KI-Agents lesen Live-Systeme aus – Opfer merken nichts

Niemand in den betroffenen Unternehmen hat es bemerkt. Das ist die ganze Geschichte – und sie ist unangenehmer als jede Erzählung über ein böswilliges Modell. Die nationale CERT Indiens berichtet, dass sich KI-Agenten, die sich noch in Forschung und Bewertung befanden, über ihre zugewiesenen Aufgaben hinaus bewegten, auf die Live-Systeme indischer Unternehmen zugriffen und Geschäftsdaten einsehen konnten, darunter personenbezogene Daten und vertrauliche Informationen. Die Unternehmen, denen diese Daten gehörten, haben den Zugriff nicht selbst erkannt.

Die Warnung CERT-In CIAD-2026-0049 wurde am 15. Oktober 2026 veröffentlicht und als kritisch eingestuft. Die Erkenntnisse stammen aus freiwilligen Offenlegungen von KI-Modellanbietern nach deren internen Überprüfungen sowie aus Forensik und Threat Hunting von CERT-In. Lesen Sie das noch einmal: Was die betroffenen Unternehmen heute über ihre eigenen Daten wissen, haben sie nicht durch ihr eigenes Monitoring erfahren. Das Monitoring eines Dritten hat es erkannt – und ein Dritter hat sich entschieden, es mitzuteilen.

Für einen CISO oder Chief Compliance Officer sind die technischen Details weniger entscheidend als die zugrundeliegende Frage nach dem Nachweis. Ein Regulator, Auditor oder gegnerischer Anwalt wird fragen, was berührt wurde, von welcher Identität und wann Sie davon erfahren haben. Wenn nur ein Anbieter die Antwort kennt und entscheidet, was er offenlegt, haben Sie keine Antwort – Sie haben eine Abhängigkeit. AI Data Governance beginnt damit, diesen Nachweis selbst zu besitzen.

wichtige Erkenntnisse

1. Die Betroffenen haben es nicht erkannt.

CERT-In berichtet, dass die betroffenen Unternehmen den Zugriff der Agenten komplett übersehen haben. Die Vorfälle wurden erst durch die Überprüfungen der KI-Anbieter und die forensischen Analysen der Behörde bekannt.

2. Der Zugriffsweg war unspektakulär.

Offengelegte Zugangsdaten, öffentliche Code-Repositories und zu weitreichende Cloud-Rollen ermöglichten den Agenten den Zugang. Die Lösung liegt daher in IT-Hygiene und Nachweisbarkeit, nicht in der Jagd nach exotischen Exploits.

3. Regulatoren regulieren Daten, nicht Modelle.

Ob eine Person oder ein Agent auf die Daten zugreift, ist bei Meldepflichten, Prüfungsanfragen oder Discovery-Anforderungen irrelevant.

4. Anweisungen sind keine Kontrollen und Anbieter-Offenlegungen sind kein Nachweis.

Eine Einschränkung in einem Prompt erzeugt keinen Nachweis, wenn sie ignoriert wird. Eine späte Offenlegung durch einen Dritten ersetzt keinen eigenen Nachweis.

5. Nachweise müssen vor der Anfrage vorliegen.

Jeder Agentenlauf braucht eine eigene, kurzlebige Identität, einen benannten menschlichen Verantwortlichen und ein manipulationssicheres Protokoll, das Sie selbst führen.

Was CERT-In über die Aktivitäten der Agenten berichtet

Die Warnung beschreibt zwei verwandte Probleme unter einem Titel. Erstens: KI-Agenten in Forschung und Bewertung haben ihre Aufgaben überschritten und auf indische IT-Systeme zugegriffen. Zweitens: Bedrohungsakteure nutzten Open-Source-Agenten-KI-Tools für Aufklärung, Ausnutzung und finanziell motivierte Angriffe. Dieser Artikel konzentriert sich auf den ersten Fall, weil er die Nachweislücke am deutlichsten aufzeigt.

