Jak legalnie trenować medyczne AI? Anonimizacja, RODO, ochrona własności intelektualnej w projektach MedTech.

Sztuczna inteligencja rewolucjonizuje współczesną medycynę. Algorytmy potrafią dziś wykrywać zmiany nowotworowe na obrazach radiologicznych z precyzją dorównującą doświadczonym lekarzom, a systemy analizujące dane pacjentów pomagają personalizować terapie w ułamku sekundy.
Jednak, aby stworzyć skuteczne narzędzia MedTech potrzebne są ogromne zbiory danych treningowych. W przypadku medycyny są to dane o zdrowiu: zdjęcia z rezonansu, opisy przypadków, wyniki badań laboratoryjnych czy historie chorób. Dla twórców technologii to ogromne wyzwanie. Dane medyczne podlegają bowiem najsurowszej ochronie prawnej.
Jak przejść przez proces uczenia maszynowego zgodnie z przepisami i nie narazić projektu na gigantyczne kary?

1. Pułapka pseudonimizacji. Dlaczego usunięcie nazwiska pacjenta to za mało?

Wielu deweloperów i managerów projektów IT zakłada, że usunięcie z bazy danych bezpośrednich identyfikatorów (np. imię, nazwisko, numer PESEL czy adres) wystarcza i sprawia, że RODO przestaje ich dotyczyć. W świetle prawa to niebezpieczny mit.

Usunięcie danych osobowych przy jednoczesnym zachowaniu unikalnego zestawu cech pacjenta (np. rzadka jednostka chorobowa, specyficzny przebieg leczenia, wiek pacjenta i lokalizacja placówki) to jedynie pseudonimizacja.

Dane spseudonimizowane wciąż są danymi osobowymi w rozumieniu RODO. Jeśli na podstawie innych dostępnych informacji (nawet posiadanych przez podmioty trzecie np. szpital) istnieje choćby teoretyczna możliwość ponownej identyfikacji pacjenta, cały zbiór nadal podlega przepisom o ochronie danych. Ocena możliwości reidentyfikacji powinna uwzględniać wszystkie sposoby, jakimi można się racjonalnie posłużyć (motyw 26 RODO) – w tym środki dostępne podmiotom trzecim. Warto również odnotować stanowisko Europejskiej Rady Ochrony Danych wyrażone w opinii 28/2024: nawet sam wytrenowany model AI nie może być automatycznie uznany za anonimowy, jeżeli możliwe jest wyodrębnienie z niego danych osób, których informacje posłużyły do treningu. Anonimowość modelu zawsze wymaga wykazania w konkretnym przypadku.

Co zrobić w takiej sytuacji?

Rozwiązaniem jest pełna, nieodwracalna anonimizacja. Proces ten polega na takim przetworzeniu danych, aby ani twórca AI, ani nikt inny (w tym jednostka dostarczająca dane) nie był w stanie powiązać informacji z konkretną osobą. Anonimizacja jest jednak procesem technicznym i prawnym – wymaga zastosowania odpowiednich modeli matematycznych oraz formalnego potwierdzenia, że proces jest trwały. Dane skutecznie zanonimizowane przestają podlegać RODO, co diametralnie upraszcza ich dalsze wykorzystanie. Należy przy tym pamiętać, że sama operacja anonimizacji stanowi przetwarzanie danych osobowych i wymaga podstawy prawnej. W praktyce najbezpieczniejszy jest model, w którym anonimizacji dokonuje placówka medyczna jako administrator danych, a na zewnątrz – do firmy technologicznej – trafiają wyłącznie dane już skutecznie zanonimizowane.

Przykład z praktyki: zbiór treningowy zawiera przypadek dziewięcioletniego pacjenta z rzadką chorobą metaboliczną, leczonego w jednym z dwóch ośrodków referencyjnych w Polsce. Mimo usunięcia imienia, nazwiska i numeru PESEL, kombinacja wieku, jednostki chorobowej i lokalizacji placówki pozwala na identyfikację dziecka każdemu, kto dysponuje podstawową wiedzą o tym środowisku klinicznym. Taki zbiór pozostaje zbiorem danych osobowych (i to szczególnej kategorii), a jego przekazanie firmie technologicznej bez właściwej podstawy prawnej naraża obie strony na odpowiedzialność.

2. Zgoda pacjenta vs. inne podstawy prawne

Intuicyjnym krokiem wydaje się zapytanie pacjentów o zgodę na wykorzystanie ich dokumentacji medycznej do trenowania modelu AI. Choć zgoda jest powszechnie stosowana w przypadku długofalowych projektów badawczo-rozwojowych wiąże się ona z ogromnym ryzykiem biznesowym. Zgodnie z RODO każdy pacjent ma prawo do wycofania zgody w dowolnym momencie, bez podawania przyczyny.

Co to oznacza dla projektu MedTech?

Jeśli pacjent wycofa zgodę po roku, jego dane należy bezpowrotnie usunąć z bazy. W skrajnym wypadku może to oznaczać konieczność trenowania modelu od zera, co generuje olbrzymie straty finansowe i czasowe. Warto przy tym doprecyzować: wycofanie zgody nie działa wstecz, więc przetwarzanie dokonane przed jej wycofaniem zasadniczo pozostaje zgodne z prawem. Obowiązek usunięcia dotyczy danych w zbiorze treningowym. W konsekwencji to, czy obejmuje również „wpływ” danych na wytrenowany już model, zależy od tego, czy model umożliwia wyodrębnienie danych osobowych, co należy oceniać w świetle przywołanej wyżej opinii EDPB 28/2024. Niepewność w tym zakresie sama w sobie stanowi jednak istotne ryzyko projektowe.

Jakie są alternatywy?

W zależności od struktury projektu, warto rozważyć inne podstawy prawne przetwarzania danych wrażliwych przewidziane w RODO, takie jak:\

  • przetwarzanie do celów badań naukowych i statystycznych (art. 9 ust. 2 lit. j RODO);
  • względy ważnego interesu publicznego w dziedzinie zdrowia publicznego (art. 9 ust. 2 lit. i RODO).

Wybór odpowiedniej ścieżki wymaga precyzyjnego zaprojektowania architektury prawnej projektu jeszcze przed zebraniem pierwszej paczki danych. Dwie kwestie mają tu jednak zasadnicze znaczenie. Po pierwsze, wyjątki z art. 9 ust. 2 RODO uchylają jedynie zakaz przetwarzania danych szczególnej kategorii, równolegle konieczne jest więc ustalenie „ogólnej” podstawy prawnej z art. 6 ust. 1 RODO. Po drugie, przesłanka badań naukowych (art. 9 ust. 2 lit. j) nie działa automatycznie i wymaga oparcia w prawie Unii lub państwa członkowskiego, zachowania proporcjonalności oraz wdrożenia zabezpieczeń przewidzianych w art. 89 ust. 1 RODO, takich jak minimalizacja danych, czy pseudonimizacja. Komercyjny projekt R&D nie zawsze zmieści się w pojęciu „badań naukowych”, a granica w każdym przypadku wymaga jednak indywidualnej oceny.

Przykład z praktyki: startup MedTech wytrenował model wykrywania zmian skórnych na kilkudziesięciu tysiącach zdjęć zebranych za zgodą pacjentów trzech klinik. Po dwóch latach jedna z klinik przekazała oświadczenia o wycofaniu zgody od kilkuset pacjentów. Spółka zmuszona była nie tylko usunąć zdjęcia ze zbioru treningowego, ale także wstrzymać wydanie nowej wersji produktu do czasu rozstrzygnięcia, czy z modelu można wyodrębnić dane tych osób. Gdyby projekt od początku oparto na danych zanonimizowanych po stronie klinik albo na właściwie skonstruowanej przesłance badawczej, ryzyko to prawdopodobnie w ogóle by nie powstało.

3. Komu przysługują prawa do danych? Własność intelektualna w relacji ze szpitalem.

Dane osobowe nie pojawiają się na serwerach start-upów samoistnie – najczęściej pozyskuje się je z baz danych szpitali, klinik czy laboratoriów. Tutaj zderzamy się z problematyką własności intelektualnej.

Bazy danych zgromadzone przez placówki medyczne są chronione na podstawie ustawy o ochronie baz danych. Pobieranie i wtórne wykorzystywanie tych danych bez formalnej umowy z daną jednostką jest złamaniem prawa. Ochrona bazy danych to jednak tylko część obrazu. Dokumentacja medyczna podlega odrębnemu, restrykcyjnemu reżimowi udostępniania na gruncie ustawy o prawach pacjenta i Rzeczniku Praw Pacjenta, a zawarte w niej informacje objęte są tajemnicą medyczną. Katalog podmiotów uprawnionych do dostępu do dokumentacji jest zamknięty, co oznacza, że placówka nie może swobodnie przekazać jej (i zawartych w niej informacji) firmie technologicznej na cele komercyjne. Bezpieczną ścieżką jest anonimizacja danych po stronie placówki jeszcze przed ich udostępnieniem albo precyzyjnie skonstruowany model współpracy badawczej z właściwą podstawą prawną przetwarzania.

Przystępując do umowy z placówką medyczną, kluczowe jest uregulowanie warunków udostępniania danych w umowie, ze szczególnym uwzględnieniem tego czy placówka przekazuje je na wyłączność oraz na jaki dokładnie czas. Niezbędne jest również rozstrzygnięcie kwestii podziału praw do wypracowanych efektów. Wytrenowany model AI, jego unikalny algorytm oraz wagi sieci neuronowej stanowią najcenniejsze aktywa start-upu, dlatego prawa do nich muszą bezdyskusyjnie należeć do twórców oprogramowania. Dopełnieniem bezpiecznego kontraktu są mocne gwarancje prawne ze strony podmiotu udostępniającego dane, który musi formalnie potwierdzić, że informacje te zostały zebrane w pełni legalnie i placówka posiada wszelkie prawa do ich dalszego transferu na cele badawczo-rozwojowe.

Przykład z praktyki: spółka technologiczna zawarła ze szpitalem klinicznym umowę o współpracy badawczej, która szczegółowo regulowała zasady dostępu do danych, ale milczała o prawach do wytrenowanego modelu. Po zakończeniu projektu szpital, powołując się na swój wkład w postaci danych i wiedzy klinicznej personelu, zażądał udziału w przychodach z komercjalizacji. Toczący się spór w konsekwencji zablokował rozmowy z inwestorami na wiele miesięcy. Negocjowanie podziału praw po powstaniu wartościowego aktywa jest nieporównanie trudniejsze niż uregulowanie tej kwestii w umowie na starcie projektu.

4. Nadchodzące wyzwania: AI Act

Warto pamiętać, że unijne przepisy AI Act klasyfikują systemy AI wykorzystywane w medycynie (zwłaszcza te będące wyrobami medycznymi podlegającymi certyfikacji MDR) jako systemy wysokiego ryzyka. Kwalifikacja następuje w tym przypadku na podstawie art. 6 ust. 1 AI Act, tzn. system AI będący wyrobem medycznym lub jego elementem bezpieczeństwa, podlegający ocenie zgodności z udziałem jednostki notyfikowanej na gruncie MDR, jest systemem wysokiego ryzyka automatycznie, tj. bez możliwości skorzystania z wyjątków (tzw. filtra) przewidzianych dla systemów z załącznika III. Zgodnie z uzgodnionym w maju 2026 r. pakietem Digital Omnibus on AI, obowiązki dotyczące systemów wysokiego ryzyka wbudowanych w produkty regulowane będą stosowane od 2 sierpnia 2028 r., co wciąż daje twórcom rozwiązań MedTech realny horyzont na przygotowanie.

AI Act nakłada na twórców takich systemów rygorystyczne obowiązki w zakresie zarządzania danymi treningowymi. Bazy danych będą musiały być poddawane audytom pod kątem reprezentatywności, braku uprzedzeń oraz podatności na błędy. Przygotowanie procesów gromadzenia danych z uwzględnieniem tych wymogów już dziś pozwala uniknąć kosztownych poprawek w przyszłości. Podstawą tych obowiązków jest art. 10 AI Act, który wymaga stosowania praktyk zarządzania danymi obejmujących m.in. ocenę adekwatności i reprezentatywności zbiorów, badanie potencjalnej „stronniczości” (bias) oraz środki jej ograniczania. Co istotne dla praktyki, art. 10 ust. 5 AI Act dopuszcza, co prawda pod ścisłymi warunkami i w zakresie absolutnie niezbędnym, przetwarzanie szczególnych kategorii danych osobowych właśnie w celu wykrywania i korygowania stronniczości systemu wysokiego ryzyka. To raczej rzadki przypadek, w którym regulacja AI wprost otwiera furtkę do przetwarzania danych wrażliwych, niedostępną na zasadach ogólnych RODO.

Na horyzoncie pozostaje również rozporządzenie w sprawie europejskiej przestrzeni danych dotyczących zdrowia (EHDS), które weszło w życie w marcu 2025 r. i będzie stosowane etapami. Docelowo EHDS stworzy sformalizowaną ścieżkę wtórnego wykorzystania elektronicznych danych zdrowotnych (w tym do trenowania algorytmów AI) za pośrednictwem organów ds. dostępu do danych zdrowotnych, na podstawie zezwoleń i w bezpiecznych środowiskach przetwarzania. Dla twórców rozwiązań MedTech oznacza to w perspektywie kilku lat nową, systemową alternatywę wobec dwustronnych umów z pojedynczymi placówkami, zapewne wartą uwzględnienia już dziś w długoterminowej strategii pozyskiwania danych.

Jeżeli planują Państwo projekt wykorzystujący dane medyczne do rozwoju rozwiązań AI – zapraszamy do kontaktu z kancelarią. Wspieramy twórców i odbiorców technologii MedTech na każdym etapie: od zaprojektowania architektury prawnej przetwarzania danych i oceny skuteczności anonimizacji, przez negocjowanie umów z placówkami medycznymi zabezpieczających prawa do wytrenowanych modeli, aż po przygotowanie do wymogów AI Act i MDR.

Ewa Trybulec | Barta & Partners

Ewa Trybulec

praktykant