On 23 July 2026, Politico published the headline Startup founders urge U.S. government not to shut off Chinese open weight AI. I am deliberately staying with the smallest hard fact from that link, the title. Four days later, Dario Amodei wrote in Our position on open-weights models that Anthropic has never advocated for a ban on open-weights models, while adding that reports suggest some U.S. officials are considering banning the use of Chinese open-weights models by U.S. companies.
That sequence gives production teams a new outage class. You can lose a model family when access terms move underneath you. Your dashboards can stay green the whole time.
The earlier piece here on model portability as a governance feature covered the harness boundary. Keep that harness under your control. This follow-up puts the same boundary inside disaster recovery.
The outage can come from policy, not a status page
Most AI recovery plans stop at provider uptime and rate limits. Add one more row: loss of access to a model family.
That loss can arrive through a licensing decision, an account action, or a provider decision that changes who may use what. The point for engineering is simple: a model dependency can fail without any technical fault inside your system.
If your agent stores state in a vendor thread object and leans on that vendor's tool and safety behavior, your recovery exercise starts with rewriting product logic. The dangerous combination here is a property of your wiring. Under pressure, teams call that a failover. In practice they are running a migration.
Treat model access as a continuity dependency. For each shipped AI workload, decide in advance whether you have an approved path from the hosted primary to an open-weight fallback, and what quality loss you will accept if that switch ever becomes necessary.
That is why the portability argument got sharper. The harness boundary buys you operator convenience on calm days. It buys you continuity when access conditions move underneath you.
Released weights change one recovery property
Anthropic's post contains the detail that matters for DR planning. It calls open-weights models that do not have dangerous capabilities a public good because they 'don't cost anything besides the compute needed to run them'. It also says that 'once weights are released they cannot be withdrawn'.
For recovery, that second sentence matters more than most benchmark charts. A hosted model can disappear behind an account ban or a contract change. A released model artifact gives you a different control point. Once you have an approved model, a way to serve it, and the compute budget to keep it alive, continued access no longer depends on one vendor's API gate.
You still need real plumbing. Someone has to approve the license. Someone has to provision capacity. Someone has to own the serving stack. Your fallback can run on your own GPUs or on a managed inference service that exposes open-weight models. The recovery property is continued access to the artifact plus an approved runtime path.
Anthropic also states the downside plainly. Open-weights models can present higher risk because guardrails are hard to apply and monitoring is hard to enforce after an irreversible release. That is useful guidance for workload selection. Keep open-weight failover away from flows whose safety case depends on provider monitoring or provider-enforced abuse controls.
I would keep hosted models as the primary for your highest-risk flows until your own testing and controls say otherwise. Disaster recovery asks for a classified fallback set. It does not ask you to pretend every workload has the same risk surface.
Classify workloads before the switch is urgent
Do this at the workload level, not at the model-family level. 'Can this workload run on open weights?' is too vague to help during an incident. 'Can support-ticket triage fail over to an approved open-weight model with a defined regression budget and no product changes?' is a plan.
On Monday, take your top five model-backed workflows and answer three questions:
Does this workflow trigger irreversible or high-risk side effects?
Can you define an eval set and a regression budget for it?
Does the workflow rely on hosted-only safety or monitoring controls?
This flow keeps the decision in one picture.
flowchart TD
A[Workload] --> B{High-risk or irreversible side effects?}
B -- No --> C{Defined eval set and regression budget?}
B -- Yes --> D{Hosted-only safety or monitoring required?}
C -- No --> H[Hosted-only for now]
C -- Yes --> E{Open-weight candidate passes eval budget?}
E -- Yes --> F[Portable now]
E -- No --> G[Portable with controls]
D -- Yes --> H
D -- No --> I{Schemas, validation, approval gates in place?}
I -- Yes --> G
I -- No --> H
If you already followed the earlier portability advice and kept the harness in your own stack, this classification takes an afternoon. If a provider still owns those pieces, the exercise will surface where the lock-in sits.
Use recent, real tasks for the eval set. A few dozen requests from production logs, scrubbed as needed, will tell you more than a synthetic benchmark that never touches your tools. Measure task success first. Then look at invalid tool arguments and the human-escalation load. Write the budget before you run the test.
A written threshold ends the 2 a.m. debate.
The buckets usually look like this:
Bucket
Good candidates
Required controls
Portable now
summarization, extraction, routing, retrieval post-processing, draft generation
no irreversible side effects, eval within budget, no provider-only safety dependency
Portable with controls
internal ticket creation, metadata updates, code suggestions, draft external replies
strict JSON schema validation, allow-listed tools, dry-run or human approval, rollback path
Hosted-only for now
wide-access coding agents, direct customer actions, regulated advice, workflows whose safety case depends on hosted monitoring
keep on hosted models until you replace the missing controls
Anthropic's post helps with the judgment here because it refuses hand-waving. The company supports mandatory safety testing for all sufficiently capable models, open and closed, and names concrete misuse concerns rather than leaving risk abstract. Your product probably does not sit on the biological frontier, but the structure of the advice transfers cleanly: test the concrete workload, then classify it.
Anthropic also says the added risk from open models, and whether that risk can be mitigated, should emerge from testing rather than assumption. Production teams should steal that sentence. Treat open-weight failover as something you validate on your own evals, not something you bless or reject in the abstract.
Give the failover path an owner, a trigger, and a rehearsal
Recovery plans fail in the handoff between architecture and operations. Someone on product has to own the primary model choice. Someone on platform has to own the fallback runtime. Legal or procurement has to bless the license terms. Security has to sign off on which workloads may use the fallback. If those names are missing, the path will not survive the first real dispute.
A short runbook for each approved fallback should record:
the primary hosted model
the approved open-weight fallback
where the fallback runs
which workloads may use it
the eval gate and allowed regression
who can authorize the switch and who can roll it back
which events trigger review or failover
when the team last rehearsed the path
Anthropic's policy position makes the broader lesson hard to ignore. The company backs keeping powerful chips and chipmaking equipment out of China, cracking down on smuggling, cracking down on industrial-scale distillation, and requiring safety testing for sufficiently capable models whether they are open or closed. Whatever you think of those positions, they show where model access now lives. It sits inside licensing and state policy as much as inside product selection.
Run the path before you need it. Replay saved requests through the fallback. Check schema validity first. Then time the cutover and watch the escalation load. Confirm that your team can switch routing without rewiring prompts or migrating transcript state under pressure.
Pick one bounded workload this quarter and prove the move. Summarization or extraction are good starting points because the side effects stay small and the evals are easy to define. If you can move one of those from your hosted primary to an approved open-weight alternative without changing product logic, you have started a real DR plan.
Steal this
Drop this into ai-model-dr.md and fill one out for each shipped AI workflow.
## AI workload DR record
- Workload:
- Owner:
- Product surface:
- Primary hosted model:
- Approved open-weight fallback:
- Fallback runtime:
- License review owner:
- Last drill date:
### Classification
- Bucket: portable-now | portable-with-controls | hosted-only
- Irreversible or high-risk side effects:
- Hosted-only safety or monitoring controls:
- Human approval required on fallback: yes | no
### Eval gate
- Eval set location:
- Success-rate floor:
- Invalid tool-call ceiling:
- Refusal-rate ceiling:
- Max latency increase:
- Max cost increase:
- Notes:
### Switch control
- Trigger events:
- vendor terms or pricing change
- policy or procurement block
- sustained outage or rate-limit failure
- failed safety review
- Switch authority:
- Rollback authority:
- Customer communication owner:
### Drill notes
- Last replay batch:
- Result:
- Fixes opened: