Kiedy placówka medyczna rozważa asystenta głosowego odbierającego telefon, rozmowa zwykle kręci się wokół tego, czy głos brzmi naturalnie i czy system rozumie polskie nazwiska. To są ważne pytania. Nie są to jednak pytania, które zdecydują o tym, czy wdrożenie przetrwa pierwszą kontrolę albo pierwszą skargę pacjenta.
Te pytania brzmią inaczej. Gdzie fizycznie leży nagranie rozmowy z pacjentem. Na jakiej podstawie prawnej je przetwarzacie. Jak długo je trzymacie i kto je może odsłuchać. Kto jest podmiotem przetwarzającym, a kto administratorem. I czy pacjent wie, że rozmawiał z maszyną.
Odpowiedzi na nie nie ma w żadnej ofercie, jaką widzieliśmy. Zebrałem więc w jednym miejscu to, co trzeba ustalić, zanim taki system w ogóle zadzwoni.
Zastrzeżenie na wejściu, bo jest istotne: nie jesteśmy kancelarią i to nie jest opinia prawna. Budujemy systemy i wiemy, które decyzje techniczne przesądzają o tym, czy da się na te pytania odpowiedzieć. Przy konkretnym wdrożeniu i tak potrzebujecie inspektora ochrony danych albo kancelarii, a ten tekst ma sprawić, że rozmowa z nimi będzie krótsza.
Nagranie rozmowy o wizycie to dane o zdrowiu
Pierwsza rzecz, która bywa zaskoczeniem: samo to, że ktoś umawia się do konkretnego lekarza, jest już informacją o jego zdrowiu.
Nie trzeba mówić o objawach. Wystarczy, że pacjent prosi o termin u psychiatry, onkologa albo w poradni leczenia uzależnień. Nazwa specjalizacji w połączeniu z imieniem i nazwiskiem mówi o tej osobie rzecz, której nie chciałaby zobaczyć w cudzych rękach.
Pisałem już o tym przy okazji tego, czego RODO wymaga od strony kliniki, i przy telefonie zasada jest dokładnie ta sama, tylko kanał inny.
RODO nazywa to szczególną kategorią danych i traktuje inaczej niż zwykłe dane kontaktowe. Zasadą jest zakaz przetwarzania, a przetwarzać wolno tylko wtedy, gdy zachodzi jeden z wyjątków wymienionych w art. 9. Podmioty lecznicze zwykle opierają się tu na przesłance dotyczącej sprawowania opieki zdrowotnej, ale to nie jest przesłanka, która obejmuje wszystko, co da się w placówce zrobić z głosem pacjenta.
Praktyczna konsekwencja: zapis na wizytę i nagranie rozmowy to dwie różne operacje i każda potrzebuje własnego uzasadnienia. To, że wolno Wam zapisać pacjenta, nie znaczy automatycznie, że wolno Wam trzymać nagranie tej rozmowy przez rok, bo przyda się na wypadek reklamacji.
Cztery pytania o nagranie, na które trzeba mieć odpowiedź
Czy w ogóle musicie nagrywać. To jest pierwsze i najczęściej pomijane pytanie. Asystent głosowy do działania potrzebuje przetworzyć dźwięk na tekst. Nie potrzebuje do tego trwałego przechowywania pliku audio. Da się zbudować przepływ, w którym nagranie żyje kilkadziesiąt sekund w pamięci, a to, co zostaje, to sucha notatka: kto dzwonił, w jakiej sprawie, jaki termin ustalono. Jeżeli nagranie nie jest Wam do niczego potrzebne, najtańsza zgodność polega na tym, żeby go nie mieć.
Jak długo je trzymacie, jeśli już trzymacie. Retencja musi być liczbą wpisaną w konfigurację systemu, nie deklaracją w polityce. Różnica ujawnia się przy pierwszym żądaniu usunięcia danych. „Kasujemy po trzydziestu dniach” jest odpowiedzią tylko wtedy, gdy ktoś potrafi pokazać, gdzie ta trzydziestka jest ustawiona i co się dzieje z kopiami zapasowymi.
Kto ma dostęp. Nagranie rozmowy z pacjentem nie powinno być dostępne dla wszystkich, którzy mają dostęp do panelu asystenta. To jest ten sam problem, który znacie z systemu gabinetowego, tylko w nowym miejscu i zwykle nierozwiązany, bo panel dostawcy ma jedną rolę: administrator.
Co się dzieje z transkryptem. Tekst rozmowy to nadal te same dane. Bywa, że placówka porządnie ogarnia nagrania i zupełnie zapomina o transkryptach, które lądują w logach, w narzędziu do analityki jakości i w skrzynce mailowej kierowniczki rejestracji.
Dwie umowy powierzenia, nie jedna
Tu jest najczęstszy błąd konstrukcyjny, jaki widujemy.
Placówka podpisuje umowę powierzenia z firmą, która dostarczyła asystenta, i uznaje temat za zamknięty. Tymczasem w typowym wdrożeniu w przetwarzanie zaangażowane są co najmniej dwa różne podmioty: dostawca telefonii, przez którego przechodzi połączenie, i dostawca modelu językowego, który zamienia mowę na tekst i formułuje odpowiedzi. Bywa, że to trzy podmioty, bo rozpoznawanie mowy i generowanie odpowiedzi robią różne firmy.
Każdy z nich przetwarza dane pacjenta. Dla każdego z nich potrzebna jest podstawa i każdy musi być wymieniony w rejestrze czynności przetwarzania. Jeśli dostawca asystenta korzysta z nich jako podwykonawców, potrzebna jest zgoda na dalsze powierzenie i lista podprocesorów, która jest aktualizowana, a nie napisana raz.
Do tego dochodzi pytanie, które warto zadać wprost i na piśmie: czy dane z rozmów są używane do trenowania modelu. Odpowiedź „nie” musi być w umowie, nie w mailu od handlowca. Duzi dostawcy modeli mają na to osobne tryby korzystania z usługi i one nie włączają się same.
Gdzie te dane fizycznie są
Model językowy nie musi stać w Polsce ani nawet w Unii. Bardzo często nie stoi.
To nie jest automatycznie problem, bo przekazywanie danych poza Europejski Obszar Gospodarczy jest dopuszczalne przy spełnieniu warunków z rozdziału V RODO. To jest natomiast problem, jeśli nikt tego nie sprawdził i nie udokumentował, a przy danych o zdrowiu jest to jedno z pierwszych pytań, jakie padnie przy kontroli.
Pytanie do dostawcy brzmi konkretnie: w jakim regionie przetwarzane jest audio, w jakim regionie przetwarzany jest tekst, i na jakiej podstawie odbywa się ewentualny transfer poza EOG. Jeżeli odpowiedź brzmi „w chmurze”, to nie jest odpowiedź.
Ocena skutków, czyli DPIA
Przy asystencie głosowym w placówce medycznej ocena skutków dla ochrony danych jest w praktyce nie do uniknięcia. Składają się na to trzy rzeczy naraz: dane szczególnej kategorii, nowa technologia i skala, bo mówimy o wszystkich pacjentach dzwoniących do placówki.
Traktujemy DPIA nie jako formalność do odhaczenia po wdrożeniu, tylko jako dokument, który powstaje przed wyborem dostawcy. Powód jest praktyczny: pytania z DPIA to dokładnie te pytania, na które dostawca albo umie odpowiedzieć, albo nie umie. Ten test przechodzi zaskakująco mało ofert.
AI Act: pacjent ma wiedzieć, że rozmawia z maszyną
To jest przepis, który wszedł w życie niedawno i wielu dostawców jeszcze go nie uwzględniło.
Unijne rozporządzenie o sztucznej inteligencji, czyli rozporządzenie (UE) 2024/1689, w art. 50 nakłada obowiązek przejrzystości na systemy przeznaczone do bezpośredniej interakcji z człowiekiem. Asystent głosowy odbierający telefon jest dokładnie takim systemem. Obowiązek jest po stronie dostawcy systemu i polega na tym, że system ma być zaprojektowany tak, żeby osoba wiedziała, że ma do czynienia ze sztuczną inteligencją. Informacja ma trafić do człowieka na początku interakcji, nie w regulaminie na stronie.
Ten obowiązek stosuje się od 2 sierpnia 2026, czyli już teraz. Przewidziano wyjątki, między innymi wtedy, gdy jest to oczywiste dla rozsądnie zorientowanej osoby oraz w sytuacjach związanych ze ściganiem przestępstw, ale żaden z nich nie dotyczy rejestracji w przychodni.
W praktyce sprowadza się to do jednego zdania w otwarciu rozmowy. Warto jednak zauważyć, że to samo zdanie rozwiązuje przy okazji problem, który i tak byście mieli: pacjenci orientują się, że rozmawiają z automatem, a ci, którzy zostali w to wpuszczeni bez uprzedzenia, czują się oszukani i piszą o tym w opiniach.
Gdzie kończy się organizacja pracy, a zaczyna medycyna
Osobna granica, o której napisałem szerzej w tekście o tym, co asystent głosowy naprawdę robi, ale która wraca tutaj w wersji regulacyjnej.
Asystent, który zapisuje na wizytę, informuje o terminach i przekierowuje do człowieka, jest narzędziem organizacyjnym. Asystent, który zbiera objawy po to, żeby ocenić pilność albo pokierować pacjenta do właściwego specjalisty, robi coś jakościowo innego i wchodzi w obszar, w którym pojawiają się wymogi znacznie cięższe niż wszystko, o czym piszę powyżej.
Nie chodzi o to, że tego nie da się zbudować. Chodzi o to, że to jest inny projekt, z inną dokumentacją, innym budżetem i innym czasem. Placówka, która zamawia usprawnienie rejestracji, a dostaje coś, co po cichu ocenia stan zdrowia, ma problem, o którym dowie się najpóźniej.
Czego to nie załatwia
Uczciwie: zgodność asystenta głosowego nie czyni placówki zgodnej.
Jeśli podlegacie pod NIS2, to obowiązki dotyczące zarządzania ryzykiem, kopii zapasowych i zgłaszania incydentów nie znikają dlatego, że telefon odbiera teraz system. Przybywa Wam natomiast jeden dostawca do rejestru i jeden kanał, przez który przechodzą dane pacjentów, więc to jest raczej nowa pozycja w analizie ryzyka niż jej zamknięcie.
Podobnie z RODO. Rejestr czynności przetwarzania, obowiązek informacyjny i polityka retencji trzeba zaktualizować, nie odhaczyć.
Lista pytań do dostawcy
Jeżeli mielibyście wziąć z tego tekstu jedną rzecz, to niech to będzie ta lista. Zadajcie te pytania na piśmie, zanim podpiszecie cokolwiek.
| Pytanie | Czego szukacie w odpowiedzi |
|---|---|
| Czy nagranie audio jest przechowywane, czy przetwarzane ulotnie | Konkretna odpowiedź, nie „zależy od konfiguracji” |
| Jaka jest retencja nagrań i transkryptów | Liczba dni i miejsce, gdzie się ją ustawia |
| Kto jest podprocesorem i gdzie przetwarza dane | Pełna lista z regionami, aktualizowana |
| Czy dane z rozmów trenują model | „Nie” zapisane w umowie |
| Jak system informuje pacjenta, że jest automatem | Zdanie otwarcia, nie zapis w regulaminie |
| Jak wygląda przekazanie do człowieka | Ścieżka, którą pacjent uruchamia sam |
| Kto w panelu widzi treść rozmów | Role i uprawnienia, nie jedno konto administratora |
| Co system robi, gdy pacjent mówi o objawach | Odmowa oceny i przekierowanie, nie próba pomocy |
Dostawca, który odpowie na te osiem pytań bez uników, prawdopodobnie robi to poważnie. Dostawca, który zacznie od tego, że „to wszystko jest zgodne z RODO”, jeszcze się nad tym nie zastanawiał.
Budujemy asystentów głosowych i te pytania traktujemy jak część specyfikacji, a nie jak załącznik prawny na koniec. Odpowiada na nie u nas ta sama osoba, która potem pisze integrację, więc nie kończy się na deklaracji w ofercie. Jeżeli chcecie przejść tę listę na konkretnym przypadku swojej placówki, napiszcie do mnie. Więcej o tym, jak podchodzimy do regulacji unijnych w projektach IT i co dokładnie robimy dla placówek medycznych, jest na osobnych stronach.



