KI-Sicherheit ist vor allem Systemdesign

KI-Sicherheit ist vor allem Systemdesign

Das Sicherheitsmeeting nach der Demo

Die Demo war wie üblich gut verlaufen. Das Modell las einen Stapel interner Dokumente, beantwortete eine Frage zur Richtlinie, schlug einen nächsten Schritt vor und erstellte eine ordentliche Zusammenfassung für die Fallakte. Die Runde nickte. Jemand fragte, ob man es an das Workflow-System anschließen könne. Jemand anderes fragte, wie bald. Dann fragte der Sicherheitsbeauftragte, was passieren würde, wenn das Modell falsch, aber überzeugend läge. Der Raum wurde plötzlich sehr interessiert an den Keksen.

Mit dieser Frage beginnt praktische KI-Sicherheit. Nicht im Abstrakten und nicht in einem Slogan. Sondern in der Form des Systems um ein Modell herum, das manchmal falsch liegt, manchmal veraltet ist, manchmal zu selbstsicher, manchmal zu unsicher und manchmal aus dem falschen Grund richtig liegt. Das Sicherheitsproblem ist nicht nur das Verhalten des Modells. Es ist das, was das System diesem Verhalten erlaubt zu tun.

Ein Modell, das einen Satz entwirft, ist ein Risiko. Ein Modell, das eine Leistungsentscheidung aktualisiert, ist ein anderes. Ein Modell, das ein Tool mit Schreibzugriff aufruft, ist wieder ein anderes. Ein Modell, das einen Patienten weiterleitet, einen Anspruch ablehnt, ein Kreditlimit ändert oder Geräte steuert, gehört in eine völlig andere Gefahrenklasse. Dasselbe zugrunde liegende Modell kann harmlos, nützlich, riskant oder inakzeptabel sein, je nach Grenzen, Zustand, Evidenz, Befugnissen, Überwachung und Wiederherstellung. Deshalb ist KI-Sicherheit größtenteils Systemdesign.

Größtenteils trägt in diesem Satz Bedeutung. Modellforschung ist wichtig. Datenqualität ist wichtig. Alignment-Methoden sind wichtig. Evaluationswissenschaft ist wichtig. Aber wenn eine Organisation KI einsetzt, wird Sicherheit operativ. Wer fragen darf. Was das Modell sehen darf. Was es ändern darf. Welcher Nachweis erforderlich ist. Welcher Zustand erhalten bleibt. Was passiert, wenn Quellen sich widersprechen. Wann ein Mensch genehmigen muss. Wie Drift erkannt wird. Wie ein fehlerhaftes Release zurückgerollt wird. Das sind Designfragen, bevor sie Ethikaussagen sind. Die Ethikaussage mag aufrichtig sein. Das System führt Aufrichtigkeit nicht aus.

Sicherheit ist ein Kontrollproblem

Wenn Menschen Sicherheit hören, denken sie oft an Werte, Trainingsdaten, Ablehnungsrichtlinien und Modell-Alignment. Das ist Teil des Bildes, aber ein eingesetztes System braucht auch Kontrollen. Eine Kontrolle ist etwas, das verändert, was passieren kann: eine Zugriffsprüfung, ein Schema, ein Timeout, ein Schwellenwert, eine menschliche Genehmigung, eine Sandbox, ein Ratenlimit, ein Verifizierer, ein Rollback, ein Kill Switch, ein Datensatz, der vom Serving-Pfad nicht bearbeitet werden kann. Kontrollen sind langweilig, bis sie fehlen. Dann werden sie zum gesamten Meeting.

Ein sicheres KI-System geht davon aus, dass das Modell versagen kann, und gestaltet die umgebende Mechanik entsprechend. Es trennt Vorschlag von Handlung. Es begrenzt die Befugnisse der Werkzeuge. Es prüft Belege, bevor sich der Zustand ändert. Es macht Unsicherheit sichtbar. Es protokolliert Modellversion und Quellenumfang. Es verweigert die Arbeit, wenn Pflichtfelder fehlen. Es gibt den Bedienenden eine Möglichkeit, die Automatisierung zu pausieren. Es behandelt die Ausgabe des Modells als Kandidaten, nicht als Erlass einer sehr wortgewandten Tabellenkalkulation.

