Vom Notiztool zur KI-Infrastruktur: Wohin sich Wissenssysteme entwickeln

Teil 3 hat gezeigt, wie aus einem geordneten Wissensbestand über RAG ein befragbares Unternehmens-Gehirn wird. An diesem Punkt hat man etwas Funktionierendes: eine Wissensbasis, die auf Fragen antwortet und ihre Quellen nennt. Dieser letzte Teil schaut nach vorne – auf das, was sich aus dieser Grundlage entwickelt, wenn man sie konsequent weiterdenkt.

Obsidian und ein einfaches RAG-Setup sind dabei nicht das Ziel, sondern der Einstieg. Sie sind die sichtbare Spitze einer Entwicklung, die tiefer reicht: weg von der KI als Chatfenster, hin zu persistentem Unternehmenskontext als eigener Infrastrukturschicht.

Von der Suche zum Agenten

Ein RAG-System beantwortet Fragen. Der nächste Schritt sind Systeme, die nicht nur antworten, sondern handeln. Ein Agent kann mehrere Schritte planen, Werkzeuge benutzen und ein Ergebnis erarbeiten statt nur einen Textausschnitt zu liefern.

Auf die Wissensbasis angewandt heißt das: Statt „Wie läuft das Onboarding?” zu beantworten, kann ein Agent das Onboarding-Dokument lesen, die nötigen Schritte ableiten, einen Entwurf für eine Aufgabenliste erstellen und offene Punkte markieren. Die Wissensbasis wird vom Nachschlagewerk zur Arbeitsgrundlage. Wie weit das heute schon trägt und wo die realistischen Grenzen liegen, ordnet die Serie zu KI-Agenten ein – mit der nötigen Nüchternheit gegenüber dem Hype.

Wichtig ist die Reihenfolge: Ein Agent ist nur so verlässlich wie der Kontext, auf dem er arbeitet. Wer Agenten auf ungeordnetem Wissen aufsetzt, automatisiert das Chaos. Deshalb steht die saubere Wissensbasis am Anfang und der Agent am Ende – nicht umgekehrt.

MCP: der gemeinsame Anschluss

Eine der wichtigeren Entwicklungen der letzten Zeit ist ein Standard dafür, wie KI-Systeme auf externe Werkzeuge und Datenquellen zugreifen: das Model Context Protocol (MCP). Vereinfacht ist MCP eine einheitliche Schnittstelle, über die ein Modell mit der Wissensbasis, dem CRM, dem Ticketsystem oder beliebigen anderen Quellen sprechen kann – ohne dass für jede Quelle eine eigene Sonderlösung gebaut werden muss.

Für Unternehmenswissen ist das bedeutsam, weil es das Fragmentierungsproblem aus Teil 1 an der Wurzel angeht. Statt fünf isolierte Wissensinseln zu haben, entsteht eine gemeinsame Anschlussebene, über die ein KI-System auf alle zugreift. Die Wissensbasis wird dann nicht durch Migration vereinheitlicht, sondern durch ein gemeinsames Protokoll erschlossen.

Knowledge Graphs: von Texten zu Beziehungen

RAG findet ähnliche Textstellen. Ein Knowledge Graph geht einen Schritt weiter: Er hält explizit fest, welche Dinge wie zusammenhängen. Kunde A gehört zu Projekt B, das auf Prozess C beruht, der wegen Entscheidung D so aussieht, wie er aussieht. Solche Beziehungen lassen sich abfragen und durchwandern, nicht nur per Ähnlichkeit finden.

Die Verknüpfungen, die in Obsidian zwischen Notizen entstehen, sind bereits ein Vorläufer davon – ein handgepflegtes Netz aus Beziehungen. Der Schritt zum echten Knowledge Graph besteht darin, diese Beziehungen maschinell auswertbar und kombinierbar zu machen. In Kombination mit RAG entsteht ein hybrides System: Die semantische Suche findet die relevanten Inhalte, der Graph liefert die strukturellen Zusammenhänge dazu. Das ist deutlich mächtiger als jeder Ansatz für sich.

