Berechtigungen KI Chatbot sitzen vor der Suche, nicht im Prompt

Nur ein Filter vor der Suche verhindert, dass eine Praktikantin Gehaltsdaten liest. Der KI-Chatbot darf nur Treffer erhalten, die ihre Rolle in der Datenquelle freigibt.

Suche, Kontext und Datenquelle gehören deshalb in dieselbe Berechtigungsentscheidung. Ein Chatfenster darf höchstens anzeigen, was die serverseitige Prüfung vorher zugelassen hat — alles andere ist nur Kosmetik.

Das Beispiel mit Gehaltsdaten zeigt die Grenze sehr klar. Wenn ein Datensatz nicht erlaubt ist, darf er weder im Suchtreffer noch im Modellkontext landen.

Eine Prompt-Regel reicht nicht aus, weil sie den Datenzugriff nicht sperrt. Ein Filter vor der Suche ist prüfbar, eine Anweisung im Prompt ist eine Bitte.

Sobald ein Gehaltsblatt im Kontext liegt, ist die Berechtigungsgrenze schon überschritten. Das Modell soll dann ignorieren, was es bereits gesehen hat — genau dort beginnt der Fehler.

Der Prompt eignet sich für Ton, Format und Grenzen der Antwort. Für Zugriff auf Personalakten, Verträge oder Tickets taugt er nicht als Sicherheitsgrenze.

Die Prüfung gehört in Datenbank, Retrieval oder Index, also an die Stelle der Abfrage. Dort entscheidet der Server, welche Zeilen, Dokumente oder Abschnitte überhaupt als Treffer gelten.

Row-Level-Security ist dafür ein klares Muster: Die Datenbank liefert nur Zeilen, die zur Rolle passen. Sicherheit vor Bequemlichkeit bedeutet hier, dass der Browser nie die letzte Instanz ist.

Im Migrationsablauf gehören Rechteregeln neben Tabellen, Rollen und Serverfunktionen. Jede neue Quelle braucht dieselbe Frage: Welche Rolle darf welchen Datensatz lesen, schreiben oder löschen.

Der KI-Chatbot braucht serverseitige Dienstrechte, die eng zu seinem Auftrag passen. Die Trennung lautet: Endnutzerrechte entscheiden über Inhalte, Bot-Rechte entscheiden über technische Ausführung.

Zu breite Bot-Rechte machen aus jeder Nutzerfrage eine Vollabfrage der Datenquelle. Deshalb braucht der Dienst nur Rechte, die der Server nach Rolle, Quelle und Zweck einschränkt.

Im Betrieb sehen verschiedene Rollen dieselbe Quelle unterschiedlich. Mitarbeitende sehen eigene Tickets, die Personalabteilung sieht Personalunterlagen, externe Nutzer sehen nur freigegebene Vorgänge.

Ein Bot darf nichts vererben oder erraten. Er zeigt nur Inhalte an, die eine Rolle ausdrücklich freigibt, und behandelt fehlende Freigaben wie fehlende Daten.

Das ist vor allem bei gemischten Quellen wichtig. Ein Wissensartikel, ein Ticket und eine Freigabe können im selben Index liegen, aber völlig andere Leserechte tragen.

Die Fehler sitzen meist auf der Zugriffsebene. Der Bot bekommt zu breite Datenbankrechte, der Index enthält mehr als die Quelle freigibt, oder der Browser versteckt nur Felder.

Der häufigste Bruch entsteht beim Aufbau des Suchindex. Die Quelle prüft Rechte sauber, aber der Index übernimmt alle Dokumente und verliert die Grenze zwischen Rollen.

Noch gefährlicher sind Protokolle, Exporte und Backups. Wenn Antworten, Trefferlisten oder Rohtexte dort offen liegen, entsteht neben der Datenbank eine zweite unkontrollierte Quelle.

Vor dem Go-live gehört eine Berechtigungsprüfung an jede Datenquelle und an jeden Index. Sie muss zeigen, welche Rolle welche Treffer bekommt und welche Treffer ausbleiben.

Ein Datenschutz-Check vor dem Go-live nennt sieben Punkte: Datenhygiene, Zweck und Rechtsgrundlage, Rollen, Protokollierung, Zugriff und Berechtigungen, Löschkonzept und Risiko-Check.

Für Berechtigungen zählt besonders die Gegenprobe mit echten Rollen. Eine Architekturprüfung muss testen, ob eine Praktikantin, ein externer Nutzer und eine Führungskraft unterschiedliche Treffer erhalten.

Die Minimalregel lautet: Wer etwas nicht sehen darf, bekommt es weder in Suche noch Kontext noch Antwort. Diese Regel muss vor der ersten Modellanfrage greifen.

Damit werden Berechtigungen im KI-Chatbot zu einer Architekturfrage. Der Prompt formuliert Verhalten, aber die Datenquelle entscheidet, welche Inhalte der Bot überhaupt kennen darf.