communicode GmbH

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.

Illustration eines Roboters mit der Aufschrift „AI“, der über verschiedenen Symbolen für Daten, Suche, Datenbanken, Dokumente, Automatisierung und Software schwebt. Der Hintergrund besteht aus abstrakten, türkisfarbenen digitalen Wellen und Punktmustern.

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.

Grafik eines KI-Reifegradmodells mit drei Stufen: Assisted, Informed und Autonomous. Links werden die drei Ebenen mit kurzen Beschreibungen dargestellt, rechts steht ein Roboter mit der Aufschrift „AI“ vor einem abstrakten digitalen Hintergrund.

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.

  • Was bedeutet das Context-Problem bei KI?
    Das Context-Problem beschreibt die Situation, in der KI-Systeme zwar technisch leistungsfähig sind, aber nicht auf unternehmensspezifisches Wissen zugreifen können. Das Modell kennt allgemeines Wissen aus seinen Trainingsdaten, nicht aber interne Produktdaten, Klassifikationsregeln, aktuelle Preisstrukturen oder spezifische Unternehmensprozesse. Das Ergebnis: Outputs sind zu generisch für den produktiven Einsatz ohne manuelle Prüfung. Das Context-Problem ist kein Modell-Problem – es ist ein Architekturproblem, das durch einen strukturierten Zugang zu Unternehmensdaten gelöst wird.
  • Was ist Enterprise RAG und warum ist es relevant?
    Enterprise RAG steht für Retrieval-Augmented Generation im Unternehmenskontext. Das Prinzip: Bevor ein Sprachmodell antwortet, ruft es in Echtzeit relevante Informationen aus unternehmensinternen Datenquellen ab – PIM-Systemen, Dokumentenmanagementsystemen, ERP- oder CRM-Daten. Damit kennt das Modell nicht nur allgemeines Weltwissen, sondern den spezifischen Kontext des Unternehmens. Enterprise RAG ist die technische Grundlage dafür, dass KI von Zone 1 (Assisted, alles wird geprüft) zu Zone 2 (Informed, verlässliche Ergebnisse auf Basis echter Daten) und Zone 3 (Autonomous, KI handelt selbstständig) skalieren kann.
  • Was ist das KI-Reifegradmodell mit drei Zonen?
    Das Drei-Zonen-Modell beschreibt die Entwicklungsstufen von KI-Systemen in Unternehmen. Zone 1 (Assisted): KI erzeugt Vorschläge, Menschen prüfen jeden Output – Supervision ist Pflicht. Zone 2 (Informed): KI hat Zugriff auf strukturierte Unternehmensdaten, Outputs sind nachvollziehbar und verlässlicher, die Supervisionsquote sinkt. Zone 3 (Autonomous): KI handelt selbstständig, eskaliert nur bei echter Unsicherheit, Entscheidungen werden lückenlos protokolliert. Die meisten Unternehmen befinden sich aktuell in Zone 1. Der Weg zu Zone 3 führt über den Aufbau eines belastbaren Context Layers, nicht über den Wechsel auf ein anderes Modell.
  • Warum skaliert KI in Unternehmen oft nicht über Piloten hinaus?
    KI-Piloten scheitern selten am Modell. Sie scheitern an der Datenbasis, die in der Produktivumgebung vorliegt. Im Pilot wird mit sauber aufbereiteten Testdaten gearbeitet. Im Produktivbetrieb treffen KI-Systeme auf inkonsistente Stammdaten, fehlende Attribute, unklare Systemgrenzen und Wissen, das nicht formalisiert ist. Hinzu kommen organisatorische Faktoren: Teams in Silos verantworten keinen gemeinsamen Datenbestand. Eine aktuelle Roland Berger Studie von 2026 bestätigt, dass 37 Prozent der Unternehmen Organisationsstruktur und Prozesse als größte KI-Barriere nennen – vor der Technologie selbst.
  • Was ist der Unterschied zwischen Enterprise RAG und manuell gepflegten Rules-Files?
    Manuell gepflegte Rules-Files oder System-Prompts enthalten Informationen, die jemand zu einem bestimmten Zeitpunkt aufgeschrieben hat. Sie veralten, wenn sich das Unternehmen verändert. Niemand merkt sofort, wenn die Datei nicht mehr stimmt. Das erzeugt Pflegeaufwand und letztlich Misstrauen in KI-Outputs. Enterprise RAG verbindet das Modell direkt mit den Quelldaten – PIM, DAM, ERP, Wissensdatenbank. Änderungen in den Quelldaten sind sofort verfügbar, ohne manuelle Aktualisierung. Das ist der strukturelle Unterschied: Rules-Files sind ein manueller Kontext-Ersatz, Enterprise RAG ist ein automatisierter Context Layer auf echten Unternehmensdaten.

Sprechen Sie mit uns

Per WhatsApp oder Telefon, schnell und persönlich.

WhatsApp+49 201 84188188

Schreiben Sie uns

Schnell, persönlich und direkt per

Oder einfach per Mail: sales@communicode.de

Warum KI nicht skaliert: Das Context-Problem erklärt