Warum ein KI-Pilot noch keine betriebliche Fähigkeit ist

Ein KI-Prototyp kann in wenigen Tagen überzeugend wirken. Er fasst Dokumente zusammen, ordnet Anfragen zu oder schlägt Antworten vor. Die Demo läuft mit ausgewählten Beispielen, ein fachkundiger Mitarbeiter sitzt daneben und korrigiert Fehler sofort. Das Ergebnis wird als erfolgreicher Pilot bewertet.

Für den späteren Betrieb ändern sich die Bedingungen. Eingaben sind unvollständig, neue Fälle tauchen auf, Nutzer verlassen sich auf plausible Formulierungen und der Anbieter ändert ein Modell. Gleichzeitig wird aus einer einzelnen Testanfrage ein wiederkehrender Prozess mit Zugriffsrechten, Kosten, Support und Verantwortung.

Der Pilot hat damit nicht versagt. Er hat nur eine kleinere Frage beantwortet:

Kann die Technologie bei einer abgegrenzten Aufgabe grundsätzlich helfen?

Die Frage der Produktionsreife ist umfassender:

Kann die Organisation mit dieser Technologie unter realen Bedingungen wiederholt ein verantwortbares Ergebnis liefern?

Ein erfolgreicher Pilot ist deshalb ein Erkenntnisgewinn, aber noch keine betriebliche Fähigkeit.

Die Demo zeigt Können – der Betrieb braucht Beherrschbarkeit

Ein klassisches Softwaremodul folgt im Regelfall programmierten Regeln. Ein KI-System erzeugt Ergebnisse dagegen aus Modell, Daten, Konfiguration und Nutzungskontext. Seine Qualität kann sich zwischen Aufgaben, Eingaben und Nutzergruppen deutlich unterscheiden. Bei extern bezogenen Modellen kommen Änderungen außerhalb der eigenen Organisation hinzu.

Das NIST AI Risk Management Framework 1.0 ordnet die Steuerung deshalb in vier zusammenhängende Funktionen:

• Govern: Regeln, Rollen und Verantwortung schaffen,
• Map: Zweck, Kontext, Beteiligte und mögliche Folgen verstehen,
• Measure: Qualität und Risiken mit geeigneten Methoden prüfen,
• Manage: Risiken priorisieren, behandeln, überwachen und über Fortführung entscheiden.

Das Framework ist freiwillig, branchenneutral und wird nach Angaben des NIST derzeit weiterentwickelt. Es ist keine Zertifizierung und kein Ersatz für rechtliche Anforderungen. Für die betriebliche Kernfrage ist seine Logik dennoch hilfreich: Ohne verstandenen Kontext ist eine Messung wenig aussagekräftig, ohne Messung ist eine Go-/No-Go-Entscheidung kaum belastbar und ohne laufende Steuerung veraltet die anfängliche Bewertung.

Ein Pilot konzentriert sich meist auf Map und einen begrenzten Teil von Measure. Produktionsreife benötigt zusätzlich Governance und einen dauerhaft tragfähigen Betrieb.

Ein konstruiertes Beispiel: Rechnungen richtig zuordnen

Stellen Sie sich folgende Situation vor:

Ein KI-Assistent ordnet eingehende Rechnungen im Test zuverlässig Kostenstellen zu. Im Produktivprozess fehlen jedoch Regeln für neue Lieferanten, widersprüchliche Bestellbezüge und unsichere Vorschläge. Ohne Eskalationsweg würde das Modell aus einer hilfreichen Vorprüfung eine nicht autorisierte Buchungsentscheidung machen.

Dieses Beispiel ist konstruiert. Es enthält keine behauptete Trefferquote, keine erfundene Kundensituation und kein vermeintlich gemessenes Einsparergebnis.

Der Unterschied zwischen Pilot und Betrieb liegt hier nicht nur in der Modellqualität. Mindestens fünf organisatorische Fragen sind offen:

1. Soll das System lediglich einen Vorschlag machen oder selbst buchen?
2. Welche Daten darf es dafür verarbeiten?
3. Wie wird Unsicherheit erkannt und behandelt?
4. Wer darf einen Vorschlag fachlich bestätigen?
5. Was geschieht, wenn Modell oder Schnittstelle nicht verfügbar sind?

