KI im Praxiseinsatz: Wo Datenschutz- und Sicherheitsrisiken wirklich entstehen

Datenquelle

Ein solides Risikobewusstsein beginnt bei den Daten. Schon bei der Erhebung können personenbezogene Informationen enthalten sein, oft auch dort, wo man es nicht erwartet (z. B. in Logs, Freitextfeldern, Tickets oder „harmlosen“ Metadaten). Datenschutzbehörden betonen, dass KI-Modelle regelmäßig personenbezogene Daten verarbeiten.

Von „echter“ Anonymität kann nur dann gesprochen werden, wenn eine Identifizierung von Personen oder die Extraktion personenbezogener Informationen sehr unwahrscheinlich ist und genau das ist in der Praxis selten. Es braucht dafür belastbare Rechtsgrundlagen, eine konsequente Datenminimierung und, wo sinnvoll, die Pseudonymisierung der personenbezogenen Daten. Der Europäische Datenschutzausschuss (EDPB) hat hierzu eine umfangreiche Stellungnahme veröffentlicht: Sie ordnet mögliche Rechtsgrundlagen ein, zeigt Grenzen des „berechtigten Interesses“ auf und beschreibt die Folgen von Rechtsverstößen in der Entwicklungsphase. 

Diese Folgen wirken in den Betrieb hinein. Wer beim Training gegen Datenschutz verstößt, kann das spätere System nicht einfach „reinwaschen“. 

Modell

Beim Modell selbst stehen vor allem zwei Risiken im Fokus. Erstens: Data Poisoning (Datenvergiftung). Schon wenige manipulierte Trainingsdaten können Modellverhalten verzerren oder unerwünschte Effekte dauerhaft verankern. Security-Publikationen und speziell Analysen der ENISA (European Union Agency for Cyber Security) stufen das als relevante Bedrohung ein. Zweitens: unbeabsichtigte Memorisation. Sprachmodelle können Teile ihres Trainingskorpus wiedergeben, inklusive personenbezogener oder geschützter Inhalte. Studien zeigen, dass sich bestimmte Sequenzen (z. B. besonders eindeutige Datenmuster) gezielt extrahieren lassen. Neuere Arbeiten beschreiben zudem Angriffe, die das Modell gezielt „verwirren“, um so die Wahrscheinlichkeit von Memorisation und ungewollter Ausgaben zu erhöhen. Das macht Red-Teaming, robuste Testverfahren und Datenschutzmaßnahmen im Training unverzichtbar. 

Betrieb

Im Betrieb entstehen weitere Risiken, beispielsweise könnten Prompts bösartig gestaltet sein: Direkt oder indirekt lassen sich versteckte Anweisungen einschleusen, die Regeln aushebeln oder Geheimnisse abfragen. Das betrifft Chatbots, Assistenzsysteme und RAG-Anwendungen gleichermaßen. Entsprechend braucht es Eingabefilter, klare Systemprompts, saubere Quellenhygiene und Laufzeitkontrollen. Gleichzeitig steigt die Gefahr von „Schatten-KI“: Mitarbeitende nutzen nicht genehmigte GenAI-Dienste, teilen sensible Daten und umgehen die unternehmenseigene Governance. Analysten erwarten, dass bis 2030 mehr als 40 % der Unternehmen dadurch Sicherheits- oder Compliance-Vorfälle erleben. Das ist kein Randthema, sondern eine Kernaufgabe für IT, Datenschutz und andere Fachbereiche. 

Internationaler Datentransfer ist ein weiteres zentrales Risiko. Seit dem EuGH Urteil „Schrems II“ sind Übermittlungen in Drittländer nur zulässig, wenn ein im Wesentlichen gleichwertiges Schutzniveau sichergestellt ist. Unternehmen benötigen dafür typischerweise Standardvertragsklauseln (SSC) oder Binding Corporate Rules (BCR)und ggf. zusätzlich ein Transfer Impact Assessment (TIA). Häufig sind technische Zusatzmaßnahmen erforderlich, etwa eine starke Verschlüsselung mit Schlüsselkontrolle innerhalb der EU. Ohne diese Schritte entstehen rechtliche Lücken und zugleich Angriffsflächen. Leitfäden zeigen, wie sich TIAs, SCCs und ergänzende Maßnahmen konsistent zusammenführen und laufend überwachen lassen. 

Schatten‑KI

Schatten-KI entsteht dort, wo Regeln fehlen oder nicht gelebt werden: Mitarbeitende probieren schnelle Lösungen aus, laden Dateien hoch oder kopieren Inhalte in öffentliche KI-Assistenten. Das wirkt effizient, ist aber riskant. Studien und Marktanalysen berichten von realen Vorfällen – vom Verlust geistigen Eigentums bis hin zu Datenschutzverletzungen. Die Gegenmittel sind nicht kompliziert: eine klare KI-Policy, freigegebene Werkzeuge, Sensibilisierung und technisches Monitoring. Ohne diese Bausteine bleibt Governance ein Papiertiger. 

Trainings‑Leakage

Trainings-Leakage hat oft banale Ursachen: Datensätze sind nicht sauber bereinigt, eindeutig personenbezogene Daten bleiben im Korpus, und es fehlen Prüfungen auf Ausreißer oder Duplikate. Die Forschung zeigt, wie hartnäckig Memorisation sein kann. Selbst wenn einzelne angreifbare Beispiele entfernt werden, können an anderer Stelle neue Angriffspunkte entstehen („Privacy Onion Effect“). Deshalb braucht es mehrschichtige Maßnahmen: personenbezogene Daten-Filter, Deduplizierung, Ausreißer-/Anomalieerkennung, geeignete Trainingsverfahren (z. B. mit Privacy-Mechanismen) und regelmäßige Red-Team-Tests. Mit diesen Maßnahmen senkt man die reale Rate unbeabsichtigter Leakausgaben und nicht nur das subjektive Sicherheitsgefühl.

