Blog

DeepSeek’s privacy policy: what it means for your data

featured-deepseek-privacy-policy

Employees are already pasting roadmaps, deal terms, and source code into the DeepSeek app, and that data may move to servers governed by PRC access law.When personal data is involved, the employer may have its own obligations as a data controller, including responsibility for the lawfulness of the transfer.

Regulators in Italy, Germany, and South Korea have already acted on DeepSeek’s data transfers. Yet blocking the app outright without providing a sanctioned alternative can push users toward personal devices and other unvetted tools, reducing security-team visibility.

For the CISO or CAIO, regulator pressure and employee demand leave a hard middle ground: how do you let the business use a fast-moving model without losing control of the data that reaches it? If you’re already fielding DeepSeek questions from legal and compliance, you’ve seen how quickly the conversation shifts from feature request to risk review.

This article walks through what DeepSeek’s privacy policy means for enterprise data, where regulators have already drawn lines, and how AI risk management governs DeepSeek use, prompt by prompt, without a blanket ban.

Key takeaways

  • DeepSeek use can move enterprise prompts to PRC-hosted servers governed by PRC access law, while the enterprise remains responsible for transfer compliance and internal controls.
  • Regulators in Italy, Berlin, and South Korea have acted over DeepSeek’s data handling or transfers, but blocking access without a sanctioned alternative can drive employees toward Shadow AI.
  • Self-hosted or Amazon Bedrock deployments can change where data resides, but they still require runtime protection against prompt injection, jailbreaks, harmful outputs, and other model behavior risks.
  • You should verify current terms, direct sensitive work to approved models, document possible breaches, and use controls and evidence such as audit trails, SOC 2 Type II-certified infrastructure, customer-controlled encryption keys, and appropriate regional deployment to support governed decisions.
WitnessAI Platform
PLATFORM OVERVIEW

Stop Choosing Between AI Innovation and Security

WitnessAI lets you observe, protect, and control your entire AI ecosystem without slowing down the business. Enterprise AI adoption, without the risk.

See How It Works

What the DeepSeek privacy policy means for enterprise data

Using DeepSeek’s hosted services raises three enterprise concerns: data stored in the PRC may be subject to PRC law, regulators have challenged aspects of DeepSeek’s data handling and transfers, and blunt blocking can drive use into less visible channels. The sections below walk through each of these in turn.

1. Data sits under PRC access laws

The DeepSeek privacy policy states that the personal information DeepSeek collects is stored on secure servers located in the People’s Republic of China. That storage location is what brings enterprise prompts into scope of PRC access law. China’s Data Security Law requires organizations to cooperate when public security or state security organs collect data for national security or criminal investigations under Article 35.

Article 36 bars those same organizations from handing PRC-stored data to foreign law enforcement without government permission. The U.S. House hearing record puts it plainly: As Rep. Vince Fong stated in his opening remarks at the March 17, 2026 House Homeland Security subcommittee hearing: “Every interaction [with DeepSeek] is stored on servers located in the People’s Republic of China, where authorities can demand access to that data under Chinese law.”

Without a data processing agreement, an enterprise has fewer contractual levers, including audit rights and deletion guarantees. Sub-processor controls can also be limited. Similar constraints can apply when an IDE plugin or AI agent calls a DeepSeek API endpoint on an employee’s behalf. Once an M&A memo is pasted into the app, the company has limited control over it.

2. Regulators have already found the transfers deficient

Italy’s Garante order placed a definitive limitation on DeepSeek’s processing of Italian users’ data on January 30, 2025. It cited violations of GDPR Articles 31, 12, 13, 14, 6, 32, and 27. Berlin’s data commissioner followed on June 27, 2025 and reported the app to Apple and Google as illegal content. The commissioner found that “The transfer of user data by DeepSeek to China is unlawful” under GDPR Article 46(1).

South Korea’s Personal Information Protection Commission (PIPC) found on April 24, 2025 a prompt content transfer to Beijing Volcano Engine Technology Co., Ltd. without user consent and without disclosure in its policy, though DeepSeek had already blocked the transfer of AI prompt information on April 10, 2025.

If you’re a European employer, you need to show that your transfers meet Chapter V requirements. The controller carries that burden, and an unlogged session gives you little evidence to support your position.

Under DORA, EU financial entities must keep a contractual arrangements register for ICT third-party service providers. A publicized incident tying customer data to a PRC transfer could also involve the CMO and communications team alongside Legal.

3. Blocking DeepSeek pushes use into Shadow AI

Blocking the DeepSeek domain is a common first response, but without a safe, approved alternative it can push demand into unsanctioned Shadow AI. Employees who still need AI help may reach it through personal devices or other unvetted apps.

Once employees are working around the block, the security team loses visibility into what data is leaving the company and where it’s going. A blocked domain provides one control, but without a sanctioned alternative it can move some usage into channels the security team cannot see., whether that’s a personal phone at lunch or an API call from an IDE plugin nobody logged.

WitnessAI Observe
OBSERVE

Your Employees Use 5x More AI Tools Than You Think

WitnessAI scans your entire network to catalog every AI app, agent, and conversation. No endpoint clients or browser extensions are required.

