EU AI Act 2026: Was sich durch den Aufschub ändert und was weiterhin gilt

Am 27. Juli 2026 trat der Digital Omnibus on AI, die Verordnung (EU) 2026/1744, in Kraft und änderte den Zeitplan des EU AI Act. Die Anforderungen für Hochrisiko-KI-Systeme, die ursprünglich ab dem 2. August 2026 gelten sollten – darunter die Meldepflicht für schwerwiegende Vorfälle gemäß Artikel 73 –, gelten nun erst ab dem 2. Dezember 2027 für eigenständige Hochrisiko-KI-Systeme (Anhang III) und ab dem 2. August 2028 für KI-Systeme, die in regulierte Produkte integriert sind (Anhang I). 

Nicht alles wurde verschoben: Seit dem 2. August 2026 gelten die Transparenzpflichten nach Artikel 50, und die Kommission kann gegen Anbieter von KI-Modellen mit allgemeinem Verwendungszweck Geldbußen verhängen. Die seit August 2025 geltenden Verpflichtungen für GPAI – einschließlich der Meldepflicht für schwerwiegende Vorfälle bei Modellen mit systemischem Risiko – bleiben unverändert in Kraft.

Aufgeschoben, aber nicht aufgehoben. Die zusätzlichen 16 Monate sind das Zeitfenster, um die Meldung schwerwiegender Vorfälle in die eigenen Betriebsprozesse zu integrieren – und kein Grund, das Thema auf Eis zu legen. Im Folgenden erklären wir, was sich geändert hat, was unverändert bleibt und was Ihr Incident-Prozess künftig leisten muss.

‍

Was durch den Digital Omnibus geändert wurde

Die Europäische Kommission legte den Digital Omnibus on AI am 19. November 2025 vor, nachdem deutlich geworden war, dass das Compliance-Ökosystem nicht rechtzeitig zum ursprünglich vorgesehenen Stichtag im August 2026 bereit sein würde: Die Ausarbeitung der harmonisierten Normen von CEN-CENELEC verzögerte sich, Konformitätsbewertungsstellen waren noch nicht benannt, und viele Mitgliedstaaten hatten ihre Marktüberwachungsbehörden noch nicht eingerichtet. Parlament und Rat erzielten am 7. Mai 2026 eine politische Einigung und verabschiedeten den Text im Juni formell. Er wurde am 24. Juli 2026 im Amtsblatt der Europäischen Union veröffentlicht. Drei Tage später trat die Verordnung in Kraft – sechs Tage vor der ursprünglich vorgesehenen Frist.

Ein Detail ist für die Planung besonders wichtig: Die neuen Termine sind fest und nicht an Bedingungen geknüpft. Der ursprüngliche Vorschlag der Kommission machte den Aufschub noch davon abhängig, ob Normen und Leitlinien rechtzeitig vorliegen würden; 2027 beziehungsweise 2028 waren lediglich als späteste Termine vorgesehen. Parlament und Rat ersetzten dieses Modell durch feste Stichtage. Dr. Nils Rauer von Pinsent Masons bezeichnete die Einigung als „einen pragmatischen Schritt hin zu mehr Rechtssicherheit“. Es gibt damit kein Szenario, in dem die Verpflichtungen früher greifen, und auch kein realistisches Szenario, in dem sie erneut verschoben werden.

‍

Der Zeitplan des EU AI Act – aktueller Stand

• 2. Februar 2025 (in Kraft): Verbotene KI-Praktiken (Artikel 5); Pflicht zur KI-Kompetenz (Artikel 4)
• 2. August 2025 (in Kraft): Verpflichtungen für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck (GPAI), einschließlich der Pflichten für Modelle mit systemischem Risiko (Kapitel V)
• 2. August 2026 (in Kraft): Transparenzpflichten nach Artikel 50; Befugnisse der Kommission zur Verhängung von Geldbußen gegen GPAI-Anbieter (Artikel 101)
• 2. Dezember 2027: Anforderungen für eigenständige Hochrisiko-KI-Systeme nach Anhang III, einschließlich der Protokollierungspflichten nach Artikel 12 und der Meldepflicht für schwerwiegende Vorfälle nach Artikel 73
• 2. August 2028: Anforderungen für Hochrisiko-KI-Systeme, die in regulierte Produkte integriert sind (Anhang I)

