A model can perform brilliantly in a pilot and still become an enterprise risk in production. The danger may not be a bad answer. It may be a contract dispute, a policy change, an unavailable feature, a regional restriction, a security incident, a sudden price shift, or a disagreement about permitted use.
That possibility became unusually visible on 28 August 2026, when a US federal judge blocked the Pentagon's designation of Anthropic as a supply-chain risk. Reuters reported that the dispute grew from disagreements over limits on the use of AI for surveillance and autonomous weapons. The court ruling concerns a specific legal and government-procurement conflict; it should not be generalized into a verdict on ordinary enterprise vendors.
It does, however, expose a broader operating question: what happens to a critical workflow when the buyer and the AI provider no longer agree?
The responsible answer cannot be “we will decide later.” AI sourcing needs an exit plan before exit becomes urgent.
Vendor risk is larger than uptime
Traditional resilience planning often focuses on service availability. Does the provider publish an uptime commitment? Is there disaster recovery? How quickly will support respond?
Those questions remain necessary, but AI introduces additional dependencies. A workflow may rely on a model's particular tool-calling behavior, context window, safety policy, output format, embeddings, evaluation method, and data-retention terms. Even when another model is available, it may not behave as a drop-in replacement.
There is also policy dependency. Providers define acceptable-use boundaries and can change them. Buyers have their own regulatory obligations, risk appetite, and ethical limits. A use case can become unworkable even when both parties act consistently with their respective principles.
This is not an argument for distrusting providers. It is an argument for treating alignment as an explicit requirement rather than an assumption.
Start with the business service, not the model
An enterprise inventory should describe the service that the AI supports: customer inquiry resolution, document review, fraud investigation, route planning, knowledge retrieval, or another business capability. It should then record the model and supporting components used to deliver that service.
This order matters. If the asset register starts and ends with a model name, teams can miss the actual impact of a change. A single model may support several journeys with very different criticality. Conversely, one customer journey may depend on several providers, databases, connectors, and human review queues.
For each AI-enabled service, document the owner, users, data classes, permitted decisions, maximum acceptable outage, fallback process, and customer or regulatory commitments. That creates a basis for deciding how much resilience is justified.
A low-risk copywriting assistant may tolerate days of disruption. A system supporting time-sensitive operational or financial decisions may need an immediate manual path. Resilience should follow business criticality, not enthusiasm for technology.
Portability has several layers
“We can switch models” sounds reassuring until a team tries to do it. Portability should be tested across at least four layers.
**Data portability** asks whether prompts, conversation records, evaluation cases, embeddings, and configuration can be exported in usable formats. It also asks what must be deleted and how deletion is evidenced.
**Application portability** asks how tightly the workflow is coupled to proprietary APIs, tool definitions, response schemas, authentication, and streaming behavior. An abstraction layer can help, but an abstraction that hides every provider-specific capability may also reduce product quality. The goal is deliberate coupling, not artificial sameness.
**Behavioral portability** asks whether an alternative can reach an acceptable outcome. Models differ in instruction following, refusal patterns, language quality, reasoning, latency, and error modes. Passing the same prompt is not evidence of equivalent service.
**Operational portability** asks whether monitoring, incident response, approvals, support, and human fallback still work after the switch. A technically successful migration can fail if reviewers are unprepared for a different exception profile.
Each layer needs evidence. Architecture slides are not enough.
Define policy boundaries in the contract and the product
AI contracts increasingly need to address more than price and service levels. Buyers should understand permitted use, prohibited use, data handling, model training, retention, subcontractors, intellectual-property treatment, change notification, audit evidence, and termination assistance.
The product must enforce those boundaries too. If an agreement prohibits certain data from reaching a model, the control cannot live only in a procurement document. It should appear in data classification, routing rules, access control, logging, and user guidance.
Similarly, if the provider changes a material policy or model version, the organization needs a decision path. Who assesses the change? Which evaluation suite is rerun? Can the update be delayed? When must risk, legal, security, product, and operations leaders approve continued use?
Clear boundaries reduce surprises for both sides. They also make disagreement manageable before it becomes a crisis.
Build a graceful degradation ladder
Resilience does not always require a second provider running at full scale. A practical design can use a ladder of fallback options.
At the first level, retry a transient failure within a strict limit. Next, route to a smaller or previous approved model for cases it can safely handle. Then narrow the feature: provide retrieval without generation, create a draft without taking action, or accept only lower-risk requests. After that, send the case to a human queue with the necessary context. Finally, pause the service clearly if no safe path remains.
Every step should specify the trigger, owner, customer message, data handling, and recovery objective. The ladder should avoid silent degradation that produces lower-quality decisions without informing anyone.
This design is especially important for agentic systems. If an agent can call tools or update records, a fallback model must not inherit the same permissions automatically. Capability and confidence should be reassessed together.
Test the exit while the relationship is healthy
Exit plans often look convincing on paper because their assumptions have never been tested. A tabletop exercise can reveal missing owners and contracts. A technical test can reveal incompatible schemas, inaccessible logs, lost evaluations, or unacceptable quality.
Teams can select a representative slice of traffic and run it through an approved alternative without affecting customers. Compare task success, error categories, latency, cost, review effort, and policy compliance. Export a sample of required records. Rebuild a small knowledge index. Verify credential rotation and deletion procedures. Time how long it takes to activate the human fallback.
The objective is not to prove that switching is effortless. It is to know the real switching cost and reduce the most dangerous unknowns.
Procurement can support this with termination-assistance clauses, export formats, notice periods, and pricing transparency. Architecture can limit unnecessary coupling. Product can define the minimum acceptable experience. Operations can maintain the manual path. Risk and legal teams can identify non-negotiable boundaries.
Optionality is a managed capability
Multi-vendor architecture is sometimes presented as automatic protection. It is not. Supporting several providers adds integration, testing, security, procurement, and operational cost. An unused fallback can decay quietly until it fails when needed.
Optionality therefore needs ownership and maintenance. Critical services may justify frequent failover tests. Lower-risk services may only need portable data, documented reconstruction steps, and an acceptable manual process.
The central principle is proportionality: invest in exit readiness according to the impact of losing the service.
The recent Anthropic-Pentagon dispute is exceptional in its legal and political context. Its durable lesson for enterprise teams is simpler. Vendor relationships can change for reasons beyond system uptime, and AI products can carry dependencies that ordinary software questionnaires do not reveal.
A strong vendor strategy is not a prediction about which provider will fail. It is a disciplined answer to what the business will do if assumptions change.
**Discussion:** If your primary AI provider became unavailable tomorrow, which would be hardest to replace: the model, the data, the workflow, or the governance approvals?
Sources
- [Reuters — US judge blocks Pentagon's Anthropic blacklisting, 28 August 2026](https://www.reuters.com/legal/government/us-judge-blocks-pentagons-anthropic-blacklisting-2026-08-28/)
- [NIST — AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [NIST — Generative AI Profile, AI 600-1](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)