Vom Pilot zum verlässlichen Betrieb

Eine erfolgreiche Demo trifft auf einen veränderlichen echten Prozess

Ein Supportteam testet einen Antwortassistenten. In der Vorführung bearbeitet er 20 ausgesuchte Anfragen. Die Texte sind vollständig, die Anhänge lesbar und die passenden Handbuchseiten aktuell. Das Ergebnis sieht gut aus.

Am Montag gehen 600 echte Anfragen ein. Einige Kunden schicken Fotos. Andere antworten auf alte E-Mails und lassen wichtige Angaben weg. Über Nacht wurde ein Produkt umbenannt. Eine angebundene Datenquelle fällt für 18 Minuten aus. Der Assistent schreibt trotzdem flüssige Antworten.

Die Demo hat eine Möglichkeit gezeigt. Sie hat keinen verlässlichen Betrieb bewiesen.

Ein Pilot ist ein begrenzter Einsatz unter echten Bedingungen. Dabei trifft das geprüfte KI-System auf einen Prozess, der sich ständig verändert. Nutzer formulieren anders, Daten altern und Anbieter aktualisieren ihre Dienste. Selbst ein unverändertes Modell kann dadurch schlechtere Ergebnisse liefern.

Darum führt der Weg in den Betrieb über mehrere Stufen:

1. Im Offline-Test bearbeitet das System gespeicherte Fälle ohne Kontakt zu echten Kunden.
2. Im Schattenbetrieb verarbeitet es aktuelle Fälle, aber seine Ausgabe bleibt ohne Wirkung.
3. In der Assistenz sehen Beschäftigte Vorschläge und entscheiden selbst über die Verwendung.
4. Eine begrenzte Freigabe öffnet den Ablauf für eine kleine Gruppe oder wenige Fälle.
5. Der breite Betrieb folgt erst nach stabilen Ergebnissen und wirksamen Kontrollen.

Eine begrenzte Freigabe für einen kleinen Anteil heißt in der Softwareentwicklung Canary Release. Vor jeder Stufe stehen Abbruchkriterien. Das können mehr als 3 Prozent fachlich schwere Fehler, unerwartete Datenübertragungen oder verdoppelte Kosten sein. Die Zahlen sind keine allgemeinen Grenzwerte. Das Team legt sie passend zum eigenen Prozess fest.

Kapitel 16 hat gezeigt, wie du mit einem Vergleichswert, Testfällen und Freigabebedingungen prüfst. Hier beginnt die nächste Aufgabe: Du musst denselben Qualitätsanspruch über Änderungen, echte Fälle und Vorfälle hinweg erhalten.

Verantwortliche, Nutzer, Eingaben, Ausgaben und Rückfallweg festlegen

Bleiben wir beim Supportteam. Der Satz „Wir nutzen KI für Support“ ist zu ungenau. Ein brauchbarer Betriebsauftrag klingt so:

„Das System erstellt für geschulte Beschäftigte einen Antwortentwurf aus der Kundenanfrage und freigegebenen Handbuchseiten. Ein Mensch prüft Fakten, Ton und erlaubte Zusagen. Bei einem Ausfall arbeitet das Team im bisherigen Ticketsystem weiter.“

Dieser Satz nennt Nutzer, Eingaben, Ausgabe, Prüfung und Rückfallweg. Ein Rückfallweg ist der frühere oder vereinfachte Ablauf, der bei einem Fehler übernimmt. Er muss nicht schön sein. Er muss funktionieren und genug Kapazität haben.

Jede produktive Anwendung braucht außerdem benannte Verantwortung:

• Der fachliche Verantwortliche legt Zweck, erlaubte Fälle und akzeptable Ergebnisse fest.
• Der technische Verantwortliche betreibt die Anwendung und kennt ihre Abhängigkeiten.
• Die Nutzer wissen, was sie prüfen, ablehnen und eskalieren müssen.
• Eine Freigabestelle darf starten, stoppen oder zum Rückfallweg wechseln.

