Czego dowiesz się z tego artykułu?

  • Jak przełożyć komunikat UODO po AI & MEDTECH na prostą kartę danych przed pilotażem AI.
  • Jak rozdzielić dane pacjentów, dane personelu, logi i retencję, zanim pojawi się dostawca.
  • Kiedy AI może porządkować proces, a kiedy człowiek musi zatrzymać decyzję kliniczną lub prawną.

UODO po konferencji AI & MEDTECH CEE 2026 powiedział rzecz bardzo praktyczną dla managera placówki: problemem nie jest samo AI, tylko utrata kontroli nad celem, zakresem i odpowiedzialnością za dane. W polskiej przychodni to od razu przekłada się na pytanie: czy wiemy, jakie dane trafią do narzędzia, zanim pokażemy zespołowi pierwsze demo?

Ja bym nie zaczynał od wyboru modelu ani od obietnicy dostawcy, że „wszystko jest bezpieczne”. Zacząłbym od jednej strony: rejestru danych dla konkretnego procesu, właściciela procesu, podstawy przetwarzania, logów, retencji i punktu zatwierdzenia przez człowieka.

To nie jest porada prawna, tylko operacyjny sposób rozmowy z IOD, właścicielem placówki i dostawcą. AI może przygotować szkic, klasyfikację albo listę wyjątków, ale przy danych pacjenta i decyzjach klinicznych człowiek musi widzieć, zatwierdzać i odpowiadać za dalszy krok.

Najważniejsze

  • Przed pilotażem AI placówka powinna mieć kartę procesu: cel, dane wejściowe, wynik, role, logi, retencję i punkt zatrzymania.
  • Największe ryzyko to Shadow AI: pracownik korzysta z narzędzia poza wiedzą organizacji, a dane pacjenta lub dokumenty trafiają do niezatwierdzonego dostawcy.
  • Rejestr danych nie jest dodatkiem „dla RODO”; to narzędzie managera do decyzji, czy pilotaż w ogóle można uruchomić.
  • Human-in-the-loop musi być wpisany w proces: AI porządkuje, człowiek zatwierdza, zwłaszcza przy danych medycznych, komunikacji z pacjentem i dokumentacji.

Matryca ryzyka danych przed pilotażem

W wielu placówkach rozmowa o AI zaczyna się od prezentacji funkcji. To zła kolejność przy danych medycznych. Najpierw trzeba nazwać proces, na przykład obsługę zapytań z formularza, porządkowanie dokumentów przed wizytą albo szkic odpowiedzi administracyjnej. Dopiero potem można sprawdzić, które dane naprawdę są potrzebne.

Ta matryca ryzyka nie musi być długa. Powinna odpowiedzieć na pytania: jakie dane wchodzą do narzędzia, po co, kto je widzi, gdzie są logi, jak długo dane zostają w systemie i kto zatwierdza wynik. Jeśli tych odpowiedzi nie ma, pilotaż jest jeszcze za wcześnie, nawet gdy narzędzie wygląda rozsądnie.

Element karty procesuCo wpisać przed pilotażemDecyzja managera
Cel użycia AIJedno zadanie: klasyfikacja zgłoszeń, szkic odpowiedzi, podsumowanie dokumentówCzy cel jest administracyjny, czy dotyka decyzji klinicznej
Kategorie danychDane kontaktowe, organizacyjne, medyczne, dane personelu, metadane systemoweCzy zakres jest minimalny i uzasadniony
Podstawa i roleAdministrator, podmiot przetwarzający, IOD, właściciel procesuKto odpowiada za decyzję i kto podpisuje zakres
Logi i historia zmianKto użył narzędzia, jaki wynik zatwierdzono, co odrzuconoCzy da się odtworzyć decyzję po błędzie
Retencja i usuwanieJak długo trzymane są dane wejściowe, wynik i logiCzy dane znikają po zakończeniu celu
Punkt stopDane medyczne, skarga, objawy, niepewność modelu, błąd klasyfikacjiKiedy sprawa trafia do człowieka

Ta tabela celowo nie zastępuje rejestru czynności przetwarzania z art. 30 RODO. Jest roboczą kartą pilotażu, która pomaga IOD i managerowi zobaczyć, czy nowy proces powinien trafić do istniejącej dokumentacji, czy wymaga osobnej oceny i rozmowy z dostawcą.

Pytania do IOD, dostawcy i managera

Shadow AI w placówce zwykle nie zaczyna się od złej intencji. Recepcja chce szybciej odpisać pacjentowi, lekarz chce uporządkować notatkę, manager chce streścić skargę. Problem zaczyna się wtedy, gdy nikt nie wie, gdzie trafiły dane i czy narzędzie zostało dopuszczone do pracy w placówce.

Przed startem warto zadać cztery pytania do IOD, dostawcy i managera. Po pierwsze: czy w wejściu są dane pacjenta, dokumentacja albo informacje o zdrowiu? Po drugie: czy wynik AI może wpłynąć na termin, komunikat do pacjenta albo decyzję lekarza? Po trzecie: czy dostawca używa danych do trenowania modeli lub poprawy usługi? Po czwarte: czy placówka ma logi i możliwość usunięcia danych? Bez tych odpowiedzi nie ma kontroli, tylko nadzieja.

To ma sens, gdy placówka ma wybrany jeden proces, właściciela po stronie biznesu, IOD włączonego przed umową i prostą listę danych, których nie wolno wysyłać do niezatwierdzonych narzędzi. To nie ma sensu, gdy zespół chce testować publiczne AI na realnych zgłoszeniach pacjentów albo gdy dostawca nie potrafi jasno opisać retencji, logów i trenowania modeli.

Jeżeli zespół dopiero uczy się zasad korzystania z narzędzi, warto połączyć ten temat ze szkoleniem opisanym w artykule o AI dla zespołu placówki. Rejestr danych i szkolenie powinny się spotkać w jednym miejscu: pracownik musi wiedzieć, co wolno, czego nie wolno i gdzie zgłosić wątpliwość.

Przykład z przychodni: formularz kontaktowy i szkic odpowiedzi

Przykład modelowy — scenariusz pokazuje sposób myślenia o pilotażu. Nie opisuje realnej placówki ani danych konkretnego pacjenta.

Wyobraźmy sobie prywatną przychodnię w Polsce, która chce użyć AI do porządkowania zgłoszeń z formularza kontaktowego. Na starcie proces ma obsługiwać wyłącznie sprawy organizacyjne: prośbę o zmianę terminu, pytanie o przygotowanie do wizyty i informację o brakującym dokumencie. AI może oznaczyć kategorię zgłoszenia i przygotować szkic odpowiedzi, ale recepcja zatwierdza wysyłkę.

W karcie danych manager zapisuje, że system nie przyjmuje opisów objawów jako materiału do automatycznej odpowiedzi. Jeśli pacjent wpisze informację medyczną, skargę albo pytanie o pilność kontaktu, proces się zatrzymuje. Recepcja przekazuje sprawę według procedury, a lekarz lub uprawniony personel decyduje o komunikacie klinicznym. To jest human-in-the-loop w praktyce, a nie dopisek w regulaminie.

Druga granica dotyczy danych personelu. Jeśli AI ma analizować jakość odpowiedzi rejestracji, w rejestrze trzeba opisać nie tylko dane pacjentów, ale też dane pracowników: identyfikatory kont, czas reakcji, historię zmian i ewentualne oceny jakości. Pilotaż AI może dotykać zespołu równie mocno jak pacjenta, więc rozmowa z managerem i IOD nie powinna kończyć się na dokumentacji medycznej.

Jeżeli placówka rozważa bardziej zamknięte środowisko lub własną bazę wiedzy, dobrym tłem jest tekst o prywatnym modelu AI w placówce. Tu jednak pierwszy krok jest prostszy: nie wybór architektury, tylko spisanie danych i decyzji, które architektura ma obsłużyć.

Pierwszy warsztat: 45 minut, jedna karta procesu

Na warsztat zaprosiłbym cztery osoby: managera placówki, właściciela procesu, IOD lub osobę odpowiedzialną za RODO oraz przedstawiciela zespołu, który ma używać narzędzia. Nie zaczynałbym od dostawcy, bo wtedy placówka łatwo dopasowuje proces do funkcji produktu zamiast do własnej odpowiedzialności.

Agenda jest krótka. Wybierz jeden proces, wypisz dane wejściowe, zaznacz dane zakazane, ustal wynik AI, wskaż człowieka zatwierdzającego i zdecyduj, co logujesz. Na końcu zapisz trzy odpowiedzi: co mierzymy po miesiącu, kto przegląda błędy i kiedy zatrzymujemy pilotaż.

Metryka sukcesu w tym temacie nie brzmi „AI oszczędziło X godzin”. Na tym etapie lepsza metryka to kompletna karta procesu: cel, kategorie danych, role, retencja, logi, decyzje człowieka i lista sytuacji stop. Jeżeli karta nie mieści się na jednej lub dwóch stronach, zakres pilotażu prawdopodobnie jest za szeroki.

Dopiero z taką kartą poszedłbym do dostawcy. Wtedy pytania są konkretne: gdzie przetwarzane są dane, czy są używane do trenowania, jak wygląda usunięcie danych po teście, kto ma dostęp administracyjny i czy placówka dostaje logi. To jest mniej efektowne niż demo, ale znacznie bliższe temu, czego oczekuje odpowiedzialny manager medyczny.

Źródła