Das ist gewöhnliche Sicherheitstechnik mit einem Sprachmodell in der Mitte. Luftfahrt, Medizin, Bahn, industrielle Steuerung und Finanzwesen haben alle gelernt, dass wichtige Systeme mehrschichtige Kontrollen brauchen, weil keine Komponente perfekt ist. Die KI-Version fühlt sich neu an, weil die Komponente spricht. Sprache macht Versagen sozial überzeugend. Eine falsche Antwort, die ruhig klingt, kann an einer müden Bedienperson leichter vorbeigleiten als ein blinkender roter Fehler. Das Kontrolldesign muss daher störrischer sein als der Text.

Kontrolldesign beginnt mit der Frage, was das System beeinflussen darf. Wenn die KI nur entwerfen kann, konzentriert sich die Sicherheit auf Quellenqualität, Halluzinationsprüfungen, Klarheit der Benutzeroberfläche und Überprüfung. Wenn sie Arbeit weiterleiten kann, kommen Zustandsverfolgung, Warteschlangenintegrität, Service-Level und Beschwerdewege hinzu. Wenn sie Werkzeuge aufrufen kann, kommen Berechtigungsumfänge, Argumentvalidierung, Transaktionsprotokolle und ausgleichende Maßnahmen hinzu. Wenn sie Rechte oder physische Systeme beeinflussen kann, verlangt die Sicherheit Nachweise, formelle Überprüfung, eingeschränkte Autonomie und ernsthafte Störfallplanung. Das Modell ist der eine Teil. Die Befugnisgrenze ist der andere.

Die Grenze ist das Produkt

Die wichtigste Linie in einem KI-System ist oft in der Oberfläche nicht sichtbar. Es ist die Grenze zwischen Lesen und Schreiben, Empfehlen und Entscheiden, Zusammenfassen und Aufzeichnen, Unterstützen und Handeln. Schwache Grenzen sind der Weg, auf dem harmlose Prototypen zu unsicheren Diensten werden. Ein Modell, das als Entwurfshilfe beginnt, bekommt einen Knopf, um den Entwurf zu übernehmen. Dann bekommt es ein Werkzeug, um den Fall zu aktualisieren. Dann kommt eine Weiterleitungsregel hinzu, weil das Team beschäftigt ist. Sechs Monate später kann niemand mehr erklären, welche Entscheidungen automatisiert und welche nur unterstützt werden. Das ist keine Bosheit. Es ist eine schleichende Ausweitung des Aufgabenbereichs in bequemen Schuhen.

Gute Grenzen sind ausdrücklich und überprüfbar. Das Modell darf diese Quellen lesen, nicht jene. Es darf diese Felder vorschlagen, aber nicht festschreiben. Es darf dieses Werkzeug mit diesen Argumenten aufrufen, nicht mit beliebigem Text. Es darf risikoarme Fälle weiterleiten, nicht umstrittene Fälle. Es darf nur antworten, wenn die Belege aktuell sind. Es darf private Notizen nicht für öffentliche Erklärungen verwenden. Es darf nicht von einem Mandanten, einer Region, einem Konto oder einer Rechtsgrundlage in eine andere wechseln, nur weil der nächste Absatz hilfreich aussah.

Grenzen müssen auch außerhalb des Modells durchgesetzt werden. Eine Aufforderung, die sagt, schreibe nicht in die Kundendatenbank, ist keine Grenze, wenn das Werkzeug Schreibzugriff hat und kein Gateway dazwischenliegt. Eine Systemnachricht, die sagt, nenne Quellen, ist keine Grenze, wenn Antworten ohne Quellenangabe gespeichert werden können. Ein Policy-Absatz, der sagt, menschliche Genehmigung sei erforderlich, ist keine Grenze, wenn der Workflow der Automatisierung erlaubt, die Genehmigung selbst zu markieren. Sicherheitsanweisungen im Modell sind nützlich, aber sie reichen nicht aus. Das System muss unsichere Wege schwierig oder unmöglich machen.

