Is DeepSeek Safe? A Data Privacy and Security Deep Dive

Short answer: DeepSeek is safe for public, non-sensitive work and unsafe for regulated or confidential data — because its hosted API stores prompts on servers in China, subject to Chinese law. Self-hosting the open-weights model on infrastructure you control removes most of the risk. The rest of this guide walks through the specifics regulated buyers need before making that call.

DeepSeek is one of the most capable language models available today. It is also based in Hangzhou, China, and its privacy policy states that data may be stored on servers in the People's Republic of China.

For many companies, this is not just a policy question. It is a legal one. Sending certain types of data to Chinese servers can violate ITAR, HIPAA, SOC 2 commitments, and data residency laws. The risk is worse than most teams realize because routing tools like OpenRouter can send data to DeepSeek without explicit user awareness.

This guide covers where DeepSeek stores data, what Chinese law says about government access, which compliance frameworks are affected, and how to audit your stack for hidden DeepSeek exposure.

Where DeepSeek Stores Data

DeepSeek is developed by High-Flyer, a Chinese AI lab based in Hangzhou, Zhejiang Province, China. The company operates its model infrastructure from Chinese data centers.

DeepSeek's privacy policy states that user data may be stored on servers in the People's Republic of China. This applies to prompts sent through the DeepSeek API, responses generated, and associated metadata.

When you send a prompt to DeepSeek's API, your data travels to and is processed on servers in China. There is no option to select a US or EU data center for the DeepSeek API. The data residency is fixed.

This is a factual statement based on DeepSeek's published privacy policy. It is not speculation. Any company sending data to DeepSeek's API should understand this before proceeding.

• DeepSeek is based in Hangzhou, Zhejiang Province, China
• Privacy policy states data may be stored on servers in the PRC
• No option to choose US or EU data centers for the API
• Prompts, responses, and metadata are all processed in China
• Applies to direct API use and to access through routing tools

Chinese Law and Government Data Access

Three Chinese laws are relevant to data stored on DeepSeek's servers: the Personal Information Protection Law (PIPL), the National Security Law, and the National Intelligence Law. Together, they give the Chinese government broad authority to access data held by Chinese companies.

The PIPL, enacted in 2021, governs how personal information is collected and processed. It requires that data processing in China comply with Chinese government requests related to national security, public interest, and criminal investigation.

The National Security Law, passed in 2015, requires all organizations and citizens to support national security work. The National Intelligence Law, passed in 2017, requires organizations to support and cooperate with national intelligence efforts.

The practical effect is that data stored on servers in China can be accessed by Chinese government authorities. Companies that store data there cannot guarantee that it will remain private from the Chinese government.

• PIPL (2021): governs personal data processing, requires compliance with government requests
• National Security Law (2015): requires organizations to support national security work
• National Intelligence Law (2017): requires organizations to cooperate with intelligence efforts
• Combined effect: Chinese government can compel access to data stored in China
• No US or European legal protections apply to data on Chinese servers

ITAR: The Criminal Risk of Sending Controlled Data to China

The International Traffic in Arms Regulations (ITAR) control the export of defense-related technical data. Sending ITAR-controlled information to a Chinese server can constitute an unauthorized export, which is a criminal offense.

ITAR does not care about intent. If controlled technical data reaches a Chinese server through a routing tool that picked DeepSeek as the cheapest model, the violation occurred regardless of whether anyone intended it.

The penalties are severe. ITAR violations can result in fines up to $1 million per violation and prison sentences up to 20 years. The Department of State and Department of Justice enforce these provisions.

Defense contractors, aerospace companies, and any organization handling ITAR-controlled technical data should treat DeepSeek and other Chinese-hosted models as prohibited endpoints. This includes indirect access through routing tools.

• ITAR controls export of defense-related technical data
• Sending controlled data to Chinese servers is an unauthorized export
• Intent does not matter: accidental routing is still a violation
• Penalties: up to $1M per violation and up to 20 years imprisonment
• Includes indirect access through routing tools like OpenRouter or LiteLLM

HIPAA: Protected Health Information on Chinese Servers

HIPAA requires that protected health information (PHI) be processed only by covered entities and their business associates, with appropriate safeguards. Sending PHI to DeepSeek's servers in China violates this requirement in most scenarios.

