Human Rights, Democracy and the Rule of Law Risk and Impact Assessment

Description

HUDERIA is the Council of Europe's methodology for identifying and assessing the risks an AI system poses to human rights, democracy and the rule of law, and for planning how to prevent or reduce them, from design through deployment to retirement. It is non-binding guidance that public and private organisations may use or adapt in whole or in part; it was drawn up to support risk assessment in line with the Council of Europe's Framework Convention on Artificial Intelligence, and the human rights treaties its resources cite are illustrative, binding only the states that are parties to them. A multidisciplinary team first runs a context-based risk analysis (COBRA): it scopes the system's purpose, data and affected groups, works through risk factors in the system's application, design and deployment contexts, maps potential impacts on specific rights and on democratic and legal processes, gives each impact an initial rating, and triages the system, deciding whether further assessment is needed and whether the system should be built or deployed at all. Impacts are rated for severity, judged by scale (how serious the harm is), scope (how many people, which groups and for how long) and reversibility (whether those affected can be restored to their earlier position), and for probability; for systems that may pose significant risks, the team may engage affected stakeholders and then re-examines and re-rates each impact in a fuller risk and impact assessment. The output is a mitigation plan that prefers avoiding a harm to reducing, repairing or compensating for it, names who is responsible for each measure, outlines where appropriate the remedies open to affected people, and schedules repeat reviews as the system and its context change.

Example Use Cases

General

A city council's children's services department is offered a model that ranks safeguarding referrals for follow-up. A team of caseworkers, a data scientist and a human rights lawyer runs the context-based risk analysis, maps impacts on family life, non-discrimination and fair procedure, and at triage asks whether existing caseworker screening would serve the problem better and whether the referral data represent the families concerned, before deciding whether to procure the model at all.

A recruitment software company assessing a CV-screening model engages disabled and older job seekers, the groups its analysis found most exposed, then rates each mapped impact for scale, scope, reversibility and probability under a scoring rule it writes down. Its mitigation plan drops a feature that scored video interviews, an 'avoid' measure, rather than relying on correcting decisions afterwards, and names the owner of each remaining measure.

A national tax authority that assessed its fraud-risk model before launch repeats the risk and impact assessment when it adds bank-transaction data, and again when a change in benefit rules alters who is flagged. Each review updates the mitigation plan and the information and appeal routes offered to people wrongly flagged, so the assessment on file describes the system as it now runs.

A health ministry outside Europe adapts HUDERIA for a symptom-checker chatbot, keeping the treaty references in the risk-factor and impact lists only for the instruments its state is party to and adding its own constitution, health law and data protection law, while keeping the four elements and the severity variables so that its assessments follow a published structure others can recognise and check.

Limitations

HUDERIA leaves the rule for combining scale, scope, reversibility and probability into a risk level, and the thresholds used at triage, to the authorities or project teams applying it. Two teams can rate the same system differently and both be following the methodology, so an assessment can be compared or checked only if the team records the scoring rule it chose and why.
Stakeholder engagement and the detailed risk and impact assessment are optional, and are expected mainly for systems that the team's own triage finds may pose significant risks. A team that under-rates a system at triage can skip the stages most likely to expose the problem, so the evidence is stronger when someone outside the team has reviewed the triage reasoning.
The assessment rests on documents, expert judgement and what stakeholders report; it does not test the system. Probability ratings made before a system is built can be little more than informed estimates, so claims about how the system actually behaves, for example whether it treats groups differently, need test results from other techniques alongside the assessment.
HUDERIA assesses one system at a time. It asks teams to consider cumulative effects when a system runs alongside others serving similar purposes, which is where many harms to democratic and legal processes arise, but gives no method for estimating them. An assessment can therefore find each system acceptable while their combined contribution to a wider harm goes unmeasured, so claims about societal impact need evidence beyond a single assessment.
A full assessment needs people who can judge impacts on rights in law as well as people who understand the system's data and design, and it is meant to be repeated over the system's life. Organisations without access to human rights legal expertise may be unable to carry out the impact mapping and mitigation planning to the depth the methodology intends.

Resources

Research Papers

Human rights, democracy, and the rule of law assurance framework for AI systems: A proposal

David Leslie et al.•Jan 1, 2022

Documentations

HUDERIA Methodology and Model: Methodology for assessing the risks and impacts of artificial intelligence systems from the perspective of human rights, democracy and the rule of law

Council of Europe•Apr 1, 2026

Related Techniques

Name	Description	Assurance Goals
Algorithm Review Boards	An algorithm review board, also called an AI ethics board or AI review board, is a standing group from different disciplines that examines proposed AI systems or AI research projects before they proceed. It differs from an Institutional Review Board (IRB), which protects the human subjects of research, because it also weighs harms to the people a system will affect and to society. Many boards first sort projects by risk, and for higher-risk work the project team submits a written account of the system's purpose, data, foreseeable harms and planned mitigations, which members with technical, legal, ethical and domain backgrounds question and iterate on with the team. Where it has the power to decide, the board approves, approves with conditions such as a monitoring plan or a re-review date, or rejects; where it only advises, it recommends one of these. It keeps a dated record of its decision, reasons and conditions that later reviews and audits can check against what was built, and some organisations share that record with an oversight body or publish it.	General Transparency
Human-in-the-Loop Safeguards	Human-in-the-loop safeguards hold an AI system's output at a checkpoint until a trained person has reviewed it. Designers set the rules that send a case to review, such as low model confidence (the system's own estimate of how likely it is to be right), a high-stakes outcome or a request to appeal. Some schemes also review a random sample of routine cases to audit the rest. The reviewer approves, changes or rejects the output, and the record of each review shows how often people overrode the system. Review protects only where reviewers keep using independent judgement, so the design also has to guard against over-trust and fatigue.	General Safety Transparency
AI Incident Reporting with the OECD Common Reporting Framework	AI incident reporting with the OECD common reporting framework records each event in which an AI system caused harm, or could plausibly have caused it, in the common set of 29 fields the OECD published in February 2025, so that reports from different organisations, sectors and countries can be compared and pooled. The framework is meant for both mandatory and voluntary reporting and defines what a report contains, not the reporting interface or what should happen afterwards. The reporter first classifies the event using the OECD's definitions: an AI incident is an event in which the development, use or malfunction of an AI system directly or indirectly leads to harm to people's health, disruption of critical infrastructure, a violation of human rights or of laws protecting fundamental, labour or intellectual property rights, or harm to property, communities or the environment, and an AI hazard is one that could plausibly lead to such harm. Seven fields are mandatory: a title, a description, how the AI system was involved (as a direct cause, a contributing factor, a failure to act, through over-reliance or misuse, through human error, or through a failure to comply with the law), who is reporting, supporting material, the severity (hazard, serious hazard, incident, serious incident or disaster) and the type of harm. The other 22 record, where known and among other things, when and where it happened, the system and the organisations behind it, the people affected, the sector, how widely the system was deployed, whether training data, the model or several interacting systems were involved, the system's task and level of autonomy, and any action taken, giving an inspectable register of what went wrong in operation.	General