Greșeli frecvente de documentație tehnică

Greșelile obișnuite nu țin de formatare, ci de domeniu, dovezi, responsabilitate și controlul schimbărilor. Un dosar poate părea complet, dar să fie imposibil de verificat. Articolul 11 din AI Act obligă furnizorii sistemelor cu risc ridicat să pregătească documentația înainte de introducerea pe piață sau punerea în funcțiune și să o mențină actualizată. Anexa IV stabilește conținutul minim. Regulamentul (UE) 2026/1744 simplifică prezentarea pentru anumite organizații mici, dar nu reduce nevoia de a susține afirmațiile.

Nu orice companie SaaS este furnizorul unui sistem cu risc ridicat. Confirmați mai întâi limita sistemului, rolul și clasificarea.

1. Documentarea modelului, nu a sistemului

O fișă de model sau de furnizor nu descrie prompturile, fluxurile de date, interfețele, supravegherea umană, jurnalele și acțiunile ulterioare. Definiți limita și înregistrați componentele, actorii, intrările, ieșirile și controalele. Separați informațiile furnizorului de faptele verificate intern. Ghidul AI Act pentru furnizorii SaaS ajută la stabilirea rolului și domeniului.

2. Începerea cu un șablon narativ

Șabloanele mari produc texte plauzibile despre testare și supraveghere înainte să existe dovezi. Începeți cu un index: cerință, artefact sursă, versiune, proprietar, evaluator, stare și declanșator de actualizare. Scrieți explicația numai din surse controlate.

3. Confundarea politicilor cu dovezile

O politică spune ce ar trebui să se întâmple; dovada arată ce s-a întâmplat pentru o versiune precisă. Cerințele aprobate, deciziile de arhitectură, evidențele datelor, evaluările, modelele de amenințări, aprobările versiunilor și revizuirile monitorizării sunt utile. Fiecare dovadă trebuie să indice afirmația, sursa, data, versiunea și responsabilul.

4. Pierderea trasabilității versiunilor

Diagramele suprascrise, testele fără versiunea modelului sau setului de date și tablourile schimbătoare rup lanțul. Dați sistemului un identificator stabil și legați fiecare artefact de versiune, model, configurație și dată. Din producție, evaluatorul trebuie să găsească cerințele, arhitectura, testele, riscurile, controalele, instrucțiunile și aprobarea.

5. Atribuirea întregului dosar conformității

Conformitatea coordonează standardul și contestă afirmațiile slabe, dar nu trebuie să redacteze fapte tehnice din relatări indirecte. Produsul deține scopul; ingineria, arhitectura și schimbările; datele sau ML, evaluările; securitatea, controalele; managementul lansării, ceea ce a fost livrat. Un responsabil central gestionează acoperirea fără a crea fiecare dovadă.

6. Tratarea documentației ca sarcină unică

Modelele, datele, furnizorii și riscurile se schimbă. Adăugați o verificare de impact la schimbări de scop, limită, model, date importante, performanță, supraveghere, securitate, instrucțiuni sau monitorizare. Revizuirea periodică este o plasă de siguranță; controlul principal trebuie declanșat de evenimente. O structură bună accelerează și auditurile.

7. Măsurarea activității, nu a calității

Numărul de documente sau tichete închise nu dovedește calitatea. Măsurați completitudinea inițială, lacunele importante, excepțiile expirate, linkurile rupte, diferențele de versiune și timpul de actualizare. Dacă evaluatorul trebuie să intervieveze autorul, dovada nu este autonomă.

8. Acceptarea afirmațiilor furnizorului fără verificare

Certificatele și fișele pot privi altă versiune, limbă, populație sau mediu. Înregistrați documentul exact, evaluați diferența față de utilizarea proprie și testați comportamentul relevant. Lipsa informației este un risc sau o lacună, nu o bază pentru presupuneri.

9. Ascunderea lacunelor în excepții vagi

„De completat ulterior” nu este o decizie controlată. Înregistrați lacuna, motivul, controlul temporar, proprietarul riscului, aprobarea, remedierea și expirarea. Un model clar de responsabilitate pentru conformitate previne excepțiile permanente.

Revizuire concentrată

1. Confirmați limita, rolul, clasificarea, scopul și versiunea curentă.
2. Creați indexul anexei IV și legați sursele controlate.
3. Verificați câte o afirmație despre arhitectură, performanță, risc, supraveghere și schimbare.
4. Confirmați identificatori consecvenți și rezultate reproductibile.
5. Dați fiecărei lacune proprietar, importanță, acțiune și dată.
6. Integrați declanșatoare în produs, furnizori, securitate și lansare.

Întrebări frecvente

Care este scopul practic?

Să explice trasabil ce este sistemul, cum a fost dezvoltat și evaluat, ce riscuri și controale se aplică și de ce cerințele sunt considerate îndeplinite.

Când se aplică echipelor SaaS?

Articolul 11 se aplică furnizorilor sistemelor cu risc ridicat. Confirmați limita, rolul și clasificarea înainte de a trata anexa IV ca obligație directă.

Ce trebuie remediat mai întâi?

Scopul, versiunea, arhitectura, evaluarea, riscurile materiale, supravegherea umană, instrucțiunile și aprobarea lansării. Rezolvați întâi contradicțiile și afirmațiile importante fără suport.

Surse

• Regulamentul (UE) 2024/1689, în special articolul 11 și anexa IV.
• Regulamentul (UE) 2026/1744, inclusiv simplificările documentației tehnice.