15 June 2026 · 11 min
The Act is law. Vague policies will not satisfy an auditor. Here is what to have ready.
The EU AI Act arrives with a reputation for being enormous, complex and frightening — and for most organisations that reputation is largely undeserved. The Act is risk-based, which means the vast majority of AI systems fall into categories that require little or nothing beyond what a responsible team would already do. The real work is not compliance theatre; it is figuring out, honestly, which of your systems are actually in scope and at what tier. Once that is clear, the obligations are usually far lighter than the headlines suggest.
This is a practical walk-through of how to approach readiness without panic. It is written by engineers who help teams do this, not by lawyers, and the aim is to help you scope the problem correctly so your actual legal counsel can sign off efficiently rather than starting from a blank page.
You cannot classify what you have not listed. The first step is a complete inventory of every system in your organisation that uses AI — and that includes the ones bought from vendors, embedded in SaaS tools, or quietly added to an existing product, not just the models you trained yourself. Teams routinely underestimate this list by half, because AI has crept into features nobody thinks of as "an AI system."
For each entry, capture what it does, what data it uses, who is affected by its outputs, and how much autonomy it has. This inventory is the foundation of everything that follows, and it is also simply good practice: you cannot govern what you cannot see.
The Act sorts systems into tiers, and almost everything you own will land in the lower ones. A small set of uses are prohibited outright. A defined list of high-risk uses — things touching areas like employment decisions, credit, essential services, biometrics and safety components — carry real obligations. Everything else is either limited-risk, where the main duty is transparency, or minimal-risk, where there is essentially nothing to do.
The single most valuable step is placing each inventoried system in the right tier, because that determines the entire workload. Most systems are minimal or limited risk. The mistake to avoid in both directions is treating a minimal-risk tool as if it were high-risk (wasting effort) or, worse, missing that a system genuinely is high-risk (carrying real exposure).
For limited-risk systems — chatbots, content generation, and similar — the core obligation is honesty with the people interacting with them. Users should know when they are dealing with an AI rather than a human, and AI-generated content should be identifiable as such. This is usually a modest change: a clear disclosure, some labelling, a line of interface copy. It rarely requires re-architecting anything.
If a system does land in the high-risk tier, the obligations become concrete: a risk management process, appropriate data governance, technical documentation describing how the system works, record-keeping and logging, meaningful human oversight, and a level of accuracy, robustness and security appropriate to the use. None of these are exotic to a team that already builds software responsibly — they are the disciplined version of things good engineering does anyway.
The work is assembling this into a coherent, maintainable conformity file rather than a scramble before an audit. Documentation written continuously as the system evolves is far cheaper than documentation reconstructed under deadline, and it is the difference between readiness and a fire drill.
A recurring theme in the Act is meaningful human oversight — and the word that matters is "meaningful." A human who rubber-stamps every automated decision without the ability or information to intervene is not oversight; it is theatre. Designing genuine oversight means giving a person the context, the authority and the practical ability to review, override or stop the system, and building the interfaces that make that possible.
This is a design problem as much as a compliance one, and it is worth doing well regardless of the law, because a system a human cannot meaningfully supervise is a liability in every sense.
The teams that find the Act painful are the ones who treat documentation as a separate project bolted on at the end. The teams that find it manageable build the evidence as they go: model cards, data lineage, evaluation results, decision logs, produced as a natural output of good engineering rather than reconstructed afterwards. The Act rewards this working style, and it happens to be how reliable systems get built anyway.
We are engineers, not lawyers, and we are careful about that line. What we do is the technical readiness work: inventory, risk classification, data-governance mechanisms, oversight design, and assembling the documentation and evaluation evidence into a structured conformity file. What we deliberately leave to your legal counsel is the final legal judgement. Structured well, the engineering evidence lets that counsel sign off efficiently instead of untangling an undocumented system, which is the fastest and cheapest path to genuine readiness.
Book a 30-minute call. We will tell you honestly whether we can help.
Book a call