UK ICO AI Controls Mapping: Guidance, Owner, Test and Evidence

A customer-support request can carry a name, account history and complaint into a hosted model through one HTTPS POST. The control decision has to connect that event to an approved purpose, accountable controller, provider route, data class and policy outcome. That is the operating layer beneath the Information Commissioner's Office guidance on AI and data protection.

I use six fields for this UK ICO AI guidance AI controls mapping: objective, owner, implementation, test, evidence and coverage. The ICO guidance landing page says the guidance is under review following the Data (Use and Access) Act. Legal and the DPO should record that status beside the current legislative analysis rather than treating the guidance as frozen law.

Accountability and governance control

The ICO's accountability and governance guidance makes the controller accountable for compliance and demonstration when an AI system processes personal data. It calls for aligned structures, roles, responsibilities, training, policies and incentives, with governance proportionate to the use of AI.

Senior management owns the governance model, the DPO owns data-protection oversight and each AI service owner owns implementation. Test one production use against the approved system inventory, role map, policy set and review schedule. Evidence includes the system record, controller-or-processor analysis, approval minutes, owner attestations and open remediation items.

Observed HTTP model routes and policy decisions provide partial gateway coverage by exposing an unregistered provider or stale policy. Corporate accountability, training and role assignment sit outside that traffic boundary.

DPIA and risk-treatment control

The same ICO chapter describes a data protection impact assessment as a central accountability mechanism and says the high-risk decision is case-specific. Its AI DPIA discussion calls for the nature, scope, context and purposes of processing, data flows, data volume and sensitivity, intended outcomes, meaningful human involvement, processors, risks, alternatives and mitigations.

The DPO and business owner approve the assessment. Privacy engineering maps data flows, while security and model-risk teams own technical treatments. Select risk DPIA-24, inject a synthetic purple marker into the relevant HTTP route and verify the expected permit, redaction or denial. Preserve the test input, model destination, policy version, result and reviewer decision beside the DPIA treatment.

Coverage is partial because routed traffic can test a named treatment. Necessity, proportionality, residual-risk acceptance, consultation and prior ICO engagement remain organisational decisions.

Transparency control

The ICO's AI transparency guidance says privacy information should identify processing purposes, retention periods and recipients. Timing depends on how personal data was obtained, and the linked ICO material addresses explanations for AI-assisted decisions.

Privacy and legal own the approved information. Product owns presentation and version deployment. Run a clean-user test that captures the notice shown before the AI feature processes supplied personal data, then compare its purpose, provider and retention language with the system record. Evidence is the approved copy, dated interface capture, notice version, release record and sampled interaction reference.

Gateway coverage is outside scope for proving that a person saw the notice. An application-supplied notice-version value can join a request to the product record, but that correlation needs trustworthy application instrumentation.

Lawfulness, purpose and minimisation control

The ICO separates lawfulness, fairness and transparency into distinct chapters. At the request boundary, the implementable objective is narrower: send personal data only for an approved purpose, to an approved destination, with the minimum data classes the application needs for that task.

Legal owns lawful-basis and special-category analysis. The business owner defines purpose, and privacy engineering defines permitted data. Test an approved support-summary route with required fields, an unrelated account field and a special-category marker. The expected outcome should preserve necessary content and redact or deny the unrelated class under the recorded policy version.

Evidence includes the purpose register, data-field decision, route policy, test cases and sampled outcomes. Coverage can be full for applying a policy to routed HTTP traffic when the application supplies a trustworthy purpose value. Source-data collection, training data, retention and offline processing need separate controls.

Fairness and human-review control

The ICO guidance treats fairness across the AI lifecycle and connects automated decision-making safeguards to its fairness analysis. A request gateway can preserve inputs, routes and policy outcomes, yet a fairness conclusion requires population-level evaluation and the downstream decision context.

The product owner and model-risk team own the evaluation plan. Legal and the DPO review protected-group, Article 22 and equalities implications. Test a representative cohort under one model and application version, document error distribution and inspect cases where human review changed an outcome. Evidence includes dataset provenance, evaluation protocol, results, reviewer instructions, override records and remediation.

Gateway coverage remains partial for this control. Request records can reconstruct selected model calls and prove that an escalation rule fired. They cannot establish representative sampling, assess outcome disparity or prove that a human review was meaningful.

Security and model-query control

The ICO's security and data-minimisation chapter says security measures depend on the processing risk. It discusses AI supply chains, training-data movement, model inversion, membership inference and monitoring suspicious API queries, including account suspension or blocking where appropriate.

Security owns the threat model and AI platform owns enforcement. Test an unapproved provider, missing identity context, prohibited personal-data class and suspicious query sequence. Record restrictive outcomes, alerts, investigation ownership and clean retests. Evidence joins the threat model, provider inventory, policy, event sample and incident ticket.

Coverage can be full for route, identity-context and request-policy tests on HTTP model traffic. Source repositories, model weights, local inference, endpoint compromise and training pipelines require code, infrastructure and data-governance controls.

Individual-rights and processor controls

A defensible rights process needs the intake request, identity verification, search method, decision, response and execution evidence across every relevant store. Processor governance needs the approved service, instructions, security terms, retention, subprocessors and actual destination used by the AI feature.

Privacy operations owns rights handling. Procurement and legal own provider terms, and the platform owner owns route reconciliation. Test a synthetic subject request using a stable subject reference that can differ from the authenticated caller. Then compare the observed endpoint with the approved processor and region record.

Per-decision records provide partial coverage by identifying routed disclosures when the application supplies a stable subject reference. Source correction, deletion inside provider stores, contract terms and international-transfer analysis remain outside the gateway.

Consolidated mapping

• Accountability: Senior management, the DPO and service owner maintain the system and role file. Route inventory supplies partial evidence.
• DPIA: The DPO and business owner connect risks to treatments and tests. Request-path controls verify selected technical treatments.
• Transparency: Privacy and product prove the notice and timing. Gateway records provide correlation only.
• Purpose and minimisation: Legal, privacy and platform owners define and enforce approved data use. Coverage is full only with routed egress and trustworthy context.
• Fairness: Product, model risk, legal and the DPO evaluate outcomes and human review. Runtime samples supply partial evidence.
• Security: Security and AI platform test destination, identity, data-class and query policy. HTTP control coverage can be full for those cases.
• Rights and processors: Privacy, procurement and platform owners connect subject searches and provider routes. Coverage remains partial across those duties.

My opinion is that the grey Partial cells are the useful part of this map. A page of green cells would hide the legal, product and data work that a gateway was never designed to perform. Put the map on one screen and event DPIA-24 on another; every technical artifact should point to the owner who completes the objective.

DeepInspect

DeepInspect implements the HTTP request-path slice of this mapping for authenticated users or agents calling LLM endpoints. It evaluates application-supplied identity and purpose context, role, data classification, destination and policy before forwarding a request, then creates a signed, tamper-evident decision record outside the calling application's write path.

Those records support route reconciliation, minimisation tests, suspicious-query controls, sampled DPIA treatments and subject searches where the application supplies a stable reference. DeepInspect leaves legal interpretation, notice delivery, fairness evaluation, contracts, training data, source-system rights execution and offline AI controls with the owners named above. Book a technical deep dive at deepinspect.ai.