Die Pre-Deployment-Checkliste: Guardrails, die Fehler früh erkennen

# Die Pre-Deployment-Checkliste: Guardrails, die Fehler früh erkennen

Ein Vision-System in einem europäischen Presswerk der Automobilindustrie hat einmal jeden Offline-Accuracy-Test bestanden, 99,2 % Erkennung von Oberflächendefekten, und dann eine Charge Mikrorisse in der Linie übersehen, weil die Beleuchtungsanlage im Werk mit einer anderen Farbtemperatur arbeitete als im Labor. Die fehlerhaften Bleche gingen drei Schichten lang in den Versand, bis ein Mitarbeiter an der Linie das Muster mit dem Auge erkannte. An der Mathematik des Modells war nichts falsch. Falsch war alles daran, was vor dem Go-live geprüft wurde.

Das ist die zentrale Lehre dieses Moduls: Die meisten KI-Fehler in der Produktion sind keine Algorithmus-Fehler, sondern Governance-Fehler. Eine Pre-Deployment-Checkliste ist der Weg, sie zu finden, bevor sie die Linie erreichen.

Warum Checklisten und nicht nur Modellmetriken

Die Accuracy eines Modells auf einem Validierungsdatensatz sagt Ihnen, wie das System auf Daten abgeschnitten hat, die es schon kannte. Sie sagt nichts über:

• Drift zwischen Laborbedingungen und Bedingungen im Shopfloor (Beleuchtung, Vibration, Sensorkalibrierung).
• Was passiert, wenn das Modell zuversichtlich und falsch ist.
• Wer es überstimmen kann, und wie schnell.
• Was das Werk tut, wenn das System komplett ausfällt.

Die Regulierung bewegt sich in dieselbe Richtung. Der EU AI Act (in Kraft seit August 2024, mit gestuften Pflichten bis 2026-2027) klassifiziert viele industrielle KI-Anwendungen, etwa Sicherheitsbauteile in Maschinen, als „hochriskant“ und verlangt dokumentiertes Risikomanagement, menschliche Aufsicht und Logging vor dem Deployment. In den USA gibt es kein einheitliches Bundesgesetz zu KI, aber die OSHA (Occupational Safety and Health Administration) hält Arbeitgeber weiterhin für einen „recognized hazard“ haftbar, wenn ein KI-gesteuerter Prozess einen Mitarbeiter verletzt, und das AI Risk Management Framework des NIST (kostenlos, vom NIST) wird zum De-facto-Auditstandard, der in Versicherungs- und Beschaffungsverträgen zitiert wird.

Die vierteilige Checkliste

1. Datenvalidierung: sind die Inputs an Tag eins vertrauenswürdig?

Bevor ein Modell die Produktion berührt, bestätigen Sie:

• Herkunft von Sensordaten und Labels: Woher kamen die Trainingsdaten, und passen sie zur Anlagengeneration, zum Kamerawinkel und zum Umfeld der Ziellinie?
• Verteilungsprüfung: Lassen Sie den eingehenden Produktionsdatenstrom durch einen statistischen Vergleich gegen die Trainingsdaten laufen (ein einfacher Population Stability Index, PSI, genügt). Ein PSI über etwa 0,25 gilt in der Praxis als Daumenregel für „materielle Drift, vor dem Vertrauen in Vorhersagen untersuchen“.
• Abdeckung von Edge Cases: Enthält der Datensatz seltene, aber reale Bedingungen, Beleuchtung in der Nachtschicht, saisonale Luftfeuchtigkeit, eine Rohmaterialcharge eines neuen Lieferanten?

Ein einfacher Drift-Check in Python, wie ihn ein Datenteam im Werk wöchentlich laufen lassen kann:

import numpy as np

def psi(expected, actual, bins=10):
    e_perc, edges = np.histogram(expected, bins=bins)
    a_perc, _ = np.histogram(actual, bins=edges)
    e_perc = e_perc / len(expected) + 1e-6
    a_perc = a_perc / len(actual) + 1e-6
    return np.sum((a_perc - e_perc) * np.log(a_perc / e_perc))

score = psi(training_sensor_values, live_sensor_values)
print(f"PSI: {score:.3f}")  # >0.25 löst eine Untersuchung aus

2. Human-in-the-Loop-Overrides: wer kann die Maschine stoppen, und wie schnell?

„Human-in-the-Loop“ (HITL) bedeutet, dass eine Person die Entscheidung der KI vor oder während der Ausführung prüft oder per Veto stoppen kann, und nicht erst im Nachhinein.

Checkliste:

• Eine benannte Override-Instanz in jeder Schicht, nicht nur zu Bürozeiten.
• Zielwert für Override-Latenz: Wie viele Sekunden von „Operator sieht ein Problem“ bis „System stoppt“? Siemens und andere Automatisierungsanbieter legen sicherheitskritische Override-Schleifen typischerweise auf Reaktionszeiten unter einer Sekunde aus; wenn Ihre KI-Schicht dort Verzögerung hinzufügt, braucht sie ihr eigenes Budget.
• Keine stillen Overrides: Jeder Override sollte mit einem Grund-Code geloggt werden und in Retraining und Audit-Trails zurückfließen (diese Logging-Pflicht ist in Artikel 12 des EU AI Act zur Aufzeichnung bei Hochrisikosystemen ausdrücklich geregelt).

3. Fallback-to-Manual: was passiert, wenn die KI ausfällt?

Jeder Rollout im Werk braucht einen dokumentierten und geübten manuellen Fallback. Fragen Sie:

• Kann die Linie ohne die KI mit reduzierter Geschwindigkeit oder im manuellen Prüfmodus laufen, und wie lange, bevor sie stehen muss?
• Gibt es einen geschulten menschlichen Backup für die konkrete Aufgabe (Defektsortierung, Predictive-Maintenance-Alarme, Bahnplanung von Robotern)?
• Wurde der Fallback tatsächlich getestet und nicht nur aufgeschrieben? Eine Fallback-Prozedur, die niemand geübt hat, ist ein Guardrail auf Papier.

Ein nützlicher Benchmark aus der Risikopraxis der Lean Manufacturing: Behandeln Sie KI-Systemausfälle wie jede andere kritische Ausfallart in Ihrer FMEA (Failure Mode and Effects Analysis), mit einem definierten Zielwert für Mean Time to Fallback (MTTF), üblicherweise unter 5 Minuten für Inline-Qualitätssysteme in Automobil- oder Elektroniklinien mit hohem Durchsatz (das ist eine praktische Schätzung, keine allgemeingültige regulatorische Größe).

4. Performance-Schwellen: „gut genug“ vor dem Launch definieren, nicht danach

Legen Sie numerische Schwellen vorab fest und schreiben Sie sie in die Deployment-Freigabe:

• Minimale Precision und Recall für die konkrete Defektklasse, nicht nur die Gesamt-Accuracy (ein Modell kann 99 % „accurate“ sein und dabei das 1 % der Defekte übersehen, das am meisten zählt).
• Obergrenze für False Negatives: Bei sicherheitsrelevanter Erkennung zählen False Negatives (übersehene Defekte, übersehene Gefahren) meist mehr als False Positives. Setzen Sie eine harte Obergrenze und einen Rollback-Trigger, wenn sie im Produktionsmonitoring überschritten wird.
• Confidence-basiertes Routing: Vorhersagen unter einem festgelegten Confidence-Score (zum Beispiel unter 85 %, pro Use Case kalibriert) gehen automatisch in die menschliche Prüfung statt in autonome Aktion.

Zusammengesetzt: ein Rollout-Gate, kein Launch-Datum

Führende Hersteller (Siemens, Bosch und die Produktionssystem-Teams von Toyota haben Elemente dieses Ansatzes in verschiedenen technischen und Nachhaltigkeitsberichten veröffentlicht) behandeln KI-Deployments zunehmend wie ein Prozess-FMEA-Gate: Das System geht nicht an einem Kalenderdatum live, sondern wenn es eine Checkliste passiert, und zwar sequenziell:

1. Datenvalidierung bestanden und dokumentiert.

2. HITL-Override mit echten Operatoren getestet, nicht nur mit Ingenieuren.

3. Fallback-to-Manual unter einem simulierten Ausfall geübt.

4. Performance-Schwellen gesetzt, überwacht und an einen automatischen Rollback-Trigger gekoppelt.

Diese Reihenfolge ist wichtig, weil das Überspringen von Schritt 2 oder 3 der häufigste Fehler in der Praxis ist. Teams pilotieren Modelle ausführlich (Schritt 1 und Schritt 4), behandeln das menschliche Backup aber als Nebensache und stellen dann bei einem echten Ausfall fest, dass sich niemand an die manuelle Prozedur erinnert.

🎬 [VIDEO: "Human-in-the-Loop AI: Why It Matters in Manufacturing" - youtube.com - nach aktuellen Konferenzvorträgen zu Manufacturing-KI suchen, die HITL-Design-Patterns und Override-Architektur an Produktionslinien behandeln]

Eine Anmerkung zur Governance-Verantwortung

Nichts davon funktioniert ohne benannten Owner. Nach dem EU AI Act müssen Anbieter und Betreiber von Hochrisiko-KI-Systemen Verantwortliche für Risikomanagement und Post-Market-Monitoring benennen. Auch außerhalb der EU berichten Werke von besseren Ergebnissen, wenn ein namentlich benannter Qualitäts- oder Sicherheitsingenieur, nicht ein Lieferant, nicht ein Data-Science-Team allein, die Pre-Deployment-Checkliste verantwortet und die Befugnis hat, einen Launch zu verschieben.

Wichtigste Erkenntnisse

• Metriken zur Modell-Accuracy sind notwendig, aber nicht ausreichend; die meisten KI-Fehler in der Produktion entstehen aus Abweichungen im Umfeld, unklarer Override-Zuständigkeit oder ungetesteten Fallback-Prozeduren, nicht aus schlechten Algorithmen.
• Arbeiten Sie vor jedem Produktions-Deployment eine vierteilige Checkliste ab: Datenvalidierung (inklusive Drift-Checks wie PSI), Human-in-the-Loop-Override-Design mit Latenzzielen, geübte Fallback-to-Manual-Prozeduren und vorab vereinbarte Performance-Schwellen mit automatischen Rollback-Triggern.
• Regulatorische Rahmenwerke erwarten das inzwischen schriftlich: Der EU AI Act verlangt dokumentiertes Risikomanagement und Logging für industrielle Hochrisiko-KI, und das AI RMF des NIST wird zum Referenzstandard, selbst für US-Werke ohne direkte gesetzliche Verpflichtung.
• Behandeln Sie das Deployment als Gate, nicht als Datum: Ordnen Sie die Checkliste so, dass das System erst live geht, wenn jeder Guardrail getestet und nicht nur konzipiert wurde.
• Benennen Sie einen einzigen Owner mit der Befugnis, den Launch zu verschieben. Checklisten ohne Verantwortlichkeit werden Papierkram; Checklisten mit Verantwortlichkeit werden Guardrails.