The EU AI Act for AAISM candidates

The EU AI Act, Regulation (EU) 2024/1689, is the EU's regulation "laying down harmonised rules on artificial intelligence", and it changed in July 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the high-risk rules to December 2, 2027 for the systems listed in Annex III and to August 2, 2028 for AI in regulated products, added two prohibitions from December 2, 2026, and rewrote the AI literacy duty. The security core did not change: Article 15 requires high-risk AI systems to resist attacks such as data poisoning and adversarial examples, Articles 12 and 26 make logs a legal record, and Article 73 puts deadlines on serious incident reports. This guide covers what the Act regulates, its dates after the Omnibus, the articles a security manager owns, the fines, and how it meets ISACA's AAISM outline.

The short answer

• What it regulates: AI by risk, in four layers: banned practices, high-risk systems, transparency duties, and rules for general-purpose AI models.
• Who it binds: mainly providers, who develop AI and put it on the market under their own name, and deployers, who use AI systems under their authority.
• The security core: Article 15 on accuracy, robustness and cybersecurity, logs under Articles 12 and 26, serious incident reports under Article 73, and cybersecurity duties for general-purpose models with systemic risk under Article 55.
• The dates after the Omnibus: high-risk rules from December 2, 2027 (Annex III) and August 2, 2028 (Annex I); two new bans from December 2, 2026.
• The fines: up to EUR 35 million or 7% of worldwide annual turnover for banned practices, and up to EUR 15 million or 3% for most other duties.

Is the EU AI Act on the AAISM exam?

ISACA's outline names no law. It does name the work: topic 1A is "Stakeholder Considerations, Industry Frameworks, and Regulatory Requirements", and the tasks include "Conduct AI impact assessments and ensure conformity with regulatory requirements" and incident processes run "in accordance with regulatory and contractual requirements". The AI Act is a concrete, detailed set of AI-specific requirements, which is why our course teaches it.

ISACA's guide says its questions are "developed with the intent of measuring practical knowledge and the application of general concepts and standards". So expect scenarios about what a security manager should do when a law applies, not questions on article numbers.

The Act in brief

The Act regulates by risk:

• Prohibited practices (Article 5). Practices the EU bans outright, among them manipulative or deceptive techniques that cause significant harm, social scoring that leads to unjustified or unrelated detrimental treatment, and, outside narrow exceptions, real-time remote biometric identification in public spaces for law enforcement.
• High-risk AI systems (Article 6). AI that is a safety component of a product covered by the EU laws in Annex I, or is such a product, where that product needs a third-party conformity assessment; and AI used in the areas Annex III lists: biometrics, critical infrastructure, education, employment, essential private and public services, law enforcement, migration and border control, and the administration of justice and democratic processes. These carry the heaviest duties.
• Transparency (Article 50). People must be told when they are interacting with an AI system, and providers of systems that generate synthetic audio, images, video or text must ensure the outputs are marked "in a machine-readable format and detectable as artificially generated or manipulated".
• General-purpose AI models (Chapter V). Documentation and copyright duties for every provider, and more for models with systemic risk.

Two roles matter most. A provider develops an AI system or model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer is a body "using an AI system under its authority". Most enterprises are deployers of most of their AI, and providers of what they build.

The dates, after the Omnibus

The Omnibus did not delay everything. The bans have applied since February 2025, the rules for general-purpose models since August 2025, and the transparency duties since August 2026. What moved is the high-risk regime, and with it the duties that attach to high-risk systems. High-risk systems already on the market before their date are caught only if their design changes significantly afterward, except those meant for public authorities, which must comply by August 2, 2030.

What a security manager owns

Article 15: accuracy, robustness and cybersecurity

High-risk AI systems must be designed so that they "achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle". They must be "resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities", and the technical solutions must include, where appropriate, measures against "attacks trying to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws".

That sentence is the closest the law comes to an AI threat model, and it lines up with the catalogs: poisoning, evasion and confidentiality attacks all have techniques in MITRE ATLAS, and poisoning is an entry in the OWASP LLM Top 10. Article 15 also asks for resilience against errors and faults, which "may be achieved through technical redundancy solutions, which may include backup or fail-safe plans", and, for systems that keep learning after release, controls on feedback loops.

Logs: Articles 12 and 26

