The AI Act Starts Enforcing: For Taiwanese Models, SaaS and Content Platforms Entering the EU, Who Is Provider, Who Is Deployer?

Article 2 of the AI Act brings several scenarios into scope. A provider established in the EU or in a third country can be covered as soon as it places an AI system or GPAI model on the EU market; a deployer located in the EU is likewise in scope. Even where the provider or deployer is located in a third country, the Act can apply if the output produced by its AI system is used in the EU. ^[3][4]

This makes "our servers are in Taiwan" an insufficient answer. Suppose a Taiwanese SaaS company charges a German enterprise directly and lets its European HR department use AI to screen résumés — there is a clear EU market and use nexus. Even if the contract is signed by the Taiwanese parent company and inference runs in an Asian data center, the output is still being used by an EU company in a personnel process.

Another scenario: a Taiwanese company contracts only with a US headquarters, but the system's output is used by the French subsidiary of a multinational group. Reasonable inference — medium-to-high confidence: if the supplier knows, or the design anticipates, that the output will be used in the EU, it cannot exclude the AI Act simply on the basis of the billing address. That said, whether the Act actually applies still depends on how the product is supplied, its intended purpose, the contract, and actual control.

Nor does the scope extend without limit. Article 2 carries its own conditions and exceptions for purely personal non-professional activity, national security and military use, certain research activities, and open-source components, and how these apply has to be judged against the text itself. ^[4] "Output used in the EU" is not a general EU claim of jurisdiction over every AI system on earth — it requires the product chain to actually have an EU market or use nexus.

Taiwanese teams are used to calling the model developer the "provider" and the paying customer the "user." The AI Act's roles are more granular. The key markers of an AI system provider typically include: developing, or having developed, an AI system, and placing it on the market or putting it into service under one's own name or trademark. That means a SaaS company that calls a third party's model API can still be the provider of its own system, because what the end customer buys is the functionality that company defined, integrated, and labeled.

For example: a Taiwanese customer-service SaaS company uses a US model, adds its own knowledge-base retrieval, prompt management, sensitive-word filtering and support interface, and sells the result under its own brand to an EU retailer. The underlying model company may be the GPAI model provider; the Taiwanese SaaS company may be the provider of the overall customer-service AI system; and the EU retailer, which puts the system into operational use, may be the deployer. These are not mutually exclusive answers — they are roles at different layers.

Roles can also shift. An EU agent that merely resells the product under the original brand may sit closer to an importer or distributor; but if it rebrands a high-risk system under its own trademark, makes a substantial modification, or turns an originally non-high-risk use into a high-risk one, it may become a provider under Article 25. ^[3] A contract clause stating "this company is merely a distributor" cannot override what actually happens.

Companies therefore cannot get by with a single company-level questionnaire. For every product, they should at minimum record: the external brand, who develops and controls it, the underlying model, fine-tuning and prompts, intended use, prohibited use, customer regions, agent structure, version differences, and who has the authority to change functionality. Judging the role requires these facts.

A deployer is a natural or legal person using an AI system under its authority, though purely personal, non-professional activity is generally excluded from this concept. ^[3] An EU company using a Taiwanese SaaS product to handle recruitment, credit, education, or workforce management may be a deployer; and a Taiwanese company using a third party's AI in its own operations may also face extraterritorial application if the relevant output is used in the EU.

A deployer's responsibility is not limited to pressing a button. Depending on risk level and use, it may need to operate the system according to the instructions for use, monitor inputs and outputs, keep records, arrange human oversight, inform affected persons, or complete a fundamental-rights impact assessment. The specific obligations cannot be generalized before a product's classification has been determined.

Content platforms in particular are prone to holding several identities at once. A platform that develops its own AI recommendation, labeling, or generative tools and offers them to users may be a provider; using a third party's model for internal content moderation may make it a deployer; and hosting user-uploaded content brings other digital-services rules into play as well. Writing the whole platform down as simply "a deployer" would miss the provider obligations attached to its outward-facing features.

A general-purpose AI (GPAI) model can be integrated into a huge number of downstream systems. The AI Act imposes on GPAI providers obligations such as model documentation, providing information to downstream parties, a copyright policy, and a summary of training content; models presenting systemic risk carry additional obligations around evaluation, adversarial testing, incident reporting, and cybersecurity. ^[2][8] These obligations are distinct from the risk classification of some downstream customer-service or analytics system.

The European Commission has explained that GPAI obligations apply to relevant new models from 2 August 2025, with a phased adjustment period for existing models, and that the AI Office can begin enforcement from 2 August 2026. ^[8] Companies need to check when a model was first placed on the market and its version history — a single date cannot cover every case.

