Warum sauber wirkende Daten KI trotzdem scheitern lassen: semantische Inkonsistenz

„Garbage in, garbage out“ gehört zu den meistzitierten Sätzen in der Data Science, und er stimmt: Wer ein Modell mit schlechten Daten trainiert, sollte keine guten Ergebnisse erwarten. Das Problem ist, dass der Satz so vertraut ist, dass er einen tückischeren Fall verdeckt. Was, wenn die Daten gar kein Müll sind? Was, wenn sie sauber aussehen? Die Spalten sind befüllt, die Formate gültig, offensichtliche Duplikate gibt es nicht, die Pipeline läuft, die Dashboards sehen normal aus, die Datenqualitätsprüfungen sind grün – und das KI-System trifft trotzdem unzuverlässige Entscheidungen.

Genau das ist Dateninkonsistenz. Die Werte sind nicht unbedingt falsch. Dieselben Daten bedeuten nur an verschiedenen Stellen Verschiedenes.

Auch saubere Daten können in die Irre führen

Nehmen wir ein Feld, das jedes Unternehmen in irgendeiner Form hat:

customer_status

Im CRM könnten seine Werte Folgendes bedeuten:

Active = Customer currently purchasing
Inactive = Customer hasn't purchased recently

Die Abrechnung liest dieselben Wörter anders:

Active = Account is financially open
Inactive = Account is closed

Und der Support hat eine dritte Lesart:

Active = Customer currently has an open support relationship
Inactive = No active support case

Jedes System kann gültige Werte, einheitliche Formatierung, vollständige Datensätze und keine sichtbaren Fehler haben, also findet eine klassische Datenqualitätsprüfung nichts. Führt man die Datensätze aber zusammen, ohne zu klären, was die Wörter bedeuten, bekommt die KI drei Definitionen von „active“. Die Daten sind nicht schmutzig. Ihre Semantik ist inkonsistent, und das ist viel schwerer zu erkennen.

Semantischer Drift

Bei Konsistenz geht es nicht nur ums Format. Es geht auch darum, ob Werte dasselbe bedeuten. Schauen wir uns „revenue“ an drei Stellen an. Ein System definiert es so:

System A:
Revenue = Invoiced amount

Zwei weitere Systeme weichen ab:

System B:
Revenue = Collected amountSystem C:
Revenue = Contract value

Der Feldname ist überall gleich, die Zahlen sind gültig, die Schemas sind gültig, die Pipelines funktionieren. Zusammengeführt ergibt sich trotzdem ein irreführender Datensatz. Ein Modell kann nicht wissen, dass hinter drei identischen Feldnamen drei geschäftliche Definitionen stehen. Jemand muss es ihm sagen.

Bedeutungen ändern sich mit der Zeit

Auch Definitionen verschieben sich. Angenommen, ein Unternehmen speichert ein Segment in diesem Feld:

customer_segment

Von 2022 bis 2024 lauten die Werte:

Enterprise
Mid-Market
SMB

Dann ändert das Unternehmen seine Segmentierungsstrategie, und ab 2025 lauten die Werte:

Strategic
Growth
Core

In der Datenbank gibt es weiterhin ein einziges Feld, die Pipeline läuft weiter, der Datentyp hat sich nicht geändert. Das Modell sieht ungefähr Folgendes:

2022 → Enterprise
2023 → Enterprise
2024 → Enterprise
2025 → Strategic
2026 → Strategic

Technisch ist nichts kaputt, aber die Bedeutung hat sich verschoben. Behandelt das Modell die alten Kategorien als direkt vergleichbar mit den neuen, lernt es womöglich Zusammenhänge, die das Geschäft nicht mehr beschreiben. Das ist ein Grund, warum Zeit Teil der Datenqualität sein muss.

Strukturelle und semantische Konsistenz

Die beiden werden leicht verwechselt, deshalb lohnt es sich, sie zu trennen.

Strukturelle Konsistenz bedeutet, dass die Daten den erwarteten technischen Regeln folgen:

customer_id → string
revenue → decimal
created_at → timestamp
status → allowed values

Semantische Konsistenz bedeutet, dass ein Feld überall, wo es verwendet wird, dieselbe geschäftliche Bedeutung trägt. Zum Beispiel sollte dieses Feld:

revenue

in Finanzen, Vertrieb, Analytics, CRM und Data Warehouse dasselbe bedeuten. Eine Pipeline kann die erste Anforderung erfüllen und an der zweiten komplett scheitern, und genau dort geraten viele KI-Systeme in Schwierigkeiten.

Warum die üblichen Prüfungen es übersehen

Die meisten Pipelines sind gut darin, technische Fehler zu erkennen:

NULL values
Duplicate rows
Invalid data types
Missing columns
Unexpected formats
Broken joins
Out-of-range values

Diese Prüfungen sind nützlich. Stellen Sie sich aber eine Tabelle mit den Kunden-IDs 101, 102 und 103 vor, alle als Active markiert, mit Umsätzen von 50000, 72000 und 31000. Alles wirkt plausibel. Nehmen wir nun an, Active bedeutet in System A einen kaufenden Kunden, in System B ein finanziell offenes Konto und in System C einen Kunden, der aktuell vom Support betreut wird. Eine Standard-Validierungsregel schlägt trotzdem nicht an, denn ungültig sind nicht die Werte. Ungültig ist ihre Bedeutung.

KI verschärft das Problem

Am stärksten wirkt sich das beim maschinellen Lernen aus. Klassische Software hat oft explizite Geschäftsregeln, etwa diese:

if customer_status == "Active":
    allow_action()

Ein Mensch kann diese Regel lesen und erkennen, was sie erwartet. Machine-Learning-Systeme lernen Zusammenhänge dagegen aus historischen Daten. Mischen die Trainingsdaten verschiedene Definitionen, kann das Modell die Inkonsistenzen aufnehmen, als wären es echte Muster:

Historical Data
      ↓
Different Business Definitions
      ↓
Combined Dataset
      ↓
Model Training
      ↓
Learned Relationships
      ↓
Predictions

Das Modell weiß nicht unbedingt, welche Definition maßgeblich ist. Es lernt aus dem, was es bekommt.

RAG leidet unter demselben Übel

Das betrifft nicht nur klassisches ML. Stellen Sie sich drei Unternehmensdokumente vor. Das Vertriebshandbuch sagt, ein qualifizierter Lead sei ein Interessent, der die BANT-Kriterien erfüllt. Die Marketingdokumentation sagt, ein qualifizierter Lead habe mit mindestens drei Kampagnen interagiert. Die CRM-Dokumentation sagt, es sei ein Lead, den ein Vertriebsmitarbeiter manuell als qualifiziert markiert hat.

Ein Mitarbeiter fragt einen internen Assistenten, was einen Lead qualifiziert. Das Retrieval findet womöglich alle drei Dokumente, und das Sprachmodell kann eine flüssige Antwort schreiben und sogar die Quellen zitieren. Das eigentliche Problem bleibt: Die Organisation hat keine einheitliche Definition. Die KI halluziniert nicht unbedingt. Sie spiegelt eine inkonsistente Wissensbasis wider.

Probleme, die nicht kaputt aussehen

Deshalb ist „Garbage in, garbage out“ für moderne KI zu einfach. Müll ist offensichtlich, Inkonsistenz kann unsichtbar sein. Einige Formen, die sie annimmt:

Derselbe Name mit unterschiedlichen Bedeutungen. Diese Bezeichnung:

"Revenue"

kann in einem System den fakturierten Umsatz und in einem anderen den eingegangenen Umsatz bezeichnen.

Derselbe Wert in unterschiedlichen Kontexten. Dieser hier:

"Active"

kann einen aktiven Kunden, ein aktives Konto oder ein aktives Abonnement bedeuten.

Dieselbe Kennzahl, unterschiedlich berechnet. Diese hier:

"Churn"

wird vielleicht von einem Team monatlich und von einem anderen jährlich berechnet.

Derselbe Zeitstempel in unterschiedlichen Zeitzonen. Dieser Wert:

2026-08-20 10:00

kann in einem System Ortszeit und in einem anderen UTC sein.

Derselbe Kunde unter unterschiedlichen Identitäten:

Customer ID: 10482
Account ID: C10482
External ID: 10482-IN

Keiner dieser Datensätze ist zwangsläufig fehlerhaft. Es sind inkonsistente Abbildungen der geschäftlichen Realität.

