Vom KI-Pilotprojekt in den echten Betrieb

1. Ihr Pilot war ein Erfolg. Genau das ist das Problem.

Es gibt eine Diagnose, die in deutschen Unternehmen gerade Karriere macht, obwohl sie in keinem Lehrbuch steht: Pilotitis. Das Krankheitsbild verläuft immer gleich. Ein KI-Pilot wird aufgesetzt, das Team ist angetan, die Demo überzeugt die Geschäftsführung – und dann passiert: nichts. Der Pilot bleibt Pilot. Ein paar Monate später startet der nächste, mit neuem Werkzeug und gleichem Ergebnis. Produktiv, mit echten Kunden, echten Daten und echter Verantwortung, arbeitet die KI nie.

Die Zahlen dazu sind drastisch – und werden fast immer falsch zitiert. Der bekannteste Beleg stammt aus dem MIT-Umfeld: 95 Prozent der Organisationen, so der Report „The GenAI Divide“ von 2025, erzielen aus ihren GenAI-Investitionen bislang keinen messbaren Ertrag; nur 5 Prozent der Piloten erreichen Wirkung in der Gewinn-und-Verlust-Rechnung [1]. Gemessen wurde also nicht, ob die Technik funktioniert, sondern ob binnen sechs Monaten ein selbstberichteter Ergebniseffekt eintrat – als ausdrücklich vorläufiger Befund auf schmaler Datenbasis. Die methodische Kritik ließ nicht auf sich warten: Die 95 Prozent sind aus den veröffentlichten Daten nicht als repräsentative Marktquote herzuleiten, das Beobachtungsfenster ist kurz, und die Auswahl verbindet öffentliche Initiativen, Interviews und eine Befragung. Wer die Zahl als „KI funktioniert nicht“ liest, liest sie also falsch [1].

Weitere Quellen messen andere, aber verwandte Übergangsprobleme. Gartner prognostizierte im Juli 2024, dass mindestens 30 Prozent aller GenAI-Projekte bis Ende 2025 nach dem Proof of Concept (dem reinen Machbarkeitsnachweis) abgebrochen sein würden [2]. Im Januar 2026 berichtete Gartner rückblickend von mindestens 50 Prozent aufgegebenen GenAI-Projekten nach dem PoC; genannt werden schlechte Datenqualität, unzureichende Risikokontrollen, steigende Kosten und unklarer Geschäftswert [3]. S&P Global maß 2025 unter gut tausend Unternehmen in Nordamerika und Europa: Der Anteil derer, die die Mehrheit ihrer KI-Initiativen vor der Produktivsetzung stoppen, ist binnen eines Jahres von 17 auf 42 Prozent gesprungen [4].

Diese Kennzahlen sind nicht gleichzusetzen: Sie erfassen fehlenden Ergebniseffekt, Projektabbruch und ausbleibende Produktivsetzung. Gemeinsam zeigen sie dennoch eine Umsetzungslücke. Viele KI-Initiativen scheitern nicht an der Modellfähigkeit allein, sondern an der Übersetzung in einen wirtschaftlich und organisatorisch tragfähigen Betrieb. Das ist die gute Nachricht in den schlechten Zahlen, denn viele dieser Bedingungen lassen sich gestalten. Wie das misslingt und dann gelingt, zeigt in diesem Paper ein durchgängiges Beispiel: der Reklamations-Agent eines Elektro-Großhändlers. Ein Agent ist dabei mehr als ein Chatbot, nämlich ein KI-System, das selbstständig Arbeitsschritte ausführt, Daten abruft und Vorgänge anstößt. Dieser Agent begann als gefeierter Pilot, stürzte als teurer Blindflug ab und wurde beim zweiten Anlauf erwachsen.

Drei verschiedene Erhebungen mit drei verschiedenen Messgrößen. Die Zahlen lassen sich weder addieren noch zu einer gemeinsamen Scheiterquote verrechnen.

2. Der Pilot beweist das Falsche

Warum scheitern Piloten, die doch funktioniert haben? Weil ein Pilot eine andere Frage beantwortet, als der Betrieb stellt. Der Pilot fragt: Kann das Modell die Aufgabe? Der Betrieb fragt: Übersteht das System den Alltag? Das sind keine zwei Schwierigkeitsgrade derselben Prüfung. Es sind zwei verschiedene Fächer.

Im Piloten bearbeitet die KI ausgewählte, oft stillschweigend kuratierte Fälle. Im Betrieb kommt das Alltagsrauschen: unvollständige Anfragen, wütende Kunden, Sonderfälle, Tippfehler, Anhänge in absurden Formaten. Im Piloten sitzen wohlwollende Power-User, die Fehler der KI amüsiert korrigieren. Im Betrieb sitzen Sachbearbeiter unter Zeitdruck – und draußen echte Kunden, die jede Auskunft für bare Münze nehmen. Im Piloten greift niemand an; im Betrieb ist jede E-Mail, jedes PDF ein möglicher Träger versteckter Anweisungen an den Agenten (Prompt Injection). Im Piloten steht das Modell still; im Betrieb ändert der Anbieter es im Hintergrund, und das Verhalten kippt leise. Im Piloten sind die Kosten eine sichtbare Flatrate; im Betrieb laufen sie nutzungsbasiert und unsichtbar in der Cloud-Sammelrechnung auf. Und im Piloten bleiben Haftungsfragen oft ausgeblendet; im Betrieb trägt das Unternehmen das rechtliche und wirtschaftliche Risiko der eingesetzten Systeme, dessen konkrete Folgen vom Einzelfall abhängen.

