How to Audit Third-Party AI Governance

An organization can spend months performing due diligence on an AI platform and still lose control of the risk a few weeks later. The vendor changes the underlying model, adds a new subprocessor, revises its data-retention terms, or modifies a safety control. The contract remains active and the service still works, but the exposure is no longer the one management originally approved.

That is the central problem with third-party AI governance: outsourcing the technology does not outsource accountability.

For Internal Audit, this changes the assurance question. It is not enough to ask whether the vendor was approved, holds a certification, or supplied a SOC report. The broader question is: can the organization continuously identify, assess, and control risks created by AI capabilities it does not directly operate?

Third-party AI is not just another vendor risk

Traditional third-party controls still matter, but AI introduces two characteristics that make point-in-time reviews inadequate.

The first is opacity. An organization may consume a model, API, or AI capability embedded in enterprise software without full visibility into training data, evaluations, architecture, or the provider's internal control environment. The IIA's Artificial Intelligence Auditing Framework highlights third- and fourth-party risk, recommends understanding vendor control environments, and calls for third-party responsibilities to be defined and monitored, including audit rights where appropriate.

The second is continuous change. COSO notes that GenAI reliability can shift because of changing data, model drift, or vendor updates. The risk therefore does not end when procurement signs the contract; it has to be governed through the lifecycle.

ISO/IEC 42001:2023 reinforces this lifecycle view through an AI management system. Annex A includes controls addressing allocation of responsibilities among the organization, partners, suppliers, customers, and other third parties, as well as the organization's use of supplier-provided services, products, and materials. ISO/IEC 42001 is a voluntary standard unless made applicable through regulation, contract, certification, or another obligation; it should not be presented as law.

Start with inventory and risk tiering, not the vendor questionnaire

A useful audit does not begin with the supplier questionnaire. It begins by identifying where third-party AI dependencies actually exist.

That includes products marketed as AI, but also AI features embedded in productivity suites, ERP, CRM, cybersecurity tools, HR platforms, software-development environments, and analytics products. The NIST Generative AI Profile recommends inventorying third parties with access to organizational content and updating acquisition and procurement due diligence for AI-specific risks.

Internal Audit should assess whether management tiers vendors using factors such as use-case impact, data sensitivity, degree of autonomy, potential effects on individuals, operational dependency, substitutability, change frequency, and reliance on downstream providers. An internal drafting assistant should not receive the same treatment as an external system that screens job candidates, influences credit decisions, or executes actions in production.

Risk tiering also determines audit depth. The Global Internal Audit Standards require risk-based planning and engagement-level risk assessment. In addition, The IIA's Third-Party Topical Requirement, issued in 2025, becomes effective on September 15, 2026. From that date, conformance will be mandatory for applicable assurance services and will establish a minimum baseline for evaluating third-party governance, risk management, and controls across selection, contracting, onboarding, monitoring, and offboarding.

The contract should make control possible, not merely authorize the purchase

A contract is a preventive control. If the organization discovers after an incident that it lacks sufficient rights to obtain information, challenge material changes, or recover its data, the control failure started before deployment.

For material AI providers, Internal Audit should verify that contractual terms reflect the identified risk and make sufficient assurance evidence available throughout the relationship.

Contract area	What should be resolved	Useful audit evidence
Use and data	Approved purposes, permitted data, retention, reuse, and restrictions on training or service improvement.	Contract, data-processing terms, architecture, and data-flow documentation.
Service changes	Which model, configuration, feature, or subprocessor changes require notification and when reassessment is required.	Change clauses, vendor notices, version history, and internal approvals.
Incidents and performance	Thresholds, notification windows, escalation, root-cause analysis, and corrective action.	SLA, incident procedures, tickets, reports, and post-incident reviews.
Assurance access	Risk-proportionate mechanisms to evaluate the provider: audit or assessment rights, independent reports, testing results, and technical evidence.	Audit clauses, SOC or other assurance reports, certifications, test results, and remediation responses.
Subcontracting	Visibility into material fourth parties and obligations that must flow down to them.	Subprocessor inventory, change notifications, and relevant contractual terms.
Exit	Replacement, portability, data return or deletion, access revocation, and transition support.	Exit plan, deletion evidence, access inventory, and continuity plan.

NIST takes a similar approach. Its GenAI Profile suggests contract clauses that allow organizations to evaluate third-party GenAI processes and standards, along with AI-specific procurement due diligence and dynamic monitoring. These are voluntary recommendations rather than universal requirements, but they provide useful control-design and audit criteria.

One important caution: a SOC report may provide valuable evidence over service, security, or processing controls, but it does not by itself demonstrate that a model behaves appropriately for the organization's use case. The auditor needs to understand what the report actually covers and what remains outside scope.

Changes, incidents, and monitoring are the real test of governance

The most revealing audit work often occurs after contracting. That is where the organization demonstrates whether its process still works when the provider changes.

Select a sample of higher-risk AI vendors and trace actual events: a new model release, a subprocessor change, an SLA amendment, an outage, a vulnerability, or a privacy incident. For each event, test whether the organization detected the change, assessed its impact, decided whether revalidation was necessary, and documented either risk acceptance or corrective action.

The NIST AI RMF Playbook includes an outcome under Manage 3.1 that third-party AI risks and benefits are regularly monitored and controls documented. It also connects post-deployment management with monitoring, incident response, recovery, change management, and decommissioning.

COSO adds a useful internal-control lens: in GenAI, models, prompts, retrieval connectors, and other configurations can evolve quickly, so risk assessment, change control, and monitoring need to keep pace. From an audit perspective, an initial approval with no evidence of periodic reassessment is a warning sign.

Management also needs information sources of its own. If monitoring depends entirely on what the vendor chooses to disclose, oversight is fragile. Internal Audit can look for internal quality metrics, user complaints, failures, performance deviations, control exceptions, anomalous consumption, data incidents, and changes in the criticality of the business process.

Exit readiness is a governance control, not an administrative afterthought

Vendor dependency can grow quietly. Over time, the organization accumulates integrations, prompts, knowledge bases, automated workflows, historical data, and operational habits that make switching difficult. Exit capability therefore needs to be assessed before it is needed.

The IIA Third-Party Topical Requirement requires, when applicable, assessment of formal offboarding that addresses termination, replacement, return or destruction of sensitive data, and revocation of access. For AI, the auditor should extend the question: what happens to embeddings, vector stores, configurations, logs, organization-supplied datasets, fine-tuned assets, and API dependencies? Can a critical capability be recreated with another provider? Is the transition period realistic?

A useful test is a tabletop exercise. Select one critical provider and ask management to describe how it would exit the relationship within 30, 60, or 90 days. Gaps surface quickly when no one knows where the data resides, which integrations must be replaced, or what evidence of deletion should be obtained.

A useful audit conclusion should address dependency, not isolated vendors

Auditing third-party AI is not about deciding whether a provider is “good” or “bad.” It is about whether the organization can maintain sufficient control over a capability that depends on technical and operational decisions made outside its boundaries.

A strong conclusion connects six elements: inventory, risk tiering, due diligence, contracts, monitoring of changes and incidents, and exit readiness. If one is missing, the organization may be accepting a risk it never consciously evaluated.

The final audit question is simple: if the vendor materially changed the model tomorrow, would the organization know, understand the impact, and have realistic options to respond? If that cannot be demonstrated with evidence, third-party AI governance is not yet under control.