Artikel 50 Absatz 2 technisch umsetzen: maschinenlesbare KI-Kennzeichnung im eigenen Stack

Die meisten Compliance-Projekte zum EU AI Act enden bei einem Satz im Impressum und einem Hinweis im Chatfenster. Artikel 50 Absatz 2 lässt sich damit nicht erledigen. Die Vorschrift verlangt, dass die Ausgabe selbst maschinenlesbar markiert ist – nicht die Oberfläche, nicht die AGB, sondern der erzeugte Text, das erzeugte Bild, die erzeugte Audiodatei. Das ist keine Rechtsabteilungsaufgabe, sondern ein Eingriff in die Inferenz-Pipeline.

Dieser Artikel beschreibt, wo genau der Eingriff stattfindet, welche Verfahren 2026 produktionsreif sind, welche Angriffe dagegen publiziert wurden – und wie ein realistischer Umsetzungsplan bis zum 2. Dezember 2026 aussieht. Vorweg die wichtigste Unterscheidung, weil sie in fast jeder Zusammenfassung untergeht: Die Schonfrist bis Dezember gilt ausschließlich für Systeme, die vor dem 2. August 2026 in Verkehr gebracht wurden. Wer heute ein neues generatives System startet, hat null Tage Restlaufzeit.

Was Artikel 50 Absatz 2 verlangt

Art. 50 Abs. 2 der Verordnung (EU) 2024/1689 verpflichtet Anbieter von KI-Systemen, die synthetische Audio-, Bild-, Video- oder Textinhalte erzeugen, dafür zu sorgen, dass die Ausgaben „in einem maschinenlesbaren Format markiert und als künstlich erzeugt oder manipuliert erkennbar" sind. Der Gesetzgeber nennt bewusst keine Technologie. Stattdessen nennt er vier Qualitätskriterien, an denen sich jede gewählte Lösung messen lassen muss.

• Wirksam (effective): Die Markierung muss die Ausgabe tatsächlich als synthetisch erkennbar machen – nicht nur theoretisch.
• Interoperabel (interoperable): Dritte müssen sie mit gängigen Werkzeugen auslesen können. Ein proprietäres Format, das nur der eigene Detektor versteht, erfüllt das Kriterium nicht.
• Robust (robust): Die Markierung muss übliche Weiterverarbeitung überstehen – Formatwechsel, Kompression, Ausschnitte.
• Zuverlässig (reliable): Falsch-positive und falsch-negative Erkennungen müssen in einem vertretbaren Rahmen bleiben.

Alle vier stehen unter dem Vorbehalt „soweit technisch machbar", ausdrücklich unter Berücksichtigung der Besonderheiten und Grenzen der jeweiligen Inhaltsart, der Implementierungskosten und des allgemein anerkannten Stands der Technik. Dieser Vorbehalt ist kein Freibrief, sondern eine Dokumentationspflicht: Wer eine Lücke lässt, muss begründen können, warum sie beim aktuellen Stand der Technik unvermeidbar war.

Wen die Pflicht trifft – und wen nicht

Art. 50(2) adressiert den Anbieter. Art. 50(4) – die sichtbare Deepfake-Kennzeichnung und die Kennzeichnung von KI-erzeugtem Text zu Angelegenheiten von öffentlichem Interesse – adressiert dagegen den Betreiber. Diese Trennung entscheidet darüber, welche Pflicht bei Ihnen landet: Wer ein generatives System lediglich einsetzt, schuldet die sichtbare Kennzeichnung. Wer es unter eigenem Namen bereitstellt, schuldet zusätzlich die maschinenlesbare Markierung.

Zwei Ausnahmen nennt die Verordnung selbst: Systeme mit reiner Unterstützungsfunktion bei der Standardbearbeitung, die die Eingabedaten oder deren Semantik nicht wesentlich verändern – das klassische Beispiel ist die Grammatikkorrektur – sowie gesetzlich zur Aufdeckung und Verfolgung von Straftaten zugelassene Systeme. Ein Assistent, der aus drei Stichpunkten einen Angebotstext formuliert, fällt nicht darunter. Er verändert die Semantik erheblich.

Die Fristen: 2. August und 2. Dezember 2026

Artikel 50 gilt seit dem 2. August 2026. Damit sind die Chatbot-Offenlegung nach Abs. 1 und die Deepfake- sowie Textkennzeichnung nach Abs. 4 uneingeschränkt durchsetzbar. Für die maschinenlesbare Markierung nach Abs. 2 gibt es eine einzige, eng gefasste Sonderregel.

