What Evidence Should an AI Governance Program Retain?

A governance program without evidence is a set of good intentions. When a customer, auditor, insurer or regulator asks “show me”, the answer has to be a file, not a meeting. This guide sets out what to retain for each control, how long, how to make it tamper-evident, how to separate what has been uploaded from what has been verified, and how to export it.

Why evidence, specifically

Several instruments in our verified dataset turn on records:

• Colorado SB 26-189 requires developers and deployers of covered ADMT to retain records needed to demonstrate compliance for at least three years, with obligations starting 1 January 2027 and Attorney General enforcement subject to a 60-day cure period until 1 January 2030. A cure is only possible if you can show what you did.
• EU AI Act high-risk duties (Annex III from 2 December 2027) are evidence-heavy: technical documentation kept up to date (Art. 11), logging capability (Art. 12), deployer log retention of at least six months (Art. 26(6)), worker notification records (Art. 26(7)) and fundamental rights impact assessments where Art. 27 applies.
• Texas TRAIGA gives a rebuttable presumption of reasonable care to documented programs aligned with the NIST AI RMF. The presumption is only as strong as the documentation.
• NYC Local Law 144 requires an independent bias audit within the past year and a public summary. Ontario ESA s. 8.4 is proven by copies of postings. Illinois HB 3773 is proven by notice delivery records. FTC accuracy enforcement is answered by claim-substantiation files.
• Quebec P-39.1 s. 3.2 requires published governance policies covering retention and destruction, and s. 3.3 requires privacy impact assessments. California’s CPPA regulations require documented risk assessments (existing processing by 31 December 2027, first submissions by 1 April 2028).

None of these says keep everything; they say keep the right things, retrievably.

Evidence by control

Control	Evidence to retain	Produced by	Notes
AI policy adopted	Signed or approved policy with version and date; approval record (minutes, e-sign, email)	Owner	Keep superseded versions
Roles assigned	Governance charter or RACI; appointment of privacy officer (Quebec s. 3.1 publication)	Owner	Update on personnel change
AI inventory maintained	Inventory export with timestamps; change log	Owner	Monthly snapshot
AI literacy / training	Curriculum, attendance or completion records, assessment results	HR or owner	EU Art. 4
Use-case screening	Prohibited-practice screen per system (EU Art. 5; TRAIGA s. 552)	System owner	Re-screen on change
Risk and impact assessment	Completed assessment, reviewer sign-off, residual-risk acceptance; PIA (Quebec s. 3.3), DPIA (GDPR Art. 35), FRIA (EU Art. 27), CCPA risk assessment	System owner	Dated, versioned
Vendor due diligence	Questionnaire responses, contract clauses, bias-audit or testing reports, documentation packs (Colorado developer documentation from 2027), update notices	Procurement or owner	Keep request and response dates
Notices and disclosures	Posting copies (Ontario), candidate and employee notices with send logs (NYC, Illinois), ADMT notices (Colorado, California), decision notices (Quebec s. 12.1), chatbot disclosure screenshots (EU Art. 50, Utah)	HR, marketing, owner	Screenshot with URL and date
Human oversight	Approval records, sample-review logs, kill-switch tests, credential-scope exports	Oversight owner	See the agent oversight guide
System reviews and testing	Ground-truth test sheets, adverse-impact analyses, injection-test records, accuracy metrics (EU Art. 15)	System owner	Before launch and on change
Monitoring and logs	Log retention configuration, sample log extracts, monitoring reports	IT or vendor	EU Art. 26(6) six months minimum
Incidents	Incident records, breach assessments, notifications, post-incident reviews	Governance owner	Include “no notification required” decisions
Marketing claims	Substantiation file for each AI accuracy or capability claim	Marketing	FTC Section 5
Management review	Minutes, decisions, action tracking	Owner	ISO/IEC 42001 clause 9 style

Retention periods

Set periods per evidence class, write them in the policy, and enforce them.

Evidence class	Minimum anchored in dataset	Suggested default
ADMT compliance records for Colorado consumers	3 years (SB 26-189, from 1 January 2027)	3 years from the record date, or from decommissioning for system-level records
EU high-risk system logs held by deployers	At least 6 months (Art. 26(6), from 2 December 2027), unless other law sets a different period	6 months rolling; longer for incident holds
EU high-risk technical documentation	Kept up to date while the system is on the market (Art. 11)	Life of system plus a defensible tail
NYC bias audits	Audit within the past year before each use	Keep every annual audit and summary for the life of the tool plus three years
CCPA risk assessments	Documented and submitted on the schedule in the regulations	Life of processing plus a defensible tail
Everything else (policies, training, reviews, incidents, vendor files)	No period in dataset	Set a defensible period: life of system plus three years is a common choice that covers the longest statutory anchor above; confirm with counsel against your limitation periods

