When exactly does an AI feature require a data protection impact assessment?

Whenever the processing is likely to result in a high risk to people's rights and freedoms, with three named cases that always qualify: a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based; large-scale processing of special-category or criminal-offence data; and systematic monitoring of a publicly accessible area on a large scale. Most AI features that score, rank, personalise, recommend or flag individuals fall into the first case. Beyond the named three, national supervisory authorities publish lists of operations that always require an assessment, and those lists routinely name innovative technology, artificial intelligence, biometric matching, data combined from multiple sources, and processing of employee or child data. The practical test used by most privacy teams is a nine-criteria screen: if the processing hits two or more of evaluation or scoring, automated decision-making with significant effect, systematic monitoring, sensitive data, large scale, matched or combined datasets, vulnerable data subjects, innovative use of technology, and processing that prevents people exercising a right or using a service, an assessment is expected.

Our AI vendor says it already completed a DPIA. Does that cover us?

No. The obligation sits with the controller — the organisation deciding why and how the personal data is processed — and deploying a vendor's model against your users makes you the controller of that deployment. The vendor is usually a processor, and a processor's duty is to assist you with your assessment by providing the information you need, not to perform it for you. What the vendor's document can legitimately give you is the technical layer: model architecture, training-data provenance, retention, sub-processors, security measures, known accuracy and error characteristics. What it cannot give you is the part that matters most in an enforcement conversation — your lawful basis, your necessity and proportionality analysis for your users, the specific risks in your context, and the mitigations you chose. Ask for the vendor pack, attach it as an annex, and write your own assessment around it.

What has to be in the assessment for it to be adequate?

Four elements are mandatory and a fifth is effectively mandatory in practice. First, a systematic description of the processing operations and their purposes, including any legitimate interests pursued. Second, an assessment of the necessity and proportionality of the processing in relation to those purposes — meaning an honest answer to whether a less intrusive design would achieve the same goal, which is the section most assessments skip. Third, an assessment of the risks to the rights and freedoms of the people involved. Fourth, the measures envisaged to address those risks, including safeguards, security measures and mechanisms that demonstrate compliance. The fifth, practically required, is evidence of the process itself: the data protection officer's advice, whether the views of data subjects or their representatives were sought, and the date and version. An assessment that reads as a description with no residual-risk rating and no rejected alternatives will not satisfy a regulator.

What is prior consultation, and how likely is it that we need it?

If the assessment concludes that the processing would result in a high risk and you cannot mitigate that risk to an acceptable level, you must consult the supervisory authority before starting the processing. The trigger is the residual risk after mitigation, not the inherent risk before it — which is why the residual-risk rating is the most consequential line in the document. In practice the requirement is rare, because the ordinary outcome of a competent assessment is a set of mitigations that bring residual risk down. It becomes live when the mitigation you would need is the one you are unwilling to implement: a fully automated decision with significant effect and no human review, biometric identification without a solid basis, or training on user content where opt-out is technically impossible. Consultation timelines run to several weeks and can extend, so discovering the need a fortnight before launch is a schedule event as much as a legal one.

Do we need a new assessment every time we change the model?

Not for every change, but the assessment is a living record and must be reviewed when the risk presented by the processing changes. Four changes reliably require a revisit: a new purpose for the same data, a new category of data entering the pipeline, a change in who is affected such as extending a feature from employees to customers or from adults to minors, and a change in the decision consequence such as a recommendation becoming an automated action. Swapping the underlying model provider also counts, because sub-processors, training practices, retention and data location all change with it. A sensible cadence is a scheduled annual review plus an event-driven trigger wired into your change process, so that the question is asked by the release checklist rather than remembered by a person.

When Your AI Feature Needs a DPIA 2026: Data Protection Impact Assessment Triggers

Why AI Features Cross the Threshold by Default

The threshold is not "are you doing something controversial." It is whether the processing is likely to result in a high risk to people's rights and freedoms, judged on the nature, scope, context and purposes of what you are building. Three categories are named outright as always qualifying, and the first of them — systematic and extensive evaluation of personal aspects by automated means, including profiling, where decisions with legal or similarly significant effects follow — describes the standard architecture of a modern AI feature.

Teams talk themselves out of it in two ways. The first is scale: "we only have a few thousand users." Scale is one factor among several, not a gate, and a small user base processing sensitive inferences about vulnerable people can present higher risk than a large one processing preferences about products. The second is consequence: "the model only makes a suggestion, a human decides." That argument works when the human review is real — a competent person, with authority to overturn, who sees the underlying inputs and does not approve at a rate indistinguishable from rubber-stamping. It does not work when the human is a queue.

