De ce se blochează proiectele de inteligență artificială la nivelul întreprinderilor înainte de a ajunge la producție: este vorba de harnașament, nu de model

Modelul nu a fost niciodată partea dificilă. Din interiorul construcției, producția este câștigată sau pierdută în stratul din jurul său: recuperare, ancorare, rutare și evaluare.

Fiecare sondaj major de inteligență artificială la nivelul întreprinderilor descrie acum același zid: organizațiile pot accesa modelele, pot rula proiectele-pilot și pot demonstra ceva impresionant, iar apoi aproape nimic din toate acestea nu ajunge la producție. Rapoartele descriu această lacună din exterior, prin intermediul executivilor care răspund la chestionare. Acesta este punctul de vedere de pe partea cealaltă: din interiorul construcțiilor, unde proiectele-pilot fie ajung la producție, fie mor în tăcere.

Lacuna pe care o măsoară toată lumea

Numerele au devenit familiare. Raportul Deloitte despre starea inteligenței artificiale în întreprinderi a constatat că accesul la inteligența artificială este acum aproape universal, dar doar aproximativ o pătrime din organizații reușesc să pună în producție mai mult de 40% din experimentele lor, iar aproximativ o persoană din cinci raportează o guvernanță matură pentru agenți autonomi. Proiectul NANDA al MIT a spus lucrurile mai pe șleau: din sute de implementări, majoritatea covârșitoare nu a generat niciun beneficiu financiar măsurabil. Gartner a prevăzut că o parte semnificativă a proiectelor de inteligență artificială generativă va fi abandonată după etapa de demonstrație a conceptului, invocând calitatea slabă a datelor, costurile în creștere și lipsa unei valori comerciale clare.

Înșiruiți aceste constatări și o singură formă iese la iveală. Blocajul nu este accesul la modele capabile. Această problemă este rezolvată. Blocajul este distanța dintre un model care funcționează într-o demonstrație și un sistem care funcționează în producție, de fiecare dată, pentru fiecare utilizator, sub o încărcătură reală, cu consecințe reale pentru greșeli.

O observație demnă de menționat în mod clar: multe proiecte-pilot nu ajung la producție din motive care nu au nimic de-a face cu ingineria: nu există un caz de afaceri real, nu există date utilizabile, nu există un sponsor executiv, sau costul total nu a fost modelat de nimeni. Puneți acestea deoparte. Ceea ce urmează se referă la acel set mare și frustrant de proiecte-pilot care sunt tehnic reale, demonstrează convingător și au un caz de afaceri real în spatele lor și, totuși, se blochează pe drumul spre producție. Pentru acestea, factorul decisiv este aproape niciodată modelul.

Ce datele de sondaj nu pot spune este ce anume închide această distanță. Răspunsul nu trăiește într-un chestionar. Trăiește în deciziile de inginerie luate după ce demonstrația impresionează pe toată lumea și înainte ca sistemul să fie încredințat unor clienți reali.

Modelul: soluția decisivă este aproape niciodată modelul

De-a lungul angajamentelor noastre de inteligență artificială la nivelul întreprinderilor, un model constant se păstrează: atunci când un proiect-pilot blocat ajunge în cele din urmă la producție, schimbarea care l-a adus acolo rareori este un model mai bun. Este stratul din jurul modelului: modul în care informațiile sunt recuperate și ancorate, modul în care ieșirile sunt verificate înainte de a ajunge la un utilizator, modul în care lucrul este rutat către modelul potrivit și nu către cel mai puternic, și modul în care totul este evaluat continuu.

Noi numim acest strat stratul de harnașament. Un agent, în termeni practici, este un model cu acces la unelte, iar harnașamentul este tot ceea ce guvernează modul în care modelul recuperează contextul, utilizează aceste unelte și este ținut responsabil pentru ceea ce produce: recuperare, verificare, rutare, garduri de protecție și evaluare. Aceste componente nu funcționează în izolare. Trebuie să le combinați, intenționat, pentru un anumit caz de utilizare. Această disciplină combinată este ceea ce numim harnașament de agent, și este acolo unde se câștigă sau se pierde pregătirea pentru producție.

Acest lucru reconfigurează capcana demonstrației. Echipele se blochează pentru că continuă să optimizeze partea care funcționează deja. Echipele schimbă un model mai nou, reingineresc prompturi și așteaptă următoarea frontieră, în timp ce punctele reale de eșec stau la un strat mai exterior, în părțile sistemului pe care o demonstrație nu le solicită niciodată.

Ancorarea, nu un model mai deștept, este ceea ce un agent suficient de sigur pentru a fi lansat

Să considerăm un asistent de recomandare și consultanță pe care l-am construit în sectorul asigurărilor, un domeniu în care o răspuns ferm, dar greșit, nu este o eroare, ci o problemă de răspundere. Primul instinct în astfel de cazuri este să ajungă la modelul cel mai capabil disponibil și să presupună că capacitatea cumpără siguranța. Nu este așa. Un model mai fluent produce halucinații mai convingătoare, ceea ce într-un context reglementat este mai rău, nu mai bine.

Ceea ce a făcut sistemul lansabil a fost harnașamentul: o proiectare de recuperare care a extras doar din surse guvernate și sigure pentru chiriași; verificări de ancorare care au verificat afirmații generate împotriva acestor surse înainte ca acestea să ajungă la un utilizator; și un pas de verificare care a preferat să se abțină decât să susțină ceva nesuportat. Rezultatul a fost o reducere măsurată a halucinațiilor cu 80 până la 90 la sută față de o linie de bază LLM, cu o acuratețe a ancorării de peste 95 la sută, menținând o latență sub doi secunde P95, astfel încât stratul de siguranță nu a făcut niciodată sistemul să se simtă lent.

