Dutch regulator sets out the EU AI Act’s FRIA process

The Dutch Data Protection Authority (AP) says deployers covered by Article 27 of the EU AI Act must complete a fundamental-rights impact assessment (FRIA) before using an in-scope high-risk AI system and notify the market-surveillance authority of the result. Eligible organisations can apply to test the AP’s reporting process until 21 September 2026, ahead of the December 2027 Article 27 obligation.

The AP’s Getting started with the FRIA guidance, published on 17 August, maps the assessment created by the EU AI Act. It does not classify every AI system as high risk. Nor does a model-level assessment replace an examination of the system in the setting where people will encounter it.

The deployer decides whether Article 27 applies

Article 27 of the AI Act places the FRIA duty on specified deployers before they put an in-scope high-risk system into use. The covered group includes bodies governed by public law, private entities providing public services and deployers of high-risk systems used for specified creditworthiness and life or health-insurance risk assessments. The Article excludes high-risk AI systems used in the area listed in point 2 of Annex III on critical infrastructure.

The scope is narrower than any organisation using AI. The accountable legal or compliance owner should record the legal entity deploying the system, its intended purpose, the relevant high-risk category and why Article 27 applies or does not apply. The evidence artefact is a dated scope determination. A general-purpose model may sit inside the technical stack, but the FRIA concerns the effects of the in-scope deployed system in its actual context.

The assessment must be complete before use.

The AP’s guidance requires the deployer to examine its own process, the people likely to be affected and the risks produced by that setting. Supplier product documentation is an input to that work, not the completed assessment.

Six elements define the FRIA record

Article 27 requires the record to describe:

1. the deployer’s process in which the high-risk system will be used, consistent with its intended purpose;
2. the period and frequency of the intended use;
3. the categories of people and groups likely to be affected in the specific context;
4. the specific risks of harm to those people or groups, taking account of information supplied by the provider;
5. the human-oversight measures to be implemented in line with the instructions for use; and
6. the measures to be taken if those risks materialise, including internal governance and complaint mechanisms.

The structure connects the use, affected population, potential harm and response measures. A generic list of fundamental rights does not explain who may be affected or how. A technical risk register does not, by itself, describe the consequences for people in the deployment process.

Article 27 requires the deployer to take account of information supplied by the provider when assessing specific risks. The deployment owner should therefore preserve the provider material used, identify the system version and map those inputs to the deployer’s process, affected groups, identified harms, human oversight and response measures.

The resulting completed FRIA template is the core evidence artefact. It should distinguish provider facts from the deployer’s assessment and show who approved the record before use.

Reuse DPIA evidence, then control changes

Article 27 recognises overlap with a data protection impact assessment. Where a requirement has already been met through a DPIA under the GDPR or the law-enforcement data-protection directive, the deployer may cross-reference the relevant section or include the relevant parts in the FRIA. That reduces duplication but does not answer fundamental-rights questions that the DPIA did not cover.

The Act also requires the deployer to update the information when it considers that relevant factors have changed. A versioned change review can record which factor changed, who assessed the effect and whether the existing FRIA still holds. The review should remain linked to the current FRIA and the system version used in the deployment.

After completing the assessment, the deployer must notify the relevant market-surveillance authority of the result using the mechanism provided for the FRIA. The AP guidance explains that reporting step; it does not create a routine filing duty for AI systems outside Article 27. The filled FRIA template and notification submission provide the completion evidence.

The pilot sets the next checkpoint

The AP is inviting eligible organisations to test the reporting process before the December 2027 Article 27 obligation. Its pilot invitation sets out the purpose, participation criteria and timetable, with applications open until 21 September 2026.

The pilot is voluntary. For covered organisations, it offers a defined rehearsal of the evidence trail from scope determination to reportable assessment, including any DPIA cross-references, change review and notification submission. That rehearsal should test whether the record is complete without adding requirements beyond Article 27.

The immediate decision belongs to the legal or compliance owner: determine Article 27 coverage and, if eligible, decide by 21 September 2026 whether to apply for the AP pilot. The deployment owner then has to complete the FRIA before use, while the reporting owner retains the submission evidence and the change-control owner updates the record when relevant factors change.