Fiktives, realitätsnahes Szenario vom 19. Juli 2026. Die Geschäftsführerin eines Grazer Maschinenbauzulieferers liest die Meldung, der AI Act sei verschoben worden. Die Meldung stimmt – für Hochrisiko-Systeme. Diese wandern auf den 2. Dezember 2027. Sie schließt den Tab erleichtert, denn im Betrieb läuft nichts, was als hochriskant gilt. Der Support-Chatbot auf der Website beantwortet wöchentlich mehrere hundert Kundenanfragen. Das Marketing-Tool schreibt Produkttexte und Social-Media-Beiträge. Beides ist nicht hochriskant eingestuft. Beides fällt unter eine Pflicht, die am 2. August 2026 beginnt – in vierzehn Tagen.
Dieses Szenario verdichtet typische Betriebsmuster; es ist kein Kundenfall und kein behauptetes Ergebnis. Der Fehler liegt nicht in Nachlässigkeit. Eine vernünftige Führungskraft liest eine korrekte Schlagzeile über den falschen Artikel.
Die Verschiebung, die keine war
Zwei Ereignisse aus 2026 werden in DACH-Chefetagen gern zu einem Satz verschmolzen. Sie gehören getrennt betrachtet.
Das erste ist der Digital Omnibus: eine vorläufige politische Einigung vom 6. Mai 2026, vom Rat am 13. Mai 2026 bestätigt. Sie verschiebt die operativ anspruchsvollsten Teile des AI Act. Eigenständige Hochrisiko-Systeme nach Anhang III – Recruiting-Scoring, Kreditentscheidungen, Bildungsanwendungen und Vergleichbares – wandern vom 2. August 2026 auf den 2. Dezember 2027. In regulierte Produkte eingebettete KI nach Anhang I, etwa in Medizinprodukten oder Maschinen, wandert auf den 2. August 2028. Es handelt sich um eine vorläufige Einigung, die formell noch angenommen und im Amtsblatt veröffentlicht werden muss – die Daten sind der beabsichtigte Zielpunkt, keine belastbare Rechtsgrundlage, auf der Sie heute schon eine Verteidigungslinie aufbauen sollten.
Das zweite Ereignis: Artikel 50 blieb, wo er war. Die Transparenzpflichten gelten ab dem 2. August 2026. Sie waren nie Teil der Verschiebung. Ausgerechnet die am breitesten wirkende Pflicht im gesamten AI Act ist diejenige, die nicht verschoben wurde.
Die Berichterstattung war nicht falsch. Der Schluss, den viele daraus zogen, war es. „Der AI Act wurde verschoben“ stimmt für Hochrisiko und stimmt nicht für Transparenz – und ausgerechnet die Unternehmen, die diesen Schluss am ehesten ziehen, sind die, für die Artikel 50 geschrieben wurde.
Warum Artikel 50 weiter reicht als High-Risk je reichte
Die Hochrisiko-Klassifizierung ist bewusst eng gefasst. Die meisten Mittelständler liegen tatsächlich außerhalb von Anhang III, und ihre Entlastung war insoweit berechtigt.
Artikel 50 folgt einer anderen Logik. Er knüpft an ein Verhalten an, nicht an eine Risikoklasse. Sobald ein KI-System direkt mit Menschen interagiert oder synthetische Audio-, Bild-, Video- oder Textinhalte erzeugt, kann die Pflicht greifen – unabhängig davon, wie harmlos der Anwendungsfall wirkt. Ein Chatbot beim Sanitärgroßhändler und ein Frontier-Modell bei einer Großbank stehen hier auf derselben Seite der Linie.
Das kehrt die übliche Compliance-Intuition um. Bei den meisten Teilen des AI Act gilt: klein und einfach heißt außen vor. Bei Artikel 50 gilt: klein und einfach heißt mitten drin – und kleine, einfach aufgestellte Unternehmen haben die Meldung über die „Verschiebung“ am ehesten für bare Münze genommen.
Die Durchsetzung folgt derselben Logik. Ab dem 2. August 2026 können nationale Behörden und das AI Office gegen Verstöße von Providern und Deployern vorgehen, mit einem Bußgeldrahmen von bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Ob ein konkreter Verstoß den Höchstrahmen auslöst, ist eine eigene Frage – die Aufsichtspraxis in Österreich und Deutschland formt sich gerade erst –, aber die Obergrenze ist keine theoretische Größe.
Provider oder Deployer: die Frage, die über Ihre Pflicht entscheidet
Artikel 50 legt nicht jedem dieselbe Pflicht auf. Er teilt die Rollen zwischen der Partei, die ein System auf den Markt bringt, und der Partei, die es einsetzt. Wer die eigene Rolle falsch bestimmt, bereitet sich auf die falsche Pflicht vor.
Grob gilt: Wer ein KI-System baut oder unter eigenem Namen auf dem EU-Markt platziert, trägt Provider-Pflichten nach Artikel 50(1) und 50(2). Wer das System eines Dritten im eigenen Betrieb einsetzt, trägt Deployer-Pflichten nach 50(3) und 50(4).
Die Falle: Ein einzelnes Unternehmen ist meist beides, und oft beides innerhalb desselben Workflows. Ein Betrieb, der einen zugekauften Chatbot auf der eigenen Website betreibt, ist Deployer dieses Chatbots. Derselbe Betrieb, der eine KI-Funktion in das eigene Produkt einbaut, ist Provider dieser Funktion. Und ein Unternehmen, das ein White-Label-KI-System unter eigener Marke ausliefert, kann feststellen, dass es zum Provider eines Systems geworden ist, das es nie selbst gebaut hat.
Die Rollenbestimmung ist einzelfallabhängig und richtet sich nach Verträgen, Markenauftritt und Grad der Veränderung. Dieser Artikel liefert die Methode, die Frage sauber zu stellen. Er beantwortet sie nicht für Ihre konkreten Systeme – das kann kein Artikel leisten.
MARK: vier Fragen vor dem 2. August
Vier Fragen, in dieser Reihenfolge. Der Name spielt bewusst auf die Kennzeichnungspflicht aus Artikel 50(2) an, denn die Kennzeichnung ist der Teil, den Teams am spätesten entdecken und am längsten zum Aufbauen brauchen.
M – Map (Kartieren)
Welche Ihrer Systeme interagieren direkt mit Menschen, welche erzeugen synthetische Audio-, Bild-, Video- oder Textinhalte? Das ist enger als „wo setzen wir KI ein“ und weiter als „was haben wir beschafft“. Es umfasst Funktionen, die in Tools stecken, die für einen anderen Zweck gekauft wurden, und es umfasst KI, die eine Fachabteilung ohne Rücksprache aktiviert hat.
A – Actor (Rolle)
Sind Sie für jedes kartierte System Provider, Deployer oder beides? Dokumentieren Sie die Begründung und die Vertragsklausel, auf der sie beruht – alles Weitere baut auf dieser Bestimmung auf.
R – Reveal (Offenlegen)
Was genau wird offengelegt, auf welcher Fläche, zu welchem Zeitpunkt, in welcher Form? Eine Offenlegung, die in einem Dokument steckt, das niemand öffnet, ist keine Offenlegung. Das ist die Frage, die Teams am billigsten beantworten – und am häufigsten falsch.
K – Keep (Nachweisen)
Welcher Nachweis belegt, dass die Offenlegung an diesem Datum, in dieser Form, tatsächlich live war? Compliance, die Sie erreicht, aber nicht belegen können, ist von übersprungener Compliance nicht zu unterscheiden – genau in dem Moment, in dem es darauf ankommt.
Die vier Pflichten aus Artikel 50 im Betriebsalltag
Der Wortlaut der Pflichten ist beim AI Act Service Desk der Kommission veröffentlicht. Was folgt, ist die operative Übersetzung – kein Ersatz für den Rechtstext.
| Vorschrift | Wer schuldet | Auslöser | Was Compliance in der Praxis bedeutet |
|---|---|---|---|
| 50(1) | Provider | KI-System, das direkt mit Menschen interagieren soll | Die Person wird informiert, dass sie mit einem KI-System interagiert, außer dies ist für eine informierte, aufmerksame Person offensichtlich |
| 50(2) | Provider | System erzeugt synthetische Audio-, Bild-, Video- oder Textinhalte | Ausgabe ist maschinenlesbar gekennzeichnet und als künstlich erzeugt oder verändert erkennbar; die Lösung muss wirksam, interoperabel, robust und zuverlässig sein |
| 50(3) | Deployer | System zur Emotionserkennung oder biometrischen Kategorisierung | Betroffene Personen werden über den Betrieb informiert, Datenschutzrecht gilt parallel |
| 50(4) | Deployer | Deepfakes; KI-generierter Text zur Information der Öffentlichkeit über Angelegenheiten von öffentlichem Interesse | Der künstliche Ursprung wird offengelegt; leichtere, weniger aufdringliche Offenlegung gilt für erkennbar künstlerische, kreative, satirische oder fiktionale Werke; redaktionell geprüfter Text hat eine eigene Ausnahme |
In jeder Vorschrift gibt es Ausnahmen – Strafverfolgung, unterstützende Bearbeitungsfunktionen, Systeme, die den Input nicht wesentlich verändern, redaktionelle Prüfung. Sie sind eng gefasst, und sich ohne dokumentierte Begründung in eine Ausnahme hineinzulesen, ist eine Entscheidung, die Sie später verteidigen müssen.

Was der Entwurf der Kommission als nicht ausreichend markiert
Parallel zur Frist veröffentlichte die Kommission einen Entwurf von Leitlinien zur Umsetzung der Artikel-50-Pflichten, mit einer gezielten Konsultation, die am 3. Juni 2026 endete. Das ist ein Entwurf. Er zeigt die Denkrichtung der Kommission, ist nicht das letzte Wort, und der finale Text kann sich noch verschieben.
Zwei Signale aus diesem Entwurf verdienen jetzt schon Beachtung, weil beide die naheliegendsten Abkürzungen versperren.
Ein Verweis in den AGB oder in der Produktdokumentation gilt demnach als nicht ausreichend für die Pflicht aus 50(1). Die Pflicht besteht darin, die interagierende Person zu informieren – ein Link, den niemand öffnet, informiert niemanden.
Auch eine rein technische Kennzeichnung – Metadaten oder ein Wasserzeichen allein – gilt für dieselbe Pflicht als nicht ausreichend. Die maschinenlesbare Kennzeichnung ist eine eigenständige Pflicht nach 50(2); sie erfüllt nicht die Pflicht, einem Menschen zu sagen, dass er mit einer Maschine spricht. Der Entwurf deutet auf eine Kombination hin: ein klar sichtbarer Hinweis in einfacher Sprache, ein dauerhaftes visuelles Kennzeichen und akustische Signale, wo die Interaktion gesprochen wird.
Zusammen genommen verschieben diese Signale die Offenlegung aus der Rechtsabteilung in die Produktebene. Das ist eine Design- und Engineering-Aufgabe mit vierzehn Tagen Vorlauf, keine Dokumentenprüfung.
Das Fenster bis zum 2. Dezember 2026 – und wer es wirklich bekommt
Es gibt genau eine echte Fristverlängerung innerhalb von Artikel 50, und sie wird regelmäßig überschätzt.
Generative KI-Systeme, die bereits vor dem 2. August 2026 auf dem Markt sind, haben bis zum 2. Dezember 2026 Zeit, die maschinenlesbare Kennzeichnungspflicht nach Artikel 50(2) zu erfüllen. Das sind vier zusätzliche Monate, für eine einzige Pflicht, für Systeme, die bereits existieren.
Sie verlängert nicht die Pflicht aus 50(1), über die KI-Interaktion zu informieren. Sie verlängert nicht die Deepfake-Pflicht aus 50(4). Sie gilt nicht für ein System, das Sie im September starten. Wenn Ihr Compliance-Plan auf dem Satz „wir haben bis Dezember Zeit“ beruht, prüfen Sie, ob dieser Satz den Kontakt mit diesen drei Einschränkungen übersteht – in den meisten Fällen tut er das nicht.
Wer in Österreich und Deutschland tatsächlich fragen wird
Eine EU-Verordnung wird von nationalen Behörden vollzogen, und in DACH bauen sich diese Behörden gerade erst auf. Das ist ein Grund, früher zu beginnen, nicht später.
In Österreich unterstützt die bei der RTR angesiedelte KI-Servicestelle Unternehmen bereits jetzt beim Verständnis ihrer AI-Act-Pflichten und bietet Orientierung. Sie ist so positioniert, dass sie sich zur nationalen Behörde für Marktüberwachung und verwandte Aufgaben entwickeln soll, sobald der AI Act vollständig anwendbar ist – dann stehen die Durchsetzungsbefugnisse und Sanktionen des AI Act dahinter. In Deutschland würde der Entwurf des KI-Marktüberwachungs- und Innovationsförderungsgesetzes (KI-MIG) die Bundesnetzagentur zur zentralen Koordinierungs- und Marktüberwachungsbehörde machen. Dieses Gesetz ist ein Entwurf, und seine endgültige Form steht noch nicht fest.
Die praktische Einschätzung: Die ersten Monate nach dem 2. August 2026 werden vermutlich weder wie aggressive Vollzugspraxis noch wie Untätigkeit aussehen. Aufsicht, die zunächst auf Orientierung setzt, stellt trotzdem Fragen – und die Antwort „wir sind davon ausgegangen, außen vor zu sein“ ist spürbar schwächer als „hier ist unsere Scope-Bestimmung, hier ist, was wir offengelegt haben, hier ist das Datum“. Das ist eine Einschätzung der Aufsichtshaltung, keine Rechtsaussage und keine Vorhersage des Verhaltens einer bestimmten Behörde.
Für Unternehmen, die im gesamten DACH-Raum tätig sind, steht dasselbe Produkt oft zwei Aufsichtsbehörden mit unterschiedlichen Zeitplänen und unterschiedlicher Terminologie gegenüber. Die Begründung einmal so zu dokumentieren, dass beide sie lesen können, ist günstiger, als sie zweimal zu rekonstruieren.
Wo die Offenlegung wirklich lebt: Fläche, Zeitpunkt, Ton
Sobald Offenlegung zur Produktfrage wird, folgen drei Entscheidungen – keine davon ist eine Rechtsentscheidung.
Fläche. Der Hinweis gehört dorthin, wo die Interaktion stattfindet, nicht dorthin, wo die Dokumentation liegt: ins Chatfenster, auf das generierte Asset, in den Sprachdialog. Kann ein Nutzer die KI erreichen, ohne am Hinweis vorbeizukommen, ist die Fläche falsch gewählt.
Zeitpunkt. Vor oder spätestens bei der ersten Interaktion, und dauerhaft genug, dass ein Nutzer, der mitten in der Sitzung dazustößt, nicht in die Irre geführt wird. Ein Hinweis, der einmal erscheint und dann verschwindet, versagt bei Nutzern, die zurückscrollen oder am nächsten Tag wiederkommen.
Ton. Klartext schlägt Juristendeutsch, und genau hier überkonstruieren viele Teams. „Sie chatten mit einem KI-Assistenten. Ein Mensch kann jederzeit übernehmen.“ leistet mehr Compliance-Arbeit als ein Absatz voller Legaldefinitionen – und kostet weniger Vertrauen.
Es gibt hier ein kaufmännisches Argument, das mit Regulierung nichts zu tun hat. Klare KI-Kennzeichnung wird im DACH-B2B-Geschäft zunehmend zum Vertrauenssignal, wo Einkäufer immer öfter fragen, wie ein Lieferant KI einsetzt, bevor sie nach dem Preis fragen. Unternehmen, die das als Gestaltungschance behandeln, landen besser als Unternehmen, die es als Warnhinweis abhaken. Das ist eine Einschätzung, keine Rechtsaussage.
Evidenz: einen Nachweis erbringen, den Sie längst erbracht haben
Das Muster aus jedem anderen Compliance-Regime wiederholt sich hier. Das Unternehmen hat das Richtige getan, kann es aber für das relevante Datum nicht belegen und argumentiert aus der Erinnerung heraus. Artikel-50-Offenlegungen gehen besonders leicht verloren, weil sie in Oberflächen leben, die laufend weiterentwickelt werden.
| Nachweis | Warum er zählt | Owner |
|---|---|---|
| Systemidentität und Rollenbestimmung | Legt fest, ob Provider- oder Deployer-Pflichten gelten, und mit welcher Begründung | System-Owner |
| Hinweistext, Fläche und versionierter Screenshot | Zeigt, was ein Nutzer tatsächlich gesehen hat – nicht, was eine Richtlinie beabsichtigte | Product Owner |
| Datum des Inkrafttretens und Änderungsdatum | Beantwortet die einzige Frage, die eine Aufsichtsbehörde stellt: war es zu diesem Zeitpunkt live? | Product Owner |
| Kennzeichnungsmethode und Testergebnis zur Erkennbarkeit | Belegt die Aussage zu 50(2), statt sie nur zu behaupten | Engineering |
| Herangezogene Ausnahme, mit Begründung | Macht aus einer stillschweigenden Annahme eine verteidigbare, dokumentierte Entscheidung | Recht und System-Owner |
| Lieferantenzusage für zugekaufte Systeme | Legt fest, was der Anbieter zusichert und was bei Ihnen verbleibt | Einkauf |
Das ist dieselbe Disziplin wie bei einem KI-Systeminventar, angewendet auf eine einzelne, eng gefasste Frage. Existiert dieses Inventar bereits, ist der Vierzehn-Tage-Sprint unten realistisch. Existiert es nicht, ist das Inventar selbst der Sprint.

Der 14-Tage-Sprint vor dem 2. August
Vierzehn Tage reichen nicht, um ein Governance-Programm zu bauen. Sie reichen, um die Lücke zwischen Systemen, von denen niemand wusste, dass sie im Anwendungsbereich liegen, und Hinweisen, die schlicht fehlen, zu schließen.
Tag 1-4: Kartieren und einordnen
- Jedes System auflisten, das mit Menschen spricht oder synthetische Inhalte erzeugt, einschließlich Funktionen in Tools, die für andere Zwecke gekauft wurden.
- Für jedes System Provider oder Deployer festhalten, samt Begründung.
- Kunden- und öffentlichkeitswirksame Systeme als erste Priorität markieren; rein interne Systeme können folgen.
- Pro System einen verantwortlichen Owner benennen. Unbesetzte Systeme sind der Ort, an dem Fristen gerissen werden.
Tag 5-9: Offenlegen
- Hinweistext in einfacher Sprache verfassen, pro System und pro Betriebssprache.
- Auf der Interaktionsfläche platzieren, nicht in der Dokumentation, und dauerhaft sichtbar machen.
- Lieferanten schriftlich fragen, welche Kennzeichnung sie nach 50(2) anwenden und was sie zur Erkennbarkeit zusichern.
- Bewusst über Deepfake- und Text-Offenlegung nach 50(4) entscheiden, auch wenn die Antwort lautet, dass es nicht zutrifft.
Tag 10-14: Nachweisen und prüfen
- Datierte Screenshots und Versionsnachweise für jede live geschaltete Offenlegung sichern.
- Testen, dass ein Nutzer auf jedem Weg zum System auch auf den Hinweis trifft.
- Jede genutzte Ausnahme mit Begründung schriftlich dokumentieren.
- Die Person benennen, die dies nach dem 2. August weiter überprüft, denn Oberflächen werden weiter ausgeliefert.
Die 30/60/90-Tage-Spur für den Dauerbetrieb
Der Sprint verschafft Ihnen die Frist. Er hinterlässt kein System, das auch dann konform bleibt, wenn sich Ihr Produkt wöchentlich ändert.
Tag 1-30
Artikel-50-Scope in das KI-Systeminventar einbetten, sodass neue Systeme bei Aufnahme eingestuft werden, statt später geprüft zu werden. Eine Offenlegungsfrage in die Beschaffungs-Checkliste aufnehmen. Festlegen, welche Nachweise automatisch und welche manuell erfasst werden.
Tag 31-60
Offenlegung zum Release-Gate machen: keine KI-Funktion geht live ohne Offenlegungsentscheidung und datierten Nachweis. Lieferantenzusagen zur Kennzeichnung validieren statt sie ungeprüft zu übernehmen. Die Finalisierung der Transparenz-Leitlinien und des Code of Practice zur Kennzeichnung KI-generierter Inhalte verfolgen und die eigene Vorgehensweise gegen den finalen Text abgleichen.
Tag 61-90
Eine interne Prüfung durchführen, als wären Sie selbst die Aufsichtsbehörde: drei Systeme auswählen, fragen, was ein Nutzer wann gesehen hat, und prüfen, ob der Nachweis darauf eine Antwort gibt. Die KI-Kompetenzpflicht einbeziehen, die seit Februar 2025 gilt und in DACH vielerorts noch unzureichend umgesetzt ist. Festlegen, was sich ändert, wenn die verschobenen Hochrisiko-Pflichten im Dezember 2027 eintreffen – solange noch Zeit bleibt, zu gestalten statt zu reagieren.
Was die offiziellen Quellen belegen
Die AI Act Service Desk-Seite der Kommission zu Artikel 50 enthält den maßgeblichen Wortlaut der vier Transparenzpflichten und ihrer Ausnahmen. Der Entwurf der Leitlinien zur Umsetzung der Artikel-50-Transparenzpflichten legt die aktuelle Denkrichtung der Kommission dar, einschließlich unzureichender Offenlegungsmethoden; er bleibt nach der am 3. Juni 2026 abgeschlossenen Konsultation ein Entwurf. Der Code of Practice zur Kennzeichnung KI-generierter Inhalte wird parallel finalisiert und wird prägen, was „wirksam, interoperabel, robust und zuverlässig“ in der Praxis bedeutet.
Die Verschiebung der Hochrisiko-Pflichten durch den Digital Omnibus ist eine vorläufige politische Einigung, die noch formell angenommen werden muss. Die Einstufung eines konkreten Systems und die Rolle, die Sie dabei einnehmen, sind einzelfallabhängig. Nichts in diesem Artikel ist Rechtsberatung.
FAQ
Wurde der EU AI Act verschoben?
Teilweise. Hochrisiko-Pflichten wandern unter einer vorläufigen politischen Einigung – Anhang-III-Systeme auf den 2. Dezember 2027, in Produkte eingebettete Anhang-I-Systeme auf den 2. August 2028. Die Transparenzpflichten aus Artikel 50 wurden nicht verschoben und gelten ab dem 2. August 2026.
Gilt Artikel 50 auch für mein Unternehmen, wenn ich kein Hochrisiko-System betreibe?
Ja, das ist möglich. Artikel 50 knüpft an Verhalten an, nicht an Risikoklasse: Systeme, die direkt mit Menschen interagieren, oder Systeme, die synthetische Audio-, Bild-, Video- oder Textinhalte erzeugen. Ein risikoarmer Support-Chatbot kann im Anwendungsbereich liegen, obwohl im Unternehmen sonst nichts hochriskant ist.
Reicht ein Hinweis in unseren AGB als Offenlegung?
Der Entwurf der Kommissions-Leitlinien behandelt einen Verweis in AGB oder Produktdokumentation als nicht ausreichend für die Pflicht aus Artikel 50(1) und behandelt reine Metadaten oder Wasserzeichen ebenfalls als nicht ausreichend. Die Richtung zeigt auf einen sichtbaren Hinweis in einfacher Sprache direkt auf der Interaktionsfläche.
Was bedeutet die Frist zum 2. Dezember 2026?
Eine begrenzte Übergangsfrist. Generative KI-Systeme, die bereits vor dem 2. August 2026 auf dem Markt sind, haben bis zum 2. Dezember 2026 Zeit, die maschinenlesbare Kennzeichnungspflicht nach Artikel 50(2) zu erfüllen. Sie verlängert nicht die übrigen Artikel-50-Pflichten und gilt nicht für Systeme, die nach dem 2. August 2026 gestartet werden.
Welche Sanktionen drohen bei einem Verstoß gegen Artikel 50?
Für Verstöße gegen Provider- und Deployer-Pflichten reicht der Bußgeldrahmen bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Wie die Aufsichtsbehörden in Österreich und Deutschland dies in der Praxis anwenden werden, entwickelt sich noch.
Nächster Schritt
Bringen Sie die Systeme mit, die mit Ihren Kunden sprechen, die Tools, die Ihre Inhalte generieren, Ihre Lieferantenverträge und das Inventar, das bereits existiert. Als AI Systems Architect kartiert Ali Najafzadeh den Artikel-50-Scope, bestimmt mit Ihnen Provider- und Deployer-Rollen, gestaltet die Offenlegungsflächen und hinterlässt Ihnen einen datierten Evidenznachweis statt einer Meinung. AI Systems Review vereinbaren.