EU AI Act und California AI Transparency Act 2026: Was Entwickler jetzt ändern müssen

Der auffälligste Fehler bei der Vorbereitung auf neue KI-Transparenzpflichten ist nicht fehlender guter Wille, sondern die falsche technische Annahme: Ein sichtbarer Hinweis wie „KI-generiert“ wird häufig mit einer vollständigen Kennzeichnung verwechselt. Für ein Produktteam kann das bedeuten, dass die Benutzeroberfläche korrekt aussieht, die Herkunftsinformation beim Export aber trotzdem verloren geht.

Genau deshalb sollten Sie den EU AI Act und California AI Transparency Act 2026 nicht als reine Textpflichten betrachten. Entscheidend ist, an welcher Stelle Ihr System Inhalte erzeugt, welche Metadaten es überträgt, wer die Offenlegung auslöst und ob ein Dritter die Kennzeichnung später noch überprüfen kann. Der 02.08.2026 ist dabei kein allgemeiner Stichtag für jede denkbare KI-Regel, sondern ein wichtiger Anwendungsbeginn für bestimmte Transparenzpflichten in der EU und für die kalifornische Regelung nach AB 853. (digital-strategy.ec.europa.eu)

Welche Regeln gelten ab dem 02.08.2026 tatsächlich?

Beim EU AI Act beginnt die Anwendung der Transparenzpflichten aus Artikel 50 am 02.08.2026. Die Europäische Kommission hat dazu am 20.07.2026 Leitlinien veröffentlicht. Für Entwickler besonders relevant sind Artikel 50 Absatz 2, 4 und 5: künstlich erzeugte oder manipulierte Inhalte sollen maschinenlesbar gekennzeichnet werden, Deepfakes müssen offengelegt werden, und bestimmte Texte mit Bezug zu Angelegenheiten von öffentlichem Interesse benötigen einen klar erkennbaren Hinweis. (digital-strategy.ec.europa.eu)

Artikel 50 enthält daneben weitere Pflichten. Anbieter interaktiver Systeme müssen betroffene Personen darüber informieren, dass sie mit einem KI-System interagieren, sofern dies nicht ohnehin offensichtlich ist. Betreiber von Systemen zur Emotionserkennung oder biometrischen Kategorisierung müssen exponierte Personen ebenfalls informieren. Für die hier betrachteten generativen Produkte sind jedoch vor allem die Markierung und Offenlegung von Inhalten die unmittelbar sichtbaren Änderungsbereiche. (eur-lex.europa.eu)

In Kalifornien verschiebt AB 853 den operativen Start der California AI Transparency Act auf den 02.08.2026. Das Gesetz richtet sich unter anderem an Personen oder Unternehmen, die ein generatives KI-System erstellen, programmieren oder anderweitig produzieren, wenn dieses öffentlich zugänglich ist und mehr als 1.000.000 monatliche Besucher oder Nutzer aufweist. Für solche Anbieter sieht das Gesetz ein kostenlos verfügbares KI-Prüfwerkzeug vor. (leginfo.legislature.ca.gov)

Die kalifornische Regelung arbeitet außerdem mit späteren Umsetzungsstufen:

Diese Zeitpunkte bedeuten nicht, dass jedes Produkt am selben Tag dieselben Funktionen benötigt. Die konkrete Einordnung hängt von Geschäftsmodell, Nutzerzahl, Inhaltstyp und Rolle in der Lieferkette ab. (leginfo.legislature.ca.gov)

Wer ist Anbieter, Betreiber oder Plattform?

Die wichtigste Vorarbeit ist eine Rollenkarte. Viele Unternehmen bezeichnen sich intern als „KI-Anbieter“, obwohl sie rechtlich und technisch mehrere Rollen gleichzeitig übernehmen.

Ein Modellanbieter stellt beispielsweise eine generative Komponente bereit. Ein Produktanbieter integriert diese Komponente in eine Anwendung. Ein Betreiber nutzt die Anwendung für Kundenprozesse. Eine Plattform hostet oder verteilt schließlich die erzeugten Dateien. Dieselbe Organisation kann alle vier Funktionen ausüben.

