So führst du einen 90-Tage-KI-Piloten durch, der wirklich in Produktion geht

Warum die meisten KI-Piloten scheitern

Lass mich direkt sein: Die meisten KI-Piloten scheitern nicht, weil die Technologie nicht funktioniert hat. Sie scheitern, weil sie nie dafür designt waren, die Produktion zu erreichen. Sie haben eine glänzende Demo statt eines teuren Prozesses gewählt, sie haben nie eine Baseline gesetzt, an der man messen kann, und sie hatten keinen Plan für die langweiligen 20 Prozent, die ein echtes System abdecken muss. Also produzieren sie eine beeindruckende Demo, ein vages gutes Gefühl und nichts, das in Produktion geht.

Ein Pilot ist kein Wissenschaftsexperiment. Er ist die erste Phase eines Produktionssystems, klein und gemessen gefahren, damit du auf Basis von Evidenz statt Hoffnung entscheiden kannst, ob du skalierst. Neunzig Tage reichen, um einen sauber gescopten Use Case zu beweisen oder zu beerdigen, wenn du ihn mit Disziplin fährst. Dieser Guide ist diese Disziplin.

Ein guter Pilot beantwortet eine Frage mit einer Zahl: Schlägt dieser Prozess, automatisiert, die manuelle Baseline deutlich genug, um die Skalierung zu rechtfertigen. Alles andere ist Theater.

Wir fahren KI-Projekte genau so, und wir beweisen Patterns auf unseren eigenen Produkten, Exfinity und OGuardAI, bevor wir sie zu Kunden bringen. Das ist das Playbook. Für die Business-Perspektive, was du automatisieren solltest, siehe unseren Guide Echte KI ist kein Chatbot, und das ist Kernarbeit unserer KI-Services und unseres Consultings.

Wen was interessiert

Die Regel: Wähle den Prozess, nicht die Demo

Die wichtigste Entscheidung überhaupt ist, was du pilotierst, und sie fällt vor jeder Zeile Code. Das richtige Ziel ist nicht das beeindruckendste, sondern das am häufigsten wiederholte und teuerste.

Bewerte Kandidatenprozesse auf drei Achsen.

High volume?           ──▶ yes ──┐
Rule-heavy with        ──▶ yes ──┼──▶ pilot this
   exceptions?                   │
A person spends hours  ──▶ yes ──┘
   on the boring 80%?

Ein Prozess, der tausende Male im Jahr läuft und Senior-Zeit frisst, ist ein starker Pilot. Ein Prozess, der nur gelegentlich läuft, ist keinen Custom Build wert, egal wie interessant. Unser Consulting-Team hilft dabei, das ehrlich zu bewerten, und unsere Use Cases zeigen, wie gute Kandidaten aussehen.

Setze die Baseline, bevor du baust

Du kannst nicht beweisen, dass ein Pilot funktioniert hat, wenn du nie gemessen hast, was er ersetzt. Miss vor jeder Zeile Code den manuellen Prozess: wie lange er dauert, was er kostet, wie oft er Fehler macht, wie das Team ihn empfindet. Diese Baseline ist der Maßstab, und sie vorab zu vereinbaren verhindert das "es fühlt sich besser an"-Argument, das jede ernsthafte Bewertung killt.

Ohne das ist der Erfolg des Piloten Meinungssache. Mit ihr ist die Skalierungsentscheidung reine Arithmetik. Unser KI-Observability-Guide zeigt, wie du das von Tag eins an instrumentierst.

Die 90 Tage, Phase für Phase

So sieht ein Pilot aus, der zu einer echten Entscheidung führt.

Wochen 1 bis 3: Scope und Baseline. Wähle den Prozess, miss die manuelle Version, definiere als Zahl, was "besser" bedeutet, und designe das kleinste System, das es beweisen könnte. Noch nichts bauen außer einem Spike.

Wochen 4 bis 8: Baue den Kern. Baue das Retrieval oder die Pipeline oder den Agenten, auf Produktionsfundamenten, nicht als Wegwerfversion. Verdrahte die menschliche Review-Queue von Anfang an, denn die Ausnahmen sind Teil des Systems, kein Nachgedanke.

Wochen 9 bis 11: Lauf auf echten Daten. Schick echte Arbeit parallel zum manuellen Prozess durch das System und miss gegen die Baseline. Beobachte die Confidence- und Fehlerzahlen, nicht nur den Happy Path.

