Jak wybrać dostawcę AI dla szpitala: pytania przed demo i kryteria pilotażu

Większość rozmów o AI w szpitalu zaczyna się od prezentacji dostawcy. To zła kolejność. Jeśli zastanawiacie się, jak wybrać dostawcę AI dla szpitala, zacznijcie od nazwania jednego problemu, który system ma rozwiązać, i od kilku niewygodnych pytań wysłanych na piśmie: gdzie trafią dane pacjentów, jak system połączy się z waszym HIS i co się stanie, gdy zechcecie zrezygnować. Potem demo na przykładowych danych, pilotaż na waszych z kryteriami spisanymi przed startem, a na końcu decyzja.

Piszemy jako dostawca, który w takich rozmowach siedzi po drugiej stronie stołu, więc nasze odpowiedzi są na końcu. Reszta przyda się w rozmowie z każdą firmą.

Proces wyboru dostawcy w jednym schemacie

Proces wyboru dostawcy AI

1. 1

   Potrzeba

   proces i liczby
2. 2

   Pytania

   na piśmie
3. 3

   Demo

   dane przykładowe
4. 4

   Pilotaż

   wasze dane
5. 5

   Decyzja

   umowa albo koniec

Na schemacie to oczywiste, w praktyce etapy często zamieniają się miejscami: demo odbywa się, zanim ktokolwiek zapytał o dane, a kryteria pilotażu powstają, kiedy pilotaż już trwa. Kończy się to dodatkową rundą uzgodnień z IOD albo sporem o to, czy pilotaż się udał.

Przygotowanie przed pierwszą rozmową

Zanim zaprosicie dostawcę na spotkanie, nazwijcie jeden proces, który ma się zmienić. „Wdrożenie AI w szpitalu” procesem nie jest. Dyktowanie opisów badań, przenoszenie leków i rozpoznań z kart informacyjnych do rejestru czy anonimizacja dokumentacji do badań już tak.

Potem zmierzcie, jak ten proces działa dziś: ile trwa, ile dokumentów przechodzi przez niego w miesiącu, ile błędów wyłapuje kontrola. Bez tego każdy wynik pilotażu da się opowiedzieć jako sukces.

Przy stole powinni siedzieć właściciel procesu klinicznego, ktoś z IT, inspektor ochrony danych i dział zamówień. Najczęściej brakuje IOD. Kiedy dowiaduje się o projekcie dopiero po podpisaniu umowy pilotażowej, projekt zwykle cofa się o kilka tygodni.

Szpital publiczny kupuje według Prawa zamówień publicznych. Przed postępowaniem może przeprowadzić wstępne konsultacje rynkowe (art. 84 Pzp), o ile nie zakłócą one konkurencji. Rozmowy z kilkoma dostawcami dają wtedy materiał do opisu przedmiotu zamówienia. Źródła finansowania zebraliśmy na stronie o KPO i kolejnych naborach.

Pytania do dostawcy AI przed demo

Pytania wyślijcie na piśmie i na piśmie poproście o odpowiedzi. Ustna deklaracja ze spotkania nie trafi do umowy. Dostawca, który na pytanie o lokalizację danych proponuje „omówić to na spotkaniu”, najpewniej nie ma gotowej odpowiedzi.

Dane i RODO

Zacznijcie od pytania najprostszego: gdzie fizycznie będą przetwarzane dane pacjentów? Na serwerach szpitala, w chmurze dostawcy czy u podwykonawcy, i w jakim kraju? Od tego zależy zakres umowy powierzenia. Poproście o jej projekt i o listę dalszych podmiotów przetwarzających, bo hosting, wsparcie techniczne i dostawca modelu bazowego to często osobne firmy.

Osobno zapytajcie, czy dostawca będzie trenował modele na danych szpitala, także tych z pilotażu, i czy da się to wyłączyć. To pytanie wiele mówi. Dobra odpowiedź jest krótka i trafia do umowy, zła siedzi drobnym drukiem w ogólnych warunkach. Ustalcie też, kiedy dostawca usunie dane po zakończeniu współpracy i jak to potwierdzi.

Bezpieczeństwo i KSC

IT zapyta, jakiego dostępu do infrastruktury szpitala potrzebuje dostawca i jak jest on uwierzytelniany i logowany. Stały dostęp zdalny „na wszelki wypadek” to coś, czego w szpitalu nie chcecie. Zapytajcie też, co się dzieje, gdy padnie łącze z internetem, bo od tego zależy, czy lekarze będą mogli wtedy pracować z systemem.

