
Die bekannteste Liste der LLM-Sicherheitsrisiken hat zehn Punkte. Drei davon entscheidest du in deinem Haus. Bei den anderen sieben bist du Zuschauer.
Das ist die nützlichere Nachricht von beiden. Solange die Liste als Pflichtenheft gelesen wird, steht am Ende ein Sicherheitsprojekt, das im Haus niemand betreiben kann, und daneben ein Budgetposten für ein Werkzeug, das gegen sieben der zehn Punkte nichts ausrichtet.
Die Liste der LLM-Sicherheitsrisiken ist nicht für dich geschrieben
Gemeint ist die OWASP Top 10 for LLM Applications, Fassung 2025, gepflegt vom OWASP GenAI Security Project. OWASP sagt im ersten Satz selbst, für wen die Sammlung gedacht ist: für Risiken und Gegenmassnahmen beim Entwickeln und Absichern von generativer KI und LLM-Anwendungen, über den ganzen Entwicklungs-, Bereitstellungs- und Betriebszyklus. Keine dieser Tätigkeiten findet in einem Haus statt, das Microsoft 365 abonniert und einen Assistenten dazubucht.
Drei der zehn Punkte zeigen das sofort: Data and Model Poisoning, System Prompt Leakage, Vector and Embedding Weaknesses. In den meisten KMU trainiert niemand ein Modell, und es gibt keinen selbst geschriebenen Systemprompt, den jemand stehlen könnte.
Sortiert man die LLM-Sicherheitsrisiken für ein Haus, das KI einkauft, ergibt sich dieses Bild: drei Punkte entscheidest du im Betrieb, drei beim Einkauf, drei gehören dem Anbieter. Bleibt Nummer eins, Prompt Injection. Den haben wir separat auseinandergenommen, und der Befund dort war, dass Prompt Injection für dich eine Rechtefrage ist und keine Modellfrage. Damit landet er beim zweiten der drei Entscheide, die dir gehören.
Was reingeht, und was der Assistent von sich aus lesen darf
Sensitive Information Disclosure steht auf Platz zwei. OWASP zählt auf, was gemeint ist: Personendaten, Finanzdaten, Gesundheitsdaten, vertrauliche Geschäftsdaten, Zugangsdaten, juristische Dokumente. An die Nutzerseite gerichtet steht dort der Satz, dass Anwender die Risiken verstehen müssen, unabsichtlich sensible Daten zu liefern, die später in der Ausgabe des Modells wieder auftauchen können.
Dieser Punkt hat zwei Hälften. Über die zweite redet kaum ein Anbietergespräch.
Die erste Hälfte ist, was Mitarbeitende eintippen. Darüber reden die meisten Einführungen, und mit einer Datenordnung und einem Firmenkonto ist sie weitgehend erledigt. Welche Kategorien in ein KI-Werkzeug dürfen und welche nicht, haben wir bei der Frage welche Daten in ChatGPT dürfen durchgespielt.
Die zweite Hälfte ist, was der Assistent von sich aus lesen darf. Ein Assistent, der in dein Microsoft 365 eingebaut ist, bekommt keine neuen Rechte. Er benutzt die, die die angemeldete Person schon hat. Wenn ein Laufwerk seit Jahren für alle offen steht, war das vorher ein Ordnungsproblem, das kaum jemand gesehen hat. Jetzt ist es ein Ordnungsproblem mit einer Suchfunktion, die freundlich antwortet.
OWASP nennt als Gegenmassnahme dazu nichts Exotisches, sondern das Prinzip der minimalen Rechte: Zugriff nur auf Daten, die für die Person oder den Prozess nötig sind. Diese Empfehlung klingt unspektakulär. In unserer Erfahrung bringt sie mehr als ein zugekauftes Werkzeug. Für den Durchgang vor einer Copilot-Einführung haben wir das in Berechtigungen vor dem Copilot-Rollout aufgeschrieben.
Beide Hälften sind eine Zugriffsfrage, und kein Modellhersteller kann sie für dich beantworten.
Was er ohne Rückfrage tun darf
Excessive Agency, Platz sechs, ist laut OWASP die Schwachstelle, die es möglich macht, dass schädliche Handlungen ausgeführt werden, wenn die Ausgabe eines Modells unerwartet, mehrdeutig oder manipuliert ist. Als Wurzeln nennt die Liste drei: zu viele Funktionen, zu viele Rechte, zu viel Selbstständigkeit.
Das Wort «manipuliert» holt Nummer eins wieder herein. Ob das Modell halluziniert oder ob jemand ihm über einen eingeschleusten Text etwas vorgesagt hat, ändert am Schaden nichts. Was den Schaden begrenzt, ist die Antwort darauf, was der Assistent ohne Rückfrage tun darf. OWASP empfiehlt wörtlich, einen Menschen einzubauen, der Handlungen mit hoher Wirkung vorher freigibt, und nennt als Beispiel für zu weite Rechte einen Lesezugriff, der auch ändern und löschen darf, obwohl nur gelesen werden sollte.
In dem Moment, in dem ein Assistent eine Anbindung bekommt, die schreiben darf, ist das keine KI-Frage mehr. Es ist dieselbe Frage wie bei jedem Dienstkonto: wer hat das freigegeben, mit welchen Rechten, und bis wann. Die letzte Teilfrage fehlt in vielen Häusern. Eine Freigabe ohne Ablaufdatum wird selten nachgeprüft, und in unserer Erfahrung sammeln sich genau dort die Rechte an, die niemand mehr begründen kann.
Wie tief die Prüfung vor einer Freigabe gehen muss, haben wir in KI-Tools bewerten gestaffelt. Für Werkzeuge, die mehrere Schritte selbst aneinanderhängen, gilt zusätzlich das, was wir zur Governance für KI-Agenten geschrieben haben.
Was du mit der Antwort machst
Misinformation steht auf Platz neun, und dieser Punkt lässt sich nicht einkaufen. OWASP beschreibt den Kern als Überverlass: Anwender vertrauen den Ausgaben zu stark und prüfen die Richtigkeit nicht.
Die Gegenmassnahmen, die OWASP dazu nennt, sind organisatorisch: Ausgaben gegen verlässliche externe Quellen gegenprüfen, menschliche Aufsicht und Faktenprüfung bei kritischen Inhalten einbauen, Grenzen und Risiken gegenüber den Anwendern klar benennen. Dazu ein Satz, der selten zitiert wird: auch die Menschen, die prüfen, müssen geschult sein, damit sie sich nicht selbst auf die KI verlassen.
Für ein KMU wird daraus eine Betriebsfrage. Sie lautet: an welchen Stellen kostet eine falsche Antwort Geld oder Vertrauen? Eine Offerte, eine Kalkulation, eine Vertragsklausel, eine Lohnabrechnung, eine Datenschutzauskunft an einen Kunden, beantwortet aus einem Chatfenster. An diesen Stellen gab es schon vor der KI ein Vieraugenprinzip, oder es hätte eines geben müssen. Der Assistent macht das Fehlen davon nur schneller sichtbar.
Dieser Punkt verlangt keine Investition. Er verlangt, dass du drei oder vier Stellen benennst, an denen eine Antwort nicht ungeprüft weitergeht.
Drei Punkte, die am Einkauf hängen
Drei weitere LLM-Sicherheitsrisiken fallen im Einkaufsgespräch, und danach schaut sie selten jemand wieder an.
Supply Chain, Platz drei, ist davon der greifbarste. OWASP empfiehlt, Datenquellen und Lieferanten sorgfältig zu prüfen, Geschäftsbedingungen und Datenschutzerklärungen eingeschlossen, und nur vertrauenswürdige Lieferanten einzusetzen. Dazu der Nebensatz, der die Grenze dieser Prüfung benennt: Modelle sind binäre Blackboxes, und anders als bei offenem Quellcode lassen sich durch Hinschauen kaum Sicherheitsaussagen gewinnen. Schweizer Recht sagt in dieselbe Richtung, nur verbindlicher. Art. 9 Abs. 2 des Datenschutzgesetzes hält fest: «Der Verantwortliche muss sich insbesondere vergewissern, dass der Auftragsbearbeiter in der Lage ist, die Datensicherheit zu gewährleisten.» Vergewissern, nicht vereinbaren. Und Abs. 3 verlangt für die Weitergabe an einen Dritten die vorgängige Genehmigung, was bei KI-Anbietern mit langen Unterauftragsketten der Punkt ist, an dem es unbequem wird. Den Durchgang dafür haben wir im Auftragsbearbeitungsvertrag-Check für KI-Tools beschrieben.
Vector and Embedding Weaknesses, Platz acht, betrifft dich nur, wenn der Assistent auf deinen eigenen Dokumenten arbeitet. Genau das tun die Assistenten in den Office-Paketen. OWASP beschreibt das Risiko so, dass in gemeinsam genutzten Umgebungen Inhalte zwischen Nutzern oder Abfragen durchsickern können, und empfiehlt einen Vektorspeicher, der Berechtigungen kennt. Die Bauarbeit dafür liegt beim Anbieter. Dir bleibt eine einzige Frage im Einkaufsgespräch: Hält der Index die Berechtigungen ein, die in unserem System gelten? Kommt darauf keine klare Antwort, hast du eine Information, die mehr wert ist als ein Zertifikat im Anhang.
Unbounded Consumption, Platz zehn, verlangt genaues Lesen. OWASP schreibt es aus Sicht des Anbieters: ein Angreifer löst massenhaft Abfragen aus und treibt die Kosten des Dienstes ins Unhaltbare. Für dich wird daraus erst etwas, wenn du nach Verbrauch bezahlst statt pro Nutzer und Monat. Dann ist es eine Rechnungsfrage, und die Gegenmassnahme steht ebenfalls in der Liste: Obergrenzen und Kontingente. Bei einem Abo pro Kopf kannst du diesen Punkt abhaken.
Die Baustelle des Anbieters
Data and Model Poisoning, Improper Output Handling und System Prompt Leakage sind Bauarbeit. Wer das Modell trainiert, wer die Anwendung schreibt, wer den Systemprompt setzt, verantwortet sie. In einem Haus, das KI einkauft, gibt es dafür keinen sinnvollen Arbeitsauftrag.
Eine Ausnahme wird häufiger. Improper Output Handling heisst, dass die Ausgabe eines Modells ungeprüft dort landet, wo sie etwas auslöst. Sobald jemand bei dir einen Ablauf baut, in dem eine Modellantwort eine Aktion startet, in einem Low-Code-Werkzeug, einem Makro, einem Skript, ist dieser Punkt bei dir angekommen. Dann ist es das, was es immer war: ungeprüfte Eingabe, die ausgeführt wird.
Daraus ergibt sich eine Streichliste, die ein Budget schont. Für diese drei LLM-Sicherheitsrisiken braucht ein KMU kein eigenes KI-Sicherheitsprodukt. Ein zugekauftes Werkzeug, das verspricht, Modellvergiftung oder Prompt-Diebstahl zu verhindern, verteidigt eine Baustelle, die dir nicht gehört. Dasselbe gilt für den Anbieterfragebogen mit vierzig Positionen, der am Ende keinen der drei Entscheide beantwortet, die bei dir liegen. Das Geld ist besser in der Durchsicht der Zugriffsrechte angelegt, die du ohnehin brauchst, und oft steckt die gewünschte Funktion schon in einem Abo, das längst bezahlt wird. Dieses Muster beschreiben wir ausführlicher beim Konsolidieren von Sicherheitstools.
Der Rest ist eine Frage an den Anbieter
Legst du die drei Entscheide nebeneinander, die in deinem Haus fallen, handelt keiner davon vom Modell. Es geht um Zugriff, um Freigaben und darum, wer für eine Antwort geradesteht. Diese Fragen hättest du auch stellen müssen, wenn nie jemand ein Sprachmodell gebaut hätte. Die KI hat sie nicht erfunden, sie hat sie nur dringend gemacht.
Das ist auch der Grund, warum eine KI-Richtlinie, die bei den Werkzeugen anfängt, oft im Leeren läuft. Nützlicher ist eine, die bei diesen drei Entscheiden anfängt. Wir haben aufgeschrieben, was auf eine Seite KI-Richtlinie gehört, und begleiten in der KI-Governance und sicheren KI-Einführung genau diesen Teil. Wer einordnen will, wo das eigene Haus bei den LLM-Sicherheitsrisiken steht, bekommt im Erstgespräch eine nüchterne Einschätzung, unverbindlich.
Wer darf bei euch einem KI-Werkzeug ein Schreibrecht erteilen?
Häufige Fragen
Was ist die OWASP Top 10 für LLM-Anwendungen?
Die OWASP Top 10 for LLM Applications ist eine Liste der zehn wichtigsten Sicherheitsrisiken von Anwendungen mit grossen Sprachmodellen, gepflegt vom OWASP GenAI Security Project. Die Fassung 2025 richtet sich laut OWASP an alle, die solche Anwendungen entwickeln, bereitstellen und betreiben, nicht an reine Anwenderfirmen.
Welche LLM-Sicherheitsrisiken kann ein KMU selbst beeinflussen?
Drei davon. Erstens, welche Daten hineingehen und was der Assistent von sich aus lesen darf. Zweitens, welche Handlungen er ohne menschliche Freigabe ausführen darf. Drittens, was mit der Antwort geschieht, also wo ungeprüfte Ergebnisse Geld oder Vertrauen kosten. Alle drei sind Zugriffs- und Freigabefragen, keine Modellfragen.
Braucht ein KMU ein eigenes Sicherheitsprodukt für KI?
In den meisten Fällen nicht. Risiken wie Modellvergiftung, fehlerhafte Ausgabeverarbeitung und Systemprompt-Diebstahl liegen beim Anbieter, der die Anwendung baut. Ein zugekauftes Werkzeug verteidigt dort eine fremde Baustelle. Wirksamer ist eine Durchsicht der bestehenden Zugriffsrechte, oft mit Funktionen, die im vorhandenen Abo bereits enthalten sind.




