Jede gescheiterte KI-Initiative, die ich in den letzten drei Jahren diagnostiziert habe, hatte ein funktionierendes Modell. Die GPT-4- oder Claude-Instanz tat, was sie tun sollte, wenn man ihr saubere Daten in einem kontrollierten Test gab. Das Problem war nie das Modell. Das Problem war alles, was passierte, bevor das Modell seinen Input erhielt.
Das ist der Kontext-Layer — die zweite Komponente des KI-Betriebssystems. Er definiert, wie Daten den KI-Workflow erreichen, in welcher Form, mit welcher Geschwindigkeit und mit welchem Domänenwissen angereichert. Stimmt er, liefert ein mittelmäßiges Modell exzellente Ergebnisse. Stimmt er nicht, liefert ein State-of-the-Art-Modell nichts Brauchbares.
In The AI Operating System widme ich dieser Komponente ein ganzes Kapitel, weil sie der am konsistentesten unterschätzte Faktor in Enterprise-KI ist. Unternehmen investieren in Modellauswahl, Prompt Engineering und Fine-Tuning und ignorieren dabei, dass ihre Daten den Workflow gar nicht in brauchbarer Form erreichen können.
Was Kontext tatsächlich bedeutet
Kontext ist kein Synonym für Daten. Daten sind Rohmaterial. Kontext sind Daten, die zugänglich gemacht, für die Aufgabe aufbereitet, aktuell gehalten und mit Domänenwissen angereichert wurden. Vier Eigenschaften definieren einen funktionierenden Kontext-Layer:
Datenzugänglichkeit
Kann der KI-Workflow auf die benötigten Daten zugreifen — ohne manuelle Intervention? Nicht „haben wir die Daten" — diese Frage wird fast immer mit Ja beantwortet. Die Frage ist, ob es einen programmatischen Pfad gibt von dort, wo die Daten liegen, dorthin, wo das Modell sie braucht.
In einem typischen DACH-Mittelstandsunternehmen umfasst die Antwort SAP, eine Handvoll Excel-Dateien, die von bestimmten Personen gepflegt werden, ein Dokumentenmanagementsystem, das älter ist als das Smartphone, und Erfahrungswissen, das in den Köpfen von drei Personen steckt, die seit zwanzig Jahren im Unternehmen sind.
Die Daten existieren. Der Pfad nicht.
Datenqualität
Qualität bedeutet nicht Perfektion. Es bedeutet Eignung für den Zweck. Ein KI-Workflow, der eingehende Versicherungsschäden klassifiziert, braucht die Schadenbeschreibung, den Schadentyp und die Policennummer. Wenn diese drei Felder konsistent befüllt sind, ist die Datenqualität ausreichend — auch wenn die Kundenadresse Formatierungsinkonsistenzen hat.
Der Fehler ist, Datenqualität als binären Zustand zu behandeln. Entweder „unsere Daten sind sauber" oder „unsere Daten sind ein Chaos." Keine der beiden Rahmungen ist nützlich. Die nützliche Frage ist: Für diesen spezifischen Workflow — sind die erforderlichen Felder ausreichend befüllt und konsistent, um zuverlässige Outputs zu produzieren?
Datenaktualität
Wie alt sind die Daten, wenn sie das Modell erreichen? Ein Claims-Triage-Workflow, der gestrige Schäden verarbeitet, ist nützlich. Einer, der die Schäden des letzten Monats verarbeitet, ist nutzlos. Eine Produktempfehlungsmaschine mit letzte Woche aktualisierten Bestandsdaten wird vergriffene Artikel empfehlen.
Aktualitätsanforderungen variieren nach Workflow. Manche brauchen Echtzeitdaten. Die meisten brauchen Daten, die weniger als 24 Stunden alt sind. Fast keiner toleriert Daten, die mehr als eine Woche veraltet sind.
Domänenkontext
Rohdaten ohne Domänenkontext produzieren rohe Outputs. Das Modell muss wissen, dass „Kaskoschaden" nicht dasselbe ist wie „Haftpflichtschaden." Es muss wissen, dass ein 5.000-Euro-Schaden bei einer gewerblichen Police Routine ist, aber ein 5.000-Euro-Schaden bei einer privaten Haftpflichtpolice ungewöhnlich. Es muss verstehen, dass „Lieferant A" seit fünfzehn Jahren zuverlässig liefert und „Lieferant B" im letzten Quartal zweimal ausgefallen ist.
Domänenkontext ist das institutionelle Wissen, das erfahrene Mitarbeitende in ihren Köpfen tragen. Es explizit zu machen und dem KI-Workflow verfügbar zu machen, ist einer der schwierigsten und wertvollsten Teile beim Aufbau des Kontext-Layers.
Die Lücke zwischen „wir haben Daten" und „die KI kann sie nutzen"
Jedes Unternehmen, mit dem ich arbeite, hat Daten. Kein Unternehmen, mit dem ich arbeite, hat Daten, die sofort von einem KI-Workflow genutzt werden können. Die Lücke zwischen Besitz und Nutzbarkeit ist das Kontext-Layer-Problem, und es manifestiert sich in vorhersehbaren Mustern quer durch DACH-Branchen.
Muster 1: Daten eingesperrt in SAP
Die Daten sind in SAP. Das SAP-System hat keine moderne API. Daten zu extrahieren erfordert entweder einen Custom-ABAP-Report (den die IT auf vier Monate schätzt) oder einen manuellen Export (den jemand jeden Freitagabend durchführt). Beides ist keine Grundlage für einen produktiven KI-Workflow.
Dieses Muster ist besonders häufig in der Fertigungsindustrie und im Handel. Die Daten, die KI-Workflows transformativ machen würden — Bestellhistorien, Lagerbestände, Lieferantenperformance — sind technisch zugänglich, aber praktisch hinter Integrationsbarrieren eingesperrt.
Muster 2: Excel als Integrationsschicht
Die echte Datenpipeline ist eine Sammlung von Excel-Dateien, die von bestimmten Personen gepflegt werden. Der Einkaufsspezialist hat ein Spreadsheet, das Lieferzeiten trackt. Der Qualitätsmanager hat eines, das Fehlermuster protokolliert. Der Vertriebsleiter hat eines mit der Kundensegment-Profitabilität.
Diese Spreadsheets enthalten echte Business Intelligence. Sie repräsentieren auch Single Points of Failure, sind nie versioniert und können nicht programmatisch abgefragt werden.
Muster 3: Erfahrungswissen
Der wertvollste Kontext befindet sich in keinem System. Er steckt im Urteilsvermögen erfahrener Mitarbeitender. Der Schadenbearbeiter, der weiß, dass eine bestimmte Werkstatt Kostenvoranschläge aufbläht. Der Einkaufsleiter, der weiß, dass die angegebenen Lieferzeiten eines bestimmten Lieferanten immer zwei Wochen zu optimistisch sind. Die Kundenservice-Mitarbeiterin, die am Ton einer Beschwerde erkennen kann, ob sie eskalieren wird.
Dieses Wissen ist real, wertvoll und für jedes KI-System vollständig unsichtbar, das keinen Mechanismus hat, es zu erfassen und zu kodieren.
Den Kontext-Layer aufbauen
Der Kontext-Layer ist kein Data-Warehouse-Projekt. Er ist ein fokussierter Aufwand, die richtigen Daten für spezifische Workflows verfügbar zu machen. Hier ist die praktische Architektur.
Schritt 1: Datenanforderungen pro Workflow mappen
Beim Workflow anfangen, nicht bei den Daten. Für jeden KI-Workflow, den Sie deployen wollen, dokumentieren Sie exakt, welche Daten das Modell braucht, um seinen Output zu produzieren. Seien Sie spezifisch: Feldnamen, Formate, Aktualitätsanforderungen, Volumen.
Ein Versicherungs-Claims-Triage-Workflow braucht möglicherweise: Schadenbeschreibung (Freitext), Schadenkategorie (codiert), Schadenhöhe (numerisch), Policentyp (codiert), Kundenhistorie (letzte 5 Schäden). Das sind fünf Datenpunkte. Nicht „alle Kundendaten." Fünf spezifische Felder.
Schritt 2: Den Datenpfad nachverfolgen
Für jeden benötigten Datenpunkt den Pfad von dort, wo er liegt, dorthin, wo das Modell ihn braucht, nachverfolgen. Gibt es eine API? Eine Datenbankverbindung? Einen Dateiexport? Eine Person, die ihn manuell kopiert?
Den aktuellen Pfad ehrlich dokumentieren. Wenn der Pfad „Maria exportiert es freitags aus SAP und mailt es Thomas" lautet, schreiben Sie das auf. Das ist Ihr Startpunkt.
Schritt 3: Die minimal funktionsfähige Pipeline bauen
Sie brauchen für Level 1 keine Echtzeit-Streaming-Architektur. Sie brauchen eine zuverlässige, automatisierte Pipeline, die die benötigten Daten im benötigten Format in der benötigten Frequenz liefert.
Für viele DACH-Mittelstands-Workflows bedeutet das: eine geplante Datenbankabfrage oder ein API-Call, der nächtlich läuft, eine strukturierte Datei an einem definierten Ort ablegt und einen Validierungscheck auslöst. Wenn die Datei valide ist, verarbeitet der KI-Workflow sie. Wenn nicht, wird ein Alert ausgelöst.
Das ist nicht glamourös. Es ist zuverlässig. Und Zuverlässigkeit ist der ganze Punkt.
Schritt 4: Domänenkontext kodieren
Das Erfahrungswissen nehmen und explizit machen. Das bedeutet typischerweise den Aufbau einer Wissensbasis — strukturierte Dokumente, die die Regeln, Ausnahmen und Urteilsheuristiken erfahrener Mitarbeitender erfassen.
Für einen Claims-Triage-Workflow: eine Tabelle, die Schadentypen erwarteten Schadenhöhenbereichen zuordnet. Eine Liste markierter Werkstätten. Regeln, wann ein Schaden unabhängig von der Höhe eskaliert werden soll. Das sind keine Trainingsdaten für das Modell — es ist Referenzmaterial, das der Workflow während der Verarbeitung konsultiert.
Retrieval-Augmented-Generation-(RAG-)Architekturen sind der Standardansatz hier. Das Modell ruft relevanten Domänenkontext aus der Wissensbasis ab, bevor es seinen Output generiert. Die Qualität der Wissensbasis bestimmt direkt die Qualität des Outputs.
Schritt 5: Aktualitätsgarantien etablieren
Aktualitäts-SLAs für jede Datenquelle definieren und durchsetzen. Wenn die Schadendaten weniger als 24 Stunden alt sein müssen, Monitoring aufbauen, das alarmiert, wenn die Pipeline nicht gelaufen ist. Wenn die Wissensbasis aktuelle Policen widerspiegeln muss, einen Verantwortlichen benennen, der sie monatlich prüft.
Aktualität ist keine technische Eigenschaft — sie ist ein operatives Commitment. Jemand muss sie verantworten.
Die Context-Readiness-Checkliste
Vor dem Deployment eines KI-Workflows den Kontext-Layer gegen diese Kriterien bewerten:
Datenzugänglichkeit:
- Kann jeder benötigte Datenpunkt programmatisch abgerufen werden?
- Ist der Datenpfad dokumentiert und einer namentlich benannten Person zugeordnet?
- Kann eine Staging-/Testumgebung bereitgestellt werden, ohne Produktion anzufassen?
Datenqualität:
- Sind die workflow-kritischen Felder ausreichend befüllt (80 %+ Befüllungsrate)?
- Sind codierte Felder konsistent (keine doppelten Kategorien, kein Freitext in codierten Feldern)?
- Gibt es einen Prozess für den Umgang mit fehlenden oder ungültigen Daten?
Datenaktualität:
- Ist die Aktualitätsanforderung für jede Datenquelle definiert?
- Gibt es automatisiertes Monitoring für Pipeline-Ausfälle?
- Erfüllt die aktuelle Pipeline die Aktualitätsanforderung?
Domänenkontext:
- Wurden Domänenexperten interviewt, um Entscheidungsheuristiken zu erfassen?
- Ist die Wissensbasis strukturiert und abfragbar?
- Gibt es einen Verantwortlichen, der die Wissensbasis aktuell hält?
Jeden Bereich als blockierend, schwach, adäquat oder stark bewerten. Zwei oder mehr blockierende Bewertungen bedeuten, dass der Kontext-Layer Arbeit braucht, bevor ein Workflow-Deployment realistisch ist.
Warum Kontext sich aufaddiert
Der Kontext-Layer ist kein einmaliger Aufbau. Er ist ein Asset, das über die Zeit an Wert gewinnt. Jeder Workflow, der den Kontext-Layer nutzt, validiert und bereichert die zugrundeliegenden Daten. Korrekt triagierte Schäden bestätigen die Genauigkeit der Domänenregeln. Inkorrekt triagierte Schäden offenbaren Lücken, die, wenn adressiert, den nächsten Zyklus verbessern.
So addieren sich KI-Initiativen auf — nicht durch bessere Modelle, sondern durch reicheren Kontext. Die Lernkomponente des KI-Betriebssystems formalisiert diese Feedbackschleife. Aber sie beginnt beim Kontext-Layer.
Die Unternehmen, die einen produktionstauglichen Kontext-Layer für ihren ersten Workflow bauen, stellen fest, dass der zweite Workflow dramatisch einfacher ist. Die Datenpfade existieren. Die Wissensbasis ist begonnen. Die Aktualitätsgarantien sind etabliert. Die Grenzkosten des Kontexts sinken mit jedem Deployment.
Wo anfangen
Wenn Sie vermuten, dass Ihre KI-Initiativen am Kontext scheitern statt an Modellen — und statistisch ist das fast sicher der Fall — beginnen Sie mit zwei Aktionen. Erstens: Nehmen Sie ein stehengebliebenes KI-Projekt und mappen Sie den tatsächlichen Datenpfad von der Quelle zum Modell. Dokumentieren Sie jeden manuellen Schritt, jede Excel-Übergabe, jede Erfahrungswissen-Abhängigkeit. Zweitens: Vergleichen Sie diese Karte mit der obigen Context-Readiness-Checkliste.
Die Lücke zwischen dem Ist-Zustand und dem Soll-Zustand ist Ihr Kontext-Layer-Projekt. Es ist weniger aufregend als Modellauswahl. Es ist wichtiger als alles andere zusammen.
Den vollständigen Implementierungsleitfaden für den Kontext-Layer, inklusive Templates und ausgearbeiteten Beispielen, finden Sie in Kapitel 04 von The AI Operating System.
Für ein Gespräch über den Aufbau des Kontext-Layers für Ihren ersten KI-Workflow vereinbaren Sie ein Erstgespräch.