Łatwo przeoczyć dwa pytania. Kto instaluje aktualizacje i czy szpital może je wstrzymać, żeby najpierw sprawdzić je u siebie? I w jakim czasie dostawca powiadomi szpital o incydencie po swojej stronie? Jeśli szpital podlega ustawie o KSC, obie odpowiedzi trafią do jego polityki bezpieczeństwa łańcucha dostaw.

Integracja z HIS

Najważniejsze jest rozróżnienie, które dostawcy chętnie zacierają: z którymi systemami HIS integracja już działa u klientów, a z którymi „da się zintegrować”. W praktyce „da się” znaczy zwykle, że jeszcze nikt tego nie zrobił. Zapytajcie o mechanizm, czyli API producenta HIS, HL7 lub FHIR albo eksport plików. Dowiedzcie się też, gdzie trafia wynik działania AI i czy lekarz zatwierdza go, zanim znajdzie się w dokumentacji. Więcej w tekście jak połączyć AI z systemem szpitalnym.

Jakość modelu na polskich danych

Każdy dostawca ma na slajdzie jakiś procent skuteczności, więc zapytajcie, na czym go policzył. Poproście o nazwę metryki i opis zbioru, bo test na polskich nagraniach czy tekstach medycznych to coś innego niż test na tłumaczeniach. Rozpoznawanie mowy mierzy się zwykle wskaźnikiem WER, czyli odsetkiem błędnie rozpoznanych słów, a ekstrakcję danych precyzją, czułością i F1, osobno dla każdego typu informacji. Liczba bez wyniku innego modelu na tym samym zbiorze niewiele mówi.

Zapytajcie też, czy dostawca uprzedza o nowej wersji modelu, zanim ją uruchomi. Po cichej aktualizacji model może działać inaczej.

Regulacje: AI Act i MDR

Poproście dostawcę, żeby na piśmie sklasyfikował swój system według AI Act i odpowiedział, czy jest on wyrobem medycznym według MDR. Uzasadnienie powinno wynikać z przeznaczenia systemu. Jeśli system jest wyrobem medycznym, poproście o deklarację zgodności i zakres przeznaczenia oraz sprawdźcie oznakowanie CE. Jeśli nie jest, z opisu przeznaczenia powinno wynikać, że system nie służy do podejmowania decyzji diagnostycznych ani terapeutycznych. Zapytajcie też o instrukcje, których szpital jako podmiot stosujący potrzebuje do nadzoru nad systemem.

Koszty i skala

Model rozliczenia bywa różny: licencja, abonament, opłata za dokument albo za minutę nagrania. Ważniejsze jest to, czego cena nie obejmuje. Policzcie sprzęt, np. serwer z GPU przy wdrożeniu lokalnym, oraz integrację, szkolenia i utrzymanie. Poproście o dwie wyceny, dla oddziału z pilotażu i dla całego szpitala.

Wsparcie i wyjście z umowy

O wyjściu z umowy najlepiej rozmawiać na początku, kiedy obu stronom jeszcze zależy. Zapytajcie, w jakim formacie dostaniecie swoje dane i wyniki, jaki jest okres wypowiedzenia i czy pilotaż zobowiązuje do zakupu. Ustalcie też czasy reakcji i naprawy oraz to, kto u dostawcy odpowiada za wdrożenie.

Co jest wymagane przepisami, a co jest dobrą praktyką

Część tych pytań wynika wprost z przepisów i odpowiedzi na nie muszą trafić do umowy albo dokumentacji. Reszta to dobra praktyka, o którą się negocjuje. Rozdzielajcie jedno od drugiego, bo dostawcom zdarza się przedstawiać własny standard jako wymóg prawny.

Wymagane przepisami

RODO wymaga umowy powierzenia, jeśli dostawca przetwarza dane pacjentów w imieniu szpitala (art. 28). Szpital jako administrator odpowiada za odpowiednie środki bezpieczeństwa przetwarzania (art. 32), a gdy przetwarzanie może powodować wysokie ryzyko, musi przeprowadzić ocenę skutków dla ochrony danych, czyli DPIA (art. 35). Dane o zdrowiu przetwarzane na dużą skalę nową technologią to zwykle właśnie taki przypadek.

Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa obowiązuje od 3 kwietnia 2026 r. Podmioty kluczowe i ważne, które spełniały kryteria tego dnia, mają czas do 3 kwietnia 2027 r. na wdrożenie nowych obowiązków, w tym systemu zarządzania bezpieczeństwem informacji z polityką bezpieczeństwa łańcucha dostaw. Ustawa (ISAP) wdraża dyrektywę NIS2, której art. 21 ust. 2 lit. d obejmuje relacje z bezpośrednimi dostawcami. Jeśli wasz szpital jest podmiotem kluczowym lub ważnym, dostawca AI wchodzi w zakres tej polityki.