Für den EU AI Act ist der Unterschied zwischen Anbieter und Betreiber entscheidend. Anbieter müssen bestimmte technische Transparenzmaßnahmen in das System oder in den Ausgabefluss integrieren. Betreiber müssen bei bestimmten Anwendungen für die Offenlegung gegenüber Personen sorgen und den Nutzungskontext berücksichtigen. Die EU-Kommission beschreibt Artikel 50 ausdrücklich als Regelwerk für Anbieter und Betreiber bestimmter KI-Systeme. (digital-strategy.ec.europa.eu)

Für Kalifornien liegt der Schwerpunkt von AB 853 stärker auf dem Anbieter des generativen Systems. Relevant ist nicht nur der Sitz des Unternehmens, sondern auch, ob das System innerhalb Kaliforniens öffentlich zugänglich ist. Ein europäisches SaaS-Unternehmen mit kalifornischen Kunden sollte daher mindestens diese Fragen beantworten:

1. Ist die Anwendung in Kalifornien ohne besondere Zugangssperre verfügbar?
2. Erzeugt oder verändert das eigene System Bilder, Videos, Audio oder Kombinationen daraus?
3. Überschreitet das System den Schwellenwert von mehr als 1.000.000 monatlichen Besuchern oder Nutzern?
4. Werden Inhalte direkt vom eigenen System erzeugt oder nur über ein fremdes Modell weitergeleitet?
5. Werden Herkunftsdaten beim Download, bei API-Antworten oder beim Plattform-Upload erhalten?

Die letzte Frage ist besonders wichtig. Ein Unternehmen kann die Generierung an einen Drittanbieter delegieren, bleibt aber möglicherweise für den eigenen Ausgabekanal, die Nutzerinformation oder die Weiterverarbeitung verantwortlich. Das ist eine technische Risikozuordnung, keine automatische Rechtsaussage.

EU AI Act und California AI Transparency Act 2026 im direkten Vergleich

Die beiden Regelwerke verfolgen ein ähnliches Ziel, setzen aber unterschiedliche Schwerpunkte. Der EU AI Act verlangt in bestimmten Fällen eine maschinenlesbare Kennzeichnung und eine sichtbare Offenlegung. Kalifornien ergänzt dies um ein kostenloses Prüfwerkzeug und um latente Offenlegungen, die dauerhaft oder außerordentlich schwer entfernbar sein müssen, soweit dies technisch machbar ist. (leginfo.legislature.ca.gov)

Die Tabelle ist eine redaktionelle Gegenüberstellung auf Grundlage der Gesetzestexte und offiziellen Erläuterungen, keine verbindliche Rechtsauslegung.

Die gemeinsame technische Basis kann trotzdem groß sein: ein Herkunftsobjekt, ein standardisiertes Metadatenformat, eine Validierungsbibliothek, ein Exporttest und ein Protokoll für fehlgeschlagene Prüfungen. Der Unterschied liegt darin, welche zusätzliche Benutzerinformation und welcher Prüfkanal erforderlich ist.

Was bedeutet „maschinenlesbare Kennzeichnung“?

Eine sichtbare Beschriftung ist für Menschen gedacht. Eine maschinenlesbare Kennzeichnung wird dagegen von Software verarbeitet. Sie kann beispielsweise in Dateimetadaten, einem standardisierten Provenienzobjekt oder einer Signatur liegen. Der konkrete technische Mechanismus muss zum Medienformat, zum Bearbeitungsworkflow und zur späteren Plattformübertragung passen.

Bei AI-generierten Inhalten mit maschinenlesbarer Kennzeichnung sollten Sie mindestens folgende Informationen prüfen:

• Wurde der Inhalt vollständig erzeugt oder nur teilweise verändert?
• Welches System oder welcher Anbieter hat die Generierung ausgelöst?
• Wann wurde die Kennzeichnung geschrieben?
• Bleibt sie nach Größenänderung, Transkodierung oder Formatwechsel erhalten?
• Kann ein externes Prüfwerkzeug die Information ohne interne Datenbank auswerten?
• Wie wird mit Inhalten umgegangen, deren Herkunft unbekannt oder beschädigt ist?

Für Bilder ist ein Metadaten- und Signaturtest notwendig. Bei Video müssen Sie zusätzlich Transkodierung und Ausschnitte testen. Bei Audio darf die Kennzeichnung nicht nur an einer Containerinformation hängen, die beim Streaming entfernt wird. Für Text liegt die Herausforderung anders: Ein sichtbarer Hinweis kann erforderlich sein, während eine dauerhafte maschinenlesbare Markierung bei frei kopierbarem Text deutlich schwieriger durchzusetzen ist.

Die offiziellen EU-Leitlinien und die dazugehörigen Fragen-und-Antworten-Dokumente sollten Ihre technische Auslegung ergänzen. Eine geeignete offizielle Übersicht zu den Transparenzpflichten nach Artikel 50 gehört in die interne Compliance-Dokumentation. (digital-strategy.ec.europa.eu)

Wann braucht Ihr Produkt einen Deepfake-Hinweis?

Bei einem Deepfake geht es nicht nur darum, dass ein Inhalt mit KI erstellt wurde. Entscheidend ist der realistische Eindruck, eine reale Person, ein reales Ereignis oder eine reale Handlung werde dargestellt, obwohl der Inhalt künstlich erzeugt oder manipuliert wurde.

Ein Produkt sollte deshalb vor der Veröffentlichung unterscheiden zwischen:

• vollständig künstlich erzeugtem Video,
• Austausch oder Veränderung eines Gesichts,
• synthetischer Stimme,
• nachträglicher Veränderung eines realen Ereignisses,
• stilisierter oder offensichtlich fiktiver Darstellung,
• redaktioneller Bearbeitung ohne realistische Täuschungsabsicht.

Artikel 50 des EU AI Act verlangt bei künstlich erzeugten oder manipulierten Bild-, Audio- oder Videoinhalten, die einen Deepfake darstellen, eine klare Offenlegung. Die Offenlegung sollte so erfolgen, dass sie nicht nur in einer technischen Dateiansicht auffindbar ist, sondern beim normalen Nutzungskontext verständlich bleibt. (eur-lex.europa.eu)

Bei öffentlichen Interessentexten besteht ein anderes Risiko. Ein automatisiert erzeugter Text über Wahlen, öffentliche Sicherheit oder andere gesellschaftlich relevante Themen kann einen sichtbaren Hinweis benötigen, sofern die gesetzlichen Voraussetzungen erfüllt sind. Das Produktteam sollte daher nicht nur nach dem MIME-Typ entscheiden, sondern auch nach Inhalt und Nutzungskontext.

Was ist eine „latente Offenlegung“ in Kalifornien?

Die GenAI latent disclosure validation tools beziehungsweise Werkzeuge zur Prüfung latenter Offenlegungen sind keine bloßen Wasserzeichenleser. Eine latente Offenlegung soll Informationen über die künstliche Erzeugung oder Veränderung im Inhalt oder in einer damit verbundenen technischen Struktur transportieren. AB 853 verlangt für bestimmte künstlich erzeugte oder veränderte Bild-, Video- und Audioinhalte eine dauerhafte oder außerordentlich schwer entfernbare Offenlegung, soweit dies technisch machbar ist. (leginfo.legislature.ca.gov)

Für ein Produktteam ergeben sich daraus drei getrennte Funktionen:

1. Schreiben: Die Kennzeichnung wird bei der Erzeugung oder beim finalen Export eingebracht.
2. Erhalten: Nach Bearbeitung, Download, Upload und Weitergabe bleibt sie möglichst bestehen.
3. Prüfen: Ein Benutzer kann kostenlos feststellen, ob die Kennzeichnung erkannt wird und welche Provenienzdaten vorliegen.

Ein GenAI-Latent-Disclosure-Verifizierungstool sollte daher nicht nur „ja“ oder „nein“ ausgeben. Sinnvoll sind mindestens ein Erkennungsstatus, die gefundenen Provenienzdaten, der verwendete Prüfzeitpunkt, technische Warnungen und ein Hinweis auf unbekannte oder beschädigte Herkunftsinformationen.

Wie sollte die technische Umsetzung ablaufen?

Die folgende Reihenfolge verhindert, dass das Team zu früh eine sichtbare Oberfläche baut und erst später feststellt, dass die Exportkette keine Herkunftsdaten erhält.

1. Inhaltstypen und Länderzugang inventarisieren