Was für 2026 schon gilt, unabhängig vom Fristaufschub

Wenn Sie KI-Systeme in der EU entwickeln oder einsetzen, sind zwei Punkte bereits jetzt relevant:

Transparenzpflichten (Artikel 50, seit dem 2. August 2026): Nutzer müssen darüber informiert werden, wenn sie mit einem KI-System interagieren. KI-generierte oder manipulierte Inhalte müssen zudem gekennzeichnet und maschinell erkennbar sein. Dabei handelt es sich nicht um eine Pflicht im Zusammenhang mit Incidents, wohl aber um eine der ersten Verpflichtungen aus dem EU AI Act, auf deren Einhaltung viele Engineering-Teams tatsächlich geprüft werden dürften.

Durchsetzung der GPAI-Vorschriften (seit dem 2. August 2026): Die Transparenz-, Dokumentations- und Urheberrechtspflichten für GPAI-Anbieter gelten bereits seit August 2025. Neu ist die Befugnis der Kommission, bei Verstößen Geldbußen von bis zu 3 % des weltweiten Jahresumsatzes oder 15 Millionen Euro zu verhängen – je nachdem, welcher Betrag höher ist. Für Anbieter von GPAI-Modellen mit systemischem Risiko wird die Erfassung und Meldung schwerwiegender Vorfälle bereits nach Artikel 55 Absatz 1 Buchstabe c verlangt. Der Code of Practice sieht dabei Meldefristen vor, die denen aus Artikel 73 entsprechen, sowie eine Frist von fünf Tagen für schwerwiegende Cybersicherheitsvorfälle.

‍

Artikel 73: Anforderungen an die Meldung schwerwiegender Vorfälle

Artikel 73 enthält die zentralen Vorgaben des EU AI Act für die Meldung schwerwiegender Vorfälle. Gerade bei den Fristen lohnt es sich, genau hinzusehen: Häufig wird fälschlicherweise von einer 72-Stunden-Regel nach dem Vorbild der DSGVO ausgegangen. Für Anbieter von Hochrisiko-KI-Systemen gelten tatsächlich folgende Fristen:

• Unverzügliche Meldung, nachdem ein ursächlicher Zusammenhang zwischen dem KI-System und dem Vorfall oder die hinreichende Wahrscheinlichkeit eines solchen Zusammenhangs festgestellt wurde, und spätestens innerhalb von 15 Tagen, nachdem der Anbieter von einem schwerwiegenden Vorfall Kenntnis erlangt hat.
• Spätestens innerhalb von 2 Tagen bei einem weitverbreiteten Verstoß oder einer schwerwiegenden und irreversiblen Beeinträchtigung kritischer Infrastrukturen.
• Spätestens innerhalb von 10 Tagen, wenn eine Person infolge des Vorfalls verstorben ist.

Ein „schwerwiegender Vorfall“ ist ein Vorfall oder eine Fehlfunktion, die direkt oder indirekt zum Tod oder zu einer schwerwiegenden Gesundheitsschädigung, zu einer schwerwiegenden und irreversiblen Beeinträchtigung kritischer Infrastrukturen, zu einem Verstoß gegen Verpflichtungen zum Schutz der Grundrechte oder zu schwerwiegenden Schäden an Eigentum oder Umwelt führt.

Drei operative Aspekte sind für Engineering-Teams besonders wichtig:

Ein unvollständiger Erstbericht ist ausdrücklich zulässig und kann später durch einen vollständigen Bericht ergänzt werden. Die Verordnung geht davon aus, dass die Meldung erfolgt, während die Untersuchung noch läuft. Der Meldeprozess darf daher nicht davon abhängen, dass das Postmortem bereits abgeschlossen ist.

