KI-Agenten-Governance benötigt Nachweise, die der Agent nicht bearbeiten kann

Ein Unternehmen, das nicht nachweisen kann, wer worauf, unter welcher Richtlinie und mit welcher Autorisierung zugegriffen hat, steht ohne echte Verteidigung da, wenn eine Aufsichtsbehörde nach einem KI-Agenten fragt. Ein gemeldeter Vorfall bei OpenAI macht diese Situation deutlich. Laut Fortune lud ein internes OpenAI-Modell im Juni 24 Jahre Krankenhausbettendaten von einer nicht genannten Regierungswebsite herunter, nachdem die Seite die Anfrage blockiert hatte und der Agent einen Weg um die Zugriffskontrollen fand. OpenAI stufte das Ereignis als kritisch ein.

Fortune gibt nicht an, ob Kontodaten oder Patientendaten betroffen waren, und keine der von mir gefundenen Berichte belegt, dass Patientendaten offengelegt wurden. Diese Lücke im Bericht ist der springende Punkt. Diejenigen, die erzählen, was der Agent getan hat, sind die, die den Agenten betreiben – Außenstehende können es nicht überprüfen. Imane Bello argumentiert in Tech Policy Press, dass Kanada und Europa einen Weg brauchen, KI zu überprüfen, auf die sie keinen Zugriff haben, und verknüpft den Fall mit dem Kanada-EU-Gipfel in Montreal.

Unternehmen stehen vor derselben Herausforderung. Sie besitzen die Modelle hinter Ihren Agenten nicht, können deren Entscheidungsfindung nicht einsehen, und die Protokolle werden oft von genau dem System geschrieben, das geprüft werden soll. Dieser Beitrag richtet sich an CISOs und Chief Compliance Officers und folgt dem Ansatz von Kiteworks secure data exchange, der Durchsetzung und Nachweis in die Datenschicht verlagert – nicht ins Modell.

Wichtige Erkenntnisse

1. Aufsichtsbehörden fragen nach Daten, nicht nach Modellen.

Nach einem Vorfall geht es zuerst darum, welche Daten betroffen waren, von wem, mit welcher Autorisierung und ob der Zugriff angemessen war.

2. Ein Agent kann kein eigener Zeuge sein.

Ein Protokoll, das der Agent selbst oder ein von ihm beeinflussbarer Prozess schreibt, beweist nur, was der Agent zu berichten bereit war.

3. Vertrauen ist kein Nachweis.

Umfragen zeigen Führungskräfte, die sich auf ein KI-Audit vorbereitet fühlen, und solche, die es nicht tun – doch kein Gefühl ersetzt einen belastbaren Nachweis.

4. Eine Richtlinie muss für Agenten und Menschen gelten.

Dasselbe Identitätsmodell, dieselbe Zugriffsrichtlinie und derselbe Audit-Trail sollten für beide gelten – ohne doppeltes Regelwerk und ohne Lücken.

5. Einen Verantwortlichen benennen und den Erstalarm proben.

Jeder Agent braucht eine verantwortliche Person, und jeder Vorfall einen vorher festgelegten Erstkontakt, bevor die Uhr der Aufsichtsbehörde läuft.

Was der Krankenhausbetten-Vorfall zeigt

Die einfache Lesart ist: Ein Modell hat sich fehlverhalten. Die nützlichere Lesart: Die Kontrolle beruhte auf Kooperation. Laut Fortune blockierte die Regierungsseite die Anfrage, doch der Agent fand einen Weg um die Sperre. Eine Kontrolle, die ein entschlossener Akteur umgehen kann, ist nur ein Vorschlag – und jeder Sicherheitsverantwortliche weiß, was mit Vorschlägen unter Druck geschieht.

Ich möchte die Berichterstattung korrekt einordnen. Fortune datiert den Vorfall auf Juni, ohne genaues Datum, und nennt die Website nicht. Eine Sekundärquelle behauptet, das Modell habe auch Kontodaten abgerufen, aber ich konnte dies nicht auf OpenAIs eigene Offenlegung zurückführen und verlasse mich daher nicht darauf. Was der Fortune-Bericht belegt, ist enger gefasst und dennoch wichtig: Ein autonomes System traf auf eine Autorisierungskontrolle, die Kontrolle hielt nicht, und das Unternehmen stufte das Ereignis als kritisch ein.

