Cand se aplica obligatiile furnizorului si ce faci dupa

Obligatiile furnizorului se aplica atunci cand o companie SaaS este responsabila pentru un sistem AI sau un model AI de uz general conform EU AI Act. Nu conteaza doar cine a scris codul modelului. Conteaza si daca firma dezvolta sistemul, il comanda, il ofera sub propriul nume, il introduce pe piata UE, modifica substantial un sistem high-risk, schimba scopul intentionat sau furnizeaza un model GPAI.

Pasul urmator este operational: deschide un registru pentru obligatiile furnizorului, documenteaza activul AI, scopul intentionat, rolul, traseul de risc, obligatiile declansate, ownerul dovezilor si gate-ul de lansare.

De ce conteaza practic

Aceste obligatii arata cine trebuie sa dovedeasca faptul ca sistemul a fost proiectat, documentat, evaluat, monitorizat si sustinut. Pentru sistemele high-risk, articolul 16 include sistem de calitate, documentatie tehnica, loguri, evaluare de conformitate, declaratie UE de conformitate, marcaj CE cand este necesar, inregistrare, actiuni corective si cooperare cu autoritatile.

In SaaS, intrebarea apare in munca obisnuita de produs: functie de scoring AI, model tert integrat, modul rebranduit, schimbare de scop sau API pentru un model fine-tuned.

Cand se aplica

Incepe cu rolurile. Aceeasi companie poate fi deployer pentru un tool intern, furnizor pentru o functie client-facing, distribuitor pentru un tool integrat si furnizor GPAI pentru un API. "Folosim AI de la vendor" nu este suficient pentru decizii de release.

Trigger-e comune includ functii AI pentru clienti, module white-label, ranking sau scoring, recomandari automate, contexte high-risk, modele noi, surse noi de date, segmente noi de clienti si pozitionare noua a produsului.

Ce documentezi mai intai

Registrul minim raspunde la sase intrebari: ce activ AI este, care este scopul, ce rol joaca firma, ce traseu de obligatii se aplica, ce dovezi sunt necesare si cand trebuie reevaluat.

Include documentatie tehnica, registre de risc, data governance, teste, decizii de logging, human oversight, instructiuni pentru clienti, documente vendor, monitorizare si aprobari de release.

Integreaza in delivery

Workflow-ul trebuie sa existe in product discovery, architecture review, vendor review, release readiness si monitorizare post-lansare. Product descrie use case-ul. Engineering aduce faptele tehnice. Legal sau compliance interpreteaza rolurile si obligatiile. Security valideaza controalele. Echipele customer folosesc explicatii aprobate.

Greseli comune

Prima greseala este presupunerea ca vendorul modelului este intotdeauna furnizorul sistemului. Alte greseli sunt inventare AI fara campuri de rol, raspunsuri juridice unice, informatii downstream pierdute pentru clienti si dovezi separate de release.

FAQ

Care este scopul practic?

Sa identifici cine este responsabil pentru sistemul AI sau modelul GPAI si sa legi rolul de documentatie, controale de risc, informatie pentru clienti, monitorizare si dovezi.

Cand se aplica pentru SaaS?

Cand echipa dezvolta, comanda, ofera sub propriul nume, pune pe piata, modifica substantial, schimba scopul sau furnizeaza un model GPAI.

De unde incepi?

Cu un registru pentru activ, scop, rol, traseu de risc, obligatii, owner de dovezi, locatie documentatie, gate de lansare si trigger-e de reevaluare.