KI im Lebensmittelhandel: Eine Outside-in-Chancenkarte für MPREIS

Öffentliche Informationen geprüft am 14. August 2026. Dieser Artikel stellt eine enge wirtschaftliche Frage: Welche Software-, KI- und Automatisierungschancen wären bei einem regionalen Lebensmittelhändler mit der öffentlich sichtbaren Größenordnung, Sortimentsbreite, App und Nachhaltigkeitsarbeit von MPREIS zuerst prüfenswert? Er diagnostiziert MPREIS nicht, beschreibt keine aktuelle Architektur und behauptet nicht, eine vorgeschlagene Fähigkeit fehle. MPREIS kann ähnliche Fähigkeiten längst intern betreiben, ohne sie öffentlich darzustellen.

Warum MPREIS ein interessanter Blickwinkel auf Retail-Technologie ist

Öffentliche Größenordnung und regionale Unterschiede schaffen einen konkreten Betriebskontext. Die offizielle Unternehmensseite nennt aktuell 279 Märkte, mehr als 5.000 Mitarbeiter:innen, über 250 regionale Lieferant:innen und ein Sortiment von mehr als 11.000 Produkten. Das sind öffentliche Fakten, keine Hinweise auf die Qualität von Prognosen, Daten oder Software.

Auch die Kundenschnittstelle ist sichtbar. Die offizielle MPREIS App-Seite zeigt App-Gutscheine, Sammelbonus, digitale Flugblätter, Einkaufsliste, Rezepte und Baguette-Menüs. Der öffentliche Produktkatalog macht außerdem die Verfügbarkeit nach Auswahl eines Marktes sichtbar. Von außen deutet das auf eine nützliche digitale Planungsfläche hin, auf der Aktionen, Filialkontext und Kundenabsicht zusammenkommen könnten. Wie App, Produktkatalog, Kasse und Warenbestand verbunden sind, ist daraus nicht ersichtlich.

MPREIS veröffentlicht bereits eine konkrete Maßnahme gegen Lebensmittelverschwendung. Laut der eigenen Too-Good-To-Go-Seite wurde die Zusammenarbeit im Juni 2024 auf fast alle Vertriebsformen MPREIS, miniM und Baguette ausgeweitet. Für 2026 nennt die Seite seit Beginn der Zusammenarbeit 416.000 gerettete Sackerl. Ein Vorschlag sollte diese sichtbare Fähigkeit erweitern und nicht so tun, als habe das Unternehmen hier noch nichts unternommen.

Was öffentlich beobachtbar ist und was nicht

Eine im Februar 2018 veröffentlichte Microsoft-Kundenstory beschrieb ein damaliges Cloud-Strategieprojekt sowie frühere Experimente mit Self-Scanning und Online-Shopping. Das ist ausschließlich historischer Kontext. Der Beitrag darf nicht als Beschreibung der MPREIS-Technologie im Jahr 2026 gelesen werden.

Die vier Chancen, die wir zuerst untersuchen würden

Chance 1: Frische prognostizieren und den Entscheidungsablauf verbessern

Das Geschäftsproblem lautet nicht bloß „Absatz vorhersagen“. Ein nützliches System muss eine Entscheidung auf Markt- und Artikelebene liefern, und zwar zu einem Zeitpunkt, an dem eine Bestellung noch verändert werden kann. Außerdem muss es die ungleichen Kosten von zu wenig und zu viel Bestand berücksichtigen. EU-weite Daten belegen die öffentliche Relevanz des Feldes: Eurostat berichtete, dass Einzelhandel und sonstige Lebensmittelverteilung 2022 acht Prozent der Lebensmittelabfälle in der EU verursachten. Das ist eine Branchenstatistik und keine Schätzung für MPREIS.

Wir würden mit einer kleinen, repräsentativen Auswahl aus Frische- und häufig beworbenen Artikeln in wenigen unterschiedlichen Markttypen beginnen. Mögliche Eingangsdaten müssten intern validiert werden: historische Verkäufe, Nichtverfügbarkeit, Abschriften, Aktionen, Preise, Lieferkalender, Haltbarkeit, Wetter und lokale Ereignisse. Ein Modell erzeugt Prognose und Unsicherheitsbereich. Eine Regel-Schicht übersetzt beides in eine zulässige Empfehlung. Mitarbeiter:innen sehen nur wesentliche Ausnahmen, Begründungen und die erwartete Wirkung einer Annahme oder Korrektur.

KI ist nicht automatisch das beste Prognoseverfahren. Eine begutachtete Studie über drei Lebensmittelketten und 151 Filialen zeigte, dass ein interpretierbares Retail-Prognoseverfahren in der untersuchten Konstellation Boosted Trees und weitere Benchmarks übertraf. Daraus folgt nicht, dieses Modell zu kopieren. Statistische, saisonale und Machine-Learning-Kandidaten müssen auf der tatsächlichen Verlustfunktion verglichen werden. Gewinnen sollte das einfachste Verfahren, das zuverlässig bessere Entscheidungen ermöglicht.

