Die schleichende Gewalt schlechter Daten

Die schleichende Gewalt schlechter Daten

Die Tabellenkalkulation hat nicht geschrien

Die Tabellenkalkulation sah nicht gefährlich aus. So beginnt es fast immer. Sie lag in einem gemeinsamen Ordner mit einem vernünftigen Namen, drei ausgeblendeten Spalten, zwei Datumsformaten, einem Kommentarfeld, das zu einem kleinen Roman geworden war, und einem Tab namens final, der auf die traditionelle Weise log. Ein Team nutzte sie, um Kundendatensätze abzugleichen, bevor ein neuer Workflow damit gefüttert wurde. Niemand war leichtsinnig. Man prüfte die Summen. Man entfernte offensichtliche Duplikate. Man fragte die Person, die die Datei von der Person geerbt hatte, die die Datei geerbt hatte. Die Antworten waren plausibel genug, um weiterzumachen.

Drei Monate später trat der Schaden auf, aber nicht als ein einzelnes Ereignis. Ein Kunde wurde um Dokumente gebeten, die er bereits vorgelegt hatte. Ein anderer wurde zur falschen Service-Warteschlange geleitet. Ein Risikohinweis erschien bei einem Fall, weil ein geschlossenes Konto noch aktiv aussah. Ein Support-Mitarbeiter verbrachte zwanzig Minuten damit, sich für ein System zu entschuldigen, das auf einer alten Adresse beharrte. Ein Manager sah einen leicht besseren Durchsatz und ein leicht schlechteres Vertrauen. Keiner dieser Vorfälle wirkte groß genug, um das Programm zu stoppen. Zusammen waren sie das Programm.

Schlechte Daten werden oft als technische Unannehmlichkeit beschrieben. Fehlende Felder, inkonsistente Codes, doppelte Zeilen, veraltete Datensätze, schwache Beschriftungen. Diese Sprache ist korrekt und zu klein. Schlechte Daten werden zu langsamer Gewalt, wenn kleine Fehler stillschweigend Kosten auf Menschen übertragen, die sie nicht verursacht haben. Sie zwingen Bürger dazu, zu beweisen, was die Institution vergessen hat. Sie zwingen Mitarbeiter dazu, zu reparieren, was die Pipeline verzerrt hat. Sie zwingen Kunden dazu, sich zu wiederholen. Sie zwingen Prüfer dazu, Bedeutung zu rekonstruieren, nachdem Bedeutung weggeworfen wurde. Sie lassen Modelle unsicher, voreingenommen oder töricht erscheinen, wenn sie teilweise ein Aufzeichnungsversagen widerspiegeln.

Die Gewalt ist langsam, weil der Schaden verteilt ist. Keine einzelne Zeile übernimmt Verantwortung. Kein einzelnes Dashboard räumt die Schuld ein. Das System funktioniert weiter und wirkt daher aus ausreichender Entfernung erfolgreich. Der Schaden lebt in zusätzlichen Anrufen, abgelehnten Anträgen, falschen Briefen, verweigertem Zugang, frustrierten Mitarbeitern, beschädigtem Ruf und Entscheidungen, die schwerer anzufechten sind, weil der Datensatz gelernt hat, offiziell zu klingen. Schlechte Daten brauchen kein Drama. Sie haben Geduld.

Qualität ist nicht Sauberkeit

Datenqualität wird oft auf Sauberkeit reduziert, als wäre das Ziel eine Tabelle ohne sichtbare Krümel. Sauberkeit hilft. Standardformate, gültige Werte, vollständige Felder, deduplizierte Zeilen und sinnvolle Bereiche sind notwendig. Aber ein sauberer Datensatz kann trotzdem falsch für die Aufgabe sein. Ein Feld kann perfekt formatiert und semantisch kaputt sein. Ein Datum kann gültig und veraltet sein. Ein Label kann konsistent und unfair sein. Ein Datensatz kann vollständig sein, weil jemand unbekannt mit nein ausgefüllt hat, so ziehen viele kleine Katastrophen eine Krawatte an.

Qualität ist Eignung für einen Zweck mit Belegen. Derselbe Datensatz kann gut genug für den Versand eines Newsletters sein, unzureichend für eine Kreditentscheidung, gefährlich für ein medizinisches Triage-Modell und irrelevant für eine Evaluation öffentlicher Politik. Der Kontext entscheidet. Wer den Datensatz erstellt hat. Nach welcher Regel. Für welche Aufgabe. Mit welcher Messmethode. Wie oft aktualisiert. Welche Auslassungen erwartet werden. Welche Werte abgeleitet sind. Welche Werte vom Nutzer stammen. Welche Transformationen auf dem Weg passiert sind. Ohne diesen Kontext wird Qualität zu einer Stimmung und das Dashboard zu Innenarchitektur.

