ModelRefs / AI Audit — AI Glossary

AI Audit — AI Glossary

A systematic review of an AI system's design, training data, outputs, and deployment practices to assess compliance, fairness, and risk.

Overview

AI audits examine: training data provenance, model performance across demographic groups, decision process transparency, security vulnerabilities, and policy compliance. Methodologies: third-party technical audits, algorithmic impact assessments (AIA), red-teaming. Mandated for high-risk AI under the EU AI Act; voluntary for most US deployments.

Reference details

Topic	safety
Last reviewed	2026-06-24

How it works

Scope and standard are fixed first — which system, which version, against which framework — because an audit without a named standard produces opinion rather than a finding.
Evidence is collected from the operator rather than inferred: data provenance records, training and evaluation documentation, monitoring output, incident history, and the decisions behind each.
The system is tested independently, including disaggregated performance across the groups the use case affects, since an aggregate score can hide a gap that only appears per-group.
Each finding is written against a specific control with the evidence attached, so a reader can check the conclusion rather than take it on trust.
Findings carry remediation and a re-test date, and the audit is repeated on a cycle, because it describes a version and a moment rather than the system in general.

Example: Why an aggregate number is not an audit finding

A screening model reports 92% accuracy overall. Disaggregated, it is 95% on the largest group, which is 80% of the evaluation set, and 80% on a group that is 5% of it. The weighted average still lands near 92% — 0.8 × 95 + 0.05 × 80 + the remainder — so the headline figure is accurate and conceals a 15-point gap. An audit is the step that requires the per-group breakdown, and the reason the aggregate was never sufficient is arithmetic rather than policy.

Commonly confused with

Often used loosely for any internal review, which drops the part doing the work. An audit is conducted against a stated standard by someone independent of the team that built the system, and produces findings traceable to evidence. An internal evaluation is a team measuring its own system, which is necessary and is not an audit. It is also distinct from an algorithmic impact assessment: an AIA is prospective, asking what harms a planned deployment could cause, while an audit is retrospective, asking what the deployed system actually does.

When to use it

Reach for it when:

A deployment falls under a framework that requires independent assessment of a high-risk use case.
A model informs consequential decisions about people and you need evidence rather than confidence.
A procurement or partner requires third-party assurance about a system you operate.

Reach for something else when:

Routine quality monitoring, which is continuous and internal by design.
As a substitute for ongoing evaluation — an audit is a point-in-time finding, not a monitor.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to AI Audit — AI Glossary.

Frequently asked questions

What is AI Audit?