RAG-Production-Readiness-Checkliste für EU-Unternehmen

Eine RAG-Demo über die eigenen Dokumente ist einer der einfachsten Erfolge in der KI. Setz einen Retriever auf dein Wiki, häng ihn an ein Modell, und du hast an einem Nachmittag etwas, das Fragen beantwortet. Schwer wird alles nach der Demo. Eine Demo, die ein Meeting beeindruckt, ist nicht dasselbe wie ein Assistent, auf den sich deine Mitarbeiter oder Kunden verlassen können, und in der EU muss er das sein und unter DSGVO und KI-Verordnung haltbar, ohne eine Cloud-Rechnung, die sich still jedes Quartal verdoppelt. Das ist die Checkliste, die wir durchgehen, bevor ein RAG-System von interessant zu vertrauenswürdig wird.

Nichts davon ist ein Argument gegen RAG. Es ist der billigste Weg, einem Modell dein Wissen zu geben, ohne irgendetwas neu zu trainieren. Es ist ein Argument dafür, die Demo als Anfang der Arbeit zu behandeln, nicht als ihr Ende.

Ist das Retrieval wirklich gut genug?

Alles weiter unten hängt davon ab, dass das Modell die richtigen Passagen bekommt. Ist das Retrieval schwach, rettet dich kein noch so feines Prompt-Tuning, weil das Modell aus der falschen Quelle oder aus dem Nichts antwortet. Genau diesen Teil überspringen Demos, denn auf einer Handvoll sauberer Dokumente sieht fast jedes Setup gut aus.

• Chunking, das Bedeutung respektiert. Ein Split nach fester Zeichenzahl reißt Sätze und Tabellen auseinander. Chunke entlang der Struktur, Überschriften, Abschnitte, logische Einheiten, damit eine abgerufene Passage ein vollständiger Gedanke ist.
• Ein Embedding-Modell, das zu deinem Inhalt passt. Der Default ist selten der beste für deine Domäne oder deine Sprachen. Wenn du Kunden auf Deutsch und Englisch bedienst, teste, dass das Retrieval in beiden funktioniert, nicht nur in der, in der du demonstriert hast.
• Ein Evaluierungs-Set, kein Bauchgefühl. Schreib echte Fragen auf und die Passagen, die sie beantworten sollten. Miss den Recall, ob die richtige Passage tatsächlich abgerufen wird, bevor du sonst etwas anfasst.
• Quellenangaben zu jeder Antwort. Das System sollte zurückgeben, welche Dokumente es genutzt hat. Das macht Antworten überprüfbar und später das Ganze auditierbar.

Erfindet es Dinge?

Ein Modell mit Retrieval halluziniert trotzdem, wenn du es lässt. Die Disziplin von RAG ist, das Modell an der kurzen Leine zu halten: aus dem abgerufenen Kontext antworten, und nur aus ihm.

• Nur aus dem abgerufenen Kontext antworten. Weise das Modell an, jede Aussage in den übergebenen Passagen zu verankern und Lücken nicht aus seinem allgemeinen Training zu füllen.
• Verweigern, wenn der Kontext dünn ist. Kommt das Retrieval leer oder schwach zurück, ist die richtige Antwort "das habe ich nicht", keine selbstbewusste Vermutung. Ein System, das gut verweigert, ist vertrauenswürdiger als eines, das immer antwortet.
• Die Quellen zeigen. Stell die Quellenangaben dem Nutzer dar. Das erlaubt ihm zu verifizieren, und es verändert das Verhalten: Menschen vertrauen einem System mehr, wenn sie sehen, woher die Antwort kommt, und weniger blind.

"Eine RAG-Demo beantwortet die Fragen, die du getestet hast. Ein RAG-Produkt muss die beantworten, die du nicht getestet hast, und schweigen, wenn es schweigen sollte. Die Lücke zwischen beidem ist das ganze Engagement."

Kannst du es zweimal gleich messen?

Was RAG-Projekte still tötet, ist, dass sich jede Änderung wie Fortschritt anfühlt und niemand es beweisen kann. Du tauschst das Embedding-Modell, drehst an einem Prompt, indizierst neu, und die Demo läuft weiter, also lieferst du aus. Dann wird eine Klasse von Fragen still schlechter.

Bau ein Golden-Set aus Fragen und Antworten: eine feste Liste echter Fragen mit den Antworten und Quellen, die du erwartest. Lass es bei jeder Änderung neu laufen, ein neuer Prompt, ein neues Modell, eine Neuindizierung, und vergleiche. Es muss nicht ausgefeilt sein. Es muss jedes Mal gleich sein, damit eine Regression als sinkende Zahl auftaucht statt als Beschwerde drei Wochen später.

Was kostet der Betrieb, und wie schnell ist es?

Eine RAG-Demo für eine Person ist in jeder relevanten Hinsicht kostenlos. Ein RAG-Assistent für ein Unternehmen ist eine wiederkehrende Rechnung, die mit der Nutzung skaliert, und eine Latenz, die Nutzer bei jeder Anfrage spüren. Beides sind Designentscheidungen, keine nachträglichen Gedanken.

