EU AI Act: Konkrete Umsetzungsschritte für IT- und Produktionsleiter bis August 2026

Warum Produktions- und IT-Leiter jetzt eine operative AI-Act-Roadmap brauchen

Wenn Ihre Produktions-KI auf unvollständige Echtzeitdaten zugreift, hilft keine juristische Debatte. Dann fehlt der operative Nachweis, welche Daten ein Modell tatsächlich gesehen hat, wo seine Grenzen liegen und wer eine Entscheidung im Störfall nachvollziehen kann. Genau hier liegt der Druck für Produktions- und IT-Leiter: Der AI Act ist seit dem 1. August 2024 in Kraft getreten; die Verordnung gilt jedoch nicht für alle Pflichten gleichzeitig, sondern gestaffelt. [1]

Für die Praxis bedeutet das: Wer KI-Systeme in Produktion, Instandhaltung, Qualitätsprüfung oder Planung einsetzt, braucht jetzt eine Roadmap, die nicht bei der Regellage stehen bleibt. Ein Großteil der Bestimmungen wird ab dem 2. August 2026 relevant. [2] Bis dahin bleibt wenig Zeit, um KI-Anwendungen zu inventarisieren, Verantwortlichkeiten zu ziehen und die technische Dokumentation so aufzubauen, dass sie im Betrieb belastbar ist. Dieser Beitrag liefert allgemeine Informationen und ersetzt keine individuelle Rechtsberatung; lassen Sie die konkrete Einordnung durch Legal oder Compliance prüfen.

Der AI Act arbeitet risikobasiert. Er unterscheidet vier Risikoklassen: unannehmbares Risiko, hohes Risiko, begrenztes Risiko und minimales Risiko. Zusätzlich gibt es eine Kategorie für General-Purpose AI. [1] Für IT- und Produktionsleiter ist diese Einordnung kein theoretisches Thema. Sie entscheidet darüber, ob ein System verboten ist, Transparenzpflichten auslöst oder bei hohem Risiko Sicherheits-, Qualitäts- und Konformitätsnachweise braucht. [1]

Was viele Projektteams unterschätzen: Produktions-KI scheitert in der Umsetzung selten an der Modellarchitektur. Sie scheitert an Schnittstellen, Datenqualität und unklaren Betriebsgrenzen. Wenn Sensordaten aus der Linie, Stammdaten aus dem ERP und manuelle Eingriffe aus der Schicht nicht sauber zusammenlaufen, entsteht keine verlässliche Grundlage für Compliance oder Betriebssicherheit. Genau deshalb muss die Roadmap technisch beginnen und nicht mit einem reinen Policy-Dokument.

Was der Zeitplan für die operative Umsetzung bedeutet

Der erste Fehler ist, den AI Act wie ein reines Stichtagsprojekt zu behandeln. Das Gesetz gilt bereits, aber die operative Wirkung entfaltet sich gestaffelt. [1] Für Ihr Team heißt das: Nicht auf den letzten Regeltermin warten, sondern jetzt die Systeme priorisieren, die in kritische Produktions- und Steuerungsprozesse eingreifen. Eine spätere Nachdokumentation kostet dann meist mehr Zeit als die saubere Erfassung im laufenden Betrieb.

Warum die Risikoklasse die Projektlogik vorgibt

Die Risikoklasse bestimmt, ob Sie zuerst Transparenz, Governance oder technische Nachweise aufbauen. Bei minimalen Risiken genügt oft eine schlanke Steuerung. Bei hohem Risiko müssen Sie deutlich tiefer in Qualität, Sicherheit und Konformität einsteigen. [1] Für die Roadmap heißt das: Jede KI-Anwendung braucht eine erste operative Zuordnung. Ohne diese Zuordnung werden Budget, Ressourcen und Verantwortlichkeiten im Zweifel falsch verteilt.

Schritt 1: KI-Landschaft im Betrieb inventarisieren und Risikoklassen zuordnen

