Open Knowledge Format: die fehlende Ebene für KI-Agenten

Warum 95 Prozent der KI-Pilotprojekte nichts bringen

MIT-Forscher aus dem NANDA-Projekt sind in ihrer Studie „The GenAI Divide: State of AI in Business 2025“ genau dieser Frage nachgegangen: Warum bringt generative KI in Unternehmen so oft nichts? Grundlage waren, wie Fortune über die Studie berichtet, 52 Experteninterviews, eine Befragung von 153 Führungskräften und eine Analyse von 300 öffentlichen KI-Einsätzen. Das Ergebnis: 95 Prozent der GenAI-Pilotprojekte in Unternehmen zeigten keinen messbaren Effekt auf Umsatz oder Gewinn. Nur etwa jedes zwanzigste brachte etwas, das ein CFO als Ergebnis durchgehen ließe.

Der Reflex ist, das Modell verantwortlich zu machen. Das ist die falsche Ebene. Die Studie fand organisatorische Barrieren: Tools, die in der Demo überzeugen, scheitern an echten Unternehmens-Workflows und an der Datenlage. Das Modell funktioniert, nur das Wissen, das es für sinnvolle Antworten braucht, liegt in Trümmern.

Studienleiter Aditya Challapally beschreibt das im Fortune-Gespräch als „Lerner-Lücke“ auf beiden Seiten, bei den Tools und bei den Organisationen. Generische Werkzeuge wie ChatGPT funktionieren für Einzelpersonen gut, gerade weil sie flexibel sind. In Unternehmen stocken dieselben Werkzeuge, weil sie sich nicht an bestehende Workflows anpassen und aus ihnen nichts lernen.

Dieses Problem gab es schon vor KI. Schlechte Dokumentation, isolierte Wikis, Prozesse, die nur im Kopf der dienstältesten Kollegen existieren: eine jahrzehntealte Klage. Was KI verändert, ist, dass die Kosten davon sofort sichtbar werden. Ein Agent, der auf die Frage „Wie berechne ich wöchentlich aktive Nutzer aus unserem Event-Stream?“ eine generische Antwort gibt, ist nicht dumm. Er hat einfach keine Ahnung, wie dein Unternehmen tatsächlich arbeitet.

Selbst das teuerste Modell im aktuellen Lineup ändert daran nichts. Zwölf Stunden autonomes Arbeiten helfen wenig, wenn die Grundlage darunter nirgends dokumentiert ist. Genau das ist der Punkt, den die MIT-Zahlen belegen: Das Problem sitzt eine Ebene tiefer als das Modell.

Wie fragmentiertes Wissen in der Praxis aussieht

Firmenwissen liegt an mehreren Orten gleichzeitig: in Datenkatalogen, Confluence-Seiten, geteilten Laufwerken, Code-Kommentaren. Jede Quelle wurde für ein anderes Publikum gebaut und spricht ein eigenes Format: der Datenkatalog für Analysten, die Wiki-Seite für neue Mitarbeitende, der Code-Kommentar nur für die nächste Person, die genau diese Datei öffnet. Nichts davon ist verbunden, dazu kommt das Langzeitgedächtnis der Person, die am längsten dabei ist und das in keinem System steht.

Ein Agent, der eine echte Geschäftsfrage beantworten soll, muss all das ohne Landkarte zusammensetzen. Manchmal klappt das. Häufiger halluziniert er eine plausibel klingende Antwort, weil die echte nicht auffindbar war. Er nennt dann eine Zahl, sauber formatiert, deren Formel eigentlich für ein anderes Team galt.

Das ist kein Retrieval-Problem. Bessere Vektorsuche hilft am Rand, ändert aber nichts am eigentlichen Defizit: Das Wissen war nie in einer Form strukturiert, die Agenten zuverlässig navigieren können. Genau diese Lücke will das Open Knowledge Format schließen.

Wer mit Agenten baut und sich fragt, warum sie ständig generische Antworten liefern, findet die technische Seite davon im Beitrag zu Context Engineering. Kurzfassung: Datenhygiene löst die meisten Agentenprobleme, bevor überhaupt am Modell gedreht werden muss.

Was das Open Knowledge Format eigentlich ist

Google hat OKF v0.1 als offene Spezifikation veröffentlicht, zusammen mit dem knowledge-catalog-Repository auf GitHub. Der Anspruch: ein portabler, herstellerneutraler Standard, der Firmenwissen in einer Form ablegt, die Menschen und KI-Agenten gleichermaßen lesen können, ohne dass jemand zwischen den beiden übersetzen muss.

Das Format ist bewusst minimal, drei Bausteine reichen. Jede Markdown-Datei beschreibt ein Konzept, einen Datensatz, eine Kennzahl, einen Ablauf, und der Dateipfad ist die Identität dieses Konzepts. Markdown-Links zwischen den Dateien bilden einen Wissensgraphen: Verlinkt die Datei zu „wöchentlich aktive Nutzer“ auf die Datei zum Event-Stream-Schema, ist diese Beziehung explizit und navigierbar. Im YAML-Frontmatter ist type das einzige Pflichtfeld, title, description, resource, tags und timestamp sind optional. Die Datei zu „wöchentlich aktive Nutzer“ aus dem Beispiel oben bräuchte im Frontmatter also nur type: metric, alles andere ist Kür.

Ein Bundle ist einfach ein Ordner voller solcher Dateien. Eine optionale index.md gibt Struktur vor und ordnet die Konzepte nach Themenbereichen. Ein optionales log.md hält die Historie fest und zeigt, wann ein Konzept zuletzt aktualisiert wurde. Das hilft einem Agenten einzuschätzen, ob eine Information noch gilt. Ein SDK braucht es nicht, das ganze System lebt in einem Ordner im Versionskontrollsystem.

