AI Governance

The AI evidence pack: ten records your regulator or auditor will ask for

The AI evidence pack: ten records your regulator or auditor will ask for

What evidence do auditors and regulators need for AI? Ten records, who asks for each, what good looks like, and where firms usually fall short.

Auditors and regulators ask for ten records: an AI inventory with risk ratings, named owners, a risk assessment before use, tests against thresholds set in advance, monitoring records, proof of human intervention, decision logs, vendor due diligence, notices and appeal records, and an incident log.

No regulator publishes this list in one place. Read the EU AI Act, OSFI E-23, the NAIC bulletin, US supervisors, UK data protection law and the new US state laws side by side, and the same ten records keep appearing. Build the pack once and you can answer most requests from it.

What are the ten records, and who asks for each?

RecordWho asksWhat good looks like
1. Inventory with risk ratingOSFI E-23, NAIC bulletin, PRA SS1/23Every system, built or bought, rated, with a review date
2. Named ownersNAIC bulletin, FCA (SM&CR), EU AI Act Art. 26, SECA person, not a team, linked to a senior manager
3. Risk assessment before useEU AI Act Art. 9, ICO draft guidance, California CCPASigned off before go-live, updated on change
4. Tests against preset thresholdsEU AI Act Art. 9 and 15, OSFI E-23, NAIC, SECPass mark written down first, checked independently
5. Monitoring and driftOSFI E-23, NAIC bulletin, EU AI Act Art. 26A fixed cadence, a trend, action on breaches
6. Human interventionEU AI Act Art. 14 and 26, UK GDPR Art. 22C, Colorado, California, FINRA, insurersTrained reviewers, overrides on record
7. Decision logsEU AI Act Art. 12 and 26, FINRA, ColoradoAny decision rebuilt in an hour, without an engineer
8. Vendor due diligenceOSFI E-23, NAIC bulletin, PRA SS1/23, FINRAA file per vendor model, plus your own checks
9. Notices and appealsColorado, California, UK GDPR Art. 22C, EU AI Act Art. 26 and 50, NAICTemplates in use, every request logged
10. Incident logEU AI Act Art. 26, internal auditNear misses too, each tied to a fix

On dates: the EU AI Act's high-risk duties (Articles 9 to 15 and 26) apply to Annex III uses from 2 December 2027, while Article 50 already applies. Colorado and California start on 1 January 2027, OSFI E-23 on 1 May 2027.

1. An inventory with a risk rating

Every AI system, model and agent you run, built or bought, with a risk rating that sets how closely it's watched.

Who asks: OSFI E-23, vendor models included. The NAIC AI bulletin, adopted in 26 US jurisdictions. PRA SS1/23, for UK banks with internal model approval.

Good: One inventory across the business, with an owner and a next review date on every line.

Common gap: AI bought by business units. If procurement can find it and the inventory can't, the inventory is wrong.

2. Named owners and senior accountability

A named person accountable for each system, with a clear line to the senior manager who answers for it.

Who asks: The NAIC bulletin (senior management accountability). The FCA, through the Senior Managers and Certification Regime rather than AI-specific rules. EU AI Act Article 26 (competent people assigned to oversight). SEC examiners (policies and procedures to supervise AI use).

Good: Owners who know they're owners, and AI risk reaching a senior committee.

Common gap: "IT" or "the vendor" in the owner column.

3. A risk or impact assessment before use

A dated assessment of what could go wrong, for whom, and which controls you put in place.

Who asks: EU AI Act Article 9 for high-risk providers. The ICO's draft guidance on automated decisions (a DPIA is likely to be needed). California's CCPA rules (risk assessments for new processing). Colorado is the exception: SB 26-189 dropped impact assessments in favour of notices and human review.

Good: Completed before go-live and updated whenever the model, data or scope changes.

Common gap: An assessment written once for the pilot and never revisited for production.

4. Test results against thresholds set in advance

Evidence the system was tested, accuracy included, against a metric and pass mark written down beforehand.

Who asks: EU AI Act Article 9 (testing against "prior defined metrics and probabilistic thresholds") and Article 15 (accuracy metrics declared in the instructions for use). OSFI E-23 (review independent of development, defined thresholds for breaches). The NAIC bulletin (validation). SEC examiners (whether what you say about your AI is accurate).

Good: The metric, threshold, test set and result, checked by someone other than the builder. For generated text, a claim-by-claim check against sources, as in our Accuracy Evidence File.

Common gap: A vendor's benchmark filed as if it were your own test.

5. Monitoring and drift records

Proof you kept checking after go-live, and acted when results moved.

Who asks: OSFI E-23 (monitoring scaled to the risk rating). The NAIC bulletin (drift monitoring). EU AI Act Article 26 (deployers monitor, and suspend use if a risk appears).

Good: A fixed cadence, a trend over time, and what you did about each breach.

Common gap: Monitoring that tracks uptime and cost but not whether the outputs are still right.

6. Proof a competent human could and did intervene

Records showing reviewers understood the system, had authority to change the outcome, and sometimes did.

Who asks: EU AI Act Article 14 (the ability to override or stop) and Article 26 (competent overseers). UK GDPR Article 22C safeguards (since 5 February 2026), with the ICO's draft guidance saying human involvement must be active, not tokenistic. Colorado's right to meaningful human review and California's human appeal route. FINRA (human monitoring of outputs). Insurers, who increasingly want evidence of human oversight.