Chance 2: Die App vor dem Einkauf nützlich machen

Die öffentliche App verbindet bereits Aktionen, Listen, Rezepte und Marktbezug. Eine mögliche nächste Hypothese ist ein Planungsassistent für begrenzte Aufgaben, etwa: „Stelle drei vegetarische Abendessen für vier Personen aus aktuellen Aktionen in meinem gewählten Markt zusammen und bleibe unter meinem Budget.“ Der Assistent schlägt eine Liste vor, zeigt Ersatzprodukte und erklärt die verwendeten Bedingungen.

Das Modell soll Sprache und Präferenzen verarbeiten, nicht Wahrheit erzeugen. Verfügbarkeit, Preis, Allergene und Nährwerte müssen aus deterministischen Services kommen. Personalisierung braucht Einwilligung, Zweckbindung und eine einfache Rücksetzung. Für eine günstige Validierung reicht ein Prototyp mit kleinem Sortimentsausschnitt. Verglichen werden abgeschlossene Listen, akzeptierte Ersatzprodukte, Korrekturrate und Wiederverwendung. Der Versuch sollte stoppen, wenn Nutzer:innen ihn nicht klarer finden als Filter und Suche.

Chance 3: Lebensmittelrettung mit früheren Entscheidungen verbinden

Too Good To Go setzt bei Produkten nahe ihrer Verkaufsgrenze an. Wir würden prüfen, ob frühere Signale das Programm ergänzen können: erwarteter Restbestand, verbleibende Haltbarkeit, Nachfrage bis Ladenschluss und verfügbare Rettungskanäle. Das Ergebnis soll eine priorisierte Handlung sein, keine autonome Preisentscheidung.

Ein denkbarer Workflow empfiehlt eine von mehreren genehmigten Aktionen: Sichtbarkeit in der App erhöhen, ein Rettungssackerl vorbereiten, eine bestehende Abschriftenregel auslösen, die nächste Bestellung anpassen oder nichts tun. Lebensmittelsicherheit, Preisbefugnis und Eignung bleiben deterministisch. Marktmitarbeiter:innen behalten die Freigabe und erfassen einen Grund, wenn lokales Wissen besser ist als das Modell. Solche Korrekturen sind Evaluationsdaten und kein Beleg für ein Mitarbeiterproblem.

Chance 4: Produktdaten als wiederverwendbares Betriebskapital behandeln

Bei mehr als 11.000 Produkten können dieselben Fakten auf Website, App, Suche, Rezepten, Lieferantenabläufen und im Support auftauchen. Zuerst würden wir für jedes Feld die verbindliche Quelle und änderungsberechtigte Rolle abbilden. Danach kann Automatisierung Vollständigkeit prüfen, Konflikte finden und unkritische Texte entwerfen.

Generative KI kann Lieferantentexte in einen konsistenten Entwurf überführen oder fehlende Kategorien vorschlagen. Sie darf Allergene, Zutaten, Herkunftsangaben, Preise oder Bestand nie erfinden. Diese Felder benötigen Schema-Validierung, Herkunftsnachweis und menschliche Prüfung. Häufig schaffen ein gutes Produktinformationsmodell, klare Regeln und eine bessere Redaktionswarteschlange mehr Wert als ein größeres Sprachmodell.

Eine mögliche technische Architektur

Das folgende Muster ist hypothetisch und keine Beschreibung interner MPREIS-Systeme. Ohne Discovery lässt sich nicht einmal der passende Integrationsstil seriös wählen.

1. Quelladapter: lesen freigegebene Snapshots oder Ereignisse aus Kasse, Bestand, Produkt, Aktion, Abschrift, App und externem Kontext. Im Pilot wird kein führendes System ersetzt.
2. Governed Data Contracts: vereinheitlichen Markt, Artikel, Zeit, Aktion und Ergebnis, einschließlich Lineage, Qualitätsprüfungen und Zugriffsregeln.
3. Decision Services: betreiben Baseline-Prognosen, Kandidatenmodelle und deterministische Grenzen hinter versionierten APIs.
4. Workflow-Schicht: liefert priorisierte Ausnahmen an handlungsberechtigte Personen, fordert Freigaben und speichert Empfehlung, Änderung und Ergebnis.
5. Kundenschicht: zeigt ausschließlich freigegebene Verfügbarkeit, Preise und Inhalte in bestehenden App- und Web-Flächen. Einwilligung bleibt von Betriebsdaten getrennt.
6. Evaluationsschicht: vergleicht Modellversionen mit dem bisherigen Prozess, überwacht Drift und macht Rollback zu einem normalen Release-Schritt.

Die Hypothese in 30, 60 und 90 Tagen prüfen

Tag 0 bis 30: Discovery und Baseline