Das ist die unromantische Arbeit, die Menschen tatsächlich schützt. Typisierte Werkzeugaufrufe. Enge Umfänge. Schreibgeschützte Standardeinstellungen. Getrennte Genehmigungsdienste. Idempotente Operationen. Prüfprotokolle. Versionierte Richtlinien. Warteschlangenzustände. Ausdrückliche Verweigerungszustände. Das Vokabular klingt, als hätte eine Backend-Entwicklerin ein ruhiges Wochenende mit einer Klemmbrettliste verbracht. Gut. Sicherheit in der Produktion sieht meistens so aus. Sie versucht nicht, einen Slogan-Wettbewerb zu gewinnen.

Der Zustand ist der Ort, an dem Sicherheit real wird

KI-Gespräche können Systeme zustandslos erscheinen lassen. Ein Nutzer fragt, ein Modell antwortet, der Bildschirm ändert sich. Produktion ist nicht zustandslos. Fälle bewegen sich. Tickets altern. Berechtigungen laufen ab. Dokumente werden korrigiert. Eine Modellversion ändert sich. Ein Mensch überstimmt eine Empfehlung. Ein Einspruch trifft ein. Ein Nutzer fragt, warum etwas letzten Monat passiert ist. Sicherheit hängt davon ab, ob das System den Zustand bewahrt hat, der für die Antwort nötig ist.

Der Zustand sagt dem System, was bereits geschehen ist und was als Nächstes geschehen darf. Ohne ihn sieht das Modell einen Ausschnitt und rät den Rest. So entstehen doppelte Aktionen, Fristen verschwinden, Genehmigungen werden angenommen und alte Belege gelangen in eine neue Entscheidung. Ein sicherer Arbeitsablauf hält explizite Zustände fest: Entwurf, Beleg fehlt, Richtlinie blockiert, Prüfung erforderlich, genehmigt, ausgeführt, angefochten, korrigiert, zurückgerufen. Diese Zustände sind nicht dekorativ. Sie verhindern, dass das Modell einen folgenreichen Prozess wie ein Chatprotokoll mit Ambitionen behandelt.

Der Zustand gibt Menschen auch Hebelwirkung. Ein Operator kann prüfen, warum ein Fall in der Prüfung ist. Ein Manager kann sehen, ob Automatisierung einen Rückstau erzeugt. Ein Prüfer kann abspielen, welche Quellversionen aktiv waren. Ein Nutzer kann ein Ergebnis mit etwas Soliderem als einem Screenshot anfechten. Ein Entwickler kann messen, ob ein neues Modell Ablehnungen, Eskalationen oder Nacharbeit erhöht. Ohne Zustand wird jedes Sicherheitsgespräch zum Theater. Menschen sprechen über Verantwortung, aber das System hat die Substantive verlegt.

Für KI sollte der Zustand Modell- und Richtlinienversion, Prompt- oder Vorlagenkennung, Quellsatz, Abrufzeitstempel, Tool-Aufrufe, Konfidenz oder Unsicherheit, Ablehnungsgrund, menschliche Handlung und nachgelagerte Wirkung umfassen. Nicht alles davon gehört in eine Protokollzeile, und nicht alles sollte für alle sichtbar sein. Datenschutz und Sicherheit sind wichtig. Aber die Informationen müssen unter kontrolliertem Zugriff existieren. Sonst wird Sicherheit vom Gedächtnis abhängig, und das Gedächtnis ist eine berüchtigt schlechte Datenbank mit hervorragenden Ausreden.

Belege sind die Sicherheitsschiene

Eine Modellantwort ist sicherer, wenn sie mit Belegen verbunden ist. Das klingt offensichtlich, bis das System unter Druck steht. Belege werden übersprungen, weil sie Latenz hinzufügen. Zitate werden als Text statt als Kennungen gespeichert. Abrufbewertungen werden nicht bewahrt. Quellversionen werden überschrieben. Das Modell schreibt eine selbstbewusste Erklärung aus einem Dokument, das inzwischen korrigiert wurde. Später fragt jeder, warum die Antwort falsch war. Die Antwort ist, dass die Schiene dekorativ war.

