Zgłaszanie poważnych incydentów na gruncie AI Act: Artykuł 73 w praktyce

Co wymaga artykuł 73 i kogo wiąże

Artykuł 73 znajduje się w rozdziale IX Aktu, poświęconym monitorowaniu po wprowadzeniu do obrotu i nadzorowi rynku. Podstawowy obowiązek z artykułu 73(1) jest krótki: providerzy systemów AI wysokiego ryzyka wprowadzonych na rynek Unii zgłaszają każdy poważny incydent organom nadzoru rynku państwa członkowskiego, w którym incydent wystąpił.

Z tego sformułowania wynikają dwie kwestie zakresu.

Po pierwsze, obowiązek jest przypisany do systemów wysokiego ryzyka. To systemy objęte artykułem 6: AI będąca komponentem bezpieczeństwa regulowanego produktu na mocy załącznika I oraz samodzielne przypadki użycia wymienione w załączniku III, obejmujące biometrię, infrastrukturę krytyczną, zatrudnienie i zarządzanie pracownikami, dostęp do usług podstawowych, ściganie przestępstw i kilka innych. Firma, która używa asystenta ogólnego przeznaczenia do streszczania dokumentów albo pisania tekstów, jest deployerem, ale na tej podstawie nie eksploatuje systemu wysokiego ryzyka, więc artykuł 73 nie obejmuje tego użycia.

Po drugie, wskazanym adresatem obowiązku jest provider. Provider, w rozumieniu artykułu 3(3), to podmiot, który tworzy system wysokiego ryzyka i wprowadza go do obrotu albo oddaje do użytku pod własną nazwą lub znakiem towarowym. Deployer, w rozumieniu artykułu 3(4), to podmiot, który używa systemu na własną odpowiedzialność w ramach działalności zawodowej. Architektura zgłoszeniowa zakłada, że provider jest w najlepszej pozycji, żeby zbadać system i złożyć zgłoszenie do organu, podczas gdy deployer często jako pierwszy widzi incydent w praktyce. Akt łata tę lukę przez obowiązek eskalacji po stronie deployera, o czym niżej.

Istnieje osobny, równoległy obowiązek dla modeli GPAI o ryzyku systemowym. Artykuł 55(1)(c) wymaga od ich providerów śledzenia i zgłaszania poważnych incydentów do Urzędu ds. AI i organów krajowych. Ten reżim działa na własnym torze, z własnym szablonem, i nie jest przedmiotem tego przewodnika. Organizacje objęte oboma obowiązkami powinny dopasować do siebie swoje procesy, ale to dwa odrębne obowiązki.

Co liczy się jako poważny incydent

Wyzwalaczem jest definicja z artykułu 3(49). Poważny incydent to incydent lub nieprawidłowe działanie systemu AI, które bezpośrednio lub pośrednio prowadzi do jednego z poniższych:

• (a) śmierci człowieka albo poważnego uszczerbku na jego zdrowiu;
• (b) poważnego i nieodwracalnego zakłócenia zarządzania infrastrukturą krytyczną lub jej funkcjonowania;
• (c) naruszenia obowiązków wynikających z prawa Unii chroniącego prawa podstawowe;
• (d) poważnej szkody na mieniu lub środowisku.

Trzy cechy tej definicji kształtują to, jak działa ona w praktyce.

Pierwsza to sformułowanie „bezpośrednio lub pośrednio”. Projekt wytycznych Komisji traktuje pośredni związek przyczynowy jako wystarczający. Przykłady z wytycznych obejmują błędną analizę medyczną AI, która powoduje szkodę dopiero po tym, jak lekarz zadziała na podstawie błędnej informacji, odmowę kredytu opartą na wadliwej ocenie AI oraz niekorzystne traktowanie kwalifikujących się kandydatów przez dyskryminującą procedurę selekcji. Chodzi o to, że system AI nie musi być bezpośrednią ani jedyną przyczyną. Jeśli jest ogniwem w łańcuchu prowadzącym do jednego z czterech skutków, obowiązek może się uruchomić. Te przykłady nie są wyczerpujące i pochodzą z projektu, ale sygnalizują szeroką interpretację.

