Confirm with counsel whether you must do one, then assess each high-risk capability separately. Describe what the agent does in the process, at what depth; name who is affected and how their rights could be harmed; record oversight and redress; and have a named senior person decide whether the residual risk is acceptable. Reopen it when the capability changes.
What is a fundamental rights impact assessment?
A fundamental rights impact assessment asks how an AI system's use could affect the rights of the people it touches: fair treatment, non-discrimination, privacy, access to essential services, the ability to challenge a decision. Article 27 of the EU AI Act requires certain deployers of high-risk systems to carry one out before first use. The provision and who it covers are set out in EU AI Act Article 27 fundamental rights impact assessment for AI agents, and whether your agent is in scope in do AI agents need a fundamental rights impact assessment?.
In substance, the assessment describes the process the system is used in, how long and how often it is used, the categories of people likely to be affected, the specific risks of harm to them, the human oversight measures, and what the deployer will do if those risks materialise, including governance and complaint arrangements. Where the Act requires it, the deployer notifies the relevant authority of the results.
The accountable owner is a named senior person, usually the executive responsible for the business area. Compliance runs the process. The agent owner, operations, data protection, and people who know the affected groups contribute. The wider set of controls is in AI agent regulation, mapped to controls.
Why assess an agent per capability?
The rights at stake depend on what the agent does, and an agent does several things. Drafting a reminder letter and recommending whether to extend credit to an individual affect people very differently. An assessment that treats the agent as one system ends up vague. One that takes each high-risk capability in turn can say precisely who is affected, how, and what stops harm.
Depth matters too. A capability that drafts for a person to decide carries different risks from one that acts. The assessment should state the current depth and be reopened if it widens.
What is the method?
- Legal: confirms whether an assessment is required for each capability, and whether a data protection impact assessment under GDPR Article 35 also applies. Evidence: the determination.
- Agent owner: describes the process: what the capability does, at what depth, how often, for how long, and what a person decides. Evidence: the process description.
- Compliance, with business and customer-facing staff: identifies the people affected: customers, applicants, employees, third parties, and groups who may be affected differently, such as people in vulnerable circumstances or those whose documents the agent reads less reliably. Evidence: the affected groups.
- Compliance: identifies specific risks of harm for each group: unfair refusal, unequal treatment, wrongful disclosure, loss of access to a service, inability to challenge. For an agent that acts, include harms from actions, not only from outputs. Evidence: the risk list.
- Agent, depth 1: supplies evidence from its records: refusal and hold patterns by case type, certification results on the escalation and adversarial gates, complaints.
- Agent owner: sets out oversight: which actions are held, who the named approvers are, their training, and how depth can be lowered. Evidence: the oversight description.
- Agent owner and complaints: sets out remedies: how a person can challenge an outcome, reach a human, and obtain redress; how work is taken back from the agent if harm appears. Evidence: the remedy arrangements.
- Accountable owner: decides whether residual risk is acceptable, with conditions, and signs. Evidence: the signed assessment.
- Compliance: notifies the authority where the Act requires. Evidence: the notification.
- Agent owner: reopens the assessment on any trigger: new capability, widened depth, new affected group, a pattern of complaints. Evidence: the review log.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Requirement | Nothing | none | Legal |
| Process | Describes its own capability and depth | 1 | Agent owner confirms |
| Affected people | Nothing | none | Compliance with staff |
| Risks | Nothing | none | Compliance |
| Evidence | Supplies patterns from records | 1 | Interpreting |
| Oversight | Nothing | none | Agent owner |
| Remedies | Nothing | none | Agent owner, complaints |
| Decision | Nothing | none | Accountable owner signs |
| Notification | Nothing | none | Compliance |
| Review | Flags triggers | 1 | Reopening |
A structured format is the fundamental rights impact assessment template for AI agents.
Which decisions stay with the named owner?
The judgement that residual risk is acceptable cannot be delegated to the agent, the vendor or the template. Nor can the conditions attached to it: a cap on depth, a group of customers for whom every action is held, a requirement for monthly complaint review. The owner also decides when the assessment must be reopened beyond the set triggers. Their signature, and the reasoning behind it, is what a supervisor will ask to see.
How does this relate to other assessments?
A data protection impact assessment under GDPR focuses on personal data processing. The fundamental rights assessment is broader: it covers harms that do not involve data protection, such as unfair treatment in access to a service. Where both are required, run them together and cross-refer, rather than producing two documents that disagree.
Voluntary frameworks can help structure the work. The NIST AI Risk Management Framework's approach to mapping impacts is a useful companion; see NIST AI RMF impact assessment for AI agents.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What are the signs it is going wrong?
The assessment is generic. It lists every fundamental right and says the risk is low for each. No specific harm, group or control appears.
Affected groups are guessed. No one who deals with customers was asked.
Oversight is described as it should be, not as it is. Approvers named in the assessment have never worked the held queue.
The assessment is filed and forgotten. Depth widens, a capability is added, and the signed version still describes the pilot.
Questions people ask
Who should be consulted?
People who know the affected groups: front-line staff, complaints handlers, and where appropriate representatives of customers or workers. Their input is what makes the risk list specific.
Can we reuse a provider's assessment?
A provider's material can inform yours, but the assessment concerns your use, your process and your customers. It must be your own.
What if the assessment finds the risk unacceptable?
Then the capability does not go live as designed. Lower its depth, narrow its scope or add oversight, and reassess.