Compliance

AI Act w placówce medycznej: jakie obowiązki ma deployer i od kiedy?

Od 2 sierpnia 2026 r. placówki medyczne mają konkretne obowiązki jako deployer według AI Act. Sprawdź, co musisz mieć wdrożone i na kiedy.

⏱ 7 min czytania · 📅 31.07.2026 · 👁 2 wyświetleń

Od 2 sierpnia 2026 r. placówka medyczna używająca systemu AI jest podmiotem stosującym, czyli deployerem, w rozumieniu rozporządzenia 2024/1689 (AI Act). Oznacza to konkretne obowiązki, niezależnie od tego, czy korzystasz z jednego narzędzia do analizy obrazów radiologicznych, czy z kilku systemów jednocześnie. Zakres tych obowiązków zależy od kategorii ryzyka systemu i od daty: większość wymagań weszła w życie 2 sierpnia 2026 r., a dla systemów AI wbudowanych w wyroby medyczne objęte unijnym prawem harmonizacyjnym obowiązuje zmieniony termin 2 grudnia 2027 r.

Deployer to nie dostawca: różnica, która zmienia Twoje obowiązki

AI Act wyróżnia dwie główne role. Dostawca (provider) tworzy system AI i wprowadza go do obrotu. Deployer używa gotowego systemu we własnej działalności. Szpital kupujący dostęp do platformy wspomagającej diagnostykę onkologiczną jest deployerem. Klinika wdrażająca chatbota opartego na zewnętrznym modelu językowym też jest deployerem.

Dostawca odpowiada za techniczną zgodność systemu, dokumentację techniczną i deklarację zgodności UE. Deployer odpowiada za to, co dzieje się z systemem wewnątrz placówki: jak jest używany, przez kogo, z jakim nadzorem i co się robi, gdy coś pójdzie nie tak. Żadna klauzula w umowie handlowej tego nie zmienia.

Które systemy AI w ochronie zdrowia to wysokie ryzyko?

Załącznik III do AI Act wymienia kategorie systemów wysokiego ryzyka. W ochronie zdrowia wpadają tu przede wszystkim:

  • systemy AI stanowiące wyrób medyczny lub element bezpieczeństwa wyrobu medycznego w rozumieniu rozporządzenia MDR (2017/745) lub IVDR (2017/746), np. oprogramowanie do automatycznej analizy mammografii zaklasyfikowane jako wyrób klasy IIa lub wyżej
  • systemy AI wspomagające decyzje kliniczne: narzędzia sugerujące diagnozę, rozpoznające zmiany patologiczne w obrazie, rekomendujące dawkowanie leku lub oceniające ryzyko hospitalizacji
  • systemy zarządzające dostępem do świadczeń zdrowotnych, które automatycznie kwalifikują lub wykluczają pacjentów z określonej terapii bez udziału człowieka przy każdej decyzji

Nie każdy system AI w placówce to wysokie ryzyko. Asystent do sporządzania e-maili administracyjnych, narzędzie do wstępnego kodowania ICD-10 z obowiązkową weryfikacją lekarza, platforma do planowania grafiku dyżurów, zazwyczaj nie spełniają kryteriów. Ale AI Act ocenia przeznaczenie i kontekst zastosowania, nie tylko nazwę produktu. Warto sprawdzić każdy przypadek osobno, zanim uzna się system za niskiego ryzyka.

Co trafia tylko w obowiązki przejrzystości?

Art. 50 AI Act nakłada lżejsze wymagania na systemy wchodzące w interakcję z ludźmi lub generujące treści. Obowiązują od 2 sierpnia 2026 r. Dotyczy to:

  • chatbotów i asystentów konwersacyjnych obsługujących pacjentów, np. botów do umawiania wizyt, przypomnień SMS, wstępnego zbierania objawów przez aplikację
  • automatycznie generowanych treści prezentowanych pacjentom lub personelowi: wygenerowanych streszczeń dokumentacji medycznej, szablonów wypisów, materiałów informacyjnych dla pacjenta

Obowiązek przejrzystości jest jeden, ale twardy: użytkownik musi wiedzieć od początku interakcji, że ma do czynienia z systemem AI, nie z człowiekiem. Informacja musi być widoczna, nie schowana w regulaminie. Chatbot w rejestracji, który się nie identyfikuje, narusza AI Act.

Kalendarz: co obowiązuje od 2 sierpnia 2026 r., a co od 2 grudnia 2027 r.?

