Ein Modell unterscheidet Anweisung und Inhalt nicht

Was die Rolle im Alltag tatsächlich tut

Der größte Teil der Arbeit sieht aus wie Anwendungssicherheit, nur mit anderen Annahmen. Es geht um Berechtigungen, um Trennung von Mandanten, um Netzzugriffe, um Zugangsdaten und um die Frage, was ein System darf, wenn es sich unerwartet verhält. Der Unterschied liegt darin, dass eine der Komponenten nicht deterministisch ist und dass eine Eingabe aus einer Datenquelle stammen kann, die niemand als Eingabe betrachtet hat.

Ein wiederkehrender Arbeitsblock ist die Bedrohungsbetrachtung für einen konkreten Anwendungsfall. Welche Daten fließen in den Kontext, wer darf sie sehen, welche Werkzeuge hängen daran, was passiert im schlechtesten Fall, und was davon lässt sich technisch verhindern statt nur zu erkennen. Diese Betrachtung ist der Punkt, an dem eine Rolle wie diese Wert schafft, und sie gehört vor die Entwicklung und nicht hinter sie.

Der zweite Block ist das Testen. Es gibt inzwischen gut dokumentierte Angriffskategorien, an denen man sich entlanghangeln kann: eingeschleuste Anweisungen, Abfluss vertraulicher Informationen über den Kontext, zu weit gefasste Handlungsbefugnis von Agenten, manipulierte Trainings- oder Suchdaten, Schwächen in Vektorspeichern und Angriffe über den Verbrauch. Die frei verfügbaren Übersichten der OWASP zu Anwendungen mit Sprachmodellen und die Sammlung von MITRE zu Angriffen auf KI-Systeme sind dabei der übliche Ausgangspunkt.

Was nicht zur Rolle gehört, ist die Governance. Wer für die Einhaltung der Pflichten aus der europäischen KI-Verordnung sorgt, Risikoklassen einordnet und Dokumentationspflichten steuert, hat eine andere Aufgabe. Diese beiden Rollen müssen eng zusammenarbeiten, aber sie sind nicht dieselbe, und in Häusern, die sie zusammenlegen, leidet meist die technische Seite.

Eine Rolle, die sich gerade erst formt

Es gibt für dieses Feld keinen Ausbildungsberuf, keinen Studiengang mit diesem Namen und keine etablierte Zertifikatskette, die von Arbeitgebern breit verlangt wird. Wer heute behauptet, es gäbe einen üblichen Karriereweg dorthin, beschreibt eine Wunschvorstellung. Die Stellen entstehen fast immer aus einer konkreten Not heraus: Ein KI-Projekt läuft in die Sicherheitsprüfung, niemand kann die Fragen beantworten, und jemand im Haus übernimmt das Thema.

Die Leute kommen aus vier Richtungen. Aus der Anwendungssicherheit, weil dort Bedrohungsbetrachtung, Berechtigungen und Prüfung von Eingaben ohnehin das Handwerk sind. Aus dem Sicherheitsbetrieb, weil dort Erkennung und Vorfallsbearbeitung sitzen. Aus der ML- und Datenentwicklung, weil dort das Verständnis für Modelle, Einbettungen und Auslieferung liegt. Und aus der Plattform- und Cloud-Entwicklung, weil ein großer Teil der Absicherung aus Identitäten, Netzen und Rechten besteht.

Jede dieser Herkünfte bringt eine typische Lücke mit. Wer aus der Sicherheit kommt, unterschätzt regelmäßig, wie sehr Nichtdeterminismus die Prüfung verändert, und behandelt ein Modell wie eine Bibliothek mit fester Ausgabe. Wer aus der ML-Seite kommt, unterschätzt Rechte, Netztrennung und Zugangsdaten und traut technischen Schutzmaßnahmen im Modell selbst zu viel zu. Die Rolle wird von denen gut ausgefüllt, die ihre eigene Lücke kennen und gezielt geschlossen haben.

Statt Zertifikaten gibt es derzeit Referenzwerke, und die sind frei zugänglich. Die OWASP führt eine Liste der zehn wichtigsten Risiken für Anwendungen mit Sprachmodellen, MITRE sammelt in einer eigenen Wissensbasis Techniken für Angriffe auf KI-Systeme, und das NIST beschreibt in seinem Rahmenwerk für KI-Risiken das Vorgehen auf Organisationsebene. Wer diese drei durchgearbeitet und an einer eigenen Anwendung angewendet hat, ist weiter als jemand mit einer Prüfungsbescheinigung.

Woran du wächst, und was den Unterschied macht

Der erste Unterschied liegt in der Fähigkeit, Sicherheit nicht als Blockade zu formulieren. Ein Anwendungsfall, der abgelehnt wird, kommt als Schatteneinführung zurück, und dann ist er außerhalb jeder Kontrolle. Wer stattdessen eine engere Variante anbietet, die den fachlichen Zweck erfüllt, wird beim nächsten Vorhaben früher gefragt. Das ist in einem so neuen Feld wichtiger als in einem etablierten, weil die Fachbereiche gerade schneller sind als die IT.

Der zweite Unterschied ist Messbarkeit. Es gibt Leute, die zu einer Anwendung sagen, sie sei anfällig für eingeschleuste Anweisungen, und solche, die eine Testsammlung haben und sagen können, wie viele von hundert Angriffsversuchen durchkommen und wie sich der Wert nach einer Änderung verschoben hat. Nur die zweite Aussage lässt sich in eine Entscheidung übersetzen.

Der dritte Unterschied ist die Breite. Diese Rolle liegt an der Schnittstelle von Modell, Anwendung, Identität, Netz und Recht. Wer nur eine dieser Ecken kennt, wird zum Zulieferer. Wer die Übersetzung zwischen ihnen leistet, wird zu der Person, die im Haus entscheidet, ob ein Vorhaben tragbar ist. Genau diese Übersetzungsleistung ist derzeit knapp und der Grund, warum es diese Stellen überhaupt gibt.

Wohin sich die Rolle entwickeln dürfte

Absehbar ist, dass sich das Feld aufteilt. Ein Zweig geht in die Absicherung der Modelle und ihrer Lieferkette: woher Gewichte stammen, wie Anpassungen nachvollziehbar bleiben, wie manipulierte Trainingsdaten auffallen. Ein zweiter Zweig geht in die Absicherung von Agenten im Betrieb, also in Rechte, Freigaben und Überwachung von Systemen, die selbstständig handeln. Ein dritter bleibt bei der Anwendungssicherheit und behandelt Sprachmodelle als eine weitere Komponente unter vielen.

Ebenfalls absehbar ist, dass die Erkennung nachzieht. Sicherheitsbetriebe fangen an, Anfragen und Werkzeugaufrufe von Agenten wie sicherheitsrelevante Ereignisse zu behandeln, und daraus entstehen dieselben Aufgaben, die es für andere Systeme längst gibt: Erkennungsregeln, Alarmierung, Untersuchung. Wer heute aus dem Sicherheitsbetrieb kommt, hat dort den kürzesten Weg.

Offen ist die Frage der Nachweise. Es ist gut möglich, dass sich in den nächsten Jahren Prüfungen etablieren, die von Arbeitgebern verlangt werden, und ebenso möglich, dass es bei Referenzwerken und Arbeitsproben bleibt, wie es in der offensiven Sicherheitsarbeit lange der Fall war. Wir schreiben hier nicht auf, was sich durchsetzen wird, sondern was heute gilt: Gefragt wird nach dem, was du an einer echten Anwendung gebaut, getestet und begründet hast.