Procurement, Vendor Management and Open Models
Chapter 6 assessed where a model comes from and whose law can reach its provider. This chapter, which closes Part II, turns that assessment into the terms on which an organisation buys. Very few large organisations train their own foundation models, so most of the AI they deploy will be bought, licensed, or downloaded, and procurement becomes an architectural activity. The contract decides which documentation the organisation will receive, whether it can leave, what happens when the vendor changes the model, and who answers to a supervisory authority when something goes wrong. The chapter covers the roles that purchasing creates under Regulation (EU) 2024/1689, the AI Act, public procurement, the third-party risk duties of DORA, the choice between open-weight and proprietary models, and the contract clauses that make exit possible.
Figure 7.1: Sourcing options fall into buy, adapt and build. The further towards build the organisation moves, the more provider obligations it takes on (the table below).
| Option | Group | Main consequences |
|---|---|---|
| Proprietary model via API | Buy | Third-party risk register and exit strategy |
| Vendor product with embedded AI | Buy | Third-party risk register and exit strategy |
| Open-weight model hosted by a cloud provider | Adapt | Exit strategy; data residency and sovereignty |
| Open-weight model self-hosted | Adapt | Data residency and sovereignty |
| Fine-tuned model under own name | Adapt | Provider obligations may transfer |
| Model trained in house | Build | Provider obligations may transfer |
Table for Figure 7.1: Sourcing options and their consequences.
Buying AI is buying an obligation
Every AI purchase assigns the buyer a role, and the role carries duties. The AI Act distinguishes the provider, who develops a system or has it developed and places it on the market under its own name, from the deployer, who uses it under its own authority (1, European Union, 2024). Most purchasing organisations expect to be deployers; the contract and the architecture decide whether that expectation holds.
Roles along the value chain
Article 25 of the AI Act makes a distributor, importer, deployer, or other third party the provider of a high-risk AI system if it puts its own name on a system already on the market, makes a substantial modification to it, or modifies its intended purpose so that it becomes high-risk. Each of these is an architectural act. An organisation that fine-tunes a purchased model and deploys it under its own branding for a purpose the original provider never documented has thereby taken on the provider's obligations for technical documentation, risk management, and conformity assessment. The original provider must then cooperate under Article 25(2), unless it has stated that its system must not be changed into a high-risk system.
Article 25(4) adds that the provider of a high-risk AI system and any third party supplying it with AI systems, tools, services, or components must specify by written agreement the information, technical access, and assistance the provider needs to comply. Free and open-source components are exempt, except general-purpose AI models. The law therefore expects the supply chain of a high-risk system to be contracted, and the architect should see those contracts before approving a design that depends on a component.
What a provider must be able to hand over
For a high-risk AI system, the buyer's readiness review depends on artefacts only the provider can supply. Article 13 requires instructions for use describing the intended purpose, accuracy and robustness, known limitations, and human oversight measures; Article 11 and Annex IV define the technical documentation; Article 72 requires post-market monitoring; and Article 73 requires the provider to report serious incidents. The deployer's duty under Article 26(5) to inform the provider of a risk or serious incident only works if the contract names a channel and a response time, and because Article 26(12) requires deployers to cooperate with competent authorities, the contract should also oblige the vendor to supply logs and documentation on request within a stated period.
Where the purchase is a general-purpose AI model, Article 53 requires the model provider to maintain technical documentation, to supply downstream providers with integration information, to put in place a copyright policy, and to publish a summary of training content. The General-Purpose AI Code of Practice gives providers a voluntary route to demonstrating compliance (14, European Commission, 2025). A buyer should ask whether the provider has signed the Code and make the downstream documentation a condition of contract, not a courtesy afterwards.
Public procurement of AI
Public authorities buy under Directive 2014/24/EU (9, European Union, 2014), whose Article 18 principles of equal treatment, non-discrimination, transparency, and proportionality become architectural constraints that a private company can ignore and a public body cannot.
The Directive in practice
Article 42 has technical specifications formulated in performance or functional terms, by reference to standards, or by a combination of the two, and permits references to a specific make only exceptionally, where a sufficiently precise description is not possible, and with the words "or equivalent". An authority therefore cannot specify a named vendor's model; it must specify what the system must do, how well, under which evaluation, and with which documentation. The evaluation set, the versioned test cases and acceptance thresholds against which any candidate is measured, is thus not only a quality tool but the lawful way to express a requirement that would otherwise be a brand name.
Article 40 permits preliminary market consultations, the moment to learn what the market can document, not only what it can demonstrate. The competitive procedure with negotiation, the competitive dialogue, and the innovation partnership (Articles 29 to 31) allow authorities to procure something that does not yet exist in finished form, and Article 68 allows life-cycle costing, the right basis for comparing a cheap hosted model with a self-hosted one whose exit cost is near zero. Article 72 governs modification of contracts: a model that the vendor replaces every quarter is a modification by any reasonable reading, so specify model updates as a contracted process with notice periods, evaluation windows, and rollback rights.
The EU model contractual AI clauses
The European Commission's Public Buyers Community has published model contractual AI clauses for pilot use, in a version for high-risk AI systems and a lighter version for other systems, both drafted against the Commission's proposal for the AI Act, before its adoption (18, European Commission, 2023). They are not a complete contract but a schedule of AI-specific terms covering data governance, documentation, transparency, human oversight, accuracy and robustness, and supplier cooperation. Their value to the architect is that they give the contract the same vocabulary as the law and the readiness checklist.
Evaluating vendors for AI Act compliance
Vendor assessment for AI is routinely done badly: the security questionnaire is reused, a question about "AI ethics" is appended, and the vendor answers yes to everything. The remedy is to ask for artefacts rather than assurances and to record the assessment in a form that can be re-run when the vendor changes its model or terms.
The vendor assessment schema
The schema records what the organisation has received, not what the vendor has claimed. A missing artefact is a finding, which either blocks the contract or becomes a recorded exception with an owner.
# vendors/assessments/model-provider-alpha.yaml
vendor_assessment:
vendor: Model Provider Alpha
offering: hosted general-purpose AI model, API access
assessed: 2026-09-15
ai_act_role_of_vendor: provider of a general-purpose AI model
our_role: deployer
artefacts_received:
technical_documentation: {received: true, reference: AI Act Article 53(1)(a)}
downstream_integration_information: {received: true, reference: AI Act Article 53(1)(b)}
copyright_policy: {received: true, reference: AI Act Article 53(1)(c)}
training_content_summary:
received: false
reference: AI Act Article 53(1)(d)
finding: requested, not yet supplied
contract_terms:
customer_data_used_for_training: false
data_processing_location: EU only
model_update_notice_days: 90
version_pinning_months: 12
serious_incident_notification_hours: 24
exit_assistance_months: 6
dora:
supports_critical_or_important_function: true
register_of_information_entry: ROI-2026-031
exit_strategy_reference: exit/model-provider-alpha.md
outcome: approved_with_exception
exception_owner: head_of_ai_platform
exception_expires: 2027-03-31
A model card is an artefact; a statement that the vendor "follows responsible AI principles" is not. The assessment is re-run on a cadence and whenever the gateway reports that the vendor has changed the model version.
Worked example: vendor due-diligence questionnaire
Illustrative example. Nordvik Region is procuring a benefits-triage system that orders incoming applications for caseworkers. The system falls under Annex III point 5(a) of the AI Act, so the supplier is the provider of a high-risk AI system and the Region its deployer. The questionnaire is issued with the tender documents; every question asks for an artefact and names the obligation it supports, which keeps the evaluation transparent and equal for all tenderers as Article 18 of Directive 2014/24/EU requires. The excerpt shows a selection of its 22 questions.
# Due-diligence questionnaire: benefits-triage system (tender NR-2026-117)
A statement without the artefact scores 0. Scoring: 0 = not supplied, 1 = partial,
2 = complete and current. A score of 0 on any [M] question excludes the tender.
| No. | Question | Artefact required | Obligation |
|-----|---------------------------------------------------|-----------------------------------------|------------------------|
| 1.1 | Confirm that you are the provider. [M] | Signed statement naming the entity | AI Act Art. 3(3), 16 |
| 1.2 | Supply the instructions for use. [M] | Instructions for use, current version | AI Act Art. 13 |
| 1.4 | Supply declared accuracy and known limitations. | Evaluation report with test population | AI Act Art. 13(3)(b) |
| 1.6 | Supply the EU declaration of conformity. [M] | Signed declaration | AI Act Art. 47 |
| 1.10| Describe the training, validation and test data. | Datasheet with sources, gaps and bias | AI Act Art. 10 |
| 2.1 | Describe the human oversight measures. [M] | Oversight design and override path | AI Act Art. 14 |
| 2.2 | Describe the logs and how we obtain them. [M] | Log schema and export procedure | AI Act Art. 12, 26(6) |
| 2.4 | Name the incident channel and response time. [M] | Incident procedure with contact, hours | AI Act Art. 26(5), 73 |
| 2.5 | State where personal data is processed. [M] | Draft data processing agreement | GDPR Art. 28, Ch. V |
| 2.8 | Describe how model updates are announced and rolled back. | Release procedure with notice | Dir. 2014/24/EU Art. 72|
| 2.9 | Supply input for our fundamental rights impact assessment. | Affected groups and known risks | AI Act Art. 27 |
Evaluation: [M] questions are pass or fail; the rest are weighted at 20 % of the
quality criterion under Art. 67.
Because every answer is an attachment, the panel scores evidence, and the same questions, re-asked at each major release, become the re-assessment that feeds the vendor assessment schema.
Lock-in and exit strategies
Lock-in with AI is subtler than with conventional software because much of it hides in artefacts the organisation created itself. Prompts are tuned to one model's quirks, embeddings in the vector index are meaningless to another provider's model, tool-calling formats differ, fine-tuned weights may not be exportable, and evaluation thresholds were calibrated on one model's behaviour.
Where lock-in hides and how to contain it
The gateway pattern, in which every model call passes through one platform-owned interface that can switch providers behind it, contains the most visible form of lock-in. The less visible forms need their own controls: prompts stored as versioned, model-agnostic configuration; an embedding model versioned independently of the generation model, so that re-indexing is a pipeline job rather than a crisis; evaluation sets that express business acceptance criteria rather than one model's achievable scores; and fine-tuning with reproducible methods and formats. The exit strategy is then a document in the repository that names each dependency, the replacement path, the estimated time, and the evidence that the path has been exercised. An exit strategy that has never been rehearsed is a hope.
Hansa Mutual's exit strategy for Model Provider Alpha, the file the assessment above points to, illustrates the form. Its generation model would be replaced by a self-hosted open-weight model or another EU-hosted provider in an estimated four weeks, with prompt tuning and tool-calling format as the lock-in; the embedding model needs no replacement because it was sourced independently; the moderation endpoint maps to the platform guardrail library in two weeks. During a switch, claims are handled under the manual triage runbook RB-CLM-07, within a maximum tolerable outage of 72 hours. The rehearsal on 2026-06-12 switched the claims retrieval route to the fallback model in staging, passed the evaluation at 0.93 against a threshold of 0.92, and required prompt changes in 11 templates, which is the evidence a supervisor will ask for under Article 28(8) of DORA.
DORA and third-party risk
For banks, insurers, and the other financial entities within its scope, Regulation (EU) 2022/2554, DORA, turns vendor management into a supervised discipline (3, European Union, 2022). Article 28 requires financial entities to manage ICT third-party risk within their ICT risk management, to maintain a register of information on all ICT contractual arrangements, and to assess before contracting whether an arrangement supports a critical or important function and what concentration risk it creates. Article 28(8) requires exit strategies for such services, and Article 30 lists the mandatory contractual provisions, including data location, service levels, incident assistance, cooperation with authorities, termination rights, and, for critical or important functions, unrestricted rights of access, inspection, and audit.
A hosted foundation model underpinning customer-facing processes is an ICT service, so a financial entity using it for a critical or important function must record it, assess it, contract for it, and be able to leave it. Chapter V of DORA also lets the European Supervisory Authorities designate critical ICT third-party providers, for which the hyperscale providers hosting most commercial models are obvious candidates. For a bank, therefore, the vendor assessment schema is the source of the register of information that the supervisor will ask for.
Open-weight versus proprietary models
The vocabulary of openness in AI is unreliable. Many models described as open have downloadable weights but restrictive licences, no training code, and no description of the training data. The Open Source Initiative's Open Source AI Definition requires the freedoms to use, study, modify, and share, together with sufficiently detailed information about the training data, the complete training and inference code, and the parameters (39, OSI, 2024). Measured against it, most open-weight models are not open-source AI, and the distinction matters when the organisation must reproduce, inspect, or defend a model's behaviour.
What the choice changes architecturally
The AI Act treats openness as partial relief. Article 53(2) exempts providers of general-purpose AI models released under a free and open-source licence from the documentation obligations of Article 53(1)(a) and (b), unless the model presents systemic risk; the copyright policy and training content summary remain. The relief is the provider's, however, not the downloading organisation's: deploying the model in a high-risk system still makes it a deployer, and modifying and rebranding it may make it a provider under Article 25.
The practical trade-off is between control and capability. Open-weight models can be self-hosted within European jurisdiction, answering the concerns of Chapter 6, can be evaluated without rate limits, and cannot be silently changed by a vendor; but they demand infrastructure, inference engineering, and security competence, and their licences need the same review as a commercial contract. Proprietary hosted models offer capability and convenience at the cost of dependency, transfer risk, and changes on the vendor's timetable. A mature programme uses both, behind a gateway, with an evaluation service able to prove when a cheaper or more sovereign model is good enough.
Contract clauses for data use, model updates, and audit rights
The clauses below are the ones architecture reviews most often find missing. Each is paired with the control that enforces it, because a clause with no corresponding control is a promise the organisation cannot verify.
| Clause | What it must state | Enforcing control |
|---|---|---|
| Customer data use | Prompts, completions, and uploads are not used for training; retention stated | Gateway logging; vendor attestation on file |
| Processing location | Jurisdictions of inference and storage; change requires notice | Gateway routing policy; DORA register entry |
| Model updates | Notice period, version pinning, evaluation window, rollback right | Gateway version pin; evaluation run on each change |
| Documentation delivery | Model card, instructions for use, Article 53 information per major version | Readiness checklist item; vendor assessment |
| Incident notification | Channel and maximum time to notify serious incidents | Incident runbook; monitored contact address |
| Audit and access rights | Right to audit and to obtain logs and evidence on request | DORA Article 30 wording; annual audit |
| Exit assistance | Duration and content of assistance, data return and deletion | Rehearsed exit strategy |
Architecture as Code (Chapter 12) argued that compliance obligations should be expressed as controls that pipelines can check (66, Nordqvist, 2025). Contract clauses are no different: the assessment schema records what was agreed, and the gateway, the evaluation service, and the evidence pipeline check that it is being honoured.
Across the usage modes
The contract form, and therefore the clauses worth fighting for, follow the usage mode defined in Chapter 2 (see the usage-mode matrix).
| Usage mode | Typical contract form | Clauses that matter most |
|---|---|---|
| Mode 0 Ambient AI | Existing software agreement, amended by the supplier | Change control for new AI features: notice, default-off, data-use and sub-processor terms |
| Mode 1 Conversational assistants | Enterprise SaaS licence | Data use, retention, location, administrative controls |
| Mode 2 Embedded workplace assistants | Add-on to an office suite agreement | Inherited data terms, permission model, audit log access |
| Mode 3 Agentic work tools | SaaS licence with consumption pricing | Data use for code and files, tool permissions, audit logs |
| Mode 4 Built AI applications | API terms or negotiated model-supply agreement | Updates and version pinning, Article 53 documentation, incidents, exit |
| Mode 5 Autonomous production agents | Negotiated platform and model contracts | As Mode 4, plus service levels, audit rights, and DORA Article 30 |
Mode 0 is the case procurement most often misses, because no purchase takes place: a supplier switches on an AI feature inside a licensed product, and data flows to a model under terms never assessed. The remedy is change control in every existing software agreement, requiring notice before AI features are enabled and a right to keep them disabled; for public authorities, Article 72 of Directive 2014/24/EU (9, European Union, 2014) is a further reason to provide for such changes. In Modes 1 to 3 the organisation buys a finished service on terms it can rarely rewrite, so its leverage lies in the licence tier and in verifying the administrative controls. In Modes 4 and 5 it may become a provider under Article 25 of the AI Act (1, European Union, 2024), which moves the update, documentation, and exit clauses to the top of the list.
Worked example: model-supplier contract clause checklist
Illustrative example. Hansa Mutual's procurement, legal, and architecture teams reviewed draft v3 of the master agreement with Model Provider Alpha against a checklist that applies the clause table above and adds the provisions of Article 30 of DORA. The excerpt shows selected rows from both parts; the legal function owns the legal assessment, and the checklist shows the controls that make each clause verifiable.
# Contract clause checklist: Model Provider Alpha, master agreement draft v3 (excerpt)
Reviewed: 2026-09-10 | Function supported: claims handling (critical or important)
Status key: OK = present and adequate | GAP = present, needs change | MISSING
| No. | Clause or provision | Ref. | Status | Enforcing control / action |
|-----|-------------------------------------------|-----------------|---------|------------------------------------------|
| A1 | No training on prompts, outputs, files | Sched. 2 §4 | OK | Attestation filed; gateway logs |
| A2 | Retention of prompts and outputs <= 30 d | Sched. 2 §5 | GAP | Draft says "limited period" |
| A4 | Update notice >= 90 days, eval window | §9.3 | GAP | Notice 30 days in draft |
| A6 | Training content summary | Art. 53(1)(d) | MISSING | Add delivery obligation before go-live |
| A9 | Information for authority requests <= 5 d | Art. 26(12) | MISSING | Combine with B7 |
| B7 | Cooperation with competent authorities | DORA 30(2)(g) | MISSING | Combine with A9 |
| B13 | Threat-led penetration testing | DORA 30(3)(d) | MISSING | Required if in TLPT scope |
| B14 | Unrestricted access, inspection, audit | DORA 30(3)(e) | GAP | Remote audit only; require on-site |
| B15 | Exit strategy and transition period | DORA 30(3)(f) | OK | Exit strategy rehearsed 2026-06-12 |
Outcome: not ready for signature. 4 MISSING, 8 GAP. Re-review after draft v4.
Register of information entry: ROI-2026-031
The AI-specific clauses and the DORA provisions sit in separate parts because they have different owners and sources, yet one contractual change often closes both, as A9 and B7 show. A clause the organisation cannot verify through its own gateway, evaluation service, or evidence pipeline is recorded as a gap even when the wording is acceptable.
Nordvik Region and Hansa Mutual
Nordvik Region buys under public procurement law: its questionnaire is issued under Directive 2014/24/EU as transposed (9, European Union, 2014), draws on the EU model contractual AI clauses, and must respect public-access duties, because tender documents may be requested by the public. Its leverage is the contract, and since switching suppliers is expensive, a weak exit clause becomes lock-in for years.
Hansa Mutual buys as a private group under financial-sector rules. Its exit strategy and checklist apply DORA Article 30 (3, European Union, 2022), and every AI provider appears in the register of information that Article 28(3) requires. One group contract is used by seven entities, however, so data-transfer terms differ: transfers to the United Kingdom and Switzerland rely on adequacy, and those entities apply their own outsourcing rules in place of DORA. Solvency II Article 49 keeps each insurance entity fully responsible for what it outsources (184, European Union, 2009). Nordvik's challenge is buying well under procurement law; Hansa's is one contract that must satisfy seven regimes.
Summary
Buying AI is buying an obligation. The AI Act assigns roles along the value chain, and Article 25 means an organisation can become a provider through its own architectural choices. The buyer should therefore insist on the artefacts the provider must produce, and the contract should name the channels through which incidents and authority requests flow.
Public authorities buy under Directive 2014/24/EU, whose principles turn the evaluation set into the lawful way to specify quality and whose rules on contract modification make model updates a process to be contracted. Financial entities add DORA, whose register of information, exit strategies, and contractual provisions make the vendor assessment a supervised artefact. Open-weight models offer control at the price of competence and infrastructure, proprietary models capability at the price of dependency, and a gateway, versioned prompts, independent embeddings, and rehearsed exit strategies keep the choice reversible.
A contract governs what a supplier owes, not what the organisation does with what it receives. Part III turns from buying AI to governing it, and Chapter 8 opens it with AI risk management and classification as code: the rules every proposed use case passes through before it receives resources, and again whenever its purpose, data or model changes.
Sources
- European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
- European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union. (3, European Union, 2022)
- European Parliament and Council of the European Union (2014). Directive 2014/24/EU on public procurement. Official Journal of the European Union. (9, European Union, 2014)
- European Commission (2025). The General-Purpose AI Code of Practice. European AI Office. (14, European Commission, 2025)
- European Commission (2023, updated 2025). EU model contractual AI clauses to pilot in procurements of AI. Public Buyers Community. (18, European Commission, 2023)
- Open Source Initiative (2024). The Open Source AI Definition, version 1.0. Open Source Initiative. (39, OSI, 2024)
- Nordqvist, G. Architecture as Code. Companion volume, aac.geon.se. (66, Nordqvist, 2025)
- European Parliament and Council of the European Union (2009). Directive 2009/138/EC on the taking-up and pursuit of the business of Insurance and Reinsurance (Solvency II) (recast). Official Journal of the European Union, L 335, 17 December 2009. (184, European Union, 2009)