Wie ein belastbarer KI-Pilot in 30 Tagen aussieht

Das Wichtigste in Kürze

• Der Pilot untersucht einen Prozess und eine klar benannte Frage.
• Bereits in der zweiten Woche läuft eine dünne, aber vollständige Kette vom Eingang bis zum Ergebnis.
• Qualität, Prüfzeit, Sicherheit und Ausfallverhalten werden gemessen, bevor irgendetwas vorgeführt wird.
• Nach 30 Tagen steht eine Entscheidung: weiterführen, nachschärfen, enger schneiden oder stoppen.

Ein Monat reicht nicht für eine fertige Plattform über mehrere Abteilungen. Er reicht aber für eine belastbare Antwort auf eine enge Frage.

Der Unterschied zu einer Demo liegt im Gegenstand. Eine Demo zeigt, was ein Modell an ausgewählten Fällen kann — und ausgewählt heißt: an den Fällen, die funktionieren. Ein Pilot zeigt, ob ein realer Arbeitsablauf mit echten Daten, Schnittstellen, Fehlern und Mitarbeitenden trägt. Die Demo übersteht jede Vorführung. Der Pilot muss einen gewöhnlichen Dienstagvormittag überstehen.

Nach 30 Tagen muss nicht alles fertig sein. Die wichtigste Unsicherheit muss kleiner sein.

Vor dem Start stehen fünf Festlegungen

• Welche genaue Frage soll der Pilot beantworten?
• Welche Vorgänge und Varianten gehören zum Umfang?
• Welche Qualitätsgrenzen gelten für wichtige Felder?
• Welche Aktionen bleiben sicherheitshalber manuell?
• Wer trifft am Ende die Entscheidung?

Fehlen diese Punkte, wird der Pilot zur offenen Entwicklung. Dann ist nach 30 Tagen viel gebaut, aber wenig entschieden.

Woche 1: Prozess, Daten und Maßstäbe

Die ersten beiden Tage gehören dem Ablauf. Auslöser, Eingaben, Systeme, Schritte, Ausnahmen und das verbindliche Ergebnis werden auf einer Seite beschrieben; der Pilot bekommt einen klaren Anfang und ein klares Ende. An Tag drei und vier entsteht der Testsatz: normale Vorgänge, schwierige Dokumente, frühere Fehler und Fälle, bei denen die Lösung bewusst stoppen soll. Zu jedem Fall wird die fachlich richtige Fassung festgehalten. Diese Sammlung ist unspektakuläre Arbeit und das wertvollste Artefakt des ganzen Monats — sie wird den Piloten überleben.

Tag fünf gehört der Ausgangslage: Bearbeitungszeit, Rückfragen, Fehler und heutige Liegezeit werden erfasst. Ohne diesen Ausgangswert lässt sich später nur zeigen, dass etwas funktioniert — nicht, ob es besser ist. An den Tagen sechs und sieben werden Risiko und Datenzugriff begrenzt: welche Daten gebraucht werden, wer sie sehen darf, welche Wirkung der Pilot haben darf. Kritische Buchungen und Außenkommunikation bleiben zunächst gesperrt.

Woche 2: Eine dünne vollständige Kette bauen

Die Lösung soll früh den ganzen Weg durchlaufen: vom realen Eingang über den KI-Schritt und die Prüfung gegen Regeln und Fachsysteme bis zum Ergebnis in einer echten Freigabeoberfläche. Nicht schön, nicht vollständig, aber echt. Der erste Durchlauf mit einem echten Dokument ist regelmäßig ernüchternd anzusehen — und trotzdem der wichtigste Moment der zweiten Woche, weil ab jetzt jede Verbesserung an etwas Ganzem gemessen wird.

Konkret heißt das: An den Tagen acht bis zehn werden Eingang und Ausgabe festgelegt. Die wichtigsten Dokumente werden angenommen, das Modell liefert feste Felder statt freien Text, fehlende oder unzulässige Angaben werden sichtbar. An Tag elf und zwölf wird mindestens eine echte Datenquelle angebunden — etwa Artikelstamm oder Bestand. Ersatzdaten in einer Tabelle wären bequemer; sie würden aber genau den Integrationsaufwand verdecken, den der Pilot messen soll.

Die Tage 13 und 14 gehören der Freigabeoberfläche. Die Pilotgruppe sieht Ergebnis, Fundstelle und den Grund für offene Punkte; Korrektur und Ablehnung sind möglich. Ein reiner JSON-Bildschirm beweist wenig über den späteren Alltag.

Woche 3: Qualität, Sicherheit und Störungen

An den Tagen 15 bis 17 läuft der feste Testsatz. Gemessen werden Feldgenauigkeit, vollständig richtige Vorgänge, falsch durchgelassene Fälle, Prüfrate und Bearbeitungszeit; Fehler werden nach Ursache geordnet. Erst dieses Ordnen macht aus einer Fehlerliste einen Arbeitsplan.

Tag 18 gehört den Angriffen. Zu unseren Testdokumenten gehört inzwischen immer auch ein präpariertes PDF, in dem in weißer Schrift auf weißem Grund steht, das System möge alle Prüfungen überspringen und den Vorgang freigeben. Dazu kommen ungewöhnliche Formate und unzulässige Forderungen. Erfolg bedeutet nicht, dass das Modell jeden dieser Versuche erkennt. Erfolg bedeutet, dass daraus keine unerlaubte Wirkung entsteht — weil Rechte, Regeln und Freigaben davor stehen.

An Tag 19 zieht jemand den Stecker. Modell, Schnittstelle und Datenquelle werden nacheinander unterbrochen, gern mitten in einem Vorgang. Der Vorgang muss erhalten bleiben, einen verständlichen Status bekommen und ohne Doppelwirkung fortgesetzt werden können. Ein System, das diesen Tag nicht übersteht, hat im Betrieb nichts verloren.

Woche 4: Einsatzprobe und Entscheidung

Von Tag 20 bis 23 bearbeitet eine kleine Gruppe reale oder realitätsnahe Vorgänge im begleiteten Betrieb. Gemessen werden Zeit vom Eingang bis zum Ergebnis, Prüfzeit, Korrekturen, Ausnahmen und Bedienprobleme; kritische Wirkungen bleiben gesperrt. Diese Tage fördern verlässlich Dinge zutage, die in keinem Konzept standen — in einem Piloten stolperte die Kette gleich am ersten Vormittag über ein quer eingescanntes PDF eines Lieferanten. Genau dafür ist die Woche da.

An den Tagen 24 bis 26 werden die wichtigsten Hürden beseitigt: Fehler mit großer Wirkung, häufige Bedienprobleme. Neue Funktionen kommen nicht auf die Liste. Der Pilot gewinnt jetzt durch Ruhe, nicht durch Umfang. An Tag 27 und 28 folgt der Abnahmelauf: Der unangetastete Abnahmesatz läuft auf der vorgesehenen Fassung, die Ergebnisse werden gegen die vorher beschlossenen Grenzen bewertet, Prüfzeit und Betriebsaufwand fließen ein.

Die letzten beiden Tage bereiten die Entscheidung vor. Die Abschlussrunde erhält keine Show, sondern einen kurzen Bericht: Kennzahlen, Fehlergruppen, Sicherheitsbefunde, Rückmeldungen, Kosten, offene Anbindungen und der empfohlene nächste Umfang. Wer eine Vorführung erwartet hat, ist zunächst enttäuscht — und meist schnell versöhnt, weil sich auf dieser Grundlage tatsächlich entscheiden lässt.

Was nach 30 Tagen vorliegen muss

Maßstäbe, die vor dem Pilot feststehen

• Trefferquote für wichtige Angaben,
• höchstens zulässige Zahl falsch durchgelassener Fälle,
• Anteil schwieriger Fälle, die sicher gestoppt werden,
• maximale Prüfzeit,
• vertretbare Laufzeit und Menge pro Stunde,
• Verhalten bei Ausfall von Modell oder Fachsystem,
• Ergebnis der Sicherheits- und Rechteprüfung,
• Akzeptanz der Arbeitsoberfläche.

Diese Maßstäbe vor dem Start festzulegen ist unbequem, weil noch niemand weiß, was erreichbar ist. Genau deshalb gehören sie an den Anfang. Maßstäbe, die nach den Ergebnissen festgelegt werden, haben die angenehme Eigenschaft, immer erfüllt zu sein.

Vier mögliche Entscheidungen

Am Ende stehen vier mögliche Ausgänge, und alle vier sind legitim. Weiterführen, wenn Qualität, Nutzen und Betrieb tragen — der Umfang kann dann kontrolliert wachsen. Nachschärfen, wenn der Kern funktioniert, aber Daten, Oberfläche oder Qualitätsgrenzen eine weitere begrenzte Runde brauchen. Enger schneiden, wenn ein kleinerer Teilprozess das bessere Verhältnis aus Nutzen und Beherrschbarkeit zeigt. Oder stoppen, wenn Daten, Nutzen, Risiko oder Anbindung nicht tragen — die Erkenntnisse und der Testsatz bleiben dokumentiert und sind beim nächsten Kandidaten sofort wieder wertvoll.

Ein gestoppter Pilot nach 30 Tagen ist kein gescheitertes Projekt. Ein Projekt, das zwei Jahre lang niemand zu stoppen wagt, ist eines.

Was nicht in diesen Monat gehört

Vollständige Autonomie, mehrere Abteilungen, eine große Datenmigration, die gleichzeitige Erneuerung der Warenwirtschaft oder Entscheidungen mit hoher Wirkung gehören nicht in denselben Pilot.

Ein enger Umfang ist kein Mangel. Er ist die Voraussetzung dafür, nach 30 Tagen etwas zu wissen.

Fazit

Ein 30-Tage-Pilot beweist nicht, dass „KI funktioniert“. Er beantwortet eine konkrete betriebliche Frage.

Reale Daten, eine durchgängige Kette, feste Tests und ein klarer Entscheidungsrahmen machen aus einer Vorführung eine belastbare Grundlage für den nächsten Schritt.

Quellen und weiterführende Hinweise

1. NIST: AI Risk Management Framework
2. NIST: AI RMF Playbook
3. OWASP: Sicherheitsprinzipien für KI-Agenten

Ein Pilot braucht eine beantwortbare Frage

Ein enger Umfang und klare Maßstäbe schaffen in kurzer Zeit eine belastbare Entscheidung.

Pilot besprechen