Why the fundamental rights impact assessment is different
Most of the EU AI Act’s paperwork falls on the companies that build AI. The fundamental rights impact assessment is one of the few obligations aimed squarely at the organisations that use it — and it asks a question that no other compliance document asks.
A conformity assessment asks whether a system meets technical requirements. A data protection impact assessment asks what happens to personal data. Article 27 asks something broader and more uncomfortable: who will this system affect, how might it harm them, and what will you do when it does. It is a deployer-side document about people, not about software.
Who actually has to do one
Article 27 does not apply to every deployer of every high-risk system, and the scoping is narrower than most summaries suggest. The duty falls on two groups deploying high-risk systems listed in Annex III, excluding the critical infrastructure category:
The first is bodies governed by public law, and private entities providing public services. That second phrase does real work — a private company running a public service under contract is caught, even though it is not a public authority.
The second is deployers of two specific Annex III categories regardless of who they are: point 5(b), creditworthiness assessment and credit scoring of natural persons, and point 5(c), risk assessment and pricing in life and health insurance. These are the only ordinary private-sector deployers pulled in by category. If you are a lender or an insurer using AI for those purposes, the duty is yours.
Everyone else deploying high-risk AI has Article 26 deployer obligations, but not Article 27.
What the assessment must contain
Article 27(1) sets out six elements, and they read as a sequence rather than a checklist.
The processes and the timeframe
You describe the deployer’s processes in which the system will be used, in line with its intended purpose, and the period and frequency over which you intend to use it. The intended purpose is the provider’s, not yours — if you are using the system for something else, you have a much larger problem under Article 25, which can make you the provider.
Who is affected
You identify the categories of natural persons and groups likely to be affected in your specific context of use. Not users. Affected persons — the loan applicants, the insured, the people on the other side of the decision, including those who never interact with your organisation directly.
The specific risks of harm
You set out the specific risks of harm likely to affect those categories, taking account of the information the provider must give you under Article 13. This is where the assessment earns its keep, and where most drafts fail. “The model may be biased” is not a specific risk of harm. “Applicants in this postcode band may be systematically declined for reasons unrelated to their financial position, losing access to credit” is.
Human oversight and what happens when things go wrong
You describe the human oversight measures you will implement, in line with the provider’s instructions for use, and then the measures to be taken if the risks materialise — including internal governance arrangements and complaint mechanisms. The last point matters: the Act expects affected people to have a route to complain, and expects you to have decided in advance what happens when they do.
First use, updates and notification
Article 27(2) attaches the obligation to the first use of the system. In similar cases a deployer may rely on a previously conducted assessment rather than starting again. But the paragraph also imposes a live duty: if during use the deployer considers that any of the six elements has changed or is no longer up to date, it must take the necessary steps to update the information. A fundamental rights impact assessment is not a document you file and forget.
Article 27(3) then requires something unusual. Once the assessment has been performed, the deployer must notify the market surveillance authority of its results, submitting the filled-out template. This is not an internal record. It goes to your regulator.
Article 27(5) requires the AI Office to develop a template questionnaire, including through an automated tool, to help deployers comply in a simplified manner. That template is what Article 27(3) refers to.
The relationship with your data protection impact assessment
Article 27(4) addresses the obvious overlap. Where any of the Article 27 obligations is already met through a data protection impact assessment conducted under Article 35 of the GDPR, the fundamental rights impact assessment complements that assessment. The Digital Omnibus on AI strengthened this in July 2026: the fundamental rights assessment may now expressly include or cross-refer to the relevant sections of the data protection assessment, and the Commission template is to be built to support that route.
The practical effect is that you should be building one integrated assessment, not two overlapping documents on different templates maintained by different teams.
The converse does not hold, and this is worth stating plainly. A fundamental rights impact assessment does not discharge your GDPR obligation. The Article 35 duty is independent, and for systematic automated evaluation producing legal or similarly significant effects it is mandatory in its own right. You cannot substitute one for the other; you can only avoid writing the same analysis twice.
When this applies
Article 27 sits in Chapter III of the AI Act, which the Digital Omnibus on AI, Regulation (EU) 2026/1744, deferred when it entered into force on 27 July 2026. The duty applies from 2 December 2027 for stand-alone Annex III systems, and from 2 August 2028 for high-risk AI embedded in regulated products under Annex I.
That is not as far away as it sounds. A credible fundamental rights impact assessment requires you to know your affected populations, to have outcome data broken down in ways most organisations do not currently collect, and to have designed a complaint mechanism that works. None of that is a document-drafting exercise you can start in November 2027.
Praktiskt exempel
A Swedish lender uses an AI creditworthiness model. It falls in Annex III point 5(b), so Article 27 applies to it directly.
Its first draft assessment describes the model, cites the vendor’s accuracy figures and states that a human reviews every decline. That draft fails on three of the six elements. It does not identify the categories of affected persons in the lender’s actual context of use — which includes applicants who never become customers. It does not state specific risks of harm to those groups, only generic model risk. And it describes human oversight without establishing that the reviewer has the authority, information and time to depart from the recommendation, which is also what determines whether GDPR Article 22 bites.
The useful version of that document is shorter on the model and longer on the people: who applies, which groups are plausibly disadvantaged, what the outcome data shows, what the reviewer can actually change, and what happens when an applicant complains. That version is also most of the lender’s data protection impact assessment, which is the point of Article 27(4).
Vanliga misstag som företag gör
The first is assuming the duty is public-sector only. Credit scoring and life and health insurance pricing pull ordinary private companies in by category.
The second is writing about the system instead of about people. An assessment that never names an affected group has not been done.
The third is treating it as an internal document. Article 27(3) requires notification of the results to the market surveillance authority — it will be read by a regulator.
The fourth is running it as a one-off. Article 27(2) requires updates whenever the underlying elements change, and models, populations and use cases all drift.
The fifth is duplicating the data protection impact assessment on a separate template with a separate owner, which produces two documents that disagree with each other — the worst possible outcome when a regulator reads both.
Rekommenderade åtgärder
Work out first whether you are actually in scope, because the answer is binary and narrower than the general high-risk population. Public body, private entity providing a public service, credit scoring, or life and health insurance pricing — otherwise Article 26 applies to you and Article 27 does not.
If you are in scope, start with the data you do not yet have. Identifying affected groups and specific risks of harm requires outcome monitoring segmented in ways most organisations have never set up, and building that capability is the long pole. Design the complaint mechanism early too, since Article 27 asks what you will do when risks materialise and a mechanism that exists only on paper will not survive scrutiny.
Merge the workstream with your data protection impact assessment now, under one owner, so that the cross-referencing Article 27(4) permits is available to you rather than a retrofit. Look at ISO/IEC 42005 on AI system impact assessment for a workable methodology while the Commission template is still pending. And treat the assessment as a living document with a review trigger attached to model changes, population changes and material incidents.
Vanliga frågor
Does a data protection impact assessment cover this?
Partly, and the Act intends you to use the overlap. Where an Article 27 obligation is already met through a GDPR Article 35 assessment, the fundamental rights assessment complements it and may cross-refer to it. But the coverage is not complete — Article 27 reaches harms beyond data protection, and it requires notification to the market surveillance authority. And a fundamental rights assessment never discharges the GDPR duty in the other direction.
We deploy a high-risk recruitment tool. Do we need one?
Only if you are a body governed by public law or a private entity providing public services. Employment and worker management sits in Annex III point 4, which is not one of the two categories that catch ordinary private deployers. A private employer using a high-risk recruitment tool has Article 26 deployer obligations, and separately has GDPR Article 22 exposure, but not an Article 27 duty.
What happens after we send the results to the authority?
The Act requires notification of the results using the template; it does not establish an approval process, so you are not waiting for clearance. In practice the notification gives your market surveillance authority a documented view of how you assessed the risks, which is why the quality of the assessment matters well beyond the moment of filing.
Slutsats
Article 27 asks deployers to write down who their AI system might harm, how, and what they will do about it — then send the results to their regulator. It applies to public bodies, to private entities providing public services, and to two private-sector categories: credit scoring and life and health insurance pricing. It attaches to first use, must be kept up to date, and is designed to be built on top of a data protection impact assessment rather than beside it. The deadline is 2 December 2027, and the hard part is not the document but the outcome data and complaint machinery it depends on. Lawgent helps businesses determine whether Article 27 applies to them, build integrated fundamental rights and data protection impact assessments, and put the monitoring and complaint mechanisms in place that make those assessments credible.
