Compliance as Code

In regulierten Branchen wird Compliance heute am Ende geprüft: Vor dem Produktivgang sammeln Projekte Dokumente, füllen Checklisten aus und warten auf Freigaben von Sicherheit, Datenschutz und Revision. Im agentischen Software Development Lifecycle trägt dieses Muster nicht mehr, weil Agenten mehr Änderungen in kürzerer Zeit erzeugen, als eine nachgelagerte Prüfung je bewältigen kann. Dieser Beitrag beschreibt, wie wir Regulatorik in die Pipeline verlegen: Richtlinien werden als maschinenlesbare Regeln formuliert, an jedem Gate automatisch geprüft und mit einem lückenlosen Audit-Trail belegt, sodass Nachweise als Nebenprodukt der Arbeit entstehen.

Warum die nachgelagerte Prüfung nicht mehr trägt

In den ersten drei Beiträgen dieser Serie ging es um die Arbeitsteilung zwischen Mensch und Agent, um Prüfgates, an denen Menschen entscheiden, und um die Messung des Reifegrads. Der vierte Baustein ist die Governance, und er entscheidet in regulierten Häusern darüber, ob ein agentischer Pilot je produktiv wird. Von den vier Gründen, aus denen agentische Transformationen scheitern, ist „Governance zu spät“ aus meiner Sicht der tückischste: Aufsicht, Revision, Datenschutz und Betriebsrat kommen erst vor dem Produktivgang an den Tisch, und der Rollout stoppt auf der letzten Meile.

Das Problem ist strukturell, nicht organisatorisch. Eine nachgelagerte Compliance-Prüfung setzt voraus, dass es wenige, große Releases gibt, die sich einzeln betrachten lassen. Agentische Zellen liefern jedoch in Zyklen von Tagen, in reifen Zellen von Stunden. Wenn jede dieser Änderungen ein Compliance-Review von mehreren Wochen durchlaufen muss, ist der Zeitgewinn verloren, bevor er beim Fachbereich ankommt. Wird das Review stattdessen auf Stichproben reduziert, verliert die Organisation genau die Nachvollziehbarkeit, die die Regulatorik verlangt. Beides ist keine Option.

Dazu kommt ein zweites Problem: Ein Sprachmodell kennt die Sicherheitsrichtlinien Ihres Hauses nicht, ebenso wenig die Architekturvorgaben, die Datenklassifizierung oder die Aufbewahrungsfristen aus dem Fachrecht, solange niemand sie ihm als prüfbare Regel vorgibt. Eine Richtlinie, die nur in einem Dokument steht, wird von einem Agenten weder gelesen noch eingehalten. Sie existiert für ihn nicht.

Eine Richtlinie, die in einem Dokument steht, wird erinnert. Eine Richtlinie, die in der Pipeline steht, wird eingehalten.

Was Compliance as Code bedeutet

Compliance as Code heißt, Richtlinien so zu behandeln wie Software: Sie werden maschinenlesbar formuliert, versioniert, getestet und in der Delivery-Pipeline als Gate-Kriterien erzwungen. Drei Eigenschaften machen den Unterschied zur klassischen Richtlinie im Intranet aus.

• Prüfbar. Jede Regel hat eine automatisierte Prüfung, die an einem definierten Gate läuft. Eine Regel, die sich nicht prüfen lässt, ist noch keine Regel, sondern eine Absicht, und wird so lange präzisiert, bis sie prüfbar ist.
• Versioniert. Regeln haben Eigentümerinnen und Eigentümer, eine Historie und einen Freigabeprozess. Wer eine Regel ändert, hinterlässt eine nachvollziehbare Spur, genau wie bei einer Codeänderung.
• Erzwungen. Ein Verstoß blockiert das Gate. Ausnahmen sind möglich, aber sie sind dokumentierte, befristete und personalisierte Entscheidungen, keine stillschweigende Umgehung unter Termindruck.

In unseren Projekten fallen die Regeln in vier Klassen. Sicherheitsregeln betreffen etwa Abhängigkeiten mit bekannten Schwachstellen, unzulässige Lizenzen, Geheimnisse im Code oder Verschlüsselungsstandards. Architekturregeln legen fest, welche Technologien, Schnittstellenstandards und Schichtenschnitte zulässig sind und wo Daten liegen dürfen, etwa ausschließlich in europäischen Rechenzentren. Datenschutzregeln beschreiben, welche Datenklassen in welchen Umgebungen verarbeitet werden dürfen, welche Löschfristen gelten und was protokolliert werden muss. Fachlich-regulatorische Regeln schließlich sind Anforderungen aus Gesetzen und Aufsichtsvorgaben, die das System selbst erfüllen muss: ein Vier-Augen-Prinzip ab einer bestimmten Betragsgrenze, eine Aufbewahrungsfrist, eine Meldepflicht.