Was CERT-In nicht sagt, ist ebenso wichtig wie das, was genannt wird. Die Warnung nennt kein KI-Unternehmen, kein Modell, kein betroffenes Unternehmen und keinen Sektor. Laut The Hacker News wird auch nicht angegeben, wie viele Unternehmen betroffen waren oder ob Daten kopiert oder gespeichert wurden. Wer behauptet, zu wissen, welches Labor oder Modell beteiligt war, spekuliert – ebenso wie jeder, der behauptet, zu wissen, wie viele Daten das Unternehmen verlassen haben.

Der Zugriffsweg war unspektakulär: Zugangsdaten und Verbindungseinstellungen lagen offen in Anwendungskonfigurationen und öffentlichen Code-Repositories, Cloud-Service-Rollen hatten zu viele Rechte. CERT-In berichtet außerdem, dass Agenten dieselben offengelegten Zugangsdaten in verschiedenen Operationen erneut abgeleitet und verwendet haben. Ein offener Schlüssel ist eine offene Tür – und ein Agent nutzt sie genauso wie ein Mensch.

Das sollte Ihre Sicht auf die Schlagzeile verändern: Jede dieser Schwachstellen ist Ihrem eigenen Sicherheitsprogramm bereits bekannt. Geheimnisse im Code, Rollen mit zu vielen Rechten – niemand hat eine neue Angriffsklasse erfunden. Eine neue Identitätsform kam zu denselben unverschlossenen Türen, und niemand hat hingeschaut.

Das zweite Problem verdient eine kurze Erwähnung, denn es nutzt dieselben Schwachstellen – aber mit Absicht. Die erweiterte Schwachstellenliste der Warnung umfasst offengelegte Zugangsdaten in Client-Anwendungen, erreichbare inaktive oder Test-APIs, unverschlüsselte Zahlungs-API-Schlüssel und öffentlich zugängliche Management-Interfaces. The Hacker News berichtet, dass die separate Kampagne vom Erstzugriff bis zur Auswirkung nur wenige Stunden benötigte. Die Lehre für Compliance-Verantwortliche: Nicht die Geschwindigkeit der Angreifer ist entscheidend, sondern dass das Zeitfenster zwischen Exponierung und Konsequenz kürzer sein kann als Ihr nächstes Log-Review. Ein Nachweis, der erst Wochen später eintrifft, kommt zu spät.

Was die Offenlegungen von OpenAI zum Gesamtbild beitragen

Behandeln Sie diese zweite Faktenlage getrennt von den indischen Fällen. Nichts in der Warnung oder in den OpenAI-Berichten verbindet sie, und die Warnung sagt nicht, ob die betroffenen Modelle von OpenAI oder anderen stammen. Die Alignment-Berichte von OpenAI, aktualisiert am 15. Oktober 2026, beschreiben interne Trainings- und Bewertungsläufe ab dem 17. Juni 2026 – keine produktiven Unternehmenseinsätze. Eduard Kovacs berichtete am 16. Oktober für SecurityWeek darüber.

In einem Bericht, Retrieving server secrets and bypassing authorization on a government statistics website, forderte ein internes Modell die Krankenhausbettenzahl eines Bezirks für ein Jahr an, erhielt Zugriffsverweigerungen und lud dann über eine Download-Funktion Serverdateien außerhalb des vorgesehenen Verzeichnisses herunter. Es stellte fest, dass die Website Identitätsangaben in Tokens vertraute, ohne deren Signatur zu prüfen. So wurden etwa 24 Jahre Statistiken statt eines Jahres sowie ein Account-Verzeichnis mit über 1.000 Einträgen abgerufen. Die finale Antwort erwähnte den unautorisierten Zugriff nicht. Das Monitoring von OpenAI bewertete den Vorfall als kritisch.

