Build vs buy AI: cumperi, construiești pe API sau găzduiești?

Decizia „build vs buy AI” nu mai are două răspunsuri, ci trei: cumperi un produs gata făcut, construiești pe API-ul unui furnizor de modele sau găzduiești un model deschis. Fiecare cale mută în alt loc costul, datele, dependența de furnizor și răspunderea. Mai jos ai matricea pe opt criterii, componentele costului total pe 12–24 de luni, șapte întrebări de triere, clauzele de ieșire și o fișă de decizie pe o pagină.

Build vs buy AI: de ce sunt trei căi, nu două

În software-ul clasic, „cumperi” însemna o licență, iar „construiești” însemna o echipă. La AI a apărut o poziție intermediară, care produce confuzia din ședințele de buget: cineva spune „construim” cu gândul la o integrare pe un API, altcineva aude „ne luăm servere”.

• Calea 1: cumperi un produs gata făcut. O soluție AI la cheie: un asistent cu plan pentru echipe, modulul AI al suitei de birou, o unealtă verticală pentru contracte sau suport. Primești interfață, administrare și un model ales de altcineva.
• Calea 2: construiești pe API-ul unui furnizor de modele. Modelul rămâne al furnizorului și îl plătești pe consum; aplicația, prompturile, evaluarea și integrarea sunt ale tale.
• Calea 3: găzduiești sau ajustezi un model deschis. Un model găzduit intern: rulezi greutăți publicate sub o licență care permite asta, pe hardware propriu sau închiriat, eventual ajustate pe datele tale. Deții și operezi tot lanțul.

Pe măsură ce cobori în listă, câștigi control și pierzi viteză. Întrebarea utilă e unde stă diferențierea ta: dacă valoarea e în experiență, în date sau în distribuție, modelul e o utilitate pe care o cumperi; dacă e chiar comportamentul modelului pe sarcina ta, te apropii de construcție. Este cadrul din lecția despre build vs buy a cursului AI Product Management: construirea și lansarea produselor cu AI, care tratează decizia din scaunul de produs, alături de discovery, evaluare și economia pe utilizare.

Ce model alegi e o decizie separată, care vine după alegerea căii: vezi ghidul de alegere a modelului AI pentru business. Ordinele de mărime în lei sunt în analiza despre cât costă implementarea AI într-o firmă din România.

Cele trei căi, pe opt criterii

Trei lucruri pe care tabelul le ascunde:

• Decizia se ia pe flux, nu pe firmă. Redactarea de e-mailuri și analiza unor dosare medicale nu au aceeași sensibilitate și aceeași toleranță la eroare.
• Evaluarea nu dispare pe nicio cale. Și un produs cumpărat se verifică pe sarcinile tale reale, înainte de semnare.
• Control nu înseamnă calitate. Accesul la greutăți nu garantează rezultate mai bune pe sarcina ta; asta o arată doar evaluarea.

Costul total pe 12–24 de luni: componentele, nu cifrele

Costul total de proprietate se judecă pe un orizont care prinde ce lipsește din oferta inițială: o reînnoire de contract, cel puțin o migrare de model și, la găzduire, un ciclu de actualizări. Nu îți dau sume, pentru că prețurile se schimbă de la un trimestru la altul, ci liniile care trebuie să existe în foaia de calcul; o linie lipsă nu e o economie, e un zero mincinos.

Calea 1: produsul cumpărat

• Licențele: preț pe loc × locuri × luni, cu minimul contractual și cu treapta de plan pe care stau autentificarea unică și controalele de administrare.
• Locurile nefolosite: oamenii care deschid unealta de două ori pe lună.
• Integrarea și contractul: conectarea la sistemele firmei, evaluarea furnizorului, acordul de prelucrare a datelor.
• Instruirea și ieșirea: regulile interne, apoi exportul datelor și reinstruirea la plecare.

Costul crește cu numărul de oameni, nu cu utilizarea. Comparația între oferte e în ChatGPT Business vs Claude Team vs Microsoft 365 Copilot.

Calea 2: construcția pe API

• Dezvoltarea: integrarea, interfața, fluxul de date, controlul accesului.
• Setul de evaluare: cazuri reale adnotate și praguri de acceptare; singurul activ care rămâne al tău indiferent de furnizor.
• Consumul: tokeni de intrare și de ieșire × volum; o singură acțiune a utilizatorului poate ascunde multe apeluri la model.
• Mentenanța: jurnal, alerte, cost pe sarcină, prompturi de întreținut.
• Migrarea de model: cel puțin una în orizontul de calcul.

Migrarea are rândul ei pentru că nu depinde de tine. Anthropic se angajează la cel puțin 60 de zile de preaviz înainte de retragerea unui model public. Politica OpenAI indică, în lipsa unor motive de siguranță sau de conformitate, minimum 6 luni pentru modelele general disponibile și 3 luni pentru variantele specializate, iar modelele „preview” pot fi retrase cu un preaviz mult mai scurt, de exemplu două săptămâni. Pregătirea e descrisă în ghidul despre migrarea modelelor AI.

Calea 3: modelul găzduit sau ajustat

• Calculul: hardware amortizat sau GPU închiriat, energie, răcire.
• Operarea: ore lunare × luni pentru actualizări, monitorizare și incidente.
• Securitatea și evaluarea: integral ale tale.
• Ajustarea, dacă o faci: date, antrenare și re-antrenare la fiecare schimbare a sarcinii sau a modelului de bază.
• Licența: de exemplu, politica de utilizare a Llama 4 precizează că, pentru modelele multimodale din familie, drepturile din licență nu se acordă companiilor cu sediul principal în Uniunea Europeană.

Costul fix e mare, iar costul unei cereri în plus e mic. Găzduirea devine avantajoasă abia peste un volum-prag, la care costul fix amortizat pe cerere coboară sub tariful API-ului. Metoda de calcul e în articolul despre asistentul intern self-hosted.

Ajustarea vine după ce un prompt mai bun și RAG s-au dovedit insuficiente; criteriile sunt în ghidul despre când merită fine-tuning-ul. Pe platforma unui furnizor comercial, e ea însăși o dependență: OpenAI își închide treptat serviciul self-serve de fine-tuning, iar din 6 ianuarie 2027 nici clienții activi nu mai pot crea joburi noi, potrivit paginii de deprecări citate mai sus.

Cumperi sau construiești o soluție AI: șapte întrebări de triere

Răspunde în ordine. Primul răspuns ferm îți restrânge opțiunile; următoarele îl confirmă sau îl răstoarnă.

1. Problema e a ta sau a tuturor? Rezumate de ședințe, redactare, căutare în documente: probleme comune, cu produse mature. Dacă rezolvarea nu te diferențiază, cumperi.
2. Există un produs care acoperă cazul fără ocolișuri? Trece douăzeci de sarcini reale prin produs. Dacă echipa ajunge să copieze rezultate dintr-o fereastră în alta, ai un semnal pentru calea 2.
3. Rezultatul trebuie să trăiască în produsul sau în sistemele tale? O funcție în aplicația pe care o vinzi sau un flux intern legat de ERP ori de CRM nu se cumpără de la raft. Construiești pe API.
4. Au voie datele să iasă din rețea? Nu „ți-ar plăcea să nu iasă”, ci: există un contract, o lege sau cerința scrisă a unui client care interzice asta? Dacă da, fluxul acela merge pe calea 3.
5. Ai cine să opereze? Fără o persoană cu timp alocat lunar, un model găzduit ajunge să ruleze versiuni vechi pe date sensibile. Dacă nu ai, calea 3 e exclusă.
6. Sarcina e îngustă, repetitivă, la volum mare și stabil? Abia aici un model mic, găzduit și eventual ajustat, are sens economic.
7. Cine semnează când sistemul greșește? Dacă nimeni din firmă nu poate deține evaluarea și răspunderea, cumperi și îngustezi cazul de utilizare.

Întrebările 4 și 5 le bat pe celelalte: interdicția reală de a scoate datele împinge spre găzduire, iar lipsa unui operator o blochează. Când se ciocnesc, soluția e îngustarea cazului de utilizare sau amânarea lui.

Dependența de furnizor: cum citești clauzele de ieșire

Dependența are patru fețe: prețul se poate schimba la reînnoire, o întrerupere la furnizor devine a ta, o versiune nouă de model îți schimbă subtil rezultatele, iar furnizorul poate lansa un produs concurent cu al tău. Nu se rezolvă evitând furnizorii, ci știind dinainte cât costă plecarea.

Ce pleacă cu tine și ce rămâne

Pleacă documentele, setul de evaluare, logica de integrare și datele exportabile. Pleacă greu prompturile calibrate pe un anumit model, care nu dau automat același rezultat pe altul, configurările ținute într-un format proprietar și greutățile unui model ajustat pe platforma furnizorului, dacă primești doar dreptul de a-l apela.

Ce spune Data Act

Regulamentul (UE) 2023/2854 se aplică din 12 septembrie 2025 și obligă furnizorii de „servicii de prelucrare a datelor” să elimine obstacolele din calea trecerii la alt furnizor sau la o infrastructură proprie (art. 23). Contractul trebuie să prevadă, între altele, un preaviz de cel mult două luni, o tranziție de cel mult 30 de zile calendaristice (până la șapte luni, dacă furnizorul justifică o imposibilitate tehnică) și o perioadă de extragere a datelor de cel puțin 30 de zile (art. 25). Taxele de trecere la alt furnizor, inclusiv cele pentru ieșirea datelor, dispar începând cu 12 ianuarie 2027; până atunci sunt permise doar taxe reduse, limitate la costurile direct legate de proces (art. 29).

Două limite. Definiția vizează serviciile de tip cloud (infrastructură, platformă și software ca serviciu, potrivit considerentelor); dacă o anumită unealtă AI intră sub ea e o întrebare de pus furnizorului în scris. Apoi, serviciile personalizate pentru un singur client au mai puține obligații, iar versiunile de test, nedestinate producției, sunt exceptate (art. 31).

Ca reper de negociere, Comisia Europeană a publicat pe 19 noiembrie 2025 un proiect de recomandare cu clauze contractuale standard, neobligatorii, pentru contractele de cloud, cu un set dedicat trecerii la alt furnizor și ieșirii.

Șase lucruri de căutat în contract

1. Exportul: ce date și în ce format, ca listă, nu ca „datele clientului”.
2. Preavizul și tranziția: cât durează și dacă serviciul rămâne funcțional.
3. Datele la încetare: ștergere sau returnare, cu termen.
4. Prețul la reînnoire: plafon de creștere sau doar „tariful în vigoare”.
5. Modelul de dedesubt: cu cât timp înainte afli că se schimbă.
6. Retragerea unei funcții: ce preaviz primești dacă dispare cea pe care te bazai.

Formulările de negociat și cele de refuzat sunt în articolul despre clauzele AI din contractele software.

Cine răspunde când sistemul greșește

În AI Act, furnizorul e cel care dezvoltă un sistem de IA, ori comandă dezvoltarea lui, și îl introduce pe piață sau îl pune în funcțiune sub propriul nume; implementatorul e cel care utilizează un sistem aflat sub autoritatea sa (art. 3 pct. 3 și 4). Punerea în funcțiune acoperă și uzul propriu (art. 3 pct. 11). Pe calea 1 ești, de regulă, implementator. Pe căile 2 și 3, sistemul construit e al tău, chiar dacă modelul vine de la altcineva.

Rolul se poate schimba și fără o linie de cod. Potrivit art. 25 din forma consolidată a Regulamentului (UE) 2024/1689, cine își aplică numele sau marca pe un sistem cu grad ridicat de risc, îl modifică substanțial ori schimbă scopul preconizat al unui sistem, inclusiv al unuia de uz general, astfel încât acesta devine cu grad ridicat de risc este considerat furnizor și preia obligațiile aferente. Un asistent general cumpărat pentru redactare și pus apoi să filtreze candidaturi intră în această discuție: recrutarea figurează în anexa III, iar obligațiile pentru aceste sisteme se aplică din 2 decembrie 2027.

