Does the EU AI Act Apply to the USA?

Does the EU AI Act apply to the USA? The Act is not US law, but it can apply directly to US companies that place AI systems on the EU market or produce AI outputs used in the Union. Applicability turns on a company’s role and its connection to the EU market, not on where it is headquartered. Knowing where AI is running is the first step in scoping.

Last updated: September 2026.

When Does the EU AI Act Apply to US Companies?

Extraterritorial reach means a law applies to conduct outside the enacting territory when that conduct connects back to the territory in ways the law defines. The EU AI Act does not reach a US company for being American. It reaches defined activity tied to the Union, and Regulation (EU) 2024/1689 sets out which activity qualifies (EUR-Lex, 2024).

Article 2 names the connecting factors. It covers providers that place AI systems on the Union market or put them into service in the Union, wherever the provider is established. It covers deployers established or located in the Union. It covers providers and deployers established in a third country where the output produced by the AI system is used in the Union. Importers, distributors, product manufacturers, and authorised representatives are named as well.

The output hook is the wide one for US organizations. A US company can fall within Article 2 when its AI system produces output that is used in the Union, even without a direct EU customer contract. Score an applicant in Dublin, produce a risk rating an underwriting team in Munich relies on, or generate a summary an EU-based manager acts on: each raises the output question, and each is assessed against the Article 2 wording for that specific system. Compare GDPR, which reaches non-EU controllers when they offer goods or services to people in the Union or monitor their behaviour (GDPR, 2016). The AI Act’s output hook does not use that targeting and monitoring test.

Article 2 also carves activity out. Military, defence, and national security uses sit outside the Regulation. So do AI systems and models developed and used purely for scientific research and development, personal non-professional use by individuals, and certain free and open-source components, for which the prohibitions, high-risk rules, and transparency duties do not apply. Those exclusions narrow fast once a system is used commercially.

Provider or Deployer? A Five-Step Scoping Test for US Teams

A provider develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in a professional capacity. Most US software companies are providers for the AI features they ship and deployers for the AI tools their own staff use, so the role is decided per system, not per company.

The role can shift. Under Article 25, a distributor, importer, deployer, or other third party takes on provider obligations for a high-risk system in three situations: it puts its own name or trademark on the system, it makes a substantial modification to the system, or it changes the system’s intended purpose in a way that makes it high-risk. Those three tests move the obligation, not customization in general.

  1. Inventory the AI in use. List every AI application, embedded AI feature, AI Copilot, coding assistant, agent, and model API in the environment, including the accounts and tools nobody registered. Nothing downstream works without this.
  2. Trace where the outputs land. For each system, ask who uses the result: an EU customer, an EU employee, an EU applicant, an EU-based downstream system. Output use in the Union is a scope trigger. Server location is not.
  3. Assign a role per system. Provider, deployer, importer, distributor, or general-purpose AI model provider. One organization commonly holds several roles at once.
  4. Classify the risk. Prohibited practice, high-risk use case, transparency duty, a use outside those categories, or a general-purpose AI model. Several Annex III categories matter most to US enterprises: employment and worker management, access to credit and essential services, education, biometrics, critical infrastructure, and law enforcement.
  5. Map obligations to evidence and owners. Name the person accountable for each system, the record that shows the control operates, and the retention period for logs. Evidence produced while the system runs beats evidence reconstructed at audit time.

Run the five steps against one system and you get a role, an EU connection, a risk classification, and an applicable date. Those four answers determine the obligation that follows.

Two duties catch US teams by surprise. A provider established outside the Union must appoint an authorised representative established in the Union by written mandate before making a high-risk AI system available on the EU market (Article 22), and providers of general-purpose AI models not established in the Union must designate their own authorised representative before placing a model on the market (Article 54). For Annex III high-risk systems, providers register themselves and the system in the EU database before placing it on the market or putting it into service, and deployers that are public authorities or bodies governed by public law register their use (Article 49). Registration fields, timing, and category-specific exceptions sit in the Regulation text and are checked per system.

Role Typical US example Core obligations for high-risk systems
Provider US software company shipping an AI screening feature to EU customers Risk management system, data governance, technical documentation, logging, conformity assessment and CE marking, EU database registration, post-market monitoring, authorised representative in the Union
Deployer US employer using an AI tool to evaluate EU-based staff or applicants Use per the provider’s instructions, assign trained human oversight, ensure input data is relevant, monitor operation, retain logs under its control for at least six months, inform affected workers
General-purpose AI model provider US company training or substantially modifying a model offered in the EU Technical documentation, information for downstream providers, copyright policy, public summary of training content, authorised representative, added duties for models with systemic risk
Third party turned provider US firm that rebrands, substantially modifies, or repurposes a high-risk system Assumes the provider obligation set for that system from the point the Article 25 test is met