The GPAI Code of Practice is a voluntary tool meant to help operators demonstrate how they comply with their statutory obligations. ^[2] Voluntary does not mean unimportant — adoption may reduce friction in demonstrating compliance — but it is not the law itself: failing to sign the Code does not automatically mean non-compliance, and signing it does not guarantee that any given product is fully compliant either way. Companies still have to check their own facts against the formal regulation.

For Taiwanese model companies, the most important task is to maintain a documentation interface between the model and downstream systems. They need to be able to explain capabilities, limitations, testing, training-data policy, and safety measures to integrators, and to obtain necessary use-context and incident feedback from downstream parties in return. When both sides of a supply chain push responsibility onto the other, the usual result is that something goes wrong at the end output with no complete evidence trail to be found.

The rule with the most direct impact on SaaS companies and content platforms in 2026 is the Article 50 transparency obligation. ^[5] It covers at least several distinct situations. First, for AI systems designed to interact directly with natural persons, the provider must in principle ensure that people know they are interacting with AI, unless this is already obvious from the context.

Second, for systems that generate synthetic audio, image, video, or text content, the provider must ensure the output is marked in a machine-readable format and detectable as artificially generated or manipulated, subject to conditions such as technical feasibility. ^[5] This is closer to a system-level technical capability than a single disclaimer line printed on screen.

Third, deployers using systems for emotion recognition or biometric categorization must inform the natural persons exposed to them. Fourth, deployers publishing a deepfake must in principle disclose that the content has been artificially generated or manipulated; artistic, creative and satirical works are subject to a more limited form of disclosure. Fifth, deployers publishing AI-generated or AI-manipulated text used to inform the public on matters of public interest also carry a disclosure obligation — but where the content has undergone human review or editorial control, and a natural or legal person holds editorial responsibility for it, the text provides for an exception. ^[5][6]

These obligations attach to different parties. The underlying model company may need to supply markable capability; the SaaS provider needs to integrate that capability into the system; the content platform or media outlet, as deployer, may need to ensure disclosure to people at the point of publication. If a contract simply states that "the supplier warrants AI Act compliance" without specifying how marking information is to be preserved along the API, through file conversion, and into the publishing pipeline, transparency will quietly disappear somewhere in the supply chain.

The Commission's 2026 guidelines further explain the enforcement of Article 50, and note that for systems within the scope of Article 50(2) already placed on the market before 2 August 2026, providers have an adjustment period running to 2 December 2026. ^[6] So existing generative features cannot all be treated as instantly non-compliant from the stroke of midnight on 2 August, nor can the year-end deadline be ignored.

Taiwan's software and hardware industries are skilled at OEM, ODM, and white-label partnerships. A given AI feature may be developed by a Taiwanese company, named by a European brand, and then deployed by an enterprise customer. This division of labor can be structured commercially through contracts, but the legal role still turns on who places the product on the market under its own name; for high-risk systems, it also turns on who makes a substantial modification or changes the intended purpose. ^[3]

Suppose a Taiwanese company supplies a general-purpose customer-service engine, and a French brand renames it, adds an industry knowledge base, and restricts it to insurance-claims use. The Taiwanese company may still be the provider of certain components or the original system; the French brand may also take on a provider role because of its own branding and control over the use case; and the ultimate insurance company would be the deployer. It cannot be simplified to "there is only one real provider."

Another scenario: a Taiwanese hardware maker embeds a vision model into industrial equipment. If the equipment is used only for quality inspection, the risk may differ from equipment used for decisions about worker performance or safety. If an EU customer changes the use case, the role and classification may change too; the supplier needs technical restrictions, a statement of intended use, change notifications, and logs in order to demonstrate where its liability ends.

Reasonable inference — high confidence: what a white-label chain needs most is not a blanket indemnity clause but a role schedule. Every version should list who places it on the market, under what trademark, which model, who controls the system, its intended use, its prohibited uses, its transparency interface, incident-notification arrangements, and documentation hand-off. Legal roles cannot be created purely by contract, but a contract can give every party the actual capacity to fulfil its real role.

The 2026 AI Omnibus entered into force on 27 July, adjusting the timeline for some high-risk AI rules. ^[10] The Commission has explained that the timeline for the high-risk use cases listed in Annex III is pushed back to 2 December 2027, while high-risk AI systems embedded in other regulated products are pushed back to 2 August 2028.

This change is easily marketed as "the EU AI Act has been delayed." In fact it only affects specific high-risk rules and classification milestones — it does not make the transparency obligations, GPAI enforcement, prohibited practices, or governance preparation that began in 2026 disappear along with it. ^[1][10] A company that stops all its compliance work on this basis is conflating several different regulatory clocks into one.

The delay also does not mean high-risk products can wait until the final year to take stock. Determining whether a system touches recruitment, education, critical services, biometrics, or a regulated product requires product, legal, and customer teams to work through the use cases together; and building data quality, logging, risk management, human oversight, and supply-chain documentation also takes time. What the delay offers is a window for correction and implementation — not proof that no preparation is needed.

The first is the model company. If a Taiwanese team makes its own GPAI model available on the EU market via API or download, it may be a GPAI model provider; if it also launches a complete chat or analytics application, it may simultaneously be an AI system provider. The company needs to keep model documentation, downstream information, and application-layer transparency controls separate — one model card cannot cover every product.

The second is the SaaS company. Even where the underlying model comes from a third party, as long as the Taiwanese company supplies an AI system with a specific purpose under its own brand, it can still be the system's provider. The EU enterprise customer may be the deployer, and the agent may be an importer or distributor. If the SaaS product lets customers freely change the intended use, product restrictions, contracts, and monitoring are also needed to handle classification drift.

The third is the content platform. When a platform supplies generative tools, it may be a provider; when it uses AI for internal content moderation, it is a deployer; and when it publishes or helps publish a deepfake or public-interest text, it needs to check the disclosure duties under Article 50 as well. A platform needs to track where content originates, whether synthetic markings survive compression and file conversion, and who holds human editorial responsibility — not merely add an "AI-generated" button.

These three types of company can also overlap. A content SaaS company with its own model could easily hold every one of these roles at once. The difficulty of the AI Act lies precisely in this: roles are generated along the product chain, not assigned by a line in a business registration.

The first is a product-line role matrix. List, row by row, every model, AI system, and feature, its brand, who places it on the market, its EU customers, agents, end use, likely role, and facts still to be confirmed. Do not stop at company names — the enterprise edition, the API edition, and the white-label edition of the same product may reach different conclusions.

The second is an EU-nexus inventory. Compile EU revenue, users, agents, where output is used, marketing pages, and the scope of contracted services. For an API where "we don't know where the output is used" is the honest answer, design customer declarations, regional controls, or use-case information — rather than treating the unknown as nonexistent.

The third is version and control evidence. Preserve the underlying model's version history, fine-tuning, system prompts, data sources, evaluations, known limitations, human oversight, marking mechanisms, and change logs. Role and risk can change because of a substantial modification, and without a version record there is no way to reconstruct what the product actually looked like at the time.

The fourth is a liability interface. Contracts should specify who supplies technical documentation, who retains logs, who handles incidents and regulator inquiries, who maintains the marking, who informs end users, and how the roles are to be reassessed when white-labeling or use cases change. This interface cannot substitute for statutory liability, but it can stop every party from assuming someone else will handle it.

What is confirmed is that the AI Act has clear pathways for extraterritorial application; a Taiwanese company having no EU legal entity is not, by itself, enough to exclude it from regulation. 2 August 2026 is an important milestone for AI Office enforcement and certain transparency obligations, while GPAI, existing systems, and high-risk rules each follow their own phased timelines. ^[1][4][8]

Another confirmed point is that provider, deployer, GPAI model provider, importer, and distributor each correspond to different market conduct. Not training the underlying model oneself does not mean a branded SaaS product is necessarily not a system provider; nor is the enterprise customer necessarily the only deployer.

Reasonable inference — high confidence: Taiwanese companies' biggest near-term risk is substituting a company-level self-description for actual product-chain analysis. White-labeling, rebranding, and substantial modifications or use-case changes to high-risk systems will all move roles along the supply chain. Compliance work that lacks a version-by-version role matrix is prone to preparing for the wrong product, the wrong role, and the wrong date.

What remains unknown is the final classification of each individual product, regulators' enforcement priorities, the technical standards for transparency marking, and case-by-case measures. This article cannot deliver a legal conclusion for any single company; all of that requires further judgment based on the actual product, contract, and deployment.

For Taiwanese model companies, SaaS providers, and content platforms, the first deliverable of the AI Act should not be a badge that says "compliant" — it should be an honest map of the product chain: where the model comes from, who turns it into a system, who supplies it under their own brand, who decides its use, where the output is used, and who can reconstruct the record when something goes wrong. Only by first answering "who am I" at every link can a company know which set of obligations it must meet — and be ready to give a verifiable answer once the EU begins enforcing in earnest.