Regulatory-Change-RAG mit GraphRAG: DORA, NIS2, AI Act, MaRisk

Pexon Consulting | 11 Min. Lesezeit | 13.06.2026

TL;DR

Regulatory Change RAG ist 2026 das härteste RAG-Problem in regulierten Branchen: Eine Regulator-Aktualisierung (DORA, NIS2, AI Act, MaRisk) ändert nicht nur den Text einer Norm — sie löst eine Kette von Folge-Fragen aus: Welche internen Controls sind betroffen, welche Policies hängen an den Controls, wer ist Owner der Policy, wann muss er aktualisieren. Klassisches Vector-RAG kann diese Multi-Hop-Beziehungen strukturell nicht abbilden. GraphRAG mit explizitem Knowledge Graph schafft das. Pexon Consulting baut solche Setups für Banken, Versicherer und KRITIS-Betreiber.

Warum Regulatory Change so hart ist

Wir hören das aktuell in fast jedem CISO-Erstgespräch bei Banken und Versicherern: Mit DORA seit Januar 2025, NIS2-Umsetzung, EU AI Act ab August 2026 und MaRisk-Aktualisierungen kommen alle paar Wochen Regulator-Änderungen ins Haus. Die Compliance-Abteilung soll bewerten, was die Änderungen für das eigene Haus bedeuten — und scheitert strukturell.

Das Problem ist nicht „lesen können“ — die Compliance-Profis lesen die Texte. Das Problem ist die Multi-Hop-Frage: Wenn DORA Artikel 5 die Anforderungen an ICT-Risikomanagement verschärft, welche unserer 280 internen Controls sind betroffen, welche der 47 Policies hängen an diesen Controls, welche der 18 Process Owner müssen ihre Policies aktualisieren, bis wann.

Bei einem Pilotkunden im Versicherungsbereich hat die manuelle Beantwortung dieser Frage pro Regulator-Änderung im Schnitt 22-38 Stunden gekostet — Compliance-Officer arbeitet sich durch die interne Doku, vergleicht händisch, schreibt Action-Listen. Bei 8-12 Regulator-Änderungen pro Jahr sind das 200-450 Stunden allein für die Impact-Analyse, ohne die eigentliche Umsetzungs-Arbeit.

Klassisches Vector-RAG hilft hier nur teilweise. Es findet die relevante Regulator-Klausel („welcher Abschnitt der DORA spricht über ICT-Risikomanagement“). Aber die Beziehung „diese DORA-Klausel hängt an diesen Controls, die hängen an diesen Policies, die haben diese Owner“ ist strukturell — sie ist nicht in einzelnen Dokument-Chunks gespeichert, sondern in den expliziten Beziehungen zwischen Entitäten.

Was GraphRAG anders macht

GraphRAG, ursprünglich von Microsoft Research 2024 populär gemacht, kombiniert klassische Vector-Retrieval mit einem expliziten Knowledge Graph. Statt nur Dokument-Chunks zu indizieren, werden auch die Entitäten (Regulation-Klausel, Control, Policy, Owner) plus ihre Beziehungen modelliert.

Bei einer Anfrage „DORA Artikel 5 wurde aktualisiert, was bedeutet das“ macht GraphRAG zwei Dinge parallel. Erstens, Vector-Retrieval findet den DORA-Klausel-Text. Zweitens, Graph-Traversal folgt den expliziten Beziehungen: Regulation-Klausel → Control → Policy → Owner. Das LLM bekommt beide Informationen — den Text der Klausel UND die Liste der konkret betroffenen Owner.

Konkret bei einem unserer Banking-Kunden: GraphRAG findet bei einer DORA-Änderung in unter 15 Sekunden die 6-12 betroffenen Controls, die 3-5 betroffenen Policies und die 2-3 Owner — mit klarer Begründung pro Verbindung. Ein Compliance-Officer würde dafür Tage brauchen.

Die Graph-Struktur konkret

Wir bauen den Knowledge Graph mit fünf Entitäten-Typen.

