Polityka mówi „przechowujemy dane tylko tak długo, jak potrzeba”. Brzmi odpowiedzialnie i nie mówi nic. Źródło zostaje usunięte, ale odpowiedź nadal istnieje, cache pamięta cytat, a backup po restore przywraca wszystko. Retencja wymaga konkretnych terminów i procesu dla każdej warstwy.
Przy AI trzeba opisać źródło, wynik, indeks, logi, kopie i wyjątki. Nie każda kopia ma ten sam cel. Legal hold ogranicza dostęp, a nie otwiera nowego wyszukiwania przez agenta.
Zacznij od celu i kategorii
Zapisz, po co dane są przechowywane i jaka jest ich kategoria. Obsługa, publikacja, analiza, test, bezpieczeństwo i backup mają różne cele. Nie stosuj jednego terminu dla wszystkiego.
Opisz źródło, wynik, fragmenty, embeddingi, logi i eksporty. Nie przechowuj pełnych dokumentów w rejestrze. Wystarczy identyfikator, właściciel i proces.
Przy minimalizacji stosuj zasady z artykułu o RODO przy AI. Retencja powinna wynikać z celu i obowiązków, a nie z dostępnego miejsca.
Termin i sposób zakończenia
Zapisz datę lub regułę końca, sposób usunięcia i właściciela. „Na zawsze” wymaga wyjątkowego uzasadnienia. „Tymczasowo” nie jest retencją.
Rozróżnij usunięcie, archiwum, ograniczenie dostępu i zachowanie wymagane. Każdy stan ma inny test. Nie przedstawiaj archiwum jako usunięcia.
Przy procesie stosuj zasady z artykułu o retencji i automatyzacji AI. Operacje powinny obejmować wszystkie warstwy.
Pochodne i historia odpowiedzi
Oceń, jak długo przechowujesz odpowiedzi, podsumowania i historię konwersacji. Mogą zawierać najważniejsze informacje ze źródła. Nie traktuj ich jako mniej wrażliwych automatycznie.
Przy usunięciu źródła sprawdź, co zrobić z pochodnymi. Czasem trzeba usunąć całość, innym razem ograniczyć dostęp lub zachować wymagany dowód. Decyzja wymaga właściciela.
Nie przechowuj pełnych odpowiedzi w logach diagnostycznych bez potrzeby. Identyfikator i typ skutku wystarczą przy wielu procesach.
Backup i restore
Dla każdej kopii bezpieczeństwa ustal, kto może ją odtworzyć, jak długo jest przechowywana i które systemy obejmuje. Próbę przywrócenia wykonuj w oddzielnym środowisku, zanim dane ponownie trafią do pracy.
Jednym ze wzorców jest tombstone, czyli trwały znacznik usunięcia, oraz reguła blokująca przywrócenie obiektu do produkcji. Dobierz zakres i czas przechowywania identyfikatora do procesu, retencji i wymogów prawnych; znacznik nie może sam ujawniać zbędnych danych. Przywracanie powinno respektować decyzję o usunięciu. Stary eksport nie jest nowym źródłem pracy.
Test przywracania w środowisku kontrolowanym powinien sprawdzać odzyskanie dozwolonych danych i blokadę usuniętych. Taki test nie dowodzi usunięcia każdej kopii u wszystkich odbiorców.
Legal hold z ograniczeniem dostępu
Jeżeli zachowanie jest wymagane, zapisz podstawę, zakres, właściciela i koniec. Nie używaj legal hold jako powodu do dalszej analizy przez model. Przechowywanie i użycie są różne.
Oddziel kolekcję i role. Dokument może być zachowany bez wyszukiwania i odpowiedzi agenta. Test powinien potwierdzać odmowę przy każdej operacji niezgodnej z celem.
Po zakończeniu holdu przygotuj nową decyzję o retencji. Nie zostawiaj statusu bez daty przeglądu.
Dostawcy i kopie zewnętrzne
Sprawdź, jak dostawca rozróżnia usunięcie z widoku, dezaktywację i fizyczne usunięcie. Zapytaj o backup, logi, wsparcie i podwykonawców. Ogólna deklaracja nie wystarcza.
Przy zakończeniu umowy wykonaj eksport, odwołaj tokeny i zleć usunięcie zgodnie z procesem. Sprawdź, czy integracje nie przywracają danych. Stare konta nie powinny działać.
Przy umowie stosuj zasady z artykułu o dostawcy AI i wyjściu. Retencja powinna obejmować wszystkich odbiorców.
Żądanie usunięcia i wyjątki
Przy żądaniu ustal zakres, tożsamość zgodnie z procesem, systemy i wyjątki. Nie przesyłaj pełnej historii do modelu dla znalezienia danych. Mapa identyfikatorów powinna ograniczać pracę.
Zachowaj potwierdzenie wykonanych kroków bez usuniętej treści. Jeżeli część danych musi zostać, opisz powód i dostęp. Nie oznaczaj całości jako zakończonej przy samym źródle.
Przy błędzie usuwania przypisz właściciela i status. Nie raportuj sukcesu przed odbiorem.
Przykład: usunięty dokument w RAG
Dokument znika z repozytorium, ale odpowiedź nadal go cytuje. Indeks ma fragmenty, cache odpowiedź, a log zawiera tekst. Proces musi objąć każdą warstwę.
Najpierw zatrzymaj nowe pobieranie. Potem usuń pochodne i sprawdź wyszukiwanie charakterystycznej frazy. Zachowaj wymagane dowody z ograniczeniem, a nie jako źródło pracy.
Przy RAG stosuj zasady z artykułu o danych poufnych i uprawnieniach. Usuwanie i uprawnienia są powiązane, ale nie identyczne.
Przykład: restore po migracji
Migracja przywraca stary eksport z usuniętymi rekordami i tworzy je jako nowe. Retencja zostaje naruszona mimo poprawnego importu technicznego. Przed importem sprawdź tombstones.
Rozdziel dozwolone dane od usuniętych. Ogranicz przywracanie i zaktualizuj indeks. Test kończy się brakiem obiektów w systemie i wyszukiwaniu.
Nie przenoś wszystkiego dla kompletu migracji. Kompletność nie jest ważniejsza niż decyzja o usunięciu.
Test retencji przed wdrożeniem
Utwórz fikcyjny dokument z charakterystycznym znacznikiem. Zaindeksuj go, wygeneruj odpowiedź, usuń i spróbuj odnaleźć znacznik w każdej warstwie. Następnie wykonaj restore.
Sprawdź źródło, indeks, cache, logi, eksport i historię. Znacznik nie powinien wrócić do zwykłego użycia. Test powinien być powtarzalny przy nowych wersjach.
Zapisz wynik z datą i ograniczeniami. Nie przechowuj pełnego znacznika poufnego w raporcie publicznym.
Kiedy zatrzymać proces
Jeżeli nie wiadomo, gdzie są kopie objęte żądaniem usunięcia, wstrzymaj dalszy eksport i ustal zakres z właścicielem danych. Osobno wyjaśnij z osobą odpowiedzialną ewentualny obowiązek zachowania informacji przed podjęciem decyzji o kasowaniu.
Przy nowym dostawcy oceń usuwanie i backup przed eksportem. Nie przenoś starych reguł bez testu. Platforma może mieć inne kopie i terminy.
Przy większym procesie Aeneia Audit pomaga zmapować dane i odpowiedzialność. Aeneia Design pomaga opisać proces użytkownikowi.
Minimalna karta retencji
Zapisz kategorię, cel, źródło, pochodne, termin, sposób usunięcia, właściciela i test. Dodaj wyjątki i dostęp. Nie przechowuj treści usuniętego obiektu jako dowodu.
Przy każdej zmianie procesu zaktualizuj mapę i powtórz zależne testy. Nie przepisuj całej polityki bez nowego skutku. Karta powinna prowadzić do operacji.
Dobra retencja nie kończy się na przycisku delete. Zachowuje cele, ogranicza kopie i blokuje wskrzeszenie przy restore. Proces ma dowód i właściciela.
Retencja dla danych syntetycznych i testowych
Dane fikcyjne też powinny mieć koniec. Nie zostawiaj testowych klientów i dokumentów w produkcyjnym indeksie, bo mogą odpowiadać jako prawdziwe źródła. Oznacz status, właściciela i datę usunięcia.
Jeżeli dane syntetyczne powstają z produkcyjnych, oceń, czy nadal pozwalają na identyfikację. Zmiana nazwiska nie zawsze wystarcza. Retencja powinna obejmować oryginał, wersję syntetyczną i kopie.
Retencja logów i metryk
Oddziel logi bezpieczeństwa, diagnostykę, analitykę i pełne prompty. Każda kategoria ma inny cel i dostęp. Nie przechowuj treści tylko dlatego, że może przydać się przy nieznanym przyszłym problemie.
Zapisz, jakie identyfikatory są potrzebne do odtworzenia incydentu i jak długo. Przy końcu okresu usuń je zgodnie z procesem. Jeżeli log zawiera dane osobowe, stosuj tę samą ocenę minimalizacji co przy źródle, a nie specjalną zasadę „bo techniczne”.
Usuwanie przy małej firmie
Nie potrzebujesz wielkiego systemu retencji na start. Wypisz kilka kategorii, właścicieli i sposoby usuwania. Przypisz termin przeglądu i wykonaj jeden test od źródła do restore. Proces powinien być wykonalny przez osobę zastępującą.
Jeżeli nie wiesz, gdzie są kopie, zacznij od jednego procesu zamiast deklarować pełną mapę. Zaznacz niewiadome i właściciela sprawdzenia. Uczciwy ograniczony rejestr jest lepszy niż idealna tabela, która pomija połowę systemów.
Odbiór bez przechowywania usuniętej treści
Dowód usunięcia powinien zawierać identyfikator, datę, wynik i wersję, a nie pełny dokument. Możesz użyć skrótu lub bezpiecznego znacznika. Nie twórz archiwum usuniętych treści dla udowodnienia, że zostały usunięte.
Przy błędzie pokaż system i powód, nie cytat. Właściciel powinien móc ponowić operację bez pobierania danych ponownie. Odbiór powinien potwierdzać brak odpowiedzi i dostępu, a nie tylko status zadania.
Przegląd po zmianie celu
Nowa analiza lub kampania może zmieniać cel przetwarzania. Nie przenoś starego terminu automatycznie. Oceń, czy dane mogą być użyte i czy wymagają nowej decyzji lub podstawy.
Przy zakończeniu celu wykonaj zaplanowane operacje zamiast szukać nowego powodu do przechowywania. Jeżeli proces ma być zachowany jako archiwum, ogranicz dostęp i użycie. Retencja powinna reagować na decyzje biznesowe, a nie tylko na kalendarz.
Retencja przy pracy dla klienta
Zapisz, kto ustala termin i kto wykonuje operacje po zakończeniu projektu. Nie zostawiaj danych klienta na własnych kontach dla przyszłego portfolio. Eksport i usunięcie powinny odpowiadać umowie oraz procesowi.
Przy współdzielonych systemach ustal, która strona usuwa źródło i pochodne. Nie zakładaj, że druga strona wykona to automatycznie. Odbiór powinien obejmować obie konfiguracje i potwierdzenie bez poufnych treści.
Usuwanie podczas incydentu
Nie usuwaj automatycznie wszystkich logów przy wycieku. Zachowaj wymagane dowody z ograniczeniem dostępu i oceń legal hold. Jednocześnie zatrzymaj nowe przetwarzanie i wyszukiwanie przez agenta.
Zapisz, które kopie zostały usunięte i które wymagają decyzji. Komunikat nie powinien twierdzić, że dane zniknęły wszędzie przed odbiorem. Właściciel odpowiada za spójność retencji i reakcji incydentu.
Przegląd wykonania retencji
Raz na jakiś czas wybierz jeden proces i sprawdź, czy terminy są egzekwowane. Porównaj daty w rejestrze z rzeczywistymi obiektami. Brak operacji nie jest dowodem usunięcia; może oznaczać zatrzymany automat.
Po teście zaktualizuj właściciela i reguły. Jeżeli ten sam błąd wraca, popraw proces zamiast dodawać kolejne przypomnienie. Retencja powinna działać bez ręcznego ratowania każdego dokumentu.
Mapę miejsc przechowywania i odpowiedzialności można przygotować z Aeneia Audit. Przykład porządkowania odbiorców i kopii zawiera także rejestr przepływu danych Aeneia Signal.
Dobra retencja jest konkretna i sprawdzona. Mówi, co znika, co zostaje i dlaczego. Backup nie powinien być drugim życiem dla danych usuniętych.
Przy kolejnej polityce opisz jeden konkretny przykład usunięcia i restore zamiast dodawać nowe ogólne zasady. Zespół powinien wiedzieć, co zrobić z kopiami i kto potwierdza wynik. Dokument ma prowadzić do działania, a nie tylko do zgody na spotkaniu. Retencja jest gotowa, kiedy proces działa również po migracji i zmianie właściciela, a nie tylko w idealnym środowisku testowym.
Przy odbiorze przypisz osobę, która potrafi powtórzyć test i podjąć decyzję o błędzie. Sam automat nie wystarcza przy konflikcie wersji i legal hold. Właściciel powinien znać zakres kopii bez dostępu do pełnej usuniętej treści. To pozwala zachować dowód i ograniczyć kolejne przetwarzanie.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
