Jede gescheiterte KI-Initiative, die ich in den letzten 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 keine subjektive Beobachtung. Gartner prognostiziert, dass Unternehmen bis 2026 sechzig Prozent ihrer KI-Projekte abbrechen werden — nicht weil die Modelle versagen, sondern weil die zugrundeliegenden Daten nicht AI-ready sind. Dreiundsechzig Prozent der Organisationen haben laut derselben Analyse entweder keine geeigneten Datenpraktiken für KI oder wissen es schlicht nicht. Der Kontext-Layer ist die systematische Antwort auf dieses Problem.
Er ist die zweite Komponente des KI-Betriebssystems. Er definiert, wie Daten einen KI-Workflow erreichen — in welcher Form, mit welcher Geschwindigkeit, mit welchem Domänenwissen angereichert. Stimmt er, liefert ein mittelmäßiges Modell exzellente Ergebnisse. Stimmt er nicht, liefert selbst ein State-of-the-Art-Modell nichts Brauchbares. Und seit 2. August 2025 ist das, was viele bisher als technisches Implementierungsdetail behandelt haben, für Anbieter und Betreiber von KI-Systemen mit erhöhtem Risiko zur regulatorischen Anforderung geworden: Artikel 10 des EU AI Acts schreibt verbindliche Data-Governance-Praktiken vor.
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 stellt die Grundfrage: Gibt es einen programmatischen Pfad von dort, wo die Daten liegen, dorthin, wo das Modell sie braucht — ohne manuelle Intervention? Nicht „haben wir die Daten?" — diese Frage wird fast immer mit Ja beantwortet. 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 programmatische Pfad nicht.
Datenqualität bedeutet nicht Perfektion, sondern 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. Das BSI hat im Juli 2025 mit dem QUAIDAL-Leitfaden einen methodischen Rahmen veröffentlicht, der abstrakte Qualitätsanforderungen des EU AI Acts in zehn konkrete Qualitätskriterien — mit 143 Metriken und Methoden — überführt. Das Dokument richtet sich primär an Anbieter von Hochrisiko-KI-Systemen, ist aber als Referenzrahmen für jede ernsthafte Enterprise-KI-Implementierung nützlich. Der EU AI Act selbst verlangt in Artikel 10 explizit, dass Trainings-, Validierungs- und Testdaten relevant, ausreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig sein müssen — sowie, dass potenzielle Verzerrungen aktiv geprüft und dokumentiert werden.
Datenaktualität ist die am häufigsten unterschätzte Dimension. 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 empfiehlt vergriffene Artikel. Aktualitätsanforderungen variieren nach Workflow: Manche brauchen Echtzeitdaten, die meisten tolerieren maximal 24-stündige Latenz, und fast keiner kann mit Daten arbeiten, die mehr als eine Woche veraltet sind.
Domänenkontext ist das institutionelle Wissen, das erfahrene Mitarbeitende in ihren Köpfen tragen und das für jedes KI-System vollständig unsichtbar bleibt, solange es keinen Mechanismus gibt, es zu erfassen und verfügbar zu machen. 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 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. Dieses Wissen explizit zu machen und dem 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"
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.
Daten eingesperrt in Altsystemen. 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.
Excel als Integrationsschicht. Die eigentliche Datenpipeline ist eine Sammlung von Spreadsheets, die von bestimmten Personen gepflegt werden. Der Einkaufsspezialist hat eine Tabelle, die Lieferzeiten trackt. Der Qualitätsmanager eine, die Fehlermuster protokolliert. Der Vertriebsleiter eine mit der Kundensegment-Profitabilität. Diese Dateien enthalten echte Business Intelligence — sie repräsentieren aber auch Single Points of Failure, sind nie versioniert und können nicht programmatisch abgefragt werden. Sobald der Einkaufsspezialist im Urlaub ist oder das Unternehmen verlässt, bricht die Pipeline.
Erfahrungswissen ohne programmatischen Pfad. Der wertvollste Kontext befindet sich in keinem System. 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.
Den Kontext-Layer aufbauen: die praktische Architektur
Der Kontext-Layer ist kein Data-Warehouse-Projekt. Er ist ein fokussierter Aufwand, die richtigen Daten für spezifische Workflows verfügbar zu machen — und er beginnt beim Workflow, nicht bei der Dateninfrastruktur.
Datenanforderungen pro Workflow mappen. Für jeden KI-Workflow, den Sie deployen wollen, dokumentieren Sie exakt, welche Daten das Modell braucht: Feldnamen, Formate, Aktualitätsanforderungen, Volumen. Ein Versicherungs-Claims-Triage-Workflow braucht möglicherweise Schadenbeschreibung (Freitext), Schadenkategorie (codiert), Schadenhöhe (numerisch), Policentyp (codiert) und Kundenhistorie (letzte fünf Schäden). Das sind fünf Datenpunkte — nicht „alle Kundendaten," sondern fünf spezifische Felder. Diese Präzision ist der Ausgangspunkt für alles Weitere.
Den Datenpfad ehrlich dokumentieren. Für jeden benötigten Datenpunkt: Wo liegt er? Gibt es eine API, eine Datenbankverbindung, einen Dateiexport, eine Person, die ihn manuell kopiert? Wenn der Pfad lautet „Maria exportiert es freitags aus SAP und mailt es Thomas" — schreiben Sie das auf. Das ist Ihr Startpunkt, nicht ein Problem, das Sie verschweigen. Erfahrungsgemäß führt ehrliche Dokumentation in diesem Schritt zu einer deutlich kürzeren Liste wirklich umsetzbarer Workflows.
Die minimal funktionsfähige Pipeline bauen. Sie brauchen für den ersten produktiven Workflow 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 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.
Domänenkontext kodieren. Das Erfahrungswissen nehmen und explizit machen — in strukturierten Dokumenten, die die Regeln, Ausnahmen und Entscheidungsheuristiken 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: 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.
Aktualitätsgarantien etablieren und verantworten. Aktualitäts-SLAs für jede Datenquelle definieren und durchsetzen. Wenn Schadendaten weniger als 24 Stunden alt sein müssen, brauchen Sie Monitoring, das alarmiert, wenn die Pipeline nicht gelaufen ist. Wenn die Wissensbasis aktuelle Policen widerspiegeln muss, brauchen Sie einen namentlich benannten Verantwortlichen, der sie monatlich prüft. Aktualität ist keine technische Eigenschaft — sie ist ein operatives Commitment.
Die regulatorische Dimension
Für Unternehmen, die KI in Bereichen mit erhöhtem Risiko einsetzen — Kreditentscheidungen, Personalauswahl, Sicherheitskritisches — ist ein sauberer Kontext-Layer seit 2. August 2025 keine Empfehlung mehr, sondern gesetzliche Pflicht. Artikel 10 des EU AI Acts verlangt nachweisbare Data-Governance-Praktiken für Hochrisiko-KI-Systeme: Dokumentation der Datenerhebungsprozesse, aktive Prüfung auf Verzerrungen, Identifikation von Datenlücken, die die regulatorische Konformität gefährden. Ab 2. August 2026 gelten diese Anforderungen für den vollständigen Annex-III-Katalog der Hochrisiko-Anwendungen.
Der QUAIDAL-Leitfaden des BSI, veröffentlicht im Juli 2025, bietet dafür eine praktische Brücke: Er übersetzt die abstrakten Qualitätsanforderungen des AI Acts in zehn konkrete Kriterien mit messbaren Metriken — und ist auf GitHub als maschinenlesbares Format verfügbar. Für DACH-Unternehmen, die KI-Initiativen ernsthaft skalieren wollen, ist er Pflichtlektüre.
Warum der Kontext-Layer 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 Strukturen. 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. 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. Die Lernkomponente des KI-Betriebssystems formalisiert diese Feedbackschleife — aber sie beginnt hier, beim Kontext-Layer.
Wo anfangen
Wenn Sie vermuten, dass Ihre KI-Initiativen am Kontext scheitern statt an Modellen — und die Datenlage legt nahe, dass das in den meisten Organisationen der Fall ist — beginnen Sie mit zwei konkreten Aktionen. Nehmen Sie ein stehengebliebenes KI-Projekt und mappen Sie den tatsächlichen Datenpfad von der Quelle zum Modell: jeden manuellen Schritt, jede Excel-Übergabe, jede Erfahrungswissen-Abhängigkeit. Vergleichen Sie diese Karte dann ehrlich mit den vier Dimensionen oben — Zugänglichkeit, Qualität, Aktualität, Domänenkontext.
Die Lücke zwischen Ist-Zustand und 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.
Ein Fit Call klärt in dreißig Minuten, wo Ihr Kontext-Layer steht und welcher Workflow als erster produktionsreif ist — bevor weitere KI-Budgets in Pilots ohne Datenpfad fließen.
Quellen: Gartner, „Lack of AI-Ready Data Puts AI Projects at Risk," Februar 2025 (gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk); Gartner, „Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025," Juli 2024; BSI, „QUAIDAL — Methodischer Leitfaden zur Datenqualität in KI-Systemen," Juli 2025 (bsi.bund.de); EU AI Act, Artikel 10 „Data and Data Governance" (artificialintelligenceact.eu/article/10/).