Die meisten Unternehmen haben KI-Tools schneller eingeführt, als sie ihre Sicherheitsarchitektur entsprechend angepasst haben. Entwicklungsteams nutzen Copiloten, Produktteams verbinden LLM-APIs mit internen Daten, und Geschäftsanwender richten KI-Assistenten über Low-Code-Tools ein, oft ohne Wissen oder Genehmigung der IT-Abteilung.

Das Ergebnis ist eine verteilte KI-Präsenz, die Sicherheitsteams nicht vollständig inventarisieren, klassifizieren oder steuern können. Jüngste Untersuchungen zeigten, dass 99,4 % der CISOs im Jahr 2025 SaaS- oder KI-Sicherheitsvorfälle meldeten, doch nur 6 % der Unternehmen verfügen über eine fortschrittliche KI-Sicherheitsstrategie.

Dies wäre ein überschaubares Problem, wenn sich KI-Komponenten wie herkömmliche Software verhalten würden. Das tun sie aber nicht. Ein interner Zusammenfassungsagent kann aufgrund falsch konfigurierter Berechtigungen Finanzdatenbanken abfragen, auf die er eigentlich keinen Zugriff haben sollte. Ein kundenorientierter Copilot kann Kontext von einer Benutzersitzung in eine andere lecken. 

Für die technische Führungsebene ist dies ein Problem der Systemhygiene. Es bedarf einer Kontrollschicht, die eine kontinuierliche Transparenz über Ihre KI-Präsenz bietet, und die meisten Organisationen verfügen noch nicht über eine solche.

Was AI Security Posture Management ist

AI Security Posture Management (AI-SPM) bietet Sicherheitsteams kontinuierliche Transparenz darüber, wo KI-Systeme laufen, auf welche Daten sie zugreifen, wie sie konfiguriert sind und ob sie den von der Organisation festgelegten Richtlinien entsprechen. Es behandelt jede KI-Komponente als Teil der Angriffsfläche.

Um den Umfang zu verdeutlichen: Traditionelles Cloud Security Posture Management (CSPM) prüft, ob ein Server gepatcht ist. AI-SPM prüft, ob das auf diesem Server laufende Modell anfällig für Prompt Injection ist oder ob es über eine überprivilegierte Retrieval-Pipeline auf personenbezogene Kundendaten (PII) zugreifen kann.

Diese Unterscheidung ist wichtig, weil sich die Kategorien in diesem Bereich so stark überschneiden, dass sie Beschaffung und Planung erschweren können.

AI-SPM vs. DSPM für KI vs. KI-Governance

Die meisten Organisationen benötigen alle drei, aber AI-SPM ist die Schicht, die die Lücke zwischen der erklärten Richtlinie und der beobachteten Realität schließt.

Wie AI-SPM in der Praxis funktioniert

AI-SPM arbeitet als kontinuierlicher Prozess über fünf Schichten hinweg. Jede Schicht löst ein spezifisches Transparenz- oder Kontrollproblem, das unbehandelt zu einer Schwachstelle wird.

Erkennung

Sie können keine KI-Workloads verwalten, die Sie nicht gefunden haben. Die Erkennung scannt Ihre Infrastruktur. Cloud-Konten, SaaS-Plattformen, interne Anwendungen und On-Premise-Systeme. Sie identifiziert jede in der Umgebung laufende KI-Komponente, einschließlich derer, die ohne Wissen der IT-Abteilung bereitgestellt wurden.

Das ist schwieriger, als es klingt. Geschäftsanwender erstellen KI-Workflows mit Low-Code-Tools und „Vibe Coding“. Entwicklungsteams richten Modell-Endpunkte in Entwicklerkonten ein, die nie registriert werden. SaaS-Anbieter betten KI-Funktionen ein, die standardmäßig aktiviert sind. Ein Erkennungsprozess, der nur genehmigte Infrastruktur scannt, wird einen erheblichen Teil der tatsächlichen KI-Nutzung übersehen.

Inventarisierung (KI-Stückliste)

Sobald Sie die Workloads gefunden haben, müssen Sie sie katalogisieren. Eine KI-Stückliste (AI-BOM) erfasst die Komponenten hinter jedem KI-System: welches Modell es verwendet, mit welchen Datenquellen es verbunden ist, welche Vektorspeicher oder Retrieval-Schichten beteiligt sind, welche Drittanbieter-APIs es aufruft und welche Identitäten Zugriff haben.

Stellen Sie sich dies als das Lieferketten-Manifest für ein KI-System vor. Ohne es können Sie grundlegende Sicherheitsfragen nicht beantworten: 

1. „Was passiert mit unserem Gefährdungspotenzial, wenn dieser Modell-Anbieter eine Sicherheitsverletzung hat?“ 
2. „Welche Systeme sind betroffen, wenn wir den Zugriff auf diese Datenquelle widerrufen?“

Gefährdungsanalyse

Diese Ebene bildet die tatsächlichen Datenzugriffspfade Ihrer KI-Systeme ab und vergleicht sie mit dem, was beabsichtigt ist. Die Lücke zwischen diesen beiden Dingen ist der Ausgangspunkt für Sicherheitsverletzungen.

Ein häufiges Ergebnis: Ein KI-Agent, der für die interne Textzusammenfassung entwickelt wurde, erbt weitreichende Dienstkontoberechtigungen und kann Datenbanken abfragen, die personenbezogene Kundendaten (PII), Finanzunterlagen oder Quellcode enthalten. Das Team, das den Agenten entwickelt hat, beabsichtigte diesen Zugriff nie. Die Berechtigungen wurden von den Infrastruktur-Standardeinstellungen geerbt, und niemand hat sie mit dem tatsächlichen Umfang des Agenten abgeglichen.

Die Gefährdungsanalyse identifiziert diese Fehlkonfigurationen, bevor es ein Angreifer oder eine falsch konfigurierte Eingabeaufforderung tut.

Richtlinienabdeckung und Kontrollzuordnung

Sicherheitsteams müssen überprüfen, ob bestehende Kontrollen auch für KI-Workloads gelten. Viele Organisationen verfügen über ausgereifte Zugriffskontrollen, Protokollierungs- und Überprüfungsprozesse für menschliche Benutzer und traditionelle Dienste, aber KI-Agenten, Modell-Endpunkte und Retrieval-Pipelines liegen vollständig außerhalb dieser Kontrollen.

Diese Ebene bildet Ihre technischen Kontrollen gegenüber den regulatorischen und Compliance-Frameworks ab, unter denen Sie agieren, dem EU AI Act, NIST AI RMF, internen Sicherheitsrichtlinien, und identifiziert Abdeckungslücken. Die Frage, die sie beantwortet: „Gelten unsere Kontrollen tatsächlich für die KI-Ebene, oder decken sie nur die darunterliegende Infrastruktur ab?“

Kontinuierliche Sicherheitslagebewertung

KI-Systeme sind nicht-deterministisch. Ihr Verhalten ändert sich, wenn Modelle aktualisiert, neue Tools verbunden, Abrufquellen modifiziert und Berechtigungen abweichen. Ein System, das bei der Bereitstellung sicher war, kann durch routinemäßige Änderungen, die niemand bemerkt, gefährdet werden.

Die kontinuierliche Bewertung betrachtet die Sicherheitslage als Signal, nicht als Momentaufnahme. Sie erkennt Konfigurationsabweichungen, neu eingeführte Datenzugriffspfade und Änderungen in der Bedrohungslandschaft, sobald sie auftreten, anstatt sie erst im nächsten vierteljährlichen Audit aufzudecken.

Wo die Sicherheitslage zuerst brüchig wird: vier wiederkehrende Gefährdungsbereiche

Sicherheitsmängel bei KI-Implementierungen konzentrieren sich tendenziell auf vier Bereiche. Dies sind keine unabhängigen Kategorien. Sie verstärken sich gegenseitig: Nicht nachverfolgte KI-Nutzung führt zu unkontrollierter Datengefährdung, die bestehen bleibt, weil Richtlinien nicht auf KI-Workloads ausgeweitet wurden, und all dies skaliert mit der Angriffsfläche, die agentenbasierte Workflows einführen.

