KI-Pilotprojekt planen: Scope, Erfolgskriterien und Betrieb

Ein Pilotprojekt soll eine Frage beantworten: Funktioniert dieser eine KI-gestützte Prozess bei uns, unter echten Bedingungen, mit echten Daten und echten Nutzenden? In der Praxis beantworten die meisten Piloten diese Frage nie. Sie enden als Demo, die einmal gut aussah, oder als Dauerzustand ohne Abschlussentscheidung. Laut Bitkom-Studie 2026 nutzen mittlerweile 41 % der Unternehmen ab 20 Beschäftigten KI aktiv – vor einem Jahr waren es erst 17 %. Der Sprung ist real, aber er sagt nichts darüber aus, wie viele dieser Einsätze aus einem sauber geplanten Piloten mit Entscheidung am Ende entstanden sind und wie viele als loses Experiment weiterlaufen.

Dieser Artikel ist Teil unseres Themen-Clusters KI-Strategie und geht speziell auf die Pilotphase ein: den Schritt zwischen „wir haben einen Use Case ausgewählt” und „wir wissen, ob er sich lohnt”. Wenn du noch nicht so weit bist, welchen Use Case du überhaupt testen willst, hilft dir zuerst die Auswahl- und Priorisierungslogik im Cluster weiter. Hier geht es darum, wie aus einer guten Idee ein Pilot wird, der ein belastbares Ergebnis liefert – egal ob er am Ende zum Rollout führt oder zur Erkenntnis, dass der Ansatz so nicht funktioniert.

Das Problem: Piloten bleiben Demos

Das typische Scheitern eines KI-Pilotprojekts sieht selten dramatisch aus. Es beginnt vielversprechend: Ein Tool wird ausprobiert, eine erste Anwendung läuft, alle sind zufrieden mit dem Ergebnis der ersten Woche. Und dann passiert nichts Definiertes mehr. Nach zwei, drei Monaten ist unklar, ob der Pilot noch läuft, ob er erfolgreich war oder ob ihn überhaupt noch jemand nutzt. Drei Muster wiederholen sich dabei:

• Der Scope wächst während des Piloten. Was als „einen Prozess testen” startete, wird unterwegs auf weitere Teams, Sonderfälle und Wunschfunktionen ausgeweitet – bis niemand mehr sagen kann, was eigentlich getestet wurde.
• Es gibt keine Erfolgskriterien, nur einen Eindruck. Ohne vorher festgelegte Kennzahlen wird der Pilot am Ende nach Bauchgefühl bewertet. Das Ergebnis hängt dann stärker davon ab, wer gerade gute Laune hat, als davon, was tatsächlich passiert ist.
• Niemand trifft die Abschlussentscheidung. Der Pilot läuft weiter, weil ihn abzuschalten wie ein Rückschritt wirkt, und er wird nie offiziell zum Regelbetrieb, weil ihn niemand dafür freigegeben hat. Er hängt dazwischen – produktiv genutzt, aber nie wirklich verantwortet.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die einen konkreten Use Case bereits ausgewählt haben und ihn jetzt so testen wollen, dass am Ende eine echte Entscheidung steht – ausrollen, anpassen oder einstellen.

Begriffe kurz geklärt

Ein paar Begriffe, die im Zusammenhang mit Piloten häufig unscharf verwendet werden:

• Pilotprojekt: die zeitlich und im Umfang begrenzte Umsetzung eines einzelnen Use Cases mit vorher definierten Erfolgskriterien und einem festen Enddatum, an dem eine Entscheidung fällt.
• Scope: die Grenze des Piloten – welcher Prozess, welches Team, welche Datenquellen, welche Ausnahmen ausdrücklich nicht Teil des Tests sind.
• KPI (Key Performance Indicator): eine vorher festgelegte, nach dem Pilot messbare Kennzahl, an der Erfolg oder Misserfolg objektiv festgemacht wird – kein nachträglich gewählter Wert, der gerade gut aussieht.
• Proof of Concept (PoC): oft mit einem Piloten verwechselt, aber enger gefasst. Ein PoC zeigt technisch, dass etwas grundsätzlich funktioniert, meist ohne echte Nutzende und echten Datenfluss. Ein Pilot testet den Betrieb unter realen Bedingungen. Ein PoC kann dem Piloten vorausgehen, ersetzt ihn aber nicht.
• Rollout / Skalierung: die Ausweitung eines erfolgreich abgeschlossenen Piloten auf weitere Teams, Prozesse oder Standorte.

