The EU AI Act High-Risk Deadline Moved to December 2027. Here Is What That Means for Auditors.

The Council and Parliament reached a provisional agreement this morning on the Digital Omnibus. Annex III high-risk AI systems get pushed to December 2, 2027. AI embedded in regulated products under Annex I moves to August 2, 2028. Compliance teams will treat this as breathing room. They shouldn't — Articles 9 through 15 didn't change, and the work to satisfy them takes longer than the seventeen-month extension you just got. The full agreement text is available from the Council of the EU.

What moved is the enforcement date — not the obligations. Articles 9 through 15 (risk management, data governance, technical documentation, logging, accuracy, robustness, cybersecurity) are unchanged. Article 26 deployer duties are unchanged. The risk classification under Article 6 and Annex III is unchanged. If your organization was already behind on the August 2026 deadline, the December 2027 date gives you more time to be behind.

Two things actually got harder. First, the Article 5 prohibition list expanded to cover AI systems that generate non-consensual sexual or intimate content, and AI used to produce child sexual abuse material. These prohibitions apply from February 2, 2027. Providers have until then to comply, and the carve-out is narrow: a safe harbor exists only for systems with effective preventive safeguards, not systems where someone added a content filter as an afterthought. Second, the Article 50(2) transparency obligation for generative AI output (watermarking and AI-content disclosure) was given a compressed grace period, cut from six months to three, and now applies from December 2, 2026, roughly seven months from now. If your organization deploys generative AI in customer-facing products, that one lands first.

The agreement is provisional. It still needs endorsement by the Council and Parliament, legal-linguistic revision, and publication in the Official Journal. The political signal is clear. The legal text is not yet final. Continue to plan against the new dates while watching the Official Journal for the formal text.

The rest of this article covers what IT auditors actually have to verify, what your CISA program already gets right, and where the gaps are. The deadlines moved. The exam did not. If anything, the next nineteen months are the moment to get this right rather than scramble through it.

How to Read Annex III Before Your Next Vendor Review

Article 6 of the EU AI Act, paired with Annex III, defines high-risk AI for stand-alone systems. Annex I covers AI embedded in products that already fall under EU sectoral safety law (medical devices, machinery, automotive, and similar). Read the relevant Annex carefully. Two of the eight Annex III categories cover almost every high-risk AI system a typical enterprise will own or deploy:

• Point 4: Employment, workers' management, and access to self-employment: Resume screening tools, AI-assisted recruiting platforms, performance evaluation systems, promotion and termination algorithms, and task allocation tools. If your HR team uses an applicant tracking system that ranks candidates, you are in scope.
• Point 5: Access to and enjoyment of essential private and public services: Credit scoring for natural persons, life and health insurance pricing and risk assessment, evaluation of eligibility for public benefits, and dispatching of emergency services. Banks, insurers, and any company offering credit are all here.

The other Annex III categories — biometrics, critical infrastructure, education, law enforcement, migration, and administration of justice — apply to a narrower set of organizations. Do not skim them. A facial recognition feature buried in a building access system can pull an otherwise unremarkable IT environment into Annex III Point 1.

Article 6(3) creates a derogation. A system listed in Annex III is not considered high-risk if it does not pose a significant risk to health, safety, or fundamental rights. The catch is that the provider has to document the assessment in writing and register it under Article 49(2). The Omnibus agreement preserved that registration obligation, despite earlier proposals to soften it. Auditors should expect to see this documentation, and should expect most of it to be poorly reasoned. Vendors are using the derogation as a paperwork exercise. Do not accept conclusions you cannot reconstruct from evidence.

Articles 9 Through 15: The Control Objectives Your CISA Program Does Not Cover

Articles 9 through 15 contain the substantive obligations on high-risk AI systems. Each one creates control objectives that do not exist in any IT general controls program built around CISA principles.

Article 9: Risk Management System

Article 9 requires a continuous, iterative risk management process across the entire AI system lifecycle. This is not an annual risk register that gets dusted off before a steering committee meeting. The provider must identify and analyze known and foreseeable risks, evaluate risks emerging from post-market monitoring, adopt targeted risk management measures, and test that the measures work.

• What CISA covers: enterprise risk management at the program level, residual risk acceptance, change management discipline.
• What CISA does not cover: model-specific risks like distributional shift, proxy discrimination, prompt injection in generative components, and harms that only emerge after the system meets a population it was not trained on. A risk register that lists "AI risk" as a single line is not Article 9 compliant. The auditor's job is to verify that risks are identified at the level of the model, the use case, and the affected population.

Article 10: Data and Data Governance

Training, validation, and testing datasets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete. Datasets must consider characteristics specific to the geographical, behavioral, and functional setting where the system will be used.

The Omnibus agreement broadened the lawful basis for processing sensitive personal data when needed to detect and correct bias. The standard is still 'strictly necessary' and the use is restricted to specific bias-related purposes. This is not a license to process sensitive attributes freely. It is a narrow allowance that has to be documented.

