Zyski:
- Umiejętność zaprojektowania minimalnego schematu ścieżki audytu wystarczającego do odtworzenia zdarzenia
- Możliwość zapobiegania sytuacji, w której dziennik jest źródłem wycieku, poprzez maskowanie monitu/odpowiedzi
- Możliwość tworzenia weryfikowalnych dzienników z tożsamością korelacji, niezmiennością i okresem przechowywania
W systemie AI pewnego dnia na pewno zostanie zadane pytanie: „Dlaczego podjęto tę decyzję w ten sposób, co dokładnie wydarzyło się tamtego dnia?” Pytanie to może zadać klient, audytor, organ regulacyjny lub sąd. Twoja odpowiedź będzie albo weryfikowalną ścieżką audytu, albo „nie wiemy”. To drugie jest niedopuszczalne w środowisku korporacyjnym. W tej części dowiemy się, co powinno, a czego nie powinno być rejestrowane w przypadku sztucznej inteligencji, jak ustalić ścieżkę audytu i jak zachować równowagę logów z bezpieczeństwem i prywatnością.
Dlaczego rejestrowanie w AI jest inne?
W klasycznym oprogramowaniu rejestrowane jest „kto co zrobił”. W sztucznej inteligencji dodano do tego trzy nowe wymiary: jaki model/wersję wykorzystano, jaki komunikat został wysłany i jaka została udzielona odpowiedź. W przypadku wystąpienia błędu lub skargi nie można zrekonstruować zdarzenia bez tych trzech elementów. Jednak ta bardzo szybka odpowiedź/odpowiedź może zawierać informacje umożliwiające identyfikację, jak widzieliśmy w części 2 — co oznacza, że sam dziennik może stać się źródłem wycieków. To jest sztuka równowagi.
Uwaga: rejestrowanie nie oznacza „rejestrowania wszystkiego”. Zbyt częste rejestrowanie stwarza ryzyko prywatności, a zbyt małe rejestrowanie powoduje brak dowodów. Celem jest zachowanie wystarczającej ilości informacji umożliwiających identyfikację, aby zrekonstruować zdarzenie poprzez jego maskowanie.
Co należy rejestrować? Schemat ścieżki audytu
Solidna ścieżka audytu AI obejmuje co najmniej:
- Kto: Identyfikator użytkownika i rola (lub identyfikator usługi).
- Kiedy: Znacznik czasu (tylko do dołączenia, jeśli to możliwe).
- Co: Pożądana akcja i przywołane narzędzia.
- Który model: nazwa i wersja modelu (np. claude-opus-4-8), parametry krytyczne, takie jak temperatura.
- Skrót wejścia/wyjścia: wersja zamaskowana lub skrót/skrót żądania i odpowiedzi.
- Decyzja: Czy zostało przetworzone automatycznie, trafiło do człowieka, zostało zatwierdzone czy odrzucone?
- Wynik: czy operacja się powiodła, czy wystąpił błąd, jakiego zasobu dotyczy?
Krok po kroku: ustanawianie ścieżki audytu
- Wyznacz cel. Kto będzie czytał te logi i dlaczego? (Reakcja na incydenty, audyt zgodności, debugowanie). Cel określa, co przechowujesz.
- Egzekwuj zasady umożliwiające identyfikację osób. Zamaskuj monit/odpowiedź przed zalogowaniem (część 2).
- Zapewnij niezmienność. Pozwól, aby dzienniki krytyczne mogły być tylko dodawane; Nikt nie powinien być w stanie po cichu wymazać przeszłości.
- Zdefiniuj okres przechowywania. Określ czas trwania zgodnie z wymogami prawnymi i poufnością; Automatycznie usuwaj po upływie czasu.
- Ogranicz dostęp. Dostęp do dzienników powinien być również chroniony za pomocą RBAC; Odczyt dziennika również powinien zostać zarejestrowany.
- Dodaj identyfikator korelacji (identyfikator śledzenia). Połącz wszystkie etapy żądania (wejście, wywołanie narzędzia, weryfikacja, wyjście) za pomocą jednej tożsamości.
Cztery szablony do kopiowania
Schemat dziennika audytu (JSON):
{ "trace_id": "...", "time": "RRRR-MM-DDThh:mm:ssZ", "user": "...", "role": "...", "model": "claude-opus-4-8", "parameters": { "temperatura": 0 }, "request_summary": "<masked>", "response_summary": "<masked>", "tools": ["tool_a", "tool_b"], "decyzja": "auto|human_approval", "approval": "zatwierdzono|odrzucono|brak", "wynik": "sukces|błąd", "affected_resource": "..."}
Zaloguj monit kontroli PII:
Sprawdź poniższe przykłady logów. Czy pola wymagane w ścieżce audytu (kto, kiedy, model, decyzja, wynik) są kompletne? Czy wyciekły także surowe dane osobowe? Dla każdego wiersza zgłoś jako: „za mało / brakujące miejsce: ... /wyciek danych osobowych: …” <logs>{{ przykłady }</logs>
Monit o przebudowanie zdarzenia:
Następujące rekordy kontroli należą do jednego identyfikatora śledzenia. Zmień wydarzenie w narrację w porządku chronologicznym: czego chciał użytkownik, co zrobił model, jakie przeprowadzono walidacje, jak podjęto decyzję, jaki był wynik? Oznacz brakujące lub niespójne kroki.<records>{{trace_registers }</records>
Reguła dotycząca decyzji dotyczących zasad przechowywania:
Dla każdego typu dziennika określ: - Czy istnieje prawny obowiązek przechowywania? (minimalny okres, jeśli istnieje) – Czy zawiera informacje umożliwiające identyfikację? (jeśli uwzględniono, skróć czas trwania, zawęź dostęp) - Dowód zdarzenia związanego z bezpieczeństwem? (nie można zmienić sklepu) Wynik: „przechowuj N dni + mi z możliwością dołączenia tylko + poziom dostępu”.
Słaba podpowiedź/silna podpowiedź
słabe podejście
Mocne podejście
W ogóle się nie loguję („nie potrzebuję”)
Rejestrowanie minimalnego zestawu w celu rekonstrukcji zdarzenia
Rejestrowanie surowego monitu/odpowiedzi w niezmienionej postaci
Zamaskowane podsumowanie + rejestrowanie identyfikatora śledzenia
Przechowuj logi bez ograniczeń
Okres przechowywania z zachowaniem równowagi prawnej i prywatności
Każdy może usunąć logi
Krytyczne dzienniki można tylko dołączać i mają kontrolę dostępu
Trzy mini etui
Przypadek 1 — Trace ID skrócił dzienny czas dochodzenia do 15 minut. „Mój wniosek został niesłusznie odrzucony” – powiedział klient do asystenta banku ds. wstępnej oceny kredytowej. Dzięki identyfikatorowi korelacji zespół zrekonstruował dane wejściowe we wniosku, weryfikacje pracowników i decyzję w ciągu 15 minut; pokazało, że błąd był spowodowany nieprawidłowym progiem podczas sprawdzania reguły i naprawiło go.
Przypadek 2 – Podczas audytu wykryto nadmierne rejestrowanie danych. Firma zajmująca się handlem elektronicznym zapisywała wszystkie monity/odpowiedzi do nieprzetworzonych dzienników w celu debugowania. Podczas corocznego audytu stwierdzono, że rejestry te zawierały adresy klientów i numery telefonów i były przechowywane przez 2 lata. Ustalenie zostało zamknięte poprzez przejście na politykę maskowania + 90-dniowego przechowywania; Funkcja ścieżki audytu została zachowana.
Przypadek 3 — Dziennik typu „tylko dołączanie” ujawnił nadużycia wewnętrzne. Pracownik jednego z dostawców próbował usunąć dzienniki, aby ukryć błędną partię, którą utworzył. Ponieważ logi są przeznaczone tylko do dodawania i rejestrowane są próby odczytu/usunięcia dziennika, próba była natychmiast widoczna; Incydent spowodował korektę dyscyplinarną i procesową.
Wskazówka: przypisz identyfikator korelacji (identyfikator śledzenia) do każdego żądania i przeprowadź go przez wszystkie kroki. Kiedy pojawia się problem, możliwość zebrania „wszystkich informacji na temat tego żądania” za pomocą jednego zapytania jest największym przyspieszaczem reakcji na incydenty.
Typowe błędy
- Brak logowania w ogóle lub rejestrowanie tak mało, że nie można zrekonstruować zdarzenia.
- Rejestrowanie nieprzetworzonego żądania/odpowiedzi bez maski i przekształcanie dziennika w źródło wycieku.
- Brak rejestrowania nazwy/wersji modelu i decyzji (automatycznej/ręcznej).
- Przechowywanie logów przez czas nieokreślony zwiększa ryzyko prywatności.
- Pozostawienie krytycznych dzienników podlegających zmianom; Brak logowania dostępu do dziennika.
- Nie można połączyć ze sobą kroków, ponieważ nie jest używany identyfikator korelacji (identyfikator śledzenia).
Podsumowując
- Rejestrowanie AI dodaje trzy wymiary do „kto co zrobił”: który model/wersja, jaki monit i jaka odpowiedź.
- Celem jest utrzymanie minimalnej ilości informacji umożliwiających identyfikację użytkownika, aby możliwe było zrekonstruowanie zdarzenia poprzez jego maskowanie — ani więcej, ani mniej.
- Ścieżka audytu powinna zawierać pola kto/kiedy/co/jaki model/decyzja/wynik.
- Krytyczne dzienniki powinny umożliwiać tylko dołączanie, dostęp powinien być ograniczony, a dostęp do dzienników również powinien być rejestrowany.
- Identyfikator korelacji (identyfikator śledzenia) łączy wszystkie etapy żądania i przyspiesza badanie incydentu.
Zadanie aplikacji
Wybierz żądanie z własnego przepływu AI i napisz dla niego idealną ścieżkę audytu, korzystając z powyższego schematu JSON. Następnie wykonaj dwa testy: (1) Czy możesz opowiedzieć historię od początku do końca za pomocą tylko tego nagrania? (2) Czy w aktach znajdują się surowe dane umożliwiające identyfikację? Jeśli brakuje pola, dodaj je, jeśli jest PII, zamaskuj. Na koniec ustaw okres przechowywania i poziom dostępu.
lista kontrolna
- [ ] Ścieżka audytu obejmuje pola kto/kiedy/co/wzorzec/decyzja/wynik.
- [ ] Podpowiedź/odpowiedź jest maskowana przed logami (bez PII).
- [ ] Do każdego żądania przypisywany jest identyfikator korelacji (identyfikator śledzenia).
- [ ] Dzienniki krytyczne można tylko dołączać, a dostęp jest kontrolowany.
- [ ] Okres przechowywania jest określony przez saldo prawne + poufność i jest usuwany na koniec okresu.
- [ ] Dzięki logom mogę zrekonstruować wydarzenie w mniej niż 30 minut.