Was ist ein sinnvoller Pilot-Scope?

Der häufigste Fehler bei der Scope-Definition ist, zu viel gleichzeitig zu testen. Ein sinnvoller Pilot-Scope beantwortet fünf Fragen in jeweils einem Satz:

1. Welcher Prozess – nicht „Kundenservice verbessern”, sondern „eingehende Support-Anfragen zu einem bestimmten Produkt kategorisieren”.
2. Welches Team – eine Abteilung oder ein Standort, nicht das ganze Unternehmen gleichzeitig.
3. Welche Datenquellen – die konkreten Systeme, aus denen der Pilot Informationen bezieht, ausdrücklich benannt.
4. Welche Ausnahmen sind draußen – Sonderfälle, Randprozesse oder Kundengruppen, die bewusst nicht Teil des Tests sind, auch wenn sie später relevant werden.
5. Wo ist der Mensch im Prozess – wer prüft, freigibt oder korrigiert die Ausgabe, bevor sie wirkt.

Wenn eine dieser fünf Antworten fehlt oder vage bleibt („eigentlich alle Anfragen”, „am besten unternehmensweit”), ist der Scope noch nicht pilotreif. In meiner Arbeit sehe ich das am häufigsten bei der zweiten Frage: Teams wollen den Piloten gleich für mehrere Standorte gleichzeitig aufsetzen, „damit wir nicht zweimal Aufwand haben”. Das Ergebnis ist fast immer, dass keiner der Standorte richtig getestet wird, weil sich Aufmerksamkeit und Fehleranalyse über mehrere Umgebungen verteilen.

Ein sauberer Scope ist auch die Voraussetzung für die nächste Frage: Ohne klaren Scope lässt sich keine Kennzahl sinnvoll definieren, weil unklar bleibt, wovon sie eigentlich abhängt.

Welche KPIs braucht ein Pilotprojekt?

Erfolgskriterien gehören vor den Start des Piloten festgelegt – nicht danach, wenn das Ergebnis schon feststeht. Drei Kategorien sind für die meisten Piloten relevant, wobei nicht jede Kategorie für jeden Use Case zwingend nötig ist:

KPI-Kategorie	Beispielkennzahl	Wann wichtig
Effizienz	Bearbeitungszeit pro Vorgang, Durchlaufzeit	Bei zeitkritischen oder volumenstarken Prozessen
Qualität	Fehlerquote, Korrekturaufwand, Nacharbeit	Wenn fehlerhafte Ausgaben spürbare Folgekosten haben
Akzeptanz	Nutzungsquote, Zufriedenheit der Anwendenden, freiwillige Weiternutzung nach Pilotende	Immer – ein Tool, das niemand nutzt, ist kein Erfolg, egal wie gut die anderen Werte sind
Prüfaufwand	Anteil der Ausgaben, die ein Mensch korrigieren musste	Bei Human-in-the-Loop-Prozessen, um zu sehen, ob sich der Prüfaufwand über die Zeit reduziert

Eigene KPI-Matrix Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten.

Wichtig ist der Ausgangswert: Ohne eine Messung vor dem Pilotstart (die aktuelle Bearbeitungszeit, die heutige Fehlerquote) fehlt der Vergleichspunkt, und jede Zahl am Ende ist Behauptung statt Beleg. Diesen Vorher-Wert zu erheben kostet meist nur wenige Stunden – aus bestehenden Systemauswertungen oder einer kurzen Stichprobe –, wird aber regelmäßig vergessen, weil er vor dem eigentlichen Projektstart liegt.

Als Faustregel: zwei bis vier KPIs reichen für die meisten Piloten. Weniger als zwei lässt zu viel Interpretationsspielraum, mehr als fünf verwässert die Aufmerksamkeit und produziert am Ende einen Bericht, in dem sich für jede gewünschte Schlussfolgerung eine passende Zahl findet.

