Governance, die skaliert: KI-Aufsicht über mehrere Werke hinweg

# Governance, die skaliert: KI-Aufsicht über mehrere Werke hinweg

Ein Predictive-Maintenance-Modell, das auf Vibrationssensoren in einem Motorenwerk in Michigan trainiert wurde, wird in ein Schwesterwerk in Monterrey kopiert. Niemand aktualisiert das Risikoregister. Sechs Monate später hat die Linie in Monterrey andere Maschinen, andere Fehlerbilder, und ein Modell, das unbemerkt False Negatives produziert. Niemand ist für die Korrektur zuständig, weil niemand für das Modell zuständig ist. Das ist kein Gedankenexperiment: Es ist der Standardfehler, wenn Hersteller KI von einer Pilotlinie auf einen globalen Footprint skalieren, ohne die Governance mitzuskalieren.

Governance, die für ein Werk, ein Modell und einen Champion funktioniert, bricht in dem Moment zusammen, in dem Sie zwanzig Werke, zweihundert Modelle und eine wechselnde Besetzung von Werksleitern haben. Diese Lektion zeigt, wie Sie eine Aufsicht aufbauen, die mit dem Rollout mitskaliert und nicht dahinter herläuft.

Warum Governance für ein einzelnes Werk im MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßstab scheitert

Ein Pilot lebt meist unter dem Schreibtisch eines einzelnen Ingenieurs. Die Freigabe ist informell: Der Werksleiter gibt sein OK, die IT schließt den Datenfeed an, und alle arbeiten schnell.

Dieses Modell bricht unter drei Multi-Site-Belastungen zusammen:

• Model Sprawl. Jedes Werk passt das Modell an die lokale Ausrüstung an und erzeugt so Dutzende undokumentierte Varianten „desselben“ Systems.
• Ownership Drift. Der ursprüngliche Data Scientist wechselt das Team oder verlässt das Unternehmen. Niemand übernimmt die Verantwortung für Drift-Monitoring oder Retraining.
• Inkonsistente Risikoexposition. Ein Vision-Inspection-Modell, das auf einer unkritischen Verpackungslinie ausfällt, ist ein Ärgernis. Dasselbe Fehlermuster bei einer sicherheitskritischen Drehmomentprüfung für Luftfahrtverbindungselemente ist eine völlig andere Risikoklasse, und dennoch stehen beide möglicherweise in derselben informellen Tracking-Tabelle oder in gar keinem Tracking.

Aufsichtsbehörden und Normungsorganisationen erwarten von Herstellern zunehmend, KI-Risiken so zu behandeln, wie sie Qualitätsrisiken unter Systemen wie ISO 9001 längst behandeln: dokumentiert, mit klarer Verantwortung, auditierbar und nach Konsequenz abgestuft.

Die Grundstruktur: Modellinventar, Tiering, Ownership

Skalierte Governance ruht auf drei Bausteinen.

1. Ein Modellinventar. Ein einziges, verbindliches Register jedes KI-Systems in Produktion oder Pilotbetrieb, über alle Werke hinweg. Mindestfelder: Modellname, Zweck, Werk(e) im Einsatz, Datenquellen, Owner, Risk Tier, Datum der letzten Validierung, Datum der nächsten Review. Ist ein Modell nicht im Inventar, darf es nicht live gehen. Das entspricht der Erwartung eines „KI-System-Inventars“ in den Pflichten des EU AI Act für Anbieter von Hochrisikosystemen und ist unabhängig von der Jurisdiktion gute Praxis.

2. Risk Tiering. Nicht jedes Modell verdient dieselbe Prüftiefe. Ein praxistaugliches Drei-Stufen-SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →, das mehrere Industrieunternehmen nutzen:

| Tier | Beispiel | Aufsicht |

|---|---|---|

| Tier 1: sicherheits-/compliancekritisch | Schweißfehlererkennung mit Pass/Fail-Entscheid für Strukturbauteile | Vollständige Validierung, menschliche Freigabe, Quartalsaudit |

| Tier 2: operativ | Predictive Maintenance, Demand Forecasting | Dokumentiertes Monitoring, halbjährliche Review |

