Accesul la AI în funcție de rol: de ce nu toți angajații ar trebui să primească aceleași instrumente și date?
Într-o firmă în care documentele de lucru au fost adunate de-a lungul anilor în aceleași câteva foldere, un asistent AI conectat la arhivă poate părea o soluție salvatoare. În loc să cauți ultima versiune a unei proceduri sau să-l întrebi pe colegul care știe pe de rost unde sunt toate, scrii o întrebare și primești răspunsul în câteva secunde. Surpriza vine atunci când aceeași aplicație găsește, cu aceeași ușurință, un contract aflat încă în negociere sau o anexă cu salariile care a rămas, din greșeală, într-un folder prea larg partajat. Informația era deja accesibilă, dar până atunci trebuia să știi unde s-o cauți.
Când compania cumpără licențe pentru inteligență artificială, decizia vizibilă ține de numărul de conturi și de prețul lor. Decizia care schimbă modul în care circulă informația vine după aceea: ce poate vedea asistentul din contul fiecărui angajat, ce are voie să facă în numele lui și în ce situații trebuie să se oprească. Două persoane pot lucra în aceeași interfață, cu același model, dar cu instrumente și surse diferite. E felul în care o firmă poate oferi acces larg la AI fără să transforme fiecare cont într-o cheie pentru toate departamentele.
O licență comună poate ascunde trei tipuri de acces
Primul este accesul la instrument. Un coleg folosește un chatbot pentru a reorganiza un text, altul caută prin procedurile interne, iar un al treilea poate cere unui agent să deschidă o solicitare în aplicația de suport. Pentru utilizator, comenzile pot arăta aproape identic. Pentru companie, diferența este mare: într-un caz rezultatul rămâne în conversație, în altul asistentul citește documente interne, iar în ultimul produce o modificare într-un sistem pe care se bazează și alți oameni.
Al doilea este accesul la date. Un specialist în vânzări are nevoie de oferta comercială, de condițiile negociate cu clienții pe care îi gestionează și de istoricul relevant pentru acele conturi. Un coleg din resurse umane poate avea nevoie de procedura privind concediile, dar accesul la dosarele individuale depinde de responsabilitățile lui. Dacă amândoi întreabă „ce știi despre această persoană?”, răspunsul depinde de sursele pe care fiecare este autorizat să le consulte și de scopul pentru care informațiile sunt folosite. Formularea întrebării nu poate înlocui această verificare.
Al treilea este dreptul de a acționa. Poți lăsa un asistent să pregătească un e-mail pentru client fără să-i permiți să-l expedieze. Îi poți da voie să citească o factură fără să-i dai acces la schimbarea contului bancar al furnizorului. Pentru o operațiune cu efecte financiare, un flux poate cere confirmarea persoanei autorizate în aplicația în care se face plata, cu destinatarul și suma la vedere. Un buton generic de confirmare, apăsat după un rezumat convingător, oferă mai puțină protecție dacă utilizatorul nu poate verifica exact ce urmează să se execute.
Rolurile sunt un punct de plecare bun, dar nu rezolvă singure accesul. Doi consultanți pot avea aceeași funcție în organigramă și pot lucra pentru clienți diferiți. Un coleg delegat pe durata unei vacanțe are nevoie de anumite drepturi pentru două săptămâni, nu până la următorul audit. În practică, funcția se combină cu proiectul, relația cu dosarul și durata mandatului. Așa eviți situația în care o permisiune acordată pentru un incident urgent rămâne activă după ce toată lumea a uitat de el.
Asistentul poate găsi în câteva secunde ce firma a partajat ani la rând
Într-un sistem care caută prin documente, modelul primește fragmente considerate relevante și le folosește pentru a redacta răspunsul. Controlul de acces trebuie făcut când serviciul selectează fragmentele, înainte ca acestea să ajungă la model. Dacă aplicația recuperează documente dintr-un index comun și speră că asistentul va ascunde pasajele confidențiale, informația a trecut deja de filtrul care trebuia s-o oprească. Același principiu se aplică atunci când răspunsurile sunt memorate pentru reutilizare: un rezumat realizat pentru un cont privilegiat nu poate deveni automat răspunsul oferit tuturor.
Un detaliu pe care îl poți rata la demonstrație este identitatea folosită de conector. Uneori, aplicația cere date folosind identitatea utilizatorului. Alteori, un cont tehnic vede mult mai mult, iar serviciul trebuie să aplice separat drepturile persoanei care a pus întrebarea. Ambele arhitecturi pot fi construite cu verificări, dar un cont tehnic foarte puternic, combinat cu filtrare incompletă, poate anula în practică separarea dintre departamente. Merită să testezi ce se întâmplă după ce muți un document într-un folder restricționat, inclusiv cât durează până când schimbarea se reflectă în index.
Conținutul pe care îl citește agentul poate încerca și să-l influențeze. Imaginează-ți o solicitare trimisă la suport în care, sub descrierea unei defecțiuni, sunt ascunse instrucțiuni pentru asistent să exporte istoricul clienților și să-l expedieze la altă adresă. Aceasta este o formă de injectare de instrucțiuni prin conținut extern. Dacă agentul nu poate vedea lista completă și nu poate trimite fișiere în afara organizației, o parte decisivă a scenariului se oprește la nivel de permisiuni, chiar dacă modelul interpretează greșit textul. OWASP descrie tocmai acest risc când instrumentele au funcții, drepturi sau autonomie excesive.
Politica de acces are și o dimensiune de confidențialitate. GDPR cere ca datele personale prelucrate să fie limitate la ceea ce este necesar pentru scopul urmărit și protejate cu măsuri potrivite riscului. O licență de companie sau o setare prin care furnizorul nu folosește conversațiile pentru antrenare poate răspunde unei întrebări contractuale, dar mai rămân de clarificat accesul intern, stocarea conversațiilor și exportul datelor. Sunt lucruri diferite. Un asistent conectat la documente poate divulga colegului nepotrivit informații pe care furnizorul nu le folosește deloc pentru antrenare.
Cum arată accesul diferențiat într-o companie obișnuită
Gândește-te la un distribuitor român care își începe proiectul cu echipele de suport, vânzări și contabilitate. La suport, asistentul caută în manuale, în procedura de garanție și în solicitarea curentă. Pregătește un răspuns pe care operatorul îl verifică. Vânzările au acces la catalog, la oferte și la conturile alocate. În contabilitate, instrumentul poate extrage câmpuri dintr-o factură și poate marca neconcordanțe, iar confirmarea documentului și aprobarea plății rămân în fluxul financiar. Toate echipele folosesc AI, dar fiecare vede în interfață doar comenzile pe care le poate folosi în activitatea sa.
Un sistem bine gândit poate refuza o cerere într-un mod util. Dacă un coleg cere situația completă a tuturor clienților, interfața îi poate spune că sunt disponibile doar conturile repartizate și îi poate arăta unde se solicită acces suplimentar. Un mesaj vag, care îl lasă să creadă că a primit un răspuns complet, creează o problemă de alt fel: va lua o decizie pe baza unui fragment despre care nu știe că este fragment. Formularea refuzului trebuie să explice limita fără să confirme existența unui dosar la care persoana nu are acces.
Dacă firma are colaboratori externi, testează un cont de invitat separat de cele interne. Dreptul de a comenta într-un proiect nu trebuie să deschidă, prin asistent, accesul la istoricul tuturor proiectelor clientului.
Diferențele de acces au nevoie și de o justificare ușor de înțeles pentru angajați. Dacă doar șefii primesc instrumente bune de traducere, redactare și căutare, o regulă prezentată drept securitate poate adânci un decalaj de productivitate care nu are legătură cu sensibilitatea datelor. Poți oferi un instrument de bază pentru toată lumea și drepturi suplimentare acolo unde există un caz de lucru documentat. Instruirea urmează aceeași logică: un operator care verifică răspunsuri către clienți are nevoie de exerciții diferite de ale colegului care administrează conectori sau aprobă comenzi externe.
Ce testezi înainte să lași AI să lucreze în numele angajaților
Dacă răspunzi de introducerea unui asistent, pornește de la câteva operațiuni concrete și descrie, pentru fiecare, ce date intră, ce rezultat iese și unde ajunge. Apoi testează conturi obișnuite, inclusiv unul care tocmai a schimbat departamentul și unul căruia i s-a revocat accesul la un proiect. Verifică dacă aceeași limită se păstrează la căutare, la export, la conversațiile distribuite și la accesul prin aplicațiile conectate. Demonstrația făcută cu un singur cont de administrator îți arată ce poate produsul; rareori îți arată cine poate face fiecare lucru după ce produsul ajunge în firmă.
Înregistrează suficiente informații pentru a putea reconstrui o operațiune: cine a solicitat-o, ce serviciu a executat-o, ce tip de resurse au fost accesate și dacă a existat o aprobare. Separă accesul la jurnal de accesul la instrument, stabilește un termen de păstrare și evită să copiezi automat conținutul integral al tuturor documentelor în loguri. Altfel, poți ajunge să protejezi foarte bine arhiva și să creezi, prin monitorizare, o a doua arhivă mai ușor de consultat decât prima.
Un test util este să dezactivezi temporar o integrare și să vezi ce se întâmplă cu oamenii care depind de ea. Dacă un coleg nu mai poate lucra deloc când asistentul pierde accesul la un sistem, procedura are nevoie de o cale de rezervă. Dacă agentul încearcă să continue cu o identitate mai puternică decât cea a utilizatorului, ai găsit o problemă de autorizare. Ambele pot rămâne ascunse cât timp aplicația funcționează impecabil în prezentare și nimeni nu schimbă nimic în configurație.
O companie știe că a rezolvat problema accesului când poate explica de ce un angajat vede o informație, de ce altul nu o vede și cine poate revoca dreptul înainte ca următoarea comandă să fie executată. Cea mai bună măsură a succesului rămâne destul de simplă: colegii găsesc mai repede lucrurile de care au nevoie, iar răspunsul la o întrebare obișnuită nu depinde de întâmplarea că un document confidențial a fost partajat cândva în locul greșit.