Digital Omnibus przesuwa obowiązki dla AI wysokiego ryzyka w wyrobach medycznych z sierpnia 2027 na sierpień 2028, a dla samodzielnych systemów z Załącznika III z sierpnia 2026 na grudzień 2027. Dla zespołów healthtech w Niemczech, Austrii i Szwajcarii to dodatkowy rok na planowanie, a nie reset terminu dla decyzji architektonicznych.
TL;DR — co się zmieniło, a co nie
Wstępne porozumienie Digital Omnibus z maja 2026 przesuwa obowiązki wysokiego ryzyka z art. 6 ust. 1 dla AI w wyrobach medycznych na 2 sierpnia 2028, a dla systemów z Załącznika III – na 2 grudnia 2027. Osiem wymogów technicznych z artykułów 9–17 (zarządzanie ryzykiem, governance danych, dokumentacja techniczna, automatyczne logowanie, transparentność, nadzór człowieka, dokładność, system zarządzania jakością) zostaje bez zmian. Trzy z nich: logowanie, nadzór człowieka, governance danych to decyzje architektoniczne, których wprowadzenie w istniejącym systemie zajmuje od 6 do 18 miesięcy. Kolejki w niemieckich jednostkach notyfikowanych sięgają dziś 24 miesięcy od pierwszego kontaktu do certyfikatu. Zaczynanie teraz to ścieżka ostrożna, nie wczesna.
Większość CTO w regionie DACH odczytała nagłówki o Omnibusie jako „mamy więcej czasu” i zdjęła AI Act z listy priorytetów. Część z nich w 2023 i 2024 roku wprowadziła już na rynek produkty z AI klinicznym — zbudowane na architekturze zaprojektowanej pod krajobraz regulacyjny, który dziś nie obowiązuje. Opóźnienie nie cofa tych produktów z rynku. Daje tylko jeden kwartał dodatkowego marginesu na ich przebudowę.
Z zespołami healthtech pracujemy nad tym zestawem regulacji od czasu, zanim AI Act został opublikowany w Dzienniku Urzędowym UE. W każdym projekcie kształt tej przebudowy wygląda tak samo. Horyzont 2028 nic w tym nie zmienia.
Czym jest „AI wysokiego ryzyka” w sektorze medycznym pod EU AI Act?
AI medyczne jest klasyfikowane jako wysokiego ryzyka pod AI Act wtedy, gdy oprogramowanie spełnia definicję wyrobu medycznego pod MDR i wymaga oceny zgodności przez jednostkę notyfikowaną, czyli przy klasie IIa, IIb lub III. To ścieżka z art. 6 ust. 1 i obejmuje większość klinicznych zastosowań AI. Drugą ścieżkę otwiera Załącznik III pkt 5 – wpada w nią AI używane przez organy publiczne do oceny uprawnień do świadczeń zdrowotnych, AI do wyceny ryzyka w ubezpieczeniach zdrowotnych oraz systemy triage’u w ratownictwie.
Wyroby medyczne klasy I, które nie wymagają udziału jednostki notyfikowanej, pozostają poza art. 6 ust. 1. MDCG doprecyzowała w wytycznych MDCG 2025-6 z czerwca 2025, że klasyfikacja wysokiego ryzyka pod AI Act nie zmienia klasy ryzyka pod MDR. To dwa niezależne reżimy, oceniane równolegle przez tę samą jednostkę notyfikowaną przy klasie IIa i wyższych.
W praktyce dla zespołu produktowego oznacza to trzy rzeczy. Funkcja AI w aplikacji klasy I może być poza art. 6 ust. 1, ale wciąż podlega obowiązkom transparentności z art. 50. Funkcja AI w SaMD klasy IIa i wyższej jest jednoznacznie wysokiego ryzyka. A AI na granicy klasyfikacji to najryzykowniejsza strategia produktowa, bo regulatorzy patrzą najpierw właśnie na tę linię.
Kiedy EU AI Act faktycznie zacznie obowiązywać dla medical AI?
Pierwotne terminy 2 sierpnia 2026 i 2 sierpnia 2027 są przesuwane przez porozumienie Digital Omnibus z maja 2026. Formalne przyjęcie spodziewane jest przed 2 sierpnia 2026. Dla roadmapy w healthtechu liczą się cztery daty:
Data Co wchodzi w życie Kogo dotyczy 2 lutego 2025 Zakazane praktyki AI, obowiązki AI literacy Wszyscy dostawcy i operatorzy AI 2 sierpnia 2025 Obowiązki dla modeli GPAI, governance, kary Twórcy modeli foundation, operatorzy downstream 2 grudnia 2027 (opóźnione) Wysokie ryzyko z Załącznika III (m.in. uprawnienia zdrowotne, ubezpieczenia, triage ratunkowy) Publiczne AI zdrowotne, ubezpieczyciele, dispatch 2 sierpnia 2028 (opóźnione) Wysokie ryzyko z art. 6 ust. 1 dla AI w wyrobach MDR/IVDR Dostawcy SaMD z AI, producenci wyrobów klasy IIa i wyższych Uzasadnienie Parlamentu Europejskiego jest proste: zharmonizowane normy techniczne nie są jeszcze gotowe. JTC 21 w CEN-CENELEC wciąż je opracowuje. Bez tych norm ocena zgodności staje się interpretacją zamiast pomiaru.
Same obowiązki opóźnienie nie zmienia. Artykuły 9–17 pozostają poprzeczką techniczną. Gdy normy pojawią się w 2027, jednostki notyfikowane będą egzekwować je z tą samą rygorystycznością, z jaką dziś egzekwują MDR.
Jak EU AI Act, MDR i EHDS uzupełniają się, a gdzie ze sobą kolidują?
Produkt z AI medycznym w DACH działa pod trzema regulacjami jednocześnie. Pisały je różne zespoły według różnych modeli myślenia, a styki między nimi widać na poziomie architektury.
Wymiar EU AI Act MDR 2017/745 EHDS (Rozp. 2025/327) Trigger Klasyfikacja wysokiego ryzyka przez art. 6 lub Załącznik III Oprogramowanie o przeznaczeniu medycznym Elektroniczne dane zdrowotne, EHR, wybrane aplikacje wellness Ocena zgodności Kontrola wewnętrzna lub jednostka notyfikowana – ta sama co dla MDR przy klasie IIa+ Jednostka notyfikowana dla klasy IIa, IIb, III Ocena zgodności EHR od 2029 Dokumentacja Art. 11 + Załącznik IV – dokumentacja techniczna Dokumentacja techniczna z Załącznika II MDR Dowód zgodności z EEHRxF Logowanie Art. 12 – automatyczne, przez cały cykl życia Log audytowy zgodnie z IEC 62304 Interoperacyjny eksport do użycia wtórnego Nadzór człowieka Art. 14 – egzekwowalny operacyjnie Wymagany dla clinical decision support Prawa pacjenta do dostępu i nadpisania Po wprowadzeniu na rynek Art. 72 monitoring + raportowanie incydentów Art. 83–86 nadzór rynkowy Raportowanie do Health Data Access Body Punkt tarcia, który widzimy najczęściej: ocena kliniczna pod MDR dowodzi działania urządzenia w stosunku do przeznaczenia. AI Act oczekuje dowodu na dokładność modelu, jego odporność i brak dyskryminujących wyników w grupach chronionych. Ten sam model, dwie ramy oceny. Zespoły, które od razu zaprojektowały framework ewaluacji tak, by obsługiwał obie naraz, produkują jeden dokument. Te, które tego nie zrobiły, robią ewaluację dwa razy.
Czego termin 2028 faktycznie wymaga od zespołu produktowego?
Osiem wymogów technicznych z artykułów 9–17, z czego trzy to decyzje architektoniczne, których nie da się dorobić później: automatyczne logowanie, nadzór człowieka i governance danych. Pozostałe pięć: zarządzanie ryzykiem, dokumentacja techniczna, transparentność, dokładność i odporność, system zarządzania jakością to warstwy operacyjne nadbudowane na tej architekturze.
Liczby z aktualnych raportów branżowych pokazują skalę pracy. Walidacja AI w healthcare podnosi koszt zgodności o 20–40%. Wymagania dokumentacyjne wydłużają czas developmentu o 15–25%. Roczny koszt zgodności na jeden model AI to około 29 277 euro. Ocena zgodności przez stronę trzecią kosztuje od 10 000 do 40 000 euro za system. Badanie Pharmaceutical Technology z 2025 pokazało, że tylko 60% europejskich firm pharma planuje wdrożyć zarządzanie ryzykiem AI do 2027 roku, a 45% planuje przebudowę systemu zarządzania jakością pod AI. Pozostałe 40% i 55% rusza za późno.
Wąskie gardło jednostek notyfikowanych pogłębia problem. Najbardziej oblegane niemieckie jednostki, BSI, TÜV SÜD, DEKRA – mają obecnie kolejki przyjęciowe na 6–12 miesięcy, a sam cykl oceny trwa 13–18 miesięcy. Od pierwszego kontaktu do certyfikatu trzeba więc zakładać 24 miesiące. Pod MDR działa około 45 jednostek notyfikowanych, wobec około 80 pod poprzednią dyrektywą MDD, i obsługują one znacznie większy nakład pracy na ocenę.
Wniosek z arytmetyki jest prosty: jeśli Twój SaMD klasy IIa z AI ma być certyfikowany przed 2 sierpnia 2028 roku, realistyczny ostatni moment na wejście do kolejki jednostki notyfikowanej to III kwartał 2026 roku. Czyli teraz.
Trzy scenariusze produktowe z naszej praktyki w DACH
Te same decyzje architektoniczne wracają w bardzo różnych kategoriach produktów. Trzy przykłady z naszej praktyki w sektorze healthcare pokazują, jak gotowość pod AI Act wygląda w kodzie.
Narzędzie do dokumentacji terapii z AI w kategorii Mentalyc to podręcznikowy przypadek pod art. 14. Każde nagranie sesji to dane szczególnej kategorii z art. 9 RODO. Każdy wynik modelu jest artefaktem klinicznym. Decyzja terapeuty o zaakceptowaniu, zmodyfikowaniu lub odrzuceniu notatki wygenerowanej przez AI to dokładnie ten nadzór człowieka, który ma na myśli art. 14. Pytanie architektoniczne brzmi: czy Twoja baza potrafi dla dowolnej notatki odtworzyć to, co zaproponował model, to, co zmienił terapeuta, i kiedy. Tę ścieżkę audytową wbudowaliśmy w model danych Mentalyca już w pierwszym sprincie. Doposażenie istniejącego systemu wymagałoby migracji każdej historycznej notatki.
Clinical decision support system dla szpitali, sklasyfikowany jako MDR klasy IIa, to system wysokiego ryzyka pod art. 6 ust. 1 od sierpnia 2028. Wyzwanie architektoniczne to tu reprezentacja niepewności. Art. 15 wymaga dokładności, art. 13 wymaga, by operatorzy rozumieli ograniczenia systemu. Odpowiedź z API nie może zwracać samej rekomendacji. Musi zwrócić również skalibrowaną wartość confidence, cechy, które najmocniej wpłynęły na decyzję, oraz znacznik dla danych spoza dystrybucji treningowej. Większość systemów CDSS zbudowanych przed 2024 zwraca samą rekomendację. Przebudowa jest znacząca.
Aplikacja mHealth do zarządzania cukrzycą w duchu mySugr, z funkcją AI sugerującą korektę dawki insuliny, znajduje się na granicy klasyfikacji. Jeśli AI stanowi wyrób medyczny pod MDR a większość rekomendacji dotyczących dawkowania nim jest, to system wysokiego ryzyka przez art. 6 ust. 1. Jeśli zostanie sklasyfikowane jako wellness suggestion poniżej progu MDR, może znaleźć się poza wysokim ryzykiem. Ta linia to dokładnie miejsce, w które patrzą regulatorzy. Doradzamy zespołom projektować pod zgodność wysokiego ryzyka i z pozycji architektonicznej siły argumentować klasyfikację — nie odwrotnie.
Gdzie utknie większość zespołów
Trzy decyzje architektoniczne decydują o tym, czy zgodność z AI Act stanie się planowalnym programem inżynierskim, czy przeciągniętą na kilka kwartałów przebudową.
Rozdzielenie wyniku modelu od nadpisania przez człowieka w warstwie danych. Art. 14 wymaga, by człowiek mógł zainterweniować, zanim wynik AI dotrze do użytkownika. W kodzie znaczy to, że każdy artefakt wygenerowany przez AI potrzebuje trzech pełnoprawnych stanów: oryginalny wynik modelu, wersja zmodyfikowana przez człowieka, wersja finalna w rekordzie. Większość schematów przechowuje wyłącznie wersję finalną, nadpisując pozostałe. Działa to dla UX produktu, ale nie przejdzie audytu pod art. 14.
Niezmienny, odpytywalny ślad audytowy. Art. 12 wymaga automatycznego logowania przez cały cykl życia systemu AI. Próg audytowy to nie pytanie „czy logujemy”, tylko „czy potrafimy odpowiedzieć na pytanie jednostki notyfikowanej, korzystając z logu”. Jeśli regulator zapyta, jak model zachowywał się w konkretny wtorek w marcu, log musi pozwolić odpowiedzieć w ciągu minut, nie tygodni. Magazyn obiektowy w trybie tylko-do-dopisywania, indeksowany po wersji modelu i znaczniku czasu inferencji, się sprawdza. Logi aplikacyjne zrzucane do SIEM zoptymalizowanego pod zdarzenia security — nie.
Potok model card → dokumentacja techniczna. Art. 11 i Załącznik IV określają zawartość dokumentacji technicznej: cel zastosowania, charakterystykę danych treningowych, metryki działania w reprezentatywnych populacjach, znane ograniczenia, mechanizmy nadzoru człowieka. Zespoły, które utrzymują kartę modelu (model card) dla każdej wersji modelu — aktualizowaną razem z każdym retrainem — generują plik z Załącznika IV jako eksport. Zespoły produkujące dokumentację techniczną ręcznie, jako jednorazowy artefakt, odkrywają, że następny retrain ją unieważnia.
Co zrobilibyśmy, gdybyśmy zaczynali dziś
Gdybyśmy w maju 2026 roku budowali nowy produkt z medical AI dla DACH, potraktowalibyśmy osiem obowiązków z artykułów 9–17 jako osiem decyzji architektonicznych podjętych w pierwszym sprincie — nie jako równoległy strumień prac nad zgodnością obok developmentu. Wymodelowalibyśmy wynik AI, modyfikację człowieka i rekord docelowy jako trzy odrębne klasy danych. Logowalibyśmy każdą inferencję do niezmiennego magazynu indeksowanego po wersji modelu. I pisalibyśmy kartę modelu w tym samym pull requeście co kod modelu.
Zespoły, które będą miały problem w 2027 i 2028, to nie te, które zaczynają dziś. To te, które odczytują nagłówki o Omnibusie jako pozwolenie na czekanie. Niemiecki rynek digital health jest prognozowany na 38,33 mld dolarów w 2026 roku, z SaMD rosnącym w tempie 20,9% CAGR do 2032. Ryzyko konkurencyjne związane z opóźnieniem jest większe niż koszt zbudowania produktu od razu dobrze.
Przetestujmy razem Twoją architekturę medical AI pod kątem AI Act
Jeśli budujesz AI kliniczne lub wellness dla rynku DACH i chcesz drugiej opinii o tym, co termin 2 sierpnia 2028 oznacza dla Twojej konkretnej architektury – chętnie się umówimy. Pracujemy nad tymi decyzjami z zespołami healthtech Austrii od czasu, zanim AI Act został sfinalizowany – w tym z klientami takimi jak Mentalyc, Selfapy i mySugr/Roche.
Umów 30-minutową konsultację → · Zobacz naszą praktykę healthcare i medtech → ·