Pflicht	Adressat	Gilt seit / ab
Art. 50(1) – Offenlegung KI-Interaktion	Anbieter	02.08.2026
Art. 50(2) – maschinenlesbare Markierung, System ab 02.08.2026 in Verkehr	Anbieter	02.08.2026
Art. 50(2) – maschinenlesbare Markierung, Bestandssystem vor 02.08.2026	Anbieter	02.12.2026
Art. 50(4) – sichtbare Deepfake- und Textkennzeichnung	Betreiber	02.08.2026
Art. 99(4)/(6) – Sanktionsbefugnis der Marktüberwachung	–	02.08.2026

Die viermonatige Übergangsregel stammt aus dem Digital Omnibus on AI, dem im Juli 2026 in Kraft getretenen Änderungspaket. Wichtig für die Einordnung: Der Omnibus hat Artikel 50 inhaltlich nicht entschärft. Er hat lediglich die Übergangsregel für Abs. 2 auf gesetzliche Grundlage gestellt. Parallel verschob er Annex-III-Hochrisikopflichten auf den 2. Dezember 2027 und Annex-I-Pflichten auf den 2. August 2028 und führte zum 2. Dezember 2026 neue Verbote ein – unter anderem für nicht-einvernehmliche intime Bilddarstellungen und Darstellungen sexuellen Kindesmissbrauchs. Die Sanktionsbefugnis der nationalen Marktüberwachungsbehörden wurde nicht verschoben.

Der wirtschaftliche Rahmen: Verstöße gegen Art. 50 sind nach Art. 99(4) mit Geldbußen von bis zu 15 Millionen Euro oder 3 Prozent des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres bewehrt – je nachdem, welcher Betrag höher ist. Für den Mittelstand ist Art. 99(6) der relevantere Absatz: Für KMU und Start-ups gilt der jeweils niedrigere der beiden Beträge als Obergrenze. Das nimmt der Zahl 15 Millionen ihre Schockwirkung, macht die Pflicht aber nicht optional.

Textwasserzeichen im Sampling-Schritt

Bei Bild und Audio kann man ein Wasserzeichen nachträglich einbetten – das Signal lebt in den Pixel- oder Frequenzdaten und es gibt genug Redundanz, um es dort zu verstecken. Bei Text gibt es diese Redundanz nicht. Ein Satz besteht aus einer diskreten Folge von Tokens; jede nachträgliche Änderung ist entweder sichtbar oder trivial entfernbar.

Genau deshalb setzt die erfolgreiche Klasse von Textwasserzeichen – SynthID Text und die verwandten KGW-Schemata – nicht am fertigen Text an, sondern an der Stelle, an der er entsteht: beim Sampling. Technisch ist das ein LogitsProcessor, der in der Generierungsschleife nach Top-K- und Top-P-Filterung greift und die Token-Auswahl über eine pseudozufällige g-Funktion verschiebt (im Fall von SynthID Text über sogenanntes Tournament Sampling). Das Ergebnis liest sich für Menschen unverändert, trägt aber eine statistische Signatur, die ein Detektor mit dem passenden Schlüssel wiederfindet.

Warum nachträgliche Textmarkierungen das Robustheitskriterium reißen

Die naheliegenden Alternativen – Unicode-Homoglyphen, Zero-Width-Zeichen, charakteristische Whitespace-Muster – erfüllen die Kriterien aus Art. 50(2) nicht. Ein Copy-and-Paste in einen Plaintext-Editor entfernt sie vollständig, ohne dass der Anwender es merkt oder beabsichtigt. Wer sie als Hauptmaßnahme einsetzt, hat eine Markierung, die weder robust noch zuverlässig ist. Als zusätzliche Ebene sind sie unbedenklich, als einzige nicht.

Die praktische Konsequenz ist unbequem, aber eindeutig: Wer Textwasserzeichen setzen will, muss in die Inferenz-Schleife eingreifen können. Ein reiner API-Konsument kann das nicht.

SynthID Text: was quelloffen ist – und was nicht

Google DeepMind hat SynthID Text quelloffen gestellt. Die Referenzimplementierung liegt unter github.com/google-deepmind/synthid-text (Apache License 2.0), die produktionsreife Variante steckt seit v4.46.0 (Release 23. Oktober 2024) in Hugging Face Transformers. Konfiguriert wird über zwei Parameter:

• keys: die Wasserzeichen-Schlüssel. Empfohlen werden 20 bis 30 zufällige Ganzzahlen. Diese Liste ist das Geheimnis Ihres Systems – wer sie kennt, kann sowohl detektieren als auch fälschen.
• ngram_len: die Kontextlänge der g-Funktion. Minimum 2, Default 5. Kleinere Werte markieren aggressiver, größere sind unauffälliger, brauchen aber längere Texte für eine sichere Detektion.

Für die Detektion stehen zwei Wege offen: ein trainingsfreier Weighted-Mean-Detektor, der sofort einsatzbereit ist, und ein deutlich stärkerer Bayes-Detektor, der zuvor auf markierten und unmarkierten Beispielen trainiert werden muss. Für ein internes Prüfprotokoll reicht der Weighted-Mean-Detektor in der Regel aus; wer Detektion als Dienstleistung anbietet, wird um den Bayes-Detektor nicht herumkommen.

Zwei Einschränkungen gehören zwingend in jede Bewertung. Erstens: Nur die Text-Variante von SynthID ist Open Source. SynthID für Bild, Audio und Video ist es nicht – dafür brauchen Sie einen anderen Ansatz (siehe nächster Abschnitt). Zweitens: DeepMind weist selbst darauf hin, dass die Open-Source-Variante in Detektionsrate und Robustheit hinter Googles interner Implementierung zurückbleibt. Und die Erkennungssicherheit fällt laut Google und Hugging Face deutlich ab, wenn Text gründlich umgeschrieben oder in eine andere Sprache übersetzt wird. Ein Wasserzeichen ist kein Kopierschutz.

C2PA-Manifeste für Bild, Audio und Video

Für alles, was keine Tokenfolge ist, führt der Weg über C2PA – die Content Credentials der Coalition for Content Provenance and Authenticity. Ein C2PA-Manifest ist ein kryptografisch signierter Datensatz, der an die Mediendatei gebunden wird und festhält, womit sie erzeugt wurde, welche Bearbeitungsschritte folgten und wer dafür einsteht. Aktueller Stand der Spezifikation ist C2PA 2.3.

Der praktische Vorteil beim Selbstbetrieb: Sie signieren mit eigenen Zertifikaten. Der private Schlüssel liegt in Ihrem HSM oder Key-Vault und verlässt das Haus nicht. Das ist der Unterschied zwischen „ein Anbieter bestätigt, dass dieses Bild aus seinem Modell stammt" und „unser Unternehmen bestätigt mit seinem eigenen Schlüssel, dass dieses Bild aus unserer Pipeline stammt". Nur die zweite Aussage können Sie im Streitfall selbst belegen.

Die tatsächliche Grenze: Verarbeitungsketten ohne C2PA-Unterstützung

Die verbreitete Aussage „Re-Encoding entfernt C2PA" ist zu pauschal. C2PA-Manifeste überstehen die meisten Formatkonvertierungen und Re-Encodings – solange C2PA-fähige Werkzeuge im Spiel sind. Verloren gehen sie in drei Situationen:

1. Naives Re-Speichern mit einem Werkzeug ohne C2PA-Unterstützung. Der Inhalt bleibt, das Manifest fällt weg.
2. Screenshots. Hier entsteht eine neue Datei ohne jede Beziehung zum Original.
3. Plattform-Pipelines, die Metadaten strippen. Viele Bild- und Video-CDNs tun das aus Größen- und Datenschutzgründen automatisch.

Genau für diese Fälle sieht die C2PA-Spezifikation Soft Bindings vor: ein unsichtbares Wasserzeichen oder einen perzeptuellen Fingerprint, über den ein entferntes Manifest in einer Registry wieder aufgefunden werden kann. C2PA 2.3 bringt dafür eine eigene Soft Binding API mit. Wer nur das Manifest setzt und kein Soft Binding, hat die interoperable, aber nicht die robuste Ebene abgedeckt.

Defense in Depth statt Einzelmaßnahme

Im Umfeld des Code of Practice wird ausdrücklich festgehalten, dass derzeit keine einzelne Markierungstechnologie alle vier Kriterien gleichzeitig erfüllt und dass forensische Detektionsverfahren noch nicht als hinreichend zuverlässig gelten – gemeinsame Evaluations-Benchmarks fehlen schlicht. Der Code empfiehlt deshalb explizit geschichtete Lösungen aus Metadaten, Wasserzeichen und Provenance-Mechanismen; im Entwurf wurde C2PA als Beispiel einer Lösung genannt, die alle vier Kriterien adressiert, verbunden mit der Empfehlung, C2PA mit unsichtbaren Wasserzeichen zu kombinieren.

