LLM w firmie: jak projektować politykę retencji logów i promptów, żeby spełnić compliance i nie zabić debugowania

1. Cel i zakres polityki retencji dla logów oraz promptów w systemach LLM

Polityka retencji dla systemów opartych o LLM ma dwa równorzędne cele: (1) ograniczyć ryzyko prawne i bezpieczeństwa wynikające z gromadzenia treści rozmów, promptów i metadanych oraz (2) zachować wystarczającą widoczność działania systemu, by umożliwić utrzymanie, rozwiązywanie incydentów i kontrolę jakości. W praktyce chodzi o świadome zdefiniowanie, jakie dane są logowane, po co, jak długo, gdzie i kto może do nich sięgać.

W systemach LLM retencja jest trudniejsza niż w klasycznych aplikacjach, bo „log” może zawierać nie tylko parametry techniczne, ale też pełną treść zapytań użytkownika, fragmenty dokumentów, kontekst z baz wiedzy i wygenerowane odpowiedzi. To powoduje, że polityka retencji musi obejmować zarówno typowe logi systemowe, jak i artefakty specyficzne dla LLM.

Podstawowe rozróżnienie:

• Logi techniczne – dane o działaniu komponentów (np. zdarzenia, błędy, latencja, identyfikatory żądań). Zwykle są bardziej przewidywalne i łatwiejsze do minimalizacji.
• Logi treści (content logs) – prompt, odpowiedź, kontekst, a czasem narzędzia wywoływane przez agenta i ich wyniki. Mogą nieść najwyższe ryzyko, bo często zawierają dane wrażliwe.
• Metadane interakcji – informacje opisujące żądanie bez pełnej treści (np. znaczniki czasu, identyfikatory sesji, kanał, wersja modelu, konfiguracja). Często pozwalają na obserwowalność przy mniejszym ryzyku.

Polityka retencji powinna wprost zdefiniować, które z tych warstw są przechowywane, w jakim stopniu (pełna treść vs. skróty lub wyciągi), oraz kiedy preferowane jest logowanie metadanych zamiast treści.

Zakres polityki powinien obejmować wszystkie miejsca, gdzie powstają lub mogą „zatrzymać się” dane związane z LLM:

• Aplikacja kliencka i backend – logi aplikacyjne, telemetria, ślady błędów.
• Warstwa orkiestracji LLM (np. gateway/proxy, framework agentowy) – rejestrowanie promptów, kontekstu, wywołań narzędzi i odpowiedzi.
• Dostawca modelu (API/hosting) – ustawienia i zasady dotyczące przechowywania danych po stronie dostawcy oraz to, co organizacja wysyła na zewnątrz.
• Integracje i narzędzia – konektory do baz danych, systemów biletowych, repozytoriów dokumentów, wyszukiwania, RAG.
• Warstwy pośrednie – cache, kolejki, systemy analityczne, APM/observability, SIEM, hurtownie logów.
• Zbiory do uczenia/ewaluacji – jeśli interakcje są odkładane do analizy jakości lub testów regresji, należy traktować je jako osobny strumień retencji.

Ważnym elementem zakresu jest również rozróżnienie środowisk (dev/test/prod) oraz ścieżek danych „normalnych” i „awaryjnych” (np. tryb podwyższonego logowania na czas incydentu). Polityka powinna wskazywać, w jakich sytuacjach dopuszczalne jest czasowe zwiększenie szczegółowości logów i jak szybko następuje powrót do ustawień domyślnych.

Na poziomie definicji organizacyjnej polityka retencji dla LLM powinna też jednoznacznie ustalić:

• Co jest przedmiotem retencji – które typy zdarzeń i artefaktów (np. prompt, odpowiedź, załączniki, kontekst, wyniki narzędzi, metadane) podlegają przechowywaniu.
• Granice odpowiedzialności – co jest utrzymywane przez organizację, a co przez dostawców i podwykonawców, oraz jakie wymagania trzeba przenieść do umów i konfiguracji usług.
• Celowość – retencja nie jest „archiwizacją na wszelki wypadek”; każdy strumień danych powinien mieć przypisany uzasadniony cel operacyjny.
• Domyślne podejście – zasada minimalnego przechowywania: najpierw projektuj observability na metadanych, a treść utrzymuj tylko wtedy, gdy jest niezbędna.

Efektem dobrze zdefiniowanego celu i zakresu jest spójny zestaw reguł, które pozwalają zespołom budować i utrzymywać systemy LLM bez niekontrolowanego „wycieku” danych do logów, a jednocześnie bez utraty zdolności do diagnozowania problemów i mierzenia działania rozwiązania.

2. Wymagania prawne i compliance: minimalizacja danych, RODO, podstawy przetwarzania i obowiązki informacyjne

Retencja logów i promptów w systemach LLM musi być zaprojektowana tak, aby jednocześnie wspierać cele techniczne (np. diagnostykę) i spełniać wymagania prawne oraz wewnętrzne standardy compliance. W praktyce oznacza to podejście „privacy by design” i „privacy by default”: już na etapie projektowania definiuje się, co jest zapisywane, po co, na jak długo, kto ma dostęp i jak realizowane są prawa osób, których dane dotyczą.

Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Minimalizacja danych jako punkt wyjścia

Z perspektywy RODO kluczowe są zasady: minimalizacji danych (zbieraj tylko to, co niezbędne), ograniczenia celu (dane tylko do jasno określonych celów) oraz ograniczenia przechowywania (nie dłużej, niż to konieczne). Dla logów i promptów oznacza to, że:

• nie każdy prompt musi trafiać do trwałego logowania; decyzja powinna wynikać z konkretnego celu (np. obsługa incydentów bezpieczeństwa),
• nie wszystko, co „da się zapisać”, wolno i warto zapisywać; szczególnie dotyczy to treści generowanych przez użytkowników, identyfikatorów, metadanych urządzeń i kontekstu biznesowego,
• retencja powinna być rozróżniona dla różnych strumieni danych (np. telemetria techniczna vs. treści wejściowe/wyjściowe).

Minimalizacja dotyczy także obszaru widoczności: jeśli do celu wystarczy sygnatura błędu, skrót lub agregat statystyczny, utrwalanie pełnej treści promptu bywa nieproporcjonalne.

RODO: kiedy logi i prompty są danymi osobowymi

W kontekście LLM łatwo nie zauważyć, że dane osobowe mogą wystąpić zarówno wprost (np. imię, e-mail), jak i pośrednio (identyfikatory, numery spraw, opisy sytuacji umożliwiające identyfikację, dane w załączonych dokumentach, a czasem również unikalne fragmenty tekstu). Co istotne, nawet jeśli system nie wymaga podania danych osobowych, użytkownicy często umieszczają je w promptach. Z perspektywy RODO to oznacza, że retencja promptów/logów może być przetwarzaniem danych osobowych, a organizacja powinna traktować ten obszar jako potencjalnie „wysokiego ryzyka”, zależnie od skali i wrażliwości treści.

Role i odpowiedzialności: administrator, podmiot przetwarzający, współadministrator

Model odpowiedzialności zależy od tego, kto decyduje o celach i sposobach przetwarzania danych w logach/promptach:

