Bewertung der Datenreife

Ziel

Die Bewertung der Datenreife klärt, ob die verfügbaren Daten für einen bestimmten Anwendungsfall genügen und was die Lücke kostet. Sie folgt auf die Abgrenzung des Anwendungsfalls und geht der Wahl eines Modells oder eines Anbieters voraus.

Neil Lawrence stellt fest, dass Projektanträge den Daten wenig Aufmerksamkeit schenken. Sie unterschätzen die Arbeit mit den Daten und statten diese Arbeit mit zu wenig Mitteln aus. Nithya Sambasivan und ihre Mitautorinnen und Mitautoren haben 53 KI-Fachleute aus Bereichen mit hohem Risiko befragt. Sie nennen die negativen Folgen, die ein Datenproblem weiter hinten im Ablauf auslöst, "Datenkaskaden". Diese Folgen bleiben oft unsichtbar und zeigen sich spät. 92% der Befragten haben mindestens eine erlebt.

Das Ergebnis ist ein Register zur Datenreife. Jede Zeile beschreibt einen Datensatz: das Ergebnis der Prüfungen, die erreichte Stufe, den Status, die verantwortliche Person für jede Lücke und deren geschätzte Kosten. CRISP-DM dokumentiert das Datenverständnis in Berichten zur ersten Datenerhebung, zur Beschreibung, zur Exploration und zur Qualität der Daten. Das Register verdichtet die Berichte zur Erhebung, zur Beschreibung und zur Qualität auf eine Zeile je Datensatz. Die Exploration gehört zur explorativen Datenanalyse. Der Sponsor liest im Register ab, was das Projekt vor dem ersten Modell bezahlen muss.

Einsatz

Wann einsetzen

• KI-Anwendungsfall abgegrenzt: die Daten hinter den Blöcken des AI Canvas prüfen, bevor Budget gesprochen wird.
• Offerte eines Anbieters zu beurteilen: prüfen, ob die Organisation die Daten besitzt, die die Lösung voraussetzt.
• Daten, die "irgendwo vorhanden sein müssen": einen Auszug beschaffen, bevor die Planung auf ihnen aufbaut.
• Neue Frage an bereits genutzte Daten: die Prüfung der Eignung wiederholen.
• Zusammenführung zweier bereits bewerteter Datensätze: den kombinierten Datensatz bewerten. Er birgt eigene Risiken der Reidentifizierung.
• Generativer Assistent auf internen Dokumenten: den Dokumentbestand wie einen Datensatz bewerten.
• Dashboard oder Analyse ohne KI: dieselben Prüfungen auf die Quellen anwenden, bevor der Bericht entsteht.

Wann nicht einsetzen

• Anwendungsfall noch nicht gewählt: Ohne Aufgabe lässt sich Stufe A nicht beurteilen. Die Liste der Daten ist dann nur eine Vermutung. Zuerst die Anwendungsfälle erfassen und priorisieren.
• Datensatz akzeptiert und geladen, jetzt vertieft zu verstehen: zur explorativen Datenanalyse übergehen.
• Daten eines noch zu bauenden Systems: Es gibt nichts zu bewerten. Die Elemente in einem Datenwörterbuch definieren.

Beschreibung

Die Reifestufen nach Lawrence

Neil Lawrence hat 2017 in einem Positionspapier Datenreifegrade (Data Readiness Levels) vorgeschlagen. Vorbild sind die Technologie-Reifegrade der NASA. Kein Normungsgremium hat sie standardisiert. Die Reifegrade bilden drei Stufen: A, B und C. Jede Stufe ist weiter unterteilt. Die Unterteilung reicht von C4 für die Daten mit der geringsten Reife bis A1 für die Daten mit der höchsten.

Stufe C betrifft den Zugriff. Auf C4 behauptet jemand, die Daten existierten. Niemand hat sie gesehen. Lawrence spricht von Daten vom Hörensagen: "Der Verkauf muss darüber eine Aufstellung haben." Auf C1 lassen sich die Daten in eine Analysesoftware laden. Die ethischen und rechtlichen Fragen ihrer Verarbeitung sind geklärt.

