Die meisten Unternehmen haben inzwischen irgendeine Form von KI im Haus. Nicht immer offiziell. Nicht immer bezahlt. Und selten vollständig erfasst. Genau hier beginnt das Sicherheitsproblem: Nicht beim großen Sprachmodell selbst, sondern bei der Frage, wer im Unternehmen welche KI nutzt, mit welchen Daten, über welchen Zugang und mit welchen Folgen.
KI-Sicherheit beginnt nicht mit einem Modell
Viele Sicherheitsprogramme setzen an der falschen Stelle an. Sie diskutieren Prompt-Regeln, verbieten einzelne öffentliche Dienste oder schreiben Richtlinien für generative KI. Das kann sinnvoll sein, bleibt aber oft zu spät und zu schmal. Denn in der operativen Realität steckt KI längst in SaaS-Anwendungen, Entwicklungswerkzeugen, Office-Paketen, Support-Systemen, Analyseplattformen und selbst gebauten API-Integrationen.
Eine belastbare KI-Strategie beginnt deshalb mit einem Inventar. Welche KI-Systeme sind im Einsatz? Welche davon sind offiziell beschafft, welche entstehen in Fachabteilungen, welche laufen als Funktion in bereits vorhandenen Produkten? Ohne diese Sichtbarkeit bleibt jede Governance ein Dokument ohne Anschluss an die Infrastruktur.
Praktisch bedeutet das: Unternehmen brauchen Werkzeuge und Prozesse zur Erkennung von KI-Nutzung. Dazu gehören SaaS-Management, Cloud-Security-Posture-Management, API-Discovery, Endpoint-Telemetrie und Auswertungen von Beschaffungs- und Zugriffsdaten. Kein einzelnes Produkt löst das vollständig. Entscheidend ist, dass Sicherheits- und IT-Teams eine aktuelle Arbeitsliste der KI-Berührungspunkte bekommen. Erst dann lässt sich bewerten, wo sensible Daten landen, welche Anbieter beteiligt sind und wer technische Verantwortung trägt.
Governance ist eine Betriebsfrage
KI-Governance klingt nach Komitee. In der Praxis ist sie näher an Change Management, Risikoklassifizierung und Zugriffssteuerung. Unternehmen müssen unterscheiden, ob ein Team ein internes Textwerkzeug nutzt, ob Kundendaten verarbeitet werden, ob ein Modell Entscheidungen vorbereitet oder ob ein Agent Aktionen in produktiven Systemen auslösen darf.
Daraus ergeben sich unterschiedliche Anforderungen. Ein internes Recherchewerkzeug braucht andere Kontrollen als ein KI-gestützter Supportprozess mit Kundendaten. Ein Assistent, der nur Vorschläge erzeugt, ist anders zu behandeln als ein System, das Tickets schließt, Code ändert oder Bestellungen auslöst. Die Strategie muss diese Unterschiede abbilden, sonst wird sie entweder zu lax oder blockiert alles.
Hilfreich sind etablierte Rahmenwerke wie das NIST AI Risk Management Framework oder die OWASP Top 10 for LLM Applications. Sie ersetzen keine interne Risikoentscheidung, geben aber eine Sprache vor. Begriffe wie Datenherkunft, Prompt Injection, Modellmissbrauch, Ausgabevalidierung oder Monitoring werden dadurch prüfbar. Das ist weniger spektakulär als Pilotprojekte mit generativer KI, aber für Unternehmen deutlich wichtiger.
Identität wird zur zentralen Kontrollschicht
Der oft unterschätzte Teil einer sicheren KI-Strategie ist Identität. KI-Systeme handeln selten isoliert. Sie lesen Dokumente, durchsuchen Wissensdatenbanken, greifen auf CRM-Daten zu, erzeugen Code oder verbinden sich mit internen Diensten. Damit wird die Frage entscheidend, unter welcher Identität sie arbeiten.
Ein KI-Assistent darf nicht mehr sehen als der Nutzer, in dessen Auftrag er agiert. Das klingt selbstverständlich, ist aber technisch anspruchsvoll, wenn Berechtigungen aus Dateisystemen, SaaS-Plattformen, Datenbanken und selbst gebauten Anwendungen zusammenkommen. Fehler in dieser Schicht führen nicht automatisch zu einem spektakulären Angriff. Oft reichen schon zu breite Leserechte, schlecht gepflegte Gruppen oder unklare Datenklassifizierung, damit vertrauliche Informationen in Antworten auftauchen.
Unternehmen sollten KI daher in bestehende Identity- und Access-Management-Strukturen einbinden. Rollen, Gruppen, privilegierte Zugänge, Service Accounts und API-Schlüssel müssen nachvollziehbar sein. Besonders wichtig ist die Trennung zwischen menschlichen Nutzern, technischen Diensten und KI-Agenten. Wer KI wie einen normalen Nutzer behandelt, übersieht, dass diese Systeme Anfragen skalieren, kombinieren und automatisieren können.
Guardrails sind kein Sicherheitszaun
Der Begriff Guardrails wird oft überdehnt. In vielen Präsentationen klingt er, als könne man ein Modell mit einigen Regeln sicher machen. In der Praxis sind Guardrails eher eine Schicht aus Begrenzungen, Prüfungen und Protokollierung. Sie können Eingaben filtern, Ausgaben prüfen, sensible Daten erkennen, Aktionen beschränken oder riskante Vorgänge an Menschen eskalieren.
Dafür kommen unterschiedliche Werkzeugklassen in Frage: Data-Loss-Prevention-Systeme, Klassifizierung von Dokumenten, API-Gateways, Modell-Gateways, Secret-Scanning, Content-Filter, Policy-as-Code, SIEM-Integration und Red-Teaming-Umgebungen. Die Schwierigkeit liegt nicht in der Existenz solcher Werkzeuge, sondern in ihrer Verbindung. Ein Filter ohne Logging hilft wenig. Logging ohne Verantwortliche hilft ebenfalls wenig. Und ein Freigabeprozess, den Fachbereiche umgehen, schafft nur Schattenbetrieb.
Besonders heikel sind KI-Funktionen, die Aktionen auslösen. Sobald ein System nicht nur Text erzeugt, sondern E-Mails verschickt, Code schreibt, Datenbankabfragen startet oder Tickets verändert, muss die Sicherheitsarchitektur enger werden. Dann braucht es Freigabepunkte, Transaktionsgrenzen, Testumgebungen und nachvollziehbare Protokolle. Der Unterschied zwischen Assistenz und Aktion ist für die Risikobewertung zentral.
Die sinnvolle Reihenfolge
Eine sichere KI-Strategie lässt sich nicht als einzelnes Projekt einkaufen. Sie entsteht in Schichten. Erstens: Sichtbarkeit herstellen. Zweitens: KI-Anwendungsfälle nach Risiko sortieren. Drittens: Identität und Datenzugriff klären. Viertens: technische Kontrollpunkte einziehen. Fünftens: Nutzung überwachen und regelmäßig testen.
Diese Reihenfolge ist unspektakulär, aber sie verhindert einen häufigen Fehler: Unternehmen kaufen zuerst ein Sicherheitsprodukt für KI und suchen danach das Problem. Besser ist die umgekehrte Richtung. Welche Daten dürfen in welche Systeme? Welche Nutzergruppen brauchen welche Funktionen? Welche Anwendungen sind geschäftskritisch? Welche Ausgaben müssen überprüft werden? Wo reicht Protokollierung, wo braucht es Freigabe?
Für europäische Unternehmen kommt eine weitere Ebene hinzu: Regulierung und Nachweisbarkeit. Wer KI in relevanten Geschäftsprozessen einsetzt, wird erklären müssen, wie Risiken bewertet, Zuständigkeiten definiert und Kontrollen umgesetzt wurden. Das spricht nicht für mehr Papier, sondern für eine engere Kopplung von Governance und Betrieb.
Die Lehre für Sicherheitsverantwortliche
Der wichtigste Schritt ist nicht, KI im Unternehmen zu bremsen. Das wird in den meisten Organisationen ohnehin nicht funktionieren. Der wichtigere Schritt ist, KI aus dem informellen Raum zu holen. Sicherheitsverantwortliche müssen wissen, welche Systeme genutzt werden, welche Daten sie berühren und welche Identitäten dahinterstehen.
Die Debatte über sichere KI wird oft zu groß geführt: als Grundsatzfrage über Maschinen, Arbeit oder Kontrolle. Für Unternehmen ist sie zunächst kleiner und härter. Inventar. Berechtigungen. Datenklassifizierung. Protokolle. Freigaben. Tests. Wer diese Schicht nicht beherrscht, sollte nicht darauf vertrauen, dass ein Modellanbieter, ein Policy-Dokument oder ein einzelnes Tool die Risiken auffängt.
Eine sichere KI-Strategie ist damit weniger eine Vision als ein Betriebsmodell. Sie entscheidet nicht abstrakt, ob KI gut oder schlecht ist. Sie legt fest, unter welchen Bedingungen KI im Unternehmen arbeiten darf. Genau diese trockene Kontrolle wird in den nächsten Jahren wichtiger sein als die nächste Demo.
