Contracts cannot transfer statutory AI Act roles, but they can and should allocate the information, cooperation and evidence duties that let each actor perform its role. A value-chain contract should state the intended purpose and permitted uses, the classification information, the documentation and instructions to be supplied, the update and change notice process, the incident and feedback channels, the logging and monitoring information, and the cooperation duties with authorities. A handoff record should show what was supplied, in which version, to whom, and when, so that each actor's file can be traced to the version it received. A contract that only states a price, a licence and a warranty does not support AI Act compliance for a high-risk system.
What information must travel downstream?
Downstream actors need the intended purpose, the capabilities and limitations, the instructions for use, the human oversight design, the logging capability, the update and versioning practice, the known risks, and the incident channel. For general-purpose models, Article 53 requires information for downstream providers, including technical documentation and capability information. For high-risk systems, Article 13 requires instructions that enable the deployer to interpret output and use the system appropriately. The contract should list the documents to be supplied, the format, the language, the version, and the update process, and the handoff should be recorded. A downstream actor that cannot obtain the information should record the gap and limit the deployment, rather than proceeding on assumed information.
What information must travel upstream?
Upstream actors need feedback on performance, incidents, misuse, purpose changes, and operating conditions. Deployers must inform providers of risks and serious incidents under Articles 26 and 73, importers and distributors must inform providers of non-conformity and risk under Articles 23 and 24, and authorised representatives must inform providers where a system presents a risk. The contract should provide a channel for that feedback, a response time, and a record of the action taken. Upstream feedback should feed into the provider's post-market monitoring and risk management, so that a deployer report leads to analysis and, where needed, a design or instruction change. A contract with only a downstream information flow, and no upstream feedback route, is incomplete.
For the broader regulatory framework, see deployer responsibilities.
How should purpose and change be controlled by contract?
The contract should state the specified intended purpose, the permitted uses, and the uses that are not permitted, and should require notice and approval before a purpose change, a substantial modification, a rebranding, or a new deployment context. It should require notice of model updates, data changes, integration changes, and supplier changes that could affect classification or conformity. It should state the process for reassessment, the information to be supplied for reassessment, and the consequence of an unapproved change, including suspension of supply or use. The contract should also address the Article 25 consequence directly: the parties should acknowledge that a purpose change or substantial modification can change the statutory role, and should allocate the work needed to meet the new role's duties.
What should a handoff record contain?
A handoff record should contain the system and version, the documents supplied with their versions, the instructions version, the classification summary, the conformity information, the recipient, the date, and the person who supplied and received the handoff. It should be retained by both parties, so that a later reviewer can trace which version of the system and which version of the documentation a deployer received. Where a system is supplied through a chain of importers and distributors, each handoff in the chain should be recorded, so that the chain can be followed from provider to deployer. A handoff that is only an email with an attachment, without a record of what was supplied and when, is difficult to reconstruct after a change or an incident.
What limits should contracts respect?
Contracts should not purport to transfer statutory roles, to waive duties owed to authorities or affected persons, or to prevent an actor from informing an authority where the Act requires it. A clause that requires a deployer not to report a risk, or that requires an importer not to withhold a non-conforming system, would conflict with the Act and should not be relied on. Contracts should also respect data protection law, including processor terms where personal data are processed, and should not require the disclosure of information that the disclosing party is not entitled to share. The contract should state the cooperation duties with authorities, the handling of confidential information in authority requests, and the process for joint responses where more than one actor is involved.
Continue with provider responsibilities.
What is not decided by this guide?
This guide explains the information and contract structure in outline. It does not draft contract clauses, does not decide whether a particular contract satisfies the Act, and does not allocate liability between parties. Contract drafting for a high-risk value chain should be done with legal advice, taking account of the classification, the roles, the product and sectoral law, and the applicable data protection and liability rules. The contract should be reviewed when the system, the roles, or the law changes, and the handoff records should be kept current with the versions actually supplied.
Frequently asked questions
Can a contract make a deployer the provider?
No, not by itself. Article 25 applies by statute where its conditions are met, such as rebranding, substantial modification or purpose change. A contract can allocate information and cooperation duties and can prohibit changes, but it cannot create or remove the statutory role change.
What is the most common contract gap for high-risk systems?
The absence of an update, change notice and feedback process. Many contracts cover initial supply but not model updates, purpose changes, incident reporting or documentation updates, leaving the downstream actor without the information needed to meet its ongoing duties.
Should a handoff include the full technical documentation?
Not necessarily. Deployers need instructions and the information Article 13 requires, not the full technical file. Importers and authorised representatives need the conformity file the Act requires them to hold. The contract should state what each actor receives, in which version, and when.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