Key takeaways
- An AI impact assessment measures what a system does to people, not what it costs the organisation. That orientation decides which rules apply to it.
- Six separate instruments share the name. Only some bind you legally, and which one applies depends on your role, your sector and your jurisdiction.
- The EU AI Act Article 27 fundamental rights impact assessment is owed by three narrow categories of deployer, not by every organisation that uses AI.
ISO/IEC 42005is the method to reach for when no statute compels you. It is guidance, and nobody can certify you against it.- The timing moved. Article 27 now applies from 2 December 2027, and Colorado deleted its own impact assessment duty in May 2026.
What an AI impact assessment actually is
An AI impact assessment is a structured evaluation of how an AI system affects the people it touches: the individuals subject to its outputs, the groups it sorts, and the wider public that lives with the consequences. The orientation is outward. That single property separates it from most of the assessment work an organisation already does.
A risk assessment asks what a system could cost you: regulatory exposure, downtime, reputational damage, model failure. An AI impact assessment asks what the system could cost someone else, such as a rejected loan applicant, a wrongly flagged traveller, or a candidate filtered out before a human ever opened the file. The two overlap, because harm to people becomes harm to the organisation eventually, but they are not substitutes. A company can maintain a complete AI risk register and still have no evidence about whether its systems treat people fairly.
The second defining property is timing. An AI impact assessment is a decision-making milestone, not a report written after go-live. It exists to change the deployment decision while that decision is still open. Assessments produced after procurement has closed and the contract is signed tend to document choices rather than inform them, which is the most common failure mode practitioners report.
Public-sector bodies have been formalising this for longer than private ones. The Australian Government’s AI impact assessment tool is a fillable workbook that walks an agency through purpose, expected benefits and an inherent risk assessment across eight categories before any threshold test is applied, which is a useful shape to borrow even where no policy compels you.
The third property is that the output is a record. Whatever framework you follow, the deliverable is a written artefact naming the system, the affected groups, the harms considered, the mitigations adopted, and the person who accepted the residual position. That artefact is what a regulator, an auditor or a claimant will eventually ask to see.
Six regimes, one name
The phrase covers at least six distinct instruments. They differ on who is bound, what triggers them, what you must produce and whether anyone can penalise you for skipping the exercise.
| Instrument | Who is bound | Trigger | Output | Enforceable |
|---|---|---|---|---|
| EU AI Act Art. 27 FRIA | Three deployer categories only | Before first use of an Annex III high-risk system | Written assessment, notification to the market surveillance authority, public summary | Yes, from 2 Dec 2027 |
ISO/IEC 42005:2025 | Anyone adopting it | Voluntary, continuous across the lifecycle | Documented assessment inside an AI management system | No, guidance only |
| GDPR Art. 35 DPIA | Any controller | Processing likely to be high risk to rights and freedoms | DPIA record, prior consultation if residual risk stays high | Yes, since 2018 |
| Canada, Directive on Automated Decision-Making | Federal institutions | Before production of an automated decision system | Algorithmic Impact Assessment, published openly | Yes, as policy on federal bodies |
| Colorado SB 24-205, as amended | Deployers in Colorado | Effective 1 Jan 2027 | Disclosures only, the assessment duty was repealed | Partly, see below |
| NYC Local Law 144 | Employers using automated employment decision tools | Annually, before use | Independent bias audit, published summary | Yes, since July 2023 |
Two observations matter more than the table itself.
First, the only instruments that carry penalties for a private company in Europe are the AI Act and the GDPR, and they bite in different places. Second, most organisations that search for this topic are not bound by Article 27 at all, and would be better served by ISO/IEC 42005 as a method than by a legal text that does not name them. Getting this right early saves a great deal of wasted work. The wider map of which statute reaches which organisation is covered in our guide to the EU AI Act, the Colorado AI Act and automated employment decision tools.
Who actually owes an Article 27 FRIA
This is where most published guidance is imprecise. Article 27 does not apply to everyone deploying a high-risk system, and it does not apply to providers at all.
Three categories of deployer are required to carry out a fundamental rights impact assessment, as set out by the European Center for Not-for-Profit Law and the Danish Institute for Human Rights in their practitioner guide to the obligation:
- Public authorities deploying high-risk AI systems in the Annex III areas: biometrics, education and vocational training, employment, access to essential private and public services, law enforcement, migration and border control, and the administration of justice and democratic processes.
- Private entities providing essential public services.
- Insurance and banking companies using AI to price life and health insurance or to evaluate the creditworthiness of natural persons.
Everyone else deploying a high-risk system still carries the Article 26 deployer duties, including human oversight and serious incident reporting, but not the FRIA.
Providers are outside Article 27 entirely. Their equivalent obligation is the Article 9 risk management system, which runs across the whole lifecycle of the system they place on the market. This split confuses people because both processes examine harm, but they sit with different parties and produce different records. Our EU AI Act operators guide sets out which role attracts which duty.
A practical consequence: if you are a software vendor selling a high-risk system into European public authorities, you will be asked for material that feeds your customers’ FRIAs even though you owe none yourself. Contractual clauses on data quality, explainability documentation and notification of changes affecting accuracy are the usual mechanism.
What Article 27 requires you to produce
The Article specifies the contents. A fundamental rights impact assessment must describe the deployer’s processes in which the high-risk system will be used in line with its intended purpose; the period and frequency of intended use; the categories of natural persons and groups likely to be affected; the specific risks of harm to those categories, taking account of the information the provider supplied; the human oversight measures being implemented, following the instructions for use; and the measures to take if those risks materialise, including internal governance arrangements and complaint mechanisms.
Two obligations sit alongside the document itself. The deployer notifies the market surveillance authority of the results, subject to a narrow exemption. Public-entity deployers publish a summary of the assessment in the EU high-risk database, with summaries from law enforcement and migration authorities going to a restricted part visible only to market surveillance authorities.
The publication duty is the part most teams underestimate. A summary written for public consumption has to explain, in language a non-specialist can follow, how the system is used, what decisions are taken with its outputs, what the assessment found, what mitigations were adopted, why the deployment was judged acceptable, and how someone affected can complain. Documentation drafted purely for internal defensibility rarely survives that translation. Building the record properly the first time is far cheaper, which is the same argument that applies to AI system documentation generally.
FRIA, DPIA, and where the boundary sits
Organisations bound by Article 27 are almost always bound by Article 35 of the GDPR as well, so the practical question is whether to run one process or two.
The ECNL and Danish Institute guidance treats them as separate but complementary, and that is the safer default. A data protection impact assessment addresses risks arising from processing personal data. A fundamental rights impact assessment addresses impacts on the full set of rights in the EU Charter, including harms with no processing nexus at all. Worker displacement caused by introducing an AI system is the clearest example: no personal data question arises, and a DPIA has no place to record it. The same is true of de-skilling among professionals who come to rely on automated outputs, and of effects on access to education or healthcare that operate at the level of a group rather than an identified person.
In practice, most teams share the inputs and keep the outputs distinct. The system description, the data map and the stakeholder list serve both. The rights analysis, the severity method and the consultation record belong to the FRIA. Merging them entirely tends to produce a document dominated by data-protection vocabulary, in which the non-data harms quietly disappear.
ISO 42005: the method when no law compels you
ISO/IEC 42005:2025 was published in April 2025 and gives organisations a structured method for AI system impact assessment. It covers how to scope the assessment, how to consider technical behaviour, data, user workflow, affected groups, foreseeable misuse, accountability, controls and monitoring, and how to reassess across the lifecycle.
Two facts about it are routinely misstated. It is guidance, not a requirements standard, so there is no certification against ISO/IEC 42005 and any claim to be certified to it is wrong. And it is designed to sit inside an AI management system rather than beside one, complementing ISO/IEC 42001 rather than competing with it. If you already run a management system, the impact assessment becomes one of its documented processes rather than a standalone exercise.
For the large majority of organisations, this is the right instrument. It gives you a defensible method, it maps onto the AI Act contents if you later fall in scope, and it produces the evidence trail that customers and insurers increasingly ask for. Adopting it is a decision you can make now, without waiting for a regulator to name you.
How to run an AI impact assessment
The method below follows the five-phase structure in the ECNL and Danish Institute guidance, which was built for Article 27 but transfers cleanly to a voluntary assessment.
Set up the team and scope the work
Three staffing models exist. An in-house cross-functional team preserves accountability and builds internal capability, but can be superficial where expertise is thin. An externalised assessment buys independence and expertise, but can dilute ownership and miss institutional realities. A hybrid, an internal team advised by an external steering group, tends to work best for large deployments, at the cost of coordination effort.
Scoping means a context analysis across three clusters: the deployment context, meaning intended purpose, timeframe, what decisions are taken with the output and who is affected; the system features, meaning technical behaviour, personal data processing, and what is known about data quality and accuracy; and the governance arrangement, meaning the split of responsibilities with the provider, the monitoring process, and the measures for human oversight and transparency.
Assess severity and likelihood
Build three to five concrete scenarios describing how the system might harm people, including a worst case, and identify every right each scenario touches. Rights are interconnected, so a biased system in education can reach non-discrimination, the right to education, children’s rights and privacy simultaneously.
Severity is then assessed on four parameters: the extent of the interference with the right, the scope of the impact and how many people it reaches, the gravity of the material, psychological or physical harm, and the irreversibility of that harm. Likelihood turns on the provider’s compliance with its own obligations, the quality of the data, the degree of meaningful human oversight, the scope for further modification, and the potential for malicious interference.
Pay particular attention to people in situations of vulnerability, who experience the same impact more severely and have fewer routes to remedy. The AI Act itself names persons in extreme poverty, ethnic and religious minorities, children, and people with disabilities.
Choose mitigations and decide
Mitigations fall into three families. Organisational measures cover human oversight, complaint handling, public transparency and staff competence. Technical measures cover logging, security and input data quality. Contractual measures bind the provider on data representativeness, on supplying documentation for explainability requests, and on notifying changes that affect accuracy.
The deployment decision then depends on which rights are in play. A small number of rights are absolute, including freedom from torture and freedom of thought, and no interference with them is acceptable at any severity or likelihood. The rest are qualified, meaning an interference can be lawful if it is provided by law, serves a legitimate objective, and is necessary and proportionate. The assessment team is not a court and is not expected to reach judicial precision, but working through the test shows you the criteria your conduct would eventually be judged against.
Monitor and update
The assessment is not finished at deployment. Monitor whether the mitigations actually work, using complaint volumes and their resolution, the observed quality of human oversight, and user feedback. Update the assessment when the use changes, when impacts appear that were not captured, when a mitigation underperforms, or when the law moves.
The 2026 timing reality
Anything written about this topic before mid-2026 is now partly wrong on dates.
In Europe, the Digital Omnibus on AI, Regulation (EU) 2026/1744, was approved by the European Parliament on 16 June 2026 and by the Council on 29 June 2026, published in the Official Journal on 24 July 2026 and in force from 27 July 2026. It defers the Annex III standalone high-risk obligations, and with them the Article 27 FRIA, from 2 August 2026 to 2 December 2027. Annex I embedded high-risk moves to 2 August 2028. The prohibited practices in Article 5 are unaffected and have applied since 2 February 2025.
Article 27(5) requires the AI Office to develop a template questionnaire to help deployers comply. As of mid-2026 it had not been published, and there is no deadline attached to it. Its absence does not suspend the obligation, so organisations in scope should build their method now rather than wait for a form.
In the United States the movement went the other way. Colorado SB 189, signed on 14 May 2026, delays the Colorado AI Act to 1 January 2027 and removes the duty of care against algorithmic discrimination, the deployer risk management programme and the impact assessment obligation, leaving a framework focused on disclosure and transparency plus limited rights to access, correct and obtain human review. Any guidance still describing a Colorado impact assessment duty is describing a repealed provision. Our roundup of AI laws in 2026 tracks the moving pieces.
The net effect for a European deployer is roughly eighteen extra months, and a strong argument for using them on the method rather than on the deadline.
FAQ
Is an AI impact assessment legally required?
Sometimes. Under the EU AI Act it is required only of three deployer categories: public authorities using Annex III high-risk systems, private entities providing essential public services, and insurers and banks using AI for life and health pricing or creditworthiness. Under the GDPR a DPIA is required whenever processing is likely to result in high risk to rights and freedoms, which is a much wider net. ISO/IEC 42005 is voluntary. Most private companies owe no statutory AI impact assessment and adopt one as good practice.
What is the difference between an impact assessment and a risk assessment?
Direction. A risk assessment protects the organisation from the system, and measures exposure, cost and failure. An AI impact assessment protects people from the system, and measures effects on their rights, opportunities and treatment. The AI Act uses both: Article 9 gives providers a risk management system, while Article 27 gives certain deployers a fundamental rights impact assessment.
Is an AI impact assessment the same as a DPIA?
No. A DPIA under Article 35 of the GDPR addresses risks that arise from processing personal data. A fundamental rights impact assessment addresses impacts on all EU Charter rights, including harms with no data-processing dimension such as workforce displacement. Organisations bound by both usually share the inputs and keep the two records separate.
Can we get certified to ISO 42005?
No. ISO/IEC 42005:2025 is a guidance document, not a requirements standard, so there is nothing to audit against for certification purposes. The certifiable standard in this family is ISO/IEC 42001, the AI management system standard, and an impact assessment process can be evidenced within that certification.
When do we have to have this done?
For deployers in scope of Article 27, before first use of the system, and the obligation applies from 2 December 2027 after the Digital Omnibus deferral. For a DPIA, before the processing begins. For NYC Local Law 144 bias audits, within the twelve months preceding use. For a voluntary ISO/IEC 42005 assessment, before the deployment decision, then repeated across the lifecycle.
Who should carry out the assessment?
A cross-functional team, not the model owners alone. The guidance recommends combining fundamental rights knowledge with engineering, legal, data protection, procurement and operations, and consulting the people the system will affect or their legitimate representatives. Where internal rights expertise is missing, buy it in or pair the internal team with an external advisory group rather than skipping the perspective.
Conclusion
The useful question is not how to run an AI impact assessment in the abstract but which one you owe and what evidence it leaves behind. For most organisations the honest answer in 2026 is that no statute names them yet, that ISO/IEC 42005 is the method worth adopting, and that the eighteen-month deferral of Article 27 is an opportunity to build the record properly rather than a reason to wait.
What separates a defensible assessment from a filed one is the trail underneath it: the scenarios considered, the severity reasoning, the mitigations assigned to named owners, and the monitoring that shows they held. AI Sigil keeps that trail as a live record against every system and framework you operate, so the assessment is a by-product of how you govern rather than a document you reconstruct under deadline. See how the AI governance model fits together.