KI-Compliance-Architektur: Drei Entscheidungen, die schwerer wiegen als die Framework-Wahl

Warum ist die Framework-Frage die falsche erste Frage?

Die meisten Framework-Vergleiche bewerten Geschwindigkeit, Entwicklerfreundlichkeit und Skalierbarkeit. Keiner prüft, ob das Framework in regulierten Umgebungen überhaupt tragfähig ist. Das sind zwei verschiedene Bewertungen mit zwei verschiedenen Ergebnissen.

Nach Teil 1 dieser Serie kam eine Frage immer wieder: „Welches Framework sollen wir nehmen?" Die Frage ist verständlich. Sie überspringt drei Entscheidungen, die schwerer wiegen als jede Framework-Wahl. Dieser Artikel arbeitet diese Entscheidungen ab, bevor wir in Teil 3 konkrete Frameworks vergleichen. Die richtige KI-Compliance-Architektur funktioniert auch mit dem falschen Framework. Die falsche Architektur fällt mit jedem Framework durch. Laut einer aktuellen Branchenauswertung bauen 70 Prozent der regulierten Unternehmen ihren KI-Agenten-Stack innerhalb der ersten 90 Tage komplett um, weil die erste Architektur im Produktivbetrieb nicht trägt¹.

Wo braucht eine KI-Compliance-Architektur Determinismus, und wo darf sie probabilistisch arbeiten?

Vor drei Monaten: Audit-Unterstützung bei einem mittelgroßen Versicherer mit rund 450 Mitarbeitenden. Das Haus betreibt seit einem Jahr ein RAG-System, das bei Fragen zu den Versicherungsbedingungen die Sachbearbeitung unterstützt. Testfrage der internen Revision: Welche Meldefrist gilt für einen Leitungswasserschaden nach der Bedingungswerk 2022? Die Vektordatenbank liefert 93 Prozent Match, zitiert aber einen Absatz aus Bedingungswerk 2018, aus einer anderen Tarifgeneration und mit einer anderen Frist. Der Auditor hatte seinen Befund.

Der Grund ist lehrreich. Ein probabilistisches System hat eine deterministische Frage beantwortet. Semantische Nähe sagt: Diese beiden Texte handeln vom gleichen Thema. Ein Auditor fragt etwas anderes. Er fragt: Ist diese Anforderung erfüllt, ja oder nein, und wo ist der Nachweis?

„Wir müssen Multi-Agenten-Systeme bauen." „Wir brauchen RAG." Diese Sätze höre ich in jedem zweiten Gespräch. Meine Rückfrage: Wofür genau? Compliance verlangt Determinismus. Die halbe Branche baut probabilistische Systeme, weil Multi-Agent und RAG gerade die Begriffe sind, die auf Konferenzen funktionieren. Die Architektur entscheidet. Das Framework kommt danach. Eine Studie der Hochschule Karlsruhe unter 517 mittelständischen Unternehmen stützt das Muster: 40 Prozent setzen KI ein, aber nur 21 Prozent haben eine KI-Strategie. Werkzeuge werden eingeführt, bevor die Architekturfragen beantwortet sind².

Die entscheidende Unterscheidung ist nicht binär. Ein Compliance-Status hat vier Zustände. Compliant heißt: Die Kontrolle ist dokumentiert, implementiert und nachgewiesen. Partial heißt: Die Kontrolle existiert, aber Nachweise fehlen oder sind veraltet. Gap heißt: Keine passende Kontrolle vorhanden. Not applicable heißt: Die Kontrolle gilt für dieses Unternehmensprofil nicht. Ein System, das nur Ähnlichkeit misst, kann diese vier Zustände nicht unterscheiden. Es sagt „94 Prozent Match". Ein architektonisch durchdachtes System sagt „partial: Policy vorhanden, Nachweis abgelaufen seit 14 Monaten".

Dieses Prinzip gilt branchenübergreifend. In der Compliance heißt es: „MFA wird empfohlen" bedeutet etwas anderes als „MFA ist Pflicht". Im Qualitätsmanagement: „Messwert wurde erfasst" bedeutet etwas anderes als „Messwert liegt im Toleranzbereich". In der Finanzkontrolle: „Rechnung existiert" bedeutet etwas anderes als „Rechnung ist freigegeben und gebucht". In jedem Fall gilt: Ein Dokument, das ein Thema erwähnt, beweist nicht, dass eine Verpflichtung erfüllt ist.

Die linke Spalte toleriert kein „kommt drauf an". Die rechte Spalte gewinnt durch KI, braucht aber Leitplanken. Wer diese Aufteilung vor der ersten Codezeile macht, spart sich den Architektur-Umbau nach dem ersten gescheiterten Audit.

