Wissen, Daten & Multi-Kontext: Warum Unter­neh­mens­wissen Menschen und Agenten gleich­zeitig hilft

01 Wie KI hilft, das Wissen aus den Köpfen zu heben und aktuell zu halten

Warum klassische Firmen-Wikis veralten und was sich durch KI ändert: Ein Wiki stirbt im Alltag fast immer aus demselben Grund: Die Fachleute, die das Wissen im Kopf haben, haben am wenigsten Zeit, es sauber auszuformulieren und an der richtigen Stelle einzusortieren.

Mit einem Sprachmodell als Strukturierungs-Helfer ändert sich dieser Kreislauf grundlegend:

1. Rohwissen unkompliziert aufnehmen: Ein erfahrener Servicetechniker spricht nach einem kniffligen Einsatz zwei Minuten in eine Sprachmemo; eine Sachbearbeiterin fotografiert ihren Spickzettel mit den Sonderkonditionen; im Ticketsystem wird ein neuer Ausnahmefall geklärt.
2. KI strukturiert und ordnet zu (Entwurfs-Schritt): Ein Kontext-Job liest den Roheingang, sucht über das Inhalts­ver­zeichnis (INDEX.md) die passende bestehende Wissensseite, prüft auf Widersprüche zu bisherigen Regeln und formuliert einen konkreten Ände­rungs­vor­schlag (Diff) mit Quellenverweis.
3. Das Eigentümer-Tor (Menschliche Freigabe): Der eingetragene fachliche Eigentümer der Regel (z. B. die Teamleitung Kundenservice) erhält den fertigen Vorschlag, prüft ihn in dreißig Sekunden und klickt auf „Freigeben“. Warum dieses Tor unverzichtbar ist: Ohne menschliche Freigabe könnte eine einmalige Kulanz-Ausnahme oder ein Missverständnis versehentlich zur dauerhaften Firmenregel für alle Agenten werden.
4. Sofortiger Doppelnutzen: Ab dem Moment der Freigabe greifen sowohl alle Mitarbeitenden (beim Nachschlagen und in der Einarbeitung) als auch alle persönlichen und prozessgebundenen Agenten auf denselben aktuellen Stand zu.

02 Vier Wege, Unter­neh­mens­kon­text anzu­binden (Multi-Kontext-Archi­tektur)

Warum die Refe­renz­ar­chi­tektur mehrere Möglichkeiten bietet, Kontext anzubinden: Unter­neh­mens­kon­text liegt in der Praxis in ganz unterschiedlichen Speicherformen vor (Anthropic: Effective Context Engineering for AI Agents (externe Seite, anthropic.com)). Eine Sammlung von Markdown-Dateien (nach Andrej Karpathys Vorschlag einer LLM Knowledge Base / LLM-Wiki (externe Seite, gist.github.com)) eignet sich hervorragend für Regeln, Entscheidungen und Ein­ar­bei­tungs­wissen. Sekündlich wechselnde Lagerbestände im ERP oder zehntausende gescannte Altverträge im Archiv brauchen dagegen andere Zugriffswege.

Deshalb verbindet der Multi-Backend Kontext-Layer unserer Refe­renz­ar­chi­tektur vier komplementäre Anbindungswege unter einem gemeinsamen Rechte- und Eigentümermodell:

Weg A · Kura­tiertes Regel- und Domä­nen­wissen (Markdown / Karpathy-Variante)

• Warum dieser Weg: Firmenziele, Ent­schei­dungs­re­geln, Freigabegrenzen, Ausnahmen und Ein­ar­bei­tungs­wissen müssen für Menschen im Browser ebenso klar lesbar sein wie für Sprachmodelle. Markdown-Dateien in einem versionierten Git-Repository kommen ohne proprietäre Datenbank aus, lassen sich zeichengenau vergleichen (Diff) und über eine zentrale INDEX.md verknüpfen.
• Wie er unternehmensfähig wird: Im Unterschied zu einem privaten Forschungs-Wiki erhält jede Markdown-Datei im Unternehmen ein verbindliches Kopfschema (Frontmatter) mit fachlichem Eigentümer (eigentuemer), Gültigkeitsstatus (entwurf | vorschlag | freigegeben), Prüfdatum (pruef_datum) und Leseklasse (leseklasse). Agenten lesen im Produktivbetrieb ausschließlich Dateien mit dem Status freigegeben.
• Wo die Grenze liegt: Ungeeignet für sekündlich wechselnde Bestandsdaten (Preise, Lager, offene Posten) oder riesige ungekürzte PDF-Archive.

