Presupunerea de conformitate pe care o fac greșit organizațiile de sănătate
Fiecare organizație de sănătate care implementează instrumente de cloud AI primește același sfat de la echipa juridică: semnează un Business Associate Agreement cu furnizorul și ești acoperit conform HIPAA.
Cerința BAA este reală. HIPAA Privacy Rule necesită entităților acoperite să execute BAA-uri cu asociații de afaceri — furnizori care creează, primesc, mențin sau transmit informații de sănătate protejate în numele lor. Furnizorul de AI care procesează notele clinice tale are nevoie de un BAA înainte să atingă acele date.
Dar cerința BAA abordează relația contractuală între organizații. Nu abordează ceea ce se întâmplă cu PHI pe infrastructura furnizorului după semnarea contractului.
Întrebarea critică nu este dacă ai un BAA. Este dacă furnizorul poate accesa PHI-ul tău în text clar — și ce se întâmplă cu acele date atunci când experimentează o încălcare.
Ce acoperă de fapt un Business Associate Agreement
Un BAA stabilește că un asociat de afaceri va:
- Folosi PHI doar pentru scopurile specificate în acord
- Implementa protecții adecvate pentru a proteja PHI
- Raporta orice încălcare PHI entității acoperite
- Returna sau distruge PHI la încetarea acordului
BAA este o obligație contractuală. Asociatul de afaceri se angajează să gestioneze PHI responsabil, să implementeze securitate rezonabilă și să notifice entitatea acoperită dacă ceva merge prost.
Ceea ce BAA nu face:
- Nu previne sistemele asociatului de afaceri să fie compromise
- Nu elimină accesul tehnic al asociatului de afaceri la PHI în formă decriptată
- Nu protejează entitatea acoperită de răspunderea HIPAA atunci când asociatul de afaceri este compromis
Atunci când un furnizor de cloud AI este compromis și stocarea lor pe server conține PHI-ul pacienților tăi în formă decriptabilă, obligația de notificare a încălcării este satisfăcută de BAA — dar expunerea PHI este reală, pacienții sunt dăunați, și entitatea acoperită se confruntă cu investigația de aplicare a HIPAA indiferent de ce contract a fost semnat.
Problema PHI pe server
Instrumentele de cloud AI care procesează date de sănătate funcționează pe o arhitectură fundamentală: datele se deplasează la serverele furnizorului, sunt procesate acolo de modelul AI și rezultatele sunt returnate utilizatorului. Pentru ca aceasta să funcționeze, infrastructura furnizorului trebuie să aibă acces la date într-o formă pe care modelul AI o poate procesa.
Aceasta înseamnă fie că datele sunt neencriptate pe serverele furnizorului, fie că criptarea este gestionată de furnizor folosind chei pe care furnizorul le controlează.
Criptarea controlată de furnizor nu este criptare end-to-end. Dacă furnizorul deține cheile, furnizorul poate decripta. Dacă furnizorul poate decripta, un server furnizor compromis expune datele tale în formă lizibilă.
Aceasta este arhitectura pe care BAA-urile nu o abordează. BAA necesită furnizorului să folosească "protecții adecvate" — dar criptarea pe server controlată de furnizor satisface acea cerință contractual, chiar dacă nu oferă protecție împotriva încălcărilor pe partea furnizorului.
Datele de sănătate procesate de cloud AI în aceste condiții au un profil de risc specific: PHI-ul folosit pentru a genera documentație clinică asistată de AI, coduri de facturare sau planuri de îngrijire există în infrastructura furnizorului într-o formă care poate fi citită dacă acea infrastructură este compromisă.
Aplicarea HIPAA nu face distincție între "am fost compromis dar am avut un BAA" și "am fost compromis." PHI-ul pacienților entității acoperite a fost expus. Entitatea acoperită avea o obligație să o protejeze. Implementarea tehnică a acelei protecții este ceea ce determină dacă obligația a fost îndeplinită — nu contractul.
Ce schimbă Zero-Knowledge Architecture
Zero-knowledge architecture abordează problema accesului pe server la nivel arhitectural.
Într-o implementare zero-knowledge, PHI este anonimizat înainte să plece din mediul entității acoperite. Furnizorul de AI primește date anonimizate — note clinice cu identificatori de pacient înlocuiți cu jetoane structurate, înregistrări de facturare cu nume și numere de cont substituite, planuri de îngrijire cu informații demografice eliminate.
Modelul AI procesează conținutul anonimizat și returnează rezultate. Entitatea acoperită re-asociază rezultatele cu înregistrarea pacientului original folosind maparea jetonului, care nu a fost niciodată transmisă furnizorului.
Ceea ce aceasta schimbă:
Furnizorul nu primește niciodată PHI. Notele clinice procesate prin anonimizare zero-knowledge nu conțin nume, date de naștere, adrese, numere de înregistrare medicală sau alți identificatori PHI definiți de HIPAA. Modelul AI al furnizorului funcționează pe date anonimizate.
O încălcare a furnizorului nu expune PHI. Dacă infrastructura furnizorului de AI este compromisă, datele stocate acolo conțin conținut anonimizat fără informații de identificare a pacientului. Încălcarea nu poate duce la expunere PHI deoarece PHI nu a fost niciodată transmis.
Cerințele BAA sunt satisfăcute la un standard mai înalt. Entitatea acoperită a implementat protecții tehnice care depășesc minimul contractual — nu pentru că BAA o necesită, ci pentru că arhitectura face expunerea PHI imposibilă din punct de vedere tehnic mai degrabă decât doar contractual interzisă.
Standardul de conformitate care de fapt se menține
Aplicarea HIPAA sub HHS Office for Civil Rights se concentrează pe dacă entitățile acoperite au implementat protecții rezonabile și adecvate pentru a proteja PHI. "Rezonabil și adecvat" este evaluat în funcție de riscul pentru PHI, probabilitatea compromiterii și costul protecțiilor disponibile.
Furnizori de cloud AI care procesează PHI sub BAA-uri au experimentat încălcări. Riscul nu este ipotetic. Întrebarea pe care o pun investigatorii de aplicare a legii este dacă entitatea acoperită a implementat protecții care au abordat profilul de risc cunoscut al relațiilor lor cu furnizori.
O entitate acoperită care s-a bazat pe un BAA și criptare pe server controlată de furnizor a luat o abordare contractuală la o problemă tehnică. O entitate acoperită care a implementat anonimizare zero-knowledge înainte de a transmite orice PHI furnizorilor de AI a luat o abordare tehnică care a eliminat expunerea.
A doua abordare abordează întrebarea de aplicare a legii: PHI nu a fost niciodată în posesia furnizorului în formă utilizabilă. Nu există încălcare de raportat, nu există pacient de notificat, nu există investigație de aplicare a legii la care să răspunzi — deoarece arhitectura a făcut modul de defecțiune imposibil.
Pentru organizațiile de sănătate care evaluează adoptarea cloud AI, cadrul de conformitate nu este "obține un BAA și continuă." Este "asigură-te că PHI nu ajunge niciodată la un mediu furnizor în formă recuperabilă." BAA satisface cerința contractuală. Zero-knowledge architecture satisface cea tehnică.
Surse: