Fragen Sie zehn Anbieter nach „KI im E-Commerce" und neun zeigen Ihnen einen Chatbot, der FAQ-Fragen beantwortet. Das ist die häufigste, günstigste und am wenigsten wertvolle Anwendung künstlicher Intelligenz in einem Shop — eingeführt, damit auf der Website ein „AI-powered"-Abzeichen erscheint, und nicht, damit sich am Geschäftsergebnis etwas ändert.
Dieser Artikel handelt von etwas anderem. Wir zeigen drei Use Cases, die wir produktiv umgesetzt haben und die täglich in echten Shops arbeiten. Für jeden beschreiben wir dasselbe: welches geschäftliche Problem er löst, wie er wirklich unter der Haube funktioniert (Mechanismus, benötigte Daten, Integrationspunkte), woher der Return on Investment kommt — und, genauso wichtig, wann sich die Umsetzung nicht lohnt. Denn die ehrlichste Empfehlung zu KI lautet oft: „in Ihrem Fall rechnet sich das nicht".
Warum die meiste „KI im E-Commerce" Theater ist
Ein FAQ-Chatbot ist Theater, weil er auf nichts Zugriff hat, was zählt. Er kennt den Lagerbestand nicht, sieht den Status der Kundenbestellung nicht, kennt die Aktionsregeln nicht und kann keinen Rabatt berechnen. Er beantwortet allgemeine Fragen, die Kunden ohnehin nicht stellen — und bei der ersten konkreten Frage verweist er auf das Kontaktformular. Die Umsetzung dauert eine Woche, kostet wenig und bewegt keine Metrik, weil sie an keinen Prozess angebunden wurde, der diese Metrik erzeugt.
Gescheiterte KI-Projekte scheitern meist auf eine von drei Weisen, und es lohnt sich, sie zu erkennen, bevor Sie einen Vertrag unterschreiben. Erstens: Das Modell ist nicht an lebende Daten angebunden, also antwortet es mit Allgemeinplätzen statt mit Fakten aus Ihrem System. Zweitens: Es löst ein Problem, das Sie nicht haben — es baut einen Assistenten, wo ein guter Filter genügt hätte. Drittens: Niemand hat definiert, was sich ändern soll, also lässt sich nach der Einführung nicht sagen, ob überhaupt etwas funktioniert. Jeder dieser drei Fehler ist vermeidbar — aber nur vor dem Start, nicht danach.
Unser Prinzip ist umgekehrt: Wir beginnen beim geschäftlichen Problem, nicht bei der Technologie. Die Frage lautet nicht „wo drücken wir KI hinein", sondern „löst KI dieses konkrete Problem besser und günstiger als die Alternativen, die es schon gibt". Wenn eine gute Suche mit Filtern die Sache erledigt, raten wir von KI ab. Wenn drei Dashboards 90% der Fragen der Geschäftsführung beantworten, raten wir von einem Analyse-Assistenten ab. KI ist nur dort sinnvoll, wo sie tatsächlich Arbeit abnimmt, die Entscheidungszeit verkürzt oder einen Verkauf abschließt, den Sie sonst nicht abgeschlossen hätten.
Ein Chatbot, der keinen Zugriff auf Ihr Lager, Ihre Preisliste und Ihre Bestellstatus hat, ist keine „KI im E-Commerce". Das ist ein Widget. Wert entsteht erst dort, wo das Modell Zugriff auf Ihre echten Daten und Ihre echten Prozesse erhält.
Alle drei Use Cases unten haben eines gemeinsam: Das Modell ist an die lebenden Daten des Shops angebunden und verrichtet konkrete Arbeit in einem konkreten Prozess. Das ist die einzige Art von KI, die einen messbaren Ertrag bringt — und die einzige, die wir umsetzen.
Use Case 1: Einkaufsassistent und Self-Service-Kasse
Dieselbe Engine bedient zwei Kanäle: den Bildschirm der Self-Service-Kasse im stationären Geschäft und ein Widget im Onlineshop. Wir haben ihn bei einem Retail-Kunden produktiv eingeführt.
Das geschäftliche Problem
Ein Kunde steht an der Self-Service-Kasse oder durchsucht den Katalog online und bleibt hängen: Er findet das Produkt nicht, weiß nicht, ob es von einer Aktion erfasst ist, kann den Code nicht scannen, ist nicht sicher, ob die gewünschte Variante verfügbar ist. Im stationären Geschäft ruft er einen Mitarbeiter — wenn gerade einer frei ist. Online geht er einfach. Jede dieser Situationen bedeutet entweder gebundene Servicezeit oder einen abgebrochenen Warenkorb.
Wie es wirklich funktioniert
Das ist kein Chatbot, der an die Seite geklebt wurde. Es ist ein Modell der GPT-4-Klasse, eingebettet in eine RAG-Architektur (Retrieval-Augmented Generation): Die Frage des Kunden geht zuerst in eine Suche über den vektorisierten Produktkatalog, und das Modell formuliert die Antwort ausschließlich auf Basis dessen, was es tatsächlich in Ihren Daten findet. Dazu kommen Funktionsaufrufe an lebende Systeme — Prüfung des Lagerbestands, des Bestellstatus, der Aktionsregeln. Dadurch „erfindet" der Assistent keinen Preis: Entweder kennt er ihn aus dem System, oder er sagt, dass er es nicht weiß, und leitet zum Service. Dieser eine Unterschied — eine aus dem System geholte statt einer vom Modell generierten Antwort — trennt einen produktiven Assistenten von einem dekorativen Chatbot. Ein Kunde an der Kasse darf keinen Preis erhalten, den der Kassenbon nicht akzeptiert, und kein Verfügbarkeitsversprechen, das das Lager nicht bestätigt. Die gesamte Ingenieursarbeit dieses Use Cases besteht darin, das Modell an der kurzen Leine Ihrer echten Daten zu halten.
Was eine solche Umsetzung braucht:
Einen sauberen Produktkatalog — Namen, Attribute, Varianten, Preise, Verfügbarkeit. Das ist das Fundament; über seine Qualität schreiben wir weiter unten, und es entscheidet über alles.
Eine API für Preisliste und Aktionen — damit die Antwort zum Rabatt mit dem übereinstimmt, was die Kasse berechnet. Eine Abweichung hier ist schlimmer als kein Assistent.
Lager- und Bestellstatus — Verfügbarkeit einer konkreten Variante, Sendungsverfolgung.
Einen Kontaktpunkt — den Bildschirm der Self-Service-Kasse oder ein Widget im Onlineshop. Die Logik ist für beide Kanäle gemeinsam (Omnichannel), nur die Oberfläche unterscheidet sich.
Woher der ROI kommt
In unserer Retail-Umsetzung nahm der Assistent dem Service rund 60% der Zeit, die Mitarbeitende früher für die Unterstützung an den Kassen aufgewendet hatten, in den ersten Monaten ab. Das sind echte Personalstunden, die zu höherwertigen Aufgaben verschoben wurden — keine „Optimierung", sondern zählbare Teamkapazität. Online schließt derselbe Mechanismus Warenkörbe, die sonst beim ersten „ich weiß nicht, ob das passt" verschwunden wären. Der Ertrag ist messbar, weil wir die Metrik — Servicezeit, Abbruchquote — vor dem Start definieren und nicht nachträglich zum Ergebnis passend machen.
Wann es sich nicht lohnt
Wenn Sie einen kleinen Katalog, geringen Traffic an den Kassen und eine funktionierende Suche mit Filtern haben, wird der Assistent seine Kosten nicht zurückverdienen — weil es nichts zu holen gibt. Wenn Ihre Produktdaten unordentlich sind, bringen Sie zuerst die Daten in Ordnung: Ein Assistent auf einem Müllkatalog wird selbstbewusst und elegant falsche Antworten geben, und das ist schlimmer als gar kein Assistent.
Use Case 2: Visuelle Suche (Visual Search)
Der Kunde sucht Produkte, indem er sie fotografiert, statt sie mit Worten zu beschreiben. Diesen Use Case haben wir bei D2C-Kunden mit einem visuell reichen Katalog umgesetzt.
Das geschäftliche Problem
Der Kunde hat ein Produkt gesehen — ein Möbelstück bei Bekannten, eine Jacke auf einem Foto, eine Lampe im Café — und will es kaufen, kann es aber nicht beschreiben. Er tippt „so eine hölzerne Lampe im Retro-Stil" und die Textsuche liefert entweder zu viel oder nichts. Die Kaufabsicht ist hoch, und die Beschreibungshürde tötet sie. Das ist ein Verkauf, den Sie nicht am Preis oder an der Verfügbarkeit verlieren, sondern daran, dass der Kunde nicht benennen kann, was er will.
Wie es wirklich funktioniert
Der Kunde macht ein Foto. Ein Vision-Modell (CLIP-Klasse) kodiert dieses Foto in einen Vektor in demselben Raum, in den wir zuvor die Bilder Ihres gesamten Katalogs eingebettet haben; eine Nearest-Neighbour-Suche liefert die visuell ähnlichsten Produkte. Eine vorgeschaltete Objekterkennung erlaubt es, die Kategorie zu erkennen und einzuschränken, damit Stühle nicht mit Lampen vermischt werden. Den Katalog vektorisieren wir einmal und indexieren dann bei jeder Änderung des Sortiments nach — sonst lassen sich Neuheiten nicht finden.
Was hier kritisch ist:
Konsistente Produktfotografie in guter Qualität — das ist der Treibstoff dieses Use Cases. Je reicher und „visueller" der Katalog, desto treffsicherer die Zuordnungen.
Ein Vektorindex über die Katalogbilder, der zusammen mit dem Sortiment aktualisiert wird.
Eine Kategorie-Taxonomie — zum Einschränken und sinnvollen Sortieren der Ergebnisse.
Ein bequemer Upload, besonders mobil — der Kunde macht das Foto am Telefon, dort muss es reibungslos funktionieren.
Woher der ROI kommt
In optikgetriebenen Kategorien — Mode, Möbel, Interior, Accessoires — hebt die Suche per Foto die Konversion meist um einen niedrigen zweistelligen Prozentwert (in unseren Umsetzungen rund 12–18% in Shops mit visuell reichem Katalog). Der Mechanismus ist einfach: Sie gewinnen die Absicht „ich habe das irgendwo gesehen" zurück, die eine Textsuche nicht bedienen kann, und verkürzen den Weg vom Foto in den Warenkorb auf wenige Sekunden.
Wann es sich nicht lohnt
Bei Katalogen, die auf Spezifikationen und nicht auf Optik beruhen — Schrauben, Kabel, B2B-Komponenten — ist die parametrische Textsuche einfach besser; ein Foto unterscheidet nichts zwischen zwei fast identischen Teilen. Wenn die Fotografie dürftig oder inkonsistent ist oder der Katalog klein, wird Visual Search ein Gadget und kein Verkaufswerkzeug. Und wenn Kunden Produkte problemlos über Namen oder SKU finden — haben Sie kein Problem zu lösen.
Use Case 3: Analyse-Assistent über den Shopdaten
Die Person, die den Shop führt, fragt in natürlicher Sprache nach Daten, statt Abfragen zu schreiben oder auf einen Report zu warten. Diesen Use Case haben wir bei einem B2B-Kunden umgesetzt.
Das geschäftliche Problem
Der Inhaber oder die Geschäftsführung will in natürlicher Sprache fragen: „Zeig mir die 10 rentabelsten Produkte der letzten 30 Tage mit Jahresvergleich". Heute bedeutet das entweder eine SQL-Abfrage schreiben oder sich durch vier Reports klicken oder — meistens — ein Ticket an die IT stellen und zwei Tage warten. Das Wissen liegt in den Daten, aber der Zugang dazu ist der Engpass, und deshalb fallen manche Entscheidungen „aus dem Bauch", obwohl die Zahlen in der Datenbank liegen.
Wie es wirklich funktioniert
Ein LLM (Claude oder GPT-4) fungiert als Schicht, die natürliche Sprache in eine Abfrage auf Ihre Daten übersetzt. Die Frage wird in eine Abfrage auf die Bestell-, Kunden- und Produktdatenbank umgesetzt, auf echten Daten ausgeführt, und das Ergebnis kommt als Zahlen plus knappe Beschreibung zurück. Entscheidend: Das Modell „kennt" Ihre Verkäufe nicht aus dem Training — es fragt Ihre Datenbank live ab. Über die Datenbank legen wir eine semantische Schicht mit Metrikdefinitionen (was genau „Rentabilität" bedeutet), eine Zugriffskontrolle (wer worüber fragen darf) und ein Logging aller Abfragen.
Bedingungen, ohne die das nicht funktioniert:
Verlässliche, gut modellierte Verkaufsdaten — ein konsistentes Schema oder ein Data Warehouse. Ohne das sind die Antworten gleichzeitig selbstsicher und falsch.
Festgelegte Metrikdefinitionen — sonst bedeutet „Marge" in jeder Antwort etwas anderes und niemand vertraut dem Werkzeug.
Zugriffskontrolle und Audit der Abfragen — denn das ist eine Schicht über sensiblen Finanzdaten, nicht über Produktbeschreibungen.
Woher der ROI kommt
Hier ist der Ertrag anders als in den beiden vorherigen Fällen — es ist die Demokratisierung von Daten. Entscheider erhalten Antworten ohne Vermittlung der IT und ohne Warteschlange beim Analysten. Der Wert liegt in der verkürzten Entscheidungszeit, nicht in einem einzelnen eindrucksvollen Prozentwert; er ist schwerer einer konkreten Zahl zuzuordnen, bedeutet in der Praxis aber schnellere, häufigere und besser datengestützte Entscheidungen. Für einen Shop, in dem jede Woche jemand auf einen Report wartet, ist das ein echter Tempowechsel in der Führungsarbeit.
Wann es sich nicht lohnt
Das ist der anspruchsvollste der drei Use Cases — und der, den man am leichtesten verdirbt. Wenn Ihre Daten unordentlich sind, bekommen Sie das Schlimmste: ein Modell, das mit voller Überzeugung eine falsche Zahl liefert, und diese landet in einer Präsentation für die Geschäftsführung. Wenn Sie drei Reports haben, die 90% der Fragen beantworten, und niemand wirklich Ad-hoc-Fragen stellt — bauen Sie das nicht. Eine halluzinierte Zahl in einer Geschäftsentscheidung ist teurer als ein fehlendes Werkzeug.
Nicht das Modell ist der Engpass, sondern Ihre Daten
Wenn aus den drei Abschnitten oben ein Muster durchscheint, dann dieses: Jedes Mal, wenn KI scheitert, sind die Daten die Ursache, nicht das Modell. Ein Einkaufsassistent ist nur so gut, wie der Katalog sauber ist. Visual Search ist nur so gut, wie die Fotografie konsistent ist. Ein Analyse-Assistent ist nur so gut, wie das Data Warehouse verlässlich ist. Modelle der GPT-4- oder Claude-Klasse sind für E-Commerce heute schon gut genug — sie sind nicht die Begrenzung.
Wir bauen für typische E-Commerce-Anwendungen keine Modelle von Null auf. Foundation Models plus Fine-Tuning oder RAG sind günstiger und besser als eigenes Training. Die eigentliche Arbeit — und das eigentliche Budget — fließt in das Ordnen der Daten, nicht in das Modell.
Deshalb empfehlen wir, bevor wir den ROI von KI berechnen, häufig zuerst das Ordnen der Produktdaten — genau diese Arbeit leisten wir bei PIM-Implementierungen. Ohne einen sauberen, vollständigen Katalog startet jeder dieser Use Cases im Minus, und Sie zahlen für ein Modell, das nichts hat, worauf es zugreifen kann.
Das Zweite, was eine produktive Umsetzung von einer eindrucksvollen Demo unterscheidet, ist die Ingenieursarbeit um das Modell herum:
Monitoring und Fallbacks — wenn das Modell oder die API des Anbieters nicht antwortet, darf der Verkaufsprozess nicht stehenbleiben. Es muss einen Plan B geben.
Kontrolle der API-Kosten — Caching von Antworten, Auswahl des Modells passend zur Aufgabe (ein günstigeres, kleineres Modell genügt oft), harte Verbrauchsgrenzen.
Sicherheit und DSGVO — Konfiguration von Zero Data Retention auf Anbieterseite (OpenAI Enterprise, Anthropic mit BAA), Anonymisierung sensibler Daten vor dem Senden an das Modell, DSGVO-Audit vor dem Produktivgang.
Welcher Use Case passt zu Ihrem Shop
Eine verkürzte Entscheidungskarte — wovon abhängt, ob sich ein Use Case rechnet, und wann man besser darauf verzichtet:
Use CaseGrößter Ertrag, wenn…Daten, die sauber sein müssenWann verzichtenEinkaufsassistent / Self-Service-Kassegroßer Katalog, hoher Traffic, viele Fragen „passt das / ist das verfügbar"Katalog, Preisliste, Aktionen, Lagerbestandkleiner Katalog, gute Filter genügen bereitsVisuelle Sucheoptikgetriebene Kategorien (Mode, Möbel, Interior)konsistente, reiche Produktfotografiespezifikationsgetriebener Katalog (Teile, B2B), dürftige FotografieLLM-Analyse-Assistenthäufige Ad-hoc-Fragen, lange Warteschlange zur IT / zum Analystengut modellierte Verkaufsdatenbank + MetrikdefinitionenDaten unordentlich oder Dashboards beantworten 90% der Fragen
Was kostet das
Wir nennen hier bewusst keinen festen Preis. Die Kosten einer KI-Umsetzung hängen von drei Dingen ab: der Komplexität des Use Cases, der Zahl der Integrationen und dem erforderlichen Niveau der Datensicherheit. Grob steigen sie in der Reihenfolge, in der wir die Use Cases beschrieben haben — der Einkaufsassistent ist meist der einfachste, der Analyse-Assistent über einer sensiblen Finanzdatenbank der anspruchsvollste, weil Zugriffskontrolle und Audit hinzukommen. Zur einmaligen Umsetzung kommen laufende, planbare Kosten der API-Aufrufe — in der Größenordnung der monatlichen Kosten eines Werkzeugs im Firmenstack, nicht einer zusätzlichen Vollzeitstelle.
Statt Versprechen definieren wir geschäftliche KPIs vor dem Start und messen sie in einem Fenster von 90 Tagen. Ist das Ziel danach nicht erreicht, suchen wir zuerst die Ursache — sie liegt meist in den Daten, nicht im Modell — und korrigieren ohne Zusatzkosten. Zeigt sich, dass KI zu diesem Problem einfach nicht passt, erstatten wir in unseren Verträgen einen Teil des Projektwerts. Das ist eine praktikable Definition von „messbarem ROI" und kein Slogan auf einer Landingpage.
Fazit
KI im E-Commerce funktioniert genau dann, wenn sie aufhört, Zierde zu sein, und beginnt, an Ihre Daten und Ihre Prozesse angebunden zu sein. Die drei Use Cases oben — Einkaufsassistent, visuelle Suche und Analyse-Assistent — verbindet, dass jeder konkrete Arbeit abnimmt oder einen konkreten Verkauf abschließt und dass ihr Erfolg mehr von der Qualität Ihrer Daten abhängt als von der Wahl des Modells. Am häufigsten ist die beste Empfehlung eine Verengung: ein Use Case, ein definierter KPI, ein Fenster von 90 Tagen.
Wenn Sie prüfen möchten, welcher davon — falls überhaupt einer — sich in Ihrem Shop rechnet, haben wir unseren Ansatz ausführlicher auf der Seite KI im E-Commerce beschrieben. Und wenn Sie lieber gleich über ein konkretes Problem und die Daten sprechen, die Sie haben — schreiben Sie uns. Wir beginnen mit der Frage, ob KI hier überhaupt das richtige Werkzeug ist.