Druga to kategoria (c), naruszenie praw podstawowych, czyli kategoria najbardziej prawdopodobna do wystąpienia w zwykłej AI korporacyjnej. Pozostałe trzy kategorie opisują szkodę fizyczną albo środowiskową, która wpisuje się w myślenie o bezpieczeństwie produktu. To kategoria (c) sprawia, że dyskryminujący filtr rekrutacyjny, stronnicza decyzja kredytowa albo niezgodna z prawem kategoryzacja biometryczna są zgłaszalne jako poważny incydent same w sobie, nawet bez szkody fizycznej.

Trzecia jest taka, że kategoria (c) niesie ze sobą specjalną zasadę routingu. Na mocy artykułu 73(7), gdy organ nadzoru rynku otrzymuje zgłoszenie incydentu z kategorii (c), informuje organy krajowe chroniące prawa podstawowe, wymienione w artykule 77(1). To jest zaczep, który łączy zgłaszanie incydentów AI z istniejącym systemem nadzoru nad prawami podstawowymi.

Zegar zgłoszeniowy: trzy prędkości

Artykuł 73 ustala domyślny termin i dwa przyspieszone. W każdym przypadku zgłoszenie jest należne „niezwłocznie”, gdy tylko provider ustali związek przyczynowy między systemem a incydentem, albo jego uzasadnione prawdopodobieństwo, a potem obowiązuje sztywny górny termin. Zegar biegnie od powzięcia wiedzy o poważnym incydencie.

• Domyślny poważny incydent · Górny termin: Nie później niż 15 dni od powzięcia wiedzy · Podstawa: Art. 73(2)
• Mogła nastąpić śmierć człowieka · Górny termin: Nie później niż 10 dni od powzięcia wiedzy · Podstawa: Art. 73(4)
• Powszechne naruszenie albo poważne i nieodwracalne zakłócenie infrastruktury krytycznej (kategoria (b)) · Górny termin: Nie później niż 2 dni od powzięcia wiedzy · Podstawa: Art. 73(3)

Terminy to górne granice, nie cele same w sobie. Artykuł 73(2) wymaga, żeby okres zgłoszeniowy uwzględniał wagę incydentu, więc poważny incydent wykryty z jasnym związkiem przyczynowym nie może czekać do 15 dnia. Standardem jest „bez zbędnej zwłoki”, a liczbowy limit działa jako zabezpieczenie na wypadek najgorszego scenariusza.

Artykuł 73(5) daje ulgę w sytuacji, którą zna każdy, kto reaguje na incydenty: możesz nie mieć pełnego obrazu w ramach okna czasowego. Provider, a tam gdzie ma to zastosowanie także deployer, może złożyć wstępne, niekompletne zgłoszenie, a potem uzupełnić je pełnym. Praktyczna interpretacja jest taka, żeby zgłosić to, co się ma, w ramach terminu, i uzupełniać w miarę postępu dochodzenia, zamiast przegapić okno w oczekiwaniu na pewność.

Po zgłoszeniu artykuł 73(6) wymaga od providera niezwłocznego zbadania sprawy, w tym oceny ryzyka i działań naprawczych, oraz współpracy z właściwym organem i wszelką odpowiednią jednostką notyfikowaną. W artykule 73(6) jest istotna zasada zachowania stanu: provider nie może zmienić systemu AI w sposób, który mógłby wpłynąć na późniejszą ocenę przyczyn incydentu, zanim poinformuje organ. To odpowiednik zachowania dowodów na gruncie AI Act i ogranicza, jak szybko można załatać albo wycofać system, który jest przedmiotem dochodzenia.

Po stronie odbiorczej artykuł 73(8) daje organowi nadzoru rynku siedem dni na podjęcie odpowiednich środków na mocy artykułu 19 rozporządzenia w sprawie nadzoru rynku (UE) 2019/1020. Te środki mogą obejmować wycofanie produktu, odwołanie albo ograniczenia w udostępnianiu systemu. Zgłoszenie poważnego incydentu nie jest więc dokumentem, który znika w kolejce, może wywołać działania nadzorcze wobec systemu w ciągu tygodnia.

Provider czy deployer: kto naprawdę zgłasza

Główny obowiązek z artykułu 73(1) spoczywa na providerze, ale większość organizacji eksploatujących AI w UE to deployerzy, a deployer często jako pierwszy widzi incydent. Akt rozwiązuje to przez artykuł 26(5), obowiązek deployera stojący obok artykułu 73.

