A lifecycle view of governing AI vendors and model providers, complementing the risk lens with the management of the relationship itself.
Executive summary
- Vendor governance is broader than a single risk assessment. It spans the whole relationship, from how a vendor is chosen to how the enterprise would leave it.
- Contracts should secure the things that matter for AI: notice of material model change, limits on training use of enterprise data, security commitments, audit rights, and a workable exit.
- Concentration on a small number of AI providers is itself a governance concern, because heavy dependence on one provider becomes a strategic risk.
- A clean exit and portability are what keep an enterprise from being locked in, so the ability to leave should be designed in rather than discovered when it is needed.
- Vendor governance and third-party AI risk management are complementary: the risk discipline assesses and monitors, while vendor governance manages the relationship that carries the risk.
Source basis: ISO/IEC 27036, Information security for supplier relationships; APRA Prudential Standard CPS 230 Operational Risk Management; ISO 37500:2014, Guidance on outsourcing. Full citations and scope notes appear below.
Vendor governance and third-party risk
AI vendor governance and third-party AI risk management are closely related and often confused, so it helps to distinguish them. Third-party AI risk management is the discipline of identifying, assessing, and monitoring the risk that a vendor AI carries. Vendor governance is the broader management of the relationship itself, across its whole life: how the vendor is selected, how the relationship is contracted, how it is managed over time, how concentration is controlled, and how the enterprise would exit. The risk discipline assesses the risk; the governance discipline manages the relationship that carries it.
The two connect at every stage. Selection draws on the risk assessment to choose a vendor whose AI the enterprise can govern. Contracting secures the terms that make risk management possible, such as change notification and audit rights. Ongoing management uses the monitoring the risk discipline performs. And exit is both a risk mitigation and a relationship decision. Vendor governance provides the frame of the relationship, within which third-party AI risk management does its work, and the two are strongest when designed together.
The reason to treat vendor governance as its own discipline is that the relationship raises questions the risk assessment alone does not answer. Whether to depend on a vendor at all, how much to concentrate on one, what to secure in the contract, and how to retain the ability to leave are governance decisions about the relationship, not just assessments of its risk. An enterprise that manages only the risk of vendor AI, without governing the relationship, may find itself well informed about a dependence it can no longer escape, which is knowledge without control.
The vendor relationship lifecycle
AI vendor governance is best understood as a lifecycle, because the relationship with a vendor passes through distinct stages, each needing its own governance. The enterprise selects a vendor, contracts with it, onboards its AI, manages the relationship over time, and eventually reviews or exits it. Governance attention should be designed for each stage rather than concentrated at contract signing, which is the common but mistaken pattern where all the scrutiny happens once and the relationship then runs unmanaged until something goes wrong.
The lifecycle view matters because the risk and the governance needs change across the relationship. At selection, the governance question is whether to depend on this vendor at all. At contracting, it is what to secure in the terms. During the relationship, it is how the vendor AI is actually behaving and being used. At exit, it is how to leave cleanly. Governance that treats the relationship as a single event at contracting misses the stages where much of the real risk emerges, particularly the ongoing management stage where the vendor AI changes and the enterprise dependence deepens.
The steps below show the vendor governance lifecycle. Its value is that it makes explicit that vendor governance is a continuous responsibility, not a procurement transaction. Each stage produces governance artefacts, the selection rationale, the contract terms, the onboarding record, the monitoring results, and the exit plan, that together document the relationship and its governance. An enterprise that governs across the lifecycle can account for its vendor relationships; one that governs only at signing has a contract and little else.
Governance stages across the vendor relationship
Governance attention should be designed for each stage, not concentrated only at contract signing.
Screen for AI data handling, security, behaviour, and fit.
Secure change notice, data terms, audit rights, and exit.
Configure controls and document intended use.
Track model change, service, incidents, and concentration.
Reassess on renewal, and exit cleanly when needed.
Selection criteria
Selection is where vendor governance begins, and choosing well is far cheaper than governing a poor choice later. Selection criteria for AI vendors should extend beyond the usual considerations of price, functionality, and reputation to the governability of the vendor AI: how the vendor handles data, whether it is transparent about model behaviour and change, what security it offers, and whether its terms allow the enterprise to govern the AI in its own environment. A vendor whose AI cannot be governed, however capable, is a poor choice for an enterprise that takes governance seriously.
Selection should weigh the ability to exit as well as the appeal of entering. A vendor that is easy to adopt but hard to leave creates a lock in that becomes a governance problem later, when the enterprise wants to change but cannot. Considering portability and exit at selection, before commitment, is what preserves the enterprise freedom of action. The most attractive vendor at the point of selection is not always the best governance choice if adopting it means surrendering the ability to leave, which is a consideration that selection driven by features alone tends to overlook.
Selection also sets the pattern for concentration, because each selection either reinforces or diversifies the enterprise dependence on particular providers. A selection that adds to an already heavy dependence on one provider increases concentration risk, even if the individual choice is sound, so selection should be made with awareness of the aggregate picture. This is where selection connects to the strategic question of how much to depend on any one vendor, which is a governance decision that individual selections, each reasonable on its own, can quietly determine if made without regard to the whole.
Contracting for AI
The contract is where vendor governance secures the terms that make everything else possible, and AI contracts need provisions that general vendor contracts do not. The most important are notice of material model change, so the enterprise can reassess when the vendor alters the AI, limits on the use of enterprise data for training, so the enterprise does not lose control of its confidential information, security commitments appropriate to the sensitivity of the data, audit rights that let the enterprise verify the vendor claims, and a workable exit that lets the enterprise leave with its data and without undue penalty.
These terms are worth negotiating hard, because they are the levers the enterprise will need throughout the relationship, and they are far harder to obtain after signing than before. A contract that lacks change notification leaves the enterprise blind to model updates. One that permits training on enterprise data may expose confidential information irreversibly. One with no exit provision creates lock in. The moment of contracting, when the enterprise has the most leverage, is when these protections must be secured, because a vendor has little incentive to grant them once the enterprise is committed.
Contracts should also allocate responsibility clearly, particularly where regulation places obligations on the enterprise as a deployer of vendor AI. The EU AI Act, for example, places duties on deployers of high risk AI that the enterprise must satisfy regardless of the vendor, so the contract should ensure the vendor provides what the enterprise needs to meet its own obligations. A contract that leaves responsibility ambiguous, or assumes the vendor carries obligations that in fact fall on the enterprise, sets up a compliance gap that surfaces when a regulator asks who was responsible.
Onboarding and intended use
Onboarding is where a contracted vendor AI is brought into the enterprise environment and governance, and doing it well prevents the vendor AI from becoming an ungoverned dependency. Onboarding configures the controls that will govern the vendor AI, documents the intended use so that later drift can be detected, and connects the vendor AI to the enterprise monitoring and risk register. A vendor AI that is contracted but not properly onboarded can end up running in the enterprise without being governed, which defeats the purpose of the careful selection and contracting that preceded it.
Documenting intended use at onboarding is particularly important, because it becomes the reference against which later change is judged. The enterprise records what the vendor AI is for, what data it will process, what it is permitted to do, and what it is not, so that if the use expands or the vendor changes the AI, the enterprise can see the drift from what was agreed. Without this record, the vendor AI use can expand quietly beyond what was assessed and contracted, carrying risk that the enterprise no longer recognises because it has no baseline to compare against.
Onboarding also establishes the enterprise controls over the vendor AI, which is where vendor governance connects to runtime governance. Where the enterprise can enforce its own controls over how a vendor AI is used, what data reaches it, and what a vendor agent can do in the enterprise environment, onboarding sets these controls up. This is what lets the enterprise govern the use of vendor AI rather than relying on the vendor, and it is far easier to establish at onboarding than to retrofit later once the vendor AI is embedded in the enterprise operations.
Managing the relationship over time
The ongoing management stage is the longest and most neglected part of vendor governance, and it is where much of the real risk emerges. Over the life of the relationship, the vendor AI changes, the enterprise use of it grows, the vendor security and financial health may shift, and the dependence deepens. Managing the relationship means watching all of these: monitoring the vendor AI behaviour and service, tracking how the enterprise use is expanding, staying aware of the vendor’s own health and direction, and reassessing the relationship as these change.
Ongoing management should be proportionate to the materiality of the relationship, with the most material vendor relationships managed most actively. Operational risk rules such as APRA CPS 230 require regulated entities to manage material service providers throughout the relationship, not only at contracting, and this expectation captures exactly the right principle: that a material dependence deserves active ongoing management. A vendor relationship that is material to the enterprise operations should have an owner who actively manages it, rather than being left to run until renewal.
Ongoing management also maintains the enterprise leverage, which erodes over time if the relationship is not managed. An enterprise that manages a vendor relationship actively, tracking performance against the contract and maintaining alternatives, retains the ability to hold the vendor to account and to leave if necessary. One that lets the relationship run unmanaged finds its leverage gone when it needs it, deeply dependent on a vendor it has not held to its commitments and cannot easily leave. Active management is what keeps a vendor relationship a governed dependence rather than a drift into lock in.
Concentration risk
Concentration is the vendor governance risk that grows quietly and can become strategic, and it deserves deliberate attention. As enterprises standardise on a small number of AI providers, dependence on any one deepens, until a large part of the enterprise AI capability rests on a single provider. A problem with that provider, a service failure, a change in terms, a change in behaviour, or a commercial decision, then affects the enterprise broadly at once. Concentration turns a vendor problem into an enterprise problem, which is what makes it a strategic risk rather than an operational one.
Concentration accumulates through reasonable decisions, which is why it must be watched at the aggregate level. Each choice to use the leading provider is individually sensible, because leading providers are capable and well supported, but the sum of these choices is a concentration that no single decision intended. An enterprise that watches only individual vendor decisions, without tracking the aggregate concentration, will find itself heavily dependent on one provider without ever having decided to be, which is how concentration becomes a hidden strategic vulnerability.
Managing concentration means tracking it, avoiding designs that lock the enterprise irretrievably to one provider, and maintaining enough portability to move if necessary. This does not mean spreading AI use thinly across many providers, which sacrifices the benefits of standardisation, but maintaining awareness and options. The stack below lists the concentration risks vendor governance should watch. The goal is a dependence that is deliberate and reversible rather than accidental and permanent, so that a reasonable preference for a good provider does not become a strategic trap.
What concentration to watch
Concentration accumulates through reasonable decisions, so it must be watched at the aggregate level, not just per decision.
Exit and portability
The ability to exit a vendor relationship is what keeps an enterprise from being trapped, and it should be designed into the relationship from the start rather than discovered when it is needed. Exit planning asks how the enterprise would leave a vendor: how it would retrieve its data, how it would replace the vendor AI, and how it would manage the transition without disrupting critical operations. A vendor relationship with no exit plan is one the enterprise cannot leave without improvising under pressure, which is the worst time to work out how to exit.
Portability is the technical foundation of exit, and it should be considered at selection and secured at contracting. An enterprise that builds its AI use in a way that is portable, avoiding deep dependence on the specific features and formats of one vendor, retains the ability to move. One that builds in a way that is tightly coupled to a single vendor finds that even with a contractual right to exit, the practical cost of moving is prohibitive. Portability is what turns the right to exit into a real option rather than a theoretical one, and it is far easier to preserve than to recover.
Exit is also a governance discipline in itself, because the ability to leave is what gives the enterprise leverage throughout the relationship. A vendor that knows the enterprise can leave has an incentive to serve it well and to honour its commitments, while a vendor that knows the enterprise is locked in has less. Maintaining a credible ability to exit, through portability and exit planning, therefore benefits the enterprise not only when it actually exits but throughout the relationship, by keeping the vendor accountable. Exit capability is a source of governance power, not just a contingency.
Governance activities by stage
Vendor governance involves distinct activities at each stage of the lifecycle, and setting them out helps an enterprise see whether its vendor governance is complete or concentrated at one point. At selection, the activity is assessment and choice. At contracting, it is securing terms. At onboarding, it is configuration and documentation. During management, it is monitoring and reassessment. At exit, it is transition. Each activity produces evidence, and together they document a governed relationship rather than a signed contract followed by silence.
The matrix below sets out the governance activities and evidence by stage. Laying them out this way reveals the common pattern where governance is heavy at contracting and thin everywhere else, which leaves the relationship ungoverned for most of its life. A complete vendor governance has activity and evidence at every stage, so that the enterprise can account for how it selected, contracted, onboarded, managed, and would exit each material vendor relationship, which is what a regulator or an auditor examining vendor governance would expect to see.
The activities also connect vendor governance to the wider governance system. Selection connects to procurement, contracting to legal, onboarding to the risk register, management to operational risk, and exit to resilience. Vendor governance is not a standalone discipline but the coordination of these functions across the relationship, which is why it needs an owner who can bring them together. A vendor relationship governed by each function in isolation, with no one owning the whole, tends to have gaps at the boundaries, which is where vendor governance failures often occur.
Governance activity and evidence across the lifecycle
A complete vendor governance has activity and evidence at every stage, not just at contracting.
Vendor agents and delegated authority
Vendor AI that can take actions, rather than only produce outputs, raises vendor governance to a higher level of concern, because the enterprise is now allowing a third-party system to act within its environment. A vendor agent that can call tools, access systems, and take actions carries the authority the enterprise grants it, and governing this means governing the authority, not only the relationship. The enterprise must decide what a vendor agent may do, ensure those limits are enforced, and be able to see and stop what the agent does, which is a deeper governance than for a vendor that only provides outputs.
The key governance choice is who controls the vendor agent’s authority within the enterprise environment. An arrangement where the vendor controls what its agent can do, with the enterprise trusting the vendor to bound it, is a significant risk, because the enterprise is exposed to actions taken by a system it does not control. An arrangement where the enterprise enforces the agent boundaries itself, in its own environment, keeps control where it belongs. Vendor governance should prefer the latter, retaining the enterprise ability to govern what any agent, including a vendor agent, does in its systems.
This connects vendor governance to runtime governance, because controlling a vendor agent’s authority means enforcing and recording what it does at runtime. Where the enterprise governs vendor agent actions in its environment, the vendor relationship can extend to agents safely, because the enterprise retains control regardless of the vendor. Where the enterprise cedes this control to the vendor, it is granting a third party the authority to act in its systems on terms it does not fully control, which is a vendor governance decision that deserves the highest level of scrutiny.
Common vendor governance failures
The most common vendor governance failure is governance concentrated at contracting, where the enterprise scrutinises a vendor carefully at signing and then lets the relationship run unmanaged. This leaves the relationship ungoverned for most of its life, precisely when the vendor AI changes and the dependence deepens. The remedy is the lifecycle discipline, with governance activity and evidence at every stage, so that the relationship is managed continuously rather than assessed once.
A second failure is silent concentration, where the enterprise accumulates heavy dependence on one provider through reasonable individual decisions, without tracking the aggregate. The remedy is to watch concentration at the enterprise level and manage it deliberately. A third is the absence of an exit, where the enterprise has no plan or ability to leave a vendor, discovering the lock in only when it wants to move. The remedy is to design exit and portability from the start, treating the ability to leave as a source of leverage throughout the relationship.
A fourth failure is ceding control of vendor agent’s authority, granting a vendor agent broad authority in the enterprise environment controlled by the vendor rather than the enterprise. The remedy is to retain enterprise control over what vendor AI does in its systems, enforcing the boundaries itself. Each of these failures reflects treating vendor governance as a procurement transaction rather than the ongoing governance of a relationship and a dependence, and the remedy in each case is to govern the relationship across its whole life, with the enterprise retaining control and the ability to leave.
Conclusion: the Helixar perspective
The Helixar research perspective is that vendor governance is stronger when the enterprise can see and control how vendor AI is used in practice. A contract sets terms, but only visibility of the actual use, what data flows to a vendor AI, how it behaves, and what a vendor agent does, lets the enterprise hold a vendor to its commitments and govern the dependence. When operational policy governance provides this visibility and control, vendor governance turns contract terms into something the enterprise can actually verify and enforce.
This matters most for vendor agents, where the enterprise is allowing a third-party system to act in its environment. The ability to enforce and record what a vendor agent does, in the enterprise’s own environment, is what lets the vendor relationship extend to agents without ceding control to the vendor. An enterprise that governs vendor agent actions at runtime retains control regardless of the vendor, which is the difference between a governed dependence and a trust based one.
Read alongside the third-party risk and operational risk reports, this report shows how the enterprise governs its AI vendor relationships across their whole life: selecting for governability and portability, contracting for the terms that matter, managing the relationship actively, watching concentration, and retaining the ability to exit. Vendor governance manages the relationship that third-party risk management assesses, and the two together keep dependence on vendor AI under control. For the whole discipline these reports support, the Enterprise AI Governance Framework is the anchor.
Enterprise checklist
- Govern the whole vendor lifecycle, not just the contract signing.
- Select for governability and portability, with an eye on concentration, not only features and price.
- Contract for change notice, data protection, audit rights, and a workable exit.
- Document intended use at onboarding, and configure enterprise controls over the vendor AI.
- Manage material relationships actively, and track provider concentration at the aggregate.
- Design exit and portability from the start, treating exit capability as leverage.
- For vendor agents, retain enterprise control of what they can do in your environment.
Frequently asked questions
How is vendor governance different from third-party AI risk management?
What contract terms matter most for AI vendors?
Why does provider concentration matter?
Why plan for exit before we need it?
How should we govern a vendor agent?
Method and source use
This report is a Helixar synthesis of the cited public standards and guidance. Named sources are linked at first mention and listed below. Unless a cited source is identified, maturity levels, diagrams, allocations, scores, and operating models are illustrative Helixar reference models, not survey findings or legal requirements. Organisations should verify current obligations with the authoritative source and qualified advisers.
References
- ISO/IEC 27036, Information security for supplier relationships
- APRA Prudential Standard CPS 230 Operational Risk Management
- ISO 37500:2014, Guidance on outsourcing
- Regulation (EU) 2024/1689, Artificial Intelligence Act
- NIST AI Risk Management Framework (AI RMF 1.0)
- Helixar research: Third-Party AI Risk Management
- Helixar research: Enterprise AI Governance Framework