LLM-Anwendungen absichern: Prompt Injection, Datenabfluss und Zugriffskontrolle

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.

Ein belastbares Muster sieht so aus: Jedes Dokument trägt Metadaten für Mandant, Geschäftsbereich, Datenklasse, Sprache, Region und Löschstatus. Der Mandantenkontext kommt aus der Session oder dem Identitätssystem, nicht aus dem Modelloutput. Der Suchraum wird serverseitig auf erlaubte Collections oder Partitionen begrenzt. Feldfilter greifen bereits im Quellsystem oder im Preprocessing, bevor Text in Embeddings überführt wird. Gelöschte oder gesperrte Inhalte müssen aus Index und Cache verschwinden, nicht nur aus der Primärquelle.

Für viele Shared-Service- und BPO-nahe Setups in Polen ist physische Trennung der robustere Weg. Das ist keine starre regulatorische Pflicht, sondern ein Architektururteil zugunsten von Auditierbarkeit und Fehlertoleranz. Sobald mehrere Gesellschaften, externe Dienstleister oder unterschiedliche Datenklassen zusammenkommen, sinkt mit getrennten Indizes die Zahl der Fehlerpfade. Wer im EU-Markt einen generischen KI-Assistenten kauft und Mandantentrennung erst später nachrüstet, kauft oft zweimal.

Ein typisches Rollout-Problem ist organisatorisch. Ein zentrales Team in Polen bearbeitet Anfragen für mehrere EU-Einheiten, während Fachbereiche eigene Wissensquellen nachpflegen. Dann reicht es nicht, Dokumente technisch zu indexieren. Es braucht einen klaren Freigabeprozess dafür, wer welche Quelle mit welcher Datenklasse und welchem Mandantenkontext einspeisen darf. Sonst wird aus Retrieval ein Berechtigungsproblem mit besserer Oberfläche.

Logs, Caches und Debug-Pfade sind oft das eigentliche Leck

Viele Lecks entstehen nicht in der Modellantwort, sondern in Nebenpfaden. Vollständige Prompts mit personenbezogenen Daten, komplette Antworten mit Kundendetails, Dateianhänge, Zugangstoken, API-Schlüssel, Session-Cookies oder unmaskierte Tickettexte gehören nicht in Standard-Logs. Dort sollten stattdessen Referenzen, Hashes, Klassifizierungen, Policy-Entscheidungen und technische Fehlercodes landen.

Auch Caches werden regelmäßig unterschätzt. Wenn Antworten, Retrieval-Ergebnisse oder Embeddings zwischengespeichert werden, muss die Cache-Strategie dieselben Grenzen respektieren wie das Primärsystem: Mandant, Datenklasse, Löschstatus, Aufbewahrung und Zugriff. Ein Cache ohne Mandantenkontext ist kein Performance-Feature, sondern ein potenzieller Querverweis auf fremde Daten.

Das NIST AI Risk Management Framework hilft hier als Governance-Referenz, weil es Monitoring und laufende Risikokontrolle betont. Daraus folgt keine unmittelbare Rechtsnorm. Es ist aber eine brauchbare Richtschnur für die Frage, welche Rohdaten man überhaupt speichern sollte und welche besser gar nicht erst in allgemeine Observability-Systeme gelangen.

Der EU AI Act ändert ebenfalls nicht jede Architekturentscheidung direkt. Er erhöht aber den Druck auf nachvollziehbare Governance, Dokumentation und menschliche Aufsicht in risikorelevanten Einsatzszenarien. Wer Kontrollschichten nur implizit in Prompts versteckt, baut gegen diese Marktrichtung.

Zugriffskontrolle für LLM: Rechte vor dem Kontext, Freigaben vor dem Schreiben

Zugriffskontrolle für LLM muss auf vier Ebenen greifen: Benutzer, Datenobjekt, Tool und Ausgabe. Wer nur beim Login prüft und danach dem Modell vertraut, baut keine Sicherheitsarchitektur, sondern eine Fassade.

Die wichtigste Regel lautet: Rechte werden vor dem Prompt erzwungen. Wenn ein Benutzer ein Objekt oder Feld nicht sehen darf, darf dieser Inhalt gar nicht erst in Retrieval, Prompt oder Tool-Kontext gelangen. Nachträgliches Maskieren ist schwächer, weil das Modell die Information bereits verarbeitet hat und sie in Zusammenfassungen oder Folgeaktionen indirekt wieder auftauchen kann.

Das gilt besonders für Feldrechte. Ein Mitarbeiter darf vielleicht einen Kundenfall sehen, aber nicht Zahlungsdaten oder interne Eskalationsnotizen. Dann müssen genau diese Felder vor dem Kontextaufbau entfernt werden. Ein grobes Rollenmodell auf Dokumentebene reicht in vielen Unternehmensprozessen nicht aus.