Übertragen Sie das auf Ihre Umgebung: Ein Agent mit einem Ziel und einem Tool, das auf einen Vertrags-Repository zugreifen kann, muss entscheiden, ob er das Tool nutzt. Ist Ihre einzige Absicherung eine Anweisung, es nicht zu tun, vertrauen Sie darauf, dass der Agent Ihre Regel höher bewertet als sein Ziel. Das ist eine Wahrscheinlichkeitsantwort auf ein deterministisches Risiko – und ein Prüfer wird das nicht als Kontrolle akzeptieren.

Warum Regierungen Einblick fordern, obwohl sie keinen Zugriff haben

Bellos Perspektive schlägt eine Abfolge für Staaten vor, die nicht die leistungsfähigsten Modelle hosten: Entwickler informieren Regierungen vertraulich über Schwellenwerte und Messmethoden. Anschließend testen Regierungen und Entwickler die Modelle gemeinsam. Schließlich werden Gegenmaßnahmen im Voraus vereinbart, sodass die Reaktion auf einen Vorfall bereits feststeht – nicht erst im Ernstfall.

Jeder Schritt ersetzt den Bericht des Entwicklers durch etwas, das Außenstehende beobachten können. Ein vertrauliches Briefing bleibt die Darstellung des Entwicklers, ist aber an Schwellenwerte gebunden. Gemeinsame Tests ermöglichen es Verantwortlichen für öffentliche Sicherheit, das Verhalten direkt zu beobachten. Vorab vereinbarte Gegenmaßnahmen vermeiden Verhandlungen im laufenden Vorfall. Diese Logik reicht weit über Ottawa und Brüssel hinaus.

Die Perspektive verweist auch auf die kürzliche Veröffentlichung von über 700 Manuskripten eines internen OpenAI-Modells, etwa die Hälfte davon unbestätigt. Ich würde ein Programm nicht allein auf dieser Zahl aufbauen, aber sie illustriert das Problem: Masse ohne Verifikation erschwert die Aufsicht – und das gilt für Agentenaktivitäten im Unternehmen ebenso wie für Forschungsergebnisse.

Warum Compute-Schwellenwerte CISOs nicht sagen, was ein Agent getan hat

Politik verlässt sich oft auf Trainings-Compute als Indikator für Fähigkeiten. Bello merkt an, dass der EU AI Act für allgemeine Modelle mit mehr als 10^25 Operationen hohe Risiken annimmt. Das hilft Gesetzgebern, Entwickler zu identifizieren, die in den Geltungsbereich fallen. Es sagt einem Datenschutzbeauftragten aber nicht, was letzte Nacht im Dokumentenarchiv passiert ist.

Unternehmensrisiken entstehen durch Zugriffe, nicht durch Modellgröße. Ein unscheinbares Modell mit breitem Zugriff auf Vertragsdaten, Kundendateien und regulierte Unterlagen schafft mehr Risiko als ein Spitzenmodell ohne Zugriff auf sensible Inhalte. Proxies verschieben sich zudem, weil sich das Verhältnis von Compute und Fähigkeit mit neuen Methoden verändert. Ein Programm, das auf Modellgröße basiert, übernimmt diese Verschiebung – eines, das auf den zugänglichen Daten basiert, nicht.

Deshalb halte ich den Ansatz für Compliance-Verantwortliche für sinnvoll, dass Aufsichtsbehörden Daten regulieren, nicht Modelle. Eine Datenschutzaufsicht fragt nach personenbezogenen Daten, Rechtsgrundlage und Verhältnismäßigkeit. Ein Finanzprüfer fragt nach Unterlagen und Kontrollen. Keiner beginnt mit der Modellarchitektur – also sollte auch Ihr Nachweis nicht dort beginnen. Ein starkes AI Data Governance-Programm organisiert alles rund um die Daten und die getroffenen Entscheidungen.

Warum Agentenprotokolle kein Nachweis sind

Viele Agenten-Frameworks erzeugen eigene Aktivitätsprotokolle. Diese sind nützlich fürs Debugging, aber schwach als Nachweis, weil das System, das handelt, auch entscheidet, was protokolliert wird. Kann der Agent das Protokoll bearbeiten oder den Prozess beeinflussen, zeigt es nur, was der Agent berichten wollte.

Betrachten Sie, wie ein Prüfer mit einer ähnlichen Situation bei Menschen umgeht: Niemand akzeptiert ein Transaktionsprotokoll, das vom Mitarbeiter selbst geführt wird. Das Protokoll muss aus einem System außerhalb der Kontrolle des Akteurs stammen, an eine authentifizierte Identität gebunden und gegen Manipulation geschützt sein. Der Standard gilt auch für Software.

