A mid-market exec team asked us this last year, almost sheepishly: “How many AI systems do we actually run?” Nobody at the table knew. Between the support chatbot, the CV-screening tool in HR, the customer risk scoring, and a handful of Microsoft 365 features switched on without anyone noticing, the real count was north of fifteen. That is where the AI Act starts. Not in a legal text. In an inventory most companies have never done.
The EU’s Artificial Intelligence Act entered into force in August 2024 and applies in stages through 2027. By 2026, this is no longer about getting ready: some obligations already bite, others land within months. This article won’t recite the regulation back to you. It tells you what to do, in what order, and what to steer well clear of.
Classify your use cases, not “AI” in general
The AI Act does not regulate the technology. It regulates the use. The same language model can be harmless in one context and high-risk in another. So everything begins with one question, asked system by system: what is it for, and who does it decide about?
Four tiers structure the text. Here is how they land on cases you will recognise.
- Unacceptable risk (banned since February 2025): social scoring, behavioural manipulation, emotion recognition in the workplace, certain forms of biometric categorisation. If one of these is lurking somewhere in your stack, it is not a compliance topic. It is an immediate shutdown.
- High risk: the heart of the regulation for most companies. CV screening and candidate shortlisting, credit scoring, decisions affecting access to a job, an essential service, or education. A CV-sorting tool is explicitly high-risk. So is credit scoring. This tier triggers the bulk of the obligations.
- Limited risk: transparency, mostly. A chatbot must disclose that it is an AI. Generated content (image, text, audio) must be identifiable as such. Cheap to do, and far too often skipped.
- Minimal risk: the silent majority. Spam filters, product suggestions, spell-checkers. No specific obligations. No need to spend three meetings on them.
The classic trap here is an HR chatbot. On the surface, it is limited risk: it just needs to announce itself as an AI. But the moment it starts shortlisting applications or steering internal mobility decisions, it tips into high risk. The line is not drawn by the model. It is drawn by what you ask the model to do.
The timeline: what already bites
Plenty of leaders still assume 2026 or 2027 “leaves time”. Wrong. Part of the text already has teeth.
- February 2025: ban on unacceptable-risk uses, plus an “AI literacy” duty — the people in your organisation who use AI must understand it well enough. This is live.
- August 2025: obligations for general-purpose AI models (the providers of large models), with EU and national governance bodies in place.
- August 2026: transparency obligations (limited risk) and much of the high-risk regime apply. This is the deadline that should frame your roadmap.
- August 2027: the final stage, for high-risk systems embedded in products already covered by sector-specific regulation.
In plain terms: if you operate a high-risk system, the date that matters is not 2027. It is summer 2026, and the documentation takes months to assemble.
What you actually need to do now
Forget the stack of PDFs from law firms. Here is the concrete sequence, in the order that makes sense.
- Inventory your AI systems. List everything: in-house apps, bought components, AI features baked into SaaS you already pay for. This is the step everyone underestimates. In practice, you always find two to three times more systems than expected.
- Classify. For each entry, assign a risk tier. Be honest about the real purpose, not the purpose printed in the vendor’s brochure.
- Build the register. A living document: who owns it, which vendor, what data goes in, what decision comes out, what risk tier. This is the backbone of the whole effort. Without it, you start from scratch at every audit.
- Risk-assess the high-risk systems. For those: bias analysis, quality and representativeness of the training data, risks to the people affected, mitigation measures.
- Write the technical documentation. How the system is designed, what it was trained on, its known limits, its performance. The useful habit is to document as you go, not in a panic when a check lands.
- Set up human oversight. Not a human clicking “OK” on autopilot. Someone who can read the output, challenge it, override it. A recruiter must be able to keep a candidate the tool rejected, and to see why the tool rejected them.
- Inform the people affected. Anyone subject to an AI-assisted decision should know. The candidate, the loan applicant, the customer. It is an obligation, and it is also a matter of trust.
GDPR and the AI Act: don’t do the work twice
Good news for anyone who took GDPR seriously: part of the road is already paved. The two texts overlap heavily. A record of processing activities and a register of AI systems run on the same logic, and a data protection impact assessment (DPIA) feeds an AI Act risk assessment as much as the other way round. Legal basis, data minimisation, informing the people involved: none of this is new vocabulary to you.
The mistake would be to stand up two parallel machines, two registers, two committees, two sets of documents that drift apart within six months. Anchor AI governance to what your DPO already does. Extend it. Don’t duplicate it.
The two traps, and who should own this
There are two ways to get this wrong. Opposite ends, equally expensive.
Denial first. “We’ll deal with it in 2027”, “it doesn’t really apply to us”. Meanwhile, systems multiply inside the business units, off the radar, and compliance debt grows quietly. The day a candidate contests an automated rejection, or a regulator asks a question, you discover you cannot even answer “how many systems?”.
Over-compliance next. More insidious, because it looks virtuous. You freeze every AI project “as a precaution”, you convene an ethics board to sign off on a spell-checker, you write a hundred pages for a minimal-risk tool. The result: innovation stalls, and energy drains into things that do not matter. Compliance done well concentrates the effort on high risk and lets the rest breathe.
Which leaves the real question: who owns all this? Not the CIO alone, it is not purely technical. Not the lawyer alone, they cannot see the systems. In practice, the trio that works is an AI lead (often sitting in data or transformation) who drives it, the DPO on the data side, and the CISO on system security. The exec committee makes the risk calls, because those are business decisions, not compliance footnotes.
Start small, but start. An honest inventory beats a perfect governance policy that never ships. This is exactly what we set up with our clients through our Run, Ops & governance offer, and what we dig into across our guides & resources. Understanding the regulation was never the hard part. Knowing, at last, what is actually running across your business is.