Ein Risikoteam erhält zwei Tage vor dem Start einen neuen Chatbot zur Unterstützung von Mitgliedern im Gesundheitswesen. Bei einem späten Test gibt der Bot einem Mitglied Schritt-für-Schritt-Anweisungen zur Dosierung eines verschreibungspflichtigen Medikaments – obwohl die Produktanforderungen vorsehen, dass er medizinische Ratschläge verweigern und das Mitglied an eine Hotline für Pflegefachkräfte verweisen muss. Niemand kann die erste für eine Risikobewertung erforderliche Frage beantworten: An welcher Stelle im System hätte dieses Verhalten verhindert, erkannt oder eingedämmt werden können?
Im weiteren Verlauf dieser Lektion erstellen wir ein Bedrohungsmodell für schädliche Ausgaben, indem wir die Ereigniskette von Anfang bis Ende durchgehen und diese Kette anschließend in konkrete Kontrollpunkte umwandeln, die sich messen und steuern lassen.
In diesem Kurs ist ein Bedrohungsmodell eine strukturierte Beschreibung, wie ein bestimmter Schaden in Ihrer LLM-Anwendung entstehen kann, welche Komponenten daran beteiligt sind, welche Bedingungen erfüllt sein müssen und welche Nachweise Sie sammeln können, um diesen Pfad zu bestätigen oder zu widerlegen. Bei schädlichen Ausgaben bedeutet dies, dass wir die Ausgabe als Fehlerzustand betrachten und den Weg rückwärts über Prompt, Abruf (Retrieval), Generierung, Moderation und Auslieferung (Delivery) nachverfolgen, bis wir die kontrollierbaren Schwachstellen in der Kette finden.
Simuliert – Auszug aus dem Vorfallbericht:
Ein Mitglied fragt den Chatbot, ob es die Dosis verdoppeln darf, um einen versäumten Tag auszugleichen. Der Chatbot ruft allgemeine FAQs zu Medikamenten sowie einen Ausschnitt aus einem Community-Forum ab, der informelle Diskussionen zur Dosierung enthält. Das Modell antwortet mit bedingten Dosierungshinweisen und einer Warnung; die Benutzeroberfläche (UI) stellt diese ohne zusätzliche Kontrollinstanz dar. Es wird weder eine Ablehnungsmeldung ausgelöst, noch erfolgt eine menschliche Überprüfung.
Der entscheidende Schritt besteht darin, den Fehlerhergang in beobachtbare Systemereignisse zu unterteilen: Eine Benutzeranfrage ging ein, der Abrufprozess lieferte eine Mischung aus akzeptablem und unsicherem Kontext, das Modell generierte einen Ratschlag zu einem regulierten Thema, der Moderationsschritt blockierte oder leitete die Anfrage nicht um, und der Ausgabekanal präsentierte die Antwort als normalen Hilfeinhalt. Wir benötigen ein Bedrohungsmodell, da jeder dieser Schritte (Hops) unterschiedliche Telemetriedaten und Kontrollgrenzen aufweist.
Wir können diese Kette im Systemdiagramm konkret darstellen. Achten Sie bei der Durchsicht darauf, welche Komponente ein latentes Risiko in eine tatsächlich ausgelieferte Antwort umgewandelt hat. Ordnen Sie nun die Fehlerpunkte der Architektur zu:
Ein Kontrollpunkt ist eine Stelle im Ablauf von der Anfrage bis zur Antwort, an der eine Sicherheitsentscheidung auf der Grundlage einer Eingabe, einer Richtlinie und einer Durchsetzungsmaßnahme getroffen werden kann. Bei schädlichen Ausgaben ist es sinnvoll, Kontrollpunkte in die Phasen vor, während und nach der Generierung zu unterteilen, da jede Gruppe unterschiedliche Garantien bietet und mit unterschiedlichen Kosten für falsch-positive Ergebnisse verbunden ist.
Kontrollen vor der Generierung beeinflussen, was das Modell sieht. Dazu gehören die Filterung von Benutzereingaben, Einschränkungen beim Abruf (Retrieval) und Prompt-Vorlagen. Sie können die Wahrscheinlichkeit schädlicher Ausgaben verringern, aber keine Sicherheit garantieren, da harmlos erscheinende Eingaben zu unsicheren Vervollständigungen führen können und beim Abruf dennoch grenzwertige Texte zutage treten können, die im jeweiligen Kontext gefährlich sind.
Kontrollen während der Generierung steuern, was das Modell produzieren darf. Hier kommen Systemanweisungen, Richtlinien für Agenten-Tools und – sofern verfügbar – modellseitige Sicherheitsfunktionen zum Einsatz. Sie können das Verhalten zwar einschränken, hängen aber dennoch davon ab, dass das Modell die Anweisungen auch bei böswilligen oder mehrdeutigen Eingaben befolgt; zudem sind sie ohne systematische Tests schwer zu verifizieren.
Kontrollen nach der Generierung entscheiden darüber, was ausgeliefert und was weitergeleitet wird. Dazu gehören Klassifikatoren zur Moderation der Ausgabe, Positiv- und Negativlisten für risikoreiche Themen sowie Warteschlangen für die menschliche Überprüfung. Oft sind sie die einzige Stelle, an der sich garantieren lässt, dass unzulässige Texte nicht zum Benutzer gelangen; allerdings können sie die Latenz erhöhen, zu einer inkonsistenten Benutzererfahrung führen und eine disziplinierte Protokollierung erfordern, um im Bedarfsfall ihre Wirksamkeit nachzuweisen.
Garantien erfordern DurchsetzungEine Richtlinie allein ist noch keine Kontrollmaßnahme. Ein Kontrollpunkt existiert erst dann, wenn es eine durchsetzbare Entscheidung und einen überprüfbaren Nachweis (Audit Trail) gibt.
Ein weit verbreiteter Irrglaube ist, dass das Risiko schädlicher Ausgaben lediglich ein Problem der Modellqualität sei. In der Praxis ist das Modell jedoch nur eine Komponente in einem verteilten System. Dasselbe Basismodell kann in einem Triage-Workflow für medizinische Hotlines mit strenger Weiterleitung nach der Generierung akzeptabel sein, während es in einer Self-Service-Chat-Oberfläche ohne Filtermechanismen inakzeptabel ist, da der Auslieferungsweg Auswirkungen und Erkennbarkeit verändert.
Um die Kontrollpunkte operativ nutzbar zu machen, hinterlegen wir entsprechende Nachweise. Für jeden Punkt sollten wir beantworten können, welches Signal protokolliert, wo es gespeichert und wie es überprüft wird. Gehen Sie die Eingriffspunkte und die zu erwartenden Protokolle durch: