Who owns the AI risk stance?

The model-risk question is the wrong question.

Banks got good at one test. Is the model accurate, on representative data, with its limitations written down? That test assumes a model produces an output and a human decides what to do with it. The human is the actor. The model is an instrument.

An agent is not a longer prompt. It retrieves, reasons, acts, and routes. It can open a record, call a tool, and hand work on before anyone has read the result. A weak prompt returns a weak answer. An unbounded agent takes an action. A model can pass validation and still be doing something nobody authorised.

Prompting keeps a person on every turn. Agenting delegates the loop, and the specification has to say what that delegation includes, because the prompt will not hold it. BLUEPRINT treats the agent as a system allowed to act: a mandate, limits, and permissions that can be enforced. If the model does not need to choose its own next step, keep it a prompt or a fixed workflow. Autonomy is a design choice, not a default that arrives with a new model.

The question is no longer whether the model is good enough to deploy. It is whether anyone has decided what the system may do when no one is watching the next step.

Five risks a validation report was not built to hold.

Model risk stays. These five sit on top of it.

Access. An agent inherits whatever its tools can reach. A retrieval that looked harmless in a demonstration becomes a sweep across client records, payment instructions, or internal correspondence once it meets production entitlements. The question is whose permissions it is using, and whether the platform makes the wrong access impossible rather than merely discouraged.

Evidence. A score can sit beside its inputs. An agent leaves a chain of retrievals, judgements, tool calls, and handoffs. If that chain is not kept, the institution cannot reconstruct why an action happened. An action you cannot explain is an action you cannot defend.

Operational. Agents fail the way processes fail. They loop, stall, call the wrong tool, or mark a step complete when it is not. The risk is a workflow that keeps moving after it should have stopped. Containment, a way to undo the action, and a hard stop belong in the design, not in the note written afterwards.

Change. A model is promoted through a release. An agent also changes when a prompt is edited, a tool is added, a source is refreshed, or a vendor ships a new model under a name that did not change. Treat that as change with an owner and a test, or a controlled pilot becomes a habit.

Ownership. This is the risk the other four conceal. Access without an owner is an entitlement nobody narrows. Evidence without an owner is a log nobody reads. Failure without an owner circulates. Change without an owner is drift. Model risk can name a model owner. It rarely names the person accountable for what the agent did on a Tuesday afternoon.

A control library that only asks whether the model is accurate is governing the instrument and leaving the actor alone.

Write the boundaries before the first production run.

The boundaries have to exist before deployment, in language a non-specialist can challenge. I use three tiers.

Always do. Work the agent may finish without asking, because it is reversible, inside the mandate, and already authorised. Retrieve approved context for a defined job. Draft a note that cannot leave the institution until a person sends it. Record what was done.

Ask first. Anything consequential. A message that will reach a client. A change to a record another team will treat as fact. A recommendation that could be mistaken for advice. The agent prepares. A person decides. Ask first is a gate the system enforces, or it is not a control.

Never do. Actions that stay out of mandate even if someone asks, and even if the agent is confident. Regulated advice it is not permitted to give. Moving money. An identity it was not issued. A system it was not entitled to reach. A source invented because none could be found. A never-do that lives only in a prompt is a hope. A never-do enforced in permissions is a control.

EVOLVE puts the same discipline at enterprise altitude: multi-step work inside explicit boundaries — always, ask first, and never — with people at the consequential decision. The lists stop a pilot from inheriting whatever the demonstration could do. If they cannot be completed, there is not a use case. There is an experiment, and experiments do not belong on client work.

Autonomy is a licence, not a launch setting.

Most institutions set autonomy once, at go-live, and then treat it as a property of the model. It is a permission. It should widen only when the live workflow earns it, against three thresholds measured on the work as it runs, not on a curated demonstration.

Quality. Does the output meet the standard the owner defined — the definition of done for this job, not a generic accuracy score? If the standard is not written down, there is nothing to clear.

Exception rate. How often does a run leave the always-do path and need a person? A falling rate means the boundary is holding. A rising rate means the agent is meeting cases the design did not anticipate. That is a reason to stop and redesign, not to push through.

Traceability. Can a consequential action be reconstructed: what was retrieved, decided, and done, and who was accountable? If it cannot, autonomy contracts.

Clear all three, and the always-do list may widen. Miss one, and it narrows. A successful pilot is not a reason to remove the human. Autonomy that only ratchets upward is optimism with a change ticket.

A name, not a forum.

Every AI workflow needs a human who sets the standard, approves consequential outputs, and owns the exceptions. Not a working group. Not a shared inbox. A named owner.

That person defines what good looks like, in terms a reviewer can apply without them in the room. They approve the outputs that leave the institution, change a record, or could be relied on by someone else. They own the exceptions: the failed runs, the cases the boundary did not anticipate, and the decision to tighten or widen what the agent may do alone.

Risk, compliance, technology, and the business can advise. A forum cannot be the owner, explain the judgement, or change the standard by the end of the week.

Relationship-led work feels this earlier than a transaction line. Two situations with the same summary numbers can call for opposite treatments. An agent can assemble the case. It cannot own the relationship, or the exception that does not fit the pattern. The owner is the person who can say that this case is different, and here is what we will do.

If that name cannot sit next to the workflow, do not deploy the agent. Keep a person on every turn. Calling an unowned agent a pilot does not shrink it. It hides the gap.

Supervisors are already talking about the actor.

Waiting for a final rule before naming an owner is a way of not deciding. The supervisory direction is already past the poster.

MAS FEAT — fairness, ethics, accountability, and transparency — still frames AI and data analytics in Singapore’s financial sector. It does not tell a bank how to bound an agent that can use tools. In November 2025, MAS consulted on proposed AI Risk Management Guidelines covering generative AI and AI agents, with oversight at the board and senior management. In August 2026, MAS told Parliament that those expectations apply to agentic AI and would be finalised soon, and pointed to Project MindForge and Safeguards for Agentic Finance at Runtime: how actions are authorised, when a person is brought in, and what is recorded. It did not make that approach a binding rule.

The EU AI Act, Regulation (EU) 2024/1689, reaches the same problem from another legal tradition. It covers systems designed to operate with varying levels of autonomy and to produce outputs that can influence an environment. Where a use is high-risk, it requires human oversight and expects the organisations involved to understand the system and keep control of it. Not every bank workflow is in that class. The convergent demand does not wait on the classification: know what the system can do, bound it, keep a person accountable for consequential outcomes, and be able to show the work.

Neither text supplies the three tiers. Both make it unreasonable to call an agent just a model because the validation pack still says so.

Someone has to sign.

Who signs the AI risk stance? Not the vendor, the model card, or the forum that noted the pilot. The stance is what this class of system may do, what it must ask, what it must never do, how autonomy is earned and withdrawn, and which named person is accountable when the agent acts. In a regulated bank that signature belongs with the executive accountable for the workflow’s outcomes, advised by risk, compliance, and technology, and visible to the board. If that person cannot describe the three tiers for the workflows already running, the institution has activity, not a stance.

Many still cannot answer. They can report accuracy and name a vendor. They cannot say who approves a consequential output, who owns the exception, or what would make them take autonomy back. That is an accountability gap. A better prompt will not close it.

Write the stance. Name the owner. Then, and only then, let the agent act.

Named here, not quoted: the MAS FEAT principles; the MAS consultation on proposed Guidelines on Artificial Intelligence Risk Management (November 2025) and MAS’s written parliamentary reply on agentic AI in financial services (August 2026); and the EU AI Act, Regulation (EU) 2024/1689.

The views and ideas in this essay are my own and do not necessarily represent those of my employer.