Pilot-Framework — vom Use-Case zum belastbaren Ergebnis

Der Pilot ist kein Experiment

Ein KI-Pilot ist kein Spielplatz. Er ist ein strukturierter Versuch mit klarem Rahmen, klaren Zielen und einer klaren Entscheidung am Ende: ausweiten, nachbessern oder beenden.

In dieser Lektion lernen Sie ein Framework, das sich in mittelständischen Unternehmen mehrfach bewährt hat — pragmatisch genug, um ohne schwere Stäbe zu funktionieren, und strukturiert genug, um am Ende eine belastbare Entscheidung zu ermöglichen.

Die sechs Phasen eines KI-Piloten

Phase 1: Discovery (Woche 1 bis 2)

Bevor der Pilot startet, müssen drei Fragen beantwortet sein:

• Was ist der Use-Case genau? Ein bis zwei Sätze, für Externe verständlich.
• Welche Daten braucht er? Welche Systeme, welche Personen, welche Zugriffe.
• Wer sind die Stakeholder? Fachbereich, IT, Datenschutz, mindestens eine Person mit Entscheidungsbefugnis.

Parallel wird eine Baseline-Messung durchgeführt: Wie lange dauert der Prozess heute, wie oft kommt er vor, wie viele Fehler passieren? Ohne Baseline gibt es später keinen Vergleich.

Phase 2: Prototyp (Woche 3 bis 4)

Ein erster funktionierender Prototyp — bewusst mit minimalem Aufwand. Meistens reicht ein direkter Aufruf eines LLM mit einem sauberen Prompt oder eine einfache RAG-Anbindung über Standardwerkzeuge. Ziel ist nicht Perfektion, sondern Machbarkeitsnachweis.

Ein häufiger Fehler: Der Prototyp wird zu schick gebaut, bevor die fachliche Eignung geprüft ist. Das kostet Wochen. Ein Prototyp darf unschön sein, solange er auf echten Daten arbeitet und die Kernfunktion zeigt.

Phase 3: Anwendertests (Woche 5 bis 7)

Drei bis fünf Personen aus dem Fachbereich arbeiten mit dem Prototypen. Keine großangelegten Nutzerbefragungen — tiefe Einzelgespräche, kurze Feedbackschleifen, konkrete Beispielfälle. Hier zeigt sich, ob der Use-Case im Alltag funktioniert oder nicht.

Wichtig: Nutzer-Feedback ist fast nie die unmittelbare Lösung, aber es zeigt, was fehlt. Ein gutes Pilot-Team übersetzt Feedback in konkrete Änderungen am Prompt, am Datenmaterial oder am Ablauf.

Phase 4: Iteration (Woche 6 bis 9, überlappend)

Basierend auf den Tests wird der Prototyp gezielt verbessert — Prompt schärfen, Quellen qualifizieren, Edge-Cases ergänzen. In dieser Phase entsteht auch der erste belastbare Prompt- und Datenstand, der später produktiv werden kann.

Phase 5: Messung (Woche 10 bis 11)

Der optimierte Stand wird gegen die Baseline gemessen:

• Zeit pro Vorgang
• Fehlerrate
• Nutzerzufriedenheit
• Kostenbilanz

Die Messung muss nicht wissenschaftlich sein, aber konsistent. Eine Woche alte und neue Bearbeitungsmethode parallel zu fahren, zeigt oft sehr deutlich, ob sich Investitionen lohnen.

Phase 6: Entscheidung (Woche 12)

Am Ende steht eine formale Entscheidung mit drei Optionen:

• Ausweiten: Der Pilot erfüllt die vereinbarten Kriterien. Jetzt wird die nächste Projektphase mit Fachbereich, IT, Datenschutz und Freigabeverantwortlichen geplant.
• Nachbessern: Die Wirkung ist da, aber Qualität oder Bedienung genügen nicht. Ein zweiter Pilot-Zyklus wird geplant.
• Abbrechen: Die Wirkung ist zu gering, die Risiken zu hoch, der Use-Case zu unpassend. Der Lernwert bleibt, das Projekt endet.

Ein begründeter Abbruch ist kein Scheitern, sondern ein mögliches Ergebnis des Rahmens. Entscheidend ist, dass die Entscheidung anhand der vorab festgelegten Kriterien dokumentiert wird.

Was in jedem Piloten schriftlich fixiert sein muss

Drei Dokumente sind Pflicht:

• Pilot-Charter. Zwei Seiten: Use-Case, Ziele, KPIs, Baseline, Scope, Budget, Zeitrahmen, Entscheider.
• Risiko- und Compliance-Check. Welche personenbezogenen Daten werden verarbeitet? Gibt es eine Rechtsgrundlage? Sind Geschäftsgeheimnisse betroffen? Die Einordnung nach EU AI Act sollte anhand des Verordnungstexts und der aktuellen Umsetzungshinweise der EU-Kommission projektspezifisch geprüft werden.
• Abschlussbericht. Ergebnisse, Empfehlung, Lessons Learned. Auch ein abgebrochener Pilot liefert wertvolle Inhalte für den nächsten.

Drei häufige Fehler bei der Pilot-Durchführung

Fehler 1: Kein Fachbereichs-Lead. Der Pilot läuft allein in der IT. Am Ende weiß niemand im operativen Geschäft, was er damit anfangen soll.

Fehler 2: Kein Enddatum. Piloten, die "bis Herbst" oder "mal schauen" laufen, finden kein Ende. Ein fester Entscheidungspunkt zwingt zu Fokus.

Fehler 3: Zu viele Piloten parallel. Die tragbare Zahl paralleler Piloten hängt von Fachbereich, IT, Datenschutz und Entscheidungswegen ab. Planen Sie nur so viele, wie diese Rollen tatsächlich begleiten und bewerten können.

Was Sie aus dieser Lektion mitnehmen

Ein belastbarer Pilot hat klare KPIs, eine Baseline-Messung und endet mit einer expliziten Entscheidung. Ausweiten, nachbessern oder abbrechen sind gleichwertige Ergebnisse. Im nächsten Kapitel geht es um eine der zentralen strategischen Fragen: selbst bauen oder kaufen?