Architektur-Referenz | STOP.LI

STOP.LI · AI Security · Technik und Betrieb

ArchitekturLLM-Anwendungen sicher aufbauen.

Eine sichere KI-Anwendung entsteht durch Kontrollen um das Modell, nicht im Modell. Diese Seite zeigt die Bausteine einer LLM-Anwendung, ihre Vertrauensgrenzen, die vier Kontrollpunkte Eingang, Kontext, Ausgang und Tool-Aufruf sowie Vorgaben für Hosting, Identitäten, Isolation und Secrets.

Rechtsstand: 11. Oktober 2026. Die Referenzarchitektur ist eine eigene Einordnung auf Basis frei zugänglicher Leitlinien. Art. 15 AI Act ist EU-Recht und betrifft Hochrisiko-KI-Systeme.

ISMS-Prozess: 04 Architektur · 12 IAM · 13 Kryptografie · 14 Entwicklung
Ausgangslage

Kontrollen
um das Modell.

Ein Sprachmodell verarbeitet Anweisungen und Daten im selben Eingabestrom. Die Architektur darf sich deshalb nicht darauf verlassen, dass das Modell Anweisungen sauber von Daten trennt. Sicherheit entsteht an den Stellen, an denen Daten in das Modell hinein und Aktionen aus dem Modell heraus fliessen. Dort liegen die Kontrollpunkte.

Die Seite beschreibt eine generische Anwendung mit Chat- oder Assistenzfunktion. Agenten mit eigenem Handlungsspielraum behandelt Agenten und MCP. Die zugehörigen Angriffe stehen in der Bedrohungslandschaft.

Grundlage

Die NCSC/CISA-Leitlinien für die sichere Entwicklung von KI-Systemen (Version 1.0, 27.11.2023) gliedern den Lebenszyklus in Design, Entwicklung, Bereitstellung sowie Betrieb und Wartung. Im Abschnitt Secure Design empfehlen sie, Bedrohungen zu modellieren und KI-Komponenten, die Aktionen auslösen, angemessen einzuschränken. Dieser Aufbau dient hier als Ordnungsrahmen. Die Leitlinien sind eine Empfehlung, kein Gesetz.

Bausteine

Sieben Bausteine,
ein Datenpfad.

Baustein Aufgabe Sicherheitsrelevanz
Client Web-App, Mobile-App, Integration in Fachanwendung. Authentifizierung der Nutzer, keine Secrets im Client, Eingaben gelten als nicht vertrauenswürdig.
Gateway Einziger Zugang zur KI-Funktion: Authentifizierung, Mengenbegrenzung, Prüfung von Ein- und Ausgabe. Zentraler Durchsetzungspunkt, schützt die Programmierschnittstelle (API) vor Missbrauch und Kostenexplosion.
Orchestrierung Baut Anfrage und Kontext auf, steuert Abläufe, ruft Modell und Werkzeuge auf. Hält Systemprompt, Konfiguration und Zugangsdaten. Hier entscheidet sich, welche Daten das Modell sieht.
Modell Erzeugt Ausgaben aus Eingaben und Kontext. Extern über API, verwaltet beim Cloud-Anbieter oder selbst betrieben. Modelldateien gelten als Fremdcode, solange ihre Herkunft nicht geprüft ist.
Wissensbasis (RAG, Vektordatenbank) Liefert geprüfte Inhalte als Kontext (Retrieval-Augmented Generation, RAG). Zugriffsrechte der Quelle müssen beim Abruf gelten, Inhalte sind ein Einfallstor für indirekte Prompt Injection.
Werkzeuge (Tools) Schnittstellen, über die das System Aktionen ausführt oder Daten ändert. Jede Aktion ist ein Rechtekontext. Minimale Rechte, Freigabe bei schreibenden Aktionen.
Protokollierung Hält Anfragen, Entscheide und Aktionen nachvollziehbar fest. Protokolle enthalten Prompts und Antworten und sind selbst schützenswert (Aufbewahrung, Zugriff).
Vertrauensgrenzen

Wo Daten
die Zone wechseln.

Eine Vertrauensgrenze liegt dort, wo Daten oder Aufrufe zwischen Zonen mit unterschiedlichem Schutzbedarf wechseln. Jede Grenze braucht Authentifizierung, Prüfung und Protokollierung. Rechtliche Fragen zu den Datenflüssen (Rechtsgrundlage, Auslandübermittlung, Aufbewahrung) behandelt Datenkontrollen.

