Von der KI-Governance zur kontinuierlichen Absicherung: Compliance-Nachweise für agentische Systeme entwickeln

Richtlinien und jährliche Überprüfungen beschreiben die beabsichtigte Kontrolle. Agentic-Systeme benötigen eine zweite Ebene: den Nachweis, dass die relevante Kontrolle für die tatsächlich erfolgte Freigabe, Identität, Aktion und das Ergebnis auch durchgesetzt wurde.

Traditionelle Governance-Artefakte beantworten wichtige Fragen: Wer ist für den Anwendungsfall verantwortlich, welche Richtlinie gilt, welche Risikostufe wurde zugewiesen, welche Kontrollen wurden konzipiert und wer hat die Bereitstellung genehmigt? Agentic-Systeme werfen eine schwierigere Frage auf: Hat die relevante Kontrolle gegriffen, als diese Version unter dieser Identität und in diesem Kontext diese Aktion ausführte?

Die Antwort lässt sich nicht allein aus einem Richtliniendokument ableiten. Sie kann auch nicht aus einer riesigen Menge an Traces stammen. Absicherung erfordert eine Kette von Nachweisen, die die Verpflichtung mit einem Kontrollziel, einem Durchsetzungspunkt, gespeicherten Beweisen und einem Test verbindet, der zwischen Erfolg, Fehler, Ausnahme und Unbekannt unterscheiden kann.

Das ist die praktische Bedeutung von kontinuierlicher Absicherung. Es bedeutet nicht, dass jedes rechtliche Urteil automatisiert oder jedes Ereignis in Echtzeit geprüft wird. Es bedeutet, dass die Absicherung bei Systemänderungen aufrechterhalten wird, indem Beweise verwendet werden, die nah genug an der Ausführung liegen, um zu erkennen, wenn ein zuvor gültiger Anspruch nicht mehr zutrifft.

Beginnen Sie mit einem Absicherungsanspruch, nicht mit einem Dashboard

Abbildung 1 zeigt die Mindestkette. Eine Verpflichtung wird in eine Systemeigenschaft übersetzt; eine benannte Komponente setzt diese Eigenschaft durch; Aufzeichnungen belegen die getroffene Entscheidung; und ein Test bewertet die Aufzeichnungen anhand expliziter Kriterien. Fehlt ein Glied, kann ein Dashboard zwar Aktivität anzeigen, ohne jedoch zu beweisen, dass die beabsichtigte Kontrolle auch angewendet wurde.

Betrachten Sie die Anforderung: „Ein Mensch muss Rückerstattungen mit hohem Wert genehmigen.“ Dies ist zu vage für einen Test. Ein Kontrollziel könnte lauten: Bevor eine Rückerstattung oberhalb eines definierten Schwellenwerts eingereicht wird, muss ein berechtigter Prüfer den normalisierten Vorgang einmalig genehmigen; die Genehmigung verfällt nach fünfzehn Minuten oder nach einer wesentlichen Änderung an Kunde, Bestellung, Betrag, Währung oder Ziel; das Zahlungssystem muss die Rückerstattung weiterhin autorisieren und ausführen.

Nun sind die Durchsetzungspunkte identifizierbar. Die Anwendung klassifiziert Wert- und Materialfelder. Ein Gateway oder eine Laufzeitumgebung hält den Tool-Aufruf fest. Das Identitätssystem bestimmt die Berechtigung des Prüfers. Die Handelsplattform wendet die Rückerstattungsrichtlinie an und führt den Vorgang aus. Die Beweise umfassen Richtlinienversion, Anforderer und Agent, Digest des normalisierten Vorgangs, Genehmigung, Zeitstempel, Vorgangskennung, Tool-Ergebnis und abgeglichenen Rückerstattungsdatensatz.

Der Absicherungstest kann mehr als nur „bestanden“ oder „nicht bestanden“ melden. „Unbekannt“ ist kritisch: Fehlende Korrelation, unterdrückte Beweise, Zeitabweichungen oder ein unbemerktes Umgehen der Kontrolle sollten nicht als Erfolg gewertet werden. Ausnahmen sollten benennen, wer sie akzeptiert hat, warum, für welchen Bereich und bis wann. Dies macht das Kontrolldesign zu einem operativen Vertrag.