Na mocy artykułu 26(5), deployer, który zidentyfikuje poważny incydent, musi natychmiast poinformować, w tej kolejności, providera, potem importera lub dystrybutora, i właściwe organy nadzoru rynku. Głównym ruchem deployera jest eskalacja do providera, który dalej niesie obowiązki zgłoszeniowe i dochodzeniowe z artykułu 73. Deployer nie jest jednak zwolniony z relacji z organem: sformułowanie obejmuje też organ nadzoru rynku.

Jest wariant awaryjny. Jeśli deployer nie może dotrzeć do providera, artykuł 73 stosuje się do deployera bezpośrednio, w języku Aktu „mutatis mutandis”. Mówiąc wprost, deployer, który nie może eskalować, wchodzi w rolę zgłoszeniową providera i składa zgłoszenie do organu w tym samym terminie. To ma znaczenie operacyjne: deployer nie może traktować „powiedzieliśmy dostawcy” jako końca obowiązku, jeśli dostawca jest nieosiągalny albo nie odpowiada.

Praktyczną konsekwencją jest to, że deployerzy potrzebują wewnętrznego wyzwalacza, który rozpoznaje poważny incydent w rozumieniu artykułu 3(49), a nie tylko zwykłą awarię usługi, oraz udokumentowanej ścieżki eskalacji do providera z wariantem awaryjnym do organu. Terminy wiążące providera faktycznie wiążą też eskalację deployera, bo spóźniona eskalacja czyni spóźnione zgłoszenie providera nieuniknionym.

Warto wspomnieć jeszcze o jednej granicy. Deployer, który istotnie modyfikuje system wysokiego ryzyka albo oznacza go własną nazwą lub znakiem towarowym, może stać się providerem na mocy artykułu 25. Organizacja, która przekroczyła tę granicę, nie eskaluje już do kogoś innego, sama jest providerem na potrzeby artykułu 73 i zgłasza bezpośrednio.

Jak artykuł 73 nakłada się na RODO, NIS2 i DORA

Tu mieszka większość realnej złożoności. Jeden incydent AI może znajdować się w kilku reżimach zgłoszeniowych naraz, każdy z własnym organem, progiem i zegarem. AI Act żadnego z nich nie zastępuje. Poniższa tabela pokazuje osobne zegary. Chodzi o to, że biegną one równolegle, spełnienie jednego nie spełnia pozostałych.

• AI Act, art. 73 · Wyzwalacz: Poważny incydent dotyczący systemu AI wysokiego ryzyka (art. 3(49)) · Organ: Organ nadzoru rynku · Termin wstępny: 2, 10 albo 15 dni, zależnie od wagi
• RODO, art. 33 · Wyzwalacz: Naruszenie danych osobowych mogące zagrażać prawom osób · Organ: Organ ochrony danych · Termin wstępny: 72 godziny od powzięcia wiedzy
• NIS2, art. 23 · Wyzwalacz: Istotny incydent w podmiocie kluczowym lub ważnym · Organ: CSIRT albo organ właściwy · Termin wstępny: Wczesne ostrzeżenie w ciągu 24 godzin; aktualizacja w ciągu 72 godzin; raport końcowy w ciągu miesiąca
• DORA, art. 19 · Wyzwalacz: Poważny incydent ICT w podmiocie finansowym · Organ: Właściwy organ finansowy · Termin wstępny: Wstępne powiadomienie w terminie ustalonym przez regulacyjne standardy techniczne (znacznie skrócony dla poważnych incydentów)

Dwa punkty integracji w samym artykule 73 ograniczają dublowanie, i oba są ważne.

Artykuł 73(9): równoważne reżimy zgłoszeniowe. Dla systemów wysokiego ryzyka z załącznika III, których providerzy są już objęci unijnymi instrumentami ustanawiającymi równoważne obowiązki zgłoszeniowe, powiadomienie z artykułu 73 ogranicza się do kategorii (c), incydentów dotyczących praw podstawowych. Interpretacja, która wyłania się z projektu wytycznych Komisji i analiz praktyków, jest taka, że gdy incydent jest już objęty reżimem sektorowym takim jak NIS2, DORA albo dyrektywa o odporności podmiotów krytycznych, samo zdarzenie zgłasza się na mocy tego reżimu sektorowego, a AI Act służy tylko do dodania wymiaru praw podstawowych tego samego zdarzenia. To reguła routingu, nie zwolnienie: incydent nadal jest zgłaszany, po prostu nie dwa razy w pełnym zakresie.

