09.06.2026
Gernot Fritz, Tanja Pfleger
Künstliche Intelligenz ist in vielen Unternehmen längst kein Zukunftsthema mehr. KI-Systeme beantworten Kundenanfragen, fassen Dokumente zusammen, durchsuchen interne Wissensdatenbanken, unterstützen HR-Prozesse oder helfen in der Softwareentwicklung. Damit entstehen neue Effizienzgewinne – aber auch neue rechtliche und technische Angriffsflächen.
Im Mittelpunkt stehen dabei nicht nur Fragen der richtigen Nutzung, sondern vor allem Fragen der Kontrolle: Welche Informationen gelangen in das System? Welche Quellen darf die KI abrufen? Welche Berechtigungen übernimmt ein KI-Assistent vom Nutzer? Welche Daten landen in Prompts, Logs, Chatverläufen oder Vektordatenbanken? Und wie wird verhindert, dass manipulierte Eingaben interne Informationen offenlegen oder unerwünschte Aktionen auslösen?
Prompt Injection: Wenn fremde Anweisungen das System kapern
Eine der zentralen Angriffsklassen im KI-Betrieb ist Prompt Injection. Gemeint ist damit, dass ein KI-System durch eine Eingabe dazu gebracht wird, seine eigentlichen Vorgaben zu umgehen, fremde Anweisungen zu befolgen oder Informationen preiszugeben, die es nicht offenlegen sollte.
Besonders gefährlich ist die indirekte Prompt Injection. Dabei stammt die manipulative Anweisung nicht vom Nutzer selbst, sondern ist in einem fremden Inhalt versteckt: etwa in einer E-Mail, einem Dokument, einer Webseite, einem Ticket, einem Kalendereintrag oder sogar in einem Bild. Wird dieser Inhalt von einem KI-System verarbeitet, kann das Modell die versteckte Anweisung fälschlich als relevante Instruktion behandeln.
Sicherheitsforschung und Praxistests zeigen, dass KI-Assistenten durch präparierte E-Mails, manipulierte Webseiten oder eingebettete Inhalte dazu gebracht werden können, interne Informationen offenzulegen oder unerwünschte Aktionen auszulösen. Bei multimodalen Systemen können sich versteckte Anweisungen sogar in scheinbar harmlosen Dateien oder Bildern befinden. Sobald KI-Systeme fremde Inhalte lesen und zugleich auf interne Daten oder Tools zugreifen können, entsteht eine neue Angriffsfläche.
Jailbreaking: Wenn Schutzmechanismen ausgehebelt werden
Jailbreaking ist eng mit Prompt Injection verwandt. Gemeint sind Eingaben, die darauf abzielen, Sicherheitsgrenzen eines KI-Systems zu umgehen. Das kann dazu führen, dass ein System verbotene, unerwünschte oder vertrauliche Inhalte ausgibt, obwohl es dies nach seiner Konfiguration gerade nicht tun sollte.
Rechtlich wird das insbesondere dann relevant, wenn dadurch personenbezogene Daten offengelegt, Schutzmechanismen umgangen oder unzulässige Verarbeitungen ausgelöst werden. Nicht jeder erfolgreiche Jailbreak ist automatisch ein Datenschutzvorfall. Wenn aber personenbezogene Daten unbefugt zugänglich werden, verändert oder offengelegt werden, kann regelmäßig eine Verletzung des Schutzes personenbezogener Daten im Sinne der DSGVO vorliegen.
Überprivilegierte KI-Assistenten: Der Bot darf zu viel
Besonders riskant sind KI-Anwendungen, die an E-Mail-Postfächer, HR-Systeme, CRM-Datenbanken, SharePoint, DMS-Systeme oder interne Wissensdatenbanken angebunden sind. Die praktische Gefahr liegt oft nicht im Modell selbst, sondern in den Berechtigungen rundherum.
Wenn ein KI-Assistent dieselben weitreichenden Zugriffsrechte hat wie ein Nutzer – oder sogar mehr –, kann eine manipulierte Eingabe ausreichen, um Dokumente sichtbar zu machen, die für den konkreten Zweck nicht benötigt werden. Das betrifft insbesondere RAG-Systeme, also Anwendungen, die externe oder interne Datenbestände abrufen und als Kontext an ein Sprachmodell übergeben.
RAG kann Halluzinationen reduzieren und Antworten nachvollziehbarer machen. Datenschutzrechtlich entsteht aber eine zusätzliche Verarbeitungsebene: Dokumente werden indexiert, zerlegt, in Vektoren umgewandelt, gespeichert und bei Anfragen wieder abgerufen. Für Unternehmen bedeutet das: Nicht nur das Modell muss geprüft werden. Auch Ingestion, Indexierung, Zugriffskontrolle, Berechtigungserbung, Mandantentrennung, Löschung und Logging sind rechtlich relevant.
DSGVO: Sicherheit beginnt bei der Architektur
Für KI-Systeme gelten keine datenschutzrechtlichen Sonderregeln im luftleeren Raum. Ausgangspunkt bleiben die allgemeinen Grundsätze und Sicherheitsanforderungen der DSGVO.
Art 5 Abs 1 lit f DSGVO verlangt Integrität und Vertraulichkeit der Verarbeitung. Personenbezogene Daten müssen so verarbeitet werden, dass sie gegen unbefugte oder unrechtmäßige Verarbeitung sowie gegen unbeabsichtigten Verlust, Zerstörung oder Schädigung geschützt sind. Art 25 DSGVO verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Art 32 DSGVO konkretisiert die Sicherheit der Verarbeitung und verlangt ein dem Risiko angemessenes Schutzniveau.
Übertragen auf KI bedeutet das: Prompts, Chatverläufe, Tool-Calls, RAG-Speicher, API-Keys, Logs und Fehlermeldungen sind nicht bloß technische Nebenspuren. Sie können personenbezogene Daten, Geschäftsgeheimnisse oder besonders sensible Informationen enthalten und müssen entsprechend geschützt werden.
Die CNIL betont in ihren Empfehlungen zur Entwicklung von KI-Systemen genau diesen Punkt. Sie adressiert nicht nur das Modell selbst, sondern auch Risikoanalyse, Zugriffskontrolle, Datensätze, Modellkomponenten, Dokumentation und sichere Entwicklungsumgebungen. Die CNIL weist zudem darauf hin, dass KI-Modelle, die mit personenbezogenen Daten trainiert wurden, wegen möglicher Memorisation unter die DSGVO fallen können.
Dieser ganzheitliche Blick ist entscheidend. In der Praxis entstehen Schwachstellen häufig in der Umgebung: unzureichend geprüfte Bibliotheken, schlecht abgesicherte Schnittstellen, kopierte Testdaten, offene Logs, unsichere API-Schlüssel oder unklare Verantwortlichkeiten zwischen Anbieter, Integrator und Betreiber.
Eine rein modellbezogene Prüfung reicht daher regelmäßig nicht aus. Entscheidend ist die gesamte technische und organisatorische Umgebung.
AI Act: Nicht jede KI ist Hochrisiko – aber Sicherheit wird ausdrücklich relevant
Der AI Act folgt einem risikobasierten Ansatz. Nicht jede KI-Anwendung ist ein Hochrisiko-KI-System. Die Einordnung hängt vom konkreten Zweck, der Rolle des Unternehmens und dem Einsatzkontext ab. Die Verordnung enthält aber bereits jetzt wichtige Anknüpfungspunkte für KI-Sicherheit.
Hervorzuheben ist Art 4 AI Act: Anbieter und Betreiber von KI-Systemen müssen nach besten Kräften sicherstellen, dass ihr Personal und sonstige Personen, die in ihrem Auftrag mit dem Betrieb oder der Nutzung von KI-Systemen befasst sind, über ein ausreichendes Maß an KI-Kompetenz verfügen. Das umfasst nicht nur ein Grundverständnis von KI, sondern auch den konkreten Einsatzkontext und die damit verbundenen Risiken.
Für Hochrisiko-KI-Systeme wird der AI Act noch konkreter. Art 15 AI Act verlangt ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit über den gesamten Lebenszyklus. Die Norm nennt ausdrücklich KI-spezifische Angriffe wie Data Poisoning, Model Poisoning, Adversarial Examples, Model Evasion, Angriffe auf die Vertraulichkeit und Schwachstellen des Modells. Hochrisiko-KI-Systeme müssen daher auch gegen Versuche unbefugter Dritter abgesichert werden, Nutzung, Output oder Leistung durch Ausnutzung von Schwachstellen zu verändern.
Für Betreiber von Hochrisiko-KI-Systemen kommen operative Pflichten hinzu, zB Nutzung nach Anleitung, geeignete technische und organisatorische Maßnahmen, menschliche Aufsicht durch kompetente Personen sowie Aufbewahrung automatisch erzeugter Logs, soweit diese ihrer Kontrolle unterliegen.
Wenn etwas schiefgeht: KI-Vorfall oder Datenschutzvorfall?
Nicht jeder KI-Fehler ist ein Datenschutzvorfall. Eine falsche Antwort, ein unpassender Vorschlag oder ein harmloser Jailbreak ohne Personenbezug lösen für sich genommen noch keine Meldepflicht nach der DSGVO aus.
Anders ist es, wenn personenbezogene Daten unbefugt offengelegt, verändert, verloren oder zugänglich gemacht werden. Dann ist zu prüfen, ob eine Verletzung des Schutzes personenbezogener Daten vorliegt. Nach Art 33 DSGVO muss eine solche Verletzung der zuständigen Aufsichtsbehörde gemeldet werden, sofern sie voraussichtlich ein Risiko für Rechte und Freiheiten natürlicher Personen mit sich bringt. Auftragsverarbeiter müssen den Verantwortlichen unverzüglich informieren. Bei voraussichtlich hohem Risiko für betroffene Personen kann zusätzlich eine Benachrichtigung nach Art 34 DSGVO erforderlich sein.
Für Unternehmen ist deshalb entscheidend, KI-Vorfälle nicht nur als „Modellfehler“ zu behandeln. Ein manipulierter Prompt, ein kompromittierter API-Key, ein falsch konfigurierter RAG-Speicher oder ein überprivilegierter Connector kann sehr schnell ein datenschutzrechtlich relevanter Sicherheitsvorfall werden.
Was Unternehmen jetzt tun sollten
Der wirksame Schutz gegen KI-Risiken liegt nicht in einem einzelnen Filter. Er verlangt ein mehrschichtiges Konzept.
Am Anfang steht ein vollständiger Überblick: Welche KI-Systeme werden eingesetzt? Für welche Zwecke? Durch welche Fachbereiche? Mit welchen Daten? Mit welchen Integrationen? Mit welchen Anbietern? Und mit welchen Zugriffen?
Darauf aufbauend sollten Unternehmen für jeden relevanten Use Case prüfen, welche Daten in Prompts, Kontextfenstern, RAG-Systemen, Logs und Ausgaben verarbeitet werden. Gerade Chatverläufe und Telemetriedaten werden häufig unterschätzt. Sie können besonders aussagekräftig sein, weil sie Fragen, Kontexte, interne Dokumente und Antwortmuster zusammenführen.
Technisch sollten KI-Systeme nach dem Need-to-know-Prinzip gestaltet werden. Ein Assistent darf nur jene Daten abrufen, die für den konkreten Zweck erforderlich sind. Schreibrechte, Tool-Zugriffe und externe Aktionen sollten beschränkt und bei sensiblen Vorgängen durch menschliche Bestätigung abgesichert werden.
Für RAG-Systeme braucht es ein eigenes Berechtigungskonzept. Das System darf nicht deshalb mehr sehen, weil es technisch einfacher ist. Entscheidend ist, ob der konkrete Nutzer auch im Quellsystem Zugriff auf die jeweiligen Inhalte hätte.
Ebenso wichtig sind sichere Entwicklungs- und Testumgebungen. Viele Risiken entstehen nicht im Produktivsystem, sondern in Pilotprojekten, Sandboxes oder Demos, in denen echte Daten mit unfertigen Berechtigungs- und Löschkonzepten kombiniert werden.
Schließlich sollten Incident-Prozesse ausdrücklich KI-Szenarien erfassen: Prompt Injection, Jailbreaks, Datenabfluss über Outputs, manipulierte Wissensquellen, kompromittierte API-Schlüssel, fehlerhafte Tool-Calls und unzulässige Speicherung in Logs. Nur dann kann im Ernstfall rechtzeitig beurteilt werden, ob eine Meldung an die Datenschutzbehörde oder eine Benachrichtigung betroffener Personen erforderlich ist.
Fazit
Die eigentliche Herausforderung beim Einsatz von KI liegt nicht nur darin, ob das Modell „richtig“ antwortet. Die größere Frage lautet: Welche Daten sieht das System, welche Schlüsse zieht es daraus, welche Aktionen darf es auslösen – und wer kontrolliert diese Prozesse?
Die derzeit diskutierten Omnibus-Vorschläge könnten Unternehmen bei bestimmten Hochrisiko-KI-Systemen mehr Zeit geben, Meldepflichten vereinfachen und die DSGVO-Meldefrist für Datenschutzvorfälle verlängern. Ob und in welcher Form diese Änderungen tatsächlich beschlossen werden, ist derzeit noch offen. Beides ändert aber nichts am Grundsatz: KI-Sicherheit ist schon heute Teil von Datenschutz-Compliance, IT-Sicherheit, Vertragsgestaltung und Governance.
Wer KI produktiv einsetzt, sollte Prompt Injection, Jailbreaking, RAG-Risiken, Logs, API-Schlüssel und Berechtigungen daher nicht als technische Randthemen behandeln. Sie sind der Kern einer rechtssicheren KI-Architektur.
Wer KI produktiv einsetzen will, braucht klare Verantwortlichkeiten und belastbare Prozesse. Wir helfen Ihnen gerne bei der Umsetzung.