Two cautions. First, “set a defensible period” means a written, reasoned choice, not an indefinite default. Second, evidence that contains personal information is still personal information. PIPEDA’s limiting-retention principle and Quebec’s s. 3.2 retention and destruction requirements apply, so redact or minimise personal data in evidence where the control can be proven without it, and never keep raw transcripts “just in case”.

Hashes and tamper-evidence

Evidence persuades only if nobody could have quietly changed it. Four practices make a small-business store credible:

1. Hash at upload. Compute a SHA-256 hash of every file when it enters the system and store the hash with the record. Anyone can later recompute it to confirm the file is unchanged.
2. Record provenance. Who uploaded it, when, from where, and which control and system it relates to.
3. Make the store append-only. Replacing a file creates a new version with a new hash; the old one stays. Use storage with versioning or write-once settings rather than a shared drive where anyone can overwrite.
4. Keep a change log. Every status change (uploaded, verified, expired, superseded) is logged with actor and timestamp.

For system-generated logs, export periodically, hash the export, and store the hash separately from the export so a compromised log store cannot also rewrite the hash.

Uploaded versus verified evidence

Most evidence failures are not missing files; they are files that do not prove what someone assumed. Separate the two states:

• Uploaded. A file exists against a control. It counts for nothing yet.
• Verified. A second person has checked, and recorded, that the file is the correct document for the named system and period, is complete and legible, shows the control operating (not just a template), is dated within the required window, and matches its hash.
• Expired. The file was valid but has passed its validity window (for example, a bias audit more than a year old under NYC rules, or a training record for a system that has changed materially).
• Superseded. Replaced by a newer version; retained for history.

Control status should be computed only from verified, unexpired evidence. If the person who uploaded a file is also the only person who can verify it, record that limitation; a sole proprietor can still date and hash files, but should not describe them as independently verified.

Export bundles for auditors, customers and regulators

Decide the bundle format before anyone asks. A workable structure:

1. Cover note. Who requested it, scope (which systems, controls, period), date generated, who generated it, and any redactions applied.
2. Index. One row per evidence item: control, system, file name, date, status (verified or uploaded), verifier, hash.
3. Evidence files. Organised by control, using the index file names.
4. Hash manifest. The list of hashes so the recipient can confirm integrity.
5. Inventory and policy extracts. The current inventory entries and policy version in force for the period.

Tailor the audience. A customer’s procurement team needs the policy, inventory summary, vendor due diligence and review evidence for the systems that touch their data. An ISO/IEC 42001 auditor needs management review, internal audit and corrective-action records. A regulator under a cure period needs the notices, assessments and records for the systems named in the letter. In every case, redact personal information not needed to prove the control.

Example. Sable & Finch Insurance Brokers, a fictional 45-person brokerage in Winnipeg and Denver, uses an AI quoting assistant. Its evidence store holds the approved policy (v3, hashed), the inventory entry, a dated risk assessment with reviewer sign-off, the vendor’s documentation pack and contract, the Colorado point-of-interaction notice screenshot ready for 1 January 2027, quarterly test sheets, monthly sample-review logs, two incident records (one with a documented “no notification required” decision) and the kill-switch test log. Each item has a hash, an uploader, a verifier and an expiry. When a US carrier partner sends a 40-question AI questionnaire, the operations lead generates a scoped bundle in an afternoon, redacts client names from the test sheets, and attaches the manifest.

Sources

• Colorado SB 26-189 – https://leg.colorado.gov/bills/sb26-189
• EU AI Act Art. 11 (technical documentation) – https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng#art_11
• EU AI Act Art. 12 (record-keeping) – https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng#art_12
• EU AI Act Art. 26 (deployer obligations, log retention) – https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng#art_26
• EU AI Act Art. 27 (FRIA) – https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng#art_27
• Digital Omnibus on AI, Regulation (EU) 2026/1744 – https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
• Texas HB 149 (TRAIGA) – https://capitol.texas.gov/tlodocs/89R/billtext/html/HB00149F.htm
• NYC Local Law 144 (DCWP) – https://www.nyc.gov/site/dca/about/automated-employment-decision-tools.page
• Ontario Employment Standards Act, 2000 – https://www.ontario.ca/laws/statute/00e41
• Illinois Public Act 103-0804 (HB 3773) – https://www.ilga.gov/legislation/publicacts/fulltext.asp?Name=103-0804
• Quebec P-39.1 – https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1
• PIPEDA Schedule 1 principles – https://laws-lois.justice.gc.ca/eng/acts/P-8.6/page-7.html
• California CPPA regulations – https://cppa.ca.gov/regulations/ccpa_updates.html
• FTC Workado final order – https://www.ftc.gov/news-events/news/press-releases/2025/08/ftc-approves-final-order-against-workado-llc-which-misrepresented-accuracy-its-artificial
• NIST AI Risk Management Framework – https://www.nist.gov/itl/ai-risk-management-framework
• ISO/IEC 42001:2023 – https://www.iso.org/standard/42001