Twój algorytm przewiduje raka skuteczniej niż lekarz. Gratulacje. Teraz sprawdźmy, czy możesz go legalnie sprzedawać w Europie – bo AI Act, MDR i RODO mają na ten temat sporo do powiedzenia.
Polskie i zagraniczne startupy tworzą systemy AI, które analizują obrazy histopatologiczne, prowadzą autonomiczne sesje terapii poznawczo-behawioralnej, przewidują ryzyko zawału serca czy diagnozują Alzheimera na podstawie 10-sekundowego nagrania głosu. Technologia działa. Problem w tym, że zanim taki produkt trafi do pacjenta w UE, musi przejść przez trzy nakładające się reżimy regulacyjne: Rozporządzenie AI Act (EU 2024/1689), MDR (EU 2017/745) i RODO.
Jeśli budujesz produkt AI w sektorze zdrowia – diagnostykę, wspomaganie decyzji klinicznych, chatbota terapeutycznego, protezę bioniczną sterowaną sygnałami mięśniowymi – ten artykuł wyjaśni, co musisz zrobić, zanim zaczniesz sprzedawać. Pokażę harmonogram obowiązków, kryteria klasyfikacji i konkretne kroki, które warto podjąć już teraz.
Podstawowe pojęcia, które musisz znać
Zanim przejdziemy do szczegółów, uporządkujmy terminologię. Trzy regulacje operują własnymi definicjami, a ich zrozumienie warunkuje prawidłową klasyfikację Twojego produktu.
| Pojęcie | Co oznacza | Gdzie jest zdefiniowane |
|---|---|---|
| System AI wysokiego ryzyka | System AI, który – ze względu na swoje przeznaczenie – może stwarzać znaczące ryzyko dla zdrowia, bezpieczeństwa lub praw podstawowych osób fizycznych | Art. 6 AI Act |
| MDSW (oprogramowanie jako wyrób medyczny) | Oprogramowanie, które samodzielnie spełnia definicję wyrobu medycznego – ma cel diagnostyczny, terapeutyczny lub monitorujący wobec indywidualnego pacjenta | Art. 2 pkt 1 MDR 2017/745 |
| Dostawca systemu AI | Podmiot, który wprowadza system AI do obrotu lub oddaje go do użytku pod własną nazwą – nawet jeśli zlecił jego stworzenie podwykonawcy | Art. 3 AI Act |
| Podmiot stosujący | Organizacja (np. szpital, klinika), która korzysta z systemu AI w ramach swojej działalności zawodowej | Art. 3 AI Act |
| Dane szczególnych kategorii | Dane zdrowotne, biometryczne, genetyczne i inne wymienione w art. 9 ust. 1 RODO – ich przetwarzanie jest co do zasady zakazane, z wyjątkami z art. 9 ust. 2 | Art. 9 RODO |
| Ocena zgodności | Procedura weryfikująca, czy produkt spełnia wymagania regulacyjne – w zależności od klasy ryzyka może wymagać udziału jednostki notyfikowanej (niezależnego audytora) | Art. 43 AI Act, Załącznik IX MDR |
Jedno zastrzeżenie: Komisja Europejska ma przedstawić wytyczne z praktycznymi przykładami systemów AI wysokiego ryzyka nie później niż 2 lutego 2026 r. Do tego czasu firmy muszą samodzielnie oceniać klasyfikację swoich produktów – i dokumentować tę ocenę.
Dlaczego Twój produkt AI prawdopodobnie jest systemem wysokiego ryzyka
AI Act klasyfikuje systemy AI według poziomu ryzyka. Dla sektora zdrowia oznacza to, że zdecydowana większość produktów AI trafia do kategorii wysokiego ryzyka – i to dwiema niezależnymi ścieżkami.
Ścieżka 1: przez MDR (art. 6 ust. 1 AI Act)
System AI jest automatycznie systemem wysokiego ryzyka, jeżeli spełnia łącznie dwa warunki:
- Jest elementem związanym z bezpieczeństwem wyrobu medycznego objętego MDR 2017/745 (lub IVDR 2017/746) albo sam stanowi taki wyrób.
- Dany wyrób podlega ocenie zgodności przez jednostkę notyfikowaną – a tak jest dla wszystkich wyrobów medycznych klasy IIa i wyższych.
Reguła 11 Załącznika VIII MDR klasyfikuje oprogramowanie medyczne w następujący sposób:
| Przeznaczenie oprogramowania | Klasa MDR | System wysokiego ryzyka wg AI Act? |
|---|---|---|
| Dostarcza informacji do decyzji diagnostycznych lub terapeutycznych | IIa | Tak |
| Błędna decyzja może spowodować poważne pogorszenie zdrowia lub konieczność interwencji chirurgicznej | IIb | Tak |
| Błędna decyzja może spowodować zgon lub nieodwracalne pogorszenie zdrowia | III | Tak |
| Monitorowanie życiowych parametrów fizjologicznych, których zmiana zagraża pacjentowi | IIb | Tak |
| Pozostałe oprogramowanie medyczne | I | Nie (brak obowiązku oceny przez jednostkę notyfikowaną) |
Wniosek: jeśli Twoje oprogramowanie AI wspomaga diagnostykę, terapię lub monitorowanie pacjenta i spełnia definicję MDSW – z dużym prawdopodobieństwem trafia co najmniej do klasy IIa. A to automatycznie oznacza status systemu wysokiego ryzyka w rozumieniu AI Act.
Ścieżka 2: przez Załącznik III AI Act (art. 6 ust. 2)
Nawet jeśli Twój system AI nie jest wyrobem medycznym, może być systemem wysokiego ryzyka na podstawie Załącznika III, punkt 5. Dotyczy to systemów AI używanych do:
- Oceny uprawnień osób do świadczeń zdrowotnych (publicznych i prywatnych)
- Oceny ryzyka i ustalania cen w ubezpieczeniach zdrowotnych i na życie
- Klasyfikacji i priorytetyzacji zgłoszeń alarmowych oraz dysponowania zespołami ratownictwa medycznego
- Triażu pacjentów w opiece doraźnej
Kiedy wyjątek od klasyfikacji może Cię dotyczyć
Art. 6 ust. 3 AI Act przewiduje, że system z Załącznika III nie jest systemem wysokiego ryzyka, jeżeli nie stwarza znaczącego ryzyka szkody i spełnia jeden z warunków:
- Wykonuje wąsko określone zadanie proceduralne
- Poprawia wynik wcześniej zakończonej czynności ludzkiej
- Wykrywa wzorce bez zastępowania oceny człowieka
- Wykonuje zadania przygotowawcze
Ale uwaga: wyjątek nie ma zastosowania, gdy system dokonuje profilowania osób fizycznych. Jeśli uznasz, że Twój system nie jest wysokiego ryzyka, musisz udokumentować tę ocenę przed wprowadzeniem do obrotu i zarejestrować system w unijnej bazie danych.
Przykład: system AI do wewnętrznej analizy jakości diagnostyki w szpitalu, bez wpływu na bieżące decyzje kliniczne, mógłby potencjalnie skorzystać z tego wyjątku. Chatbot terapeutyczny prowadzący autonomiczne sesje CBT – raczej nie.
Trzy regulacje, jeden produkt – jak nakładają się AI Act, MDR i RODO
Jeśli Twój produkt AI w zdrowiu kwalifikuje się jako wyrób medyczny, podlegasz kumulatywnie trzem reżimom. Nie możesz wybrać jednego. Musisz spełnić wymogi wszystkich trzech.
Jak to wygląda w tabeli obowiązków
| Obszar | AI Act | MDR | RODO |
|---|---|---|---|
| Zarządzanie ryzykiem | Art. 9 – iteracyjny system przez cały cykl życia | Załącznik I – analiza ryzyka wyrobu | Art. 35 – DPIA przy przetwarzaniu na dużą skalę |
| Dokumentacja techniczna | Art. 11, Załącznik IV – opis modelu, dane treningowe, metryki | Załącznik II i III – dokumentacja techniczna wyrobu | Art. 30 – rejestr czynności przetwarzania |
| Jakość danych | Art. 10 – dane treningowe adekwatne, reprezentatywne, wolne od błędów | Art. 61 – ocena kliniczna, dane kliniczne | Art. 5 – zasada minimalizacji, ograniczenia celu |
| Nadzór człowieka | Art. 14 – lekarz musi móc zignorować, odrzucić lub wyłączyć system | Reguła 11 – decyzja diagnostyczna/terapeutyczna należy do lekarza | Art. 22 – prawo do niepodlegania decyzji zautomatyzowanej |
| Monitoring po wdrożeniu | Art. 72 – ciągłe gromadzenie i analiza danych o działaniu | Art. 83–86 – nadzór po wprowadzeniu do obrotu, system czuwania | Art. 5 ust. 1 lit. e – ograniczenie przechowywania |
| Ocena zgodności | Art. 43 – kontrola wewnętrzna lub jednostka notyfikowana | Załącznik IX–XI – procedury z udziałem jednostki notyfikowanej | Nie dotyczy wprost (ale DPIA jest obowiązkowa) |
Dobra wiadomość: motyw 46 AI Act wprost przewiduje możliwość integracji procesów oceny zgodności MDR i AI Act, aby uniknąć powielania obciążeń. Dostawca może łączyć dokumentację techniczną, procedury testowania i audyty. To nie eliminuje obowiązków, ale pozwala zoptymalizować koszty i czas.
Dane zdrowotne w trenowaniu modeli ML – co mówi RODO
Systemy AI w medycynie z definicji przetwarzają dane szczególnych kategorii: zdrowotne, biometryczne, genetyczne. Art. 9 ust. 1 RODO zakazuje takiego przetwarzania – chyba że zachodzi jedna z przesłanek z art. 9 ust. 2.
Najczęściej stosowane podstawy prawne dla startupów healthtech:
| Przesłanka z art. 9 ust. 2 RODO | Kiedy ma zastosowanie | Ograniczenia |
|---|---|---|
| Lit. a – wyraźna zgoda | Pacjent świadomie zgadza się na przetwarzanie danych w określonym celu | Problematyczna w relacjach pracowniczych (brak równowagi stron); musi być konkretna i dobrowolna |
| Lit. h – cele diagnostyki, opieki zdrowotnej | Przetwarzanie niezbędne do diagnozy, profilaktyki, leczenia | Wymaga, by przetwarzanie odbywało się przez lub pod odpowiedzialnością osoby podlegającej tajemnicy zawodowej |
| Lit. i – interes publiczny w zdrowiu publicznym | Wykrywanie, diagnozowanie, kontrola chorób | Wymaga przepisu prawa UE lub państwa członkowskiego |
| Lit. j – badania naukowe lub statystyczne | Trenowanie modelu AI na danych historycznych w celach badawczych | Wymaga odpowiednich zabezpieczeń (pseudonimizacja, szyfrowanie, ograniczenie dostępu); art. 89 RODO |
Uwaga na art. 469b ustawy Prawo o szkolnictwie wyższym i nauce: podmioty systemu szkolnictwa wyższego mogą przetwarzać dane szczególnych kategorii do badań naukowych i prac rozwojowych, pod warunkiem pseudonimizacji i ograniczenia dostępu. Ale to dotyczy podmiotów naukowych – nie każdego startupu.
Europejska Rada Ochrony Danych (EROD) w opinii z grudnia 2024 r. wskazała, że model AI może być uznany za anonimowy tylko wtedy, gdy bardzo mało prawdopodobne jest zarówno bezpośrednie, jak i pośrednie zidentyfikowanie osób z danych treningowych. Dla systemów trenowanych na danych medycznych – obrazach diagnostycznych, nagraniach głosu, sygnałach biometrycznych – osiągnięcie pełnej anonimizacji jest trudne.
Dlatego: jeśli trenujesz model na danych pacjentów, przeprowadź ocenę skutków dla ochrony danych (DPIA) dla każdego procesu przetwarzającego dane zdrowotne. Zidentyfikuj podstawę prawną z art. 9 ust. 2 RODO. Udokumentuj zabezpieczenia techniczne i organizacyjne.
Napisz do nas – pomożemy Ci ocenić, która podstawa prawna odpowiada Twojemu modelowi przetwarzania danych.
Harmonogram: ile czasu masz na dostosowanie się
Nie wszystkie obowiązki wchodzą w życie jednocześnie. Poniższy harmonogram pokazuje, co już obowiązuje, a co dopiero przed Tobą.
| Data | Co wchodzi w życie | Kogo dotyczy |
|---|---|---|
| 2 lutego 2025 | Zakazy praktyk niedopuszczalnych (art. 5 AI Act); obowiązek AI literacy (art. 4) | Wszyscy dostawcy i podmioty stosujące systemy AI |
| 2 sierpnia 2025 | Przepisy o organach nadzoru rynku, modele AI ogólnego przeznaczenia (GPAI), sankcje | Dostawcy modeli GPAI; państwa członkowskie (wyznaczenie organów) |
| 2 lutego 2026 | Wytyczne Komisji Europejskiej z praktycznymi przykładami klasyfikacji | Wszyscy (dokument pomocniczy) |
| 2 sierpnia 2026 | Pełne stosowanie przepisów dla systemów AI wysokiego ryzyka | Dostawcy i podmioty stosujące systemów AI w medycynie |
| 9 grudnia 2026 | Termin implementacji nowej dyrektywy o odpowiedzialności za produkty wadliwe (PLD 2024/2853) | Producenci produktów, w tym oprogramowania i systemów AI |
Projekt polskiej ustawy o systemach sztucznej inteligencji przewiduje powołanie Komisji Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI) jako krajowego organu nadzoru rynku. KRiBSI będzie miała kompetencje do nakładania kar administracyjnych do 35 mln euro lub 7% światowego rocznego obrotu. W skład komisji wejdą przedstawiciele UOKiK, KNF, KRRiT, UKE, Państwowej Inspekcji Pracy i organu regulującego wyroby medyczne.
Postępowanie przed KRiBSI będzie co do zasady jednoinstancyjne, z odwołaniem do Sądu Ochrony Konkurencji i Konsumentów.
Kto odpowiada, gdy AI postawi błędną diagnozę
To jedno z najczęstszych pytań founderów healthtech – i odpowiedź nie jest prosta.
Obecny stan prawny
Projektowana dyrektywa o odpowiedzialności za AI (AILD) została wycofana z agendy legislacyjnej Komisji Europejskiej w lutym 2025 r. Oznacza to, że na poziomie UE nie ma (jeszcze) dedykowanego reżimu odpowiedzialności za szkody wyrządzone przez systemy AI.
W zamian obowiązują:
- Nowa dyrektywa o odpowiedzialności za produkty wadliwe (PLD 2024/2853) – rozszerza pojęcie produktu na oprogramowanie i systemy AI. Termin implementacji: 9 grudnia 2026 r. Poszkodowany nie musi udowadniać winy producenta – wystarczy wykazać wadę produktu i związek przyczynowy ze szkodą.
- Polskie przepisy ogólne – art. 415 k.c. (odpowiedzialność na zasadzie winy), art. 430 k.c. (odpowiedzialność zwierzchnika za podwładnego), art. 435 k.c. (odpowiedzialność na zasadzie ryzyka za przedsiębiorstwo wprawiane w ruch siłami przyrody).
- Odpowiedzialność za produkt niebezpieczny – art. 449¹–449¹¹ k.c.
Kto odpowiada w jakim scenariuszu
| Scenariusz | Kto odpowiada | Podstawa |
|---|---|---|
| Wadliwy algorytm prowadzi do błędnej diagnozy | Dostawca systemu AI (producent) | PLD 2024/2853 (od XII 2026); art. 449¹ k.c. |
| Lekarz ignoruje poprawną rekomendację AI lub nie weryfikuje błędnej | Lekarz / placówka medyczna | Art. 415, 430 k.c.; odpowiedzialność zawodowa |
| Szpital modyfikuje system AI (dotrenowuje model, zmienia przeznaczenie) | Szpital staje się dostawcą w rozumieniu AI Act | Art. 3 AI Act – zmiana roli |
| Brak nadzoru człowieka nad systemem AI | Podmiot stosujący (placówka medyczna) | Art. 26 AI Act – obowiązki podmiotu stosującego |
Warto wiedzieć: naruszenie wymogów AI Act (np. brak dokumentacji technicznej, brak systemu zarządzania ryzykiem) może stanowić dodatkowy argument w sporze o odpowiedzialność cywilną – jako dowód niedochowania należytej staranności.
Co zrobić, zanim Twój produkt trafi na rynek – lista priorytetów
Poniżej – konkretna kolejność działań dla foundera lub CTO startupu healthtech/medtech. Każdy krok odpowiada wymogowi regulacyjnemu.
Działania, które musisz podjąć (must do)
- Przeprowadź klasyfikację systemu AI według Załącznika III AI Act. Ustal, czy Twój produkt jest systemem wysokiego ryzyka. Jeśli jest wyrobem medycznym klasy IIa lub wyższej – odpowiedź brzmi: tak. Udokumentuj tę ocenę.
- Zweryfikuj, czy Twoje oprogramowanie spełnia definicję wyrobu medycznego (MDSW) wg MDR. Sprawdź, czy oprogramowanie ma cel diagnostyczny, terapeutyczny lub monitorujący wobec indywidualnego pacjenta. Jeśli tak – uruchom proces certyfikacji CE z udziałem jednostki notyfikowanej.
- Przeprowadź DPIA dla każdego procesu przetwarzającego dane zdrowotne pacjentów. Zidentyfikuj podstawę prawną z art. 9 ust. 2 RODO. Udokumentuj zabezpieczenia: pseudonimizację, szyfrowanie, ograniczenie dostępu.
- Wdróż mechanizm nadzoru człowieka (human oversight). Lekarz musi mieć możliwość zweryfikowania rekomendacji systemu, odrzucenia jej lub wyłączenia systemu. To wymóg zarówno AI Act (art. 14), jak i MDR.
- Zadbaj o AI literacy w zespole. Od 2 lutego 2025 r. obowiązuje art. 4 AI Act – musisz zapewnić odpowiednie kompetencje w zakresie AI osobom, które wchodzą w interakcję z systemem lub odpowiadają za jego działanie.
Działania, które powinieneś podjąć (should do)
- Opracuj dokumentację techniczną systemu AI zgodną z Załącznikiem IV AI Act. Opis modelu, dane treningowe, metryki wydajności, analiza ryzyka, środki mitygujące. Rozważ integrację z dokumentacją MDR – motyw 46 AI Act na to pozwala.
- Wdróż system rejestrowania zdarzeń (logi). Art. 12 i 19 AI Act: automatyczne rejestrowanie przez cały cykl życia, przechowywanie minimum 6 miesięcy.
- Przeszkol zespół produktowy i developerski. Wyjaśnij role: dostawca systemu AI, podmiot stosujący, dystrybutor. Każda rola ma inne obowiązki. Szczególnie: jeśli klient (szpital) modyfikuje Twój system – może stać się dostawcą i przejąć pełen katalog obowiązków.
- Zaplanuj monitoring po wprowadzeniu do obrotu (art. 72 AI Act). Aktywne i systematyczne gromadzenie danych o działaniu systemu, analiza incydentów, działania korygujące.
- Sprawdź, czy możesz skorzystać z piaskownicy regulacyjnej. Art. 57 AI Act przewiduje tworzenie piaskownic regulacyjnych (regulatory sandboxes) – kontrolowanych środowisk do testowania innowacyjnych systemów AI pod nadzorem organu. Państwa członkowskie mają obowiązek ustanowić co najmniej jedną piaskownicę do 2 sierpnia 2026 r. Polski projekt ustawy przewiduje, że KRiBSI będzie miała kompetencje do ich tworzenia.
Ile to kosztuje – perspektywa startupu
Nie ma jednej kwoty. Ale dostępne dane pozwalają oszacować skalę obciążeń.
| Kategoria kosztów | Szacunkowy zakres | Źródło |
|---|---|---|
| Certyfikacja MDR dla wyrobu klasy III | 1–4 mln euro | Dane branżowe, raporty MedTech Europe |
| MDR compliance jako % przychodów (firma średniej wielkości) | 8–15% | Dane branżowe |
| Conformity assessment AI Act (systemy wysokiego ryzyka) | Dziesiątki do setek tysięcy euro | Szacunki eksperckie (brak twardych danych rynkowych) |
| DPIA dla przetwarzania danych zdrowotnych na dużą skalę | Koszt wewnętrzny lub audyt zewnętrzny | Zależny od skali |
Dane ankietowe z rynku VC:
- 73% funduszy venture capital spodziewa się spadku konkurencyjności europejskich startupów AI w związku z AI Act
- 50% startupów uważa, że AI Act spowolni innowacje
- 16% startupów rozważa przeniesienie działalności poza UE
Czas wdrożenia compliance szacowany jest na 12–24 miesięcy – co przy dacie granicznej 2 sierpnia 2026 r. oznacza, że okno na rozpoczęcie prac zamyka się w połowie 2025 r.
Możemy Ci w tym pomóc
Budowanie produktu AI w medycynie wymaga równoległego planowania trzech ścieżek regulacyjnych. Każda z nich ma własne terminy, dokumentację i procedury. Pominięcie którejkolwiek może zablokować wprowadzenie produktu na rynek UE lub narazić firmę na kary sięgające 35 mln euro.
Wspieramy startupy healthtech i medtech w porządkowaniu tych obszarów:
- Klasyfikacja systemu AI – ocena, czy Twój produkt jest systemem wysokiego ryzyka w rozumieniu AI Act i/lub wyrobem medycznym w rozumieniu MDR
- Roadmapa compliance – plan działań z harmonogramem, budżetem i przypisaniem odpowiedzialności
- Dokumentacja techniczna – przygotowanie dokumentacji zgodnej z Załącznikiem IV AI Act, zintegrowanej z dokumentacją MDR
- DPIA i strategia danych – identyfikacja podstaw prawnych przetwarzania danych zdrowotnych, zabezpieczenia techniczne i organizacyjne
- Umowy z podwykonawcami i partnerami – uregulowanie ról dostawcy, podmiotu stosującego i dystrybutora w łańcuchu wartości
- Wsparcie przy piaskownicach regulacyjnych – ocena możliwości skorzystania z piaskownicy AI Act i przygotowanie dokumentacji zgłoszeniowej
Łączymy prawo IT/AI/IP z ochroną danych i prawem wyrobów medycznych – bo Twój produkt podlega tym regulacjom łącznie, nie osobno.
Zanim Twój algorytm trafi do pacjenta – sprawdź, czy jest gotowy prawnie
AI Act, MDR i RODO tworzą trzy nakładające się warstwy regulacyjne dla systemów AI w medycynie. Pełne stosowanie przepisów AI Act dla systemów wysokiego ryzyka rozpocznie się 2 sierpnia 2026 r., ale część obowiązków – zakazy praktyk niedopuszczalnych, AI literacy – obowiązuje już od lutego 2025 r.
Jeśli budujesz produkt AI w sektorze zdrowia, Twoje okno na przygotowanie się zamyka się szybko. Klasyfikacja systemu, DPIA, dokumentacja techniczna, mechanizm nadzoru człowieka, strategia danych treningowych – to nie są zadania na ostatni miesiąc przed deadline’em.
Sprawdź, czy Twój produkt AI jest gotowy na AI Act. Napisz do nas – przeprowadzimy audyt klasyfikacji systemu i przygotujemy roadmapę compliance dopasowaną do etapu Twojej firmy.
Najczęściej zadawane pytania
Czy mój produkt AI w zdrowiu jest systemem wysokiego ryzyka według AI Act?
Jeśli Twoje oprogramowanie AI wspomaga diagnostykę, terapię lub monitorowanie pacjenta i spełnia definicję wyrobu medycznego klasy IIa lub wyższej wg MDR – tak, jest systemem wysokiego ryzyka automatycznie na mocy art. 6 ust. 1 AI Act. Nawet jeśli nie jest wyrobem medycznym, może być systemem wysokiego ryzyka na podstawie Załącznika III (np. systemy triażu, oceny uprawnień do świadczeń zdrowotnych). Wyjątek z art. 6 ust. 3 dotyczy wąsko określonych zadań proceduralnych, ale nie ma zastosowania przy profilowaniu osób fizycznych.
Czy oprogramowanie AI wspomagające diagnostykę potrzebuje certyfikacji CE jako wyrób medyczny?
Tak, jeśli spełnia definicję MDSW z art. 2 pkt 1 MDR – czyli ma cel diagnostyczny, terapeutyczny lub monitorujący wobec indywidualnego pacjenta i wykonuje działanie na danych wykraczające poza proste przechowywanie czy komunikację. Reguła 11 Załącznika VIII MDR klasyfikuje takie oprogramowanie co najmniej do klasy IIa, co wymaga udziału jednostki notyfikowanej w ocenie zgodności. Bez certyfikacji CE nie możesz legalnie wprowadzić produktu do obrotu w UE.
Jakie dane mogę zbierać od pacjentów do trenowania modelu AI i na jakiej podstawie prawnej?
Dane zdrowotne i biometryczne to szczególne kategorie danych z art. 9 RODO. Potrzebujesz jednocześnie podstawy z art. 6 ust. 1 RODO i przesłanki uchylającej zakaz z art. 9 ust. 2 – najczęściej: wyraźna zgoda (lit. a), cele diagnostyki i opieki zdrowotnej (lit. h) lub badania naukowe (lit. j, z zabezpieczeniami z art. 89 RODO). Dla każdego procesu przetwarzającego dane zdrowotne przeprowadź DPIA. EROD w opinii z grudnia 2024 r. podkreśliła, że model AI może być uznany za anonimowy tylko wtedy, gdy bardzo mało prawdopodobne jest zidentyfikowanie osób z danych treningowych.
Ile czasu mam na dostosowanie się do AI Act, jeśli mój produkt jest już na rynku?
Pełne stosowanie przepisów dla systemów AI wysokiego ryzyka rozpocznie się 2 sierpnia 2026 r. Ale zakazy praktyk niedopuszczalnych i obowiązek AI literacy obowiązują od 2 lutego 2025 r. Czas wdrożenia compliance szacowany jest na 12–24 miesięcy, co oznacza, że prace nad dostosowaniem warto rozpocząć jak najszybciej.
Kto odpowiada, gdy AI postawi błędną diagnozę – dostawca systemu, szpital czy lekarz?
Zależy od scenariusza. Dostawca systemu AI odpowiada za wadliwość produktu (na podstawie PLD 2024/2853 od grudnia 2026 r. i polskich przepisów o odpowiedzialności za produkt niebezpieczny). Lekarz i placówka medyczna odpowiadają za brak weryfikacji rekomendacji systemu lub zignorowanie poprawnej rekomendacji. Szpital, który modyfikuje system AI (np. dotrenowuje model na własnych danych), staje się dostawcą w rozumieniu AI Act i przejmuje pełen katalog obowiązków dostawcy. Naruszenie wymogów AI Act może stanowić dodatkowy argument w sporze o odpowiedzialność cywilną.
Czy mogę testować system AI na pacjentach w ramach pilotażu bez pełnej certyfikacji?
Art. 57 AI Act przewiduje piaskownice regulacyjne – kontrolowane środowiska do testowania innowacyjnych systemów AI pod nadzorem organu. Państwa członkowskie mają obowiązek ustanowić co najmniej jedną piaskownicę do 2 sierpnia 2026 r. Art. 54 AI Act reguluje zasady przetwarzania danych osobowych w piaskownicy, a art. 58 – testy poza piaskownicą. W zakresie MDR – badania kliniczne wyrobów medycznych podlegają odrębnym procedurom (art. 61 i nast. MDR). Pilotaż bez jakiejkolwiek podstawy regulacyjnej naraża na odpowiedzialność za produkt i kary administracyjne.
