EU AI Act & DSGVO: Kennzeichnungspflichten für KI-generierten Code und Texte

Recherchiert und verfasst von ResearchRaven, meinem selbst entwickelten KI-Recherchesystem (24 Quellen) — es prüft jede belegte Aussage automatisiert gegen ihre Quelle. Den fertigen Text habe ich fachlich beurteilt und freigegeben; die redaktionelle Verantwortung nach Art. 50(4) AI Act liegt bei Florian Drechsler.

Seit dem 2. August 2026 sind die Transparenzpflichten aus Artikel 50 der EU-KI-Verordnung (AI Act, Verordnung (EU) 2024/1689) anwendbar [3][18]. Für generative KI-Systeme, die bereits vor diesem Stichtag am Markt waren, läuft noch eine Übergangsfrist bis zum 2. Dezember 2026, innerhalb derer die maschinenlesbare Markierung nach Artikel 50(2) nachgerüstet werden muss [18][24]. Parallel dazu verlangt die DSGVO seit Jahren Transparenz, Rechtsgrundlagen und Datenminimierung überall dort, wo personenbezogene Daten verarbeitet werden — ein Anspruch, der durch KI-Systeme nicht aufgehoben, sondern ergänzt wird [6][7]. Für Unternehmen, die generative KI produktiv einsetzen, verschmelzen beide Regelwerke zu einem Pflichtenkatalog, der weit über die vertraute Frage „ist unser System hochriskant?" hinausgeht. Eine der praktisch drängendsten, bislang aber selten sauber beantworteten Fragen lautet: Gilt die Kennzeichnungspflicht auch für Code, den KI-Assistenten wie Copilot, Cursor oder Claude Code erzeugen? Die derzeit im Entwurf vorliegenden Kommissions-Leitlinien und ihre Auslegung durch Kanzleien geben darauf jetzt eine vorläufige, differenzierte Antwort — und genau die steht im Zentrum dieses Beitrags.

Rechtlicher Rahmen: DSGVO trifft AI Act

Der AI Act verfolgt einen risikobasierten Ansatz: Systeme mit „unannehmbarem Risiko" sind verboten, „hochriskante" Systeme unterliegen strengen Konformitätspflichten, und alle übrigen Systeme tragen — je nach Einsatzzweck — allenfalls Dokumentations- oder Transparenzpflichten [1][6]. Generative KI fällt meist in die dritte Kategorie: Sie basiert überwiegend auf KI-Modellen mit allgemeinem Verwendungszweck (General-Purpose AI, GPAI), für die der AI Act ein eigenes Regime mit Risikominderungspflichten bei „systemischem Risiko" vorsieht [6]. Zentrale Rollen definiert Artikel 3: Der „Anbieter" entwickelt ein KI-System und bringt es in Verkehr, der „Betreiber" (Deployer) setzt es unter eigener Verantwortung ein — beide Rollen tragen unterschiedliche, aber sich ergänzende Pflichten [14].

Wichtig für die Praxis: Der AI Act ersetzt die DSGVO nicht, sondern ergänzt sie [6]. Die französische Datenschutzbehörde CNIL hat dazu Anfang 2026 ein mehrstufiges Compliance-Framework veröffentlicht, das Unternehmen bei der Entwicklungsphase datenverarbeitender KI-Systeme anleitet — von der Zweckbestimmung über die Wahl der Rechtsgrundlage (inklusive Web-Scraping-Absicherungen) bis zur Datenminimierung, Aufbewahrungsfristen, Betroffenenrechten und einer eigenen Fokus-Anleitung zu Datenschutz-Folgenabschätzungen [7]. Wo Betreiber hochriskante KI-Systeme einsetzen, verlangt Artikel 26 zusätzlich, dass die nach Artikel 13 bereitgestellten Informationen zur Erfüllung der DSGVO-Folgenabschätzungspflicht (Art. 35 DSGVO) genutzt werden — die beiden Regelwerke greifen hier technisch ineinander [13]. Enterprise-Compliance-Guides fassen die Schnittmenge inzwischen in praktikable Compliance-Checklisten und empfehlen als „compliance-sicheren" Rollout-Ansatz selbst gehostete, zugriffsbeschränkte, vollständig geloggte und menschlich überprüfte KI-Einsätze [8].

