Cât costă un feature AI: cum estimezi și ce promiți în ofertă

„Vrem un asistent care să răspundă la întrebări pe documentele noastre. Cât costă?" Întrebarea vine pe e-mail, joi după-amiază, iar răspunsul e așteptat luni. Dacă estimezi ca la un modul obișnuit — atâtea zile de backend, atâtea de front-end, plus testare — vei greși în ambele direcții: subestimezi partea de calitate și uiți complet costul lunar de rulare. Ambele erori se plătesc din marjă.

Articolul e pentru firmele de software și pentru freelancerii care ofertează funcționalități cu modele: cum construiești estimarea, ce promiți în contract și cum formulezi oferta astfel încât un rezultat nedeterminist să rămână, totuși, un angajament pe care îl poți respecta.

De ce estimările clasice eșuează aici

Într-un modul obișnuit, incertitudinea e despre cât durează. Într-o funcționalitate cu model, mai apar trei surse de incertitudine, toate necunoscute în ziua ofertei:

Calitatea răspunsului. Nu știi, înainte să încerci, dacă modelul rezolvă sarcina la un nivel acceptabil pentru client. Poate ajunge la 95% din primul prompt sau poate rămâne la 60% după trei săptămâni de ajustări. Diferența nu e de efort de programare, ci de câte iterații de evaluare sunt necesare.

Datele clientului. „Documentele noastre" pot însemna PDF-uri curate, exportate dintr-un sistem, sau scanuri strâmbe de la fax, în trei formate, cu diacritice inconsistente. Efortul de pregătire diferă de zece ori între cele două situații.

Costul la rulare. Spre deosebire de un modul clasic, funcționalitatea costă bani în fiecare lună după livrare. Dacă nu l-ai calculat și nu l-ai comunicat, discuția apare la prima factură a clientului — în cel mai prost moment posibil.

La toate acestea se adaugă un efect documentat: raportul DORA din 2025, realizat de Google Cloud pe aproape cinci mii de profesioniști, arată o relație pozitivă între adoptarea AI și debitul livrării, dar negativă cu stabilitatea livrării, pentru că accelerarea expune slăbiciunile din aval. Tradus în limbaj de ofertă: livrezi mai repede, dar ai nevoie de mai multă verificare, iar verificarea trebuie plătită de cineva.

Împarte estimarea în trei bugete

Cea mai utilă schimbare de metodă e să nu mai dai un singur număr. Dai trei, pentru că se comportă diferit:

Ofertarea într-un singur număr înseamnă că bugetul de calitate dispare, iar tu îl acoperi din marjă. Ofertarea în trei linii face vizibil exact lucrul care, altfel, produce discuția neplăcută de la jumătatea proiectului.

Disciplina din spatele bugetului de calitate — set fix de cazuri, praguri, scor reproductibil — e subiectul cursului AI Evals pentru LLM-uri în Producție. Fără ea, „gata" rămâne o chestiune de opinie, iar un proiect fără definiție de „gata" nu se închide niciodată.

Spike-ul de trei zile, plătit

Regula care schimbă economia acestor proiecte: nu ofertezi ferm înainte de a atinge datele reale. Ceea ce ofertezi ferm e un spike scurt, plătit, cu livrabile clare.

Ce livrezi într-un spike de trei zile:

1. Un set de 30–50 de cazuri reale, construit împreună cu clientul, cu răspunsurile pe care el le consideră corecte. Acesta e, de fapt, cel mai valoros artefact al întregului proiect.
2. Un prototip minim, care rulează sarcina pe acele cazuri.
3. O măsurătoare: câte cazuri sunt rezolvate acceptabil, unde greșește sistematic.
4. Costul estimat pe cerere, calculat din consumul real al prototipului.
5. O recomandare: merge, merge cu restrângerea domeniului, sau nu merge acum.