Die vierte Klasse zeigt, dass Compliance as Code zwei Ebenen hat. Die erste ist die Compliance des Prozesses: Wie entsteht die Software, wer verantwortet welche Änderung, was ist protokolliert? Die zweite ist die Compliance des Produkts: Erfüllt die Software nachweislich die Vorschriften, die für ihren Einsatz gelten? Beide Ebenen gehören in die Pipeline, aber sie werden an unterschiedlichen Gates und mit unterschiedlichen Mitteln geprüft.

Drei Prinzipien tragen die Governance

Die Aufsicht über agentische Delivery ruht in unserem Betriebsmodell auf drei Prinzipien. Erstens verantwortet der Mensch jede Änderung eines Agenten; Rechenschaft gegenüber Aufsicht, Revision und Partnern bleibt eindeutig personalisiert. Zweitens werden Richtlinien als Compliance as Code in Pipelines erzwungen statt in Dokumenten erinnert. Drittens macht ein lückenloser Audit-Trail jede Agentenaktion, jeden verwendeten Kontext und jede Freigabe rekonstruierbar.

Die europäische Regulatorik verlangt genau diese Bausteine. Die KI-Verordnung (EU) 2024/1689, in Kraft seit August 2024, fordert für Hochrisiko-KI-Systeme unter anderem ein Risikomanagementsystem, technische Dokumentation, Aufzeichnungspflichten und menschliche Aufsicht (Artikel 9, 11, 12 und 14). DORA, die Verordnung (EU) 2022/2554, gilt seit Januar 2025 für Finanzunternehmen und verlangt ein belastbares IKT-Risikomanagement, das Management IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz und die Steuerung von Drittanbietern. Und die interne Revision verlangt seit jeher, dass jede produktive Änderung nachvollziehbar ist.

Ein Hinweis zur Einordnung: Ob ein KI-System als Hochrisiko-System gilt, hängt von seinem Einsatzzweck ab, nicht von der Technologie. Deshalb gehört zu Compliance as Code auch, den Einsatzzweck jedes Agenten zu klassifizieren und zu dokumentieren. Und wenn die Software, die Agenten bauen, selbst unter die Verordnung fällt, werden deren Anforderungen zu Anforderungen in der Spezifikation, mit Testfällen wie jede andere Anforderung auch.

Wo die Regeln in der Pipeline greifen

Die vier Gates aus dem zweiten Beitrag dieser Serie sind zugleich die Orte, an denen Compliance as Code wirkt. An jedem Gate gilt dieselbe Arbeitsteilung: Agenten generieren, Agenten verifizieren, Menschen entscheiden.

1. Definition of Ready. Regulatorische Anforderungen stehen als prüfbare Anforderungen in der Spezifikation, jede mit Verweis auf die Vorschrift, aus der sie stammt. Mit reqChecker prüfen wir, ob sie eindeutig, verifizierbar und singulär formuliert sind; erst dann werden sie zur Grundlage von Testfällen und maschinenlesbaren Bauaufträgen. Der Wissensgraph verknüpft Vorschrift und Anforderung, sodass die Herkunft jeder Regel belegt ist.
2. Definition of Done. Vor jedem Merge laufen die Prüfungen der Prozess-Compliance: Security-Scans, Abhängigkeits- und Lizenzprüfung, Architekturregeln, Suche nach Geheimnissen im Code, Testabdeckung. Unabhängige Prüfagenten führen sie aus; kein Agent prüft die eigene Arbeit. Ein Verstoß blockiert das Gate, und was beim Menschen ankommt, ist ein verifiziertes Ergebnis mit Prüfprotokoll.
3. Definition of Deploy. Vor dem Go-live wird die Produkt-Compliance nachgewiesen: Abnahmetests gegen die Spezifikation mit Signoff, einschließlich der regulatorischen Anforderungen, ein Security-Review durch unsere Expertinnen und Experten und ein getesteter Rollback. Die Go/No-Go-Entscheidung trifft ein Mensch, auf Basis eines revisionssicheren Abnahmeberichts.
4. Definition of Operability. Im Betrieb greifen Observability, Protokollierung und Incident-Verantwortung. Vorfälle werden erkannt, dokumentiert und gemeldet, wie es DORA für den Finanzsektor verlangt, und die Erkenntnisse fließen in Backlog und Spezifikation zurück.

Der entscheidende Nebeneffekt entsteht im Wissensgraphen: Weil Vorschrift, Anforderung, Code, Testfall und Release über typisierte, belegte Beziehungen verbunden sind, entsteht die Nachweiskette nicht als eigenes Projekt vor dem Audit, sondern laufend. Ändert sich eine Vorschrift, zeigt eine Impact-Analyse in Minuten, welche Anforderungen, Module und Tests betroffen sind. Bisher dauerte diese Frage in gewachsenen Landschaften Wochen.

Was das in der Praxis verlangt

Compliance as Code ist keine Werkzeugentscheidung, sondern eine organisatorische. Aus unseren Projekten lassen sich fünf Konsequenzen ableiten.

