What Article 53(1)(c) asks of a general-purpose AI model provider
If you place a general-purpose AI model on the EU market, you must have a written copyright policy in place before you do so. The policy has to make you comply with Union copyright and related rights law, and it has to identify and respect reservations of rights, the machine-readable opt-outs that rightsholders express under Article 4(3) of Directive (EU) 2019/790. The text of Article 53(1)(c) also expects you to use state-of-the-art technologies to do this. In practice, that means the policy must describe how your crawling and data collection find opt-outs, how you honor them, and who decides what happens when a rightsholder objects. Your legal team owns the policy, while engineering owns the technical means of acting on it. Neither can delegate the accountability to a vendor.
The difficulty is that opt-outs do not arrive in one format. Rightsholders express reservations through site-level signals, robots directives, terms of use, metadata and other machine-readable or natural-language notices, and they appear across millions of domains that change over time. Training data also often arrives through third-party datasets, where the original source and its opt-out status are poorly recorded. Ask your data team to confirm, for each corpus, where the source URL and collection date are stored, whether the collection pipeline logged the reservation checks it applied, and how an opt-out received after training is handled. Without these records, you cannot show an assessor how the policy works on real data.
The open-source exemption does not apply here. Article 53(2) exempts open-source providers only from the documentation duties in points (a) and (b), so an open-source model provider still needs a copyright policy and must be able to show it works. The Commission says the copyright chapter of the General-Purpose AI Code of Practice gives all providers practical ways to meet this duty, and you can read it at the General-Purpose AI Code of Practice page. If you do not adhere to the code or a harmonised standard, Article 53(4) requires you to demonstrate alternative adequate means of compliance to the Commission, so plan the evidence from the start.
Which models, teams and data sources fall under the copyright policy duty
Article 53(1)(c) applies to every general-purpose AI model provider placing a model on the EU market, so the first job is deciding which models, teams and data flows count. The cards below cover the scoping choices that change how much work the policy requires and which third parties its processes must reach.
Open source and closed models alike
The open-source exemption in Article 53(2) covers only the documentation duties in points (a) and (b). It does not cover the copyright policy in point (c), so a model released under an open licence still needs a written policy for complying with EU copyright law and honoring text and data mining opt-outs. Confirm this with counsel before assuming a licence changes your obligations. Check that the policy addresses how the model was trained, not only how it is distributed.
Non-EU providers placing models on the EU market
Article 2 applies the Act to providers placing general-purpose AI models on the EU market wherever they are established. A provider in another country that makes a model available to EU customers should treat Article 53(1)(c) as in scope, even if training happened outside the Union. Ask who decides when a model is placed on the market, since that decision, not the location of the servers, usually sets the obligation.
Models built or fine-tuned downstream
A team that fine-tunes or adapts a model may become the provider of a new general-purpose model, or may only be a downstream integrator. The answer depends on the Commission's thresholds for who counts as a provider, which the sibling Article 53(1)(a) and (b) guidance covers. Record which party trained the base model, which party changed it, and which copyright policy each party relies on, so no training step falls outside a documented policy.
Web crawls and opt-out signals
Web crawls are the data source most likely to contain material subject to reservations of rights under Article 4(3) of Directive (EU) 2019/790. The policy must say how crawlers identify and honor machine-readable opt-outs, how robots and similar signals are read, and what happens when a rights holder objects after collection. Ask each crawler operator to document the signals it respects and the dates it changes its rules.
Licensed datasets and their terms
Licensed datasets bring their own usage limits, territorial scope and expiry dates, which may not match the training plan. The policy should require a register of each licence, the rights it grants for training, and any rights reserved by the licensor. Confirm whether the licence permits use for model training in the EU, and whether the licensor has made its own opt-out reservations for the content.
User uploads and synthetic data
User uploads and synthetic data are easy to overlook because they do not arrive through a crawl or a purchase. Uploads need terms that grant the right to train, a way to honor later withdrawals, and a record of which items entered each training run. Synthetic data inherits the rights status of the material used to generate it, so the policy should trace each synthetic set back to its source. Include data vendors, crawl providers and model hosts in the same review, because their processes sit inside your compliance chain.
How an assessor tests the copyright policy
This table compares each element an assessor is likely to check under Article 53(1)(c), from the written policy to the alternative-means route. Read each row as a test question, the evidence to prepare, and the gaps that tend to surface. The main takeaway is that a policy document alone rarely passes; the assessor will look for records showing that opt-outs were applied to real crawling and dataset work.
| Element tested | Evidence requested | Common findings |
|---|---|---|
| Written copyright policy | Versioned policy naming the owner, approval date, scope of models covered and the EU copyright rules it addresses | Generic text copied from general privacy or AI policies, with no named owner or model scope |
| Identification of reservations of rights | Documented method for detecting machine-readable opt-outs, the sources checked, and the tools or standards used to read them | Method described in general terms only, with no list of sources checked or no test showing detection works |
| Honoring opt-outs during crawling | Crawler configuration, robots and exclusion rule handling logs, and records of blocked domains or paths | Opt-out logic exists in a design document but the crawler configuration does not reflect it |
| Opt-outs applied to dataset assembly | Exclusion lists tied to dataset versions, and a record of which sources were removed before training | No record of which sources were excluded, so the provider cannot show that opt-outs reached the training data |
| Handling of third-party and licensed content | Source register with licence terms, provenance notes and the decision path for each category | Licensed or scraped sources mixed together with no provenance field |
| Ongoing monitoring over time | Review schedule, change logs for policy and crawler rules, and records of re-checks on previously collected sources | Reviews happen only at launch, so later opt-out changes are never picked up |
| Adequacy of alternative means (Article 53(4)) | Gap analysis against the code of practice copyright chapter and evidence that the chosen approach reaches the same outcome | Provider not adhering to the code offers no comparable evidence, or relies on assertion rather than demonstration |
How to build a copyright policy that stands up to review
The sequence below turns Article 53(1)(c) into a documented, owned and reviewable policy that shows how training data is sourced, how reservations of rights are honored, and how the policy stays current. Each step ends with an artifact an assessor or the AI Office can inspect.
Assign an accountable owner
Name one senior person who is accountable for the copyright policy, with a deputy who can act when the owner is unavailable. Give the owner written authority over training data acquisition, crawling decisions and escalation to legal counsel, and confirm that engineering, data and legal teams know who holds that authority. The step closes when a signed role description and a reporting line exist in the governance records.
Map every training data source
Build an inventory of every dataset, web crawl, licensed corpus, user-contributed source and synthetic data source used to train, fine-tune or evaluate the model. For each entry, record the acquisition route, the date obtained, the licence or legal basis relied on, the crawler or vendor involved and the person who approved it. The step closes when the inventory is complete, reviewed by legal counsel and linked to the training runs that used each source.
Define how reservations are identified
Document the technical methods used to detect machine-readable reservations of rights under Article 4(3) of Directive (EU) 2019/790, such as robots.txt directives, metadata signals and other standardized protocols your crawlers are configured to read. Ask your crawler and data vendors which signals they honor, and record any signals you cannot read so they can be handled in the next step. The step closes when a written detection standard exists and each crawler configuration references it.
Honor opt-outs in the pipeline
Specify how detected reservations are applied before data enters training, including exclusion rules, filter logs and the point at which excluded content is removed from the dataset. Test the filters on a sample of sources and keep the results, since an assessor will ask whether a reserved source could have reached training. The step closes when filter configuration, test results and a log of excluded items are retained and can be reproduced.
Decide how to handle disputed opt-outs
Set a documented procedure for unclear, conflicting or late reservations, including who decides, what evidence is needed, when content is excluded while the question is open and how the decision is recorded. Include a channel for rightsholders to raise objections and a rule for how past training is reviewed when a reservation is found after a model was trained. The step closes when the escalation procedure is approved, tested on at least one scenario and linked to the inventory.
Set the review and update cadence
Define how often the policy, the source inventory and the detection standard are reviewed, and which events force an earlier review, such as a new crawler, a new data licence, a change in EU copyright case law or a new version of the General-Purpose AI Code of Practice. Confirm the cadence with legal counsel and record the reason for each review. The step closes when a review calendar and a change log for the policy are in place.
Document and approve the policy
Write the policy as a single controlled document that covers scope, roles, the source inventory method, detection and exclusion rules, the dispute procedure and the review cadence, then obtain sign-off from the accountable owner and senior management. Keep every version under version control so you can show what changed and who approved it. The step closes when the approved policy, its approval record and the version history can be produced for an assessor or the AI Office.
Evidence that shows the policy is in force
Article 53(1)(c) asks for a policy that is actually followed, so the evidence has to show a written policy, the decisions behind each dataset, and the checks that opt-outs were honored. The cards below connect the policy text to the training data it governs, and each one should be refreshed whenever a dataset or model version changes.
Approved copyright policy and version history
This is the written policy itself, approved by a named owner and kept under version control so every change records what changed, when and by whom. It shows the duty to comply with Union copyright and related rights law and to identify reservations of rights under Article 4(3) of Directive (EU) 2019/790 is a standing commitment, not a one-off document. Check that each approved version is retained and that the version in force on the date of each training run can be identified.
Source acquisition and exclusion records
These records show how each data source was obtained, under what terms, and whether it was excluded because a rights holder reserved its rights. An assessor will look for a clear reason on file for every excluded source and for every source kept. Keep the acquisition date, the licence or access basis and the exclusion decision together, so the record can be traced to a specific training run.
Opt-out compliance logs per dataset version
The core proof of honored opt-outs is a log showing the reservation checks applied to each dataset version before training. It should record which sources were checked, the method used, what was found and what was removed or excluded. Because state-of-the-art technologies are referenced in the obligation, document the tool and its version, and confirm with your own engineers how the check handles content that carries a reservation in machine-readable form.
Training data manifests
A manifest lists every dataset and source in a given training run, with identifiers, sizes and a link to the acquisition and exclusion records. It lets an assessor reconcile what the model was trained on with what the policy says was permitted. Generate the manifest from the pipeline at training time, not by hand afterward, and store it with the model version it produced.
Review and approval records
These show that someone independent of the training team reviewed the policy, the exclusion decisions and the opt-out results before a model was released. Record the reviewer, the date, the scope reviewed and any findings with their resolution. Reviews should repeat on a schedule and whenever a new data source, a new model version or a material change in the copyright rules is introduced.
Responsible owner records
Assessors expect a named owner accountable for the copyright policy, with a documented scope of authority and evidence that the owner acts on the logs and reviews. Keep the appointment, the owner's sign-off on each release and a log of the questions or rights holder complaints they handled. Confirm that the role has a deputy so the records stay current when the owner is unavailable.
How self-hosted tools keep the copyright evidence current
The copyright policy itself needs to be kept under control from its first draft onward, because Article 53(1)(c) is judged on the policy in force, not on a version someone remembers approving. XWiki can hold the policy as a page where every change is kept under version control, recording what changed, when and by whom. Reviewers can compare any two versions, and an earlier version can be restored if a later edit introduced an error. Before relying on this, confirm in your own deployment how page history is retained, whether it can be exported with its metadata, and how long older revisions survive if someone purges them. Those answers are what an assessor will ask about when they want to see what the policy said on a given date.
Approval rights over the policy need the same discipline. BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. In practice, the copyright policy can sit in a restricted book where only the legal and compliance roles can edit or publish, while engineering and data teams hold read access. Map each role to a named owner, check the effective permissions for that page as a test user, and record who approved each published version. Confirm with the vendor how role and permission changes are logged and whether those logs can be exported separately from page content.
The policy document is the easy part. The evidence that the policy works sits in other records: the log of reservations of rights your crawlers honored, the list of excluded sources, and the training manifests showing which content entered each model. Those need their own systems and retention rules. Tools such as garak and Langfuse produce test and trace records, but they do not record copyright exclusions or training provenance on their own, so decide which system owns each record before the first model is trained. Ask your implementation partner to document where each record lives, how long it is kept, and how it is tied back to the policy version it supported.
What meeting Article 53(1)(c) costs in money and effort
This table compares each cost component of a copyright policy for a general-purpose AI model, who is paid for it, whether it recurs, and what pushes it up or down. Use it to structure a written quote, since no fee or duration is supplied for this obligation. The main takeaway is that most of the cost scales with the number of data sources and model versions, not with the policy document itself.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Legal review of the copyright policy | One-time drafting, then recurring review | Number of jurisdictions where the model is placed, changes in EU copyright case law, and the number of internal policy owners | Reuse a single policy with named owners, and ask counsel to scope a review cycle tied to new model releases |
| Engineering time for opt-out detection | One-time build, then recurring maintenance | Number of data sources, volume of crawled content, and the number of distinct machine-readable opt-out signals a provider must honor | Limit crawling to sources with documented rights status, and confirm which opt-out protocols the team will support before build starts |
| Engineering time for dataset filtering | Recurring with each training run | Number of model versions, size of each training corpus, and how often data is refreshed | Record filter decisions per dataset so later versions reuse the same pipeline rather than rebuilding it |
| Tooling and licence spend | Recurring subscriptions or hosting | Commercial crawler, rights-database or content-verification services, and the scale of hosted compute | Self-hosted open-source components can remove licence spend on version control and logging, though hosting and staff time still apply |
| Evidence upkeep | Recurring | Number of model versions, frequency of dataset changes, and how many records must be retained per training run | Keep policy, decisions and filter logs in one version-controlled system with defined retention rules |
| External review of the policy | Optional, usually per review cycle | Scope of the policy, the need for a third-party opinion, and whether the provider adheres to the Code of Practice | Ask for a fixed-scope review limited to the copyright chapter and the evidence pack |
| Assessor or Commission review time | Recurring when requested | Whether the provider follows an approved code of practice, or must show alternative adequate means under Article 53(4) | Prepare the alternative means file in advance so the review is a walkthrough, not a rebuild |
Who owns the policy, who prepares the evidence and who assesses it
Your organization owns the copyright policy itself. That includes the legal position on which EU copyright and related rights rules apply to your training activities, how you read reservations of rights, and which data sources you admit or exclude. These decisions carry legal and commercial risk, so they belong with counsel, the model owners and an accountable executive. An outside partner can support the work, but it cannot make these calls for you.
- Policy ownership: an accountable owner signs the copyright policy and approves changes to it.
- Legal position: counsel documents how rights reservations are interpreted and what the organization will do when a rights holder objects.
- Data source decisions: the team approves or rejects sources, datasets and crawling scopes before training begins.
- Exception handling: someone internal decides how disputed content is removed, retrained or excluded.
- Independence line: the policy must reflect your own judgment, so no external party should be the sole author of it.
Check that the policy names an owner, a review cadence and a record of every legal decision on rights.
An implementation partner typically prepares the technical side. Work of this kind includes building data pipelines that apply opt-out signals, maintaining exclusion records, configuring logging and collecting evidence in a form an assessor can read. DeployOpen works this way: it plans, builds and documents these systems inside your own infrastructure, and most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Opt-out handling pipelines: engineering that reads machine-readable reservations of rights and applies them during data collection.
- Exclusion records: versioned lists of excluded sources and the reason each one was excluded.
- Logging and traceability: configured audit trails that show what was collected, when and under which policy version.
- Evidence packs: documentation and exports that map each system to the policy statements it supports.
- Independence line: the partner prepares systems and evidence but does not decide the legal position, and it does not issue reports or attestations.
Confirm that the statement of work lists each deliverable, the systems in scope and who keeps the evidence after handover.
An independent auditor, assessor or other competent authority tests whether the policy and its supporting evidence hold up. Under Article 53(4), a provider that does not adhere to an approved code of practice or a harmonised standard must demonstrate alternative adequate means of compliance for assessment by the Commission. Only an independent party issues findings, reports or certificates. DeployOpen does not issue audit reports, attestations or certifications.
- Independent testing: the assessor samples exclusion records, pipeline logs and policy versions against the stated commitments.
- Reports and findings: any written conclusion comes from the assessor, not from the partner that built the controls.
- Scope agreement: the assessor confirms what it will test, the period covered and the evidence it needs.
- Conflict control: the assessor should not be the party that designed the controls it tests.
- Independence line: a partner's evidence is an input to the assessment, never a substitute for it.
Ask the assessor which evidence it accepts, how it samples records and whether it expects the Commission route under Article 53(4).
Where copyright policies usually fall short and how to close each gap
Most copyright policies under Article 53(1)(c) fail in predictable ways: they describe the law instead of the operation, and they are not kept current. The six gaps below share one root cause, which is that the policy is not tied to records that show what the organization actually did. Each fix turns a statement into something an assessor can test.
Policy restates the law
A policy that repeats the text of Article 53(1)(c) and Directive (EU) 2019/790 says what the provider intends, not how it acts. Assessors look for the operational steps: which sources are collected, who decides what is used, and how reservations are handled at each stage. Fix it by writing the policy as a description of your pipeline, from data sourcing through filtering and exclusion, with a named step for each duty. Check that someone outside the drafting team can trace each sentence to a system or role.
No record of reservations found
Many providers can say they honor opt-outs but cannot show which reservations they found, where, and what they did with each one. Without a log, the policy is a claim with no evidence behind it. Fix it by recording, for each source, the reservation signal detected, the date checked, the action taken and the reviewer. Keep these records with the training data inventory so an assessor can sample a source and follow it through.
Opt-outs checked once
Reservations of rights can change after a first crawl, so a check made at collection time may be stale by the time the model is trained or updated. Providers that scan a source once and never again cannot show that later reservations were respected. Fix it by setting a re-check schedule tied to each training run and to any re-crawl, and by keeping the timestamp of each check. Confirm with counsel which signals your pipeline must read and how far back a reservation applies.
No owner for disputed cases
Rights holders will contest use, and a policy with no named decision-maker stalls every dispute. Engineering may hold the data, but only a defined role should decide whether content is excluded, retained or escalated. Fix it by naming an accountable owner, a deputy, and an escalation path to legal counsel, with a written procedure for removal requests and a record of each decision. Confirm that the owner has authority to stop an ingestion job.
Policy not versioned or dated
A policy that is edited in place cannot show what applied when a given model was trained. Assessors will ask for the version in force at each training date, and undated edits weaken the record. Fix it by storing the policy in a controlled document system that keeps every revision with its author, date and changes, and that lets you compare and restore earlier versions. Tie each model release to the policy version it used.
Code of practice cited without alternatives
Citing the General-Purpose AI Code of Practice is a valid route, but a provider that does not adhere to an approved code or a harmonised standard must show alternative adequate means of compliance for Commission assessment under Article 53(4). Organizations that rely on the code without documenting how their own measures meet the same objectives have no fallback. Fix it by mapping the copyright chapter's measures to your controls, recording where you follow it, and documenting the equivalent means you use where you do not.
Questions buyers ask about Article 53(1)(c) before hiring help
How much effort does a copyright policy under Article 53(1)(c) take, and what does it need from our team?
The policy itself is a document, but the effort sits in the work behind it: deciding how training data is sourced, how rights reservations are checked, and who signs off on exceptions. Most of the effort falls on legal or compliance counsel, the engineers who run data collection and training pipelines, and the people who own model releases. Engineers need to explain where each data source came from and what filtering was applied. Counsel needs to set the position on Union copyright and related rights law. Effort grows with the number and variety of data sources, and with how much of the crawl or licensed material passes through automated pipelines. Ask any partner to show which team members and decisions the policy depends on before work starts.
Do open-source model providers really need a copyright policy under the AI Act?
Yes. The open-source exemption in Article 53(2) covers only the documentation duties in points (a) and (b) of Article 53(1). The copyright policy duty in point (c) still applies to open-source model providers. Being open source changes what you must publish, not whether you need a policy. Teams releasing open weights often assume the exemption covers the whole chapter, so confirm the exact scope with counsel and check whether your release is classed as a provider placing a model on the EU market.
What should we ask a consultant to include in a quote for this work?
Ask for a written scope that names each deliverable, such as the copyright policy document, the list of data sources it covers, the process for identifying reservations of rights, and the evidence records the process produces. Ask who writes the policy, who reviews the legal position and who signs off. Confirm whether the quote covers technical work on opt-out detection, such as crawler configuration or logging, and whether it includes updates when the model or data pipeline changes. Ask what is one-time and what recurs, and what the engagement excludes. Fixed-scope quotes make these boundaries easier to compare across bidders.
Can an implementation partner make our copyright policy legally sufficient?
A partner can help prepare the systems, records and written process that the policy describes, but legal sufficiency is a legal judgment. Advice on what Union copyright and related rights law requires, how Article 4(3) of Directive (EU) 2019/790 applies to your sources, and whether the policy is adequate must come from qualified counsel. An implementation partner's role is to build and document the technical process, such as recording data sources, applying rights reservation checks and keeping logs. Ask counsel to review the final text, and make sure your contract states which party is responsible for each part.
How long does the copyright policy work take, and what drives the timeline?
The timeline depends mainly on how many training data sources you use, how well they are documented today, and how much of the opt-out process must be built rather than described. Teams with clear data provenance records usually move faster than teams reconstructing where past training data came from. Legal review cycles, internal approvals and any changes to crawling or filtering tools also extend the schedule. Agree on milestones in writing, and ask the partner which steps depend on your team's availability. Confirm your own deadlines against the dates in the AI Act, since these affect when the obligations apply to your models.
Does following the General-Purpose AI Code of Practice remove the need for our own copyright policy?
No. The Commission says the copyright chapter of the General-Purpose AI Code of Practice offers practical ways for providers to meet the Article 53(1)(c) obligation, but it does not replace the duty to adopt a policy. Providers that adhere to an approved code of practice can use it to show compliance. Providers that do not adhere must demonstrate alternative adequate means of compliance for assessment by the Commission under Article 53(4). In both cases, you should be able to show your own policy and the process behind it. Check the current status of the code and your adherence with counsel.
What evidence should we keep to show our copyright policy is working?
Keep records that connect each training data source to its origin, licence or basis, the rights reservation checks applied, and the decisions made when a reservation was found. Version control of the policy and its procedures shows what changed, when and by whom, and tools such as XWiki keep page history in that form. Access controls on the policy pages, for example role-based permissions in BookStack, show who could edit or approve it. Logs from data pipelines and evaluation runs add technical evidence. Confirm with counsel which records they need for their assessment.
How DeployOpen scopes and prepares copyright policy evidence
DeployOpen helps organizations prepare the systems, documentation and evidence that support a copyright policy for Article 53(1)(c), working inside the client's own infrastructure. The organization owns the policy and its decisions, and an independent auditor or assessor, not DeployOpen, forms any conclusion on compliance.
How we scope
- The written scope names the models, repositories, data pipelines and internal wiki spaces that the copyright policy covers.
- Scope lists which rights-reservation sources the organization will check, and how those checks are recorded in the policy.
- Engagements are fixed-scope, and ongoing support for policy upkeep is available as a retainer.
How we build
- We set up a version-controlled wiki space for the copyright policy, its revision history and approval records.
- We configure role-based access so policy owners can edit while reviewers and auditors can read and compare versions.
- We test that training-data exclusion logs and opt-out handling are captured in tooling the client operates and can export.
How we hand over
- Deliverables include the written policy, a control-to-evidence map, role assignments and the configuration records behind them.
- We document how each rights-reservation check is performed, who performs it, and where its outputs are stored.
- The client receives runbooks so its own staff can maintain the policy, evidence and tooling after the engagement ends.
How we support
- Retainers cover policy updates when the code of practice, EU copyright guidance or the model changes.
- We can schedule periodic reviews of evidence completeness ahead of a regulator request or an independent assessment.
- Confirm with your legal counsel which copyright positions the policy must state before scoping begins.

