DeepSeek for Regulated Buyers: The On-Prem vs. Cloud Compliance Question

Three DeepSeek questions, not one Healthcare CIOs, behavioral health CTOs, and PE operating partners have all asked us a version of the same question over the last six months: "Can we use DeepSeek?" The question hides three separate questions that have three different answers. Treat them as one and the answer is "no" by default; treat them as three and the answer becomes "it depends, and here is on what." The three questions are: 1. Can we use the hosted DeepSeek API? No. Disqualified for HIPAA, SOC 2, and any US-regulated workload, full stop, on data-residency grounds alone. 2. Can we self-host the open-weight DeepSeek models on US cloud infrastructure? Yes, technically, under Architecture B or C from our HIPAA AI Architecture Field Guide. But the operational lift is meaningful and most mid-market buyers will not justify it. 3. Can we self-host on dedicated on-prem infrastructure? Yes, with the addition of supply-chain review. Architecture C, executed correctly, is defensible. The geopolitical question on top of the technical one is real and worth a board-level conversation. The rest of this briefing walks each of the three. Question 1: Hosted DeepSeek API, disqualified The hosted DeepSeek API runs on infrastructure outside the United States. That fact alone disqualifies it for any workload touching PHI under HIPAA, regardless of the model's quality. The Security Rule's data residency expectations, the Privacy Rule's minimum-necessary obligations, the typical state law overlay (CCPA, the various AGs, the patchwork of breach-notification regimes), and any defensible BAA chain all break at the same place: the inference endpoint sits in a jurisdiction the regulator will not accept. The vendor does not currently offer a US-hosted enterprise tier with a HIPAA-grade BAA. There is no Zero Data Retention addendum equivalent. There is no SOC 2 Type II report mid-market healthcare buyers can rely on. The hosted product is an excellent way to evaluate the model's reasoning quality before you commit to self-hosting it. It is not a path to production for any regulated workload. For any buyer reading this from a regulated context: if your team is currently routing prompts through , the only defensible immediate action is to stop, document the workflow, and assess whether any PHI was sent. Treat as you would any unauthorized BAA-less vendor. We have audited two healthcare deployments this year that had quietly stood up the hosted API for "innocuous" administrative tasks and discovered, on review, that the prompts contained patient identifiers a human reviewer had not anticipated. The remediation in both cases was a multi-month exercise. Question 2: Self-hosted open-weight on US cloud, technically defensible This is the question where DeepSeek becomes interesting, and where most of the procurement conversations we have are getting confused. The DeepSeek-V3 and DeepSeek-R1 model weights are open-weight (released under permissive licenses on Hugging Face). Open-weight means you can pull the weights and run inference yourself on infrastructure you control. The hosted API and the open-weight self-hosting are completely different architectural decisions. The first is disqualified for HIPAA on residency grounds; the second is just another deployment of a model in your own infrastructure. If you self-host the open-weight DeepSeek-V3 or DeepSeek-R1 inside your AWS or Azure account, the BAA chain is the cloud provider's BAA, same as if you were running Llama, Mistral, or any other open-weight model. The architecture question is the question Field Guide #1 (HIPAA AI Architecture) answers. You are now in Architecture B (cloud-native with self-managed BAA scope) or Architecture C (on-prem / VPC-isolated), and the architecture is defensible if you implement it correctly. But: the operational lift is real. Hosting the DeepSeek-R1 reasoning model at production scale requires GPU capacity (typically multiple H100s or A100s, depending on quantization), an inference server (vLLM, Text Generation Inference, or a managed alternative), an orchestration layer you build, and an audit-logging pipeline that captures prompt-and-completion content at HIPAA retention. None of that is impossible. None of it is what most mid-market regulated buyers are set up to do well. The marginal model-quality improvement DeepSeek-R1 might offer over Claude or GPT-4 on a given workflow rarely justifies the architectural rebuild. There is one workload class where it does justify it: highly mathematical or reasoning-intensive tasks where DeepSeek-R1's chain-of-thought reasoning materially outperforms the alternatives, AND where the workload is internal (not patient-facing), AND the team already has the GPU footprint and ML-ops maturity. For those workloads, self-hosted DeepSeek-R1 on AWS or Azure under the cloud provider's BAA is a defensible architecture. For the other 95% of regulated mid-market AI workloads, Anthropic, OpenAI under ZDR, Bedrock, or Foundry will deliver more value with materially less architectural exposure. Question 3: Self-hosted on-prem, Architecture C plus supply chain The third version of the question is the one we get from large healthcare systems, behavioral health groups with privacy-sensitive workflows, and a small number of PE-backed regulated SaaS buyers with explicit "PHI never leaves the trust boundary" mandates. Architecture C from the Field Guide: model and orchestration both run inside the trust boundary, PHI never crosses it. For Architecture C deployments, the model selection question expands to "open-weight models we can run locally." DeepSeek's models are eligible candidates alongside Llama, Mistral, Gemma, Phi, and the rest of the open-weight ecosystem. The architectural questions, audit logging, minimum-necessary, access controls, transmission security, integrity, authentication, BAA chain, are the same as for any other open-weight model on the same infrastructure. What is different about DeepSeek specifically is the supply-chain question. The weights were trained by a Chinese lab. We do not yet have the same multi-year track record of independent security analysis on these weights as we have for Llama or Mistral. There is no evidence of malicious model-level behavior in the public DeepSeek releases, the research community has been picking through them for months, but absence of evidence is not evidence of absence at the depth required for healthcare deployments. The weights are open; you can review them. The training data provenance is opaque; you cannot. Whether this matters for your org depends on threat model, board posture, and whether your auditor or your customers will ask the question. They increasingly do. Two practical implications for orgs considering Architecture C with DeepSeek weights specifically: First, document your model supply-chain review process. A board-level memo explaining why the DeepSeek weights are acceptable in your environment is the artifact you want before deployment, not after. We have written this memo for two clients this year. The structure is: model version evaluated, license terms, weights provenance, security analysis cited, threat-model summary, deployment-controls summary, ongoing monitoring plan. Second, plan for the geopolitical scenario. Current US export controls on advanced AI capability do not restrict downstream use of already-released open-weight Chinese models. That could change. Build your deployment so the model layer is replaceable, Llama-class fallback, equivalent inference path, comparable reasoning capability where possible. The architecture should not bet on any single open-weight model remaining a permitted choice for the next five years. Where the Diagnostic Fits If your team is asking the DeepSeek question and the answer matters for a workload you are about to ship, whether it is "can we use the hosted API" (it is not) or "should we self-host it on Architecture C" (depends on the specific workload, your team, and your appetite for supply-chain review), that is the question the Adopt-AI-Safely Diagnostic answers. Two to three weeks, fixed-scope, fixed-price written report. We document the architecture you have or are about to commit to, evaluate it against the seven HIPAA controls AI tools must satisfy, score the BAA chain, and produce a sequenced fix plan with cost ranges. The report stands on its own. You keep it whether or not you engage us further. The DeepSeek-specific shape of that engagement: we walk the three questions above against your specific workload, surface the architectural options under each, and recommend a model + architecture pair. The recommendation is rarely DeepSeek for mid-market regulated buyers, but in the cases where the model genuinely matters, the report makes the case defensibly. What to do this week Three actions any CIO, CTO, or compliance lead can take inside the next five business days, regardless of whether they engage us: 1. Inventory any current DeepSeek hosted API usage. Pull from procurement, engineering, and shadow-IT discovery. Confirm zero PHI has flowed; if any has, treat as you would any unauthorized BAA-less data path. 2. Write the one-page model-decision memo. Five lines: what model, what architecture, what BAA chain, what audit-log surface, who owns it. The orgs that get this in writing avoid 80% of the procurement-conversation noise the DeepSeek question is currently producing. 3. Pull the latest BAA Coverage Matrix from the AI Watch vendor reference. It is updated quarterly; the DeepSeek row is current as of this briefing's publish date. Compare against your active vendors. Anything missing is a procurement conversation. The vendor matrix is at . The HIPAA AI Architecture Field Guide that grounds the architectural framework is at . We update both when the underlying landscape moves.