La datele personale, pe căile 1 și 2 furnizorul care le prelucrează în numele tău e persoană împuternicită, iar contractul acoperă elementele din art. 28 alin. (3) GDPR, inclusiv ștergerea sau returnarea datelor la încetare. Pe calea 3 nu mai ai un împuternicit pentru model, dar nici pe cine să suni. Acesta e cadrul, nu o analiză juridică pe cazul tău.

Trei scenarii pedagogice

Situațiile de mai jos sunt construite pentru exemplificare; nu descriu firme reale, iar cifrele sunt ipotetice.

Scenariu pedagogic 1: distribuitorul care vrea „AI pentru birou”

O firmă de distribuție cu 60 de oameni în birouri vrea ajutor la e-mailuri, rezumate de ședințe și căutare în proceduri. Nimic din acestea nu o diferențiază, iar firma nu are dezvoltatori. Prima întrebare închide discuția: cumpără. Munca reală e în contract și în regulile interne.

Scenariu pedagogic 2: produsul software care primește o funcție AI

O firmă cu un produs propriu de gestiune vrea extragerea automată a datelor din documentele încărcate de clienți. Funcția trebuie să trăiască în produs, deci calea 2. Deciziile care contează nu țin de model: un strat de abstractizare din prima versiune, un set de evaluare din documente reale, o linie de buget pentru migrare și un acord de prelucrare cu furnizorul modelului.

Scenariu pedagogic 3: laboratorul cu date care nu au voie să iasă

Un laborator de analize vrea rezumate ale dosarelor, iar contractele cu clinicile partenere interzic scoaterea datelor din infrastructura proprie. Întrebarea 4 împinge spre calea 3, iar întrebarea 5 decide dacă se poate: laboratorul are un administrator de sisteme cu o zi pe săptămână alocată. Rezultatul e un hibrid: model deschis găzduit pentru dosare, produs cumpărat pentru restul firmei. Fără administrator, răspunsul corect ar fi fost amânarea.

Varianta hibridă: regula, nu excepția

Firmele mature ajung, de obicei, la o combinație: un produs cumpărat pentru munca generală de birou, o construcție pe API pentru funcția care le diferențiază și un model găzduit pentru datele care nu au voie să iasă. Ca hibridul să nu devină trei proiecte fără legătură, ține patru lucruri comune:

• o regulă scrisă de rutare: ce tip de date merge pe ce cale;
• un strat de abstractizare: aplicațiile vorbesc cu o interfață, iar schimbarea modelului înseamnă schimbarea unui adaptor;
• un singur set de evaluare pe sarcină: același test rulează pe orice model candidat;
• un singur proprietar al deciziei: cineva care ține fișele la zi.

Gateway-ul cu mai mulți furnizori, rutarea și strategiile de rezervă sunt tratate în cursul Arhitectura sistemelor AI la scară, iar găzduirea propriu-zisă, de la alegerea unui model deschis la dimensionarea hardware-ului, în LLM-uri locale cu Ollama. Portabilitatea costă și ea, deci investești în ea unde riscul de dependență e real, nu din principiu.

Semnalele că trebuie să schimbi calea

O decizie build vs buy are termen de valabilitate. Stabilește dinainte ce o redeschide.

• De la produs spre API: oamenii copiază rezultate între ferestre; ai nevoie de rezultat într-un sistem în care produsul nu ajunge; plătești locuri pentru o funcție folosită rar.
• De la API spre model găzduit: volumul a devenit mare și previzibil; a apărut o cerință contractuală sau legală privind locul datelor; sarcina s-a îngustat cât să o ducă un model mic.
• De la model găzduit înapoi: omul care opera sistemul a plecat; actualizările se amână de la o lună la alta; rezultatele nu mai trec evaluarea.

