KI-Tests enden oft so: Ein paar Kolleginnen und Kollegen probieren ein Tool aus, den meisten gefällt es, und drei Monate später kann niemand sagen, ob es Zeit gespart, die Qualität verbessert oder nur zusätzliche Arbeit gemacht hat. Das Tool bleibt, weil niemand entscheidet. Ein Pilotprojekt verhindert das. Es ist ein kurzer, geplanter Test eines Anwendungsfalls in der echten Arbeit, mit Zahlen vorher und nachher und einer klaren Entscheidung am Ende.
Dieser Artikel ist Teil 1 von Level 3 unseres Lernpfads AI Work. Level 2 hat Abläufe und Qualitätskontrolle behandelt. In Level 3 geht es um Automatisierung, Integration und Messung, und es beginnt mit der Methode, die aus einer Idee einen Beleg macht. Sie lernen, einen Anwendungsfall auszuwählen, einen Ausgangswert zu messen, KPIs und Erfolgskriterien festzulegen, sechs bis acht Wochen zu planen und am Ende über das Weitermachen zu entscheiden, mit einem Plan für den Ausbau.
Einen Anwendungsfall wählen, der einen Pilot lohnt
Ein Pilot beantwortet eine Frage: Schafft dieser Anwendungsfall in unserer täglichen Arbeit einen Nutzen, und unter welchen Bedingungen? Das ist eine andere Frage als beim Tool-Test in Level 2, bei dem Sie die Finalisten mit Pilotnutzern getestet haben. Ein Tool-Test fragt: Welches Tool? Ein Pilotprojekt fragt: Funktioniert die ganze Veränderung? Gemeint sind das Tool, der neue Ablauf, die Prüfungen und die Menschen.
Beginnen Sie mit einer Liste von Kandidaten. Fragen Sie jedes Team, welche Aufgaben viel Zeit kosten, sich oft wiederholen und einem Muster folgen. Unser Tool-Vergleich für AI Work führt 46 Tools für Vertrieb, Kundenservice, Marketing, E-Commerce und Betrieb und zeigt, was heute möglich ist. Dann bewerten Sie jeden Kandidaten auf zwei Skalen: den Nutzen, den er bringen könnte, und den Aufwand für Daten, Anbindung, Schulung und Prüfung.
Ein guter erster Pilot liegt im Feld oben links: klarer Nutzen, wenig Aufwand. Außerdem besteht er vier weitere Tests:
- Häufig: Die Aufgabe kommt jeden Tag oder jede Woche vor, sodass in wenigen Wochen genug Fälle zusammenkommen.
- Messbar: Sie können Zeit, Menge oder Fehler zählen, am besten in Systemen, die Sie schon nutzen.
- Begrenzt: Macht die KI einen Fehler, fängt ihn ein Mensch ab, bevor ihn ein Kunde oder die Buchhaltung sieht.
- Gewollt: Das Team, das die Arbeit macht, will es ausprobieren.
Dieser Teil nutzt durchgehend ein Beispiel. Das Serviceteam eines Onlineshops beantwortet Kunden-E-Mails in einem Helpdesk, der Software, die Kundenanfragen als Tickets sammelt. Im Pilot entwirft eine KI-gestützte Funktion für jede Routine-E-Mail eine Antwort, etwa zu Lieferzeiten, Rücksendungen oder Rechnungen. Eine Servicekraft prüft den Entwurf, bearbeitet ihn und verschickt ihn. Jede Antwort geht weiterhin durch die Hände eines Menschen, und das macht diesen Anwendungsfall zu einem sicheren ersten Pilot.
Die Tools für solche Anwendungsfälle reichen von Kundenservice-Plattformen mit eingebautem KI-Agenten bis zu KI-Agenten für große Serviceteams. Nach Angaben der Anbieter verbindet Tidio einen KI-Agenten mit Live-Chat und Ticketsystem, und Typewise bietet KI-Agenten, die Anfragen über mehrere Kanäle bearbeiten und Abläufe in CRM- und ERP-Systemen ausführen. Für die Messung verbindet Databox Datenquellen mit Dashboards, Zielen und automatischen Berichten:
Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.
Bevor es losgeht, schreiben Sie einen einseitigen Pilotsteckbrief: das Problem, den Anwendungsfall, was dazugehört und was nicht, die Pilotnutzer, die beteiligten Daten, die KPIs, den Zeitplan, die verantwortliche Person und die Entscheidungsregel. Eine Seite zwingt zur Genauigkeit, und an ihr misst die Entscheiderin oder der Entscheider später die Ergebnisse.
Den Ausgangswert messen, bevor sich etwas ändert
Der Ausgangswert (englisch Baseline) beschreibt, wie die Aufgabe heute läuft, gemessen genau so, wie Sie sie später im Pilot messen. Ohne ihn ist jedes Ergebnis geraten. „Es fühlt sich schneller an“ ist kein Ergebnis.
Messen Sie den Ausgangswert mindestens zwei normale Wochen lang, bevor der Pilot beginnt. Viele Zahlen gibt es schon: Ein Helpdesk erfasst, wann eine E-Mail eingeht, wann eine Servicekraft sie öffnet und wann die Antwort hinausgeht. Für die Qualität ziehen Sie eine Zufallsstichprobe gesendeter Antworten, zum Beispiel 50 pro Woche, und lassen die Teamleitung sie mit einer kurzen Checkliste prüfen: richtige Fakten, vollständige Antwort, passender Ton.
Drei Fallen verzerren den Vergleich:
- Saison und Aktionen. Wochen vor Feiertagen sehen anders aus als ruhige Wochen. Vergleichen Sie ähnliche Zeiträume oder halten Sie die Unterschiede zumindest fest.
- Eine geänderte Messung. Zählt der Ausgangswert die Bearbeitungszeit vom Öffnen der E-Mail bis zum Senden der Antwort, muss der Pilot sie genauso zählen.
- Der Neuheitseffekt. Menschen arbeiten anders, wenn sie wissen, dass ein Test läuft, und ein neues Tool bekommt in den ersten Tagen besondere Aufmerksamkeit. Bewerten Sie die letzten Wochen des Pilots, nicht die ersten.
Wenn möglich, bilden Sie eine Vergleichsgruppe: ein ähnliches Team oder eine Schicht, die in denselben Wochen ohne KI arbeitet. Eine volle Woche trifft dann beide Gruppen, und der Unterschied zwischen ihnen zeigt die Wirkung der KI deutlicher.
Messen Sie auf Teamebene, nicht pro Person. Ein Pilot ist keine Leistungsbeurteilung, und wer sich beobachtet fühlt, meldet keine Probleme mehr. In Deutschland hat der Betriebsrat ein Mitbestimmungsrecht, wenn ein Unternehmen technische Einrichtungen einführt, die Verhalten oder Leistung der Beschäftigten überwachen können (§ 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz, BetrVG). Beziehen Sie ihn vor dem Start ein. Verarbeitet der Pilot personenbezogene Daten auf neue Weise, klären Sie mit Ihrem Datenschutzbeauftragten, ob eine Datenschutz-Folgenabschätzung nötig ist (Art. 35 DSGVO).
KPIs und Erfolgskriterien festlegen
Ein KPI (Key Performance Indicator, Leistungskennzahl) ist eine Zahl, die zeigt, ob Sie ein Ziel erreichen. Ein Pilot braucht KPIs von vier Arten, denn eine einzelne Zahl kann ein Problem verdecken: Antworten können gleichzeitig schneller und schlechter werden.
| Art | Beispiel-KPI | So messen Sie | Beispielziel |
|---|---|---|---|
| Nutzen | Bearbeitungszeit pro Routine-E-Mail | Zeitstempel im Helpdesk, Median pro Woche | Mindestens 20 % unter dem Ausgangswert |
| Qualität | Fehler pro 50 gesendete Antworten | Wöchentliche Zufallsstichprobe, mit der Checkliste geprüft | Nicht über dem Ausgangswert |
| Nutzung | Anteil der Routine-E-Mails, bei denen der Entwurf genutzt wird | Helpdesk-Bericht oder Markierung am Ticket | Mindestens 70 % in den letzten zwei Wochen |
| Leitplanke | Kundenzufriedenheit (CSAT) und Beschwerden | Umfrage nach Abschluss des Tickets, Beschwerdeliste | Kein Rückgang gegenüber dem Ausgangswert |
Der Median ist der mittlere Wert: Die Hälfte der E-Mails hat weniger Zeit gebraucht, die Hälfte mehr. Anders als der Durchschnitt lässt er sich von wenigen sehr langen Fällen nicht verzerren. Die Ziele in der Tabelle sind Beispiele. Legen Sie Ihre eigenen vor dem Start fest und schreiben Sie sie in den Pilotsteckbrief.
Eine Leitplanken-Kennzahl ist eine Zahl, die nicht schlechter werden darf, auch wenn sich alles andere verbessert. Kundenzufriedenheit, Beschwerden und Datenschutzvorfälle sind typische Leitplanken. Reißt eine Leitplanke, besteht der Pilot nicht, egal wie viel Zeit er spart.
Dann machen Sie aus den Zielen eine Entscheidungsregel, zum Beispiel: „Weiter, wenn die Bearbeitungszeit um mindestens 20 Prozent sinkt, Fehler und Kundenzufriedenheit mindestens auf dem Ausgangswert bleiben und mindestens zwei Drittel der Pilotnutzer so weiterarbeiten wollen.“ Eine Regel, die vor dem Start feststeht, schützt die Entscheidung am Ende vor Wunschdenken.
Halten Sie auch fest, was der Pilot an Zeit kostet: Einrichtung, Schulung, die wöchentliche Runde und das Prüfen der Entwürfe. Diese Stunden gehören ins Ergebnis. Level 4 zeigt, wie daraus eine vollständige Rechnung wird, wenn Sie den ROI von KI in der Arbeit messen.
Sechs bis acht Wochen mit einem kleinen Team planen
Sechs bis acht Wochen sind eine gute Länge für einen ersten Pilot. Das ist lang genug, damit die Lernphase vorbei ist und normale Wochen sichtbar werden, und kurz genug, damit alle bei der Sache bleiben. Ein kleines Team genügt:
- Verantwortliche Person: jemand aus dem Fachbereich, der den Pilot leitet und das Ergebnis berichtet, hier die Leitung des Serviceteams.
- Vier bis acht Pilotnutzer: eine Mischung aus Begeisterten, Skeptikern und neuen Kolleginnen und Kollegen.
- Technischer Ansprechpartner: richtet Zugänge, Verbindungen und Datenexporte ein.
- Datenschutzbeauftragte und, falls vorhanden, Betriebsrat: vor dem Start eingebunden, nicht danach.
- Auftraggeber: die Führungskraft, die am Ende entscheidet und der Entscheidungsregel vorab zugestimmt hat.
Die wöchentliche Runde ist das Herzstück des Pilots. In 30 Minuten schauen sich die verantwortliche Person und die Pilotnutzer die Zahlen an, gehen die Liste der Probleme durch und vereinbaren kleine Änderungen, etwa eine klarere Anweisung an die KI oder eine fehlende Antwort in der Wissensdatenbank. Tragen Sie jede Änderung mit Datum in ein Änderungsprotokoll ein. Sonst können Sie später nicht sagen, welche Änderung welche Wirkung hatte.
Bewerten Sie den Pilot nicht nach der ersten Woche. Teams werden oft erst langsamer, bevor sie schneller werden: Sie lernen den neuen Ablauf, finden Lücken in der Wissensdatenbank und prüfen jeden Entwurf sehr gründlich. Das Beispiel unten zeigt diesen typischen Verlauf.
Risiken im laufenden Pilot steuern
Viele Risiken eines Pilots kündigen sich früh an. Achten Sie in jeder wöchentlichen Runde darauf:
| Risiko | Frühes Warnzeichen | Was Sie tun |
|---|---|---|
| Falsche Fakten in Entwürfen | Fehler in der wöchentlichen Stichprobe | Servicekräfte prüfen jeden Entwurf; die Wissensdatenbank korrigieren, nicht nur die einzelne Antwort |
| Personenbezogene Daten am falschen Ort | Kundendaten in nicht freigegebenen Tools | Nur freigegebene Konten, so wenig Daten wie möglich, Vertrag zur Auftragsverarbeitung |
| Geringe Nutzung | Die Nutzung sinkt nach den ersten Tagen | Die Pilotnutzer nach dem Grund fragen, Hindernisse beseitigen, eine kurze Auffrischung anbieten |
| Ausufernder Umfang | Anfragen wie „Kann es das auch?“ | Neue Ideen auf eine Liste für die Zeit nach der Entscheidung setzen |
| Wissen in einem Kopf | Nur die verantwortliche Person kennt Einstellungen und Anweisungen | Einstellungen, Anweisungen und Änderungsprotokoll dokumentieren |
| Ein endloser Pilot | Kein Entscheidungstermin im Kalender | Den Entscheidungstermin in Woche 0 buchen |
Entscheiden: weiter, anpassen oder aufhören
Am Ende stellt die verantwortliche Person dem Auftraggeber die Ergebnisse auf einer Seite vor: die KPIs im Vergleich mit Ausgangswert und Zielen, die Leitplanken, die Stimmen der Pilotnutzer, die Zeit, die der Pilot gekostet hat, und eine Empfehlung. Es gibt drei mögliche Ergebnisse.
- Weiter (Go): Alle Kriterien sind erfüllt. Planen Sie den Ausbau.
- Anpassen: Der Nutzen ist da, aber eine Bedingung fehlt, zum Beispiel zu viele Fehler bei einer Art von E-Mail. Beheben Sie genau diesen Punkt und verlängern Sie den Pilot um einige Wochen, aber nur einmal.
- Aufhören (No-Go): Der Nutzen rechtfertigt den Aufwand nicht, oder eine Leitplanke ist gerissen. Halten Sie fest, was Sie gelernt haben, und schließen Sie den Pilot ab.
Ein Abbruch ist ein Ergebnis, kein Scheitern: Er spart die Kosten einer Einführung, die nicht funktioniert hätte. Bewahren Sie Steckbrief, Zahlen und Erkenntnisse für den nächsten Kandidaten auf Ihrer Liste auf.
Abbrüche sind häufig. Ein viel zitierter Bericht des MIT aus dem Jahr 2025 fand, dass 95 % der Organisationen, die generative KI einsetzen, keinen klaren Ertrag ihrer Investition sahen, und führte das auf eine Lernlücke im Umgang mit den Tools zurück, nicht auf die Technik selbst (Quelle: MIT-Bericht, berichtet von Fortune, September 2025). Ein Pilot mit Ausgangswert und festen Kriterien zeigt früh, auf welcher Seite dieser Lücke Ihr Anwendungsfall steht.
Den Ausbau vor der Einführung vorbereiten
Ein Pilot läuft mit motivierten Nutzern, besonderer Aufmerksamkeit und einer verantwortlichen Person, die jede Woche auf die Zahlen schaut. Der Alltag muss ohne all das funktionieren. Bauen Sie in Wellen aus, ein Team nach dem anderen, und prüfen Sie vor jeder Welle diese Punkte:
| Thema | Im Pilot | Vor dem Ausbau |
|---|---|---|
| Nutzer | Vier bis acht Freiwillige | Schulung für alle Nutzer und eine Ansprechperson für Fragen |
| Verbindungen | Manuelle Schritte sind in Ordnung | Stabile Anbindung an Helpdesk und CRM, siehe Teil 2: KI an CRM und Helpdesk anbinden |
| Qualitätsprüfung | Jeder Entwurf geprüft, wöchentliche Stichprobe | Klare Regeln, welche Ergebnisse ein Mensch prüft, siehe Teil 5: Human in the Loop |
| Messung | Wöchentliche Runde der verantwortlichen Person | Dieselben KPIs in einem regelmäßigen Bericht, mit unveränderten Definitionen |
| Verantwortung | Die verantwortliche Person des Pilots | Eine benannte verantwortliche Person für Tool, Einstellungen und Wissensinhalte |
| Verträge und Datenschutz | Testkonten, Pilotbedingungen | Regulärer Vertrag, Vertrag zur Auftragsverarbeitung, Löschregeln |