Die gleiche Technologie kann abhängig von diesen Antworten ein risikoarmes Hilfsmittel oder ein schlecht kontrollierter Entscheidungspunkt sein.

Acht Prüffelder für die Produktionsreife

Eine pauschale Punktzahl würde zu viel Genauigkeit vortäuschen. Ein nicht geklärtes Entscheidungsrecht darf nicht durch gute Antwortzeiten ausgeglichen werden. Deshalb trennt das folgende Modell acht eigenständige Prüffelder.

1. Geschäftszweck und Prozessgrenze

Definieren Sie die Aufgabe so eng, dass Erfolg und Misserfolg beobachtbar werden. „Wir setzen KI im Kundenservice ein“ ist kein prüfbarer Zweck. „Das System schlägt für eingehende Anfragen eine Kategorie und drei passende Wissensartikel vor“ ist deutlich konkreter.

Klären Sie:

• Wer nutzt das Ergebnis?
• Welche Entscheidung oder Tätigkeit wird unterstützt?
• Was gehört ausdrücklich nicht zum Anwendungsfall?
• Welcher Nutzen soll für Prozess, Nutzer oder Organisation entstehen?
• Warum ist KI dafür geeigneter als eine einfachere Regel, Suche oder Prozessänderung?

Der Leitfaden zur Prozessprüfung vor einer Digitalisierung hilft, Ergebnis, Daten und Verantwortung vor der technischen Lösung zu klären.

Ausschlussgrund: Es gibt keinen abgegrenzten Geschäftszweck oder die erwartete Wirkung lässt sich nicht von allgemeiner Technikbegeisterung unterscheiden.

2. Daten und Berechtigungen

Ein Pilot arbeitet häufig mit kuratierten oder manuell bereitgestellten Daten. Der Betrieb benötigt dagegen einen geregelten Zugriff:

• Welche Eingabe-, Kontext- und Ergebnisdaten werden verarbeitet?
• Enthalten sie personenbezogene, vertrauliche oder geschützte Informationen?
• Woher stammen sie und wie verlässlich sind sie?
• Wer darf sie für diesen Zweck verwenden?
• Welche Daten erhält ein externer Anbieter?
• Werden Eingaben oder Ergebnisse für Training oder Produktverbesserung genutzt?
• Wie werden Aufbewahrung, Löschung und Export geregelt?

Das BSI-Management-Blitzlicht zu Secure AI Operations empfiehlt unter anderem eine Bestandsaufnahme eingesetzter KI-Systeme, definierte Einsatzzwecke, geeignete Unternehmenszugänge und Schutzregeln für personenbezogene sowie sensible Geschäftsinformationen.

Ein technisch erreichbarer Datenbestand ist nicht automatisch eine zulässige oder geeignete Datenquelle. Rollen, Schutzbedarf und fachliche Verantwortung müssen vor der produktiven Anbindung geklärt sein.

Ausschlussgrund: Die erforderliche Datenverarbeitung ist nicht zulässig, nicht angemessen geschützt oder beruht auf unkontrollierten persönlichen Zugängen.

3. Qualitätsmaß und repräsentative Prüfung

Die Aussage „Die Antworten waren erstaunlich gut“ ist für einen Pilotbericht verständlich, aber für den Betrieb unzureichend. Qualität muss auf die konkrete Aufgabe bezogen werden.

Je nach Anwendungsfall können relevant sein:

• Anteil fachlich korrekter Ergebnisse,
• Arten und Folgen falscher Ergebnisse,
• übersehene und fälschlich erkannte Fälle,
• Vollständigkeit notwendiger Informationen,
• Anteil der Ergebnisse, die Menschen korrigieren,
• Stabilität bei unterschiedlichen Formulierungen und Fallgruppen,
• Zahl der Fälle, die sicher eskaliert statt geraten werden,
• Zeit- und Kostenvorteil nach menschlicher Prüfung.

Der Testbestand muss die reale Nutzung angemessen abbilden. Nur einfache bekannte Fälle zu prüfen, misst die Auswahl der Beispiele und nicht die Produktionsqualität. Testfälle sollten deshalb Standardfälle, relevante Randfälle, unvollständige Eingaben und bekannte Fehlerbilder enthalten.

