Cum protejezi datele utilizatorilor în aplicația ta creată cu IA (fără o echipă de securitate)

O coach pe care o cunoaștem și-a construit într-un weekend o aplicație de urmărire a clienților cu un creator de aplicații cu IA. Note de ședință, obiective, verificări de progres — tot ce obișnuia să țină într-un caiet, acum căutabil și organizat. A funcționat atât de bine încât două coach-uri prietene au cerut să o folosească și ele.

Atunci i-a picat fisa: nu-și mai ținea propriile note. Deținea notele altora despre clienții lor — detalii de sănătate, lupte personale, nume. Dacă datele acelea s-ar scurge, n-ar fi jena ei. Ar fi a lor.

Nu ai nevoie de o echipă de securitate ca să gestionezi asta responsabil. Ai nevoie de trei obiceiuri și de disponibilitatea de a-i pune creatorului tău cu IA câteva întrebări directe. Ghidul acesta acoperă cum să protejezi datele utilizatorilor în aplicația ta creată cu IA, la nivelul care contează cu adevărat pentru un produs mic.

Începe prin a observa ce date despre utilizatori deții de fapt

Cei mai mulți creatori subestimează asta. „Eu doar am un formular de înscriere” înseamnă de obicei că ai:

• Adrese de e-mail — suficient ca să trimiți cuiva spam sau phishing.
• Nume legate de comportament — ce au cumpărat, ce au scris, când se autentifică.
• Tot ce scriu utilizatorii tăi în câmpurile de text liber — iar oamenii vor scrie orice într-un câmp de note: numere de telefon, detalii medicale, salarii, plângeri despre șeful lor.

Acordă-ți zece minute și notează fiecare informație pe care aplicația ta o stochează despre o persoană. Nu câmpurile din baza de date — sensul lor uman. „E-mailul”, „ce suplimente iau”, „notele pe care antrenorul lor le-a scris despre ei”. Lista aceea e suprafața ta de responsabilitate. Tot restul articolului e despre cum să o faci mai mică și mai sigură.

Obiceiul 1: colectează mai puțin

Cele mai ieftine date de protejat sunt datele pe care nu le-ai colectat niciodată. Înainte să protejezi orice, scurtează lista.

Parcurge lista pe care tocmai ai făcut-o și întreabă-te pentru fiecare element: folosesc asta?. Aplicația coach-ului cerea data nașterii la înscriere pentru că șablonul de înscriere al creatorului cu IA o includea. Nu a folosit-o niciodată, nicăieri. O singură frază către creatorul ei cu IA — „elimină data nașterii de la înscriere și șterge coloana” — și o întreagă categorie de date sensibile a dispărut.

Lucruri pe care aplicațiile le colectează frecvent și nu le folosesc niciodată: data nașterii, numere de telefon, adrese fizice, gen, „cum ai auzit de noi”. Dacă nu o folosești luna asta, poți întotdeauna să o ceri mai târziu. Dar nu poți anula o scurgere.

Obiceiul 2: controlează cine ce poate vedea

Există două versiuni ale acestei întrebări și ai nevoie de amândouă.

În interiorul aplicației: poate un utilizator să vadă datele altui utilizator? Dacă aplicația ta are clienți și coach-uri, poate clientul A să vadă vreodată notele clientului B? Am scris un ghid întreg despre permisiunile de utilizator în aplicația ta creată cu IA, dar pe scurt: descrie-i regula creatorului tău cu IA în limbaj simplu („un coach vede doar propriii clienți; clienții se văd doar pe ei înșiși”) și apoi testează tu însuți cu două conturi. Autentifică-te ca un utilizator și încearcă să ajungi la datele altui utilizator dând clic peste tot. Cinci minute, două conturi de test. Acest singur test prinde cea mai frecventă scurgere din aplicațiile mici.

În afara aplicației: cine poate vedea baza de date în sine? Adică tu, platforma creatorului tău cu IA și oricine ai dat date de autentificare. Ceea ce ne aduce la întrebări.

Obiceiul 3: pune-i creatorului tău aceste cinci întrebări

Nu ai nevoie să înțelegi răspunsurile în profunzime. Ai nevoie să întrebi, iar răspunsurile ar trebui să fie „da”-uri sigure. Copiază-le în creatorul tău de aplicații cu IA, câte una pe rând:

1. „Parolele utilizatorilor sunt stocate criptat (hashed) sau le poate citi oricine?” Singurul răspuns acceptabil conține cuvântul „hashed”. Dacă aplicația ta stochează parolele astfel încât oricine să le poată citi, repară asta azi — de obicei e o reparație dintr-un singur prompt, iar majoritatea creatorilor moderni fac asta corect în mod implicit.
2. „Conexiunea la aplicație este criptată (HTTPS)?” Caută lăcățelul în propriul browser. Dacă adresa aplicației tale începe cu https://, ești gata cu asta.
3. „Dacă cineva ar pune mâna pe fișierul bazei de date, ar putea citi câmpurile sensibile?” Asta e despre criptarea în repaus. Majoritatea platformelor de hosting o gestionează automat — întreabă oricum și notează răspunsul.
4. „Ce servicii terțe primesc date despre utilizatori?” Instrumente de e-mail, analiză, procesatori de plăți. Nu îi elimini — îți completezi lista, pentru că fiecare serviciu care deține datele utilizatorilor tăi face parte din suprafața ta de responsabilitate.
5. „Există un backup și cine îl poate accesa?” Backupurile sunt copii ale datelor tale, iar copiile au și ele nevoie de protecție. (Dacă nu ai configurat deloc backupuri, începe de aici.)

Salvează răspunsurile într-un document. Documentul acela e începutul posturii tale de securitate și te vei bucura că există prima dată când un client — sau avocatul unui client — îți cere socoteală.

Când cineva spune „șterge-mi datele”

Cineva o va face, în cele din urmă, iar legea în majoritatea locurilor (GDPR în Europa, reguli similare în altă parte) spune că trebuie chiar să o faci. Decide acum care e răspunsul tău:

• Poți să ștergi un utilizator și tot ce e legat de el? Cere-i creatorului tău cu IA să adauge asta — „construiește o acțiune de admin care șterge un utilizator și toate datele lui” — înainte să ai nevoie de ea sub presiunea unui termen-limită.
• Ștergerea lui din aplicație îl elimină și din instrumentul tău de e-mail și din analiză? Verifică lista de la întrebarea 4.
• Backupurile îl vor mai conține o vreme. Asta e normal și, în general, în regulă — doar fii conștient de asta, ca să o poți spune sincer.

Să răspunzi la o cerere de ștergere într-o zi pentru că te-ai pregătit arată profesionist. Să te zbați două săptămâni arată exact ca ceea ce este.

Scrie pagina de confidențialitate în limbaj simplu

Lasă deoparte deocamdată cele 4.000 de cuvinte de jargon juridic generat. Scrie cinci fraze sincere: ce colectezi, de ce, cine altcineva atinge datele (instrumentul tău de e-mail, procesatorul tău de plăți), cât timp le păstrezi și cum se poate cere ștergerea. Pune-o la /privacy și leag-o din pagina de înscriere.

Asta nu e consultanță juridică, iar dacă gestionezi date cu adevărat sensibile — sănătate, copii, finanțe — cheltuie banii pe o oră cu un avocat. Dar o pagină clară și sinceră bate una care arată impresionant și pe care nimeni n-o poate citi, iar scrierea ei te obligă să-ți cunoști cu adevărat propriile răspunsuri.

Ștacheta e mai jos decât te temi și mai sus decât zero

Nu te aperi de state naționale. Te aperi de eșecurile plictisitoare și comune: un câmp de date rămas de care nimeni nu avea nevoie, o regulă de permisiuni pe care nimeni n-a testat-o, un tabel de parole pe care cineva a uitat să-l cripteze. Protejarea datelor utilizatorilor la acest nivel nu e o abilitate de specialist — fiecare dintre acele eșecuri se poate repara cu un prompt în limbaj simplu și un test de cinci minute.

Coach-ul de la început a făcut toate astea într-o singură după-amiază: a șters două câmpuri nefolosite, a rulat testul cu două conturi (și a prins o scurgere — clienții își puteau vedea unii altora prenumele într-un meniu derulant), a pus cele cinci întrebări, a scris pagina ei de confidențialitate. Aplicația ei n-a arătat deloc diferit după aceea. Dar când prietena ei a întrebat „e chestia asta sigură pentru notele clienților mei?”, a avut un răspuns real.

Acordă-ți după-amiaza. Utilizatorii tăi ți-au dat datele pe încredere — uite cum arată să o păstrezi.