Obligations summarized from Regulation (EU) 2024/1689, Articles 16, 22, 25, 26, 49, 53, and 54.

Risk Classification Decides Which Obligations Apply

Risk classification decides which obligations apply. Scope answers whether the Regulation touches a company. Classification answers how much work follows. The Regulation separates prohibited practices, high-risk systems, systems carrying transparency duties, uses outside those categories, and a distinct track for general-purpose AI models. A system is high-risk either because it is a safety component of a product already covered by EU product legislation, or because it falls within a listed use case in Annex III (Article 6).

Annex III lists employment and worker management, access to credit and essential private and public services, education and vocational training, biometrics, critical infrastructure, law enforcement, and migration. Credit scoring and employment ranking can fall within Annex III when their intended purposes match its listed use cases. Healthcare needs a separate assessment under Article 6, because medical device rules can bring a system into scope through the product-safety route rather than the Annex III list. Sector control mapping helps here, whether the work sits with financial services compliance teams or with healthcare and pharmaceutical governance teams.

Below high-risk, Article 50 sets transparency duties: tell people when they are interacting with an AI system, mark synthetic content in machine-readable form, and disclose deepfakes and AI-generated text published to inform the public. Uses outside the prohibited, high-risk, and specified transparency categories carry no additional obligation under the Regulation beyond the AI literacy duty, while consumer protection, employment, and data protection law still apply to the same use. General-purpose AI model providers carry documentation, downstream-information, and copyright duties, with distinct treatment for open-source models and for models designated as carrying systemic risk.

Take a US human resources software company with EU customers. Step one finds the AI in use: a candidate ranking feature it ships, an AI Copilot inside its own SaaS stack, and two coding assistants its engineers installed. Step two traces outputs: the ranking feature scores candidates for an employer in Rotterdam, so that output is used in the Union. Step three assigns roles: provider for the ranking feature it markets under its own name, deployer for the AI Copilot and the coding assistants its staff use.

Step four classifies: candidate ranking maps to an Annex III employment use case, so the provider duties for a high-risk system come into play, while internal AI Copilot use sits outside those categories unless it feeds an EU-affecting decision. Step five names owners and evidence: risk management, technical documentation, logging, conformity assessment, EU database registration, and an authorised representative for the ranking feature, plus a record of which internal AI tools touched candidate data. The same company reaches a different answer for a product analytics feature whose output is used only by US customers, which is why the test runs per system.

Deadlines and Penalty Exposure

The Regulation phased in rather than arriving at once. It entered into force on 1 August 2024. The prohibitions on unacceptable practices and the AI literacy duty applied from 2 February 2025. Obligations for general-purpose AI models applied from 2 August 2025. The bulk of the Regulation, including the Annex III high-risk regime, applied from 2 August 2026, and high-risk systems embedded in regulated products follow on 2 August 2027 (Article 113).

Penalties are tiered. Engaging in a prohibited practice can draw administrative fines of up to 35 million euro or 7 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. Most other infringements, including provider and deployer duties for high-risk systems, top out at 15 million euro or 3 percent of turnover. Supplying incorrect, incomplete, or misleading information to authorities or notified bodies reaches 7.5 million euro or 1 percent (Article 99). The turnover base named in the Regulation is worldwide rather than EU revenue, so a US company’s global figure can set the ceiling.

How the EU AI Act Compares With US State and Federal Rules

The United States has no single comprehensive AI statute. Federal oversight runs through existing authorities: unfair and deceptive practice enforcement, employment discrimination law, fair lending rules, and sector regulators applying their existing mandates to AI-assisted decisions. State legislatures have been the more active source of binding AI rules (Stanford HAI, 2026).

Colorado’s SB 24-205, as enacted in 2024, shows the direction state law has taken. Developers and deployers of high-risk AI systems must use reasonable care to protect consumers from algorithmic discrimination, and deployers must complete impact assessments, provide notice to consumers, and maintain a risk management program (Colorado General Assembly, 2024).

The structural difference matters for US teams. Federal enforcement often examines a decision after it is made, while the EU regime and some state rules call for assessment, documentation, and oversight before and during deployment. Several evidence inputs overlap across regimes. An AI inventory, named owners, interaction records, oversight evidence, and applicable logs can support EU documentation, state impact assessments, and mapping to the NIST AI Risk Management Framework (NIST, 2023). Build one evidence base, then map each record to the requirements of each jurisdiction.

Discovery Is Step Zero: Finding the AI That Creates EU Exposure

Every step above assumes the organization knows what AI is running, and that assumption is usually where the work breaks. Unapproved tools, personal accounts on business devices, AI features switched on inside existing SaaS, and locally installed agents can all send output toward an EU user without appearing in a procurement record.

