Unternehmenswissen steckt in Köpfen, Chats und PDFs – so wird es KI-fähig

In den meisten Unternehmen liegt das wertvollste Wissen an den schlechtesten Orten: im Kopf einzelner Mitarbeiter, verstreut über Chat-Verläufe, eingeschlossen in PDFs, die niemand mehr findet. Solange alles läuft, fällt das nicht auf. Es fällt erst auf, wenn jemand das Unternehmen verlässt, wenn ein Projekt nach zwei Jahren wieder aufgegriffen wird, oder wenn eine neue Kollegin Wochen braucht, um Dinge zu verstehen, die längst irgendwo dokumentiert sein müssten.

Mit dem Einzug von KI-Systemen in den Arbeitsalltag bekommt dieses alte Problem eine neue Dringlichkeit. Denn ein Sprachmodell ist nur so gut wie der Kontext, den es bekommt. Und genau dieser Kontext – das spezifische Wissen eines Unternehmens – fehlt den Modellen vollständig. Dieser Artikel ist der Einstieg in eine vierteilige Serie darüber, wie Unternehmen gerade beginnen, ihr Wissen KI-fähig zu machen. Es geht nicht um das nächste Tool, sondern um eine Verschiebung in der Art, wie Organisationen ihr Wissen behandeln.

Wie Unternehmen Wissen verlieren

Wissensverlust ist selten ein dramatisches Ereignis. Er passiert schleichend und an vielen Stellen gleichzeitig.

Das offensichtlichste Leck ist Fluktuation. Wenn eine erfahrene Person geht, verschwindet nicht nur eine Stelle im Organigramm, sondern ein Großteil des nicht dokumentierten Wissens über Kunden, Prozesse, Sonderfälle und die unzähligen kleinen Entscheidungen, die nie aufgeschrieben wurden. Der Nachfolger erbt eine Rolle, aber nicht den Kontext.

Das zweite Leck ist die Fragmentierung der Werkzeuge. Wissen entsteht heute in Slack und Teams, in E-Mail-Threads, in Confluence, in Google Docs, in Tickets, in Meeting-Mitschriften und in lokalen Dateien auf einzelnen Rechnern. Ein typischer Fall: Die finale Entscheidung steht in einem Slack-Thread, die Umsetzung im Ticket, die ursprüngliche Idee im Confluence-Dokument – verknüpft ist nichts davon. Jedes dieser Systeme hat seine eigene Suche, seine eigene Logik, seine eigenen Lücken. Niemand sucht an fünf Orten gleichzeitig, also wird Wissen lieber neu erzeugt als wiedergefunden – und die Fragmentierung verstärkt sich selbst.

Das dritte Leck ist das stille Wissen, das nie verschriftlicht wird, weil es als selbstverständlich gilt. Warum ein Kunde auf eine bestimmte Art angesprochen werden muss, warum ein scheinbar unnötiger Zwischenschritt im Prozess existiert, welche Abkürzung in welchem Fall gefährlich ist – das steht in keinem Dokument. Es lebt in Gewohnheiten und Gesprächen, und es verschwindet, sobald die Person verschwindet, die es trägt.

Das Modell kennt Ihr Unternehmen nicht

Hier treffen sich das alte Wissensproblem und die neue Technologie. Ein großes Sprachmodell weiß erstaunlich viel über die Welt im Allgemeinen – aber nichts über Ihr Unternehmen im Besonderen. Es kennt nicht Ihre Kunden, nicht Ihre Preislogik, nicht Ihre internen Begriffe, nicht die Geschichte eines Projekts. Es hat keinen Zugriff auf das, was Ihr Unternehmen einzigartig macht.

Wer ein Modell ohne diesen Kontext nach internen Dingen fragt, bekommt eine von zwei Antworten: eine allgemeine, die für jedes Unternehmen passt und deshalb für keines wirklich hilft – oder eine erfundene. Fragt man etwa nach der Preislogik eines bestimmten Kundenprojekts, kommt entweder eine generische Antwort („üblicherweise richtet sich Pricing nach…”) oder eine, die plausibel klingt und frei erfunden ist. Sprachmodelle füllen Lücken plausibel, und ohne Faktenbasis wird aus „ich weiß es nicht” schnell eine selbstbewusst formulierte Halluzination. Ob und wie sich das eindämmen lässt, ist eine eigene Frage – eine differenzierte Antwort darauf gibt der Artikel Reduziert RAG wirklich Halluzinationen?.

Das ist die zentrale Einsicht, die im Lärm um immer neue Modelle leicht untergeht. Der Wettbewerb der Anbieter dreht sich um Reasoning-Fähigkeit, Kontextfenster und Geschwindigkeit. Für Unternehmen ist die entscheidende Frage aber eine andere: Wie kommt das eigene Wissen verlässlich in das Modell hinein, im richtigen Moment, in der richtigen Form?

Prompts ersetzen keinen Kontext

Eine verbreitete erste Reaktion ist, in das Prompt-Schreiben zu investieren. Schulungen, Vorlagen, „Prompt-Bibliotheken” – die Idee dahinter ist, dass bessere Fragen bessere Antworten erzeugen. Das stimmt bis zu einem Punkt, aber es verkennt das eigentliche Problem.

Ein perfekt formulierter Prompt ändert nichts daran, dass das Modell die nötigen Fakten nicht hat. Man kann eine Frage beliebig elegant stellen – wenn die Information über den konkreten Kunden, den konkreten Vertrag, den konkreten Prozess nicht vorliegt, kann auch die beste Frage sie nicht herbeizaubern. Der Hebel liegt nicht in der Formulierung, sondern im verfügbaren Kontext. Pointiert gesagt: Prompt Engineering optimiert die Frage – Context Engineering sorgt dafür, dass es überhaupt etwas Belastbares zu beantworten gibt. Diese Verschiebung von „Prompt Engineering” zu „Context Engineering” ist der Kern des Artikels Warum Knowledge-Container wichtiger werden als Prompts.

Der naheliegende Ausweg – relevante Texte einfach per Copy & Paste in den Chat zu kopieren – funktioniert für eine einzelne Frage, skaliert aber nicht. Es setzt voraus, dass jemand bereits weiß, welches Dokument relevant ist und wo es liegt. Genau dieses Wissen fehlt aber oft. Und bei jeder Frage erneut das halbe Intranet zusammenzukopieren, ist keine Arbeitsweise, sondern ein Symptom.

Überall entstehen gerade Wissensbasen

Aus dieser Lage heraus passiert gerade an vielen Stellen dasselbe: Unternehmen fangen an, ihr Wissen bewusst zu strukturieren, damit Maschinen damit arbeiten können. Die Werkzeuge dafür sind unterschiedlich, der Gedanke ist überall gleich.

Notion und ähnliche Workspace-Tools werden zur zentralen Ablage für Prozesse und Projektwissen – komfortabel, aber als Cloud-Dienst mit den bekannten Fragen nach Datenhoheit. NotebookLM von Google zeigt im Kleinen, wie sich ein begrenzter Dokumentenbestand befragen lässt. Klassische Wikis und SOP-Systeme (Standard Operating Procedures) erleben eine Renaissance, weil dokumentierte Prozesse plötzlich nicht nur für Menschen, sondern auch für KI lesbar sein sollen. Und Obsidian wird zunehmend als lokales, dateibasiertes „zweites Gehirn” entdeckt – gerade von datenschutzbewussten Organisationen, weil das Wissen den eigenen Rechner nie verlässt.

Diese Werkzeuge unterscheiden sich in Komfort, Hosting-Modell und Offenheit. Was sie verbindet, ist die Funktion: Sie sind der Versuch, das verstreute Wissen eines Unternehmens an einem strukturierten, durchsuchbaren Ort zu bündeln – als Vorbedingung dafür, dass KI überhaupt sinnvoll damit arbeiten kann. Für strukturierte, flexible Web-Inhalte empfiehlt sich hierbei ein modular aufgebautes Headless CMS, um Daten sauber getrennt von der Präsentationsschicht zu verwalten.