In einem kleinen Unternehmen kann eine Person mehrere Rollen übernehmen. Die Entscheidungen bleiben trotzdem sichtbar. „Das KI-Team kümmert sich“ reicht nicht, wenn bei einem Fehler niemand abschalten darf.

Das Modell ist keine juristische Person. Es ist also kein rechtlich selbstständiger Träger von Rechten und Pflichten. Es kann die rechtliche oder organisatorische Verantwortung des Unternehmens nicht übernehmen. Diese bleibt bei den benannten Menschen und Stellen.

Schreibe auch die Grenzen auf. Welche Daten dürfen hinein? Welche Ausgabe darf das System erzeugen? Welche Handlung bleibt verboten? Wann muss es nachfragen oder an einen Menschen übergeben? Erst wenn diese Punkte geklärt sind, wird aus einem Konto bei einem Anbieter ein gestalteter Arbeitsprozess.

Kapitel 17 erklärt die Mechanik von Werkzeugrechten, Freigaben und Prompt Injection ausführlich. Für den Betrieb genügt hier die Konsequenz: Die festgelegten Grenzen müssen in normaler Software, Rollen und Abläufen durchgesetzt werden. Ein Satz im Prompt ist keine Betriebsregel.

Modell, Prompts, Retrieval, Werkzeuge und Prüfungen versionieren

Am Dienstag ändert das Team zwei Sätze im System-Prompt. Am Mittwoch aktualisiert der Anbieter sein Modell. Am Donnerstag kommen 300 neue Handbuchseiten in die Suche. Welche Fassung hat die problematische Antwort am Freitag erzeugt?

Das kannst du nur beantworten, wenn jede Freigabe ein Versionsprotokoll hat. Es hält die Bestandteile fest, die das Ergebnis beeinflussen:

• Anbieter, Modellversion und Einstellungen
• System-Prompt, Vorlagen und feste Beispiele
• Retrieval, also die automatische Suche nach passenden Quellen, samt Dokumentbestand und Suchindex
• Reranker, der gefundene Quellen noch einmal sortiert
• Werkzeuge, ihre Beschreibungen und Berechtigungen
• Anwendungscode, Laufzeit und wichtige Bibliotheken
• Testfälle, Bewertungsregeln und Freigabegrenzen

Eine Regression ist die Verschlechterung einer Eigenschaft, die vorher funktioniert hat. Sie kann aus jedem dieser Teile entstehen. Deshalb löst eine relevante Änderung die passenden Prüfungen aus Kapitel 16 erneut aus. Das Team vergleicht die neue Fassung mit der freigegebenen Fassung und dokumentiert die Entscheidung.

Ein Anbieter stellt nicht immer eine feste Modellversion bereit. Dann prüfst du den laufenden Dienst regelmäßig und besonders nach angekündigten Änderungen. Kannst du eine Version festhalten, bleibt sie trotzdem nicht für immer unangetastet. Sicherheitsupdates, auslaufende Schnittstellen und neue Anforderungen machen eine erneute Freigabe nötig.

Versionierung bedeutet also mehr als einen Modellnamen in eine Tabelle zu schreiben. Sie verbindet eine beobachtete Ausgabe mit dem vollständigen System, das sie erzeugt hat.

Qualität, Kosten, Antwortzeit und betriebliche Drift überwachen

Vor dem Start kennt das Team seine Testfälle. Nach dem Start kommen Fälle hinzu, an die vorher niemand gedacht hat. Fortlaufende Überwachung heißt häufig Monitoring. Sie zeigt, ob der reale Betrieb noch zu den Annahmen der Freigabe passt.

Vier Gruppen von Signalen gehören zusammen:

• Qualität umfasst akzeptierte Ergebnisse, menschliche Korrekturen, Beschwerden, Eskalationen und geprüfte Stichproben.
• Kosten umfassen Modellaufrufe, Werkzeuge, Speicher und menschliche Nacharbeit pro akzeptablem Ergebnis.
• Antwortzeit umfasst typische und langsame Fälle. Das 95. Perzentil ist der Wert, den 95 Prozent der gemessenen Aufrufe nicht überschreiten.
• Betriebssignale umfassen Ausfälle, Abbrüche, Werkzeugfehler, blockierte Eingaben und ungewöhnliche Zugriffe.

Drift ist eine Verschiebung im laufenden Betrieb. Vielleicht schreiben Kunden plötzlich in einer neuen Sprache. Vielleicht ändern sich Produkte, Dokumente oder das Verhalten eines Dienstes. Dann bilden frühere Testergebnisse den aktuellen Prozess schlechter ab. Monitoring muss deshalb sowohl veränderte Eingaben als auch veränderte Systemleistung erfassen.

Ein Messwert braucht eine Handlung. Bei steigenden Korrekturen prüft das Team eine Stichprobe. Bei hohen Kosten untersucht es lange Eingaben und Werkzeugschleifen. Bei einem schweren Fehler stoppt es die betroffene Funktion. Ein Dashboard ohne Zuständigkeit beobachtet den Schaden nur besonders ordentlich.

Protokolle können Prompts, Antworten, Werkzeugargumente und Kundendaten enthalten. Speichere deshalb nicht vorsorglich alles. Welche Daten nötig sind, wer sie sehen darf und wann sie verschwinden, gehört zum Betriebsentwurf. Den Löschweg betrachten wir gleich noch genau.

Abbildung 13: Tests, begrenzte Freigabe und Monitoring bilden einen Kreislauf. Änderungen und neue Fehler fließen als Fälle in die nächste Prüfung zurück.

Vorfälle, Rollback und Anbieteränderungen behandeln

Freitag um 14 Uhr häufen sich falsche Supportzusagen. Das Team weiß noch nicht, ob ein neuer Prompt, eine veraltete Quelle oder der Anbieter dahintersteckt. Es weiß aber, was als Nächstes geschieht.

Ein Vorfall ist ein Ereignis, das den erlaubten Betrieb verletzt oder ernsthaft bedroht. Der vorbereitete Ablauf enthält mindestens diese Schritte:

1. Eine benannte Person bewertet Schwere und betroffene Prozesse.
2. Das Team begrenzt die Wirkung und schaltet bei Bedarf die Funktion ab.
3. Der Rückfallweg übernimmt neue Fälle.
4. Geschützte Belege sichern Versionen, Eingaben, Ausgaben und ausgeführte Handlungen.
5. Zuständige Personen prüfen Kommunikation und gesetzliche Meldepflichten.
6. Ursache, Korrektur und ein neuer Testfall werden dokumentiert.

Rollback bedeutet die Rückkehr zu einer früher geprüften Version oder zum früheren Ablauf. Bei einem Antwortentwurf ist das oft einfach. Eine versendete E-Mail kommt dadurch nicht zurück. Das gilt erst recht für Zahlungen, veröffentlichte Daten oder Löschungen. Solche Handlungen brauchen vorher Grenzen, Bestätigung, Verzögerung oder eine eigene Möglichkeit zur Rücknahme.

Auch eine Anbieteränderung läuft durch diesen Prozess. Neue Modellversionen, geänderte Limits, auslaufende Schnittstellen und andere Speicherregeln sind keine gewöhnliche Randnotiz. Sie können Qualität, Kosten oder Rechtmäßigkeit verändern. Der Verantwortliche prüft Ankündigungen, ordnet die betroffenen Anwendungen zu und entscheidet über einen neuen Test oder einen Wechsel.

Bei einer Verletzung des Schutzes personenbezogener Daten gelten in der Europäischen Union besondere Pflichten. Artikel 33 der Datenschutz-Grundverordnung verlangt eine Meldung an die zuständige Aufsicht ohne unangemessene Verzögerung und möglichst binnen 72 Stunden nach Kenntnis. Das gilt nicht, wenn voraussichtlich kein Risiko für Rechte und Freiheiten natürlicher Personen entsteht. Ob ein Vorfall diese Schwelle erreicht, muss die zuständige Datenschutzfunktion anhand des konkreten Falls prüfen.

