ISO/IEC 42001 requires top management to assign and communicate responsibilities and authorities for the AI management system. For AI agents, that comes down to one rule: every agent has a named owner, and every action needing approval has a named approver with a deputy. Whoever writes an agent's brief should never be the one who approves it.
What does the standard require on roles?
ISO/IEC 42001:2023, like other management system standards, puts leadership at its centre. In substance:
- Top management demonstrates leadership and commitment, sets the AI policy, and makes sure responsibilities and authorities for relevant roles are assigned and communicated.
- Someone is assigned responsibility for making sure the management system conforms to the standard and for reporting on its performance to top management.
- The annex controls on internal organisation expect roles and responsibilities for AI to be defined and allocated according to the organisation's needs, and a process for reporting concerns about AI.
- Competence requirements mean people in those roles have the skills to perform them, with evidence.
The standard does not prescribe job titles. It expects every responsibility that matters to belong to someone. Our explainer on what ISO/IEC 42001 is gives the wider structure.
Who does it apply to?
Any organisation adopting ISO/IEC 42001, whatever its role in AI. A vendor assigns roles over how agents are built and supplied; a deployer assigns roles over how they are used. Many organisations are both, and the role map should show which hat each person wears.
Which roles does an agent need?
An agent is not a model sitting in a repository. It acts in business processes, so its roles must span the technology and the business. Seven roles cover most deployments.
- Top management approves the AI policy and the limits within which agents may operate.
- The management system lead runs the AI management system and reports on it.
- The agent owner is accountable for one agent: its purpose, risks, performance and retirement.
- The brief author writes and changes the agent's brief, sources and bounds.
- The brief approver reviews and approves changes before release, independent of the author.
- The overseer decides on actions the agent holds for a person, and has a named deputy.
- The internal auditor tests that the system and agents work as documented, independent of all of the above.
Two roles carry most of the weight. The agent owner should sit in the business, not in technology, because the agent's risks are business risks: a wrong refund, a missed complaint, a held payment. The overseer must be someone who knows the process well enough to disagree with the agent; our piece on ISO/IEC 42001 human oversight controls covers that role in depth.
What changes because agents act?
Three features of agents make role design more demanding than for other AI.
Authority must map to people. Every action an agent may take is an authority someone granted. If nobody can say who granted the agent its permission to issue refunds, the role design has failed. Record, per capability, who approved the authority and on what evidence.
Separation of duties matters more. An agent's brief changes its behaviour as much as code does. If the same person writes and approves it, there is no check. The same applies to the person who owns an agent and the person who audits it.
Roles go stale. People move. An agent whose owner left six months ago still runs, still acts and still holds actions for an overseer who no longer exists. Tie roles to the joiner, mover and leaver process so changes trigger reassignment.
The impact assessment is a good place to anchor these roles, because it names who is affected; see ISO/IEC 42001 AI system impact assessment for agents.
How do you meet the requirement with evidence?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Roles assigned and communicated | Role register listing each agent's owner, approvers, overseers and deputies | Role register with acknowledgements |
| Authority traceable | Each capability's authority recorded with who granted it | Authority records per capability |
| Separation of duties | Brief author and approver must differ; owner and auditor must differ | Change records showing both identities |
| Competence | Training defined per role and completed | Training records by role |
| Roles kept current | Leavers and movers trigger reassignment before access ends | Reassignment records |
| Concerns can be raised | Route for staff to report concerns about an agent | Concern log and outcomes |
| Reporting to management | Management system lead reports agent performance and issues | Management review inputs |
What will an auditor ask?
- Who owns this agent, and when did they last review it?
- Who approved its current brief, and who wrote it?
- Who decides when it holds an action, and who covers when they are away?
- Show us what happened when the previous owner left.
- How were the people in these roles trained?
- How can staff raise a concern about an agent?
What does the standard not settle?
It does not assign legal accountability; regimes such as the UK's Senior Managers and Certification Regime or sector rules do that. It does not tell you how many people you need. And it is one option among frameworks; see whether to follow the NIST AI RMF or ISO/IEC 42001 and whether you need ISO/IEC 42001 to deploy agents. For the principle that authority must be bounded and owned, see our guide agent governance is a bound, not a model.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
In Pryme, every held verdict names the person who must decide, and every brief change is versioned with who made and approved it. An agent with no current owner or overseer cannot route its held actions, which surfaces stale roles quickly instead of letting actions wait on someone who has left.
Questions people ask
Can one person own several agents?
Yes, if they have the time and knowledge to answer for each. Owners of many agents should have deputies and clear reporting so nothing goes unreviewed.
Should the agent owner be technical?
Usually not. The owner should understand the business process and its risks. Technical colleagues build and run the agent under the owner's direction.
What if an agent spans several departments?
Name one owner anyway, with named contacts in each department. Shared ownership tends to mean nobody answers when something goes wrong.