AI Act, czyli rozporządzenie 2024/1689, wchodzi w życie etapami. Od 2 lutego 2025 r. podmioty stosujące AI muszą dbać o kompetencje swojego personelu w zakresie AI (art. 4). Od 2 sierpnia 2026 r. obowiązuje art. 50 o przejrzystości, który wymaga na przykład, żeby osoba rozmawiająca z systemem AI wiedziała, że to system AI. Przy systemach wysokiego ryzyka art. 26 każe podmiotowi stosującemu używać takiego systemu zgodnie z instrukcją, zapewnić nadzór człowieka i przechowywać rejestry zdarzeń. Po zmianach wprowadzonych rozporządzeniem 2026/1744 te obowiązki stosuje się od 2 grudnia 2027 r. dla systemów z załącznika III i od 2 sierpnia 2028 r. dla systemów objętych prawodawstwem z załącznika I, w tym wyrobów medycznych. Umowa podpisana dziś będzie wtedy nadal obowiązywać.

MDR dotyczy oprogramowania, które według producenta służy między innymi do diagnozy, monitorowania lub leczenia. Taki wyrób medyczny przechodzi ocenę zgodności i ma oznakowanie CE (rozporządzenie 2017/745, art. 20), a szpital używa go zgodnie z przeznaczeniem określonym przez producenta.

Dobra praktyka, której przepisy nie wymagają

Żaden przepis nie każe pokazywać demo na danych podobnych do waszych ani ustalać progów sukcesu przed pilotażem. Nie wymaga też wyników na polskich danych, zakazu trenowania modeli na danych szpitala, SLA, uprzedzania o nowych wersjach modelu, eksportu w otwartym formacie ani depozytu kodu. To wszystko szpital musi wynegocjować sam, i naszym zdaniem warto, bo właśnie te zapisy rozstrzygają, czy po roku będziecie zadowoleni z wyboru.

Pytania techniczne możecie porównać z wytycznymi ENISA o cyberbezpieczeństwie w zakupach szpitali z lipca 2026 r. Zespołowi przyda się też poradnik CSIRT CeZ „Podstawy bezpieczeństwa i ochrony danych w sektorze ochrony zdrowia”. Sam AI Act opisujemy szerzej w tekście AI Act: co zmieni dla szpitali.

Demo na danych przykładowych

Demo odbywa się na wczesnym etapie, więc nie obciążajcie go przekazywaniem danych pacjentów. To oznaczałoby umowę powierzenia, decyzję IOD i anonimizację, zanim w ogóle wiecie, czy dostawca wam pasuje. Wystarczą dane przykładowe dostawcy albo dane publiczne lub syntetyczne, byle podobne do szpitalnych, np. typowe polskie dokumenty czy nagrania z oddziału o podobnym profilu. Poproście, żeby znalazły się wśród nich trudne przypadki, bo na łatwych każdy system wypada dobrze.

Jeśli chcecie, przynieście własne przykłady, które nie zawierają danych pacjentów albo zostały zanonimizowane. To dobry sprawdzian, ale nie warunek. Na prawdziwych danych szpitala system sprawdzicie dopiero w pilotażu. O bezpiecznym przekazywaniu danych pisaliśmy w tekście jak bezpiecznie udostępniać dane medyczne.

Jak zaplanować pilotaż AI w szpitalu

Pilotaż nie jest darmowym okresem próbnym, tylko eksperymentem z konkretną hipotezą. Jego plan mieści się na jednej stronie i obie strony podpisują go przed startem.

Dopiero w pilotażu system pracuje na prawdziwych danych szpitala. Dlatego przed startem szpital podpisuje z dostawcą umowę powierzenia, a IOD bierze udział w planowaniu od początku. Pilotaż on-premise upraszcza sprawę, bo dane nie opuszczają szpitala.

Cel zapiszcie jednym zdaniem i niech dotyczy procesu, a nie technologii. „Opis badania powstaje szybciej, a liczba poprawek się nie zmienia” to dobry cel. „Wdrożyć rozpoznawanie mowy” celem nie jest, to środek.

