When does an AI use case need a data protection impact assessment before launch?

Why the DPIA decision has to happen before the AI tool goes live

If an AI use case touches personal data, the DPIA question belongs at the start of the project. Waiting until procurement is finished or the workflow is already embedded turns the assessment into a clean-up exercise.

For professional services firms, the practical test is simple: could this AI system change what happens to a client, employee, applicant, borrower, policyholder or matter file in a way they would reasonably care about? If yes, assess it before launch.

The safest answer is to run a DPIA when the AI use case creates high privacy risk

A data protection impact assessment is needed before launch when the AI use case is likely to create high risk for people. That risk can come from the data going in, the decision the tool supports, the scale of use, the lack of transparency, or the vendor architecture behind the tool.

In practice, run a DPIA before launch if the AI tool will process confidential client files, legal or financial records, health data, complaints, identity checks, HR material, vulnerable-customer data, call recordings, behavioural signals, or any other sensitive operational data. Also run one when the AI output will influence decisions about service, pricing, eligibility, advice, risk scoring, complaints, fraud, performance or case strategy.

Check whether an AI use case needs a pre-launch risk review

Use five trigger questions before treating the DPIA as optional

Ask these questions at intake, before pilots become business-as-usual:

• What personal data enters the system? Include prompts, uploaded files, transcripts, CRM notes, emails, case documents and metadata.
• What will the AI output affect? A drafting aide is lower risk than a tool that shapes advice, triage, eligibility, credit, insurance, legal strategy or complaint outcomes.
• Can the person understand or challenge what happened? If the workflow is hard to explain, record the transparency and review controls before launch.
• Who processes the data and where? The source article makes this point in a legal AI context: vendor answers on retention, model training, processing location and contractual guarantees are not minor details.
• What human supervision is required? If staff may rely on the output, document the review standard, escalation route and audit trail.

Confidentiality and vendor architecture are part of the DPIA decision

The source article is written for law firms worried about attorney-client privilege, but the same governance lesson applies across UK professional services: do not assess an AI tool only by its feature list. Assess the data pathway.

Before launch, record whether prompts and files are stored, used for model training, shared with sub-processors, processed outside approved regions, retained for debugging, or visible to vendor staff. If those answers are unclear, the use case should not move straight to live deployment.

For legal work, also capture how confidentiality, privilege and supervision are protected. For financial services and insurance, connect the same evidence to Consumer Duty, SM&CR accountability, complaints handling, vulnerable-customer treatment, operational resilience and model risk controls where relevant.

Set up an AI governance operating model for live tools

What to put in the DPIA file

A useful DPIA file should be short enough to maintain and clear enough to defend. Capture the business purpose, user group, personal data categories, special category data, data flow, vendor role, retention settings, training opt-out position, access controls, human review process, failure modes, affected people, mitigation actions and launch decision.

Do not bury the core decision. State whether the use case is approved, approved with controls, paused for redesign, or rejected. Name the accountable owner and the date for review.

A practical launch gate for AI projects

Make DPIA triage part of the AI project checklist. Every proposed use case should have a named owner, a data classification, a vendor due-diligence note, a supervision standard and a go-live decision. The full DPIA is required when that triage shows high privacy risk.

This keeps low-risk productivity use cases moving while stopping sensitive AI workflows from going live without the evidence a regulator, client or internal risk committee would expect.

Build AI launch controls into implementation projects

Conclusion

Run the DPIA before launch whenever the AI use case touches sensitive personal data, confidential client material, meaningful decisions, monitoring, profiling, vulnerable groups, or opaque vendor processing. The source article’s legal AI lesson is the right one: the hard questions are not anti-AI. They are how responsible adoption gets permission to scale.

Need a safer AI route for your firm?

If this article reflects a live decision in your practice, the useful next step is to map the workflows, confidentiality risks, supplier controls and governance gaps before tools spread informally.

• Map AI risk and opportunity
• Put usable AI governance in place
• Roll out AI with privacy and supplier controls
• See AI support for legal services