KI-Antwortgenauigkeit im Unternehmenseinsatz: Warum 96 Prozent kein Zufall sind

Die Erwartungen an KI-Einführungen sind hoch. Die Realität in Unternehmen fällt deutlich nüchterner aus. Drei aktuelle Studien von MIT NANDA,  S&P Global Market Intelligence und Tolly Group zeichnen ein konsistentes Bild: Projekte scheitern nicht an fehlendem Budget und nur selten an der Modellqualität. Sie scheitern an der Lücke zwischen Demo und Produktivbetrieb.

Eine Demo lässt sich mit ein paar Dokumenten im Kontextfenster bauen. Dort funktionieren auch generische Tools überzeugend. Sobald reale, komplexe Unternehmensdokumentation verarbeitet werden muss, mit Tabellen, Schaltplänen, technischen Zeichnungen und Bildern, brechen Antwortqualität und Verlässlichkeit ein.

Genau diese Lücke hat die Tolly Group im März 2026 in einem unabhängigen Benchmark vermessen. Auf identischer technischer Dokumentation erreicht octonomy eine Antwortgenauigkeit von 96 Prozent. Microsoft Copilot Studio Knowledge Base kommt auf 58 Prozent. Der Report ist öffentlich zugänglich. Die Zahlen sind nachprüfbar. Dieser Artikel erklärt, was dahintersteckt.

KI ist in den meisten Unternehmen angekommen. Pilotprojekte laufen, erste Use Cases sind definiert, Budgets sind freigegeben. Viele Entscheider berichten dennoch, dass die Ergebnisse in der Praxis nicht halten, was die Demos versprochen haben.

MIT NANDA hat in „The GenAI Divide“ untersucht, was aus den geschätzten 30 bis 40 Milliarden US-Dollar geworden ist, die Unternehmen weltweit in generative KI investiert haben: 95 Prozent der GenAI-Pilotprojekte liefern keinen messbaren P&L-Effekt. Nur 5 Prozent der evaluierten Enterprise-Systeme erreichen den Produktivbetrieb. Und extern beschaffte Lösungen schaffen es rund doppelt so oft in Produktion wie intern entwickelte Systeme.

S&P Global Market Intelligence kommt in „Voice of the Enterprise 2025“ zu einem ähnlichen Befund aus anderer Perspektive: 42 Prozent der Unternehmen verwerfen die Mehrheit ihrer KI-Initiativen, bevor sie in Produktion gehen. Im Vorjahr waren es noch 17 Prozent. Im Schnitt landen 46 Prozent aller Proof-of-Concepts nie im produktiven Einsatz.

Das hat eine strukturelle Ursache. Die meisten Benchmarks und Demos arbeiten mit einfachen Textdokumenten, kurzen FAQ-Datenbanken oder synthetisch erzeugten Testfragen. Reale Unternehmensdokumentation sieht anders aus. Technische Handbücher enthalten Schemazeichnungen, in denen Kraftangaben als beschriftete Pfeile eingetragen sind. Servicedokumentationen verteilen kritische Informationen über dutzende Kapitel. Produktspezifikationen arbeiten mit Leistungskurven, aus denen Werte interpoliert werden müssen. In diesem Terrain versagen Standard-KI-Systeme zuverlässig.

Verteilung von 50 Benchmark-Fragen auf vier KI-Schlussfolgerungsfähigkeiten

octonomy verarbeitete das vollständige, unveränderte Dokument als einheitliche Wissensbasis. Alle anderen Lösungen erforderten manuelle Vorsegmentierung in Kapitel-Dateien, ein Mehraufwand, der auf Seiten der Wettbewerber lag. Trotzdem haben sie verloren.

octonomy erreichte 96 Prozent Antwortgenauigkeit. Microsoft Copilot in der direkten Upload-Variante kam auf 58 Prozent. Der führende KI-Chatbot-Anbieter auf 34 Prozent. Microsoft Copilot über SharePoint auf 26 Prozent.

Die Ergebnisse der unabhängigen Toll-Group-Studie

