Wie Sie Retrieval-Augmented Generation (RAG) in einem regulierten Unternehmen einführen

Ein produktionsreifes RAG-System in regulierter Umgebung wird als Folge gesteuerter Phasen entworfen, nicht als einzige Pipeline. Jede Phase erzeugt ein Artefakt, das eine interne Revision oder eine externe Aufsicht später prüfen kann.

1. Quellkorpus-Governance. Klassifizieren Sie jedes Dokument nach Sensitivität, Lokalisierung und Aufbewahrung, bevor es in den Index gelangt. Führen Sie einen schriftlichen Datenkatalog, dokumentieren Sie Herkunft und Rechtsgrundlage nach Artikel 6 DSGVO und schliessen Sie besondere Datenkategorien aus, sofern keine ausdrückliche Bedingung nach Artikel 9 vorliegt. Nach Artikel 17 zur Löschung markierte Dokumente müssen sich innerhalb des vertraglichen Fensters aus dem Index entfernen lassen.
2. Chunking- und Embedding-Strategie. Wählen Sie Chunkgrösse und Überlappung pro Dokumenttyp, nicht global. Regulierungstexte, Verträge und klinische Leitlinien profitieren von semantischem Chunking, das Klausel- und Abschnittsgrenzen respektiert; Transaktionsprotokolle profitieren von festen Fenstern. Hinterlegen Sie zu jedem Vektor die Version des Embedding-Modells, damit Re-Embedding ausgelöst werden kann, wenn ein Modell veraltet oder ein Regulierungstext überarbeitet wird.
3. Auswahl des Vektorspeichers. Wählen Sie einen Speicher, der in EU-Regionen läuft, ruhende Daten mit kundenseitig verwalteten Schlüsseln verschlüsselt, eine Liste der Unterauftragnehmer veröffentlicht und Zugriffskontrolle pro Mandant oder Dokument unterstützt. Prüfen Sie die ISO/IEC-27001- und, wo verfügbar, die ISO/IEC-42001-Attestierungen des Anbieters [3].
4. Evaluation des Retrievals. Bauen Sie ein Ground-Truth-Set aus realen, von Fachexperten beantworteten Fragen. Messen Sie recall@k, Mean Reciprocal Rank und Context Precision, bevor ein LLM-Endpunkt angeschlossen wird. Eine Retrieval-Schicht, die nicht die richtigen Chunks liefert, wird auch durch einen besseren Generator nicht gerettet.
5. Generierung mit erzwungener Zitation. Beschränken Sie die Orchestrierungsschicht so, dass jede Ausgabe mindestens einen abgerufenen Chunk zitiert und ungrounded-Antworten verworfen oder zur Prüfung markiert werden. Die Stanford-CRFM-Literatur zur Verankerung zeigt, dass erzwungene Zitation Halluzinationen gegenüber freier Generierung deutlich reduziert [4].
6. Human-in-the-Loop für regulierte Entscheidungen. Jede Ausgabe, die eine betroffene Person wesentlich betrifft, muss vor Wirksamwerden über einen qualifizierten Prüfer laufen. Das ist die operative Lesart von Artikel 22 DSGVO und Artikel 14 EU-KI-Verordnung und in Kreditvergabe, Versicherungs-Underwriting, klinischer Triage oder Leistungsentscheidungen nicht optional [1][2].
7. Kontinuierliches Evaluations-Harness. Führen Sie Tests zu Faithfulness, Antwortrelevanz und Zitationsvollständigkeit bei jedem Release aus. Verfolgen Sie Drift im Embedding-Modell, im Quellkorpus und in den Veröffentlichungen der Aufsicht. Behandeln Sie regulatorische Aktualisierungen wie Code-Releases: wenn EBA, EIOPA, ENISA oder das AI Office veröffentlichen, werden Korpus und Tests in derselben Woche aktualisiert [6][7].

Die Architektur ist gleich, die Pflichten sind es nicht. Eine regulierte Bereitstellung muss jederzeit darlegen können, wie jede Ausgabe entstand und wie jede Designentscheidung begründet ist.

