EU AI Act: Was jetzt in der Praxis zählt

Für den Einstieg in unser Thema würde ich gerne mit einer aus meiner Sicht wenig gewagten These starten: Ja, es macht noch Sinn, sich um die Umsetzung des AI Acts zu kümmern.

Denn ich gehe davon aus, dass wir trotz der Whistleblower-Offenbarungen aus dem Maschinenraum der großen LLM-Anbieter OpenAI und Anthropic die Deadline am 2. Dezember 2027 für Hochrisiko-Systeme im AI Act noch erleben werden. Selbst dann, wenn die CEOs der genannten Unternehmen öffentlich eingestehen, dass sie ihre eigenen Kreationen nicht mehr vollständig im Griff haben.

Das ist allerdings weniger ein Armageddon-Szenario als vielmehr Marketing und der Versuch, Regulierung nach eigenem Ermessen aus staatlicher Hand in die eigene Verantwortung zu überführen. Davon unberührt bleibt jedoch – und umso wichtiger ist – die Tatsache, dass es unbedingt einer globalen Regulierung bedarf, wenn private Konzerne sich anschicken, eine technologische Singularität im Bereich der KI zu verwirklichen. 

Konzentrieren wir uns aber erst einmal auf das, was bisher tatsächlich passiert ist, als scheinbar marodierende Banden entfesselter KI-Agenten in den vergangenen Wochen für Schlagzeilen sorgten.

Beim letzten OpenAI-Vorfall sollten KI-Agenten in einer kontrollierten Testumgebung Aufgaben lösen. Dabei durften sie nur lesend auf das Internet zugreifen. Die Agenten fanden jedoch eine Lücke, um den Lesezugriff zum Schreiben zu missbrauchen. Bereits ab Mai 2026 nutzten sie eine editierbare deutschsprachige Wiki-Plattform als inoffiziellen Kommunikationskanal. Öffentlich bekannt wurde das erst Anfang September 2026, wie eine detaillierte technische Rekonstruktion des Vorfalls zeigt. Technisch war das eher mit unerlaubter Kommunikation oder Spam vergleichbar als mit einem klassischen Hack. Etwas weniger dramatisch also als dargestellt. Für technische Verantwortliche bleibt trotzdem eine konkrete Frage. Wer erkennt die Abweichung, wer stoppt das System, wer sichert die Beweise?

Die technische Grundfrage bleibt dieselbe, ob ein KI-Agent ein Wiki entgegen der Vorgabe nutzt oder ein System in der Produktion außerhalb seiner freigegebenen Betriebsbedingungen agiert. Genau an dieser Stelle wird der EU AI Act praktisch relevant. Nicht jedes KI-System ist hochriskant, und nicht jedes unerwartete Verhalten ist automatisch ein Rechtsverstoß. Aber Zweck, Systemgrenzen, Daten, Tests, Befugnisse und Änderungen müssen so gestaltet sein, dass ein Unternehmen sein System auch dann noch beherrscht, wenn die KI etwas tut, das niemand in das Lastenheft geschrieben hat.
 

Der EU AI Act ordnet Risiken und Marktrollen

Der EU AI Act, Verordnung (EU) 2024/1689, schafft einen einheitlichen Rechtsrahmen für die Entwicklung, das Inverkehrbringen, die Inbetriebnahme und die Nutzung von KI-Systemen in der Europäischen Union. Sein Ziel ist vertrauenswürdige KI, die Gesundheit, Sicherheit und Grundrechte schützt und zugleich Innovation ermöglicht. Der Ansatz ist risikobasiert. Je kritischer der Zweck und je größer das mögliche Schadenspotenzial, desto höher sind die Anforderungen.