• Administrator – podmiot, który ustala cele i środki przetwarzania (np. firma wdrażająca LLM w procesach).
• Podmiot przetwarzający – dostawca lub partner, który przetwarza dane w imieniu administratora (np. hosting, narzędzia observability, dostawca komponentów).
• Współadministratorzy – sytuacja, gdy strony wspólnie ustalają cele/sposoby (rzadziej, ale możliwe w złożonych ekosystemach danych).

Konsekwencją jest potrzeba odpowiednich umów i ustaleń (np. umowa powierzenia, zakres instrukcji, podwykonawcy), w tym jasnego określenia, czy i w jakim celu dostawca może wykorzystywać treści promptów (np. do ulepszania modeli), oraz jak wygląda usuwanie danych po zakończeniu świadczenia usługi.

Podstawy przetwarzania: dobór do celu i proporcjonalności

Retencja musi mieć podstawę prawną. W praktyce dla logów i promptów najczęściej rozważa się:

• Wykonanie umowy – gdy utrwalanie określonych danych jest niezbędne do świadczenia usługi (np. rozliczalność działań w ramach konta, zapewnienie ciągłości działania).
• Obowiązek prawny – gdy przepisy wymagają przechowywania określonych informacji (np. wybrane obowiązki sektorowe, rachunkowe, audytowe).
• Prawnie uzasadniony interes – często stosowany dla bezpieczeństwa, zapobiegania nadużyciom i utrzymania jakości usług, ale wymaga testu równowagi i ograniczenia zakresu do niezbędnego minimum.
• Zgoda – powinna być traktowana ostrożnie w kontekście usług, gdzie istnieje nierównowaga stron; bywa uzasadniona dla dodatkowych celów (np. opcjonalne udostępnienie rozmów do poprawy jakości), o ile jest dobrowolna i łatwa do wycofania.

Wybór podstawy powinien być spójny z tym, co jest logowane oraz jak długo. Przechowywanie „na wszelki wypadek” jest trudne do obrony zarówno w RODO, jak i w audytach compliance.

Obowiązki informacyjne i przejrzystość

Jeżeli w logach/promptach mogą znajdować się dane osobowe, organizacja powinna spełnić obowiązki informacyjne: jasno przekazać, jakie kategorie danych są przetwarzane, w jakich celach, na jakich podstawach, przez jaki czas oraz komu dane mogą zostać ujawnione (np. dostawcom narzędzi infrastrukturalnych). Dla systemów LLM szczególnie ważne jest, aby komunikaty były zrozumiałe i adekwatne do kanału:

• informacje w polityce prywatności i w warunkach korzystania z usługi,
• krótsze komunikaty kontekstowe tam, gdzie użytkownik wprowadza treści (np. wskazanie, czy rozmowy są zapisywane i przez jaki czas),
• klarowne rozróżnienie między danymi używanymi do działania usługi a danymi wykorzystywanymi dodatkowo (np. do poprawy jakości),
• mechanizmy umożliwiające realizację praw (dostęp, usunięcie, sprzeciw), o ile mają zastosowanie do konkretnego przypadku.

Ocena ryzyka, DPIA i szczególne kategorie danych

W zależności od kontekstu, retencja promptów może obejmować szczególne kategorie danych (np. zdrowie) albo informacje wrażliwe biznesowo. To zwiększa wymagania w zakresie podstawy przetwarzania, zabezpieczeń oraz oceny ryzyka. Jeżeli przetwarzanie może powodować wysokie ryzyko naruszenia praw lub wolności osób, właściwe może być przeprowadzenie oceny skutków dla ochrony danych (DPIA). Nawet gdy DPIA nie jest formalnie wymagana, podejście oparte o ryzyko jest praktycznie konieczne, bo pozwala uzasadnić zakres logowania, długość retencji i poziom zabezpieczeń.

Transfery danych i lokalizacja przetwarzania

Systemy LLM często korzystają z dostawców zewnętrznych oraz usług chmurowych, co może oznaczać transfer danych poza EOG. Wymaga to weryfikacji podstaw transferu (np. standardowe klauzule umowne), oceny ryzyka oraz spójności z deklarowaną retencją. Z perspektywy polityki retencji ważne jest, aby organizacja miała kontrolę nad tym, gdzie dane są przechowywane i czy kopie zapasowe lub systemy obserwowalności nie wydłużają przechowywania ponad ustalone limity.

Rozliczalność i gotowość audytowa

Compliance w obszarze retencji to nie tylko „mieć zasady”, ale też móc wykazać, że są stosowane. Zasada rozliczalności oznacza potrzebę udokumentowania decyzji: celów logowania, doboru podstawy prawnej, czasu przechowywania, kategorii danych, ról podmiotów oraz mechanizmów kontroli. W polityce warto unikać ogólników i opierać się na weryfikowalnych założeniach: co jest zbierane, kiedy, przez kogo i jak jest usuwane.

3. Przypadki użycia retencji: debugowanie, bezpieczeństwo, audyt, jakość i observability (oraz ryzyka)

Retencja logów i promptów w systemach LLM ma sens tylko wtedy, gdy wynika z konkretnych potrzeb operacyjnych. W praktyce te potrzeby dzielą się na kilka głównych obszarów: debugowanie, bezpieczeństwo, audyt, jakość oraz observability/SRE. Każdy z nich wymaga innego zakresu danych, innej granularności oraz innego horyzontu czasowego — a jednocześnie generuje inne ryzyka (głównie nadmiarowego zbierania danych i ekspozycji treści wrażliwych).

3.1 Debugowanie i obsługa incydentów produktowych

Najczęstszy powód utrzymywania promptów i odpowiedzi to możliwość odtworzenia problemu: „dlaczego model zwrócił taki wynik?” albo „dlaczego narzędzie/agent wykonał niepoprawną akcję?”. Do debugowania zwykle potrzebne są kontekst wykonania oraz ślad decyzji, a nie pełna treść wszystkich danych wejściowych.

• Reprodukcja: identyfikator żądania, wersja promptu/systemu, parametry inferencji, identyfikator modelu, konfiguracja narzędzi, kontekst rozmowy (często w formie skróconej).
• Triaging: kody błędów, wyjątki, time-outy, informacje o rate-limitach, metadane połączeń z narzędziami i zewnętrznymi API.
• Analiza regresji: porównanie zachowań między wersjami (model, prompt, retrieval, narzędzia), z naciskiem na metadane i próbki, a nie pełen strumień treści.

Ryzyko: w logach debugowych łatwo „przy okazji” utrwalić pełne treści rozmów, dokumentów z RAG, fragmenty baz danych lub dane uwierzytelniające (np. w payloadach). Im bardziej surowy log, tym większa ekspozycja.

3.2 Bezpieczeństwo: wykrywanie nadużyć, ataków i wycieków

Retencja wspiera bezpieczeństwo w dwóch wymiarach: wykrywanie anomalii (w trakcie) oraz analizę powłamaniową (po fakcie). W systemach LLM pojawiają się specyficzne zdarzenia, których nie ma w klasycznych aplikacjach, np. prompt injection, próby wyciągania sekretów z kontekstu, czy nieautoryzowane użycie narzędzi przez agentów.