• What CISA covers: data classification, access controls over data stores, retention policies.
• What CISA does not cover: dataset documentation that describes provenance, collection methodology, intended population, and known biases; statistical analysis of representativeness; bias testing across protected attributes. An IT auditor walking into an Article 10 review needs to read a model card and a datasheet and know whether the documents are real or theatre.

Articles 11 and 12: Technical Documentation and Record-Keeping

Article 11 requires technical documentation drawn up before the system is placed on the market and kept up to date. Annex IV lists what has to be in it. Article 12 requires automatic recording of events (logs) over the lifetime of the system.

• What CISA covers: SDLC documentation, change tickets, system logs.
• What CISA does not cover: model lineage, training run logs, hyperparameter records, evaluation results across versions, and the linkage between a deployed inference and the model version that produced it. If your audit cannot trace a specific output to a specific model version on a specific date, Article 12 is not satisfied. Every MLOps environment I have reviewed that was built before 2024 required retrofit to meet this standard — the logging was designed for operational monitoring, not regulatory traceability.

Article 13: Transparency and Information to Deployers

The provider must give deployers instructions for use that include the system's intended purpose, the level of accuracy and known limitations, the human oversight measures, the expected lifetime, and any maintenance requirements.

• What CISA covers: vendor management, third-party assurance reports, contract review.
• What CISA does not cover: review of model documentation for accuracy claims that are statistically defensible, verification that stated limitations were tested, and assessment of whether the deployer can actually operate the system within the conditions the provider specified. A SOC 2 report tells you nothing about whether the model performs as advertised.

Article 14: Human Oversight

The system must be designed so that natural persons can effectively oversee it during the period in which it is in use. The deployer's staff must have the competence, training, and authority to intervene, override, or stop the system.

• What CISA covers: segregation of duties, authorization controls, supervisor approval workflows.
• What CISA does not cover: meaningful human review of model outputs at speed, the cognitive load problem (auditors call it automation bias), and the question of whether a human can actually understand the model's reasoning well enough to override it. A loan officer who clicks "approve" on every recommendation in under three seconds is not exercising oversight. The audit finding writes itself.

Article 15: Accuracy, Robustness, and Cybersecurity

The system must achieve an appropriate level of accuracy, robustness, and cybersecurity, and perform consistently throughout its lifecycle. The article calls out adversarial examples, data poisoning, and model evasion specifically.

• What CISA covers: cybersecurity baseline controls, vulnerability management, patch cadence.
• What CISA does not cover: adversarial robustness testing, data poisoning detection in continuously trained systems, prompt injection defenses, model extraction protections, and the specific failure modes of probabilistic systems under distribution shift. If your penetration test scope did not include the model itself, Article 15 has a gap your scope did not see.

What Changed in Article 5, and Why the Safe Harbor Is Narrower Than It Looks

The Omnibus agreement added a prohibition. Article 5 now bans AI systems capable of generating non-consensual sexual or intimate content, including AI used to produce child sexual abuse material. The safe harbor is narrow: it covers systems with effective preventive safeguards, not systems where someone added a content filter as an afterthought.

This is not abstract. Generic image generation models can be coaxed into Article 5 territory through fine-tuning, jailbreaks, or downstream integration. If your organization hosts, distributes, integrates, or fine-tunes a foundation model with image-generation capability, the audit question is now: what controls prevent the system from producing prohibited output, and how do you evidence that those controls work? 'We added a moderation layer' is not an answer. Tested, documented, monitored controls are.

The Article 50(2) transparency obligation for generative AI also got tighter, not looser. The grace period was compressed. The new effective date is December 2, 2026 — seven months out. If your product uses generative AI to produce text, images, audio, or video that interacts with end users, you have until December to be able to mark synthetic output and disclose it where required. This is the deadline that sneaks up on most enterprises.

The Deployer Trap

Most US-headquartered enterprises will not be the provider of the high-risk AI system. They will be the deployer. Article 3(4) defines a deployer as the entity using an AI system under its authority, except where the use is for personal non-professional activity. Article 26 sets the deployer's obligations, and the Omnibus did not move them.

Buying AI from a vendor does not transfer compliance risk. Article 26 requires deployers to:

• Use the system in accordance with the provider's instructions
• Assign human oversight to natural persons with the necessary competence, training, and authority
• Ensure input data is relevant and sufficiently representative for the intended purpose
• Monitor the operation of the system and inform the provider of risks or serious incidents
• Keep the logs the system generates for at least six months
• Inform workers' representatives and affected workers before deploying a high-risk system in the workplace
• Conduct a fundamental rights impact assessment if the deployer is a public body or providing services of general interest

The fundamental rights impact assessment under Article 27 catches most internal audit teams off guard. It is not a privacy impact assessment. It covers the categories of natural persons likely to be affected, the specific risks of harm, the human oversight measures, and the measures to be taken if those risks materialize. If your privacy team is treating this as a GDPR DPIA with extra fields, the documentation will not survive scrutiny.

For IT auditors, the deployer angle is where most engagements will live. Your organization will buy AI from vendors and integrate it. The audit question is whether the organization is discharging its deployer obligations on every high-risk system it operates. Most companies cannot list their high-risk AI systems. That is the first finding.

