AI-Eignung ist mehr als ein Score

Begriffe vor dem Lesen

• Data Quality / DQ — Eignung von Daten für einen konkreten Zweck, nicht ein allgemeiner Schönheitswert.
• Regel — Prüfbare Erwartung an Daten mit Umfang, verantwortliche Person, Schwelle und Konsequenz.
• Quality Prüfpunkt — Entscheidungspunkt, der Daten nur bei erfüllter Erwartung weitergibt oder veröffentlicht.
• Vereinbarung / Vertrag — Vereinbarung zwischen Anbieter und Nutzer über Bedeutung, Qualität, Aktualität und Änderung.
• Incident — Vorfall, bei dem eine vereinbarte Erwartung verletzt wurde und daraus gelernt werden muss.

Ausgangslage

sales_otc scored 98 % gültig — der RAG-Bot darf customer_id trotzdem nicht trainieren. Fit-for-AI ist Zweck- und Rechteignung, kein einzelner Quality-Score.

Umgekehrt kann ein Datensatz mit bekannten Lücken für einen begrenzten Assistenzfall geeignet sein, wenn die Lücken sichtbar sind, das System Unsicherheit kommuniziert und ein Mensch die Aussage prüft. Eignung ist daher keine allgemeine Eigenschaft des Assets. Sie ist eine belegte Entscheidung für einen Zweck, eine Version, einen Zeitraum und eine Risikoklasse.

AI verstärkt Kontextverlust

Klassische Reports zeigen häufig feste Kennzahlen in einem bekannten Prozess. AI-Systeme kombinieren Daten dynamisch: Sie suchen Dokumente, bilden Embeddings, erzeugen Features, fassen Inhalte zusammen oder formulieren Empfehlungen. Dabei können Herkunft, Zeitbezug und Einschränkungen auf dem Weg vom Quelldokument zum Output verloren gehen.

Ein Sprachmodell formuliert zudem selbstbewusst, auch wenn Evidenz fehlt. Ein Ranking-Modell kann historische Verzerrungen reproduzieren. Ein Agent kann eine plausible Antwort in eine Aktion übersetzen. Deshalb genügt es nicht, Inputqualität zu messen. Die Eignungsentscheidung muss auch erlaubte Nutzung, Provenienz, Aktualität, bekannte Lücken und menschliche Kontrolle umfassen.

Ein Score verbirgt harte Ausschlusskriterien

Durchschnittswerte sind besonders riskant, wenn einzelne Bedingungen zwingend sind. 99 gute Kriterien kompensieren keine fehlende Nutzungsberechtigung. Hohe Vollständigkeit kompensiert keine unbekannte Herkunft. Aktuelle Daten kompensieren keine unzulässige automatisierte Entscheidung.

Scores dürfen Orientierung und Priorisierung unterstützen. Die Freigabe muss jedoch harte Gates und explizite Bedingungen kennen. „Nicht beurteilt“ ist dabei ein eigener Status, nicht automatisch ein niedriger oder hoher Score.

Leitentscheidung

Bewerte AI-Eignung als versionierte Use-Case-Freigabe mit Evidenz, nicht als universelles Gütesiegel. Jede Freigabe nennt erlaubte und verbotene Nutzung, Freshness-Anforderung, Provenienz, bekannte Lücken, Quality-Nachweise und erforderliche menschliche Genehmigung für hochwirksame Aussagen oder Aktionen.

Die Einheit der Bewertung

Bewerte nicht nur „die Tabelle“. Die kleinste sinnvolle Einheit verbindet:

• Datenasset oder Dokumentenmenge und Version,
• konkreten KI-Use-Case,
• Modell-, Retrieval- oder Agentenfunktion,
• betroffene Personen oder Geschäftsobjekte,
• geplanten Output und seine Wirkung,
• Betriebsumgebung und Zugriffsweg.

Dieselbe Wissensbasis kann für interne Suche erlaubt und für externe Rechtsauskunft ungeeignet sein. Dasselbe Kundenmerkmal kann für aggregierte Nachfrageplanung akzeptabel und für individuelle Preissetzung verboten sein.

Stack-neutraler Grundsatz

Die Bewertung funktioniert unabhängig davon, ob Daten in Warehouse, Lakehouse, Suchindex, Vektordatenbank, Filesystem oder SaaS liegen und ob das System klassische ML-, generative AI- oder Agententechnik nutzt. Entscheidend sind überprüfbare Fragen, nicht Produktnamen:

1. Darf dieser Inhalt für diesen Zweck verwendet werden?
2. Ist er aktuell genug für die behauptete Aussage?
3. Ist seine Herkunft bis zur Quelle nachvollziehbar?
4. Welche Population, Zeiträume und Perspektiven fehlen?
5. Welche Quality-Evidenz gilt für genau diese Version?
6. Welche Outputs brauchen menschliche Freigabe?
7. Was geschieht, wenn Evidenz fehlt oder veraltet?

Erlaubte Nutzung definieren

Rechtliche, vertragliche und interne Grenzen

Zugriff auf Daten bedeutet nicht automatisch Erlaubnis für jeden AI-Zweck. Verträge können Training, Weitergabe an Provider oder dauerhafte Speicherung ausschließen. Datenschutzgrundsätze können Zweckbindung, Minimierung oder Löschung verlangen. Interne Policies können sensible Merkmale von Profiling, Ranking oder automatisierter Entscheidung ausschließen.

Dokumentiere erlaubte Verwendungsarten getrennt: Training oder Fine-Tuning, Evaluation, Retrieval, Prompt-Kontext, Feature-Berechnung, Monitoring und manuelle Analyse. Eine Erlaubnis für Retrieval ist keine Erlaubnis für Training. Eine anonymisierte Evaluation ist nicht dasselbe wie Produktion mit personenbezogenem Kontext.

Verbote müssen ausführbar werden

Ein Tag „restricted“ informiert, erzwingt aber allein nichts. Übersetze Nutzungsbedingungen in Zugriffspolicies, Filter, getrennte Indizes, Retention, Provider-Konfiguration und Output-Gates. Prüfe auch abgeleitete Artefakte: Embeddings, Caches, Logs, Prompt-Traces, Trainingsschnappschüsse und exportierte Features können den Schutzbedarf erben.

Wenn technische Durchsetzung nicht möglich ist, muss die verbleibende manuelle Kontrolle explizit sein. Eine Freitextwarnung ohne Owner und Prüfpunkt ist keine belastbare Kontrolle.

Freshness ist aussageabhängig

Nicht „aktuell“, sondern aktuell genug

Freshness beschreibt die Zeit zwischen relevanter Realität, Erfassung, Verarbeitung und Nutzung. Für eine Richtlinienauskunft kann die letzte freigegebene Dokumentversion entscheidend sein. Für Bestandsdisposition können Minuten zählen. Für langfristige Segmentanalyse kann ein Monatsstand reichen.

Definiere daher:

• fachlichen Referenzzeitpunkt,
• späteste zulässige Quellaktualisierung,
• maximale End-to-End-Latenz,
• Umgang mit verspäteten Korrekturen,
• Verhalten bei überschrittenem Alter.

Der AI-Output sollte den Datenstand nennen, wenn Aktualität die Interpretation beeinflusst. „Basierend auf Informationen bis 24. August, 18:00 Uhr“ ist hilfreicher als ein unsichtbarer Freshness-Score.

Wissensverfall und widersprüchliche Versionen

Dokumente können gültig, abgelöst oder nur historisch relevant sein. Ein Retrieval-System darf eine alte Richtlinie nicht gleichwertig neben die aktuelle stellen. Erfasse Gültigkeitsbeginn, Ende, Version, ersetztes Dokument und Freigabestatus. Bei widersprüchlichen Quellen braucht das System eine Prioritätsregel oder muss an einen Menschen eskalieren.

Freshness-Monitoring prüft nicht nur, ob ein Index technisch neu gebaut wurde. Es muss belegen, dass die erwarteten Quellen und Versionen tatsächlich enthalten sind.

Provenienz bis zum Output erhalten

Herkunft ist mehr als ein Quellname

Belastbare Provenienz verbindet Output oder Feature mit Quelle, Version, Transformationsschritten und Auswahlentscheidung. Für generierte Antworten gehört dazu, welche Dokumentpassagen abgerufen wurden, wann sie gültig waren und welche Filter angewendet wurden. Für ML gehören Feature-Definition, Trainingsfenster, Label-Herkunft und Ausschlüsse dazu.

Ein pauschales „aus dem Data Lake“ ist keine Provenienz. Eine URL ohne Dokumentversion kann nachträglich anderen Inhalt zeigen. Verwende stabile IDs, Versionen, Zeitstempel und unveränderliche Evidenz, soweit Risiko und Aufwand es rechtfertigen.

Zitate sind notwendig, aber nicht immer hinreichend