• Artikel 9 EU-KI-Verordnung verlangt ein dokumentiertes Risikomanagementsystem über den gesamten Lebenszyklus eines Hochrisikosystems mit ausdrücklicher Identifikation, Bewertung und Minderung absehbarer Risiken [1].
• Artikel 5 DSGVO Datenminimierung greift bereits im Retrieval-Schritt. Die Pipeline darf keine personenbezogenen Daten abrufen, die der Generator nicht benötigt; die richtigen Stellschrauben sind Filter zur Abfragezeit und rollenbasierte Zugriffsbereiche.
• Artikel 32 DSGVO Sicherheitspflichten umfassen Verschlüsselung in Transit und at Rest, granulare Zugriffskontrolle, unveränderbare Audit-Logs und getestete Incident Response. Die Logs müssen ausreichen, um jede einzelne Antwort zu rekonstruieren.
• Artikel 35 DSGVO verlangt eine Datenschutz-Folgenabschätzung vor der produktiven Inbetriebnahme, wann immer die Verarbeitung wahrscheinlich ein hohes Risiko für Betroffene mit sich bringt. Bei generativen Systemen mit Personenbezug ist das die Standardannahme.
• Artikel 22 zusammen mit Artikel 14 EU-KI-Verordnung kodifiziert die menschliche Aufsicht: ein kompetenter Prüfer mit Befugnis und Information zur Übersteuerung des Systems gehört bei wesentlichen Entscheidungen in den Loop.
• Sektorale Auflagen. Banken-Deployments müssen SR 11-7 zur Modellrisiko-Governance erfüllen, einschliesslich unabhängiger Validierung und laufender Überwachung. Versicherungs-Deployments fallen unter EIOPA-Leitlinien und Säule 2 von Solvency II. Gesundheits-Deployments, die klinische Entscheidungen unterstützen, müssen die Medizinprodukte-Verordnung einhalten und für geschützte Gesundheitsdaten HITRUST oder gleichwertige Kontrollen umsetzen [6].

Fünf Fehlerbilder treten in Audits produktiver RAG-Systeme regelmässig auf, jedes ist mit dem richtigen Test im Evaluations-Harness vermeidbar.

• Stiller Verlust der Verankerung. Ein Quelldokument wird aktualisiert, alte Vektoren bleiben im Index, das System zitiert weiterhin eine veraltete Passage. Massnahme: jeder Chunk trägt einen Content-Hash und eine Quelldokument-Version, veraltete Vektoren werden beim Ingest entfernt.
• Embedding-Drift bei regulatorischen Revisionen. Wenn die Aufsicht einen Schlüsseltext ändert, liegt das Embedding des neuen Abschnitts an einem anderen Punkt im Vektorraum. Massnahme: geplantes Re-Embedding bei regulatorischen Veröffentlichungen mit Paritätstest gegen den Vorindex.
• Re-Ranker maskiert die Zitation. Ein Re-Ranker hebt einen Chunk mit hoher Ähnlichkeit, aber geringer Autorität an, und die Zitation zeigt nicht mehr auf das Dokument, auf das sich die Antwort tatsächlich stützte. Massnahme: rangbewusstes Citation-Logging, das jeden für die finale Antwort relevanten Chunk dokumentiert.
• Prompt Injection über hochgeladene Dokumente. Ein Nutzer lädt ein PDF hoch, dessen Inhalt versucht, die Systeminstruktion zu überschreiben. Massnahme: untrusted Content auf Orchestrierungsebene von Anweisungen trennen, Uploads sanitisieren und der ENISA-Leitlinie zur Bedrohungsmodellierung folgen [7].
• Cross-Tenant-Leakage im Retrieval. Ein fehlkonfigurierter Filter liefert Chunks aus einem anderen Mandanten oder einer anderen Abteilung. Massnahme: Mandanten-IDs als verpflichtendes Prädikat jeder Abfrage, automatisierte Tests mit adversarialen Anfragen und Index-Isolation pro Mandant für die sensibelsten Korpora.

Evaluation ist in regulierter Umgebung eine kontinuierliche Engineering-Praxis, kein Launch-Checkpoint. Die minimale Metrik-Matrix hat sechs Dimensionen.

• Faithfulness. Anteil der generierten Aussagen, die durch den abgerufenen Kontext gestützt sind. Gemessen gegen ein gelabeltes Ground-Truth-Set.
• Antwortrelevanz. Ob die Antwort tatsächlich die Frage des Nutzers adressiert und nicht eine Tangente.
• Context Precision und Recall. Ob der Retriever die richtigen Chunks und nur die richtigen Chunks ausgespielt hat.
• Zitationsvollständigkeit. Ob jede wesentliche Aussage in der Antwort auf eine konkrete abgerufene Passage verweist.
• Latenz bei p95. Ein regulierter Workflow, der im Human-Review-Schritt aussteigt, ist unbrauchbar; das Latenzbudget muss Orchestrierung, Retrieval, Generierung und alle Guardrails einschliessen.
• Kosten pro Abfrage. Erfasst je Intent-Klasse, damit das Geschäft entscheiden kann, wo das System eingesetzt und wo ein deterministischer Lookup günstiger ist.

Open-Source-Frameworks für RAG-Evaluation sind so weit gereift, dass regulierte Käufer diese Metriken in der Continuous Integration ausführen können. Frameworks unterscheiden sich im Bewertungsmodell und im Reporting; entscheidender als die Wahl ist die Disziplin, sie bei jedem Release auszuführen [4].