AI vendor relationships are usually governed with a third-party risk policy that had the word AI inserted into it. The structure survives because the underlying logic looks the same: assess the supplier, tier the relationship, add clauses, monitor. The logic holds for a payroll processor and breaks for a model.
AI vendor arrangements break it because four imbalances exist in AI procurement that do not exist in ordinary supply. The vendor understands the system and you carry the regulatory obligation. The vendor changes the system and you discover it afterwards. Liability can transfer to you by operation of law without anyone signing anything. And the cost of leaving is set at signature or never.
A vendor AI policy earns its length by closing those four gaps and nothing else. Everything else in an AI vendor policy is procurement boilerplate that already exists elsewhere. The sections below take each asymmetry, the clause that closes it and the instrument behind it, and then deal with the part most guidance omits entirely, which is who inside your organisation is allowed to decide any of it. Teams that have not yet built the screening process underneath should start with how to govern vendor AI systems end to end.
Asymmetry One: The Vendor Understands the Model and You Carry the Obligation
Regulatory weight sits with the provider, and in an AI vendor relationship the provider is usually not you until it suddenly is.
Article 16 of the EU AI Act lists twelve obligations for providers of high-risk systems, running from (a) to (l): compliance with the Section 2 requirements, identification on the system or its packaging, a quality management system, documentation, logs, conformity assessment, a declaration of conformity, CE marking, registration, corrective action, demonstrating conformity on a reasoned request, and accessibility. Twelve duties, almost all of which require knowledge of how the system was built, and in an AI vendor arrangement that knowledge sits on the other side of the contract.
Bargaining before signature is contractual rather than statutory. Article 25(4) requires the provider and any third party supplying tools, services, components or processes to specify by written agreement the necessary information, capabilities, technical access and other assistance, based on the generally acknowledged state of the art. The Digital Omnibus amended that paragraph, adding that the AI Office may develop and recommend voluntary model contract terms, published free of charge.
ISO/IEC 42001 approaches the same gap through Annex A.10 on third-party and customer relationships, which carries three controls: A.10.2 on allocating responsibilities, A.10.3 on suppliers, and A.10.4 on customers. The supplier control asks for a process ensuring that the organisation’s use of supplier services, products and materials aligns with its own approach to responsible AI.
A second jurisdiction is closing the same gap with near-identical content. Colorado’s replacement statute, signed in May 2026 and effective 1 January 2027, requires developers to give deployers documentation covering intended and harmful uses, training data categories, known limitations, and appropriate-use and monitoring instructions. Drafting the evidence schedule once against both lists is cheaper than discovering the overlap in 2027.
An AI vendor policy has to state the evidence threshold rather than describe it. Which artefacts a vendor must produce before contract by tier, what counts as sufficient, and crucially who inside your organisation is competent to decide that what arrived is adequate. Procurement cannot assess a model card, which is why AI vendor acceptance needs a named technical signatory. The vendor questionnaire and the foundation model questions supply the asks; the policy supplies the acceptance authority.
Asymmetry Two: The Vendor Changes the System and You Learn Afterwards
Ordinary suppliers change slowly and tell you. AI vendors ship continuously and tell you in a changelog.
Timing is the asymmetry that defeats point-in-time assessment. An AI vendor assessment completed in March describes a system that no longer exists in June, and nothing in a standard third-party risk cycle catches that. Annual reassessment is calibrated to a world where the thing being assessed stays still.
Post-market monitoring makes this a live obligation rather than a preference. Article 72 requires providers to actively and systematically collect and analyse performance data across the lifecycle, and much of the data sits with whoever operates the runtime. Where a bought system is involved, the AI vendor holds it. The monitoring obligations and who holds the data are worth reading before drafting this clause, because the clause has to extract what the statute assumes you already have.
An AI vendor policy closes the gap with three commitments, and all three need a number. A notice period before material change, with material defined in the contract rather than left to the vendor. A right to re-test on notice, with the window stated. And a standstill right, meaning the ability to pin a version while you re-test, which is the one vendors resist and the one that makes the other two usable. Organisations already running change management for model updates internally should mirror those triggers outward into the contract.
Cadence should follow tier rather than the calendar. A supplier whose model sits behind a consequential decision earns a shorter notice period and a tighter re-test window than one powering an internal search box, and writing a single cadence for all suppliers guarantees it is wrong at both ends. Tiering already exists in most programmes for security; the AI vendor tier has to be set on what the model decides, not on how much the contract is worth. NIST’s prioritisation guidance points the same way, placing systems that interact directly with people, use sensitive personal data or affect individuals at higher initial priority.
Asymmetry Three: Liability Can Transfer to You Without a Signature
Liability transfer belongs at the centre of any AI vendor policy, and it is the asymmetry most third-party frameworks never mention.
Article 25(1) provides that a distributor, importer, deployer or other third party shall be considered a provider of a high-risk AI system where they do any of three things. Put their name or trademark on a high-risk system already placed on the market. Make a substantial modification to a high-risk system already placed on the market. Or modify the intended purpose of an AI system, including a general-purpose system, so that it becomes high-risk.
Read the consequence in Article 25(2) carefully, because it is a transfer rather than a sharing. The original provider “shall no longer be considered to be a provider of that specific AI system”. The twelve obligations in Article 16 do not get split. The obligations move.
Three ordinary commercial acts in an AI vendor relationship trigger that movement. White-labelling an AI vendor tool under your own brand. Fine-tuning or materially reconfiguring a bought model. Repurposing a general tool into a hiring, credit or education workflow. None of those decisions normally reaches legal, and none of them feels like assuming a regulatory role at the moment it is taken. The same deployer and operator split appears in DIFC Regulation 10, which puts the duties on the party authorising or benefiting from an autonomous system rather than the party that built it.
Article 25(2) does give the new provider something back, and the Digital Omnibus strengthened it. The initial provider must cooperate closely, including by making available technical documentation sufficient to assess compliance with Article 16, informing the new provider about known limitations and failure modes, and granting targeted technical access for testing and validation.
AI vendor diligence then has to hunt for the carve-out, which is drafted as an exception to the whole paragraph. Article 25(2) does not apply where the initial provider has clearly specified that its system is not to be changed into a high-risk AI system.
What that exception actually removes is read two ways, and the difference is worth a great deal of money. The Commission’s own reference describes it as switching off the cooperation duty, which leaves you holding Article 16 with no right to the evidence that discharges it. A second reading takes the exception at face value, so that the paragraph as a whole falls away and the initial provider never stops being the provider. No authority has settled which reading is right, and third-party AI contracts are being signed against both. Either way the practical instruction for an AI vendor policy is the same: find out before signature whether the supplier has made that specification, because it changes the risk of every downstream modification.
An AI vendor policy closes this asymmetry in two moves. The clause names which roles may perform any act in Article 25(1), and makes those acts require approval rather than discretion. And it requires diligence to identify whether the supplier has made the Article 25(2) specification, because that single sentence in a vendor’s terms changes the risk of every downstream modification. Whether the system is high-risk at all is settled first, by the Annex III classification route.
Asymmetry Four: Exit Is Priced at Signature or Not at All
Exit from a model supplier is harder than exit from a software supplier, and the difference is not technical.
Three things complicate exit. Fine-tuning work and prompt assets built against one vendor’s behaviour rarely transfer. Historical outputs may need to remain explainable after the relationship ends, because the duty to explain a decision outlives the contract that produced it. And evidence obligations persist, so logs and documentation you relied on for compliance have to survive termination.
Annex A.10.2 on allocating responsibilities across the AI system life cycle is the control that covers this, and lifecycle includes the end of it. Allocation that stops at go-live is incomplete allocation, and most AI vendor policies stop there. Article 26 points the same way from the other direction. Deployer log retention runs to at least six months for logs under the deployer’s control, and nothing in that duty is expressed to end when a supplier contract does, which is a reading worth testing with counsel rather than assuming.
Four exit commitments belong in an AI vendor policy because they cost nothing before signature and are unobtainable afterwards. Return or deletion of your data and of artefacts derived from it, with the distinction spelled out. Continued access to logs and documentation for a stated period after termination. Transition assistance, defined in days rather than described as reasonable. And an agreed position on fine-tuned weights, which is the item most contracts leave silent and most disputes later turn on.
| Asymmetry | What the policy must commit to | Backing instrument |
| Information | Evidence threshold by tier, and who may accept it | Article 25(4); ISO/IEC 42001 A.10.3 |
| Timing | Notice period, re-test right, standstill right | Article 72; ISO/IEC 42001 A.10.2 |
| Liability | Approval gate on the three Article 25(1) acts | Article 25(1) and 25(2); Article 16 |
| Exit | Data and artefact return, log access period, transition days | ISO/IEC 42001 A.10.2 |
What the Policy Must Assign, Rather Than Describe
Guidance on vendor AI is plentiful on process and almost silent on authority, which is why so many of these documents read well and decide nothing.
An AI vendor policy is separated from a guide by four allocations. Who may approve a vendor at each tier, named by role, with the highest tier reserved to a body rather than an individual. Who may sign a contract that omits the required AI clauses, which should be a shorter list than people expect. Who may grant an exception, and for how long, because a waiver without an expiry date is an amendment. And who accepts that vendor evidence is adequate, which is a technical judgment wearing a procurement badge.
Delegation of approval authority deserves its own line. A policy that assigns approval to a role without saying whether that role may delegate will be delegated informally, and the record will show the wrong name against the decision. State whether delegation is permitted, to whom, and whether it survives absence.
Exceptions need a register rather than a mailbox. Every waiver should carry the vendor, the clause waived, the compensating control, the approver and the expiry, and the register should be reviewed on a cycle that is shorter than the shortest expiry on it. An exception process without a register produces a policy whose real content is undocumented, since the waivers describe what the organisation actually does.
One more allocation is specific to AI and routinely missed. Someone has to own the question of whether a purchased product contains AI at all. Vendors add model-backed features to existing products continuously, and a contract signed for a non-AI tool becomes an AI vendor relationship without any procurement event occurring. Without an owner for that question, the register silently goes stale, which is why the system inventory and the vendor register have to be the same list rather than two.
The parent document above this one is the AI governance policy, which allocates the authority this policy spends, and the thresholds it spends against live in the risk management policy. Where the terms in all three are defined differently by different instruments, the lexicon resolves which definition applies.
AI vendor decisions are only defensible if the approval, the evidence behind it and the date are retrievable against the vendor and the system together. govern365.ai holds the tier, the accepted evidence, the approver and the exception expiry on one record, so that a question about a supplier two years from now does not become an email search. Teams standing this up alongside an internal approval chain can see how govern365.ai runs the workflow, and the wider platform is where the vendor register and the system register stop being separate spreadsheets.
Questions About AI Vendor and Third-Party Policy
What Should an AI Vendor Policy Cover That a Standard Third-Party Policy Does Not?
Four things. An evidence threshold with a named acceptance authority, because procurement cannot judge model documentation. A notice and re-test right covering vendor-side changes, since models change continuously. An approval gate on the acts in Article 25(1) that would make your organisation the provider. And exit terms covering data, derived artefacts, log access and fine-tuned weights, which are unobtainable after signature.
When Does Buying AI Make You the Provider?
Article 25(1) treats a distributor, importer, deployer or other third party as the provider of a high-risk AI system where they put their name or trademark on a high-risk system already on the market, make a substantial modification to such a system, or modify the intended purpose of an AI system, including a general-purpose system, so that it becomes high-risk.
Does the Original Vendor Stay Liable After That?
No. Article 25(2) states that the original provider shall no longer be considered to be a provider of that specific AI system. The twelve obligations in Article 16 transfer rather than being shared. The original provider owes cooperation, not continued responsibility.
What Must the Original Vendor Hand Over?
Under Article 25(2) as amended, the initial provider must cooperate closely with the new provider, including by making available technical documentation sufficient to assess compliance with Article 16, informing them of known limitations and failure modes, and providing targeted technical access for testing and validation. Article 25(2) does not apply where the initial provider has clearly specified that its system is not to be changed into a high-risk AI system. Whether that removes only the cooperation duty or preserves the original provider’s status is read both ways and remains unsettled.
Which ISO/IEC 42001 Controls Cover Vendors?
Annex A.10 on third-party and customer relationships, which holds three controls: A.10.2 on allocating responsibilities across the AI system life cycle, A.10.3 on suppliers, and A.10.4 on customers. A.10 is one of nine Annex A objectives running A.2 to A.10, across 38 reference controls in total.
How Often Should Vendor AI Be Reassessed?
Calendar-based reassessment alone does not work for systems that change between reviews. The policy should bind reassessment to events rather than dates: a vendor notice of material change, a change in how your organisation uses the system, and a change in the regulatory position. A contractual notice period for material change is what makes the first of those three observable at all.
Who Should Approve a High-Tier AI Vendor?
A body rather than an individual, with the role named in the policy and delegation addressed explicitly. The approval record should carry the tier, the evidence accepted, the approver and any exception with its expiry. Exceptions without an expiry date function as permanent amendments to the policy.
Does This Policy Replace a Vendor Risk Questionnaire?
An AI vendor policy does not replace it. The questionnaire gathers the evidence, and the policy states what evidence is required at each tier, who may accept it, and what happens when it is incomplete. A questionnaire without an acceptance authority produces third-party AI files that nobody has formally judged, which is a gap an auditor can find without reading a single answer.