Eine andere Frage stellen

Statt nur zu fragen, ob die Daten sauber sind, sollten KI-Teams fragen, ob sie überall, wo sie verwendet werden, dasselbe bedeuten. Das führt zu tieferen Fragen: Wem gehört welche Definition, welche Geschäftsregeln gelten, wie haben sich Bedeutungen über die Jahre verändert, wie und aus welchem Quellsystem werden Kennzahlen berechnet, was bedeuten Begriffe und Einheiten, wie werden Zeitstempel erfasst und wie werden Identitäten zwischen Systemen zugeordnet. Das ist näher an semantischer Datenqualität als an gewöhnlicher Datenbereinigung.

Einen semantischen Vertrag schreiben

Ein praktischer Schritt ist ein semantischer Vertrag für kritische Felder. Beginnen Sie mit dem Namen des Felds:

Field:
customer_status

Halten Sie dann seine Bedeutung und die zulässigen Werte fest:

Business Definition:
Current commercial relationship with the customer.Allowed Values:
active
inactive
prospectOwner:
Customer OperationsSource of Truth:
CRMEffective From:
2026-01-01Rules:
"active" requires an active commercial relationship.
"prospect" cannot have completed customer status.

Nachgelagerte KI-Systeme haben jetzt eine explizite Grundlage. Verwendet ein anderes System diese Definition:

active = account has an open invoice

haben Sie einen Konflikt, und den können Sie lösen, bevor er überhaupt beim Modell ankommt.

Definitionen wie APIs behandeln

Ingenieure kennen den Wert von Verträgen zwischen Systemen längst. Verspricht eine API Folgendes:

{
  "customer_id": "string",
  "status": "active | inactive"
}

verlassen sich nachgelagerte Konsumenten darauf. Bei Daten sollte es genauso sein. Legen Sie für KI-kritische Felder die gesamte Kette offen:

Field
↓
Type
↓
Allowed Values
↓
Business Meaning
↓
Owner
↓
Source of Truth
↓
Effective Date
↓
Change History

Damit werden semantische Annahmen sichtbar, und sichtbare Annahmen lassen sich leichter testen.

Bedeutungsprüfungen in die Pipeline aufnehmen

Eine ausgereifte Pipeline fragt nicht nur, ob der Lauf erfolgreich war, sondern auch, ob sich die Bedeutung der Daten geändert hat. Eine konzeptionelle Validierungsschicht könnte so aussehen:

Incoming Data
      ↓
Schema Validation
      ↓
Data Quality Checks
      ↓
Semantic Validation
      ↓
Business Rule Validation
      ↓
AI Readiness Check
      ↓
Model / RAG Pipeline

Die Schema-Validierung fängt „die Spalte ist verschwunden“ ab. Die semantische Validierung fängt „die Spalte ist noch da, aber ihre geschäftliche Bedeutung hat sich geändert“ ab. Das sind sehr unterschiedliche Problemklassen.

Definitionen überwachen, nicht nur Werte

Angenommen, eine Pipeline verfolgt den durchschnittlichen Bestellwert, und das Dashboard zeigt:

Average Order Value
₹4,850

Nichts wirkt auffällig. Dann definiert das Unternehmen die Kennzahl neu: Früher war es der Bruttobestellwert, jetzt der Nettobetrag nach Abzug von Rabatten und Retouren. Die Zahl verschiebt sich womöglich so allmählich, dass kein technischer Alarm auslöst, doch das Modell, das sie verarbeitet, bekommt jetzt ein anderes Konzept. Monitoring muss von „Hat sich der Wert geändert?“ zu „Hat sich die Bedeutung geändert?“ reifen.

Agenten spüren es stärker

KI-Agenten sprechen zunehmend mit mehreren Tools und Datenquellen gleichzeitig:

Agent
 ├── CRM
 ├── Billing
 ├── Analytics
 ├── Knowledge Base
 └── Support System

Der Agent fragt womöglich jedes System nach demselben Kunden, und sind die Definitionen inkonsistent, bekommt er widersprüchliche Antworten. Das CRM sagt zum Beispiel Folgendes:

CRM:
Customer = Active

Abrechnung und Support melden dagegen etwas anderes:

Billing:
Account = DelinquentSupport:
Relationship = Closed

Der Agent hat jetzt drei technisch gültige Antworten. Welcher soll er glauben? Ohne semantische Regeln muss selbst ein sehr leistungsfähiges Modell zwischen widersprüchlichen geschäftlichen Bedeutungen raten.

Ein Data Dictionary sollte etwas tun

Viele Organisationen führen ein Data Dictionary, und oft wird daraus statische Dokumentation, die niemand prüft. Für KI sollten zentrale Definitionen zu operativen Kontrollen werden:

Definition
    ↓
Data Contract
    ↓
Validation Rule
    ↓
Pipeline Check
    ↓
AI Readiness

Ändert sich eine Definition, sollten die davon abhängigen nachgelagerten Systeme überprüft werden. So wird Data Governance von Dokumentation zu Engineering.

Was zu prüfen ist

Prüfen Sie bei KI-kritischen Datensätzen mindestens fünf Arten von Konsistenz:

1. Strukturell: Sind Felder und Typen konsistent?
2. Werte: Werden Werte auf dieselbe Weise dargestellt?
3. Semantisch: Bedeutet ein Feld überall dasselbe?
4. Zeitlich: Hat sich die Definition im Lauf der Zeit geändert?
5. Systemübergreifend: Stimmen verschiedene Systeme bei der zugrunde liegenden Geschäftsentität oder Kennzahl überein?

Das ergibt ein realistischeres Bild der Datenqualität.

Ein besseres mentales Modell

Das übliche Bild sieht so aus:

Bad Data → Bad AI

Ein genaueres hat einen zusätzlichen Schritt:

Bad Data
    ↓
Inconsistent Data
    ↓
Ambiguous Business Meaning
    ↓
Unreliable AI Context
    ↓
Unreliable AI Output

Und manchmal sieht der Weg so aus:

Clean-looking Data
        ↓
Hidden Semantic Differences
        ↓
Model Learns False Relationships
        ↓
Production Reliability Degrades

Gefährlich ist der zweite Weg, weil die Pipeline die ganze Zeit gesund aussieht.

Manchmal ist die Einigung das Schwierige

Es gibt eine unbequeme Möglichkeit: Die Organisation hat vielleicht gar kein Datenproblem, sondern ein Definitionsproblem. Die Finanzabteilung definiert einen Kunden so, der Vertrieb anders, das Marketing auf eine dritte Art, und der Betrieb hat seine eigene Lesart. Jeder hält seine Version für richtig, und von der KI wird erwartet, sie zu versöhnen. Das kann sie nicht – zumindest nicht zuverlässig – ohne explizite Geschäftsregeln. Bevor man fragt, wie man die Daten bereinigt, ist es manchmal sinnvoller zu fragen, ob sich das Unternehmen darauf einigen kann, was die Daten bedeuten.

Vor dem Modell hinschauen

Liefert ein KI-System unzuverlässige Ergebnisse, ist der erste Reflex, dem Modell die Schuld zu geben: den Prompt prüfen, das Modell wechseln, Parameter tunen, Retrieval hinzufügen, den Kontext vergrößern. Manchmal lernt das Modell aber schlicht aus einem inkonsistenten Bild des Geschäfts. Kein Upgrade löst einen undefinierten Geschäftsbegriff. Wenn drei Systeme sich nicht einig sind, was ein aktiver Kunde ist, schließt ein stärkeres Modell diese Governance-Lücke nicht. Es gibt nur eine überzeugendere Antwort auf eine mehrdeutige Frage.

Fazit

„Garbage in, garbage out“ ist ein guter Rat, reicht aber nicht mehr aus. Moderne KI braucht neben sauberen Werten auch eine konsistente Bedeutung. Der riskanteste Datensatz ist nicht immer der voller offensichtlicher Fehler. Es kann ein Datensatz sein, in dem alle Spalten vorhanden sind, alle Werte die Prüfung bestehen, alle Jobs durchlaufen und alle Dashboards grün bleiben, während verschiedene Ecken der Organisation demselben Feld stillschweigend unterschiedliche Bedeutungen geben. Ein solches Problem besteht jede technische Prüfung und schadet trotzdem der Zuverlässigkeit der KI. Bevor Sie also fragen, ob Ihre Daten sauber sind, fragen Sie, ob sich alle einig sind, was sie bedeuten.