Bevor Sie über Kontrollen, Schulungen oder Dokumentationspflichten sprechen, brauchen Sie ein vollständiges Bild der KI-Systeme im Betrieb. Der AI Act arbeitet risikobasiert und unterscheidet vier Kategorien: unannehmbares Risiko, hohes Risiko, begrenztes Risiko und minimales Risiko. Zusätzlich erfasst er General-Purpose AI als eigene Kategorie. [1] Für IT- und Produktionsleiter ist das die operative Startlinie. Ohne Inventur bleibt offen, welche Anwendungen überhaupt in den Anwendungsbereich fallen und welche Systeme Sie zuerst priorisieren müssen.

Erfassen Sie deshalb nicht nur offensichtliche KI-Tools, sondern auch versteckte Einsatzpunkte in Produktions-IT und OT. Dazu zählen Planungsassistenz, Qualitätsprüfung, Instandhaltungslogik, Anomalieerkennung, Schichtunterstützung und Modelle in angebundenen Plattformen. Gerade GPAI-Modelle brauchen besondere Aufmerksamkeit, weil sie Transparenz- und Dokumentationspflichten auslösen können. [3] Ab dem 2. August 2026 greifen für viele dieser Pflichten die maßgeblichen Umsetzungsregeln. [2]

Wer hier sauber arbeitet, spart später Aufwand. Die Frage ist nicht, ob ein Tool „KI“ im Marketing-Sinn ist. Entscheidend ist, ob das System im Betrieb Entscheidungen vorbereitet, beeinflusst oder automatisiert. Genau daran hängt die spätere Compliance-Logik.

Inventur-Checkliste für Produktions-IT

Starten Sie mit einer technischen Erfassung aller Systeme, die Modelle nutzen, einbetten oder über Schnittstellen auf KI-Funktionen zugreifen. Prüfen Sie pro Anwendung vier Punkte: Welcher Systemtyp läuft in der Produktion oder in der angrenzenden IT? Welche Datenquellen speisen das System? Läuft ein eigenes Modell oder ein externer Dienst? Und in welchem Einsatzkontext entscheidet das System mit — etwa im Shopfloor, in der Qualitätssicherung oder in der Planung? Diese vier Blickrichtungen reichen meist aus, um Schatten-IT und unklare Modellnutzung sichtbar zu machen.

Wichtig ist auch die Zuordnung zur Betriebsrealität. Ein Modell, das nur Prognosen liefert, hat ein anderes Risikoprofil als ein System, das Maschinenparameter direkt beeinflusst. Halten Sie deshalb je Anwendung fest, wer fachlich verantwortet, wer technisch betreibt und wo das System produktiv eingreift. Nur so lässt sich später belastbar begründen, warum eine Anwendung als geringes oder erhöhtes Risiko behandelt wurde.

Risikoprüfung anhand AI-Act-Kategorien

Nach der Inventur folgt die Einordnung nach Wirkung. Der AI Act unterscheidet vier Risikokategorien und verlangt damit keine pauschale, sondern eine anwendungsbezogene Bewertung. [1] Für die Praxis heißt das: Sie bewerten nicht zuerst die Technologie, sondern die potenziellen Auswirkungen im Betrieb. Eine KI, die nur bei der Priorisierung von Wartungsaufträgen unterstützt, landet anders als ein System, das sicherheitsrelevante Produktionsprozesse steuert oder Entscheidungen mit unmittelbaren Folgen für Menschen und Anlagen vorbereitet.

Für High-Risk-Szenarien sollten Sie besonders strikt prüfen, ob das System in sensible Prozesse eingreift, ob Fehlentscheidungen Schäden auslösen können und ob eine spätere Konformitätsprüfung realistisch dokumentierbar ist. Systeme mit allgemeinem Verwendungszweck gehören ebenfalls auf die Liste, weil sie Transparenz- und Dokumentationspflichten mitbringen können. [3] Mit dieser Zuordnung steht fest, welche Anwendungen überhaupt reguliert sind; im nächsten Schritt bauen Sie die Dokumentation auf.

Schritt 2: Daten- und Modelltransparenz herstellen – Kernanforderung bis August 2026

Wenn ein Modell in der Qualitätssicherung Fehler markiert, reicht das Ergebnis allein nicht aus. Sie müssen auch zeigen, welche Eingangsdaten das System gesehen hat, wie es zu seiner Entscheidung kam und wo seine Grenzen liegen. Genau hier setzt die Transparenzpflicht an: Sie verlangt, dass Unternehmen Funktionsweise, Grenzen, Trainingsdaten, Systementscheidungen und mögliche Risiken ihrer KI-Lösungen dokumentieren und offenlegen. [4] Für High-Risk-Systeme verlangt der AI Act zusätzlich transparente, qualitätsgesicherte Dokumentation und Sicherheits- sowie Qualitätsobligationen. [1]

