Co powinna zawierać umowa z dostawcą AI dla szpitala lub przychodni?

Umowa z dostawcą AI musi regulować przynajmniej pięć obszarów: zasady przetwarzania danych pacjentów, podział odpowiedzialności za błędy systemu, warunki integracji z HIS i EDM, parametry SLA wraz z zasadami aktualizacji modelu oraz warunki wyjścia ze współpracy. Bez tych zapisów narażasz placówkę na ryzyko prawne i operacyjne, które ujawni się dopiero przy pierwszym incydencie albo gdy zdecydujesz się zmienić dostawcę. Traktowanie tego kontraktu jak zwykłej umowy na oprogramowanie biurowe to jeden z częstszych błędów przy pierwszym wdrożeniu AI w placówce medycznej.

Dlaczego umowa AI to nie standardowy kontrakt IT

W zwykłej umowie na system informatyczny opisujesz funkcje, terminy, ceny i wsparcie techniczne. Przy AI dochodzą co najmniej trzy problemy, których przy standardowym SaaS nie ma.

Po pierwsze, model AI może zachowywać się inaczej po aktualizacji niż przed nią. Wersja modelu z marca może dawać inne wyniki niż wersja z września, nawet jeśli interfejs użytkownika wygląda identycznie. Jeśli umowa nic o tym nie mówi, dowiesz się o zmianie wtedy, gdy personel zacznie zgłaszać, że "coś jest nie tak z wynikami".

Po drugie, jeśli AI przetwarza dane pacjentów, wchodzisz w reżim RODO, ustawy o prawach pacjenta i przepisów o dokumentacji medycznej. W razie kontroli UODO lub incydentu bezpieczeństwa brak odpowiednich zapisów to konkretna odpowiedzialność administracyjna.

Po trzecie, AI Act nakłada obowiązki na Ciebie jako wdrażającego (deployer), nie tylko na producenta systemu. Masz obowiązek zapewnić, że system jest używany zgodnie z instrukcją dostawcy, monitorować jego działanie i reagować na odchylenia. Umowa powinna to odzwierciedlać: kto co dostarcza i w jakim terminie, żebyś mógł te obowiązki faktycznie wypełnić.

Co musi zawierać umowa o przetwarzaniu danych pacjentów

Jeśli AI ma dostęp do danych osobowych pacjentów, nawet pseudonimizowanych, obowiązkowo potrzebujesz umowy powierzenia przetwarzania danych zgodnej z art. 28 RODO. To osobny dokument, nie klauzula wpleciona gdzieś na stronie 12. ogólnych warunków.

Minimalna zawartość tej umowy:

• Cel i zakres przetwarzania: jakie kategorie danych (np. wyniki laboratoryjne, dane demograficzne, historia leczenia), do jakich operacji i przez jaki czas.
• Lokalizacja serwerów: czy dane są przetwarzane w EOG, a jeśli poza nim, na jakiej podstawie prawnej (np. standardowe klauzule umowne SCC).
• Podprzetwarzający: pełna lista firm, którym dostawca przekazuje dane (infrastruktura chmurowa, monitoring, zewnętrzne wsparcie), z obowiązkiem pisemnego informowania o każdej zmianie.
• Procedura przy naruszeniu bezpieczeństwa: czas reakcji dostawcy i sposób powiadomienia Cię jako administratora. Standardowo nie więcej niż 24-72 godziny od wykrycia incydentu.
• Usunięcie danych po zakończeniu umowy: termin i forma potwierdzenia. Protokół usunięcia danych to dokument, który możesz być zobowiązany okazać podczas kontroli.

Dodaj też zapis o tym, czy dostawca może używać Twoich danych do trenowania lub ulepszania modeli. Domyślna odpowiedź powinna brzmieć: nie, bez pisemnej zgody administratora. Część dostawców wpisuje taką zgodę w ogólnych warunkach korzystania z usługi. Warto to sprawdzić, zanim ktokolwiek cokolwiek podpisze.

Jak zapisać odpowiedzialność za błąd AI i integrację z systemami szpitala

Podział odpowiedzialności to najtrudniejszy fragment negocjacji. Dostawcy często proponują zapisy wyłączające ich odpowiedzialność za decyzje podjęte "na podstawie" systemu. Z punktu widzenia dyrekcji placówki taki zapis jest do przyjęcia, ale tylko wtedy, gdy AI pełni rolę wspomagającą, a ostateczna decyzja kliniczna zawsze należy do lekarza. Jeśli umowa opisuje system jako "autonomiczny" lub "podejmujący decyzje", pojawia się problem zgodności z AI Act dla systemów wysokiego ryzyka.

Zadbaj o zapisy, które:

• Jednoznacznie określają, że system jest narzędziem wspomagającym, a nie zastępującym ocenę kliniczną.
• Wskazują, kto odpowiada za utrzymanie modelu w stanie zgodnym z deklarowaną klasą działania (performance class) opisaną w dokumentacji technicznej dostawcy.
• Definiują procedurę obsługi "incydentu AI": kto i co robi, kiedy i na jakim formularzu zgłasza odchylenie od normy.
• Opisują, co się dzieje, gdy model zacznie systematycznie dawać wyniki poza deklarowaną dokładnością. Fachowo nazywa się to dryfem koncepcyjnym lub degradacją modelu po zmianie profilu populacji pacjentów.

Przy integracji z HIS lub EDM ogólny zapis "integracja zapewniona" to za mało. U jednego z naszych klientów okazało się po podpisaniu umowy, że dostawca AI zbudował system pod standard FHIR R4, a wewnętrzny HIS szpitala obsługiwał wyłącznie HL7 v2.x. Uzgodnienie mapowania pól kosztowało kilka dodatkowych miesięcy i pieniądze, których w budżecie projektu nie było. Zapytaj przed podpisaniem o konkretny protokół, wersję standardu, kto dostarcza mapowanie i czy dostawca udostępnia środowisko testowe przed uruchomieniem produkcyjnym.

SLA, aktualizacje modelu i prawo powrotu do poprzedniej wersji

SLA przy systemie AI w placówce medycznej to nie tylko "dostępność 99,9%". Liczy się też to, co dzieje się w czasie niedostępności i po każdej aktualizacji modelu.

Parametry warte negocjacji w SLA:

• Dostępność systemu: poziom i precyzyjna definicja, czy planowane okna serwisowe wliczają się do przestoju.
• Czas reakcji przy zgłoszeniu krytycznym: dla systemu działającego na SOR-ze inne normy niż dla narzędzia raportowego używanego raz w tygodniu.
• Procedura fallback: co robi personel, gdy AI nie działa. Dobra umowa opisuje to wprost, zamiast zostawiać to domyślności.
• Kary umowne: czy istnieją i od jakiego progu niedostępności się naliczają.

Model AI to nie statyczne oprogramowanie. Dostawca może go aktualizować, retrenować i zmieniać architekturę bez Twojej wiedzy, jeśli umowa tego nie zabrania. Postuluj:

• Pisemne powiadomienie z co najmniej 14-dniowym wyprzedzeniem przed każdą istotną zmianą modelu produkcyjnego.
• Dokumentację każdej wersji modelu, tzw. model card lub kartę techniczną wersji z opisem parametrów jakości.
• Prawo przetestowania nowej wersji w środowisku testowym przed wdrożeniem na produkcję.
• Prawo powrotu do poprzedniej wersji modelu przez ustalony czas (np. 30 dni), jeśli nowa wersja daje gorsze wyniki na Twoich danych operacyjnych.

To ostatnie jest rzadko negocjowane, a bywa bardzo przydatne. Nowa wersja modelu może być lepsza statystycznie na danych globalnych, ale gorsza na specyficznej populacji pacjentów Twojej placówki.

Jak wyjść z umowy i zabrać swoje dane

Zanim podpiszesz, zastanów się, co się dzieje, gdy za dwa lata chcesz zmienić dostawcę. Kluczowe pytanie brzmi: czy dane historyczne (wyniki AI, logi, modele dostosowane do Twoich danych) są eksportowalne i w jakim formacie?

Postuluj:

• Prawo do eksportu wszystkich danych wygenerowanych w systemie w otwartym formacie (CSV, JSON, FHIR) w ustalonym terminie od złożenia wniosku.
• Obowiązek dostawcy do asysty przy migracji przez określony czas po zakończeniu umowy, np. 30 dni.
• Brak klauzul wyłączności, które blokowałyby Cię przed wyborem innego narzędzia lub utrudniały równoległe testy alternatywnego systemu.
• Termin trwałego usunięcia Twoich danych z serwerów dostawcy i forma pisemnego protokołu potwierdzającego.

Jeśli dostawca przez kilka lat budował model dostosowany specjalnie do danych Twojej placówki, taki model ma realną wartość. Bez zapisu wskazującego właściciela tego modelu po zakończeniu współpracy możesz mieć problem z dochodzeniem swoich praw. Własność modelu to punkt, który warto ustalić przy stole negocjacyjnym, nie w sądzie.

Od czego zaczynamy przed podpisaniem

Zanim usiądziesz do negocjacji, zbierz trzy dokumenty: specyfikację techniczną systemu od dostawcy, listę systemów IT w placówce, z którymi AI ma się integrować, oraz wewnętrzną politykę bezpieczeństwa informacji. Na tej podstawie prawnik z doświadczeniem w ochronie danych medycznych i Twój dział IT ocenią, które zapisy w propozycji dostawcy wymagają korekty przed podpisaniem.

Robimy bezpłatny audyt gotowości placówki do wdrożenia AI, który obejmuje też przegląd typowych ryzyk kontraktowych. Możesz też sprawdzić, jak wyglądały realne wdrożenia u innych placówek, zanim zdecydujesz, co Ci odpowiada.