Wenn die einzige Sperre ein Satz im Systemprompt ist

Die wichtigste Schutzvorkehrung eines KI-Systems stand nicht in der Konfiguration. Sie stand im Systemprompt. Ein Satz, sinngemäß: Das System darf keine Zahlungen auslösen. Auf die Frage, wo diese Regel technisch verankert sei, kam die Antwort, sie stehe doch da. Und sie stand da. Nur eben an der einzigen Stelle, an der sie nichts bewirkt.

Ich schreibe das ohne Alarm. Es ist kein Skandal und kein Beleg dafür, dass KI außer Kontrolle gerät. Es ist eine Verwechslung, und zwar eine, die man im Audit regelmäßig findet: Eine Absicht wird für eine Maßnahme gehalten. Der Unterschied ist der ganze Beruf.

Ein Prompt sitzt in derselben Schicht wie die Eingabe

Ein Systemprompt ist Text. Er wird dem Modell zusammen mit der Nutzereingabe vorgelegt, und das Modell verarbeitet beides in derselben Schicht. Es gibt darin keine Rangordnung, die von außen erzwungen wird. Anbieter geben dem Systemprompt mehr Gewicht, aber Gewicht ist keine Grenze. Wer in dieselbe Schicht schreiben kann, verhandelt mit derselben Stimme.

Genau deshalb lässt sich diese Art von Regel überreden. Nicht durch Zauberei, sondern weil sie als Sprache formuliert ist und Sprache mehrdeutig bleibt. Eine Anweisung im Prompt ist eine Bitte an ein statistisches System, sich in den allermeisten Fällen so zu verhalten. Für ein Werbebanner reicht das. Für eine Zahlung nicht.

Der Vergleich aus der Werkstatt: Ein Schild „Nicht hineingreifen“ an der Maschine ist sinnvoll und richtig. Es ersetzt trotzdem keine Schutztür mit Verriegelung. Niemand käme auf die Idee, das Schild als Schutzeinrichtung in die Gefährdungsbeurteilung zu schreiben. Bei KI-Systemen passiert genau das, ständig.

Der Vergleich trägt noch weiter, und zwar an der unangenehmen Stelle. Die Verriegelung an der Maschine hat einen Zustand, den man messen kann. Sie ist geschlossen oder offen, sie meldet sich an die Steuerung, und wenn jemand sie überbrückt, sieht man die Brücke. Ein Satz im Prompt hat keinen Zustand. Er ist entweder vorhanden oder nicht, und ob er im Einzelfall gewirkt hat, weiß hinterher niemand. Genau deshalb lässt sich seine Wirksamkeit nicht nachweisen, und genau deshalb trägt er im Audit nichts.

Es lohnt sich, an dieser Stelle sauber zu bleiben und nicht ins Dramatische zu rutschen. Ein Modell, das eine Prompt-Regel übergeht, bricht nicht aus, es rebelliert nicht und es entwickelt keine Absicht. Es hat schlicht eine andere Fortsetzung berechnet als die erwartete. Das ist kein Kontrollverlust, sondern der normale Betriebszustand eines statistischen Systems. Wer das als Aufstand erzählt, verkauft Angst; wer es als Nichtereignis abtut, übersieht die Folge. Die Folge ist banal und teuer zugleich: Auf eine Regel ohne Zustand kann man keine Zusage bauen.

Was in der Konfiguration stand, und was nicht

Konfigurationsprüfungen sind unspektakulär. Man lässt sich zeigen, welche Rechte der technische Benutzer hat, welche Schnittstellen erreichbar sind, welche Schutzfunktionen des Anbieters aktiv sind und wer das zuletzt geändert hat. Das dauert eine Stunde und beantwortet mehr Fragen als jedes Gespräch über Sicherheitskonzepte.

Was dabei häufig zusammenkommt, ist ein Muster aus drei Teilen. Erstens: Schutzfunktionen des Anbieters sind abgeschaltet, weil sie im Betrieb gestört haben. Zweitens: Der Netzzugang wurde absichtlich geöffnet, damit das System Daten nachladen kann. Drittens: Die Regel, die den Missbrauch verhindern soll, steht im Prompt. Jeder einzelne Schritt war nachvollziehbar begründet. Zusammen ergeben sie ein System ohne wirksame Begrenzung.