Artykuł 73(10): wyroby medyczne. Dla systemów wysokiego ryzyka, które są wyrobami albo komponentami bezpieczeństwa wyrobów na mocy rozporządzenia o wyrobach medycznych (UE) 2017/745 albo rozporządzenia o wyrobach medycznych do diagnostyki in vitro (UE) 2017/746, powiadomienie z AI Act znów ogranicza się do kategorii (c) i trafia do krajowego organu właściwego wyznaczonego do tego celu. Resztę niesie system nadzoru nad wyrobami.

Czego to wszystko nie zmienia, to RODO. Jeśli incydent AI obejmuje też naruszenie danych osobowych, 72-godzinny zegar z artykułu 33 RODO biegnie niezależnie od zegara AI Act, do innego organu, na innym progu. Dyskryminująca decyzja rekrutacyjna AI może być jednocześnie poważnym incydentem z kategorii (c) na mocy AI Act i naruszeniem danych osobowych na mocy RODO, i oba zgłoszenia mogą być należne. Analiza projektu wytycznych firmy Latham mówi to samo: Komisja oczekuje, że procesy z artykułu 73 będą dopasowane do procesów zgłaszania naruszeń RODO, a nie w nie wtopione.

Praktyczny model, który się sprawdza, to jeden wewnętrzny proces obsługi incydentów z krokiem klasyfikacji, który zadaje cztery pytania przy każdym kwalifikującym się zdarzeniu: czy to poważny incydent na mocy artykułu 3(49) AI Act; czy doszło do naruszenia danych osobowych na mocy RODO; czy to istotny incydent na mocy NIS2; i, dla podmiotów finansowych, czy to poważny incydent ICT na mocy DORA. To samo zdarzenie może odpowiedzieć „tak” na więcej niż jedno pytanie, a każde „tak” uruchamia własny zegar do własnego organu.

Proponowane uproszczenie: czytaj jako projekt, nie jako prawo

Trwa ruch w stronę ograniczenia tego nakładania się. W listopadzie 2025 roku Komisja Europejska opublikowała Digital Omnibus, pakiet mający uprościć unijny zbiór przepisów cyfrowych, w tym części AI Act, RODO i Data Act. Jeden element istotny tutaj to proponowany pojedynczy punkt wejścia dla zgłaszania incydentów i naruszeń, który kierowałby jedno zgłoszenie do kilku reżimów naraz (NIS2, RODO, DORA, eIDAS i dyrektywa o odporności podmiotów krytycznych), tak żeby organizacja mogła spełnić wiele obowiązków zgłoszeniowych jednym raportem zamiast kilkoma.

Na lipiec 2026 pojedynczy punkt wejścia jeszcze nie istnieje, a obecne obowiązki opisane wyżej pozostają obowiązującymi wymogami. Część AI Act w Digital Omnibus, przyjęta przez Parlament 16 czerwca 2026 i przez Radę 29 czerwca 2026, czekająca na publikację w Dzienniku Urzędowym, przesuwa datę stosowania załącznika III wysokiego ryzyka na 2 grudnia 2027, a datę załącznika I na 2 sierpnia 2028, ale te zmiany jeszcze nie weszły w życie. Traktuj to uproszczenie jako kierunek do śledzenia, nie jako zabezpieczenie, na którym można polegać. Buduj model równoległego zgłaszania pod prawo, jakie obowiązuje dziś, i dostosuj go, jeśli i kiedy pojedynczy punkt wejścia zostanie przyjęty.

Jak wygląda dobre przygotowanie

Terminy zgłoszeniowe są na tyle krótkie, że nie da się ich dotrzymać improwizacją po fakcie. Praca, która czyni artykuł 73 wykonalnym, jest robiona wcześniej i mocno pokrywa się z pracą nad reagowaniem na incydenty, którą organizacje już wykonują dla RODO i NIS2.

Pozycja, którą da się obronić, ma kilka elementów. Jest definicja „poważnego incydentu” wpisana w proces reagowania na incydenty, żeby osoby reagujące potrafiły rozpoznać zdarzenie z artykułu 3(49), a nie tylko zwykłą awarię usługi. Jest krok klasyfikacji, który sprawdza każdy kwalifikujący się incydent pod kątem wszystkich czterech reżimów naraz. Jest wyznaczony właściciel relacji z providerem po stronie deployera, ze ścieżką eskalacji i udokumentowanym wariantem awaryjnym na wypadek, gdyby providera nie dało się osiągnąć. I jest nawyk dokumentowania, bo szablon zgłoszeniowy, który Komisja wydała do konsultacji, jest obszerny, a dwu- i dziesięciodniowe okna nie zostawiają czasu na zbieranie faktów od zera.

