RAG ist inzwischen der Standardansatz, wenn ein Unternehmen eigene Inhalte in ein Sprachmodell bringen will. Die Architektur ist gut verstanden, die Werkzeuge sind verfügbar, und die ersten Prototypen laufen meist innerhalb von Wochen.
Trotzdem scheitern viele dieser Projekte nach dem Prototyp. Nicht an der Technik.
Was RAG leistet
Retrieval Augmented Generation bedeutet vereinfacht: Bevor das Modell antwortet, werden passende Dokumentabschnitte aus Ihren Quellen gesucht und in den Prompt gegeben. Das Modell antwortet dann auf Basis dieser Abschnitte statt aus dem Trainingswissen.
Der Effekt ist belegt. Eine Meta-Analyse aus 2024 nennt eine Reduktion von Halluzinationen um 40 bis 71 Prozent durch RAG mit validiertem Kontext. Diese Spanne ist wichtig: Sie gilt für RAG mit validiertem Kontext, nicht für RAG allein.
Genau in dieser Einschränkung steckt der Grund, warum Projekte stecken bleiben.
Warum der Prototyp funktioniert und der Rollout nicht
Im Prototyp wählt jemand 20 gute Dokumente aus. Die Antworten sind überzeugend, die Demo läuft, das Budget kommt.
Im Rollout zeigen Sie das System auf den echten Bestand: SharePoint, Fileshares, Confluence, ein paar Ticketsysteme. Und dort liegen drei Dinge gleichzeitig, die vorher nicht im Testset waren.
1 Veraltete Inhalte
Die Arbeitsanweisung von 2021 liegt neben der von 2025. Beide sind formal gültige Dokumente. Das Retrieval hat keine Grundlage, sich für die richtige zu entscheiden.
2 Widersprüche
Zwei Abteilungen haben denselben Prozess unterschiedlich beschrieben. Beide Fassungen fließen in die Antwort ein, und das Modell formuliert daraus eine plausible Mischung, die nirgends gilt. Warum ein Wiki das strukturell nicht auflöst, steht im Beitrag zur Confluence Alternative.
3 Lücken
Was nicht dokumentiert ist, kann nicht gefunden werden. Bei 42 Prozent nicht dokumentiertem jobbezogenem Wissen (Panopto/McKinsey) fehlt genau der Teil, der bei kritischen Fragen gebraucht wird. Das Modell füllt diese Lücke, weil es dafür gebaut ist. Und dann wird es teuer.
Die Folgen sind gemessen: 67,4 Milliarden Dollar globale Geschäftsverluste durch KI-Halluzinationen 2024 (AllAboutAI). 47 Prozent der Enterprise-KI-Nutzenden trafen mindestens eine wichtige Geschäftsentscheidung auf Basis halluzinierter Inhalte. Und 4,3 Stunden pro Mitarbeitendem und Woche gehen für Verifikation auf, rund 14.200 Dollar im Jahr.
Die Schicht, die in den meisten Architekturdiagrammen fehlt
Typische RAG-Architekturen bestehen aus vier Bausteinen: Quellen, Indexierung mit Embeddings, Retrieval, Generierung. Dazwischen fehlt eine fünfte Schicht.
Nennen wir sie Trust Layer. Ihre Aufgabe ist es, aus Dokumenten belastbaren Kontext zu machen, bevor sie indexiert werden. Vier Eigenschaften braucht jedes Wissensobjekt in dieser Schicht:
- Owner. Eine benannte Person, die für die Aussage verantwortlich ist.
- Gültigkeitsdatum. Wann wurde geprüft, bis wann gilt es.
- Verifikationsstatus. Geprüft, ungeprüft, im Konflikt.
- Herkunft. Woher kommt die Aussage, aus welchem Interview oder Dokument.
Mit diesen vier Attributen kann das Retrieval priorisieren statt zu raten. Und die Antwort kann ihre Grundlage ausweisen, was der Unterschied zwischen einer nutzbaren und einer riskanten Antwort ist.
Wie die Lücke gefüllt wird
Der Trust Layer löst das Widerspruchs- und Aktualitätsproblem. Er löst nicht das Lückenproblem, denn eine Validierungsschicht kann nur validieren, was existiert.
Für die Lücke braucht es einen anderen Mechanismus: aktive Erfassung. KI-gestützte Experteninterviews holen Entscheidungslogik, Ausnahmen und Heuristiken aus den Köpfen und führen sie als strukturierte Wissensobjekte in dieselbe Schicht ein. Konsolidiert wird entlang von fünf Dimensionen: Korrektheit, Aktualität, Relevanz, Konfliktfreiheit, Vollständigkeit.
Erst dann stimmt die Voraussetzung, unter der die 40 bis 71 Prozent gelten: validierter Kontext.
Anbindung an Ihre bestehende Landschaft
Praktisch relevant ist, dass diese Schicht nicht Ihr Frontend ersetzt. Sie liefert Kontext an das, was Sie schon haben, über RAG-API, REST-API und MCP Server. SharePoint-Ausspielung ist möglich, Microsoft Copilot kann als Kontextnehmer angebunden werden, SAP HR oder Workday können als Trigger-Quelle dienen, etwa wenn ein Austritt ansteht.
Der MCP-Server ist dabei der Punkt, der für Agenten-Szenarien zählt. Ein Agent, der eigenständig handelt, braucht Kontext mit Herkunftsnachweis, nicht Textähnlichkeit. Ohne Kontext skaliert KI Fehler statt Kompetenz.
Was Sie in DACH zusätzlich klären müssen
Zwei regulatorische Punkte sind seit 2025 in Kraft und gehören in jede Architekturentscheidung: EU AI Act Artikel 4 zur KI-Kompetenzpflicht seit Februar 2025 und NIS-2 seit Dezember 2025.
Praktisch bedeutet das Anforderungen an Hosting, Nachvollziehbarkeit und Governance. Relevante Merkmale in der Bewertung: EU-Hosting auf Azure mit Rechenzentren in Deutschland, DSGVO-Konformität, TISAX-Zertifizierung, keine Nutzung von Kundendaten für Modelltraining, kein Datentransfer in die USA, vollständige und nachweisbare Löschbarkeit, rollenbasierte Zugriffssteuerung mit Audit-Trail.
Und ein Nebenthema mit realem Risiko: Über 50 Prozent der Mitarbeitenden nutzen privates GenAI unkontrolliert für die Arbeit (Gartner, Februar 2026). Ein funktionierender interner Zugang ist damit auch eine Maßnahme gegen Schatten-KI.
Reihenfolge, die sich in der Praxis bewährt
Nicht: Modell wählen, dann Daten suchen. Sondern umgekehrt.
Wählen Sie einen konkreten Anwendungsfall mit messbarem Nutzen, etwa Support-Antworten für eine Produktlinie oder Entscheidungsunterstützung in einem Betriebsprozess. Bestimmen Sie, welches Wissen dafür nötig ist. Prüfen Sie, wie viel davon dokumentiert, aktuell und widerspruchsfrei vorliegt. Erfassen Sie die Lücke aktiv. Erst dann bauen Sie das Retrieval.
Diese Reihenfolge ist langsamer im Start und schneller im Ergebnis. Der umgekehrte Weg produziert überzeugende Demos und unbrauchbare Rollouts.
