It Works, But You Can't Ship It

Both providers work. Claude Sonnet 4.6 fills the government DOCX form on the first attempt — every field mapped, formatting preserved, no hallucinated values. After weeks of debugging the wrong architecture, the wrong upload method, and the wrong model versions, the technical problem is solved. The compliance problem hasn't started yet.

The implementation uses sandboxed code execution — the file goes into a container, the model reads the OOXML structure, writes python-docx modifications, and saves a valid binary. Piecing together the right API calls took time, but the result is clean.

GPT-5.4 on the public OpenAI API produces the same result independently. Different SDK, different container model, different file retrieval pattern — same filled form. Two providers, both working. The technical question is closed.

The Question That Stops It

The demo goes well. A client in the government-adjacent space watches the form fill in real time, checks the output, nods. Then someone from their compliance team asks: "Where does the data go when it hits that endpoint?"

The question isn't hostile. It's procedural. They ask it about every external service. But for this feature, the answer creates a problem.

This client runs on a regional cloud tenancy. Their data residency policy requires that document data stays within a specific jurisdiction. The AI feature routes their DOCX — containing names, addresses, case references — through an API endpoint outside their jurisdiction. No regional alternative exists for the sandbox infrastructure.

The Infrastructure That Doesn't Exist

I mapped the options after that meeting.

Anthropic code execution: the direct API runs code execution sandboxes in the US only. Azure AI Foundry supports it in East US2 and Sweden Central. Google Vertex AI doesn't support code execution at all. None of these cover the APAC regions this client needs.

OpenAI code_interpreter: same situation on the public API. Azure OpenAI technically supports the Responses API with code_interpreter, but the container infrastructure in non-US regions is unreliable — I hit timeout errors and empty responses testing on Azure that didn't reproduce on the public API. And the regions this client needs — Australia East, AP-Southeast — don't have the sandbox infrastructure deployed at all.

EU sovereign instances: not available for either provider's code execution features.

This isn't a configuration problem. There's no support ticket to file, no flag to set. The sandbox infrastructure that makes DOCX manipulation work does not exist in those regions today. Standard inference endpoints are available regionally — code execution sandboxes are not.

The Question That Should Have Come First

The data residency constraint wasn't hidden. It's in every provider's deployment documentation. Anthropic's data residency docs list US-only workspace geo for code execution. Azure AI Foundry adds Sweden Central but nothing in APAC. The Azure OpenAI docs list which features are available in which regions — code_interpreter coverage is sparse.

The constraint was discoverable. It was in the documentation. It was not in my scoping conversation.

If someone had asked "what cloud tenancy does this customer run on?" before I chose the code execution approach, the architecture decision would have been different. I might have scoped a local processing fallback. I might have flagged the feature as opt-in from the start.

The Fork That Isn't Technical

Two options, and one of them has to happen before the feature ships.

Option A: ship the feature as opt-in. Surface a clear data-handling disclosure at the point of use — "this document will be processed via [provider]'s global API" — and let the customer's compliance team make the call. Some will accept it. Some won't.

Option B: exclude customers under strict data-residency requirements entirely. Document why. Don't offer the feature in deployments where it can't meet the tenancy policy.

Neither option is wrong. Both require a product decision that no amount of engineering can avoid.

The Question That Comes First Next Time

For any AI feature that routes documents through an external API, ask the residency question in the first scoping conversation. The capability is real — both providers fill the form correctly. The constraint is also real, and there's no workaround on the horizon.