AI Third-Party Risk Management

AI is increasingly delivered through software that procurement has already approved. A vendor review completed at onboarding may not cover a later AI capability, model, connector, or data-use term.

AI third-party risk management, or AI TPRM, extends the existing vendor process to the AI capability and its organizational use. It connects due diligence, contracts, controls, owners, and reassessment as the product changes.

The vendor lifecycle needs an AI layer

AI features may be included when software is first bought, added as a paid option, switched on by an administrator, or introduced through a vendor update.

76%

of products in an April 2026 review of our curated enterprise-software library contained detected AI features. An application-level inventory will therefore miss many of the AI systems people can use at work.

The library is curated toward enterprise business software. AI detection is based on source-linked vendor product, security, and data handling documentation. The percentage is not an estimate for all software.

Employees may use unsanctioned tools or personal accounts outside procurement controls. An approved application may also contain an AI capability introduced after the original review. The second case is not necessarily shadow AI, but the capability can remain unreviewed.

Existing TPRM processes remain the foundation. AI adds information and decisions at each stage:

1. Identify the vendor, product, AI capability, and proposed use.

2. Triage the use according to its data, access, affected people, and potential impact.

3. Perform proportionate AI-specific due diligence.

4. Approve, restrict, or reject the use and implement the required controls.

5. Monitor material changes, incidents, and control performance.

6. Reassess, renew, or offboard while retaining the supporting evidence.

The vendor, application, AI capability, and organizational use should be connected but kept distinct because each capability and use can require different controls.

AI-specific due diligence

Security, privacy, financial, and operational reviews continue to apply. The AI review adds questions about how the capability works and how the organization will use it.

Review area	Information required
Use and impact	The intended task, users, people affected, decisions supported, and consequences of an incorrect or unsuitable output.
Data handling	Inputs, retention, processing location, vendor and subprocessor access, reuse for training or improvement, and deletion.
Model supply chain	The model provider, external APIs, relevant dependencies, model version, and how changes are communicated.
Access and autonomy	Repositories, connectors, permissions, available actions, approval gates, and whether actions can be reversed.
Performance and oversight	Known limitations, testing, output verification, monitoring, human oversight, and escalation procedures.
Legal position and evidence	Intended purpose, provider instructions, applicable classification, restricted uses, logs, test results, version history, and incident routes.

The product name does not determine the decision. A document assistant used to summarize a public report requires different controls from the same assistant processing employee files or supporting recruitment decisions.

This distinction also matters under the EU AI Act. When an organization uses a vendor's AI system under its authority, it is generally the deployer while the vendor remains the provider. The applicable obligations depend on the capability and use rather than the procurement category alone.

Contracting for AI-specific risk

The contract should reflect the facts established during due diligence and provide a route for keeping them current. Depending on the use and exposure, relevant provisions may cover:

• permitted and prohibited uses of customer data;

• retention, deletion, processing location, and subprocessor requirements;

• use of inputs or outputs for model training or product improvement;

• notice of material changes to AI capabilities, models, providers, terms, or default settings;

• notification of security incidents, material service failures, and relevant regulatory enquiries;

• access to current documentation, instructions, logs, and assurance evidence; and

• responsibility allocation, remediation, suspension, and offboarding support.

Not every vendor or use requires the same terms. Contract requirements should be proportionate to the data, system access, affected process, and potential impact.

The contract defines vendor commitments, while managed accounts, configuration, access restrictions, output checks, employee guidance, and technical guardrails govern organizational use.

Ownership and decision rights

AI TPRM requires shared evidence and explicit decision rights. The TPRM function can coordinate the process without owning every underlying risk.

Owner	Primary responsibility
TPRM	Coordinate triage, evidence collection, review status, reassessment, and the overall vendor record.
Business owner	Define the intended use, affected process, expected benefit, acceptable limitations, and operational oversight.
Procurement and legal	Negotiate commercial terms, AI-specific restrictions, change notice, and responsibility allocation.
Security and privacy	Assess data flows, permissions, technical controls, security exposure, and privacy requirements.
AI governance or compliance	Assess AI-specific risks, classification, policy alignment, oversight, and required evidence.
IT or application owner	Configure licences, accounts, connectors, permissions, default settings, and technical restrictions.

The record should identify who approves the use, implements each control, accepts the remaining exposure, and responds when the vendor or use changes.

Material changes trigger reassessment

A point-in-time vendor review becomes incomplete when relevant product or use information changes. Material AI changes should therefore trigger proportionate reassessment.

Relevant triggers include:

• addition or automatic activation of an AI capability

• replacement of the model or model provider

• new connectors, repositories, permissions, or agent actions

• changes to training, retention, processing location, or subprocessor terms

• expansion to a new team, purpose, dataset, or affected population

• use of outputs in employment, credit, safety, or other consequential decisions

• a material incident, control failure, or deterioration in performance

• changes to provider instructions, legal requirements, or regulatory classification

Reassessment does not always require a complete new vendor review. The changed information should be routed to the appropriate owner and linked to the earlier decisions that relied on it. The review can then produce one of four outcomes: no change, updated controls, restricted use, or suspension.

This methodology concentrates work on changes that can alter the exposure and records why the existing decision remained valid or was revised.

How Validaitor supports AI TPRM

Validaitor helps organizations identify AI in third-party software, collect source-linked vendor evidence, connect capabilities to organizational uses, assign risks and controls, route work to accountable owners, and monitor relevant changes. This keeps the third-party AI record current across the vendor lifecycle:

For a review of the AI capabilities across your software estate, talk to us.

Review your third-party AI estate

Author: Art Richards, Berlin