Artikel 50 im Detail: Vier Transparenzpflichten, zwei Adressaten

Artikel 50 unterscheidet klar zwischen Anbietern und Betreibern [16][19]. Anbieter müssen erstens KI-Systeme, die direkt mit Menschen interagieren — Chatbots, Sprachassistenten, KI-Agenten, Avatare —, so gestalten, dass für die Nutzer erkennbar ist, dass sie es mit einer KI zu tun haben, es sei denn, dies ist für eine „normal informierte, aufmerksame Person" ohnehin offensichtlich oder gesetzlich zur Straftatenverfolgung erlaubt [3][16][19]. Diese Pflicht gilt laut Kommentierung explizit auch für agentische KI, sobald eine Interaktion mit einer Person „vernünftigerweise vorhersehbar" ist [20]. Zweitens müssen Anbieter — auch von GPAI-Systemen — synthetische Audio-, Bild-, Video- oder Textinhalte mit maschinenlesbaren, erkennbaren Markierungen versehen, wobei die eingesetzten technischen Lösungen wirksam, interoperabel, robust und zuverlässig sein müssen, soweit dies technisch machbar ist [3][16][19].

Betreiber tragen zwei eigene Pflichten: Sie müssen Personen informieren, die Emotionserkennungs- oder biometrischen Kategorisierungssystemen ausgesetzt sind, und sie müssen Deepfakes sowie KI-generierte oder -manipulierte Texte zu Angelegenheiten von öffentlichem Interesse kennzeichnen — letzteres entfällt, wenn der Inhalt einer menschlichen Überprüfung mit redaktioneller Verantwortung unterzogen wurde oder eindeutig künstlerisch, kreativ, satirisch oder fiktional ist [3][16][19]. Für generative Systeme, die bereits vor dem 2. August 2026 am Markt waren, sieht die Kommission eine begrenzte Übergangsregel vor: Die maschinenlesbare Markierungspflicht greift für sie erst zum 2. Dezember 2026, ohne dass bereits veröffentlichte Alt-Inhalte rückwirkend markiert werden müssen [18][20]. Die Europäische Kommission hat diese Pflichten durch eigene, derzeit im Entwurf vorliegende Leitlinien konkretisiert, die den Anwendungsbereich vorläufig eingrenzen, ihn aber noch nicht abschließend abgrenzen, und die freiwillige „Code of Practice on Transparency of AI-Generated Content" ergänzen [2][5][19].

KI-generierter Code: Was Artikel 50(2) erfasst — und was nicht

Für Unternehmen, die Copilot, Cursor, Claude Code oder vergleichbare Coding-Assistenten einsetzen, ist die praktisch drängende Frage: Muss generierter Quellcode selbst als „künstlich erzeugter Inhalt" markiert werden? Die derzeit im Entwurf vorliegenden Kommissions-Leitlinien zu Artikel 50 beantworten das differenziert [19], und Kanzleikommentare — insbesondere von William Fry und Conventus Law — arbeiten die Trennlinie präzise heraus [20][21].

Die kurze Antwort: Quellcode als solcher fällt nicht unter die Markierungspflicht des Artikels 50(2). Die Leitlinien enthalten laut Kommentierung einen Ausnahmetatbestand für Quellcode-Ausgaben (Randnummer 64) — ein bewusster Carve-out, der genau auf agentische Entwicklerwerkzeuge wie Claude Code, Cursor und Copilot zielt, deren Kernfunktion die automatisierte Codeerzeugung ist [21]. Diese Ausnahme erstreckt sich nach übereinstimmender Lesart auf den Code im engeren Sinne und ebenso auf Inline-Kommentare und Docstrings, soweit sie integraler Bestandteil des Code-Artefakts sind [19][20][21]. Ergänzt wird dies durch eine eng gefasste B2B-/Industrie-Ausnahme: Rein technische Ausgaben, die nur einem beschränkten Fachpublikum zugänglich sind, können unter bestimmten Voraussetzungen ebenfalls von der Markierungspflicht ausgenommen sein [20].

