Produktdatenvalidierung: KI, wo nötig

Produktdaten sind ein attraktiver Anwendungsfall für KI im Unternehmen: Die Eingaben sind uneinheitlich, während das gewünschte Ergebnis strukturiert erscheint. Doch ein Modell, das ein Dokument lesen oder eine Beschreibung formulieren kann, sollte nicht entscheiden, ob ein Datensatz den Vorgaben entspricht. 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 Nachweise von Lieferanten, kommerzielle Anforderungen, rechtliche Pflichten, Kanalvorgaben und interne Stammdaten. Ein einzelnes Attribut kann Suche, Logistik, Steuern, Sicherheitsprüfung, Verpackung oder Kundenerwartungen beeinflussen. Eine scheinbar kleine Änderung kann sich auf viele nachgelagerte Systeme auswirken.

„Produktinhalte generieren“ ist daher die falsche Systemgrenze. Die Generierung ist nur eine Tätigkeit. Der eigentliche Workflow nimmt Nachweise entgegen, identifiziert Entitäten und Attribute, wendet Richtlinien an, weist Ausnahmen zu, protokolliert Freigaben und veröffentlicht eine autorisierte Version. Zuverlässigkeit hängt von der gesamten Kette ab.

Wir beginnen deshalb mit zwei Arbeitskategorien:

Interpretation: unterschiedliche Dokumente, Bilder oder Freitexte lesen; ungewohnte Sprache auf bekannte Begriffe abbilden; eine prägnante Beschreibung entwerfen.
Kontrolle: Pflichtfelder, Datentypen, zulässige Werte, Einheiten, feldübergreifende Abhängigkeiten, Nachweisanforderungen, Berechtigungen und Veröffentlichungsstatus prüfen.

Interpretation ist probabilistisch und profitiert von Modellen. Kontrolle sollte deterministisch sein, wo sich die Richtlinie ausdrücklich formulieren lässt. Beides in einem Prompt zu verbinden, erschwert die Überprüfung, das Testen und das Anfechten der Ergebnisse.

Vor dem KI-Einsatz den kanonischen Datensatz definieren

Das kanonische Produktmodell braucht stabile Kennungen, typisierte Felder und ausdrückliche Zuständigkeiten. Für jedes Attribut dokumentieren wir Definition, Einheit, Kardinalität, zulässige Quellen, erforderliche Nachweise, Geltungsbereich für Märkte oder Kanäle und die Befugnis zur Freigabe von Änderungen.

Die ursprünglichen Nachweise bleiben unveränderlich. Extrahierte Kandidaten speichern wir getrennt von freigegebenen Werten. So wird ein modellgenerierter Wert nicht stillschweigend zur Tatsache, und Prüfer können Kandidaten mit ihrer Quelle vergleichen. Ein minimaler Datensatz zur Datenherkunft und Verarbeitungshistorie umfasst:

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

Der Produktivdatensatz enthält nur Werte, die die relevanten Regeln und den Freigabeprozess durchlaufen haben. Das entspricht der Architektur eines B2B-Katalogs mit Zertifizierungsseiten: Aussagen sollten mit Nachweisen verbunden bleiben, statt als austauschbare Marketingtexte behandelt zu werden.

Wo Modelle Mehrwert schaffen

Modelle sind an den variablen Schnittstellen des Workflows nützlich.

Kandidaten aus unstrukturierten Nachweisen extrahieren

Lieferantenformulare, technische Datenblätter, Etiketten und Bilder stellen dasselbe Attribut oft in unterschiedlichen Layouts oder Formulierungen dar. Ein Modell kann wahrscheinliche Werte lokalisieren, den umgebenden Text normalisieren und einen strukturierten Kandidaten mit einem Verweis auf den Nachweis liefern. Die Ausgabespezifikation sollte bei fehlendem Nachweis null verlangen. Raten ist kein abgeschlossener Arbeitsschritt.

Bei Bildaufgaben sollte das System den Bildbereich oder die Seite erhalten, die die Extraktion belegt; bei Texten eine kurze Quellpassage oder Positionsangabe. Konfidenz hilft bei der Zuweisung von Arbeit, ist aber kein Nachweis und darf nie den Quellenverweis ersetzen.

Sprache auf ein kontrolliertes Vokabular abbilden

