EU AI Act Compliance Audit: Checklist & Preparation Guide

Preparing for an EU AI Act compliance audit is not a matter of downloading a generic checklist and asking whether each policy exists.

The first questions are more fundamental: Which AI systems are in scope? What role does the organization have for each system? What is the system's intended purpose and risk classification? Which requirements apply to that particular combination, and from what date?

Those questions determine the audit scope. A provider of a high-risk AI system, a company deploying a third-party recruitment system, and a provider of a general-purpose AI (GPAI) model can have materially different obligations. The same organization can also be a provider for one AI system and a deployer for another.

A useful audit therefore tests more than documentation. It connects each applicable requirement to a control, identifies who owns that control, examines evidence that it exists and operates, records gaps, and verifies remediation.

The timing must also be current. Regulation (EU) 2024/1689 was materially amended in 2026 by the Digital Omnibus on AI, Regulation (EU) 2026/1744. The amendments changed important provisions and postponed the application of core high-risk requirements. The European Commission's current AI Act implementation timeline now runs through 2 August 2028.

Regulatory status: This article was reviewed on 24 September 2026 against the current consolidated AI Act, Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, and current European Commission implementation materials.

The sections below show how to move from scope → applicable obligations → control testing → evidence → findings → remediation → ongoing audit readiness.

What Is an EU AI Act Compliance Audit?

An EU AI Act compliance audit is a structured assessment of whether the AI Act requirements applicable to an organization and its AI systems have been translated into effective controls and whether the organization can demonstrate those controls through reliable evidence.

The Regulation does not prescribe one universal internal-audit methodology or require every organization to conduct an annual “EU AI Act audit.” What must be assessed depends on the AI system, intended purpose, regulatory role, classification, and application date.

For the wider regulatory framework, see AGC's guide to EU AI Act compliance.

In practice, four exercises should be distinguished:

• A compliance audit tests compliance with applicable legal requirements and the controls intended to satisfy them.

• A readiness assessment examines whether the organization is prepared for requirements that apply now or will apply at a defined future date.

• A gap assessment compares the current control environment with the required or target state.

• A technical AI audit tests technical properties such as performance, robustness, data quality, security or bias. Technical testing may support legal compliance, but it does not by itself establish AI Act compliance.
  

A strong audit works from requirement to control to evidence. A statement such as “we have human oversight” is not enough. The auditor should be able to identify who performs that oversight, what authority the person has, what information they receive, how intervention works, and what records demonstrate that the process operates.

Start With Scope: Determine Which AI Systems and Obligations Apply

Organizations should resist the temptation to start with a 100-question compliance checklist. First establish the population being audited.

Build an AI system inventory

An AI inventory is an audit-management control rather than a universally prescribed AI Act template. Its purpose is to create a reliable population against which scope, classification and obligations can be assessed.

For each system, the inventory should normally capture:

• system or product name;

• business purpose and intended purpose;

• internal system owner;

• relevant provider, model provider and vendors;

• the organization's regulatory role;

• users and potentially affected persons;

• deployment environment;

• countries or regulatory contexts in which it is used;

• relevant AI components and model dependencies;

• available legal, technical, contractual and governance documentation;

• current version and lifecycle status; and

• material changes since the last assessment.

The inventory should distinguish different uses of the same technology. A GPAI-based tool used for internal drafting and a customer-facing system built on the same underlying model may create different classification, transparency and control questions.

Determine the organization's role

The AI Act defines several operators, including providers, deployers, importers and distributors. GPAI model providers have additional obligations under Chapter V. The definitions and responsibilities should be assessed against the current consolidated EU AI Act, rather than assigned purely from contractual terminology.

One organization may occupy different roles for different systems.

Role analysis also needs to consider changes over time. Under Article 25, certain distributors, importers, deployers or other third parties can assume provider responsibilities for high-risk systems where, for example, they place their name or trademark on the system, substantially modify it, or change its intended purpose in a way that makes it high-risk.

An audit should therefore test the actual operating model, not merely ask what the vendor contract calls each party.

Map each system to its risk category

Classification should determine whether the system potentially involves:

• a prohibited AI practice under Article 5;

• a high-risk system under Article 6 and Annex I or Annex III;

• transparency obligations under Article 50;

• GPAI model obligations; or

• an AI system outside those specific categories.

For Annex III systems, the analysis should also address the Article 6(3) conditions under which certain systems listed in Annex III may nevertheless not be considered high-risk. Providers relying on that route must document the assessment, and profiling systems within the relevant Annex III pathway remain high-risk.

