RAG-Systeme im Produktivbetrieb: Woran sie tatsächlich scheitern

Retrieval-Augmented Generation ist einer der praktischsten Wege geworden, generative KI in Unternehmensumgebungen zu bringen. Statt sich auf das zu verlassen, was ein Modell im Training gelernt hat, holt das System Informationen aus der eigenen Wissensbasis der Organisation und stellt diese Belege als Kontext für die Antwort bereit.

Der Prototyp ist meist unkompliziert. Dokumente werden geparst, in Chunks zerlegt, eingebettet, indexiert und abgerufen, wenn ein Nutzer eine Frage stellt. Ein leistungsfähiges Modell macht aus den gefundenen Passagen eine flüssige Antwort, oft mit Quellenangaben. In einer kontrollierten Demo kann das Ergebnis erstaunlich schnell produktionsreif wirken.

Das ist es selten.

Der schwierige Teil von RAG im Produktivbetrieb ist nicht das Erzeugen einer Antwort. Er besteht darin, nachzuweisen, dass das System die richtige Information aus der maßgeblichen Quelle, unter den korrekten Berechtigungen und zum richtigen Zeitpunkt geholt hat — und dass die Organisation rekonstruieren kann, was geschehen ist, wenn eine Antwort angezweifelt wird.

Für allgemeines Unternehmenswissen entscheidet das darüber, ob Nutzer der Plattform vertrauen. Für Behörden, Finanzdienstleistungen, Gesundheitswesen, industriellen Betrieb oder kritische Infrastruktur kann es zur Sicherheits-, Kontinuitäts- und Governance-Anforderung werden.

Retrieval-Fehler wirken oft wie Modellfehler

Wenn eine RAG-Anwendung eine falsche Antwort liefert, wird zuerst oft das Sprachmodell verantwortlich gemacht. In der Praxis kann der Fehler lange vor der Inferenz aufgetreten sein.

Nehmen wir eine mehrfach überarbeitete Betriebsanweisung. Das kontrollierte Dokumentenmanagement enthält die aktuelle Fassung, während eine alte Kopie in einem Projektarchiv liegt, eine Präsentation eine frühere Fassung zusammenfasst und ein Protokoll die Diskussion der geplanten Änderung enthält. Semantisches Retrieval kann sie mit guten Gründen alle für relevant halten.

Wird das veraltete Dokument über das maßgebliche gestellt, kann ein starkes Modell aus den falschen Belegen eine außerordentlich überzeugende Antwort erzeugen.

Deshalb muss die Bewertung im Produktivbetrieb zwischen Retrieval-, Kontext- und Generierungskorrektheit unterscheiden. Hat die Plattform die maßgebliche Quelle geholt? Hat sie genug Umfeld bewahrt, damit diese Quelle richtig gedeutet werden kann? Wurden widersprüchliche oder ersetzte Dokumente erkannt? Erst wenn diese Fragen beantwortet sind, ist es sinnvoll, das Schlussfolgern des Modells zu bewerten.

Ein einzelner aggregierter Wert für „Antwortqualität“ verdeckt zu viel. Ein Retrieval-Fehler verlangt eine andere technische Antwort als eine Halluzination, und beide unterscheiden sich wiederum von einem Fehler durch veraltete Daten oder falsche Berechtigungen.

Auch die Folge zählt. Eine veraltete Kantinenregel zu finden ist lästig. Eine überholte Freischaltanweisung für eine Industrieumgebung oder eine ersetzte behördliche Anweisung zu finden gehört in eine völlig andere Risikoklasse.

Unternehmenswissen braucht eine eigene Architektur

Echtes Organisationswissen kommt nicht als saubere Absätze daher.

Es kommt als komplexe PDFs, Tabellen, Spreadsheets, Scans, technische Zeichnungen, Präsentationen, E-Mail-Verläufe, Vertragsanlagen und doppelte Exporte aus Systemen, die nie für KI-Retrieval gedacht waren. In regulierten Umgebungen trägt die Information zudem oft einen Eigentümer, einen Freigabestatus, eine Aufbewahrungspflicht, eine Vertraulichkeitsstufe, eine Rechtsordnung und eine Gültigkeitsdauer.

All das zu anonymen Textfragmenten einzuebnen zerstört Beziehungen, die für die Deutung wesentlich sein können.