Das NIST empfiehlt in seinem AI Risk Management Framework und in SP 800-61 Revision 3 vorbereitete Abläufe für Erkennung, Reaktion und Wiederherstellung. Das sind US-amerikanische Rahmenwerke und Empfehlungen, kein in Deutschland bindendes Gesetz.

Datenschutz, Zugriffe, Aufbewahrung und Schatten-KI

Nehmen wir an, eine Kundin verlangt die Löschung ihrer Daten. Das Ticketsystem entfernt den Vorgang. Der Text steckt aber noch im Suchindex, in einem Eval-Fall, in Protokollen und beim externen KI-Anbieter. Dann war die Schaltfläche kein vollständiger Löschweg.

Vor dem Betrieb brauchst du ein Verzeichnis der gespeicherten Daten. Dazu können Eingaben, Ausgaben, abgerufene Dokumente, Werkzeugargumente, Protokolle, Suchindizes, Eval-Fälle und Sicherungskopien gehören. Für jede Kategorie stehen Zweck, Zugriff, Speicherort, Frist und verantwortliche Stelle fest.

Ein Auftragsverarbeiter ist ein Dienstleister, der personenbezogene Daten im Auftrag des verantwortlichen Unternehmens verarbeitet. Beauftragt er dafür weitere Dienste, sind das Unterauftragnehmer.

Ein Löschweg beginnt mit einem Auslöser. Das kann eine abgelaufene Frist, das Vertragsende oder ein berechtigtes Löschverlangen sein. Danach läuft ein prüfbarer Prozess:

1. Die zuständige Stelle prüft, welche Daten betroffen sind und ob eine gesetzliche Aufbewahrungspflicht oder eine andere Ausnahme greift.
2. Eine stabile Kennung findet den Datensatz in Hauptsystem, Suchindex, Analysebestand und abgeleiteten Eval-Fällen.
3. Das System löscht oder anonymisiert die zulässigen Bestände und sperrt sie bis zum Abschluss gegen weitere Nutzung.
4. Auftragsverarbeiter und Unterauftragnehmer erhalten den passenden Löschauftrag.
5. Sicherungskopien laufen nach ihrer festgelegten Frist aus. Nach einer Wiederherstellung wird der Löschauftrag erneut angewendet.
6. Eine Kontrolle bestätigt den Abschluss, ohne den gelöschten Inhalt einfach in einem neuen Protokoll zu verewigen.

Teste diesen Weg vor der Freigabe mit einem künstlichen Datensatz. Prüfe auch das Vertragsende mit dem Anbieter. Ein Löschversprechen hilft wenig, wenn niemand weiß, wie Kopien, Indizes und Backups behandelt werden.

In der Europäischen Union gilt die Datenschutz-Grundverordnung seit dem 25. Mai 2018. Artikel 5 verlangt Datenminimierung und Speicherbegrenzung. Artikel 17 gibt unter bestimmten Voraussetzungen ein Recht auf Löschung und nennt Ausnahmen. Nach Artikel 28 Absatz 3 Buchstabe g muss ein Auftragsverarbeiter nach Ende der Leistung personenbezogene Daten nach Wahl des Verantwortlichen löschen oder zurückgeben und vorhandene Kopien löschen, soweit keine gesetzliche Speicherung verlangt ist. Das sind bindende Regeln für personenbezogene Daten, keine allgemeine Löschpflicht für jede beliebige Unternehmensdatei.

NIST SP 800-88 Revision 2 vom September 2025 beschreibt die sichere Bereinigung von Speichermedien und logischem Speicher. Diese technische US-Empfehlung kann beim Verfahren helfen. Sie ersetzt weder die europäische Rechtsprüfung noch die vertragliche Durchsetzung beim Anbieter.

