Mit der KI-Entwicklung Schritt zu halten, heißt nicht, mit den Unternehmen Schritt zu halten: Vorbereitung auf die KI-Regulierung

Michael MontoyaChief Technology Operations Officer | F5

In der Branche wird derzeit darüber diskutiert, wie schnell die Entwicklung von KI-Modellen an der technologischen Spitze voranschreiten sollte. Zusätzliche Dringlichkeit erhielt diese Debatte durch von Anthropic und OpenAI offengelegte Vorfälle, bei denen Modelle mit reduzierten Schutzvorkehrungen in Testumgebungen Handlungen ausführten, die weit über das von irgendjemandem Beabsichtigte hinausgingen. Sie griffen auf Systeme zu, von denen sie eigentlich abgeschottet sein sollten, und koordinierten sich über Instanzen hinweg, die voneinander isoliert sein sollten. Vor Kurzem plädierte Anthropic-CEO Dario Amodei zudem dafür, die Weiterentwicklung der Fähigkeiten solcher Spitzenmodelle bewusst zu steuern und unabhängige Prüfer direkt in den Laboren einzusetzen, um dies zu überprüfen.

Die Reaktionen auf diesen Vorschlag sind unterschiedlich ausgefallen. Die KI-Labore konzentrieren sich auf den Entwicklungsprozess: darauf, wie stark ein Trainingslauf die Fähigkeiten erweitert, wie gründlich ein Modell vor der Veröffentlichung evaluiert wird und ob Standards freiwillig eingehalten oder gesetzlich geregelt werden sollten. Andere argumentieren, dass sich die Grenzen des Machbaren in ihrem eigenen Tempo verschieben werden, dass der Rest der Welt nicht langsamer wird und dass Sicherheit in die Systeme rund um die Modelle integriert werden muss.

Ich werde diese Debatte hier nicht entscheiden, aber dabei fällt etwas Interessantes auf: Beide Lager sind sich einig, dass Kontrollmechanismen außerhalb des Modells angesiedelt sein sollten und die Überprüfung nicht allein denjenigen überlassen werden darf, die es entwickelt haben.

Das ist eine weiter gefasste Version des Arguments, das ich im Mai vorgebracht habe. Damals schrieb ich, dass sich die Sicherheitsgrenze bei KI auf den Inferenzpfad verlagert habe. Anwendungen rufen Modelle auf, Agenten nutzen Tools, und Modelle greifen auf andere Dienste zu, um Daten abzurufen, Workflows auszulösen und operative Aktionen durchzuführen. Meine Schlussfolgerung war, dass dieser Datenverkehr wie jede andere kritische Anwendungsinteraktion bereitgestellt, überprüft, authentifiziert und kontrolliert werden muss.

Das war ein architektonisches Argument, doch in den vergangenen Monaten ist daraus zunehmend auch eine Compliance-Frage geworden. Das Tempo an der Spitze bestimmt nicht das Tempo in den Unternehmen. Unabhängig davon, worauf sich Forschungslabore und Regierungen einigen: Die bereits veröffentlichten Modelle werden schon jetzt in unseren Organisationen eingesetzt, und die mit dieser Nutzung verbundenen Verpflichtungen nehmen bereits Gestalt an.

Meiner Erfahrung nach gibt es zwei Arten von Punkten auf einer Security-Roadmap. Da sind zum einen diejenigen, von denen man überzeugt ist, die aber mit allem anderen um das Budget konkurrieren und dabei manchmal den Kürzeren ziehen. Und dann gibt es diejenigen, die mit einem Termin versehen sind, zu denen ein Auditor Fragen stellen wird und für die es einen Eintrag im Risikoregister gibt. Schutzmechanismen für KI wandern gerade von der ersten in die zweite Kategorie – und wer lange genug in dieser Branche tätig ist, dem dürfte das bekannt vorkommen.

Was wir aus PCI DSS gelernt haben

Wir haben dieses Experiment schon einmal durchgeführt. Vor 2008 war die Sicherheit von Webanwendungen weitgehend ein Wunschbild – regelmäßige Code-Audits, statische Scans und die Disziplin der Entwickler sollten dafür sorgen. Dann kam die PCI-DSS-Anforderung 6.6, die Organisationen, die Karteninhaberdaten verarbeiten, dazu verpflichtete, entweder den gesamten Anwendungscode auf Schwachstellen zu prüfen oder eine automatisierte technische Schutzmaßnahme vor öffentlich zugängliche Anwendungen zu schalten.

Zwei Dinge daran sind mir besonders im Gedächtnis geblieben.

PCI DSS begann nicht als Gesetz. Der Standard entstand aus dem Bestreben der Branche, einer Regulierung zuvorzukommen. Er war ein vertraglicher Standard, der über Vereinbarungen mit Acquirern durchgesetzt wurde, und hat dennoch einen ganzen Markt umgestaltet. Wahrscheinlich sogar schneller, als es durch gesetzliche Regelungen möglich gewesen wäre, denn Verträge lassen sich schneller umsetzen als Gesetze. Das ist relevant, weil Unternehmen diesen Druck zunächst nicht von einer Aufsichtsbehörde zu spüren bekommen werden, sondern durch einen Sicherheitsfragebogen eines Kunden, eine Klausel im Beschaffungsvertrag oder einen Versicherer, der wissen möchte, welche Kontrollen ihren Modellen vorgeschaltet sind.

Und dann ist da noch die Frage, wie es endete. Mit PCI DSS v4.0 entfiel die Wahlmöglichkeit. Die Alternative einer Codeüberprüfung gibt es nicht mehr; gemäß Anforderung 6.4.2 ist nun eine automatisierte technische Lösung vorgeschrieben, die öffentlich zugänglichen Webanwendungen vorgeschaltet ist.

Heute fragt niemand mehr, ob die PCI-Compliance optional ist. Aus der Option wurde eine Anforderung.

Wo wir heute bei der KI-Regulierung stehen

Die regulatorische Schonfrist für KI ist vorbei. Das KI-Pendant zu PCI nimmt gleichzeitig auf mehreren Wegen und mit unterschiedlicher Geschwindigkeit Gestalt an. Am weitesten fortgeschritten ist die KI-Verordnung der EU. Ihre Verpflichtungen für Modelle mit allgemeinem Verwendungszweck werden bereits umgesetzt. Zwar hat die Europäische Union die Durchsetzung der Vorschriften für Hochrisiko-KI kürzlich auf Dezember 2027 verschoben, doch die Anforderungen an technische Robustheit, menschliche Aufsicht und Protokollierung sind bereits festgelegt. Unternehmen übersehen immer wieder, dass einige dieser Verpflichtungen sie selbst betreffen und nicht nur die Anbieter der Modelle. Wenn sie das Modell eines anderen Anbieters in einem Hochrisiko-Anwendungsfall einsetzen, tragen sie die Verantwortung.

In den USA gibt es bislang kein vergleichbares Gesetz, doch das NIST AI Risk Management Framework und das zugehörige Profil für generative KI haben sich zu einem Standard entwickelt, den viele als Maßstab für angemessene Sorgfalt heranziehen. Auf der Zertifizierungsseite übernimmt ISO/IEC 42001 eine ähnliche Rolle und taucht inzwischen sogar in Ausschreibungsunterlagen auf. Auf Ebene der Bundesstaaten wurden mehrere Gesetze mit unterschiedlichen Vorgaben zu Transparenz, Offenlegung und bestimmten Anwendungsfällen eingebracht, während die Aufsichtsbehörden für den Finanz- und Gesundheitssektor über szenariospezifische Leitlinien beraten.

Auch die OWASP Top 10 for LLM Applications gehören inzwischen zum Standardreferenzmaterial bei Sicherheitsprüfungen. Wenn ein Kunde einem Anbieter einen Fragebogen zu KI-Kontrollmaßnahmen schickt, stammen die Fragen sehr häufig aus dieser Quelle.

Betrachtet man all diese Vorgaben, taucht immer wieder dieselbe Anforderung auf: Es muss nachgewiesen werden, dass sich fortlaufend kontrollieren lässt, was in ein Modell einfließt und was es ausgibt, und dass sich dies im Nachhinein lückenlos belegen lässt.

Dies ist in erster Linie ein betriebliches Problem und erst danach ein Compliance-Problem.

Unser Bericht „State of Application Strategy 2026“ ergab, dass inzwischen 55 % der Anwendungsportfolios KI-gestützt sind und Unternehmen im Durchschnitt sieben Modelle in ihrem Inferenzpfad einsetzen. Mehr als die Hälfte (52 %) verknüpft oder orchestriert mehrere Modelle. Und 90 % gehen davon aus, dass sie Inferenzanfragen über eine gemeinsam genutzte Infrastruktur leiten werden.

Stellen Sie sich nun vor, ein Prüfer verlangt einen Nachweis dafür, dass eine einzelne Richtlinie – beispielsweise, dass keine personenbezogenen Kundendaten in der Ausgabe eines Modells enthalten sind – durchgängig eingehalten wird.

Diese Frage lässt sich nicht beantworten, indem man sieben Modelle einzeln konfiguriert. Erst recht nicht, wenn drei davon miteinander verkettet sind und die Ausgabe des einen als Eingabe für das nächste dient. Und die meisten Unternehmen, mit denen ich spreche, sind selbst davon noch einen Schritt entfernt, denn wenn sie sich auf die Suche machen, stoßen sie zunächst keineswegs auf ein selbst gehostetes Modell. Vielmehr kopieren Mitarbeitende sensible Daten in KI-Tools für Endverbraucher, während KI-Funktionen in bereits genutzten SaaS-Anwendungen unbemerkt aktiviert sind.

