“If you opt for on-prem technology, you assume full responsibility for security”

The assistant replaces the traditional user interface with natural language. Instead of navigating through menus, customers can make their request in the chat: “Show me all payments made to Galaxus over the past six months” or “Set up a standing order for 100 Swiss francs to my grandson’s account.” The assistant provides the information, suggests what action to take, and carries this out once it has been confirmed. It is important to note that the bank itself decides which LLM runs in the background. This could be an open-source model that is operated entirely on-premises.

Commercial cloud-based LLMs have a reputation for being simpler and offering better quality. But open-source models have largely caught up, enabling solutions that remain independent from external providers and geopolitical developments. In banking, there is another key factor to consider: Banking secrecy, Swiss Financial Market Supervisory Authority (FINMA) requirements, and the GDPR set clear limits. Sensitive customer data is not allowed to leave the bank’s own infrastructure. With cloud-based LLMs, some control is inevitably lost. An on-premises approach, on the other hand, means that the bank has complete control over the model, logs, and data flow. The compromise is that it also has to assume full responsibility for security. However, this is not necessarily a bad thing especially in banking—it is actually essential for building trust.

Cloud providers such as OpenAI and Anthropic have built-in security mechanisms, including misuse detection, content filters, and safety training. An on-prem solution provides none of this. The bank has to build this layer of protection itself. If they underestimate the need for this, they are essentially building a high-performance system without a safety net.

This name was chosen deliberately: Like a grilled onion, the system has many layers that absorb heat before it reaches the core. Basically, this means that every inquiry goes through several layers of security checks, from network security to the application gateway and right through to dedicated input and output guardrails. No single filter can catch everything. But having multiple layers makes the system robust. The final layer is a human escalation system.

On the input side, they filter what the model actually sees: jailbreak attempts, off-topic inquiries, hidden instructions in user input. On the output side, they check what the user will see: profanity detection, PII masking, compliance checks. In between these, policy guardrails control which backend systems the assistant is actually allowed to access. The LLM only has access to what it needs for the context in question.

Because LLMs are designed from the bottom up to follow instructions in text. That is exactly what makes them vulnerable. Attackers do not need to find a vulnerability in the code. They only have to hide an instruction within the data that the model processes. It’s a structural issue. Two examples from 2025 illustrate this well: In the “EchoLeak” incident, Microsoft 365 Copilot was tricked into exfiltrating sensitive data via a malicious email without the user doing anything. In the “ForcedLeak” incident, a single tampered web form was enough to con Salesforce Agentforce into revealing CRM data. Both attacks used indirect prompt injection, so there were hidden instructions in the data, not in the user’s input. That is much harder to catch.

No, we have to be honest about that. In terms of LLM security, prompt injection is the biggest issue that still needs to be tackled. Guardrails significantly reduce the risk, but do not provide complete protection. A multi-layered approach is so important for the simple reason that if one layer fails, others can take over. And that is why "human-in-the-loop" is essential for critical operations—having someone on hand to intervene before something irreversible happens.

Security has to be built in from the start, not added as an afterthought. That sounds obvious, but it rarely happens in practice. That means you need to document data flows, define trust boundaries, and carry out threat modeling before writing a single line of production code. And organize a red teaming exercise, because if you don’t test your system for vulnerabilities yourself, you won’t discover them until someone else does.