Produktdatenvalidierung: AI, wo nötig

Produktdaten sind ein attraktiver Enterprise-AI-Use-Case: Inputs sind unordentlich, das gewünschte Ergebnis wirkt strukturiert. Doch ein Modell, das ein Dokument lesen oder einen Text formulieren kann, sollte nicht über Compliance entscheiden. Wir trennen probabilistische Interpretation von deterministischer Kontrolle: Modelle extrahieren und formulieren; nachvollziehbare Regeln validieren und entscheiden.

Produktdaten sind ein Kontrollsystem, keine Schreibaufgabe

Ein Produktdatensatz verbindet Lieferantenevidenz, kommerzielle Anforderungen, rechtliche Pflichten, Kanalvorgaben und Stammdaten. Ein Attribut kann Suche, Logistik, Steuer, Sicherheit, Verpackung oder Erwartungen beeinflussen. Kleine Änderungen propagieren in viele Systeme.

„Produktcontent generieren“ ist daher die falsche Systemgrenze. Der Workflow nimmt Evidenz an, erkennt Entitäten und Attribute, wendet Policy an, routet Ausnahmen, protokolliert Freigaben und publiziert eine autorisierte Version.

Interpretation: variable Dokumente, Bilder oder Freitext lesen; Sprache auf bekannte Konzepte abbilden; Texte entwerfen.
Kontrolle: Pflichtfelder, Typen, Werte, Einheiten, Abhängigkeiten, Evidenz, Rechte und Publikationsstatus prüfen.

Interpretation ist probabilistisch und profitiert von Modellen. Kontrolle bleibt deterministisch, wo Policy formulierbar ist. Beides in einem Prompt zu verbinden erschwert Audit, Test und Einspruch.

Vor AI den kanonischen Datensatz definieren

Das Produktmodell braucht stabile IDs, typisierte Felder und Owner. Für jedes Attribut dokumentieren wir Definition, Einheit, Kardinalität, zulässige Quellen, Evidenz, Markt-/Kanal-Scope und Freigaberecht.

Rohe Evidenz bleibt unveränderlich; extrahierte Kandidaten stehen getrennt von freigegebenen Werten. So wird ein Modellwert nicht still zur Tatsache. Minimale Lineage:

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

Der Produktionsdatensatz enthält nur Werte, die Regeln und Approval passiert haben. Wie bei einem B2B-Katalog mit Zertifizierungsseiten bleiben Claims mit Evidenz verbunden.

Wo Modelle Wert schaffen

Kandidaten aus unstrukturierter Evidenz extrahieren

Formulare, technische Blätter, Labels und Bilder drücken dasselbe Attribut unterschiedlich aus. Ein Modell lokalisiert Werte, normalisiert Kontext und liefert strukturierte Kandidaten mit Evidenzreferenz. Fehlt Evidenz, verlangt der Outputvertrag null statt einer Vermutung. Bildregion, Seite oder Textstelle bleiben erhalten. Konfidenz routet Arbeit, ersetzt aber nie Evidenz.

Sprache auf ein kontrolliertes Vokabular abbilden

Ein Quellbegriff kann von der Taxonomie abweichen. Das Modell schlägt ein Konzept und eine Begründung vor; Regel oder autorisierter Reviewer akzeptiert. Exakte Synonymtabellen laufen zuerst, AI bearbeitet den Rest.

Kundentexte formulieren

Modelle entwerfen Titel, Bullets, Zusammenfassungen oder Übersetzungen ausschließlich aus freigegebenen Attributen. Danach prüfen Regeln Länge, verbotene Claims, Qualifier, Terminologie und unbelegte Werte. Das Modell beurteilt nicht die Compliance seines eigenen Texts.

Wo Regeln entscheiden müssen

Regeltyp	Beispielkontrolle
Vorhandensein	Pflichtattribut für diese Produktklasse befüllt
Typ und Format	Wert entspricht Typ und Encoding
Bereich	Zahl liegt im autorisierten Intervall
Enumeration	Wert gehört zum aktuellen Vokabular
Einheit	Einheit erlaubt, Umrechnung verlustfrei oder freigegeben
Feldübergreifend	Abhängiges Feld bei Triggerwert vorhanden
Evidenz	Claim besitzt zulässige, aktuelle Quelle
Konsistenz	Packmenge, Maße und Summen stimmen überein
Scope	Wert gilt für Sprache, Markt und Kanal
Autorität	Akteur darf Feld freigeben oder publizieren

Jede Regel hat ID, Version, Owner, Schwere und verständliche Meldung. Regeln laufen bei Ingestion, nach Extraktion, nach Edit, vor Export und Publikation. Interface, Batch und API verwenden denselben versionierten Validierungsdienst; duplizierte Logik erzeugt Widersprüche.

Diese Trennung macht auch Flatfile-Automatisierung über mehrere Ziele sicherer: Zielspezifische Formate können sich ändern, ohne die kanonische Validierung zu schwächen.

Ein Referenzworkflow

Ingest: Dateien, Checksums, Herkunft und Eingang registrieren.
Preprocess: Dokumente klassifizieren und Produktidentitäten zuordnen.
Extract: erst Parser, dann Modelle für ungelöste Felder.
Normalise: Formate und Einheiten ohne Bedeutungsänderung konvertieren.
Validate: zutreffende versionierte Regeln ausführen.
Review: nur Exceptions oder Hochrisikoänderungen autorisiert prüfen.
Approve: Wert, Evidenz und freigebende Identität erfassen.
Publish: kontrollierte Adapter je Ziel verwenden.
Observe: Ablehnungen, Korrekturen und Outcomes erfassen.

Jeder Übergang erzeugt ein Event. So können neue Taxonomien oder Regeln betroffene Records revalidieren, ohne alles neu zu extrahieren. Exakte IDs, Daten, Einheiten und Codes nehmen deterministische Pfade; Modelle bearbeiten mehrdeutige Felder. Das spart Kosten und Latenz.

Dasselbe gilt für Sprachvarianten. Eine saubere mehrsprachige Commerce-Architektur behandelt Übersetzungen als abgeleitete, versionierte Outputs, während freigegebene Fakten und Evidenz gemeinsam bleiben.

Konfidenz routet Arbeit, sie gewährt keine Wahrheit

Hohe Konfidenz beweist weder korrekte, aktuelle noch autorisierte Quellen. Wir kombinieren sie mit Risiko und Regelresultat. Niedrigrisiko-Kandidaten mit direkter Evidenz können leicht geprüft werden; sensible Claims brauchen unabhängig davon Approval. Fehlende Evidenz führt zur Abstention.

Schwellen werden nach Attribut und Dokumenttyp auf repräsentativen Daten kalibriert. Wir messen Precision, Recall, Abstention und Reviewer-Overrides je Segment, statt Unterschiede hinter einem globalen Wert zu verbergen.

Exceptions sind Teil des Produkts

Kataloge enthalten Bundles, Ersatzartikel, regionale Varianten, Altbestände und widersprüchliche Dokumente. Jede Exception braucht Reason Code, Schwere, Owner, Fälligkeit und erlaubte Lösung. Reviewer sehen Kandidat, Quelle, fehlgeschlagene Regeln und Downstream-Wirkung gemeinsam und können akzeptieren, korrigieren, ablehnen oder neue Evidenz anfordern.

Overrides bleiben explizit und scoped; sie deaktivieren keine globale Regel. Wiederholte Overrides zeigen Verbesserungsbedarf bei Regel, Taxonomie, Quelle oder Datenmodell. Service Levels folgen dem Risiko, nicht der Ankunftsreihenfolge.

Messung von Baseline bis Outcome

Vor Automation messen wir Vollständigkeit, First-Pass-Validierung, Korrekturschleifen, Review-Zeit, Downstream-Ablehnung und schwere Defekte. Vertrauliche Berichte verwenden einen Index mit Baseline = 100; absolute Mengen und Werte bleiben autorisiert intern.

Danach trennen wir Extraktionsqualität und Betriebsergebnis:

Kandidatengenauigkeit und Evidenzabdeckung je Attribut;
Regelpass- und Abstention-Raten;
menschliche Overrides und Korrekturen;
Queue-Alter und Zeit zum freigegebenen Record;
Zielablehnungen und Korrekturen nach Publikation;
Guardrails für schwere Fehler.

Modelle, Prompts, Taxonomien und Regeln werden separat versioniert. Evaluation Sets enthalten Normalfälle und Exceptions. Replays vergleichen neu akzeptierte und abgelehnte Records. Verschlechtert sich ein Guardrail über die Toleranz, blockiert das Release trotz besserem Durchschnitt.

Änderungen wie Policy-Änderungen steuern

Regeln kodieren operative Policy und brauchen Owner, Begründung, Wirksamkeitsdatum, Tests und risikogerechte Freigabe. Modelländerungen werden auf gelabelten, adversarialen und schwachen Inputs sowie ihrem strukturierten Outputvertrag getestet. Unbekannte Felder, falsche Typen und fehlende Evidenz müssen sicher scheitern.

Rollout erfolgt über Shadow Mode, begrenzte Kohorte und Erweiterung bei stabilen Guardrails. Der Write-Adapter erzwingt Idempotenz, Least Privilege und Rollback. Kein Modell erhält direkten, unbeschränkten Zugriff auf das System of Record.

Die skalierbare Arbeitsteilung

Die Architektur heißt nicht „AI gegen Regeln“, sondern klare Arbeitsteilung. Modelle verwandeln variable Evidenz in Kandidaten und freigegebene Fakten in Sprache. Regeln formulieren wiederholbare Policy. Menschen lösen Mehrdeutigkeit, genehmigen risikoreiche Änderungen und verbessern Policy. Event Logs verbinden jede Entscheidung mit Evidenz und Version.

Das begrenzt Risiko nach Aktion und Evidenz, schafft testbare Verträge und macht Fehler konkret. Produktdaten müssen nicht perfekt sein. Das System muss wissen, was beobachtet, abgeleitet und erlaubt ist und wer entschieden hat. AI gehört dorthin, wo Interpretation nötig ist; Regeln dorthin, wo die Organisation die Entscheidung formulieren kann.

Produktdatenvalidierung: AI, wo nötig – Regeln überall sonst