On-premise ili cloud AI u zdravstvu: kompromisi uz GDPR

Odabir mjesta na kojem radi AI sustav u zdravstvu izgleda kao infrastrukturno pitanje: koji poslužitelji, koja regija, koji dobavljač. U praksi je to odluka o upravljanju podacima, a infrastruktura iz nje proizlazi. Pitanje koje razrješava većinu slučajeva nije „cloud ili on-premise?”, nego „koji podaci napuštaju našu kontrolu, u kojem obliku i tko poslije može dokazati što se s njima dogodilo?”. Odgovorite li na to precizno, model implementacije obično se nametne sam.

Ovaj vodič namijenjen je zdravstvenim startupima, klinikama, tvrtkama koje razvijaju medicinski softver i timovima za digitalno zdravstvo u Europi koji žele koristiti umjetnu inteligenciju (AI) s osjetljivim zdravstvenim podacima, a nisu sigurni je li cloud AI prihvatljiv. Vodič uspoređuje javni cloud AI, private cloud i on-premise implementaciju, objašnjava kada je svaki od tih modela opravdan i opisuje arhitekturne obrasce zahvaljujući kojima većina timova može izbjeći izbor „sve ili ništa”. Riječ je o tehničkim i strateškim smjernicama, a ne o pravnom savjetu: pravna osnova za obradu i konačna odluka o prijenosima podataka pripadaju Vašem službeniku za zaštitu podataka i pravnim savjetnicima.

Zašto zdravstveni podaci postavljaju strože zahtjeve za implementaciju AI-ja?

Zdravstveni podaci postavljaju strože zahtjeve za implementaciju AI-ja jer ih GDPR, odnosno Opća uredba o zaštiti podataka, prema članku 9. svrstava u posebnu kategoriju osobnih podataka. Njihova je obrada zabranjena osim ako je ispunjen neki od malobrojnih uvjeta, primjerice pružanje zdravstvene skrbi, javno zdravlje, znanstveno istraživanje ili izričita privola. Ta jedna klasifikacija utječe na svaki infrastrukturni izbor. Opsežna obrada zdravstvenih podataka u pravilu zahtijeva procjenu učinka na zaštitu podataka (DPIA) prema članku 35. stavku 3. točki (b), a pružatelji zdravstvene zaštite iznad propisanih pragova veličine obuhvaćeni su i Direktivom NIS2 kao sektor visoke kritičnosti, što donosi dodatne obveze upravljanja kibernetičkim rizicima. Ništa od toga ne zabranjuje AI ni cloud, ali znači da svaki tok podataka o pacijentima mora biti opravdan, zaštićen i dokumentiran, a AI sustav obično odjednom uvodi nekoliko novih tokova: upite (promptove), embeddinge, zapise (logove), skupove za evaluaciju i izlaze modela. Pet svojstava odlučuje može li implementacija zadovoljiti te zahtjeve.

Posebna kategorija podataka

Status posebne kategorije znači da je za zdravstvene podatke prije bilo kakve obrade potrebna i zakonita osnova iz članka 6. i uvjet iz članka 9., uključujući obradu koju u Vaše ime obavlja dobavljač AI rješenja. Posebna kategorija obuhvaća više od dijagnoza: povijest termina, recepti, uputnice i slobodne bilješke u kojima se spominje neko stanje također se ubrajaju. Timovi često ispravno klasificiraju očita polja, a propuste slobodni tekst, iako upravo njega jezični modeli obrađuju.

Smanjenje količine podataka

Smanjenje količine podataka, prema članku 5. stavku 1. točki (c), zahtijeva da obrada bude ograničena na ono što je nužno za svrhu. Kod AI-ja to je vrlo konkretno: model koji sažima otpusna pisma ne treba ime pacijenta, broj zdravstvenog osiguranja ni adresu da bi obavio svoj posao. Svako polje koje uklonite prije inferencije polje je koje ne može procuriti, koje pružatelj usluge ne može zadržati i za koje nije potrebna procjena prijenosa.