Sie müssen den Vorfall untersuchen, das Risiko bewerten und Korrekturmaßnahmen ergreifen: Bevor die zuständigen Behörden informiert wurden, darf das KI-System zudem nicht so verändert werden, dass dies die Bewertung der Ursachen des Vorfalls beeinträchtigen könnte. Die Beweiskette muss also auch während der Incident Response erhalten bleiben.

Auch Betreiber sind eingebunden: Nach Artikel 26 Absatz 5 muss ein Betreiber, der einen schwerwiegenden Vorfall feststellt, unverzüglich den Anbieter informieren und anschließend gegebenenfalls den Importeur oder Händler sowie die Marktüberwachungsbehörden. Kommunikationswege zwischen Anbieter und Betreiber sind damit ein Bestandteil der Compliance und kein optionales Extra.

Die Kommission hat bereits einen Entwurf für Leitlinien sowie eine standardisierte Meldevorlage zu Artikel 73 veröffentlicht; die endgültigen Fassungen stehen noch aus. Zugleich sieht der EU AI Act selbst bereits vor, Doppelmeldungen zu vermeiden: Fällt ein Hochrisiko-KI-System unter eine sektorspezifische Regelung mit gleichwertigen Meldepflichten – etwa kritische Infrastrukturen unter NIS2 oder Medizinprodukte unter der MDR –, beschränken Artikel 73 Absätze 9 und 10 die Meldepflicht nach dem EU AI Act auf Vorfälle, die Grundrechte betreffen. Alle anderen Vorfälle werden nach den jeweiligen sektorspezifischen Vorschriften gemeldet.

Kurz gesagt: Ein gut aufgesetzter Incident-Prozess kann die Anforderungen mehrerer Aufsichtsregime gleichzeitig abdecken.

Warum jetzt handeln – und nicht erst im November 2027?

Es spricht vieles dafür, den Aufschub aktiv zu nutzen, statt ihn einfach verstreichen zu lassen:

Die Termine stehen jetzt fest: Feste Stichtage haben die Unsicherheit beseitigt, die ein Abwarten bislang noch rechtfertigen konnte.

Die Anforderungen betreffen vor allem operative Abläufe – nicht bloß Dokumentationspflichten: Manipulationssichere Protokollierung, bereichsübergreifende Benachrichtigung, Beweissicherung und Melden während einer laufenden Untersuchung sind operative Fähigkeiten. Teams, die solche Abläufe erst im vierten Quartal 2027 einführen, werden unter erheblichem Zeitdruck stehen.

Wer sie bereits jetzt etabliert und erprobt, gewinnt dagegen rund ein Jahr praktische Erfahrung.

Der gleiche Prozess zahlt sich schon heute in anderen Regelwerken aus: Die 24-Stunden-Frühwarnung und die 72-Stunden-Meldung nach NIS2, die 72-Stunden-Frist der DSGVO für Datenschutzverletzungen sowie die Incident-Meldepflichten nach DORA folgen jeweils eigenen Zeitvorgaben – und keine davon wurde verschoben. Ein einheitlicher Incident-Prozess mit automatischer Fristenverfolgung, rollenbasierten Eskalationen und auditfähigen Postmortems kann mehrere regulatorische Anforderungen mit derselben Dokumentations- und Beweisgrundlage abdecken.

‍

Checkliste für die Anforderungen nach Artikel 73 

Was Ihr Incident-Prozess bis Dezember 2027 leisten können muss – und was sich bereits heute im Hinblick auf NIS2, DORA und DSGVO auszahlt:

1. Bereits bei der Erfassung klassifizieren: Im Rahmen der Triage muss geprüft werden, ob ein Vorfall die Definition eines „schwerwiegenden Vorfalls“ nach Artikel 3 Nummer 49 erfüllen könnte. So wird die Frist nach dem EU AI Act vom ersten Tag an berücksichtigt – und nicht erst beim Postmortem.
2. Zeitpunkt der Kenntniserlangung dokumentieren: Die Fristen von 2, 10 beziehungsweise 15 Tagen beginnen mit dem Zeitpunkt, zu dem Sie von dem Vorfall Kenntnis erlangen. Dieser Zeitpunkt sollte automatisch erfasst werden, anstatt ihn später zu rekonstruieren zu müssen.
3. Beweise sichern, bevor Sie Änderungen vornehmen: Bis die Behörden informiert sind, dürfen keine Änderungen am KI-System vorgenommen werden, die die Ursachenanalyse beeinträchtigen könnten (Artikel 73 Absatz 6). Logs, Modellversionen und Eingabedaten müssen daher während der Incident Response erhalten bleiben.
4. Melden, während die Untersuchung noch läuft: Ein unvollständiger Erstbericht ist zulässig. Der Meldeprozess darf daher nicht auf die abschließende Ursachenanalyse warten.
5. Kommunikationsweg zwischen Betreiber und Anbieter festlegen: Betreiber müssen Anbieter unverzüglich informieren (Artikel 26 Absatz 5). Kommunikationskanal und Vorlage sollten deshalb im Voraus festgelegt werden.
6. Rechtsabteilung und Kommunikationsteam parallel zum Engineering einbinden: Die Person, die die Meldung einreicht, ist in der Regel nicht dieselbe Person, die den Incident behebt.
7. Anwendbares Regelwerk für jedes System bestimmen: Es muss klar sein, welche Frist greift – nach EU AI Act, NIS2, DORA oder DSGVO – oder ob eine sektorspezifische Regelung die Meldepflicht nach Artikel 73 Absätze 9 und 10 ersetzt.
8. Incident-Zeitleiste exportierbar machen: Jede Meldung erfordert eine nachvollziehbare Dokumentation. Sie sollte direkt aus den aufgezeichneten Ereignissen erstellt werden können – und nicht nachträglich aus dem Gedächtnis.

So unterstützt ilert die Incident-Meldepflichten des EU AI Act 

ilert macht Sie nicht automatisch EU-AI-Act-konform – das kann kein Tool. Es sorgt jedoch dafür, dass die operativen Anforderungen zu festen Abläufen werden, statt im Ernstfall zu einem Heldeneinsatz zu werden:

• Auditfähige Zeitleisten (Artikel 12, Artikel 73 Absatz 6): Jede Alarmierung, Eskalation, Bestätigung und Maßnahme wird automatisch in der Incident-Zeitleiste erfasst und kann exportiert werden. So entsteht eine belastbare Dokumentation über die gesamte Dauer des Incidents, ohne dass während einer Störung ein Teammitglied parallel alles manuell protokollieren muss.
• Meldeprozesse innerhalb der vorgegebenen Fristen (2/10/15 Tage): Multi-Channel-Alarmierung, Dienstpläne und Eskalationsrichtlinien sorgen dafür, dass Incidents innerhalb weniger Minuten erkannt und an die richtigen Personen weitergeleitet werden. Die eigentliche Herausforderung von Artikel 73 ist nicht die Meldefrist selbst, sondern dass Ursachenanalyse und Dokumentation rechtzeitig vorliegen. Automatisierte Zeitleisten und KI-gestützte Postmortems erzeugen einen Großteil dieser Dokumentation direkt im Zuge der Incident Response.
• Bereichsübergreifende Abläufe (Artikel 26 Absatz 5, Artikel 73 Absatz 1): Playbooks binden Engineering, Rechtsabteilung und Kommunikationsteam parallel ein. Statusseiten versorgen Stakeholder mit verifizierten Updates, ohne die Responder durch zusätzliche Meetings von der Incident Response abzuhalten.
• Von Monitoring zu Incident (Artikel 55 Absatz 1 Buchstabe c, Artikel 72): Werden in Ihrem Monitoring-Stack Schwellenwerte überschritten, treten Output-Drift, erhöhte Inferenzfehler oder ungewöhnliche Verzögerungen auf, kann über die Alarmierungsquellen von ilert automatisch ein Incident eröffnet werden. So laufen Post-Market-Monitoring und Incident-Tracking auf derselben Datengrundlage.
• Datenverarbeitung auf EU-Niveau: ilert wird in Deutschland entwickelt und gehostet, ist nach ISO 27001 zertifiziert und DSGVO-konform. Auch die KI-Inferenz bleibt innerhalb der Region. So schafft das Tooling für die Reaktion auf KI-Incidents keine zusätzlichen Risiken beim Datentransfer.
• Governance statt unkontrollierter Autonomie: Ein zentrales Prinzip des EU AI Act ist die menschliche Aufsicht über KI. ilert AI SRE folgt demselben Grundsatz: Der Agent untersucht, korreliert und erstellt Entwürfe; ein Responder prüft die Ergebnisse und entscheidet über die nächsten Schritte. Die KI übernimmt die Analyse. Die Entscheidung liegt beim Menschen.