NIST AI RMF, ISO 42001, and ISO 23894: How the Frameworks Map to the Act

The EU AI Act does not tell you how to comply. The frameworks do.

• NIST AI RMF 1.0: maps cleanly onto the Act's substantive requirements. The MAP function aligns with Articles 6 and 9. The MEASURE function aligns with Articles 10 and 15. The MANAGE function aligns with Articles 9, 14, and 26. The GOVERN function sits across the top and aligns with the deployer's program-level obligations. If you can audit a program against NIST AI RMF, you can audit it against the Act with one additional column for regulation-specific evidence.
• ISO/IEC 42001:2023: is the certifiable AI management system standard. The harmonized standards work coordinated by CEN-CENELEC points toward 42001 conformity creating a presumption of compliance with the management-system aspects of the Act once the harmonized standards are published. The clauses on context, leadership, planning, and operation provide the structure your AI governance program will eventually be measured against. If your organization is going to invest in one certification adjacent to the Act, ISO/IEC 42001 is it.
• ISO/IEC 23894:2023: on AI risk management provides the testing and treatment vocabulary that Article 9 expects. This is the document your control owners should be reading, not the Act itself.

The auditor who knows these three documents and can navigate them at speed is the auditor who will be billable on Article 9 through 15 reviews for the next decade. The auditor who knows only CISA will be billable on the access reviews and patch management portions of those engagements.

Three Reasons the Deferral Makes the Audit Job Harder, Not Easier

Three reasons the deferral is harder on auditors, not easier.

First, the harmonized standards under EN ISO/IEC 42001 and the related CEN-CENELEC work are not yet published. The original timeline was always going to compress because organizations would have had to comply against drafts. The new timeline gives the standards bodies room to finish, which means auditors will be measured against a more demanding final text, not the simpler interim text. The bar moved up, not down.

Second, regulators in member states will use the extra time to staff up and write enforcement playbooks. The first enforcement actions after December 2027 will be more deliberate and better-resourced than first actions would have been in 2026. The early cases will set precedent. A weak audit program is a worse defense in 2028 than it would have been in late 2026.

Third, your competitors will use the extra time. The organizations that get this right will start the clock now. The organizations that read the news as relief will resurface in mid-2027 with eighteen months of catch-up to do. Auditors who can credibly evaluate AI governance programs will be the constraint between those two outcomes. There will not be enough of them.

What the AAIA Exam Actually Tests on This

If you have read this article and felt you understood about half of it, that is the AAIA gap. The exam is designed to verify that you can do the work this regulation now requires. ISACA wrote it that way on purpose.

ISACA's Advanced in AI Audit (AAIA) credential is the certification built around exactly this body of knowledge. Domain 1 (AI Governance and Risk, weighted 33%) tests regulatory awareness directly, with the EU AI Act as a primary reference. Domain 2 (AI Operations, 46%) tests the operational reality of Articles 10 through 15 in practice: bias testing, drift detection, MLOps controls, model lifecycle. Domain 3 (AI Auditing Tools and Techniques, 21%) tests the audit response.

For a deeper read on where IT auditors stumble inside the exam, see the AAIA Exam Domains Explained guide. For the bridge from CISA to AAIA, see From CISA to AAIA in 90 Days.

A Realistic Audit Roadmap to December 2027

The new high-risk deadline is December 2, 2027. That gives you nineteen months. A serious audit team can spend that runway in three phases.

• Q3 2026 — Inventory and Classification: Build a list of every AI system your organization operates, sources from a vendor, or integrates into a customer-facing product. For each one, classify it under Article 6 and the relevant Annex. Document the basis for the classification. Where the derogation under Article 6(3) is invoked, capture the evidence and prepare the Article 49(2) registration. The deliverable is a defensible high-risk AI register. In my experience reviewing enterprise AI programs, most organizations cannot produce one on request. That gap is the first finding on every Article 9 engagement I have run.
• Q4 2026 through Q2 2027 — Gap Analysis and Remediation: Walk the high-risk register through Articles 9 through 15 and Article 26. For each control objective, document the existing evidence, the gap, and the owner. Use NIST AI RMF as the structuring framework. Use ISO 42001 to structure the management-system controls. Build the remediation backlog with named owners and quarterly checkpoints. The gap analysis phase typically runs longer than planned because the inventory phase surfaces systems that were not on anyone's radar.
• Q3 2027 through Deadline — Sustained Operation and Dry Run: Close the documentation gaps first. Logging and technical documentation are the cheapest fixes and the ones the regulator will ask about first. Then move to bias testing, robustness testing, and human oversight design. Stand up post-market monitoring under Article 72 if your organization is a provider, or input monitoring under Article 26 if it is a deployer. Run a dry-run audit in Q3 2027 — three months before the deadline — to find what is broken with time to fix it. Three months is not much runway if the dry run surfaces a documentation gap in Article 11 or a logging failure in Article 12.

One deadline does not get nineteen months. Article 50(2) transparency for generative AI applies from December 2, 2026. If your organization deploys generative AI in customer-facing products, that work has to happen first.