What UK software teams must do now that the EU AI Act is live?

TL;DR: The EU AI Act's transparency obligations came into force on 2 August 2026. The high-risk AI system deadline for most Annex III systems was pushed to December 2027 under the AI Omnibus political agreement reached in May 2026. But several obligations are live now and affect UK businesses building for EU customers. This post walks through three specific things that should change in how software teams build, the provider versus deployer distinction that matters most for UK startups and what to ask your development partner about compliance before you sign.

The EU AI Act has extraterritorial scope. If your software serves EU customers or your AI outputs reach EU users, the regulation applies to your business regardless of where you are headquartered. That covers a substantial portion of UK SaaS products, digital platforms and agency-built client applications, and it is worth understanding which obligations apply now rather than assuming the August date was moved or superseded

The confusion is understandable. The timeline has shifted more than once. The high-risk deadline most organisations were preparing for in August 2026 was pushed back to December 2027 under the AI Omnibus political agreement reached in May 2026. That extension created a reasonable impression that the August date no longer carried weight.

It does. Three categories of obligation came into force on 2 August 2026, and none of them was affected by the Omnibus extension. The full timeline is documented on the official EU AI Act page.

What came into force on 2 August 2026

Transparency obligations under Article 50

AI systems that interact directly with people must now disclose that they are AI. This applies to chatbots, AI-generated content tools and any system where a user might reasonably believe they are interacting with a human.

Synthetic content including audio, images, video and text generated by AI must be labelled in a machine-readable format. For generative AI providers, systems placed on the market before 2 August 2026 have until 2 December 2026 to add the required digital watermarking or metadata. Systems launched after that date must comply from the start.

For most UK software teams building products with AI features, this is the most immediately relevant obligation. If your product includes an AI chat interface, an AI content generation tool or any feature that produces synthetic media, the disclosure requirement applies now.

GPAI penalty enforcement

Obligations for providers of general-purpose AI models have applied since August 2025. What changed on 2 August 2026 is that the European Commission's full enforcement powers against those providers came online. Fines of up to €15 million or 3% of global annual turnover can now be imposed for non-compliance with transparency and copyright requirements.

For most UK startups, this category is relevant only if you are building or fine-tuning your own AI model rather than using third-party APIs. If you are calling established AI APIs in your product, you are a deployer rather than a provider, and your obligations under this category are significantly lighter.

Prohibited practices enforcement infrastructure

The ban on prohibited AI practices has been in force since February 2025. What activates in August 2026 is the full enforcement infrastructure behind it, including national authority inspection powers, cross-border enforcement through the European AI Office and the penalty regime that backs it all up.

The prohibited practices most likely to affect UK software teams are social scoring systems, AI that manipulates users through subliminal techniques and real-time biometric identification in public spaces. If your product does none of these things, this category requires no immediate action beyond confirming that clearly in your documentation.

Three things that should change in how software teams build

1. Documentation and traceability for AI features

Any AI system within the scope of the Act requires documentation that can demonstrate compliance if a regulator asks. For transparency obligations, this means being able to show what the AI does, how it discloses its nature to users and how synthetic content is labelled.

For high-risk systems, when those obligations come into force in December 2027, the requirements are more extensive. Technical documentation must be drawn up before market placement and retained for ten years. Logging must be integrated into the core design of the system, not added afterwards.

The practical implication now is that building AI features without documentation makes the eventual compliance work harder and more expensive. Teams that document as they build will have a significantly easier path in 2027 than teams that treat documentation as something to address when a deadline approaches.

2. Human oversight: when it is required and what it means technically

The Act requires that high-risk AI systems be designed to allow effective human oversight. This has specific technical implications: the system must be interpretable enough for a human reviewer to understand its outputs, controllable enough for a human to intervene and designed so that oversight is a genuine capability rather than a checkbox.

For UK startups using third-party AI APIs, this question is most relevant when building systems that make or inform consequential decisions. A recommendation engine suggesting content has different oversight requirements from a system that informs credit decisions or employee performance evaluation.

