What has to be true before a bank moves an AI agent from pilot to production? Six gates

Why use gates instead of a regulatory checklist?

This article is written for risk, compliance and technology leaders at banks and wealth managers in Switzerland, Germany and the US. For each gate it sets out what the sources expect, what evidence a second line of defence will ask for, and a short checklist. It is not legal advice.

Pilots usually pass on demonstrations. Production reviews fail on evidence: a register entry nobody wrote, a data flow nobody drew, a test that was not re-run when the model changed. The Financial Stability Board's final report "Sound practices for responsible adoption of artificial intelligence" (15 October 2026) is the newest cross-jurisdiction reference, and it frames its 12 practices as ones financial institutions are "encouraged to consider"; they are "non-prescriptive and do not constitute a binding international standard" (FSB final report, p. 2). FINMA Guidance 08/2024, BaFin's ICT-risk guidance on AI (23 January 2026), the Federal Reserve's SR 26-2 and the EU's AI Act and DORA add national and legal detail.

Two framing points matter before the gates:

• Most of this is guidance, not hard rules. BaFin states its guidance is non-binding ("non-mandatory advice", and not "a binding interpretation of DORA"). SR 26-2 "does not set forth enforceable standards or prescriptive requirements". Where this article says a source "asks for" or "encourages" something, that is the strength of the wording. DORA and the AI Act are binding law; the sections below say where they apply.
• Gates are ordered along a bank's path: classify, ground the data, prove it works, constrain it, watch it, and plan the exit.

For the stage-by-stage delivery view of the same journey, see AI proof of concept to production for banks. For the FSB's practices in full, see our FSB walkthrough.

Gate 1. Is the agent inventoried and risk-tiered?

What the sources expect. The FSB's practice 5 says: "Financial institutions implement an effective and systematic approach to assess the materiality and risk of AI use cases at the inception stage and thereafter." Practice 3 asks risk management frameworks to "include processes for documentation of AI use, as well as for materiality and risk assessment." (FSB final report, practice 5 p. 31, practice 3 p. 24; page numbers are the printed report pages.)

BaFin (p. 16, non-binding) approaches it through ICT assets: "Information and ICT assets (including components of AI systems) must be identified, classified, documented and continuously monitored. This also applies, for example, to training data sets, model implementations, software libraries, hardware, and internally and externally developed software." BaFin ties this to DORA Article 8(4).

FINMA Guidance 08/2024 (18 December 2024, p. 4) says it assessed whether institutions with many or significant applications have "a centrally managed inventory with a risk classification and resulting measures". It observed that "some supervised institutions defined AI narrowly in order to focus on supposedly larger or new risks" and that it was "a challenge to ensure the completeness of inventories" because, "since the advent of generative AI, applications are accessible to everyone" (p. 4). It also states that "AI is not a high-risk application per se": risk depends on complexity, adaptivity and autonomy, the area of application and integration into processes (footnote 7, p. 5), and it lists non-exhaustive materiality factors such as the number of clients affected and the consequences of errors or failure (footnote 2, p. 3). The criteria for classification "should be defined by the supervised institutions" (footnote 5, p. 4).

On the EU side, tiering is a real question, not a formality. Annex III 5(b) of the AI Act lists "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud". Under Regulation (EU) 2026/1744 (the "Digital Omnibus on AI", of 8 July 2026, OJ L, 24.7.2026), the high-risk obligations apply from 2 December 2027 for systems classified under Article 6(2) and Annex III, and from 2 August 2028 for systems classified under Article 6(1) and Annex I. Most customer-support, AML and KYC agents will not fall under Annex III, but that is a conclusion the tiering step must document, not assume. See EU AI Act and AI agents in banks for the detail.

Evidence a bank needs. One register entry per agent: owner, purpose, model and version, data sources, the tools and permissions it can call, autonomy level, materiality score with criteria, sign-off date, and the trigger for reassessment (new tool, new model version, new data).

Common failure. The pilot ran as a sandbox with no register entry and the tools the agent can call were never listed, so the real blast radius is unknown at go-live.

Checklist

• Agent has a register entry with a named owner.
• Tool and permission list is complete and current.
• Materiality score and the AI Act Annex III question are answered in writing.
• Reassessment triggers are defined.

Gate 2. Do you know what data the agent sees and where it is processed?

What the sources expect. FSB practice 7 (p. 35): "Financial institutions establish appropriate data governance to maintain data that is fit-for-purpose for training, testing and using AI (i.e. accurate, complete, consistent, reliable, secure)."