Die OKF-Spezifikation zitiert Andrej Karpathy: LLMs werden nicht müde, vergessen keinen Querverweis zu aktualisieren und können in einem Durchgang 15 Dateien anfassen. Das Format macht diese Eigenschaft erst nutzbar, indem es Agenten eine konsistente Struktur zum Navigieren gibt. Im Repository liegen drei Beispiel-Bundles, für GA4-E-Commerce-Daten, Stack-Overflow-Daten und öffentliche Bitcoin-Datensätze.

Warum die Analogie zum Betriebssystem trägt

Der Vergleich mit einem Betriebssystem passt gut: die Schicht, von der jeder Prozess startet, gemeinsam genutzt, versioniert, konsistent. Die meisten KI-Projekte in Unternehmen haben dafür aktuell kein Äquivalent. Jeder Agent fängt bei null an und kratzt zusammen, was er gerade findet.

OKF schlägt genau diese gemeinsame Wissensebene vor: ein Ordner mit Konzept-Dateien, der neben dem Code im Versionskontrollsystem liegt, wie Code aktualisiert wird und für Menschen und Agenten aus derselben Quelle lesbar ist. Braucht ein Agent Wissen darüber, wie die Datenpipeline funktioniert, navigiert er durch das OKF-Bundle. Fängt ein neuer Kollege an, liest er dieselben Dateien. Der eigentliche Wert liegt genau darin, in einer einzigen strukturierten Ebene, die beide Seiten ohne Übersetzung nutzen, nicht in einem schickeren Datenkatalog.

Das trifft genau den Unterschied zwischen einem KI-Assistenten und einem KI-Agenten. Ein Assistent kommt mit vagem Kontext noch irgendwie durch. Ein Agent, der autonom in Schleifen läuft, so wie OpenClaw es mit Shell-Zugriff auf eigener Hardware tut, kommt damit nicht durch. Er braucht verlässliche Struktur, sonst driftet er ab.

Wie das aussieht, wenn eine strukturierte Wissensebene tatsächlich in eine Pipeline eingebaut wird, zeigt der Fall der Content Machine: Ein Fünf-Agenten-System übernimmt Recherche, Entwurf und Formatierung. Ein großer Teil der Zuverlässigkeit kommt daher, dass die Eingaben strukturiert sind, bevor überhaupt ein Agent sie anfasst.

Was du frei übernehmen kannst und wo du genauer hinschauen solltest

Das Format selbst ist unbedenklich. Markdown-Dateien, YAML-Frontmatter, alles im eigenen Repository. Keine Herstellerabhängigkeit steckt in der Spezifikation. Googles statischer HTML-Visualizer hält Daten ausdrücklich lokal, dort verlässt nichts die Seite.

Genauer hinschauen solltest du bei Googles gehosteter Tooling-Kette. Der BigQuery Enrichment Agent geht deine Datensätze durch, entwirft OKF-Dokumente und lässt LLM-Durchläufe über sie laufen, um sie mit Schemas und Verknüpfungen anzureichern, alles innerhalb von Google Cloud. Das ist eine andere Entscheidung als die, das Dateiformat zu übernehmen.

Übernimm das offene Format frei. Prüf aber, welches interne Wissen in jede gehostete Pipeline fließt, die es erzeugt oder verwaltet. Es ist dieselbe Prüfung, die du bei jedem Anbieter machen würdest, der deine internen Daten verarbeitet. Vendor-Lock-in schleicht sich oft genau über die Datenebene ein, nicht über das Modell davor. Ein offenes Format macht die Pipeline dahinter deshalb noch nicht automatisch neutral.

Die 5 Prozent, die es schaffen, haben wahrscheinlich kein besseres Modell gefunden

Zurück zur MIT-Zahl. Eine Fehlerquote von 95 Prozent beschreibt Organisationen, die fähige Agenten auf Wissen aufsetzen, das nie dafür gedacht war, von irgendetwas konsumiert zu werden. Das lässt sich nicht durch ein neueres Modell reparieren, weil das Problem gar nicht beim Modell liegt.

Die Unternehmen, denen es gut läuft, fahren keine anderen LLMs. Sie haben die unglamouröse Arbeit gemacht, ihr internes Wissen auffindbar und strukturiert zu machen. OKF ist ein konkreter Vorschlag, wie das aussehen kann: einfache Dateien, explizite Beziehungen, kein proprietäres Format.

Ob OKF am Ende zum branchenweiten Standard wird oder eine nützliche Idee von Google bleibt, das dahinterliegende Prinzip hält so oder so. KI-Projekte, die an der Wissensqualität scheitern, scheitern unabhängig von der Modellgeneration weiter. Die Wissensebene zu reparieren ist schwerer, als das Modell zu aktualisieren, und es zeigt sich nicht in der Demo. Mein Verdacht: genau deshalb überspringen die meisten Teams diesen Schritt.

Wer wissen will, wo man anfängt: Wie viel eine strukturierte Rechercheebene ausmacht, steht in meinem Bericht darüber, wie ich Marktrecherche ohne KI automatisiert habe. Der Unterschied in der Ausgabequalität kam dort größtenteils aus der Qualität der Eingaben. Der pragmatischste erste Schritt bleibt trotzdem klein: ein paar zentrale Konzepte als OKF-Dateien anlegen, prüfen, ob ein Agent sie zuverlässig findet, und von dort aus wachsen.