Wann ist ein Knowledge Graph die bessere Wahl als Vektorsuche?

Die zweite Entscheidung betrifft die Schichten Ihrer KI-Compliance-Architektur. Die meisten RAG-Implementierungen haben eine Schicht: die Vektorsuche. Für Compliance reicht das nicht.

Ein Compliance-System, das einen Audit besteht, braucht drei Schichten. Der Knowledge Graph bildet die regulatorische Struktur ab und entscheidet, was anwendbar ist. Die Vektorsuche findet innerhalb des anwendbaren Scopes semantisch relevante Dokumente. Das LLM erklärt, warum ein Ergebnis relevant ist, und produziert lesbare Reports. Gartner nennt Knowledge Graphs einen „Critical Enabler" für generative KI in regulierten Umgebungen³. Der Grund: Knowledge Graphs liefern die strukturierte Wahrheit, die LLMs aus sich heraus nicht produzieren können.

Die Reihenfolge dieser drei Schichten ist eine bewusste Architekturentscheidung. Der Graph filtert zuerst. Die Vektorsuche verfeinert. Das LLM erklärt. Das LLM ist nie die Quelle der Wahrheit. In der Compliance ist das eine Governance-Anforderung.

Die Genauigkeitslücke lässt sich messen. GraphRAG-Systeme erreichen 90,6 Prozent Genauigkeit bei Exact-Match-Compliance-Benchmarks. Standard-RAG schafft 65,6 Prozent⁴. Das sind 25 Prozentpunkte, die ein Auditor bemerken wird.

So sieht das in der Praxis aus. Ein Unternehmensprofil enthält strukturierte Daten: Branche (Finanzdienstleistung), Jurisdiktion (EU), Datentypen (personenbezogen und finanziell), Unternehmensgröße (200 Mitarbeitende). Diese Eingabe steuert die Graph-Abfrage. Ergebnis: DORA, DSGVO und ISO 27001 sind anwendbar. HIPAA nicht, weil das Unternehmen keine US-Gesundheitsdaten verarbeitet. Erst nach diesem Filter startet die Vektorsuche, und zwar nur innerhalb der anwendbaren Regulierungen.

Ohne diesen ersten Schritt durchsucht die Vektorsuche die komplette regulatorische Datenbank. Sie findet „ähnliche" Paragraphen aus Regulierungen, die für das Unternehmen gar nicht gelten. Mit diesem Schritt sucht sie nur dort, wo es tatsächlich relevant ist. Nach unserer Erfahrung halbiert das die False Positives mindestens (Schätzung).

Der gesamte Workflow passt in acht Zeilen:

12345678INPUT:  Unternehmensprofil (Branche, Jurisdiktion, Größe, Datentypen)
STEP 1: Graph-Abfrage → anwendbare Regulierungen filtern       [deterministisch]
STEP 2: Graph-Abfrage → zugehörige Kontrollen laden            [deterministisch]
STEP 3: Vektorsuche → interne Policies auf Kontrollen mappen   [probabilistisch]
STEP 4: Semantische Verifikation → Kontroll-Status klassifizieren [probabilistisch]
        (compliant | partial | gap | not applicable)
STEP 5: Risikobewertung → Lücken priorisieren                  [probabilistisch]
OUTPUT: Strukturierter Compliance-Report mit Evidence Chain

Die Tags zeigen es deutlich: Entscheidung 1 legt fest, welche Technologie wohin gehört. Schritt 1 und 2 sind Graph-Abfragen ohne LLM. Ab Schritt 3 trägt KI bei, aber mit strukturierten Outputs und vorgegebenen Klassifikationskategorien.

Wann braucht ein Compliance-System Agenten, und wann reicht eine Pipeline?

Die dritte Entscheidung wird am häufigsten falsch beantwortet.

Eine Pipeline folgt einer festen Sequenz von Schritten. Ein- und Ausgaben sind strukturiert. Ergebnisse sind reproduzierbar. Dieselbe Frage zweimal gestellt liefert dieselbe Antwort. Für die meisten Compliance-Aufgaben ist das genau richtig.

Ein Agent trifft Runtime-Entscheidungen. Er wählt, welcher Schritt als nächstes ausgeführt wird, welche Datenquellen er kombiniert, wann er aufhört. Das ist mächtig, und für bestimmte Aufgaben nötig. Für viele Compliance-Aufgaben ist es unnötig riskant. Eine Google-DeepMind/MIT-Studie von Dezember 2025 quantifiziert das: Multi-Agenten-Systeme kosten pro gelöster Aufgabe ein Vielfaches von Single-Agenten, bei schlechteren Ergebnissen⁵.

„Welche Regulierungen gelten für dieses Unternehmen?" ist eine deterministische Graph-Abfrage. Kein Agenten-Problem. „Analysiere diese 200-seitige Policy gegen 42 Kontrollen, identifiziere Lücken, priorisiere nach Business-Risiko und schlage Policy-Änderungen vor" ist ein mehrstufiges Problem, bei dem Zwischenergebnisse den nächsten Schritt formen. Hier verdienen Agenten ihren Platz.

Selbst dann ist der richtige Ansatz: orchestrierte Workflows mit definierten Schritten und menschlichen Freigabe-Gates. Keine autonomen Loops, in denen ein Agent alles zur Laufzeit entscheidet. Frameworks wie LangGraph stellen durable StateGraphs mit Checkpointing und Human-in-the-Loop-Gates zur Verfügung⁶. Ein Compliance-Agent braucht Checkpoints nach jedem Schritt, menschliche Freigaben vor risikoreichen Entscheidungen und einen Audit-Trail, der dokumentiert, warum jede Entscheidung so getroffen wurde.

Der Unterschied zwischen einem Marketing-Chatbot und einem Compliance-System lässt sich auf eine Frage reduzieren: Ist jeder Zwischenschritt nachvollziehbar und auditierbar? Ein autonomer Agent, der alles allein entscheidet, ist ein Risiko, das kein Compliance Officer abnimmt. Laut Branchenauswertung qualifizieren sich nur 16 Prozent aller Enterprise-Deployments als echte Agenten (Systeme, die planen, ausführen, beobachten und anpassen). Der Rest sind, im Wortlaut der Autoren, „glorifizierte Chatbots mit einem API-Call"¹.

Wie prüft eine KI-Compliance-Architektur Nachweise in sechs Schritten?

Die Architekturentscheidungen aus den vorigen Abschnitten geben den Rahmen. Die Nachweisprüfung zeigt, wie dieser Rahmen in der Praxis arbeitet. In einer auditfesten KI-Compliance-Architektur durchläuft jeder Compliance-Datensatz sechs klar definierte Schritte. Die Brücke dazwischen ist die „Common Control"-Ebene: Sie übersetzt zwischen ISO 27001 A.9.4.2, SOC 2 CC6.1 und DORA Art. 9, die alle Zugangskontrolle fordern, aber in unterschiedlicher Formulierung. Ohne diese Abstraktionsschicht müssen Sie jedes Framework einzeln gegen jede Policy matchen. Mit der Schicht matchen Sie einmal und bekommen die Abdeckung über alle Frameworks.

1. Nachweis hochladen. Das Dokument wird ins System geladen und bekommt eine eindeutige ID für den Audit-Trail.
2. Relevante Informationen extrahieren. Entweder aus strukturierten Feldern oder per OCR, je nach Dokumenttyp. Metadaten wie Ausstellungsdatum, Aussteller und Gültigkeitszeitraum werden erfasst.
3. Vollständigkeit und Format prüfen. Fehlende Unterschrift? Datum in der Zukunft? Datei unlesbar? Alles strukturell Defekte wird hier herausgefiltert.
4. Über den Graphen einer Kontrolle zuordnen. Das System ordnet den Nachweis über den Knowledge Graph einer konkreten Kontrolle zu: welche Regulierung, welche Anforderung, welcher Kontrollpunkt?
5. Freshness-Check. Ist der Nachweis noch gültig? Ein Pen-Test-Zertifikat von 2023 beweist nicht, dass die Systeme von 2026 sicher sind. Abgelaufene Nachweise verschieben den Status von compliant auf partial.
6. Status-Klassifikation. Das System klassifiziert den Nachweis als compliant, partial, gap oder not applicable und schreibt das Ergebnis mit Begründung in den Audit-Trail.

Jeder dieser sechs Schritte erzeugt einen Audit-Trail-Eintrag. Freshness ist hier eine harte Bedingung, kein optionaler Filter. Automatische Freshness-Checks sind die Stelle, an der KI-Systeme operativ den größten Unterschied machen, weil kein Compliance-Team mit 200 Nachweisen manuell hinterherkommt.

Datensouveränität ist im Mittelstand nicht verhandelbar. Regulatorische Texte (DORA, ISO 27001, EU AI Act) sind öffentlich und können in einer Cloud verarbeitet werden. Interne Policies, Nachweise und Risikobewertungen sind vertraulich. Ein 200-Personen-Unternehmen schickt seine internen Audit-Dokumente nicht in eine US-Cloud. Eine KI-Compliance-Architektur muss hybrid deploybar sein: öffentliche Daten in der Cloud, vertrauliche Daten on-premise oder in einem EU-Rechenzentrum.

Wo die echte Komplexität sitzt

Die größte Überraschung in unserem Projekt war der initiale Aufbau des Knowledge Graphs. Mehr Aufwand als Modelle, Vektorsuche und Orchestrierung zusammen.

Jedes regulatorische Dokument muss von einem LLM verarbeitet werden, um Entitäten (Regulierungen, Anforderungen, Kontrollen) und ihre Beziehungen zu extrahieren. Das kostet Geld. Realistische Spanne: 40 bis 80 Euro pro Dokument (Schätzung). Bei einem Starter-Set von 70 Dokumenten sind Sie bei 2.000 bis 5.000 Euro, bevor die erste Abfrage läuft. Diese Zahl taucht in keinem Tutorial auf, das ich gelesen habe.

Zweite Überraschung: Ontologie-Qualitätssicherung. Automatisch extrahierte Beziehungen sind nicht immer korrekt. Ein LLM interpretiert eine Empfehlung als Pflicht oder verknüpft eine Kontrolle mit der falschen Anforderung. Manuelle Prüfung ist Pflicht und keine einmalige Aufgabe. Regulierungen ändern sich, neue Frameworks kommen, bestehende Beziehungen müssen aktualisiert werden. Das ist ein laufender Prozess, der eine eigene Kapazität braucht.

Die dritte Erkenntnis hat uns überrascht. Wir formulieren regulatorische Anforderungen jetzt als testbare Aussagen. „GIVEN protocol is TCP AND port is 22, WHEN evidence is evaluated, THEN action must be DROP." Das klingt wie Software-Tests, weil es Software-Tests sind. Die Juristen im Team schreiben inzwischen selbst Tests. Kein Witz. Compliance-Anforderungen als formale Testfälle zu formulieren erzwingt eine Präzision, die natürliche Sprache allein nicht liefert.

Unsere Einordnung

Die Framework-Frage ist die falsche erste Frage.

Wer mit „sollen wir LangGraph oder CrewAI nehmen?" anfängt, überspringt die drei Entscheidungen, die diesen Artikel tragen. Die richtige erste Frage lautet: Welche Teile meines Systems müssen deterministisch liefern?

Sobald Sie das beantwortet haben, wissen Sie, wo ein Knowledge Graph hingehört, wo die Vektorsuche reicht und wo ein LLM echten Mehrwert schafft. Die Framework-Wahl ergibt sich dann fast von selbst.

Was wir bei Ethenios gelernt haben, ist eine organisatorische Erkenntnis. Architekturentscheidungen wiegen schwerer als Tool-Entscheidungen. Eine modulare, sauber entworfene KI-Compliance-Architektur funktioniert mit LangGraph, mit CrewAI oder mit einem selbst gebauten Orchestrator. Die falsche Architektur fällt mit jedem Framework durch. Genauer: Sie fällt bei dem ersten Auditor durch, der sagt: „Zeigen Sie mir die Evidence Chain."

Für den Mittelstand ist das eine gute Nachricht. Aktuelle Zahlen zeigen, dass 36 Prozent der Mittelständler mit 50 und mehr Beschäftigten heute KI einsetzen, gegenüber sechs Prozent im Zeitraum 2016 bis 2018⁷. Die meisten sind früh genug im Prozess, um Architekturfragen vor dem Produktivbetrieb zu klären. Gegenüber Konzernen hat der Mittelstand hier reale Vorteile: schnellere Entscheidungen, weniger Legacy, weniger parallele Initiativen, die sich gegenseitig blockieren.

In Teil 3 zeigen wir, wie eine Framework-Bewertung aussieht, wenn diese drei Entscheidungen bereits getroffen sind. Das Ergebnis unterscheidet sich deutlich von den üblichen Vergleichstabellen, weil wir nach Kriterien bewerten, die dort fehlen: Auditierbarkeit, Checkpoint-Fähigkeit und Nachvollziehbarkeit jedes Zwischenergebnisses.

Wenn Sie Ihre KI-Compliance-Architektur auf den Prüfstand stellen wollen, starten wir mit einem 30-minütigen Readiness-Check. Wir identifizieren, welche Ihrer Compliance-Prozesse deterministisches Ergebnis brauchen und wo KI den größten Hebel liefert.

Quellen

Sie haben Fragen zu diesem Thema?