Kontrola pristupa

Kontrola pristupa u AI sustavu mora obuhvatiti i ono što model može dohvatiti, a ne samo tko se može prijaviti. Klinički asistent koji pretražuje svaki dokument u repozitoriju bez zadrške će prikazati zapis koji liječnik koji postavlja pitanje nikada nije bio ovlašten vidjeti. Članak 32. zahtijeva odgovarajuće tehničke mjere, a u praksi to znači da sloj za dohvat (retrieval) primjenjuje iste dozvole temeljene na ulogama kao i izvorni sustav.

Mogućnost revizije

Mogućnost revizije znači da i nekoliko mjeseci kasnije možete rekonstruirati tko je što pitao, koje je podatke sustav koristio i što je odgovorio. Načelo pouzdanosti iz članka 5. stavka 2. GDPR-a očekuje da možete dokazati usklađenost, a EU AI Act prema članku 12. zahtijeva automatsko vođenje zapisa za visokorizične sustave, pri čemu ih subjekti koji uvode sustav moraju čuvati najmanje šest mjeseci. Implementaciju koju ne možete revidirati ne možete ni obraniti.

Lokacija podataka

Lokacija podataka odnosi se na to gdje se podaci pohranjuju i obrađuju te čije ih pravo može dosegnuti. Prijenosi osobnih podataka izvan EGP-a zahtijevaju pravni mehanizam prema poglavlju V. GDPR-a, a Sud Europske unije poništio je oba prethodna okvira za prijenos između EU-a i SAD-a, 2015. i 2020. godine. Hosting u EU-u smanjuje izloženost prijenosima, ali ne rješava sve: matično društvo pružatelja usluge, pristup podrške i podizvršitelji obrade i dalje mogu biti drugdje.

Koja je razlika između cloud AI-ja, private clouda i on-premise implementacije?

Razlika između cloud AI-ja, private clouda i on-premise implementacije leži u tome tko upravlja infrastrukturom koja dolazi u doticaj s podacima o pacijentima, a time i komu morate vjerovati te koga ugovorno obvezati. Ta tri modela točke su na spektru, a ne suprotstavljeni tabori, i većina organizacija na kraju koristi više od jednog.

Javni cloud AI znači pozivanje modela koji hostira pružatelj usluge putem API-ja ili korištenje upravljane AI usluge u regiji nekog hyperscalera. Podatke šaljete van, pružatelj izvodi inferenciju, a Vi dobivate rezultat. Dobivate najsposobnije modele, gotovo nikakvo operativno opterećenje i brzu iteraciju, ali ovisite o ugovoru pružatelja, postavkama zadržavanja podataka i podizvršiteljima obrade.

Private cloud znači namjensku infrastrukturu s jednim zakupcem (single-tenant), obično u regiji EU-a, na kojoj model sami postavljate i kontrolirate: open-weight model na rezerviranim GPU instancama u Vašem vlastitom cloud računu ili namjensku implementaciju pružatelja s izoliranim zakupom. Podaci i dalje napuštaju Vašu zgradu, ali ne i Vašu administrativnu kontrolu.

On-premise znači da model radi na hardveru u Vašem vlastitom podatkovnom centru ili bolničkoj serverskoj sobi, unutar perimetra Vaše mreže. Ništa ne izlazi van osim ako to sami ne pošaljete. Snosite cjelokupno opterećenje hardvera, zakrpa, nadzora i ažuriranja modela, a ograničeni ste na modele za koje imate licencu za lokalno pokretanje.

Kako se cloud, private cloud i on-premise AI uspoređuju u zdravstvu?

Cloud, private cloud i on-premise AI razlikuju se na svakoj osi koja je u zdravstvu važna, pa korisna usporedba nije koji je „najsigurniji”, nego koje rizike svaki od njih premješta i na koga. Tablica u nastavku sažima kompromise na koje najčešće nailazimo pri definiranju opsega AI projekata u europskom zdravstvu, uključujući i hibridni model jer na njemu završava većina timova.

