Nadzór Posprzedażowy EU AI Act (Art. 72): Obowiązki dla Dostawców AI Wysokiego Ryzyka

Zgodność nie kończy się w momencie wejścia na rynek. Art. 72 wymaga od dostawców systemów AI wysokiego ryzyka utrzymywania aktywnego systemu nadzoru posprzedażowego, zbierania danych o wydajności i zgłaszania poważnych incydentów. Oto, co musisz robić — i kiedy.

Co to jest Nadzór Posprzedażowy?

Ocena zgodności i oznakowanie CE to bilet wstępu na rynek UE dla systemu AI wysokiego ryzyka — a nie linia mety. Art. 72 EU AI Act nakłada ciągły obowiązek: dostawcy muszą ustanowić i prowadzić system nadzoru posprzedażowego (PMM), który aktywnie zbiera, analizuje i działa na podstawie danych o rzeczywistej wydajności przez cały operacyjny czas życia systemu.

Uzasadnienie jest proste. System AI zwalidowany na stałym zestawie danych może driftować, gdy rzeczywiste dane wejściowe zmieniają się, gdy populacja użytkowników zmienia się lub gdy środowisko, w którym działa, ewoluuje. Statyczne migawki zgodności nie mogą tego uchwycić. PMM to mechanizm, który przekształca zgodność w ciągły proces, a nie jednorazowe zdarzenie.

System PMM musi być proporcjonalny do charakteru i ryzyk danego systemu AI wysokiego ryzyka. Model scoringu kredytowego wdrożony na dużą skalę u milionów konsumentów będzie wymagał intensywniejszego monitorowania niż wąskie narzędzie do klasyfikacji dokumentów używane wewnętrznie przez regulowaną firmę.

Kto Musi Ustanowić System PMM?

Obowiązkowe dla:

• Dostawców samodzielnych systemów AI wysokiego ryzyka Annex III — systemów wymienionych w Annex III, które nie są składnikami bezpieczeństwa produktu (np. AI stosowany do decyzji o zatrudnieniu, dostępie do edukacji, egzekwowaniu prawa, ocenie zdolności kredytowej, zarządzaniu infrastrukturą krytyczną)
• Dostawców systemów AI wbudowanych w produkty Annex I — składniki bezpieczeństwa AI zintegrowane w produktach objętych istniejącym unijnym prawodawstwem harmonizacyjnym (wyroby medyczne, maszyny, pojazdy)

Nie wymagane dla:

• Dostawców systemów AI minimalnego ryzyka (brak formalnego obowiązku PMM, choć dobre praktyki mają zastosowanie)
• Dostawców systemów AI wyłącznie przejrzystości (obowiązki Art. 50 nie rozciągają się na PMM)
• Dostawców modeli GPAI — podlegają one oddzielnemu reżimowi na podstawie Art. 61–62, który obejmuje zgłaszanie incydentów dla modeli o ryzyku systemowym, ale jest inaczej skonstruowany niż PMM Art. 72

Rola podmiotu wdrażającego jest wspierająca, ale nie opcjonalna. Podmioty wdrażające muszą obsługiwać system AI zgodnie z instrukcjami dostawcy, aktywować i przechowywać wbudowaną w system funkcjonalność rejestrowania oraz — co kluczowe — zgłaszać wszelkie poważne incydenty, o których się dowiedzą, dostawcy bez zbędnej zwłoki. Podmiot wdrażający, który obserwuje poważny incydent i nie powiadamia dostawcy, nie jest w zgodności.

Plan Nadzoru Posprzedażowego (Annex IV, Pkt 12)

Plan PMM to obowiązkowy składnik dokumentacji technicznej (Annex IV). Nie może być dokumentem ogólnym: musi być specyficzny dla systemu, jego kontekstu wdrożenia i zidentyfikowanych ryzyk. Co najmniej musi definiować:

1. Zbieranie danych — jakie metryki wydajności są przechwytywane (dokładność, wskaźniki błędów, wyniki decyzji), jak dane są zbierane (automatyczna telemetria, raporty podmiotów wdrażających, opinie użytkowników) i z jaką częstotliwością
2. Pętle informacji zwrotnej — mechanizm, za pomocą którego podmioty wdrażające mogą zgłaszać problemy z wydajnością, anomalie lub incydenty z powrotem do dostawcy w sposób ustrukturyzowany i terminowy
3. Monitorowanie dokładności — jak wydajność systemu jest śledzona w stosunku do zwalidowanego benchmarku użytego podczas oceny zgodności, w tym ewentualna metodologia wykrywania dryftu
4. Monitorowanie uprzedzeń — dla systemów, w których wyniki demograficzne są istotne (zatrudnienie, kredyt, egzekwowanie prawa), bieżące monitorowanie statystycznych dysproporcji w chronionych grupach, z zdefiniowaną metodologią i progami
5. Progi uruchamiające aktualizacje — konkretne ilościowe lub jakościowe progi, które skłaniają do działań naprawczych, w tym ponownego trenowania modelu, dostosowania parametrów lub zawieszenia wdrożenia
6. Harmonogram przeglądów — jak często sam plan PMM jest przeglądany i aktualizowany, zapewniając, że pozostaje odpowiedni w miarę ewolucji kontekstu wdrożenia

Plan PMM musi być aktualizowany. Nieaktualne plany, które nie odzwierciedlają już rzeczywistej metodologii monitorowania, nie spełniają Art. 72.

Zgłaszanie Poważnych Incydentów (Art. 73)

Co stanowi poważny incydent?

Art. 73 definiuje poważny incydent jako każdy incydent lub awarię systemu AI wysokiego ryzyka bezpośrednio lub pośrednio prowadzącą do:

• Śmierci lub poważnej szkody dla zdrowia (fizycznej lub psychologicznej)
• Poważnego i nieodwracalnego zakłócenia w zarządzaniu lub eksploatacji infrastruktury krytycznej
• Poważnego naruszenia praw podstawowych (prywatność, niedyskryminacja, należyty proces)
• Sytuacji, w której osoba prawie uniknęła któregokolwiek z powyższych

Co ważne, EU AI Act nie wymaga ustalenia związku przyczynowego z systemem AI przed zgłoszeniem. Wystarczy uzasadnione podejrzenie, że system AI przyczynił się do szkody lub nie zapobiegł jej. Dostawcy, którzy czekają na pewność przed zgłoszeniem, ryzykują niezgodność.

Harmonogramy sprawozdawcze

15-dniowy zegar zaczyna biec, gdy dostawca powziął wiadomość o incydencie — co w praktyce oznacza, gdy podmiot wdrażający go powiadomi. Dostawcy powinni projektować swoje procedury powiadamiania podmiotów wdrażających tak, aby informacje docierały do nich wystarczająco szybko, aby spełnić termin sprawozdawczy niższego szczebla.

Co musi zawierać raport o incydencie

Kompletny raport o incydencie do krajowego organu nadzoru rynku powinien zawierać:

• Identyfikację systemu: nazwa, wersja, numer rejestracyjny w unijnej bazie danych AI
• Opis incydentu: co się wydarzyło, jaka szkoda wystąpiła lub prawie wystąpiła, data i miejsce
• Dotknięte osoby: liczba i kategorie dotkniętych użytkowników lub stron trzecich (zanonimizowane tam, gdzie wymagane przez RODO)
• Wstępna analiza przyczynowa: aktualne rozumienie przez dostawcę, jak incydent powstał, wyraźnie oznaczone jako wstępne
• Podjęte natychmiastowe środki naprawcze lub bezpieczeństwa: wszelkie już podjęte kroki w celu ograniczenia dalszych szkód lub ryzyk (np. zawieszenie dotkniętej funkcjonalności, powiadomienia podmiotów wdrażających)
• Punkt kontaktowy: osoba lub zespół odpowiedzialny za korespondencję uzupełniającą z organem

Raport powinien być faktyczny i proporcjonalny. Raporty wstępne mogą być uzupełnione raportami uzupełniającymi w miarę postępu dochodzenia.

Obowiązkowe Rejestrowanie (Art. 12)

