The EU AI Act for UK and US Companies: What Applies to You in 2026

The short answer: yes, the EU AI Act can apply to a UK or US company. It reaches you if you place an AI system on the EU market or if your system’s output is used in the EU, wherever you are incorporated. The Digital Omnibus, in force since 27 July 2026, pushed the main high-risk deadlines to December 2027 and August 2028, but prohibitions, general-purpose AI rules and transparency duties already apply.

Position as at 22 September 2026; not legal advice. This is a practitioner’s reading of scope and of the engineering work the Act implies. The timeline has already changed once. Confirm your position with counsel, and check the dates against the European Commission’s pages before you plan around them.

Does the EU AI Act Apply to UK and US Companies?

It does whenever one of the Act’s triggers is met, and the triggers are about the market and the output, not your registered office. Article 2(1) of the Regulation, as published on the Commission’s AI Act Service Desk, covers providers placing AI systems or general-purpose AI models on the market in the Union, importers and distributors, and, critically for anyone outside the EU, “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”.

The Commission’s own Navigating the AI Act FAQ (updated 7 August 2026) puts it plainly: the Act applies to public and private actors inside and outside the EU who place an AI system or general-purpose AI model on the EU market, or put an AI system into service or use it in the EU.

So a London SaaS company with customers in Germany is in scope, and so is a US HR-tech vendor whose screening tool ranks applicants for a role in Dublin. Neither needs an EU office. As with GDPR, the law follows the people affected.

What Did the Digital Omnibus Change?

The Commission proposed the Digital Omnibus on 19 November 2025, partly because harmonised standards and national authorities were not going to be ready for the original high-risk date. It is no longer a proposal. It was adopted and published in the Official Journal as Regulation (EU) 2026/1744 on 24 July 2026, and the Cloud Security Alliance’s research note observes that it entered into force three days later rather than after the usual twenty, because the old deadline was days away.

The Commission’s announcement, AI Omnibus enters into force (27 July 2026), sets out what changed:

• High-risk dates moved. Annex III rules now apply from 2 December 2027 and Annex I rules from 2 August 2028.
• A new prohibition. AI systems that generate non-consensual sexually explicit or intimate content, or child sexual abuse material, are banned.
• Lighter touches elsewhere. A simplified AI literacy duty, some SME measures extended to small mid-cap companies, permission to process special category data to detect and correct bias, and more AI Office oversight of systems built on general-purpose models.

What did not change matters more for most readers. According to Freshfields’ analysis of the final text (10 July 2026), the Article 50 transparency requirements still apply from 2 August 2026, with only machine-readable marking of AI-generated content getting a grace period to 2 December 2026 for systems already on the market. The high-risk delay is a deferral, not a repeal. Some of the top-ranking UK guides I checked this week still show 2 August 2026 as the high-risk date; that date is gone.

What Applies When?

The timeline as it stands on 22 September 2026, drawn from the Commission’s AI Act policy page (updated 3 August 2026) and FAQ, with the marking and prohibition grace dates from the Freshfields and CSA briefings above.

Two readings of this table. The generous one: if you are high-risk under Annex III, you have sixteen months more than the original text gave you. The accurate one: if you ship a chatbot or generate content that reaches EU users, you are already inside an applicable obligation today.

Are You a Provider, a Deployer or Neither?

Everything turns on role. The Commission’s FAQ gives the clean version: a provider develops an AI system or model and places it on the market (its example is the developer of a CV-screening tool); a deployer uses a system someone else developed (a bank using that tool). The complication is Article 25: a deployer, distributor or importer becomes the provider of a high-risk system if it puts its own name or trademark on it, substantially modifies it, or changes the intended purpose of any AI system, including a general-purpose one, so that it becomes high-risk.

Work through the table in two steps: first your role, then your risk tier.

Step 1: What is your role?

Step 2: What is your risk tier?

The Commission’s policy page notes that the vast majority of AI systems in the EU fall into the minimal tier. Most UK and US software companies I speak to land in one of two cells: a provider of a transparency-tier system built on someone else’s model, or a provider whose product drifts towards high-risk because a customer has started using it for hiring, credit or access decisions. The second case is the one to watch, because it can happen without a single line of your code changing.

Which Obligations Actually Bite for a Software Company?

Read the high-risk chapter as an engineer and most of it is not paperwork. It is a specification for how the system must be built. Four articles do most of the work, all viewable on the AI Act Service Desk:

• Logging (Article 12). High-risk systems “shall technically allow for the automatic recording of events (logs) over the lifetime of the system”. On the other side, Article 26 requires deployers to keep the logs under their control for at least six months. If your customers are deployers, they will ask you how.
• Human oversight (Article 14). The person overseeing the system must be able to understand its limits, stay alert to automation bias, “disregard, override or reverse the output”, and stop it safely. That is a user interface and a permission model, not a policy.
• Data governance (Article 10). Training, validation and test data must be relevant, sufficiently representative and, as far as possible, free of errors and complete, with bias examined and mitigated.
• Technical documentation (Article 11). Drawn up before the system is placed on the market and kept up to date, with a simplified form for SMEs.

Add Article 50 for anything that talks to people or generates content, and you have the list. Every item is cheap to design in and expensive to bolt on. A request ID propagated from the first commit costs nothing; reconstructing which model version, prompt and retrieved documents produced a decision eighteen months ago, from logs that were never designed for it, is often impossible.

I have seen the retrofit cost first-hand. On a pharmaceutical AI platform I hardened for enterprise pilot, the starting position was no audit trail and no AI traceability at all. Adding them took a dedicated two-week milestone of a seven-week engagement: an audit logger covering more than twelve critical actions including every AI query, request IDs carried across services, a trace record per model call holding the tenant, user, request ID, latency and token counts, and 365-day append-only retention. The engagement closed with 24 of 24 acceptance criteria passed. None of it was intellectually hard. All of it would have been close to free if the platform had been built that way from the start.

How Do Evaluation Sets and Audit Trails Fit In?

They are how you prove the obligations are met, rather than assert it. Documentation says what a system is supposed to do; an evaluation set shows what it does. The accuracy claims in your technical documentation are only as credible as the frozen, versioned test set behind them. How to build one that holds up is covered in building an LLM evaluation set.

Audit trails do the same for operation. After an incident the question is not whether you had a logging policy; it is what the system saw, what it produced and who acted on it. Pharmaceutical validation asks the same questions under a different law, which is why the approach in validating LLM systems for 21 CFR Part 11 transfers almost unchanged to an AI Act technical file.

Human oversight is the one teams most often get wrong, treating it as a reviewer somewhere in the loop. On the Compliance AI Processor I built for regulated document review, oversight was a design feature: every flag carried the exact source citation, a confidence score and a human override. That is roughly what Article 14 asks for, expressed as a product. Guardrails work the same way: the pharma platform’s input and output guardrails were switchable between blocking and logging, each backed by test cases. The patterns are in prompt injection defence for RAG.

Finally, data governance has an awkward corner that the AI Act and GDPR share: personal data that has been embedded is still personal data. If you cannot delete a person from your vector store and caches, your data governance story has a hole in it, as covered in right to erasure in vector databases.

What Is the UK’s Own Position on AI Regulation?

There is still no UK equivalent of the AI Act. Osborne Clarke’s May 2026 regulatory outlook reports that the King’s Speech contained no plans for further regulation of AI, while a Regulating for Growth Bill will put regulatory sandboxes on a statutory footing. The UK approach remains principles-based, with existing regulators applying existing law.

The regulator that matters most for AI systems is the ICO. Its guidance on the Data (Use and Access) Act 2025 confirms that all of the Act’s data protection provisions were in force by 19 June 2026, and that the Act opens the full range of lawful bases for significant automated decisions, so long as appropriate safeguards are applied. The ICO’s guidance on AI and data protection is under review as a result, and its consultation on automated decision-making guidance closed on 29 May 2026.

So a UK company faces a lighter domestic regime and a heavier EU one for the same product. Build to the EU standard once: the logs, oversight and documentation it requires also answer the ICO’s safeguards questions. How I work with UK teams on that is set out on the UK consulting page.

What Should US Companies Watch at Home?

The EU scope works identically for US companies. At home, the most-cited state law has just been rewritten. According to Norton Rose Fulbright, Colorado repealed and replaced its original AI Act (SB 24-205) with SB 26-189, signed on 14 May 2026 and effective 1 January 2027. The new law regulates “automated decision-making technology”, requires deployers to disclose its use, explain adverse outcomes and offer meaningful human review on request, and requires developers to give deployers documentation on intended uses, limitations and human review.

Notice the overlap. Documentation passed down the supply chain, explanation and human review are the same capabilities the EU asks for. Build them once and they serve both regimes; how I work with US teams on that is set out on the US consulting page.

What Should You Do in the Next 90 Days?

1. Inventory every AI feature and where its output lands. Include features built on third-party models and anything customers can point at people decisions.
2. Assign a role and tier to each, using the two tables above, and write the reasoning down. A documented “out of scope because” is itself an asset.
3. Close the Article 50 gap now. It already applies. Check chatbot disclosure and plan machine-readable marking before 2 December 2026.
4. Get your model vendor’s downstream documentation. GPAI providers must supply it. File it; your technical documentation will depend on it.
5. Design logging and oversight in, before the next major release. Request IDs, per-call traces, retention and an override path in the interface.
6. Freeze an evaluation set with a pre-agreed pass threshold, and rerun it on every model or prompt change.
7. Check your contracts for who is provider and who is deployer, and what happens if a customer repurposes your system.

If you need to decide who should help, I have compared the kinds of firm that sell this work in AI consultants for regulated industries. If you want an independent technical view of whether a system you have built would stand up to these obligations, AI assurance is the engagement I run for that question.

Frequently Asked Questions

The Deadline Moved; the Architecture Did Not

The Omnibus gave high-risk providers more time, and some teams will read that as permission to wait. The better reading is that the extra time is the window in which logging, oversight and evaluation are still cheap to add. Every release shipped without them makes the eventual retrofit larger.

If you sell AI into the EU from the UK or US and want to know which obligations apply to your product and what they mean for its architecture, you can book a consultation to work through it.