Jurnalizare și păstrarea evidențelor: ghid practic pentru echipe SaaS

În AI Act, jurnalizarea și păstrarea sunt controale de trasabilitate, nu o instrucțiune de a colecta nelimitat orice date. Pentru sistemele AI cu risc ridicat, articolul 12 cere posibilitatea tehnică de a înregistra automat evenimente pe durata ciclului de viață. Furnizorii și implementatorii trebuie să păstreze logurile automate aflate sub controlul lor pentru o perioadă adecvată scopului și, de regulă, cel puțin șase luni, dacă altă lege nu prevede diferit.

Obligațiile nu se aplică automat oricărei funcții AI sau firme SaaS. Echipa trebuie întâi să identifice sistemul, scopul, rolul propriu și clasificarea și să distingă logurile furnizorului de cele controlate de client sau un vendor din amonte. Obiectivul este un lanț de dovezi proporțional, prin care un evaluator autorizat leagă un eveniment important de versiune, contextul intrării și ieșirii, acțiunea umană, control și decizie.

Chiar înainte ca regulile pentru risc ridicat să se aplice, disciplina ajută investigațiile, monitorizarea securității, răspunsurile către clienți, gestionarea schimbărilor și deciziile de produs. Nu este supraveghere nediferențiată, ci jurnalizare deliberată cu scopuri, acces, declanșatori și limite.

Începeți cu domeniul, nu cu platforma

Documentați funcția, modelele și serviciile terțe, scopul, utilizatorii, persoanele afectate, intrările, ieșirile, integrările, mediile și deciziile influențate. Doar apelul API al modelului de bază poate omite date retrieval, reguli de business, intervenții ale utilizatorului sau acțiuni ulterioare care formează fluxul SaaS complet.

Stabiliți apoi rolul. Compania care dezvoltă sau comercializează în nume propriu un sistem cu risc ridicat poate fi furnizor; clientul care folosește sistemul altuia poate fi implementator. Rebrandingul, modificarea substanțială sau schimbarea scopului pot transfera responsabilități. Etichetele contractuale nu decid analiza.

Evaluați clasificarea. Articolul 6 acoperă sisteme asociate produselor din anexa I și cazuri din anexa III, în condițiile și excluderile Regulamentului. Clasificarea candidaților cere altă analiză decât redactarea de marketing intern. Înregistrați motivarea, evaluatorul, data, ipotezele și declanșatorii. Vedeți și cum schimbă AI governance așteptările de conformitate.

Ce cere AI Act

Conform AI Act, articolul 12 cere înregistrarea automată a evenimentelor în ciclul de viață. Funcțiile trebuie să ofere trasabilitate adecvată, să ajute la identificarea riscurilor sau modificărilor substanțiale, să sprijine monitorizarea după introducerea pe piață și să permită implementatorului să supravegheze operarea.

Evenimentele depind de sistem. Pentru anumite sisteme biometrice de identificare la distanță din anexa III, articolul 12 specifică informații minime suplimentare. Copierea acelei scheme într-un produs diferit nu demonstrează conformitatea. Evenimentele trebuie derivate din scop, riscuri, limite de performanță, supraveghere umană, instrucțiuni și plan de monitorizare.

Articolul 19 cere furnizorilor păstrarea logurilor automate sub controlul lor pentru o perioadă adecvată de cel puțin șase luni, cu excepția altor reguli UE sau naționale, mai ales privind datele. Articolul 26 stabilește un minim paralel pentru implementatori. Acesta nu autorizează păstrarea nelimitată. Calendarul trebuie să împace trasabilitatea cu minimizarea, limitarea stocării, securitatea, dreptul muncii, regulile sectoriale, contractele și incidentele.

După Regulamentul (UE) 2026/1744, cerințele se aplică de la 2 decembrie 2027 sistemelor din anexa III și de la 2 august 2028 celor din produsele reglementate ale anexei I. Calendarul Comisiei reflectă aceste date.

Ce trebuie înregistrat

Un eveniment util răspunde unei întrebări de control, nu doar dovedește că serverul funcționa:

1. Sistem și versiune: identificator stabil, model sau componentă, configurație, mediu și release.
2. Timp și corelare: marcaj temporal fiabil, ID de cerere sau tranzacție și legături între evenimente.
3. Context operațional: funcție, flux intenționat, rol de utilizator sau serviciu și setări relevante.
4. Intrare și ieșire: referințe, hashuri, rezumate sau instantanee protejate suficiente pentru o reconstrucție justificată.
5. Supraveghere umană: revizuire, aprobare, respingere, override, escaladare și autoritate.
6. Controale: verificări, praguri, filtre, acces, erori, fallback și rezultat.
7. Schimbare și monitorizare: deployments, modificări de model sau date, drift, incidente, reclamații și corecții.
8. Integritate: sursă, istoric de acces, păstrare și transformare sau ștergere.

