How to Run an AI Compliance Audit: Scope, Frameworks, Gaps

An AI compliance audit is a structured review that checks your AI systems against a named framework, gathers evidence that the controls actually work, and writes up the gaps before a regulator or a buyer finds them. Done properly, it maps every system to its legal obligations, tests the controls, and leaves you with documentation you can hand to a board, a notified body, or an enterprise procurement team. Here's how to run one.

What does an AI compliance audit actually check?

An auditor isn't grading your AI on whether it's clever. They're checking whether you can prove three things: that you know what your AI systems do, that you've put controls around the risky ones, and that those controls hold up under inspection.

That breaks into a few concrete areas:

• System inventory and risk classification. A list of every AI system in use, what each one decides, and which risk tier it falls into. The EU AI Act sorts systems into prohibited, high-risk, limited-risk, and minimal-risk. Most audit failures start here, with a system nobody catalogued.
• Governance and accountability. Who owns each system, who signs off changes, and how incidents get escalated. Named people, not a committee that meets twice a year.
• Data and privacy. Where training and inference data comes from, lawful basis under GDPR, retention, and whether you ran a data protection impact assessment.
• Bias and performance testing. Evidence the system was tested across the groups it affects, plus monitoring for drift after launch. One test at launch isn't enough.
• Technical documentation. The record of how the system was built, trained, and validated. For EU high-risk systems this is a legal requirement, not a nice-to-have.
• Human oversight and transparency. Whether a person can intervene, and whether affected people know AI is involved.

The auditor's job is to find the daylight between what your policies say and what your systems actually do. That gap is where the risk lives.

Which frameworks should an AI compliance audit map to?

You don't pick one. You map your systems to whichever apply, and most regulated businesses end up touching all three of the below. This is the part most internal teams get wrong, so it's worth slowing down here.

Framework	What it is	Status	Best for
EU AI Act	Binding law for AI placed on the EU market	Mandatory, phasing in 2025 to 2027	Anyone selling to or operating in the EU
ISO/IEC 42001	AI management system standard, certifiable	Voluntary, certifiable by accredited bodies	Proving governance maturity to buyers and regulators
NIST AI RMF	Voluntary risk framework, four functions	Voluntary, widely referenced	Structuring internal risk work, US-facing organisations

The EU AI Act is the one with teeth

The EU AI Act entered into force on 1 August 2024 and phases in over three years. The dates that matter:

• 2 February 2025: bans on prohibited practices and AI literacy obligations took effect.
• 2 August 2025: obligations for general-purpose AI models began.
• 2 August 2026: most high-risk system obligations apply, including the Annex III categories like employment, credit scoring, and biometrics.
• 2 August 2027: high-risk AI embedded in already-regulated products applies.

For high-risk systems, the Act requires a conformity assessment before the system goes to market. Article 43 gives providers two routes: internal control under Annex VI, or assessment by a notified body under Annex VII. Pass it and you affix a CE marking. An audit that ignores conformity assessment for a high-risk system has missed the point.

The penalties are steep enough to change how a board thinks about this. Under Article 99, breaching the prohibited-practices rules can cost up to €35 million or 7% of total worldwide annual turnover, whichever is higher. Most other breaches run to €15 million or 3%, and giving incorrect information to authorities up to €7.5 million or 1%. For an SME, the lower of the percentage or the fixed sum applies.

ISO/IEC 42001 is how you prove governance

ISO/IEC 42001, published in December 2023, is the first international standard for an AI management system. It runs on the Plan-Do-Check-Act cycle that ISO 9001 and ISO 27001 use, so if you already hold those, the structure is familiar. You can be certified against it by an accredited body, which gives you something concrete to show a sceptical buyer.

A development worth noting: ISO/IEC 42006, published on 7 July 2025, sets the rules for the bodies that audit and certify against 42001. It builds on ISO/IEC 17021-1. In plain terms, the people certifying your AI management system now have a competence standard of their own, so a 42001 certificate carries more weight than it did a year ago.

NIST AI RMF structures the internal work

The NIST AI Risk Management Framework, released on 26 January 2023, is voluntary and organises risk work into four functions: Govern, Map, Measure, and Manage. Govern runs across the other three. It won't satisfy a European regulator on its own, but it's a sensible scaffold for the day-to-day risk work that feeds an EU or ISO audit. We cover it in depth in our NIST AI RMF implementation guide.

How do you run an AI compliance audit, step by step?

A workable audit has four phases. Skip the scoping and you'll test the wrong things thoroughly.

Phase 1: Scope and inventory. List every AI system, including the ones embedded in tools you bought rather than built. Classify each against the EU AI Act risk tiers. Note which jurisdictions each system operates in, because obligations shift by geography. This phase alone surfaces systems nobody knew counted as AI.

