Sicherheit in der Generierung – Prüfpipelines für KI-Assistenten im Kundenkontakt

Mehr Prüfschichten bedeuten nicht mehr Sicherheit

Sobald ein KI-Assistent nach außen antwortet, im Kundenservice, im Support-Chat oder im Self-Service-Portal, steht jede Antwort im Namen des Unternehmens. Der verbreitetste Umgang mit den Sicherheitsbedenken, die daraus folgen, ist eine zusätzliche Prüfschicht. Das erhöht die Sicherheit nicht: Jede nachgelagerte Prüfung fängt nur ab, was vorher nicht gesteuert wurde, und ein Netz aus Prüfschichten wird mit jeder Prompt-Änderung durchlässiger. Eine Prüfstufe, die häufig greift, zeigt ein Steuerungsproblem in der Generierung an. Sie ist ein Symptom, keine Lösung.

Der Leitsatz dieser Lesson stammt aus einem realen Architektur-Review in einer stark regulierten Domäne: Sicherheit entsteht nicht dadurch, dass mehr geprüft wird, sondern dadurch, dass in der Generierung weniger schiefgehen kann. Prüfschichten sind Absicherung, keine Steuerung. Gesteuert wird dort, wo die Antwort entsteht.

Die Landkarte: Position 0 bis 4

Position 0 und 3 sind derselbe Mechanismus an unterschiedlichen Stellen, und sie werden regelmäßig verwechselt. Der Nachfilter schützt den Nutzer vor einer fehlerhaften Antwort. Der Vorfilter schützt die Daten des Nutzers vor dem System: Was er maskiert, gelangt nie in den Prompt, nie zum Modellanbieter und nie in die Logs. Dass er daneben auch plumpe Missbrauchsmuster abfängt, ist Kostenbremse, nicht Sicherheitsgrenze, mehr dazu in Step 2. Damit die Positionen greifbar bleiben, zieht sich ein Beispielsystem durch alle Steps: ein Leistungs-Assistent für ein Versicherungsportal. Er beantwortet Fragen zu Leistungen, Beträgen und Fristen, also genau die Mischung aus harmlos und haftungsrelevant, an der Sicherheitsarchitektur sichtbar wird. In fünf Schritten baust du seine Pipeline: das Grundmuster mit seinen Verträgen, den Vorfilter davor, das Risiko-Routing, den Freiheitsgrade-Regler und die drei Ausstiegspfade.

Wer einen Assistenten in einem regulierten Umfeld baut, landet fast zwangsläufig bei diesem Muster: prüfen, was hereinkommt, generieren, prüfen, was hinausgeht. Drei Stufen, drei getrennte Modellaufrufe. Das ist eine gute Grundfigur. Der häufigste Denkfehler liegt nicht im Muster, sondern in seiner Auslegung: Die dritte Stufe wird als die Sicherheitsmaßnahme behandelt und die zweite als reine Textproduktion.

Drei getrennte Aufrufe statt einem, aus drei Gründen:

1. Zielkonflikt-Entkopplung: „Sei maximal hilfreich“ und „mach keine verbindlichen Zusagen“ im selben Aufruf ist eine Regelkollision, und unter Druck gewinnt meist die Hilfsbereitschaft. Ein separater Prüfaufruf hat diesen Druck nicht.
2. Modellgröße: Drei fokussierte Durchläufe machen mit mittelgroßen Modellen messbar weniger Fehler als ein einzelner Aufruf, der klassifizieren, formulieren und prüfen gleichzeitig soll.
3. Auditierbarkeit: Drei Stufen erzeugen drei protokollierbare Zwischenergebnisse. In regulierten Domänen trägt oft genau dieses Audit-Argument die Entscheidung.

Die Übergabeverträge als Typen

Die Qualität der Pipeline steckt in den Übergabeverträgen, nicht in den Prompts. Zwei Verträge musst du festlegen: was der Guard an die Generierung übergibt, und was die Generierung an den Validator übergibt. Als TypeScript-Typen sehen sie so aus:

Der zweite Vertrag enthält die Stelle, die in Reviews am häufigsten fehlt: die Liste der tatsächlich genutzten Wissensbausteine. Ein Validator, der nur den Antworttext sieht, kann nicht prüfen, ob die Antwort gedeckt ist. Er kann nur beurteilen, ob sie plausibel klingt, und das ist genau die Eigenschaft, die du nicht willst. Erst mit den Quellbausteinen im Kontext wird aus einer Stilprüfung eine Deckungsprüfung.

Das Skelett der Pipeline

So sehen die drei Stufen orchestriert aus, und hier steckt die Korrektur zu Schwachstelle 1: Die harten Grenzen stehen zusätzlich im System Prompt der Generierungsstufe, nicht nur in der Prüfung. Nicht als einzige Absicherung, sondern damit die Absicherung selten greifen muss:

Achte auf das Retrieval: Der Guard liefert Themenkandidaten und Filterwerte, aber nicht die fertige Abfrage. Würde die Abfrage aus der Themenextraktion des Guards gebaut, entschiede ein Modell ohne Kenntnis der Wissensbasis darüber, welches Wissen geladen wird. Eine falsche Extraktion hieße falsches oder gar kein Wissen, und die Generierung merkt es nicht. Sie formuliert aus dem, was sie bekommt.

Pipeline-Diagramme beginnen üblicherweise mit der Eingangsstufe, und die ist ein Modellaufruf. Damit ist eine Entscheidung gefallen, die niemand bewusst getroffen hat: Der volle Rohtext der Nutzeranfrage geht an ein Modell, inklusive Versicherungsnummer, Klarname, IBAN und Gesundheitsangaben. Eine Verhaltensregel im System Prompt hilft dagegen nicht, denn sie greift erst, nachdem die Daten das Modell erreicht haben. Die Position davor arbeitet deterministisch: Regex und Musterlisten, bevor das erste Modell den Text sieht.

Was sich musterhaft erkennen lässt

Strukturierte Kennungen wie IBAN, Steuer-ID oder E-Mail-Adressen haben feste Formate, teils Prüfsummen. Diese Klasse erkennt ein Regex mit hoher Präzision. Was mit einem Fund passiert, ist dagegen keine technische Entscheidung, sondern eine Designentscheidung, und sie fällt pro Datenklasse:

Was Regex nicht kann

Für die dritte Zeile gibt es keine Vorfilter-Lösung: Gesundheitsangaben in Freitext („bei meiner Mutter wurde letzte Woche etwas festgestellt“) lassen sich musterhaft nicht erkennen. Wer sie erkennen will, braucht eine Modellklassifikation, und dann hat ein Modell die Daten bereits gesehen. Die Architektur kann diese Entscheidung nicht umgehen, sie kann sie nur explizit machen. Auch bekannte Injection-Formeln fängt der Vorfilter nur in der plumpen Variante. Er ist an dieser Stelle eine Kostenbremse, keine Sicherheitsgrenze. Die eigentliche Absicherung bleibt die positive Scope-Definition eine Stufe später.

Die Reihenfolge-Entscheidung

In regulierten Umfeldern ist die Protokollierung jedes Durchlaufs oft Freigabevoraussetzung. Ohne Vorfilter widerspricht sie der Datenminimierung: Wer den Rohrequest protokolliert, legt personenbezogene Daten in Logs ab, und Logs leben länger und liegen an mehr Stellen als Gesprächsverläufe. Die Auflösung ist eine Reihenfolgeentscheidung: Der Vorfilter läuft vor der Protokollierung. Ins Log kommt die maskierte Fassung plus die Information, welche Klasse maskiert wurde, nicht der Wert:

Das volle Muster aus Step 1 behandelt jede Anfrage gleich: Die Frage nach den Öffnungszeiten durchläuft dieselben drei Modellaufrufe wie die Frage nach dem individuellen Leistungsanspruch. Das kostet Latenz und Geld, und es verhindert Streaming, denn ein Validator, der die vollständige Antwort beurteilt, lässt den Nutzer mehrere Sekunden auf das erste Zeichen warten. Die entscheidende Größe ist deshalb nicht die Zahl der Prüfschichten, sondern die Freiheit, die die Generierung für die jeweilige Anfrage braucht. Je weniger Freiheit, desto weniger Prüfung.

Die vier Varianten

Auswahl in vier Fragen

1. Gibt es Haftungsrisiko oder Auditpflicht? Nein: Variante D genügt. Ja: weiter.
2. Ist das Modell in Größe oder Anbieter eingeschränkt? Ja: D scheidet aus, die Zerlegung kompensiert die Modellgrenze.
3. Sind Tonalität und Angemessenheit produktkritisch, oder geht es um korrekte Sachauskunft? Nur Sachauskunft: Variante A. Tonalität kritisch: Variante B.
4. Gibt es eine kleine Menge von Anfragen mit sehr hohem Risiko? Ja: für diese Variante C, für den Rest B.

Das Routing im Code

Alle Prüfarchitekturen aus Step 3 laufen einer Generierung hinterher, die zu viel darf. Der Gegenentwurf dreht die Richtung um: Was nie generiert werden kann, muss nicht abgefangen werden. Für die kritischsten Anfragen formuliert das Modell keine Fakten mehr. Es wählt aus freigegebenen Antwortbausteinen aus, ordnet sie und verbindet sie sprachlich. Die fachliche Prüfung wandert aus der Laufzeit in die Redaktion. Freiheit ist dabei kein Schalter, sondern ein Regler mit fünf Stufen:

Stufe 4 im Code

Die Redaktion pflegt dafür Antwortbausteine, nicht nur Wissensbausteine. Der Unterschied: Ein Wissensbaustein ist informationsdicht und tonlos, er weiß nicht, wer ihn liest. Ein Antwortbaustein ist eine freigegebene, an eine Person adressierte Formulierung, zwei bis fünf Sätze, mit Version und Freigabedatum:

Das Modell bekommt zur Laufzeit das Bedürfnis-Signal, die Kandidatenbausteine mit Metadaten und einen engen Auftrag: Wähle die passenden aus, bringe sie in eine sinnvolle Reihenfolge, füge Anrede und Übergänge hinzu. Formuliere keine Aussage, die nicht in einem gewählten Baustein steht. Die Ausgabe ist strukturiert, nicht Prosa, und damit wird die Prüfung trivial:

1. Frei mit Deckungsprüfung starten: Stufe 1 bis 2 aufbauen, deterministische Deckungsprüfung dahinter. Damit läuft das System.
2. Rückweisungen und Beschwerden auswerten: festhalten, welche Fragen Verstöße produzieren und welche häufig kommen.
3. Die Schnittmenge kuratieren: Für häufige und riskante Fragen Antwortbausteine erstellen und diese Anfragen auf Stufe 4 heben.
4. Rest auf Stufe 2 lassen: Die Prüfstufen bleiben für alles außerhalb der Kuration. So wächst die Kuration datengetrieben statt nach Vermutung.

Architekturdiagramme zeigen den Erfolgsfall. Was passiert, wenn die Anfrage nicht hierher gehört, das Wissen nicht reicht oder die Prüfung nicht besteht, taucht selten auf, obwohl diese Fälle zusammen einen erheblichen Teil des Verkehrs ausmachen. Ohne definierten Ausgang nimmt das System den einzigen Weg, den es kennt: Es antwortet trotzdem. Eine ungedeckte Antwort, die später als Halluzination auffällt, ist meist nicht das Ergebnis eines Modellfehlers, sondern einer fehlenden Alternative zum Antworten.

Ausgang 1: Scope-Guard

Der verbreitete Aufbau prüft Anfragen gegen eine Sperrliste unerwünschter Themen. Das Problem ist strukturell: Eine Sperrliste ist eine Liste dessen, woran man bisher gedacht hat. Sie wächst reaktiv, nach Vorfällen, und ist per Konstruktion immer unvollständig. Robuster ist die umgekehrte Logik, eine Zulassungsliste: Der zulässige Raum wird positiv definiert.

Ausgang 2: Abstain

Abstain, wörtlich „sich enthalten“, ist die bewusste Entscheidung des Systems, nicht oder nur teilweise zu antworten, weil das geprüfte Wissen nicht reicht. Es ist der wichtigste und am häufigsten fehlende Ausgang. Liefert das Retrieval nichts oder nur schwach Passendes und die Generierung läuft trotzdem, formuliert sie aus dem Allgemeinwissen des Modells. Die Antwort klingt kompetent, sie ist nur nicht gedeckt. Genau so gelangen die meisten ungedeckten Aussagen in geprüfte Systeme. Der Normalfall ist dabei der Teilabstain: Die allgemeine Regelung ist gedeckt, der individuelle Anspruch nicht. Die Architektur muss diesen gemischten Zustand können, sonst wird er auf „antworten“ gerundet. Eine gute Abstain-Antwort hat vier Elemente, in dieser Reihenfolge:

1. Was gesichert bekannt ist: Falls es einen gedeckten Teil gibt, kommt der zuerst.
2. Was offen ist, ohne Umschreibung: Nicht „dazu gibt es unterschiedliche Auffassungen“, sondern „das liegt mir nicht geprüft vor“.
3. Wohin: Eine konkrete Stelle, nicht „bitte informieren Sie sich“.
4. Was der Nutzer mitnehmen kann: Die Frage so formuliert, dass sie an der zuständigen Stelle direkt gestellt werden kann. Das ist der Unterschied zwischen einer Absage und einer Hilfestellung.

Ausgang 3: Fallback mit Wiederholungsbudget

Mehr als ein Wiederholungslauf lohnt nicht: Wird eine präzise benannte Beanstandung im zweiten Versuch nicht behoben, liegt das Problem meist nicht in der Formulierung, sondern in der Faktenlage oder im Prompt. Weitere Versuche kosten Zeit und Geld, ohne die Wahrscheinlichkeit deutlich zu erhöhen. Der Safe-Fallback ist kein generierter Text, sondern eine vorab freigegebene Antwort pro Beanstandungstyp, faktisch ein Baustein der Stufe 5 aus Step 4. Und er ist keine Blockade: Eine leere Antwort oder ein technischer Fehler wäre für den Nutzer der schlechteste aller Ausgänge.

Die Orchestrierung unten setzt jedes Artefakt dieser Lesson zusammen: den Vorfilter vor der Protokollierung, den Guard mit Signal, die Zulassungsliste, das eigenständige Retrieval mit Abstain, den Prüfplan aus der Risikoklasse, die Generierung mit Grenzen im Prompt, Nachfilter und Modellprüfung, das Wiederholungsbudget und den Safe-Fallback:

Die sechs Schwachstellen als Review-Checkliste

Die Steps haben sie einzeln eingeführt, hier stehen sie als Prüfliste für jede vorgelegte Architektur:

Die Regeln auf einen Blick