Unbekannte KI-Nutzung (Schatten-KI)

Mitarbeiter übernehmen KI-Tools schneller, als die meisten Organisationen sie bewerten, genehmigen und bereitstellen können. Über 80 % der Fortune-500-Unternehmen setzen inzwischen aktive KI-Agenten ein, viele davon von Geschäftsanwendern mit Low-Code-Plattformen und ohne Sicherheitsüberprüfung erstellt. Wenn Teams KI-Tools außerhalb genehmigter Kanäle entwickeln und bereitstellen, erben diese Tools keine Überwachung, keine Zugriffskontrollen und keine Abdeckung durch die Incident Response.

Die Herausforderung besteht nicht darin, dass Menschen böswillig handeln. Sie lösen reale Probleme mit den verfügbaren Tools. Aber jedes nicht nachverfolgte KI-System ist ein blinder Fleck in Ihrer Sicherheitslage.

Offenlegung sensibler Daten

KI-Systeme verbrauchen Daten aggressiv. Trainings-Pipelines greifen auf interne Repositories zu. Retrieval-Augmented Generation indiziert Dokumente in Vektordatenbanken. Copilots verarbeiten den Inhalt aller Dateien, die Benutzer in ihrem Workflow öffnen.

Das architektonische Problem: Sobald sensible Daten in den Trainingsdatensatz eines Modells oder eine gemeinsame Vektordatenbank gelangen, können Sie diese nicht selektiv abrufen oder löschen. Die Daten sind in Gewichten eingebettet oder in Vektoren zerlegt, die keine Datensatzgrenzen bewahren. Personenbezogene Daten (PII), Geschäftsgeheimnisse oder regulierte Daten, die in diese Systeme gelangen, stellen eine dauerhafte Gefährdung dar.

Lückenhafte Richtlinienabdeckung

Die meisten Organisationen verfügen über Zugriffskontrollen, Audit-Protokollierung und Überprüfungsprozesse, die auf menschliche Benutzer und traditionelle Dienstkonten zugeschnitten sind. KI-Agenten, Modell-Endpunkte und Retrieval-Pipelines stellen eine andere Identitätsklasse dar. Sie agieren kontinuierlich, treffen autonome Entscheidungen und interagieren mit Backend-Systemen über API-Aufrufe, die die benutzerseitigen Kontrollen umgehen.

NISTs Leitfaden zur KI-Sicherheit hebt hervor, dass traditionelle Schwachstellenscanner KI-spezifische Artefakte übersehen. Wenn Ihre Sicherheitsrichtlinie Zugriffsregeln für menschliche Benutzer und Standarddienste definiert, aber keine Bestimmungen für nicht-menschliche KI-Identitäten enthält, weist Ihre Richtlinienabdeckung eine strukturelle Lücke auf.

Die agentische Angriffsfläche

Autonome Agenten führen ein qualitativ anderes Risikoprofil ein. Wenn ein Agent externe Eingaben lesen, Tools aufrufen und Aktionen in anderen Systemen auslösen kann, wird er zu einem Ziel für indirekte Prompt-Injektion (XPIA).

Das Angriffsmuster: Ein Agent verarbeitet ein externes Dokument, eine E-Mail oder eine Webseite, die versteckte Anweisungen im Inhalt enthält. Der Agent interpretiert diese Anweisungen als Teil seiner Aufgabe und führt sie aus. Der Benutzer, der den Workflow ausgelöst hat, bemerkt davon nichts.

Dies ist eine inhärente Eigenschaft von Systemen, die nicht vertrauenswürdige Eingaben verarbeiten und über Tool-Aufrufberechtigungen verfügen. Jede externe Datenquelle, die ein Agent lesen kann, ist ein potenzieller Injektionsvektor. Jedes Tool, das ein Agent aufrufen kann, ist ein potenzieller Eskalationspfad. Die Angriffsfläche wächst multiplikativ mit den Fähigkeiten des Agenten.