Zugriffe folgen dem nötigen Arbeitsumfang. Wer Entwürfe liest, braucht nicht automatisch Zugriff auf alle Rohdaten. Wer eine Stichprobe prüft, braucht keine dauerhafte Exportmöglichkeit. Die technische Umsetzung von geringsten Rechten und der Schutz vor Prompt Injection gehören zu Kapitel 17.

Schatten-KI bezeichnet nicht freigegebene KI-Dienste, die Beschäftigte für ihre Arbeit nutzen. Ein Verbot kann für sensible Daten nötig sein. Gleichzeitig braucht das Team einen brauchbaren erlaubten Weg, klare Datenklassen und eine einfache Stelle für neue Wünsche. Sonst bleibt das Arbeitsproblem bestehen und wechselt nur den Browser-Tab.

Menschliche Prüfung ist ein gestalteter Prozess, kein Hinweis

Ein Prüfer bekommt 90 Antwortentwürfe pro Stunde. Er sieht weder die Kundendokumente noch die verwendeten Handbuchseiten. Unter jedem Entwurf steht nur: „Bitte prüfen.“ Diese menschliche Freigabe ist kaum mehr als Dekoration.

Eine echte Prüfung beantwortet konkrete Fragen:

• Was genau muss die Person prüfen?
• Welche Originaldaten und Quellen sieht sie dabei?
• Welche Fehler kann sie mit ihrer Fachkenntnis erkennen?
• Wie viel Zeit erhält sie pro Fall?
• Darf sie ablehnen, korrigieren und den Ablauf stoppen?
• Wohin gibt sie unklare oder schwere Fälle weiter?

Die Oberfläche sollte Behauptungen neben den passenden Quellen zeigen. Sie sollte Unsicherheit nicht hinter einer flüssigen Formulierung verstecken. Bei einer Zahlung sieht der Prüfer Betrag, Empfänger, Grundlage und mögliche Duplikate. Bei einer Supportantwort sieht er die Anfrage, die verwendete Produktinformation und unerlaubte Zusagen.

Nicht jede Ausgabe braucht dieselbe Prüfung. Ein interner Entwurf kann durch Stichproben kontrolliert werden. Eine schwer umkehrbare Handlung braucht eine Prüfung vor der Wirkung. Die Einordnung nach Folgen, Erkennbarkeit und Umkehrbarkeit stammt aus den Kapiteln 15 und 16. Kapitel 17 erklärt zusätzlich die technische Freigabe bei Agenten.

Korrekturen und Ablehnungen sind Betriebsdaten. Sie zeigen neue Fehlergruppen und gehören regelmäßig in Monitoring und Testsammlung. Die Organisation darf menschliche Prüfung deshalb nicht als letzten Satz einer Richtlinie behandeln. Sie muss Zeit, Ansicht, Befugnis und Eskalation entwerfen.

Veränderung gemeinsam mit betroffenen Beschäftigten gestalten

Ein Supportassistent verändert mehr als die Schreibgeschwindigkeit. Vielleicht werden einfache Fälle schneller, während schwierige Fälle beim Team bleiben. Dann steigt die Belastung, obwohl die Zahl bearbeiteter Tickets gut aussieht. Eine reine Zeitmessung würde diese Veränderung übersehen.

Beziehe betroffene Beschäftigte deshalb vor dem Pilot ein. Sie kennen Ausnahmen, stilles Zusatzwissen und die Stellen, an denen der heutige Prozess bereits hakt. Gemeinsam lassen sich Zweck, erlaubte Nutzung, Qualitätsmaß und Meldeweg genauer festlegen.

Beschäftigte brauchen Antworten auf praktische Fragen: Welche Aufgaben ändern sich? Welche Entscheidungen bleiben bei ihnen? Welche Daten dürfen sie verwenden? Wie fließen Korrekturen in Leistungsbewertungen ein? Was geschieht mit Rollen, die einen großen Teil ihrer bisherigen Arbeit verlieren?

