Why the AI Act Reaches Your Contracts
The EU AI Act's impact on AI vendor contracts begins with its reach: if you build, deploy, or even procure an AI system that touches anyone in the European Union, the Act applies — regardless of where your company is headquartered. It is a binding regulation with extraterritorial scope, conformity assessments, and penalties, not a voluntary code. That makes it a contract problem, because the obligations and the liability for meeting them have to be allocated between you and your AI vendors in writing.
The penalties make the allocation worth fighting over. Infringements involving prohibited AI practices carry fines up to €35 million or 7% of global turnover — nearly double the GDPR ceiling — with up to €15 million or 3% for other obligation breaches and €7.5 million or 1% for supplying incorrect information to authorities. These obligations sit alongside the data protection and sovereignty terms in our GDPR and data sovereignty guides, and belong in the same governance operating model as the rest of the compliance and governance programme.
The 2025–2027 Compliance Timeline
The Act entered into force on 1 August 2024 and applies in phases. The key dates for contracting are already biting.
| Date | Obligation | Status |
|---|---|---|
| 2 Feb 2025 | Prohibited AI practices banned; AI literacy duties apply | In force |
| 2 Aug 2025 | General-purpose AI (GPAI) model obligations apply | In force |
| 2 Aug 2026 | High-risk AI systems: conformity assessment, registration, risk management, logging, human oversight | Upcoming |
| 2 Aug 2027 | Full compliance for pre-Aug-2025 GPAI models and AI embedded in regulated products | Future |
The practical implication is that AI procured today will cross compliance thresholds during the life of the contract. An agreement signed in 2026 for a high-risk use case must already account for the August 2026 conformity-assessment obligations — which is why the contract, not a later remediation project, is the right place to fix responsibility. The Microsoft vendor hub is a useful reference point given how many enterprises meet these questions first through Copilot and Azure AI services.
Fine-tune a foundation model heavily enough and you can be reclassified from deployer to provider — inheriting the far heavier obligations. The contract should define who holds which role, and what happens if that classification changes.
Provider vs Deployer: Who Carries What
The Act assigns obligations by role, and the contract should make the allocation explicit. If you build a retrieval pipeline or an agent on top of a foundation model, you are likely a deployer — but substantially modify the model, for instance through extensive fine-tuning, and you can be reclassified as a provider with significantly heavier obligations. The line is consequential, and vendors will try to push provider-level duties onto the customer while keeping the commercial upside.
GPAI providers carry specific duties that you should be able to rely on contractually: maintaining technical documentation of how the model was built and tested, publishing a summary of training data, supplying a model card describing intended and excluded uses, and respecting EU copyright rules. The GPAI Code of Practice is technically optional but confers a presumption of conformity — a meaningful safe harbour — so a vendor's adherence to it is a fair contractual ask. Treat all of this as part of structured third-party risk management, because an AI vendor's compliance failure can become your enforcement problem.
The Clauses to Negotiate Now
Five contract terms deserve priority. First, role allocation: state explicitly who is provider and who is deployer, and address what happens if customer modifications change that classification. Second, documentation and disclosure rights: access to the technical documentation, model cards, and training-data summaries you need to meet your own obligations. Third, compliance warranties that the system meets applicable AI Act requirements for its risk tier, backed by a commitment to maintain conformity as the deadlines arrive. Fourth, indemnities covering regulatory penalties and third-party claims arising from the vendor's non-compliance. Fifth, change control, so a model update cannot silently alter the system's risk classification or behaviour without notice.
These map directly to the issues set out in the AI Contract Red Flags white paper and the AI Procurement Checklist, and the commercial negotiation runs through our AI procurement advisory practice. Given penalties that reach 7% of global turnover, the allocation of AI Act liability is now one of the most consequential terms in any AI agreement — request a confidential briefing before you sign one.
Building an AI Inventory and Risk Classification
You cannot allocate AI Act liability in contracts for systems you have not catalogued. The foundational step — and the one most enterprises have not completed — is an AI inventory: a register of every AI system in use or under procurement, the vendor behind it, the data it processes, and the business purpose it serves. Because much AI now enters the enterprise embedded inside ordinary SaaS rather than as a standalone "AI project", this inventory routinely surfaces dozens of systems that no one had classified as AI at all, each carrying its own obligations.
With the inventory built, classify each system by the Act's risk tiers — prohibited, high-risk, limited-risk, or minimal — because the tier determines both the obligations and the contractual protections you need. A high-risk system used in employment or credit decisions, subject to conformity assessment from August 2026, demands far stronger documentation and warranty terms than a minimal-risk productivity assistant. The classification also drives the AI-literacy duty that has applied since February 2025, which requires that staff working with these systems understand their capabilities and limits.
The inventory then becomes the control point for everything that follows. It tells procurement which new agreements need the full set of AI Act clauses and which need only light touch; it tells legal where the conformity-assessment deadlines fall; and it gives the business a defensible record if a regulator asks what AI the organisation runs and how it is governed. Run the inventory and classification as a standing process rather than a one-off, since a vendor's model update or a change of use can move a system between tiers, and feed the output straight into procurement so that every new AI agreement is negotiated against a known risk position rather than a blank page. The enterprises that will struggle under the Act are not those using the most AI, but those that cannot say, on demand, what AI they use at all.