Wenn ein auf einem großen Sprachmodell (LLM) basierendes System beginnt, mit echten Daten umzugehen oder einflussreiche Entscheidungen zu treffen, ist die Aussage „funktioniert meistens“ kein akzeptabler Maßstab mehr. Der Beitrag des Stack Overflow Blog schlägt im vierten Reifegradmodell für LLM-Systeme vor, Sicherheit und Governance direkt in die Architektur einzubauen – durch vier miteinander verbundene Praktiken: mehrere Schutzvorkehrungen, die Kontrolle personenbezogener Daten an jeder Systemgrenze, ein manipulationssicheres Auditprotokoll und einen klar begrenzten Speicher.
Mehrere Schutzvorkehrungen statt eines einzigen Schutzpunkts
Der Beitrag kritisiert, sich auf einen einzigen Filter für die Ausgaben des Modells zu verlassen, und schlägt vor, jede Schutzvorkehrung als kleinen Softwarevertrag zu gestalten, der unabhängig getestet und angeordnet werden kann. Anfragen durchlaufen Schichten, die die Eingabe und Versuche zur Anweisungsinjektion prüfen, Einschränkungen für Grounding und das Ausgabeformat kontrollieren, Ergebnisse von Richtlinienverstößen oder personenbezogenen Daten bereinigen, anschließend Geschäftsregeln validieren, für Fälle, die richtig erscheinen, aber falsch sind, ein sekundäres Urteil heranziehen und schließlich das Vertrauen bewerten sowie bestimmen, ob die Entscheidung ausgeführt wird oder eine Eskalation an einen Menschen erfordert.
Die zentrale Regel lautet „Fail-Closed“: Wenn eine Schutzvorkehrung ausfällt oder nicht verfügbar ist, darf die Anfrage nicht automatisch weitergeleitet werden. Außerdem sollte jeder Blockierungsvorgang als Betriebssignal protokolliert werden; ein plötzlicher Anstieg des Werts kann auf einen Angriff, eine Verschlechterung der Version oder einen Fehler bei der Bereitstellung hindeuten. Der Beitrag betont, dass die tatsächlichen Einschränkungen unzulässige Ausgaben nicht darstellbar machen sollten, anstatt sich lediglich auf Textanweisungen zu verlassen, die das Modell umgehen kann.
Personenbezogene Daten werden an den Grenzen verarbeitet
Jeder Übergang zwischen Systemkomponenten stellt eine Sicherheitsgrenze dar: die Eingabe von Daten, ihre Übermittlung an das Modell, das Schreiben in Protokolle oder das Entscheidungsprotokoll sowie die Weitergabe an einen anderen Dienst. Der Beitrag empfiehlt eine zentrale Klassifizierung der Sensibilität, wobei unbekannte Felder standardmäßig als personenbezogene Daten behandelt werden, und anschließend die Entfernung, Verschleierung oder Aufteilung der Daten, bevor jede Grenze überschritten wird.
Im Entscheidungsprotokoll sollte nicht die vollständige sensible Nutzlast gespeichert werden, um zu belegen, worauf die Entscheidung beruhte. Die Alternative ist eine bereinigte Zusammenfassung mit einem keyed Hash unter Verwendung von HMAC und einem mandantenspezifischen Schlüssel. Der Beitrag weist darauf hin, dass die Verwendung von einfachem SHA-256 bei Daten mit geringer Zufälligkeit, etwa einer E-Mail-Adresse oder Kartennummer, eine Rückwärtsbestimmung durch Raten ermöglicht. Außerdem ist eine kanonische und stabile JSON-Darstellung, beispielsweise nach der JCS-Spezifikation, erforderlich, damit eine erneute Hash-Berechnung dasselbe Ergebnis liefert.
Ein Auditprotokoll, das die Historie belegt, statt lediglich Protokolle aufzubewahren
Der Beitrag unterscheidet zwischen Betriebsprotokollen, die sich zur Fehlerbehebung eignen und möglicherweise rotiert oder unstrukturiert sind, und einem ausschließlich angehängten Auditprotokoll, das jede Entscheidung und ihre Begründung festhält. Dieses Protokoll umfasst die Identität der Entscheidung, den Mandanten, Berechtigungen, die Versionen von Modell und Prompt, Entscheidung und Vertrauenswert sowie den Routingpfad – zusätzlich zu einer bereinigten Zusammenfassung und gehashten Eingaben.
Korrekturen ändern den vorherigen Eintrag nicht, sondern erstellen einen neuen Eintrag, der auf den von ihm ersetzten Eintrag verweist. Um Manipulationen aufzudecken, werden die Einträge durch eine Hash-Kette verbunden, wobei die Reihenfolge und Vollständigkeit der Nummern überprüft werden. Die Kette allein verhindert jedoch weder das Löschen des Endes noch den vollständigen Wiederaufbau des Protokolls; daher schlägt der Beitrag vor, die Einträge zu signieren und regelmäßig Prüfpunkte in einem externen Speicher zu veröffentlichen. Außerdem muss das Anhängen unter einer Sperre erfolgen, damit zwei gleichzeitig ausgeführte Schreibvorgänge keine zwei Zweige der Kette erzeugen.
Klassifizierter Speicher und eine Trennlinie zwischen Ausgeliefertem und Erworbenem
In Systemen mit mehreren Mandanten wird der Speicher zu einer Frage der Data Governance und nicht bloß zu einem Feature. Der Beitrag schlägt getrennte Kategorien vor, etwa gemeinsames Wissen des Mandanten, Agentenbereich, temporärer Workflow-Kontext, Auditprotokoll, semantisches Wissen und Benutzerkonversation. Jede Kategorie verfügt über einen Zugriffsbereich, eine Sensibilitätsrichtlinie und einen Partitionierungsschlüssel, die im Datenspeicher selbst erzwungen werden, wobei jegliches mandantenübergreifendes Lesen oder Schreiben verhindert und die Konversation eines Benutzers von Entscheidungsagenten anderer Benutzer isoliert wird.
Der Beitrag unterscheidet außerdem zwischen Ausgangsdaten, die das Team ausliefert, etwa Prompts, Regeln, Testsammlungen und Grounding-Daten, und Betriebsdaten, die das System erwirbt, etwa Speicher, Abweichungssignale und Sitzungskontext. Erstere müssen versionskontrolliert und während des Betriebs unveränderlich sein, während Letztere innerhalb eines bestimmten Bereichs bereinigt werden können, ohne das Auditprotokoll zu löschen. Jedes neue Verhalten, das aus Betriebsdaten abgeleitet wird, sollte vor seiner Aufnahme in eine spätere Version eine Überprüfung und Tests durchlaufen; Lernen sollte laut dem Beitrag eher einem Softwareänderungsantrag gleichen als einem nicht nachvollziehbaren Nebeneffekt.
Warum sind diese Praktiken wichtig?
Der praktische Wert des Vorschlags liegt nicht in einem einzelnen Tool, sondern in der Verteilung des Vertrauens auf unabhängige Schichten. Die Bereinigung von Ausgaben ersetzt weder die Validierung von Geschäftsregeln, noch rechtfertigt ein Auditprotokoll die Aufbewahrung von Rohdaten, und der Speicher wird nicht allein dadurch sicher, dass eine Vektordatenbank verwendet wird. Zu den offenen Fragen, die weiterhin eine technische Entscheidung erfordern, gehören die Festlegung geeigneter Datenkategorien für jedes System, die Abstimmung von Richtlinien für Aufbewahrung und Zugriff, die Bestimmung der Fälle, die eine menschliche Überprüfung erfordern, sowie der Nachweis, dass die Bereinigung des Speichers keine für die Entscheidungsfindung notwendigen Eingaben entfernt.