KI-Agent im Kundenservice einführen: Vom Anwendungsfall zum Pilotprojekt

KI-Agenten versprechen schnellere Antworten und Entlastung im Kundenservice. Ob ein Pilotprojekt tatsächlich hilft, entscheidet sich aber lange vor der Auswahl eines Modells: beim richtigen Anwendungsfall, verlässlichem Wissen und klaren Grenzen für eigenständige Aktionen. Dieser Leitfaden zeigt, wie Unternehmen Schritt für Schritt vom Problem zum kontrollierten Pilotbetrieb gelangen.

1. Mit einem Serviceproblem beginnen

Der Wunsch nach einem KI-Agenten ist noch kein Anwendungsfall. Besser ist eine konkrete Frage: Welche Anliegen landen häufig im Service, wie werden sie heute bearbeitet und an welchen Stellen entstehen Wartezeiten? Beispiele sind Fragen zu Lieferstatus, Vertragsunterlagen oder der zuständigen Ansprechperson. Nicht jede dieser Aufgaben muss ein Agent übernehmen: Ein gut gepflegter FAQ-Bereich oder eine einfache Statusabfrage kann bereits genügen.

Sichten Sie zunächst Anfragen aus verschiedenen Kanälen und beziehen Sie das Serviceteam ein. Mitarbeitende wissen häufig, welche Fälle einfach aussehen, in der Praxis aber Ausnahmen enthalten. Achten Sie bei der Analyse auf datenschutzgerechte Aufbereitung und betrachten Sie neben dem Volumen auch die Folgen einer falschen Antwort. Ein häufiges Anliegen mit überschaubarem Risiko und einer klaren Wissensgrundlage ist oft ein besserer Einstieg als ein komplexer Reklamationsprozess.

Formulieren Sie das Ziel messbar: etwa Anfragen zu einem bestimmten Lieferprozess schneller beantworten und gleichzeitig die Antwortqualität halten. Legen Sie auch fest, was außerhalb des Projekts bleibt. Eine Bestandsaufnahme der Datenbasis für KI-Agenten hilft dabei, fehlende Zuständigkeiten und veraltete Informationen früh zu erkennen.

2. Chatbot und KI-Agent voneinander abgrenzen

Ein regelbasierter Chatbot führt häufig durch vorgegebene Dialoge. Ein generativer Assistent formuliert Antworten beispielsweise auf Grundlage freigegebener Dokumente. Ein KI-Agent kann darüber hinaus – je nach Architektur und Berechtigung – Werkzeuge nutzen, Informationen aus Systemen abrufen und mehrere Schritte ausführen. Die Begriffe werden am Markt unterschiedlich verwendet; entscheidend sind deshalb die konkreten Fähigkeiten und Rechte des Systems.

Ein Agent, der Öffnungszeiten erklärt, benötigt keinen Zugriff auf Kundendaten. Soll er dagegen den Status einer Bestellung abrufen, braucht er eine verlässliche Identitätsprüfung und einen begrenzten Zugang zum zuständigen System. Eine Stornierung wäre ein weiterer Schritt mit anderen Risiken. Trennen Sie daher Auskunft, Datenabruf und Änderungen bewusst voneinander.

Im ersten Pilot kann ein Assistent Antworten vorschlagen, die Mitarbeitende prüfen. Erst wenn Qualität, Berechtigungen und Übergaben funktionieren, lässt sich über zusätzliche Automatisierung entscheiden. Menschliche Kontrolle sollte bei unklaren Fällen und folgenreichen Aktionen nicht erst nach einem Fehler einsetzen.

3. Den ersten Anwendungsfall auswählen

Bewerten Sie mögliche Prozesse mit einer einfachen Matrix. Vier Fragen sind besonders hilfreich:

• Volumen: Wie häufig tritt das Anliegen tatsächlich auf, und wie schwankt es saisonal?
• Wissen und Daten: Gibt es aktuelle, freigegebene Quellen und eindeutige Verantwortliche?
• Komplexität: Wie viele Ausnahmen, Rückfragen und Systeme sind beteiligt?
• Fehlerrisiko: Was passiert bei einer falschen Antwort, einer Datenpanne oder einer unberechtigten Aktion?

Ein fiktiver Onlinehändler könnte etwa Fragen zu Rücksendefristen untersuchen. Der Agent würde nur freigegebene Informationen erklären und bei Ausnahmen an das Team übergeben. Er dürfte weder eine Erstattung zusagen noch eine Rücksendung auslösen. Für eine personalisierte Statusabfrage wären zusätzlich Identifizierung und eine passende Schnittstelle nötig. Diese Grenzen gehören in die fachliche Beschreibung, nicht nur in einen Prompt.