Wie lange sollte ein Pilot dauern?

Eine feste, belastbare Studienzahl zur „richtigen” Pilotdauer gibt es nicht – die Bandbreite hängt stark vom Prozess ab. Aus meiner Projekterfahrung mit KMU hat sich für die meisten Einstiegsfälle mit bestehenden Modellen (keine Eigenentwicklung) eine Laufzeit von etwa sechs bis zwölf Wochen bewährt, unter der Annahme, dass Daten bereits zugänglich sind und eine verantwortliche Person reales Zeitbudget hat.

Die Logik dahinter: Kürzer als vier Wochen reicht selten, um saisonale Schwankungen, Wochenanfang-Wochenende-Effekte oder die Lernkurve der Nutzenden herauszurechnen – die erste Woche eines Piloten testet meist eher die Gewöhnung als das eigentliche System. Länger als drei Monate wird es dagegen schwierig, den Piloten sauber abzugrenzen: Systeme, Teams und manchmal die Zielsetzung selbst verändern sich unterwegs, und die anfängliche Ausgangsmessung verliert an Vergleichbarkeit.

Zwei Anpassungen nach oben und unten:

• Kürzer möglich bei hochfrequenten Prozessen (täglich viele Vorgänge), weil sich hier auch in vier bis sechs Wochen genug Datenpunkte für eine belastbare Auswertung ansammeln.
• Länger nötig bei seltenen Prozessen (z. B. monatliche oder quartalsweise Vorgänge) oder wenn eine Integration in bestehende Systeme selbst mehrere Wochen braucht, bevor der eigentliche Test beginnt.

Welche Daten und Nutzer werden benötigt?

Daten. Der Pilot braucht Zugriff auf genau die Daten, die der getestete Prozess tatsächlich verwendet – nicht auf einen möglichst vollständigen Datenbestand „für den Fall der Fälle”. Drei Fragen helfen bei der Prüfung: Liegen die relevanten Informationen digital vor? Sind sie aktuell genug, um brauchbare Ergebnisse zu liefern? Und ist rechtlich und technisch geklärt, dass das Pilotsystem darauf zugreifen darf – inklusive Auftragsverarbeitung, falls ein externer Anbieter beteiligt ist? Wenn eine dieser drei Fragen mit Nein beantwortet wird, ist das kein Grund, den Piloten trotzdem zu starten, sondern ein Signal, den Scope enger zu fassen oder die Datenfrage zuerst zu klären.

Nutzende. Eine kleine, aber repräsentative Gruppe – typischerweise die Personen, die den betroffenen Prozess im Alltag tatsächlich ausführen, nicht nur technikaffine Freiwillige. Eine reine „Early-Adopter”-Gruppe liefert oft zu positive Ergebnisse, weil sie Probleme eher selbst umschifft, statt sie zu melden. Sinnvoll ist außerdem eine feste Ansprechperson pro Team, die Rückmeldungen sammelt und an den Use-Case-Owner weiterträgt – ohne diesen Kanal verpuffen viele wertvolle Beobachtungen im Alltagsgeschäft.

Ein Punkt aus der Praxis: Kläre vor dem Start, wie viel Zeit die Testnutzenden für Feedback und Dokumentation der Auffälligkeiten realistisch haben. Ein Pilot ohne dieses Zeitbudget liefert am Ende zwar Nutzungszahlen, aber kaum verwertbares qualitatives Feedback dazu, warum etwas funktioniert oder nicht.

Umsetzung: So planst du deinen Piloten

Ein Pilot-Canvas bündelt die bisherigen Fragen in einem Dokument, das vor dem Start ausgefüllt und von Sponsor sowie Use-Case-Owner gemeinsam abgenommen wird:

Feld	Ausfüllen mit
Prozess & Scope	Ein Satz, der Prozess, Team und Ausnahmen benennt
Hypothese	Was soll sich verbessern, und warum glauben wir das?
KPIs & Ausgangswert	2–4 Kennzahlen mit Messwert vor dem Start
Laufzeit & Enddatum	Festes Datum, an dem die Entscheidung fällt
Daten & Systeme	Konkrete Quellen, Zugriffsklärung, Auftragsverarbeitung falls nötig
Nutzende	Anzahl, Team, Ansprechperson für Feedback
Rollen	Sponsor, Use-Case-Owner, IT/Datenschutz-Zuständigkeit
Stopp-Kriterien	Ab wann wird abgebrochen, bevor das Enddatum erreicht ist?
Entscheidungsoptionen	Ausrollen / Anpassen und erneut testen / Einstellen

Eigenes Pilot-Canvas Philogic Labs, als Vorlage für die Planung – eine Seite reicht, wenn alle Felder konkret statt vage ausgefüllt sind.

Der Ablauf in der Praxis folgt üblicherweise vier Schritten: Erstens das Canvas gemeinsam mit Sponsor und Use-Case-Owner ausfüllen und die Ausgangsmessung vornehmen. Zweitens die technische Anbindung aufsetzen – bei bestehenden Tools oft eine Sache von Tagen, bei tieferer Systemintegration entsprechend länger. Drittens die Testphase mit regelmäßigen kurzen Check-ins (wöchentlich reicht meist), um früh erkennbare Probleme nicht erst am Ende zu entdecken. Viertens am festgelegten Enddatum die KPIs auswerten, die Nutzenden befragen und die Entscheidung treffen – dokumentiert, nicht nur im Gespräch getroffen.

Ein Rechenbeispiel aus einer typischen Konstellation: Ein KMU testet die Kategorisierung eingehender Support-Mails für ein Team. Ausgangswert vor dem Pilot: durchschnittlich 6 Minuten Bearbeitungszeit pro Vorgang, ermittelt aus einer zweiwöchigen Stichprobe im Ticketsystem. KPIs: Bearbeitungszeit pro Vorgang, Anteil der Vorschläge, die ohne Korrektur übernommen werden, Nutzungsquote im Team. Laufzeit: acht Wochen, weil das Team täglich mehrere Dutzend Vorgänge bearbeitet und damit genug Datenpunkte für eine belastbare Auswertung entstehen. Entscheidungspunkt: Woche 8, mit vorher festgelegtem Schwellenwert für „Erfolg” bei der Bearbeitungszeit. Wie hoch dieser Schwellenwert konkret sein sollte, hängt am Ende immer vom Einzelfall ab – das lässt sich nicht pauschal beziffern, sondern nur im Abgleich mit der eigenen Ausgangslage festlegen.

Wann wird gestoppt oder skaliert?

Die Abschlussentscheidung gehört an das im Canvas festgelegte Enddatum, nicht danach. Drei mögliche Ausgänge:

• Skalieren, wenn die KPIs die vorher definierten Schwellenwerte erreichen und die Nutzenden den Prozess erkennbar freiwillig weiternutzen wollen. Beide Bedingungen zählen – gute Zahlen bei gleichzeitiger Ablehnung im Team sind ein Warnsignal, keine Erfolgsmeldung.
• Anpassen und erneut testen, wenn Teilergebnisse vielversprechend sind, aber einzelne KPIs verfehlt wurden oder sich während des Piloten neue Erkenntnisse zum Prozess ergeben haben. Ein zweiter, kürzerer Testlauf mit angepasstem Scope ist hier oft sinnvoller als ein sofortiger Rollout auf Verdacht.
• Einstellen, wenn die Kriterien klar verfehlt wurden oder sich herausstellt, dass der Prozess aus anderen Gründen (Datenlage, Akzeptanz, Aufwand) nicht der richtige Fall für diese Lösung ist. Das ist kein gescheitertes Projekt, sondern ein Pilot, der genau das getan hat, wofür er da war: eine offene Frage vor dem großen Investment beantworten.

Zusätzlich zum Enddatum lohnen sich vorab festgelegte Stopp-Kriterien für den Fall, dass etwas früher schiefgeht – etwa eine deutlich erhöhte Fehlerquote mit spürbaren Folgen oder ein Datenschutzproblem. Diese Kriterien gehören ins Pilot-Canvas, nicht in eine Ad-hoc-Entscheidung mitten im Testbetrieb.

