AI i prompt injection w placówce medycznej: jak pacjent lub dokument może oszukać chatbota?

Prompt injection brzmi technicznie, ale w placówce zaczyna się bardzo zwyczajnie: pacjent wpisuje coś w formularzu, przesyła dokument albo rozmawia z chatbotem na stronie. Jeśli system AI traktuje każdy tekst jak polecenie, a nie jak dane do sprawdzenia, może wykonać instrukcję ukrytą w treści, zamiast trzymać się zasad ustalonych przez placówkę.

Dla polskiej przychodni lub kliniki to nie jest temat „dla programistów na później”. To jest temat dla managera, IOD i osoby odpowiedzialnej za rejestrację, bo w grę wchodzą dane pacjenta, odpowiedzialność za proces i kontrola nad tym, co trafia do systemu placówki. Ja bym go traktował jak ryzyko organizacyjne, nie jak ciekawostkę o chatbotach.

Najprostsza teza jest taka: AI może podsumować, sklasyfikować albo zaproponować odpowiedź, ale nie powinno samodzielnie decydować o zapisie do EDM, zmianie terminu, eskalacji klinicznej ani ujawnieniu informacji. Człowiek musi widzieć, co model zrobił, dlaczego to zrobił i gdzie system zatrzymał ryzykowną sytuację.

Najważniejsze

• Prompt injection to próba zmuszenia modelu AI, aby zignorował reguły placówki i wykonał instrukcję ukrytą w tekście pacjenta, dokumencie lub stronie internetowej.
• Największe ryzyko pojawia się wtedy, gdy chatbot ma dostęp do narzędzi: grafiku, CRM, EDM, bazy wiedzy, poczty albo automatycznego wysyłania wiadomości.
• W placówce medycznej minimalnym standardem jest separacja instrukcji od danych, whitelista dozwolonych akcji, walidacja odpowiedzi i logi zdarzeń.
• AI nie powinno zapisywać niczego do EDM ani zmieniać procesu pacjenta bez weryfikacji człowieka, jeśli treść dotyka danych medycznych lub decyzji klinicznej.
• Pierwszym krokiem nie jest zakup narzędzia, tylko mapa miejsc, w których pacjent, dokument albo zewnętrzna treść mogą wejść do modelu.

Gdzie atak zaczyna się w zwykłym procesie placówki

W praktyce prompt injection najczęściej nie wygląda jak „atak hakerski” z filmu. To może być zdanie dopisane w formularzu kontaktowym, ukryta instrukcja w pliku PDF, opis objawów wklejony do okna chatbota albo treść pobrana przez system z zewnętrznej strony. Model nie widzi intuicyjnej granicy między poleceniem od placówki a tekstem, który ma tylko przeczytać.

W medycynie ta granica ma duże znaczenie. Jeżeli chatbot ma tylko odpowiedzieć, że placówka oddzwoni, ryzyko jest inne niż wtedy, gdy może zmienić termin wizyty, wysłać dane do recepcji, utworzyć notatkę lub podpiąć streszczenie do dokumentacji. Im więcej narzędzi ma podpiętych do modelu, tym bardziej prompt injection przestaje być problemem językowym, a staje się problemem uprawnień.

Prosta architektura obrony, którą rozumie recepcja

Dobra obrona nie polega na jednym magicznym filtrze. Sugeruję myśleć o niej jak o czterech bramkach po drodze: wejście, model, walidacja odpowiedzi i decyzja o akcji. Dzięki temu manager może rozmawiać z dostawcą konkretnie, bez wchodzenia w żargon infrastruktury.

Najważniejsza zasada brzmi: model może proponować, ale system placówki decyduje według osobnych reguł. Innymi słowy, chatbot nie powinien sam „uznać”, że wolno mu zapisać coś w EDM. Taka akcja powinna przejść przez whitelistę, kontrolę uprawnień i człowieka tam, gdzie dotyczy pacjenta lub procesu klinicznego.

flowchart LR
  A[Pacjent lub dokument] --> B[Filtr wejścia]
  B --> C[Model AI]
  C --> D[Walidacja odpowiedzi]
  D --> E{Akcja dozwolona?}
  E -->|tak| F[Recepcja zatwierdza]
  E -->|nie| G[Blokada i log]
  F --> H[EDM lub CRM po kontroli]

Rys. 1. Prosty przepływ zabezpieczeń: AI przygotowuje odpowiedź, ale akcję zatwierdza człowiek i reguły placówki.

