Die gute Nachricht vorab: Viele Grundlagen für KI-Security kennen Unternehmen bereits aus Datenschutz und IT-Security. Neu ist vor allem, wie generative KI bestehende Risiken kombiniert und welche zusätzlichen Angriffsmöglichkeiten durch Prompt Injection, angebundene Datenquellen und autonome Aktionen entstehen. Entscheidend ist deshalb nicht nur, welche Daten eine KI sieht. Ebenso wichtig ist, welche Berechtigungen sie besitzt und was sie selbstständig tun darf.
Personenbezogene Daten sind für KI nicht grundsätzlich tabu
Die generalisierte Regel „Keine personenbezogenen Daten in eine KI eingeben“ klingt sicher, greift aber zu kurz. Personenbezogene Daten können grundsätzlich auch mit KI-Anwendungen verarbeitet werden. Dafür braucht es wie bei anderen IT-Systemen eine passende Rechtsgrundlage, einen klar definierten Zweck und geeignete technische sowie organisatorische Maßnahmen.
Wird ein externer KI-Dienst als Auftragsverarbeiter eingesetzt, muss zudem geprüft werden, ob die Voraussetzungen nach Art. 28 DSGVO erfüllt sind. Bei Verarbeitungen mit voraussichtlich hohem Risiko kann eine Datenschutz-Folgenabschätzung notwendig werden. Die Datenschutzkonferenz weist ausdrücklich darauf hin, dass diese Prüfung auch beim Einsatz von KI-Anwendungen relevant ist.
Deshalb macht es einen erheblichen Unterschied, ob Mitarbeitende Kundendaten über einen privaten KI-Account verarbeiten oder ob das Unternehmen ein zentral verwaltetes Werkzeug mit geprüften Vertragsbedingungen und passenden Einstellungen bereitstellt. Die Datenschutzkonferenz empfiehlt für die berufliche Nutzung ausdrücklich betriebliche Accounts und weist unter anderem auf Einstellungen zur Trainingsnutzung und Eingabehistorie hin.
Die Frage lautet also nicht nur, ob sensible Daten in einer KI landen. Unternehmen müssen wissen, bei welchem Anbieter sie verarbeitet werden, zu welchem Zweck das geschieht, wie lange sie gespeichert bleiben und wer darauf zugreifen kann.
Ein Enterprise-KI-Tool löst nicht automatisch das Security-Problem
Ein geeignetes Enterprise-Produkt kann einen großen Unterschied machen. Es kann klare Vertragsbeziehungen, zentrale Administration, geregelte Berechtigungen und kontrollierbare Einstellungen ermöglichen.
Damit ist KI-Security aber nicht erledigt.
Sobald die Anwendung auf SharePoint, E-Mail-Postfächer, Ticketsysteme oder andere interne Quellen zugreifen kann, entsteht eine zweite Ebene. Jetzt geht es nicht mehr nur darum, was der KI bewusst in ein Chatfenster eingegeben wird. Sie verarbeitet Inhalte aus angebundenen Systemen und arbeitet innerhalb der dort gewährten Berechtigungen.
Das BSI beschreibt Indirect Prompt Injection genau in diesem Zusammenhang. Manipulierte Anweisungen können beispielsweise in Webseiten oder Dokumenten verborgen sein und über angebundene Quellen in den Kontext eines Sprachmodells gelangen. Das Modell kann diese Inhalte anschließend als Anweisung interpretieren.
Ein datenschutzfreundlicher Vertrag schützt deshalb nicht automatisch vor Prompt Injection. Und die Zusicherung, dass Eingaben nicht zum Training genutzt werden, sagt noch nichts darüber aus, ob eine KI zu viele interne Dokumente lesen oder eine manipulierte Aktion ausführen kann.
Mehr Rechte bedeuten auch mehr technischen Grenzen
Bei einem klassischen Chat sind die Auswirkungen eines Fehlers häufig begrenzt. Das System erzeugt eine Antwort und ein Mensch entscheidet, was damit passiert.
Bei einem KI-Agenten sieht das anders aus. Ein Agent kann selbstständig Informationen beschaffen, Werkzeuge aufrufen und mehrere Arbeitsschritte nacheinander ausführen. Besitzt er zusätzlich Schreibrechte, kann aus einem falschen Output eine reale Aktion werden.
OWASP bezeichnet zu weitreichende Funktionen, Berechtigungen und Autonomie als zentrale Ursache für „Excessive Agency“. Ein System, das lediglich E-Mails zusammenfassen soll, benötigt beispielsweise keine Berechtigung zum Versenden oder Löschen von Nachrichten. Für Aktionen mit größeren Auswirkungen empfiehlt OWASP eine explizite menschliche Freigabe.
Damit verändert sich die zentrale Security-Frage. Bei einem Chat lautet sie häufig, welche Informationen das Modell verarbeiten darf. Bei einem Agenten muss zusätzlich geklärt werden, welchen Schaden das System mit seinen vorhandenen Rechten verursachen könnte.
Ein Prompt ist keine belastbare Sicherheitsgrenze
Viele Sicherheitsregeln lassen sich einem Sprachmodell als Systemanweisung mitgeben. Das ist sinnvoll, sollte aber nicht mit einer technischen Zugriffskontrolle verwechselt werden.
Ein Agent sollte eine Datei nicht deshalb unangetastet lassen, weil in seinem Prompt steht, dass er sie nicht verändern darf. Robuster ist eine Umgebung, in der ihm die dafür notwendige Berechtigung schlicht fehlt.
OWASP empfiehlt deshalb unter anderem Least Privilege, getrennte Behandlung nicht vertrauenswürdiger Inhalte sowie menschliche Freigaben für risikoreiche Aktionen. Die Autorisierung sollte in den angebundenen Systemen technisch durchgesetzt werden und nicht allein dem Sprachmodell überlassen bleiben.
Für autonom arbeitende Agenten wird außerdem Sandboxing wichtiger. Das britische National Cyber Security Centreempfiehlt, den Zugriff eines Agenten auf Netzwerk, Daten, Credentials und Ausführungsumgebungen technisch zu begrenzen. Je größer sein Zugriff ist, desto größer kann auch der Schaden bei Fehlverhalten oder einer Kompromittierung werden.
Das gleiche Prinzip gilt für RAG-Systeme. Eine KI sollte nicht deshalb Zugriff auf sämtliche Unternehmensdokumente bekommen, weil sie theoretisch nur die richtigen davon verwenden soll. Bestehende Zugriffsrechte sollten möglichst erhalten bleiben. Wo das technisch nicht sinnvoll möglich ist, können getrennte Wissensbestände eine sauberere Lösung sein.
KI-Security: ein Kurzüberblick
Wer morgen damit anfangen möchte, braucht zunächst kein neues Security-Regelwerk mit hundert Seiten. Wichtiger ist ein belastbares Bild der eigenen KI-Nutzung.
- KI-Anwendungen und Use Cases erfassen. Unternehmen sollten wissen, welche Werkzeuge bereits genutzt werden, welche Daten darin verarbeitet werden und welche Systeme angebunden sind.
- Geeignete zentrale Werkzeuge bereitstellen. Ein kontrollierbares Angebot für Mitarbeitende ist meist sinnvoller als ein pauschales Verbot, das private Accounts und Schatten-KI begünstigt. Die Datenschutzkonferenz empfiehlt ebenfalls klare interne Regeln und betriebliche Accounts.
- Datenverarbeitung bewusst gestalten. Rechtsgrundlage, Auftragsverarbeitung, Speicherfristen, Trainingsnutzung, Administration und Betroffenenrechte müssen zum konkreten Anwendungsfall passen.
- Berechtigungen an der Aufgabe ausrichten. Eine KI, die lesen muss, braucht nicht automatisch Schreibrechte. Ein Agent sollte nur auf die Systeme und Funktionen zugreifen können, die für seinen Auftrag tatsächlich erforderlich sind.
- Kritische Aktionen technisch absichern. Das Versenden einer E-Mail, Löschen einer Datei oder Ändern eines Systems kann eine zusätzliche Freigabe rechtfertigen. Human in the Loop ist besonders dort sinnvoll, wo eine Aktion schwer rückgängig zu machen ist oder große Auswirkungen haben kann.
- Integrationen regelmäßig neu bewerten. Aus einem zunächst überschaubaren Chat kann durch zusätzliche Datenquellen und Tools schrittweise ein weitreichendes System werden. Das Risikoprofil muss deshalb mitwachsen.
KI verändert Angriffe
KI-Security betrifft nicht nur den Schutz der KI selbst. Generative Modelle verändern auch klassische Angriffe.
Das BSI beschreibt den Einsatz von LLMs für Social Engineering, personalisierte Phishing-Nachrichten und die automatisierte Erstellung sprachlich überzeugender Inhalte. Auch bei der Informationsbeschaffung und der Unterstützung cyberkrimineller Aktivitäten können generative Modelle die Arbeit von Angreifern erleichtern.
Für Unternehmen bedeutet das nicht, dass bisherige Security-Maßnahmen plötzlich wertlos werden. Im Gegenteil. Identitätsmanagement, Least Privilege, technische Zugriffskontrollen, sichere Systemgrenzen und geschulte Mitarbeitende werden noch wichtiger.
Gute KI-Security begrenzt den möglichen Schaden
Die entscheidende Frage bei KI lautet nicht, ob ein Modell irgendwann einen Fehler machen oder manipuliert werden kann. Unternehmen sollten davon ausgehen, dass beides möglich ist.
Entscheidend ist, was anschließend passieren kann.
Ein Chat ohne sensible Daten und ohne Systemzugriff hat ein anderes Risikoprofil als ein Agent mit Zugriff auf E-Mails, interne Dokumente und ausführbare Funktionen. Je mehr Komfort, Datenzugriff und Autonomie ein Unternehmen ermöglicht, desto sorgfältiger müssen Berechtigungen, Sandboxing und Freigaben gestaltet sein.
Genau darin liegt die praktische Aufgabe von KI-Security. Nicht jede Funktion maximal einzuschränken, sondern bewusst zu entscheiden, welche Freiheiten einen echten Nutzen bringen und welche zusätzlichen Risiken dafür technisch beherrscht werden müssen.
Wenn Sie Ihre bestehenden KI-Use-Cases, Berechtigungen und Integrationen einmal strukturiert auf ihr Risikoprofil prüfen möchten, schauen wir uns gemeinsam an, wo technische Grenzen sinnvoll sind und wo Sicherheitsmaßnahmen die Nutzung unnötig kompliziert machen würden.
Über den Autor: Als ISB der the consulting GmbH fokussiert sich Benedict Blümel auf die sichere und zugleich performante Implementierung von KI-Lösungen in mittelständischen Unternehmen