Vesster
Alle Insights
Architektur15. Aug. 20266 Min. Lesezeit

RAG ist keine Governance: Retrieval in regulierten Umgebungen

Retrieval erdet eine Antwort in Ihren Dokumenten. Es macht sie nicht konform. In einer regulierten Umgebung braucht RAG dieselbe Governance wie jede Agentenaktion.

RAG ist keine Governance: Retrieval in regulierten Umgebungen

Retrieval-augmented Generation hat sich ihre Beliebtheit ehrlich verdient. Statt einem Modell zu vertrauen, dass es eine Tatsache aus seinen Gewichten erinnert, holen Sie die passende Passage aus Ihren eigenen Dokumenten und geben sie dem Modell als Kontext. Die Antwort ist in Ihrem Material verankert, Halluzination sinkt, und Sie können auf die Quelle zeigen. Für einen Wissensdatenbank-Chatbot reicht das oft.

Nur sind in einer regulierten Umgebung eine gegroundete und eine konforme Antwort nicht dasselbe, und sie gleichzusetzen gehört zu den teureren Fehlern, die ein ernsthaftes Team machen kann. Retrieval steuert, was das Modell liest. Es sagt nichts darüber, was das Modell lesen darf, ob die gelesene Quelle aktuell war, ob die Passage echt war oder ob die resultierende Entscheidung überhaupt an einen Menschen hätte gehen müssen. RAG ist eine Grounding-Technik. Governance ist eine andere Disziplin, und RAG enthält sie nicht.

Die unbequeme Fassung der These lautet: RAG lässt eine Antwort autoritativ aussehen, ohne sie verantwortlich zu machen. Eine Zitation neben einer falschen oder unzulässigen Antwort repariert die Antwort nicht. Sie wäscht sie und kleidet eine ungovernte Ausgabe in den Anschein von Provenienz. In einem regulierten Prozess ist das schlimmer als eine offensichtliche Vermutung, denn es besteht das Review, indem es sorgfältig aussieht.

Provenienz ist eine Behauptung, die Sie belegen können müssen

Beginnen Sie bei der Zitation selbst, denn sie ist das Merkmal, dem alle am meisten trauen und das am wenigsten geprüft wird.

Gibt ein RAG-System eine Antwort "basierend auf" einem abgerufenen Chunk zurück, ist die Zitation nur so vertrauenswürdig wie die Installation dahinter. Drei Dinge müssen halten, und keines ist automatisch. Die abgerufene Passage muss die Behauptung tatsächlich tragen, statt ein semantisch ähnlicher Chunk zu sein, den das Modell locker paraphrasiert hat. Das Dokument, aus dem der Chunk stammt, muss die echte, aktuelle Fassung sein, kein abgelöster Entwurf, der zufällig noch im Index lag. Und die Verbindung von Behauptung zu Quelle muss aufgezeichnet sein, nicht im Nachhinein rekonstruiert, indem man das Modell fragt, woher es die Antwort zu haben glaubt.

Der letzte Punkt zählt mehr, als er aussieht. Ein Modell, das seine Quellen zitieren soll, produziert plausible Zitationen, ob es die tatsächlich genutzten Passagen sind oder nicht. Provenienz, die Sie erzeugen, indem Sie das Modell um Erklärung bitten, ist keine Provenienz. Sie ist eine zweite Halluzination mit Fußnote. Echte Provenienz ist eine Nachweisspur, die die Retrieval-Schicht zur Abrufzeit erfasst: diese Anfrage, gegen diese Indexversion, lieferte diese Dokument-IDs, und die Antwort wurde genau daraus erzeugt. Diese Aufzeichnung muss geschrieben werden, bevor die Antwort ausgeliefert wird, nicht zusammengestellt, wenn ein Prüfer fragt.

Der Agent darf nur abrufen, was seine Identität sehen darf

Hier ist der Fehlermodus, der ein hilfreiches RAG-System in einen Compliance-Vorfall verwandelt, und er hat nichts mit Halluzination zu tun.

Die meisten Retrieval-Systeme sind auf Relevanz gebaut, nicht auf Autorisierung. Der Vektorindex hält alles, und der Retriever gibt zurück, was der Anfrage semantisch am nächsten ist. Das ist in einer regulierten Umgebung genau falsch, wo die fragende Instanz bestimmt, was zurückgegeben werden darf. Ein Support-Agent, der einen Korpus abfragt, sollte keine Passage aus einem Dokument abrufen können, für das der Mensch, dem er dient, keine Freigabe hat. Lebt die Zugriffskontrolle aber nur an der Vordertür der Anwendung und nicht im Retrieval, kann eine geschickt formulierte Anfrage eine gesperrte Passage ins Kontextfenster ziehen und von dort in eine Antwort, eine E-Mail oder ein Log.

Zugriffskontrolle muss zur Abrufzeit gegen die eigene Identität des Agenten durchgesetzt werden, nicht nachträglich angeschraubt. Der Agent läuft unter seiner eigenen nicht-menschlichen Identität mit definiertem Scope, und die Retrieval-Schicht filtert die Kandidatenmenge auf das, was diese Identität sehen darf, vor dem Ranking, nicht danach. Die Berechtigungsprüfung ist Teil der Anfrage, kein Nachfilter, um den sich ein Prompt herumreden kann. Alles andere heißt, Ihre Zugriffsregeln gelten überall außer an der einen Stelle, an der das Modell Ihre Daten tatsächlich liest.