Weg B · Doku­menten-Zerlegung, Layout-Struktur & Archiv-Kontext (Document Intel­li­gence, OCR & Hybrid-Suche)

• Warum reine Buch­sta­be­ner­ken­nung (klassisches OCR) für KI-Kontext zu kurz greift: Jedes gewachsene Unternehmen besitzt tausende Bestandsdokumente (Rahmenverträge, Rechnungen, technische Datenblätter, Prüfprotokolle, PDF-Scans auf Netzlaufwerken oder in SharePoint/OneDrive). Würde man über diese Seiten lediglich eine einfache Texterkennung laufen lassen, entstünde ein flacher Zeichenbrei, in dem der räumliche Zusammenhang verloren geht. Für ein Sprachmodell ist bei einem Geschäftsdokument aber entscheidend, wie Daten und Texte räumlich (vertikal und horizontal) zusammengehören:
  1. Vertikale vs. horizontale Lesereihenfolge (Mehrspaltigkeit & Blöcke): Auf einer zweispaltigen Vertragsseite oder einem Formular gehören die Zeilen vertikal innerhalb einer Spalte zusammen. Liest ein einfacher Parser einfach waagerecht über die gesamte Seitenbreite, verschmelzen Halbsätze aus der linken und rechten Spalte zu unbrauchbarem Text.
  2. Tabellen-Zuordnung (Kreuzung aus Zeile und Spalte): Eine Zahl wie 420,00 EUR oder 14 Tage bekommt ihre Bedeutung erst durch die Kombination aus dem Spaltenkopf vertikal darüber und der Posi­ti­ons­be­zeich­nung horizontal links daneben. Deshalb muss die Dokumentenstrecke Tabellen als zusammenhängendes Gitter (Markdown- oder HTML-Tabelle) übergeben.
  3. Texte, die zu Grafiken und Diagrammen gehören: In Berichten und Datenblättern stehen entscheidende Zahlen oft als Ach­sen­be­schrif­tung, Legende oder Säulenwert mitten in einer Grafik. Werden diese Schnipsel isoliert ausgelesen, schweben Zahlen wie 210 oder Q3 zusammenhanglos im Raum. Eine gute Zerlegung fasst die Grafik samt ihrer verbindenden Achsenlinien, Beschriftungen und der Bildunterschrift zu einer gemeinsamen Region zusammen, damit ein Vision-Modell Grafik und Text gemeinsam im Kontext auswerten kann.
• Wie er umgesetzt wird (Gemietete Dienste vs. eigener Aufbau): Für diese strukturierte Dokument-Zerlegung (Document Layout Analysis) gibt es zwei bewährte Wege: Entweder nutzt man spezialisierte Cloud-Dienste wie Microsoft Azure AI Document Intelligence (externe Seite, learn.microsoft.com) (früher Azure Form Recognizer, mit dem prebuilt-layout-Modell), AWS Textract oder Google Document AI (Layout Parser), die Seiten direkt in Regionen, Lesereihenfolgen, Schlüssel-Wert-Paare und Markdown-Tabellen zerlegen. Oder man betreibt (wie in unserem eigenen Evernote-Nachbau, dokumentiert in den Beiträgen Wo in der eigenen Texterkennung das Modell sitzt und Wie eine Maschine ein Dokument zerlegt) eine mehrstufige eigene Pipeline, die eingebettete PDF-Textschichten, geometrische Strich-/Rahmen-Regeln, ein lokales Layout-Modell und ein Vision-Sprachmodell für Diagramme und Handschrift kombiniert. Darüber liegt eine Hybrid-Suche (exakte Volltextsuche BM25 plus Vektor-Embeddings) mit striktem Berechtigungs- und Gültigkeitsfilter vor dem Prompt.
• Wo die Grenze liegt: Liegen in einem ungepflegten Ordner fünf veraltete und eine aktuelle Richtlinie ohne Metadaten nebeneinander, zieht eine reine Ähnlichkeitssuche widersprüchliche Aussagen in den Kontext. Verbindliche Regeln gehören deshalb nach Weg A.

