«Wer On-Prem geht, erbt die gesamte Sicherheitsverantwortung»

Der Assistent ersetzt die klassische Benutzeroberfläche durch natürliche Sprache. Statt durch Menüs zu navigieren, formuliert der Kunde sein Anliegen im Chat: «Zeig mir alle Zahlungen an Galaxus der letzten sechs Monate» oder «Richte einen Dauerauftrag von 100 Franken auf das Konto meines Enkels ein». Der Assistent liefert die Information, schlägt die Aktion vor und führt sie auf Bestätigung aus. Wichtig: Die Bank wählt selbst, welches LLM im Hintergrund läuft. Das kann auch ein Open-Source-Modell sein, das vollständig On-Premises betrieben wird.

Die Einfachheit bei kommerziellen Cloud-LLMs ist nur vermeintlich und der Qualitätsvorsprung auch. Open-Source-Modelle haben die Lücke weitgehend geschlossen und ermöglichen Lösungen, die unabhängig von externen Anbietern und geopolitischen Entwicklungen bleiben. Im Banking kommt ein entscheidender Faktor hinzu: Bankgeheimnis, FINMA-Anforderungen und DSGVO setzen klare Grenzen. Sensible Kundendaten dürfen die eigene Infrastruktur schlicht nicht verlassen. Bei Cloud-LLMs gibt man unweigerlich einen Teil der Kontrollhoheit ab. On-Premises bedeutet dagegen: Die Bank kontrolliert Modell, Logs und Datenfluss vollständig. Der Preis dafür ist, dass man auch die gesamte Sicherheitsverantwortung selbst übernimmt. Aber gerade im Banking ist das keine Schwäche, denn es ist die Voraussetzung für Vertrauen.

Bei Cloud-Anbietern wie OpenAI oder Anthropic sind Sicherheitsmechanismen wie Missbrauchserkennung, Content-Filter, Safety-Training eingebaut. On-Prem fällt das alles weg. Die Bank muss diese Schutzschicht selbst bauen. Wer das unterschätzt, baut ein leistungsfähiges System ohne Sicherheitsnetz.
 

Der Name ist bewusst gewählt: Wie eine gegrillte Zwiebel hat das System viele Schichten, die Hitze absorbieren, bevor sie den Kern erreicht. Konkret bedeutet das: Jede Anfrage durchläuft mehrere Kontrollstufen, von der Netzwerksicherheit über das Application Gateway bis zu dedizierten Input- und Output-Guardrails. Kein einzelner Filter fängt alles ab. Aber mehrere Schichten zusammen machen das System robust. Ein menschliches Eskalationssystem bildet die letzte Schicht.

Auf der Eingangsseite filtern sie, was das Modell überhaupt sieht: Jailbreak-Versuche, Off-Topic-Anfragen, versteckte Instruktionen in Nutzereingaben. Auf der Ausgangsseite prüfen sie, was der Nutzer zu sehen bekommt: Profanitätserkennung, PII-Maskierung, Compliance-Checks. Dazwischen kontrollieren Policy-Guardrails, welche Backend-Systeme der Assistent überhaupt aufrufen darf. Das LLM bekommt nur Zugriff auf das, was es für den jeweiligen Kontext braucht.

Weil LLMs von Grund auf darauf ausgelegt sind, Instruktionen in Text zu folgen. Genau das macht sie angreifbar. Ein Angreifer muss keine Schwachstelle im Code finden. Er muss nur eine Instruktion in Daten verstecken, die das Modell verarbeitet. Das ist strukturell. Zwei Beispiele aus 2025 zeigen das gut: Bei «EchoLeak» wurde Microsoft 365 Copilot über eine präparierte E-Mail dazu gebracht, sensitive Daten zu exfiltrieren, ohne dass der Nutzer etwas getan hat. Bei «ForcedLeak» genügte ein manipuliertes Webformular, um Salesforce Agentforce dazu zu bringen, CRM-Daten preiszugeben. Beide Angriffe nutzten indirekte Prompt Injection, also versteckte Instruktionen in Daten, nicht in der Nutzereingabe. Das ist deutlich schwerer abzufangen.

Nein, das muss man offen sagen. Prompt Injection ist das am wenigsten gelöste Problem in der LLM-Sicherheit. Guardrails reduzieren das Risiko erheblich, aber sie sind kein vollständiger Schutz. Deshalb ist der mehrschichtige Ansatz so wichtig: Wenn eine Schicht versagt, fangen andere auf. Und deshalb gehört Human-in-the-Loop bei kritischen Aktionen dazu: ein Mensch, der eingreifen kann, bevor etwas Irreversibles passiert.

Sicherheit muss von Anfang an mitgedacht werden, nicht nachträglich aufgesetzt. Das klingt banal, ist in der Praxis aber selten. Konkret: Datenflüsse dokumentieren, Vertrauensgrenzen definieren, Threat Modeling machen, bevor die erste Zeile produktiver Code geschrieben wird. Und Red Teaming einplanen: Wer sein System nicht selbst angreift, findet die Schwachstellen erst, wenn es jemand anderes tut.