Spike-ul se facturează. Nu pentru că trei zile de muncă trebuie plătite — deși trebuie —, ci pentru că un client care plătește spike-ul participă la el, oferă datele reale și acceptă concluzia. Un spike neplătit devine „o demonstrație", iar demonstrațiile nu produc decizii.

După spike, estimarea pentru restul proiectului are o bază reală, iar riscul rămas se exprimă în interval, nu în speranță.

Cum arată estimarea de efort, pe componente

Intervalele de mai jos sunt un cadru de pornire pentru o funcționalitate de complexitate medie, nu o promisiune — ajustează-le cu datele din proiectele tale:

• Ingestia și pregătirea datelor: 3–10 zile. Variabila principală e curățenia surselor, nu volumul.
• Stratul de regăsire sau de integrare: 3–8 zile.
• Interfața și fluxul de lucru: 4–10 zile. Include stările de eroare și anularea, tratate în ghidul despre streaming în aplicații AI.
• Evaluarea și iterațiile până la prag: 4–12 zile. Componenta cu cea mai mare dispersie.
• Integrarea cu sistemele existente: 2–15 zile, în funcție de ce API are clientul. Pentru integrările cu sisteme de gestiune, discuția e detaliată separat.
• Guvernanță și documentație: 2–4 zile — jurnalizare, drepturi de acces, procedura de avarie, documentele pentru evaluarea de securitate.

Regula de agregare: aduni minimele pentru varianta optimistă, maximele pentru cea pesimistă și ofertezi pe mijloc, cu o marjă de siguranță declarată. Și scrii în ofertă ce anume mută proiectul spre limita de sus: date murdare, surse noi, cerințe de conformitate apărute pe parcurs.

Costul lunar: formula și marja de siguranță

Calculul e simplu, iar faptul că mulți îl sar e motivul pentru care apar surprize:

cereri pe lună × (tokeni de intrare + tokeni de ieșire) × prețul pe token

Pentru ordinele de mărime, tarifele publicate de furnizori în septembrie 2026 se situează, pentru modelele de clasă medie, în jurul a 2 dolari pe milionul de tokeni de intrare și 10 dolari pe milionul de tokeni de ieșire; modelele mai puternice sunt de câteva ori mai scumpe, cele mici, de câteva ori mai ieftine. Verifică prețurile la data ofertei, pentru că se schimbă.

Trei corecții pe care le aplici înainte de a pune cifra în ofertă:

Cache-ul de prompt. Dacă trimiți același context la fiecare cerere, citirile din cache costă o fracțiune din prețul standard de intrare. Într-un asistent peste documente, diferența e substanțială.

Marja de siguranță. Adaugă cel puțin 30% peste estimare. Utilizatorii reali reformulează, reiau, încarcă documente mai mari decât în test.

Costul de operare. Stocarea vectorilor, monitorizarea, alertele — mici, dar existente. Iar dacă oferi și mentenanță, timpul tău de verificare lunară intră tot aici.

Modul în care aceste decizii se leagă de arhitectura sistemului — orchestrare, caching, alegerea modelelor, FinOps — e tratat în cursul Arhitectura Sistemelor AI la Scară. Structura completă a costului la rulare, cu pârghiile care o reduc, e tratată în articolul despre costul unui agent AI cu context lung, iar modelul de preț cu care transferi acest cost către client — în ghidul despre facturarea pe consum.

Ce promiți în ofertă și ce nu

Aici se decide dacă proiectul se închide sau devine o negociere perpetuă.

Promiți un prag măsurat pe un set fix. „Sistemul răspunde corect la cel puțin 85% dintre cele 50 de cazuri convenite, verificate împreună la recepție." E verificabil, e limitat și se poate atinge.

Promiți comportamentul la eșec. Ce se întâmplă când sistemul nu știe: spune „nu știu" și trimite către om, nu inventează.

Promiți transparența. Utilizatorul știe că vorbește cu un sistem AI — obligație care, potrivit articolului 50 din Regulamentul (UE) 2024/1689, se aplică din 2 august 2026.

