Die Eignung der Daten als Problem für KI im Unternehmen

KI-Programme im Unternehmen stocken selten, weil ein Team kein Modell aufrufen kann. Sie stocken, weil die Organisation nicht klären kann, was ihre Daten bedeuten, ob sie aktuell sind, welcher Datensatz maßgeblich ist, wer auf Grundlage einer Ausgabe handeln darf oder wie ein Ergebnis gemessen wird. Wir klären diese Fragen vor der Modellwahl mit einem Bewertungsmodell aus sechs Prüfpunkten: Datenherkunft, Aktualität, Duplikate, Ausgangswerte, Handlungsrechte und Ergebnismessung.

Das Modell ist meist nicht der erste Engpass

Das Modell ist der sichtbare Teil eines KI-Systems. Der operative Teil umfasst alles darum herum: Quellsysteme, Kennungen, fachliche Definitionen, Berechtigungen, Warteschlangen für die Prüfung, Schreibpfade und Feedback. Ein leistungsfähiges Modell, das mit unzuverlässigen Betriebsdaten arbeitet, erzeugt flüssig formulierte Unsicherheit. Ein weniger leistungsfähiges Modell in einem klar definierten Entscheidungssystem kann verlässlichen Nutzen schaffen.

Diese Unterscheidung ist für die Unternehmensführung wichtig, weil sich die Beschaffung eines Modells leicht budgetieren und ankündigen lässt. Die Eignung der Daten für den Einsatz liegt dagegen in der Verantwortung mehrerer Bereiche. Der operative Bereich verantwortet die tatsächlichen Abläufe, die IT die Systeme und der Finanzbereich wichtige Definitionen. Rechtsabteilung und Informationssicherheit begrenzen die Nutzung, während die Fachbereiche viele der Aktionen kontrollieren, die Ergebnisse bewirken. Kein Team kann allein erklären, dass die Daten einsatzbereit sind.

Die Forschung stützt diese Sicht als Betriebsproblem. RANDs Untersuchung gescheiterter KI-Projekte basiert auf Interviews mit erfahrenen Praktikern und nennt ungeeignete Daten, schwache Infrastruktur und mangelnde Ausrichtung am Geschäftsproblem als wiederkehrende Ursachen. Sie weist auch darauf hin, dass für Compliance oder Protokollierung vorgehaltene Daten den Kontext für einen neuen Analysezweck möglicherweise nicht bewahren. Das Wirtschaftskapitel des Stanford AI Index 2026 dokumentiert die rasche Einführung von KI in Unternehmen und entsprechende Investitionen. Die Einführung allein ist jedoch keine messbare operative Rendite. Zusammen führen diese Erkenntnisse zu einer praktischen Schlussfolgerung: Die Eignung der Daten muss anhand einer Entscheidung und eines Workflows geprüft werden; sie lässt sich nicht aus Datenmengen oder der Begeisterung der Unternehmensführung ableiten.

Mit einer Entscheidungsvereinbarung beginnen

Bevor wir Tabellen prüfen, formulieren wir eine kurze Entscheidungsvereinbarung. Sie benennt die wiederkehrende Entscheidung, die dafür verantwortliche Person, die erlaubten Aktionen, die verfügbare Zeit, die erforderlichen Nachweise und das zu beobachtende Geschäftsergebnis. „KI für Produktdaten einsetzen“ ist keine Vereinbarung. „Der für den Produktkatalog verantwortlichen Person vor dem wöchentlichen Veröffentlichungsschluss fehlende Attributwerte empfehlen, ohne freigegebene Datensätze zu überschreiben“ ist eine.

Die Vereinbarung verhindert einen bekannten Fehler: Ein Team optimiert eine Offline-Kennzahl, für die es keinen verlässlichen Weg in den Betrieb gibt. Sie zeigt auch, ob KI überhaupt nötig ist. Manche Entscheidungen bestehen aus deterministischen Nachschlagevorgängen, Schwellenwertprüfungen oder Abstimmungen. Dafür sollten Regeln zuständig bleiben. KI ist sinnvoll, wenn Eingaben so mehrdeutig, unstrukturiert oder variabel sind, dass Regeln allein fehleranfällig werden.

Anschließend prüfen wir die Eignung der Daten anhand von sechs Prüfpunkten. Ein Prüfpunkt ist kein Schlagwort für einen Reifegrad: Er umfasst Nachweise, eine verantwortliche Person und ein Kriterium für das Bestehen.

Prüfpunkt 1: Datenherkunft

Die Datenherkunft beantwortet die Fragen: Woher stammt dieses Feld, nach welcher Definition, über welche Transformationen und unter wessen Befugnis?