There is also a supervisory-authority layer people forget. National regulators publish lists of operations that always require an assessment in their jurisdiction, and those lists commonly name innovative technologies, artificial intelligence applied to individuals, biometric processing, datasets combined from multiple sources, and processing of employee or child data. If you operate across several member states, the union of those lists is your effective trigger set.

The Nine-Criteria Screen, Applied to Real Features

Evaluation, scoring and prediction

Lead scoring, churn prediction, credit-adjacent risk models, health or wellbeing inference, fraud probability, content-quality ranking applied to a named author, employee productivity scoring.

Why it counts: This is the single most common trigger, and it is met even when the score is only shown internally. The criterion is about building an evaluation of personal aspects, not about who gets to read it.

Automated decisions with significant effect

Auto-rejecting an application, suspending an account, throttling access, setting an individual price, routing someone to a worse tier of service, or filtering a candidate out before any person sees the file.

Why it counts: Denial of a service or an opportunity is the paradigm case of a similarly significant effect. Where this criterion is met, a second and separate rulebook on automated decision-making also engages, with its own transparency and human-intervention duties.

Systematic monitoring

Session recording, workplace activity analytics, camera analytics in a store or lobby, always-on assistants that observe a workspace, driver or device telemetry attributed to an individual.

Why it counts: Monitoring is high risk partly because the person cannot easily avoid it and often does not know its extent. Publicly accessible areas are called out expressly, but workplace monitoring reaches the same conclusion through the vulnerability criterion.

Sensitive data and vulnerable people

Health context in a support transcript, biometric or voice data, inferences about religion or union membership drawn from free text, and any feature serving children, patients, employees, applicants or benefit recipients.

Why it counts: Special-category data at scale is a named always-qualifies case. Inference matters here: you do not have to ask for sensitive data to end up holding it, and a model that derives it has created it as surely as a form field would have.

Innovative use and combined datasets

Applying a general-purpose model to a new internal use case, enriching first-party records with purchased or scraped data, joining behavioural and identity graphs, or building a retrieval index across systems that were previously separate.

Why it counts: Combination is a risk multiplier because it defeats the expectations under which each dataset was originally collected. Novelty is a criterion in its own right, on the reasoning that unknown risks cannot be managed by precedent.

The Three Sections Assessments Actually Fail On

Necessity and proportionality. This section is supposed to record the less intrusive designs you considered and rejected, and why. Most versions assert that the processing is necessary for the purpose without testing whether a smaller data set, a shorter retention period, aggregation, on-device inference or an opt-in cohort would have achieved the same outcome. An assessment with no rejected alternative reads as a justification written after the decision.
Residual risk. Inherent risk minus mitigation equals residual risk, and residual risk is what decides whether you may proceed at all or must consult the regulator first. Documents that list mitigations but never state the remaining risk level have skipped the one output the rest of the analysis exists to produce.
The lawful basis for training. Deploying a model and improving a model are separate processing operations with separate bases. Teams settle the deployment basis carefully and then let user content flow into training on the same paperwork. If the basis for training is legitimate interests, the balancing test belongs in the file, along with the objection route and evidence that the route actually removes the data from future training runs.

Who Writes It When a Vendor Model Is Involved

The controller writes it. If you decide to run a hosted model over your users' data for your purposes, that is your processing, and the model provider is normally a processor obliged to assist you with the assessment on request. The assistance duty is real and worth invoking in writing: ask for training-data provenance, retention and deletion behaviour, the sub-processor list and locations, security certifications, documented accuracy and error characteristics, and confirmation of whether your content is used to improve their models.

Two structures complicate this. Where the provider genuinely determines its own purposes — most commonly by training on your data for its own product — it is acting as a controller for that operation, and you need to establish which of you is responsible for what before you can describe the processing at all. And where a feature is embedded by a platform you resell, you may be a joint controller with an obligation to set out the respective responsibilities in an arrangement, including who answers when a person exercises a right.

The Pre-Launch Assessment Checklist

Run this at design time for any feature that touches individual-level data. The screening step takes under an hour; the full assessment is only triggered for a minority of features, and the screening record is what proves you asked.

1. Screening and Scope

☐Run the nine-criteria screen and record the answer even when the outcome is 'no assessment required'
☐Check the supervisory-authority mandatory lists for every jurisdiction you serve, not only your lead one
☐Define the processing boundary precisely: inference, logging, evaluation, fine-tuning and support access are separate operations
☐Identify whether you are controller, joint controller or processor for each operation in the boundary
☐Set the trigger point in the release process so screening happens at design, not at launch review

2. The Analysis

