AI-Tools werden in Unternehmen längst nicht mehr nur „testweise“ genutzt. Mitarbeitende automatisieren damit Abläufe, koordinieren Aufgaben und optimieren Entscheidungen – häufig mit Anwendungen, die IT geprüft hat. Doch ein großer Teil passiert über private Konten oder Browser-Erweiterungen, die in der Security-Welt weder sichtbar noch freigegeben sind. Genau hier entsteht ein Spannungsfeld: Wie kann man Innovation ermöglichen, ohne das Risiko für sensible Daten und Unternehmenswissen auszuweiten?
Ein bewährtes Sicherheitsmuster besteht darin, eingesetzte SaaS-Apps zu entdecken, den Zugriff zu steuern und mit DLP-Regeln typische Datenmuster zu überwachen. Für klassische Cloud-Anwendungen ist das sinnvoll. Bei KI greift dieses Modell jedoch oft zu kurz. Der entscheidende Unterschied: Das Risiko entsteht nicht nur im „App-Zugriff“, sondern in der Interaktion – also im Prompt, in der Antwort und in dem, was agentische Systeme danach anstoßen.
Warum CASB und DLP bei KI an Grenzen stoßen
Bei herkömmlichen SaaS-Risiken lässt sich die Prüfung häufig auf klar umrissene Ebenen herunterbrechen: eine bestimmte Anwendung, eine Datei oder ein strukturiertes Datenfeld. Das passt zu vielen CASB-Ansätzen, die den Zugriff auf Apps regeln und in vielen Fällen definieren, was Nutzer innerhalb einer freigegebenen Umgebung tun dürfen. DLP ergänzt das, indem es bekannte sensible Muster erkennt und Übertragungen oder Speicherungen kontrolliert.
KI funktioniert anders. Das Risiko zeigt sich in der Unterhaltung: was gefragt wird (Prompt), was das Modell daraus ableitet (Response) und welche Aktionen daraufhin von autonomen Agenten ausgeführt werden. In dieser Kette stimmen die Prüfziele von CASB und DLP nicht immer sauber mit dem überein, was tatsächlich gefährlich wird.
Das Problem liegt im semantischen Kontext
CASB fragt in der Regel: „Darf ein Benutzer diese Anwendung öffnen?“ Bei KI ist die gleiche Frage allein nicht genug. Denn das Risiko hängt oft daran, welche Bedeutung eine Anfrage im Gesamtkontext hat. Ein Prompt kann zunächst harmlos wirken, gewinnt aber durch Formulierung, Hintergrund und fortlaufende Konversation eine andere Wirkung. DLP-Regeln greifen zudem häufig dann nicht, wenn kein klassisches „verbotenes Muster“ direkt sichtbar ist.
So kann es passieren, dass Mitarbeitende sensible Informationen unabsichtlich in mehreren Schritten teilen. Die Details werden nicht immer als Konto-Nummer oder API-Schlüssel übergeben. Stattdessen werden Informationen indirekt beschrieben – und das Modell versteht sie trotzdem so, dass daraus ein echtes Geschäftsrisiko entsteht.
Beispiele: Wo KI-Risiken trotz Regelwerk auftauchen
Um die Lücke zu verdeutlichen, helfen konkrete Situationen. Das Grundprinzip bleibt: Ein Nutzer kann prinzipiell eine KI-App verwenden, doch die riskante Komponente entsteht später in der Interaktion.
- Marketing-Content vs. vertrauliche Produktinfos: Ein KI-Prompt für einen Blog-Entwurf kann alltäglich sein. Kritisch wird es, wenn daraus Go-to-Market-Text entsteht, der auf ein noch nicht veröffentlichtes Produkt verweist.
- Generische Hilfe vs. proprietäre Logik: Für einen Entwickler ist eine generische Antwort mit niedrigem Risiko verbunden. Anders sieht es aus, wenn der Prompt proprietäre Logik enthält – besonders, wenn sie mit einem realen Kundenproblem verknüpft ist.
- Genehmigte Wissensbasis vs. Externversand interner Dokumente: Das Abrufen einer freigegebenen Wissensquelle ist oft unkritisch. Gefährlich wird es, wenn ein Agent anschließend eingeschränkte interne Dokumente extern weiterleitet.
- Zusammenfassung öffentlich verfügbarer Inhalte: Die Verdichtung eines bereits öffentlichen Dokuments ist meist unproblematisch. Rekonstruktionen vertraulicher Inhalte aus unvollständigen Ausschnitten können jedoch riskant sein.
- Prompt Injection: Inhalte werden wie „Daten“ behandelt – das ist das erwartete Verhalten. Aber wenn Anweisungen so verpackt sind, dass der Agent sie als Auftrag übernimmt, entsteht ein ernstzunehmendes Prompt-Injection-Risiko. Das Modell kann nicht zuverlässig zwischen Daten und Instruktionen unterscheiden.
- Autorisierung reicht nicht: Authentifizierung für Agenten oder Sessions ist ein Basis-Schutz. Trotzdem kann aus einem niedrigriskanten Request plötzlich ein hochriskantes Ergebnis werden, wenn der Kontext kippt. Dann braucht Security Mechanismen, die Anomalien und Risikoänderungen erkennen.
Warum die Sicherheitsprüfung dort beginnen muss, wo das Risiko entsteht
Wenn CASB und DLP das App- bzw. Daten-„Außenbild“ optimieren, dann muss eine zusätzliche Kontrollschicht genau die Stelle adressieren, an der KI tatsächlich angreift: die Interaktion zwischen Person und KI-Modell. Das bedeutet, dass Sicherheitsmechanismen nicht nur entscheiden sollten, ob der Zugriff auf den KI-Dienst erlaubt ist, sondern dass sie die gesamte Sequenz genauer ansehen:
- Was wird in der Unterhaltung gefragt (Prompt)?
- Was erzeugt das Modell als Antwort (Response)?
- Welche Tools ruft ein Agent auf (Tool Invocation)?
- Welche Daten werden abgerufen oder übertragen?
- Welche resultierenden Aktionen sind autorisiert?
Mit dieser Perspektive wird Governance „tiefer“ umgesetzt: Nicht nur Zugang wird geprüft, sondern die potenzielle Wirkung der Anfrage und Ausgabe.
Interaktionsbasierte AI-Sicherheitsprüfung statt reines Blocken
Ein häufiges Missverständnis: „Wir blockieren einfach alles, was irgendwie nicht sicher aussieht.“ Ein Standard-Deny kann auf dem Papier überzeugend wirken. In der Realität entstehen dadurch aber häufig Umgehungsstrategien. Mitarbeitende stehen unter Zeitdruck und wechseln dann auf private Accounts oder nicht verwaltete Erweiterungen. Genau das treibt Shadow-AI voran – und macht das Risiko für Security oft sogar schwerer kontrollierbar.
Stattdessen geht es darum, die Governance zu erweitern, ohne Produktivität abzuwürgen. Die interaktionsbasierte AI-Sicherheitsprüfung soll dabei helfen, Diskussionen und Aktionen innerhalb klarer Grenzen zu halten – sodass Mitarbeitende KI sinnvoll einsetzen können, während sensible Daten und unerwünschtes Agentenverhalten nicht „durchrutschen“.
So bauen Sie ein schlüssiges Sicherheitsmodell auf
Reduzieren Sie das KI-Risiko nicht als Wettbewerb zwischen einzelnen Tools. CASB, DLP und eine zusätzliche Interaktionsschicht lösen unterschiedliche Teile des Problems. Ein praxisnahes Zielbild umfasst mehrere Bausteine:
- Prompt Injection und Agentenmissbrauch real behandeln: Betrachten Sie diese Themen nicht als Randfälle. In der Praxis können sie durch alltägliche Workflows entstehen.
- CASB und DLP für Sichtbarkeit und Grundsteuerung nutzen: Damit entdecken Sie verwendete SaaS- und KI-Apps, steuern Zugriffe, erkennen bekannte sensible Muster und unterstützen Compliance-Berichte.
- Eine Interaktionsschicht ergänzen: Diese prüft die Semantik der Prompts, die Sensitivität der Antworten sowie die Autorisierung von Agentenaktionen.
- Ein Balanceziel verfolgen: Nicht „KI ausschließen bis sie sicher ist“, sondern Beschäftigten Raum geben, KI zu übernehmen und zu testen – bei gleichzeitigen Leitplanken für sensible Daten und für das Verhalten von Agenten.
Der richtige Fokus: Von „Kann er das Tool öffnen?“ zu „Ist die Aktion sicher?“
Viele Security-Entscheidungen starten mit einer simplen Frage: Darf eine Person die KI-Anwendung öffnen? Bei KI ist das zu kurz gedacht. Entscheidend ist vielmehr, ob eine bestimmte Prompt-Interaktion sicher ist, ob die Antwort sicher gehandhabt werden kann und ob die daraus resultierende Aktion autorisiert ist.
Wenn Sie Ihre Strategie um genau diese Fragen herum aufbauen, erhöhen Sie die Wahrscheinlichkeit, dass Mitarbeitende KI produktiv nutzen. Gleichzeitig bleibt das Risiko für sensible Daten, geistiges Eigentum und fehlerhaftes oder missbräuchliches Agentenverhalten besser eingedämmt.
Fazit
KI verändert die Sicherheitslogik: Das Risiko entsteht nicht nur beim Zugriff auf eine Anwendung oder beim Erkennen einzelner Datenmuster, sondern in der Interaktion selbst. CASB und DLP bleiben wertvolle Bausteine – für Sichtbarkeit, Zugriffskontrolle und datenschutzbezogene Mustererkennung. Für den KI-Kontext brauchen Sie jedoch zusätzlich eine interaktionsbasierte AI-Sicherheitsprüfung, die Prompts, Responses und agentische Aktionen semantisch und autorisierend betrachtet. So schaffen Sie eine Sicherheitsbasis, die Innovation ermöglicht, ohne sensible Informationen und Unternehmenswissen unnötig zu gefährden.
