Jako prawnik doradzający firmom technologicznym w zakresie legalności oprogramowania wiem, że nawet najlepiej zaprojektowane algorytmy mogą zawodzić. Sytuacja, w której system sztucznej inteligencji prowadzi do poważnego incydentu, oznacza dla dostawcy konieczność szybkiego działania w warunkach wysokiej odpowiedzialności. Dlatego kluczowe znaczenie ma ustalenie, kiedy powstaje obowiązek zgłoszenia takiego zdarzenia oraz jakie procedury uruchamiają wówczas przepisy europejskie. Artykuł 73 rozporządzenia w sprawie sztucznej inteligencji (AI Act) ustanawia zasady raportowania poważnych incydentów do organów nadzoru rynku. Istotne znaczenie ma przy tym zarówno prawidłowe obliczanie ustawowych terminów, jak i zachowanie integralności materiału dowodowego. Równie ważne pozostaje przygotowanie się na działania następcze, których może zażądać właściwy organ wobec dostawcy.
Spis treści
Kiedy powstaje obowiązek zgłoszenia poważnego incydentu
W świetle art. 73 Aktu o AI obowiązek zgłoszenia nie powstaje dopiero wtedy, gdy dostawca dysponuje pełnym potwierdzeniem technicznej przyczyny błędu. Przeciwnie, oczekiwanie na definitywne wyniki wewnętrznego postępowania wyjaśniającego może prowadzić do naruszenia obowiązków regulacyjnych. Zgłoszenie staje się wymagalne już w chwili ustalenia związku przyczynowego między systemem AI a poważnym incydentem albo dostatecznie wysokiego prawdopodobieństwa istnienia takiego związku. Jeżeli monitoring po wprowadzeniu systemu do obrotu wskazuje, że oprogramowanie mogło przyczynić się do naruszenia, dostawca powinien niezwłocznie uruchomić procedurę raportową. Odkładanie zawiadomienia do czasu zakończenia analiz inżynieryjnych zwiększa ryzyko naruszenia ustawowych terminów i może skutkować odpowiedzialnością regulacyjną.
Jakie terminy na zgłoszenie incydentu przewiduje AI Act
Zarządzanie incydentem wymaga dyscypliny w pilnowaniu ustawowych terminów, które uzależnione zostały od wagi danego zdarzenia. Czas na reakcję liczy się od dnia, w którym dostawca albo podmiot stosujący dowiedzieli się o wystąpieniu incydentu. Zgodnie z omawianym przepisem, ramy czasowe na formalne zgłoszenie do organu nadzoru rynku wyglądają następująco:
- Termin 15 dni (Standardowy): Jest to maksymalny czas na zgłoszenie zwykłego poważnego incydentu, choć ustawa i tak nakazuje działanie natychmiastowe po ustaleniu prawdopodobieństwa błędu.
- Termin 10 dni (Śmierć człowieka): W skrajnym przypadku, gdy dochodzi do śmierci człowieka, a system AI mógł mieć na to wpływ (np. błąd oprogramowania medycznego), czas na reakcję zostaje istotnie skrócony.
- Termin 2 dni (Powszechne naruszenie): W sytuacjach krytycznych, takich jak powszechne naruszenie praw obywatelskich na dużą skalę, zgłoszenia trzeba dokonać natychmiast, nie później niż w ciągu 48 godzin od uzyskania informacji.
Jak działa zgłoszenie wstępne w AI Act
Przy tak krótkich terminach zebranie pełnej dokumentacji technicznej awarii bywa obiektywnie niemożliwe. Prawodawca przewidział jednak ten problem i w art. 73 rozporządzenia wprowadził instytucję tak zwanego zgłoszenia wstępnego. Jeżeli wymaga tego sytuacja i brakuje czasu, dostawca ma pełne prawo złożyć do urzędu niekompletny raport, sygnalizując jedynie wystąpienie poważnego problemu. Takie działanie pozwala dotrzymać terminów ustawowych i otwiera drogę do późniejszego dosłania pełnego zgłoszenia wraz z techniczną analizą. Znacznie bezpieczniej jest wysłać niepełne pismo w terminie, niż spóźnić się z dopracowanym i idealnym raportem.
Integralność systemu po incydencie
Naturalnym odruchem każdego zespołu programistów po wykryciu krytycznego błędu jest natychmiastowe wdrożenie poprawki, aby ograniczyć dalsze straty po stronie klientów. Trzeba jednak bardzo wyraźnie podkreślić, że art. 73 ust. 6 rozporządzenia zakazuje wprowadzania zmian w systemie w trakcie śledztwa bez wiedzy właściwych organów. Podejmowanie na własną rękę działań modyfikujących kod w sposób, który mógłby wpłynąć na późniejszą ocenę przyczyn incydentu, jest traktowane przez prawo jako zacieranie śladów. Algorytm w środowisku, w którym doszło do awarii, musi zostać w niezmienionej formie na potrzeby analizy. Każda ingerencja w podstawową architekturę modelu w toku postępowania wyjaśniającego wymaga wcześniejszego poinformowania o tym właściwego organu nadzoru. Naruszenie tego zakazu podważa zaufanie do dostawcy i może skutkować nakazem wycofania produktu z rynku unijnego.
Działania następcze i współpraca z jednostką notyfikowaną
Samo wysłanie urzędowego zgłoszenia incydentu to dopiero początek procesu naprawczego, który czeka organizację. Po dokonaniu zgłoszenia dostawca ma obowiązek niezwłocznie przeprowadzić postępowanie wyjaśniające. Proces ten musi zakończyć się udokumentowaną oceną zaistniałego ryzyka oraz wdrożeniem konkretnych działań naprawczych, o których mowa w przepisach dotyczących compliance. Co bardzo istotne, jeżeli Twój system wysokiego ryzyka był wcześniej certyfikowany przez podmiot zewnętrzny, w postępowanie musi zostać włączona właściwa jednostka notyfikowana. Współpraca z audytorem, który pierwotnie dopuścił produkt do obrotu, jest konieczna do sprawdzenia, czy wdrożone poprawki spełniają europejskie normy jakościowe.
