EU AI Act readiness checklist for CIOs

The Act entered into force on 1 August 2024, with staggered application dates that every CIO needs in their planning calendar [1].

2 February 2025. Chapter I (general provisions) and Chapter II (prohibited practices) apply. From this date, the practices listed in Article 5 - including untargeted scraping of facial images, social scoring by public authorities, and certain emotion-recognition systems in workplaces and education - cannot be placed on the market or put into service in the EU. Article 4 obligations on AI literacy of staff also apply.

2 August 2025. Obligations on providers of general-purpose AI models, the rules for notified bodies, the governance structure under the AI Office and the European AI Board, the confidentiality and penalty provisions, and the rules for model providers placed on the market all apply.

2 August 2026. The bulk of the Act applies. This is the date most enterprises are planning around. From this date, providers and deployers of high-risk systems under Annex III must comply with Articles 8 to 22, which cover the risk-management system, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, and post-market monitoring.

Risk classification is the gate that determines which obligations apply. The Act defines four categories. The CIO's first task is to place every AI system in the inventory into one of them, with a written rationale.

Prohibited (Article 5). A short list of practices that cannot be deployed in the EU at all, including manipulation that exploits vulnerabilities, social scoring by public authorities, predictive policing based solely on profiling, untargeted scraping of facial images to build recognition databases, real-time remote biometric identification in public spaces by law enforcement except in narrow circumstances, and emotion recognition in workplaces and education except for medical or safety reasons. If a system in the inventory falls here, decommission it.

High-risk (Article 6 plus Annex III). Systems used in eight listed areas where AI can materially affect rights or safety: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services (including credit scoring), law enforcement, migration and border control, administration of justice and democratic processes. Plus systems that are safety components of products covered by the Annex I legislation. High-risk systems carry the heaviest obligations and most CIOs will have at least one in their inventory.

Limited-risk (Article 50). Systems that interact with natural persons (chatbots), generate synthetic content (deepfakes), perform emotion recognition or biometric categorisation outside high-risk contexts, or generate text published to inform the public on matters of public interest. The obligation is principally transparency: users must be informed they are interacting with AI, and synthetic content must be labelled as such in machine-readable form.

The checklist below is grouped into five sections. Each item is a binary question with a documented evidence path. A CIO should be able to walk through this in an afternoon for any single in-scope system, longer for the full inventory.

Section A - Inventory and classification (items 1-5).

1. Is there a single, current inventory of every AI system in use across the organisation, including third-party platforms with embedded AI?
2. For each system, is there a written description of the intended purpose, the deployer, the provider, and the user population?
3. Is each system classified as prohibited, high-risk, limited-risk, or minimal-risk under the Act, with a written rationale?
4. For each high-risk system, is the specific Annex III heading documented?
5. Is there a named accountable owner inside the organisation for each system?

Section B - Data and model governance (items 6-10).

For a single high-risk system, the compliance file has a predictable shape. Article 8 requires a risk-management system that runs across the lifecycle. Article 9 requires that risk-management system to identify, evaluate, and mitigate known and foreseeable risks. Article 10 requires data governance, including bias examination of training data. Article 11 requires technical documentation in line with Annex IV, prepared before the system is placed on the market. Article 12 requires automatic logging. Article 13 requires transparency for users. Article 14 requires human oversight. Article 15 requires accuracy, robustness, and cybersecurity. Article 17 requires a quality management system. Article 72 requires post-market monitoring. Article 73 requires reporting of serious incidents.

In a real organisation, this translates into a structured set of artefacts: a risk register, a data inventory, a model card, a logging schema specification, a user-facing description, a human-oversight design document, a measurement plan with current results, a quality-management procedure or an ISO 42001 statement of applicability, a monitoring plan, and an incident-response runbook. Each artefact has a named owner. Each is reviewed on a documented cadence. The file is not a one-time submission. It is a living set of documents that change as the system changes.

The file does double duty. It satisfies the AI Act, and it is the same file that supports DPIAs under GDPR, ISO 42001 audits, customer assurance questionnaires, and internal audit reviews. Building it once for the AI Act and re-using it across these regimes is the most efficient compliance posture available.

From August 2025, providers of general-purpose AI models face their own obligations under Article 53 and following: technical documentation, summaries of training content, copyright policy, and additional obligations for models with systemic risk. Most enterprise CIOs are not providers of GPAI models. They are deployers building on top of them. The deployer's obligations flow through the relationship with the provider.

For deployers, the practical questions are: which GPAI models are in our stack, what does the provider's published documentation cover, what are the contractual commitments on data residency and on training-data use, and what is our fallback if the provider changes the terms or withdraws the model. The AI Act formalises the documentation chain that responsible deployers were already running. It also creates a stronger procurement position, because a provider that cannot answer the documentation questions has a regulatory problem, not just a commercial one.

The European Commission's AI Office has been publishing GPAI codes of practice through 2025 with industry input. CIOs procuring GPAI capacity should be tracking the codes that apply to their providers and asking, in writing, how the provider intends to comply [2].

We run a TRACE readiness audit as a paid two-to-four-week scoping engagement. The deliverable is a written file that includes an AI inventory, a risk classification per system, a gap analysis against the 25-item checklist, a target-state architecture for the highest-priority systems, and a remediation plan with named owners and target dates. The file is reviewable by the DPO, the security lead, and internal audit.

From there, engagements split into delivery work on specific in-scope systems, ongoing operate work for systems already in production, and advisory work supporting the compliance function through the August 2026 application date. We do not certify or audit; that work belongs to notified bodies and accredited assessors. We design and build the systems and the documentation that survive their reviews.

If you would like to walk the 25-item checklist against your own AI inventory, the intake form is the only path in. We reply within one business day with a written next step.