Trennen Sie Kontrolldesign von der Kontrollausführung

Designnachweise zeigen, dass eine Kontrolle existiert: Architektur, Konfiguration, Richtlinie, Prüfprotokoll, Testplan und Verantwortlicher. Betriebsnachweise zeigen, dass die Kontrolle auf relevante Ausführungen angewendet wurde. Beides ist wichtig. Ein perfekt konfiguriertes Gateway deckt keinen Datenverkehr ab, der es umgeht. Ein Laufzeitereignis beweist nicht, dass die bereitgestellte Richtlinie die geprüfte Version war. Eine nachgelagerte Transaktion kann ein Ergebnis belegen, ohne zu erklären, welcher Agent oder welche Genehmigung dazu geführt hat.

Erstellen Sie ein Abdeckungsmodell. Erfassen Sie alle relevanten Agenten, Umgebungen, Modellrouten, MCP-Server, direkten API-Pfade, Anmeldedaten und Datensysteme. Identifizieren Sie für jede Kontrolle die Durchsetzungspopulation und die Beweispopulation. Testen Sie dann auf Lücken zwischen erwartetem und beobachtetem Datenverkehr. Kontinuierliche Absicherung, die Umgehungspfade ignoriert, kann zu kontinuierlichem falschem Vertrauen führen.

Kontrollverantwortliche sollten die Häufigkeit anhand von Risiko und Beweislatenz definieren. Einige Ansprüche können bei jeder Anfrage bewertet werden: War eine Identität vorhanden, war ein Tool erlaubt, lief ein Leitplanken-Check, existierte eine Genehmigung? Andere erfordern periodische Stichproben oder Batch-Abgleiche: Wurden Ergebnisse abgeglichen, wurde die Aufbewahrung durchgeführt, blieb der Zugriff angemessen oder blieb eine Fairness-Metrik auf Populationsebene innerhalb eines genehmigten Bereichs? „Kontinuierlich“ beschreibt die aufrechterhaltene Verknüpfung und rechtzeitige Erkennung, nicht notwendigerweise die millisekundengenaue Bewertung jeder Verpflichtung.

Erstellen Sie ein geschichtetes Beweismodell

Abbildung 2 unterteilt Nachweise in Konfigurations-, Laufzeit- und Ergebnisebenen. Die Konfiguration erläutert, was zum jeweiligen Zeitpunkt beabsichtigt und wirksam war. Die Laufzeit erklärt, was der Agent und die Steuerungsebene beobachtet haben. Ergebnisnachweise verdeutlichen, was autoritative Systeme tatsächlich ausgeführt haben und wen dies betraf. Korrelationskennungen, Zeitstempel für die Gültigkeit und synchronisierte Uhren verknüpfen diese Ebenen; keine kann die andere ersetzen. Wo die Integrität von Nachweisen entscheidend ist, müssen Export, Zugriffskontrolle, Aufbewahrung und Manipulationssicherheit explizit konzipiert werden, anstatt sie lediglich aus der Existenz einer Protokollspur abzuleiten.

Konfigurationsnachweise umfassen Agenten- und Workflow-Releases, Modellberechtigungen, Überarbeitungen von Prompts und Fähigkeiten, Tool-Schemata, Identitätsvergaben, Genehmigungsrichtlinien, Leitplanken-Richtlinien, Protokollierungsregeln und die Umgebung. Die Semantik des Gültigkeitszeitpunkts ist dabei entscheidend. Ein Prüfer, der einen Vorgang vom August untersucht, benötigt die Richtlinien und Berechtigungen, die zu diesem Zeitpunkt galten, nicht die heute sichtbaren Einstellungen.

Laufzeitnachweise umfassen Sitzungs- und Vorgangskennungen, Akteur und Subjekt, das ausgewählte Modell, Metadaten zu Token und Latenz, die Tool-Absicht, normalisierte Argumente oder geschützte Digests, Ergebnisse von Autorisierungen und Leitplanken, den Genehmigungsstatus, Wiederholungs- und Abbruchereignisse sowie den Abschlussstatus. Dabei sollte zwischen vorgeschlagen, versucht, bestätigt, abgelehnt und fehlgeschlagen unterschieden werden. Eine Modellaussage, dass eine Rückerstattung veranlasst wird, ist kein Tool-Versuch; eine Tool-Antwort ist nicht zwangsläufig eine verbindliche Rückerstattung.