Es gibt keine universelle Mindestquote für „produktive KI“. Eine falsche Zuordnung von internem Wissen hat andere Folgen als eine fehlerhafte Entscheidung über Zahlung, Sicherheit oder Personen. Die akzeptable Qualität entsteht aus Aufgabe und Fehlerfolge.

Ausschlussgrund: Erfolg ist nicht messbar definiert oder der Testbestand bildet die relevanten Fehlerfolgen nicht ab.

4. Fehlerfolgen und Abbruchkriterien

Nicht jeder Fehler muss verhindert werden. Die Organisation muss jedoch wissen, welche Fehler sie akzeptiert, erkennt und begrenzt.

Prüfen Sie für wesentliche Fehlerarten:

• Wer oder was könnte betroffen sein?
• Kann der Fehler vor seiner Wirkung erkannt werden?
• Ist er rückgängig zu machen?
• Welche finanzielle, rechtliche, sicherheitsbezogene oder persönliche Folge ist möglich?
• Welche Häufung oder Veränderung löst eine Untersuchung aus?
• Wann wird der Anwendungsfall eingeschränkt oder abgeschaltet?

Das BSI empfiehlt vor der Integration generativer KI in Arbeitsabläufe eine individuelle Risikoanalyse. Diese ist kein einmaliges Formular. Modell, Daten, Angriffe und Nutzung können sich verändern; relevante Risiken und Gegenmaßnahmen müssen deshalb über den Lebenszyklus betrachtet werden.

Ein Abbruchkriterium ist keine Schwäche des Projekts. Es schützt die Organisation davor, einen ungeeigneten Einsatz aus Investitions- oder Erwartungsdruck weiterzuführen.

Ausschlussgrund: Ein erheblicher Fehler könnte unbemerkt wirksam werden und lässt sich weder technisch noch organisatorisch auf ein vertretbares Maß begrenzen.

5. Menschliche Entscheidung und Eskalation

„Human in the Loop“ wird häufig als allgemeine Absicherung genannt. Ein Mensch in einem Prozess macht die Entscheidung aber nicht automatisch sicher.

Die prüfende Person benötigt:

• ausreichende Fachkenntnis,
• die notwendigen Quelldaten und den Kontext,
• erkennbare Kennzeichnung des KI-Ergebnisses,
• Zeit für eine echte Prüfung,
• die Befugnis, das Ergebnis abzulehnen oder zu ändern,
• einen Weg für unsichere oder strittige Fälle.

Wenn Mitarbeitende hunderte Vorschläge unter Zeitdruck nur bestätigen, ist die menschliche Freigabe möglicherweise formal vorhanden, aber praktisch wirkungslos. Ebenso problematisch ist eine Prüfung, bei der das System keine Begründung oder relevante Quelle zugänglich macht.

Die Trennung von Aufgabe, Verantwortung, Entscheidungsrecht und technischer Berechtigung gilt auch für KI: Das System kann vorbereiten oder ausführen. Wer ein Ergebnis verantwortet und wer es verbindlich freigeben darf, bleibt eine Organisationsentscheidung.

Ausschlussgrund: Eine notwendige menschliche Kontrolle ist nur nominell vorgesehen oder die prüfende Rolle kann Fehler weder erkennen noch wirksam stoppen.

6. Betrieb, Überwachung und Protokollierung

Ein Pilot wird vom Projektteam beobachtet. Im Betrieb muss geklärt sein, wer reagiert, wenn Qualität, Kosten oder Verfügbarkeit abweichen.

Ein Mindestmodell beantwortet:

• Wer ist fachlicher Owner des Anwendungsfalls?
• Wer betreibt Integration, Datenzugriffe und Konfiguration?
• Welche Versionen von Modell, Prompt, Regeln und Wissensbestand werden verwendet?
• Welche Qualitäts-, Sicherheits-, Kosten- und Verfügbarkeitswerte werden beobachtet?
• Wie melden Nutzer Fehler?
• Wer bewertet Änderungen des Anbieters?
• Wie werden Vorfälle, Korrekturen und Entscheidungen nachvollziehbar dokumentiert?
• Wann wird erneut getestet?