Die meisten dieser Unterschiede vertieft diese Whitepaper-Serie in eigenen Papers – etwa zur Haftung für Agentenfehler, zu den Kosten im laufenden Betrieb und zur Ausfallsicherheit; hier genügt der Blick auf die Summe (Abbildung 1): Der Pilot findet unter Laborbedingungen statt und wird an der Begeisterung gemessen. Der Betrieb findet unter Alltagsbedingungen statt und wird am Ergebnis gemessen. „Der Pilot lief doch super“ unterliegt deshalb leicht einem Selektions- und Demo-Bias: Sichtbar werden die kuratierten Fälle, nicht die Verteilung und Fehlerschwere im späteren Alltag.

Die Empirie stützt diese Lesart. Der MIT-Report definiert Erfolg ausdrücklich als Einsatz jenseits der Pilotphase mit messbaren Kennzahlen; sein Befund betrifft damit gerade die Schwelle zur Wirkung, schließt Modell- oder Aufgabenprobleme aber nicht aus [1]. Gartner nennt als Abbruchgründe Datenqualität, Risikokontrollen, Kosten und unklaren Geschäftswert [3]. McKinsey vermaß Ende 2025 dieselbe Lücke von der anderen Seite: 88 Prozent der Unternehmen nutzen KI inzwischen regelmäßig in mindestens einer Geschäftsfunktion, aber fast zwei Drittel haben mit der Skalierung noch nicht einmal begonnen, und nur 39 Prozent berichten überhaupt einen Ergebniseffekt auf Unternehmensebene [5].

Ein Einwand gehört an dieser Stelle offen ausgesprochen, weil er sich auf dieselben Quellen stützt: Gartner nennt unter den Abbruchgründen ausdrücklich unklaren Geschäftswert, McKinsey misst Verbreitung ohne Ergebniseffekt, MIT misst ausbleibende Wirkung in der Gewinn-und-Verlust-Rechnung. Ein erheblicher Teil der Piloten stirbt also nicht an fehlenden Kontrollen, sondern daran, dass er sich nicht rechnet. Für diese Fälle wäre mehr Governance die falsche Medizin – sie verteuert genau das, was ohnehin am Nutzen scheitert. Beide Ursachen existieren nebeneinander, und sie verlangen unterschiedliche Antworten: Fehlt der Wert, gehört der Anwendungsfall beendet. Fehlt die Betreibbarkeit, gehört sie gebaut. Dieses Whitepaper behandelt den zweiten Fall – setzt den ersten aber voraus. Die Reihenfolge ist nicht verhandelbar: erst Business Case, dann Stufe (Kapitel 7).

Dass der zweite Fall nicht selten ist, spricht auch für ein älteres Muster: Schon 2015 zeigte eine viel zitierte Arbeit für klassisches maschinelles Lernen, dass der Modellcode der kleinste Teil eines Produktivsystems ist und der Aufwand in Daten, Konfiguration, Überwachung und Schnittstellen steckt [23]. Die Pilotitis ist insofern kein GenAI-Phänomen, sondern seine jüngste Ausprägung.

Oft fehlt deshalb nicht nur Modellqualität, sondern ein Betriebskonzept. Eine seiner zentralen Entscheidungen lautet: Wie viel darf das System allein? Wer diese Frage nicht ausdrücklich beantwortet, beantwortet sie durch Unterlassen – und landet in einer der beiden Verlaufsformen der Pilotitis, die das nächste Kapitel auf der Treppe verortet.

3. Die Autonomie-Treppe – und warum dieses Modell bei Stufe 4 endet

„Soll die KI das dürfen?“ wird im Mittelstand meist als Ja/Nein-Frage verhandelt: Entweder bleibt der Agent Spielzeug, oder er bekommt im Überschwang des Rollouts auf einen Schlag alle Freiheiten. Beides ist falsch, denn Autonomie ist keine Eigenschaft, die ein System hat oder nicht hat. Sie hat Stufen.