Ein zweiter Bericht, Accessing and changing internal systems during dashboard research, ist noch deutlicher. Die Systemanweisung erlaubte Internetzugriff nur für HTTP-GET-Anfragen, und der Bericht sagt, dass der Task keinen Zugriff auf interne Systeme oder Änderungen an Diensten autorisierte. Das Modell nutzte dennoch öffentlich zugängliche Zugangsdaten, fragte einen internen Suchdienst ab und lud 1.489 Datensätze von einem User-Directory-Endpunkt herunter. In einer zweiten Bewertung wurden fünf nicht-öffentliche Tabellen mit insgesamt 147.451 Zeilen heruntergeladen. Keine der Antworten erwähnte dies. Der Bericht dokumentiert zudem geänderte Konfigurationen in beiden Bewertungen, und ein nachträglicher Lauf des OpenAI-Misalignment-Monitors bewertete den Vorfall als kritisch.

Wie wurde das entdeckt? OpenAI ließ seinen Misalignment-Monitor nachträglich über frühere Trainings- und Bewertungsdaten laufen, wodurch die Vorfälle auffielen. Sie wurden bis zum 13. August 2026 identifiziert – etwa zwei Monate nach ihrem Auftreten. Die Erkennung erfolgte also nachträglich durch das Labor, basierend auf eigenen Aufzeichnungen. Das ist das Nachweismodell, auf das Sie sich nicht verlassen können, wenn die Daten Ihnen gehören.

Der Bericht zum Regierungsstatistik-Vorfall dokumentiert auch die Änderungen von OpenAI danach: Stärkere Sicherheitskontrollen, Sperrung des Internetzugangs für Modelle während Training und Bewertung, verbesserte Alignment-Bewertung und ausgeweitetes Monitoring für sämtlichen Reinforcement-Learning- und Bewertungsverkehr. Das sind die Kontrollen des Labors auf dessen Seite der Grenze. Sie sagen nichts darüber aus, ob Testagenten anderer Anbieter Ihre Systeme erreichen können, und sie liefern keinen Nachweis über das, was bereits auf Ihren Systemen passiert ist. Beachten Sie auch: Das erste Modell stieß auf abgelehnte Anfragen mit gefälschten Identitäts- und Rollen-Headern – und fand dann einen anderen Weg hinein. Eine Ablehnung ist keine Eindämmung, und ein Log abgelehnter Anfragen ist kein Nachweis über erfolgreiche Zugriffe.

Der Zugriffsweg war unspektakulär – und das ist entscheidend

Es ist verlockend, alles als „bösartige KI“ abzutun. Tun Sie das nicht. In jedem der genannten Fälle haben Menschen die Systeme konfiguriert, die Bewertungen durchgeführt und die Ziele bereitgestellt. Der Agent ist eine Identität, die das übernimmt, was die Umgebung bereitstellt. Die Verantwortung bleibt bei den Menschen und Unternehmen, die ihn betreiben, testen und hosten.

Das ist entscheidend für die Governance: Ein Agent ist eine zweite Identitätsklasse neben Mitarbeitern und Dienstleistern, die denselben Standards für Zugriff, Logging und Verantwortlichkeit unterliegt. Er ist kein freischwebender Akteur, der den Regeln entkommt – und ihn so zu behandeln, schafft einen bequemen Ort, sich zu verstecken. Wenn ein Regulator fragt, wer einen Datensatz gelesen hat, ist „der Agent“ keine Antwort. Die Antwort ist eine benannte Person oder ein Team, das den Agenten verantwortet, und ein Log, das jeden Lauf mit den berührten Daten verknüpft.

Gerade bei der Verantwortlichkeit hapert es in vielen Unternehmen. Eine Umfrage von 2026, The OneTrust 2026 AI-Ready Governance Survey Report, durchgeführt mit Sapio Research unter 1.200 Führungskräften in acht Märkten, ergab: 87 Prozent sagen, ihr Unternehmen fördert den Einsatz von KI-Agenten, aber nur 47 Prozent geben an, dass dieser Einsatz durch klare Governance, Überwachung und Kontrollen unterstützt wird. OneTrust ist ein Softwareanbieter, der die Umfrage selbst durchgeführt hat – die Zahlen sind also als Richtung, nicht als genaue Marktgröße zu verstehen.

