Kiedy rejestrowanie i przechowywanie mają zastosowanie i co dalej

Rejestrowanie i przechowywanie nie dotyczą każdej funkcji SaaS jednakowo. Szczególne obowiązki z art. 12, 19 i 26 AI Act dotyczą systemów AI wysokiego ryzyka i zależą od tego, czy organizacja jest dostawcą czy podmiotem stosującym oraz jakie logi kontroluje. Inne systemy mogą wymagać zapisów dla bezpieczeństwa, prywatności, umów, jakości lub incydentów, lecz nie należy mylić tych powodów z obowiązkami wysokiego ryzyka.

Zacznij od zakresu: systemu, zamierzonego celu, procesu, roli, klasyfikacji i pytań dowodowych. Potem zapisuj tylko zdarzenia i decyzje potrzebne do identyfikowalności, monitorowania, nadzoru i dochodzeń. Zabezpiecz je, uzasadnij retencję i sprawdź, czy upoważniona osoba potrafi odtworzyć istotne zdarzenie.

Czego wymaga AI Act

Art. 12 wymaga, by system wysokiego ryzyka technicznie umożliwiał automatyczne rejestrowanie zdarzeń w całym cyklu życia. Ma to zapewnić identyfikowalność odpowiednią do celu, wykrywanie ryzyka lub istotnych zmian oraz wesprzeć monitorowanie po wprowadzeniu do obrotu i nadzór operacyjny.

Dla dostawcy jest to wymóg projektowy. Art. 19 nakazuje mu przechowywać automatyczne logi pod jego kontrolą; art. 26 nakłada analogiczny obowiązek na podmiot stosujący. Zasadnicze minimum to sześć miesięcy, chyba że inne prawo stanowi inaczej, a okres musi odpowiadać celowi. Osobno dostawca przechowuje określoną dokumentację techniczną, jakościową i zgodności przez dziesięć lat.

Nie istnieje jeden schemat. Art. 12 podaje minimum dla wybranych systemów biometrycznych, a w innych przypadkach projekt ma być proporcjonalny. Przewodnik AI Act dla dostawców SaaS omawia role i klasyfikację.

Kiedy obowiązki mają zastosowanie

Odpowiedz na cztery pytania: czy funkcja spełnia definicję systemu AI; czy jest wysokiego ryzyka według art. 6 oraz załącznika I lub III; jaką rolę ma firma; jakie logi rzeczywiście kontroluje? Zwykłe reguły i automatyzacja nie stają się AI tylko dlatego, że przetwarzają dane. Znaczenie mają zamierzony cel i wyjątki.

Firma rozwijająca i oferująca system pod własną nazwą może być dostawcą; używająca cudzego systemu pod własną kontrolą może być podmiotem stosującym. Nowy cel, rebranding lub istotna zmiana mogą zmienić analizę. Dostawca i klient często kontrolują różne części łańcucha dowodowego.

Zmiana z 2026 r. ustaliła daty na 2 grudnia 2027 r. dla art. 6 ust. 2 i załącznika III oraz 2 sierpnia 2028 r. dla art. 6 ust. 1 i załącznika I. Brakujących danych historycznych nie da się później odtworzyć.

Kiedy inne zapisy nadal są potrzebne

Poza wysokim ryzykiem można potrzebować zdarzeń uwierzytelniania, konfiguracji i incydentów; dowodów zgody, wniosków, dostępu lub usunięcia; historii usług i zmian; wersji, ocen, zatwierdzeń i rollbacku. Dla każdej klasy wskaż rzeczywisty cel prawny, umowny, bezpieczeństwa lub operacyjny.

„Nie jest wysokiego ryzyka” nie znaczy „niczego nie przechowywać”, lecz AI Act nie uzasadnia też bezterminowego gromadzenia promptów, dokumentów, wyników i tożsamości. Czasem wystarczy identyfikator, zabezpieczone odwołanie, hash, ustrukturyzowany wynik lub próbka.

Praktyczny proces

1. Opisz cel, użytkowników, osoby, decyzję, wejścia, wyjścia, środowiska, integracje, modele, źródła, dalsze działania i przegląd człowieka.
2. Zapisz rolę, klasyfikację, fakty, osobę oceniającą, zatwierdzenie, niepewności i wyzwalacze ponownej oceny. Dla dostawców użyj pytań przed wdrożeniem wewnętrznych narzędzi AI.
3. Zdefiniuj pytania: która wersja utworzyła wynik, jakie źródła i kontrole wykorzystano, czy nastąpił przegląd człowieka i jakie było dalsze działanie?
4. Powiąż pytania z minimalnymi zapisami: identyfikatorem, wiarygodnym czasem, wersjami, kontekstem, odwołaniami wejścia i wyjścia, wynikiem kontroli, działaniem człowieka, rezultatem i integralnością.
5. Wskaż właściciela całości oraz właścicieli instrumentacji, dostępu, prywatności, wniosków dowodowych, wyjątków, usuwania i napraw. Stosuj silne uwierzytelnianie, szyfrowanie, ograniczenia eksportu i monitoring.
6. Ustal okresy per klasa i osobno przetestuj rekonstrukcję oraz usuwanie w produkcji, analityce, eksportach, archiwach i właściwych backupach.

Błędy i następny krok

Zwykła telemetria nie jest automatycznie ścieżką audytu: dostępność i opóźnienia rzadko wyjaśniają konfigurację, kontrole i działania człowieka. Jedna strona nie zawsze kontroluje cały łańcuch; umowy, dokumentacja i rzeczywista konfiguracja muszą się zgadzać. Nie stosuj sześciu miesięcy do wszystkiego i nie projektuj wyłącznie pod audyt. Oceniaj ponownie przy wydaniach, zmianach dostawcy, ryzykach i incydentach. Zobacz typowe błędy rejestrowania.

Wybierz ważny proces i utwórz kartę z granicą, celem, rolą, klasyfikacją, źródłami, pytaniami, właścicielami i wyzwalaczami. Powiąż pięć–dziesięć pytań z minimalnymi zapisami i przed wydaniem przeprowadź niezależny test rekonstrukcji. Podejście odpowiada zmieniającym się oczekiwaniom AI governance i kontrolom wymaganym przez kupujących.

FAQ

Czy dotyczy to każdej funkcji AI?

Nie. Omówione artykuły dotyczą systemów wysokiego ryzyka; inne cele mogą jednak wymagać zapisów.

Czy dostawca i podmiot stosujący przechowują te same logi?

Niekoniecznie. Każdy zachowuje właściwe automatyczne logi pod własną kontrolą.

Czy sześć miesięcy jest zawsze właściwe?

Nie. To ogólne minimum dla właściwych logów wysokiego ryzyka, z zastrzeżeniem innego prawa. Inne klasy mogą mieć inne okresy.

Źródła

• Rozporządzenie (UE) 2024/1689, art. 12, 18, 19 i 26.
• Rozporządzenie (UE) 2026/1744 w sprawie nowych dat.
• Komisja Europejska, „AI Act”, bieżący harmonogram.