Warum Claude oder ChatGPT Ihre Firmendokumente nicht wirklich kennt

Kategorien: Datenschutz

Eine KI, die einfach alle Firmendokumente kennt und jede Frage dazu beantworten kann – das klingt nach der perfekten Lösung für jedes Unternehmen mit gewachsenem Wissen. Doch zwischen dieser Vorstellung und der Realität von ChatGPT, Claude und Co. liegt eine überraschend große Lücke. Wer versteht, woran generische KI-Lösungen bei großen Dokumentenmengen scheitern, trifft bessere Entscheidungen für die eigene digitale Infrastruktur.

Einleitung

Stellen wir uns ein mittelständisches Unternehmen vor: eine Maschinenbaufirma mit 150 Mitarbeitenden. Über die Jahre sind dort tausende Dokumente entstanden – Wartungsprotokolle für jede ausgelieferte Anlage, technische Datenblätter, Serviceberichte der Außendienstmitarbeiter, interne E-Mails zu Kundenproblemen, Schulungsunterlagen und Verträge mit Zulieferern. Insgesamt kommen schnell mehrere zehntausend Dateien zusammen, verteilt über Dateiserver, ein altes Wiki und unzählige E-Mail-Postfächer.

Die Geschäftsführung hört von ChatGPT und Claude und hat eine naheliegende Idee: Warum nicht einfach der KI Zugriff auf all diese Dokumente geben? Mitarbeitende könnten dann Fragen stellen wie "Welche Ersatzteile wurden bei Anlage X in den letzten drei Jahren am häufigsten ausgetauscht?" oder "Zeig mir alle offenen Reklamationen aus dem letzten Quartal" – und die KI würde aus dem gesamten Firmenwissen die passende Antwort destillieren.

In der Theorie klingt das nach der perfekten Anwendung für generative KI. In der Praxis zeigt sich jedoch schnell: Cloud-KI-Dienste wie ChatGPT oder Claude sind für genau diesen Anwendungsfall – tausende eigene Dokumente als verlässliche Grundlage für Antworten – nicht gemacht. Die Gründe dafür liegen in vier Bereichen: der begrenzten Kontextlänge, den laufenden API-Kosten, dem notwendigen Unterbau aus Speicherung und Index (RAG) sowie grundsätzlichen Grenzen dieser Technik bei vollständigen oder statistischen Auswertungen. Dieser Artikel geht jeden dieser Punkte anhand konkreter Beispiele durch – und zeigt, warum am Ende oft eine speziell für den eigenen Anwendungsfall entwickelte Anwendung der praktikablere Weg ist.

Das Kontextfenster: Eine harte Grenze

Sprachmodelle wie ChatGPT oder Claude verarbeiten Text in einem sogenannten Kontextfenster – einem begrenzten "Arbeitsspeicher", der alle Informationen einer Anfrage aufnehmen muss: die Frage selbst, den bisherigen Gesprächsverlauf und alle mitgelieferten Dokumente.

Selbst sehr große Kontextfenster von 100.000 bis 200.000 Token entsprechen grob 150 bis 300 Seiten Text. Das mag für einzelne Berichte oder Verträge ausreichen – bei tausenden Dokumenten ist es jedoch bei Weitem zu wenig.

Beispiel: Die Maschinenbaufirma aus unserem Beispiel hat allein über 3.000 Wartungsprotokolle, jedes etwa zwei bis drei Seiten lang. Das sind schon mehr als 6.000 Seiten – also rund das Zwanzigfache eines großen Kontextfensters, nur für diese eine Dokumentenkategorie. Rechnet man Datenblätter, E-Mails und Serviceberichte hinzu, landet man schnell bei zigtausenden Seiten. Diese Menge passt unter keinen Umständen gleichzeitig in ein Kontextfenster, egal wie geschickt man Texte kürzt oder zusammenfasst.

Hinzu kommt ein subtileres Problem: Modelle behandeln nicht jeden Teil eines langen Kontexts gleich gut. Informationen, die "in der Mitte" eines sehr langen Prompts stehen, werden häufiger übersehen oder schlechter gewichtet als Informationen am Anfang oder Ende. Selbst wenn man es schaffen würde, alle relevanten Dokumente irgendwie hineinzuquetschen, würde die Antwortqualität leiden – einzelne wichtige Details könnten im "Rauschen" der Masse untergehen.

