By · Last updated 2026-03-10

Povratak na BlogZdravstvo

HIPAA u oblaku: Arhitektura nultog znanja za PHI

Ugovori o poslovnom suradniku ne sprječavaju HIPAA kršenja kada vaš cloud AI dobavljač obrađuje PHI u obliku čistog teksta. Evo što arhitektura nultog znanja zapravo mijenja — i zašto je BAA samo ugovorni minimum.

March 10, 20269 min čitanja
HIPAA compliancezero-knowledge architecturePHI anonymizationcloud securityBAA limitations

Pretpostavka usklađenosti koju zdravstvene organizacije pogrešno shvaćaju

Svaka zdravstvena organizacija koja raspoređuje cloud AI alate dobiva isti savjet od svog pravnog tima: potpišite Ugovor o poslovnom suradniku (BAA) s dobavljačem i pokriti ste pod HIPAA-om.

Zahtjev za BAA je stvaran. Pravilo o privatnosti HIPAA-e zahtijeva od pokrivenih subjekata da sklope BAA-ove s poslovnim suradnicima — dobavljačima koji stvaraju, primaju, održavaju ili prenose zaštićene zdravstvene informacije (PHI) u njihovo ime. AI dobavljač koji obrađuje vaše kliničke bilješke treba BAA prije nego što dotakne te podatke.

Ali zahtjev za BAA adresira ugovorni odnos između organizacija. Ne adresira što se događa s PHI-jem na infrastrukturi dobavljača nakon potpisivanja ugovora.

Kritično pitanje nije imate li BAA. To je može li dobavljač pristupiti vašem PHI-ju u obliku čistog teksta — i što se događa s tim podacima kada dožive kršenje.

Što Ugovor o poslovnom suradniku zapravo pokriva

BAA utvrđuje da će poslovni suradnik:

  • Koristiti PHI samo za svrhe navedene u ugovoru
  • Implementirati odgovarajuće zaštitne mjere za zaštitu PHI-ja
  • Prijaviti svako kršenje PHI-ja pokrivenom subjektu
  • Vratiti ili uništiti PHI po raskidu ugovora

BAA je ugovorna obveza. Poslovni suradnik se obvezuje odgovorno rukovati PHI-jem, implementirati razumnu sigurnost i obavijestiti pokriveni subjekt ako nešto pođe po krivu.

Što BAA ne čini:

  • Ne sprječava kršenje sustava poslovnog suradnika
  • Ne eliminira tehnički pristup poslovnog suradnika PHI-ju u dešifriranom obliku
  • Ne štiti pokriveni subjekt od HIPAA odgovornosti kada je poslovni suradnik hakiran

Kada je cloud AI dobavljač hakiran i pohrana na strani poslužitelja sadrži PHI vaših pacijenata u dešifriranom obliku, obveza obavješćivanja o kršenju zadovoljena je BAA-om — ali izlaganje PHI-ja je stvarno, pacijenti su oštećeni, a pokriveni subjekt suočava se s istragom provedbe HIPAA-e bez obzira koji je ugovor potpisan.

Problem PHI-ja na strani poslužitelja

Cloud AI alati koji obrađuju zdravstvene podatke rade na temeljnoj arhitekturi: podaci putuju na poslužitelje dobavljača, ondje se obrađuju AI modelom i rezultati se vraćaju korisniku. Da bi ovo funkcioniralo, infrastruktura dobavljača mora imati pristup podacima u obliku koji AI model može obraditi.

To znači da su podaci ili nešifrirani na poslužiteljima dobavljača, ili je enkripcija kojom rukuje dobavljač koristeći ključeve koje kontrolira dobavljač.

Enkripcija kontrolirana dobavljačem nije end-to-end enkripcija. Ako dobavljač drži ključeve, dobavljač može dešifrirati. Ako dobavljač može dešifrirati, kompromitirani poslužitelj dobavljača izlaže vaše podatke u čitljivom obliku.

Ovo je arhitektura koju BAA-ovi ne adresiraju. BAA zahtijeva da dobavljač koristi "odgovarajuće zaštitne mjere" — ali enkripcija na strani poslužitelja kojom kontrolira dobavljač zadovoljava taj zahtjev ugovorno, iako ne pruža zaštitu od kršenja na strani dobavljača.

