EU AI Act (Regulation (EU) 2024/1689) Compliance program

Build the program around a shared AI inventory, a role matrix, and a classification workflow. Every system and model should move through the same logic: scope, Article 5 screening, high risk analysis, transparency analysis, GPAI analysis, and release controls.

Make one team accountable for the operating model, but keep execution distributed. Product owns intended purpose and release. Engineering owns implementation and evidence. Security owns threat and resilience controls. Legal and compliance own classification review and authority response.

The dates matter because the obligation mix changes over time. Entry into force was 1 August 2024. From 2 February 2025, the general provisions, prohibited practices, and AI literacy requirements apply. From 2 August 2025, Chapter V for GPAI, governance provisions, and penalties provisions begin to matter. The main application date is 2 August 2026, with later special dates for some product safety and transition scenarios.

A mature program turns each date into deliverables. That means owners, acceptance criteria, artifact templates, and review calendars tied to the applicable phase.

The control stack should be simple to describe and strong enough to survive challenge. The minimum set is inventory, classification, approvals, evidence retention, incident response, corrective action, and recurring review. Everything else should attach to those foundations.

Where possible, connect the AI Act program to existing release, security, procurement, and audit processes. Standalone AI governance tools often fail because they drift away from the systems that actually govern shipping.

Some systems need deeper specialist tracks. High risk systems need Annex IV planning, conformity work, human oversight design, logging design, post market monitoring, and, in certain contexts, FRIA and EU database registration. GPAI providers need model level documentation, copyright policy, training content summary publication, and systemic risk response readiness.

Do not bury these specialist tracks inside generic AI governance. They need named SMEs, templates, and evidence standards of their own.

A strong program can prove both design intent and actual operation. That means training records, meeting outcomes, release gates, technical documentation, and monitoring results all point to the same current system state.

If your evidence is only narrative and not version linked, your program will look stronger on paper than it is in practice.