KI-VERORDNUNG · ARTIKEL 50(2)Lucairn / Compliance

Maschinenlesbare Kennzeichnung synthetischer Inhalte —
was die Verordnung verlangt, was Lucairn liefert.

Wirksam ab 2. Dezember 2026.

Artikel 50(2) der EU-KI-Verordnung verlangt von Anbietern von KI-Systemen, die synthetische Audio-, Bild-, Video- oder Textinhalte erzeugen, dass die Ausgaben in einem maschinenlesbaren Format gekennzeichnet und als künstlich erzeugt erkennbar sind. Die Pflicht wird wirksam am 2. Dezember 2026 — ein Kompromissdatum aus dem Digital-Omnibus-Paket vom Mai 2026. Die Verordnung gibt die Kennzeichnungstechnik nicht vor; die Normungsarbeit bei CEN-CENELEC JTC 21 und ISO/IEC läuft, die Anleitung des KI-Büros steht noch aus. Bis diese feststeht, brauchen Nutzer und Anbieter einen vertretbaren Mechanismus. Diese Seite erklärt, was die Pflicht tatsächlich verlangt, warum Hinweistext allein nicht ausreicht und wie Lucairns Decision Certificate pro Konversation auf den wahrscheinlichen Prüfmassstab eines Aufsehers nach Artikel 74 abbildet.

01Was die Verordnung sagt

Artikel 50(2),
im Klartext.

Artikel 50(2), wörtlich:
“Anbieter von KI-Systemen, einschließlich KI-Systemen mit allgemeinem Verwendungszweck, die synthetische Audio-, Bild-, Video- oder Textinhalte erzeugen, stellen sicher, dass die Ausgaben des KI-Systems in einem maschinenlesbaren Format gekennzeichnet und als künstlich erzeugt oder manipuliert erkennbar sind.”
KI-Verordnung · Artikel 50(2) · konsolidierter Text via EUR-Lex
A

Was „maschinenlesbar“ hier bedeutet.

Erkennbar durch einen automatisierten Prozess, nicht nur durch einen Menschen, der einen Hinweis liest. Das ist die entscheidende Verschiebung weg vom Hinweistext als Compliance-Ansatz. Ein Datenschutz-Banner, das sagt „dieser Inhalt wurde mit KI erzeugt“, hält nicht stand, wenn ein Aufseher einen Detektor gegen die tatsächliche Datei laufen lässt.

B

Was Artikel 50(2) NICHT festlegt.

Die Kennzeichnungstechnik. Den Detektor. Die Aufteilung der Verantwortung zwischen Anbieter und Nutzer für Kennzeichnung versus Erkennung. Das wird in der CEN-CENELEC-JTC-21-Normungsarbeit (laufend) und in der Anleitung des KI-Büros (ausstehend) geklärt. Wer heute eine Artikel-50(2)-Zertifizierung verkauft, überzieht — die Standards sind nicht finalisiert.

C

Querverweis auf Artikel 50(4).

Nutzer synthetischer Inhalte legen offen. Anbieter nach 50(2) kennzeichnen. Die Kennzeichnung muss in der Antwort vorhanden sein, damit die Offenlegung des Nutzers verifizierbar ist. Die beiden Absätze sind verkettet — fehlt oder verschwindet die Kennzeichnung des vorgelagerten Anbieters, wird die Offenlegung des nachgelagerten Nutzers unfalsifizierbar.

02Warum Hinweistext nicht reicht

Die Frage des Aufsehers
lautet pro Ausgabe, nicht pro Policy.

Die Frage eines Aufsehers nach Artikel 74 lautet: „Zeigen Sie mir für diese konkrete Ausgabe, dass sie zum Zeitpunkt der Erzeugung gekennzeichnet wurde.“ Ein Datenschutzhinweis oder ein Banner, der sagt „wir kennzeichnen unsere Inhalte“, beantwortet diese Frage nicht. Die Verteidigung verlangt vier Eigenschaften zusammen:

  • Ein Artefakt, das an die konkrete Ausgabe gebunden ist. Keine Policy, die generisch auf „alle KI-erzeugten Inhalte“ verweist. Ein Beleg, der an diesen Hash, diesen Prompt, diese Antwort gebunden ist.
  • Erzeugt zum Zeitpunkt der Generierung. Nicht nachträglich aus Logs rekonstruiert, nachdem eine Beschwerde eintrifft. Der Zeitstempel ist entscheidend, weil retrospektive Kennzeichnung genau das ist, was eine Untersuchung ausschliesst.
  • Verifizierbar durch eine unabhängige Partei. Der Prüfer sollte nichts auf das Wort des Nutzers oder Anbieters verlassen müssen. Die Signatur, der Inklusionsbeweis, die Zeitstempel-Authority — alles überprüfbar ohne Lucairn oder den Nutzer zu kontaktieren.
  • Nicht entfernbar oder veränderbar durch Nutzer oder nachgelagerte Plattformen. Eine Kennzeichnung, die in veränderlichen Anwendungslogs steckt, scheitert an dieser Eigenschaft. Ein signierter externer Beleg, der an einem öffentlichen Transparenz-Log verankert ist, überlebt eine Operator-Kompromittierung.

Das ist dieselbe Lücke, die der Eckpfeiler-Beitrag zu den Artikel-50-Pflichten für Nutzer beschreibt — siehe Artikel 50 der EU-KI-Verordnung — was GPAI-Nutzer bis August 2026 tatsächlich umsetzen müssen. Artikel 50(2) macht die Lücke schärfer, weil der Aufseher einen Detektor direkt gegen den Inhalt laufen lassen kann; der Nutzer kann das Fehlen einer Kennzeichnung nicht durch Verweis auf einen Policy-Text verteidigen.

03Was Lucairn liefert

Eine signierte Quittung
pro Konversation, durch Konstruktion.

Im Klartext. Architektur auf Artikel 50(2) abgebildet:

  • Decision Certificate pro Konversation. Jeder Inferenz-Aufruf, der über das Lucairn-Gateway läuft, erzeugt eine signierte Quittung. Die Quittung bindet: die Eingabe (sanitisierter Prompt-Hash), die Ausgabe (sanitisierter Antwort-Hash), die Modellkennung, den Zeitstempel und die Signaturen der beteiligten Dienste (Sanitizer, Bridge, Gateway, Sandbox-B-Inferenz). Der Witness-Assembler-Dienst im Repository ist für die Signable-Konstruktion zuständig.
  • Ed25519-Signaturen. Jeder beteiligte Dienst signiert seine Behauptung. Der Witness signiert anschliessend das zusammengesetzte Zertifikat über eine 7-Schlüssel-Signable-Map, die durch einen Invariant-Test im Repository festgelegt ist. Die kryptographische Kette ist aus dem öffentlichen Lucairn-Keystore-Endpunkt rekonstruierbar.
  • Sigstore-Rekor-v2-Verankerung. Inklusionsbeweise werden in das öffentliche Rekor-Transparenz-Log geschrieben (Rekor v2, GA Oktober 2025). Jeder kann verifizieren, dass das Zertifikat vor jedem strittigen nachgelagerten Ereignis veröffentlicht wurde — eine Eigenschaft, die der Nutzer nachträglich nicht herstellen kann.
  • FreeTSA-RFC-3161-Zeitstempel. Unabhängiger Zeitanker, der weder von Lucairns Uhr noch von Rekors Uhr abhängt. RFC 3161 ist der Standard, den Finanzdienstleistung und Dokumenten-Archivierung seit zwei Jahrzehnten nutzen.
  • Detektor auf Empfänger-Seite. Die öffentliche /verify-Seite akzeptiert eine Zertifikat-ID oder URL und rekonstruiert die Kette. Programmatische Verifikation über die veröffentlichten SDKs (Python, TypeScript, Go) auf /developer.

Was das nicht ist. Es ist kein Wasserzeichen, das in den Audio-/Bild-/Video-/Text-Inhalt selbst eingebettet ist. Lucairn liefert eine signierte externe Quittung, die an den Inhalt gebunden ist. Das ist eine vertretbare Antwort auf „maschinenlesbare Kennzeichnung“; es ist nicht die einzige Architektur, die der Aufseher akzeptieren wird, und die Verordnung empfiehlt keine konkrete Technik.

04Wie ein 7-Monats-Pfad aussieht

Ungefähr dreissig Wochen
bis zum 2. Dezember 2026.

Auf einen Einzel-Team-Rollout kalibriert. Die Form lässt sich auf grössere Organisationen übertragen; nur das Scoping in Wochen 1–4 ändert sich wesentlich.

Wochen 1–4

Inventar.

Listen Sie jede Stelle auf, an der Ihr Produkt oder Workflow synthetische Inhalte erzeugt. Klassifizieren Sie jede in: Texterzeugung (LLM-Completion / Chat-Ausgabe), Bilderzeugung, Audio-Synthese (TTS, Speech-to-Speech), Videoerzeugung. Die meisten Teams unterschätzen die Anzahl der Pfade — interne Tools und Slack-integrierte Agenten fehlen meistens beim ersten Durchgang.

