Mit Gemini, NotebookLM und den KI-Funktionen in Workspace hat Google in Rekordzeit eine ganze Produktlandschaft um generative Modelle aufgebaut. Für Unternehmen entstehen damit Effizienzvorteile – gleichzeitig aber auch technische Risiken, die sich mit klassischen Sicherheitskonzepten nur unzureichend abdecken lassen. Große Sprachmodelle verarbeiten Sprache probabilistisch und nicht regelbasiert. Gerade dieser Umstand macht sie zwar so leistungsfähig, zugleich aber auch manipulierbar.
Prompt Injection: Die neue Kategorie von Schwachstellen
Die bekannteste Angriffsklasse auf LLMs sind die sogenannten Prompt Injection. Hierbei wird der Modellkontext so verbogen, dass Anweisungen aus untergeordneten Quellen, etwa aus einer E-Mail, einem PDF oder einer Website, die Rolle einer Systemanweisung übernehmen. In der Folge vollzieht das Modell dann Aktionen, die nicht vom Betreiber intendiert waren. Bei Gemini, das über Workspace direkten Zugriff auf Kalender, Mails und Dateien haben darf, ist diese Klasse besonders kritisch, weil eine erfolgreiche Injection sofort in Datenabfluss oder Fehlbenutzung ziehen kann.
Die OWASP Top 10 for Large Language Model Applications führen Prompt Injection seit ihrer ersten Veröffentlichung als Risiko Nummer eins. Daneben findet man noch weitere Kategorien wie unsichere Ausgabeverarbeitung, Trainingsdaten-Vergiftung, Model Denial of Service und überhöhte Funktionsrechte von Agenten. Spezialisierte Testverfahren wie ein KI-Penetrationstest, etwa bei a7.de angeboten, setzen an genau diesen Punkten an und prüfen LLMs, RAG-Systeme und KI-Agenten in ihrem produktiven Umfeld, nicht im Testlabor.
RAG-Architekturen und die Frage der Datenherkunft
Die meisten Unternehmen fahren Gemini oder andere Modelle nicht als reine Chat-Oberfläche, sondern binden interne Datenquellen über Retrieval-Augmented Generation an. Dokumente aus Google Drive, Wissensdatenbanken oder Ticketsysteme werden in Vektorspeicher überführt und dann bei Bedarf in den Kontext des Modells geladen. Diese Architektur schafft Mehrwert, gefährdet aber gleichzeitig das Modellverhalten. Ein manipuliertes Dokument, das in den Index gerät, wird das langfristig beeinflussen. Zugriffsrechte, Datenklassifizierung und Herkunftsnachweise werden damit sicherheitsrelevante Kontrollmechanismen.
Zur Prüfung solcher Systeme haben sich mehrere Verfahren herausgebildet. Dazu gehören etwa strukturierte Red-Team-Übungen gegen den gesamten Datenpfad, automatisierte Fuzzing-Ansätze gegen Systemprompts oder Kennzahlen wie Erfolgsquote bei Jailbreaks, Rate erfolgreicher Datenextraktionen und mittlere Reaktionszeit auf erkannte Anomalien. Diese Kennzahlen sind eine belastbare Grundlage für den Vergleich von Fortschritten zwischen zwei Testzyklen.
Regulatorik: EU AI Act, NIS-2 und ISO 27001 im Zusammenspiel
Parallel zur technischen Diskussion entwickelt sich der regulatorische Rahmen weiter. Der EU AI Act klassifiziert KI-Systeme nach Risikostufen und verlangt für Hochrisikoanwendungen unter anderem Risikomanagement, Nachweise über die Qualität der verwendeten Daten, Protokollierung und menschliche Aufsicht. Für Betreiber kritischer Infrastrukturen kommt die NIS-2-Richtlinie hinzu, die technische und organisatorische Maßnahmen zur Cybersicherheit fordert und dabei auch Lieferketten prüft. Wer ein Managementsystem nach ISO 27001 betreibt, kann sehr viele der Anforderungen an KI-Systeme über bestehende Prozesse abdecken: Asset-Inventar, Zugriffskontrolle, Vorfallsmanagement usw.
In der Praxis kommen beim Einsatz eines LLM in der Regel drei Dokumentationsebenen zusammen: die technische (Testberichte, Modellkarten, Prompt-Governance); die organisatorische (Nutzungsrichtlinien, Rollenkonzepte, Schulungen) und die Nachweisebene gegenüber Auditoren, Kunden und Aufsichtsbehörden.
Was Unternehmen jetzt konkret prüfen sollten
Ein realistischer Einstieg besteht aus vier Schritten:
- Inventar aller produktiven und in Planung befindlichen KI-Anwendungen, mit den angebundenen Datenquellen und den Funktionsrechten.
- eine Risikoanalyse nach den OWASP-Kategorien, ergänzt um branchenspezifische Bedrohungen.
- eine technische Prüfung, entweder als isolierter LLM-Test oder als integrierter Red-Team-Ansatz, der klassische Netzwerk- und Anwendungskomponenten berücksichtigt.
- die Integration der Ergebnisse in das bestehende ISMS, damit Findings verfolgt werden können und beim nächsten Audit nachvollziehbar dokumentiert sind.
Wer Gemini und vergleichbare Systeme sicher betreiben will, kommt an strukturierten Prüfverfahren nicht vorbei. Die Technologie entwickelt sich schneller als die meisten internen Sicherheitsprozesse, und genau in dieser Lücke werden die Vorfälle der kommenden Jahre entstehen.