Cum evaluezi OpenAI și alți furnizori AI

Checklist în 20 de întrebări pentru OpenAI și alți furnizori AI: roluri, date, retenție, subprocessatori, securitate, schimbări și exit.

Publicat 1 august 20265 minute

AI ACT · PROCUREMENT TEHNOLOGIC

O evaluare de furnizor AI nu este o colecție de logo-uri de securitate. Trebuie să lege produsul cumpărat de cazul tău de utilizare, datele trimise, rolul juridic, lanțul tehnic și posibilitatea reală de a schimba sau opri serviciul.

Începe cu produsul și rolul, nu cu numele companiei

Același furnizor poate oferi o aplicație pentru persoane, un workspace business, API, modele găzduite și conectori cu condiții diferite. Evaluează configurația pe care o vei folosi. Apoi stabilește dacă organizația este deployer al unui sistem, furnizor al unei soluții sub propriul nume sau are alt rol; integrarea unui model upstream nu produce automat o singură clasificare. ^[EU-REG] ^[EU-GPAI-G] ^[EU-DESK]

Primele patru întrebări fixează obiectul achiziției. Fără ele, răspunsurile despre retenție, locație sau securitate pot fi corecte pentru alt produs și inutile pentru proiectul tău. ^[EU-GPAI-G] ^[OAI-DPA]

1. Ce produs, model, versiune, regiune și funcții cumpărăm exact?
2. Care este scopul, cine îl folosește și ce decizie sau acțiune influențează?
3. Ce rol AI Act are fiecare parte pentru acest caz concret?
4. Ce documentație oferă furnizorul pentru clasificare și integrare downstream?

Date, antrenare, retenție și locație

OpenAI spune că, implicit, nu antrenează pe inputurile și outputurile produselor business și API dacă organizația nu optează explicit pentru partajare. Aceasta este o informație importantă, dar trebuie legată de produs, cont și setări. Separă folosirea pentru antrenare de retenția operațională, moderare, suport, securitate și logurile proprii. ^[OAI-DATA] ^[OAI-DPA]

DPA-ul OpenAI atribuie clientului responsabilitatea pentru anumite configurații, inclusiv retenție și ștergere, și descrie transferurile pentru datele EEA. Nu accepta formula „datele rămân în Europa” fără a verifica produsul, regiunea aleasă, entitățile implicate, excepțiile și mecanismul contractual. ^[OAI-DPA]

5. Ce date intră, ies și se păstrează în fiecare etapă?
6. Sunt inputurile sau outputurile folosite pentru antrenare și prin ce setare?
7. Care sunt termenele de retenție, excepțiile și opțiunile de ștergere?
8. Unde se procesează datele și ce mecanism acoperă transferurile?

Subprocesatori, securitate și incidente

Lista OpenAI din 9 iulie 2026 diferențiază subprocessatorii după produs, scop și locație și include situații condiționate de alegerile clientului. DPA-ul prevede notificarea modificărilor, drept de obiecție în 30 de zile și obligații comparabile pentru subprocessatori. Evaluarea trebuie să păstreze versiunea consultată și proprietarul care urmărește schimbările. ^[OAI-SUB] ^[OAI-DPA]

Nu evalua securitatea numai prin certificări. Cere controalele relevante fluxului: identitate, segregarea tenantului, criptare, gestiunea cheilor, acces administrativ, exportul logurilor, vulnerabilități, notificarea incidentului și sprijinul pentru investigație. Dovada trebuie să fie suficientă pentru riscul datelor și acțiunilor permise sistemului. ^[OAI-DPA] ^[EU-REG]

9. Ce subprocessatori ating datele, pentru ce scop și în ce locație?
10. Cum suntem notificați și ce putem face când lanțul se schimbă?
11. Ce controale de securitate sunt valabile pentru configurația cumpărată?
12. În cât timp și cu ce informații sunt comunicate incidentele?

Calitate, transparență și schimbarea modelului

Documentația unui model și semnarea unui cod de bune practici sunt semnale utile, nu substitut pentru testarea pe cazul tău. OpenAI a anunțat semnarea Codului GPAI, iar Comisia îl listează între semnatari. Verifică însă modelul folosit, limitele publicate, informațiile downstream și dacă sistemul tău adaugă prompturi, date, instrumente sau acțiuni care schimbă profilul de risc. ^[OAI-ACT] ^[EU-GPAI] ^[EU-GPAI-G]

Stabilește un set de evaluare înainte de achiziție: răspuns corect, refuz corect, citarea sursei, comportamentul multilingv, atacuri, date sensibile, erori ale instrumentelor și cost. Păstrează rezultatul pe versiune. Un alias de model care se actualizează poate schimba calitatea fără o schimbare în cod, deci contractul și monitorizarea trebuie să trateze versiunea ca dependență. ^[EU-GPAI-G] ^[EU-LIT]

13. Ce limitări, evaluări și documentație sunt publicate pentru model?
14. Cum îndeplinim transparența față de utilizatori în interfața noastră?
15. Cum suntem informați despre versiuni, retrageri și schimbări materiale?
16. Ce teste trebuie să treacă fiecare model înainte de promovare în producție?

Cost, control și planul de exit

Un furnizor potrivit azi poate deveni nepotrivit prin preț, limită, regiune, condiții, performanță sau strategie. Contractul trebuie să spună ce poți exporta, în ce format, cât timp ai acces după încetare și ce copii sunt șterse. La nivel tehnic, păstrează separată logica produsului de API-ul furnizorului și documentează funcția degradată fără model. ^[OAI-DPA] ^[EU-REG]

Scorul final nu trebuie să ascundă un criteriu eliminatoriu. Un furnizor poate avea rezultat general bun, dar să fie incompatibil cu datele sensibile, rezidența cerută sau acțiunea ireversibilă. Înregistrează acceptarea riscului cu nume și termen, nu într-o medie matematică. Reevaluează la schimbare materială și cel puțin la ciclul stabilit în registrul AI. ^[EU-DESK] ^[EU-REG] ^[OAI-SUB]

17. Care este costul total la volum, inclusiv loguri, evaluări și suport?
18. Putem limita permisiunile, bugetul și acțiunile pe echipă și mediu?
19. Ce date, prompturi, evaluări și configurații putem exporta la exit?
20. Cine decide reevaluarea, suspendarea și înlocuirea furnizorului?