Unternehmen setzen auf KI, ihre IT-Teams regulieren sie kaum Fünf Use Cases entscheiden über echte KI-Sicherheit

Anbieter zum Thema

Netskope Germany GmbH

cidaas by Widas ID GmbH

KI läuft in Unternehmen längst nicht mehr nur auf einer Ebene, sondern gleichzeitig bei Mitarbeitern, Entwicklern, eigenen Modellen und autonomen Agenten. Wer nur eine dieser vier Ebenen absichert, lässt die anderen drei offen, warnt Netskope in seinem aktuellen AI Risk and Readiness Report.

Das Governance-Problem ist bekannt. Laut dem 2026 AI Risk and Readiness Report haben 73 Prozent der Unternehmen KI-Tools bereits produktiv im Einsatz – aber nur 7 Prozent verfügen über eine Echtzeit-Governance, die Richtlinien auch technisch durchsetzt. 90 Prozent haben ihre KI-Sicherheitsbudgets erhöht. Dennoch fühlen sich 29 Prozent weniger sicher als zwölf Monate zuvor.

Das Paradox erklärt sich nicht durch mangelnde Investitionsbereitschaft, sondern durch eine strukturelle Fehldiagnose: Die meisten Sicherheitsstrategien behandeln KI-Risiko als ein singuläres Problem. In Wirklichkeit sind es fünf – mit jeweils eigenen Akteuren, Datenflüssen und Angriffsflächen. Wer sie alle mit demselben Werkzeug angeht, löst bestenfalls eines davon.

Drei Ansätze für sichere KI-Nutzung im Vergleich

KI-Sicherheit: Welcher Ansatz schützt wirklich?

Use Case 1: Mitarbeiter als KI-Nutzer – das Problem liegt eine Ebene tiefer

Die sichtbarste KI-Aktivität in Unternehmen ist die alltägliche Nutzung durch Mitarbeiter: Sprachmodelle für Zusammenfassungen, Recherchen, Textentwürfe, Codevorschläge. Dass diese Nutzung kontrolliert werden muss, ist Konsens - entsprechend viele Sicherheitsanbieter haben hier Antworten.

Die eigentliche Herausforderung liegt eine Ebene tiefer. 47 Prozent der Beschäftigten nutzen KI-Tools über private, nicht unternehmenskontrollierte Accounts. 88 Prozent der Sicherheits­teams können nicht zuverlässig zwischen einem autorisierten Unternehmens-Tenant und einem privaten Account auf derselben Plattform unterscheiden. Damit laufen DLP-Policies, Zugriffskontrollen und Audit-Trails ins Leere - nicht, weil sie fehlen, sondern weil die Grundlage fehlt, auf der sie wirken könnten.

Durchsetzung, die wirklich greift, operiert auf Instanzebene: Sie unterscheidet nicht nur, welche Anwendung genutzt wird, sondern über welches Konto – und passt Kontrollen in Echtzeit an. Entscheidend ist dabei der Kontext der Interaktion: Was wurde eingegeben? Welche Daten waren beteiligt? Was hat das Modell zurückgegeben? Nur wer diese Transaktionsebene versteht, kann sinnvoll coachen statt blind blockieren – und damit Sicherheit und Produktivität tatsächlich vereinbaren.

Netskope Threat Labs Report Europe 2026

Europas Unternehmen fehlt die Kontrolle über GenAI

Use Case 2: Entwickler als KI-Integratoren - ein anderes Sicherheitsproblem

Während die Diskussion um Nutzer-KI-Governance läuft, entsteht parallel ein Risikovektor, der deutlich weniger Aufmerksamkeit bekommt: Entwickler, die LLM-APIs direkt in Produktions­an­wen­dungen einbinden. Hier gibt es keine menschliche Eingabe im klassischen Sinne – sondern Anwendungen, die automatisiert Anfragen an externe Sprachmodelle stellen, deren Antworten verarbeiten und in Geschäftsprozesse einspeisen.

Das Sicherheitsproblem ist ein anderes: Welche Daten verlassen die eigene Infrastruktur in API-Calls? Welche Antworten werden unkritisch weiterverarbeitet? Wie werden Prompts kon­stru­iert, die vertrauliche Kontextinformationen enthalten? Klassische Sicherheitswerkzeuge, die für menschliche Interaktionen entwickelt wurden, sehen diese Schicht nicht.

Eine tragfähige Sicherheitsarchitektur für diesen Use Case setzt zwischen der Anwendung und dem externen Modell an – sie inspiziert API-Calls auf Inhaltsebene, erzwingt Richtlinien für ausgehende Datenanfragen und schützt vor manipulierten Modellantworten, die downstream Schaden anrichten. Das ist kein Gateway-Problem. Es ist ein Datenschutz- und API-Governance-Problem, das eine spezialisierte Infrastruktur erfordert.

KI-Sicherheit beginnt bei der Identität, nicht beim Netzwerk

KI-Lieferketten haben keinen Perimeter

Use Case 3: Unternehmenseigene Modelle – Sicherheit beginnt vor dem ersten Prompt

Immer mehr Unternehmen betreiben eigene, intern gehostete KI-Modelle – trainiert auf proprietären Daten, eingebunden in kritische Prozesse. Das verringert die Abhängigkeit von externen Anbietern, verlagert aber das Sicherheitsproblem vollständig in die eigene Verantwortung.

Zwei Zeitpunkte sind dabei entscheidend. Vor dem Deployment: Wurde das Modell auf Bias, ungewollte Verhaltensweisen und Schwachstellen gegenüber adversarialen Angriffen getestet? Red-Teaming für KI-Modelle – also das systematische Testen mit manipulierten Eingaben, Jailbreak-Versuchen und kontextverändernden Angriffen – ist fundamental anders als klassisches Penetration Testing, das bekannte Schwachstellen in Code und Infrastruktur sucht. KI-Red-Teaming zielt auf das Verhalten des Modells unter adversarialen Bedingungen ab.