Dvije točke u tablici zaslužuju poseban naglasak. Prvo, sigurnost nije svojstvo lokacije: dobro vođen cloud zakup često je bolje zaštićen od bolničke serverske sobe s premalo osoblja, a rizici navedeni za on-premise stvarni su. Drugo, hibridni redak najčešći je odgovor, zbog čega su arhitekturni obrasci opisani dalje u ovom vodiču važniji od samog osnovnog izbora.

Kada je cloud AI prihvatljiv za zdravstvene podatke?

Cloud AI često je prihvatljiv za zdravstvene podatke kada su ispravni uvjeti oko njega, a ne sam cloud. Europska nadzorna tijela nisu proglasila obradu zdravstvenih podataka u cloudu nezakonitom; očekuju da je voditelj obrade opravda. Njemačka je 2024. otišla korak dalje i korištenje clouda uredila zakonom: § 393 SGB V, odredba pete knjige njemačkog Zakonika o socijalnoj sigurnosti koja uređuje zakonsko zdravstveno osiguranje, dopušta pružateljima zdravstvene zaštite i zakonskim zdravstvenim osigurateljima obradu zdravstvenih podataka u cloudu. Uvjet je da se obrada odvija u EU-u, EGP-u ili zemlji za koju postoji odluka o primjerenosti te da pružatelj usluge ima važeću C5 atestaciju njemačkog BSI-ja (Savezni ured za informacijsku sigurnost). Pet uvjeta u nastavku, prema našem iskustvu, čine cloud implementaciju opravdanom. Što ih više ispunite, to je argumentacija jača, a slučaj upotrebe koji ne ispunjava nijedan pripada sljedećem odjeljku.

Nijedan podatak koji omogućuje identifikaciju pacijenta ne napušta Vaše okruženje

Cloud AI najlakše je opravdati kada poslani podaci uopće nisu osobni podaci: istinski anonimizirani zapisi, sintetički testni podaci, objavljene smjernice ili administrativni tekst bez ikakve poveznice s pacijentom. Budite oprezni s riječju „anonimizirano”. Pseudonimizirani podaci prema članku 4. točki 5. i dalje su osobni podaci, a slobodne kliničke bilješke poznato je teško anonimizirati jer se identitet skriva u datumima, rijetkim bolestima i obiteljskim pojedinostima.

Snažne ugovorne kontrole

Snažne ugovorne kontrole počinju ugovorom o obradi podataka prema članku 28., ali za AI moraju pokriti i ono što je specifično za modele: da se Vaši ulazi i izlazi ne koriste za treniranje, koliko se dugo čuvaju upiti i odgovori te pohranjuje li nadzor zlouporabe sadržaj radi ljudskog pregleda. Mnoge poslovne AI usluge na zahtjev nude nulto ili kratko zadržavanje podataka. Neka Vam to bude potvrđeno pisanim putem, i to za konkretnu uslugu koju zaista pozivate.

Hosting u EU-u i lokacija podataka

Hosting u EU-u trebao bi značiti da se i pohrana i inferencija odvijaju u regiji EU-a, a ne samo podaci u mirovanju. Provjerite lokaciju obrade same krajnje točke modela (endpointa), jer neke usluge usmjeravaju zahtjeve onamo gdje je kapacitet trenutačno dostupan. Ako je sjedište pružatelja izvan EU-a, pitajte kako postupa sa zahtjevima državnih tijela za pristup podacima, jer hosting u EU-u tu izloženost smanjuje, ali je ne uklanja. Odgovor zabilježite u procjeni učinka prijenosa (transfer impact assessment).

Jasni uvjeti za izvršitelje i podizvršitelje obrade

