Warum KI nicht skaliert: Das Kontext-Problem erklärt
KI ist in den meisten Unternehmen angekommen. Tools sind lizenziert, Piloten sind gelaufen, Teams haben gelernt, Prompts zu schreiben. Und trotzdem passiert in den meisten Meetings das Gleiche: Irgendjemand reviewt am Ende jeden Output. Manuell. Immer wieder.
Das ist die Supervision-Falle. Und fast jedes Team, mit dem ich spreche, steckt darin.

GPT-4o, Claude, Gemini – sie alle liefern in kontrollierten Umgebungen beeindruckende Ergebnisse. Das Problem entsteht danach. Wenn KI auf echte Unternehmensdaten trifft. Auf Altdaten, Silos, halb gepflegte Systemdokumentationen, Wissen, das in den Köpfen von drei Mitarbeitenden steckt, die schon lange hier sind.
Das ist das Kontext-Problem. Und auch das ist ein Architekturproblem.
Dieser Artikel erklärt, was Kontext für KI wirklich bedeutet, warum die meisten Teams auf einem frühen Reifegrad feststecken und was es architektonisch braucht, um KI produktiv loszulassen.
Die Supervision-Falle: Was wirklich passiert
Ich führe regelmäßig Gespräche mit Digitalverantwortlichen, die sich über dasselbe Muster beklagen: KI erzeugt Texte, Analysen, Kategorisierungen, aber niemand traut dem Ergebnis genug, um es ohne Prüfung zu verwenden. Also prüft jemand. Immer.
Das ist kein Zeichen mangelnden Vertrauens in KI im Allgemeinen. Es ist ein rationales Verhalten gegenüber einem System, das den eigenen Unternehmenskontext nicht kennt. Ein Modell weiß, was im Internet steht. Es weiß, was in seinen Trainingsdaten stand. Es weiß nichts über eure Produkthierarchie, eure Kundensegmente, eure internen Klassifikationsregeln, eure aktuellen Preisstrukturen oder die Ausnahmen, die das Team seit Jahren kennt und die nirgends dokumentiert sind.
Wer ein KI-System so einsetzt, bekommt generische Qualität. Generische Qualität erfordert Supervision. Supervision kostet Zeit. Zeit ist der ROI, den KI eigentlich einsparen sollte.
Der Zirkel ist geschlossen. Und er öffnet sich nicht durch ein besseres Modell.
Was Kontext für KI bedeutet – Konkret erklärt
Kontext ist alles, was ein KI-System wissen muss, um eine Aufgabe verlässlich zu erledigen.
Kontext bedeutet: Welche Produkte gehören zu welcher Kategorie, nach welcher internen Systematik? Was bedeutet ein bestimmtes Attribut im Datensystem? Was ist die aktuelle Preisregel für Segment B? Was hat das letzte Meeting zu diesem Thema ergeben und in welchem System liegt das Protokoll? Das betrifft nicht nur interne Prozesse: Auch personalisierte Kundenansprache scheitert am selben Problem – ein Modell ohne Zugriff auf echte Kundensegmente und Produktdaten liefert generische Empfehlungen statt relevanter Inhalte.
Kein Modell der Welt hat darauf von sich aus Zugriff. Es kann nur mit dem arbeiten, was ihm zur Verfügung gestellt wird. Das ist der Kontext. Und der fehlt in den meisten Produktivumgebungen.
Dabei mangelt es selten an dem Willen, häufig liegt es an drei strukturellen Problemen:
- Wissen steckt in Dokumenten, die keine Maschine sinnvoll auslesen kann. PDFs ohne Struktur, Word-Dateien mit Versionschaos, SharePoint-Ordner, die seit Jahren niemand aufgeräumt hat.
- Wissen steckt in Köpfen. Erfahrene Kolleginnen und Kollegen wissen, wie Dinge laufen. Dieses Wissen ist nicht formalisiert, nicht strukturiert, nicht abrufbar.
- Wissen steckt in Systemen, die nicht miteinander reden. PIM, ERP, CRM, DAM – jedes System pflegt seinen eigenen Ausschnitt der Realität. Eine KI, die auf eines davon Zugriff hat, sieht ein Fragment.
Das Ergebnis: KI läuft bei 60 % der Arbeit mit – in den Bereichen, wo allgemeines Wissen ausreicht. Bei den restlichen 40 % bricht Qualität ein, weil der spezifische Unternehmenskontext fehlt. Und diese 40 % sind genau die, die wirklich zählen.
Das Reifegradmodell: Drei Zonen, eine ehrliche Einordnung
Ich arbeite intern mit einem einfachen Modell, das beschreibt, wo KI heute steht und was es braucht, um weiterzukommen.