The distinction matters because a team can move from deployer to provider obligations without changing their tooling. Using an AI coding assistant for code completion carries near-zero compliance exposure. Routing that same tooling into a workflow that evaluates developer performance and feeds into management decisions puts the team in a materially different category of obligation.

3. The provider versus deployer distinction

This is the most consequential distinction in the Act for UK startups and it is the least understood.

A provider is an organisation that places an AI system on the market or puts it into service. A deployer is an organisation that uses a third-party AI system under its own authority and responsibility. The obligations are materially different between the two.

Most UK startups calling third-party AI APIs are deployers. Their obligations are lighter: appropriate use of the system, human oversight where required and transparency to end users. They are not responsible for the compliance of the underlying model.

The line between deployer and provider is easier to cross than it appears. Fine-tuning a third-party model on your own proprietary data moves you toward provider obligations. Building a product that places an AI system on the EU market rather than simply using one internally does the same. Understanding which category you are in is the first compliance question worth answering, and the answer can change as the product evolves.

What to ask your development partner about AI Act compliance

If you are commissioning software that includes AI features, the compliance question does not sit entirely with you. The team building the software makes architectural decisions that determine whether compliance is achievable. These questions are worth raising before work begins:

• Does the team build AI disclosure into the user interface as a standard practice or does it require a specific brief?
• How do they handle documentation for AI features during the build rather than retrospectively?
• What is their approach to logging AI system behaviour in a way that satisfies traceability requirements?
• Have they considered the provider versus deployer distinction for your specific product, and can they explain which category applies?
• Do they have a view on how their approach to AI-generated code intersects with IP ownership under the Act?

What to listen for is whether the answers are grounded in how the team actually builds rather than in general awareness of the regulation. A partner that can describe their current process in specific terms has thought about this in practice. One that stays at the level of general regulatory awareness probably has not yet integrated it into how they work.

Frequently asked questions

Does the EU AI Act apply to UK businesses after Brexit? Yes. The Act has extraterritorial scope. If your software is used by EU customers or your AI outputs reach EU users, the regulation applies regardless of where your business is headquartered. Brexit does not exempt UK businesses from EU regulations that cover their products' reach into the EU market.

What came into force on 2 August 2026 under the EU AI Act? Three categories of obligation activated on 2 August 2026: transparency requirements under Article 50 requiring disclosure when users interact with AI and labelling of synthetic content; full GPAI penalty enforcement powers for the European Commission; and the complete enforcement infrastructure behind the prohibited practices ban that has applied since February 2025.

Was the EU AI Act high-risk deadline delayed? Yes. Under the AI Omnibus political agreement reached in May 2026, the high-risk AI system obligations for Annex III systems, including recruitment tools, credit scoring and education applications, were pushed from 2 August 2026 to 2 December 2027. This extension did not affect the transparency obligations or GPAI enforcement that came into force on 2 August 2026.

What is the difference between a provider and a deployer under the EU AI Act? A provider places an AI system on the market or puts it into service. A deployer uses a third-party AI system under their own authority. Providers carry significantly heavier obligations. Most UK startups using third-party AI APIs are deployers. Fine-tuning a model on proprietary data or building a product that places an AI system on the EU market can shift a business from deployer to provider obligations.

What should UK software teams do now to prepare for EU AI Act compliance? Three practical steps: map every AI feature in your product and identify which Article 50 transparency obligations apply now; document AI features as you build rather than retrospectively; and understand whether your product puts you in the provider or deployer category under the Act. If you are building for EU customers, that last question is worth working through with your development partner before the next feature ships.

How Aecor helps

We build software that includes AI features for UK startups, SaaS businesses and digital agencies. The compliance question comes up in almost every engagement now and we would rather address it at the architecture stage than as a retrofit.

If you are building a product with AI features and want to understand what the Act means for your specific build, a free 60-minute technical discovery call is a good starting point. It is a working session focused on your product specifically, covering which obligations apply now and what they mean in practice. You can also read more about how we approach AI Automation as part of our engineering practice.

Book your free 60-minute Technical Discovery Call