Third-Party AI: Who Owns the Risk?

A company acquires an AI service to review claims, rank candidates, or answer customer questions. The vendor supplies the model, hosts the infrastructure, and manages updates. Months later, the underlying model changes, a new subprocessor is introduced, or data-retention terms are revised. The business process still has the same name, but the system the organization originally approved is no longer exactly the same system.

That is the central challenge of third-party AI. Organizations can outsource technology, operations, and part of the evidence base. They cannot assume that the consequences have been outsourced with them.

For auditors, the working thesis is straightforward: risk can be apportioned among parties, but the customer organization still needs to understand what it depends on, what it controls, what it must monitor, and what it will do when the relationship is no longer acceptable. With AI, that obligation extends well beyond initial vendor due diligence.

Buying AI does not transfer accountability

ISO/IEC 42001:2023 addresses third-party relationships explicitly. Control A.10.2 requires responsibilities across the AI system lifecycle to be allocated among the organization, partners, suppliers, customers, and other third parties. A.10.3 requires a process to ensure that the organization’s use of supplier-provided services, products, or materials aligns with its approach to responsible AI development and use.

The distinction matters. Allocating responsibility is not the same as transferring all accountability. A contract may require a provider to meet service levels, protect information, report incidents, or remediate deficiencies. The customer organization must still decide whether the provider is suitable for the intended use, whether the dependency is acceptable, and whether internal compensating controls are sufficient.

The NIST AI Risk Management Framework points in the same direction. Its Govern function includes policies for risks arising from third-party software, data, and supply-chain dependencies, while Manage calls for regular monitoring of third-party resources. NIST also notes that acquired technologies can be complex or opaque and that a provider’s risk tolerance may not align with that of the organization deploying the system.

The audit question is therefore not simply, “Did the vendor accept responsibility?” It is: Can the organization demonstrate which responsibilities remain its own and how it exercises them?

Vendor opacity changes what counts as evidence

Third-party dependency is not new. What is different is how much can sit below the visible surface of an AI service.

An enterprise application may rely on a SaaS provider, a foundation model from another company, software libraries, purchased datasets, and cloud services. The NIST Generative AI Profile highlights this value-chain risk: generative AI systems can combine many third-party components, reducing transparency and accountability for downstream users.

This creates an assurance tension. The organization needs enough evidence to govern the use, but a provider may limit access because of intellectual property, security, or confidentiality. The answer is not automatically to demand source code. It is to define which evidence is necessary for the actual risk.

Depending on the use case, auditors may reasonably expect evidence such as:

documentation of intended use, limitations, and material changes;
independent testing or evaluation results;
performance, incident, and availability metrics;
information on data provenance where it is material;
controls over critical subprocessors and components;
escalation and remediation mechanisms;
logs that can reconstruct relevant decisions or changes when the use case requires traceability.

The red flag is not that some information is confidential. It is that the organization cannot explain what evidence it needs, what it cannot obtain, and how it compensates for that limitation.

The contract must anticipate a service that changes

Traditional technology contracts often concentrate on price, security, availability, and data protection. Those remain important, but they can be insufficient for AI because the service can change behavior without the business process changing its name.

A contract or service agreement should translate AI risk into workable rights and obligations. There is no universal clause set, but the topics that typically deserve analysis include:

service definition, intended use, and relevant restrictions;
documentation and cooperation obligations;
notice of material changes to models, data, functionality, or subprocessors;
relevant service levels and performance measures;
handling of customer inputs and confidential information;
incident management and notification;
audit, assessment, or evidence-access rights;
remediation obligations;
data ownership, portability, return, and deletion;
continuity, termination, and exit assistance.

The critical issue is change management. ISO/IEC 42001 treats change as part of the AI lifecycle, and its implementation guidance addresses updates, changes in intended use, and communication to users. If a vendor changes the model behind a high-impact decision, the organization needs criteria for deciding whether that change triggers revalidation, approval, communication, or additional controls.

A contract is a control design. Risk is reduced only when contractual obligations become information, decisions, and actions throughout the life of the service.

Monitoring means watching the relationship and the system

A common control failure is treating third-party risk as complete after due diligence and signature. That is why the IIA’s Third-Party Topical Requirement is particularly relevant. It was issued on September 15, 2025 and becomes effective on September 15, 2026. From that date, when applicable to an assurance engagement, it establishes a baseline for assessing third-party governance, risk management, and control processes. It does not, by itself, require every vendor to be audited or replace risk assessment.

Its User Guide organizes the third-party relationship into five stages: selecting, contracting, onboarding, monitoring, and offboarding. That lifecycle is especially useful for AI because the risk can change after acquisition.

Stage	Audit question	Useful evidence	AI-specific concern
Selection	Does the use case justify this provider and dependency?	risk assessment, due diligence, alternatives	opacity, concentration, dependency
Contracting	Do the obligations reflect the material risks?	contract, schedules, SLAs, audit rights	model changes, data, subprocessors
Onboarding	Is the integration consistent with approved use?	architecture, configuration, testing, owners	out-of-scope use, unsuitable data
Monitoring	Do we know whether the service remains acceptable?	KPIs/KRIs, incidents, changes, periodic reviews	drift, model updates, new capabilities
Offboarding	Can we terminate the relationship in a controlled way?	exit plan, testing, data and access inventory	portability, deletion, continuity, technical lock-in

A mature program does not apply the same monitoring intensity to every provider. The level of oversight should reflect criticality, potential impact, data access, autonomy, substitutability, and concentration. An internal writing assistant should not require the same control depth as an AI system influencing credit, hiring, safety, or regulatory decisions.

Exit risk starts before the contract is signed

The most revealing test of a vendor relationship often comes when the organization wants to leave.

Can it retrieve its data in a usable format? Can it reconstruct configurations, rules, prompts, logs, or decisions that matter? Does it know what the provider and downstream parties must delete? Is there an operational fallback during migration? Will a replacement provider require the use case to be revalidated? Has the business process become dependent on a proprietary API, taxonomy, or feature?

Those questions make exit risk broader than a termination clause. It is a problem of resilience, portability, evidence, and concentration.

NIST explicitly includes contingency processes for high-risk third-party failures and safe decommissioning. The IIA User Guide includes exit strategy and formal exit planning within offboarding. For auditors, the implication is practical: exit capability should be assessed while the organization still has negotiating leverage, not after the provider has become a critical dependency.

What an auditor should be able to conclude

A third-party AI audit does not need to become a deep model assessment to add value. It can begin with a governance question: Can the organization demonstrate that it identifies, allocates, controls, and monitors the risks created by dependence on an AI provider?

A defensible conclusion should be supported by evidence that:

the organization maintains a sufficiently complete inventory of relevant AI providers and components;
internal and external responsibilities are defined without material gaps;
risk assessment determines the evidence, controls, and contractual obligations required;
material service changes can be detected and trigger review;
performance, incidents, and dependencies are monitored according to criticality;
the organization has a viable response to vendor failure, degradation, or nonperformance;
the relationship can be terminated without losing control of data, access, evidence, or critical continuity.

The vendor may operate the model. It may host the infrastructure. It may accept substantial contractual obligations. But the decision to rely on that service still belongs to the customer organization.

For internal audit, that is the boundary that matters: outsourcing changes who performs activities; it does not remove the need to know who is accountable when the AI fails.