Problema „cine ce poate vedea”: adăugarea permisiunilor de utilizator în aplicația ta creată cu IA

Momentul în care aplicația ta creată cu IA încetează să fie doar pentru tine e momentul în care permisiunile devin o problemă reală. Până atunci, fiecare pagină arată totul. Fiecare listă arată fiecare rând. Fiecare buton funcționează pentru toată lumea. E o aplicație de un singur jucător care se preface că e de mai mulți.

Apoi adaugi primul coleg de echipă, sau primul client, sau primul tester beta — și ei văd un lucru pe care n-ar trebui să-l vadă. Poate e salariul colegului lor. Poate e o ciornă care nu era gata. Poate sunt setările de administrator, expuse din greșeală.

Asta e problema „cine ce poate vedea”, și e cel mai mare lucru pe care creatorii non-tehnici îl greșesc când lansează un proiect făcut cu un creator de aplicații cu IA. Vestea bună: nu trebuie să devii expert în securitate ca s-o rezolvi. Ai nevoie doar de un mod clar de a-i vorbi creatorului tău cu IA despre asta.

De ce aplicația ta creată cu IA pornește permisivă

Când descrii o aplicație unui creator cu IA — „vreau un CRM în care să pot adăuga clienți și note” — creatorul optimizează pentru un singur lucru: să o facă să funcționeze pentru persoana care o descrie. Aplicația implicită e „oricine e autentificat poate vedea totul”. Asta e în regulă pentru un instrument personal. E un dezastru în clipa în care apare un al doilea utilizator.

Ăsta nu e un bug în creatorul de aplicații cu IA. E rezultatul natural al faptului că nu i-ai spus cui îi e permis să vadă ce. Creatorul habar n-are că lista ta de clienți e sensibilă, sau că „Note” ar putea conține lucruri pe care nu vrei să le vadă clienții. Trebuie să i-o spui.

Cele trei întrebări de pus înainte să adaugi un al doilea utilizator

Înainte să inviți pe cineva, întreabă-te trei lucruri. Scrie răspunsurile — i le vei da creatorului tău cu IA în pasul următor.

1. Care sunt rolurile?

Nu oamenii — categoriile. Majoritatea aplicațiilor au între două și patru. Pentru un portal de freelancer: „Eu” și „Client”. Pentru un instrument intern: „Administrator”, „Manager”, „Membru al echipei”. Pentru o aplicație de comunitate: „Moderator”, „Membru”, „Invitat”. Rezistă tentației de a trece de patru roluri devreme. Fiecare rol dublează regulile pe care trebuie să le ții minte.

2. Pentru fiecare rol, ce poate vedea?

Treci mental prin fiecare pagină din aplicația ta. Pentru fiecare, întreabă-te: ar trebui ca un Client să vadă pagina asta în general? Ar trebui să vadă toate datele de pe ea, sau doar pe ale lui? Ar trebui să vadă pagina, dar cu unele câmpuri ascunse?

Cel mai simplu tipar: proprietarii văd totul; toți ceilalți văd doar ceea ce li s-a dat acces explicit. Asta funcționează pentru 80% dintre aplicații, fără prea multă personalizare.

3. Pentru fiecare rol, ce poate face?

Același exercițiu, dar pentru butoane și acțiuni. Poate un Membru să șteargă un proiect? Poate un Client să-și editeze profilul, dar nu și planul? Poate un Manager să invite oameni noi? Majoritatea creatorilor non-tehnici uită complet pasul ăsta și ajung cu aplicații în care orice utilizator autentificat poate șterge toată baza de date cu un singur clic de buton.

Cum îi vorbești creatorului tău cu IA despre permisiuni

Odată ce ai răspunsurile, prompt-ul pentru creatorul tău cu IA se scrie singur. Arată cam așa:

Actualizează această aplicație ca să accepte două roluri: Proprietar și Client.

Proprietarii pot vedea toți clienții, toate proiectele și toate facturile. Proprietarii pot crea, edita și șterge orice.

Clienții pot vedea doar propriile proiecte și propriile facturi. Nu pot vedea lista de clienți, pagina de echipă sau pagina de setări. Își pot vizualiza proiectele, dar nu le pot edita. Își pot vizualiza și plăti propriile facturi.

Când un Client e autentificat, ascunde linkurile de navigare către Setări și Echipă. Dacă un Client încearcă să viziteze acele pagini prin URL, redirecționează-l către panoul lui de control.

Trei lucruri contează în acel prompt:

Fii specific pe pagină și acțiune. „Clienții își pot vedea proiectele” e vag. „Clienții își pot vizualiza, dar nu edita, propriile proiecte pe pagina /projects” e ceva ce un creator cu IA chiar poate implementa.
Spune ce se întâmplă cu navigarea. A ascunde linkul nu e același lucru cu a bloca pagina. Le vrei pe amândouă.
Acoperă cazul scrierii URL-ului. Altfel, un utilizator curios poate lipi /admin în bara de browser și intră direct.

Cele patru greșeli pe care le văd în fiecare săptămână

După ce am urmărit o mulțime de creatori lansând prima lor aplicație cu mai mulți utilizatori, apar aceleași greșeli:

A ascunde butonul nu înseamnă a ascunde datele. Dacă îi spui creatorului tău cu IA să „ascundă butonul de ștergere pentru Clienți”, butonul dispare de pe ecran. Dar operațiunea de ștergere din spate tot funcționează dacă cineva își dă seama cum s-o apeleze. Soluția: spune-i creatorului și să „respingă cererile de ștergere de la conturile care nu sunt Proprietar, pe backend”. Dacă creatorul nu știe ce înseamnă „backend” în aplicația ta, cere-i să „blocheze acțiunea pe server, nu doar să ascundă butonul”.

Un singur rol pentru două roluri. Oamenii confundă „cei care plătesc” cu „cei care folosesc aplicația”. Un Client care îți plătește pentru o lucrare și un Client-angajat care folosește panoul de control pe care l-ai construit pentru acel client nu sunt același rol. Dacă îi amesteci, vei petrece luna următoare cârpind reguli ad-hoc. Două roluri. Întotdeauna.

Să lași utilizatorii să invite utilizatori din prima zi. E tentant să adaugi „Invită un coleg de echipă” imediat. N-o face. Pentru primii tăi 10 utilizatori, invită-i tu însuți, de mână, dintr-un panou de administrator pe care doar tu îl poți vedea. Invitațiile de tip autoservire sunt o întreagă categorie de reguli de permisiuni (cine pe cine poate invita? ce rol primesc cei invitați? pot ei invita pe alții?). Așteaptă până când chiar ai nevoie de asta.

Să ai încredere în ce spune creatorul cu IA fără să verifici. Creatoarele cu IA îți vor spune, cu încredere, că permisiunile sunt configurate. Poate că sunt. Poate că nu. Verifică întotdeauna autentificându-te ca utilizator care nu e proprietar și încercând să faci lucruri rele: dă clic pe butoane de ștergere, lipește URL-uri de administrator, editează câmpuri pe care n-ar trebui să le poți edita. Dacă funcționează ceva ce n-ar trebui, cere-i creatorului să repare acel lucru anume.

O listă de verificare rapidă înainte să inviți pe cineva

Înainte să trimiți acea primă invitație unui al doilea utilizator, treci prin asta:

Pot enumera rolurile din aplicația mea pe degetele de la o mână.
Pentru fiecare rol, știu ce pagini ar trebui să vadă și pe care nu.
M-am autentificat ca utilizator care nu e proprietar și am confirmat că paginile greșite sunt ascunse.
Am încercat să lipesc un URL de administrator în browser ca utilizator care nu e proprietar și am fost blocat.
Am încercat să dau clic pe butoane de ștergere sau editare care ar trebui să fie interzise și am fost blocat.
Dacă ceva merge prost, am o modalitate de a retrage rapid accesul unui utilizator.

Dacă vreunul dintre punctele alea nu trece, aceea e următoarea conversație cu creatorul tău cu IA — înainte să trimiți invitația, nu după.

Schimbarea de mentalitate care ajută

A construi permisiuni pentru o aplicație cu mai mulți utilizatori înseamnă mai ales să-ți imaginezi că ești o versiune ușor băgăcioasă a celui mai prost-comportat utilizator al tău. Nu răuvoitor — doar curios. Vor da clic pe lucruri. Vor lipi URL-uri. Vor încerca să vadă ce e pe pagina de „Setări” pe care au observat-o în captura ta de ecran.

Slujba ta — și slujba creatorului tău cu IA — e să te asiguri că, atunci când se uită, răspunsul e consecvent: ori pot vedea pentru că sunt datele lor, ori nu pot vedea pentru că nu sunt. Fără margini neglijate. Fără pagini de administrator expuse din greșeală. Fără „am uitat că exista pagina aia”.

Majoritatea creatorilor nu se gândesc la permisiuni până nu se întâmplă ceva jenant. Vestea bună: 20 de minute petrecute gândindu-te la roluri înainte de lansare îți economisesc cele 20 de ore de reparat asta mai târziu, plus e-mailul pe care nu vrei să-l scrii clientului care a văzut ce nu trebuia.

Construiești ceva cu o latură pentru mai mulți utilizatori? Data viitoare când te așezi cu creatorul tău de aplicații cu IA, începe sesiunea enumerând cu voce tare rolurile din aplicația ta. E cel mai ușor obicei de cinci minute de format, și va prinde majoritatea celor mai grave greșeli înainte să se întâmple.