AI Act series for business (no. 8) · They are not demanded out of caution, but because the Regulation imposes obligations on you that you cannot discharge unless the supplier hands something over.
There is an asymmetry at the centre of this question. Regulation (EU) 2024/1689 allocates obligations between the provider of an AI system and the party deploying it. The contract, on the other hand, is drafted by the provider.
And its standard terms are written to give you none of what you need. Not out of bad faith, but because they are drafted from the side that does not bear your obligations. So a contract with an AI supplier is not a software contract with a data protection annex. It is the document in which your company buys — or loses — its own ability to comply.
Seven clauses, in the order in which they matter. But first, a warning that changes which of them apply to you.
First of all: is it a high-risk system?
Three of the seven clauses — the first, the second and the fourth — derive from articles 25 and 26 of the Regulation, which sit in the chapter on high-risk AI systems and apply only to those. If your company uses a generative tool to draft marketing copy, it has no article 26 obligations and will not acquire them however firmly the supplier says otherwise.
There is also a question of timing. The high-risk obligations are deferred: depending on the type of system, to 2 December 2027 or to 2 August 2028. Those under article 50 apply from 2 August 2026, and the AI literacy duty under article 4 has applied since 2 February 2025.
That is not a reason to leave these clauses for later; it is the reason to introduce them now. A service contract signed today with automatic renewals will still be running when those obligations bite, and by then there will be no negotiating margin. What makes no sense is demanding the high-risk clauses for a system that is not high-risk.
1. Who is the provider and who is the deployer
This is the first and the one that can change everything. Article 25(1) of the Regulation sets out three circumstances in which a distributor, importer, deployer or other third party is deemed to be a provider of a high-risk system: where it puts its name or trademark on a high-risk system already placed on the market; where it makes a substantial modification to a high-risk system that remains high-risk; and where it modifies the intended purpose of a system — including a general-purpose one — that was not high-risk, such that it becomes so.
Which means that putting your logo on someone else’s tool, or using it for something other than what it was sold for, can transfer the entire provider regime to you: conformity assessment, technical documentation, marking and the rest.
Article 25(2) provides the way out: the initial provider ceases to be considered the provider of that system, but must cooperate closely with the new one, supplying the documentation needed to verify compliance with article 16, disclosing known limitations and failure modes, and granting access for testing and validation. But that duty does not apply where the initial provider has clearly stated that its system is not to be turned into a high-risk system.
There lies the trap, and the reason for the clause. A single line in the general terms stating that the service is not to be used for high-risk purposes leaves the supplier with no duty of cooperation and you with the provider’s regime and no documentation. The clause must do three things: state expressly who is provider and who is deployer; require the supplier to notify any change to the system capable of altering that allocation; and capture the article 25(2) duty of cooperation contractually, whatever the general terms may say.
2. The instructions for use
Where the system is high-risk, article 26(1) requires you to use it in accordance with the instructions for use accompanying it, taking appropriate technical and organisational measures to that end. Article 26(2) requires you to assign human oversight to natural persons with the necessary competence, training and authority.
Neither obligation can be discharged without a document the supplier has and you do not. Require its delivery, in a language your organisation understands, with updates when the system changes, and — this is the part that gets forgotten — that the instructions cover the uses you will actually make, not merely those the supplier imagined.
3. Article 50 transparency, allocated precisely
This one does apply to any system, high-risk or not, and has done since 2 August 2026. But it is worth knowing exactly whose each duty is, because it is easy to assume someone else’s obligations.
Paragraphs 1 and 2 bind the provider. Article 50(1) requires systems interacting directly with natural persons to be designed so that those persons are informed they are dealing with an AI system, unless that is obvious to a reasonably well-informed person. Article 50(2) requires the outputs of systems generating synthetic content — audio, image, video or text, including general-purpose systems — to be marked in a machine-readable format and detectable as artificially generated or manipulated, with exceptions where the system performs an assistive function for standard editing or does not substantially alter the input data.
Paragraphs 3 and 4 bind the deployer, but only in specific cases. Article 50(3) requires deployers of emotion recognition or biometric categorisation systems to inform the persons exposed to them. Article 50(4) requires disclosure that content is artificially generated or manipulated in the case of deep fakes of image, audio or video, and of text published to inform the public on matters of public interest — with two significant qualifications: for evidently artistic, creative, satirical or fictional works the duty is limited to disclosing that such content exists in a manner that does not hamper the work, and the duty regarding text does not apply where the text has undergone human review or editorial control and a person bears editorial responsibility for its publication.
Two practical consequences follow, and they should not be confused. First: if you deploy a third party’s conversational assistant, the duty to inform under 50(1) and the duty to mark under 50(2) are theirs, not yours, and what you need from the contract is a warranty that they comply, with liability if they do not. Second, and this is what connects back to the first clause: if you put your trademark on that system or change its intended purpose, article 25 may make you the provider, and those duties then become yours. The allocation under article 50 depends on the role you occupy, and the role is settled by clause one.
4. The logs, which you only have if they let you export them
For high-risk systems, article 26(6) requires you to keep the automatically generated logs for a period appropriate to the system’s intended purpose and of at least six months, insofar as those logs are under your control.
“Under your control” is the operative phrase. In a cloud service, the logs sit on the supplier’s server. If you cannot export them, you cannot keep them — and your obligation subsists. Require access, a usable export format, the retention period you need and — the clause nobody includes — access to the logs after the contract ends, because the retention obligation outlives the commercial relationship.
5. What the supplier may do with what you put in
This is the clause with the greatest economic value and the worst default position. Standard terms commonly reserve the supplier’s right to use customer inputs to train or improve its models. It should be struck out or narrowed with precision.
Three further points travel with it: the processor agreement where personal data is involved, with its international transfer regime; confidentiality for the trade secrets your staff will type into prompts without thinking; and an express prohibition on using your data to train models subsequently offered to third parties, which is a different and graver matter than improving the service you buy.
6. Model changes, versions and exit
A supplier that changes the underlying model without notice changes your outputs, your risk assessment and your compliance position all at once, and without your knowing.
Require notice of material changes, the ability to pin a version for a reasonable period, adequate notice of a model’s withdrawal, and a right to terminate without penalty where a change materially affects you. And, with the previous section, export of data and logs on termination.
7. Liability: why the usual cap is derisory
Article 99 of the Regulation provides for fines that may reach EUR 15 million or 3% of worldwide annual turnover, depending on the infringement. Against that, the liability cap customary in technology contracts — the amount invoiced over the previous twelve months — bears no relation to the risk.
But precision is needed here, because the usual drafting of this clause is legally defective. An administrative fine cannot be transferred by contract. The penalty is personal to the infringer and serves a public purpose; agreeing that someone else will bear it does not displace it, and depending on the applicable law an indemnity drafted in those terms may be ineffective.
What can be done, and what should be asked for, is different: to define as an express contractual breach by the supplier the failure to deliver documentation, the absence of marking, or the assertion of a conformity that did not exist — and to exclude from the liability cap the damages arising from those breaches. Whether the amount of a fine you have paid can be counted among those damages is a question of the applicable law and of causation, not something the clause can settle on its own. But without that groundwork there is no argument to be had at all: the twelve-month cap applies and that is the end of it.
That the cap should cover service failures is reasonable. That it should also cover the consequences of what the supplier did not do and you were required to evidence is not.
What this changes in practice
None of these seven clauses is exotic, and none requires renegotiating an entire framework agreement: they are addenda. What they require is doing one thing before signing, which is to ask which obligations under the Regulation will fall on your company, and what you need from the supplier in order to discharge them.
With that list made, the contract drafts itself. Without it, you sign the supplier’s — which is precisely the one that makes no provision for your obligations.
This article is for general information and does not constitute legal advice. Whether a system is high-risk, and how the provider and deployer roles are allocated, depends on the particular case.