Warum KI die Sicherheit so viel schwerer gemacht hat

Deine Reaktion:

Stell dir vor, dein Unternehmen macht die ersten Schritte mit KI. Die Belegschaft ist begeistert, die Führung drückt aufs Tempo, jede Abteilung experimentiert. Die Finanzabteilung steckt vertrauliche Umsatzmodelle in öffentliche KI-Playgrounds. Die Personalabteilung lädt sensible Mitarbeiterdaten in externe Dienste hoch – ohne zu prüfen, wie lange die Daten dort bleiben. Für die Sicherheitsteams wird das zum Albtraum. KI hat die Unternehmenssicherheit härter gemacht – nicht durch neue, exotische Bedrohungen, sondern weil sie vorhandene Schwächen gnadenlos beschleunigt.

Der Autor ist kein KI-Gegner. Er nutzt die Technologie täglich, hält sie für transformativ und unvermeidlich. Aber er ist Pragmatiker. Jeder Technologieschub ändert nur die Gestalt der Probleme und verschiebt sie auf eine andere Architekturebene. Die rasche Demokratisierung von Large Language Models und autonomen Code-Agenten hat die Sicherheit in mehreren Punkten deutlich erschwert. Wir müssen über oberflächliche Verwundbarkeiten hinausblicken und die strukturellen Engpässe analysieren, die Sicherheitsteams zermürben.

Der Autor unterscheidet zwei Unternehmenstypen: solche mit ausgereifter KI-Infrastruktur und solche in der hektischen Experimentierphase. In reifen Unternehmen hat man gelernt, dass Nutzen und Risiken von KI variabel sind. Jede Bereitstellung wird geprüft: Datenherkunft, Modellgrenzen, Ausführungsebenen. Man weiß, ob ein Risiko die operative Reibung wert ist. In hyperoptimistischen Experimentierphasen herrscht eine gefährliche Anspruchshaltung. Die Führung ist überzeugt, dass die Vorteile von KI abstrakte Risiken automatisch überwiegen. Also wird uneingeschränkter Zugang gefordert – nicht nur von Entwicklern, sondern von jeder nicht-technischen Abteilung.

Diese Teams wollen die volle Erfahrung sofort. Jede Sicherheitsgrenze gilt als Bedrohung der Unternehmensgeschwindigkeit. Sie wollen die Schleusen öffnen und jeder internen Anwendung vollen Zugriff geben – ohne zu bedenken, dass der Datenzugriff einer KI abgeschottet werden muss. Granulare Identitäts- und Zugriffskontrollen brauchen Zeit. Optimistische, geschwindigkeitsbesessene Organisationen investieren diese Zeit nicht. Auf der Jagd nach einer reibungslosen Benutzererfahrung türmen sie strukturelle Risiken auf, bevor sie ihr erstes Produktionsfeature ausliefern.

Diese Reibung zeigt eine Asymmetrie des Scheiterns. Der Autor vergleicht die Bewertung eines autonomen Agenten durch ein Engineering-Team mit der Sicht eines CISOs. Ein Entwicklungsteam, dessen interner Agent zu 90 % erfolgreich Repositorys patcht oder Kunden-Tickets löst, feiert das als Triumph. Aus Produktsicht ist eine Fehlerrate von 10 % tolerierbar. Für einen CISO ist diese 10 %-Varianz eine katastrophale strukturelle Verwundbarkeit. Sicherheit verfolgt ein anderes Ziel: absolute Vermeidung von Systemversagen. Ein einziger unentdeckter Fehler oder eine halluzinierte Zugriffsgrenze reicht aus, um eine Datenpanne oder einen Betriebsvorfall auszulösen. Produktorientierte Organisationen können endlos experimentieren, weil sie nur einmal erfolgreich sein müssen. Ironischerweise nutzen Angreifer dasselbe Modell. Ein Gegner kann tausendmal scheitern, aber er muss nur eine lockere Prompt-Konfiguration finden, um zu gewinnen. Sicherheitsteams sitzen in der Zange: Sie müssen eine riesige, nicht-deterministische Angriffsfläche verteidigen und zu 100 % richtig liegen, während Entwicklerteams die Architektur aktiv bewaffnen.

Führungskräfte glauben oft, KI schaffe völlig neue Cyberbedrohungen. Der Autor argumentiert, KI erfindet selten neuartige Verwundbarkeiten. Stattdessen verstärkt sie bestehende schlechte Angewohnheiten, Architekturpraktiken und technische Schulden. Eine KI-Anwendung verhält sich wie ein Taschenrechner: Gibst du die falschen Zahlen ein, liefert sie eine falsche Antwort – um Größenordnungen schneller als ein Mensch. KI wendet diese mechanische Beschleunigung auf die Softwareentwicklung an. Wenn dein Team bereits unordentliche IAM-Konfigurationen oder schlechte Code-Review-Disziplin hat, vervielfacht KI diese Fehler sofort. Ein KI-Agent beurteilt keine Qualität. Er repliziert ein loses Berechtigungsmuster in Sekunden über Hunderte von Microservices. Das deckt latente Infrastrukturfehler auf und erzeugt eine massive Systemausbreitung, bevor ein Sicherheitsingenieur den ersten Commit-Log analysiert.

