Wer eine LLM-Anwendung absichern will, muss die Architekturfrage früh und ohne Ausweichmanöver klären: Darf das System nur lesen und formulieren, oder darf es schreiben und Aktionen auslösen? Genau an dieser Stelle wird aus einem nützlichen Assistenten ein Sicherheitsproblem. Produktiv tragfähig wird generative KI erst dann, wenn Berechtigungen, Retrieval, Tool-Aufrufe, Freigaben und Protokollierung außerhalb des Modells erzwungen werden.
Für Unternehmen in Polen und der EU ist das keine akademische Debatte. Viele produktive Einsätze entstehen in Shared Services, BPO-nahen Support-Teams, Wissensarbeit und Backoffice-Prozessen. Dort laufen Daten aus mehreren Gesellschaften, Ländern und Rollenmodellen zusammen. Ein sprachlich starkes Modell hilft wenig, wenn Mandantentrennung, Feldrechte und Freigaben erst nachträglich an einen Universalassistenten geschraubt werden.
Die eigentliche Sicherheitsgrenze liegt nicht im Prompt
Ein LLM kann Inhalte klassifizieren, formulieren und strukturieren. Es ist aber keine verlässliche Vertrauensgrenze. Benutzeranfragen, importierte Dokumente, Tool-Beschreibungen und interne Regeln landen im selben semantischen Raum. Genau deshalb behandelt das OWASP Top 10 for LLM Applications Prompt Injection, Datenlecks und überprivilegierte Agenten als typische Fehler produktiver Systeme.
Die verbreitete Idee, Sicherheitslogik in einen besonders guten Systemprompt zu verlagern, hält im Betrieb selten stand. Ein Systemprompt kann Verhalten lenken. Er ersetzt keine belastbare Autorisierung. Sobald eine Anwendung sensible Daten liest, externe Systeme abfragt oder Seiteneffekte auslöst, braucht sie eine serverseitige Kontrollschicht mit festen Regeln, Schema-Validierung und prüfbaren Entscheidungen.
Die meisten ersten produktiven LLM-Setups sollten read-only oder draft-only bleiben. Das ist kein Dogma, sondern ein solides Architektururteil. Wenn Objektberechtigungen noch unklar sind, Ausnahmen häufig auftreten oder mehrere Datenquellen zusammenlaufen, sind frühe Schreibrechte meist kein Zeichen von Reife, sondern von zu viel Vertrauen in die Demo.
Vier Betriebsmodi reichen für die meisten Entscheidungen. Read-only passt für Suche, Zusammenfassung und Wissenszugriff. Draft-only mit Freigabe eignet sich für E-Mail-Entwürfe, Ticketantworten oder Vertragsbausteine. Schreibende Aktionen mit Freigabe gehören in Prozesse mit Kundendaten, Vertragsstatus oder externer Kommunikation. Vollautomatisierung ist nur vertretbar, wenn die Aktion reversibel ist, der Datenraum eng bleibt und Fehlverhalten keinen kritischen Schaden auslöst.
Sobald mehrere Modelle, Datenquellen oder Werkzeuge beteiligt sind, wird eine zentrale Kontrollschicht schnell sinnvoll. Ein Enterprise AI Gateway ist dann keine modische Zusatzebene, sondern der saubere Ort für Routing, Secrets, Richtlinien, Protokollierung und Freigaben. Bei einem isolierten internen Wissensassistenten kann man darauf verzichten. Bei CRM, Ticketsystem, DMS und E-Mail in einer Kette eher nicht.
Prompt Injection begrenzen: Kontext isolieren, Aktionen entkoppeln
Prompt Injection verhindern heißt nicht, dem Modell mehr Warnhinweise zu geben. Es heißt, untrusted content technisch von Steuerlogik zu trennen. Das Risiko steckt in PDFs, E-Mails, Wiki-Seiten, Tickets, Chatverläufen und Dateianhängen. In RAG-Architekturen wird daraus fast automatisch ein Standardproblem, weil fremde Inhalte maschinell in den Kontext gezogen werden.
Die robuste Gegenmaßnahme ist Kontextisolation. Benutzerfrage, Systemregeln, Dokumentauszüge und Tool-Schemata werden getrennt verarbeitet und mit einer Vertrauensstufe versehen. Dokumente dürfen Inhalt liefern, aber keine Berechtigungen verändern und keine Aktionen legitimieren. Wer diese Trennung nicht erzwingt, baut eine Einladung für indirekte Prompt Injection.
Ein häufiger Fehler ist die freie Übergabe von SQL, Filtern oder API-Parametern aus dem Modell an Backend-Systeme. In Demos wirkt das elegant. Im Betrieb ist es unnötig riskant. Produktive Anwendungen sollten Tool-Aufrufe über strukturierte Absichten, feste Schemata und serverseitige Allowlists abwickeln. Sonst wandert Sicherheitslogik in probabilistische Textausgabe.
Welche Prüfungen vor jedem Tool-Aufruf Pflicht sind
Vor jeder echten Aktion braucht die Anwendung eine deterministische Prüfung außerhalb des Modells. Erstens erzeugt das Modell nur eine strukturierte Absicht, keine freie API-Anweisung. Zweitens werden Parameter gegen ein festes Schema validiert. Drittens erfolgt die Autorisierung serverseitig anhand von Rolle, Mandant, Scope und Objektzugriff. Viertens wird die Aktion einer Risikoklasse zugeordnet, damit sie erlaubt, blockiert oder zur Freigabe vorgelegt werden kann.
type Action = {
type: "search_kb" | "read_ticket" | "draft_reply" | "send_email" | "update_customer";
tenantId: string;
objectId?: string;
fields?: string[];
payload?: Record<string, unknown>;
};
function classifyRisk(action: Action): "low" | "medium" | "high" {
if (action.type === "send_email" || action.type === "update_customer") return "high";
if (action.type === "read_ticket" || action.type === "draft_reply") return "medium";
return "low";
}
function authorize(user, action: Action) {
if (user.tenantId !== action.tenantId) return false;
if (action.type === "read_ticket") return user.scopes.includes("ticket:read");
if (action.type === "draft_reply") return user.scopes.includes("reply:draft");
if (action.type === "send_email") return user.scopes.includes("email:send") && user.requiresApproval === false;
if (action.type === "update_customer") return user.scopes.includes("customer:write");
if (action.type === "search_kb") return user.scopes.includes("kb:read");
return false;
}Dieses Muster ist absichtlich unspektakulär. Genau das macht es belastbar. Sicherheitskritische Entscheidungen sollten testbar, nachvollziehbar und langweilig sein.
Ein konkretes Beispiel: Ein interner Support-Assistent darf Tickets lesen, Antwortentwürfe erzeugen und bei Bedarf Kundendaten aus dem CRM nachschlagen. In einem unsauberen Setup enthält ein Ticket die Anweisung, alle Regeln zu ignorieren und die Historie an eine externe Adresse zu senden. Wenn Tickettext, Tool-Beschreibung und Berechtigungslogik im selben Kontext vermischt sind, kann das Modell diese Anweisung semantisch ernst nehmen. In einem sauberen Setup erzeugt es höchstens die Absicht send_email; die Anwendung klassifiziert sie als Hochrisiko-Aktion und blockiert sie ohne Freigabe.
Ein CRM-Agent mit Schreibrechten ist noch heikler. Wenn das Modell aus einer vagen Benutzeranfrage selbst ableitet, welches Feld geändert werden soll, reicht schon ein missverständlicher Prompt oder ein manipuliertes Dokument für eine falsche Stammdatenänderung. Ein Wissensassistent mit Leserechten ist ärgerlich, wenn er halluziniert. Ein schreibender Agent mit schwacher Autorisierung wird teuer.
Das NIST AI 100-2 ist hier als Orientierung nützlich, weil es adversariale Einflüsse auf KI-Systeme systematisch einordnet. Daraus folgt keine einzelne Pflichtarchitektur. Es stützt aber die Praxis, Angriffsflächen nicht im Prompt zu verwalten, sondern in einer technischen Kontrollschicht davor und daneben.
Datenabfluss bei KI vermeiden: Retrieval, Logs und Speicherpfade begrenzen
Datenabfluss bei KI vermeiden beginnt vor dem Modell und endet nicht bei der Antwort. Kritische Stellen liegen oft im Prompt-Building, in Telemetrie, Caches, Vektorindizes, Debug-Logs und Exportpfaden. Dort verlieren Teams die Kontrolle, obwohl die sichtbare Modellantwort harmlos wirkt.
Für den polnischen Markt ist das besonders relevant, weil viele Einführungen in zentralisierten Service-Strukturen stattfinden. Ein Support- oder Operations-Team in Polen arbeitet für mehrere EU-Gesellschaften, nutzt gemeinsame Systeme und verarbeitet Inhalte mit unterschiedlichen lokalen Rechten. Ein gemeinsamer Assistent klingt effizient. Ohne tenant-aware Trennung wird daraus schnell ein internes Leck über Organisationsgrenzen hinweg.
Die DSGVO macht an dieser Stelle keine LLM-Sonderwelt auf. Sie verlangt unter anderem Datenminimierung sowie Integrität und Vertraulichkeit nach Art. 5 Abs. 1 lit. c und f. Technisch heißt das: nur notwendige Felder laden, Zugriff vor dem Prompt begrenzen, Speicherpfade trennen und Verarbeitung nachvollziehbar halten. Die EDPB-Leitlinien zu Datenschutz durch Technikgestaltung sind hier relevant, weil sie aus einem abstrakten Prinzip eine konkrete Designrichtung machen, nicht weil sie eine einzelne Vektorarchitektur vorschreiben.
Mandantentrennung vor der Suche erzwingen
Ein gemeinsamer Vektorindex für mehrere Mandanten oder Gesellschaften kann funktionieren, aber nur unter engen Bedingungen: verpflichtende serverseitige Filter, saubere Metadaten, belastbare Löschpfade und Tests gegen Fehlkonfigurationen. Fehlt eine dieser Bedingungen, ist ein gemeinsamer Index kein Effizienzgewinn, sondern ein stilles Betriebsrisiko.