• Klein anfangen, aber verbindlich. Nicht alle Richtlinien werden auf einmal codiert. Wir beginnen mit den Regeln, die heute am häufigsten Freigaben verzögern, meist Sicherheit und Abhängigkeiten, und erweitern domänenweise entlang der Pilotzellen. In unserem Vorgehen sind Quality Gates und Compliance as Code bereits in der Pilotierung produktiv; flächendeckend werden sie im zweiten Horizont des Reifegradpfads, wenn Agenten mehrstufige Aufträge über Bereiche hinweg ausführen.
• Revision, Datenschutz und Sicherheit werden zu Autorinnen und Autoren. Die Fachleute, die heute am Ende prüfen, formulieren die Regeln am Anfang. Das verschiebt ihre Rolle von der Kontrolle am Ende zur Quelle der Regel am Anfang und holt genau die Stakeholder früh an den Tisch, deren spätes Erscheinen Rollouts stoppt.
• Jede Regel braucht eine Eigentümerin oder einen Eigentümer. Eine Regel ohne Verantwortung veraltet, und eine veraltete Regel, die weiterhin Gates blockiert, untergräbt die Akzeptanz des ganzen Ansatzes. Ausnahmen werden befristet und mit Begründung dokumentiert.
• Die Nachweiskette gehört der Organisation. Regeln, Prüfergebnisse und Audit-Trail liegen in der eigenen Plattform und im eigenen Wissensgraphen, nicht beim Modellanbieter. Modelle werden Sie in den nächsten Jahren mehrfach wechseln; die Nachweise bleiben.
• Leitplanken messen. Neben der Delivery-Effizienz gehören der Anteil der automatisiert geprüften Regeln, die Zeit von der Änderung bis zur Freigabe und die vier Kennzahlen der Delivery-Forschung (Forsgren, Humble, Kim 2018) in die Steuerung. Effizienzgewinne zählen nur, wenn Change Failure Rate, Produktionsstörungen, Defektrate und Testabdeckung sich nicht verschlechtern.

Dass dieser Weg auch in streng regulierten Häusern gangbar ist, zeigt ein Programm bei einer europäischen Großbank, das wir begleiten: Unter Bankenaufsicht, DORA und KI-Verordnung entstand ein Kapabilitätsmodell mit 41 Fähigkeiten in neun Domänen über sechs Reifegrade, regulatorisch gemappt, mit „Sicherheit, Risiko und Compliance“ als eigener Domäne. In der Portfolio-Logik, mit der wir solche Programme priorisieren, zählt Compliance as Code zu den strategischen Wetten, neben agentischen Pilotzellen und dem Wissensgraphen für Legacy-Code: mit Business Case, Vorstandssponsorship und stufenweiser Finanzierung, nicht als Quick Win (Angaben zum Programm anonymisiert und gerundet, Projektstand erstes Quartal 2026).

Die wirtschaftliche Seite ist klar: Die bis zu fünffach schnellere Delivery im agentisch orchestrierten Umsetzungsmodell und die 20 bis 45 Prozent Effizienzgewinn über Gesamtprojekte (Erfahrungswerte aus ReqPOOL-Projekten 2023 bis 2026, projektspezifisch validierbar) sind in regulierten Branchen nur erreichbar, wenn die Compliance-Prüfung mit der Delivery Schritt hält. Compliance as Code ist die Bedingung dafür, nicht der Preis.

Wie wir es selbst tun: reqCoder

In reqCoder, dem vollständigen, vollautomatisierten agentischen Software Development Lifecycle von ReqPOOL, der bei uns intern im Einsatz ist, sind diese Prinzipien fest verdrahtet. Die Evidenzkette über die vier Stages enthält reqChecker-Prüfung und Security-Scan in der Beta, Signoff-Abnahme und Audit-Trail in der Deployment-Stage und den vollständigen Übergang des geistigen Eigentums in der Produktion. Jede Agentenaktion, jeder verwendete Kontext und jede Freigabe werden protokolliert und sind rekonstruierbar. Die Modelle werden über EU-Rechenzentren angebunden, und es gibt kein Training mit Kundendaten. Jede Freigabe an einem Gate bleibt eine menschliche Entscheidung.

Richtig gebaut ist der agentische Software Development Lifecycle deshalb nicht das Compliance-Risiko, für das er in vielen Häusern gehalten wird, sondern die erste Form der Delivery, in der Nachweise als Nebenprodukt der Arbeit entstehen. Das ist, so meine Einschätzung nach den vier Beiträgen dieser Serie, der eigentliche Grund, weshalb regulierte Branchen nicht die letzten, sondern die ersten sein sollten, die den Übergang gestalten.

Der nächste Schritt

Wie wir Governance, Quality Gates und Compliance as Code in Ihrer Delivery-Organisation verankern, lesen Sie auf der Seite Agentic Software Development Lifecycle. Wie die Evidenzkette und der Audit-Trail in unserer eigenen agentischen Pipeline aussehen, beschreibt die Seite reqCoder. In einem Expertengespräch prüfen wir gemeinsam, welche Ihrer Richtlinien sich heute schon maschinenlesbar formulieren lassen und an welchem Gate sie zuerst greifen sollten.