Wochen 5–10

Kennzeichnungsansatz entscheiden.

Native Wasserzeichen (modellseitig) für Bild und Audio — Frequenzbereichs- oder Spread-Spectrum-Techniken sind ausgereift; bei Text ist Wasserzeichnung heute umstritten (siehe C2PA Content Credentials und aktuelle akademische Literatur). Externe signierte Quittungen (die Architektur-Klasse von Lucairn). Oder beides. Die Wahl ist teilweise vertraglich: an welche vorgelagerten GPAI-Anbieter sind Sie gebunden, und welche Kennzeichnung liefern diese?

Wochen 11–18

Erkennungspfad bauen.

Ein Aufseher nach Artikel 74 wird seinen Detektor laufen lassen. Ist Ihre Kennzeichnung intern (natives Wasserzeichen), kommt der Detektor mit dem Modell oder mit C2PA-fähigem Werkzeug. Ist Ihre Kennzeichnung extern (signierte Quittung), ist Ihr Detektor Ihr /verify-Endpunkt oder Ihr SDK. So oder so muss das Runbook des Nutzers den Detektor vor einem Vorfall dokumentieren.

Wochen 19–26

Vertragskette verknüpfen.

Hängen Sie für die Kennzeichnung von einem GPAI-Anbieter ab, muss Ihr Vertrag dessen Artikel-50(2)-Compliance, den verwendeten technischen Mechanismus und Ihren Zugang zum Verifikationspfad abdecken. Die Artikel-50(4)-Offenlegung des Nutzers muss auf eine verifizierbare vorgelagerte Kennzeichnung zeigen — sonst ist die Offenlegung Hearsay.

Wochen 27–30

Audit-Probelauf wie ein Aufseher.

Wählen Sie eine synthetische Inhaltsprobe aus der Produktion, geben Sie sie jemandem ausserhalb des Teams, lassen Sie sie die Kennzeichnung verifizieren. Gelingt das nicht, ist die Lücke vor dem 2. Dezember 2026 real. Der Probelauf ist die einzige Ausgabe, die „wir glauben, dass wir konform sind“ als Verteidigung überlebt.

05Was Lucairn nicht behauptet

Der ehrliche Scope
dieses Mechanismus.

  • Lucairn behauptet keine Artikel-50(2)-Compliance im Namen eines Kunden. Die Verordnung bindet den Anbieter des KI-Systems; Lucairn ist Infrastruktur, mit der Ihr Team die Beweisschicht erzeugt. Compliance ist eine Verantwortlichen-Pflicht mit Governance, Risikomanagement und nutzerseitiger Offenlegung nach Artikel 50(4) — Lucairn deckt die technische Fläche ab; Ihr CISO und Ihre Datenschutzbeauftragte decken den Rest.
  • Lucairn behauptet nicht, sein Quittungs-Ansatz sei die einzige akzeptable Artikel-50(2)-Kennzeichnungstechnik. Die Verordnung gibt absichtlich keine Technik vor, und die CEN-CENELEC-JTC-21- und ISO/IEC-Normungsarbeit läuft. Wenn die Standards landen, müssen Anbieter neu bewerten — Lucairn eingeschlossen.
  • Lucairn bettet keine Wasserzeichen in den Ausgabeinhalt selbst ein. Verlangt Ihr Anwendungsfall inhaltsgebundene Wasserzeichen (reine Bild-Deployments, Broadcast-Workflows, Datei-Archivierungspipelines), ergänzt die Lucairn-Quittung das, ersetzt es aber nicht.
  • Die Verordnung kann sich vor dem 2. Dezember 2026 weiterentwickeln. Sekundärrechtsakte, Anleitungen des KI-Büros oder weitere Omnibus-Revisionen können die operative Form ändern. Beobachten Sie das — das Datum der Pflicht steht fest, die Umsetzungsanleitung ist noch in Bewegung.
06Nächste Schritte

Ein Beispiel-Zertifikat verifizieren
oder die vollständige Pflichten-Karte sehen.

Die architektonische Aussage ist überprüfbar. Die Verify-Seite lässt Sie ein echtes signiertes Zertifikat prüfen, ohne Lucairn zu kontaktieren; die KI-Verordnung-Compliance-Seite bildet auf dieselbe Weise jede andere Pflicht (Artikel 12, 13, 14, 15, Anhang IV) auf Beleg-Felder ab.

Beispiel-Zertifikat verifizieren →Vollständige Pflichten-Karte ansehen →

REFERENZEN