Buying AI does not transfer accountability for the organisation's use. Third-party AI risk management connects supplier evidence with the use case, data, users, decisions and controls that the buyer operates.
What Counts as Third-Party AI?
The scope includes foundation-model APIs, SaaS copilots, embedded AI features, externally hosted agents, specialist models, data or retrieval services, agent tools and relevant subprocessors. A familiar software product may become an AI dependency through a normal feature update.
Tier the Supplier and Use Case Before Due Diligence
Tiering should consider business and user impact, data sensitivity, action authority, regulatory exposure, affected population, supplier concentration, substitutability and recovery if the service fails. Assess the same supplier differently when use cases create materially different consequences.
The Third-Party AI Risk Lifecycle
Intake and scoping
Record purpose, owner, service, model or feature, data flows, users, integrations, decision impact, autonomy and prohibited uses.
Due diligence and evidence review
Request proportionate evidence on security, data use, evaluation, model and service limitations, human oversight, incident history, business continuity and supplier governance.
Contract and accountability controls
Translate material dependencies into obligations covering permitted use, data, changes, subprocessors, incidents, cooperation, evidence access, termination and deletion.
Approval and onboarding
Record approved scope, conditions, control owners, required configuration, monitoring and review date. Do not allow a broad enterprise contract to replace use-case approval.
Continuous monitoring and reassessment
Watch for changes to model, functionality, data processing, hosting, tools, agents, subprocessors, terms and control evidence. Reassess when a change could affect the original decision.
Incident response and supplier escalation
Define notification routes, evidence preservation, containment responsibilities, customer communication, investigation cooperation and decision authority to restrict or suspend use.
Exit, portability and evidence retention
Plan for data export and deletion, replacement, service interruption, dependency removal, record retention and verification that credentials and integrations no longer operate.
Supplier Evidence Matrix
| Lifecycle stage | Buyer question | Evidence requested | Owner | Reassessment trigger |
|---|---|---|---|---|
| Intake | What service, model, data and action are in scope? | Use-case record, architecture and data flow | Business and technical owner | New purpose, population, integration or autonomy |
| Due diligence | Which risks and limitations has the supplier tested? | Test method, results, assurance reports and limitations | Risk and specialist reviewers | Material evidence expiry or new failure information |
| Contract | What must the supplier disclose or support? | Change, incident, audit, export and deletion terms | Procurement and legal | Terms, subprocessor or service change |
| Operation | Is use still inside the approved boundary? | Configuration, monitoring, incidents and exceptions | Service owner | Control failure, incident or repeated exception |
| Exit | Can the organisation leave safely? | Export, deletion, credential revocation and replacement plan | Service, data and records owners | Termination, unacceptable change or supplier failure |
Contract and Change-Control Requirements
Contract terms should address data use and retention, training use, locations, subprocessors, service and model changes, security notification, incident cooperation, evidence availability, continuity, export, termination and verified deletion. A contractual right is useful only if an owner monitors it and a workflow turns a notice into a decision.
Worked Example: An AI-Enabled SaaS Copilot
A team proposes a copilot that reads internal documents and drafts customer responses. The buyer tiers it as material because it processes confidential content and influences external communication. Approval requires restricted data sources, human review before sending, evidence of access controls and supplier notification of model or processing changes.
After launch, the supplier introduces an agent that can update CRM records. This expands authority and integrations, so the organisation pauses that feature, updates the data and action map, requests new evidence and reassesses risk before enabling it. The product name did not change; the governed use did.
Evaluate Platform Support for Third-Party AI Risk
Ask a platform to connect supplier, service, model, use case, owner, obligations, evidence, exceptions and change history. Test whether a supplier change reaches affected use cases and produces reassessment rather than a disconnected alert. Use the platform requirements method to define the proof and the catalogue to screen relevant governance capabilities.
For regulatory supplier evidence, use the EU AI Act supplier-readiness guide. For the broader risk process, use the AI risk management guide.