| Tier 3: unkritisch | Interner Chatbot für FAQs zur Schichtplanung | Leichtgewichtiges Logging, jährliche Review |

Das Tiering bestimmt Auditfrequenz, Dokumentationstiefe und wer freigeben muss, damit der Aufwand dort landet, wo die Konsequenzen am größten sind.

3. Namentlich benannte Accountability Owner. Zwei getrennte Rollen, die so oft vermischt werden, dass es zu Fehlern führt:

• Model Owner: verantwortlich für Performance, Retraining und Außerbetriebnahme. Meist ein Data-Science- oder Engineering-Lead.
• Business Owner: verantwortlich für die operative Entscheidung, die das Modell unterstützt, und für das, was passiert, wenn es falsch liegt. Meist ein Werks-Operations- oder Qualitätsmanager.

Beide Namen stehen im Inventar. Wenn ein Drehmomentprüfmodell versagt, weiß innerhalb von Minuten jeder, wer das Modell untersucht und wer die Linie anhält.

Governance-Gremien: wer tatsächlich tagt und entscheidet

Eine funktionierende Struktur hat drei Ebenen und vermeidet sowohl ein einzelnes überlastetes Komitee als auch ein regelloses Durcheinander:

• Corporate AI Governance Council: legt die Policy fest, genehmigt das Risk-Tiering-Framework, prüft Tier-1-Modelle über alle Standorte, tagt monatlich oder quartalsweise. Typischerweise mit den Leitungen von Qualität, IT/OT-Security, Legal und Manufacturing Operations.
• AI Champions auf Standortebene: einer pro Werk, verantwortlich für die Pflege des lokalen Inventarteils, das Melden neuer Pilotprojekte und die termingerechte Durchführung lokaler Audits.
• Cross-Plant Model Review Board: für Modelle, die über Standorte hinweg kopiert oder skaliert werden (wie im Monterrey-Beispiel), eine Review vor jedem Redeployment, die bestätigt, dass das Modell auf lokalen Daten revalidiert und nicht bloß kopiert wurde.

Diese Struktur greift auf, wie Hersteller die Funktionen des AI Risk Management Framework von NIST (govern, mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →, measure, manage) bereits betreiben, überträgt sie aber auf einen physischen Multi-Site-Footprint statt auf eine einzelne Business Unit.

Auditrhythmus: was prüfen und wie oft

Audits sollten kein Compliance-Nachgedanke sein. Ein minimaler, praxistauglicher Rhythmus:

• Pre-Deployment-Check (jedes Modell, jeder Standort): Data LineageData LineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.Vollständige Definition ansehen → bestätigt, Bias-/Fehlertests auf lokalen Daten, definiertes Fallback-Verfahren, falls das Modell ausfällt oder nicht verfügbar ist.
• 30/60/90-Tage-Check nach Launch (Tier 1 und 2): Modellvorhersagen gegen Ground Truth vergleichen (tatsächlich gefundene Defekte, tatsächliche Maschinenausfälle), Schwellenwerte rekalibrieren.
• Quartalsweise Drift-Review (Tier 1): statistische Prüfung auf Data Drift, also darauf, ob die Live-Eingangsdaten von den Trainingsdaten abgewichen sind, etwa weil eine neue Rohmaterialcharge eines Lieferanten die Sensorwerte verändert.
• Jährliches Vollaudit (alle Tiers): erneut bestätigen, dass Business Owner und Model Owner noch die richtigen Personen sind, prüfen, ob das Modell noch seinem dokumentierten Zweck entspricht, Ungenutztes stilllegen.

Ein einfacher Drift-Check, den ein Qualitätsingenieur ohne Data-Science-Abschluss ausführen kann:

# Compare recent sensor readings to training baseline
import pandas as pd

baseline = pd.read_csv("training_data_baseline.csv")
recent = pd.read_csv("last_30_days_sensor_data.csv")

# Flag if the mean has shifted more than 2 standard deviations
threshold = baseline["vibration_reading"].std() * 2
drift = abs(recent["vibration_reading"].mean() - baseline["vibration_reading"].mean())

if drift > threshold:
    print("ALERT: possible data drift, escalate to model owner for review")
else:
    print("Within normal range")

