Art. 4 Directive 2019/790: Why Your TDM Process Needs an Audit Trail, Not Just a Legal Opinion

Most teams doing Text and Data Mining have read Art. 4 of Directive (EU) 2019/790 at least once. A few have had legal counsel confirm that yes, what they do qualifies as TDM. And then they move on, assuming the matter is settled.

It is not settled. A legal opinion is a starting point, not a shield. The question is not only whether your activity fits within the TDM exception — the question is whether you can demonstrate it, step by step, if challenged. That is a documentation problem, not a legal one. And most TDM operations are not ready for it.

This post is not about explaining what Art. 4 says. It is about what you need to have built before the exception protects you in practice.

The gap between the right and its exercise

Art. 4 of Directive 2019/790 establishes a mandatory copyright exception for TDM carried out for any purpose, not just scientific research. It covers reproductions and extractions made lawfully, on content that you have legitimate access to. Retention of processed copies is allowed as long as it serves the purpose of the mining.

On paper, this is broad and functional. In practice, the exception only holds if you can account for each element it requires:

• Lawful access: you accessed the sources through public means, without circumventing any technical measure.
• TDM purpose: the reproduction or extraction happened to enable analysis, not to redistribute content.
• Retention justified by purpose: stored copies exist because the analysis requires it, not as a by-product of convenience.

Rightsholders who dispute a TDM operation will target the weakest link in that chain. If you have no record of how access was established, the first element collapses. If your pipeline retains full-text content beyond what your analysis requires, the third element is contested.

What an audit trail for TDM actually looks like

An audit trail for TDM is not a PDF from legal. It is a technical and procedural record that maps your pipeline against the requirements of the exception. It should cover at minimum:

1. Source access logs Every source you process should have a documented access method. Was it an open public URL, a feed, a licensed API? What technical conditions governed access? If a rightsholder claims you bypassed restrictions, your logs either confirm or deny it. Without logs, you have no argument.

2. Processing records What happened to the content after access? Was it transformed into structured signals? Was full text retained or discarded after extraction? The further your stored output is from the original content, the stronger your TDM position. Document the transformation steps.

3. Retention policy with documented rationale How long do you keep what, and why? Art. 4 allows retention to the extent justified by the TDM purpose. That means you need a written policy that ties retention periods to specific analytical functions. "We keep it until the project ends" is not a policy. "We retain derived signals for 18 months to enable longitudinal trend analysis, and discard source reproductions after processing" is closer to defensible.

4. Scope definition TDM conducted for a purpose that cannot be articulated is TDM that cannot be defended. What was the analytical objective? What sources were in scope? What was out of scope and why? These are questions that an audit, a dispute, or a data protection review will ask.

Why public sources are not automatically safe

There is a persistent misconception that processing publicly accessible content is inherently unproblematic under Art. 4. Publicly accessible does not mean unrestricted. A source can be publicly visible and still have terms of service that restrict automated processing, or technical measures that signal a reservation of rights.

Art. 4(3) explicitly allows rightsholders to reserve their rights using machine-readable means. If a source has signalled such a reservation and you processed it anyway, you are outside the exception — regardless of whether the content was publicly visible. This is not a theoretical risk. As reservation mechanisms become more standardised, the distinction between "public" and "unrestricted" will be tested more frequently.

The implication is operational: your source selection process needs to include a rights-reservation check, and that check needs to be logged. If you cannot show that you verified the reservation status of a source before processing, you cannot show that access was lawful.

Derived signals are not the same as retained content

One of the most practical decisions a TDM operation can make is to build pipelines that output derived signals rather than storing reproductions of source content. A derived signal — a sentiment score, an entity tag, a relevance classification, a trend indicator — is not a reproduction in the copyright sense. It is an analytical output that happens to have been generated from content you processed.

This distinction matters legally and operationally. Legally, it removes the retention question from the dispute: there is no retained copy of the original content to challenge. Operationally, derived signals are more compact, more queryable, and more useful for downstream analysis than raw content.

At TrawlingWeb, the processing architecture is built around this principle. The output is analysis, not a mirror of the source universe. That is not only a technical choice — it is a TDM compliance choice, and it shapes the entire infrastructure.

The documentation gap is solvable, but it requires intention

The teams that are genuinely protected by Art. 4 are not the ones with the most sophisticated legal opinion. They are the ones who have built documentation into the pipeline itself — logging, transformation records, retention policies with written rationale, source assessment protocols.

None of this is complicated in isolation. The problem is that it requires someone to own it. Legal teams do not own the pipeline. Engineering teams do not own the legal framing. The documentation gap lives in that space between them, and it tends to persist until there is a reason to close it.

The best time to build an audit trail is before you need one. Once a dispute or an inquiry begins, assembling records retrospectively is both harder and less credible than having maintained them continuously.

Review what your pipeline currently logs. Map each log against the elements of Art. 4. Identify where the gaps are. Then close them — not because a regulator is watching, but because an indefensible TDM operation is not one you can scale with confidence.