Ein falscher Wert im Checkout kostet mehr als einen Support-Ticket-Vorgang. Wenn ein KI-Modell im Shop den Endpreis, die Ratenhöhe oder die Versandkosten berechnet, trifft der Kunde eine Kaufentscheidung auf Basis dieser Zahl. Liegt das Modell daneben, entsteht ein Rechtsproblem, kein UX-Problem. Genau deshalb rückt eine Frage in den Vordergrund, die viele Teams beim Rollout überspringen: Wie prüfen Händler, ob ein Sprach- oder Rechenmodell im Livebetrieb verlässlich rechnet?
Warum generative Modelle bei Zahlen systematisch daneben liegen
Große Sprachmodelle sind keine Taschenrechner. Sie erzeugen Wahrscheinlichkeiten über Token-Folgen und haben keine eingebaute Arithmetik. Bei kurzen Rechnungen fällt das selten auf, bei mehrstufigen Ketten – Nettopreis plus Steuer, minus Rabatt, plus Versand nach Zonenlogik – steigt die Fehlerquote messbar. Studien zu Reasoning-Benchmarks wie GSM8K und MATH zeigen seit 2023 durchgängig: Selbst starke Modelle brechen ein, sobald mehrere Rechenschritte und Einheiten ins Spiel kommen.
Für Shopbetreiber heißt das: Ein Modell darf im Checkout nicht rechnen, es darf nur formulieren. Die Zahl selbst muss aus einer deterministischen Quelle kommen – Preisregel-Engine, Steuer-API, Versandkostenmatrix. Alles andere ist ein Haftungsrisiko, das im Streitfall gegen den Händler läuft.
Wie funktioniert ein Praxistest für KI-gestützte Preis- und Zahlungslogik?
Der Test ist unspektakulär und in einem halben Tag machbar. Sie ziehen eine Stichprobe von 200 bis 500 realen Warenkörben aus den letzten 90 Tagen und lassen das Modell jeden Fall durchrechnen – Endpreis, Steueranteil, Versandkosten, Ratenhöhe bei Finanzierung. Parallel läuft dieselbe Stichprobe durch Ihre bestehende Preis- und Checkout-Logik. Jede Abweichung wird protokolliert.
Entscheidend ist die Toleranzschwelle. Bei Preisen gilt null Cent Abweichung. Bei gerundeten Raten und Steueranteilen ebenso, sobald sie dem Kunden angezeigt werden. Alles darüber ist ein Blocker für den Livegang. Shopify-Händler können das über die Admin-API und eine Testumgebung abbilden, Shopware- und Adobe-Commerce-Teams über die jeweiligen Preisregel- und Promotionsmodule. Wer Zahlungsdienste wie Klarna oder RatePay einbindet, muss zusätzlich die Ratenberechnung des Providers gegen die Modellausgabe stellen.
- Stichprobe aus realen Warenkörben, nicht aus konstruierten Testfällen
- Referenzlauf durch die bestehende Preis-Engine, nicht durch ein zweites Modell
- Abweichungsprotokoll mit Warenkorb-ID, Eingabe, Modellausgabe, Sollwert
- Wiederholung nach jedem Modell-Update oder Prompt-Wechsel
Was passiert, wenn der Test fehlt?
Die Fehler sind selten spektakulär, aber teuer. Ein um 3,40 Euro zu niedrig ausgewiesener Versandpreis bei 40.000 Bestellungen im Monat ist eine sechsstellige Differenz pro Quartal. Ein zu hoch angezeigter Ratenzins führt zu Abbrüchen im letzten Checkout-Schritt – und die sind nach Daten von Baymard Institute mit rund 70 Prozent Warenkorbabbrüchen ohnehin der teuerste Teil des Funnels.
Hinzu kommt die regulatorische Seite. Seit der Omnibus-Richtlinie müssen Preisangaben und Streichpreise belegbar sein. Ein Modell, das eine Zahl „plausibel“ schätzt, liefert diesen Beleg nicht. Im Beschwerdefall fehlt die Nachvollziehbarkeit.
Wer KI im Checkout einsetzt, braucht zwei Dinge: eine deterministische Rechenquelle und ein Protokoll, das jede angezeigte Zahl auf diese Quelle zurückführt.
Der Test gehört damit nicht ins KI-Projekt, sondern ins Release-Verfahren. Teams, die das ernst nehmen, bauen ihn als Gate ein: Kein Deploy der Checkout-Logik ohne bestandenen Abweichungslauf. Das klingt nach Overhead, ist aber der einzige Weg, generative Funktionen und Preisintegrität gleichzeitig zu betreiben. Wer heute Preise, Raten oder Liefertermine per Modell ausspielt, sollte die Stichprobe diese Woche ziehen – nicht nach der ersten Beschwerde.