A Business Associate Agreement (BAA) is required with any third party that processes PHI. DeepSeek does not offer BAAs to US healthcare organizations. Without a BAA, sending PHI to DeepSeek is a HIPAA violation.

The risk is amplified by routing tools. If a healthcare organization uses OpenRouter and the auto-router selects a DeepSeek model for a request containing patient data, PHI has left approved infrastructure without authorization.

HIPAA violations carry civil penalties up to $2.1 million per violation category per year. Willful neglect violations that are not corrected can result in the maximum penalty.

• PHI must be processed only by covered entities and business associates
• DeepSeek does not offer BAAs to US healthcare organizations
• Sending PHI to DeepSeek without a BAA is a HIPAA violation
• Routing tools can send PHI to DeepSeek without explicit authorization
• Civil penalties up to $2.1M per violation category per year

SOC 2 and ISO 27001: Attestation Accuracy

SOC 2 and ISO 27001 require that organizations document where data is processed and ensure that processing locations align with their stated policies. If your routing tool sends data to Chinese servers that are not in your documented inventory, your attestation is inaccurate.

SOC 2 Trust Service Criteria require that you identify and manage risks related to data processing. An undocumented data flow to Chinese infrastructure is an unidentified risk that should have been caught.

During a SOC 2 audit, auditors will ask where AI model data is processed. If you answer "OpenAI and Anthropic" but your router also sends data to DeepSeek, the response is incomplete. Incomplete responses can result in qualified opinions or failed audits.

The fix is straightforward: document every model endpoint your routing tool can reach, assess each one against your data processing policies, and block non-compliant endpoints before your next audit.

• SOC 2 requires documentation of all data processing locations
• Undocumented data flows to Chinese servers create attestation gaps
• Auditors will ask where AI model data is processed
• Incomplete answers can result in qualified opinions or failed audits
• Fix: document, assess, and block non-compliant model endpoints

The Hidden Risk: Routing Tools That Silently Send Data to DeepSeek

The most dangerous scenario is not direct use of DeepSeek. It is indirect use through a routing tool where no one on your team realizes data is going to China.

OpenRouter includes DeepSeek models in its default catalog. If a developer uses OpenRouter's auto-router or cost-based routing, DeepSeek may be selected as the cheapest qualifying model. The developer sees a successful API response. They do not see that the prompt went to China.

LiteLLM documentation shows how to add DeepSeek as a provider. A developer following the docs may add it to the proxy config for testing and never remove it. Production traffic then routes to DeepSeek alongside approved providers.

This is not a theoretical risk. It is a configuration default. Companies need to audit their routing tool configurations, check usage logs for Chinese-hosted model traffic, and implement allowlists that restrict routing to approved endpoints only.

• OpenRouter auto-routing can select DeepSeek without explicit user choice
• LiteLLM docs normalize adding DeepSeek as a provider endpoint
• Developers may add Chinese endpoints for testing and forget to remove them
• Usage logs may show traffic to DeepSeek that no one authorized
• Allowlists that restrict routing to approved models are the primary defense

How to Audit Your Stack for DeepSeek Exposure

Start by searching your codebase for any reference to DeepSeek, Qwen, Yi, Moonshot, or their API endpoints. Check environment variables, config files, and proxy configurations.

Next, review your routing tool's usage logs. Look for requests that were routed to Chinese-hosted model providers. If the tool does not log which model handled each request, that itself is a compliance gap.

Check your team's OpenRouter account settings, LiteLLM proxy config, or Portkey virtual keys for any Chinese-hosted model endpoints. Remove or block them if they violate your data residency policies.

Finally, implement an allowlist as part of a formal routing vendor audit. Instead of blocking specific models, define which models are approved and block everything else. This prevents new Chinese-hosted models from being automatically available when they are added to your routing tool's catalog.

• Search codebase for DeepSeek, Qwen, Yi, Moonshot API references
• Review routing tool usage logs for Chinese-hosted model traffic
• Check OpenRouter preferences, LiteLLM config, or Portkey virtual keys
• Remove or block non-compliant endpoints
• Implement an allowlist of approved models instead of a blocklist