The EU AI Act reaches your non-EU software team, and the delay doesn't save you
Headquarters outside the EU does not put you outside the EU AI Act. Under Article 2(1)(c) of Regulation (EU) 2024/1689, the Act reaches your team the moment your AI system's output is used in the Union. The widely reported 2027 delay postpones only the heavy high-risk track. The duties that need engineering, GPAI, Article 50 transparency and machine-readable marking, and logging, are live or due in August 2026.
tsukumo
It is a Tuesday standup in Zurich. A four-person team is about to ship an AI feature: a summariser that turns a customer's support inbox into a daily digest. The lead pulls up the compliance question someone raised in the channel, reads two lines from a newsletter, and closes it in nine seconds. Standup moves on. The feature ships Thursday. Half the customers using it are in Germany and France.
"We're not in the EU, and high-risk got pushed to 2027 anyway."
Both halves of that sentence are wrong in a way that costs engineering time later instead of now. Being headquartered outside the EU does not put you outside the Act. And the delay everyone is quoting moves a track this team was never on, while leaving the duties that actually require code exactly where they were.
Short version: the EU AI Act applies to non-EU software teams whenever the output of their AI system is used in the European Union, under Article 2(1)(c) of Regulation (EU) 2024/1689. Headquarters location does not decide reach; where the output lands does. The widely reported 2027 delay is a provisional political agreement that postpones only the heavy high-risk conformity track. The duties that require engineering, GPAI obligations, Article 50 transparency and machine-readable labeling, and logging, are live or due in August 2026. So for a non-EU team, the Act is already an architecture problem, not a legal one to revisit next year.
Does the EU AI Act even reach a company based outside the EU?#
Yes, and the trigger is your output, not your address. Regulation (EU) 2024/1689 borrows the same extraterritorial logic the GDPR made familiar: it follows the data and the effect, not the company's flag. Article 2(1)(c) extends the Act to providers and deployers established in a third country where the output produced by the AI system is used in the Union. Your incorporation in Zug, Austin, or Bangalore is not the question the statute asks.
Here is the scope text itself, because the exact wording is what decides whether your Thursday release is in or out.
European Parliament and Council · EUR-Lex / artificialintelligenceact.eu · 2024
“This Regulation applies to: (a) 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; (b) deployers of AI systems that have their place of establishment or are located within the Union; (c) 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;”
Read (a) and (c) together and the architecture of the jurisdiction becomes obvious. Paragraph (a) catches you if you place a system on the EU market. Paragraph (c) catches you even if you never market in the EU at all, as long as the output of your system is used there. The Zurich team is squarely in (c): they sell to a customer, that customer's users sit in Munich, the digest renders on a screen in Munich. The output is used in the Union.
Now the honest part, because this is where careful teams and careless ones diverge. The Act does not define what "used in the Union" means. There is no recital that draws the line at the end user, the deployer's seat, the server region, or the place a human reads the result. So the conclusion that a Swiss or other non-EU team is in scope the moment its output lands on an EU screen is legal inference from the text of Article 2(1)(c), not a quoted ruling. It is the reading the major firms advising on the Act have converged on (William Fry, DLA Piper, and Cooley among them), and it is the reading the statute's output-based structure most naturally supports. We are telling you the direction of the law, not pretending a court has nailed the edge case. Plan for the broad reading, because the narrow one is the bet you cannot afford to lose.
Doesn't the 2027 delay mean I have nothing to do until then?#
No, because the delay moves a different track than the one most software teams are on. The relief everyone is sharing comes from the Digital Omnibus, which pushes the application dates for high-risk systems back: Annex III high-risk obligations to 2 December 2027, and Annex I high-risk to 2 August 2028. That is real, and for a team building, say, AI for medical devices or recruitment scoring, it matters a great deal. But it postpones the product-conformity track: the heavy regime of risk management systems, conformity assessments, and CE-style documentation for systems classed high-risk.
It does not touch the obligations that bite a general AI feature. GPAI model duties became applicable on 2 August 2025. Article 50 transparency and the bulk of enforcement arrive around August 2026. Logging and record-keeping ride alongside. None of those moved.
And before you bank even the part that did move, read the status line carefully.
So the comfortable reading, "delayed to 2027, nothing to do," fails twice. The thing that was delayed is provisional. And the things that were not delayed are the things that need engineers.
What the delay moves, and what it leaves exactly where it was
Postponed by the Digital Omnibus
Untouched, live or due Aug 2026
The obligation
Annex III high-risk to 2 Dec 2027; Annex I high-risk to 2 Aug 2028
GPAI model duties; Article 50 transparency; machine-readable output marking; logging and record-keeping
Who it hits
Teams building systems classed high-risk under Annex I/III
Almost any team shipping a user-facing AI feature with EU output
Legal status today
Provisional political agreement, pending OJ publication
In force or applying on the original timeline
What it asks of you
A conformity and documentation regime, later
Engineering work, now
What's already live right now, and what lands in August 2026?#
The Act has been phasing in since 2024, and the engineering-relevant clauses are the next to bite. This is not a single switch that flips in 2027. It is a staircase, and a non-EU team is already standing on it. The dates that matter:
1 August 2024: Regulation (EU) 2024/1689 entered into force.
2 February 2025: the bans on prohibited practices took effect, and the AI-literacy duty (Article 4) began to apply.
2 August 2025: obligations for general-purpose AI models became applicable. This is live now. If you build on or distribute a GPAI model, the duties already attach.
Around 2 August 2026: Article 50 transparency obligations and the main enforcement and penalty machinery apply.
That last date is the one the Zurich team should have circled. It is roughly six weeks out from their Thursday release, and it covers the exact feature they are shipping: an AI system producing output that EU users read.
The Act is a staircase, not a 2027 switch. The duties that need code arrive first; the postponed high-risk track branches off to the right.
The point of laying the dates out is not to alarm. It is to show that the structure of the rollout puts the cheap-to-build, expensive-to-retrofit duties early and the heavy product regime late. The Digital Omnibus widened that gap, it did not close it.
What are the four things engineers actually have to build?#
Four concrete capabilities, and each one is a deterministic layer, not a model prompt. This is the payoff, the part the standup skipped. Strip away the legal vocabulary and the Act asks your system to do four things it probably does not do today:
In-scope determination. Instrument where the output is consumed, not just where it is generated. You cannot honour or rebut Article 2(1)(c) if your system has no idea whether the digest landed in Munich or Montréal. This is a data-flow question: tag the destination, the tenant, the user region, at the point output leaves the system.
Article 50(1) interaction transparency. Where a user interacts with an AI system, they must be told. The statute requires that persons be "informed that they are interacting with an AI system, unless this is obvious." That is a UI and routing concern, enforced server-side, not a sentence you add to a system prompt and hope the model repeats.
Article 50(2) machine-readable output marking. AI-generated or manipulated content has to be marked so a machine can detect it. This is provenance metadata, watermarking, or signed output, applied at the generation boundary, on every relevant response, deterministically.
Logging and record-keeping. You need an audit trail: what the system did, when, for whom, with what inputs and outputs, durable enough to answer a regulator. That is an append-only logging layer below the model, not something you reconstruct from a chat history after the fact.
Here is the transparency text these duties trace to, verbatim, so the engineering requirement is unambiguous.
European Parliament and Council · EUR-Lex / artificialintelligenceact.eu · 2024
“Article 50(1): persons must be "informed that they are interacting with an AI system, unless this is obvious". Article 50(2): outputs "are marked in a machine-readable format and detectable as artificially generated or manipulated."”
Notice what every one of the four shares: it sits around the model, in code you control, behaving the same way on every request. None of them is satisfied by a cleverer prompt or a bigger model. This is the same lesson we keep relearning in our own builds, that the durable behaviour belongs in deterministic state machines, not in the LLM, and that observability has to be designed in. We wrote up the per-action logging pattern in AI agent observability, which came directly out of dogfooding our own agent, yoru.
How is this an architecture problem, not a legal one?#
Because none of the four duties can live in a policy PDF or a model instruction; they have to be built into the layer beneath the model. A lawyer can tell you Article 50 applies. A lawyer cannot make your system mark its output in a machine-readable format on every response. That is a build.
Think about where each duty has to physically execute. Interaction transparency that depends on the model choosing to disclose will fail the first time the model is jailbroken, or simply has a bad day. So it cannot be a prompt; it has to be a fail-closed layer in the response path that emits the notice regardless of what the model said. Output marking that the model is asked to add will be missing exactly when it matters. So it has to be applied at the generation boundary, in deterministic code, on the way out. In-scope determination that nobody instrumented is a shrug in front of a regulator. So it has to be real telemetry on where output is consumed, with tenant isolation so one customer's EU exposure is not smeared across the whole system. Audit logging that you hope to reconstruct later is not an audit trail. So it has to be append-only, written as the action happens, from audited tool calls rather than after-the-fact summaries.
The duties move from the model, where behaviour is probabilistic and unprovable, down to the tool and inference layer, where behaviour is deterministic and auditable. That relocation is the compliance work.
We have made this argument before in a different jurisdiction, and the shape is identical. In writing about confidential client data and the ChatGPT boundary, the load-bearing line was that control, not geography, decides reach. A Swiss firm's secret does not stay safe because the data is hosted in Switzerland; it stays safe because of the architecture around it. The EU AI Act is the mirror image of the same principle. Your team is not out of scope because your office is in Zurich. The output's reach, and your ability to prove how the system behaved, is decided by what you built, not where you sit. This is what we mean when we call compliance an architecture constraint: the regulation lands as a set of invariants your system has to hold, and invariants live in code.
The fine scales to your worldwide turnover, which is the phrase that should end the "we're not in the EU" conversation. Article 99 does not cap the penalty at EU revenue, EU headcount, or anything tied to your physical presence in the Union. It ties the ceiling to your total global business.
European Parliament and Council · EUR-Lex / artificialintelligenceact.eu · 2024
“Prohibited breaches: "up to 35 000 000 EUR or ... up to 7 % of its total worldwide annual turnover ... whichever is higher". Other obligations: "up to 15 000 000 EUR or ... up to 3 % of ... total worldwide annual turnover ... whichever is higher".”
Sit with whichever is higher for a second. For a prohibited-practice breach, the regulator takes the larger of EUR 35,000,000 and 7% of your global turnover. For the transparency and logging duties this article is about, the larger of EUR 15,000,000 and 3%. A non-EU base does not shrink that denominator. "Total worldwide annual turnover" is doing all the work here: it is the drafting choice that makes a non-EU address irrelevant to the size of the exposure. You can be a company that earns most of its money outside the EU and still have your fine computed on every franc, dollar, and rupee you booked. The headquarters that felt like a shelter on Tuesday is not in the formula.
To be clear about proportion: enforcement starts around August 2026, regulators ramp rather than carpet-bomb, and the 7% tier is reserved for prohibited practices, not for a missing AI-disclosure banner. We are not telling you the fax-machine fine arrives Friday. We are telling you the ceiling is indexed to your whole business, so the rational engineering response is to build the cheap controls now rather than litigate the denominator later.
We build the in-scope instrumentation, the Article 50 transparency and marking, and the logging perimeter as architecture, before the agent code ships, not bolted on after a regulator asks. That ordering is the whole point. Retrofitting machine-readable output marking and append-only audit logging into a system that was never designed for them is expensive and brittle. Designing them in as deterministic layers from the start is cheap and provable.
This is not a slide we drew for the occasion. It is how we build our own software. Our agent yoru logs every action it takes, per-action, as the action happens, which is exactly the record-keeping pattern Article 50 and the logging duties want: not a transcript you scrape later, but an audit trail written at the boundary. That dogfood is the proof that the pattern works, because we run on it. We have also pushed token-efficient routing far enough in trovex that it returns one canonical answer instead of dumping context, cutting roughly 60% of the tokens a naive approach would burn, which is the same discipline of putting the determinism in the layer below the model rather than asking the model to behave.
If you are a non-EU team shipping AI into the Union, the move is to instrument the perimeter before August 2026, not to wait for 2027 to arrive and discover it was never your deadline. You can see what we have built on our proof page.
We map where your AI output actually lands today, then put the boundary into the system: in-scope instrumentation, fail-closed Article 50 transparency and machine-readable marking, and append-only logging that answers a regulator. Architecture, not a policy PDF.
Have us build your EU AI Act perimeter before August 2026
One honest caveat, because this is fast-moving law. The dates and the delay above were accurate as of 26 June 2026, and two points are moving rather than settled: the Digital Omnibus delay is a provisional political agreement pending OJ publication, and the in-scope reading of Article 2(1)(c) for non-EU teams is inference from a statute that does not define "used in the Union." Verify the current state before you bet a release on it. We push the boundary into architecture precisely because architecture holds still while political agreements and edge-case readings do not.
Common questions
Does the EU AI Act apply to companies outside the EU?
Yes, under Article 2(1)(c) of Regulation (EU) 2024/1689 it binds providers and deployers in a third country where the output of their AI system is used in the Union. Headquarters location does not exempt you. The Act does not define "used in the Union," so this rests on the statute's output-based logic.
Is the EU AI Act delayed to 2027?
Only partly, and only provisionally. As of 26 June 2026 the Digital Omnibus is a political agreement, not yet law, pending publication in the Official Journal expected before 2 August 2026. It postpones the high-risk conformity track to December 2027 and August 2028, not GPAI duties, Article 50 transparency, or logging.
What does the EU AI Act require engineers to build?
Four things: instrumentation to determine whether output is used in the Union; Article 50(1) notice that users are interacting with an AI; Article 50(2) machine-readable marking of AI-generated output; and logging and record-keeping for an audit trail. These are deterministic layers around the model, not model prompts.
What are the penalties under the EU AI Act?
Article 99 of Regulation (EU) 2024/1689 sets fines up to EUR 35,000,000 or 7% of total worldwide annual turnover, whichever is higher, for prohibited-practice breaches, and up to EUR 15,000,000 or 3% for other obligations. The fine scales to global turnover, so a non-EU base is no shelter.