Der Vorbehalt folgt jedoch unmittelbar danach — und genau hier liegt die Falle für Vendoren wie für Anwenderunternehmen: Die Ausnahme gilt nicht für eigenständig generierte Dokumentation. README-Dateien, marketingartige Produktbeschreibungen oder natürlichsprachliche Erklärtexte, die vom selben Tool separat erzeugt werden, sind „Text im gewöhnlichen Sinne" und fallen wieder vollumfänglich unter Artikel 50(2) [20][21]. Auch generative Systeme, die auf GPAI-Modellen aufbauen, bleiben markierungspflichtig, soweit sie solche Textausgaben erzeugen [20]. Die Kommentierung warnt davor, aus dem Quellcode-Carve-out eine pauschale „wir generieren ja nur Code"-Ausnahme abzuleiten; Anbieter von Coding-Agenten sollten ihre Offenlegungsmechanismen gezielt entlang dieser Trennlinie gestalten, statt sich auf eine Blankett-Freistellung zu verlassen [21]. Diese Feinabgrenzung sei — so der Hinweis in der Kommentierung — noch nicht abschließend geklärt und werde sich erst durch die finalen Leitlinien oder die Aufsichtspraxis endgültig festigen [21].

Für Unternehmen bedeutet das konkret: Ein internes Regelwerk „KI-generierter Code ist ohnehin ausgenommen" reicht nicht. Wer KI-gestützte Entwicklungstools einsetzt und dabei automatisiert Begleitdokumentation, README-Dateien oder Produktbeschreibungen erzeugen lässt, muss diese Textausgaben gesondert auf ihre Markierungspflicht prüfen — unabhängig davon, dass der zugrunde liegende Code selbst von der Markierungspflicht befreit bleibt. Wer Coding-Assistenten als internes Werkzeug mit stark eingeschränktem Nutzerkreis betreibt, kann sich zusätzlich auf die B2B-Ausnahme stützen, sollte deren enge Voraussetzungen aber dokumentieren [20].

Warum Wasserzeichen bei Text schwerer zu realisieren sind als bei Audio und Bild

Die gesetzliche Anforderung klingt einfach: „maschinenlesbar, erkennbar, wirksam, interoperabel, robust und zuverlässig" [3]. Technisch ist sie es nicht — und die Schwierigkeit ist bei Text ungleich größer als bei Audio, Bild oder Video. Zwischen den regulatorischen Erwartungen und den technischen Grenzen bestehender Wasserzeichen-Verfahren klafft eine wachsende Lücke; ohne durchsetzbare Standards, Audit-Infrastruktur und Vollzugsmechanismen droht „symbolische Compliance" statt wirksamer Aufsicht [17].

Die peer-reviewte Forschung liefert dazu inzwischen belastbare Evidenz. Kein marktübliches LLM-Wasserzeichenverfahren ist gegen die volle Bandbreite realistischer Nachbearbeitungsschritte gleichermaßen robust — belegt an zehn Verfahren, die die einheitliche Testumgebung „WaterPark" der Arbeit „Watermark under Fire" gegen zwölf repräsentative Entfernungsangriffe — von Paraphrasierung bis zu gezielten adversariellen Manipulationen — antreten lässt, um systematisch abzuleiten, wie Design-Entscheidungen die Robustheit beeinflussen und welche Betriebspraktiken sich in feindlichen Umgebungen bewähren (angenommen bei EMNLP 2025) [22]. Wirksamkeit hängt dabei stark vom jeweiligen Angriffsvektor und von Konfigurationsentscheidungen ab [22].

Noch konkreter für Text wird es in der Arbeit von Kirchenbauer et al. (ICLR 2024): Text-Wasserzeichen überleben sowohl menschliches als auch maschinelles Paraphrasieren in vielen Fällen, weil Paraphrasen statistisch gesehen n-Gramme oder längere Fragmente des ursprünglichen Textes „durchsickern" lassen — eine zuverlässige Erkennung mit hoher Konfidenz ist damit grundsätzlich möglich, wie die Untersuchung zur Robustheit gegenüber menschlichem Umschreiben, maschineller Paraphrasierung und dem Einbetten in längere, handgeschriebene Dokumente zeigt [23]. Der Preis dafür ist allerdings hoch: Unter starker menschlicher Paraphrasierung braucht es rund 800 beobachtete Token, um bei einer Falsch-Positiv-Rate von 1e-5 eine verlässliche Detektion zu erzielen [23] — für kurze Chat-Antworten, Codekommentare oder Social-Media-Posts ist dieser Schwellenwert oft schlicht nicht erreichbar. Bild-, Audio- und Video-Wasserzeichen können dagegen auf robustere Signalverarbeitungsverfahren zurückgreifen, die Kompression und Neucodierung besser überstehen; bei natürlichsprachlichem Text fehlt dieses redundante Signalreservoir weitgehend, was die vom Gesetzgeber geforderte Zuverlässigkeit „soweit technisch machbar" zu einer echten Ingenieursherausforderung macht [17][22][23].

Was „effektiv, robust, interoperabel und dokumentiert" konkret bedeutet

Der AI Act verlangt keine perfekte, sondern eine dem Stand der Technik angemessene Lösung — und er macht die Erfüllung dieser Pflicht überprüfbar. Die freiwillige Code of Practice on Transparency of AI-Generated Content, deren finale Fassung am 10. Juni 2026 veröffentlicht wurde, konkretisiert in Abschnitt 1 die Anbieterpflichten nach Artikel 50(2): Die eingesetzten maschinenlesbaren Markierungs- und Erkennungslösungen müssen effektiv, interoperabel, robust und zuverlässig sein, soweit dies technisch machbar ist, zugeschnitten auf den jeweiligen Inhaltstyp, den Stand der Technik, einschlägige technische Normen und die Verhältnismäßigkeit des Aufwands [24]. Abschnitt 2 regelt spiegelbildlich die Betreiberpflichten nach Artikel 50(4) — Gestaltung, Platzierung und Präsentation von Kennzeichnungen für Deepfakes und öffentlich relevante KI-Texte, samt eines optionalen EU-Icons [24].

Für die Compliance-Praxis maßgeblich ist der Nachweisweg, den die Kommissions-Leitlinien beschreiben: Wer die Code of Practice unterzeichnet und einhält, kann die Einhaltung der Markierungs- und Kennzeichnungspflichten primär darüber demonstrieren. Wer sich der Code of Practice nicht anschließt, muss die Compliance durch andere, gleichwertig geeignete Mittel nachweisen — und trägt damit die volle Dokumentationslast selbst [19]. Für die übrigen Transparenzpflichten dürfen Unternehmen angemessene Maßnahmen ohnehin selbst bestimmen, sollen dabei aber die Leitlinien berücksichtigen [19]. Wichtig ist zugleich die rechtliche Einordnung der Code of Practice selbst: Sie ist ausdrücklich freiwillig und begründet keine Pflichten, die über den AI Act hinausgehen — sie soll lediglich eine konsistente, praxistaugliche und verhältnismäßige Umsetzung der bereits bestehenden gesetzlichen Transparenzregeln fördern, ohne den AI Act oder die Kommissions-Leitlinien zu ersetzen [24]. Für Unternehmen heißt das in der Praxis: Beitritt zur Code of Practice reduziert den eigenen Dokumentations- und Nachweisaufwand erheblich, ersetzt aber nicht die inhaltliche Auseinandersetzung mit den zugrunde liegenden Pflichten. Wer eigene technische Maßnahmen wählt — etwa aus Gründen der Produktarchitektur —, sollte deren Wirksamkeit, Robustheit und Angemessenheit von Anfang an so dokumentieren, dass sie im Zweifel gegenüber Marktüberwachungsbehörden, dem AI Office oder dem Europäischen Datenschutzbeauftragten belastbar ist [19].

Von der begrifflichen Klarheit her lohnt sich zudem die saubere Trennung dreier oft vermischter Konzepte: technisches Wasserzeichen (Markierung im Inhalt selbst), Kennzeichnung/Labeling (sichtbarer Hinweis für Nutzer) und allgemeine Offenlegungspflicht (Disclosure) — mit jeweils unterschiedlichen Verantwortlichkeiten zwischen Anbieter und Betreiber [3][19].

DSGVO-Schnittstellen: Wenn KI-generierte Inhalte personenbezogene Daten enthalten

