Czego dowiesz się z tego artykułu?
- Dlaczego dane dzieci, pacjentów zależnych i pacjentów w terapii psychologicznej wymagają ostrzejszego procesu niż zwykła automatyzacja administracyjna.
- Jak poukładać zgodę opiekuna, minimalizację danych, dostęp personelu i zakaz eksperymentów z publicznymi narzędziami AI.
- Jak utrzymać human-in-the-loop, gdy AI pomaga w opisie sprawy, ale decyzję kliniczną i dostęp do danych zatwierdza człowiek.
W polskiej przychodni pediatrycznej albo poradni psychologii dziecięcej pytanie o AI bardzo szybko przestaje być pytaniem o narzędzie. Zaczyna się od procesu: kto widzi dane dziecka, kto może je przepisać do systemu, kto zatwierdza notatkę i czy opiekun rozumie, co dokładnie dzieje się z informacją o zdrowiu.
Ja bym przy takim temacie nie zaczynał od „który model wybrać”, tylko od mapy ryzyka. Dane dziecka, dane o stanie psychicznym, informacje o osobie zależnej albo niepełnosprawnej to nie jest materiał do testowania promptów. Najpierw reguły, potem pilotaż.
W praktyce AI może pomóc: uporządkować zgłoszenie, przygotować szkic instrukcji dla recepcji, wyłapać brakujące pola w formularzu. Ale w sprawach klinicznych, prawnych i opiekuńczych człowiek zatwierdza decyzję, a AI nie dostaje więcej danych, niż realnie potrzebuje do zadania.
Najważniejsze
- Jeśli w procesie pojawiają się dane dzieci lub pacjentów zależnych, placówka powinna traktować pilotaż AI jak proces wysokiego ryzyka organizacyjnego, nawet gdy narzędzie wygląda „tylko administracyjnie”.
- Minimalizacja danych jest decyzją operacyjną: zespół musi wiedzieć, których pól nie wolno przepisywać do AI i kiedy sprawę eskalować do lekarza, IOD albo managera.
- Zgoda opiekuna nie zastępuje analizy celu, podstawy prawnej, retencji, dostępu i umowy z dostawcą. To jeden element, nie tarcza ochronna.
- Publiczne narzędzia AI nie powinny służyć do eksperymentowania na opisach wizyt, diagnozach, opiniach psychologicznych ani pełnych dokumentach pacjenta.
- Dobrze ustawiony human-in-the-loop oznacza, że personel widzi szkic, rozumie jego ograniczenia i świadomie akceptuje albo odrzuca wynik.
Rys. 1. Prosty filtr przed pilotażem AI w procesie, w którym mogą pojawić się dane dziecka lub pacjenta zależnego.
Najpierw proces, potem narzędzie
W placówce medycznej najczęstszy błąd polega na tym, że zespół testuje AI na prawdziwym materiale, bo „to tylko streszczenie” albo „to tylko poprawa języka”. Przy danych dzieci taki skrót jest szczególnie niebezpieczny. Opis wizyty, zaświadczenie, notatka psychologa, informacja od rodzica mogą ujawniać znacznie więcej niż sam fakt leczenia.
Dlatego pierwszym krokiem powinien być przegląd procesu, nie demo produktu. Manager powinien spisać, gdzie dane powstają: telefon, formularz online, rejestracja, gabinet, e-mail, system EDM, komunikacja z opiekunem. Dopiero potem warto zapytać, czy AI ma przygotować szkic, wykryć brak informacji, pomóc w klasyfikacji sprawy czy usprawnić raport wewnętrzny.
Sugeruję rozdzielić trzy rzeczy: dane potrzebne do obsługi organizacyjnej, dane potrzebne lekarzowi lub psychologowi oraz dane, których AI w ogóle nie powinno zobaczyć. Ten podział zwykle studzi entuzjazm, ale ratuje projekt przed chaosem.
Cztery ostrzejsze reguły dla pediatrii i osób zależnych
W procesach pediatrycznych i opiekuńczych nie wystarczy ogólna polityka „nie wrzucamy danych wrażliwych”. Zespół potrzebuje reguł, które da się zastosować w recepcji, gabinecie i administracji. Reguła musi być zrozumiała dla osoby nietechnicznej, bo to ona najczęściej decyduje, co trafi do narzędzia.
| Obszar | Pytanie managera | Decyzja operacyjna |
|---|---|---|
| Zgoda i opiekun | Czy wiadomo, kto ma prawo działać w imieniu dziecka? | Rejestracja nie rozstrzyga sporu; eskaluje do osoby odpowiedzialnej. |
| Minimalizacja danych | Czy AI potrzebuje pełnej treści dokumentacji? | Do testu trafia opis procesu albo dane syntetyczne, nie historia pacjenta. |
| Dostęp personelu | Kto widzi wynik działania AI? | Role są ograniczone: recepcja widzi zadanie, lekarz widzi kontekst kliniczny. |
| Narzędzia publiczne | Czy dostawca daje kontrolę nad danymi i retencją? | Brak kontroli oznacza brak pilotażu na danych pacjentów. |
Warto też odróżnić pacjenta małoletniego od pacjenta dorosłego, który wymaga wsparcia opiekuna lub przedstawiciela. To inne sytuacje prawne i organizacyjne, ale wspólna zasada jest podobna: placówka nie powinna przerzucać decyzji o dostępie do danych na przypadkową osobę przy biurku rejestracji.
Przykład z przychodni: zadanie dla recepcji, nie diagnoza
Przykład modelowy — scenariusz pokazuje sposób myślenia o pilotażu. Liczby ilustrują metryki, nie gwarantują wyniku wdrożenia.
Wyobraźmy sobie poradnię pediatryczną, w której lekarz po wizycie chce, żeby recepcja przypomniała opiekunowi o kontroli za 6 tygodni i o przygotowaniu wyniku badania. AI nie dostaje pełnej historii choroby. Dostaje tylko zatwierdzony przez lekarza komunikat operacyjny: typ zadania, termin, kanał kontaktu i informację, że treść medyczna pozostaje w EDM.
W takim układzie AI może przygotować szkic zadania dla recepcji, ale lekarz zatwierdza treść i zakres informacji, a rejestracja nie dopisuje własnych interpretacji. Jeśli opiekun zada pytanie o wynik, leczenie albo zmianę objawów, sprawa wraca do personelu medycznego. To jest human-in-the-loop w praktyce, nie ozdobne hasło.
Po 30 dniach manager może mierzyć proste rzeczy: ile zadań wróciło do lekarza, ile wymagało korekty, ile razy personel próbował dopisać zbyt dużo informacji do pola AI, ile zgłoszeń wymagało decyzji IOD. Metryki mają pokazać kontrolę procesu, a nie obiecywać oszczędność czy automatyzację pracy lekarza.
Checklista przed pilotażem
Poniższa checklista jest celowo krótka. Jeśli placówka nie umie odpowiedzieć na te pytania, to pierwszy krok nie brzmi „kupmy narzędzie”, tylko „opiszmy proces i odpowiedzialność”.
Checklista pilotażu AI przy danych dzieci:
1. Cel: jakie jedno zadanie ma wspierać AI i czego nie wolno mu robić?
2. Dane: które pola są potrzebne, a które muszą zostać poza narzędziem?
3. Opiekun: kto potwierdza uprawnienie do kontaktu i dostępu do informacji?
4. Role: kto widzi wejście, wynik, logi i historię akceptacji?
5. Decyzja kliniczna: kiedy sprawa automatycznie wraca do lekarza lub psychologa?
6. Dostawca: gdzie dane są przetwarzane, jak długo i na jakiej podstawie?
7. Publiczne AI: czy zespół ma jasny zakaz wpisywania danych pacjentów do narzędzi bez umowy i kontroli?Z mojego doświadczenia taka karta pilotażu zmienia rozmowę z dostawcą. Zamiast pytać, czy „system obsługuje pediatrię”, placówka pyta o logi, retencję, role, wyłączenia danych i możliwość pracy na danych syntetycznych. To są pytania, które realnie chronią pacjenta i personel.
Kiedy ostrzejszy proces jest konieczny
To ma sens, gdy placówka ma powtarzalny, dobrze opisany proces administracyjny, a AI ma pomagać w porządkowaniu zadań, tworzeniu szkiców lub kontroli kompletności informacji. Wtedy dane można ograniczyć, wynik może zatwierdzić człowiek, a pilotaż da się zatrzymać bez szkody dla pacjentów.
To nie ma sensu, gdy zespół chce wkleić do publicznego czatu opis wizyty dziecka, opinię psychologiczną, pełną dokumentację albo korespondencję z opiekunem. Nie ma też sensu, gdy nikt nie wie, kto ma prawo widzieć wynik działania AI i kto odpowiada za błąd w komunikacji z pacjentem.
W tematach pediatrii, psychologii dziecięcej i osób zależnych ostrożność nie jest hamulcem innowacji. Jest warunkiem, żeby projekt nie naruszał zaufania, na którym placówka medyczna działa każdego dnia.
Pytania na spotkanie z IOD i personelem
Na koniec proponuję prostą rozmowę przy stole: manager, kierownik rejestracji, lekarz albo psycholog, IOD i osoba od systemu EDM. Nie trzeba zaczynać od wielkiego audytu. Trzeba ustalić, czy proces jest na tyle dojrzały, żeby wpuścić do niego AI.
Pierwsze pytanie: gdzie w tym procesie pojawia się dziecko, opiekun albo pacjent zależny? Drugie: które dane są absolutnie zbędne dla AI? Trzecie: kto ma prawo zatrzymać pilotaż, jeśli personel zacznie obchodzić reguły albo dostawca nie odpowie na pytania o przetwarzanie.
Jeżeli potrzebujesz kontekstu dla bardziej klinicznych zastosowań, zobacz też tekst o tym, kiedy AI może być traktowane jak wyrób medyczny. Przy danych dzieci warto jednak zacząć jeszcze wcześniej: od procesu, zgód, dostępu i zakazu testowania na prawdziwych historiach pacjentów.
Źródła
- UODO — Obowiązkowa edukacja zdrowotna wspiera ochronę prywatności i praw podstawowych — oficjalny materiał z 2026-04-24; wnosi aktualny kontekst szczególnej ochrony dzieci, ryzyk cyfrowych i danych wrażliwych.
- UODO — Uwagi Prezesa UODO do projektu ustawy o systemach sztucznej inteligencji — komunikat z 2026-04-23; pokazuje, że nadzór nad AI i przetwarzaniem danych osobowych wymaga jasnych zasad współpracy organów.
- ISAP — Ustawa o prawach pacjenta i Rzeczniku Praw Pacjenta, tekst ujednolicony — tekst z 2026-04-17; podstawa dla dokumentacji medycznej, przedstawiciela ustawowego i obowiązków podmiotu leczniczego.
- Pacjent.gov.pl — Prawo do informacji — źródło publiczne dla pacjentów; wyjaśnia zasady informacji u pacjentów poniżej 18 lat, dostęp: 2026-07-01.
- Pexels — zdjęcie Pavla Danilyuka — atrybucja okładki; spokojny kadr konsultacji pediatrycznej bez sensacyjności, dostęp: 2026-07-01.