Rimon

Virtual Fireside Chat: EU Market Entry by Chinese AI Companies

Insights Virtual Fireside Chat: EU Market Entry by Chinese AI Companies Judy Deng · September 22, 2026

Speaker: Steven De Schrijver Steven De Schrijver is a Partner at Allegiance Law in Belgium with more than 30 years of experience advising Belgian and international companies on technology, corporate, and regulatory matters. His practice spans technology law, digital business, data protection and privacy, cybersecurity, corporate transactions, and M&A, with particular experience in the technology, media, telecommunications, and life sciences sectors. He regularly advises international companies on complex technology projects and cross-border matters and has been recognized by Chambers Europe, Legal 500, IFLR, and Who’s Who Legal for his work.

Host: Judy Deng Judy Deng is a Partner at Rimon Law in the Silicon Valley office. Ms. Deng advises international technology companies, investors, and emerging businesses on complex cross-border corporate and regulatory matters. Her practice focuses on corporate and securities law, including cross-border restructurings and reorganizations, financings, mergers and acquisitions, executive and employee incentive programs, and strategic intellectual property transactions. She has extensive experience working with companies across the technology sector, including interactive entertainment, digital media, software, and medical technology.

Opening Remarks:

Judy Deng: Welcome, and thank you for joining us. As Chinese AI and technology companies increasingly pursue growth in Europe, they are navigating one of the world’s most complex and rapidly evolving regulatory environments.

The EU AI Act is central to that landscape, but it is only one part of a broader framework that also includes data protection, cybersecurity, product safety and data-access rules. The critical task is to understand how these regimes intersect and to address them from the outset of product development. Although our primary audience is China-based businesses and investors, today’s discussion applies equally to other non-EU companies. Steven, thank you for joining me.

Judy Deng: Let’s begin with a practical question: when should a Chinese or other non-EU AI company planning to enter the European market begin addressing regulatory compliance?

Steven De Schrijver: At the product-design stage, not when the product is ready to launch. Compliance is becoming part of product architecture. If you discover just before launch that your AI system is high-risk, that your connected product needs a different data-access set-up, or that your cybersecurity documentation is inadequate, it can be expensive or even technically difficult to fix.

I would therefore start with a regulatory mapping exercise. What exactly are you selling: an AI system, a general-purpose AI model, software, a medical device, an IoT product, a cloud service, or a combination? Then map which rules apply – not only the EU AI Act, but also the GDPR, the EU Data Act, the Cyber Resilience Act (CRA) and any sector-specific product rules. Treat EU compliance as part of market-entry strategy, not as a last-minute legal check.

Judy Deng: When does the EU AI Act apply to a Chinese company, and does it matter where its models and servers are located?

Steven De Schrijver: The EU AI Act has deliberately broad territorial scope. It applies when a provider places an AI system or a general-purpose AI (GPAI) model on the EU market or puts an AI system into service in the Union, regardless of where the provider is established. That covers distribution through a European importer, but also SaaS, API and cloud models where European customers access the system directly from a Chinese provider.

Article 2(1)(c) also extends the rules to providers and deployers outside the EU where the output produced by the AI system is used in the Union. If a Chinese company runs an AI system in Shanghai that assesses credit risk, and an EU company uses those outputs to take decisions in Europe, the fact that the computation happened in China does not necessarily take the system outside the Act. Not every output accessible in Europe automatically triggers the Act – the actual use and the facts matter – but server location is no longer an effective regulatory perimeter.

Note also that the EU AI Act does not regulate “Chinese companies” as a category. It regulates legal and natural persons according to their role and activities. Ownership and control can matter under other regimes, such as FDI screening, sanctions or export controls, but Chinese ownership as such does not determine whether the EU AI Act applies.

Judy Deng: How can a company determine which role it occupies in the European AI supply chain, and why does that matter?

