Ein KI-Assistent im Chat ist ein Bauteil im Betrieb Ihrer Website und kein in sich geschlossenes Gerät. Er hängt an einer Wissensbasis, häufig an einer Warenwirtschaft oder einem Kalender, an einem Sprachmodell und an dem Skript, das ihn in die Seite lädt. Jede dieser Verbindungen kann langsam werden oder ausbleiben. In der Jahresauswertung des Uptime Institute gaben 57 Prozent (Uptime Institute) der befragten Betreiber an, dass ihr letzter größerer Ausfall mehr als 100.000 US-Dollar gekostet hat, und jeder fünfte (Uptime Institute) nannte Kosten oberhalb einer Million. Die eigentliche Frage lautet deshalb nicht, ob es einen schlechten Tag gibt, sondern was Ihre Besucherin an diesem Tag im Chatfenster liest. Dieser Beitrag beschreibt die Stufen, in denen ein Assistent zurückfällt, den Ersatzweg, den er dabei sichtbar macht, und das, was hinterher im Protokoll steht.
Das Wichtigste in Kürze
- Ausfall ist selten ein Ganz-oder-gar-nicht. Häufiger ist der Teilausfall: Die Wissensbasis antwortet, das angebundene Warenwirtschaftssystem nicht. Ein Assistent braucht deshalb Stufen und keinen einzelnen Schalter.
- Zeitüberschreitung ist eine Entscheidung, keine Panne. 0,1 Sekunden, 1 Sekunde und 10 Sekunden (Nielsen Norman Group) sind seit Jahrzehnten die Grenzen der Wahrnehmung. Wer bis Sekunde 30 wartet, hat den Gast in der Regel längst verloren.
- Der Ersatzweg gehört ins Chatfenster, nicht auf eine Statusseite. 62 Prozent (Bitkom) der Online-Shopper wollen im Problemfall eine schnell erreichbare Person, 52 Prozent (Bitkom) einen E-Mail-Weg und 40 Prozent (Bitkom) einen Rückruf über die Website.
- Jeder Vorfall wird protokolliert: Zeitpunkt, Dauer, Stufe, Auslöser und der Ersatzweg, den der Gast gesehen hat. Ohne diese Aufzeichnung bleibt jede spätere Verbesserung eine Vermutung.
Was Ausfall beim Chat-Assistenten wirklich heißt
Wer von Ausfall spricht, denkt meistens an eine weiße Seite. Im Alltag eines Chat-Assistenten sieht die Störung anders aus. Die Wissensbasis antwortet, aber das angebundene Lagersystem braucht zwölf Sekunden. Das Sprachmodell liefert, aber der Kalender meldet einen Fehler. Das Widget lädt, allerdings erst, nachdem der Besucher weitergeklickt hat. Ein Assistent besteht aus mehreren Diensten, und die fallen selten gemeinsam aus. Genau deshalb führt die binäre Frage "läuft er oder läuft er nicht" in die Irre. Die brauchbare Frage lautet: Welcher Teil fehlt gerade, und was kann der Assistent ohne diesen Teil noch verantworten?
Die Abhängigkeit von fremden Bestandteilen ist dabei kein Sonderfall dieser Anwendung, sondern der Normalzustand im Web. Nach der Auswertung des HTTP Archive binden 90 bis 92 Prozent (Web Almanac 2025) der untersuchten Seiten mindestens eine Ressource von einem fremden Anbieter ein, und die mittlere Seite kommt auf 79 Fremdanfragen (Web Almanac 2025) auf dem Mobilgerät. Jede davon ist eine Stelle, die langsam werden kann. Für den Assistenten heißt das: Er wird auf einer Seite geladen, die selbst schon eine Kette von Abhängigkeiten hat, und er darf diese Kette nicht verlängern, ohne einen Plan für den Fall zu haben, dass ein Glied fehlt. Wie ein Assistent technisch sauber in Seite und Shop kommt, steht im Beitrag zur Einbindung in Website und Shop.
Kurz erklärt: Verfügbarkeit, Rückfallebene, Wartungsfenster
Zeitüberschreitung: ab wann der Assistent aufhören muss zu warten
Die Grenzen menschlicher Geduld sind gut untersucht und seit Jahrzehnten stabil. 0,1 Sekunden (Nielsen Norman Group) sind die Schwelle, bis zu der eine Reaktion als unmittelbar empfunden wird. Bis 1 Sekunde (Nielsen Norman Group) bleibt der Gedankenfluss des Nutzers erhalten, auch wenn die Verzögerung bemerkt wird. Bei 10 Sekunden (Nielsen Norman Group) reißt die Aufmerksamkeit ab, und der Nutzer wendet sich anderen Dingen zu. Jakob Nielsen hat diese drei Grenzen 1993 zusammengefasst, und sie beruhen auf noch älteren Untersuchungen. Genau deshalb sind sie belastbar: Sie beschreiben Wahrnehmung, nicht Technik. Für den Chat bedeutet das, dass eine Antwort nach 25 Sekunden auch dann verloren ist, wenn sie fachlich genau stimmt.
Auf der technischen Seite gibt es Richtwerte, an denen sich ein Zeitbudget ausrichten lässt. Als gute Serverantwortzeit gelten 800 Millisekunden (web.dev) bis zum ersten Byte. Erreicht wird dieser Wert längst nicht überall: Nur 44 Prozent (Web Almanac 2025) der mobil gemessenen Websites lagen zuletzt im guten Bereich. Wer sein Zeitbudget an solchen Zahlen ausrichtet, kommt zu einer einfachen Regel: Die Seite hat ein Budget, der Assistent hat ein eigenes, und jedes angebundene System bekommt eines, das kleiner ist als das des Assistenten. Nur dann kann eine träge Abfrage die Antwort nicht mehr komplett aufhalten.
- Bis 1 Sekunde: Die Eingabe wird sichtbar angenommen, der Assistent zeigt, dass er arbeitet. Ohne dieses Zeichen wirkt jedes weitere Warten wie ein Defekt.
- Bis 3 Sekunden: Die erste Antwort beginnt. Dauert es länger, erscheint ein Satz im Gesprächsverlauf, nicht bloß ein stiller Ladepunkt.
- Bis 5 Sekunden je Fremdsystem: Lagerbestand, Kalender oder Auftragsstatus bekommen ein eigenes, hartes Limit. Läuft es ab, antwortet der Assistent ohne diese Angabe und sagt das auch.
- Bis 8 Sekunden: Der Assistent wechselt auf die Wissensbasis und verzichtet auf alles, was er nur mit Livedaten belegen könnte.
- Ab 20 Sekunden: Das Gespräch wird auf den Ersatzweg gelenkt. Der Gast bekommt ein Formular, einen Rückrufwunsch oder die Adresse, unter der Ihr Team direkt erreichbar ist.
- Bei jeder überschrittenen Grenze: ein Protokolleintrag mit Stufe, Dauer und betroffenem System, damit die Ursache später auffindbar bleibt.
Wichtig ist die Reihenfolge dieser Grenzen. Ein einziger Zeitwert für das ganze Gespräch führt dazu, dass eine langsame Lagerabfrage die gesamte Antwort blockiert, obwohl der Assistent neunzig Prozent der Frage längst beantworten könnte. Getrennte Budgets je angebundenem System drehen das um: Der Assistent liefert, was er hat, und benennt sauber, was gerade fehlt. Welche Aufrufe er dabei überhaupt absetzt und wie diese Aufrufe abgesichert werden, beschreibt der Beitrag zur Steuerung von Tools per Function Calling.
Stufe 0: Normalbetrieb
Wissensbasis, Sprachmodell und angebundene Systeme antworten im Budget. Der Assistent arbeitet ohne Einschränkung und ohne Hinweis an den Gast.
Stufe 1: Verzögerte Antwort
Eine Quelle ist langsam. Der Assistent kündigt die Verzögerung im Verlauf an, statt den Gast auf einen Ladepunkt starren zu lassen.
Stufe 2: Ohne Fremdsystem
Lager, Kalender oder Auftragsstatus sind nicht erreichbar. Der Assistent antwortet fachlich weiter und kennzeichnet die fehlende Livedatenlage.
Stufe 3: Nur Wissensbasis
Es bleibt der geprüfte Bestand. Jede Antwort trägt eine Fundstelle, es wird nichts geschätzt und nichts zugesagt, was nicht belegt ist.
Stufe 4: Formular statt Chat
Der Chat nimmt Anliegen entgegen und leitet sie weiter, ohne selbst zu antworten. Der Gast erhält eine Bestätigung mit Zeitrahmen.
Stufe 5: Stiller Rückzug
Lädt selbst das Widget nicht, bleibt die Seite vollständig bedienbar. Kontaktweg und Formular stehen unabhängig vom Assistenten in der Seite.
Der sichtbare Ersatzweg statt der stillen Störung
Ein Assistent, der still ausfällt, ist unangenehmer als einer, der ehrlich weniger kann. Der Besucher weiß nicht, ob er sich vertippt hat, ob die Seite hakt oder ob er warten soll. Deshalb gehört zu jeder Stufe ein Satz, der im Gesprächsverlauf steht, und ein Weg, den man anklicken kann. Die Zahlen aus dem Kundenservice geben die Reihenfolge vor: 62 Prozent (Bitkom) der Online-Shopper wenden sich im Problemfall am liebsten an eine schnell erreichbare Person, 52 Prozent (Bitkom) wünschen sich einen E-Mail-Service, 40 Prozent (Bitkom) einen Rückruf, den sie über die Website anfordern können, und 28 Prozent (Bitkom) greifen auf eine FAQ zurück. Der Notbetrieb sollte genau diese vier Wege anbieten, in dieser Rangfolge.
- Was gerade fehlt, in einem Satz und ohne Fachbegriff: "Der Lagerbestand lässt sich im Moment nicht abrufen."
- Was trotzdem geht: "Zu Maßen, Lieferzeiten und Zubehör kann ich weiter Auskunft geben."
- Der Ersatzweg als Schaltfläche: Formular, Rückrufwunsch oder die Adresse, die auch ohne Chat funktioniert.
- Ein Zeitrahmen für die Antwort: kein Versprechen, sondern die übliche Bearbeitungszeit Ihres Teams.
- Der Hinweis, dass der bisherige Gesprächsverlauf mitgeht, damit der Gast nichts zweimal erzählen muss.
- Bei einer Wartung zusätzlich das Ende des Fensters mit Uhrzeit, damit der Besucher entscheiden kann, ob er wartet oder den Ersatzweg nimmt.
Der Ersatzweg braucht denselben Datenschutzrahmen wie der Chat selbst. Wenn der Assistent im Notbetrieb eine E-Mail-Adresse oder eine Rufnummer aufnimmt, gelten die gleichen Anforderungen wie im Normalbetrieb: Zweck, Rechtsgrundlage und, wo nötig, eine Einwilligung. Wie das sauber gelöst wird, zeigt der Beitrag zur Einwilligung bei Kontaktdaten im Chat. Wo die Daten dabei liegen und wer sie verarbeitet, beantwortet unsere Seite zu Datenschutz und Hosting. Beides ändert sich im Notbetrieb nicht, auch wenn es an diesem Tag umständlicher wirkt.
Der Notbetrieb ist kein kleinerer Chat, sondern ein anderes Versprechen
Wartungsfenster planen und rechtzeitig ankündigen
Der geplante Ausfall ist der einzige, den Sie vollständig in der Hand haben. Er gehört deshalb nicht in die Kategorie Störung, sondern in den Kalender. Ein Wartungsfenster für den Assistenten unterscheidet sich von dem der Website: Es darf kürzer sein, es sollte in die Randzeiten Ihres Publikums fallen, und es braucht eine eigene Ankündigung im Chatfenster, weil die wenigsten Besucher eine Statusseite aufrufen. Praktisch bewährt hat sich ein Hinweis 24 Stunden vorher im Chat, ein zweiter beim Öffnen des Fensters während der Wartung und eine kurze Rückmeldung an alle, die im Fenster ein Anliegen hinterlassen haben.
Für die Planung hilft die Auswertung der eigenen Gespräche. Wann kommen die meisten Anfragen, welche Themen sind zeitkritisch, welcher Wochentag ist ruhig? Eine Auswertung der geführten Gespräche beantwortet das genauer als das Bauchgefühl, und wie man sie liest, zeigt der Beitrag zur Gesprächsanalyse. Sie zeigt außerdem, welche Fragen im Wartungsfenster gestellt worden wären. Genau daraus entsteht die Liste der Antworten, die der Notbetrieb vorhalten sollte.
| Situation | Ohne Betriebskonzept | Mit gestuftem Rückfall |
|---|---|---|
| Fremdsystem antwortet spät | Gespräch bleibt stehen, der Gast klickt weg | Antwort ohne Livedaten, Hinweis im Verlauf |
| Wissensbasis nicht erreichbar | Assistent antwortet frei und rät | Chat nimmt das Anliegen auf, ohne fachlich zu antworten |
| Geplante Wartung | Widget verschwindet ohne Erklärung | Angekündigtes Fenster mit Endzeit und offenem Formular |
| Gast möchte eine Person sprechen | Kontaktweg steht nur im Impressum | Rückruf und E-Mail direkt im Chatfenster |
| Nach dem Vorfall | Die Zahl der Betroffenen bleibt unbekannt | Protokoll mit Zeitpunkt, Dauer, Stufe und Anzahl |
| Wiederholung | Gleiche Ursache im nächsten Quartal | Auslöser dokumentiert, Grenzwert nachgezogen |
Übergabe an den Menschen: die Störung ist ein eigener Auslöser
Wann ein Assistent an eine Person übergeben sollte, ist ein eigenes Thema, und die inhaltlichen Auslöser haben wir in Übergabe an Mitarbeiter beschrieben: die ausdrückliche Bitte, erkennbarer Frust, zwei erfolglose Antworten, geringe Antwortsicherheit. Die technische Störung kommt als eigener Auslöser dazu, und sie funktioniert anders. Bei den inhaltlichen Auslösern entscheidet der Gesprächsverlauf. Bei der Störung entscheidet ein Messwert, den der Gast gar nicht kennt. Beide Wege führen zur selben Person, aber sie brauchen unterschiedliche Sätze und unterschiedliche Eskalation.
Der teuerste Ausfall ist der, den niemand bemerkt hat, weil das Chatfenster freundlich weiter geantwortet hat. Ein Assistent, der im Notbetrieb schweigt und den Kontaktweg zeigt, kostet weniger als einer, der rät.
Daraus folgt eine praktische Regel: Die Übergabe bei technischer Störung darf nicht auf die Besetzung Ihres Teams warten. Ist niemand erreichbar, wird das Anliegen aufgenommen und mit Zeitrahmen bestätigt. Wie man Frustsignale von echten Störungen unterscheidet, zeigt der Beitrag zum Erkennen von Frust im Chat: Ein verärgerter Gast braucht zuerst eine Person, ein technisch gestörtes Gespräch braucht zuerst einen funktionierenden Ersatzweg. Dass es sich lohnt, den menschlichen Weg offenzuhalten, zeigt dieselbe Erhebung, aus der die Zahlen oben stammen: 86 Prozent (Bitkom) der Befragten sind mit dem Kontakt zu einer menschlichen Ansprechperson zufrieden.
Protokollieren, was tatsächlich passiert ist
Nach dem Vorfall beginnt der Teil, der über die nächste Störung entscheidet. Was wurde gemessen, wie lange hat es gedauert, welche Stufe war aktiv, wie viele Gespräche waren betroffen, und was hat der Gast dabei gesehen? Diese fünf Angaben ergeben zusammen ein Bild. Fehlt eine davon, bleibt die Nachbereitung eine Erzählung. Das Protokoll gehört dabei getrennt vom Gesprächsinhalt geführt: Der Betriebseintrag braucht Zeitpunkt, Stufe und System, aber nicht den Wortlaut der Nachricht. Diese Trennung erleichtert später auch die Auskunft gegenüber Betroffenen, weil Betriebsdaten und Inhalte nicht vermischt sind.
Der Betrieb einer solchen Anwendung ist zudem ein Sicherheitsthema und kein reines Verfügbarkeitsthema. Das Bundesamt für Sicherheit in der Informationstechnik zählt für seinen Berichtszeitraum durchschnittlich 119 neue Schwachstellen (BSI) pro Tag in Softwareprodukten. Ein Teil der Vorfälle, die als Störung beginnen, endet als Sicherheitsthema, und umgekehrt. Das Protokoll ist in beiden Fällen dieselbe Quelle. Wer Angriffsversuche auf den Assistenten selbst einordnen möchte, findet die Grundlagen in Prompt Injection absichern.
Übungsausfall: einmal im Quartal einen Stecker ziehen
Der Einstieg: ein Betriebskonzept auf zwei Seiten
Ein Notbetriebskonzept muss kein Handbuch sein. Zwei Seiten reichen, wenn sie die richtigen Fragen beantworten: Welche Systeme hängen dran, welches Zeitbudget hat jedes, welche Stufe folgt auf welchen Zustand, welcher Satz steht dann im Chatfenster, und wer bekommt Bescheid. Der Aufwand liegt selten in der Technik, sondern in der Entscheidung, was der Assistent im eingeschränkten Zustand noch sagen darf. Diese Entscheidung trifft das Fachteam, nicht die Entwicklung. Ein Assistent für den Support ist dabei anders zu behandeln als einer, der Anfragen qualifiziert: Beim Support ist die falsche Auskunft das größere Risiko, bei der Anfrage der verlorene Kontakt.
Wie viel technische Tiefe dabei nötig ist, hängt vom Umfang der Anbindungen ab. Ein Assistent, der nur auf einer Wissensbasis steht, hat zwei Stufen und ist in einem Nachmittag beschrieben. Einer, der Aufträge, Termine und Bestände über Schnittstellen zieht, braucht je Anbindung eine eigene Zeile. Der Rückenwind ist da: 41 Prozent (Bitkom) der Unternehmen ab 20 Beschäftigten setzen KI bereits ein, weitere 48 Prozent (Bitkom) planen oder diskutieren den Einsatz. Mit der Verbreitung wächst allerdings auch die Erwartung an den Betrieb. Ein Assistent, der im ersten Jahr als Versuch gilt, ist im zweiten Jahr ein Kanal, dessen Ausfall auffällt. Wer die Rückfallebenen erst dann baut, baut sie unter Druck.
- Abhängigkeiten auflisten: Wissensbasis, Sprachmodell, Warenwirtschaft, Kalender, Ticketsystem, Auslieferung des Widgets
- Je Abhängigkeit ein Zeitbudget festlegen, das kleiner ist als das Budget des Gesamtgesprächs
- Die Stufen 0 bis 5 schriftlich festhalten, mit dem Leistungsumfang, den jede Stufe noch verantwortet
- Je Stufe den Satz formulieren, der im Chatfenster erscheint, und ihn vom Fachteam freigeben lassen
- Ersatzweg einrichten, der unabhängig vom Assistenten funktioniert: Formular, Rückruf und Adresse
- Wartungsfenster in die Randzeiten legen und mindestens einen Tag vorher im Chat ankündigen
- Protokollfelder festlegen: Zeitpunkt, Dauer, Stufe, Auslöser, betroffene Gespräche, gezeigter Ersatzweg
- Einmal im Quartal einen Übungsausfall fahren und das Ergebnis in die Grenzwerte zurückspielen
Quellen und Studien