---
title: "AI Agent Governance for Banks: A Post-Go-Live Checklist - S-PRO"
url: https://s-pro.io/blog/ai-agent-governance-for-banks
lang: en
description: "AI agent governance for banks after go-live: a control checklist with evidence, owners and FINMA, EU AI Act and Swiss data protection sources."
updated: 2026-11-03T05:30:34+00:00
source: S-PRO (https://s-pro.io)
---

[Back to insights](https://s-pro.io/blog)

Article

# AI Agent Governance for Banks: A Post‑Go‑Live Checklist

Author

[Igor Izraylevych](https://s-pro.io/author/sproadmin)

CEO and Co-founder of S-PRO

Published

November 3, 2026

Time to read

14 min

Table of content

- Key Takeaways
- Table of Contents
- Why an agent needs more governance than an assistant
- The control checklist
- Responsibilities and independent review
- Monitoring and drift
- Documentation and fallback
- Logs, change control and incidents
- Data, access and client rights
- Third parties, hosting and exit
- Human oversight and authority limits
- Where the EU AI Act adds to the baseline
- A review rhythm that holds up
- What we think matters most
- Build governed agents with an engineering partner
- FAQ
- How S-PRO helps banks and financial institutions
- Sources

Share

No AI-specific law exists in Switzerland, a point the [law-firm commentary on FINMA Guidance 08/2024](https://www.mll-news.com/finma-guidance-08-2024-governance-and-risk-management-when-using-artificial-intelligence/?lang=en) makes explicitly: existing governance and risk rules apply to AI. FINMA states expectations instead of writing a new rulebook, so governance of an AI agent comes down to six things you can show on request: owners, oversight, logs, change control, incident handling and third-party control. This article gives you a checklist for the operating model after go-live, with the evidence an auditor will ask for and the role that should own each control.

S-PRO

Govern Bank AI Beyond Go-Live

S-PRO builds AI agents for banks with EU AI Act, FINMA and DORA requirements in mind, supporting governance from design through production.

[Explore S-PRO’s banking AI](https://s-pro.io)

## Key Takeaways

- FINMA expects AI risks to be handled inside the existing governance, risk and internal control framework, so the work is assigning owners and producing evidence, not waiting for a new law.
- An agent acts, which raises the bar compared with an assistant: permissions, authority limits and escalation paths need to be written down per use case.
- Each control in the checklist below has an evidence artifact and an accountable role. If you cannot name both, the control does not exist yet.
- Outsourcing, subcontractor changes and exit options are governance topics, not only procurement topics.
- For high-risk systems under the EU AI Act, risk management, human oversight and deployer duties add to this baseline.

## Table of Contents

- The control checklist
- Monitoring and drift
- Documentation and fallback
- Logs, change control and incidents
- Data, access and client rights
- Third parties, hosting and exit
- Human oversight and authority limits
- A review rhythm that holds up
- FAQ
- Sources

## Why an agent needs more governance than an assistant

The Swiss Bankers Association [describes an AI agent](https://www.swissbanking.ch/_Resources/Persistent/2/0/3/b/203b937e175f25819ea271c883a095fe1dfa1ee0/SBA_Generative-AI-in-Banking_EN.pdf) as a system that pursues a defined objective by reasoning, planning, selecting tools and carrying out a sequence of actions within set parameters. An assistant mostly reacts to a request with information. An agent may access banking systems, adapt its plan and execute authorized actions, such as updating account data, with limited human intervention.

That difference changes what you have to govern. For an assistant, the main question is the quality of an answer. For an agent, the questions are which systems it can reach, what it may do without a person, what happens when it is wrong and who can stop it.

The same SBA paper lists the risks that matter for client advisory, onboarding, KYC, reporting and operations: incorrect or hallucinated outputs, bias, weak robustness and explainability, prompt injection, data leakage, poor data quality, dependency on third parties and cloud providers, and unclear accountability when an autonomous action causes harm. It also points to stronger controls where outputs touch clients, AML and KYC, fraud prevention or legally consequential decisions.

## The control checklist

The table maps each control to the evidence you should be able to produce, the role that should own it, and the source. Where no regulatory source exists, the row says so and reflects S-PRO working practice. Paragraph references are to FINMA Guidance 08/2024 (“s.”) and FINMA circulars (“Rz”). The [Gilliéron Avocat operational guide](https://www.gillieronavocat.ch/en/2025/05/17/ai-governance-in-swiss-banks-an-operational-guide-to-implementing-finma-communication-08-2024/) walks through the Guidance in more detail.

| Control | Evidence | Owner | Source |
| --- | --- | --- | --- |
| Responsibilities and independent review | Named accountable owner per agent; written scope of authority; review reports from staff independent of the build team | Business line head (accountable); second line risk or compliance (review) | FINMA Guidance 08/2024, s.2.1, 2.7 |
| Monitoring and drift | Defined quality metrics and thresholds; dashboards; records of breaches and actions taken | Agent owner; model risk function | FINMA Guidance 08/2024, s.2.4 |
| Documentation and fallback | Current description of purpose, data, tools and limits; tested manual fallback procedure | Agent owner; operations | FINMA Guidance 08/2024, s.2.5 |
| Logs, change and incidents | Action logs that reconstruct what the agent did and why; change tickets with approval; incident register with lifecycle records | Head of IT operations; operational risk | FINMA Circular 2023/1, Rz 50-52, 65, 68 |
| Outsourcing and exit | Provider due diligence file; contract with subcontractor notice and audit rights; tested exit plan | Procurement; CIO; operational risk | FINMA Circular 2018/3, Rz 18.1, 20-26, 33; FSB SP 9, 10, 12 |
| Agent inventory and tool permissions | Register of all agents with the systems, tools and data each can reach; access reviews | CISO; agent owner | S-PRO working practice |
| Authority limits and escalation | Per-use-case limits (for example monetary thresholds), confidence thresholds, named escalation contacts | Business line head; compliance | S-PRO working practice |
| Stop and rollback | A documented way to suspend one agent without stopping the process; evidence of a drill | COO; IT operations | S-PRO working practice |
| Pre-production testing and re-validation | Test plans covering robustness, accuracy and bias; re-validation after material changes | Model risk; agent owner | S-PRO working practice |

The sections below explain how to run each row once the agent is live.

## Responsibilities and independent review

Start with one name per agent. Not a committee, not a project team: one accountable person in the business line that uses the agent. The SBA suggests a decentralized model in which business divisions stay accountable for the agents they use, supported by a central center of expertise. That fits most Swiss banks, because it keeps accountability next to the process while the standards stay in one place.

Independent review means someone who did not build or operate the agent examines it. In practice that is the second line, internal audit, or a qualified external reviewer. Give the reviewer the documentation, the logs and the test results, and agree in advance what a failed review triggers: a restriction of permissions, a pause, or a remediation plan with a date.

Write the scope of authority in plain language. “The agent may draft a KYC file summary and propose a risk rating; a named analyst approves.” That sentence is easier to audit than a policy paragraph.

## Monitoring and drift

Performance after go-live is not the performance you measured in the pilot. Inputs change, client behavior changes, upstream systems change, and the underlying model may be updated by the provider. Monitoring should tell you when output quality moves before a client or a regulator does.

A workable minimum:

- A small set of quality metrics per agent, such as the share of outputs corrected by a human, the share escalated, and error rates on a sampled review set.
- Thresholds with a defined response: investigate, restrict, or suspend.
- A regular sample review by a person who did not generate the output.
- Re-validation after material model or prompt changes. Independent pre-deployment testing for robustness, accuracy and bias, with re-validation after material updates, is a recurring recommendation in [Swiss practitioner guidance](https://www.legal500.com/intelligence/switzerland/technology/control-responsibility-and-governance-of-autonomous-ai-agents-in-swiss-fintech).

FINMA also looked at whether AI applications were explainable enough for results to be understood, explained or reproduced and critically assessed, as the [Gilliéron Avocat guide](https://www.gillieronavocat.ch/en/2025/05/17/ai-governance-in-swiss-banks-an-operational-guide-to-implementing-finma-communication-08-2024/) reports. For an agent, the practical test is whether you can replay a decision from its logs and explain it to a client or a supervisor.

## Documentation and fallback

Documentation is what lets a successor, an auditor or a supervisor understand the agent without asking its builders. Keep it short and current: the objective, the data it reads, the tools it can call, its limits, its known failure modes, and who approved the last change.

Fallback is the part banks skip. If the agent is suspended on a Monday morning, the process still has to run. Write the manual procedure, assign the staff, and test it. A fallback that has never been exercised is an assumption.

## Logs, change control and incidents

FINMA Circular 2023/1 on operational risks and resilience sets expectations for change management, separated test and production environments, and the handling of significant ICT incidents. The [SwissBanking Cloud Guidelines (2025)](https://www.swissbanking.ch/_Resources/Persistent/c/3/7/8/c378dbe9e1dafa45f4e4f8783cacddf7436cd1e6/Cloud%20Guidelines%20%282025%29.pdf) summarize the same expectations for banks using cloud providers. Apply them to agents directly.

**Logs.** Record, for every action: the input, the plan or reasoning summary, each tool call with its parameters, the result, the human approval if any, and the version of the agent configuration. Store them where the agent itself cannot alter them.

**Change.** Treat a prompt, a tool definition, a permission and a model version as changes. Each gets a ticket, an approver who is not the author, a test in a non-production environment and a rollback path.

**Incidents.** Decide in advance what counts as an agent incident: a wrong action on a client account, a data exposure, a prompt injection that succeeded, a silent quality drop. Define who is notified, who can suspend the agent, and how the incident is recorded through to closure and lessons learned.

If your agents are moving from pilot to live operation, align these controls with your pilot-to-production checks before launch so the evidence exists from day one rather than being reconstructed later.

## Data, access and client rights

The SBA guidelines stress robust data governance and identity and access management so that unauthorized agents cannot reach sensitive data. Give every agent its own identity, grant the minimum permissions per task, and review them on a schedule. An agent that inherits a human user’s broad access is the most common design shortcut to avoid.

The Swiss Federal Act on Data Protection adds duties of its own. According to the [text on Fedlex](https://www.fedlex.admin.ch/eli/cc/2022/491/en), controllers and processors must ensure risk-appropriate data security, and controllers must carry out a data protection impact assessment beforehand when processing is likely to pose a high risk. Article 21 requires notice of a decision based exclusively on automated processing that has legal consequences or considerable adverse effects, and the person concerned may state a point of view and ask for review by a natural person, subject to specified exceptions. If an agent can decide, not just suggest, build that review route into the process.

## Third parties, hosting and exit

Most agents depend on a model provider, a cloud platform or both. The SwissBanking Cloud Guidelines say banks should know and control where client data are processed, obtain disclosure of provider and subcontractor data flows, define and monitor access, receive advance notice of significant subcontractor changes, and preserve export and exit options. FINMA’s outsourcing circular 2018/3 sits behind the same points.

For agents, add three questions to the usual due diligence:

1. Can the provider change the model version without telling you? If so, how will you detect the change?
2. Where are prompts, tool outputs and logs stored, and who at the provider can read them?
3. If you leave, can you take your configurations, evaluation sets and logs with you, and can another model be substituted without redesigning the process?

The exit plan should be tested on paper at least, with named owners and a realistic time frame set by your own risk assessment.

## Human oversight and authority limits

Effective oversight depends on explicit authority limits per use case, such as monetary thresholds, and clear escalation for anomalies or low-confidence outputs, as [Swiss practitioner guidance](https://www.legal500.com/intelligence/switzerland/technology/control-responsibility-and-governance-of-autonomous-ai-agents-in-swiss-fintech) puts it. The SBA adds that production should keep monitoring, guardrails, human review and escalation for high-stakes or adverse outcomes, with periodic reassessment and an appeal route for affected clients.

Two design choices make oversight real rather than ceremonial:

- **Reviewers who can disagree.** A reviewer who sees hundreds of items an hour and approves nearly all of them is not exercising oversight. Size queues so that review is meaningful, and track how often reviewers change the agent’s proposal.
- **Escalation that is cheap.** The agent should be able to stop and hand over with the context attached. Reward that behavior in design, not penalize it.

## Where the EU AI Act adds to the baseline

A Swiss bank is not automatically in scope of the EU AI Act, but those serving EU clients or operating EU entities should check it. For high-risk systems, [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) adds three obligations that overlap with the controls above. Article 9 calls for a risk management system maintained across the life of the system. Article 14 requires that the system be designed so that natural persons can effectively oversee it. Article 26 sets duties for the organizations deploying such a system, including using it according to its instructions, assigning competent human oversight, monitoring its operation and keeping the logs it generates.

Whether a given agent is high-risk is a question for the use case: check Annex III against the use case rather than assuming. Our separate guide on EU AI Act timing and classification for agents covers it in detail, so it is not repeated here.

## A review rhythm that holds up

Controls decay unless someone looks at them on a calendar. A simple rhythm:

- **Continuous:** automated monitoring, alerting and log retention.
- **Monthly:** the agent owner reviews metrics, incidents, overrides and pending changes.
- **Quarterly:** second line samples outputs, checks permissions against the inventory and reviews provider notices.
- **Annually, or on material change:** independent review, fallback and exit drill, and a refresh of the documentation and impact assessment.

Every review should end with a dated record: what was examined, what was found, who owns each action. That record is the evidence column of the table above in its most useful form.

> ## What we think matters most
>
>
>
> Banks that govern agents well treat them as production systems with accountable owners, not as experiments that happened to survive. We design for that from the start: the logs, the permissions, the escalation path and the fallback are part of the build, not a documentation exercise afterwards.
>
>
>
> We also argue for keeping governance close to the process. The people who run onboarding, advisory or reporting know where an agent can go wrong, and they should hold the pen on authority limits, supported by risk and compliance who review independently.
>
>
>
> Finally, a governed agent is easier to scale. Once the control pattern exists for the first agent, the second and third reuse it, and the supervisory conversation gets shorter.
>
>
>
> *The S-PRO team*

## Build governed agents with an engineering partner

If your bank is designing or operating agents, our work on AI agents for banks covers building them with owners, permissions, logs and human escalation in place from the first release.

Bring one use case, such as KYC file preparation or relationship manager preparation, and we can walk through which controls from this checklist apply and what evidence each would produce.

## FAQ

### Does FINMA require a specific AI governance framework for banks?

No AI-specific Swiss law exists. FINMA Guidance 08/2024 states supervisory expectations, and it expects AI risks to be managed within the existing governance, risk management and internal control system. The practical result is that you document owners, oversight, monitoring, logs, change, incident handling and third-party control for each AI application.

### Who should own an AI agent in a bank?

One named person in the business line that uses the agent should be accountable for it. The Swiss Bankers Association describes a decentralized model with business divisions accountable and a central center of expertise supporting them. Independent review sits with a function that did not build or run the agent.

### How is governing an agent different from governing a chatbot?

An agent can select tools and execute actions in banking systems, so you must govern permissions, authority limits, action logs and stop mechanisms in addition to output quality. A chatbot mostly generates information in response to a request. The more an agent can do without a person, the more precise the limits and escalation rules need to be.

### What should we log for an AI agent?

Log the input, the plan or reasoning summary, every tool call with its parameters and result, any human approval, and the configuration version. Keep the logs tamper-resistant and retained for as long as your record-keeping policy requires. The test is whether a reviewer can reconstruct and explain a past action from the logs alone.

## How S-PRO helps banks and financial institutions

S-PRO is a Swiss international firm founded in 2014, headquartered in Zurich at Löwenstrasse 45, with 250+ engineers. We build AI agents for banks and financial institutions on our own agentic platform, S-PRO Agents, and run them as a service, with the governance controls above designed into the solution. Solutions are designed with EU AI Act, FINMA and DORA requirements in mind. Start with the use case, and we will work through owners, evidence and escalation with your CIO, COO and compliance teams.

*Last updated: 1 November 2026*

## Sources

- [FINMA Guidance 08/2024: governance and risk management when using AI (MLL News Portal)](https://www.mll-news.com/finma-guidance-08-2024-governance-and-risk-management-when-using-artificial-intelligence/?lang=en)
- [AI governance in Swiss banks: an operational guide to FINMA Communication 08/2024 (Gilliéron Avocat)](https://www.gillieronavocat.ch/en/2025/05/17/ai-governance-in-swiss-banks-an-operational-guide-to-implementing-finma-communication-08-2024/)
- [Generative AI in Banking (Swiss Bankers Association)](https://www.swissbanking.ch/_Resources/Persistent/2/0/3/b/203b937e175f25819ea271c883a095fe1dfa1ee0/SBA_Generative-AI-in-Banking_EN.pdf)
- [Cloud Guidelines 2025 (SwissBanking)](https://www.swissbanking.ch/_Resources/Persistent/c/3/7/8/c378dbe9e1dafa45f4e4f8783cacddf7436cd1e6/Cloud%20Guidelines%20%282025%29.pdf)
- [Federal Act on Data Protection, SR 235.1 (Fedlex)](https://www.fedlex.admin.ch/eli/cc/2022/491/en)
- [Control, Responsibility and Governance of Autonomous AI Agents in Swiss Fintech (Legal 500)](https://www.legal500.com/intelligence/switzerland/technology/control-responsibility-and-governance-of-autonomous-ai-agents-in-swiss-fintech)
- [Regulation (EU) 2024/1689 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)

Subscribe

Get technical insights, and industry news

Thank you!

Get ready! You will receive handpicked content right to your inbox.

---

Talk to an engineer who builds AI agents for banks.

ISO 27001 and ISO 27701 certified. S-PRO is a Certified partner in the Claude Partner Network. Zurich, since 2014, 250+ engineers. Clients include AMINA Bank and Earlybird.

[Book a discovery call (45 min)](https://s-pro1.pipedrive.com/scheduler/9AOA0Ix/s-pro-introductory-meeting)[or send a message](https://s-pro.io/get-in-touch)

Link copied to clipboard

[Get in touch](https://s-pro.io/get-in-touch)
