Technology buyers have absorbed a decade of regulatory clause sets, from data protection addenda to security schedules to resilience requirements. The EU AI Act adds another, and it behaves differently from its predecessors in one important respect. Data protection obligations attach fairly predictably to the roles of controller and processor. AI Act obligations attach to roles that can change based on what you do with the system after you buy it.
The regulation entered into force in August 2024 and applies in phases. Prohibitions and AI literacy duties came first, general purpose AI model obligations followed, with Commission enforcement powers over general purpose model providers becoming applicable in August 2026, and high-risk system obligations phasing in from that point with product-embedded systems later. Amendment proposals have sought adjustments to parts of this timetable, so confirm the position that applies to your specific systems rather than working from any summary, including this one.
For a general counsel or a technology procurement lead, the practical question is narrower than the regulation as a whole. What has to appear in vendor paper, what has to be tracked afterwards, and what silently transfers risk onto your organization.
The clause set that actually matters
Most of the AI Act is about product requirements rather than contract terms. The contractual work concentrates in a handful of areas where your ability to meet your own obligations depends on the vendor.
- Role allocation and classification, an explicit statement of which party is provider and which is deployer for each system, the intended purpose as declared, and the risk classification the parties are proceeding on.
- Information and documentation rights, access to technical documentation, instructions for use, performance and accuracy characteristics, and the information you need to perform your own assessments and to respond to an authority.
- Change and modification notification, a duty to notify changes to the model, training data provenance, intended purpose or performance characteristics, since a substantial modification can alter classification and reassign roles.
- Logging, record keeping and cooperation, access to the logs and records required for your monitoring duties, plus a cooperation obligation for authority requests, incident reporting and corrective actions.
- Transparency and output marking, allocation of responsibility for user-facing disclosure and, where relevant, marking of synthetic content, which is easy to leave unassigned between vendor and customer.
Role allocation deserves the most attention because it is the term most likely to be wrong by accident. A customer that white-labels a vendor system under its own brand, materially modifies it, or deploys it for a purpose the vendor did not declare can find itself carrying provider obligations it never priced. That outcome is driven by conduct rather than by drafting, but the contract is where the parties can at least agree the intended purpose and require notice before it changes.
A contract cannot make you a deployer if your conduct makes you a provider. What the contract can do is fix the declared intended purpose, require your approval before it changes, and secure the information you would need if the role did shift. Treat role allocation as a risk control rather than as a definitional formality.
Where AI clauses go wrong in vendor paper
These patterns show up repeatedly in both vendor-supplied and customer-supplied templates.
- Information rights qualified into uselessness. Access to documentation subject to the vendor reasonable discretion and protection of confidential information is a common formulation that fails at the moment it is needed. Tie the right to the purpose of meeting your own regulatory obligations.
- No change notification for the model itself. Agreements notify changes to the service and say nothing about the underlying model, its version, or its training data provenance. Model change is precisely what can alter performance and classification.
- Classification asserted rather than assessed. The agreement records that the system is not high risk without stating the basis. When an authority or a customer asks, there is nothing behind the assertion.
- Warranties that cannot be operationalized. Broad compliance warranties feel protective and provide little practical remedy. Specific information, notification and cooperation duties are more useful than a general representation.
- Sub-processor style gaps in the AI supply chain. Vendors embed third-party models and components. Without a disclosure and flow-down duty, you cannot see the parts of the stack that carry the obligations.
A five-step approach for the contract portfolio
Step 1, Inventory systems, not vendors
Build a register of AI systems in use, each with its declared intended purpose, its role allocation, its vendor and the agreement that governs it. Vendor-level inventories miss systems embedded in broader platforms.
Step 2, Classify and record the basis
For each system, record the classification reached, the reasoning and the date. An assertion without a basis is not evidence, and classification will be revisited as guidance develops.
Step 3, Standardize an AI addendum by role
Write one addendum for systems where you are deployer and one for where you may be provider, each with the information, notification and cooperation duties stated specifically rather than by general reference.
Step 4, Track notification duties as obligations
Model change, intended purpose change, incident reporting and documentation refresh are dated commitments. Represent them as tracked obligations so a vendor silence becomes visible. The same mechanism used for data protection terms applies, as described in the DPA, GDPR and CCPA enforcement checklist.
Step 5, Review classification on trigger
Re-examine role and classification when the vendor changes the model, when your intended purpose changes, when you brand the system as your own, or when you modify it. Those four events are where roles move.
See AI terms tracked across the vendor portfolio
Aavenir holds role allocation, classification basis and notification duties on the agreements that govern each AI system.
Why the AI addendum should not simply copy the DPA pattern
It is tempting to treat AI terms as another privacy addendum, because the shape looks similar: a regulation, two roles, a set of flow-down duties and a schedule of technical measures. The analogy is useful for structure and misleading on substance. Data protection roles are relatively stable across the life of an arrangement, and the processor duties are largely about how data is handled. AI Act roles can move when a system is rebranded, modified or repurposed, and the obligations attach to a product placed on the market rather than to a data flow. The practical consequences are that the AI addendum needs a live intended purpose statement rather than a static processing description, a change notification duty focused on the model rather than on the service, and a re-assessment trigger tied to conduct. Where a system also processes personal data, both addenda apply and should be drafted to avoid conflicting information and audit rights. Teams already running a mature data protection program have the right muscles for this work; they just need to point them at a moving classification rather than a fixed one.
Role, duty and contract lever
The summary below is a planning aid rather than legal advice, and the operative text of the regulation together with current guidance should govern any assessment.
| Your role | Main duties | What you need from the vendor | Contract lever |
|---|---|---|---|
| Deployer of a high-risk system | Use per instructions, human oversight, input data control, monitoring | Instructions for use, performance characteristics, logs | Information rights tied to your obligations |
| Provider of a high-risk system | Risk management, data governance, documentation, conformity, post-market monitoring | Component documentation and technical access from suppliers | Supplier information and cooperation duties |
| Deployer becoming provider | Full provider duties on rebrand, substantial modification or purpose change | Advance notice and documentation sufficient to assume the role | Intended purpose fixed, change notice required |
| Buyer of a general purpose model | Depends on downstream use | Model documentation, usage limits, change notice | Model version and change notification |
| Any role, transparency cases | User-facing disclosure and content marking | Clarity on which party discharges the duty | Explicit allocation of the disclosure duty |
AI clauses reward specificity. Broad compliance warranties and reasonable cooperation language read well and deliver little when an authority, a customer or an incident requires an answer within days. Fix the role, fix the intended purpose, secure the information rights against your own obligations, and track the notification duties as dated commitments. For the commercial pressures that push these terms through review too quickly, see the deal desk bottlenecks guide.
For related guidance, see The IT leader’s guide to SaaS vendor contract sprawl, SaaS renewal and vendor consolidation, at a glance and EHR vendor contracts: interfaces, export and data access.
