Czy AI dla szpitala musi być w chmurze, czy może działać lokalnie na własnym serwerze?

AI dla szpitala nie musi działać w chmurze. Dostępne są modele lokalne (on-premise), w których dane pacjentów nigdy nie opuszczają twojej serwerowni, oraz hybrydowe, gdzie wrażliwe przetwarzanie zostaje wewnątrz, a mniej krytyczne funkcje działają u dostawcy. Wybór zależy od tego, jakie dane AI będzie widział, jak wygląda twoja infrastruktura IT i co konkretny dostawca faktycznie oferuje. Warto to ustalić przed podpisaniem umowy, nie po.

Co w praktyce oznacza "chmura" dla szpitala

Gdy dostawca mówi "chmura", oznacza to zazwyczaj, że dane wysyłasz do jego serwerów, a model AI przetwarza je zdalnie i odsyła wynik. Twoje zapytania, fragmenty dokumentacji, dane pacjentów, treść zleceń: wszystko opuszcza sieć szpitala. Dla wielu funkcji to nie problem. Przy dokumentacji klinicznej już tak.

Kilka rzeczy, które się z tym wiążą:

• Umowa powierzenia przetwarzania danych zgodna z art. 28 RODO jest obowiązkowa, zanim cokolwiek przetwarzasz. To nie formalność, to warunek legalności.
• Lokalizacja serwerów: dane pacjentów powinny być przetwarzane w Unii Europejskiej lub EOG. Zapytaj dostawcę wprost, w którym regionie fizycznie stoją serwery i czy możesz to zablokować umownie.
• DPIA, czyli ocena skutków dla ochrony danych: jeśli AI przetwarza dane wrażliwe pacjentów na dużą skalę, przepisy wymagają jej przeprowadzenia przed uruchomieniem produkcyjnym.
• Stałe łącze jako warunek działania. Awaria internetu w nocy oznacza brak AI.

Modele chmurowe mają też zalety. Szybsze wdrożenie, brak kosztów sprzętowych na start, automatyczne aktualizacje. Dla funkcji, które nie dotykają danych osobowych, chmura jest często najprostszym wyborem.

Kiedy on-premise ma sens w szpitalu

Model lokalny oznacza, że model AI działa na serwerach w twojej serwerowni. Dane pacjentów nie opuszczają infrastruktury placówki. Typowo wygląda to tak, że na dedykowanym serwerze z kartą graficzną (GPU) uruchamiasz model językowy, a aplikacja AI komunikuje się z nim przez wewnętrzną sieć szpitala. Brak połączenia z zewnętrzem przy codziennym przetwarzaniu.

To podejście wybierają głównie:

• szpitale kliniczne i instytuty badawcze, gdzie przetwarzane są rozbudowane zbiory danych diagnostycznych i badawczych,
• placówki z własnym, kompetentnym IT, które są w stanie utrzymać środowisko,
• jednostki, gdzie przetarg lub wymogi właściciela (np. ministerstwo, samorząd) wprost nakazują, żeby dane nie opuszczały budynku,
• szpitale, które po złych doświadczeniach z wyciekami danych lub audytem UODO po prostu nie chcą kolejnych ryzyk.

Jakie są koszty sprzętowe? Nie podajemy liczb, bo różnica między serwerem wystarczającym do małego asystenta administracyjnego a infrastrukturą do analizy obrazowania jest ogromna. Zapytaj dostawcę o minimalne wymagania sprzętowe dla konkretnego przypadku użycia i zestaw to z tym, co już stoi w twojej serwerowni.

Model hybrydowy: co zostaje lokalnie, co może iść na zewnątrz

Większość wdrożeń, które widzimy w polskich placówkach, nie jest ani w pełni chmurowa, ani w pełni lokalna. Podział jest mniej więcej taki:

• Lokalnie: przetwarzanie danych identyfikujących pacjenta, treści dokumentacji medycznej, wyników badań, treści skierowań.
• W chmurze: funkcje niedotykające danych osobowych, np. generowanie szablonów pism urzędowych, tworzenie materiałów dla pacjentów, obsługa ogólnych pytań na chatbocie bez dostępu do konkretnych rekordów.
• Pseudonimizacja przed wysłaniem: część dostawców buduje warstwę, która podmienia dane osobowe zanim zapytanie trafi do modelu w chmurze. To podejście pośrednie, ale wymaga starannej weryfikacji, co faktycznie jest usuwane, a co nie.