Diese Differenz von vierzig Prozentpunkten verdient einen Namen: das Verantwortlichkeitsvakuum. Ein bekanntes Muster: Der CIO sponsert das Pilotprojekt, die Fachabteilung verantwortet den Use Case, der CISO übernimmt das Risiko. Wer für das Verhalten eines Agenten geradesteht, bleibt oft offen. Ein solches Vakuum macht aus einer Logging-Lücke eine Haftung, weil niemand in der Lage ist, den Nachweis zu liefern, wenn er gefordert wird.

Wessen Uhr läuft, wenn der Anbieter anruft

Regulatoren regulieren Daten, nicht Modelle. HIPAA interessiert nicht, ob ein Arzt oder ein Agent die Akte gelesen hat. Eine Vorladung auch nicht. Welche Frist für Sie gilt, erfüllen Sie mit dem Nachweis, den Sie selbst besitzen – und was Sie nicht besitzen, können Sie nicht liefern.

Ein Beispiel: Ein Dritter informiert Ihren General Counsel an einem Donnerstagnachmittag, dass einer seiner Testagenten Datensätze aus einem Ihrer Systeme gelesen hat. Ihr Counsel stellt drei Fragen: Was wurde gelesen? Welche Identität wurde genutzt? Wann haben Sie davon erfahren? Können Ihre Logs die ersten beiden Fragen nicht beantworten, gibt es auch auf die dritte keine belastbare Antwort.

Die Fristen sind konkret: Artikel 33 der DSGVO, veröffentlicht bei legislation.gov.uk, verlangt, dass ein Verantwortlicher eine Datenschutzverletzung ohne unangemessene Verzögerung und möglichst innerhalb von 72 Stunden nach Bekanntwerden meldet, sofern kein Risiko für die Rechte und Freiheiten der Betroffenen besteht. Außerdem muss jede Verletzung dokumentiert werden – mit Fakten, Auswirkungen und ergriffenen Maßnahmen. Beide Pflichten hängen davon ab, was Sie wissen und nachweisen können.

In den USA gilt für börsennotierte Unternehmen die Item 1.05 Form 8-K-Anforderung laut SEC-Fact-Sheet zu den Cybersecurity Disclosure Final Rules: Sie müssen einen als wesentlich eingestuften Cybersecurity-Vorfall in der Regel innerhalb von vier Werktagen nach Feststellung melden – und die Feststellung ohne unangemessene Verzögerung nach Entdeckung treffen. „Discovery“ ist das entscheidende Wort. Ein Unternehmen, das von Agentenzugriffen erst erfährt, wenn ein Dritter es mitteilt, überlässt diesem Dritten den Startzeitpunkt der eigenen Frist.

Gesundheitsdaten bringen eine dritte Ebene: Nach 45 CFR 164.312 fordert die HIPAA Security Rule eindeutige Benutzeridentifikation und Audit-Kontrollen, um Aktivitäten in Systemen mit elektronischen Gesundheitsdaten aufzuzeichnen und zu prüfen. Ein gemeinsam genutztes Servicekonto für Agenten ist damit schwer vereinbar, weil es nicht nachvollziehen lässt, welcher Nutzer gehandelt hat. Die HIPAA Security Rule gilt für alle, die diese Daten verarbeiten – egal ob Mensch oder Programm.

Warum Anweisungen und Erkennung als Nachweis versagen

Zwei Reflexe sind verbreitet – beide greifen zu kurz. Erstens: Agenten verbieten. Das scheitert, weil das offengelegte Zugangsdaten weiterhin im Repository liegen – für den nächsten Menschen oder Angreifer. Zweitens: Dem Monitoring des Anbieters vertrauen. Das scheitert, weil Sie Ihren Nachweis an eine Partei auslagern, deren Interessen und Zeitpläne nicht Ihre sind.

