If Article 51 is about which foundation models the regulator will chase, Article 53(1)(c) and Article 53(1)(d) are about which data those models ate to become foundation models in the first place. The EU treats training-data provenance as a first-class compliance object: a copyright policy that respects the text-and-data-mining opt-out reservations of rightsholders, and a public summary of training content according to an AI Office template that every GPAI provider, signatory or not, must publish. The downstream consequence is a deployer-side data-sourcing policy you build in your own organization, because the moment you fine-tune an upstream model you become the provider of the fine-tuned dataset under Article 25(1)(b) and inherit your own provenance burden. This lesson is the L2.Ch6.L2 playbook for drafting that policy, aligned to the GPAI Code of Practice transparency template and the AI Office's expected schema for the Article 53(1)(d) public summary.

Why Training-Data Provenance Is Now a Board-Level Question

In 2023, training-data provenance was a research-ethics topic for academic ML teams. In 2024, it became a litigation surface as the New York Times v. OpenAI, Authors Guild v. OpenAI, Getty Images v. Stability AI, and a string of class actions made it impossible to discuss frontier-model training without a copyright lawyer in the room. In 2025, the EU codified the question, Article 53(1)(c) obliging every GPAI provider to implement a copyright policy that complies with Union copyright law (in particular respecting the text-and-data-mining opt-outs of Copyright Directive Article 4(3)), and Article 53(1)(d) obliging every GPAI provider to publish a sufficiently detailed summary of training content according to a template produced by the AI Office. The GPAI Code of Practice (final July 10, 2025) added the operational Copyright chapter that gives signatories a presumption-of-compliance pathway. The result, in May 2026, is a regulatory regime where training-data provenance is one of the most concrete operational obligations of the entire AI Act.

For your organization, the obligation is doubled. As a deployer, you depend on the upstream GPAI provider's Article 53(1)(c) and 53(1)(d) work. You must verify the policy exists, you must verify the summary is published, you must verify both are consistent with your downstream use case. As a fine-tuner, the moment you take an upstream base model and substantially fine-tune it under Article 25(1)(b), you become the provider of the fine-tuned model and you inherit your own training-data provenance obligations on the fine-tune dataset. Your organization has to know what was in the fine-tune set, whether rightsholders' TDM opt-outs were respected, whether GDPR special-category-data screens were applied, and whether the resulting dataset survives an audit. The data-sourcing policy is the artifact that proves it, and the L2 deliverable that your AI Officer signs.

The non-obvious complication is that the U.S. has no equivalent TDM opt-out regime. Fair use under 17 U.S.C. §107 is the closest analog, and the courts are actively shaping the doctrine through pending litigation. An enterprise operating on both sides of the Atlantic cannot rely on a single training-data sourcing standard; it must run an EU policy that respects Article 4(3) opt-outs and a parallel U.S. posture that tracks fair-use litigation and the U.S. Copyright Office's evolving guidance on AI-assisted works. The data-sourcing policy reflects both regimes explicitly.

The TDM Opt-Out Regime - Copyright Directive Article 4(3) and the Machine-Readable Reservation

The EU's text-and-data-mining framework lives in Directive (EU) 2019/790, the Digital Single Market Copyright Directive. Article 3 creates a mandatory TDM exception for research organizations and cultural heritage institutions. Article 4 creates a broader TDM exception for any beneficiary (including commercial AI training), but Article 4(3) gives rightsholders the right to reserve their works from that exception. The reservation, when made, removes the TDM safe harbor for that work; any TDM use thereafter requires the rightsholder's authorization.

The operational language of Article 4(3) is decisive: the reservation must be made in an "appropriate manner," and for content made publicly available online, the reservation must be made by "machine-readable means." That single phrase, machine-readable means, is the entire infrastructure question. How does a rightsholder declare a TDM reservation in a form that an AI training crawler can detect? How does a GPAI provider build a crawler that respects those reservations? The answer in May 2026 is a stack of overlapping conventions:

