Sobald ein Support-Team über einen AI-Agenten nachdenkt, kommt die Datenfrage meistens vor der Effizienzfrage, und zu Recht: Bevor ein System überhaupt Antworten formulieren darf, muss klar sein, was es dafür lesen darf und wohin diese Information danach fließt. Wir beschreiben das hier anhand eines laufenden Falls bei Essential Bag, wo ein Agent auf Basis von Zendesk-Tickets Antwortentwürfe erstellt.
Diese Reihenfolge, erst die Daten, dann die Zeitersparnis, ist bewusst gewählt und nicht nur diesem Artikel geschuldet. In jedem Kickoff mit einem neuen Support-Projekt klären wir zuerst, welche Systeme überhaupt beteiligt sind und wer im Unternehmen die Datenschutz-Verantwortung dafür trägt, bevor ein einziger Prompt geschrieben wird. Das kostet am Anfang etwas Zeit, spart aber genau die Diskussion, die sonst mitten im Projekt aufkommt, wenn plötzlich jemand fragt, wo die Kundendaten eigentlich landen.
Was in diesem Artikel steht, und was nicht
Essential Bag ist bereits als Kunde dokumentiert, mit einem AI-Agenten, der Support-Antworten auf Basis von Shopify-Daten vorschlägt, öffentlich als Case Study auf dieser Website. Die hier beschriebene Zendesk-Integration ist ein weiterer, aktuellerer Baustein derselben Zusammenarbeit. Für sie liegt bislang keine freigegebene Kennzahl zu Zeitersparnis oder Ticketvolumen vor, deshalb steht in diesem Artikel keine. Was folgt, ist eine Beschreibung des Mechanismus und des Datenwegs, nicht eine Erfolgsgeschichte mit Zahl.
Der Fall: Essential Bag und Zendesk
Essential Bag nutzt Zendesk als Ticketsystem für den Kundenservice. Läuft ein neues Ticket ein, braucht das Support-Team Kontext, um es zu beantworten: Was hat die Person zuvor geschrieben, welche öffentlichen Kommentare gab es bereits, was ist über die Bestellung bekannt. Bisher musste diese Vorgeschichte bei jedem Ticket manuell zusammengesucht werden. Der Agent übernimmt genau diesen Schritt: Er sammelt die relevante Vorgeschichte und legt sie dem Support als Zusammenfassung bereit.
Diese Art von Aufgabe eignet sich besonders gut für einen Agenten, weil sie zwei Eigenschaften kombiniert: Sie kommt oft genug vor, dass sich der Aufbau lohnt, und ein falsches Ergebnis fällt vor dem Versand auf, weil ein Mensch die Zusammenfassung ohnehin liest. Wo diese zweite Eigenschaft fehlen würde, etwa bei einer direkt automatisiert verschickten Antwort, wäre unsere Einschätzung eine andere, wie der Abschnitt weiter unten zeigt.
Der Datenweg, Schritt für Schritt
Der Flow läuft in einer festen Reihenfolge, ohne Umweg über ein System, das im Prozess nichts verloren hätte.
- Ein Ticket kommt in Zendesk an, ausgelöst durch eine Kundenanfrage
- Der Agent ruft die letzten Tickets derselben Person und die dazugehörigen öffentlichen Kommentare ab
- Diese Vorgeschichte wird an ein Sprachmodell zur Zusammenfassung übergeben
- Die Zusammenfassung wird als Kontext zurück ans Ticket gehängt, sichtbar für den Support
- Ein Mitarbeitender liest Ticket und Zusammenfassung, formuliert oder bestätigt die Antwort und sendet sie ab
Wo Kundendaten das System verlassen, und wo nicht
Für ein Support-Team ist die entscheidende Grenze nicht "wird KI genutzt", sondern welche Systeme die Daten überhaupt sehen. In diesem Flow sind das genau zwei: Zendesk als Quelle der Ticketdaten und der Sprachmodell-Anbieter, der die Zusammenfassung erstellt. Kein drittes System bekommt die Daten zu sehen, und die Verarbeitung beim Modell-Anbieter läuft über eine vertragliche Grundlage, die eine Nutzung der Daten zum Training des Modells ausschließt.
Das ist bewusst so knapp gehalten, weil jedes zusätzliche System eine zusätzliche Stelle ist, an der etwas schiefgehen kann, sei es ein falsch konfigurierter Zugriff oder eine vergessene Löschfrist. Ein Flow mit zwei beteiligten Systemen lässt sich vollständig auf einem Blatt Papier skizzieren und im Team durchsprechen. Ein Flow mit sechs oder acht Systemen dazwischen kann das kaum noch jemand aus dem Kopf erklären, und was niemand erklären kann, lässt sich auch nicht verlässlich absichern.
- Zendesk bleibt die alleinige Quelle für Ticket- und Kommentardaten
- Der Sprachmodell-Anbieter verarbeitet die Daten nur für die konkrete Anfrage, nicht für eigenes Training
- Kein zusätzliches Drittsystem erhält im Rahmen dieses Flows Zugriff auf Kundendaten
- Die fertige Zusammenfassung bleibt im Ticket selbst, nicht in einer separaten Datenbank außerhalb von Zendesk
Warum der Mensch den Senden-Klick behält
Der Agent liefert eine Zusammenfassung und einen Antwortvorschlag, er sendet nie selbst an einen Kunden. Der Grund ist derselbe wie bei jedem anderen Support-Agenten, den wir gebaut haben: Eine falsche interne Zusammenfassung fällt im Zweifel niemandem auf, eine falsche Antwort an einen Kunden schon, und zwar sofort. Solange dieser Unterschied besteht, bleibt die Freigabe beim Menschen, unabhängig davon, wie gut die Zusammenfassungen im Alltag bereits funktionieren.
Diese Entscheidung ist keine technische Notlösung, sondern bewusst so angelegt. Selbst wenn ein Agent über Monate hinweg zuverlässig richtige Zusammenfassungen liefert, ändert das nichts an der Konsequenz eines einzelnen Ausreißers, der an einen Kunden geht, statt intern aufzufallen. Der Aufwand, jede Antwort zu lesen, ist gemessen an diesem Risiko klein, und genau diese Abwägung sollte jedes Team für den eigenen Anwendungsfall selbst treffen, statt sie von der Technik vorgeben zu lassen.
Das gilt auch mit Blick auf die EU-KI-Verordnung: Systeme, die mit Personen interagieren, unterliegen eigenen Transparenzpflichten. Ein Agent, der im Hintergrund Kontext zusammenfasst und den ein Mensch vor dem Versand prüft, ist datenschutzrechtlich eine andere Kategorie als ein Chatbot, der direkt mit einer Kundin oder einem Kunden spricht. Diese Unterscheidung lohnt sich, bevor man den eigenen Anwendungsfall rechtlich einordnet.