Sicherheitskritische Sorgfalt in produktiver KI
Was ein reguliertes System sicher hält: Entscheidungen trifft Code, jede Grenze validiert, im Fehlerfall hält das System an, und alles Unumkehrbare bekommt eine Freigabe durch einen Menschen. Genau das fehlt den meisten produktiven Systemen mit Sprachmodellen.
Die Denkweise überträgt sich, die Zertifizierung nicht
Fünfzehn Jahre in regulierter, sicherheitskritischer Software trainieren einen bestimmten Reflex: Nimm an, dass die Komponente ausfällt, und baue so, dass ihr Ausfall ungefährlich ist. Im Automobilbereich nach ISO 26262 und ASPICE ist ein Defekt ein Rückruf und kein Bug-Ticket. Weil dort niemand darauf hoffen kann, dass ein Teil sich benimmt, wird von vornherein für den Fall gebaut, dass es das nicht tut.
Ein Sprachmodell ist eine probabilistische Komponente, also greift derselbe Reflex. Damit klar ist, was ich behaupte und was nicht: Übernommen wird die Denkweise, denn ein Sprachmodell nach einem Funktionssicherheitsstandard zu zertifizieren ist nicht möglich, und einen Sicherheitsnachweis dafür gibt es ebenso wenig.
Die Ingenieursdisziplin dahinter überträgt sich aber sehr wohl, und genau sie fehlt produktiven Systemen mit Sprachmodellen meistens: Entscheidungen trifft Code, jede Grenze validiert, im Fehlerfall hält das System an, und alles Unumkehrbare bekommt eine Freigabe durch einen Menschen.
Entscheidungen deterministisch, Lesen probabilistisch
Die klarste Regel, die ich anwende: Das Modell liest, der Code entscheidet. In einer Dokumenten-Pipeline extrahiert das Sprachmodell Fakten aus einer Rechnung, während die Frage, zu welcher Einheit sie gehört und wohin sie geleitet wird, regelbasiertes Python entscheidet und nie das Modell.
Eine probabilistische Komponente über etwas entscheiden zu lassen, das korrekt sein muss, heißt sie raten zu lassen. Also bekommt das Modell den unscharfen, menschlichen Teil, das Lesen, während der folgenreiche Teil, das Entscheiden, in Code bleibt, den man lesen und testen kann.
An der Grenze validieren
Probabilistische Komponenten scheitern leise. Deshalb wird jedes Ergebnis gegen ein striktes Schema geprüft, bevor es angenommen wird, und ein Validierungsfehler löst denselben Rückfall aus wie ein API-Fehler. Der gefährliche Ausfall ist nicht der Aufruf, der einen Fehler wirft, sondern die selbstbewusste, wohlgeformte und falsche Antwort. Eine Grenze, die nur prüft, ob überhaupt geantwortet wurde, verfehlt genau den Ausfall, auf den es ankommt.
Eine Freigabe für alles Unumkehrbare
In einer Content-Pipeline für eine Marke hat der Generator nie den Knopf zum Veröffentlichen, sodass alles, was er produziert, in einer Freigabeliste landet, aus der ein separater Prozess nur das veröffentlicht, was ein Mensch abgezeichnet hat. Auf den öffentlichen Kanälen einer Marke zu posten ist unumkehrbar, also gehört genau dort ein Mensch dazwischen.
Ein Generator, der veröffentlichen kann, ist ein Generator, der einen Fehler veröffentlichen kann. Trennen Sie die Rolle, die erstellt, von der Rolle, die freigibt.
Das ist dasselbe Prinzip wie ein Freigabe-Gate in sicherheitskritischer Arbeit: Das System, das eine Änderung erzeugt, ist nicht das System, das sie genehmigt. Es kostet einen menschlichen Handgriff, dafür kann eine einzelne schlechte Generierung nicht von allein an die Öffentlichkeit gelangen.
Was diese Sorgfalt kostet
Nichts davon ist umsonst: Eine Freigabe durch Menschen kostet täglich einen Handgriff, das Validieren vor dem Annehmen kostet die Latenz eines zweiten Aufrufs, und Entscheiden und Lesen zu trennen kostet bewegliche Teile.
Sorgfalt ist ein Kostenfaktor, den man bewusst zahlt, im Verhältnis dazu, 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 darüber, wie viel Sorgfalt ein bestimmtes System verdient, ist selbst die Erfahrung, die ich aus regulierter Arbeit mitbringe.