Glean, einer der großen Anbieter für KI-gestützte Unternehmenssuche, meldet in seiner eigenen Unternehmensmitteilung vom 8. Dezember 2025 ein Verhältnis von wöchentlich zu monatlich aktiven Nutzern von 40 Prozent, bei durchschnittlich fünf Anfragen pro Nutzer und Tag. Das Unternehmen bezeichnet diesen Wert selbst als branchenführend. Lies das Verhältnis noch einmal: Von den Leuten, die das System überhaupt einmal im Monat benutzen, ist in einer beliebigen Woche weniger als die Hälfte aktiv. Nicht an einem Tag, in einer ganzen Woche. Und das ist der Wert, mit dem der Anbieter wirbt.
Dazu die Abbruchquote. Gartner sagte am 29. Juli 2024 in einer eigenen Pressemitteilung voraus, dass Unternehmen bis Ende 2025 mindestens 30 Prozent ihrer Generative-AI-Projekte nach dem Proof of Concept einstellen, wegen schlechter Datenqualität, unzureichender Risikokontrollen, steigender Kosten und unklaren Geschäftsnutzens.
Wir haben den Use Case für eine interne Wissensdatenbank im Detail ausgearbeitet und beraten Unternehmen dazu. Je länger wir uns damit beschäftigen, desto klarer wird eines: Die gesparte Suchzeit ist der falsche Maßstab. Nützlicher ist die Liste der Fragen, auf die so ein System antwortet: „Dazu habe ich keine Information in euren Unterlagen gefunden.”
Die Suchzeit-Rechnung setzt voraus, dass die Antwort existiert
Der übliche Business-Case geht so: Das McKinsey Global Institute bezifferte 2012 den täglichen Suchaufwand pro Wissensarbeiter auf rund 1,8 Stunden. Multipliziere das mit deiner Teamgröße und einem Bruttostundensatz, und du bekommst eine Monatszahl, bei der jede Investition klein aussieht. Der Use Case zur internen Wissensdatenbank rechnet das vor, samt der Warnung, dass in der Praxis oft nur 30 bis 50 Prozent davon ankommen.
Die Rechnung hat zwei Bruchstellen. Die erste ist die Nutzung, und dafür steht Gleans Zahl. Die zweite ist unbequemer: Die Rechnung misst die Zeit, die jemand für das Finden eines Dokuments braucht. Sie sagt nichts über den Fall, in dem es das Dokument nie gab.
Dieser zweite Fall kommt in keiner Suchzeit-Rechnung vor. Er lässt sich darin auch nicht abbilden.
Wenn du wissen willst, was so ein System kostet, welche Werkzeuge wann passen und was die DSGVO dabei von dir verlangt: Das steht komplett in unserem Use Case zur internen Wissensdatenbank, mit Kostenrahmen, Tool-Vergleich und Datenschutz-Checkliste. Dieser Text handelt von etwas anderem.
Der Satz, den niemand hören will, ist ein Messwert
Ein sauber konfiguriertes RAG-System rät nicht. Es beantwortet Fragen ausschließlich aus den indexierten Dokumenten und nennt dazu die Quelle. Findet es nichts, sagt es genau das. Dieser Fallback ist kein Makel, den man wegkonfiguriert. Er ist ein Messinstrument.
Jedes Mal, wenn dieser Satz erscheint, ist eine echte Person mit einem echten Anliegen auf eine Lücke gestoßen. Nicht auf eine gedachte Lücke aus einem Dokumentations-Workshop, sondern auf eine, die jemanden gerade an der Arbeit hindert. Sammle diese Fälle über ein paar Wochen, und du hast etwas, das kein Wiki-Projekt produziert: eine nach echter Nachfrage sortierte Liste dessen, was dein Unternehmen nie aufgeschrieben hat.
In kleinen Firmen wirkt das schärfer, nicht milder. Wo 200 Leute arbeiten, federn zwei oder drei Kolleginnen eine Wissenslücke ab, weil sie es zufällig auch wissen. In einem Team von acht Leuten ist die Lücke eine einzelne Person im Urlaub. Der Bus-Faktor ist dort keine Metapher, sondern ein Kalendereintrag.
Ein Dokumentationsprojekt kennt die Fragen noch nicht, die es beantworten soll
Ein Einwand liegt nahe: Wenn das System auf viele Fragen nichts findet, ist das Projekt gescheitert. Erst dokumentieren, dann die KI einführen.
Klingt vernünftig. Ist trotzdem falsch herum gedacht: Dokumentation ohne Nachfragesignal ist Angebotsplanung im Blindflug. Teams dokumentieren, was sich leicht dokumentieren lässt: den Prozess, den gerade jemand abgeschlossen hat, das Tool, das jemand mag, die Onboarding-Checkliste, die ohnehin fällig war. Was dabei entsteht, ist ein Wiki, das an den falschen Stellen vollständig ist.
Ein Fehlerprotokoll sortiert anders, nämlich nach dem, was tatsächlich gefragt wurde, und nach Häufigkeit. Diese Reihenfolge kann ein Dokumentationsprojekt vorher nicht kennen, weil es die Fragen noch nicht kennt. Dieselbe Diagnose stellen wir auch in bezahlten Kundenprojekten: Die Dokumentation, die vorhanden ist, beantwortet erstaunlich selten die Fragen, die wirklich gestellt werden.
Die Kennzahl dafür gibt es längst, nur im falschen Kontext
Im E-Commerce wird sie seit Jahren geführt. Algolia empfiehlt in seinem eigenen Merchandising-Playbook zur Null-Ergebnis-Optimierung, die Rate der Suchanfragen ohne Treffer unter 2 Prozent zu halten. Zwischen 3 und 5 Prozent gilt als suboptimal, oberhalb von 10 Prozent als klar kaputte Nutzererfahrung. Kein Shop-Betreiber führt diese Zahl aus Neugier. Er führt sie, weil jede Suche ohne Treffer verlorener Umsatz ist.
Übertrage die Kennzahl auf deine interne Wissensdatenbank, und du hast das Fehlerprotokoll, von dem dieser Text handelt. Mit einem Unterschied in der Deutung: Im Shop ist die Null-Ergebnis-Rate ein Defekt, den du beseitigst. Intern ist sie ein Backlog mit Prioritäten.
Deshalb ist eine Rate von null intern kein Ziel, sondern ein Warnsignal. Sie bedeutet entweder, dass niemand mehr die unbequemen Fragen stellt, oder dass das System anfängt zu raten.
Wer nur die Antworten prüft, prüft die falsche Hälfte
Was passiert, wenn diese Hälfte niemand prüft, zeigt ein Fall aus der Medizin. MD Anderson Cancer Center und IBM bauten ab 2013 gemeinsam den Oncology Expert Advisor auf Basis von IBM Watson. Ein 48-seitiger Prüfbericht des University of Texas System deckte im Februar 2017 Beschaffungsprobleme, Kostenexplosionen und Verzögerungen auf. MD Anderson ließ den Vertrag auslaufen, bevor das System je an echten Patienten eingesetzt wurde, nach Gesamtkosten von rund 62 Millionen US-Dollar über vier Jahre, davon 39 Millionen an IBM und 23 Millionen an PwC.
Der eigentliche Befund kam später. Am 25. Juli 2018 legte eine Recherche von STAT News auf Basis interner IBM-Dokumente offen, dass Watson for Oncology mit synthetischen, hypothetischen Fallbeispielen statt mit echten Patientendaten trainiert worden war und wiederholt Empfehlungen ausgab, die intern als unsicher und inkorrekt bezeichnet wurden, teils im Widerspruch zu nationalen Behandlungsleitlinien.
Ein Onkologie-Assistent ist keine interne Frage-Antwort-Datenbank, und das Risikoprofil ist ein anderes. Der Mechanismus ist derselbe: Niemand hatte eine Liste, auf der stand, was das System nicht wusste.
„Wirf einfach alles rein” und du erfährst nie, was fehlt
Der zweite Einwand kommt aus der Technik: Kontextfenster sind heute riesig, also braucht es weder Kuratierung noch Auswahl. Lade den gesamten Bestand in den Kontext und lass das Modell entscheiden.
Das scheitert schon an der Technik selbst. Nelson F. Liu und Kollegen zeigten in „Lost in the Middle” (Transactions of the Association for Computational Linguistics, 2024), dass die Trefferquote für ein relevantes Dokument in der Mitte eines Kontexts aus 20 Dokumenten auf 55 Prozent fällt, gegenüber 75 Prozent am Anfang. GPT-3.5-Turbo rutschte dabei sogar unter seine eigene Baseline von 56 Prozent ohne jeden Kontext. Warum das eine Architekturfrage ist und keine Prompt-Frage, haben wir im Text zum Context Engineering aufgeschrieben.
Dazu kommen Zugriffsrechte, die ein reiner Kontext-Dump nicht abbildet. Dazu kommen veraltete Stände, deren Widerspruch zur gültigen Fassung niemand aufgelöst hat. Der Preis dafür heißt KI-Schulden, und er wird später fällig.
Für dieses Argument zählt aber ein anderer Punkt mehr: Ein System, das immer irgendetwas antwortet, produziert kein Fehlerprotokoll. Du verlierst nicht nur Präzision. Du verlierst das Signal, das dir zeigt, wo dein Unternehmen blind ist.
Der Engpass wandert gerade vom Modell in den Korpus
Gartner legte am 26. Februar 2025 in der Pressemitteilung „Lack of AI-Ready Data Puts AI Projects at Risk” nach: Bis Ende 2026 werden Unternehmen 60 Prozent ihrer KI-Projekte aufgeben, weil die zugrunde liegenden Daten nicht KI-tauglich sind. Grundlage ist eine Gartner-Umfrage unter 248 Verantwortlichen für Datenmanagement aus dem dritten Quartal 2024, in der 63 Prozent der Organisationen angaben, keine oder keine gesicherten Datenmanagement-Praktiken für KI zu haben.
In den kommenden 12 bis 24 Monaten wird das unangenehmer, nicht harmloser. Sobald Agenten schreibenden Zugriff auf interne Systeme bekommen, ist nicht die Modellqualität der Engpass, sondern die Frage, ob dein Bestand diesen Zugriff trägt. Ein Lesefehler produziert eine falsche Auskunft, die jemand bemerken kann. Ein Schreibfehler produziert einen falschen Datensatz, mit dem danach weitergearbeitet wird.
Die Regulierung zieht in dieselbe Richtung. Artikel 12 der KI-Verordnung verlangt für Hochrisiko-Systeme nach Anhang III die automatische Aufzeichnung von Ereignissen über die Lebensdauer des Systems. Wichtig und oft falsch zitiert: Eine interne Frage-Antwort-Datenbank fällt nicht automatisch unter Anhang III, und die Fristen für diese Kategorie sind zuletzt verschoben worden. Das ist keine Rechtspflicht für dein RAG-System, sondern eine Richtung: Nachvollziehbarkeit wird vom Nice-to-have zur Erwartung.
Vier Wochen Protokoll bringen dir mehr als ein Dokumentationsprojekt
Das ist kein großes Vorhaben, sondern eine Betriebsregel.
Erstens: Konfiguriere den Fallback so, dass das System nicht raten darf. Kein „vermutlich”, kein „üblicherweise”. Entweder eine Antwort mit Quelle, oder der klare Satz, dass in den Unterlagen nichts steht. Den fertigen Prompt dafür findest du in unserem Use Case.
Zweitens: Protokolliere jeden dieser Fälle mit Frage, Datum und Person. Nicht als Fehlermeldung im Ticketsystem, sondern als Liste. Vier Wochen reichen für ein brauchbares Bild.
Drittens: Sortiere nach Häufigkeit, nicht nach Thema. Die Sortierung nach Thema führt zurück ins Wiki-Denken. Die Sortierung nach Häufigkeit ergibt deine nach Nachfrage priorisierte Dokumentations-Warteschlange, und die oberen fünf Einträge bearbeitest du zuerst.
Und wenn nach vier Wochen dieselbe Frage zum fünften Mal auf der Liste steht und niemand sie beantworten konnte, dann weißt du eine Sache sicher: Das Problem war nie die Suchzeit.