Stufe B betrifft die Verlässlichkeit. Beschreiben die geladenen Daten, was sie zu beschreiben vorgeben? Lawrence verortet in dieser Stufe die Hauptschwierigkeit der Data Scientists: den Abstand zwischen dem vermuteten und dem tatsächlichen Inhalt der Daten. B1 zu erreichen ist oft der teuerste Teil des Projekts. Auf B1 kennt die Analystin die Grenzen des Datensatzes. Unter B1 bleibt ein Mangel an Verlässlichkeit offen.

Stufe A betrifft die Eignung für eine Aufgabe. Ein Datensatz erreicht sie erst, wenn die Aufgabe feststeht. Ein sauberer und vollständiger Datensatz enthält unter Umständen keine Spur der Zielvariable. Derselbe Datensatz kann für die Vorhersage von Kündigungen A1 erreichen und für die Vorhersage der Reaktion auf ein Angebot auf B1 bleiben.

Nach diesen Stufen ordnen wir die Prüfungen, die der Guide des IIBA und CRISP-DM liefern.

Vom Entscheid und von der Aufgabe ausgehen

Die Aufgabe legt die Liste der zu bewertenden Daten fest. Darum beginnt die Analystin mit ihr. Sie nimmt den abgegrenzten Anwendungsfall auf: den unterstützten Entscheid, was das Modell vorhersagt, die Handlung, die folgt. Daraus erstellt sie die Liste der benötigten Daten: die Eingabedaten, die Zielvariable und den Zeitraum der Historie. Die Liste trennt die bereits erhobenen Daten von den noch zu erhebenden.

Um die Erhebung zu planen, legt die Analystin auch fest, wann und wie die Daten erhoben werden und wie sie nach der Erhebung validiert werden.

Die Kriterien mit dem Fachbereich festlegen

Der Guide des IIBA überträgt die fachliche Validierung den Stakeholdern, die über die Daten bestimmen. Sie genehmigen die Quellen und legen die Akzeptanzkriterien fest. Ein Akzeptanzkriterium sagt zum Beispiel, welcher Anteil leerer Werte bei der Zielvariable tragbar ist oder welchen Zeitraum die Historie abdecken muss. Vor den Prüfungen macht die Analystin diese Akzeptanzkriterien prüfbar. Eine Schwelle, die nach der Messung festgelegt wird, richtet sich nach dem Ergebnis.

Existenz und Eigentümer prüfen

Für jede Zeile der Liste hält die Analystin fest, wer die Daten besitzt und in welchem System. Eine Behauptung wie "Das Callcenter erfasst den Grund jedes Anrufs" bleibt auf C4, bis ein Auszug sie bestätigt. Ohne Auszug entdeckt das Projekt erst in der Entwicklung ein leeres Feld oder einen anderen Zeitraum. Die Analystin verlangt vom Eigentümer einen echten Auszug über den betrachteten Zeitraum. Eine Feldbeschreibung oder ein Datenbankschema ersetzt den Auszug nicht. Das Datenwörterbuch sagt, was das Feld enthalten sollte. Der Auszug zeigt, was es enthält.

Zugriff und Nutzungsrecht prüfen

Der Zugriff wirft technische Fragen auf: das Format, den Speicherort, die Verteilung der Daten auf mehrere Systeme. Ein von Hand geführtes Register, ein PDF oder ein altes Maschinenformat sind häufige Fälle. Interne Daten sind oft günstiger zu beschaffen als externe. Der Guide des IIBA ergänzt die nicht funktionalen Anforderungen der Quelle: Vertraulichkeit, Sicherheit, Aufbewahrungsdauer, Erhebungshäufigkeit und Service Level Agreements. Eine Anforderung an Vertraulichkeit oder Sicherheit kann einen Datensatz allein unbrauchbar machen.

Das Nutzungsrecht wirft rechtliche und vertragliche Fragen auf. CRISP-DM verlangt, dieses Recht zu prüfen. Daten, die zur Erfüllung eines Vertrags erhoben wurden, dürfen nicht immer zum Trainieren eines Modells verwendet werden. Eine Lizenz für externe Daten kann diese Nutzung ausschliessen. Die Analystin benennt die Einschränkung und die Stelle, die darüber entscheidet. Personendaten fallen unter das Datenschutzgesetz.

Die Qualität am Auszug prüfen

Die Analystin misst die Qualität an dem Auszug, den das Projekt verwenden wird. Der Guide des IIBA nennt fünf Merkmale und schlägt für jedes einen Test vor. CRISP-DM und Lawrence ergänzen die Codierung fehlender Werte.

Daten, die in einer Tabellenkalkulation bearbeitet wurden, verlangen eine zusätzliche Prüfung. Lawrence nennt die Sortierung, die eine Spalte auslässt und Werte ohne Fehlermeldung verschiebt. Er ordnet auch die Prüfung des Erhebungsverfahrens der Stufe B zu: War die Erhebung zufällig oder gezielt? Der Guide des IIBA hält fest, dass die Validierung in diesem Stadium summarisch bleibt. Die explorative Datenanalyse untersucht die Daten danach im Detail.

Die Datenherkunft nachzeichnen

Die Datenherkunft (Lineage) sagt, woher die Daten kommen, welche Umwandlungen sie durchlaufen haben und wo sie gespeichert sind. Ohne Datenherkunft kann die Analystin die Qualität nicht beurteilen. Aggregierte Daten können ihre fehlenden Werte verbergen. Lawrence berichtet von einem Projekt zur Vorhersage von Malaria in Uganda. Die Daten je Bezirk waren aggregiert worden, ohne die fehlenden Werte zu behandeln. Das Modell zeigte zunächst keine räumliche Korrelation. Auf den Rohdaten behandelte das Team die fehlenden Werte und fand die erwartete Korrelation wieder. Ein Verarbeitungsfehler in Stufe B führte zu einem negativen Ergebnis in Stufe A. Niemand hatte die Aggregation dokumentiert. Die Datenherkunft macht einen solchen Schritt vor der Modellierung sichtbar.

Zwei Quellen codieren dieselbe Information manchmal verschieden: Ziffern in der einen, Buchstaben in der anderen. Die Analystin notiert die herzustellende Zuordnung. Das Data Mapping spezifiziert sie danach.

Menge und Repräsentativität für die Aufgabe beurteilen

Keine der zitierten Quellen legt eine Mindestmenge fest. Die Antwort hängt von der Aufgabe und vom Modell ab. Wir raten zu einer prüfbaren Frage: Hat jeder Fall, den der Entscheid unterscheiden muss, genug Beispiele in der Historie? Ein jährliches Ereignis wie ein Vertragsablauf verlangt mehrere Jahre Historie. Ein Kanton mit wenig Kundschaft oder ein neues Produkt zählt unter Umständen nur einige Dutzend Fälle.

Die Repräsentativität misst sich an der Population, über die das Modell entscheiden wird. Eine Umfrage, deren Stichprobe von der Zielpopulation abweicht, ist der klassische Fall. Eine Historie, die nur die von einer Mitarbeiterin ausgewählten Dossiers enthält, spiegelt diese Auswahl. Solche Verzerrungen lassen sich in diesem Stadium erkennen, bevor ein Modell sie lernt.

Diese Prüfung ordnet einen Datensatz für eine bestimmte Aufgabe der Stufe A zu. Eine andere Aufgabe ergibt ein anderes Ergebnis.

Entscheiden: starten, zuerst korrigieren oder abbrechen

Keine der zitierten Quellen formuliert diesen Entscheid mit drei Ausgängen. Er ist unsere Empfehlung aus der Praxis. Die Analystin gibt zuerst jedem Datensatz einen Status: akzeptiert, behebbar oder verworfen. Danach erhält der Anwendungsfall seinen Entscheid.

Die Stakeholder, die über die Daten bestimmen, genehmigen die akzeptierten Quellen und unterzeichnen das Register.

