---
title: "Narzędzie AI w EUDAMED: 5 dowodów przed zakupem
"
description: "Sprawdź pięć dowodów w EUDAMED, zanim polska placówka kupi narzędzie AI: właściwy UDI, wersję, przeznaczenie, SS(C)P i nadzór po wdrożeniu.
"
image: "https://ai4med.pl/img/eudamed-ai-dowody.jpg"
date: 2026-07-12
author: Jacek Wyderka
category: Narzędzia i wdrożenia
tags: EUDAMED narzędzie AI, wyrób medyczny AI, SSCP, UDI oprogramowanie medyczne, wybór dostawcy AI
url: "https://ai4med.pl/narzedzia-i-wdrozenia/eudamed-ai-dowody"
inLanguage: pl
---

# Narzędzie AI w EUDAMED: 5 dowodów przed zakupem


## Czego dowiesz się z tego artykułu?

- Jak odróżnić rekord w EUDAMED od dowodu skuteczności konkretnego narzędzia AI.
- Które pięć dowodów połączyć, aby sprawdzić produkt, wersję, przeznaczenie i bezpieczeństwo po wdrożeniu.
- Gdzie AI może porządkować dokumenty, a gdzie decyzję musi zatwierdzić manager lub lekarz.
- Co zrobić, gdy w okresie przejściowym brakuje certyfikatu albo SS(C)P w publicznym rekordzie.

Przed zakupem narzędzia AI deklarowanego jako wyrób medyczny nie pytaj tylko: „czy jest w EUDAMED?”. Pytaj: **czy rekord dotyczy produktu pokazanego na demo** oraz **czy dokumenty obejmują wersję, którą placówka ma faktycznie dostać**. Jedna zgodna nazwa handlowa to za mało, by podpisać umowę.

Od 28 maja 2026 r. cztery pierwsze moduły EUDAMED są obowiązkowe, ale nadal działają przepisy przejściowe dla części wyrobów i certyfikatów. Dlatego **brak rekordu nie zawsze oznacza naruszenie**, a **obecność rekordu nie jest gwarancją skuteczności klinicznej**. Manager musi sprawdzić datę wprowadzenia produktu do obrotu, dokumenty przejściowe i powiązanie identyfikatorów.

Jeśli zespół używa AI do streszczania długich dokumentów, traktowałbym wynik wyłącznie jako **mapę do źródeł**, nie jako opinię o zgodności. **Człowiek weryfikuje każdy dowód w dokumencie pierwotnym**, dyrektor medyczny zatwierdza użycie kliniczne, a IOD ocenia przepływ danych. Model nie może sam potwierdzić, że jego własna wersja jest bezpieczna.

## Najważniejsze

- **EUDAMED identyfikuje i łączy informacje**, lecz nie zastępuje oceny zgodności, dowodów klinicznych ani nadzoru po wprowadzeniu produktu do obrotu.
- **Basic UDI-DI nie wystarcza do ustalenia wdrożonego buildu**; dostawca powinien pokazać cały łańcuch wersja → UDI-PI → UDI-DI → Basic UDI-DI.
- **Przeznaczenie wyrobu wyznacza granice użycia**. Slajd sprzedażowy nie rozszerza instrukcji używania ani oceny klinicznej producenta.
- **SSCP nie jest obowiązkowe dla każdego software’u medycznego**; najpierw sprawdź klasę i okres przejściowy, potem żądaj właściwego dokumentu lub wyjaśnienia.
- **Zakup nie kończy kontroli**. Placówka potrzebuje właściciela monitorowania wersji, incydentów, działań korygujących i zmian dokumentacji.

## Ta sama nazwa na slajdzie, inna wersja w gabinecie

Najczęstsza pułapka nie wygląda spektakularnie. W prezentacji jest „MedAI Pro”, w umowie ta sama nazwa, a w dokumentacji **Basic UDI-DI dla rodziny produktów**. Tymczasem instalowana wersja ma inny algorytm, zmieniony interfejs albo nowe źródło danych. **To właśnie zgodność konkretnej wersji** trzeba udowodnić przed wdrożeniem.

