UK DPA AI Audit Evidence: Reconstruct Personal Data in Model Traffic

One AI request can turn a support transcript into a disclosure of personal data to a model provider. The evidence chain begins before the HTTPS POST leaves the application: approved purpose, processing basis, data categories, authenticated principal, provider endpoint, policy decision and resulting record. I want to show how that chain supports a UK data protection audit while labeling sound operating practice as implementation guidance.

The legal baseline is the UK General Data Protection Regulation, supplemented by the Data Protection Act 2018. On 11 August 2026, legislation.gov.uk presented the latest revised texts and identified outstanding changes that may take effect later. The Information Commissioner's Office also states that its AI guidance is under review following the Data (Use and Access) Act. That warning belongs in the audit file because current guidance and current legislation serve different evidential roles.

Accountability sets the evidence objective

Article 5 makes the controller responsible for compliance with the data protection principles and able to demonstrate it. For an AI system, the objective is a connected record showing how lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, security and accountability operated in the deployed use case.

The ICO's AI accountability and governance guidance tells senior management and DPOs to understand controller and processor relationships, align roles and policies, and demonstrate data protection by design and default on an ongoing basis. The same page describes a DPIA as an ideal way to demonstrate compliance.

Start the package with one evidence index. Give every artifact an owner, version, approval date, system identifier and join key. My view is that a polished policy with missing join keys deserves less confidence than a plain export that reconstructs one production disclosure in five minutes.

Article 30 processing records anchor the system file

Article 30 specifies records of processing activities for controllers and processors. A controller record includes purposes, categories of data subjects and personal data, recipient categories, applicable international transfers, possible erasure time limits and a general description of technical and organisational security measures. Processor records cover each controller, processing categories, applicable transfers and that security description.

Create an AI system sheet that extends the Article 30 record with implementation detail. Name the business feature, controller, processor, DPO contact, approved purpose, lawful-basis decision, personal-data classes, data-subject groups, model provider, endpoint hostname, configured region, retention rule and go-live date. Mark added fields as operating evidence. Article 30 describes processing activities at system level. Per-request retention is an implementation choice governed by purpose, necessity and the applicable retention analysis.

Run a seven-day reconciliation between the approved endpoint list and observed HTTP model traffic. A white spreadsheet row naming uk-support-summary-04 should link to the processor contract, DPIA, current policy and every sampled event. An unexplained hostname gets an owner and investigation date.

The DPIA joins predicted risk to observed operation

Article 35 requires a DPIA before processing likely to result in high risk, taking account of the nature, scope, context and purposes. The provision expressly identifies systematic and extensive evaluation based on automated processing where decisions produce legal or similarly significant effects, large-scale processing of special category or criminal-offence data, and systematic monitoring of a publicly accessible area on a large scale.

For an AI deployment inside Article 35, retain the processing description, necessity and proportionality assessment, risks to people, planned measures, DPO advice and approval history. Add the model and application versions tested. The ICO guidance asks teams to revisit risk as the use case and technical system change, so the package should preserve review dates and resulting decisions.

Bind the DPIA to runtime samples through a risk identifier. If risk DPIA-17 concerns disclosure of health details to an unapproved provider, send a synthetic record containing a visible purple test marker to that route on 11 August 2026. Keep the denial, alert, policy version and reviewer sign-off beside the risk treatment.

Request samples support purpose and minimisation tests

Article 5 requires specified purposes and personal data limited to what is necessary for those purposes. Article 6 supplies the lawful-basis framework, while Articles 9 and 10 add conditions for special category and criminal-offence data. Counsel and the DPO own those legal decisions. Technical evidence shows which declared purpose, data class and destination were presented to the enforcement point.

Build a sample containing at least one permit, redaction, denial, policy change and evaluator failure. Each event should carry a stable ID, UTC timestamp, authenticated principal, workload identity, purpose value supplied by the application, detected personal-data class, endpoint, policy version, outcome and correlation ID. Preserve the query used to select the sample.

A purpose control depends on a trustworthy purpose value. Caller identity alone gives weak evidence when a caseworker asks about a customer. Add a stable data-subject reference when rights retrieval needs to locate the person described in the payload. Then trace each selected event back to the purpose register and forward to the named recipient.

Security evidence needs design and operating tests

Article 32 requires controllers and processors to implement technical and organisational measures appropriate to risk. Its assessment factors include implementation costs, processing context, available technical capabilities and risk. The listed measures include appropriate pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, restoration capability, and a process for regular testing and evaluation.

For HTTP AI traffic, retain the policy design, route inventory, identity validation configuration, data-classification rules, failure behavior, event schema, access list, retention configuration and integrity-verification procedure. Put the record writer outside the calling application's custody and use signatures or chained integrity values. These patterns are implementation guidance for independence and tamper detection. Article 32 sets a risk-based security duty.

Test three conditions under change ticket SEC-1187: an unapproved endpoint, missing identity context and a policy-evaluator timeout. Record the restrictive outcomes, alerts, remediation and clean retest. A red denial row beside two amber test rows on the review screen gives the DPO a concrete control result.

Processor and rights records complete the legal chain

Article 28 governs processor selection and contract terms, including documented instructions, confidentiality, security, assistance, deletion or return, information needed to demonstrate compliance, and audits or inspections. For a hosted model, preserve due diligence, the signed agreement, subprocessor list, data-use terms, location commitments, incident contacts and deletion instructions.

Compare those documents with the endpoint and region observed in the request sample. The contract records the approved arrangement. Runtime evidence records the destination used for a particular event. A mismatch should open a procurement and privacy review with a named owner.

Rights evidence needs the intake request, identity verification, search method, decision, response and execution record across relevant stores. Articles 15 through 18 cover access, rectification, erasure and restriction subject to their conditions. Runtime records can supply a disclosure history when they carry a stable subject reference. Source-record correction, provider-side deletion and removal across vector stores require separate execution evidence.

HTTP-boundary evidence and organisational controls stay separate

An HTTP policy gateway can inspect authenticated requests sent to HTTP-based LLM endpoints. It can evaluate identity context supplied by the application, purpose-bound policy, personal-data classification and destination before transmission. The resulting event record can support endpoint reconciliation, sampled disclosures, security testing, incident scoping and rights searches.

The wider UK data protection file covers legal basis, fairness analysis, transparency notices, controller and processor classification, DPIA approval, staff training, supplier contracts, international-transfer analysis, retention decisions and rights handling. Data quality inside source systems, model evaluation, local agent execution, storage permissions, endpoint security and offline training pipelines also need controls beyond the HTTP route.

Keep two labeled folders in the 11 August 2026 package. HTTP-boundary evidence contains routed request decisions and tests. Legal and organisational controls contains the DPO, legal, procurement, data-governance and security artifacts. That separation gives an ICO reviewer a credible scope statement and prevents one traffic log being presented as proof for an entire compliance programme.

DeepInspect

DeepInspect supplies the HTTP-boundary portion of UK DPA AI audit evidence 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. Each permit, redaction or denial produces a signed, tamper-evident decision record outside the calling application's write path.

Those records let a reviewer reconcile approved providers with observed traffic, retrieve the policy used for event uk-support-summary-04, inspect restrictive outcomes under SEC-1187, bound affected requests and support a rights search where the application supplies a stable subject reference. DeepInspect leaves legal basis, notices, DPIA approval, contracts, transfer decisions, source-data correction, workforce controls and offline AI systems with their accountable owners. Book a technical deep dive at deepinspect.ai.