Prima reacție a unui antreprenor când aude „conectăm ERP-ul la AI” e, pe bună dreptate, „și clienții mei?”. Baza de date a unui magazin sau a unui ERP are nume, adrese, telefoane, emailuri, uneori CNP-uri și date de card mascate. Nimic din toate astea nu trebuie să ajungă într-un model AI, și vestea bună e că nici nu are nevoie să ajungă. Aproape toate întrebările de business se pun pe sume, cantități, date și categorii, nu pe persoane. Articolul ăsta descrie cum separi cele două lumi, pe un flux pe care îl folosim la fiecare client.
Principiul: modelul citește o copie, nu producția
Nu conectăm niciodată un model direct la baza de producție a unui ERP. Nu doar din motive de securitate, ci și de performanță: o interogare analitică grea pe producție încetinește vânzările. În schimb, construim o copie analitică, actualizată zilnic (sau în timp real, printr-o replică, unde e posibil), pe un server separat. Copia e cea pe care o citește modelul, printr-un server MCP, cu un utilizator care are doar drept de citire.
Separarea asta are un efect important: tot ce se întâmplă cu datele personale se întâmplă la import, o singură dată, într-un loc pe care îl controlezi și îl poți audita. Modelul nu vede niciodată versiunea brută.
Pasul 1: inventarul datelor personale
Înainte de orice, trebuie să știi unde sunt datele personale. Într-un ERP tipic, ele apar în mai multe locuri decât te aștepți: tabela de clienți, evident, dar și adresele de livrare și facturare, comentariile de pe comenzi („sunați înainte, vecina e doamna Popescu”), tabela de utilizatori ai platformei, jurnalele de email, notele de la service, uneori chiar numele produselor personalizate. Facem inventarul automat (căutăm coloane și conținut care seamănă a email, telefon, CNP, nume) și îl verificăm manual, împreună cu cineva de la client.
Rezultatul e o listă de coloane de exclus, de pseudonimizat sau de păstrat. Lista devine parte din importul automat și se verifică la fiecare rulare: dacă apare o coloană nouă cu date personale după o actualizare a platformei, importul se oprește și alertează, în loc să o copieze.
Pasul 2: pseudonimizarea
Pseudonimizarea înseamnă să înlocuiești identitatea cu un identificator stabil. Clientul cu emailul ana.popescu@... devine client_8f31c, iar codul e același de fiecare dată, în toate tabelele, ca să poți pune întrebări despre comportament: a doua comandă, intervalul între comenzi, valoarea pe viață. Numele, adresa și telefonul nu se copiază deloc. Ce rămâne despre client e ceea ce contează pentru analiză: județul (nu strada), tipul (persoană fizică sau firmă), data primei comenzi, canalul de achiziție.
Două detalii fac diferența între o pseudonimizare corectă și una de formă:
- Cheia de pseudonimizare nu stă lângă date. Identificatorul se calculează cu o cheie secretă păstrată separat; fără ea, nimeni nu poate reface emailul din cod. Fără cheie secretă, un simplu hash al emailului se poate inversa prin încercări.
- Câmpurile libere se tratează ca date personale. Comentariile de pe comenzi, observațiile de la curier, motivele de retur conțin adesea nume și telefoane scrise de oameni. Ori le excluzi, ori le cureți cu reguli (eliminarea secvențelor care seamănă a telefon sau email), ori le păstrezi doar ca indicator („are comentariu: da/nu”).
Pentru firme (clienți B2B), practica e diferită: denumirea și CUI-ul unei societăți nu sunt date personale, dar numele persoanei de contact este. Păstrăm firma, excludem contactul.
Pasul 3: copia doar de citire și limitele pe interogare
Copia analitică primește un utilizator de bază de date cu un singur drept: SELECT. Nicio scriere, nicio modificare de structură. Serverul MCP mai adaugă două limite: timp maxim pe interogare (ca o întrebare prost formulată să nu blocheze serverul) și număr maxim de rânduri întoarse (ca modelul să primească un rezumat, nu un export de un milion de rânduri). Toate interogările se jurnalizează cu utilizatorul care le-a pus.
Dacă în viitor vrei ca modelul să și facă lucruri (să creeze o comandă către furnizor, de exemplu), acel drum trece printr-un alt canal, cu drepturi minime și cu confirmare de la un om, niciodată prin același utilizator de citire.
Pasul 4: unde stau datele și cine le poate vedea
Copia stă pe un server în UE, dedicat clientului, nu partajat. La cerere, stă pe un server al clientului. Accesul la conector e autentificat per utilizator (OAuth 2.1), deci șeful de la achiziții se conectează cu contul lui, și accesul se poate revoca separat. Ce ajunge la furnizorul de model (Anthropic, în cazul Claude) este conversația: întrebarea, descrierea tabelelor și rezultatul interogării (un tabel cu agregate), sub termenii abonamentului tău. Datele personale nu ajung, pentru că nu există în copie.
Formal, pentru GDPR, idasc e persoană împuternicită de operator (clientul) și semnăm un acord de prelucrare a datelor care descrie exact fluxul de mai sus. Pseudonimizarea nu scoate datele de sub GDPR (ele rămân date personale cât timp cheia există), dar reduce riscul la un nivel pe care orice audit îl poate accepta, și e explicit recomandată de regulament ca măsură tehnică.
Cum arată o întrebare, după toate astea
„Câți clienți noi din septembrie au mai comandat o dată în octombrie și ce au cumpărat a doua oară, pe categorie?” Modelul citește descrierea, vede că există un client_id pseudonimizat și o dată a primei comenzi, scrie interogarea, primește un tabel cu categorii și numere, îl explică. Nicio clipă nu a avut nevoie de un nume. Dacă îl întrebi „cine sunt acești clienți?”, răspunsul corect e că nu are acces la identitate, și că lista de identificatori poate fi folosită de echipa ta în ERP, unde identitatea există, cu drepturile de acolo.
Greșelile pe care le vedem cel mai des
- Lipirea unui export în prompt. Un CSV cu comenzi aruncat într-o conversație conține tot ce ai vrut să eviți și pleacă necontrolat. Dacă faci asta, măcar scoate coloanele personale înainte.
- Acces direct la producție „doar de citire”. Rezolvă scrierea, dar nu datele personale, și încarcă serverul de vânzări.
- Hash fără cheie. Un hash simplu al emailului se inversează cu o listă de emailuri. Folosește o cheie secretă.
- Câmpurile libere uitate. Comentariile de pe comenzi sunt locul în care se ascund cele mai multe telefoane.
- Lipsa verificării la fiecare import. Platforma se schimbă; o coloană nouă poate apărea oricând. Verificarea trebuie să fie automată, nu o dată la început.
Dacă vrei ca fluxul ăsta să fie construit pentru ERP-ul tău, așa lucrăm, iar întrebările despre securitate au răspunsuri aici.
Citește și: