The EU AI Act has been on the calendar for a while, but for most UK suppliers it has felt comfortably distant. That stops in August. On 2 August 2026 the high-risk provisions of the Act come fully into force, and any UK firm placing an AI system on the EU market — directly, through a partner, or embedded in a product their customers ship to Europe — has obligations to meet by that date. Non-compliance carries fines of up to €35 million or 7 per cent of global turnover, whichever is higher.
We have spent the last few months working through what this actually means for the kind of AI work we deliver: agents, RAG systems, generative AI features embedded in client applications. This article is the checklist we use internally, written for engineering and product teams rather than lawyers. It is not legal advice, but it should help you work out whether you have a problem, and what to do about it.
Does the Act Apply to You?
The first question to answer is the simplest one to get wrong. Three things matter:
- You are placing an AI system on the EU market. That includes selling, licensing, or making available for free. It includes embedding AI features in a wider product. It includes deploying agents that act on behalf of EU users.
- The system meets the EU’s definition of AI. That is intentionally broad — machine learning, logic-based, statistical inference — but excludes simple deterministic software.
- You are either a “provider” or a “deployer” of the system as the Act defines those roles, and the system falls into one of the four risk categories.
The Act does not care where your servers live or where your company is registered. If your AI is being used in the EU, you are in scope. The “Brexit gets us off the hook” hope is a misreading; UK suppliers are squarely in scope when selling into Europe.
The Four Risk Categories — Most of You Are in Two of Them
The Act sorts AI systems into four tiers:
| Risk level | What it covers | What you have to do |
|---|---|---|
| Unacceptable | Social scoring, real-time biometric surveillance in public spaces, manipulative AI | Prohibited entirely |
| High-risk | AI used in employment, credit, education, critical infrastructure, law enforcement, certain medical and product-safety contexts | Heavy compliance obligations from 2 Aug 2026 |
| Limited risk | Chatbots, emotion recognition, deepfakes | Transparency obligations (users must know they are interacting with AI) |
| Minimal risk | Most other AI applications | No specific obligations under the Act |
For most of the work we see — recruitment screening agents, public-sector decision-support tools, AI features in financial services applications, AI in healthcare and education — high-risk is the relevant category. Annex III of the Act spells out the specific use cases. If your AI touches hiring, promotion, credit decisions, exam grading, public benefits administration, or a handful of other named domains, you are high-risk by default.
High-Risk Provider Obligations: The Checklist
If your system is high-risk, the August 2026 deadline brings a set of concrete obligations. Here is what we work through with clients:
1. Risk Management System
You need a documented, iterative risk management process that runs for the entire lifecycle of the system. Not a one-off risk register, but a living artefact that gets updated when the model is retrained, the data shifts, or new failure modes are discovered.
In practice, this means an owner, a review cadence, and version-controlled documentation showing how risks were identified and mitigated.
2. Data Governance
Training, validation and test data have to meet specified quality criteria — representative, free of errors as far as possible, appropriate for the intended purpose, and assessed for bias. You need to be able to evidence where the data came from, how it was prepared, and what checks were applied.
This is the obligation that catches most teams off guard. If you fine-tuned a model on a dataset scraped from somewhere convenient and you cannot reconstruct the lineage, that is a problem to fix now.
3. Technical Documentation
Article 11 requires technical documentation comprehensive enough that a regulator can assess compliance from it. Architecture diagrams, training methodology, performance metrics, known limitations, intended purpose, foreseeable misuse. We treat this as a living document maintained alongside the codebase, not a separate compliance artefact.
4. Record-Keeping and Logs
High-risk AI systems must log their operation automatically. The logs need to allow traceability of inputs, outputs, and the events that led to a particular decision. For agentic systems this is particularly demanding — every tool call, every retrieved document, every model response needs to be reconstructable. We build this in using OpenTelemetry and structured logging from the start.
5. Transparency to Deployers
If you are a provider, the people deploying your system need clear instructions for use — what the system does, what its limitations are, how to interpret its outputs, what human oversight is required. A two-line API description is not enough.
6. Human Oversight
The system must be designed so that humans can effectively oversee it. That means meaningful human review of outputs that matter, the ability to override or intervene, and clear escalation paths. The FCA already enforces this principle in UK financial services; the AI Act generalises it.
For agentic systems, this is a design question, not a compliance bolt-on. Where does the human sit in the loop? Which actions can the agent take autonomously? Which require approval? We answer these at the architecture stage, not after launch.
7. Accuracy, Robustness and Cybersecurity
The system must perform consistently with its intended purpose, be resilient against errors and adversarial inputs, and meet appropriate cybersecurity standards. Evaluation suites with documented test cases are the practical evidence here.
8. Conformity Assessment and CE Marking
Before placing the system on the market, you need to go through a conformity assessment — internal for most categories, third-party for some. Successful systems carry a CE marking and are registered in the EU’s high-risk AI database.
9. Post-Market Monitoring
After deployment, you need a documented process to monitor real-world performance, detect drift and incidents, and report serious incidents to the relevant authorities. This is not optional, and it is not a quarterly review — it is continuous.
What This Means in Practice
The honest truth is that for most high-risk systems, meeting these obligations is a non-trivial engineering and operations project. It is not a matter of writing a policy document and filing it. It changes how you build, how you test, how you log, and how you operate AI systems in production.
The good news is that the obligations align almost exactly with what well-engineered AI systems look like anyway. Structured logging, evaluation suites, version-controlled data pipelines, human-in-the-loop design, post-deployment monitoring — these are things responsible teams already do. The Act formalises them and adds documentation requirements.
A Pragmatic Plan for the Next Three Months
If you are reading this and realising you have work to do before August, the order we recommend is:
- Triage your AI systems. Inventory everything, classify against Annex III, and identify which systems are high-risk. This usually takes a week or two and clarifies the scope of the problem.
- Map gaps against the obligations. For each high-risk system, walk through the nine areas above and identify where you have documentation, where you have practice but not documentation, and where you have neither.
- Prioritise the binding gaps. Risk management, logging, human oversight and post-market monitoring tend to be the load-bearing ones. Documentation can be assembled in parallel.
- Engage proper legal counsel for the formal pieces. Conformity assessment, CE marking and database registration benefit from someone who has done it before.
- Build the operational capability. This is the largest piece of work and the one most often deferred. Get it in flight now.
Where We Come In
We build production AI systems for UK organisations, and we do it with the engineering discipline that the AI Act now requires by law. If you are looking at the August deadline and wondering whether your current AI projects will hold up, or you are planning new AI work and want to build it compliant from the start, get in touch. We work with clients across recruitment, public sector, financial services and healthcare — the sectors where high-risk obligations bite hardest.
The August date is not negotiable, but the work to meet it is entirely manageable if it starts now. The teams that leave it until July are the ones who will struggle.
