Când se aplică documentația tehnică și ce trebuie făcut în continuare

Documentația tehnică este o obligație specifică a AI Act atunci când o companie este furnizorul unui sistem cu risc ridicat. Articolul 11 cere ca documentația să fie pregătită înainte de introducerea pe piață sau punerea în funcțiune, menținută la zi și suficient de clară pentru ca autoritățile și organismele notificate să evalueze conformitatea. Anexa IV stabilește conținutul minim.

Prin urmare, nu fiecare companie SaaS care utilizează un API AI are nevoie de un dosar complet. Răspunsul depinde de limita sistemului, rolul companiei și clasificare. Chiar fără obligație directă, un dosar proporțional ajută guvernanța produsului, evaluarea furnizorilor, clienții, incidentele și reevaluările.

Confirmați sistemul, rolul și clasificarea

Descrieți întregul sistem: scop, utilizatori, persoane afectate, intrări, ieșiri, integrări, context și influența rezultatului. Un model extern poate fi doar o componentă a produsului SaaS.

Stabiliți apoi rolul. Compania care dezvoltă și comercializează sub numele propriu un sistem cu risc ridicat este, de regulă, furnizor; clientul poate fi implementator. Rebrandingul, modificarea substanțială sau un scop nou pot schimba responsabilitățile. Evaluați cele două rute principale din articolul 6: produsele reglementate din anexa I și utilizările din anexa III. Consultați ghidul pentru furnizorii SaaS.

Când se aplică articolul 11

Articolul 11 și anexa IV privesc documentația sistemelor cu risc ridicat și plasează obligația principală asupra furnizorului. După Regulamentul (UE) 2026/1744, normele pentru sistemele din anexa III se aplică din 2 decembrie 2027, iar cele pentru sistemele integrate în produsele din anexa I din 2 august 2028.

Nu așteptați aceste date. Dreptul sectorial, protecția datelor, contractele, securitatea și verificările clienților pot solicita deja dovezi similare. Începerea timpurie evită reconstruirea versiunilor, datelor, testelor și deciziilor.

Dacă sistemul nu este cu risc ridicat sau compania este doar implementator, dosarul complet poate să nu fie necesar. Înregistrați totuși decizia, faptele, revizorul și declanșatoarele reevaluării. Un scop sensibil nou, schimbări materiale ale modelului sau datelor, piețe noi ori impact mai mare asupra persoanelor trebuie să redeschidă analiza.

Acoperirea minimă

Anexa IV solicită cel puțin:

1. Identitate, scop, versiuni, utilizatori și condiții de operare.
2. Dezvoltare, arhitectură, componente și decizii de proiectare.
3. Proveniența datelor, validare, teste și limite de performanță.
4. Riscuri, controale, supraveghere umană, jurnale și escaladare.
5. Robustețe, securitate cibernetică și rezultate nedorite previzibile.
6. Modificări, incidente și monitorizare ulterioară introducerii pe piață.
7. Standarde, calea de conformitate și aprobări.
8. Trasabilitatea fiecărei afirmații la o dovadă controlată.

Dosarul poate fi un index către evidențe controlate. Legăturile stabile, permisiunile, versiunile și păstrarea contează mai mult decât numărul de pagini.

Flux practic

1. Aprobați domeniul: înregistrați identificator, scop, limită, rol, clasificare și ipoteze.
2. Creați indexul anexei IV: includeți sursă, proprietar, versiune, statut, revizor și declanșator.
3. Păstrați dovada la proprietarul real: produsul răspunde de scop; ingineria, de arhitectură; datele sau ML, de evaluări; securitatea, de controale; conformitatea, de mapare.
4. Închideți întâi lacunele critice: clasificare, performanță, riscuri, supraveghere și aprobarea lansării.
5. Legați schimbările: scopul, modelele, datele, pragurile, utilizatorii, integrările sau controalele trebuie să declanșeze actualizări și, dacă este necesar, teste noi.
6. Testați recuperarea: un revizor independent trebuie să urmărească o afirmație de performanță, un control, o cale de supraveghere și o versiune până la dovezi.

Lista de verificare a documentației tehnice oferă o structură detaliată. Răspunsurile pentru clienți trebuie să corespundă și controalelor AI solicitate de cumpărători.

Greșeli frecvente

• Începerea cu un șablon înainte de stabilirea domeniului și dovezilor.
• Documentarea modelului, nu a întregului sistem.
• Tratarea documentelor furnizorului drept dovadă pentru configurația proprie.
• Nereevaluarea unei concluzii de risc scăzut.
• Menținerea unui dosar de audit separat de lansări și schimbări.

Exemplu: selectarea asistată a candidaților

Pentru o funcție care ordonează candidaturi, echipa trebuie să definească scopul, furnizorul, limita și analiza anexei III. Dacă furnizează un sistem cu risc ridicat, dosarul acoperă versiuni de producție, date, fluxul clientului, evaluări pe grupuri, indicatori, limite, verificare umană, jurnale, securitate și monitorizare. Schimbarea modelului sau pragului trebuie să redeschidă înregistrările asociate.

FAQ

Când se aplică echipelor SaaS?

Articolul 11 se aplică furnizorilor de sisteme cu risc ridicat. Confirmați limita, rolul și clasificarea înainte de a trata dosarul complet ca obligație legală.

Ce trebuie documentat mai întâi?

Scopul, limita, rolul, clasificarea, versiunea de producție, arhitectura, riscurile, evaluările, controalele, instrucțiunile și proprietarii.

Pot fi reutilizate documentele de inginerie?

Da. Conectați surse actuale și controlate și arătați în index cerința și versiunea acoperite.

Surse

• Regulamentul (UE) 2024/1689, articolele 6 și 11 și anexele I, III și IV.
• Regulamentul (UE) 2026/1744 privind documentația și datele aplicării.
• Comisia Europeană, „AI Act”, calendarul actual de implementare.