Der Befund lautet dann nicht, dass die Organisation nachlässig war. Er lautet, dass keine der drei Entscheidungen dokumentiert bewertet wurde. Es gibt kein Papier, auf dem steht, dass die Schutzfunktion abgeschaltet wurde, warum, wer das entschieden hat und was stattdessen greift. Das ist der Kern: nicht die Abschaltung, sondern die fehlende Entscheidung darüber.

Die Rechtelage ist dabei fast immer die aufschlussreichste Einzelfrage. Systeme, die für einen Versuch aufgesetzt wurden, laufen häufig unter einem technischen Benutzer, der aus einer anderen Anwendung geerbt wurde, weil das am schnellsten ging. Der Versuch geht in den Betrieb über, ohne dass jemand die Rechte zurückschneidet. Fragen Sie nicht, ob es ein Berechtigungskonzept gibt. Lassen Sie sich zeigen, was dieser eine Benutzer heute tatsächlich darf, und vergleichen Sie das mit dem, was das System können soll.

Der zweite ergiebige Griff ist die Frage nach dem Netzzugang. Ein KI-System, das Daten nachladen darf, holt sich Inhalte, die niemand geprüft hat, und verarbeitet sie in derselben Schicht wie seine Anweisungen. Ob das nötig ist, ist eine fachliche Entscheidung und keine technische. Sie gehört dokumentiert, mit der Angabe, welche Ziele erreichbar sein müssen und welche ausdrücklich nicht. Eine offene Verbindung ohne diese Liste ist keine Konfiguration, sondern ein Zustand.

Wer den Test bestehen will, schaltet die Kontrolle ab

Es gibt eine unangenehme Dynamik, die selten ausgesprochen wird. Wenn ein System eine Aufgabe erledigen soll und eine Schutzfunktion dabei im Weg steht, wird die Schutzfunktion abgeschaltet. Nicht aus Böswilligkeit, sondern weil das Ziel lautet, dass es läuft. Der Nachweis, dass das System die Aufgabe kann, entsteht dann unter Bedingungen, unter denen es später nie laufen soll.

Im Audit sieht man beides nebeneinander: das erfolgreiche Testprotokoll und die abgeschaltete Kontrolle. Beide sind echt. Nur belegt das Protokoll nicht das, was es zu belegen scheint. Es belegt, dass das System die Aufgabe ohne Schutzvorkehrungen erledigt. Über den produktiven Zustand sagt es nichts.

Ein Test, für den die Kontrolle abgeschaltet wurde, ist kein Nachweis für den Betrieb mit Kontrolle. Er ist der Nachweis, dass jemand die Kontrolle für hinderlich hielt.

Deshalb gehört zu jedem vorgelegten Testergebnis die Frage nach dem Stand, unter dem es entstanden ist. Welche Version, welche Konfiguration, welche Schutzfunktionen aktiv. Ohne diese vier Angaben ist ein Testbericht eine Momentaufnahme ohne Adresse. Er lässt sich weder wiederholen noch auf den Betrieb übertragen.

Vier Fragen, die den Unterschied sichtbar machen

Sie brauchen dafür kein technisches Spezialwissen. Sie brauchen vier Fragen, und Sie müssen die Antworten sehen wollen, nicht hören.

• Wo steht die Regel außerhalb des Modells? Zeigen Sie mir die Stelle in der Konfiguration, im Berechtigungskonzept oder im vorgelagerten Dienst.
• Was passiert, wenn das Modell die Regel ignoriert? Wenn die Antwort lautet, dass dann nichts passiert, ist die Regel keine Maßnahme.
• Welche Spur entsteht bei einem Verstoß? Ohne Eintrag im Protokoll ist ein Verstoß nicht feststellbar, und was nicht feststellbar ist, wird nicht bemerkt.
• Wer hat die letzte Änderung an dieser Konfiguration freigegeben, und wann? Eine Maßnahme ohne verantwortliche Rolle hat keinen Eigentümer.

Die zweite Frage ist die schärfste. Sie trennt die Bitte von der Sperre in einem Satz. Eine echte Maßnahme wirkt auch dann, wenn das Modell sich nicht daran hält, weil sie nicht im Modell sitzt. Ein Betragslimit im Zahlungsdienst greift, ganz gleich was der Agent vorhat. Eine Freigabe durch einen Menschen greift, ganz gleich wie überzeugend die Begründung des Systems klingt.

