Datenmüll vor AI

Begriffe vor dem Lesen

• Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, zuständige Fachrolle, Aktualität, Herkunft oder Qualitätsnachweis.
• KI-Suche — Retrieval-Augmented Generation: ein Modell ruft Inhalte zur Laufzeit ab, statt nur aus Training zu antworten.
• Training — Nutzung von Daten, um Modellverhalten oder Features zu lernen.
• Imputation / Schätzung — Ersetzen fehlender Werte durch abgeleitete Annahmen. Das muss sichtbar bleiben.
• KI-Fitness — Eignung eines Assets für Retrieval, Training oder Agentennutzung mit Zweck, Qualität, Rechten und Nachweis.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Verantwortung. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Nachweis: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Produkte und Entscheidungen

Datenmüll vor AI braucht nicht einfach einen größeren oder saubereren Index. Es braucht wenige klare Arbeitsprodukte, die Fachbereich, Stewardship und Plattformbetrieb gemeinsam verstehen.

Ausschlussregister für KI-Kontext

Dieses Produkt beschreibt:

• Asset-ID, Hygiene-Klasse, KI-Touchpoints, Entscheidung zum Lebenszyklus, Zweckstatus, zuständige Fachrolle, Steward und Wiedervorlage.

Entscheidungen:

• Welche Assets berühren den Pilot-Dokumentbestand?
• Wer darf eine Sperre aufheben?
• Welche leere Freigabe gilt als gesperrt und nicht als Kandidat?

Entscheidung vor Aufnahme in KI-Systeme

Ohne Lebenszyklusentscheidung kein KI-Kontext.

Es benötigt:

• Entscheidung aus der Hygiene-Serie: behalten, archivieren, stilllegen oder löschen.
• Datum und Link zum Inventar.
• Sperre für Index, Retrieval und Trainingsjob.

Entscheidungen:

• Welche Klassen sind standardmäßig gesperrt, etwa verwaiste Assets, Zombie-Reports oder unzulässige Schattenkopien?
• Wer stoppt die Aufnahme, wenn die Entscheidung fehlt?
• Wo wird festgehalten, dass „technisch vorhanden“ keine Freigabe ist?

Freigabe für KI-Suche und Training getrennt behandeln

KI-Suche und Training sind zwei verschiedene Nutzungen. Ein Dokument kann für die beantwortete Suche geeignet sein und trotzdem nicht für Training freigegeben sein.

Entscheidungen:

• Darf das Asset in eine KI-Suche, aber nicht ins Training?
• Wer darf Trainingsnutzung freigeben?
• Welche Dienstleister-Uploads brauchen zusätzlich einen Rechte- und Zwecknachweis?

Touchpoint-Liste

Die Touchpoint-Liste zeigt, wo Datenmüll bereits KI berührt: Indexe, Trainingsjobs, Dienstleister, Notebooks, Dateien, Agenten oder interne Suchsysteme.

Entscheidungen:

• Welche Indexe, Trainingsjobs, Dienstleister und Notebooks berühren das Asset heute?
• Wer entfernt einen stillen Treffer?
• Welcher Vorfall ist eigentlich ein fehlender Lebenszyklusentscheid?

Wo Governance hängt

Zwischen Katalogsuche und AI-Gate

Auffindbar heißt nicht freigegeben. Der Crawler liest Existenz, nicht Zweck.

Zwischen Hygiene-Register und KI-Allowlist

Ein verwaistes Asset ohne Entscheidung bleibt im Index, bis die Allowlist das Hygiene-Register verbindlich nutzt.

Zwischen KI-Suche und Training

Eine Freigabe für beantwortete Suche ist kein Trainingsrecht. Beide Entscheidungen gehören an dasselbe Asset, bleiben aber getrennt.

Zwischen selbstbewusster Antwort und altem Auswertungsbestand

Das Modell hat die Zahl nicht frei erfunden. Governance hat eine veraltete Quelle nicht aus dem Kontext gehalten.

Zwischen Shadow-Excel und „offizieller“ Quelle

Stille Kopien werden Treffer. Sie brauchen eine Zeile, bevor sie „helfen“.

Zwischen Plattform-Admin und AI-Zweckfreigabe

Wer den Index betreibt, entscheidet nicht training-ok.

Rollen-Mapping

Zuständige Fachrolle

Die zuständige Fachrolle verantwortet Zweck und Entscheidung, ob das Asset KI berühren darf. Sie entscheidet aber nicht allein den Index-Job.

Hygiene Steward

Führt Disposition und Hygiene-Klasse (Serie Datenhygiene). Hygiene ersetzt nicht die AI-Zweckfreigabe.

AI / Context Steward

Führt Ausschlussregister, Status für KI-Suche und Training sowie Wiedervorlagen. Stewardship braucht dafür echte Kapazität, nicht nur Restzeit nach einem Vorfall.

Technischer Betreiber für Index und Plattform

Setzt Blocks und Allowlists um. Konfigurationsmacht ist keine Zweck-Verantwortung.

AI Product Owner

Priorisiert Corpus-Scope und welche Assets Kandidaten werden. Nutzen und Lieferbarkeit ersetzen aber nicht die Hygiene-Disposition.

Audit / Incident User

Erhält Register, Nachweise und eine klare Einordnung, ob ein Vorfall durch Modellverhalten oder durch fehlende Datenhygiene entstanden ist.

Mini-Fall

Alltagssituation: Eine alte Auswertungstabelle sales_legacy_2019 hat keine zuständige Fachrolle, ist aber im Katalog noch auffindbar. Die KI-Suche nimmt sie auf, weil sie technisch existiert. Danach liefert der Assistent eine überzeugend klingende, aber falsche Zahl.

Was schiefläuft: Im Incident heißt es schnell: „KI hat gelogen.“ Tatsächlich wurde ein veralteter Datenbestand nicht archiviert, ausgeschlossen oder gelöscht. Das Modell hat nicht entschieden, welche Quelle gültig ist; es hat gefunden, was verfügbar war.

Vereinbarung: Alte Assets bekommen Disposition: behalten, archivieren, aus Retrieval ausschließen oder löschen. Für KI-Suche zählen nur Quellen mit Zweck, zuständiger Fachrolle, Aktualität und Freigabe. Der Index zitiert diese Entscheidung, statt alles aufzunehmen, was technisch erreichbar ist.

Kritische Übergabe

Anti-Patterns

