Your supplier passed its security review: Five shifts third-party risk management (TPRM) must make for AI-enabled services

A critical supplier passes third-party due diligence and continues to deliver a reliable service. Months later, it may switch the provider behind an artificial intelligence (AI) feature your business relies on, changing who processes your data. Or its existing provider may release a model update that changes the outputs your teams use. Neither change necessarily causes a breach or outage, yet the risk profile approved at onboarding may no longer reflect how the service operates.

The issue for chief information security officers (CISOs) and senior third-party risk leaders is whether TPRM can detect and respond to that shift. Existing supplier checks assess security and resilience, but AI-enabled services also require a view of the models and providers behind critical services, the business data they process and the evidence available about their controls. Leaders need to define which changes or incidents trigger reassessment and name an owner authorized to seek further evidence, require testing or restrict use while the risk is reviewed. These five shifts show how TPRM can manage AI-enabled services as they change.

1. Map AI across critical services

Supplier records may show who provides a critical service without showing which features now use AI. For each service, leaders need to establish which AI-enabled functions the business uses, what data they process and where their outputs influence staff decisions or customer interactions. The consequences of unreliable outputs, changed data handling or loss of the function should determine the depth of review.

Spending records alone will not fill that gap. In a 2026 UK government survey, 47% of businesses able to estimate their AI expenditure reported no spend in 2025. The report partly attributes this to free tools and AI features embedded in existing software. Mapping how the service is used gives TPRM a basis for prioritizing scrutiny and tracing the models and providers behind it.

2. Look beyond the supplier for control and evidence

The supplier delivering a service may use a model it built and controls, or one provided by another company. It can test how its own service performs but may depend on that provider for evidence about how the underlying model was developed, secured and tested. In a 2026 Bank of England and Financial Conduct Authority (FCA) survey, 34% of responding UK financial firms identified limited transparency into third-party AI systems as a major constraint on adopting third-party AI. Guidance from the National Cyber Security Center (NCSC) on AI supply chains calls for transparency and traceability across models, data and other components.

For critical services, leaders need to identify who provides and updates the model and which organizations process the business’s data. They also need to know what evidence the supplier can obtain from those providers about model development, security testing, performance and data handling. This shows where assurance depends on another company and helps define which material changes to the model, provider or use of data the supplier can detect and report.

3. Reassess risk when exposure changes

Due diligence can become outdated when software behind a supplier’s AI service changes. In March 2026, attackers published compromised versions of LiteLLM, a tool that connects applications to AI models. Those versions were designed to steal credentials. Mercor later confirmed it was affected and that sensitive information relating to a limited subset of its experts was impacted. For a buyer, an incident of this kind calls for fresh evidence about exposure and remediation.

TPRM should define which changes or incidents trigger reassessment, including those that could materially affect data handling, output reliability, service resilience or the security of upstream AI components. For higher-risk services, supplier agreements should specify what notice and supporting evidence the supplier can provide for significant model updates, changes of AI provider, new uses of business data and security incidents involving AI components it relies on.

A named service owner, supported by TPRM and security, can then decide whether to seek further evidence, require remediation or testing, or restrict use while the risk is reassessed. Guidance from the US National Institute of Standards and Technology (NIST) on generative AI includes ongoing monitoring of third-party AI and contract terms addressing system changes over time.

4. Test whether fallbacks are genuinely independent

Leaders should test whether a proposed alternative can take over when a critical AI-enabled service is disrupted. That starts with checking whether it shares a model provider or cloud platform with the primary service. The test should show how quickly work can move to another model or supplier, or continue manually, and whether the alternative meets requirements for output quality, security and data handling.

During an August 2026 incident, a degradation at an upstream provider caused 63.3% of requests using the Kimi K3 model in GitHub Copilot, an AI coding service, to fail. Requests using other models, including those routed through Copilot’s Auto setting, were unaffected. The incident shows how another model can provide a working route during a disruption. A proposed backup supplier needs the same check for shared dependencies.

5. Use AI to strengthen oversight while people remain accountable

TPRM teams should record AI use in critical services and work with service owners and security to assess model and data controls, test outputs used in business or customer decisions and rehearse fallbacks. AI can help manage that work by suggesting risk tiers, identifying shared providers, reviewing supplier evidence and flagging changes for investigation. Teams must verify its findings against the underlying evidence before acting.

If an AI agent can request evidence or start a review, the organization should define which systems and data it can access, what it can do without approval and when human authorization is required. Its access and actions should be recorded in an audit log. The NCSC’s interim advice on agentic AI recommends restricted access, logging and human oversight. The accountable service owner, supported by TPRM and security, should decide whether the supplier has provided enough information and test results to reassess the risk. If gaps remain, the owner should decide whether to restrict the feature or escalate the risk for formal acceptance.

What to check now

The risk accepted at onboarding must still match how the service operates today. TPRM therefore needs to identify AI use in critical services, map the models and providers behind it, define which changes or incidents trigger reassessment and test whether alternative arrangements will work during a disruption. AI can help teams monitor this information, but named service owners must decide when to request evidence, reassess risk or restrict use.

At Elixirr, we help clients build cyber risk management capabilities around the services that matter most. Start with one critical supplier service: can you identify the models and providers behind it, confirm which material AI changes or incidents the supplier must report, and name the person authorized to reassess or restrict the service?