Lideri de opinie

De ce proiectele de inteligență artificială agentică se blochează la scară și ce trebuie să corecteze întreprinderile în primul rând

mm
Adaugă Unite.AI la sursele tale preferate pe Google

Inteligența artificială agentică devine rapid un element critic pentru toate întreprinderile. Afacerile incorporează proiecte-pilot în operațiunile lor, medii de demonstrație impresionează conducerea și planurile de drum sunt rescrise în jurul fluxurilor de lucru autonome de inteligență artificială.

Dar pentru multe dintre aceste proiecte, ceva se strică între demo-ul controlat și implementarea de producție. Proiectul se blochează, implementările se prelungesc de la luni la ani și echipele responsabile de livrare sunt lăsate să explice de ce agentul care a funcționat perfect în testare se comportă imprevizibil în lumea reală.

În aproape toate cazurile, răspunsul nu este modelul în sine, ci patrimoniul de date, stratul de orchestrare, cadrul de guvernanță și infrastructura moștenită pe care majoritatea întreprinderilor nu au reușit să o modernizeze înainte de a decide să construiască agenți inteligenți pe baza acesteia. Până când aceste fundații nu sunt abordate, inteligența artificială agentică va continua să producă demo-uri care impresionează și implementări care dezamăgesc.

Mediul de test este o capcană

Majoritatea întreprinderilor evaluează modelele. Mult mai puține evaluează comportamentul agenților de la capăt la capăt. Un model poate fi foarte precis și agentul construit pe baza acestuia poate să nu funcționeze deloc. Acest lucru se datorează faptului că agenții lansează apeluri de instrumente în mod secvențial și o singură etapă proastă produce un răspuns greșit pe care următoarea etapă îl tratează ca intrare corectă, amplificând eroarea în aval înainte ca cineva să observe.

Mediul de test este proiectat pentru a ascunde acest lucru. Intrările sunt controlate, domeniul de aplicare este îngust și cineva supraveghează ieșirile. Niciuna dintre aceste condiții nu există în producție. Agentul care a obținut rezultate bune la testare se confruntă acum cu instrucțiuni ambigue, erori de permisiune și decizii secvențiale pe baza datelor cu care nu a fost testat. Echipa care l-a construit descoperă că cadrele de evaluare proiectate pentru performanța modelului nu spun dacă agentul a escaladat corect, a gestionat un caz limită cu grație sau a știut când să se oprească.

Conform raportului McKinsey despre starea inteligenței artificiale din 2025, 88% dintre organizații folosesc inteligență artificială în cel puțin o funcție de afaceri, dar doar aproximativ o treime au reușit să o extindă la scară largă în întreaga întreprindere. Decalajul dintre adoptare și scalare începe cu modul în care întreprinderile definesc și evaluează proiectele-pilot. Echipele care extind cu succes tratează analiza modului de eșec ca o cerință de proiectare. Înainte de implementare, ele construiesc un catalog al modului în care agentul este așteptat să eșueze și ce este răspunsul atunci când se întâmplă acest lucru. Sună evident. Foarte puține întreprinderi fac acest lucru de fapt.

Datele de calitate slabă, agenții de calitate slabă

Întreprinderile continuă să se întrebe de ce agenții lor nu funcționează bine în producție. Răspunsul vine aproape întotdeauna de la date. Patrimoniul de date nu a fost niciodată pregătit. Sursele erau fragmentate în zeci de sisteme construite la momente diferite pentru scopuri diferite. Definițiile erau inconsistente în întreaga unitate de afaceri. Nu exista un strat semantic. Nu exista o sursă unică de adevăr. Existau doar ani de datorie de date acumulată, pe care nimeni nu a prioritizat-o, deoarece vechile sisteme funcționau suficient de bine.

