Building a DPIA for Private AI: The Exact Steps and Evidence the ICO Expects | Insights

UK GDPR Article 35 requires a Data Protection Impact Assessment before processing that is likely to result in a high risk to data subjects. AI processing of client-privileged legal files, HMRC correspondence, and financial records triggers this requirement. The DUAA 2025 extends DPIA obligations to automated decision-making with material effects. DPIAs must be retained for five years minimum and produced on ICO demand via enhanced information notices.

If your firm processes client data through AI tools — sovereign or otherwise — and has not completed a DPIA, that is not a planning gap. It is a present compliance failure that the ICO can now compel you to evidence.

For the ICO’s enforcement methodology and penalty escalation factors for AI-related breaches, read our parent article. This piece provides the step-by-step methodology for completing a DPIA that satisfies the ICO’s expectations — specifically for a zero-egress sovereign AI deployment.

Step 1: Establish the DPIA Trigger

Article 35(1) requires a DPIA where processing is “likely to result in a high risk to the rights and freedoms of natural persons.” Article 35(3) provides specific examples, including systematic and extensive evaluation of personal aspects based on automated processing (directly applicable to AI-assisted document review, contract analysis, and case prioritisation) and processing on a large scale of special categories of data.

For a Scottish law firm, the trigger analysis is straightforward. Client files routinely contain legal professional privilege, personal financial data, health information (in family or personal injury matters), and commercially sensitive details. AI processing of these files — whether by a public tool or a sovereign deployment — constitutes high-risk processing. The DPIA is mandatory.

Document the trigger clearly: “This DPIA is conducted pursuant to UK GDPR Article 35(1) because the firm’s sovereign AI deployment processes client-privileged data, including categories of data subject to legal professional privilege, using automated means.”

Step 2: Describe the Processing

The ICO expects a clear, precise description of what happens to the data. For a sovereign AI deployment, this description is architecturally constrained — which makes it significantly simpler than a cloud AI DPIA.

Data inputs: Authorised staff submit prompts and upload documents (PDFs, contracts, matter files, correspondence) through the user interface.

Processing operations: Prompts are submitted to the locally running inference layer for open-weight model inference. Documents are chunked, embedded via the local embedding model, and stored as vector representations on the encrypted persistent storage. Retrieval-Augmented Generation queries match prompts against stored embeddings and provide source-cited responses.

Data outputs: AI-generated text responses displayed in the user interface. Source citations referencing specific document passages. Conversation histories stored in the application database on the encrypted block storage.

Data location: All processing, storage, and inference occurs on the dedicated bare-metal server within a UK data centre. No data leaves the server. Egress is sealed at the network level — no outbound data path to any external AI service or API.

Data recipients: No third-party AI vendor receives any data. The infrastructure provider supplies hypervisor-level encrypted infrastructure. The self-hosted access layer provides access control with no third-party holding access metadata. Private AI Ltd holds zero access post-deployment.

Step 3: Assess Necessity and Proportionality

The ICO expects the DPIA to demonstrate that the processing is necessary and proportionate to the firm’s legitimate purpose.

Necessity: The firm requires AI capability to maintain competitive parity, accelerate document review, and improve advisory efficiency. Public AI tools create unacceptable compliance risk (Shadow AI). A sovereign deployment delivers equivalent capability without the compliance exposure.

Proportionality: The processing is limited to data the firm already holds and has a lawful basis to process (client instructions, contractual necessity, legitimate interests). The AI environment processes only data explicitly submitted by authorised users. No bulk data ingestion. No automated scraping. No processing beyond the scope of the user’s instruction.

Data minimisation: Role-based access controls within the user interface govern access to specific document collections. Users access only the data relevant to their role and matters. The AI model is static — client inputs do not modify model weights or contribute to training.

Step 4: Identify and Assess Risks

For each identified risk, the DPIA must document the risk description, likelihood, severity, and the specific measure that mitigates it.

Risk: Unauthorised data egress to third-party AI vendors. Likelihood: Eliminated. Mitigation: Sealed network environment with no outbound data path. The architecture enforces this at the network level — not through application-layer policy, but by design. Independently verifiable.

Risk: Unauthorised access to the AI environment. Likelihood: Low. Mitigation: Self-hosted access layer with mandatory two-factor authentication on every session. No exposed ports. No public IP. Access logs identity-correlated and timestamped.

Risk: Data breach via compromised storage. Likelihood: Low. Mitigation: Encrypted persistent block storage with hypervisor-managed encryption at rest. Hardware-level tenant isolation for compute.

Risk: AI hallucination leading to incorrect legal advice. Likelihood: Medium. Mitigation: All AI output is advisory. Professional sign-off by a qualified solicitor is mandatory before any AI-assisted work product is relied upon or communicated to clients. Firm’s acceptable use policy requires human review of all AI outputs.

Risk: Supply chain compromise via tampered software update. Likelihood: Low. Mitigation: All application dependencies installed via hash-checked package installs. The inference layer and other packages verified against pre-seeded checksums. SBOM drift detection at upgrade commencement. Forward cryptographic verification inherent to the install process.

Risk: Incidental data exposure during vendor support. Likelihood: Low. Mitigation: Over-the-Shoulder support model with Clean Screen Policy Schedule. Private AI Ltd engineer observes but does not access. JIT Support (if required) constitutes a Level 1 or Level 2 access event under Schedule 2 of the standing DPA, with absolute prohibitions on data extraction and full keystroke audit logging.

Step 5: Document the Processor Map

The DPIA must identify every Data Processor and the legal basis for each processing relationship.

UK bare-metal infrastructure provider — Direct Data Processor. UK entity. Domestic Article 28 DPA. No international transfer.
Private AI Ltd — Standing Data Processor under Article 4(8) UK GDPR. Zero Standing Privileges architecture. Zero active access credentials in the Default Operating State. Active processing limited to authorised JIT Support Sessions under the standing DPA.

No AI vendor appears in the processor map. No sub-processor chain extends beyond the single directly contracted entity. The self-hosted access layer introduces no additional processor — access control is handled entirely within the client’s own contracted infrastructure.

Step 6: File, Retain, and Review

Sign the DPIA. Date it. File it in the firm’s data protection records. Retain it for a minimum of five years as required by the DUAA 2025. Make it available to the ICO on request without delay.

Schedule annual reviews — or sooner if the architecture changes, new models are deployed, or the processing scope expands. In practice, a sovereign bare-metal deployment changes infrequently: model upgrades occur during scheduled maintenance windows, and the architecture itself is stable. Annual review is typically sufficient.

The completed DPIA is not a burden. It is the single most valuable document your firm can produce in an ICO investigation — evidence that the firm assessed the risk, identified the controls, and verified them before processing commenced.

Talk to our team to receive a pre-structured DPIA template aligned to Private AI Ltd’s sovereign deployment architecture.

Private AI Ltd (SC881079)