AI Audit Checklist for Enterprise AI Compliance

Key Takeaways

• An audit covers governance, data, privacy, security, documentation, human oversight, and monitoring — not just how well the model performs.
• A usable checklist item names four things: the control, the evidence that proves it exists, the test that verifies it operates, and what a failure looks like.
• Keep a living inventory of AI systems with owners, data sources, vendors, and applicable requirements. Everything else in an audit depends on this existing first.
• GDPR, the EU AI Act, ISO/IEC 42001, NIST AI RMF, HIPAA, and NIS2 don't apply uniformly — they scale with jurisdiction, sector, system risk, and your role.
• Test whether a control actually operates. A human-review policy that a workflow can technically bypass isn't a control — it's a document.
• Generative AI, AI agents, RAG pipelines, and unsanctioned "Shadow AI" tools each raise audit questions a standard model-validation checklist won't catch.
• Pseudonymized data usually still counts as personal data under GDPR. Only true anonymization takes it out of scope — don't treat the two as interchangeable.
• Findings need an owner, a deadline, and a retest date. An audit that ends at the report is half an audit.

An AI audit checklist is a working set of controls, evidence requirements, and test procedures for evaluating whether an AI system — or an entire enterprise AI program — is properly governed, documented, secured, and compliant. It goes well beyond model accuracy: a real audit looks at who owns the system, what data it touches, what legal basis covers that data, how the system is secured, whether a human can actually intervene when needed, and whether all of that can be proven with evidence rather than just described in a policy. What applies to your organization specifically depends on jurisdiction, sector, the system's risk classification, and your role as provider, deployer, or processor — so treat what follows as a comprehensive menu to scope from, not a uniform mandate.

This guide gives you something to actually run an audit against: 50+ checks across ten domains, the evidence auditors ask for, a control-evidence-test-finding method for verifying controls actually work (not just exist), and separate checklists for generative AI, AI agents, and third-party vendors.

Quick Checklist: 15 Essential Checks

1. AI system inventory — every model, tool, and embedded AI feature in use, including vendor SaaS with AI built in.
2. System ownership — a named business owner and technical owner for each system, not a department.
3. Intended use — a written statement of what the system does and who it affects.
4. Risk classification — each system rated against a chosen framework, with the reasoning documented.
5. Data flows — what data goes in, where it comes from, and where outputs land.
6. Lawful basis — a documented legal basis for any personal data the system processes.
7. Security controls — access control, encryption, and AI-specific defenses like prompt-injection testing.
8. Vendor risk — contracts and security posture reviewed for every AI vendor and subprocessor.
9. Documentation — architecture, training-data description, and known limitations kept current.
10. Human oversight — a review mechanism for consequential decisions that's actually enforced, not just described.
11. Transparency — people are told when they're interacting with or affected by AI, where that applies.
12. Bias/fairness testing — where the system affects individuals, tested before and after deployment.
13. Logging — decisions, data access, and changes are logged and retrievable.
14. Incident process — a defined path for AI-specific incidents like data leakage or model malfunction.
15. Monitoring and remediation — drift and control effectiveness tracked continuously, with findings closed out, not just filed.

What Is an AI Audit?

An AI audit is a systematic, evidence-based review of an AI system — or an organization's whole AI program — against governance, legal, security, and performance requirements. It differs from a standard IT audit in one important way: AI systems are probabilistic and can behave differently over time as data, prompts, or model versions shift. So the audit has to test current behavior, not just check a configuration that was true at launch.

In practice, that means examining who owns and approved a system, what data it processes and under what legal basis, what security controls apply, what documentation exists, whether human oversight actually functions, how the system performs (including fairness testing where relevant), and whether prior findings were fixed. Audits are run by internal audit or compliance teams, external assessors, certification bodies for standards like ISO/IEC 42001, or regulators. The output is usually a report with findings and a remediation plan, not a simple pass/fail — unless it's specifically for certification.

One thing worth correcting up front: it's inaccurate to say AI audits are now a blanket legal requirement under GDPR, the EU AI Act, HIPAA, and NIS2 for every organization. What's accurate is narrower. GDPR requires accountability and, in some cases, a Data Protection Impact Assessment. The EU AI Act imposes documentation and conformity duties on providers and deployers of systems it classifies as high-risk. HIPAA requires safeguards and audit controls for covered entities and business associates handling PHI. NIS2 imposes risk-management duties on entities a member state designates as essential or important. Whether a formal audit is mandated for you specifically depends on role, sector, and jurisdiction — but demonstrating AI governance through some structured review is good practice regardless.

They overlap constantly, but they're not interchangeable: an audit tests whether something works, a compliance assessment checks it against a rulebook, and a governance review asks who's actually accountable when it doesn't.

The Enterprise AI Audit Checklist

Ten domains, expanded from the 15 essentials above. For each, verify the control exists and pull evidence that it operates.

Inventory, ownership & governance. A complete inventory including embedded vendor AI, a working Shadow AI discovery process, named owners per system, a documented change-management workflow, a governance policy on a review cycle, a cross-functional oversight body, role-appropriate AI literacy training, and a decommissioning process for retired systems. Most of what goes wrong downstream traces back to a gap here — a system nobody claims ownership of is a system nobody can answer for.

Risk classification & impact assessment. Document a risk rating per system, map it to any applicable regulatory tier, identify who's affected, assess potential harms, and formally accept and document residual risk. Don't assume every system is "high risk," and don't treat classification as permanent — reclassify when purpose, data, or deployment context changes.

Data governance & privacy. Data inventory and lineage, a documented lawful basis, minimization and purpose limitation, controls for sensitive data categories, enforced retention and deletion, data subject rights that are technically operable (not just described), a DPIA where required, current cross-border transfer mechanisms, and a correct distinction between Data anonymization and pseudonymization. That last one matters more than it sounds: pseudonymized data — identifiers swapped out but still re-linkable — generally remains personal data under GDPR. True anonymization has to make re-identification practically impossible, including by your own organization. An audit should test which one is actually in place rather than accept a vendor's label.

Regulatory and standards alignment. GDPR for any EU/EEA personal data; the EU AI Act for systems placed on the market or used in the EU; ISO/IEC 42001 for organizations formalizing an AI management system, often for certification or procurement reasons; NIST AI RMF, voluntary but increasingly referenced in contracts and some state laws; HIPAA for covered entities and business associates handling PHI; NIS2 for entities designated essential or important; SOC 2 for vendor due diligence rather than legal mandate. This is a scoping menu — figure out which of these actually touch your organization before auditing against all of them.

Security. Authentication and role-based access on AI systems and APIs, prompt-injection testing, data leakage checks on both inputs and outputs, resistance to model extraction and inversion, integrity controls on training and fine-tuning pipelines, secrets management and encryption, logging and anomaly detection, an incident response plan that covers AI-specific failure modes, and red-teaming for higher-risk or public-facing systems.

Documentation & traceability. Current technical documentation, model cards where appropriate, retained validation and test records, version history, documented limitations and prohibited uses, and a dependency inventory covering third-party components.

Transparency & human oversight. User-facing disclosures where applicable, explainability scaled to the decision's actual impact, a human review step for consequential decisions that's been tested and can't be silently bypassed, an appeal mechanism where relevant, and clear accountability when oversight fails. Not every system needs the same bar here — a marketing copy generator and a credit-decisioning model are not the same audit.

Bias, fairness & performance. Defined metrics and test datasets, bias testing where the system affects individuals, tracked accuracy and error rates, performance checked across relevant subgroups where applicable, drift detection, and revalidation triggered by significant model or data changes.

Third-party AI & supply chain. A complete vendor inventory, vendor risk assessments and current security certifications, data processing agreements that specify retention, deletion, and whether your data trains their models, visibility into subprocessors, audit rights or an equivalent assurance mechanism, and exit/portability terms so you're not locked in.

Audit logging & evidence. Approval records per system, retrievable version and configuration history, records of data used and tests run, change and incident records tied to remediation status, and — the most common gap in practice — evidence that can actually be produced on demand, not just described as existing.

Control → Evidence → Test → Finding

This is the habit that separates an audit from a policy review: for every control, know what proves it exists, how you'd verify it operates, and what a failure looks like.

Take human oversight. The control is that a defined high-impact workflow — an automated denial, say — requires human review before it's finalized. The evidence is a review log showing reviewer, timestamp, and decision. The test is trying to push a case through the workflow in a way that should trigger review, and seeing whether the system actually enforces it. The finding, if it fails, is that the workflow completed without logging a review event — meaning the control exists on paper but not in the system.

Or take vendor data retention. The control is that your Enterprise AI vendor deletes customer data within a contractually defined window after termination. The evidence is a deletion confirmation or an exercised audit right. The test is requesting that confirmation, or pulling it from a completed offboarding. The finding, if it fails, is that the vendor can't produce deletion evidence, or the contract never specified a timeline to begin with.

Apply that pattern everywhere in this checklist. A checklist that only asks "does a policy exist?" will pass systems that fail in production.

Audit Questions to Ask

Governance: Who owns this system, and who approved it? Who can stop it? What happens when the model or vendor changes? Is there a standing body reviewing new deployments?

Data: What data enters, and from where? What's the legal basis? How long is it retained, and how is it deleted? Is it truly anonymized, or just pseudonymized?

Security: Has prompt injection been tested? How are the APIs authenticated and rate-limited? Can any user reach data or outputs they shouldn't? Has it been red-teamed?

Compliance: Which laws apply to this specific system? Is a DPIA or impact assessment required — and done? What could you show a regulator today, with no preparation time?

Oversight: Is the documentation current? Can a human actually override an automated decision, and has that been tested? What's disclosed to affected people?

Operations: How is drift detected? How are incidents logged and escalated? Can you reconstruct a specific past decision from logs? How are model or prompt changes approved before release?

How to Conduct an AI Audit

A checklist tells you what to check. This is how the audit itself runs, and it's a different thing:

1. Define the scope — systems, business units, timeframe.
2. Build or refresh the inventory for systems in scope.
3. Confirm ownership for each one.
4. Classify systems and risks.
5. Map data flows and dependencies, including vendors.
6. Identify which regulations and standards actually apply.
7. Collect evidence against each domain above.
8. Test controls — not just documentation.
9. Interview stakeholders to fill what documentation alone can't answer.
10. Document findings where controls don't hold up under testing.
11. Rate severity.
12. Assign owners and realistic remediation deadlines.
13. Set retest dates.
14. Re-test after remediation.
15. Write the final report.
16. Move into continuous monitoring so the next audit starts from a stronger baseline.

Findings and Risk Rating

Use a consistent scale — critical, high, medium, low, observation — so remediation effort tracks actual risk rather than whoever escalated loudest.

Here's what a real finding looks like: a customer-support AI assistant logs full chat transcripts, including unredacted card numbers, to a third-party analytics vendor with no data processing agreement in place.

Evidence: sample transcripts and a contract review showing no DPA.

Risk: high — unmanaged sensitive-data exposure to an unassessed third party.

Root cause: no data sanitization before the data leaves the workflow.

Recommendation: filter or anonymize before third-party logging, and get a DPA signed.

Owner and deadline: assigned to the DPO, 45 days, retest scheduled.

An audit report itself should cover: an executive summary, scope, applicable frameworks, methodology, findings by domain, risk ratings, referenced evidence, an assessment of control effectiveness, a remediation plan with owners and deadlines, management's response, and a retest date.

ISO/IEC 42001, NIST AI RMF, and EDPB Guidance

ISO/IEC 42001 is the international standard for an AI management system. It's certifiable but not mandatory — organizations usually pursue it for procurement leverage or to formalize governance that already needs structure. Clause 9.2 requires planned internal audits of the management system; Annex A provides AI-specific controls (impact assessment, data governance, third-party relationships) that map closely onto the domains above, with findings feeding into corrective action and management review.

NIST AI RMF organizes risk management into four functions — Govern, Map, Measure, Manage — running continuously rather than as sequential phases. It's voluntary federally, though increasingly referenced in contracts and some state laws.

Loosely: ownership and policy work maps to Govern, inventory and classification to Map, testing to Measure, and incident response and remediation to Manage.

EDPB's AI Auditing project, run through its Support Pool of Experts at the initiative of Spain's data protection authority, produced a downloadable checklist methodology and a proposed "algo-score" framework for assessing GDPR safeguards in AI systems, completed by an external expert in early 2023. It's aimed mainly at helping data protection authorities structure inspections — it isn't a substitute for a full compliance program and doesn't touch the EU AI Act's non-privacy obligations. But as one of the few regulator-produced auditing methodologies publicly available, it's a useful cross-check for the privacy dimension of your own checklist.

EU AI Act and GDPR: What Actually Applies