Lecția contraintuitivă pentru oricine încă asociază siguranța cu alegerea modelului: stratul de ancorare și verificare este guvernanța. Documentele de politică și comitetele de aprobare contează, dar nu opresc un model să inventeze un fapt la momentul inferenței. Un harnașament de recuperare și verificare o face. În implementările noastre, stratul tehnic de ancorare este mecanismul real de guvernanță: locul în care “inteligența artificială nu trebuie să inventeze lucruri” nu mai este un principiu, ci o proprietate impusă a sistemului.

Rutarea modelului, nu selectarea modelului, este locul în care se decide costul inteligenței artificiale

Al doilea loc în care proiectele-pilot mor este revizuirea bugetară. Un sistem poate funcționa frumos și, totuși, poate fi anulat atunci când economia pe token, multiplicată de mii de utilizatori și zeci de cazuri de utilizare, se transformă într-o problemă de cost total de proprietate pe care nimeni nu a modelat-o dinainte.

Și aici, instinctul de a alege un model puternic și de a ruta totul prin el este greșeala. Majoritatea sarcinilor de lucru la nivelul întreprinderilor sunt un amestec: o parte semnificativă a solicitărilor sunt rutiniere, iar o mică parte sunt cu adevărat dificile. Trimiteți fiecare solicitare la un model de frontieră înseamnă a plăti prețuri de frontieră pentru munca de triaj pe care un model mai mic și mai ieftin o poate face perfect.

În o migrare pe care am efectuat-o de la un API LLM de la un terț la Amazon Bedrock , câștigurile au venit din restructurarea stratului de model, nu din schimbarea modelului. Rutarea fiecărei sarcini de lucru către nivelul de model potrivit, combinată cu controalele de cost și guvernanță native Bedrock, a livrat o reducere de 42 la sută a costurilor infrastructurii de inteligență artificială și o generare de conținut conform cu 60 la sută mai rapid, fără a reconstrui aplicația.

Extindeți acest principiu și el se compune. O arhitectură de “consultant” în trepte, modele ieftine care triază și gestionează majoritatea solicitărilor, modele de frontieră rezervate pentru cazurile care au nevoie cu adevărat de ele, transformă rutarea dintr-o economie unică într-una structurală.

Acest model a condus la o scădere a costurilor de inteligență artificială la nivelul întreprinderilor cu 60 până la 80 la sută pentru operațiunile de agent, și cu până la 85 la sută în unele implementări. Punctul nu este procentul de titular; este acela că costul unui sistem de inteligență artificială este stabilit de arhitectura sa, nu de modelul pe care l-ați ales.

De ce acest lucru este invizibil în datele de sondaj

Nimic din toate acestea nu apare curat într-un sondaj, pentru că sondajele întreabă executivi despre rezultate, nu ingineri despre mecanisme. “A ajuns proiectul-pilot la producție?” este un da/nu pe care un executiv îl poate răspunde. “Ce anume l-a adus acolo?” este o întrebare pe care doar echipa de construcție o poate răspunde, și răspunsul este rareori “am găsit un model mai bun”. Este aproape întotdeauna o variantă a “am reparat stratul din jurul modelului”.

Acest decalaj explică persistența ciudată a capcanei demonstrației. Industria continuă să diagnosticheze o problemă de model și să cumpere soluții de model, în timp ce constrângerile reale stau în recuperare, ancorare, rutare și evaluare: conductele nevizibile pe care nicio demonstrație nu le arată și nicio lansare de model de bază nu le promovează.

Acesta explică, de asemenea, de ce guvernanța și viteza de livrare nu sunt opusele pe care se presupun a fi. Narativa comună tratează guvernanța ca frâna care împiedică lansarea. În experiența noastră, este mai aproape de opusul: lucrul de ancorare și verificare care face un sistem guvernabil este același lucru care îl face de încredere suficient pentru a fi pus în fața unor utilizatori reali. Făcut la nivelul de harnașament, guvernanța nu este ceea ce încetinește construcția. Este ceea ce permite construcției să fie lansată deloc.

Ce înseamnă acest lucru dacă proiectul-pilot dvs. este blocat

Dacă aveți un proiect de inteligență artificială generativă care stă în purgatoriul demonstrației, cel mai util lucru pe care îl puteți face este să rezistați impulsului de a privi modelul mai întâi. Modelul este partea care este cel mai probabil să fie deja suficient de bun. Priviți, în schimb, stratul din jurul său:

• Recuperare și ancorare: sistemul răspunde din surse guvernate și verificabile, sau improvizează din antrenamentul său?
• Verificare: există ceva care verifică ieșirile înainte ca un utilizator să le vadă, sau încrederea modelului trece direct?
• Rutare: fiecare solicitare plătește prețuri de frontieră, sau lucrul este asignat modelului cel mai ieftin care poate face treaba bine?
• Evaluare: calitatea este măsurată continuu împotriva propriilor noastre repere, sau a fost validată o singură dată în demonstrație și niciodată după aceea?

Organizațiile care trec de la proiecte-pilot la producție în 2026 nu sunt cele care au acces la cele mai bune modele. Toată lumea are asta. Sunt cele care au înțeles că modelul nu a fost niciodată partea dificilă și care și-au pus efortul de inginerie în harnașament, unde producția este cu adevărat câștigată.