Aurascape starts at that inventory problem. The platform continuously discovers AI applications, embedded AI features, AI Copilots, coding assistants, agents, and MCP servers across network, endpoint, and API planes, scoring each app for risk and capability against a continuously updated catalog of 30,000+ AI apps and agents (Aurascape, 2026). The endpoint agent finds AI running on laptops and servers, and detects an agent launch and its configuration, including MCP server connections, before the agent takes its first action.

Inventory alone does not show what moved. Aurascape decodes the AI exchange inline: prompts and responses, files and code, identity and entitlement, account type, intent and mode, connectors, and tool calls, with 600+ real-time data classifiers applied as the interaction happens (Aurascape, 2026). Policy runs inline, with actions that allow, coach, notify, redact, redirect, or block an interaction. Telling an enterprise tenant from a personal account is often what separates a system under policy from an unrecorded one.

Agent activity needs the same treatment on the execution side. Aurascape discovers and secures local AI agents and their interactions, and adds a Zero-Bypass MCP Gateway that marks every tool call it approves and blocks unmarked calls, governing the agent-to-tool execution path inline rather than observing it, where the Gateway and AI Proxy are deployed (Aurascape, 2026). Model Context Protocol (MCP) is one common tool-execution pattern, not the whole agent access-control problem. Aurascape creates interaction records for audit and effectiveness, governed by role-based access control (RBAC) for privacy, so compliance teams hold a running record of who used which AI, what data was involved, and what policy decision followed.

Scoping input Destination-based controls (SWG, CASB, DLP) Aurascape
AI apps, accounts, and agents in use Act on destinations and identities Continuous discovery against a catalog of 30,000+ AI apps and agents
Personal versus enterprise account use Identity and destination context Distinguishes enterprise tenants from personal accounts inside the interaction
Sensitive data moving into AI Act on data patterns 600+ real-time data classifiers applied inline to prompts, files, and code
Agent tool calls and MCP activity Act on destinations Zero-Bypass MCP Gateway marks approved tool calls and blocks unmarked calls
Local AI on endpoints Cover traffic that traverses the control Endpoint agent detects a local agent launch and its MCP server connections before the first action
Record available for audit Records of destination and pattern decisions Decoded interaction records covering user, app, tool, data category, and policy action

Existing web and SaaS controls act primarily on destinations, identities, and data patterns, alongside which Aurascape acts on the interaction itself. Teams building a broader control map can start from the operating model used for enterprise AI compliance frameworks, then narrow to the systems whose outputs are used in the Union.

Frequently Asked Questions

Does the EU AI Act apply to US companies?

Yes, when the company’s activity meets one of the connections in Article 2: placing an AI system on the EU market, putting it into service in the Union, acting as a deployer established or located in the Union, or producing output that is used in the Union. Corporate nationality and server location are not the test.

How does the EU AI Act’s reach compare with GDPR’s?

GDPR reaches non-EU controllers that offer goods or services to people in the Union or monitor their behaviour. The AI Act adds a separate hook keyed to where a system’s output is used, so a company can be in scope of one regime and not the other.

What makes a US company a provider rather than a deployer?

Providers put a system on the market or into service under their own name or trademark. Deployers use someone else’s system under their own authority at work, and Article 25 can move a deployer into the provider role through rebranding, substantial modification, or an intended-purpose change.

Does a US company need an authorised representative in the EU?

Providers outside the Union appoint one by written mandate before making a high-risk AI system available on the EU market, and general-purpose AI model providers outside the Union carry a parallel duty. Deployers carry oversight and logging duties instead.

Which obligations already apply in September 2026?

The prohibitions and AI literacy duty (from February 2025), general-purpose AI model obligations (from August 2025), and the Annex III high-risk regime (from 2 August 2026). High-risk systems embedded in regulated products follow on 2 August 2027.

What is the maximum fine under the EU AI Act?

Up to 35 million euro or 7 percent of total worldwide annual turnover, whichever is higher, for prohibited practices. Lower ceilings apply to other infringements and to misleading information supplied to authorities.

Does internal use of a public AI tool put a US company in scope?

It can, when the use satisfies an Article 2 connection, including when the system’s output is used in the Union. Which obligations follow depends on the use case, not on the tool’s brand.

What is the first practical step for a US compliance team?

Confirm what AI is running before assigning any role or classification, because unapproved tools and locally installed agents are the systems most likely to be missing from an existing inventory. Regulated teams often extend a program already in place, such as the control mapping used for banks and investment firms.


Aurascape turns EU AI Act scoping into an operational exercise instead of a survey. Continuous discovery inventories the AI apps, accounts, and agents in use, inline decoding shows what data moves through each interaction, and interaction records governed by role-based access control give compliance teams evidence for role determination, oversight, and logging work. See how discovery and inline visibility support scoping and evidence collection under the obligations now in effect.

See how Aurascape discovers and governs the AI behind your EU exposure →

Aurascape Solutions