The EU AI Act is not a single rule you either pass or fail. It's a sliding scale, and almost every practical question about compliance starts in the same place: which category is my system, product or platform actually in?
Get that answer wrong in one direction and you gold-plate a spam filter with documentation it never needed.
Get it wrong in the other and you ship a recruitment tool into a high-risk category without any of the controls the law demands, and, once the high-risk rules come into play in December 2027, with real fines attached.
Here's an overview of how it works, in simple terms.
A lot of UK teams have filed the EU AI Act under 'not our problem'. That's a mistake. The Act follows the market and the output, not the postcode of the team that built the system. It applies if your AI system is placed on the EU market, put into service in the EU, or - the one people often miss - if its output is used in the EU.
There's a common mix-up worth clearing up before you start. Using AI to build a product is not the same as shipping a product that contains AI - and only the second one matters here.
A rules-based calculator written with heavy AI assistance is still deterministic: same input, same output, no model in the running system. The Act has nothing to say about how it was built. What it categorises is the AI in your product - the model that predicts, ranks, scores or generates once the product is in someone's hands. If there's no such system in the product, the AI in your toolchain doesn't put you anywhere on this scale.
The Act sorts every AI system into one of four buckets, and the obligations scale with the risk.
Most of what most teams build sits in that bottom row.
The single most useful test is not 'does this use AI?' It's this: does AI make, or materially inform, a consequential decision about a person, in one of the sensitive domains? Run your system through these in order.
None of the above? Minimal or zero risk - get on with building.
Categorisation tells you how heavy the obligations are. Your role tells you whose they are.
The Act splits responsibility between the provider (whoever puts the system on the market under their own name) and the deployer (whoever uses it).
For software teams building to a client's spec, this is where liability can get misallocated - so it needs settling in the contract, not assumed.
If you build it and the client runs it under their brand, the client is usually the provider. If you productise it under your own name, that's you.
The timeline has shifted, so this is worth getting current on rather than working from last year's stale slide deck or an old blog article (including this one! Dates were correct at time of writing 01/07/2026).
Since February 2025 - the banned practices and the AI-literacy duty (i.e. train your staff) are already in force.
Since August 2025 - obligations on general-purpose AI models apply, which matters if you wire a foundation model into your system.
2 August 2026 - transparency duties start, and full enforcement powers switch on. This is the nearest hard deadline for most teams (at time of writing).
2 December 2026 - a new prohibition on AI-generated intimate imagery and CSAM, plus a tightened deadline for marking synthetic content.
2 December 2027 and 2 August 2028 - the high-risk obligations, deferred by the Digital Omnibus package. The package was politically agreed in May 2026 and given final Council approval on 29 June 2026, pending publication in the Official Journal. The deferment gives some breathing room, but the transparency and GPAI deadlines were not moved.
Many teams build on a commercial LLM API rather than training their own. This doesn't outsource your risk (but it doesn't increase it either) - wiring in a third-party model does not, on its own, change your tier. The GPAI obligations in the Act sit mainly with the model provider, not with you as the integrator. Your risk profile is still set by what your product does with the output. The same chatbot is limited risk whether it runs on your own model or someone else's. Where it does matter is the transparency duties: if your product generates or manipulates content, you carry the obligation to label it, regardless of whose model produced it.
Everything above is about categorising your product. Article 4 applies to you the moment your staff use AI, whatever tier your systems sit in. It requires 'a sufficient level of AI literacy' among the people operating AI on your behalf - in force since February 2025, enforceable from 2 August 2026.
It's easy to underestimate: it's the broadest duty in the Act (staff and contractors, including AI embedded in everyday tools, and it can't be contracted out); there's no size carve-out; and the evidence is the point - a written policy, a short induction and a log of who did what is what makes it defensible.
For regulated delivery, it's the cheapest, earliest step toward everything else the Act asks for.
For Irish teams there's a local dimension too: Ireland published its Regulation of Artificial Intelligence Bill 2026 in June, standing up the AI Office of Ireland and a network of familiar sectoral regulators - the Data Protection Commission, the Central Bank, the Competition and Consumer Protection Commission and others - rather than one remote authority. In practice, you'll answer to bodies you already know.
By contrast, the UK has taken the opposite road: no single AI Act, and none expected soon. Instead, existing regulators apply broad principles, with the real legal weight sitting in UK laws already followed - chiefly UK GDPR. In practice that means the ICO, applying UK GDPR - particularly its rules on automated decision-making and profiling, and its transparency and fairness duties - rather than a bespoke AI regulator. The exposure still exists, it just sits in data protection law rather than a dedicated Act. It's lighter-touch by design. But 'no UK AI Act' does not mean 'no rules', and the moment output reaches the EU, the EU AI Act applies regardless.
For anyone building across both markets, the pragmatic move is to design to the stricter EU standard once, rather than try to maintain two compliance positions.
Risk categorisation isn't box-ticking - it's the decision that determines how much engineering, documentation and oversight a system genuinely needs.
Most of your portfolio will likely be minimal risk. A small, identifiable part, perhaps not. The teams that will do well are the ones that can tell the two apart early, and design the controls in from the start rather than retrofitting, potentially under a tight deadline.
At Marino Software, we routinely build for public sector and regulated clients - Met Éireann, Irish Rail, NTMA and others - where getting this right isn't optional. Working out where a system sits is the kind of question we help regulated clients answer before a line of code is written. If that's where you are, let's talk.
Photo by Jen Theodore on Unsplash
Have a project in mind, or just starting to think one through? We’re good at both.
Get in touch