Der Entscheid über den Anwendungsfall hängt von seinen erforderlichen Datensätzen ab. Sind alle akzeptiert, startet er. Ein erforderlicher Datensatz mit dem Status "behebbar" führt zu "zuerst korrigieren": Der Anwendungsfall wartet auf die Korrektur. Ein verworfener erforderlicher Datensatz bricht den Anwendungsfall ab. Ein verworfener ergänzender Datensatz verkleinert den Umfang. Das Modell entsteht ohne ihn. Google rät, ein Produkt ohne maschinelles Lernen zu lancieren, solange die Daten fehlen. Nach diesem Leitfaden erzielt eine einfache Heuristik einen Teil des erwarteten Nutzens.

Der Guide des IIBA lässt zu, dass eine Forschungsfrage fallen gelassen wird, wenn die Daten zu teuer zu beschaffen sind. Lawrence nennt Beispielaussagen, die seine Reifegrade möglich machen. Eine schätzt die Kosten, einen Datensatz auf B1 zu bringen. Eine andere verschiebt eine Studie, bis ein Partner einen Datensatz auf C1 garantiert.

Was die Bewertung verfälscht

Die am Data Warehouse gemessene Qualität. Das Datenteam versichert, das Data Warehouse sei sauber. Das Projekt filtert jedoch einen Zeitraum, ein Produkt oder eine Region. Die Analystin misst den Auszug des Projekts. Er hat seine eigenen Mängel.

Die nicht neu bewertete Zusammenführung. Zwei getrennt bewertete Datensätze ergeben einen kombinierten Datensatz, der neu zu bewerten ist. Nach Lawrence lassen sich medizinische Daten leicht reidentifizieren, sobald man sie mit anderen Datensätzen verknüpft. Zwei verschiedene Erhebungsprotokolle erschweren die Zusammenführung zusätzlich.

Die unterschätzte Arbeit an den Daten. Lawrence plante einige Stunden eines Wochenendes ein, um die Metadaten der Beiträge einer Konferenz ladbar zu machen. Die Arbeit dauerte rund sechs Arbeitstage. Der Datensatz umfasste 3'198 Beiträge und warf keine Frage der Vertraulichkeit auf. Das Register beziffert jede Lücke, damit diese Kosten ins Budget eingehen.

KI-Überlegungen

Ein KI-Assistent, der Code ausführt, beschleunigt das Profiling. Aus einem Datenwörterbuch schreibt er die Abfragen, die Nullwerte, Duplikate und Sonderwerte zählen. Er fasst die Ausgabe eines Profiling-Werkzeugs in einer Liste von Auffälligkeiten zusammen, die an den Eigentümer gehen. Er liest eine Stichprobe eines Freitextfelds und schätzt ab, was es enthält. Er formuliert die Fragen an jeden Dateneigentümer.

Der Assistent bestätigt die Existenz von Daten nicht. Ein Assistent, der behauptet: "Ihr CRM erfasst wahrscheinlich das Datum des letzten Kontakts", liefert Hörensagen. Sein Satz bleibt auf C4 wie jede Behauptung ohne Auszug. Über das Nutzungsrecht urteilt er ebenfalls nicht. Darüber entscheiden die Juristin und der Eigentümer. Der Auszug enthält oft Personendaten. Die Analystin gibt ihn nur einem Assistenten, den ihre Organisation freigegeben hat. Andernfalls arbeitet sie mit einem anonymisierten Auszug.

Bei einem generativen Assistenten, der aus internen Dokumenten antwortet, sind diese Dokumente die Daten. Wir wenden auf den Dokumentbestand dieselben Prüfungen an. In Stufe C: Liegen die Dokumente in lesbarer Form vor? Wer darf welches lesen? In Stufe B: Welche Fassung ist massgebend? Welche sind veraltet? In Stufe A: Decken sie die Fragen ab, die die Nutzerinnen und Nutzer stellen werden? Die Retrieval-Augmented Generation (RAG) behebt keinen dieser Mängel: Sie gibt sie in ihren Antworten wieder.