Basic UDI-DI łączy wyroby o tym samym przeznaczeniu, klasie ryzyka i podstawowych cechach konstrukcyjnych. UDI-DI schodzi niżej — do konkretnego modelu, wariantu lub wersji. Dla oprogramowania dochodzi identyfikacja produkcyjna, czyli UDI-PI. **Publiczny rekord nie pokazuje zawsze wartości UDI-PI**, więc placówka nie odczyta z niego automatycznie numeru buildu. Potrzebuje pisemnego mapowania od dostawcy.

Jeżeli dopiero ustalasz, czy dane rozwiązanie w ogóle powinno być traktowane jako wyrób, najpierw przeczytaj analizę [AI jako wyrób medyczny](/dane-i-bezpieczenstwo/ai-jako-wyrob-medyczny). Tutaj przyjmujemy już deklarację dostawcy i sprawdzamy coś innego: **czy wszystkie dowody opisują ten sam produkt**, a nie podobnie nazwaną rodzinę.

## Ranking pięciu dowodów: od identyfikacji do nadzoru

To nie jest podium, na którym pierwszy dowód jest ważny, a piąty opcjonalny. Traktuj ranking jak **pięć kolejnych bramek**: każda odpowiada na inne pytanie i **brak jednej zatrzymuje decyzję zakupową** do czasu wyjaśnienia. Dopiero komplet pozwala sensownie porównać kandydatów.

### 1. Basic UDI-DI i producent

Poproś o **Basic UDI-DI, nazwę prawną producenta i jego SRN**, a następnie otwórz bezpośredni rekord w publicznym EUDAMED. Porównaj klasę ryzyka, nazwę handlową, jednostkę notyfikowaną i powiązane certyfikaty. Materiał przesłany jako zrzut ekranu nie wystarcza — potrzebny jest link, który placówka może sprawdzić ponownie.

Ten identyfikator jest dobrym początkiem, bo łączy certyfikat, deklarację zgodności i dokumentację rodziny wyrobów. **Nie dowodzi jednak, który build zostanie zainstalowany** ani czy obietnica z prezentacji mieści się w przeznaczeniu. Czerwona flaga pojawia się, gdy dostawca podaje wyłącznie znak CE lub nazwę produktu, ale unika identyfikatora.

### 2. Łańcuch wersja → UDI-PI → UDI-DI

Drugi dowód to pisemna mapa: **numer wersji i buildu oferowanego placówce**, sposób identyfikacji UDI-PI, właściwy UDI-DI oraz nadrzędny Basic UDI-DI. Poproś też o regułę, według której producent uznaje zmianę za większą albo mniejszą. W software poprawka bezpieczeństwa może zmienić UDI-PI, a zmiana wpływająca na działanie, bezpieczeństwo, interpretację danych lub przeznaczenie może wymagać nowego UDI-DI.

Ja bym wpisał ten łańcuch do załącznika technicznego umowy. Dzięki temu aktualizacja nie przechodzi po cichu z „6.2” do „6.4”, gdy dokumenty nadal dotyczą starszego wariantu. **Niezgodność wersji oznacza pauzę**, nie prośbę o późniejsze dosłanie papierów po uruchomieniu.

### 3. Literalne przewidziane zastosowanie

Trzeci dowód odpowiada na pytanie: **do czego producent naprawdę przeznaczył wyrób**. Otwórz aktualną instrukcję używania i wypisz użytkownika, populację, wskazania, przeciwwskazania, rodzaj danych wejściowych, znaczenie wyniku oraz rolę człowieka. Następnie zestaw to z procesem planowanym w polskiej przychodni lub klinice.

Jeżeli instrukcja mówi o wsparciu lekarza w ocenie obrazu, prezentacja handlowa nie może po drodze zmienić produktu w autonomiczny triage. **Użycie poza przeznaczeniem nie staje się zgodne dlatego, że technicznie działa**. Przy decyzjach klinicznych wynik AI pozostaje materiałem pomocniczym, a uprawniony lekarz interpretuje dane i zatwierdza decyzję.

### 4. Aktualne SS(C)P — jeśli jest wymagane