Das zentrale Ergebnis lässt sich auf einen Satz reduzieren: Microsoft Copilot nutzte in der direkten Upload-Variante dasselbe Basismodell wie octonomy, nämlich Anthropic Claude Sonnet, und erzielte trotzdem nur 58 Prozent Genauigkeit gegenüber 96 Prozent. Das Modell ist nicht der limitierende Faktor. Die Fähigkeit, komplexe Dokumente zu verarbeiten und Kontext korrekt zuzuordnen liegt in der Architektur dahinter.

Die Tolly Group hat die Fehler der getesteten Lösungen systematisch analysiert und dabei vier reproduzierbare Muster gefunden, von denen kein Wettbewerber alle vermeiden konnte. Diese Fehler folgen aus grundlegenden Architekturentscheidungen, die viele Standard-KI-Systeme teilen.

Alle vier Muster haben dasselbe Fundament. Die Lösungen verarbeiten Dokumentation als reinen Textfluss. Was nicht als Text vorliegt, wird ignoriert. Was als Text vorliegt, wird ohne Kontextverständnis abgerufen. Wenn beides scheitert, generiert das System lieber eine Antwort, als seine Unsicherheit zuzugeben.

Die Tolly Group dokumentiert die Fehler nicht nur als Statistik, sondern an konkreten Fragen aus dem Benchmark. Drei davon illustrieren die vier Fehlermuster besonders deutlich.

Ein Techniker fragt nach der Designlast an einem Trägerbauteil einer Rohrhalterung. Der korrekte Wert, F = 5,85 kN, ist als beschrifteter Pfeil direkt in die technische Zeichnung eingetragen. Er erscheint weder in einer Tabelle noch im Fließtext. octonomy identifiziert den Wert aus der Zeichnung und beschreibt den Kontext vollständig. Copilot findet die Zeichnung, liest die Bemaßungen aus, übersieht aber die Kraftannotation und kommt zu dem Schluss, das Dokument „spezifiziere keine numerische Designlast“. Der führende Chatbot findet die relevante Dokumentation gar nicht und bezeichnet die Information als „nicht klar dokumentiert“.

Die zweite Frage betrifft den Mindest-Überkopfabstand für eine Außeninstallation. Die Dokumentation enthält separate Freigabediagramme für Innen- und Außeninstallation auf verschiedenen Seiten. octonomy gibt den korrekten Außenwert zurück, mindestens 4,2 Meter, und unterscheidet explizit zwischen beiden Installationskontexten. Copilot findet Freigabedokumentation, gibt aber die Innenwerte zurück, weil es nicht zwischen den beiden Szenarien unterscheidet. Der führende Chatbot halluziniert einen generischen Innenwert aus einem anderen Abschnitt und ergänzt Hinweise zu „Luftaustauschvolumen“, die in keiner Quelle existieren.

Das dritte Beispiel erfordert grafische Interpolation: Ein Wert soll aus einer Temperaturkurve bei einer bestimmten Bandgeschwindigkeit abgelesen werden. octonomy liest die Achsen korrekt aus und interpoliert einen Wert von etwa 31 Grad Celsius, innerhalb der akzeptablen Toleranz von plus minus zwei Grad. Der führende Chatbot findet die richtige Kurve, verwechselt aber Celsius und Fahrenheit und gibt einen Wert an, der auch nach Umrechnung nicht stimmt. Copilot beschreibt die Kurve korrekt, verweigert jedoch die Interpolation mit dem Hinweis, der genaue Wert sei „kein expliziter Datenpunkt“.

Halluzinierte Antworten, die von Nutzern als korrekt akzeptiert und auf deren Basis gehandelt wird, können erhebliche Probleme verursachen. Eine erkennbar falsche Antwort wird hinterfragt. Eine plausibel falsche Antwort wird ausgeführt.

In normalen Kontexten bedeutet das einen Fehler. In technischen, medizinischen oder sicherheitskritischen Kontexten kann es erhebliche Konsequenzen haben. Bei der Instandhaltung kritischer Infrastruktur kann eine halluzinierte Fehlerdiagnose eine unnötige Anfahrt über hunderte Kilometer auslösen. In der Logistik mit Gefahrgutvorschriften kann eine falsch interpolierte Grenzwertangabe einen Compliance-Verstoß produzieren. In der Versicherungswirtschaft kann eine fabrizierte Vertragsauskunft eine Kundenzusage erzeugen, die keine Grundlage hat.