For the Annex I route, the 2026 amendments also refined the concept of a safety component and the interaction with product-sector conformity rules. That is another reason not to rely on pre-2026 classification summaries.

Record the conclusion, legal basis, intended purpose, relevant assumptions, evidence considered, reviewer and date. That classification record becomes a key audit artifact.

Check the Current EU AI Act Compliance Timeline

The Digital Omnibus changed dates that still appear in many older compliance resources. The Commission's official implementation timeline should be checked before a readiness assessment is finalized.

The amended dates are set out in the Digital Omnibus on AI and reflected in the Commission's current implementation timeline.

Legacy systems also require separate analysis. Article 111 contains transitional provisions for certain high-risk systems placed on the market or put into service before the relevant high-risk requirements apply, including rules linked to significant changes in their designs. Do not assume that every existing system follows the same transition pathway.

EU AI Act Compliance Audit Checklist

The following is an audit framework, not a statement that every control applies to every AI system. A broader business-focused EU AI Act compliance checklist can be used alongside this audit-specific approach.

1. Governance and accountability

Determine who owns AI Act compliance at the organizational, system and control levels.

Test whether there are defined responsibilities for classification, approval, monitoring, incidents, vendor management, documentation updates and regulatory escalation. Review policies, governance minutes, approval records and evidence of actual decision-making.

Article 4 now requires providers and deployers to take measures to support the development of AI literacy among relevant staff and other people dealing with AI systems on their behalf. The 2026 amendment expressly states that organizations do not have to guarantee a specific level of AI literacy for each individual. The Commission's current AI literacy guidance reflects that amended standard.

For audit purposes, ask what measures were selected, which roles they cover, why they are appropriate and what evidence demonstrates implementation.

2. AI inventory and scope

Test the completeness of the inventory rather than accepting it at face value.

Reconcile it, where appropriate, against procurement records, software inventories, AI/model accounts, architecture records and interviews with business owners.

For sampled systems, confirm that the inventory accurately records intended purpose, owner, vendor, role, deployment context, classification and lifecycle status.

3. Risk classification

For each sampled system, review whether the organization has documented:

• Article 5 prohibited-practice screening;

• Article 6 and Annex I/Annex III analysis;

• any reliance on Article 6(3);

• Article 50 applicability;

• GPAI considerations where relevant; and

• the rationale and evidence supporting the conclusion.

A classification should also have a change trigger. If the intended purpose, model, functionality or deployment context changes materially, the original determination may no longer be reliable.

4. Risk management

Where the high-risk requirements apply, Article 9 requires a risk-management system that is established, implemented, documented and maintained as a continuous lifecycle process. It covers identification, evaluation and mitigation of relevant risks, residual risk and testing.

Audit evidence may include risk registers, test plans, validation results, mitigation decisions, residual-risk approvals and links to post-market information.

Distinguish:

Design effectiveness: Is there a process capable of identifying and treating applicable risks?

Operating effectiveness: Can the organization show that the process was actually performed for the system being audited?

5. Data and data governance

For applicable high-risk systems, examine the requirements under the current Article 10 rather than assuming every AI use requires the same data-governance controls. The 2026 Digital Omnibus amended Article 10, including its treatment of training, validation and testing datasets.

Where relevant, assess evidence concerning:

• data origin and collection;

• preparation and labelling;

• relevance and suitability;

• representativeness;

• documented assumptions;

• bias detection and correction;

• data-quality issues; and

• the context in which the system will operate.

A deployer purchasing a finished system should not automatically be assessed against every provider-side development obligation. Test the duties that actually attach to that actor and system.

6. Technical documentation and records

For relevant high-risk providers, Article 11 requires technical documentation to be prepared before placing the system on the market or putting it into service and kept up to date so that compliance can be assessed.

An audit should examine:

• completeness;

• consistency with the production system;

• version control;

• traceability to testing and risk records;

• ownership;

• accessibility; and

• update processes.

Documentation that accurately described version 1.0 may be weak evidence for version 3.0 if significant technical changes were never incorporated.

7. Human oversight

For high-risk systems where the relevant requirements apply, Article 14 requires effective human oversight appropriate to the risks, autonomy and context of use. Relevant persons may need to understand system limitations, monitor operation, recognize automation bias, interpret outputs and, where appropriate, disregard, override or interrupt the system.

For deployers, Article 26 also addresses the competence, training, authority and support of persons assigned to oversight.

Do not accept “human in the loop” as sufficient evidence.

