Every limit an AI agent obeys is a statement of risk appetite, translated into a number. Risk managers own that translation, and the risk register behind it, which is why they are the real control in an agent deployment: if those numbers are wrong, every downstream control inherits the error.
How does risk appetite become an agent's limit?
Through the minimum chain. Every agent action meets five bounds at once: role scope, certificate, sources, the organisation's own limits and the platform guardrails. The lowest one wins, and the verdict names which bound decided. The organisation's own limits are where risk appetite turns into something an agent obeys at the moment of action.
A board might say it has low appetite for customer detriment from automated decisions. That sentence means nothing to an agent. A per-capability limit does: refunds up to 100 may execute, above that they are held; affordability exceptions are always held; payments to new payees are held regardless of value. Translating appetite into these limits, and keeping them aligned as the business changes, is a core risk management skill once agents arrive.
What belongs in the risk register for an agent?
Each agent capability is a source of risk, and the register should treat it that way. Useful entries describe the capability, its depth, the worst credible outcome, the controls and the evidence those controls leave:
| Capability | Depth | Worst credible outcome | Controls | Evidence |
|---|---|---|---|---|
| Draft customer replies | 2 | Misleading promise sent | Reviewer approval, sampling | Approver name and decision in the record |
| Execute small refunds | 3 | Refunds to wrong accounts | Value limit, sealed account data | Verdicts naming the limit |
| Release held payments | 4 | Funds lost to fraud | Hold for named person, second approver | Two approver names per release |
| Coordinate other agents | 5 | Authority passed beyond bounds | Orchestrator certification, platform floor | Chain of verdicts per task |
A register built like this lets the risk manager answer the questions a board or supervisor will ask: what can go wrong, how likely, what stops it, and how we know.
Which indicators should a risk manager watch?
The record is a source of key risk indicators that most functions never had. Every verdict is filed in an append-only record, so trends are visible. Rising overrides of refusals suggest reviewers are under pressure or limits are too tight. Falling hold rates may mean the agent's work changed, or a limit was quietly raised. Certificate lapses show where assurance is thin: certificates lapse after 90 days, and a run that clears no depth drops the agent to depth 1 the same day.
Risk managers who learn to read these signals can challenge the first line with evidence rather than opinion. That is the second line doing its job.
The record also changes how incidents are analysed. In a manual process, reconstructing a bad decision means interviews and partial notes. With agents, the risk manager can see the verdict, the deciding bound, the sources and their provenance, and the person who approved. That turns root-cause analysis from opinion into evidence, and it lets the risk manager tell whether a loss came from a weak limit, a stale source or a reviewer who did not look. Each of those needs a different fix.
Why is model risk only part of the picture?
Banks and insurers already manage model risk; in the United Kingdom, PRA SS1/23 sets model risk management principles for banks, and in the United States SR 11-7 has long shaped practice. Agents raise model risk questions, but the bigger exposure is often operational: an agent acting at the wrong depth, on a stale source, with a reviewer who did not look.
A risk manager who treats agents only as models will validate the agent and miss the operation around it. Training should cover both: what the certification evidence shows about the agent, and what the record shows about the people and limits around it. Frameworks such as the NIST AI Risk Management Framework, with its Govern, Map, Measure and Manage functions, and ISO/IEC 23894 on AI risk management, help structure this.
What does a risk manager need to learn?
How depth is earned: the role sets a ceiling, evidence from certification against the organisation's own cases sets the depth, and the lower wins. How to write limits that agents can enforce and people can explain. How to read verdicts and the record. Why withheld actions are a platform decision, not a setting the organisation can change, and what manual controls replace them. And how to challenge depth increases: a request for depth 4 on payments needs evidence, not enthusiasm.
The review method is in how risk managers review an AI agent's decisions. Operations managers turn the risk manager's appetite into daily practice, described in operations managers as the real control. Insurance gives the role a particular shape; the briefs on risk managers in insurance in Ireland and in Nigeria cover those markets. The overview is in AI agent skills by role.
Where the Academy fits
Risk managers often start with Pryme Intelligence Academy's Foundations track, then take the Operator track to see review from the inside. Those overseeing regulated, multi-agent deployments may go on to the Architect track, which ends in a capstone and a board review with two Pryme assessors and earns Certified Pryme Architect, valid for 24 months.
Questions people ask
Should risk managers approve every limit change?
They should approve changes that move a limit outside agreed appetite, and see all changes in the record. Small adjustments within appetite can sit with operations, provided each carries a reason and an approver.
How do risk managers test that limits are working?
By sampling verdicts near each limit and checking that actions above it were held and decided by an authorised person. The record makes this a routine test rather than a special exercise.
Is an agent's certification enough assurance for the risk function?
It is strong evidence about the agent on the organisation's own cases. It says nothing about whether reviewers are competent or limits are right, which the risk manager must assess separately.