Multi-Hop Compliance-Bots: Vendor-Vertrag × Policy × Vorschrift

Pexon Consulting | 10 Min. Lesezeit | 13.06.2026

TL;DR

Multi-Hop Compliance-Bot ist 2026 die strukturell richtige Antwort auf das Vendor-Risk-Problem in regulierten Branchen: Eine Compliance-Frage wie „Erfüllt dieser Vendor-Vertrag unsere DSGVO-Vorgaben und die DORA-Drittparteien-Anforderungen“ verlangt das Cross-Produkt zwischen drei Doku-Welten — Vendor-Vertrag, interne Policy, externe Vorschrift. Single-Shot-RAG kann das strukturell nicht. Pexon Consulting baut Multi-Hop-Setups für Banken, Versicherer und KRITIS-Betreiber, die diese Compliance-Frage in unter 5 Minuten beantworten.

Warum Single-Shot-RAG strukturell scheitert

Wir hören das aktuell wöchentlich in CCO- und CISO-Erstgesprächen: Eine Compliance-Profil schickt eine Anfrage an den unternehmensinternen Chatbot — „Prüfe, ob der Vendor-Vertrag mit Lieferant X unsere DSGVO-Vorgaben erfüllt“. Der Chatbot antwortet plausibel, aber inkomplett. Die Compliance-Profis nutzen ihn nicht mehr.

Das Problem ist nicht das LLM. Das Problem ist die Frage-Struktur. „Erfüllt Vertrag X die Anforderung Y“ ist keine Single-Lookup-Frage. Sie verlangt:

1. Aus der externen Vorschrift (DSGVO Art. 28, DORA Art. 30 etc.) die konkreten Anforderungs-Klauseln extrahieren.
2. Aus der internen Policy („Vendor-Risk-Management-Richtlinie“) die hauseigenen Mindest-Anforderungen extrahieren.
3. Aus dem Vendor-Vertrag die relevanten Klauseln extrahieren.
4. Die drei Anforderungs-Sets gegeneinander vergleichen.
5. Eine Lücken-Liste mit klarer Verantwortlichkeit produzieren.

Single-Shot-RAG kann Schritt 1 oder 2 oder 3, aber nicht alle drei plus den Vergleich. Wer das probiert, bekommt plausible Halbantworten, die Compliance-Profis nicht audit-tauglich finden.

Was Multi-Hop strukturell tut

Architektur in drei Schichten.

Schicht 1: Drei separate Retrieval-Räume. Jede der drei Doku-Welten — Vorschriften, Policies, Verträge — hat ihren eigenen Index. Bei einer Anfrage werden parallel alle drei Räume durchsucht, mit anfrage-spezifischen Filtern.

Schicht 2: Knowledge Graph als Verbindungs-Layer. Pro Doku-Welt werden die Klauseln als Entitäten extrahiert. Verbindungen zwischen Entitäten:

• Vorschriften-Klausel --addressedBy--> Policy-Klausel
• Policy-Klausel --implementedBy--> Vertrags-Klausel
• Vertrags-Klausel --fulfills--> Vorschriften-Klausel

Damit kann das System die „Erfüllt Vertrag X die Anforderung Y“ Frage als Multi-Hop-Traversal beantworten.

Schicht 3: Lücken-Analyse-Logik. Pro Vorschriften-Klausel wird geprüft, ob es eine verbundene Vertrags-Klausel gibt, die sie erfüllt. Lücken werden klar markiert: „DSGVO Art. 28 Abs. 3 lit. h verlangt Audit-Recht — Vendor-Vertrag enthält keine entsprechende Klausel. Empfehlung: Klausel ergänzen.“

Mit der Knowledge-Graph-Verbindung läuft das in unter 5 Minuten, gegenüber 4-12 Stunden manuelle Compliance-Profil-Arbeit pro Vendor-Vertrag.

Use-Case-Beispiel: DSGVO-Vendor-Audit

Konkretes Beispiel aus einem Pilotkunden. Mittelständische Versicherung mit etwa 380 Vendor-Verträgen, davon 47 mit personenbezogenen Daten als Verarbeitungs-Inhalt.

Frage: „Prüfe alle 47 DPA-relevanten Vendor-Verträge gegen die aktuellen DSGVO-Anforderungen plus unsere interne Vendor-Risk-Policy“.

Multi-Hop-Workflow:

Schritt 1: Bot lädt alle 47 Verträge aus dem Vendor-Management-System.

Schritt 2: Pro Vertrag wird die Multi-Hop-Analyse ausgeführt — alle DSGVO-Art-28-Anforderungen plus alle internen Policy-Anforderungen plus die Vertrags-Klauseln werden gegeneinander gemappt.

Schritt 3: Output ist eine strukturierte Liste pro Vertrag mit den konkreten Lücken plus Vorschlag zur Klauselformulierung pro Lücke.

Schritt 4: Compliance-Profil prüft Output, schickt die Vertragsverlängerungs-Anforderungen mit den vorgeschlagenen Klausel-Ergänzungen an die Vendoren.

Vorher: 47 Verträge × 4-6 Stunden Prüfung = 188-282 Stunden, also rund 6 Wochen Vollzeit. Nachher: 5 Stunden Bot-Lauf plus 35-50 Stunden Compliance-Review. Faktor 4-6 schneller.

Drei Use-Cases für Multi-Hop Compliance-Bots

Use-Case 1: Vendor-Vertrag gegen DSGVO/DORA prüfen. Wie oben beschrieben. Häufigster Einsatz bei Banken, Versicherern und KRITIS-Betreibern.

Use-Case 2: Interne Policy gegen externe Vorschrift abgleichen. „Erfüllt unsere ISMS-Policy die aktuellen NIS2-Vorgaben“. Multi-Hop verbindet jede NIS2-Anforderung mit den zugehörigen Policy-Klauseln und identifiziert die Lücken.

Use-Case 3: Vertragsänderung-Impact-Analyse. „Wir wollen Klausel X im Standard-Vendor-Vertrag ändern. Welche Vorschriften und Policies sind betroffen“. Reverse-Multi-Hop ausgehend vom Vertrag.

Pexon-Sprint für Multi-Hop Compliance-Bot

Wir liefern das als 12-16-Wochen-Sprint. Lieferumfang: Indexierung der drei Doku-Welten, Knowledge-Graph-Aufbau mit den Verbindungen, Multi-Hop-Query-Engine, Lücken-Analyse-Output-Formatter, Anbindung an euer Vendor-Management-System (typisch ServiceNow GRC, OneTrust oder eigene Lösung), Schulung der Compliance-Profis.

Investment 195-285k EUR je nach Anzahl Vorschriften und Doku-Tiefe.

Häufig gestellte Fragen

Wie unterscheidet sich das vom Regulatory-Change-RAG?

Regulatory-Change-RAG fokussiert auf „wenn sich eine Vorschrift ändert, wer in meinem Haus muss reagieren“ — Mapping Vorschrift zu interner Owner. Multi-Hop Compliance-Bot fokussiert auf „erfüllt dieser konkrete Vertrag die Anforderungen“ — Mapping Vertrag zu Vorschrift via Policy. Beide nutzen Knowledge Graph, adressieren aber unterschiedliche Compliance-Fragen. Mehr im Regulatory-Change-Blog.

Was, wenn unsere Vendor-Verträge inkonsistent strukturiert sind?

Häufige Realität. Wir nutzen die Indexierungs-Phase auch als Strukturierungs-Cleanup — der LLM erkennt Klausel-Typen unabhängig vom konkreten Format, mappt auf die kanonischen Anforderungen. Verträge werden nicht umgeschrieben, aber strukturiert verstanden.

Wer ist verantwortlich für die finale Compliance-Entscheidung?

Immer der Mensch — Compliance-Profil oder Legal. Der Bot liefert Vorschläge und Lücken-Analyse, die Entscheidung liegt bei der zuständigen Person. Audit-Trail dokumentiert, wer was entschieden hat.

Funktioniert das auch mit unseren englischsprachigen Verträgen?

Ja. Multilingual-Setup ist Standard. Englische Verträge gegen deutsche Vorschriften und Policies werden über das gemeinsame semantische Verständnis der Modelle gemappt.

Wie integriert sich das in unsere bestehende GRC-Plattform?

Über die Standard-APIs der GRC-Plattform (ServiceNow GRC, OneTrust, LogicGate). Die Multi-Hop-Engine läuft als zusätzlicher Service, Lücken-Liste wird in eure GRC-Plattform als Action-Items eingespielt.

Nächster Schritt

Wenn deine Compliance-Funktion unter dem Vendor-Risk-Druck steht und Multi-Hop-Fragen manuell bearbeitet: Wir machen einen 60-Minuten-Call mit dir und idealerweise dem CCO oder Compliance-Officer. Du beschreibst die Vendor-Landschaft und Vorschriften-Stack, wir skizzieren das Setup mit Festpreis.

Verwandte Themen