Wenn Wissensstrukturen an Anbieter binden

Viele Organisationen haben längst eine Wissensablage – nur eben eine, die an einen Anbieter gekoppelt ist. Wer stark auf Microsoft 365 setzt, landet fast zwangsläufig bei Copilot; wer in der Google-Welt arbeitet, bei Gemini. Das funktioniert, solange man genau dieses Modell will. Schwierig wird es, sobald sich die Lage ändert – und sie ändert sich derzeit im Monatstakt.

Das eigentliche Risiko ist nicht das einzelne Werkzeug, sondern die Kopplung. Wer die Wissensstruktur direkt an Copilot oder Gemini bindet, übernimmt implizit auch deren Datenmodell, APIs und Zugriffsmuster. Liegen die Daten in proprietären Strukturen und hängen die Workflows an einem Ökosystem, lässt sich ein alternatives Modell – ein lokales Open-Source-System, ein europäischer Anbieter wie Mistral, das nächste deutlich bessere Modell – nur mit Reibung anbinden. Die Wahl des Wissenssystems entscheidet damit indirekt mit, wie frei ein Unternehmen bei der Wahl der KI bleibt.

Damit rückt eine Frage in den Vordergrund, die vor zwei Jahren noch niemand gestellt hat: Wie organisiert man Wissen so, dass die KI austauschbar bleibt? Offene, portable Formate werden hier zum strategischen Vorteil – nicht aus technischer Vorliebe, sondern weil sie verhindern, dass eine Entscheidung von heute die Optionen von morgen verbaut. Wie ein bewusst offenes, dateibasiertes System konkret aussieht, zeigt der nächste Teil dieser Serie am Beispiel Obsidian.

Zwei Ebenen, die man trennen sollte

Bei der Umsetzung lohnt es sich, zwei Ebenen sauber auseinanderzuhalten, weil sie verschiedene Zielgruppen und verschiedene Anforderungen haben.

Die praktisch nutzbare Ebene richtet sich an normale Unternehmen: ein lokales Wissenswerkzeug, eine überschaubare Struktur, eine einfache Anbindung an ein Modell. Das ist mit vertretbarem Aufwand erreichbar und liefert schnell Nutzen.

Die AI-native Infrastruktur-Ebene richtet sich an Entwickler und technisch reife Organisationen: lokale Embeddings, Vektordatenbanken, eigene Pipelines, Agentensysteme. Das ist mächtiger, aber auch deutlich aufwendiger – und nicht jedes Unternehmen braucht es.

Diese Serie behandelt beide Ebenen, aber in der richtigen Reihenfolge. Wer zu früh in die Infrastruktur-Ebene springt, baut mit großem Aufwand ein System um Wissen herum, das noch gar nicht geordnet ist.

Was in dieser Serie folgt

Der nächste Teil wird konkret und zeigt am Beispiel Obsidian, wie sich Unternehmenswissen überhaupt sinnvoll strukturieren lässt – noch fast ohne KI, dafür mit lokalen Dateien, Versionierung und Datensouveränität. Teil drei steigt technisch ein und erklärt, wie KI über RAG wirklich mit diesem Wissen arbeitet: Embeddings, semantische Suche, Vektordatenbanken und die Rolle lokaler und europäischer Modelle. Teil vier schaut nach vorne, auf den Weg vom Notiztool zur KI-Infrastruktur.

Die Reihenfolge ist Absicht. Das technisch Spannende kommt zum Schluss, weil das eigentlich Wichtige am Anfang steht: nicht wie man ein Plugin installiert, sondern warum diese Systeme gerade jetzt entstehen. Der Übergang, der sich hier abzeichnet, geht von „LLMs als Chatbots” hin zu „LLMs als Betriebssystem für Unternehmenswissen”. Wer ihn früh versteht, baut auf der richtigen Grundlage auf.