Datenreife für KI: eine Checkliste für Führungskräfte

„Unsere Daten sind nicht bereit für KI“ ist der meistgesagte Satz in Vorgesprächen und fast immer ungenau. Daten sind nicht grundsätzlich bereit oder unbereit. Sie sind geeignet oder ungeeignet für einen bestimmten Anwendungsfall, unter bestimmten Bedingungen, für einen bestimmten Zeitraum.

Derselbe Datenbestand kann für einen internen Prototyp mit reinem Lesezugriff vollkommen ausreichen und für ein System, das in eine Kundenakte zurückschreibt, offensichtlich unzureichend sein. Die Prüfung beginnt deshalb nicht bei den Daten, sondern bei der Arbeit.

1. Zweck: benennen Sie Entscheidung oder Aufgabe

Formulieren Sie den Zweck in betrieblicher Sprache. „Kundendaten mit KI nutzen“ liefert kein Prüfkriterium. „Die letzten drei freigegebenen Servicevorgänge für einen Berater vor dem Gespräch zusammenfassen“ benennt Nutzer, Aufgabe, Quellgrenze und Ergebnis. Nur das Zweite lässt sich bewerten.

Der Zweck hat auch rechtliche Bedeutung. Verordnung (EU) 2024/1689 knüpft Einstufung und Pflichten an die Zweckbestimmung, und die Anforderungen an die Daten-Governance bei Hochrisikosystemen hängen unmittelbar daran.

2. Bestand: verfolgen Sie den tatsächlichen Datenweg

Verfolgen Sie den Weg, wie er ist, nicht wie er dokumentiert ist. Wo entsteht der Datensatz, durch wie viele Systeme läuft er, wo wird er transformiert, wo in eine Tabelle kopiert und wo manuell neu erfasst. Die manuellen Schritte sind wichtig, weil dort die Herkunft verloren geht.

Ein nützliches Ergebnis dieses Schritts ist eine Liste der Stellen, an denen derselbe Wert in zwei Fassungen existiert. Wenn das Unternehmen nicht sagen kann, welche massgeblich ist, wird kein Modell das für es entscheiden.

3. Rechtsgrundlage: technisch möglich ist nicht zulässig

Technischer Zugriff ist keine Erlaubnis. Für jede Quelle muss klar sein, auf welcher Grundlage sie erhoben wurde, zu welchem Zweck und ob die geplante Nutzung damit vereinbar ist. Die Datenschutz-Grundverordnung setzt den Rahmen; die Orientierungshilfen der Datenschutzkonferenz gliedern ihn nach den Phasen Planung und Auswahl, Implementierung und Nutzung, was sich gut auf ein Projekt abbilden lässt.

Stammen Daten aus externen Quellen oder werden sie geteilt, können zusätzlich Verordnung (EU) 2022/868 über Daten-Governance und Verordnung (EU) 2023/2854 über Daten einschlägig sein. Der Vertrag mit dem Systemanbieter hebt keine davon auf.

4. Beschäftigtendaten sind ein eigener Fall

Sobald ein Datenbestand Rückschlüsse auf einzelne Beschäftigte zulässt, kommt neben dem Datenschutz die betriebliche Mitbestimmung ins Spiel. Nach § 87 Betriebsverfassungsgesetz genügt es, dass eine technische Einrichtung zur Überwachung von Verhalten oder Leistung objektiv geeignet ist — eine entsprechende Absicht ist nicht erforderlich.

Das trifft mehr Vorhaben, als Projektteams erwarten. Bearbeitungszeiten je Sachbearbeiter, Qualitätsbewertungen einzelner Vorgänge, Auswertungen von Servicegesprächen: All das ist zur Leistungsbeurteilung geeignet, auch wenn das Projekt auf Prozessverbesserung zielt. Die Frage gehört in die Bestandsaufnahme, nicht in die Abnahme.

5. Erforderlichkeit: das Minimum, das die Aufgabe trägt

Es ist verlockend, alles Verfügbare zu übergeben und das Modell auswählen zu lassen. Das erhöht Risiko, Kosten und die Reichweite jedes künftigen Fehlers. Beginnen Sie mit dem kleinsten Bestand, der die Aufgabe erfüllen kann, und ergänzen Sie erst, wenn die Evaluierung eine konkrete Lücke zeigt.

Minimierung ist zugleich ein praktischer Vorteil in der internen Abstimmung. Ein Anwendungsfall, der drei Felder nutzt, ist deutlich leichter freizugeben als einer, der Zugriff auf die vollständige Akte verlangt.

6. Qualität: Eignung für genau diese Nutzung

Qualität ist nicht abstrakt. Sie ist eine Menge konkreter Eigenschaften, bemessen an der Aufgabe: Vollständigkeit der genutzten Felder, Aktualität im Verhältnis zur Änderungsgeschwindigkeit, Einheitlichkeit des Formats und eine Definition, nach der zwei Personen das Feld gleich befüllen würden.

Ein Freitextfeld dort, wo der Prozess einen Schlüssel vorsieht, ist ein bekanntes Muster. Es lässt den Prototyp meist unbeschadet und verhindert die Skalierung.

7. Repräsentativität: wissen, wer und was fehlt

