The EU AI Act for AI auditors and the AAIA

For an AI auditor, the EU AI Act is the clearest source of criteria there is: binding law, with obligations attached to named roles and risk tiers. ISACA's AAIA exam content outline names no law, but its topic on "Leading Practices, Ethics, Regulations, and Standards for AI" and its task on evaluating AI policies "including compliance with legal and regulatory requirements" make regulation part of the job, and the Act comes up in 12 of our 18 AAIA lessons. This guide reads the Act as an auditor uses it: who holds which duties, how a system's tier is decided, which articles turn into evidence requests, what deployers owe, and the dates as amended in July 2026.

The short answer

• Two roles carry most of the duties. A provider develops an AI system, or has it developed, and puts it on the market or into service under its own name; a deployer uses an AI system under its own authority.
• The tier decides the obligations. High-risk systems carry the heaviest duties, and a system listed in Annex III is high-risk unless a narrow exception applies, which never covers profiling.
• The high-risk duties are an evidence list. A risk management system, data governance, technical documentation, logs, transparency to deployers, human oversight, and accuracy, robustness and cybersecurity, with a quality management system behind them.
• Deployers have duties of their own, from staffing oversight to keeping logs for at least six months.
• Serious incidents have deadlines: 15 days at most, 10 after a death, 2 for a widespread infringement or a critical-infrastructure disruption.
• The high-risk rules apply from December 2, 2027 for Annex III systems and August 2, 2028 for Annex I systems, dates the Digital Omnibus set.

Why the Act matters to an AI auditor

An audit finding is a gap between what is and what should be, and the strongest statement of what should be is a law that applies to the organization. The Act gives an AI auditor that: obligations stated in articles, tied to roles and risk tiers, with fines behind them. Where it applies, it is criteria an organization cannot opt out of, unlike a voluntary framework.

It also needs care, because the Act applies to some systems and some roles and not others, and its dates have moved. An auditor who applies the wrong obligation, or applies it before it is in force, writes a finding that will not stand. The rest of this guide follows the order in which an auditor has to settle those questions.

Our EU AI Act guide for AAISM candidates reads the same text for a security manager, with Article 15's cybersecurity duties in depth, and our EU AI Act guide for the AIGP and EU AI Act timeline cover the rest of the Act for governance professionals. This guide does not repeat them.

First, the role: provider or deployer

The Act assigns duties by role, so the first audit question is which role the organization holds for each system. A provider is the one that develops an AI system, or has one developed, and "places it on the market or puts the AI system into service under its own name or trademark". A deployer is one "using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity".

Most organizations an AI auditor reviews are deployers of systems bought from vendors, and some are providers of systems they built. Many are both, for different systems. The distinction matters because buying a system moves the provider's duties to the vendor, not the deployer's: an organization that uses a vendor's high-risk system under its own authority still owes the deployer's obligations itself.

Second, the tier: is the system high-risk?

The Act's heaviest duties apply to high-risk systems, and classification is where an audit can find its most consequential error. Annex III lists the high-risk uses, among them recruitment and the screening of job applications, credit scoring, life and health insurance pricing, and emergency patient triage. A system used for one of them is high-risk unless an exception in Article 6(3) applies: an Annex III system "shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons", for example where it only performs a narrow procedural task.

Two limits on that exception matter to an auditor. It never covers profiling: a system "shall always be considered to be high-risk where the AI system performs profiling of natural persons." And it has to be documented in advance: "A provider who considers that an AI system referred to in Annex III is not high-risk shall document its assessment before that system is placed on the market or put into service."

So an auditor who finds an Annex III use recorded as "not high-risk" asks for that assessment. If none exists, the classification has nothing behind it; if the system profiles people, the classification is simply wrong. Either way, the obligations that follow from the higher tier may never have been applied, which makes misclassification a root-cause finding rather than one gap among many.

Third, the high-risk duties as an evidence list

