EU AI Act · Articles 13, 22, 25

Most companies start their AI compliance work after go-live. The moment that actually determines how much work it will be comes months earlier: at the purchase order.

Buying a high-risk AI system means taking on the deployer obligations of Article 26 from the first day in production. Those obligations can only be met with documentation the provider has to supply. If it is missing, the deployer has no basis to work from — while the provider considers the contract fully performed.

That is the asymmetry in AI procurement: the deployer's obligations start on day one of production. The provider's documentation is only obtainable with negotiating leverage, and after signature nobody has any left.

What the provider owes anyway

None of the following is a special request from a requirements document. All of it is a mandatory component of a high-risk AI system lawfully placed on the market. Asking for it means asking for nothing the provider should not already have produced.

Document	Basis	Why the deployer needs it
Instructions for use	Art. 13	Art. 26(1) requires use in accordance with the instructions for use. Without them the obligation cannot be met.
EU declaration of conformity	Art. 47	Evidence that the system went through a conformity assessment procedure.
CE marking	Art. 48	Visible proof of conformity on the system or in the accompanying documentation.
Registration in the EU database	Art. 49	Publicly verifiable. A missing entry is a signal in itself.
Description of logging	Art. 12, 13	Art. 26(6) requires the deployer to retain logs. That presupposes knowing which logs exist and where they sit.
Authorised representative	Art. 22	Only for providers established outside the EU. The contact point inside the Union that holds the documentation.

Four items the instructions for use must contain

Article 13 sets out what instructions for use have to include. Four of those points can be checked before the contract is signed, and they say more about a provider's maturity than any product demo.

Identity and contact details of the provider

This sounds trivial, but in SaaS distribution it is not. The counterparty on the contract is not necessarily the provider within the meaning of the regulation. Knowing who formally is tells the deployer where to report an incident under Art. 26(5).

Performance characteristics, capabilities and limitations

Including accuracy, robustness and cybersecurity, plus the circumstances under which performance may deviate. A provider who cannot name the limits of their own system has not examined them.

The human oversight measures provided for

Art. 26(2) requires the deployer to assign oversight to people with the necessary competence and authority. What intervention the system actually allows is decided by the provider — and has to be described here.

Expected lifetime and maintenance

Including arrangements for updates. This is where the dispute tends to start later: a provider update can overtake the deployer's risk assessment without anyone inside the company hearing about it.

The test before signing

Ask for the instructions for use before the contract is signed. If they do not arrive, or if they turn out to be marketing material, that answers the question of whether the provider really went through the conformity procedure. The enquiry costs one email and replaces half an audit.

When buying turns you into a provider

Article 25 describes situations in which the purchasing company itself becomes the provider — with the full set of Article 16 obligations, from technical documentation under Annex IV to a quality management system. Two of them occur regularly in practice without anyone noticing.

The visible case: your own name

Putting your own name or trademark on a high-risk system already placed on the market makes you the provider. That covers every white-label arrangement and every hand-over to group companies under your own product name.

The quiet case: a new intended purpose

Changing the intended purpose of a system that is not high-risk so that it becomes high-risk has the same effect. The general-purpose writing tool a department starts using to pre-screen job applications is the standard example.

Neither tends to happen by decision; both happen by habit. And both carry sanctions: the obligations under Article 25 are part of the penalty catalogue in Article 99.

When the provider sits outside the EU

A substantial share of the AI systems in use comes from providers with no establishment in the Union. Article 22 requires them to appoint, in writing and before placing the system on the market, an authorised representative established in the EU. That representative keeps the declaration of conformity and the technical documentation available and acts as the contact point for the authorities.

Practical note: the name and contact details of the authorised representative belong in the delivery documentation, not in a later research exercise. When the market surveillance authority asks, that is the address the deployer relies on — and a provider who cannot name one has a distribution structure worth a second look.

What the AI Act does not settle, but the contract must

Three points decide whether a deployer can act when it matters, and none of them appears in any article of the regulation.

Processing agreement and training data

If the system processes personal data, it needs a contract under Art. 28 GDPR — independently of the AI Act. A separate question to settle: whether inputs are used for training. Where the provider pursues its own purposes in doing so, it is no longer acting as a processor in that respect.

Cooperation in incidents and audits

Response times, named contacts, and an obligation to assist with regulatory information requests. The degree of cooperation with the authority is a criterion in setting fines — but it partly depends on the provider.

Notification of material changes

A contractual duty to inform on model swaps, changed performance characteristics or new features. Without it, the deployer learns about the change when the outputs start looking different.

The actual point

Compliance effort does not arise in operations. It arises wherever documentation is missing that should have been delivered once. Every item not asked for at procurement becomes a research project later: during risk assessment, when assigning roles, at the latest with the first information request.

Procurement is the only point in an AI system's lifecycle at which the deployer holds negotiating leverage. After that, every missing document is an escalation with an uncertain outcome.

With SimpleAct

Know what is in the house — and what came with it.

EU AI Act and GDPR in one platform: register AI systems centrally, classify them rule-based, assign roles and responsibilities, and export audit-ready evidence at any time. Made in Germany, hosted in Germany.

Start your AI inventory →

This article is for general information only and does not constitute legal advice. Last updated: 16 September 2026.

Buying AI: the documentation the provider has to deliver