Für schreibende oder auslösende Funktionen braucht es zusätzlich ein Freigabemodell. Das Modell erzeugt nur den Entwurf oder die strukturierte Absicht. Die Anwendung erstellt daraus einen serverseitigen Freigabevorgang mit Aktionsklasse, betroffenen Objekten, Quellen, Risikostufe, verantwortlicher Rolle und Zeitstempeln. Erst nach expliziter Bestätigung wird ausgeführt.

Gerade in Polen sind solche Modelle oft wichtiger, weil zentrale Teams im Namen mehrerer Gesellschaften arbeiten. Ein einfacher Chat-Verlauf reicht dann als Nachweis nicht aus. Man braucht einen Audit-Trail, der zeigt, wer welche Aktion ausgelöst hat, auf welcher Grundlage sie freigegeben wurde und welche Datenquellen dabei im Spiel waren.

Ein sicheres System muss im Zweifel blockieren.

Das klingt banal, wird aber in Projekten regelmäßig verdrängt. Gute Sprachmodelle sind auf Hilfsbereitschaft optimiert. Produktionssysteme brauchen an kritischen Stellen das Gegenteil: defensives Verhalten bei Unsicherheit, fehlender Berechtigung oder unklarer Policy.

Welche Architektur für Unternehmen in Polen und der EU meist sinnvoll ist

Für viele Unternehmen ist ein hybrides Betriebsmodell die vernünftigste Wahl: Modellzugriff über einen etablierten Anbieter, aber Vorverarbeitung, Feldfilter, Policy-Entscheidungen, Tool-Broker und Audit unter eigener Kontrolle. Das reduziert Integrationsaufwand, ohne die kritischen Sicherheitsentscheidungen aus der Hand zu geben.

Die Anbieterauswahl sollte nicht mit Marketingbegriffen beginnen, sondern mit vier nüchternen Prüfungen: Wo werden Anfragen verarbeitet und gespeichert? Werden Kundendaten für Training oder Produktverbesserung verwendet? Welche Löschpfade, Administrationskontrollen und Audit-Logs sind dokumentiert? Und wie transparent sind Rollenmodell, Schlüsselverwaltung und Netzwerkgrenzen?

Für polnische Unternehmen mit regionalen Gesellschaften oder zentralisierten Shared Services ist der Datenfluss oft komplexer als die Modellintegration. Entscheidend ist nicht nur, ob das Modell in der EU gehostet wird. Entscheidend ist, ob Mandant, Land, Geschäftsbereich und Datenklasse entlang der gesamten Verarbeitungskette technisch erzwungen werden.

Ein häufiger Beschaffungsfehler ist schnell beschrieben: Zuerst wird ein universeller KI-Assistent gekauft, danach versucht man Berechtigungen, Logging und Datenfilter nachzurüsten. Das verkauft sich gut in der Demo und schlecht im Audit. Im EU-Markt ist ein generischer Assistent mit nachträglich angeflanschter Rechte-Logik selten die günstigste Lösung über den Lebenszyklus.

Ein sinnvoller Rollout bleibt absichtlich eng. Zuerst ein Use Case mit klarem Geschäftswert und ohne kritische Schreibrechte. Danach Retrieval und Tooling pro Funktion statt als Universalagent modellieren. Freigaben zuerst für externe Kommunikation und Datenänderungen einführen. Auditierbarkeit vor Komfort priorisieren. Erst dann Reichweite und Automatisierungsgrad erhöhen.

Die operative Schlüsselfrage lautet nicht, ob das Modell gute Antworten gibt. Entscheidend ist, ob die Anwendung dem Modell nur Sprache oder bereits operative Macht gibt.

Damit wird auch die Kaufentscheidung klarer. Standard-SaaS ist stark, solange der Prozess standardisiert ist. Sobald Objektberechtigungen, Feldfilter, Freigaben und Mandantentrennung pro Fachprozess variieren, kippt der Vorteil. Dann ist nicht das Modell der Engpass, sondern die fehlende Kontrollschicht zwischen Modell und Unternehmenssystemen.

LLM-Anwendungen absichern heißt deshalb nicht, den Prompt immer weiter zu verfeinern. Es heißt, Kontext zu isolieren, Retrieval und Speicherpfade zu begrenzen, Rechte vor dem Kontextaufbau zu erzwingen und schreibende Aktionen nur über prüfbare Freigaben zuzulassen. Alles andere kann im Pilot funktionieren. Für produktive Umgebungen in Polen und der EU ist es kein belastbarer Standard.