Dieser Beitrag wurde mit KI-Unterstützung erstellt, fachlich geprüft und redaktionell freigegeben.Artikelbild-Kennzeichnung: AI GENERATED

Ein Website-Chatbot kann Öffnungszeiten und Rückgabefristen aus einer gepflegten Wissensbasis beantworten. Schwieriger wird es bei Informationen, die sich laufend ändern: Preise, Varianten, Lagerbestand, Lieferzeit oder Abholbarkeit. Kopiert ein Unternehmen solche Werte regelmäßig in einen KI-Prompt oder in ein Dokument, beginnt die Antwort schon kurz danach zu veralten. Ein freundlich formulierter Satz kann dann sachlich falsch sein.

Ein KI-Chatbot mit Live-Daten braucht deshalb mehr als ein Sprachmodell. Er benötigt eindeutig benannte Quellsysteme, begrenzte Schnittstellen, Aktualitätsregeln und einen sicheren Ausstieg, wenn eine verlässliche Antwort nicht möglich ist. Für Online-Shops, Händler und andere KMU in Deutschland zeigt dieser Leitfaden, wie sich dynamische Produktinformationen kontrolliert ausgeben lassen, ohne dass der Bot Preise erfindet oder eine unverbindliche Prognose als Zusage formuliert.

Warum eine statische Wissensbasis für Live-Daten nicht reicht

Eine Wissensbasis eignet sich für relativ stabile Inhalte: Versandländer, Kontaktwege, Garantieabläufe oder Erklärungen zu Produktgruppen. Preis und Bestand haben dagegen einen eigenen Lebenszyklus. Ein Warenwirtschaftssystem kann einen Artikel reservieren, ein Shop kann einen Aktionspreis aktivieren und ein Versanddienst kann eine Laufzeit neu berechnen. Der Chatbot darf diese Werte nicht aus einem alten Text ableiten.

Die wichtigste Architekturentscheidung lautet daher: Das Sprachmodell formuliert die Antwort, aber das zuständige System liefert die Fakten. Für den Verkaufspreis kann das der Shop sein, für den verfügbaren Bestand das Warenwirtschafts- oder Lagerverwaltungssystem und für die Lieferprognose eine Versandlogik. Eine professionelle KI-Chatbot-Entwicklung für Websites beginnt mit dieser Zuordnung und nicht mit einer möglichst großen Prompt-Datei.

Auch offizielle Produktplattformen behandeln Preis und Verfügbarkeit als dynamische Daten. Die Google-Merchant-Produktspezifikation verlangt, dass Verfügbarkeit mit Landingpage, Checkout und strukturierten Daten übereinstimmt. Beim Preis beschreibt Google ebenfalls die Übereinstimmung zwischen Datenquelle, Produktseite und Checkout. Diese Vorgaben richten sich an Merchant Center, verdeutlichen aber ein allgemeines Qualitätsprinzip: Mehrere Ausgabekanäle sollten dieselbe belastbare Quelle verwenden.

Zuerst die verbindliche Datenquelle festlegen

Vor der technischen Anbindung braucht jedes dynamische Feld einen fachlichen Eigentümer. „Der Shop“ ist zu ungenau, wenn Preise zusätzlich im ERP gepflegt oder Bestände zwischen Filialen aufgeteilt werden. Ein kleines Quellenregister verhindert, dass Entwickler und Redaktion widersprüchliche Werte verwenden.

Information Verbindliche Quelle Zusätzlicher Kontext Sicherer Fallback
Preis Shop oder ERP Währung, Steuerstatus, Variante, Kundengruppe Produktseite verlinken, keinen Betrag nennen
Bestand Warenwirtschaft Filiale, Reservierungen, Sicherheitsbestand „Aktuell nicht sicher abrufbar“
Lieferzeit Versand- oder Shoplogik Zielregion, Zeitpunkt, Versandart Spanne oder menschliche Auskunft
Abholung Filialbestand Standort und Reservierungsstatus Filiale kontaktieren