Nu promiți acuratețe totală. Niciun furnizor serios nu o face, iar clauza îți rămâne în cârcă la primul răspuns greșit.

Nu promiți rezultate de business. „Veți reduce timpul de procesare cu 40%" e o promisiune care depinde de comportamentul angajaților clientului, nu de codul tău.

Nu promiți performanță la volume netestate. Dacă ai măsurat pe 5.000 de documente, nu garanta pe 500.000.

Structura ofertei, în cinci secțiuni

Forma contează aproape la fel de mult ca cifrele, pentru că decidentul citește primele două paragrafe și sare la preț.

1. Problema, în cuvintele clientului. Două fraze care arată că ai înțeles ce îl doare: „patru persoane petrec aproximativ șase ore pe săptămână căutând informații în contracte".

2. Ce livrezi, concret. Funcționalitatea, sursele incluse, unde apare în fluxul lor de lucru. Fără termeni tehnici care cer explicații.

3. Cum se măsoară succesul. Pragul de calitate pe setul de cazuri, plus una-două măsuri de proces pe care le urmărește clientul.

4. Cele trei bugete. Implementare, calitate, rulare — cu mențiunea explicită că al treilea e recurent.

5. Ce nu e inclus. Sursele noi, integrările suplimentare, migrările viitoare de model, traducerea în alte limbi. Secțiunea aceasta previne mai multe conflicte decât toate celelalte la un loc.

Un detaliu de negociere care funcționează: prezintă riscurile ca opțiuni, nu ca avertismente. „Dacă documentele vin din scanare, adăugăm un pas de recunoaștere optică — 4 zile suplimentare" e o opțiune pe care clientul o poate alege. „Atenție, scanurile pot crea probleme" e o umbrelă sub care nu se ascunde nimeni la facturare.

Greșelile care mănâncă marja

Cazurile noi de documente. „Mai adăugăm și facturile de la furnizorul X" pare o cerere minoră și înseamnă, de regulă, o nouă rundă de pregătire a datelor și de evaluare. Se tratează ca modificare de contract, nu ca favoare.

Datele murdare descoperite târziu. De aceea spike-ul atinge datele reale, nu un eșantion ales de client.

Evaluarea nefacturată. Dacă bugetul de calitate nu apare în ofertă, va fi consumat oricum — din timpul tău.

Recepția fără criterii. Fără prag scris, recepția devine o discuție despre impresii, iar impresiile se schimbă cu fiecare persoană care încearcă sistemul.

Mentenanța uitată. Modelele se retrag după calendare publicate, iar migrarea cere muncă — subiect tratat în ghidul despre migrarea modelelor AI. Dacă în contract scrie „mentenanță", scrie și cine plătește migrările.

Un exemplu de calcul

Asistent intern peste 5.000 de documente, 40 de utilizatori, aproximativ 600 de întrebări pe lună.

Efort: ingestie 5 zile, regăsire 4, interfață 6, evaluare 7, integrare cu autentificarea clientului 3, guvernanță 3 — total 28 de zile, plus spike-ul de 3. La un tarif obișnuit de piață, aceasta e linia principală a ofertei.

Rulare: 600 de întrebări × aproximativ 8.000 de tokeni de intrare (context regăsit) și 600 de ieșire. La tarifele de clasă medie, ordinul de mărime al costului lunar cu modelul e de câțiva dolari până la câteva zeci, în funcție de model și de cache — o cifră care surprinde pe toată lumea, în sens bun, și care nu trebuie umflată artificial. Costul real pentru client e, aproape întotdeauna, mentenanța și suportul, nu tokenii.

Ce scrii în ofertă: cele trei bugete, pragul de calitate, lista surselor incluse, comportamentul la eșec și ce se întâmplă la depășirea volumului convenit.