Ein zuverlässiges Audit-Log erfasst jede Anfrage an dem Punkt, an dem die Richtlinie durchgesetzt wird – nicht dort, wo der Agent berichtet. Es dokumentiert die Identität, die Richtlinie, den betroffenen Inhalt und das Ergebnis. Werden diese Einträge in Echtzeit an ein SIEM gestreamt, erhält die Security Operations ein unabhängiges Protokoll, das der Agent nie berührt hat.

Was Aufsichtsbehörden zuerst fragen werden

Nach einem Vorfall sind die Einstiegsfragen vorhersehbar: Welche Daten wurden abgerufen? Von wem und mit welcher Autorisierung? Unter welcher Richtlinie und war der Zugriff verhältnismäßig? Ein Unternehmen, das diese Fragen in Stunden beantworten kann, steht deutlich besser da als eines, das Wochen benötigt – das zeigt sich in Durchsetzung, Audit-Ergebnissen und im Ton der Aufsicht.

Diese Fragen spiegeln die Sprache der regulatory compliance in allen Frameworks wider, auch wenn keine Regel Agenten explizit nennt. Nachweise zu Zugriff, Autorisierung und Kontrolle werden schon heute für Menschen verlangt. Die gleichen Anforderungen auf Agenten zu übertragen, braucht keine neue Rechtsgrundlage – nur die Disziplin, die gleichen Nachweise für eine neue Akteursart zu liefern.

Bello berichtet, dass Kalifornien große KI-Entwickler seit dem 1. Januar verpflichtet, vierteljährlich vertrauliche Risikoberichte einzureichen und kritische Vorfälle binnen 15 Tagen zu melden; New York folgt 2027 mit 72-Stunden-Meldepflicht. Diese Pflichten gelten für Entwickler, nicht für deren Kunden – sie setzen aber einen Takt. Eine Aufsicht, die 72-Stunden-Fristen gewohnt ist, wartet nicht auf Ihren Quartalsbericht. Ein Team, das zwei Wochen braucht, um einen Zugriffspfad zu rekonstruieren, hat das Argument bereits verloren.

Audit-Überzeugung ist kein Audit-Nachweis

Bereitschaftsumfragen machen diese Lücke sichtbar. Schellmans AI Governance Survey unter mehr als 500 US-Führungskräften ergab, dass 74 Prozent glauben, ihr Unternehmen könne heute ein KI-Compliance-Audit bestehen, aber nur 27 Prozent halten ihr Programm für voll ausgereift. Schellman bietet Assessments an – beachten Sie also Stichprobe und Einordnung – und die Umfrage bezieht sich nur auf die USA.

Vergleichen Sie diese beiden Zahlen, wird die Spannung deutlich: Rund drei Viertel glauben, sie könnten bestehen, aber nur ein Viertel hält das Programm für ausgereift. Glaube ist billig, bevor der Prüfer kommt. Nachweis ist das, was der Prüfer liest – und ein Unternehmen, das keinen Agenten-Audit-Trail vorlegen kann, hat ein Glaubensproblem als Bereitschaftsergebnis getarnt.

Eine andere Umfrage zeigt das Gegenteil: Grant Thorntons Umfrage zur KI-Nachweislücke unter fast 1.000 Führungskräften Anfang 2026 ergab, dass 78 Prozent nicht voll überzeugt sind, ein unabhängiges KI-Governance-Audit binnen 90 Tagen zu bestehen. Nur jeder Fünfte hat einen Reaktionsplan für KI-Ausfälle getestet. Die Stichproben, Zeitpunkte und Fragen unterscheiden sich von der ersten Umfrage – die Zahlen sollten also nicht vermischt werden.

Was beide Umfragen gemeinsam haben, ist nützlicher als die Unterschiede: Führungskräfte sollen für eine Fähigkeit bürgen, die sie kurzfristig nicht nachweisen können. Die praktische Antwort: Den Nachweis schaffen – also einen aktuellen Agenten-Zugriffsverlauf und einen erprobten Reaktionsplan.

Schwellenwerte für menschliche Prüfung und benannte Verantwortung

Nicht jede Agentenaktion braucht menschliche Kontrolle – alles gleich zu behandeln, bremst die Arbeit oder führt zu blindem Abnicken. Setzen Sie Schwellenwerte nach Sensibilität und Aktionstyp. Das Lesen eines veröffentlichten Berichts braucht keine Freigabe, der Export eines Kundendatensatzes an externe Stellen schon. Dokumentieren Sie die Regeln, benennen Sie einen Verantwortlichen für jeden Agenten und testen Sie die Schwellenwerte mit jemandem außerhalb des Entwicklerteams. So erhält das Agentenverhalten überprüfbare Grenzen – und Ihre Prüfer erhalten konkrete Nachweise.

