Agentic AI
Mai 28, 2026
Der 2. August 2026 steht fest – und für Entwickler von Foundation Models bedeutet das mehr als eine Eintragung im Kalender. Während viele Unternehmen noch auf eine generelle Fristverschiebung im AI Act hoffen, bleibt Artikel 50 der KI-Verordnung bei seinem Stichtag. Was KI-Watermarking technisch bedeutet, wer was implementieren muss und wo die Lücken im aktuellen Regulierungsrahmen klaffen: eine Einordnung ohne Beschönigung.
Ein hartnäckiges Missverständnis kursiert derzeit in Compliance-Teams und Legal-Blogs: Der AI Act habe generell Fristen nach hinten verschoben, man habe noch Zeit. Wer so plant, sitzt auf einer falschen Annahme. Die sogenannte Digital-Omnibus-Initiative vom Mai 2026 hat tatsächlich Fristen für bestimmte Hochrisiko-KI-Systeme auf 2027 und 2028 verlagert. Konformitätsbewertungspflichten für kritische Infrastruktur, medizinische Anwendungen, Bildung – das hat Aufschub bekommen.
Artikel 50 der Verordnung (EU) 2024/1689 steht nicht auf dieser Liste. Die Kennzeichnungspflicht für synthetische Medien läuft nach aktuellem Stand der Rechtskommentare zum ursprünglichen Stichtag am 2. August 2026 scharf. Mehrere Compliance-Plattformen und IT-Rechtsportale, darunter eRecht24, bestätigen das explizit. Wer auf eine generelle Gnadenfrist setzt, riskiert eine böse Überraschung – und Bußgelder bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes.
Das Timing ist kein Zufall. Die EU hat die Kennzeichnungspflicht bewusst früh angesetzt, weil synthetische Medien – Deepfakes, KI-generierte Stimmen, automatisch produzierte Nachrichtentexte – als unmittelbare demokratische Bedrohung eingestuft werden. Hochrisiko-Systeme regulieren ist komplex. Watermarking dagegen gilt politisch als niedrigschwellige Sofortmaßnahme. Ob das technisch stimmt, ist eine andere Frage.
Artikel 50 unterscheidet sauber zwischen zwei Rollen, die in der Praxis häufig durcheinandergeworfen werden. Für Foundation-Model-Entwickler ist diese Unterscheidung operativ entscheidend.
Anbieter von KI-Systemen – also wer ein Modell entwickelt, trainiert und über API oder Produkt verfügbar macht – müssen sicherstellen, dass alle synthetischen Ausgaben in einem maschinenlesbaren Format als künstlich erzeugt markiert sind. Das betrifft Audio, Bilder, Video und unter bestimmten Bedingungen auch Text. Die Pflicht trifft OpenAI, Anthropic, Mistral, Google, aber auch kleinere Teams, die eigene Basismodelle mit Medienoutput bereitstellen. Konkret bedeutet das: Wer eine Bildgenerierungs-API anbietet, muss technisch dafür sorgen, dass jedes ausgegebene Bild eine maschinenlesbare Kennzeichnung trägt – bevor es beim Kunden ankommt.
Betreiber – also Unternehmen oder Einzelpersonen, die ein fremdes KI-System in eigene Produkte oder Workflows integrieren – tragen zusätzliche Pflichten auf der Nutzungsebene. Sie müssen bei Deepfakes und bei öffentlichkeitsrelevanten Texten ohne menschliches Lektorat sichtbar kennzeichnen. Das ist eine andere Schicht: nicht maschinenlesbar, sondern für das menschliche Auge bestimmt. „Dieses Video wurde mit KI erzeugt“ als Einblendung, ein Hinweis in der Podcast-Beschreibung bei synthetischen Stimmen, ein Disclaimer im Artikelkopf bei automatisch generierten Nachrichtentexten.
Wer also ein Foundation Model baut und gleichzeitig eine Applikation darauf betreibt, sitzt auf beiden Stühlen. Die Pflichten kumulieren sich.
Der AI Act schreibt keine bestimmte Technologie vor. Er verlangt maschinenlesbare Erkennbarkeit – und überlässt den Weg dorthin den Anbietern. Das klingt flexibel, erzeugt in der Praxis aber erhebliche Unsicherheit: Welche Standards gelten als compliant?
Zwei Ansätze haben sich in der Industrie als wahrscheinliche De-facto-Standards herauskristallisiert. Erstens C2PA (Coalition for Content Provenance and Authenticity): ein offenes Metadaten-Framework, das von Adobe, Microsoft und Google mitentwickelt wurde und Herkunfts- sowie Bearbeitungsnachweise direkt in Mediendateien einbettet. Für Bild-, Audio- und Videoausgaben von Foundation Models gilt C2PA-Konformität aktuell als stärkste Kandidatin für regulatorische Anerkennung.
Zweitens Token-basiertes Watermarking für Textausgaben. Googles SynthID, das inzwischen als Open Source verfügbar ist, setzt unsichtbare probabilistische Signaturen in generierten Text ein – auf Tokenebene, ohne den Inhalt zu verändern. Die Idee: Erkennungssysteme können das Muster auch nach moderater Bearbeitung noch nachweisen. Für Foundation-Model-Anbieter, die Textausgaben produzieren und öffentlichkeitsrelevant einsetzen, ist dieses Verfahren ein realistischer Ausgangspunkt.
Meine Einschätzung dazu: Auf standardisierte Open-Source-Werkzeuge wie SynthID zu setzen ist aus strategischer Sicht sinnvoll. Interoperabilität und Nachweisbarkeit gegenüber Behörden sprechen dafür. Aber die rechtliche Anerkennung spezifischer Technologien ist noch offen – wer heute vollständig auf ein einzelnes Verfahren setzt, sollte die Entwicklung der technischen Standards genau verfolgen.
Hier liegt das eigentlich unbequeme Problem für Anbieter großer Foundation Models. Das Modell selbst markiert seine Ausgaben maschinenlesbar. Dann kommt die Downstream-Pipeline: Fine-Tuning, Post-Processing, Re-Encoding, Formatkonvertierung, Integration in Drittprodukte. An jedem dieser Schritte können Watermarks verloren gehen oder korrumpiert werden.
Wer ist dafür verantwortlich? Artikel 50 legt die primäre technische Pflicht beim Anbieter des Modells. Wie diese Pflicht entlang komplexer API-Kaskaden durchsetzbar bleibt – etwa wenn ein Foundation Model über einen Aggregator in eine SaaS-Plattform eines Drittanbieters eingebunden wird – ist regulatorisch noch nicht abschließend ausjudiziert. Klar ist: Anbieter müssen in ihrer Dokumentation und in ihren Nutzungsbedingungen festhalten, welche Downstream-Nutzer welche Kennzeichnungspflichten selbst tragen.
Praktisch bedeutet das, dass API-Designs und SDK-Integrationen heute so gebaut werden müssen, dass die Kennzeichnung nicht nachträglich stillschweigend entfernt werden kann. Das ist keine triviale Architekturentscheidung. Wer Foundation Models als Infrastruktur betreibt, sollte jetzt technische Leitlinien für Integratoren entwickeln – schriftlich, versioniert, mit klarer Zuweisung der Verantwortlichkeiten.
Eine häufig gestellte Frage in Entwicklerkreisen: Sind Open-Source-Modelle von der Kennzeichnungspflicht ausgenommen? Die Antwort ist differenzierter als die Frage vermuten lässt.
Der AI Act sieht für bestimmte Open-Source-Veröffentlichungen von GPAI-Modellen (General Purpose AI) erleichterte Anforderungen vor – vor allem bei Dokumentations- und Transparenzpflichten. Aber Artikel 50 zielt auf das Betreiben von Systemen, die synthetische Inhalte erzeugen, nicht nur auf deren Veröffentlichung. Wer ein Open-Source-Modell in einem Dienst einsetzt, der Medienoutputs an Nutzer ausliefert, ist Anbieter im Sinne der Verordnung – und damit kennzeichnungspflichtig. Die Open-Source-Eigenschaft des Basismodells ändert daran nichts.
Für reine Forschungsveröffentlichungen ohne kommerziellen Einsatz sieht die Lage anders aus. Hier ist der regulatorische Druck deutlich geringer. Wer jedoch ein offenes Modell über eine öffentliche Inference-API zugänglich macht, verlässt den Forschungskontext und bewegt sich in den Anwendungsbereich des AI Act.
An dieser Stelle muss man unbequem ehrlich sein. Mozilla Research – eine der wenigen Institutionen, die das systematisch untersucht hat – bewertet gängige Methoden zur Kennzeichnung und Erkennung synthetischer Inhalte als lediglich „schwach“ bis „mittelmäßig“ effektiv. Das ist kein Randproblem.
Wasserzeichen können durch einfaches Zuschneiden, Re-Encoding oder Paraphrasieren verloren gehen. Erkennungssysteme für KI-Text liefern sowohl Falsch-Positiv- als auch Falsch-Negativ-Ergebnisse – menschliche Texte werden fälschlicherweise als KI-generiert markiert, KI-Texte werden als menschlich durchgewunken. Das ist nicht nur ein technisches Problem, sondern ein rechtliches: Wie soll eine Behörde einen Verstoß gegen die Kennzeichnungspflicht nachweisen, wenn Watermarks im Laufe der Verarbeitungskette verschwinden können?
Das regulatorische Konzept setzt auf Technik, die noch nicht ausgereift ist. Das ist kein Argument gegen die Pflicht – synthetische Medien ohne jede Kennzeichnung sind schlechter als mit lückenhafter Kennzeichnung. Aber es bedeutet, dass die aktuellen Anforderungen voraussichtlich nicht das letzte Wort sind. Anbieter sollten mit einer Verschärfung der technischen Standards rechnen, sobald erste Durchsetzungspraxis entsteht.
Abstrakte Regulierungstexte helfen wenig, wenn Entwicklungsteams entscheiden müssen, welche Produktfeatures bis August 2026 angepasst werden müssen. Drei Szenarien illustrieren, wie Artikel 50 in konkreten Geschäftssituationen wirkt – und wo die Grenzfälle liegen.
Ein deutsches Verlagshaus nutzt die API eines Foundation-Model-Anbieters, um kurze Börsenmeldungen automatisch zu generieren. Die Texte erscheinen ohne redaktionelle Überarbeitung auf der Website. In diesem Fall trifft die Betreiberpflicht aus Artikel 50 das Verlagshaus direkt: Die Texte müssen für Leserinnen und Leser sichtbar als KI-generiert gekennzeichnet sein. Den Foundation-Model-Anbieter trifft gleichzeitig die maschinenlesbare Kennzeichnungspflicht auf Ausgabeebene – er muss sicherstellen, dass die API-Antworten entsprechende Metadaten tragen, auch wenn das Verlagshaus diese technisch nicht weitergibt. Beide Parteien sind in der Pflicht, und keine Vertragsklausel kann die gesetzliche Verantwortung vollständig auf die andere Seite verschieben.
Ein Anbieter von KI-generierten Produktbildern liefert per API fertige JPEGs an Online-Shops. Die Bilder zeigen fiktive Modelle in realen Produkten. Hier greift die Pflicht zur maschinenlesbaren Kennzeichnung unmittelbar: Jedes ausgelieferte Bild muss C2PA-Metadaten oder eine gleichwertige Signatur tragen. Schwierig wird es, wenn der Online-Shop die Bilder intern weiterverarbeitet – durch Zuschneiden, Komprimierung oder Formatkonvertierung für mobile Darstellung. Dabei gehen Metadaten in gängigen Bildpipelines regelmäßig verloren. Der API-Anbieter muss in seiner Dokumentation explizit darauf hinweisen und Integratoren technisch in die Lage versetzen, Kennzeichnungen durch die eigene Pipeline hindurch zu erhalten.
Ein SaaS-Unternehmen betreibt einen Kundendienst-Chatbot mit synthetischer Sprachausgabe, die auf einem externen Sprachmodell basiert. Die Stimme klingt täuschend menschlich. In diesem Fall überlagern sich mehrere Anforderungen: Die synthetische Audiausgabe muss maschinenlesbar markiert sein, und in der Nutzerinteraktion – etwa im Interface oder durch eine Ansage zu Beginn des Gesprächs – muss für Menschen erkennbar sein, dass keine echte Person spricht. Dass viele Nutzer wissen, dass sie mit einem Bot reden, reicht als Begründung nicht aus: Die Kennzeichnung muss aktiv und unmissverständlich erfolgen, nicht nur implizit.
Die Debatte um Artikel 50 ist nicht so eindeutig wie der Regulierungstext suggeriert. In der Industrie und der Forschungsgemeinschaft werden mehrere ernsthafte Einwände diskutiert, die jeder kennen sollte, der die Kennzeichnungspflicht bewertet.
Das Wirksamkeitsargument: Wasserzeichen schützen nicht vor böswilligem Missbrauch. Wer synthetische Medien bewusst zur Desinformation einsetzt, wird die Kennzeichnung entfernen oder umgehen – technisch ist das in vielen Fällen möglich. Die Pflicht belastet vor allem Anbieter, die gar kein Interesse an Täuschung haben, während sie gegen tatsächliche Akteure der Desinformation kaum wirkt. Dieses Argument ist berechtigt, führt aber nicht zur Schlussfolgerung, dass Watermarking nutzlos ist: Es erhöht den Aufwand für Missbrauch und schafft eine nachvollziehbare Herkunftskette für legitime Anwendungen.
Das Wettbewerbsargument: Europäische und im EU-Markt tätige Anbieter tragen Compliance-Kosten, die Konkurrenten außerhalb des EU-Rechtsraums nicht tragen. Kleinere Anbieter und Start-ups können dadurch unverhältnismäßig belastet werden. Dieses Argument kennt die Regulierung: Der AI Act enthält für GPAI-Modelle unterhalb bestimmter Rechenleistungsschwellen vereinfachte Anforderungen. Ob diese Schwellenwerte praktisch ausreichen, um kleinere Akteure zu entlasten, ist unter Beobachtern umstritten.
Das Standardisierungsargument: Solange kein verbindlicher technischer Standard für maschinenlesbare Kennzeichnung existiert, sind Anbieter in einer rechtlich unsicheren Position. Was heute als compliant gilt, könnte morgen durch neue Leitlinien der Aufsichtsbehörden neu bewertet werden. Wer jetzt investiert, investiert möglicherweise in eine Lösung, die nachjustiert werden muss. Dieses Risiko lässt sich nicht vollständig eliminieren – es spricht aber dafür, auf offene, interoperable Standards wie C2PA zu setzen statt auf proprietäre Lösungen, die schwerer anpassbar sind.
Weniger als zwölf Monate bis zum Stichtag. Das ist nicht viel, wenn Watermarking tief in die Modell-Architektur und in API-Designs eingebaut werden muss. Was steht auf der operativen Checkliste?
Technische Implementierung starten. Wer noch kein Watermarking-Verfahren in der Produktionsinfrastruktur hat, muss jetzt entscheiden: C2PA für Medienausgaben, Token-Watermarking für Textausgaben oder eine Kombination. Die Wahl sollte dokumentiert und mit der Rechtsabteilung abgestimmt sein. Eine fundierte technische Übersicht zu Watermarking-Verfahren hilft dabei, die verschiedenen Ansätze einzuordnen.
Downstream-Verantwortung klären. Nutzungsbedingungen und Developer-Dokumentationen müssen explizit festhalten, welche Kennzeichnungspflichten auf Integratoren und Drittanbieter übergehen. Das schützt rechtlich und schafft Klarheit in der Supply Chain.
Robustheit testen. Watermarking-Implementierungen müssen gegen gängige Manipulationsszenarien getestet werden: Format-Konvertierung, Nachbearbeitung, Paraphrasierung durch andere Modelle. Was nicht standhält, schützt im Ernstfall nicht vor Haftung.
Dokumentation für Behörden aufbauen. Welche Ausgabetypen werden gekennzeichnet? Nach welchem Standard? Seit wann? Diese Dokumentation ist nicht nur gute Praxis – sie ist im Streitfall der zentrale Nachweis gegenüber nationalen Aufsichtsbehörden.
Aufklärung in der eigenen Organisation. Nicht nur das Entwicklungsteam muss die Anforderungen kennen. Produktmanagement, Legal, Sales – alle, die gegenüber Kunden Aussagen über Compliance machen, müssen verstehen, was Artikel 50 tatsächlich verlangt und was er nicht verlangt. Missverständnisse über die vermeintliche „Gesamtverschiebung“ des AI Act können in Kundenverträgen gefährlich werden.
Der 2. August 2026 ist ein Datum, kein Konzept. Foundation-Model-Anbieter, die jetzt systematisch implementieren, bauen Compliance-Infrastruktur auf, die regulatorisch flexibel bleibt – egal wie sich technische Standards weiterentwickeln. Wer wartet, muss unter Zeitdruck patchen.
Die eigentlich unbequeme Frage stellt sich aber dahinter: Welchen gesellschaftlichen Schutzeffekt liefert KI-Watermarking, wenn die technischen Verfahren nach aktuellem Forschungsstand nur mäßig zuverlässig sind – und wenn die Durchsetzungspraxis erst noch entwickelt werden muss? Die Regulierung schafft Pflichten, bevor die Technologie die versprochene Wirksamkeit beweisen konnte. Das ist kein Fehler des AI Act. Aber es ist ein Risiko, das Anbieter und Regulierer gemeinsam tragen.
Welche technischen Mindeststandards werden Aufsichtsbehörden in der Praxis durchsetzen – und wann werden wir das wissen?
