Bei allen KI-Implementierungen, die ich in unterschiedlichsten Branchen überprüft habe, zeigt sich immer wieder dasselbe Muster: Unternehmen suchen an der falschen Stelle nach Risiken. Ihr Blick richtet sich meist auf das Modell selbst — einschließlich Trainingsdaten, Sicherheitsmechanismen und Verhalten. In der Praxis entstehen Probleme dort jedoch nur selten.
Viele der folgenschwersten Schwachstellen entstehen im umgebenden System — also darin, wie Prompts aufgebaut sind, wie externe Daten beschafft und als vertrauenswürdig eingestuft werden, worauf das Modell zugreifen darf und unter welchen Identitäten es arbeitet. Genau dort sind KI-Systeme am häufigsten angreifbar: an den Schnittstellen zwischen Komponenten, wo Governance meist am schwächsten ausgeprägt ist.
Das tieferliegende Problem ist die Lücke zwischen Erwartung und Realität. Unternehmen rechnen mit einer bestimmten Art von Fehler, doch produktive Systeme scheitern in ganz anderer Weise. Risiken entstehen genau in dieser Diskrepanz — in Annahmen, die Skalierung, Autonomie oder Integration nicht standhalten.
Dieselben Fehlannahmen über die Absicherung von KI tauchen immer wieder auf. Es lohnt sich, die fünf wichtigsten genauer anzusehen.
- LESEN SIE AUCH → Vertrauen in der Geschwindigkeit der KI: Aufbau einer Cybersicherheitsstrategie für KI
Fehlannahme Nr. 1: Wenn das Modell sicher ist, ist das System sicher
Das ist der häufigste Fehler, den ich sehe — und er ist leicht nachvollziehbar. Das Modell wirkt neu, also konzentrieren sich Teams auf Guardrails und Tests und gehen dann davon aus, dass damit alles erledigt ist.
Doch so scheitern diese Systeme nicht. Das Modell ist nur eine Komponente einer deutlich größeren Infrastruktur, und die meisten Ausfälle entstehen dort, wo es mit Daten, Tools und anderen Systemen verbunden ist. Sich nur auf das Modell zu konzentrieren, ist so, als würde man in einem Gebäude ohne Wände eine Hochsicherheitstür einbauen.
So beheben Sie das Problem: Um ein KI-System abzusichern, sollten Sie die gesamte Umgebung als Angriffsfläche betrachten. Erfassen Sie den vollständigen Datenfluss — von Eingaben über Retrieval und Memory bis hin von Tools zu Ausgaben — und behandeln Sie Prompts, Agenten, Vektordatenbanken, Identitäten und Konnektoren als klar verantwortete Assets mit eindeutigen Kontrollpunkten, Zuständigkeiten und Richtlinien, so wie bei jedem anderen geschäftskritischen System.
Fehlannahme Nr. 2: Prompt Injection ist nur ein weiteres Eingabeproblem
Sicherheitsteams mit Web-Hintergrund greifen bei neuen Problemen oft zuerst zu vertrauten Werkzeugen. Bei der Absicherung von KI kann genau dieser Impuls jedoch in die falsche Richtung führen.
Prompt Injection ähnelt auf den ersten Blick einer SQL-Injection — also einem Angriff, bei dem Systeme bösartige Eingaben als Befehl interpretieren — verhält sich aber grundlegend anders. Klassische Software kann Anweisungen und Daten klar voneinander trennen. Große Sprachmodelle können das nicht zuverlässig. Sie verarbeiten Anweisungen und Daten als denselben Textstrom und treffen nur probabilistische Entscheidungen darüber, was was ist.
Das britische National Cyber Security Centre (NCSC) ist hier eindeutig: Prompt Injection unterscheidet sich strukturell von SQL-Injection und muss auch anders behandelt werden.
So beheben Sie das Problem: Filter und Detektoren helfen, lösen das Problem aber nicht allein. Die wirksamsten Schutzmaßnahmen sind architektonischer Natur. Beschränken Sie den Zugriff auf Tools, setzen Sie Least Privilege durch, isolieren Sie nicht vertrauenswürdige Inhalte und validieren Sie Tool-Aufrufe und Parameter deterministisch. Verlangen Sie für sensible Aktionen eine explizite Freigabe, führen Sie Ausführung in Sandboxes aus und überwachen Sie konsequent. Diese Maßnahmen reduzieren sowohl die Wahrscheinlichkeit als auch die Auswirkungen einer Kompromittierung, beseitigen das Risiko jedoch nicht. Wenn das Restrisiko unvertretbar bleibt, eignet sich der Anwendungsfall nicht für ein großes Sprachmodell.
Fehlannahme Nr. 3: KI-Ausgaben sind nur Text — sie erzeugen kein reales Risiko
Frühe KI-Implementierungen haben Autonomie belohnt. Diese Denkweise wurde in produktive Umgebungen übertragen, wo sie nicht hingehört.
KI-Ausgaben mögen wie harmloser Text aussehen, bleiben es aber selten. Sobald sie an ein anderes System weitergegeben werden, können sie reale Aktionen auslösen — E-Mails versenden, Datenbanken abfragen, Code ausführen oder einen Datensatz löschen. In diesem Kontext erbt eine erfolgreiche Prompt Injection alles, was das System tun kann.
Genau dort wird das Risiko real: Die Fähigkeiten des Systems werden zu den Fähigkeiten des Angreifers.
Das Open Web Application Security Project stuft "excessive agency" als eines der gravierendsten Risiken agentischer KI ein, während das NCSC darauf hinweist, dass genau an diesem Punkt Prompt Injection aufhört, ein Ärgernis zu sein, und zu einer Sicherheitsverletzung wird.
So beheben Sie das Problem: Der Ansatz ist einfach: Begrenzen Sie, was das System tun darf, setzen Sie Least-Privilege-Zugriffe durch und behandeln Sie Modell-Outputs als nicht vertrauenswürdig, bis sie an der Ausführungsgrenze eine deterministische Validierung durchlaufen haben. Das macht einen kompromittierten Agenten nicht harmlos, reduziert aber den potenziellen Schaden erheblich.
Fehlannahme Nr. 4: Externe Daten machen KI zuverlässiger und sicherer
Retrieval-Augmented Generation (RAG), bei der Modelle externe Daten einbeziehen, verbessert die Genauigkeit, macht Systeme aber nicht sicherer. Forschungsergebnisse, die bei USENIX veröffentlicht wurden, zeigen, dass bereits die Manipulation weniger Einträge in einer Wissensbasis ausreicht, um RAG-Outputs zuverlässig und in großem Maßstab zu beeinflussen.
Jede Datenquelle, die Sie anbinden, wird zu einem potenziellen Einstiegspunkt. Wenn diese Daten nicht vertrauenswürdig, veraltet oder manipuliert sind, können sie die Ausgaben des Modells auf schwer erkennbare Weise beeinflussen.
So beheben Sie das Problem: Das ist sowohl ein Modellthema als auch ein Daten- und Supply-Chain-Thema. Behandeln Sie externe Quellen als Abhängigkeiten, die Governance benötigen. Setzen Sie Kontrollen für Herkunftsnachweise, Validierung, Schreibzugriffe, Scans bei der Ingestion, Versionierung, Quellentrennung und Change Management um.
Fehlannahme Nr. 5: Managed AI bedeutet, dass der Anbieter die Sicherheit übernimmt
Viele verwechseln Managed Services mit ausgelagerter Sicherheit. Tatsächlich ist die Verantwortung geteilt, und die Sicherheitsverantwortung auf Kundenseite bleibt erheblich.
Der Anbieter sichert den Service selbst ab. Sie sind für alles verantwortlich, was darum herum geschieht: welche Daten eingehen, wer Zugriff hat, was das Modell tun darf und wie die Outputs verwendet werden.
So beheben Sie das Problem: Legen Sie klar fest, wofür Sie verantwortlich sind, bilden Sie das Shared-Responsibility-Modell eindeutig ab und gehen Sie nicht davon aus, dass etwas sicher ist, nur weil es gemanagt wird. Prüfen Sie die Kontrollen des Anbieters und schließen Sie anschließend selbst die Lücken bei Identitäten, Datenverarbeitung, Konfiguration, Monitoring und Integrationssicherheit.
Was bei jeder Implementierung vorhanden sein sollte
Die meisten Unternehmen, die ich bewerte, können aufzählen, welche KI sie eingeführt haben. Deutlich weniger können mir sagen, wem sie gehört, welche Daten sie berührt, wozu sie in der Lage ist oder was passiert, wenn sie ausfällt. Das weist auf ein Governance-Problem hin.
Die Grundlagen sind nicht besonders kompliziert — sie werden nur uneinheitlich umgesetzt.
Mindestens vorhanden sein sollten:
- Eine klare, vom Management freigegebene KI-Sicherheitsstrategie und ein definiertes Risikoprofil, abgestimmt auf konkrete Anwendungsfälle und Datentypen
- Ein vollständiges Inventar Ihrer KI-Assets (Modelle, Prompts, Agenten, Datensätze, Vektordatenbanken, Konnektoren, Service-Accounts und Plugins) mit benannten Verantwortlichen
- Threat Models, die Vertrauensgrenzen definieren und Richtlinien an vorhersehbaren Kontrollpunkten durchsetzen
- Starke Integritätskontrollen über Ihre Supply Chain und Datenpipeline hinweg, einschließlich Herkunftsnachweisen, Signierung, Scanning, Lineage, Versionierung und, wo sinnvoll, gemanagten Registries
- Least-Privilege-Zugriffe auf Tools für Agenten, mit Human-in-the-Loop-Aufsicht bei Maßnahmen mit hoher Wirkung
- Validierungsebenen für Outputs, bevor irgendetwas ausgeführt, geschrieben oder Nutzern bereitgestellt wird
- Kontinuierliche Evaluierung und Überwachung als fester Bestandteil des Change Managements
- Incident-Runbooks, die in der Praxis getestet sind, einschließlich Szenarien für Eindämmung, sicheres Deaktivieren und Rollback
Wenn Sie das umsetzen, wenden Sie dieselbe Engineering-Disziplin an, die auch von jedem anderen geschäftskritischen System erwartet wird.
Das Fazit zur KI-Sicherheit
KI-Sicherheit bedeutet mehr, als nur Systeme oder Modelle abzusichern. Wer das früh erkennt, ist denen voraus, die es erst lernen, wenn bereits etwas schiefgelaufen ist.
Das ist keine einmalige Aufgabe. KI-Systeme entwickeln sich ständig weiter, und die Sicherheit muss Schritt halten. Dazu gehören fortlaufende Tests, einschließlich Red Teaming — also der gezielte Versuch, das System zu kompromittieren, um seine Schwachstellen zu verstehen.
Und wenn Sie Ihre Angriffsfläche über Modelle, Integrationen, Datenpipelines und Agenten hinweg nicht klar nachvollziehen können, ist bereits diese Unsicherheit ein Teil des Risikos.