Erstellen Sie eine Liste aller Ausgaben: Chattext, Bild, Audio, Video, kombinierte Medien, bearbeitete Uploads und API-Downloads. Ergänzen Sie, in welchen Ländern die jeweilige Funktion verfügbar ist. Ein Produkt, das in der EU und in Kalifornien ohne getrennte Version angeboten wird, sollte beide Regelwerke bereits in der Architektur berücksichtigen.

2. Rollen und Drittanbieter dokumentieren

Ordnen Sie jedem Generierungsschritt eine verantwortliche Organisation und einen technischen Dienst zu. Dokumentieren Sie, ob Ihr System selbst generiert, ein fremdes Modell anweist oder fremde Inhalte lediglich weiterleitet. Halten Sie zusätzlich fest, welcher Dienst die Kennzeichnung schreibt und wer sie beim Export kontrolliert.

3. Ein Provenienzschema definieren

Legen Sie ein internes Schema für Erzeugung, Bearbeitung, Modellquelle, Zeitstempel und Prüfstatus fest. Es sollte nicht an eine einzelne Benutzeroberfläche gebunden sein. So kann dieselbe Information in einer Webanwendung, einer API-Antwort und einem Batch-Export verwendet werden.

4. Kennzeichnung direkt in die Erzeugungskette integrieren

Schreiben Sie die maschinenlesbare Markierung nicht erst beim manuellen Download. Besser ist ein Ausgabeschritt, der vor Speicherung, Vorschau und Veröffentlichung ausgeführt wird. Bei fehlgeschlagener Kennzeichnung sollte das System entweder blockieren oder den Inhalt eindeutig als nicht verifiziert behandeln.

5. Sichtbare Offenlegung nach Kontext auslösen

Für Deepfakes, bestimmte öffentliche Interessentexte und direkte KI-Interaktionen benötigen Sie verständliche Hinweise. Vermeiden Sie versteckte Informationen in allgemeinen Nutzungsbedingungen. Die Offenlegung muss dort erscheinen, wo der Benutzer den Inhalt wahrnimmt oder mit dem System interagiert.

6. Export- und Übertragungstests automatisieren

Testen Sie mindestens Download, erneuten Upload, Bildkompression, Videotranskodierung, Audio-Konvertierung, API-Weitergabe und Speicherung in einem Content-Management-System. Für jede Stufe sollte dokumentiert werden, ob die Herkunftsdaten erhalten, verändert oder entfernt wurden.

7. Prüfwerkzeug und Nachweise bereitstellen

Für Kalifornien muss das erforderliche kostenlose Prüfwerkzeug für erfasste Anbieter Teil der Produktplanung sein. Ergänzen Sie eine Protokollierung für Prüfresultate, Fehlermeldungen und Versionen des Validierungsalgorithmus. Das erleichtert die Bearbeitung von Kundenanfragen und interne Audits. (leginfo.legislature.ca.gov)

8. Freigabe durch Produkt, Technik und Recht

Die letzte Freigabe sollte nicht allein beim Entwickler liegen. Produktverantwortliche prüfen Verständlichkeit, Entwickler die technische Beständigkeit und die zuständige Rechts- oder Compliance-Funktion den Anwendungsbereich. Die Entscheidung muss mit Datum, Version und Begründung dokumentiert werden.

Wichtiger Praxishinweis: Eine erkannte Provenienz ist kein Beweis für die Wahrheit des Inhalts. Sie zeigt, welche technischen Angaben gefunden wurden. Ihr Produkt sollte deshalb nicht behaupten, ein Validierungstool könne jede Fälschung zuverlässig erkennen.

Wo entstehen die versteckten Kosten?

Die Kosten liegen selten nur in der Implementierung eines Wasserzeichens. Mehr Aufwand entsteht typischerweise an den Schnittstellen:

• Drittanbieter liefern unterschiedliche Metadaten oder gar keine verwertbare Provenienz.
• Medienserver transkodieren Dateien und entfernen dabei technische Angaben.
• Marketing- und Supportteams formulieren Offenlegungen uneinheitlich.
• API-Kunden speichern nur den Inhalt, nicht den Prüfstatus.
• Datenschutz- und Sicherheitsanforderungen begrenzen, welche Herkunftsdaten dauerhaft gespeichert werden dürfen.
• Alte Inhalte aus dem Bestand benötigen einen gesonderten Status, wenn sie vor dem Inkrafttreten erzeugt wurden.