BaFin (p. 10) observes that "many financial entities adopt risk-based requirements for the use of AI systems, depending on the criticality of the data used and the location of storage and processing." On cloud use (p. 18), "entities are encouraged to perform a risk inventory of the AI application (materiality, data sensitivity, technical requirements)", and it names "the risks of unauthorised data leakage, including to the cloud service provider". On p. 19 it expects the entity to keep an overview of "where (location/region)" processing takes place, citing DORA Article 30(2)(b). FINMA observed that "some supervised institutions have not defined any requirements or controls to ensure data quality for AI applications" and that "data quality is therefore often more important than the selection of the specific model" (Guidance 08/2024, p. 5). It also notes that for purchased solutions institutions "often have no influence on or knowledge of the underlying data" (p. 5).

Evidence a bank needs. A data-flow diagram showing what leaves the bank and to which region; data classification per field; evidence of masking or minimisation; retention rules for prompts and outputs; and the contractual list of processing locations.

Common failure. The pilot used a copy of production data in a developer tenant. Production design is the first time anyone asks where inference runs and whether prompts are retained.

Residency answers depend on the specific provider and deployment option, so rely on the provider's own documentation rather than a generic claim. For the Swiss angle see Claude for Swiss banks: data residency.

Checklist

• Data-flow diagram approved by information security.
• Field-level classification; masking where possible.
• Prompt and output retention defined and agreed with data protection.
• Processing locations listed in the contract.

Gate 3. Can you prove it works, and keeps working after model changes?

What the sources expect. FSB practice 9 (p. 43): "Financial institutions evaluate the performance of AI use cases proportionately to their materiality and risk, including through performance assessments, testing and ongoing monitoring." Practice 8 on explainability (p. 38): "If appropriate and feasible, financial institutions adopt more explainable AI or consider compensating controls."

BaFin is the most concrete (p. 14, non-binding): "Financial entities are required to develop, document and implement tests. The level of testing must be commensurate to the criticality of the business procedures and ICT assets concerned." It adds that "Since generative AI is suitable for general purposes, testing is more difficult than with internally developed software that has been designed for a specific application." On p. 15 it names a risk agent programmes often miss: "Another challenge for testing arises from unannounced model changes where an AI model obtained from third parties is used." Depending on criticality it lists adversarial testing, adversarial penetration testing and "stress-testing the performance of AI systems, e.g. with significantly modified data distributions or in overload scenarios". FINMA's Guidance 08/2024 points the same way (pp. 5-6): it assessed whether institutions schedule tests "which include checks for accuracy, robustness and stability and, if necessary, bias", with performance indicators "defined in advance", and its footnote 9 says that the more essential and complex the application, the more important it is to assess whether it works "before productive use, in the event of changes and ... on an ongoing basis", and to consider fallback mechanisms. On p. 6 it also names monitoring of changes in input data ("data drift") and analysis of cases where users ignored or changed the output. Back to BaFin: on p. 13 changes need "an independent review, documented testing and specifying fall-back procedures", plus "Systematic archiving of all model versions and parameters".

For AML and KYC agents, the EU's AMLA published draft guidelines on ongoing monitoring for consultation on 3 June 2026 (consultation closed 3 September 2026; AMLA says the final guidelines "will be issued in Q4 2026"). The draft says tools should "maintain the expected performance over time, including through appropriate monitoring and, where relevant, the identification of material performance degradation or drift" (para. 95), and that the deployment of such tools "should not, in itself, be considered an indicator of effectiveness" (para. 93). This is a draft and may change.

US note. The Federal Reserve's SR 26-2 (17 April 2026), which replaces SR 11-7, states in footnote 3: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization's risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document." Its principles apply to traditional statistical and non-generative, non-agentic models. A US bank deploying agents therefore reuses the same validation discipline by choice, under general governance, not because SR 26-2 covers agents.

Evidence a bank needs. A golden test set with pass thresholds per task; red-team results; a regression run on every model, prompt or tool change; a documented fall-back; and a named person who signs the release.

Common failure. The pilot is accepted on demo cases and a sample reviewed by the project team; the vendor swaps the model version and nobody re-runs the tests.

Checklist

• Test set with explicit pass thresholds, owned by someone outside the build team.
• Adversarial and stress tests run and documented.
• Automatic re-run on any model, prompt or tool change; model versions pinned and archived.
• Fall-back procedure tested.

Gate 4. Who can stop or override the agent, and what can it do alone?