Test who has oversight, their system permissions, their authority, what instructions they receive, how exceptions are escalated and whether sampled records demonstrate that meaningful oversight actually occurs.

8. Transparency

Article 50 has applied since 2 August 2026, subject to a limited transition until 2 December 2026 for the Article 50(2) marking obligations of certain systems placed on the market before 2 August 2026. The Commission has also published current Article 50 transparency guidance and detailed Article 50 FAQs.

Depending on the use case, audit:

• disclosures when people interact directly with AI systems;

• machine-readable marking and detectability requirements for certain synthetic content;

• information provided to persons exposed to emotion-recognition or biometric-categorization systems;

• deepfake disclosures; and

• disclosures for AI-generated or manipulated text published to inform the public on matters of public interest.

Each obligation has its own scope and exceptions. Article 50 should not be converted into a blanket rule that “all AI content must be labelled.”

9. Logging, monitoring and incident management

High-risk systems must support appropriate automatic logging under Article 12 where the applicable high-risk provisions are in force. For providers and deployers, Articles 19 and 26 contain requirements concerning logs under their control, including an applicable minimum retention period of six months unless other Union or national law provides otherwise.

For applicable providers, also assess the post-market monitoring system under Article 72 and serious-incident processes under Article 73.

Test more than the incident policy. Inspect:

• monitoring outputs;

• incident classification decisions;

• escalation records;

• notification assessments;

• corrective actions; and

• evidence that corrective actions were verified.

10. Conformity assessment and registration

Conformity assessment, EU declarations of conformity, CE marking and registration are not universal requirements for every AI system.

Where the high-risk framework applies, determine the correct conformity route under Article 43. Most Annex III categories use internal control under Annex VI, while notified-body involvement can apply in specified circumstances. For systems within relevant Annex I product legislation, the 2026 amendments clarified the interaction between AI Act requirements and sectoral conformity procedures; inclusion of high-risk AI does not automatically require a notified-body route where the applicable product legislation permits another procedure and the amended conditions are satisfied.

Article 49 also contains registration requirements for defined providers, certain Article 6(3) determinations and specified public-sector deployers.

The audit file should show both the conclusion and the legal reasoning supporting the chosen route.

11. Fundamental rights impact assessment

Article 27 does not require every deployer or every AI system to undergo a fundamental rights impact assessment (FRIA).

Its scope covers specified deployers of certain Article 6(2)/Annex III high-risk systems, including bodies governed by public law, private entities providing public services and deployers of certain systems identified in Annex III points 5(b) and 5(c), subject to the Article's detailed scope and exclusions.

Where Article 27 applies, examine the assessment of:

• the deployment process;

• period and frequency of use;

• affected groups;

• specific fundamental-rights risks;

• human oversight;

• mitigation measures;

• governance arrangements; and

• complaint mechanisms.

The 2026 amendment also allows relevant material from GDPR or Law Enforcement Directive data-protection impact assessments to be cross-referenced or included in the FRIA where appropriate. It does not make a DPIA automatically equivalent to the FRIA.

For Annex III systems, the relevant high-risk requirements now apply from 2 December 2027.

12. Third-party and vendor compliance

A vendor's assurance should be treated as evidence to evaluate, not as a substitute for the organization's own role analysis.

Review:

• provider identity and contractual role;

• intended purpose;

• system and model dependencies;

• instructions for use;

• relevant classification information;

• technical and conformity documentation where applicable;

• incident-notification arrangements;

• responsibility allocation;

• material-change notifications; and

• evidence supporting vendor compliance claims.

Article 25 is particularly relevant because rebranding, substantial modification or changing intended purpose can, in defined circumstances, shift provider responsibilities. The Regulation also addresses written agreements between providers of high-risk systems and certain third-party suppliers concerning information, technical access and assistance.

For broader procurement and supply-chain considerations, see AGC's discussion of EU AI Act vendor compliance.

What Evidence Should You Prepare for an EU AI Act Audit?

Policies matter, but policies alone rarely prove that a control operates.

A useful evidence repository may include:

• AI inventory and system descriptions;

• scope and role determinations;

• classification records;

• requirement-to-system mappings;

• governance policies and decision records;

• AI literacy measures and participation records;

• risk assessments and treatment records;

• technical documentation;

• testing and validation outputs;

• human-oversight procedures and intervention records;

• transparency designs and test evidence;

• system logs and monitoring outputs;

• incident and escalation records;

• vendor documentation and contracts;

• conformity and registration records where applicable;

• FRIAs and related assessments where applicable; and

• remediation and closure records.

Evidence quality should also be assessed.

Weak evidence: a policy says a control should happen.

Stronger evidence: the organization can identify the control owner, show the procedure, produce dated records demonstrating operation, and explain how exceptions are handled.

Stronger still for recurring controls: representative samples show that the control operates consistently over time.

An evidence-to-control matrix creates that traceability:

This is a recommended audit tool, not an official European Commission template.

The practical reason for building this evidence architecture is regulatory as well as operational. Under Article 74, market-surveillance authorities can, where the legal conditions are met, obtain access to documentation and relevant development datasets for high-risk systems; access to source code is subject to narrower conditions and a reasoned request. An internal readiness assessment is not the same as a regulatory inspection, but evidence should be retrievable and explainable if competent authorities exercise their lawful powers.

Professionals who need a structured foundation in classification, roles, controls and evidence can use AGC's EU AI Act compliance training as part of their professional development. Training can strengthen capability, but it does not replace system-specific legal analysis, implementation or audit evidence.

How to Conduct an EU AI Act Compliance Audit Step by Step

Step 1: Define audit scope

Document:

• entities and business units;

• AI systems;

• jurisdictions;

• regulatory roles;

• applicable provisions;

• relevant application dates; and

• the audit period.

Record exclusions and their rationale.

A reviewer should be able to understand exactly what the audit covered and what it did not.

Step 2: Map applicable requirements

Build a requirement-to-system matrix.

For each AI system, map:

provision → applicability rationale → actor → control objective → control → owner → evidence → application date

This prevents a common audit error: testing the entire AI Act against every AI system regardless of role or classification.

Step 3: Test controls

For each applicable requirement, identify what the control should achieve and how evidence will be tested.

Testing can include:

• document inspection;

• record sampling;

• interviews;

• configuration inspection;

• walkthroughs;

• re-performance;

• examination of system outputs or logs; and

• comparison of written procedures with actual practice.

Always distinguish control design from control operation.

For example, a procedure requiring classification reassessment after a material change may be well designed. If two major model changes occurred and neither triggered a reassessment, the control did not operate effectively.

Step 4: Record gaps

A practical internal status scale might use:

• Missing

• Partially implemented

• Implemented

• Not applicable

• Requires legal interpretation

These are internal audit-management labels, not official EU classifications.

A useful finding identifies the criterion, observed condition, evidence reviewed, gap and likely impact.

Step 5: Assign remediation

Each finding should become a trackable action containing:

• finding;

• applicable requirement or control objective;

• impact;

• root cause where useful;

• remediation action;

• accountable owner;

• target date; and

• closure evidence.

A status change to “complete” should not be the closure evidence.

Step 6: Perform a follow-up review

Verify remediation rather than relying on an owner's completion statement.

Inspect revised documentation, configuration or records, repeat the relevant test and confirm that the original gap has been addressed.

Where risk remains, document the residual risk and the basis for further treatment or acceptance.

Common EU AI Act Audit Gaps to Look For

The following are examples of gaps an audit may identify; they are not presented as regulator-established statistics or as a definitive ranking of the most common failures:

• incomplete AI inventories;

• role classifications that do not reflect actual activities;

• outdated risk classifications after system changes;

• unsupported Article 6(3) conclusions;

• policies without operating evidence;

• technical documentation that does not match the production version;

• unclear or ineffective human oversight;

• inadequate vendor documentation;

• contracts that do not reflect operational responsibilities;

• missing model or vendor change controls;

• insufficient logging or monitoring;

• poorly defined AI incident escalation;

• Article 50 controls not mapped to actual use cases;

• impact assessments prepared too late in the lifecycle; and

• assuming GDPR compliance automatically demonstrates AI Act compliance.

GDPR work can support an AI Act audit in relevant areas, but the regimes remain distinct. The amended Article 27's ability to cross-reference relevant DPIA material is a good example of coordination rather than equivalence.

How to Turn Audit Findings Into an EU AI Act Compliance Implementation Plan

A readiness audit should create implementation work, not simply produce a red-amber-green dashboard.

AGC's broader guide to EU AI Act compliance implementation covers the wider implementation sequence; the audit team's role is to translate identified deficiencies into controlled remediation.

Prioritize findings

Prioritization can consider:

• whether the obligation already applies;

• proximity of the application date;

• legal and operational impact;

• potential effect on individuals;

• system criticality;

• severity of the control weakness;

• availability of evidence;

• technical complexity;

• external dependencies; and

• vendor lead times.

This prioritization is a management method, not an official AI Act scoring scheme.

Build a remediation roadmap

Establish continuous monitoring

