DeepSeek DLP: One Model Name, Four Deployment Paths, Four Different Answers About Where Data Goes
DeepSeek models reach an enterprise through at least four paths: the vendor API, self-hosted open weights, third-party inference hosts, and consumer apps on unmanaged devices. Each path has a different data destination, a different jurisdiction and a different retention posture, while all four produce requests that look alike to an application. This piece separates the four, explains why a policy written against a model name governs nothing, and sets out where classification and per-decision records belong.
Two services in the same company both report that they call DeepSeek-V3. One sends requests to api.deepseek.com. The other sends them to a vLLM server running on four A100s in the company's own Frankfurt datacenter.
Same model family, same request format, same entry in the architecture diagram. Completely different answers to every question a data protection officer will ask.
That divergence is what makes DeepSeek DLP a deployment-path problem before it is a content problem. A policy written as "DeepSeek is approved" governs one of these paths and silently authorizes the rest.
Four paths
The vendor API at api.deepseek.com sends requests to infrastructure operated by DeepSeek, with the retention and jurisdiction terms in the vendor's published policy. This is the path a developer takes when they want it working this afternoon.
Self-hosted open weights run the published model weights on your own compute, through vLLM, SGLang, TGI or similar. Requests never leave your boundary. This path answers the residency question cleanly and introduces different questions: who can reach the inference server, what it logs, and whether it sits behind any authorization at all. An internal vLLM endpoint with no auth on port 8000 is a thing that exists in more environments than anyone would like.
Third-party inference hosts serve DeepSeek weights from their own infrastructure. Together, Fireworks, OpenRouter, Bedrock and Azure AI Foundry catalogues, and others each present a different hostname, a different jurisdiction, a different retention policy and a different contract. The model is the same. Nothing else is.
Consumer apps on phones and personal laptops are the fourth path, and the one no architecture diagram contains. This is ordinary shadow AI, and it behaves the same way it does for every other consumer AI product.
An inventory that records "DeepSeek" as one row is recording four different risk postures as one.
Why hostname allowlisting fails here specifically
Most network-layer AI policy is written as an allowlist of provider hostnames. That works while there is one hostname per model.
Open weights break the assumption. Anyone can serve the model, so the set of hostnames that could be carrying DeepSeek traffic is open-ended and grows without anyone telling you. A team that switches from the vendor API to an OpenRouter route has changed the destination, the jurisdiction and the contract, and the change is a one-line base URL edit in a config file.
Self-hosting breaks it the other way. Traffic to an internal inference server never touches an egress control at all, so the path with the best residency story is also the path with the least inspection.
The property that survives all four cases is that policy follows the content and the identity rather than the destination hostname. What class of data is in this request, and who is sending it. That question has the same answer whether the request goes to Beijing, to Frankfurt, or to a GPU in the next rack.
The open-weights case deserves its own controls
Teams that self-host often treat the residency answer as the end of the analysis. Three things stay open regardless.
Access to the inference endpoint is the first. A vLLM server exposed inside a flat network is reachable by every workload on that network, and OpenAI-compatible servers commonly ship with no authentication configured. Whatever governance existed at the application layer is bypassed by anything that can open a socket.
Logging is the second open question. Inference servers log at the request level if you configure them to, and those logs contain prompts. A prompt log on a GPU host with wide operational access is a copy of your sensitive content in a place nobody classified.
Retention inside the application is the third. Self-hosting removes the vendor from the retention question and leaves your own conversation stores, caches and traces, which are now the complete record.
A self-hosted deployment moves the problem inside the boundary. It does not remove it, and the controls it needs are ones the residency conversation tends to skip.
What DeepSeek DLP has to classify
The classes are the organization's own. The interesting part is that the same class carries a different consequence per path.
Customer PII sent to a self-hosted endpoint in your own region is a data handling question governed by your existing controls. The same PII sent to a vendor API is a cross-border transfer with a legal basis to establish. The same PII sent to a third-party host is a transfer to whichever jurisdiction that host operates in, under whichever contract someone signed, possibly nobody.
That means the policy has to evaluate content class and destination together, per request, rather than approving a model name once. Classification runs on the assembled prompt, which is the practice covered in prompt-level DLP, and the class definitions come from the work covered in AI data classification.
For reasoning models specifically, chain-of-thought output is worth an explicit decision. A reasoning trace restates the input at length, and if the application stores traces, the store inherits the classification of everything that went in.
The record
decision_id: d-b2f377, recorded at 2026-08-14T15:52:11Zoriginating_identity: t.nakamura@example.comacting_service: svc-support-summarizermodel_family: deepseek-v3, recorded separately from the destinationdestination_host: api.deepseek.com,destination_jurisdiction: external-vendordeployment_path: vendor_api, one of vendor_api, self_hosted, third_party_host or unmanagedclassifications: customer-pii on 8 spanspolicy: cross-border-ai-egress-v3,outcome: blockedreason: customer-pii bound for an external vendor destination
The deployment_path and destination_jurisdiction fields are the ones that answer the question a regulator asks. A record showing only the model family cannot distinguish a self-hosted call from a cross-border transfer, and those are the two facts the whole assessment turns on.
Keeping model_family separate from destination_host is what makes a later migration auditable. When a team repoints from the vendor API to an internal endpoint, the records show the exact date the transfer stopped.
DeepInspect
This is the gap DeepInspect closes. DeepInspect sits as a stateless proxy on the HTTP path between your users, applications and agents and whatever model endpoint they call, which covers the vendor API, a third-party host and your own self-hosted inference server on identical terms. Content is classified before the request is forwarded, policy is evaluated against the identity that originated the request and the destination it is bound for, and a per-decision record is written into storage you control.
Because the policy is written against content class and identity rather than hostname, a base URL change in a config file produces a policy decision rather than a silent change of jurisdiction. Enforcement is inline and fails closed.
DeepInspect does not host models, manage your GPU fleet, or negotiate your vendor terms.
If your inventory has one row for DeepSeek and your traffic takes four paths, the other three are ungoverned today. Book a demo today.