Benötigen Sie tatsächlich AI-SPM?

Ein nützlicher erster Test: Können Sie jedes KI-System in Ihrer Umgebung auflisten und angeben, auf welche Daten jedes einzelne zugreifen kann? Wenn nicht, haben Sie ein Problem mit der unkontrollierten Haltung, unabhängig vom Umfang.

Für eine strukturiertere Bewertung helfen diese fünf Fragen zu bestimmen, wie dringend Sie ein formelles AI-SPM-Programm benötigen:

Wenn Ihre KI-Nutzung auf einen einzelnen isolierten Pilotversuch ohne Zugriff auf sensible Daten und ohne agentische Autonomie beschränkt ist, könnte ein formelles AI-SPM verfrüht sein. In der Praxis hält dieser Zustand selten an. Die KI-Einführung neigt dazu, sich schnell auszubreiten, sobald ein anfänglicher Anwendungsfall seinen Wert beweist, und die Haltungslücke vergrößert sich mit jeder neuen Bereitstellung.

Was AI-SPM nicht ersetzt

AI-SPM ist eine Sichtbarkeits- und Priorisierungsebene. Es zeigt Ihnen, was läuft, was exponiert ist und wo Ihre Kontrollen unzureichend sind. Es behebt diese Probleme nicht von selbst. Vier Fähigkeiten liegen außerhalb seines Geltungsbereichs und bleiben unerlässlich.

Sicheres Systemdesign. Haltungsmanagement erkennt Fehlkonfigurationen und Richtlinienlücken nach der Bereitstellung. Es verhindert sie nicht. Wenn Ihre KI-Systeme von Anfang an ohne Bedrohungsmodellierung, Eingabevalidierung und bereichsbezogene Berechtigungen erstellt werden, wird AI-SPM eine lange Liste von Feststellungen zutage fördern – aber Sie werden Probleme beheben, die ein besseres Design verhindert hätte.

Architektur nach dem Prinzip der geringsten Rechte. Jeder KI-Agent, jeder Modell-Endpunkt und jede Retrieval-Pipeline benötigt Zugriffskontrollen, die auf seine tatsächliche Funktion zugeschnitten sind. AI-SPM kann überprivilegierte Identitäten identifizieren, aber es kann das Prinzip der geringsten Rechte nicht in Ihrem Namen durchsetzen. Ihre Teams müssen diese Einschränkungen aufbauen und pflegen.

Mensch-in-der-Schleife-Kontrollen. Autonome KI-Systeme, die risikoreiche Entscheidungen treffen – Finanztransaktionen, Datenlöschungen, Zugriffsberechtigungen – benötigen explizite menschliche Freigabeprozesse. AI-SPM kann Ihnen sagen, welche Agenten die Möglichkeit haben, diese Aktionen auszuführen, aber die Entscheidung, eine menschliche Genehmigung zu verlangen, ist eine architektonische und politische Wahl.

Protokollierung und Beobachtbarkeit. AI-SPM ist auf Daten aus Ihrer Protokollierungs-, Tracing- und Überwachungsinfrastruktur angewiesen. Wenn Ihre KI-Workloads keine Audit-Logs generieren oder wenn diese Logs nicht gesammelt und aufbewahrt werden, hat das Posture Management keine Grundlage für seine Arbeit.

Fazit

AI-SPM löst nicht jedes KI-Sicherheitsproblem. Es löst das erste: zu wissen, was Sie haben, worauf es zugreifen kann und ob Ihre Kontrollen es abdecken. Ohne diese Grundlage basiert jede andere Sicherheitsinvestition, jedes Red Teaming, jede Modellbewertung und jede Richtlinienentwicklung auf unvollständigen Informationen.

Für die technische Führungsebene ist die praktische Frage einfach. Sie müssen feststellen, ob Ihr Unternehmen seinen KI-Bestand heute überblicken kann, und falls nicht, welche Tools und Prozesse Sie benötigen, um diese Lücke zu schließen, bevor die nächste Bereitstellung sie vergrößert.