Jasni uvjeti za izvršitelje i podizvršitelje obrade znače da znate svaku tvrtku koja može pristupiti podacima, a članak 28. stavak 2. daje Vam pravo prigovora na promjene. AI usluge često povezuju više pružatelja u lanac: dobavljač aplikacije poziva pružatelja modela, koji radi na infrastrukturi hyperscalera. Zatražite potpuni popis podizvršitelja obrade, informaciju o tome kako ćete biti obaviješteni o promjenama i gdje se svaka strana nalazi. Ako dobavljač ne može navesti tko izvodi inferenciju, i to je odgovor.

Ljudski pregled i vođenje zapisa

Ljudski pregled i vođenje zapisa čine cloud implementaciju obranjivom i naknadno. Za sve što utječe na skrb neka u procesu sudjeluje kliničar. Svaki zahtjev, uključene kategorije podataka, verziju modela i izlaz bilježite u spremištu koje sami kontrolirate, ne samo u konzoli pružatelja. EU AI Act upravo to očekuje za visokorizične sustave prema člancima 12. i 14., a riječ je o dobroj praksi i daleko ispod tog praga.

Kada je bolja on-premise ili privatna AI implementacija?

On-premise ili privatna AI implementacija bolji su izbor kada podaci, organizacija ili radni proces vanjsku obradu čine teško opravdanom, a ne tek neugodnom. Budite iskreni u pogledu kompromisa: odričete se najlakšeg pristupa frontier modelima i preuzimate brigu o hardveru i operacijama. Open-weight modeli ipak su znatno smanjili taj jaz. Model veličine 7 do 8 milijardi parametara radi na jednom GPU-u za podatkovne centre, a model od 70 milijardi parametara uz 4-bitnu kvantizaciju stane na jedan akcelerator od 80 GB. Za mnoge zadatke kliničke ekstrakcije, klasifikacije i sažimanja te su mogućnosti dovoljne. Pet situacija najčešće nas usmjerava prema lokalnoj ili privatnoj implementaciji.

Vrlo osjetljivi podaci o pacijentima

Vrlo osjetljivi podaci o pacijentima, poput psihijatrijskih bilježaka, zapisa o spolnom zdravlju, genetskih podataka ili zapisa o maloljetnicima, imaju teže posljedice u slučaju izloženosti, i Vaša će DPIA to pokazati. Genetski podaci zasebna su posebna kategorija prema članku 9. Kada se preostali rizik nakon svih cloud zaštitnih mjera i dalje ocjenjuje visokim, zadržavanje inferencije lokalno najizravnija je mjera ublažavanja i najlakše ju je objasniti pacijentima i nadzornim tijelima.

Bolnice sa strogim IT i sigurnosnim pravilima

Bolnice sa strogim IT i sigurnosnim pravilima često riješe pitanje prije bilo kakvog pregleda arhitekture: mnoge zabranjuju da klinički podaci napuštaju mrežu ili za svakog novog vanjskog izvršitelja obrade zahtijevaju višemjesečnu sigurnosnu provjeru. Borba protiv takve politike oduzima više vremena od gradnje unutar nje, a on-premise sustav koji prođe provjeru za nekoliko tjedana obično je bolji od cloud sustava koji godinu dana stoji u nabavi.

Procesi medicinske slikovne dijagnostike

Procesi medicinske slikovne dijagnostike snažan su argument za lokalnu inferenciju, jednako iz praktičnih kao i iz pravnih razloga. Jedna CT pretraga može imati stotine megabajta, digitalizirani patohistološki preparat (whole-slide image) može premašiti gigabajt, a podaci se već nalaze u bolničkom PACS-u. Njihovo premještanje radi inferencije dodaje latenciju, opterećuje propusnost i stvara još jednu kopiju kojom treba upravljati. DICOM zaglavlja i oznake upisane u samu sliku (burned-in) također sadrže identifikatore koje je lako previdjeti.

Interni sustavi kliničkog znanja

