Der Datenweg ist größer als das Eingabefeld
Bei einem einfachen Chat scheint der Datenfluss übersichtlich: Eine Person gibt Text ein und erhält eine Antwort. Im Hintergrund können jedoch Kontodaten, Gesprächsverlauf, hochgeladene Dokumente, technische Metadaten und Sicherheitsprotokolle verarbeitet werden. In integrierten Lösungen kommen Wissensdatenbanken, E-Mail, Kalender, Fachverfahren und Schnittstellen hinzu. Entscheidend ist deshalb nicht nur, was jemand eintippt, sondern welche Informationen das Gesamtsystem erreichen kann.
Für jeden Anwendungsfall sollte eine verständliche Datenkarte entstehen: Woher kommen Informationen? Welche Datenarten sind enthalten? Wohin werden sie übertragen? Wie lange bleiben sie dort? Wer kann sie sehen? Werden sie für Training, Missbrauchserkennung oder Support verwendet? Welche Unterauftragnehmer und Regionen sind beteiligt? Eine allgemeine Aussage wie „Die KI speichert nichts“ ist ohne Produktvariante, Konfiguration und Vertrag ungefähr so präzise wie „Das Auto fährt sparsam“ ohne Strecke und Fahrweise.
Die Betrachtung umfasst auch Ausgaben. Ein Modell kann vertrauliche Informationen zusammenfassen, personenbezogene Angaben neu kombinieren oder scheinbar harmlose Einzelinformationen zu einem sensiblen Gesamtbild verbinden. Datenklassifikation darf daher nicht am Eingang enden. Auch erzeugte Texte, Bilder, Quellcode und Analysen benötigen eine passende Kennzeichnung, Ablage und Berechtigung.
Für die Datenkarte braucht es einen Eigentümer. Der Fachbereich bestätigt Zweck und benötigte Quellen, die IT beschreibt technische Wege, Informationssicherheit bewertet Zugriffe und der Datenschutz klärt personenbezogene Verarbeitung. Änderungen am Modell oder an einer Integration werden an diese Übersicht zurückgespielt. So bleibt aus einer einmaligen Zeichnung ein Arbeitsmittel für Betrieb, Vorfälle und Ausstieg.
- 01Quelle
Menschen, Dateien, Systeme und externe Inhalte.
- 02Verarbeitung
Prompt, Modell, Kontext und verbundene Werkzeuge.
- 03Speicherung
Verlauf, Protokolle, Anbieter und Unterauftragnehmer.
- 04Ausgabe
Text, Bild, Code, Bewertung oder Aktion.
- 05Löschung
Fristen, Nachweise, Backups und Vertragsende.
Sichtbar ist oft nur der Prompt. Auch Prompt-Kopien, Protokolle und Metadaten können eigene Speicher-, Ausgabe- und Löschpfade haben. Verantwortet werden muss der gesamte Weg.
Daten nach Zweck und Schutzbedarf einordnen
Nicht jede Information ist gleich kritisch. Öffentlich veröffentlichte Produktinformationen können anders behandelt werden als unveröffentlichte Planungen, Zugangsdaten, Personalinformationen oder Kundendaten. Hilfreich ist eine einfache Einteilung nach Vertraulichkeit und möglicher Schadwirkung. Entscheidend bleibt der konkrete Zusammenhang: Eine einzelne technische Bezeichnung kann harmlos sein; zusammen mit Architektur, Schwachstelle und Kundenname entsteht möglicherweise ein brauchbarer Angriffsplan.
Vor der Nutzung werden zulässige Datenarten festgelegt. Dazu gehören klare Beispiele für erlaubte, eingeschränkt erlaubte und verbotene Eingaben. Zugangsdaten, private Schlüssel, vollständige Produktionsdatenbanken und nicht freigegebene Geschäftsgeheimnisse sollten nicht versehentlich zu Testmaterial werden. Personenbezogene Daten benötigen zusätzlich eine datenschutzrechtliche Grundlage und eine Prüfung, ob der Zweck mit weniger oder pseudonymisierten Daten erreicht werden kann.
Datenminimierung ist keine rein juristische Pflichtübung. Weniger Daten bedeuten häufig eine kleinere Angriffsfläche, verständlichere Tests und geringere Folgeschäden. Ein Modell braucht nicht automatisch das gesamte Dokumentenarchiv, nur weil eine Schnittstelle es technisch zulässt. Zuerst werden die für die Aufgabe erforderlichen Informationen bestimmt; danach werden Rechte und Quellen passend begrenzt.
Praktisch helfen Testfälle für jede Datenklasse. Darf ein öffentlicher Geschäftsbericht zusammengefasst werden? Was gilt für ein internes Angebot, eine Supportanfrage mit Namen oder eine Tabelle mit Gesundheitsdaten? Solche Beispiele werden mit der Richtlinie verknüpft und regelmäßig ergänzt. Dadurch wird aus „keine sensiblen Daten“ eine Regel, die im Arbeitsalltag tatsächlich anwendbar ist.
- 01Freigegeben
Öffentliche oder ausdrücklich für den Zweck zugelassene Inhalte.
- 02Eingeschränkt
Nur in geprüften Systemen, mit passender Grundlage und Schutz.
- 03Nicht eingeben
Zugangsdaten, Schlüssel und nicht freigegebene sensible Bestände.
Die konkrete Klassifikation folgt den Regeln und Risiken der Organisation.
Anbieter, Produktvariante und Vertrag prüfen
Der Name eines Anbieters beantwortet noch nicht, wie ein konkreter Dienst Daten verarbeitet. Kostenfreie Endkundenversion, Geschäftskonto, API und lokal betriebene Lösung können unterschiedliche Bedingungen besitzen. Zu prüfen sind Vertragsrolle, Nutzungszwecke, Speicherfristen, Trainingsnutzung, Administrationsmöglichkeiten, Verschlüsselung, Unterauftragnehmer, Verarbeitungsorte, Löschung und Unterstützung bei Auskunft oder Vorfällen.
Auch Einstellungen gehören zur Freigabe. Verlauf abschalten, Trainingsnutzung ausschließen, Aufbewahrung begrenzen und zentrale Konten erzwingen kann sinnvoll sein – sofern das Produkt diese Funktionen zuverlässig bietet und sie administrativ kontrolliert werden. Eine Schutzfunktion, die jeder Nutzende mit zwei Klicks deaktivieren kann, ist eher ein freundlicher Hinweis als eine belastbare Kontrolle.
Verträge ersetzen technische Prüfung nicht. Umgekehrt ersetzt ein Penetrationstest keine klare Vereinbarung über Datenverwendung. Einkauf, Datenschutz, Informationssicherheit, IT und Fachbereich betrachten verschiedene Teile desselben Sachverhalts. Die Entscheidung wird gemeinsam dokumentiert: für welchen Zweck, mit welchen Daten, in welcher Produktvariante und unter welchen Auflagen der Dienst genutzt werden darf.
Zum Betrieb gehören Änderungsinformationen des Anbieters. Neue Modelle, längere Kontexte, automatische Websuche oder zusätzliche Plug-ins können den Datenweg verändern. Ein Review sollte deshalb vertragliche Änderungen, technische Funktionen und Sicherheitsmeldungen erfassen. Nicht jedes Update verlangt eine neue Grundsatzentscheidung; jedes wesentliche Update verlangt aber jemanden, der es bemerkt und einordnet.
Zugriffe und Integrationen klein halten
Eine eigenständige Chatoberfläche sieht nur die Informationen, die ihr gegeben werden. Ein integrierter Assistent kann dagegen Dokumente durchsuchen, Nachrichten lesen, Termine anlegen oder Datensätze verändern. Mit jedem Werkzeug wächst der Nutzen – und die mögliche Wirkung eines Fehlers. Deshalb erhält eine KI nur die Rechte, die für den freigegebenen Anwendungsfall notwendig sind.
Lesen und Schreiben werden getrennt. Entwürfe sind etwas anderes als Versand, Vorschläge etwas anderes als Buchung und Analyse etwas anderes als Löschung. Folgenreiche Aktionen benötigen Vorschau, fachliche Freigabe, Mengenbegrenzung oder technische Rücknahme. Eigene technische Identitäten, kurze Berechtigungszeiten und aussagekräftige Protokolle erleichtern Widerruf und Nachvollziehbarkeit.
Besondere Vorsicht gilt für externe Inhalte. Dokumente, Webseiten und E-Mails können Anweisungen enthalten, die ein KI-System fehlinterpretiert. Prompt Injection ist deshalb kein Problem, das allein durch eine freundlichere Systemanweisung verschwindet. Nicht vertrauenswürdige Inhalte werden von Steuerinformationen getrennt; Werkzeuge validieren Parameter und erzwingen Rechte unabhängig vom Modell.
Bei wissensgestützten Systemen muss außerdem die bestehende Berechtigung der Quelle erhalten bleiben. Ein Suchindex darf Beschäftigten nicht Dokumente erschließen, die sie im ursprünglichen System nicht sehen dürften. Filter werden serverseitig durchgesetzt und getestet, auch bei Gruppenwechsel, Austritt und Freigabelinks. Die KI soll Wissen auffindbar machen, nicht nebenbei das Berechtigungskonzept kreativ interpretieren.
- 01Lesen
Begrenzte Quellen und nur notwendige Daten.
- 02Vorschlagen
Entwurf ohne unmittelbare Außenwirkung.
- 03Freigeben
Qualifizierter Mensch sieht Inhalt und Folgen.
- 04Ausführen
Technische Limits, Protokoll und Rücknahme.
Eine gute Antwort ist noch keine Erlaubnis, eine Aktion auszuführen.
Ausgaben bleiben prüfbedürftig
Generative Modelle erzeugen plausible Ausgaben, nicht automatisch wahre Aussagen. Sie können Quellen erfinden, Rechenwege verkürzen, veraltete Informationen verwenden oder einen unsicheren Codevorschlag liefern. Deshalb richtet sich die Kontrolle nach dem möglichen Schaden. Ein interner Ideenentwurf benötigt weniger Prüfung als eine Kundeninformation, eine Personalentscheidung oder ein Skript mit Produktionsrechten.
Prüfregeln werden vor der Nutzung festgelegt: Welche Quellen sind zulässig? Welche Fakten müssen belegt sein? Wer darf freigeben? Wann muss die KI Unsicherheit anzeigen oder die Bearbeitung abbrechen? Stichproben genügen nur dort, wo Fehler rechtzeitig entdeckt und leicht korrigiert werden können. Bei hoher Wirkung braucht es eine Einzelfallprüfung durch eine fachlich geeignete Person.
Auch die Ausgabe selbst kann schädlich sein. Sie kann personenbezogene Daten enthalten, Schadcode vorschlagen, beleidigende Aussagen erzeugen oder bestehende Rechte verletzen. Filter des Anbieters sind hilfreich, aber kein vollständiger Schutz. Die Organisation bleibt dafür verantwortlich, was sie verwendet, veröffentlicht oder in andere Systeme übernimmt.
Für Code gelten zusätzlich normale Entwicklungsregeln. Vorschläge durchlaufen Review, Tests, Abhängigkeitsprüfung und Sicherheitsanalyse; Geheimnisse und produktive Konfigurationen bleiben außen vor. Ein syntaktisch überzeugender Vorschlag kann unsichere Bibliotheken, fehlende Fehlerbehandlung oder erfundene Schnittstellen enthalten. KI verändert die Herkunft des Entwurfs, nicht die Verantwortung für die Auslieferung.
Protokollierung mit Augenmaß gestalten
Protokolle helfen, Fehler, Missbrauch und Vorfälle zu untersuchen. Sie können zugleich besonders sensible Inhalte sammeln: Prompts, Dokumentauszüge, Ausgaben, Nutzerkennungen und Systemaktionen. Deshalb wird festgelegt, welche Ereignisse für Sicherheit und Nachweis wirklich benötigt werden. Vollständige Gesprächsinhalte sind nicht automatisch die beste oder einzige Form der Nachvollziehbarkeit.
Geeignete Protokolle erfassen beispielsweise technische Identität, Zeitpunkt, verwendetes System, Datenquelle, aufgerufenes Werkzeug, Freigabe und Ergebnisstatus. Inhalte können gekürzt, kategorisiert oder getrennt geschützt werden. Zugriff erhalten nur zuständige Rollen; Aufbewahrung und Löschung folgen einem begründeten Zweck. Ein Protokoll, das jeder lesen kann, löst ein Nachweisproblem und schafft nebenbei ein neues Sicherheitsproblem.
Bei produktiven Änderungen muss nachvollziehbar sein, welche Modell- oder Systemversion, welche Konfiguration und welche Quellen beteiligt waren. Das ist besonders wichtig, wenn Ergebnisse später nicht reproduzierbar sind. Vollständige Reproduzierbarkeit ist bei probabilistischen Systemen nicht immer erreichbar; eine belastbare Ereigniskette bleibt trotzdem möglich.
Monitoring betrachtet nicht nur Verfügbarkeit. Auffällige Mengen, ungewöhnliche Werkzeugaufrufe, abgelehnte Freigaben, Qualitätsabfall und steigende Kosten können auf Fehlkonfiguration oder Missbrauch hinweisen. Schwellenwerte werden mit dem normalen Betrieb abgeglichen, damit nicht jede intensive Nutzung zum Alarm wird. Ein Alarm, der ständig ertönt, trainiert vor allem das Wegklicken.
Vorfälle, Löschung und Ausstieg vorbereiten
Ein KI-Vorfall kann eine falsche Berechtigung, eine sensible Eingabe, eine manipulierte Datenquelle, einen unerwarteten Output oder eine unzulässige Aktion betreffen. Nutzende brauchen einen einfachen Meldeweg. Die erste Reaktion lautet: Zugriff begrenzen, Sachverhalt sichern, Wirkung verstehen und zuständige Rollen einbinden. Die Schuldfrage kann warten, bis das Problem nicht mehr wächst.
Für Löschung wird geklärt, welche Daten in Verlauf, Protokollen, Wissensspeichern, Backups und beim Anbieter liegen. Eine Löschung in der Oberfläche entfernt nicht zwingend jede Kopie sofort. Verträge, technische Funktionen und dokumentierte Fristen müssen zusammenpassen. Bei personenbezogenen Daten kommen Betroffenenrechte und Nachweispflichten hinzu.
Auch das Ende eines Dienstes wird geplant. Daten, Vorlagen und Konfigurationen werden exportiert, technische Identitäten entzogen, Schnittstellen geschlossen und Löschungen bestätigt. Fachbereiche erhalten ein Ersatzverfahren. Ein Anbieterwechsel ist wesentlich entspannter, wenn er vor dem Kündigungstermin einmal gedanklich stattgefunden hat.
Notfalltests prüfen einen konkreten Ablauf: Dienst sperren, betroffene Zugänge widerrufen, eine alternative Arbeitsweise aktivieren und nach der Bereinigung kontrolliert wieder starten. Dabei wird sichtbar, ob Kontakte, Protokolle und Exportdaten unabhängig erreichbar sind. Ein Notfallplan im selben ausgefallenen System besitzt eine gewisse konzeptionelle Eleganz, praktisch aber nur begrenzten Nutzen.
Modelle und Änderungen kontrolliert testen
Ein Sicherheitstest umfasst normale Aufgaben, Grenzfälle und absichtlich problematische Eingaben. Geprüft werden Datenoffenlegung, unerlaubte Werkzeugaufrufe, Prompt Injection, fehlerhafte Quellen, überlange Eingaben und der Umgang mit Unsicherheit. Testdaten werden so gewählt, dass keine echten Geheimnisse für einen Sicherheitstest gefährdet werden. Synthetische und gezielt freigegebene Fälle reichen für viele Prüfungen aus.
Die Ergebnisse werden nach Wirkung bewertet. Ein falscher Stilhinweis ist etwas anderes als eine fremde Akte, ein ausgeführter Befehl oder unsicherer Code. Für wichtige Fehler gibt es Abbruchkriterien und Verantwortliche. Schutzmaßnahmen werden erneut getestet, nachdem Modell, System-Prompt, Datenquelle, Werkzeug oder Berechtigung geändert wurden. Die Aussage „Das Modell wurde verbessert“ ersetzt keinen Regressionstest.
Nicht jede Schwäche lässt sich vollständig beseitigen. Verbleibende Risiken werden sichtbar akzeptiert, technisch begrenzt oder führen zu einem engeren Einsatzzweck. Besonders bei generativen und agentischen Systemen ist Sicherheit eine Kombination aus Modell, Anwendung, Identität, Schnittstelle und Betriebsprozess. Wer nur das Modell testet, prüft einen wichtigen Teil – aber eben nur einen Teil.
Vor dem produktiven Start werden Abnahmekriterien schriftlich festgelegt. Dazu gehören zulässige Fehlerquoten, verbotene Datenoffenlegungen, maximale Berechtigungen, ein funktionierender Abbruch und die Reaktion auf fehlende Quellen. Für kritische Fälle testet eine zweite Person unabhängig vom Entwicklungsteam. Ergebnisse, Abweichungen und akzeptierte Restrisiken bleiben nachvollziehbar. Nach dem Start werden reale Fehlerbilder in den Testbestand übernommen. So wächst die Prüfung mit dem Betrieb, statt nach einer gelungenen Vorführung im Archiv zu verschwinden. Auch hier gilt: Ein grünes Häkchen ist ein Ergebnis eines bestimmten Tests zu einem bestimmten Zeitpunkt, kein allgemeines Gütesiegel für jede künftige Nutzung.
Praxisbeispiel: interner Dokumentenassistent
Ein fiktives Unternehmen möchte freigegebene Richtlinien mit einem internen Assistenten durchsuchen. Zunächst werden nur aktuelle Dokumente ohne Personal- oder Kundendaten eingebunden. Das System darf Antworten mit Fundstellen erzeugen, aber keine Richtlinie ändern und keine verbindliche Einzelfallentscheidung treffen. Fachverantwortliche prüfen normale Fragen, Widersprüche und Fälle ohne ausreichende Quelle.
Die Datenkarte zeigt, dass Dokumente beim Cloudanbieter verarbeitet, Protokolle dreißig Tage gespeichert und technische Metadaten länger aufbewahrt werden. Die Organisation wählt die passende Geschäftsversion, begrenzt Administrationsrechte und schaltet eine Nutzung für Modelltraining vertraglich und technisch aus. Antworten ohne Fundstelle werden nicht zur Verwendung freigegeben.
Im Pilot zeigt sich, dass veraltete Fassungen in einer Ablage liegen. Der Datenbestand wird bereinigt, bevor weitere Nutzer hinzukommen. Das ist kein Versagen der KI. Sie hat lediglich sichtbar gemacht, dass eine gute Antwort von einem gepflegten Informationsbestand abhängt. Alles hängt mit allem zusammen – gelegentlich sogar die Dokumentenlenkung mit dem modernen Assistenten.
Vor dem Rollout werden messbare Kriterien festgelegt: Anteil der Antworten mit korrekter Fundstelle, berechtigte Nicht-Antworten, kritische Fehler, notwendige Nacharbeit und Meldungen zu unzulässigen Inhalten. Änderungen an Quellen oder Modell lösen Stichproben aus. So bleibt der Assistent ein betreuter Dienst und wird nicht nach einer gelungenen Demonstration sich selbst überlassen.
Häufige Fragen
Dürfen vertrauliche Daten grundsätzlich in eine KI eingegeben werden?
Nicht pauschal. Zulässig ist die Eingabe nur, wenn Zweck, Produktvariante, Vertrag, Konfiguration, Berechtigungen und Schutzmaßnahmen zur Datenklasse passen. Für besonders sensible Inhalte kann eine abgeschottete oder lokal betriebene Lösung notwendig sein. Zugangsdaten und private Schlüssel gehören grundsätzlich nicht in Prompts. Maßgeblich sind die freigegebenen Regeln der eigenen Organisation.
Werden Eingaben automatisch zum Training verwendet?
Das hängt vom Dienst, Tarif, Vertrag und den Einstellungen ab. Manche Anbieter schließen Trainingsnutzung für Geschäftskonten oder APIs aus, andere bieten Wahlmöglichkeiten. Zusätzlich können Daten für Protokollierung, Sicherheit oder Support gespeichert werden. Die konkrete Produktdokumentation und Vereinbarung müssen geprüft werden; eine allgemeine Aussage über einen Anbieter reicht nicht.
Reicht Anonymisierung für eine sichere Nutzung?
Nur wenn sie tatsächlich belastbar ist. Entfernte Namen reichen nicht, wenn Personen aus Kombinationen, Kontext oder seltenen Merkmalen wiedererkannt werden können. Der EDPB verlangt für anonyme KI-Modelle eine Einzelfallprüfung und eine sehr geringe Wahrscheinlichkeit von Identifizierung oder Datenextraktion. Häufig ist Pseudonymisierung realistischer; dann bleibt die DSGVO anwendbar.
Was ist Prompt Injection?
Dabei beeinflussen präparierte Eingaben oder externe Inhalte das Verhalten eines KI-Systems entgegen dem vorgesehenen Zweck. Ein Dokument könnte etwa Anweisungen enthalten, Informationen preiszugeben oder ein Werkzeug aufzurufen. Schutz entsteht durch minimale Rechte, Trennung von Daten und Steuerung, validierte Schnittstellen, Freigaben und Überwachung. Ein System-Prompt allein ist keine belastbare Sicherheitsgrenze.
Müssen alle Prompts vollständig protokolliert werden?
Nein. Umfang und Inhalt folgen Zweck, Risiko und rechtlichen Anforderungen. Vollständige Prompts können selbst sensible Daten enthalten. Häufig genügen technische Identität, Zeitpunkt, System, Werkzeugaufruf, Freigabe und Ergebnisstatus; für bestimmte Fälle kann mehr Inhalt erforderlich sein. Aufbewahrung, Zugriff und Löschung müssen festgelegt und transparent sein.
Wie prüft man KI-Ausgaben angemessen?
Die Prüftiefe richtet sich nach Fehlerfolgen und Korrigierbarkeit. Interne Entwürfe können mit Stichproben auskommen; externe Aussagen, Code, Personal- oder Sicherheitsentscheidungen benötigen strengere Fachprüfung. Prüfer brauchen Quellen, Kontext, Zeit und echte Ablehnungsmöglichkeit. Eine menschliche Freigabe ist nur dann eine Kontrolle, wenn der Mensch sinnvoll prüfen kann.
Was gehört in einen KI-Sicherheitsvorfallprozess?
Ein einfacher Meldeweg, erreichbare Zuständige, technische Begrenzung, Beweissicherung, Bewertung von Daten und Systemaktionen sowie Kommunikation mit Datenschutz, Recht oder Anbieter. Danach folgen Wiederherstellung, Ursachenanalyse und Verbesserung. Der Prozess sollte auch Fehlfreigaben, Datenabfluss, manipulierte Quellen und unerwartete autonome Aktionen abdecken, nicht nur klassische Systemausfälle.
Quellen und weitere Informationen
Diese Seite bietet allgemeine Orientierung und ersetzt keine rechtliche, datenschutzrechtliche oder sicherheitsbezogene Prüfung des Einzelfalls.
Quellenstand: 27. Oktober 2026.