The short answer
- AI does not create an exemption from UK data-protection principles.
- A DPIA is required when planned processing is likely to create high risk for individuals.
- A vendor contract does not transfer the controller’s overall accountability.
- Human review must be meaningful when a process relies on it as a safeguard.
- Privacy, security and explainability require continuing operation after launch.
1. Map the purpose, data and accountable parties
Start with a data-flow map for the complete automation. Record where information originates, which fields enter each system, what the model receives, what new information or inferences it creates, where outputs are stored, who can access them, which actions follow and when records are deleted. Include test, support and logging environments; personal data copied into debugging tools is still personal data.[1]
Write one specific purpose for each processing activity. ‘Improve the business with AI’ is not a usable purpose. A purpose such as triaging support requests for a named service can be assessed against necessity, fairness and customer expectations. If the team later wants to reuse the same information for training, marketing or staff evaluation, that is a separate purpose that needs its own assessment.[3]
Determine whether each organisation is a controller, joint controller or processor for the particular activity. The ICO describes controllers as the parties that determine the purposes and means of processing. Labels in a supplier contract do not settle the question by themselves. Record the internal owner, data-protection contact, system owner and person authorised to stop the automation.[1]
- Inventory personal, special-category and criminal-offence data
- Map vendors, subprocessors, storage locations and international transfers
- Document purpose, retention and deletion for inputs, outputs and logs
- Assign controller, processor, business-owner and escalation roles
2. Establish lawfulness, fairness and transparency
Identify and document an appropriate lawful basis before processing begins. Consent is not the default answer, and a contract basis applies only when the processing is objectively necessary to perform a contract with the individual or take a requested pre-contractual step. Special-category or criminal-offence data needs additional conditions. Obtain specialist advice when the basis or sector rules are uncertain.[3]
Test whether people would reasonably expect the proposed use and whether it creates an unjustified adverse effect. Fairness is wider than technical accuracy. A system can produce a statistically plausible result while disadvantaging a group, using information outside the stated purpose or making an action difficult to challenge. Record who might be affected, including people represented indirectly in training, reference or matched data.[3]
Update privacy information before collection or reuse. Explain the purpose, data categories, sources, recipients, retention, rights and any relevant automated decision in clear language. Do not describe a process as ‘human reviewed’ unless the reviewer has time, authority, evidence and competence to change the outcome. The ICO’s AI explanation guidance emphasises transparency, accountability, context and impact.[1]
- Record the lawful basis and any additional condition
- Assess reasonable expectations and possible adverse effects
- Make privacy information accurate before deployment
- Describe human involvement as it works in practice
3. Screen for a DPIA and significant decisions
Screen the project for a data protection impact assessment before building around irreversible choices. The ICO says a DPIA is required where processing is likely to result in high risk to individuals’ rights and freedoms. Relevant indicators include systematic evaluation, significant automated decisions, sensitive or large-scale data, matching datasets, vulnerable people, monitoring and innovative uses of technology.[2]
A DPIA is a decision process, not a document created after launch. Describe the processing and necessity, consult relevant people, assess likelihood and severity of harm, define measures, identify residual risk and record approval. The result must be capable of changing or stopping the design. If high residual risk cannot be reduced, the ICO explains that prior consultation may be required before proceeding.[2]
Give special attention to decisions producing legal or similarly significant effects. Record whether the action is solely automated, what information the person receives, how they can request intervention, express their view and contest an outcome, and how staff perform a genuinely independent review. The exact legal analysis is context-specific and should be checked against current ICO guidance.[1][2]
- Complete and retain a DPIA screening decision
- Run the DPIA early enough to influence architecture and scope
- Document harm scenarios, controls, residual risk and approval
- Design intervention, explanation and challenge paths where required
4. Minimise data and control suppliers
The ICO’s data-minimisation principle requires personal data to be adequate, relevant and limited to what is necessary. Remove fields that do not serve the stated purpose, redact unnecessary identifiers, constrain retrieval and avoid sending entire records when a smaller selection will do. Use realistic synthetic or de-identified test data where it can provide valid evidence without exposing real people.[4]
Perform supplier due diligence at the service configuration you will actually use. Record whether prompts and outputs are retained, used for model improvement, reviewed by people or transferred elsewhere. Check access controls, encryption, audit capability, deletion, incident support, service changes and subprocessor management. A general security badge does not answer how your particular data moves through the product.
When a processor handles personal data for a controller, the ICO requires a written contract with specified protections. The agreement should cover instructions, confidentiality, security, subprocessors, rights assistance, breach support, DPIAs, deletion or return and audit information. Keep an exit plan that covers exported records, workflow configuration, credentials, logs and verified deletion from connected services.[5]
- Send only fields necessary for the documented purpose
- Limit access by role and environment
- Verify vendor retention, training-use and subprocessor settings
- Put controller-processor terms in writing where required
- Test deletion, export and supplier-exit procedures
5. Test, operate and review the complete system
Build a representative evaluation set before release. Include routine inputs, missing information, conflicting records, edge cases, different affected groups, malicious content and examples that should be refused or escalated. Define acceptable behaviour, uncertainty handling and evidence requirements in advance. Model output quality is only one measure; evaluate the downstream action and the human-machine workflow.
Create operating controls for access reviews, log review, incidents, data-subject requests, vendor notices, model changes, prompt or rule changes and performance drift. Assign a person to investigate complaints and false outputs. Preserve enough traceability to understand which version, data and approval path produced an action without retaining excessive personal data indefinitely.
Review the DPIA and data map when the purpose, data, supplier, model, integration, affected population or consequence changes. NIST’s voluntary AI RMF reinforces continuous govern, map, measure and manage activities throughout the lifecycle. ICO AI and DPIA materials also note that parts of the guidance are under review following UK data-law changes, so verify the current official position and obtain legal advice for high-impact deployments.[1][2][6]
- Test the system before release and after material changes
- Monitor outcomes, complaints, failures and group-level impacts
- Exercise access, deletion, incident and rollback procedures
- Revisit the DPIA when processing or risk changes
- Check current ICO guidance before each production launch
Sources and further guidance
Blancc uses primary guidance where factual or regulatory context matters. Recommendations remain general and should be assessed against the specific business, audience, product, and risk.
Read Blancc’s editorial standards and corrections policy for source selection, illustrative labels, update dates, software assistance and corrections.