UK DPA AI Compliance Checklist: 10 Tests for Deployed Model Traffic

One HTTPS request can combine a customer name, support history and account status before sending the assembled prompt to a model provider. A UK data protection review has to connect that event to an approved purpose, lawful basis, processor arrangement, risk decision and security control. This UK DPA AI compliance checklist turns those dependencies into tests that another team can repeat.

The legal baseline is the latest revised UK GDPR, supplemented by the Data Protection Act 2018. The ICO marks its AI guidance as under review following the Data (Use and Access) Act. Use current legislation for operative duties and record the date on which the guidance was consulted.

1. Inventory AI processing and actual destinations

Article 30 specifies records of processing activities for controllers and processors. The 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.

Owner: privacy with AI platform engineering.

Done when: every deployed AI feature has a row naming its purpose, role, data classes, provider, endpoint, processing location, retention rule and system owner. Reconcile that register against observed HTTP model destinations. Give each unknown hostname a named investigator.

Keep: Article 30 record, AI inventory, route export and reconciliation result.

2. Approve a lawful basis for each purpose

Article 5 requires lawful, fair and transparent processing for specified purposes, with data limited to what is necessary. Article 6 supplies the lawful-basis framework. Articles 9 and 10 add conditions for special category and criminal-offence data.

Owner: privacy and legal share this documented decision.

Done when: each inventory row links to a documented purpose and lawful-basis decision. Where the payload can contain special category or criminal-offence data, the file also identifies the applicable condition and any additional DPA 2018 requirement.

Keep: purpose register, lawful-basis assessment, approval date and review trigger.

3. Give people usable information about the AI processing

The transparency principle in Article 5 applies when AI processes personal data. The ICO's current AI transparency guidance points organisations to information about purposes, retention and rights, with the detail adapted to the processing and audience.

Owner: product and privacy share the notice control.

Done when: a synthetic user can reach the notice before the relevant processing begins. The notice version links to the feature, provider categories, purpose, retention rule and rights route represented in the inventory.

Keep: rendered notice, version history, usability review and deployment record.

4. Complete the DPIA where the risk threshold is met

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

Owner: privacy with the business decision owner, security and the DPO.

Done when: every use has a recorded threshold decision before launch. Qualifying uses have an approved DPIA tied to model version, data flow, provider, mitigations and a change trigger.

Keep: threshold screen, DPIA, DPO advice, approval and risk register.

5. Minimise the payload at the request boundary

Article 5 limits personal data to what is necessary for the approved purpose. A support-summary request may need the latest message and case category while the application has access to an entire account record.

Owner: product, data governance and AI platform engineering.

Done when: a test payload containing approved fields plus a visible purple synthetic identifier is classified before transmission. Excess fields receive the configured redaction or refusal, and the record identifies the policy version used.

Keep: approved schema, test payload, classification output, decision record and exception procedure.

6. Bind model access to the originating principal and purpose

Authentication of a shared application credential establishes the workload. The compliance test also needs the person or agent that originated the action, plus an application-supplied purpose value that policy can evaluate.

Owner: IAM and AI platform engineering, with privacy approval of purpose rules.

Done when: the same data class is permitted for an approved support purpose and refused for an unapproved destination or role. Both records carry the originating principal, workload, purpose, endpoint and outcome.

Keep: identity mapping, purpose policy, permit sample, denial sample and correlation trace.

7. Test security under normal and failure conditions

Article 32 requires technical and organisational measures appropriate to risk. Its factors include implementation costs, the processing context, available technical capabilities and risks to people. The provision includes ongoing confidentiality, integrity, availability and resilience, restoration capability, and regular testing and evaluation where appropriate.

Owner: security engineering owns the failure tests and retests.

Done when: tests cover an unknown endpoint, missing identity context and a policy-evaluator timeout. Each condition produces the approved restrictive response, alert and independently retrievable event.

Keep: test plan, console capture, decision records, alert ticket and clean retest.

8. Govern processors and verify the route used

Article 28 governs processor selection and contract terms, including documented instructions, confidentiality, security, assistance, deletion or return, audit information and subprocessor conditions.

Owner: procurement, legal and privacy.

Done when: every hosted model route maps to an approved provider file and contract. A sample compares the observed endpoint and configured region with that arrangement. Any mismatch opens a privacy and procurement review.

Keep: due diligence, signed terms, subprocessor list, route map, deletion instructions and discrepancy ticket.

9. Make retention and individual-rights retrieval operational

Article 5 includes storage limitation. UK GDPR rights provisions cover access, rectification, erasure and restriction subject to their conditions. Runtime retrieval needs a stable data-subject reference when the person described in a prompt differs from the caller.

Owner: data governance and privacy operations.

Done when: decision records, application prompts and provider-held data have approved retention rules. A synthetic subject-range request finds relevant disclosures, routes source correction to its owner and records the rights decision.

Keep: retention schedule, disposal test, search query, disclosure export, correction ticket and response record.

10. Reconstruct one event without relying on the calling application

Accountability under Article 5 requires the controller to demonstrate compliance. Per-request records are an implementation evidence pattern rather than a universal statutory logging format. Their value comes from reconstructing how an approved control operated.

Owner: internal audit with privacy and platform engineering.

Done when: a reviewer selects one denied event and retrieves its timestamp, originating principal, purpose, data class, destination, policy version, outcome and integrity evidence. The event joins to the Article 30 row, DPIA risk, processor file and security test without asking the calling application to rewrite history.

Keep: sample query, export, integrity verification, evidence index and reviewer sign-off.

Completion register

Use one scannable record per item:

• Item and owner: the control number and one accountable function.
• State: Pass, Gap or Not applicable, with the reason.
• Test date: the date on which the completion condition ran.
• Evidence: a direct artifact link and stable identifier.
• Remediation: owner, due date and retest result for every Gap.

My view is that item 10 deserves more attention than a glossy AI policy. A white policy page can list approved providers. A signed denial row showing the production endpoint at 02:14 answers the factual question an investigator will ask.

DeepInspect

DeepInspect supplies the request-boundary controls and evidence in items 1, 5, 6, 7, 8 and 10. It sits inline between authenticated users or agents and HTTP-based LLM endpoints, evaluates application-supplied identity and purpose context, role, data classification, destination and policy, then records each permit, redaction or denial outside the calling application's write path.

The legal decisions and organisational controls remain with privacy, legal, procurement, data governance and the business owner. DeepInspect gives those teams an observed route inventory, repeatable policy tests and signed, tamper-evident decision records for the HTTP slice they need to examine. Book a technical deep dive at deepinspect.ai.