Tocmai pentru că tokenii sunt ieftini la volume mici, tentația e să nu discuți deloc despre ei. E o greșeală: clientul trebuie să știe că există un cost recurent, altfel prima lui factură de la furnizorul de modele va părea o surpriză neplăcută, iar tu vei fi cel care nu a spus.

Listă de control înainte de a trimite oferta

1. Ai atins datele reale, nu doar un eșantion ales de client?
2. Există un set de cazuri convenit, cu răspunsuri considerate corecte?
3. Ai trei bugete separate: implementare, calitate, rulare?
4. Pragul de calitate e scris ca număr, pe un set fix?
5. Ai definit comportamentul la eșec și punctele de supraveghere umană?
6. Ai calculat costul lunar, cu cache și cu marjă de siguranță?
7. Ai enumerat sursele incluse și procedura pentru surse noi?
8. Ai scris cine plătește migrările de model și mentenanța?
9. Ai inclus informarea utilizatorului că interacționează cu un sistem AI?
10. Ai enumerat explicit ce nu garantezi?

Întrebări frecvente

Î: Cât durează, în medie, o funcționalitate AI de complexitate medie? R: Pentru un asistent peste documente interne, un interval realist e de 20–35 de zile de lucru, plus un spike de 2–3 zile înainte de ofertarea fermă. Dispersia cea mai mare vine din curățenia datelor clientului și din numărul de iterații necesare până la pragul de calitate convenit — motiv pentru care estimarea fermă se dă după spike, nu înainte.

Î: Cum ofertez dacă nu știu dinainte ce calitate pot atinge? R: Ofertezi ferm spike-ul și dai pentru restul un interval, cu condiții explicite. La finalul spike-ului ai o măsurătoare pe cazuri reale și poți converti intervalul într-un preț ferm, cu un prag de calitate scris. Clientul primește astfel o decizie informată după trei zile, în loc de o promisiune la trei săptămâni.

Î: Ce scriu despre acuratețe în contract? R: Un prag măsurabil pe un set fix de cazuri, convenit înainte, plus comportamentul la eșec: sistemul semnalează incertitudinea și trimite cazul către un om. Nu promite procente pe cazuri necunoscute și nu promite rezultate de business, care depind de utilizarea internă a clientului.

Î: Cine plătește costul lunar cu modelul? R: De regulă clientul, fie direct pe contul lui, fie prin tine, cu marjă. Important e ca alegerea să fie scrisă în contract, împreună cu un volum inclus și cu ce se întâmplă la depășire. Varianta „vedem noi" produce, invariabil, o discuție la a treia lună.

Î: Merită să ofer un pilot fără plată ca să câștig proiectul? R: Rareori. Un pilot neplătit e tratat ca o demonstrație: clientul nu alocă oameni, nu dă datele reale și nu ia o decizie la final. Un spike plătit, chiar și simbolic, schimbă complet dinamica și îți lasă în mână setul de cazuri — artefactul care face restul proiectului previzibil.

Concluzie

Funcționalitățile cu modele nu sunt mai greu de estimat decât restul software-ului; sunt greu de estimat înainte de a atinge datele reale. Un spike scurt și plătit transformă necunoscutele în cifre, iar cifrele în ofertă fermă.

Restul e disciplină de ofertare: trei bugete în loc de unul, un prag de calitate scris ca număr, costul lunar comunicat din start și o listă onestă de lucruri pe care nu le garantezi. Clienții serioși nu fug de această listă — dimpotrivă, e adesea motivul pentru care te aleg pe tine.

Surse: Raportul DORA 2025, Google Cloud · Documentația Claude — prețuri API · Regulamentul (UE) 2024/1689 privind inteligența artificială

Articol informativ, publicat la 20 septembrie 2026. Intervalele de efort și cifrele de cost sunt orientative și depind de proiect; prețurile furnizorilor se modifică — verifică-le la data ofertei. Nu constituie consultanță juridică sau financiară.