The EU AI Act (Regulation 2024/1689) applies extraterritorially, meaning it reaches companies based outside the EU. The trigger isn't where your company is registered or where your data centers are. It's whether EU residents use the output of your AI systems. This article explains exactly how the scope works, what it means for US and UK fintechs specifically, what the difference between provider and deployer obligations is, and how enforcement reaches non-EU companies in practice.
The short answer: extraterritorial scope catches most global companies
Article 2(1) of the Act sets out four categories of entity that are in scope:
- Providers that place AI systems on the EU market or put them into service in the EU, regardless of whether the provider is established in the EU or in a third country.
- Deployers of AI systems that are located in the EU.
- Providers and deployers of AI systems that are established in a third country when the output produced by those systems is used in the EU.
- Importers and distributors of AI systems.
The third category is the key one for non-EU companies. It applies regardless of where you're based. If your AI system produces an output (a recommendation, a decision, a generated text, a risk score) that is used by someone in the EU, you are a subject of the Act. Full stop.
How Article 2 defines who must comply
The Act defines two primary roles with different obligations:
- Provider: Any natural or legal person that develops an AI system or general-purpose AI model and places it on the market or puts it into service under their own name or trademark, whether for payment or free of charge. If you built the AI and you're deploying it, you're the provider.
- Deployer: Any natural or legal person that uses an AI system under its authority for professional purposes. If you're integrating a third-party AI API into your product and deploying it to your customers, you're a deployer with respect to that model, even if you're also a provider of your own product layer on top.
In practice, most companies are both. A fintech that uses OpenAI's API to power its customer service chatbot is a deployer of that GPAI model and a provider of its chatbot product. Each role carries distinct compliance obligations, and you need to assess each layer of your stack separately.
The "output used in the EU" trigger
The clearest test for extraterritorial scope is Article 2(1)(c): an entity is in scope if the output produced by its AI system is used in the EU. "Output" under the Act means any content, prediction, recommendation, decision, or other result generated by the AI system and acted upon by a person or another system.
This is deliberately broad. It includes:
- A credit score produced by your model and used by a EU bank to decide whether to grant a loan
- A customer service chatbot response received by an EU customer on your website
- A fraud risk flag generated by your system and used to block a transaction for an EU account holder
- A content recommendation served to an EU user of your platform
- A job application screening result used by an EU employer who licenses your HR software
If any of those scenarios describe your product, you're in scope. The location of the server, the company, or the data doesn't change this.
What this means for US and UK fintechs specifically
US and UK fintechs are among the most exposed non-EU companies for two reasons: their products tend to use AI for consequential decisions (credit, fraud, identity), and they often have EU customers either directly or through white-label arrangements with EU financial institutions.
For a US fintech:
- If you offer a credit or lending product accessible to EU residents, your underwriting model is almost certainly in scope as a high-risk Annex III system (creditworthiness assessment is explicitly listed in Annex III).
- If you provide a fraud detection API used by EU banks or payment processors, your EU customers' use of that API means your AI output is used in the EU, making you a provider in scope.
- If you have a customer-facing AI assistant, chatbot, or recommendation engine that EU users interact with, Article 50 transparency obligations apply to that product from 2 August 2026.
For a UK fintech, the position is even more direct. UK companies that were subject to EU AI rules through GDPR equivalence and existing EU market access maintain that exposure post-Brexit. The Act doesn't include a Brexit carve-out; if your product reaches EU users, you're in scope on the same terms as any other non-EU company.
What this means for SaaS companies with EU customers
B2B SaaS companies often assume they aren't in scope because they don't serve EU consumers directly. That assumption needs re-examination:
- If your SaaS product uses AI to produce outputs consumed by your EU business customers' employees or end users, those outputs are "used in the EU" and you're in scope.
- If you're a SaaS company that licenses your AI-powered HR, legal, or risk management tools to EU companies, the employees who receive AI-generated recommendations, scores, or decisions from your system are EU users of AI output. You're a provider in scope for those systems.
- If you provide AI-powered analytics dashboards to EU clients, the dashboards' AI-generated insights are outputs used in the EU.
The only genuinely out-of-scope scenario for a SaaS company is one where no AI output of any kind reaches a user in the EU, directly or via your client's deployment. For most SaaS companies serving global markets, that scenario doesn't exist.
The 2 August 2026 deadline applies to you regardless of where you're based. Better Societies specialises in helping non-EU AI and fintech companies navigate extraterritorial scope, determine their exact obligations, and get compliant before the fines apply. Start your compliance assessment.
The difference between provider and deployer obligations
Understanding whether you're primarily a provider or deployer (or both) shapes what you actually need to do:
- Provider obligations are heavier. Providers must conduct conformity assessments, build technical documentation (Annex IV for high-risk systems), register in the EU AI database, affix CE marking where applicable, establish a quality management system, and designate an EU representative if not established in the EU.
- Deployer obligations are lighter but real. Deployers must ensure AI is used as intended by the provider, implement human oversight measures, inform employees about AI use where required, report serious incidents to the provider, and conduct fundamental rights impact assessments for high-risk AI in certain contexts.
If you use a third-party AI API and integrate it into your own product that you then deploy to customers, you're a deployer of that model and a provider of your product. The provider of the underlying model owes you technical documentation and a declaration of conformity. You, as the downstream provider, must ensure your product layer meets high-risk requirements if applicable.
How enforcement reaches non-EU companies
A common assumption is that enforcement against non-EU companies is weak or theoretical. That assumption is wrong, and GDPR enforcement history demonstrates it. Several mechanisms bring non-EU companies into enforcement reach:
- EU representative requirement: Non-EU providers of AI systems available in the EU must designate an EU representative established in a member state where the system is made available. Enforcement actions can be directed at the representative, and through them at the non-EU parent. The representative is jointly and severally liable in some circumstances.
- EU subsidiaries: Non-EU companies that have EU subsidiaries can face enforcement against the EU subsidiary. The subsidiary's obligations flow from the parent's AI systems if those systems are deployed in or made available to the EU market.
- Market access bans: The most effective enforcement lever is the threat of market access withdrawal. A non-EU company that doesn't comply can have its AI systems removed from the EU market by national market surveillance authorities. That's a direct business impact that no fine needed to achieve.
- Cross-border enforcement cooperation: The Act mandates cooperation between national authorities and the European AI Office. Investigations can proceed jointly, and evidence gathered in one jurisdiction can support actions in another. This mirrors the GDPR's one-stop-shop mechanism and gives authorities real investigative power.
What "placing on the EU market" means in practice
"Placing on the EU market" is the Act's core jurisdictional concept, and it's interpreted broadly. It means making an AI system available for the first time in the EU, whether for free or for payment. Practical examples:
- Making a SaaS product accessible at a URL that EU users can reach constitutes placing it on the EU market, even if you didn't explicitly target EU users.
- Offering an API that EU-based developers or companies can subscribe to and use is placing the AI system on the EU market.
- Licensing your AI software to an EU company that then deploys it to their customers is placing it on the EU market, and the EU company is an importer with corresponding obligations.
- Publishing an open-source AI model on GitHub that EU developers can download and deploy is placing it on the EU market (with reduced obligations for open-source providers, but not zero obligations for GPAI models).
You don't need a physical presence in the EU, a registered subsidiary, or an EU customer contract to be on the EU market. If EU users can access your AI system and use its output, you're there.