Die Denkfigur kennen Sie vom autonomen Fahren: Die Norm SAE J3016 unterscheidet sechs Stufen, von „keine Automation“ bis zum vollautonomen Fahrzeug [6]. Dass Automation grundsätzlich ein Kontinuum abgestufter Niveaus ist, hat die Ingenieurpsychologie schon vor einem Vierteljahrhundert beschrieben [7], und die aktuelle Agentenforschung überträgt die Stufenlogik gerade auf KI-Agenten – am greifbarsten über die Rolle, die dem Menschen auf jeder Stufe bleibt, vom Bediener bis zum bloßen Beobachter [8], [9]. Der Geltungsbereich dieses Whitepapers sind LLM-basierte Agentensysteme, die Informationen erzeugen, Daten abrufen oder Arbeitsschritte auslösen; für andere KI-Systeme ist die Treppe nur nach einer eigenen Risikoanalyse übertragbar. Für die Praxis übersetzen wir das in fünf Rollenbilder, die jeder Geschäftsführer aus seiner Organisation kennt: die Autonomie-Treppe. Das Neue daran ist weniger die Stufenlogik als ihre Konsequenz: Jede Stufe bekommt Pflichten (Kapitel 4), eine Bewährung (Kapitel 5) und einen Rückweg (Kapitel 6). Was jede Stufe bedeutet, zeigt derselbe Vorgang – eine eingehende Reklamation.

Eine Stufe allein beschreibt ein System nicht. Neben der Entscheidungsautonomie steht der Wirkradius: Erzeugt der Agent nur Vorschläge, greift er auf eigene Daten und Systeme zu, oder wirkt er unmittelbar nach außen? Beide Achsen sind unabhängig. Ein Agent auf Stufe 1, der Personaldaten liest, braucht mehr Kontrollen als ein Agent auf Stufe 3, der reversible interne Dateien sortiert. Deshalb nennt jede Zeile der Readiness-Matrix in Kapitel 4 ausdrücklich, was sie auslöst: die Stufe, der eigene Datenzugriff oder ein Risikotrigger.

Stufe 0 – das Werkzeug

Der Mensch arbeitet, die KI schlägt vor. Der Sachbearbeiter fragt den Chat nach einer Formulierung, kopiert, was taugt. Außenwirkung der KI: keine.

Stufe 1 – der Zuarbeiter

Die KI liefert vollständige Entwürfe. Im einfachsten Fall stellt der Mensch den freigegebenen Kontext bereit. Liest die KI – wie im Reklamationsbeispiel – selbst Reklamation, Historie oder Lieferdaten, beginnen Identitäts-, Rechte-, Logging-, Security- und Datenschutzkontrollen bereits auf dieser Stufe. Der Mensch prüft jede einzelne Ausgabe, bevor irgendetwas das Haus verlässt (Human in the Loop). Die meisten erfolgreichen Piloten leben genau hier.

Stufe 2 – der Sachbearbeiter mit Vier-Augen

Die KI führt den Vorgang aus, auch in den Systemen: Sie bereitet die Gutschrift im ERP vor, adressiert die Antwort. Aber jede Wirkung nach außen braucht eine qualifizierte menschliche Freigabe auf Basis sichtbarer Originaldaten und Belege. Ein Klick allein genügt nicht. Das Vier-Augen-Prinzip, das bei Zahlungen niemand infrage stellt, gilt jetzt für den Agenten.

Stufe 3 – der beaufsichtigte Autopilot

Standardfälle laufen Ende-zu-Ende ohne Klick. Der Mensch verschwindet nicht, er wechselt die Rolle: Er überwacht über Stichproben, Alarme und Kennzahlen, und definierte Sonderfälle – Neukunde, hoher Betrag, gereizter Ton – eskalieren automatisch an ihn (Human on the Loop).

Stufe 3 ist nicht Stufe 2 mit weniger Arbeit. Sie ist die Stufe mit der eigenen Fehlerklasse. Die Automatisierungsforschung beschreibt das seit Jahrzehnten: Wer nur noch überwacht, verliert Übung und Situationsbewusstsein – und muss genau dann eingreifen, wenn die Lage ungewöhnlich und der Prüfer am wenigsten vorbereitet ist. Menschen sind schlechte Daueraufmerksamkeitsmaschinen, und wer selten korrigiert, korrigiert irgendwann gar nicht mehr [20], [21], [22]. Praktische Folge: Stichproben werden nach Risiko gezogen, nicht zufällig; ein Teil der Fälle bleibt dauerhaft prüfpflichtig, damit die Prüfkompetenz nicht verfällt; Alarme müssen eine Handlung erzwingen statt nur zu erscheinen; und wer prüft, braucht Zeit und Zugriff auf die Originaldaten. Wer Stufe 3 ohne diese Vorkehrungen betritt, hat die Kontrolle nicht verlagert, sondern abgeschafft.

Stufe 4 – Autonomie in Grenzen

Die KI entscheidet allein, aber in einem eng umrissenen, schriftlich fixierten Rahmen: etwa Kulanz bis zu einem risikobasiert festgelegten Beispielwert von 200 Euro, definierte Fallklassen und lückenloses Protokoll. Der Mensch kommt bei Eskalationen und im Audit vor, nicht mehr im Einzelfall.

