Warum die meisten KI-Pilotprojekte scheitern (und wie Sie eines bauen, das besteht)

KI-Pilotprojekte lassen sich leicht starten und schwer beenden. In den meisten Schweizer KMU folgt die erste Begegnung mit generativer KI einem vertrauten Muster: Ein Teammitglied meldet sich für ein Tool an, testet einige eindrückliche Prompts, zeigt die Ergebnisse in einer Besprechung – und jemand ruft ein Pilotprojekt aus. Wenige Wochen später lässt die Begeisterung nach, das Tool wird seltener genutzt und das Projekt leise unter «Lessons Learned» abgelegt.

Der Fehler ist selten technischer Natur. Das Modell funktioniert in der Regel. Das Problem ist, dass das Pilotprojekt darauf ausgelegt war, eine Demo zu liefern – nicht zu verändern, wie die Arbeit erledigt wird.

Die Pilotfalle

Die meisten gescheiterten KI-Pilotprojekte teilen dieselbe DNA. Sie beginnen mit dem Tool, nicht mit dem Workflow. Sie messen Aktivität statt Ergebnisse. Und sie behandeln das Pilotprojekt als Experiment dafür, was KI kann, statt als Test, ob sich eine konkrete Geschäftsaufgabe verbessern lässt.

• Kein klarer Owner: IT baut es, eine Fachabteilung nutzt es, aber niemand ist für Akzeptanz, Qualität oder Ergebnisse verantwortlich.
• Keine Ausgangslage: Das Team kann nicht sagen, wie lange die Aufgabe bisher dauerte, wie oft sie fehlerhaft war oder was «besser» bedeutet.
• Keine Workflow-Integration: Der Agent liefert einen Entwurf in einem Tab, während die eigentliche Arbeit in einem anderen System passiert.
• Keine Leitplanken: Sensible Daten gelangen in das Tool, bevor die Compliance es geprüft hat – und schaffen neue Risiken.
• Keine Abbruchkriterien: Das Pilotprojekt läuft weiter, weil es interessant ist, nicht weil es Nutzen beweist.

Wie ein nützliches Pilotprojekt aussieht

Ein nützliches Pilotprojekt ist auf die richtige Weise langweilig. Es zielt auf eine einzelne, wiederkehrende Aufgabe ab, die bereits echte Zeit kostet. Es hat einen Owner, eine Ausgangslage, eine definierte Erfolgsmetrik und ein klares Entscheidungsdatum. Das Ziel ist nicht zu beweisen, dass KI magisch ist. Das Ziel ist zu beweisen, dass ein bestimmtes Team eine bestimmte Aufgabe schneller, konsistenter oder mit weniger Nacharbeit erledigen kann – und dabei Ihre Governance-Regeln einhält.

• Ein Workflow: HR-Richtlinien beantworten, Support-Tickets triagieren oder wöchentliche Projektupdates entwerfen – nicht alles auf einmal.
• Ein Owner: eine Fachperson, die das Problem spürt und entscheiden kann, was gut aussieht.
• Eine Metrik: Dauer bis zur Fertigstellung, Korrekturquote, Reaktionszeit oder Selbstständigkeit der Mitarbeitenden.
• Eine Grenze: welche Dokumente der Agent nutzen darf, welche Aktionen eine menschliche Freigabe brauchen und welche Daten ausgeschlossen bleiben.

Starten Sie mit einer Ausgangslage, nicht einem Benchmark

Bevor ein Agent gebaut wird, dokumentieren Sie, wie die Aufgabe heute abläuft. Wie lange dauert sie? Wer ist beteiligt? Wo bleiben Mitarbeitende hängen? Wie oft ist das Ergebnis falsch oder unvollständig? Diese Ausgangslage ist die Messlatte für das Pilotprojekt. Ohne sie ist jedes Ergebnis nur eine Anekdote.

Die Ausgangslage zeigt auch, ob das Problem wirklich für KI geeignet ist. Manche Aufgaben sind langsam, weil der Prozess unklar ist, nicht weil den Menschen Hilfe fehlt. Wenn die Quelldokumente sich widersprechen oder der Freigabeprozess defekt ist, bringt ein Agent diese Probleme nur schneller ans Licht. Beheben Sie den Workflow zuerst, automatisieren Sie dann.

Wählen Sie eine Entscheidung, nicht ein Modell