Protokollierung bedeutet nicht, vorsorglich alle Eingaben dauerhaft zu speichern. Umfang, Zugriffsrechte und Aufbewahrung müssen zum Zweck und Schutzbedarf passen. Für Qualitäts- und Vorfallanalyse werden ausreichende Nachweise benötigt, ohne eine neue unkontrollierte Sammlung sensibler Daten aufzubauen.

Ausschlussgrund: Nach dem Projektende gibt es keinen verantwortlichen Betrieb oder keine Möglichkeit, relevante Qualitäts- und Sicherheitsabweichungen zu erkennen.

7. Kosten und Anbieterabhängigkeit

Ein Pilot betrachtet häufig Lizenz oder API-Aufruf. Die produktive Kostenbasis ist breiter:

• Modell- und Plattformnutzung,
• Datenaufbereitung und Wissenspflege,
• Integration und technische Infrastruktur,
• menschliche Prüfung und Nachbearbeitung,
• Überwachung, Tests und Support,
• Sicherheits- und Datenschutzmaßnahmen,
• Fehler, Ausfälle und Rückabwicklung,
• Anpassung an neue Modell- oder Produktstände,
• Export, Wechsel oder Abschaltung.

Ein günstiger Einzelaufruf kann durch hohe Prüf- oder Nacharbeitskosten unwirtschaftlich werden. Umgekehrt kann ein teurerer Dienst wirtschaftlich sein, wenn er einen klar abgegrenzten Prozess zuverlässig verbessert.

Die Verbindung von IT-Kosten und Leistungskennzahlen ist deshalb auch für KI entscheidend. Gemessen wird nicht nur der Preis pro Anfrage, sondern der Aufwand für ein akzeptables Prozessergebnis.

Ausschlussgrund: Die Organisation kann laufende Kosten weder begrenzen noch einem messbaren Nutzen zuordnen oder besitzt keinen realistischen Umgang mit einer wesentlichen Anbieterabhängigkeit.

8. Rückfallweg und Ausstieg

Jeder produktive KI-Anwendungsfall benötigt eine Antwort auf zwei unterschiedliche Situationen:

1. Was geschieht kurzfristig, wenn das System nicht verfügbar oder nicht verlässlich ist?
2. Wie beendet oder ersetzt die Organisation den Einsatz dauerhaft?

Ein Rückfallweg kann eine manuelle Bearbeitung, eine einfachere Regel oder eine begrenzte Notfunktion sein. Er muss nicht dieselbe Geschwindigkeit bieten. Er muss jedoch für den kritischen Zeitraum realistisch funktionieren.

Für den dauerhaften Ausstieg sind unter anderem relevant:

• Export benötigter Daten und Protokolle,
• Trennung von anbietergebundenen und eigenen Komponenten,
• Entfernung von Zugängen und Integrationen,
• Aufbewahrung notwendiger Nachweise,
• Rückkehr oder Übergang des Prozesses,
• Information betroffener Nutzer und Verantwortlicher.

Das NIST AI RMF sieht auch die sichere Außerbetriebnahme als Bestandteil der Governance. Eine KI-Lösung ist nicht beherrschbar, wenn ihr Einsatz zwar begonnen, aber organisatorisch nicht beendet werden kann.

Ausschlussgrund: Ein Ausfall würde einen wesentlichen Prozess ohne tragfähige Alternative stoppen oder die Organisation kann Daten, Zugriffe und Verantwortung beim Ausstieg nicht geordnet übernehmen.

Die Go-/No-Go-Entscheidung braucht keine Gesamtpunktzahl

Die acht Prüffelder werden nicht addiert. Stattdessen werden drei Arten von Ergebnissen unterschieden:

Ergebnis	Bedeutung	Konsequenz
Ausschlusskriterium offen	Ein rechtlicher, fachlicher, sicherheitsbezogener oder betrieblicher Grund verhindert den verantwortbaren Einsatz	nicht produktiv setzen; Ursache klären oder Anwendungsfall verändern
Nachweis noch unzureichend	Zweck ist plausibel, aber Qualität, Kosten oder Ablauf sind noch nicht ausreichend belegt	Pilot gezielt verlängern und eine konkrete Annahme prüfen
Produktionsreife begrenzt belegt	Kritische Voraussetzungen sind erfüllt und der Einsatz besitzt kontrollierte Grenzen	begrenzte Einführung mit Monitoring, Reviewtermin und Rückfallweg

