RAG dovoljenja za spletne klepetalnike: Varno upravljanje dostopa do dokumentov

Spletni klepetalnik lahko združuje odgovore s strani s pogostimi vprašanji (FAQ), dokumentacije izdelkov in internih virov znanja. To je koristno – dokler ista baza znanja ne vsebuje vsebine, ki ni namenjena vsem. V takem primeru o varnem odgovoru ne odloča le kakovost jezikovnega modela, temveč korak pridobivanja pred tem: Katerim dokumentom sploh sme dostopati ta konkretna zahteva?

RAG dovoljenja povezujejo preverjene identitete, vloge ali skupine z metapodatki na dokumentih. Klepetalnik prejme le že filtrirane vire. Cilj je namerno ozek: Model ne bi smel na podlagi poziva (prompta) odločati, ali je nekaj zaupno. Aplikacija omeji dovoljeni kontekst, dokumentira to odločitev in ob negotovosti izbere varno rezervno možnost (fallback).

Zakaj pravila v pozivih ne nadomeščajo nadzora dostopa

Sistemsko navodilo, kot je »Ne razkrivaj internih informacij«, je koristno, vendar ni plast za preverjanje dovoljenj. Če nedovoljeni dokument že vstopi v kontekst, ga lahko odgovor povzame, posredno razkrije ali na zahtevo ponovno sestavi. Tudi naknadno preverjanje besedila je prepoznega pomena in nagnjeno k napakam. Varnost se zato začne pred generiranjem in idealno pred razvrščanjem rezultatov.

Azure AI Search opisuje obrezovanje varnosti (Security Trimming) kot filtrirni vzorec: dokumenti nosijo vrednosti identitete ali skupine; poizvedba vsebuje le entitete (principale) osebe, ki daje zahtevo. Amazon Bedrock podobno opozarja, da pridobivalni filtri, ki se zavedajo ACL-jev, ne nadomeščajo preverjanja pristnosti. Vaša aplikacija mora najprej sama zanesljivo preveriti identiteto in predati le preverjeni kontekst.

Štirje gradniki zanesljive rešitve

1. Preverite identiteto in sejo na strani strežnika

Javno okno za klepet običajno nima pravic do dokumentov. Dostopa lahko le do javnih virov. Za strankarski portal ali območje za zaposlene pa se oseba identificira prek obstoječe prijave. Vlogo, organizacijo in ustrezne skupine preberite na strani strežnika iz seje ali podpisanega žetona. Nikoli se ne zanašajte na polje, ki ga prosto pošlje brskalnik, kot je role=admin, ali na sporočilo v klepetu, ki trdi pripadnost.

2. Vzdržujte metapodatke o dovoljenjih pri vsakem viru

Vsak kos besedila (chunk) poleg besedila, URL-ja in datuma posodobitve potrebuje tudi sledljive informacije o dostopu: na primer audience=public, ID najemnika (tenant ID), seznam dovoljenih skupin ali klasifikacijo. Ti metapodatki morajo izvirati iz istega poslovnega vira kot dovoljenje za dokument. Ločen list v preglednici, ki se vzdržuje le občasno, povzroča nevarna odstopanja. Pri novih dokumentih in spremembah pravic skupin je zato sinhronizacija metapodatkov del poteka objavljanja ali indeksiranja (crawl workflow).

3. Filtrirajte pred razvrščanjem (ranking)

Poizvedba sestavi filter iz preverjenega konteksta. Šele nato se ocenijo semantični ali hibridni zadetki. Tako zaupni priročnik ne more zmagati kot posebej ustrezen zadetek, da bi bil pozneje spet odstranjen. Pri več najemnikih je ID najemnika obvezen filter in ne le signal za razvrščanje. Za osebne ali posebej zaščitene podatke se poleg tega priporoča lastno podatkovno območje namesto skupne, le logično filtrirane zbirke.

4. Beležite vire in odločitve

Za podporo in analizo incidentov sami transkripti klepetov ne zadoščajo. Za vsako zahtevo mora biti sledljivo, kateri občutljivi ali neobčutljivi atributi identitete so bili uporabljeni za oblikovanje filtra, kateri razred filtra je veljal, koliko zadetkov je ostalo po filtriranju in kateri viri so dejansko vstopili v poziv. Ne shranjujte nepotrebnih celotnih vsebin ali žetonov. Podatkovno varčen revizijski dogodek omogoča iskanje napak, ne da bi iz nadzora ustvaril drugo puščanje znanja.

Praktičen potek za spletne ekipe

1. Vsak vir znanja dodelite jasni ciljni skupini: javno, stranka, partner, interna ekipa ali konkreten najemnik.
2. Določite, kateri zahtevki seje (session claims) dokazujejo to ciljno skupino. Skupine iz sistema identitet so bolj zanesljive kot prosto izbirljivi vnosi v obrazcih.
3. Te zahtevke na strani strežnika prenesite v filter za pridobivanje in dovolite le majhno, znano količino polj filtra.
4. Pri vsakem indeksiranju (crawl) izvedite primerjavo: novi, spremenjeni in odstranjeni dokumenti potrebujejo tudi posodobljene metapodatke o dovoljenjih.
5. Modelu predajte le filtrirane zadetke in jasno navodilo, naj ne ugiba manjkajočih informacij.
6. Če ni zadetkov, so viri v nasprotju ali pa so dovoljenja nejasna, preusmerite na varno kontaktno pot.

Ta potek dopolnjuje strukturiranje, opisano v našem prispevku o RAG deljenju besedila (chunking): Dobri odseki izboljšajo zadetke, vendar ne nadomeščajo nadzora dostopa. Prav tako ostajajo pomembni sveži viri; zastarelo stanje dovoljenj je hkrati težava s kakovostjo in varnostjo.