• Detekcja nadużyć: wzorce promptów wskazujące na jailbreak/injection, nietypowe wolumeny, próby obejścia polityk, skoki tokenów.
• Ochrona sekretów: identyfikacja przypadków, w których do promptu trafiają klucze API, tokeny sesji, dane konfiguracyjne.
• Forensics: śledzenie „kto, kiedy, jakim kanałem” wykonał żądanie, jakie narzędzia zostały użyte, jakie zasoby odczytano/zapisano.

Ryzyko: logi bezpieczeństwa mogą stać się „skarbnicą” dla atakującego (zawierają ślady działań i czasem treści). Dodatkowo zbyt długa retencja zwiększa powierzchnię skutków incydentu.

3.3 Audyt i rozliczalność (accountability)

Audyt wymaga udowodnienia, że system działał zgodnie z regułami: kto miał dostęp, jakie decyzje podjął system, jakie polityki były aktywne, jakie były podstawy decyzji automatycznych (na ile to możliwe). W LLM szczególnie ważne jest rozdzielenie: śladu procesu od treści. Często do audytu wystarcza zapis metadanych i identyfikatorów artefaktów, bez utrwalania pełnych promptów.

• Ślad operacyjny: identyfikatory żądań, czas, użytkownik/rola, aplikacja/tenant, wersje komponentów.
• Ślad kontroli: informacje o filtrach bezpieczeństwa, blokadach, decyzjach moderacji, użyciu narzędzi i uprawnieniach.
• Spójność: możliwość powiązania logów LLM z logami systemów źródłowych (np. ticketing, CRM, IAM) bez kopiowania danych.

Ryzyko: audyt może „pchać” organizację w stronę nadmiernego logowania. Jeśli nie ustali się granic, audytowe logi zaczną zawierać treści, które nie są konieczne do rozliczalności.

3.4 Jakość, produkt i analiza zachowań (quality analytics)

Utrzymywanie danych do oceny jakości pomaga odpowiadać na pytania: czy odpowiedzi są pomocne, czy model halucynuje, jakie są typowe niepowodzenia, czy polityki bezpieczeństwa nie blokują za dużo. W tym obszarze szczególnie ważne jest rozróżnienie między: próbkami do oceny a pełnym logiem wszystkich interakcji.

• Ewaluacje offline: zestawy przypadków testowych, benchmarki wewnętrzne, porównywanie wersji promptu/modelu.
• Feedback użytkowników: oceny, flagi „niepoprawne/niebezpieczne”, zgłoszenia błędów.
• Analiza kategorii problemów: typy pytań, tematy, długości kontekstu, skuteczność retrieval i narzędzi.

Ryzyko: dane jakościowe są najłatwiejszą drogą do budowania „cienia” bazy wiedzy o użytkownikach (profilowanie). Dodatkowo próbki do ewaluacji często są kopiowane, eksportowane i krążą poza kontrolą produkcyjnych systemów.

3.5 Observability i SRE: wydajność, koszty i niezawodność

Observability w LLM to nie tylko standardowe metryki aplikacyjne, ale też metryki „tokenowe” i specyficzne etapy pipeline’u (np. retrieval, reranking, narzędzia, moderacja). Zwykle do observability potrzebne są metryki i zdarzenia, a nie pełne treści promptów.

• Wydajność: latencje per etap, time-outy, kolejki, współbieżność, obciążenie.
• Koszty: liczba tokenów wejścia/wyjścia, rozkład długości kontekstu, koszt per funkcja/tenant.
• Niezawodność: błędy integracji narzędzi, wskaźniki degradacji jakości (np. wzrost odmów/blocked), retry i circuit breakers.

Ryzyko: „dla wygody” do metryk zaczyna się doklejać treści (np. etykiety z promptu), co może prowadzić do niekontrolowanego ujawnienia w systemach monitoringu i w alertach.

3.6 Szybkie porównanie: co trzymać i dlaczego (na poziomie intencji)

3.7 Najczęstsze ryzyka „retencji na skróty”

• Retencja z przyzwyczajenia: kopiowanie praktyk z klasycznych logów aplikacyjnych na LLM, mimo że prompty zawierają znacznie więcej wrażliwej treści.
• Brak rozdzielenia warstw: te same dane trafiają jednocześnie do APM, SIEM, narzędzi analitycznych i hurtowni, co multiplikuje ekspozycję.
• Niekontrolowane „artefakty”: eksporty rozmów do plików, ticketów i narzędzi BI bez jednolitej kontroli retencji.
• Utrwalanie danych z kontekstu: logowanie fragmentów dokumentów, wyników wyszukiwania i odpowiedzi narzędzi, choć celem było tylko monitorowanie działania pipeline’u.
• Rozjechanie celu i zakresu: zbieranie danych „do wszystkiego naraz” zamiast jasno przypisać, które sygnały wspierają debugowanie, a które bezpieczeństwo lub jakość.

4. Klasyfikacja danych w logach/promptach: kategorie, wrażliwość, PII/PHI, tajemnice przedsiębiorstwa

Klasyfikacja danych to praktyczny sposób na rozróżnienie, co dokładnie zapisują logi i prompty oraz jak ryzykowne jest to w kontekście prywatności, bezpieczeństwa i interesów firmy. W systemach LLM problem jest specyficzny: w jednym „rekordzie” (prompt, odpowiedź, trace) mogą mieszać się dane użytkownika, dane biznesowe i artefakty techniczne. Dlatego klasyfikacja powinna działać na poziomie fragmentów (np. pola, segmenty tekstu), a nie wyłącznie „całego loga”.

Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności: w praktyce trudno jest konsekwentnie rozpoznać, który kawałek śladu żądania niesie ryzyko (PII/PHI, IP, sekrety), a który jest „czystą telemetrią”.

4.1. Co zwykle trafia do logów/promptów w systemach LLM

• Dane wejściowe: prompt użytkownika, instrukcje systemowe, kontekst z RAG (wycinki dokumentów), parametry zapytania.
• Dane wyjściowe: odpowiedź modelu, cytaty/źródła, decyzje klasyfikatorów, wyniki narzędzi (tool output).
• Metadane: identyfikatory żądań, timestampy, tenant/projekt, wersja promptu/łańcucha, model, parametry inferencji.
• Telemetria techniczna: błędy, stack trace, czasy, liczniki tokenów, statusy narzędzi.
• Ślady bezpieczeństwa: zdarzenia dostępu, alerty, wyniki skanów treści, sygnały nadużyć.

Te kategorie mogą się przenikać: np. stack trace potrafi zawierać fragment promptu, a prompt bywa wklejonym dokumentem lub zrzutem ekranu po OCR. Klasyfikacja ma to wychwycić i ujednolicić zasady postępowania.

4.2. Wymiary klasyfikacji: wrażliwość, identyfikowalność, krytyczność biznesowa

Żeby klasyfikacja była użyteczna, warto rozdzielić co najmniej trzy wymiary:

• Wrażliwość danych (jak poważna szkoda przy ujawnieniu): od publicznych po ściśle poufne.
• Identyfikowalność osoby: czy dane zawierają PII (dane osobowe) lub umożliwiają identyfikację pośrednią (np. kombinacja atrybutów, identyfikatory urządzeń).
• Krytyczność biznesowa: czy dane stanowią tajemnicę przedsiębiorstwa, element strategii, IP, warunki handlowe, kod źródłowy, dane klientów/kontrahentów.

