KI in GRC: Zitieren ist nicht Prüfen

Ein KI-Agent liest eine Sicherheitsrichtlinie, findet einen passenden Absatz und bewertet eine Anforderung als „erfüllt“. Daneben stehen eine nachvollziehbar klingende Begründung und ein Quellenlink.

Das Ergebnis sieht überzeugend aus. Aber eine entscheidende Frage bleibt offen: Welche Veränderung an der Anforderung oder am Nachweis würde diese Bewertung ändern?

Diese Frage zieht sich für uns durch mehrere der interessantesten technischen GRC-Arbeiten dieses Jahres. Die Forschung beschäftigt sich längst nicht mehr nur damit, ob Sprachmodelle Compliance-Fragen beantworten können. Sie untersucht, ob Bewertungen tatsächlich von den richtigen Informationen abhängen, wie Nachweise maschinenlesbar werden und welche Teile einer Prüfung reproduzierbar ausgeführt werden können. Zwei besonders aktuelle Arbeiten dazu erschienen am 8. beziehungsweise 1. Oktober 2026: Verdict Without the Rule und eine Untersuchung zu überprüfbaren Risikobewertungen.

Für uns ergibt sich daraus eine zentrale Produktthese: Ein leistungsfähiger GRC-Agent braucht mehr als Wissen über Standards. Er braucht eine Architektur, die zwischen Anforderungen, Beobachtungen und Bewertungen unterscheidet – und diese Verbindung überprüfbar macht.

Was passiert, wenn man der Compliance-KI die Regel wegnimmt?

Der Preprint Verdict Without the Rule vom 8. Oktober stellt eine ungewöhnlich direkte Frage: Hängt das Urteil eines Modells überhaupt von der vorgegebenen Regel ab?

Die Autoren untersuchen fünf lokal betriebene Modelle über 20 regulatorische und plattformbezogene Themenbereiche. Der Sachverhalt bleibt gleich. Nur die Regel wird entfernt, durch eine andere ersetzt oder hinsichtlich verpflichtender Aussagen negiert. Beim vollständigen Entfernen der Regel ändert sich das Urteil, über Modelle und Themenbereiche gemittelt, lediglich in 5,3 Prozent der Fälle. arXiv

Das ist kein Beweis, dass jedes unveränderte Urteil falsch ist. Ein Sachverhalt kann auch unter verschiedenen Regeln gleich zu bewerten sein. Die Untersuchung ist außerdem kein Test sämtlicher aktueller Spitzenmodelle. Sie zeigt aber eine wichtige Grenze klassischer Benchmarks: Eine richtige Antwort allein verrät nicht, wie abhängig das System von der tatsächlich vorgelegten Regel ist. arXiv

Für Secani leiten wir daraus einen konkreten Anspruch an unsere Evaluation ab: Wir wollen nicht nur einzelne Antworten mit einer Musterlösung vergleichen. Wir brauchen fachlich geprüfte Fallpaare, bei denen eine bestimmte Änderung auch eine bestimmte Bewertungsänderung verlangt.

Ein Beispiel wäre eine interne Vorgabe für Berechtigungsprüfungen: einmal quartalsweise, einmal monatlich. Die vorliegenden Prüfprotokolle bleiben identisch. Decken sie nur Quartalsprüfungen ab, darf das System daraus nicht unverändert die Erfüllung der monatlichen Vorgabe ableiten.

Umgekehrt sollte eine rein sprachliche Umformulierung derselben Vorgabe die Bewertung nicht verändern.

Ein guter Test prüft also beides: Reaktion auf fachlich relevante Änderungen und Stabilität gegenüber irrelevanten Änderungen.

Eine passende Textstelle ist noch kein ausreichender Nachweis

Der nächste Fehler kann bereits bei der Informationssuche entstehen.

PACE, ein im Mai erstmals veröffentlichter und am 28. September überarbeiteter Preprint, untersucht die Abdeckung von Sicherheitsanforderungen durch organisatorische Richtlinien. Das System trennt die Suche nach relevanten Textstellen von der Bewertung, ob diese eine Anforderung vollständig, teilweise oder gar nicht abdecken. Über 1.007 NIST-SP-800-53-Controls und zwei organisatorische Richtlinienbestände berichten die Autoren F1-Werte von 88,54 und 82,31 Prozent. Bewertet wird dabei ausdrücklich die Dokumentation, nicht die operative Wirksamkeit der beschriebenen Maßnahmen. arxiv.org

Diese Grenze ist für das Produktdesign entscheidend. Eine Richtlinie kann erklären, dass privilegierte Zugänge mit Mehrfaktor-Authentifizierung geschützt werden sollen. Damit ist noch nicht nachgewiesen, für welche Konten sie technisch erzwungen wird, welche Ausnahmen bestehen und ob Umgehungswege geprüft wurden.

Der Juli-Preprint ReCon zeigt einen noch grundsätzlicheren Fehler: In untersuchten Beispielen behandeln Modelle den im Prompt enthaltenen ISO-Anforderungstext selbst als Unternehmensnachweis. Das Modell behauptet beispielsweise, eine Richtlinie beschreibe Datenmaskierung, obwohl dieser Inhalt nur in der Prüfvorgabe steht. arXiv

Für Secani bedeutet das: Anforderungen und Unternehmensnachweise müssen bereits im Datenmodell unterschiedliche Objekte sein. Ein Quellenverweis sollte außerdem überprüfbar auf die tatsächliche Fundstelle zeigen – nicht lediglich auf irgendein Dokument zum passenden Thema.

Auch die Bewertung sollte mehrere Fragen auseinanderhalten: Ist etwas dokumentiert? Ist seine Umsetzung belegt? Wurde seine Wirksamkeit untersucht?

Für einen Consultant entsteht der Nutzen gerade in dieser Differenzierung. „Die Richtlinie ist vorhanden, aber für diese drei privilegierten Konten fehlt der technische Nachweis“ ist eine konkrete Arbeitsgrundlage. Ein pauschales „teilweise erfüllt“ ist es noch nicht.

Auch echte Quellen können zu einer falschen Bewertung führen

Quellenbindung löst allerdings nicht jedes Zuordnungsproblem.

Muth und Margraf beschreiben in From Legacy Documentation to OSCAL vom Juli eine Agenten-Pipeline, die Systembeschreibungen in ein Asset-Inventar, einen Wissensgraphen und OSCAL-Artefakte überführt. Sprachmodelle übernehmen interpretierende Schritte; strukturierte Abfragen liefern Informationen aus Threat-Intelligence-Quellen. In fünf Durchläufen eines synthetischen Wasserversorger-Szenarios erreicht die Pipeline einen CVE-Recall von 90 Prozent. arXiv

Interessanter als die Kennzahl ist die Fehleranalyse: Wird anfangs ein Asset falsch extrahiert, können nachgelagerte Abfragen echte Schwachstellen für das falsche Produkt liefern. Die Schwachstelle existiert. Die Quelle ist korrekt. Nur ihre Zuordnung zum untersuchten System stimmt nicht. arXiv

Der Fehler steckt dann in der Beziehung zwischen zwei Informationen, nicht zwingend in den Informationen selbst.

Daraus folgt für Secani eine andere Vorstellung von menschlicher Prüfung. Der wichtigste Review-Schritt liegt nicht unbedingt am Ende eines langen Berichts. Er kann viel früher liegen: bei einer unsicheren Produktversion, einer vermuteten Systemgrenze oder der Zuordnung einer Umsetzung zu einem Standort.

Unser Ziel ist deshalb, solche Unsicherheiten dort sichtbar zu machen, wo weitere Bewertungen von ihnen abhängen. Ein bestätigtes Inventar sollte anders behandelt werden als ein automatisch extrahierter Vorschlag. Wird eine grundlegende Zuordnung korrigiert, müssen ihre abgeleiteten Bewertungen auffindbar bleiben.

Das ist kein Argument dafür, jede Agentenaktion manuell bestätigen zu lassen. Es ist ein Argument dafür, menschliche Aufmerksamkeit gezielt an die Stellen zu lenken, an denen ein einzelner Fehler viele weitere Entscheidungen beeinflussen würde.

Nachweise brauchen Bedingungen, unter denen sie gelten

Was müsste ein Evidence-Objekt eigentlich enthalten?

