Applicability of the EU AI Act when AI runs in the US but its output is used in the EU

Why compute location is the wrong starting point

Many teams begin with a simple question: where does the model run? If the answer is a US region, they conclude the EU AI Act does not reach the system. The Regulation is written to prevent that reasoning. It states that, to prevent circumvention and to protect natural persons located in the Union, it also applies to providers and deployers of AI systems established in a third country, to the extent the output produced by those systems is intended to be used in the Union.

Two features of that wording matter. First, the trigger is the output, such as a decision, score, piece of content or recommendation, and not the infrastructure that produced it. Second, the wording is about intended use. A US-based underwriting model whose scores feed an EU affiliate's decisions, or a customer-facing assistant that serves EU customers, is a plausible candidate for scope. A purely internal US model whose output never reaches the EU is a different case.

How far 'intended' extends, for example to incidental or unplanned EU use, is an interpretive question for counsel. What engineering can do is make the question answerable by recording who consumes each output. Without that record, the scoping decision rests on assumption.

Role and risk classification decide the obligations

Being in scope is only the first determination. The obligations that follow depend on the role the enterprise plays for each system, whether provider, deployer, importer or distributor, and on the system's risk classification. One enterprise can hold different roles for different systems. It can also hold more than one role for the same system, for instance when it builds a system and also uses it with EU affiliates.

For systems counsel classifies as high-risk, the questions to settle include whether an authorised representative is needed for a non-EU provider, and how transparency, human oversight, logging and record-keeping duties apply to your specific role. These should be answered from the operative articles of the Regulation, not from summaries, and the answers should be recorded with the date and the person who made the decision.

A useful working split is to separate the questions that need legal judgment from those that can be built and tested.

• Counsel: Whether the system is in scope, which role applies, the risk classification, and whether an authorised representative is needed.
• Compliance: Which policies express the legal determination, who approves exceptions, and what evidence the organisation will retain.
• Engineering: Where policy is enforced, how EU-facing interactions are identified, and how records are produced and stored.
• Security and data: Retention periods, data residency settings and access to the records.

Mapping obligations to runtime controls

Policy documents describe what an AI system should do. A regulator or auditor will want to see what it was allowed to do and what it did. That gap is easiest to close when policy is enforced in the execution path, so each decision is made, and recorded, at the moment of the interaction rather than reconstructed afterwards.

Four actions cover most EU-facing cases. Allow permits an interaction that meets policy. Redact removes specific data from a prompt or response before it moves on. Block stops an interaction that policy prohibits. Escalate routes an interaction to a person for approval before it proceeds, which gives human oversight a concrete, recorded form. These are design options. The Regulation does not prescribe these specific actions, and counsel should decide which determinations they implement.

There are tradeoffs. Enforcement keyed to an EU-facing indicator depends on an accurate inventory. If the indicator is too narrow, in-scope interactions go unmarked. If it is too broad, ordinary US traffic takes on review friction it does not need. Escalation also adds latency and reviewer workload, so it suits consequential actions rather than every request.

Retention and data residency should be configured independently of where compute runs. Where the records of EU-facing interactions are held, and for how long, is a separate decision from where inference occurs.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, on individual interactions and tool calls, with allow, redact, block, rate limit and escalate for human approval. That enforcement generates audit-ready evidence mapped to the EU AI Act. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Timing and what to monitor

As of November 2026, the AI Act is in force as Regulation (EU) 2024/1689, adopted on 13 June 2024. The Commission proposed targeted amendments, known as the Digital Omnibus on AI, on 19 November 2025, and the Council and Parliament reached a provisional agreement on 7 May 2026.

The proposal describes fixed deadlines for the delayed application of high-risk rules: 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for high-risk systems embedded in products. The provisional agreement also postpones the deadline for national AI regulatory sandboxes to 2 August 2027. It reduces the grace period for providers to implement transparency solutions for artificially generated content from six months to three, with a new deadline of 2 December 2026. These items concern timing and implementation. Adoption and publication should be tracked before any date is written into internal plans.

The practical consequence is that timing may move while the scoping logic stays the same. An inventory of output destinations, a documented role determination and enforced, recorded policy remain useful whichever dates apply. Assign an owner to monitor changes, and review each scoping decision when dates or Commission guidance change.