Când se aplică jurnalizarea și păstrarea evidențelor și ce urmează

Jurnalizarea și păstrarea nu se aplică identic fiecărei funcții SaaS. Articolele 12, 19 și 26 din AI Act vizează sistemele AI cu grad ridicat de risc și depind de rolul de furnizor sau implementator și de jurnalele controlate. Alte sisteme pot necesita evidențe pentru securitate, confidențialitate, contracte, calitate sau incidente, fără ca aceste motive să fie confundate cu obligațiile de risc ridicat.

Începeți cu domeniul: sistem, scop preconizat, flux, rol, clasificare și întrebări probatorii. Apoi înregistrați doar evenimentele și deciziile necesare pentru trasabilitate, monitorizare, supraveghere și investigații. Protejați-le, justificați termenele și testați dacă un evaluator autorizat poate reconstrui un eveniment important.

Ce impune AI Act

Articolul 12 cere ca sistemele cu risc ridicat să permită tehnic înregistrarea automată a evenimentelor pe durata ciclului de viață. Aceasta trebuie să asigure trasabilitate adecvată scopului, să ajute la identificarea riscurilor sau modificărilor substanțiale și să sprijine monitorizarea ulterioară introducerii pe piață și monitorizarea operațională.

Pentru furnizori este o cerință de proiectare. Articolul 19 îi obligă să păstreze jurnalele automate sub controlul lor; articolul 26 impune obligația paralelă implementatorilor. Minimul general este șase luni, dacă altă lege aplicabilă nu prevede diferit, iar durata trebuie să corespundă scopului. Separat, furnizorul păstrează anumite documente tehnice, de calitate și conformitate timp de zece ani.

Nu există o schemă universală. Articolul 12 precizează date pentru anumite sisteme biometrice, iar în rest proiectarea trebuie să fie proporțională. Consultați ghidul AI Act pentru furnizorii SaaS.

Când se aplică obligațiile

Răspundeți la patru întrebări: funcția este un sistem AI; este de risc ridicat potrivit articolului 6 și anexei I sau III; ce rol are compania; ce jurnale controlează în realitate? Regulile convenționale și automatizarea nu devin AI doar fiindcă procesează date. Scopul preconizat și excepțiile contează.

O companie care dezvoltă și comercializează sub numele propriu poate fi furnizor; cea care utilizează sistemul altuia sub autoritatea sa poate fi implementator. Un scop nou, rebrandingul sau o modificare substanțială pot schimba analiza. Furnizorul și clientul controlează deseori părți diferite ale lanțului probatoriu.

Modificarea din 2026 a stabilit 2 decembrie 2027 pentru articolul 6 alineatul (2) și anexa III și 2 august 2028 pentru articolul 6 alineatul (1) și anexa I. Folosiți timpul de pregătire: dovezile istorice absente nu pot fi create ulterior.

Când contează alte evidențe

În afara riscului ridicat pot fi necesare evenimente de autentificare, configurare și incident; dovezi de consimțământ, solicitare, acces sau ștergere; istorice de serviciu și schimbare; versiuni, evaluări, aprobări și rollback. Pentru fiecare clasă indicați scopul juridic, contractual, de securitate sau operațional real.

„Nu este de risc ridicat” nu înseamnă „nu păstrați nimic”, dar AI Act nu justifică nici stocarea nelimitată a prompturilor, documentelor, rezultatelor și identităților. Uneori ajunge un identificator, o referință protejată, un hash, un rezultat structurat sau un eșantion.

Flux practic

1. Documentați scopul, utilizatorii, persoanele afectate, decizia, intrările, ieșirile, mediile, integrările, modelele, sursele, acțiunile ulterioare și revizuirea umană.
2. Înregistrați rolul, clasificarea, faptele, evaluatorul, aprobarea, incertitudinile și factorii de reevaluare. Pentru terți folosiți întrebările înaintea adoptării instrumentelor AI interne.
3. Definiți întrebări: ce versiune a produs rezultatul, ce surse și controale au fost folosite, a existat revizuire umană și ce acțiune a urmat?
4. Corelați întrebările cu evidențele minime: identificator, timp fiabil, versiuni, context, referințe, rezultat al controlului, acțiune umană, rezultat ulterior și integritate.
5. Numiți un responsabil general și responsabili pentru instrumentare, acces, confidențialitate, solicitări, excepții, ștergere și remediere. Aplicați autentificare puternică, criptare, limite la export și monitorizare.
6. Stabiliți termene pe clase și testați separat reconstrucția și ștergerea în producție, analytics, exporturi, arhive și backupurile aplicabile.

Erori și următorii pași

Telemetria obișnuită nu este automat o pistă de audit: disponibilitatea și latența explică rar configurația, controalele și acțiunile umane. O singură parte nu controlează neapărat întregul lanț; contractele, documentația și configurația reală trebuie să coincidă. Nu aplicați șase luni tuturor datelor și nu proiectați doar pentru audit. Reevaluați la lansări, schimbări de furnizor, riscuri și incidente. Vedeți greșelile frecvente de jurnalizare.

Alegeți un flux important și creați o fișă cu limită, scop, rol, clasificare, surse, întrebări, responsabili și declanșatori. Corelați cinci-zece întrebări cu evidențele minime și efectuați un test independent înaintea următoarei versiuni. Abordarea urmează noile așteptări de AI governance și controalele cerute de cumpărători.

FAQ

Se aplică fiecărei funcții AI?

Nu. Articolele discutate privesc sisteme cu risc ridicat; alte scopuri pot necesita totuși evidențe.

Furnizorul și implementatorul păstrează aceleași jurnale?

Nu neapărat. Fiecare păstrează jurnalele automate relevante aflate sub controlul său.

Șase luni sunt întotdeauna corecte?

Nu. Este minimul general pentru jurnalele de risc ridicat vizate, sub rezerva altui drept. Alte clase pot avea termene diferite.

Surse

• Regulamentul (UE) 2024/1689, articolele 12, 18, 19 și 26.
• Regulamentul (UE) 2026/1744 privind datele modificate.
• Comisia Europeană, „AI Act”, calendarul actual.