• robots.txt. The decades-old Robots Exclusion Protocol (now IETF RFC 9309) gives publishers the ability to disallow specific user-agents from crawling their site. AI providers have published their crawler user-agents (GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider, others). A site that disallows these user-agents is asserting a TDM reservation against those crawlers. The Commission's preliminary guidance treats robots.txt as one acceptable machine-readable means under Article 4(3), provided the user-agent identifies as an AI training crawler.
• HTML meta tags and X-Robots-Tag headers. The <meta name="robots" content="noai,noimageai"> tag and the parallel X-Robots-Tag HTTP header signal TDM reservation at the page level. The "noai" / "noimageai" tokens were popularized by DeviantArt in 2023 and have been adopted by Adobe, Shutterstock, and other rights-management platforms.
• TDM Reservation Protocol (TDMRep). The W3C Community Group's TDMRep specification provides a more granular machine-readable TDM-reservation format using tdm-reservation and tdm-policy properties, transportable via HTTP headers, HTML meta, or a well-known JSON file at /.well-known/tdmrep.json. TDMRep is the most rightsholder-friendly of the conventions because it allows granular policy expression (e.g., "no commercial TDM, but research TDM allowed").
• IETF AI Preferences Working Group. The IETF AIPREF working group (chartered 2024) is drafting AI Preferences, a successor convention designed to consolidate the fragmented robots.txt / meta-tag / TDMRep ecosystem into a single machine-readable preference signal that distinguishes AI-training crawling from generic indexing, RAG retrieval from training set inclusion, and commercial from research uses. Drafts are circulating in 2026; the final RFC is expected in late 2026 or 2027.
• C2PA and content provenance signals. Coalition for Content Provenance and Authenticity (C2PA) manifests embedded in images, video, and audio carry training-permission flags. While C2PA is primarily a provenance standard, the Training and Mining Assertion (TMA) extension provides explicit do-not-train signaling for visual media.

For a GPAI provider, the operational expectation is to honor all of the above signals in its training crawler. The GPAI Code of Practice Copyright chapter operationalizes this: signatory providers commit to detecting and respecting robots.txt, meta-tag, TDMRep, and emerging AI-preferences signals, and to documenting the detection process. For a deployer, the operational expectation is to honor the same signals when collecting data internally for fine-tuning, evaluation, or RAG corpus construction.

How the TDM Opt-Out Flows Through the AI Stack

A rightsholder publishes a recipe blog. They add <meta name="robots" content="noai"> to every page and disallow GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider in their robots.txt. They publish a /.well-known/tdmrep.json reserving TDM rights. What changes downstream?

A GPAI provider's crawler that respects these signals must skip the site entirely (robots.txt) and exclude any pages it encounters via other routes (meta tags, TDMRep). The provider's training-data summary under Article 53(1)(d) should reflect the exclusion at the aggregate level (e.g., "approximately X% of candidate web content was excluded due to robots.txt or meta-tag reservations"). The provider's Article 53(1)(c) copyright policy should describe the detection and exclusion process. The provider's internal audit trail should retain the per-URL exclusion record sufficient to demonstrate compliance to the AI Office on inquiry.

A deployer fine-tuning the resulting base model on its own internal recipe corpus inherits a parallel obligation: the deployer's collection of training data for the fine-tune must also respect TDM opt-outs of any external content used. If the deployer's fine-tune corpus includes scraped recipe pages from the same rightsholder, the deployer is on the hook regardless of the upstream provider's compliance. The data-sourcing policy is what binds the deployer's collection workflow to the same standards.

Article 53(1)(c) - The GPAI Copyright Policy and the Code of Practice Chapter

The text of Article 53(1)(c) is short and explicit: every GPAI provider must "put in place a policy to comply with Union law on copyright and related rights, and in particular to identify and comply with, including through state-of-the-art technologies, a reservation of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790." Four operational elements live inside that sentence:

• A documented policy, not an informal practice, but a written policy that can be exhibited to the AI Office or a national competent authority on request.
• Compliance with Union copyright law generally, not just the TDM opt-out, but the entire body of EU copyright law applicable to the provider's training activities.
• Identification of TDM reservations, active detection of opt-out signals using state-of-the-art technologies. The "state-of-the-art" language is a moving target; what counts as state of the art in 2026 is the robots.txt / meta-tag / TDMRep / AI-preferences stack, plus emerging C2PA signals for visual media.
• Compliance with the reservation once identified, exclusion of reserved content from training datasets, with audit trail.

The GPAI Code of Practice Copyright chapter (final July 10, 2025) translates the statutory text into a set of signatory commitments. Signatories agree to:

• Implement and document a TDM opt-out detection process covering the established machine-readable conventions (robots.txt, meta tags, TDMRep, emerging AI-preferences signals).
• Maintain an internal audit trail of exclusion decisions sufficient to demonstrate compliance on AI Office inquiry.
• Establish a rightsholder engagement channel, typically a published contact for rightsholders to assert opt-outs or raise concerns about specific works.
• Publish high-level transparency about the training-data sources used, consistent with the Article 53(1)(d) public summary.
• Refresh the policy and detection technology on a defined cadence as the machine-readable-opt-out conventions evolve.

For a deployer reviewing an upstream GPAI provider's compliance, the diligence checklist is straightforward: (1) Has the provider published its Article 53(1)(c) copyright policy? (2) Does the policy name the specific TDM-reservation conventions it honors? (3) Does the policy describe the audit trail and refresh cadence? (4) If the provider is a Code signatory, do the Code's Copyright chapter commitments appear consistent with the policy? (5) Is there a public rightsholder engagement channel? Each "yes" reduces the deployer's downstream attestation burden; each "no" or "unclear" elevates it.

Article 53(1)(d) - The Public Training-Content Summary and the AI Office Template

Article 53(1)(d) is the EU's transparency lever on training data. Every GPAI provider, designated or not, signatory or not, must "draw up and make publicly available a sufficiently detailed summary about the content used for training of the general-purpose AI model, according to a template provided by the AI Office." Three operational elements:

• Public availability. Not regulator-only. The summary is published to a public-facing URL the AI Office and any interested party can read.
• Sufficiently detailed. The Commission has signaled that "sufficiently detailed" is more than a one-paragraph statement and less than a full dataset disclosure. The expected level is categories of sources (web crawl, licensed datasets, public-domain corpora, user contributions, synthetic data), languages and language distributions, modalities (text, image, audio, video, code), and order-of-magnitude proportions.
• According to a template. The AI Office publishes the template; providers complete it. The template constrains the format so that summaries across providers can be compared and the AI Office can aggregate the EU-wide training-data landscape.

The AI Office's template (published in iterative drafts through 2025, with the operational version aligned to the Code of Practice transparency commitments) defines the expected schema. The schema typically includes:

• Data categories. Web crawl (with sources, crawl periods, exclusion logic), licensed datasets (with licensors), public-domain corpora, user-generated content, synthetic data, fine-tuning data, evaluation data.
• Languages and modalities. Language distribution (typically by ISO 639 code), modality breakdown (text, image, audio, video, code), and approximate token / item counts per category.
• TDM-reservation handling. Description of the opt-out detection process, the conventions honored, and the order-of-magnitude exclusion rate.
• Special-category data screens. Description of how GDPR Article 9 special categories (health, ethnic origin, political opinion, religious belief, sexual orientation, biometrics, genetics) and AI Act Article 10(5) special categories (sensitive attributes for bias detection) were handled.
• Personal-data handling. Description of the lawful basis for personal-data inclusion (Article 6 GDPR) and the data-subject rights mechanisms (Articles 13-22 GDPR).
• Update cadence. When the summary will be refreshed (typically on each model version release).
• Contact for further information. A published channel for AI Office inquiries, rightsholder concerns, and data-subject requests.

For deployer-side vendor diligence, the Article 53(1)(d) public summary is a high-value receivable. It tells you what categories of data are in the model you depend on, which languages it was trained on (relevant for Article 50 transparency obligations in your downstream applications), and which special-category exposure it carries. If your fine-tune adds substantial domain-specific data, your own Article 53(1)(d) obligation kicks in (when your fine-tune crosses the substantial-modification threshold under Article 25), and your published summary must reference the upstream provider's summary and describe the delta you added.

Deployer-Side - The Data-Sourcing Policy You Have to Write

The L2.Ch6.L2 deliverable is a written data-sourcing policy that governs how your organization collects, retains, and uses data in any AI training, fine-tuning, evaluation, or RAG corpus construction workflow. The policy is the artifact your AI Officer signs and the artifact a Schellman / A-LIGN / BSI / KPMG ISO 42001 auditor will look for under Annex A.7 (data governance). It is also the artifact a notified body will request if your organization seeks Article 43 conformity assessment for any high-risk AI system that depends on internally curated data. A defensible policy includes:

Scope - What the Policy Covers and What It Excludes