Ein Quellbegriff entspricht möglicherweise nicht exakt der Taxonomie des Unternehmens. Ein Modell kann den nächstliegenden kontrollierten Begriff vorschlagen und die Zuordnung erläutern. Die endgültige Annahme bleibt einer Regel oder einem befugten Prüfer vorbehalten. Gibt es eine exakte Synonymtabelle, sollte zuerst der deterministische Abgleich laufen. Das Modell bearbeitet nur die ungelösten Fälle.

Kundentexte formulieren

Modelle können Titel, Aufzählungspunkte, Zusammenfassungen oder Übersetzungen aus freigegebenen Attributen entwerfen. Der Prompt sollte ausschließlich den freigegebenen Datensatz verwenden und optionale Stilvorgaben klar kennzeichnen. Danach prüfen Regeln Länge, verbotene Aussagen, erforderliche Einschränkungen, Terminologie und unbelegte Werte.

Das Modell wird nicht gefragt, ob sein eigener Text die Vorgaben erfüllt. Sonst wäre dieselbe probabilistische Komponente zugleich Autor und Prüfer.

Wo Regeln entscheiden müssen

Regeln eignen sich dort, wo sich eine Fehlerbedingung formulieren und testen lässt. Typische Kategorien sind:

Regeltyp	Beispielprüfung
Vorhandensein	Erforderliches Attribut für diese Produktklasse ist ausgefüllt
Typ und Format	Wert lässt sich entsprechend dem deklarierten Typ und der Zeichenkodierung verarbeiten
Wertebereich	Zahlenwert liegt im freigegebenen Intervall
Enumeration	Wert gehört zum aktuellen kontrollierten Vokabular
Einheit	Einheit erlaubt, Umrechnung verlustfrei oder freigegeben
Feldübergreifend	Abhängiges Feld ist vorhanden, wenn der auslösende Wert zutrifft
Nachweis	Aussage besitzt ein zulässiges, aktuelles Quelldokument
Konsistenz	Packmenge, Abmessungen und daraus abgeleitete Summen stimmen überein
Geltungsbereich	Wert ist für Zielsprache, Zielmarkt und Zielkanal gültig
Befugnis	Akteur darf dieses Feld freigeben oder veröffentlichen

Jede Regel braucht eine Kennung, Version, verantwortliche Person, einen Schweregrad und eine verständliche Meldung. Die Meldung ist entscheidend: „Validierung fehlgeschlagen“ erzeugt ein Supportticket; „Nettomenge benötigt eine freigegebene Einheit und einen Quellenverweis“ erzeugt eine konkrete Korrekturaufgabe.

Diese Trennung macht auch die Flatfile-Automatisierung für mehrere Zielsysteme sicherer: Zielspezifische Formatierung kann sich ändern, ohne die kanonischen Validierungsrichtlinien zu schwächen.

Regeln sollten an mehreren Schnittstellen laufen: bei der Datenübernahme, nach der Extraktion, nach menschlichen Änderungen, vor dem Export und vor der Veröffentlichung. Oberfläche, Batch-Pipeline und API sollten denselben versionierten Validierungsdienst verwenden. Duplizierte Regellogik führt zu widersprüchlichen Ergebnissen.

Ein Referenzworkflow

Wir setzen den Prozess als Folge expliziter Zustandsübergänge um:

Daten übernehmen: Quelldateien, Prüfsummen, Herkunft und Eingangszeit registrieren.
Vorverarbeiten: Dokumente klassifizieren und möglichen Produktidentitäten zuordnen.
Extrahieren: zuerst deterministische Parser verwenden, danach Modelle für ungelöste Felder.
Normalisieren: Formate und Einheiten umrechnen, ohne die semantische Bedeutung zu verändern.
Validieren: das zutreffende versionierte Regelwerk ausführen.
Prüfen: nur Ausnahmen oder Änderungen mit hohem Risiko an eine befugte Person weiterleiten.
Freigeben: den angenommenen Wert, Nachweise und die Identität der freigebenden Person erfassen.
Veröffentlichen: über einen kontrollierten Adapter in jedes Zielsystem schreiben.
Beobachten: nachgelagerte Ablehnungen, Korrekturen und Ergebnissignale erfassen.

