Zum Hauptinhalt springen
Zurück zum Blog
BlogEN verfügbar

KI-Piloten steuern: Kriterien für Stop, Anpassung und Skalierung

Ein KI-Pilot braucht mehr als Nutzungszahlen. So werden Use Cases, Qualität, Human Checkpoints und Skalierungsregeln vor dem Start prüfbar.

Andrea Giugliano
KI-Piloten steuern: Kriterien für Stop, Anpassung und Skalierung

Ein KI-Pilot soll keine Begeisterung oder Verwendung messen. Er soll eine Entscheidung ermöglichen.

Viele KI-Piloten werden evaluiert anhand der falschen Kennzahlen oder Fragen wie z.B.: Wie viele Personen haben das Tool genutzt? wie viele Lizenzen vergeben? Wie viele Nutzer verwenden die KI. Jedoch wäre wichtiger zu beurteilen, ob klar begrenzte Anwendungsfälle, welche einen Mehrwert liefern und unter realistischen Bedingungen bessere Ergebnisse liefern und ob die Organisation Qualität, Risiken und Verantwortung über diese Ergebnisse sicherstellen kann.

Lizenzaktivität kann zeigen, dass Zugang vorhanden ist. Sie belegt weder Zeitgewinn noch bessere Qualität. Sie sagt auch nichts darüber aus, wie viel Korrekturarbeit entsteht, welche Aufgaben nicht zum System passen oder ob die Lösung im späteren Betrieb tragfähig wäre.

Wer einen Pilot nur als Tooltest organisiert, erhält am Ende meist eine Sammlung von Eindrücken. Wer ihn als Evaluations- und Governance-System gestaltet, erhält eine begründete Entscheidung: stoppen, anpassen, begrenzt fortführen oder skalieren.

Nutzung ist ein Signal, aber kein Ergebnis

Generative KI kann Arbeit beschleunigen. Die Wirkung ist jedoch weder gleichmäßig noch automatisch auf ganze Abläufe übertragbar.

Eine randomisierte Feldstudie mit 7.137 Wissensarbeitenden in 66 Unternehmen untersuchte einen in E-Mail, Meetings und Dokumentarbeit integrierten KI-Assistenten. In der zweiten Hälfte des sechsmonatigen Experiments verbrachten aktive Nutzende weniger Zeit mit E-Mail. Gleichzeitig fanden die Forschenden keine entsprechende Veränderung bei Umfang oder Zusammensetzung der Aufgaben. Individuelle Zeitersparnis verändert noch nicht automatisch Koordination, Entscheidungen oder das Operating Model. Die Studie ist ein NBER Working Paper; mehrere Autoren arbeiteten zum Untersuchungszeitpunkt bei Microsoft. Diese Einschränkung gehört zur Einordnung. Dillon et al., NBER Working Paper 33795

Auch die Aufgabenpassung variiert. Eine 2026 in Organization Science veröffentlichte experimentelle Studie mit Management Consultants beschreibt eine ungleichmäßige technologische Grenze. Bei Aufgaben innerhalb der Fähigkeiten des eingesetzten Systems verbesserten sich Produktivität und Qualität. Bei einer Aufgabe außerhalb dieser Grenze konnte KI-Unterstützung die Leistung verschlechtern. Ähnlich wirkende Aufgaben können damit zu gegensätzlichen Ergebnissen führen. Dell’Acqua et al., Organization Science

Für einen Pilot folgt daraus: Durchschnittswerte über alle Aufgaben verdecken genau die Unterschiede, die für eine Skalierungsentscheidung wichtig sind. Sinnvoller ist es die verschiedenen Anwendungsfälle anhand verschiedener Kriterien zu bewerten und dort eine Aussage zu Tätigen wo KI einen Mehrwert bring und in welchen Fällen der Einsatz nicht gerechtfertigt ist.

Ein Pilot benötigt klare Fragestellungen die Evaluiert werden sollen

Geeignete Fragestellungen sind beispielsweise:

  • Kann das System einen klar definierten Arbeitsschritt beschleunigen, ohne die vereinbarte Qualitätsgrenze zu unterschreiten?

  • Für welche Aufgaben und Rollen ist die Unterstützung geeignet und wo bleibt sie ausgeschlossen?

  • Wie viel fachliche Prüfung und Korrektur ist erforderlich?

  • Welche Daten, Berechtigungen und Kontrollpunkte sind für einen sicheren Betrieb notwendig?

  • Reichen Nutzen und organisatorische Voraussetzungen für eine begrenzte Skalierung?