Risiken & Grenzen

Ein paar ehrliche Einschränkungen zur Pilotplanung:

• Ein erfolgreicher Pilot ist kein Beweis für den Rollout. Er zeigt, dass etwas unter den getesteten Bedingungen funktioniert hat – mit diesem Team, dieser Datenmenge, diesem Zeitraum. Skalierung bringt neue Randfälle, mehr Nutzende und oft eine tiefere Systemintegration, die im Pilotmaßstab nicht sichtbar war.
• KPIs lassen sich manipulieren, wenn man es will. Ein zu eng gefasster Erfolgsmaßstab (z. B. nur die einfachsten Vorgänge in den Piloten aufnehmen) liefert scheinbar gute Zahlen, die sich im Regelbetrieb nicht halten. Der Scope aus dem Canvas sollte deshalb repräsentativ für den späteren Regelbetrieb sein, nicht für die besten Fälle ausgewählt.
• Rechtliche und Datenschutzfragen gehören vor den Pilotstart, nicht ins Nachgang. Sobald personenbezogene Daten verarbeitet werden, gelten die üblichen DSGVO-Anforderungen unabhängig davon, dass es „nur ein Test” ist. Seit Februar 2025 gilt außerdem die KI-Kompetenzpflicht aus Artikel 4 der europäischen KI-Verordnung – Personen, die mit KI-Systemen arbeiten, müssen ausreichende Kenntnisse über deren Grenzen haben. Für Unternehmen, die neue KI-Ansätze unter kontrollierten Bedingungen testen wollen, sieht die Verordnung zudem Reallabore (Regulatory Sandboxes) vor, auch auf EU-Ebene. Stand Juli 2026, keine Rechtsberatung – im Zweifel gehört das Thema zu Datenschutzbeauftragten oder Rechtsberatung.
• Ein Pilot ersetzt keine Strategie. Auch ein sauber geplanter, erfolgreicher Pilot beantwortet nur eine Frage zu einem Prozess. Woher der nächste Use Case kommt und wie mehrere Piloten zu einer sinnvollen Reihenfolge werden, ist eine andere Ebene der Planung.

Checkliste: Pilotprojekt planungsreif?

1. Der Scope lässt sich in einem Satz beschreiben: ein Prozess, ein Team, klare Ausnahmen.
2. Es gibt 2–4 KPIs mit einem gemessenen Ausgangswert vor dem Pilotstart.
3. Die Laufzeit ist festgelegt, inklusive eines konkreten Enddatums für die Entscheidung.
4. Die benötigten Daten sind digital verfügbar, aktuell genug und ihre Nutzung rechtlich geklärt.
5. Die Testnutzenden sind eine repräsentative Gruppe mit realem Zeitbudget für Feedback, nicht nur Freiwillige.
6. Sponsor, Use-Case-Owner und IT/Datenschutz-Zuständigkeit sind benannt.
7. Stopp-Kriterien für einen vorzeitigen Abbruch stehen fest, bevor der Pilot beginnt.
8. „Einstellen” ist als Ergebnis ausdrücklich erlaubt und wird nicht als Scheitern gewertet.
9. Alle drei Entscheidungsoptionen – skalieren, anpassen, einstellen – sind vorab definiert, nicht erst am Ende erfunden.
10. Das Pilot-Canvas ist von Sponsor und Use-Case-Owner gemeinsam abgenommen, nicht nur von einer Person ausgefüllt.

Wenn du diese zehn Punkte für deinen geplanten Piloten mit Ja beantworten kannst, ist er planungsreif. Willst du das Pilot-Canvas gemeinsam mit uns durchgehen oder brauchst du Unterstützung bei der Priorisierung davor? Unser Beratungsangebot mit Prozess-Audit und Pilotbegleitung findest du auf der Startseite; passende Schulungen zur KI-Kompetenz im Team ergänzen die Vorbereitung. Ein kostenloses Erstgespräch klärt in 45 Minuten, ob und wie wir dabei unterstützen können.