Eine wirtschaftlich sinnvolle Priorisierung richtet sich deshalb nach vier Faktoren: monatliches Nutzungsvolumen, Zahl der Medienformate, Anteil fremder Modelle und Stabilität der bestehenden Exportpipeline.

Ein textzentriertes Produkt mit klarer EU-Zielgruppe benötigt möglicherweise zunächst Interaktionshinweise und eine Regel für öffentliche Interessentexte. Ein Medienprodukt mit Bild-, Video- und Audioausgabe benötigt dagegen frühzeitig Provenienzschreiben, Transkodierungstests und ein Prüfwerkzeug. Eine Plattform sollte zusätzlich die späteren Anforderungen ab 01.01.2027 einplanen, auch wenn diese nicht bereits am 02.08.2026 vollständig gelten. (leginfo.legislature.ca.gov)

Warum reicht ein Wasserzeichen allein nicht?

Ein Wasserzeichen kann sichtbar, aber leicht entfernbar sein. Außerdem wird es von Maschinen nicht immer zuverlässig erkannt. Umgekehrt kann eine technische Kennzeichnung vorhanden sein, ohne dass ein Benutzer den Hinweis im richtigen Moment wahrnimmt.

Typische Fehler sind:

1. Nur die Vorschau wird gekennzeichnet: Die exportierte Originaldatei enthält keine Herkunftsdaten.
2. Nur eigene Modelle werden berücksichtigt: Ausgaben eines externen Modells laufen durch denselben Produktkanal, bleiben aber ungeprüft.
3. Die Kennzeichnung wird beim Transkodieren gelöscht: Das Produkt testet die Erzeugung, nicht die gesamte Übertragung.
4. „Unbekannt“ wird als „nicht künstlich“ angezeigt: Ein fehlendes Signal ist kein Gegenbeweis.
5. Prüfergebnisse werden nicht gespeichert: Später lässt sich nicht mehr nachvollziehen, welche Version geprüft wurde.
6. Der Hinweis steht nur in den Bedingungen: Eine schwer auffindbare Klausel ersetzt keine kontextgerechte Offenlegung.

Die sicherere Architektur trennt sichtbare Hinweise, maschinenlesbare Herkunftsdaten und interne Prüfprotokolle. Keine dieser Ebenen ersetzt automatisch die anderen.

Grenzüberschreitendes Beispiel: ein Medieneditor mit API

Nehmen wir ein SaaS-Produkt, das aus Textbeschreibungen Bilder und kurze Videos erzeugt. Die Anwendung wird von europäischen Agenturen und von Kunden in Kalifornien genutzt. Das Produkt verwendet teilweise eigene Nachbearbeitung, teilweise externe Generierungsdienste und erlaubt den Export über eine API.

Für die EU muss das Team zunächst prüfen, ob die Ausgaben unter die Kennzeichnungs- und Offenlegungspflichten des Artikels 50 fallen. Bei realistisch wirkenden Personen- oder Ereignisvideos ist insbesondere die Deepfake-Offenlegung relevant. Die Kennzeichnung sollte vor dem Export geschrieben und beim Teilen über die API erhalten werden. (eur-lex.europa.eu)

Für Kalifornien muss das Team zusätzlich feststellen, ob der gesetzliche Schwellenwert und die übrigen Voraussetzungen für einen erfassten Anbieter erfüllt sind. Ist dies der Fall, braucht die Anwendung für die erfassten Bild-, Video- und Audioinhalte ein kostenloses Prüfwerkzeug, das erkennbare Provenienzdaten ausgibt. Das System sollte außerdem latente Offenlegungen nicht nur in der Benutzeroberfläche anzeigen, sondern technisch in der Medienpipeline berücksichtigen. (leginfo.legislature.ca.gov)

Die produktseitige Lösung kann teilweise gemeinsam sein: ein Provenienzobjekt, ein Export-Gateway und automatisierte Integritätstests. Nicht automatisch gemeinsam sind jedoch die Benutzerhinweise, der Umfang des Prüfwerkzeugs und die späteren Plattformpflichten.

Ihre Checkliste vor dem 02.08.2026