KI macht diese Unterscheidung schwieriger, weil Modelle hungrig nach Größe sind. Größe hat eine verführerische Wirkung auf Organisationen. Ein großer Datensatz kann Menschen davon abhalten zu fragen, ob die Zeilen noch das bedeuten, was sie zu bedeuten scheinen. Mehr Daten können Rauschen statistisch überdecken, aber sie können auch eine falsche Annahme weiter verbreiten. Wenn ein Label von einem überlasteten Team erzeugt wurde, geben Ihnen eine Million Labels vielleicht eine sehr große Messung von Überlastung. Wenn ein fehlendes Feld in einem System verweigert und in einem anderen unbekannt bedeutet, schafft die Zusammenführung eine Kategorie, die eine Warnweste tragen sollte.

Die alte Redewendung Müll rein, Müll raus ist immer noch nützlich, aber sie ist zu fröhlich. Moderne Systeme können Müll rein in selbstbewusste Ausgaben verwandeln, priorisierte Warteschlangen, automatisierte Briefe, Risikobewertungen, Managementberichte und Trainingsfeedback, das das nächste Modell füttert. Müll verlässt nicht mehr höflich den Raum. Er zirkuliert, lernt den Organisationsplan und wird in Steuerungsgremien eingeladen.

Der Standard, der zur Politik wurde

Viele Datenfehler beginnen mit einem Standardwert. Leer wird zu falsch. Fehlend wird zu null. Unbekannt wird zu geringem Risiko. Keine Antwort wird zu Zustimmung. Letzte bekannte Adresse wird zu aktueller Adresse. Neuester Datensatz wird zu bestem Datensatz. Eine Freitextnotiz wird zu einem Label, weil jemand das Dashboard ausliefern musste. Standardwerte sind nicht böse. Systeme brauchen Standardwerte. Das Problem ist, wenn Standardwerte zu Politik werden, ohne als Politik benannt zu sein.

Ein Standardwert ist eine Entscheidung über Unsicherheit. Er sagt, was die Organisation tun wird, wenn sie es nicht weiß. Diese Entscheidung kann in einem Workflow mit geringen Auswirkungen harmlos und in einem folgenschweren inakzeptabel sein. Wenn ein Marketing-Präferenzfeld leer ist, kann ein vorsichtiger Standardwert einfach eine Nachricht vermeiden. Wenn ein Feld zur Anspruchsberechtigung von Leistungen leer ist, kann die Behandlung als nein Unterstützung verweigern. Wenn ein Feld zu klinischen Allergien leer ist, ist die Behandlung als keine keine Datenentscheidung. Es ist ein sehr schlechter Tag, der früh ankommt.

Gute Daten-Governance zwingt Standardwerte ans Licht. Sie unterscheidet unbekannt, nicht zutreffend, nicht erhoben, verweigert, ausstehend, geschätzt, geerbt, abgeleitet und verifiziert. Diese Kategorien wirken mühsam, bis die Alternative eine leere Zelle in Autorität verwandelt. Ein System, das Unsicherheit nicht darstellen kann, lässt Unsicherheit oft verschwinden, indem es vorgibt, sie aufzulösen. Das ist effizient auf dieselbe Weise, wie das Fegen von Glas unter einen Teppich effizient ist. Der Boden ist klar. Der Fuß widerspricht später.

Der praktische Test ist einfach: Könnte ein Prüfer sehen, wo der Standardwert gewirkt hat. Wenn eine Modellempfehlung, ein Workflow-Pfad oder eine Berichtskennzahl von einem Standardwert abhängt, sollte der Datensatz das zeigen. Wenn sich der Standardwert ändert, sollten frühere Ergebnisse interpretierbar bleiben. Wenn Menschen mit dem Standardwert nicht einverstanden sind, sollte es einen Verantwortlichen geben. Sonst hat die Organisation keine Regel automatisiert. Sie hat eine Annahme automatisiert, die Augenkontakt vermeidet.

Schlechte Labels sind leise Politik