• Alles indexieren „für KI“
• Existenz im Katalog als Freigabe lesen
• Retrieval-Allow auf Fine-Tune vererben
• Incident als Modellfehler führen, obwohl Disposition fehlt
• Shadow-Kopien im KI-Pfad ignorieren
• Index-Admin als Zweck-zuständige Fachrolle führen
• Hygiene-Serie umschreiben statt bridgen

Im Alltag betreiben

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Zuständigkeiten, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Datenmüll vor KI
• Lernpfad — Datenmüll vor KI

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Hygiene-Zeilen listen, die den Pilot-Corpus berühren. Heutige RAG- und Trainingspfade markieren. Default blocked setzen. Zuständige Fachrolle und Steward benennen.

Schritt 2: Control und Nachweis umsetzen

Exclusion Register für das Pilot-Corpus schließen. Top-Orphan aus dem Crawl nehmen. Retrieval- vs. Train-Status trennen.

Schritt 3: Testen und Ausnahmen sichtbar machen

Eine Shadow-Kopie im AI-Pfad flaggen oder blocken. Negativtest: Asset ohne Disposition darf nicht ingestiert werden. Prep-Anschluss (Teil 2) vorbereiten.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster auf ein zweites Corpus übertragen.

Exit-Kriterien

• Pilot-Dokumentbestand-Assets haben Hygiene-Klasse und KI-Zweckstatus; leer heißt blocked.
• Orphans, Zombies und illegale Shadows sind für Index und Train gesperrt, bis Disposition da ist.
• Retrieval-ok und training-ok sind getrennte Freigaben.
• Touchpoints sind benannt; stille Treffer werden geräumt oder gewaived.
• Technischer Betreiber setzt den Block; die zuständige Fachrolle bleibt für die Zweckfreigabe verantwortlich.

Weiterlesen

• Datenhygiene
• Löschung die hält
• KI Foundations
• Mails & Dokumente vor KI
• Die 8 Säulen
• Fit for KI

Begriffe vor dem Lesen

• Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, zuständige Fachrolle, Aktualität, Herkunft oder Qualitätsnachweis.
• KI-Suche — Retrieval-Augmented Generation: ein Modell ruft Inhalte zur Laufzeit ab, statt nur aus Training zu antworten.
• Training — Nutzung von Daten, um Modellverhalten oder Features zu lernen.
• Imputation / Schätzung — Ersetzen fehlender Werte durch abgeleitete Annahmen. Das muss sichtbar bleiben.
• KI-Fitness — Eignung eines Assets für Retrieval, Training oder Agentennutzung mit Zweck, Qualität, Rechten und Nachweis.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Verantwortung. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Nachweis: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Eine KI-Suche für Richtlinien, Supporttexte oder interne Wissensdatenbanken entsteht nicht dadurch, dass man Ordner in einen Vektorspeicher kippt. Sie braucht einen kontrollierten Pfad: Inventar, Bereinigung, Zweckfreigabe, Snapshot und nachvollziehbaren Job. Sonst wird der Müll aus Teil 1 zum scheinbar zuverlässigen KI-Kontext.

Nachbarn bleiben für Tiefe führend: Metadaten für AI…, Datenhygiene.

Vorher: Müll-Assets vergiften den AI-Kontext. Weiter: DQ-Gates für AI-Fitness.

Entscheidung

Bevor ein Dokumentbestand eine KI-Suche oder ein Training speist, müssen fünf Entscheidungen getroffen sein:

1. Inventar: Quellen, zuständige Fachrolle, Hygiene-Klasse, Sensitivität und Link zum Ausschlussregister aus Teil 1.
2. Bereinigung: Gesperrte Assets entfernen, Dubletten reduzieren, personenbezogene Daten und Secrets schützen, technische Störungen protokollieren.
3. Zweckfreigabe: KI-Suche und Training getrennt freigeben. Ein Dokument kann für Suche erlaubt und für Training verboten sein.
4. Aufnahme: Nur freigegebene Snapshots verwenden. Der Job muss auf eine Version zeigen, nicht auf einen beliebigen Live-Ordner.
5. Rollen: Die fachlich zuständige Fachrolle entscheidet den Zweck, der Steward pflegt das Vorbereitungspaket, der technische Betreiber setzt Snapshot und Jobbindung um.

Rohfreigaben aus Laufwerken, Partnerordnern oder Exporten sind nie automatisch Produktionskontext. Wenn sich der Zweck ändert, beginnt die Freigabe neu.

Inventory ──► Scrub ──► Purpose Card ──► Snapshot ──► Index / Train-Job
                │              │
                └── blocked ───┴── zurück zur Hygiene-Disposition

Prep-Workflow

1. Dokumentbestand benennen

Die fachlich zuständige Fachrolle vergibt eine Corpus-ID, nennt das KI-Produkt und beschreibt den Zweck. Der Steward übernimmt das Ausschlussregister und markiert gesperrte Quellen. Ohne eindeutige ID wird jeder Share irgendwann „der Corpus“.

2. Bereinigen und protokollieren

Der Steward definiert die Bereinigungsschritte: personenbezogene Daten erkennen, Dubletten reduzieren, Sprache prüfen, sensible Inhalte aussteuern. Der technische Betreiber schreibt Eingangszahlen, Ausgangszahlen und Versionen ins Laufprotokoll. Eine Bereinigung ohne Protokoll ist nur eine Behauptung.

3. Zweck getrennt freigeben

Die fachlich zuständige Fachrolle stellt getrennte Freigaben für KI-Suche und Training aus, inklusive Nicht-Zielen. Datenschutz und Security müssen Trainingsfreigaben sehen, wenn personenbezogene, vertrauliche oder vertraglich begrenzte Inhalte betroffen sind. Dieselbe CSV für Suche und Training ohne zweite Freigabe ist ein vermeidbares Risiko.

4. Snapshot festschreiben

Der technische Betreiber lässt Jobs nur die freigegebene Snapshot-ID lesen. Der Steward verlangt das Metadatenprofil vor der Aufnahme, wie in Metadaten für AI beschrieben. Ein Live-Crawl über nicht freigegebene Pfade bleibt ausgeschlossen.

5. Rebuild auslösen

Die fachlich zuständige Fachrolle legt fest, wann ein Rebuild nötig ist: Quelle stillgelegt, personenbezogene Daten gefunden, Schema gebrochen oder Zweck geändert. Der Steward aktualisiert das Vorbereitungspaket. Stilllegung ohne Rebuild lässt alte Dokumente im Index.

Praktische Übergabe

Anti-Patterns