U jednego z klientów pracujących na SOR wdrożenie wyglądało tak: analiza objawów i wstępna segmentacja pacjentów działały lokalnie, bo przetwarzały dane kliniczne z numerem PESEL. Generator wyjaśnień dla pacjenta, co oznacza jego kod ICD, był chmurowy, bo dostawał tylko kod i ogólny tekst bez identyfikatorów. To był świadomy podział, a nie przypadek.

Co RODO mówi konkretnie o chmurze dla danych medycznych

Dane medyczne to dane szczególnej kategorii w rozumieniu art. 9 RODO. Wymagają mocniejszej podstawy prawnej i większej ostrożności. Przed wdrożeniem chmurowego AI sprawdź konkretnie:

• Czy dostawca podpisze umowę powierzenia przetwarzania danych osobowych? Bez tego ani kroku.
• Czy dostawca lub jego podwykonawcy przetwarzają dane poza EOG? Jeśli tak, potrzebujesz standardowych klauzul umownych lub innego mechanizmu transferu. Adekwatność USA po Schrems II to temat na osobną rozmowę z IOD.
• Czy twój Inspektor Ochrony Danych uczestniczył w ocenie? Szpitale publiczne mają obowiązek jego wyznaczenia. W kontekście AI nie może to być formalna konsultacja na etapie "już działamy".
• Czy dostawca używa twoich danych do trenowania modeli? To jedno z pierwszych pytań, które zadaje IOD. Odpowiedź musi być jednoznaczna i zawarta w treści umowy, nie tylko w regulaminie na stronie.

Przy modelu on-premise te pytania nadal są ważne, jeśli aplikacja łączy się z serwerami dostawcy choćby do aktualizacji lub telemetrii. Zapytaj, co konkretnie jest wysyłane na zewnątrz i kiedy.

Jak model wdrożenia wpływa na wybór dostawcy

Nie każdy dostawca AI oferuje wdrożenie lokalne. Duże platformy SaaS często działają wyłącznie w chmurze i nie mają opcji instalacji na serwerze klienta. Mniejsze firmy budujące AI specjalnie dla polskiej ochrony zdrowia częściej oferują on-premise lub hybrid, bo znają wymagania rynku.

Przy rozmowach z dostawcą pytaj wprost:

• Czy macie wdrożenie on-premise lub private cloud?
• Jakie są minimalne wymagania sprzętowe dla tego przypadku użycia?
• Jak wyglądają aktualizacje modelu w wersji lokalnej i kto je przeprowadza?
• Czy aplikacja wymaga stałego połączenia z waszymi serwerami, nawet jeśli dane są u nas?
• Co dzieje się z naszymi danymi po rozwiązaniu umowy?

To ostatnie pytanie jest ważniejsze niż wygląda. Jeśli model był dotrenowywany na twoich danych i działa w infrastrukturze dostawcy, po zakończeniu współpracy możesz mieć poważny problem z migracją i z wiedzą, gdzie twoje dane skończyły.

Od czego zaczynamy

Zanim zdecydujesz o modelu wdrożenia, zrób dwie rzeczy. Pierwsza: sprawdź aktualny stan IT w placówce, czy masz własną serwerownię, jakie są możliwości sprzętowe, kto zarządza infrastrukturą na co dzień. Druga: określ, jakie dane AI faktycznie będzie widział. Jeśli to tylko szablony pism i FAQ bez danych pacjentów, wymagania są zupełnie inne niż przy analizie dokumentacji klinicznej lub opisach obrazowania.

Jeśli nie wiesz, jak to zmapować, możemy pomóc. Bezpłatny audyt pozwala ocenić, który model wdrożenia pasuje do twojej placówki i jakie opcje są realne przy twoim obecnym środowisku IT. Możesz też sprawdzić, jak inne placówki podjęły tę decyzję: realne wdrożenia pokazują konkretne konfiguracje z polskich szpitali i przychodni, łącznie z tym, co ostatecznie trafiło lokalnie, a co zostało w chmurze.