Zu jedem Feld gehören außerdem Einheit, Zeitzone und Zeitpunkt der letzten Aktualisierung. Der Wert „5“ ist ohne Kontext nutzlos: Fünf Stück im Zentrallager, fünf frei verfügbare Einheiten oder fünf inklusive bereits reservierter Ware? Ein Chatbot sollte nur Daten erhalten, deren Bedeutung technisch feststeht.

Die Abfrage zwischen Nutzerfrage und Antwort begrenzen

Ein sicherer Ablauf besteht aus mehreren getrennten Schritten. Zuerst erkennt der Bot die Absicht, etwa „Preis der blauen Variante“ oder „Lieferung nach Köln“. Danach werden nur die benötigten Parameter extrahiert: Produkt-ID, Variante, Menge, Postleitzahl oder gewünschte Filiale. Eine serverseitige Funktion prüft diese Parameter und fragt das freigegebene Quellsystem ab. Erst das strukturierte Ergebnis darf in die Antwort einfließen.

Das Modell sollte keine beliebigen Datenbankabfragen erzeugen und keinen direkten Schreibzugriff erhalten. Stattdessen stehen wenige Funktionen zur Verfügung, beispielsweise get_product_price, get_available_stock und estimate_delivery_window. Jede Funktion akzeptiert nur definierte Felder, setzt Zeitlimits und liefert einen eindeutigen Status wie ok, not_found, stale oder unavailable.

Diese Trennung erleichtert auch Tests. Ob eine API den korrekten Bruttopreis liefert, lässt sich ohne Sprachmodell prüfen. Ob der Bot den Wert verständlich und mit den nötigen Einschränkungen ausgibt, ist ein eigener Test. Der bestehende Leitfaden KI-Chatbot testen: Testfälle für sichere Website-Antworten zeigt, wie normale Antworten, Grenzfälle und Übergaben systematisch erfasst werden.

Preise nur mit vollständigem Kontext ausgeben

Bei einer Preisanfrage muss die Schnittstelle mindestens Artikel oder Variante, Betrag und Währung zurückgeben. Je nach Angebot können Mengeneinheit, Grundpreis, Aktionszeitraum, Kundengruppe oder Standort hinzukommen. Der Bot darf nicht stillschweigend den günstigsten Variantenpreis auf eine andere Ausführung übertragen. Ebenso wenig sollte er einen Nettopreis als Endkundenpreis formulieren.

Die Preisangabenverordnung definiert unter anderem den Gesamtpreis einschließlich Umsatzsteuer und sonstiger Preisbestandteile. Welche Angaben im konkreten Shop und Gespräch erforderlich sind, hängt vom Angebot und Kontext ab. Der technische Prozess sollte deshalb nicht selbst rechtlich bewerten, sondern die von Shopverantwortlichen freigegebenen Preisfelder und Formulierungen verwenden. Bei Unsicherheit verweist der Bot auf die aktuelle Produktseite oder den Checkout. Dieser Beitrag ersetzt keine Rechtsberatung.

Praktisch hilfreich ist ein kurzer Zeitstempel in der internen Antwortstruktur. Nutzer müssen nicht jede Millisekunde sehen, doch der Bot kann bei stark veränderlichen Angeboten formulieren: „Der aktuell abgerufene Preis beträgt …; verbindlich ist die Anzeige im Checkout.“ Eine solche Einordnung muss zur tatsächlichen Vertrags- und Shopgestaltung passen und redaktionell freigegeben sein.

Bestand nicht mit Lieferbarkeit verwechseln

Ein positiver Lagerbestand bedeutet nicht automatisch, dass die gewünschte Menge sofort versendet werden kann. Reservierungen, beschädigte Ware, Sicherheitsbestände oder getrennte Standorte beeinflussen die verfügbare Menge. Für öffentliche Antworten ist oft eine abgestufte Aussage besser als eine exakte Zahl: „auf Lager“, „nur wenige verfügbar“, „vorbestellbar“ oder „derzeit nicht verfügbar“.

Welche Schwellen gelten, entscheidet das Unternehmen. Diese Regeln gehören in die Schnittstelle und nicht in die freie Formulierung des Modells. Fragt jemand nach zwölf Einheiten, muss die Funktion genau diese Menge prüfen. Eine Antwort auf Basis des allgemeinen Status „auf Lager“ wäre nicht ausreichend. Für Filialabholung kommen Standort und Reservierbarkeit hinzu.

Google beschreibt in seiner offiziellen Spezifikation für Bestandsdaten unter anderem Verfügbarkeitsstatus, Menge und Zeitstempel. Ein Chatbot muss dieses konkrete Feed-Format nicht übernehmen. Die Felder zeigen aber, warum Zustand, Menge und Aktualität getrennt modelliert werden sollten.

Lieferzeiten als berechnete Prognose behandeln

Lieferzeit entsteht aus mehreren Faktoren: Bearbeitungszeit, Lagerort, Bestellzeitpunkt, Feiertage, Zielregion und gewählte Versandart. Eine in der Wissensbasis gespeicherte Standardaussage kann diese Bedingungen nicht abbilden. Wenn der Shop bereits eine Lieferprognose berechnet, sollte der Chatbot dieselbe Logik abfragen.

Fehlt eine belastbare Berechnung, darf das Modell keine konkrete Ankunft erfinden. Dann sind eine redaktionell freigegebene Spanne, ein Link zur Produktseite oder eine Übergabe an den Support sinnvoll. Begriffe wie „garantiert“ oder „spätestens“ sollten nur erscheinen, wenn das Unternehmen dafür eine eigene verbindliche Regel und Datenbasis festgelegt hat.

Aktualität, Cache und Ausfälle sichtbar beherrschen

Live bedeutet nicht zwingend, dass jede Nutzerfrage direkt das ERP belastet. Ein kurzer Cache kann Antwortzeit und Systemlast verbessern. Entscheidend ist, dass die zulässige Cache-Dauer pro Datentyp feststeht. Ein Produktname kann länger zwischengespeichert werden als ein Restbestand. Aktionspreise benötigen möglicherweise eine sekundengenaue Gültigkeit.

Jede Abfrage sollte den Datenzeitpunkt und die Cache-Quelle protokollieren. Überschreitet ein Wert die erlaubte Aktualität, lautet der Status stale; das Modell bekommt den alten Betrag dann nicht als normalen Fakt. Bei Timeout, Wartung oder unvollständiger Antwort greift ebenfalls ein klarer Fallback. „Ich kann den aktuellen Bestand gerade nicht sicher abrufen“ ist besser als eine plausible, aber erfundene Zahl.

Für den Betrieb braucht es Kennzahlen: Anteil erfolgreicher Live-Abfragen, Zeitüberschreitungen, veraltete Antworten, Fallbacks, Übergaben und spätere Korrekturen. Häufen sich Fehler bei einer Produktgruppe, lässt sich so unterscheiden, ob Datenpflege, Schnittstelle oder Dialoglogik die Ursache ist.

Datenschutz und Zugriffsrechte klein halten

Öffentliche Preis- und Produktdaten benötigen in der Regel keine Kundendaten. Der Bot sollte daher nicht vorsorglich Namen, E-Mail-Adressen oder Bestellhistorien anfordern. Für individuelle Fragen wie „Wo ist meine Bestellung?“ ist ein separater, authentifizierter Prozess nötig. Die Orientierungshilfe der Datenschutzkonferenz zu KI und Datenschutz betont unter anderem klare Zwecke, Rechtsgrundlagen und die Prüfung, welche personenbezogenen Daten tatsächlich erforderlich sind.

Technisch bedeutet das: nur lesende API-Rechte, getrennte Schlüssel pro Umgebung, keine Zugangsdaten im Prompt und keine vollständigen Antwortdaten in frei zugänglichen Logs. Protokolle sollten Produkt-ID, Funktionsstatus und technische Laufzeit erfassen, aber unnötige Inhalte aus Nutzerfragen vermeiden. Die weiterführende Übersicht zur Wissensbasis, Datenminimierung und menschlichen Übergabe hilft bei der organisatorischen Einordnung.

Transparenz beim ersten Kontakt einbauen

