Ein Kunde sieht 412,90 Euro im Checkout, bestellt, und die Rechnung nennt 489,20 Euro. Der Fall klingt konstruiert, ist aber die logische Konsequenz, wenn Shopbetreiber großen Sprachmodellen Aufgaben überlassen, deren Ergebnisse Kunden unmittelbar handeln lassen: Preisberechnung, Rabattlogik, Ratenzahlungsbeträge, Versandkosten. Wer KI hier ohne Kontrolle einsetzt, verkauft Zahlen, die niemand verifiziert hat.
Der Kern des Problems ist nicht die Modellqualität. Es ist die fehlende deterministische Prüfschicht. Ein LLM liefert bei gleichem Prompt nicht garantiert dasselbe Ergebnis — ein klassischer Rechenkern schon. Sobald ein KI-System einen Preis, eine Rate oder einen Zahlbetrag ausgibt, den ein Kunde per Klick bestätigt, handelt es sich rechtlich um eine Preisanzeige, nicht um einen Vorschlag. Eine falsche Zahl ist damit kein UX-Fehler, sondern ein Vertrags- und Compliance-Problem.
Warum klassische Tests bei KI-Preisen versagen
Eine klassische Preisberechnung ist testbar: Eingabe, Formel, erwarteter Output. Bei einem Modell, das Beträge „schätzt“ oder aus Freitext ableitet, fehlt diese Eindeutigkeit. Der Test muss deshalb anders aussehen. Entscheidend ist die Trennung: Die KI darf interpretieren und vorbereiten, aber der verbindliche Zahlenwert muss aus einer deterministischen Quelle kommen — Datenbank, Pricing-Engine, ERP-Schnittstelle.
Praktisch heißt das: Formuliert ein KI-Assistent eine Ratenzahlung über zwölf Monate, muss die Rate aus der Payment- oder Finanzierungslogik kommen, nicht aus dem Sprachmodell. Das LLM darf den Vorgang anstoßen und das Ergebnis in Text kleiden — nicht aber die Zahl selbst erzeugen. Diese Architektur ist der eigentliche Test, den jedes Unternehmen vor dem Livegang fahren sollte.
Wie funktioniert ein belastbarer Vorab-Test für KI-Zahlen?
Der Test besteht aus drei Stufen. Erstens: Grenzfälle. Händler definieren Eingaben, bei denen Rundung, Währung, Steuersatz und Staffelpreise kippen — also genau dort, wo Modelle typischerweise danebenliegen. Zweitens: Wiederholung. Derselbe Prompt läuft mindestens zwanzigmal; weicht ein einziger Betrag ab, ist die Zahl nicht freigabefähig. Drittens: Abstimmung gegen das führende System. Jede vom Modell vorgeschlagene Zahl wird gegen die Pricing- oder Warenwirtschaftslogik geprüft.
- Preis- und Rabattberechnung: nur aus Shopsystem oder PIM, nie aus dem Modell
- Ratenzahlung und Finanzierung: Beträge aus der Payment-Integration (z. B. Klarna, RatePay, PayPal Ratenkauf)
- Versand- und Zollkosten: aus der Versand-API, nicht aus geschätzten Werten
- Steuer- und Währungsbeträge: aus der Shop- oder ERP-Steuerlogik
Shopify, Shopware und Adobe Commerce haben in den vergangenen Monaten KI-Funktionen für Produkttexte, Suche und Empfehlungen ausgebaut. Sobald diese Systeme auch preisnahe Ausgaben erzeugen — etwa dynamische Bundle-Preise oder personalisierte Rabattvorschläge —, greift dieselbe Prüfpflicht. Ein Shopware-Händler, der ein KI-Plugin für Preisvorschläge testet, sollte den Output gegen die eigene Preisregel-Engine spiegeln, bevor das Feature live geht.
Was bedeutet das für den Shop-Alltag?
Die Verantwortung liegt beim Händler, nicht beim Anbieter des Modells. AGB und Preisangabenverordnung verlangen den korrekten Endpreis; ein Hinweis „KI-generiert“ entlastet nicht. Wer KI in zahlungsrelevanten Prozessen einsetzt, braucht deshalb einen festen Freigabeprozess: Modell liefert Vorschlag, Regel-Engine liefert die verbindliche Zahl, ein Log dokumentiert beide. Nur so bleibt im Streitfall nachvollziehbar, woher ein Betrag stammte.
Der Test vor dem Livegang ist damit kein IT-Detail, sondern Teil der Preis-Governance. Händler, die ihn überspringen, sparen zwei Wochen und riskieren Rückbuchungen, Widerrufe und Ärger mit der Verbraucherzentrale. Wer KI beschleunigen will, sollte zuerst die rechenbare Schicht bauen — und die KI nur davor setzen.