Brauchbare Belege sind keine Fußnote. Sie sind eine Kette. Die Anfrage kam mit einer Identität und einem Zweck herein. Quellen wurden mit Berechtigung ausgewählt. Die Abfrage fand bestimmte Textabschnitte oder Datensätze. Das Modell erzeugte eine Ausgabe unter einer benannten Version. Ein Prüfer verifizierte Behauptungen oder Schwellenwerte. Ein Mensch akzeptierte, bearbeitete oder lehnte ab. Die Aktion änderte einen Zustand. Das System speicherte genug von dieser Kette, um sie erneut abzuspielen oder anzufechten. Das ist keine Bürokratie um ihrer selbst willen. So überlebt Sicherheit die Zeit.

Belege schützen das Modell auch davor, zu unmöglicher Arbeit aufgefordert zu werden. Wenn das System aktuelle Quellen verlangt, kann das Modell veraltete Eingaben ablehnen. Wenn das System zwei übereinstimmende Datensätze verlangt, kann es Widersprüche kennzeichnen. Wenn das System Quellkennungen verlangt, kann es unbelegte Behauptungen stoppen. Das Modell muss fehlende Beweise nicht mehr in flüssiges Unsicherheitsmanagement verwandeln. Es kann einen sicheren Zustand zurückgeben. Das ist freundlicher zum Modell und viel freundlicher zu der Person, die von der Ausgabe betroffen ist.

Es gibt eine Balance. Die Erfassung von Belegen sollte keine Überwachung werden. Sensible Inhalte können gehasht, geschwärzt, getrennt oder nur für begrenzte Zeiträume aufbewahrt werden. Es geht nicht darum, alles für immer aufzuzeichnen. Es geht darum, die Fakten zu bewahren, die nötig sind, um wichtiges Verhalten zu prüfen. Sicherheit ohne Belege ist nur Vertrauen mit einer hübscheren Jacke. In der Lobby mag das gut aussehen. Bei einem Vorfall hält es nicht stand.

Menschen brauchen gestaltete Autorität

Human in the Loop wird oft als Zauberwort verwendet. Es ist kein Zauber. Eine müde Prüfperson mit schwachen Belegen, unklarer Richtlinie und einer Warteschlange von zweihundert Fällen ist kein Sicherheitssystem. Das ist eine Person, die ans Ende eines Fließbands gestellt wird und Governance sein soll. Es kann kurz funktionieren, besonders wenn die Person erfahren und hartnäckig ist. Es ist kein Design.

Menschliche Autorität muss konkret sein. Welche Fälle eine Prüfung erfordern. Welche Belege die Prüfperson sieht. Kann die Prüfperson strukturierte Felder ändern oder nur Prosa genehmigen. Weiß die Prüfperson, ob das Modell unsicher war oder ob die Richtlinie eine Eskalation verlangte. Werden Meinungsverschiedenheiten in die Auswertung zurückgespeist. Sind Prüfpersonen vor Automatisierungsbias geschützt. Können sie einen Arbeitsablauf anhalten. Können sie an eine Fachperson eskalieren. Können sie ähnliche frühere Fälle sehen. Können sie eine Entscheidung der betroffenen Person erklären. Diese Details entscheiden, ob menschliche Aufsicht echt oder nur Dekoration ist.

Gute Aufsicht trennt auch Urteilsvermögen von bürokratischer Aufräumarbeit. Menschen sollten ihre Zeit nicht damit verbringen, fehlende Quellkennungen zu finden, Wiederholungen zu bereinigen, Modellprosa in Workflow-Zustände zu übersetzen oder zu raten, welche Richtlinienversion galt. Das System sollte den Fall verpacken. Der Mensch sollte Urteilsvermögen dort anwenden, wo es nötig ist: bei strittiger Bedeutung, Ausnahmen, Verhältnismäßigkeit, Kontext, Empathie und Verantwortung. Wenn der Mensch hauptsächlich Infrastrukturlücken beseitigt, hat die Organisation Personal mit Sicherheit verwechselt.

Das Design muss es Menschen auch ermöglichen, der Automatisierung zu widersprechen, ohne dass Reibung zur Bestrafung wird. Wenn das Überstimmen des Modells acht Klicks erfordert und das Akzeptieren einen, hat die Schnittstelle eine Richtlinie. Wenn Eskalation ein Team langsam aussehen lässt, werden Menschen Eskalation vermeiden. Wenn Kennzahlen nur den Durchsatz belohnen, werden Sicherheitsüberprüfungen zur Zeremonie. Systemdesign umfasst Anreize, Bildschirme, Warteschlangen und Standardwerte. Das Modell kennt die Kennzahl vielleicht nicht, aber die Menschen ganz sicher.