W takim układzie instrukcje systemowe są oddzielone od danych pacjenta, a zewnętrzne treści są traktowane jako materiał do analizy, nie jako polecenia. To nie usuwa ryzyka do zera, ale zmniejsza skutki pomyłki modelu. Właśnie o to chodzi w realnym wdrożeniu: nie obiecywać odporności absolutnej, tylko projektować proces tak, żeby błąd nie przeniósł się automatycznie do dokumentacji lub obsługi pacjenta.

Co AI może zrobić, a czego nie powinno robić samo

AI może wykonać wiele użytecznych czynności: wyłapać brakujące pola, streścić wiadomość, zaproponować kategorię sprawy, przygotować szkic odpowiedzi do pacjenta. To są działania pomocnicze. Problem zaczyna się wtedy, gdy model ma prawo samodzielnie wykonać akcję o skutku dla pacjenta albo dla placówki.

Ja bym rozdzielił to na trzy poziomy. Poziom niski to odpowiedzi informacyjne z zatwierdzonej bazy wiedzy, na przykład godziny pracy albo ogólna ścieżka rejestracji. Poziom średni to klasyfikacja sprawy i propozycja działania dla recepcji. Poziom wysoki to zmiana terminu, triage, zapis do dokumentacji, interpretacja kliniczna lub przekazanie danych dalej. Ten trzeci poziom wymaga człowieka w pętli.

To ma sens, gdy placówka potrafi wskazać konkretne akcje, które AI może tylko zaproponować, oraz osobę, która je zatwierdza. To nie ma sensu, gdy chatbot dostaje szeroki dostęp do narzędzi i ma „sam sobie poradzić” z wyjątkami, zwłaszcza przy danych pacjenta, dokumentach medycznych lub skargach.

Przykład modelowy: formularz przed wizytą i chatbot na stronie

Przykład modelowy — scenariusz pokazuje sposób myślenia o pilotażu. Liczby ilustrują metryki, nie gwarantują wyniku wdrożenia.

Załóżmy, że prywatna przychodnia specjalistyczna w Polsce chce połączyć formularz przed wizytą z chatbotem na stronie. Pacjent opisuje powód kontaktu, dołącza dokument i pyta, czy powinien umówić konsultację. AI ma uporządkować treść dla rejestracji, ale nie diagnozować i nie kwalifikować medycznie pacjenta.

Ryzykowny scenariusz wygląda tak: w dokumencie albo opisie pojawia się instrukcja, która próbuje zmienić zachowanie modelu. System bez zabezpieczeń może potraktować ją jak polecenie, pominąć normalny ton odpowiedzi, zasugerować pilność albo ujawnić fragment wewnętrznych reguł. W dobrze ustawionym procesie model powinien zignorować instrukcje pochodzące z danych pacjenta, oznaczyć sprawę jako wymagającą weryfikacji i przekazać recepcji neutralne streszczenie.

Human-in-the-loop jest tu bardzo konkretny. Recepcja może potwierdzić dane kontaktowe, manager może ocenić reguły eskalacji, a lekarz lub uprawniony personel medyczny decyduje o znaczeniu klinicznym informacji. AI przygotowuje kontekst, człowiek zatwierdza decyzję i odpowiada za dalszy krok. Bez tego łatwo pomylić automatyzację obsługi z automatyzacją odpowiedzialności.

Mini-test dla managera przed pilotażem

Przed rozmową z dostawcą warto zrobić krótki test warsztatowy. Nie chodzi o łamanie systemu, tylko o sprawdzenie, czy proces ma jasne granice wejścia, akcji i eskalacji. Ten test można przeprowadzić bez danych pacjenta, na fikcyjnych, neutralnych przykładach.

Jesteś zespołem wdrożeniowym placówki medycznej.
Przetestuj planowany chatbot lub asystenta AI bez używania danych pacjenta.
Sprawdź trzy kanały wejścia: formularz, dokument testowy, rozmowa z chatbotem.
Dla każdego kanału opisz:
1. jakie instrukcje systemowe są oddzielone od danych użytkownika,
2. jakie akcje są na whiteliście,
3. które odpowiedzi wymagają zatwierdzenia recepcji, IOD lub lekarza,
4. jakie zdarzenia trafiają do logu i jak długo są przechowywane.
Nie proponuj diagnozy, leczenia ani zapisu do EDM bez człowieka w pętli.