Ergebnisnachweise liegen in autoritativen Systemen: die Rückerstattungstransaktion, die geänderte Zugriffsberechtigung, die gesendete Benachrichtigung, der erstellte Support-Fall, das bereitgestellte Artefakt oder der Datensatz zu Auswirkungen auf Kunden. Ein Abgleich verknüpft die Vorgangskennung mit diesem Status. Diese Ebene ist für Effektivitätstests unerlässlich, da eine Kontrolle exakt wie geplant funktionieren kann, während das geschäftliche Ergebnis dennoch ausbleibt – oder ein unbeobachteter Pfad zu einem Ergebnis führen kann, ohne dass entsprechende Laufzeitnachweise vorliegen.

Nachweise minimieren, ohne die Überprüfbarkeit zu gefährden

Compliance-Programme reagieren auf Unsicherheit oft damit, alles zu speichern. Bei agentenbasierten Systemen kann dies ein zweites Risiko schaffen: Prompts, Tool-Nutzlasten, abgerufene Dokumente und Modellantworten können personenbezogene Daten, Anmeldeinformationen, vertrauliche Kommunikation, Quellcode oder regulierte Datensätze enthalten. Das Design von Nachweisen sollte mit dem Anspruch beginnen und nur die Felder beibehalten, die für dessen Überprüfung zwingend erforderlich sind.

Verwenden Sie strukturierte Metadaten für Identität, Release, Modell, Tool, Richtlinie, Entscheidung und Korrelation. Speichern Sie normalisierte Feld-Digests, wenn Prüfer nachweisen müssen, dass eine Genehmigung mit einer Aktion übereinstimmte, ohne die vollständige Nutzlast in der zentralen Protokollspur zu speichern. Bewahren Sie sensible Inhalte nur dort auf, wo es der Zweck erfordert, unter Berücksichtigung von Schwärzung, strengem Zugriffsschutz, Aufbewahrungsfristen und Löschung. Pflegen Sie Zuordnungen zum autoritativen Datensatz, anstatt jedes Geschäftsobjekt in den KI-Observability-Speicher zu kopieren.

Die dokumentierte Protokollierungskonfiguration von TrueFoundry ist ein nützliches Beispiel für diese Unterscheidung. Regeln bestimmen, ob Anforderungs- und Antwortkörper gespeichert werden und welche sensiblen Muster in der gespeicherten Kopie geschwärzt werden. Kosten, Token, Latenz und Metadaten bleiben aufgezeichnet. Dies kann ein datenschutzbewusstes Design von Nachweisen unterstützen, doch die Organisation entscheidet weiterhin über den rechtmäßigen Zweck, die Aufbewahrung, den Zugriff, die Lokalisierung und darüber, ob vordefinierte oder benutzerdefinierte Muster für ihre Daten ausreichen.

Telemetrie nicht mit einem Compliance-Urteil gleichsetzen

Protokollspuren sind die Grundlage für Nachweise. Sie sind weder ein Evaluator, ein Kontrolltest noch ein rechtliches Urteil. Ein Assurance-Service benötigt explizite Logik für diese Datensätze: Definition der Grundgesamtheit, erwartete Ereignisse, zulässige Sequenzen, Zeitvorgaben, Ausnahmen, Ergebnisabgleiche und den Umgang mit fehlenden Daten.

Verwenden Sie für Verhaltenskontrollen Offline-Regressionssets und Trajektorienprüfungen gegen versionierte Releases. Bewerten Sie für Betriebskontrollen Produktionsereignisse und Ergebnisse. Definieren Sie für statistische Verpflichtungen Nenner, Kohorten, Konfidenz, Wesentlichkeit und Eskalationsstufen. Ein einzelner „Compliance-Score“ neigt dazu, zu verschleiern, welcher Anspruch fehlgeschlagen ist und ob der Nachweis fehlte oder negativ ausfiel.