Rollenverantwortlichkeit

Unklare Rollen sind ein organisatorisches Risiko. Anbieter, Betreiber, Datenschutzbeauftragte, Security und weitere Fachbereiche tragen jeweils definierte Aufgaben. Die KI-Verordnung und DSGVO setzen hier klare Erwartungen. Wenn Verantwortlichkeiten nicht feststehen, bleiben Prüfungen liegen und am Ende fühlt sich niemand zuständig. Abhilfe schafft ein verbindliches Rollenmodell mit klaren Entscheidungswegen, einer geregelten Eskalation und Dokumentation. Das ist ohne großen Formalismus machbar, muss aber im Alltag gelebt werden.

Vendor‑Risiken

Vendor-Risiken wachsen mit der Abhängigkeit. Wer sich stark auf eine Plattform festlegt, hängt an Roadmap, Schnittstellen und Prioritäten des Anbieters. Hinzu kommen Datenstandorte, Subprozessoren und Update-Zyklen, die man nicht selbst steuert. Leitfäden zur Cloud-Nutzung nach dem Schrems-II-Urteil empfehlen Transfer Assessments, klare Vertragsklauseln zu Log-Zugriff und Datenstandorten sowie einen belastbaren Exit-Plan. Dadurch bleibt man handlungsfähig, auch wenn sich technische oder rechtliche Rahmenbedingungen ändern.

Messungen entscheiden, ob Kontrollen tatsächlich wirken. Eine zentrale Kennzahl ist die Leakage-Rate in Tests: Wie oft gibt das System in kontrollierten Szenarien personenbezogene Daten aus? Ermitteln lässt sich das über kuratierte Testprompts, definierte Angriffsszenarien und wiederholbare Testläufe. Studien zeigen, dass Modelle unter bestimmten Bedingungen Trainingsinhalte reproduzieren können. Wer diese Rate nachhaltig senkt, stärkt Privatsphäre messbar, typischerweise durch saubere Korpora, Privacy-verstärkende Verfahren (z. B. Differential Privacy, wo passend), Ausreißererkennung/Deduplizierung und robuste Ausgabefilter.

Ein zweites Steuerinstrument ist die Prompt-Resilienz. Sie beschreibt, wie gut ein System gegen direkte und indirekte Prompt-Injection abgesichert ist. Praktische Tests prüfen, ob Systemprompts überschrieben werden können, ob versteckte Anweisungen aus Dokumenten „durchschlagen“ und Tools oder Funktionen missbraucht werden. Sicherheitsberichte und Leitfäden erläutern diese Angriffsmuster und Gegenmaßnahmen. Wer hier konsequent testet (inkl. Regressionstests nach Updates), reduziert Betrugsfälle, Datenabflüsse und „Policy-Bypass“-Effekte deutlich.

Drittens ist Data Lineage entscheidend: Sie macht nachvollziehbar, woher Trainings- und RAG-Daten stammen, welche Versionen und Lizenzen gelten, welche Rechtsgrundlagen greifen und wohin Daten fließen. Gerade in internationalen Szenarien (Stichwort Schrems II) ist diese Transparenz unverzichtbar. Gute Lineage vereinfacht Transfer-Bewertungen und Risikoanalysen, beschleunigt Reviews durch Kunden oder Aufsicht und sorgt insgesamt für ruhigere Projekte, weil Verantwortlichkeiten, Nachweise und Datenflüsse eindeutig sind.

Auch die Rechenschaftspflicht lässt sich messen. Wie vollständig sind die Logs? Decken sie die definierten Ereignisse ab (Zugriffe, Konfigurationsänderungen, Modell-/Prompt-Versionen, Tool-Aufrufe)? Werden Retentionsfristen eingehalten, und sind Rollen für Zugriff und Prüfung klar geregelt? Ein regelmäßiges Review nach Art. 32 („testen, bewerten, evaluieren“) schließt den Kreis: Kontrollen sind nur so gut wie ihr Nachweis im Betrieb.

Antwortlängen, reine Token-Zahlen oder allgemeine „Halluzinationsraten“ können für Produktteams nützlich sein, verbessern den Datenschutz aber meist nur indirekt. Der Schwerpunkt sollte auf Metriken mit direkter Wirkung liegen: Leakage-Rate, Prompt-Resilienz, Lineage-Abdeckung und Audit-/Log-Vollständigkeit. Ein Outcome-Fokus statt reiner Checklisten hält das Monitoring schlank und wirklich steuerungsrelevant.

KI‑Sicherheit und Datenschutz gelingen, wenn Governance, Technik und dokumentierte Nachweise zusammenspielen. Die KI‑VO sorgt für einen klaren Rahmen, der die Privatsphäre nicht verdrängt, sondern stärkt. Der Datenschutz bleibt der Dreh‑ und Angelpunkt für Rechtsgrundlagen, Datenschutz-Folgenabschätzungen und Sicherheit der Verarbeitung. Mit sauberem Daten‑Clearing, starker Prompt‑Härtung, belastbaren Logs und wiederverwendbaren Templates wird KI nicht zum Risiko, sondern zum verlässlichen Werkzeug. Wer sich an bewährte Leitlinien hält und Empfehlungen von Aufsichtsbehörden ernst nimmt, schafft eine belastbare Basis für verantwortungsvolle KI-Nutzung in der Praxis.