The EU AI Act's obligations are tiered by risk category and by your role as provider or deployer — there's no single checklist item that applies uniformly. As of this writing: prohibited practices and AI literacy obligations have applied since February 2025, and general-purpose AI model obligations since August 2025. Following the "AI Omnibus" simplification package that took effect in July 2026, most stand-alone high-risk systems under Annex III now face a compliance deadline of December 2, 2027, and high-risk AI embedded in already-regulated products (Annex I) moves to August 2, 2028 — while transparency obligations under Article 50 still apply from August 2, 2026. These dates are politically live and worth verifying against the European Commission's timeline before you rely on them. Where a system is in scope, audit for: documented classification and role, an ongoing risk-management process, data governance on training/validation/test sets, current technical documentation, sufficient logging, human oversight that's actually effective, tested accuracy/robustness/cybersecurity, Article 50 transparency where relevant, and post-market monitoring.

GDPR doesn't create one universal "AI audit" obligation — it requires accountability, and a DPIA where processing is likely high-risk. In practice that still means: a documented lawful basis, minimization applied to prompts and training data, privacy notices that reflect actual AI processing, data subject rights that work technically (including against fine-tuning data), Article 22 safeguards where decisions are solely automated and legally significant, Article 28-compliant processor agreements, valid transfer mechanisms, enforced retention schedules, and the anonymization/pseudonymization distinction applied correctly rather than assumed.

Generative AI, Agents, and Vendors

Generative AI needs its own pass: know your LLM provider's data-retention and training-use policies, inventory RAG data sources and vector database contents, test for prompt injection and data leakage in both directions, evaluate hallucination rates for your specific use case, put output validation or guardrails in front of anything reaching end users, track model version changes with re-testing triggers, and log the interface itself.

AI agents extend the audit past a static model to whatever actions the agent can take — and not every agent needs identical controls, so scope this to what it's actually permitted to do. Check its identity and ownership, its explicit permission boundaries, which tools and APIs it can invoke, what data it can read or write, whether high-impact actions require a human approval gate that's actually enforced, whether its decisions and tool calls are logged in enough detail to reconstruct behavior, how memory is retained and purged across sessions, whether irreversible actions (payments, deletions, external comms) have controls around them, and whether its actions can be rolled back if something goes wrong.

Third-party AI vendors need their own checklist too: data processing and retention terms, whether your data trains their models and under what opt-out, subprocessor disclosure, current security certifications scoped to the AI product specifically, incident notification timelines, audit rights or an equivalent, and a real exit and deletion process at contract end.

Shadow AI

Shadow AI — employees using AI tools outside any governance review — creates a visibility gap: you can't assess or control risk in systems you don't know are running. Detecting it usually takes a combination of network-level monitoring for AI traffic, procurement and expense review, and employee surveys, since no single method catches everything on its own. Governing it means clear acceptable-use policy paired with sanctioned tools good enough that people don't feel they need alternatives, plus a technical backstop — privacy-first anonymization that sanitizes sensitive data before it reaches any external AI system, regardless of which tool someone reaches for. Policy alone, with no technical enforcement, is asking for voluntary compliance and calling it a control.

Continuous Assurance

A checklist run once a year can't keep up with systems that change weekly. It helps to separate four distinct activities: continuous monitoring (automated, near-real-time tracking of drift and control status), periodic internal audit (a scheduled deeper review), event-triggered review (triggered by a model change, new vendor, incident, or regulatory shift), and formal external audit (independent, sometimes required for certification). What should be watched continuously: model and data changes, vendor changes, regulatory developments, drift, new vulnerabilities, incidents, control effectiveness, new systems entering the inventory, and Shadow AI signals. Done well, a formal audit just confirms what continuous monitoring already showed.

Documentation vs. Actual Control

The most important discipline here is refusing to stop at "do you have a policy?" Every mature audit asks a second question: can you demonstrate the policy is implemented and operating? A human-oversight policy a workflow can technically skip isn't a control. A retention policy nothing automatically enforces isn't a control. A vendor clause promising deletion, never once verified, isn't a control. Test both questions for every item in this checklist — regulators, customers, and internal risk committees increasingly ask the second one first.

Most first-time audits land at Level 1 or 2 — that's the expected starting point for AI adopted faster than governance could keep up, not a failure. What matters is moving up deliberately, one level at a time.

