EU AI Act compliance roadmap

The EU AI Act is Regulation (EU) 2024/1689. It applies a risk-based legal framework to AI systems and general-purpose AI models. The exact duties depend on what is being supplied or used, the organization's role, the system's classification, and the context in which it operates.

Rules for general-purpose AI models began applying in August 2025. Article 50 transparency obligations for specified AI systems began applying on 2 August 2026. The Commission's current implementation page states that obligations for high-risk systems begin applying on 2 December 2027. Prohibited-practice dates and transitional provisions require system-specific legal review rather than reliance on one summary timeline.

Implementation should therefore separate obligations already in force from controls that need to be ready for later application. Keep the regulatory interpretation dated and owned because Commission guidance, standards, codes, and the underlying implementation timetable can change.

The same organization can hold different roles for different systems. A company may deploy a purchased AI service internally, provide an AI-enabled product to customers, import a system into the EU, distribute another provider's system, or place its own name on a substantially modified system. Obligations follow the relevant role, not the organization's preferred description of itself.

Start with a legal-entity and product-flow map. Record who develops the system, whose name appears on it, who places it on the market, who operates it, who determines the intended purpose, and who makes material modifications. Include embedded AI supplied through SaaS and product updates, not only systems labelled as AI projects.

The Commission describes four broad risk levels: unacceptable risk, high risk, transparency risk, and minimal or no risk. General-purpose AI models also have a separate regime. Classification must use the regulation, relevant annexes, current Commission guidance, and the actual intended use.

Do not classify a system by model name or vendor category. A general-purpose model can sit inside workflows with very different effects. Record the system boundary, intended purpose, users, affected people, decisions, sector, safety function, automation, human oversight, and foreseeable misuse before reaching a conclusion.

Article 50 obligations began applying on 2 August 2026. Depending on the system, providers may need to design systems so people are informed when interacting with AI or so synthetic outputs can be detected in a machine-readable format. Deployers have obligations for specified uses such as certain emotion-recognition, biometric-categorisation, deepfake, and public-interest text scenarios.

Treat transparency as a product requirement, not a policy sentence. Define what information appears, when it appears, who receives it, which outputs require marking or labelling, how accessibility is handled, and how the organization proves the disclosure operated for the relevant version and channel.

The Commission's overview identifies core high-risk obligations including risk management, data quality, logging, technical documentation, information for deployers, human oversight, robustness, cybersecurity, and accuracy. Providers and deployers carry different duties, so the evidence set must show ownership and hand-offs across the supply chain.

A model card alone is not sufficient. The evidence must describe the complete system, its intended use, data, interfaces, human decisions, controls, performance limits, deployment context, monitoring, incidents, and change history. Where conformity assessment or registration applies, plan it into release governance rather than treating it as a final documentation exercise.

Run implementation as a portfolio programme with system-level evidence. The sequence below is Kesho's operating recommendation; it is not a statutory timetable. Prioritize systems with prohibited-use exposure, active Article 50 duties, high-risk indicators, sensitive decisions, or significant customer and operational impact.

The AI Act should not create a parallel governance bureaucracy. Connect legal obligations to the organization's product lifecycle, security, privacy, procurement, model risk, quality management, incident response, and enterprise risk processes. One artifact can support several duties when traceability is explicit.

NIST AI RMF provides voluntary risk-management outcomes, while ISO/IEC 42001 specifies requirements for an AI management system. Neither automatically proves EU AI Act compliance. They can provide operating structure and evidence, but the legal mapping must remain role-, system-, and jurisdiction-specific.

Boards and executive committees do not need every article and annex reproduced. They need a reliable view of exposure, deadlines, unresolved decisions, investment requirements, and whether the organization can demonstrate control.