W małej klinice pytania o bezpieczeństwo często żyją krótko: trafiają do ankiety dostawcy, wraca seria odpowiedzi „tak”, a przy negocjowaniu umowy nikt już do nich nie zagląda. Problem nie polega na braku kolejnej checklisty, tylko na tym, że wymaganie nie ma dalszego ciągu: dowodu, klauzuli, testu odbiorowego i właściciela po uruchomieniu.
22 lipca 2026 r. ENISA (Agencja Unii Europejskiej ds. Cyberbezpieczeństwa) opublikowała nową iterację wytycznych zakupowych dla szpitali i świadczeniodawców. Dokument obejmuje cały cykl zamówienia, w tym produkty i usługi z AI. Dla polskiej placówki najważniejsza zmiana perspektywy brzmi: deklaracja dostawcy jest początkiem weryfikacji, nie jej końcem.
Dotyczy to również funkcji, których sprzedawca nie eksponuje jako „AI”. Model może działać w produkcie, przez zewnętrzny interfejs albo u podwykonawcy używającego go do wsparcia, dokumentacji czy analizy. AI może uporządkować publiczne dokumenty i wskazać puste pola, lecz człowiek po stronie placówki zatwierdza wymaganie, dowód, wynik testu i ryzyko. Stan materiału: 29 lipca 2026 r.
Co dokładnie zmieniło się 22 lipca
ENISA porządkuje zakup w trzech fazach: plan, source (wybór źródła i dostawcy) oraz manage (wdrożenie, utrzymanie i zakończenie). Wytyczne wymagają, aby w dokumentacji zakupowej określić m.in. cel i zakres funkcji AI, dostawcę modelu i sposób wdrożenia, kategorie danych, retencję, podwykonawców, nadzór człowieka, logowanie oraz zasady informowania o istotnych zmianach.
Tego samego dnia ENISA podała, że nowa iteracja jest jednym z pierwszych rezultatów unijnego planu działań dla cyberbezpieczeństwa ochrony zdrowia. Do raportu dołączono checklistę, która wiąże środki bezpieczeństwa z rodzajem zakupu i konkretnymi zagrożeniami. Nie jest to nowa ustawa ani automatyczny obowiązek każdej małej kliniki. Sam raport zastrzega, że nie zastępuje regulacji krajowych.
W Polsce nowelizacja ustawy o KSC weszła w życie 3 kwietnia 2026 r., a Centrum e‑Zdrowia udostępnia narzędzie do weryfikacji statusu i gotowości. Materiały CeZ mają charakter informacyjny, dlatego manager powinien najpierw ustalić, czy i w jakim zakresie przepisy dotyczą jego podmiotu. Pomocny kontekst daje także test gotowości KSC w placówce.
Karta decyzji: jeden wymóg, sześć punktów kontroli
Poniższy rejestr nie kopiuje 69 stron raportu. Przekłada jego trzy fazy na sześć momentów, w których mała placówka może zgubić wymaganie albo zamienić je w sprawdzalną decyzję.
| Etap | Wymóg i dowód | Test lub decyzja | Właściciel |
|---|---|---|---|
| Cel zakupu | Opis procesu, funkcji AI, danych i skutku niedostępności | Czy AI jest potrzebna i czy istnieje bezpieczny tryb ręczny? | manager procesu |
| Zapytanie ofertowe | Osiem krytycznych wymagań zapisanych tak, by dało się je potwierdzić | Czy każde wymaganie ma oczekiwany dokument albo demonstrację? | manager z IT/IOD |
| Ocena oferty | Certyfikat, raport audytu, opis architektury, retencji, logów i podwykonawców | Czy zakres dowodu obejmuje kupowaną usługę i aktualną wersję? | osoba techniczna + IOD |
| Umowa | Klauzule o incydentach, podatnościach, poprawkach, zmianach AI i zakończeniu usługi | Czy terminy, odpowiedzialność i sposób eskalacji są mierzalne? | decydent umowy |
| Odbiór | Konfiguracja dostępu, logowanie, eksport, kopia i tryb awaryjny | Czy test przeszedł na danych syntetycznych, a wyjątki zapisano? | właściciel odbioru |
| Eksploatacja i wyjście | Rejestr zmian, dowody poprawek, zwrot i usunięcie danych, odebranie dostępów | Czy placówka potrafi odtworzyć, wyeksportować i bezpiecznie usunąć dane? | właściciel usługi |
Taki rejestr moge pokazać na jednym spotkaniu, zamiast przerzucać kilka niespójnych plików. Jego zaletą nie jest kompletność. Zaletą jest ślad: jeżeli wymaganie dotyczące logów pojawiło się w zapytaniu, przy odbiorze musi istnieć test eksportu, a w eksploatacji ktoś sprawdza, czy logi nadal powstają i mają uzgodnioną retencję.
Osiem wymagań wystarczy na pierwszy przegląd
Pierwsza wersja nie musi obejmować wszystkich miar ENISA. Wybierz osiem pól, które odpowiadają kupowanej usłudze AI:
- cel i granice funkcji AI — co model robi, a czego nie wolno mu robić;
- dostawca, sposób wdrożenia i podwykonawcy — kto faktycznie dotyka usługi;
- kategorie i lokalizacja danych — jakie dane trafiają do systemu i gdzie są przetwarzane;
- retencja oraz użycie wtórne — jak długo pozostają wejścia, wyniki i dane pochodne oraz czy służą do trenowania;
- nadzór człowieka — kto zatwierdza wynik i kto może zatrzymać funkcję;
- logi i eksport — jakie zdarzenia są rejestrowane, jak długo i czy placówka może je pobrać;
- incydenty, podatności i poprawki — kto zgłasza, w jakim terminie i jak powstaje dowód naprawy;
- wyjście z usługi — zwrot i usunięcie danych, odebranie kont, migracja oraz potwierdzenie zakończenia.
W małej placówce, nie trzeba tworzyć komitetu jak w dużym szpitalu. Potrzebne są jednak nazwane role: manager procesu, osoba techniczna lub dostawca IT, IOD przy danych osobowych oraz lekarz albo manager medyczny, jeżeli funkcja dotyka procesu klinicznego. Proporcjonalność oznacza krótszy rejestr, a nie rezygnację z dowodu.
Kiedy przerwać negocjacje
Idź dalej, gdy każde krytyczne wymaganie ma właściciela, oczekiwany dowód i zaplanowany test. Zatrzymaj zakup, jeśli pozostaje wyłącznie odpowiedź „spełniamy”, ale brakuje dokumentu, demonstracji albo testu. Kolejne sygnały to odmowa ujawnienia dostawcy modelu, podwykonawców, retencji lub mechanizmu powiadamiania o zmianach oraz umowa bez wykonalnego wyjścia.
Po uruchomieniu mierz tylko to, co pomaga podjąć decyzję. Dobry początek to odsetek krytycznych wymagań mających jednocześnie dowód i test, czas odebrania dostępu dostawcy oraz wynik trzech prób: odtworzenia, eksportu i usunięcia. Model AI może zaznaczyć brakujące pole w rejestrze, ale nie powinien sam uznać dowodu za wystarczający ani zaakceptować ryzyka.
Pierwszy ruch jest prosty: weź jeden aktualny kwestionariusz dostawcy i przepisz osiem najważniejszych odpowiedzi do czterech kolumn: wymaganie, dowód, test, właściciel. Jeżeli nie da się wskazać testu lub osoby odpowiedzialnej, wymaganie nie przeszło jeszcze z ankiety do zakupu.
Źródła
- ENISA — Procurement guidelines for the cybersecurity of hospitals and healthcare providers — raport opublikowany 22 lipca 2026 r.; definiuje fazy plan–source–manage, wymagania dla AI, logów, dostawców i bezpiecznego wyjścia. Sprawdzono: 2026-07-29.
- ENISA — First steps forward for the implementation of the Health Action Plan — komunikat z 22 lipca 2026 r.; potwierdza nową iterację wytycznych i checklistę powiązaną z zagrożeniami oraz typami zamówień. Sprawdzono: 2026-07-29.
- Centrum e‑Zdrowia — Weryfikacja zgodności z wymogami cyberbezpieczeństwa — polskie źródło urzędowe porządkujące status, terminy i samoocenę KSC, wraz z zastrzeżeniem informacyjnego charakteru materiału. Sprawdzono: 2026-07-29.
- Okładka: Jo McNamara na Pexels
