KI-Governance
in der Industrie.
Der EU AI Act als Engineering-Aufgabe.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
KI-Governance ist die Summe aus Regeln, Rollen und Nachweisen, mit denen ein Unternehmen den Einsatz seiner KI-Systeme steuert und belegt. In der industriellen Praxis besteht sie aus vier Artefakten: einem KI-Register, einer Model Card je Modellstand, automatisierten Drift- und Robustheitstests und einem dokumentierten Freigabeschritt. Alle vier lassen sich in der CI/CD-Pipeline erzeugen, statt sie vor einem Audit von Hand zusammenzutragen. Der rechtliche Rahmen dafür ist die KI-Verordnung (EU) 2024/1689, deren Hochrisiko-Stichtage der Digital Omnibus zur KI, Verordnung (EU) 2026/1744, auf den 2. Dezember 2027 (Anhang III) und den 2. August 2028 (Anhang I) verschoben hat. Am 2. August 2026 wird die Verordnung dennoch allgemein anwendbar, und die Transparenzpflichten nach Art. 50 greifen. Drei Fragen bleiben für jedes Industrieunternehmen zu klären: Sind wir Anbieter oder Betreiber? Ist unser System Hochrisiko? Und woher kommen die Nachweise für Risikomanagement, Daten-Governance, Logging und menschliche Aufsicht? Seit dem 7. Juli 2026 gibt es mit dem BSI-Prüfkatalog A5 erstmals einen deutschen Prüfmaßstab, gegen den sich diese Nachweise testieren lassen.
Aus der politischen Einigung vom Mai ist geltendes Recht geworden: Die Verordnung (EU) 2026/1744 („Digital Omnibus on AI“) vom 8. Juli 2026 wurde am 24. Juli im Amtsblatt veröffentlicht und ist am 27. Juli in Kraft getreten. Sie verschiebt die Hochrisiko-Stichtage auf den 2. Dezember 2027 (Anhang III) und den 2. August 2028 (Anhang I). Verbote, Transparenzpflichten und Sanktionen bleiben unangetastet. Was das im Einzelnen ändert, steht in Abschnitt 02; die Fristen im Überblick in der Zeitleiste.
Ist der EU AI Act bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Ab wann gilt der EU AI Act?
Der AI Act ist seit dem 1. August 2024 in Kraft, seine Pflichten greifen aber gestaffelt — und die Staffelung hat sich Ende Juli 2026 geändert. Für die Industrie sind jetzt drei Stichtage entscheidend: der 2. August 2026 für die allgemeine Anwendbarkeit und die Transparenzpflichten nach Art. 50, der 2. Dezember 2027 für Hochrisiko-Systeme nach Anhang III und der 2. August 2028 für KI in regulierten Produkten nach Anhang I. Maßgeblich ist der Volltext der Verordnung (EU) 2024/1689 auf EUR-Lex; die offizielle Umsetzungs-Zeitleiste pflegt die Kommission im AI Act Service Desk.
Aus der Einigung vom 7. Mai 2026 ist Recht geworden: Die Verordnung (EU) 2026/1744 vom 8. Juli 2026 steht seit dem 24. Juli im Amtsblatt und gilt seit dem 27. Juli. Wer die Vorbereitung deshalb pausiert, verschiebt nur den Aufwand: Die Pflichten selbst ändern sich nicht, nur ihr Stichtag — und 16 Monate mehr sind in einem Maschinenprojekt keine lange Zeit.
Was ändert der Digital Omnibus an der KI-Verordnung — und was bleibt?
Der Digital Omnibus zur KI ist ein Änderungspaket der EU-Kommission: Verordnung (EU) 2026/1744 verschiebt die Hochrisiko-Stichtage der KI-Verordnung auf den 2. Dezember 2027 und den 2. August 2028 und schärft einzelne Begriffe — Verbote, Transparenzpflichten und Sanktionen lässt sie unberührt. Geändert werden dabei nicht nur die KI-Verordnung, sondern auch die Verordnungen (EU) 2018/1139 und (EU) 2023/1230. Für Industrieunternehmen sind fünf Punkte relevant — die Fristen, der Bestand an Pflichten zum 2. August 2026, der geschärfte Begriff des Sicherheitsbauteils, der neue Weg über die Maschinenverordnung und die abgeschwächte KI-Kompetenz-Pflicht. Wer im Frühjahr eine Roadmap auf den 2. August 2026 gebaut hat, muss sie nicht wegwerfen, aber neu datieren.
Welche neuen Fristen setzt der Digital Omnibus?
Verordnung (EU) 2026/1744 ändert Art. 113 der KI-Verordnung: Hochrisiko-KI nach Anhang III muss die Anforderungen aus Kapitel III Abschnitt 1–3 erst ab dem 2. Dezember 2027 erfüllen, Hochrisiko-KI in regulierten Produkten nach Anhang I erst ab dem 2. August 2028. Begründet wird das mit harmonisierten Normen, die noch nicht vorliegen, und mit Behörden, die noch im Aufbau sind. Das ist keine Einigung mehr, über die man Neuigkeiten abwarten müsste — es steht seit dem 24. Juli 2026 im Amtsblatt und gilt seit dem 27. Juli.
Was gilt trotzdem ab dem 2. August 2026?
Die Verordnung wird an diesem Tag allgemein anwendbar, und die Transparenzpflichten nach Art. 50 greifen: Wer mit einem KI-System interagiert, muss das erkennen können, KI-generierte Inhalte sind zu kennzeichnen. Unverändert gelten außerdem die Verbote nach Art. 5, die GPAI-Pflichten und die Sanktionsvorschriften — verschoben wurden ausschließlich die Hochrisiko-Anforderungen. Für ein Industrieunternehmen heißt das praktisch: Der Chatbot im Serviceportal und die generative KI in der Dokumentation brauchen jetzt eine Kennzeichnung, das Risikomanagement für die Anlagen-KI hat mehr Zeit.
Bleibt unsere KI-Qualitätsinspektion ein Hochrisiko-System?
Der Omnibus schärft den Begriff des Sicherheitsbauteils: Eine Komponente erfüllt nur dann eine Sicherheitsfunktion, wenn ihre Zweckbestimmung darin besteht, Risiken für Gesundheit und Sicherheit abzuwenden oder zu mindern. Ausdrücklich ausgenommen sind Systeme, die allein der Unterstützung der Bedienung, der Leistungsoptimierung, der Effizienz, dem Komfort oder einer nicht sicherheitsbezogenen Qualitätskontrolle dienen. Eine Kamera-KI, die Oberflächenfehler sortiert, wird damit nicht dadurch zum Hochrisiko-System, dass sie in einer Maschine sitzt. Die Einstufung selbst muss aber weiterhin begründet und dokumentiert sein — und genau diese Begründung ist es, die im Prüffall vorliegen muss.
Was ändert sich für Maschinenbauer konkret?
Der Verweis auf Maschinen wandert in Anhang I von Abschnitt A nach Abschnitt B der KI-Verordnung und zeigt künftig auf die Maschinenverordnung (EU) 2023/1230 statt auf die alte Maschinenrichtlinie. Der Weg zur Konformität führt damit stärker über das Produktrecht: Die Kommission muss bis zum 2. August 2028 delegierte Rechtsakte erlassen, die die KI-Anforderungen in Anhang III der Maschinenverordnung einarbeiten. Für die Entwicklung heißt das: Die Nachweise werden Teil der Maschinen-Konformitätsbewertung, nicht ein separates KI-Verfahren daneben.
Gilt die KI-Kompetenz-Pflicht nach Art. 4 weiter?
Sie gilt, aber abgeschwächt. Anbieter und Betreiber müssen Maßnahmen ergreifen, um die KI-Kompetenz ihres Personals zu fördern — ein garantiertes Kompetenzniveau einzelner Personen schuldet niemand mehr. Kommission und Mitgliedstaaten sollen mit Schulungsangeboten und Informationsmaterial unterstützen. Wer Schulungen dokumentiert und Rollen benennt, ist damit auf der sicheren Seite; wer bislang gar nichts hat, sollte das nicht als Entwarnung lesen.
Die verschobenen Stichtage sind kein Grund, das Thema zurückzustellen — sie sind das Zeitfenster, in dem sich die Nachweise ohne Termindruck automatisieren lassen. Der Aufwand entsteht nicht durch die Verordnung, sondern durch das nachträgliche Rekonstruieren von Trainingsständen, Testergebnissen und Freigaben. Wie das aus der Pipeline heraus funktioniert, steht in Abschnitt 05.
Wer ist vom AI Act betroffen — Anbieter oder Betreiber?
Der AI Act unterscheidet Rollen entlang der Wertschöpfungskette — und an der Rolle hängt der Pflichtenumfang. Für Maschinenbau und Automotive ist diese Einordnung der erste Schritt jeder AI-Act-Umsetzung, denn viele Unternehmen sind beides zugleich: Betreiber von KI in der eigenen Produktion und Anbieter von KI in ihren Produkten. Fast jedes Industrieunternehmen startet dabei am selben Punkt: Es gibt keine vollständige Liste der eingesetzten KI-Systeme, und die Rollenfrage hat sich bislang niemand gestellt. Das ist der normale Ausgangspunkt, kein Versäumnis — nur sollte die Bestandsaufnahme nicht erst mit dem Stichtag beginnen. Überwacht wird die Einhaltung in Deutschland künftig zentral durch die Bundesnetzagentur als KI-Marktüberwachungsbehörde; das nationale Durchführungsgesetz durchläuft derzeit den Bundestag.
Entwickelt ein KI-System oder lässt es entwickeln und bringt es unter eigenem Namen in der EU in Verkehr — auch als Teil eines Produkts. Anbieter tragen die vollen Hochrisiko-Pflichten: Risikomanagement, Konformitätsbewertung, CE-Kennzeichnung, Registrierung in der EU-Datenbank.
Setzt ein KI-System unter eigener Verantwortung ein — etwa eine zugekaufte Inspektionslösung in der Linie. Pflichten nach Art. 26: bestimmungsgemäße Nutzung, menschliche Aufsicht durch geschultes Personal, Kontrolle der Eingabedaten und Aufbewahrung der automatisch erzeugten Protokolle.
Wer ein Hochrisiko-System unter eigenem Namen vermarktet oder wesentlich verändert, wird selbst zum Anbieter (Art. 25) — inklusive aller Anbieter-Pflichten. Relevant für Maschinenbauer, die zugekaufte KI-Module in ihre Anlagen integrieren und als Gesamtsystem verkaufen.
Vier Industrie-Beispiele — und ihre Einstufung
KI-Qualitätsinspektion per Computer Vision
Eine Kamera-KI, die Oberflächenfehler erkennt, fällt in der Regel nicht unter Anhang III — sie ist meist ein System mit minimalem Risiko. Der Digital Omnibus stützt diese Einordnung ausdrücklich: Eine nicht sicherheitsbezogene Qualitätskontrolle erfüllt keine Sicherheitsfunktion und wird nicht dadurch zum Hochrisiko-System, dass sie in einem regulierten Produkt steckt. Trotzdem gelten die KI-Kompetenz-Pflichten (Art. 4), und die Einstufung selbst muss begründet und dokumentiert sein. Wer falsch einstuft, riskiert die Nachprüfung durch die Marktüberwachung.
Predictive Maintenance auf Sensordaten
Vorausschauende Wartung ist meist ebenfalls kein Hochrisiko-Fall. Anders, wenn die KI als Sicherheitskomponente im Betrieb kritischer Infrastruktur arbeitet (Anhang III Nr. 2) — etwa in der Energie- oder Wasserversorgung. Dann greifen die vollen Pflichten, seit dem Omnibus ab dem 2. Dezember 2027.
KI im Sicherheitsbauteil einer Maschine
Übernimmt KI eine Sicherheitsfunktion — etwa adaptive Geschwindigkeitsbegrenzung bei Mensch-Roboter-Kollaboration — wird sie über Anhang I in Verbindung mit der Maschinenverordnung zum Hochrisiko-System. Der Stichtag liegt hier auf dem 2. August 2028, und bis dahin arbeitet die Kommission die KI-Anforderungen in die Maschinenverordnung ein. Maschinen, die dann auf den Markt kommen, sind heute in der Konstruktion.
KI im Personaleinsatz
Oft übersehen: Systeme für Schichtplanung mit Leistungsbewertung, Bewerber-Screening oder Beförderungsentscheidungen sind Hochrisiko nach Anhang III Nr. 4 — auch im Maschinenbauunternehmen, das sonst keine Hochrisiko-KI betreibt. Stichtag ist der 2. Dezember 2027; die Systeme laufen in vielen Personalabteilungen längst.
Welche Pflichten gelten für Hochrisiko-KI?
Kapitel III des AI Act definiert für Hochrisiko-Systeme sechs technische Kernanforderungen (Art. 9–15). Hinzu kommen für Anbieter ein Qualitätsmanagementsystem, die Konformitätsbewertung mit CE-Kennzeichnung und die Registrierung in der EU-Datenbank. Erfüllt sein müssen sie ab dem 2. Dezember 2027 (Anhang III) beziehungsweise dem 2. August 2028 (Anhang I) — der Digital Omnibus hat die Stichtage verschoben, den Katalog selbst aber nicht angetastet. Die Anforderungen sind kein einmaliges Zulassungs-Audit — sie gelten über den gesamten Lebenszyklus, also bei jedem Modell-Update neu. Und im Prüffall zählt nicht, was das Team über das System weiß, sondern was sich belegen lässt: Die Marktüberwachung fragt nach Dokumenten und Protokollen, nicht nach Erinnerungen.
Risikomanagementsystem
Ein kontinuierlicher, dokumentierter Prozess über den gesamten Lebenszyklus: Risiken identifizieren, bewerten, mindern — nicht einmalig vor dem Inverkehrbringen, sondern bei jedem Update neu.
Daten-Governance
Trainings-, Validierungs- und Testdaten müssen relevant, repräsentativ und so fehlerfrei wie möglich sein. Herkunft, Aufbereitung und bekannte Verzerrungen sind zu dokumentieren.
Technische Dokumentation
Vor dem Inverkehrbringen muss eine Dokumentation nach Anhang IV vorliegen: Zweckbestimmung, Architektur, Trainingsverfahren, Metriken, Grenzen des Systems — und sie muss aktuell bleiben.
Aufzeichnungspflichten (Logging)
Hochrisiko-Systeme müssen Ereignisse über ihre Laufzeit automatisch protokollieren, damit Risikosituationen und wesentliche Änderungen nachvollziehbar sind. Betreiber bewahren die Logs mindestens sechs Monate auf.
Menschliche Aufsicht
Das System muss so gestaltet sein, dass Menschen es wirksam überwachen, eingreifen und es stoppen können. Die Aufsichtsmaßnahmen gehören in die Gebrauchsanweisung — und beim Betreiber in geschulte Hände.
Genauigkeit, Robustheit, Cybersicherheit
Angemessene Genauigkeit über den Lebenszyklus, Widerstandsfähigkeit gegen Fehler und Manipulation — einschließlich KI-spezifischer Angriffe wie Data Poisoning oder Adversarial Examples.
Womit weist man das nach? Der BSI-Prüfkatalog A5.
Bislang war die ehrliche Antwort auf diese Frage: mit selbstgebauten Kriterienkatalogen und viel Interpretationsspielraum. Das ändert sich gerade. Am 7. Juli 2026 hat das BSI den ersten Community Draft seines KI-Prüfkatalogs A5 (AI Audit and Assurance Assessment Architecture) veröffentlicht — eine modulare Prüfarchitektur für die Vertrauenswürdigkeit von KI-Systemen, methodisch angelehnt an den etablierten Cloud-Katalog C5 und den Prüfstandard ISAE 3000. Adressiert sind ausdrücklich die Nachweisanforderungen aus AI Act und Cyber Resilience Act.
Für DevOps-Teams ist das interessanteste Detail ein technisches: Die Kriterien erscheinen zusätzlich maschinenlesbar im OSCAL-Format — sie lassen sich also direkt in Compliance-Toolchains und damit in die Pipeline integrieren, statt in einem PDF zu altern. Noch ist A5 ein Entwurf, kommentierbar bis zum 31. August 2026. Aber die Richtung ist klar: Die Nachweise aus Art. 9–15 werden künftig gegen einen konkreten deutschen Prüfmaßstab testiert — und wer seine Audit-Trails heute schon automatisiert erzeugt, muss dafür nichts umbauen. Module, Methodik und Handlungsempfehlungen haben wir in einer eigenen Analyse zum BSI A5 Prüfkatalog aufgeschlüsselt.
Wie setzt man den AI Act in der CI/CD-Pipeline um?
Die gute Nachricht für DevOps-Teams: Die Hochrisiko-Pflichten beschreiben im Kern Engineering-Disziplin — Versionierung, Tests, Protokollierung, Dokumentation. Wer Modelle, Trainingsdaten und Code gemeinsam versioniert und die Nachweise als automatische Quality Gates in die Pipeline verankert, erzeugt die AI-Act-Dokumentation bei jedem Release als Nebenprodukt — statt sie vor dem Audit manuell zusammenzusuchen. Wer diese Rekonstruktion schon einmal rückwirkend versucht hat, kennt den Preis: Wochen an Sucharbeit für Trainingsstände, die nie festgehalten wurden — und am Ende bleiben Lücken, die sich nicht mehr schließen lassen.
pipeline (AI-Act-Gates, vereinfacht) ├── 01 data-validation Trainings-/Testdaten gegen Governance-Regeln prüfen (Art. 10) ├── 02 model-versioning Modell, Daten und Code gemeinsam versionieren (Art. 11) ├── 03 robustness-tests Genauigkeit, Drift- und Adversarial-Checks (Art. 15) ├── 04 tech-doku Technische Dokumentation aus der Pipeline generieren (Anhang IV) ├── 05 audit-log Ereignisprotokolle revisionssicher ablegen (Art. 12) └── 06 human-gate Freigabe-Step mit dokumentierter menschlicher Aufsicht (Art. 14)
Konkret heißt das: Jeder Modellstand ist über Git nachvollziehbar mit den Daten und Parametern verknüpft, die ihn erzeugt haben (Art. 11). Robustheits- und Drift-Tests laufen als Gate vor jedem Deployment (Art. 15). Die technische Dokumentation nach Anhang IV wird aus Pipeline-Metadaten generiert statt in Word gepflegt. Und der Freigabe-Step dokumentiert die menschliche Aufsicht revisionssicher (Art. 14) — GitOps-Workflows liefern den Audit-Trail frei Haus. Der Moment, in dem die erste Anhang-IV-Dokumentation fertig generiert aus einem Release fällt, verändert die Wahrnehmung im Team: Compliance ist dann kein Sonderprojekt mehr, sondern ein Nebeneffekt des normalen Arbeitens. Wie KI-Systeme strukturiert in die industrielle Softwarelieferkette einziehen, beschreibt unser Leitfaden zur Intelligisierung der Industrie.
Der Nebeneffekt: Dieselbe Pipeline-Infrastruktur — Audit-Trails, signierte Artefakte, automatisierte Doku — bedient auch IEC 62443, den Cyber Resilience Act und NIS2. Wie Comquent solche Compliance-Gates aufbaut, zeigt die Seite DevSecOps & Compliance. Und wenn Sie einordnen möchten, wie weit Ihre eigene Pipeline von diesem Stand entfernt ist: Das erste Gespräch dauert 30 Minuten, kostet nichts und verpflichtet zu nichts.
Was ist KI-Governance in der Praxis, und wer pflegt sie?
KI-Governance ist die Summe aus Regeln, Rollen und Nachweisen, mit denen ein Unternehmen den Einsatz seiner KI-Systeme steuert und belegt. In der industriellen Praxis besteht sie aus fünf Artefakten: einem KI-Register, einer Model Card je Modellstand, einem Drift-Gate vor dem Deployment, einer Freigabe mit Namen und Zeitstempel sowie dem Nachweis, wer geschult ist. Gepflegt werden sie nicht von einem Gremium, sondern von dem Team, das die Modelle baut.
Die verfügbare Literatur zum Thema beschreibt Governance fast durchgehend als Organisationsfrage: Richtlinien, Rollen, Freigabegremien, Ethikbeirat. Das ist nicht falsch, beantwortet aber nicht die Frage, an der es in einem Industrieunternehmen hängt. Ob ein KI-Register funktioniert, entscheidet sich nicht am Tag, an dem es angelegt wird, sondern acht Wochen später: Steht dort noch der Modellstand, der tatsächlich in der Linie läuft? Governance, die neben der Entwicklung liegt, driftet ab. Governance, die in der Pipeline liegt, kann nicht abdriften, weil dieselbe Änderung, die das Modell ausrollt, auch den Nachweis erzeugt.
KI-Register
Die KI-Verordnung verlangt kein Register als solches. Sie verlangt, dass Sie für jedes System die Rolle, die Risikoklasse und die Begründung der Einstufung vorlegen können, und ohne Liste geht das nicht. In der Praxis scheitert diese Liste selten am Anlegen, sondern am zweiten Monat: Sie liegt als Tabelle auf einem Netzlaufwerk, und niemand bemerkt, wenn ein Team ein Modell tauscht. Legen Sie das Register stattdessen als versionierte Datei neben den Code, in dem die Systeme leben. Dann erzeugt jede Änderung einen Commit mit Autor und Datum, und der Review der Entwicklung ist zugleich die Freigabe der Governance.
Model Card je Modellstand
Eine Model Card beschreibt einen einzelnen Modellstand: Zweckbestimmung, Trainings- und Testdaten, Metriken, bekannte Grenzen und die Bedingungen, unter denen das Modell nicht verwendet werden darf. Das deckt einen guten Teil dessen ab, was Anhang IV für die technische Dokumentation verlangt, ersetzt sie aber nicht vollständig. Der eigentliche Gewinn liegt im Zeitpunkt. Wird die Model Card im Trainingslauf aus Metadaten erzeugt, ist sie am Tag des Modells fertig, statt ein halbes Jahr später aus Notizbüchern und Chatverläufen rekonstruiert zu werden.
Drift-Gate vor dem Deployment
Art. 15 verlangt angemessene Genauigkeit über den gesamten Lebenszyklus, nicht nur am Tag der Freigabe. Modelle verlieren diese Genauigkeit unauffällig. Bei Model Drift ändert sich der Zusammenhang, den das Modell gelernt hat, bei Data Drift verschiebt sich die Verteilung der Eingangsdaten. In der Fertigung genügen dafür eine neue Charge Rohmaterial, eine getauschte Kameraoptik oder ein anderer Lieferant. Ein Gate, das die aktuellen Vorhersagen gegen einen festen Referenzdatensatz prüft und bei Überschreitung eines Schwellwerts rot wird, macht aus diesem schleichenden Vorgang ein Ereignis mit Zeitstempel.
Freigabe als Commit
Menschliche Aufsicht nach Art. 14 ist im Prüffall keine Aussage, sondern ein Beleg. Wer freigibt, muss benannt sein, und die Freigabe muss sich einem konkreten Stand zuordnen lassen. Ein Approval im Merge-Request leistet genau das, ohne dass jemand ein zusätzliches Formular ausfüllt. Es trägt Person, Zeitpunkt, Modellstand und Kommentar. Teams mit GitOps-Workflow haben diesen Audit-Trail längst, sie nennen ihn nur nicht Governance.
KI-Kompetenz und Rollen
Art. 4 verlangt seit Februar 2025 Maßnahmen zur Förderung der KI-Kompetenz des Personals. Der Digital Omnibus hat daraus eine Förderpflicht ohne garantiertes Kompetenzniveau gemacht, an der Umsetzung ändert das wenig. Sie brauchen eine Zuordnung, wer welches System bedienen und beaufsichtigen darf, und einen Nachweis, dass diese Personen geschult wurden. Wer die Rollen ohnehin im Register führt, hängt die Schulungsnachweise an dieselbe Stelle.
Keines dieser fünf Artefakte ist neu erfunden. Versionierung, Reviews, Testgates und Freigaben sind das tägliche Handwerk jedes DevOps-Teams, und genau darin liegt der Hebel: Ein Unternehmen mit funktionierender CI/CD-Praxis hat die Hälfte der KI-Governance bereits gebaut, bevor die erste Richtlinie geschrieben ist. Wie diese Praxis aussieht, wenn KI planmäßig in die industrielle Softwarelieferkette einzieht, steht in unserem Text zu MLOps und Industrial AI in der Fertigung. Wo Ihr Team dabei heute steht, zeigt der DevOps-Reifegrad-Check in 15 Minuten, ohne Anmeldung.
Wie sieht die Umsetzung in drei Industrie-Anwendungsfällen aus?
Die vier Beispiele in Abschnitt 03 beantworten die Frage, ob ein System Hochrisiko ist. Die drei hier beantworten die Frage danach: Was baut das Team konkret, wenn die Einstufung steht? Alle drei stammen aus Konstellationen, die uns in Industrieprojekten regelmäßig begegnen, und in allen dreien ist die Einstufung der kleinere Teil der Arbeit.
Vision-Modell in der Endprüfung
- Situation
- Ein Sondermaschinenbauer prüft Schweißnähte mit einem Kamera-Modell. Die Anlagen gehen an Kunden in der EU, und das Modell wird alle paar Monate mit neuen Fehlerbildern nachtrainiert.
- Einstufung
- Die Prüfung ist Qualitätskontrolle ohne Sicherheitsfunktion. Das System fällt damit nicht über Anhang I in die Hochrisiko-Klasse, was der Digital Omnibus ausdrücklich klarstellt. Nachweispflichtig bleibt die Einstufung selbst.
- In der Pipeline
- Register-Eintrag mit Rolle, Risikoklasse und Begründung. Model Card bei jedem Nachtraining. Drift-Gate gegen einen eingefrorenen Satz Prüfbilder, das anschlägt, bevor der Ausschuss in der Statistik auffällt.
KI-Funktion im Steuergerät
- Situation
- Ein Zulieferer entwickelt eine Assistenzfunktion mit einem neuronalen Netz im Steuergerät. Sie greift in die Längsführung ein, also in eine Sicherheitsfunktion.
- Einstufung
- Hier ist die KI Sicherheitsbauteil eines regulierten Produkts und fällt über Anhang I in die Hochrisiko-Klasse. Stichtag ist der 2. August 2028. Parallel laufen ohnehin ASPICE und ISO 26262.
- In der Pipeline
- Der Aufwand entsteht nicht zweimal. Traceability, HiL-Läufe und Freigabeprotokolle gibt es im Automotive-Umfeld längst. Was meist fehlt, ist die Verknüpfung zwischen einem konkreten Modellstand und dem Testergebnis, das ihn freigegeben hat. Genau diese Verknüpfung ist die Anhang-IV-Dokumentation.
Predictive Maintenance über vier Werke
- Situation
- Ein Fertiger betreibt dasselbe Wartungsmodell an vier Standorten. Jedes Werk hat eigene Sensorik, eigene Wartungsintervalle und nach zwei Jahren auch eigene Modellstände, die niemand mehr vollständig auseinanderhalten kann.
- Einstufung
- Vorausschauende Wartung ist meist kein Hochrisiko-Fall, solange die KI keine Sicherheitsfunktion übernimmt. In der Energie- oder Wasserversorgung sieht das anders aus, dort greift Anhang III Nr. 2 mit Stichtag 2. Dezember 2027.
- In der Pipeline
- Ein Register, das je Standort den ausgerollten Modellstand führt, und ein Rollout über dieselbe Pipeline für alle vier Werke. Die Frage, welches Werk seit wann auf welchem Modell läuft, ist danach eine Abfrage und keine Rundmail.
Auffällig ist, was in allen drei Fällen die eigentliche Arbeit ausmacht. Nicht die juristische Einstufung, für die ein Nachmittag mit dem Entscheidungspfad aus Abschnitt 03 reicht. Sondern die Frage, wo der belastbare Zusammenhang zwischen einem Modellstand, den Daten dahinter und der Person entsteht, die ihn freigegeben hat. Wer diesen Zusammenhang nach dem Stichtag herstellen will, sucht in Ordnerstrukturen. Wer ihn vorher in die Pipeline legt, hat ihn beim nächsten Release automatisch. Wie wir solche Nachweis-Gates aufbauen, steht auf der Seite DevSecOps & Compliance.
AI Act, CRA, NIS2 — was reguliert was?
Die drei Regularien überlappen bewusst: Eine vernetzte Maschine mit KI-Sicherheitsfunktion fällt unter den AI Act und den Cyber Resilience Act; betreibt ein unter NIS2 fallendes Unternehmen diese Maschine, kommen die organisatorischen Pflichten dazu. Wer die Nachweise einmal in der Pipeline automatisiert, beantwortet alle drei Regularien aus derselben Infrastruktur — statt drei getrennte Compliance-Projekte zu führen.
Was ist der EU AI Act?
Der EU AI Act (Verordnung (EU) 2024/1689) ist die weltweit erste umfassende KI-Regulierung. Er ist seit dem 1. August 2024 in Kraft und stuft KI-Systeme nach Risiko ein: verbotene Praktiken, Hochrisiko-Systeme mit umfangreichen Pflichten, Systeme mit Transparenzpflichten und KI mit minimalem Risiko ohne Sonderauflagen. Als Verordnung gilt er unmittelbar in allen EU-Mitgliedstaaten — ein nationales Umsetzungsgesetz wie bei NIS2 ist nicht erforderlich.
Was ist KI-Governance?
KI-Governance ist die Summe aus Regeln, Rollen und Nachweisen, mit denen ein Unternehmen den Einsatz seiner KI-Systeme steuert und belegt. Sie hat eine organisatorische Seite, also Zuständigkeiten, Freigabewege und Richtlinien, und eine technische, die im Prüffall die eigentliche Last trägt: ein KI-Register mit Rolle und Risikoklasse je System, eine Model Card je Modellstand, automatisierte Drift- und Robustheitstests sowie eine Freigabe mit Name und Zeitstempel. Für Industrieunternehmen ist die zweite Seite die entscheidende, weil sich Compliance dort nicht behaupten, sondern nur belegen lässt. Wer diese Artefakte in der CI/CD-Pipeline erzeugt, hält sie automatisch aktuell, statt sie in einer Tabelle nachzupflegen.
Was gehört in ein KI-Register?
Ein KI-Register listet je System mindestens: Bezeichnung und Zweckbestimmung, die Rolle des Unternehmens als Anbieter oder Betreiber nach Art. 25, die Risikoklasse mit der Begründung der Einstufung, den aktuell ausgerollten Modellstand, die verwendeten Datenquellen, die verantwortliche Person und den Nachweis ihrer Schulung nach Art. 4. Die KI-Verordnung schreibt kein Register als Dokument vor, verlangt aber genau diese Angaben im Prüffall. Praktisch bewährt hat sich, das Register als versionierte Datei im Repository zu führen statt als Tabelle auf einem Laufwerk: Jede Änderung erzeugt dann einen Commit mit Autor und Datum, und der Eintrag veraltet nicht still, wenn ein Team ein Modell tauscht.
Was ist eine Model Card, und reicht sie als technische Dokumentation nach Anhang IV?
Eine Model Card ist ein kurzes, versioniertes Dokument zu einem einzelnen Modellstand: Zweckbestimmung, Trainings-, Validierungs- und Testdaten, Metriken, bekannte Grenzen und die Bedingungen, unter denen das Modell nicht eingesetzt werden darf. Als alleinige technische Dokumentation nach Anhang IV der KI-Verordnung reicht sie nicht, weil dort zusätzlich Systemarchitektur, Risikomanagement und Angaben zur menschlichen Aufsicht verlangt werden. Sie deckt aber den Kern ab und löst das eigentliche Problem, nämlich den Zeitpunkt: Wird die Model Card im Trainingslauf automatisch aus Metadaten erzeugt, ist sie am Tag des Modells fertig, statt Monate später aus Notizen rekonstruiert zu werden.
Welche KI-Kompetenz verlangt der AI Act von Mitarbeitern?
Art. 4 der KI-Verordnung verpflichtet Anbieter und Betreiber seit dem 2. Februar 2025, Maßnahmen zur Förderung der KI-Kompetenz ihres Personals zu ergreifen, angemessen zu technischem Wissen, Erfahrung und Einsatzkontext. Der Digital Omnibus hat die Vorschrift zu einer Förderpflicht abgeschwächt, ein garantiertes Kompetenzniveau einzelner Personen schuldet niemand mehr. Für die Umsetzung ändert das wenig: Nachweisbar sein muss, wer welches System bedienen und beaufsichtigen darf und dass diese Personen geschult wurden. In der Praxis genügt dafür, Rollen und Schulungsnachweise am jeweiligen Eintrag im KI-Register zu führen, statt eine getrennte Kompetenzmatrix zu pflegen.
Wie erkennt man Model Drift und Data Drift in einer Produktions-KI?
Model Drift und Data Drift erkennt man, indem die laufenden Vorhersagen regelmäßig gegen einen eingefrorenen Referenzdatensatz gemessen und die Verteilungen der Eingangsdaten überwacht werden. Bei Data Drift verschiebt sich die Verteilung der Eingangsdaten, bei Model Drift ändert sich der Zusammenhang, den das Modell gelernt hat. In der Fertigung reichen dafür eine neue Charge Rohmaterial, eine getauschte Kameraoptik oder ein anderer Lieferant. Weil Art. 15 der KI-Verordnung angemessene Genauigkeit über den gesamten Lebenszyklus verlangt und nicht nur zum Zeitpunkt der Freigabe, gehört diese Messung als Gate vor jedes Deployment: Überschreitet die Abweichung einen definierten Schwellwert, bricht die Pipeline ab und der schleichende Qualitätsverlust wird zu einem Ereignis mit Zeitstempel.
Was ändert sich am 2. August 2026?
Am 2. August 2026 wird der AI Act allgemein anwendbar, und die Transparenzpflichten nach Art. 50 greifen — etwa die Kennzeichnung von KI-Interaktionen und KI-generierten Inhalten. Die Hochrisiko-Pflichten nach Anhang III sind an diesem Tag dagegen nicht mehr fällig: Der Digital Omnibus zur KI, Verordnung (EU) 2026/1744, ist am 27. Juli 2026 in Kraft getreten und hat sie auf den 2. Dezember 2027 verschoben; Hochrisiko-KI in regulierten Produkten nach Anhang I folgt am 2. August 2028. Unverändert bleiben die Verbote nach Art. 5, die GPAI-Pflichten und die Sanktionsvorschriften.
Was ist der Digital Omnibus zur KI?
Der Digital Omnibus ist ein Änderungspaket der EU-Kommission, mit dem bestehende Digitalgesetzgebung nachjustiert wird; sein KI-Teil ist die Verordnung (EU) 2026/1744, in Kraft seit dem 27. Juli 2026. Sie ändert Art. 113 der KI-Verordnung (EU) 2024/1689 und verschiebt damit die Stichtage für Hochrisiko-KI-Systeme, schärft den Begriff des Sicherheitsbauteils und schwächt die KI-Kompetenz-Pflicht nach Art. 4 zu einer Förderpflicht ab. Eine Deregulierung ist der Omnibus nicht: Er streicht keine Anforderung aus dem Hochrisiko-Katalog, sondern datiert sie neu — die Verbote nach Art. 5, die Transparenzpflichten nach Art. 50, die GPAI-Pflichten und die Sanktionsvorschriften bleiben unverändert.
Wurden die Hochrisiko-Fristen des AI Act verschoben?
Ja. Verordnung (EU) 2026/1744 („Digital Omnibus on AI“) vom 8. Juli 2026 wurde am 24. Juli 2026 im Amtsblatt veröffentlicht und ist am 27. Juli 2026 in Kraft getreten. Sie ändert Art. 113 der KI-Verordnung: Hochrisiko-KI nach Anhang III muss die Anforderungen aus Kapitel III Abschnitt 1–3 ab dem 2. Dezember 2027 erfüllen, Hochrisiko-KI als Sicherheitsbauteil regulierter Produkte nach Anhang I ab dem 2. August 2028. Verschoben ist nur der Stichtag — die Pflichten selbst bleiben unverändert, und die Zeit ist der eigentliche Gewinn: Wer die Nachweise jetzt in die Pipeline baut, hat sie fertig, wenn sie geprüft werden.
Welche KI-Systeme gelten als Hochrisiko?
Zwei Wege führen zur Hochrisiko-Einstufung: Anhang III listet Einsatzfelder wie Sicherheitskomponenten kritischer Infrastruktur, Beschäftigung und Personalmanagement, Bildung oder Strafverfolgung. Anhang I erfasst KI als Sicherheitsbauteil von Produkten, die bereits einer EU-Harmonisierung mit Drittprüfung unterliegen — etwa Maschinen oder Medizinprodukte. Typische Industrie-KI wie Qualitätsinspektion oder Predictive Maintenance ist dagegen meist kein Hochrisiko-Fall. Der Digital Omnibus stellt das ausdrücklich klar: Systeme, die allein der Unterstützung der Bedienung, der Effizienz oder einer nicht sicherheitsbezogenen Qualitätskontrolle dienen, erfüllen keine Sicherheitsfunktion. Die Einstufung muss aber dokumentiert und begründet sein.
Gilt der EU AI Act für Maschinenbau und Automotive?
Ja. Sobald KI eine Sicherheitsfunktion in einer Maschine oder einem Fahrzeug übernimmt, wird sie über Anhang I zum Hochrisiko-System; der Stichtag dafür ist nach dem Digital Omnibus der 2. August 2028. Typische Produktions-KI wie Qualitätsinspektion oder Predictive Maintenance bleibt dagegen meist außerhalb der Hochrisiko-Klasse. Betroffen sind Maschinenbau und Automotive außerdem als Betreiber von KI in der eigenen Fertigung und bei KI im Personaleinsatz nach Anhang III (Stichtag 2. Dezember 2027). Wer zugekaufte KI-Module in eine Anlage integriert und als Gesamtsystem verkauft, wird nach Art. 25 selbst zum Anbieter mit den vollen Pflichten.
Bin ich Anbieter oder Betreiber eines KI-Systems?
Anbieter ist, wer ein KI-System entwickelt oder entwickeln lässt und unter eigenem Namen in Verkehr bringt — er trägt die vollen Hochrisiko-Pflichten inklusive Konformitätsbewertung und CE-Kennzeichnung. Betreiber ist, wer ein KI-System in eigener Verantwortung einsetzt — mit Pflichten wie menschlicher Aufsicht, Kontrolle der Eingabedaten und Log-Aufbewahrung. Achtung: Wer ein Hochrisiko-System wesentlich verändert oder unter eigener Marke vermarktet, wird rechtlich selbst zum Anbieter (Art. 25).
Welche Bußgelder drohen bei Verstößen gegen den AI Act?
Verstöße gegen die verbotenen Praktiken kosten bis zu 35 Mio. € oder 7 % des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist. Verstöße gegen die übrigen Pflichten, etwa die Hochrisiko-Anforderungen, werden mit bis zu 15 Mio. € oder 3 % geahndet; falsche Angaben gegenüber Behörden mit bis zu 7,5 Mio. € oder 1 %. Für KMU gilt jeweils der niedrigere der beiden Beträge.
Wie weise ich die Vertrauenswürdigkeit meines KI-Systems nach — was ist der BSI-Prüfkatalog A5?
Der A5-Prüfkatalog (AI Audit and Assurance Assessment Architecture) des BSI ist der erste deutsche Prüfmaßstab für vertrauenswürdige KI-Systeme. Der Community Draft ist seit dem 7. Juli 2026 öffentlich und kann bis zum 31. August 2026 kommentiert werden. A5 ist modular aufgebaut — ein technologieunabhängiges Trustworthiness-Basismodul plus Betriebsmodule wie Cloud-Infrastruktur mit Querverbindung zum C5-Katalog — und methodisch am Prüfstandard ISAE 3000 orientiert. Die Kriterien erscheinen zusätzlich maschinenlesbar im OSCAL-Format und lassen sich damit in Compliance-Toolchains und CI/CD-Pipelines integrieren. A5 adressiert ausdrücklich die Nachweisanforderungen aus EU AI Act und Cyber Resilience Act.
Weiterführende Informationen.
- EUR-Lex, Amtsblatt der EU
- Europäische Kommission, DG CONNECT
- AI Act Service Desk, Europäische Kommission
- EUR-Lex, Amtsblatt der EU (veröffentlicht 24.07.2026)
- Rat der Europäischen Union
- Bundesnetzagentur
- Bundesministerium für Digitales und Staatsmodernisierung
- EUR-Lex, Amtsblatt der EU
- Future of Life Institute, artificialintelligenceact.eu
- BSI, Bundesamt für Sicherheit in der Informationstechnik
- heise online
Wie geht es bei Ihnen mit dem EU AI Act weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
Intelligisierung: KI in der Fertigung einführen
4-Stufen-Reifegradmodell, Agentic AI und Anwendungsfälle für KI in der industriellen Softwarelieferkette.
NIS2: Wer ist betroffen & wie umsetzen?
Betroffenheitsprüfung, Pflichten nach Art. 21, Meldefristen und Umsetzung in der CI/CD-Pipeline.
Cyber Resilience Act im Maschinenbau
Was der CRA für Hersteller digitaler Produkte bedeutet — Security by Design, SBOM und Update-Pflichten.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance