Using Chinese AI models in Europe: hosted API or self-hosted weights

The AI Act is origin-blind

Nothing in Regulation (EU) 2024/1689 distinguishes Chinese, American or European models. Its scope follows function and geography of effect: it reaches providers placing AI systems or general-purpose models on the EU market wherever they are established, and it reaches providers and deployers in third countries where the system's output is used in the EU, as Article 2(1) provides; the Commission's GPAI questions and answers repeat the point for model providers wherever established.

Two consequences follow for the European buyer. First, your deployer duties are yours, whatever the model's nationality: the transparency rules we covered in our Article 50 update and staff AI literacy apply identically whether the engine is from Hangzhou or San Francisco, as do the prohibited-practice rules in force since February 2025, and the high-risk rules will do the same when they apply, from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems under the consolidated text of 27 July 2026. Second, a Chinese provider serving the EU market carries EU obligations it may or may not honour (a model already on the market before 2 August 2025 has until 2 August 2027 to comply), and the gap between the two becomes your diligence question, because you are the one inside the enforcement perimeter.

Hosted API or self-hosted weights

The legally decisive choice is architectural. Path A, the hosted API: every prompt, and whatever documents your staff paste into it, travels to the provider's servers, together with account and usage data. Where those servers are in China, the personal data in that flow, and there is almost always some, is transferred, under Chapter V of the GDPR, to a third country without an adequacy decision, since China is not on the Commission's adequacy list, so it needs appropriate safeguards and a transfer impact assessment that confronts Chinese state-access law directly, an assessment that is difficult to pass for anything sensitive.

The Italian Garante has already ordered, as an urgent measure, the definitive limitation of the DeepSeek companies' processing of personal data of data subjects located in Italy, by provvedimento of 30 January 2025 (docweb 10098477) (see also the Garante's announcement), finding breaches of the cooperation, information, legal-basis, data-subject-rights, security and representative provisions, with storage in China treated as a security failure, after judging the companies' answers, including the argument that they do not operate in Italy and that European law does not apply to them, entirely unsatisfactory. The order concerns the hosted service and says nothing about independently hosted DeepSeek weights; a transfer mechanism alone would not have cured its findings, and no further Garante decision on DeepSeek had been published by the date of this update.

Path B, self-hosted open weights: you download the model and run it on EU or Swiss infrastructure. Provided nobody in China can reach the deployment, whether through remote support access, telemetry, logging or an integration, no personal data is disclosed to China; the EDPB treats remote access from a third country as a transfer where a separate controller or processor gains the access, even if the data stay stored in the EU (Guidelines 05/2021, paragraph 16 and Example 11; access by the controller's own staff from abroad is internal processing, Example 8), so the data flows have to be verified and documented; the server location alone settles nothing, and where no transfer occurs the controller stays accountable under Articles 5, 24 and 32 for processing that reaches a third country.

A separate Swiss hosting provider is still a third-country recipient for an EU controller; the transfer needs no further safeguard because the Commission's adequacy decision for Switzerland stands; Switzerland is outside the EEA.

Once the transfer question is settled, the remaining work is the deployment's own compliance file: the ordinary GDPR file for the deployment itself, since removing the transfer supplies neither a lawful basis nor transparency, rights handling or, where the use case calls for one, a data protection impact assessment; licence terms (open-weight licences vary, and some carry use restrictions); model provenance and integrity, including the data protection provenance of the weights: the EDPB's Opinion 28/2024 treats a model trained on personal data as anonymous only where extraction and regurgitation of that data are insignificant using reasonable means, and expects a deploying controller to have assessed, in proportion to the risk, whether the model was developed through unlawful processing, so a documented check on the training-data position belongs in the file; security testing before the weights touch production, output quality and bias evaluation for your use case, and, for financial entities, the vendor and register logic we described in our DORA update.

When you become the provider

The Commission's guidelines for providers of general-purpose AI models of 18 July 2025 address the scenario of fine-tuning or otherwise modifying a model. The guidelines draw the line narrowly: a downstream modifier becomes the provider of the model only where the modification leads to a significant change in the model's generality, capabilities or systemic risk, with an indicative criterion of training compute for the modification exceeding one third of the original model's, and where that threshold is crossed the obligations attach to the modification, for instance supplementing the technical documentation for what you changed. Ordinary fine-tuning does not, by itself, flip the role.

Two questions have to be kept apart. Who provides the general-purpose AI model is answered by the significant-change test. Who provides the AI system built around the model is a separate question: an organisation that develops a system around an unchanged third-party model and places it on the market, or puts it into service under its own name, and putting into service includes first use for its own purposes, is the provider of that system, with the system-level duties that follow and, for a high-risk system, the Article 25 conditions. It does not thereby become the provider of the model, and installing third-party software as supplied does not make an organisation the provider of anything.

The direction of travel is still real: the more you modify, integrate and market, the more provider-like your position becomes, up to and including the Article 50 marking duties for a system you place on the market under your own brand (a content-generating system already on the market before 2 August 2026 has until 2 December 2026 to meet Article 50(2)). The open-source exemptions soften parts of this for models released under free and open-source licences, subject to conditions, and never for models classified as carrying systemic risk. In practice, the moment your roadmap says "we fine-tune and ship it", the AI Act analysis must be redone against that significant-change test, and documented, even where the answer is that the role has not flipped.

The remaining questions

Four further questions decide real deployments. Confidentiality: a hosted Chinese API is a third party like any other, except that contractual remedies against it are, realistically, harder; client-confidential and trade-secret material does not belong in Path A regardless of the GDPR analysis. Sector overlays: regulated firms carry their own outsourcing, secrecy and resilience rules on top. Procurement policy: in our experience, public-sector and enterprise customers increasingly flow down restrictions on Chinese AI tooling in their contracts; check what your own client contracts already promise before your engineers pick a model. And Switzerland: the same architecture question governs, with the transfer analysis running under the FADP in parallel; Swiss businesses should not assume the Swiss analysis is softer, and groups spanning both should write one policy for the two regimes. A blanket ban is not what we recommend: a documented, architecture-based policy captures the cost advantage where the risk is manageable, blocks it where it is not, and is easier to defend than a rule written in reaction to headlines.

What this means for you

• Decide the architecture before the model, and write the policy once. Hosted API versus self-hosted weights determines most of the legal analysis, so choose deliberately, per use case; one architecture-based rulebook for the EU and Switzerland is easier to defend than ad hoc decisions or a blanket ban.
• Treat hosted Chinese APIs as restricted-data zones. No personal data without a transfer solution that survives scrutiny, and no confidential material as a matter of policy.
• Document the self-hosted deployment. The deployment's own GDPR file, licence review, provenance (including the training-data position) and security testing, evaluation results, and the DORA vendor entries where they apply.
• Re-run the analysis if you fine-tune, integrate or ship. Under the Commission's GPAI guidelines only a significant change to the model flips the model role, but building and putting into service your own system around the model, including for internal use, makes you the provider of that system; assess and document each time.

Isak Legal advises companies on AI deployment governance, model procurement and the interaction of the AI Act, data protection and sector rules across the EU and Switzerland. See our AI, Data & Technology page, or get in touch.

This client update is provided for general information only, reflects the position as at 27 September 2026 and does not constitute legal advice or create a lawyer-client relationship. Enforcement practice and guidance in this area are developing quickly; verify the current position at the official sources linked above before acting, and note that references to specific models are illustrative only. For advice on a specific matter, please contact us.