Vraag een leverancier of zijn AI-chatbot werkt op content voor leden en je krijgt meestal een enthousiast ja. Vraag hoe, en de antwoorden splitsen zich snel in twee heel verschillende architecturen, waarvan er maar één veilig is.
Waarom chatbots op basis van crawlers stoppen bij de login
De meeste AI-chatbots op de markt werken door je website te crawlen zoals een zoekmachine dat doet. Ze halen publieke pagina's op, halen de tekst eruit en indexeren die. Voor een marketingsite werkt dat prima en voor een kennisbank faalt het volledig, want de crawler botst op je loginscherm en ziet exact wat een anonieme bezoeker ziet, namelijk niets.
Sommige leveranciers stellen voor om dat te omzeilen met een serviceaccount voor de crawler. Dat is erger dan het klinkt. De crawler ziet nu alles wat dat account mag zien, en de index die hij bouwt heeft geen herinnering aan welk artikel bij welk toegangsniveau hoorde. Elke gebruiker bevraagt vervolgens één vlakke index waar alles in zit. Het enige wat dan tussen een gewoon lid en premiumcontent staat, is een instructie in een prompt, en instructies in prompts zijn geen beveiligingsmaatregel.
De architectuur die wel werkt
Een chatbot voor afgeschermde content moet in het CMS zelf zitten en de content daardoorheen lezen. Op Drupal betekent dat nodes lezen via de entity API en bij elke geïndexeerde passage de toegangsinformatie vastleggen die Drupal al bijhoudt: rollen, node access grants, Group-lidmaatschappen of lidmaatschapsniveaus.
Bij een vraag ligt de volgorde vast:
- Identificeer de gebruiker via de bestaande sessie, niet via iets wat hij ingetypt heeft.
- Bouw server-side een toegangsfilter uit zijn rollen en grants.
- Pas dat filter toe op de zoekopdracht, zodat enkel toegelaten passages opgehaald worden.
- Geef het taalmodel die passages en niets anders.
Het model krijgt afgeschermde content nooit te zien, dus geen enkele slimme prompt kan er iets uit halen. Dat is de eigenschap die je nodig hebt, en ze is enkel haalbaar door te filteren vóór het ophalen.
De subtiele lekken die het waard zijn om te kennen
Het hoofdfilter juist krijgen is noodzakelijk maar niet voldoende. Een aantal kleinere kanalen lekt informatie als je ze negeert:
- Bestaan prijsgeven. Een gewoon lid vertellen "hier bestaat een artikel over, maar je mag het niet zien" onthult iets. Soms is dat net wat je wil, omdat het upgrades oplevert. Soms is het een inbreuk op vertrouwelijkheid. Dat hoort een bewuste instelling te zijn, geen toeval.
- Gespreksgeheugen. Als de rechten van een gebruiker halverwege een sessie beperkt worden, kunnen eerdere antwoorden nog in de gespreksgeschiedenis zitten. Beoordeel toegang per vraag in plaats van per sessie.
- Logs. Zoeklogs bevatten opgehaalde passages, wat betekent dat je logsysteem nu afgeschermde content bevat. Daar horen dezelfde toegangsregels op als op de content zelf.
- Caching. Antwoorden cachen op enkel de vraagtekst serveert het toegestane antwoord van de ene gebruiker aan de andere. Elke cachesleutel moet de toegangscontext bevatten.
Waar het draait weegt hier zwaarder
Voor publieke content is tekst naar een commerciële AI-leverancier sturen een beheersbare vraag. Voor content achter een login is dat meestal niet zo, want die content staat net afgeschermd omdat ze niet bedoeld is om te reizen. Daarom duwen afgeschermde kennisbanken organisaties veel vaker richting on-premise of Europese hosting dan publieke sites doen. We vergelijken de opties in on-premise AI versus cloud-AI.
Wat je nakijkt voor je begint
Drie dingen zijn de moeite om te bevestigen voor zo'n project start. Ten eerste: klopt je toegangsmodel in het CMS vandaag eigenlijk wel? Een chatbot handhaaft de rechten die je hebt, niet die je bedoeld had in te stellen, en deze projecten leggen geregeld artikels bloot die nooit correct afgeschermd zijn. Ten tweede: kan je het controleren? Je moet voor elk antwoord kunnen tonen welke bronnen gebruikt zijn en of die gebruiker op elk daarvan recht had. Ten derde: kan je het testen? Stel als gebruiker met weinig rechten vragen die enkel uit afgeschermde content te beantwoorden zijn, en bevestig dat het systeem weigert. Die test hoort in je acceptatiecriteria, niet in een lijstje wensen.