So wählen Sie den ersten Use Case für einen KI-Agenten.

Warum der erste Use Case wichtiger ist als der zehnte

Jedes Unternehmen, das KI ausprobiert hat, hat eine Geschichte dazu, und meist handelt sie vom ersten Versuch. Ein sichtbarer Fehlschlag, ob ein Chatbot, der das Serviceteam blamiert hat, oder ein Pilot, der die Sandbox nie verlassen hat, kauft achtzehn Monate „Das haben wir probiert, das funktioniert bei uns nicht“. Ein sichtbarer Erfolg bewirkt das Gegenteil: Bereichsleitungen fragen nach einem eigenen Agenten, die IT bekommt Budget für die Anbindung, und Governance-Diskussionen werden praktisch statt theoretisch.

Deshalb sollte der erste Use Case weder der ehrgeizigste sein noch der mit der größten theoretischen Einsparung. Es sollte der sein, der mit der höchsten Wahrscheinlichkeit innerhalb eines Quartals mit messbarem Ergebnis in den Produktivbetrieb kommt. Ehrgeiz kommt in der zweiten Welle – auf der Glaubwürdigkeit, die die erste aufgebaut hat.

Ein Bewertungsraster für Kandidaten

Wir bewerten jeden Kandidaten nach sieben Kriterien. Die Zahlen sind weniger wichtig als das Gespräch, das sie zwischen Prozessverantwortung, IT und Geschäftsführung erzwingen. Vergeben Sie je Kriterium eins bis fünf Punkte und seien Sie bei den niedrigen Werten ehrlich – sie entscheiden.

Drei davon sind faktisch K.-o.-Kriterien. Ohne Sponsor stirbt der Pilot an der ersten Integrationshürde. Ohne Ausgangsbasis können Sie nicht belegen, dass es funktioniert hat. Ohne Umkehrbarkeit wird der erste Fehler zur Geschichte.

Was gute erste Use Cases gemeinsam haben

• Hohes Volumen, wenig Glanz. Die Arbeit ist so repetitiv, dass niemand sie verteidigt, und so häufig, dass Verbesserungen in Wochen sichtbar werden.
• Klare Regeln mit Urteilsvermögen in der Mitte. Der Prozess ist dokumentiert, aber eine erfahrene Person wendet trotzdem Faustregeln an. Genau diese Lücke füllt ein Sprachmodell – und RPA nicht.
• Unstrukturierte Eingaben. E-Mails, PDFs, Tickets, Freitextformulare. Wären die Eingaben strukturiert, gäbe es längst eine einfachere Integration.
• Ein Mensch prüft das Ergebnis heute schon. Der Prüfschritt existiert bereits, also fügt sich der Agent in eine Autonomiestufe ein, die die Organisation schon kennt.
• Messbar. Durchlaufzeit, Rückstand, Fehlerquote oder Stunden je Fall lassen sich vorher und nachher messen.
• Begrenzt. Ein Workflow, ein Team, zwei oder drei Systeme. Nicht „Kundenservice“, sondern „Antwortentwürfe für Tickets zum Bestellstatus“.

Was Sie beim ersten Mal vermeiden sollten

• Kundenkontakt mit hohem Einsatz. Ein Agent, der ohne Prüfung mit Kunden spricht, in einer Situation, in der eine falsche Antwort einen Vertrag kostet, ist ein Projekt für die zweite Welle.
• Rechtlich heikle Entscheidungen. Alles, was Einstellung, Beförderung, Kredit oder Zugang zu wesentlichen Leistungen berührt, gilt nach dem EU AI Act als Hochrisiko und bringt Aufsichts- und Dokumentationspflichten mit, die Sie nicht im ersten Piloten lernen wollen. Unser Leitfaden zum EU AI Act listet die Kategorien auf.
• Keine Ausgangsbasis. Wenn niemand sagen kann, wie lange der Prozess heute dauert oder wie oft er scheitert, messen Sie das zuerst oder wählen einen anderen Prozess.
• Ein Prozess, der ohnehin umgebaut wird. Ein bewegliches Ziel zu automatisieren, liefert einen Agenten für einen Workflow, den es in sechs Monaten nicht mehr gibt.
• Nutzen erst bei voller Autonomie. Wenn der Business Case nur aufgeht, sobald der Agent ganz ohne Prüfung handelt, setzen Sie den ersten Piloten auf Stufe vier. Wählen Sie etwas, das sich schon auf Stufe zwei oder drei rechnet.

Acht konkrete Kandidaten

Diese ersten Use Cases sehen wir in vielen Unternehmen. Jeder ist auf der verlinkten Lösungsseite ausführlicher beschrieben.

