Ce Face Diferit un AI PM: Incertitudine, Calibrare și Probabilism

Apeși un buton și obții exact același rezultat de fiecare dată. Ceri unui model să rezume un document și, la același input, primești răspunsuri diferite — unele corecte, altele fluent și convingător greșite. Distanța dintre cele două lumi nu este una de stil, ci de fundament: managementul produselor construite pe modele de inteligență artificială guvernează un sistem care răspunde probabilist, în care corectitudinea nu este o proprietate binară, ci o distribuție. Din această singură diferență decurg trei concepte care revin în fiecare modul al cursului — incertitudinea structurală, calibrarea încrederii și degradarea tăcută — și, odată cu ele, cea mai profundă schimbare de mentalitate pe care o cere rolul.

De la Specificație Deterministă la Comportament Distribuțional

Un PM software clasic scrie specificații care descriu un contract: „când utilizatorul apasă Trimite, formularul este validat, iar dacă toate câmpurile sunt corecte, comanda este salvată". Contractul este verificabil punct cu punct. Un tester poate confirma că butonul face X de fiecare dată. Dacă nu îl face, există un bug, iar bug-ul are o cauză localizabilă în cod.

Produsele AI rup acest contract. Un model lingvistic mare — fie GPT-5.5, Claude Opus 4.8 sau Gemini 3.1 Pro — nu execută o regulă scrisă de un inginer, ci produce ieșirea cea mai probabilă conform distribuției învățate din date. Specificația nu mai poate spune „rezumă documentul corect de fiecare dată". Cel mult poate spune: „pe distribuția reală de documente ale utilizatorilor noștri, modelul produce un rezumat pe care un evaluator uman îl consideră acceptabil în aproximativ 85% din cazuri, iar restul de 15% trebuie proiectat — prin guardrails, fallback-uri, escaladare umană sau reformularea promisiunii făcute utilizatorului".

Trecerea aceasta — de la „butonul face X de fiecare dată" la „modelul are dreptate într-o fracțiune din cazuri, iar restul trebuie gestionat ca produs" — este cea mai profundă schimbare de mentalitate pe care o cere rolul. Ea reorientează întreaga muncă a PM-ului:

• Cerința nu mai este o listă de funcționalități, ci o țintă pe o distribuție de comportamente.
• Acceptanța nu mai este un test pass/fail pe un caz, ci o evaluare statistică pe un set reprezentativ de cazuri.
• Defectul nu mai este neapărat un bug în cod, ci adesea o nepotrivire între distribuția de inputuri pe care a fost gândit produsul și distribuția reală întâlnită în producție.

Tabel: Două Lumi, Două Mentalități

Calibrarea Încrederii: A Ști CE NU Știi

Al doilea concept central este calibrarea încrederii PM-ului. În statistică și în evaluarea modelelor, calibrarea înseamnă că nivelul de încredere declarat corespunde frecvenței reale de a avea dreptate: dacă spui „sunt 70% sigur" în multe situații, atunci în aproximativ 70% dintre ele ar trebui să ai dreptate. Transpus în rolul de produs, un AI PM calibrat este unul care își cunoaște cu precizie marginile de incertitudine: știe pentru ce tipuri de inputuri sistemul este fiabil, pentru care este fragil și — crucial — știe ce nu știe încă despre comportamentul sistemului.

Anti-pattern-ul opus este supraîncrederea: PM-ul care, după ce a văzut sistemul funcționând în câteva exemple alese de el, declară produsul „gata" și extrapolează acea performanță la întreaga populație de utilizatori. Supraîncrederea este periculoasă pentru că modelele AI sunt convingătoare chiar și când greșesc — produc text fluent, sigur pe sine, plauzibil. Un PM care nu și-a calibrat propria încredere va confunda fluența cu corectitudinea.

Calibrarea se manifestă în decizii concrete:

1. Înainte de lansare: PM-ul calibrat insistă pe o evaluare reprezentativă, nu pe un demo. Întreabă „ce procent din inputurile reale arată ca exemplele pe care le-am testat?" și „care este coada — cazurile rare unde costul unei erori este mare?".
2. În definirea promisiunii: nu promite ceea ce nu poate susține pe distribuția reală. Reformulează valoarea produsului astfel încât să fie adevărată chiar și pentru cazurile în care modelul greșește.
3. În monitorizare: presupune că nu va ști totul dinainte și construiește mecanisme de observare a comportamentului în producție.

Degradarea Tăcută: De Ce Eșecurile AI Nu Țipă

A treia diferență fundamentală este modul în care eșuează sistemele AI. Un sistem software clasic care se strică tinde să o facă zgomotos: aruncă o excepție, returnează un cod de eroare, afișează un ecran roșu. Eșecul este vizibil și declanșează alarme.

Sistemele AI se degradează adesea tăcut. Un model care a început să primească un tip de input ușor diferit de cel pe care a fost gândit — un nou jargon, un format de document nemaiîntâlnit, o limbă cu acoperire mai slabă — nu va arunca o excepție. Va continua să producă ieșiri fluente, încrezătoare și greșite. Din punctul de vedere al infrastructurii, totul pare sănătos: latența e bună, codul HTTP e 200, nu există stack trace. Din punctul de vedere al valorii livrate utilizatorului, produsul s-a stricat — dar nimeni nu primește o alertă.

