Sicherheitsrisiken beim Einsatz von LLMs in Unternehmensprozessen

Die wichtigsten Sicherheitsrisiken beim Einsatz von LLMs in Unternehmensprozessen sind der Abfluss sensibler Daten über externe APIs, Prompt-Injection-Angriffe, unbefugter Zugriff auf Informationen durch unzureichend getrennte Daten und unkontrolliertes Handeln von Agenten in angebundenen Systemen. Die meisten davon entstehen nicht durch das Modell selbst, sondern durch die Architektur darum herum: wie das Modell mit Unternehmensdaten verbunden ist, über welche Werkzeuge es verfügt und wer seine Ausgaben sieht. Eine sauber entworfene Architektur beseitigt die meisten Risiken bereits im Entwurf statt durch nachträgliche Flicken.

Datenabfluss über externe APIs

Sendet ein Unternehmen sensible Daten ohne weitere Zusicherungen an eine öffentliche API, verlassen diese Daten die kontrollierte Umgebung. Bei manchen Anbietern besteht das Risiko, dass sie für weiteres Training verwendet oder länger gespeichert werden als erwartet.

Was hilft. Enterprise-Verträge mit der Zusicherung, dass Daten nicht zum Training verwendet werden, oder ein On-Premise- beziehungsweise EU-gehosteter Betrieb für die sensibelsten Fälle.

Prompt Injection

Ein Angreifer platziert schädliche Anweisungen direkt in den Eingabedaten — in einer E-Mail, einem Dokument oder einer Webseite, die der Agent verarbeitet —, um das System von seiner Aufgabe abzubringen: interne Informationen preiszugeben oder eine unbefugte Aktion auszuführen.

Was hilft. Strikte Trennung von Systemanweisungen und Eingabedaten, Validierung der Ausgabe vor jeder Aktion und Beschränkung der Befugnisse des Agenten auf das für die Aufgabe nötige Minimum.

Unzureichende Trennung der Zugriffsrechte

Arbeitet das System mit Daten mehrerer Abteilungen, Kunden oder Vertraulichkeitsstufen ohne saubere Filterung, kann eine Person mit geringeren Rechten eine Antwort erhalten, die auf Daten beruht, die sie nie sehen sollte.

Was hilft. Metadaten-Filterung in der Suchschicht, nicht erst in der Anwendung, und gründliche Isolationstests vor dem Start. Wie das bei mehreren Mandanten in einem System aussieht, behandelt die Multi-Tenant-Vektordatenbank.

Unkontrolliertes Handeln von Agenten

Bei Agenten mit Zugriff auf reale Systeme — CRM, ERP, E-Mail, Zahlungen — ist eine Fehlentscheidung ein echtes Risiko: falsche Information an einen Kunden, fehlerhafte Aktualisierung eines Datensatzes oder eine Aktion außerhalb des vorgesehenen Rahmens.

Was hilft. Klar definierte Befugnisgrenzen, verpflichtende menschliche Freigabe bei sensiblen Aktionen wie Zahlungen oder vertraglichen Zusagen, und laufendes Monitoring des Ausgeführten.

Halluzinationen in kritischen Prozessen

Ein Modell kann eine sachlich falsche Antwort mit hoher Sicherheit erzeugen. In Prozessen wie Compliance, Rechtsberatung oder Finanzentscheidungen kann ein solcher Fehler schwere Folgen haben.

Was hilft. Eine RAG-Architektur mit Verweis auf ein prüfbares Quelldokument statt Verlass auf das Allgemeinwissen des Modells, dazu eine klare Kennzeichnung, wo menschliche Prüfung nötig ist.

Fehlender Audit-Trail

Ohne Aufzeichnung darüber, was das System getan hat, auf welcher Datengrundlage und warum, lässt sich ein Vorfall nicht nachträglich untersuchen und Compliance bei einer Prüfung nicht belegen.

Was hilft. Protokollierung aller Eingaben, Ausgaben und ausgeführten Aktionen, aufbewahrt gemäß internen und regulatorischen Anforderungen.

Überblick

Sicherheit als Entwurfsfrage

Sicherheit wird nicht nach dem Start ergänzt. Die wirksamsten Unternehmen behandeln diese Risiken bereits im Architekturentwurf:

• Geringstmögliche Rechte – Modell oder Agent erhält nur Zugriff auf Daten und Werkzeuge, die die Aufgabe wirklich verlangt.
• Segmentierung nach Vertraulichkeit – die sensibelsten Prozesse können einen strengeren Betrieb rechtfertigen als die übrigen.
• Tests vor dem Einsatz – simulierte Angriffe einschließlich Prompt Injection und Prüfung der Datenisolation vor der Produktion.
• Laufendes Monitoring – Sicherheit ist keine einmalige Prüfung, sondern Teil des Betriebs.

Die meisten Vorfälle bei KI-Systemen sind kein Versagen des Modells. Sie sind ein Versagen der Berechtigungen.

DSGVO und EU AI Act

Beim Einsatz in der EU überschneiden sich diese Sicherheitsrisiken mit rechtlichen Pflichten. Die DSGVO verlangt eine klare Grundlage für die Verarbeitung personenbezogener Daten und den Nachweis, wo und wie verarbeitet wird. Der EU AI Act ergänzt Anforderungen an Transparenz und Risikosteuerung für Systeme, die als hochriskant eingestuft sind; dazu können auch bestimmte Unternehmensagenten in sensiblen Branchen zählen: Gesundheitswesen, Finanzwesen und Entscheidungen über Personen.