Das Data-Readiness-Problem bei Enterprise AI

Enterprise-AI-Programme scheitern selten daran, dass ein Team kein Modell aufrufen kann. Sie stocken, weil die Organisation nicht klären kann, was Daten bedeuten, ob sie aktuell sind, welcher Datensatz maßgeblich ist, wer aufgrund eines Outputs handeln darf oder wie Ergebnisse gemessen werden. Wir lösen diese Fragen vor der Modellwahl mit sechs Prüfpunkten: Provenienz, Aktualität, Duplikate, Baselines, Handlungsrechte und Ergebnismessung.

Das Modell ist meist nicht die erste Einschränkung

Das Modell ist der sichtbare Teil eines AI-Systems. Der operative Teil besteht aus Quellsystemen, Identitäten, Definitionen, Berechtigungen, Review-Queues, Schreibpfaden und Feedback. Ein leistungsfähiges Modell auf unzuverlässigen Daten erzeugt wortgewandte Unsicherheit; ein bescheideneres Modell in einem klar definierten Entscheidungssystem kann verlässlichen Wert schaffen.

Das ist eine Führungsaufgabe: Operations kennt den Prozess, Technology die Systeme, Finance wichtige Definitionen, Legal und Security setzen Nutzungsgrenzen, und Fachbereiche kontrollieren die ergebniswirksamen Aktionen. Kein Team kann allein Data Readiness erklären.

Die Evidenz stützt diese operative Sicht. RAND nennt ungeeignete Daten, schwache Infrastruktur und die Fehlausrichtung am Geschäftsproblem als wiederkehrende Ursachen gescheiterter AI-Projekte. Daten für Reporting oder Compliance enthalten zudem nicht zwingend den Kontext für neue Analysen. Der Economy-Teil des Stanford AI Index 2026 zeigt schnelle Adoption und Investitionen, doch Adoption ist keine messbare operative Rendite. Readiness muss deshalb an Entscheidung und Workflow getestet werden, nicht an Datenmenge oder Begeisterung.

Mit einem Entscheidungsvertrag beginnen

Vor der Tabellenprüfung formulieren wir einen kurzen Entscheidungsvertrag: wiederkehrende Entscheidung, verantwortliche Person, erlaubte Aktionen, Zeitfenster, erforderliche Evidenz und zu beobachtendes Geschäftsergebnis. „AI für Produktdaten“ ist kein Vertrag. „Fehlende Attributwerte vor dem wöchentlichen Publikationsschluss empfehlen, ohne freigegebene Datensätze zu überschreiben“ ist einer.

Damit optimiert ein Team nicht versehentlich eine Offline-Metrik ohne Weg in den Betrieb. Zugleich wird sichtbar, ob AI überhaupt nötig ist. Deterministische Lookups, Schwellenwerte und Abstimmungen bleiben Regeln; AI verdient ihren Platz bei mehrdeutigen, unstrukturierten oder stark variablen Inputs.

Danach prüfen wir sechs Gates. Jedes hat Evidenz, Owner und Pass-Bedingung.

Gate 1: Provenienz

Provenienz beantwortet, woher ein Feld stammt, unter welcher Definition und Transformation und mit welcher Autorität. Für jeden Input benötigen wir eine Spur mit Quellsystem, Extraktionszeit, Record-Key, Transformationsversion und menschlichen Korrekturen. Widersprüchliche Werte werden über Definitionen und Pfade geklärt, nicht durch Auswahl der größeren Tabelle.

Lineage muss abfragbar sein. Empfehlungen behalten Referenzen auf Quelldatensätze und Logikversion. Führungskräfte brauchen nicht jedes Event, aber einen verantwortlichen Owner je kritischer Domäne und einen Eskalationspfad. Bestanden ist das Gate, wenn ein Reviewer einen wesentlichen Output ohne den ursprünglichen Entwickler rekonstruieren kann.

Auch die Extraktionsgrenze zählt. Ein wiederholbarer operativer Datenextraktions-Workflow protokolliert Anfrage, Eingang und Fehler, damit Abwesenheit nicht als Nullwert gilt.

Gate 2: Aktualität

Aktualität ist kein universeller Zeitstempel, sondern das Höchstalter, in dem Daten für eine Entscheidung noch tauglich sind. Wir erfassen Ereigniszeit, Aufzeichnung im Quellsystem und Konsum im AI-Workflow. So werden verspätete Integrationen sichtbar. „Pipeline erfolgreich“ bedeutet nicht „Daten aktuell“.

Ein Freshness-Budget definiert Warnung, Abstention, deterministischen Fallback oder Schreibsperre bei Überschreitung. Stille Arbeit mit alten Daten ist unzulässig. Eine belastbare Data-Warehouse- und Ingestion-Schicht ist Teil des Entscheidungsprodukts, nicht nur Vorarbeit.

Gate 3: Duplikate und Identität

Duplikate sind oft Identitätsfehler. Dasselbe Objekt kann mehrere IDs tragen, eine ID kann über Regionen wiederverwendet werden. Wir definieren zunächst die geschäftliche Identitätsregel und ihren Scope, bewahren rohe sowie kanonische IDs auf und dokumentieren Match-Methode und Konfidenz. Deterministische Keys gehen vor; unsichere probabilistische Matches kommen in eine Review-Queue.

Erforderlich sind Duplikatraten nach Quelle und Segment, reversible Merges, Survivorship-Regeln und Monitoring neuer Kollisionen. Kann das Team nicht erklären, welcher Datensatz warum gewinnt, darf darauf keine automatisierte Entscheidung beruhen.

Deshalb ist vollständige operative Dateneigentümerschaft wichtig: Rohhistorie und stabile IDs ermöglichen Abgleich und Replay trotz veränderter Upstream-Schnittstellen.

Gate 4: Baselines

Ohne Baseline bleibt AI eine Demo. Vor einer Änderung dokumentieren wir Fehlerquote, Durchlaufzeit, Review-Aufwand, Abdeckung, Exceptions und das beabsichtigte Geschäftsergebnis.

Vertrauliche interne Evidenz veröffentlichen wir als Index mit Baseline = 100; absolute Werte bleiben in der autorisierten Messumgebung. Nenner, Population und Zeitfenster bleiben konstant. Segmentierung verhindert, dass Gesamtverbesserungen Schäden in Hochrisikogruppen verdecken. Gleichzeitige Promotions, Policy- oder Personaländerungen werden erfasst. Bestanden ist das Gate nur, wenn sich die Baseline aus versionierten Daten und Definitionen reproduzieren lässt.

Gate 5: Handlungsrechte

Datenzugriff ist keine Handlungserlaubnis. Eine Anwendung darf vielleicht lesen, aber nicht stornieren, prüfen, aber nicht publizieren. Wir ordnen daher jede Aktion System of Record, erlaubtem Akteur, Freigabe, Risiko- oder Wertgrenzen, Funktionstrennung und Rollback zu.

Der Startmodus ist meist read-only oder recommendation, danach folgt dry-run und erst nach nachgewiesenen Kontrollen ein freigegebener Write. Credentials erhalten Minimalrechte, Read und Write bleiben getrennt, risikoreiche Aktionen verlangen ein Approval-Token und Mutationen möglichst Idempotenz sowie Korrelations-ID. „Human in the loop“ ist erst konkret, wenn Person, Zeitpunkt, Information und Reaktionszeit feststehen.

Gate 6: Ergebnismessung

Modellqualität genügt nicht. Wir instrumentieren die Kette Input → Empfehlung → Review → Aktion → Ergebnis mit stabilen IDs, sodass Resultate auf Versionen von Modell, Regeln und Quellen zurückführbar sind. Auch Abstentions und abgelehnte Vorschläge werden erfasst, sonst bevorzugt das Feedback leichte Fälle.

Der Plan definiert Primärergebnis, Guardrails und Review-Rhythmus. Guardrails können Fehlerschwere, Override-Rate, Beschwerden, Policy-Verstöße, Latenz oder verlagerten Aufwand umfassen. Wer eine Queue verkleinert und eine größere versteckte schafft, hat Operations nicht verbessert.

Ein praktischer Readiness-Score

Status	Bedeutung	Release-Konsequenz
Unknown	Evidenz fehlt	Kein Pilot mit operativen Claims
Defined	Owner, Definition und Test existieren	Nur Offline-Evaluation
Verified	Test auf repräsentativen Daten bestanden	Kontrollierter Workflow-Pilot
Monitored	Produktionsschwelle und Reaktion existieren	Für begrenzte Skalierung geeignet

Durchschnitte täuschen: fünf überwachte Gates kompensieren keine unbekannten Handlungsrechte. Das schwächste Gate mit möglichem materiellem Schaden begrenzt den Release. Für Builder wird der Score zur Acceptance-Test-Liste; für Executives zum Portfoliofilter.

Investitionen vor der Modellwahl ordnen

Mit sichtbaren Gates lösen wir Identitäten vor zusätzlicher Inferenzkapazität, erfassen Ereigniskontext vor Prognosen, klären Rechte vor dem Bau eines handlungsunfähigen Agenten und sichern die Baseline vor Prozessänderungen.

Erst dann vergleichen wir Modelle auf repräsentativen Exceptions nach Task-Erfolg, Kalibrierung, Latenz, Privacy und Kosten. Ein stärkeres Modell ersetzt weder unbeobachtbare Ergebnisse noch unautorisierte Write-Pfade. Readiness bleibt kontinuierlich: Quellen driften, IDs ändern sich, Rechte laufen ab und Definitionen entwickeln sich. Jedes Gate braucht Owner, automatisierte Tests und Reaktion auf Schwellenverletzungen.

Die Executive-Frage

Die nützlichste Frage lautet nicht „Welches Modell verwenden wir?“, sondern: „Zeigt uns die Kette von Quellevidenz über autorisierte Aktion bis zum gemessenen Ergebnis.“ Ist sie reproduzierbar, kann das Programm lernen. Ist sie es nicht, erhöht mehr Modellleistung nur Tempo und Sicherheit eines ungeprüften Prozesses. Data Readiness ist nicht die Vorphase der interessanten AI-Arbeit, sondern das Design des Betriebssystems, in dem AI vertrauenswürdig wird.