SSCP, czyli podsumowanie bezpieczeństwa i działania klinicznego, jest wymagane na gruncie MDR dla wyrobów implantowanych i klasy III. Dla wyrobów IVD klas C i D właściwym dokumentem jest SSP. **Brak SSCP dla nieimplantowalnego software’u klasy IIa lub IIb nie jest automatycznie błędem**; trzeba sprawdzić klasę i poprosić o adekwatne dowody kliniczne, deklarację zgodności oraz dokumenty jednostki notyfikowanej.

W czerwcu 2026 r. MDCG opisała przejściowy sposób publikowania SS(C)P po obowiązkowym starcie pierwszych modułów EUDAMED. Dla nowych certyfikatów i aktualizacji dokument nadal wgrywa jednostka notyfikowana do czasu uruchomienia nowej funkcjonalności, a dla części starszych wyrobów rekord może jeszcze nie mieć certyfikatu lub SS(C)P. **Nie akceptuj pustego pola bez wyjaśnienia**, ale też **nie wydawaj wyroku bez sprawdzenia terminu migracji**. Poproś o kopię zatwierdzoną przez jednostkę i wskaż, kto ma uzupełnić rekord.

### 5. Właściciel monitorowania po wdrożeniu

Piąty dowód nie mieści się w jednym polu EUDAMED. Moduł Vigilance i nadzoru po wprowadzeniu do obrotu nadal jest rozwijany, więc **publiczna baza nie daje dziś pełnej historii PMS**. Dostawca powinien wskazać właściciela procesu, cykl aktualizacji PMS lub PSUR, ścieżkę zgłaszania incydentów, działania FSCA/CAPA oraz sposób informowania placówki o zmianie wersji i dokumentacji.

Placówka także potrzebuje właściciela: osoby, która raz w miesiącu lub przed każdą aktualizacją sprawdza komunikaty, wersję, certyfikat i nowe ograniczenia. **Zakup bez przypisanej odpowiedzialności tworzy martwy rejestr**. Wyrób może być poprawnie wybrany w lipcu, a źle używany po październikowej aktualizacji.

Poniższe zestawienie nie zastępuje dokumentów. Służy do szybkiego sprawdzenia, **czy pięć dowodów tworzy jeden spójny łańcuch**, oraz wskazuje moment, w którym **manager powinien zatrzymać ocenę**.

| Dowód | Minimalny zapis w karcie | Zatrzymaj zakup, gdy |
| --- | --- | --- |
| 1. Tożsamość | Basic UDI-DI, producent, SRN i link do rekordu | Dostawca pokazuje tylko znak CE lub zrzut ekranu |
| 2. Wersja | Build, UDI-PI, UDI-DI i reguła aktualizacji | Dokumenty opisują inny model albo starszy algorytm |
| 3. Przeznaczenie | Użytkownik, populacja, dane wejściowe i rola wyniku | Demo rozszerza funkcje poza aktualną instrukcję |
| 4. Dowody kliniczne | SS(C)P albo uzasadniony pakiet właściwy dla klasy | Brak dokumentu nie ma podstawy ani terminu uzupełnienia |
| 5. Nadzór | Właściciel PMS, cykl przeglądu i ścieżka FSCA/CAPA | Nikt nie odpowiada za incydenty i zmianę wersji |

## Karta decyzji zakupowej: pięć pól albo stop

Sugeruję jedną kartę na każdego kandydata. Nie punktuj jakości prezentacji ani liczby funkcji. Wpisz **link do dowodu, datę weryfikacji, właściciela i wynik** dla pięciu pól:

1. Basic UDI-DI oraz zgodny producent i SRN.
2. Mapa buildu do UDI-PI, UDI-DI i Basic UDI-DI.
3. Przeznaczenie zgodne z planowanym procesem placówki.
4. Właściwe i aktualne SS(C)P albo uzasadniony pakiet dokumentów zastępczych.
5. Właściciel oraz ślad PMS, incydentów, działań korygujących i aktualizacji.

Wynik **5/5 bez sprzeczności** oznacza, że kandydat może przejść do kontrolowanego pilotażu — nie że należy go automatycznie kupić. Wynik **4/5 oznacza wstrzymanie**, a nie warunkowy podpis. Przy 3/5 lub rozbieżności wersji albo przeznaczenia kończyłbym ocenę do czasu dostarczenia nowych dowodów.

