Ein CTO aus dem Maschinenbau meldet sich Anfang Juni. Das RAG-System für die interne Wissensdatenbank läuft seit sieben Monaten im POC. Zwei Data-Scientists Vollzeit, ein Product Owner halbtags. Zufriedenheit mit den Demo-Antworten hoch. Produktive Nutzung: null. Die Frage ist nicht mehr, wie sie es fertigbekommen, sondern wie sie dem Vorstand erklären, dass sie es nicht fertigbekommen.
Das ist der Normalfall. Laut BCG-Studie vom September 2025 schaffen 74% der AI-Initiativen den Sprung vom Pilot in die Produktion nicht. Bei RAG-Systemen ist die Quote nach unserer Erfahrung eher noch höher — weil RAG unterschätzt wird, wie ein leicht anzuklickendes Puzzle, das dann in der Realität aus lauter beweglichen Teilen besteht.
Drei Muster sehen wir in jedem zweiten Erstgespräch.
Muster 1: Alles läuft im Notebook
Der Prototyp entstand in einem Jupyter-Notebook mit LangChain oder LlamaIndex. Die Prompts stehen direkt im Code. Der Vector-Store ist entweder in-memory FAISS oder eine hochgeladene Chroma-DB auf einem einzelnen Container. Ein Modell ist fest verdrahtet, oft die neueste OpenAI-Variante.
Das ist für die erste Demo super. Für Production ist es tödlich. Beim ersten Deploy explodieren die Fehlerraten, weil:
- Prompts nicht versioniert sind — man kann Änderungen nicht zurückrollen.
- Der Vector-Store beim Neustart leer ist oder unauflösbare Konflikte hat.
- Es keinen Fallback gibt, wenn das eine Modell mal ausfällt.
- Latenz-Spikes nicht erkannt werden, weil kein Monitoring läuft.
Die Lösung ist nicht mehr Framework. Die Lösung ist eine saubere Trennung zwischen Prompt-Config, Vector-Store-Setup und Modell-Wahl in versionierten Layern. Zwei Sprints Arbeit, kein Rocket Science, wird aber gerne übersprungen.
Muster 2: Es gibt keine Evaluation
Die zweite tödliche Falle. Das Team sagt "die Antworten sind gut", basierend auf 20 Demo-Prompts. Es gibt keinen Ground-Truth-Datensatz, keine Retrieval-Metriken, keine Groundedness-Checks. Bei jeder Prompt-Änderung ist völlig offen, ob das System besser oder schlechter geworden ist.
Konkret fehlen:
- Retrieval Hit@k: Wie oft ist das richtige Dokument unter den Top-k Retrieval-Ergebnissen?
- Groundedness: Antwortet das Modell tatsächlich aus dem Retrieval-Kontext oder halluziniert es?
- Refusal Rate: Verweigert das Modell Antworten, wenn kein Kontext gefunden wurde?
- Answer-F1 gegen Ground-Truth: Wie nah ist die generierte Antwort an der erwarteten?
Ohne diese Metriken kann jede Änderung im System eine Regression sein, ohne dass es jemand merkt. Und Regressionen häufen sich, bis die Nutzer aussteigen.
Der Aufwand für ein Minimal-Eval-Setup ist überschaubar: 50 Prompt-Antwort-Paare händisch kuratiert, ein einfaches Skript das Retrieval-Hit@k und Groundedness ausrechnet, im CI verlinkt. Zwei bis drei Personentage. Wer das überspringt, spart drei Tage und verliert drei Monate.
Muster 3: DSGVO als Nachgedanke
Das dritte Muster erkennt man daran, dass DSGVO im Kick-off-Meeting mit "das machen wir am Ende" abgehakt wurde. Der Vector-Store liegt in einem US-Region-Managed-Service. Es gibt keinen PII-Scanner auf Prompt-Eingaben. Data-Lineage existiert nicht. Right-to-Erasure ist ein Konzept aus einer alten Schulung.
Das reicht für Sprint 1 bis 11. Ab Sprint 12, wenn das System für den ersten echten Nutzer freigegeben werden soll, fällt der Datenschutzbeauftragte aus allen Wolken. Der Launch wird gestoppt. Es kommt der Nachbau des Systems auf EU-Region-Infrastruktur, plus PII-Scanner, plus Data-Lineage-Tracking. Das dauert typischerweise zwei bis vier Monate zusätzlich.
Der Gegenvorschlag: DSGVO ab Sprint 1. Vector-Store in EU-Region-Frankfurt oder eu-west. PII-Scanner als Middleware zwischen Nutzer-Prompt und Modell-Call. Data-Lineage für jeden Chunk (Quelle, Version, Aufnahmedatum). Right-to-Erasure als Delete-by-Source-ID im Vector-Index. Das ist zwei Sprints Zusatzaufwand am Anfang und spart drei Monate am Ende.
Was die 26% anders machen
Die Teams, die es in Production schaffen, haben drei gemeinsame Merkmale.
Sie behandeln RAG nicht als Data-Science-Projekt, sondern als System-Engineering-Projekt. Ein Data-Scientist im Team ist wichtig, aber der Rest sind Backend- und Platform-Engineers. Die Trennung zwischen "Prototyp" und "Production" ist explizit gemacht, mit klaren Kriterien wann etwas als production-ready gilt.
Sie automatisieren Evaluation vom ersten Sprint an. Auch wenn das erste Eval-Set nur 20 Prompts hat. Es wird bei jedem Pull-Request ausgeführt. Regressionen werden sofort sichtbar.
Sie planen DSGVO und Compliance in die Architektur ein, nicht als Add-On. Sie akzeptieren, dass EU-Region und PII-Filter nicht 0% Overhead sind, aber weit unter dem, was ein Nachbau kostet.
Wenn ihr im Notebook feststeckt, keine Evaluation habt oder DSGVO noch ansteht — nichts davon ist unlösbar. Aber jede Woche länger wird es teurer. Wenn ihr eine externe Perspektive auf euer RAG-Setup wollt, sind wir bei NeuralMedic erreichbar. Aktive Retainer-Kunden seit April 2024, spezialisiert auf genau diese Übergangs-Situation.
Der Reifegrad-Check auf dieser Website gibt euch in 90 Sekunden eine Selbst-Einschätzung mit konkreten nächsten Schritten. Ohne Anmeldung, ohne Speichern eurer Daten. Als Startpunkt reicht das oft.