KI-Systeme können heute Compliance-Artefakte erzeugen, die strukturell vollständig, terminologisch korrekt und bei oberflächlicher Betrachtung von dem, was ein erfahrener Analyst produzieren würde, nicht zu unterscheiden sind. TARAs, Safety Cases, Traceability-Matrizen, Gefährdungsanalysen. Allesamt.
Das sollte eine gute Nachricht sein. Stattdessen wirft es eine Frage auf, die sich leichter ignorieren ließ, solange Menschen die Arbeit erledigten: Was genau wird dabei eigentlich verifiziert?
Das Unbehagen ist berechtigt. Aber es weist in die falsche Richtung. Das Problem ist nicht, dass KI Compliance-Dokumentation erzeugt. Das Problem ist, dass KI einen strukturellen Fehler sichtbar macht, der schon immer vorhanden war: Compliance-Prozesse, die auf Artefakte optimieren, nicht auf die Eigenschaften, die diese Artefakte abbilden sollten.
Ein Traceability-Link, der einen Tag vor einem Audit angelegt wird, ist strukturell identisch mit einem, der während der Entwicklung entstand. Die Matrix zeigt in beiden Fällen grün. Das Audit besteht möglicherweise. Aber ein Link, der zur Erfüllung eines KPIs erstellt wurde, trägt nichts zur Sicherheit des Produkts bei. Das Artefakt und die Realität, die es abbilden sollte, haben sich entkoppelt.
Compliance-Theater gibt es seit Jahrzehnten, lange vor KI. KI führt diesen Fehler nicht ein. Sie beseitigt die Reibung, die ihn bislang tolerierbar machte.
Das Artefakt ist nicht das Argument
Nach ISO 21434 ist eine Threat Analysis and Risk Assessment nicht deshalb wertvoll, weil sie dokumentiert, was jemand über Sicherheit gedacht hat. Sie ist wertvoll, weil sie eine nachweisbare Eigenschaft kodiert: Gegeben diese Assets, diese Bedrohungsakteure, diese Angriffspfade und diese Maßnahmen liegt das Restrisiko unterhalb des definierten Schwellenwerts. Das Dokument ist der Träger. Die Eigenschaft ist das, was zählt.
Dasselbe gilt für Traceability. Eine Traceability-Matrix beweist Requirements Coverage nicht durch ihr bloßes Vorhandensein. Sie beweist Coverage, weil die darin kodierten Links formal konsistent mit den referenzierten Artefakten sind und als solche verifiziert werden können. Entfernt man diese formale Konsistenz, ist die Matrix eine Tabelle mit Häkchen.
Menschlich erstellte Compliance-Artefakte hatten dieses Problem immer, weil die Bedingungen für ihre Pflege nie günstig waren. Traceability mit dem tatsächlichen Entwicklungsstand synchron zu halten ist aufwendig und produziert nichts, was der Kunde ausliefern kann. Die implizite Priorisierung ist rational: Das Produkt wird ausgeliefert, die Dokumentation holt auf, das Audit wird gemanagt.
Das praktische Ziel war nicht, ein nachweislich sicheres Produkt zu bauen. Es war, einen externen Prüfer zu überzeugen, dass man es getan hat.
KI verändert die Ökonomie, nicht die Anreizstruktur. Compliance-Dokumentation, für die früher Wochen benötigt wurden, kann nun in Stunden produziert werden. Volumen erweist sich als wirksamster Schutz vor Prüfung, nicht weil Prüfer unaufmerksam sind, sondern weil Inkonsistenzen in einem großen Artefakt-Set echten Aufwand erfordern, um sie zu finden.
Volumen ist kein Beweis. Es ist Deckung.
Als wir Automatisierungsfunktionen in itemis ANALYZE, einem Traceability-Tool für Compliance in regulierten Domänen, eingeführt haben, war das Nutzungsmuster sofort und eindeutig. Kunden setzten die Automatisierung von der ersten Woche an als Ersatz für manuelle Traceability-Arbeit ein. Niemand musste überzeugt werden. Der Anreiz, Compliance-Overhead zu eliminieren, ist eindeutig, und er äußert sich in dem Moment, in dem eine Alternative existiert.
Der geschlossene Kreislauf
Die naheliegende Antwort ist, KI auch für die Prüfung einzusetzen. Das bedeutet: KI prüft KI-generierte Dokumentation. Interne Konsistenz wird nachgewiesen, sonst nichts. Ein Auditor, der dieses Ergebnis akzeptiert, verifiziert keine Sicherheit. Er verifiziert, dass die Artefakte miteinander übereinstimmen.
Das ist keine Compliance. Das ist ein geschlossener Kreislauf mit einem Stempel am Ende.
Das Problem liegt nicht darin, dass KI auf beiden Seiten beteiligt ist. Es liegt darin, dass beide Seiten mit demselben operieren: Dokumentation, die vom eigentlichen Produkt entkoppelt wurde. Ein besserer Prüfer löst das nicht. Ein intelligenterer Generator auch nicht. Der geschlossene Kreislauf ist ein strukturelles Versagen, das eine strukturelle Lösung erfordert.
Ein Agent, der einen definierten Prozess steuert und überwacht, ist etwas anderes. Er generiert keine Compliance-Artefakte. Er führt einen Prozess aus: die Schritte, die Regeln, die erforderlichen Ergebnisse an jedem Punkt, in der richtigen Reihenfolge, mit den richtigen Eingaben, und verifiziert dabei, dass die formalen Eigenschaften durchgehend eingehalten werden. Menschliche Beteiligung konzentriert sich auf zwei Dinge: den Prozess zu definieren und festzulegen, was das Ergebnis nachweisen muss.
Die Artefakte, die dabei entstehen, sind keine Beschreibungen von Compliance. Sie sind Belege dafür, dass der Prozess abgelaufen ist.
KPIs und Metriken werden zu dem, was sie immer sein sollten: nicht Zahlen, die vor einem Audit angepasst werden, sondern Belege dafür, dass der Prozess korrekt ausgeführt wurde. Die Rolle des Auditors verschwindet nicht. Sie verändert sich: vom Lesen von Dokumenten zur Inspektion der Prozessausführung. Von „Sieht das richtig aus?" zu „Hat der Prozess stattgefunden, und spiegelt das Ergebnis ihn wider?" Das ist ein strengerer Maßstab, kein schwächerer.
Das Dokument ist das Nebenprodukt. Der Prozess ist der Beweis.
Neuartige Bedrohungsszenarien, domänenspezifische Risikobeurteilungen, Entscheidungen über akzeptables Restrisiko: Das bleiben menschliche Verantwortlichkeiten. Was ein Agent beseitigt, ist der Overhead, der bislang verhindert, dass das Urteilsvermögen der Ingenieure dort eingesetzt wird, wo es tatsächlich zählt. Das ist keine Verringerung von Rigorosität. Es ist die Voraussetzung dafür, dass Rigorosität überhaupt möglich wird.
Für einen Anbieter von Compliance- und Traceability-Werkzeugen verändert diese Verschiebung nicht die Produkt-Roadmap. Sie verändert, was das Produkt grundsätzlich ist.
Ein Tool, das Ingenieure bei der Compliance-Verwaltung unterstützt, ist ein Produktivitätswerkzeug. Sein Wert wird in eingesparter Zeit, vermiedenen Fehlern und optimierten Workflows gemessen. Wenn Agenten die primären Anwender werden, entfällt dieses Wertversprechen. Agenten brauchen kein besseres Interface.
Was Agenten brauchen, ist ein formales Modell, gegen das sie ausführen können. Eine präzise Definition dessen, was Compliance erfordert, kodiert in einer Struktur, die deterministisch, auditierbar und vollständig genug ist, um einen Prozess darauf auszuführen. Das Graphmodell, die Coverage-Logik, die semantischen Konsistenzprüfungen: Das sind keine Features, die menschliche Analysten beschleunigen. Sie sind die Spezifikation dessen, was korrekte Compliance bedeutet.
Der Unterschied zwischen einem Traceability-Graphen, der Links speichert, und einem, der kontrollierte Semantik kodiert, entscheidet genau darüber, ob ein Agent darüber schlussfolgern kann. Ein Graph ohne explizite, versionierte Semantik ist kein Substrat, auf dem ein Agent ausführen kann. Er ist ein Reporting-Artefakt.
Ein Anbieter, der dieses Wissen formalisiert hat, besitzt den Prozess. Ein Anbieter, der ein Interface gebaut hat, nicht.
Traceability war immer das verbindende Gewebe zwischen dem Produkt und seinen Compliance-Verpflichtungen. Von Menschen unter Zeitdruck gepflegt, entkoppelte es sich. Von Agenten gepflegt, die einen definierten Prozess ausführen, spiegelt es den tatsächlichen Zustand des Produkts kontinuierlich wider, nicht nur vor einem Audit.
Das ist der Zweck, für den Compliance-Dokumentation konzipiert wurde. Die Frage ist, ob das zugrundeliegende Modell formal genug ist, um ihn zu erfüllen.
Requirements Traceability in der Praxis: Wie durchgängige Traceability in regulierten Projekten funktioniert, welche Tools sich bewährt haben und wo der RTM-Ansatz an seine Grenzen stößt: Requirements Traceability bei itemis →