Definieren Sie eine verantwortliche Person im Fachbereich und eine technische Ansprechperson. Gemeinsam entscheiden sie, welche Quellen gelten, wer Inhalte aktualisiert und wer eine Funktion im Zweifel abschaltet. So wird aus einer interessanten Demonstration ein überprüfbares Betriebsmodell.

4. Nutzerbedürfnisse verstehen und einen Prototyp testen

Ein funktionierender Dialog beginnt mit den Anliegen der Menschen, die ihn nutzen sollen. Analysieren Sie typische Formulierungen, unvollständige Fragen und mehrdeutige Begriffe. Ein Kunde fragt selten in der Sprache eines internen Prozesshandbuchs. Er schreibt eher „Wo bleibt mein Paket?“ als „Wie ist der aktuelle Fulfillment-Status?“.

Skizzieren Sie den Gesprächsverlauf zunächst ohne vollständige Integration: Einstieg, Rückfragen, mögliche Antworten und Übergabe an einen Menschen. Testen Sie mit realistischen, für den Test geeigneten Beispielen auch schwierige Fälle: widersprüchliche Angaben, veraltete Dokumente, mehrere Anliegen in einer Nachricht oder eine Frage, auf die es keine freigegebene Antwort gibt.

Für Workshops zur Nutzeranalyse und Prototypentwicklung bietet der AI Agent Guide des Anbieters DialogBits Methoden und ausfüllbare Vorlagen. Die verlinkte Seite bietet den Leitfaden zum Download an und enthält auch Hinweise auf weitere Angebote des Unternehmens. Die Auswahl und Bewertung der Methoden bleibt Aufgabe des Projektteams.

Halten Sie Testergebnisse strukturiert fest: Was wollte die testende Person erreichen? Welche Quelle wurde herangezogen? War die Antwort korrekt und verständlich? Gab es eine geeignete Übergabe? Ein Prototyp darf auch zeigen, dass ein Prozess zunächst ungeeignet ist – diese Erkenntnis spart später Aufwand.

Dieses Bild wurde komplett mit KI generiertProviderHiggsfieldModellOpenAI GPT Image 2.5 FlarePromptEditorial photograph for a practical guide to AI customer service pilot projects: diverse service professionals at a desk reviewing a prototype conversation on a monitor together, human oversight and thoughtful testing, natural modern office, realistic and understated, navy and teal accents, no legible text, no logos, landscape 16:9.

5. Wissensquellen und Schnittstellen begrenzen

Ein Sprachmodell erzeugt flüssige Texte, kann dabei aber plausible Fehler machen. Eine Wissensanbindung, oft als Retrieval-Augmented Generation oder RAG bezeichnet, stellt passende Dokumentenausschnitte für die Antwort bereit. Das verbessert die Nachvollziehbarkeit, garantiert aber keine richtige Antwort: Auch die gefundenen Dokumente können veraltet, unvollständig oder für eine bestimmte Person nicht freigegeben sein.

Inventarisieren Sie deshalb die Quellen: Wer besitzt das Dokument, wann wurde es zuletzt geprüft und für welche Zielgruppe gilt es? Interne Arbeitsanweisungen und öffentlich freigegebene Informationen sollten nicht ungeprüft in denselben Suchbereich gelangen. Zugriffsrechte müssen auch bei Suchabfragen durchgesetzt werden. Quellenangaben in Antworten erleichtern die Kontrolle, ersetzen aber keine Qualitätsprüfung.

Für Schnittstellen gilt das Prinzip der geringsten notwendigen Rechte. Ein Pilot für Auskünfte braucht zunächst vielleicht nur lesenden Zugriff auf einen begrenzten Datenbestand. Schreibzugriffe, Transaktionen und Versandfunktionen sollten getrennt abgesichert und bei Bedarf ausdrücklich freigegeben werden. Test- und Produktivsysteme gehören auseinander; Zugangsdaten gehören nicht in Prompts oder frei zugängliche Dokumente.

6. Datenschutz und Datenflüsse vor dem Pilot klären

Zeichnen Sie den Weg einer Anfrage auf: Welche Daten geben Kundinnen und Kunden ein? Welche Informationen zieht das System aus internen Quellen hinzu? An welche Plattform, welches Sprachmodell und welchen Hosting-Anbieter werden sie übermittelt? Dazu gehören auch Protokolle, Supportzugriffe, Unterauftragsverarbeiter und mögliche Übermittlungen in Drittländer.

