The pitch for DeepSeek infrastructure almost always arrives as a cost story. The weights are open, the inference is cheap, the benchmarks look strong — so the reasoning goes, adopt it and ship. That framing skips the part that actually decides whether you can deploy: where the model runs, what training-data provenance you can prove, and what happens to prompt data on the serving path. We have watched more than one open-weight rollout sail through a technical proof-of-concept and then stall for a quarter at the first legal or data-protection review, because nobody mapped governance controls onto the stack before it touched a production feature. DeepSeek is a good model. It is also a specific stack with specific exposure, and the exposure is what a review board asks about — not the leaderboard rank. How does DeepSeek infrastructure work? Strip away the branding and “DeepSeek infrastructure” is three separable things. There is the model — open weights you can download, quantise, and serve yourself. There is the hosted API — DeepSeek’s own endpoints, where you send prompts and get completions back over the network. And there is the serving layer you build around either one: the runtime, the batching, the KV-cache reuse, the logging. These are not interchangeable from a governance standpoint even though they produce the same tokens. When you self-host the open weights on your own GPUs — an H800/H100 cluster, or a cost-tuned mix — your prompt data never leaves your boundary, and you own the entire data-flow record. When you call the hosted API, prompt and output cross a network path to infrastructure you do not control, under terms of service you did not write. The tokens are identical; the compliance posture is not. In practice this means the first question a production team should answer about DeepSeek is not “how fast is it” but “which of these three am I actually adopting, and for which of them can I produce a data-flow diagram a reviewer will accept.” We walk through the serving-cost and runtime mechanics separately in our breakdown of DeepSeek inference in production; the point here is that the runtime choice and the governance choice are the same choice wearing two hats. Self-hosted open weights versus hosted API: how do they differ on data residency? This is the fork that everything else hangs off. The naive read is that self-hosting is “harder but private” and the API is “easy but you give up control” — true as far as it goes, but it hides the dimensions a review actually scores. DeepSeek deployment options compared Dimension Self-hosted open weights Hosted API Prompt data residency Stays inside your boundary; you choose the region Leaves your boundary to the provider’s infrastructure Data-flow record You author it end to end Bounded by provider terms; you document the egress, not the internals PII handling on serving path You control redaction, logging, retention Governed by provider’s stated retention and use policy Operational burden GPU capacity, runtime tuning, scaling, on-call Minimal — the provider runs it Cost profile Fixed capacity cost; efficient at sustained load Per-token; efficient at low or spiky volume Defensible on data-residency? Yes, with a documented topology Only if provider terms satisfy your regulator The residency line is the one that decides regulated deployments. If you are handling health, financial, or EU personal data, “the prompt left our boundary to a third-party endpoint” is a sentence that stops a data-protection review cold unless you can point to a data-processing agreement and a residency guarantee that actually covers it. Self-hosting removes that sentence entirely — the trade is that you inherit the operational weight of running the stack, which is a prototype-to-production problem in its own right. We treat that operational lens as a governance problem, not just a scaling one, because that is how it shows up in review. For a workload that is spiky and non-sensitive, the API is often the right call and the residency question is answerable. For a sustained, regulated feature, the fixed cost of self-hosted capacity is usually both cheaper at load and the only defensible answer on residency. The decision is contextual — which is exactly why it should be made against a framework rather than a benchmark. What copyright and training-data provenance questions does DeepSeek raise? Open weights tell you what the model is. They do not tell you what it was trained on, and that gap is where copyright exposure lives. When a production GenAI feature generates text or code that a customer relies on, the question a legal reviewer eventually asks is: can the training data provenance be characterised well enough to bound the risk of regurgitated copyrighted material or license contamination? For DeepSeek, as for most open-weight models, the honest answer is that provenance is partial. You get the weights and a model card; you do not get an auditable manifest of every source in the pretraining corpus. That is not disqualifying — it is a known, bounded uncertainty that has to be named and accepted rather than ignored. The failure mode we see is teams treating the open license on the weights as if it were a clean provenance guarantee on the data. It is not. The weights being MIT-licensed says nothing about the copyright status of what produced them. The governed approach documents this explicitly: state what provenance you can establish, state what you cannot, and record the mitigations — output filtering for verbatim regurgitation, human review on high-stakes generations, contractual carve-outs. This is the same provenance discipline that shows up whenever generated output has downstream consequences, and it connects directly to how the data-centric view exposes where GenAI fails on production data: the data you cannot see is still part of your risk surface. How does prompt and output PII get handled on the serving path? Every prompt is a potential PII vector, and on a DeepSeek serving path the PII can leak in more places than teams expect. It is in the prompt itself if users paste customer data. It is in the logs if you record raw prompts for debugging. It is in the KV cache if that cache is shared across tenants. It is in the output if the model reflects back something sensitive it was given. Keeping data-protection exposure inside accepted residual risk means putting controls on each of those points rather than trusting the model to behave: Ingress redaction — strip or tokenise identifiable data before it reaches the model, especially on shared endpoints. Log hygiene — decide deliberately whether raw prompts are retained, for how long, and who can read them; default to not logging prompt bodies in regulated contexts. Cache isolation — prefix-cache reuse is a real latency win, but a shared radix or KV cache across tenants is a cross-contamination path that a reviewer will flag; isolate per tenant or per trust boundary. Output review on sensitive flows — where a generation feeds a decision about a person, a human or a policy layer sits between the model and the action. None of these are DeepSeek-specific in principle — they are the standard controls any serving stack needs. What is DeepSeek-specific is that the open-weight, self-hosted path gives you the ability to enforce them, where the hosted-API path constrains you to what the provider offers. That is another reason residency and PII handling collapse into the same decision. How does a DeepSeek deployment get checked against a governance framework before it ships? The whole argument comes down to a gate. Before a candidate DeepSeek stack touches a production feature, it should clear a documented check on three axes: provenance, PII handling, and accepted residual exposure. This is exactly the work an A2 GenAI Feasibility Audit does — it maps the same governance controls a mature framework already names onto this specific stack, and produces a record that a review board recognises. DeepSeek deployment readiness checklist Score each item as documented / partial / missing before the feature ships: Which stack am I adopting — self-hosted weights, hosted API, or a mix — and is the choice deliberate rather than default? Data-flow record — can I draw the path a prompt takes, from user to model to log to response, and does it stay inside the boundary I claimed? Residency guarantee — for every hop that leaves my boundary, is there a term or topology that satisfies my regulator? Provenance statement — have I stated what training-data provenance I can and cannot establish, with mitigations named? PII controls — are ingress redaction, log hygiene, cache isolation, and output review each explicitly decided, not assumed? Residual-risk register — is the exposure I am choosing to accept written down and signed off by someone with the authority to accept it? A stack that scores “documented” across all six clears a legal or data-protection review in weeks rather than quarters, because there is nothing left for the reviewer to discover — the risks and controls were named up front. That compression is the ROI, and it is a governance dividend, not a benchmark one. It also produces a provenance and data-flow record that regulators and insurers actually recognise, which is worth more at renewal time than any leaderboard position. What residual risks should leadership expect to accept? No governed deployment reduces risk to zero, and pretending otherwise is its own failure mode. Leadership adopting DeepSeek infrastructure should expect to accept, in writing, at least three things: incomplete training-data provenance that no open-weight model can fully close; some residual regurgitation risk that output filtering reduces but does not eliminate; and, on any hosted-API path, dependence on a third party’s stated retention and use terms. The governed posture is not the absence of these risks — it is knowing exactly which ones you are carrying and having someone with the authority to accept them sign that they are acceptable for this feature. FAQ What matters most about DeepSeek infrastructure in practice? DeepSeek infrastructure is three separable things: open model weights you can self-host, DeepSeek’s hosted API, and the serving layer you build around either. They produce identical tokens but carry different governance postures — self-hosting keeps prompt data inside your boundary, while the API sends it to infrastructure you do not control. In practice the first question is which of the three you are adopting and whether you can produce a data-flow record a reviewer will accept. What are the deployment options for DeepSeek models — self-hosted open weights versus hosted API — and how do they differ on data residency? Self-hosted open weights keep prompt data in a region you choose, let you author the full data-flow record, and are usually cheaper at sustained load; the trade is the operational weight of running the stack. The hosted API is minimal-burden and efficient for spiky, low-volume workloads, but prompt data leaves your boundary under provider terms. For regulated, sustained features, self-hosting is typically both cheaper at load and the only defensible answer on residency. What copyright and training-data provenance questions does DeepSeek raise for a production GenAI feature? Open weights and an open license tell you what the model is, not what it was trained on, so provenance is only partial — you get a model card, not an auditable corpus manifest. That is a bounded uncertainty to name and accept, not ignore; the failure mode is treating the weight license as a data-provenance guarantee. The governed approach documents what provenance you can and cannot establish and records mitigations like output filtering and human review on high-stakes generations. How does prompt and output PII get handled on a DeepSeek serving path, and what controls keep data-protection exposure inside accepted residual risk? PII can leak in the prompt, the logs, a shared KV or radix cache, and the output. Keeping exposure inside accepted residual risk means putting explicit controls on each point: ingress redaction, deliberate log hygiene, per-tenant cache isolation, and output review on sensitive flows. The self-hosted path gives you the ability to enforce these where the hosted API constrains you to the provider’s offering. How does a DeepSeek deployment get checked against a production governance framework before it ships? It clears a documented gate on provenance, PII handling, and accepted residual exposure before touching a production feature — the work an A2 GenAI Feasibility Audit performs. A six-point readiness checklist (stack choice, data-flow record, residency, provenance statement, PII controls, residual-risk register) is scored documented/partial/missing. A stack that scores “documented” across all six clears review in weeks rather than quarters because there is nothing left for the reviewer to discover. What residual risks should leadership expect to accept when adopting DeepSeek infrastructure? At least three: incomplete training-data provenance no open-weight model can fully close; some residual regurgitation risk that output filtering reduces but does not eliminate; and, on any hosted-API path, dependence on a third party’s retention and use terms. The governed posture is not the absence of these risks — it is knowing which ones you carry and having someone with authority sign that they are acceptable for this feature. The interesting question is not whether DeepSeek is cheap enough to adopt — it is whether you can put your name on the residual-exposure register before the feature ships. That is the deployment gate an A2 GenAI Feasibility Audit exists to clear, and it is the difference between an open-weight model that ships and one that stalls at review.
