Maetra empfiehlt, dass Betreiber wesentlicher Dienste im Vereinigten Königreich testen, ob sie Nachweise für einen erfolglosen Versuch sichern können, einen KI-Agenten zu stoppen. Das neue Faktenblatt der Regierung zur Resilienz agentischer KI, veröffentlicht am 3. November, beschreibt vorgeschlagene künftige Maßnahmen zu Sicherheit, Meldungen, Beweissicherung und Vorfallsprüfungen. Es begründet diese agentenspezifischen Pflichten heute noch nicht. Für Compliance-Teams ist eine Übung sinnvoll, die eine beobachtete Handlung mit dem Eingriff des Betreibers und dem danach folgenden Verhalten verknüpft.
Das offizielle Grundsatzpapier erklärt, dass genauer Anwendungsbereich und Definitionen gemeinsam mit der Branche und den Aufsichtsbehörden entwickelt werden. Im Mittelpunkt steht der Verlust der Überwachung oder Kontrolle über Agenten in Netz- und Informationssystemen. Teams sollten diesen sich entwickelnden Anwendungsbereich zusammen mit ihren bestehenden Regelungen für Vorfälle verfolgen.
Was die Regierung vorgeschlagen hat
Das Faktenblatt stellt vier Maßnahmen in Aussicht: technische und organisatorische Resilienzanforderungen, die Benachrichtigung anderer betroffener Organisationen, die Sicherung relevanter Vorfallsinformationen und ministerielle Befugnisse zur Beauftragung technischer Überprüfungen. Die Umsetzung würde nach der königlichen Zustimmung durch nachrangige Rechtsvorschriften erfolgen, einschließlich Konsultation und parlamentarischem Zustimmungsverfahren. Das Papier begrenzt seinen Anspruch ausdrücklich auf agentischen Kontrollverlust und nicht auf ein umfassendes Regelwerk für sämtliche KI-Schäden.
Diese Unterscheidung prägt die Compliance-Arbeit. Ein interner Eintrag sollte den Vorschlag, den potenziell betroffenen Dienst und eine für die Beobachtung der Entwicklungen verantwortliche Person benennen. Offene Fragen zur Anwendbarkeit und zu Umsetzungsfristen sollten dabei sichtbar bleiben. Wenn ein Vorschlag als bereits umgesetzte Pflicht erfasst wird, entsteht eine trügerische Sicherheit, und technische Arbeit kann auf eine Anforderung ausgerichtet werden, deren Anwendungsbereich noch entwickelt wird.
Maetras Analyse ist, dass Organisationen nützliche operative Nachweise vorbereiten können, während diese Fragen noch offen sind. Die vorgeschlagene Richtung zur Beweissicherung macht eine eng umrissene Übung sinnvoll: Sie sollte zeigen, was geschah, als ein Betreiber versuchte, die Kontrolle zurückzugewinnen. Die nachfolgend beschriebene Übung ist eine Vorbereitungsmethode, keine Checkliste der Regierung und keine Aussage über die rechtlichen Pflichten irgendeiner Organisation.
Nicht nur die Agentenhandlung, sondern auch den Eingriff sichern
Ein Nachweis, der bei einer Warnmeldung endet, kann nicht erklären, ob die Eindämmung funktioniert hat. Auch ein Befehl zum Stoppen eines Workflows reicht für sich genommen nicht aus. Ermittler müssen zwischen der Anforderung, ihrer Bestätigung und dem danach beobachtbaren Verhalten unterscheiden können.
Betrachten Sie einen hypothetischen Agenten für das Service-Management, der beginnt, Datensätze außerhalb des ihm zugewiesenen Dienstes zu ändern. Ein Betreiber pausiert dessen Scheduler, ein bereits laufender Agentenprozess nutzt jedoch weiter einen Konnektor. Ein Logeintrag mit „Agent pausiert“ würde diese Lücke verdecken. Ein besserer Nachweis würde zeigen, welcher Scheduler pausiert wurde, welcher Prozess aktiv blieb, welchen Zugriff er behielt und wann sein letzter externer Vorgang abgeschlossen wurde.
Auch das Beispiel im Faktenblatt selbst umfasst Angaben zu Handlungen von Agenten und zu Versuchen, sie zu kontrollieren. Teams sollten festlegen, welche verlässlichen Nachweise ihre Systeme tatsächlich erzeugen können. Sie sollten vermeiden, vermutete interne Überlegungen zur Voraussetzung für die Rekonstruktion zu machen. Aufrufe von Werkzeugen, Autorisierungsentscheidungen, Antworten von Konnektoren und beobachtete Systemänderungen können eine Untersuchung stützen, auch wenn die internen Schlussfolgerungen eines Modells nicht verfügbar sind.
Einen Eingriff zur Kontrolle des Agenten erproben
Wählen Sie in einer sicheren Testumgebung einen klar abgegrenzten Workflow aus und legen Sie vor dem Start das erwartete Ergebnis der Eindämmung fest. Benennen Sie für die Übung eine technisch verantwortliche Person und eine verantwortliche Person für Compliance-Nachweise. Die technisch verantwortliche Person legt fest, was die Kontrollen tun. Die für die Nachweise zuständige Person prüft, ob das Ergebnis auch für Dritte nachvollziehbar ist.
| Aufzubewahrender Nachweis | Frage, die damit beantwortet werden soll |
|---|---|
| Workflow-, Prozess- und Konnektor-Kennungen | Welche Teile des Systems konnten noch handeln? |
| Zeitstempel für Warnung und Eingriff | Wann erfuhr der Betreiber von dem Problem, und wann reagierte er? |
| Genaue Anweisung und Empfangsbestätigung | Was wurde angefordert, und welche Komponente hat dies angenommen? |
| Ergebnisse der nachfolgenden Handlungen | Wurde die Aktivität gestoppt, schlug sie fehl oder lief sie anderswo weiter? |
| Speicherort der Nachweise und Zugriffsprotokoll | Wer kann die Nachweise abrufen, ohne sie zu verändern? |
Verwenden Sie eine harmlose, rückgängig zu machende Testhandlung mit bekanntem Ziel. Wenn ein Prozess nach einer Pause weiterläuft, sichern Sie dieses Ergebnis als Feststellung. Kennzeichnen Sie die Übung nicht allein deshalb als erfolgreich, weil sich der Status im Dashboard geändert hat. Vereinbaren Sie eine Korrektur, weisen Sie eine verantwortliche Person zu und wiederholen Sie den Test nach der Änderung.
Auch die Aufbewahrung erfordert eine eigene Entscheidung. Sichern Sie die Informationen, die zum Verständnis des Vorfalls erforderlich sind, beschränken Sie den Zugriff und wenden Sie einschlägige Datenschutz- und Aufbewahrungsregeln an. Das Kopieren jedes Prompts, jeder Datei und aller Zugangsdaten in einen Vorfallsordner kann ein eigenständiges Risiko schaffen. Verweisen Sie, wo angemessen, auf geschützte Originale und dokumentieren Sie bewusste Schwärzungen, damit Prüfende erkennen, was fehlt.
Entscheidungen zu betroffenen Organisationen nachvollziehbar halten
Der Vorschlag blickt außerdem über die Benachrichtigung von Kunden hinaus auf andere Organisationen, die ein Agent beeinträchtigen könnte. Zur Vorbereitung kann die verantwortliche Person für einen Dienst die Ziele von Konnektoren einem operativen Kontakt zuordnen und festhalten, wer entscheiden würde, ob eine Benachrichtigung erforderlich ist. Welche Benachrichtigungspflichten und Schwellenwerte tatsächlich gelten, muss nach den zum jeweiligen Zeitpunkt anwendbaren Regeln bewertet werden.
Testen Sie während des Probelaufs, ob das Team aus den eigenen Aufzeichnungen ein betroffenes externes System identifizieren kann. Dokumentieren Sie Unsicherheiten, wenn ein gemeinsam genutzter Konnektor das Ziel oder die verwendete Identität verdeckt. Eine Kontaktliste ist nur dann nützlich, wenn das Team sie mit dem untersuchten Vorgang verknüpfen kann.
Dies knüpft an die Verantwortungsfragen in Maetras NIST-Analyse zu Nachweisen von Agentenidentitäten an. Die konkrete Frage hier lautet, ob Nachweise einen versuchten Eingriff überdauern und eine spätere Überprüfung stützen. Comply unterstützt Framework-Mapping, Regulierungsbeobachtung und Nachweisverwaltung. Audit unterstützt eine prüfbare Historie. Keines von beiden ersetzt die technische Vorfallbearbeitung oder entscheidet über die rechtliche Anwendbarkeit.
Für die nächste Compliance-Prüfung können Sie Maetras Framework-Abdeckung nutzen, um eine bestehende Kontrolle mit der für ihren Nachweis verantwortlichen Person und dem jüngsten Ergebnis des Probelaufs zu verknüpfen. Halten Sie den Status des britischen Vorschlags getrennt, bis durch Konsultation und Umsetzung feststeht, welche Anforderungen gelten.
Quellen
- Regierung des Vereinigten Königreichs, Agentic AI resilience measures, 3. November 2026. Primäres Grundsatzpapier. Der vorstehende operative Probelauf ist Maetra-Analyse.