EU AI Act Contract Clauses for High-Risk AI Vendors

What the Act requires, and what it leaves to contract

Regulation (EU) 2024/1689 places direct duties on deployers of high-risk AI systems. Deployers must take appropriate technical and organisational measures to use the system in accordance with its instructions for use. To the extent they control input data, they must ensure it is relevant and sufficiently representative for the intended purpose. They must monitor operation on the basis of the instructions for use and, where relevant, inform providers in accordance with Article 72. They must also inform affected persons and, before workplace deployment, affected employees and workers' representatives.

The Act does not mandate deployer-vendor contract terms. Its written-agreement requirement and its provision on voluntary model terms apply to providers and the third-party suppliers of tools, services, components or processes integrated into their systems. They do not govern the deployer-provider relationship. Deployers therefore have to write their own clauses, and the useful starting point is the obligation list above: each clause should exist because a deployer duty cannot be met without something the vendor controls.

Timing affects negotiation. As of November 2026, the Commission's AI Act page states that high-risk obligations start on 2 December 2027. Under the provisional agreement on the Digital Omnibus on AI, the dates are 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for systems embedded in products. Contracts signed now will usually still be in force when those dates arrive, so the terms should be drafted for the obligations as they will apply.

Clauses that secure information and access

Instructions for use and documentation. Monitoring, risk reporting and suspension duties are all tied to the provider's instructions for use. The contract should require delivery of the instructions in a form the deployer can retain, and prompt written notice of every update, with a statement of what changed. Without this, a deployer cannot show that it used the system as instructed, because it cannot show which version of the instructions applied at a given time.

Log access and retention. The contract should state which logs and records the vendor generates, how the deployer can obtain them, in what format, and for how long they remain available. It should also say what happens to them on termination. Recital 91 refers to deployer obligations on monitoring and, as appropriate, record-keeping, so the deployer needs a defined route to this material rather than a general promise of cooperation.

Risk and incident notification. Where a deployer has reason to consider that use in accordance with the instructions may present a risk within the meaning of Article 79(1), it must without undue delay inform the provider or distributor and the relevant market surveillance authority, and suspend use. The Commission's FAQ adds that deployers must act upon identified risks or serious incidents. The contract can set vendor deadlines for notifying the deployer of risks and incidents the vendor identifies, require the vendor to support investigation, and require a named contact. The notification to the authority and the suspension of use remain deployer actions, and no clause transfers them.

Clauses for change, oversight, data and the supply chain

Substantial modification and change notice. A deployer, distributor, importer or other third party is treated as a provider, with Article 16 obligations, if it puts its name or trademark on a high-risk system already on the market, makes a substantial modification such that the system remains high-risk, or changes the intended purpose of a non-high-risk system so that it becomes high-risk. Only the name-or-trademark trigger is stated to be without prejudice to contractual arrangements allocating the obligations otherwise. The text lists no such carve-out for the other two triggers, so a contract should not be relied on to shift provider status after substantial modification or repurposing. The practical clause is a change-notice and cooperation term: the vendor tells the deployer when its own changes or intended-purpose statements move, and the deployer commits to consult before configuring, rebranding or repurposing the system.

Human oversight support. Recital 91 states that persons assigned to implement instructions for use and human oversight need competence, AI literacy, training and authority. The deployer supplies the people, but the vendor can be required to provide training material, a description of the oversight measures the system supports, and updates when they change.

Data governance. The input-data duty applies only to the extent the deployer controls the data. The contract should state which party controls which inputs, so responsibility for relevance and representativeness is not left ambiguous. It should also require the vendor to supply the information on system output and logic that the deployer needs for affected-person notices and for explanations on request where a decision produces legal effects.

Audit, cooperation and subcontractor flow-down. Audit and cooperation rights should cover documentation, logs and support for regulator requests. Because providers must specify by written agreement what their own suppliers of integrated models, tools and components provide, the deployer contract should require the vendor to disclose those suppliers and flow the cooperation obligations down to them.

What a contract cannot do

A clause can give the deployer a right to documents, logs and notice. It cannot demonstrate that the deployer used the system as instructed, that oversight took place, or that a risk was escalated and acted on. The Act frames deployer duties as the deployer's own technical and organisational measures, and a regulator can ask what the system was permitted to do and what it did on a given occasion. Vendor-held logs answer part of that question, but they depend on the vendor's retention, format and cooperation.

This is why operational controls belong alongside the contract. One approach is to enforce policy at runtime, in the execution path between the deployer's users or agents and the AI system, so each interaction is allowed, redacted, blocked or escalated for human approval, and each decision is recorded. The records then show which instructions-for-use constraints were applied, when a person approved an action, and what was retained. This is an operational-control approach, not a requirement of the regulation, and it should be treated as a complement to vendor logs, not a substitute for them.

Trussed enforces policy in this way for individual interactions and tool calls, and produces audit-ready evidence mapped to the EU AI Act. Scope matters: it covers what passes through the enforcement point, so it does not replace vendor documentation, incident support or audit rights.

Internally, deployers should also assign trained and authorised oversight staff, set an escalation path covering provider and authority notification and suspension, and keep a register of deployment changes so that possible substantial modification or purpose changes are caught early.