Od 2 sierpnia 2026 r. obowiązują wszystkie wymagania dla deployerów systemów AI wysokiego ryzyka z załącznika III, w tym systemy wspomagające decyzje kliniczne, które nie są jednocześnie zaklasyfikowanym wyrobem medycznym podlegającym unijnemu prawu harmonizacyjnemu. Od tej samej daty egzekwowalne są obowiązki przejrzystości z art. 50.

Od 2 grudnia 2027 r., po zmianie harmonogramu rozporządzenia, wchodzą w pełni w życie wymagania dla systemów AI wbudowanych w wyroby medyczne objęte rozporządzeniami MDR i IVDR oraz innymi aktami wymienionymi w załączniku I do AI Act. Jeśli Twój szpital korzysta z systemu diagnostycznego zintegrowanego z certyfikowanym urządzeniem medycznym, dostawca ma do tamtej daty czas na kompletną dokumentację zgodności po swojej stronie. Twoje obowiązki jako deployera i tak zaczynają się 2 sierpnia 2026 r., bo wdrażasz system, nie produkujesz urządzenie.

Konkretne obowiązki deployera systemów wysokiego ryzyka

Rejestr systemów AI (art. 26 ust. 6). Każda placówka używająca systemu AI wysokiego ryzyka musi prowadzić wewnętrzną ewidencję tych systemów. Minimalna zawartość: nazwa systemu, dostawca, przeznaczenie, obszar zastosowania, data wdrożenia, osoba odpowiedzialna za nadzór. To jeden z pierwszych dokumentów, o które pyta organ nadzorczy przy kontroli.

Ocena wpływu na prawa podstawowe (art. 27). Podmioty lecznicze finansowane ze środków publicznych i prywatne placówki świadczące usługi o charakterze publicznym mają obowiązek przeprowadzenia oceny wpływu na prawa podstawowe przed wdrożeniem systemu AI wysokiego ryzyka. Ocena dotyczy potencjalnego wpływu na prawa pacjentów: równy dostęp do świadczeń, ochrona danych osobowych, ryzyko automatycznego wykluczenia z terapii. Wynik przekazujesz organowi nadzorczemu na żądanie.

Nadzór człowieka (art. 26 ust. 1). To wymaganie najczęściej wymaga realnych zmian w workflow. Lekarz lub uprawniony pracownik musi mieć techniczną i organizacyjną możliwość odrzucenia podpowiedzi systemu AI bez żadnej blokady. Musi to być każda decyzja, nie tylko wyjątkowe przypadki. U jednego z naszych klientów wymagało to dodania jawnego pola wyboru "Zatwierdzam / Odrzucam podpowiedź AI" bezpośrednio w formularzu klinicznym, z zapisem decyzji, daty i danych osoby w logu systemu. Jeśli system przetwarza dane dalej automatycznie bez kroku weryfikacji, taka konfiguracja nie spełnia wymagań AI Act. Nieważne, jak dobry jest system.

Logi i przechowywanie zdarzeń. Musisz przechowywać logi generowane przez system AI przez okres wynikający z instrukcji użytkowania dostawcy lub z przepisów krajowych. W przypadku systemów zaklasyfikowanych jako wyroby medyczne dochodzą jeszcze wymagania MDR. Logi muszą umożliwiać odtworzenie: kto skorzystał z systemu, kiedy, w jakim kontekście klinicznym i jaka podpowiedź została wygenerowana.

Zgłaszanie poważnych incydentów. Jeśli system AI zadziałał w sposób, który spowodował lub mógł spowodować poważną szkodę zdrowotną, masz obowiązek zgłosić incydent dostawcy niezwłocznie po tym, jak się o nim dowiesz. Dostawca następnie zgłasza go do właściwego organu nadzorczego. Brak wewnętrznej procedury do identyfikacji i przekazywania takich zdarzeń to konkretna luka, która ujawnia się przy pierwszym poważnym zdarzeniu, nie przy audycie.

Kompetencje personelu (art. 26 ust. 6). Szkolenie personelu z obsługi konkretnego systemu AI musi być udokumentowane. Ogólny kurs o sztucznej inteligencji nie wystarczy. Program powinien obejmować: opis działania systemu, jego ograniczenia, sytuacje, w których podpowiedź może być błędna, i sposób jej odrzucenia. Dokumentacja szkolenia to arkusz lub certyfikat z datą, zakresem i danymi uczestnika. Musi być możliwy do okazania na żądanie.

