AI Impact Assessments vs DPIAs vs Fundamental Rights Assessments

This article accompanies Hour 7: Ethical Data Stewardship in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.

A business team wants to introduce an AI workflow that will prioritise high-impact customer cases. Procurement has opened a supplier review. The privacy team is asking whether a DPIA is required. Legal is checking whether the EU AI Act changes the governance route. Risk wants to know who signs off the pilot. The business owner wants a decision this month.

That is a common pressure point. It is also where organisations can create a lot of paperwork without creating much assurance.

An AI impact assessment, a data protection impact assessment and a fundamental rights assessment may all be relevant to the same use case, but they do not answer the same question. If they are treated as competing templates, teams can spend weeks repeating background facts and still miss the real governance issue: what are we approving, on what evidence, with what limits, and when must the decision be reopened?

This article is general guidance, not legal advice. It is written for DPOs, privacy teams, legal leads and governance owners who need to make the assessment route practical inside a working organisation.

The useful question is not "which template wins?" It is "which assessment questions apply to this use case, and how do we keep one clear evidence trail?"

Why this becomes difficult in practice

AI assessment work often starts with a product name. That is understandable, but it is not enough. The same AI tool may be low risk when used to summarise public meeting notes and much higher risk when used to rank vulnerable customers, screen job applicants, support clinical triage or recommend fraud action.

The assessment route should therefore start with the governed use case. What will the AI system do? Who will use it? Who may be affected? What decision, recommendation or output will it influence? What personal data is used? Is the system only supporting internal drafting, or could its output change how a person is treated?

Once that use case is clear, the organisation can decide which assessment duties and governance checks are triggered. The answer may be a DPIA, an AI impact assessment, an AI Act role and risk classification record, a fundamental rights assessment in a specific high-risk deployer context, supplier due diligence, security review, or some combination of those records.

That combination should not become a bundle of unconnected forms. The cleaner route is to maintain one factual spine for the use case, then attach the assessment records that answer different legal and governance questions.

The difference between the assessment routes

A DPIA is a data protection tool. Under GDPR and UK GDPR-style accountability, it is used where processing is likely to result in a high risk to individuals' rights and freedoms. It should describe the processing, assess necessity and proportionality, identify risks to people, record measures to address those risks and show whether residual high risk remains.

An AI impact assessment is usually broader. It may cover fairness, bias, explainability, system reliability, human oversight, safety, operational impact, complaints handling, auditability, staff behaviour, supplier change control and misuse. Some of that will overlap with the DPIA because it affects people through personal data. Some of it will sit outside strict data protection analysis but still be essential to responsible governance.

An AI Act-related fundamental rights assessment is narrower than the phrase sometimes suggests. It is not a universal AI ethics form. Under the EU AI Act, specific deployers of high-risk AI systems must carry out a fundamental rights impact assessment in defined circumstances. Where it applies, it should connect to the DPIA and wider AI governance record, but it should not be treated as a replacement for either.

The practical distinction can be put like this:

This is not a hierarchy. A broad AI impact assessment does not remove the need for a DPIA where the personal data processing is likely to be high risk. A DPIA does not automatically answer every AI governance, equality, procurement or operational question. A fundamental rights assessment, where required, must sit within the wider decision record rather than float beside it.

A worked example: one workflow, several assessment questions

Imagine an organisation that wants to deploy an AI system to help prioritise complex service cases. The system will review case notes, previous contact history and structured indicators, then suggest a priority level and recommended next action. Staff will make the final decision, but the AI output will be visible in the case management system.

The privacy team starts with some useful facts. The system will process personal data. Some data may reveal vulnerability, health, financial hardship or other sensitive circumstances. The output may affect how quickly a person receives help. The supplier says customer data will not be used for model training, but the procurement file does not yet show whether prompts, logs or feedback are retained. The business owner says the workflow is a pilot, but there is no written limit on pilot numbers, affected groups or review date.

Several unknowns matter before approval:

• whether special category data is processed directly or inferred;
• whether the supplier acts only as processor for the relevant processing;
• whether any data is transferred outside the UK or EEA;
• what human review will involve in practice;
• whether the AI output could become a de facto decision;
• whether the system falls within an AI Act high-risk category for the relevant EU deployment context;
• what evidence will show that the pilot stayed within its approved limits.

The risk question is not simply "can we buy the tool?" It is whether the organisation can lawfully and responsibly run this use case, with controls that are strong enough for the effect it may have on people.

The DPO or privacy team would normally check the purpose, affected individuals, data categories, lawful basis, fairness, transparency, necessity and proportionality. They would test whether less intrusive or less automated routes could meet the same operational need. They would ask whether staff can meaningfully challenge the recommendation, whether individuals receive appropriate information, whether rights requests can be answered, and whether errors or unfair patterns will be detected.

The AI governance owner would check model use limits, output reliability, training, monitoring, misuse, escalation, quality assurance and review cadence. Procurement and security would check the supplier, hosting, access, logging, support, retention, subprocessor and change-control evidence. Legal would check contracts, AI Act role mapping and whether a fundamental rights assessment is required for the relevant deployment.

The evidence created afterwards should be connected. The DPIA should not repeat the whole AI assessment, but it should refer to it where the controls matter for data protection risk. The AI impact assessment should not pretend to be the DPIA, but it should show how privacy risks have been addressed. If a fundamental rights assessment is needed, it should draw from the same use-case facts and record its own conclusion.

Escalation or review would be triggered if the pilot expands, new data categories are introduced, human review is reduced, the supplier changes model behaviour or retention terms, complaints arise, quality checks show unfair patterns, staff rely on the score more heavily than expected, or AI Act classification changes as the deployment facts become clearer.

What the DPO or privacy team should check

The privacy check should be practical enough to support a real decision. A useful route is to ask:

• What is the specific AI use case, and which people may be affected by it?
• What personal data is used at input, prompt, retrieval, output, logging and feedback stages?
• Is special category data, criminal offence data, children's data, vulnerability data or inferred sensitive data involved?
• What lawful basis and, where needed, Article 9 condition is being relied on?
• Is the processing necessary and proportionate for the stated purpose?
• What will people be told about the AI system, and when?
• Who is controller, joint controller or processor for each processing activity?
• What AI Act role mapping has been completed, and is high-risk classification relevant?
• Does the use case trigger a DPIA, and is prior consultation a possibility if residual high risk remains?
• Does any AI Act-related fundamental rights assessment requirement apply to the deployer?
• What supplier, contract, subprocessor, transfer, retention and security evidence supports the assessment?
• What human oversight, escalation, complaints and quality-review controls will operate after launch?
• Who accepts residual risk, on what conditions, and when will the decision be reviewed?

The answer to these questions should not live only in email threads. It should be visible in the assessment record that supports sign-off.

Evidence that should exist afterwards

After a high-impact AI workflow has been assessed, the organisation should be able to show what was decided. The record should normally include:

• a short use-case description and approved scope;
• the DPIA screening decision and DPIA where required;
• the AI impact assessment or equivalent governance record;
• AI Act role and risk classification notes where relevant;
• fundamental rights assessment where required;
• supplier, contract, security, hosting, retention and transfer evidence;
• transparency and rights-handling position;
• human oversight and escalation design;
• residual risk record and approval conditions;
• owner, review date and event-triggered review criteria;
• action log for unresolved conditions.

This does not need to be heavy for every use case. A low-risk internal assistant may need a much lighter route. But where the workflow is high-impact, the record should be strong enough that a new reviewer can understand the facts, the judgement and the conditions without reconstructing the decision from meeting notes.

What this means for CPD

Hour 7 of Event B focuses on ethical data stewardship. In practice, that means being able to move from broad AI concern to a clear governance decision. The learning is not only that DPIAs, AI impact assessments and fundamental rights assessments exist. It is how to connect them so the organisation can explain the decision it made.

For DPOs and privacy teams, the practical skill is to keep the use case at the centre. Start with the people affected, the data used, the decision influenced and the evidence available. Then decide which assessment routes apply, who owns each one and what sign-off record must exist before the use case proceeds.

XpertDPO supports organisations that need to make this route clearer, including through AI governance and DPIA lifecycle support, DPIA support, DPO support and board and legal privacy assurance. Where assessment records already need to stand up to complaint, audit or regulator scrutiny, regulator response support may also be relevant.

This article is intended to support the learning covered in Hour 7 of our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.