The EU AI Act stopped being a future problem some time ago. It entered into force in August 2024, its prohibitions and AI literacy duties have applied since February 2025, obligations for general-purpose AI models arrived in August 2025, and the bulk of high-risk requirements land through 2026 and 2027. The penalty ceiling, up to 7% of global annual turnover for prohibited practices, is designed to reach the board.
If your organisation operates in the EU, sells into it, or uses AI outputs that affect people in it, this is now a governance obligation with a timetable. Here is the checklist we work through with leadership teams.
1. Do you know where AI is already in the building?
You cannot classify what you have not inventoried. Most enterprises discover their AI footprint is far larger than the official list: models inside procured SaaS, copilots switched on by individual teams, scripts calling public APIs with company data. The first deliverable of any readiness program is a complete register of AI systems in use, who owns each one, and what decisions each touches.
2. Have you classified each system against the Act's risk tiers?
The Act regulates by risk. Prohibited practices (social scoring, manipulative techniques, most real-time biometric identification) must simply stop. High-risk systems, including AI used in hiring, credit, essential services, and safety components, carry the heavy obligations: risk management, data governance, technical documentation, human oversight, logging, and accuracy requirements. Limited-risk systems mostly owe transparency: people must know they are interacting with AI. Getting each system into the correct tier is the core legal exercise, and the place where guessing is most expensive.
3. Can you produce the documentation on demand?
For high-risk systems, the Act expects technical documentation that explains what the system is for, what data it was trained and operates on, how it was evaluated, and how it is monitored in production. If your AI systems were built without an audit trail of decisions, data lineage, and evaluation results, that documentation debt is the longest lead-time item on this list. It is also the reason we build every system with auditable decision logs by default: retrofitting explainability is far harder than designing for it.
4. Is a named human accountable for each system?
The Act's human oversight requirements have a corporate shadow: someone must own each system's behaviour, be able to interpret its output, and have real authority to intervene or switch it off. "The vendor handles that" is not an answer regulators accept for systems you deploy. Each entry in your AI register needs a named owner with the technical means to exercise that oversight.
5. Are your vendors' obligations sorted from yours?
Most enterprises are deployers of AI rather than providers, but the boundary blurs quickly: fine-tune a model, rebrand a system, or put your name on one, and you can inherit provider obligations. Every AI procurement now needs contract language covering who holds the technical documentation, who notifies whom of incidents, and who answers to which regulator. Your existing vendor risk process is the right home; it just needs AI-specific questions.
6. Have your people been trained for it?
The AI literacy obligation is broader than most compliance training: staff who use or operate AI systems need a sufficient understanding of how they work, their limits, and their risks. For leadership, the bar is higher still, because the decisions the Act cares about, deploying a hiring screen, automating a credit decision, are made in the business, not in IT.
7. Does any of this survive contact with your delivery process?
The trap in AI governance is building it as paperwork beside the engineering rather than controls inside it. A risk register nobody consults and a policy PDF nobody reads will not survive an audit, or an incident. Readiness that holds up is operational: classification happens at project intake, documentation is generated by the delivery pipeline, oversight gates are part of deployment, and logs exist because the systems were built to produce them.
The honest summary
For most organisations the gap is not intent, it is inventory, classification, and documentation, in that order. None of it requires pausing your AI ambitions; run properly, the same disciplines that satisfy the Act (scoped systems, human authorization gates, auditable decisions) are the ones that make AI deployments succeed anyway.
That overlap is not a coincidence, and it is where we focus enterprise engagements: building systems that are compliant because of how they are engineered, not despite it. If your board is asking where you stand, the register from point one is the place to start this quarter.