Praktycznie: log może być „techniczny”, ale jeśli zawiera identyfikator klienta i fragment umowy, to należy go traktować jak dane wrażliwe, niezależnie od tego, że powstał w procesie debugowania.

4.3. Proponowane poziomy wrażliwości (prosta skala)

Poniższa skala jest wystarczająca, aby spiąć politykę retencji z kontrolą dostępu, bez nadmiernej biurokracji:

Skala powinna być powiązana z praktyczną regułą: zawsze klasyfikuj wg najwyższego poziomu, jaki występuje w rekordzie (np. jeden numer PESEL w promptcie podnosi całość do L4).

4.4. PII vs PHI: jak rozpoznawać w kontekście LLM

PII (dane osobowe) w logach/promptach to nie tylko oczywiste pola typu „imię i nazwisko”. W systemach LLM częste są dane „wklejone” w naturalnym języku: opisy spraw, reklamacji, korespondencja. Do PII zaliczają się również identyfikatory pośrednie, jeśli mogą prowadzić do osoby po zestawieniu z innymi danymi (np. numer zamówienia + data + lokalizacja).

PHI (dane dotyczące zdrowia) to szczególny przypadek: często pojawia się w rozmowach z użytkownikiem (objawy, wyniki, historie leczenia) lub w dokumentach załączonych do promptu. Nawet jeśli nazwa nie pada wprost, kontekst medyczny w połączeniu z identyfikatorem lub inną cechą może kwalifikować dane jako szczególnie chronione.

• PII w promptach: treści zgłoszeń, podpisy maili, wklejone faktury, loginy, identyfikatory urządzeń.
• PHI w promptach: opisy diagnoz, leki, wyniki badań, informacje o wizytach, numery polis zdrowotnych.

W praktyce klasyfikacja powinna obejmować zarówno treść (tekst), jak i załączniki (np. PDF, obrazy po OCR) oraz kontekst pobrany z RAG, bo to często główne źródło PII/PHI.

4.5. Tajemnica przedsiębiorstwa i IP: najczęściej pomijana kategoria

W politykach retencji łatwo skupić się na PII, a pominąć dane, które nie są „osobowe”, ale są równie wrażliwe:

• Tajemnice przedsiębiorstwa: strategie, marże, warunki umów, listy klientów, plany produktu, wyniki badań.
• Własność intelektualna: kod źródłowy, prompty systemowe i „sekretne” instrukcje, dane treningowe, wewnętrzne modele scoringowe, schematy baz.
• Dane bezpieczeństwa: konfiguracje IAM, topologia sieci, szczegóły podatności, treści alertów zawierające ścieżki, tokeny, sekretne URL-e.

LLM sprzyjają „wyciekowi IP do logów” przez to, że użytkownicy i zespoły operacyjne wklejają do promptów: fragmenty kodu, konfiguracje, logi produkcyjne, opisy incydentów. Klasyfikacja musi to uwzględniać, aby nie traktować takich treści jak zwykłych danych debugowych.

4.6. Jednostka klasyfikacji: rekord, pole, segment

Warto z góry ustalić, na jakim poziomie przypisujecie klasyfikację:

• Rekord: najprostsze (jeden poziom dla całego promptu/logu), ale prowadzi do „podnoszenia” wszystkiego do wysokiej wrażliwości.
• Pole: osobno np. user_message, system_prompt, retrieved_chunks, tool_output, stack_trace.
• Segment: najbardziej precyzyjne (np. redakcja/oznaczenie fragmentów w tekście), przydatne gdy chcecie zachować część informacji do analityki bez przechowywania wrażliwej treści.

Niezależnie od poziomu, przyjmijcie zasadę: metadane nie są automatycznie „bezpieczne”. Identyfikatory sesji, adresy IP, user-agent, identyfikatory tenantów czy identyfikatory spraw mogą być PII lub umożliwiać reidentyfikację.

4.7. Minimalny schemat etykiet (tagów) dla logów/promptów

Żeby klasyfikacja była egzekwowalna, oprócz poziomu wrażliwości warto dodać kilka tagów opisowych (do filtrowania, raportowania i wyjątków):

• DataType: PII / PHI / SecuritySecrets / TradeSecret / SourceCode / GeneralBusiness / TechnicalTelemetry.
• Source: UserPrompt / SystemPrompt / RAG / ToolOutput / Exception / Observability.
• Scope: Tenant / Project / Environment (dev/test/prod).
• Identifiability: Direct / Indirect / None.

Dzięki temu da się rozdzielić np. „telemetrię techniczną” od „promptów z danymi klienta” nawet jeśli oba elementy są częścią jednego śladu żądania.

4.8. Krótki przykład: jak to wygląda w praktyce (schemat logu)

{
  "request_id": "...",
  "environment": "prod",
  "fields": {
    "user_message": {
      "classification_level": "L3",
      "tags": ["PII", "UserPrompt", "Direct"]
    },
    "system_prompt": {
      "classification_level": "L2",
      "tags": ["TradeSecret", "SystemPrompt"]
    },
    "tool_output": {
      "classification_level": "L1",
      "tags": ["TechnicalTelemetry", "ToolOutput"]
    }
  }
}

To nie definiuje jeszcze retencji ani technik anonimizacji, ale pokazuje cel klasyfikacji: ujednolicić język i umożliwić różne zasady dla różnych fragmentów tego samego zdarzenia.

5. Okresy retencji i harmonogramy: środowiska (dev/test/prod), typy danych, uzasadnienia i wyjątki

Retencja w systemach LLM nie powinna być „jedną liczbą dni” dla wszystkiego. Dobrze zaprojektowana polityka opiera się na harmonogramach retencji (retention schedules), które różnicują okres przechowywania według środowiska (dev/test/prod), typu danych (telemetria, logi aplikacyjne, prompty, odpowiedzi, artefakty bezpieczeństwa) oraz celu (debugowanie, incydenty, audyt, rozliczalność). Kluczowy jest kompromis: im dłuższa retencja, tym większe ryzyko i koszt; im krótsza, tym gorsze debugowanie i trudniejsza analiza regresji.

5.1. Zasada „minimum potrzebnego” i różnice między środowiskami

Najprostszy i praktyczny podział to trzy profile:

• Dev – krótkie okresy, wysoka zmienność, nacisk na szybkie debugowanie. W idealnym świecie brak danych produkcyjnych; jeśli trafiają, retencja powinna automatycznie się skracać.
• Test/UAT – średnie okresy, potrzeba powtarzalności testów i analizy regresji. Dane powinny być syntetyczne lub odpowiednio przekształcone; retencja zwykle krótsza niż w produkcji.
• Prod – retencja zdefiniowana pod wymagania operacyjne, bezpieczeństwa i rozliczalności, z wyraźnym rozdzieleniem na dane „pomocnicze” (observability) i „wrażliwe” (treści promptów, załączniki).

5.2. Typy danych i sugerowane „koszyki” retencyjne