Dwie metryki wystarczą na start: **odsetek kandydatów z kompletem zweryfikowanych dowodów** oraz **czas potrzebny na ponowne sprawdzenie dokumentów po aktualizacji**. Jeśli zespół nie umie odtworzyć decyzji bez opiekuna handlowego dostawcy, karta nie spełnia swojej funkcji.

## Co robi klinika, gdy dokumenty nie zgadzają się z demo

> **Przykład modelowy** — scenariusz pokazuje sposób myślenia o pilotażu. Liczby ilustrują metryki, nie gwarantują wyniku wdrożenia.

Prywatne centrum diagnostyczne porównuje dwa systemy AI wspierające radiologa w porządkowaniu listy badań. Dostawca A pokazuje build 6.4, lecz przesłany certyfikat i instrukcja wskazują wariant 6.2. Przeznaczenie mówi o **wsparciu oceny obrazu przez lekarza**, podczas gdy prezentacja obiecuje samodzielne przesuwanie badań w kolejce. To dwie sprzeczności, więc manager zatrzymuje ocenę przed integracją.

Dostawca dosyła mapę wersji, aktualną instrukcję i wyjaśnienie jednostki notyfikowanej. Dopiero wtedy centrum uruchamia ograniczony test w zatwierdzonym środowisku, bez wynoszenia danych pacjentów do publicznego modelu. **Radiolog sprawdza każdy wynik AI**, a system nie zmienia kolejności ani opisu badania bez jego zatwierdzenia. Manager zapisuje wersję, datę i wynik w karcie decyzji.

Ten przykład pokazuje, po co jest human-in-the-loop. **AI może porządkować listę i wskazywać rozbieżności**, ale nie rozstrzyga, czy dokument prawny obejmuje konkretny build ani czy wynik kliniczny jest prawidłowy. Odpowiedzialność zostaje po stronie uprawnionych osób w placówce.

## Gdzie kończy się rola AI, a zaczyna odpowiedzialność

Model językowy może pomóc znaleźć numery identyfikatorów, zestawić daty i zaznaczyć różnice między dokumentami. To przydatne, o ile pracuje na zatwierdzonych materiałach i **każde twierdzenie prowadzi do źródła pierwotnego**. Nie powierzaj mu samodzielnej interpretacji MDR, walidacji SSCP ani oceny dowodów klinicznych.

Podział ról powinien być prosty: **manager zakupowy pilnuje kompletności**, dyrektor medyczny zatwierdza dopasowanie do procesu klinicznego, IOD i bezpieczeństwo informacji oceniają dane oraz środowisko, a dostawca odpowiada za mapę wersji i nadzór produktu. Lekarz pozostaje osobą podejmującą decyzję kliniczną; model przygotowuje kontekst i wskazuje wyjątki.

Nie wklejaj do ogólnego modelu danych pacjentów, raportów z realnymi przypadkami ani dokumentów zawierających niepotrzebne dane osobowe. **Due diligence produktu nie wymaga historii choroby ani PESEL-u**. Jeżeli test ma używać danych klinicznych, musi odbyć się w zatwierdzonym środowisku, na podstawie udokumentowanej decyzji placówki i z kontrolą człowieka.

## Kiedy iść do pilotażu, a kiedy zakończyć rozmowę

**To ma sens, gdy…** wszystkie pięć dowodów dotyczy tego samego produktu, wersji i przeznaczenia, a placówka ma właściciela aktualizacji oraz zatwierdzony punkt kontroli lekarza. Wtedy pilot może sprawdzić dopasowanie do procesu, ergonomię i jakość działania bez udawania, że rekord w bazie przewiduje wynik wdrożenia.

**To nie ma sensu, gdy…** dostawca zasłania się samym znakiem CE, nie mapuje buildu do UDI, rozszerza przeznaczenie w prezentacji albo nie pokazuje, kto monitoruje incydenty i zmiany. **Czerwona flaga nie jest zaproszeniem do szybszego pilotażu** — jest powodem, by zatrzymać zakup.

W okresie przejściowym dopuszczalna odpowiedź może brzmieć: „rekord lub certyfikat będzie uzupełniony do terminu wynikającego z przepisów”. Musi jednak wskazywać **konkretną podstawę, datę i dokument zastępczy**. Ogólne „EUDAMED jeszcze nie działa” po 28 maja 2026 r. nie opisuje już poprawnie sytuacji czterech obowiązkowych modułów.

