Compliance als ausführbare Policy
Die meisten Organisationen behandeln Compliance als Dokument. Eine Policy wird geschrieben, geprüft, unterschrieben und abgelegt. Das System wird getrennt gebaut, und irgendwo dazwischen bestätigt ein Control-Owner, dass beides übereinstimmt. Für deterministische Software, die nach einem Release-Plan aktualisiert wird, funktioniert das meistens.
Nur liest ein Agent Ihr Policy-PDF nicht und hält für Ihr Quartals-Control-Review nicht an. Er handelt auf lebendem Kontext, probabilistisch, potenziell tausendfach am Tag, und er kann sich nach einem nächtlichen Modell-Update anders verhalten, für das niemand einen Change Request gestellt hat. Ein Compliance-Regime, das in einem Dokument neben dem System lebt, kann ein System dieser Geschwindigkeit nicht governen. Die Pflicht muss im System laufen, sonst läuft sie gar nicht.
Das ist die Verschiebung, die EU AI Act, DORA und DSGVO regulierten Unternehmen still aufzwingen: Compliance hört auf, ein PDF zu sein, und wird Code, der ausgeführt wird, Verdikte ausgibt, denen der Workflow folgen muss, und Nachweise hinterlässt, die eine Aufsicht rekonstruieren kann.
Policy ist Code, der Ihrem Compliance-Team gehört
Der Instinkt der Entwickler ist, Compliance-Logik in den Code des Agenten zu packen. Das ist der falsche Eigentümer. Die gegenüber der Aufsicht verantwortlichen Personen sind Ihr Compliance-Team, also müssen ihm die Regeln gehören, und es muss das belegen können.
In der Praxis heißt das Policy-as-Code: ein Policy-Entscheidungspunkt, eine OPA- oder Rego-Engine, die Ihr Compliance-Team versioniert, testet, kryptografisch signiert und vor dem Deployment freigibt. Mechanismus und Entscheidung sind sauber getrennt. Die Entwickler bauen die Maschinerie, die die Policy-Engine fragt "darf das weitergehen?". Dem Compliance-Team gehören die Regeln, die antworten. Keiner kann den anderen still überstimmen, und die Trennung ist selbst prüfbar.
Die Dividende: Eine Compliance-Regel ist jetzt ein testbares, versioniertes Artefakt mit Signatur und Eigentümer, keine Auslegung im Kopf einer Person oder vergraben im Anwendungscode. Fragt eine Aufsicht "wer hat entschieden, dass das erlaubt ist, und wann?", ist die Antwort eine signierte Policy-Version, kein Meeting ohne Protokoll.
Policies verfallen auch per Laufzeit. Jede Regel muss planmäßig geprüft, neu freigegeben und neu signiert werden, was Veraltung sichtbar und governbar macht statt still. Eine Regel, die leise aus der Relevanz gealtert ist, hört auf, unsichtbares Risiko zu sein, und wird ein markierter Punkt, den jemand erneut unterschreiben muss.
Jedes Gate löst sich in eines von vier Verdikten auf
Damit der Workflow der Policy folgt, muss die Policy in Verdikten sprechen, auf die der Workflow reagieren kann. Jedes Compliance-Gate löst sich in eines von vier auf.
- ALLOW. Alle Bedingungen erfüllt. Der Agent fährt ohne menschliches Eingreifen fort.
- ALLOW-WITH-CONDITIONS. Teilweise erfüllt. Der Agent fährt unter dokumentierten Auflagen fort, etwa zusätzlichem Logging, einer Scope-Grenze oder einem Review-Flag.
- DENY. Eine harte Bedingung scheitert. Die Transaktion wird blockiert, ohne Ausnahmepfad.
- REQUIRE-HUMAN. Die Entscheidung trägt regulatorisches Gewicht, das nicht delegierbar ist. Der Agent analysiert nur; ein Mensch entscheidet.
Die vier Verdikte verwandeln "das System ist compliant" von einer Zusicherung in einen Mechanismus. Eine Zusicherung lässt sich nicht testen. Ein Verdikt schon: Sie können auf jede Transaktion zeigen und sehen, welches Verdikt feuerte, unter welcher Policy-Version und warum.
REQUIRE-HUMAN ist das tragende Verdikt für regulierte Arbeit
Von den vieren trägt eines das Gewicht des regulierten Anwendungsfalls, und es lohnt, es direkt mit dem Gesetz zu verbinden.
Nach DSGVO Artikel 22 hat eine Person das Recht, keiner ausschließlich auf automatisierter Verarbeitung beruhenden Entscheidung unterworfen zu werden, die rechtliche oder ähnlich erhebliche Wirkung entfaltet. Die Kreditentscheidung, die Schadenablehnung, die Compliance-Freigabe: Diese lassen sich nicht vollständig an eine Maschine delegieren. In dieser Architektur lösen sie sich per Policy zu REQUIRE-HUMAN auf. Der Agent bereitet vor, prüft und orchestriert. Die regulierte Entscheidung bleibt bei einer Person.
Das liest sich leicht als Einschränkung, die man einem Juristen zuliebe angeschraubt hat. Es ist das Gegenteil. Es ist der Entwurf, der das ganze System rechtmäßig macht. Ein Agent, der die folgenschwere Entscheidung selbst träfe, wäre schneller und illegal. Ein Agent, der die gesamte Arbeit bis zur Entscheidung erledigt und einem Menschen eine vollständige, belegte Akte übergibt, ist schnell und rechtmäßig. REQUIRE-HUMAN ist nicht die Schwäche des Agenten. Es ist die Grenze, die Autonomie überall sonst verteidigbar macht.
Kein Nachweis, keine Entscheidung
Eine laufende Policy ist nur die halbe Pflicht. Die andere Hälfte ist, im Nachhinein zu belegen, was geschah. Nach den Aufzeichnungspflichten des EU AI Act (Artikel 12) müssen Sie rekonstruieren können, warum eine Entscheidung getroffen wurde.
Jede Agentenentscheidung hinterlässt daher eine append-only, hash-verkettete Nachweisspur auf einem Write-once-Speicher, geschrieben bevor die Entscheidung bindend wird. Die Reihenfolge zählt: Die Aufzeichnung wird zuerst geschrieben, und erst dann wird die Entscheidung wirksam. Kann der Nachweis nicht geschrieben werden, findet die Entscheidung nicht statt. Das System schlägt geschlossen fehl.
Diese eine Regel, kein Nachweis keine Entscheidung, macht einen Agenten prüfbar statt zur Blackbox. Die Aufzeichnung jeder Entscheidung erfasst, wer handelte, in wessen Vollmacht, auf welchen Eingaben, gegen welche signierte Policy-Version, auf welcher Autonomiestufe und mit welchen Nachweisen. Die Hash-Verkettung heißt, dass die Spur nicht still nachträglich editiert werden kann: Manipulation bricht die Kette. Zeigen Ihre Prüfer auf eine Transaktion, reichen Sie ihnen eine Aufzeichnung, keine Rekonstruktion.
Das ist auch die Antwort auf die Frage, die ein Risikoausschuss wirklich stellt: Wie geben wir eine Blackbox frei? Die ehrliche Antwort ist, dass es für den Ausschuss keine Blackbox ist. Es ist ein System, in dem jede Entscheidung vorab belegt ankommt, gegen eine Policy, die das Compliance-Team signiert hat, mit folgenschweren Entscheidungen bei Menschen. Der Ausschuss gibt ein dokumentiertes, testbares Control frei, kein Versprechen.
Gebaut für den regulatorischen Horizont, nicht nur für die Regel von heute
Die Regulierung steht nicht still, und das ist das letzte Argument dafür, Compliance ausführbar statt dokumentarisch zu machen.
EU AI Act Artikel 4 gilt bereits: Seit Februar 2025 müssen Organisationen, die KI einsetzen, für ausreichende KI-Kompetenz ihrer Bedienenden sorgen, und die nationalen Behörden beaufsichtigen das seit August 2025. Die Hochrisiko-Pflichten, die Resilienzregeln unter DORA, das Recht auf Erklärung und Datenresidenzanforderungen kommen nach eigenen Zeitplänen. Ein als signierte, versionierte, ablaufende Policy kodiertes Compliance-Regime passt sich mit den Regeln an, weil ein Control zu ändern heißt, ein Policy-Artefakt zu ändern, nicht das System neu zu bauen. Ein Compliance-Regime in PDFs passt sich im Tempo eines Dokumenten-Review-Zyklus an, also zu langsam.
Die Umdeutung für Ihr nächstes Audit lautet also nicht "sind wir mit der aktuellen Regel compliant?". Sie lautet: können wir unsere Pflichten als signierte, testbare Policy ausführen, jede Entscheidung mit einem vor ihrer Bindung geschriebenen Nachweis belegen und ein Control ändern, ohne das System neu zu bauen? Lebt Compliance noch in einem Dokument neben dem System, bestätigen Sie eine Übereinstimmung, die Sie nicht auf Verlangen zeigen können.
Wenn Sie eine Pflicht als laufendes Control an einem echten Prozess sehen wollen, buchen Sie einen Termin.