Grenze Was sie überquert Mindestkontrolle
1 · Nutzer zu Gateway Anfragen, Dateien, Sitzungsinformation. Starke Authentifizierung, Mengenbegrenzung, Eingabeprüfung.
2 · Orchestrierung zu Modell Prompt, Kontext, ggf. Personendaten und vertrauliche Inhalte. Datenminimierung, Freigabe nur für zugelassene Modelle und Regionen, verschlüsselte Verbindung.
3 · Wissensquelle zu Kontext Dokumentausschnitte, Metadaten. Rechteprüfung beim Abruf, Herkunft der Inhalte, Trennung nach Mandanten und Schutzklassen.
4 · Modell zu Werkzeug Aufrufe mit Parametern, Ergebnisse. Parameter validieren, minimale Rechte, Freigabe bei Schreibzugriff, Abbruchmöglichkeit.
5 · System zu Protokoll Prompts, Antworten, Aktionen. Zugriffsschutz, Maskierung sensibler Inhalte, definierte Aufbewahrung.
Kontrollpunkte

Vier Stellen,
an denen geprüft wird.

1 · Eingang

Authentifizieren, Mengen und Kosten begrenzen, Eingaben auf Format, Länge und bekannte Angriffsmuster prüfen. Die NCSC-Leitlinien sehen vor, Daten und Eingaben zu prüfen und zu bereinigen. Das NCSC-Prinzip 4.2 (Machine Learning Principles, Version 2.0) nennt dies als Betriebsmassnahme.

2 · Kontext

Nur Inhalte in den Kontext laden, die der Nutzer sehen darf. Systemprompt vom Nutzerinhalt trennen. Abgerufene Inhalte als nicht vertrauenswürdig behandeln. Sensible Daten minimieren oder maskieren, bevor sie das Modell erreichen.

3 · Ausgang

Ausgaben vor der Weitergabe prüfen: vertrauliche Inhalte, Schadcode, Verweise auf fremde Adressen. Ausgaben nie ungeprüft in Befehle, Abfragen oder Webseiten einsetzen. Die NCSC-Leitlinien sehen Guardrails für Modellausgaben vor, wo nötig, und Ausgaben ohne unnötige Details.

4 · Tool-Aufruf

Aktionen auf eine Positivliste begrenzen, Parameter validieren, Rechte pro Werkzeug minimieren. Die NCSC-Leitlinien sehen Einschränkungen und Fail-Safes ausserhalb der KI vor. Vertiefung und Freigabeschwellen: Agenten und MCP.

Ein LLM Gateway mit Guardrails bündelt die Kontrollpunkte 1 und 3 an einer Stelle. Es ersetzt die Rechteprüfung in der Orchestrierung (Punkte 2 und 4) nicht.

Hosting-Varianten

Wer trägt
welchen Teil.

Die Wahl der Bereitstellung verschiebt Verantwortung, hebt sie aber nicht auf. Die NCSC-Leitlinien empfehlen, bei externen Modellanbietern deren Sicherheitslage zu prüfen und Daten, die an externe Dienste gehen, besonders zu kontrollieren. Prüfpunkte zu Anbietern: Lieferanten und Modelle.

Variante Beim Betreiber Beim Anbieter Typischer Schwerpunkt
A · Modell über externe API Gateway, Orchestrierung, Wissensbasis, Daten, Zugriffsrechte, Protokolle. Modell, Plattform, Betrieb. Welche Daten verlassen die Organisation? Vertrag, Speicherort, Nutzung für Training.
B · Verwalteter Modelldienst im eigenen Cloud-Konto Konfiguration, Netzwerk, Identitäten, Daten, Anwendung. Betrieb des Modelldienstes. Sichere Voreinstellungen, private Anbindung, Schlüsselverwaltung.
C · Selbst betriebenes Modell Alles inklusive Modelldateien, Laufzeit und Infrastruktur. Allenfalls Herkunft der Modellgewichte. Herkunftsprüfung und Scan von Modelldateien, Patchen, Schutz der Gewichte.

Die Tabelle ist eine eigene Einordnung. Konkrete Verantwortungsteilung steht im Vertrag und in der Dokumentation des Anbieters.

Identitäten

IAM für Nutzer,
Modelle, Dienste.

Drei Arten von Identitäten greifen auf eine KI-Anwendung zu oder handeln in ihrem Namen. Jede braucht eigene Konten und eigene Rechte. Details zur Verwaltung von Dienstkonten: Machine Identity Management.

  • Nutzer: Anmeldung über das zentrale Identitätssystem mit starker Authentifizierung. Abrufe aus der Wissensbasis laufen mit den Rechten des Nutzers, nicht mit einem Sammelkonto.
  • Dienste und Komponenten: je Komponente ein eigenes Dienstkonto mit kurzlebigen Berechtigungen und minimalem Umfang. Die NCSC-Leitlinien sehen Zugriffskontrollen für APIs, Modelle, Daten und Pipelines vor.
  • Modell und Werkzeuge: Das Modell erhält keine eigenen Rechte. Es handelt über Werkzeuge mit klar begrenzten Rechten. Das OWASP AI Exchange nennt dies Least Model Privilege.