Interni sustavi kliničkog znanja, poput asistenata koji odgovaraju na pitanja na temelju lokalnih protokola, bolničkih lista lijekova i zapisa o pacijentima, zahtijevaju dohvat nad podacima koji su istodobno osjetljivi i zaštićeni dozvolama. Kada indeks za dohvat i model rade unutar mreže, model pristupa ostaje jednostavan: sustav nasljeđuje postojeće dozvole iz imeničkog servisa (directory) i nikada ne mora replicirati zapise u vanjsko spremište samo da bi ih pretraživao.

Podaci koji ne smiju napustiti okruženje

Podaci koji ne smiju napustiti okruženje ponekad su ugovorna činjenica, a ne procjena rizika. Istraživački podaci na koje se odnosi odobrenje etičkog povjerenstva, podaci razmijenjeni u okviru bolničkog partnerstva ili zapisi obuhvaćeni nacionalnim propisima o liječničkoj tajni mogu imati izričita ograničenja vanjske obrade. Kada je odgovor određen ugovorom ili zakonom, jedino preostalo arhitekturno pitanje jest kako isporučiti koristan AI unutar te granice.

Koji arhitekturni obrasci čine AI u zdravstvu korisnim i prilagođenim GDPR-u?

Arhitekturni obrasci koji AI u zdravstvu čine korisnim i prilagođenim GDPR-u počivaju na istoj ideji: odredite koje podatke svaka komponenta stvarno treba i granicu svoje kontrole postavite upravo tamo. Članak 25. GDPR-a to naziva tehničkom i integriranom zaštitom podataka, a takvu je zaštitu daleko lakše ugraditi od prvog dana nego naknadno dodavati nakon što DPIA ukaže na problem. Članak 32. izričito navodi pseudonimizaciju i enkripciju kao odgovarajuće sigurnosne mjere, a prvi obrazac u nastavku izravno se temelji na pseudonimizaciji. Tih pet obrazaca pokriva većinu onoga što gradimo za timove u zdravstvu i medicinskom softveru, a osmišljeni su tako da se kombiniraju, ne da se bira između njih.

Deidentifikacija prije obrade u cloudu

Deidentifikacija prije obrade u cloudu uklanja ili zamjenjuje izravne identifikatore unutar Vašeg okruženja, cloud modelu šalje samo tako umanjeni tekst, a identifikatore na povratku ponovno pridružuje lokalno. Imena, datumi, adrese i brojevi zapisa postaju dosljedni zamjenski nazivi (placeholderi), pa model i dalje može kroz cijeli dokument zaključivati o „pacijentu A”. Deidentifikator tretirajte kao komponentu kritičnu za sigurnost i mjerite njegov odziv (recall) na vlastitim dokumentima, jer je svako propušteno ime otkrivanje podataka.

Retrieval-augmented generation nad kontroliranim spremištima dokumenata

Retrieval-augmented generation (RAG) zadržava kliničko znanje u spremištu dokumenata koje sami kontrolirate i modelu u trenutku upita prosljeđuje samo nekoliko relevantnih odlomaka, umjesto da se model trenira na tim podacima. U zdravstvu to donosi tri prednosti: ništa osjetljivo nije ugrađeno u težine modela, kontrola pristupa provodi se pri dohvatu, a svaki odgovor može citirati izvorne odlomke koje je koristio, pa su izlazi sljedivi i za kliničare i za revizore.

Lokalna inferencija za osjetljive procese

Lokalna inferencija za osjetljive procese pokreće open-weight model na Vašem vlastitom hardveru ili u privatnom zakupu za korake koji dolaze u doticaj s podacima koji omogućuju identifikaciju: ekstrakciju iz uputnica, podršku pri kodiranju, sažetke za trijažu. Naša studija slučaja iz zdravstva jedan je primjer: sustav za inteligentnu obradu dokumenata implementiran u potpunosti on-premise, koji izvlači strukturirane podatke iz medicinske dokumentacije, usmjerava dokumente pravom odjelu i integrira se s postojećim bolničkim informacijskim sustavom.

Hibridne arhitekture

