What Evidence Should AI Auditors Request?

An audit team can receive a polished artificial intelligence policy, a detailed inventory, and a reassuring dashboard and still lack enough evidence to conclude that the controls actually work.

That is one of the recurring problems in AI assurance: available documentation is not automatically audit evidence.

Useful evidence should let the auditor reconstruct a chain: what was expected to happen, how the control was designed, what actually happened, and what outcome followed. A policy demonstrates intent. A procedure describes design. A log may demonstrate operation. A metric, incident record, or corrective action may show whether the control achieved its intended result.

The better question is therefore not “Which documents should we request?” It is “What evidence do we need to test each risk and control?”

Start with the assertion, not the document name

The Global Internal Audit Standards provide the methodological baseline. Standard 14.1 requires internal auditors to gather information that is relevant, reliable, and sufficient. Reliability is strengthened, among other factors, when information is obtained directly, comes from an independent source, is corroborated, or is produced by a system with effective governance, risk management, and control processes.

Standard 14.6 adds a practical quality test: engagement documentation should enable an informed and competent person to repeat the work and derive the same engagement results.

For an AI audit, that means an evidence request should specify more than “AI policy,” “risk assessment,” or “test results.” For each item, define:

the assertion being tested;
the population and period the evidence covers;
who or what system generated it;
which model, application, or configuration version it represents;
how the auditor will corroborate it.

The Standards’ examples of evidence of conformance are helpful illustrations, but they are not mandatory requirements or an exhaustive checklist. The auditor remains responsible for deciding what evidence is appropriate for the engagement objective.

First evidence set: governance, scope, and decisions

Before testing models, prompts, or metrics, the auditor needs to establish what is being audited and under which governance decisions it operates.

A practical opening request often includes:

Evidence	What it should help establish	Typical audit move
AI policy and related standards	Criteria, permitted uses, responsibilities, exceptions	Compare requirements with actual practice and verify approval/currentness
AI system and use-case inventory	Audit population, owners, status, criticality	Test completeness against procurement, SSO, cloud, repositories, or spend
Roles and approval records	Who can approve, change, operate, and stop the system	Trace a sample of decisions to the authorized role
Risk and impact assessments	Identified risks, criteria, treatment, affected stakeholders	Reperform selected ratings and inspect significant changes
Exception register	Accepted deviations and compensating controls	Verify approval, expiry, monitoring, and closure

ISO/IEC 42001:2023 reinforces this evidence logic. Among other requirements, the standard calls for documented AI policy, assigned responsibilities, and retained documented information on AI risk assessments, risk treatment, and AI system impact assessments. It also requires documented evidence of monitoring and measurement results within the AI management system.

The point is not to turn ISO/IEC 42001 into an automatic checklist for every AI audit. Its value here is to illustrate the kinds of records that can demonstrate whether governance is operating rather than merely described.

Second evidence set: design, data, and pre-deployment testing

Once the context is clear, the next question is whether the system was designed and validated for its actual intended use.

Depending on the risk and technology, auditors may request:

functional requirements and acceptance criteria;
architecture and data-flow diagrams;
documentation for the model, service, or vendor being used;
data sources, lineage, provenance, usage rights, and data-quality controls;
data selection and preparation criteria;
training, validation, and test results where applicable;
relevant accuracy, robustness, security, bias, privacy, or performance testing;
known limitations, assumptions, foreseeable misuse, and conditions in which the system should not be used;
pre-deployment review and approval evidence;
third-party due diligence, contracts, service commitments, and change responsibilities.

There is an important audit trap here: a test report does not prove that the tested system is the system currently deployed. Validation evidence should be linked to the relevant version, configuration, data, release date, and deployment approval.

The NIST AI RMF Playbook is useful non-mandatory guidance. Its documentation practices include business purpose, risks, assumptions, data, validation results, dependencies, and monitoring plans. Under the Measure function, NIST also emphasizes documenting test sets, metrics, and tools used in test, evaluation, verification, and validation activities.

NIST describes the Playbook as voluntary and non-prescriptive. As of 2026, NIST also notes that AI RMF 1.0 is being revised, so auditors should treat the Playbook as a practical supporting resource rather than a static compliance checklist.

Third evidence set: proof that the control operated

Design documentation shows what should happen. Operational evidence shows what did happen.

Depending on the system, this may include:

access and privileged-account logs;
model, application, and configuration version history;
change tickets and approvals;
execution logs, model calls, errors, and relevant events;
prompt and output records when necessary and legally appropriate;
evidence that filters, limits, or guardrails were active;
human reviews, overrides, escalations, and intervention decisions;
exceptions and out-of-process use;
backup, continuity, and recovery records where relevant;
activity records from vendors or external components.

The persuasiveness of this evidence depends on traceability. A spreadsheet manually exported by the process owner may be useful, but it is stronger when Internal Audit can reconcile it to the source, validate the population, understand the extraction logic, and determine whether relevant events were excluded.

For a generative AI application, this may mean sampling sessions or transactions. For a predictive model, it may mean reconciling predictions to subsequent decisions or outcomes. For an AI agent, it may require reconstructing the sequence of tools used, permissions exercised, human approvals obtained, and actions executed.

Fourth evidence set: monitoring, incidents, and outcomes

A system may pass every pre-launch test and still degrade after deployment. AI evidence therefore needs to cover not only go-live, but also subsequent behavior.

Auditors should consider requesting:

defined performance metrics and thresholds;
monitoring results for drift, quality, bias, security, or reliability as relevant to the risk;
alerts and evidence of their resolution;
incidents, problems, complaints, and user feedback;
root-cause analyses;
decisions to suspend, restrict, retrain, or reconfigure the system;
corrective actions and evidence of effectiveness;
periodic risk and impact reassessments;
management reporting and evidence of accountable follow-up.

In 2026, COSO released Achieving Effective Internal Control Over Generative AI, which applies the five components of the Internal Control—Integrated Framework to GenAI. Its audit relevance is practical: it connects controls, illustrative metrics, and monitoring activities to evidence that can be tested. The publication does not replace COSO-ICIF and does not claim to cover every form of AI; it is GenAI-specific guidance.

Request evidence packages, not isolated files

A mature evidence request groups artifacts that test the same assertion from more than one angle. Suppose the control claim is: “Only approved model changes reach production.”

Requesting the change-management procedure alone is weak. A stronger package includes the procedure, the population of changes for the audit period, technical version history, approvals, and a sample of deployments. The auditor can then compare those sources.

This approach also prevents unnecessary collection of sensitive data. Internal Audit does not need every prompt, every training record, or every log “just in case.” Evidence should be proportionate to the engagement objective and handled with appropriate confidentiality, privacy, intellectual-property, and information-security protections.

A simple five-question test helps refine each request:

Which risk or control am I testing?
Does the evidence cover the right population and period?
Can I identify its source, date, and version?
Can I corroborate it with another source or direct access?
Would it allow another competent auditor to reproduce my conclusion?

The best AI audit evidence list is not the longest one. It is the one that makes the chain between criteria, control, operation, and outcome visible. When that chain is intact, documents stop being a repository and become a defensible basis for professional judgment.