EU AI Act & GDPR: Labelling Obligations for AI-Generated Code and Text

Researched and written by ResearchRaven, the AI research system I built (24 sources) — it checks every sourced claim against its source automatically. I reviewed and approved the finished text on the merits; editorial responsibility under Art. 50(4) AI Act rests with Florian Drechsler.

The transparency obligations under Article 50 of the EU AI Act (Regulation (EU) 2024/1689) have applied since 2 August 2026 [3][18]. Generative AI systems already on the market before that date have a transitional period until 2 December 2026, within which the machine-readable marking required by Article 50(2) must be retrofitted [18][24]. In parallel, the GDPR has for years required transparency, a lawful basis and data minimisation wherever personal data is processed — a requirement AI systems do not displace but add to [6][7]. For companies running generative AI in production, the two regimes merge into a set of duties that reaches well beyond the familiar question "is our system high-risk?". One of the most pressing practical questions, and one rarely answered cleanly so far: does the labelling obligation also cover code produced by assistants such as Copilot, Cursor or Claude Code? The Commission's draft guidelines and their reading by law firms now give a provisional, differentiated answer — and that answer is the centre of this piece.

The legal frame: GDPR meets AI Act

The AI Act takes a risk-based approach: systems posing "unacceptable risk" are prohibited, "high-risk" systems face strict conformity obligations, and everything else carries — depending on purpose — at most documentation or transparency duties [1][6]. Generative AI usually falls into the third category: it is mostly built on general-purpose AI models (GPAI), for which the AI Act provides a separate regime with risk-mitigation duties where there is "systemic risk" [6]. Article 3 defines the central roles: the "provider" develops an AI system and places it on the market; the "deployer" uses it under its own authority — the two carry different but complementary obligations [14].

What matters in practice: the AI Act does not replace the GDPR, it supplements it [6]. The French data protection authority CNIL published a staged compliance framework in early 2026 guiding companies through the development phase of data-processing AI systems — from defining the purpose, through choosing the legal basis (including safeguards around web scraping), to data minimisation, retention periods, data subject rights and a dedicated focus sheet on data protection impact assessments [7]. Where deployers use high-risk AI systems, Article 26 additionally requires that the information provided under Article 13 be used to fulfil the DPIA obligation under Art. 35 GDPR — the two regimes interlock mechanically at this point [13]. Enterprise compliance guides now condense the overlap into workable checklists and recommend self-hosted, access-restricted, fully logged and human-reviewed AI deployments as the "compliance-safe" rollout approach [8].

Article 50 in detail: four transparency duties, two addressees

Article 50 draws a clear line between providers and deployers [16][19]. Providers must, first, design AI systems that interact directly with people — chatbots, voice assistants, AI agents, avatars — so that users can tell they are dealing with an AI, unless this is obvious to a "reasonably well-informed, observant" person anyway, or permitted by law for the detection of criminal offences [3][16][19]. Commentary holds this duty to apply explicitly to agentic AI as soon as interaction with a person is "reasonably foreseeable" [20]. Second, providers — including those of GPAI systems — must mark synthetic audio, image, video or text content with machine-readable, detectable markings, and the technical solutions used must be effective, interoperable, robust and reliable as far as this is technically feasible [3][16][19].

Deployers carry two duties of their own: they must inform people exposed to emotion recognition or biometric categorisation systems, and they must label deepfakes as well as AI-generated or manipulated text on matters of public interest — the latter falling away where the content has undergone human review with editorial responsibility, or is evidently artistic, creative, satirical or fictional [3][16][19]. For generative systems already on the market before 2 August 2026, the Commission provides a limited transitional rule: the machine-readable marking duty applies to them only from 2 December 2026, without any obligation to retroactively mark content already published [18][20]. The European Commission has fleshed out these duties in its own guidelines, currently in draft, which provisionally narrow the scope without yet delimiting it conclusively, and which complement the voluntary "Code of Practice on Transparency of AI-Generated Content" [2][5][19].

AI-generated code: what Article 50(2) covers — and what it does not

For companies using Copilot, Cursor, Claude Code or comparable coding assistants, the pressing practical question is whether generated source code itself must be marked as "artificially generated content". The Commission's draft guidelines on Article 50 answer this in a differentiated way [19], and law-firm commentary — particularly from William Fry and Conventus Law — draws the dividing line precisely [20][21].

The short answer: source code as such does not fall under the marking obligation of Article 50(2). According to the commentary, the guidelines contain an exemption for source-code outputs (paragraph 64) — a deliberate carve-out aimed precisely at agentic developer tools such as Claude Code, Cursor and Copilot, whose core function is automated code generation [21]. On the consistent reading, this exemption extends to code in the narrow sense and equally to inline comments and docstrings, insofar as they are an integral part of the code artefact [19][20][21]. It is complemented by a narrowly drawn B2B/industrial exemption: purely technical outputs accessible only to a limited professional audience may, under certain conditions, also be exempt from the marking obligation [20].

The caveat follows immediately — and this is where the trap lies for vendors and user companies alike: the exemption does not cover independently generated documentation. README files, marketing-style product descriptions or natural-language explanatory text produced separately by the same tool are "text in the ordinary sense" and fall squarely back under Article 50(2) [20][21]. Generative systems built on GPAI models likewise remain subject to marking where they produce such text outputs [20]. The commentary warns against deriving a blanket "we only generate code" exemption from the source-code carve-out; providers of coding agents should design their disclosure mechanisms deliberately along this dividing line rather than relying on a general exclusion [21]. This fine-grained boundary is — as the commentary notes — not yet settled, and will only firm up through the final guidelines or supervisory practice [21].

In concrete terms for companies: an internal rule stating "AI-generated code is exempt anyway" is not enough. Anyone using AI-assisted development tools that also automatically produce accompanying documentation, README files or product descriptions must assess those text outputs separately for their marking obligation — regardless of the fact that the underlying code itself remains exempt. Companies running coding assistants as an internal tool with a strictly limited user base can additionally rely on the B2B exemption, but should document its narrow conditions [20].

Why watermarking text is harder than watermarking audio and images

The statutory requirement sounds simple: "machine-readable, detectable, effective, interoperable, robust and reliable" [3]. Technically it is not — and the difficulty is far greater for text than for audio, image or video. A widening gap separates regulatory expectations from the technical limits of existing watermarking methods; without enforceable standards, audit infrastructure and enforcement mechanisms, the risk is "symbolic compliance" rather than effective oversight [17].

Peer-reviewed research now provides solid evidence here. No commercially available LLM watermarking method is equally robust against the full range of realistic post-processing steps — demonstrated across ten methods, which the unified testbed "WaterPark" from the paper "Watermark under Fire" pits against twelve representative removal attacks, from paraphrasing to targeted adversarial manipulation, in order to derive systematically how design decisions affect robustness and which operating practices hold up in adversarial environments (accepted at EMNLP 2025) [22]. Effectiveness depends heavily on the specific attack vector and on configuration decisions [22].

Kirchenbauer et al. (ICLR 2024) get more specific for text: text watermarks survive both human and machine paraphrasing in many cases, because paraphrases statistically "leak" n-grams or longer fragments of the original text — reliable detection with high confidence is therefore possible in principle, as their study of robustness against human rewriting, machine paraphrasing and embedding into longer, hand-written documents shows [23]. The price is high, however: under heavy human paraphrasing it takes around 800 observed tokens to achieve reliable detection at a false positive rate of 1e-5 [23] — for short chat replies, code comments or social media posts that threshold is often simply out of reach. Image, audio and video watermarks, by contrast, can draw on more robust signal-processing methods that survive compression and re-encoding better; natural-language text largely lacks that redundant signal reservoir, which turns the reliability demanded by the legislator "as far as technically feasible" into a genuine engineering challenge [17][22][23].

What "effective, robust, interoperable and documented" actually means

The AI Act does not demand a perfect solution, but one appropriate to the state of the art — and it makes compliance with that duty verifiable. The voluntary Code of Practice on Transparency of AI-Generated Content, whose final version was published on 10 June 2026, sets out provider obligations under Article 50(2) in Section 1: the machine-readable marking and detection solutions used must be effective, interoperable, robust and reliable as far as technically feasible, tailored to the content type in question, the state of the art, relevant technical standards and the proportionality of the effort involved [24]. Section 2 mirrors this for deployer obligations under Article 50(4) — design, placement and presentation of labels for deepfakes and publicly relevant AI text, including an optional EU icon [24].

What matters for compliance practice is the evidentiary route the Commission's guidelines describe: those who sign and adhere to the Code of Practice can demonstrate compliance with the marking and labelling obligations primarily through it. Those who do not join must demonstrate compliance by other, equally suitable means — and carry the full documentation burden themselves [19]. For the remaining transparency obligations, companies may determine appropriate measures themselves in any case, but are expected to take the guidelines into account [19]. The legal status of the Code of Practice itself matters equally: it is expressly voluntary and creates no obligations beyond the AI Act — it is meant only to promote consistent, workable and proportionate implementation of existing statutory transparency rules, without replacing the AI Act or the Commission's guidelines [24]. In practice this means: joining the Code of Practice substantially reduces a company's own documentation and evidentiary burden, but does not replace engaging with the underlying obligations on the merits. Anyone choosing their own technical measures — for reasons of product architecture, say — should document their effectiveness, robustness and adequacy from the outset in a way that will hold up before market surveillance authorities, the AI Office or the European Data Protection Supervisor [19].

On terminology, it is worth cleanly separating three concepts that are often conflated: technical watermarking (marking within the content itself), labelling (a visible notice for users), and general disclosure — each carrying different responsibilities as between provider and deployer [3][19].

GDPR interfaces: when AI-generated content contains personal data

