LLM-Sicherheit: Die Risiken von Sprachmodellen und wie Unternehmen sie kontrollieren
LLM-Sicherheit umfasst die Maßnahmen, mit denen Unternehmen die spezifischen Risiken von Sprachmodellen beherrschen: Eingaben, die das Verhalten des Modells manipulieren, Ausgaben, die ungeprüft weiterverarbeitet werden, und Berechtigungen, die weiter reichen als nötig.
Der entscheidende Unterschied zur klassischen Anwendungssicherheit: Bei einem Sprachmodell gibt es keine saubere Trennung zwischen Anweisung und Daten. Beides kommt als Text an, und das Modell kann nicht zuverlässig unterscheiden, was davon eine legitime Anweisung ist.
Dieser Artikel ordnet die Risiken, die Betreiber betreffen – also Unternehmen, die Modelle einsetzen, statt sie zu entwickeln –, und benennt die Gegenmaßnahmen nach Wirkung.
Direkte und indirekte Prompt Injection
Prompt Injection bezeichnet den Versuch, ein Modell über Text dazu zu bringen, seine Vorgaben zu übergehen. Bei der direkten Variante tippt die nutzende Person diesen Text selbst ein. Sie ist das kleinere Problem, weil die Person ohnehin nur ihre eigenen Rechte nutzt.
Die indirekte Variante ist die relevante: Die Anweisung steckt in Inhalten, die das Modell im Auftrag der Person liest – in einem hochgeladenen Dokument, einer Webseite, einer E-Mail, einem Kalendereintrag. Das Modell verarbeitet sie als Text und kann sie als Anweisung auffassen.
Damit wird jedes System, das externe Inhalte einliest, zur Angriffsfläche. Der Angreifer braucht keinen Zugang zum Unternehmen – es genügt, dass ein Dokument mit präpariertem Inhalt dort ankommt und gelesen wird.
Die Risiken, die Betreiber betreffen
Wer Modelle einsetzt statt sie zu bauen, muss sich nicht mit allen Risikoklassen befassen. Diese sechs sind die relevanten; die vollständige Systematik pflegt das OWASP GenAI Security Project.
| Risiko | Was passiert | Wirksamste Gegenmaßnahme |
|---|---|---|
| Indirekte Prompt Injection | Präparierter Text in einem Dokument oder auf einer Webseite steuert das Modell | Externe Inhalte als nicht vertrauenswürdig behandeln; keine automatischen Aktionen aus gelesenen Inhalten ableiten |
| Abfluss vertraulicher Daten | Personendaten oder Geschäftsgeheimnisse gelangen in ein System ohne Vertrag und Standortzusage | Zentrale Plattform mit Auftragsverarbeitungsvertrag und geklärter Region statt privater Accounts |
| Ungeprüfte Weiterverarbeitung von Ausgaben | Modellausgaben landen ungefiltert in Dokumenten, Mails, Code oder Datenbankabfragen | Ausgaben als Entwurf behandeln; technische Validierung, bevor sie in Systeme fließen |
| Zu weit gefasste Berechtigungen | Ein Assistent darf mehr, als der Anwendungsfall verlangt – etwa schreiben statt nur lesen | Rechte je Anwendungsfall minimieren; schreibende Aktionen bestätigen lassen |
| Falschaussagen mit Faktenanmutung | Zahlen, Fristen oder Rechtsgrundlagen werden überzeugend, aber falsch dargestellt | Verbindliche Quellenprüfung; Anwendungen mit belegbaren Fundstellen bevorzugen |
| Schwächen in der Wissensbasis | In eine durchsuchbare Ablage gelangen Inhalte, die nicht alle Nutzenden sehen dürfen | Zugriffsrechte auf Dokumentebene abbilden, nicht erst in der Antwort filtern |
Warum Halluzinationen ein Sicherheitsthema sind
Falsche Modellausgaben werden meist als Qualitätsproblem behandelt. Sicherheitsrelevant werden sie, sobald sie in Entscheidungen einfließen: eine erfundene Frist in einem Schriftsatz, eine falsche Rechtsgrundlage in einem Bescheid, eine nicht existente Vorschrift in einer internen Weisung.
Technisch lassen sich Halluzinationen nicht ausschließen. Organisatorisch lassen sie sich einhegen, indem Ausgaben grundsätzlich als Entwurf gelten und für bestimmte Kategorien – Zahlen, Fristen, Rechtsgrundlagen, Zitate – eine Prüfung an der Quelle verbindlich ist.
Anwendungen, die auf hinterlegte eigene Dokumente zugreifen und Fundstellen zurückgeben, senken das Risiko deutlich, weil die Prüfung dann nicht mehr Recherche, sondern nur noch Nachschlagen bedeutet.
Berechtigungen: das Risiko wächst mit den Rechten
Solange ein Modell Text erzeugt, bleibt der Schaden begrenzt. Er wächst sprunghaft, sobald es handeln darf – E-Mails versenden, Dateien schreiben, Datensätze ändern, andere Systeme aufrufen.
In dieser Kombination wird die indirekte Prompt Injection gefährlich: Ein präpariertes Dokument kann dann nicht nur eine Antwort verfälschen, sondern eine Aktion auslösen. Deshalb gilt für Assistenten dieselbe Regel wie für Dienstkonten – so wenige Rechte wie möglich, und schreibende Aktionen mit ausdrücklicher Bestätigung.
Rahmenwerke zur Orientierung
Man muss die Systematik nicht selbst erfinden. Drei etablierte Rahmenwerke decken unterschiedliche Ebenen ab und lassen sich kombinieren.
- OWASP GenAI Security Project: pflegt die Top-10-Liste der Risiken von LLM-Anwendungen – die technische Referenz für Bedrohungen und Gegenmaßnahmen.
- NIST AI Risk Management Framework 1.0, veröffentlicht im Januar 2023: gliedert das Risikomanagement in die vier Funktionen Govern, Map, Measure und Manage – nützlich als Aufbau für die eigene Governance.
- ISO/IEC 42001, veröffentlicht im Dezember 2023: die erste zertifizierbare Norm für KI-Managementsysteme – relevant, wenn Kunden oder Aufsicht einen Nachweis verlangen.
Maßnahmen nach Wirkung
Die Reihenfolge ist nach Wirkung je Aufwand sortiert. Die ersten drei Schritte decken den größten Teil des realistischen Risikos ab.
- Nutzung zentralisieren: ein verwalteter Zugang mit Vertrag, geklärter Region und ausgeschlossenem Training statt privater Accounts. Das beseitigt den häufigsten Schadensfall.
- Ausgaben als Entwurf definieren und die Prüfpflicht für Zahlen, Fristen und Rechtsgrundlagen schriftlich festhalten.
- Rechte je Anwendungsfall minimieren; schreibende Aktionen nur mit Bestätigung.
- Externe Inhalte als nicht vertrauenswürdig behandeln – besonders dort, wo Dokumente oder Webseiten automatisch eingelesen werden.
- Zugriffsrechte in der Wissensbasis auf Dokumentebene abbilden, statt erst die Antwort zu filtern.
- Protokollieren, was wann von wem genutzt wurde, damit sich ein Verdacht überhaupt prüfen lässt.
- Schulen: Wer indirekte Prompt Injection einmal an einem Beispiel gesehen hat, erkennt sie im Alltag wieder. Das adressiert zugleich Art. 4 EU AI Act.
Häufige Fragen
Was ist Prompt Injection?
Der Versuch, ein Sprachmodell über Text dazu zu bringen, seine Vorgaben zu übergehen. Direkt gibt die nutzende Person den Text selbst ein; indirekt steckt er in Inhalten, die das Modell liest – etwa in einem Dokument oder auf einer Webseite. Die indirekte Variante ist für Unternehmen die relevantere.
Lässt sich Prompt Injection technisch verhindern?
Vollständig nicht, weil Sprachmodelle Anweisung und Daten nicht sauber trennen können – beides kommt als Text an. Beherrschbar wird das Risiko über die Architektur: externe Inhalte als nicht vertrauenswürdig behandeln, Rechte minimieren und aus gelesenen Inhalten keine automatischen Aktionen ableiten.
Sind Halluzinationen ein Sicherheitsproblem?
Sobald Ausgaben in Entscheidungen einfließen, ja. Eine erfundene Frist oder Rechtsgrundlage wirkt wie eine falsche Auskunft. Die wirksame Gegenmaßnahme ist organisatorisch: Ausgaben gelten als Entwurf, und für Zahlen, Fristen und Rechtsgrundlagen ist die Prüfung an der Quelle verbindlich.
Welche Rolle spielt die Wahl des Modells?
Eine geringere als oft angenommen. Die häufigsten Schadensfälle entstehen nicht durch das Modell, sondern durch die Umgebung: fehlender Vertrag, unklarer Verarbeitungsstandort, zu weite Rechte, ungeprüfte Weiterverarbeitung. Die Modellwahl ist eine Qualitätsfrage, die Umgebung eine Sicherheitsfrage.
Brauchen wir eine ISO/IEC 42001-Zertifizierung?
Nur, wenn Kunden, Aufsicht oder Ausschreibungen einen Nachweis verlangen. Als Ordnungsrahmen ist die Norm auch ohne Zertifizierung nützlich. Für die meisten Unternehmen im DACH-Raum ist eine dokumentierte KI-Richtlinie samt Schulung der pragmatischere erste Schritt.
Was ist der häufigste Fehler in der Praxis?
Sicherheit am Modell festzumachen statt an der Umgebung. Der weitaus häufigste Schadensfall ist kein Angriff, sondern der Alltag: vertrauliche Daten in einem privaten Account, ohne Vertrag, ohne geklärte Region und ohne Protokoll darüber, was dorthin geflossen ist.
Quellen
- OWASP Top 10 für LLM-Anwendungen · OWASP GenAI Security Project
- AI Risk Management Framework (AI RMF 1.0) · NIST
- Verordnung (EU) 2024/1689 (EU AI Act) · EUR-Lex
Weiterführende Inhalte
Bringen Sie KI sicher in Ihr Unternehmen.
Testen Sie Custodos mit Ihrem Team – und erleben Sie, wie schnell sichere KI produktiv wird.
- Mit dem ganzen Team testen
- In Minuten eingerichtet
- Sofort produktiver arbeiten