Typowe błędy w rejestrowaniu i przechowywaniu danych w zespołach SaaS

Najczęstsze błędy nie wynikają z braku danych. Pojawiają się, gdy zespół nie potrafi wyjaśnić, co rejestruje, dlaczego, kto kontroluje dane, jak długo są przechowywane i na jakie konkretne pytanie odpowiadają. Powstaje kosztowna telemetria zwiększająca ryzyko prywatności i bezpieczeństwa, ale nie tworząca wiarygodnej ścieżki audytowej AI.

Dla systemów AI wysokiego ryzyka art. 12 unijnego aktu o AI wymaga technicznej możliwości automatycznego rejestrowania zdarzeń w cyklu życia. Art. 19 i 26 wymagają od dostawców i podmiotów stosujących przechowywania automatycznych logów pod ich kontrolą przez odpowiedni okres, co do zasady co najmniej sześć miesięcy, chyba że inne prawo stanowi inaczej. Nie oznacza to, że każda funkcja SaaS jest wysokiego ryzyka ani że trzeba przechowywać każdy prompt i wynik.

Błąd 1: rozpoczęcie od platformy zamiast od zakresu

Włączenie wszystkich zdarzeń nie wyznacza granic systemu. Proces SaaS oparty na AI może obejmować interfejs, wyszukiwanie, reguły biznesowe, model zewnętrzny, akceptację człowieka i dalszą automatyzację. Samo logowanie wywołania modelu często pomija fakty wyjaśniające wynik.

Udokumentuj cel, użytkowników, osoby, wejścia, wyjścia, integracje, wersje, środowiska i decyzje. Następnie określ rolę firmy, klasyfikację, założenia i przesłanki ponownej oceny. Szerszy kontekst zawiera przewodnik po AI Act dla dostawców SaaS.

Błąd 2: domyślne rejestrowanie wszystkiego

Pełne prompty, dokumenty, wyniki i identyfikatory mogą zawierać dane osobowe, tajemnice klientów lub dane dostępowe. Nieograniczone gromadzenie zwiększa ryzyko dostępu, incydentu i usuwania oraz utrudnia odnalezienie ważnych zdarzeń.

Powiąż każde pole z pytaniem. Do ustalenia wersji potrzebne są stabilne identyfikatory. Do wykazania nadzoru człowieka zapisz wymóg, działanie, rolę, czas i wynik. Gdy wystarczy, użyj odwołania, skrótu, kategorii lub chronionego podsumowania zamiast pełnej treści.

Błąd 3: mylenie telemetrii ze ścieżką audytową

Logi aplikacyjne pokazują dostępność, opóźnienia i błędy, ale nie zawsze łączą istotny wynik z modelem, konfiguracją, źródłem, kontrolą, działaniem człowieka i wydaniem.

Użyteczna ścieżka koreluje cały proces: wersje, czas, identyfikator transakcji, kontekst, odwołania do wejścia i wyjścia, kontrole, ostrzeżenia, przegląd człowieka, dalszą akcję i status incydentu. Potrzebne są udokumentowane schematy, spójne zegary i jednoznaczne identyfikatory. Niezależny recenzent powinien odtworzyć wybrane zdarzenie.

Błąd 4: stosowanie sześciu miesięcy do wszystkich rekordów

Minimum sześciu miesięcy dotyczy automatycznych logów systemów wysokiego ryzyka pod kontrolą danego operatora. Nie jest to uniwersalny termin ani zgoda na bezterminowe przechowywanie wszystkich danych osobowych.

Harmonogram powinien określać klasę, początek okresu, datę usunięcia, cel, wyjątki, zgody, repliki, eksporty i kopie zapasowe. Pogódź identyfikowalność z minimalizacją, ograniczeniem przechowywania, bezpieczeństwem, prawem sektorowym i umowami. Testuj usuwanie także poza głównym panelem.

Błąd 5: ignorowanie granic kontroli

Dostawca, podmiot stosujący, klient i dostawca nadrzędny mogą kontrolować różne elementy. Przypisz każde zdarzenie stronie i systemowi, które je kontrolują. Umowy i dokumentacja powinny wyjaśniać tworzenie, dostęp, żądanie dowodów, retencję i zakończenie usługi. Weryfikuj rzeczywistą konfigurację, nie tylko kwestionariusz dostawcy.

Przed wdrożeniem użyj pytań dotyczących wewnętrznych narzędzi AI i uzgodnij odpowiedzi z kontrolami AI oczekiwanymi przez kupujących.

Błąd 6: niejawna odpowiedzialność

Product odpowiada za cel i proces; engineering za instrumentację i schemat; security za dostęp i integralność; privacy za minimalizację; compliance za mapę wymagań i standard dowodowy. Wyznacz jednego właściciela całości oraz osoby obsługujące wyjątki, dostęp, żądania dowodów, przedłużenie retencji, blokady i naprawę luk.

Błąd 7: niewystarczająca ochrona ścieżki

Logi mogą ujawniać aktywność użytkowników, decyzje wewnętrzne, treści klientów i słabości systemu. Stosuj minimalne uprawnienia, silne uwierzytelnianie, szyfrowanie, rejestrowanie dostępu, separację środowisk i kontrolę eksportu. Chroń integralność przez kontrolowane schematy, wiarygodne znaczniki czasu, śledzone przekształcenia i procedury zabezpieczenia. Oddziel zwykły dostęp od uprzywilejowanego dostępu dochodzeniowego.

Błąd 8: brak testu odtworzenia

Wybierz ważne zdarzenie i poproś niezależnego recenzenta o ustalenie wersji, kontekstu, kontroli, działania człowieka, dalszego wyniku i reakcji. Zapisz braki i przydziel naprawy. Powtarzaj po zmianach modelu, promptu, źródła, progu, integracji, nadzoru lub celu oraz po incydentach.

To podejście odpowiada nowym oczekiwaniom wobec AI governance: audytorzy chcą dowodu działania kontroli, nie tylko polityki.

Praktyczny proces naprawczy

Zacznij od jednego ważnego procesu. Udokumentuj zakres, cel, rolę, klasyfikację, źródła, dostawców i właścicieli. Wypisz prawdopodobne pytania i powiąż je z minimalnymi zdarzeniami. Oceń konieczność, wrażliwość, dostęp, integralność, retencję i usuwanie każdego pola. Przeprowadź test odtworzenia i usunięcia, a wyniki, luki, właścicieli i terminy przechowuj razem.

Według obecnego harmonogramu Komisji zasady wysokiego ryzyka dla systemów z załącznika III obowiązują od 2 grudnia 2027 r., a dla AI w produktach regulowanych z załącznika I od 2 sierpnia 2028 r.

FAQ

Jaki jest największy błąd?

Gromadzenie zdarzeń bez określenia systemu i pytań kontrolnych, co tworzy ilość bez wiarygodnej identyfikowalności.

Czy każda funkcja AI w SaaS wymaga tych logów?

Nie. Omówione art. 12, 19 i 26 dotyczą systemów wysokiego ryzyka i zależą od roli oraz kontroli. Inne przepisy, umowy lub kontrole mogą wymagać zapisów.

Czy trzeba zachować każdy prompt?

Nie. Dobierz proporcjonalne pola; mogą wystarczyć odwołania, hashe, kategorie, metryki lub chronione próbki.

Co udokumentować najpierw?

Granice, cel, rolę, klasyfikację, kontrolowane źródła, pytania, minimalny schemat, właściciela, dostęp i retencję.

Jak sprawdzić użyteczność?

Poproś osobę trzecią o odtworzenie zdarzenia i przetestuj usuwanie wygasłych danych ze wszystkich kopii.

Źródła

• Rozporządzenie (UE) 2024/1689, zwłaszcza art. 6, 12, 19 i 26.
• Rozporządzenie (UE) 2026/1744 dotyczące zmienionych dat stosowania.
• Komisja Europejska, „AI Act”, aktualny harmonogram wdrażania.