Câștiguri:
- Capacitatea de a proiecta o schemă minimă de urmărire de audit suficientă pentru a reconstrui evenimentul
- Abilitatea de a preveni jurnalul să fie o sursă de scurgere prin mascarea promptului/răspunsului
- Abilitatea de a stabili jurnalele verificabile cu identitate de corelare, imuabilitate și perioadă de păstrare
Într-un sistem AI, într-o zi se va pune cu siguranță întrebarea: „De ce a fost luată această decizie în acest fel, ce s-a întâmplat exact în acea zi?” Această întrebare poate fi pusă de un client, un auditor, un organism de reglementare sau o instanță. Răspunsul dumneavoastră va fi fie o pistă de audit verificabilă, fie „nu știm”. Acesta din urmă este inacceptabil într-un mediu corporativ. În această unitate, vom învăța ce ar trebui și ce nu ar trebui să fie înregistrate specifice AI, cum să stabilim o pistă de audit și cum să păstrăm jurnalele în echilibru cu securitatea și confidențialitatea.
De ce este logarea diferită în AI?
În software-ul clasic, „cine a făcut ce” este înregistrat. În AI, trei dimensiuni noi se adaugă la aceasta: ce model/versiune a fost folosit, ce prompt a fost trimis și ce răspuns a fost produs. Când apare o eroare sau o plângere, nu puteți reconstitui incidentul fără aceste trei. Dar acest prompt/răspuns poate conține PII, așa cum am văzut în unitatea 2 - ceea ce înseamnă că jurnalul în sine poate deveni o sursă de scurgeri. Aceasta este arta echilibrului.
Atenție: Înregistrarea nu este „înregistrați totul”. Prea multă înregistrare creează un risc de confidențialitate, iar prea puțină înregistrare creează lipsa de dovezi. Scopul este de a păstra suficient din PII pentru a reconstrui evenimentul prin mascarea acestuia.
Ce ar trebui să fie înregistrat? Schema de urmărire de audit
O pistă solidă de audit AI include cel puțin:
- Cine: ID utilizator și rol (sau ID serviciu).
- Când: ștampilă temporală (numai pentru atașare, dacă este posibil).
- Ce: Acțiunea dorită și instrumentele invocate.
- Ce model: numele și versiunea modelului (de exemplu, claude-opus-4-8), parametri critici, cum ar fi temperatura.
- Rezumat de intrare/ieșire: o versiune mascată sau un rezumat/hash al cererii și răspunsului.
- Decizie: a fost procesat automat, a fost trimis la un om, a fost aprobat sau respins?
- Rezultat: operațiunea este reușită sau eroată, ce resursă este afectată?
Pas cu pas: stabilirea unei piste de audit
- Stabileste un obiectiv. Cine va citi aceste jurnale și de ce? (Răspunsul la incident, auditarea conformității, depanarea.) Scopul determină ceea ce păstrați.
- Aplicați politica privind informațiile personale. Mascați promptul/răspunsul înainte de înregistrare (unitatea 2).
- Oferă imuabilitate. Lăsați jurnalele critice să fie numai atașate; Nimeni nu ar trebui să poată șterge trecutul în tăcere.
- Definiți perioada de păstrare. Determinați durata conform echilibrului dintre cerințele legale și confidențialitatea; Ștergeți automat când expiră timpul.
- Limitați accesul. Accesul la jurnalele ar trebui, de asemenea, protejat cu RBAC; Citirea jurnalului ar trebui, de asemenea, înregistrată.
- Adăugați ID de corelare (ID de urmărire). Conectați toți pașii unei cereri (intrare, apel de instrument, verificare, ieșire) cu o singură identitate.
Patru șabloane copiabile
Schema jurnalului de audit (JSON):
{ "trace_id": "...", "time": "AAAA-MM-DDThh:mm:ssZ", "user": "...", "rol": "...", "model": "claude-opus-4-8", "parameters": { "temperature": 0 }, "request_summary": "<mask", <mask>> "tools": ["tool_a", "tool_b"], "decizie": "auto|human_approval", "approval": "aprobat|respins|niciunul", "rezultat": "succes|eroare", "afected_resource": "..."}
Solicitare de control PII în jurnal:
Consultați exemplele de jurnal de mai jos. Câmpurile necesare pentru pista de audit (cine, când, model, decizie, rezultat) sunt complete? De asemenea, au fost scurse PII brute? Pentru fiecare rând, raportați ca: „nu este suficient / lipsește spațiu: ... / scurgere IPI: ...” <logs>{{ exemple }}</logs>
Solicitare de reconstruire a evenimentului:
Următoarele înregistrări de audit aparțin unui singur trace_id. Transformați evenimentul într-o narațiune în ordine cronologică: ce a dorit utilizatorul, ce a făcut modelul, ce validări au rulat, cum a fost luată decizia, care a fost rezultatul? Semnalați pașii lipsă sau inconsecvenți.<records>{{ trace_registers }}</records>
Regula de decizie privind politica de păstrare:
Pentru fiecare tip de buștean, determinați:- Există o obligație legală de păstrare? (perioada minimă, dacă există) - Conține PII? (dacă este inclus, scurtați durata, restrângeți accesul)- Dovada incidentului de securitate? (magazinul nu poate fi schimbat)Rezultat: „magazin N zile + numai adăugare mi + nivel de acces”.
Solicitare slabă / Solicitare puternică
abordare slabă
Abordare puternică
Nu te conectezi deloc („nu este nevoie”)
Înregistrarea setului minim pentru a reconstrui evenimentul
Înregistrare prompt/răspuns brut ca atare
Rezumat mascat + înregistrare ID urmărire
Stocați jurnalele nelimitat
Perioada de păstrare cu echilibru legal + confidențialitate
Oricine poate șterge jurnalele
Jurnalele critice sunt doar anexate, accesul controlat
Trei mini carcase
Cazul 1 — Trace ID a redus investigația unei zile la 15 minute. „Solicitarea mea a fost respinsă pe nedrept”, i-a spus un client asistentului de pre-evaluare a creditului unei bănci. Datorită ID-ului de corelare, echipa a reconstruit intrarea acelei aplicații, verificările angajaților și decizia în 15 minute; a arătat că eroarea a fost cauzată de un prag incorect în validarea unei reguli și a remediat-o.
Cazul 2 — În cadrul auditului a fost descoperită o înregistrare excesivă. O companie de comerț electronic scria toate solicitările/răspunsurile la jurnalele brute pentru depanare. În cadrul auditului anual s-a constatat că aceste jurnale au conținut adrese și numere de telefon ale clienților și au fost păstrate timp de 2 ani. Constatarea a fost închisă prin trecerea la o politică de mascare + 90 de zile; Funcția de urmărire de audit a fost păstrată.
Cazul 3 — Jurnalul numai pentru atașare a dezvăluit un abuz intern. Un angajat de la un furnizor a încercat să ștergă jurnalele pentru a ascunde un lot eronat pe care l-a făcut. Întrucât jurnalele sunt numai pentru atașare și încercările de citire/ștergere a jurnalelor sunt înregistrate, încercarea a fost imediat vizibilă; Incidentul a dus la corectarea disciplinară și a procesului.
Sfat: Atribuiți un ID de corelare (ID de urmărire) fiecărei solicitări și efectuați-l prin toți pașii. Când apare o problemă, posibilitatea de a colecta „totul despre acea cerere” cu o singură interogare este cel mai mare accelerator al răspunsului la incident.
Greșeli comune
- Nu vă înregistrați deloc sau înregistrați atât de puțin încât să nu puteți reconstrui evenimentul.
- Înregistrarea cererii/răspunsului brut fără mască și transformarea jurnalului într-o sursă de scurgere.
- Nu se înregistrează numele/versiunea și decizia modelului (automat/uman).
- Stocarea jurnalelor pentru o perioadă nelimitată de timp crește riscul de confidențialitate.
- Lăsarea jurnalelor critice supuse modificării; Nu se înregistrează accesul la jurnal.
- Neputând conecta pașii împreună, deoarece nu folosește un ID de corelare (ID de urmărire).
Pe scurt
- Înregistrarea AI adaugă trei dimensiuni la „cine a făcut ce”: ce model/versiune, ce prompt, ce răspuns.
- Scopul este de a menține PII suficient de minimă pentru a reconstrui evenimentul prin mascarea acestuia - nici mai mult, nici mai puțin.
- Pista de audit ar trebui să includă câmpurile cine/când/ce/ce model/decizie/rezultat.
- Jurnalele critice ar trebui să fie doar anexate, accesul ar trebui să fie limitat și accesul la jurnal ar trebui, de asemenea, înregistrat.
- ID-ul de corelare (ID-ul de urmărire) conectează toți pașii unei cereri și accelerează investigarea incidentului.
Sarcina de aplicare
Selectați o solicitare din propriul flux AI și scrieți pista de audit ideală pentru aceasta cu schema JSON de mai sus. Apoi faceți două teste: (1) Puteți spune povestea de la început până la sfârșit doar cu această înregistrare? (2) Există PII brute în înregistrare? Dacă lipsește un câmp, adăugați-l, dacă există PII, mascați-l. În cele din urmă, setați o perioadă de păstrare și un nivel de acces.
lista de verificare
- [ ] Pista de audit include câmpurile cine/când/ce/model/decizie/rezultat.
- [ ] Promptul/răspunsul este mascat înaintea jurnalelor (fără PII).
- [ ] Fiecărei cereri i se atribuie un ID de corelare (ID de urmărire).
- [ ] Jurnalele critice sunt numai pentru atașare și accesul controlat.
- [ ] Perioada de stocare este definită de soldul legal + confidențialitate și este ștearsă la sfârșitul perioadei.
- [ ] Cu jurnalele pot reconstrui un eveniment în mai puțin de 30 de minute.