Model and Third-Party Risk

Model providers change their products on their own schedule. One of the largest announced a new model family in April 2025 and, in the same post, gave developers three months before an earlier model was turned off¹; days later it rolled back an update to its default assistant that users found “overly flattering or agreeable”². Neither event was a scandal. Both were the ordinary life of a fast-moving supplier. Now imagine the notice that reaches your own technology team.

Technically, it is good news. Nothing breaks. Underneath, the answers arrive in a different style, the system calls your tools differently, response times shift and the price tiers have moved. The application is still running. The business behavior has already changed.

AI dependency is business dependency

An AI system is rarely just a model. It is a small supply chain. At the top sits a business process that customers feel. Under it sits the application your teams use. Under that sit the providers, the model maker, the cloud that hosts it and often a data supplier, and under them a layer of support services: interfaces, a vector database that holds searchable versions of your documents, monitoring and plug-ins.

Every layer outside your own walls is another point of operational, security, privacy, financial and continuity risk. That stays true when every provider is reputable. Bank supervisors put the principle plainly: using a third party “does not diminish or remove” an organization’s responsibility for doing the work safely and lawfully³. The guidance was written for banks, but the logic applies to any board. You can outsource the work. You cannot outsource the accountability.

None of this is an argument against suppliers. Many enterprises will buy their models, and should, as Build vs Buy vs Partner argued. The aim is controlled dependency: knowing which providers you rely on, how much, and what you would do if one changed. AI Is Already Inside Your Organization showed that AI arrives through vendor updates. This chapter is about what to do once it has.

Two risks that travel together

Two kinds of risk arrive with every external model, and they are easy to blur.

Model risk comes from how the model behaves: its accuracy, its bias, its limits, how its performance drifts and what changes between versions. Third-party risk comes from who provides the model and on what terms: their security, the contract, service levels, support, financial health, their own suppliers and their ability to keep operating. Earlier chapters in this module dealt with accuracy, bias and security in their own right. Here the point is that both kinds of risk sit outside your control when the model is bought.

Risk leaders in financial services should note a gap. When US banking supervisors revised their model risk guidance in April 2026, they stated that generative and agentic AI models “are not within the scope” of it, because they are novel and changing fast⁴. A bank cannot assume that its existing model-validation machinery already covers the language model behind a new assistant. Many other industries never had such machinery.

Both risks are tested the same way: on your own work. A provider’s public benchmark measures someone else’s tasks. For third-party risk, look past the demonstration to security, data handling, support, continuity and viability, and for a strategic dependency add one more question. If this provider changed its business direction next year, what would happen to us? The story later in this chapter shows why that question belongs on the list.

Provider change is business change

A provider can change your business without any change on your side. The changes fall into six kinds.

The first three can arrive while the interface stays the same. A new default version changes behavior, as the flattering update did. Safety and usage policies change what the model will and will not do. Rate limits, model names and features change, and old versions retire on a deprecation date, as the three-month notice did. Model behavior can shift even under an unchanged name; Build vs Buy vs Partner cited researchers who watched one hosted model’s accuracy on a simple task fall from 84 to 51 percent in three months⁵.

The other three hit operations and economics. The service can go down, slow down or fail in one region. The price can change, and usage-based pricing already moves with more users, longer inputs, more tool calls and agent loops; the economics belong to Module 08. And data-handling terms can change: what is kept, where it is processed and whether it is used for training.

The response is a discipline, not a technology. Treat any significant provider change as a controlled change to a critical system: test it on your own cases before it reaches customers, and keep the option of holding the old version for as long as the notice period allows. The Evolution of AI Models sets out the routine of testing every release before migrating. If the AI is business-critical, a provider outage is a business interruption, and it should be in the continuity plan like any other.

The chain is longer than the contract

The next question is how far your data and your dependencies travel.

Your prompts, documents and records go to the provider you have a contract with. The provider may pass them to a subprocessor for hosting, support or monitoring, and that subprocessor may rely on a service your contract never names. NIST’s profile for generative AI lists this as a risk of its own, value chain and component integration: third-party components that are poorly documented or hard to trace⁶. Security practitioners rank supply chain weaknesses among the top ten risks for applications built on large language models⁷, and the NIST AI Risk Management Framework asks organizations to have policies for third-party software, data and supply chain risk, and contingency plans for failures in third-party systems⁸.

So ask concrete questions. What data is sent? Where is it processed? How long is it kept? Is it used for training? Who can see it? Verify the answers for the exact service and configuration you use, because products from the same provider can behave differently. Privacy and Confidential Data covers what may be sent at all, and Security and AI Attacks covers the controls. The point here is narrower: the provider sits inside your security boundary, and a contract gives you protections and remedies without giving you control.

The law also divides responsibility along the chain.

Concentration: one failure, many functions

Now step back from one application to the whole portfolio. Suppose, as an illustration, one provider sits behind customer support, software engineering, document processing, marketing and analytics. Each choice made sense on its own; each team picked the provider it knew. Put them on one page and you see concentration risk. One outage, one policy change or one price change now reaches five functions at once.

A well-documented example of what concentration costs comes from outside AI. On 19 July 2024 a faulty update from one security-software supplier crashed Windows machines around the world.