Kennzeichnungspflichten nach Artikel 50 lösen die datenschutzrechtlichen Fragen nicht automatisch mit. Sobald ein KI-System für Emotionserkennung oder biometrische Kategorisierung eingesetzt wird, verlangt Artikel 50(3) eine Informationspflicht gegenüber betroffenen Personen und verweist zugleich auf die Verarbeitung nach der DSGVO, der Verordnung (EU) 2018/1725 und der Richtlinie (EU) 2016/680 [3]. Die CNIL-Empfehlungen zeigen, wie tief diese Verzahnung in der Entwicklungsphase reicht: von der Festlegung des Verarbeitungszwecks über die Bestimmung von Verantwortlichkeit und Auftragsverarbeitung, die Wahl der Rechtsgrundlage (mit gesonderter Anleitung zu berechtigtem Interesse und Web-Scraping-Schutzmaßnahmen), die Prüfung der Rechtmäßigkeit einer Datenweiterverwendung, Datenminimierung und Aufbewahrungsfristen bis zur Sicherung von Betroffenenrechten über Datensätze und Modelle hinweg [7]. Die AI Act-Betreiberpflichten nach Artikel 26 verweisen ihrerseits auf die datenschutzrechtliche Folgenabschätzung: Betreiber müssen die nach Artikel 13 bereitgestellten Informationen nutzen, um ihre DSGVO-Pflichten nach Artikel 35 beziehungsweise nach Artikel 27 der Richtlinie (EU) 2016/680 zu erfüllen [13]. Wer generative KI zur Verarbeitung personenbezogener Daten einsetzt — etwa in Kundenservice-Chatbots oder bei der automatisierten Textgenerierung mit Kundendaten —, muss also DSGVO-Grundlagen und AI-Act-Transparenzpflichten von Anfang an gemeinsam denken, nicht nacheinander abarbeiten [6][8].

Auch die Haftungsfrage bleibt in Bewegung. Eine Analyse im Cambridge Forum on AI: Law and Governance untersucht, ob AI Act, der Entwurf der KI-Haftungsrichtlinie (AILD) und die überarbeitete Produkthaftungsrichtlinie (revPLD) die Schadenshaftung für generative KI ausreichend abdecken. Sie tun es nicht vollständig: Es bleiben Lücken — etwa Unklarheiten im Anwendungsbereich und Passungsprobleme mit dem generischen, aufgabenunabhängigen Charakter von Foundation-Modellen —, und künftige Haftungsszenarien verteilen sich entlang der Trainings-, Nutzungs- und Output-Erzeugungsphase [9]. Für Unternehmen bedeutet das: Selbst vollständige Artikel-50-Compliance schließt zivilrechtliche Haftungsrisiken aus fehlerhaften oder schädigenden KI-Ausgaben nicht per se aus.

Bußgelder, Zeitplan und die Frage der Fristen

Verstöße gegen den AI Act sind teuer. Artikel 99 staffelt die Bußgelder in drei Stufen: Verstöße gegen verbotene Praktiken können mit bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes geahndet werden, Verstöße gegen sonstige Anbieter-, Betreiber- oder Notified-Body-Pflichten mit bis zu 15 Millionen Euro oder 3 Prozent, und die Bereitstellung falscher oder irreführender Informationen mit bis zu 7,5 Millionen Euro oder 1 Prozent — KMU profitieren jeweils vom niedrigeren der beiden Beträge [15]. Die Höhe richtet sich nach Faktoren wie Art des Verstoßes, Unternehmensgröße und Vorverstößen; Mitgliedstaaten müssen der Kommission jährlich über verhängte Bußgelder berichten [15].

