DeepSeek-R1 is a reasoning model built by a Chinese AI lab. It runs as a fully managed model on Amazon Bedrockin Virginia, Ohio, and Oregon. These two facts are mechanically boring and politically radioactive, and if you sell into public sector accounts, you'll encounter the politics long before anyone asks about the mechanism.
The business logic for why it's on Bedrock at all is straightforward: DeepSeek-R1 is published under an MIT license, its reasoning benchmarks are competitive with frontier models, and AWS hosts dozens of third-party models as a platform play. Amazon added a high-performing, permissively licensed model to its marketplace. Same business logic behind every other third-party model on Bedrock. What follows is the mechanism behind that hosting, so you can respond to buyer concerns with something more useful than a shrug.
What a model file actually is
A model file is a static collection of numerical weights, frozen at the moment training ended. DeepSeek-R1's weights are published under an MIT license, the most permissive open-source license in common use: anyone can copy, modify, host, and sell the model with no obligation to the original creator. No royalties. No data-sharing clause. No phone-home requirement.
A note on terminology that will matter in buyer conversations: DeepSeek-R1 is an open-weight model, not a fully open-source model. The weights and inference code are public. The training data and training pipeline are not. Industry commentary often uses "open-source" loosely here. The distinction matters because the withheld training data is the core of the provenance concern covered below.
When AWS serves DeepSeek-R1 on Bedrock, the weights sit on AWS-managed infrastructure. Your API call hits an AWS endpoint. Inference runs on AWS compute. The response returns from AWS. No network traffic leaves AWS infrastructure for DeepSeek's servers. AWS states this directly: "Users' inputs and model outputs are not shared with any model providers."
The model has no network agency. It doesn't make outbound calls. It is a very large math function that produces outputs when given inputs, running inside infrastructure you already trust for classified-adjacent workloads.
- Model file: A static artifact. DeepSeek-R1's weights are frozen parameters with no runtime network access and no connection to DeepSeek's infrastructure.
- No data path to DeepSeek: When served on Bedrock, all inference happens on AWS compute. No prompts, outputs, or telemetry flow to DeepSeek or any infrastructure outside your AWS account.
Three things your buyer is conflating
The "DeepSeek sends data to China" concern bundles three distinct things into one fear. Separating them is the entire job.
The model is a file. DeepSeek-R1's weights are publicly available, MIT-licensed, and independently downloadable from Hugging Face. Any researcher can grab the same artifact and inspect it. AWS doesn't expose a mechanism to verify that the managed-service weights match the public download. You're trusting AWS on that, which is the same trust you extend for every managed service on the platform. The weights themselves are independently auditable outside Bedrock. The model does not connect to DeepSeek. It does not update itself. It does not exfiltrate data.
The hosting environment is AWS. Bedrock serves DeepSeek-R1 from US commercial regions only, with cross-region inference staying within the US geography. AWS applies its standard security controls: encryption at rest and in transit, IAM-based access, VPC connectivity. Customers can layer Bedrock Guardrails on top for content filtering and sensitive information detection. AWS explicitly recommends Guardrails for DeepSeek deployments.
Telemetry stays in your AWS account. Inference logs, usage metrics, and model outputs remain within the customer's account boundary. There is no telemetry channel to DeepSeek. Architecturally identical to how Bedrock handles every other model provider: the model provider gets nothing from your usage.
On data residency and telemetry, the separation is clean. Your data does not go to China.
- Hosting separation: Your prompts and outputs stay in US AWS regions, governed by your IAM policies. No usage data flows to DeepSeek. The model provider receives nothing from your inference calls.
You've deployed this pattern before. A Thales or Gemalto authentication module running on your infrastructure, where the vendor's country of origin doesn't determine where your authentication traffic flows. The deployment boundary is your trust boundary. Where the analogy breaks: With an identity product, you can audit the code or validate behavior against known specifications. With a model trained on undisclosed data, you inherit whatever the training data embedded. Hosting separation governs where your data flows. Training-data provenance is a separate question that lives upstream of any deployment decision, and hosting can't reach back to answer it.
Where the separation doesn't hold
Three concerns survive the hosting boundary.
Training-data provenance. DeepSeek has not disclosed what data R1 was trained on. The open-weight release includes the weights and inference code, not the training data or training pipeline. You can inspect the weights. You cannot reverse-engineer the training corpus from them. Reporting on efforts to "de-censor" DeepSeek-R1 has consistently noted that Chinese government censorship shaped the training data itself, not just the post-training alignment, making full removal non-trivial. The China Media Project, which tracks CCP propaganda in AI outputs, found that template responses repeating official Party viewpoints have increased over time in DeepSeek's products, suggesting growing government involvement. This is a durable unknown. Better documentation won't close it.
Embedded content behaviors. Documented, not speculative. Enkrypt AI, a commercial AI security firm, tested DeepSeek-R1 against 300 geopolitical questions and found 91.2% of responses on China-related disputes favored the Chinese government's position. (The methodology is transparent and the sample is narrow enough that the percentage describes a specific test, not a universal rate. Use it as evidence of a pattern, not a headline number.) A systematic preprint on arXiv, not yet peer-reviewed, identified two censorship patterns in the weights themselves: template responses echoing CCP talking points, and outright refusals concentrated on topics like Tiananmen Square.
A security analysis on Medium, citing CrowdStrike research, reported something more operationally concerning: when DeepSeek-R1 was told it was writing code for infrastructure in politically sensitive regions like Tibet, the rate of severe security vulnerabilities in generated code jumped nearly 50% above baseline. The primary CrowdStrike publication is not publicly linked in this reporting, so treat the finding as credible but secondhand.
Some censorship is app-layer only. Running R1 locally instead of through DeepSeek's website unlocks answers it previously refused. But the weight-level behaviors documented above persist regardless of where you host the model. Bedrock Guardrails can filter outputs, but they're catching symptoms downstream of a cause that lives inside the weights.
The regulatory picture is formally unsettled. The Biden administration's AI Diffusion Rule would have created export controls on advanced AI model weights but explicitly carved out published open-weight models like DeepSeek-R1. BIS rescinded the rule in May 2025 before it took effect, calling it "overly bureaucratic," and announced a replacement that hasn't materialized. As of today, no operative federal regulation controls deploying a published MIT-licensed model on US infrastructure. Legal analysts at JustSecurity, a national security law publication, have noted that existing export control frameworks weren't designed for AI model outputs at all. That could change. Nobody has a clean answer yet.
- Training-data provenance: Hosting separation can't address this. The model inherited whatever its training data contained, and that data has not been disclosed.
- Embedded content behaviors: Documented in the weights, not just the app layer. Guardrails filter outputs but the model's internal tendencies remain.
- Regulatory status: No current restriction on deploying published open-weight models on US infrastructure. Replacement rules are pending.
What the agency bans actually target
Multiple federal agencies moved fast when DeepSeek went viral in January 2025. The Pentagon, Navy, NASA, DOE, and the House of Representatives all issued restrictions. The specifics of what they restricted deserve a closer read than the headlines suggest.
NASA's memo is the most precisely worded: it cited that DeepSeek's servers "operate outside of the United States, raising national security and privacy concerns." That rationale is specific to the hosted service and does not cover the model running on AWS in Virginia.
The Navy's memo used broader language, prohibiting use of DeepSeek "in any capacity." Whether that covers the open-weight model running on authorized US infrastructure is unresolved. No public clarification has surfaced. The Department of Energy took a middle path: its CIO prohibited DeepSeek on DOE assets but allowed exceptions for AI research at national labs.
Australia's government-wide ban targeted "DeepSeek products, applications and web services" on government systems. Security researchers immediately noted the enforcement gap: the open-weight nature of the model means anyone can host their own instance, and the directive's language doesn't cleanly address that scenario.
No government-wide OMB directive addresses the specific case of deploying DeepSeek-R1 as an open-weight model on FedRAMP-authorized cloud infrastructure. The White House conducted an informal review but nothing formal resulted. Bipartisan legislation to ban DeepSeek on government devices has been introduced in both chambers but targets the app and hosted service.
Worth flagging for your next public sector conversation: DeepSeek-R1 on Bedrock is available in US commercial regions only. Bedrock itself operates in GovCloud with FedRAMP authorization, but no AWS documentation confirms DeepSeek-R1 among the models available there. For buyers requiring GovCloud or IL4/5 environments, this is a hard constraint today. Verify against current AWS model availability before making commitments.
- Agency bans: Overwhelmingly target the DeepSeek hosted service and app, not the open-weight model on US infrastructure. The Navy's "in any capacity" language is the notable exception, and its scope for the Bedrock scenario is unresolved.
- GovCloud availability: DeepSeek-R1 is not confirmed available in AWS GovCloud. Public sector buyers requiring FedRAMP/IL-authorized environments should verify current availability directly.
How to have this conversation accurately
When a buyer says "we can't use DeepSeek, it sends data to China," they're conflating the hosted service with the model file. Acknowledge the concern is legitimate for the DeepSeek app and API, then separate it: the model on Bedrock runs on AWS, your data stays in your AWS account, and there is no network path to DeepSeek's infrastructure.
Then name what's genuinely unresolved. That's what earns you the room. The training data hasn't been disclosed. The model carries documented content biases from Chinese censorship norms that persist in the weights regardless of where you host them. The regulatory picture could shift. And the model isn't in GovCloud.
The buyer who hears you distinguish the real concern from the misconception will trust you more than the one who hears you dismiss the whole thing. The spec calls this "hosting separation," which is an accurate term for what it solves and a generous term for what it doesn't.
Things to follow up on...
- BIS replacement rule status: The Bureau of Industry and Security rescinded the Biden-era AI Diffusion Rule in May 2025 and promised a replacement, but no new rule has been issued as of this writing, leaving open-weight model deployment in a regulatory gap.
- De-censoring efforts and limits: Multiverse Computing and Perplexity have both released variants of DeepSeek-R1 claiming to remove embedded censorship, but MIT Technology Review's reporting suggests training-data-level censorship may resist post-hoc removal.
- No DeepSeek on Government Devices Act: Bipartisan legislation introduced in both the House and Senate would formally ban DeepSeek on federal workers' devices, though the bills target the app and hosted service rather than open-weight deployments on authorized cloud infrastructure.
- CrowdStrike's code vulnerability finding: Research reportedly showed DeepSeek-R1 generates significantly more insecure code when given politically sensitive context, a finding reported secondhand that warrants tracking for a primary CrowdStrike publication.