Funcții AI în mediul de producție: ce verificați înainte să le folosească clienții

Am testat un model AI mai ieftin pentru un sistem care citește documente comerciale. Pe opt documente reale, modelul mai ieftin și-a acordat scoruri de încredere puțin mai mari decât modelul mai mare pe care urma să-l înlocuiască. Comparat câmp cu câmp cu rezultatele modelului mai mare, a returnat liste mai scurte în 7 din cele 8 documente (15 elemente în loc de 19 într-unul dintre ele), iar în 3 documente a omis o condiție importantă pe care modelul mai mare o identificase.

Judecând după cifrele din dashboard, schimbarea părea evidentă: fiecare apel ar fi durat cu aproximativ șase secunde mai puțin și ar fi folosit cu 320 de tokeni mai puțini (tokenii sunt unitățile după care furnizorii AI facturează textul procesat), adică sub 2% din tokenii unui apel. Ne-a oprit o regulă de lucru, nu o bănuială: înainte de orice schimbare de model, ambele variante rulează pe aceleași documente reale, iar rezultatele sunt comparate câmp cu câmp. Între timp, referința a devenit mai strictă: un set de documente ale căror informații-cheie au fost verificate de un om pe documentul original. Astfel, comparația arată nu doar că rezultatele a două modele diferă, ci și care dintre ele are dreptate.

Ghidul se adresează companiilor care folosesc deja, sau urmează să folosească, un model AI în produs ori într-un proces important: pentru a citi facturi, comenzi, e-mailuri sau solicitări de la clienți, pentru a extrage informații din ele sau pentru a lua decizii. Veți găsi cinci condiții care trebuie îndeplinite înainte să se bazeze clienții pe răspunsuri, cu măsurătorile din spatele lor, și trei verificări pe care le puteți face încă din această lună. Dacă încă vă întrebați dacă un prototip făcut cu instrumente AI este pregătit pentru utilizatori reali, începeți cu ce mai are nevoie un prototip vibecoded; dacă este vorba despre o aplicație dezvoltată de echipa dumneavoastră pentru uz intern, citiți aplicațiile interne făcute cu AI: le păstrați, le înlocuiți sau le refaceți?.

1. Siguranța modelului nu dovedește că are dreptate

Scorul de încredere arată cât de sigur este modelul pe propriul răspuns. Nu arată însă dacă răspunsul este corect pentru documentele dumneavoastră, iar un model poate fi cel mai convins tocmai acolo unde greșește. În exemplul de mai sus, dintre cele două modele, cel mai ieftin era mai sigur pe el.

Întrebarea se lămurește doar cu un set de referință:

• Exemple reale. Începeți cu 20 de documente sau solicitări pe care produsul le primește efectiv, inclusiv cele dificile: o pagină scanată, un format neobișnuit, o sumă scrisă altfel decât de obicei.
• Răspunsul corect, stabilit de un om. O persoană care cunoaște bine documentele notează, pentru fiecare exemplu, ce ar trebui să returneze modelul, câmp cu câmp, verificând în original.
• O evaluare la fiecare schimbare. Orice schimbare de model, de prompt sau de setări este testată pe set înainte de lansare, iar rezultatul este comparat câmp cu câmp cu versiunea folosită acum.
• Un set care crește. Fiecare răspuns greșit semnalat de un client devine un exemplu nou, iar aceeași greșeală este prinsă data viitoare.

Douăzeci de exemple nu dovedesc că o funcție este corectă. Sunt însă suficiente pentru a detecta o schimbare care strică grav rezultatele: în cazul de mai sus, au fost de ajuns opt documente.

Aceeași regulă lămurește și întrebările despre cost

Măsurătorile pe propriile documente răspund și la întrebări care altfel rămân presupuneri. În același sistem, pe un tip de document, când am lăsat modelul să raționeze mai mult înainte de a răspunde, a completat 62% din câmpurile-cheie, față de 50%, cu aproximativ 12% mai mulți tokeni de ieșire. Pe alt tip de document, aceeași setare a produs de patru ori mai mulți tokeni de ieșire, a durat de patru ori mai mult și nu a completat niciun câmp în plus. Un câmp completat trebuie să corespundă referinței pentru a fi considerat corect, dar o setare care nu completează nimic în plus se elimină ușor.

Ambele rezultate sunt valabile doar pentru acel sistem și acele documente, și tocmai aici este ideea: setarea potrivită depinde de documentele dumneavoastră și o arată doar măsurătorile făcute pe ele. Fără acestea, o echipă fie plătește pentru o calitate pe care nu o primește, fie economisește tocmai la calitatea de care avea nevoie.

2. Factura depinde de numărul de apeluri la model

Prețul pe token îl stabilește furnizorul. Numărul de apeluri la model din spatele unei operațiuni îl stabiliți dumneavoastră și, de obicei, contează mai mult. În același sistem, analiza completă a unui dosar de cinci documente înseamnă 12 apeluri la model, aproximativ 201.000 de tokeni de intrare și puțin peste două minute. Înmulțiți asta cu fiecare dosar, fiecare client și fiecare lună și veți vedea că felul în care este proiectată funcția cântărește în factură cel puțin cât lista de prețuri, iar aceasta este partea pe care o controlați.

Cinci reguli de proiectare țin acest număr sub control:

1. Datele structurate se citesc direct. Când informațiile sosesc în câmpuri structurate, sistemul le preia direct din câmpuri. Modelul primește doar textul liber propriu-zis.
2. Modelul se alege după miză. Un model mic și ieftin se ocupă de pașii de rutină, iar unul mai mare, de pașii în care o greșeală costă scump. Setul de referință arată unde este granița.
3. O cerere identică este procesată o singură dată. Dacă aceeași cerere a primit deja un răspuns, sistemul folosește rezultatul existent.
4. Fiecare client are un buget. Consumul fiecărui client este contorizat și nu poate depăși limita stabilită, iar un apel reluat se socotește o singură dată.
5. Volumele mari se eșalonează. Un import mare este împărțit în timp, astfel încât un singur client să nu consume într-o oră bugetul unei luni.

Rezultatul este un cost AI cunoscut pentru fiecare client, iar prețul devine o decizie, nu o estimare. Când apare un model mai bun sau mai ieftin, schimbarea privește un singur pas, testat pe referință, fără rescrierea aplicației.

3. Clienții lucrează în continuare cât timp modelul procesează

O funcție care cere răspunsul modelului în timp ce utilizatorul așteaptă funcționează impecabil într-un demo cu un singur document scurt. Cu documente și utilizatori reali, modelul răspunde mai greu, cererile expiră, iar oamenii apasă din nou pe buton. Fiecare clic în plus poate porni din nou aceeași procesare plătită.

În mediul de producție, aceeași funcție lucrează altfel:

• Cererea este înregistrată și confirmată imediat, iar ecranul arată stadiul procesării: în așteptare, în curs, finalizată sau eșuată.
• Un al doilea clic pe același document găsește procesarea deja pornită și îi afișează stadiul, fără să pornească și să plătească a doua oară aceeași procesare.
• Procesarea rulează în fundal și continuă după o repornire a serverului, fără ca lucrul făcut până atunci să se piardă.
• Fiecare pas începe când se termină cel anterior: documentul este primit, textul lui este citit, apoi sunt extrase informațiile.
• Fiecare apel la model are o limită de timp și este reluat doar după erori temporare, cum ar fi depășirea timpului de răspuns, limitarea traficului de către furnizor sau o eroare a serverului acestuia, niciodată după o cerere respinsă de furnizor.

Pentru companie, un furnizor AI lent încetinește o singură funcție, nu întreaga aplicație, iar mai mulți utilizatori înseamnă o coadă mai lungă, nu mai multe erori.

4. Când un document dă ordine modelului

Dacă un model citește fișierele încărcate de clienți, o frază din fișier poate funcționa ca o instrucțiune: ignoră regulile de până acum, trimite aceste date, aprobă această cerere. Fenomenul se numește prompt injection (injectare de instrucțiuni) și contează din momentul în care modelul poate acționa, nu doar răspunde. Este primul pe lista OWASP a riscurilor de securitate pentru aplicațiile bazate pe modele de limbaj.

