Rejestrowanie i przechowywanie: praktyczny przewodnik dla zespołów SaaS

W AI Act rejestrowanie i przechowywanie to mechanizmy identyfikowalności, a nie polecenie bezterminowego zbierania każdego możliwego punktu danych. W przypadku systemów AI wysokiego ryzyka art. 12 wymaga technicznej możliwości automatycznego rejestrowania zdarzeń przez cały cykl życia. Dostawcy i podmioty stosujące muszą przechowywać automatyczne logi pod swoją kontrolą przez okres odpowiedni do celu systemu, zasadniczo co najmniej sześć miesięcy, chyba że inne prawo stanowi inaczej.

Obowiązki te nie dotyczą automatycznie każdej funkcji AI ani firmy SaaS. Najpierw trzeba określić system, jego zamierzony cel, własną rolę i klasyfikację wysokiego ryzyka, a także odróżnić logi dostawcy od danych kontrolowanych przez klienta lub dostawcę wyższego szczebla. Celem jest proporcjonalny łańcuch dowodowy, dzięki któremu uprawniony recenzent połączy istotne zdarzenie z wersją systemu, kontekstem wejścia i wyjścia, działaniem człowieka, kontrolą i decyzją.

Nawet zanim wymogi wysokiego ryzyka zaczną obowiązywać, ta dyscyplina pomaga badać incydenty, monitorować bezpieczeństwo, odpowiadać klientom, zarządzać zmianami i uzasadniać decyzje produktowe. Nie chodzi o masową obserwację, lecz o celowe logowanie z określonymi celami, dostępem, wyzwalaczami i limitami.

Zacznij od zakresu, nie od platformy

Udokumentuj funkcję produktu, modele i usługi zewnętrzne, cel, użytkowników, osoby dotknięte działaniem, wejścia, wyjścia, integracje, środowiska i decyzje. Sam log wywołania API modelu bazowego może pominąć dane retrieval, reguły biznesowe, interwencje użytkownika lub działania dalsze, które tworzą pełny przepływ SaaS.

Następnie ustal rolę. Firma rozwijająca lub sprzedająca system wysokiego ryzyka pod własną nazwą może być dostawcą; klient korzystający z cudzego systemu może być podmiotem stosującym. Rebranding, istotna modyfikacja lub zmiana celu mogą przesunąć obowiązki. Nazwy w umowie nie rozstrzygają analizy.

Oceń klasyfikację. Art. 6 obejmuje systemy powiązane z produktami z załącznika I i przypadki z załącznika III, z uwzględnieniem warunków i wyłączeń. Ranking kandydatów wymaga innej analizy niż redagowanie wewnętrznego marketingu. Zapisz uzasadnienie, recenzenta, datę, założenia i wyzwalacze. Zobacz też jak AI governance zmienia oczekiwania compliance.

Czego wymaga AI Act

Zgodnie z AI Act, art. 12 wymaga automatycznego rejestrowania zdarzeń w cyklu życia. Funkcje mają zapewniać identyfikowalność odpowiednią do celu, pomagać wykrywać ryzyko lub istotne modyfikacje, wspierać monitorowanie po wprowadzeniu do obrotu i umożliwiać podmiotom stosującym nadzór nad działaniem.

Konkretne zdarzenia zależą od systemu. Dla niektórych systemów zdalnej identyfikacji biometrycznej z załącznika III art. 12 określa dodatkowe minimum. Skopiowanie specjalistycznego schematu do innego produktu nie dowodzi zgodności. Zdarzenia należy wywieść z celu, ryzyk, limitów wydajności, nadzoru człowieka, instrukcji i planu monitorowania.

Art. 19 wymaga od dostawców przechowywania automatycznych logów pod ich kontrolą przez odpowiedni okres co najmniej sześciu miesięcy, chyba że prawo UE lub krajowe, zwłaszcza ochrona danych, stanowi inaczej. Art. 26 wprowadza równoległe minimum dla podmiotów stosujących. Nie jest to zgoda na bezterminową retencję. Harmonogram musi łączyć identyfikowalność z minimalizacją, ograniczeniem przechowywania, bezpieczeństwem, prawem pracy, wymogami sektorowymi, umowami i potrzebami incydentowymi.

Po rozporządzeniu (UE) 2026/1744 wymogi obowiązują od 2 grudnia 2027 r. dla załącznika III i od 2 sierpnia 2028 r. dla systemów w produktach regulowanych z załącznika I. Harmonogram Komisji potwierdza te daty.

Co rejestrować

Przydatne zdarzenie odpowiada na pytanie kontrolne, a nie tylko potwierdza działanie serwera:

1. System i wersja: stabilny identyfikator, model lub komponent, konfiguracja, środowisko i release.
2. Czas i korelacja: wiarygodny znacznik czasu, identyfikator żądania lub transakcji i łącza między zdarzeniami.
3. Kontekst operacyjny: funkcja, zamierzony przepływ, rola użytkownika lub usługi i istotne ustawienia.
4. Wejście i wyjście: odwołania, skróty, podsumowania lub chronione migawki wystarczające do uzasadnionej rekonstrukcji.
5. Nadzór człowieka: przegląd, zatwierdzenie, odrzucenie, override, eskalacja i uprawnienie.
6. Kontrole: reguły, progi, filtry, decyzje dostępu, błędy, fallback i wynik.
7. Zmiany i monitoring: wdrożenia, zmiany modeli lub danych, drift, incydenty, skargi i korekty.
8. Integralność: źródło, historia dostępu, status zachowania i przekształcenie lub usunięcie.

