AI Act deployer readiness: a working checklist

This is a working checklist, not legal advice. It is written from an architecture perspective: each question maps to something a system either does or does not do. Take the legal reading from your own counsel, and confirm the current timetable before planning against it, since it has been amended since the regulation entered into force.

Run it per system rather than per organization. The answers differ, and an organizational average hides the system that will cause the problem.

1. Scope and role

• Is this system on your AI inventory, and does that inventory have a named owner?
• Are you the deployer, or have you become a provider by putting your name on it, modifying it substantially, or changing its intended purpose?
• What is the stated intended purpose, and does actual use still match it?
• Does the system fall into a prohibited category, a high risk category, or neither, and who made that determination?

If the inventory does not exist, stop here and build it. Every other question is unanswerable at organizational scale without one, and most organizations discover systems they did not know were running.

2. Human oversight

• Is a specific role accountable for oversight of this system, named rather than implied?
• Does the interface allow that person to reject or override an output, or only to view it?
• Do they have the competence to judge the output, and the authority to act on that judgement?
• Is there a record of when overrides happened, so oversight can be shown to be real rather than nominal?

The common failure is a review step with no reject path. A person who can only watch is not oversight, and an interface that offers no override cannot be documented into one.

3. Data and inputs

• Can you describe what data the system consumes, and where each source comes from?
• Is that input data relevant and sufficiently representative for the stated purpose?
• Does the system process personal data, and on what legal basis?
• Can you trace, for a given output, which inputs and sources produced it?

4. Logging and evidence

• Does the system generate logs automatically, rather than on request?
• Is a retention period defined, and does storage actually hold that long?
• Do the logs capture enough to reconstruct a decision, including model and context version?
• Could you produce the record for a single named case within a working day?

The last question is the useful one. Retention policies are easy to write, and the gap usually appears when someone tries to retrieve a specific interaction from four months ago.

5. Transparency and people

• Where the system interacts with people, is it clear to them that they are dealing with a machine?
• Where it generates content, is that content marked as synthetic at the point of creation?
• Where it is used in the workplace, have workers and their representatives been informed before deployment?
• Do the staff who work with it have sufficient understanding of what it does and where it fails?

Every question here is answered by the system or not at all. A policy describing the intended behaviour is not evidence that the behaviour occurs.

Reading the results

A system that fails on logging or oversight has an architectural gap, and the remediation is engineering work with a lead time. A system that fails on scope questions has a governance gap, which is faster to close and usually reveals more failures elsewhere.

If a system fails most of section 1, it is not ready for a compliance discussion. Establish what it is and who owns it first.

What we recommend

Run the inventory before the assessment. Then work the list on your two or three highest-exposure systems rather than attempting the whole estate, since the pattern of gaps repeats and fixing it once usually fixes it broadly.

Be conservative in classification. The reasoning has to hold up later, and it is cheaper to over-prepare a borderline system now than to defend a thin argument during an inspection. Where a system sits close to the line, redesigning it to sit clearly below the line is often cheaper than either.

Where should an AI Act readiness assessment start?

With an inventory of the AI systems already running, including ones adopted without a project. Record purpose, accountable owner, data touched, and whether you are provider or deployer. Every other question is unanswerable at scale without that list.

What counts as human oversight in practice?

A named role with the competence to judge an output and the authority to override it, using an interface that actually offers a reject path, with overrides recorded. A review step that only allows viewing is not oversight and cannot be documented into one.

What logging is needed for a deployed AI system?

Automatically generated logs, a defined retention period that storage actually honours, and enough captured to reconstruct a decision including model and context version. The practical test is whether you could produce the record for one named case within a working day.

Should we assess every system or start with a few?

Start with the two or three highest-exposure systems. The pattern of gaps tends to repeat across an estate, so fixing it once usually fixes it broadly, and a full sweep before any remediation delays the work that matters.