Vzorec napake: Filtriranje po pridobivanju

Pogosta napačna zasnova je naslednja: Sistem pridobi deset najboljših zadetkov, nato preveri njihove oznake in odstrani problematične dokumente. To se sprva zdi zadostno, vendar odpove zaradi stranskih učinkov. Nedovoljeni zadetek se lahko že pojavi v dnevnikih, predpomnilnikih ali izpisu za odpravljanje napak. Poleg tega njegova ocena spremeni izbiro preostalih zadetkov. Boljši je filter v sami zahtevi za pridobivanje, ki kot kandidate dovoljuje le odobrene dokumente.

Druga napaka je splošno zaupanje v funkcijo ACL posameznega ponudnika. Dokumentacija proizvajalca lahko jasno navaja, da storitev pri pridobivanju upošteva ACL-je, vendar sama ne preveri pristnosti posredovanega uporabniškega konteksta. Zato natančno preverite: Kdo preverja pristnost osebe? Od kod prihajajo skupine? Kdaj se pravice sinhronizirajo v sistem za pridobivanje? Kaj se zgodi, če metapodatki manjkajo?

Natančno zapiranje (Fail closed): Kaj naj se zgodi ob negotovosti

Ob manjkajočem zahtevku (claim), nesinhroniziranem viru ali napaki pri pridobivanju klepetalnik ne bi smel poskušati širšega iskanja. Uporabite nevtralen odgovor: Zahtevana vsebina v trenutnem kontekstu dostopa ni na voljo; človeški kontakt lahko preveri dostop. To ni pomanjkljivost pogovorne uporabniške izkušnje (Conversational UX), temveč poštena meja. Prispevek o predaji človeku (Human Handoff) prikazuje, kako se takšna predaja izvede konkretno in brez slepe ulice.

Za javne vsebine velja ista zamisel v manjši merilu: Če viri ne zadoščajo, mora bot izraziti negotovost, ponuditi preverjene povezave ali navesti kontaktno pot – namesto da si izmišljuje verjetne podrobnosti. To zmanjšuje halucinacije in preprečuje, da bi navidezno koristen odgovor pozival k napačni odobritvi.

Testni primeri, ki sodijo pred uvedbo

Preizkus dovoljenj ni enkratno preverjanje skrbnika. Ustvarite majhen zlati nabor (Golden Set) z enakimi vprašanji za več vlog: gost, registrirana stranka, pooblaščeni partner, blokiran uporabnik in skrbnik. Za vsako kombinacijo določite pričakovane vire, ne le pričakovano besedilo odgovora. Preizkusite tudi spremembe skupin, potekle seje, izbrisane dokumente, manjkajoče metapodatke ACL in izpad storitve pridobivanja.

V rezultatih preverite vsaj štiri stvari: Noben nedovoljen URL ali ID dokumenta ne pride v kontekst; dovoljeni viri ostanejo dosegljivi; odgovor ne navaja vsebin iz filtriranih dokumentov; in rezervna možnost ostane razumljiva. Te preglede dodajte svojim testom kakovosti odgovorov, da boste varnost in strokovno kakovost merili skupaj.

Pragmatična izvedba varstva podatkov in preglednosti

Podatki o dovoljenjih so sami po sebi vredni zaščite. V metapodatkih za pridobivanje uporabite čim bolj stabilne tehnične ID-je namesto imen v čistem besedilu. Revizijske dnevnike omejite na namen, obdobje in potrebne atribute. Uporabnike jasno obvestite, ko klepetalnik dostopa do prijavljenega območja, in ponudite človeško pot za vprašanja o dostopu. Ta članek ne nadomešča posamičnega pravnega svetovanja; konkretni roki hrambe in pravne podlage so odvisni od konteksta uporabe.

Tehnično se izplača jasna odgovornost: Lastniki vsebin (Content-Owners) vzdržujejo ciljne skupine, ekipa za identitete odgovarja za zahtevke in preverjanje sej, produktna ekipa pa skrbi za testiranje filtrov in rezervnih možnosti. Tako baza znanja ne postane nekontroliran bazen podatkov, temveč vir, katerega doseg ostaja sledljiv.

Seznam za preverjanje pred zagonom

• Ali je vsak nejavni vir dodeljen vlogi, skupini ali ID-ju najemnika?
• Ali kontekst poizvedbe izvira iz identitete, preverjene na strani strežnika?
• Ali filter deluje pred pridobivanjem in razvrščanjem?
• Ali se spremembe pravic in indeksiranja (crawls) sinhronizirajo skupaj?
• Ali obstajajo regresijski testi na podlagi vlog s pričakovanimi viri?
• Ali vsako neznano ali napačno stanje vodi do varne predaje?
• Ali so dnevniki podatkovno varčni in zadostni za analizo napak?

Zaključek

Dober spletni klepetalnik ne odgovori na vsako vprašanje za vsako osebo. Prikazuje le vire, ki ustrezajo preverjenemu kontekstu dostopa, ob negotovosti pa ostaja namerno zadržan. Začnite z majhno matriko virov, strežniškim filtrom in nekaj jasnimi preizkusnimi vlogami. Nato lahko postopoma razširite metapodatke o dovoljenjih, revizije in sinhronizacijo – ne da bi varnost prenesli na formulacije v pozivih.

Viri

• Microsoft Learn: Security Filter Pattern in Azure AI Search
• Microsoft Learn: Document-level access control in Azure AI Search
• Amazon Bedrock: ACL awareness enablement
• Amazon Bedrock: Document-level access controls