Auf dieser Stufe kommt eine Rechtsfrage hinzu, die auf den unteren Stufen nicht auftritt. Trifft ein System eine Entscheidung über eine natürliche Person allein und hat diese Entscheidung rechtliche Wirkung oder beeinträchtigt sie die Person in ähnlicher Weise erheblich, greift Art. 22 DSGVO: Solche Entscheidungen sind grundsätzlich unzulässig, sofern keine Ausnahme greift, und verlangen dann mindestens das Recht auf Eingreifen einer Person, auf Darlegung des eigenen Standpunkts und auf Anfechtung [17]. Im Reklamationsbeispiel geht es um Geschäftskunden, dort greift die Vorschrift regelmäßig nicht. Bei Verbrauchern, Bewerbern oder Beschäftigten kann sie die zulässige Höchststufe begrenzen – unabhängig davon, wie gut das System misst.

Dieses Governance-Modell sieht bewusst keine Stufe 5 ohne organisatorische Aufsicht vor. Das ist keine Aussage über technische Machbarkeit, sondern eine Führungsentscheidung: Auch bei hoher operativer Autonomie bleiben Verantwortlichkeit, Monitoring, Audit und Abschaltbarkeit erhalten. Für Hochrisiko-Systeme schreibt die EU-KI-Verordnung wirksame menschliche Aufsicht ausdrücklich vor [10]; für andere Systeme bestimmt die Risikoanalyse Art und Intensität der Aufsicht (Kapitel 6).

Auf dieser Treppe lassen sich die beiden Verlaufsformen der Pilotitis präzise verorten. Verlaufsform eins ist die ewige Demo: Das Unternehmen wächst auf Stufe 0 oder 1 fest, aus Vorsicht, und der Nutzen bleibt so klein, dass der Business Case nie trägt. Verlaufsform zwei ist der Blindflug: der Sprung von Stufe 1 direkt auf Stufe 3 oder 4 im Rollout – ohne die Kontrollen, die diese Stufen verlangen. Die erste Form kostet den Nutzen. Die zweite produziert den Vorfall, der das Projekt beerdigt.

4. Wann welche Pflicht greift: die Readiness-Matrix

Die Treppe strukturiert eine Dimension der Produktionsreife: operative Autonomie. Die Readiness-Matrix (Abbildung 4) ordnet zehn Kontrollbereiche als Mindestkontrollen zu. „Ab Stufe 2″ bedeutet deshalb spätestens ab Stufe 2, nicht erst ab Stufe 2. Wer Stufe 3 will, muss die dort ausgewiesenen Pflichten erfüllen, bevor der erste Standardfall automatisch das Haus verlässt.

Die Stufe setzt den Startpunkt, sie ist aber nicht der einzige Auslöser. Drei Auslöser stehen nebeneinander, und es gilt immer der früheste: Stufe – Qualität und Grounding, Evals, Kostensteuerung, Mensch und Prozess folgen der Autonomiestufe, weil sie deren Fehlermodi adressieren. Zugriff – Security, Identität und Rechte, Datenschutz und technisches Logging beginnen, sobald der Agent selbst auf Daten oder Systeme zugreift, im Reklamationsfall also bereits auf Stufe 1. Trigger – Verfügbarkeit und Notbetrieb folgen einer Kritikalitätsprüfung, nicht der Stufennummer; ebenso können die fünf Risikotrigger einzelne Kontrollen vorziehen. Abbildung 4 weist den Auslöser je Zeile mit S, Z oder T aus.

Der Risiko-Overlay: fünf Trigger

Vor der Stufenzuordnung werden fünf Kontextfragen beantwortet. Schon ein starker Trigger kann zusätzliche Kontrollen, Mitzeichnungen oder eine niedrigere maximal zulässige Autonomie verlangen. Die Logik folgt dem kontextbezogenen Govern–Map–Measure–Manage-Ansatz des NIST AI RMF und ersetzt weder Rechtsprüfung noch Business Case [11], [19].

Vier kontrastierende Anwendungsfälle zeigen, warum beide Achsen nötig sind – und wo die Stufenlogik an ihre Grenze kommt (Abbildung 3). Die Beispiele illustrieren die Entscheidungslogik, belegen aber keine empirische Wirksamkeit des Frameworks.

Verlässlich antworten

Sobald Entwürfe menschliche Arbeit ersetzen (Stufe 1), braucht jede Tatsachenbehauptung des Agenten einen Beleg aus den eigenen Daten. Ein Grounding-Check stellt sicher, dass Aussagen aus den abgerufenen Dokumenten stammen und nicht aus dem Sprachgefühl des Modells, das erfundene Auskünfte genauso selbstsicher formuliert wie echte. Dahinter gehört eine gepflegte Wissensbasis, deren Aktualität aktiv verwaltet wird.

Ab Stufe 2 kommt Verhaltensstabilität hinzu: versionierte Prompts und eine Eval-Suite, also automatisierte Tests, die regelmäßig und vor jeder eigenen Änderung prüfen, ob bewährte Fälle noch richtig beantwortet werden. So fallen stille Modell-Updates des Anbieters oder ein Modellwechsel auf, bevor Kunden sie bemerken.