1. Kundenservice: Ticket-Triage und Antwortentwürfe. Der Agent klassifiziert eingehende Tickets, zieht Auftrags- und Vertragsdaten heran und entwirft eine Antwort, die eine Servicemitarbeiterin freigibt. Ausgangsbasis: Zeit bis zur ersten Antwort, Bearbeitungszeit. Siehe Kundenservice.
2. Finanzen: Rechnungsabgleich und Erklärung von Abweichungen. Eingangsrechnungen werden mit Bestellungen und Wareneingängen abgeglichen; Abweichungen werden mit Belegen erklärt und weitergeleitet. Ausgangsbasis: Tage bis zur Buchung, Anteil manueller Ausnahmen. Siehe Finanzen.
3. Vertrieb: Qualifizierung eingehender Leads und CRM-Anreicherung. Leads werden recherchiert, nach Ihren Kriterien bewertet und mit einem Vorschlag für die erste Antwort übergeben. Ausgangsbasis: Zeit bis zum Erstkontakt, Datenvollständigkeit. Siehe Vertrieb.
4. Operations: Auftragserfassung aus E-Mails und PDFs. Aufträge werden gelesen, gegen Preislisten und Bestände geprüft und ins ERP übernommen; Ausnahmen bestätigt ein Mensch. Ausgangsbasis: Stunden je Auftrag, Erfassungsfehler. Siehe Operations.
5. HR: Mitarbeiter-Helpdesk zu Richtlinien und Prozessen. Fragen werden mit Quellenangabe aus dem Handbuch beantwortet, Routineanfragen wie Bescheinigungen vorbereitet. Ausgangsbasis: HR-Tickets pro Monat, Antwortzeit. Siehe HR.
6. Einkauf: Erfassung und Vergleich von Lieferantendokumenten. Angebote und Zertifikate werden extrahiert, vereinheitlicht und gegen Anforderungen verglichen; ein Einkäufer entscheidet. Ausgangsbasis: Zeit je Angebotsauswertung. Siehe Einkauf.
7. Recht: Erstprüfung von Verträgen gegen ein Playbook. Standardverträge werden gegen Ihre Positionen geprüft, Abweichungen mit Begründung markiert. Ausgangsbasis: Prüfzeit je Vertrag, Rückstand. Siehe Recht und Compliance.
8. IT: Anreicherung von Störungen und Runbook-Ausführung mit Freigabe. Störungen werden mit Logs und Historie angereichert; bekannte Lösungen werden nach einem Klick ausgeführt. Ausgangsbasis: Lösungszeit, Tickets je Engineer. Siehe IT und Engineering.

So gestalten Sie den Piloten

Ein erster Pilot sollte so zugeschnitten sein, dass in der Regel in sechs bis acht Wochen ein produktionsreifer Agent für einen Workflow entsteht. Das heißt: echte Daten, echte Systeme und echte Nutzer von Anfang an, keine synthetische Demo. Vier Entscheidungen sind dabei ausschlaggebend.

• Zuerst die Ausgangsbasis. Messen Sie den heutigen Prozess zwei Wochen lang, bevor der Agent ihn berührt: Fälle, Zeit je Fall, Fehlerquote, Rückstand. Ohne diese Zahl kann der Pilot nicht gelingen, nur beeindrucken.
• Zwei oder drei Erfolgskennzahlen, schriftlich. Eine für den Nutzen (Stunden oder Durchlaufzeit), eine für die Qualität (Fehlerquote oder Nacharbeit), eine für die Akzeptanz (Anteil der Fälle, die das Team dem Agenten überlässt). Legen Sie die Go/No-Go-Schwelle vor dem Start fest.
• Menschliche Kontrollpunkte von Anfang an. Entscheiden Sie je Aktion, was der Agent allein tun darf, was er vorschlägt und was er zur Freigabe vorbereitet. Beginnen Sie konservativ und lockern Sie auf Basis von Evaluationsdaten, nicht von Begeisterung.
• Ein Evaluationsset. Fünfzig bis einige Hundert historische Fälle mit bekanntem richtigem Ergebnis. Jede Änderung an Prompts oder Werkzeugen wird dagegen getestet, damit Verbesserungen belegt und Rückschritte erkannt werden.

Unsere Projekte zur KI-Agenten-Entwicklung folgen dieser Struktur, und das Readiness-Assessment, das ihnen oft vorausgeht, liefert die Shortlist und die Ausgangsbasen.

Typische Fehler

• Von der Technologie ausgehen. „Wir haben Copilot-Lizenzen, was können wir damit machen?“ ist eine Einkaufsfrage, keine Use-Case-Auswahl.
• Kein Prozessverantwortlicher. IT-getriebene Piloten ohne eine Abteilung, die das Ergebnis will, erreichen selten den Produktivbetrieb.
• Aktivität statt Ergebnis messen. Anzahl der Prompts, Anzahl der Nutzer und Zufriedenheitsumfragen sind kein Business Case.
• Zu viel Autonomie zu früh. Der erste sichtbare Fehler auf Stufe vier kostet mehr Glaubwürdigkeit, als ein langsamer Start auf Stufe zwei je kosten wird.
• Evaluation überspringen. Prompt-Änderungen nach Gefühl liefern einen Agenten, der dienstags gut und donnerstags schlecht ist.
• Kein Plan für den Betrieb. Ein Agent braucht nach dem Piloten einen Verantwortlichen, Monitoring und einen Änderungsprozess. Hat niemand über Managed AI Operations nachgedacht, ist der Pilot das Ende der Geschichte.