What the sources expect. FSB practice 10 (p. 49): "Financial institutions implement appropriate and effective human oversight relevant to the materiality, risk, autonomy, complexity and explainability of different AI use cases." Practice 2 (p. 22) asks institutions to "define clear roles and responsibilities, and maintain an appropriate governance framework to enable responsible AI adoption." Note the scaling: oversight is proportionate, not a human on every action.

BaFin (p. 10) expects responsibilities to be "defined within the organisation ... e.g. for the use of AI-generated results in decision-making processes", with ICT risk management, control and internal audit functions involved "depending on the criticality of the AI system, while maintaining independence and avoiding conflicts of interest." FINMA's observations point the same way: it assessed whether governance includes "the definition of responsibilities and accountabilities for the development, implementation, monitoring and use of AI" (p. 4), and it "did not observe a clear distinction between the development of AI applications and the independent review in all cases"; only "a few supervised institutions" carry out an independent review of the entire model development process "by qualified personnel" (p. 7).

AML is the sharpest example. The AMLA draft (paras 78-79, p. 39) would allow auto-closing only for cases that, after automated analysis, "do not indicate suspicious or unusual transactions", not "where there are indicators of heightened risk", and "subject to effective human oversight, including periodic validation through sampling". Draft status again applies. See AI agents for AML transaction monitoring.

The AI Act's human-oversight provision for high-risk systems, Article 14, requires that such systems "can be effectively overseen by natural persons during the period in which they are in use" (Art. 14(1)), with oversight measures "commensurate with the risks, level of autonomy and context of use" (Art. 14(3)), and that overseers can remain aware of "automation bias" (Art. 14(4)(b)). It applies only where the system is in scope, which loops back to Gate 1.

Evidence a bank needs. An autonomy matrix per action type (read, draft, act with approval, act alone); approval thresholds; a named accountable owner; proof that overrides work (a kill switch that has actually been tested); a sampling plan for auto-closed or auto-approved items.

Common failure. "Human in the loop" exists on paper, but the reviewer sees only the agent's summary, so approval is a rubber stamp; or the agent holds write permissions it never needs.

Checklist

• Autonomy level defined for each action; least-privilege permissions.
• Reviewer sees source evidence, not just the agent's conclusion.
• Kill switch and rollback tested.
• Sampling and escalation rules written down.

Gate 5. Can you reconstruct any decision and see drift early?

What the sources expect. FSB practice 9 (p. 43) includes "ongoing monitoring", and practice 3 (p. 24) asks for "documentation of AI use". BaFin (p. 17, non-binding) notes "Continuous monitoring of AI systems has proven useful for the early detection of anomalies (Article 10 of DORA)" and states that "entities are encouraged to ensure comprehensive, risk-based logging of AI decisions, model versions and training data (to the extent permitted by data protection law), depending on the criticality and area of application of the relevant AI systems." On p. 16 it refers to documentation of operating activities such as "log files from model inference processes". AI systems should also feature in business continuity plans tested "at least annually" (p. 17). The AMLA draft again adds drift and "material performance degradation". FINMA's guidance observes that results "often cannot be understood, explained or reproduced and therefore cannot be critically assessed" (p. 6), and expects documentation of purpose, data, performance measures, limitations, testing, controls and fallback solutions for material applications (p. 6).

Note the wording: BaFin says "encouraged", not "required", and logging is bounded by data protection law.

Evidence a bank needs. A per-decision log (input, retrieved sources, tool calls, model and prompt version, output, human action); a retention period agreed with data protection; dashboards for drift and quality with alert thresholds; an incident runbook and a named on-call owner.

Common failure. Logs capture the final answer but not the retrieved context or tool calls, so a disputed decision cannot be replayed; or logs hold personal data with no retention rule.

For audit-trail design in KYC, see KYC AI audit trail and explainability.

Checklist

• One decision can be replayed end to end from logs.
• Retention and access to logs agreed with data protection.
• Drift and quality alerts with thresholds and an owner.
• Incident runbook tested, including model-vendor outage.

Gate 6. What happens if the model vendor changes, fails or leaves?

What the sources expect. FSB practice 12 (p. 60): "Financial institutions appropriately manage risks from third-party AI dependencies with a focus on performance, transparency, data quality, supply chain and concentration risks, and business continuity." Practice 11 (p. 55) adds "incorporating AI cyber and ICT risk scenarios into tests and exercises" where appropriate.

BaFin (p. 19, non-binding, citing DORA) is direct on exit: "Entities are encouraged to ensure that models, training data and configuration scripts can be exported seamlessly to ensure portability to another environment." It warns that "proprietary cloud functions (e.g. specialised AI offerings) can significantly increase the costs, duration and technical expertise required for a change (known as 'vendor lock-in')." It also says audit and control rights "should also apply without exception to subcontracts that support critical or important functions" and expects an overview of the subcontracting chain. Before contracting (p. 18), due diligence should consider changes to the AI system "even if all changes to the model are made by the service provider".

