Der Pilot-Friedhof: warum die meisten KI-Agenten nie in Produktion gehen
Auf den meisten Roadmaps steht irgendwo „KI-Agent für Prozess X“ — und ein Jahr später steht dort noch immer dasselbe, nur mit einem neuen Datum. Das Muster wiederholt sich: Ein Agentic-AI-Prototyp funktioniert in der Demo beeindruckend, verschwindet danach aber in einer Warteschleife aus „wir müssen erst noch prüfen“, „das Datenschutzteam hat Rückfragen“ und „eigentlich bräuchten wir noch ein Feature“. Nach sechs Monaten gibt es einen Prototyp, aber keinen Betrieb.
Die Agentic-AI-Infrastruktur selbst ist dabei selten das Problem. Runtime, Tool-Gateway und Observability sind heute solide genug, um einen einzelnen gut abgegrenzten Vorgang zuverlässig zu automatisieren. Was fehlt, ist ein Fahrplan, der die richtige Reihenfolge erzwingt — und ein Punkt, an dem ein Projekt ehrlich beendet werden darf, statt endlos in der Warteschleife zu verharren.
Der Grund ist fast nie die Modellqualität. Es ist die Reihenfolge. Teams starten mit einem Use Case, der sich gut anhört, aber nicht messbar ist, geben dem Agenten zu früh Rechte, die ein Restrisiko bergen, und haben keinen Punkt definiert, an dem sie ehrlich sagen könnten: Das funktioniert nicht, wir brechen ab. Ohne diesen Punkt läuft ein Pilot nicht auf ein Ergebnis zu — er läuft aus.
Die These dieses Artikels: 90 Tage reichen für einen einzelnen, gut gewählten Use Case bis zur Betriebsübergabe mit eng begrenztem Aktionsrecht — nicht für eine unternehmensweite Automatisierung. Wer das akzeptiert, kommt tatsächlich in Produktion. Wer mehr will, bekommt meist wieder einen Prototyp.
Die Auswahl des ersten Use Case: ein Kriterium entscheidet
Bevor ein einziger Sandbox-Zugang beantragt wird, sollte eine Frage beantwortet sein: Lässt sich das Ergebnis dieses Use Case maschinell prüfen? Nicht durch eine Person, die sagt „sieht gut aus“, sondern durch eine automatisierte Prüfung, die zwischen richtig und falsch unterscheidet, ohne dass jemand zusieht.
Konkret heißt das: Ein Test in der Eval-Suite läuft grün oder rot. Eine Summe stimmt mit der Bestellung überein oder nicht. Eine Ausgabe validiert gegen ein Schema mit Typen und Wertebereichen — oder sie tut es nicht. Ein Datensatz zum Abgleich existiert bereits im ERP, im Ticketsystem oder im Monitoring — oder er existiert nicht. Diese vier Muster sind die einzigen, mit denen sich der Fortschritt eines Piloten objektiv messen lässt.
Warum das der häufigste Bruchpunkt ist
Use Cases wie „bessere interne Kommunikation“, „schnellere Entscheidungsfindung“ oder „intelligentere Priorisierung“ hören sich in der Projektpräsentation überzeugend an. Sie scheitern aber am selben Problem: Niemand kann nach vier Wochen mit einer Zahl belegen, ob es besser geworden ist. Ohne Erfolgskriterium wird jede Bewertung zur Meinungsfrage, und Meinungsfragen enden fast immer mit „lass uns noch etwas beobachten“ — dem Vorzimmer des Pilot-Friedhofs.
Die Rechnungsprüfung, die Klassifizierung von Support-Tickets — deren wirtschaftlicher Nutzen sich, wie im Artikel Support-Deflection: die Rechnung vorgerechnet, unmittelbar in Fallzahlen ausdrücken lässt —, der Abgleich von Wareneingang gegen Bestellung oder ein Migrationsschritt mit automatisierten Tests sind deshalb bessere erste Kandidaten als kreative oder beratende Aufgaben — nicht weil sie wichtiger wären, sondern weil sie überhaupt einen Maßstab liefern. Wer bereits eine Eval-Suite oder eine vergleichbare Testbasis für seinen bevorzugten Use Case besitzt, hat die halbe Auswahlarbeit bereits erledigt.
Auch die Systemintegration selbst folgt diesem Prinzip: Ein Agent, der über MCP an bestehende Systeme angebunden wird, sollte zunächst an genau eine gut dokumentierte Schnittstelle andocken, nicht an fünf gleichzeitig. Wie eine solche Systemintegration technisch sauber aufgebaut wird, ist Thema eines eigenen Artikels dieser Serie — hier zählt vor allem, dass die erste Anbindung schmal und beherrschbar bleibt.
Woche 1: Sandbox mit einem echten Vorgang
Der Fahrplan beginnt nicht mit einer Konzeptphase, sondern mit einem einzigen echten Fall. Im Quickstart wird in einem rund 45-minütigen gemeinsamen Termin Zugang eingerichtet, ein Projekt angelegt, ein MCP-Server für genau ein lesendes Werkzeug registriert und eine erste Policy hinterlegt. Dann läuft der Agent gegen einen realen Vorgang — eine echte Rechnung, ein echtes Ticket, einen echten Datensatz.
Woche 1 im Überblick
Ziel: Nachweis, dass der Agent den Vorgang technisch greifen kann — Zugriff auf die Datenquelle, brauchbare Extraktion, ein lauffähiger Trace.
Beteiligte: eine Fachperson mit dem echten Fall, ein Ansprechpartner aus dem IT-Betrieb für Zugänge und Netzwerk, ein Agent-Engineer.
Abbruchkriterium: Die Datenquelle ist nicht zugänglich, das Format ist so unstrukturiert, dass keine Schema-Validierung möglich ist, oder der Vorgang erfordert bereits im ersten Schritt eine juristische statt eine faktische Bewertung.
Am Ende liegt vor: ein funktionierender Sandbox-Lauf mit Trace und Wiederholbarkeit (agentctl replay), der reale Fall als erste Eval-Fixture.
Diese Woche entscheidet mehr als jede andere über den Rest des Projekts. Wenn der Agent an der Datenquelle oder am Format scheitert, ist das kein Rückschlag — es ist genau die Information, die verhindert, dass drei weitere Monate in einen ungeeigneten Use Case fließen.
Woche 2 bis 4: Lesender Betrieb
Ab Woche 2 läuft der Agent parallel zum bestehenden menschlichen Prozess — ausschließlich lesend, ohne eine einzige Aktion auszulösen. Aus dem ersten Fall wird eine wachsende Eval-Suite: 30 bis 50 reale Fälle, gegen die der Agent seine Einschätzung abgibt, die dann mit der tatsächlichen menschlichen Entscheidung verglichen wird.
Woche 2 bis 4 im Überblick
Ziel: eine belastbare Trefferquote auf einer wachsenden Eval-Suite, ohne dass der Agent produktiv etwas verändert.
Beteiligte: Fachbereich mit mehr Zeitanteil, Datenschutz zur Prüfung des Leserechts (welche personenbezogenen Daten sind im Scope, Eintrag im Verarbeitungsverzeichnis), IT-Betrieb für Monitoring und Log-Pipeline.
Abbruchkriterium: Die Trefferquote bleibt über mehrere Nachbesserungsrunden unter der vorher festgelegten Schwelle — meist ein Zeichen, dass der Use Case doch mehr Kontext oder Ermessen braucht, als angenommen.
Am Ende liegt vor: eine dokumentierte Eval-Suite mit Baseline-Genauigkeit, ein DSGVO-Kurzcheck des Leserechts, erste Observability-Daten aus echten Läufen.
Diese Phase ist die günstigste im ganzen Fahrplan, weil noch nichts automatisiert entschieden wird — und gleichzeitig die aufschlussreichste, weil sie zeigt, wie gut der Agent tatsächlich ist, bevor irgendein Risiko eingegangen wird.
Woche 5 bis 8: Eng begrenztes Aktionsrecht mit Freigabeschwelle
Erst jetzt, mit einer belastbaren Eval-Baseline im Rücken, bekommt der Agent ein erstes Aktionsrecht — und zwar strikt begrenzt. Unterhalb einer definierten Schwelle (ein Betrag, eine Konfidenz, eine Kategorie) darf er selbst handeln, etwa einen Buchungsvorschlag erzeugen oder ein Ticket automatisch klassifizieren. Oberhalb der Schwelle oder bei Unsicherheit geht der Fall weiterhin an eine Person. Das ist der Kern von Human-in-the-Loop: nicht jeder Schritt wird kontrolliert, aber jeder kritische Schritt hat eine definierte Freigabeschwelle.
Woche 5 bis 8 im Überblick
Ziel: produktive Entlastung unterhalb der Freigabeschwelle, saubere Eskalation oberhalb davon.
Beteiligte: Fachbereich zur Festlegung der Schwelle, IT-Betrieb für Policy und Kostendeckel, Betriebsrat — sobald der Agent Vorgänge beeinflusst, die Rückschlüsse auf Verhalten oder Leistung von Mitarbeitenden zulassen könnten, gehört er spätestens jetzt an den Tisch.
Abbruchkriterium: Ein Vorfall zeigt, dass ein Fehler nicht sauber zurückgerollt werden kann, oder die Freigabeschwelle wird derart häufig ausgelöst, dass keine reale Entlastung entsteht.
Am Ende liegt vor: eine dokumentierte Policy (tools.policy.yaml) mit Freigabewegen, ein gesetzter Kostendeckel je Lauf, erste echte Betriebszahlen.
Die Freigabeschwelle ist bewusst kein Kompromiss, sondern die eigentliche Erfindung dieser Phase: Sie erlaubt Automatisierung genau dort, wo das Risiko gering und die Eval-Basis stark ist, und verweigert sie dort, wo beides nicht zutrifft — ohne dass jemand jeden einzelnen Lauf beobachten müsste.
Rechte so eng wie möglich, nicht so weit wie bequem
Technisch stützt sich diese Phase auf zwei Prinzipien, die in dieser Serie ausführlicher behandelt werden: Agent Identity statt geteilter Admin-Zugänge, damit jede Aktion eindeutig einem Lauf zurechenbar bleibt, und Zero Trust als Grundhaltung — jeder Tool-Aufruf wird geprüft, keiner gilt automatisch als vertrauenswürdig, nur weil er vom eigenen Agenten kommt. Ergänzend setzt die Runtime auf Durable Execution: Bricht ein Lauf mitten im Tool-Call ab, muss er sauber und ohne doppelte Buchung wiederaufgenommen werden können — genau das prüft das Abbruchkriterium dieser Phase. Wie Schatten-KI und unsauber vergebene Rechte in der Praxis zum Sicherheitsrisiko werden, zeigt der Artikel KI-Agenten im Unternehmen: Die neue Angriffsfläche.
Woche 9 bis 12: Ausweitung und Betriebsübergabe
In der letzten Phase wächst der Scope vorsichtig — mehr Fallarten, ein etwas höheres Volumen, in kleinen Schritten angehobene Schwellen, jeweils erneut gegen die Eval-Suite geprüft. Parallel wandert die Verantwortung vom Projektteam in den regulären Betrieb: Dashboards, Kostenüberwachung, ein definierter Ansprechpartner für Störungen, die passende Service-Klasse für Reaktionszeiten.
Woche 9 bis 12 im Überblick
Ziel: ein Agent, der ohne das ursprüngliche Projektteam weiterläuft.
Beteiligte: IT-Betrieb als neuer Owner, Fachbereich für laufende Qualitätskontrolle, Geschäftsführung für Freigabe der laufenden Kosten.
Abbruchkriterium: Der Betrieb findet keinen internen Owner — ein Agent ohne Ansprechpartner verfällt genauso wie ein Server ohne Patch-Verantwortlichen.
Am Ende liegt vor: ein erster Betriebsreport mit Kosten je erfolgreichem Vorgang, eine festgelegte Service-Klasse, klare Eskalationswege.
Damit endet der 90-Tage-Fahrplan nicht mit „der Agent funktioniert“, sondern mit „der Agent hat einen Betrieb“ — ein Unterschied, den viele Piloten nie erreichen, weil er organisatorisch anstrengender ist als der technische Teil. Zur Betriebsübergabe gehört auch die Wahl der vertraglichen SLA-Klasse: Die Standard-Klasse hat keine zugesicherte Vor-Ort-Reaktion, Business und Enterprise schon — welche Klasse passt, hängt davon ab, wie geschäftskritisch der automatisierte Vorgang inzwischen geworden ist.
Nicht jedes Unternehmen will diesen Betrieb selbst führen. Wer weder ein eigenes Team noch Kapazität für Monitoring und Kostenüberwachung aufbauen möchte, findet in KI Managed Services ein vollständig betreutes Modell von der Sandbox bis zum laufenden Betrieb. Wer aus Datenschutz- oder Compliance-Gründen keine geteilte Cloud-Verarbeitung will, ist mit KI On-Premise besser bedient — technische Details zum eigenen Modellbetrieb liefert der Artikel On-Premise-KI mit vLLM. Und wer den gesamten KI-Stack — von Infrastruktur über Modelle bis zum Anwendungsfall — an einen Partner geben möchte, prüft KI Full-Stack-Providing. Alle drei Wege ändern nichts am 90-Tage-Fahrplan selbst, nur daran, wer die Rolle des IT-Betriebs in Woche 9 bis 12 übernimmt.
Rollen im Projekt: wer wann eingebunden gehört
Ein 90-Tage-Fahrplan scheitert selten an der Technik und häufig an der Organisation — vor allem daran, dass Rollen zu spät oder in falscher Reihenfolge eingebunden werden.
- Fachbereich: von Tag eins an. Definiert das Erfolgskriterium, liefert reale Fälle, entscheidet über Klarfälle. Ohne Fachbereich gibt es keinen realistischen ersten Fall.
- IT-Betrieb: von Tag eins an für Zugänge, Netzwerk und MCP-Server, ab Woche 9 als operativer Owner. Zuständig für Monitoring, Kostendeckel und die spätere Betriebsübergabe.
- Datenschutz: spätestens ab Woche 2, sobald der Agent lesend auf personenbezogene Daten zugreift. Prüft Verarbeitungsverzeichnis, Auftragsverarbeitung nach DSGVO und — bei sensiblen Datenkategorien — die Notwendigkeit einer Datenschutz-Folgenabschätzung. Eine Trust-Seite mit Angaben zu Aufbewahrung, Datenresidenz und AVV-Status erleichtert diese Prüfung erheblich.
- Betriebsrat: spätestens ab Woche 5, sobald Aktionsrechte entstehen oder der Agent Daten verarbeitet, die Rückschlüsse auf Verhalten oder Leistung von Mitarbeitenden zulassen. In der Praxis ist eine frühere Information oft günstiger als eine späte Mitbestimmungsdiskussion unter Zeitdruck — eine rechtliche Einzelfallprüfung ersetzt das nicht.
Praxisbeispiel: Rechnungsprüfung als erster Use Case
Ein Rechenbeispiel für einen Produktionsbetrieb mit rund 200 Mitarbeitenden und 1.850 Eingangsrechnungen pro Monat, angelehnt an das Use-Case-Modell Rechnungsverarbeitung. Vor dem Projekt liegt die Bearbeitungszeit bei 7 Minuten je Beleg, die Klarfallquote bei 18 Prozent, und 6 Prozent der skontofähigen Rechnungen verfallen, weil Klarfälle liegen bleiben.
Annahme: Verlauf über 90 Tage
Woche 1: eine einzelne reale Rechnung im Sandbox-Lauf, Extraktion gegen ein Schema mit Lieferant, Rechnungsnummer, Positionen und Steuersätzen.
Woche 2–4: 40 reale Rechnungen als Eval-Fixtures, lesender Abgleich gegen Bestellung und Wareneingang, parallel zur Buchhaltung — Ergebnis wird verglichen, nicht gebucht.
Woche 5–8: Buchungsvorschlag automatisiert bis zu einer Betragsgrenze und bei eindeutigem Abgleich; alles darüber und jede Abweichung geht als Klarfall an die Buchhaltung. Rund 400 der 1.850 Rechnungen laufen bereits automatisiert durch.
Woche 9–12: Ausweitung auf den vollen Bestand, Übergabe an Buchhaltung und IT-Betrieb als reguläre Fachanwendung.
Ein Rechenbeispiel für die laufenden Kosten in Woche 9 bis 12: bei rund 1.850 Läufen pro Monat, angenommenen 0,05 Euro je Lauf für Modell- und Tool-Aufrufe zuzüglich der Betriebspauschale von 690 Euro für die Einstiegsklasse ergibt sich eine Größenordnung von etwas über 780 Euro pro Monat zuzüglich Umsatzsteuer — eine Annahme zur Einordnung, keine Preisliste. Die tatsächlichen Nutzungsraten hängen vom individuellen Fall ab und werden vor Vertragsschluss durchgerechnet.
Der wirtschaftlich interessanteste Effekt liegt dabei nicht in der reinen Zeitersparnis je Beleg, sondern in der zweiten Zahl: Verfallenes Skonto entsteht fast ausschließlich, weil Belege in Klarfallschleifen liegen bleiben. Wer die Durchlaufzeit senkt, senkt genau dort messbar Kosten.
Sandbox, Pilot und Betrieb im Vergleich
| Stufe | Dauer | Kosten | Ergebnis | Ausstiegspunkt |
|---|---|---|---|---|
| Sandbox (Woche 1) | 1 Woche | Sandbox kostenlos, 45-Minuten-Termin | Ein Lauf, ein Trace, erste Eval-Fixture | Use Case ungeeignet, wenn Datenzugriff oder Format grundsätzlich fehlen |
| Pilot (Woche 2–8) | 7 Wochen | Einstiegspauschale ab 690 €/Monat zzgl. geringem Nutzungsvolumen | Dokumentierte Eval-Baseline, begrenzt produktive Aktionen unterhalb der Schwelle | Trefferquote bleibt unter Zielwert oder Freigabeschwelle wird zu oft ausgelöst |
| Betrieb (ab Woche 9) | laufend | Betriebspauschale nach Volumen (1.490 € / ab 3.900 €) plus nutzungsabhängige Komponenten | Betriebsreport, festgelegte Service-Klasse, aktiver Kostendeckel | Abschaltung jederzeit möglich, keine gebundene Eigeninvestition in Infrastruktur |
Typische Fehler auf dem Weg
- Zu breiter Scope: mehrere Use Cases gleichzeitig starten. Das verteilt Aufmerksamkeit von Fachbereich, Datenschutz und IT-Betrieb und macht Abbruchkriterien unscharf. Ein Use Case, dann der nächste.
- Kein Erfolgskriterium: ohne maschinell prüfbaren Maßstab wird jede Statusrunde zur Meinungsfrage — und Meinungsfragen enden selten mit einer Entscheidung.
- Rechte zu früh: Aktionsrechte vor einer stabilen Eval-Baseline sind der häufigste Grund für Vorfälle, die das gesamte Projektvertrauen kosten.
- Kein Kostendeckel: ohne Budget-Cap je Lauf kann eine fehlerhafte Schleife über Nacht teuer werden — technisch trivial zu verhindern, organisatorisch oft vergessen.
- Kein Ansprechpartner nach Go-Live: das Projektteam wechselt zum nächsten Thema, der Agent bleibt ohne Owner zurück und verwaist wie ein ungepatchter Server.
Wann sich das NICHT lohnt — die Grenzen von 90 Tagen
Der Fahrplan ist ehrlich begrenzt, und das sollte er auch bleiben. In 90 Tagen entsteht ein produktiver erster Use Case — nicht mehr.
- Keine unternehmensweite Orchestrierung: mehrere Agenten über Abteilungsgrenzen hinweg mit gemeinsamen Abhängigkeiten sind ein eigenes Vorhaben mit eigenem Zeitrahmen.
- Kein Ersatz für komplexe juristische Bewertung: Fälle, die Ermessen statt Fakten erfordern, bleiben Handarbeit — der Fahrplan eignet sich nur für Use Cases mit prüfbarem Ergebnis.
- Kein vollständiger Compliance-Nachweis: die High-Risk-Pflichten des EU AI Act nach dem Digital Omnibus greifen erst am 2. Dezember 2027 beziehungsweise 2. August 2028 — wer früh eine saubere Governance-Basis mit Audit-Trail und Freigabewegen aufbaut, spart sich später Nacharbeit, muss aber in 90 Tagen keinen vollständigen Nachweis erbringen. Ein ISO-27001-zertifizierter Betrieb der zugrundeliegenden Infrastruktur ist dabei eine sinnvolle Grundlage, ersetzt aber keine eigene KI-Governance.
- Keine belastbare Kostenoptimierung: Kosten je erfolgreichem Vorgang lassen sich erst mit echtem Volumen sauber senken, nicht schon im Pilotbetrieb.
- Kein internes Kompetenzzentrum: 90 Tage reichen für einen Use Case, nicht für ein Team, das eigenständig weitere Agenten baut.
- Mitbestimmung kann länger dauern: wenn ein Rollout Verhaltens- oder Leistungsdaten von Mitarbeitenden berührt, kann die Abstimmung mit dem Betriebsrat den 90-Tage-Rahmen sprengen — das ist dann kein technisches, sondern ein organisatorisches Zeitfenster.
Ehrlich: Wenn der geplante erste Use Case eines dieser Kriterien braucht, ist er nicht der richtige erste Use Case. Das ist kein Grund, das Projekt zu stoppen — es ist ein Grund, den Use Case zu wechseln.
Häufige Fragen zum 90-Tage-Fahrplan
Wie wähle ich den ersten Use Case für einen KI-Agenten aus?
Über ein einziges Kriterium: Lässt sich das Ergebnis maschinell prüfen? Läuft ein Test grün oder rot, stimmt eine Summe, validiert eine Ausgabe gegen ein Schema, existiert ein Datensatz zum Abgleich. Ohne dieses Kriterium bleibt der Fortschritt Meinungssache.
Was ist ein maschinell prüfbares Erfolgskriterium?
Eine automatisierte Prüfung ohne menschliches Ermessen: ein Eval-Test, eine Summenprüfung, eine Schema-Validierung oder ein Abgleich gegen einen bestehenden Datensatz wie Bestellung oder Ticket-Protokoll.
Wie lange dauert es bis zum ersten produktiven KI-Agenten?
Mit einem gut gewählten Use Case realistisch 90 Tage bis zur Betriebsübergabe mit eng begrenztem Aktionsrecht — nicht bis zur vollständigen Automatisierung aller Fälle.
Ab wann muss der Betriebsrat eingebunden werden?
Spätestens, sobald der Agent Daten mit Rückschluss auf Verhalten oder Leistung berührt oder über reines Lesen hinaus Handlungen auslöst. Frühere Information erspart in der Praxis oft spätere Zeitverluste; eine rechtliche Einzelfallprüfung ersetzt das nicht.
Was kostet ein 90-Tage-Pilot für einen KI-Agenten?
Die Betriebspauschale beginnt bei 690 Euro pro Monat zuzüglich Umsatzsteuer, dazu nutzungsabhängige Komponenten je Lauf, Tool-Aufruf und Million Tokens. Details liefert der Rechner auf der Preisseite.
Wann sollte man einen Piloten abbrechen?
Wenn ein vorab festgelegtes Abbruchkriterium eintritt — Trefferquote bleibt unter Zielwert, Freigabeschwelle wird zu oft ausgelöst, oder ein Vorfall zeigt fehlende Rollback-Fähigkeit.
Was kommt nach den ersten 90 Tagen?
Die Verantwortung wandert in den regulären IT-Betrieb, der Scope wächst schrittweise, und die Kosten je erfolgreichem Vorgang werden zur laufenden Kennzahl.
Kann man mehrere KI-Agenten gleichzeitig einführen?
Technisch ja, empfehlenswert nein — ein zu breiter Scope verteilt Aufmerksamkeit und macht Abbruchkriterien unscharf. Der erste Use Case sollte allein stehen, bevor ein zweiter startet.