Nicht die KI ist die Revolution. Freies Wissen ist es.

In jeder Firma, in der ich gearbeitet habe, gab es diesen einen Kollegen. Er wusste, warum die Maschine bei Auflagen über zwanzigtausend die Farbe zieht. Er wusste es seit vierzehn Jahren. Aufgeschrieben hat er es nie.

Das war kein Versehen. Das war sein Arbeitsplatz. Wer als Einziger weiß, wie etwas läuft, wird nicht wegrationalisiert — so denkt man, wenn man lange genug in einem Betrieb sitzt, in dem regelmäßig jemand gehen musste. Ich habe das nie verurteilt. Ich habe es verstanden. Und trotzdem hat es die Firma jedes Mal Geld gekostet, wenn der Mann in Urlaub war.

Vor Kurzem habe ich mir an einem Nachmittag ein Wissens-Wiki gebaut, das eine KI pflegt und ich nur lese. Seitdem denke ich über etwas ganz anderes nach als über meine eigenen Notizen. Ich denke darüber nach, was passiert, wenn so ein Ding nicht auf meinem Mac liegt — sondern auf einem internen Server, hinter einem Firmen-Login, für eine ganze Abteilung.

Wissen war immer Macht. Genau das war das Problem.

Gatekeeping ist selten böse gemeint. Es entsteht von selbst, überall dort, wo Wissen im Kopf entsteht und im Kopf bleibt. Der Netzwerker, der die Firewall-Regeln im Gefühl hat. Die Kollegin aus der Kalkulation, die weiß, welcher Kunde welche Sonderkondition hat und warum. Der Entwickler, der als Einziger versteht, warum dieses eine Skript um 3:40 Uhr laufen muss.

Jeder von ihnen würde sein Wissen teilen, wenn man ihn fragt. Das ist der Punkt: wenn man fragt. Wissen, das nur auf Anfrage herausgegeben wird, ist ein Flaschenhals. Es macht den Wissenden wichtig und alle anderen abhängig. Und es stirbt mit der Kündigung.

Die Antwort darauf heißt seit dreißig Jahren: Dokumentation. Confluence, SharePoint, ein Wiki auf einem alten Server, den keiner mehr anschaut. Ich kenne kaum eine Firma, in der das funktioniert hat. Nicht, weil die Leute faul sind. Sondern weil Dokumentation eine Arbeit ist, die niemandem gehört.

Warum Firmenwikis sterben

Schauen Sie sich ein zwei Jahre altes Firmenwiki an. Sie finden dort drei Sorten Seiten: die eine, die jemand am ersten Tag mit Begeisterung angelegt hat. Die zweite, die halb fertig ist. Und die dritte, die noch stimmt, aber niemand weiß, ob sie noch stimmt — was auf dasselbe hinausläuft.

Der Grund ist mechanisch, nicht kulturell. Ein Wiki muss konsistent gehalten werden. Ändert sich ein Prozess, betrifft das nicht eine Seite, sondern zehn. Querverweise, Screenshots, die Anleitung im Nachbarordner, die veraltete Zahl im Kapitel weiter unten. Diese Arbeit wächst quadratisch mit dem Bestand — der Nutzen nur linear. Irgendwann kippt es, und ab da pflegt niemand mehr.

Menschen sind schlecht in dieser Arbeit. Nicht weil sie es nicht könnten, sondern weil es stumpfe Buchführung ist, die keiner belohnt. Fünfzehn Seiten in einem Durchgang anfassen und keinen Querverweis vergessen — dafür gibt es keine Beförderung.

Einer KI ist das egal. Sie macht genau diese Arbeit, ohne zu murren, ohne zu vergessen, und sie macht sie in Minuten. Das ist keine kleine Verbesserung. Das ist die Aufhebung der Bedingung, an der jedes Wiki bisher gestorben ist.

Das Muster: die KI schreibt, der Mensch liest und prüft

Die Idee dahinter ist unspektakulär und deshalb gut. Statt Rohdokumente in eine Suchmaschine zu kippen und die KI bei jeder Frage neu darin wühlen zu lassen, baut und pflegt die KI ein dauerhaftes Wiki aus verlinkten Markdown-Seiten. Kommt eine neue Quelle dazu — ein Protokoll, ein Vertrag, ein Herstellerhandbuch, ein Ticket — liest die KI sie, zieht das Wesentliche heraus und arbeitet es in die bestehenden Seiten ein. Sie aktualisiert die Prozessseite, ergänzt Querverweise und markiert ausdrücklich, wo das Neue dem Alten widerspricht.