Phase 2: Map obligations to controls. For each system, write down the specific obligations it triggers, then the control that's meant to satisfy each one. This produces a matrix of requirement against evidence. Empty cells are your gap list before you've tested anything.

Phase 3: Collect and test evidence. Pull the actual artefacts. Technical documentation, bias test results, data protection impact assessments, incident logs, sign-off records, monitoring dashboards. Then check the controls work, not just that a policy exists describing them. A policy with no logs behind it is a finding.

Phase 4: Report and remediate. Rank findings by severity and regulatory exposure. Each gets an owner, a fix, and a date. The report has to read for two audiences: the engineers who'll fix it and the executives who'll sign the budget.

What gaps do AI compliance audits find most often?

Across the systems we review, the same handful of gaps come up again and again. None of them are exotic. They're the boring stuff that gets deferred.

• The shadow inventory. Teams using AI through a SaaS tool, an API, or an embedded feature that never made the official list. You can't audit what you haven't found.
• Documentation that exists for engineers but not for regulators. Plenty of technical detail, no business-readable record of what the system does, why, and what it's been tested against. EU technical documentation requirements are specific, and generic README files don't meet them.
• Bias tested once, never again. A fairness check at launch, then nothing. Models drift, data shifts, and a system that was fair in March can skew by September with no monitoring to catch it.
• Human oversight on paper only. A policy says a human reviews decisions, but in practice the volume makes real review impossible. Auditors check whether oversight is genuine.
• No incident path for AI-specific failures. Existing security playbooks assume traditional breaches. Bias incidents, model poisoning, and adversarial inputs need their own response steps.

The pattern underneath all of these: organisations treat AI compliance as a document exercise when it's an evidence exercise. The question is never "do you have a policy." It's "show me it working."

Should you run the audit internally or bring in an outside reviewer?

Honest answer: internal teams are fine for ongoing monitoring and low-risk systems, and a bad fit for anything you'll have to defend. Two reasons. First, you can't credibly audit systems your own team built and signed off. The conflict is structural, not a question of integrity. Second, mapping a system to the EU AI Act and ISO/IEC 42001 at the same time takes specialist knowledge most internal teams don't have yet, because the field is barely two years old.

The sensible split: run continuous internal monitoring against a framework like NIST AI RMF, and bring in independent review for high-risk systems, for conformity assessment prep, and before any external certification. The independence is the point. A regulator or an enterprise buyer weights an outside opinion far more heavily than your own.

This is the work VerityAI does as a Responsible AI advisory. We review high-risk systems against the EU AI Act, ISO/IEC 42001, and NIST AI RMF, and leave clients with documentation that holds up under inspection. Not a tool you run yourself. A reviewed, defensible position.

Frequently asked questions

How long does an AI compliance audit take?

It depends entirely on scope. A single high-risk system mapped to the EU AI Act can be reviewed in a few weeks. A full portfolio across multiple jurisdictions, with conformity assessment prep, runs longer. The scoping phase tells you, which is why it comes first. Anyone quoting a fixed timeline before seeing your inventory is guessing.

Is an AI compliance audit a legal requirement?

The audit itself is not named in law, but the obligations it checks are. For EU high-risk systems, the conformity assessment under Article 43 is mandatory before market entry, and the technical documentation behind it is required. An audit is how you get ready for that and how you prove you stayed ready.

What's the difference between ISO/IEC 42001 certification and an EU AI Act audit?

ISO/IEC 42001 certifies that you run a sound AI management system, and it's voluntary. The EU AI Act is binding law with conformity assessment and penalties attached. A 42001 certificate helps demonstrate maturity and supports your Act compliance, but it doesn't replace the Act's specific requirements for high-risk systems.

Who carries out an AI compliance audit?

Internal risk or compliance teams handle routine monitoring. For high-risk systems and formal certification, the work goes to independent reviewers, and for ISO/IEC 42001 certification specifically, to a body accredited under ISO/IEC 42006. That accreditation is what makes the certificate credible.

The bottom line

Most AI compliance audits fail in the first phase, not the last. The system nobody catalogued, the tool bought with AI baked in, the model running in a region with its own rules. Get the inventory and the risk classification right and the rest is methodical. Get them wrong and you'll test the wrong things with great precision.

My view: treat the EU AI Act dates as fixed deadlines, not aspirations. High-risk obligations land on 2 August 2026, and conformity assessment isn't something you start the week before. The organisations that handle this well started mapping their systems in 2025 and built the evidence trail as they went. The ones that wait will be assembling documentation under pressure while a regulator or a buyer waits for an answer. Start with the inventory. Everything else follows from knowing what you actually have.

For the board-level view, see VerityAI's AI compliance audits for healthcare.

For hands-on help, see VerityAI's our AI governance practice.