Labels verdienen besonderes Misstrauen, weil sie oft objektiver wirken, als sie sind. Betrug, hohes Risiko, förderfähig, konform, dringend, schlechte Qualität, zufrieden, unsicher, abgeschlossen. Diese Wörter verdichten menschliches Urteil, Politik, Gewohnheit, Anreize, Zeitdruck und manchmal institutionelle Vorurteile zu einem Feld, das kurz genug für ein Modell ist. Das Label reist dann weiter, als wäre es eine Tatsache. Wenn es das Training erreicht, ist das Argument, das es erzeugt hat, meist schon nach Hause gegangen.

Ein Label kann falsch sein, weil der Mensch einen Fehler gemacht hat. Es kann auch falsch sein, weil die Anweisung unklar war, die Politik sich geändert hat, dem Prüfer der Kontext fehlte, die Kategorie zu breit war, das Werkzeug Eile begünstigte oder die Organisation ein bestimmtes Ergebnis belohnte. Ein Label kann konsistent sein und trotzdem eine schlechte Praxis kodieren. Konsistenz ist keine Tugend. Sie ist bloße Wiederholbarkeit, und Wiederholbarkeit kann Torheit mit bewundernswerter Disziplin wiederholen.

Für KI werden schwache Labels zu mehr als nur Rauschen in der Berichterstattung. Sie werden zum Ziel, das das Modell lernt. Wenn frühere Entscheidungen durch ungleichen Zugang, historische Vorurteile, schlechte Anreize oder unvollständige Aufzeichnungen beeinflusst wurden, kann das Modell das Narbengewebe der Institution lernen und es Vorhersage nennen. Das macht das Modell nicht bösartig. Es macht das Trainingsziel unzureichend geprüft. Nur den Algorithmus zu beschuldigen, ist attraktiv, weil Algorithmen keine Leistungsbeurteilungen besuchen.

Bessere Kennzeichnungspraxis ist nicht glamourös. Schreiben Sie Richtlinien. Erfassen Sie die Identität oder Rolle des Prüfers, wo angemessen. Halten Sie Meinungsverschiedenheiten fest. Stichproben für Qualität. Bewahren Sie Beispiele für Randfälle auf. Überprüfen Sie Labels nach Politikänderungen. Trennen Sie Labels für den Betrieb von Labels für das Training. Benennen Sie Unsicherheit. Erlauben Sie Prüfern zu sagen: nicht bestimmbar. Das Letzte ist überraschend radikal in Organisationen, die ordentliche Spalten ehrlichem Zweifel vorziehen.

Duplikate sind nicht nur Speicherverschwendung

Doppelte Datensätze klingen wie ein Speicherproblem, bis sie auf einen Menschen treffen. Dann werden sie zu verpassten Terminen, falscher Förderfähigkeit, fragmentierter Geschichte, wiederholtem Onboarding, mehreren Rechnungen, widersprüchlichen Risikobewertungen und Briefen, die einen Menschen als drei Kunden ansprechen. Die Datenbank mag denken, sie habe mehr Datensätze. Der Mensch erlebt, dass die Institution sie nicht erkennt. Das ist eine andere Kategorie von Fehler.

Identität ist besonders schwierig, weil die reale Welt unordentlich ist. Menschen ändern Namen, Adressen, Arbeitgeber, Ärzte, Schulen und Familienstrukturen. Unternehmen fusionieren. Vermögenswerte wandern. Geräte werden ersetzt. Abteilungen benennen Programme um, weil die Welt offenbar noch Verwirrung übrig hatte. Abgleichregeln brauchen Bescheidenheit. Zu streng und dieselbe Person wird auf mehrere Datensätze verteilt. Zu locker und verschiedene Personen verschmelzen zu einer institutionellen Fiktion. Beide Fehler richten Schaden an.

KI-Systeme verstärken Identitätsprobleme, weil sie sich auf zusammengesetzten Kontext stützen. Eine Fallzusammenfassung kann relevante Vorgeschichte übersehen, weil die Datensätze getrennt waren. Ein Risikowert kann die Gefährdung überzeichnen, weil Duplikate doppelt gezählt wurden. Eine Empfehlung kann einen Datensatz einer anderen Person anführen, nachdem zu aggressiv zusammengeführt wurde. Der Abruf kann die falsche Akte zutage fördern, weil Kennungen wiederverwendet wurden. Das Modell wird zum sichtbaren Gesicht einer Identitätsebene, die still vor sich hin krank war.

