---
title: "Zakup AI do placówki: ENISA obejmuje cały cykl zamówienia
"
description: Nowe wytyczne ENISA pokazują, jak utrzymać wymagania, dowody i testy cyberbezpieczeństwa od zapytania po bezpieczne wyjście z systemu AI.
image: "https://ai4med.pl/img/enisa-cykl-zakupu-ai.jpg"
date: 2026-07-30
author: Jacek Wyderka
category: Dane i bezpieczeństwo
tags: ENISA, cyberbezpieczeństwo, zakup systemu AI, dostawcy, placówka medyczna
url: "https://ai4med.pl/dane-i-bezpieczenstwo/enisa-cykl-zakupu-ai"
inLanguage: pl
---

# Zakup AI do placówki: ENISA obejmuje cały cykl zamówienia


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](/dane-i-bezpieczenstwo/ankieta-csirt-ksc).

## 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:

1. **cel i granice funkcji AI** — co model robi, a czego nie wolno mu robić;
2. **dostawca, sposób wdrożenia i podwykonawcy** — kto faktycznie dotyka usługi;
3. **kategorie i lokalizacja danych** — jakie dane trafiają do systemu i gdzie są przetwarzane;
4. **retencja oraz użycie wtórne** — jak długo pozostają wejścia, wyniki i dane pochodne oraz czy służą do trenowania;
5. **nadzór człowieka** — kto zatwierdza wynik i kto może zatrzymać funkcję;
6. **logi i eksport** — jakie zdarzenia są rejestrowane, jak długo i czy placówka może je pobrać;
7. **incydenty, podatności i poprawki** — kto zgłasza, w jakim terminie i jak powstaje dowód naprawy;
8. **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](https://www.enisa.europa.eu/publications/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](https://www.enisa.europa.eu/news/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](https://cez.gov.pl/pl/page/weryfikacja-zgodnosci-z-wymogami-cyberbezpieczenstwa) — 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](https://www.pexels.com/photo/hanging-controllers-beside-the-screen-11288664/)