Art. 12 wymaga, aby systemy AI wysokiego ryzyka były projektowane i budowane z możliwością automatycznego generowania logów na poziomie szczegółowości wystarczającym do:

• Nadzoru posprzedażowego zgodnie z Art. 72
• Śledzenia zdarzeń prowadzących do poważnego incydentu
• Dochodzenia przez organy krajowe

Jest to wymóg projektowy nałożony na dostawcę. Dostawca musi wbudować możliwość rejestrowania w system przed jego wprowadzeniem do obrotu.

Obowiązek aktywowania i przechowywania tych logów spada na podmiot wdrażający. Podmioty wdrażające nie mogą wyłączać funkcjonalności rejestrowania i muszą przechowywać logi przez okres określony w instrukcjach dostawcy i dokumentacji technicznej. Gdzie nie zdefiniowano konkretnego okresu przechowywania, logi powinny być przechowywane przez okres adekwatny do operacyjnego cyklu życia systemu i wszelkich wymogów sektorowych dotyczących prowadzenia dokumentacji (np. zasady prowadzenia dokumentacji usług finansowych na podstawie DORA lub MiFID II).

Istotne Modyfikacje i Ponowna Ocena

Nie każda zmiana wdrożonego systemu AI uruchamia nową ocenę zgodności. Rozporządzenie rozróżnia między drobnymi aktualizacjami a istotnymi modyfikacjami.

Modyfikacja jest istotna — i wymaga nowej oceny zgodności i zaktualizowanej dokumentacji technicznej — gdy:

• Zmienia zamierzone przeznaczenie systemu (nawet częściowo)
• Obejmuje znaczącą zmianę architektury lub metodologii trenowania
• Używa nowych danych do trenowania, które istotnie wpływają na wydajność systemu w sposób mogący wpłynąć na zachowanie istotne dla zgodności
• Pogarsza wydajność poniżej progów zdefiniowanych w dokumentacji zarządzania ryzykiem w sposób wpływający na bezpieczeństwo lub prawa podstawowe

Drobne aktualizacje — łatki bezpieczeństwa, poprawki błędów korygujące wyraźnie zidentyfikowane defekty bez zmiany zachowania istotnego dla zgodności, kosmetyczne zmiany interfejsu — nie wymagają pełnej ponownej oceny. Muszą jednak być udokumentowane, a dostawca musi zachować pisemną ocenę potwierdzającą, że modyfikacja nie stanowi istotnej modyfikacji. Zapis ten podlega inspekcji przez organy nadzoru rynku.

Praktyczna Lista Kontrolna Wdrożenia

Poniższa lista kontrolna odzwierciedla minimalne wymagania operacyjne na podstawie Art. 72, Art. 73 i Art. 12. Nie zastępuje porady prawnej, ale stanowi punkt wyjścia do analizy luk.

• [ ] Plan PMM udokumentowany w pliku technicznym (Annex IV, pkt 12), specyficzny dla systemu i jego kontekstu wdrożenia
• [ ] Automatyczna możliwość rejestrowania zaprojektowana i wbudowana w system przed wprowadzeniem do obrotu
• [ ] Instrukcje dla podmiotów wdrażających zawierają wyraźną, pisemną procedurę zgłaszania incydentów z kontaktem eskalacyjnym
• [ ] Wewnętrzny punkt kontaktowy ds. zgłaszania incydentów ustanowiony i zakomunikowany właściwemu krajowemu organowi nadzoru rynku
• [ ] Procesy lub pulpity monitorowania uprzedzeń i dokładności zdefiniowane, z udokumentowaną metodologią i progami
• [ ] Progi eskalacji dla działań naprawczych udokumentowane i powiązane z systemem zarządzania ryzykiem
• [ ] Procedura oceny istotnej modyfikacji na miejscu, z szablonem zapisu decyzji dla każdej aktualizacji
• [ ] Polityka przechowywania logów zdefiniowana, zakomunikowana podmiotom wdrażającym i zgodna z sektorowymi zasadami przechowywania

Odnośniki: Dokumentacja Techniczna — Systemy AI Wysokiego Ryzyka Annex III — Dostawcy a Podmioty Wdrażające