DORA has applied since 17 January 2025 (Article 64). Article 28(3) requires a register of information on all contractual arrangements for ICT services; for ICT services supporting critical or important functions, Article 28(8) requires exit strategies, "comprehensive, documented" and "sufficiently tested and reviewed periodically"; and Article 30(2)(b) requires every ICT services contract to specify the locations (regions or countries) where services are provided and data is processed, including storage, with advance notice of changes. The financial entity must "at all times, remain fully responsible" for compliance (Article 28(1)(a)). These duties sit with the bank and reach a vendor through contract, so the practical question is what a bank asks its AI vendor to provide. FINMA also names "a growing dependence on third parties such as providers of hardware solutions, models or cloud services in an increasingly concentrated market" as a risk (p. 3), and for outsourcing it assessed whether institutions had implemented "additional tests, controls and contractual clauses governing responsibilities and liability issues" (p. 4).

Evidence a bank needs. A register-of-information entry for the model provider and cloud; a subcontractor list; the audit-rights clause; a tested exit plan (a second model or an on-premises fallback, with portable prompts, evals and configurations); and a concentration view across the bank's AI services.

Common failure. Agent logic, prompts and evaluations are written against one vendor's proprietary features, so exit means a rebuild; concentration on one cloud is first discussed at renewal.

Checklist

• Vendor and sub-processors recorded in the register.
• Audit and exit clauses in the contract.
• Prompts, evals and tool definitions kept portable and in the bank's repository.
• Exit or fall-back exercised at least once on a non-production copy.

How do the six gates fit together?

Swipe to compare →

Gates are cumulative: a gap in Gate 1 (an unlisted tool) usually surfaces as a failure in Gates 4 and 5.

How S-PRO helps

S-PRO is a Swiss international firm headquartered in Zurich (Löwenstrasse 45, 8001 Zürich), founded in 2014, with 250+ engineers, R&D centers in Zurich and Łódź, and ISO 27001 and ISO 27701 certifications. S-PRO is a Certified partner in the Claude Partner Network.

We help banks and wealth managers take AI agents from pilot to production: we build the agent so the evidence for each gate (register inputs, test sets, approval flows, decision logs, portable configurations) is produced as part of delivery, not reconstructed afterwards. See AI proof of concept to production for banks and AI agent development, or talk to us about a specific agent you are trying to get through review.

Book a discovery call (45 min)

Sources

• FSB, Sound practices for responsible adoption of artificial intelligence (AI), final report, 15 October 2026: https://www.fsb.org/2026/10/sound-practices-for-responsible-adoption-of-artificial-intelligence-ai-final-report/ (PDF: https://www.fsb.org/uploads/P151026-1.pdf; page numbers in this article are the printed report pages, PDF page = printed + 4)
• BaFin, guidance on ICT risks in the use of AI (23 January 2026): https://www.bafin.de/SharedDocs/Downloads/EN/Anlage/dl_Anlage_orientierungshilfe_IKT_Risiken_bei_KI_en.pdf
• FINMA, press release on Guidance 08/2024 (18 December 2024): https://www.finma.ch/en/news/2024/12/20241218-mm-finma-am-08-24/
• FINMA Guidance 08/2024, "Governance and risk management when using artificial intelligence", 18 December 2024 (PDF, 7 pp.): https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/4dokumentation/finma-aufsichtsmitteilungen/20241218-finma-aufsichtsmitteilung-08-2024.pdf
• Federal Reserve, SR 26-2 (17 April 2026): https://www.federalreserve.gov/supervisionreg/srletters/SR2602.pdf
• EU AI Act, Annex III (AI Act Service Desk): https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3
• DORA, Regulation (EU) 2022/2554: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• EU AI Act, Regulation (EU) 2024/1689, Article 14 and Annex III: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• Regulation (EU) 2026/1744 (Digital Omnibus on AI, amends the AI Act dates), OJ L, 24.7.2026: https://eur-lex.europa.eu/eli/reg/2026/1744/oj
• AMLA, draft Guidelines on ongoing monitoring of a business relationship under Article 26(5) of Regulation (EU) 2024/1624 (consultation 3 June to 3 September 2026): https://www.amla.europa.eu/policy/public-consultations/consultation-draft-guidelines-ongoing-monitoring-business-relationship_en