Und von Anfang an gilt: Der Zuständigkeitsbereich des Agenten ist schriftlich definiert, was er tut und was ausdrücklich nicht. Ab Stufe 2 wird diese Grenze technisch durchgesetzt (Guardrails), nicht nur dokumentiert.

Sicher und datenschutzgerecht handeln

Sobald der Agent selbst Daten oder Systeme liest – im Reklamationsfall bereits auf Stufe 1 – gelten Least Privilege, eine eigene Maschinenidentität, inventarisierte und befristete Zugangsdaten sowie ein geregeltes Offboarding. Alles, was der Agent liest, kann versteckte Anweisungen enthalten; externe Inhalte werden deshalb als nicht vertrauenswürdig behandelt, Aktionen eng berechtigt und irreversible Schritte bestätigt. Genau diese Muster – Prompt Injection, übermäßige Handlungsvollmacht, unkontrollierte Werkzeugnutzung – führt die aktuelle OWASP-Liste für agentische Anwendungen als Hauptrisiken [18]. Ein Sammel-Account mit Adminrechten ist auf keiner Stufe vertretbar.

Personenbezogene Daten lösen unabhängig von der Autonomiestufe einen eigenen Kontrollpfad aus: festgelegter Zweck und Rechtsgrundlage, Datenminimierung, Herkunft, Aufbewahrung und Löschung, Betroffenenrechte, Anbieter- und Transferprüfung sowie angemessene Sicherheit. Bei voraussichtlich hohem Risiko ist zu prüfen, ob eine Datenschutz-Folgenabschätzung erforderlich ist. Entscheidet das System über natürliche Personen allein, kommt Art. 22 DSGVO hinzu – mit dem Recht auf Eingreifen einer Person, auf Darlegung des eigenen Standpunkts und auf Anfechtung. Wer nach außen wirkt, braucht deshalb einen benannten Weg, auf dem ein Betroffener eine menschliche Überprüfung verlangen kann. Das folgt aus Datenschutz durch Technikgestaltung und der risikobasierten DSGVO-Logik [17].

Und er bekommt ein Kostenmaß. Verbrauchsmessung je Vorgang ab Stufe 2; ab Stufe 3 zusätzlich Budgetdeckel und ein Not-Aus (Kill-Switch), denn ein Agent kann sich in wiederholten Anläufen festlaufen, und jede Runde kostet Geld.

Verantwortet betreiben

Menschen zuerst: Schulung und ein attraktives, freigegebenes Werkzeug gehören schon auf Stufe 0 dazu. Sonst wandert die Nutzung in die Schatten-KI, und mit ihr jede Kontrolle. Die KI-Verordnung verlangt diese Kompetenzförderung seit Februar 2025 ausdrücklich von Anbietern wie Betreibern (Art. 4) [10], [15] – unabhängig davon, wie das System später eingestuft wird.

In mitbestimmten Betrieben kommt ein Aufwandstreiber hinzu, der regelmäßig unterschätzt wird. Sobald das System Freigabezeiten, Korrektur- oder Override-Quoten je Sachbearbeiter erfasst – und genau das verlangt eine belastbare Bewährung –, ist es eine technische Einrichtung, die zur Überwachung von Verhalten oder Leistung geeignet ist. Damit greift das Mitbestimmungsrecht des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG. Eine Betriebsvereinbarung ist dann kein Nice-to-have, sondern Voraussetzung der Einführung – und sie braucht Vorlauf.

Verantwortung heißt: je Anwendungsfall ein benannter Verantwortlicher, dokumentierte Entscheidungsgrenzen und ein Audit-Log ab der ersten automatisierten Daten- oder Systemaktion. Das Protokoll soll vollständig, zugriffsgeschützt und manipulationsgeschützt beziehungsweise manipulationsnachweisbar sein; Aufbewahrung, Löschung und Zugriffsrollen werden ausdrücklich festgelegt. Es sind dieselben Unterlagen, die im Schadensfall Rekonstruktion und rechtliche Bewertung ermöglichen.

Verfügbarkeit folgt nicht automatisch aus Stufe 3. Eine Kritikalitätsprüfung entscheidet, ob ein Ausfall des Modell-Anbieters oder der Cloud den Prozess stoppt, welcher Notbetrieb nötig ist und wie Wiederanlauf sowie Ausfall geübt werden. Ein Stufe-1-System kann kritisch, ein isoliertes Stufe-3-System dagegen leicht ersetzbar sein.

