In unserem Artikel über den Souveränitäts-Gap von Microsoft Copilot haben wir ein Szenario beschrieben: Ein Praktikant fragt den Assistenten nach der Gehaltsstruktur im Marketing. Er bekommt eine freundliche, präzise Antwort. Die Quelle ist eine vergessene Excel-Datei in einem Archiv-Ordner, den seit Jahren niemand aufgeräumt hat. Die Datei war nie gesperrt. Sie war nur schwer zu finden. Für eine KI-Suche ist "schwer zu finden" keine Hürde mehr.
Mit dem Finger auf Copilot zu zeigen ist leicht. Dann haben wir für TheroAI eine eigene Suche über 19 lesend angebundene Anwendungen gebaut und standen vor exakt derselben Frage: Was darf der Assistent sehen, wenn er im Namen einer bestimmten Person antwortet?
Dieser Artikel erzählt, wie wir diese Frage beantwortet haben. Er erzählt auch, welchen naheliegenden Lösungsweg wir verworfen haben und wo die ehrliche Grenze unseres Ansatzes liegt.
Das Problem entsteht beim Kopieren
TheroAI beantwortet Fragen aus Unternehmenswissen. Dafür binden wir Quellen wie Google Workspace, Microsoft 365 und GitHub über lesende Konnektoren an. Damit die Suche schnell ist, indexieren wir Inhalte. Ein Index ist eine Kopie.
Genau hier entsteht das Problem. In dem Moment, in dem ein Dokument aus Google Drive in einen Suchindex kopiert wird, schützt das Berechtigungsmodell von Drive dieses Dokument nicht mehr. Drive weiß, wer die Datei öffnen darf. Der Index weiß es zunächst nicht. Ohne Gegenmaßnahme beantwortet die Suche jede Frage aus dem gesamten Bestand. Wir hätten das Praktikanten-Szenario damit in unser eigenes Produkt eingebaut.
Dazu kommt: Jede Quelle bringt ihr eigenes Berechtigungsmodell mit.
- Google Drive kennt persönliche Freigaben, Ordner-Vererbung und geteilte Ablagen.
- Postfächer in Gmail und Outlook sind grundsätzlich persönlich.
- In GitHub entscheiden Organisation, Team und Repository-Rolle über den Zugriff.
- Quer dazu liegen Gruppen, die sich ändern, sobald jemand die Abteilung wechselt.
Die Aufgabe lautet also: Diese Modelle müssen in der Suche genauso gelten wie in der Quelle selbst. Intern nennen wir das Berechtigungs-Spiegelung.
Der naheliegende Weg, den wir verworfen haben
Die offensichtliche Architektur ist schnell gebaut. Man durchsucht den kompletten Index, nimmt die besten Treffer und prüft danach für jeden Treffer, ob die anfragende Person das Dokument lesen darf. Verbotene Treffer fliegen aus der Liste. Diese Variante heißt Post-hoc-Filterung. In einer Demo sieht sie korrekt aus.
Wir haben sie aus zwei Gründen verworfen.
Erstens: Aussortierte Dokumente beeinflussen das Ergebnis trotzdem. Eine Suche liefert nie alle Treffer, sondern eine begrenzte Zahl der besten. Wenn verbotene Dokumente mitspielen, belegen sie Plätze in dieser Rangliste. Ein Dokument, das die Person lesen dürfte, rutscht dadurch aus den Top-Treffern und wird nie geladen. Die Antwort wird schlechter, und sie wird es in Abhängigkeit von Inhalten, die die Person gar nicht sehen darf. Bei Snippets wird es heikler. Wenn Textausschnitte oder Zwischenzusammenfassungen entstehen, bevor der Filter läuft, steht verbotener Inhalt bereits im Kontext des Sprachmodells. Ein Filter, der anschließend die Trefferliste kürzt, holt ihn dort nicht wieder heraus.
Zweitens: Ein veralteter Filter zitiert Dokumente, die es für die Person nicht mehr gibt. Die Prüfung nach der Suche braucht aktuelle Berechtigungsdaten im Moment der Anfrage. In der Praxis wird diese Prüfung gecacht, weil sonst jede Frage Dutzende API-Aufrufe an die Quelle auslöst. Ein Cache veraltet. Das Ergebnis: Der Assistent zitiert wörtlich aus einem Dokument, dessen Freigabe gestern entzogen wurde. Der Quellenlink unter der Antwort führt auf eine Fehlerseite. Der Inhalt steht trotzdem in der Antwort. Der Schaden passiert beim Lesen, nicht beim Klicken.
Unsere Entscheidung: Der Filter ist Teil der Suchanfrage
Wir haben den umgekehrten Weg gewählt. Berechtigungen werden zusammen mit den Inhalten indexiert, und der Berechtigungsfilter ist Bestandteil der Suchanfrage selbst.
Konkret liest jeder Konnektor beim Synchronisieren zwei Dinge aus der Quelle: den Inhalt eines Dokuments und seine Zugriffsliste. Also welche Nutzer und Gruppen lesen dürfen, inklusive aufgelöster Ordner-Vererbung. Beides landet gemeinsam im Index. Stellt jemand eine Frage, enthält die Suchanfrage neben den Suchbegriffen eine feste Bedingung: Berücksichtige ausschließlich Dokumente, deren Zugriffsliste diese Person enthält.
Ein Dokument, das eine Person nicht öffnen darf, darf auch ihre Antwort nicht beeinflussen.
Der Unterschied klingt klein und ist architektonisch groß:
- Das Ranking rechnet von Anfang an nur über Dokumente, die die Person lesen darf. Verbotene Inhalte belegen keine Plätze in der Trefferliste.
- Snippets und Antworten entstehen ausschließlich aus erlaubten Inhalten. Es gibt keine Pipeline-Stufe, in der verbotener Text kurz sichtbar war.
- Ein Dokument ohne passenden Berechtigungseintrag wird schlicht nicht gefunden. Fehlende Zugriffsinformation führt zu einem fehlenden Treffer, nie zu einem durchgerutschten. Das System fällt in die sichere Richtung.
Der Vergleich in der Übersicht:
| Aspekt | Filter nach der Suche | Filter in der Suchanfrage (TheroAI) |
|---|---|---|
| Zeitpunkt der Prüfung | Nach dem Ranking, vor der Anzeige | Während der Suche, vor dem Ranking |
| Sicht des Rankings | Gesamter Index inklusive verbotener Dokumente | Nur Dokumente mit Leserecht |
| Snippets und Kontext | Können vor dem Filter aus verbotenen Inhalten entstehen | Entstehen nur aus erlaubten Inhalten |
| Fehlende Berechtigungsdaten | Treffer erscheint im Zweifel trotzdem | Dokument wird nicht gefunden |
| Herkunft der Berechtigungsdaten | Live-Abfrage oder eigener Cache pro Anfrage | Im Index, aktualisiert per Delta-Sync |
Ein Durchstich durch das Produkt
Wie sieht das im Alltag aus? Wir folgen dem Weg, den jeder Admin bei der Einrichtung geht, und bleiben bei Google Drive als Beispiel.
Die Anbindung beginnt im Dialog "App hinzufügen". Dort stehen die 19 Anwendungen, die TheroAI lesend anbinden kann, gruppiert nach Anbieter.
Wählt der Admin Google Drive aus, öffnet sich die Einrichtung des Workspace-Konnektors. Uns war wichtig, dass die Berechtigungs-Spiegelung an dieser Stelle sichtbar ist und kein Kleingedrucktes bleibt. Die Einrichtung führt die Mitindexierung der Freigaben als eigene, abgehakte Punkte auf, direkt neben der Schritt-für-Schritt-Anleitung. Wer den Konnektor verbindet, sieht schwarz auf weiß, dass Inhalte und Berechtigungen gemeinsam eingelesen werden.
Nach dem Verbinden läuft der erste vollständige Sync. Er liest Dokumente und Zugriffslisten ein. Danach wechselt die Quelle in der Konnektor-Übersicht auf den Status "Synchronisiert". Ab diesem Moment beantwortet der Assistent Fragen aus Drive, für jede Person ausschließlich aus ihrer eigenen Sicht.
Interessant wird der Moment, in dem sich eine Berechtigung ändert. Nehmen wir den konkreten Fall: Sie entziehen in Drive einer Person die Freigabe für den Ordner "Vergütung 2026". Was passiert dann, Schritt für Schritt?
- 1.In Drive wirkt die Änderung sofort. Die Person kann die Dateien nicht mehr öffnen.
- 2.Der Konnektor erfährt davon beim nächsten Delta-Sync. Delta heißt: Wir lesen nur ein, was sich seit dem letzten Lauf geändert hat. Diese Läufe starten mehrmals pro Stunde. Wo die Quelle Änderungsbenachrichtigungen unterstützt, verarbeiten wir sie in Echtzeit statt im Intervall.
- 3.Der Sync aktualisiert die Zugriffslisten der betroffenen Dokumente im Index.
- 4.Ab jetzt erfasst die Suchanfrage dieser Person die Dokumente nicht mehr. Der Assistent findet sie nicht, zitiert sie nicht und führt sie nicht als Quelle auf. Es gibt keinen separaten Löschmechanismus in der Antwortlogik. Die Dokumente gehören für diese Person schlicht nicht mehr zum Suchraum.
Die ehrliche Grenze: so schnell wie der nächste Sync
Schritt 2 ist die Grenze unseres Ansatzes, und wir benennen sie lieber selbst: Die Spiegelung ist genauso aktuell wie der letzte Delta-Sync. Zwischen dem Entzug einer Freigabe in der Quelle und der Aktualisierung des Index liegt ein Zeitfenster. In diesem Fenster kann eine Person in Antworten noch Inhalte sehen, die sie in der Quelle bereits nicht mehr öffnen kann. Bei Quellen mit Echtzeit-Benachrichtigung ist das Fenster kurz. Im Intervall-Betrieb entspricht es dem Abstand zum nächsten Sync-Lauf.
Das gilt in beide Richtungen. Auch eine neu erteilte Freigabe wirkt erst nach dem nächsten Sync. Wer gerade Zugriff auf einen Ordner bekommen hat, bekommt Antworten daraus erst, wenn der Konnektor die Änderung gespiegelt hat.
Die Alternative wäre eine Live-Prüfung gegen die Quelle bei jeder einzelnen Frage. Sie würde jede Antwort verzögern, die API-Kontingente der Quellen belasten und das oben beschriebene Ranking-Problem trotzdem nicht lösen, weil die Kandidatenauswahl dann längst gelaufen ist. Wir halten das Sync-Fenster für den ehrlicheren Kompromiss. Und wir sagen es lieber hier, als dass Sie es im Betrieb selbst herausfinden.
Was Sie daraus mitnehmen können
Wenn Sie ein KI-Werkzeug über Ihre Datenquellen legen, unabhängig vom Anbieter, lohnen sich vier Fragen:
- Werden die Berechtigungen der Quelle zusammen mit den Inhalten indexiert, oder prüft das System erst bei der Anzeige?
- Läuft der Berechtigungsfilter vor dem Ranking oder danach? Diese Antwort entscheidet, ob verbotene Dokumente Ergebnisse beeinflussen können.
- Wie schnell kommt eine entzogene Freigabe im Index an? Lassen Sie sich das konkrete Sync-Intervall nennen. Das Wort "synchronisiert" allein beantwortet das nicht.
- Können Sie es selbst testen? Entziehen Sie in der Quelle eine Freigabe, stellen Sie dieselbe Frage erneut und beobachten Sie, wann sich die Antwort ändert.
Die vierte Frage ist die wichtigste. Eine Berechtigungs-Spiegelung, die Sie nicht überprüfen können, ist ein Versprechen. Eine, die Sie überprüfen können, ist eine Eigenschaft des Produkts.
Thero live sehen
Buchen Sie eine kurze Demo. Sie sprechen direkt mit dem Gründerteam.