Două măsuri de protecție contează cel mai mult. Prima: modelul primește cel mult drepturile utilizatorului pentru care lucrează, așa că un document încărcat de un client nu poate ajunge, prin model, la datele altui client. A doua: orice acțiune cu consecințe, cum ar fi o trimitere, o plată, o ștergere sau modificarea unei înregistrări, așteaptă confirmarea unui om. În proiectele de soluții AI și automatizare stabilim, pas cu pas, ce decizii poate lua modelul singur și unde este nevoie de aprobarea unui om. Echipa de securitate Microsoft a mers mai departe pe 19 octombrie 2026: un agent AI ar trebui să pornească fără acces permanent și să primească doar permisiunile necesare unei sarcini, numai pe durata ei.

5. Fiecare răspuns poate fi explicat ulterior

După câteva luni, un client contestă un rezultat. Pentru a-i răspunde, trebuie să știți ce versiune a instrucțiunilor a primit modelul, ce model a rulat, câți tokeni a consumat și cât a durat.

Pentru asta sunt necesare două evidențe. Fiecare versiune a unui prompt este păstrată, împreună cu autorul și motivul schimbării, astfel încât orice rezultat poate fi legat de instrucțiunile care l-au produs. Iar fiecare apel la model este înregistrat, cu modelul folosit, consumul și durata. Aceleași evidențe arată și efectul unei schimbări: dacă noul prompt a completat mai multe câmpuri pe setul de referință și cât a costat.

Trei verificări pentru luna aceasta

1. Douăzeci de exemple. Alegeți 20 de exemple reale, stabiliți împreună cu cineva care cunoaște documentele răspunsul corect pentru fiecare, treceți-le prin sistemul actual și numărați câte răspunsuri sunt corecte.
2. Apeluri pe operațiune. Numărați apelurile la model din spatele unei cereri obișnuite în funcția AI cea mai folosită. Cifra aceasta spune mai mult despre factura de anul viitor decât orice listă de prețuri.
3. Cel mai mare document, de două ori. Încărcați cel mai mare document real pe care îl aveți, cronometrați procesarea, apoi apăsați de două ori la rând butonul de procesare și urmăriți ce se întâmplă.

A doua și a treia verificare durează sub o oră. Prima cere mai mult timp la început, dar setul pe care îl construiți rămâne util la fiecare schimbare viitoare. Un rezultat neașteptat este cel mai util lucru pe care îl poate scoate la iveală o verificare, pentru că vă arată de unde să începeți.

Urmărirea AI după indicatori stabiliți este încă rară. În studiul PwC pe 366 de companii mari din Europa Centrală și de Est, prezentat pe 8 octombrie 2026, doar 2% dintre companiile din România aveau o strategie de AI aprobată de conducere, cu obiective și indicatori de monitorizare, față de 17% în regiune.

Întrebări frecvente

Trecem pe un model nou imediat ce apare?

Testați-l mai întâi pe setul de referință. Treceți pe el dacă obține cel puțin aceleași rezultate pe exemplele dumneavoastră, la un cost pe care îl considerați acceptabil. Dacă alegerea modelului este configurată într-un singur loc, testul durează o după-amiază, iar schimbarea este minoră.

De câte exemple avem nevoie la început?

Douăzeci sunt suficiente pentru a detecta o schimbare care strică grav rezultatele. Extindeți apoi setul cu fiecare greșeală descoperită în utilizare și cu fiecare tip nou de document pe care îl acceptă produsul.

Cine stabilește răspunsurile corecte?

Oamenii care cunosc documentele: colegii care citesc astăzi aceste facturi, comenzi sau solicitări. Echipa tehnică pregătește evaluarea automată, dar referința în sine ține de cunoașterea afacerii și este unul dintre cele mai valoroase lucruri pe care le are produsul.

Se aplică doar sistemelor mari?

Verificările de mai sus funcționează pentru orice funcție AI, inclusiv pentru una făcută rapid cu instrumente AI. Cu cât o parte mai mare din activitate depinde de răspunsurile modelului, cu atât referința, bugetul și evidențele valorează mai mult.

Dacă produsul dumneavoastră se bazează deja pe răspunsuri AI

Scrieți-ne prin formularul de contact ce face funcția AI, ce citește, ce decizie depinde de răspunsul ei și cum o verificați astăzi. Vă răspundem cu prima verificare pe care am face-o. Dacă funcția face parte dintr-un sistem mai mare, prin proiectele de dezvoltare software personalizat acoperim tot ce mai este necesar pentru ca ea să ruleze stabil în mediul de producție.