Halten Sie rechtliche Auslegung und technische Testlogik miteinander verbunden, aber getrennt. Rechtsabteilungen oder Compliance-Verantwortliche bestimmen, welche Verpflichtungen gelten, und genehmigen das Kontrollziel. Die Technik implementiert die Durchsetzung und die Nachweise. Interne Revision oder Assurance-Funktionen bewerten, ob Design und Betrieb den Anspruch stützen. Ein Gateway-Anbieter sollte einen Kunden nicht allein deshalb für compliant erklären, weil eine Funktion aktiviert ist.

Assurance durch Änderungen auslösen

Abbildung 3 schließt den Kreislauf. Änderungen an Release, Modell, Tool, Identität, Richtlinie und regulatorischen Vorgaben können vor oder während der Einführung eine gezielte Neubewertung auslösen. Produktionsverhalten und abgeglichene Ergebnisse können danach eine Eindämmung oder Rezertifizierung nach sich ziehen. Eine vorherige Genehmigung bleibt nur so lange gültig, wie ihre Annahmen, ihr Umfang und ihre Nachweise Bestand haben.

Kalenderbasierte Überprüfungen sind weiterhin nützlich, aber wesentliche Ereignisse sollten nicht auf diese warten. Ein neues Tool ändert die Befugnisse. Ein Update der Modell-Route kann das Verhalten ändern, ohne den Anwendungscode anzupassen. Eine Überarbeitung von Fähigkeiten kann das Verfahren ändern. Eine Zuordnung im Identitätsanbieter kann ändern, wer Zugriff erhält. Eine Änderung der Protokollierungsrichtlinie kann Nachweise entfernen. Eine neue regulatorische Auslegung kann das Kontrollziel ändern, selbst wenn das System unverändert bleibt.

Klassifizieren Sie Änderungen nach den Ansprüchen, die sie gefährden. Änderungen an Prompts oder Modellen lösen Verhaltens- und Trajektorienbewertungen aus. Änderungen an Tools und Sandboxes erfordern zusätzliche Kapazitäts-, Abhängigkeits- und Eindämmungstests. Identitäts- und Richtlinienänderungen lösen Autorisierungs- und Negativ-Zugriffstests aus. Protokollierungsänderungen lösen Tests auf Vollständigkeit der Nachweise und Datenschutz aus. Änderungen an nachgelagerten Schemata lösen Abgleichs- und Nachbedingungstests aus.

Nutzen Sie für wesentliche Änderungen gestaffelte Rollouts, begrenzte Zielgruppen, Überwachung und Rollback-Optionen. Ein Rollback ist nicht immer eine Wiederherstellung: Wenn ein Agent bereits externe Auswirkungen verursacht hat, muss die Organisation möglicherweise kompensierende Maßnahmen ergreifen. Die Assurance sollte daher Nachweise zur Eindämmung und Wiederherstellung enthalten, nicht nur zur Release-Freigabe.

Transparenzpflichten sorgfältig auf die Architektur abbilden

Die Europäische Kommission hat festgelegt, dass ab dem 2. August 2026 bestimmte interaktive KI-Systeme Nutzer darüber informieren müssen, dass sie mit einer KI interagieren. Zudem unterliegen bestimmte KI-generierte oder manipulierte Inhalte entsprechenden Kennzeichnungs- oder maschinenlesbaren Markierungspflichten. Die genaue Verpflichtung hängt von der Rolle, dem System, dem Inhalt, Ausnahmen und den jeweiligen Durchführungsrichtlinien ab. Die Technik sollte die geltenden rechtlichen Anforderungen in prüfbare Kriterien übersetzen, anstatt lediglich ein allgemeines „KI-Offenlegung aktiviert“-Kontrollkästchen in jeden Arbeitsablauf zu integrieren.