Zeitlich gilt: Die allgemeinen Bestimmungen und Verbote gelten bereits seit dem 2. Februar 2025, die GPAI-Regeln und Governance-Strukturen seit dem 2. August 2025 [18]. Seit dem 2. August 2026 sind die Transparenzregeln nach Artikel 50 sowie ein Großteil der übrigen Vorschriften anwendbar, mit Vollzugsbeginn auf nationaler und EU-Ebene für GPAI-Modelle, Verbote, Transparenzregeln und KI-Kompetenzpflichten [18]. Der 2. Dezember 2026 markiert zusätzlich neue Verbote (nicht-einvernehmliche sexuelle Deepfakes, Missbrauchsmaterial) sowie das Ende der Übergangsfrist für Artikel 50(2) bei Alt-Systemen [18]. Nach dem Einigungspaket „Digital Omnibus" wurden die Fristen für hochriskante KI-Systeme nach Annex III auf den 2. Dezember 2027 und für Hochrisiko-KI in regulierten Produkten nach Annex I auf den 2. August 2028 verschoben [18]. Diese Verschiebung betrifft jedoch nur die strengsten Hochrisiko-Pflichten — Artikel 50 gilt davon unberührt bereits jetzt, und die Bußgelder sind real [11][18].

Praktische Umsetzung im Unternehmen

Was folgt daraus für die Compliance-Praxis? Erstens: Rollenklärung. Wer als Anbieter und wer als Betreiber im Sinne von Artikel 3 auftritt, entscheidet darüber, welche der vier Artikel-50-Pflichten überhaupt greifen [14][16]. Zweitens: Inventarisierung aller generativen KI-Einsätze — inklusive „Schatten-KI", die von Fachabteilungen ohne zentrale Freigabe genutzt wird, denn auch der bloße Einsatz von Drittanbieter-Tools macht ein Unternehmen zum Betreiber mit eigenen Pflichten [10]. Drittens: Für jeden Anwendungsfall gesondert prüfen, ob Ausgaben unter die Markierungspflicht fallen — mit besonderer Sorgfalt bei Coding-Assistenten, deren Code-Output ausgenommen sein kann, deren begleitende Dokumentation aber nicht [20][21]. Viertens: Entscheidung über den Beitritt zur Code of Practice, da dieser den Dokumentationsaufwand für den Compliance-Nachweis spürbar reduziert [19][24]. Fünftens: technische und organisatorische Maßnahmen dokumentieren — welches Markierungsverfahren wurde gewählt, warum gilt es als Stand der Technik, welche Robustheitsgrenzen sind bekannt [19][22][23]. Sechstens: DSGVO-Prozesse und AI-Act-Transparenzpflichten organisatorisch zusammenführen, etwa über ein cross-funktionales Governance-Gremium mit Vertretern aus Recht, Sicherheit, Produkt und Engineering, das Meilensteine bei Design, Test und Launch verantwortet [8][12]. Praxisleitfäden zu Artikel 50 empfehlen dafür konkrete Checklisten mit Fristen, Verantwortlichkeiten und Freigabeprozessen [4].

Fazit

Artikel 50 des AI Act verlangt von Unternehmen keine pauschale „KI-Kennzeichnung", sondern eine differenzierte, rollen- und inhaltstypabhängige Compliance-Architektur. Für KI-generierten Code gilt: Der Code selbst — inklusive Kommentaren und Docstrings — bleibt von der Markierungspflicht ausgenommen, doch diese Ausnahme endet dort, wo dieselben Werkzeuge eigenständigen, natürlichsprachlichen Text erzeugen — README-Dateien, Produktbeschreibungen, Erklärtexte [19][20][21]. Für Text im Allgemeinen gilt zudem, dass die gesetzlich geforderte Robustheit von Wasserzeichen technisch anspruchsvoller ist als bei Audio oder Bild, weil Paraphrasierungsangriffe erst nach mehreren Hundert Token verlässlich erkennbar werden [22][23]. Wer diese Feinheiten ignoriert und sich auf pauschale Ausnahmen verlässt, riskiert Bußgelder bis zu 15 Millionen Euro oder 3 Prozent des Jahresumsatzes [15] und darüber hinaus Haftungsrisiken, die über den AI Act hinausreichen [9].

Die Frist zum 2. August 2026 ist verstrichen: Artikel 50 gilt. Was bleibt, ist die Übergangsregel bis zum 2. Dezember 2026 für Systeme, die vorher am Markt waren — und für alle anderen die Frage, ob die eigene Umsetzung einer Prüfung standhält. Wer bis heute nicht begonnen hat, arbeitet nicht mehr auf eine Frist hin, sondern in einem Zustand, der bereits sanktionsbewehrt ist [18][24].