Czego dowiesz się z tego artykułu?

  • Jak przygotować opis procesu AI, żeby rozmowa z ubezpieczycielem nie zatrzymała się na haśle „sztuczna inteligencja”.
  • O co zapytać brokera, ubezpieczyciela i dostawcę narzędzia przed startem w polskiej placówce medycznej.
  • Gdzie obowiązkowe OC placówki może nie wystarczyć, jeśli pilotaż dotyka danych, dokumentacji albo reklamacji.
  • Jak zostawić człowieka w decyzji klinicznej i organizacyjnej, żeby nie przenosić odpowiedzialności na system.

Właściciel przychodni rzadko pyta o polisę OC, kiedy ogląda demo narzędzia AI. Pyta o telefony, dokumenty, rejestrację, skrócenie kolejek i mniej chaosu w recepcji. A jednak przy pilotażu medycznym ubezpieczenie powinno wejść do rozmowy wcześniej niż umowa produkcyjna, bo problem zaczyna się nie przy slajdzie dostawcy, tylko przy realnym skutku dla pacjenta.

W polskiej placówce medycznej polisa OC nie jest magiczną osłoną na każdy błąd procesu. Trzeba rozdzielić szkody związane z udzielaniem świadczeń zdrowotnych, naruszenia danych, kary umowne, awarie systemu, błędną komunikację i reklamację pacjenta. Ja bym zaczęła od bardzo prostego pytania: co dokładnie AI robi, kto zatwierdza wynik i jaki ślad zostaje, gdy pacjent zakwestionuje działanie placówki?

To nie jest porada prawna ani instrukcja likwidacji szkody. To jest mapa rozmowy dla managera, który chce przed startem pilotażu wejść do brokera i dostawcy z konkretną kartą ryzyka, a nie z ogólnym zdaniem: „będziemy używać AI”. Im bardziej konkretny opis procesu, tym mniej miejsca na późniejsze zdziwienie.

Najważniejsze

  • Nie pytaj, czy polisa „obejmuje AI”. Zapytaj, czy obejmuje konkretny proces: rejestrację, dokumentację, komunikację z pacjentem, analizę dokumentów albo wsparcie lekarza.
  • Obowiązkowe OC placówki dotyczy szkód z udzielania świadczeń zdrowotnych lub zaniechania ich udzielenia. Nie zakładaj automatycznie, że pokryje każdy błąd dostawcy, cyberincydent, karę umowną lub naruszenie danych.
  • Human-in-the-loop musi być opisany w procedurze. Lekarz, rejestracja, manager albo IOD powinni wiedzieć, kiedy AI kończy pracę, a człowiek zatwierdza dalszy krok.
  • Najważniejsza metryka nie brzmi „czy narzędzie działa”. Dla polisy ważniejsze jest pisemne potwierdzenie zakresu ochrony, wyłączeń, podziału odpowiedzialności i ścieżki reklamacji.
  • Pierwszy krok to karta ryzyka procesu. Jedna strona wystarczy, jeśli pokazuje zastosowanie AI, dane, decyzję człowieka, dostawcę i możliwy scenariusz szkody.

Najpierw opisz proces, potem polisę

Rozmowa z ubezpieczycielem nie powinna zaczynać się od nazwy modelu ani od porównania dostawców. Polisa odpowiada na ryzyko konkretnego działania, więc potrzebuje opisu działania: kto coś robi, na jakich danych, w jakim systemie, z jakim skutkiem i kto może zatrzymać wynik. W praktyce inna rozmowa dotyczy voicebota przypominającego o terminie, inna narzędzia streszczającego dokumentację, a jeszcze inna systemu podpowiadającego lekarzowi kolejny krok.

Ja bym przygotowała opis w pięciu zdaniach. Pierwsze: jaki proces w placówce wspiera AI. Drugie: jakie dane widzi system i czy są to dane medyczne. Trzecie: co AI może tylko przygotować, a czego nie może zrobić samodzielnie. Czwarte: kto zatwierdza wynik przed kontaktem z pacjentem albo wpisem w dokumentacji. Piąte: gdzie zapisujemy logi, reklamację i decyzję człowieka. To jest język ubezpieczeniowy bardziej niż technologiczny, bo pozwala ocenić ryzyko działania, a nie modę na narzędzie.

