KI im Handel: Warum Fachlichkeit bessere Daten liefert

Zwischen Black Friday, Weihnachtsgeschäft und Retourenwelle zeigt sich jedes Jahr brutal ehrlich, was im Einzelhandel wirklich zählt: Verfügbarkeit, Tempo und verlässliche Entscheidungen. Genau hier wird KI gern als Heilsbringer verkauft – als würde ein neues Modell allein plötzlich Bedarfe perfekt prognostizieren, Lieferketten glätten und personalisierte Empfehlungen „von selbst“ erzeugen.

Most companies get this wrong: Nicht die KI ist zuerst das Problem, sondern die Daten – und die entstehen aus der Art, wie wir Software bauen. 2025 hat diese Erkenntnis in vielen Tech-Teams an Schärfe gewonnen. Der Leitgedanke „Softwareentwicklung ist kein Selbstzweck“ trifft den Handel besonders, weil Technik dort nie eine Spielwiese ist: Sie muss verkaufen helfen, Kosten senken oder Risiken reduzieren.

Dieser Beitrag gehört in unsere Reihe „KI in Logistik und Lieferkettenmanagement“ und übersetzt den 2025er-Rückblick aus der Softwarearchitektur in eine sehr praktische Frage für Retail und E-Commerce: Wie bauen wir Systeme, die KI überhaupt erst sinnvoll machen – von Bestandsoptimierung bis Kundenanalyse?

Fachlichkeit zuerst: KI scheitert selten am Modell, fast immer am System

Wenn KI-Projekte im Handel enttäuschen, liegt es meist daran, dass Systeme Geschäftsprozesse auf technische CRUD-Aktionen reduzieren – und dabei Kontext vernichten. Das passiert leise und alltäglich: Ein Datensatz wird überschrieben, ein Status „aktualisiert“, eine Adresse „geändert“. Das System weiß danach zwar den aktuellen Stand, aber nicht mehr die Geschichte.

Für KI ist das fatal. Denn KI braucht nicht nur „was ist“, sondern „wie ist es dazu gekommen“:

• Warum wurde ein Artikel storniert – Preis, Lieferzeit, Zahlungsart, Fraud-Flag?
• Wieso ist der Bestand gesunken – Verkauf, Bruch, Inventurdifferenz, Umlagerung?
• Warum hat ein Kunde nicht gekauft – Out-of-Stock, falsche Größe, Checkout-Abbruch?

CRUD-Systeme speichern meist nur Zustände. Zustände sind für Reports okay. Für Ursachenanalyse, Prognosen und Personalisierung sind sie oft zu dünn.

Snippet-Satz: KI ist so gut wie die Ereignisse, die dein System sauber aufzeichnet.

Was „Fachlichkeit“ im Handel konkret heißt

Fachlichkeit klingt nach Theorie, ist aber im Handel sehr greifbar: Es sind die realen Vorgänge, die Geld kosten oder bringen. Beispiele:

• „Filiale hat 24 Stück erhalten“ (Wareneingang)
• „Kundin hat 2 Stück reserviert“ (Reservation)
• „Kommissionierung fehlgeschlagen“ (Fulfillment)
• „Retoure in Klasse B eingelagert“ (Retouren-Qualität)
• „Preis wurde wegen MHD reduziert“ (Markdown)

Wenn Software diese Sprache abbildet, entstehen Daten, die für KI brauchbar sind – weil sie Kontext, Zeit und Kausalität enthalten.

Von CRUD zu Ereignissen: Warum Event Sourcing für Bestände und Prognosen so gut passt

Event Sourcing speichert nicht den Endzustand, sondern die fachlichen Ereignisse, die ihn erzeugen. Im Handel ist das besonders wertvoll, weil Bestände nicht „einfach da“ sind – sie sind das Ergebnis vieler Bewegungen.

Statt:

• bestand = 120

speicherst du Ereignisse wie:

• WareneingangGebucht( +50, Lieferant, Charge, Zeitstempel )
• VerkaufAbgeschlossen( -2, Kanal, Preis, Kampagne )
• RetoureEingetroffen( +1, Grund, Zustand )
• InventurKorrektur( -3, Ursache )

