Article 25(2): the provider hand-over pack — and how to make it undisputable

Regulation (EU) 2026/1744, in force since 27 July 2026, did something quiet but consequential to Article 25 of the AI Act: it rewrote the hand-over duty in concrete terms and made breaching it fineable. When another actor becomes the provider of a high-risk AI system, the initial provider now owes a specific evidence package. This page is what triggers the duty, what the package must contain, and the one property most packages will lack when it matters: proof of when they were written.

What changed on 27 July 2026

Article 25(2) always required the initial provider to cooperate when provider responsibility moves. The Digital Omnibus on AI (Regulation (EU) 2026/1744) replaced the general wording with three concrete deliverables, and added a new point to Article 99(4) making non-compliance with Article 25(2) and 25(4) subject to administrative fines. A duty that used to live in contract negotiations now has a regulator and a price attached.

When someone else becomes the provider

Under Article 25(1), a distributor, importer, deployer or other third party is treated as the provider of a high-risk system when it puts its name or trademark on a system already on the market, makes a substantial modification to it, or modifies its intended purpose in a way that brings it into high-risk scope. Delivery firms and white-label arrangements live inside this article: the client that ships the system under its own brand is, in the regulation's eyes, the new provider — and the firm that built it owes the pack below.

The three deliverables

Article 25(4) extends the logic upstream: suppliers of models, tools and components used in a high-risk system must specify, by written agreement, the information, capabilities and technical access needed for compliance, "based on the generally acknowledged state of the art." Free and open-source components outside general-purpose AI models are exempt.

Why every hand-over is an evidence event

Picture the dispute two years after a hand-over. The new provider says a failure mode was never disclosed. The initial provider produces a document that lists it. The new provider asks the only question that matters: when was this document written? An ordinary file has no good answer — file dates are editable, wikis are versioned by the same party that benefits, and an email thread proves sending, not content stability. Both sides now argue about the record instead of the system, which is precisely the situation Article 99(4) fines were designed to punish.

The undisputable version

The fix is the same pattern this site documents for evaluation claims: reduce the pack to canonical bytes, hash it (SHA-256), and have the hash countersigned by parties who do not work for you — an RFC 3161 timestamp authority and a public transparency log. From that moment, "this exact pack existed in this exact form on this date" is a fact either side can verify offline, and the dispute collapses back to the system itself.

PRML is the open standard for the evaluation-claims slice of that pack: nine fields locking a metric, comparator, threshold, dataset hash and seed before a run, with public receipts that are Ed25519-signed, RFC 3161 countersigned and mirrored to the Rekor transparency log. The same locking pattern applies naturally to the rest of a hand-over package — the limitations register, the failure-mode list, the access-grant record. What matters is that the lock happens while the system is being built, not the week the hand-over is negotiated.

What to do now

If your firm builds AI systems that clients ship under their own name: start keeping the limitations register and failure-mode list as living, locked documents today, so that the pack exists before any hand-over is on the table. If you are on the receiving side, ask for the pack's hash and its independent timestamps before you accept provider responsibility. Either way, the cost of the lock is minutes; the cost of the missing lock is an Article 99(4) argument.