Für einen interaktiven Agenten könnte ein prüfbares Kriterium den Offenlegungstext, den Kanal, den Zeitpunkt, die Sprache, die Beständigkeit bei Übergaben sowie den Nachweis der Anzeige umfassen. Bei generierten Inhalten kann sich das Kriterium darauf beziehen, welche Ausgabeklassen eine Kennzeichnung erfordern, wo diese angebracht wird, ob Transformationen sie erhalten und welche Ausnahmen gelten. Eine Agenten-Laufzeitumgebung kann protokollieren, dass sie Offenlegungs-Metadaten erstellt hat; der Übermittlungskanal oder die Inhaltsplattform muss jedoch nachweisen, dass die Nutzer diese tatsächlich erhalten oder gespeichert haben.

Dies verdeutlicht das zentrale Muster: Verpflichtungen überschreiten Systemgrenzen. Das Modell, das Gateway, die Laufzeitumgebung, die Anwendung, die Benutzeroberfläche und das Aufzeichnungssystem halten jeweils einen Teil der Nachweise. Kontinuierliche Absicherung ist die disziplinierte Zusammenführung dieser Teile, nicht die Behauptung, dass eine einzelne Plattform die alleinige rechtliche Verantwortung trägt.

Die Rolle von TrueFoundry und TrueForge

Eine Implementierung kann jede Anfrage mit Identifikatoren für Anwendungsfall, Umgebung, Release, Kontrollset und Vorgang versehen, Modell- und MCP-Datenverkehr über die vorgesehenen Kontrollebenen leiten, TrueForge-Ereignissequenzen bewahren und die relevanten Metadaten exportieren. Ein separater Absicherungsprozess bewertet dann die erwarteten Kontrollen, führt maßgebliche Ergebnisse zusammen und öffnet Ausnahmefälle. Diese Aufteilung hält die Durchsetzung nah am Datenverkehr, während die Compliance-Bewertung explizit und überprüfbar bleibt.

Praxisbeispiel: Rückerstattungen im Kundensupport

Ein Kundensupport-Agent kann Fragen zu Bestellungen beantworten und Rückerstattungen vorschlagen. Rückerstattungen unter einem niedrigen Schwellenwert können bei berechtigten Bestellungen automatisch ausgeführt werden; größere oder ungewöhnliche Rückerstattungen erfordern eine menschliche Genehmigung. Das Unternehmen muss zudem eine KI-Offenlegung im Chat-Kanal bereitstellen und vermeiden, unnötige Zahlungs- oder Identitätsdaten in Beobachtungssystemen zu speichern.

Das Kontrollset legt den Agenten, den Prompt und die Skill-Version fest, definiert zulässige Modelle und Tools, schreibt vor, dass der Kanal die Offenlegung vor der ersten Antwort des Agenten anzeigt, begrenzt das Rückerstattungstool nach Identität und wendet eine einmalige Genehmigung für hochwertige Anfragen an. Protokollierungsregeln unterdrücken oder schwärzen sensible Inhalte, während Identifikatoren und Entscheidungs-Metadaten erhalten bleiben. Der Commerce-Dienst bewertet unabhängig die Rückerstattungsberechtigung und unterstützt einen idempotenten Vorgangsidentifikator.

Die Laufzeitabsicherung prüft jede Rückerstattung auf authentifiziertes Subjekt und Agenten, erwartete Richtlinienversion, Autorisierungsergebnis, erforderliche Genehmigung, Vorgangsidentifikator und Abschlussereignis. Ein geplanter Abgleich vergleicht erfolgreiche Tool-Aufrufe mit Commerce-Transaktionen und markiert sowohl verwaiste Tool-Erfolge als auch Transaktionen ohne gesteuerten Laufzeitpfad. Ein Test auf Kanalebene stichprobt Sitzungen, um zu verifizieren, dass die Offenlegung tatsächlich angezeigt wurde und nicht nur, dass der Agent Offenlegungs-Metadaten ausgegeben hat.

Wenn sich der Rückerstattungsschwellenwert ändert, werden der Genehmigungskontrolltest und die betroffenen Szenarien erneut ausgeführt. Wenn sich eine Modellroute ändert, werden Verhaltensregression und Trajektorientests wiederholt. Wenn sich der Chat-Client ändert, wird die Anzeige der Offenlegung neu zertifiziert. Wenn eine Korrelationslücke auftritt, meldet das System „unbekannt“, öffnet eine Ausnahme und untersucht den Vorfall, anstatt fehlende Nachweise als regelkonformes Verhalten zu behandeln.