Besucher müssen erkennen können, dass sie mit einem KI-System interagieren. Artikel 50 des EU AI Acts verlangt für Systeme, die direkt mit natürlichen Personen interagieren, grundsätzlich eine entsprechende Information, sofern dies nicht offensichtlich ist. Die Information soll spätestens beim ersten Kontakt klar, unterscheidbar und zugänglich erfolgen.

Die Leitlinien der EU-Kommission zu Transparenzpflichten erläutern die seit 2. August 2026 anwendbaren Vorgaben. Für einen Website-Chatbot ist eine knappe Kennzeichnung im geöffneten Dialog sinnvoll. Zusätzlich sollte der Bot deutlich machen, wann er Live-Daten abruft, wann eine Angabe nur eine Prognose ist und wie ein Mensch erreichbar ist. Eine lange Rechtserklärung ersetzt diese verständliche Orientierung nicht.

Ein umsetzbarer Workflow für KMU

  1. Anwendungsfälle priorisieren: Zuerst wenige häufige Fragen auswählen, etwa Preis, Bestand und Lieferfenster für Standardprodukte.
  2. Quellenregister freigeben: Für jedes Feld System, Verantwortliche, Einheit, Aktualität und Fallback dokumentieren.
  3. Lesende Funktionen bauen: Kleine serverseitige Endpunkte mit festen Parametern, Zeitlimits und eindeutigen Statuswerten bereitstellen.
  4. Antwortregeln festlegen: Zulässige Formulierungen für Preise, geringe Bestände, Prognosen und Ausfälle redaktionell prüfen.
  5. Daten minimieren: Öffentliche Produktabfragen strikt von authentifizierten Bestellprozessen trennen.
  6. Testfälle automatisieren: Varianten, Mengen, Aktionswechsel, leere Bestände, Timeout, veralteten Cache und falsche IDs prüfen.
  7. Menschliche Übergabe testen: Supportweg, Öffnungszeiten und übergebener Kontext müssen in Desktop- und Mobilansicht funktionieren.
  8. Überwacht starten: Zunächst begrenzte Produktgruppen freischalten, Fehlerquoten auswerten und erst danach erweitern.

Publish-Check für dynamische Chatbot-Antworten

  • Ist für Preis, Bestand und Lieferzeit jeweils genau eine verbindliche Quelle benannt?
  • Enthält jede API-Antwort Zeitstempel, Status und die nötigen Kontextfelder?
  • Kann das Modell nur freigegebene lesende Funktionen verwenden?
  • Werden Variante, Menge, Standort und Kundengruppe korrekt berücksichtigt?
  • Blockiert ein veralteter oder unvollständiger Wert die normale Antwort?
  • Gibt es für Timeout und Ausfall eine ehrliche, getestete Fallback-Formulierung?
  • Sind individuelle Bestelldaten durch Authentifizierung und getrennte Prozesse geschützt?
  • Ist der KI-Hinweis beim ersten Kontakt sichtbar und barrierefrei erreichbar?
  • Funktioniert die menschliche Übergabe auch auf Mobilgeräten und per Tastatur?
  • Ist dokumentiert, wer Datenquellen, Antwortregeln und Veröffentlichung freigegeben hat?

Fazit: Live-Daten brauchen klare Grenzen

Ein KI-Chatbot mit Live-Daten ist zuverlässig, wenn er aktuelle Fakten abruft, statt sie sprachlich zu erraten. Die entscheidenden Bausteine sind verbindliche Quellsysteme, begrenzte Funktionen, definierte Aktualität, getrennte Tests und ein ehrlicher Fallback. Preis, Bestand und Lieferzeit sollten nie allein aus einem alten Dokument oder aus der statistischen Plausibilität eines Sprachmodells stammen.

AdSimple kann mit der KI-Chatbot-Entwicklung Datenquellen, Dialoglogik, Transparenz, Übergaben und Qualitätskontrollen als zusammenhängenden Prozess planen. Der sinnvolle Einstieg ist klein: eine Produktgruppe, drei klar definierte Live-Funktionen und messbare Testfälle. Erst wenn diese Basis stabil arbeitet, sollten weitere Systeme oder individuelle Kundenvorgänge hinzukommen.

Quellen