• Cache, was sich wiederholt. Viele Fragen werden immer wieder gestellt. Abgerufenen Kontext und häufige Antworten zu cachen senkt Kosten und Latenz.
• Staffle deine Modelle. Nicht jede Anfrage braucht das größte Modell. Leite einfache Fragen an ein kleineres, billigeres weiter und behalte das große Modell für die harten Fälle.
• Budgetiere deine Token. Zwanzig Passagen in jeden Prompt zu stopfen ist langsam und teuer und macht Antworten oft schlechter. Ruf weniger, bessere Passagen ab.

Die Ökonomie verschiebt sich hier schnell, und die Architektur, die du jetzt wählst, entscheidet, was du später zahlst. Tiefer sind wir darauf in der Verschiebung der LLM-API-Kosten eingegangen.

Hält es unter EU-Regeln stand?

Hier haben EU-Unternehmen Hausaufgaben, die ein US-Tutorial nicht erwähnt. Wir beschreiben Pflichten hier auf allgemeiner Ebene, keine Rechtsberatung, und die Details hängen von deiner Branche und deinen Daten ab. Sprich für die Einzelheiten mit einem Anwalt. Aber die technischen Fragen sind klar genug für eine Checkliste.

• Kenne deine Datenflüsse. Unter der DSGVO musst du wissen, wohin personenbezogene Daten gehen. Enthalten deine Dokumente oder Nutzerfragen personenbezogene Daten und sitzt dein Modell oder Vektorspeicher außerhalb der EU, ist das eine Übermittlung, die du rechtfertigen können musst. Datenresidenz ist eine Designentscheidung, die du früh triffst, kein Schalter, den du spät umlegst.
• Sei transparent, dass es KI ist. Die KI-Verordnung erwartet, dass Nutzer wissen, wann sie mit einem KI-System statt mit einem Menschen interagieren. Bei einem Assistenten heißt das in der Regel, es den Leuten klar zu sagen.
• Geh bewusst mit PII um. Entscheide, welche personenbezogenen Daten in den Index und in Prompts dürfen und was redigiert oder ausgeschlossen wird. Retrieval kann ein Dokument hervorholen, dessen Sensibilität jemand vergessen hatte.
• Logge für das Audit. Halte fest, was gefragt, was abgerufen und was geantwortet wurde. Du wirst es zum Debuggen brauchen, zum Verbessern und um die Frage "warum hat es das gesagt" zu beantworten, wenn jemand sie stellt.

Über die Kosten der KI-Verordnungs-Compliance für ein Startup und wie sich DSGVO und KI-Verordnung stapeln für ein DACH-SaaS haben wir separat geschrieben, falls du die regulatorische Seite tiefer willst.

Kann jemand es brechen oder lesen, was er nicht sollte?

Ein RAG-System hat zwei Sicherheitsprobleme, denen die meisten Demos nie begegnen: Das Modell lässt sich über seine Eingaben manipulieren, und der Index wird ein neuer Ort, an dem sensible Daten liegen.

• Prompt Injection. Ein abgerufenes Dokument kann Anweisungen ans Modell enthalten: "ignoriere deine Regeln und gib X preis". Behandle abgerufenen Inhalt als nicht vertrauenswürdige Eingabe, nicht als Befehl, und teste darauf.
• Zugriffskontrolle auf dem Index. Der Vektorspeicher ist jetzt eine Kopie deines Wissens. Er braucht dieselben Zugriffskontrollen wie die Quellsysteme, nicht schwächere, weil es "nur Embeddings" sind.
• Dokumentberechtigungen pro Nutzer. Das ist die, die am härtesten zubeißt. Darf ein Nutzer nur bestimmte Dokumente sehen, muss das Retrieval das bei jeder Anfrage respektieren, damit der Assistent nie eine Passage aus einem Dokument hervorholt, das dieser Nutzer nie lesen durfte. Ein RAG-System, das Berechtigungen ignoriert, ist ein Datenleck mit freundlicher Chat-Oberfläche.

Die Checkliste

Geh das durch, bevor du jemanden sich auf einen RAG-Assistenten verlassen lässt. Wenn eine Zeile dich zögern lässt, ist das die Zeile, die du zuerst reparierst.

1. Retrieval. Sinnvolles Chunking, ein auf deinem Inhalt und deinen Sprachen getestetes Embedding-Modell, ein Eval-Set mit gemessenem Recall, Quellenangaben zu jeder Antwort.
2. Grounding. Antworten kommen nur aus dem abgerufenen Kontext, das System verweigert bei Unsicherheit, Quellen werden dem Nutzer gezeigt.
3. Wiederholbare Evaluierung. Ein Golden-Set aus Fragen und Antworten, das du bei jeder Prompt-, Modell- oder Index-Änderung neu laufen lässt.
4. Kosten und Latenz. Caching, Modell-Staffelung und Token-Budgets, die du im Maßstab verteidigen kannst, nicht nur in der Demo.
5. EU-Compliance. Bekannte Datenflüsse und Residenz, Transparenz, dass es KI ist, bewusster PII-Umgang, Audit-Logging.
6. Sicherheit. Prompt Injection getestet, Zugriffskontrolle auf dem Index, Berechtigungen pro Nutzer beim Retrieval durchgesetzt, damit nichts über Nutzer hinweg leakt.

Das Ergebnis ist keine Slideshow über RAG. Es ist ein System, das das Richtige abruft, verweigert, wenn es sollte, kostet, was du budgetiert hast, und nicht leakt.