Angreifer nutzen diese Geschwindigkeitsdynamik. Sie setzen automatisierte Tools ein, um die maschinell erzeugte Ausbreitung zu kartieren und auszunutzen – schneller, als defensive Teams reagieren können. Es ist ein ermüdender Kampf gegen einen automatisierten Taschenrechner, der ständig die falschen Zahlen eingibt.

Weil die Technologie zu schnell für traditionelle defensive Frameworks ist, erleben wir eine schmerzhafte Umstrukturierung der Sicherheitsorganisation. Historisch wurden Sicherheitsteams mit einer Compliance-zuerst-Denkweise aufgebaut. Sie waren administrative Körper, die Kästchen ankreuzen, Audit-Logs sammeln und externe Anforderungen erfüllen. Selbst mit hochtechnischen Sicherheitsingenieuren fraß die Compliance-Maschine das Betriebsbudget. Da KI den Softwareentwicklungslebenszyklus einebnet, werden Engineering-Teams enorm gestärkt. Sicherheit kann Risiken nicht mehr durch administrative Richtlinien managen. Die Kluft zwischen Compliance und Engineering wird zu groß.

Um die Lücke zu schließen, spaltet sich die traditionelle CISO-Rolle in zwei Personas. Der compliance-fokussierte CISO wird zum Chief Compliance Officer, der externe Audit-Zyklen managt. Unternehmen holen echte Engineering-Leader als technische CISOs ins Boot – Menschen, die Plattformarchitektur verstehen. Ein neues Security Engineering Team entsteht als Puffer zwischen beiden Welten. Es übersetzt Compliance-Anforderungen in programmierbare Code-Guardrails, die Engineering verdauen kann. Dieser organisatorische Wandel ist unvermeidlich, macht den Sicherheitsjob kurzfristig chaotisch. Er sorgt für Prozessverwirrungen, stellt Eskalationswege auf den Kopf und lässt compliance-fokussierte Praktiker mit weniger Einfluss und Ressourcen zurück.

Diese Störung eröffnet eine Marktchance für Security-Startups. Die meisten KI-Sicherheitsanbieter leiden unter Tunnelblick. Sie bauen fortschrittliche Orchestrierungstools für Elite-Engineering-Teams. Aber diese Teams sind bereits kompetent und überlastet. Der unbediente Markt gehört dem Anbieter, der Software baut, die dem alten compliance-fokussierten Team hilft, sich mit KI in eine moderne Engineering-Einheit zu verwandeln. Ein schwieriges Produkt, dessen Gewinner-Oberfläche noch unklar ist. Wenn ein Startup unordentliche regulatorische Frameworks aufnehmen und elegante, versionierte Policy-as-Code-Konfigurationen ausgeben kann, die in Entwickler-Pipelines passen, erschließt es eine Elite-Kategorie von Unternehmensausgaben. Snyk schloss die Lücke zwischen Entwicklern und AppSec. Wiz verwandelte komplexe Cloud-Infrastruktur in einen priorisierbaren Risikographen. Der Gründer, der die Übersetzungsmaschine für die Compliance-Kluft baut, prägt das nächste Jahrzehnt der Enterprise-Security-Software.

KI hat die Sicherheit härter gemacht, weil sie die Illusion von Kontrolle zerstört hat. Wir können uns nicht länger hinter statischen Richtlinien oder manuellen Gates verstecken. Die Maschine des Unternehmens bewegt sich mit Runtime-Geschwindigkeit. Wenn unsere defensiven Frameworks nicht skalieren, bewachen wir einen leeren Perimeter. Hört auf, nach neuen, exotischen Bedrohungen zu suchen. Automatisiert eure grundlegenden Hygienepraktiken – das ist der Hebel, den KI zieht.

Quelle: franklyspeaking.substack.com

Deine Reaktion:
Artikel teilen:
Sebastian Krötzsch
Autor

Sebastian Krötzsch

Sebastian Krötzsch schreibt auf sebask.de über Künstliche Intelligenz, Automatisierung, digitale Systeme und die Frage, was davon im Alltag wirklich nützlich ist. Ohne Buzzword-Nebel, dafür mit klarem Blick auf Praxis, Tools und echte Wirkung.