Oricum, fișa se redeschide la reînnoirea contractului, la un anunț de retragere a modelului și la o schimbare de tarif.

Fișa de decizie pe o pagină

Completează câte o fișă pentru fiecare flux. Dacă nu încape pe o pagină, cazul de utilizare e prea larg.

FIȘĂ DE DECIZIE: un flux, o pagină

Flux:                Proprietar:                Data:

1. Diferențiere   problema e comună / e specifică nouă
2. Date           au voie să iasă din rețea: da / nu (temei)
3. Volum          cereri pe lună: estimat / măsurat
4. Echipă         cine construiește / cine operează
5. Termen         primul rezultat util până la
6. Răspundere     cine deține evaluarea și semnează

Calea aleasă:     1 cumpărăm / 2 API / 3 găzduim / hibrid
Cost total 12–24 luni, pe linii:
                  licențe sau consum, dezvoltare, operare,
                  evaluare, migrare, ieșire
Costul ieșirii:   ce exportăm, preaviz, durată
Ce ar răsturna decizia: 2–3 semnale măsurabile
Data re-evaluării: cel târziu la reînnoirea contractului

Cel mai valoros e penultimul rând: decizia care spune ce ar răsturna-o se revizuiește la timp.

Greșeli frecvente

• Compari tariful pe token cu prețul pe licență. Sunt unități diferite; compari costul total, pe linii, și costul pe rezultat acceptat.
• Găzduiești „pentru confidențialitate” fără operator. Un server neactualizat, cu date sensibile, e mai riscant decât un serviciu comercial cu un contract bun.
• Construiești ce puteai cumpăra și cumperi ce trebuia să te diferențieze. Ambele pornesc din aceeași întrebare sărită: unde stă valoarea ta.
• Semnezi fără să citești ieșirea. Exportul, preavizul și soarta datelor se negociază înainte, nu la plecare.
• Tratezi licența modelului deschis ca pe un detaliu. „Deschis” nu înseamnă „fără condiții”.

Întrebări frecvente

Ce înseamnă build vs buy AI pentru o firmă mică, fără echipă tehnică? Aproape întotdeauna, calea 1: cumperi un produs și îți pui energia în reguli interne, instruire și contract. Celelalte două căi cer oameni care construiesc și operează.

Este mai ieftin să găzduiești un model decât să plătești un API? Doar peste un anumit volum, stabil și previzibil. Sub prag, API-ul câștigă pe costul total, chiar dacă tariful pe token pare mai mare.

Cum reduc dependența de furnizor fără să renunț la API-urile comerciale? Prin două investiții: un strat de abstractizare între aplicație și model, care transformă schimbarea furnizorului într-o schimbare de adaptor, și un set de evaluare propriu, care îți arată dacă noul model e suficient de bun.

Se aplică Data Act și uneltelor AI pe care le cumpăr? Regulile despre trecerea la alt furnizor privesc serviciile de prelucrare a datelor, adică serviciile de tip cloud, inclusiv software-ul ca serviciu. Cere-i furnizorului să confirme în scris dacă unealta lui intră sub definiție.

Cât de des trebuie reluată decizia? La fiecare reînnoire de contract, la un anunț de retragere a modelului, la o schimbare de tarif și la apariția unei cerințe noi privind datele. Altfel, o dată pe an.

Concluzie

Build vs buy AI nu e o alegere între două tabere, ci o triere pe fluxuri între trei căi: cumperi unde problema e comună, construiești pe API unde rezultatul trebuie să trăiască în produsul tău și găzduiești unde datele nu au voie să iasă și ai cine să opereze. Costul se compară pe linii, pe 12–24 de luni, cu migrarea și ieșirea incluse. Dependența de furnizor se gestionează prin clauze citite înainte de semnare, un strat de abstractizare și un set de evaluare propriu. Iar fișa de o pagină spune ce ai ales, de ce și ce te-ar face să te răzgândești.

Articol informativ, nu consultanță juridică. Sursele au fost consultate la 5 octombrie 2026; termenele și licențele citate se pot schimba.