Editorial frame. This article observes and synthesizes published guidance from named regulators and standards bodies. It is editorial reading for compliance officers, GCs, DPOs, and boards. It is not legal or compliance advice for your specific deployment. AI governance obligations depend on your jurisdiction, sector, role (provider, deployer, importer, distributor), and the systems you operate. Engage qualified counsel and your data protection authority before acting on any structural pattern shown here.
The question most general counsel at Southeast Asian AI companies ask first is “we have no EU office, so does the EU AI Act apply to us.” That is the wrong starting question. The Act’s Article 2 does not ask where a company is established. It asks where the company’s AI system is placed on the market, or where the system’s output is used. A Singapore SaaS vendor with zero EU employees can be fully in scope the moment an EU customer subscribes. This essay walks the five scope triggers a non-EU company can hit, using worked examples drawn from Singapore, Malaysia, and Indonesia, and closes with the structural comparison to GDPR Article 3 that most compliance teams already have a mental model for.
The Five Scope Triggers in Article 2, and Which One Catches Most Non-EU Companies
EU Regulation 2024/1689, Article 2(1), contains seven sub-paragraphs defining who the Act binds. Four are the ones a non-EU company needs to check first.
Article 2(1)(a) binds “providers placing on the market or putting into service AI systems or placing on the market general-purpose AI models in the Union, irrespective of whether those providers are established or located within the Union or in a third country.” This is the broadest and least ambiguous trigger. Market placement covers commercial availability in any form: SaaS subscriptions, API access, licensed products.
Article 2(1)(c) binds “providers and deployers of AI systems that have their place of establishment or are located in a third country, where the output produced by the AI system is used in the Union.” This is the trigger with no direct precedent in GDPR, and it is the one that surprises B2B AI vendors most often.
Article 2(1)(d) binds importers and distributors of AI systems, typically EU-established entities bringing non-EU systems into the market, but relevant to non-EU providers because of how obligations shift along the supply chain.
Article 2(1)(f) requires “authorised representatives of providers, which are not established in the Union” wherever a provider trigger applies. This is a structural consequence of the other triggers, not a separate scope question.
The Act carves out military and national security use (Art 2(3)), purely personal non-professional use (Art 2(10)), free and open-source models unless high-risk or prohibited (Art 2(12)), and pre-market research and development other than real-world testing (Art 2(8)).
The Output-Used-in-the-EU Trigger
Article 2(1)(c) is the trigger worth the most attention because it requires no direct relationship between the non-EU provider and any EU person. A non-EU company providing an AI system to a non-EU client, where that client’s EU business unit later uses the system’s output, can fall in scope even though the provider never contracted with an EU entity and may not know its output reaches EU territory.
Consider an Indonesian HR-technology company offering an AI candidate-screening tool to multinational clients. One client is a US multinational with a German office. The screening tool ranks and scores applications from German job applicants, and the German office uses those scores in hiring decisions. The Indonesian company’s AI system output is used in the Union. The screening tool falls within Annex III’s high-risk category for employment and worker management, specifically recruitment and filtering of job applications, which means the Indonesian company faces the same high-risk obligation chain as an EU-established provider, despite having no EU entity, no EU customer relationship, and no EU employees.
A second example: a Malaysian fintech provides an AI credit-decisioning API to a Philippine bank. The Philippine bank has EU-resident customers, including expatriates and overseas workers holding EU accounts. The credit score the API generates governs lending decisions affecting those EU residents. Whether Article 2(1)(c) applies here turns on whether the output has genuine operational effect within the EU, a decision made using the output, a status change caused by it, rather than merely that the output is transmitted to or through EU infrastructure. The Act does not define “used in the Union” with precision, and this interpretive gap is expected to require formal AI Office guidance to resolve. Any non-EU company relying on a narrow reading of this trigger should treat that reading as provisional, not settled.
The operational consequence of Article 2(1)(c) is identical to Article 2(1)(a): there is no lighter compliance track for output-triggered scope. The same non-EU representative requirement, the same conformity obligations, apply.
What the Act Activates Once a Company Is in Scope
Once a non-EU provider is in scope for a high-risk AI system, four structural obligations activate. Article 22 requires appointing an EU-established authorized representative, through a written mandate, before placing the system on the EU market. The representative is not a mailbox: it must actively verify that the EU declaration of conformity and technical documentation are properly prepared, maintain documentation for ten years, and cooperate with market surveillance authorities. Article 47 requires a written declaration of conformity for each high-risk system, also retained for ten years. Article 48 requires CE marking, including a digital marking path for software-only systems. Article 49 requires registration in the EU AI database before market placement.
General-purpose AI model providers follow a lighter but structurally similar track. Article 53 requires technical documentation under Annex XI, disclosure to downstream integrators, compliance with EU copyright law, and a published training-data content summary. Article 54 requires the same non-EU representative appointment as Article 22, adapted for GPAI providers. Models presenting systemic risk, generally those trained above defined compute thresholds, carry additional obligations under Article 55: adversarial testing, systemic risk assessment, and incident reporting to the AI Office.
Article 25 governs a separate scenario: when a distributor, importer, deployer, or other party applies its own name or trademark to an existing AI system, substantially modifies it while it remains high-risk, or changes its intended purpose in a way that makes it high-risk, that party becomes the provider and inherits the full provider obligation chain. A German logistics company that licenses a Malaysian warehouse-automation system and rebrands it under its own name becomes the provider under Article 25, and the original Malaysian developer’s provider obligations shift accordingly, though the developer must still cooperate and provide necessary technical information. Article 25(3) requires a written supply-chain agreement to allocate these obligations explicitly, which is the practical mechanism non-EU vendors and their EU distributors should have in place before any rebranding or modification occurs.
The GDPR Article 3 Parallel: What Is Familiar, What Has Changed
Most general counsel and data protection officers at non-EU companies have already worked through a GDPR Article 3 analysis. That experience is a useful anchor, because the AI Act borrows GDPR’s structural logic and extends it.
GDPR Article 3(1) applies wherever an establishment in the Union carries out the processing, regardless of where the processing itself occurs. Article 3(2) extends GDPR to non-EU controllers offering goods or services to EU data subjects, or monitoring their behavior within the Union. The EDPB’s Guidelines 3/2018 interpret the targeting criterion broadly: EU-language website content beyond English, EU currency pricing, and EU-specific delivery options are all treated as evidence of intentional targeting, and the targeting need not be exclusive.
The AI Act’s Article 2(1)(a) mirrors this logic but shifts the object of regulation from data processing to market placement. The question moves from “are you processing EU persons’ data” to “are you placing an AI product on the EU market.” The non-EU representative requirement carries an almost exact structural parallel: GDPR Article 27 requires non-EU controllers and processors to designate an EU representative, and AI Act Articles 22 and 54 replicate that structure for AI providers. A company that has already appointed a GDPR Article 27 representative will find the AI Act appointment process structurally familiar, even though the scope of obligations differs.
Three departures from GDPR matter most. First, the output-used-in-the-EU trigger under Article 2(1)(c) has no GDPR parallel: GDPR requires either offering goods or services to EU data subjects, or monitoring their behavior, both of which involve some direct relationship to EU persons. The AI Act’s output trigger requires neither. Second, the AI Act’s representative duty is materially heavier than GDPR’s: a GDPR Article 27 representative is a contact point without independent verification obligations, while an AI Act Article 22 representative must actively verify that conformity documentation is properly prepared. Third, prohibited practices under Article 5 have applied to non-EU entities since 2 February 2025, ahead of the broader high-risk and GPAI obligation chains, which mirrors how GDPR’s prohibitions on processing special categories of data applied from the regulation’s outset regardless of controller location.
| Dimension | GDPR Article 3 | EU AI Act Article 2 |
|---|---|---|
| Primary extraterritorial hook | Offering goods or services to EU data subjects, or monitoring their behavior | Placing AI systems on the EU market |
| Broadest trigger | Monitoring EU behavior | AI system output used in the Union |
| EU representative requirement | Contact point (Art 27) | Active verification duty (Arts 22, 54) |
| Representative for foundational technology | No direct parallel | Article 54, specific to GPAI model providers |
| Earliest enforcement against non-EU entities | May 2018, full application | 2 February 2025, prohibited practices |
The Timeline: What Is Already in Force
The Act applies in phases, and non-EU companies commonly underestimate how much is already live. Prohibited AI practices under Article 5 and the AI literacy expectation under Article 4 became enforceable 2 February 2025, with no geographic carve-out for non-EU entities. General-purpose AI model obligations under Articles 53 through 55, along with the governance and penalties framework, applied from 2 August 2025. Most remaining provisions, including high-risk AI system obligations, CE marking under Article 48, registration under Article 49, and transparency obligations under Article 50, apply from 2 August 2026. Article 6(1) reaches full effect 2 August 2027, the date by which GPAI providers who placed models on the market before August 2025 must reach full compliance.
A November 2025 AI omnibus simplification proposal has introduced some public uncertainty: certain European Commission pages currently show amended dates that diverge from the statutory implementation timeline. That proposal has not been formally enacted as of this writing. The statutory dates above remain the operative reference point, with the note that a simplification proposal is under legislative review and the timeline may shift.
The practical read for a non-EU compliance officer: a company offering a general-purpose AI model to EU customers, or operating any AI system that touches an Article 5 prohibited category, is not waiting for an August 2026 deadline. Those obligations are live now. High-risk system obligations are the ones still ahead.
Editorial content from Business Data Guide. Not legal, regulatory, or compliance advice. AI governance obligations depend on jurisdiction, sector, deployment context, and your role as provider, deployer, importer, or distributor. Engage qualified counsel before acting on any structural pattern shown here.