Dass eine einzelne Schicht nicht trägt, ist keine Vorsichtsformel, sondern empirisch belegt. Die Arbeit „Watermark Stealing in Large Language Models" von Nikola Jovanović, Robin Staab und Martin Vechev (SRI Lab, ETH Zürich, ICML 2024) zeigt: Ein Angreifer kann für unter 50 US-Dollar an API-Kosten das Wasserzeichen-Schema eines Anbieters einmalig rekonstruieren – schlicht, indem er die öffentliche API mit einer begrenzten Zahl von Prompts abfragt und aus den Antworten die Verteilungsverschiebung zurückrechnet. Danach sind beliebig viele Angriffe ohne weiteren Aufwand möglich, in beide Richtungen.

Angriff (ETH Zürich, ICML 2024)	Wirkung	Erfolgsquote	Baseline vorher
Spoofing	Unmarkierter Text wird fälschlich dem Anbieter zugerechnet	> 80 %	< 25 %
Scrubbing	Vorhandenes Wasserzeichen wird aus markiertem Text entfernt	> 80 %	< 25 %
Kosten der Schema-Rekonstruktion	Einmalig, danach unbegrenzt viele Angriffe kostenlos	< 50 USD	–

Angegriffen wurde KGW2-SelfHash, ein zuvor als sicher geltendes State-of-the-Art-Schema. Zwei Lehren daraus. Erstens: Spoofing ist für ein Unternehmen die gefährlichere Richtung. Wer Ihr Schema rekonstruiert hat, kann beliebigen Text erzeugen, den Ihr eigener Detektor als aus Ihrem Haus stammend ausweist. Zweitens: Wer sein Wasserzeichen-Schema nicht über eine offene, unlimitierte API der Welt zur Verfügung stellt, macht die Rekonstruktion erheblich teurer – das ist ein zusätzliches Argument für den Betrieb hinter der eigenen Firewall und für Rate Limits auf allen exponierten Generierungsendpunkten.

Die praktikable Antwort ist eine dreischichtige Architektur, die sich mit üblichen Guardrails und einer sauberen LLMOps-Pipeline umsetzen lässt:

• Ebene 1 – Wasserzeichen im Sampling (Text) beziehungsweise unsichtbares Wasserzeichen als Soft Binding (Medien). Deckt Robustheit ab, hält aber gezielten Angriffen nicht dauerhaft stand.
• Ebene 2 – signierte Provenance-Metadaten per C2PA-Manifest mit eigenen Zertifikaten. Deckt Interoperabilität und Nachweiswert ab, überlebt aber nicht jede Verarbeitungskette.
• Ebene 3 – serverseitiges Generierungsprotokoll. Für jede Ausgabe: Zeitstempel, Modell- und Adapterversion, Prompt-Hash, Ausgabe-Hash, Nutzer- oder Systemkennung, verwendeter Wasserzeichen-Schlüsselindex. Diese Ebene ist unabhängig von der Datei und damit die einzige, die ein Angriff auf die Datei nicht erreicht.

Ebene 3 wird regelmäßig unterschätzt. Sie ist der eigentliche Nachweis im Streitfall: Wenn ein Kunde behauptet, ein Text stamme aus Ihrem System, und Ihr Protokoll den Ausgabe-Hash nicht kennt, ist das ein belastbares Gegenargument – auch wenn das Wasserzeichen gespooft wurde. Umgekehrt beweist ein Treffer im Protokoll die Herkunft besser als jedes statistische Signal. Achten Sie beim Design auf Datensparsamkeit: Prompt-Hash statt Prompt-Klartext, definierte Löschfristen, Zugriffsbeschränkung auf das Compliance-Team.

Warum das nur beim Self-Hosting vollständig kontrollierbar ist

Ein verbreitetes Missverständnis vorweg: On-Premise-Betrieb befreit nicht von Art. 50(2) – er verlagert die Pflicht auf Ihr Unternehmen. Wer ein Open-Weight-Modell selbst hostet und ein generatives System unter eigenem Namen in Verkehr bringt oder in Betrieb nimmt, wird damit selbst zum Anbieter im Sinne der Verordnung. Nach Art. 25 wird auch ein Betreiber zum Anbieter, wenn er ein System wesentlich verändert, feinabstimmt oder unter eigenem Namen vermarktet. Ein fein abgestimmtes Modell auf eigener Hardware erfüllt diese Merkmale in aller Regel.