Steven De Schrijver: Role allocation comes first, because the obligations follow the role. The provider develops an AI system or GPAI model, or has it developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses the system under its authority. An importer is an EU-established party that places on the market a system bearing the name or trademark of a non-EU provider. A distributor makes the system available further down the chain. An authorised representative performs specific statutory tasks on behalf of a non-EU provider.

Within a group, a Chinese parent may be the provider while its Belgian, German or French subsidiary is the importer or distributor. Roles can also change. Under Article 25, an importer, distributor, deployer or other third party becomes the provider of a high-risk system if it puts its own name or trademark on it, substantially modifies it, or changes its intended purpose so that the system becomes high-risk. I would literally draw the supply chain on one page and assign a role to each participant.

Judy Deng: For a Chinese provider without an EU establishment, when is an authorized representative required?

Steven De Schrijver: A provider established outside the EU must, by written mandate, appoint an authorised representative established in the Union before making a high-risk AI system available on the EU market (Article 22). A similar requirement applies to non-EU providers of GPAI models (Article 54), although qualifying free and open-source models are exempt unless they present systemic risk.

The representative is not a mailbox. The mandate must enable it to verify that the required conformity documentation exists, keep documentation available for authorities, respond to regulatory requests, cooperate with market-surveillance authorities and, where applicable, handle registration. Authorities can also address the representative directly.

When selecting a representative, look at regulatory competence, technical capability, confidentiality safeguards and responsiveness. The agreement should also address what happens if the representative believes the provider is not compliant, because the Act requires it in certain circumstances to terminate the mandate and inform the authorities. This is a real compliance relationship, not simply an address in Europe.

Judy Deng: How can a company determine whether its AI system is high-risk, and why does that classification matter?

Steven De Schrijver: I would use a two-track analysis. The first track covers AI that is a safety component of a product, or is itself a product, covered by the EU product legislation listed in Annex I, where that product is subject to third-party conformity assessment. The second covers the use cases listed in Annex III: biometrics, critical infrastructure, education and vocational training, employment, access to essential private and public services, law enforcement, migration, asylum and border control, and the administration of justice and democratic processes.

There are limited exceptions for Annex III systems that do not pose a significant risk of harm, for example because the AI performs only a narrow procedural or preparatory task (Article 6(3)). But the provider must document why the exception applies and must still register the system in the EU database. Profiling of natural persons always remains high-risk.

Classification determines the whole compliance architecture. High-risk status triggers detailed requirements on risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness, cybersecurity, conformity assessment, registration and post-market monitoring. Rather than creating separate policies for each, I would build them into the product-development lifecycle, with each stage producing evidence. The European Commission published draft classification guidelines on 19 May 2026; the final version, expected by the end of 2026, will be important for systems close to the boundary.

Judy Deng: How does the EU AI Act interact with existing product-safety rules for AI-enabled products?

Steven De Schrijver: The EU AI Act does not replace existing EU product legislation; it sits on top of it. For an AI-enabled medical device, you first analyse the product under the Medical Devices Regulation (MDR) or the In Vitro Diagnostic Medical Devices Regulation (IVDR). If the AI is a safety component of such a product, or is itself the product, and third-party conformity assessment is required, the AI system is high-risk under Article 6(1). Providers can, however, integrate EU AI Act testing and documentation into the existing product procedures rather than running two separate processes (Article 8(2)).

For industrial products, the Digital Omnibus on AI clarified that an AI function which merely assists the user or optimises performance is not a “safety component” where its failure does not endanger health or safety. It also moved the Machinery Regulation from Section A to Section B of Annex I, so AI safety components in machinery are now dealt with primarily through the sectoral machinery route rather than the full EU AI Act high-risk regime.

The intended purpose of the AI within the product is therefore crucial, and product regulatory and AI compliance teams cannot work in silos.

Judy Deng: How should companies use their contracts with European distributors, importers, customers and other partners to allocate EU AI Act responsibilities?