Jeder Übergang erzeugt ein Ereignis. Das Ereignisprotokoll macht den Ablauf erneut ausführbar: Ändert sich eine Taxonomie oder Regel, lassen sich betroffene Datensätze identifizieren und erneut validieren, ohne alles nochmals zu extrahieren.

Dasselbe gilt für Sprachvarianten. Eine konsequente mehrsprachige E-Commerce-Architektur behandelt Übersetzungen als abgeleitete, versionierte Ausgaben, während freigegebene Fakten und Nachweise gemeinsam genutzt werden.

Der Workflow vermeidet außerdem ein teures Fehlmuster: jedes Feld an das größte verfügbare Modell zu senden. Exakte Kennungen, Datumsangaben, bekannte Einheiten und definierte Codes sollten deterministische Pfade nehmen. Modelle bleiben mehrdeutigen Feldern vorbehalten. Das senkt Kosten und Latenz und macht die verbleibende Modellevaluation aussagekräftiger.

Konfidenz steuert die Zuweisung, belegt aber keine Wahrheit

Konfidenzwerte werden häufig missverstanden. Hohe Modellkonfidenz beweist nicht, dass eine Quelle korrekt, aktuell oder autorisiert ist. Sie beschreibt nur die Einschätzung des Modells unter einer bestimmten Methode.

Wir kombinieren Konfidenz mit Risiko und Regelergebnissen, um einen Bearbeitungsweg auszuwählen. Ein risikoarmer Kandidat mit direktem Nachweis, der alle Regeln erfüllt, kann in eine vereinfachte Prüfwarteschlange gelangen. Eine regulierte oder wirtschaftlich sensible Aussage kann unabhängig von der Konfidenz menschliche Freigabe erfordern. Fehlende Nachweise führen zum Verzicht auf eine Entscheidung, nicht zu einem niedrigeren Schwellenwert.

Schwellenwerte sollten je Attribut und Dokumenttyp mit repräsentativen Daten kalibriert werden. Ein globaler Schwellenwert verdeckt große Unterschiede: Die Extraktion einer Standardkennung ist nicht mit der Interpretation einer Materialaussage gleichzusetzen. Für jedes relevante Segment verfolgen wir Präzision, Trefferquote, den Anteil der Fälle ohne Entscheidung und gezielte Übersteuerungen durch Prüfer.

Ausnahmen sind Teil des Produkts

Reale Kataloge enthalten Produktbündel, Ersatzartikel, regionale Varianten, Altdatensätze und widersprüchliche Lieferantendokumente. Ein nur für den störungsfreien Standardfall konzipiertes System erzeugt manuelle Arbeit an unsichtbaren Stellen.

Jede Ausnahme braucht einen Ursachencode, Schweregrad, eine verantwortliche Person, ein Fälligkeitsdatum und eine zulässige Lösung. Prüfer sollten Kandidat, Quellnachweise, fehlgeschlagene Regeln und nachgelagerte Auswirkungen in einer Ansicht sehen. Sie müssen annehmen, korrigieren, ablehnen oder neue Nachweise anfordern können, ohne die ursprünglichen Quelldaten zu bearbeiten.

Gezielte Übersteuerungen müssen ausdrücklich dokumentiert und begrenzt sein. Ein Prüfer kann eine Warnung für ein bestimmtes Produkt und Zielsystem übersteuern, sollte aber die zugrunde liegende Regel nicht global abschalten. Wiederholte Übersteuerungen sind ein Signal, dass Regel, Taxonomie, Quellenprozess oder Produktmodell überarbeitet werden müssen.

Serviceniveaus sollten sich nach dem Geschäftsrisiko richten, nicht nach der Eingangsreihenfolge. Ein fehlendes optionales Marketingfeld und ein widersprüchliches Sicherheitsattribut gehören nicht in dieselbe Warteschlange.

Vom Ausgangswert zum Ergebnis messen

Vor der Automatisierung messen wir Feldvollständigkeit, Validierung im ersten Durchlauf, Korrekturschleifen, Prüfzeit, Ablehnungsquote in Folgesystemen und Quote schwerer Fehler. Für vertrauliche interne Berichte können wir jede Messreihe als Index mit Baseline = 100 ausdrücken. Absolute Mengen und kommerzielle Werte bleiben innerhalb der autorisierten Umgebung.

