Third-party AI risk: due diligence on model providers

Very few firms build their own large language models. Most use models from a handful of providers, accessed through cloud platforms or built into the software they already buy. That makes third-party risk central to AI governance.

This article sets out what to assess before relying on an AI provider, which rules may apply, and how to stay resilient when a provider changes or fails.

Map your AI dependencies

Start by listing every third party your AI depends on:

• Model providers — the organisations whose models generate the output.
• Platforms — cloud or AI platforms through which models are accessed.
• Software vendors — CRM, telephony, document and productivity tools with AI features.
• Fourth parties — the providers your vendors rely on.

Link each provider to the use cases that depend on it. One provider record, linked to many use cases, makes it obvious where a single failure would have wide impact.

Due diligence questions

Data

• Is our content retained, for how long, and can retention be switched off?
• Is our content used to train or improve the provider’s models? Under which terms?
• Who at the provider can access our content, and when?
• Where is data processed and stored? Are transfers covered?
• How is data deleted at the end of the relationship?

The ICO’s guidance on AI and data protection helps frame the data protection questions.

Security

• What certifications and independent assurance does the provider hold?
• How are access, encryption and incident response handled?
• How quickly will the provider notify us of an incident affecting our data?

Models

• How and when do models change? Will we get notice of significant changes?
• Can we pin a model version, and for how long?
• What testing and safety information does the provider publish?

Resilience

• What are the service levels and historical availability?
• What happens if the service is unavailable, degraded or withdrawn?
• Can we switch to an alternative provider, and how quickly?

Contract

• Audit and access rights, including for regulators where required.
• Sub-processor and subcontracting terms.
• Exit and transition support.

Which rules may apply

• Outsourcing. SYSC 8 sets requirements and guidance on outsourcing operational functions. SYSC 8.1.1R is addressed to common platform firms; other firms apply related provisions as guidance. Whether a particular AI service is an outsourcing — and whether it is critical or important — depends on what it does for you.
• Operational resilience. For firms within scope of SYSC 15A, important business services must be mapped to the resources that support them. The FCA’s good practice publication notes that mapping AI dependencies is a requirement for in-scope firms. See the FCA’s operational resilience pages.
• Data protection. Provider relationships need appropriate data processing terms under UK GDPR.

Record your applicability decisions and the reasons, rather than assuming every rule applies or none does.

Staying resilient

The FCA’s publication highlights avoiding single-provider dependence, seeking notice of significant model changes, and testing contingency plans. In practice:

• Use more than one provider where the use case allows, so a failure or unacceptable change at one does not stop the business.
• Route access through one control point, so switching providers does not mean retraining every user or re-implementing every control.
• Re-test after model changes. A new model version can behave differently; run your test prompts and check outcomes.
• Exercise the contingency. Practise what happens if a provider is unavailable for a day, a week, or permanently.

Ongoing oversight

Due diligence is not a one-off. Review providers periodically and when something changes: new terms, a significant model change, an incident, or a change in how you use the service. Track open issues against each provider and report them in AI management information.

How Dutira helps

Dutira’s third-party AI register holds one record per provider, linked to every use case and model that depends on it, with due diligence, open issues and review dates. The workspace routes model access through one control point and currently supports OpenAI, Anthropic and Google models through their APIs, so firms can use more than one provider under the same policies. Model choices are subject to your agreements with each provider. See the platform.