Co zostaje po Twojej stronie, nawet przy dobrej umowie, i jak zacząć?

To nieporozumienie pojawia się regularnie. Dostawca dostarcza system, dokumentację techniczną i deklarację zgodności. Ty jako deployer odpowiadasz za to, co z tym systemem robisz wewnątrz placówki. Rejestr systemów prowadzisz Ty. Szkolenia organizujesz Ty. Nadzór człowieka konfigurujesz razem z dostawcą, ale za jego faktyczne działanie odpowiada placówka. Procedurę incydentową wdraża Ty. Przy kontroli organu nadzorczego pytania o te elementy kierowane są do deployera, nie do dostawcy systemu.

Dobra umowa z dostawcą powinna zawierać: instrukcję użytkowania w języku polskim, opis logów generowanych przez system i sposób ich eksportu do własnej archiwizacji, zobowiązanie dostawcy do informowania Cię o incydentach po stronie systemu oraz informację o planowanym czasie wsparcia technicznego. Brak tych elementów to sygnał, że dostawca może nie być gotowy na AI Act, co jest też Twoim problemem.

Pierwszy praktyczny krok to inwentaryzacja. Sporządź listę wszystkich systemów AI używanych w placówce, z podziałem na kliniczne i administracyjne. Przy każdym zapisz, czy wchodzi w decyzje kliniczne lub kontakt z pacjentem. Dla systemów klinicznych sprawdź, czy producent dostarczył instrukcję użytkowania z opisem przeznaczenia i ograniczeń. Czy masz już osobę odpowiedzialną za sprawdzanie każdego nowego systemu AI przed wdrożeniem? Jeśli nie, to warto ją wyznaczyć teraz, bo lista systemów AI w typowej placówce rośnie szybciej, niż się wydaje.

Jeśli chcesz sprawdzić gotowość swojej placówki do AI Act bez zaczynania od zera, możemy to zrobić razem. Oferujemy bezpłatny audyt obejmujący inwentaryzację systemów AI, mapę obowiązków deployera i listę luk do zamknięcia. Możesz też sprawdzić, jak takie przeglądy przebiegały u innych, w realnych wdrożeniach.

Najczęstsze pytania

Czy mała przychodnia musi stosować AI Act?

Tak, jeśli używa jakiegokolwiek systemu AI w procesach klinicznych lub w kontakcie z pacjentem. Rozmiar placówki nie zmienia zakresu obowiązków, zmienia tylko liczbę systemów do zinwentaryzowania.

Czy certyfikat CE na system AI zwalnia placówkę z obowiązków deployera?

Nie. Certyfikat CE i deklaracja zgodności UE to obowiązki dostawcy systemu. Placówka jako deployer odpowiada osobno za rejestr systemów, szkolenia personelu, nadzór człowieka i procedurę zgłaszania incydentów.

Co grozi placówce za brak zgodności z AI Act?

AI Act przewiduje kary administracyjne, których wysokość określą krajowe przepisy wdrożeniowe. Oprócz sankcji finansowych ryzyko obejmuje odpowiedzialność cywilną wobec pacjenta, jeśli szkoda wynikła z nieprawidłowego stosowania systemu AI.

Czy chatbot do rejestracji pacjentów to system wysokiego ryzyka?

Zazwyczaj nie, jeśli nie podejmuje decyzji klinicznych ani nie kwalifikuje pacjentów do świadczeń. Podlega jednak obowiązkom przejrzystości z art. 50 AI Act: pacjent musi wiedzieć od początku interakcji, że rozmawia z systemem AI, nie z człowiekiem.

Co musi być w umowie z dostawcą AI, żeby placówka była chroniona?

Umowa powinna zawierać: instrukcję użytkowania w języku polskim, opis logów generowanych przez system i sposób ich eksportu, zobowiązanie dostawcy do informowania o incydentach po stronie systemu oraz czas wsparcia technicznego. Sama umowa nie przenosi obowiązków deployera na dostawcę.

Opracowanie: zespół redAi z wykorzystaniem narzędzi AI.

Chcesz sprawdzić, jak AI rozwiąże to u Ciebie?

Bezpłatny audyt potrzeb i pokaz działającego wdrożenia. Bez zobowiązań.

Umów bezpłatny audyt

Może Cię też zainteresować