Menge garantiert keine Abdeckung. Fragen Sie, ob die Daten die Personen, Dokumenttypen, Sprachen, Produkte, Kanäle und Betriebszustände umfassen, in denen das System genutzt wird. Ein Klassifikationsmodell kann insgesamt genau wirken und bei einer kleinen, aber folgenreichen Fallgruppe systematisch versagen.

Für deutschsprachige Prozesse kommt eine sprachliche Dimension hinzu. Eine Bewertung auf englischem Text sagt wenig über die Leistung bei deutscher Korrespondenz mit Fachbegriffen, Abkürzungen und Komposita, die im Ausgangsmaterial nie vorkamen.

8. Nachvollziehbarkeit und Evaluierung

Beeinflusst ein Ergebnis eine Entscheidung, muss rekonstruierbar sein, woher es stammt: welcher Datensatz, welche Fassung, zu welchem Zeitpunkt. Das ist nicht nur eine Prüfanforderung, sondern die Voraussetzung dafür, Fehler gezielt zu beheben.

Der Evaluierungsdatensatz ist klein, schwierig und Ihr Eigentum. Er enthält echte Fälle mit bekannter richtiger Antwort, auch die Grenzfälle. Ihn zu bauen kostet einmal Zeit und dient danach bei jedem Wechsel von Modell, Anbieter oder Version. Die Funktionen Map und Measure des NIST AI Risk Management Framework geben eine Struktur dafür, was beschrieben und was gemessen wird.

9. Verantwortung: Datenreife ist ein Dauerzustand

Datenreife ist kein einmal erreichter Zustand. Quellen ändern sich, Felder werden neu definiert, Schnittstellen neu geschrieben. Es braucht eine verantwortliche Person für die konkreten Bestände, die konkrete Systeme nutzen, und einen Prüfrhythmus, der Änderungen erfasst, bevor sie als schlechteres Ergebnis auffallen.

Der Datenweg endet nicht an der Unternehmensgrenze

In der Praxis liegen die relevanten Daten selten nur in eigenen Systemen. Ein Teil stammt aus Vorsystemen von Dienstleistern, ein Teil aus Portalen von Kunden oder Lieferanten, ein Teil aus Fachanwendungen, die von einem externen Betreiber gepflegt werden. Für die Reifeprüfung heisst das, dass die Fragen nach Rechtsgrundlage, Qualität und Nachvollziehbarkeit auch für die Abschnitte beantwortet werden müssen, die ausserhalb liegen.

Zwei Punkte sind dabei besonders folgenreich. Erstens die Frage, ob Sie Änderungen an Struktur oder Bedeutung eines Feldes überhaupt erfahren — viele Auslagerungsverträge sehen keine Mitteilungspflicht bei Schemaänderungen vor, obwohl genau diese ein produktives Modell stillschweigend entwerten. Zweitens die Frage, ob Sie historische Stände zurückholen können; ohne sie ist eine spätere Fehleranalyse auf Vermutungen angewiesen.

Beides gehört in den Vertrag, nicht in die Projektdokumentation. Der günstigste Zeitpunkt dafür ist die nächste ohnehin anstehende Verlängerung, und der teuerste ist der Moment, in dem ein Ergebnis erklärt werden muss.

Historische Daten enthalten historische Entscheidungen

Vergangenheitsdaten sind das am leichtesten verfügbare Material und das am häufigsten missverstandene. Sie beschreiben nicht, was zutraf, sondern was entschieden und erfasst wurde. Wurden bestimmte Fälle über Jahre strenger behandelt, früher abgelehnt oder gar nicht erst erfasst, lernt das Modell die Praxis, nicht die Wirklichkeit.

Besonders sichtbar wird das bei Genehmigungsdaten. Zum Verhalten der abgelehnten Fälle existieren in der Regel keine Daten, weil sie nie Gelegenheit hatten, es zu zeigen. Ein Modell, das nur auf Genehmigungen trainiert, optimiert auf die Reproduktion der bisherigen Schwelle.

Eine Entscheidung auf einer Seite

Das Ergebnis lautet nicht „bereit“ oder „nicht bereit“. Es ist ein Satz mit Geltungsbereich: geeignet für einen lesenden Prototyp auf freigegebenen Dokumenten, nicht für das Zurückschreiben in eine Kundenakte; geeignet für ein Team und eine Sprache, nicht für das Gesamtunternehmen. Der Geltungsbereich ist eine Kontrolle — und die einzige, die sich einführen lässt, bevor Budget ausgegeben ist.

Was diese Prüfung nicht leisten kann

Die Reifeprüfung verbessert die Daten nicht. Sie zeigt, wo sie die Absicht nicht tragen, was oft unbequem ist, weil die Behebung langsam ist und nicht nach Innovation aussieht. Sie sagt auch nicht voraus, ob der Anwendungsfall Wert schafft — geeignete Daten sind eine Bedingung, keine Garantie.

Wenn Sie strukturiert prüfen lassen möchten, ob Ihre Daten einen konkreten KI-Anwendungsfall tragen, beginnen Sie mit der kostenlosen Diagnose.

Dieser Beitrag ist eine Adaption des englischen Originals. Im Zweifel gilt die englische Fassung.