Zdravstveni podaci obrađeni od strane cloud AI-a pod ovim uvjetima imaju specifičan profil rizika: PHI koji se koristi za generiranje AI-potpomognute kliničke dokumentacije, kodova za naplatu ili planova njege postoji u infrastrukturi dobavljača u obliku koji se može pročitati ako je ta infrastruktura kompromitirana.

Provedba HIPAA-e ne razlikuje "bili smo hakirani, ali imali smo BAA" i "bili smo hakirani." PHI pacijenata pokrivenog subjekta bio je izložen. Pokriveni subjekt imao je obvezu zaštititi ga. Tehnička implementacija te zaštite određuje je li obveza ispunjena — ne ugovor.

Što arhitektura nultog znanja mijenja

Arhitektura nultog znanja adresira problem pristupa na strani poslužitelja na arhitektonskoj razini.

U implementaciji nultog znanja, PHI se anonimizira prije nego napusti okruženje pokrivenog subjekta. AI dobavljač prima anonimizirane podatke — kliničke bilješke s identifikatorima pacijenata zamijenjenim strukturiranim tokenima, zapise naplate s imenima i brojevima računa zamijenjenim, planove njege s uklonjenim demografskim informacijama.

AI model obrađuje anonimizirani sadržaj i vraća rezultate. Pokriveni subjekt ponovno asociira rezultate s originalnim zapisom pacijenta koristeći mapiranje tokena, koje nikad nije preneseno dobavljaču.

Što ovo mijenja:

Dobavljač nikad ne prima PHI. Kliničke bilješke obrađene putem anonimizacije nultog znanja ne sadrže imena, datume rođenja, adrese, brojeve medicinskih kartona ili druge identifikatore PHI-ja definirane HIPAA-om. AI model dobavljača radi na anonimiziranim podacima.

Kršenje dobavljača ne izlaže PHI. Ako je infrastruktura AI dobavljača kompromitirana, podaci pohranjeni ondje sadrže anonimizirani sadržaj bez informacija koje identificiraju pacijente. Kršenje ne može rezultirati izlaganjem PHI-ja jer PHI nikad nije prenesen.

Zahtjevi BAA-a ispunjeni su na višem standardu. Pokriveni subjekt implementirao je tehničke zaštitne mjere koje nadilaze ugovorni minimum — ne zato što to BAA zahtijeva, već zato što arhitektura čini izlaganje PHI-ja tehnički nemogućim umjesto samo ugovorno zabranjenim.

Standard usklađenosti koji zapravo drži

Provedba HIPAA-e pod HHS Uredom za građanska prava fokusira se na to jesu li pokriveni subjekti implementirali razumne i odgovarajuće zaštitne mjere za zaštitu PHI-ja. "Razumno i odgovarajuće" procjenjuje se u odnosu na rizik za PHI, vjerojatnost kompromise i trošak dostupnih zaštitnih mjera.

Cloud AI dobavljači koji obrađuju PHI pod BAA-ovima doživjeli su kršenja. Rizik nije hipotetski. Pitanje koje istražitelji provedbe postavljaju jest jesu li pokriveni subjekti implementirali zaštitne mjere koje su adresirala poznati profil rizika njihovih odnosa s dobavljačima.

Pokriveni subjekt koji se oslanjao na BAA i enkripciju na strani poslužitelja kontroliranu dobavljačem uzeo je ugovorni pristup tehničkom problemu. Pokriveni subjekt koji je rasporedio anonimizaciju nultog znanja prije prenošenja bilo kakvog PHI-ja AI dobavljačima uzeo je tehnički pristup koji je eliminirao izlaganje.

Drugi pristup adresira pitanje provedbe: PHI nikad nije bio u posjedu dobavljača u upotrebljivom obliku. Nema kršenja za prijaviti, nema pacijenta za obavijestiti, nema istrage provedbe na koju treba odgovoriti — jer je arhitektura učinila način propusta nemogućim.

Za zdravstvene organizacije koje procjenjuju usvajanje cloud AI-a, okvir usklađenosti nije "nabavite BAA i nastavite." To je "osigurajte da PHI nikad ne dostignu okruženje dobavljača u obnovljivom obliku." BAA zadovoljava ugovorni zahtjev. Arhitektura nultog znanja zadovoljava tehnički.

Izvori:

Spremni za zaštitu vaših podataka?

Započnite anonimizaciju PII-a s 285+ vrsta entiteta na 48 jezika.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.