Für jede Eingabe des Systems benötigen wir eine nachvollziehbare Verbindung vom angezeigten Wert zur Quelle. Dazu gehören Quellsystem, Extraktionszeit, Datensatzschlüssel, Transformationsversion und sämtliche menschlichen Korrekturen. Wenn zwei Berichte unterschiedliche Umsatz-, Bestands- oder Statuswerte zeigen, löst die Auswahl der größeren Tabelle das Problem nicht. Definitionen und Transformationspfade müssen abgeglichen werden.

Entwickler sollten Datenherkunft und Verarbeitungshistorie abfragbar machen. Eine Prognose oder erzeugte Empfehlung sollte Verweise auf die Quelldatensätze und die verwendete Version der Verarbeitungslogik behalten. Führungskräfte müssen nicht jedes Ereignis in dieser Historie prüfen. Sie brauchen aber eine Person mit Ergebnisverantwortung für jeden kritischen Datenbereich und einen dokumentierten Eskalationsweg bei widersprüchlichen Definitionen.

Die Schnittstelle zur Datenextraktion ist ebenso wichtig wie das Data Warehouse. Ein wiederholbarer Workflow zur Extraktion von Betriebsdaten protokolliert, was angefragt wurde, was eingegangen ist und was fehlgeschlagen ist, damit fehlende Daten nicht mit einem Nullwert verwechselt werden.

Ein einfaches Kriterium für das Bestehen lautet: Eine prüfende Person kann eine wesentliche Ausgabe auswählen und ihre Herkunft rekonstruieren, ohne den ursprünglichen Entwickler zu fragen. Erfordert dies Wissen, das nur einzelne Mitarbeiter besitzen, ist der Prüfpunkt nicht bestanden.

Prüfpunkt 2: Datenaktualität

Datenaktualität ist kein allgemeingültiges Ziel für einen Zeitstempel. Sie bezeichnet das Höchstalter, bei dem Daten für eine bestimmte Entscheidung noch geeignet sind. Eine monatliche Klassifizierung kann eine Verzögerung von Tagen tolerieren, eine Verfügbarkeitsentscheidung möglicherweise nicht einmal Stunden. Die Entscheidungsvereinbarung legt das erforderliche Serviceniveau fest.

Wir erfassen die Aktualität an drei Punkten: beim Ereignis, bei dessen Aufzeichnung im Quellsystem und bei der Nutzung im KI-Workflow. Diese Zeitstempel zeigen verzögerte Integrationen und verspätete Aktualisierungen. Außerdem unterscheiden wir „Pipeline erfolgreich“ von „Daten aktuell“: Ein Auftrag kann erfolgreich abgeschlossen werden, obwohl er nur den unveränderten Datenstand von gestern kopiert.

Die Kontrolle im Produktivbetrieb besteht aus einer zulässigen Altersgrenze für Daten und einem ausdrücklich festgelegten Verhalten bei deren Überschreitung. Das System kann warnen, auf eine Entscheidung verzichten, auf einen deterministischen Wert zurückgreifen oder eine Schreibaktion blockieren. Unbemerkter Betrieb mit veralteten Daten ist nicht akzeptabel. Eine verlässliche Data-Warehouse- und Datenübernahmeschicht ist deshalb Teil des Entscheidungssystems und nicht bloß technische Vorarbeit.

Prüfpunkt 3: Duplikate und Identität

Duplikate sind oft Identitätsfehler, die wie Bereinigungsaufgaben aussehen. Derselbe Lieferant, dasselbe Produkt, derselbe Auftrag oder Standort kann unter verschiedenen Kennungen auftreten. Umgekehrt kann eine Kennung über Regionen oder Systeme hinweg wiederverwendet werden. Ein Modell kann ein undefiniertes Entitätsmodell nicht reparieren.

Zuerst legen wir die fachliche Identitätsregel fest: Wann beziehen sich zwei Datensätze auf dieselbe Entität, und in welchem Geltungsbereich? Dann bewahren wir sowohl die ursprünglichen Kennungen als auch eine kanonische Kennung auf, einschließlich Abgleichmethode und Konfidenz. Deterministische Schlüssel haben Vorrang. Ein probabilistischer Identitätsabgleich darf Zuordnungen vorschlagen, aber unsichere Zusammenführungen gehören in eine Warteschlange zur Prüfung. Eine falsche Zusammenführung kann jedes nachgelagerte Merkmal und Ergebnis verfälschen.

Die Eignung für den Einsatz erfordert gemessene Duplikatraten nach Quelle und Segment statt eines einzigen globalen Prozentsatzes. Außerdem sind reversible Entscheidungen zur Zusammenführung, Regeln zur Auswahl maßgeblicher Werte bei widersprüchlichen Feldern und die Überwachung neuer Kollisionsmuster erforderlich. Kann das Team nicht erklären, welcher Datensatz Vorrang hat und warum, ist es nicht bereit, Entscheidungen auf Grundlage dieser Entität zu automatisieren.

