Run it per agent capability, not per agent. ISO/IEC 42001 requires a defined AI risk assessment process that gives consistent, comparable results, weighs consequences for the organisation, individuals and society, compares risks against set criteria, and leads to treatment with controls justified against the standard's annex. For agents, the consequences turn on which actions they can take.
What does ISO/IEC 42001 require?
In substance, the organisation must define and use an AI risk assessment process that:
- is informed by the AI policy and AI objectives;
- is designed so repeated assessments produce consistent, valid and comparable results;
- identifies risks that help or hinder achieving AI objectives;
- analyses risks by assessing potential consequences for the organisation, for individuals and for societies, and the realistic likelihood, and determines the level of risk;
- evaluates risks by comparing them with risk criteria and prioritising them for treatment.
The organisation must establish risk criteria that separate acceptable from unacceptable risks. It must then treat risks: choose treatment options, determine the necessary controls, compare them with the controls in Annex A to check nothing necessary was missed, produce a statement of applicability, prepare a risk treatment plan and obtain approval of residual risk from designated management. Assessments are repeated at planned intervals and when significant changes occur, with documented results kept.
Who does it apply to?
Organisations implementing an AI management system under ISO/IEC 42001, whether as developer, provider or user of AI. Whether you need the standard at all to deploy agents is answered in do you need ISO/IEC 42001 to deploy AI agents; short answer, no, but many regulated firms adopt it.
What does the assessment mean when the system is an agent that acts?
Two requirements bite harder for agents than for other AI.
Consistency and comparability. The standard wants assessments that would reach the same answer if repeated. Agent assessments often fail this because they rely on general impressions: "the model sometimes hallucinates; medium risk". To be consistent, analysis must rest on fixed criteria and evidence, such as the agent's performance on a defined set of real cases.
Consequences for individuals and society. An agent that acts produces consequences directly. A wrong answer is one thing; a wrong payment, a closed account or a missed complaint deadline is another. The analysis must look at what each action does to people when it goes wrong.
How do you run the assessment for an agent?
- List the capabilities. Break the agent into what it does: for example, reads account history, drafts a repayment plan, sends the plan, updates the account status.
- Rate each action against fixed criteria. Use criteria based on reversibility and harm, set once for the organisation so every assessment uses the same scale.
- Identify risks per capability. For each, ask what goes wrong: wrong data, wrong reasoning, wrong scope, manipulation, failure to escalate, unfair outcomes, drift after a change.
- Estimate likelihood from evidence. Use test results on cases from your own operation, not vendor claims. Where there is no evidence yet, treat likelihood as high.
- Assess consequences on three levels. For the organisation, for the individual affected and for society or groups, as the standard requires.
- Evaluate against criteria. Decide which risks are acceptable, which need treatment and which make the capability unacceptable.
- Choose treatments. Narrow sources, set limits, hold actions for a person, or remove the capability.
- Check against Annex A. Confirm no necessary control has been missed; record decisions in the statement of applicability.
- Approve residual risk. The accountable owner signs off what remains.
- Set triggers for reassessment. Brief changes, new sources, model changes, incidents and the planned cycle.
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Defined, consistent process | Written method with fixed criteria and capability-level scope | Approved methodology |
| Risk criteria | Criteria based on action reversibility and harm | Criteria document |
| Identification | Risk list per capability using a standard set of failure types | Risk register |
| Analysis of likelihood | Evidence from testing on the organisation's own cases | Test results linked to entries |
| Consequences for individuals and society | Three-level consequence rating per risk | Analysis records |
| Evaluation and prioritisation | Comparison to criteria; ranked treatment list | Evaluation records |
| Treatment and Annex A comparison | Controls selected and checked against Annex A | Treatment plan; statement of applicability |
| Residual risk approval | Owner sign-off | Approval records |
| Reassessment | Triggered by change and on schedule | Reassessment log |
Consequences for individuals overlap with the separate impact assessment the standard also requires; see ISO/IEC 42001 AI system impact assessment for agents for how to keep the two distinct but linked.
What will a certification auditor ask?
- Show us your risk criteria. Would two assessors apply them the same way?
- How did you estimate likelihood for this agent, and on what evidence?
- Where do consequences for individuals appear in the analysis?
- How did you use Annex A to check your controls?
- Who approved the residual risk, and when?
- What triggered the last reassessment?
What does the requirement not cover?
It does not prescribe criteria, tests or thresholds. It does not replace legal risk assessments such as a DPIA. The NIST AI RMF covers similar ground with a different structure; see NIST AI RMF vs ISO/IEC 42001 for AI agents and whether to follow the NIST AI RMF or ISO/IEC 42001. For the standard as a whole, see what ISO/IEC 42001 is, and for the full map, AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Can one risk assessment cover several similar agents?
Yes, if they share capabilities, sources and limits. Assess separately any agent whose actions or data differ, because consequences and likelihood will differ.
How should a model change be treated?
As a significant change that triggers reassessment, at least for likelihood. Retest the affected capabilities on the same cases and compare.
Is a high-risk agent action ever acceptable?
Yes, if treatments bring residual risk within criteria and the owner approves. Often that means a person releases the action, or limits keep the harm small.