Good: Training records for reviewers, and a log of overrides as well as approvals.

Common gap: Reviewers who have never overturned anything. A regulator will ask whether they were reviewing at all.

7. Logs that rebuild any decision

Enough detail to reconstruct a single decision: the inputs, what the system did, the output and who approved it.

Who asks: EU AI Act Article 12 (automatic logging) and Article 26 (deployers keep logs for at least six months). FINRA (tracking agent actions). Colorado SB 26-189 (three years of records).

Good: Someone in risk can rebuild a decision without an engineer. For agents, the log shows what the approver saw next to what ran (see our agent governance framework).

Common gap: Logs that exist but can't be tied to a policy, a person or a customer.

8. Vendor due diligence

A file for every third-party model or AI service you rely on.

Who asks: OSFI E-23 (vendor models are the institution's model risk). The NAIC bulletin (third-party due diligence). PRA SS1/23 (vendor models in scope). FINRA (due diligence on generative AI vendors).

Good: What the model does, how the vendor tested it, what data it uses, how you'll hear about changes, and your own checks on its results.

Common gap: A security questionnaire filed as if it covered model risk.

9. Notices, explanations and appeal records

What you told affected people, what they asked for, and what happened next.

Who asks: Colorado SB 26-189 (explain the AI's role in an adverse decision within 30 days, a right to correct data, meaningful human review). California's ADMT rules (pre-use notice, opt-out or human appeal, access to the logic and outcome). UK GDPR Article 22C. EU AI Act Article 26 (inform affected people) and Article 50 (tell people they're dealing with AI). The NAIC bulletin (consumer notice).

Good: Approved templates, and a log of every request with dates and outcomes.

Common gap: A notice drafted by legal that operations can't fulfil inside the deadline.

10. An incident log

Every AI error that reached a customer, a record or a decision, with cause, impact and fix.

Who asks: EU AI Act Article 26 (deployers report serious incidents, which means knowing you've had one). Internal audit, every time.

Good: Near misses logged as well as incidents, each linked to a change in tests or controls.

Common gap: Errors fixed quietly in the workflow and never written down.

Is there an accuracy threshold you have to meet?

No. None of the regimes above sets a numeric accuracy threshold for AI output. What they ask for is a metric you stated, a check independent of whoever built the system, a threshold set before testing, and a named human who acts when it's breached. That's records 4 and 6 working together. A score on its own doesn't meet that bar; see An accuracy score is not evidence.

Where do US banks stand after SR 26-2?

SR 26-2 (Federal Reserve, OCC and FDIC, 17 April 2026) replaced SR 11-7 and is aimed mainly at banks over $30bn in assets. Its attachment says generative and agentic AI are not within its scope, leaving them to each bank's own risk management. That doesn't remove the need for these records. It means the bank has to set its own standard, write it down and show it followed it.

Where does ISO/IEC 42001 fit?

ISO/IEC 42001 is a management-system standard for AI. Mapping your evidence pack to its clauses helps show the system is run consistently. Two limits: it isn't a harmonised standard under the EU AI Act, and it describes how you manage AI, not whether any given output was right. More in ISO 42001 and the EU AI Act.

How do you build the pack?

  1. Start with the inventory. Include agents and vendor tools. Everything else hangs off it.
  2. Rate and name. A risk rating and a named owner on every line. Highest-rated systems first.
  3. File what you already have. Assessments, test results and vendor files usually exist somewhere. File them against the inventory line.
  4. Fix the logs. Rebuild one decision for each high-rated system. Set retention to the longest rule that applies.
  5. Set the cadence. Monitoring, review sampling and incident review on a fixed schedule, at least monthly for high-rated systems.
  6. Run a mock request. Ask someone outside the team to request the pack for one system and one decision. Time it, then fix whatever slowed them down.

How ETT can help

For UiPath estates we run under Agentic Managed Services, the monthly evidence report covers drift checks, change control and a sample of agent-written outputs checked against their sources. That keeps the monitoring record current, rather than rebuilt the week before an audit. See Agentic Managed Services.

FAQ

What is an AI audit framework?

It's the structure an auditor uses to test how you govern AI. For internal audit, the IIA's AI Auditing Framework (updated in 2024) is the obvious starting point. Whatever framework is used, the testing comes back to records like the ten above. No records, nothing to test.

How long should we keep AI decision logs?

It depends on the rule. Under the EU AI Act, deployers of high-risk systems must keep logs for at least six months, from 2 December 2027 for Annex III uses. Colorado SB 26-189 requires three years of records from 1 January 2027. Set retention to the longest rule that applies.

Who should own the evidence pack?

The teams running the systems produce the records. Risk or compliance should own the pack and the standard it's held to. Internal audit tests it. If one team builds, owns and tests the pack, it isn't independent.

Sources

AI GovernanceAuditEvidence

Want to apply this to a specific process?

Bring the workflow you had in mind. We will talk through whether these ideas apply to it, and what it would take to find out.

Around four minutes. Indicative guidance based on your answers.

Region & currency

Changes spelling, terminology, the data-protection regime named in our notices, and the currency used in indicative figures. It does not change where we are or quote you a price in your currency. ETT is headquartered in Dallas, with offices in London and Vancouver.