Eine zitierte Quelle kann ungeeignet, veraltet oder falsch interpretiert sein. Prüfe daher neben Existenz auch Autorität, Gültigkeit und Unterstützung der konkreten Behauptung. Bei wichtigen Aussagen sollte nachvollziehbar sein, welcher Teil der Quelle die Aussage trägt.

Wenn der Output mehrere Quellen synthetisiert, muss das System Widersprüche sichtbar machen. Es darf keine scheinbar eindeutige Antwort erzeugen, wenn autoritative Quellen unterschiedliche Regeln enthalten.

Bekannte Lücken aktiv modellieren

Fehlende Populationen und Perspektiven

Quality-Checks messen oft nur vorhandene Daten. AI-Eignung fragt zusätzlich, wer oder was nicht vertreten ist. Historische Daten können neue Produkte, kleine Regionen, seltene Fehlerfälle oder Gruppen mit geringer digitaler Nutzung unterrepräsentieren. Support-Tickets bilden nur Personen ab, die ein Ticket eröffnet haben.

Dokumentiere bekannte Lücken als strukturierte Einschränkungen: fehlende Population, Zeitraum, Ursache, erwartete Wirkung und kompensierende Maßnahme. „Daten unvollständig“ ist zu ungenau. „Keine belastbaren Beispiele für Verträge vor 2021; Antworten zu älteren Verträgen erfordern manuelle Prüfung“ ist handlungsfähig.

Unbekannte Lücken sichtbar lassen

Nicht jede Verzerrung ist bekannt. Erfasse deshalb, welche Analysen durchgeführt wurden und welche nicht. Stichprobenumfang, Vergleichspopulation und Testgrenzen gehören zur Evidenz. Ein fehlender Bias-Test darf nicht als bestandener Test erscheinen.

Das System braucht ein Verhalten bei geringer Abdeckung: Unsicherheit ausgeben, keine Empfehlung erzeugen, zusätzliche Quelle anfordern oder an einen Menschen eskalieren. Die richtige Reaktion hängt von der Wirkung des Outputs ab.

Menschliche Genehmigung für hochwirksame Aussagen

Wirkung statt Modelltyp

Ob menschliche Freigabe nötig ist, hängt nicht primär davon ab, ob ein großes Sprachmodell oder eine klassische Regel verwendet wird. Entscheidend ist die Wirkung: Beeinflusst der Output Beschäftigung, Kredit, Gesundheit, Sicherheit, Rechtsposition, Zugang zu Leistungen, wesentliche Preise oder eine irreversible externe Aktion?

Auch interne Aussagen können hochwirksam sein, etwa eine Betrugseinstufung oder eine Empfehlung zur Vertragskündigung. Klassifiziere Use-Cases nach Schadenspotenzial, Reichweite, Reversibilität und Möglichkeit zur Anfechtung.

Human-in-the-loop konkret gestalten

„Ein Mensch prüft“ ist zu vage. Definiere:

• welche Outputs vor Nutzung geprüft werden,
• welche Evidenz die prüfende Person sieht,
• welche Kompetenz und Berechtigung erforderlich ist,
• welche Entscheidungen möglich sind,
• wie Ablehnung und Korrektur erfasst werden,
• wann eine erneute Prüfung nötig ist.

Der Mensch darf kein Bestätigungsstempel für hohe Automatisierungsgeschwindigkeit sein. Die Oberfläche muss Quellen, Freshness, Unsicherheit und bekannte Lücken zeigen. Zeitbudget und Anreizsystem müssen echte Prüfung erlauben.

Automatisierungsgrenzen und Eskalation

Für niedrig wirksame Entwürfe kann nachgelagerte Stichprobe genügen. Für hochwirksame Behauptungen ist Freigabe vor Veröffentlichung oder Aktion angemessen. Bestimmte Fälle können vollständig ausgeschlossen sein, wenn keine ausreichende Evidenz oder rechtliche Grundlage besteht.

Lege Schwellen fest, die automatisch eskalieren: fehlende autoritative Quelle, abgelaufene Daten, Konflikt zwischen Quellen, geringe Abdeckung, sensible Kategorie oder Output außerhalb des erlaubten Scopes.

Quality-Evidenz mit dem Use-Case verbinden

Keine Wiederverwendung ohne Scope-Prüfung

Ein bestehender Quality-Test ist nur relevant, wenn sein Scope zum AI-Use-Case passt. Eindeutigkeit einer Kunden-ID beweist keine korrekte Kündigungsempfehlung. Dokumentvollständigkeit beweist nicht, dass alle aktuellen Richtlinien enthalten sind. Verknüpfe jede wichtige Output-Annahme mit passender Evidenz.

Nutze harte Gates für Nutzungsrecht, erforderliche Provenienz und hochwirksame Freigabe. Verwende Metriken und Scores für graduelle Eigenschaften wie Abdeckung oder Drift. So können Durchschnittswerte keine zwingende Bedingung überstimmen.

Laufzeitkontrollen ergänzen Designfreigabe

Eine einmalige Freigabe veraltet. Quellen ändern sich, Modelle werden aktualisiert, Prompts angepasst und Populationen verschieben sich. Definiere Trigger für Neubewertung: neue Quelle, neue Zweckbestimmung, Modell- oder Prompt-Major-Version, deutliche Drift, Incident, Policy-Änderung oder abgelaufenes Review.

Laufzeitkontrollen überwachen Freshness, Quellabdeckung, Zugriff, Output-Policy und Eskalationsrate. Sie beweisen nicht allein die Eignung, liefern aber Evidenz, ob die Freigabebedingungen weiter gelten.

Outputs als neue Evidenzobjekte behandeln

Input-Eignung garantiert keinen geeigneten Output

Selbst freigegebene Daten können zu unbelegten oder irreführenden Ergebnissen führen. Retrieval kann die falsche Passage auswählen, ein Modell kann Quellen vermischen, und ein Agent kann einen korrekten Fakt im falschen Entscheidungskontext anwenden. Ergänze die Dateneignung deshalb um Output-Evaluation für die behauptete Funktion.

Geeignete Kriterien sind Quellenunterstützung, fachliche Korrektheit, relevante Abdeckung, Unsicherheitskommunikation, Einhaltung des erlaubten Scopes und sichere Ablehnung. Die Testfälle müssen reale Grenzfälle, widersprüchliche Quellen, veraltete Inhalte und fehlende Evidenz enthalten. Ein Durchschnitt über einfache Fragen beweist keine Sicherheit bei den kritischen Fällen.

Behauptung und Aktion getrennt kontrollieren

Eine textliche Behauptung und eine ausgeführte Aktion haben unterschiedliche Risiken. Ein Agent darf möglicherweise einen Änderungsvorschlag erzeugen, aber nicht ohne Freigabe einen Vertrag kündigen oder einen Datensatz löschen. Trenne deshalb Leserechte, Vorschlagsrecht, Freigabe und Ausführung technisch und organisatorisch.

Protokolliere bei hochwirksamen Vorgängen die verwendete Evidenz, Modell- und Prompt-Version, Entscheidung des Menschen und tatsächlich ausgeführte Aktion. Vermeide dabei unnötige Speicherung sensibler Volltexte. Auditierbarkeit und Datenminimierung müssen gemeinsam entworfen werden.

Feedback ist nicht automatisch Wahrheit

Nutzerreaktionen helfen, Fehler und fehlende Quellen zu erkennen. Ein Klick, eine Übernahme oder ein positives Rating beweist jedoch keine Korrektheit. Behandle Feedback als Signal mit Herkunft und Kontext. Fachlich bestätigte Korrekturen können Evaluationsfälle oder neue Quality-Regeln werden; ungeprüfte Präferenzen dürfen nicht direkt autoritative Metadaten überschreiben.

Verfolge außerdem Automation Bias: Wie oft übernehmen Prüfer Vorschläge unverändert, wie häufig erkennen sie absichtlich eingebaute Fehler, und welche Zeit steht ihnen zur Verfügung? Eine nominelle Human-Approval-Rate von 100 Prozent ist wertlos, wenn die Kontrolle praktisch keine Abweichung entdeckt.

Betriebsmodell

Rollen

Der Data Product Owner verantwortet Datenversprechen und bekannte Grenzen. Der Use-Case Owner verantwortet Zweck, Wirkung und Prozessintegration. Privacy, Security oder Legal entscheiden über einschlägige Nutzungsbedingungen. Fachverantwortliche definieren autoritative Quellen und prüfen hochwirksame Aussagen. Engineering setzt Filter, Gates, Logging und Versionierung um. Risk oder Governance stellt konsistente Kriterien und Review sicher.

Eine zentrale AI-Stelle darf die fachliche Verantwortung nicht ersetzen. Sie schafft Standards und unabhängige Challenge; die Freigabe bleibt bei den Personen, die Daten und Wirkung tatsächlich verantworten.