Erstellung eines Audit-Pakets zur Beantwortung eines Kriteriums

Ein nützliches Audit-Paket ist auf Kriterien ausgerichtet. Es umfasst Umfang und Population, Quelle der Verpflichtung, genehmigtes Kontrollziel, Verantwortliche, Architektur, relevante Release- und Richtlinienversionen, Durchsetzungspunkte, Nachweisschema, Testmethode, Periodenergebnisse, Ausnahmen, Abhilfemaßnahmen und bekannte Einschränkungen. Stichproben verweisen über Korrelationsidentifikatoren auf geschützte zugrunde liegende Datensätze, sofern autorisiert.

Es sollte auch angeben, was durch die Nachweise nicht belegt werden kann. Zum Beispiel: Gateway-Protokolle decken gerouteten Datenverkehr ab, aber keine direkten Anbieteraufrufe; Laufzeitereignisse protokollieren eine Tool-Antwort, aber das Commerce-Hauptbuch belegt die Verbindlichkeit; die Unterdrückung von Inhalten begrenzt die Rekonstruktion; Fairness-Analysen werden in einem separaten Ergebnisdatensatz durchgeführt; die rechtliche Anwendbarkeit wurde vom Unternehmen bestimmt, nicht von der Plattform.

Diese Transparenz verbessert die Absicherung. Ein eng gefasstes, belegtes Kriterium ist verteidigbarer als ein umfassendes Dashboard-Label, das fehlende Abdeckung verschleiert.

Kontinuierliche Absicherung bedeutet gepflegte Nachweise, nicht kontinuierliche Gewissheit

Agentische Systeme ändern sich zu häufig, überschreiten zu viele Grenzen und treffen zu viele Laufzeitentscheidungen, als dass eine periodische Dokumentation die gesamte Governance-Last tragen könnte. Die Lösung ist jedoch nicht eine universelle Überwachung oder ein automatisiertes Rechtsurteil.

Das bessere Design ist eine gepflegte Kette: anwendbare Verpflichtung, genehmigtes Kontrollziel, benannter Durchsetzungspunkt, datenschutzkonformer Nachweis, expliziter Test, verantwortliche Ausnahme und maßgebliches Ergebnis. TrueFoundry und TrueForge können wichtige Kontroll- und Telemetrieoberflächen über Modelle, Tools, Identitäten, Genehmigungen und den Laufzeitzustand hinweg bereitstellen. Die Organisationen bleiben weiterhin verantwortlich für die Abdeckung, Unternehmensrichtlinien, Bewertung, rechtliche Interpretation und das abschließende Absicherungsergebnis.

Diese Aufgabenteilung ist keine Einschränkung, die es zu verbergen gilt. Sie ist das, was das System prüfbar macht. Die Infrastruktur sollte zuverlässige, begrenzte Nachweise liefern; die Absicherung sollte genau definieren, was diese Nachweise belegen.

Referenzen

1. IBM — Von der KI-Governance zur KI-Absicherung: Was wir auf der Think 2026 geteilt haben.
2. Europäische Kommission – Durchsetzungs- und Transparenzanforderungen ab dem 2. August 2026.
3. Europäische Kommission – Überblick zur KI-Verordnung.
4. OWASP – Top 10 für agentische Anwendungen 2026.
5. TrueFoundry – Protokollierungskonfiguration.
6. TrueFoundry – MCP-Gateway.
7. TrueFoundry – MCP-Tool-Freigaben.
8. TrueFoundry – Agenten-Registry.
9. TrueForge – SDK-Konzepte.

Redaktioneller Hinweis. Dieser Artikel spiegelt die technische Interpretation der zitierten öffentlichen Materialien durch TrueFoundry zum Stand vom 13. September 2026 wider. Der Funktionsumfang der Produkte beschränkt sich auf die verlinkte Dokumentation. Die Beispiele dienen der Veranschaulichung und stellen keine Rechtsberatung, kein Prüfungsgutachten, keinen unabhängigen Benchmark und keine Garantie für Compliance oder Sicherheit dar.

‍