Weg C · Führende Bestands­daten in Echtzeit (Live-Adapter via SQL, API & MCP)

• Warum dieser Weg: Ob ein Kunde in Umsatzklasse A oder B eingestuft ist, ob eine Rechnung bezahlt wurde oder ob ein Ersatzteil auf Lager liegt, entscheidet sich im führenden System (ERP, CRM, Warenwirtschaft, Ticketsystem). Würde man solche beweglichen Fakten in Markdown-Dateien oder Vektordatenbanken kopieren, arbeiteten Agenten ständig mit veralteten Ständen.
• Wie er umgesetzt wird: Über streng typisierte, schreibgeschützte Datenadapter (Read-Only SQL-Views, REST-Endpunkte oder MCP-Ressourcen) fragt der Context-Router die führenden Systeme im Moment der Auf­ga­ben­be­ar­bei­tung in Echtzeit ab.
• Wo die Grenze liegt: Ein Live-Adapter liefert den exakten Statuswert (z. B. Bestellwert: 420 EUR, Kundenklasse: B). Für die Ermessensregel, wie der Betrieb mit diesem Fall umgehen soll, wird Weg C mit Weg A kombiniert.

Weg D · Prozess- und Erfah­rungs­wissen (Vorgangs- & Ausnahme-Gedächtnis)

• Warum dieser Weg: Viele wichtige Betriebsregeln entstehen im Arbeitsalltag, wenn erfahrene Mitarbeitende einen KI-Entwurf abändern oder einen kniffligen Sonderfall lösen.
• Wie er umgesetzt wird: Wenn ein Sachbearbeiter einen vorbereiteten Entwurf am Freigabetor korrigiert, speichert das System die Abweichung strukturiert mit. Ein periodischer Auswertungs-Lauf bündelt wiederkehrende Korrekturen und legt sie dem Facheigentümer als Regel-Ergänzung für Weg A sowie als neuen Prüffall für den Modellwechsel-Test vor.

03 Gegen­probe am konkreten Fall: Dasselbe Sprach­mo­dell unter drei Kontext-Zuständen

Warum selbst das beste Sprachmodell ohne diesen Kontext-Layer scheitert: Das folgende Beispiel aus dem Kundenservice zeigt, wie identische Modellgewichte auf dieselbe Anfrage reagieren:

1. Zustand 1 · Nacktes Sprachmodell (Nur allgemeines Trainingswissen):
   Das Modell greift auf allgemeines Wissen über kaufmännische Rügepflichten zurück und formuliert ein höfliches Ableh­nungs­schreiben („Nach 9 Tagen leider verfristet“). Ergebnis: Klingt sprachlich perfekt, verärgert aber einen wichtigen B-Kunden und verstößt gegen die interne Kulanzregel der Firma.
2. Zustand 2 · Ungeordneter Dokumenten-Dump (Naives RAG ohne Eigentümer):
   Die Vektorsuche findet im Laufwerk ein altes PDF (2021: „5 Tage Frist“) und eine neuere Notiz (2025: „14 Tage Kulanz“), kennt aber weder den echten Kundenstatus aus dem CRM noch die Belegpflicht für den Speditionsregress. Das Modell sagt die 420 € sofort zu. Ergebnis: Teurer Folgefehler, weil ab 250 € ohne Foto der Umverpackung die Versicherung ausfällt.
3. Zustand 3 · Gepflegter Multi-Kontext-Layer (Weg A + Weg C + Weg B):
   Der Context-Router lädt die freigegebene wiki/service/kulanzregeln.md (Weg A: 14 Tage Frist für A/B-Kunden; ab 250 € Verpackungsfoto Pflicht), fragt live im CRM den Kundenstatus ab (Weg C: Umsatzklasse B) und prüft die Ticket-Anhänge (Weg B). Ergebnis: Der Agent stützt sich auf alle drei Quellen und legt dem Sachbearbeiter den passenden Entwurf vor: „Frist ist gewahrt, aber für die Freigabe über 420 € fehlt noch das Foto der Umverpackung. Rückfrage-Mail an den Kunden ist vorbereitet.“