Governing the AI risk you buy, not only the AI you build, across the whole life of the third-party relationship.
Executive summary
- A large and growing share of enterprise AI risk is not built in house. It arrives through vendor products, AI features switched on inside existing tools, and model providers accessed through APIs.
- Due diligence must cover AI specific concerns: how the vendor handles enterprise data, whether it uses data for training, how the model behaves under adversarial input, and how change is notified.
- The most overlooked third-party AI risk is the embedded feature, an AI capability switched on inside a tool the enterprise already uses, which can enter without any procurement or assessment.
- Third-party AI risk is ongoing, not a one time check. Models change, terms change, and a low risk feature can become higher risk when it gains the ability to act, so monitoring matters as much as onboarding.
- Concentration on a small number of providers is itself a risk, and the enterprise needs contingency options rather than silent dependence on a single model or vendor.
Source basis: ISO/IEC 27036, Information security for supplier relationships; APRA Prudential Standard CPS 230 Operational Risk Management; NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management. Full citations and scope notes appear below.
The AI risk you buy, not build
Much of the attention on AI governance focuses on the AI an enterprise builds, but a large and growing share of AI risk is bought rather than built. It arrives through vendor products that embed AI, through AI features switched on inside the SaaS tools the enterprise already uses, and through model providers accessed by API. This bought AI carries real risk, and because it enters through procurement and product features rather than through an internal build, it often escapes the governance applied to systems the enterprise develops itself.
The governance gap for bought AI is dangerous precisely because it is easy to miss. An internally built AI system goes through some form of review because someone builds it deliberately, but an AI feature that a vendor enables in an existing tool can arrive with no review at all, appearing as a product update rather than a new system. The enterprise ends up using AI it never assessed, processing its data through models it never evaluated, and carrying risks it never recorded, all because the AI came in through a channel governance did not watch.
Third-party AI risk management extends governance to this bought AI, treating it with the same seriousness as built AI. It asks the same questions, about data, behaviour, security, and impact, of a vendor model as of an internal one, and it brings vendor AI into the risk register and the governance cycle. The principle is that governance should follow the use of AI and the impact of the workflow, regardless of who built the model, because a risk is no less real for having been bought rather than built.
Where third-party AI risk enters
Third-party AI risk enters through several channels, and an enterprise that watches only one will miss the others. The first is the dedicated AI vendor product, bought deliberately, which is the channel most likely to receive assessment. The second is the model provider accessed by API, where the enterprise builds on a foundation model it does not control. The third, and most overlooked, is the embedded feature, an AI capability switched on inside a SaaS tool the enterprise already uses, which can arrive without any procurement decision at all.
Each channel carries a different risk profile and a different likelihood of being governed. The dedicated vendor product is usually assessed, because buying it is a decision. The model provider relationship is often assessed at the point of building on it, though the assessment may not be repeated as the model changes. The embedded feature is frequently not assessed at all, because it does not present as a decision, which makes it the channel where ungoverned third-party AI risk most often accumulates. Open source models and components form a further channel, entering through engineering choices rather than procurement and carrying supply chain concerns of their own. The bars below show an illustrative view of where this risk concentrates.
Understanding the channels is the first step to governing them, because each needs a different approach to discovery. Dedicated products are found through procurement records. Model provider relationships are found through architecture and integration records. Embedded features are the hardest to find, because they require watching the AI capabilities of the tools the enterprise already uses and noticing when a vendor enables a new one. An enterprise that does not actively watch for embedded features will be surprised by how much vendor AI is processing its data without its knowledge.
Illustrative concentration of third-party AI risk
Where bought AI risk enters, and how likely each channel is to be governed. The embedded feature is the most overlooked.
The due diligence questions
Due diligence for third-party AI extends vendor assessment to AI specific concerns that a general security or procurement review would not cover. The core questions are about data, behaviour, security, and change. How does the vendor handle enterprise data, and is it used to train models. How does the model behave, including under adversarial input such as prompt injection. What security controls protect the model and the data. And how will the vendor notify the enterprise of material changes to the model or its behaviour, which is where many later surprises originate.
These questions should be asked systematically, using a due diligence questionnaire tailored to AI rather than a generic vendor form. Supplier relationship guidance such as ISO/IEC 27036 provides a baseline for third-party security, and AI specific concerns extend it. The matrix below sets out the core due diligence areas and what each seeks to establish. Asking these questions before onboarding is far cheaper than discovering the answers after a data exposure or a behaviour that the enterprise did not anticipate.
Due diligence should also be proportionate to the risk of the use case, not uniform across all vendors. A vendor AI feature used for low risk internal drafting warrants lighter diligence than one embedded in a customer facing decision or one that can take actions on the enterprise’s behalf. Matching the depth of due diligence to the risk keeps it feasible across the many vendor AI relationships an enterprise has, while concentrating scrutiny where the impact of a vendor failure would be greatest. Uniform diligence either overburdens low risk relationships or underserves high risk ones.
Core areas of AI vendor due diligence
AI specific questions that extend general vendor assessment. Depth should be proportionate to the risk of the use case.
Data handling and training use
Data handling is the first concern with any third-party AI, because using a vendor model usually means sending enterprise data to it. The enterprise needs to know where its data goes, how it is stored, how long it is retained, who can access it, and crucially whether it is used to train the vendor models. Training use is a particular concern, because data used to train a model can influence its outputs to others and is difficult to remove, so an enterprise that unknowingly allows its confidential data to be used for training may lose control of it in ways it cannot reverse.
The terms that govern data handling vary widely between vendors and between service tiers, and the enterprise must read them rather than assume. Some vendors do not train on enterprise data by default, some do unless the enterprise opts out, and some offer stronger protections only on higher tiers. The difference matters enormously for confidential and personal data, and an enterprise that assumes protection it does not actually have may be exposing sensitive information through a vendor feature it never examined. Reading and negotiating data terms is core third-party AI diligence.
Data handling also engages privacy law, because enterprise data sent to a vendor model often includes personal information. This brings third-party AI risk into contact with privacy obligations around cross border transfer, purpose limitation, and processor arrangements. An enterprise operating in Australia and New Zealand should read vendor AI data handling against its privacy obligations, treating the privacy and AI risk questions together, because a vendor AI arrangement that is acceptable on AI grounds may still breach privacy law if the data handling does not meet the required standard.
Model behaviour and security
The behaviour of a vendor model matters because the enterprise inherits it. If a vendor model is prone to confabulation, susceptible to prompt injection, or biased in ways relevant to the use case, those weaknesses become the enterprise weaknesses when it relies on the model. Due diligence should therefore seek evidence of how the model behaves, including under adversarial conditions, rather than accepting a general assurance that it is safe. A vendor that can show testing for the relevant failure modes offers more confidence than one that offers only marketing claims.
Security of the vendor model and its infrastructure is equally important, because a compromise of the vendor can become a compromise of the enterprise. The enterprise should understand how the vendor protects the model, the data, and the infrastructure, and whether it holds recognised security certifications. This is standard third-party security diligence applied to AI, and it should not be relaxed because the vendor is an AI vendor. If anything, the novelty and rapid change of AI services argues for more scrutiny of their security, not less.
The enterprise should also understand the vendor supply chain, because a vendor AI is often built on other vendors models and services. A model provider may itself depend on infrastructure and components from others, and a risk in that deeper supply chain can reach the enterprise through the vendor. Guidance on supply chain risk such as the NIST supply chain risk management publications applies here, extended for AI. An enterprise that assesses only its direct vendor, without understanding what that vendor depends on, has visibility of one layer of a supply chain that may be several deep.
Change notification and model updates
One of the distinctive risks of third-party AI is that the model can change under the enterprise without notice, altering behaviour the enterprise had come to rely on. A vendor may update a model to improve it in general while changing how it behaves on the enterprise specific use case, and if the enterprise is not notified, it may not discover the change until it causes a problem. This makes change notification a critical term in any AI vendor relationship, and its absence a significant risk that many enterprises do not think to address.
Contractual change notification gives the enterprise the chance to reassess when a model changes, which is essential because a model update can invalidate the due diligence and testing the enterprise did at onboarding. A model that was assessed as behaving acceptably may behave differently after an update, so the enterprise needs to know when an update happens in order to decide whether to reassess. Without notification, the enterprise assessment slowly becomes stale as the model evolves, describing a version of the model that no longer exists.
The enterprise should also monitor for behaviour change even where notification exists, because notification may be incomplete or delayed. Monitoring the vendor AI outputs for shifts in behaviour, quality, or error patterns can detect a change that was not notified or whose significance the vendor did not appreciate. This combination of contractual notification and independent monitoring is what keeps the enterprise aware of the moving target that a third-party model represents, and an enterprise that relies on notification alone is trusting the vendor to recognise and report every change that matters to it.
Ongoing monitoring, not just onboarding
The most common structural failure in third-party AI risk management is to treat it as an onboarding check rather than an ongoing discipline. The risk of a vendor AI is not fixed at the point of contract. Models change, terms change, the vendor security posture changes, the use of the feature grows, and a feature that was low risk can become higher risk when it gains new capabilities. An enterprise that assesses a vendor AI once and never revisits it is governing a relationship as it was, not as it is, and the gap between the two grows over time.
Ongoing monitoring watches the dimensions that change: the model behaviour, the service reliability, the security posture, the terms, and the way the enterprise uses the feature. The flow below shows third-party AI risk as a lifecycle from selection through assessment and contracting to monitoring and reassessment. The monitoring and reassessment steps are what distinguish real third-party AI risk management from a one time gate, and they are the steps most often missing in enterprises that treat vendor assessment as a procurement formality.
Reassessment should be triggered by change as well as by cadence. A model update, a change in terms, a security incident at the vendor, or an expansion in how the enterprise uses the feature should each trigger a reassessment, because each can materially alter the risk. This change trigger is the same discipline the risk register applies, extended to vendor AI, and it is what keeps third-party AI risk management responsive to a relationship that evolves rather than static against one assumed to stay still.
From selection to ongoing monitoring
Third-party AI risk is a lifecycle. Onboarding checks are necessary but not sufficient without ongoing monitoring and reassessment.
Screen vendors for AI data, security, and behaviour.
Due diligence on data use, behaviour, and controls.
Terms for change notice, audit, and exit.
Track model change, service, security, and incidents.
Reassess on material change or renewal.
Contingency and concentration
Depending on a third-party AI creates exposure to its failure, and the enterprise needs contingency for the case where a vendor AI degrades, changes unacceptably, or becomes unavailable. Contingency planning asks what the enterprise would do if a critical vendor AI stopped working or changed in a way it could not accept, and it ensures there is an answer other than hoping it does not happen. For a vendor AI embedded in a critical process, the absence of a contingency plan is an operational risk that the enterprise carries without having decided to.
Concentration is a related and growing risk, because enterprises are standardising on a small number of AI providers, and heavy dependence on one creates a strategic exposure. If much of an enterprise AI capability runs on the foundation models of a single provider, a problem with that provider, whether a service failure, a change in terms, or a change in behaviour, affects a large part of the enterprise AI use at once. Concentration risk is easy to accumulate without noticing, because each individual decision to use the dominant provider is reasonable, while the aggregate dependence is a risk in itself.
Managing concentration does not mean avoiding the leading providers, which are leading for good reasons, but maintaining awareness and options. The enterprise should track how concentrated its AI dependence is, avoid designs that lock it irretrievably to one provider, and maintain enough portability that it could move if it had to. This is the same discipline enterprises apply to other critical dependencies, extended to AI, and it is what prevents a reasonable preference for a good provider from becoming a strategic vulnerability that the enterprise cannot unwind.
The embedded feature problem
The embedded AI feature deserves particular attention, because it is the channel through which the most ungoverned third-party AI risk enters. When a SaaS vendor enables an AI capability in a tool the enterprise already uses, it can begin processing enterprise data through a model the enterprise never assessed, under terms it never read, with no procurement decision and no risk assessment. The feature arrives as a product update, and unless someone is watching for exactly this, it enters governance blind.
The difficulty is that embedded features are hard to discover, because they do not announce themselves as new AI systems. Finding them requires watching the AI capabilities of the enterprise existing tools and noticing when a vendor adds one, which is a discovery discipline most enterprises have not built. The result is that embedded AI accumulates, processing data and influencing work, while the enterprise governance remains focused on the AI it built and the AI it bought deliberately, blind to the AI that simply appeared.
Governing embedded features means bringing them into the same discipline as other third-party AI: discovering them, assessing their data handling and behaviour, and deciding deliberately whether to use them. It also means engaging with SaaS vendors about how they enable AI features, seeking notice before a feature is switched on rather than discovering it after. An enterprise that treats embedded AI as seriously as it treats bought and built AI closes the channel through which the most ungoverned risk enters, which is often its single largest third-party AI exposure.
Third-party risk for agentic vendor AI
Vendor AI that can take actions, rather than only produce outputs, raises the stakes of third-party risk, because the enterprise is now relying on a third-party system to act on its behalf. A vendor agent that can call tools, access systems, and take actions carries all the risks of an internal agent plus the risks of being controlled by a third party. The enterprise must understand not only how the vendor agent behaves but what authority it has, what it can do within the enterprise environment, and how that authority is bounded and enforced.
This means third-party diligence for agentic vendor AI must cover the agent authority and its limits, not only its outputs. What tools can the vendor agent invoke, what data can it reach, what actions can it take, and who controls those permissions, the vendor or the enterprise. An arrangement where a vendor agent has broad authority in the enterprise environment, controlled by the vendor rather than the enterprise, is a significant risk, because the enterprise is exposed to actions taken by a system it does not fully control.
The enterprise should prefer arrangements where it retains control over what a vendor agent can do in its environment, enforcing the agent boundaries itself rather than relying on the vendor to do so. This connects third-party AI risk to runtime governance: the enterprise ability to enforce and record what any agent does, including a vendor agent, in its environment. Where the enterprise governs vendor agent actions at runtime, third-party agentic risk is contained. Where it delegates that control entirely to the vendor, it is trusting a third party with authority over its own systems.
Regulatory expectations and common failures
Regulators increasingly expect enterprises to manage third-party AI risk actively, particularly in regulated sectors. Operational risk rules such as APRA CPS 230 in Australia require regulated entities to manage material service providers throughout the relationship, not only at contracting, and this expectation extends naturally to material AI vendors. The EU AI Act places obligations on both providers and deployers of high risk AI, which means an enterprise deploying a vendor high risk AI carries obligations it must satisfy regardless of the vendor. These expectations reinforce that third-party AI risk is the enterprise responsibility, not the vendor alone.
The most common failure in third-party AI risk management is treating it as a one time onboarding gate, which leaves the enterprise governing vendor AI as it was rather than as it is. The second is missing the embedded feature channel entirely, so that ungoverned vendor AI accumulates through SaaS updates. The third is accepting vendor assurances without evidence, trusting marketing claims about safety and data handling rather than seeking the evidence that substantiates them.
A fourth failure is silent concentration, where the enterprise accumulates heavy dependence on one provider without noticing, until a single vendor problem affects a large part of its AI use. Each of these failures shares a root: treating third-party AI as outside governance because it was bought rather than built. The remedy in each case is to extend the same governance discipline, discovery, assessment, monitoring, and evidence, to bought AI, so that a risk is governed regardless of whether it was built in house or arrived through a vendor.
Conclusion: the Helixar perspective
The Helixar research perspective is that enterprises should govern the use of vendor AI, not only the vendor contract. A contract sets terms, but it does not tell the enterprise how a vendor feature is actually used, what data flows to it, or what a vendor agent does in its environment. When operational policy governance can see how vendor AI is used, what data reaches it, and what it is allowed to do, third-party AI risk becomes observable rather than assumed, and the enterprise has evidence if the vendor relationship is ever challenged.
This matters most for the channels where vendor AI risk is least governed: the embedded feature that processes data through an unassessed model, and the vendor agent that can act in the enterprise environment. Governing the use of these, rather than relying on the vendor to govern them, is what turns third-party AI risk from a matter of trust into a matter of control. The enterprise that can see and constrain what vendor AI does in its environment governs bought AI as seriously as built AI.
Read alongside the vendor governance and risk register reports, this report shows how the enterprise manages the AI risk it buys: by finding it across all its channels, assessing it against AI specific concerns, monitoring it over the life of the relationship, and governing its use in the enterprise environment. The AI you buy is no less risky than the AI you build. For the whole discipline these reports support, the Enterprise AI Governance Framework is the anchor.
Enterprise checklist
- Bring bought AI into governance: vendor products, model providers, and embedded features.
- Run AI specific due diligence on data handling, behaviour, security, and change notice.
- Read and negotiate data terms, especially whether enterprise data is used for training.
- Secure contractual change notification and monitor for behaviour change independently.
- Treat third-party AI risk as ongoing, with reassessment on change and on cadence.
- Maintain contingency for vendor AI failure and track provider concentration.
- For vendor agents, retain control of what they can do in your environment.
Frequently asked questions
What is the most overlooked third-party AI risk?
Does a vendor certification remove the need for due diligence?
Why does model change notification matter so much?
How should we handle agentic vendor AI?
What regulations bear on third-party AI risk?
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
- NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management
- Regulation (EU) 2024/1689, Artificial Intelligence Act
- NIST AI Risk Management Framework (AI RMF 1.0)
- Helixar research: AI Vendor Governance
- Helixar research: Enterprise AI Risk Register Framework