Przychodnia z pięcioma lekarzami, trzydzieści telefonów dziennie do rejestracji, trzy czwarte z nich to potwierdzenie wizyty lub pytanie o przygotowanie do badania krwi na czczo. Rejestratorka odbiera każde z osobna. To nie jest problem diagnozy. To problem procesu administracyjnego, który można rozwiązać AI bez wchodzenia w obszar kliniczny.
Ale ten sam argument bywa rozciągany za daleko. „AI oceni czy warto przyjść do lekarza" brzmi jak odciążenie recepcji, a jest ukrytą próbą triagowania klinicznego przez narzędzie, które nie ma ku temu ani kompetencji, ani prawa. Granica między tymi dwoma jest konkretna. Poniżej ją narysujemy.
Co AI może zrobić w przychodni i co z tego wynika
#Zadania administracyjne w placówce medycznej są powtarzalne, ustrukturyzowane i dobrze zdefiniowane. Dokładnie te cechy, przy których AI działa najlepiej.
Rejestracja i umawianie wizyt. Agent AI z dostępem do kalendarza lekarzy może przyjmować prośby o wizytę przez chat, SMS lub formularz, proponować dostępne terminy i potwierdzać rezerwację. Może też obsługiwać odwołania i przesunięcia. Nie podejmuje decyzji klinicznych, tylko zarządza slotami w grafiku. Porównywalny wzorzec techniczny opisujemy w agencie AI do umawiania spotkań.
Przypomnienia i follow-upy. Automatyczne SMS lub e-mail na 24 godziny przed wizytą zmniejszają liczbę nieobecności (badania szacują 20-40% redukcji no-show w placówkach z przypomnień). Nie ma tu żadnego przetwarzania klinicznego, tylko dane kontaktowe i termin.
FAQ o przygotowaniu do badań. Odpowiedź na pytanie „czy muszę być na czczo przed badaniem TSH" jest faktem medycznym z bazy wiedzy, nie oceną kliniczną pacjenta. RAG na zweryfikowanych materiałach przychodni (protokoły przygotowania, standardy laboratorium) daje odpowiedzi spójne z procedurami placówki, bez ryzyka improwizacji modelu.
Wstępne zbieranie powodów wizyty. Agent może zapytać, czego dotyczy wizyta, i przekazać tę informację lekarzowi przed wejściem pacjenta. To administracyjne ustrukturyzowanie danych, nie diagnoza. Różnica jest prosta: agent pyta „Czego dotyczy wizyta?", nie „Co Pana/Pani boli i jak poważne to może być?".
Czego AI absolutnie nie powinna robić w przychodni
#Ta lista jest krótka, ale absolutna.
Interpretacja objawów i rekomendacja leczenia to obszar zastrzeżony dla lekarza. „Pacjent opisuje ból w klatce piersiowej i duszność — agent sugeruje, że to prawdopodobnie niegroźne" to scenariusz z konsekwencjami prawnymi i medycznymi, niezależnie od tego, jak jest opakowany w interfejs.
Triage kliniczny (ocena pilności w oparciu o objawy) należy do personelu medycznego. Agent może zapytać o powód wizyty i przekazać go lekarzowi lub rejestratorce. Nie może oceniać, czy pacjent powinien jechać na SOR czy zaczekać na wizytę za tydzień.
Interpretacja wyników badań. Wynik morfologii, TSH, CRP to dane kliniczne. Odpowiedź „wynik wygląda normalnie" lub „wynik jest poza normą, to oznacza X" to diagnoza w rozumieniu prawa, nie informacja administracyjna.
AI Act (Załącznik III, punkt 5) obejmuje systemy AI stosowane do wspomagania decyzji klinicznych jako systemy wysokiego ryzyka. Wdrożenie bez wymaganej dokumentacji, bez nadzoru ludzkiego, bez oceny skutków (DPIA) jest naruszeniem prawa europejskiego. Szerszy kontekst prawny: AI Act w medycynie i systemy wysokiego ryzyka.
Tabela: zadanie, dozwolone, wymagane zabezpieczenia
#| Zadanie AI | Obszar | Klasyfikacja AI Act | Wymagane zabezpieczenia |
|---|---|---|---|
| Umawianie i potwierdzanie wizyt | Administracja | Nie wysokie ryzyko | Szyfrowanie danych kontaktowych, logi dostępu, RODO art. 6 |
| Przypomnienia SMS/e-mail | Administracja | Nie wysokie ryzyko | Zgoda marketingowa lub umowa, możliwość opt-out |
| FAQ o przygotowaniu do badań | Administracja (weryfikowana baza) | Nie wysokie ryzyko | RAG na zweryfikowanych materiałach, disclaimer że nie jest poradą medyczną |
| Zbieranie powodów wizyty (ustrukturyzowane) | Administracja | Nie wysokie ryzyko | PII masking w logach, dostęp ograniczony do personelu |
| Triage kliniczny (ocena pilności z objawów) | Kliniczny | Wysokie ryzyko | Human-gate (lekarz/pielęgniarka), dokumentacja techniczna AI Act, DPIA |
| Interpretacja wyników badań | Kliniczny | Wysokie ryzyko | Zakazane bez pełnej zgodności AI Act + nadzór lekarza |
| Rekomendacja leczenia / leków | Kliniczny | Wysokie ryzyko | Zakazane w jakiejkolwiek formie autonomicznej |
RODO art. 9 i dane zdrowotne: co to znaczy technicznie
#Dane pacjenta (imię, PESEL, termin wizyty, powód wizyty) to dane osobowe. Powód wizyty, wyniki badań, rozpoznania to dane wrażliwe w rozumieniu RODO art. 9 — kategoria szczególna, wymagająca osobnej podstawy prawnej i zaostrzonych zabezpieczeń.
Trzy decyzje architektoniczne mają tu największy wpływ.
Self-hosting lub data residency EU. Dane zdrowotne pacjentów nie powinny opuszczać infrastruktury placówki lub EU bez wyraźnej podstawy prawnej i umowy powierzenia. Lokalne LLM (model działający na serwerze przychodni lub w centrum danych EU) eliminuje ten problem strukturalnie. Alternatywą jest dostawca chmurowy z data residency PL/EU i podpisaną umową art. 28 RODO. Wzorzec omawia self-hosted LLM a RODO.
PII masking przed przetwarzaniem. Agenci AI nie muszą widzieć pełnych danych pacjenta, żeby wykonać swoje zadanie. Numer PESEL, adres, numer telefonu można maskować przed wysłaniem do modelu, zachowując tylko ID sesji. Logi konwersacji przechowywane bez PII zmniejszają ryzyko przy naruszeniu bezpieczeństwa. Techniki opisujemy w anonimizacji PII przed AI.
Retencja i prawo do usunięcia. Pacjent ma prawo żądać usunięcia danych (RODO art. 17). Architektura musi to obsługiwać technicznie: logi rozmów z agentem powinny być powiązane z ID pacjenta i usuwalne na żądanie. Przechowywanie logów w niespójnej strukturze, z której nie da się wyczytać co dotyczy kogo, to problem zgodności, nie tylko organizacyjny.
DPIA jest wymagana, gdy przetwarzane są dane zdrowotne na dużą skalę lub gdy system podejmuje automatyczne decyzje mające wpływ na dostęp pacjenta do usług (np. automatyczne odrzucenie wniosku o wizytę na podstawie historii). Dla standardowego systemu rejestracyjnego bez elementów automatycznych decyzji DPIA może nie być wymagana, ale warto przeprowadzić ocenę wstępną.
Jak wdrożyć krok po kroku
#Wdrożenie asystenta AI w przychodni zajmuje 4-8 tygodni dla zakresu administracyjnego. Etapy:
Tydzień 1-2: audyt procesów. Katalog pytań, które dziś trafiają do rejestracji. Podział na administracyjne (można automatyzować) i kliniczne (zawsze do lekarza). Bez tego kroku system będzie odpowiadał na pytania kliniczne, bo pacjenci je zadają.
Tydzień 2-4: budowa bazy wiedzy RAG. Dokumenty źródłowe: protokoły przygotowania do badań, cennik, grafik lekarzy, procedury rejestracji, FAQ ze strony placówki. To treść, na której agent bazuje. Jakość bazy wiedzy bezpośrednio determinuje jakość odpowiedzi. Szczegółowy wzorzec: przygotowanie danych firmowych pod AI.
Tydzień 3-5: guardrails i testy. Każdy system w placówce medycznej musi mieć twarde ograniczenia: lista tematów, na które agent nie odpowiada (objawy, diagnoza, dawkowanie leków), automatyczna eskalacja do rejestratorki gdy temat wychodzi poza zakres, disclaimer że rozmowy nie zastępują porady lekarskiej.
Tydzień 5-8: pilot shadow mode. Agent działa równolegle z rejestratorem, jego odpowiedzi są logowane i weryfikowane. Dopiero po 2-3 tygodniach bez istotnych odchyleń przychodzi samodzielna obsługa wybranych kategorii zapytań. Wzorzec pilotażu: plan wdrożenia AI krok po kroku.
Wypróbuj na żywo
#FAQ
#Czy agent AI w przychodni musi być klasyfikowany jako system wysokiego ryzyka wg AI Act?
#Nie automatycznie. System obsługujący wyłącznie administrację (umawianie wizyt, przypomnienia, FAQ o przygotowaniu do badań) nie wchodzi w zakres Załącznika III AI Act, który dotyczy systemów wspomagających decyzje kliniczne. Granica jest jednak proceduralna, nie techniczna: jeśli agent odpowiada na pytania o objawy lub rekomenduje, czy warto przyjść do lekarza, wchodzi w obszar kliniczny i klasyfikacja się zmienia. Zakres systemu musi być udokumentowany i egzekwowany przez guardrails.
Jaką podstawę prawną RODO wybrać dla danych pacjentów przetwarzanych przez AI?
#Dla danych administracyjnych (kontakt, termin wizyty) podstawą jest najczęściej art. 6 ust. 1 lit. b (wykonanie umowy) lub lit. c (obowiązek prawny). Dla danych zdrowotnych wchodzi art. 9 ust. 2 — w praktyce placówki medycznej najczęściej lit. h (profilaktyka zdrowotna, diagnoza medyczna, leczenie przez personel zobowiązany do zachowania tajemnicy) lub lit. a (wyraźna zgoda). Wybór podstawy prawnej wpływa na możliwość przetwarzania, retencję i prawa pacjenta. Konsultacja z inspektorem ochrony danych jest zalecana przed wdrożeniem.
Czy system przypomnień SMS wymaga DPIA?
#Standardowy system przypomnień o wizytach (imię, termin, numer kontaktowy) przy skali typowej przychodni raczej nie wymaga DPIA. DPIA jest wymagana, gdy przetwarzanie może skutkować wysokim ryzykiem dla praw osób fizycznych, w szczególności przy dużej skali, systematycznym monitorowaniu lub decyzjach automatycznych z istotnymi skutkami. Jeśli przypomnienia zawierają informacje o rodzaju wizyty lub specjalizacji (co może ujawniać stan zdrowia), próg ryzyka rośnie.
Czy AI może przeprowadzić wywiad wstępny przed wizytą?
#Może zbierać informacje strukturalne: powód wizyty (w jednym zdaniu), czas trwania dolegliwości, czy pacjent był już leczony z tego powodu. Nie może oceniać, klasyfikować pilności ani sugerować rozpoznania na podstawie tych informacji. Zebrane dane trafiają do lekarza jako kontekst, nie jako ocena. Granica jest tu subtelna technicznie, więc wymaga precyzyjnych guardrails i testów przed wdrożeniem.
Jak długo przechowywać logi rozmów z agentem AI?
#Logi konwersacji z agentem pełnią dwie role: debugowanie (krótki czas, zazwyczaj 30-90 dni) i rozliczalność systemu AI (dłuższy czas, powiązany z retencją dokumentacji medycznej). Logi zawierające PII pacjenta powinny być usuwane na żądanie (RODO art. 17) i nie powinny być przechowywane dłużej niż wynika z celu. Architektura musi umożliwiać wyszukanie i usunięcie logów konkretnego pacjenta bez usuwania całej historii systemu.