KI-Pilotprojekt: warum es im Pilot bleibt und was es in den Betrieb bringt

Ein KI-Pilotprojekt beweist, dass ein Modell eine bestimmte Aufgabe mit echten Daten lösen kann. Ob daraus ein Vorgang wird, der jeden Tag läuft, entscheidet sich an anderen Fragen: Wer ist zuständig, was kostet ein Durchlauf, was passiert bei einer unsicheren Antwort und wer prüft das Protokoll.

KI-Pilotprojekt: was es beweist und was offenbleibt

Ein Pilot ist ein begrenzter Versuch: eine Aufgabe, eine Auswahl an Daten, eine kleine Gruppe von Nutzern und meist eine Person, die das Vorhaben mit viel persönlichem Einsatz trägt. Unter diesen Bedingungen liefert ein Sprachmodell oft beeindruckende Ergebnisse. Die Vorführung vor der Geschäftsführung gelingt, und die Begeisterung im Raum ist echt.

Der Alltag stellt andere Bedingungen. Daten kommen ungefiltert und unvollständig, die Nutzer haben keine Zeit für Experimente, und die treibende Person wendet sich irgendwann dem nächsten Thema zu. Was im Versuch von Hand aufgefangen wurde, muss nun die Organisation leisten. Genau hier bleiben viele Vorhaben stehen: Die Machbarkeit ist gezeigt, aber niemand hat den Auftrag, sie in einen dauerhaften Ablauf zu übersetzen.

Die Betriebslücke: sechs Fragen, die ein Pilot selten beantwortet

• Zuständigkeit. Welche Abteilung verantwortet den Vorgang, und wer entscheidet, wenn ein Ergebnis strittig ist? Die IT betreibt die Technik, den fachlichen Nutzen kann sie nicht verantworten.
• Kosten je Vorgang. Im Versuch fallen Modellkosten kaum auf. Bei voller Nutzung zählt, was ein einzelner Durchlauf kostet und wo eine Obergrenze greift; die Grundlagen erklärt der Beitrag zu Token-Kosten.
• Unsichere Antworten. Was geschieht, wenn das Modell danebenliegt oder sich nicht festlegen kann? Der Betrieb braucht eine feste Regel, ab wann ein Mensch übernimmt – das Prinzip heißt Human-in-the-Loop.
• Nachvollziehbarkeit. Welche Eingabe hat zu welchem Ergebnis geführt? Ohne Protokoll lässt sich weder ein Fehler erklären noch eine Reklamation beantworten.
• Anbindung. Im Versuch werden Ergebnisse oft von Hand übertragen. Im Alltag müssen sie dort ankommen, wo gearbeitet wird: im ERP, im CRM, im Postfach der Sachbearbeitung.
• Verträge und Daten. Mit welchem Anbieter besteht ein Auftragsverarbeitungsvertrag, welche Daten erhält das Modell, und was gilt, wenn der Anbieter sein Modell austauscht?

Weiterführen, umbauen oder beenden: die Vorlage für die Geschäftsführung

Am Ende eines Versuchs steht ein Beschluss, keine stillschweigende Verlängerung. Brauchbar ist eine Vorlage, die fünf Punkte nüchtern nebeneinanderstellt:

1. Volumen: Wie oft fällt der Vorgang tatsächlich an – gezählt, nicht geschätzt?
2. Qualität: Wie oft lag das System richtig, gemessen an einem festen Satz echter Fälle? Wie ein solcher Prüfsatz aufgebaut wird, beschreibt die KI-Evaluierung.
3. Fehlerkosten: Was verursacht ein falsches Ergebnis, das unbemerkt durchrutscht – eine korrigierte Buchung oder einen verärgerten Kunden?
4. Wirtschaftlichkeit: laufende Kosten je Vorgang einschließlich des Prüfaufwands, verglichen mit der heutigen Bearbeitung.
5. Trägerschaft: Gibt es im Fachbereich eine benannte Person, die den Vorgang dauerhaft verantworten will?

Fehlt der fünfte Punkt, lautet die Antwort in der Regel „beenden“ oder „zurückstellen“, so gut die übrigen Werte auch aussehen. Ein sauber beendeter Versuch mit festgehaltenen Gründen ist ein verwertbares Ergebnis. Ein Pilot, der ohne Beschluss weiterläuft, bindet dagegen Aufmerksamkeit und Budget, ohne etwas zu liefern.

Vom KI-Pilotprojekt in den Betrieb: was die Übergabe braucht

Fällt die Entscheidung für den Betrieb, wird aus dem Versuch ein System mit Pflichten. Dazu gehören eine Oberfläche, in der Sachbearbeiter Ergebnisse prüfen und freigeben, feste Rollen mit abgestuften Rechten, eine Kostengrenze je Anwendung und ein Protokoll jedes Aufrufs. Hinzu kommt ein Betriebshandbuch: welche Fälle das System bearbeitet, welche es an Menschen weitergibt, wie es abgeschaltet wird und wer bei einer Störung Bescheid bekommt.

Ebenso wichtig ist ein Plan für Veränderungen. Anbieter aktualisieren ihre Modelle, Eingangsdokumente wechseln das Format, Regeln im Fachbereich werden angepasst. Der Satz an Prüffällen aus dem Versuch bleibt deshalb erhalten und läuft nach jeder Änderung erneut durch, bevor sie wirksam wird.

Muster, an denen Piloten hängen bleiben

• Innovationsbudget ohne Betriebsbudget. Der Versuch ist finanziert, der Dauerbetrieb nicht, und das hat vor dem Start niemand ausgesprochen.
• Ein privates Konto als Fundament. Der Pilot lief über den Zugang eines einzelnen Mitarbeiters; mit dessen Wechsel verschwinden Anweisungen, Einstellungen und Verlauf.
• Applaus statt Messung. Die Freude über eine gelungene Vorführung ersetzt die Auswertung echter Fälle.
• Datenschutz am Schluss. Die Frage, welche Daten das Modell sehen darf, kommt erst auf den Tisch, wenn alles fertig ist, und hält dann das gesamte Vorhaben an.
• Technik ohne Fachbereich. Die IT übernimmt ein Werkzeug, dessen Ergebnisse sie inhaltlich nicht beurteilen kann.

Wie wir Piloten in den Betrieb überführen

Wir beginnen mit der Entscheidungsvorlage: welcher Versuch einen dauerhaften Vorgang rechtfertigt und welcher besser endet. Für die Vorhaben, die weitergehen, bauen wir Freigabe-Oberfläche, Rollen, Protokoll und Anbindung an die vorhandenen Systeme; die Kriterien, nach denen das Ergebnis abgenommen wird, stehen vor dem Start im Angebot. Anwendungen, die im Betrieb Sprachmodelle nutzen, rufen sie bei uns über ein eigenes Gateway mit harter Kostengrenze auf. Wie ein täglicher Vorgang im Betrieb aussieht, zeigt ein Beispiel aus Lebensmittelproduktion und Handel: Die Zahlen von 8 Kassen kommen nachts von selbst, handschriftliche Zählblätter erscheinen als Vorschläge zur Bestätigung. Die Leistung dazu heißt KI-Implementierung; wo erst sortiert werden muss, welcher Versuch sich lohnt, steht die KI-Beratung am Anfang.