# Achiziție soluții AI în 2026: checklist pentru firme din România
O achiziție soluții AI nu ar trebui să înceapă cu o demonstrație spectaculoasă, ci cu o întrebare simplă: ce poate face sistemul, cu ce date și cine îl oprește când greșește? Pentru companiile din România, răspunsul trebuie să țină cont de buget, GDPR, obligațiile relevante din AI Act și riscurile concrete ale procesului automatizat. Checklistul de mai jos transformă principiile de AI responsabil în criterii pe care le poți verifica înainte de pilot, negociere sau semnarea contractului.
De ce noul Cod Microsoft schimbă întrebările puse furnizorilor AI
La 14 septembrie 2026, Microsoft AI a publicat prima versiune a Codului de Conduită pentru modelele MAI și a deschis documentul consultării publice pentru șase săptămâni. Reperul este util deoarece mută discuția de la declarații generale — „AI sigur”, „utilizare responsabilă”, „protecție enterprise” — la controale observabile: supraveghere umană, posibilitatea de oprire, limite pentru extinderea autonomă a scopului și opțiuni de configurare pentru organizații.
Codul trebuie folosit ca punct de plecare, nu ca recomandare exclusivă pentru un anumit furnizor. Aceleași întrebări sunt relevante pentru orice model, aplicație sau agent AI, indiferent dacă rulează în Azure, într-un cloud diferit ori în infrastructura proprie.
Separă întotdeauna cele trei niveluri ale unei promisiuni:
Promisiune publică: furnizorul descrie o intenție sau un principiu.
Control tehnic: funcția există, poate fi configurată și poate fi testată.
Obligație contractuală: furnizorul își asumă termene, responsabilități și remedii dacă acel control nu funcționează.
Primele două pot inspira încredere. Doar al treilea nivel îți oferă o bază clară pentru remediere. Nici codul voluntar al unui furnizor, nici acest checklist nu garantează conformitatea cu GDPR sau AI Act și nu înlocuiesc evaluarea juridică, analiza de risc ori o DPIA atunci când este necesară.
Înainte de achiziție soluții AI: clasifică utilizarea și datele
Nu evalua o platformă în abstract. Evaluează sistemul în contextul exact în care va fi folosit. Un asistent care rezumă proceduri interne are alt profil de risc decât un agent care aprobă rambursări sau modifică un mediu de producție.
Începe cu o fișă de utilizare de o pagină:
Scopul: ce rezultat de business urmărește sistemul?
Acțiunile permise: recomandă, generează, aprobă sau execută?
Acțiunile interzise: ce nu trebuie să poată face niciodată?
Datele: folosește date personale, confidențiale, financiare ori proprietate intelectuală?
Impactul erorii: produce consecințe financiare, juridice, operaționale sau reputaționale?
Rolurile: cine este operator, persoană împuternicită, furnizor și subprocesator?
Într-un IMM, tentația este să comprimi evaluarea pentru a reduce costul. Dar o clasificare bună economisește bani: elimină din start funcții inutile, limitează cantitatea de date expusă și arată unde este justificată intervenția umană. Pentru opțiuni de proiectare și implementare adaptate procesului, consultă pagina noastră de soluții AI pentru companii.
Checklist în 10 puncte pentru achiziție soluții AI
Salvează sau tipărește lista. Pentru fiecare punct, notează cine răspunde, ce dovadă ai primit și dacă cerința apare în contract.
1. Scop permis și acțiuni interzise
Definește în scris ce poate face sistemul. Un agent de suport poate propune un răspuns, dar nu ar trebui să acorde automat o compensație nelimitată. Cere limite funcționale, valorice și temporale, plus reguli care împiedică extinderea autonomă a obiectivului.
2. Control uman real
„Human in the loop” nu înseamnă o persoană care apasă mecanic „Aprobă”. Operatorul trebuie să primească explicații suficiente, să poată respinge rezultatul și să aibă timpul și competența necesare pentru verificare. Stabilește pragurile peste care aprobarea devine obligatorie.
3. Oprire testată
Cere un kill switch accesibil persoanelor autorizate și o procedură pentru dezactivare. Testul trebuie să arate că oprirea blochează acțiunile noi, revocă accesul unde este cazul și păstrează dovezile necesare investigației.
4. Permisiuni minime și medii separate
Agentul primește doar accesul necesar sarcinii, pe durata necesară. Separă dezvoltarea, testarea și producția. Folosește sandbox pentru execuții riscante și limitează instrumentele disponibile. Vezi și analiza despre securitatea agenților AI și capcanele enterprise, inclusiv riscurile asociate permisiunilor și scenariilor de abuz.
5. Reguli clare pentru date
Documentează unde sunt procesate și stocate datele, perioada de retenție, mecanismul de ștergere și condițiile de transfer. Cere confirmarea că datele companiei nu sunt folosite la antrenare fără o bază și o opțiune explicită acceptate de tine.
6. Loguri și trasabilitate
Trebuie să poți reconstrui ce intrare a primit sistemul, ce instrumente a folosit, ce decizie a propus sau executat și cine a aprobat-o. Verifică dacă logurile sunt exportabile, protejate împotriva modificării și păstrate suficient pentru audit și incidente.
7. Testare de securitate și red teaming
Solicită rezultate, nu doar confirmarea că „s-au făcut teste”. Cere metodologia, data, scenariile, severitatea problemelor și dovada remedierii. Testarea ar trebui să acopere prompt injection, exfiltrarea datelor, escaladarea permisiunilor și utilizarea neintenționată a instrumentelor.
8. Monitorizarea performanței și schimbărilor
Stabilește indicatori pentru acuratețe, erori, refuzuri, latență și cost. Furnizorul trebuie să te informeze înaintea schimbărilor materiale de model sau comportament. Actualizările importante impun retestare, nu acceptare automată.
9. Incidente, rollback și continuitate
Contractul trebuie să specifice intervalul de notificare, canalul de escaladare, suportul și accesul la informațiile necesare investigației. Verifică dacă poți reveni la o versiune stabilă sau la un proces manual fără a bloca activitatea.
10. Audit, răspundere și ieșire
Clarifică dreptul de audit, limitele răspunderii, despăgubirile și responsabilitățile fiecărei părți. La încetare, compania trebuie să își poată exporta datele și logurile într-un format utilizabil, apoi să obțină confirmarea ștergerii copiilor rămase.
Trei exemple din companiile românești
Retail și e-commerce
Un agent răspunde clienților, schimbă adrese și poate rambursa comenzi. Configurația prudentă include o limită valorică per tranzacție și per zi, aprobare umană pentru excepții, blocarea modificării contului bancar și un jurnal complet. Testarea trebuie să includă solicitări contradictorii, tentative de manipulare și clienți care trimit date sensibile în conversație.
Servicii financiar-contabile
Un model extrage date din facturi și pregătește înregistrări pentru ERP. Cere izolarea documentelor între clienți, retenție configurabilă și reguli stricte privind antrenarea. Rezultatul trebuie validat înainte de înregistrare, mai ales pentru IBAN, TVA, monedă și furnizori noi. Un procent bun de recunoaștere nu compensează o eroare contabilă greu de detectat.
BPO și software
Un agent poate modifica aplicații sau sisteme de producție. Rulează-l inițial într-un sandbox, cu acces minim, secrete temporare și ramuri separate. Impune aprobare pentru deploy, kill switch, rollback și teste independente. Măsoară nu doar câte sarcini finalizează, ci și câte intervenții nesigure încearcă.
Ce dovezi trebuie să ceri, nu doar ce întrebări să pui
Răspunsurile dintr-un chestionar comercial sunt utile, dar insuficiente. Construiește un dosar de evaluare care să conțină:
rapoarte recente de testare și limitele cunoscute ale modelului;
diagrama fluxurilor de date, regiunile de procesare și stocare;
lista subcontractorilor și subprocesatorilor relevanți;
demonstrație live pentru oprire, rollback, aprobări și exportul logurilor;
SLA pentru incidente și suport;
politica de actualizare a modelului și procedura de informare;
documentele de securitate și conformitate aplicabile serviciului cumpărat.
Marchează fiecare afirmație într-o matrice simplă: demonstrat, documentat, contractualizat sau doar promis. O funcție prezentată în demo poate depinde de un abonament superior. O politică publică se poate modifica. O clauză vagă poate exclude tocmai incidentul care te preocupă. Matricea face vizibile aceste diferențe înainte ca ele să devină costuri.
Exemplu de scor pentru compararea a trei furnizori
Folosește o scară de la 1 la 5 pentru fiecare criteriu, apoi înmulțește nota cu ponderea. Notele trebuie acordate pe baza dovezilor, nu a prezentării comerciale.
| Criteriu | Pondere | Furnizor A | Furnizor B | Furnizor C |
|---|---:|---:|---:|---:|
| Securitate și date | 25% | 4 | 3 | 5 |
| Control uman și limitarea autonomiei | 20% | 5 | 3 | 4 |
| Conformitate | 20% | 4 | 4 | 3 |
| Performanță | 15% | 4 | 5 | 4 |
| Integrare | 10% | 3 | 5 | 4 |
| Cost total | 10% | 3 | 4 | 2 |
| Scor ponderat / 5 | 100% | 4,05 | 3,75 | 3,90 |
Ponderile sunt orientative. Pentru procesarea documentelor medicale sau financiare, securitatea, datele și conformitatea pot valora mai mult. Pentru un instrument intern care nu accesează date sensibile, integrarea și performanța pot primi o pondere mai mare. Totuși, prețul nu trebuie să compenseze lipsa unui control critic: un furnizor fără oprire verificabilă, loguri sau reguli clare pentru date ar trebui eliminat, nu „echilibrat” prin cost.
Pilotul de 30 de zile înainte de contractul final
Un pilot bun validează riscul și valoarea în condiții controlate. Nu este o versiune redusă a implementării finale și nici un demo prelungit.
Săptămâna 1: definește limitele
Alege un singur caz de utilizare, măsoară performanța actuală și stabilește KPI. Documentează datele permise, acțiunile interzise, persoanele responsabile și criteriile care opresc pilotul.
Săptămâna 2: testează controlul
Configurează sandboxul și permisiunile minime. Rulează scenarii de abuz, date incorecte, instrucțiuni conflictuale și indisponibilitatea unui sistem conectat. Testează practic oprirea și revenirea la procesul anterior.
Săptămâna 3: validează în context local
Implică utilizatori români și date reprezentative, anonimizate sau sintetice când este posibil. Verifică limba, formatele locale, diacriticele, documentele și excepțiile reale. Nu expune inutil date de producție doar pentru a face testul „mai realist”.
Săptămâna 4: decide go/no-go
Centralizează rezultatele, incidentele, riscurile rămase și costul total: licențe, integrare, monitorizare, suport și muncă umană. Decizia de extindere trebuie să includă controalele obligatorii și clauzele finale, cu un proprietar și un termen pentru fiecare.
Semnale de alarmă care justifică oprirea achiziției
Oprește evaluarea sau cere remediere înainte să continui dacă furnizorul:
nu explică unde sunt procesate și stocate datele;
nu poate demonstra oprirea sau limitarea acțiunilor agentului;
nu oferă loguri exportabile;
evită un termen clar pentru notificarea incidentelor;
își poate schimba unilateral modelul fără informare și retestare;
refuză să declare subcontractorii relevanți;
promite conformitate, dar nu acceptă obligații contractuale;
condiționează exportul ori ștergerea datelor de costuri neclare.
Entuziasmul echipei și un demo reușit nu sunt motive pentru a ignora aceste semnale. Când miza include bani, date personale sau continuitatea operațională, absența unui control esențial este un criteriu de oprire.
Concluzie: cumpără control, nu doar capabilități
O achiziție soluții AI bine făcută compară mai mult decât acuratețea și prețul. Ea verifică limitele sistemului, controlul uman, traseul datelor, dovezile tehnice și obligațiile asumate în contract. Codul Microsoft oferă întrebări mai bune, dar responsabilitatea selecției și implementării rămâne la compania care folosește tehnologia.
Dacă vrei să transformi acest checklist într-o evaluare adaptată proceselor tale, descoperă serviciile Agenția de AI și solicită o evaluare pentru proiectul tău AI. Definim riscurile, comparăm furnizorii și proiectăm un pilot de 30 de zile cu criterii clare de succes și oprire.
Întrebări Frecvente
Ce trebuie verificat înainte de achiziția unei soluții AI?
Verifică scopul permis, datele folosite, controlul uman, securitatea, logurile, procedura de oprire, notificarea incidentelor și obligațiile contractuale ale furnizorului.
Este suficient codul de conduită al furnizorului pentru conformitate?
Nu. Un cod voluntar este un reper util, dar compania trebuie să facă propria analiză de risc și să transforme controalele necesare în cerințe tehnice și clauze contractuale.
Cum testează un IMM din România o soluție AI înainte de cumpărare?
Rulează un pilot limitat într-un mediu izolat, cu date și permisiuni controlate, KPI clari, scenarii de eroare și criterii explicite pentru oprire sau extindere.
Ce clauze sunt importante într-un contract pentru servicii AI?
Include utilizarea și retenția datelor, subcontractorii, securitatea, logurile, actualizările modelului, notificarea incidentelor, SLA, dreptul de audit, răspunderea și portabilitatea datelor la încetare.
Vrei să discutăm despre proiectul tău?
Primul apel e gratuit.
HAI SĂ DISCUTĂM?





