
On 5 March 2025, the European Commission published an updated set of model contractual clauses for AI procurement, aimed initially at public buyers. Within months, as the IAPP noted in May 2026, private-sector procurement teams were treating them as the de facto standard for AI contracting across Europe. When there is no established practice for buying software that makes consequential decisions, buyers tend to follow the most authoritative guidance available. In this case, that guidance came from the Commission.
Those same procurement teams quickly discovered why the clauses mattered: buying AI software in Europe now involves three separate legal frameworks, each with its own timeline, its own definitions, and its own allocation of responsibility. Getting the contract right is not a just legal formality that follows the commercial decision. It shapes what the commercial decision actually will eventually cost.
The EU AI Act, Regulation (EU) 2024/1689, divides responsibility between the provider who built the system and the deployer who puts it to work. Jorpex's June 2026 guide on the Act and public procurement makes the practical sequence clear: map the system against Annex III before you specify it, not after you sign for it. Annex III covers AI used in employment decisions, credit scoring, access to education, and critical infrastructure, among other areas. If the system you are buying falls into one of those categories, the high-risk obligations attach to the deployer from the moment of deployment. The vendor's certification does not discharge them.
Procurement teams most often go wrong precisely here. A supplier can hand over a CE-marked, conformity-assessed and documented system, but the organisation that deploys it still carries its own duties: such to ensure human oversight works in practice, keeping the required logs, and making sure the people operating the system meet the AI literacy obligation that has applied since 2 February 2025. As the European Institute of Public Administration observed in December 2024, significant responsibility rests with procurement officers to translate these requirements into technical specifications and award criteria, not to append them as contractual boilerplate after the selection is made.
For financial institutions, a second framework sits on top of this. The Digital Operational Resilience Act has applied since 17 January 2025. For any AI arrangement supporting a critical or important function, DORA's Articles 28 to 30 require audit rights, a register of information, and a tested exit strategy, all before the contract is signed. An AI tool that qualifies as a third-party ICT service and supports a critical function cannot be procured without those provisions in place. The timeline is not a grace period.
The frameworks describe obligations as if the product you buy stays the product you bought. It does not. VDF AI's July 2026 procurement checklist identifies the structural issue plainly: models are versioned, replaced, and re-tuned after purchase, and the assets that accumulate around a deployment, embeddings, indexes, agent definitions, evaluation sets, and audit logs, are frequently held in vendor-specific formats. Exit is harder than with conventional software, and the compliance position can shift when the vendor updates the model.
Regulated organisations face a specific version of this difficulty. A system that was not high-risk when first deployed can become high-risk after a capability update, because the deployer's obligations under the AI Act attach to how the system is actually used, not how it was described in the original procurement. Contracts must therefore address what happens when the system changes: who assesses the new version, who holds the audit trail, and what triggers a re-evaluation of the risk classification.
The Commission's model clauses address some of this. They include provisions on system updates, audit rights, and data portability. They are also a starting point, drafted for public buyers and not yet tested in litigation. A private organisation procuring AI software in Europe today is working from guidance that is serious, structured, and incomplete.
Starting from the Commission's model clauses, mapping the system against Annex III before specifying it, and building DORA's requirements into the term sheet rather than the schedule, gives procurement teams a much stronger starting point. Most organisations buying AI tools in Europe are still relying on general software procurement templates. By the time the questions arrive from legal, compliance, customers, or regulators, rebuilding that position is far more difficult than having it documented from the start.