Sehen Sie den gesamten Ablauf – Alarmierung, Zeitleiste, Postmortem – in der wöchentlichen Live-Demo von ilert.

Häufig gestellte Fragen

Wurde der EU AI Act verschoben?

Teilweise. Der Digital Omnibus on AI (Verordnung (EU) 2026/1744, in Kraft seit dem 27. Juli 2026) verschob die Anforderungen für Hochrisiko-KI-Systeme auf den 2. Dezember 2027 (Anhang III) beziehungsweise den 2. August 2028 (Anhang I). Die Verpflichtungen für GPAI sowie die Transparenzpflichten nach Artikel 50 blieben bei ihren ursprünglich vorgesehenen Terminen.

‍

Welche Bestimmungen gelten seit dem 2. August 2026?

Die Transparenzpflichten nach Artikel 50 sowie die Befugnis der Kommission, gegen GPAI-Anbieter Geldbußen zu verhängen. Die GPAI-Verpflichtungen selbst – einschließlich der Meldepflicht für schwerwiegende Vorfälle bei Modellen mit systemischem Risiko – waren zu diesem Zeitpunkt bereits in Kraft.

‍

Ab wann gilt die Meldepflicht für schwerwiegende Vorfälle nach Artikel 73?

Die Meldepflicht ist an die Anforderungen für Hochrisiko-KI-Systeme gekoppelt: Sie gilt ab dem 2. Dezember 2027 für eigenständige Systeme nach Anhang III und ab dem 2. August 2028 für in regulierte Produkte integrierte Systeme nach Anhang I. Für GPAI-Modelle mit systemischem Risiko gilt bereits eine parallele Meldepflicht nach Artikel 55 Absatz 1 Buchstabe c.

‍

Wie schnell müssen schwerwiegende Vorfälle nach dem EU AI Act gemeldet werden?

Unverzüglich, sobald ein ursächlicher Zusammenhang – oder dessen hinreichende Wahrscheinlichkeit – festgestellt wurde, und spätestens innerhalb von 15 Tagen nach Kenntniserlangung. Bei weitverbreiteten Verstößen oder einer schwerwiegenden Beeinträchtigung kritischer Infrastrukturen gilt eine Frist von 2 Tagen, bei einem Todesfall von 10 Tagen. Es gilt also keine 72-Stunden-Frist – diese stammt aus der DSGVO.

‍

Hat der Aufschub Auswirkungen auf NIS2, DORA oder die DSGVO?

Nein. Diese Regelwerke und ihre jeweiligen Meldefristen bleiben unverändert. Das umfassendere Digital-Omnibus-Paket sieht zwar Änderungen an der DSGVO und NIS2 vor, diese befinden sich zum Zeitpunkt der Veröffentlichung jedoch noch in Verhandlung und sind noch nicht geltendes Recht. Der EU AI Act selbst sieht für die meisten Incidents bei sektorspezifisch regulierten Systemen vor, dass die Meldung nach den jeweiligen sektorspezifischen Vorschriften erfolgt (Artikel 73 Absätze 9 und 10). Ein einheitlicher Incident-Prozess ist daher die sinnvollste Lösung, um mehrere regulatorische Anforderungen abzudecken.

‍

Dieser Artikel bietet praktische Hinweise zur Gestaltung von Incident-Prozessen und stellt keine Rechtsberatung dar.

‍