• Eine betriebliche Entscheidung, eine verantwortliche Rolle und eine wirtschaftliche Kennzahl auswählen.
• Aktuellen Workflow, Ausnahmen, Vorlaufzeiten und unverhandelbare Regeln dokumentieren.
• Nur die erforderlichen Daten auf Fehlstellen, Aktualität, Historie und Rechtsgrundlage prüfen.
• Repräsentativen Pilotausschnitt und Kontrollgruppe wählen.
• Stop-Kriterien vor dem Build festlegen.

Tag 31 bis 60: Shadow Mode

• Einfache Baselines und Kandidatenmodelle auf denselben Eingaben ausführen.
• Empfehlungen erzeugen, ohne Bestellungen, Preise oder Kundenerlebnisse zu verändern.
• Nur eine handhabbare Stichprobe prüfen lassen und Korrekturgründe strukturiert erfassen.
• Prognosefehler gemeinsam mit Verfügbarkeit, Verschwendung, Arbeitsaufwand und Stabilität messen.

Tag 61 bis 90: Kontrollierter Betrieb

• Einen begrenzten Ausschnitt mit Freigaben und sofortigem Rollback ausrollen.
• Vollständige Entscheidungskosten inklusive Daten, Inferenz, Integration und Review-Zeit erfassen.
• Mit der vereinbarten Baseline und Kontrolle vergleichen, nicht mit einer Demo.
• Ausweiten, iterieren oder stoppen. Ein gestoppter Pilot mit klarer Evidenz ist ein gültiges Ergebnis.

Unser 30/60/90-Tage-Plan für KI-Piloten erklärt Shadow Mode und Übergabe. Die Kill-or-Scale-Scorecard liefert das Modell für die Entscheidung.

Möglicher wirtschaftlicher Effekt ohne erfundenen ROI

Die Wirtschaftlichkeit hängt von internen Baselines ab. Unser Wertmodell wäre: vermeidbarer Abschriftenwert plus Deckungsbeitrag aus wiedergewonnener Verfügbarkeit plus frei werdende Betriebskapazität, abzüglich Implementierungs-, Betriebs- und Veränderungskosten. Jeder Term braucht Eigentümer:in, Datenquelle und kontrafaktischen Vergleich. Vorher würden wir weder prozentuale Einsparung noch Amortisationsdauer oder Umsatzwirkung veröffentlichen.

Nützliche Pilotmetriken sind gewichteter Prognosefehler, Regalverfügbarkeit, Abschriftenwert, Nutzung von Rettungskanälen, Review-Minuten, Override-Rate, Kundenkorrekturen, Aufgabenabschluss und Kosten pro angenommener Empfehlung. Eine Prognose kann besser werden, während der Betrieb schlechter wird. Deshalb darf keine einzelne Modellmetrik die Investition entscheiden.

Was wir intern erfahren müssten

• Welches Geschäftsziel hat Vorrang und welcher Zielkonflikt ist akzeptabel?
• Wer verantwortet Bestellung, Aktionen, Produktdaten, App-Erlebnis und Verschwendung?
• Welche Systeme sind führend, welche Schnittstellen existieren und welche Änderungen sind sicher?
• Welche Daten liegen auf Markt- und Artikelebene vor, mit welcher Aktualität und Historie?
• Welche Liefer-, Haltbarkeits-, Preis-, Personal-, Lebensmittelsicherheits- und Rechtsgrenzen gelten?
• Welche Einwilligung zur Personalisierung besteht und welche Kundennutzung wäre im Scope?
• Welche Baseline, Kontrolle und welches Stop-Kriterium machen die Pilotentscheidung glaubwürdig?

Bis diese Fragen beantwortet sind, bleibt die Chancenkarte eine Hypothesensammlung. Das ist professionelle Zurückhaltung und kein fehlendes Architekturdiagramm.

KI-Governance für einen Retail-Pilot

Nachfrageprognosen und Einkaufsempfehlungen sind nicht automatisch Hochrisiko-KI im Sinn des EU AI Acts. Die Einordnung hängt von Zweck und Einsatz ab. Die Verordnung bietet dennoch sinnvolle Engineering-Disziplin für Datengovernance, Logs und menschliche Aufsicht. Der offizielle Text definiert in Artikel 14 die menschliche Aufsicht für Hochrisikosysteme. DSGVO, Verbraucherrecht, Lebensmittelinformation und Arbeitsrecht können unabhängig von der AI-Act-Klasse relevant sein.

Praktisch bedeutet das: persönliche App-Daten nicht ohne gültigen Zweck und Einwilligungsmodell wiederverwenden, verbindliche Produktfakten außerhalb generativer Ausgaben halten, betrieblichen Nutzer:innen Begründung und Override geben, Entscheidungen protokollieren, ohne versteckte Mitarbeiterüberwachung zu schaffen, und zuerst die Nicht-KI-Baseline testen.