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

Ein RAG-Prototyp über einen begrenzten Dokumentbestand lässt sich schnell zusammenbauen. Das belegt keine Produktionsreife. Ein Assistent braucht repräsentative Nachweise für Retrieval- und Antwortqualität, gemessene Kosten und Latenz, Datenschutzkontrollen sowie eine Autorisierung, die bei echten Nutzern und echten Daten standhält. EU-Teams müssen außerdem die DSGVO und alle anwendbaren Pflichten der KI-Verordnung dem tatsächlichen Anwendungsfall zuordnen. Das ist die risikobasierte Checkliste, die wir verwenden, bevor Menschen sich auf ein RAG-System verlassen sollen.

RAG ist eine Möglichkeit, externes Wissen bereitzustellen, ohne Modellgewichte zu verändern. Ob es günstiger oder geeigneter ist als Long Context, Suche, Fine-Tuning oder ein deterministischer Workflow, hängt von der Arbeitslast ab. Behandle den Prototyp als Anfang der Evaluierung, nicht als ihr Ende.

Wenn das Wissen als PDF eintrifft, beginnt Retrieval-Qualität schon vor dem Chunking. Unser Leitfaden zu PDF-Parsing und OCR-Routing zeigt, wie nativer Text lokal bleibt, Scan- und Mischseiten erkannt werden und OCR nur dort läuft, wo sie nötig ist.

Eine RAG-Demo, die live gehen soll?

RAG-Production-Review buchen

Ist das Retrieval wirklich gut genug?

Die Antwortqualität ist begrenzt, wenn relevante Belege nicht abgerufen werden. Prompting kann eine Quelle, die nie in den Modellkontext gelangt ist, nicht wiederherstellen, auch wenn ein passendes Design zusätzlich Tools, strukturierte Daten oder einen ausdrücklichen Kein-Antwort-Pfad nutzen kann. Evaluiere das Retrieval mit repräsentativen Dokumenten und Anfragen statt nur mit einer kuratierten Demo.

Chunking, das am Inhalt getestet wird. Ansätze mit fester Größe, Struktur, Semantik, Parent-Child-Beziehungen oder dokumentspezifischen Regeln haben unterschiedliche Vor- und Nachteile. Tabellen und abschnittsübergreifende Verweise brauchen oft eine besondere Behandlung.
Eine Embedding- und Retrieval-Methode, die an deinem Inhalt getestet wird. Wenn du Kunden auf Deutsch und Englisch bedienst, teste beide Sprachen und relevante sprachübergreifende Anfragen, statt anzunehmen, dass ein Default übertragbar ist.
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.
Nachvollziehbare Belege, wo angemessen. Gib für faktische Antworten die verwendeten Passagen und Dokumentversionen zurück. Eine Quellenangabe verbessert die Überprüfbarkeit, beweist aber nicht, dass die Quelle die generierte Aussage stützt.

Erfindet es Dinge?

Retrieval beseitigt Halluzinationen nicht. Definiere, welche Aussagen durch abgerufene Belege gestützt werden müssen, welche anderen Tools oder Wissensquellen erlaubt sind und was der Assistent tun soll, wenn die Unterstützung nicht ausreicht.

Die Beleggrenze definieren. Weise das Modell an, welche Aussagen abgerufene Unterstützung benötigen, und validiere die Zuordnung von Aussagen zu Passagen.
Bei unzureichender Unterstützung enthalten. Kalibriere den Kein-Antwort-Pfad mit repräsentativen Beispielen. Leeres Retrieval, widersprüchliche Quellen, veraltete Dokumente und schwach bewertete Belege können unterschiedliche Behandlung erfordern.
Nutzbare Herkunft zeigen. Zeige relevante Passage, Titel, Version und Link, wenn der Nutzer sie prüfen kann. Teste, ob Quellenangaben die Aussage tatsächlich stützen und für diesen Nutzer zugänglich sind.

"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?

Änderungen an Embedding-Modell, Chunking, Prompt, Reranker, Quellkorpus oder Generierungsmodell können manche Anfrageklassen verbessern und andere verschlechtern. Eine erfolgreiche Demo zeigt diesen Zielkonflikt nicht.

Pflege ein versioniertes Evaluierungs-Set aus realen Deployment-Bedingungen, einschließlich erwarteter Belege, akzeptabler Antworten, Enthaltungen, mehrsprachiger Anfragen, Berechtigungsfällen und adversarieller Eingaben. Führe es bei relevanten Änderungen erneut aus und ergänze aggregierte Werte um Ergebnisse pro Teilgruppe und menschliche Prüfung. Aktualisiere das Set bewusst, wenn sich Korpus und Risiken verändern, statt ein fixes Set für vollständig zu halten.

Was kostet der Betrieb, und wie schnell ist es?

Ein Prototyp zeigt weder Produktionskosten noch Produktionslatenz. Miss Embedding- und Indexierungsarbeit, Vektorsuche, Reranking, Modelleingabe und -ausgabe, Cache-Operationen, Wiederholungsversuche, Observability und menschliche Prüfung bei erwarteter Parallelität.

Mit Grenzen cachen. Caching kann wiederholte Arbeit reduzieren, doch Schlüssel, Mandantentrennung, Autorisierung, Aktualität, Invalidierung und sensible Inhalte entscheiden, ob Wiederverwendung sicher ist.
Modell-Routing testen. Route erst, wenn eine repräsentative Evaluierung zeigt, wo ein kleineres Modell die Anforderung erfüllt. Berücksichtige Eskalations- und Wiederholungskosten.
Kontext aus Belegen budgetieren. Stimme Passagenzahl und Kontextgröße auf Retrieval-Abdeckung, Grounding, Latenz und Kosten ab, statt anzunehmen, dass weniger immer besser ist.