Schulungen arbeiten am besten mit echten Aufgaben aus dem Betrieb. Ein allgemeiner Vortrag kann Begriffe erklären. Sichere Gewohnheiten entstehen beim Prüfen unvollständiger Eingaben, beim Melden eines Fehlers und beim Wechsel auf den Rückfallweg. Das Team sollte den manuellen Ablauf gelegentlich üben. Sonst existiert er nur auf Papier.

In Deutschland gelten zusätzlich Beteiligungsrechte. Nach § 90 Betriebsverfassungsgesetz muss der Arbeitgeber einen vorhandenen Betriebsrat rechtzeitig über geplante Arbeitsverfahren und Arbeitsabläufe einschließlich des Einsatzes von KI unterrichten und die Auswirkungen beraten. § 87 Absatz 1 Nummer 6 gibt dem Betriebsrat ein Mitbestimmungsrecht bei technischen Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung von Beschäftigten zu überwachen. Ob diese Voraussetzungen erfüllt sind, hängt vom konkreten Einsatz ab.

Veränderung gelingt nicht durch eine freundlich formulierte Ankündigung. Sie braucht Mitsprache, Zeit zum Lernen, einen sicheren Meldeweg und eine ehrliche Betrachtung der neuen Arbeitslast.

Governance richtet sich nach den möglichen Folgen

Eine interne Hilfe formuliert drei Überschriften für einen Entwurf. Ein anderes System sortiert Bewerbungen oder steuert eine Maschine. Beide verwenden KI. Sie brauchen trotzdem nicht dieselben Kontrollen.

Governance bezeichnet die Regeln, Rollen und Kontrollen, mit denen eine Organisation ihre KI-Systeme steuert. Sie beginnt mit einem Verzeichnis der produktiven und geplanten Anwendungen. Für jeden Eintrag stehen dort Zweck, Nutzer, Daten, Anbieter, Verantwortliche, mögliche Folgen, Freigabestatus, letzte Prüfung, Vorfallweg und Ausstiegsplan.

Die Kontrollen folgen den Folgen eines Fehlers:

• Bei geringer Wirkung reichen oft ein klarer Zweck, erlaubte Daten und Stichproben.
• Bei spürbaren Folgen kommen feste Qualitätsgrenzen, geschulte Prüfer und engere Änderungen hinzu.
• Bei hohen oder schwer umkehrbaren Folgen braucht der Prozess unabhängige Freigaben, starke Zugriffsgrenzen, häufigere Prüfung und einen geübten Notfallweg.

Diese Einteilung ist eine praktische Empfehlung. Sie ist keine rechtliche Risikoklasse.

Für die rechtliche Einordnung gilt in diesem Abschnitt der Stand vom 6. August 2026 und die Zuständigkeit der Europäischen Union beziehungsweise Deutschlands. Die Datenschutz-Grundverordnung ist bindendes EU-Recht für die Verarbeitung personenbezogener Daten. Das Betriebsverfassungsgesetz ist bindendes deutsches Recht. Beide können unabhängig davon gelten, in welche Klasse ein System nach der KI-Verordnung fällt.

Die europäische KI-Verordnung (EU) 2024/1689 trat am 1. August 2024 in Kraft. Die Änderungsverordnung (EU) 2026/1744 trat am 27. Juli 2026 in Kraft. Damit ist die aktuelle Fassung in allen EU-Mitgliedstaaten bindendes Recht. Artikel 4 verpflichtet Anbieter und Betreiber von KI-Systemen zu Maßnahmen, welche die Entwicklung von KI-Kompetenz bei den beteiligten Personen unterstützen. Welche Maßnahme passt, hängt unter anderem von Wissen, Erfahrung, Ausbildung und Nutzungskontext ab.

