A DPIA asks whether processing personal data puts people at high risk; a FRIA asks whether using a high-risk AI system puts their fundamental rights at risk. For an AI agent they cover much of the same ground, and the EU AI Act says the FRIA complements an existing DPIA. Run them as one assessment with two outputs.
What does each require?
The DPIA (GDPR Article 35). A controller must carry out a data protection impact assessment before processing that is likely to result in a high risk to people's rights and freedoms, in particular where new technologies are used. In substance, it must contain a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to people, and the measures to address them. If high risk remains after mitigation, the supervisory authority must be consulted before processing starts.
The FRIA (EU AI Act Article 27). Certain deployers of high-risk AI systems must assess the impact on fundamental rights before first use. In substance, it must describe the deployer's processes in which the system is used, the period and frequency of use, the categories of people and groups likely to be affected, the specific risks of harm to them, the human oversight measures, and what the deployer will do if risks materialise. The results are notified to the market surveillance authority.
The Act states that where a DPIA already meets any of these obligations, the FRIA complements it. That sentence is the legal basis for running them together.
Who must do which?
The DPIA falls on any controller whose processing meets the high-risk threshold. For agents that read customer data and influence decisions, that threshold is often met.
The FRIA falls on a narrower group: bodies governed by public law, private entities providing public services, and deployers of high-risk systems used to assess the creditworthiness of individuals or price life and health insurance for them.
So there are three common situations:
- DPIA only. A service agent processing customer data at scale, not in a listed high-risk use.
- Both. A credit agent assessing individual applicants, or an insurer's pricing agent for life cover.
- Neither. An internal agent that processes no personal data and is not high-risk. This is rarer than it sounds.
The UK has the DPIA duty under UK GDPR but no FRIA; UK GDPR DPIA for AI agents covers the UK version.
Where do they overlap, and where do they differ?
| Topic | DPIA | FRIA |
|---|---|---|
| Description of the processing or process | Yes, with purposes | Yes, the deployer's process using the system |
| Who is affected | Data subjects | Categories of people and groups, including more exposed groups |
| Rights in scope | Data protection and privacy, with wider rights and freedoms | All fundamental rights, including non-discrimination, dignity and access to services |
| Necessity and proportionality | Required | Not expressly, but implied by risk assessment |
| Human oversight | Relevant to Article 22 safeguards | Required section |
| Measures if risks materialise | Mitigations | Governance and complaint routes |
| Who is told | Authority consulted if high risk remains | Authority notified of results |
The DPIA is deeper on data: lawful basis, minimisation, retention, transfers, security. The FRIA is wider on rights: discrimination, access to essential services, the effect of errors on people's lives.
Why does an agent make joint assessment more useful?
An agent is not a single processing operation. It reads several sources, calls tools, drafts and acts. Each step has a data protection angle and a rights angle, and they are often the same step seen twice.
Take an agent that reads applicants' bank statements to summarise income. The DPIA asks whether reading every transaction is necessary, how long the summary is kept, and whether special category data, such as payments to a religious organisation or a health provider, is exposed. The FRIA asks whether the summary systematically understates income for people with irregular or cash earnings, and whether that leads to unfair refusals. Both questions are about the same capability and the same control: what the agent reads, what it keeps and what it passes on.
Assessing them apart creates two descriptions of the agent that drift, and two sets of mitigations that may conflict.
How do you run one process that serves both?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| One description of the agent | Capability map: each step, the data it reads, the action it takes, its depth | Shared description used by both outputs |
| DPIA: necessity and proportionality | Per-capability data justification; fields not needed are blocked | Data map with justification |
| FRIA: affected groups | Groups listed, including those more exposed | Group analysis |
| Both: risks | One risk table, each risk tagged as data protection, wider rights, or both | Joint risk register |
| Both: oversight | Hold points before decisions with significant effects; named approvers | Approval records |
| Both: mitigations | One action list; conflicts resolved explicitly | Signed mitigation plan |
| DPIA: consult if high risk remains | Prior consultation route | Consultation record |
| FRIA: notify authority | Notification of results | Submission receipt |
| Both: review on change | New capability, source or population triggers joint review | Revision history |
A practical starting structure is our DPIA template for an AI agent, extended with the FRIA fields. Banks will want to align the same description with their ICT risk records; see EU AI Act and DORA together for AI agents in banks.
What will a supervisor or auditor ask?
- Show us the assessment. Which parts are the DPIA and which the FRIA?
- Do the two describe the same agent, in its current version?
- Which risks did you find that are about rights other than privacy?
- How did you resolve any conflict between minimising data and testing for bias?
- When was it last updated, and why?
What does neither assessment cover?
Neither certifies the agent or replaces the provider's conformity assessment. Neither sets the limits on what the agent may do; they inform those limits. And neither replaces model validation or operational risk assessment required by sector rules. For the full map, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Who should own a combined FRIA and DPIA?
The business owner of the process the agent supports, with the data protection officer advising on the DPIA part and compliance or risk on the FRIA part. One owner signs both.
Can the FRIA simply reference the DPIA?
Where the DPIA already covers a FRIA element, yes, the Act expects the FRIA to complement it. The FRIA must still address the elements the DPIA does not, such as non-discrimination and access to services.
Does a DPIA need updating when the agent's model changes?
If the change affects how personal data is processed or the risks to people, yes. Treat model, source and capability changes as triggers for review of both parts.