Die IEEE-Access-Arbeit Compliance-as-Code for AI-Driven Identity Systems von Nweke und Yeng, veröffentlicht am 18. Februar, gibt darauf eine technische Antwort: sogenannte Evidence Contracts. Sie beschreiben, welche Nachweisarten erforderlich sind, welche Zuordnungen und Felder vorhanden sein müssen und für welche Releases beziehungsweise Beobachtungszeiträume die Nachweise benötigt werden. Fehlende oder veraltete Evidenz wird als eigener Befund sichtbar. Der Prototyp verbindet dafür unter anderem OPA/Rego, CI-Prüfungen, Laufzeitereignisse und OSCAL-Exporte. Evaluiert wird er an zwei reproduzierbaren Identity-Workloads mit synthetischen Abläufen, nicht an einer breiten Unternehmensstichprobe. ResearchGate

Für Secani ist daran besonders interessant, dass eine Datei nicht pauschal „der Nachweis“ sein muss. Sie ist Material, das eine bestimmte Aussage unter bestimmten Bedingungen unterstützen kann.

Ein Testprotokoll vom März beantwortet beispielsweise nicht automatisch, ob dieselbe Kontrolle nach einer Systemumstellung im September noch greift. Ein Konfigurationsexport für eine Tochtergesellschaft belegt nicht ohne Weiteres den Zustand einer anderen.

Ein Nachweis sollte deshalb mit seinem Prüfgegenstand, seinem Zeitraum, seiner Herkunft und der unterstützten Aussage verbunden sein. Seine Eignung ergibt sich aus diesem Zusammenhang, nicht allein aus dem Dateinamen oder Upload-Datum.

Das verändert auch den Umgang mit ausgefallenen Integrationen. Bleiben erwartete Daten aus, sollte das System nicht einfach den letzten grünen Status fortschreiben. Zunächst fehlt die Grundlage für eine aktuelle Bewertung. Das ist etwas anderes als ein festgestelltes Versagen der zugrunde liegenden Sicherheitsmaßnahme.

Für das Produktdesign bedeutet das: „Nicht belegt“ und „nachweislich nicht erfüllt“ brauchen unterschiedliche Zustände und unterschiedliche nächste Schritte.

Die KI interpretiert. Überprüfbare Regeln führen aus.

Wie wird aus diesen Informationen ein belastbares Prüfergebnis?

Ontological Knowledge Blocks von Sharma und Kunkel, veröffentlicht im Mai, beschreibt einen Ansatz mit einer expliziten Zwischenstufe: Fachlich verantwortete Anforderungen werden in einer strukturierten YAML-Repräsentation festgehalten. Ein deterministischer Compiler übersetzt sie anschließend in SHACL-Regeln, mit denen sich Bedingungen in einem Evidenzgraphen prüfen lassen. Die normative Interpretation wird dabei ausdrücklich nicht automatisiert. Die Evaluation umfasst 24 Validierungsläufe in einem HPC-Szenario – ein Machbarkeitsnachweis, keine universelle Compliance-Engine. arXiv

Der für uns relevante Gedanke ist nicht die Verpflichtung auf einen bestimmten Technologie-Stack. Es ist die Trennung zweier Aufgaben: eine Anforderung fachlich operationalisieren und die vereinbarte Prüfung wiederholt ausführen.

Ein Sprachmodell kann beispielsweise helfen, aus einer Richtlinie prüfbare Kriterien vorzuschlagen. Ob ein erforderliches Feld vorhanden ist, ein festgelegter Grenzwert überschritten wird oder ein erwarteter Nachweis fehlt, sollte anschließend nicht bei jedem Durchlauf neu interpretiert werden müssen.

Für Risikobewertungen verfolgt der Preprint von Huang, Halak und Kang vom 1. Oktober einen verwandten Ansatz. Beobachtbare technische Artefakte werden über versionierte Regeln auf ordinale Bewertungen abgebildet. Formal überprüft wird unter anderem, ob stärkere Controls die bewertete Angriffsdurchführbarkeit nicht erhöhen. Untersucht werden fünf öffentliche AI-Projekte. Das Modell liefert ausdrücklich keine empirisch kalibrierten Vorfallwahrscheinlichkeiten. arXiv