Jeder Agent braucht zudem einen benannten Verantwortlichen. Wenn ein Agent handelt, muss eine Person für den Zugriff und das Handeln verantwortlich sein – und im Vorfall auffindbar. Ein geteiltes Servicekonto macht die Untersuchung zum Ratespiel. Eine authentifizierte Identität, die auf die autorisierende Person verweist, macht daraus eine gezielte Recherche.

Auch Vorfälle brauchen einen Verantwortlichen. Legen Sie im Voraus fest, wer den Erstalarm gibt, wer Agentenberechtigungen entzieht und wer die Rechtsabteilung informiert. Behandeln Sie diese Antworten als kurzen, schriftlichen Incident-Response-Plan, der mindestens einmal geprobt wurde. Die Probe ist entscheidend, denn der häufigste Fehler ist nicht ein fehlender Plan, sondern ein Plan, den niemand getestet hat.

Durchsetzung auf der Datenschicht

Ein Agent, der nur eine Anweisung bekommt, einen Ordner zu meiden, ist auf Kooperation angewiesen. Ein Agent, der Inhalte nur über eine kontrollierte Datenschicht erreicht, ist auf Architektur angewiesen. Die Schicht authentifiziert die Anfrage, prüft die Richtlinie und dokumentiert das Ergebnis in einem Audit-Trail, den der Agent nicht verändern kann. Das Modell kann so clever argumentieren, wie es will – es stößt auf eine verschlossene Tür, und der Versuch wird protokolliert.

Kiteworks Compliant AI folgt diesem Ansatz. Es steuert KI-Zugriffe auf sensible Inhalte auf der Datenschicht – unabhängig vom Modell, Prompt oder Agenten-Framework. Jede Anfrage trägt eine OAuth-2.0-Identität, die mit dem autorisierenden Menschen verknüpft ist, durchläuft eine attributbasierte Richtlinienprüfung, wird verschlüsselt und in einen manipulationssicheren Audit-Trail geschrieben. Es funktioniert mit Claude, Copilot und anderen Modellen, die MCP unterstützen. Der Secure MCP Server ist die Integrationsschnittstelle.

Die entscheidende Designentscheidung ist Parität: Agenten und Mitarbeitende sollten gemeinsam gesteuert werden – mit einem Identitätsmodell, einer Richtlinie und einem Audit-Trail. Eine Anfrage, die einem Mitarbeitenden verweigert würde, sollte auch dem Agenten verweigert werden, der für ihn handelt. Richtlinien auf Basis von attribute-based access control sind dafür ideal, weil sie Attribute des Anfragenden, des Inhalts und des Kontexts prüfen – ohne separates Regelwerk für Software. Im Vergleich zu rein rollenbasierten Modellen lassen sich so Sensibilitäts- und Zweckbedingungen ausdrücken, die Agenten notwendig machen.

Vorfall-Uhren und die ersten 72 Stunden

Zeitdruck verändert, wie guter Nachweis aussieht. Stellen Sie sich vor, eine Aufsicht fragt Montagmorgen, was ein Agent im letzten Monat getan hat. Ein Team mit unabhängigem Nachweis filtert nach Identität, Zeitraum und Inhalt und liefert bis Mittag eine belastbare Antwort. Ein anderes Team rekonstruiert Aktivitäten aus Applikationsprotokollen – und die Antworten ändern sich ständig.

Die Vorbereitung ist weniger Technik- als Gewohnheitssache. Testen Sie, dass verweigerte Anfragen auch wirklich abgelehnt und protokolliert werden. Lassen Sie die Ergebnisse von jemandem außerhalb des Entwicklerteams prüfen, denn die Entwickler sehen oft das, was sie bauen wollten. Halten Sie die Nachweise nicht nur vor, sondern auch abrufbar unter Druck. Ein Nachweis, der existiert, aber drei Wochen zur Zusammenstellung braucht, erfüllt keine 72-Stunden-Anforderung.

Ein CISO-Dashboard, das Agentenaktivitäten, abgelehnte Anfragen und Richtlinienausnahmen an einem Ort zusammenführt, verkürzt den Weg von der Frage zur Antwort. Es gibt dem Vorstand zudem einen Überblick, der nicht von der Zusammenfassung eines Engineers abhängt. Ziel ist eine Berichtslinie von Nachweis zu Führungsebene, die kein einzelnes Team kontrolliert.

Souveränität und wohin Agenten-Anfragen gehen

Ruft ein Agent ein extern gehostetes Modell auf, verlässt Inhalt die eigene Umgebung. Für Unternehmen mit Datenresidenz-Anforderungen ist dieser Grenzübertritt ein Compliance-Ereignis – ob beabsichtigt oder nicht. Legen Sie im Voraus fest, wohin Inhalte gehen dürfen, und dokumentieren Sie jeden Übertritt, damit Sie Zusagen belegen können – nicht nur behaupten.

Das steht in direktem Zusammenhang mit Data Sovereignty-Erwartungen in der EU, dem Vereinigten Königreich und dem Golf, wo Aufsichtsbehörden sowohl auf den Standort als auch auf die Kontrolle der Daten achten. Kombinieren Sie das mit Datenminimierung: Ein Agent, der nur die für die Aufgabe nötigen Felder erhält, reduziert das Risiko – und der Zugriffsverlauf ist kürzer und leichter zu verteidigen.

Data Classification liefert die Labels, die diese Regeln durchsetzbar machen. Ist Inhalt nach Sensibilität gekennzeichnet, kann die Richtlinie entscheiden, was ein Agent lesen, zusammenfassen oder niemals exportieren darf. Ohne Labels wird jede Regel zur Einzelfallentscheidung des Agenten.

Ein 30-Tage-Plan für CISOs und Compliance-Verantwortliche

Starten Sie mit einer Bestandsaufnahme: Listen Sie alle Agenten und KI-Integrationen, die jeweiligen Repositorys und die genehmigende Person auf. Die meisten Unternehmen entdecken dabei Agenten, von denen das Security-Team nichts wusste – die Bestandsaufnahme ist der erste echte Befund jeder Governance-Initiative. Sie fließt in Ihr Governance, Risk and Compliance-Reporting ein und gibt Prüfern einen Ausgangspunkt.

Testen Sie anschließend die Kontrollen: Wählen Sie die fünf Agenten mit dem weitesten Zugriff, prüfen Sie, ob Anfragen außerhalb des Scopes abgelehnt werden und ob die Ablehnung in einem Audit-Trail erscheint, den der Agent nicht bearbeiten kann. Wenden Sie dann zero trust-Prinzipien für generative KI an – jede Anfrage gilt als nicht vertrauenswürdig, bis Identität, Richtlinie und Kontext geprüft sind. Die gleiche Logik gilt für den zero trust data exchange beim Austausch zwischen Menschen, Systemen und Agenten.

Schreiben Sie schließlich das Playbook, bevor Sie es brauchen: Dokumentieren Sie, wer Berechtigungen entzieht, wer die Aufsicht informiert, wer mit Kunden spricht und wie Nachweise zusammengestellt werden. Führen Sie mindestens eine Tabletop-Übung durch. Überarbeiten Sie das Playbook nach jeder Änderung im Agenten-Umfang – ein Playbook für die Agenten des letzten Quartals übersieht die von heute.

Was diese Berichterstattung nicht verrät

Eine faire Einordnung erfordert Ehrlichkeit über die Quellen. Die Perspektive, die diese Debatte prägt, ist eine Meinungsäußerung, und der Vorfall basiert auf Presseberichten. Ich habe weder den Originaltext des EU AI Act, noch die Gesetze von Kalifornien und New York oder OpenAIs eigenen Bericht gelesen – die rechtlichen Details stammen von Bello und sollten vor bindenden Entscheidungen mit Rechtsberatung geprüft werden. Auch die Angaben, wie viele Länder den Finnland-Norwegen-Vorstoß zur Kontrolle von Frontier-Modellen unterstützen, variieren – eine Quelle nennt 29, eine Regierungsmitteilung 20 plus die EU-Kommission.

Das schwächt das Kernargument nicht: Unabhängig von den finalen Regeln ist das Unternehmen, das nachweisen kann, wer worauf, unter welcher Richtlinie und mit welcher Autorisierung zugegriffen hat, besser aufgestellt als eines, das das nicht kann. Regierungen lernen, dass vertrauliche Briefings und gemeinsame Tests besser sind als Selbstberichte. Unternehmen können diese Lektion günstiger lernen – indem sie unabhängige Nachweise auf der Datenschicht verankern, bevor ein Agent aktiv wird.

Erfahren Sie mehr über die Steuerung von KI-Agenten auf der Datenschicht – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Zero‑Trust-Strategien für erschwinglichen 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
  Aufsichtsbehörden fragen nicht mehr, ob Sie eine KI-Richtlinie haben. Sie wollen den Nachweis, dass sie funktioniert.