Does FINMA's AI speech bind you?
A speech adds no duty, but one line from FINMA's Chair gives a Swiss institution a useful question: who owns the purpose, limits, and outcomes of each AI application, the bought-in ones included?
A speech adds no duty, but one line from FINMA's Chair gives a Swiss institution a useful question: who owns the purpose, limits, and outcomes of each AI application, the bought-in ones included?
A speech adds no duty, but one line from FINMA's Chair gives a Swiss institution a useful question: who owns the purpose, limits, and outcomes of each AI application, the bought-in ones included?
In the text FINMA published for the SBA Digital Finance Day, its Chair, Marlene Amstad, writes of "a principle I consider non-negotiable: accountability cannot be delegated to an algorithm." The page is dated 3 November 2026, six days before the event on 9 November, so I quote the published text and not a record of what was said. If you answer for AI risk at a Swiss supervised institution, the question is what a sentence in a speech can bind you to.
My answer is that it binds you to nothing you weren't already bound to, because the three texts in play carry different weight.
FINMA doesn't explain how "expects" sits beside "does not have legal impact." I read the expectation as a statement of how the rules get applied, with the obligation staying in the rules. Which provisions reach your license is a question for counsel.
The speech, then, signals where the Chair's attention sits. Section 3 of the guidance says FINMA "will also refine its expectations" on AI and, where necessary, make them transparent. I wouldn't call a speech that refinement.
The speech never cites Guidance 08/2024; the only guidance it mentions is on digital fraud. Connecting the two is my reading.
Section 2 closes its list of AI risks with "scattered responsibilities for AI applications at supervised institutions." Section 2.1 supplies a cause:
"the development of AI applications is often decentralised, making it challenging to implement consistent standards, assign responsibilities clearly to employees with the appropriate skills and experience and address all relevant risks."
FINMA then looked for "the definition of responsibilities and accountabilities for the development, implementation, monitoring and use of AI."
"Scattered responsibilities" sits in a list of risks and challenges with no count behind it, and the document gives no counts anywhere. It's also a December 2024 record. FINMA's release at the time put most institutions "in the early stages of development," and I can't say how much of that still holds.
The speech's line lands on a gap FINMA had already written down, and it goes further by saying "every" and naming what has to be owned.
The speech is wider than the guidance. It introduces the principle through agentic AI, systems that plan, execute, and chain tasks on their own, and then widens it to every application.
Section 1 also applies proportionality across the board: the institution's size, complexity, structure, and risk profile, the materiality of the applications, and the probability that the risks materialize.
I'd work from both scopes and give them different jobs. Ownership can reach every application, and the depth of documentation and review scales with materiality. An owner for a low-materiality application is closer to the name on a jar in a shared fridge than to a file. It tells you whom to ask.
Naming an owner presupposes a list of applications. Section 2.2 records that "some supervised institutions defined AI narrowly in order to focus on supposedly larger or new risks," then says FINMA "assessed the existence and completeness of AI inventories and the risk classification of AI applications," with no materiality limit on that sentence, though section 2.1 lists a centrally managed inventory among what it assessed at institutions with many or significant applications. An application left out by a narrow definition has no owner to find.
Purpose, limits, and outcomes each match language already in the guidance. The mapping is mine; FINMA doesn't draw it.
| Speech | Guidance language | Where |
|---|---|---|
| Purpose | "the purpose of the application"; "achieves the set goals" | Section 2.5 (material applications only); section 2.4 |
| Limits | "assumptions, limitations" and "fallback solutions"; "potential application limits" | Section 2.5 (material applications only); footnote 8 |
| Outcomes | "the correctness and ongoing quality of the outputs"; cases where "the output has been ignored or changed by users"; "results often cannot be understood, explained or reproduced" | Section 2.4; section 2.6 |
Section 2.5 is limited to material applications and sections 2.4 and 2.6 aren't, so for a minor application I'd expect a short answer on purpose and limits and still want someone looking at what it produces.
Then there's the word someone. The speech says "someone in your organisation"; the guidance says "employees with the appropriate skills and experience." I'd sharpen that to a named owner, which appears in neither text. If the answer to "who owns this?" is a department or a committee, I think responsibility can stay as scattered as the guidance described. A name doesn't show that you meet FINMA's expectations, but "who owns this?" is the first question I'd ask.
The speech names the hardest case directly: "an institution remains responsible for the applications it uses, including those it has bought in."
The numbers around this come from FINMA's 2025 survey of around 400 institutions, as the speech reports them: on average, "the institutions surveyed run around five AI applications and are working on nine more," and "Few develop their applications in-house. Most rely on external providers." It gives no percentage for that last claim, and FINMA's April 2025 release is softer, saying most "do not rely solely on their own developments, but also use external service providers." The release also says around 50% of the institutions surveyed use AI or have applications in development.
Responsibility stays with the institution, while the knowledge can sit with the vendor. The guidance records this:
"In the case of externally purchased applications and services, the supervised institutions sometimes had difficulties determining whether AI is included, which data and methods are used and whether sufficient due diligence exists." (section 2.1)
"In the case of purchased solutions, the supervised institutions often have no influence on or knowledge of the underlying data." (section 2.3)
Section 2.1 adds that "in the case of outsourcing," FINMA assessed whether institutions had "additional tests, controls and contractual clauses governing responsibilities and liability issues." I wouldn't assume every bought-in tool counts as outsourcing in the regulatory sense.
So what can an owner own here? Purpose and limits, because the institution decides what it uses the application for and where it stops. Outcomes too: footnote 9 says the less known about a system or its data, the more important it is to assess whether it works "according to its purpose." The vendor's data may stay out of reach, and what the owner can hold is an honest record of what isn't known.
Neither text says how much vendor knowledge is enough, so I can't tell you where that line sits. If you're the vendor, those are questions your customer may bring to you.
The guidance runs to seven pages, and you don't need all of them to begin. Start at sections 2.1, 2.2, and 2.5. Then take one bought-in application and ask who in your organization owns its purpose, its limits, and its outcomes. Hold the answer against the table, and you'll see which rows have a name and which have a vendor.
devguard has an AI policy template, process templates for AI impact assessments, and an AI risk template set, none of them mapped to FINMA guidance; you choose one owner role when you add the risks, so naming a person for each application stays with you (App 2.6.0 in the changelog).
Angelo runs strategy and the relationships behind devguard. He spends his time with the teams who live with compliance day to day, and keeps what we build tied to what they actually need.
Start free, bring your frameworks, and keep the evidence attached as the work ships. No setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships. No setup friction, no audit-week fire drill.