Gute Identitäts-Governance gibt Duplikaten einen Prozess, nicht nur eine Bereinigungsaktion. Sie definiert Abgleichsicherheit, Schwellen für menschliche Prüfung, Quellenautorität, Rechte zum Zusammenführen und Trennen, Prüfpfade, Benachrichtigungspflichten und Korrekturwege. Am wichtigsten ist, dass sie das Trennen als erstklassige Operation behandelt. Organisationen lieben das Zusammenführen, weil es sich wie Aufräumen anfühlt. Beim Trennen lernen sie, ob das Aufräumen die Realität zerbrochen hat.

Veraltung ist ein Governance-Problem

Daten bleiben nicht wahr, nur weil niemand sie angefasst hat. Manche Fakten verfallen. Adressen, Beschäftigungsstatus, Kontostand, Rechtsvorschriften, klinische Zustände, Einwilligungen, Risikostufen, Lagerbestände, Leistungsberechtigung, Eigentum, Gerätekalibrierung, Lieferantenstatus. Ein veralteter Wert kann die Validierung problemlos bestehen. Er hat den richtigen Typ, den zulässigen Code und die professionelle Haltung. Trotzdem ist er heute falsch.

Veraltung ist gefährlich, weil Systeme das Ausbleiben von Aktualisierung oft als Beleg für Stabilität behandeln. In vielen Bereichen bedeutet Schweigen, dass niemand geprüft hat. Ein Quellfeed kann ausgefallen sein. Ein Kunde kann keinen Grund gehabt haben, sich anzumelden. Ein öffentliches Register kann nachhinken. Ein Sensor kann getrennt sein. Eine Abteilung kann noch den Extrakt vom letzten Quartal verwenden, weil der Aktualisierungsjob einer Person gehört, die jetzt im Urlaub ist. Die Daten wurden nicht aktuell, indem sie höflich in einer Datenbank saßen.

Jedes folgenreiche Feld braucht einen Frischevertrag. Wie alt darf dieser Wert für diese Verwendung sein. Welche Quelle bestätigt ihn. Was passiert, wenn die Frische abläuft. Kann der Arbeitsablauf mit Warnung fortfahren, menschliche Prüfung verlangen, eine Live-Quelle abrufen oder stoppen. Frische sollte vom Zweck abhängen. Eine Postanschrift für einen Newsletter verträgt mehr Alter als eine Adresse für die Zustellung rechtlicher Mitteilungen. Ein Risikoindikator für den Tagesbetrieb kann nicht nach demselben Kalender leben wie die Jahresberichterstattung.

Frischeverträge helfen auch bei der KI-Bewertung. Wenn ein Modell versagt, fragen Teams oft, ob das Modell die Daten verstanden hat. Sie sollten zuerst fragen, ob die Daten noch lebendig waren. Ein veralteter, aber gültiger Datensatz ist eine besonders unangenehme Falle, weil er technische Prüfungen besteht und an der Realität scheitert. Die Realität, wie üblich, legt weniger Tickets an, als wir uns wünschen würden.

Das Modell bekommt die Schuld für das Archiv

Wenn die KI-Ausgabe schlecht ist, ist das Modell der naheliegendste Verdächtige. Es ist sichtbar, teuer, neu und manchmal wunderbar selbstüberzeugt. Aber viele Ausgaben sind nur so stark wie die Datensätze, die sie sehen können. Ein Modell, das eine unvollständige Datei zusammenfassen soll, produziert eine polierte Unvollständigkeit. Ein Modell, das Fälle anhand inkonsistenter Labels klassifizieren soll, lernt die Inkonsistenz mit hervorragender Haltung. Ein Modell, das Richtlinien aus einer veralteten Wissensdatenbank abrufen soll, zitiert die Vergangenheit, als hätte es noch Bürozugang.

Das ist wichtig, weil auf das Modell ausgerichtete Korrekturen Zeit verschwenden können. Nachschulung repariert keine fehlende Einwilligung. Ein größerer Kontextfenster behebt keine doppelten Identitäten. Ein besserer Prompt stellt keine gelöschte Bedeutung wieder her. Mehr Evaluierung hilft nicht, wenn der Testsatz dieselben kaputten Labels trägt wie die Produktion. Das Modell mag trotzdem Arbeit brauchen. Aber die Datenschicht muss als Verdächtige mit Mittel, Motiv und langer Vorgeschichte untersucht werden.

Es gibt auch eine politische Bequemlichkeit darin, dem Modell die Schuld zu geben. Wenn das Modell schuld ist, gehört die Lösung zum KI-Team. Wenn die Daten schuld sind, kann die Lösung zu Betrieb, Recht, Richtlinien, Produkt, Kundenservice, Aktenverwaltung, Lieferanten und Führung gehören. Das ist ein größerer Tisch. Größere Tische erzeugen mehr Tagesordnungspunkte. Manche Organisationen bevorzugen einen kleineren Tisch und eine schlechtere Erklärung.