octonomy begegnet diesem Risiko durch eine klare Architekturentscheidung: Das System gibt keine Antwort, die nicht durch eine verifizierte Quelle belegt ist. Wenn eine Frage nicht mit ausreichender Sicherheit beantwortet werden kann, kommuniziert das System das transparent. Alle Antworten werden strikt auf die angebundene Wissensbasis zurückgeführt und mit Kapitelangabe ausgegeben.

Nicht jede KI-Lösung ist dasselbe, nur weil sie KI heißt. Der entscheidende Unterschied liegt nicht im Anbieter oder im Basismodell, sondern in der Fähigkeit, mit komplexem Unternehmenswissen umzugehen. Das folgende Reifegradmodell ordnet KI-Systeme in vier Stufen ein, basierend auf dem KPMG AI Capability Maturity Assessment, der Klippa IDP-Studie 2025, dem Retresco KI-Reifegrad-Report 2025 und den Benchmarkdaten der Tolly Group.

Stufe 1 – FAQ-Automatisierung.
Diese Systeme beantworten Standardfragen auf Basis vordefinierter Antwortmuster. Sobald eine Frage vom Muster abweicht oder mehrere Informationsquellen erfordert, bricht die Leistung ein. Viele Unternehmen beginnen ihre KI-Initiativen auf dieser Stufe und bleiben dort stecken.

Stufe 2 – kontextbasiertes Q&A.
RAG-Systeme und semantische Suche ermöglichen Antworten aus internen Textdokumenten. Die Qualität steigt deutlich, solange die Wissensbasis aus sauber strukturiertem Text besteht. Sobald die relevante Information in einer Tabelle, einem Diagramm oder einer technischen Zeichnung liegt, endet die Kompetenz dieser Systeme strukturell.

Stufe 3 – fortgeschrittene Dokumentenintelligenz.
Diese Systeme auf dieser Stufe verarbeiten mehrere Quellen gleichzeitig und verbessern die Kontextzuordnung. Sie scheitern dennoch systematisch, wenn Antworten aus visuellen Quellen interpoliert werden müssen oder wenn kontextabhängige Varianten korrekt unterschieden werden müssen.

Stufe 4 – komplexe Dokumentenverarbeitung mit visuellem Cortex.
Ein System auf dieser Ebene verarbeitet Text, Layout, Diagramme und technische Zeichnungen als zusammenhängende Wissensquelle. Das ist die Stufe, auf der octonomy operiert. Der Tolly-Benchmark hat das unabhängig gemessen: 96 Prozent Antwortgenauigkeit bei 50 komplexen Fragen aus einer realen industriellen Dokumentation mit über 1.000 Seiten.

Ein System auf Stufe 2 oder 3 liefert in Szenarien mit visuell kodierten Informationen nicht einfach schlechtere Ergebnisse. Es liefert strukturell keine Ergebnisse, weil seine Architektur keinen Zugang zu diesen Informationen hat. Das ist eine Architekturfrage, die bei der Systemauswahl entschieden wird.

Die folgenden vier Fälle zeigen, was der Unterschied zwischen 96 Prozent und 26 bis 58 Prozent Antwortgenauigkeit im laufenden Betrieb konkret bedeutet.

Prokon ist Deutschlands größte Energiegenossenschaft: 77 Windparks, 20 verschiedene Anlagengenerationen, 2.641 technische Dokumente mit über 50.000 Seiten. Weil Diagnosen vor Ort getroffen werden mussten und das relevante Wissen nicht greifbar war, kam es im Schnitt zu sechs Anfahrten pro Störungsfall. Mit octonomy, integriert in Microsoft Dynamics Field Service, analysiert das System Fehlercodes, verknüpft Monitoring-Daten mit Herstellerdokumentation und erstellt konkrete Handlungspläne, bevor der Techniker zur Anlage fährt. Ergebnis: 50 Prozent weniger Serviceeinsätze pro Störungsfall, 25 Prozent schnellere Problemlösung vor Ort. Der initiale Rollout dauerte zehn Tage.

