The EU AI Act in practice: a compliance checklist for businesses that use AI

On 2 August 2026 the bulk of Regulation (EU) 2024/1689 — the EU AI Act — moved into general application. For most businesses that changed very little about what they are allowed to build, and quite a lot about what they need to be able to show. The distinction matters, because the market has responded with a great deal of compliance theatre aimed at organisations that are, in regulatory terms, doing something fairly ordinary.

This is the checklist we run before an AI system we have built goes into production. It is written from the engineering side: what has to exist in the software, in the logs and in the documentation. It is not a legal opinion, and the classification questions at the end of it belong with your counsel.

First, work out which role you are in

The Regulation divides duties mainly between providers, who place an AI system on the market, and deployers, who use one under their own authority. Most companies buying or commissioning AI are deployers, and deployer duties are meaningfully lighter.

The trap is that you can become a provider without intending to. Putting your own name or trademark on a system, changing its intended purpose, or substantially modifying a high-risk system moves the provider obligations onto you. This is the single most common surprise we see, and it is worth resolving on day one rather than during a customer's security review.

Then work out which risk tier applies

The Act scales with risk rather than with technology. The same model can be unregulated in one context and high-risk in another, because classification follows what the system decides and about whom.

1. 01

   Unacceptable risk — prohibited

   Social scoring, untargeted scraping of facial images, emotion inference in workplaces and schools, and a small number of other practices. These are banned outright and have been since February 2025.

2. 02

   High risk — the heavy obligations

   Systems that materially influence decisions about employment, creditworthiness, education, essential public or private services, migration or law enforcement, plus AI embedded in products already covered by EU product-safety law. This tier carries risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness requirements.

3. 03

   Limited risk — transparency duties

   Chatbots, assistants and generated content. Article 50 requires that people are told they are interacting with an AI system, and that synthetic content is marked as such. This is where the large majority of ordinary business AI sits.

4. 04

   Minimal risk — no specific obligations

   Spam filtering, search ranking, forecasting, most internal tooling. Good engineering practice still applies; the Regulation adds nothing on top.

The checklist

Below is what we make sure exists before launch. Each item is trivial to build in and expensive to reconstruct afterwards, which is the entire argument for doing it up front.

1. Disclosure in the interface (Art. 50)

If a person is interacting with an AI system, they must be told, in a way that is clear at the point of interaction. A line in a privacy policy does not satisfy this. Practically: a persistent label in the chat interface, and — where you generate text, images or audio on a customer's behalf — machine-readable marking of the output.

2. A human who can actually intervene (Art. 14)

Human oversight is not a clause; it is a screen somebody uses. In our builds this means a confidence threshold that routes uncertain cases to a review queue, and a named person who can pause the automation and reverse an action it has taken. If the only way to stop the system is to ring an engineer, oversight does not exist.

3. Logs that answer 'why' (Art. 12)

Record the input, the sources or features the decision drew on, the output, the confidence score and — where applicable — who reviewed it. Give the log a retention rule, because an unbounded log is a GDPR problem wearing an AI Act costume. When a regulator or a customer asks why a particular decision came out the way it did, the answer should be a query rather than an investigation.

4. A data-source register (Art. 10)

Write down where the training, tuning or retrieval data came from, what it contains, what was deliberately excluded and why. Do this while you build. Reconstructing it eighteen months later is guesswork, and guesswork is exactly what the obligation exists to prevent.

5. A technical file (Art. 11)

Purpose, architecture, model choices and the reasoning behind them, known limitations, and test results. Ours is a document in the repository that changes with the code, not a PDF written the week before an audit.

6. Evidence that it works (Art. 15)

Accuracy has to be a number, produced by an evaluation set built from real cases and agreed before launch. Re-run it on every change. This is the item teams resist most and benefit from most, because it is also the only reliable way to tell whether the last three weeks of tuning helped.

Where the AI Act and the GDPR meet

They overlap rather than compete. The GDPR governs the personal data flowing through the system; the AI Act governs the system itself. In practice the same design decisions serve both: minimisation at collection, retention rules enforced by a job rather than a policy, role-based access with an audit trail, and a human in the loop for consequential decisions.

Which is why we treat it as one architecture problem. A system designed GDPR-native from the first schema arrives at most of the AI Act's engineering requirements as a side effect, and the remaining gap is documentation.

What we would do next, in order

1. 01

   Inventory what you are already running

   Including the tools bought by a department without telling IT. You cannot classify what you have not listed, and the list is usually longer than expected.

2. 02

   Classify each use, not each vendor

   One SaaS product can host a minimal-risk feature and a high-risk one. The classification attaches to what the system decides, and about whom.

3. 03

   Close the transparency gap first

   It is the cheapest item on the list, it applies to the widest set of systems, and it is the most visible to customers.

4. 04

   Then build the evidence layer

   Logs, evaluation set, technical file. Roughly a week of engineering on a system of ordinary size, and it is the part nobody can retrofit convincingly.