Nie zapisuj automatycznie pełnych promptów, dokumentów, odpowiedzi ani tożsamości. Czasem treść jest konieczna do zbadania szkody; w innych sytuacjach wystarczy pseudonimowy identyfikator, hash, kategoria, metryka lub chroniona próbka. Decyduj pole po polu na podstawie celu i ryzyka.

Praktyczny proces

1. Sformalizuj decyzję

Dla każdego systemu zapisz zakres, cel, rolę, klasyfikację, obowiązki, cele monitoringu, kategorie danych i właścicieli. Oddziel logi własne od zależnych od klienta lub dostawcy. Wskaż założenia i wyzwalacze.

2. Połącz pytania ze zdarzeniami

Zacznij od pytań: która wersja dała wynik? Czy przegląd człowieka był wymagany i wykonany? Czy uruchomiła się kontrola? Czy użycie mieściło się w celu? Co zmieniło się przed pogorszeniem? Przypisz minimalne wiarygodne pola i źródła.

3. Rozdziel odpowiedzialność

Engineering zwykle odpowiada za instrumentację; security za dostęp, integralność, alerty i zachowanie; product za przepływ i wydania; data/ML za identyfikatory modeli, zbiorów i ocen; privacy za legalność i minimalizację; compliance za mapę wymogów. Jeden owner koordynuje, nie wymyślając faktów za innych.

4. Ustal dostęp i retencję

Oddziel dostęp operacyjny od dochodzeniowego. Stosuj minimalne uprawnienia, uwierzytelnienie, rejestr dostępu, szyfrowanie i kontrolę eksportu. Zdefiniuj początek okresu, usunięcie, wyjątki, blokady i kopie zapasowe oraz odpowiedzialność dostawcy i podmiotu stosującego.

5. Powiąż przeglądy z wyzwalaczami

Oceniaj ponownie po zmianie modelu, promptu, retrieval, progu, danych, integracji, celu lub nadzoru, a także po incydencie, skardze, nietypowej wydajności, niedozwolonym użyciu lub informacji od dostawcy. Połącz wynik z wersją produkcyjną.

6. Testuj rekonstrukcję i usuwanie

Poproś niezależnego recenzenta o odtworzenie wersji, kontroli, działań człowieka i reakcji. Następnie sprawdź usunięcie z głównego magazynu, analityki, eksportów i kopii. Oba procesy wymagają dowodów.

Typowe błędy

Logowanie wszystkiego. Więcej danych zwiększa ryzyko prywatności, bezpieczeństwa, sporów i kosztów bez poprawy identyfikowalności.

Mylenie telemetrii ze ścieżką audytu AI. Uptime i błędy rzadko wskazują model, konfigurację, nadzór i dowód wyniku.

Sześć miesięcy dla każdego rekordu. Minimum dotyczy automatycznych logów wysokiego ryzyka pod kontrolą operatora i podlega innemu prawu.

Ignorowanie granic kontroli. Dostawca nie zachowa logów, których nie otrzymuje; podmiot stosujący nie powinien zakładać, że vendor zachowa potrzebny kontekst.

Zbieranie treści wrażliwych bez zabezpieczeń. Prompty i wyniki mogą zawierać dane lub tajemnice. Minimalizuj, oddzielaj, szyfruj i monitoruj.

Przechowywanie niezrozumiałych zdarzeń. Bez schematu, czasu, wersji lub korelacji mogą być bezużyteczne.

Przykład: rekrutacja wspierana przez AI

Dostawca SaaS klasyfikuje aplikacje. Dokumentuje cel, granice, rolę i klasyfikację. Zdarzenia łączą model i konfigurację produkcyjną z rankingiem, odwołaniami do wejść, wynikiem i kontekstem, progami, ostrzeżeniami, przeglądem człowieka, zmianą decyzji i akcją końcową.

Dostęp do treści jest ograniczony do uprawnionych dochodzeń; rutynowy monitoring korzysta z agregatów. Decyzja retencyjna wyjaśnia art. 19, ograniczenia danych, odpowiedzialność klienta i okresy sektorowe. Zmiana modelu, progu lub przeglądu uruchamia ocenę i zachowuje powiązanie dowodów.

Projekt sam nie gwarantuje zgodności, ale pozwala sprawdzić działanie, nadzór człowieka i odpowiedzialną reakcję na zmiany oraz incydenty.

FAQ

Jaki jest praktyczny cel?

Zapewnienie identyfikowalności istotnej aktywności przez połączenie zdarzenia, wersji, kontekstu, kontroli, działań człowieka i reakcji bez zbędnych danych.

Kiedy obowiązki dotyczą zespołu SaaS?

Art. 12, 19 i 26 dotyczą systemów wysokiego ryzyka i dzielą wymogi według roli i kontroli. Potwierdź system, cel, klasyfikację i rolę.

Czy trzeba zachować każdy prompt i wynik?

Nie. Odpowiednia identyfikowalność nie oznacza masowej retencji. Wybierz potrzebne pola i chroń je.

Jak długo przechowywać logi?

Automatyczne logi wysokiego ryzyka pod kontrolą dostawcy lub podmiotu stosującego należy zasadniczo przechowywać odpowiednio i co najmniej sześć miesięcy. Inne prawo może wymagać lub ograniczać inny okres.

Od czego zacząć?

Zinwentaryzuj system, rolę, klasyfikację, źródła i pytania, a następnie zdefiniuj schemat, właścicieli, dostęp, retencję, wyzwalacze i test rekonstrukcji.

Źródła

• Rozporządzenie (UE) 2024/1689, zwłaszcza art. 6, 12, 19 i 26.
• Rozporządzenie (UE) 2026/1744 i zmienione daty.
• Komisja Europejska, „AI Act”, harmonogram i obowiązki wysokiego ryzyka.