EU AI Act Compliance Checklist: A 10-Step Guide

An EU AI Act compliance checklist is a structured set of steps that helps you meet the regulation's obligations without missing anything. In practice it means ten things: inventory every AI system, classify each by risk tier, write technical documentation, govern your training and input data, design human oversight, disclose AI use where Article 50 requires it, keep logs, vet your vendors, monitor systems after launch, and assign clear ownership with a review cadence. The Act applies in phases — banned uses since February 2025, general-purpose AI rules since August 2025, and most high-risk obligations from August 2026 — so the right starting point is knowing what you have and where each system sits. This is general information, not legal advice.

Why a checklist beats reading the whole regulation

The EU AI Act runs to more than a hundred articles and a stack of annexes. If you try to read it front to back before doing anything, you will either stall or panic. A checklist turns the regulation into a sequence of decisions you can actually act on, in roughly the order that makes sense for an implementer.

The Act is risk-based. It does not treat a spam filter the same way it treats an AI system that scores job applicants or triages patients. Most of the heavy obligations land on a defined set of high-risk use cases and on general-purpose AI models. A large share of everyday business AI ends up in lighter categories, where the main duty is honest disclosure. The whole point of the steps below is to find out, quickly, which bucket each of your systems falls into — so you spend effort where the law actually demands it.

One caveat before the list: this is general information to help you organise the work, not legal advice. For binding interpretation of how the Act applies to a specific system, you will want a qualified lawyer. What follows is the implementer's view — the practical work that has to happen regardless of who signs off on the legal read.

The phased dates you are working against

Compliance is not a single deadline. The Act entered into force in August 2024 and applies in stages, which is good news — it means you can sequence the work instead of doing everything at once.

• 2 February 2025 — bans on prohibited practices took effect (for example, social scoring and certain manipulative or untargeted facial-scraping uses). If you operate anything near these, it should already be switched off.
• 2 August 2025 — obligations for general-purpose AI (GPAI) models began, along with the governance and penalty framework. If you build on foundation models or provide one, this is live.
• 2 August 2026 — the bulk of the high-risk system obligations apply. This is the date most organisations are really planning around.
• 2 August 2027 — extended transition for high-risk AI that is embedded in products already covered by other EU product-safety law.

Treat August 2026 as your working horizon for high-risk systems. Anything you classify as high-risk in step two needs its documentation, oversight, and logging in place by then — and good documentation takes months, not weeks, to assemble honestly.

Step 1 — Inventory every AI system you build, buy, or use

You cannot comply with rules for systems you have not written down. Start by listing every AI system in the organisation, including the ones nobody calls "AI": the chatbot on the website, the CV-screening tool in HR, the demand-forecasting model in operations, the fraud-scoring vendor in finance, and the foundation-model API a developer wired in last quarter.

For each entry, capture the basics: what it does, who owns it, whether you built it or bought it, what data it touches, and whether its output affects a person's rights, money, safety, or access to a service. That last column is what drives the risk classification in step two.