Acest fenomen are două cauze frecvente:

• Drift de date (data drift): distribuția inputurilor reale se îndepărtează în timp de cea pe baza căreia ai evaluat sistemul. Utilizatorii încep să folosească produsul altfel, apar subiecte noi, vocabularul se schimbă.
• Cazuri rare (long tail): situații care apar rar individual, dar care cumulate formează o fracțiune semnificativă din trafic, și pe care evaluarea inițială, axată pe cazurile frecvente, le-a ratat.

Consecința pentru rolul de PM este directă: nu îți poți permite o mentalitate de tip „lansează și uită". Produsul AI trebuie observat continuu, iar PM-ul trebuie să trateze măsurarea comportamentului ca pe o funcționalitate de prim rang, nu ca pe un task opțional de mentenanță. Cum se face concret această măsurare — proiectarea de evaluări — este subiectul modulului 2; aici reținem doar principiul: fără măsurare, degradarea tăcută rămâne invizibilă până când o descoperă utilizatorii sau presa.

De Ce un Demo Impresionant Nu Este un Produs

Din cele trei diferențe de mai sus decurge hook-ul central al cursului: un demo nu este un produs. Un demo este, prin construcție, un caz fericit — un input ales cu grijă, pe care sistemul îl tratează bine, prezentat într-un context controlat. Este o dovadă de fezabilitate, nu o dovadă de fiabilitate.

Distanța dintre demo și produs este exact distanța dintre „a funcționat o dată, pentru un input ales de mine" și „funcționează consistent, pe distribuția reală de inputuri ale utilizatorilor, inclusiv pe coada de cazuri rare, timp de luni de zile, în condiții de drift". Acea distanță — denumită frecvent last mile-ul produselor AI — este unde se concentrează munca reală de produs și unde eșuează majoritatea inițiativelor care arătau spectaculos în faza de prototip. Lecția următoare disecă anatomia capcanei demo-ului în detaliu.

Logica Bunurilor Complementare: De Ce Crește Cererea pentru AI PM

Un argument important despre relevanța rolului vine din scrisoarea The Batch a lui Andrew Ng (DeepLearning.AI), intitulată „AI Product Managers Will Be In-Demand". Argumentul lui Ng se sprijină pe logica economică a bunurilor complementare: când prețul unui bun scade, cererea pentru bunurile sale complementare crește. Instrumentele AI fac construirea de software — în special prototiparea — dramatic mai ieftină și mai rapidă. Dacă a construi devine ieftin, atunci bunul complementar a cărui valoare crește este capacitatea de a decide ce merită construit: identificarea problemei potrivite, definirea produsului, prioritizarea, validarea cu utilizatorii.

Tocmai aceasta este munca PM-ului. Ng subliniază în plus că, într-un context unde prototiparea e ieftină, PM-ii AI valoroși tind să strângă feedback rapid și adesea să prototipeze ei înșiși, scurtând bucla dintre idee și învățare. Reținem argumentul calitativ — nu vom cita aici cifre de piață sau de salariu, pentru că nu dispunem de o sursă primară verificabilă pentru ele, iar standardul cursului interzice numerele inventate. Ceea ce contează pedagogic este direcția: ieftinirea construirii ridică, nu coboară, valoarea judecății de produs.

Cadrul lui Marily Nika și Poziționarea Acestui Curs

Cartea Building AI-Powered Products a lui Marily Nika (O'Reilly, 2025) oferă cadrul de referință pentru rolul de AI PM și pentru ciclul de viață al produsului AI, pe care îl vom dezvolta pe parcursul cursului — de la descoperire și strategie, prin construcție și evaluare, până la lansare, leadership și măsurare. Acest curs adoptă cadrul respectiv din scaunul de produs.

Este util de delimitat ce nu face această lecție și unde se duce restul materiei:

• Nu intrăm în governance și conformitate tehnică pentru ingineri — acela este unghiul cursului «AI Security și Ethical Engineering» (slug: ai-security-ethics); aici tratăm conformitatea, inclusiv EU AI Act, strict pedagogic și din perspectiva deciziei de produs, niciodată ca pe o consultanță juridică.
• Nu intrăm în implementarea de evaluări — acela este teritoriul modulului 2 și al cursului «AI Evals pentru LLM-uri în Producție» (slug: ai-evals-llm-productie); aici ne oprim la principiul că măsurarea este răspunsul la degradarea tăcută.
• Nu scriem cod, nu intrăm în arhitectură adâncă și nu discutăm internele modelelor.

Unghiul rămâne constant: ce decizie ia un PM și de ce, într-o lume în care produsul este probabilist. Ai acum vocabularul — incertitudine, calibrare, probabilism — dar a numi diferența dintre un demo și un produs nu este totuna cu a ști unde, exact, se rupe iluzia. Lecția următoare coboară în anatomia acelei capcane, iar fiecare modul de după adaugă o piesă la aparatul de decizie cu care vei putea susține, în fața oricui, de ce produsul tău rezistă acolo unde altele arătau spectaculos și cădeau tăcut.