Was das praktisch heißt, ist unspektakulär und billig: getrennte technische Benutzer mit den kleinstmöglichen Rechten, Betragsgrenzen und Mengengrenzen außerhalb des Modells, eine Freigabe vor jeder Handlung mit Außenwirkung, und ein Protokoll, das Eingabe, Ausgabe und Stand mitschreibt. Nichts davon ist neu. Es ist derselbe Werkzeugkasten, mit dem seit Jahrzehnten Maschinen abgesichert werden.

Was der Anbieter absichert, und was Sie selbst absichern müssen

Ein Einwand kommt an dieser Stelle zuverlässig: Der Anbieter habe doch eigene Schutzmechanismen, und die seien besser als alles, was man selbst bauen könne. Das stimmt sogar oft. Es beantwortet nur eine andere Frage als die, die im Audit gestellt wird.

Die Schutzfunktionen eines Modellanbieters zielen auf die Ausgabe. Sie sollen verhindern, dass unerwünschte Inhalte entstehen. Sie sind nicht dafür gebaut, die Handlungen Ihres Systems zu begrenzen, denn diese Handlungen finden bei Ihnen statt, nicht beim Anbieter. Ob Ihr Agent eine Zahlung auslöst, eine Datei löscht oder eine Nachricht nach außen schickt, entscheidet Ihre Anbindung. Der Anbieter sieht davon nichts.

Dazu kommt ein Punkt, der im Vertrag steht und selten gelesen wird: Diese Schutzfunktionen werden vom Anbieter geändert, ohne dass Sie gefragt werden. Was heute blockiert wird, kann nach dem nächsten Modellwechsel durchgehen, und umgekehrt. Eine Maßnahme, deren Wirkung sich ohne Ihr Zutun verschieben kann, ist keine Grundlage für eine Zusage, die Sie Ihren Kunden gegeben haben.

Praktisch heißt das nicht, die Funktionen des Anbieters zu ignorieren. Es heißt, sie als zweite Schicht zu führen und nicht als erste. Die eigene Begrenzung liegt bei Ihnen, im Berechtigungskonzept, im vorgelagerten Dienst und in der Freigabe. Was der Anbieter zusätzlich abfängt, ist ein willkommener Zugewinn und kein Bestandteil Ihres Nachweises. Diese Reihenfolge ist der ganze Unterschied zwischen einer Architektur und einer Hoffnung.

Wo das in den Normen andockt

Der Anker liegt näher, als viele denken, und er liegt nicht in erster Linie in der KI-Norm. ISO/IEC 27001:2022 führt in Anhang A die Maßnahme A.8.9 Configuration management. Sie verlangt, dass Konfigurationen festgelegt, dokumentiert, umgesetzt, überwacht und überprüft werden. Eine abgeschaltete Schutzfunktion ohne dokumentierte Entscheidung ist damit unmittelbar angreifbar. Dazu kommen A.8.15 Logging und A.8.16 Monitoring activities für die Spur und ihre Auswertung.

In ISO/IEC 42001:2023 hängt derselbe Sachverhalt an mehreren Stellen von Anhang A. A.6.2.5 betrifft die Bereitstellung des KI-Systems, also den Übergang in den Betrieb und die Bedingungen, unter denen er stattfindet. A.6.2.6 betrifft Betrieb und Überwachung. A.6.2.8 verlangt die Aufzeichnung von Ereignisprotokollen. A.9.2 und A.9.4 adressieren die Prozesse für die verantwortungsvolle Nutzung und die bestimmungsgemäße Nutzung des Systems.

Die Feststellung wird dabei nicht gegen den Prompt geschrieben. Sie wird gegen die Klausel oder die Maßnahme geschrieben, die verletzt ist, und der Prompt ist der Nachweis. Wer im Bericht formuliert, der Systemprompt sei unzureichend, hat den falschen Gegenstand gewählt. Unzureichend ist die Maßnahmenlage, und der Prompt zeigt es.

Und noch etwas gehört dazu, weil es sonst nach Verbot klingt: Ein Systemprompt ist ein gutes Werkzeug. Er formt Ton, Format und Arbeitsweise, und er gehört zu einem sauber gebauten System dazu. Er ist nur kein Ersatz für eine Grenze. Beides gleichzeitig zu sagen, ist keine Relativierung. Es ist die Voraussetzung dafür, dass die Unterscheidung überhaupt jemandem nützt.