The EU AI Act, Practically
This is a practitioner's summary, not legal advice. The EU AI Act is complex and your specific obligations should be confirmed with counsel. What follows is the engineering-and-product view — the shape of what you need to do, not the definitive legal text.
Most UK teams we speak to think the EU AI Act is either a problem for someone else, or such a big problem that they can't start thinking about it yet. Both positions are wrong — and increasingly, both cost sales.
The Act is enforceable now, with obligations phasing in through 2026 and 2027. Enterprise buyers — especially in the EU but increasingly in the UK too — are starting to ask AI vendors direct questions about compliance during procurement. Being able to answer confidently and briefly is quickly becoming a sales advantage; hedging or waffling is becoming a deal-killer.
Here's the engineering-and-product-side view of what you need to know.
Step 1: does the Act apply to you?
Broadly, yes if any of the following are true:
- You place an AI system on the EU market, or you use one in the EU, or its output is used in the EU — regardless of where your company is based.
- You're a "provider" (build/train an AI system for sale/use), "deployer" (use one in a professional context), "importer" or "distributor".
- Your general-purpose AI model is used by others in the EU (GPAI provider obligations).
UK-only businesses with UK-only customers may technically be out of scope. Practically, if you ever want an EU customer, you'll be answering these questions in RFPs — start preparing now.
Step 2: what risk tier is your system?
The Act uses four risk categories. Getting this categorisation right is the single most important compliance decision you'll make.
Prohibited (Article 5) — do not build
Social scoring, real-time biometric identification in public spaces (with narrow law-enforcement exceptions), emotion recognition in workplaces/schools, subliminal manipulation, exploitation of vulnerabilities. If your product concept lives here, it's not "high friction to ship" — it's illegal.
High-risk (Annex III + safety components)
The bulk of enterprise AI. Systems used in: recruitment/HR decisions, credit scoring, education admissions/grading, essential public/private services eligibility, law enforcement, migration/border control, biometrics, critical infrastructure, and AI as a safety component in regulated products (medical devices, machinery, etc.).
Also: most workplace AI making decisions about workers. Read Annex III carefully.
Limited-risk / transparency-only
Chatbots (must disclose users are talking to AI), deep fakes / synthetic content (must label), emotion recognition and biometric categorisation outside prohibited contexts (transparency obligations). Not onerous, but skipping the disclosure is a fine risk.
Minimal-risk
Everything else — spam filters, product recommenders, AI-generated meeting summaries, most creative AI tools. No specific Act obligations, though voluntary codes of conduct are encouraged. Most day-to-day AI products live here.
Practical rule: if your AI system makes or materially informs a decision that affects a person's job, credit, education, healthcare, legal status, benefits, or safety — assume high-risk and plan accordingly. Otherwise you're probably minimal or limited.
Step 3: if you're high-risk, what do you actually have to do?
High-risk providers must implement, roughly:
- Risk management system — documented, iterative, covering the full lifecycle.
- Data governance — training/validation/testing data quality documented, bias assessed, examples labelled properly, provenance clear.
- Technical documentation — a well-defined dossier of what the system is, how it was trained, tested and validated.
- Record-keeping — automatic logging of events sufficient for traceability and post-market monitoring.
- Transparency & instructions for deployers — the deployer must be able to understand and appropriately use the output.
- Human oversight — the system must be designable so that a person can intervene, override, or stop it.
- Accuracy, robustness, cybersecurity — appropriate to the risk.
- Quality management system — documented processes for compliance, change management, incident reporting.
- Conformity assessment — before market placement.
- Registration — in the EU database.
- Post-market monitoring & serious incident reporting.
Yes, this is a lot. But note: most of it is documenting engineering practices a well-run team should have anyway. The gap is usually less about doing new work and more about writing down work that's already happening.
General-Purpose AI Model providers
If you fine-tune, host, or place on the EU market a general-purpose AI model, you have your own obligations (technical documentation, training data summary, copyright policy). If you further hit "systemic risk" thresholds (currently 10^25 training FLOPs), obligations increase substantially.
Most teams building on top of frontier models via API are not GPAI providers — they're providers of an AI system that uses a GPAI. But if you self-host or fine-tune, check carefully.
What buyers actually ask
Enterprise procurement questionnaires now routinely include some form of:
- What risk category is the AI system under the EU AI Act?
- What is your risk-management approach?
- Where does your training data come from and how is it governed?
- How is human oversight ensured in operation?
- What monitoring do you do for accuracy and drift post-deployment?
- How do you handle serious incidents?
Being able to answer these in one short document rather than "let me get back to you" is a real advantage. We've watched clients close six-figure enterprise deals on the strength of a solid four-page AI compliance summary.
The pragmatic first move
Before spending anything on formal compliance:
- Write down every AI feature your product has today and every one on the roadmap.
- For each, classify (prohibited / high / limited / minimal). Get counsel to confirm on any that look like high-risk.
- Assemble what you already have that could go in a compliance dossier — evaluation results, monitoring dashboards, training data policy, incident process.
- Identify the top three gaps. Add them to the roadmap.
A team that starts here can typically be procurement-ready within a quarter. A team that waits until the first RFP asks tends to lose that RFP.
Need to get AI-Act ready — without stopping your roadmap?
We help engineering teams navigate the AI Act pragmatically: classification, dossier prep, evaluation, monitoring. Practical, not paranoid. Tell us where you are.
See AI consulting →