See How Observe Works

How AI risk management governs DeepSeek exposure without a blanket ban

Governing DeepSeek without banning it comes down to five practical steps: inventory where it’s being used, classify what’s moving through it, enforce graduated policies at runtime, keep audit trails that hold up with regulators, and apply the same runtime controls to any self-hosted or Bedrock-hosted version. 

The subsections below walk through each step in the order a security team would actually run them, from discovery to model-layer defense.

1. Discover DeepSeek traffic across user and agent channels

Governance starts with an inventory of AI tools employees and agents are already using. DeepSeek can reach your network through more channels than most teams expect: the consumer web app, mobile apps on personal or corporate devices, IDE plugins, API calls from internal services, and MCP tool calls initiated by AI agents on an employee’s behalf.

Network-level visibility can extend governance beyond browser-only approaches to native applications, IDEs, APIs, and agent traffic when those interactions traverse the supported inspection path. The goal at this stage is a single list that answers three questions: which employees and agents are reaching DeepSeek, through which channels, and how often. Without that baseline, later controls are guesses.

2. Classify what’s actually moving in the prompt

Discovery tells you DeepSeek was used; classification tells you what data went with the request. The security question is whether the prompt carried an M&A summary, source code, customer PII, or a generic marketing draft, and keyword- and regex-based DLP rules can miss that distinction because matching strings and patterns does not, by itself, establish the conversational context or user intent.

Intent-based classificationanalyzes conversational context to determine the purpose of an interaction, going beyond keyword and regex matching alone. Intent-based classification is the difference between logging that an employee used DeepSeek and logging that an employee sent DeepSeek a summary of a pending acquisition. Classification is what makes the next step, enforcement, proportionate instead of binary.

3. Enforce graduated policies at runtime

Effective enforcement needs more than an allow/block switch. A useful runtime policy engine supports at least four graduated actions:

  • Allow the prompt when the content is low-risk (a marketer drafting generic copy).
  • Warn the user in real time when a prompt looks like it violates acceptable-use policy, restating the rule so the employee can self-correct.
  • Block the prompt when it contains data that must never leave the environment (regulated PII, board materials, credentials).
  • Route the prompt to an approved internal or governed model when the request is legitimate but the destination isn’t.

For interactions routed through the platform, sensitive fields inside otherwise-allowed prompts can be tokenized before they reach the model and restored in the response, so the workflow completes without the raw data ever reaching DeepSeek. Cardholder data is the clearest example; whether tokenization takes a given system out of Payment Card Industry Data Security Standard (PCI DSS) scope is a decision for your Qualified Security Assessor (QSA).

4. Keep audit trails that hold up with regulators and boards

For governed DeepSeek traffic, prompts and responses should be captured in an audit trail with user attribution, timestamp, policy decision, and the classification that drove that decision. For agent and MCP tool calls, the audit trail should connect the agent action back to the human who initiated the workflow, so accountability doesn’t dead-end at a service account.

When a regulator asks what data went where, as the Garante asked DeepSeek, the audit trail is theevidence you produce. The same records answer the questions boards and audit committees ask about whether AI controls are actually working, in practice.

5. Protect self-hosted and Bedrock deployments at the model layer

Moving off the DeepSeek-hosted app changes where data resides, but not what the model itself will do. A self-hosted DeepSeek deployment keeps data outside DeepSeek’s PRC-hosted service, and on Amazon Bedrock, user inputs and model outputs are not shared with any model providers

. Both still need runtime controls for model behavior.

NIST’s Center for AI Standards and Innovation evaluated DeepSeek models downloaded directly from Hugging Face. It found that DeepSeek models responded to 94% of overtly malicious requests when a common jailbreaking technique was used, compared with 8% of requests for U.S. reference models when a well-known jailbreak attack was used, and the same evaluation found censorship built into the weights. Deployment choice controls data location; runtime controls address model behavior.

At the model layer, that means bidirectional inspection of prompts and responses: detecting and blocking prompt injection attempts on the way in, and filtering harmful or non-compliant outputs on the way out. The same AI guardrails you apply to hosted models should apply to a self-hosted DeepSeek instance, so the security posture doesn’t depend on which model the business happens to be using this quarter.

WitnessAI Control
CONTROL

Can You Prove How Your Organization Governs AI?

WitnessAI generates granular audit trails, enforces policies across every role and region, and redacts sensitive data before it ever leaves your network. Compliance-ready from day one.

See How Control Works

Turning the DeepSeek privacy policy into a governed decision

DeepSeek’s privacy policy, the storage of personal data in the People’s Republic of China, and the model’s documented behavior on jailbreak tests all point to the same question: can your organization show which prompts reached DeepSeek, what they contained, and under which policy they were allowed?

Runtime controls give security teams a practical way to answer. For AI interactions governed through the platform, security and AI teams can show regulators and the board which data reached which model and which policy decision was applied.

WitnessAI gives security and AI teams the evidence to prove control to boards and regulators, so they can decide whether a DeepSeek deployment can proceed under defined controls.

Schedule a demo to see how it applies to the AI tools already running on your network.

FAQs about the DeepSeek privacy policy