So ein Check ersetzt keine Data-Science-Review, aber ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → gibt einem Owner auf Werksebene ein Frühwarnsignal zwischen den formalen Audits.

Regulatorischer Hintergrund, der den Rhythmus prägt

Hersteller mit Aktivitäten in der EU unterliegen dem EU AI Act, der 2024 in Kraft getreten ist, mit gestaffelten Pflichten bis 2026 und darüber hinaus. Sicherheitsrelevante KI in Maschinen (etwa KI-basierte Sicherheitssteuerungen an einer Produktionslinie) kann unter die Klassifizierung „Hochrisiko“ fallen und löst damit Anforderungen an Risikomanagementsysteme, technische Dokumentation, menschliche Aufsicht und Post-Market-Monitoring aus, Pflichten, die eng zur oben beschriebenen Tiering- und Auditstruktur passen.

In den USA gibt es Stand Anfang 2026 kein einheitliches Bundesgesetz zu KI, das dem EU AI Act entspricht. Stattdessen bewegen sich Hersteller in einem Flickenteppich: Die Maschinensicherheitsvorschriften der OSHA (Occupational Safety and Health Administration) gelten weiterhin, unabhängig davon, ob KI im Spiel ist, die FTC (Federal Trade Commission) hat signalisiert, irreführende oder unsichere KI-Aussagen zu prüfen, und das NIST-Framework bleibt freiwillig, wird aber immer häufiger in Kundenverträgen und im Versicherungs-Underwriting referenziert. US-Hersteller mit mehreren Standorten, die in die EU exportieren, sollten davon ausgehen, dass die Pflichten des EU AI Act für alle in der EU eingesetzten Systeme gelten, unabhängig davon, wo die Governance ihren Sitz hat.

Die praktische Konsequenz: Bauen Sie Inventar und Tiering-System nach dem strengeren Standard (in der Regel die Dokumentationstiefe des EU AI Act), dann erfüllen Sie die leichteren US-Erwartungen automatisch, statt zwei parallele Governance-Systeme zu betreiben.

🎬 [VIDEO: „How Siemens Approaches AI Governance in Manufacturing“ - youtube.com - suchen Sie nach aktuellen Konferenzvorträgen von Siemens oder aus der Fertigungsindustrie zum Skalieren von KI-Governance über Werke hinweg, die Inventar- und Auditpraktiken in einem realen industriellen Umfeld zeigen]

Eine Rollout-Sequenz, die das Monterrey-Problem vermeidet

1. Neue KI-Pilotprojekte für zwei Wochen einfrieren und alles inventarisieren, was bereits läuft, inklusive unoffizieller Spreadsheet-Modelle, die niemand gemeldet hat.

2. Jedes bestehende Modell mit dem Drei-Stufen-Framework tieren.

3. Jedem Modell einen namentlichen Model Owner und Business Owner zuweisen; Lücken sofort an das Corporate Council eskalieren.

4. Auditrhythmus je Tier festlegen und Termine in einen gemeinsamen Kalender eintragen, nicht in einen E-Mail-Thread.

5. Bevor ein Modell an einen zweiten Standort kopiert wird, die Freigabe des Cross-Plant Model Review Board verlangen, die die lokale Revalidierung bestätigt.

Wichtigste Erkenntnisse

• Führen Sie ein einziges verbindliches Modellinventar über alle Standorte; ein Modell, das nicht im Inventar steht, sollte nicht in Produktion sein.
• Tieren Sie Modelle nach Konsequenz (sicherheitskritisch, operativ, unkritisch) und richten Sie die Auditintensität am Tier aus, nicht an der Bequemlichkeit.
• Trennen und benennen Sie zwei verantwortliche Owner pro Modell: einen für die technische Performance des Modells, einen für die Geschäftsentscheidung, die es unterstützt.
• Bauen Sie eine dreistufige Governance-Struktur (Corporate Council, Site Champions, Cross-Plant Review Board), damit die Aufsicht mit der Zahl der Werke skaliert, nicht nur mit der Zahl der Modelle.
• Legen Sie die Dokumentation standardmäßig auf die Tiefe des EU AI Act aus; damit deckt sie die US-Erwartungen (OSHA, FTC, NIST-Framework) ab, ohne doppelte Governance-Systeme zu betreiben.