Dacă o firmă din România folosește un sistem AI făcut de altcineva, întrebarea importantă nu este doar „cine l-a construit?”, ci și „cine îl pune în piață, sub ce nume și cât de mult îl schimbă?”. În AI Act, diferența dintre provider și deployer contează direct pentru obligațiile legale, iar după 2 august 2026 acest lucru devine și mai relevant, inclusiv prin noile reguli de transparență pentru anumite sisteme AI.
Ce înseamnă, pe scurt, provider și deployer
Potrivit definițiilor din articolul 3 al AI Act, provider este entitatea care dezvoltă un sistem AI sau care îl are dezvoltat și îl pune pe piață ori îl pune în funcțiune sub propriul nume sau marcă. Deployer este entitatea care folosește sistemul AI sub autoritatea sa, cu excepția utilizării personale, neprofesionale.
Tradus pe înțelesul firmelor: dacă doar folosești un instrument AI în activitatea companiei, de regulă ești deployer. Dacă începi să îl pui în piață ca produs al tău, sub brandul tău, sau îl schimbi suficient de mult încât îi modifici rolul juridic, poți ajunge provider.
Când rămâi deployer
În scenariul cel mai comun, firma cumpără sau licențiază un sistem AI terț și îl folosește intern ori îl integrează într-un flux de lucru fără să-i schimbe substanțial funcția și fără să-l relanseze sub propria marcă. Aici, în mod normal, rolul rămâne cel de deployer.
Pentru sistemele cu risc ridicat, AI Act spune și ce înseamnă asta practic. Providerul trebuie să ofere informații clare către deployer, inclusiv despre scopul sistemului, capabilități, limitări, nivelul de acuratețe, măsuri de supraveghere umană și condiții de utilizare. La rândul lui, deployerul trebuie să folosească sistemul conform instrucțiunilor, să asigure supraveghere umană competentă și să monitorizeze funcționarea lui.
Pe scurt, dacă doar implementezi un AI terț în companie, fără să-l transformi în „produsul tău”, nu pleci automat în zona de provider.
Când poți deveni provider
Aici apare zona sensibilă. Articolul 25 din AI Act spune explicit că un distribuitor, importator, deployer sau alt terț este considerat provider al unui sistem AI cu risc ridicat în anumite situații.
Prima situație este rebrandingul. Dacă pui numele sau marca ta pe un sistem AI cu risc ridicat deja pus pe piață sau pus în funcțiune, regulamentul te poate trata ca provider. Cu alte cuvinte, simplul fapt că „nu l-am creat noi, doar l-am vândut sub brandul nostru” nu te scoate din zona de responsabilitate.
A doua situație este modificarea substanțială. Dacă faci o modificare substanțială unui sistem AI cu risc ridicat care era deja pe piață și el rămâne un sistem high-risk, poți deveni provider. Aici nu vorbim despre schimbări cosmetice, ci despre intervenții care pot afecta modul în care sistemul funcționează, performează sau riscă să producă efecte relevante.
A treia situație este schimbarea scopului intenționat. Dacă modifici scopul unui sistem AI, inclusiv al unui sistem general-purpose, astfel încât el ajunge să fie încadrat ca sistem cu risc ridicat, iar înainte nu era, rolul firmei se poate schimba din deployer în provider.
Ce înseamnă „integrare” în practică
Multe companii spun că „doar integrează” un model sau un serviciu AI terț într-o aplicație proprie. Juridic, integrarea nu are un singur răspuns. Dacă integrarea înseamnă doar conectare tehnică și utilizare conform documentației furnizorului, fără schimbarea scopului și fără rebranding ca produs AI propriu, ești mai aproape de deployer.
Dar dacă integrarea merge spre white-label, împachetare comercială sub brand propriu, schimbarea fluxului decizional sau repoziționarea sistemului pentru un scop nou și sensibil, analiza se schimbă. În special la sistemele care pot intra în zona high-risk, firma nu ar trebui să pornească de la ideea că „codul e al altcuiva, deci responsabilitatea rămâne la altcineva”.
Ce ar trebui să verifice firmele acum
Primul pas este să stabilească exact rolul jucat față de fiecare sistem AI: folosire internă, integrare tehnică, distribuție, white-label sau dezvoltare pe comandă.
Al doilea pas este să verifice dacă sistemul intră sau poate intra în categoria high-risk, pentru că articolul 25 devine esențial aici.
Al treilea pas este să documenteze ce modificări fac efectiv: interfață, logică de decizie, setări, date de intrare, destinație comercială, branding și scop declarat.
Al patrulea pas este contractual: cine oferă instrucțiunile de utilizare, cine gestionează actualizările, cine răspunde pentru incidente și cine dovedește conformitatea.
Concluzia utilă
În AI Act, rolul firmei nu depinde doar de cine a scris primul cod. Depinde de cine pune sistemul pe piață, sub ce nume, pentru ce scop și cât de mult îl schimbă. Dacă doar folosești un AI terț, de regulă ești deployer. Dacă îl rebranduiești, îl modifici substanțial sau îi schimbi scopul astfel încât intră în zona high-risk, poți deveni provider, cu obligații mult mai mari.
Pentru cazurile concrete, mai ales când există integrare comercială, white-label sau utilizări sensibile, sursele oficiale trebuie verificate direct, iar analiza juridică trebuie făcută pe situația exactă a firmei.
Surse
- AI Act Service Desk — Article 3: Definitions
- AI Act Service Desk — Article 13: Transparency and provision of information to deployers
- AI Act Service Desk — Article 25: Responsibilities along the AI value chain
- AI Act Service Desk — Article 26: Obligations of deployers of high-risk AI systems
- European Commission — Safer and more transparent AI, 2 August 2026
- European Commission — AI Act enters into force, 1 August 2024