Deshalb ist die vollständige Kontrolle über die eigenen Betriebsdaten wichtig: Die Aufbewahrung der unverarbeiteten Historie und stabiler Kennungen ermöglicht spätere Abgleiche und erneute Verarbeitung, auch wenn sich vorgelagerte Schnittstellen ändern.

Prüfpunkt 4: Ausgangswerte

Ohne Ausgangswerte wird ein KI-Ergebnis zur Demo statt zu einem messbaren Eingriff in den Prozess. Vor einer Änderung des Workflows dokumentieren wir die aktuelle Leistung: Fehlerquote, Durchlaufzeit, Prüfaufwand, Abdeckung, Anzahl der Ausnahmefälle und das Geschäftsergebnis, das die Entscheidung beeinflussen soll.

Wo Vertraulichkeit wichtig ist, veröffentlichen wir interne Nachweise als normalisierten Index. Der Zustand vor dem Eingriff ist Baseline = 100. Nachfolgende Zeiträume zeigen die relative Veränderung gegenüber diesem Ausgangswert; die zugrunde liegenden absoluten Werte bleiben in der autorisierten Messumgebung. Nenner, betrachtete Population und Zeitfenster müssen gleich bleiben, sonst erzeugt der Index eine falsche Vergleichbarkeit.

Bei der Festlegung der Ausgangswerte ist auch eine Segmentierung nötig: Eine Gesamtverbesserung kann Verschlechterungen in einem risikoreichen Markt, einer Produktklasse oder Kundengruppe verdecken. Wir legen die relevanten Segmente vorab fest und erfassen gleichzeitige Änderungen wie Verkaufsaktionen, neue Richtlinien oder Personalverschiebungen. Das ermöglicht keine perfekte kausale Schlussfolgerung, verhindert aber die offensichtlichsten Fehler bei der Zuschreibung von Wirkungen.

Der Prüfpunkt ist bestanden, wenn sich die Ausgangswerte aus versionierten Daten und Definitionen reproduzieren lassen. Ein Dashboard-Screenshot reicht nicht aus.

Prüfpunkt 5: Handlungsrechte

Datenzugriff ist keine Handlungserlaubnis. Eine Anwendung darf möglicherweise einen Auftrag lesen, aber nicht stornieren, einen Produktdatensatz prüfen, aber nicht veröffentlichen oder eine Empfehlung berechnen, aber keinen Preis ändern. Wir erfassen die Befugnisse für jede einzelne Aktion.

Die Übersicht umfasst das führende System, den berechtigten Akteur, die erforderliche Freigabe, Wert- oder Risikogrenzen, Funktionstrennung und den Weg zum Rücksetzen einer Änderung. Zu Beginn sollte das System meist nur lesend arbeiten oder Empfehlungen geben. Ein Probelauf ohne Änderungen kann anschließend vorgeschlagene Aktionen mit menschlichen Entscheidungen vergleichen. Freigegebene Schreibaktionen folgen erst, wenn Kontrollen für Identität, Validierung, Protokollierung und Wiederherstellung nachgewiesen sind.

Dieser Prüfpunkt verbindet Governance mit Softwaredesign: Zugangsdaten sollten nur die minimal nötigen Berechtigungen gewähren; Werkzeuge sollten Lese- und Schreibaktionen trennen; Aktionen mit erheblichen Auswirkungen sollten ein ausdrückliches Freigabe-Token verlangen. Jede Zustandsänderung sollte, soweit möglich, idempotent sein und eine Korrelations-ID tragen. „Menschliche Prüfung im Ablauf“ bleibt zu vage, solange nicht feststeht, welche Person an welchem Punkt mit welchen Informationen und welcher Reaktionszeit beteiligt ist.

Prüfpunkt 6: Ergebnismessung

Modellqualität ist notwendig, aber nicht ausreichend. Präzision, Trefferquote oder Erfolgswerte für Aufgaben beschreiben das Verhalten auf einem Evaluationsdatensatz. Im Betrieb zählt, ob das System eine Entscheidung verändert hat und ob diese Änderung das beabsichtigte Ergebnis ohne unvertretbare Nebenwirkungen verbessert hat.

Wir erfassen die gesamte Kette von der Eingabe über Empfehlung, Prüfung und Aktion bis zum Ergebnis. Jede Stufe braucht eine stabile Kennung, damit sich ein späteres Ergebnis mit den beteiligten Versionen von Modell, Regeln und Quelldaten verknüpfen lässt. Wir protokollieren auch Fälle, in denen das System auf eine Empfehlung verzichtet, und abgelehnte Empfehlungen, nicht nur akzeptierte Ausgaben. Sonst wird der Feedback-Datensatz zugunsten einfacher Fälle verzerrt.

