We have written, reviewed or advised on more than thirty DPIAs for public-sector AI use cases in the last two years — FOI drafting, casework triage, eligibility pre-checks, planning application summarisation, childrens' services early help, adults' social care demand modelling. Some are deployed. Some were never deployed, because the DPIA found something the design had missed. Both outcomes are correct.
What a DPIA is for, in AI-speak
A Data Protection Impact Assessment is not a tickbox before deployment. It is the structured space in which the organisation decides whether the risk of processing personal data is proportionate to the benefit. For AI use cases, the usual weaknesses are:
- The benefit is poorly specified and overstated
- The alternative (non-AI) path is not analysed
- The bias, accuracy and drift risks are waved at, not quantified
- The human-in-the-loop is assumed, not designed
- The retention, deletion and right-to-object paths are missing
A good DPIA fixes each of these.
Five patterns that recur
Pattern 1 — Inbound correspondence triage
FOIs, EIRs, complaints, casework. An LLM classifies and drafts a response; a human reviews. The DPIA must state: which personal data is in scope (the requester's, third parties'), whether personal data leaves the tenancy, what the vendor's data-processing stance is, what "drafted by AI" looks like to the recipient, and how the reviewer can decline. Our usual conclusion: low residual risk when deployed in-tenancy with human review, with specific controls around third-party data and sensitive categories.
Pattern 2 — Demand forecasting
Adult social care waiting lists, temporary accommodation demand, SEND forecasting. The DPIA must state: whether the model uses personal data or only aggregates, how aggregates are derived, what the minimum cell size is, who sees the output, and what decision the forecast supports. Our usual conclusion: low risk if the model is aggregate-only, with explicit control on minimum cell sizes; moderate risk if individual-level features are used, with additional mitigations.
Pattern 3 — Eligibility pre-checks
Benefits triage, council tax support, revenue review. The DPIA must state: whether the model makes a decision or supports one, how it is explained to the resident, what the appeal route is, what the bias monitoring looks like, and what happens if the model is wrong. Our usual conclusion: moderate-to-high risk; requires explicit human-in-the-loop, bias monitoring, and a resident-facing explanation. We decline engagements where the client wants fully automated decisions in this space.
Pattern 4 — Children's and adults' services early help
Risk-signal models. The most sensitive and the most contested. The DPIA must be written with the DPO, the Director of Children's / Adults' Services, a legal representative, and a named external ethics reviewer. Pattern is high risk by default. We have advised against live deployment in three engagements. We have supported supervised research-mode pilots in two others.
Pattern 5 — Document summarisation
Planning applications, licensing, scrutiny packs. Lower sensitivity but high accuracy expectation. The DPIA must state: what happens when the summary is wrong, who is accountable, and how accuracy is monitored. Our usual conclusion: low risk with strong evaluation discipline and clear labelling of summaries.
What makes a DPIA pass review
- A stated benefit, in quantifiable terms. Not "efficiency"; "a reduction in average FOI handling time from 4.2 hours to 1.2 hours, measured across a 200-request sample".
- A non-AI alternative. What would you do instead? Often a simple rules-based triage. If the AI is only marginally better, the risk-benefit case may not carry.
- An evaluation regime. How will you know it is still working next year? Not "we will monitor". A sampling plan, an evaluation harness, a named owner.
- A deprecation path. How is this turned off if the risk profile changes? Who authorises that? When is that decision reviewed?
- Honest residual risk. A DPIA that concludes "low" everywhere has not done its job. A small number of "medium" findings, with stated mitigations, shows the assessment has bitten.
A template you can use
We do not publish our full DPIA template externally — it changes often. But the sections below are what every council we work with expects:
- Purpose and scope, including the benefit in quantified terms
- Data map: source, classification, retention, flow, vendor
- Lawful basis, including Article 6 and, if applicable, Article 9
- Necessity and proportionality, including the non-AI alternative
- Bias, accuracy and drift assessment, with evaluation plan
- Human-in-the-loop design
- Individual rights: information, access, objection, rectification, erasure
- Third-party processors and contracts
- Security controls, including tenancy and logging
- Ongoing monitoring and review cadence
- Residual risk and mitigations
- Deprecation path
- Sign-off: DPO, SIRO, service director
The DPO is your friend
Every good AI deployment we have landed in public sector has been co-authored with the DPO. Every troubled one has treated the DPIA as a late-stage sign-off. The quickest route to a live service is to bring the DPO into week one, not week nine.