Markieren Sie einen Punkt erst dann als erledigt, wenn ein Test oder ein Dokument vorliegt:

• [ ] EU- und Kalifornien-Zugang der einzelnen GenAI-Funktionen dokumentiert
• [ ] Rollen von Modellanbieter, Produktanbieter, Betreiber und Plattform geklärt
• [ ] Alle Text-, Bild-, Audio- und Videoausgaben inventarisiert
• [ ] Deepfake-Szenarien und öffentliche Interessentexte separat bewertet
• [ ] Maschinenlesbare Kennzeichnung in der Erzeugungskette vorgesehen
• [ ] Latente Offenlegung für erfasste Medien technisch geprüft
• [ ] Sichtbare Offenlegung in Produktansichten und Exportabläufen definiert
• [ ] Kostenloses Prüfwerkzeug für Kalifornien eingeplant, sofern AB 853 anwendbar ist
• [ ] Transkodierung, Kompression und API-Übertragung getestet
• [ ] Drittanbieter-Verträge und technische Zusicherungen geprüft
• [ ] Fehlende oder beschädigte Provenienz als eigener Status modelliert
• [ ] Prüfprotokolle mit Version, Zeitpunkt und Ergebnis gespeichert
• [ ] Zeitplan für Plattformpflichten ab 01.01.2027 bewertet
• [ ] Aufnahmegeräte-Schnittstellen für den Stichtag 01.01.2028 nur dann berücksichtigt, wenn das Geschäftsmodell betroffen ist
• [ ] Gemeinsame Freigabe durch Produkt, Engineering und Compliance dokumentiert

Aktuelle technische Umgebungen werden dabei oft unterschätzt. Ein Team, das Build-Tests, Medienkonvertierung und Validierung lokal oder in einer instabilen Remote-Umgebung ausführt, verliert Zeit durch wechselnde Tool-Versionen, Rechteprobleme und schwer reproduzierbare Ergebnisse. Für wiederholbare Tests kann eine standardisierte Mac-Arbeitsumgebung sinnvoll sein. Wenn Sie dafür zunächst eine flexible Testkapazität benötigen, können Sie die Mac-Mietoptionen von SpinMac mit den Anforderungen Ihrer Pipeline vergleichen oder eine Mac-Testumgebung bestellen.

Ist eine Mac-Umgebung für die Compliance-Arbeit sinnvoll?

Die Rechtsanforderung selbst schreibt keine bestimmte Hardware vor. Für die praktische Umsetzung kann eine kontrollierte Mac-Umgebung dennoch Vorteile haben: feste Entwicklungsprofile, reproduzierbare lokale Tests, getrennte Benutzerkonten und ein klarer Ablauf für Medienverarbeitung und Validierung.

Die derzeitige Lösung vieler Teams besteht aus gemischten Windows-, Linux- und Cloud-Umgebungen. Das hat drei reale Nachteile: Abhängigkeiten werden je nach System unterschiedlich installiert, Medien- und Signaturtests laufen nicht immer unter identischen Bedingungen, und temporäre Cloud-Instanzen erschweren die Nachvollziehbarkeit von Testständen. Gerade bei einem Compliance-Nachweis ist nicht nur wichtig, dass ein Test einmal funktioniert, sondern dass er unter dokumentierten Bedingungen wiederholbar bleibt.

Eine gemietete Mac-Umgebung von SpinMac kann für diese Phase praktischer sein, wenn Sie keine zusätzliche Hardware beschaffen, administrieren und später wieder ausmustern möchten. Sie erhalten damit eine planbare Umgebung für Entwicklungs-, Export- und Validierungstests, während Ihr Team die bestehende Produktinfrastruktur weiter betreibt. Das ersetzt keine rechtliche Prüfung, kann aber die technische Lücke zwischen „Kennzeichnung ist geplant“ und „Kennzeichnung ist reproduzierbar getestet“ verkleinern.

Planen Sie deshalb jetzt einen gemeinsamen Termin für Produkt, Engineering und Compliance, speichern Sie diese Checkliste als internes Freigabedokument und prüfen Sie jede betroffene Ausgabekette vor dem 02.08.2026. Dieser Beitrag dient der technischen Orientierung und stellt keine Rechtsberatung dar.