What is the Act's timeline, and what applies when?
In force August 1, 2024; application staged. February 2, 2025: the prohibitions (Article 5's unacceptable-risk practices, social scoring, exploitative manipulation, most real-time remote biometric identification in public spaces, emotion recognition in workplaces and schools, untargeted facial-image scraping) and the AI-literacy duty (Article 4). August 2, 2025: governance provisions and obligations for general-purpose AI model providers (transparency, copyright policy, training-content summaries; systemic-risk models add evaluations, incident reporting, cybersecurity), plus the penalties regime. August 2, 2026: the bulk of the Act, high-risk obligations for Annex III systems (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice), transparency duties for chatbots and synthetic content, and national enforcement fully operational. August 2, 2027: high-risk rules for AI embedded in products already covered by EU product legislation (Annex I), and GPAI models placed on the market before August 2025 must reach compliance. Planning consequence: classification drives your date, a provider of an Annex III hiring tool works to 2026; a machinery manufacturer embedding AI works to 2027; anyone operating chatbots owes transparency in 2026; and the prohibitions already apply to everyone now.
How much of Article 17's quality management system does a 42001 AIMS cover?
The structural majority. Article 17 requires high-risk providers to operate a documented QMS covering: regulatory-compliance strategy; design, design-control, and verification techniques; development, quality-control, and assurance procedures; examination, test, and validation procedures; technical specifications and standards handling; data-management systems and procedures; the Article 9 risk-management system; post-market monitoring; serious-incident reporting procedures; communication with authorities; record-keeping; resource management; and an accountability framework. A mature AIMS maps well: 42001's lifecycle controls cover design, development, verification, and validation gates; its data-governance controls address data management; its impact-assessment and risk processes seed Article 9's risk-management system; its monitoring and improvement clauses seed post-market monitoring; its roles and documentation discipline cover accountability and record-keeping. The genuine deltas: Article 9's risk-management specifics (iterative, lifecycle-long, with defined residual-risk acceptability and testing against preliminarily defined metrics); Article 10's data requirements (training, validation, test data quality criteria, bias examination, and the representativeness standard, more prescriptive than 42001's data controls); Articles 11-15 mechanics (Annex IV technical documentation, automatic logging, transparency to deployers, human-oversight design, accuracy/robustness/cybersecurity declarations); and the pure conformity machinery (assessment, CE marking, registration, declaration of conformity). Treat Article 17 as the audit checklist against the AIMS and backlog the deltas per system.
Does 42001 certification give presumption of conformity under the Act?
No, and precision here matters commercially and legally. The Act's presumption-of-conformity mechanism (Article 40) attaches to harmonized standards: European standards developed under a Commission standardization request (issued to CEN-CENELEC, whose JTC 21 is drafting them) and cited in the Official Journal of the EU. High-risk systems conforming to cited harmonized standards are presumed to comply with the corresponding requirements. As of early 2026 that catalogue is still in development, JTC 21 is producing standards for risk management, data governance, transparency, human oversight, accuracy, robustness, cybersecurity, and quality management, some building on or adapting international standards including 42001, but until specific standards are cited in the OJ, no certificate, 42001 included, triggers the presumption. What 42001 certification does deliver meanwhile: a running governance system that will absorb the harmonized requirements with deltas rather than a greenfield build; evidence of systematic AI governance for notified bodies, market-surveillance authorities, and enterprise customers; and internal machinery (documentation, lifecycle gates, monitoring) the Act's obligations presuppose. Watch two things: the JTC 21 publication schedule and OJ citations as they land, and the extent to which the eventual European QMS standard diverges from 42001, early drafts suggest adaptation rather than adoption, meaning a transition delta even for certified organizations.
We are a deployer, not a provider. What does the Act ask of us, and does an AIMS help?
Deployers (organizations using AI systems under their authority) carry a lighter but real obligation set, and it is where most companies actually sit. For high-risk systems: use per the provider's instructions; assign human oversight to persons with competence, training, authority, and support; ensure input data relevance and representativeness where the deployer controls inputs; monitor operation and inform the provider (and authorities where required) of risks and serious incidents; retain automatically generated logs within defined periods; inform workers and their representatives before workplace deployment; and for public-sector and certain private deployers of Annex III systems, complete a fundamental-rights impact assessment (Article 27) before first use. Cross-cutting duties regardless of risk class: AI literacy for staff operating AI (Article 4, applying since February 2025) and transparency where people interact with AI or encounter synthetic content. GDPR co-application continues, deployer human-oversight design and Article 22 machinery are the same engineering. An AIMS helps deployers disproportionately: 42001's use-of-AI and third-party controls are exactly deployer machinery (inventory, diligence on providers, oversight criteria, monitoring, incident routing), and the impact-assessment process extends naturally to FRIA content. The deployer trap to design against: procurement, teams buy 'features' that are legally high-risk AI systems (CV screening inside the HR suite), and without an inventory-and-classification gate in procurement, obligations attach to systems nobody registered as AI.
What should an Act-readiness program look like on top of an AIMS?
Five workstreams, sequenced by the application dates. Classification: inventory every AI system (the AIMS inventory seeds this), classify against the Act, prohibited (terminate now, applicable since February 2025), high-risk via Annex III or Annex I, limited-risk transparency cases, GPAI involvement, and record role per system (provider, deployer, importer, distributor, product manufacturer), noting that substantially modifying or white-labeling a system can convert a deployer into a provider. Prohibition and literacy hygiene: verify nothing operational crosses Article 5, and stand up role-appropriate AI training with completion records. Per-system deltas: for high-risk provider roles, backlog the Article 9-15 requirements against existing AIMS artifacts (risk system, data governance, Annex IV documentation, logging, oversight design, accuracy and robustness evidence) and plan conformity assessment, registration, and CE marking toward the 2026 date; for deployer roles, oversight assignments, log retention, FRIA where triggered, and provider-instruction conformance. Contract remediation: AI procurement and sales paper needs Act clauses, role allocation, instruction and documentation flow-downs, incident-notification duties, log access; provider-deployer boundary ambiguity is tomorrow's litigation. Monitoring: harmonized-standard citations in the OJ (each one changes the conformity calculus), AI Office guidance and codes of practice, and national enforcement postures as authorities staff up through 2026. Governance-wise, run it as the AIMS's regulatory-watch and change-management processes doing their job, not a parallel project, that is what the management system is for.