Der häufigste Anfangsfehler ist die Frage: «Welches Modell sollen wir verwenden?» Die bessere Frage lautet: «Welche Entscheidung oder Übergabe wollen wir verbessern?» Modelle sind austauschbar. Der Workflow nicht. Ein kleineres Modell, angebunden an die richtigen Dokumente und den richtigen Freigabeschritt, schlägt ein Frontier-Modell, das Fragen in einem Chat-Tab beantwortet, den niemand prüft.

Wählen Sie für ein erstes Pilotprojekt eine Aufgabe, bei der der Agent vorbereitet oder empfiehlt und eine Person entscheidet. Das hält das Risiko gering und den Nutzen leicht messbar. Sobald dieser Workflow verlässlich läuft, können Sie mehr Autonomie hinzufügen.

Messen Sie Akzeptanz, nicht nur Output-Qualität

Eine wunderschöne Antwort, die niemand nutzt, ist kein Erfolg. Das wichtigste Signal im ersten Monat ist, ob das Team den Agenten dem alten Weg vorzieht. Wenn nicht, liegt es meist an einem von drei Gründen: Der Agent ist langsamer, die Antworten sind nicht vertrauenswürdig oder das Ergebnis passt nicht in die bestehenden Tools.

• Akzeptanz: Wie oft nutzen die vorgesehenen Anwender den Agenten für die Zielaufgabe?
• Vertrauen: Wie oft prüfen oder überarbeiten Anwender die Ausgabe des Agenten?
• Geschwindigkeit: Wie viel Zeit vergeht vom Auftrag bis zum freigegebenen Ergebnis?
• Qualität: Welcher Anteil der Ergebnisse braucht erhebliche Korrektur?
• Governance: Sind Quellenangaben, Freigaben und Audit-Logs vollständig?

Der 30-Tage-Sanity-Check

Ein Pilotprojekt sollte nicht ins Schleudern geraten. Am Ende jeder Woche sollte der Owner eine kurze Reihe von Fragen beantworten können.

• Woche 1: Ist der Workflow definiert, der Owner benannt und die Ausgangslage dokumentiert?
• Woche 2: Sind die Quelldokumente verbindlich, aktuell und berechtigt?
• Woche 3: Liefert der Agent Antworten, die Anwender anhand der Quellen prüfen können?
• Woche 4: Haben Akzeptanz und Qualität die Erfolgsmetrik erreicht? Falls nicht, was ändern wir vor einer Erweiterung?

Wenn die Antwort in Woche vier unsicher ist, ist das kein Problem. Das Ziel eines Pilotprojekts ist es, kostengünstig zu lernen. Aber das Lernen sollte explizit sein: Entweder den Workflow korrigieren, die Metrik neu definieren oder stoppen.

Wann Sie erweitern sollten

Erweitern Sie erst, nachdem ein Pilotprojekt in einem Workflow wiederholbaren Nutzen gezeigt hat. Der nächste Agent sollte dieselben Kontrollen wiederverwenden: freigegebene Quellen, rollenbasierte Zugriffe, begrenzte Tools und menschliche Freigabe für folgenschwere Aktionen. Widerstehen Sie der Versuchung, «alle unsere Dokumente» anzubinden, sobald der erste Agent funktioniert. Scope Creep verwandelt kontrollierte Pilotprojekte in Shadow AI.

Wie yeos Ihnen hilft, Pilotprojekte zu etablieren, die bleiben

yeos ist für kontrollierte Pilotprojekte konzipiert. Statt einem allgemeinen Chatbot Zugriff auf alles zu geben, erstellen Sie einen abgegrenzten Agenten für einen Workflow, binden nur die Dokumente an, die er braucht, und definieren genau, was er tun darf.

• Abgegrenzte Agenten: Jeder Agent hat einen klaren Zweck, einen Wissensbestand und eine definierte Werkzeugausstattung.
• Quellengestützte Antworten: Anwender können die Dokumente hinter jeder Antwort öffnen – Vertrauen entsteht durch Belege.
• Rollenbasierte Zugriffe: Steuern Sie, wer den Agenten nutzen darf und auf welches Wissen er zugreifen kann.
• Audit-Logs: Prüfen Sie, was gefragt wurde, welche Quellen verwendet wurden und welche Aktionen vorgeschlagen wurden.
• Schweizer Hosting: Daten bleiben in der Schweiz unter Schweizer Jurisdiktion, ohne Kundendaten für das Modelltraining zu verwenden.

Starten Sie mit einem Workflow, behalten Sie bei folgenschweren Aktionen einen Menschen im Prozess und messen Sie die Akzeptanz. So wird ein Pilotprojekt zu einem Workflow.