DeepSeek writes down where the data goes. A regulator wrote down the exception.

Most arguments about a Chinese AI service rest on inference. This one does not. DeepSeek’s own privacy policy, last updated 10 February 2026, states: “To provide you with our services, we directly collect, process and store your Personal Data in People’s Republic of China.” The controller named in the policy is Hangzhou DeepSeek Artificial Intelligence Co., Ltd., with a registered address in China. Nothing here is a claim by a competitor. It is the vendor’s own text.

The European Union has no adequacy decision for China under Chapter V of the GDPR. A transfer still needs a legal basis, and the vendor has to accept that GDPR applies at all. Four dated findings show how that went.

January 2025: chat history sat on an open port

Wiz found a ClickHouse database belonging to DeepSeek “hosted at oauth2callback.deepseek.com:9000 and dev.deepseek.com:9000”, reachable with no authentication. It held “chat history, backend data and sensitive information, including log streams, API Secrets, and operational details”, with “over a million lines of log streams”. Wiz disclosed it and DeepSeek “promptly secured the exposure”.

This is an operations failure, not a model failure. It is worth naming for one reason: the plaintext conversations existed in a place a stranger could read, and no user of the service had any way to know.

January 2025: an EU regulator asked, and was told GDPR does not apply

Italy’s Garante ordered the limitation of processing of Italian users’ data by Hangzhou DeepSeek and Beijing DeepSeek. The two companies, in the Garante’s account, “declared that they do not operate in Italy and that European legislation does not apply to them”. The Garante called that reply “entirely unsatisfactory”.

For a Romanian data protection officer this single exchange settles the question. GDPR Article 28 requires a written contract with a processor that accepts the regulation’s duties. A vendor that tells a supervisory authority the regulation does not bind it cannot be that processor.

April 2025: a regulator found that the prompts themselves left

South Korea’s Personal Information Protection Commission published the results of its status examination on 24 April 2025. It found that “DeepSeek transferred users’ personal data to servers located in China and the U.S.” and that “it failed to obtain separate consent from users regarding cross-border data transfer”. Specifically, “DeepSeek transferred the details of device information, user networks, applications, and user input to Beijing Volcano Engine Technology Co., Ltd.” The commission recorded that “DeepSeek has blocked the transfer of user input since April 10, 2025”, and that the company described Volcano as a ByteDance subsidiary while the commission found it to be an independent corporation.

This is the finding to cite, and it is worth being precise about why. A regulator examined the service and recorded that the user input itself went to a third company until a named date. That is a finding on a public record, with a date and a named recipient. A capability claim about what an application could do is not the same thing, and a bank cannot put one in front of a supervisor.

June 2025: a European regulator named the article that applies

Berlin’s data protection commissioner, joined by Baden-Württemberg, Rhineland-Palatinate and Bremen, reported DeepSeek to Apple and Google as illegal content under Article 16 of the Digital Services Act. The press release states: “The service transfers the personal data collected from users to Chinese data processors and stores it on servers in China.” The commissioner, Meike Kamp, said: “The transfer of user data by DeepSeek to China is unlawful.” The violation named is Article 46(1) of the GDPR.

Romania’s supervisory authority applies the same Chapter V. A champion inside a Romanian bank who is asked “under which article” now has one, from a European regulator, in writing.

July 2025: a regulator wrote down the exception

The Czech national cyber security agency, NÚKIB, issued a warning about DeepSeek products at threat level High. Its reasoning is about the company, not the mathematics: the risk arises “from the legal and political environment of the People’s Republic of China to which the company DeepSeek is fully subject”. Then comes the sentence that matters most in this article. The warning does not apply to open-source DeepSeek large language models whose source code is publicly accessible and which are “deployed locally, without any capability to communicate with servers used by the company DeepSeek or its related entities”.

A regulator drew the line in the right place. The risk is the network path to the vendor, not the open weights. Cut the path and the same model falls outside the warning.

What this means for a regulated organisation

• Nothing here requires an organisation to judge a foreign company’s intentions. The location is in the vendor’s own policy, and two regulators have recorded transfers.
• The Czech warning binds operators of critical information infrastructure and essential services under the Act on Cybersecurity. Bans in other jurisdictions apply to government devices. None of them is a rule that binds a private Romanian bank. Do not quote them as law.
• An open model is not the same thing as a vendor’s service. NÚKIB separates the two explicitly, and the separation is the network path.
• Cisco tested DeepSeek R1 against fifty prompts from the HarmBench dataset and reported “a 100% attack success rate, meaning it failed to block a single harmful prompt”. That is a safety finding, not a privacy one, and it applies to the weights. Whoever runs an open model owns its guardrails.