• Include shadow AI — tools individual teams adopted without central sign-off.
• Note the role you play for each system: are you the provider (you build or rebrand it) or the deployer (you use someone else's)? Obligations differ.
• Keep the inventory in one living place, not a slide that goes stale the day after the meeting.

Most teams are surprised by how long the list is. That surprise is the inventory doing its job.

Step 2 — Classify each system by risk tier

The Act sorts AI into four buckets. Run every inventory item through them.

• Prohibited — banned outright (social scoring, certain biometric and manipulative uses). If anything lands here, stop using it.
• High-risk — systems used in areas like employment and worker management, education, essential private and public services, critical infrastructure, law enforcement, and as safety components of regulated products. These carry the full obligations: documentation, data governance, human oversight, logging, and more.
• Limited-risk — systems that interact with people or generate content. The duty here is transparency under Article 50 (covered in step six).
• Minimal-risk — everything else, such as spam filters or inventory optimisation. No specific obligations, though good practice still applies.

Be honest at this step. The temptation is to argue everything down to minimal-risk; the cost of getting it wrong is a system that needed controls and never got them. When a case is genuinely borderline — and several will be — that is exactly where a qualified legal read earns its fee.

Step 3 — Write technical documentation: purpose, data, decisions

For high-risk systems, the Act expects technical documentation that lets a reasonable reviewer understand what the system is, how it was built, and why it behaves the way it does. Think of it as the system's permanent file, written before deployment and kept current after.

At minimum, document the intended purpose and the conditions of use; the data used for training, validation, and testing, and where it came from; the design choices and model architecture; known limitations and foreseeable misuse; the accuracy and performance metrics you measured; and the human-oversight measures you built in.

• Write it so a non-author can follow it. Documentation only one engineer understands is a liability, not an asset.
• Version it alongside the model. When the model changes, the file changes.

This step is where most of the real effort lives. If you have built models without writing this down — and many teams have — closing that gap is the longest single task on the checklist.

Step 4 — Govern your data and its quality

High-risk systems must be built on data that is relevant, sufficiently representative, and as free of errors and gaps as the use allows. Poor data is not just a performance problem under the Act — it is a compliance problem, because biased or unrepresentative data produces outcomes that harm the people the system touches.

Practical work here: know the provenance of your datasets; examine them for bias relevant to the context (a hiring model and a credit model need different scrutiny); document the gaps you know about; and define how data is collected, labelled, and refreshed over time.

• Map this against the GDPR work you have likely already done — the two regimes overlap heavily on personal data.
• Treat data governance as ongoing, not a one-time clean-up before launch.

If your data foundations are shaky, this is where many compliance programmes quietly become data engineering programmes. That is normal — you cannot govern data you cannot trace.

Step 5 — Design human oversight that actually works

High-risk systems must be designed so a person can meaningfully oversee them — understand the output, spot when it is wrong, and intervene or override. The Act is explicit that oversight has to be real, not a rubber-stamp "human in the loop" who clicks approve on a hundred decisions an hour.

Design questions to answer: who is the named overseer for each system, what information do they see, can they stop or reverse a decision, and are they trained and resourced to actually do it? A reviewer who cannot understand the model's reasoning is not exercising oversight.

• Avoid automation bias — build in friction where a human is meant to think, not just confirm.
• Make the override path obvious and fast. If overriding is hard, people will not do it.

Good oversight is a design decision made early, not a checkbox bolted on before launch.

Step 6 — Transparency and disclosure (Article 50)

Article 50 sets transparency duties that catch far more systems than the high-risk rules do. The principle is simple: people should know when they are dealing with AI or with AI-generated content.

• If a person interacts with an AI system such as a chatbot, tell them — unless it is obvious from the context.
• If you generate or manipulate image, audio, or video content (including deepfakes), label it as artificially generated or manipulated.
• AI-generated text published to inform the public on matters of public interest must be disclosed as such.
• Emotion-recognition and biometric-categorisation systems must inform the people exposed to them.

These obligations apply broadly, even to systems you classified as limited-risk in step two. For most organisations, the practical action is a short audit of every customer-facing AI touchpoint and a clear, plain-language disclosure on each. It is low effort and high visibility — regulators and customers both notice when it is missing.

Step 7 — Logging and record-keeping

High-risk systems must automatically record events — logs — over their lifetime, so that incidents can be traced and behaviour can be reconstructed after the fact. Logging is what turns "the model did something strange last Tuesday" into an answer you can stand behind.

Decide early what each system logs, where logs are stored, how long you keep them, and who can read them. The retention period has to be appropriate to the system's purpose and to your other legal obligations.

• Log enough to reconstruct a decision: inputs, model version, output, and the human action taken.
• Protect the logs themselves — they often contain personal data and are subject to the GDPR.

Logging is cheap to build in at design time and painful to retrofit. Treat it as part of the system, not an add-on.

Step 8 — Vendor and supplier due diligence

Most organisations are deployers, not builders — you buy more AI than you make. The Act does not let you outsource responsibility by signing a contract. If you deploy a high-risk system, you carry deployer obligations regardless of who built it.

So vet your suppliers. Ask whether their system is classified as high-risk, whether they will provide the technical documentation and instructions for use you need, how they handle data, and what they commit to on monitoring and incident reporting. Build these answers into contracts and renewals.

• Keep evidence of the due diligence — a saved questionnaire response is worth more than a verbal assurance.
• Re-check when a vendor materially updates their model; their classification or guarantees may shift.

If a key supplier cannot answer basic questions about how their model was built or governed, that silence is itself a finding worth acting on.

Step 9 — Monitor and handle incidents after deployment

Compliance does not end at launch. High-risk systems require post-market monitoring — you watch how the system behaves in the real world and act when performance drifts or harms appear. Models degrade as the world changes around them, and a system that was accurate at launch can quietly become unfair a year later.

Set up the monitoring: track the metrics that matter, define what "out of bounds" looks like, and decide in advance who is alerted and what they do. Serious incidents and malfunctions that breach fundamental rights obligations carry reporting duties — know your reporting path before you need it.

• Define thresholds that trigger review, not just dashboards nobody reads.
• Write a short incident runbook: detect, contain, report, fix, document.

This is the step most teams underestimate. A POC or pilot proves a model works once; monitoring is what keeps it compliant for the years it runs in production.

Step 10 — Assign ownership and set a review cadence

A checklist that nobody owns expires the moment the project that created it ends. Name an accountable owner for AI Act compliance — often a single person who coordinates legal, data, and engineering — and give each system a named owner too.

Then set a cadence. Re-run the inventory and re-check classifications on a fixed schedule (quarterly is a sensible default), and whenever you launch a new system or materially change an existing one. New use cases appear constantly; the inventory from step one is only useful if it stays alive.

• Put compliance review on the calendar, not in someone's good intentions.
• Tie it to your existing governance — risk committees, change management, procurement gates.

Done well, this final step is what turns a one-off scramble into a process that quietly keeps you compliant as the Act's later deadlines arrive.

Where Crux Digits fits in

Most of this checklist is organisational work you can lead yourself. Where teams tend to get stuck is steps two through four — honestly classifying systems, writing technical documentation that holds up, and getting data governance into shape — because those touch how the models were actually built.

That is the kind of work Crux Digits does as a fixed-scope project. Our AI Audit & Strategy engagement (EUR 2,500, fixed) is a practical way to get the inventory, the risk classification, and a prioritised gap list done in one defined piece of work, with clear next steps rather than a vague retainer. If the audit surfaces real engineering gaps — undocumented models, untraceable data — we can scope the build to close them.

We are a boutique AI consultancy based in Nieuwegein, in the province of Utrecht, working with clients across the Netherlands and Europe. If you want a steer on where your AI sits under the Act and what to do first, a free consultation is the easiest place to start. For the Dutch-specific picture, our guide to EU AI Act compliance in the Netherlands goes deeper, and our AI consulting page lays out how we work. None of this is a substitute for legal advice — but it will tell you, concretely, what to tackle first.

Frequently asked questions