Ein KI-Modell, das im Checkout den Endpreis, die Versandkosten oder den Ratenbetrag ausgibt, ist kein Chatbot. Es ist eine Rechenmaschine, deren Ergebnis der Kunde unmittelbar als Zahlungshandlung nutzt. Genau hier liegt das Problem: Die meisten Teams testen ihre KI auf Tonalität und Antwortqualität — aber nicht auf numerische Korrektheit unter realen Shop-Bedingungen.
Der Kern der aktuellen Debatte aus der US-Entwickler-Community lässt sich auf einen Satz verdichten: Ein falsches Wort kostet Reputation, eine falsche Zahl kostet Geld. Wer ein Large Language Model (LLM) für dynamische Preisvorschläge, Staffelrabatte, Finanzierungsraten oder Brutto-Netto-Umrechnungen einsetzt, muss davon ausgehen, dass das Modell bei jeder Anfrage neu „würfelt“. LLMs rechnen nicht deterministisch, sie generieren plausibel klingende Token-Folgen. Für 19,99 Euro mal 1,19 ist das ein Konstruktionsfehler, nicht ein Bug.
Warum klassische QA-Tests bei KI-Preisen versagen
Ein Shopsystem liefert bei gleichem Input immer gleichen Output — das ist die Grundlage jeder Regressionstest-Suite. Ein LLM tut das nicht. Temperatur-Parameter, Kontextfenster und Prompt-Formulierung verschieben das Ergebnis. Ein Test, der gestern einen korrekten Ratenbetrag ausgespuckt hat, kann morgen denselben Betrag um 40 Cent verfehlen. Wer den Rechenweg nicht vom Modell, sondern von einer deterministischen Funktion erwartet, muss das architektonisch erzwingen.
Die praktikable Antwort heißt Function Calling: Das Modell interpretiert die Anfrage, ruft aber für jede Zahl eine klassische Rechenfunktion auf. Preis, Steuer, Rabatt und Versand werden im Code berechnet, nicht im Sprachmodell. Diese Trennung ist der eigentliche Test, den jedes Business vor dem Livegang fahren sollte.
Wie sieht ein belastbarer Zahlentest im Shop aus?
Der Test ist unspektakulär, aber wirksam. Man baut eine Prüfliste mit Grenzfällen — Warenkorb exakt an der Rabattgrenze, Gutschein kombiniert mit Staffelpreis, Lieferadresse außerhalb der EU, Kauf auf Rechnung mit Skonto. Dann lässt man das System diese Fälle hundertfach durchlaufen und vergleicht jeden numerischen Output gegen die Referenzrechnung im Backend.
- Jeder Preis-Output muss auf den Cent gegen die ERP- oder Shop-Datenbank abgleichbar sein.
- Jede Rundung muss derselben Regel folgen — kaufmännisch, nicht modellabhängig.
- Jede Währungsumrechnung braucht einen festen Kurszeitpunkt, keinen Live-Fantasiewert.
Wer diese drei Zeilen nicht reproduzierbar nachweisen kann, hat keinen KI-Preisrechner, sondern ein Haftungsrisiko. Bei falsch angezeigtem Endpreis greift in Deutschland Paragraf 433 BGB in Verbindung mit der Preisangabenverordnung — der Händler ist an den ausgegebenen Preis gebunden, nicht an den korrekten.
Welche Rolle spielen Shopsysteme und Payment-Anbieter?
Shopify, Shopware und Adobe Commerce setzen zunehmend auf eigene KI-Assistenz-Funktionen, etwa für Produktbeschreibungen oder dynamische Bündel. Die Preisberechnung selbst bleibt in den allermeisten Setups jedoch im Regelwerk des Shops oder im Payment-Gateway. Stripe, Adyen und PayPal liefern deterministische Beträge an der Schnittstelle — das Modell davor ist die Schwachstelle.
Für Teams, die KI-gestützte Rabattlogik oder personalisierte Preise testen wollen, lohnt ein Blick auf spezialisierte Tools: Shopify-Apps wie „Bold Discounts“ oder das Shopware-Plugin „Dynamic Pricing“ erzwingen serverseitige Regeln, bevor ein Modell überhaupt ins Spiel kommt. Wer die LLM-Schicht davorlegt, sollte mindestens einen serverseitigen Validator einbauen, der jeden generierten Betrag gegen die Datenbank prüft und bei Abweichung die Ausgabe blockiert.
Der Aufwand dafür ist gering — gemessen an dem Schaden, den eine falsche Zahl im Checkout anrichtet. Ein einzelner Kunde, der auf einen um 30 Prozent zu niedrigen Preis pocht, kostet mehr als die gesamte Testinfrastruktur. Die entscheidende Frage ist nicht, ob KI Zahlen ausgeben darf. Sie lautet: Wer haftet, wenn sie es falsch tut?