W praktyce wygodnie jest utrzymywać kilka standardowych koszyków retencji (np. 7 dni, 30 dni, 90 dni, 180 dni, 1–2 lata), a następnie mapować do nich konkretne strumienie danych. Poniżej przykładowa matryca, którą należy dopasować do realnych potrzeb i ryzyk:

Warto rozdzielić „treść” (prompt/odpowiedź/załączniki) od „kontekstu technicznego” (ID żądania, timestamp, wersja modelu, parametry, kody błędów, opóźnienia). Często to właśnie kontekst wystarcza do większości analiz operacyjnych i może mieć dłuższą retencję niż sama treść.

5.3. Harmonogramy: od „hot” do „cold” i automatyczne wygaszanie

Harmonogram retencji powinien opisywać nie tylko jak długo dane są przechowywane, ale też gdzie i w jakiej postaci. Popularny wzorzec:

• Hot (krótko) – pełne dane potrzebne do bieżącego debugowania (najczęściej dni/tygodnie), szybki dostęp, wyższy koszt.
• Warm (średnio) – ograniczony zakres (np. tylko wybrane pola, próbki, dane po redakcji), dostęp nadal wygodny.
• Cold (długo, selektywnie) – tylko to, co jest potrzebne do rozliczalności lub bezpieczeństwa; wolniejszy dostęp, niższy koszt, wyraźnie ograniczona zawartość.

W polityce warto wprost zapisać mechanizmy automatyzacji: rotację, TTL, przenoszenie między warstwami i automatyczne kasowanie po upływie okresu. Z operacyjnego punktu widzenia lepiej działa podejście „usuwa się samo” niż ręczne porządki.

5.4. Uzasadnienia biznesowe, które warto wpisać do polityki

Każdy okres retencji powinien mieć krótkie uzasadnienie, możliwe do obrony w audycie i zrozumiałe dla zespołów technicznych. Typowe uzasadnienia:

• Debugowanie i wsparcie: czas potrzebny na wykrycie, odtworzenie i naprawę błędu (często 7–30 dni).
• Analiza regresji: pokrycie co najmniej jednego cyklu wdrożeniowego lub wydania (np. 30–90 dni).
• Bezpieczeństwo i incydenty: okres, w którym incydenty są zwykle wykrywane i analizowane (często 90–180 dni lub dłużej dla śladów audytowych).
• Rozliczalność zmian: możliwość ustalenia „kto/co/kiedy” w przypadku sporu lub awarii (zwykle dłużej niż logi operacyjne).

W samej sekcji retencji wystarczy te uzasadnienia wskazać; szczegółowe ryzyka i techniki ograniczania treści (np. redakcję) opisuje się w odrębnych częściach polityki.

5.5. Wyjątki i „legal hold”: jak nie zniszczyć dowodów ani nie wydłużyć retencji wszystkiego

Najczęstszy błąd to wydłużenie retencji całego strumienia danych „na wszelki wypadek”. Zamiast tego polityka powinna przewidywać kontrolowane wyjątki:

• Incydent bezpieczeństwa: możliwość zamrożenia wybranych zakresów danych (np. konkretny tenant, ID żądania, przedział czasu) na dłużej, przy jednoczesnym niezmienianiu retencji globalnej.
• Spór/audyt/dochódzenie: mechanizm legal hold dla ściśle wskazanych danych, z rejestrem kto uruchomił wyjątek, na jakiej podstawie i na jak długo.
• Przypadki jakościowe: zachowanie niewielkiej, kontrolowanej próbki interakcji (np. oznaczonej ręcznie) do analizy jakości — ale jako wyjątek, nie domyślna polityka dla całej populacji.

Każdy wyjątek powinien mieć: zakres (co dokładnie obejmuje), termin ważności, właściciela (rola, nie osoba) oraz mechanizm cofnięcia. Dzięki temu debugowanie i forensics są możliwe bez „wiecznej retencji” treści promptów.

5.6. Przykładowy zapis w polityce (szablon)

Strumień danych: logi LLM - treść promptów i odpowiedzi (raw)
Środowisko: produkcyjne
Retencja: 14 dni (hot), następnie automatyczne usunięcie
Uzasadnienie: wsparcie i odtwarzanie zgłoszeń użytkowników
Wyjątki: legal hold dla incydentów bezpieczeństwa lub audytu, ograniczony do ID zdarzeń i przedziału czasu, max 180 dni, z rejestrem zatwierdzeń

Taki format ułatwia konsekwentne zarządzanie retencją: jest konkretny, mapowalny na konfiguracje systemów logowania i pozwala jasno rozróżnić retencję domyślną od wyjątków.

6. Anonimizacja i pseudonimizacja: techniki, tokenizacja, redakcja, ograniczenia i walidacja

W systemach LLM logi i prompty często zawierają dane wrażliwe „przy okazji”: identyfikatory, fragmenty dokumentów, treści rozmów, metadane. Zamiast polegać wyłącznie na krótkiej retencji, warto wdrożyć transformacje danych, które pozwalają zachować użyteczność diagnostyczną i analityczną, jednocześnie ograniczając ryzyko ujawnienia informacji.

Anonimizacja vs pseudonimizacja (i co to znaczy praktycznie)

Pseudonimizacja to zastąpienie identyfikatorów (np. e-mail) innymi wartościami (np. tokenem), zwykle z możliwością odtworzenia powiązania w kontrolowanych warunkach (np. przez osobny rejestr mapowań). Anonimizacja to przekształcenie danych w taki sposób, by nie dało się (rozsądnie) zidentyfikować osoby ani poprzez sam zbiór, ani poprzez połączenie z innymi informacjami.

Główne techniki ochrony treści promptów i logów

• Redakcja (maskowanie) w treści – usuwanie lub zastępowanie fragmentów uznanych za wrażliwe (np. [EMAIL], [NUMER_DOKUMENTU]). Daje dobrą czytelność, ale bywa krucha (zależy od jakości wykrywania).
• Tokenizacja – zamiana wartości na tokeny stabilne w czasie (np. ten sam e-mail → ten sam token), co ułatwia korelację zdarzeń bez ujawniania oryginału. Tokeny mogą być:
  • Deterministyczne (łatwa korelacja, większe ryzyko ataków słownikowych bez soli/sekretu).
  • Losowe (mniejsze ryzyko odgadnięcia, ale wymaga przechowywania mapowań).
• Haszowanie z tajnym sekretem (HMAC) – praktyczny wariant tokenizacji deterministycznej, który utrudnia odgadnięcie wartości przez osoby postronne. Nadal pozostaje pseudonimizacją, bo korelacja jest możliwa.
• Generalizacja – obniżenie szczegółowości (np. wiek → przedział, lokalizacja → region). Dobre do metryk jakości i trendów, słabsze do analizy jednostkowych przypadków.
• Redukcja kontekstu – zamiast logować pełny prompt/odpowiedź, loguje się streszczenie, cechy (np. długość, typ intencji), identyfikatory dokumentów, wyniki filtrów czy klasyfikatorów. To często najbezpieczniejsza forma „observability”, ale wymaga przemyślenia, co jest potrzebne do diagnozy.

Co tokenizować, a co redagować?

W praktyce warto rozdzielić elementy, które muszą być korelowalne, od tych, które powinny być po prostu usunięte:

• Tokenizacja/pseudonimizacja: identyfikatory użytkownika/klienta, identyfikatory sesji, stałe atrybuty potrzebne do śledzenia problemów (np. tenant, kanał), o ile nie są same w sobie wrażliwe.
• Redakcja/usunięcie: treści dokumentów, dane wrażliwe wprost (np. numery dokumentów, dane medyczne), fragmenty promptów zawierające tajemnice przedsiębiorstwa lub dane osób trzecich, jeśli nie są konieczne do diagnostyki.
• Generalizacja: cechy analityczne (lokalizacja do poziomu kraju/regionu, czas do przedziałów) tam, gdzie nie potrzeba precyzji.

Ograniczenia i typowe pułapki

• Reidentyfikacja przez kontekst: nawet po usunięciu e-maila użytkownik może być rozpoznawalny po „historii”, nazwach projektów, unikatowych opisach zdarzeń lub wklejonych fragmentach dokumentów.
• Ataki słownikowe: tokeny deterministyczne bez sekretu (lub z przewidywalnym sekretem) można odgadnąć, szczególnie dla danych o małej entropii (np. popularne domeny e-mail).
• Nieszczelność przez metadane: identyfikatory żądań, URL-e, nagłówki, nazwy plików i ścieżki często zawierają dane osobowe lub poufne. Maskowanie samego „tekstu promptu” nie wystarczy.
• „Zbyt agresywna” redakcja zabija debugowanie: jeśli usuniemy wszystkie sygnały, nie da się odtworzyć scenariusza błędu (np. w RAG: jaka była wersja indeksu, jakie dokumenty dobrano, jakie filtry zadziałały).
• Rozjechana spójność tokenów: zmiana kluczy/soli lub reguł maskowania bez wersjonowania utrudnia analizę trendów i korelację w czasie.
• Fałszywe poczucie bezpieczeństwa: pseudonimizacja nie „wyłącza” wrażliwości danych; nadal trzeba je chronić jak dane wrażliwe, tylko o mniejszej ekspozycji.

Walidacja skuteczności: jak sprawdzać, czy to działa

Transformacje powinny mieć mierzalne kryteria jakości. Celem walidacji jest wykrycie zarówno wycieków, jak i nadmiernego okrojenia danych.

• Testy pokrycia redakcji: zestawy kontrolne z reprezentatywnymi przykładami danych (różne formaty numerów, języki, typowe błędy użytkowników). Mierz odsetek wykrytych vs. pominiętych encji.
• Testy odporności: warianty obejść (np. rozdzielanie znakami, spacje, literówki, formaty międzynarodowe), aby sprawdzić, czy reguły nie są zbyt kruche.
• Przeglądy próbek logów (kontrolowane): okresowe audyty jakości redakcji na losowej próbce, z jasną procedurą eskalacji, gdy znajdzie się dane wrażliwe.
• Metryki „użyteczności diagnostycznej”: czy po transformacji da się nadal wykonać kluczowe analizy (korelacja po sesji/tenant, rozkład błędów po modelu/węźle, porównanie wersji promptów). Jeśli nie – trzeba dostosować zakres logowanych sygnałów, a nie wracać do pełnych treści.
• Wersjonowanie reguł: oznaczaj w logach wersję polityki redakcji/tokenizacji, by dało się interpretować dane historyczne i wychwytywać skutki zmian.

Minimalny przykład: pseudonimizacja identyfikatora przez HMAC

Poniżej przykład koncepcyjny pseudonimizacji wartości (np. e-maila) do stabilnego tokenu. To ułatwia korelację bez przechowywania oryginału w logach.

import hmac
import hashlib

def pseudonymize(value: str, secret: bytes) -> str:
    msg = value.strip().lower().encode("utf-8")
    digest = hmac.new(secret, msg, hashlib.sha256).hexdigest()
    return f"tok_{digest[:24]}"  # skrót dla czytelności w logach

Uwaga praktyczna: zabezpieczenie sekretu i jego rotacja wymagają dyscypliny operacyjnej; zmiana sekretu wpływa na możliwość korelacji w czasie.

7. Kontrola dostępu i bezpieczeństwo przechowywania: RBAC/ABAC, szyfrowanie, separacja tenantów, ślady audytowe

Nawet najlepiej dobrane okresy retencji nie spełnią swojej roli, jeśli logi i prompty można odczytać „na skróty”, skopiować poza kontrolą lub modyfikować bez śladu. Ta część polityki opisuje więc kto i w jakich warunkach ma dostęp do danych, gdzie one są przechowywane, jak są chronione kryptograficznie oraz jak organizacja udowadnia, że dostęp był zgodny z zasadami.

RBAC vs ABAC: dwa podejścia do „kto może co zobaczyć”

W polityce warto rozróżnić dwa podstawowe mechanizmy autoryzacji, bo ich zastosowania w praktyce są inne:

• RBAC (Role-Based Access Control) przypisuje uprawnienia do ról (np. SRE, SecOps, Data Protection, Support). Jest prosty w utrzymaniu i dobrze pasuje do typowych scenariuszy operacyjnych, gdzie zakres dostępu jest stabilny.
• ABAC (Attribute-Based Access Control) podejmuje decyzję na podstawie atrybutów (np. środowisko, klasyfikacja danych, tenant, region, cel dostępu, czas, stan incydentu, poziom ryzyka). Sprawdza się, gdy dostęp ma zależeć od kontekstu i wymaga dodatkowych ograniczeń.

Polityka powinna wskazać, które zasoby są chronione RBAC (np. standardowe dashboardy observability), a które wymagają ABAC (np. przegląd surowych promptów z produkcji, dostęp do danych wyłącznie dla konkretnego tenanta lub wyłącznie w trakcie aktywnego incydentu).

Zasady dostępu: minimalizacja, „need-to-know” i rozdział obowiązków

• Najmniejsze uprawnienia: dostęp do treści promptów i odpowiedzi nie powinien być domyślny dla ról inżynierskich; preferuj dostęp do metryk i zanonimizowanych wycinków, a do pełnej treści tylko wyjątkowo.
• Separacja ról: osoba mogąca zmieniać politykę retencji lub reguły maskowania nie powinna jednocześnie mieć nieograniczonego wglądu w dane; ogranicza to ryzyko nadużyć i błędów.
• Dostęp czasowy: dla wrażliwych logów stosuj podejście „just-in-time” (czasowe podniesienie uprawnień) zamiast stałych uprawnień.
• Ścieżka eskalacji: polityka powinna jasno określać, kto zatwierdza dostęp do surowych danych oraz w jakich przypadkach jest on dopuszczalny (np. incydent bezpieczeństwa, błąd krytyczny, audyt wewnętrzny).

Szyfrowanie w tranzycie i w spoczynku oraz zarządzanie kluczami

Minimalny standard to szyfrowanie danych:

• W tranzycie: chroni dane przesyłane między aplikacją LLM, warstwą logowania, magazynem oraz narzędziami analitycznymi. Polityka powinna wymagać bezpiecznych kanałów komunikacji i blokować „ciche wyjątki” dla usług wewnętrznych.
• W spoczynku: chroni dane w magazynie logów, archiwach oraz kopiach zapasowych. Ważne jest objęcie szyfrowaniem również danych pochodnych (np. eksportów, snapshotów, paczek diagnostycznych).
• Zarządzanie kluczami: określ odpowiedzialność za klucze, zasady rotacji, ograniczenia dostępu do kluczy oraz procedury na wypadek podejrzenia kompromitacji. Dla danych o wyższej wrażliwości warto stosować klucze rozdzielone per środowisko i per tenant.

W polityce istotne jest też stwierdzenie, że „szyfrowanie” nie zastępuje kontroli dostępu: kluczowe jest ograniczenie tego, kto może odszyfrować dane oraz w jakim kontekście.

Separacja tenantów i izolacja środowisk

W systemach obsługujących wielu klientów lub wiele jednostek organizacyjnych separacja danych jest równie ważna jak retencja. Polityka powinna wymagać:

• Izolacji tenantów: logi i prompty muszą być jednoznacznie oznaczone identyfikatorem tenanta, a mechanizmy autoryzacji muszą uniemożliwiać dostęp między tenantami. Dotyczy to także narzędzi analitycznych i raportowych.
• Izolacji środowisk: dev/test/prod powinny mieć oddzielne magazyny danych i odrębne uprawnienia. Szczególnie ważne jest zapobieganie kopiowaniu produkcyjnych promptów do środowisk o niższym poziomie zabezpieczeń.
• Kontroli eksportów: eksport danych (np. do narzędzi BI, ticketów, e-maili, repozytoriów) powinien być traktowany jak tworzenie nowego zasobu o własnych zasadach dostępu i przechowywania.

Ślady audytowe: kto, co, kiedy i dlaczego

Polityka powinna wymagać, aby każde działanie na logach i promptach pozostawiało wiarygodny ślad audytowy. Kluczowe elementy to:

• Rejestrowanie dostępu: odczyty, wyszukiwania, eksporty, masowe pobrania oraz wszelkie operacje administracyjne muszą być logowane.
• Uzasadnienie dostępu: dla danych wrażliwych wymóg podania celu (np. numer incydentu lub zgłoszenia) ogranicza „ciekawość” i ułatwia kontrolę.
• Niezmienność i integralność: ślady audytowe powinny być odporne na manipulacje i przechowywane w sposób umożliwiający późniejsze dochodzenie.
• Przeglądy i alerty: polityka powinna wskazać, że audyt to nie tylko archiwizacja zdarzeń, ale też regularny przegląd oraz wykrywanie anomalii (np. nietypowe zapytania, skoki wolumenu, dostęp poza godzinami pracy).

Bezpieczeństwo operacyjne przechowywania

• Segmentacja i ograniczenie powierzchni ataku: magazyny logów i promptów powinny być dostępne tylko z zaufanych sieci i usług; unikaj otwierania ich „dla wygody” na szerokie zakresy.
• Kontrola narzędzi: dostęp przez interfejsy analityczne i agregatory jest często słabszym ogniwem niż sam magazyn; polityka powinna obejmować również te warstwy.
• Zarządzanie kopiami i replikami: kopie zapasowe, repliki, cache i archiwa muszą dziedziczyć wymagania bezpieczeństwa; w przeciwnym razie retencja i dostęp będą obchodzone przez „cienie danych”.
• Procedury na wypadek incydentu: zdefiniuj zasady zamrażania dostępu, zabezpieczania dowodów i ograniczania ryzyka dalszego wycieku bez niekontrolowanego rozpowszechniania danych w materiałach diagnostycznych.

Dobrze zaprojektowana kontrola dostępu i bezpieczeństwo przechowywania pozwalają utrzymać równowagę: z jednej strony chronią prompty i logi jako dane wysokiego ryzyka, z drugiej umożliwiają skuteczne dochodzenie przy incydentach oraz kontrolowane debugowanie bez „otwierania” danych dla zbyt szerokiej grupy.

8. Procedury usuwania i realizacja praw osób: deletion workflows, backupy, legal hold + przykładowa polityka i macierz decyzji retencji

Retencja w systemach opartych o LLM nie kończy się na ustaleniu „ile dni trzymamy logi i prompty”. Żeby spełnić compliance i jednocześnie nie sparaliżować debugowania, potrzebujesz wykonywalnych procedur usuwania, sposobu obsługi żądań osób (np. dostępu, usunięcia) oraz reguł postępowania z backupami i sytuacjami legal hold. Kluczowe jest, aby usuwać dane w sposób przewidywalny, audytowalny i spójny w całym łańcuchu przetwarzania (aplikacja, logowanie, narzędzia obserwowalności, dostawcy modelu, magazyny danych).

Deletion workflows: co znaczy „usunąć” w praktyce

W kontekście LLM „usunięcie” powinno być rozumiane jako trwałe wyeliminowanie możliwości odtworzenia danych z systemów operacyjnych i analitycznych, albo zastosowanie środków równoważnych (np. kryptograficzne zniszczenie kluczy). Procedura usuwania powinna obejmować nie tylko rekord „prompt/response”, ale też powiązane artefakty: identyfikatory sesji, ślady narzędzi (tool calls), metadane, wskaźniki jakości, zrzuty błędów, a czasem wycinki kontekstu (retrieval) i cache.

• Zakres usunięcia: ustal, czy usuwasz pełną treść, czy także metadane pozwalające na reidentyfikację (np. stałe identyfikatory użytkownika, surowe adresy IP). Tam, gdzie metadane są potrzebne do bezpieczeństwa, rozważ skrócenie ich retencji lub separację przechowywania.
• Identyfikowalność: deletion workflow działa tylko, jeśli potrafisz znaleźć dane. Dlatego standardem jest przechowywanie minimalnych, kontrolowanych „kluczy korelacyjnych” (np. identyfikator sprawy, pseudonim użytkownika) i unikanie rozproszonego kopiowania treści promptów do wielu narzędzi.
• Tryby usuwania: rozróżnij usuwanie planowe (po upływie retencji), usuwanie na żądanie (prawa osoby), oraz usuwanie incydentalne (błędne logowanie wrażliwych danych).
• Dowód usunięcia: przechowuj audyt zdarzenia usunięcia (kto, co, kiedy, na jakiej podstawie), ale tak, aby audyt sam w sobie nie odtwarzał usuniętych treści.

Realizacja praw osób (DSAR): jak nie zgubić się w danych LLM

Systemy LLM często przetwarzają dane „w biegu” i w wielu warstwach (aplikacja, dostawca modelu, narzędzia do logów). Dlatego w procedurze obsługi praw osób (np. dostępu, sprostowania, ograniczenia, sprzeciwu, usunięcia) ważne są dwa elementy: ustalenie, czy osoba jest identyfikowalna w logach oraz rozgraniczenie ról (administrator/podmiot przetwarzający, współadministrowanie, odbiorcy danych).