Die KI-Verordnung der EU formuliert ähnliche Prüfungen in Artikel 10, Absätze 2 bis 4. Dieser Artikel gilt für Hochrisiko-KI-Systeme. Er erfasst auch einen Schweizer Anbieter, der ein solches System auf dem Markt der Europäischen Union in Verkehr bringt. Zu den Verfahren der Daten-Governance gehören die Bewertung der Verfügbarkeit, der Menge und der Eignung der benötigten Datensätze sowie die Ermittlung von Datenlücken. Die Datensätze müssen im Hinblick auf die Zweckbestimmung des Systems relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig sein. Sie berücksichtigen die geografischen, kontextuellen, verhaltensbezogenen oder funktionalen Rahmenbedingungen seiner Verwendung. Ein Projekt ausserhalb des Hochrisikobereichs kann diese Anforderungen als Prüfraster verwenden.

Beispiele

Ein Hausratversicherer aus der Romandie will vorhersagen, welche Kundinnen und Kunden ihre Police auf den Vertragsablauf kündigen. Die Policen und die Schadenfälle sind für den Anwendungsfall erforderlich. Die Anrufgründe sind ergänzend. Das Register per 30. Juni 2025 gibt jedem Datensatz einen Status.

Kein Budget füllt die fehlende Historie der Anrufgründe. Nur die Zeit füllt sie. Bei den Schadenfällen machen fünf Arbeitstage an der Zuordnung der Codes sechs Jahre Historie nutzbar. Diese Kosten rechtfertigen die Korrektur des Datensatzes.

Visualisierungen

Das Register passt in eine Tabelle: eine Zeile je Datensatz, eine Spalte je Prüfung, die Stufe und der Status am Zeilenende. Eine Farbe je Status macht das Register für einen Ausschuss lesbar. Teilen sich mehrere Anwendungsfälle einen Datensatz, zeigt eine Spalte je Anwendungsfall die Stufe, die der Datensatz für jeden erreicht.

Aufwand

Werkzeuge

Für das Register genügt eine Tabellenkalkulation. Die Analystin profiliert einen Auszug mit SQL auf der Quelldatenbank. In Python zählt ydata-profiling Nullwerte, Duplikate und Verteilungen je Feld. Great Expectations hält Qualitätsprüfungen als ausführbare Regeln fest. Mit OpenRefine lässt sich ein Auszug ohne Programmierung erkunden. Ein Datenkatalog wie DataHub, Collibra oder Microsoft Purview liefert die Eigentümer und die Datenherkunft, wenn die Organisation einen führt. Das Datenwörterbuch liefert die erwartete Definition jedes Felds. Der Auszug bestätigt oder widerlegt sie.

Quellen

Kein Wissensstandard beschreibt die Bewertung der Datenreife als eigenständige Technik. Der Guide des IIBA beschreibt ihre Prüfungen. Die Stufen von Lawrence sind der Vorschlag eines einzelnen Autors. Der Entscheid mit drei Ausgängen ist unsere Synthese.

• IIBA (2020), Guide to Business Data Analytics, §2.2 Source Data (§2.2.1 bis §2.2.4) und §2.3.3 Explore Data: die Planung der Datenerhebung, die nicht funktionalen Anforderungen, die Datenlücken, die Datenherkunft, die fachliche und technische Validierung, die fünf Qualitätsmerkmale.
• Lawrence, N. D. (2017), Data Readiness Levels, arXiv:1705.02245: die Stufen C, B und A, die Daten vom Hörensagen, die Zusammenführung von Datensätzen und die beiden Fallstudien.
• Chapman, P. et al. (2000), CRISP-DM 1.0: Step-by-step data mining guide: die Phase des Datenverständnisses, ihre Berichte und das Recht, die Daten zu nutzen.
• Verordnung (EU) 2024/1689 über künstliche Intelligenz, Artikel 10, Absätze 2 bis 4: die Daten-Governance von Hochrisiko-Systemen.
• Sambasivan, N. et al. (2021), "Everyone wants to do the model work, not the data work": Data Cascades in High-Stakes AI, CHI '21: der Begriff der Datenkaskade und ihre Häufigkeit bei 53 KI-Fachleuten aus Bereichen mit hohem Risiko.
• Google, Rules of Machine Learning, Regel 1: ohne maschinelles Lernen lancieren, solange die Daten fehlen.