## Checklista pierwszej wiadomości do dostawcy

Zacznij od prośby o **Basic UDI-DI oraz bezpośredni link do właściwego rekordu i dokumentacji w EUDAMED**. W jednej wiadomości zbierz komplet wejść do karty decyzji:

- numer wersji i buildu oferowanego placówce;
- mapę buildu do UDI-PI, UDI-DI i Basic UDI-DI;
- aktualną instrukcję z literalnym przeznaczeniem;
- SS(C)P albo wyjaśnienie, dlaczego dokument nie jest wymagany lub jeszcze nie widnieje w rekordzie;
- rolę właściciela PMS, cykl przeglądu i sposób przekazywania informacji o incydentach, FSCA/CAPA oraz aktualizacjach.

Poproś, aby dostawca odpowiedział linkami i załącznikami źródłowymi, nie własnym streszczeniem. **Wyznacz jedną osobę po stronie placówki**, która zapisze datę weryfikacji i wynik pięciu bramek. Ja bym nie przechodził do ceny ani integracji, dopóki nie da się odtworzyć tego łańcucha dowodów bez udziału handlowca.
## Źródła

- [MDCG 2026-4 — Management of SS(C)P in EUDAMED after mandatory use](https://health.ec.europa.eu/document/download/a80332cf-e9f0-4d45-8863-3d96e8c2a675_en?filename=mdcg_2026-4_en.pdf) — stanowisko z czerwca 2026 r. wyjaśnia bieżący podział obowiązków przy publikacji SS(C)P, okres przejściowy i powiązanie dokumentu z Basic UDI-DI; opublikowano: 18 czerwca 2026 r.; Sprawdzono: 2026-07-11.
- [Komisja Europejska — EUDAMED: stan wdrożenia](https://health.ec.europa.eu/medical-devices-eudamed/overview_en) — oficjalny wykaz czterech modułów obowiązkowych od 28 maja 2026 r. oraz informacja, że Vigilance/PMS i badania kliniczne pozostają w rozwoju; Sprawdzono: 2026-07-11.
- [URPL — komunikat o obowiązkach i terminach EUDAMED](https://www.gov.pl/web/urpl/komunikat-prezesa-urzedu-rejestracji-produktow-leczniczych-wyrobow-medycznych-i-produktow-biobojczych-z-dnia-06-03-2026-r-w-sprawie-osiagniecia-z-dniem-27-listopada-2025-r-poziomu-operacyjnego-przez-cztery-moduly-europejskiej-bazy-danych-o-wyrobach-medycznych-eudamed-i-o-wynikajacych-z-tego-obowiazkach-podmiotow-gospodarczych2) — polskie źródło urzędowe precyzuje terminy rejestracji wyrobów i certyfikatów oraz wyjątki przejściowe; opublikowano: 6 marca 2026 r.; Sprawdzono: 2026-07-11.
- [Komisja Europejska — Basic UDI-DI i UDI-DI](https://health.ec.europa.eu/document/download/ec6c4f57-0219-425d-a757-9bd99f06cef0_en?filename=md_eudamed-udi-concept_en.pdf) — oficjalna infografika rozróżnia klucz rodziny wyrobów od identyfikatora konkretnego modelu, wariantu lub wersji; Sprawdzono: 2026-07-11.
- [MDCG 2018-5 — UDI Assignment to Medical Device Software](https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2018_5_software_en_0.pdf) — wytyczne opisują, kiedy zmiana oprogramowania wymaga nowego UDI-DI, a kiedy tylko nowego UDI-PI; opublikowano: październik 2018 r.; Sprawdzono: 2026-07-11.
- [Rozporządzenie (UE) 2017/745 — tekst skonsolidowany](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX%3A02017R0745-20260101) — pierwotna podstawa definicji przeznaczenia, UDI, SSCP oraz obowiązków nadzoru po wprowadzeniu do obrotu; wersja skonsolidowana: 1 stycznia 2026 r.; Sprawdzono: 2026-07-11.
- Okładka: [Gustavo Fring na Pexels](https://www.pexels.com/photo/medical-workers-looking-a-computer-screen-6285367/)