Regulation-Klausel. Jede konkrete Klausel einer Norm (DORA Art. 5, MaRisk AT 4.3.1, etc.) ist ein Knoten. Metadaten: Quelle, Version, Inkraftsetzung, Text. Bei Updates wird eine neue Version als zusätzlicher Knoten angelegt, die alten Versionen bleiben mit Versionierungs-Beziehung.

Control. Interne Kontrolle, die regulatorische Anforderungen umsetzt. Beispiel: „ICT-Risk-Identification-Process“. Metadaten: Verantwortlicher Bereich, Reifegrad, Risikobewertung.

Policy. Schriftliche Policy-Dokumente. Beispiel: „ICT-Risikomanagement-Richtlinie“. Metadaten: Version, Freigabe-Datum, nächste Review.

Process. Geschäftsprozess, in dem die Policy angewendet wird. Beispiel: „Onboarding-Prozess neuer ICT-Dienstleister“.

Owner. Mensch oder Rolle. Beispiel: „Head of ICT Risk Management“.

Beziehungen zwischen den Entitäten:

• Regulation-Klausel --addresses--> Control
• Control --implementedBy--> Policy
• Policy --appliesTo--> Process
• Policy --ownedBy--> Owner

Damit ist die Multi-Hop-Frage als Graph-Traversal gestellt: Start bei Regulation-Klausel, folge addresses zu Controls, dann implementedBy zu Policies, dann ownedBy zu Owners. In SQL wäre das ein 4-fach-Join, in einem Graph-DB-System (Neo4j, Memgraph) eine einfache Cypher-Query.

Architektur-Komponenten

Komponente 1: Initial-Mapping mit LLM-Unterstützung. Beim Aufbau muss der Graph mit den existierenden Entitäten gefüllt werden. Wir nutzen ein Frontier-LLM (Claude Opus 4.7), das die existierenden Regulator-Texte plus die internen Policy- und Control-Dokumente liest und Vorschläge für die Beziehungen macht. Compliance-Profis prüfen und bestätigen — was dauert 80-150 Stunden für die Erstbestückung, ist dann aber das Plattform-Asset.

Komponente 2: Inkrementelles Update bei Regulator-Änderungen. Wenn ein neuer Regulator-Text reinkommt, parst ein Pipeline-Lauf die Änderungen, schlägt neue oder geänderte Beziehungen vor. Compliance-Officer prüft und bestätigt. Damit wächst der Graph kontinuierlich.

Komponente 3: Query-Engine mit Vector + Graph. Bei einer Anfrage werden parallel Vector-Retrieval auf die Dokument-Texte und Graph-Traversal auf den Knowledge Graph ausgeführt. Das LLM bekommt beide Outputs als Kontext und synthetisiert die Antwort.

Komponente 4: Audit-Trail und Versionierung. Jede Graph-Modifikation wird mit Datum, User und Begründung versioniert. Bei einem Regulator-Audit kann nachvollzogen werden, wann welche Beziehung wie modelliert war.

Vier konkrete Use-Cases

Use-Case 1: Impact-Analyse bei Regulator-Aktualisierung. Compliance-Officer bekommt eine BaFin-Rundschreiben-Aktualisierung. Frage an das System: „Was sind die Auswirkungen“. Output: Konkrete Liste betroffener Controls, Policies, Owner plus geschätzte Updates-Zeitlinie.

Use-Case 2: Vollständigkeits-Check. Vor jedem internen Audit: „Welche unserer Policies sind seit über 18 Monaten nicht aktualisiert und betreffen DORA-relevante Controls“. Graph-Traversal plus Datums-Filter — 30 Sekunden statt 4 Tage manueller Recherche.

Use-Case 3: Owner-Identifikation bei neuer Vorgabe. Eine neue EU-AI-Act-Klausel kommt rein. Wer in unserem Haus muss das adressieren. Klassische Antwort: „Compliance schickt rundrum, jeder schaut, ob er betroffen ist“. Mit GraphRAG: gezielter Routing an die 2-5 konkret betroffenen Owner mit dokumentierter Begründung.

