Third Party Model Dependence and Concentration Risk
Many companies now build AI applications using third-party models. The most obvious examples are large language models like ChatGPT, Claude, or Gemini. But the principle applies more broadly: whenever a company depends on a model, service, or component it does not control, concentration risk arises.
Concentration risk is the risk that depends on one supplier or provider creates exposure. If a company’s customer service application runs on OpenAI’s API, and OpenAI changes its terms, pricing, or performance, the company feels the impact. If OpenAI has an outage, the company’s service degrades. If OpenAI is acquired or changes its product roadmap, the company must adapt.
Financial Risk from Model Dependence
The most obvious financial risk is pricing. API pricing for models changes over time. OpenAI has lowered prices, which benefited customers. But this is not guaranteed to continue. A company that has embedded a model into its core product depends on that model’s cost structure remaining predictable. If pricing rises 10x, the business model breaks. Boards should understand the pricing structure of any third-party model in use and whether that pricing could materially affect profitability.
Performance risk is another factor. A model provider might change its model or service. A version update might improve performance for some use cases but degrade it for others. A company that has optimised its application for one model’s behaviour might find the new version requires significant rework. Some companies require contractual guarantees that models will not change without notice, though not all providers offer this.
Availability risk is acute for cloud-based models. If the provider has an outage, the company’s application fails. Companies typically address this by having a fallback model or by accepting some downtime. If downtime is unacceptable (e.g., for critical services), the company might run a local model as a backup, which creates its own costs.
The Mitigation Strategies
The strongest mitigation is diversification. A company might use multiple models from different providers. If one provider has an issue, the company switches to another. This requires that the application can work with multiple models, which adds complexity but reduces dependency.
Another strategy is fine-tuning. Instead of using a base model as-is, the company fine-tunes it on its own data. This creates some optionality: if the provider changes the base model, the company still has its fine-tuned version. This is not perfect protection, but it increases resilience.
Running a local model is an option for some companies. Open-source models like Llama, Mistral, or Qwen can be run on company infrastructure. This eliminates dependency on a cloud provider and gives the company full control. The trade-off is that local models typically require more expertise to run and optimise. They also require significant compute infrastructure.
Contractual protection is important but limited. A company can negotiate a commercial agreement with a model provider that specifies pricing guarantees, service level agreements, or notice periods for changes. Not all providers offer this (they may be serving millions of users and cannot negotiate individual terms). Large enterprises sometimes negotiate data processing agreements that include cost and availability commitments.
Vendor Lock-In Considerations
Vendor lock-in is real. Once an application is built around a specific model’s outputs, inputs, and APIs, switching to a different model requires work. The new model might have different input/output formats, different latency, different costs. If the vendor knows the customer is locked in, they have less incentive to keep terms favourable.
Boards should ask: Do we know all the third-party models and services we depend on? What would happen if pricing doubled? What would happen if a provider went out of business or withdrew the service? What is our plan for each scenario? These are not questions with comforting answers, but asking them forces clarity.
The Long-Term View
The model market is changing rapidly. New models arrive regularly. Existing models improve. Pricing trends downward for commodity capabilities (like text completion) but upward for specialised services. A strategy that made sense today might not make sense in two years. Boards should review model dependence annually and ask whether the company’s strategy is still sound.
One emerging practice is organisations training their own models on proprietary data. This is expensive and requires technical capability, but it eliminates vendor dependence for core capabilities. It also creates potential competitive advantage if the model performs better than commodity alternatives. This is a long-term investment that smaller companies may not be able to justify.