Europa wydłużyła termin wdrożenia AI Act. Problem zgodności Twojego SaMD nie zniknął.

Pakiet Digital Omnibus dał teamom healthtech więcej czasu — przynajmniej na papierze. W praktyce, jeśli rozwijasz oprogramowanie medyczne z AI, prace nad zgodnością powinny były ruszyć już dawno.

29 czerwca 2026 roku Rada UE formalnie zatwierdziła pakiet Digital Omnibus, przesuwając termin obowiązkowego stosowania przepisów dla systemów AI wysokiego ryzyka z 2 sierpnia 2026 na grudzień 2027, a dla systemów wbudowanych w wyroby regulowane przez MDR lub IVDR na 2 sierpnia 2028. Informacja obiegła kanały Slack w ciągu kilku godzin.

Reakcją większości firm była ulga. Powinna być ostrożność.

Nowe terminy nie rozwiązują podstawowego problemu. Jeśli tworzysz SaMD albo integrujesz AI z istniejącym wyrobem medycznym, od lat działasz w środowisku nakładających się obowiązków regulacyjnych. Przedłużenie daje więcej czasu zanim regulatorzy sprawdzą dokumentację. Nie daje więcej czasu na poprawienie architektury — bo te decyzje powinny były zapaść znacznie wcześniej.

Co faktycznie zmienił Digital Omnibus?

Digital Omnibus wprowadził dwa odrębne harmonogramy. Samodzielne systemy AI wysokiego ryzyka z Załącznika III muszą spełniać wymagania do 2 grudnia 2027. Systemy AI wbudowane w produkty regulowane w tym SaMD objęte MDR i IVDR mają czas do 2 sierpnia 2028.

Jeden element pozostał bez zmian: obowiązki transparentności z Artykułu 50. Zaczęły obowiązywać 2 sierpnia 2026, niezależnie od jakichkolwiek przesunięć. Jeśli produkt używa AI do komunikacji z użytkownikiem lub generuje treści, które mogłyby zostać uznane za stworzone przez człowieka, te wymogi już dotyczą Twojego systemu.

Warto też odnotować zasadę grandfatheringu. Systemy AI obecne na rynku przed 2 sierpnia 2026 podlegają nowym obowiązkom dopiero wtedy, gdy przejdą istotne zmiany projektowe. Problem polega na tym, że pojęcie „istotnej zmiany” jest wciąż interpretowane przez jednostki notyfikowane. Jeśli planujesz znaczący rozwój produktu w 2027 roku, zakładanie, że grandfathering automatycznie zapewni ochronę, byłoby ryzykowne.

Prawdziwy problem: obowiązują Cię 2 akty prawne jednocześnie

AI Act i MDR nie zastępują się wzajemnie. Nakładają się i każda funkcja AI w wyrobie medycznym z oznaczeniem CE musi spełniać oba zestawy wymagań jednocześnie.

MDR obowiązuje od maja 2021 roku. Wymaga oceny klinicznej, nadzoru pomarketingowego, dokumentacji cyklu życia oprogramowania zgodnie z IEC 62304 i zarządzania ryzykiem według ISO 14971. Nic z tego nie odpada po wejściu AI Act. Nowa regulacja dokłada własną warstwę: ocenę zgodności systemu AI, wymogi dotyczące zarządzania danymi, mechanizmy nadzoru ludzkiego, raportowanie incydentów do regulatorów i rejestrację w unijnej bazie systemów AI wysokiego ryzyka.

Dokumentacja techniczna musi więc odpowiadać obu ramom naraz. MDR pyta, czy oprogramowanie bezpiecznie realizuje swoją funkcję kliniczną. AI Act pyta dodatkowo, czy dane treningowe modelu były odpowiednie, wyniki są wyjaśnialne w miarę możliwości, a wykwalifikowany człowiek może nadpisać lub wyłączyć system. To nie są sprzeczne wymagania, ale nie były projektowane jako jeden spójny system — i pogodzenie ich w jednym pakiecie dokumentacyjnym wymaga znacznie więcej pracy, niż zakłada większość teamów.

W praktyce wiele firm odkrywa to skrzyżowanie dopiero podczas oceny MDR, gdy jednostka notyfikowana wskazuje, że nowa funkcja AI wymaga też kroków compliance z AI Act, których jeszcze nie zaczęto. W tym momencie konieczne stają się zmiany architektoniczne pod presją czasu a to jeden z najgorszych scenariuszy w projektach oprogramowania medycznego.

Co musi przygotować team deweloperski?

Nie ma jednej listy kontrolnej pasującej do każdego produktu, ale po pracy nad SaMD dla klientów z regionu DACH kilka obszarów pojawia się konsekwentnie.

Genealogia danych to pierwszy i zaskakująco łatwy do zaniedbania wymóg. AI Act wymaga pełnej dokumentacji zbiorów danych użytych do trenowania, walidacji i rozwoju modelu: źródeł, metodologii zbierania, znanych ograniczeń i błędów oraz potencjalnych uprzedzeń. Jeśli model był rozwijany iteracyjnie bez równoległego dokumentowania tych decyzji, odtworzenie historii po czasie jest kosztowne. Zaczynanie tej dokumentacji na początku prac jest nieporównywalnie łatwiejsze niż robienie tego wstecz.

Ściśle z tym związany jest nadzór ludzki i tu większość teamów napotyka problemy architektoniczne. AI Act wymaga, by człowiek mógł skutecznie nadzorować działanie systemu przez cały czas jego funkcjonowania. Dla systemów wysokiego ryzyka nie może to być checkbox dodany na końcu projektu. Jeśli system wspiera decyzje kliniczne lub diagnostyczne, mechanizm nadzoru musi być integralną częścią logiki produktu, testowaną jak każda inna funkcja i uwzględnioną w ocenie klinicznej.

Zarządzanie ryzykiem to obszar, gdzie MDR i AI Act wymagają najbardziej świadomego pogodzenia. Plik ISO 14971 obejmuje już ryzyka związane z oprogramowaniem w ramach MDR trzeba go rozszerzyć o tryby awarii charakterystyczne dla AI: degradację modelu w czasie, przesunięcie dystrybucji gdy zmienia się populacja pacjentów, nieznane wcześniej przypadki brzegowe. Ramy dają się ze sobą połączyć, ale ta praca nie dzieje się sama.

Post-Market Surveillance musi teraz uwzględniać monitoring wydajności modeli AI. Jeśli model był walidowany na populacji niemieckiej, a produkt rozszerza się na Austrię lub Szwajcarię, zmiana populacji może wpływać na jego skuteczność i powinna być śledzona. Takie mechanizmy trzeba zaprojektować od pierwszego sprintu, nie dodawać po launchu. Więcej o tym, jak testowanie aplikacji AI w ochronie zdrowia wpisuje się w wymogi compliance, opisaliśmy osobno.

Wreszcie: każda aktualizacja komponentu AI powinna przechodzić formalną ocenę, czy stanowi istotną zmianę w rozumieniu przepisów Digital Omnibus. Wbudowanie tego w process zarządzania zmianami teraz jest o wiele prostsze niż argumentowanie o tym z jednostką notyfikowaną za rok.

Gdzie teamy faktycznie wpadają w problemy?

Najczęstsze błędy compliance, które obserwujemy, nie wynikają z błędnej interpretacji przepisów. Są konsekwencją decyzji technicznych podjętych zanim ktokolwiek serio zastanowił się nad regulacyjnymi implikacjami.

Wybór modelu to jeden z częstszych przypadków. Teamy sięgają po modele fundacyjne lub zewnętrzne komponenty AI ze względów funkcjonalnych, nie pytając, czy ich proweniencja spełnia wymogi AI Act dotyczące zarządzania danymi. Jeśli dostawca nie może lub nie chce udokumentować danych treningowych, ta luka dokumentacyjna staje się problemem producenta wyrobu medycznego.

Logowanie to kolejna kwestia. AI Act wymaga rejestrów wystarczających do analizy incydentów i monitorowania pomarketingowego. Teamy, które budowały funkcje AI bez strukturowanego logowania wejść, wyników i wskaźników pewności modelu, odkrywają za późno, że nie są w stanie odtworzyć działania systemu w konkretnym przypadku klinicznym. W tym momencie naprawa jest kosztowna.

Trzeci problem to zbyt późne rozpoczęcie oceny klinicznej. Ocena kliniczna MDR dla funkcji AI trwa dłużej, niż zakłada większość teamów oceniający muszą zrozumieć, co model robi i jak zawodzi, a plan obserwacji pomarketingowej musi być gotowy od pierwszego dnia obecności produktu na rynku. Zaczynanie tego procesu po zakończeniu developmentu prowadzi do opóźnień i niekiedy do zmian projektowych, których nikt nie budżetował.

Ile naprawdę kosztuje zwlekanie?

Rynek AI w ochronie zdrowia w Niemczech był wyceniany na 3,34 mld USD w 2026 roku i ma osiągnąć 52,47 mld USD do 2035 roku, rosnąc w tempie 35,8% rocznie według IMARC Group. Za tymi liczbami stoi realne zapotrzebowanie dostawców i płatników w regionie DACH na diagnostykę, dokumentację i koordynację opieki wspomaganą przez AI.

Firmy, które zdobędą ten rynek, to te, których produkty są zgodne z przepisami, cieszą się zaufaniem klinicystów i mają zatwierdzenie jednostek notyfikowanych, gdy konkurenci wciąż kłócą się o dokumentację. Przesunięcie terminów tego nie zmienia — daje za to zgodnym produktom dłuższe okno na ugruntowanie pozycji rynkowej, zanim maruderzy nadgonią.

Co zrobić przed końcem 2026 roku

AI Act warto rozumieć jako proces a nie termin. A te nowe terminy warto potraktować jako czas na uporządkowanie, a nie pretekst do odkładania. Pierwszym krokiem powinien być gap assessment: porównaj aktualną dokumentację techniczną z wymogami MDR Załącznika II i AI Act dla systemów wysokiego ryzyka. Nie zaczynaj od zera lecz od zrozumienia, co masz i czego brakuje.

Jeśli planujesz znaczące aktualizacje na 2027 rok, upewnij się, że process zarządzania zmianami obejmuje ocenę, czy te modyfikacje uruchamiają nowe obowiązki compliance z przepisów Digital Omnibus. A jeśli Twój team deweloperski nie zna jeszcze konkretnych wymogów AI Act dotyczących logowania, nadzoru i zarządzania danymi, ta rozmowa jest zaległa.

Szerszy kontekst regulacyjny dla regionu DACH – MDR, DiGA, IEC 62304, ePA – opisaliśmy w artykule o tworzeniu oprogramowania zdrowotnego w Niemczech i Austrii.

Przez kilka ostatnich lat pomagamy klientom z sektora healthtech poruszać się po skrzyżowaniu MDR i AI Act. Jeśli chcesz zrozumieć, co to oznacza dla Twojego konkretnego produktu, chętnie to omówimy. Porozmawiajmy.