BLUF: Eine Kennzeichnung für KI-Inhalte ist nur dann belastbar, wenn Offenlegungsentscheidung, sichtbarer Hinweis und maschinenlesbare Markierung jede Grenze zwischen Generierung und Publikum überstehen. Behandeln Sie Transparenz als durchgängigen Datenvertrag: Output und Akteursrolle klassifizieren, Provenienzdatensatz erzeugen, mit dem Asset binden, Offenlegung bei CMS- und Exporttransformationen erhalten oder neu materialisieren, die ausgelieferte Repräsentation prüfen und die Entscheidungsevidenz aufbewahren. Metadaten allein sind zu fragil; ein sichtbares Badge allein ist keine maschinenlesbare Provenienz.
Dieser Beitrag ist technische Orientierung und keine Rechtsberatung. Artikel 50 trennt Pflichten von Anbietern für direkte Interaktion und maschinenlesbare Markierung von Offenlegungspflichten bestimmter Betreiber. Anwendungsbereich, Ausnahmen, Akteursrolle und die Wirkung von Änderungen müssen anhand des aktuellen konsolidierten Rechts und durch qualifizierte Rechtsberatung geprüft werden.
Beginnen Sie mit der rechtlichen Trennung—nicht mit einem universellen „KI-Label“-Schalter
Der offizielle AI-Act-Text und die Leitlinien der Kommission zu Artikel 50 definieren keine identische Kennzeichnung für jeden KI-unterstützten Satz. Artikel 50 Absatz 1 betrifft die direkte Interaktion mit einem KI-System. Absatz 2 verlangt von Anbietern generativer Systeme eine maschinenlesbare und erkennbare Markierung, berücksichtigt aber technische Machbarkeit, Inhaltstyp, Kosten, Stand der Technik und benannte Ausnahmen. Absatz 4 betrifft Betreiberhinweise für Deepfakes und bestimmte Texte zu Angelegenheiten von öffentlichem Interesse. Absatz 5 fordert klare, unterscheidbare und barrierefreie Information spätestens bei der ersten Interaktion oder Exposition.
Die FAQ der Kommission differenziert zusätzlich zwischen Anbieter und Betreiber, Standardbearbeitung, Maschine-zu-Maschine-Ausgaben, geschlossenen Industrie- oder Produktentwicklungsumgebungen und menschlicher redaktioneller Kontrolle. Diese Unterscheidungen gehören in eine von der Rechtsfunktion freigegebene Anwendbarkeitsregel—nicht in einen von Engineering geratenen Boolean. Die Architektur führt die geprüfte Entscheidung aus und bewahrt ihre Evidenz.
Die kritische Grenze ist die Exportgrenze
Ein Generator kann korrekt markieren, während die ausgelieferte Datei die Markierung verliert. Bildskalierung entfernt EXIF oder XMP. Ein Screenshot lässt DOM-Metadaten zurück. PDF-Druck kann Dokument- und Barrierefreiheitsmetadaten abflachen. Videotranscoder entfernen Containerfelder. Ein CMS bewahrt das Original, erzeugt aber Derivate ohne benutzerdefinierte Metadaten. Plattformen kodieren Medien neu; Copy-and-paste trennt Text vom Provenienznachweis. Die relevante Prüfung lautet daher nicht „Hat das Modell markiert?“, sondern „Was erhielt das Publikum nach der realen Transformationskette?“
Das ist eine andere Kontrolle als Logging und technische Dokumentation. Logs belegen Entscheidung und Systemhandlung, machen aber keinen Hinweis für das Publikum sichtbar. Ein sichtbares Label rekonstruiert umgekehrt weder Modell noch Policy-Version, Ausnahme oder Transformation. Verbinden Sie beide Ebenen über stabile IDs, ohne vertrauliche Logs offenzulegen.
Referenzarchitektur: von der Generierung bis zur Auslieferung
GENERIERUNGSEREIGNIS → Content Classifier → Akteurs- und Scope-Policy → Offenlegungsentscheidung → Provenienzdatensatz + Content-Digest → [maschinenlesbare Markierung / sichtbarer Hinweis / beides] → Source-Asset-Registry → CMS-Ingest → Derivative Builder → API- oder Dokumentexport → Channel Adapter → Prüfung der ausgelieferten Repräsentation → Evidence Store und Exception Queue. Jeder Pfeil ist ein Transformationsvertrag. Jede Ausgabevariante erhält eigenen Digest und Prüfstatus.
Für die Anwendbarkeitsentscheidung können Sie Beziehungen aus einem KI-Anwendbarkeitsgraphen für Use Cases wiederverwenden: Systemanbieter, einsetzende Organisation, Zweck, Modalität, Publikum, redaktionelle Verantwortung, Kanal und Jurisdiktion. Trennen Sie rechtliche Aussagen—etwa eine genehmigte Ausnahme—von berechneten technischen Fakten wie „XMP fehlt nach Resize“.
Nutzen Sie einen Provenienzumschlag statt einer Metadatenannahme
Definieren Sie einen unveränderlichen Provenienzumschlag je Inhaltsversion. Mindestfelder: provenance_id, parent_provenance_id, content_digest und Algorithmus, asset_id und variant_id, System- und Release-Referenz, Anbieter-/Betreiberassertion, Modalität, disclosure_policy_id und Version, Entscheidung, erforderliche Oberflächen, Ausnahme mit Owner und Evidenzreferenz, Transformationshistorie, Zeitstempel, Prüfstatus, Signatur-/Schlüsselreferenz, Aufbewahrungsklasse und gegebenenfalls redaktionelle Verantwortung. Speichern Sie keine personenbezogenen Daten, Prompts oder vertraulichen Quellen in öffentlichen Metadaten.
Der Umschlag ist das führende System; eingebettete Metadaten sind nur ein Träger. Signieren Sie den kanonischen Datensatz oder speichern Sie ihn append-only und binden Sie jedes Export-Asset per Digest. Wenn eine Transformation Bytes ändert, erzeugen Sie einen Child-Umschlag. So bleibt die Kette explizit: Original → skaliertes Bild → WebP-Karte → PDF-Anhang → Plattformderivat.
Entscheidungstabelle: Welche Oberfläche muss bestehen bleiben?
Inhalt und Kontext | Primäre Akteursfrage | Auslieferungskontrolle | Exporttest | Juristische Entscheidung Direkter Dialog | Interagiert das System selbst mit einer natürlichen Person? | persistenter barrierefreier Interaktionshinweis | Erstkontakt, neue Sitzung, Widget und API-Client | Offensichtlichkeit und Ausnahme Synthetisches Bild/Audio/Video | Ist die Organisation Anbieter, Betreiber oder beides? | maschinenlesbare Markierung plus erforderlicher sichtbarer Deepfake-Hinweis | Resize, Transcoding, Screenshot, Download, Re-Encoding | Scope, Deepfake-Definition, Ausnahme Text zu öffentlichem Interesse | Dient er der Information der Öffentlichkeit; wer trägt redaktionelle Verantwortung? | gegebenenfalls Hinweis; Provenienz intern | CMS, RSS, Print/PDF, Syndikation, Kopie | Zweck und Ausnahme durch Review Standardbearbeitung | Ändert die Assistenz Input oder Semantik wesentlich? | Entscheidungsevidenz bewahren | Input/Output und Tool-Modus vergleichen | Anwendbarkeit der Ausnahme Geschlossener B2B-/Industrieoutput | Bleibt er tatsächlich geschlossen und ohne Exposition? | Kanal vertraglich beschränken, Leakage überwachen | API-Ziel und Downstream-Export | Bedingungen enger Ausnahmen
Definieren Sie den Exportvertrag
Jeder Renderer und Channel Adapter deklariert Eingaben, Transformationen und Garantien. cms_to_web übernimmt provenance_id und Source Asset, bewahrt eine öffentliche Disclosure-Komponente, schreibt einen freigegebenen maschinenlesbaren Träger, registriert den Derivat-Digest und stoppt, wenn eine Pflichtoberfläche fehlt. pdf_export kann denselben Träger eventuell nicht erhalten; der Vertrag kann stattdessen einen sichtbaren barrierefreien Hinweis und eine Dokument-Provenienzreferenz materialisieren und beides im fertigen Dokument prüfen.
Downgraden Sie nie still. Geben Sie einen typisierten Status zurück: PRESERVED, RE_MATERIALISED, NOT_APPLICABLE, EXCEPTION_APPROVED oder BLOCKED. Speichern Sie Policy-, Transformations- und Verifier-Version sowie Evidence URI. Ein Kanal ohne erforderlichen Träger geht in einen verantworteten Ausnahme- oder Alternativpfad—nicht nach der Verteilung nur in eine Warnmeldung.
Prüfen Sie das Ergebnis, nicht die Konfiguration
Erstellen Sie Golden Assets für Text, Bild, Audio und Video. Schicken Sie sie durch jeden Produktionspfad: Upload, Crop, responsive Rendition, CDN-Optimierung, Download, E-Mail-Anhang, API-Export, Office-Konvertierung, Print/PDF und unterstützte Social-Publishing-Pfade. Extrahieren Sie Metadaten, rendern Sie sichtbare Hinweise, prüfen Sie Barrierefreiheit, berechnen Sie Digests neu und testen Sie Detektion, sofern die gewählte Technik sie unterstützt. Die Suite läuft bei Änderungen an CMS, Bildbibliothek, Encoder, Template, CDN oder Channel Integration.
Bewahren Sie drei unabhängige Signale: Trägerpräsenz, Publikumshinweis und Lineage Match. Trägerpräsenz prüft Metadaten oder Wasserzeichen. Publikumshinweis prüft klare, unterscheidbare und barrierefreie Darstellung. Lineage Match ordnet ausgelieferte Bytes einer freigegebenen Provenienzkette zu. Keines beweist die anderen—und Provenienz beweist nicht die inhaltliche Wahrheit.
Implementierungscheckliste
1. Generierungs- und Bearbeitungssysteme, Modalitäten, Akteursrollen und Kanäle inventarisieren. 2. Geprüfte Anwendbarkeitsregeln und Ausnahmeverantwortliche festlegen. 3. Provenienzumschlag, IDs, Digest-/Signaturpolicy und Aufbewahrung definieren. 4. disclosure_policy_id und provenance_id in CMS-/API-Schemata aufnehmen. 5. Transformationsverträge für Web, PDF, Derivate, Syndikation und Social definieren. 6. Sichtbare barrierefreie Hinweise getrennt von maschinenlesbaren Trägern umsetzen. 7. Golden-Asset-Exporttests bauen und Releases bei Verlust einer Pflichtoberfläche blockieren. 8. NOT_VERIFIED und BLOCKED überwachen; Owner und Ablaufdatum zuweisen. 9. Regeln bei Änderungen von Recht, Leitlinien, Standards, Encodern oder Kanälen neu bewerten.
Fehlerbilder und Trade-offs
Metadatenverlust ist offensichtlich. Weniger sichtbar sind eine veraltete Policy-Entscheidung nach Use-Case-Änderung, ein Digest nur für das Original statt das Derivat, ein per Responsive CSS verborgenes Badge, englische Hinweise auf deutschen Seiten, signierte Provenienz mit unverwalteten Schlüsseln und „menschlich geprüft“ ohne benannten Editor. Testen Sie Locale, Barrierefreiheit, Derivate und Ausnahmeevidenz.
Mehr Träger erhöhen Robustheit, aber auch Implementierungsaufwand, Dateigröße, Schlüsselverwaltung und False-Positive-Behandlung. Sichtbare Labels reduzieren Mehrdeutigkeit, beanspruchen aber Oberfläche und können in künstlerischen Kontexten unpassend sein. Manche Detektion ist probabilistisch und degradiert nach Transformation. Das Ziel ist kein unzerstörbares Universalwasserzeichen, sondern ein dokumentiertes inhaltsspezifisches Kontrollset mit gemessenem Transformationsverhalten, Fallback-Hinweis und verantworteten Ausnahmen.
Primärquellen und rechtliche Grenze
Primärquellen: Verordnung (EU) 2024/1689, Artikel 50 im AI Act Service Desk, Leitlinien der Kommission zu Artikel 50, Code of Practice zur Transparenz KI-generierter Inhalte und FAQ der Kommission. Die Kommission nennt den 2. August 2026 als Anwendungsbeginn und beschreibt einen begrenzten Übergang für bestimmte ältere Systeme. Da Rechtstext und Leitlinien geändert werden können, müssen Sie aktuelle Anwendbarkeit, Termine und Ausnahmen juristisch prüfen lassen.
Machen Sie einen Exportpfad prüfbar
Wählen Sie den volumenstärksten Pfad—etwa generiertes Bild → CMS → responsives CDN-Derivat → Download—und verfolgen Sie ein Asset vollständig. Ich unterstütze Sie dabei, daraus Provenienzschema, Transformationsvertrag, automatisierten Verifier und Release Gate zu bauen. Das relevante Ergebnis ist eine prüfbare Antwort: Welcher Hinweis erreichte das Publikum, und welche Evidenz belegt, dass er den Pfad überstanden hat?