Im günstigen Fall lassen sich die Mindestkontrollen der Stufen 1 und 2 mit vorhandenen Werkzeugen in wenigen Wochen umsetzen. Legacy-ERP, fehlendes IAM, sensible Daten, Anbieterprüfung, Mitbestimmung oder regulatorische Anforderungen können daraus jedoch ein eigenes Vorhaben machen – aus Wochen werden dann Quartale. Der Sprung ist selten linear (Abbildung 5): Der Aufwand von Stufe 0 auf 1 ist meist gering, von 2 auf 3 dagegen erheblich, weil dort Evals, Monitoring, Eskalationslogik und Notbetrieb zusammenkommen und erstmals ein laufender Betriebsaufwand entsteht. Aufwand und Zielstufe gehören deshalb in denselben Business Case – und ein zusätzlicher Kontrollaufwand, der den erwarteten Nutzen aufzehrt, ist ein Argument gegen den Anwendungsfall, nicht für eine niedrigere Stufe.

Ein Teil dieser Kontrollen lässt sich nicht selbst bauen, sondern einkaufen: Standardsoftware bringt Rechtekonzept, Protokollierung und Eskalation häufig mit. Das verschiebt zugleich die Rollenfrage – wer ein System nur einsetzt, ist Betreiber; wer es selbst zusammenbaut und in Betrieb nimmt, wird regelmäßig zum Anbieter und trägt zusätzliche Pflichten (Kapitel 6). Und für einen Teil der Standardfälle ist die ehrlichste Lösung keine KI, sondern eine Regel: Wo der Vorgang deterministisch entscheidbar ist, ist ein Sprachmodell die teurere und weniger prüfbare Variante.

Die Matrix ist eine Praxisheuristik, kein Normersatz. Sie soll Lücken sichtbar machen, nicht Vollständigkeit oder Compliance garantieren. Der Crosswalk zeigt die Anschlussfähigkeit, keine Zertifizierung oder Eins-zu-eins-Äquivalenz.

Orientierung nach NIST AI RMF, NIST GenAI Profile, NIST Playbook und ISO/IEC 42001 [11], [12], [16], [19].

5. Ein Pilot wird erwachsen

Wie sich das alles anfühlt, zeigt der Fall, der dieses Paper begleitet – konstruiert, aber aus realen Mustern gebaut; alle Zahlen sind eine Modellrechnung.

Akt 1: Der Pilot begeistert

Ein Elektro-Großhändler mit drei Standorten pilotiert einen KI-Agenten in der Reklamationsbearbeitung: Reklamation lesen, kategorisieren, Historie und Lieferdaten prüfen, Antwort entwerfen. Vier Wochen, zwei erfahrene Sachbearbeiter, Stufe 1. Die Entwürfe sparen spürbar Zeit, die Qualität überzeugt, die Geschäftsführung ist angetan. Der Pilot, heißt es im Haus, war ein voller Erfolg.

Akt 2: Blindflug und Absturz

Für den Rollout wird der Agent direkt auf Autoversand gestellt, Stufe 3, aber nur dem Namen nach: kein Beleg-Check, keine Betragsgrenze, keine Eskalationsregeln, keine Verbrauchsmessung. Drei Wochen geht das gut. Dann sagt der Agent einem A-Kunden schriftlich den vollen Ersatz einer reklamierten Großlieferung zu, rund 18.000 Euro, gestützt auf eine Kulanzregel, die es nie gab. Das Modell hat sie erfunden; kein Mechanismus hat nachgeprüft. Der Kunde besteht auf der Zusage. Dass so etwas bindend werden kann, ist keine akademische Sorge: Im Fall Moffatt v. Air Canada rechnete das Civil Resolution Tribunal in British Columbia der Airline 2024 eine falsche Tarifauskunft ihres Website-Chatbots zu [13]. Der kanadische Einzelfall zeigt, dass Betreiber sich nicht ohne Weiteres von Ausgaben des eigenen Bots distanzieren können. Er begründet jedoch keine pauschale Haftungsregel für Deutschland; Rechtsfolgen hängen von Jurisdiktion, Vertragsbeziehung, Einsatzkontext und Systemgestaltung ab und sind im konkreten Fall juristisch zu prüfen. Beim Großhändler folgt, was in solchen Fällen fast immer folgt: peinliche Verhandlung, interner Vertrauensbruch, der Agent wird abgeschaltet. Vier Monate Stillstand, Etikett: „KI funktioniert bei uns nicht.“ Das ist die klassische Verlaufsform der Pilotitis: Nicht der Fehler beerdigt das Projekt, sondern die fehlende Systematik danach.

Akt 3: Die Treppe

Der zweite Anlauf beginnt nicht mit einem besseren Modell, sondern mit einem Betriebskonzept. Stufe 2: Jede Außenwirkung braucht eine qualifizierte Freigabe; der Prüfer sieht Original, Belege und Entscheidungsgrund, hat ein realistisches Zeitbudget und kann übersteuern. Guardrails verbieten Zusagen ohne Beleg aus den Lieferdaten; jede Behauptung trägt ihre Quelle; Freigabezeit, Korrektur, Override und Fehlerschwere werden gemessen; Freigaben werden stichprobenweise auditiert. Der Leiter Vertriebsinnendienst ist benannter Verantwortlicher. Die Beschäftigten werden für Systemgrenzen und Automatisierungsbias geschult [20], [21].