Zakres powinien być wąski: jeden oddział albo jedna pracownia, konkretni użytkownicy, określona liczba tygodni. Pierwsze dni zawsze wypadają gorzej niż kolejne, więc nie oceniajcie systemu po pierwszym tygodniu.

Mierników wystarczą dwa albo trzy, z progami ustalonymi przed startem. Dobrze sprawdza się odsetek błędów wymagających poprawki i czas wykonania zadania w porównaniu z linią bazową. Do tego odsetek przypadków, w których użytkownik wrócił do starego sposobu pracy, bo ten miernik najszybciej pokazuje, czy system się przyjmie. Dodajcie też jeden miernik bezpieczeństwa: liczbę błędów AI, które trafiły do dokumentacji niezauważone. Tu jedynym akceptowalnym wynikiem jest zero.

Przed startem odłóżcie zestaw referencyjny, do którego wasi specjaliści przygotują poprawne odpowiedzi. Na nim porównacie model z obecnym procesem w powtarzalny sposób.

Wyniki powinien ocenić ktoś, kto nie pracuje u dostawcy i nie był inicjatorem projektu, najlepiej dwie osoby niezależnie od siebie. Opinie użytkowników zbierajcie osobno. System może mieć dobre metryki, a lekarze i tak z niego nie korzystają. To też jest wynik.

Zostają pieniądze. Szpitalowi publicznemu często łatwiej sfinansować gotowe rozwiązanie niż płatny pilotaż, dlatego zakres, czas i kryteria pilotażu ustalcie z dostawcą z góry. Opiszcie w tym samym dokumencie ścieżkę od udanego pilotażu do zamówienia, los danych po pilotażu i to, że pilotaż nie zobowiązuje do zakupu.

Dlaczego tyle projektów zatrzymuje się po pilotażu, pisaliśmy w tekście dlaczego większość projektów AI się nie udaje.

Czerwone flagi

Przy tych sygnałach my sami przerwalibyśmy rozmowę albo przynajmniej mocno zwolnili:

• Na pytanie o lokalizację danych albo umowę powierzenia nie ma odpowiedzi na piśmie.
• Procent skuteczności pojawia się bez informacji, na jakich danych i jaką metryką go policzono.
• Dostawca nie zgadza się na test na danych szpitala w pilotażu, nawet po podpisaniu umowy powierzenia.
• Integracja z waszym HIS jest „możliwa”, ale nigdzie nie działa i nikt nie wie, kto ma ją zrobić.
• Nie wiadomo, czy system jest wyrobem medycznym ani jak dostawca ocenia go według AI Act.
• Ogólne warunki domyślnie pozwalają trenować modele na waszych danych.
• Dane zostają w zamkniętym formacie, a pilotaż zobowiązuje do zakupu.
• Kryteria sukcesu mają powstać dopiero po pilotażu.

Checklista due diligence dostawcy AI

Tabelę możecie skopiować do arkusza i wysłać dostawcy przed demo. Przedostatnia kolumna podpowiada, jakiego dowodu oczekiwać, żeby odpowiedź nie skończyła się na deklaracji.

Jak odpowiada na te pytania Medalion

Poniżej nasze odpowiedzi na te same pytania. Piszemy tylko o tym, co możemy potwierdzić.

Nasze modele mogą działać w pełni lokalnie, w infrastrukturze szpitala, czyli on-premise. Dla VoxMedic jest też opcja hostowanego REST API. Wybór wariantu należy do szpitala i od niego zależy zakres umowy powierzenia. Dziś integrujemy się z AMMS i Optimed. Inne systemy HIS omawiamy przy konkretnym wdrożeniu.

VoxMedic, nasz model rozpoznawania polskiej mowy medycznej, ma WER 7,64% na zbiorze polskich nagrań medycznych admed. Whisper large-v3-turbo ma na tym samym zbiorze 17,07%. MedalioNER wyciąga dane z dokumentacji medycznej, ale nie nadaje kodów ICD-10. Kody ICD-10 potrafi nadawać MedDecider. AnonimiNER anonimizuje dokumentację, na przykład zanim trafi ona do badań albo zanim szpital pokaże własne przykłady na demo.

Nasze modele nie są narzędziami diagnostycznymi. Pomagają w pracy z dokumentacją i danymi. Według naszej oceny nie są systemami wysokiego ryzyka w rozumieniu AI Act.

Pilotaż prowadzimy on-premise, w infrastrukturze szpitala i na jego danych. Koszt ustalamy indywidualnie, razem z zakresem, czasem i kryteriami. Jeśli chcecie przejść tę listę pytań na konkretnym procesie, napiszcie do nas.

Najczęściej zadawane pytania

Ile powinien trwać pilotaż AI w szpitalu?

Tyle, żeby użytkownicy nauczyli się obsługi, a wy zebrali dość przypadków do porównania z linią bazową. Ustalcie czas przed startem i nie przedłużajcie pilotażu tylko dlatego, że wyniki rozczarowują.

Czy pilotaż z danymi pacjentów wymaga umowy powierzenia?

Tak, jeśli dostawca w trakcie pilotażu przetwarza dane osobowe pacjentów w imieniu szpitala. Wtedy szpital podpisuje umowę powierzenia zgodną z art. 28 RODO. Gdy system działa wyłącznie lokalnie, a dostawca nie ma dostępu do danych, umowa może być węższa. Decyzję podejmuje IOD szpitala.

Czy szpital publiczny może zrobić pilotaż bez przetargu?

To zależy od wartości i formy pilotażu, więc tryb ustalcie z działem zamówień przed startem. Przed postępowaniem szpital może też przeprowadzić wstępne konsultacje rynkowe (art. 84 Pzp), o ile nie zakłócą one konkurencji.

Jakie pytania zadać dostawcy AI przed demo?

Przede wszystkim o to, gdzie trafią dane pacjentów i czy dostawca podpisze umowę powierzenia. Dalej o dostęp do infrastruktury i incydenty, integracje z waszym HIS, wyniki na polskich danych, klasyfikację według AI Act i MDR, koszt i los danych po zakończeniu umowy. Odpowiedzi zbierajcie na piśmie.

Czy AI Act już obowiązuje szpitale?

Częściowo. Obowiązek dbania o kompetencje w zakresie AI stosuje się od 2 lutego 2025 r., a obowiązki przejrzystości z art. 50 od 2 sierpnia 2026 r. Wymogi dla systemów wysokiego ryzyka po zmianach z rozporządzenia 2026/1744 zaczną obowiązywać 2 grudnia 2027 r. dla systemów z załącznika III i 2 sierpnia 2028 r. dla systemów z załącznika I, w tym wyrobów medycznych.

Na jakich danych dostawca powinien pokazać demo?

Na danych przykładowych, publicznych albo syntetycznych, ale podobnych do szpitalnych, np. typowych polskich dokumentach czy nagraniach z oddziału o podobnym profilu. Szpital może przynieść własne przykłady bez danych pacjentów albo zanonimizowane, ale nie musi. Test na prawdziwych danych szpitala to już pilotaż, po podpisaniu umowy powierzenia i z udziałem IOD.

Czym jest due diligence dostawcy AI?

To sprawdzenie dostawcy przed zakupem: ochrony danych, bezpieczeństwa, integracji, jakości modelu, statusu regulacyjnego, kosztów i warunków wyjścia z umowy. Wynikiem są pisemne odpowiedzi i dokumenty, które szpital przenosi do umowy.

Źródła

• Rozporządzenie (UE) 2016/679 (RODO), art. 28, 32 i 35: eur-lex.europa.eu/eli/reg/2016/679/oj
• Rozporządzenie (UE) 2024/1689 (AI Act): eur-lex.europa.eu/eli/reg/2024/1689/oj
• Rozporządzenie (UE) 2026/1744 (Digital Omnibus on AI), Dz.U. UE L z 24.7.2026, zmiana art. 113: eur-lex.europa.eu/eli/reg/2026/1744/oj
• Rozporządzenie (UE) 2017/745 (MDR): eur-lex.europa.eu/eli/reg/2017/745/oj
• Dyrektywa (UE) 2022/2555 (NIS2), art. 21: eur-lex.europa.eu/eli/dir/2022/2555/oj
• Ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa: isap.sejm.gov.pl
• Ministerstwo Cyfryzacji, „Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa zaczyna obowiązywać”: gov.pl
• NASK, opracowanie o zmianach w nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa po pracach w parlamencie, luty 2026: cyberpolicy.nask.pl
• Ustawa z 11 września 2019 r. Prawo zamówień publicznych, art. 84: isap.sejm.gov.pl
• ENISA, „Procurement guidelines for the cybersecurity of hospitals and healthcare providers”, 22.07.2026: enisa.europa.eu
• CSIRT CeZ, „Podstawy bezpieczeństwa i ochrony danych w sektorze ochrony zdrowia”: cez.gov.pl