For a provider of a high-risk system, the requirements in Chapter III read almost directly as an auditor's request list. In the Act's words, or close to them:

Each row is a document or a control the auditor can ask to see and test: the risk management records, the data governance evidence, the technical documentation, the logging design, the instructions for use, the oversight design, the test results, the quality management system. Two more duties continue after release: providers "shall establish and document a post-market monitoring system", and they report serious incidents (below).

The deployer's own duties

A deployer of a high-risk system cannot point to its vendor for everything. Article 26 sets out what it owes, and each duty is testable:

• Oversight by the right people. "Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support." An auditor tests not just that someone reviews outputs, but that they are trained and able to act.
• Input data. Where the deployer controls the input data, it "shall ensure that input data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system."
• Monitoring and stopping. Deployers monitor the system on the basis of the instructions for use. Where they have reason to consider that using it as instructed may present a risk, they inform the provider or distributor and the market surveillance authority without undue delay, and "shall suspend the use of that system".
• Logs. Deployers keep the logs the system generates, to the extent they control them, for a period appropriate to its purpose, "of at least six months", unless other law provides otherwise.

Some deployers also owe a fundamental rights impact assessment before first use: under Article 27, "deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III", which are credit scoring and life and health insurance pricing.

Serious incidents and their deadlines

Article 73 gives incident reporting fixed outer limits, which an auditor can test against an incident log. A provider reports a serious incident "not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident"; in the event of a death, "not later than 10 days"; and for a widespread infringement or a "serious and irreversible disruption of the management or operation of critical infrastructure", "not later than two days". An incident procedure that has no route to the authorities, or that starts the clock at the end of an internal investigation rather than at awareness, fails these criteria on paper before any incident happens.

The dates, after the Digital Omnibus

Regulation (EU) 2026/1744 changed when parts of the Act apply. As the consolidated text's Article 113 now stands:

For an auditor, the dates decide whether a gap is a finding today or a readiness point. An Annex III system without technical documentation in 2026 is not yet in breach of Article 11, which applies to it from December 2, 2027. Reporting it as a readiness gap, with the date, is accurate; reporting it as a breach is not. Systems placed on the market or put into service before that date need a second check: under Article 111, the Regulation applies to their operators "only if, as from that date, those systems are subject to significant changes in their designs", while providers and deployers of high-risk systems intended to be used by public authorities must comply by August 2, 2030.

AI literacy and fines

Article 4, as amended, asks less than it did: providers and deployers "shall take measures to support the development of AI literacy of their staff", and "This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual." An auditor can still look for the measures, but not for a guaranteed outcome.

The fines explain why boards care. A banned practice can cost "up to EUR 35 000 000 or, if the offender is an undertaking, up to 7 % of its total worldwide annual turnover for the preceding financial year, whichever is higher", and most other breaches, including a provider's obligations under Article 16, up to EUR 15 million or 3%.

How the Act meets the AAIA's outline

The outline's task to "Evaluate the organization's AI policies and procedures, including compliance with legal and regulatory requirements" is where the Act enters most directly, and topic 1E covers regulation as a whole. But the Act runs through the operations domain too: logging and oversight are supervision questions, incident deadlines are incident-response questions, and documentation is a lifecycle question. Our lessons use the Act where it supplies the criteria, and give its high-risk dates as the Digital Omnibus set them.

How the Act shows up in a question

AAIA questions on regulation usually test whether you can tell whose duty something is, not whether you can quote an article:

Where to start

The Act is long, but an auditor needs a small part of it well: roles, tiers, the high-risk duties as evidence, and the dates. Our AAIA lessons on regulation, data, supervision and incident response teach those parts as criteria, with questions that test the judgment. A free account opens AI models and requirements in full, lessons, questions and flashcards; full access is a single payment with nothing to renew. For the frameworks an organization adopts voluntarily, see the NIST AI RMF for AI auditors.