hepster ist ein InsurTech-Unternehmen, das sich auf Embedded Insurance spezialisiert hat, also auf Versicherungslösungen, die per API in digitale Customer Journeys integriert werden. Bei hepster arbeitet octonomy als Multi-Agenten-System. heppyChat einer der octonomy-KI-Agenten bei hepster, schließt Support-Anfragen end-to-end ab. heppyClaimy automatisiert die operative Schadenbearbeitung, von der Prüfung formeller Kriterien über das Auslesen und Validieren von Dokumenten bis zu Routing und Entscheidungsvorlagen. Der Rollout nach Frankreich und Österreich lief ohne erneute Implementierung. Das Ergebnis sind 50 Prozent weniger Supportaufwand ohne Qualitätseinbußen und eine Verfügbarkeit rund um die Uhr über alle Kanäle.

Emons Spedition arbeitet täglich mit über 20 operativen Handbüchern zu Gefahrgut, Prozessen und Spedition. Eine einzelne Anfrage dauerte bis zu 15 Minuten. Mit octonomy als internem Expertensystem haben Mitarbeiter in Sekunden Zugriff, mit präziser Kapitel- und Versionsnummer. Als ein weltweit führender Getränke- und Lebensmittelkonzern einen Sustainability-Fragebogen mit 36 Detailfragen einreichte, hätte die Beantwortung ohne das System Wochen der abteilungsübergreifenden Recherche erfordert. Mit octonomy wurden alle 36 Fragen strukturiert beantwortet.

ALUCA ist ein internationaler Hersteller hochwertiger Fahrzeugeinrichtungen aus Aluminium und exportiert über ein breites Partnernetzwerk in mehr als 20 europäische Länder. für mehrsprachigen Support mit verteiltem Produktwissen nutzt ALUCA octonomy. Serviceteams in verschiedenen Ländern greifen auf dieselbe verifizierte Wissensbasis zu, sprachübergreifend und ohne Qualitätsverlust.

Lesen Sie die weiteren Customer Cases von octonomy hier.

96 Prozent Antwortgenauigkeit ist ein konkreter, unabhängig gemessener Wert. Was er bedeutet, erschließt sich erst, wenn man versteht, wie diese Genauigkeit entsteht und wie octonomy sicherstellt, dass sie im laufenden Betrieb stabil bleibt.

Agenten werden wie Software getestet. Jeder octonomy-Agent wird mit Unit-Tests geprüft, bevor er produktiv geht. Für jeden relevanten Anwendungsfall wird ein erwartetes Ergebnis definiert. Der Agent muss dieses Ergebnis zuverlässig reproduzieren, auch in Grenzfällen.

Ground-Truth-Testing mit realen Fragen. Vor jeder Implementierung erstellt octonomy gemeinsam mit dem Kunden einen Testsatz aus realen Betriebsfragen. Die Antworten werden von Fachexperten des Kunden bewertet, und das Ergebnis ist die Grundlage für den Go-Live-Entscheid. Bei Emons Spedition ergab dieses Verfahren eine verifizierte Antwortqualität von über 95 Prozent.

Kontinuierliche Verbesserung im Betrieb. Nutzer können Feedback direkt in der Plattform geben. Das System erstellt kontextbasierte Änderungsvorschläge, die Fachexperten prüfen und freigeben. Die aktualisierte Wissensbasis steht danach im gesamten System zur Verfügung.

octonomy misst Genauigkeit auf drei Ebenen: faktische Korrektheit, Relevanz für den gesuchten Kontext und Schlussfolgerungsqualität. Die meisten KI-Systeme messen Genauigkeit auf Basis einfacher Textabgleiche. Das reicht für FAQ-Systeme. Für wissensintensive Serviceprozesse reicht es nicht.

Die meisten Unternehmen stellen bei der Evaluation die falsche Frage. Sie fragen, was ein System kann, anstatt zu fragen, wie es sich verhält, wenn es wirklich gefordert wird. In der Demo zeigt jedes System seine besten Seiten: ausgewählte Dokumente, klare Fragen, saubere Daten. Die Frage ist, was passiert, wenn echte Nutzer mit echten Dokumenten und echten Problemen auf das System treffen.

Antwortgenauigkeit entscheidet darüber, ob KI im Unternehmen ein echter Gewinn wird oder ein Versprechen, das sich nicht eingelöst hat. Der Unterschied zwischen 96 und 26 Prozent ist kein technisches Detail. Er ist der Unterschied zwischen einem System, das im Produktivbetrieb trägt, und einem, das in der Pilotphase bleibt.