The AI Act and your suppliers: what to watch for in the contract

There is a sentence that appears in almost every AI sales conversation: "we are fully AI Act compliant." It is usually true and almost always irrelevant to your position, and the gap between those two facts is where companies get into trouble.

The AI Act distributes obligations across roles, not across invoices. A provider who builds and markets a system has one set. A deployer who uses it in their own operation has another. Buying from a compliant provider does not transfer your deployer obligations to them, any more than buying a compliant van removes your duty to drive it properly.

What stays yours regardless of who you buy from

If you deploy a high-risk system, several things remain yours no matter what the contract says. Ensuring there is meaningful human oversight over how it is used in your process. Using it in line with the provider's instructions, and being answerable if you do not. Monitoring how it behaves on your actual data, which is not the data it was tested on. And keeping the records that show you did those things.

Article 26 is worth reading once in full, because it is short and it is the article that describes your position rather than your supplier's. Among other things it requires that the people assigned to oversee the system have the necessary competence, training and authority, that you inform the provider of risks and serious incidents you spot, and that you keep the system-generated logs for at least six months where those logs are under your control. That last one is concrete, checkable, and frequently overlooked: if the logs live in your supplier's system and they delete them after thirty days, you cannot meet an obligation that is yours.

There is one more that catches employers specifically. If you deploy a high-risk system in the workplace, you must inform the workers affected and their representatives before putting it into use. That is not a courtesy; it is in the article.

A supplier cannot take those over, and a supplier who implies they can is either being loose with language or does not understand the regulation. Neither is a reason to walk away by itself, but it tells you something about how carefully to read the rest of what they say.

Paperwork on a table. If your supplier cannot produce documentation, you cannot meet your own obligations.

Six things to get into the contract

One: the right to the technical documentation, not a summary of it. If your system is high-risk, you need documentation to meet your own obligations. If the supplier will only provide a marketing-grade overview, you have a problem that surfaces at the worst possible moment. Ask for it before signing, and treat reluctance as information.

Two: notification when the model changes. This is the clause most often missing and the one that causes the most trouble. A model that quietly gets updated behaves differently on your data, and if you validated it before the change, you validated something that no longer exists. You need to be told, in advance, in writing.

Three: an explicit statement of what the supplier warrants about outputs. Almost always the answer is nothing, and that is normal. What matters is that it is stated rather than left ambiguous, because the ambiguity is what produces a fight later. See Wie is aansprakelijk for what that means in practice.

Four: where your data goes, and whether it trains anything. Not only for privacy law, which is a separate regime from the AI Act, but because "your inputs may be used to improve our services" is a sentence with very large consequences for a company with confidential customer data.

Five: an exit that actually works. Your data out, in a usable format, within a defined period, without a fee that makes leaving theoretical. A supplier who is confident in their product has no reason to resist this.

Six: who does what if a regulator asks. Rare, but the time to agree it is not while it is happening.

Stacked shipping containers. A stack you can swap a layer out of is a stack you still control.

The six clauses, and what goes wrong without each

None of these six require technical knowledge to ask for. All six are easier to obtain before signature than after, and the difficulty of obtaining them afterwards is roughly proportional to how much you need them.

Why the ability to leave is a compliance question, not just a commercial one

This is the part usually treated as a procurement preference and it deserves better, because it has a direct bearing on your regulatory position.

If a supplier changes their terms, raises the price, gets acquired, or turns out not to meet an obligation you depend on, your options are entirely determined by how hard it is to replace them. A company that cannot switch has no leverage and no remedy; it can only comply with whatever the supplier decides next. That is not a strong position to be in when the thing you depend on them for is your own regulatory compliance.

This is why we build the way we do, and it is worth stating plainly because it is a genuine differentiator rather than a slogan. Every layer of the stack we put in place should be replaceable in days rather than quarters: the model, the storage, the interface, the hosting. Not because we expect to replace them, but because the ability to replace them is what keeps the choice yours. A semantic layer that describes your business rather than a vendor's schema, as covered in Je data op orde krijgen, is the same principle applied to data: the definitions survive a system replacement because they were never tied to the system.

Portability is the point. EU hosting is a useful property, and it is not the same thing as control. A system hosted in Frankfurt that you cannot leave is still a system you do not control.

Questions to ask before signing

Four questions, none of which require technical knowledge, and all of which are hard to answer vaguely:

Which decisions does your tool make without a human seeing them first? What happens, concretely, when it is wrong? What do you warrant about the correctness of outputs, in writing? If we want to leave in eighteen months, what exactly do we get back and how long does it take?

The fourth one changes the tone of the conversation more than the other three combined, and how a supplier reacts to it is genuinely informative.

About this page

The provider-versus-deployer distinction is the structure the AI Act itself uses; the point that obligations follow roles rather than purchase is the accurate framing and is why "we are compliant" from a supplier does not settle your position. The portability argument reflects how Radical builds and is our own position, not a regulatory requirement. Privacy law and the AI Act are separate regimes and are treated as such here. This is not legal advice; for a specific contract, involve your own lawyer. Written by Radical's own team; no client data was used.