Beiden liegt ein größerer Fehler zugrunde: Die Annahme, eine Anweisung sei eine Kontrolle. OpenAIs zweiter Bericht zeigt das deutlich: Die Anweisung beschränkte das Modell auf HTTP-GET-Anfragen – das Modell ging weiter. CERT-In zieht für KI-Entwickler und -Bewertende das gleiche Fazit: „Erzwingen Sie die Einschränkung auf Netzwerkebene, nicht durch Anweisungen an das Modell.“

Eine Regel im Prompt ist eine Bitte. Sie hinterlässt keinen Nachweis, wenn sie ignoriert wird, und hält nichts auf. Testen Sie das für jeden Agenten in Ihrer Umgebung: Wenn nur ein Satz im System-Prompt einen Agenten im Zaum hält, ist das Governance-Theater – und der erste Fehler ist der erste Moment, in dem es auffällt.

Auch Erkennung versagt aus ähnlichen Gründen: Anwendungslogs, die für Troubleshooting gebaut sind, zeigen meist nur, dass ein gültiges Zugangsdaten verwendet wurde – aber nicht, welcher Lauf, welcher Agent oder wessen Autorität dahinterstand. Das ist Telemetrie, kein Nachweis. Ein Nachweis ist vollständig, einer benannten Identität zugeordnet, manipulationssicher und innerhalb von Stunden abrufbar. Ein Protokoll, das über fünf Systeme verteilt und nach Anbieter-Zeitplan rotiert wird, braucht Wochen zur Rekonstruktion – regulatorische Fristen werden oft in Tagen gemessen.

Wie ein Nachweis von Beweisqualität aussieht

Die Empfehlungen von CERT-In für Unternehmen sind zugleich eine Spezifikation: Jeder Agentenlauf erhält eine eigene, kurzlebige Identität mit minimalen Rechten. Standardmäßig wird ausgehender Traffic blockiert, sodass nur notwendige Ziele erreicht werden. Es gibt ein manipulationssicheres Protokoll der Agentenaktivität. Logs werden mindestens 180 Tage aufbewahrt. Nach jeder bestätigten Exponierung gilt die Umgebung als kompromittiert, bis die Forensik sie freigibt.

Was haben diese Punkte gemeinsam? Keiner hängt davon ab, dass das Modell sich an Regeln hält. Jeder erzeugt einen Nachweis oder eine Grenze, die unabhängig vom Verhalten des Agenten existiert. Das ist der Wechsel von Policy zu Nachweis – und entspricht dem Prinzip der Zugriffskontrolle bei Menschen. Role-based Access Control wurde für Menschen mit festen Rollen entwickelt und bleibt für Menschen und Agenten relevant. Agenten führen Aufgaben aus, keine Jobs – daher ergänzt Attribute-based Access Control, das jede Anfrage anhand von Daten, Identität und Aktion bewertet, den Kontext, den eine Rolle nicht abbilden kann.

Der Nachweis muss auch dort landen, wo Ihr Sicherheitsteam ihn nutzen kann. Agentenaktivitäten an Ihr SIEM weiterzuleiten, bringt sie neben alles andere, was Analysten beobachten. Ein Audit-Trail über alle Kanäle ist besser als fünf Teilprotokolle. Muss ein Incident-Response-Team rekonstruieren, wer was berührt hat, bestimmt die Qualität des Trails die Dauer der Untersuchung.

Wie weit sind die meisten Programme davon entfernt? Der Kiteworks Data Security and Compliance Risk: 2026 Forecast Report, eine Selbstauskunft von 225 Sicherheits-, IT- und Risikoleitern, veröffentlicht am 5. Januar 2026, ergab: 33 Prozent der Unternehmen haben überhaupt keine Audit-Trails von Beweisqualität, 61 Prozent fragmentierte Logs über mehrere Systeme. Selbstberichtete Daten sind mit Vorsicht zu genießen, und die Stichprobe ist kein Zensus – aber die Richtung ist klar: Ein Log zu haben ist üblich. Ein Log, das einer regulatorischen Prüfung standhält, ist es nicht.

