KI-Chatbots im Kundenservice: Transparenz, Rollen und Eskalation richtig gestalten

Nicht jeder Kundenservicebot ist hochriskant

Ein Bot, der Öffnungszeiten nennt, einen Bestellstatus abfragt oder Supportartikel auffindbar macht, fällt nicht allein wegen seiner Kundennähe in die Hochrisikokategorie. Die Klassifikation richtet sich nach konkreter Zweckbestimmung und Einsatzmodalität. Ein Hochrisikofall kann entstehen, wenn der Bot einen konkret in Anhang III genannten Zweck erfüllt, etwa die Anspruchsberechtigung für wesentliche öffentliche Unterstützungsleistungen bewertet, die Kreditwürdigkeit natürlicher Personen beurteilt oder Risiken und Preise in der Lebens- und Krankenversicherung bewertet. Eine beliebige Entscheidung über einen privaten Dienst genügt dafür nicht.

Agent Assist und autonomer Entscheidungsbot sind deshalb getrennt zu dokumentieren. Ein Antwortvorschlag, den eine geschulte Servicekraft anhand verlässlicher Unterlagen wirklich prüft, hat ein anderes Risikoprofil als eine automatisierte verbindliche Leistungsentscheidung. Die Bezeichnung Assistenz beweist jedoch nichts: Wenn Mitarbeitende Vorschläge aus Zeitdruck regelmäßig übernehmen oder keine ausreichenden Informationen zur Kontrolle erhalten, kann der tatsächliche Einfluss wesentlich sein.

• Informationsbot und Entscheidungsbot getrennt erfassen
• Zweck, Output und Folgen einer Fehlantwort beschreiben
• Tatsächliche statt nur formale menschliche Kontrolle prüfen

Quellen: [1] [2]

Transparenz bei der ersten Interaktion

Artikel 50 Absatz 1 verpflichtet den Anbieter eines Systems zur direkten Interaktion mit natürlichen Personen grundsätzlich dazu, das System so zu gestalten, dass Betroffene erkennen können, mit einem KI-System zu kommunizieren. Die Information muss spätestens bei der ersten Interaktion klar und unterscheidbar erfolgen. Sie kann entfallen, wenn dies aus Sicht einer angemessen informierten, aufmerksamen und verständigen Person aufgrund der Umstände und des Nutzungskontexts offensichtlich ist.

In der Praxis sollte die Oberfläche nicht erst in langen Bedingungen verstecken, dass ein Bot antwortet. Bei Voicebots ist eine verständliche Ansage sinnvoll; bei Chats ein sichtbarer Hinweis neben dem Einstieg. Anbieterpflicht und Betreiberkommunikation müssen vertraglich und technisch zusammenpassen. Die Transparenzinformation ist keine datenschutzrechtliche Einwilligung und schafft keine Rechtsgrundlage für die Verarbeitung personenbezogener Daten. Weitere Informationspflichten bleiben daneben bestehen.

• Hinweis spätestens bei der ersten Interaktion platzieren
• Klarheit für Text- und Sprachkanäle gesondert testen
• Transparenz nicht mit Datenschutz-Rechtsgrundlage verwechseln

Quellen: [1] [3] [5]

Rollenmodell für SaaS und White Label

Beim üblichen Standard-SaaS ist Anbieter, wer den Bot entwickelt oder entwickeln lässt und ihn unter eigenem Namen oder eigener Marke in Verkehr bringt oder in Betrieb nimmt; das einsetzende Unternehmen ist typischerweise Betreiber. Eigenentwicklung, Vermarktung unter eigenem Namen, eine erhebliche Zweckänderung oder eine wesentliche technische Änderung kann die Rollenverteilung verändern. White Label bedeutet daher nicht automatisch, dass jede Anbieterpflicht übergeht, ist aber ein klares Signal für eine vertiefte Rollenprüfung.

Verträge sollten Zweckbestimmung, unterstützte Sprachen, Wissensquellen, Modellversionen, Protokollierung, Sicherheitsmaßnahmen und Änderungsankündigungen abdecken. Der Betreiber braucht Informationen, um Antworten zu kontrollieren, Beschwerden zu untersuchen und neue Funktionen vor Aktivierung zu bewerten. Subunternehmer, Datenstandorte und die Nutzung von Gesprächsdaten für Training sind gesondert zu klären. Pauschale Anbieterzusagen ersetzen weder die Rollenakte noch eigene Plausibilitätsprüfungen.

• Anbieter und Betreiber je Kanal bestimmen
• Rebranding, Zweckänderung und wesentliche Änderung prüfen
• Informations- und Änderungsrechte vertraglich sichern

Quellen: [1] [2] [4]

Eskalation als Bestandteil des Service Designs

Ein menschlicher Kanal sollte erreichbar sein, wenn der Bot die Anfrage nicht versteht, eine verbindliche Entscheidung betrifft, sensible Daten berührt oder die Kundin beziehungsweise der Kunde widerspricht. Wie schnell und über welchen Weg eskaliert wird, hängt von Dringlichkeit und möglichem Schaden ab. Ein bloßer Endlosdialog oder eine versteckte Kontaktmöglichkeit kann Transparenz und fairen Zugang praktisch entwerten, selbst wenn formal ein Mensch verfügbar wäre.

Der Bot braucht klare Grenzen: keine erfundenen Vertragsbedingungen, keine Zusagen außerhalb freigegebener Quellen und keine Umgehung von Identitäts- oder Sicherheitsprüfungen. Wissensquellen sind versioniert zu pflegen; risikoreiche Antworten können Vorlagen, Quellenhinweise oder verpflichtende menschliche Freigabe benötigen. Beschwerden, Abbrüche, Übersteuerungen und wiederkehrende Fehlantworten sollten ausgewertet werden, um Schwellen, Inhalte und Weiterleitung zu verbessern.

• Menschlichen Kanal sichtbar und erreichbar gestalten
• Verbindliche oder sensible Fälle gezielt eskalieren
• Fehlantworten und Übersteuerungen als Qualitätssignale nutzen

Quellen: [3] [4]

Datenschutz, Sicherheit und Verbraucherrecht

Servicegespräche können Kontaktdaten, Vertragsnummern, Zahlungsinformationen oder besondere Kategorien personenbezogener Daten enthalten. Erforderlichkeit, Rechtsgrundlage, Information, Aufbewahrung und Zugriffe sind für Gesprächsinhalte und Protokolle zu bestimmen. Freitextfelder erhöhen das Risiko unnötiger Eingaben; gezielte Hinweise und technische Filter können helfen. Besonders sensible Angaben sollten nur über dafür freigegebene, angemessen gesicherte Wege verarbeitet werden.

Prompt Injection, manipulierte Wissensquellen und unberechtigte Datenabfragen sind keine rein technischen Randthemen. Berechtigungen, getrennte Datenbestände, sichere Schnittstellen und Tests gegen Missbrauch gehören in das Kontrollkonzept. Daneben sind Konsumentenschutz, Fernabsatzrecht und sektorspezifische Informationspflichten zu beachten. Ein Bot darf gesetzlich erforderliche Informationen nicht verkürzen und keine irreführende Sicherheit über Preise, Rechte oder Leistungsumfang erzeugen.

• Datenarten und Speicherfristen pro Kanal festlegen
• Schnittstellen und Wissensquellen gegen Manipulation schützen
• Verbraucher- und Sektorpflichten neben dem AI Act prüfen

Quellen: [5] [4]

Betrieb überwachen und Änderungen steuern

Vor dem Start sind realistische Dialogtests in allen vorgesehenen Sprachen und für typische Grenzfälle erforderlich. Zu beobachten sind unter anderem falsche Zusagen, Eskalationsquote, Abbrüche, Beschwerden, Sicherheitsereignisse und Unterschiede zwischen Nutzergruppen. Kennzahlen brauchen Kontext: Eine hohe Eskalationsquote kann bei komplexen Fällen gerade erwünscht sein. Stichproben müssen sich auf tatsächlich risikoreiche Antworten konzentrieren und dürfen nicht nur einfache Standardfragen messen.

Neue Modelle, Wissensquellen, Plug-ins oder Entscheidungsfunktionen können Zweck, Datenfluss und Risikoklasse verändern. Deshalb braucht jede wesentliche Änderung eine erneute fachliche, rechtliche und technische Freigabe. Fällt der konkrete Zweck unter Anhang III, gelten die spezifischen Hochrisikopflichten grundsätzlich ab 2. Dezember 2027. Bereits geltende Transparenz-, Datenschutz- und Verbraucherpflichten dürfen nicht bis dahin aufgeschoben werden.

• Vor Produktivstart Grenzfälle und Sprachen testen
• Kennzahlen risikobasiert und kontextbezogen auswerten
• Änderungen vor Aktivierung neu klassifizieren

Quellen: [1] [2] [3]

Häufige Fragen