Woche 12: Entscheide. Vergleiche mit der Baseline und triff einen ehrlichen Ship-or-Kill-Call. Wenn die Zahlen halten, hast du die erste Phase eines Produktionssystems, keine Demo zum Neubauen.

Weeks 1-3    Scope + baseline
Weeks 4-8    Build core + human loop
Weeks 9-11   Real data, measured
Week 12      Ship-or-kill decision

Die zentrale Disziplin: Baue auf Fundamenten, die Produktion werden können, damit ein erfolgreicher Pilot expandiert, statt weggeworfen und neu gebaut zu werden. Diesen Übergang behandeln wir in unserem Prototyp-zu-Produktion-Guide.

Ein durchgerechnetes Beispiel: ein Support-Triage-Pilot

Machen wir das Playbook mit einem Piloten konkret, einem Support-Ticket-Triage-System, das erste Antworten entwirft.

Weeks 1-3   Baseline: measure current triage. A ticket takes 8 minutes
            to first response on average, 400 tickets a week, agents
            spend most of it finding the right policy. Define "better":
            cut time-to-first-response, hold quality, at 80% coverage.
Weeks 4-8   Build: retrieval over the policy base, a draft-reply agent,
            and a review queue where an agent edits and sends. Built on
            production foundations, not a throwaway.
Weeks 9-11  Real data: run it beside the manual process on live tickets.
            Measure time saved, edit rate (how often agents change the
            draft), and any wrong policy cited.
Week 12     Decide: drafts are used with light edits on most tickets,
            time-to-first-response is down meaningfully, wrong-policy
            rate is at or below the manual baseline. Ship it, expand
            to the next queue.

Sieh dir an, was es funktionieren ließ. Es gab eine echte Baseline, also war "besser" eine Zahl, kein Gefühl. Die Review-Queue war von Tag eins da, also blieb die Qualität unter Kontrolle und die Agents sahen ein Tool, das ihnen hilft. Und es wurde gebaut, um Produktion zu werden, also hieß Shippen Expandieren, nicht Neubauen. Wäre stattdessen die Edit-Rate hoch gewesen und die Rate falsch zitierter Policies gestiegen, wäre das ein klares Iterate-or-Kill-Signal, und genau das in 90 Tagen für überschaubare Kosten herauszufinden ist der Punkt. Unser Prototyp-zu-Produktion-Guide behandelt den Expansionsschritt.

Shippe mit einem Menschen im Loop

Ein Pilot, der eine Urteilsaufgabe voll automatisiert, ist kein Pilot, sondern ein Haftungstest. Das richtige Design hält von Tag eins einen Menschen auf den Ausnahmen und auf allem mit hohem Einsatz. Das System übernimmt das Volumen, ein Mensch übernimmt die Ränder, und du misst, wie viel Volumen das System sicher tragen kann.

Das ist das Human-in-the-Loop-Pattern, und in einem Piloten leistet es Doppeltes: Es hält Fehler unter Kontrolle, während du lernst, und es zeigt dem Team, dass das Tool ihm hilft, statt es zu ersetzen, was für die Adoption enorm zählt. Unser KI-Governance-Guide behandelt die Verantwortungsseite.

Kläre Compliance im Piloten, nicht danach

Der schnellste Weg, einen vielversprechenden Piloten zu killen, ist beim Scale-up festzustellen, dass er nie durch eine Datenschutz- oder EU-AI-Act-Prüfung gekommen wäre. Kläre das während des Piloten. Wenn der Prozess personenbezogene Daten berührt, schütze sie von Anfang an an der Grenze, wie in unserem PII-sicheren RAG-Guide beschrieben. Wenn er regulierte Entscheidungen berührt, halte die menschliche Aufsicht und den Audit-Trail von Tag eins drin. Ein Pilot, der Compliance ignoriert, ist keine kleinere Version des Produktionssystems, sondern ein anderes System, das nicht skalieren kann. Unser DSGVO-und-KI-Guide zeigt, was du einbauen musst.

Signale, dass du bereit für einen Piloten bist

Ein Pilot lohnt sich, wenn mehrere dieser Punkte zutreffen.

• Du hast einen konkreten Prozess im Kopf, der hochvolumig und repetitiv ist und Senior-Zeit für den langweiligen Teil frisst.
• Die Führung will Beweise, bevor sie sich auf einen größeren Build festlegt, und eine Demo reicht nicht, um sie zu überzeugen.
• Ein früherer KI-Anlauf ist im Demo-Stadium stecken geblieben und hat nie die Produktion erreicht, und das willst du nicht wiederholen.
• Du kannst eine Baseline benennen, gegen die du messen würdest, oder du bist bereit, die ersten Wochen in ihre Erhebung zu stecken.
• Du hast Zugang zu echten Daten und einen Prozess-Owner, der mitzieht, nicht nur eine Idee auf einer Folie.

Wenn das meiste davon zutrifft, bist du bereit, und die 90-Tage-Struktur gibt dir eine klare Ship-or-Kill-Antwort. Wenn du den Prozess oder die Baseline nicht benennen kannst, ist das das erste Gespräch, und unser Consulting-Team macht genau dieses Scoping. Ein Pilot ohne Ziel ist nur eine Demo mit Deadline, die Bereitschaft steckt also in den Details, nicht im Enthusiasmus.

Die Entscheidung: Skalieren, Iterieren oder Killen

Am Ende triffst du einen von drei ehrlichen Calls, und alle drei sind gute Ergebnisse.

Skalieren, wenn die Zahlen die Baseline deutlich genug schlagen, um es zu rechtfertigen. Iterieren, wenn es knapp ist und du den konkreten Fix siehst. Killen, wenn es nicht funktioniert, und einen schlechten Piloten günstig zu killen ist ein Erfolg, kein Scheitern, denn du hast es in 90 Tagen statt in einem Jahr herausgefunden. Der ganze Sinn der Disziplin ist, diese Entscheidung günstig und klar zu machen. Dann nimmst du den nächsten Prozess. Unsere Methodik ist um genau diese stufenweise, evidenzgetriebene Expansion gebaut. Starte über Kontakt oder hol dir ein gescoptes Angebot.

Wie das typischerweise schiefgeht

1. Die Demo pilotieren, nicht den Prozess. Wähle den am häufigsten wiederholten, teuersten Workflow, nicht den glänzendsten.
2. Keine Baseline. Ohne ein gemessenes Vorher ist Erfolg eine Meinung. Miss zuerst.
3. Ein Wegwerf-Prototyp. Baue auf Produktionsfundamenten, damit Erfolg expandiert, statt neu gebaut zu werden.
4. Kein Human Loop. Vollautomatisierung von Urteilsaufgaben shippt Fehler. Halte einen Menschen auf den Ausnahmen.
5. Compliance als Nachgedanke. Ein Pilot, der sie ignoriert, kann nicht skalieren. Baue sie ein.
6. Keine Kill-Kriterien. Definiere vorab, wie Scheitern aussieht, damit du einen schlechten Piloten günstig beenden kannst.

Wer das baut

Oronts ist ein gründergeführtes Softwareunternehmen in München. Refaat Al Ktifan, unser Gründer und Solution Architect, führt ein Senior-Team, das KI-Piloten shippt, die dafür designt sind, die Produktion zu erreichen, nicht zu beeindrucken und stecken zu bleiben. Wir beweisen Patterns auf unseren eigenen Produkten, Exfinity und OGuardAI, bevor wir sie zu Kunden bringen. Wir scopen den Prozess, setzen die Baseline, bauen auf Produktionsfundamenten und geben dir eine Ship-or-Kill-Entscheidung mit einer Zahl dahinter. Siehe unsere Seiten Services und Solutions.

Takeaways

• Ein Pilot ist die erste Phase eines Produktionssystems, kein Wissenschaftsexperiment.
• Wähle den am häufigsten wiederholten, teuersten Prozess, nicht die beeindruckendste Demo.
• Setze eine gemessene Baseline, bevor du baust, damit die Skalierungsentscheidung Arithmetik ist, keine Meinung.
• Baue auf Produktionsfundamenten und shippe von Tag eins mit einem Menschen im Loop.
• Beende mit einem ehrlichen Ship-or-Kill-Call. Einen schlechten Piloten günstig zu killen ist ein Gewinn.

Neunzig Tage reichen, um es zu wissen. Die Disziplin ist nicht Geschwindigkeit, sondern Ehrlichkeit: ein echtes Ziel, eine echte Baseline und der Mut, es zu killen, wenn die Zahl nicht hält.

Bereit für einen Piloten, der sauber shippt oder stirbt? Nenn uns den Prozess. Starte über Kontakt oder hol dir ein gescoptes Angebot.