Eine produktive Ingestion-Architektur sollte deshalb die Herkunft bewahren, bevor Embeddings erzeugt werden. Ein Absatz sollte seinem Abschnitt zugeordnet bleiben, der Abschnitt seinem Dokument und das Dokument seiner Version, Quelle, Eigentümerschaft und Autorität. Eine gefundene Tabellenzeile sollte die Überschriften behalten, die ihren Werten Bedeutung geben. Eine Vertragsklausel sollte die Vereinbarung und Version behalten, zu der sie gehört. Eine ersetzte Anweisung sollte nicht gleichrangig mit der freigegebenen aktuellen Fassung konkurrieren, nur weil die Sprache semantisch ähnlich ist.

Auch deshalb gibt es keine allgemeingültig richtige Chunk-Größe. Chunks fester Größe sind bequeme Implementierungseinheiten, aber selten die natürlichen Einheiten organisationalen Wissens. Strukturelles Parsing, hierarchisches Retrieval, Metadaten, Quellengewichtung und Reranking können erheblich mehr ausmachen als die Frage, ob die Vektordatenbank Blöcke von 600 oder 900 Token erhält.

Das eigentliche Ziel sind nicht bessere Embeddings. Es ist, genug von der Informationsarchitektur zu bewahren, damit das Retrieval nicht nur über Ähnlichkeit, sondern auch über Autorität urteilen kann.

Berechtigungsgesteuertes Retrieval ist Teil der Sicherheitsgrenze

Der schwerwiegendste RAG-Fehler ist nicht immer eine falsche Antwort. Er kann eine korrekte Antwort sein, die an eine Identität geht, die die zugrunde liegende Information nie hätte abrufen dürfen.

Schwierig wird das, wenn eine KI-Wissensschicht Dokumentenmanagement, SharePoint, Projektablagen, CRM-Systeme, Ticketplattformen, Datenbanken und Betriebssysteme umspannt. Jede Quelle kann ein anderes Berechtigungsmodell mitbringen. Ein Nutzer darf vielleicht einen Geschäftsbereich sehen, einen anderen nicht, ein Projekt, ein anderes nicht, oder Informationen bis zu einer Klassifizierungsstufe, aber nicht darüber hinaus.

Diese Einschränkungen lassen sich nicht erst anwenden, nachdem das Modell seine Antwort erzeugt hat. Ist unbefugte Information erst einmal in den Modellkontext gelangt, ist die entscheidende Sicherheitsgrenze bereits verletzt.

Identität und Autorisierung müssen deshalb bis in den Retrieval-Pfad hineinwirken. Je nach Umgebung kann das ACLs der Quelle, rollen- oder attributbasierte Zugriffskontrolle, Mandantentrennung, Sicherheitsklassifizierungen und Dienst-zu-Dienst-Identitäten umfassen. Wo sich eine Berechtigung nicht zuverlässig feststellen lässt, ist ein sicheres Abbrechen angemessener, als den Suchbereich stillschweigend auszuweiten.

Dasselbe gilt für personenbezogene Informationen. Verarbeitet ein europäisches RAG-System personenbezogene Daten, entfallen die Datenschutzpflichten nicht dadurch, dass die Information in Embeddings umgewandelt oder einem Modell vorübergehend übergeben wurde. Die DSGVO betrifft weiterhin die Verarbeitung von Informationen über identifizierbare Personen, weshalb der gesamte Retrieval- und Inferenzfluss zu betrachten ist, nicht nur die primäre Ablage.

Die Sicherheits-Governance um die Plattform lässt sich über Normen wie ISO/IEC 27001 strukturieren, während ISO/IEC 42001 einen Managementsystem-Rahmen speziell für Organisationen einführt, die KI entwickeln, bereitstellen oder nutzen. ISO/IEC 23894 ergänzt das um Leitlinien zur Einbettung KI-spezifischen Risikomanagements in organisatorische Prozesse. Diese Normen zertifizieren nicht die Richtigkeit einer einzelnen RAG-Antwort; ihr Wert liegt in wiederholbarer Governance rund um das System, das sie erzeugt.

Abgerufene Dokumente sind nicht vertrauenswürdige Eingaben

RAG bringt zudem eine Sicherheitseigenschaft mit, die klassische Suchsysteme in dieser Form nicht hatten: Abgerufener Text kann das Verhalten der Anwendung beeinflussen, die ihn verarbeitet.

Ein bösartiges Dokument kann Anweisungen enthalten, die das Modell manipulieren sollen. Eine kompromittierte Webseite kann einem Agenten sagen, bisherige Regeln zu ignorieren, zusätzliche Informationen preiszugeben oder ein Werkzeug aufzurufen. Der Angreifer muss die Anweisung nicht mehr direkt in die Chat-Oberfläche schreiben; sie kann indirekt über eine Quelle kommen, der die KI vertrauen sollte.

Damit wird Prompt Injection zu einem umfassenderen Thema der Systemsicherheit.

Die richtige Verteidigung ist nicht einfach ein strengerer System-Prompt. Die Architektur sollte annehmen, dass abgerufene Informationen feindlich sein können. Werkzeugbefugnisse sollten außerhalb des Modells durchgesetzt werden. Sensible Operationen sollten durch deterministische Policy-Kontrollen laufen. Herkunft und Vertrauenswürdigkeit der Quelle sollten sichtbar bleiben. Ein Agent, der Informationen aus einer nicht vertrauenswürdigen Quelle erhält, sollte nicht plötzlich eine neue Fähigkeit bekommen, weil der Text es ihm gesagt hat.

Das Prinzip ist alt, nur in neuer Umgebung: Nicht vertrauenswürdige Eingaben dürfen nicht zu vertrauenswürdiger Steuerungslogik werden.

Aktualität bedeutet auch, Informationen zuverlässig löschen zu können

Die meisten Teams messen, wie schnell sie neue Informationen aufnehmen können. Produktivsysteme müssen zusätzlich zeigen, wie zuverlässig Informationen aufhören, auffindbar zu sein.

Richtlinien werden ersetzt. Verträge laufen aus. Berechtigungen werden entzogen. Beschäftigte wechseln das Team. Ein Behördendokument kann neu eingestuft werden. Datensätze können das Ende ihrer Aufbewahrungsfrist erreichen. Eine technische Anweisung kann unmittelbar nach einem Vorfall zurückgezogen werden.

Ändert sich das Quellsystem, während der Retrieval-Index unverändert bleibt, erzeugt die KI-Plattform eine parallele und zunehmend falsche Version der organisationalen Wirklichkeit.

Die technische Herausforderung ist deshalb kontinuierliche Synchronisation. Aktualisierungen sollten idempotent sein, die Dokumentidentität stabil, das Löschen verlässlich und Versionsübergänge ausdrücklich. Die Retrieval-Schicht sollte gegen die führenden Systeme abgleichbar sein, damit fehlende Aktualisierungen erkannt werden, statt still im Index zu verbleiben.

Die hinnehmbare Verzögerung hängt von der Folge ab. Ein Marketingdokument verträgt ein anderes Aktualitätsziel als eine Änderung privilegierter Zugriffe oder eine Sicherheitsanweisung. Produktives RAG braucht deshalb differenzierte Anforderungen an Aktualität und Widerruf statt eines universellen Indexierungs-SLA.

Resilienz umfasst mehr als die Verfügbarkeit der Vektordatenbank

Ein RAG-Dienst kann von einem Identitätsanbieter, Quellablagen, Dokumentenparsern, Embedding-Infrastruktur, einem Vektorspeicher, Reranking, Modellinferenz, Policy-Diensten und Observability abhängen. Die Anwendungsserver hochverfügbar zu machen, macht diese Kette nicht resilient.

Die nützlichere Architekturfrage lautet, was passiert, wenn eine dieser Annahmen wegfällt.

Wenn das bevorzugte Modell ausfällt, kann ein schwächeres Modell einen akzeptablen eingeschränkten Dienst aufrechterhalten? Wenn das Vektor-Retrieval versagt, kann ein freigegebener lexikalischer oder hybrider Suchpfad weiterhin maßgebliche Belege liefern? Wenn der Identitätsdienst gestört ist, kann das System bestehende sichere Sitzungen erhalten, ohne den Zugriff auszuweiten? Wenn die Indexierung zurückfällt, sagt die Anwendung den Betreibern, dass der Wissensstand veraltet ist, statt weiterzumachen, als sei nichts geschehen?