Zone 1 – Assisted: KI unterstützt, Menschen entscheiden alles
Das ist der aktuelle Stand der meisten Unternehmen.
KI erzeugt Entwürfe, Vorschläge, Zusammenfassungen. Ein Mensch prüft jeden Output. Supervision ist nicht optional, sie ist Pflicht. Das System kann nicht zwischen einem guten und einem schlechten Vorschlag unterscheiden, weil es den Kontext nicht kennt, der diese Unterscheidung ermöglicht.
Assisted ist kein Versagen. Es ist ein legitimer Ausgangspunkt. Aber es ist kein Ziel.
Zone 2 – Informed: KI hat Zugriff auf strukturierten Unternehmenskontext
Hier beginnt die echte Produktivität.
Ein Informed-System hat Zugriff auf interne Daten: Produktdaten, Kategorisierungsregeln, Kundensegmente, aktuelle Dokumente. Es kann Fragen beantworten, die über allgemeines Wissen hinausgehen. Vertrauen wächst, weil die Outputs nachvollziehbar sind.
Der Weg von Zone 1 zu Zone 2 führt nicht über ein besseres Modell. Er führt über den Context Layer – die Schicht, die Unternehmensdaten strukturiert, aktuell hält und für KI-Systeme abrufbar macht.
Zone 3 – Autonomous: KI handelt, eskaliert nur bei echter Unsicherheit
Das ist das Ziel, das viele beschreiben und wenige erreicht haben.
Ein autonomes System trifft Entscheidungen auf Basis von vollständigem Kontextzugriff. Es eskaliert, wenn es unsicher ist. Es protokolliert, was es entschieden hat und warum. Ein Mensch greift nur ein, wenn das System das verlangt.
Zone 3 setzt Zone 2 voraus. Ohne vollständigen, verlässlichen Kontextzugriff gibt es keine produktive Autonomie. Es gibt nur autonome Fehler.
Was Zone 3 architektonisch voraussetzt – Enterprise RAG
Der Begriff RAG steht für Retrieval-Augmented Generation. Dahinter steckt ein einfaches Prinzip: Bevor das Modell antwortet, holt es sich den relevanten Kontext aus einer Wissensbasis – in Echtzeit, aus echten Unternehmensdaten.
Das klingt nach einem technischen Detail. Es ist ein architektonischer Paradigmenwechsel.
Der Unterschied zu dem, was die meisten heute einsetzen, ist erheblich. Viele Teams arbeiten mit manuell gepflegten Rules-Files oder System-Prompts. Jemand schreibt auf, was das Modell wissen soll. Jemand aktualisiert diese Datei, wenn sich etwas ändert. Jemand merkt, wenn sie veraltet ist.
Das skaliert nicht, das erzeugt Pflegeaufwand, der mit der Komplexität des Unternehmens wächst. Und es erklärt, warum Teams irgendwann aufhören, den Rules-Files zu vertrauen – und wieder anfangen, jeden Output zu prüfen.
Enterprise RAG funktioniert anders. Das System verbindet sich mit den echten Datenquellen wie PIM, DAM, ERP und DMS. Es ruft Kontext ab, wenn er gebraucht wird, nicht wenn jemand Zeit hatte, eine Datei zu pflegen. Änderungen in den Quelldaten sind sofort verfügbar.
Das ist der Context Layer, der Zone 2 und Zone 3 erst möglich macht.
Aktuelle Daten bestätigen die Relevanz dieses Ansatzes. Der RAG-Markt wächst von 1,2 Milliarden US-Dollar im Jahr 2024 auf prognostizierte 9,86 Milliarden bis 2030 – ein jährliches Wachstum von rund 42 %. 72 % des RAG-Marktes entfallen auf große Unternehmen, die RAG primär für Wissensmanagement und interne Suche einsetzen. Für den gehobenen Mittelstand gilt das nicht weniger — im Gegenteil: Wer mit schlankeren Teams arbeitet, kann sich manuelle Kontext-Pflege noch weniger leisten als ein Konzern mit eigener Data-Engineering-Abteilung. Und eine aktuelle Analyse zeigt deutlich: 2026 ist RAG kein Modell-Problem mehr, sondern ein Retrieval Engineering Problem. Die Performance-Unterschiede entstehen durch bessere Kontextarchitektur.
Silos als strukturelles Kontextproblem – Meine Einschätzung
Ich sage das direkt, weil ich es für unterschätzt halte: Die meisten Kontextprobleme in Unternehmen sind Organisationsprobleme.
Was viele Unternehmen falsch machen, ist sich in Silos zu organisieren. Jeder Bereich optimiert seinen eigenen Datenauschnitt. Kein Team verantwortet die Datenqualität ganzheitlich. Wissen bleibt im Kopf statt im System. Das ist keine Kritik. Es ist ein strukturelles Muster, das ich in fast jedem größeren Unternehmen sehe. Und es produziert direkt das Kontext-Problem, das KI-Systeme ausbremst.
Ein KI-System, das auf eine gut gepflegte, vollständige Produktdatenbank zugreift, liefert andere Ergebnisse als eines, das auf drei widersprüchliche Excel-Exporte aus unterschiedlichen Teams trifft. Die Differenz liegt nicht im Modell. Sie liegt in der Datenqualität, die das Team dahinter verantwortet – oder eben nicht.
Was zählt sind interdisziplinäre Teams mit klarer Verantwortung für Datenqualität und Systemgrenzen. Teams, die gemeinsam entscheiden, welches System Source of Truth ist. Teams, die den Kontext pflegen, den KI braucht.
Aktuelle Studiendaten bestätigen diese Diagnose. Laut einer Roland Berger Studie aus 2026, in der 472 Führungskräfte befragt wurden, nennen 49 % fehlende KI-Fähigkeiten als größte Barriere für KI-Transformation, 37 % halten Organisationsstruktur und Prozesse für ungeeignet. Technologie steht nicht an erster Stelle. Das Fundament steht an erster Stelle.
Was das praktisch bedeutet – Eine kurze Orientierung
Wenn Sie erkennen wollen, wo Ihr Team im Reifegradmodell steht, helfen drei Fragen.
- Wer prüft KI-Outputs in Ihrem Team? Wenn die Antwort „immer jemand" ist, sind Sie in Zone 1.
- Hat KI bei Ihnen Zugriff auf echte, aktuelle Unternehmensdaten? Wenn die Antwort „nein" oder „teilweise in einem Demo-Setup" ist, haben Sie noch keinen funktionierenden Context Layer.
- Gibt es KI-Prozesse in Ihrem Unternehmen, die ohne manuelle Prüfschleife produktiv laufen? Wenn ja, dann arbeitet Zone 2. Wenn nein, dann ist Zone 3 noch eine Architekturentscheidung entfernt.
Die meisten Teams, mit denen ich spreche, sind in Zone 1 und bewegen sich langsam Richtung Zone 2. Dabei befinden sie sich keinesfalls im Rückstand. Es ist der aktuelle Stand des Marktes. Die entscheidende Frage ist, ob der Weg nach Zone 3 als Architekturaufgabe verstanden wird oder als Frage nach dem nächsten besseren Modell.
Was bei communicode dahintersteckt
Bei communicode arbeiten wir seit Jahren an Systemen, die Produktdaten strukturieren, konsistent halten und für Maschinen abrufbar machen. Das ist der Kern von PXM. Es ist auch die Grundlage für das, was Enterprise RAG braucht.
Im Rahmen von KI Integrationsprojekten kombinieren wir beides: einen vollständigen Context Layer auf echten Unternehmensdaten mit der Agenten-Architektur, die diesen Kontext nutzen kann. Das Ergebnis sind Systeme, die mit dem Wissen des Unternehmens arbeiten und nicht nur generische Antworten liefern.
Zone 3 ist für uns kein Versprechen. Es ist ein Architekturprojekt, das mit dem richtigen Fundament planbar ist.