Der Bestand lässt sich daraus jederzeit berechnen. Und wichtiger: Du kannst Fragen beantworten, die du heute noch nicht kennst. Genau das ist Gold für KI-Use-Cases wie:

• Bedarfsprognose pro Filiale/Kanal (Saisonalität, Aktionen, Lieferverzug)
• Out-of-Stock-Prävention (Frühwarnsignale aus Reservierungen, Abverkauf, Lieferplänen)
• Retourenprognose (Artikelmerkmale, Größenlogik, Versandart, Kundensegment)
• Anomalie-Erkennung (Schwund, Scanfehler, ungewöhnliche Korrekturen)

CQRS: Warum Lesen und Schreiben im Handel unterschiedliche Regeln brauchen

CQRS trennt Schreibmodelle (Transaktionen) von Lesemodellen (Abfragen/Views). Im E-Commerce ist das kein Luxus, sondern saubere Arbeitsteilung:

• Schreiben: korrekt, konsistent, auditierbar (Bestand, Preis, Auftrag)
• Lesen: schnell, flexibel, kanal- und use-case-spezifisch (Suche, Empfehlungen, Dashboards)

Praktisch heißt das: Du führst Ereignisse verlässlich, baust daraus verschiedene Sichten:

• „Verfügbar für Online-Shop“ (inkl. Reservierungen)
• „Verfügbar für Filiale“ (inkl. Umlagerungen)
• „ETA-basierte Verfügbarkeit“ (inkl. Lieferplänen)

KI greift dann auf genau die Sicht zu, die zum Problem passt – statt auf eine „one-size-fits-all“-Tabelle.

KI in der Lieferkette: Die besten Use Cases entstehen aus sauberen Ereignisdaten

Die schnellsten KI-Erfolge in Logistik und Supply Chain kommen dort, wo Ereignisse ohnehin entstehen – Scanner, Lagerbewegungen, Touren, Zustell-Scans, Retouren. Wer diese Daten fachlich korrekt modelliert, gewinnt zwei Dinge: bessere Steuerung und bessere Lernbasis.

1) Bestandsoptimierung: weniger Kapitalbindung, weniger Out-of-Stock

KI kann Bestände optimieren – aber nur, wenn klar ist, warum Bestände schwanken.

Ereignisbasierte Daten helfen bei:

• Demand Sensing: kurzfristige Signale (Abverkauf, Klicks, Reservierungen)
• Lieferzuverlässigkeit: Verzögerungen je Carrier/Lieferant als Feature
• Promo-Effekte: Kampagnen als Ereignisse, nicht nur als Attribut

Konkreter Effekt, den ich in Projekten immer wieder sehe: Sobald Teams Reservierungen, Teillieferungen und Inventurkorrekturen als eigene Ereignisse erfassen, sinkt die „mysteriöse Bestandsabweichung“ messbar – und Prognosen werden stabiler.

2) Personalisierte Empfehlungen: weniger „ähnliche Produkte“, mehr Kontext

Empfehlungs-KI wird oft auf Produktähnlichkeit reduziert. Im Handel zählt aber Kontext:

• „Wurde angesehen“ ist weniger aussagekräftig als „in Größe M in den Warenkorb gelegt“
• „Gekauft“ ist weniger aussagekräftig als „gekauft trotz längerer Lieferzeit“

Mit Ereignissen kannst du Empfehlungen bauen, die reale Kaufentscheidungen abbilden:

• Ereignisse aus Search/Navigation (Intent)
• Ereignisse aus Verfügbarkeit (Frust/Abbruchgründe)
• Ereignisse aus Retouren (Passform, Qualität, Erwartung)

Das führt zu Personalisierung, die nicht nur klickt, sondern Retouren reduziert – ein direkter Hebel für Logistikkosten.

3) Intelligente Kundendatenanalyse: Ursache statt Bauchgefühl

Kundendaten werden erst dann wertvoll, wenn sie erklärbar sind. Zustandsdaten sagen: „Kunde ist Churn-Risiko“. Ereignisdaten sagen: „Churn-Risiko, weil drei Bestellungen in Folge verspätet, dann Supportkontakt, dann Rücksendung.“