Lokalität verändert Risiko

Wo KI-Arbeit stattfindet, ist wichtig. Ein System, das jedes Dokument an ein entferntes Modell sendet, hat andere Risiken als eines, das die Extraktion in der Nähe der Daten durchführt und nur ein abgeleitetes Feld sendet. Ein System, das Ablaufverfolgungen im Bereitstellungsdienst speichert, hat andere Risiken als eines, das unabhängige Prüfprotokolle führt. Ein System, das auf einen einzigen externen Router angewiesen ist, hat andere Wiederherstellungsoptionen als eines, das lokal herabgestuft werden kann. Lokalität ist kein Nationalismus mit einem Netzwerkdiagramm. Es ist die praktische Frage, welche Risiken sich bewegen, wenn Daten, Rechenleistung, Richtlinien und Beweise sich bewegen.

Einige Arbeiten sollten in der Nähe sensibler Daten stattfinden, weil das Bewegen der Daten eine Gefährdung schafft. Einige Arbeiten sollten in der Nähe der Benutzer stattfinden, weil Latenz die Sicherheit beeinflusst. Einige Arbeiten sollten in einem zentralen Dienst stattfinden, weil spezialisierte Überprüfung oder Hardware erforderlich ist. Einige Beweise sollten abseits des Modellbereitstellungspfads gespeichert werden, weil der Bereitstellungspfad möglicherweise das untersuchte Objekt ist. Das sichere Design ist selten alles lokal oder alles entfernt. Es ist eine bewusste Platzierung.

Lokalität betrifft auch rechtliche und organisatorische Verantwortlichkeit. Wenn ein Modellaufruf Regionen überschreitet, welches Recht regelt die Daten. Wenn ein Index außerhalb des Quellsystems aufgebaut wird, wie werden Löschungen weitergegeben. Wenn ein Anbieter ein Modell ändert, wie wird die Benachrichtigung empfangen und das Testen durchgeführt. Wenn Protokolle in einem Anbieterportal liegen, kann die Organisation sie während eines Vorfalls exportieren. Dies sind keine abstrakten Souveränitätsfragen. Es sind Sicherheitsfragen, weil sie bestimmen, ob die Organisation das System unter Stress kontrollieren und erklären kann.

Eine falsche Platzierung kann sicheres Verhalten teuer machen. Wenn jeder Verifizierungsschritt einen entfernten Hin- und Rückweg erfordert, können Teams Stichproben ziehen, anstatt jeden Fall zu prüfen. Wenn Prüfdaten schwer zu verknüpfen sind, werden Untersuchungen langsam. Wenn private Daten für eine einfache Klassifizierung reisen müssen, steigt das Risiko ohne Nutzen. Gutes Lokalitätsdesign reduziert die Kosten für das sichere Handeln. Das ist wichtig, weil Kontrollen, die zu teuer sind, irgendwann als optional beschrieben werden, und so beginnen viele schlechte Geschichten.

Evaluierung muss dem System folgen

Viele Teams evaluieren das Modell und vergessen, das System zu evaluieren. Sie testen, ob Antworten auf einer Reihe von Prompts korrekt sind, und setzen dann in einem Workflow mit Berechtigungen, Quellenfrische, Warteschlangen, Tool-Aufrufen, menschlicher Prüfung, Wiederholungen und sich ändernden Richtlinien ein. Der Modell-Benchmark mag weiterhin nützlich sein, aber er beschreibt nicht mehr das gesamte Risiko. Sicherheitsfehler liegen oft in den Verbindungsstellen.

Eine Systemevaluierung testet das End-to-End-Verhalten. Sie fragt, ob die richtige Quelle für den richtigen Nutzer abgerufen wird. Sie prüft, ob veraltete Daten abgelehnt werden. Sie verifiziert, dass Tool-Aufrufe ohne Berechtigung blockiert werden. Sie misst, ob Hochrisikofälle Menschen erreichen. Sie testet Rollback. Sie testet Warteschlangenverzögerung. Sie testet Modell-Upgrade-Pfade. Sie testet seltsame, aber alltägliche Fälle: fehlendes Datum, doppelter Kunde, Regionsausnahme, Einspruch nach Korrektur, Quellenlöschung, Teilausfall, überlasteter Prüfer. Die Produktion hat eine Vorliebe für die Fälle, von denen niemand dachte, sie seien dramatisch genug.