Der Messplan legt ein primäres Ergebnis, Kennzahlen für Schutzvorgaben und einen Prüfrhythmus fest. Zu diesen Kennzahlen können Fehlerschwere, Anteil gezielter Übersteuerungen, Beschwerden, Richtlinienverstöße, Latenz oder auf ein anderes Team verlagerter Arbeitsaufwand gehören. Ein System, das eine Warteschlange verkleinert, indem es eine größere versteckte Warteschlange erzeugt, hat die operativen Abläufe nicht verbessert.

Eine praktische Bewertung der Einsatzbereitschaft

Wir nutzen das Bewertungsmodell zur Dokumentation von Entscheidungen, nicht als dekorative Punktzahl. Jeder Prüfpunkt erhält einen von vier Zuständen:

Status	Bedeutung	Folge für die Freigabe
Unbekannt	Nachweise wurden noch nicht erhoben	Kein Pilotbetrieb mit Aussagen über den operativen Nutzen
Definiert	Verantwortliche Person, Definition und Test sind festgelegt	Nur Offline-Evaluation
Überprüft	Test auf repräsentativen Daten bestanden	Kontrollierter Workflow-Pilot
Überwacht	Schwellenwert für den Produktivbetrieb und Reaktion sind festgelegt	Für eine begrenzte Skalierung freigegeben

Durchschnitte täuschen. Fünf überwachte Prüfpunkte gleichen keine unbekannten Handlungsrechte aus. Die mögliche Freigabe wird durch den schwächsten Prüfpunkt begrenzt, der erheblichen Schaden verursachen oder die Messung ungültig machen kann.

Für Entwickler wird die Bewertung zu einer Aufgabenliste für Abnahmetests: Abfragen zur Datenherkunft und Verarbeitungshistorie, Aktualitätsprüfungen, Eindeutigkeitstests, Berechnungen der Ausgangswerte, Berechtigungsprüfungen und Verknüpfungen mit Ergebnissen. Für Führungskräfte wird sie zu einem Portfoliofilter. Er zeigt, welche Vorhaben Datenarbeit brauchen, welche in einen kontrollierten Pilotbetrieb gehen können und welche gestoppt werden sollten, weil die Entscheidung selbst unzureichend definiert ist.

Investitionen vor der Modellwahl ordnen

Sobald die Prüfpunkte sichtbar sind, lassen sich Investitionen sachgerechter ordnen. Wir können ein Kennungsproblem beheben, bevor wir mehr Inferenzkapazität kaufen, Ereigniskontext ergänzen, bevor wir eine Prognose beauftragen, und Handlungsrechte klären, bevor wir einen Agenten bauen, der nirgendwo handeln darf. Ebenso können wir Ausgangswerte sichern, bevor eine Prozessänderung den Vergleichszeitraum zerstört.

Erst dann wird die Modellwahl sinnvoll. Der Evaluationsdatensatz sollte aus der überprüften Population im Betrieb stammen und bekannte Ausnahmefälle einschließen. Modellkandidaten lassen sich nach Aufgabenerfolg, Kalibrierung, Latenz, Datenschutzvorgaben und Kosten vergleichen. Ein stärkeres Modell kann weder ein unbeobachtbares Ergebnis noch einen unautorisierten Schreibpfad ausgleichen.

So werden auch Piloten zu produktiven Systemen. Die Eignung der Daten ist keine einmalige Bereinigungsphase: Quellen verändern sich, Kennungen wechseln, Berechtigungen laufen ab und fachliche Definitionen entwickeln sich weiter. Jeder Prüfpunkt braucht deshalb eine verantwortliche Person, soweit möglich automatisierte Prüfungen und eine dokumentierte Reaktion auf überschrittene Schwellenwerte.

Die Frage für die Unternehmensführung

Die nützlichste Frage bei der Prüfung von KI im Unternehmen lautet nicht „Welches Modell verwenden wir?“, sondern: „Zeigen Sie uns die Kette vom Nachweis aus der Quelle über die autorisierte Aktion bis zum gemessenen Ergebnis.“

Kann das Team diese Kette zeigen und reproduzieren, hat das Programm eine Grundlage, um zu lernen. Kann es das nicht, steigert mehr Modellleistung meist nur das Tempo und die Selbstsicherheit eines ungeprüften Prozesses. Die Eignung der Daten ist keine Vorbedingung, die vor der interessanten KI-Arbeit abgearbeitet werden muss. Sie ist der Kern des Betriebssystems, in dem KI vertrauenswürdig eingesetzt werden kann.