Vereinfacht lassen sich verbotene Praktiken, Hochrisiko-KI-Systeme, bestimmte Systeme mit Transparenzpflichten und Anwendungen ohne besondere produktspezifische Pflichten unterscheiden. Ebenso wichtig ist die Marktrolle eines Unternehmens, denn aus ihr ergeben sich zusätzliche Pflichten, je nach Risikokategorie. Vereinfacht gesagt entwickelt oder vermarktet ein Anbieter das KI-System unter eigenem Namen, während ein Betreiber das System im eigenen Verantwortungsbereich nutzt. Ein Produkthersteller wird relevant, wenn KI Bestandteil einer Maschine oder eines anderen regulierten Produkts ist.

Ob ein System in die Hochrisiko-Kategorie fällt, lässt sich auf zwei ganz unterschiedliche Arten begründen. Manchmal entscheidet allein das Einsatzfeld. Bestimmte Bereiche gelten unabhängig von der technischen Umsetzung als hochriskant, wie biometrische Zugangskontrolle zu einem Werksgelände. In anderen Fällen entscheidet die Rolle der KI innerhalb eines Produkts. Steckt sie als Sicherheitskomponente in einem Produkt, dessen Kategorie eine unabhängige Prüfstelle vorschreibt, zieht sie diese Prüfpflicht automatisch mit sich.

Unabhängig von dieser Einstufung gibt es aber noch eine zweite, davon losgelöste Frage. Wer haftet für ein System? Hier kann es entscheidend sein, welche Rolle man innehat, also zum Beispiel Anbieter oder Betreiber. Tückisch daran ist, dass es während des Lebenszyklus unter Umständen zu einem Wechsel der Rolle kommen kann. Wer ein fremdes System wesentlich verändert, kann dadurch selbst vom bloßen Betreiber zum Anbieter werden und übernimmt damit dessen volle Pflichten.
 

Was hat der Digital Omnibus an den Fristen geändert?

Der Digital Omnibus verschiebt Fristen, setzt aber keine Bestandteile aus. Als Änderungsverordnung passt er vor allem die Übergangsfristen für Hochrisiko-Pflichten an. Eigenständige Hochrisiko-Systeme nach Anhang III müssen ab dem 2. Dezember 2027 konform sein. Für KI in bereits regulierten Produkten wie Maschinen gilt eine Frist bis zum 2. August 2028. Alles, was schon vorher galt, bleibt davon unberührt. Verbotene Praktiken etwa gelten seit Februar 2025, ebenso die Pflicht zum Aufbau von KI-Kompetenz bei betroffenen Beschäftigten. Seit August 2026 gelten zusätzlich die Transparenzpflichten, also die Kennzeichnungspflicht für Chatbots, Deepfakes und andere KI-generierte Inhalte. Die Omnibus-Verordnung (EU) 2026/1744 gilt seit dem 27. Juli 2026.
 

Warum ist 2028 zum Beispiel für den Maschinenbau bereits heute relevant?

Die Fristverschiebung sollte als Chance angesehen werden, verlorene Zeit wieder gut zu machen. Denn die Frist 2028 ist bereits heute knapp, weil zum Beispiel Maschinen und andere regulierte Produkte häufig mehrere Jahre von der Konzeption bis zur Serienfreigabe benötigen. Für den Maschinenbau greifen zu allem Überfluss zwei Regelwerke ineinander. Die neue Maschinenverordnung (EU) 2023/1230 gilt ab dem 20. Januar 2027 und löst die bisherige Maschinenrichtlinie ab. Sie regelt unter anderem Produktsicherheit und Konformitätsbewertung von Maschinen und gehört zu den Produktrechtsakten, an die der EU AI Act anknüpft.

Eine für 2028 geplante Maschinengeneration befindet sich daher häufig schon heute in der Entwicklung. Konstruktion, Software, Produktion und Produktsicherheit treffen jetzt Entscheidungen über Sensorik, Systemgrenzen, Rückfallebenen und Prüfkonzepte, die später nur noch teuer geändert werden können. Wer erst kurz vor der Serienfreigabe nach dem EU AI Act fragt, fragt gegebenenfalls zu spät.
 

Wann wird KI in einer Maschine zum Hochrisiko-KI-System?

KI in einer Maschine wird nicht automatisch zum Hochrisiko-System. Entscheidend ist, ob sie nur einen Prozess unterstützt oder eine Sicherheitsfunktion übernimmt, die Gesundheit oder Sicherheit von Personen schützt. Ebenso wichtig ist, ob das geltende Produktrecht, etwa die neue Maschinenverordnung, für das Produkt eine externe Prüfung vorschreibt. Der Digital Omnibus hat die erste Frage präzisiert. Reine Assistenz, Leistungsoptimierung oder nicht sicherheitsbezogene Qualitätskontrolle zählt nicht als Sicherheitsfunktion, solange ihr Ausfall keine Gefahr auslöst. Eine optische Prüfung, die nur Ausschuss reduziert, fällt deshalb unter diese Ausnahme. Ein System, das einen gefährlichen Maschinenzustand erkennt und eine Schutzfunktion auslöst, fällt nicht darunter. Maßgeblich ist der bestimmungsgemäße Zweck, nicht das verwendete Modell. Diese Einordnung gehört dokumentiert, bevor Architektur und Tests feststehen.

Auch danach folgt nicht automatisch eine notifizierte Stelle, also eine unabhängige, staatlich benannte Prüforganisation. Die KI-Anforderungen werden in das bestehende produktrechtliche Verfahren integriert, es entsteht keine zweite Prüfschiene. Ob eine externe Prüfung nötig wird, hängt vom jeweiligen Produktrecht ab. Manche Kategorien verlangen sie, andere lassen eine interne Konformitätserklärung zu. KI-Entwicklung, Produktsicherheit und Compliance sollten das Verfahren deshalb gemeinsam klären.
 

Welche Nachweise müssen Ingenieur*innen tatsächlich liefern?

Ist ein System als hochriskant eingestuft, zählt am Ende nur, ob Zweck, Daten, Leistung, Risiken, menschliche Aufsicht und spätere Änderungen über den gesamten Lebenszyklus tatsächlich beherrscht werden. Dieser Nachweis entsteht in Anforderungen, Architekturentscheidungen und Prüfplänen.

Risiken sollen zuerst durch die Gestaltung reduziert werden, nicht erst durch Warnhinweise danach. Ein anderer Sensor oder eine sichere Rückfallebene wirkt oft mehr als eine zusätzliche Seite in der Betriebsanleitung. Bei den Daten reicht ein Gesamtwert über alle Fälle selten. Eine optische Qualitätsprüfung etwa sollte nach Fehlerklasse, Beleuchtung und Produktvariante aufgeschlüsselt werden, nicht nur im Mittel bewertet.

Robustheit und menschliche Aufsicht gehören zu den verbindlichen Anforderungen an Hochrisiko-Systeme. Für Robustheit gibt es dabei keine vorgeschriebene Methode. Adversarial Testing, bei dem das System gezielt mit manipulierten Eingaben konfrontiert wird, sowie Stresstests sind geeignete Nachweise, wenn sie aus dem Risikomodell folgen. Klassische OT-Security allein deckt modellspezifische Angriffe wie Datenmanipulation nicht zwangsläufig ab. Menschliche Aufsicht ist selbst eine Systemfunktion. Qualifizierte Personen müssen eingreifen und das System über eine tatsächliche Stopp-Funktion anhalten können, auch gegen die Neigung, automatisierten Ausgaben blind zu vertrauen. Bedienoberfläche, Alarmierung und Entscheidungsbefugnis gehören deshalb gemeinsam getestet.
 

Eine Evidence Chain verbindet Entwicklung und Betrieb

Technische Dokumentation und eine kontinuierliche Überwachung über den gesamten Lebenszyklus sind für Hochrisiko-Systeme gesetzlich vorgeschrieben. Eine belastbare Evidence Chain macht diese Überwachung erst aussagekräftig, denn ohne nachvollziehbare Historie lässt sich eine Abweichung im Betrieb nicht auf ihre Ursache zurückführen. Sie verknüpft jede wesentliche Anforderung mit Risikoanalyse, Daten- und Modellversion, Prüfung, Abweichung und Freigabeentscheidung. Nach einem Update oder Vorfall muss erkennbar bleiben, welcher Entwicklungsstand tatsächlich eingesetzt wurde und auf welcher Grundlage die Freigabe erfolgte. Experiment-Tracking und eine Model Registry helfen dabei, decken aber die Anforderungen an die technische Dokumentation nicht vollständig ab.

Diese Überwachung braucht eine technische Grundlage. Protokollierung ist deshalb keine administrative Nebenfrage. Wer entscheidet, ob Eingaben, Ausgaben, Konfidenzwerte, Modellversionen, Zeitstempel und menschliche Eingriffe gespeichert werden, trifft eine Architekturentscheidung mit Folgen für Fehleranalyse, Datenschutz und Auditierbarkeit. Was nie erfasst oder später überschrieben wurde, kann auch das beste Audit nicht rekonstruieren.

Die Nachweiskette endet nicht am Werkstor. Lieferverträge sollten erforderliche Systeminformationen, Testzugänge, Leistungsgrenzen, bekannte Fehlermodi, Updatehinweise und Unterstützung bei Vorfällen absichern. Ein fehlender technischer Zugang oder ein ungeklärtes Prüfungsrecht ist vor der Freigabe ein Projektrisiko und nicht erst bei der Konformitätsbewertung.
 

Wie gelingt KI-Governance ohne neue Parallelbürokratie?

Wer bestehende Entwicklungs-, Qualitäts-, Cybersecurity- und Compliance-Prozesse nutzt und nur nachweislich fehlende KI-Kontrollen ergänzt, kommt mit deutlich weniger Aufwand und Redundanzen zum selben Ziel. Aus eigener Erfahrung hat sich dafür eine einfache Reihenfolge bewährt, die ich Reuse, Extend, Create nenne. Zuerst wird geprüft, ob ein vorhandener Prozess die neue Anforderung bereits abdeckt. Reicht das nicht, wird der Prozess gezielt erweitert. Erst wenn beides nicht greift, entsteht etwas komplett Neues. Diese Reihenfolge spart nicht nur Aufwand, sie hält auch die Anzahl der Stellen klein, an denen später etwas übersehen werden kann. Zuständigkeiten, Freigaben und Überwachung werden damit in Prozesse integriert, die technische Teams bereits kennen. Der EU AI Act sollte früh an vorhandene Quality Gates andocken, statt neben dem etablierten Entwicklungsprozess ein zweites Freigabesystem aufzubauen. Mehr Formulare schaffen noch keine bessere Kontrolle.

Der zwingende Ausgangspunkt ist der Start eines kontinuierlichen Inventars aller entwickelten, bezogenen und eingesetzten KI-Systeme. Für jedes System sollten unter anderem Zweck, Eigentümer, Marktrolle, Einsatzort, betroffene Personen und eine begründete vorläufige Risikoklasse feststehen. Neue Systeme und wesentliche Änderungen müssen automatisch in diesen Prozess gelangen und dürfen nicht erst bei einer jährlichen Bestandsaufnahme sichtbar werden.
 

EN 18286, ISO/IEC 42001 und NIST geben Orientierung

Aus der reinen Compliance Brille betrachtet und mit Blick auf den EU AI Act, bedarf es keines umfassenden KI-Managementsystem. Denn dieses ist mehr als ein Compliance- oder Governance-Werkzeug. Es ist der Rahmen, in dem aus einer KI-Strategie tatsächlich stabile und wertschöpfende KI-Systeme im Betrieb werden. Verantwortung führt darin zu Entscheidungen, Entscheidungen werden zu Controls und Lifecycle-Vorgaben, und deren Wirksamkeit wird laufend überwacht. Dieses Zusammenspiel gibt der gesamten KI-Governance eines Unternehmens Struktur, über das gesamte Portfolio hinweg, nicht nur für ein einzelnes System. Von daher ist meine persönliche und unbedingte Empfehlung, die Umsetzung des AI Act als Initial für die Implementierung eines KI-Managementsystem zu nutzen.  