Nu stocați automat prompturi, documente, răspunsuri sau identități complete. Uneori conținutul este esențial pentru investigarea unui prejudiciu; alteori ajung un identificator pseudonim, hash, categorie, metrică sau eșantion protejat. Decideți pe câmp conform scopurilor și riscurilor documentate.

Flux operațional

1. Formalizați decizia

Pentru fiecare sistem, înregistrați domeniul, scopul, rolul, clasificarea, obligațiile, obiectivele, categoriile și responsabilii. Separați logurile proprii de cele dependente de client sau furnizor. Notați ipoteze și declanșatori.

2. Legați întrebările de evenimente

Porniți de la întrebări: ce versiune a produs rezultatul? Revizuirea umană era necesară și a avut loc? S-a activat un control? Utilizarea respecta scopul? Ce s-a schimbat înaintea degradării? Asociați câmpurile minime fiabile și sursele.

3. Distribuiți responsabilitatea

Engineering deține de regulă instrumentarea; security, accesul, integritatea, alertele și păstrarea; product, fluxul și release-urile; data/ML, identificatorii de modele, seturi și evaluări; privacy, legalitatea și minimizarea; compliance, harta cerințelor. Un responsabil coordonează fără să inventeze faptele altora.

4. Stabiliți accesul și retenția

Separați accesul operațional de investigație. Folosiți privilegii minime, autentificare, logarea accesului, criptare și controlul exportului. Definiți începutul, ștergerea, excepțiile, holds și backupurile, plus responsabilitățile furnizor-implementator.

5. Conectați revizuirile la declanșatori

Reevaluați după modificări de model, prompt, retrieval, prag, date, integrare, scop sau supraveghere și după incident, reclamație, performanță neașteptată, utilizare neautorizată sau notificare de la vendor. Legați rezultatul de versiunea din producție.

6. Testați reconstrucția și ștergerea

Cereți unui evaluator independent să reconstruiască versiunea, controalele, acțiunile umane și reacția. Apoi testați ștergerea din stocarea principală, analytics, exporturi și backupuri. Ambele au nevoie de dovezi.

Greșeli frecvente

Jurnalizarea tuturor datelor. Crește riscurile de confidențialitate, securitate, litigii și cost fără a garanta trasabilitatea.

Confundarea telemetriei cu pista de audit AI. Uptime și erorile rareori identifică modelul, configurația, supravegherea și dovada rezultatului.

Aplicarea celor șase luni tuturor evidențelor. Minimul privește logurile automate cu risc ridicat aflate sub controlul operatorului și este supus altor legi.

Ignorarea limitelor controlului. Furnizorul nu păstrează loguri pe care nu le primește; implementatorul nu trebuie să presupună că vendorul îi păstrează contextul.

Colectarea conținutului sensibil fără protecții. Prompturile și ieșirile pot conține date sau secrete. Minimizați, separați, criptați și monitorizați.

Păstrarea evenimentelor neinterpretabile. Fără schemă, timp, versiune sau corelare pot fi inutile.

Exemplu: recrutare asistată de AI

Un furnizor SaaS clasifică aplicații. Documentează scopul, limitele, rolul și clasificarea. Evenimentele leagă modelul și configurația din producție de fiecare clasare, referințele intrărilor, ieșirea și contextul, pragurile, avertismentele, revizuirea umană, override-ul și acțiunea finală.

Accesul la conținut este limitat la investigații autorizate; monitorizarea curentă folosește date agregate unde este posibil. Decizia de retenție explică articolul 19, limitele privind datele, răspunderea clientului și termenele sectoriale. Schimbarea modelului, pragului sau revizuirii declanșează o evaluare și păstrează legătura dintre dovezi.

Designul singur nu garantează conformitatea, dar permite verificarea operării, supravegherii umane și răspunsului responsabil la schimbări și incidente.

Întrebări frecvente

Care este scopul practic?

Trasabilitatea activității importante prin legarea evenimentului de versiune, context, controale, acțiuni umane și reacție, fără date fără legătură.

Când se aplică obligațiile echipelor SaaS?

Articolele 12, 19 și 26 privesc sistemele cu risc ridicat și împart cerințele după rol și control. Confirmați sistemul, scopul, clasificarea și rolul.

Trebuie păstrat fiecare prompt și răspuns?

Nu. Trasabilitatea adecvată nu înseamnă retenție nediferențiată. Alegeți câmpurile necesare și protejați-le.

Cât timp se păstrează logurile?

În general, logurile automate cu risc ridicat sub controlul furnizorului sau implementatorului se păstrează adecvat și cel puțin șase luni. Altă lege poate cere sau limita alt termen.

De unde începe o echipă?

Inventariați sistemul, rolul, clasificarea, sursele și întrebările, apoi definiți schema, responsabilitatea, accesul, retenția, declanșatorii și testul de reconstrucție.

Surse

• Regulamentul (UE) 2024/1689, în special articolele 6, 12, 19 și 26.
• Regulamentul (UE) 2026/1744 și datele modificate.
• Comisia Europeană, „AI Act”, calendar și obligații pentru risc ridicat.