Die Wirtschaftlichkeit 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.

Rollen, Zwecke, Daten und Übermittlungen abbilden. Identifiziere Verantwortliche und Auftragsverarbeiter, Rechtsgrundlage, Datenkategorien, Aufbewahrung, Unterauftragsverarbeiter, Zugriffsorte und Sicherheitsmaßnahmen. Eine Übermittlung nach Kapitel V der DSGVO hängt von der tatsächlichen Offenlegung an einen Empfänger in einem Drittland ab, nicht nur vom Hauptsitz eines Anbieters oder einer Regionsbezeichnung, und erfordert einen anwendbaren Übermittlungsmechanismus samt Bewertung.
KI-Transparenzpflichten prüfen. Artikel 50 verpflichtet Anbieter von Systemen, die für die direkte Interaktion mit natürlichen Personen bestimmt sind, sie darüber zu informieren, dass sie mit KI interagieren, sofern dies für eine angemessen informierte, aufmerksame und verständige Person im Kontext nicht offensichtlich ist. Bestimme Rollen, Ausnahmen, Anwendungsdatum und branchenspezifische Pflichten für das Deployment, statt auf jedes interne Tool dieselbe Banner-Regel anzuwenden.
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.
Verhältnismäßig loggen. Erfasse genug versionierte Belege, um Qualitäts- und Sicherheitsereignisse zu untersuchen, minimiere aber personenbezogene und vertrauliche Daten, beschränke den Zugriff, definiere Aufbewahrungsfristen und nimm nicht an, dass rohe Prompts und Antworten immer gespeichert werden sollten.

Ü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 fügt Sicherheitsgrenzen hinzu: Abgerufene Inhalte können das Modellverhalten beeinflussen, und Indizes, Metadaten, Caches, Logs und Quellkopien können sensible Daten offenlegen.

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 im gesamten Retrieval. Embeddings sind nicht zwingend eine wortgetreue Kopie des Quelltexts, doch Index und verbundene Inhalte können weiterhin sensible Informationen offenlegen. Wende Authentifizierung, Autorisierung, Mandantentrennung, Verschlüsselung, Backup- und Administrationskontrollen auf jeden relevanten Speicher an.
Berechtigungen aus dem Quellsystem. Haben Nutzer unterschiedliche Dokumentrechte, setze die wirksame Autorisierung vor oder während des Retrievals und erneut vor der Offenlegung durch. Teste Widerruf, Gruppenänderungen, öffentliche Links, vererbte Berechtigungen und Cache-Verhalten, statt dich auf eine einmal kopierte Zugriffsliste zu verlassen.

Die Checkliste

Nutze dies als erste Risikoprüfung, bevor du dich auf einen RAG-Assistenten verlässt. Es ist kein vollständiger Sicherheitsstandard, keine rechtliche Bewertung und keine Garantie. Priorisiere Lücken nach plausibler Wahrscheinlichkeit, Auswirkung, Exposition sowie den vorgesehenen Entscheidungen oder Aktionen des Systems.

Retrieval. Sinnvolles Chunking, ein auf deinem Inhalt und deinen Sprachen getestetes Embedding-Modell, ein Eval-Set mit gemessenem Recall, Quellenangaben zu jeder Antwort.
Grounding. Beleggrenzen sind definiert, Enthaltung ist kalibriert und zugängliche Quellen sind Aussagen zugeordnet.
Wiederholbare Evaluierung. Ein Golden-Set aus Fragen und Antworten, das du bei jeder Prompt-, Modell- oder Index-Änderung neu laufen lässt.
Kosten und Latenz. Caching, Modell-Staffelung und Token-Budgets, die du im Maßstab verteidigen kannst, nicht nur in der Demo.
EU-Rechtsprüfung. Rollen, Zwecke, Rechtsgrundlage, Datenflüsse, Übermittlungen, Aufbewahrung, Transparenzpflichten, Betroffenenrechte und verhältnismäßige Logs sind dem tatsächlichen Deployment zugeordnet.
Sicherheit. Prompt Injection getestet, Zugriffskontrolle auf dem Index, Berechtigungen pro Nutzer beim Retrieval durchgesetzt, damit nichts über Nutzer hinweg leakt.

Das Ergebnis sind Nachweise, dass das System innerhalb seines getesteten Umfangs definierte Anforderungen an Retrieval, Antwortqualität, Enthaltung, Kosten, Latenz, Datenschutz und Autorisierung erfüllt, ergänzt um Monitoring und Incident Handling für das, was Tests übersehen.

Genau das zu bauen ist unser KI Setup Service, wenn der Assistent auf deiner eigenen Infrastruktur läuft, und KI-Softwareentwicklung in Österreich, wenn die Retrieval-Schicht in einem Produkt steckt, das du an Kunden auslieferst. Twinsoft AI ist das nächstliegende veröffentlichte Beispiel für einen Prototyp, der genau diese Checkliste durchlaufen hat.

Fazit

Eine begrenzte RAG-Demo zeigt nicht, wie sich das System bei repräsentativen Dokumenten, mehrsprachigen Anfragen, veralteten oder widersprüchlichen Belegen, nicht autorisierten Inhalten, adversariellen Anweisungen oder Produktionslast verhält. Diese Bedingungen brauchen ausdrückliche Evaluierung und Kontrollen.

Verbinde bei einem EU-Deployment technische Nachweise mit dem tatsächlichen Datenfluss, organisatorischen Rollen, der Rechtsgrundlage, Übermittlungen, Transparenzpflichten, Aufbewahrung und dem Zugriffsmodell. Nutze diese Checkliste als erste Prüfung und lege anschließend risikobasierte Release-Kriterien, Monitoring, Rollback und Incident Handling für den vorgesehenen Einsatz fest.