Das ist auch der Grund, warum ein LLM nicht gefragt werden sollte: "Wie viele Verträge mit Firma XY haben wir eigentlich?" Das LLM kennt gar nicht alle Ihre Dokumente. Vielmehr werden die Dokumente in einer KI-Vorstufe über eine Vektordatenbank vorselektiert und nur ein paar davon für die KI-Antwort verwendet. Damit eine Abzählfrage richtig beantwortet werden kann, muss ein geignetes KI-System (ungleich KI-Modell!) errichtet werden, welches diese Art von Fragen unterstützt.

API-Kosten: Bezahlt wird pro Token, bei jeder Anfrage neu

Cloud-KI-Anbieter berechnen ihre Leistung pro Token – sowohl für den Input (alles, was man dem Modell schickt) als auch für den Output (die generierte Antwort). Das Problem dabei: Bei jeder neuen Anfrage muss der relevante Kontext erneut mitgeschickt werden, denn das Modell hat zwischen zwei Anfragen kein Gedächtnis.

Beispiel: Angenommen, man möchte bei jeder Anfrage zumindest die 20 thematisch passendsten Dokumentenausschnitte mitschicken, um eine fundierte Antwort zu ermöglichen – das entspricht grob 15.000 bis 20.000 Token Kontext pro Anfrage. Bei 150 Mitarbeitenden, die im Schnitt fünf Anfragen pro Arbeitstag stellen, kommen täglich rund 750 Anfragen zusammen. Allein der Input-Kontext summiert sich dann auf über zehn Millionen Token pro Tag – Tag für Tag, Monat für Monat. Je nach Modell und Anbieter ergeben sich daraus laufende Kosten im Bereich von mehreren hundert bis über tausend Euro monatlich, nur für das wiederholte Mitschicken von Kontext – ohne dass dabei bereits "neue Intelligenz" entsteht, sondern lediglich derselbe Hintergrund immer wieder verarbeitet wird.

Diese Kosten skalieren linear mit der Nutzung. Je erfolgreicher und beliebter ein solches System im Unternehmen wird, desto teurer wird es – ein wirtschaftliches Modell, das schnell aus dem Ruder laufen kann, wenn es nicht von Anfang an durchdacht ist.

Speicherung, Index und RAG: Der unsichtbare Unterbau

Um große Dokumentenmengen überhaupt nutzbar zu machen, braucht es einen technischen Unterbau, den die Cloud-KI selbst nicht mitbringt: Retrieval-Augmented Generation, kurz RAG.

Das Prinzip: Dokumente werden in kleinere Abschnitte (Chunks) zerlegt, mittels eines Embedding-Modells in numerische Vektoren umgewandelt und in einer Vektordatenbank gespeichert. Bei einer Anfrage wird zunächst nach den thematisch passendsten Chunks gesucht – nur diese wenigen Abschnitte werden dann zusammen mit der Frage an das Sprachmodell geschickt.

Beispiel: Die 6.000 Seiten Wartungsprotokolle aus unserem Beispiel würden in Abschnitte von je etwa 500 Wörtern zerlegt – das ergibt mehrere tausend Chunks allein für diese Dokumentenkategorie. Jeder dieser Chunks muss einmalig in einen Vektor umgewandelt werden, was Embedding-Kosten verursacht. Bei Aktualisierungen – neue Wartungsprotokolle kommen ja laufend hinzu – wiederholt sich dieser Vorgang fortlaufend. Zusätzlich muss eine Vektordatenbank betrieben werden, die diese tausenden Vektoren speichert und bei jeder Anfrage in Millisekunden durchsuchen kann. Das ist kein einmaliges Setup, sondern eine dauerhafte Infrastruktur mit eigenen Hosting- und Wartungskosten – inklusive Updates, wenn sich Dokumente ändern, gelöscht oder neu hinzugefügt werden.

RAG löst viel – aber nicht alles

RAG ist die technische Grundlage, mit der Cloud-KI überhaupt erst mit großen Dokumentenmengen umgehen kann. Doch RAG hat strukturelle Grenzen, die sich nicht einfach "wegoptimieren" lassen.