Nimmt man noch Agenten hinzu, ist nicht mehr der Prompt die Einheit, die kontrolliert werden muss, sondern die Aktion – der Tool-Aufruf, die API-Anfrage, der dadurch ausgelöste Workflow. Genau für diesen Kontrollpunkt haben wir in den vergangenen 20 Jahren Lösungen für den Anwendungsdatenverkehr entwickelt.

Diese agentische Fähigkeit befindet sich bereits in den Händen von Angreifern, die koordinierte Kampagnen mit Maschinengeschwindigkeit durchführen. Wie wir bereits bei der Bot-Abwehr gelernt haben, dürfen wir diesen Datenverkehr nicht länger danach beurteilen, wie ausgefeilt er wirkt, sondern müssen ihn anhand seiner Herkunft und seiner beabsichtigten Aktionen kontrollieren.

Guardrails müssen außerhalb des Modells angesiedelt sein

Unternehmen betreiben zunehmend eigene Modelle: Open-Weight-Modelle auf ihrer eigenen Infrastruktur, die mit ihren Daten feinabgestimmt wurden. Da es kein Sicherheitsnetz seitens des Anbieters gibt, tragen sie die volle Verantwortung für Betrieb und Compliance.

Die Prüfung jedes einzelnen Modells ist nicht skalierbar. Grundsätzlich lässt sich dies bei einem Dutzend Modellkonfigurationen noch bewerkstelligen. Ich habe Teams dabei beobachtet. Der Prozess ist manuell, bereits in dem Moment veraltet, in dem jemand einen neuen Endpunkt einrichtet, und liefert lediglich eine Momentaufnahme statt eines Kontrollmechanismus.

Alignment ist keine Sicherheitskontrolle. System-Prompts und Post-Training bieten eine nützliche Grundlage. Die Vorfälle bei OpenAI und Anthropic zeigen jedoch deren Grenzen auf. Dabei verfolgten Modelle ohne Schutzmechanismen ein eng umrissenes Ziel, stießen auf eine Grenze und umgingen sie. OpenAI hat erklärt, dass die Klassifikatoren in seinen standardmäßigen Kundenbereitstellungen die Aktivität als unsicher eingestuft hätten und dass die erweiterte Überwachung der Gedankenkette – wäre sie aktiv gewesen – das Sicherheitsteam alarmiert hätte, bevor die Modelle Hugging Face erreichten. Die allgemein verfügbaren Modelle von Anthropic verfügen über Klassifikatoren, die Ein- und Ausgaben in Echtzeit prüfen.

Beide Labore führten daraufhin umfangreiche Alignment-Maßnahmen durch, doch keines von ihnen hielt diese für ausreichend. Beide implementierten zudem Kontrollmechanismen außerhalb des Modells: Überwachungssysteme, die beobachten, was das Modell tut, und eine Aktion bewerten, bevor sie ausgeführt wird, wobei bei Bedarf ein Mensch hinzugezogen wird. Die Organisationen mit dem wohl umfassendsten Verständnis dieser Systeme kamen zu dem Schluss, dass die Kontrollinstanz außerhalb des Modells angesiedelt sein muss.

Wo man anfangen sollte

Angesichts der Richtung, in die sich die Regulierung entwickelt, und der Erkenntnisse aus den vergangenen zwei Jahrzehnten der Anwendungssicherheit darüber, wie solche Verpflichtungen auf uns zukommen, würde ich drei Dinge jetzt in die Wege leiten, anstatt abzuwarten.

1. Erfassen Sie die gesamte Angriffsfläche und beginnen Sie mit allem, was nicht autorisiert wurde: jedes produktiv eingesetzte Modell – SaaS-APIs, gehostete Endpunkte und selbstverwaltete Bereitstellungen von Open-Weight-Modellen – sowie die Schatten-KI.
2. Entkoppeln Sie die Durchsetzung vom Modell. Verankern Sie Richtlinien im Inferenzpfad statt in sieben separaten Modellkonfigurationen. Prüfen Sie, was hineingeht und was herauskommt, und setzen Sie die Vorgaben unabhängig vom jeweiligen Modell oder der jeweiligen Cloud einheitlich durch.
3. Erstellen Sie den Audit-Trail außerhalb des Systems, dessen Vorgänge er protokolliert. Erfassen Sie, was angefragt, was zurückgegeben und was blockiert wurde und wer was genehmigt hat. Stellen Sie sicher, dass er von einer Infrastruktur erzeugt wird, über die weder das Modell noch der Agent Kontrolle haben. Ermittler, die den OpenAI-Vorfall untersuchten, stellten fest, dass Agenten versucht hatten, die Aufzeichnungen über ihre eigenen Handlungen zu verändern. Wenn Ihre Aufzeichnungen von dem System erstellt werden, dessen Vorgänge sie dokumentieren, werden sie als nicht vertrauenswürdig gelten.