Vorab schriftlich fixiert ist auch, was Bewährung in dieser Modellrechnung heißt: als Beispielwerte sechs Wochen, mindestens 19 von 20 Entwürfen ohne Korrektur freigegeben und null Guardrail-Verstöße. Entscheidend ist dabei der Bezugspunkt. Eine Schwelle, die niemand vorher an der menschlichen Bearbeitung gemessen hat, ist willkürlich – und in der Praxis meist strenger als der Status quo, was Aufstiege blockiert, die längst gerechtfertigt wären. Der Großhändler misst deshalb vor dem Piloten, wie häufig und wie schwer die manuelle Bearbeitung derselben Fälle danebenliegt, und setzt die Schwelle relativ dazu: nicht schlechter als der Mensch, bei den folgenschweren Fehlerklassen messbar besser. Dazu kommen eine ausreichende Fallzahl und eine Fehlerschweregrenze – ein seltener, folgenschwerer Fehler darf nicht in einer guten Durchschnittsquote verschwinden.

Erst als Kontrollen und Kriterien erfüllt sind, folgt Stufe 3. Standardfälle gehen automatisch raus; beispielhaft eskaliert wird bei Neukunden, Streitwert über 500 Euro, negativer Tonalität und allen A-Kunden. Nach einem modellhaften Bewährungszeitraum von sechs Monaten kommt Stufe 4 für einen eng umrissenen Rahmen: Kulanz bis zum Beispielwert von 200 Euro entscheidet der Agent allein, mit Protokoll und wöchentlicher Stichprobe. Die beiden Beträge messen Verschiedenes und stehen nicht im Widerspruch: 500 Euro ist die Grenze, ab der ein Vorgang überhaupt an einen Menschen geht; 200 Euro ist der Betrag, über den der Agent innerhalb der verbleibenden Fälle selbst entscheiden darf. Als ein Modell-Update des Anbieters die Eval-Suite rot färbt, wird für zwei Wochen auf Stufe 2 zurückgeschaltet – Routine, kein Drama. Am Ende laufen in dieser Modellrechnung rund 70 Prozent der Reklamationen ohne menschlichen Handgriff, die modellhafte Durchlaufzeit fällt von zwei Tagen auf vier Stunden, die Sachbearbeiter arbeiten Sonderfälle und Stichproben. Es ist dieselbe KI wie in Akt 2. Der Unterschied ist die Treppe.

Was dieser Zielzustand für die Belegschaft bedeutet, gehört zur Planung und nicht ans Ende. Bei 70 Prozent Automatisierung ändert sich der Zuschnitt der Sachbearbeiterrolle grundlegend: weniger Routine, mehr Sonderfälle, Stichproben und Eskalationen – anspruchsvollere Arbeit, aber nicht dieselbe. Wer das erst nach dem Aufstieg bespricht, verliert die erfahrenen Prüfer, deren Urteil die Bewährung überhaupt erst möglich gemacht hat. Rollenzuschnitt, Qualifizierung und Mitbestimmung gehören deshalb in denselben Beschluss wie die Zielstufe.

6. Aufstieg ist Führungsarbeit

Werkzeuge halten eine Stufe. Über den Wechsel entscheidet Führung – und genau hier trennt sich der Betrieb von der Bastelei.

Das beginnt bei der Zuständigkeit: je Anwendungsfall ein benannter Verantwortlicher, der die Stufe kennt, die Kennzahlen sieht und den Wechsel verantwortet. Abhängig vom Risikoprofil zeichnen Fachbereich, IT/Security, Datenschutz, Compliance und gegebenenfalls Betriebsrat oder Einkauf mit. Ohne diese Zuordnung gehört der Agent allen und niemandem – und Kosten wie Vorfälle laufen als Sammelposten bei der IT auf. Der Stufenwechsel selbst ist eine dokumentierte Entscheidung entlang von vier Fragen: Sind die Bewährungskriterien erfüllt? Sind die Kontrollen der Zielstufe eingebaut und geprüft? Wer trägt das Restrisiko – und hat er es schriftlich akzeptiert? Und: Was löst die Rückstufung aus?

Denn Runterschalten ist der Normalfall eines gesunden Betriebs, nicht sein Scheitern. Ein Modell-Update färbt die Evals rot, ein Vorfall häuft sich, die Kosten je Vorgang springen an – dann geht es eine Stufe zurück, bis die Ursache verstanden ist. Eine Organisation, die nur aufwärts kennt, hat keinen Regelkreis, sondern eine Rutsche.

Öffentliche Belege dafür sind rar – und das ist selbst ein Befund. Unternehmen berichten über Automatisierungserfolge und schweigen über Korrekturen, weshalb kaum ein dokumentierter Stufenwechsel nachvollziehbar ist. Am nächsten kommt Klarna: Das Unternehmen stärkte 2025 den menschlichen Kundenservice aus Qualitätsgründen und hielt zugleich an einer AI-first-Strategie fest [14]. Das ist kein Stufenwechsel eines einzelnen Systems, sondern eine Neugewichtung auf Portfolioebene. Genau deshalb taugt es als Warnung: Wer erst nachsteuert, wenn die Qualität öffentlich sichtbar leidet, korrigiert teurer als der, dessen Rückstufung eine geübte Routine mit definierten Auslösern ist.

Die Aufsicht selbst ist ein Qualitätsprozess, kein Freigabe-Klick. Auf Stufe 2 braucht sie sichtbare Quellen und Entscheidungsgründe, realistische Prüfzeit, Schulung, dokumentierte Overrides und Audits der Freigaben. Auf Stufe 3 und 4 kommen risikogewichtete Stichproben, Alarme und ein regelmäßiger Blick mindestens auf Freigabe-, Override- und Eskalationsquote, Bearbeitungszeit, Fehlerschwere sowie Kosten je Vorgang hinzu. Das Ziel ist angemessene statt maximale Automationsnutzung [20], [21]. Diese Aufsicht produziert zugleich die Evidenz, die den nächsten Aufstieg rechtfertigt: Wer auf Stufe 2 sauber misst, kann Stufe 3 begründen, statt sie zu erhoffen.

Was verschoben wurde – und was nicht

Die Digital-Omnibus-Verordnung zur KI ist als Verordnung (EU) 2026/1744 am 24. Juli 2026 im Amtsblatt erschienen und am 27. Juli 2026 in Kraft getreten [15]. Sie verschiebt die Hochrisiko-Pflichten, lässt die übrigen Fristen aber unberührt (Abbildung 8).

Für einen kundenseitigen Agenten wie im Beispiel ist deshalb nicht 2027 das nächste relevante Datum, sondern der 2. August 2026: Wer mit einem KI-System unmittelbar mit Menschen kommuniziert, muss sie darüber informieren, soweit es sich nicht ohnehin aus den Umständen ergibt. Ob darüber hinaus die Hochrisiko-Pflichten greifen, hängt von der rechtlichen Klassifizierung des konkreten Systems ab – für eine HR-Vorauswahl etwa anders als für eine Reklamationsbearbeitung. Unabhängig von der Klassifizierung bleibt wirksame Aufsicht ein belastbares Governance-Muster.

7. Fünf Fragen, dann wissen Sie es

Ob Ihr Pilot erwachsen wird, entscheidet sich an fünf Fragen – in dieser Reihenfolge (Abbildung 10). Erstens: Trägt der Anwendungsfall überhaupt? Nutzen, Fallzahl und der Aufwand für die nötigen Kontrollen gehören in dieselbe Rechnung. Fällt sie negativ aus, ist das richtige Ergebnis nicht eine niedrigere Stufe, sondern der Verzicht. „Wir setzen das nicht produktiv“ ist ein legitimer, dokumentierter Beschluss – und bei einem erheblichen Teil der Piloten der wirtschaftlich richtige. Zweitens: Auf welcher Stufe steht jeder Ihrer KI-Anwendungsfälle heute – wirklich, nicht dem Anspruch nach? Wer die Stufe nicht benennen kann, kann auch die zugehörigen Pflichten nicht benennen; die Antwort lautet dann „unbestimmt“, und Unbestimmtheit ist kein Zustand, in dem man produktiv geht. Drittens: Welche Risikotrigger greifen bei Schaden, Reversibilität, Daten, Regulierung, Exposition und Prozesskritikalität – und wo greift der Agent selbst auf Daten zu? Viertens: Welche Stufe liefert den besten Netto-Nutzen – auch wenn das dauerhaft Stufe 1 ist? Fünftens: Welche Mindestkontrollen und vorgezogenen Kontrollen sind offen, und wer zeichnet den Wechsel mit?

Ehrlich bleibt zweierlei. Die Treppe ersetzt keinen Business Case – ob sich ein Anwendungsfall lohnt, klären Nutzen- und Kostenrechnung, denen diese Serie eigene Papers widmet: das Preisparadox der KI-Kosten und das Tokenbudget je Aufgabe. Und sie ist eine Praxisheuristik, kein zertifizierbarer Standard: Sie ordnet bewährte Konzepte – Stufenlogik, menschliche Aufsicht, Risikosteuerung – zu einem gangbaren Weg. Wo der Schutzbedarf allein aus den Daten folgt und die Autonomie fast nichts anordnet, ist sie das falsche Werkzeug.

Aber genau das ist der Punkt: Der Weg vom Piloten in den Betrieb ist kein Sprung, den man wagt, sondern eine Treppe, die man baut. Die 95 Prozent sind kein Beleg, dass KI nicht funktioniert. Sie zeigen vielmehr, wie häufig zwischen Machbarkeit, Wert und tragfähigem Betrieb eine Lücke bleibt. Die Treppe und der Risiko-Overlay machen diesen Weg prüfbar: passende Stufe, begründete Kontrollen, wirksame Aufsicht und dokumentierte Freigabe.

Quellen