Warto też od razu oddzielić dostawcę od placówki. Jeśli błąd wynika z konfiguracji procesu, braku nadzoru albo niewłaściwego użycia przez personel, rozmowa o odpowiedzialności będzie inna niż przy awarii po stronie dostawcy. Regulamin narzędzia, umowa powierzenia, SLA i polisa OC placówki muszą się ze sobą spotkać, a nie leżeć w trzech różnych folderach.

Matryca ryzyka dla rozmowy o ochronie

Najbardziej praktyczny dokument przed spotkaniem z brokerem to prosta matryca. Nie musi mieć piętnastu kolumn. Powinna pokazać, czy ryzyko dotyczy świadczenia zdrowotnego, danych pacjenta, komunikacji, dostawcy, cyberbezpieczeństwa albo relacji z pacjentem. Dopiero na tej podstawie można pytać o wyłączenia, rozszerzenia i dodatkowe polisy, zamiast oczekiwać jednej odpowiedzi na całe „AI”.

Ryzyko w procesieMożliwy skutek dla placówkiCo opisać przed rozmową o polisieKto zatwierdza / eskaluje
AI błędnie klasyfikuje wiadomość pacjentaSpóźniony kontakt, reklamacja, zarzut złej organizacjiTypy spraw, reguły eskalacji, log odrzuconych wynikówKierownik rejestracji
AI streszcza dokument przed wizytąRyzyko pominięcia informacji klinicznejZakres danych, oznaczenie szkicu, zakaz samodzielnej interpretacjiLekarz lub uprawniony personel
AI wysyła komunikat administracyjnyBłędna informacja o terminie, płatności lub przygotowaniuSzablony, akceptacja treści, historia wysyłekRecepcja / manager
Dostawca przechowuje dane lub logiRyzyko naruszenia RODO i sporu o odpowiedzialnośćUmowa, retencja, lokalizacja danych, dostęp administracyjnyIOD + właściciel procesu
Pacjent składa reklamację po użyciu AISpór o to, kto podjął decyzjęŚlad decyzji człowieka, procedura reklamacyjna, punkt kontaktuManager placówki

Taka tabela nie zastępuje OWU ani opinii brokera, ale robi jedną ważną rzecz: zmusza placówkę do nazwania miejsca, w którym może powstać szkoda. Bez tego ubezpieczyciel słyszy tylko ogólną deklarację technologiczną. Z takim opisem może odnieść się do zakresu OC, wyłączeń, odpowiedzialności dostawcy i ewentualnej potrzeby dodatkowej ochrony, na przykład cyber.

Pytania do dostawcy i brokera

Do dostawcy zapytałabym najpierw o dokumenty, które potem pokażesz brokerowi. Czy dostawca potrafi opisać przeznaczenie systemu, ograniczenia użycia, zakres danych, logi, retencję i tryb awaryjny? Jeżeli nie potrafi, placówka zostaje z marketingowym opisem funkcji, a nie z materiałem do oceny ryzyka.

Do brokera i ubezpieczyciela warto zanieść zestaw pytań wprost. Nie chodzi o straszenie ubezpieczyciela AI, tylko o uzyskanie pisemnej odpowiedzi, co jest objęte ochroną, co wymaga rozszerzenia, a czego polisa nie obejmie. Minimum pytań wygląda tak:

  • Czy opisany proces mieści się w aktualnym zakresie obowiązkowego OC placówki, czy wymaga dodatkowej ochrony?
  • Jak polisa traktuje błąd organizacyjny w procesie, w którym AI przygotowuje szkic, a człowiek zatwierdza decyzję?
  • Czy szkody wynikające z naruszenia danych, cyberincydentu albo awarii dostawcy są objęte tą polisą, czy wymagają osobnego produktu?
  • Czy OWU zawiera wyłączenia dotyczące automatyzacji, outsourcingu IT, narzędzi chmurowych, kar umownych albo utraty rzeczy?
  • Jak powinien wyglądać log zdarzenia, żeby w razie reklamacji dało się odtworzyć decyzję człowieka?
  • Czy dostawca powinien mieć własne OC zawodowe, cyber lub inne potwierdzenie odpowiedzialności kontraktowej?
  • Kto i w jakim terminie zgłasza incydent albo reklamację: manager, IOD, dostawca, broker czy właściciel placówki?

Odpowiedzi powinny trafić do dokumentacji pilotażu, nie tylko do skrzynki mailowej jednej osoby. Pisemne potwierdzenie zakresu ochrony jest tutaj metryką sukcesu, bo zmniejsza ryzyko, że po zdarzeniu każdy uczestnik procesu będzie rozumiał polisę inaczej.

Jak to wygląda w przychodni

Przykład modelowy — opis pokazuje sposób myślenia o ryzyku procesu. Nie jest opisem realnego pacjenta, szkody ani konkretnej polisy.

Wyobraźmy sobie prywatną przychodnię specjalistyczną, która chce użyć AI do porządkowania wiadomości z formularza kontaktowego i przygotowywania szkicu odpowiedzi administracyjnej. System nie kwalifikuje objawów, nie decyduje o pilności wizyty i nie wpisuje informacji do dokumentacji medycznej bez człowieka.

System tworzy roboczą kategorię sprawy, a recepcja zatwierdza odpowiedź albo przekazuje temat lekarzowi, managerowi lub IOD.

W takim układzie rozmowa o polisie nie dotyczy abstrakcyjnej „odpowiedzialności za AI”. Dotyczy błędnej informacji o terminie, opóźnionej eskalacji, naruszenia danych w formularzu, problemu z logami dostawcy i reklamacji pacjenta. Lekarz pozostaje odpowiedzialny za decyzję kliniczną, recepcja za zatwierdzenie komunikatu administracyjnego, a manager za to, że proces ma właściciela i ślad kontroli.

Jeśli po miesiącu przychodnia chce rozszerzyć zakres na streszczanie dokumentów przed wizytą, powinna wrócić do brokera z nową wersją karty ryzyka. Zmiana procesu może zmienić rozmowę o ochronie, nawet jeśli dostawca i panel użytkownika są te same. To jest moment, w którym wiele placówek popełnia błąd: traktują pilotaż jako stały opis ryzyka, a nie żywy dokument.

Granice decyzji: kiedy i kiedy nie

To ma sens, gdy placówka potrafi pokazać jeden proces, zakres danych, właściciela decyzji, regułę eskalacji i odpowiedź brokera przed startem. Wtedy AI jest elementem zarządzanego procesu, a nie czarną skrzynką między pacjentem, recepcją i lekarzem. Ubezpieczyciel nie musi rozumieć każdego modelu językowego, ale powinien dostać jasny opis ryzyka i kontroli.

To nie ma sensu, gdy placówka mówi: „zobaczymy w praktyce”, nie ma zgody IOD, nie wie, czy dane trafiają do trenowania modelu, i pozwala systemowi wysyłać komunikaty bez akceptacji człowieka. W takim układzie polisa staje się rozmową ratunkową po fakcie, a nie narzędziem zarządzania ryzykiem.

Najbardziej niebezpieczne są procesy na granicy administracji i medycyny: kwalifikacja pilności, interpretacja objawów, komunikaty po zabiegu, wstępna ocena wyniku badania. Tu human-in-the-loop musi być realny. Człowiek ma mieć prawo zatrzymać, poprawić i odrzucić wynik AI, a pacjent nie powinien odbierać szkicu systemu jako samodzielnej decyzji klinicznej.

Pierwszy krok dla właściciela placówki

Przed telefonem do brokera przygotuj jedną stronę. Na górze wpisz nazwę procesu, na przykład: „AI porządkuje wiadomości z formularza i przygotowuje szkic odpowiedzi administracyjnej”. Niżej dopisz dane, role, decyzje człowieka, dostawcę, logi i możliwe zdarzenie sporne. Jedna dobra karta ryzyka jest więcej warta niż długi opis funkcji z oferty handlowej.

Potem zrób trzy krótkie rozmowy. Pierwsza: z dostawcą, żeby potwierdzić ograniczenia systemu i dokumenty. Druga: z IOD, żeby ustalić podstawę, zakres danych i rozliczalność. Trzecia: z brokerem albo ubezpieczycielem, żeby dostać odpowiedź o zakresie ochrony i ewentualnych wyłączeniach. Sugeruję nie uruchamiać procesu dotykającego pacjenta, dopóki te trzy odpowiedzi nie są spójne.

Na koniec wpisz do procedury, kto zgłasza reklamację i gdzie szuka logów. To brzmi nudno, ale właśnie w nudnych miejscach wygrywa się spory. AI w placówce medycznej ma pomagać ludziom pracować spokojniej, a nie dokładać ryzyko, którego nikt nie umie przypisać.

Źródła