• Raw-Partnerfreigaben direkt in den Produktion-Index crawlen
• Dedup und personenbezogene Daten-Scrub auf „später“ schieben
• Dieselbe CSV für Chatbot und Dienstleister-Fine-Tune nutzen
• Metadata-Profil auf Papier, Job zieht den Partnerfreigabe
• Quell-Asset stilllegen, ohne Dokumentbestand-Rebuild

Im Alltag betreiben

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für zuständige Fachrolleen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Datenmüll vor KI
• Lernpfad — Datenmüll vor KI

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Corpus-ID, Verantwortung, Steward und Produkt für ein Retrieval-Corpus festlegen.
2. Exclusion Register importieren und blocked Sources markieren.
3. Scrub-Schritte fahren und Run-Log mit Counts speichern.
4. Einen Job so härten, dass er nur die freigegebene Snapshot-ID liest.

Begriffe vor dem Lesen

• Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, zuständige Fachrolle, Aktualität, Herkunft oder Qualitätsnachweis.
• KI-Suche — Retrieval-Augmented Generation: ein Modell ruft Inhalte zur Laufzeit ab, statt nur aus Training zu antworten.
• Training — Nutzung von Daten, um Modellverhalten oder Features zu lernen.
• Imputation / Schätzung — Ersetzen fehlender Werte durch abgeleitete Annahmen. Das muss sichtbar bleiben.
• KI-Fitness — Eignung eines Assets für Retrieval, Training oder Agentennutzung mit Zweck, Qualität, Rechten und Nachweis.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Verantwortung. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Nachweis: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Ein grüner BI-Qualitätsscore macht einen KI-Dokumentbestand nicht automatisch geeignet. Eine Tabelle kann für ein Dashboard ausreichend sein und trotzdem für KI-Suche oder Training ungeeignet bleiben, etwa weil personenbezogene Daten enthalten sind, Dubletten dominieren, ein alter Stand verwendet wird oder Schätzwerte nicht markiert sind.

KI-Fitness ist deshalb zweckgebunden: Was für eine interne beantwortete Suche erlaubt ist, kann für Training verboten sein. Was in einer Sandbox warnen darf, muss in Produktion blockieren.

Lifecycle-Gates stoppen Müll am Asset-Eingang — Müll mit Lifecycle-Gates verhindern. Hier sitzt das Gate am Corpus-Snapshot vor AI-Ingest.

Vorher: Aufräumen vor Retrieve oder Train. Weiter: PII vor AI-Ingestion stoppen.

Entscheidung

Bevor ein Snapshot aus Teil 2 in eine KI-Suche oder ein Training aufgenommen wird:

1. Fitness-Gates auf dem Snapshot: Produktion blockiert bei harten Fehlern, Sandbox darf warnen.
2. Startdimensionen: Hygiene-Entscheidung, Rate personenbezogener Daten oder Secrets, Dubletten, Trainings-Leakage, Unsicherheitslabel, Aktualität, Drift, Metadatenvertrag und ausgeschlossene Zwecke.
3. Jobs lesen den Gate-Status: Ein PDF mit Freigabe reicht nicht, wenn die Pipeline es ignoriert.
4. Ausnahmen laufen ab: Befristete Ausnahme mit Steward- und Datenschutzfreigabe, keine dauerhafte Hintertür.
5. Verantwortung pro Gate: Eine verantwortliche Rolle je Prüfdimension, Steward für Fehlergründe, technischer Betreiber für Sperre. Fitness ist nicht dasselbe wie Model Evaluation — AI Eval.

Gate-Workflow

1. Prüfungen und Verantwortliche mappen

Die zuständige Fachrolle macht jede Dimension messbar. Der Steward setzt Schwellen pro Zweck, zum Beispiel für KI-Suche anders als für Training. Ohne benannte Verantwortung bleibt „fit for AI“ nur eine Folienbehauptung — AI-Eignung ist mehr als ein Score.

2. Jobs an Status binden

Der technische Betreiber lässt Index- und Trainingspipelines nur freigegebene Snapshots lesen. Harte Fehler blockieren Produktion; Sandbox-Läufe werden sichtbar gewarnt. Ein Gate, das der Job ignoriert, ist Dekoration.

3. Fails handlungsfähig machen

Der Steward veröffentlicht Fehlergründe an die verantwortliche Rolle. Es darf keinen stillen Reject geben. Die zuständige Fachrolle entscheidet Korrektur oder befristete Ausnahme. Ein Fehler ohne Begründung erzeugt Schattenwege.

4. Drift an Rebuild hängen

Der Steward verknüpft offene Drift-Signale mit Rebuild-Triggern im Vorbereitungspaket. Hygiene-Signale wie verwaiste Assets oder häufige Gate-Fehler zeigen früh, dass der Dokumentbestand instabil wird — Hygiene Operating Scorecard. Drift Wochen nach Go-Live ohne Trigger ist ein stiller Bruch.

5. Pass und Fail belegen

Der technische Betreiber belegt beides: Ein fehlerhafter Snapshot wurde blockiert, ein bestandener Snapshot wurde mit Nachweis aufgenommen. Nachweise sind Zählwerte, IDs und Prüfergebnisse, keine Rohdaten mit personenbezogenen Informationen. Ohne diesen Gegenbeweis bleibt das Gate unbewiesen.

Practical handover

Anti-Patterns

• Warehouse-Completeness als KI-Freigabe lesen
• Fine-Tune ohne Leakage-Check gegen Eval-Sets
• Gates als PDF pflegen, Jobs den Snapshot trotzdem ziehen
• Dauerwaivers statt befristeter Sign-offs
• Fitness mit Model-Eval verwechseln

Im Alltag betreiben

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für zuständige Fachrolleen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Datenmüll vor KI
• Lernpfad — Datenmüll vor KI

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Starter-Gates auf messbare Checks und Verantwortung mappen; Schwellen je Zweck setzen.
2. Prod-Ingest bei Hard Fail blocken; Warn in der Sandbox loggen.
3. Fail-Reasons an Stewards publizieren.
4. Ein failed Snapshot blocken und ein passed Snapshot mit Nachweis ingesten.

Begriffe vor dem Lesen

• Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, zuständige Fachrolle, Aktualität, Herkunft oder Qualitätsnachweis.
• KI-Suche — Retrieval-Augmented Generation: ein Modell ruft Inhalte zur Laufzeit ab, statt nur aus Training zu antworten.
• Datenschutz-Folgenabschätzung / DSFA — Prüfung für Verarbeitungen, die ein hohes Risiko für betroffene Personen haben können.
• Training — Nutzung von Daten, um Modellverhalten oder Features zu lernen.
• Imputation / Schätzung — Ersetzen fehlender Werte durch abgeleitete Annahmen. Das muss sichtbar bleiben.
• KI-Fitness — Eignung eines Assets für Retrieval, Training oder Agentennutzung mit Zweck, Qualität, Rechten und Nachweis.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Verantwortung. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Nachweis: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Personenbezogene Daten aus HR-Exports, Supporttickets oder E-Mails dürfen nicht beiläufig in Embeddings, Prompt-Caches, Trainingsdaten oder Dienstleister-Uploads wandern. Prävention vor der Aufnahme ist einfacher, billiger und ehrlicher als nachträgliche Bereinigung in Teil 5.

Privacy-Pillars bleiben normativ: PII & Privacy Governance, DSDR Governance. Dieser Teil ist die präventive Betriebskontrolle auf dem Prep-Pfad.

Vorher: DQ-Gates für AI-Fitness. Weiter: Machine Unlearning und AI-Remediation.

Entscheidung

Bevor ein Pfad KI-Suche oder Training speist:

1. Vor dem Verschieben klassifizieren: Keine Quelle ohne Sensitivität und rechtmäßigen KI-Zweck.
2. Scannen und schützen: Personenbezogene Daten und Secrets im Bereinigungsschritt erkennen, maskieren oder entfernen; Trefferquoten dokumentieren.
3. Speicher trennen: Produktionsindexe und Trainings-Snapshots teilen keine unkontrollierten Rohablagen.
4. Dienstleister und Notebooks einbeziehen: Uploads und lokale Exporte brauchen dieselbe Zweckfreigabe und Scan-Nachweise.
5. Nebenkopien listen: Caches, Evaluationssets, Logs und Embedding-Metadaten müssen bekannt sein. Refresh und Restore lösen Re-Scan aus.
6. Rollen klären: Fachliche Verantwortung für Zweck, Steward für Kontrollkarte, Datenschutz für Sign-off, technischer Betreiber für Sperre.

KI-Suche mit minimierten Feldern ist nicht dasselbe wie Training auf vollständiger Gesprächshistorie. Training mit Personenbezug ist ein eigener Prüf- und Freigabefall, kein Crawl-Default.

Präventions-Workflow

1. Pfade mappen

Der Steward listet Crawl, Export, Feature-Job, Dienstleister und Notebook. Die fachlich zuständige Fachrolle setzt Sensitivität und KI-Zweck vor der Aktivierung. Ein nicht gemappter PoC-Upload ist eine blinde Stelle für Auskunft und Löschung.

2. Scrub mit Nachweis

Der technische Betreiber fährt Personen- und Secret-Scans im Bereinigungsschritt und speichert nur aggregierte Trefferquoten. Der Steward lässt das Gate aus Teil 3 fehlschlagen, wenn die Schwelle verletzt wird. Ein einmaliger Regex-Lauf ohne Protokoll hält Namen weiter in Chunks und Metadaten.

3. Vendor und Notebook blocken

Datenschutz und fachliche Verantwortung geben Uploads nur mit Zweckfreigabe und Scan-Nachweis frei. Der technische Betreiber blockiert unkontrollierte Dienstleisterpfade. „Nur für einen PoC“ außerhalb des Umfangs ist eine zweite Kopie ohne saubere Auskunfts- und Löschfähigkeit.

4. Nebenkopien inventarisieren

Der Steward listet Caches, Evaluationssets und Log-Aufbewahrung wie andere Nebenkopien — Nonprod, Exports…. Der technische Betreiber hängt Quell-Refreshs an einen Re-Scan des Dokumentbestands. Wer Caches auslässt, erzählt bei Auskunft und Löschung nur die halbe Wahrheit.

5. Dirty Ingest belegen

Der technische Betreiber belegt, dass ein unsauberer Ingest mit klarem Fehlergrund gestoppt wurde. Die fachlich zuständige Fachrolle hängt die Kontrollkarte an das DSDR-Runbook, damit klar ist, was bei einem Scheitern gelöscht oder neu aufgebaut werden muss. Ohne diesen Beweis bleibt das Gate Folie.

Praktische Übergabe

Anti-Patterns

• personenbezogene Daten „kurz“ in Prompt oder Dokumentbestand lassen
• Dienstleister-Fine-Tune mit Raw-CSV außerhalb Auskunfts- und Löschrechte-Umfang
• Feature Store und Notebook am Warehouse-Masking vorbeiführen
• Eval-Sets mit subjektbezogenen Texten behalten
• Nicht-Produktion-Refresh ohne Re-Scan nach Scrub

Im Alltag betreiben

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für zuständige Fachrolleen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Datenmüll vor KI
• Lernpfad — Datenmüll vor KI

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Jeden Ingest-Pfad (Crawl, Export, Vendor, Notebook) mappen.
2. Sensitivität und AI-Zweck vor Path-Enablement verlangen.
3. PII-Scan im Scrub fahren; nur aggregierte Nachweis speichern.
4. Einen unmanaged Path blocken und den Fail-Reason loggen.

Tools und Quellen

Begriffe vor dem Lesen

• Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, zuständige Fachrolle, Aktualität, Herkunft oder Qualitätsnachweis.
• KI-Suche — Retrieval-Augmented Generation: ein Modell ruft Inhalte zur Laufzeit ab, statt nur aus Training zu antworten.
• Training — Nutzung von Daten, um Modellverhalten oder Features zu lernen.
• Imputation / Schätzung — Ersetzen fehlender Werte durch abgeleitete Annahmen. Das muss sichtbar bleiben.
• KI-Fitness — Eignung eines Assets für Retrieval, Training oder Agentennutzung mit Zweck, Qualität, Rechten und Nachweis.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Verantwortung. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Nachweis: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Prävention ist gescheitert: sensible, falsche oder veraltete Daten haben bereits KI-Suche, Caches, Trainingsdaten, Dienstleisterkopien oder Modellartefakte erreicht. Eine Warehouse-Zeile zu löschen reicht dann nicht mehr. Dieser Teil ist das Incident-Playbook: Umfang klären, weitere Nutzung stoppen, passende Bereinigung je Speicherort wählen und nachweisen, was getan wurde. Er verspricht ausdrücklich nicht, dass ein Sprachmodell mit mathematischer Sicherheit „vergisst“.

Diese Serie endet hier. Nachbarn behalten ihre Tiefe: Löschung die hält, Lösch-Nachweis…, AI Governance, DSDR Governance, Pfad Deletion Ops.

Ausgangspunkt