Die Frage muss eng genug sein, damit ein Ergebnis möglich ist. „Wie können wir KI im Unternehmen nutzen?“ ist zu breit. „Kann ein Assistenzsystem den ersten Entwurf einer standardisierten internen Zusammenfassung unterstützen, wenn eine fachlich verantwortliche Rolle jede Aussage prüft?“ ist entscheidbar.

Zur Fragestellung gehören auch Nicht-Ziele. Ein begrenzter Textassistenzpilot prüft beispielsweise nicht automatisch die Eignung für Personalentscheidungen, Kundenkommunikation, sensible Daten oder autonome Prozessschritte.

Zerlegen Sie den Arbeitsablauf in konkrete Aufgaben

Die meisten Wissensprozesse bestehen nicht aus einer einzigen Tätigkeit. Recherche, Strukturierung, Entwurf, Prüfung, Entscheidung und Freigabe stellen unterschiedliche Anforderungen.

Ein Pilot sollte deshalb nicht nur einen Prozessnamen führen, sondern die geprüften Aufgaben einzeln beschreiben:

Feld

Konkrete Frage

Aufgabe

Welcher klar abgegrenzte Arbeitsschritt wird unterstützt?

Eingang

Welche Informationen und Datenklassen sind erforderlich?

Ausgang

Welches Ergebnis soll entstehen?

Qualitätsgrenze

Welche Fehler oder Abweichungen sind nicht akzeptabel?

Human Checkpoint

Wer prüft was und darf das Ergebnis verwerfen?

Ausschluss

Welche Aufgaben, Daten oder Entscheidungen sind nicht Teil des Piloten?

Das NIST AI Risk Management Framework empfiehlt ebenfalls, konkrete Aufgaben, Wissensgrenzen, erwartete Vorteile und Kosten, menschliche Aufsicht sowie Vergleichsmaßstäbe zu dokumentieren. Es handelt sich um ein freiwilliges US-Rahmenwerk, nicht um eine europäische Rechtsgrundlage. Als Struktur für Test, Evaluation, Verifikation und Validierung ist es dennoch nützlich. NIST AI RMF Core

Definieren Sie die Vergleichsbasis vor dem ersten Test

Ohne Baseline ist die Auswirkung der Veränderung (mit oder ohne KI) nicht messbar. Deswegen sollte eine Baseline erhoben werden bevor der Pilot startet.

Die Vergleichsbasis muss nicht kompliziert sein. Sie muss aber zur Aufgabe passen. Für einen begrenzten Pilot können wenige nachvollziehbare Signale genügen:

  • Bearbeitungszeit für vergleichbare Aufgaben

  • fachliche Qualität anhand einer vorab definierten Prüfliste

  • Anzahl und Schwere notwendiger Korrekturen

  • Rückfragen, Nacharbeit und Übergabefehler

  • nicht zulässige Datenverwendung oder andere Risikosignale

  • subjektive Entlastung als ergänzende, nicht alleinige Evidenz

Wichtig ist die Trennung von Brutto- und Nettozeit. Zehn Minuten schnellerer Entwurf sind kein Zeitgewinn, wenn anschließend zwanzig Minuten zusätzliche Prüfung nötig werden.

Auch Qualität darf nicht erst nach dem Pilot definiert werden. Legen Sie vorab fest, welche Kriterien fachlich entscheidend sind. Dazu können Vollständigkeit, Korrektheit, Nachvollziehbarkeit, Quellenbezug, Tonalität oder die Einhaltung eines festgelegten Formats gehören.

Menschliche Prüfung braucht Verantwortung, Zeit und Befugnis

Ein Kästchen mit der Bezeichnung „Human in the Loop“ ist noch keine wirksame Kontrolle.

Die prüfende Person muss:

  • die Aufgabe und die möglichen Fehler verstehen

  • Zugriff auf die notwendige Vergleichsevidenz haben

  • ausreichend Zeit für die Prüfung erhalten

  • das Ergebnis korrigieren, zurückweisen oder eskalieren dürfen

  • wissen, wer bei einem Fehler verantwortlich entscheidet

