UK ICO AI Audit Evidence: Build a Reconstructable Review Package

An AI audit sample should begin with a production event and travel in both directions. Backward, the reviewer reaches the approved purpose, DPIA, processor file and policy version. Forward, the record shows the destination, outcome, retention treatment and any incident or rights workflow. A folder of policies without those joins describes intent while leaving operation untested.

The ICO's Guidance on AI and data protection says it is under review following the Data (Use and Access) Act. It also identifies 15 March 2023 as the update date on the current page. Treat that material as regulatory guidance under review. Verify operative duties against the latest revised UK GDPR and Data Protection Act 2018, then record the retrieval date in the package.

Evidence starts with an indexed system file

The ICO's accountability and governance chapter addresses senior management responsibility, controller and processor relationships, data protection by design and default, and DPIAs. Article 5 makes the controller responsible for the principles and able to demonstrate compliance.

Create one evidence index for AI system UK-CLAIMS-17. Each entry gets an owner, version, approval date, system identifier, source location, retention rule and join key. The first folder should contain the use-case approval, lawful-basis decision, role analysis, Article 30 record, DPIA threshold decision, current architecture, processor arrangement, transparency material and rights procedure.

A plain index with working joins earns more confidence than a polished policy deck. I would rather see one grey spreadsheet cell link to the exact production denial than read another committee-approved statement saying that AI uses are monitored.

Sampling tests control operation

An audit sample needs selection logic that another reviewer can repeat. Define the population as routed HTTP model events for a stated system, provider set and period. Preserve the query before looking at results. Then select events across outcomes and higher-risk conditions.

Include a permit, redaction, denial, policy change, unknown destination, missing identity context and evaluator failure where those outcomes exist. Each record should carry a stable event ID, UTC timestamp, originating principal, workload, application-supplied purpose, data classification, endpoint, policy version, outcome and correlation ID. Payload retention needs its own necessity and minimisation decision.

Use synthetic records for active control tests. A purple marker in a health-detail field gives the reviewer a visible join across the test payload, classifier output and denial record without exposing a real customer. Preserve the test script, expected result, actual result and reviewer sign-off.

DPIA evidence joins predicted risk to observed traffic

Article 35 requires a DPIA before processing likely to result in high risk, taking account of its nature, scope, context and purposes. The assessment includes a description of processing, necessity and proportionality, risks to people and measures addressing those risks.

For each applicable AI use, retain the threshold decision, approved DPIA, DPO advice, consultation record where relevant, risk owner, treatment, residual decision and review trigger. Connect technical treatments to event tests through stable risk identifiers.

Suppose DPIA-22 covers disclosure of special category data to an unapproved model route. The evidence package should contain the approved route rule, a synthetic marked request, the restrictive outcome, the policy version and a later clean retest. Model, provider, purpose, population and payload changes belong in a dated change history because they can alter the risk decision.

Processing records and runtime records serve different purposes

Article 30 specifies records of processing activities. A controller record includes purposes, categories of people and personal data, recipient categories, applicable transfers, possible erasure time limits and a general description of security measures. A processor record identifies each controller, processing categories, applicable transfers and that security description.

That material provides activity-level evidence for the system file. A per-request record is an implementation pattern that can show how a control operated at a particular moment. Articles 30, 32 and 35 create specific duties, but they do not prescribe universal retention of every AI prompt and response.

Reconcile the Article 30 row against observed destinations. For each sample, join the endpoint to the approved recipient or processor file, and join the purpose and data class to the system record. An unexplained hostname is a finding with an owner and due date, rather than a footnote hidden in the architecture diagram.

Integrity and write-path independence protect the sample

Article 32 establishes risk-based security duties and includes regular testing and evaluation where appropriate. For AI audit evidence, preserve the policy design, route inventory, identity-validation configuration, classification rules, failure behaviour, event schema, access list, retention setting and integrity-verification procedure.

Write-path independence is a recommended evidence design. The calling application should lack custody of the audit commit, because selective logging, suppression and crash loss all weaken a sample generated by the system under review. Signed events or chained integrity values can expose later alteration. Store verification keys and procedures with separate operational ownership.

Run one integrity test against event EVT-8F12. Change a copied field, verify that validation fails, and keep a screenshot showing the red result beside the untouched green record. The legislation sets the risk-based duty. The independent writer and signature pattern are implementation guidance for credible evidence.

Retrieval proves that the package can answer an inquiry

Evidence has operational value when a reviewer can retrieve it within a defined scope. Prepare tested queries for event ID, principal, workload, subject reference, purpose, data class, endpoint, policy version, outcome and time window. Stable subject references matter when the person described in the prompt differs from the caller.

Run three retrieval exercises against the indexed evidence package. First, reconstruct one denied request through the purpose register, Article 30 row, DPIA risk and processor file. Second, list disclosures for a synthetic subject and route any correction to the authoritative source system. Third, bound all requests affected by one policy version during an incident window.

Keep query text, access approvals, export hashes, reviewer notes and elapsed retrieval time as operating evidence. The rights decision, exemption analysis, source correction, provider deletion and response to the individual remain in the legal and organisational folder.

Change records preserve the guidance context

The ICO page currently carries a Data (Use and Access) Act review warning. Put that warning, the guidance retrieval date and the legislation version in the evidence index. When updated guidance appears, create a change assessment rather than silently replacing the old file.

The assessment should identify affected policies, DPIAs, notices, processor terms, tests and training. Give each action an owner and closure artifact. This creates a defensible record of which guidance informed a decision at a particular time and how the organisation responded later.

Keep two clearly labeled evidence folders for the review. HTTP-boundary evidence holds routed decisions, policy tests, endpoint reconciliation, integrity results and query outputs. Legal and organisational controls holds lawful basis, fairness work, notices, role analysis, DPIA approval, contracts, transfer analysis, retention decisions, rights handling, workforce controls and offline systems. That split prevents one traffic log being presented as proof for the entire programme.

DeepInspect

DeepInspect supplies the HTTP-boundary folder for authenticated users or agents calling HTTP-based LLM endpoints. It evaluates application-supplied identity and purpose context, role, data classification, destination and policy before forwarding a request. Every permit, redaction or denial produces a signed, tamper-evident decision record outside the calling application's write path.

Those records support repeatable samples, endpoint reconciliation, DPIA treatment tests, Article 32 operating tests, integrity checks, incident scoping and rights retrieval where the application supplies a stable subject reference. DeepInspect leaves legal basis, fairness, notices, DPIA approval, contracts, source correction, workforce controls and offline AI systems with their accountable owners. Book a technical deep dive at deepinspect.ai.