Labelling obligations under Article 50 do not automatically resolve data protection questions. As soon as an AI system is used for emotion recognition or biometric categorisation, Article 50(3) requires informing the individuals concerned and simultaneously refers to processing under the GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680 [3]. The CNIL recommendations show how deeply this interlocking reaches into the development phase: from defining the processing purpose, through determining controllership and processing arrangements, choosing the legal basis (with separate guidance on legitimate interest and web-scraping safeguards), assessing the lawfulness of data reuse, data minimisation and retention periods, to securing data subject rights across datasets and models [7]. The AI Act deployer obligations under Article 26 in turn point back to the data protection impact assessment: deployers must use the information provided under Article 13 to fulfil their GDPR duties under Article 35, or Article 27 of Directive (EU) 2016/680 respectively [13]. Anyone using generative AI to process personal data — in customer service chatbots, say, or automated text generation involving customer data — must therefore think GDPR foundations and AI Act transparency duties together from the start, rather than working through them in sequence [6][8].

Liability, too, remains in motion. An analysis in the Cambridge Forum on AI: Law and Governance examines whether the AI Act, the draft AI Liability Directive (AILD) and the revised Product Liability Directive (revPLD) adequately cover damage liability for generative AI. They do not do so fully: gaps remain — ambiguities in scope, and fit problems with the generic, task-independent character of foundation models — and future liability scenarios distribute across the training, use and output-generation phases [9]. For companies this means: even full Article 50 compliance does not in itself exclude civil liability risks arising from faulty or harmful AI outputs.

Penalties, timeline and the question of deadlines

Breaches of the AI Act are expensive. Article 99 tiers fines at three levels: breaches of prohibited practices can be sanctioned with up to EUR 35 million or 7 per cent of worldwide annual turnover, breaches of other provider, deployer or notified body obligations with up to EUR 15 million or 3 per cent, and supplying false or misleading information with up to EUR 7.5 million or 1 per cent — SMEs benefit from the lower of the two amounts in each case [15]. The amount depends on factors such as the nature of the breach, company size and prior infringements; Member States must report annually to the Commission on fines imposed [15].

On timing: the general provisions and prohibitions have applied since 2 February 2025, the GPAI rules and governance structures since 2 August 2025 [18]. Since 2 August 2026 the transparency rules under Article 50 and most remaining provisions have applied, with enforcement beginning at national and EU level for GPAI models, prohibitions, transparency rules and AI literacy obligations [18]. 2 December 2026 additionally marks new prohibitions (non-consensual sexual deepfakes, abuse material) and the end of the transitional period for Article 50(2) for legacy systems [18]. Following the "Digital Omnibus" agreement package, deadlines for high-risk AI systems under Annex III moved to 2 December 2027, and for high-risk AI in regulated products under Annex I to 2 August 2028 [18]. That postponement concerns only the strictest high-risk obligations, however — Article 50 applies now regardless, and the fines are real [11][18].

Practical implementation inside a company

What follows for compliance practice? First: clarify roles. Who acts as provider and who as deployer within the meaning of Article 3 determines which of the four Article 50 duties apply at all [14][16]. Second: inventory every generative AI use — including "shadow AI" used by departments without central approval, since merely using third-party tools makes a company a deployer with duties of its own [10]. Third: assess for each use case separately whether outputs fall under the marking obligation — with particular care around coding assistants, whose code output may be exempt while their accompanying documentation is not [20][21]. Fourth: decide on joining the Code of Practice, given that it noticeably reduces the documentation burden for demonstrating compliance [19][24]. Fifth: document technical and organisational measures — which marking method was chosen, why it counts as state of the art, which robustness limits are known [19][22][23]. Sixth: bring GDPR processes and AI Act transparency duties together organisationally, for instance through a cross-functional governance body with representatives from legal, security, product and engineering, owning milestones at design, test and launch [8][12]. Practical guides to Article 50 recommend concrete checklists with deadlines, responsibilities and approval processes for this [4].

Conclusion

Article 50 of the AI Act does not require companies to apply a blanket "AI label", but to build a differentiated compliance architecture that depends on role and content type. For AI-generated code: the code itself — including comments and docstrings — remains exempt from the marking obligation, but that exemption ends where the same tools produce independent, natural-language text: README files, product descriptions, explanatory copy [19][20][21]. For text generally, the robustness the law demands of watermarks is technically more demanding than for audio or image, because paraphrasing attacks only become reliably detectable after several hundred tokens [22][23]. Anyone ignoring these distinctions and relying on blanket exemptions risks fines of up to EUR 15 million or 3 per cent of annual turnover [15], and beyond that liability risks reaching past the AI Act [9].

The 2 August 2026 deadline has passed: Article 50 applies. What remains is the transitional rule until 2 December 2026 for systems already on the market before then — and, for everyone else, the question of whether their implementation would survive scrutiny. Anyone who has not started by now is no longer working towards a deadline, but operating in a state that already carries sanctions [18][24].