Nach der Freigabe trennen wir Extraktionsqualität von betrieblicher Leistung. Eine Extraktion kann technisch korrekt sein, aber zu spät für die Veröffentlichung eintreffen. Ein Workflow kann die Prüfzeit verkürzen und zugleich mehr schwere Fehler erzeugen. Unser Kennzahlensystem umfasst deshalb:

Genauigkeit der Kandidaten und Nachweisabdeckung je Attribut;
Anteil bestandener Regelprüfungen und Fälle ohne Entscheidung;
Anteil menschlicher Übersteuerungen und Korrekturen;
Warteschlangenalter und Zeit bis zum freigegebenen Datensatz;
Ablehnungen durch Zielsysteme und Korrekturen nach Veröffentlichung;
Schutzvorgaben für Fehler mit hohem Schweregrad.

Änderungen an Modellen, Prompts, Taxonomien und Regeln werden unabhängig versioniert. Evaluationsdatensätze enthalten häufige Datensätze und bekannte Ausnahmen. Vor dem Deployment führen wir die vorgeschlagene Version erneut aus und vergleichen sowohl neu akzeptierte als auch neu abgelehnte Datensätze. Eine Veröffentlichung wird blockiert, wenn eine Schutzvorgabe sich über die vereinbarte Toleranz hinaus verschlechtert, auch bei höherer durchschnittlicher Genauigkeit.

Änderungen als Richtlinienänderungen steuern

Regeln bilden operative Richtlinien ab. Ihre Änderung kann beeinflussen, welche Produkte veröffentlicht werden dürfen, welche Aussagen erlaubt sind und welche Teams Arbeit erhalten. Regeländerungen brauchen deshalb eine verantwortliche Person, Begründung, Wirksamkeitsdatum, Tests und eine den Auswirkungen angemessene Freigabe.

Modelländerungen brauchen ähnliche Disziplin, aber andere Tests. Wir bewerten Extraktion und Formulierung anhand gekennzeichneter Fälle, einschließlich gezielt irreführender Eingaben und solcher mit geringer Qualität. Außerdem testen wir die strukturierte Ausgabespezifikation: Unbekannte Felder, ungültige Typen und fehlende Nachweise müssen kontrolliert zum Fehlschlag führen.

Die Bereitstellung sollte schrittweise erfolgen. Im Beobachtungsmodus wird der neue Pfad verglichen, ohne Datensätze zu ändern. Danach folgt eine begrenzte Gruppe und bei eingehaltenen Schutzvorgaben die breitere Einführung. Der Adapter für Schreibaktionen erzwingt Idempotenz, minimale Berechtigungen und die Möglichkeit, Änderungen zurückzusetzen. Kein Modell erhält direkten, uneingeschränkten Zugriff auf das führende System.

Die skalierbare Arbeitsteilung

Die tragfähige Architektur lautet nicht „KI gegen Regeln“. Sie beruht auf einer bewussten Arbeitsteilung.

Modelle verwandeln variable Nachweise in Kandidaten und freigegebene Fakten in brauchbare Sprache. Regeln bilden wiederholbare Richtlinien ab. Menschen lösen Mehrdeutigkeit, genehmigen Änderungen mit großen Auswirkungen und verbessern Richtlinien, wenn Ausnahmen eine Lücke zeigen. Ereignisprotokolle verbinden jede Entscheidung mit Nachweisen und versionierter Logik.

Dieses Design lässt sich Führungskräften leichter erklären, weil Risiken durch Aktionen und Nachweise begrenzt werden. Es lässt sich leichter umsetzen, weil Komponenten prüfbare Schnittstellenvereinbarungen haben. Und es lässt sich leichter betreiben, weil Fehler konkret werden: Eine Extraktion hat einen Wert übersehen, eine Quelle war unzulässig, eine Regel hat eine Kombination abgelehnt oder ein befugter Prüfer hat eine Warnung übersteuert.

Produktdaten im Unternehmen werden nie vollkommen sauber oder einheitlich sein. Das müssen sie auch nicht. Das System muss wissen, was beobachtet, was abgeleitet und was erlaubt ist und wer entschieden hat. Setzen Sie KI dort ein, wo Interpretation wirklich erforderlich ist. Verwenden Sie Regeln überall dort, wo das Unternehmen die Entscheidung bereits formulieren kann.

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