Einen KI-Assistenten an Unternehmensdaten anzubinden ist eine Berechtigungsentscheidung, kein Produkt-Rollout. Gehen Sie davon aus: Alles, was der Assistent lesen kann, kann potenziell jeder extrahieren, der mit ihm sprechen kann, und alles, was er tun kann, kann potenziell jeder auslösen, der seine Eingaben beeinflussen kann. Klären Sie fünf Punkte, bevor der Pilot startet: welche Daten zulässig sind, was der Assistent tun darf, wer ihn nutzen darf, was protokolliert wird und wer das Risiko verantwortet.
Ein Hinweis zur Herkunft der Aussagen: Punkte, die aus OWASP oder NIST stammen, sind als solche benannt und verlinkt. Alles andere in dieser Checkliste ist unsere eigene Empfehlung und keine Anforderung einer der beiden Organisationen.
Festlegen, welche Daten einfließen dürfen
Beginnen Sie mit der Klassifizierung, denn jede weitere Kontrolle hängt davon ab. Falls Sie noch kein Schema haben, genügt für den Anfang ein dreistufiges. Es muss schriftlich vorliegen, bevor jemand ein Postfach, eine Dateiablage oder ein CRM anbindet.
| Stufe | Typische Inhalte | Regel für den Assistenten |
|---|---|---|
| Öffentlich | Veröffentlichte Website-Texte, Produktdatenblätter | Erlaubt |
| Intern | Richtlinien, Projektnotizen, interne Wikis | Nur für freigegebene Tools erlaubt |
| Vertraulich | Personenbezogene Daten, Verträge, Zugangsdaten, Quellcode, Finanzdaten | Ausgeschlossen, bis ein benannter Verantwortlicher zustimmt |
Zwei Punkte werden häufig übersehen. Erstens lesen Konnektoren meist ganze Repositories oder Laufwerke ein, sodass auch ein Ordner indexiert wird, von dessen Freigabe niemand mehr weiß. Bereinigen Sie Freigaben vor der Anbindung, nicht danach. Zweitens machen Geheimnisse in Dokumenten (API-Keys auf Wiki-Seiten, Passwörter in Tickets) aus einer Suchfunktion ein Leck für Zugangsdaten.
Davon ausgehen, dass der Assistent feindlichen Text liest
Behandeln Sie alles, was der Assistent liest (eingehende E-Mails, Webseiten, geteilte Dokumente, hochgeladene Dateien), als Inhalt, den jemand anderes verfasst haben könnte, um den Assistenten zu steuern. Wir empfehlen, den Einsatz so zu gestalten, dass dies keinen Schaden anrichtet, statt sich allein auf einen System-Prompt als einzige Kontrolle zu verlassen.
In der Praxis heißt das:
- Geben Sie dem Assistenten nur die minimal nötigen Tools. Zunächst nur Lesezugriff.
- Verlangen Sie eine menschliche Bestätigung für jede Aktion mit Nebenwirkungen: E-Mails versenden, Datensätze ändern, Code ausführen, Zahlungen auslösen.
- Halten Sie nicht vertrauenswürdige Inhalte von Assistenten fern, die zugleich Zugriff auf vertrauliche Daten haben.
- Behandeln Sie die Ausgabe des Assistenten als nicht vertrauenswürdige Eingabe für jedes System, das sie weiterverarbeitet. Wenn ein nachgelagertes System sie ausführt oder darstellt, validieren Sie sie wie Benutzereingaben.
Als Referenzliste für Risiken von LLM-Anwendungen empfehlen wir die OWASP Top 10 for Large Language Model Applications. Die Projektseite beschreibt das OWASP GenAI Security Project als globale Open-Source-Initiative zu Sicherheitsrisiken generativer KI, darunter LLMs, agentische KI-Systeme und KI-gestützte Anwendungen. Dort heißt es, die Top 10 blieben ein zentraler Bestandteil, und es ist eine Version von 2025 aufgeführt. Für die aktuelle Liste verweist die Seite auf genai.owasp.org/llm-top-10/. Lesen Sie diese Liste und nutzen Sie ihre Kategorien als Struktur für Ihr Threat Model, statt eine eigene zu erfinden.
Zugriffskontrolle und Logging
Der Assistent sollte mit den Berechtigungen der fragenden Person handeln, nicht mit einem breit berechtigten Servicekonto. Nutzt er eine einzige gemeinsame Identität mit Zugriff auf alles, kann ein Berufseinsteiger womöglich Vorstandsunterlagen abrufen, indem er seine Frage geschickt formuliert. Prüfen Sie, wie der Konnektor mit nutzerbezogenen Berechtigungen umgeht, und testen Sie dies vor dem Go-live mit zwei Konten unterschiedlicher Seniorität.
Entscheiden Sie anschließend, was protokolliert wird. Mindestens sollten Sie genug erfassen, um einen Vorfall rekonstruieren zu können:
timestamp, user id, assistant/tool name,
source documents retrieved, actions requested,
actions executed, confirmation (yes/no), result statusLegen Sie vorab fest, wie lange Sie diese Logs aufbewahren, wer sie lesen darf und ob die Prompts selbst personenbezogene Daten enthalten. Konversationsprotokolle sind ein eigener Datenbestand und müssen wie die darin enthaltenen Inhalte klassifiziert werden. Leiten Sie sie an die Stelle weiter, die Ihr Monitoring betreibt, damit ein ungewöhnliches Abrufvolumen eines einzelnen Kontos auffällt.
Den Anbieter vor Vertragsabschluss prüfen
Stellen Sie dem Anbieter direkte Fragen und lassen Sie sich die Antworten schriftlich geben:
- Werden unsere Prompts und Dokumente zum Training oder zur Verbesserung von Modellen verwendet? Lässt sich das vertraglich ausschließen, nicht nur per Einstellung?
- Wo werden Daten verarbeitet und gespeichert, und welche Unterauftragsverarbeiter sind beteiligt?
- Wie lange werden Prompts, Ausgaben und hochgeladene Dateien aufbewahrt, und können wir sie löschen?
- Welche Admin-Kontrollen gibt es: Single Sign-on, rollenbasierter Zugriff, Audit-Export, Allow-Lists für Konnektoren?
- Wie werden Sicherheitsvorfälle gemeldet, und innerhalb welcher Frist?
Prüfen Sie, ob die Antworten zur tatsächlichen Admin-Konsole passen. Eine Richtlinienseite und eine konfigurierbare Einstellung sind zwei verschiedene Dinge. Bietet das Tool Plug-ins oder Konnektoren von Drittanbietern, prüfen Sie diese als eigenständige Lieferanten.
Dem Risiko einen Verantwortlichen zuweisen
Governance klingt nach Papierarbeit, und das ist sie auch, doch sie verhindert Schatten-Deployments. Das NIST AI RMF Playbook enthält Handlungsempfehlungen, die sich an den vier Funktionen des AI Risk Management Framework orientieren: Govern, Map, Measure und Manage. NIST betont, das Playbook sei weder eine Checkliste noch eine vollständig abzuarbeitende Schrittfolge, und seine Empfehlungen seien freiwillig. Zudem weist NIST darauf hin, dass AI RMF 1.0 aktualisiert wird und das Playbook folgen soll. Prüfen Sie daher, welche Version aktuell ist. Übernehmen Sie, was zur Größe Ihres Unternehmens passt.
Wir empfehlen ein kurzes Register aller eingesetzten KI-Tools, jeweils mit Verantwortlichem, den Datenstufen, die das Tool berühren darf, und einem Prüfdatum. Ergänzen Sie eine weitere Spalte: ob die Rechtsabteilung bestätigt hat, dass Pflichten aus dem EU AI Act oder der DSGVO für diesen Anwendungsfall gelten, und zu welchem Ergebnis sie gekommen ist. Diese Pflichten haben wir hier nicht bewertet. Lassen Sie dies daher von Rechtsberatung oder einer Compliance-Beratung klären. Wenn Sie Unterstützung beim Aufbau des Registers und des Prüfprozesses wünschen, deckt unsere Beratungsleistung Readiness-Assessments ab.
Wo Sie anfangen
- Erfassen Sie alle bereits genutzten KI-Assistenten, auch kostenlose Konten, die Mitarbeitende selbst angelegt haben, und benennen Sie für jeden einen Verantwortlichen.
- Verfassen Sie die oben beschriebene dreistufige Klassifizierung und ordnen Sie jede angebundene Datenquelle einer Stufe zu. Nehmen Sie vertrauliche Quellen aus dem Umfang heraus.
- Führen Sie einen Pilot mit reinem Lesezugriff, nutzerbezogenen Berechtigungen und menschlicher Bestätigung für jede Aktion durch. Testen Sie ihn mit zwei Konten unterschiedlicher Seniorität.
- Aktivieren Sie das Logging, legen Sie eine Aufbewahrungsdauer fest und leiten Sie die Logs an die Stelle weiter, die Ihre Systeme überwacht.
- Senden Sie die Anbieterfragen ab, legen Sie die schriftlichen Antworten zum Vertrag und lassen Sie die Rechtsabteilung bestätigen, ob Pflichten aus dem EU AI Act oder der DSGVO gelten.
- Lassen Sie den Aufbau vor einem breiteren Rollout von jemandem testen, der versucht, ihn anzugreifen. Ein Penetrationstest mit Szenarien rund um Ihre tatsächlichen Konnektoren zeigt, was ein Threat Model auf dem Papier übersieht.