Auch die dritte Kategorie ist keine dauerhafte Freigabe. Ein produktiver KI-Anwendungsfall kann durch neue Daten, veränderte Nutzung, Modellupdates oder neue Anforderungen seine bisherige Bewertung verlieren.

Die Entscheidung sollte mindestens dokumentieren:

• freigegebener Zweck und Prozessgrenze,
• verwendete System- und Modellversion,
• betrachtete Daten und Nutzergruppen,
• Qualitätsnachweis und bekannte Grenzen,
• akzeptierte Restrisiken,
• Owner und Freigabeberechtigte,
• Überwachung und Abbruchkriterien,
• Datum der nächsten Prüfung.

Rechtliche Einordnung ist ein eigenes Arbeitspaket

Die EU-Verordnung 2024/1689, meist AI Act genannt, unterscheidet unter anderem nach Rolle, Verwendungszweck und Risikokategorie. Anbieter, Betreiber beziehungsweise Nutzer eines Systems können je nach Konstellation unterschiedliche Pflichten besitzen.

Zum Recherchestand 27. Juli 2026 befindet sich die Verordnung in einer gestuften Anwendung. Die Europäische Kommission dokumentiert neben bereits geltenden Teilen auch laufende Anpassungen bestimmter Fristen für Hochrisiko-Regelungen. Deshalb bildet dieser Artikel bewusst keinen vermeintlich dauerhaften Fristenkalender ab.

Der betriebliche Reifecheck beantwortet nicht:

• ob ein konkreter Anwendungsfall rechtlich als KI-System einzuordnen ist,
• welche Rolle die Organisation nach der Verordnung besitzt,
• ob eine verbotene Praxis oder ein Hochrisiko-Anwendungsfall vorliegt,
• welche Transparenz-, Dokumentations-, Prüf- oder Informationspflichten gelten,
• welche weiteren Vorgaben aus Datenschutz, Arbeitsrecht oder Branchenrecht hinzukommen.

Diese Fragen müssen vor der produktiven Nutzung für den konkreten Fall aktuell geprüft und bei Bedarf qualifiziert rechtlich bewertet werden. Ein technisch risikoarm wirkender Pilot ist nicht automatisch rechtlich unkritisch. Umgekehrt ersetzt eine rechtliche Freigabe nicht den Nachweis, dass der Betrieb fachlich und technisch beherrscht wird.

Was die Geschäftsführung über einen Pilotbericht wissen sollte

Ein belastbarer Pilotbericht trennt mindestens vier Aussagen:

1. Technische Machbarkeit: Was konnte unter Testbedingungen gezeigt werden?
2. Gemessene Qualität: Auf welchen Fällen, mit welchen Kriterien und welchen Grenzen?
3. Betriebliche Voraussetzungen: Welche Rollen, Daten, Integrationen und Kontrollen fehlen noch?
4. Entscheidung: Was wird freigegeben, weiter geprüft oder beendet?

Die Aussage „Der Pilot war erfolgreich“ ist ohne diese Trennung zu breit. Ein Pilot kann seine Lernziele erreicht und gleichzeitig gezeigt haben, dass der produktive Einsatz nicht sinnvoll ist. Auch das ist ein gutes Ergebnis, weil eine teure oder riskante Einführung rechtzeitig vermieden wird.

Der erste sinnvolle Schritt

Nehmen Sie den derzeit überzeugendsten KI-Piloten und vervollständigen Sie drei Sätze:

Das System darf ausschließlich …

Das Ergebnis muss von … geprüft werden, wenn …

Der Einsatz wird gestoppt, sobald …

Wenn Zweck, Prüfgrenze und Abbruchkriterium nicht belastbar formulierbar sind, ist der nächste Schritt keine breitere Einführung. Dann muss der Pilot genau diese offenen Annahmen prüfen.

Produktionsreife entsteht nicht dadurch, dass ein Modell oft genug beeindruckt. Sie entsteht, wenn die Organisation Nutzen und Grenzen kennt, Verantwortung ausüben kann und auch bei Fehler, Ausfall oder Ausstieg handlungsfähig bleibt.