Czego dowiesz się z tego artykułu?
- Kiedy prywatny model AI albo lokalne środowisko rzeczywiście pomaga polskiej placówce medycznej.
- Kiedy bezpieczny SaaS z dobrą umową, logami i kontrolą dostępu będzie rozsądniejszy niż własna infrastruktura.
- Jak policzyć koszt organizacyjny: utrzymanie, bezpieczeństwo, odpowiedzialność i pracę zespołu.
- Jak ustawić human-in-the-loop przy danych pacjenta i decyzjach klinicznych.
W placówce medycznej hasło „prywatny model AI” często brzmi jak prosta odpowiedź na wszystkie obawy o dane. Tylko że lokalne środowisko nie jest magicznym sejfem. Jeśli nikt go nie aktualizuje, nie monitoruje logów i nie pilnuje uprawnień, ryzyko może być większe niż przy dobrze dobranym rozwiązaniu SaaS.
Ja bym zaczął od pytania bardziej przyziemnego: jaki proces chcesz wesprzeć i jakie dane naprawdę muszą do niego trafić. Inaczej rozmawia się o botcie porządkującym pytania recepcji, inaczej o wyszukiwarce w wewnętrznej bazie procedur, a jeszcze inaczej o systemie analizującym opis badania albo notatkę lekarza.
Ten tekst jest dla właściciela, managera i IOD w polskiej przychodni lub klinice. Nie chodzi o wybór najmodniejszej architektury. Chodzi o decyzję, czy placówka ma kompetencje, skalę i ryzyko uzasadniające prywatny model AI, czy raczej powinna zacząć od bezpiecznego SaaS z umową powierzenia, kontrolą dostępu i jasnym zakresem użycia.
Najważniejsze
- Prywatny model AI ma sens dopiero wtedy, gdy placówka wie, jakie dane przetwarza, po co je przetwarza i kto odpowiada za utrzymanie środowiska.
- Lokalna infrastruktura może ograniczyć ekspozycję danych, ale zwiększa obowiązki: aktualizacje, monitoring, kopie, testy bezpieczeństwa, role użytkowników i reagowanie na incydenty.
- Bezpieczny SaaS bywa lepszą decyzją dla małej lub średniej placówki, jeśli dostawca daje umowę powierzenia, retencję, logi, brak trenowania na danych placówki i realny support.
- To ma sens, gdy placówka przetwarza dużo danych medycznych, ma własną bazę wiedzy, wysokie wymagania audytowe i zespół zdolny utrzymać środowisko.
- To nie ma sensu, gdy „prywatny model” ma tylko uspokoić zarząd, a placówka nie ma procesu, polityki danych ani ludzi do obsługi infrastruktury.
Rys. 1. Decyzja o architekturze zaczyna się od procesu, danych i odpowiedzialności, nie od nazwy modelu.
Decyzja w skrócie
Prywatny model AI warto rozważyć wtedy, gdy placówka ma konkretny powód organizacyjny, a nie tylko ogólny lęk przed chmurą. Przykłady: duża liczba dokumentów wewnętrznych, własne procedury, potrzeba wyszukiwania w bazie wiedzy, szczególne wymagania klienta korporacyjnego, praca z materiałem medycznym, którego nie można wysyłać do publicznych narzędzi.
Bezpieczny SaaS warto rozważyć wtedy, gdy proces jest prostszy, dostawca ma jasną dokumentację, umowę powierzenia, możliwość wyłączenia trenowania na danych placówki, kontrolę retencji i logi dostępu. Nie każdy SaaS jest bezpieczny, ale też nie każde lokalne wdrożenie jest dojrzałe. Różnica leży w kontroli, nie w etykiecie.
| Opcja | Kiedy wybrać | Na co uważać |
|---|---|---|
| Prywatne środowisko AI | Duża skala, dane medyczne, własna baza wiedzy, wysokie wymagania audytowe | Koszt utrzymania, aktualizacje, monitoring, kopie, podatności, brak zespołu |
| Bezpieczny SaaS | Mniejszy pilotaż, proces administracyjny, szybki start z kontrolą umowną | Powierzenie, lokalizacja danych, trenowanie modeli, retencja, logi, eksport |
| Publiczne narzędzie AI | Wyłącznie neutralne testy bez danych pacjentów i bez tajemnicy placówki | Ryzyko utraty kontroli nad danymi, brak podstawy do pracy na dokumentacji medycznej |
To rozróżnienie jest ważne w całej kategorii dane i bezpieczeństwo. Jeśli narzędzie zaczyna wpływać na decyzję kliniczną, dochodzi jeszcze pytanie o status wyrobu medycznego i AI Act; ten wątek rozwija tekst o tym, kiedy AI może być traktowane jak wyrób medyczny.
Najpierw nazwij proces i dane
Najgorsza decyzja brzmi: „zróbmy prywatny model, będzie bezpiecznie”. Bez mapy procesu to tylko droższa wersja chaosu. Manager powinien najpierw nazwać przypadek użycia: rejestracja, wyszukiwarka procedur, podsumowania rozmów, wsparcie dokumentacji, analiza wewnętrznych instrukcji, edukacja pacjenta po zatwierdzeniu przez personel.
Dopiero potem trzeba rozpisać dane. Czy system widzi dane identyfikujące pacjenta? Czy widzi informacje o stanie zdrowia? Czy dostaje pełne dokumenty, czy tylko zanonimizowany opis procesu? Czy wynik trafia do dokumentacji, do zadania recepcji, czy tylko do roboczego szkicu? To są decyzje organizacyjne, nie techniczne dodatki.
Sugeruję prostą tabelę przed rozmową z dostawcą. W pierwszej kolumnie: proces. W drugiej: dane. W trzeciej: osoba zatwierdzająca wynik. W czwartej: miejsce zapisu logów. Jeśli placówka nie umie tego wypełnić, lokalny model nie rozwiąże problemu. On tylko przeniesie go na serwer, który ktoś będzie musiał utrzymywać.
Kiedy prywatne środowisko naprawdę się broni
Prywatne środowisko ma sens, gdy placówka ma realną przewagę z kontroli nad danymi i wiedzą. Przykład: sieć klinik ma tysiące wewnętrznych procedur, standardy obsługi, instrukcje dla rejestracji, własne materiały edukacyjne i potrzebuje wyszukiwarki, która nie wypycha treści do zewnętrznego modelu. Wtedy lokalny RAG, prywatna instancja modelu albo dedykowane środowisko mogą być uzasadnione.
Drugi przypadek to wysokie ryzyko danych. Jeśli system ma pracować blisko danych medycznych, opisów wizyt albo wyników badań, placówka powinna ograniczać zakres danych, a nie tylko wybierać architekturę. Prywatny model nie znosi obowiązku minimalizacji, umów, upoważnień, logów i kontroli człowieka.
Trzeci przypadek to skala. Jeżeli placówka ma wiele lokalizacji, powtarzalne procesy, zespół IT lub zewnętrznego opiekuna infrastruktury i jasny budżet utrzymaniowy, prywatne środowisko może dać większą kontrolę nad konfiguracją, integracją i audytem. Bez tej skali koszt organizacyjny może zjeść całą korzyść.
Kiedy SaaS jest rozsądniejszy niż własny model
Dla wielu polskich przychodni bezpieczny SaaS będzie lepszym pierwszym krokiem. Nie dlatego, że chmura jest z definicji bezpieczna, tylko dlatego, że dobry dostawca może zapewnić aktualizacje, monitoring, support, dokumentację i przewidywalny proces wdrożenia. Mała placówka rzadko ma czas i ludzi, żeby samodzielnie utrzymywać model, warstwę aplikacji, serwer, kopie i bezpieczeństwo.
Warunek jest jeden: dostawca musi przejść rozmowę o danych. Umowa powierzenia, lokalizacja przetwarzania, retencja, logi, role użytkowników, eksport, usuwanie danych i informacja, czy dane placówki są używane do trenowania modelu. Jeśli odpowiedzi są mgliste, to nie jest „bezpieczny SaaS”, tylko ładny panel z ryzykiem prawnym.
Ja bym w pierwszym pilotażu ograniczył SaaS do procesu, w którym AI nie podejmuje decyzji klinicznej. Na przykład: klasyfikacja pytań administracyjnych, wyszukiwanie w zatwierdzonych procedurach, szkic wiadomości do pacjenta po zatwierdzeniu przez personel. Człowiek zatwierdza wynik, a placówka mierzy jakość i błędy, zanim dopuści system bliżej danych medycznych.
Koszt, którego nie widać w ofercie
Własny model albo prywatna instancja to nie tylko jednorazowa faktura. To cykl życia. Kto aktualizuje zależności? Kto sprawdza podatności? Kto monitoruje logi dostępu? Kto reaguje, gdy model zaczyna zwracać błędne odpowiedzi na pytania personelu? Jeśli odpowiedź brzmi „nasz informatyk czasem zerknie”, to nie jest plan utrzymania.
Trzeba też policzyć koszt kompetencji. Placówka potrzebuje osoby, która rozumie dane medyczne, osobę od bezpieczeństwa lub IOD, opiekuna dostawcy, właściciela procesu i użytkowników końcowych. Prywatny model bez właściciela procesu staje się kolejną skrzynką, do której każdy wrzuca dokumenty „na próbę”.
Osobny temat to odpowiedzialność za aktualność wiedzy. Jeśli model ma odpowiadać na pytania recepcji o procedury, cennik, przygotowanie do badań albo ścieżki eskalacji, ktoś musi zatwierdzać bazę wiedzy. Nie chcesz, żeby system pewnie cytował starą procedurę, zwłaszcza gdy pacjent pyta o przygotowanie do badania albo zakres dokumentów.
Przykład w klinice: własna baza wiedzy, ale decyzja człowieka
Przykład modelowy — scenariusz pokazuje sposób myślenia o pilotażu. Liczby ilustrują metryki organizacyjne i nie są gwarancją wyniku wdrożenia.
Klinika specjalistyczna w Polsce ma trzy lokalizacje i bardzo dużo powtarzalnych pytań recepcji: przygotowanie do badań, wymagane dokumenty, zasady odwołania wizyty, ścieżka kontaktu po zabiegu. Zespół chce użyć AI, ale nie chce, żeby personel kopiował fragmenty dokumentacji pacjenta do publicznego narzędzia. W tym przypadku prywatna wyszukiwarka w zatwierdzonej bazie wiedzy może mieć sens.
Pilotaż nie obejmuje diagnoz, kwalifikacji ani decyzji terapeutycznych. AI odpowiada tylko na podstawie zatwierdzonych procedur, a jeśli pytanie dotyczy objawów, wyniku badania albo pilności kontaktu, system oznacza sprawę jako eskalację do człowieka. Lekarz lub wyznaczony personel zatwierdza decyzję kliniczną, a rejestracja nie traktuje odpowiedzi AI jako porady medycznej.
Po 30 dniach manager patrzy na metryki: ile pytań trafiło do bazy wiedzy, ile odpowiedzi personel odrzucił, ile razy system wymagał eskalacji i ile procedur trzeba było poprawić. Te liczby nie są obietnicą efektu finansowego. Są materiałem do decyzji, czy utrzymywać prywatne środowisko, rozszerzyć bazę wiedzy albo wrócić do prostszego SaaS.
| Metryka pilotażu | Co mierzyć | Decyzja po miesiącu |
|---|---|---|
| Trafność odpowiedzi | Odsetek odpowiedzi zatwierdzonych przez personel | Czy baza wiedzy jest wystarczająco dobra |
| Eskalacje kliniczne | Liczba pytań przekazanych do człowieka | Czy granice AI są ustawione poprawnie |
| Aktualizacje bazy | Liczba procedur poprawionych po błędach | Czy placówka ma właściciela wiedzy |
| Incydenty danych | Próby wpisania danych pacjenta do systemu | Czy potrzebne są dodatkowe szkolenia i blokady |
Checklista przed wyborem architektury
Poniższa checklista jest do użycia przed spotkaniem z dostawcą. Nie wpisuj do niej danych pacjentów, opisów wizyt ani pełnych dokumentów. Chodzi o decyzję organizacyjną i bezpieczeństwo procesu.
Checklista: prywatny model AI czy bezpieczny SaaS?
1. Proces: jakie jedno zadanie ma wspierać AI?
2. Dane: czy w wejściu pojawiają się dane medyczne albo identyfikujące pacjenta?
3. Decyzja: czy wynik może wpłynąć na decyzję kliniczną, pilność kontaktu lub dokumentację?
4. Człowiek: kto zatwierdza wynik i kto może zatrzymać działanie systemu?
5. Dostawca: czy jest umowa powierzenia, retencja, logi, eksport i usuwanie danych?
6. Trenowanie: czy dane placówki są używane do uczenia modeli lub poprawy usługi?
7. Utrzymanie: kto aktualizuje, monitoruje, testuje kopie i reaguje na incydenty?
8. Koszt: czy budżet obejmuje nie tylko wdrożenie, ale też opiekę przez 12 miesięcy?Jeżeli większość odpowiedzi jest niejasna, nie wybieraj jeszcze architektury. Najpierw zamknij zakres procesu i odpowiedzialność, potem porównuj dostawców. To mniej efektowne niż szybkie demo, ale w danych pacjenta taka kolejność naprawdę ma znaczenie.
Pierwszy krok dla właściciela placówki
Na najbliższe spotkanie przygotuj jedną kartę procesu. Wybierz tylko jeden przypadek użycia, na przykład wyszukiwarkę procedur dla rejestracji albo szkic odpowiedzi administracyjnej. Zapisz dane wejściowe, wynik, osobę zatwierdzającą, miejsce przechowywania logów i ścieżkę eskalacji. Bez tej karty rozmowa o prywatnym modelu będzie za wcześnie.
Potem poproś dwóch dostawców o odpowiedź na te same pytania: jeden wariant prywatny, jeden wariant SaaS. Niech pokażą nie tylko funkcje, ale też retencję, usuwanie danych, logi, role użytkowników, procedurę incydentu i koszt utrzymania. Sugeruję od razu zapytać, co się stanie, gdy placówka zakończy współpracę i chce zabrać dane oraz bazę wiedzy.
Moja rekomendacja: jeśli placówka nie ma skali, zespołu i uzasadnionego ryzyka, zacznij od kontrolowanego SaaS na wąskim procesie. Jeśli ma rozproszone dane, dużą bazę wiedzy i realne wymagania audytowe, prywatne środowisko może być dobrym kierunkiem. W obu przypadkach zasada zostaje ta sama: AI przygotowuje kontekst, człowiek zatwierdza decyzje dotyczące pacjenta.
Źródła
- UODO — Czy AI to zagrożenie dla danych? — oficjalna relacja UODO z 10.06.2026; wnosi aktualny polski kontekst utraty kontroli nad celem, zakresem i odpowiedzialnością za dane w projektach AI oraz ryzyko nieformalnego użycia narzędzi AI przez pracowników, dostęp: 2026-07-01.
- UODO — Mapa źródeł danych medycznych w Polsce — materiał UODO z 14.04.2026; pokazuje rozproszenie danych medycznych i potrzebę uporządkowania dostępu, co jest ważnym argumentem przy własnej bazie wiedzy i lokalnym środowisku AI, dostęp: 2026-07-01.
- Centrum e-Zdrowia — Nowe usługi cyfrowe i projekty AI przyspieszają transformację systemu ochrony zdrowia — komunikat CeZ z 02.06.2026; wnosi polski kontekst AI, centralnych usług e-zdrowia i cyberbezpieczeństwa w ochronie zdrowia, dostęp: 2026-07-01.
- Ministerstwo Cyfryzacji — UE upraszcza przepisy dotyczące sztucznej inteligencji — komunikat z 07.05.2026; porządkuje aktualny kontekst AI Act, systemów wysokiego ryzyka i piaskownic regulacyjnych w Polsce, dostęp: 2026-07-01.
- UODO — Opinia EROD w sprawie sztucznej inteligencji, nieoficjalne tłumaczenie — materiał UODO z 29.04.2025; przydatny do oceny, kiedy model AI można uznać za anonimowy i jakie znaczenie ma legalność danych użytych do opracowania modelu, dostęp: 2026-07-01.
- Zdjęcie: Gustavo Fring na Pexels — atrybucja okładki; spokojny kadr pracy z danymi w klinice, bez sensacyjności i bez widocznych danych pacjenta, dostęp: 2026-07-01.
