Chatbot-Sicherheit: KI-Assistenten sicher betreiben

Warum Chatbots ein eigenes Sicherheitsthema sind

Ein klassischer regelbasierter Chatbot folgt festen Entscheidungsbäumen. Ein LLM-basierter Assistent dagegen interpretiert freie Sprache und kann nicht zuverlässig zwischen Anweisungen des Betreibers und Eingaben eines Nutzers unterscheiden – beides landet als Text im selben Kontextfenster. Daraus ergeben sich Angriffsflächen, die herkömmliche Webanwendungen so nicht kennen.

Hinzu kommt, dass moderne Assistenten selten isoliert arbeiten. Sie durchsuchen per Retrieval-Augmented Generation (RAG) interne Wissensdatenbanken, lesen Tickets und Postfächer oder lösen über Schnittstellen Aktionen aus, etwa eine Bestellung, eine Terminbuchung oder das Anlegen eines Datensatzes. Je mehr ein Chatbot „darf“, desto größer ist der mögliche Schaden bei einer erfolgreichen Manipulation.

Typische Angriffs- und Fehlerszenarien

Die OWASP Top 10 for LLM Applications (Ausgabe 2025) bieten eine gute Orientierung. Für Unternehmens-Chatbots sind vor allem folgende Punkte relevant:

• Direkte Prompt Injection: Ein Nutzer versucht mit Formulierungen wie „Ignoriere alle vorherigen Anweisungen“, Schutzregeln auszuhebeln, verbotene Inhalte zu erzeugen oder den Bot zu Zusagen zu bewegen, die das Unternehmen nicht geben will.
• Indirekte Prompt Injection: Die schädliche Anweisung steckt nicht in der Nutzereingabe, sondern in einem Dokument, einer Webseite oder einer E-Mail, die der Assistent verarbeitet. Besonders kritisch bei Assistenten, die Postfächer zusammenfassen oder Webinhalte abrufen.
• Offenlegung sensibler Informationen: Ein interner Assistent gibt Inhalte preis, die der fragende Mitarbeiter eigentlich nicht sehen dürfte – häufig, weil der RAG-Index Dokumente ohne Berücksichtigung der ursprünglichen Zugriffsrechte enthält.
• System Prompt Leakage: Angreifer entlocken dem Bot seine Systemanweisungen. Problematisch wird das vor allem, wenn dort Zugangsdaten, interne URLs oder Geschäftslogik hinterlegt sind.
• Übermäßige Handlungsfreiheit (Excessive Agency): Der Chatbot hat Schreibrechte oder Werkzeugzugriffe, die für seinen Zweck nicht nötig sind, und kann nach einer Manipulation reale Aktionen auslösen.
• Unsichere Ausgabeverarbeitung: Antworten des Modells werden ungeprüft in Webseiten, Datenbankabfragen oder Skripte übernommen – mit klassischen Folgen wie Cross-Site-Scripting.
• Unbegrenzter Ressourcenverbrauch: Automatisierte Massenanfragen treiben API-Kosten in die Höhe oder machen den Dienst unbrauchbar.

Relevanz für den Mittelstand

Viele mittelständische Unternehmen setzen Chatbots im Kundenservice oder als interne Wissensassistenten ein, oft auf Basis von Cloud-Diensten großer Anbieter. Das eigentliche Risiko liegt dabei selten im Sprachmodell selbst, sondern in der Anbindung: welche Daten indexiert werden, welche Rechte der Bot erhält und wie seine Antworten weiterverwendet werden. Außerdem müssen Unternehmen damit rechnen, für Aussagen ihres Chatbots einzustehen – in Kanada wurde eine Fluggesellschaft 2024 verpflichtet, eine von ihrem Chatbot falsch zugesagte Erstattung zu leisten.

Schutzmaßnahmen in der Praxis

1. Zweck und Datenumfang festlegen: Definieren Sie schriftlich, wofür der Assistent gedacht ist, welche Datenquellen er nutzen darf und welche Themen er ablehnen soll.
2. Berechtigungen durchreichen: Interne Assistenten sollten Dokumente nur mit den Rechten des jeweiligen Nutzers abrufen. Ein zentraler Index ohne Rechteprüfung ist ein häufiger Konstruktionsfehler.
3. Minimale Werkzeugrechte: Lesende Zugriffe bevorzugen; schreibende oder finanzwirksame Aktionen nur mit expliziter Bestätigung durch einen Menschen.
4. Keine Geheimnisse im System-Prompt: API-Schlüssel und Zugangsdaten gehören in die Backend-Logik, nicht in Anweisungen an das Modell.
5. Ein- und Ausgaben filtern: Eingabefilter gegen bekannte Injection-Muster, Ausgabefilter gegen personenbezogene Daten und Kodierung aller Ausgaben, bevor sie in HTML oder Abfragen landen.
6. Protokollierung und Monitoring: Gespräche (unter Beachtung des Datenschutzes) protokollieren, Auffälligkeiten auswerten und Missbrauchsversuche erkennen. Rate Limits und Budgetgrenzen setzen.
7. Gezielt testen: Vor dem Go-live und nach wesentlichen Änderungen Red-Teaming bzw. einen Penetrationstest mit LLM-spezifischen Testfällen durchführen.
8. Mitarbeitende einbinden: Nutzer interner Assistenten sollten wissen, welche Daten sie eingeben dürfen und dass Antworten fehlerhaft sein können.

Regulatorischer Rahmen

Nach Art. 50 des EU AI Act (Verordnung (EU) 2024/1689) müssen Menschen seit dem 2. August 2026 grundsätzlich darüber informiert werden, dass sie mit einem KI-System interagieren, sofern das nicht offensichtlich ist. Verarbeitet der Chatbot personenbezogene Daten, gelten die DSGVO-Grundsätze, insbesondere Zweckbindung, Datenminimierung und die Sicherheit der Verarbeitung nach Art. 32; bei Cloud-Anbietern ist ein Auftragsverarbeitungsvertrag erforderlich. Für NIS2-pflichtige Einrichtungen gehört ein produktiver Chatbot zudem in das reguläre Risikomanagement.

Fazit

Ein sicherer Chatbot entsteht weniger durch das „richtige“ Modell als durch saubere Architektur: begrenzte Rechte, geprüfte Datenquellen und kontrollierte Ausgaben. SecTepe unterstützt bei der Risikoanalyse und testet KI-Assistenten gezielt auf LLM-spezifische Schwachstellen.

Häufige Fragen

Lässt sich Prompt Injection vollständig verhindern?

Nach heutigem Stand nicht. Filter senken das Risiko, entscheidend ist aber, den möglichen Schaden durch minimale Berechtigungen und menschliche Freigaben zu begrenzen.

Ist ein interner Chatbot weniger riskant als ein öffentlicher?

Nicht unbedingt. Interne Assistenten haben meist Zugriff auf deutlich sensiblere Daten; fehlerhafte Rechteprüfungen können dort mehr Schaden anrichten als ein öffentlicher FAQ-Bot.