Das rahmt Retrieval als Aktion mit Wirkradius, was es ist. Ein Agent, der ein Dokument abruft, übt eine Capability aus, und wie jede Capability sollte sie zugeschnitten, least privilege und protokolliert sein.

Veraltete und vergiftete Korpora sind Drift, die Sie nicht geplant haben

Governance-Leute verstehen bereits, dass ein Modell driftet, wenn es aktualisiert wird. Der Korpus, aus dem ein RAG-System abruft, driftet ebenfalls, und auf Weisen, die leichter zu übersehen sind, weil sich am Modell nichts geändert hat.

Veraltung ist die stille Variante. Ein Policy-Dokument wird abgelöst, aber die alte Fassung bleibt im Index, und das System zitiert selbstbewusst weiter eine Regel, die nicht mehr gilt. Die Antwort ist gegroundet, mit Provenienz versehen und falsch, weil sich der Boden verschoben hat. Regulierte Korpora brauchen dieselbe Lebenszyklusdisziplin wie regulierte Policy: Versionierung, eine Ablauf- und Prüfkadenz und die Garantie, dass ein abgelöstes Dokument aus dem Retrieval entfernt und nicht bloß irgendwo als veraltet markiert wird, wo der Retriever nie nachsieht.

Vergiftung ist die gegnerische Variante. Der Korpus, aus dem ein Agent abruft, wird oft von Inhalten gespeist, die die Organisation nicht verfasst hat: hochgeladene Dokumente, eingelesene E-Mails, Drittfeeds. Kann ein Angreifer Text in diesen Korpus bringen, kann er eine Passage pflanzen, die wie eine Anweisung klingt, und warten, bis der Agent sie abruft. Das ist indirekte Prompt Injection, ausgeliefert durch die Wissensdatenbank selbst, und sie wird wie jede unzuverlässige Eingabe eingedämmt: Die Komponente, die abgerufene Inhalte liest, gilt als Leserin gegnerisch kontrollierter Daten und kann strukturell nicht darauf handeln, als wären sie ein Befehl. Zu kennzeichnen, was in den Speicher geht und was aus dem Retrieval zurückkommt, ist kein Papierkram. So verhindern Sie, dass Ihr eigener Index zur Angriffsfläche wird.

RAG braucht dieselbe Nachweisspur und dasselbe menschliche Gate wie jede Agentenaktion

Legt man die drei Fäden zusammen, ist der Schluss klar. Retrieval ist keine Abkürzung um Governance herum. Es ist eine weitere Agentenaktion, die in denselben Controls sitzen muss wie jede andere.

Das heißt dieselbe Maschinerie, auf der der Rest des Systems läuft. Eine append-only Nachweisspur, die festhält, was abgerufen wurde, aus welcher Indexversion, unter welcher Identität und wie die Antwort abgeleitet wurde, geschrieben bevor die Entscheidung bindet. Zugriff, der zur Abrufzeit gegen die Identität des Agenten durchgesetzt wird. Korpus-Lebenszyklusregeln, die Veraltung sichtbar und Vergiftung eindämmbar machen. Und für folgenschwere Ausgaben dasselbe menschliche Gate: Eine gegroundete Antwort mit regulatorischem Gewicht löst sich zu REQUIRE-HUMAN auf, denn eine Zitation ist ein Beleg für eine Entscheidung, kein Ersatz dafür, sie zu treffen.

Nichts davon spricht gegen RAG. Retrieval gehört zu den nützlichsten Werkzeugen, um einen Agenten im echten Material einer Organisation zu verankern, und die Alternative, ein Modell, das aus seinen Gewichten antwortet, ist auf jeder hier zählenden Achse schlechter. Das Argument richtet sich gegen die stille Annahme, Grounding sei Governance, eine Zitation sei ein Audit-Trail, und ein System, das sorgfältig abruft, sei deshalb ein System, das Sie verteidigen können.

Die Frage für Ihr nächstes Design-Review lautet also nicht "zitiert unser RAG-System seine Quellen?". Sie lautet: kann der Agent nur abrufen, was seine Identität sehen darf, können wir belegen, woher jede Antwort kam, und hält eine gegroundete, aber folgenschwere Antwort trotzdem bei einem Menschen an? Sitzt Retrieval außerhalb Ihrer Governance statt darin, haben Sie etwas gebaut, das verantwortlich aussieht und es nicht ist, und das ist in einem regulierten Prozess das Gefährlichste, was man bauen kann.

Wenn Sie prüfen wollen, wo Retrieval an einem echten Korpus relativ zu Ihrer Governance steht, buchen Sie einen Termin und bringen Sie uns den mit den sensibelsten Dokumenten mit.

Wägen Sie das an einem echten Prozess ab?

Bringen Sie ihn zu uns, und wir geben Ihnen eine direkte Einschätzung, wo ein Agent passt — und wo nicht.