Audit readiness degrades when the evidence file remains static while the AI system evolves.

Reassessment should be triggered where relevant by changes to:

• intended purpose;

• system functionality;

• underlying models;

• vendors;

• deployment context;

• applicable legislation or regulatory guidance;

• documentation;

• performance or monitoring results; or

• incident history.

Change management should connect product, procurement, engineering, legal, risk and AI governance processes so that relevant changes reach the compliance function before the audit file becomes obsolete.

EU AI Act Compliance Audit Checklist for Different Roles

The audit plan should reflect role-specific responsibilities. AGC's guide to EU AI Act compliance for professionals provides a broader view of how compliance teams can translate requirements into controls and assurance activity.

GPAI model-provider obligations have applied since 2 August 2025, although transitional provisions must still be checked for particular models and circumstances. Article 53 sets out core documentation and downstream-information obligations for relevant GPAI providers.

When Should You Perform an EU AI Act Compliance Audit?

The Regulation does not impose one universal annual audit frequency on all organizations.

Useful audit or readiness triggers include:

• before deploying or placing a relevant AI system on the market;

• before an applicable AI Act requirement takes effect;

• after a substantial or material system change;

• after a significant model or vendor change;

• following a serious incident or significant control failure;

• during scheduled AI governance reviews;

• before relevant transactions or due diligence;

• when a system's intended purpose changes; and

• before regulatory engagement where appropriate.

The appropriate frequency depends on the systems involved, applicable obligations, pace of change, control maturity, vendor dependencies and the organization's wider assurance framework.

What an EU AI Act Audit Report Should Contain

A useful report should allow a reviewer who did not participate in the audit to understand what was tested, what evidence was examined, what was found, and what happens next.

A practical report can include:

• executive summary;

• scope and exclusions;

• entities and AI systems assessed;

• relevant operator roles;

• applicable requirements and dates;

• methodology;

• sampling approach;

• evidence reviewed;

• findings;

• control-design and operating-effectiveness conclusions;

• gaps;

• internal risk or priority rating;

• remediation actions;

• accountable owners;

• target dates;

• closure evidence;

• follow-up requirements; and

• limitations, assumptions and unresolved legal interpretations.

Where a conclusion depends on a genuinely unresolved legal question, record that limitation rather than forcing an unsupported pass/fail decision.

EU AI Act Compliance Audit Checklist: Quick Review

The following is a practical audit-readiness checklist, not an official European Commission checklist.

• AI inventory completed and reconciled against relevant source records

• EU AI Act scope assessed

• Operator roles identified by system

• Intended purposes documented

• Prohibited-practice screening completed

• Risk classifications documented and approved

• Applicable requirements and application dates mapped

• Governance and control ownership assigned

• Article 4 AI literacy measures assessed

• Applicable high-risk controls reviewed

• Technical and governance documentation tested

• Human oversight tested where applicable

• Article 50 transparency controls tested where applicable

• Logging and retention requirements assessed

• Monitoring processes reviewed

• Incident procedures tested

• Vendor responsibilities and evidence reviewed

• FRIAs and other relevant impact assessments completed or planned where applicable

• Conformity-assessment route determined where applicable

• Registration requirements assessed where applicable

• Evidence linked to requirements and controls

• Control design and operation tested

• Gaps documented with supporting evidence

• Remediation owners and target dates assigned

• Closure evidence defined

• Follow-up testing scheduled

• Regulatory and system-change triggers established

Conclusion

A defensible EU AI Act compliance audit begins with scope. Build a reliable AI inventory, determine the organization's role for each system, document classification, identify the provisions and dates that actually apply, and then map those requirements to controls and evidence.

The strongest audit files do more than contain policies. They show what the organization decided, why it decided it, who owns the relevant control, how that control operates and what evidence demonstrates implementation.

Findings should then become a remediation roadmap with accountable owners, target dates and verifiable closure evidence. Audit readiness must remain dynamic as systems, models, vendors, intended purposes and regulatory requirements change.

That regulatory currency is especially important after the 2026 Digital Omnibus. Organizations should verify significant legal conclusions against the current consolidated AI Act and the European Commission's implementation timeline rather than relying on older deadline summaries.

For professionals who need structured knowledge of the Regulation, risk classification, provider and deployer responsibilities, documentation, evidence and practical implementation, AGC's EU AI Act Compliance Training provides a focused next step. Training can develop compliance capability; organizational compliance still depends on applying the relevant legal requirements to actual AI systems, implementing effective controls, maintaining evidence and verifying that those controls continue to work.