Documentația tehnică: ghid practic pentru echipe SaaS

Documentația tehnică a unui sistem AI nu este un rezumat de arhitectură scris la finalul proiectului. Este dosarul controlat de dovezi care explică scopul sistemului, cum a fost construit, ce date și modele folosește, cum performează, ce riscuri au fost identificate, ce controale le tratează și cum sunt gestionate schimbările după lansare.

Pentru furnizorii de sisteme AI cu risc ridicat, articolul 11 din AI Act cere ca dosarul să fie pregătit înainte de introducerea pe piață sau punerea în funcțiune, menținut actualizat și suficient de clar pentru ca autoritățile și organismele notificate să poată evalua conformitatea. Anexa IV stabilește conținutul minim. Echipa SaaS trebuie să adune dovezi din produs, engineering, date, securitate, juridic și calitate în timpul dezvoltării, nu să le reconstruiască în timpul unui audit.

Obligația nu se aplică automat oricărei funcții AI. Domeniul depinde de clasificare și de rolul companiei. Documentează-le mai întâi, apoi construiește un dosar proporțional cu obligațiile și riscurile reale.

De ce contează în practică

O documentație bună arată că testele corespund scopului preconizat, leagă răspunsurile pentru clienți de dovezi controlate și ajută la decizia dacă o schimbare de model, date, prag sau workflow cere reevaluare. Evaluatorul primește o poveste coerentă, nu capturi fără context.

Dosarul conectează cerințe de produs, diagrame, model cards, proveniența datelor, evaluări, registrul riscurilor, teste de securitate, supraveghere umană, loguri, incidente, aprobări de release și monitorizare post-market. Un index central poate trimite la aceste surse fără să le dubleze.

Acest demers susține și noile așteptări de AI governance pentru furnizorii SaaS.

Confirmă domeniul

Stabilește dacă software-ul este un sistem AI, dacă are risc ridicat și ce rol joacă firma. Cine dezvoltă și comercializează sub nume propriu poate fi furnizor. Cine folosește sistemul altuia poate fi implementator, dar rebrandingul, modificarea substanțială sau schimbarea scopului pot schimba analiza.

Riscul ridicat poate rezulta din articolul 6 alineatul (1) și anexa I pentru produse reglementate sau componente de siguranță, ori dintr-un caz din anexa III în baza articolului 6 alineatul (2). Proiectele de orientări publicate de Comisie în mai 2026 sunt utile, dar nu obligatorii juridic.

Regulamentul (UE) 2026/1744 a modificat calendarul: secțiunile 1, 2 și 3 din capitolul III, inclusiv articolul 11, se aplică de la 2 decembrie 2027 sistemelor din anexa III și de la 2 august 2028 celor din anexa I. Alte legi, contracte sau angajamente față de clienți pot cere dovezi similare mai devreme.

Nu confunda acest dosar cu obligațiile separate pentru furnizorii modelelor AI de uz general din articolul 53 și anexa XI. Informațiile furnizorului de model sunt un input; furnizorul SaaS trebuie să documenteze întregul sistem, integrarea, scopul, controalele și performanța evaluată.

Ce așteaptă anexa IV

Folosește anexa ca matrice de acoperire:

1. Identitate și scop: furnizor, nume, versiune, utilizatori, scop, formă de livrare, interfețe, dependențe și UI.
2. Dezvoltare: metode, componente terțe sau preantrenate, alegerea modelului, obiective, ipoteze și decizii-cheie.
3. Arhitectură: componente, interacțiuni, resurse de calcul și justificarea alegerilor.
4. Date: sursă, selecție, etichetare, curățare, governance, limite și seturi de training, validare, test sau retrieval.
5. Capabilități și limite: metrici, acuratețe, robustețe, securitate cibernetică, rezultate nedorite previzibile și degradare.
6. Teste: protocoale, date, praguri, date calendaristice, versiuni, rezultate, eșecuri și remedieri.
7. Risc și supraveghere: risk management, măsuri, risc rezidual, supraveghere umană și instrucțiuni.
8. Ciclu de viață: versiuni, logging, change management, mentenanță, incidente și monitorizare post-market.
9. Conformitate: standarde, specificații, declarația UE și documentele organismului notificat, dacă sunt necesare.

Fiecare afirmație trebuie să ducă la o dovadă concretă. O trimitere la raport, metrică aprobată, dataset, versiune și limitare reziduală este verificabilă; „sistemul este robust” nu este.

Workflow operațional

1. Creează un index controlat

Folosește un rând pentru fiecare element al anexei IV: cerință, aplicabilitate, sursă, responsabil, versiune, aprobare, ultima revizuire și următorul trigger. „Nu se aplică” cere justificare și aprobare. Controlul accesului, istoricul și referințele stabile sunt esențiale.