Steven De Schrijver: The EU AI Act creates statutory responsibilities throughout the supply chain, but many of them depend on information and cooperation from other parties. Contracts should clarify who is the provider, importer, distributor and deployer; who prepares and maintains technical documentation; who is responsible for conformity assessment and registration; and who handles post-market monitoring, regulatory enquiries and serious incidents.

I would also address access to technical information, substantial modifications and changes to intended purpose (which can trigger a change of role under Article 25), audit rights, vulnerability management, upstream model changes, trade-secret protection, GDPR and EU Data Act responsibilities, indemnities, and suspension, recall and termination.

The important caveat is that parties cannot simply write “Party A has no regulatory responsibility.” Statutory responsibility follows the EU AI Act. Contracts determine how parties cooperate and allocate the economic consequences.

Judy Deng: What should Chinese foundation-model developers know about placing GPAI models on the EU market?

Steven De Schrijver: A company that develops a GPAI model and places it on the EU market is a GPAI provider. Under Article 53, it must maintain up-to-date technical documentation, provide specified information to downstream AI-system providers, implement a policy to comply with EU copyright law and publish a sufficiently detailed summary of the training content using the European Commission’s template. Signing the GPAI Code of Practice is voluntary but the simplest way to demonstrate compliance.

Providers of GPAI models with systemic risk face additional obligations under Article 55: model evaluation, adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting and cybersecurity safeguards. For GPAI models placed on the market from 2 August 2025, these obligations already apply; providers of models placed on the market before that date have until 2 August 2027 to comply. Since 2 August 2026, the Commission has had enforcement powers in relation to GPAI obligations.

If a company instead uses a third-party model inside its own European AI application, the upstream model provider normally retains the GPAI obligations, while the company may become the provider of the downstream AI system. But a sufficiently significant modification of a third-party model can make the modifier a provider of the modified model; the European Commission’s GPAI guidelines set out when that threshold is crossed.

Under the Digital Omnibus on AI, the AI Office now has exclusive supervisory and enforcement competence for many AI systems built on a GPAI model developed by the same provider or undertaking, subject to specific exceptions, including certain regulated-product and sensitive-sector systems. The key question is always: what exactly are you placing on the EU market – the model, the downstream AI system, or both?

Judy Deng: How should companies coordinate compliance with the EU AI Act and the GDPR?

Steven De Schrijver: The EU AI Act does not replace the GDPR; they apply in parallel. If personal data are used to train, fine-tune, test or operate an AI model, you still need a GDPR legal basis, transparency, purpose limitation, data minimisation, retention rules, security and respect for data-subject rights. Automated decision-making requires separate analysis under Article 22 GDPR, and a DPIA may be required. Deployers of high-risk systems can use the information supplied by the provider when carrying out that DPIA (Article 26(9) EU AI Act).

The EDPB addressed AI models in its Opinion 28/2024, including when a model can genuinely be regarded as anonymous, whether legitimate interests can support development or deployment, and the consequences of using unlawfully processed training data. In July 2026 it adopted draft guidelines on anonymisation (Guidelines 02/2026) and on web scraping for generative AI (Guidelines 03/2026), both highly relevant to model developers; the consultation runs until 30 October 2026.

Do not create two parallel risk systems. Build a single AI-governance process with modules covering EU AI Act risk, privacy, cybersecurity and fundamental rights. One system inventory can feed the AI classification, the DPIA and the vendor review; one data map can support both GDPR and EU AI Act data governance.

Judy Deng: How does the EU Data Act affect providers of AI-enabled connected products and cloud-based AI services?

Steven De Schrijver: Much of the economic value of modern AI products comes from data generated after sale. For connected products – vehicles, industrial machines, smart devices, medical equipment – the EU Data Act gives users rights to access and use product-generated data and, in appropriate cases, to have that data shared with third parties. The Act has applied generally since 12 September 2025, and connected products placed on the market after 12 September 2026 must be designed so that product data is accessible to the user by default (“access by design”).

For cloud and SaaS businesses, the EU Data Act introduces switching and portability requirements to reduce vendor lock-in, and switching charges, including qualifying data-egress charges, must be phased out entirely from 12 January 2027. Put simply, AI governance determines how the intelligence operates; the EU Data Act increasingly determines who can access and use the underlying data.