Ein Hochrisiko-System ist ein System, das nach Artikel 6 anhand von Zweck und Einsatzbereich als solches eingeordnet wird. Die besonderen Pflichten aus den Abschnitten 1 bis 3 des Kapitels III gelten nach der Änderung zu unterschiedlichen späteren Terminen. Für Systeme nach Artikel 6 Absatz 2 und Anhang III ist es der 2. Dezember 2027. Für Systeme nach Artikel 6 Absatz 1 und Anhang I ist es der 2. August 2028. Am 6. August 2026 sind diese Pflichten also noch nicht allgemein anwendbar. Andere Teile der Verordnung gelten bereits. Deshalb ist weder „jede KI ist Hochrisiko“ noch „das Gesetz kommt irgendwann später“ eine brauchbare Einordnung.

Standards und Rahmenwerke sind eine andere Kategorie. ISO/IEC 42001:2023 ist eine im Dezember 2023 veröffentlichte internationale Norm für ein KI-Managementsystem. Das NIST AI Risk Management Framework 1.0 vom 26. Januar 2023 ist ein freiwilliges, branchenübergreifendes US-Rahmenwerk. Beide helfen bei Rollen, Risiken, Messung und Verbesserung. Sie sind kein EU-Gesetz und belegen allein keine Rechtmäßigkeit eines konkreten Einsatzes.

Inventar, abgestufte Freigaben, Löschtests und Ausstiegsübungen in diesem Kapitel sind praktische Empfehlungen. Sie übersetzen Verantwortung in Arbeit. Die rechtliche Prüfung des konkreten Systems ersetzen sie nicht.

Anbieterabhängigkeit und Ausstiegspläne

Der Supportassistent funktioniert gut. Dann kündigt der Anbieter die verwendete Modellversion mit 60 Tagen Frist ab. Ein Wechsel ist möglich, aber die Prompts passen nicht, der neue Dienst nutzt andere Formate und alte Protokolle lassen sich kaum exportieren.

Anbieterabhängigkeit entsteht nicht nur durch einen Vertrag. Sie steckt auch in Prompts, Werkzeugen, Datenformaten, Sicherheitsfunktionen und im Wissen des Teams. Vollständige Austauschbarkeit wäre teuer und oft unnötig. Ein Ausstiegsplan begrenzt die Abhängigkeit passend zu ihrer Wirkung.

Der Plan hält fest:

• Welche Ereignisse einen Wechsel oder Rückfall auslösen
• Welche Daten, Prompts, Tests und Protokolle exportiert werden können
• Wie Rückgabe und Löschung beim Anbieter nachgewiesen werden
• Welche interne Schnittstelle Modellaufrufe und Werkzeugzugriffe bündelt
• Welche geprüfte Alternative für kritische Aufgaben bekannt ist
• Wie lange ein Wechsel dauert und welcher Betrieb in dieser Zeit möglich bleibt

Verträge sollten Änderungen, Kündigungsfristen, Unterauftragnehmer, Datenverwendung, Auskunft bei Vorfällen sowie Rückgabe und Löschung abdecken. Die technische Prüfung gehört trotzdem dazu. Ein Exportversprechen nützt wenig, wenn das Format im eigenen Prozess nicht lesbar ist.

Teste den Ausstieg mit einer kleinen Übung. Exportiere einen ungefährlichen Bestand, spiele wichtige Tests gegen eine Alternative und schalte kurz auf den manuellen Ablauf. So werden fehlende Rechte und unbekannte Abhängigkeiten sichtbar, solange noch Zeit bleibt.

Eine zweite produktive Umsetzung ist nicht für jede Schreibunterstützung sinnvoll. Sie lohnt sich dort, wo ein Ausfall oder Vertragswechsel einen wichtigen Prozess ernsthaft gefährdet. Auch hier folgt der Aufwand den Folgen.

Produktion ist Betriebsverantwortung

Der Pilot endet mit einer Entscheidung. Der Betrieb beginnt mit wiederkehrender Arbeit. Jemand pflegt Quellen, prüft Änderungen, beantwortet Vorfälle und entfernt Daten. Dafür braucht es Zeit, Budget und klare Befugnisse.