Hibridne arhitekture svaki zadatak usmjeravaju na najmanje izloženo mjesto koje ga može dobro obaviti. Tipična podjela izgleda ovako: dokumenti koji omogućuju identifikaciju obrađuju se lokalno, deidentificirani tekst ide jačem cloud modelu za složeno zaključivanje, a sadržaj koji se ne odnosi na pacijente, poput smjernica i internih pravila, slobodno koristi cloud usluge. Pravilo usmjeravanja mora biti izričito, testirano i zabilježeno, jer hibridni sustavi zakazuju upravo na granici između dviju strana.

Revizijski zapisi i pristup temeljen na ulogama

Revizijski zapisi i pristup temeljen na ulogama povezuju cijeli dizajn u cjelinu. Svaki zahtjev trebao bi bilježiti korisnika, njegovu ulogu, obuhvaćene kategorije podataka, dohvaćene dokumente, model i verziju te izlaz, u spremištu u koje se podaci samo dodaju (append-only) i koje ima vlastitu politiku zadržavanja. Uloge bi trebalo naslijediti iz sustava za upravljanje identitetima organizacije, a ne izmišljati ih iznova. Koliko dugo čuvati koje zapise, pročitajte u našem vodiču o čuvanju dokumentacije AI sustava prema GDPR-u i EU AI Actu.

Mijenja li on-premise implementacija Vaše obveze prema EU AI Actu?

On-premise implementacija ne mijenja Vaše obveze prema EU AI Actu, jer Akt razvrstava AI sustave prema namjeni, a ne prema tome gdje rade. Alat za podršku dijagnostici koji se prema MDR-u kvalificira kao medicinski proizvod klase IIa ili više visokorizičan je bez obzira na to radi li u bolničkom podrumu ili u regiji hyperscalera. Nakon izmjena iz paketa Digital Omnibus obveze za AI u reguliranim proizvodima poput medicinskih proizvoda primjenjuju se od 2. kolovoza 2028., a one za slučajeve upotrebe iz Priloga III., poput hitne trijaže pacijenata, od 2. prosinca 2027. Ono što implementacija mijenja jest koliko lako možete ispuniti zahtjeve: vođenje zapisa, ljudski nadzor i upravljanje podacima lakše je dokazati kada kontrolirate cijeli sustav. Kada GDPR i Akt vuku u različitim smjerovima, primjerice smanjenje količine podataka nasuprot zahtjevu Akta za reprezentativnim podacima, naša usporedba GDPR-a i EU AI Acta objašnjava tu napetost, a tekst što timovi za AI u zdravstvu trebaju pripremiti pokriva obveze. Naš rad na usklađenosti s EU AI Actom počinje klasifikacijom.

Kako odlučiti između cloud i on-premise AI-ja u zdravstvu?

Odluka između cloud i on-premise AI-ja u zdravstvu najbolje funkcionira kao strukturirana procjena jednog konkretnog slučaja upotrebe, a ne kao načelna rasprava o cloudu općenito. Ista organizacija s pravom može sažetke za trijažu izrađivati lokalno, a asistenta za smjernice pokretati u cloudu. AI Readiness Audit odgovara na to pitanje kroz fiksni slijed koraka:

1. Mapirajte tok podataka. Koje kategorije podataka slučaj upotrebe treba, gdje se danas nalaze i svako mjesto kamo bi putovali: upiti, indeksi za dohvat, zapisi i skupovi za evaluaciju.
2. Smanjite količinu podataka prije izbora. Uklonite svako polje koje zadatku nije potrebno i provjerite daje li model i s deidentificiranim ulazom prihvatljive rezultate. Već sam taj korak često premješta slučaj upotrebe iz on-premise okruženja u cloud.
3. Provjerite čvrsta ograničenja. Bolnička IT pravila, ugovori, odobrenja etičkih povjerenstava i nacionalni propisi koji određuju odgovor bez obzira na preferencije.
4. Usporedite kandidatske modele na vlastitim podacima. Izmjerite rezultate open-weight modela i cloud modela na reprezentativnom uzorku, primjenjujući disciplinu iz našeg kontrolnog popisa za validaciju medicinskog AI-ja. Ako lokalni model dosegne zadani prag, argument za slanje podataka van znatno slabi.
5. Procijenite operativni kapacitet. Imenujte tko će u drugoj godini instalirati zakrpe, nadzirati i ažurirati lokalni sustav. On-premise implementacija bez vlasnika sigurnosni je rizik, a ne zaštitna mjera.
6. Zapišite odluku. Obrazloženje zabilježite u DPIA-i i arhitekturnoj dokumentaciji, kako bi se izbor mogao obraniti i preispitati kada se modeli ili propisi promijene.

