Search the EU AI Act and you will find page after page written by law firms. It is thorough, it is accurate, and it is almost unreadable if you are a founder trying to ship a product. Articles, annexes, recitals, conformity assessments. What none of it tells you is the only thing you actually want to know. What does this mean for my stack, my agents, and the way I deploy? This guide answers that, in plain language, from a builder's perspective rather than a lawyer's.

We will skip the legal theatre and get to the practical questions. Does it apply to you, are you a provider or a deployer, what does your risk tier actually require you to do in your codebase and your process, and what you should do before the deadline.

First, does it even apply to you?

Yes, probably, even though you are in the UK. The Act reaches any company whose AI system or its output touches the EU, regardless of where the company is based. If you have EU users, or your AI produces output that gets used in the EU, you are likely in scope. Being outside the EU does not get you out of it, in the same way GDPR reached UK companies after Brexit.

So for most UK AI startups with any European ambition, the right assumption is that the Act applies, and the real question is not whether, but how much.

Provider or deployer (the distinction that decides everything)

This is the single most useful thing to understand, and the law firms bury it. Your obligations depend almost entirely on which of these you are.

• You are a deployer if you use an existing AI model through an API to build your product. You call OpenAI, Anthropic, or similar, and build an application on top. Most startups are here.
• You are a provider if you build or release your own model, or substantially modify an existing one and put your name on it. The obligations here are heavier.

For the majority of startups building on foundation models through an API, you are a deployer, and that is genuinely good news, because your obligations are lighter and more practical than the headlines suggest. The bulk of the heavy compliance work sits with the model provider, not with you.

What your risk tier actually requires

The Act sorts AI systems into tiers, and your obligations follow from your tier. Here is what each means in practice rather than in legalese.

• Minimal risk. Most ordinary AI products sit here. Little or no mandatory obligation. If this is you, the Act is mostly something to be aware of, not something to rebuild around.
• Limited risk. This is where most chatbots and AI content tools sit. The main requirement is transparency. In stack terms, you need to make clear to users when they are interacting with AI and label AI generated content. That is largely a product and UX change, not a deep engineering project.
• High risk. This is the demanding tier, and it applies to systems used in areas like recruitment, credit scoring, biometrics, and essential services. If your AI makes or materially supports decisions about people in those areas, you are likely here, and the obligations are substantial.
• Unacceptable risk. A small set of banned practices, such as social scoring. If you are doing one of these, you stop. These have been prohibited since February 2025.

The honest reality for most startups is that you are in limited risk, where the practical demand is transparency, or minimal risk, where there is little to do. The trap is assuming you are minimal when your product actually scores or ranks people, which can push you into high risk without you realising.

What high risk means for your build, in concrete terms

If you genuinely fall into high risk, this is where the law firm documents become a wall of articles. Translated into what it means for your stack and your process, the obligations look like this.

• Logging. Your system has to automatically log its events, and if you are a deployer of a high risk system you need to keep those logs for at least six months. In engineering terms, build proper event logging and retention in from the start.
• Human oversight. A person has to be able to understand, monitor, and if necessary override the AI's decisions. This means designing your product so a human is genuinely in the loop, not a rubber stamp.
• Transparency to the people affected. If your AI affects someone, they need to be informed appropriately. That is a product and communication requirement as much as a technical one.
• Data governance. You need to manage the quality and handling of the data your system uses, which ties directly into how you build your data pipeline.
• Technical documentation and, for providers, conformity assessment, CE marking, and registration in an EU database. These are heavier, mostly provider side obligations, but a deployer needs to ensure the provider has done their part.

The key insight for a builder is that most of these are things you design in, not paperwork you bolt on. Logging, oversight, and data governance are architecture decisions, and they are far cheaper to build early than to retrofit.

The dates that actually matter

You do not need the full eight date timeline. You need a few anchors. The banned practices have applied since February 2025. The rules for general purpose AI models, which mostly affect the big providers, applied from August 2025. The big one for most companies, the high risk obligations, applies from 2 August 2026.

There is one moving part worth knowing. A proposed package of amendments, sometimes called the Digital Omnibus, may push some high risk deadlines back to late 2027. As of now the August 2026 date stands, and the sensible move is to plan for it rather than gamble on a delay that may not arrive.

If you build on open source models

A quick note because it catches people out. Free and open source general purpose models get some exemptions from the documentation and transparency obligations. But that exemption is not total. You still have to respect copyright rules and, where relevant, publish a summary of training data. And if an open model is powerful enough to be classed as posing systemic risk, the full obligations apply regardless of it being open source. So open source helps, but it does not make the Act disappear.

What to actually do before the deadline

Here is the practical checklist, stripped of legal language.

• List every AI system you build or use, and work out whether it touches the EU. If it does, you are in scope.
• For each one, decide whether you are the provider or the deployer. For most startups on an API, you are the deployer.
• Classify each system into a risk tier, and be honest about anything that scores, ranks, or decides about people, because that is what pushes you into high risk.
• For limited risk, implement transparency. Tell users they are dealing with AI and label AI generated output.
• For high risk, build in logging, human oversight, and data governance now, because they are architecture, not afterthoughts.
• Document your classification and reasoning, so when a buyer or regulator asks, you have a clear answer ready.

Most startups will find that this is far more manageable than the law firm guides suggest, because most are deployers in the limited or minimal risk tiers, where the practical work is modest.

The honest takeaway

The EU AI Act is not the impenetrable monster the legal write ups make it feel like, at least not for most startups. If you strip away the jargon, it comes down to knowing whether you are in scope, whether you are a provider or a deployer, what tier you are in, and building a handful of sensible things into your product if you are high risk. The founders who get caught out are the ones who either assume it does not apply to them, or who never work out their classification until a buyer forces the question.

Do the classification early, build the practical requirements into your stack rather than bolting them on later, and the Act becomes something you can speak to confidently in front of an enterprise buyer, rather than a risk hanging over your roadmap.