Judy Deng: What penalties and broader enforcement risks should companies consider?

Steven De Schrijver: Fines can reach €35 million or 7% of worldwide annual turnover, whichever is higher, for prohibited AI practices; €15 million or 3% for most other infringements and, in fines imposed by the European Commission, for GPAI model providers; and €7.5 million or 1% for supplying incorrect, incomplete or misleading information. Lower caps apply to SMEs; the Digital Omnibus extended the lower-cap treatment to small mid-caps for the categories covered by Article 99(4) and (5).

But I would not focus exclusively on fines. The greater commercial risk can be regulatory intervention affecting the product itself: corrective measures, market restrictions, withdrawal or recall. And a European importer or enterprise customer may simply refuse to launch or procure a product if it cannot obtain the documentation it needs for its own compliance. The real risk is partly regulatory and partly market access.

Judy Deng: What practical steps should companies take to build a coordinated governance framework for EU compliance?

Steven De Schrijver: I would build it around one inventory and one lifecycle, rather than separate programmes for every European regulation, in eight steps.

First, inventory the relevant AI systems, models, datasets and connected products.

Second, determine the legal entity and regulatory role for each product and use case.

Third, classify the AI risk and identify adjacent regulation: the GDPR, the EU Data Act, the CRA, product safety and sector-specific rules.

Fourth, appoint clear internal ownership. Legal cannot do this alone; product, engineering, cybersecurity and privacy teams all need defined responsibilities.

Fifth, run a gap assessment and integrate compliance gates into product development. The output should not be a fifty-page memo but a practical remediation matrix: requirement, existing control, gap, action, owner, deadline and evidence.

Sixth, establish third-party governance covering foundation models, datasets, cloud services, APIs and software components.

Seventh, create one coordinated incident process. A cybersecurity incident, an AI incident and a privacy breach may overlap; separate escalation mechanisms create unnecessary risk.

Eighth, maintain the evidence: classifications, assessments, tests, decisions, approvals, contracts, logs and remediation actions.

International groups should add an EU layer covering the authorised representative, importers, distributors and local regulatory contacts. The objective is not the largest compliance manual, but a system that can demonstrate who made which decision, on what basis, and with what controls.

Judy Deng: What developments should companies watch over the next 12 to 24 months?

Steven De Schrijver: First, enforcement. The EU AI Act’s general application date of 2 August 2026 has passed. The Article 50 transparency obligations now apply (with a grace period until 2 December 2026 only for machine-readable marking of AI-generated content by systems already on the market). The AI Office and national authorities now have enforcement powers in relation to the provisions that are already applicable. New Article 5 prohibitions on “nudifier” tools and AI-generated child sexual abuse material apply from 2 December 2026.

Second, the new high-risk dates under the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026): Annex III high-risk requirements apply from 2 December 2027, and those for high-risk AI embedded in Annex I products from 2 August 2028. Treat these extensions as implementation time, not a reason to postpone work.

Third, harmonised standards on risk management, datasets, logging, human oversight, cybersecurity and quality management. Once their references are published in the Official Journal, they provide a presumption of conformity (Article 40) and may ultimately matter more operationally than pages of legal commentary.

Finally, do not watch the EU AI Act in isolation. The CRA’s vulnerability and incident-reporting obligations apply from 11 September 2026, and its full requirements from 11 December 2027. Europe is moving toward an integrated regulatory environment covering AI, data, cybersecurity, privacy and product safety. The companies that adapt best will not be those that ask, “How do we comply with each new European law?” but those that ask, “How do we build products and governance processes that accommodate European regulation by design?”

Judy Deng: Thank you very much for those insightful observations. I feel as though I have just taken a masterclass in navigating the EU AI Act and the broader European regulatory landscape. It has been an exceptionally informative and timely conversation, and I hope our audience has found it as valuable as I have.