Für IT- und Produktionsleiter ist das kein Papierprojekt. Ohne nachvollziehbare Daten- und Modellspur lässt sich später weder ein Prüfpfad noch eine belastbare Fehleranalyse aufbauen. Wer bis August 2026 compliant sein will, braucht daher eine Dokumentation, die im Betrieb gepflegt wird und nicht erst im Audit zusammengetragen wird. Dieser Beitrag liefert allgemeine Orientierung; die konkrete Rechtslage sollte Legal oder Compliance im Einzelfall prüfen.

Dokumentationspaket für Produktions-KI

Ein brauchbares Dokumentationspaket beginnt bei den Parametern. Halten Sie fest, welche Eingangsgrößen das Modell verarbeitet, welche Schwellenwerte es nutzt und welche Grenzfälle es nicht zuverlässig abdeckt. Ergänzen Sie die Herkunft der Trainingsdaten. Ohne diese Herkunft bleibt unklar, ob das Modell auf Produktionsdaten, simulierten Daten oder externen Datensätzen basiert. Genau diese Nachvollziehbarkeit ist für Transparenz und spätere Prüfungen entscheidend. [4]

Für die Praxis heißt das: Wenn Ihre Produktions-KI die Oberflächenqualität überwacht, dokumentieren Sie nicht nur das Modell, sondern auch die Fehlergrenzen, die Alarmschwellen und den Pfad vom Sensorwert bis zur Meldung im Shopfloor-System. Nur so kann ein Fachbereich später prüfen, ob ein Fehlalarm aus einer harten Grenze, einer Datenabweichung oder einem Modellfehler entstand.

Datenqualität absichern

Transparenz scheitert oft nicht am Modell, sondern an der Datenbasis. Wenn Stammdaten, Sensordaten und manuelle Nachträge aus unterschiedlichen Systemen kommen, entstehen Brüche, die jede spätere Dokumentation schwächen. Wer das sauber aufsetzen will, braucht Data Governance in Unternehmen als technische und organisatorische Grundlage. Vertiefend dazu passt der interne Leitfaden zu Data Governance in Unternehmen.

Arbeiten Sie deshalb mit klaren Verantwortlichkeiten für Datenfreigabe, Änderungsprotokolle und Validierungsregeln. Für Produktionsumgebungen ist besonders wichtig, dass Abweichungen früh erkannt werden. Ein Modell, das mit unplausiblen Werten gefüttert wird, produziert zwar weiter Ergebnisse, aber die Transparenz darüber geht verloren. Die AI-Act-Logik verlangt gerade bei risikoreichen Systemen eine belastbare Dokumentation der Qualität und der Entscheidungsgrundlagen. [1]

Wenn Sie Datenqualität und Modellgrenzen parallel absichern, schaffen Sie die Basis für die nächste Stufe: eine Governance, die technisch und organisatorisch trägt.

Schritt 3: Kompetenzen und Verantwortlichkeiten nach Artikel 4 aufbauen

Wenn ein Modell im Shopfloor falsche Prioritäten setzt oder ein OT-Interface ungewöhnliche Werte weiterreicht, hilft keine nachträgliche Diskussion über Zuständigkeiten. Artikel 4 verlangt, dass Anbieter und Betreiber von KI die nötigen Kompetenzen sicherstellen; laut Dossier tritt diese Pflicht am 5. Februar 2025 in Kraft. [5] Für Produktions- und IT-Leiter heißt das: Sie brauchen keine abstrakte Schulungsinitiative, sondern eine belastbare Zuordnung von Wissen, Freigaben und Eskalationswegen. Das ist besonders relevant für Teams, die Modelle trainieren, parametrieren, warten oder in Produktions- und OT-Systeme integrieren.

Wer diese Pflicht ernst nimmt, trennt fachliche Bedienung von technischer Verantwortung. Ein Schichtleiter darf ein KI-gestütztes Wartungssignal lesen. Er muss aber nicht die Modellgrenzen auditieren. Genau diese Trennung verhindert Fehlbedienung und macht den Betrieb prüffähig.

Kompetenzmatrix für Produktions-IT

Eine Kompetenzmatrix funktioniert nur, wenn sie an realen Aufgaben hängt. Definieren Sie für jede Rolle, welche Schulungsfelder sie abdecken muss: grundlegendes Modellverständnis, Grenzen und Fehlermuster, Datenqualität, Freigabelogik und Umgang mit Abweichungen. Für Teams in der Produktions-IT gehört auch das Verständnis für Schnittstellen, Latenzen und Rückfallebenen dazu. Wer ein Modell in eine OT-Umgebung einbindet, muss wissen, wie sich Ausfälle, falsche Schwellenwerte oder fehlerhafte Eingabedaten im Prozess bemerkbar machen. Ohne dieses Wissen bleibt die KI zwar nutzbar, aber nicht kontrollierbar. [5]

Praktisch bewährt sich eine Dreiteilung: Basiswissen für alle Nutzer, vertieftes Fachwissen für Modellverantwortliche und technisches Spezialwissen für Betrieb und Integration. So vermeiden Sie, dass dieselben Schulungen für Operator, Data Engineer und Produktionsleiter durchlaufen werden, obwohl die Risiken und Aufgaben unterschiedlich sind.

RACI-Mapping für KI-Systeme

Nach der Kompetenzmatrix braucht jedes KI-System ein klares Rollenbild. Legen Sie pro Anwendung fest, wer die Validierung verantwortet, wer die Wartung freigibt und wer Risikoanalysen anstößt. In vielen Betrieben scheitert Compliance nicht an fehlender Technik, sondern an unklaren Zuständigkeiten zwischen Fachbereich, IT und Produktion. Ein RACI-Mapping schafft hier Ordnung: Der Fachbereich entscheidet über den betrieblichen Nutzen, die IT verantwortet technische Stabilität, und ein benannter Owner koordiniert Änderungen, Dokumentation und Eskalationen.

Besonders wichtig ist das bei Systemen mit direktem Einfluss auf Produktionsentscheidungen. Wenn ein Modell in der Qualitätssicherung, Instandhaltung oder Planung arbeitet, muss klar sein, wer Abweichungen bewertet und wer im Ernstfall den Betrieb auf eine manuelle Alternative umstellt. Nur so lässt sich die spätere Compliance-Pipeline für High-Risk-Szenarien ohne Reibungsverluste aufbauen. Mit Rollen und Skills geklärt, geht es im nächsten Schritt an das technische Compliance-Setup bis August 2026.

Schritt 4: Technische Compliance-Pipeline für High-Risk-Szenarien implementieren

Wenn Ihre Produktions-KI direkt in Freigaben, Priorisierungen oder Qualitätsentscheidungen eingreift, genügt ein nachträgliches Compliance-Review nicht. High-Risk-Systeme brauchen laut Dossier Sicherheits-, Qualitäts- und Transparenzauflagen sowie eine Konformitätsbewertung. [1] Genau deshalb sollten Sie die Compliance nicht als Endkontrolle, sondern als Pipeline aufsetzen: vom ersten Modell-Release bis zur Freigabe in OT- und ERP-Ketten.

Für die operative Praxis heißt das: Jede Änderung am Modell, an der Datenquelle oder an der Schnittstelle muss einen prüffähigen Fußabdruck erzeugen. Die EU-Kommission legt die Klassifizierungsregeln für High-Risk-KI fest, und diese Einordnung entscheidet darüber, wie streng Sie dokumentieren, testen und freigeben müssen. [2] Wer das erst kurz vor dem Stichtag baut, produziert Lücken zwischen Entwicklung, Produktion und Betrieb.

Technische Pflichtmodule für High-Risk-KI

Eine belastbare Compliance-Pipeline braucht drei technische Pflichtmodule: Monitoring, Logging und Audit Trails. Monitoring zeigt Ihnen, ob das Modell im laufenden Betrieb driftet oder auffällige Muster erzeugt. Logging hält Eingaben, Ausgaben und relevante Systemereignisse fest. Audit Trails verbinden diese Ereignisse mit Versionen, Freigaben und Änderungen. Ohne diese Kette lässt sich später nicht nachweisen, warum das System eine Entscheidung getroffen hat. Das ist besonders relevant, wenn eine KI in der Produktionsplanung, Instandhaltung oder Qualitätssicherung sitzt und ihre Ausgabe in nachgelagerte Systeme weiterreicht. [1]

Für IT- und Produktionsleiter ist wichtig, dass diese Module nicht nur im KI-Stack laufen, sondern auch in den angeschlossenen OT- und ERP-Prozessen sichtbar bleiben. Wenn ein Alarm aus der Linie im ERP eine Folgeaktion auslöst, brauchen Sie dieselbe Nachvollziehbarkeit über Systemgrenzen hinweg. Sonst bleibt der Audit Trail an der Schnittstelle stecken.

Ein ergänzender Blick auf KI-Sicherheitsrisiken im Unternehmen hilft, die technische Absicherung von KI-Agenten und automatisierten Workflows im Betrieb früh mitzudenken.

Teststrategie: Konformität simulieren

Konformität sollte nicht erst im Produktivsystem geprüft werden. Simulieren Sie stattdessen frühzeitig die Bewertungslogik, die später für die Freigabe zählt. Dazu gehören Testfälle für Grenzwerte, fehlerhafte Eingaben, Ausfälle von Schnittstellen und unplausible Rückmeldungen aus der Produktion. Nur wenn Sie diese Fälle durchspielen, sehen Sie, ob Ihr System transparent reagiert oder ob es kritische Schritte verschluckt. Für High-Risk-Szenarien reicht reine Funktionstests also nicht aus; Sie brauchen Testabdeckung für die komplette Produktions-KI-Kette. [1]

Praktisch bewährt sich ein Testplan mit drei Ebenen: Erstens die Modellantwort selbst. Zweitens die Reaktion der angebundenen Systeme. Drittens die Dokumentation der Entscheidung. Wenn Ihre Produktions-KI zum Beispiel eine Qualitätsabweichung meldet, muss der Test zeigen, ob das Ereignis im OT-System ankommt, im ERP korrekt weiterverarbeitet wird und im Audit Trail nachvollziehbar bleibt. So prüfen Sie nicht nur das Modell, sondern die echte Betriebsfähigkeit unter Compliance-Bedingungen.

Nach der technischen Einrichtung folgt die Gesamtplanung bis zum Stichtag. Dann geht es um Reihenfolge, Ressourcen und Meilensteine.

Schritt 5: Roadmap bis 2. August 2026 erstellen – Priorisierung, Meilensteine, Ressourcen

Wenn Sie die AI-Act-Umsetzung erst als spätes Compliance-Projekt behandeln, verlieren Sie Zeit an Schnittstellen statt an der Sache. Ein Großteil der Bestimmungen gilt ab dem 2. August 2026. [2] Für IT- und Produktionsleiter heißt das: Die Roadmap muss jetzt entlang der operativen Eintrittsfristen stehen. Planen Sie nicht nur das KI-System, sondern auch die Datenflüsse, die BI-Infrastruktur und die Governance der beteiligten Fachbereiche mit ein. Sonst bauen Sie ein Prüfkonzept, das im Alltag nicht anschlussfähig ist.

Die Reihenfolge sollte mit den Systemen beginnen, die in Produktion, Qualität oder Instandhaltung unmittelbar Entscheidungen beeinflussen. Danach folgen Transparenz, Dokumentation und die Einbindung in bestehende Data-Governance-Prozesse. Wer BI-Plattformen bereits als zentrale Datenquelle nutzt, sollte diese früh einbeziehen, weil dort oft die Kennzahlen, Freigaben und Reportings zusammenlaufen. So vermeiden Sie Doppelarbeit zwischen Fachbereich, Produktions-IT und Governance-Team. [3]

Ressourcen- und Budgetplan

Eine belastbare Aufwandsschätzung trennt Projektarbeit, Betrieb und Nacharbeit. Rechnen Sie mit Ressourcen für Inventarisierung, Datenaufbereitung, Dokumentation, Testläufe und Schulung. Wenn Data Governance bisher nebenbei lief, braucht sie jetzt feste Kapazitäten, weil Stammdatenqualität, Freigabeprozesse und Verantwortlichkeiten sonst auseinanderlaufen. Dasselbe gilt für BI-Infrastruktur: Berichte, Kennzahlen und Nachweise müssen dieselben Datenstände verwenden wie das operative System. Nur so bleibt die Compliance-Prüfung konsistent. [3]

