This is an operational verification alert, not confirmation that every affected endpoint changed in exactly the same way.
Databricks announced that Anthropic models would be removed on September 19, 2026 from AWS GovCloud and AWS GovCloud DoD workspaces with DoD IL5 selected. The announced date has passed. Because no separate post-event completion artifact was available in our September 20 check, affected operators should test the live state rather than infer it from the calendar.
The exact scope matters
| Field | Documented scope | Do not assume |
|---|---|---|
| Platform | Databricks on AWS | Azure or Google Cloud behavior |
| Region class | AWS GovCloud and GovCloud DoD | Commercial AWS regions |
| Compliance setting | Workspaces with DoD IL5 selected | Every government workspace |
| Models | Anthropic models | All foundation models |
| Announced date | September 19, 2026 | Identical completion time for every endpoint |
Run a five-minute verification before a production incident
- Identify the workspace region and confirm whether DoD IL5 is selected.
- List every endpoint, serving configuration and application alias that can route to an Anthropic model.
- Send a low-risk test request through the same path production uses.
- Attempt the documented create or update operation in a non-production environment.
- Inspect audit logs and application fallbacks for silent rerouting.
- Record the timestamp, model identifier, response and error code.
Do not treat a successful cached response, playground test or alternate commercial endpoint as proof that the IL5 production path is available.
A fallback can create a compliance problem
An application may be configured to retry another model or region after an endpoint failure. That behavior can preserve uptime while violating an approved data route or model list. Verify the fallback target, geography, retention policy, identity boundary and logging before enabling it. The AWS sovereign-cloud model guide explains why model availability and deployment boundary must be evaluated together.
Existing and new endpoints may fail differently
A provider can block new endpoint creation before disabling an existing serving path, or reject new requests while configuration objects remain visible. Test creation, update and inference separately. Also check aliases and model-router rules that may hide the underlying model name.
Build the migration record before switching
- Approved replacement model and exact version
- Workspace, region and compliance selection
- Prompt and tool compatibility results
- Safety, refusal and structured-output regression tests
- Latency and cost comparison under representative load
- Rollback condition and responsible approver
For high-risk life-sciences workloads, the Anthropic verification-program guide illustrates another reason availability and authorization cannot be reduced to a model name.
Use an explicit escalation path
If the production-equivalent test fails, capture the request ID, endpoint, workspace, region, timestamp and exact error before changing anything. Notify the workspace owner and compliance owner together. Pause automated retries that could flood logs or trigger an unapproved fallback. Open a provider case with the documented scope and evidence, then decide whether the application should fail closed, enter a degraded mode or use an already approved replacement. Do not improvise a new region or model during the incident unless that route has passed the required authorization.
If the test succeeds, that result still needs a boundary. Record whether it covered an existing endpoint, a new endpoint, one model alias or the full application path. Schedule a second check and monitor for new provider errors. A successful point-in-time request does not override the published removal notice; it only documents what the tested route did at that moment. Share the record with the service owner so the next shift does not repeat the same uncertain diagnosis.
What is confirmed and what remains unknown
The confirmed fact is the Databricks notice and its stated September 19 removal date for the specified scope. The public record checked for this alert did not independently confirm the final state of every workspace, endpoint or request path after the deadline. That uncertainty is precisely why operators should verify now and preserve the result.
The practical verdict
If your Databricks workspace is in the documented IL5 scope, treat the deadline as an active change-control event. Test the production-equivalent route, inspect fallbacks and migrate only through an approved compliance path. If the workspace is outside the scope, do not create unnecessary incident work by generalizing the notice.
Keep the verification record with the service runbook and repeat it after any workspace, endpoint or routing change. Preserve the exact test input as well.
Primary source
Checked September 20, 2026. This alert deliberately distinguishes the published removal notice from unverified assumptions about post-deadline completion.