Evaluierung sollte negative Fähigkeit einschließen. Das System muss gut darin sein, Dinge nicht zu tun. Nicht ohne Belege zu antworten. Keine Berechtigungsgrenzen zu überschreiten. Nicht zur Aktion zu eskalieren, wenn nur Entwurf erlaubt ist. Unsicherheit nicht zu verbergen. Keine Quelle nach der Löschung zu nutzen. Nicht fortzufahren, wenn ein Tool einen inkonsistenten Zustand zurückgibt. Sicherheit hängt ebenso von Verweigerung und Innehalten ab wie von Genauigkeit. Die wichtigste Ausgabe eines sicheren KI-Systems könnte unzureichende Belege sein, ein Satz, den kein Demo-Team je auf ein Banner setzt.

Systemevaluierung verändert auch das Release-Management. Eine Prompt-Änderung, Modelländerung, Index-Neuaufbau, Richtlinienaktualisierung, Tool-Berechtigungsänderung oder Änderung der Prüferoberfläche kann die Sicherheit verändern. Jede benötigt einen Testumfang und einen Rollback-Plan. Das Team sollte wissen, welche Verhaltensweisen sich geändert haben und welche Risiken gestiegen sind. Das ist auf die Weise mühsam, wie Sicherheitsgurte mühsam sind. Es wird nur interessant, wenn es fehlt, und dann ist es für Trost zu spät.

Die Lektion

KI-Sicherheit ist größtenteils Systemdesign, weil Schaden meist durch Systeme reist. Eine Modellausgabe wird riskant, wenn ein Workflow ihr zu sehr vertraut, ein Tool-Gateway zu breit ist, Belege fehlen, der Zustand vage ist, die Prüfung überlastet ist, Protokolle schwach sind oder Rollback nur eingebildet ist. Das Modell mag die sichtbare Quelle des Satzes sein, aber das System entscheidet, ob der Satz zur Aktion wird.

Diese Sichtweise ist weniger dramatisch als viele Debatten über KI-Sicherheit und für Organisationen, die Systeme jetzt einsetzen, deutlich nützlicher. Sie fordert Teams auf, Grenzen zu ziehen, Zuständigkeiten zu benennen, Nachweise zu sichern, Zustände zu gestalten, Arbeit bewusst zu platzieren, Ende zu Ende zu evaluieren und Menschen echte Macht zu geben. Sie behandelt das Modell als leistungsfähige Komponente in einem Sicherheitsnachweis, nicht als den gesamten Sicherheitsnachweis. Das ist die erwachsene Haltung. Sie gibt Ingenieuren außerdem etwas zu bauen, das über ein weiteres Policy-PDF hinausgeht, was für alle freundlich ist.

Die Frage der Sicherheitsbeauftragten nach der Demo war genau richtig. Was passiert, wenn das Modell falsch liegt, aber überzeugend ist. Ein sicheres System sollte eine Antwort haben: Es kann hier nur einen Entwurf erstellen, es muss dort aktuelle Quellen zitieren, es darf dieses Tool nicht aufrufen, dieser Fall geht zur Überprüfung, diese Aktion hinterlässt eine Quittung, dieser Workflow kann pausiert werden, dieses Release kann zurückgerollt werden, diese Entscheidung kann angefochten werden. Diese Antworten sind keine Stimmungen. Sie sind Design.

Es wird in der KI immer Unsicherheit geben. Die praktische Aufgabe besteht darin, zu verhindern, dass aus Unsicherheit unbegrenzte Autorität wird. Das gelingt durch Schnittstellen, Zustände, Kontrollen, Nachweise, Lokalität, Evaluierung, Wiederherstellung und menschliches Urteilsvermögen, das angemessen ausgestattet ist. Mit anderen Worten: Systemdesign. Nicht weil Werte keine Rolle spielen, sondern weil Werte ausführbar gemacht werden müssen, bevor sie jemanden schützen können.