Für die Budgetierung ist ein schlankes Modell sinnvoll: Pflichtaufwand für alle KI-Systeme, Zusatzaufwand für Systeme mit höherem Risiko und Reserven für Schnittstellenkorrekturen. Diese Reserve ist wichtig, weil viele Kosten nicht im Modell selbst entstehen, sondern in der Kopplung an ERP, OT und Reporting. Wer das zu knapp kalkuliert, verschiebt die Probleme nur in die Betriebsphase.

Meilensteinplan bis August 2026

Setzen Sie Ihre Meilensteine entlang der verbleibenden Arbeitsschritte. Zuerst kommt die vollständige Inventarisierung aller KI-Anwendungen. Danach ordnen Sie die Systeme den relevanten Risikoklassen zu und prüfen, welche Transparenz- und Dokumentationspflichten daraus folgen. Im nächsten Schritt schließen Sie die Daten- und Modelltransparenz, bevor Sie die Kompetenzanforderungen nach Artikel 4 im Betrieb verankern. [1][5]

Erst wenn diese Basis steht, sollten Sie die technische Compliance-Pipeline für High-Risk-Szenarien ausrollen und die Betriebsfreigabe an feste Kontrollen binden. Für die Priorisierung hilft ein einfacher Entscheidungsfilter: Was Produktion, Qualität oder Sicherheit unmittelbar beeinflusst, landet in der ersten Welle. Was nur unterstützend arbeitet, folgt danach. So sichern Sie die knappen Ressourcen dort, wo das Risiko für Betrieb und Umsetzung am höchsten ist. Zum Abschluss folgt ein klarer Handlungsappell inklusive Checklisten-Hinweis.

Fazit: Jetzt handeln – und die Checkliste zur AI-Act-Umsetzung nutzen

Wer die AI-Act-Umsetzung erst 2026 anstößt, arbeitet gegen die Uhr. Die Verordnung ist seit dem 1. August 2024 in Kraft getreten; die Pflichten greifen jedoch gestaffelt, und viele operative Anforderungen werden ab dem 2. August 2026 relevant. [1][2] Für IT- und Produktionsleiter bedeutet das: Nicht der Stichtag ist das Problem, sondern die Vorlaufzeit für Inventarisierung, Risikozuordnung, Transparenz, Kompetenzaufbau und technische Freigabe.

Die richtige Reihenfolge ist klar. Erst verschaffen Sie sich einen vollständigen Überblick über alle KI-Anwendungen im Betrieb. Dann ordnen Sie die Systeme den relevanten Risikoklassen zu. Danach schaffen Sie Transparenz über Daten, Modelle und Entscheidungen. Parallel bauen Sie die KI-Kompetenz nach Artikel 4 im Team auf. Anschließend sichern Sie High-Risk-Szenarien über eine technische Compliance-Pipeline ab. [1][5] Wer diese Schritte in der falschen Reihenfolge angeht, produziert Lücken zwischen Fachbereich, Produktions-IT und Governance.

Für die Praxis zählt jetzt vor allem die Priorisierung. Beginnen Sie mit Systemen, die direkt auf Qualität, Verfügbarkeit oder Sicherheitsentscheidungen wirken. Prüfen Sie danach, welche Dokumentations- und Transparenzanforderungen in den angebundenen Datenflüssen stecken. So vermeiden Sie, dass die Compliance nur auf dem Papier funktioniert, aber im Shopfloor oder in der IT-Landschaft bricht. Die operative Umsetzung bleibt damit beherrschbar und planbar. [3]

Wenn Sie daraus einen belastbaren Projektstart machen wollen, nutzen Sie die Checkliste zur AI-Act-Vorbereitung bis August 2026 als Nächstes. Sie hilft Ihnen, die offenen Punkte systematisch zu erfassen, Verantwortlichkeiten zuzuordnen und den Umsetzungsstand gegenüber der Geschäftsleitung nachvollziehbar zu machen. Für IT- und Produktionsleiter ist das der schnellste Weg, aus einer abstrakten Regulierung ein steuerbares Programm zu machen.