High-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system". Deployers keep the logs under their control for a period suited to the system's purpose "of at least six months", unless other EU or national law says otherwise. For a security manager, those logs are evidence with a legal floor, and a retention setting under six months is a compliance gap.

Deployers: monitor, suspend, report

Deployers monitor the system against its instructions for use. If they have reason to think it presents a risk, they inform the provider or distributor and the market surveillance authority "without undue delay" and suspend its use. When they identify a serious incident, they "immediately inform first the provider", then the importer or distributor and the authorities.

Serious incidents: Article 73

A serious incident is one that leads, directly or indirectly, to a death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of EU law protecting fundamental rights, or serious harm to property or the environment. Providers report it to the market surveillance authority once they establish a causal link, or its reasonable likelihood, and no later than 15 days after becoming aware of it; within two days for a widespread infringement or a critical-infrastructure disruption; and within 10 days where a person has died. An incomplete first report is allowed.

One rule speaks directly to incident responders: the provider "shall not perform any investigation which involves altering the AI system concerned in a way which may affect any subsequent evaluation of the causes of the incident, prior to informing the competent authorities of such action". Preserve first, then fix. Article 73 has applied since August 2, 2026, but it concerns high-risk AI systems, and the rules that classify a system as high-risk apply from the dates above.

General-purpose models with systemic risk: Article 55

Providers of these models must evaluate them with "adversarial testing of the model with a view to identifying and mitigating systemic risks", report serious incidents to the AI Office "without undue delay", and "ensure an adequate level of cybersecurity protection for the general-purpose AI model with systemic risk and the physical infrastructure of the model". If you use such a model through a vendor's API, those are your vendor's duties, which is why they belong in your vendor review.

AI literacy: Article 4, rewritten

Providers and deployers "shall take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf". The Omnibus's version adds that this "does not require providers or deployers to guarantee any specific level of AI literacy of any individual". For a security manager, the awareness program and its records are the measures.

Sensitive data for bias detection: Article 4a, new

The Omnibus moved and widened the rule on special categories of personal data, such as ethnicity or health data. Providers of high-risk systems may process them "to the extent strictly necessary" to detect and correct bias, and so may other providers and deployers, under the same safeguards, where the biases at stake could harm health, safety or fundamental rights or lead to unlawful discrimination. Either way, only if the job "cannot be effectively fulfilled by processing other data, including synthetic or anonymised data", and only with "state-of-the-art security and privacy-preserving measures, including pseudonymisation", strict and documented access controls, no transfer to other parties, and deletion once the bias is corrected or the retention period ends.

The new bans and generative guardrails: Article 5

From December 2, 2026, Article 5 also bans AI systems that generate or manipulate realistic intimate or sexually explicit images, video or audio of an identifiable person without that person's explicit consent, and systems that generate child sexual abuse material. For providers, the ban turns on safeguards: a system is caught when such output is its intended purpose, or is a "reasonably foreseeable and reproducible outcome" and the system lacks "reasonable and adequate technical safety measures and other safeguards". That makes generative guardrails, and evidence that they work, a legal matter, not only a reputational one.

Fines: Article 99

Member States set the penalties, within ceilings:

• up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher, for banned practices;
• up to EUR 15 million or 3% for breaches of most operator duties, deployers' Article 26 duties and the Article 50 transparency duties among them;
• up to EUR 7.5 million or 1% for supplying incorrect, incomplete or misleading information to authorities.

For SMEs, including start-ups, each fine is capped at whichever of the two figures is lower, and the Omnibus extends that to small mid-cap enterprises (SMCs) for the second and third tiers.

How the Act meets the AAISM outline

ISACA's outline does not mention the AI Act, so this mapping is ours:

Learning the AI Act with QualExam

Our AAISM course teaches the Act where a security manager needs it: it appears in 33 of the 63 lessons. Lesson 1A/04, Global AI Regulation: The EU AI Act and Beyond, covers the risk tiers, the roles, the new bans and the deferred dates, and it sits in the first topic, which a free account opens in full. The incident lesson 1E/03 teaches the Article 73 clocks, and the awareness and training lessons teach the rewritten Article 4. Full access is a single payment, with nothing to renew. For the framework side, see the NIST AI RMF for AAISM candidates.