Wynik takiego ćwiczenia powinien być prosty: lista dozwolonych akcji, lista zablokowanych akcji i lista wyjątków do człowieka. Jeśli dostawca nie potrafi pokazać whitelisty akcji ani logów, to placówka nie ma jak udowodnić, że kontroluje proces. To jest moment, w którym sugeruję zatrzymać pilotaż, zanim wejdzie w dane medyczne.

W szerszym planie bezpieczeństwa warto wpisać prompt injection do kategorii dane i bezpieczeństwo, obok Shadow AI, polityki korzystania z narzędzi i umów z dostawcami. To nie jest osobny problem IT. To część zarządzania tym, gdzie trafiają dane i kto odpowiada za decyzję.

Metryki, które pokażą, czy ryzyko maleje

Właściciel placówki nie musi mierzyć prompt injection jak laboratorium bezpieczeństwa. Powinien jednak mieć kilka liczb, które pokazują, czy system zachowuje się przewidywalnie. Bez metryk zostaje tylko wiara w dostawcę, a to za mało przy danych pacjenta.

• odsetek rozmów lub dokumentów przekazanych do ręcznej weryfikacji,
• liczba prób wykonania niedozwolonej akcji przez AI,
• liczba odpowiedzi cofniętych przez recepcję lub managera,
• czas reakcji na zgłoszenie błędu lub podejrzanej odpowiedzi,
• liczba zmian w whiteliście akcji po testach i incydentach.

Te metryki nie mają udowodnić gwarantowanego ROI. Mają pokazać, czy placówka zmniejsza powierzchnię ryzyka i szybciej wychwytuje wyjątki. Jeśli po miesiącu rośnie liczba blokad, to nie musi oznaczać porażki. Może oznaczać, że system wreszcie pokazuje sytuacje, które wcześniej były niewidoczne.

Pierwszy krok w tym tygodniu

Najpraktyczniejszy start to mapa wejść do AI. Weź formularz, chatbot, skrzynkę e-mail, dokumenty od pacjentów i bazę wiedzy. Przy każdym punkcie zapisz, czy AI tylko czyta treść, czy może też wykonać akcję. Ta druga kolumna jest najważniejsza, bo prompt injection staje się groźniejsze tam, gdzie model ma narzędzia.

Potem zadaj dostawcy pięć pytań: jak oddziela instrukcje od danych, jakie akcje są dozwolone, kto zatwierdza wyjątki, co trafia do logów i czy można wyłączyć automatyczny zapis do EDM. Jeżeli odpowiedź jest ogólna, poproś o pokazanie tego na procesie placówki, nie na prezentacji sprzedażowej.

Na końcu ustal zasadę roboczą: przez pierwszy miesiąc AI nie wykonuje żadnej akcji o skutku medycznym lub administracyjnym bez człowieka. To spowalnia start, ale daje placówce materiał do oceny. W medycynie wolę wolniejszy pilotaż z kontrolą niż szybkie wdrożenie, którego nikt nie potrafi później wyjaśnić.

Źródła

• UODO — „Czy AI to zagrożenie dla danych?”, 10.06.2026. Polskie źródło urzędowe; pokazuje, że przy AI problemem dla organizacji jest utrata kontroli nad celem, zakresem i odpowiedzialnością za przetwarzanie danych, szczególnie przy danych medycznych.
• OWASP GenAI Exploit Round-up Report Q1 2026, 14.04.2026. Źródło branżowe bezpieczeństwa; wskazuje prompt injection jako realnie wykorzystywany typ ryzyka LLM i łączy go z wyciekiem danych oraz niewłaściwą obsługą wyjścia modelu.
• NCSC — Thinking carefully before adopting agentic AI, 06.2026. Praktyczne tło cyberbezpieczeństwa; podkreśla, że systemy agentowe dziedziczą ryzyka prompt injection, a większa autonomia zwiększa powierzchnię ataku i utrudnia nadzór.
• Health Sector Coordinating Council — Health Sector Publishes Guide for Third-Party A.I. Cybersecurity, 15.04.2026. Źródło sektorowe dla ochrony zdrowia; użyte jako benchmark rozmowy z dostawcami AI i kontroli ryzyk cyberbezpieczeństwa w łańcuchu usług.
• Pexels — zdjęcie Cedric Fauntleroy, dostęp: 2026-07-02. Atrybucja okładki; spokojny kadr recepcji kliniki, bez sensacyjnego tonu.