Damit wird KI handlungsfähig:

• proaktive Kompensation
• andere Carrier-Regel
• bessere Lieferzeitkommunikation

Nachvollziehbarkeit & Compliance: Warum Integrität in Retail-Daten ein KI-Thema ist

Sobald KI Entscheidungen beeinflusst (Preis, Verfügbarkeit, Fraud, Kredit), brauchst du Nachvollziehbarkeit. Nicht als „Nice-to-have“, sondern für Audits, Reklamationen, interne Revision – und in vielen Fällen für regulatorische Anforderungen.

Hier passen kryptografische Verfahren wie Merkle-Trees gut ins Bild: Sie ermöglichen, Datenintegrität von Event-Logs nachzuweisen, ohne alles offenlegen zu müssen. Im Handelskontext ist das relevant für:

• Manipulationsschutz bei Inventur- und Korrekturereignissen
• Nachweisbarkeit von Preisänderungen (z. B. bei Aktionen)
• forensische Analysen bei Fraud oder Refund-Betrug

Das ist keine technische Spielerei. Es schützt Marge und Vertrauen.

Praktischer Fahrplan: So startet ihr fachlich orientiert in KI für Logistik

Der beste Einstieg ist nicht „wir brauchen ein LLM“, sondern „welche Entscheidung wollen wir verbessern“. Danach rückwärts arbeiten – bis zur Datenerzeugung.

Schritt 1: Eine Geschäftsentscheidung auswählen (nicht zehn)

Gute Startpunkte in der Lieferkette:

1. Out-of-Stock reduzieren in A-Kategorien
2. Umlagerungen zwischen Filialen smarter planen
3. Retourenquote in Problemsegmenten senken

Definiere eine harte Zielgröße (Beispiele):

• Out-of-Stock-Rate in Kategorie X von 6% auf 4% in 12 Wochen
• Abschriften um 10% senken (MHD/Überbestand)

Schritt 2: Ereignisse definieren, die die Entscheidung erklären

Statt „wir brauchen mehr Daten“:

• Welche 10–20 Ereignistypen erklären das Problem?
• Welche Attribute sind fachlich notwendig (Zeit, Ort, Ursache, Kanal, Charge)?
• Was ist die Quelle der Wahrheit?

Schritt 3: Architektur passend bauen (Event Log + Views)

Ein pragmatisches Zielbild:

• Event Log als verlässliches Rückgrat (append-only)
• Read Models für Operations (Dashboard, Dispo, Shop-Verfügbarkeit)
• Feature Store / Trainingsdaten aus Ereignissen ableiten

Wichtig: Starte klein. Ein Pilotbereich reicht.

Schritt 4: KI erst dann modellieren – und sauber betreiben

Wenn Ereignisse stimmen, wird die Modellfrage einfacher:

• klassisches Forecasting oder ML für Nachfrage
• Anomalie-Modelle für Schwund/Fehler
• Recommender-Modelle mit Retouren-Feedback

Und: MLOps ohne Daten-Disziplin ist Theater. Wenn sich Ereignisse ändern, muss Versionierung und Monitoring das abfangen.

Was 2025 uns gelehrt hat – und warum 2026 im Handel über Datenqualität entschieden wird

2025 hat den Fokus verschoben: Codieren wird billiger, Denken wird teurer – im besten Sinne. KI kann Code schreiben. Sie kann aber nicht für dich klären, was „Reservierung“, „Verfügbarkeit“ oder „lieferfähig“ in deinem Geschäftsmodell wirklich bedeutet.

Für die Reihe „KI in Logistik und Lieferkettenmanagement“ heißt das: Wer 2026 bessere Prognosen, weniger Out-of-Stock und niedrigere Logistikkosten will, muss an einer Stelle anfangen, die viele unterschätzen: bei fachlich korrekter Softwareentwicklung.

Wenn du dir zwischen den Jahren eine einzige Frage stellst, dann diese: Erzeugt unser System Ereignisdaten, die eine Maschine verstehen kann – oder überschreiben wir die Vergangenheit weg?