Zasada zachowania stanu z artykułu 73(6) to część, która najczęściej zaskakuje zespoły inżynierskie. Instynktowną reakcją na wykrycie wadliwego systemu wysokiego ryzyka jest natychmiastowa naprawa. Artykuł 73(6) wymaga, żeby provider nie zmieniał systemu w sposób, który mógłby wpłynąć na późniejszą ocenę przyczyn, zanim poinformuje organ. Runbooki reagowania na incydenty dla AI wysokiego ryzyka muszą godzić presję na naprawę z obowiązkiem zachowania stanu, to samo napięcie, jakie zachowanie dowodów forensycznych tworzy w każdym poważnym incydencie bezpieczeństwa.

Źródła

• Regulation (EU) 2024/1689 (AI Act), Article 73 full text · https://artificialintelligenceact.eu/article/73/ (jedenaście ustępów obowiązku zgłoszeniowego, terminy, zasady dochodzenia i zachowania stanu oraz wyłączenia z 73(9) i 73(10))
• AI Act Service Desk (European Commission), Article 73 · https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-73 (oficjalny tekst artykułu 73 hostowany przez Komisję i jego data stosowania 2 sierpnia 2026)
• Regulation (EU) 2024/1689 (AI Act), Article 3 definitions · https://artificialintelligenceact.eu/article/3/ (definicje providera z artykułu 3(3), deployera z 3(4) i poważnego incydentu z 3(49))
• Regulation (EU) 2024/1689 (AI Act), Article 26 · https://artificialintelligenceact.eu/article/26/ (obowiązek deployera z artykułu 26(5) do poinformowania providera i organu oraz wariant awaryjny z artykułu 73 na wypadek nieosiągalności providera)
• Official Journal text of Regulation (EU) 2024/1689 on EUR-Lex · https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689 (autorytatywny tekst prawny AI Act)
• European Commission, draft guidance and reporting template for serious AI incidents (consultation, 26 September 2025) · https://digital-strategy.ec.europa.eu/en/consultations/ai-act-commission-issues-draft-guidance-and-reporting-template-serious-ai-incidents-and-seeks (zakres projektu, interpretacja pośredniej przyczynowości i szablon zgłoszeniowy, otwarte na komentarze do 7 listopada 2025, mające zacząć obowiązywać od 2 sierpnia 2026)
• Latham & Watkins, "European Commission Publishes Draft Guidance on Reporting Serious AI Incidents" (28 October 2025) · https://www.lw.com/en/insights/european-commission-publishes-draft-guidance-reporting-serious-ai-incidents (analiza szerokiej interpretacji związku przyczynowego, ulgi w postaci równoważnego zgłaszania dla sektorów NIS2 i dopasowania do procesów zgłaszania naruszeń RODO)
• Latham & Watkins, "EU AI Act: Obligations for Deployers of High-Risk AI Systems" · https://www.lw.com/en/insights/eu-ai-act-obligations-for-deployers-of-high-risk-ai-systems (obowiązki po stronie deployera, w tym eskalacja incydentów na mocy artykułu 26)
• Hunton, "EU Digital Omnibus Introduces a Single Reporting Point for Cybersecurity Incidents" · https://www.hunton.com/privacy-and-cybersecurity-law-blog/eu-digital-omnibus-introduces-a-single-reporting-point-for-cybersecurity-incidents (proponowany pojedynczy punkt wejścia kierujący zgłoszenia do NIS2, RODO, DORA, eIDAS i CER)
• White & Case, "EU Digital Omnibus: What changes lie ahead for the Data Act, GDPR and AI Act" · https://www.whitecase.com/insight-alert/eu-digital-omnibus-what-changes-lie-ahead-data-act-gdpr-and-ai-act (Digital Omnibus opublikowany 19 listopada 2025 jako propozycja zmieniająca AI Act, RODO i Data Act)
• Kennedys, "Comparative Overview of Reporting Requirements under EU Data Protection and Cybersecurity Laws" · https://www.kennedyslaw.com/en/thought-leadership/article/2025/comparative-overview-of-reporting-requirements-under-eu-data-protection-and-cybersecurity-laws/ (równoległe zegary zgłoszeniowe: 72 godziny RODO, 24 godziny NIS2 i DORA)