Nach dem Deployment: Wie reagiert das Modell auf Prompt-Injection-Angriffe in der Produktion? Gibt es Schutzmechanismen, die schädliche oder manipulierte Inputs abfangen, bevor das Modell sie verarbeitet? Organisationen, die hier keine Antworten haben, nehmen ein Risiko in Kauf, das kein Netzwerk-Gateway je sehen wird.

Klassische Firewalls sind blind für Angriffe in natürlicher Sprache

Warum LLM-Guards allein die KI-Sicherheit nicht retten

Use Case 4: Autonome Agenten – wenn KI im Namen von Menschen handelt

Der Use Case, der am schnellsten an Bedeutung gewinnt und am wenigsten durch bestehende Sicherheitsarchitekturen abgedeckt ist: autonome KI-Agenten, die über das Model Context Protocol (MCP) auf Unternehmenssysteme zugreifen, Aktionen ausführen und im Namen autorisierter Nutzer handeln.

Die Realität in Unternehmen zeigt: Eine wachsende Mehrheit an Organisationen ist bereits mit konkretem Agenten-Risiko konfrontiert – und ein erheblicher Teil davon durch Shadow-Deployments, von denen die IT-Abteilung nichts weiß. Die Verteilung der Schreibzugriffe macht die Dimension des Problems deutlich. KI-Agenten verfügen in vielen Organisationen bereits über direkte Schreibrechte auf Kollaborationsplattformen, E-Mail-Systeme und – in einem kleineren, aber besonders sensiblen Bereich – auf Identity Provider, also auf die Systeme, die alle anderen Zugriffe kontrollieren.

Das Sicherheitsproblem ist strukturell: Ein Agent authentifiziert sich als autorisierter Nutzer, trifft nicht-deterministische Entscheidungen und kann durch Prompt-Injection manipuliert werden. Für Endpoint, Identity Stack und SaaS-Anbieter sieht jede Transaktion korrekt aus – und dennoch sind die meisten Organisationen nicht in der Lage, einen riskanten Agenten-Vorgang zu stoppen, bevor er abgeschlossen ist.

Wirksame Architektur für diesen Use Case setzt am Punkt der MCP-Kommunikation selbst an: Sie überwacht Agenten-Transaktionen in Echtzeit, unterscheidet zwischen sanktionierten und unsanktionierten Verbindungen und erzwingt Pre-Execution-Kontrollen für Aktionen mit Schreibzugriff – bevor der Agent handelt, nicht danach.

Netzverteidigung durch Reinforcement Learning neu denken

Autonome Netzwerk-Agenten lernen Verteidigung und Angriff

Use Case 5: Transparenz – Voraussetzung für alles andere

Die vier beschriebenen Phasen setzen alle eine Grundlage voraus, die in den meisten Unternehmen fehlt: eine vollständige, aktuelle Übersicht darüber, welche KI-Systeme überhaupt im Einsatz sind – genutzte Tools, eingebundene APIs, betriebene Modelle, aktive Agenten.

Nur 6 Prozent der Organisationen berichten von vollständiger Sichtbarkeit über alle KI-Aktivitäten in ihrer Umgebung. Damit treffen 94 Prozent KI-Sicherheitsentscheidungen auf Basis eines unvollständigen Bildes.

Diese Transparenzebene ist keine schöne Ergänzung, sondern die funktionale Grundlage jeder anderen Sicherheitskontrolle. DLP braucht Sichtbarkeit, um zu wissen, was es schützen soll. Governance braucht einen Katalog, um zu wissen, was sie regulieren muss. Red-Teaming braucht eine Inventarliste, um zu wissen, was es testen soll. Eine echte KI-Sicherheitsstrategie beginnt nicht mit der Frage „Wie blockieren wir Risiken?" – sondern mit der Frage „Was läuft überhaupt in unserer Umgebung?"

Eine integrierte Analytik- und Data-Security-Posture-Management-Schicht (DSPM), die alle fünf Phasen überspannt, beantwortet diese Frage kontinuierlich und aktuell – nicht als einmaliges Audit, sondern als permanente operative Grundlage.

Jailbreaking bedroht KI-Systeme in Unternehmen

Wie Unternehmen ihre KI gegen Manipulation absichern

Fazit: Integrierte Plattform statt isolierter Tools

Die Komplexität dieser fünf Phasen verdeutlicht, dass punktuelle Sicherheitslösungen an ihre Grenzen stoßen. Ein fragmentierter Ansatz führt zu Sicherheitslücken und administrativen Überlastungen. CIOs sollten daher auf Plattformen setzen, die von der Nutzerinteraktion am Endpoint bis hin zur autonomen Agentensteuerung im Rechenzentrum eine durchgängige Sichtbarkeit und Kontrolle bieten. Die Entscheidung für eine solche Architektur ist heute weniger eine Frage der Technologiepräferenz, sondern eine grundlegende Voraussetzung für die sichere digitale Transformation im Zeitalter der Intelligenz.

Über den Autor: Mathias Widler leitet als Vice President Central & Eastern Europe die Vertriebs- und Außendienst Teams in den schnell expandierenden Märkten bei Netskope. Widler verfügt über umfangreiche Erfahrungen im Sicherheits- und Netzwerkvertrieb. Bevor er zu Netskope wechselte, war Widler u.a. erfolgreich bei Zscaler und Palo Alto Networks tätig.

(ID:50919331)