You publish work online and you put a reservation on it. Maybe that's a line in robots.txt, maybe a TDM Reservation Protocol file, maybe a sentence in your terms of use. Months later a model ships, and you have no way of knowing whether your material is inside it. The useful question is what the law actually does about that. Since 2 August 2025 the answer is more than many rightsholders expect in one direction, and less than they hope in another.
What Article 53(1)(c) puts on the model provider
Under Article 53(1)(c) of the EU AI Act, a provider of a general-purpose AI model has to put in place a policy to comply with Union copyright law. The provision names one thing specifically: identifying and complying with a reservation of rights expressed under Article 4(3) of the DSM Directive (EU) 2019/790. Obligations for GPAI providers have applied since 2 August 2025.
The verbs are worth reading slowly. Identify, then comply. The GPAI text data mining opt-out obligation sits with the provider, not with you. They're the ones who have to go looking for a reservation before they mine, and they're the ones who have to respect it once they find it. You don't have to notify them, chase them, or file anything with them for that duty to exist.
What a reservation has to look like to count
Article 4 of the DSM Directive is the commercial text and data mining exception. It allows mining of lawfully accessible works unless the rightsholder has reserved the right to prevent it. Article 4(3) is where that reservation lives, and it carries one condition that decides most arguments: for content made publicly available online, the reservation has to be expressed in a machine-readable way.
Machine-readable means a crawler can parse it without a person interpreting it. Robots.txt directives, the TDM Reservation Protocol, and rights metadata attached to the file itself all fit that description. A paragraph in your terms of use, written for a human to read, does not.
That distinction has already been tested. The Higher Regional Court of Hamburg, in its judgment of 10 December 2025 in case 5 U 104/24 (Kneschke v. LAION), held a reservation ineffective because it was expressed only in human-readable general terms of use rather than in a machine-readable format. A further appeal to the Bundesgerichtshof was expressly allowed, so the question is not closed. That judgment is covered on its own elsewhere on this blog. The short version here is that the format of a reservation carries as much weight as the fact you made one.
The duty runs against them, not for you
This is where the asymmetry starts to matter. Article 53(1)(c) is a compliance obligation placed on model providers, enforceable against them by the authorities set up to supervise them. Its existence is good news for rightsholders.
What it isn't is evidence of anything you own. A duty on someone else to look for your reservation tells nobody:
- What you actually created, as opposed to what sits on the page today
- The form the work was in at a given moment, before edits, later versions and re-uploads
- The date it existed in that form
- Whether any of that can be shown without relying on the platform that happens to host it
What a concrete dispute asks you
The moment a disagreement stops being abstract, the questions turn around. You stop asking whether a provider met a duty and start being asked to establish your own position. The questions put to you are the ordinary ones: what is the work, what form was it in, from what date, and how do you show that independently of your own systems.
Most publishers and dataset teams answer the last one with a CMS entry, a Git history, or a cloud storage timestamp. Those records are useful internally, but they sit inside infrastructure you control, so the date rests on the trustworthiness of that infrastructure rather than on something a third party can check on its own. A counterparty who wants to contest the date has an obvious line to take.
Two records, two different jobs
| Question in dispute | Machine-readable reservation | Dated record of the work |
|---|---|---|
| May a GPAI provider mine this content for commercial training | This is exactly what it addresses | Not what it does |
| Does the provider have to go looking before mining | Yes, under Article 53(1)(c), applying since 2 August 2025 | Not applicable |
| What is the work and what form was it in | Nothing, a reservation is not the work | This is what the record fixes |
| On what date did it exist in that form | Only the date the reservation itself was published | Fixed by a qualified timestamp at sealing |
| Can a third party check it without your systems | Depends on what your site served that day | Verifiable independently of where the file is stored |
What's worth putting in place now
- Express the reservation in a machine-readable form, not only in your terms of use. Robots.txt, the TDM Reservation Protocol, and embedded rights metadata are the formats currently in use.
- Separately, create a dated, tamper-evident record of each work at the point it is finished, before it goes anywhere public.
- If you want the regulatory background in one place first, our EU AI Act overview sets out how the obligations are sequenced.
Swiss Trust Layer covers the second item on that list: a qualified electronic seal and timestamp applied to a file, so the content and the date can be verified by anyone, without access to your CMS or your storage. It says nothing about whether a model provider met its own obligation, and that's the point.
The AI Act put a real obligation on model providers, and it is theirs to meet. What it did not do, and could not have done, is answer the question that gets asked of you: what did you make, and when.