Prüfen Sie mit Datenschutz und IT-Sicherheit unter anderem Zweck und Rechtsgrundlage, Informationspflichten, Datenminimierung, Löschfristen, Verträge und technische Schutzmaßnahmen. Ob eine Datenschutz-Folgenabschätzung nötig ist, hängt vom konkreten Einsatz ab. Ein Hostingstandort allein belegt keine DSGVO-Konformität; ausschlaggebend sind die tatsächlichen Datenflüsse, Zugriffe und vertraglichen sowie technischen Bedingungen.

Der Datenschutz-Ratgeber von DialogBits behandelt die Rollen von Plattform, Sprachmodell und Hosting aus Sicht des Anbieters. Einzelne Produkt- und Rechtsaussagen sollten Unternehmen anhand aktueller Vertragsunterlagen und der eigenen Verarbeitung prüfen. Einen weiteren Ausgangspunkt bietet ein Expertenbericht zu Datenschutzrisiken von Sprachmodellen, der über den Europäischen Datenschutzausschuss veröffentlicht wurde. Er stammt von einer externen Expertin und gibt nicht zwingend die offizielle Position des Ausschusses wieder.

7. Angriffe, Fehler und Eskalation einplanen

Neben gewöhnlichen Fehlantworten gehören absichtliche Manipulationsversuche in den Testplan. Bei Prompt Injection können Anweisungen in Nutzereingaben oder externen Inhalten versuchen, das System von seiner Aufgabe abzubringen. Auch eine Wissenssuche verhindert solche Angriffe nicht zuverlässig. Das OWASP-Projekt zu Prompt Injection empfiehlt unter anderem begrenzte Rechte, die Trennung externer Inhalte und menschliche Freigaben für riskante Aktionen.

Praktisch bedeutet das: Der Agent darf externe Texte nicht als übergeordnete Anweisung behandeln; sensible Funktionen werden durch technische Kontrollen geschützt. Testen Sie, ob der Assistent vertrauliche Inhalte preisgibt, unzulässige Aktionen ausführt oder bei fehlendem Wissen eine Antwort erfindet. Planen Sie eine Abschaltmöglichkeit und einen Ablauf für Vorfälle ein – einschließlich Zuständigkeit, Dokumentation und Wiederanlauf.

Ebenso wichtig ist die Übergabe: Kundinnen und Kunden sollten erkennen können, wann sie mit einem automatisierten System sprechen und wie sie einen Menschen erreichen. Bei einer Eskalation muss das Team ausreichend Kontext erhalten, ohne unnötig viele personenbezogene Daten weiterzugeben. Eine Sackgasse aus wiederholten Standardantworten ist kein gelungener Serviceprozess.

8. Pilotbetrieb messen und über den Ausbau entscheiden

Starten Sie mit einer klar begrenzten Nutzergruppe, einem definierten Zeitraum und einem überschaubaren Anliegen. Vor dem Start braucht es eine Vergleichsbasis: Wie lange dauern diese Anfragen heute? Wie oft werden sie beim ersten Kontakt geklärt? Wie zufrieden sind Kundschaft und Mitarbeitende? Erst dann lassen sich Veränderungen sinnvoll einordnen.

Ein Dashboard sollte nicht nur die Zahl automatisch beendeter Dialoge zeigen. Eine abgebrochene Unterhaltung kann bedeuten, dass jemand sein Problem gelöst hat – oder frustriert aufgegeben hat. Ergänzen Sie quantitative Werte daher um stichprobenartige Qualitätsprüfungen, Beschwerden, Fehlerkategorien und Rückmeldungen des Serviceteams. Messen Sie zudem, wie häufig Menschen übernehmen und ob die Übergabe funktioniert.

Vorab festgelegte Grenzen helfen bei der Entscheidung: Welche Fehlerrate ist für diesen Prozess akzeptabel? Wann wird die Funktion pausiert? Wer darf zusätzliche Zugriffe freigeben? Nach dem Pilot sollten Fachbereich, Datenschutz und IT gemeinsam entscheiden, ob der Anwendungsfall eingestellt, nachgebessert oder erweitert wird.

Ein KI-Agent ist dann ein Fortschritt, wenn er ein konkretes Problem zuverlässig löst und sich in bestehende Abläufe einfügt. Unternehmen, die mit einem begrenzten Einsatz beginnen, ihre Datenflüsse kennen und Freigaben technisch absichern, schaffen dafür eine belastbarere Grundlage als mit einem schnellen Rollout ohne überprüfbare Ziele.