Teams behandeln AI-Incidents oft wie einfache BI-Löschungen:

• Quelltabelle löschen und Ticket schließen;
• Chunks, Prompt-Caches und Evaluationssets unberührt lassen;
• Fine-Tune-Checkpoints und Dienstleisterkopien bleiben online;
• „wir unlearnen“ behaupten, ohne Methode, Umfang oder Prüfung zu benennen;
• Wiederauftreten nach Restore oder Re-Crawl nicht kontrollieren.

Zwei Gedächtnisarten kollidieren:

Signatur falscher Schließung:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Quelle:     Subject-Zeile in CRM + Warehouse gelöscht
Index:      120 Chunks weiter retrievebar
Cache:      Prompt-Store-Hits 14 Tage
Checkpoint: ft-customer-notes-v3 weiter served
Vendor:     Upload laut Vertrag „90 Tage“ behalten
Ticket:     closed — „AI informiert“

Ticket zu schließen, während Chunks, Cache und Fine-Tune-Checkpoint weiter antworten, ist keine Remediation — „Unlearning“ ohne Scope und Verify bleibt eine Behauptung.

Entscheidung

Führe jeden AI-Datenvorfall als Umfang klären → Eindämmen → Bereinigen → Nachweisen → Wiederauftreten verhindern. Für jede Speicherklasse muss klar sein, was betroffen ist und welche Bereinigung gilt.

1. Umfangsmatrix als erstes Pflichtartefakt

Baue eine Umfangsmatrix, bevor ungezielt aus Indizes und Caches gelöscht wird:

Regeln: leere „unknown“-Zeilen sind offene Risiken, nicht optional. Shadow- und Nonprod-Kopien zählen — Nonprod, Exports…. Verknüpfen Sie Subject- oder Müll-Asset-IDs wo möglich mit Chunk-/Document-IDs.

2. Contain

Bis Remediation fertig ist:

• Serving auf last-known-clean Model-/Index-Version disable oder pinnen;
• Crawls und Fine-Tune-Jobs pausieren, die die schlechte Quelle neu ingestieren;
• Dienstleister-Zugriff widerrufen oder weitere Uploads einfrieren;
• Prompt-Cache-Reads einschränken, die Content resurfacen können;
• Datenschutz und die zuständige Stelle für Auskunfts- oder Löschrechte benachrichtigen, wenn personenbezogene Daten betroffen sind.

Containment ist nicht Remediation. Es stoppt den Blast-Radius.

3. Remediate nach Klasse (Entscheidungstabelle)

Wähle einen Primärpfad je kontaminierter Klasse. Mischen nur mit dokumentierter Begründung.

Machine Unlearning heißt hier: Techniken, die den Einfluss bestimmter Trainingspunkte auf parametrische Modelle (manchmal auch Influence-Scores) entfernen oder reduzieren sollen. Enterprise-Einsatz bleibt approximativ. Jeden Unlearning-Lauf koppeln mit:

• dokumentierter Methode und Parametern;
• Membership-/Influence-ähnlichen Checks wo machbar;
• Fallback-Plan (Retrain), wenn Verify scheitert;
• ehrlicher Sprache in Nachweis: versuchter parametrischer Remediation, nicht zertifizierte Weight-Erasure.

Für DSDR zählen Prozess, Scope-Abdeckung und Restrisiko — Spiegel zu Lösch-Nachweis und Recurrence-Controls. Erfinden Sie keine Garantie, die die Wissenschaft nicht hergibt.

4. Nachweispaket für AI

Erweitere den Lösch-Nachweis um AI-Felder:

• Contamination Umfang Matrix (versioniert);
• Containment-Aktionen und Zeitstempel;
• Remediation-Wahl je Klasse (Tabelle oben);
• Index-Rebuild-Job-IDs, Document/Chunk-Delete-Counts, Hash des clean Snapshots;
• Model/Adapter-Registry: alte Version retired, neue live;
• Dienstleister-Delete-Request-ID und Confirmation;
• Verify: Retrieval-Tests auf Subject-/Müll-Marker; Sample-Prompts die zuvor trafen; parametrische Checks falls behauptet;
• Restrisiko-Statement (was nicht bewiesen werden konnte);
• Recurrence-Kontrollregeln: Re-Crawl-Block, Prüfpunkt-Re-Enable, Restore→Re-Delete für KI-Stores.

Referenzen und Aggregate speichern — keinen zweiten PII-Lake im Ticket-System.

5. Recurrence

Events verdrahten, die Kontamination wieder einführen:

• Source-Restore / Nicht-Produktion-Refresh → KI-Umfang re-verifizieren;
• Dokumentbestand-Rebuild ohne Part-3-Gates → Incident reopen;
• versehentliches Re-Enable retired Checkpoint → Change-Kontrollregel-Fail;
• Dienstleister-Re-Upload alter Datei → Path-Kontrollregel-Fail (Teil 4).

KPIs (Starter): Scope-Completeness, Time-to-Contain, Residual-Retrieval-Hit-Rate nach Purge, Retired-Checkpoint-Re-Serve-Rate, Vendor-Confirm-Latenz.

Checkliste

Führe das Playbook an einem Pilot-Incident (Tabletop oder real):

• Umfang-Matrix öffnen; jede Klasse in/out mit verantwortlicher Person markieren;
• Serving und Ingest innerhalb vereinbarter SLA containen;
• Remediation je Klasse über Entscheidungstabelle wählen;
• Index-Rebuild und/oder Model-Pfad ausführen; IDs festhalten;
• KI-Nachweispaket vervollständigen; Restrisiko explizit;
• Recurrence-Checks nach Restore/Refresh planen;
• Lessons in Teile 2–4 Gates und Hygiene-Register speisen;
• stoppen, wenn „done“ Pack + Verify heißt, nicht eine Chat-Nachricht.

Arbeitsartefakt

AI Remediation Case File:

1. AI Contamination Scope Matrix;
2. Containment-Log;
3. Remediation Decision Record (je Klasse);
4. Nachweispaket (AI-erweitert);
5. Restrisiko und Recurrence-Plan;
6. Links zu DSDR-Case / Hygiene-Disposition / Prep-Pack-Versionen.

Betriebsnotizen

• Index-Delete ≠ Modell-Vergessen. In jedem Status-Update sagen.
• Unlearning ohne Verify bleibt Behauptung. Bei hohem Risiko oder Regulierung Retrain bevorzugen.
• Müll-Incidents brauchen dieselbe Umfang-Disziplin; Remediation ist oft Rebuild + Prüfpunkt-Fix, nicht parametrisches Unlearning.
• Verantwortung: AI Product Owner, Steward, Datenschutz bei personenbezogenen Daten und Plattform für Index/Registry — Entscheidungsrechte, kein Crowd-Chat.
• Tiefe zu Plattform-Löschung und Backups bleibt in der Deletion-Serie; dieses Playbook ergänzt nur KI-Gedächtnisklassen.

Tools

Model Registry und Vector-Admin für Version-Pin und Purge. PII/DSDR-Tooling für Subject-IDs. Observability für Prompt-Traces. Katalog für Corpus und Sensitivität. Architecture Fit bei Multi-Vendor-Pfaden. Lernen: Deletion Ops, PII in 5 Schritten, AI Foundations.

Ressourcen

Teile 1–4 von Datenmüll vor AI. AI Governance, AI Failures, Lösch-Nachweis…, Backups, Snapshots…, GDPR für Analytics- und AI-Teams. Glossary: Machine Unlearning.

Tools und Quellen

Begriffe vor dem Lesen

• Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, verantwortliche Person, Aktualität, Herkunft oder Qualitätsnachweis.
• KI-Suche — Retrieval-Augmented Generation: ein Modell ruft Inhalte zur Laufzeit ab, statt nur aus Training zu antworten.
• Training — Nutzung von Daten, um Modellverhalten oder Features zu lernen.
• Imputation / Schätzung — Ersetzen fehlender Werte durch abgeleitete Annahmen. Das muss sichtbar bleiben.
• KI-Fitness — Eignung eines Assets für Retrieval, Training oder Agentennutzung mit Zweck, Qualität, Rechten und Nachweis.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

KI startet nicht bei Intelligenz — sondern mit Daten

KI übernimmt Annahmen aus CRM, Tickets und Excel genauso bereitwillig wie Fakten. Wer unklare Schätzwerte, Default-Nullen und veraltete Statuswerte in den Kontext mischt, bekommt selbstbewusste Antworten auf kaputte Grundlagen.

Unternehmen verbinden KI inzwischen mit fast allen Bereichen ihrer Datenlandschaft:

• Data Warehouses und Lakehouses
• Dokumenten und Wissensdatenbanken
• CRM-, ERP- und Ticketsystemen
• operativen Anwendungen und APIs
• Reports, Kennzahlen und semantischen Modellen
• E-Mails, Verträgen und Supporthistorien

Die zugrunde liegenden Daten sind nur selten eine direkte Abbildung der Realität.

Sie wurden meistens bereits:

• korrigiert
• standardisiert
• zusammengeführt
• gefiltert
• angereichert
• gemappt
• aggregiert
• imputiert
• geschätzt

Die meisten dieser Transformationen sind notwendig. Eine Datenplattform muss Formate harmonisieren, Systeme integrieren und Informationen für einen bestimmten Zweck aufbereiten.

Das Risiko beginnt dort, wo das Ergebnis vollständig und präzise aussieht, während seine Unsicherheit verschwunden ist.

Ein fehlender Wert ist sichtbar unbekannt. Ein geschätzter Wert kann sinnvoll sein, solange er eindeutig als Schätzung gekennzeichnet bleibt. Wird eine Schätzung jedoch wie eine beobachtete Tatsache gespeichert, kopiert und präsentiert, behandeln nachgelagerte Konsumenten eine Annahme möglicherweise als Wahrheit.

KI kann dieses Problem verstärken.

KI kann ableiten, was möglicherweise fehlt. Sie kann nicht wissen, ob diese Ableitung wahr ist.

Unternehmensdaten gelangen auf unterschiedlichen Wegen in KI

„Die KI wird mit Unternehmensdaten trainiert“ wird häufig als Sammelbegriff verwendet. Technisch existieren jedoch mehrere unterschiedliche Muster.

Modelltraining

Ein Modell wird mit Daten trainiert, um Muster zu erkennen und Vorhersagen zu erzeugen. Datenfehler, fehlende Abdeckung und versteckte Annahmen können das erlernte Verhalten direkt beeinflussen.

Fine-Tuning und Feature Engineering

Ein vorhandenes Modell wird mit unternehmensspezifischen Beispielen angepasst oder strukturierte Features werden für ein Machine-Learning-Modell erstellt. Qualität und Repräsentativität dieser Eingaben prägen die späteren Vorhersagen.

Retrieval-Augmented Generation

Ein Sprachmodell ruft Dokumente, Datensätze oder Wissensfragmente zur Laufzeit ab. Das Basismodell wird dabei nicht neu trainiert. Unvollständige, veraltete oder widersprüchliche Unternehmensinhalte können trotzdem zu irreführenden Antworten führen.

Agenten, Analytics und Entscheidungsunterstützung

KI-Systeme fragen Datenbanken ab, rufen APIs auf, interpretieren KPIs oder empfehlen Aktionen. Das Modell kann technisch funktionieren, während die zugrunde liegenden Geschäftsdaten, Definitionen oder Zugriffswege schwach bleiben.

Der Mechanismus unterscheidet sich. Das Governance-Prinzip bleibt gleich:

Qualität, Bedeutung und Herkunft der Eingaben begrenzen die Vertrauenswürdigkeit der Ausgaben.

Die gefährliche Umwandlung: unbekannt → geschätzt → Fakt

Datenpipelines müssen Lücken häufig schließen, damit Reports, Prozesse oder Modelle weiterarbeiten können.

Eine typische Kette sieht so aus:

1. Ein Pflichtwert fehlt in der Quelle.
2. Eine Transformation setzt einen Standard-, Mapping- oder Schätzwert ein.
3. Der korrigierte Datensatz wird in eine kuratierte Tabelle übernommen.
4. Die Kennzeichnung der Schätzung wird entfernt oder nie angelegt.
5. Der Wert wird in Features, Kennzahlen, Retrieval oder Modelleingaben weiterverwendet.
6. Die KI liefert eine Antwort, ohne sichtbar zu machen, dass ein Teil ihrer Grundlage nur abgeleitet wurde.

Der Downstream-Datensatz kann technisch vollständiger sein. Er ist dadurch nicht automatisch genauer.

Diese Unterscheidung ist entscheidend:

• Beobachtet bedeutet, dass der Wert aus einem Ereignis oder autoritativen System übernommen wurde.
• Korrigiert bedeutet, dass ein bekannter Fehler nach einer definierten Regel repariert wurde.
• Abgeleitet bedeutet, dass der Wert aus anderen Informationen berechnet wurde.
• Geschätzt oder imputiert bedeutet, dass der Wert wegen fehlender Informationen erschlossen wurde.
• Synthetisch bedeutet, dass der Wert generiert und nicht beobachtet wurde.
• Unbekannt bedeutet, dass keine verlässliche Evidenz vorhanden ist.

