DPIA vs FRIA in Romania: Which Assessment Does Your AI Project Need?
AI governance • Romania • Assessment decisions
DPIA vs FRIA in Romania is a question of two different legal tests. A data protection impact assessment (DPIA) addresses risks arising from personal-data processing under the GDPR. A fundamental rights impact assessment (FRIA) under the AI Act applies to specified deployers of certain high-risk AI systems. Your project may require one, both, or neither mandatory assessment.
When do these obligations apply?
The GDPR assessment requirements already apply. Under the AI Act’s consolidated timetable, Chapter III Sections 1–3, including Article 27, apply to Annex III high-risk systems from 2 December 2027. The corresponding date for Article 6(1)/Annex I product systems is 2 August 2028; that does not extend Article 27 to every product system.
Article 111 contains separate transition provisions for existing systems. A project review should record when the system was placed on the market or put into service and whether subsequent design changes affect its treatment. The future FRIA timetable does not postpone GDPR duties. Source: consolidated AI Act, Articles 111 and 113.
DPIA vs FRIA: the differences that change your project
Both assessments examine potential harm to people. A DPIA is not limited to confidentiality or cybersecurity: it also examines other rights and freedoms affected by personal-data processing. FRIA addresses the impact of the specified AI deployment on fundamental rights.
Click or tap a row to reveal its practical takeaway. Keyboard users: Tab to a green label and press Enter or Space. Swipe the table sideways on a small screen.
| Decision point | DPIA: GDPR Article 35 | FRIA: AI Act Article 27 |
|---|---|---|
| Personal-data processing likely to create high risks to individuals, assessed in its context. | A covered deployer using an in-scope Article 6(2)/Annex III high-risk system. | |
| The controller, with DPO advice where a DPO is designated and relevant processor assistance. | The deployer covered by Article 27. | |
| Processing, necessity, proportionality, risks to people and safeguards. | Deployment context, affected groups, risks of harm, human oversight and responses. | |
| Before the relevant processing begins; review when risk changes. | Before first use where the obligation applies; update changed or outdated elements. | |
| Prior consultation when the Article 36 threshold is met; no universal filing requirement for every DPIA. | Notify results to the market surveillance authority under Article 27(3), subject to its exception. | |
| Shared evidence can support the assessment of the actual processing. | Relevant DPIA sections may be cross-referenced or incorporated; remaining requirements still need coverage. |
GDPR Articles 28, 35–36 and 39; AI Act Article 27.
When does an AI project need a DPIA?
AI use alone does not automatically trigger a DPIA. The controller must assess whether the nature, scope, context and purposes of the processing make a high risk to people likely. Article 35 expressly recognises the relevance of new technologies.
The GDPR identifies particular situations, including systematic and extensive automated evaluation underpinning decisions with legal or similarly significant effects, large-scale processing of special-category or criminal-offence data, and large-scale systematic monitoring of publicly accessible areas. Applicable supervisory-authority lists must also be checked.
For a Romanian deployment, the file should therefore address the applicable requirements and guidance of the Romanian data protection authority, ANSPDCP, alongside Article 35. Record the reasons for a negative screening conclusion too. A supplier’s description of a product as “low risk” is not an assessment of your processing.
Where required, the DPIA must describe the processing and purposes, assess necessity and proportionality, evaluate risks to individuals and specify safeguards. This is a substantive project assessment, not simply a signed template. Source: GDPR Article 35.
For the broader data-protection framework, see our guide to GDPR compliance when using AI in Romania.
Who needs a FRIA under the AI Act?
The Article 27 obligation does not cover every business using high-risk AI. It concerns Article 6(2) high-risk systems and specified categories of deployer, with an exclusion for the critical-infrastructure area in Annex III point 2.
- Bodies governed by public law deploying qualifying systems.
- Private entities providing public services deploying qualifying systems. This status requires analysis; it is not synonymous with every company selling services to the public.
- Deployers of qualifying creditworthiness or credit-scoring systems for natural persons under Annex III point 5(b), which excludes systems used to detect financial fraud.
- Deployers of qualifying life and health insurance risk-assessment or pricing systems for natural persons under Annex III point 5(c).
Classification under Article 6 must be checked first, including the conditions of any applicable exception. The exact intended purpose matters. A financial-sector tool is not automatically a creditworthiness system, and a medical product is not automatically within the Article 27 FRIA route. Source: AI Act Articles 6 and 27 and Annex III.
Explore four deployment scenarios
These hypothetical examples explain the screening logic. They assume the stated facts and do not replace an assessment of the actual system, applicable dates or transition rules.
Candidate ranking: DPIA and FRIA can diverge
A private manufacturer uses extensive automated applicant evaluation to support hiring decisions. These facts point to a DPIA requirement under Article 35(3)(a), even if a person makes the final decision. Recruitment may also fall within Annex III. However, on the assumption that the manufacturer is neither a public-law body nor a private public-service provider, its employer status alone does not trigger Article 27 FRIA.
Consumer credit: prepare for both assessments
A lender uses an in-scope high-risk system to score individuals for loan eligibility. Systematic and extensive profiling with significant consequences can trigger a DPIA. Article 27 separately covers qualifying deployers under Annex III point 5(b). Address the applicable FRIA timetable and any transition provisions, rather than assuming both duties started on the same date.
Public benefits: assess deployment and processing together
A public body uses a qualifying high-risk system to assess eligibility for essential assistance benefits. Its status and use case bring Article 27 into the analysis. The personal-data processing needs separate DPIA screening, including relevant public-task legislation and any Article 35(10) position. One completed assessment does not automatically discharge the other.
Drafting assistant: examine the actual workflow
A team drafts generic product descriptions without personal data or decisions about people. On those narrow facts, the workflow does not itself establish a DPIA or Article 27 FRIA requirement. Check account data, logs and supplier processing separately. Introducing customer records, employee evaluation or regulated decisions changes the analysis. Other duties may still apply.
Can one assessment document cover DPIA and FRIA?
A coordinated file can reduce duplicated work, provided each legal requirement remains identifiable. The consolidated Article 27(4) expressly allows relevant DPIA sections to be cross-referenced or incorporated into FRIA where they already meet the corresponding obligations.
Start with a shared description of the system, purposes, data flows, affected people and safeguards. Then keep a requirement map showing which sections satisfy GDPR Article 35 and which satisfy AI Act Article 27. Identify gaps rather than renaming a DPIA “FRIA”. Source: AI Act Article 27(4)–(5).
As a practical drafting approach, include a separate deployment chapter addressing who may be affected beyond the immediate users, how mistakes influence access to opportunities or services, who can intervene, and how complaints lead to corrective action. Avoid treating GDPR as only a privacy checklist: the DPIA itself must consider risks to rights and freedoms.
What the FRIA needs to address
Article 27 requires the deployment process and intended use, duration and frequency, affected people and groups, specific risks of harm, implementation of human oversight, and measures if risks materialise, including governance and complaint mechanisms. Reusing a supplier assessment in similar cases is permitted, but the deployer must check its fit and update changed or outdated elements. Source: AI Act Article 27(1)–(2).
Who prepares, reviews and owns the decision?
The controller remains responsible for the DPIA; the covered deployer remains responsible for FRIA. A consultant, DPO or supplier can contribute without taking over the organisation’s statutory role.
For the DPIA, seek the designated DPO’s advice and preserve their independent advisory and monitoring function. Obtain relevant processor assistance. For the deployment review, involve the business owner, technical team and people responsible for oversight and complaints. A useful internal decision records outstanding conditions, the person accountable for each safeguard and the circumstances requiring a fresh review. Source: GDPR Articles 28(3)(f), 35(2) and 39; AI Act Article 27.
Contractual cooperation should cover the evidence you need to assess the deployment. Our AI vendor contracts guide addresses information rights, changes and supplier responsibilities.
Must the assessment be sent to an authority?
A DPIA and a FRIA follow different authority procedures. Under GDPR Article 36, prior consultation is required where high residual risk remains that cannot be sufficiently mitigated. There is no general GDPR obligation to submit every DPIA for approval.
Article 27(3) provides for notification of FRIA results to the market surveillance authority using the relevant template, subject to the Article 46(1) exception. That notification is not the GDPR prior-consultation procedure and should not be described as automatic permission to deploy. Confirm the competent authority and operational submission arrangements for the specific deployment. GDPR Article 36; AI Act Article 27(3).
A practical assessment file before deployment
- Define the use case. Identify the system, version, intended purpose, users, affected people and decisions it informs.
- Map roles separately. Record GDPR controller/processor roles and the relevant AI Act roles.
- Screen the legal route. Check prohibited practices, AI classification, DPIA triggers and Article 27 deployer coverage.
- Record timing. Distinguish existing GDPR duties from future AI Act requirements and applicable transition provisions.
- Collect evidence. Obtain data-flow information, supplier instructions, meaningful performance limitations, oversight arrangements and relevant testing.
- Assess harms and safeguards. Describe how the actual deployment may affect people and how controls reduce those risks.
- Map shared sections. Make each DPIA and FRIA requirement traceable, retaining any necessary separate analysis.
- Resolve escalation. Identify prior consultation, notification, unresolved risks and conditions preventing launch.
- Assign review triggers. Consider changes in purpose, model, data, affected groups or decision authority, and evidence from incidents or complaints.
How Atrium Romanian Lawyers Assisted an International Manufacturing Group
Anonymised client matter. The description below omits identifying information and focuses on the legal work performed.
Questions examined
- Whether the candidate-data processing required a DPIA;
- Whether the use of the system could trigger a FRIA under the AI Act;
- What human-oversight and documentation measures were needed before implementation.
Legal analysis
Our review of the recruitment process identified extensive automated evaluations of candidates with a significant impact on access to employment opportunities. The company therefore decided to complete a DPIA before implementation.
We also carried out a separate analysis of the system’s classification under the AI Act, including the organisation’s status and the obligations applicable to the deployer. The review confirmed that the DPIA and any FRIA analysis had to be treated separately because their legal triggers differ.
Measures adopted
- Documentation of the decision logic and system limitations;
- Mandatory stages of human verification;
- Internal procedures for challenging results and handling complaints;
- Updated contractual documentation and AI-governance workflows.
Practical result
Following the project, the company was able to continue the implementation on the basis of stronger documentation concerning compliance and risk management.
A focused consultation can clarify which assessment route applies and what your team needs before making deployment commitments.
Frequently asked questions
Does every AI project need both a DPIA and a FRIA?
No. Screen personal-data processing under GDPR Article 35 and, separately, the system and deployer under AI Act Article 27. One assessment may be mandatory while the other is not. A negative screening result does not remove other applicable legal obligations.
Does human review remove the need for a DPIA?
Not automatically. Article 35 has its own risk test, and its automated-evaluation category is not confined to solely automated decisions. Genuine human oversight can affect risks and safeguards, but a human signature does not by itself settle DPIA applicability.
Does a private employer need a statutory FRIA for recruitment AI?
Not solely because it is an employer using high-risk recruitment AI. Article 27 covers specified deployers and uses. Check whether the organisation is a public-law body or private public-service provider, while independently assessing its GDPR and other AI Act obligations.
Can we rely on the supplier’s impact assessment?
Supplier evidence can support the work, and Article 27 permits reliance on existing assessments in similar cases. The organisation still needs to check whether the document addresses its actual deployment, affected groups, safeguards and applicable obligations. A generic assurance is insufficient evidence of that fit.
Can we wait until the FRIA application date to conduct a DPIA?
No, if GDPR already requires a DPIA for the proposed processing. The DPIA must precede that processing. The AI Act timetable and transition provisions must be analysed separately and do not suspend GDPR requirements.
Does completing an assessment authorise the project?
No. An assessment documents analysis and safeguards; it does not supply a missing legal basis, legalise prohibited AI or override unresolved legal restrictions. Complete any required consultation or notification procedure and resolve conditions that prevent lawful deployment.