Two assessments now orbit every serious AI deployment in the EU, and they are routinely confused. The DPIA - data protection impact assessment - is the GDPR's instrument, a decade old and well understood. The FRIA - fundamental rights impact assessment - is the AI Act's new one, created by Article 27 and unprecedented in EU tech law. They overlap enough that teams assume one covers the other, and differ enough that the assumption fails audits in both directions. This spoke of our EU AI Act series sorts out which your deployment needs, and how to run both without duplicating the work.
Legal information, not legal advice: assessment triggers depend on your processing, sector, and member state - confirm your position with a qualified adviser.
Which assessment do you actually need?
The short answer for most legal teams: a DPIA analysis, often; a FRIA, rarely. A DPIA is triggered by risky processing of personal data - which AI deployments over client files frequently are. A FRIA is triggered only by deploying an Annex III high-risk system and being a covered deployer: a body governed by public law, a private entity providing public services, or a deployer of credit-scoring or life/health-insurance risk-pricing AI. A private law firm running research and drafting tools fails both limbs; a bank's legal-adjacent compliance team deploying creditworthiness AI meets both.
The classification step therefore comes first: our guide to whether legal AI is high-risk walks it through. Systems outside Annex III never trigger a FRIA, whoever deploys them.
The DPIA: GDPR's risk assessment, applied to AI
Under Article 35 GDPR, a controller must assess processing that is "likely to result in a high risk" to individuals before starting it - describing the processing, testing necessity and proportionality, mapping risks to data subjects, and recording mitigations. Systematic evaluation of people, large-scale processing of special-category data, and novel technologies are the classic triggers, and supervisory authorities have long read new AI deployments as pointing toward one. If residual risk stays high, Article 36 requires consulting the supervisory authority before proceeding.
For a legal team, the honest DPIA question about an AI platform is rarely "is this exotic?" and usually "what personal data enters, on what basis, with what safeguards?" - the same questions our GDPR guide for law firms covers for the practice generally. A documented screening that concludes no full DPIA is needed is itself part of the compliance file.
The FRIA: the AI Act's new instrument
The FRIA, created by Article 27 of the AI Act, asks a broader question: before first use of a covered high-risk system, what impact could it have on fundamental rights - not just privacy, but non-discrimination, access to justice, workers' rights, effective remedy. The assessment must describe the deployment process and period, the categories of people affected, the specific risks of harm to them, the human oversight arrangements, and what happens if risks materialise - including internal governance and complaint mechanisms. Results are notified to the market surveillance authority on an AI Office template (still unpublished as of mid-July 2026), and the assessment must be updated when its elements change.
Scope is the part everyone misreads. The duty covers deployers that are public bodies or private providers of public services - education, healthcare, housing, and similar - plus all deployers of Annex III point 5(b) and 5(c) systems: creditworthiness and credit scoring, and risk assessment and pricing in life and health insurance. Critical-infrastructure systems are carved out. So the FRIA lands hardest not on law firms but on their clients - banks, insurers, universities, agencies - which makes fluency in it advisory stock-in-trade.
FRIA vs DPIA side by side
| Dimension | FRIA (AI Act, Article 27) | DPIA (GDPR, Article 35) |
|---|---|---|
| Trigger | Deploying an Annex III high-risk system, as a covered deployer | Processing likely to result in high risk to individuals |
| Who runs it | The deployer | The controller |
| Rights covered | Full fundamental-rights spectrum: equality, remedy, workers' rights, and privacy | Data protection and privacy |
| Timing | Before first use; update on change | Before processing; review on change |
| Authority contact | Notify market surveillance authority (template pending) | Prior consultation only if residual risk stays high |
| In force | With the Annex III wave: 2 December 2027 | Since 2018 |
The overlap is real - deployment description, affected persons, risk mapping, mitigations - which is why the Act wires the two together rather than duplicating them.
Four legal-team scenarios, decided
- Law firm adopts an AI research and review platform. Not high-risk; no FRIA. Personal data in client files makes a DPIA screening - and usually vendor-terms scrutiny - the real work.
- Firm deploys AI screening of job applicants. High-risk (Annex III employment), so the Article 26 deployer duties attach from December 2027 - but a private firm is not a covered FRIA deployer, so the mandatory FRIA does not. A DPIA almost certainly is required, and running a FRIA-style analysis voluntarily is cheap insurance.
- In-house team at a bank deploys creditworthiness AI. Annex III 5(b): FRIA mandatory for any deployer, plus a DPIA - the textbook combined-assessment case.
- Government legal department deploys case-triage AI. Public-law body deploying a justice-adjacent Annex III system: FRIA and DPIA both, with the administration-of-justice entry read carefully.
Notice the pattern across the four: the assessment burden tracks the deployment, not the organisation's size or sophistication. That is also the advisory opportunity - the clients most exposed to the FRIA are precisely the regulated-sector clients law firms already serve, and a firm fluent in both instruments can turn every AI procurement its clients run into a scoped piece of work.
Timing: when the FRIA duty actually bites
Article 27 rides the high-risk wave, and the Digital Omnibus moved that wave: Annex III obligations - the FRIA included - now apply from 2 December 2027 rather than 2 August 2026. Two things temper the relief. The DPIA never moved - it binds today, and most systems that will need a FRIA already need a DPIA now. And procurement cycles are long: a system bought in 2026 on a five-year contract will be mid-term when the FRIA duty arrives, so the assessment questions belong in this year's tender documents, not 2027's remediation project.
Run them as one file, not two projects
Article 27(4) makes the design explicit: where a DPIA already covers any FRIA element, the FRIA complements it. The efficient pattern is one assessment file per deployment. Start from the DPIA core - processing description, necessity, data flows, security. Extend it with the FRIA's additions: the affected-group mapping beyond data subjects, rights beyond privacy (discrimination, access to remedy, workers' rights), the human-oversight arrangement with named roles, and the complaint and escalation mechanism. Version it, date it, and assign one owner for updates - the assessment is "living" in both regimes.
Keep the submission paths distinct even when the file is unified: the DPIA conversation runs to the data protection authority, the FRIA notification to the market surveillance authority - some member states may designate the same body for both, so verify locally. And park both in the structure your AI governance policy creates - the inventory names the system, the classification record justifies the tier, the assessment file evidences the analysis.
One drafting habit pays for itself in both regimes: write the risk sections about people, not systems. "The model may misclassify" is a technical observation; "applicants with non-standard work histories may be wrongly scored and lose access to credit, with this escalation route" is an assessment a regulator can evaluate. The provider's Article 13 documentation - instructions for use, capability and limitation statements - is the designed input for that analysis, which is another reason the vendor paperwork questions in this series matter.
Where Judicio fits
Assessments are document-heavy work: provider documentation, instructions for use, data-flow maps, prior assessments, vendor terms. Teams run that corpus through Judicio - a research workspace with citation-grounded answers for the regulatory questions, and document tools that keep every extracted fact traceable to its source page, which is precisely the evidentiary habit both assessments reward. Client documents are never used to train models, and access is role-scoped with an activity trail - answers to two questions every DPIA asks of every vendor.
The companion spokes cover the adjacent files: deployer obligations for the duty calendar and vendor due-diligence questions for the procurement side. To test the workflow on your own assessment corpus, start a 7-day free trial - 500 credits, no card required - and see the Europe hub for the EU regulatory backdrop.