Für Organisationen im Anwendungsbereich von NIS2 fügt sich dieses Denken natürlich in die Risikomanagement-Anforderungen der Richtlinie ein, die Vorfallbehandlung, Geschäftskontinuität, Notfallwiederherstellung, Lieferkettensicherheit, sichere Beschaffung und Entwicklung, Schwachstellenbehandlung, Zugriffskontrolle und weitere technische und organisatorische Maßnahmen umfassen. Der europäische Rahmen versteht Cybersicherheit ausdrücklich als risikobasierten All-Gefahren-Ansatz und nicht als bloßes Schwachstellen-Scanning.

Unterstützt der Dienst eine Einrichtung im Anwendungsbereich des Rahmens für die Resilienz kritischer Einrichtungen, weitet sich die Analyse weiter. CER behandelt die Widerstandsfähigkeit von Einrichtungen, die wesentliche Dienste erbringen, und blickt über Cybervorfälle hinaus auf die Fähigkeit, Störungen zu verhindern, sich davor zu schützen, darauf zu reagieren, ihnen standzuhalten, sie abzumildern und sich von ihnen zu erholen.

Das heißt nicht, dass jede RAG-Anwendung als kritische Infrastruktur zu entwerfen wäre. Es heißt, dass sich das Resilienzmodell nach der Tragweite der Funktion richten sollte, die das System stützt.

Observability muss jede Antwort nachvollziehbar machen

Wenn eine Fachperson eine produktive Antwort anzweifelt, ist „das Modell hat sie erzeugt“ keine ausreichende Erklärung.

Das Engineering-Team sollte rekonstruieren können, welche Identität die Anfrage gestellt hat, wie diese Anfrage für das Retrieval umgeformt wurde, welche Berechtigungs- und Metadatenfilter griffen, welche Quellen infrage kamen, welche Passagen geholt wurden, wie sie gerankt waren, welche Modellkonfiguration verwendet wurde und welche Belege die endgültige Antwort stützten.

Kann das System handeln, sollte sich die Spur über Policy-Entscheidungen, Werkzeugaufrufe, Parameter und den entstehenden externen Zustand fortsetzen.

Diese Tiefe an Observability verändert den Umgang mit KI-Vorfällen. Ein Parsing-Fehler lässt sich von einem Ranking-Fehler unterscheiden. Veraltetes Wissen wird vom Schlussfolgern des Modells trennbar. Ein Berechtigungsfehler unterscheidet sich klar von einer Halluzination. Sind diese Fehlerklassen sichtbar, kann Verbesserung systematisch statt anekdotisch werden.

Die Bewertung sollte demselben Prinzip folgen. Testsätze sollten normale Fragen, mehrdeutige Fragen, ersetzte Informationen, widersprüchliche Belege, zugangsbeschränkte Dokumente und feindliche Inhalte enthalten. Wichtiger noch: Fehler sollten nach ihrer Folge gewichtet werden. Ein System, das einen sicherheits- oder missionsrelevanten Prozess stützt, sollte nicht akzeptiert werden, weil ein breiter Durchschnittswert gut aussieht.

Die Anforderungen für den Produktivbetrieb

Eine produktive RAG-Plattform ist deshalb kein Chatbot mit angehängter Vektordatenbank.

Sie ist eine kontrollierte Architektur für den Wissenszugriff über Ingestion, Suche, Identität, Autorisierung, Information Governance, KI-Risikomanagement, Observability und operative Resilienz hinweg. Das Sprachmodell bleibt eine wichtige Komponente, aber viele der wichtigsten Fehler treten auf, bevor das Modell Kontext erhält, oder nachdem es eine Antwort erzeugt hat.

Die Schwelle zwischen Demo und Infrastruktur ist erreicht, wenn die Organisation eine schwierigere Frage beantworten kann als „funktioniert es?“

Sie sollte erklären können, warum diese Identität diese Information aus dieser Version der Belege über diesen Befugnispfad erhalten hat; was verhindert, dass eine kompromittierte Quelle zur Steueranweisung wird; wie schnell widerrufenes Wissen verschwindet; wie sich der Dienst verhält, wenn eine Abhängigkeit ausfällt; und wie ein Betreiber die vollständige Entscheidung im Nachhinein rekonstruieren kann.

Das macht ein RAG-System im Produktivbetrieb vertrauenswürdig.