Eine ernsthafte Vorfallprüfung beginnt daher früher. Welche Quelle trug die Tatsache. War sie aktuell. War sie erlaubt. Wurde die Bedeutung bewahrt. War das Label für diesen Zweck gültig. Verhielt sich der Identitätsabgleich richtig. Handelte ein Standardwert. Erreichte eine menschliche Korrektur das nachgelagerte System. Enthielt der Evaluierungssatz diese Art von Fehler. Erst nach diesen Fragen sollte das Modell eingeladen werden, sich zu verteidigen. Es mag trotzdem schuldig sein. Es sollte nicht allein sein.

Reparatur muss die Quelle erreichen

Viele Organisationen haben Korrekturprozesse, die den sichtbaren Fall beheben, aber nicht das Datensystem. Ein Support-Mitarbeiter aktualisiert die Adresse für den heutigen Brief, aber der Master-Datensatz bleibt alt. Ein Sachbearbeiter überschreibt die Berechtigung, aber das fehlende Feld bleibt fehlend. Ein Arzt korrigiert eine Zusammenfassung, aber die Extraktionsregel erzeugt weiterhin denselben Fehler. Eine Kundendienstnotiz sagt, vorherigen Wert ignorieren, was eine mutige, aber fragile Art ist, eine Datenbank zu verwalten.

Reparatur muss flussaufwärts wandern. Wenn ein Fehler am Verwendungsort gefunden wird, sollte die Korrektur die maßgebliche Quelle erreichen oder zumindest einen abgeglichenen Zustand mit Belegen schaffen. Das System sollte wissen, ob die Korrektur lokal, vorübergehend, umstritten, verifiziert oder strukturell ist. Eine Korrektur, die nicht weitergegeben werden kann, wird zu einem weiteren Stück schlechter Daten. Sehr effizient, im düsteren Sinne.

The repair path should also protect people from becoming unpaid data stewards for institutions. It is reasonable to ask someone to provide missing information once. It is not reasonable to make them correct the same record across five channels because the organisation's systems enjoy independence too much. When people repeatedly supply facts and the institution repeatedly forgets them, the problem is not user friction. It is institutional memory failure.

Good repair creates learning. If many corrections hit the same field, the collection form may be unclear. If many unmerges occur after a matching rule change, the threshold is wrong. If a label is disputed often, the guideline needs review. If stale records drive incidents, freshness contracts are missing. Data quality improves when correction is treated as evidence, not inconvenience.

Bad data is not morally neutral

It is tempting to treat data quality as a back-office concern. The records are messy, yes, but every organisation has messy records. That is true in the same way every building has dust. The question is whether the dust is on a shelf or inside the ventilation system. Once bad data drives automated decisions, prioritised work, AI outputs, reporting, compliance, payments or public services, it stops being back-office housekeeping. It becomes a way power is exercised.

That does not mean every error is a scandal. Serious institutions can make mistakes. The moral question is whether mistakes are visible, correctable and prevented from multiplying. A recordkeeping system that hides uncertainty, resists correction, punishes the person affected with repeated proof, and keeps using derived errors is not merely untidy. It is unfair in a durable way.

There is no single cure. Data work is local, domain-specific and occasionally humbling. But the posture is clear. Treat important fields as decisions with owners. Make uncertainty representable. Keep provenance close. Attach freshness to purpose. Audit labels. Govern identity. Propagate corrections. Measure repair burden, not only processing speed. When AI is involved, test the data path as hard as the model path. The records are not scenery. They are part of the machinery.

Die Tabellenkalkulation schrie nicht, denn Tabellenkalkulationen schreien selten. Das System tat, was Systeme tun: Es verwandelte stille Annahmen in lautere Konsequenzen. Die Lehre ist nicht, dass alle Daten perfekt sein müssen, bevor die Arbeit beginnen kann. Das würde die Zivilisation beenden, oder zumindest die Planung für Dienstag. Die Lehre ist, dass schlechte Daten nicht mit Autorität handeln dürfen, während sie billig, unsichtbar und das Problem eines anderen bleiben. Langsame Gewalt wird langsamer, wenn niemand sie benennt. Sie wird kleiner, wenn der Datensatz endlich für sich selbst Rechenschaft ablegen muss.