Diese Begrenzung ist wichtig: Eine formal konsistente Bewertungsfunktion beweist noch nicht, dass ihre Annahmen die Realität ausreichend abbilden.

Für Secani folgt daraus ein Architekturprinzip: Interpretierende Agentenschritte und deterministische Prüfungen sollen zusammenarbeiten, aber unterscheidbar bleiben. Zu einer Bewertung gehören deshalb nicht nur Ergebnis und Erklärung, sondern auch die verwendeten Nachweisstände, die Anforderungsversion und die angewandte Prüflogik.

So wird eine spätere Abweichung untersuchbar: Hat sich das System verändert? Die Anforderung? Die Bewertungsmethode? Oder nur die Interpretation des Agenten?

Continuous Compliance bedeutet auch, Bewertungen wieder zu öffnen

Aus diesen Arbeiten ergibt sich für uns noch eine weiterführende Produktentscheidung: Verknüpfungen dürfen nicht nur beim Erstellen einer Bewertung helfen. Sie müssen auch zeigen, wann diese Bewertung erneut geprüft werden sollte.

Die Identity-Arbeit beschreibt bereits eine solche Änderungsanalyse über versionierte Anforderungen, Controls, Prüfungen und Evidenzvorgaben. Änderungen werden entlang ihrer Zuordnungen weiterverfolgt, um betroffene Prüfungen zu identifizieren. ResearchGate

Für Secani wollen wir diesen Gedanken auf den gesamten Arbeitsprozess übertragen.

Angenommen, ein freigegebener Nachweis unterstützt Bewertungen in mehreren Frameworks. Später ändert sich der betroffene Systemumfang. Dann sollte ein Consultant erkennen können, welche Bewertungen diese frühere Systemgrenze vorausgesetzt haben – und welche davon tatsächlich neu betrachtet werden müssen.

Das ist etwas anderes, als bei jeder Dokumentänderung sämtliche Controls auf „offen“ zu setzen. Eine korrigierte Überschrift sollte keine neue Vollprüfung auslösen. Eine neue Ausnahme für privilegierte Zugänge möglicherweise schon.

Technisch verlangt das explizite Beziehungen und nachvollziehbare Versionen. Fachlich verlangt es eine Aussage darüber, welcher Teil einer Bewertung von welcher Information abhängt.

Dabei muss der historische Prüfstand erhalten bleiben. Eine zum damaligen Zeitpunkt begründete Entscheidung wird nicht rückwirkend falsch, nur weil sich ihre Voraussetzungen ändern. Aber sie darf auch nicht unbegrenzt als aktuelle Aussage über das Unternehmen weiterleben.

Für Beratungsteams wäre genau das ein erheblicher Fortschritt: nicht ständig alles erneut durchsuchen, sondern gezielt an den Bewertungen weiterarbeiten, deren Grundlagen sich verändert haben.

Das eigentliche Produkt ist die nachvollziehbare Entscheidung

Diese Forschung liefert keinen Beweis, dass sich GRC vollständig autonom erledigen lässt. Mehrere der Arbeiten sind Preprints; andere untersuchen eng begrenzte Prototypen. Die beschriebenen Ergebnisse sind deshalb eher konkrete Architekturhinweise als fertige Baupläne für ein universelles Compliance-System. arXiv

Für uns machen sie die Produktaufgabe trotzdem deutlich.

Wir wollen Agenten, die umfangreiche Vorarbeit übernehmen: Informationen erschließen, Zuordnungen vorschlagen, Nachweise zusammenführen, Lücken erklären und Maßnahmen vorbereiten. Der Consultant soll dadurch schneller zu einer fachlich verantwortbaren Entscheidung kommen – nicht lediglich schneller zu mehr generiertem Text.

Der Maßstab für Secani ist deshalb nicht, wie viele Anforderungen ein Agent auf Grün setzen kann. Sondern ob sich beantworten lässt, weshalb eine Bewertung gilt, was noch unsicher ist und welche Veränderung eine erneute Prüfung erforderlich machen würde.

Ein grüner Status ist ein Ergebnis. Die nachvollziehbare Verbindung zwischen Anforderung, Realität und Entscheidung ist das Produkt.