Dieses sollte auf internationalen Normen und Standards fußen. Die im Juli 2026 veröffentlichte EN 18286:2026 konkretisiert ein Qualitätsmanagementsystem für regulatorische Zwecke des EU AI Acts, insbesondere mit Blick auf die Pflicht der Anbieter, ein solches System zu betreiben. ISO/IEC 42001:2023 bietet einen internationalen organisationsweiten Rahmen für Aufbau, Betrieb und Verbesserung eines KI-Managementsystems. ISO 42001 diente zudem als Vorlage für den chinesischen Standard GB/T 45081.

Es bedarf aber auch einer weitergehenden technischen Sicht und entsprechende Plattformen für AI Governance bilden dies ab, mit einem zentralen Inventar aller Systeme samt Risikoklasse, mit Controls, die für mehrere Regelwerke gleichzeitig zählen, und mit einer Anbindung an bestehende Entwicklungswerkzeuge statt separater Bürokratie. 

Ob daraus letztendlich ein stabiles, wertschöpfendes System wird, entscheidet sich aber nicht im Tool und nicht im Steering Committee, sondern in der technischen Umsetzung selbst. Oder, um es mit Adi Preißler zu sagen: „Grau is' alle Theorie, entscheidend is' auf'm Platz."
 

Was am Ende zählt

Die Frist bis 2028 wirkt lang. Das täuscht, und zwar nicht nur im Maschinenbau. Wer die Vorteile einer frühen KI-Governance tatsächlich nutzen will, muss jetzt anfangen, nicht erst kurz vor der jeweiligen Deadline. Das gilt branchenübergreifend für alle, die mehr wollen als das bloße Abhaken von Pflichten.

Ohne echte technische Substanz bleibt jedes noch so vollständige KI-Managementsystem nur Governance-Theater. Es sieht auf dem Papier fertig aus und hält im Ernstfall trotzdem nicht. Wer erkennt die Abweichung, wer stoppt das System, wer sichert die Beweise? Diese Fragen aus dem Anfang dieses Textes lassen sich nicht mit einem Formular beantworten. Es braucht ein System, das echte Antworten liefert, bevor der Ernstfall eintritt. 
 

Checkliste für einen Jumpstart

1. Benenne alle relevanten Stakeholder, etwa aus Entwicklung, Produktion, Qualitätsmanagement, IT-Sicherheit, Einkauf und Recht
2. Starte das Projekt mit einem Workshop, in dem das Ziel festgelegt wird. Geht es nur um Compliance, oder soll gleich ein strategisches KI-Managementsystem entstehen?
3. Am Anfang steht eine Bestandsaufnahme. Wo steht Dein Unternehmen bei KI? Gibt es eine Strategie, oder nur vereinzelte Piloten?
4. Kläre schon jetzt bestehende Bedenken, etwa zu Sicherheit, Verletzung von Rechten an geistigem Eigentum, Schatten-KI oder amoklaufenden Agenten
5. Starte die Inventur und etabliere  sie direkt als Prozess für eine permanente Erfassung
6. Denke parallel dazu über die IT-Architektur nach, in der künftig alle relevanten Informationen zusammenlaufen
7. Bilde ein "First-Aid-Team". Teile des AI Acts sind bereits verbindlich. Das Verbot bestimmter Systeme etwa kann bei Missachtung bis zu 7 Prozent des globalen Umsatzes kosten
8. Analysiere parallel zur laufenden Inventur jeden Fall nach den Risikokategorien des AI Acts, und lege Maßnahmen bei möglichen Verstößen fest
9. Sobald die dringendsten Compliance-Probleme im Blick sind und angegangen werden, richte das Projekt strategischer aus
10. Beziehe alle Mitarbeitenden ein. KI wird Ihr Unternehmen verändern, und diese Transformation gelingt nur, wenn alle Teil davon sind