When a federal CISO says "DeepSeek is a security risk because it sends data to China," they're not wrong to be cautious. They're wrong about the mechanism. And that distinction is exactly what you need to hold before your next meeting.
The confusion is a category error: treating a trained model like a SaaS application. Fix the category, and the real concerns come into focus — the misconception stops crowding them out.
What a Trained Model Actually Is
A trained model is a file. More precisely, it's a large collection of floating-point numbers — the weights — plus configuration metadata that tells an inference engine how to use them. DeepSeek-R1, the model AWS offers through Bedrock, is roughly 671 billion parameters in its full version. That's a big file. No running process, no network stack, no ability to initiate a connection to anything. It is inert until a runtime loads it and executes inference against it.
The weights encode what the model learned during training. They do not encode a phone-home mechanism — the model has no persistent identity, no credentials, no callback address. It is, in the most literal sense, a static artifact. What happens when you run it depends entirely on the infrastructure running it.
Three Layers, Clearly Separated
The model. DeepSeek-the-company trained the model and published the weights. That relationship ended at publication. The weights are now a file that anyone with sufficient compute can download and run. DeepSeek-the-company has no ongoing technical relationship with those weights once they leave their servers.
The hosting environment. When AWS Bedrock serves DeepSeek-R1, inference runs on AWS hardware in US-East datacenters. AWS IAM governs who can invoke the model. The inference stack is AWS's, not DeepSeek's. No traffic from a Bedrock inference call traverses a path to China, because there is no such path in the architecture. AWS downloaded the weights; AWS runs them; AWS owns the infrastructure.
Telemetry. Your prompts and completions stay in your AWS account under AWS's standard data handling terms. DeepSeek-the-company never receives a Bedrock customer's inputs, because Bedrock doesn't route them there. The telemetry boundary is the AWS account boundary.
The "data goes to China" concern assumes a SaaS model — a service that phones home to its origin. That's not the architecture. The architecture is closer to downloading software and running it yourself.
The Concerns That Are Actually Real
Correcting the misconception is not the same as clearing the model. There are legitimate concerns, and a buyer who's done their homework will raise them.
Training data provenance. You don't know what was in the training corpus. That matters for government use cases where the model's implicit knowledge base could include problematic content, or where the training process may have introduced biases that affect outputs in ways that aren't immediately visible.
Embedded content policies. DeepSeek-R1 has documented refusal behaviors on certain topics — behaviors that were baked in during training and RLHF, not configured by you at deployment time. For some federal use cases, a model that declines certain queries or frames responses in particular ways is an operational problem, not just a theoretical one. This is a real evaluation question, and it belongs in any serious procurement conversation.
Export control. There are open, unresolved questions about whether certain uses of Chinese-origin AI models implicate Export Administration Regulations or other controls. This is genuinely unsettled territory. No one should be giving confident answers here without traceable legal guidance, and you should say so rather than paper over it.
The Conversation You'll Actually Have
Picture a procurement meeting at a civilian agency. The program officer has read something about DeepSeek and opens with: "We can't use this — it sends everything to Beijing." You have two options. You can say "no it doesn't" and watch the conversation go sideways, or you can ask which layer they're worried about.
If they're worried about data exfiltration through Bedrock, you can walk them through the hosting architecture. AWS US-East. IAM controls. No egress to China. That concern is addressable.
If they're worried about what the model was trained on, or whether its content policies are appropriate for their mission, or whether there are export control implications — those concerns are legitimate, and the right answer is to engage them seriously. Buyers who raise the real concerns deserve a real conversation. Buyers who raise the misconception deserve a correction that doesn't make them feel foolish for asking.
The goal isn't to sell DeepSeek. It's to be the person in the room who knows the difference between the layers, because that person is useful regardless of which model ends up in the contract.
Okta Concept Mapping
This maps most cleanly to the distinction between on-premises software deployment and a cloud service. When you deploy a SAML SP library on your own infrastructure, the library vendor doesn't see your authentication traffic — they shipped you code, you run it, they're out of the loop. DeepSeek on Bedrock works the same way for data residency purposes: AWS shipped the weights, you run inference, DeepSeek-the-company is out of the loop. The analogy holds for every question about network traffic and vendor access.
Where it breaks: a SAML library implements a specification. Its behavior is deterministic and auditable against the RFC. A trained model's behavior is a function of its training data and reinforcement process — neither of which you can fully audit by inspecting the weights. You can verify that no traffic goes to China. You cannot verify that the model's embedded content policies are neutral or appropriate for your use case. That's a different category of risk, and on-premises deployment intuition doesn't help you assess it.