Sicherheitskritische Strenge in produktiver KI

Die Denkweise überträgt sich; die Zertifizierung nicht

Vierzehn Jahre in regulierter, sicherheitskritischer Software trainieren einen bestimmten Reflex: Nimm an, dass die Komponente ausfällt, und konstruiere so, dass ihr Ausfall sicher ist. Im Systems Engineering im Automobilbereich nach ISO 26262 und ASPICE ist ein Defekt ein Rückruf, kein Bug-Ticket — man darf also nicht hoffen, dass ein Teil sich benimmt; man konstruiert für den Fall, dass es das nicht tut.

Ein LLM ist eine probabilistische Komponente. Der Reflex gilt direkt. Um klar zu sein, was ich behaupte und was nicht: Hier wird die Denkweise übernommen, nicht ein LLM nach einem Funktionssicherheits-Standard zertifiziert. Es gibt keinen Sicherheitsnachweis für ein Sprachmodell. Aber die Ingenieurs-Disziplin — deterministische Entscheidungen, Validierung an jeder Grenze, fail-safe Voreinstellungen und ein Mensch in der Schleife für alles Unumkehrbare — ist genau das, was produktiven LLM-Systemen meist fehlt.

Deterministische Entscheidungen, probabilistisches Lesen

Die klarste Regel, die ich anwende: Das Modell liest, deterministischer Code entscheidet. In einer Dokumenten-Pipeline extrahiert das LLM Fakten aus einer Rechnung, aber es entscheidet nie, zu welcher Entität die Rechnung gehört oder wohin sie geleitet werden soll — das ist regelbasiertes Python. Eine probabilistische Komponente eine Entscheidung treffen zu lassen, die korrekt sein muss, heißt, sie raten zu lassen. Nutze das Modell für den unscharfen, menschlichen Teil (Lesen); halte den folgenreichen Teil (Entscheiden) in Code, den du lesen und testen kannst.

An der Grenze validieren

Probabilistische Komponenten scheitern leise. Daher wird ein Ergebnis gegen ein striktes Schema validiert, bevor es akzeptiert wird, und ein Validierungsfehler — nicht nur ein API-Fehler — löst einen Fallback aus. Der gefährliche Ausfall ist nicht der Aufruf, der einen Fehler wirft; es ist die selbstbewusste, wohlgeformte Antwort, die falsch ist. Eine Grenze, die nur prüft „hat es geantwortet?", verfehlt genau den Ausfall, der zählt.

Eine menschliche Schleuse für unumkehrbare Aktionen

In einer markenbezogenen Content-Pipeline hält der Generator nie den Veröffentlichen-Knopf. Alles, was er produziert, landet in einer Freigabe-Queue, und ein separater Prozess veröffentlicht nur, was ein Mensch freigegeben hat. Auf die öffentlichen Kanäle einer Marke zu veröffentlichen ist unumkehrbar — also gehört genau dorthin ein Mensch.

Ein Generator, der veröffentlichen kann, ist ein Generator, der einen Fehler veröffentlichen kann. Trenne die Rolle, die erstellt, von der Rolle, die freigibt.

Das ist dasselbe Prinzip wie ein Release-Gate in sicherheitskritischer Arbeit: Das System, das eine Änderung erzeugt, ist nicht das System, das sie autorisiert. Die Kosten sind ein menschlicher Kontaktpunkt; die Versicherung ist, dass eine einzige schlechte Generierung nicht von allein an die Öffentlichkeit gelangen kann.

Die Kosten der Strenge, ehrlich benannt

Nichts davon ist umsonst. Ein menschlicher Freigabeschritt fügt einen täglichen Kontaktpunkt hinzu. Validieren vor dem Akzeptieren fügt die Latenz eines zweiten Aufrufs hinzu. Entscheidung vom Lesen zu trennen fügt bewegliche Teile hinzu. Strenge ist ein Kostenfaktor, den man bewusst zahlt, im Verhältnis zu dem, was ein Ausfall tatsächlich kostet — eine falsche Rechnung in den Büchern und ein falscher Post in einem öffentlichen Feed rechtfertigen sie beide; ein risikoarmer interner Entwurf vielleicht nicht. Das Urteil, wie viel Strenge ein gegebenes System verdient, ist selbst die Erfahrung, die ich aus regulierter Arbeit mitbringe.