Diese Zustände dürfen nicht unbemerkt zu einem generischen „bereinigten“ Wert zusammenfallen.

Datenqualitätsprobleme werden auf unterschiedliche Weise zu KI-Problemen

Nicht jede Lücke muss gefüllt werden. Manchmal ist der genaueste Wert weiterhin unbekannt.

Für KI kann es sicherer sein, diese Unsicherheit zu erhalten, als künstliche Vollständigkeit zu erzeugen.

Halluzination ist ein zusätzliches Risiko — kein anderes Wort für schlechte Daten

Schlechte Datenqualität und Halluzinationen hängen zusammen, sind aber nicht dasselbe Problem.

Schwacher, widersprüchlicher oder unvollständiger Kontext kann die Wahrscheinlichkeit einer unbelegten oder irreführenden Antwort erhöhen. Ein generatives Modell kann jedoch auch dann falsche oder erfundene Inhalte erzeugen, wenn die verfügbaren Daten korrekt sind.

Mögliche Ursachen sind:

• der probabilistische Generierungsprozess
• mehrdeutige Anweisungen
• Abruf des falschen Kontextes
• fehlender oder abgeschnittener Kontext
• widersprüchliche Quellen
• schwaches Grounding
• ungeeignetes Modellverhalten für die Aufgabe
• fehlende Evaluation und Ausgabekontrollen

Bessere Daten sind deshalb notwendig, aber nicht ausreichend.

Eine saubere Tabelle macht aus einem Sprachmodell keine Datenbank. Eine dokumentierte Wissensbasis garantiert nicht, dass jede generierte Antwort auf ihr basiert. Retrieval-Augmented Generation kann bestimmte Risiken reduzieren, beseitigt unbelegte Generierung aber nicht vollständig.

Die Gefahr besteht häufig nicht darin, dass eine Antwort offensichtlich falsch aussieht.

Sie besteht darin, dass sie schlüssig, flüssig und überzeugend klingt.

Plausibilität ist kein Beleg. Selbstsicherheit ist keine Korrektheit.

Eine governed KI-Anwendung benötigt deshalb Kontrollen für beides:

1. Qualität und Herkunft ihrer Daten und
2. Zuverlässigkeit und erlaubte Nutzung ihrer erzeugten Ausgabe.

Schätzwerte sind kein Trash — unsichtbare Schätzwerte sind das Risiko

Geschäftsdaten werden nie vollkommen vollständig sein.

Forecasts, Allokationen, Imputationen und Näherungswerte sind legitime Bestandteile vieler Prozesse. Ein Planungsmodell ohne Schätzwerte wäre häufig nicht nutzbar. Historische Datensätze können selbst nach Verbesserung des Quellprozesses unvollständig bleiben.

Das Ziel besteht daher nicht darin, geschätzte Werte zu verbieten.

Ihr Status muss steuerbar bleiben.

Ein geschätzter oder imputierter Wert sollte mindestens folgende Metadaten besitzen:

Damit wird eine zentrale Unterscheidung möglich:

Eine governed Schätzung ist eine explizite fachliche Annahme. Eine ungekennzeichnete Schätzung wird zum versteckten Fakt.

Governance muss die vollständige KI-Kette abdecken

AI Governance darf nicht erst beim Modell beginnen.

Der vollständige Weg benötigt Kontrolle.

1. Governance von Quelle und Entstehungsprozess

Die Organisation muss wissen:

• welcher Prozess die Daten erzeugt
• welches System autoritativ ist
• wer die Quelle verantwortet
• welche Felder verpflichtend sind
• welche Fehler wiederholt auftreten
• welche Probleme am Entstehungsort behoben werden können

Eine Downstream-Korrektur kann den Betrieb vorübergehend schützen. Sie darf die ursprüngliche Ursache nicht unsichtbar machen.

Das passende Playbook The Missing Pieces – Part 1: Data Quality beschreibt den notwendigen Feedback Loop von Erkennung und Eindämmung über die Ursachenbehebung bis zur Validierung und zum kontrollierten Rückbau temporärer Workarounds.

2. Data-Product-Governance

Bevor Daten für KI freigegeben werden, müssen Teams Folgendes kennen:

• Verwendungszweck
• kritische Qualitätsdimensionen
• Qualitätsregeln und Schwellenwerte
• Anforderungen an Aktualität
• bekannte Einschränkungen
• fehlende Abdeckung
• Schätz- und Imputationslogik
• Zertifizierungsstatus
• Owner, Steward und technischer Betreiber
• Lineage und Version

Das umfassendere Betriebsmodell beschreibt Data Quality Governance: Qualität muss mit Verwendungszweck, messbaren Regeln, Verantwortung, Monitoring und kontinuierlicher Verbesserung verbunden werden.

3. Modell- und Retrieval-Governance

Die KI-Schicht benötigt eigene Kontrollen:

• Modell- und Konfigurationsversion
• Version der Trainings-, Fine-Tuning- oder Evaluationsdaten
• Retrieval-Quellen und Ranking-Logik
• Version von Prompt und Systemanweisung
• erlaubte und verbotene Anwendungsfälle
• Evaluationsszenarien
• bekannte Einschränkungen
• Ausgabeschwellen und Fallback-Verhalten
• Änderungs- und Releasehistorie

Ein Modellupdate, eine neue Embedding-Version, ein veränderter Suchindex oder eine Prompt-Anpassung kann das Verhalten verändern, obwohl die zugrunde liegenden Geschäftsdaten gleich geblieben sind.

4. Anwendungs- und Output-Governance

Die konsumierende Anwendung sollte festlegen:

• wann Quellnachweise angezeigt werden müssen
• wann das System eine Antwort ablehnen muss
• wann eine menschliche Prüfung verpflichtend ist
• welche Entscheidungen niemals automatisiert werden dürfen
• wie Nutzerfeedback erfasst wird
• wie schädliche oder falsche Ausgaben eskaliert werden
• welche Prompts, Quellen und Ergebnisse protokolliert werden
• wie personenbezogene und vertrauliche Daten geschützt werden

Die Frage lautet nicht nur, ob das Modell eine Antwort erzeugen kann.

Sie lautet, ob die Anwendung nachweisen kann, warum diese Antwort für diesen Zweck verwendet werden darf.

Ein praktisches Minimum vor der Verbindung von KI und Unternehmensdaten