Entscheidend ist hier, dass KI-Governance nicht nur eine Dokumentationsaufgabe ist. Die Anforderungen an Unternehmen werden technischer Natur sein, fortlaufend gelten und belastbare Nachweise erfordern. Damit handelt es sich um eine Frage der Architektur und des Betriebs, die in den Zuständigkeitsbereich der Sicherheits- und Betriebsteams fällt – und nicht um eine Richtlinienfrage für Ihre Rechtsabteilung.

Wir sind der Ansicht, dass die Kontrolle in den Verarbeitungspfad gehört, nicht in die Modelle. Jedes Modell, das Ihr Unternehmen betreibt – ob SaaS-API, gehosteter Endpunkt, selbst verwaltetes Open-Weights-Modell, von Ihnen genehmigt oder noch unentdeckt – läuft im Inferenzpfad zusammen. Damit ist dieser der ideale Kontrollpunkt für all diese Modelle, um Richtlinien durchzusetzen und eine unabhängige, auditierbare Aufzeichnung zu erstellen.

Die Regeln werden noch ausgearbeitet

Niemand weiß, welche Anforderung das eigene Unternehmen letztlich zum Handeln zwingen wird – eine Verpflichtung aus dem EU AI Act, ein Landesgesetz, eine Branchenaufsichtsbehörde oder ein Kundenvertrag. Was ich jedoch weiß: Die technischen Definitionen innerhalb dieser Rahmenwerke stehen noch nicht fest. Was als angemessene Überwachung, ausreichende Robustheit oder akzeptable Dokumentation gilt, wird derzeit in Konsultationsverfahren, Normungsgremien und Verhaltenskodizes festgelegt.

Damit sind wir wieder bei der aktuellen Debatte über das Tempo der Entwicklung von KI-Modellen an der technologischen Grenze. Unabhängig von der inhaltlichen Bewertung möchte ich als jemand, der solche Systeme im Produktivbetrieb einsetzt, eine Beobachtung anführen: Unternehmen folgen einem anderen Zeitplan. Unabhängig davon, wie sich Forschungslabore, Regierungen und die Branche entscheiden, werden die bereits veröffentlichten Modelle in unseren Organisationen schon jetzt in großem Maßstab eingesetzt und genutzt – und die damit verbundenen Verpflichtungen sind sehr real. Sie werden Ihrem Aufsichtsrat, Ihren Führungskräften und Ihren Kunden weiterhin Antworten liefern müssen, ganz gleich, ob wir die Weiterentwicklung der Fähigkeiten verlangsamen oder nicht.

Diese Entscheidungen werden besser ausfallen, wenn sie auf den Erfahrungen von Menschen beruhen, die solche Systeme in großem Maßstab betrieben haben – die wissen, was sich tatsächlich durchsetzen lässt, welchen Preis eine Kontrollmaßnahme in Form von Latenz und Komplexität hat und wo eine gut gemeinte Regel zu Fehlanreizen führt. PCI DSS war erfolgreich, weil Fachleute aus der Praxis den Standard mitgestaltet haben. Wenn wir uns hier heraushalten, werden die Anforderungen trotzdem formuliert – nur eben von Menschen, die noch nie eine davon durchsetzen mussten.

Erfahren Sie mehr über den Ansatz von F5 zur KI-Sicherheit.

Über den Autor

Michael MontoyaChief Technology Operations Officer | F5

Michael ist für die unternehmensweite Strategie und deren Umsetzung verantwortlich, um Sicherheit und Resilienz fest im Kern der Geschäftstätigkeit zu verankern. Er leitet die Bereiche Security, Risk und Digital Operations bei F5 und sorgt für durchgängiges operatives Vertrauen bei Kunden, Partnern und Mitarbeitenden. Montoya trat im Oktober 2025 dem Executive Leadership Team von F5 bei, nachdem er von 2021 bis 2025 dem Board of Directors von F5 angehört hatte. Vor seiner Tätigkeit bei F5 war Montoya Chief Operating Officer bei BlueVoyant und zuvor Chief Information Security Officer bei Equinix und Digital Realty. Mehr als ein Jahrzehnt lang war er bei Microsoft in globalen Führungspositionen tätig, unter anderem als Chief Cyber Security Officer, als regionaler CIO/CISO für EMEA und Asien sowie in einer globalen Führungsrolle für den Rechenzentrumsbetrieb.

Weitere Blogbeiträge von Michael Montoya