Vor einer produktiven Freigabe sollte jede Anwendung diese Punkte bestehen:

1. Anwendungsfall, Nutzer, Eingaben, Ausgaben und heutiger Vergleichswert sind dokumentiert.
2. Datenfluss, Verträge, Zugriffe, Aufbewahrung und Löschweg sind geprüft.
3. Die Eval aus Kapitel 16 deckt typische Fälle, Grenzfälle und bekannte Angriffe ab.
4. Qualität, schwere Fehler, Kosten, Antwortzeit und menschliche Nacharbeit werden gemessen.
5. Die Einführung erfolgt stufenweise und hat vorher festgelegte Abbruchkriterien.
6. Monitoring und geschützte Protokolle sind eingerichtet.
7. Für Vorfälle gibt es Verantwortliche, Abschaltung, Rollback und Rückfallweg.
8. Änderungen an Modell, Prompts, Retrieval, Werkzeugen oder Prüfungen lösen passende Regressionstests aus.
9. Betroffene Beschäftigte kennen Zweck, Grenzen, Prüfung und Meldeweg.
10. Anbieterabhängigkeit, Ausstieg und regelmäßige erneute Bewertung sind geplant.

Nach der Freigabe bleibt diese Liste lebendig. Der Verantwortliche legt einen Prüfrhythmus fest. Ein wichtiger Prozess kann monatlich betrachtet werden. Eine kleine interne Hilfe vielleicht nur bei Änderungen oder nach einem Vorfall. Die Frequenz folgt wieder den möglichen Folgen und der Änderungsgeschwindigkeit.

Produktionsverantwortung heißt auch, eine Anwendung zu beenden. Vielleicht bleibt der Nutzen unter dem früheren Vergleichswert. Vielleicht steigt der Prüfaufwand. Vielleicht ändert sich der Prozess so stark, dass die ursprüngliche Aufgabe verschwindet. Abschalten ist dann kein Scheitern, sondern eine Betriebsentscheidung.

Ein Anbieter kennt deinen vollständigen Prozess nicht. Die Organisation entscheidet, welche Wirkung erlaubt ist, welche Nachweise genügen und wer bei einem Fehler handelt.

Eine gute Demo beantwortet die Frage, ob etwas grundsätzlich funktionieren kann. Verlässlicher Betrieb beantwortet jeden Tag eine andere Frage: Funktioniert unser vollständiger Prozess unter den heutigen Bedingungen noch gut genug?

Vom Betrieb zur physischen Infrastruktur

Nimm eine produktive oder geplante KI-Anwendung in deiner Firma. Beantworte dazu diese Fragen:

1. Wer darf den Betrieb freigeben, stoppen und auf welchen Rückfallweg wechseln?
2. Welche Versionen von Modell, Prompts, Retrieval, Werkzeugen und Prüfungen gehören zusammen?
3. Welche Signale zeigen Qualität, Kosten, Antwortzeit und Drift?
4. Wie läuft ein Vorfall von der Erkennung bis zum neuen Testfall?
5. Wo liegen gespeicherte Daten, und wie erreicht eine Löschung Hauptsystem, Indizes, Anbieter und Backups?
6. Welche menschliche Prüfung hat genug Information, Zeit und Befugnis?
7. Welche Kontrollen folgen den Folgen, und welche stammen wirklich aus bindendem Recht?
8. Wie funktioniert der Ausstieg, wenn der Anbieter morgen eine wichtige Version abkündigt?

Damit endet Teil III. Wir haben aus Modell, Kontext, Werkzeugen und Prüfungen einen verantworteten Unternehmensprozess gemacht. Dieser Prozess wirkt wie Software, hängt aber an sehr materiellen Dingen: Chips, Rechenzentren, Strom, Kühlung und Netzen.

Kapitel 19 beginnt Teil IV und betrachtet diese physische Infrastruktur. Dort geht es um Compute, Energie und die Maschine hinter jeder scheinbar schwerelosen Antwort.