Die Rollen sind klar getrennt. Menschen kuratieren, fragen, entscheiden und prüfen. Die KI führt Buch. Der entscheidende Unterschied zur Suche: Das Wiki ist ein Bestand, der sich verzinst. Die Synthese ist schon da, wenn jemand fragt — sie wird nicht bei jeder Frage neu zusammengestückelt.

Und beide Seiten lesen dasselbe. Eine Markdown-Datei ist für einen Menschen lesbar und für ein Sprachmodell lesbar. Kein Export, kein Konnektor, keine zweite Wahrheit für die Maschine. Das klingt nach einem technischen Detail und ist in Wirklichkeit der ganze Trick.

Das Format: OKF, und warum es im Unternehmen zählt

Damit man einem maschinengepflegten Wiki trauen kann, braucht es ein Format mit Vertrauensmodell. Google Cloud hat dafür im Sommer das Open Knowledge Format veröffentlicht — ein Verzeichnis aus Markdown-Dateien mit YAML-Frontmatter, mehr nicht. Version 0.2 ist am 24. Juli 2026 erschienen und bringt genau die Felder mit, die im Unternehmen den Unterschied machen.

Pflicht ist ein einziges Feld: type. Alles andere ist optional — und Konsumenten dürfen eine Seite nicht ablehnen, nur weil ein optionales Feld fehlt. Interessant sind die drei Familien, die v0.2 ergänzt hat:

Dazu zwei reservierte Dateien: index.md als Katalog, den jeder Agent vor einer Antwort liest, und log.md als chronologisches Protokoll aller Änderungen. Das ersetzt bei überschaubarer Größe die komplette Such-Infrastruktur. Kein Embedding-Index, keine Vektordatenbank, nur ein gepflegtes Inhaltsverzeichnis. Und ein Lint-Skript kann maschinell prüfen, ob das Bundle konform ist — Frontmatter parsebar, type überall gesetzt, Fußnoten sauber verknüpft.

verified ist das Feld, an dem sich für mich entscheidet, ob so ein System in einer Firma tragfähig ist. Eine Seite, die die KI geschrieben hat und die niemand gegengelesen hat, ist im Frontmatter ehrlich als unverifiziert erkennbar. Erst wenn ein Mensch sie geprüft hat, kommt sein Name mit Zeitstempel rein. In drei Monaten weiß dann jeder, welchen Seiten er glauben darf — und welchen nicht. Das ist kein Nice-to-have. Das ist der Unterschied zwischen einer Wissensbasis und einem Gerüchtehaufen mit Syntax-Highlighting.

Das Setup: ein Server, ein Login, ein Wiki

Technisch ist die Sache erschreckend unspektakulär. Genau das ist die gute Nachricht.

Das Wiki ist ein Git-Repository. Markdown-Dateien, sonst nix. Gitea oder GitLab auf eigener Hardware, das reicht. Versionsgeschichte gratis, jede Änderung nachvollziehbar mit Autor und Zeitstempel, Rollback jederzeit. Wer schon mal versucht hat, in einem Confluence herauszufinden, wer wann was gelöscht hat, weiß, was das wert ist.

Gelesen wird im Browser. Ein statischer Generator rendert die Markdown-Dateien zu einer internen Website — MkDocs, Quartz, Docusaurus, die Auswahl ist groß und die Unterschiede sind kleiner, als die Anbieter behaupten. Wer lieber im Editor arbeitet, öffnet dasselbe Verzeichnis in Obsidian und bekommt die Graph-Ansicht dazu. Beides liest dieselben Dateien.

Davor kommt der föderierte Login. Ein Reverse Proxy mit OIDC oder SAML gegen den Identity Provider, den die Firma sowieso schon hat — Entra ID, Google Workspace, Keycloak, Authentik. Kein zweiter Benutzerstamm, keine Passwortliste, die jemand pflegen muss. Wer die Firma verlässt, wird im Verzeichnis deaktiviert und ist damit auch aus dem Wiki draußen. Die Gruppen aus dem IdP steuern, wer welchen Bereich sieht: die Personalabteilung nicht zwingend dasselbe wie die Produktion.