Lokale und hybride Architekturen

Mit wachsendem Anspruch wächst auch die Infrastruktur darunter. Auf der entwicklernahen Ebene aus Teil 1 entsteht ein eigener Stack: lokale Modelle über Ollama oder vLLM, eine selbst betriebene Vektordatenbank, Container-Orchestrierung, ein API-Gateway davor, bei Bedarf eigene GPU-Server.

Realistisch ist für die meisten Unternehmen kein reines Entweder-oder, sondern ein hybrides Modell: Sensible Verarbeitung läuft lokal, während für besonders anspruchsvolle Aufgaben gezielt ein starkes externes Modell hinzugezogen wird – mit klarer Kontrolle darüber, welche Daten dabei das Haus verlassen dürfen. Wie sich so etwas datenschutzkonform aufsetzen lässt, zeigen die Artikel zu serverloser KI und DSGVO sowie zu lokaler Hardware mit Proxmox.

Wissen, das gepflegt bleibt

Ein lebendiges System braucht Pflege, sonst veraltet es. Hier zeigt sich ein interessanter Effekt: Dieselbe KI, die das Wissen nutzt, kann helfen, es aktuell zu halten. Aus Meeting-Mitschriften lassen sich Entwürfe für Notizen erzeugen, Widersprüche zwischen Dokumenten lassen sich aufspüren, veraltete Stellen lassen sich markieren.

Damit überträgt sich eine Disziplin aus der Softwareentwicklung auf das Wissensmanagement: Änderungen werden versioniert, geprüft und nachvollziehbar gemacht – Wissen bekommt etwas von der Sorgfalt, die Code längst hat. Die Wissensbasis wird so zu einem System, das mit dem Unternehmen mitwächst, statt einmalig erstellt und dann vergessen zu werden.

Was AI-native wirklich bedeutet

Am Ende dieser Entwicklung steht ein Begriff, der oft fällt und selten präzise gemeint ist: das AI-native Unternehmen. Brauchbar wird er, wenn man ihn nicht als „überall KI” versteht, sondern strukturell: als Organisation, deren Wissen von Anfang an so strukturiert ist, dass Menschen und Maschinen damit arbeiten können.

Das ist weniger spektakulär, als der Begriff klingt, und gerade darin liegt seine Glaubwürdigkeit. Es geht nicht um vollautomatische Unternehmen oder selbstständig agierende Agentensysteme, die alles allein erledigen. Es geht um eine solide Grundschicht: kuratierter Kontext, durchsuchbares Wissen, klare Beziehungen – als Fundament, auf dem KI als Assistenzschicht zuverlässig arbeitet.

Unterm Strich

Die vier Teile dieser Serie beschreiben einen Weg, der bewusst beim Problem beginnt und nicht beim Werkzeug. Zuerst die Einsicht, dass Kontext der eigentliche Engpass ist. Dann die Strukturierung des Wissens in lokalen, maschinenlesbaren Dateien. Dann die technische Brücke über RAG. Und schließlich der Ausblick auf die Infrastruktur, die daraus erwächst.

Die Verlockung ist groß, sofort bei der letzten Stufe einzusteigen – bei Agenten, Knowledge Graphs und eigenem GPU-Cluster. Der nachhaltigere Weg führt von unten: erst das Wissen ordnen, dann es befragbar machen, dann automatisieren. Wer diese Reihenfolge einhält, baut etwas, das trägt. Wer sie überspringt, baut beeindruckende Technik um eine wacklige Mitte. Der Übergang von „LLMs als Chatbots” zu „LLMs als Betriebssystem für Unternehmenswissen” entscheidet sich nicht am Modell – sondern daran, wie gut das Wissen darunter geordnet ist.