Is AI-generated code allowed in a bank? A traceability answer.

Somewhere in Switzerland this week, an engineering lead will be asked the question in a risk committee: “Are we actually allowed to put AI-generated code into production?” It sounds like a yes/no question. It isn't — and treating it as one is where most internal AI policies go wrong.

Here is the answer that holds up in front of FINMA, an external auditor, and your own board:

AI-generated code is not allowed or forbidden as a category. What is allowed is code whose origin, review, and approval you can prove — line by line, merge by merge.

The question is not permission. It is provability.

What Swiss regulation actually says

Switzerland has no AI-specific law for banks, and that is precisely the point. In December 2024, FINMA published Guidance 08/2024 on governance and risk management when using artificial intelligence. Its core message is that the existing, technology-neutral, principle-based regulatory requirements apply to AI just as they apply to everything else. In practice, FINMA expects supervised institutions to:

• maintain an inventory of AI applications and classify their risks;
• define clear responsibilities, down to named roles;
• ensure data quality;
• test and monitor continuously;
• document processes and be able to explain results;
• subject critical systems to independent review.

Notably, FINMA also observed that most financial institutions are still in the early stages of building these governance structures — which means the gap between “we use AI tools” and “we can govern AI tools” is, right now, one of the clearest maturity signals a supervisor sees.

Two further layers matter for Swiss institutions:

• The EU AI Act (Regulation 2024/1689) — relevant for Swiss banks with EU exposure. Client relationships, subsidiaries, or outsourced functions in the EU pull its compliance requirements across the border.
• The revised Swiss Data Protection Act (revFADP) — governs what may leave your perimeter when a coding assistant sends context to a model. Source code often contains personal data, credentials, or business logic you have contractually promised to protect.

None of this bans AI-assisted development. Swiss banking has in fact adopted it broadly, with staged rollouts across the industry: Raiffeisen introduced Copilot Chat in early 2024 as a deliberate first step before more deeply integrated tooling, and Pictet operates an internal LLM-based assistant over proprietary knowledge bases. UBS has rolled out Microsoft 365 Copilot to employees globally alongside its in-house assistant and reports over 300 live AI use cases — while publicly emphasizing that governance, explainability, and controlled deployment are the central pillars of its AI strategy, not an afterthought.

The industry signal is unambiguous: adoption is mainstream; governance is the differentiator.

The question your auditor will actually ask

When AI touches your SDLC, the audit conversation stops being “do you use AI tools?” and becomes a chain of five provability questions:

1. Inventory. Which AI tools, in which versions, are in scope of your delivery pipeline — including the ones a team adopted informally?
2. Attribution. For any given change in production, can you show which parts were AI-suggested and which a human authored or accepted? A commit trail that says “the AI wrote it” with no named human accountable fails this test.
3. Gates. Where exactly does a human review sit between AI output and anything that matters — and can you prove the gate was exercised, not just configured? Branch-protection screenshots are policy; approval records with reviewer identity, timestamp, and basis of decision are evidence.
4. Data path. What left your perimeter into a third-party model, where was it processed and retained, and is training on your data contractually and technically excluded — verified, not assumed from marketing copy?
5. Reproducibility. If a production incident traces back to an AI-assisted change from four months ago, can you reconstruct the review that approved it?

If you can answer these five, “is it allowed?” answers itself.

Three kinds of Swiss banks, three different centers of gravity

The provability chain is the same everywhere. Where it strains differs by institution type.

The international bank (UBS-scale). The challenge is breadth and jurisdiction. A global institution runs its own platform engineering, so the gates can — and must — be built into internal pipelines at scale: machine-readable AI-attribution on commits, enforced review tiers, centralized tool inventory spanning thousands of engineers. The cross-border layer adds weight: EU entities bring DORA and the EU AI Act into direct scope, so the same change may need to satisfy FINMA's principle-based expectations and the EU's prescriptive ones. Concentration risk is a supervisory theme of its own — when one model vendor sits under most of your assistants, FINMA's warnings about growing third-party dependencies apply to your SDLC, not just your customer-facing AI. And any bank digesting a merger knows the additional truth: two inherited toolchains mean two evidence models to reconcile before either can be defended.

The Kantonalbank. Here the question mutates, because much of the code isn't written in-house. With core banking typically operated on platforms like Avaloq or Finnova and significant development outsourced, the AI-code question becomes a vendor-governance question: does your core provider or engineering partner use AI in development, under which controls, and can they hand you the evidence your auditor will ask you for? FINMA's outsourcing rules make the institution accountable for what its providers do — “our vendor uses AI, ask them” is not an answer a supervised bank gets to give. Add the cantonal dimension: with public ownership and, in most cases, a state guarantee, the reputational tolerance for an AI-related incident is lower than the balance-sheet impact would suggest. The practical move: put AI-development disclosure, attribution evidence, and training-exclusion clauses into vendor contracts now, before the first audit asks for them.

The private bank. The center of gravity is confidentiality. Client data protection isn't a compliance requirement here — it is the product. That pushes two topics to the top: data residency and prompt retention (what exactly does the coding assistant transmit, where is it processed, what is cached, and does any of it touch systems holding client-identifying data?) and bespoke-system risk (decades-old portfolio and CRM systems, often thinly documented, where AI-assisted changes are tempting precisely because institutional knowledge is scarce — and where an unreviewed AI change is hardest to catch). With smaller internal IT, private banks often deliver through engineering partners, which means the evidence chain must arrive with the partner: a delivery team that cannot show commit-level attribution and gate records imports audit risk along with velocity.

The traceability answer, in one paragraph

Allowed is what you can prove. Concretely, that means five artifacts an examiner can hold: a versioned inventory of AI tools in the SDLC; commit-level attribution distinguishing AI-suggested from human-authored change; human-gate records with named reviewers and timestamps; vendor agreements with verified training exclusion and defined retention; and a reproducible trail from any production line back to the review that approved it. Institutions that have these don't ask whether AI-generated code is allowed. They ship it — faster than the ones still debating the question, and with an audit file that closes the discussion before it starts.