Această datorie nu dispare atunci când construiți un agent pe baza acesteia. Acesta devine realitatea de operare a agentului. Un agent care navighează prin surse de date fragmentate nu raționează peste o imagine coerentă a afacerii. Face tot posibilul cu ceea ce poate găsi, reconciliind contradicțiile pe parcurs și producând ieșiri care par plauzibile până când cineva care cunoaște afaceria le examinează cu atenție. Agentul nu este defect. Datele pe care i-au fost furnizate erau defecte înainte de a începe proiectul.

Deriva datelor și deriva conceptului le fac și mai grave în timp. Când distribuția reală a intrărilor se schimbă față de ceea ce a fost modelul antrenat, agentul nu aruncă o eroare. Continuă să ruleze și începe să genereze ieșiri greșite, cu încredere și la scară. Fără o conductă MLOps sau AIOps integrată în stratul de orchestrare a agentului, nu există mecanism pentru a prinde acest lucru înainte ca daunele să se acumuleze. Agentul care a funcționat acceptabil la lansare se degradează în mod liniștit timp de săptămâni înainte ca cineva să conecteze calitatea ieșirii la o problemă de date care a existat de la început.

Modernizarea datelor și modernizarea inteligenței artificiale sunt adesea tratate ca fluxuri de lucru paralele, secvențiate independent și finanțate separat. Ele nu sunt paralele. Nu poți construi un agent de încredere pe baza unei arhitecturi de date care era defectă înainte de a începe proiectul. Secvența contează enorm și sărirea peste stratul de date pentru a merge mai repede pe stratul de inteligență artificială este una dintre cele mai comune și costisitoare greșeli pe care le fac întreprinderile.

Un tablou de bord greșit dă cuiva un număr greșit. O acțiune greșită a agentului poate declanșa un proces în aval înainte ca cineva să observe, aprobând o factură care nu ar fi trebuit să fie aprobată, rutând greșit un steag de conformitate sau ajustând prețurile în afara gamei intenționate. Sistemele agenților necesită o observabilitate specializată, nu tablouri de bord reciclate din monitorizarea generală a aplicațiilor.

Avantajul unei platforme unificate de date

Întreprinderile care au trecut la o platformă unificată de date înainte de a începe programele lor de inteligență artificială agentică se extind mai repede decât cele care nu au făcut-o. Când Lakehouse, depozitul de date, modelul semantic și conductele trăiesc într-un singur mediu, așa cum se întâmplă în Microsoft Fabric, agenții au o suprafață consistentă pentru a interoga. Acest lucru elimină o întreagă clasă de eșec care provine de la agenții care sar între sisteme cu scheme diferite, cicluri de actualizare diferite și definiții diferite ale aceluiași metric de afaceri.

Acesta este motivul pentru care platformele pe care le aleg întreprinderile pentru unificarea datelor contează atât de mult pentru rezultatele lor de inteligență artificială agentică. Abordarea unificată a lui Microsoft Fabric aduce împreună Lakehouse, depozitul de date, modelul semantic și conductele într-un singur mediu, oferind întreprinderilor centrate pe Microsoft (MSFT ) un avantaj structural atunci când trec de la experimentare la utilizare operațională reală.

Databricks oferă același principiu prin arhitectura Lakehouse și Catalogul Unity, oferind echipelor de date și inteligență artificială un strat de guvernanță unificat pe date structurate și nestructurate, cu integrarea MLflow pentru a urmări comportamentul modelului în producție. Abordarea Snowflake se bazează pe Cortex AI și pe cuplarea strânsă dintre norul de date și inferența inteligenței artificiale, permițând întreprinderilor să ruleze încărcături de lucru ale agenților direct împotriva datelor guvernate și live, fără latența și riscurile de consistență care vin din mutarea datelor între sisteme.

Fiecare dintre aceste platforme reprezintă un drum diferit către același rezultat. Un strat de date coerent, observabil și de încredere suficient pentru a susține luarea deciziilor agenților la scară. Alegerea corectă depinde de stiva existentă a întreprinderii. Ceea ce nu este opțional este să faci această alegere și să te angajezi să o faci înainte de a construi stratul agentului deasupra. Ceea ce separă echipele care fac progrese de cele care sunt încă blocate în proiecte-pilot nu este platforma pe care au ales-o. Este faptul că au reparat stratul de date mai întâi.

Guvernanța înainte, nu după

Guvernanța construită ulterior nu este guvernanță deloc. Când un agent are autoritate de luare a deciziilor în aval și barajele sunt adăugate la șase luni după implementare, întreprinderea a acumulat deja șase luni de decizii neauditate. Traseul de audit trebuie proiectat înainte ca agentul să devină operațional, nu refăcut după primul incident.

Același principiu se aplică și securității inteligenței artificiale, controlului accesului bazat pe rol și definirii permisiunilor. Un agent fără permisiuni corect definite poate accesa date pe care nu ar trebui să le acceseze, executa acțiuni în afara limitei sale intenționate sau deveni o suprafață de atac activă. Acestea sunt riscuri care trebuie abordate în faza de dezvoltare, nu descoperite la revizia de implementare.

Dacă guvernanța nu este încorporată înainte ca conductele de antrenament să fie construite, datele incorecte sau adversarale pot intra în procesul de antrenament nedetectate. Un model antrenat pe date compromise funcționează bine pe benchmark-uri, dar derapează în producție, exact felul de eșec silent care este cel mai periculos atunci când deciziile agenților au consecințe reale de afaceri.

Actul UE privind inteligența artificială și cadrul regulator din ce în ce mai mare din jurul inteligenței artificiale fac ca acest lucru să fie din ce în ce mai greu de ignorat și întreprinderile care nu au construit guvernanță în arhitectura agenților lor acumulează expunere la conformitate care va costa semnificativ mai mult pentru a o rezolva ulterior.

De la proiect-pilot la producție: Ce presupune de fapt

Întreprinderile care închid gap-ul de producție sunt cele care repară stratul de date înainte de a construi stratul agentului. Ele încorporează guvernanța în proiectare, nu după ce daunele au fost făcute. Ele construiesc observabilitate în arhitectura de orchestrare și rulează managementul schimbărilor în paralel cu livrarea tehnică. Ele tratează analiza modului de eșec ca o cerință importantă de proiectare.

Cercetarea Deloitte privind inteligența artificială a întreprinderilor arată că accesul lucrătorilor la inteligența artificială a crescut cu 50% în 2025 și ponderea companiilor care rulează mai mult de 40% din proiectele lor de inteligență artificială în producție completă urmează să se dubleze în următoarele șase luni. Întreprinderile care câștigă în acest moment nu sunt cele cu modelele cele mai avansate. Sunt cele care au construit infrastructura operațională pentru a rula inteligența artificială în mod fiabil și au făcut-o înainte de a construi agenții.

Fiecare întreprindere care rulează încă proiecte-pilot separate ar trebui să se concentreze pe asigurarea faptului că investiția în modele și interfețe este proporțională cu investiția în pregătirea datelor și arhitectura de guvernanță care va determina dacă acești agenți vor reuși vreodată să iasă din mediu de demonstrație. Acesta este locul în care multe întreprinderi dau greș.

Până când acest lucru se va schimba, multe dintre proiectele de inteligență artificială agentică în care companiile au investit resurse și au sperat să aducă roade vor muri pe viță.

Amit conduce echipa de inteligență artificială la Kanerika, unde proiectează și implementează soluții practice, orientate spre afaceri, de inteligență artificială care ajută organizațiile să deblocheze o valoare mai mare din datele lor. Cu o experiență profundă în dezvoltarea Python, modelarea statistică, învățarea automată și prelucrarea limbajului natural, Amit aduce o bază tehnică puternică în fiecare angajament.

Experiența sa cuprinde pregătirea datelor, analiza predictivă și tehnici avansate de regresie, permițând livrarea de soluții scalabile, bazate pe insight. De-a lungul anilor, Amit a sprijinit mai mulți clienți Kanerika prin construirea de strategii de inteligență artificială, modele predictive și soluții cu impact care conduc la luarea deciziilor, automatizarea fluxurilor de lucru și livrarea de rezultate măsurabile.