☐Describe data flows end to end, including prompt content, retrieval sources, embeddings and logs
☐State the lawful basis separately for deployment, for improvement and for evaluation
☐Document at least two less intrusive alternatives considered and the reason each was rejected
☐Assess risks to people specifically — wrongful denial, exposure, discrimination, loss of control — not risks to the company
☐Record accuracy and error characteristics, including how errors distribute across groups

3. Mitigation and Sign-Off

☐Map each identified risk to a named mitigation with an owner and an implementation date
☐State residual risk explicitly after mitigation and have it accepted by someone with authority to accept it
☐Record the data protection officer's advice, and whether data-subject views were sought or why not
☐Trigger prior consultation with the supervisory authority if residual high risk remains, and build the timeline into the plan
☐Version and date the document; keep the superseded versions rather than overwriting

4. After Launch

☐Wire a review trigger into change management for new purposes, new data, new populations or stronger consequences
☐Re-open the assessment when the model provider or sub-processor changes
☐Verify the mitigations shipped — an unimplemented mitigation is worse evidence than none, because you documented the risk
☐Schedule an annual review with a recorded outcome even if nothing changed
☐Keep the assessment retrievable on request; it is the first artefact a regulator asks for

Frequently Asked Questions

We shipped the feature months ago and never did an assessment. What now?

Do it now, and date it honestly. Backdating is the one move that converts a compliance gap into a credibility problem, and version histories in document systems are trivially recoverable. Write the assessment against the processing as it currently exists, identify risks, and where a mitigation is missing, record it as an open item with an owner and a date rather than describing a control you do not have. If the analysis surfaces residual high risk you cannot mitigate, you are in the uncomfortable position of running processing that should have been consulted on first — the response is to mitigate down quickly, or to pause the specific operation causing it, and to document the decision either way. Regulators distinguish between an organisation that found and fixed its own gap and one that produced a clean document describing a system that does not exist.

Does an assessment apply to internal tools used only on employees?

Yes, and employee-facing deployments frequently carry higher risk than customer-facing ones. Employees are treated as vulnerable data subjects because the power imbalance in the relationship makes consent unreliable and makes objecting costly. That vulnerability is one of the screening criteria, so an internal tool that scores productivity, monitors activity, ranks performance or screens applicants can cross the threshold on a fraction of the volume a consumer feature would need. Several supervisory authorities name employee monitoring on their mandatory lists directly. The practical implication is that the internal AI pilot nobody thought of as a product — the one procured on a team credit card to summarise activity or flag underperformance — is more likely to require a formal assessment than the customer feature that went through review.

How does this relate to the risk assessments required by AI-specific legislation?

They are separate obligations with overlapping content and different owners, and neither substitutes for the other. The data protection assessment is about risk to people from processing their personal data, sits with the controller, and applies whenever the threshold is met regardless of what the system is for. AI-specific regimes impose their own conformity, risk-management and documentation duties keyed to how the system is classified and to whether you built it or deployed it, and they cover matters privacy law does not reach — safety, robustness, accuracy thresholds, human-oversight design. In a well-run programme they share evidence: one description of the system, one data-flow map, one accuracy and error analysis, feeding two documents with different framing. What fails is trying to satisfy both with a single file, because reviewers on each side then find their required sections missing.

Can we rely on legitimate interests for training a model on customer content?

It is available, but it is the hardest of the bases to hold and it requires you to do the work in advance rather than assert it later. The three-part test asks whether the interest is legitimate, whether the processing is necessary to achieve it, and whether it is overridden by the interests and fundamental rights of the people involved — and that last limb turns on their reasonable expectations. Content submitted to get a job done, especially content containing third-party personal data the submitter did not consent on behalf of, does not carry an expectation of becoming training material. If you rely on this basis, the balancing test must be written down, an unconditional objection route must exist and be easy to find, and the objection must actually remove the data from future training. Special-category data cannot ride on legitimate interests at all, which matters more than teams expect once free-text fields are in scope.

What does a regulator actually ask for when this comes up?

Almost always the same opening sequence: the assessment itself with its version history, the data-flow description, the lawful-basis analysis, the record of processing activities entry for the operation, and the processor contract with the model provider. Then the questions turn to whether the document matches reality — is the retention period in the assessment the one configured in the system, did the mitigations ship, does the human review described in the file happen at a rate consistent with genuine review. The gap between the paper and the deployment is where enforcement lands, and it is why the most valuable half hour in this whole exercise is spent verifying two or three specific controls in the live configuration before the document is signed rather than after it is requested.

Screen the Backlog, Not Just the Next Release

List every AI feature currently in production and run the nine-criteria screen against each one in a single sitting. The output is a two-column list: features that needed an assessment and have one, and features that needed an assessment and do not.

That second column is the whole exposure, stated concretely. It is almost always shorter than teams fear and almost always contains at least one internal tool nobody had classified as processing at all.