Cei care promovează cel mai zgomotos „AI-ul rezolvă orice problemă de analytics" sunt, în general, cei care nu l-au pus încă să răspundă la o întrebare reală de business cu mize. Cei care folosesc zilnic Copilot, Claude sau Gemini într-un context de echipă de date au inventarul lor de cazuri în care modelele au eșuat. Iar inventarul nu este scurt.

Analiza limitelor AI analiza date nu mai e un exercițiu teoretic în 2026. Este o competență operațională. Echipele care înțeleg unde modelele dau erori sistematice livrează rezultate consistente. Cele care nu înțeleg, livrează rapid — și greșit.

limite AI: Halucinații pe joins și pe schemă

Este eroarea cea mai des întâlnită în lucrul cu agenți AI conectați la data warehouse. Modelul primește o întrebare în limbaj natural, are acces la schema bazei de date, generează un SQL. La prima vedere arată corect. Rulează. Returnează rezultate. Dar joins-ul a fost făcut între două tabele care au coloane cu nume similar dar semantic diferit.

Exemplu concret raportat de o echipă de e-commerce în 2025: agentul a unit tabelul orders cu tabelul shipments pe coloana order_id. Părea logic. Problema — în acel sistem, shipments.order_id se referea la order-ul original, dar tabelul orders avea o coloană derivată order_id care era de fapt ID-ul unei subcomenzi după split. Rezultatul: cifre umflate cu 30%, raport livrat managementului, decizie de buget bazată pe el. Eroarea a fost descoperită trei săptămâni mai târziu.

Modelele nu „înțeleg" semantica datelor. Citesc nume de coloane și deduc relații prin similaritate. Acolo unde data dictionary-ul lipsește sau e incomplet, AI-ul construiește ipoteze. Uneori bune. Uneori dezastruoase.

Cum se atenuează

Singura soluție eficientă: semantic models bine construite în Power BI, Looker, Cube sau dbt, cu metrici definite o singură dată și exploatate de AI. Fără strat semantic, modelele lucrează direct pe tabele brute și inventează relații. Documentația Microsoft pe semantic models e referința utilă pentru echipele care construiesc acest strat. dbt Semantic Layer și Cube oferă alternative cloud-agnostic.

Pierderea contextului în analize multi-step

Întrebările simple primesc răspunsuri bune. Întrebările care implică 4-5 pași de analiză — selectare segment, calcul metrică, comparație temporală, atribuire pe cauză — încep să decupleze.

Problema concretă: într-o conversație lungă cu un agent AI, modelele pierd informații introduse în primele schimburi. Dacă în prompt 1 ai specificat că analiza e doar pentru clienții B2B, după 6-7 schimburi modelul poate să includă și B2C fără să anunțe. Context window-uri tot mai mari (1M tokens pe Claude Opus, similar pe Gemini) ajută, dar problema nu e doar de capacitate. E de relevanță — modelul nu mai distinge ce informație din conversație trebuie să rămână activă.

Pentru analize multi-step, abordarea care funcționează în 2026: împărțire în pași discreți, fiecare cu propriul prompt, cu rezultat verificat înainte de pasul următor. Nu e workflow conversațional. E mai aproape de un pipeline.

Slabă performanță pe date noi sau anormale

Un model antrenat pe pattern-uri generale de date business se descurcă bine pe scenarii tipice. Pe ce iese din distribuție — sezonalități neobișnuite, evenimente unice (lockdown, restructurare, schimbare de strategie comercială) — interpretările devin slabe.

Cazul tipic: o companie de retail întreabă agentul „de ce am vândut mai mult în martie decât în februarie". Modelul răspunde cu explicații generice — „creștere sezonală tipică, intrare în sezonul de primăvară". Dar în acel an, februarie a fost luna în care s-a închis un magazin major. Răspunsul AI-ului e plauzibil dar greșit. Doar cineva care cunoaște operațiunile companiei știe să pună întrebarea corectă: „cum afectează închiderea magazinului X comparația lună-la-lună?".

AI-ul nu are context organizațional. Nu știe că tocmai s-a încheiat o achiziție. Nu știe că un competitor a lansat o promoție. Toate aceste „date neînregistrate" sunt invizibile pentru model dar esențiale pentru interpretare.

Probleme cu cauzalitatea

Modelele actuale identifică corelații. Stabilirea cauzalității necesită design de experiment, control pentru variabile confuzive, sau cunoaștere de domeniu. Niciuna nu e punctul forte al unui LLM general.

Întrebări de tip „de ce a crescut churn-ul?" primesc răspunsuri sub formă de listă de factori corelați. Toți pot fi reali. Niciunul nu este neapărat cauza. Un analyst experimentat va spune: „ipoteza 1 are sens, dar trebuie să o testez. Construiesc o cohortă control, o cohortă tratament, măsor diferența". Modelul nu propune asta spontan. La cerere, poate ajuta cu metodologia. Din proprie inițiativă, nu o face.

Pentru analize cauzale, abordarea în 2026 este hibridă: AI-ul ajută la identificarea ipotezelor, omul proiectează testul, AI-ul ajută la execuția statistică, omul interpretează. Niciun pas nu poate fi sărit.

Costuri operaționale care escaladează

O echipă de 15 oameni care folosește intens AI în analytics — Copilot in Power BI, GitHub Copilot pentru SQL, un agent intern conectat la warehouse — poate ajunge la $8.000-$15.000/lună în costuri combinate. Asta în plus față de costul cu warehouse-ul, licențele BI, salariile.

Costul nu e doar abonamentul. E inferența pe agentul intern, care, dacă utilizatorii fac interogări intensive, generează facturi semnificative. Un singur query complex prin Snowflake Cortex sau Databricks Genie poate costa câțiva dolari. Înmulțit cu 200 query-uri/zi pe echipă, ajungi rapid la sume neprevăzute.

Decizii de control al costului

• Limitare per utilizator pe agent intern.
• Caching agresiv pentru întrebări repetitive.
• Direcționare către modele mai mici pentru sarcini de bază (un Haiku în loc de un Opus pentru rezumate scurte).
• Monitoring lunar al costului per echipă, nu doar la nivel de organizație.

Adaptare slabă la jargon intern și la KPI-uri proprii

Fiecare companie are propriul vocabular. „Activation rate" la o companie SaaS înseamnă altceva decât la alta. „Closed-won" în CRM-ul vostru poate include sau exclude oportunitățile reactivate. „Lifetime value" se calculează în 5 moduri diferite în 5 companii diferite.

Modelele AI generale nu cunosc convențiile interne. Răspund pe baza definițiilor comune din literatură. Asta produce inconsecvențe între ce livrează AI-ul și ce așteaptă business-ul.

Soluția practică: documentare în prompt-uri sistem sau în RAG (retrieval augmented generation) atașate la agentul intern, cu definițiile companiei. Dar menținerea acestei documentații e o sarcină nouă, care înainte nu exista. Companiile care iau acest pas în serios văd rezultate. Cele care îl ignoră primesc răspunsuri tehnic corecte dar funcțional inutile.

Eșec la întrebări cu mai multe interpretări legitime

„Cum performează echipa de sales?" — un prompt aparent simplu. Răspunsul depinde de ce înțelegi prin „performează": volum, pipeline velocity, conversie, satisfacție client, retenție. Toate sunt răspunsuri valide. Modelul alege una, de obicei cea statistică implicită — volumul.

Acceptabil pentru o conversație informală. Inacceptabil când răspunsul ajunge într-un raport către board. Aici intervine rolul analyst-ului ca traducător: clarificarea cererii înainte de execuție.

Modelele nu cer clarificări spontan. Răspund cu ce au, pe baza interpretării proprii. Doar prompt-uri sistem explicite („dacă întrebarea e ambiguă, cere clarificare înainte de a executa") schimbă comportamentul. Și chiar și atunci, e inconsistent.

Restricții de acces și guvernanță

Un agent AI conectat la data warehouse-ul companiei vede tot ce vede contul de service folosit pentru conectare. Asta înseamnă că, dacă nu există control fin de acces, AI-ul poate returna date pe care utilizatorul care întreabă nu ar trebui să le vadă.

Cazuri concrete raportate: un manager de marketing care a întrebat agentul „arată-mi salariile medii pe departament pentru context comp" — și a primit datele, pentru că contul de service avea acces. Sau un analyst care a întrebat despre datele unui client în CRM și a primit informații confidențiale pe care nu trebuia să le vadă.

Implementarea row-level security la nivel de warehouse, integrarea cu Active Directory pentru filtrare per utilizator, audit log-uri pentru fiecare query AI — toate sunt prerequisite pentru folosire enterprise. Lipsa lor a produs incidente reale în 2024-2025, raportate de echipe de compliance.

Halucinații în prezentare narativă

Output-ul Copilot in Power BI generează „insight-uri" automate. „Vânzările au crescut cu 12% în Q3 din cauza performanței regiunii EMEA". Sună util. Problema: „din cauza" este o inferență cauzală. Modelul nu a făcut analiza atribuirii. A văzut că EMEA a crescut și a presupus că asta explică creșterea totală.

Dacă acest text ajunge într-un raport executiv fără verificare, devine narativ companiei. Decizii bugetare se iau pe baza unor concluzii pe care nimeni nu le-a validat.

Best practice în 2026: orice narativ generat automat trebuie etichetat ca atare în interfața de raportare („Generated by AI — review before sharing") și revizuit de un om înainte de distribuire externă.

Probleme de stabilitate și reproductibilitate

Același prompt, rulat de două ori, produce rezultate ușor diferite. Pentru analize creative — generare de ipoteze, redactare de narativ — asta e acceptabil. Pentru analize numerice, e o problemă.

Modelele cu temperature 0 (sau setare echivalentă) reduc variabilitatea, dar nu o elimină. Modificări de versiune ale modelelor (de la GPT-5.0 la 5.1, de la Claude Opus 4 la 4.5) pot schimba comportamentul fără preaviz.

Echipele care lucrează cu AI în pipeline-uri de producție au învățat să versionifie prompt-urile, să facă regression testing pe seturi de cazuri-test la fiecare update de model, și să mențină un fallback la versiunile anterioare când este posibil.

Ce decizii rămân clar umane

Inventarul de limite produce un corolar util: ce nu se delegă la AI în niciun caz, indiferent de cât de bune devin modelele.

• Definirea KPI-urilor companiei.
• Decizii de comunicare a unor rezultate sensibile către management.
• Interpretarea contextului organizațional (politică internă, strategie, evenimente recente).
• Validarea cauzalității prin design experimental.
• Decizii etice despre ce date se folosesc și cum.
• Negocierea definițiilor între departamente.

Asta nu sunt limite tehnice care vor dispărea cu următoarea generație de modele. Sunt limite structurale — proceduri care necesită responsabilitate umană pentru că au consecințe pe care AI-ul nu le poate suporta.

Tema se leagă natural de discuția despre Data Analyst, unde am intrat în detaliu pe pattern-urile pe care le observăm în piață. În fond, limite AI nu e doar un concept tehnic — este o decizie de business cu impact direct pe productivitatea echipei.

Următoarele 12-18 luni

Direcțiile care vor reduce parte din limite sunt vizibile. Agenții multi-step cu memoria îmbunătățită vor diminua problema pierderii contextului. Semantic models native AI (Cube, dbt Semantic Layer, MetricFlow) vor reduce halucinațiile pe joins. Modele specializate pe analytics — antrenate pe SQL, pe pattern-uri de business, pe vocabularul BI — vor înlocui parțial modelele generale pentru sarcini de date.

Ce nu se va schimba: nevoia de validare umană pentru deciziile cu mize. Companiile care investesc acum în procese de review, în semantic layers, în governance și în training-ul echipelor pe limitele AI-ului vor obține valoare durabilă. Cele care presupun că „AI-ul rezolvă singur" vor descoperi, una câte una, exact problemele enumerate aici — și unele pe care nu le-am acoperit încă.

În practică, limite AI a trecut de la subiect de roadmap la prioritate operațională pentru echipele care livrează rezultate de business — exact tipul de tracțiune pe care o vedem reflectată în deciziile reale de buget. Pentru cititorii care lucrează zilnic cu limite AI, articolul rămâne deschis pentru update-uri pe măsură ce piața evoluează.