Rezultat je preporučeni model implementacije za svaki slučaj upotrebe, s navedenim razlozima i preostalim rizicima, spreman za pregled Vašeg službenika za zaštitu podataka i sigurnosnog tima. Ako je odgovor pilot, tekst o tome kako osmisliti dokaz vrijednosti u 30 do 90 dana objašnjava kako ga testirati u odnosu na zadani prag. Naša usluga AI integracije zatim ugrađuje odabranu arhitekturu u Vaše postojeće sustave, a stranica o našoj praksi AI-ja u zdravstvu opisuje širi rad s medicinskim timovima i timovima za digitalno zdravstvo.

Često postavljana pitanja

Smiju li se cloud AI usluge koristiti s podacima o pacijentima prema GDPR-u?

Da, korištenje cloud AI usluga s podacima o pacijentima može biti zakonito, ali ne automatski. Potreban Vam je uvjet iz članka 9. za obradu zdravstvenih podataka, ugovor o obradi koji pokriva treniranje i zadržavanje podataka, lokacija obrade u EU-u ili na drugi način zakonita lokacija te u pravilu DPIA. Potrošački chat alati rijetko ispunjavaju te uvjete, a poslovne usluge konfigurirane u tu svrhu mogu ih ispuniti. Vaš službenik za zaštitu podataka trebao bi potvrditi konkretnu postavu prije slanja bilo kakvih podataka o pacijentima.

Je li on-premise AI automatski usklađen s GDPR-om?

Ne, on-premise AI nije automatski usklađen s GDPR-om. On-premise implementacija uklanja pitanja prijenosa trećim stranama, ali sve ostale obveze iz GDPR-a i dalje vrijede: zakonita osnova, smanjenje količine podataka, kontrola pristupa, sigurnost prema članku 32., ograničenja zadržavanja i prava pacijenata. Loše zaštićen lokalni poslužitelj može biti rizičniji od dobro vođenog cloud zakupa. Lokacija je jedna kontrola među mnogima, a ne status usklađenosti.

Čini li pseudonimizacija podatke o pacijentima sigurnima za slanje u cloud?

Pseudonimizacija smanjuje rizik, ali podatke ne izuzima iz GDPR-a. Prema članku 4. točki 5. pseudonimizirani podaci ostaju osobni podaci sve dok postoje sredstva za ponovnu identifikaciju, čak i ako ih imate samo Vi. Pseudonimizacija je i dalje vrijedna zaštitna mjera koju GDPR izričito potiče, a smanjuje i ono što bi pružatelj usluge mogao izložiti. Tretirajte je kao mjeru ublažavanja unutar zakonite cloud postave, a ne kao način da takvu postavu zaobiđete.

Mogu li open-weight modeli koji rade lokalno parirati cloud AI-ju u kliničkim zadacima?

Za mnoge uske zadatke lokalni open-weight modeli mogu parirati cloud AI-ju. Ekstrakciju, klasifikaciju, podršku pri kodiranju i sažimanje kliničkih dokumenata open-weight modeli koji rade lokalno često dobro obavljaju, osobito u kombinaciji s dohvatom (retrieval). Frontier cloud modeli i dalje prednjače u složenom zaključivanju otvorenog tipa. Jedini pouzdan način da to saznate jest da oba pristupa testirate na reprezentativnom uzorku vlastitih dokumenata prije odluke.