Unvollständiges Auffinden relevanter Informationen. Die semantische Suche liefert die Chunks, die einer Anfrage am ähnlichsten erscheinen – das ist nicht dasselbe wie "alle relevanten Informationen".

Beispiel: Ein Mitarbeiter fragt: "Welche Probleme gab es bisher mit dem Hydraulikventil Typ HV-200?" Wenn dieses Ventil in 40 verschiedenen Wartungsprotokollen über mehrere Jahre erwähnt wird, aber das RAG-System standardmäßig nur die fünf bis zehn ähnlichsten Treffer zurückgibt, sieht die KI nur einen Bruchteil der relevanten Berichte. Die Antwort könnte sich auf die "lautesten" oder zuletzt indexierten Fälle stützen, während ältere oder anders formulierte Probleme schlicht unter den Tisch fallen – ohne dass der Nutzer merkt, dass die Antwort unvollständig ist.

Die Qualität der KI-Antwort hängt also ganz erheblich von der Qualität des Retrieval-Mechanismus' ab, also wie gut das Auffinden relevanter Informationen in (perfektem) Firmenwissen funktioniert.

Keine Aggregation und keine Statistik. RAG kann von seiner Funktionsweise her keine Fragen beantworten, die eine Auswertung über die gesamte Dokumentenmenge erfordern.

Beispiel: Die Frage "Wie viele Wartungseinsätze gab es 2025 insgesamt, und wie hoch war der durchschnittliche Zeitaufwand pro Einsatz?" lässt sich mit RAG grundsätzlich nicht zuverlässig beantworten. Semantische Suche findet inhaltlich ähnliche Textstellen zum Begriff "Wartungseinsatz" – sie kann aber nicht alle 2025 erstellten Protokolle vollständig erfassen, zählen und deren Zeitangaben summieren oder mitteln. Selbst wenn die KI eine Zahl ausgibt, basiert sie bestenfalls auf einer kleinen, zufälligen Stichprobe der gefundenen Dokumente – und ist damit im schlechtesten Fall schlicht falsch, ohne dass dies erkennbar wäre.

Warum Map-Reduce meist keine praktikable Alternative ist

Eine theoretische Lösung für "Fragen über alle Dokumente" ist ein Map-Reduce-Verfahren: Jedes Dokument wird einzeln durch die KI verarbeitet, die Teilantworten werden anschließend zusammengeführt.

Beispiel: Um die Frage nach den 2025 erstellten Wartungsprotokollen korrekt zu beantworten, müsste man theoretisch jedes der mehreren tausend Protokolle einzeln an die KI schicken, mit der Bitte, Datum und Zeitaufwand zu extrahieren – und die Ergebnisse anschließend zusammenzählen. Bei 3.000 Dokumenten bedeutet das 3.000 einzelne API-Aufrufe für eine einzige Nutzerfrage. Selbst bei niedrigen Kosten pro Aufruf summiert sich das schnell auf zweistellige Eurobeträge – für eine Frage, die ein Mensch in zwei Sekunden hätte stellen können, wenn die Daten in einer Tabelle gestanden hätten. Zeitlich dauert die Verarbeitung selbst mit Parallelisierung mehrere Minuten, was für eine interaktive Chat-Anwendung inakzeptabel ist. Wer stattdessen auf eigene Hardware setzt, um Kosten zu sparen, steht vor einem ähnlichen Dilemma: Die Anschaffung leistungsfähiger Grafikkarten für gelegentliche Batch-Verarbeitung lässt sich wirtschaftlich kaum rechtfertigen.

Strukturierte Datenhaltung als Ergänzung – mit einer wichtigen Einschränkung

Ein naheliegender Lösungsansatz: Statt alles der KI zu überlassen, werden beim Einlesen der Dokumente relevante Informationen einmalig extrahiert und in einer klassischen Datenbank wie PostgreSQL strukturiert abgelegt. Aggregationsfragen laufen dann über normale Datenbankabfragen – schnell, zuverlässig und ohne laufende KI-Kosten.

Beispiel: Für jedes Wartungsprotokoll könnten beim Import automatisch Felder wie Anlagen-ID, Datum, ausgetauschte Teile und Zeitaufwand in eine Tabelle geschrieben werden. Die Frage nach dem Durchschnittsaufwand 2025 wäre dann eine einfache SQL-Abfrage, die in Millisekunden ein exaktes Ergebnis liefert – ganz ohne KI-Aufruf zur Laufzeit.

Die Einschränkung dabei: Strukturierte Datenhaltung setzt ein Schema voraus – also festgelegte Felder und Datentypen. Dieses Schema ergibt sich aber aus dem jeweiligen Anwendungsfall. Bei Rechnungen sind andere Informationen relevant als bei Verträgen, Support-Tickets oder Wartungsprotokollen. Ohne zu wissen, welche Fragen später gestellt werden, lässt sich kaum entscheiden, welche Felder überhaupt extrahiert werden sollen.

Generisch lässt sich dennoch eine Basis-Schicht aufbauen: eine Volltextsuche über alle Dokumente, allgemeine Metadaten wie Datum, Dateityp oder Quelle, sowie ein Vektor-Index für die semantische Suche. Das deckt grundlegende Such- und Recherchefragen ab – fachspezifische Auswertungen wie im Beispiel der Wartungsprotokolle bleiben damit aber außen vor.

Die Konsequenz: Vorgedachte, spezialisierte Anwendungen

An diesem Punkt zeigt sich, warum generische "KI auf alle Firmendaten"-Lösungen in der Praxis enttäuschen und warum sich eine speziell entwickelte Anwendung oft lohnt.

Eine vorgedachte Anwendung kennt die Domäne: Sie weiß, welche Dokumenttypen vorkommen, welche Felder relevant sind und wie Dokumente miteinander zusammenhängen. Für die Maschinenbaufirma aus unserem Beispiel hieße das konkret: Wartungsprotokolle werden strukturiert erfasst (Anlage, Datum, Teile, Zeitaufwand), während Schulungsunterlagen oder allgemeine E-Mails eher über Volltext- und semantische Suche zugänglich gemacht werden. Auf dieser Basis lässt sich ein Schema entwerfen, das sowohl strukturierte Abfragen (Zählungen, Statistiken, Filter) als auch semantische Suche (RAG) sinnvoll kombiniert.

Ein praktikabler Weg ist dabei oft zweistufig: Zunächst wird eine generische Basis-Schicht aus Volltext- und Vektorsuche aufgebaut, mit der sich bereits viele Fragen beantworten lassen. Anschließend wird beobachtet, welche Fragetypen in der Praxis tatsächlich auftreten – und gezielt für die wichtigsten und häufigsten davon werden strukturierte Erweiterungen ergänzt, statt zu versuchen, jeden denkbaren Anwendungsfall vorab zu antizipieren.

Die KI kommt in einem solchen System an genau definierten Stellen zum Einsatz: bei der einmaligen Extraktion und Indexierung von Dokumenten, bei der semantischen Suche zur Laufzeit, und bei der Formulierung verständlicher Antworten auf Basis von Datenbankergebnissen und gefundenen Textauszügen. Die teure und unzuverlässige Vorstellung, eine KI könne "einfach alles lesen und verstehen", entfällt – zugunsten eines Systems, das für den jeweiligen Anwendungsfall tatsächlich funktioniert.

Fazit

Cloud-KI-Dienste wie ChatGPT oder Claude sind hervorragende Werkzeuge für einzelne Dokumente, kurze Recherchen oder die Formulierung von Antworten. Als direkte Grundlage für umfassendes Firmenwissen mit tausenden Dokumenten sind sie jedoch ungeeignet – begrenzt durch Kontextfenster, getrieben von linear wachsenden API-Kosten und grundsätzlich nicht in der Lage, zuverlässige Aggregationen oder Statistiken über große Datenmengen zu liefern.

RAG ist ein notwendiger, aber kein hinreichender Baustein. Wer wirklich belastbare, unternehmensweite Antworten möchte – inklusive Zählungen, Auswertungen und vollständiger Abdeckung relevanter Dokumente – kommt um eine durchdachte, auf den eigenen Anwendungsfall zugeschnittene Anwendung kaum herum. Die gute Nachricht: Mit offenen Technologien lässt sich ein solches System inkrementell aufbauen, ohne von einzelnen Cloud-Anbietern oder deren Preismodellen abhängig zu sein.