Statusmodell

Verwende mindestens: nicht bewertet, bedingt geeignet, geeignet für definierten Zweck, pausiert und nicht geeignet. „Bedingt“ nennt konkrete Einschränkungen und Ablaufdatum. Kein Status gilt universell für andere Use-Cases.

Veröffentliche Status, Scope, Evidenzdatum und Owner zusammen. Ein grünes Label ohne diese Angaben lädt zur unzulässigen Wiederverwendung ein.

Hilfe

Beginne nicht mit einem unternehmensweiten AI-Readiness-Score. Wähle einen realen Use-Case und einen konkreten Output. Formuliere zuerst, welche Aussage oder Aktion das System erzeugt und wer davon betroffen ist. Prüfe dann Erlaubnis, Freshness, Provenienz, Lücken und menschliche Kontrolle.

Wenn Metadaten fehlen, setze den Status auf „nicht bewertet“ oder „bedingt“ und benenne die fehlende Evidenz. Lass ein Modell keine autoritative Bedeutung, Lizenz oder Population aus Samples erraten. AI kann Entwürfe und Analysehinweise erzeugen; verantwortliche Personen müssen kritische Metadaten bestätigen.

Checkliste

• Ist der konkrete KI-Use-Case mit Zweck und Output beschrieben?
• Sind Datenasset, Modellfunktion und Betriebsumgebung versioniert?
• Ist Nutzung für Training, Retrieval, Prompt-Kontext und Evaluation getrennt bewertet?
• Werden sensible Ableitungen und abgeleitete Artefakte berücksichtigt?
• Ist die Freshness-Anforderung an die Aussage gebunden?
• Sind Dokumentgültigkeit und ersetzte Versionen erfasst?
• Reicht Provenienz bis zu Quellen und relevanten Transformationen?
• Werden autoritative und widersprüchliche Quellen unterschieden?
• Sind bekannte Populations-, Zeitraum- und Perspektivlücken dokumentiert?
• Ist fehlende Evidenz als „unbekannt“ sichtbar?
• Ist die Wirkungsklasse des Outputs festgelegt?
• Ist menschliche Prüfung für hochwirksame Aussagen konkret gestaltet?
• Gibt es harte Gates für unzulässige Nutzung und fehlende Pflichtnachweise?
• Sind Trigger für Neubewertung und ein Ablaufdatum definiert?
• Können Betroffene oder Nutzer eine Aussage anfechten und korrigieren lassen?

Artefakt

Das Kernartefakt ist ein AI Use-Case Evidence Sheet. Es enthält:

1. Use-Case-ID, Zweck, Owner und Wirkungsklasse,
2. Daten-, Dokument-, Modell- und Prompt-Versionen,
3. erlaubte und verbotene Nutzungen,
4. Freshness-Ziel und aktueller Datenstand,
5. Provenienzpfade und autoritative Quellen,
6. bekannte Lücken, nicht geprüfte Risiken und kompensierende Kontrollen,
7. Quality-Evidenz mit Scope, Lauf und Gültigkeit,
8. Human-Approval-Regeln und Eskalationsschwellen,
9. Status, Restrisiko, Entscheider und Ablaufdatum,
10. Neubewertungstrigger und Incident-Link.

Das Sheet ist kein einmaliges Formular. Es ist die prüfbare Momentaufnahme einer Freigabe und wird bei jeder wesentlichen Änderung versioniert.

Tools

• dbt DQ Rules Generator – Quality-Annahmen in prüfbare Regelkandidaten überführen, wenn strukturierte Daten Teil des Use-Cases sind.
• Schema YAML Editor – Felder, Beschreibungen, Tests und Versionen als technisches Evidenzartefakt pflegen.
• Governance KI Sanitizer – Inhalte vor der Übergabe an externe KI-Dienste auf sensible Angaben prüfen und bereinigen; er ersetzt keine Rechtsgrundlage oder Zugriffskontrolle.

OpenMetadata oder ein anderer Catalog kann Owner, Klassifikation, Lineage, Freshness und Quality-Ergebnisse bündeln. Prompt-Tools sind nur dann sinnvoll, wenn Prompt-Version und erlaubter Kontext tatsächlich Teil der Freigabe sind; ein gut formulierter Prompt kompensiert keine ungeeigneten Daten.

Weiterlesen

• Data-Junk- und KI-Brücke
• Operational Data Quality