Und die KI bekommt einen Zugang wie ein Mitarbeiter. Sie liest das Repository, schreibt Änderungen — und zwar als Pull Request, nicht direkt in den Hauptzweig. Ein Mensch schaut drauf, merged, und der Merge ist der Moment, in dem verified gesetzt wird. Der Review-Prozess, den Entwickler seit zwanzig Jahren für Code benutzen, funktioniert für Wissen exakt genauso.

Dazu ein Schema-Dokument im Wurzelverzeichnis — CLAUDE.md, AGENTS.md, der Name ist egal. Darin stehen die Regeln: Wie sieht eine Seite aus, welche Ordner gibt es, was darf die KI anfassen und was nicht, wie läuft die Verarbeitung neuer Quellen. Das ist der Vertrag zwischen Mensch und Maschine, und er ist der Unterschied zwischen einem disziplinierten Bibliothekar und einem Chatbot, der Dateien anlegt. Ich arbeite in meinen Web-Projekten nach demselben Prinzip: erst das Schema, dann die Arbeit.

Drei Schichten, die man sauber trennen sollte: raw/ für Rohquellen, die nie verändert werden. Das gepflegte Wiki, das der KI gehört. Und das Schema dazwischen. Wenn diese Trennung steht, ist der Rest Fleißarbeit.

Die drei Handgriffe im Alltag

Ein System ist nur so gut wie die Gewohnheiten, die es tragen. Drei reichen — und alle drei stehen im Schema-Dokument, damit jeder Agent sie gleich ausführt.

Eingang verarbeiten. Alles, was reinkommt, landet zuerst in einem Posteingang-Ordner: geclippte Artikel, Herstellerdokumentation, das Protokoll aus dem Jour fixe, der Ticket-Export. Auf Zuruf arbeitet die KI den Stapel ab — Quellenseite schreiben, betroffene Prozess- und Konzeptseiten aktualisieren, Widersprüche ausdrücklich markieren, Quelle ins Archiv verschieben, Index und Log nachziehen. Ein einzelnes Dokument darf dabei ruhig zehn Seiten berühren. Das ist kein Nebeneffekt, das ist der Sinn der Sache.

Stand sichern. Der Handgriff, der im Team am meisten bringt. Jede Arbeitssitzung — egal ob ein Mensch ein Projekt abschließt oder eine KI-Session an einem Thema gearbeitet hat — schreibt am Ende ihren Stand in die passende Projektseite: was existiert, welche Entscheidungen mit welcher Begründung fielen, was offen ist, womit der Nächste anfangen sollte. Danach übernimmt der Kollege die Seite, nicht den Chatverlauf. Ich benutze dafür einen festen Prompt-Baustein, den ich in jedes Projekt kopiere — Prompts baut man, man rät sie nicht.

Wiki-Check. Einmal die Woche lässt jemand die KI über den Bestand schauen: Wo widersprechen sich zwei Seiten? Welches Verfallsdatum ist überschritten? Welche Seite hat keinen eingehenden Link mehr? Welches Konzept wird ständig erwähnt, hat aber keine eigene Seite? Das Ergebnis ist eine kurze Liste, keine Aufgabe. Abarbeiten dauert zwanzig Minuten.

Onboarding, wie wir es kennen, wird überflüssig

Das ist der Teil, der mich am meisten umtreibt.

Ein neuer Mitarbeiter kommt heute in eine Firma und wird angelernt wie ein Schulkind. Zwei Wochen Einarbeitungsplan, drei Kollegen, die ihm zwischen zwei Terminen erklären, wie es hier läuft. Er darf nicht zu oft fragen, weil alle beschäftigt sind. Also fragt er zu wenig, macht Fehler, und die Fehler kosten mehr als die Fragen gekostet hätten. Nach sechs Monaten kann er den Job. Ein halbes Jahr, in dem er im Wesentlichen rekonstruiert hat, was im Haus längst bekannt war.

Jetzt stellen Sie sich denselben Menschen an Tag eins vor einem Wiki vor, in dem alles steht. Nicht nur, wie der Prozess läuft, sondern warum er so läuft. Welche Entscheidung wann getroffen wurde und mit welcher Begründung. Was mal probiert wurde und nicht funktioniert hat. Er fragt nicht mehr einen Kollegen, der gerade keine Zeit hat — er fragt das Wiki, im Zweifel über eine KI, die ihm die Antwort aus zwölf Seiten zusammenbaut und die Quellen dazu nennt.

