Parag K Adarkar

Insights Resilient AI strategy

Your AI strategy cannot depend on one model

Parag K Adarkar · · 5 min read

AI strategyEnterprise AIAI governance

On 12 June 2026, Anthropic disabled access to its two most capable models, Claude Fable 5 and Claude Mythos 5, for all of its customers. The reason was not a technical failure. A US export-control directive arrived that afternoon, and the company had to comply. Access was restored on 1 July, after the controls were lifted. For nineteen days, any organisation that had built critical processes on those two models alone had a problem it could not solve by itself.

I am not raising this to criticise one provider. Every major AI vendor will face some version of this. I raise it because it made visible something that enterprise technology leaders should already have known:

Models change. Access changes. Regulations evolve. Provider policies shift.

Four forces that will keep changing your AI

Models change. Providers release new versions every few months and retire old ones on their own timetable. A regulated enterprise, by contrast, may need weeks or months to re-validate a process when the model underneath it changes.

Access changes. Outages, capacity limits, regional restrictions and, as June showed, government action can all take a model offline with little or no warning.

Regulations evolve. In India, the Digital Personal Data Protection Rules were notified in November 2025, with obligations phasing in over the following months. Rules on where personal data may be processed, how consent is captured and how long data is kept directly shape which AI services an Indian utility can use for which tasks. Similar shifts are under way in Europe and elsewhere.

Provider policies shift. Pricing, rate limits, usage policies and terms of service are set by the vendor and can change mid-contract.

None of these is unusual. Enterprises have always managed suppliers who change. What is new is how quickly AI has moved from experiments into everyday processes, often before anyone asked what happens if the model is not there tomorrow.

The real differentiator: resilient AI architecture

Organisations that can absorb an event like this calmly share one trait: they treat models as replaceable components, not as the foundation. In practice, that means five design choices.

1. Own the layer between your business and the model. Put an internal gateway or orchestration layer between applications and AI providers. It routes each request by cost, sensitivity and availability, fails over when a provider goes dark, and keeps a single audit trail. Your workflows talk to your layer, never directly to a vendor.

2. Keep your evaluations, not just your prompts. Maintain a set of test cases drawn from your real work, such as sample complaints, bills, contracts and fault reports, with known good answers. When you need to switch models, you can prove in days, not months, that the replacement performs well enough.

3. Match the model to the task. Not every task needs the most capable frontier model. Smaller, cheaper or open-weight models often handle classification, extraction and routine drafting well, and they give you an option you control.

4. Know where your data goes. Classify which data may be sent to which provider and region. Under the DPDP regime, this is not optional for personal data, and for a utility it also applies to sensitive operational and grid information.

5. Design a non-AI fallback for critical processes. Billing must run, complaints must be logged and outages must be restored whether or not a model is available. AI should make critical processes faster; it should never become a single point of failure for them.

Governance that travels across providers

Resilience is not only an architecture question. It needs a governance model that does not depend on any single vendor’s tooling. Two frameworks are good starting points:

  • The NIST AI Risk Management Framework, with its Generative AI Profile (NIST AI 600-1) published in July 2024, gives a practical structure to govern, map, measure and manage AI risks.
  • ISO/IEC 42001:2023 defines an AI management system that can be audited and certified, in the same way many utilities already manage information security under ISO/IEC 27001.

Both are provider-neutral, which is exactly the point.

So what matters most?

I recently put a question to my network on LinkedIn: what is more important for enterprise AI today: the best model, the lowest cost, governance, security or flexibility?

My answer is that flexibility, backed by governance, is what makes all the others possible. The best model this quarter may not be the best next quarter. The lowest cost today may change with the next price list. Security and compliance requirements will tighten. An organisation that can switch, test and govern across providers can keep choosing the best option. One that cannot is locked into today’s choice.

Five questions for your next AI review

  1. If our main AI provider were unavailable tomorrow, which business processes would stop?
  2. How long would it take us to move a critical use case to another model, and how would we prove it still works?
  3. Do our applications call AI providers directly, or through a layer we own?
  4. Do we know which data, belonging to whom, is sent to which provider and in which country?
  5. Who is accountable for each AI-assisted process, and what is the manual fallback?

The question is not just “Which model should we use?” It is: can our AI strategy withstand change?

Sources