Das tragfähige Argument für Self-Hosting ist deshalb kein Befreiungs-, sondern ein Kontrollargument. Drei Stellschrauben lassen sich ausschließlich im eigenen Stack bedienen:

Stellschraube	Eigener Inferenz-Stack	Geschlossene SaaS-API
Sampling-Schleife	Eigener Logits-Processor, Parameter frei wählbar	Kein Zugriff – Sie erben, was eingebaut ist
Schlüsselmanagement	Wasserzeichen-Keys und C2PA-Signaturschlüssel im eigenen HSM	Schlüssel liegen beim Anbieter
Detektion	Eigener Detektor, jederzeit auditierbar	Abhängig von Verfügbarkeit und Bestand des Anbieterdienstes
Nachweisdokumentation	Vollständig im Haus, ohne Drittabhängigkeit vorlegbar	Erfordert Auskunft und Mitwirkung des Anbieters

Bei einer geschlossenen API erben Sie die Markierung des Anbieters samt ihrer Lücken – und können sie weder prüfen noch nachbessern. Ändert der Anbieter sein Schema, stellt seinen Detektionsdienst ein oder wird sein Schema wie im ETH-Szenario rekonstruiert, verlieren Sie Ihre Nachweisfähigkeit, ohne selbst etwas falsch gemacht zu haben. Wer die Inferenz im Haus betreibt, trägt mehr Pflicht, hat aber auch die Mittel, sie nachweisbar zu erfüllen.

Ein Nebeneffekt, der in der Praxis schwerer wiegt als erwartet: Bei selbst betriebener Inferenz können Sie das Wasserzeichen auch dort setzen, wo die Ausgabe nicht unmittelbar an einen Menschen geht – in Batch-Jobs, in Agenten-Pipelines, in nachgelagerten Systemen. Genau diese Kanäle werden bei Inventuren regelmäßig übersehen und sind zugleich die, aus denen Deepfake- und Fehlzuschreibungsrisiken erwachsen.

Umsetzungsplan bis Dezember 2026

Phase 1 – Inventar (empfohlen: bis Ende August 2026)

Erfassen Sie jede Stelle, an der Ihr Unternehmen synthetische Inhalte erzeugt und nach außen oder in nachgelagerte Systeme gibt. Pro Eintrag gehören in die Liste: Modalität (Text, Bild, Audio, Video), Modell und Version, Datum des Inverkehrbringens beziehungsweise der Inbetriebnahme, Ausgabekanal, Rolle Ihres Unternehmens (Anbieter oder Betreiber) und die Frage, ob eine der beiden Ausnahmen greift. Erfahrungsgemäß findet dieser Schritt zwei bis drei Kanäle, die niemand auf dem Zettel hatte – typischerweise API-Integrationen in Fachanwendungen und automatisierte Batch-Generierung.

Phase 2 – Pilot auf einem Modell (September 2026)

1. Ein System auswählen, idealerweise mit hohem Volumen und geringem Risiko. Inferenz-Stack auf eine Version bringen, die den benötigten Logits-Processor unterstützt (Transformers ab 4.46.0 für SynthID Text).
2. Schlüsselmaterial erzeugen und ablegen: 20–30 Wasserzeichen-Keys, C2PA-Signaturzertifikat. Beides ins HSM oder den Key-Vault, mit dokumentiertem Rotationskonzept.
3. Markierung aktivieren und messen: Latenz, Durchsatz, Ausgabequalität gegen die unmarkierte Baseline. Erfahrungswert für Text: einstelliger Prozentbereich beim Durchsatz.
4. Detektionspfad aufbauen. Ohne funktionierenden Detektor ist die Markierung wertlos – Sie können weder prüfen noch nachweisen.
5. Generierungsprotokoll scharfschalten und die Datenschutzfolgen dokumentieren.

Phase 3 – Rollout (Oktober bis November 2026)

Ausrollen über die restlichen Systeme, nach Risiko und Volumen priorisiert. Für Bild-, Audio- und Video-Pipelines: C2PA-Manifest plus Soft Binding, nicht nur das Manifest. Für alle Kanäle: prüfen, ob nachgelagerte Systeme oder das CDN die Metadaten strippen – wenn ja, ist das Soft Binding nicht optional, sondern die einzige verbleibende Ebene. Parallel die Betreiberpflichten aus Art. 50(4) abgleichen, sofern Sie fremde Systeme einsetzen; die gelten bereits seit August.

Phase 4 – Nachweis (fortlaufend ab Dezember 2026)

