EU AI Act for enterprises: building a compliance programme
- Enterprise compliance is an operating capability across the whole AI estate, not a one-off project.
- Start with a complete inventory, then classify and prioritise by risk tier.
- Match controls to each system's role and tier, and assign a named owner to each.
- Govern your AI vendors, and keep the programme continuous and coherent with one record per system.
- Current as of June 2026. This is general information, not legal advice.
Start with a complete inventory
The foundation is knowing what you have. Most enterprises underestimate how much AI is already in use across teams, vendors, and embedded product features. Build a single inventory of every AI system, with its owner, purpose, data, and where it is used. Without this, every later step is guesswork.
Classify and prioritise
Map each system to the four risk tiers, paying closest attention to Annex III high-risk uses and any prohibited practices. This tells you where to concentrate. A handful of high-risk systems will carry most of the obligation; the long tail of minimal-risk systems will need little. Prioritise the high-risk systems and any system that makes or informs decisions about people.
Apply the right controls per system
For high-risk systems where you are the deployer, your duties include using the system per the provider's instructions, assigning competent human oversight, monitoring operation, keeping logs, and, in some cases, completing a fundamental rights impact assessment. Where you are the provider (including where you substantially modify a high-risk system), the full provider obligations apply. Match controls to role and tier rather than applying everything everywhere.
Assign clear ownership
A programme without owners drifts. Each AI system needs a named accountable owner, and the programme as a whole needs a clear home, whether in legal, risk, compliance, or a dedicated AI governance function. Ownership is what turns a policy into a practice.
Govern your vendors
Much of your AI risk comes from systems you buy rather than build. A mature programme assesses AI vendors for governance and risk, and asks them for the evidence that supports your own obligations as a deployer. This is where your internal programme connects to your supply chain.
Make it continuous
AI systems change, and a change can alter a system's risk position or make its documentation out of date. The programme needs a process to detect change, refresh classifications and documentation, monitor systems in operation, and capture incidents. When a regulation shifts (as the timeline already has), the affected systems should be flagged and reviewed.
From scattered records to one source of truth
The hardest part of an enterprise programme is keeping it coherent as it scales. When inventory, classifications, controls, documents, and evidence live in separate places, they drift apart and the programme loses its defensibility. The enterprises that stay ready keep one connected record per system, so that the answer given to a buyer matches the document reviewed by legal and the evidence retained for a regulator. That coherence is what makes a programme genuinely defensible rather than merely documented.
Key terms
- AI estate
- The full portfolio of AI systems an organisation builds, buys, or embeds across functions and products.
- Operating capability
- An ongoing function with people, process, and tooling, not a one-off compliance project.
- Deployer
- The entity using an AI system in the course of its activities, with duties of correct use and oversight.
- FRIA
- Fundamental rights impact assessment, required of certain deployers of high-risk AI systems.
- Vendor governance
- The process of assessing and overseeing third-party AI providers across the supply chain.