Your demo works, the first customers are signing up, and usage is taking off. Then an email arrives: the model powering your product will be replaced, its pricing is changing, or certain uses will now be subject to different rules. For a start-up, that message can turn a promising sales week into an emergency engineering project. Dependence on AI platforms is not just an infrastructure issue: it affects margins, customer commitments and strategic freedom. Looking ahead to September 2026, developments already observed help identify the risks — without claiming to know providers’ next decisions.
A dependence that goes deeper than a simple API
The phenomenon is nothing new. Entrepreneurs are familiar with social media algorithm changes, app store commissions and cloud bills. But generative AI adds another challenge: the service being purchased does not behave in an entirely consistent way. Two models capable of answering the same query can produce very different results within a business process.
Switching providers therefore involves more than changing an address in the code. Responses, refusals, formats, tool calls and performance in the languages used all need to be checked. A prompt carefully optimised for one model may work poorly elsewhere. The real lock-in often lies in missing tests and accumulated fine-tuning.
The warning signs are already tangible. Successive API version deprecations at OpenAI have made migration part of developers’ everyday work. The major outage affecting its services in November 2023 was a reminder of concentration risk. The arrival of Claude 3 and then GPT-4o in 2024 illustrated the pace of renewal. These events do not predict any specific retirement in 2026; they justify preparing for the next one.
The advertised price is not your actual cost
For a founder, the price per million tokens is a convenient but incomplete benchmark. A feature may involve several calls, a lengthy conversation history, documents, retries after errors and an additional model tasked with checking the response. Document retrieval, storage and human intervention may add further costs.
Take an assistant that drafts replies for a customer service team. If a new version requires more context or produces more responses that need correcting, its actual cost may rise despite a lower unit price. Conversely, a more expensive model may prove cost-effective if it avoids multiple attempts. The right economic unit is the successfully completed task, not the token consumed.
From the first contracts, the team should track the cost per useful operation and per customer, then model several sources of pressure: a price increase, the loss of a discount, heavier usage or a switch to a backup model. An “unlimited” subscription sold before this analysis may become a commitment that is impossible to honour. It is better to specify included usage allowances, alerts and clear overage rules.
Building an exit route without overengineering
Portability does not mean maintaining five providers at all times. A young company must first deliver a useful product. However, a few early choices can prevent every change from turning into a complete rewrite.
Separate business logic from the provider
Business rules, access rights and customer data should not be buried in a proprietary integration. An internal layer can centralise calls, timeouts, retries and cost tracking. It must also make differences between providers visible: a common interface does not guarantee identical capabilities.
Prompts, output schemas and configurations should be version-controlled outside the provider’s consoles. When the product uses document retrieval, retaining source documents and their metadata makes rebuilding the index easier. Changing embedding models may require vector representations to be recalculated: this takes time and deserves a budget.
Test a genuine fallback solution
A second API key stored in a vault is not a business continuity plan. The alternative model must be evaluated against representative scenarios: difficult cases, imperfect French, long documents, manipulation attempts and structured outputs. Test data must be anonymised or used within an authorised framework.
- Quality: does the response remain usable for the business?
- Reliability: do the expected formats and safeguards hold up?
- Operations: do response times, quotas and costs remain acceptable?
- Compliance: does the processing meet the commitments made to the customer?
This assessment should lead to a straightforward decision: which functions can switch over, which will operate in a reduced-functionality mode, and which must stop? For a sensitive operation, it is better to withhold a response than silently provide a less reliable result.
The contract is part of the product
In their early days, many start-ups accept standard terms with a credit card. That is quick, but the arrangement does not necessarily provide the safeguards their own customers expect. Before promising high availability or strict data location requirements, they must check what the provider actually guarantees for the specific plan purchased.
Negotiations should focus on issues that could interrupt operations: advance notice of a model’s retirement, notification of pricing changes, quotas, support and suspension procedures. An availability commitment may offer service credits rather than compensation for business losses. That means reading the exclusions, liability caps and remedies, not just the headline percentage.
Data questions are equally concrete: are inputs and outputs used for training? How long are they retained? Which subprocessors are involved, in which regions, and how can the data be deleted? A commercial privacy option is no substitute for reviewing the data processing agreement. In a European context, commitments must, in particular, be consistent with applicable GDPR obligations.
Finally, the customer contract must reflect this reality. It can set conditions for using and replacing subcontractors, specify the functions available in reduced-functionality mode and establish how customers will be informed. Be careful not to promise an automatic substitution if it changes processing locations or agreed safeguards.
Make exit readiness a regular exercise
The best indicator is not the number of providers integrated, but the time needed to restore an acceptable service. A limited-scope switchover exercise reveals hidden dependencies: insufficient quotas, proprietary features and unexpected costs. Hosting an open-weight model is also worth considering, but should not be presented as cost-free independence: computing resources, maintenance and expertise still need funding.
What next? If the market continues its rapid pace of renewal, start-ups able to compare and replace their components should be better equipped to absorb disruption. The goal is not to leave a preferred provider, but to be able to stay by choice. From the very first customers, a test suite, a fallback plan and realistic contractual commitments provide far more credible strategic insurance than a promise to migrate “in a few days”.