• Przyjęcie i weryfikacja żądania: weryfikuj tożsamość proporcjonalnie do ryzyka. Minimalizuj dodatkowe dane pozyskiwane do weryfikacji.
• Mapowanie danych: identyfikuj, gdzie mogą znajdować się dane danej osoby: logi aplikacyjne, logi LLM gateway, system ticketowy, obserwowalność, magazyny analityczne, backupy, a także ewentualne repozytoria promptów do oceny jakości.
• Odpowiedź na żądanie: udostępniaj informacje w sposób zrozumiały, uwzględniając, że surowe prompty mogą zawierać dane osób trzecich lub tajemnice przedsiębiorstwa. W takich przypadkach stosuj ograniczenia lub redakcję, zamiast pełnej odmowy.
• Usunięcie i ograniczenie: jeśli usunięcie nie jest możliwe (np. legal hold, obowiązek prawny), wdrażaj ograniczenie przetwarzania: izolacja, blokada użycia, skrócona dostępność, ścisłe uprawnienia.

Backupy: jak pogodzić niezmienność kopii z prawem do usunięcia

Backupy są najczęstszym źródłem „ukrytej retencji”. Sensowna praktyka to takie zaprojektowanie kopii, by nie były używane do bieżącego przetwarzania, a służyły wyłącznie odtwarzaniu awaryjnemu. Wtedy usunięcie w systemach produkcyjnych jest skuteczne „od razu”, a dane w backupie znikają w wyniku cyklu rotacji.

• Rotacja i maksymalny horyzont: utrzymuj możliwie krótki i uzasadniony okres przechowywania kopii. Im dłuższy horyzont backupów, tym trudniej obronić minimalizację.
• Odtworzenia kontrolowane: jeśli dojdzie do odtworzenia z backupu, procedura powinna przewidywać ponowne zastosowanie usunięć i ograniczeń (np. „replay” list usunięć) tak, by nie „wskrzeszać” danych, które miały być skasowane.
• Segmentacja: przechowuj backupy tak, by ograniczyć rozprzestrzenianie się danych wrażliwych (np. separacja środowisk, separacja tenantów, ograniczony dostęp).
• Wyjątki: jeżeli organizacja decyduje się na „granular deletion” w backupach (usuwanie pojedynczych rekordów), musi to być opisane jako wyjątek i stosowane tylko tam, gdzie ryzyko uzasadnia koszt i złożoność.

Legal hold: kiedy retencja przestaje być „automatyczna”

Legal hold (zabezpieczenie dowodowe) to kontrolowane wstrzymanie standardowego usuwania danych, gdy istnieje obowiązek zachowania materiału na potrzeby postępowania, audytu lub sporu. W systemach LLM legal hold bywa potrzebny np. w sprawach dotyczących bezpieczeństwa, nadużyć, reklamacji lub incydentów.

• Wyzwalacze: jasno określ, kto i na jakiej podstawie może nałożyć legal hold oraz dla jakiego zakresu danych (np. konkretna sprawa, identyfikator sesji, okres czasu).
• Minimalizacja w ramach hold: legal hold nie oznacza „zachowaj wszystko”. Zakres powinien być możliwie wąski i okresowo przeglądany.
• Kontrola dostępu: dane objęte hold powinny być odseparowane i udostępniane tylko upoważnionym osobom; dostęp i pobrania muszą zostawiać ślad audytowy.
• Zakończenie hold: po ustaniu podstawy hold dane wracają do normalnego cyklu retencji albo są usuwane niezwłocznie, jeśli retencja już minęła.

Przykładowa polityka (skrót): zasady operacyjne usuwania

Poniższy przykład to zwięzły zestaw reguł, który można zaadaptować do organizacji niezależnie od technologii:

• Jedno źródło prawdy: polityka retencji i usuwania jest utrzymywana centralnie; wszystkie systemy logujące/promptowe muszą ją implementować.
• Domyślnie nie zapisujemy treści: treść promptów/odpowiedzi jest zapisywana tylko tam, gdzie istnieje uzasadniona potrzeba (np. incydenty, reprodukcja błędów) i z krótką retencją; w pozostałych przypadkach zapisujemy metadane i wskaźniki.
• Usuwanie planowe: dane są usuwane automatycznie po upływie retencji, w trybie ciągłym (rolling) z potwierdzeniem wykonania i raportowaniem wyjątków.
• Usuwanie na żądanie: żądania osób są obsługiwane w ustalonym SLA; system utrzymuje rejestr żądań i statusów bez przechowywania usuwanych treści.
• Backup nie jest archiwum: kopie służą wyłącznie odtworzeniu awaryjnemu i rotują się w określonym maksymalnym horyzoncie; po odtworzeniu stosuje się mechanizm ponownego wykonania usunięć.
• Legal hold jako wyjątek: wstrzymanie usuwania wymaga zatwierdzenia, ma zdefiniowany zakres i jest okresowo weryfikowane.
• Obsługa błędów: jeśli usunięcie się nie powiedzie (np. awaria integracji), uruchamiany jest proces naprawczy, a ryzyko jest oceniane i dokumentowane.

Macierz decyzji retencji (opisowa): jak podejmować decyzje bez nadmiaru danych

Macierz decyzji retencji pomaga rozstrzygać, czy zapisujemy treść i jak długo, w zależności od celu i ryzyka. Zamiast sztywnych liczb, stosuje się reguły „jeśli–to”, które są łatwe do obrony w compliance i proste do wdrożenia:

• Jeśli celem jest bezpieczeństwo i wykrywanie nadużyć, to preferuj metadane i zdarzenia (kto, kiedy, skąd, jaki typ operacji) z dłuższą retencją, a treść promptów tylko w przypadkach wysokiego ryzyka lub potwierdzonego incydentu.
• Jeśli celem jest debugowanie produkcyjne, to zapis treści dopuszczaj jako opcję „na czas diagnostyki” (czasowe podniesienie poziomu logowania) z krótką retencją i silną kontrolą dostępu; standardowo przechowuj sygnatury błędów i identyfikatory korelacyjne.
• Jeśli celem jest poprawa jakości, to używaj próbkowania, agregacji i danych zredagowanych; pełne treści tylko po świadomej decyzji i z mechanizmem łatwego wycofania (opt-out) tam, gdzie ma to zastosowanie.
• Jeśli dane mogą zawierać PII/PHI lub tajemnice przedsiębiorstwa, to ustaw retencję na minimum, ogranicz miejsca zapisu i włącz mechanizmy wymuszonego usuwania; eskaluj do wyjątków tylko przy formalnym uzasadnieniu.
• Jeśli dane są objęte legal hold lub obowiązkiem prawnym, to wstrzymaj usuwanie w ściśle określonym zakresie, utrzymuj separację i zakończ hold natychmiast po ustaniu podstawy.
• Jeśli nie potrafisz jednoznacznie wskazać celu i podstawy, to nie zapisuj treści, a retencję metadanych ustaw na minimalną operacyjnie.

Dobrze zaprojektowane procedury usuwania i obsługi praw osób sprawiają, że retencja przestaje być „deklaracją w dokumencie”, a staje się mechanizmem, który działa w systemach i da się obronić w audycie. Jednocześnie pozwalają zachować to, co naprawdę potrzebne do diagnozowania i bezpieczeństwa, bez utrzymywania pełnych treści promptów na wszelki wypadek.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Asana vs Trello vs Planner: 8 scenariuszy pracy, w których każde narzędzie wygrywa (i przegrywa) 07 kwietnia 2026

Ranking, który nie kłamie: normalizacja danych (min-max, z-score, robust) w raportach 05 kwietnia 2026