Microsoft estimated that 8.5 million devices were affected, less than one percent of all Windows machines¹⁰. The two figures measure different things. The device count is a share of machines; the loss is money. Because those machines ran airlines, hospitals and banks, one insurer estimated direct losses of 5.4 billion for US Fortune 500 companies alone, excluding Microsoft, of which only 10 to 20 percent was insured¹¹.

Concentration also hides below the provider, in one cloud region, one network or one chip supply. The Financial Stability Board names third-party dependencies and service-provider concentration among the AI vulnerabilities that could increase systemic risk in finance, because so many institutions rely on a few large providers¹². That is why concentration is a resilience question, not only a procurement question. Procurement sees five separate contracts. Resilience sees one point of failure. A short test shows which you have: what happens if this provider is unavailable for an hour, for a day, or stops offering the service for good?

Lock-in and the 90-day replacement test

Concentration has a quieter partner: lock-in. It hides until you try to leave. It grows from proprietary interfaces and features, from prompts tuned for one model, from tools built around one provider’s way of calling them, and from embeddings, the searchable numeric versions of your documents, which usually have to be rebuilt for a new model.

The practical test is one question. If we had to replace this provider in 90 days, could we? Sketching the answer produces a plan in four stages.

First, list everything specific to this provider. Then test an alternative on your real tasks, because a different model behaves differently even when its benchmark scores look similar. Then rebuild the prompts, the tool connections and the indexes. Finally, run old and new side by side, and switch. If you cannot sketch that plan, find out why: a feature only one provider offers, a data format, a contract term, or no credible alternative at all.

The test is not a decision to migrate. It tells you the effort, cost, quality gap and time before you need them, which is the moment when that knowledge is cheap. Build vs Buy vs Partner asks for an exit plan when you choose a supplier. The 90-day test checks, while you run the system, whether that plan still works.

Buy portability in proportion to risk

How much portability should you pay for? Often less than people fear, and more than many have.

One managed provider gives speed and the lowest operating load, with the highest dependency. A managed provider with a tested fallback lowers dependency, but adds complexity, cost and testing; the word that matters is tested, because an untested fallback is a hope. A self-hosted open model lowers provider dependency, but you now own the infrastructure, the maintenance, the security and the model’s own supply chain. Open models change the shape of the risk. They do not remove it.

Match the choice to the stakes. An experiment on public data can live with one provider and no exit plan. A workload that serves customers or touches regulated data deserves a tested alternative, a migration plan and a named owner for the provider relationship. Keeping track of which systems fall into which tier, and what to record about each, is the work of AI Inventory and Risk Classification in Module 07.

Story: when the provider became the competitor

Consider a decision a business-software company faced in late 2022. Jasper sold AI writing software to marketing teams. In October 2022 it raised 125 million at a valuation of 1.5 billion and reported more than 70,000 customers. Its chief executive said the company had been launched on the opportunity created by one provider’s model, GPT-3¹³. On 30 November that provider released its own chat assistant, free to use¹⁴.

Put yourself in the leadership seat in December 2022. The model your product depends on is now also available, directly and for free, from the company that supplies it. You could stay the course and trust that business customers will pay for your workflow and brand controls. You could diversify to other providers’ models. Or you could move up the stack, away from generic writing and toward the work only your product does for large marketing teams. Before reading on, choose.

What happened was all three, in sequence, and at a price. In July 2023 the company laid off staff¹⁵. By September, according to reporting by The Information summarized by Maginative, it had revised its revenue forecast for the year down by at least 30 percent and, a separate measure, cut its internal valuation by 20 percent, appointed a new chief executive and refocused on marketing teams at midsize and large companies¹⁶. Today it describes its product as routing each task to the best-performing model from several providers, testing each new model in its own evaluation pipeline, with no contract lock-in to a single provider¹⁷.

The lesson is not about one company. Every risk in this chapter was present at once: a single model provider, a product shaped around it, and a supplier whose strategy changed. None of it was a technical failure. The interface kept working throughout. The dependency had quietly become the business model, and the 90-day question had not been asked while asking was cheap.

What this means for leaders

Four habits separate controlled dependency from hidden dependency. First, keep model risk and third-party risk separate in every review, and assess both on your own work rather than on reputation or benchmarks. Second, treat significant provider changes as controlled business changes, tested before they reach customers. Third, look at concentration across the portfolio, not contract by contract, because resilience fails at the point where many functions share one supplier. Fourth, buy portability in proportion to the stakes, and prove it with the 90-day test rather than assuming it.

Check yourself

1. A famous AI provider means low risk.MythFact
2. A model change can alter business outcomes even when the interface stays the same.MythFact
3. Using several providers is always safer.MythFact
4. A strong contract solves vendor risk.MythFact
5. Self-hosting an open model removes third-party risk.MythFact
6. Existing US bank model risk guidance automatically covers generative AI.MythFact

Reflection: the provider you forgot

What comes next

External providers create dependency outside your walls. AI also changes something inside them: the work itself. The next chapter, Operational and Workforce Risk, examines what happens when AI changes roles, decision processes and the skills an organization relies on.