The scope section defines the data-collection activities the policy applies to: training of any model (full pre-training, continued pre-training, fine-tuning, reinforcement learning from human feedback, distillation), evaluation dataset construction, RAG / retrieval corpus construction, synthetic-data generation that uses external content as a seed. It defines the exclusions explicitly: production user data (covered by separate GDPR processing policies); first-party customer data with documented contractual rights; public-domain content with provenance certification. The scope section anchors the rest of the policy by drawing a sharp line between governed and ungoverned data flows.

Lawful Basis - GDPR Article 6 and the AI Act Article 10(5) Carve-Out

The lawful-basis section identifies, per data category, which GDPR Article 6 ground supports collection: typically Article 6(1)(b) contract, 6(1)(c) legal obligation, 6(1)(e) public task, or 6(1)(f) legitimate interest. For special-category data under GDPR Article 9, the policy identifies which exception applies. The AI Act Article 10(5) introduces a narrow new processing ground: processing special categories of personal data is permitted "to the extent that it is strictly necessary for the purposes of ensuring bias detection and correction" in high-risk AI systems, subject to enumerated safeguards. The policy describes when Article 10(5) is invoked, what safeguards are applied, and how the activity is documented in the DPIA / FRIA.

TDM Opt-Out Detection - The Article 4(3) Stack Applied Internally

The TDM-opt-out detection section is the heart of the policy for external-content collection. It specifies which signals the organization's crawlers and data-collection workflows honor: robots.txt (with the organization's published user-agents), HTML meta tags (noai / noimageai), X-Robots-Tag headers, TDMRep /.well-known/tdmrep.json, C2PA Training and Mining Assertions for visual media, and emerging IETF AI-preferences signals as they are finalized. It specifies the per-URL audit trail retained and the exclusion-rate reporting (consistent with Article 53(1)(d) if your fine-tune triggers Article 25 transfer). It specifies the rightsholder-engagement channel and the takedown workflow for post-collection assertions.

Special-Category Data Screens - GDPR Article 9 and AI Act Article 10(5)

The special-category section describes the detection and handling of GDPR Article 9 special categories: health, ethnic origin, political opinion, religious belief, sexual orientation, biometrics, genetics, trade-union membership. The policy specifies the detection method (rule-based, classifier-based, or hybrid), the action taken on detection (exclusion by default, with Article 10(5) bias-detection exception narrowly scoped), and the DPIA / FRIA reference that authorizes any retention. The section binds to the GDPR + AI Act intersection covered in the prior lesson (036).

Retention - How Long the Training Data and Audit Trail Are Kept

The retention section specifies the retention period for the training data itself (typically tied to the model's deployed lifetime plus a legal-hold buffer) and the audit-trail retention (typically longer than the data itself, to support post-deployment regulator inquiry). It identifies the deletion / archival workflow and the trigger events that initiate deletion. For high-risk AI systems under Article 6, the retention should accommodate the Article 19 logging obligations (six months minimum) and the Article 26(6) deployer-side log retention.

Audit Trail - Provenance Records the Auditor Will Demand

The audit-trail section specifies, for every dataset in scope, the provenance record retained: source, collection date, collection method, lawful basis, TDM-opt-out check outcome, special-category screen outcome, transformation log, version hash, and ownership. The minimum schema aligns with the Datasheets for Datasets framework (Gebru et al., 2018) and integrates into the CycloneDX 1.7 ML-BoM as data references with provenance attestations. The audit trail is the evidence base for the AI Office on a 53(1)(d) inquiry and for the notified body on Annex IV §2(d) review.

Refresh Cadence - When the Policy Is Reviewed

The refresh-cadence section commits to a review interval (annual minimum, plus event-triggered reviews) and lists the triggers: new GPAI Code of Practice version, AI Office template update, new IETF AI-preferences RFC, new TDMRep specification version, material change in vendor signatory status, new EU or national copyright case law, new substantial-modification fine-tuning workflow. The cadence section is where the policy stays alive against a moving regulatory target.

Article 25(1)(b) - When You Become the Provider of Your Fine-Tune Dataset

Article 25 of the EU AI Act allocates obligations along the value chain. Article 25(1)(b) is the substantial-modification limb: any party that "makes a substantial modification" to a high-risk AI system becomes the provider of that modified system and inherits Article 16 provider obligations. The parallel logic applies to GPAI under Article 53, a substantial fine-tune of a GPAI base model can make the fine-tuner the provider of the fine-tuned model for purposes of Article 53 obligations, including 53(1)(c) copyright policy and 53(1)(d) public training-data summary on the fine-tune dataset.

What is "substantial" depends on the modification's impact on the model's intended purpose, capabilities, and risk profile. A LoRA adapter trained on a few thousand examples to specialize the model for a narrow internal task is typically not substantial; a multi-epoch full fine-tune on a multi-million-example proprietary corpus that materially shifts the model's behavior on benchmark evaluations typically is. The Commission has signaled in its draft guidance that "substantial modification" for GPAI tracks the same logic as for high-risk systems under Article 43(4): a change that affects compliance with the original requirements or modifies the intended purpose.

For a deployer running a substantial fine-tune workflow, the consequences cascade:

• The fine-tuner produces its own Article 53(1)(c) copyright policy covering the fine-tune dataset collection.
• The fine-tuner produces its own Article 53(1)(d) public training-data summary covering the fine-tune dataset (typically as a delta against the upstream provider's summary).
• The fine-tuner produces Annex IV §2(d) detailed training-data documentation for the fine-tune dataset (when the resulting system is a high-risk AI system or the fine-tuned model is GPAI).
• The fine-tuner produces a Datasheet for Datasets (Gebru et al.) covering the fine-tune dataset for ISO 42001 A.7 evidence and notified-body review.
• The fine-tuner integrates the fine-tune dataset provenance into the CycloneDX 1.7 ML-BoM with attestation hashes.

The deployer's data-sourcing policy is what authorizes and constrains this workflow. Without the policy, the fine-tune is undefended; with the policy, the fine-tune is auditable.

U.S. Considerations - Fair Use, Pending Litigation, and the Parallel Track

The U.S. has no equivalent TDM opt-out regime. The closest doctrinal analog is fair use under 17 U.S.C. §107, which permits unauthorized use of copyrighted works for purposes such as criticism, comment, news reporting, teaching, scholarship, or research. The fair-use analysis weighs four factors: purpose and character of the use, nature of the copyrighted work, amount and substantiality of the portion used, and effect on the potential market for the original work. Whether AI training qualifies as fair use is the central question of the 2024-2026 U.S. AI copyright litigation cycle. The leading cases include:

• New York Times v. OpenAI and Microsoft (S.D.N.Y., filed December 2023). The Times alleges direct copying of millions of articles for training and verbatim regeneration via the deployed models. The discovery phase has been extensive and the case is shaping the doctrinal landscape on both fair use and the secondary-liability framework for model deployers.
• Authors Guild v. OpenAI (S.D.N.Y.). A class action brought by individual authors. Consolidated with related actions; the discovery and motion practice have refined the standards for class certification in mass-copyright AI cases.
• Getty Images v. Stability AI (D. Del. and UK High Court). The leading visual-media case; the U.S. and UK proceedings have run in parallel with different doctrinal frameworks.
• Concord Music Group v. Anthropic and other music-publishing class actions, addressing the training of LLMs on song lyrics.
• Kadrey v. Meta (N.D. Cal.). Author class action against Meta over LibGen and similar training corpora.

Through 2025-2026, district-court decisions have begun to draw lines. Some courts have signaled willingness to find AI training transformative for fair-use purposes; others have allowed copyright claims to proceed past the pleading stage where verbatim regeneration is plausibly alleged. The Supreme Court has not yet weighed in on AI fair use, and the doctrinal landscape will remain unsettled into 2027. The U.S. Copyright Office's series of reports on copyright and artificial intelligence (Part 1, 2, 3 published 2025; Part 4 expected 2026) provides agency guidance on the parallel question of whether AI-assisted works are themselves copyrightable, but does not resolve the upstream training-data question.

For an enterprise operating on both sides of the Atlantic, the practical posture is: the EU data-sourcing policy honors Article 4(3) TDM opt-outs because the law requires it; the U.S. data-collection workflow tracks fair-use litigation, applies the most defensible interpretation per use case, and documents the rationale. The policy explicitly distinguishes the two regimes and identifies which workflows are subject to which posture. A single global "no scraping copyrighted content" posture is over-restrictive and operationally unworkable; a single global "fair use everywhere" posture is regulatorily indefensible in the EU. The data-sourcing policy navigates the difference.

Cross-Walks - Where the Data-Sourcing Policy Cites

The data-sourcing policy is multi-framework evidence. The same artifact serves:

• EU Copyright Directive (Directive (EU) 2019/790) Article 4(3), TDM opt-out reservation. The policy's TDM-detection section directly evidences compliance.
• EU AI Act Article 53(1)(c), GPAI copyright policy. If your fine-tune triggers Article 25 transfer, the policy IS the Article 53(1)(c) instrument for your fine-tune.
• EU AI Act Article 53(1)(d), public training-data summary. The policy's data-categorization and audit-trail sections feed the public summary.
• EU AI Act Article 16(d), provider obligations on data quality. The policy's data-governance discipline evidences Article 16(d) compliance.
• EU AI Act Article 11 + Annex IV §2(d), technical documentation including detailed training-data description. The policy is the foundation; Annex IV §2(d) is the consolidated artifact.
• EU AI Act Article 10, data and data-governance practices for high-risk systems. The policy directly answers Article 10(2)(a)-(h) data-governance requirements.
• EU AI Act Article 10(5), special-category-data exception for bias detection. The policy's special-category screens authorize and document any Article 10(5) processing.
• GDPR Article 6, lawful basis. The lawful-basis section of the policy aligns with the organization's GDPR ROPA (Article 30 records of processing activities).
• GDPR Article 9, special-category processing. The special-category section identifies the Article 9 exception relied on.
• GPAI Code of Practice Copyright chapter, operational commitments. The policy aligns with the Code commitments if the upstream provider is a signatory, and where your fine-tune may itself be a Code-relevant activity.
• ISO/IEC 42001:2023 Annex A.7, data governance controls. The policy is the A.7 artifact.
• NIST AI RMF 1.0 Map 4, risks and benefits mapped for all components, including third-party software and data. The policy populates the Map 4 evidence base.
• NIST AI 600-1 Generative AI Profile, Risk 4 (data privacy) and Risk 7 (intellectual property). The policy directly mitigates both risks.
• Datasheets for Datasets (Gebru et al., 2018), dataset documentation schema. The policy's audit-trail schema instantiates the datasheet pattern.
• CycloneDX 1.7 ML-BoM, supply-chain attestation schema for ML components and datasets. The policy's provenance records flow into the ML-BoM.

Write the policy once; cite it across fifteen frameworks. The dual-citation pattern continues to drive evidence efficiency.

Six Common Mistakes in Training-Data Provenance Work

Mistake 1 - Skipping TDM Opt-Out Detection in Internal Data Collection

Many enterprises assume that because they are not training foundation models, the TDM opt-out regime does not apply to them. The opposite is true: any organization that scrapes web content to construct a fine-tune corpus, evaluation set, or RAG retrieval index is engaged in text-and-data mining subject to Article 4(3). The data-sourcing policy must impose the same robots.txt / meta-tag / TDMRep / AI-preferences discipline on internal collection workflows that the policy expects of upstream GPAI providers. Skipping internal TDM-detection is the most common audit finding in 2026.

Mistake 2 - Treating Training-Data Documentation as Vendor-Only Responsibility

"That's the provider's problem" is the default deployer posture, and it is wrong for two reasons. First, under Article 25(1)(b), substantial fine-tuning makes you a provider for the fine-tuned model. Second, even where you remain solely a deployer, your downstream Annex IV technical-file work for any high-risk system that depends on internally curated data (RAG corpus, evaluation set, prompt library) requires its own data-governance documentation under Article 10. The policy is yours regardless.

Mistake 3 - Missing the Article 53(1)(d) Public Summary in Vendor Diligence

Many procurement checklists capture the GPAI Code of Practice signatory question and the Annex XII receivable question but skip the Article 53(1)(d) public training-data summary. The summary is a public artifact (or should be) and contains the data-category, language, modality, and special-category information you need to assess downstream risk. Failing to review the summary leaves the audit committee unable to answer "what kinds of content trained the model we depend on?"

Mistake 4 - Weak Provenance Documentation on Internally Curated Fine-Tune Datasets

Fine-tune datasets are often assembled hurriedly by ML engineering teams without rigorous provenance capture. The result is a dataset that powers a deployed model but has no datasheet, no lawful-basis record, no TDM-opt-out audit, no special-category screen, and no version hash. When the AI Office, a notified body, or a downstream auditor asks "where did this data come from?" the engineering team's answer is a Google Doc and a Slack thread. The data-sourcing policy mandates the schema; the engineering pipeline implements it; the artifact survives.

Mistake 5 - No Refresh on GPAI Code of Practice and AI Office Template Updates

The Code of Practice is a living document. The AI Office template will iterate as machine-readable opt-out conventions mature and as cross-provider summary practice converges. An enterprise policy frozen on the May 2026 version of the Code and template will drift out of alignment within twelve months. The refresh-cadence section of the policy is what keeps the artifact current; without it, the policy ages out and the regulatory posture quietly erodes.

Mistake 6 - Missing U.S. Litigation Tracking in the Parallel Track

The U.S. fair-use litigation will produce doctrine-changing decisions through 2026 and 2027. Enterprises that track the EU Article 4(3) regime but do not maintain a U.S. litigation tracker will be surprised by district-court decisions that materially affect their U.S. data-collection posture. The data-sourcing policy's U.S. section should commit to quarterly review of the pending dockets (NYT v. OpenAI, Authors Guild v. OpenAI, Getty v. Stability, Concord v. Anthropic, Kadrey v. Meta, U.S. Copyright Office reports) and adjust the U.S. workflow as decisions land.

Key Takeaways

• Training-data provenance is a first-class compliance object. Article 53(1)(c) requires every GPAI provider to maintain a copyright policy honoring Copyright Directive Article 4(3) TDM opt-outs. Article 53(1)(d) requires a publicly available training-content summary per AI Office template. Both apply regardless of GPAI Code of Practice signatory status.
• The TDM opt-out is a machine-readable stack. robots.txt + meta tags (noai / noimageai) + X-Robots-Tag + TDMRep /.well-known/tdmrep.json + emerging IETF AI-preferences signals + C2PA Training and Mining Assertions for visual media. A defensible provider honors the entire stack.
• The GPAI Code of Practice Copyright chapter operationalizes Article 53(1)(c). Signatories commit to detection, audit trail, rightsholder engagement, high-level transparency, and refresh cadence. Non-signatory providers owe the same statutory obligation without the presumption.
• Article 53(1)(d) public summary is a vendor-diligence receivable. Categories of sources, languages, modalities, special-category screens, contact for further information. Review it on procurement and on every model version update.
• Article 25(1)(b) substantial fine-tuning makes the deployer a provider of the fine-tuned model. The deployer then owes its own Article 53(1)(c) policy and 53(1)(d) summary on the fine-tune dataset, plus Annex IV §2(d) technical documentation, datasheet, and ML-BoM provenance.
• The data-sourcing policy is the L2 deliverable. Scope, lawful basis, TDM-opt-out detection, special-category screens (GDPR Article 9 + AI Act Article 10(5)), retention, audit trail, refresh cadence. The AI Officer signs it; the ISO 42001 A.7 auditor reads it; the notified body cites it.
• The U.S. is on a parallel track. No equivalent TDM opt-out; fair-use doctrine actively litigated through NYT v. OpenAI, Authors Guild v. OpenAI, Getty v. Stability, Concord v. Anthropic, Kadrey v. Meta. The policy maintains an EU posture and a U.S. posture explicitly, with a quarterly litigation review.
• Six mistakes to avoid. Skipping internal TDM-opt-out detection. Treating training-data documentation as vendor-only. Missing the Article 53(1)(d) public summary in vendor diligence. Weak fine-tune provenance documentation. No refresh on Code of Practice and template updates. Missing U.S. litigation tracking.
• The policy is multi-framework evidence. EU Copyright Directive Article 4(3); EU AI Act Articles 10, 11, 16(d), 25(1)(b), 53(1)(c), 53(1)(d); GDPR Articles 6 and 9; GPAI Code of Practice Copyright chapter; ISO 42001 A.7; NIST AI RMF Map 4; NIST AI 600-1 Risks 4 and 7; Datasheets for Datasets; CycloneDX 1.7 ML-BoM. Write once, cite fifteen times.
• Internal data collection is in scope. Scraping for fine-tune corpora, evaluation sets, RAG retrieval indexes is text-and-data mining subject to Article 4(3). Apply the same opt-out discipline you expect of upstream providers.