Wer wissen will, ab wann die Kennzeichnungspflicht der KI-Verordnung greift, stößt schnell auf zwei Daten und viele offene Fragen zur Praxis. Dieser Artikel ordnet die Fristen der KI-Verordnung Kennzeichnungspflicht, erklärt, was „vor dem Geltungsbeginn in Verkehr gebracht" konkret bedeutet, und gibt euch einen Monat-für-Monat-Fahrplan bis zur Frist. Das Ganze ist eine praxisnahe Einordnung für Produktteams — keine Rechtsberatung; für verbindliche Bewertungen zieht bitte fachkundige Beratung hinzu.
Ab wann gilt die Kennzeichnungspflicht? Die zwei Daten
Für die Transparenzpflichten aus Artikel 50 der KI-Verordnung sind zwei Termine entscheidend:
- 2. August 2026 — ab diesem Tag gelten die Transparenzpflichten des Art. 50 grundsätzlich. Das ist der allgemeine Geltungsbeginn (Art. 113 der Verordnung).
- 2. Dezember 2026 — eine begrenzte Übergangsfrist kann die maschinenlesbare Kennzeichnung auf der Anbieterseite (Art. 50 Abs. 2) für berechtigte Systeme strecken, die bereits vor dem allgemeinen Geltungsbeginn am Markt waren.
Die zwei Daten betreffen also nicht dasselbe. Der 2. August 2026 markiert, ab wann die Pflichten überhaupt anwendbar sind. Der 2. Dezember 2026 ist eine eng gefasste Erleichterung nur für einen Teilaspekt — die maschinenlesbare Markierung synthetischer Ausgaben durch Anbieter — und nur für Bestandssysteme. Neue Systeme, die ihr nach dem 2. August 2026 auf den Markt bringt, können sich auf diese Streckung nicht berufen.
Den Wortlaut der Pflichten findet ihr direkt in Artikel 50; eine gut lesbare Aufbereitung bietet der AI Act Service Desk der EU-Kommission.
Die vier Pflichtenkategorien in einem Satz
Damit die Fristen greifbar werden, kurz die vier Bereiche des Art. 50 — prüft immer pro Produkt und pro System, nicht pauschal fürs ganze Unternehmen:
1. Art. 50 Abs. 1 — Interaktionshinweis (Betreiber/Anbieter): Menschen müssen erfahren, dass sie mit einem KI-System interagieren (Chatbots, Sprachassistenten), außer es ist für eine verständige Person ohnehin offensichtlich. 2. Art. 50 Abs. 2 — maschinenlesbare Markierung (Anbieter): Synthetisch erzeugte oder manipulierte Audio-, Bild-, Video- und Textausgaben müssen in einem maschinenlesbaren Format als künstlich erzeugt gekennzeichnet sein. 3. Art. 50 Abs. 3 — Emotionserkennung/biometrische Kategorisierung (Betreiber): Betroffene Personen sind zu informieren; personenbezogene Daten sind nach der DSGVO zu verarbeiten. 4. Art. 50 Abs. 4 — Deepfakes und öffentliche Texte (Betreiber): Deepfakes sind offenzulegen, ebenso KI-erzeugte oder manipulierte Texte, die zur Information der Öffentlichkeit über Angelegenheiten von öffentlichem Interesse veröffentlicht werden. Es gibt enge Ausnahmen (etwa redaktionelle Kontrolle, künstlerische oder satirische Werke).
Wichtig für die Fristenplanung: Nur die maschinenlesbare Markierung nach Abs. 2 ist von der Streckung bis 2. Dezember 2026 potenziell erfasst. Der Interaktionshinweis (Abs. 1) und die Offenlegungspflichten der Betreiber (Abs. 3, Abs. 4) orientieren sich am 2. August 2026.
Was heißt „vor dem Geltungsbeginn in Verkehr gebracht" praktisch?
Die Formulierung klingt juristisch, hat aber eine handfeste Konsequenz: Ob euer System schon am Markt war, entscheidet mit, ob die längere Frist für die maschinenlesbare Markierung überhaupt in Betracht kommt. Ein paar Leitplanken für die Selbsteinordnung:
- „In Verkehr gebracht" heißt bereitgestellt. Ein System, das vor dem 2. August 2026 bereits produktiv verfügbar war — also von Nutzerinnen und Nutzern in der EU eingesetzt werden konnte —, ist ein Bestandssystem. Eine interne Beta oder ein reiner Prototyp ohne Marktverfügbarkeit ist es in der Regel nicht.
- Der Stichtag ist scharf. Bringt ihr dasselbe Feature erst am oder nach dem 2. August 2026 heraus, greift die Streckung für Abs. 2 nicht — die maschinenlesbare Markierung sollte dann zum Start stehen.
- Die Erleichterung betrifft nur einen Baustein. Selbst wenn euer System als Bestand gilt, verschiebt sich nur die Anbieter-seitige maschinenlesbare Markierung. Sichtbare Hinweise für Nutzende (Abs. 1) und Betreiber-Offenlegungen (Abs. 4) plant ihr weiter zum 2. August 2026.
- „Bestand" ist kein Freibrief. Die Übergangsfrist ist ein Zeitpuffer für die technische Umsetzung, keine dauerhafte Ausnahme. Wer sie nutzt, sollte den Umbau bis zum 2. Dezember 2026 fest eingeplant haben.
Wann genau ein Produkt als „vor dem Geltungsbeginn in Verkehr gebracht" gilt und ob die Streckung im Einzelfall trägt, ist eine Bewertung, die von euren konkreten Release-Daten und Vertragsketten abhängt. Das ist ein typischer Punkt, an dem sich eine kurze Abstimmung mit fachkundiger Beratung lohnt.
Anbieter oder Betreiber — und beides zugleich?
Die Fristen hängen daran, in welcher Rolle ihr steht. Anbieter (provider) bringt ein KI-System auf den Markt oder nimmt es unter eigenem Namen in Betrieb; Betreiber (deployer) setzt es unter eigener Verantwortung ein. Viele Produktteams sind für Abs. 2 Anbieter (weil sie die generierende Funktion bereitstellen) und für Abs. 1/Abs. 4 zugleich Betreiber (weil sie das System im eigenen Produkt einsetzen). Genau diese Doppelrolle bestimmt, welche der zwei Fristen für welchen Baustein zählt.
Der bloße Aufruf einer fremden Modell-API (etwa von OpenAI oder Anthropic) nimmt euch die Pflichten für das von euch bereitgestellte oder betriebene System nicht ab. Das Anpassen oder Feintunen eines Allzweckmodells macht euch nicht automatisch zu dessen Anbieter — eine erhebliche Veränderung kann aber eine gesonderte GPAI-Einordnung auslösen. Das ist ein Grenzfall für die Rechtsberatung; die Leitlinien der Kommission zu GPAI-Anbietern geben den Rahmen.
Monat-für-Monat-Fahrplan bis zur Frist
Ein Datum im Kalender genügt nicht — hier ein realistischer Ablauf, der die knappe maschinenlesbare Markierung nach hinten legt und die sichtbaren Pflichten zuerst absichert. Passt die Monate an euren tatsächlichen Startpunkt an.
Ab sofort bis Ende Februar 2026 — Inventar. Listet pro Produkt jedes KI-System und jede generierende Funktion auf. Notiert je Eintrag: Rolle (Anbieter/Betreiber), Ausgabetyp (Text, Bild, Audio, Video), ob Nutzende direkt interagieren, ob Deepfake-Potenzial besteht, und das Datum der Marktverfügbarkeit. Dieses Inventar entscheidet später, welche Frist greift.
März 2026 — Einordnung. Ordnet jeden Eintrag den Abs. 1–4 zu. Markiert Systeme, die vor dem 2. August 2026 am Markt waren, als Kandidaten für die Streckung bis Dezember. Haltet die Zweifelsfälle fest, die ihr mit Beratung klären wollt (Doppelrollen, erhebliche Modelländerungen, Ausnahmen bei Abs. 4).
April 2026 — sichtbare Hinweise entwerfen. Formuliert den Interaktionshinweis (Abs. 1) und, wo einschlägig, die Deepfake- und Text-Offenlegung (Abs. 4). Klärt Platzierung, Zeitpunkt und Sprache. Diese Bausteine zielen auf den 2. August 2026 und brauchen meist Abstimmung mit Produkt, Design und Recht.
Mai 2026 — maschinenlesbare Markierung technisch spezifizieren. Legt fest, wie synthetische Ausgaben nach Abs. 2 maschinenlesbar gekennzeichnet werden — etwa über eingebettete Metadaten, HTML-Auszeichnung oder JSON-LD/Header-Metadaten. Definiert, wo im Ausgabepfad die Markierung entsteht und wie ihr sie nachprüfbar dokumentiert.
Juni 2026 — implementieren und intern verifizieren. Baut die sichtbaren Hinweise ein und startet die technische Markierung. Prüft an echten Ausgaben, ob die Kennzeichnung tatsächlich vorhanden und lesbar ist. Dokumentiert, was ihr geprüft habt — Nachvollziehbarkeit ist Teil der Sorgfalt.
Juli 2026 — Puffer und Review. Restpunkte schließen, Formulierungen mit Beratung gegenlesen, Sonderfälle final einordnen. Wenn ihr die maschinenlesbare Markierung für Bestandssysteme auf Dezember legt, dokumentiert bewusst, welche Systeme das betrifft und warum.
2. August 2026 — Stichtag 1. Sichtbare Hinweise (Abs. 1) und Betreiber-Offenlegungen (Abs. 3, Abs. 4) sollten stehen; für neue Systeme auch die maschinenlesbare Markierung.
August bis November 2026 — Markierung nachziehen. Für Bestandssysteme die maschinenlesbare Markierung nach Abs. 2 fertigstellen und verifizieren. Nicht bis zur letzten Woche warten — Encoding-Details und Ausgabepfade bergen erfahrungsgemäß Überraschungen.
2. Dezember 2026 — Stichtag 2. Ende der Streckung für die maschinenlesbare Markierung berechtigter Bestandssysteme.
Kurzer Worked-Example
Ein SaaS-Team betreibt einen KI-Chatbot (seit 2025 live) und eine neue Bildgenerierung (Start geplant Oktober 2026). Für den Chatbot gilt: Interaktionshinweis nach Abs. 1 zum 2. August 2026; die maschinenlesbare Markierung generierter Textausgaben nach Abs. 2 kann als Bestandssystem bis 2. Dezember 2026 nachgezogen werden. Für die Bildgenerierung gilt: Da sie erst nach dem Geltungsbeginn startet, greift die Streckung nicht — die maschinenlesbare Markierung der Bilder sollte zum Launch stehen. Ein Produkt, zwei Systeme, zwei unterschiedliche Fristen. Genau deshalb wird pro System geplant.
Maschinenlesbare Kennzeichnung: was sie ist und was nicht
Ein verbreitetes Missverständnis: Metadaten in HTML, JSON-LD oder Header-Feldern gälten als fälschungssichere Herkunftsnachweise. Das ist nicht der Fall. Diese Markierungen sind beratende Metadaten, keine signierte Provenienz. Sie sind keine C2PA-Zertifizierung und sollten nicht für sich allein als ausreichend behandelt werden. Sie erfüllen den maschinenlesbaren Charakter, den Abs. 2 verlangt, aber ob eure konkrete Umsetzung genügt, bestimmen die Verordnung und die offizielle Anleitung — nicht dieser Artikel.
Für die Ausgestaltung gibt es einen freiwilligen Verhaltenskodex zur Transparenz KI-generierter Inhalte. Er ist nicht verpflichtend, hilft aber, gängige Erwartungen an die Kennzeichnung einzuordnen.
Grenzüberschreitende Reichweite
Die Fristen betreffen nicht nur Teams mit Sitz in der EU. Die Pflichten des Art. 50 erfassen Anbieter und Betreiber außerhalb der EU, sobald ihre Systeme auf dem EU-Markt bereitgestellt werden oder deren Ausgaben in der EU genutzt werden. Wer also EU-Nutzende bedient, sollte die zwei Daten unabhängig vom eigenen Standort einplanen. Eine kompakte Erläuterung des Artikels findet ihr auch im Referenz-Explainer zu Artikel 50.
Nächster Schritt
Die Fristen sind machbar, wenn ihr jetzt pro Produkt ein Inventar aufstellt und die sichtbaren Pflichten zuerst absichert. Wenn ihr einen strukturierten Einstieg sucht, macht der kostenlose Readiness-Check von DiscloseKit die Pflichten je System sichtbar und unterstützt euch dabei, eure Umsetzung nachvollziehbar zu dokumentieren — als operative Standortbestimmung, nicht als Ersatz für die rechtliche Bewertung. Für verbindliche Fragen — insbesondere zu Rollen, Bestandssystemen und den Ausnahmen bei Abs. 4 — bleibt fachkundige Beratung der richtige Weg.