Das gilt besonders, wenn Ergebnisse Menschen betreffen, sensible Informationen verarbeiten oder wichtige geschäftliche Entscheidungen vorbereiten.

Die aktuelle Q&A der Europäischen Kommission zu AI Literacy richtet die Maßnahmen unter anderem an technischem Wissen, Erfahrung, Aus- und Weiterbildung sowie dem Nutzungskontext aus. Für den Einsatz bestimmter Hochrisikosysteme bleiben zusätzliche Anforderungen an Schulung und menschliche Aufsicht relevant. Welche Verpflichtung im konkreten Fall gilt, muss separat geprüft werden. Ein Blogbeitrag ersetzt diese Prüfung nicht. Europäische Kommission: AI Literacy – Questions & Answers

Das bedeutet, dass Enablement in den Pilot hinein gehört. Eine allgemeine Einführung reicht nicht. Nutzende und Prüfende müssen die Grenzen ihres konkreten Anwendungsfalls kennen und mit realistischen Beispielen üben.

Governance muss vor der Nutzung entscheidbar sein

Governance bedeutet nicht, jeden Prompt durch ein zentrales Gremium freigeben zu lassen. Sie bedeutet, vor dem Start die notwendigen Grenzen und Verantwortlichkeiten festzulegen.

Mindestens folgende Punkte müssen geklärt sein:

  1. Zulässige Daten: Welche Datenklassen dürfen verarbeitet werden, welche ausdrücklich nicht?

  2. Berechtigungen: Auf welche Systeme und Inhalte kann die Lösung direkt oder indirekt zugreifen?

  3. Anbieterbedingungen: Wie werden Eingaben, Ausgaben und Protokolle verarbeitet, gespeichert oder für Verbesserungen verwendet?

  4. Rechte: Welche Urheber-, Nutzungs- und Vertraulichkeitsfragen entstehen?

  5. Verantwortung: Wer verantwortet Aufgabe, Systemnutzung, fachliche Qualität und Risiko?

  6. Eskalation: Was passiert bei Fehlern, Datenschutzvorfällen oder unerwartetem Verhalten?

  7. Mitbestimmung: Welche arbeitsrechtlichen oder kollektivrechtlichen Prüfungen sind erforderlich?

Die Tiefe der Prüfung richtet sich nach Anwendungsfall und Risiko. Ein interner Formulierungsvorschlag mit nicht sensiblen Daten benötigt andere Kontrollen als ein System, das Entscheidungen über Personen vorbereitet.

Mehr zur organisatorischen Einbettung von KI finden Sie im Themenschwerpunkt Digitalisierung und AI-Anwendungsfälle. Wenn Software Aufgaben verteilt, Arbeit priorisiert oder Leistung bewertet, ergänzt der Beitrag „Wenn KI Arbeit steuert“ die Perspektive auf Entscheidungsrechte und Arbeitsgestaltung.

Messen Sie nach Use Case, nicht nach Person

Ein Pilot soll Aufgaben und Systeme bewerten. Er soll keine verdeckte Leistungsrangliste von Mitarbeitenden erzeugen.

Auswertungen sollten deshalb nach Use Case, Rolle und Kontext erfolgen. Personenbezogene Promptprotokolle oder individuelle Produktivitätsrankings sind in der Regel weder für die Entscheidung notwendig noch organisatorisch klug. Wo personenbezogene Daten unvermeidbar sind, braucht es eine konkrete Rechts-, Datenschutz- und Mitbestimmungsprüfung.

Eine kompakte Pilot-Scorecard kann so aussehen:

Dimension

Baseline

Pilotsignal

Entscheidungsregel

Zeit

Heutiger Aufwand für vergleichbare Aufgaben

Nettozeit inklusive Prüfung und Korrektur

Nur positiv, wenn Nacharbeit den Rohgewinn nicht aufzehrt

Qualität

Vorab definierte fachliche Prüfkriterien

Fehler, Vollständigkeit und Rückläufer

Keine Skalierung unterhalb der Mindestqualität

Risiko

Bekannte Fehlerszenarien und zulässige Daten

Vorfälle, Near Misses und Regelverstöße

Kritischer Vorfall führt zu Stopp und Review

Befähigung

Vorhandenes Rollenwissen

Sichere Anwendung und korrekte Eskalation

Fortführung nur mit ausreichender rollenspezifischer Kompetenz

Tragfähigkeit

Heutige Kosten und Prozessverantwortung

Lizenz-, Betriebs-, Support- und Kontrollaufwand

Nutzen muss den vollständigen Aufwand rechtfertigen

Nutzungsfrequenz kann erklären, warum wenig Evidenz vorliegt. Sie ist aber kein Ersatz für diese Dimensionen.

Legen Sie Stop-, Anpassungs- und Skalierungsregeln fest

Ein Pilot ohne Stop-Regel entwickelt ein Eigenleben. Ein Pilot ohne Skalierungsregel bleibt eine Dauerschleife.

Vor dem Start sollten vier mögliche Entscheidungen beschrieben sein:

  • Stoppen: Nutzen nicht belegt, Qualitätsgrenze verfehlt oder Risiko nicht vertretbar.

  • Anpassen: Use Case, Datenzugriff, Kontrollpunkt, Training oder technische Konfiguration verändern und gezielt erneut prüfen.

  • Begrenzt fortführen: Evidenz ist positiv, aber noch nicht ausreichend für breitere Nutzung.

  • Skalieren: Nutzen, Qualität, Risiko, Kompetenz und Betriebsverantwortung tragen für den definierten Scope.

Skalierung darf sich nur auf die tatsächlich geprüften Aufgaben und Bedingungen beziehen. Ein erfolgreicher Pilot für interne Textentwürfe legitimiert keine Nutzung für externe Aussagen, sensible Daten oder Entscheidungen über Personen.

Auch ein Modell- oder Anbieterwechsel kann eine Neubewertung erforderlich machen. Die Leistungsgrenze generativer Systeme verändert sich. Eine einmalige Freigabe ist deshalb kein dauerhafter Nachweis.

Ein guter Pilot macht Grenzen sichtbar

Ein belastbares Ergebnis muss nicht zwingend zeigen, dass KI skaliert werden sollte.

Ein Pilot ist auch dann wertvoll, wenn er zeigt:

  • dass der gewählte Use Case nicht passt;

  • dass Daten oder Berechtigungen ungeklärt sind;

  • dass der Korrekturaufwand den Zeitgewinn übersteigt;

  • dass die Organisation noch keine tragfähige Prüf- oder Supportstruktur hat;

  • dass ein kleinerer, klarerer Anwendungsfall sinnvoller wäre.

Der entscheidende Punkt ist nicht ein positives Ergebnis. Der entscheidende Punkt ist eine nachvollziehbare Entscheidung.

Fazit

Vor dem Start müssen Aufgabe, Baseline, Qualitätsgrenze, Daten, menschliche Prüfung und Entscheidungsregeln feststehen. Erst dann lässt sich unterscheiden, ob ein Tool genutzt wird oder ob ein Anwendungsfall tatsächlich tragfähig ist.

Wer diese Fragen erst nach dem Pilot klärt, kann Aktivität dokumentieren. Wer sie vorher klärt, kann verantwortungsvoll entscheiden.

Sie möchten einen KI-Pilot so strukturieren, dass Nutzen, Risiken und Skalierungsbedingungen prüfbar werden? In einem fokussierten Workshop lassen sich Entscheidungsfrage, Use Cases, Governance-Gates und Evaluationsplan gemeinsam klären. Vereinbaren Sie ein unverbindliches Erstgespräch.

Quellen und Einordnung

  1. Dillon et al.: Shifting Work Patterns with Generative AI. Randomisiertes Experiment in 66 Unternehmen mit 7.137 Wissensarbeitenden; NBER Working Paper, kein allgemeiner Wirkungsnachweis. Der Herstellerbezug mehrerer Autoren ist offengelegt.

  2. Dell’Acqua et al.: Navigating the Jagged Technological Frontier. Peer-reviewed experimentelle Studie mit Management Consultants; Aufgaben-, Modell- und Berufskontext begrenzen die Übertragbarkeit.

  3. NIST AI Risk Management Framework Core. Freiwilliges US-Rahmenwerk zur Strukturierung von Risiko-, Test- und Evaluationsarbeit; keine europäische Rechtsgrundlage.

  4. Europäische Kommission: AI Literacy – Questions & Answers. Offizielle Orientierung zur aktuellen Einordnung; die rechtliche Bewertung eines konkreten Systems bleibt fallbezogen.