Die Entscheidung vor dem Modell definieren

Klären:

• Welche Entscheidung oder Aktion soll die Ausgabe unterstützen?
• Wer bleibt verantwortlich?
• Welche Auswirkung haben ein False Positive, False Negative oder eine erfundene Antwort?
• Ist die Aufgabe informierend, beratend oder autonom?

Den Evidenzweg inventarisieren

Dokumentieren:

• Quellsysteme
• Transformationen
• fachliche Definitionen
• Schätzungen und Korrekturen
• Retrieval-Indizes
• Modell- und Prompt-Versionen
• konsumierende Anwendungen

Unsicherheit erhalten

Null-Indikatoren, Schätzkennzeichen, Ausnahmezustände oder Qualitätswarnungen dürfen nicht nur deshalb entfernt werden, weil die Eingabe dadurch einfacher zu verarbeiten ist.

Fakt und Annahme trennen

Soweit möglich, getrennte Felder oder Metadaten bereitstellen für:

• tatsächlichen Wert
• geschätzten Wert
• Schätzmethode
• Quellzeitpunkt
• Qualitätsstatus

Reale Fehlerszenarien testen

Die Evaluation sollte nicht nur ideale Beispiele enthalten:

• unvollständige Datensätze
• widersprüchliche Quellen
• veraltete Dokumente
• ungewöhnliche Kategorien
• Grenzfälle
• fehlende Evidenz
• angreifende oder mehrdeutige Prompts
• Fälle, in denen Nicht-Antworten das korrekte Verhalten ist

Nachvollziehbare Ausgaben verlangen

Bei faktenbasierten Unternehmensantworten sollte die Anwendung die relevante Quelle, den Datensatz, das Dokument oder die Kennzahlendefinition sichtbar machen können.

Ablehnung und Eskalation definieren

Ein vertrauenswürdiges System benötigt einen kontrollierten Weg zu Aussagen wie:

• unzureichende Evidenz
• Widerspruch zwischen Quellen
• Daten nicht aktuell
• Qualitätsschwelle unterschritten
• menschliche Prüfung erforderlich

Nach dem Release überwachen

Beobachten:

• Anteil belegter Antworten
• unbelegte Aussagen
• Retrieval-Fehler
• Verletzungen von Qualitätsregeln
• Nutzerkorrekturen
• wiederkehrende Fehlermuster
• Veränderungen nach Modell-, Prompt- oder Datenupdates

Was vermieden werden sollte

Eine kuratierte Tabelle als verifizierte Wahrheit behandeln

Eine Gold- oder Business-Schicht kann technisch sauber sein und trotzdem Schätzungen, geerbte Verzerrungen oder ungelöste Quellfehler enthalten.

Unsicherheit bei der Aufbereitung entfernen

Wer Schätzkennzeichen, Qualitätsstatus oder Quellreferenzen entfernt, macht Daten leichter konsumierbar, aber schwerer vertrauenswürdig.

Annehmen, dass RAG Halluzinationen beseitigt

Retrieval liefert Kontext. Das Modell kann weiterhin falschen Kontext auswählen, ihn ignorieren, fehlerhaft kombinieren oder über die vorhandene Evidenz hinaus generieren.

KI Quelldaten ohne Auditierbarkeit reparieren lassen

KI-gestützte Korrektur kann sinnvoll sein. Jede Änderung benötigt jedoch Nachvollziehbarkeit, Review-Regeln und eine klare Trennung von beobachteten Werten.

Nur durchschnittliche Performance messen

Ein hoher Durchschnitt kann schwere Fehler in seltenen, kritischen oder schwach repräsentierten Szenarien verdecken.

Für jeden Anwendungsfall dieselben Kontrollen verwenden

Ein Assistent für Textentwürfe und eine autonome Zahlungsentscheidung benötigen nicht dieselbe Evidenz, Prüfung und Governance.

Flüssige Sprache als Beweis interpretieren

Die Qualität der Formulierung sagt wenig über die Qualität der zugrunde liegenden Evidenz aus.

Die eigentliche Bedeutung von Trash In, Trash Out

„Trash In, Trash Out“ sollte nicht als Aussage verstanden werden, dass jeder unvollkommene Datensatz unbrauchbar ist.

Es ist eine Warnung vor Skalierung.

KI kann mehr Daten verarbeiten, mehr Signale verbinden und mehr Ausgaben erzeugen, als ein menschliches Team manuell bewältigen könnte. Das schafft Mehrwert. Es bedeutet zugleich, dass ungelöste Fehler, versteckte Annahmen und fehlender Kontext schneller vervielfältigt und überzeugender präsentiert werden können.

Governance verändert das Ergebnis, indem die Kette sichtbar bleibt:

• Quellqualität wird gemessen
• Lücken bleiben erkennbar
• Schätzwerte bleiben Schätzwerte
• Transformationen bleiben nachvollziehbar
• Verantwortung ist eindeutig
• Modelle werden für ihren vorgesehenen Zweck evaluiert
• Ausgaben zeigen Evidenz und Einschränkungen
• Fehler gelangen zurück zum Source-, Data-Product-, Modell- oder Application-Verantwortung

Das Ziel sind weder perfekte Daten noch risikofreie KI.

Das Ziel ist ein System, das zwischen Fakt, Ableitung, Schätzung und Unsicherheit unterscheiden kann.

Bessere Modelle ersetzen keine besseren Quellen.
Bessere Aufbereitung ersetzt keine Transparenz.
Bessere Antworten ersetzen keine Evidenz.

Verwandte Playbooks

• The Missing Pieces – Part 1: Data Quality — warum Downstream-Korrekturen einen Feedback Loop zur Quelle benötigen
• Data Quality Governance — das Betriebsmodell für zweckbezogene Qualität, Regeln, Verantwortung, Monitoring und Verbesserung
• Data Verantwortung & Stewardship — Data Owner, Steward, technischer Betreiber (nicht „Technischer verantwortliche Person“)
• Datenmüll vor KI — Hygiene-Schuld, Dokumentbestand-Prep, Fitness-Gates und Remediation wenn Müll oder personenbezogene Daten den KI-Kontext erreichen
• Machine Unlearning und KI-Remediation — Incident-Playbook wenn Kontamination schon in Indexen oder Modellen liegt

Weiterführende Ressourcen

• NIST KI Risk Management Framework
• NIST KI 600-1: Generative Artificial Intelligence Profile
• NIST KI RMF Playbook
• Datasheets for Datasets
• Model Cards for Model Reporting