Use-Case 4: Cross-Regulation-Konflikt-Erkennung. Wenn DORA verschärft, NIS2 anders interpretiert und MaRisk noch anders argumentiert — wo gibt es Inkonsistenzen in unseren internen Policies. Graph-Query identifiziert Controls, die mehrere Regulator-Klauseln gleichzeitig adressieren, plus Inkonsistenz-Marker.

Pexon-Sprint-Setup

Wir liefern Regulatory-Change-RAG als 12-16-Wochen-Sprint für regulierte Mittelständler.

Wochen 1-3: Workshop mit Compliance, Risk, IT-Sicherheit. Festlegung der einbezogenen Regulationen, der internen Doku-Quellen, der Graph-Struktur. Plattform-Aufbau (Neo4j oder Memgraph plus Vector-DB plus LangGraph-Orchestrierung).

Wochen 4-8: Initial-Befüllung des Knowledge Graph mit LLM-Unterstützung. Compliance-Officer-Review pro Beziehungs-Vorschlag. Aufbau der Query-Engine.

Wochen 9-12: Roll-out an die Compliance- und Risk-Funktionen. Eval gegen historische Regulator-Änderungen. Schulung der Power-User.

Wochen 13-16: Produktive Nutzung, Feedback-Loop für Graph-Verbesserung, Übergabe inkl. Pflege-Konzept.

Investment 165-260k EUR je nach Anzahl Regulationen und Doku-Tiefe. Bei Banking mit MaRisk-Komplexität tendenziell teurer, bei reinen NIS2-Setups günstiger.

Häufig gestellte Fragen

Wie unterscheidet sich GraphRAG von klassischen Compliance-Tools wie ServiceNow GRC?

Klassische GRC-Tools haben Datenmodelle für Controls, Policies, Risks — aber die Verbindung zu den Regulator-Texten ist manuell und statisch. GraphRAG fügt die KI-basierte automatische Verbindungslogik plus die natürlich-sprachliche Abfrage hinzu. Wir integrieren oft direkt in eure GRC-Plattform statt eine neue Insel zu bauen.

Was, wenn der Knowledge Graph veraltet ist?

Inkrementelle Update-Pipeline läuft kontinuierlich. Bei Regulator-Texten alle 4 Wochen, bei Policy-Änderungen sofort beim Freigabe-Event. Wir bauen einen Compliance-Dashboard, das Graph-Qualität sichtbar macht — „wie viele Controls sind seit 12 Monaten nicht reviewed, wie viele Policies haben keine klare Owner-Beziehung“.

Funktioniert das auch mit unserer Microsoft-Compliance-Center-Architektur?

Ja. Wir integrieren über die Microsoft-Compliance-Center-APIs und Purview-Connectors. Die Graph-Komponente läuft als zusätzlicher Layer, die Bestands-Tools bleiben in Betrieb.

Wie reagiert die Aufsichtsbehörde auf KI-basierte Compliance-Analyse?

BaFin-Position 2025/2026: KI darf bei der Compliance-Arbeit unterstützen, die Entscheidung muss bei der verantwortlichen Person liegen. Unser Setup ist genau das — KI liefert Analyse, Compliance-Officer trifft die Entscheidung. Audit-Trail dokumentiert wer was entschieden hat.

Welche Regulationen können wir einbinden?

Aktuell unterstützt: DORA, NIS2, EU AI Act, MaRisk, BAIT, VAIT, KAIT, KRITIS-Konkretisierung, ISO 27001, IATF 16949. Neue Regulationen können wir typisch in 1-2 Wochen einbinden.

Nächster Schritt

Wenn deine Compliance- oder Risk-Funktion an der Multi-Regulator-Wand steht: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise dem CCO oder CISO. Du beschreibst die Regulator-Last und die interne Doku-Lage, wir skizzieren das GraphRAG-Setup mit Festpreis.

Verwandte Themen