Mit der Entscheidung beginnen, nicht mit dem Prototyp
Am Ende eines zweiwöchigen AI-Piloten muss eine schriftliche Go- oder No-go-Entscheidung stehen. Ist nur eine Demo geplant, wurde der Pilot bereits falsch zugeschnitten.
Die Entscheidung benennt den Ablauf, die Nutzer, die akzeptable Fehlergrenze und das Geschäftsergebnis, das verbessert werden soll. Ebenso wichtig ist ein vorab definierter Grund zum Abbruch. Ohne Abbruchbedingung wird jedes schwache Ergebnis zur Einladung, den Prompt noch etwas länger zu bearbeiten.
Das entspricht dem NIST AI Risk Management Framework. Dort bilden Kontext, erwarteter Nutzen, Kosten und Risiken die Grundlage einer ersten Go- oder No-go-Entscheidung. Ein Pilot muss nicht beweisen, dass ein Modell eine beeindruckende Antwort schreiben kann. Er muss zeigen, ob das geplante System in einem konkreten Geschäftsprozess funktioniert.
Den Test vor dem Feature bauen
Am Anfang stehen repräsentative Fälle aus der echten Arbeit. Neben normalen Eingaben gehören schwierige Fälle und solche in den Satz, die abgelehnt oder an einen Menschen übergeben werden müssen. Sind Produktionsdaten für das Experiment nicht freigegeben, werden personenbezogene Angaben entfernt. Die eigentliche Schwierigkeit der Aufgabe muss erhalten bleiben.
Jeder Fall braucht ein erwartetes Ergebnis oder eine klare Bewertungsregel. Manche Aufgaben besitzen exakte Antworten. Bei anderen vergleichen Fachleute die Ergebnisse nach Richtigkeit, Vollständigkeit, Ton und sicherem Verhalten. Auch die Evaluations-API von OpenAI verbindet eine Datenquelle mit ausdrücklichen Testkriterien und Gradern.
Der heutige manuelle Ablauf wird mit demselben Satz geprüft. Diese Basis ist unverzichtbar. Ein AI-Ergebnis kann intelligent wirken und trotzdem langsamer, unzuverlässiger oder teurer sein als die Tabelle und die erfahrene Fachkraft, die es ersetzen soll.
Evaluation gehört nicht ans Ende. Der ursprüngliche Satz läuft erneut, sobald Prompt, Modell, Werkzeuge oder Retrieval geändert werden.
Einen schmalen vertikalen Schnitt bauen
Der Pilot führt einen Fall vom Eingang bis zum nutzbaren Ergebnis durch die echten Grenzen des späteren Produkts. Liest die Idee Supportanfragen, sollte der Schnitt den passenden Kundenkontext abrufen, eine Antwort entwerfen, Quellen festhalten und unsichere Fälle an einen Operator übergeben. Ein Prompt in einem Chatfenster ist noch kein solcher Schnitt.
Wo Zugriff vorhanden ist, sollten echte Schnittstellen verwendet werden. Folgenreiche Aktionen bleiben zunächst schreibgeschützt oder brauchen eine ausdrückliche Freigabe. Eingabe, abgerufener Kontext, Modellkonfiguration, Ausgabe, Werkzeugaufrufe, Latenz, Nutzungskosten und Prüferentscheidung werden protokolliert. Erst diese Spur erklärt Fehler und ermöglicht spätere Vergleiche.
Der Pilot muss auch den Integrationsweg sichtbar machen. Benötigte Zugangsdaten, Berechtigungsumfang, fehlende Felder, Rate Limits und Verantwortliche der verbundenen Systeme gehören zum Ergebnis. Ein Modell kann den Qualitätstest bestehen und das Projekt kann trotzdem scheitern, weil die benötigten Daten nicht sicher erreichbar sind.
Der Pilot, der nichts beweist
Der häufigste Fehler ist eine kuratierte Demo mit freundlichen Beispielen. Jemand verändert den Prompt beim Lesen der Antworten, entfernt schlechte Fälle und zeigt nur die stärkste Ausgabe. Der Raum sieht Fähigkeit, lernt aber nichts über Zuverlässigkeit.
Ein anderer leerer Pilot versteckt Menschen hinter dem Vorhang. Wenn eine Fachkraft jede Eingabe bereinigt, das passende Dokument auswählt und die Ausgabe vor der Präsentation repariert, gehört diese Person zum bewerteten System. Ihre Zeit und ihr Urteil müssen gemessen werden.
Auch mehrere gleichzeitige Änderungen zerstören Erkenntnis. Ein neues Modell, ein neuer Prompt, neues Retrieval und neue Werkzeuge können gemeinsam bessere Resultate erzeugen. Das Team weiss danach nur nicht warum. Kontrollierte Vergleiche sind weniger spektakulär und deutlich nützlicher.
Ein gescheiterter Pilot kann wertvoll sein. Vielleicht ist das Retrieval schwach, die Quelldaten sind ungeeignet, die Aufgabe braucht menschliches Urteil oder die wirtschaftliche Rechnung geht nicht auf. Solche Belege als fast fertig umzudeuten, verwandelt ein günstiges Scheitern in ein teures Projekt.
Diese Woche die Entscheidung treffen
Entscheidungssatz und Abbruchbedingung aufschreiben. Die Evaluationsfälle gemeinsam mit den Menschen zusammenstellen, die den Ablauf heute ausführen. Die manuelle Basis erfassen und denselben Satz durch den kleinsten vollständigen Produktschnitt führen.
Fehler nach Typ prüfen, nicht nur als Durchschnittswert. Falsche Antworten, unbelegte Aussagen, unsichere Aktionen, fehlender Kontext und korrekt an Menschen übergebene Fälle getrennt betrachten. Gemessene Latenz, Modell- und Werkzeugkosten, Integrationshindernisse und notwendige menschliche Korrekturen ergänzen.
Die Abschlussnotiz muss Go, No-go oder eine Änderung des Problems festhalten. Sie nennt Belege, verbleibende Risiken und die nächste notwendige Investition. Ist niemand bereit, diese Entscheidung zu treffen, hat der Pilot die Frage nicht beantwortet. Er hat sie nur verschoben.