2. Atribuie dovezile celor care le produc

Product acoperă scopul, utilizatorii, contextul și utilizarea greșită previzibilă. Engineering acoperă arhitectura, dependențele, versiunile și schimbările. Data sau ML acoperă proveniența, dezvoltarea, evaluările și limitele. Security acoperă amenințările, accesul, reziliența și vulnerabilitățile. Legal și compliance acoperă clasificarea, rolurile, mappingul normativ și guvernanța documentelor. Un owner central coordonează fără să rescrie fapte tehnice neverificate.

3. Fixează baseline-ul înainte de teste

Definește scopul și versiunea înainte de acceptarea rezultatelor. Înregistrează modelele, prompturile relevante, sursele de retrieval, feature flags, pragurile, dependențele și mediul. Pentru sisteme probabilistice, păstrează versiunea datasetului, metoda, pragul de acceptare, data, rezultatele reproductibile și limitele.

4. Leagă riscurile, controalele și testele

Fiecare risc material trebuie să conducă la o măsură, un responsabil și o dovadă de eficacitate. Dacă controlul este uman, descrie cine verifică, ce informații primește, dacă poate anula outputul, cum escaladează excepțiile și cum este dovedită execuția.

5. Integrează dosarul în releases

Fiecare release substanțial are nevoie de o verificare a impactului asupra documentației. Schimbările de scop, model, date, prag, utilizatori, țară, integrare, supraveghere sau securitate pot cere teste noi și actualizări ale riscurilor, instrucțiunilor și analizei de conformitate.

Checklist minim

Echipa trebuie să poată găsi: descrierea, rolul și clasificarea aprobate; diagrame actuale de arhitectură și flux cu versiuni; registrul modelelor, bibliotecilor, API-urilor și dependențelor; sursa și governance-ul datelor; planuri, metrici, praguri, rezultate și limite ale evaluării; riscuri legate de controale și acceptări; dovezi ale supravegherii umane; înregistrări de securitate, robustețe, loguri, incidente și monitorizare; instrucțiuni aliniate sistemului testat; istoricul release-urilor și documentele de conformitate.

Greșeli frecvente

Un template gol produce generalități fără dovezi. Un model card nu descrie întregul workflow SaaS. Documentele vendorului sunt inputuri, nu înlocuiesc analiza integrării. Ascunderea limitelor este mai greu de apărat decât explicarea lor cu măsuri. Calendarul nu este suficient: releases, incidente, date noi, utilizări și schimbări legislative declanșează revizuirea. Chestionarele clienților, paginile de produs, instrucțiunile, riscurile și dosarul trebuie să descrie același sistem.

Exemplu: selecția candidaților asistată de AI

Pentru o funcție care clasifică aplicații, dosarul include scopul, utilizările nesuportate, workflow-ul clientului, persoanele afectate, datele, logica de ranking, versiunile, grupurile evaluate, metricile, pragurile, verificarea umană, logurile, securitatea și monitorizarea.

Dacă evaluarea arată recall mai mic pentru un grup relevant, păstrează rezultatul, analiza, măsura, retestarea și decizia privind riscul rezidual. O schimbare ulterioară de model sau prag trebuie să redeschidă elementele asociate.

FAQ

Orice companie SaaS are nevoie de un dosar din anexa IV?

Nu. Articolul 11 și anexa IV privesc sistemele cu risc ridicat și obligația principală a furnizorului. Un dosar proporțional rămâne util pentru governance și clienți.

Pot fi refolosite documentele de engineering?

Da, dacă sunt controlate și actuale, iar un index arată acoperirea. Evită copiile divergente.

Cine trebuie să fie responsabil?

Un owner desemnat coordonează; product, engineering, ML/data, security, legal și compliance rămân proprietarii dovezilor lor.

Când se actualizează?

Când se schimbă scopul, versiunile, datele, integrările, utilizatorii, performanța, riscurile, controalele sau monitorizarea, înainte de releases substanțiale și după incidente.

Este disponibil formularul simplificat pentru IMM-uri?

Articolul 11 prevede un formular simplificat. Verifică materialele oficiale actuale înainte de a folosi un template. Până la un formular aplicabil, menține o matrice completă a anexei IV cu dovezi proporționale.

Surse

• Regulamentul (UE) 2024/1689, în special articolele 6, 9–17 și 43 și anexa IV.
• Regulamentul (UE) 2026/1744, cu datele modificate.
• Proiectul orientărilor Comisiei privind clasificarea cu risc ridicat, mai 2026.
• Orientările Comisiei pentru furnizorii de modele AI de uz general.