Auditarea Private Evolution: când garanțiile DP se întâlnesc cu atacurile reale
Un preprint recent pe arXiv (Canaries in the Bank) face ceva ce comunitatea differential privacy rareori se obosește să facă: măsoară ce se scurge efectiv dintr-un pipeline federat de date sintetice dimensionat pentru…
Auditarea Private Evolution: când garanțiile DP se întâlnesc cu atacurile reale
Un preprint recent pe arXiv (Canaries in the Bank) face ceva ce comunitatea differential privacy rareori se obosește să facă: măsoară ce se scurge efectiv dintr-un pipeline federat de date sintetice dimensionat pentru producție, apoi compară cifra respectivă cu garanția worst-case de pe hârtie. Diferența e mare și contează pentru oricine livrează date sintetice sub contracte DP.
Configurația auditului
Private Evolution (PE) este un mecanism federat de date sintetice în care clienții scorează o bancă partajată de mostre-candidat, iar serverul evoluează banca spre text cu utilitate mai mare. Auditul înlocuiește circa 1% din bancă cu probe derivate dintr-un canary cunoscut — o inserție la nivel de utilizator care permite auditorului să recupereze o limită inferioară a scurgerii la nivel de utilizator fără să atingă codul serverului. Două corpusuri, recenzii Yelp și tweeturi Sentiment140, au rulat sub opt variante de atac. Canary-urile cu text natural au rămas mult sub limita DP teoretică, așa cum era de așteptat — majoritatea textului privat seamănă cu alt text privat. Canary-urile bazate pe nonce-uri cu entropie ridicată au împins scurgerea cel mai aproape de plafonul mecanismului, adică exact cifra pe care o echipă de red team ar proiecta-o în mod deliberat.
Această distincție — inputurile naturale se comportă cuminți, inputurile adversariale forțează limita — reflectă ce susține ghidul NIST privind atacurile de confidențialitate asupra machine learning încă de când NIST AI 100-2 a apărut: ε-ul raportat rareori egalează ε-ul efectiv atins.
Ce se strică în producție
Auditul este protocol-aware, adică exploatează bucla de scoring a PE în loc să trateze mecanismul ca pe o cutie neagră. Aceasta e metoda onestă de măsurare — ghidul ENISA privind ingineria protecției datelor argumentează același lucru, într-un limbaj mai puțin tăios. O echipă care se bazează pe un ε declarat de 8 într-o lucrare ar putea opera la o limită inferioară empirică mai aproape de 2 pe workload-uri de limbaj natural, dar un atacator cu control chiar și asupra unei fracțiuni din bancă poate forța cifra în sus, spre plafonul declarat.
Un output tipic de audit arată aproximativ astfel:
2026-09-15T04:22Z pe-audit run_id=yelp-v3
probes_injected=612 (1.02% of bank)
attack=nonce_high_entropy emp_epsilon_lb=6.71 theoretical=8.00
attack=nonce_low_entropy emp_epsilon_lb=4.18
attack=paraphrase_natural emp_epsilon_lb=0.94
attack=membership_baseline emp_epsilon_lb=0.31Echipele care construiesc pipeline-uri sintetice sub GDPR Art. 5(1)(f) au nevoie de ambele cifre pe tichetul de deployment: ε-ul teoretic pentru documentația de conformitate, ε-ul empiric pentru registrul de riscuri. Să raportezi doar una e malpraxis. Literatura ACM privind auditul DP converge spre aceeași concluzie de doi ani.
Unde se poziționează CAI Technology
Livrăm corpusuri sintetice auditate din punct de vedere al confidențialității pentru clienți din domenii reglementate, iar poziția noastră e că ε-ul din contract este un punct de plecare, nu un SLA. Fiecare deployment primește o bancă de canary-uri dimensionată pe modelul de amenințare al clientului și o re-rulare trimestrială, cu suprafața de atac documentată alături de model card. Dacă furnizorul vostru nu vă poate arăta o urmă de audit empirică, cereți una — iar dacă vreți să o vedeți pe a noastră, pagina pilonului Janus conține metodologia curentă.