Chatbots ohne Datenleck: So schützen Sie sensible Informationen
Kundendaten und Geschäftsgeheimnisse dürfen das Modell nicht unkontrolliert verlassen. Welche Architektur und Filter das verhindern.
/img/chatbot-datenleck-dfm.webpEin Chatbot wird dann gefährlich, wenn er Zugriff auf mehr Daten hat, als für die beantwortete Frage nötig ist. Die wirksamste Maßnahme ist deshalb keine Ausgabefilterung, sondern eine Eingabebegrenzung: Jede Anfrage bekommt nur die Daten, die sie braucht, und das Modell sieht nie eine vollständige Kundendatenbank. In einem Projekt sank die Zahl der Anfragen mit Fremddatenbezug dadurch auf null.
Welche Architektur schützt Kundendaten?
Drei Schichten, die nacheinander greifen: Erstens ein Abrufsystem, das pro Anfrage nur die passenden Textstellen liefert statt ganzer Dokumente. Zweitens eine Rolle, die festlegt, welche Datenquellen eine Sitzung überhaupt erreichen darf. Drittens ein Modell, das ohne Werkzeugzugriff läuft – es darf also nicht selbst eine Datenbank abfragen, sondern erhält ausschließlich den vorbereiteten Ausschnitt.
Was darf ein Chatbot niemals sehen?
- ›Zugangsdaten, Schlüssel und Sitzungskennungen
- ›Vollständige Datensätze, wenn ein Feld genügt
- ›Daten anderer Mandanten oder Kunden
- ›Personenbezogene Angaben, die zur Antwort nicht nötig sind
- ›Interne Preiskalkulationen und Vertragskonditionen
Wie filtert man Ausgaben zuverlässig?
Ein Ausgabefilter ist die letzte Linie, nicht die erste. Er sucht nach Mustern, die auf Zugangsdaten, Kennungen oder Adressen hindeuten, und blockiert die Antwort, statt sie zu bereinigen. Wichtig ist, den Filter als Sperre zu bauen und nicht als Textersetzung – ein Filter, der eine Kennung durch Sternchen ersetzt, hat sie bereits ausgeliefert. Jede Sperre gehört protokolliert und ausgewertet.
Wie verhindert man, dass eine Frage die Grenze verschiebt?
Indem Anfragen die Rolle nicht ändern können. Der klassische Angriff lautet, dem System einzureden, es sei jetzt ein Administrator. Dagegen hilft keine Formulierung im Systemtext, sondern eine Prüfung außerhalb des Modells: Die Rolle wird serverseitig festgelegt und lässt sich durch keine Nachricht verändern. Ein Modell kann Anweisungen nur befolgen – es kann sie nicht durchsetzen.
Welche Rolle spielt der Vertrag?
Er entscheidet, wer für welche Verarbeitung haftet. Ein Anbieter, der Anfragen in Ihrem Auftrag verarbeitet, braucht einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO. Dazu kommen zwei Fragen: Werden Ihre Eingaben zum Training verwendet, und wo stehen die Server? Beide Antworten gehören schriftlich, nicht in eine Marketingzusage auf der Website.
Braucht man für einen Chatbot eine Einwilligung?
Kommt auf die Rechtsgrundlage an. Dient der Chatbot der Vertragsanbahnung und verarbeitet nur die eingegebenen Angaben, trägt Artikel 6 Absatz 1 Buchstabe b DSGVO das oft. Sobald Gesprächsinhalte zu anderen Zwecken ausgewertet oder für Werbung genutzt werden, braucht es eine eigene Grundlage – und die Protokollierung des Gesprächsverlaufs ist selbst eine Verarbeitung, die benannt werden muss.
Wie erkennt man ein Datenleck früh?
Durch Auswertung der Sperren. Jede Blockierung des Ausgabefilters ist ein Hinweis darauf, dass jemand an etwas geraten ist, das nicht für ihn bestimmt war. Häufen sich Sperren in einem Themenfeld, ist meist die Abrufregel zu weit gefasst. Zusätzlich lohnt ein regelmäßiger Testlauf mit Fragen, die bewusst nach fremden Daten suchen – mit dokumentiertem Ergebnis.
Was kostet der Aufwand?
Weniger als ein Vorfall. Die Eingabebegrenzung ist eine Frage der Datenmodellierung und fällt bei sauberer Struktur mit wenigen Zeilen an. Ausgabefilter und Protokollierung kosten einige Tage Arbeit, ebenso das Rechtemanagement. Ein meldepflichtiger Vorfall nach Artikel 33 DSGVO bindet dagegen Wochen und bringt eine Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden mit sich.
Begrenzen statt nachbessern
Ein sicherer Chatbot ist kein Modell mit guten Vorsätzen, sondern eine Architektur, in der das Modell gar nicht an die falschen Daten kommt. Wer Datenzugriff pro Anfrage vergibt, Ausgaben sperrt statt bereinigt und die Rolle serverseitig festhält, hat das Wesentliche getan. Prüfen Sie Ihre Abrufregeln danach noch einmal – dort sitzt der Fehler, der sich später als Leck zeigt.
Wir bauen das für Sie
Vom Artikel zur Implementierung — sprechen Sie mit uns.