For regulated teams that have been rejecting Chinese models on governance grounds, the access paths for DeepSeek have multiplied, and that changes the shape of the objection. “We can’t use Chinese models, compliance” stops being absolute. It becomes a per-token decision: pay Azure’s markup for enterprise perimeter controls, self-host the open weights for full sovereignty at engineering cost, or accept the governance risk of hitting DeepSeek’s direct API. The bottleneck shifts from “prohibited” to “justified.”
Why did compliance block DeepSeek for regulated teams?
DeepSeek publishes open weights and a direct API, and for a regulated enterprise that is precisely the problem. The direct API terminates at a vendor endpoint outside your cloud perimeter, with no contractually guaranteed data-residency posture and no integration with your identity provider, audit logging, or network controls. The weights are open, but running them on your own GPUs means sourcing infrastructure, operating it, and then defending the supply-chain provenance of Chinese-origin model files to your auditor. Neither path fits the controls a financial-services or healthcare security review expects.
Azure-hosted DeepSeek reframes the problem because the model becomes a “model sold by Azure,” delivered inside Microsoft’s managed boundary. The same prompts that would have left your network stay within an Azure service, subject to Azure’s data-privacy commitments for Foundry Models: prompts, completions, embeddings, and training data are not made available to other customers, not made available to the model provider, and not used to train foundation models without customer permission. That is not the same as the model being stateless. When optional stateful features such as the Responses API, Threads, or Stored completions are enabled, the service creates a data store to persist message history, in accordance with how the feature is configured.
The model is still DeepSeek. The governance wrapper is Microsoft’s. That is the compliance handoff.
What are the three paths to running DeepSeek?
A team evaluating DeepSeek now faces three structurally different routes, each with a different cost and a different governance posture.
Direct API. You call DeepSeek’s published endpoints. This is the cheapest option on paper and the one that gives your security team the most to write up. There is no enterprise SLA, no Entra ID integration, no data-residency commitment beyond what DeepSeek’s own terms provide, and the endpoint sits outside any cloud perimeter your auditor already trusts.
Azure AI Foundry. DeepSeek is hosted as a Microsoft-managed offering. You get Azure-hosted infrastructure, Entra ID authentication and RBAC, Azure networking and governance, monitoring and diagnostics, and Microsoft support with service availability commitments, per the Q&A response describing Foundry’s platform capabilities. You also get Azure’s pricing meters, which is where the cost conversation starts.
Self-hosted. You pull the weights and run inference on your own GPUs. This is the maximum-sovereignty path: data never leaves your hardware, the weights are auditable, and the deployment can satisfy GDPR or China’s CSL on your own terms. Galileo’s comparison of DeepSeek R1 hosting options puts self-hosted R1 at roughly $0.55 per million input tokens and $2.19 per million output tokens, factoring in GPU and operations overhead. That is cheaper than Azure’s hosted rates, but the line item hides the engineering cost of keeping a serving stack healthy.
| Route | Input (per 1M tokens) | Output (per 1M tokens) | Governance posture |
|---|---|---|---|
| DeepSeek direct API (V4-Pro) | $0.435 (cache miss) | $0.87 | Vendor endpoint, no enterprise SLA |
| Azure AI Foundry (V4-Pro) | ~$1.96 | ~$3.92 | Microsoft perimeter, Entra ID, enterprise controls |
| Self-hosted (R1) | ~$0.55 | ~$2.19 | Full sovereignty, GPU + DevOps overhead |
The direct-API input figure also hides cache-hit pricing of $0.003625 per million tokens. If your workload is cache-friendly, the direct API is dramatically cheaper than even self-hosting. Azure’s caching behavior for DeepSeek is not documented in the Q&A, which makes head-to-head comparisons unreliable without measuring your own traffic.
What does Azure’s markup actually buy you?
Roughly 4.5x, and the question is whether that premium purchases something your security review would otherwise cost you in engineering time.
The markup is not for the model. It is for the wrapper. The same Microsoft Q&A response enumerates what the Azure meter covers: Azure-hosted compute, enterprise security and compliance controls, Entra ID authentication with RBAC, Azure networking and governance, monitoring and diagnostics integration, and Microsoft support with service availability commitments. None of those are model capabilities. They are the platform features a regulated enterprise would otherwise have to build, contract for, or do without.
The separation guarantee is the part most likely to unblock a stalled review. Microsoft hosts the Models sold by Azure in its own Azure environment, and the data-privacy commitments state that Models sold by Azure do not interact with any services operated by the model provider, that prompts and completions are not made available to the provider, and that they are not used to train foundation models without customer permission. For a team whose security review turns on whether prompts reach the vendor, that is a contractually backed answer rather than a blog-post promise.
How does Vercel’s AI Gateway fit into the compliance path?
Vercel’s AI Gateway is a separate access layer, not a route to Azure-hosted DeepSeek. Vercel’s model page for DeepSeek V3.1 credits the provider as DeepSeek, consolidating thinking and non-thinking inference into a single endpoint accessible through the deepseek-chat and deepseek-reasoner API identifiers. The compliance value is Vercel’s own gateway posture, not Microsoft’s perimeter.
The compliance-relevant detail is the Zero Data Retention posture, and its scope is narrower than it sounds. Vercel supports Zero Data Retention for direct gateway requests; bring-your-own-key (BYOK) deployments are explicitly excluded. A team that routes through the gateway gets the retention guarantee. A team that plugs in its own provider credentials does not. If your compliance argument depends on Zero Data Retention, the routing topology is part of the control, not just the provider choice.
The gateway also handles authentication. Requests authenticate with an API key or OIDC token, and the developer does not manage provider credentials directly. That reduces the surface area a security review has to cover: one integration, one auth path, one retention posture, rather than per-provider credential sprawl.
When does the Azure-hosted tradeoff make sense?
It makes sense when the governance burden of the alternatives exceeds Azure’s per-token premium, and that calculation is sensitive to volume.
At low to moderate volume, Azure’s markup is tolerable. A workload spending $200 a month on DeepSeek’s direct API becomes roughly $900 a month through Azure. For a regulated team that has already budgeted for enterprise tooling and was previously blocked from DeepSeek entirely, paying $700 more to unblock a capable model is a straightforward decision. The cost of the engineering alternative, self-hosting, is dominated by the GPU lease and the on-call burden, not the token rate.
At high volume, the math inverts. A workload spending $20,000 a month on the direct API becomes $90,000 through Azure. At that point the $70,000 monthly delta funds a serious self-hosting operation: GPUs, a serving stack, and an engineer to maintain it. The Galileo figures suggest self-hosted R1 runs around $0.55 per million input and $2.19 per million output tokens, which under high volume undercuts Azure’s hosted rates substantially. The crossover depends on your cache-hit rate, your GPU utilization, and how much you value Microsoft’s SLA over your own on-call rotation.
What is the real bottleneck now?
The compliance objection was always doing two jobs: it was a governance concern, and it was a convenient reason not to do the cost work. Azure-hosted DeepSeek removes the first job. The model is reachable through Azure’s perimeter with privacy commitments you can cite in Microsoft’s docs, or through Vercel’s gateway with its own Zero Data Retention guarantee. The “we can’t” becomes “we chose to” or “we chose not to.”
What remains is the second job, the one that is harder to outsource. The bottleneck is now cost-per-token, and specifically whether Azure’s posture satisfies your specific regulator. Azure’s data-privacy commitments are strong on paper: prompts are not shared with the model provider and are not used to train foundation models. But “satisfies your regulator” is not a property Microsoft can certify for you. A financial-services regulator in Frankfurt, a healthcare authority in the US, and a data-protection officer reading CSL will each weigh the same documentation differently.
Azure-hosted DeepSeek does not make Chinese models safe. It makes them governable. The difference is that “governable” is a posture your security team can sign off on, with cited commitments and a named vendor on the hook, rather than a binary exclusion driven by the model’s country of origin. For teams that were blocked, that is the change that matters. The per-token premium is the price of converting an objection into a decision.
Frequently Asked Questions
Does Azure-hosted DeepSeek meet EU data residency requirements?
Azure Foundry’s DataZone deployments can process prompts and responses within any EU Member Nation, while data stored at rest remains in the customer-designated geography. That covers processing-location requirements for many regulated workloads, though your specific auditor or regulator may still ask for additional attestations.
How do Azure Foundry’s Global and DataZone deployments differ?
DataZone deployments restrict prompt and response processing to a specified geography, such as the EU, while Global deployments do not carry that same zone restriction. In both cases, stored data stays in the customer-designated geography, so the choice affects where inference runs, not where backups live.
What is the cheapest DeepSeek path for a cache-friendly workload?
DeepSeek’s direct API on cache hits, at $0.003625 per million input tokens. That rate can undercut even self-hosted R1 if your prompts are repetitive, and it is far below Azure’s observed ~$1.96 per million input tokens. Azure’s cache behavior for DeepSeek is undocumented, so the direct API is the only path with published cache-hit pricing you can model against.
Why can’t the Azure 4.5x rate be used to price Vercel’s DeepSeek gateway?
The 4.5x observation applies to DeepSeek-V4-Pro on Azure AI Foundry, while Vercel’s AI Gateway currently lists DeepSeek V3.1. The two are separate SKUs with separate provider relationships, so the Azure rate table cannot be transposed to predict Vercel gateway spend.