Isolation und Secrets

Trennen,
was getrennt bleibt.

Thema Vorgabe Grundlage
Umgebungen Entwicklung, Test und Produktion getrennt. Sensible Code- und Datenbestände in eigenen Umgebungen. NCSC/CISA-Leitlinien, Secure your infrastructure: angemessene Trennung von Umgebungen mit sensiblem Code oder Daten.
Mandanten und Schutzklassen Wissensbasen, Indizes und Protokolle nach Mandant oder Schutzklasse trennen. Zugriffsrechte beim Abruf prüfen, nicht erst in der Anzeige. OWASP AI Exchange, Kontrolle Segregate Data. Umsetzung ist eigene Einordnung.
Secrets Schlüssel und Tokens nur in einer Secrets-Verwaltung, nie im Client, im Prompt oder in Protokollen. Rotation und Entzug vorsehen. Eigene Einordnung. Werkzeug: Secrets Management.
Modelldateien Hashes oder Signaturen von Modelldateien und Datensätzen berechnen und prüfen. Fremde Modelle vor dem Laden scannen und isoliert ausführen. NCSC/CISA-Leitlinien, Secure design und Protect your model continuously.
Modell-Schnittstelle Abfragen begrenzen und auf Muster zur Modellextraktion überwachen. Angaben, die einem Angreifer helfen, auf das Nötige beschränken. NCSC/CISA-Leitlinien, Protect your model continuously (Kontrollen an der Abfrage-Schnittstelle). NCSC Machine Learning Principles 1.3 und 3.1. OWASP AI Exchange (Rate Limit, Monitor Use).
Schnittstellen Authentifizierung, Schema-Prüfung und Mengenbegrenzung für alle Schnittstellen, auch interne. Siehe API Security und WAF. NCSC/CISA-Leitlinien: Kontrollen gegen Angriffe über die API.
Rechtlicher Bezug

Art. 15
AI Act.

Für Hochrisiko-KI-Systeme verlangt Art. 15 Abs. 1 AI Act ein angemessenes Mass an Genauigkeit, Robustheit und Cybersicherheit über den gesamten Lebenszyklus. Abs. 5 verlangt Widerstandsfähigkeit gegen Versuche unbefugter Dritter, Verwendung, Ausgaben oder Leistung durch Ausnutzung von Schwachstellen zu verändern. Die technischen Lösungen umfassen gegebenenfalls Massnahmen gegen Data Poisoning, Model Poisoning, Adversarial Examples, Angriffe auf vertrauliche Daten und Modellmängel.

Das ist EU-Recht. Es betrifft Schweizer Unternehmen nur bei EU-Bezug nach Art. 2 AI Act. Einstufung und Rollen: Regulierung DCH.

Security Baseline

Die frei verfügbare AI Security Baseline V2.0 (12.07.2026) von 4T2 Solutions führt die technischen Anforderungen weiter aus: Kapitel 2 Architekturprinzipien, 3 Plattform und Deployment, 4 Identität und Zugriff, 5 Datensicherheit, 6 RAG und Vektordatenbanken, 7 Modell, Prompt und Ausgabe, 8 Agenten und MCP, 9 API und Secrets. Sie richtet sich an Finanzinstitute und ist branchenübergreifend als Orientierung nutzbar.

Weitere Grundlagen

ETSI EN 304 223 (V2.1.1, 12/2025) fasst Basisanforderungen in 13 Prinzipien über fünf Phasen. Vergleich der Grundlagen: KI-Frameworks im Vergleich. Siehe auch Kontrollkatalog und Lebenszyklus-Kontrollen.

Prüfliste

Vor der
Freigabe klären.

  • Gibt es ein Architekturbild mit allen Bausteinen, Vertrauensgrenzen und Datenflüssen, und ist es Teil der Risikobeurteilung?
  • Läuft jeder Zugriff auf das Modell über das Gateway, und gibt es keinen Umgehungspfad?
  • Gelten beim Abruf aus der Wissensbasis die Rechte des einzelnen Nutzers?
  • Sind Werkzeuge auf eine Positivliste begrenzt, mit minimalen Rechten und Freigabe bei schreibenden Aktionen?
  • Hat jede Komponente ein eigenes Dienstkonto, und liegen alle Secrets in einer Secrets-Verwaltung?
  • Sind Herkunft und Integrität der Modelldateien geprüft, und ist Variante A, B oder C mit Verantwortungsteilung dokumentiert?
  • Werden Prompts, Antworten und Aktionen protokolliert, und ist der Zugriff auf die Protokolle geregelt?
Unterstützung

Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt beim Entwurf einer sicheren Architektur für KI-Anwendungen. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.