DeepSeek says it collects, processes, and stores personal data in the People’s Republic of China for services covered by its main privacy policy. That is the starting point for the official chat service. A DeepSeek model run by another provider or on your own infrastructure can follow a different data path.
If your requirement is to keep information in a particular country or region, check the service receiving your request, where inference happens, and where copies are retained. A local app, a European server for your website, or a model called “DeepSeek” does not answer all three questions.
This guide explains the published policies and the deployment choices that affect data location. It also gives you a practical way to review an existing setup before sending customer records, internal documents, or other restricted information. It is an independent explanation, not a certification of a service or legal advice.
Table of Contents
Where does DeepSeek process and store data?
The answer depends on who operates the service. Start by identifying which of these routes you use, then follow the relevant section below.
| How you use DeepSeek | What establishes data location | What to check next |
|---|---|---|
| Official DeepSeek website or chat app | The main privacy policy identifies China for personal data handled under that notice. | Whether that policy covers the feature you use, and which additional services receive data. |
| Official DeepSeek API | The Open Platform terms, applicable privacy notice, API documentation, and any account-specific agreement. | Processing and storage commitments for your actual workload. The documents discussed here do not provide a complete geographic map of every API data category. |
| Another provider hosting a DeepSeek model | That provider’s deployment settings, service terms, and data-processing commitments. | Whether it hosts the model itself, which region or deployment type applies, and whether requests can be routed elsewhere. |
| A model you run locally or in your own cloud account | Your inference server, application, storage, and network configuration. | Logs, backups, remote tools, monitoring, and any fallback to a hosted model. |
| DeepSeek Harness | The separate Harness policy and the model service you configure. | Official-model versus custom-model use, plus the destinations of connected tools. |
The official chat service and its privacy policy
DeepSeek’s Privacy Policy, dated February 10, 2026, applies to apps, websites, software, and related services that link to or reference it. Its storage section identifies China; it also says personal data may be stored outside the country where the user lives.
For a person using the covered chat service, that means the country on their profile or the location of their device is not a choice of hosting region. An organization with a requirement to keep that data in the EU, the US, or a specific country needs an applicable commitment that satisfies the requirement before using the service for it.
The same notice describes sharing with service providers, including search providers that receive input keywords. It does not give a country-by-country inventory of every recipient. Read a named storage location as a statement about the covered processing, rather than proof that no other service is involved.
The review also extends beyond prompts. The notice covers account details, user input and chat history, device and network information, support records, and relevant payment records. It tells users not to provide sensitive personal data. A hosting preference or an internal approval does not override that restriction for the covered service.
Our DeepSeek privacy policy guide explains collection, training preferences, and deletion in more detail. Here, the important question is where each part of your workflow takes the information.
The API exception does not put the whole developer account outside the policy
Section 5.5 of the Open Platform terms distinguishes information you provide as the data subject from personal information collected from end users of an application you build. The former is handled under DeepSeek’s privacy policy; the downstream application needs its own disclosed processing rules.
This matters when assessing an integration. There may be developer account and billing records, data sent for inference, and records retained by the application operator. Do not treat the downstream-app exception as a promise that API data stays outside China, or assume that one notice explains every copy. The terms also place disclosure, rights-request, and security responsibilities on the developer operating the downstream system.
Harness: a local interface can still call a remote model
The Harness Privacy Policy, dated September 20, 2026, separates official model services from custom model services. For custom models, it says inputs go directly to the selected model provider and outputs return directly, without Harness processing or storing those inputs and outputs on its server side. That provider’s policies govern the model processing.
The notice also identifies China for personal data DeepSeek collects under the Harness policy and explains that third-party tools collect and process data directly. In practice, check the chosen model and connected tools separately. Installing the interface on your computer does not make a remote model, a search tool, or a connected business service local.
What a data-residency requirement actually covers
Data residency usually describes where data is kept, but a requirement may also restrict where it is processed or accessed. Write down the restriction before comparing providers. “Our files must be stored in Germany” and “no customer information may be processed outside Germany” ask for different guarantees.
Storage at rest includes saved conversations, uploaded files, databases, logs, and backups. Inference processing is where the model handles a request and generates its answer. Those locations can differ: the Microsoft Foundry deployment documentation, for example, explicitly separates the geography used for storage from the processing options available for different deployment types.
Data sovereignty adds questions about the laws and authorities that may apply, contractual responsibilities, and access to the data. A server address does not settle those questions. Remote support, subprocessors, and onward transfers can matter even when the main database is in the requested region.
Use the following inventory to avoid checking only the final prompt. It is a suggested review structure, not a claim that every DeepSeek service stores every item listed.
| Part of the workflow | Information it may contain | Location question |
|---|---|---|
| Input and retrieval | Prompts, attachments, extracted text, and passages retrieved from internal documents. | Where do parsing, search, embeddings, and model inference run? |
| Responses and history | Generated answers, conversation transcripts, exports, and shared copies. | Which application stores them, and where are they synchronized? |
| Files and caches | Uploaded images, reusable files, and cached request prefixes. | Who retains each object, where, and for how long? |
| Operations and recovery | Application logs, error traces, monitoring records, backups, and restored copies. | Do their destinations and failover regions follow the same restriction? |
| Account, support, and tools | Account details, billing records, support attachments, search queries, and data sent to connected services. | Which entities or tools receive them, and what locations do their terms cover? |
A location rule may apply to only some of these categories. Make those boundaries explicit. Otherwise, two teams can both report “EU-hosted” while one means the model server and the other means the complete workflow.
DeepSeek API data residency: what the documentation establishes
For the direct API, the Open Platform terms explain that the service processes end-user input to produce output. Hosting your application in a particular region does not keep that inference inside your application server: the request is sent to the configured model service.
The public terms and API guides reviewed for this article do not establish a customer-selectable EU or US processing region or a complete location schedule for prompts, service logs, caches, and files. That is a limit of the evidence available here, not evidence that the data is processed in a different country. If location is a condition of use, obtain the relevant written commitment for the exact account and service.
A useful request to the provider names the workload: for example, text-only requests containing redacted support tickets, or image requests that use stored files. Ask where those inputs and outputs are processed, where retained copies live, and which exceptions apply. A general answer about “secure infrastructure” does not resolve a country restriction.
Cache lifetime and file expiry are separate from geography
DeepSeek’s Context Caching guide says disk caching is enabled by default. It states that unused cache is usually cleared within a few hours to a few days. That describes the lifecycle of a particular cache; it is not a deletion deadline for all API records or a statement about where every record is stored.
The Files API has a separate lifecycle. It stores uploaded images that can be referenced by a file identifier. The guide allows an expiry from one hour to 30 days; omitting the expiry keeps the file permanently, with a separate deletion operation available. It covers supported image formats, not a general document-storage service.
For an application using those files, record the file identifier and chosen expiry in its own lifecycle plan, and remove the stored object when it is no longer needed. Deleting the local image or the application’s reference does not perform the provider’s file-deletion operation. Confirm the documented deletion result, while treating logs and other retained records as separate questions.
These controls reduce how long particular copies persist. They do not move inference or storage into your preferred region. Likewise, a no-training commitment would address a permitted use of data; it would not, by itself, establish data residency or zero retention.
Can you use DeepSeek with EU or US data residency?
Running a downloadable DeepSeek model on infrastructure in the required region is one route. Using a managed provider that offers an appropriate, documented deployment is another. In either case, evaluate the exact model, service, and configuration. A provider’s headquarters, an EU flag on a product page, or an endpoint name is not a complete data-location commitment.
First establish whether the provider actually hosts the model or forwards requests to another provider. A routing service can add another organization to the chain. Its default route, automatic fallback, logging, and retention settings all need to fit the intended use.
A concrete example: storage and processing in Microsoft Foundry
Microsoft lists DeepSeek models sold by Azure. Its data-privacy documentation for that service says prompts and completions are not available to the model providers. This is a statement about that Azure offering, not every third-party service carrying the DeepSeek name.
The same documentation distinguishes Global processing from DataZone processing. A Global deployment may process requests in any geography where the relevant model is deployed. A DataZone deployment restricts processing to the specified zone. An EU zone can span EU member states, so it is not a promise of processing in one chosen country. Stored data remains in the customer-designated geography under the described arrangements.
Before selecting a DeepSeek deployment, check the current model and deployment-type availability. Do not assume every model supports every option. Also distinguish these serverless deployment types from a model you deploy on managed compute, which follows a different configuration path.
The practical lesson applies beyond Azure: if a requirement covers both processing and storage, obtain evidence for both. A correct storage setting cannot compensate for an inference route that falls outside the required boundary.
What self-hosting changes—and what you still need to control
With self-hosting, you run downloaded model files on hardware you operate or in a cloud account you control. That lets you choose where inference takes place. It also gives you responsibility for the application, access controls, patching, capacity, and the copies created around the model.
Check the exact release and licence before deployment. For example, the DeepSeek-R1 repository identifies MIT licensing for its code and weights and notes the origins of its distilled models. The original DeepSeek-V3 repository separates the MIT code licence from its model licence. Avoid a blanket claim that every DeepSeek release or derivative has identical terms.
For a workload that must remain in one environment, keep the inference server and required document-processing components there, then review every outbound connection. A locally running language model may still receive text from a cloud OCR service or send queries through a remote search plugin. Those are additional processing destinations even when the final answer is generated locally.
Operational copies deserve the same attention. A debug trace can contain the full prompt; a backup can outlive the original chat; a monitoring integration can export an exception together with user content. Configure those destinations deliberately, limit the information they collect, and give access only to the people who need it.
A private network or VPC is one part of that design. Check model endpoints, storage permissions, outbound routes, administrator access, and recovery settings together. For a strict local-only requirement, disable unneeded remote integrations and hosted-model fallbacks, then have the responsible team verify the configuration before introducing real restricted data.
Self-hosting is therefore a useful option when location control is essential and you can operate the system. It is not automatically the easiest or cheapest route. Our DeepSeek local vs API comparison covers the operational and cost trade-offs without changing the location checks needed here.
How to check the data location of your setup
You do not need to begin with an elaborate audit spreadsheet. Start with one real workflow, describe the data it uses, and trace the services it calls. The following sequence turns a broad “Is DeepSeek allowed?” discussion into questions the technical owner and provider can answer.
1. Write the requirement in terms you can verify
Specify the data and boundary: customer documents stored in a named country, inference restricted to the EU, or a workload with no external model calls. Include whether the restriction covers logs, backups, remote support, and connected tools. If the rule comes from a customer contract or internal policy, keep its wording with the review.
For an ordinary public-information task, that review may be small. For confidential contracts or customer records, “we prefer local hosting” is too vague to decide whether a service is suitable.
2. Identify the service and endpoint receiving the request
Ask the application owner which provider credentials and base URL it uses, which model is selected, and whether a proxy or router sits between the application and the model. Record any fallback provider. You need configuration evidence, not a chatbot’s answer to “Where are your servers?”
For a managed service, save the selected region and deployment type alongside the relevant documentation. For a self-hosted service, identify the machine or cloud resource running inference. Do not include live API keys or other secrets in the review notes.
3. Follow the content and its retained copies
Trace a request from input to output using the inventory above. Include uploaded images, text extracted from documents, retrieved passages, conversation history, and any tool calls. Then identify logs, caches, monitoring, support attachments, and backups that can retain the same information.
For example, a support assistant may use a regional model but retrieve customer records from a separate search service. If the search or embedding step sends those records elsewhere, the model’s location does not describe the whole request. Note which components exist in your setup rather than assuming that every application uses them.
4. Match each destination to evidence
For a hosted service, read the applicable privacy notice, data-processing agreement where relevant, deployment documentation, subprocessor information, and any agreed exceptions. For infrastructure you operate, use its region, storage, logging, and backup configuration. If a required fact is missing, ask the provider or owner to resolve it before approving that data flow.
A concise request can be more useful than a generic security questionnaire:
For [service, model, and deployment], please confirm: 1. Where are our inputs and outputs processed? 2. Where are files, caches, logs, and backups stored? 3. Can failover, support access, subprocessors, or tools take this data outside [required boundary]? 4. Which retention and deletion terms apply to each category? 5. Which document or agreement makes these commitments for our account?
This is a suggested request template. Replace the brackets with your actual service and requirement; do not attach sensitive sample documents just to ask where they would be processed.
5. Reduce the data and verify the chosen controls
Use only the information needed for the task. Remove credentials, unrelated personal details, and confidential content that is outside the approved scope. Set file expiry where the feature supports it, restrict unnecessary logging, and keep backups and monitoring within the chosen boundary.
Renaming a customer “Customer A” may reduce exposure, but the rest of a document can still identify them. Treat redaction as a reduction in data, not automatic proof that privacy obligations no longer apply. Likewise, encryption is a security measure; it does not change the location where a receiving service processes a request.
6. Record the decision and the changes that require another review
Keep the service, model, deployment type, allowed data, relevant documents, unresolved questions, and responsible owner together. The decision should state what is approved—for example, public product information through one endpoint—not simply “DeepSeek approved.”
Review it again when the provider, model route, region, contract, storage feature, or connected tool changes. A previously acceptable text-only integration may need a new decision when it starts retaining uploaded files or adding external search.
Example: a regional document assistant with an overseas log
Consider a hypothetical company that requires customer documents to stay in the EU. Its documents and inference server are in the EU, but its error-monitoring system records complete requests in another region. The main deployment follows the intended location; the copied request does not.
The immediate task is to address that monitoring path: remove unnecessary request content, use an appropriate destination, or select another design that meets the requirement. Then check historical records and backups under the organization’s retention process. Moving the model server again would not solve the copy already created elsewhere.
This is why the review follows data rather than stopping at the model name. It also gives the team a specific issue to fix instead of requiring a complete rebuild without knowing the cause.
China, data sovereignty, and international transfer requirements
A stated processing location matters because organizations may have legal, contractual, sector, or procurement restrictions on where data can go. Those requirements are separate from whether a model can perform the task well. Security safeguards, a licence to use model weights, and permission to transfer personal data answer different questions.
For EEA personal data, the EDPB’s international-transfer guide explains the routes under GDPR Chapter V: an adequacy decision, appropriate safeguards, or limited derogations where their conditions apply. China is not on the European Commission’s current adequacy list.
The EDPB also explains that transfer safeguards do not replace other obligations, such as a lawful basis, data minimization, security, and a processor contract where required. Its discussion of standard contractual clauses includes assessing the circumstances of the transfer and relevant safeguards. A contract labelled “DPA” or a claim of encryption should therefore be reviewed for what it actually covers.
Keep regional rules separate. A conclusion reached under the EEA framework should not automatically be reused for the UK, Switzerland, or another jurisdiction. Have the organization’s privacy or legal owner assess the applicable requirements for the actual parties and data flow.
What the regulator statements do—and do not—establish
On June 27, 2025, the Berlin Commissioner for Data Protection said DeepSeek’s transfers to China violated Article 46(1) and notified Apple and Google in Germany. That release described a notice for the platforms to review; it did not itself confirm an app-store removal.
On January 30, 2025, Italy’s Garante announced an urgent limitation on processing Italian users’ data and opened an investigation. These dated actions explain why transfer safeguards matter. They are not a current worldwide ban list or a ruling that every independently hosted DeepSeek model has the same data flow.
For an organization deciding whether it can proceed, the useful next step is a review of its specific service and transfer arrangement. App availability alone does not demonstrate that the organization’s use meets its obligations.
Which route fits your information?
For public or low-sensitivity tasks, such as drafting from published product information, a hosted service may be appropriate under your organization’s rules. Keep private background material out of the prompt, and check whether the chosen feature sends content to additional tools.
For confidential or regulated work, choose an approved service and data flow before uploading real records. A documented managed deployment can reduce operational work; self-hosting can give you more direct control over location. Either choice still needs suitable access, retention, and security controls.
For a strict country-only or local-only requirement, eliminate routes whose documented processing scope is broader than the requirement. A multi-country data zone may be insufficient even when every country is in the EU. If the model or feature you need is unavailable within the required boundary, use an approved alternative or change the workflow instead of quietly relaxing the restriction.
Keep passwords, API keys, private keys, and other credentials out of prompts regardless of the route. For a broader deployment decision, our DeepSeek enterprise guide connects these checks with use cases, operating responsibilities, and costs.
DeepSeek data residency FAQ
Does every DeepSeek model send data to China?
No. The operator and configuration determine where a request goes. DeepSeek’s own covered services have the policy statements discussed above; a downloaded model running on your infrastructure or a model hosted by another provider follows that deployment’s data path. Check connected services before treating a setup as local.
Can I select an EU region for the official DeepSeek API?
The public documents reviewed here do not establish such an option for the direct API. If EU processing is mandatory, request a commitment for your account or evaluate a separately hosted deployment with documented coverage. Do not infer EU residency from the location of your application server.
Will a VPN change where DeepSeek stores my data?
A VPN changes the network route from your device and may change the location your connection appears to come from. It does not select the model service’s inference servers or storage region. Use the provider’s documented deployment controls to address a residency requirement.
Does encryption or a training opt-out solve the residency question?
No. Encryption protects data in particular states or channels; a training opt-out concerns how data may be used. Neither setting, on its own, changes the processing country, controls all retained copies, or proves that a cross-border transfer is permitted.
Does DeepSeek’s cache cleanup mean all API data is deleted?
No. The documented cleanup concerns unused context cache. Uploaded Files API objects have their own expiry or deletion process, while application logs, account records, and other copies require separate review. Check each record type rather than assigning one retention period to the whole service.
Is a local DeepSeek app the same as a self-hosted model?
No. An app can run on your computer while sending prompts to a remote API. For local inference, the model itself must run in the intended environment. Its document tools, plugins, logs, and backups also need to follow your location requirement.
Does hosting DeepSeek in Europe make it GDPR compliant?
European hosting can address part of a location requirement. It does not establish a lawful basis, appropriate access controls, valid retention practices, or every other obligation. The assessment must cover the application and its recipients as well as the model server.
Can an IP lookup prove that my data stays in one country?
No. An IP lookup may identify the apparent location of an endpoint or network edge. It does not reveal every processing server, log, backup, support system, or onward destination. Use deployment configuration and applicable written commitments, and resolve any gaps with the provider.
Choose a deployment you can account for
Start with the information you need to use and the boundary it must stay within. Then choose a service whose processing, storage, and connected tools fit that requirement. If you cannot explain where a request and its retained copies go, keep restricted data out of that workflow until the missing part is resolved. That gives you a clear basis for choosing how to use DeepSeek and for knowing when the choice needs another review.