What a Trained Model Actually Is
A trained model is a file. More precisely, it's a large collection of numerical parameters, the weights, that encode the statistical relationships the model learned during training. When you deploy a model, you're working with a static artifact. It has no network stack, no background process, no mechanism to initiate outbound connections. It cannot call home because it is not a program that runs independently. It executes only when something invokes it, in the environment where it's deployed, under the access controls of that environment.
That's a description of the artifact's structure, not a contractual commitment.
The weights for DeepSeek R1 on AWS Bedrock are sitting in AWS infrastructure, in US-East data centers, governed by AWS IAM. When a Bedrock customer sends a prompt, the request goes to AWS. It is processed by AWS compute. The response comes back from AWS. DeepSeek, the company headquartered in Hangzhou, never sees the request, the response, or the customer's account metadata. There is no network path from a Bedrock inference call to anything in China. Telemetry stays in the customer's AWS account, under the same service terms that govern every other model on Bedrock. The model provider does not receive customer inputs. Full stop.
The question "is our data going to China" has a clean answer when the deployment is Bedrock: no, because the data never leaves AWS, and AWS is not DeepSeek.
IDAM Concept Mapping: The Certificate Analogy, and Where It Breaks
The closest identity concept here is the distinction between a certificate and the CA that issued it. A certificate is a static signed artifact — it doesn't phone home to the CA. What matters for trust is who signed it, under what policy, and whether the issuing authority is subject to controls you trust. The weights are the certificate; DeepSeek-the-company is the CA; AWS is the PKI infrastructure you're actually running on.
Where the analogy breaks: a certificate's provenance is cryptographically verifiable. You can read the certificate policy, audit the CA's practices, and verify the chain of trust. You cannot do any of that with trained weights. There is no cryptographic attestation of what training data went in, what behavioral constraints are embedded, or whether the artifact you received matches the artifact that was trained. The opacity is structurally different — and that's exactly where the real concerns live.
The Concerns That Are Actually Unsettled
Three things deserve accurate naming, because a buyer who is asking the wrong question may still be pointing at a real problem.
Training data provenance. What went into the training corpus is not publicly auditable. Whether it included data scraped from sources that create IP exposure, security-relevant content, or material subject to export controls is genuinely unknown. This is not unique to DeepSeek — it applies to most frontier models — but it's a real gap, not a dismissed concern. If your buyer's agency handles sensitive research or operates in a domain where training data contamination matters, this is a legitimate line of inquiry.
Embedded content policy. The model's refusal behaviors are baked into the weights. DeepSeek's models have documented patterns of deflecting on certain topics, primarily politically sensitive ones in the Chinese domestic context. This is a behavioral characteristic of the artifact, not a network characteristic. It has nothing to do with data leaving the country; it means the model's outputs may behave differently than expected on certain inputs. Whether that matters for a given use case is a real evaluation question, especially for public sector deployments where topic coverage and consistency matter.
Export controls. The legal status of frontier model weights under the Export Administration Regulations is genuinely unsettled. Commerce has been working on rules in this space for over a year, and the question of whether deploying certain weights in certain agency contexts creates compliance exposure has not been definitively answered. Flag it as open. Don't pretend it's resolved in either direction.
What to Do With This in the Room
When a CISO or procurement lead asks whether their data is going to Beijing, the accurate answer is: not via the hosting architecture. The request never leaves AWS. That closes the network question. The artifact questions are still open.
What's worth working through together is training data provenance, the model's behavioral characteristics on sensitive topics, and whether deploying these weights creates any compliance exposure for this agency's specific use case.
A buyer who gets a clean "no, you're wrong, there's no risk" is going to trust you less than a buyer who gets "the specific risk you're worried about isn't the architecture — here's what the architecture actually does, and here are the questions that are genuinely open." The second answer is also the accurate one, which helps.