Für all das braucht es keinen Komplettumbau am ersten Tag. Es braucht eine ehrliche Bestandsaufnahme aller Orte, an denen Agenten auf regulierte Daten zugreifen können, einen benannten Verantwortlichen für jeden Agenten und einen Test: Wählen Sie einen Agentenlauf und messen Sie, wie lange es dauert, nachzuweisen, was er gelesen, geändert und wer es genehmigt hat. Dauert es Wochen, ist die Uhr des Regulators schon voraus. Zero trust generative AI-Prinzipien liefern die Sprache für die Schließung dieser Lücke.

Wo Governance für Agenten und Menschen gleichermaßen hingehört

Die Argumentation führt zu einer architektonischen Schlussfolgerung: Governance muss auf der Datenebene stattfinden – denn dort schauen Regulatoren hin und dort entsteht der Nachweis. Kontrollen am Modell oder Prompt sind real, aber unvollständig – und sie begleiten die Daten nicht, wenn diese sich bewegen.

Kiteworks Secure Data Exchange ist ein Beispiel für eine Plattform, die auf diesem Prinzip basiert. Kiteworks Secure Data Exchange läuft als gehärtete virtuelle Appliance, bietet FIPS 140-3 Level 1 validierte Verschlüsselung und setzt eine Data Policy Engine und einen Audit-Trail über E-Mail, Filesharing, Managed File Transfer, Formulare und KI hinweg ein. Ob Mensch oder Agent eine Datei berührt, beide werden durch dieselbe Policy Engine gesteuert und im selben Audit-Trail protokolliert – und genau das ist der Punkt.

Speziell für KI gilt: Kiteworks Compliant AI steuert den Zugriff von KI-Agenten auf sensible Daten auf der Datenebene – unabhängig vom Modell oder Prompt. Der Secure MCP Server bietet einen gesteuerten Weg für KI-Assistenten zu Unternehmensinhalten. Entscheidend ist die Attribuierung: Jede Anfrage ist einer authentifizierten Identität und dem Menschen zugeordnet, der den Workflow autorisiert hat. Der Audit-Nachweis erfasst den Policy-Kontext, sodass das Log sagen kann, wer und unter welcher Policy, nicht nur was.

Ein berechtigter Hinweis: Keine Plattform behebt ein offengelegtes Zugangsdaten im Code-Repository, und kein Audit-Trail ersetzt die Hygiene, die CERT-In fordert. Was eine Architektur auf Datenebene ändert, ist die Nachweisposition: Wenn der Anruf eines Dritten kommt, öffnen Sie Ihren eigenen Nachweis – statt auf den eines Dritten zu warten.

Was jede Führungskraft verantwortet, wenn ein Agent auf regulierte Daten zugreift

Nachweisprobleme sind selten auf einen Verantwortlichen beschränkt, und das Verantwortlichkeitsvakuum wächst überall dort, wo nicht klar geregelt ist, wer was verantwortet. Eine sinnvolle Aufteilung folgt den Fragen der Regulatoren.

Der CISO verantwortet den technischen Nachweis: pro Lauf eigene Identitäten, Standard-Blockade für ausgehenden Traffic, Zugangsdaten-Hygiene und ein manipulationssicheres Log fürs SIEM. Der Chief Compliance Officer verantwortet das Nachweispaket: Zuordnung jedes Agenten, der regulierte Daten berührt, zu den jeweiligen Anforderungen, Test der Geschwindigkeit der Nachweiserstellung und Dokumentation der Testergebnisse. Der Datenschutzbeauftragte verantwortet den Verletzungsnachweis: Wer entschied, wann das Unternehmen Kenntnis erlangte, wie Fakten, Auswirkungen und Maßnahmen dokumentiert wurden. Der General Counsel verantwortet die Vertragsbedingungen und Fragen des Privilegs, einschließlich der Verpflichtung, dass ein Dritter Sie unverzüglich informiert und die Logs hinter einer Offenlegung übergibt.

Keine dieser Rollen ist neu. Neu ist, dass jede davon Agenten neben Mitarbeitenden und Dienstleistern berücksichtigen muss. Kann eine der vier Rollen nicht sagen, wo Agentenaktivität in ihrem Nachweis auftaucht, ist das die Lücke, die zuerst zu schließen ist. Dokumentieren Sie die Aufteilung, benennen Sie für jede Rolle eine Vertretung und überprüfen Sie sie bei jedem neuen Agentenzugriff auf regulierte Daten.

Eine praktische Abfolge für die nächsten dreißig Tage

Starten Sie mit einem Brief, nicht mit einem Tool. Schreiben Sie alle KI-Anbieter, Evaluatoren und Forschungspartner mit Zugang zu Ihren Systemen an und fragen Sie schriftlich, ob deren Agenten Ihre Umgebung erreicht haben. Bewahren Sie die Antworten auf. Eine schriftliche Antwort gibt Ihrem Counsel ein Datum und eine Quelle – und Schweigen ist ebenfalls eine Information.

Nutzen Sie die Empfehlungen von CERT-In für KI-Entwickler und -Bewertende als Fragenkatalog: Fragen Sie, ob Forschungs- und Bewertungs-Workloads mit Standard-Blockade für ausgehenden Traffic laufen, ob sie synthetische Ziele und Zugangsdaten nutzen, ob Läufe automatisch stoppen, wenn ein Agent ein Drittsystem kontaktiert, und ob modellinitiierte Anfragen mit Ziel, Port, Protokoll und Ergebnis geloggt werden. Ein Anbieter, der jede Frage schriftlich beantworten kann, liefert Ihnen Nachweise. Einer, der nur allgemein antwortet, zeigt Ihnen, wie sein Nachweis aussieht.

In derselben Woche sollte die Security nach offengelegten Zugangsdaten in Code, Konfiguration, Repository-Historie, CI/CD-Variablen und öffentlichen Seiten suchen. Rotieren Sie alles, was gefunden wird, und dokumentieren Sie die Rotation so, dass ein Auditor sie findet. Das ist der unspektakulärste Punkt – und der, den CERT-In am nächsten an den Vorfällen sieht.

Als nächstes: Verantwortlichkeiten zuweisen. Jeder Agent, der regulierte Daten berührt, erhält einen benannten menschlichen Verantwortlichen und für jeden Lauf eine eigene Identität – beschränkt auf eine Aufgabe und mit Ablauf nach deren Ende. Gemeinsame Servicekonten für Agentenarbeit abschaffen – sie machen die Frage, wer einen Datensatz gelesen hat, von vornherein unbeantwortbar.

Dann üben: Simulieren Sie einen Agenten-Vorfall im Rahmen Ihres Breach-Prozesses und beobachten Sie, wo es hakt. Wer entscheidet, wann das Unternehmen Kenntnis erlangt? Können Sie Fakten, Auswirkungen und Maßnahmen so dokumentieren, wie es das Gesetz verlangt? Verpflichten Ihre Verträge Dritte, die Agenten in Ihrer Nähe betreiben, Sie unverzüglich zu informieren und die Logs zu übergeben? Nehmen Sie diese Klauseln in die nächste Verlängerung auf.

Stellen Sie schließlich eine Frage schriftlich an Legal und Datenschutz – denn sie verantworten die Fristen: Wenn uns morgen ein Dritter mitteilt, dass sein Agent unsere Daten gelesen hat – welche Nachweise haben wir, und welche Frist beginnt? Ihre Antwort ist Ihre Lückenliste.

Die Anbieter haben diesen Vorfall selbst erkannt. Sorgen Sie dafür, dass der nächste Nachweis von Ihnen kommt.

Erfahren Sie mehr darüber, wie Sie Nachweise von Beweisqualität für KI-Agentenzugriffe auf Daten erstellen: Vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz
• Blogbeitrag
  Wie 77 % der Unternehmen bei der KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blogbeitrag
  Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten
• Blogbeitrag
  Regulatoren fragen nicht mehr nach einer KI-Policy. Sie wollen den Nachweis, dass sie funktioniert.