Der Auditnachweis besteht aus drei Dokumenten, die Sie ohnehin erzeugen, wenn Sie die Phasen 1 bis 3 sauber durchlaufen:

• Prüfprotokoll je System: welches Verfahren, welche Parameter, welche Version, seit wann aktiv, wer verantwortlich.
• Stichprobentests: monatlich eine definierte Zahl von Ausgaben je Kanal durch den eigenen Detektor schicken und Trefferquote protokollieren. Ein einfacher Cron-Job genügt – das Protokoll ist das Beweismittel.
• Begründete Lückenliste: Wo die Markierung technisch nicht machbar ist, halten Sie fest, warum, welche Alternativen geprüft wurden und wann Sie erneut prüfen. Genau das meint der Vorbehalt „soweit technisch machbar" in Art. 50(2).

Wer die Fristen und Pflichten des AI Act über einzelne Systeme hinweg strukturiert erfassen will, findet den vollständigen Rahmen auf unserer Übersicht zum EU AI Act 2026 und in der EU-AI-Act-Checkliste. Für die technische Seite – Inferenz-Stack, Schlüsselmanagement, Protokollierung – ist der Betrieb auf eigener On-Premise-Infrastruktur die Voraussetzung dafür, alle drei Ebenen tatsächlich selbst in der Hand zu haben.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. AI Act Explorer transparency rules article 50
2. cooley.com 2026 08 03 eu ai act transparency obligations take effect 2 august 2026
3. gibsondunn.com eu ai act omnibus agreement postponed high risk deadlines and other key changes
4. usercentrics.com eu ai act high risk delay article 50 transparency consent
5. compliancehub.wiki eu ai act article 50 transparency digital omnibus 2026
6. Europäische Kommission – Digital Strategy code practice ai generated content
7. Europäische Kommission – Digital Strategy commission publishes code practice marking and labelling ai generated content
8. Europäische Kommission – Digital Strategy strong backing code practice transparency ai generated content
9. Europäische Kommission – Digital Strategy guidelines transparency ai generated content
10. techpolicy.press the eus ai transparency code of practice explained
11. watermark-stealing.org
12. arXiv 2402.19361

Häufig gestellte Fragen zur Kennzeichnungspflicht nach Art. 50

Bis wann muss die maschinenlesbare Kennzeichnung stehen?

Artikel 50 ist seit dem 2. August 2026 durchsetzbar. Für Systeme, die vor diesem Datum in Verkehr gebracht wurden, gilt die Markierungspflicht nach Absatz 2 erst ab dem 2. Dezember 2026. Für jedes System, das am oder nach dem 2. August 2026 in Verkehr gebracht oder in Betrieb genommen wird, gibt es keine Schonfrist – dort gilt die Pflicht sofort.

Reichen C2PA-Metadaten aus?

In der Regel nicht allein. C2PA-Manifeste überstehen Formatkonvertierungen und Re-Encodings, solange C2PA-fähige Werkzeuge im Spiel sind – sie gehen aber bei naivem Re-Speichern ohne C2PA-Unterstützung, bei Screenshots und in metadatenstrippenden Plattform-Pipelines verloren. Die Verordnung verlangt eine robuste und zuverlässige Markierung. Praktisch bedeutet das die vom Code of Practice empfohlene Kombination aus signierten Metadaten, unsichtbarem Wasserzeichen und serverseitiger Protokollierung.

Kann ich die Kennzeichnung von meinem Modellanbieter erben?

Bei Textausgaben aus selbst gehosteten Open-Weight-Modellen nicht. Ein Wasserzeichen der SynthID- oder KGW-Klasse entsteht im Sampling-Schritt der Generierung. Wer selbst hostet, führt diesen Schritt selbst aus – und wird durch das Inverkehrbringen unter eigenem Namen nach Art. 50(2) und gegebenenfalls Art. 25 selbst zum pflichtigen Anbieter. Bei einer geschlossenen SaaS-API erben Sie umgekehrt genau die Markierung des Anbieters samt ihrer Lücken und können sie weder prüfen noch nachbessern.

Was droht bei Verstößen gegen Artikel 50?

Nach Art. 99(4) AI Act drohen Geldbußen bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres – je nachdem, welcher Betrag höher ist. Für KMU und Start-ups gilt nach Art. 99(6) der jeweils niedrigere Betrag als Obergrenze. Die Sanktionsbefugnis der nationalen Marktüberwachungsbehörden ist seit dem 2. August 2026 aktiv und wurde vom Digital Omnibus nicht verschoben.