Agentic AI changes the control question.

A conventional assistant produces an answer. An agent can plan, choose a tool, retrieve information, update a system or trigger the next step in a workflow. That ability creates value because it reduces hand-offs. It also creates risk because an error can become an action.

The wrong response is to treat governance as a large approval gate placed in front of every experiment. That slows low-risk learning without necessarily improving high-risk design. The better response is to build control into identity, data access, permitted tools, human approvals, evaluations, observability and audit trails.

Governance should make the safe path the easiest path.

Start with a bounded job

“Build an operations agent” is too broad to govern or deliver.

An agent needs a specific job, a defined user and a clear boundary. It might collect case context, compare it with an operating procedure, suggest a resolution and prepare an update for human approval.

The team can ask:

  • Which cases are in scope?
  • Which systems can the agent read?
  • Which tools can it invoke?
  • Can it write, or only draft?
  • When must a human approve?
  • What happens when information conflicts?
  • How is uncertainty shown?
  • Which event stops execution?

I would begin with reversible actions. Retrieval, classification, drafting and evidence preparation are easier places to learn than irreversible transactions. As performance and controls improve, the action set can expand deliberately.

Identity is the first control

An agent should never have a floating identity with broad access.

Its permissions should derive from the user, role, business domain, environment and specific workflow. If a user cannot access a client file, the agent acting for that user should not access it either. If a workflow only needs to draft an email, it should not receive permission to send one.

A practical identity model distinguishes:

  • the human user;
  • the agent or service identity;
  • the tools available to that agent;
  • the data scopes available in the current context;
  • the action that requires approval;
  • the accountable product and business owner.

The combination should be visible in logs. “The model did it” is not an acceptable ownership model.

Data access should be contextual

Not every user and use case needs the same AI environment.

Public and non-confidential work can operate with a relatively light control set. Internal business information needs domain access, approved knowledge sources and stronger data-loss controls. Confidential client or regulated data requires a controlled environment, explicit need-to-know permissions, restricted tools and deeper auditability.

FINMA’s Guidance 08/2024, published 18 December 2024, expects supervised institutions to consider the materiality of AI applications and align governance and controls accordingly. It identifies data security, data quality, model robustness, correctness, explainability, bias, third-party dependency and legal and reputational exposure among the relevant risks.

Those risks become more manageable when data access is a runtime policy, not a paragraph in a document.

Treat tools as products with permissions

Agentic systems become powerful through tools: search, CRM access, document retrieval, case updates, ticket creation, messaging or transaction systems.

Each tool needs a clear contract:

  • what it does;
  • which inputs it accepts;
  • which data it can expose;
  • whether the action is reversible;
  • which roles may invoke it;
  • whether approval is required;
  • what evidence is logged;
  • how failure is handled.

Sensitive tools can use a prepare-and-approve pattern. The agent gathers context and proposes an action. A human sees the evidence, edits if necessary and approves execution. This preserves judgement while removing administrative effort.

Human review must be meaningful. If the interface hides source evidence or encourages one-click approval across a long queue, the control exists on paper but not in practice.

Evaluate the workflow, not only the answer

Agent evaluation needs several layers.

First, evaluate the model output: factuality, relevance, source use and policy adherence. Second, evaluate tool selection: did the agent choose an allowed and appropriate action? Third, evaluate execution: were parameters correct, approvals respected and outcomes recorded? Fourth, evaluate the end-to-end task: did the workflow reach a good result with acceptable effort and risk?

A useful test set includes common and edge cases, ambiguous instructions, missing data, conflicting sources, attempts to exceed permissions and cases where the correct behaviour is to stop.

The BIS paper “Regulating AI in the financial sector: recent developments and main challenges” (12 December 2024) points to governance, skills, model risk, data governance and third-party AI providers as areas requiring particular attention. Evaluation is where many of those concerns become concrete and testable.

Passing a pre-release test is not enough. Model versions, data sources, prompts, tools and user behaviour change. Evaluations need to run again when important components change and continue in production through sampled review and operational metrics.

Make the system observable

Teams need to reconstruct what happened.

For an agentic workflow, that means logging the relevant sequence: user request, context used, model and workflow version, tools considered, tool selected, parameters, approval, result, error and final outcome. Sensitive data still needs appropriate handling; observability is not a licence to copy everything into an unrestricted log.

Operational monitoring should cover:

  • completion and escalation rates;
  • tool errors and retries;
  • approval rates and human edits;
  • evaluation performance;
  • latency and cost;
  • unusual access patterns;
  • incidents and near misses;
  • user feedback.

The BIS report “Governance of AI adoption in central banks” (29 January 2025) proposes a governance and risk-management framework for institutions handling critical functions and sensitive data. Although a private bank has a different mandate, the design principle travels well: accountability, risk assessment and monitoring must operate throughout the lifecycle.

Version everything that can change behaviour

Agent behaviour depends on more than a base model.

Prompts, instructions, tool descriptions, retrieval logic, model configuration, policies and workflow code all affect outcomes. Those components need controlled versions. A release should identify what changed, which evaluations ran, who approved it and how to roll back.

Vendor management belongs here too. Providers may change capabilities, terms, data handling or availability. The bank needs an inventory of dependencies and a substitution plan proportionate to the service.

The European Commission’s official AI Act framework reinforces a risk-based approach and lifecycle obligations across the European context. International banks should design for traceability and role clarity even where the precise legal classification varies.

Use paved roads to increase speed

Strong governance can accelerate delivery when it is implemented as reusable infrastructure.

An approved model gateway removes repeated procurement and security work. Standard access tiers reduce ambiguity. A tool registry makes permissions visible. Evaluation templates shorten validation. A human-review component gives teams a tested interaction. Logging and incident patterns create consistent operations.

There will still be judgement calls. A novel client-data use case or a high-impact autonomous action deserves deeper review. The point is not to eliminate gates. It is to apply them where material risk justifies them, with the evidence already available.

Governed agentic AI is therefore not control versus speed. Good control design is part of how a bank earns speed.

Three concrete takeaways

  1. Define a bounded job and start with reversible actions before expanding an agent’s authority.
  2. Enforce identity, data and tool permissions at runtime, with meaningful human approval for sensitive actions.
  3. Evaluate and observe the full workflow, version every behavioural component and reuse the resulting controls as platform services.
The views expressed here are personal and do not represent those of my current or previous employers.