A contract for an AI system should state the role of each party for AI Act purposes, the intended purpose, the documentation and information to be provided, the data arrangements, the change and update arrangements, the incident and cooperation arrangements, and the action to be taken if the system is found to be non compliant or unsafe. It should not rely on general statements that a party will comply with the law, and it should not allocate regulatory duties in a way that contradicts the Act. This guide gives contracting topics in general terms. It is not a contract template and it does not give legal advice for a specific supply arrangement.
Why does the contract matter for AI Act roles?
The contract matters because the AI Act assigns duties by role, and the role depends on the facts of the supply arrangement, not only on the label used in the contract. A supplier that develops a system and places it on the market under its own name is the provider. A customer that uses the system under its authority is the deployer. A distributor, importer or integrator that puts its name on the system, substantially modifies it or changes its intended purpose can become the provider under Article 25. A contract that calls a supplier a processor, a consultant or a subcontractor does not change the regulatory role where the facts meet the Act definitions. The contract should therefore state the role as the parties understand it, with the facts that support it, and should state what will happen if the facts change. It should also state who holds the conformity file, who provides the instructions for use, who provides the transparency information, and who is responsible for post market monitoring and incident reporting. A contract that is silent on those matters will leave gaps that become visible only when an authority or a customer asks for the file.
What documentation and information should the contract require?
The contract should require the information that the receiving party needs to meet its own duties. For a deployer, that includes the instructions for use, the intended purpose and limitations, the performance and accuracy information, the human oversight arrangements, the logging arrangements, the data requirements, and the information needed for the deployer risk assessment and fundamental rights impact assessment where applicable. For a downstream provider that integrates a model or a component, that includes the technical documentation or information required by Articles 53 and 25, the limitations and failure modes, and the testing evidence. The contract should state the form of the documentation, the version, the language, the update arrangements and the response time for questions. It should state what happens if documentation is incomplete, late or inaccurate, including the right to pause use or to withhold payment where the contract allows it. It should also address confidentiality and intellectual property, so that the receiving party can use the documentation for regulatory purposes without breaching a confidentiality duty. A documentation clause that promises information on request, without a form, a version or a time limit, will not support the receiving party when it needs the information urgently.
For the broader regulatory framework, see SMEs, startups and open source overview.
How should data, updates and changes be handled?
Data, updates and changes are the areas where AI contracts most often fail in practice. The contract should state what data the system uses, what data the customer provides, what data is generated in use, who controls each category, how long data is kept, and how data is returned or deleted at the end of the contract. It should state who can update the model, the software or the data, what testing is required before an update, who approves the update, how users are informed, and what happens if an update changes the intended purpose or the performance. It should state the change notification duties, with a notice period and a description of the change, so that the receiving party can reassess classification, risk and oversight before the change takes effect. It should address retraining, fine tuning and configuration changes by the customer, and state whether those changes are within the intended purpose or require the supplier to be consulted. A contract that allows silent updates, or that allows the customer to retrain a model without any notification or testing, will create a record gap and a risk gap that the parties will discover only after a problem.
What incident and cooperation clauses are needed?
The contract should state the incident reporting and cooperation duties in practical terms. It should define what counts as an incident or a serious incident for the purposes of the contract, who must notify whom, within what time, in what form, and with what information. It should state the cooperation duties on investigation, on corrective action, on authority requests and on customer notifications. It should state the arrangements for suspending use, for rolling back an update, for withdrawing a version, and for providing a fix. It should state the record keeping duties, including logs, incident records and change records, and the retention period. It should address the Article 25 cooperation duties where a party may become a new provider, including the provision of documentation, limitations information and technical access. The clauses should be tested with a hypothetical incident: if the system fails on a Friday evening, who is called, what information is available, and what action can be taken. A clause that requires cooperation without naming a contact, a time limit or a form will not work in that situation.
What should a small supplier not promise?
A small supplier should not promise what it cannot evidence, and should not promise to meet a legal conclusion for the customer. It should not promise that a system is compliant, that it is not high risk, or that it meets a standard, without the file that supports the promise and the conditions and limits that apply. It should not promise unlimited liability, unlimited updates or unlimited support where it cannot deliver them. It should not accept a customer requirement that would require it to change the intended purpose, to process data it should not process, or to remove a safety or oversight measure, without a fresh assessment. It should state the limitations of the system plainly, in the instructions and in the contract, including the conditions under which the system should not be used. A contract that over promises will create a commercial dispute and a regulatory problem at the same time. A contract that states the system, its limits and the evidence plainly will be easier to perform, easier to explain to a customer and easier to defend to an authority. The supplier should also be careful with standard terms imposed by a large customer that allocate AI Act duties in a way that contradicts the Act. Those terms should be reviewed by a legal adviser before signature.
Continue with startup first product planning.
What does this guide not provide?
This guide does not provide a contract template, does not draft clauses, and does not give legal advice for any specific supply arrangement. Contracting for AI systems turns on the facts of the system, the parties, the data, the sector and the jurisdiction, and on the law that governs the contract. A small supplier or customer with a specific arrangement should obtain legal advice on the contract, with the system description, the intended purpose and the regulatory file in hand. This guide gives the topics to cover and the questions to ask, so that the advice can be sought efficiently and the contract can be reviewed against a clear list. It does not replace that advice.
Frequently asked questions
Can a contract make a deployer the provider?
A contract label alone does not change the regulatory role, which depends on the facts under the Act definitions and Article 25. A contract can allocate costs and cooperation duties between the parties, and should state the roles as understood with the facts that support them, but a deployer that substantially modifies a system or changes its intended purpose can become the provider by operation of Article 25, whatever the contract label says.
What documentation should a customer insist on?
The instructions for use, the intended purpose and limitations, performance and accuracy information, human oversight and logging arrangements, data requirements, and the information needed for the deployer risk assessment and any fundamental rights impact assessment. The form, version, language, update arrangements and response time should be stated in the contract.
How should updates be contracted?
With a change notification duty, a description of the change, testing and approval arrangements, user information, and a statement of whether customer retraining or configuration changes are within the intended purpose. Silent updates, and updates that change the intended purpose without reassessment, should be avoided.
Should a small supplier promise compliance in a contract?
A supplier should promise only what it can evidence, with the file, conditions and limits stated. A general promise that a system is compliant, without the supporting file, creates commercial and regulatory risk. Limitations should be stated plainly in the instructions and in the contract.
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 ↗