HomeBlogThe EU AI Act, Practically
AI regulation

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:

  1. Risk management system — documented, iterative, covering the full lifecycle.
  2. Data governance — training/validation/testing data quality documented, bias assessed, examples labelled properly, provenance clear.
  3. Technical documentation — a well-defined dossier of what the system is, how it was trained, tested and validated.
  4. Record-keeping — automatic logging of events sufficient for traceability and post-market monitoring.
  5. Transparency & instructions for deployers — the deployer must be able to understand and appropriately use the output.
  6. Human oversight — the system must be designable so that a person can intervene, override, or stop it.
  7. Accuracy, robustness, cybersecurity — appropriate to the risk.
  8. Quality management system — documented processes for compliance, change management, incident reporting.
  9. Conformity assessment — before market placement.
  10. Registration — in the EU database.
  11. 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:

  1. What risk category is the AI system under the EU AI Act?
  2. What is your risk-management approach?
  3. Where does your training data come from and how is it governed?
  4. How is human oversight ensured in operation?
  5. What monitoring do you do for accuracy and drift post-deployment?
  6. 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:

  1. Write down every AI feature your product has today and every one on the roadmap.
  2. For each, classify (prohibited / high / limited / minimal). Get counsel to confirm on any that look like high-risk.
  3. Assemble what you already have that could go in a compliance dossier — evaluation results, monitoring dashboards, training data policy, incident process.
  4. 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