Er ist nach zwei Wochen produktiv statt nach sechs Monaten. Und der Kollege, der ihn sonst angelernt hätte, arbeitet weiter an seinem eigenen Zeug.

Der Nebeneffekt ist noch größer: Die Firma hört auf, ihr Gedächtnis in Köpfen zu lagern. Wenn jemand geht, geht ein Mensch — nicht ein Kapitel Betriebswissen. Das ist der Unterschied zwischen einem Unternehmen, das lernt, und einem, das alle paar Jahre von vorne anfängt.

Der unbequeme Teil

Ich will das nicht schöner malen, als es ist. Transparenz ist nicht für jeden angenehm, und drei Einwände sind berechtigt.

Nicht jeder will das. Wer seine Position auf exklusivem Wissen aufgebaut hat, verliert etwas — und zwar real, nicht eingebildet. Ein Wiki einzuführen ist deshalb kein IT-Projekt, sondern eine Führungsentscheidung. Wenn die Geschäftsleitung nicht klarmacht, dass Wissen teilen belohnt wird und nicht bestraft, bleibt das Wiki halbleer, egal wie gut die Technik ist. Die Technik ist der einfache Teil. Sie war es immer.

Nicht alles gehört rein. Personalakten, Gehälter, laufende Verhandlungen, alles mit Personenbezug — Finger weg oder sauber getrennt, mit eigenen Zugriffsgruppen aus dem IdP. Und wenn im Wiki Daten über Beschäftigte auftauchen, ist der Betriebsrat kein Hindernis, sondern der richtige Ansprechpartner, bevor das Ding produktiv geht. Ich bin kein Jurist, und das hier ist kein Rechtsrat. Aber wer diese Frage erst nach dem Rollout stellt, macht sich das Leben unnötig schwer.

Und es bleibt Arbeit. Weniger als vorher, aber nicht null. Jemand muss Quellen einwerfen. Jemand muss prüfen und verified setzen. Jemand muss den Wiki-Check laufen lassen. Das kostet vielleicht eine Stunde pro Woche für eine Abteilung. Verglichen mit dem, was ein gepflegtes Confluence gekostet hat, ist das nix.

Warum ich das für wichtiger halte als die KI selbst

Über KI wird derzeit hauptsächlich geredet, als ginge es um Effizienz. Schneller Texte, schneller Code, schneller Präsentationen. Das ist alles wahr und alles ziemlich langweilig.

Das, was hier passiert, ist etwas anderes. Zum ersten Mal fällt die Pflegearbeit weg, die freies Wissen in Organisationen immer verhindert hat. Nicht der Wille hat gefehlt — die Kapazität hat gefehlt. Jetzt ist sie da, sie kostet fast nix, und sie arbeitet auf einer offenen, prüfbaren Markdown-Datei.

Ich sehe darin dieselbe Bewegung, die ich schon bei Open Source erlebt habe, als ich 2003 damit angefangen habe: Nicht das Werkzeug war die Revolution, sondern dass der Quelltext offen lag. Jeder konnte lesen, prüfen, weiterbauen. Genau das passiert gerade mit Betriebswissen. Und wie damals ist das Format wichtiger als der Anbieter — ein Verzeichnis mit Markdown-Dateien läuft in zehn Jahren noch, wenn die Firma hinter dem Werkzeug längst verkauft ist. Offene Formate überleben ihre Hersteller.

Ein Wiki ist kein Archiv. Es ist das Gedächtnis einer Organisation — und Gedächtnis, das niemand teilen darf, heißt Vergessen mit zusätzlichen Schritten.

Die KI ist nicht die Revolution. Sie ist der Bibliothekar, der endlich zur Verfügung steht. Die Revolution ist, dass Wissen aufhört, jemandem zu gehören.

Quellen: Open Knowledge Format v0.2 (Google Cloud, veröffentlicht am 24. Juli 2026) sowie die OKF-Spezifikation im Repository GoogleCloudPlatform/knowledge-catalog. Die Angaben zu Frontmatter-Feldern, reservierten Dateien und Konformität stammen aus der Spezifikation, nicht aus meiner Erinnerung.