Industry Considerations

Financial services often layers model-risk-management expectations on top of AI-specific frameworks. Healthcare adds HIPAA safeguards and, for clinical-decision tools, device or safety scrutiny. SaaS companies are frequently driven more by enterprise customer due diligence than direct regulation right now. Legal work adds privilege and confidentiality risk on top of standard data protection. BPO and customer service raise data-minimization and vendor-oversight priorities given the volume of personal data flowing through. Government and public-sector deployments usually face procurement rules that exceed private-sector baselines. Requirements vary by jurisdiction within all of these — treat this as a starting point for scoping, not legal advice.

FAQs

How do you audit an AI system?

Scope it, confirm inventory and ownership, classify risk, map data flows, identify applicable rules, collect evidence, test whether controls actually operate, interview stakeholders, document findings with risk ratings, and track remediation to retest.

What evidence is needed?

Typically: the inventory, ownership records, risk assessments, data-flow maps, DPIAs, model documentation, test results, vendor contracts, oversight logs, incident records, and monitoring reports.

How often should AI systems be audited?

There's no single interval that applies everywhere. Many organizations run a full audit annually and after material changes, with continuous monitoring and event-triggered reviews filling the gaps.

AI audit vs. AI compliance assessment — what's the difference?

An audit verifies controls operate and produces findings. A compliance assessment checks alignment against a specific law and produces a gap analysis. They share evidence but answer different questions.

AI audit vs. AI governance — what's the difference?

Governance is the ongoing structure — policies, ownership, decision rights. An audit is the periodic check on whether that structure is actually working.

How does ISO/IEC 42001 relate to AI audits?

It's a certifiable AI management system standard requiring internal audits under Clause 9.2, with Annex A controls that map closely to standard audit domains.

How does NIST AI RMF support auditing?

It gives auditors a shared vocabulary — Govern, Map, Measure, Manage — for structuring findings. It's voluntary unless a contract or state law makes it applicable.

How does GDPR affect AI audits?

It requires a lawful basis, minimization, and accountability, plus a DPIA where risk is likely high — which in practice demands audit-equivalent evidence even without naming an "AI audit" specifically.

How does the EU AI Act affect AI audits?

It imposes classification, documentation, oversight, and conformity duties on high-risk systems, phased in by role and risk tier — audit scope should map directly to whichever obligations actually apply.

DPIA vs. AI impact assessment — what's the difference?

A DPIA (GDPR Article 35) covers risk to data protection rights specifically. An AI impact assessment can be broader — fundamental rights, safety, societal impact — where a framework like the EU AI Act requires one. Some organizations run both as one process.

What should an AI audit report contain?

Executive summary, scope, applicable frameworks, methodology, findings, risk ratings, evidence, control-effectiveness assessment, remediation plan, management response, retest date.

Biggest risks to check in generative AI?

Prompt injection, data leakage through prompts or completions, unclear provider retention/training policies, unvalidated RAG sources, unvalidated outputs reaching users, and thin logging.

How do you audit an AI agent?

Verify identity and ownership, permission boundaries, whether high-impact actions require enforced human approval, logging detail, memory handling, and whether actions can be rolled back.

Is an AI audit legally required?

Not universally, and rarely by that exact name. Specific obligations — a DPIA, an EU AI Act conformity assessment, HIPAA safeguards, NIS2 risk management — can effectively demand audit-equivalent evidence depending on your role and sector. Confirm with counsel for your specific situation.

AI audit vs. AI security audit — what's the difference?

A security audit is narrower: access controls, model and API security, adversarial testing. A full AI audit adds governance, privacy, documentation, and oversight on top.

Conclusion

A checklist gets you started; it doesn't finish the job. The domains, evidence tables, and control-evidence-test-finding pattern here will surface real gaps and give you a defensible starting inventory. What happens after — remediation tracked to closure, controls retested, monitoring that catches the next drift or vendor change before it becomes a finding — is where the actual risk reduction happens.

A lot of what this checklist surfaces traces back to one root cause: sensitive data reaching AI systems, sanctioned or not, without a consistent control at the point it leaves your environment. A privacy-first AI gateway that anonymizes that data before it reaches any model, logs what happened, and applies the same control regardless of which tool someone's using is one practical way to close that gap without rebuilding every system individually — which is the layer Questa AI is built to provide.