De ce se blochează proiectele-pilot de IA și cum decizi dacă merită extinși

O demonstrație poate răspunde bine la zece întrebări alese de echipă. A doua zi, sistemul întâlnește documente noi, utilizatori cu drepturi diferite și cazuri pe care nimeni nu le-a pregătit. Dacă nu există o persoană care să repare erorile și să urmărească rezultatele, demonstrația rămâne o prezentare reușită, nu un proces util.

Nu există un procent universal de succes pentru piloții IA. Studiile folosesc definiții diferite pentru „pilot”, „producție” și „reușită”, iar o cifră luată dintr-un rezumat secundar nu spune ce se va întâmpla în firma ta. Ghidul de față propune criterii observabile pentru a decide dacă să continui, să corectezi sau să oprești o probă.

Ca reper metodologic, AI RMF Playbook al NIST (resursă oficială în engleză) grupează gestionarea voluntară a riscurilor IA în guvernare, definirea contextului, măsurare și gestionare. Recomandările se pot adapta la dimensiunea și riscul proiectului; nu reprezintă o certificare și nu înlocuiesc cerințele legale aplicabile în România sau în UE.

Diferența dintre o demonstrație și un proces operabil

Într-o demonstrație, datele sunt selectate, întrebările sunt cunoscute și un specialist poate corecta rezultatul pe loc. Într-un proces real, intrările sunt variate, sursele se schimbă, unele persoane nu au dreptul să vadă anumite informații, iar o eroare trebuie tratată fără improvizații. Un pilot bun testează tocmai această diferență.

Verifică patru elemente înainte să spui că proiectul este pregătit:

• Problemă și responsabil: există o sarcină delimitată și cineva din organizație poate decide dacă soluția ajută sau trebuie oprită.
• Date permise și reprezentative: proba include cazuri uzuale și excepții, cu drepturile de acces și calitatea datelor verificate.
• Rezultat măsurabil: compari fluxul actual cu cel propus, incluzând verificarea umană și erorile.
• Operare după pilot: sunt stabilite suportul, bugetul, măsurarea continuă și metoda de revenire la procesul anterior.

Un pilot poate avea un rezultat valoros chiar dacă decizia finală este „nu lansăm”. Descoperirea timpurie a unui cost prea mare sau a unui risc necontrolat poate evita o investiție mai mare într-un sistem nepotrivit.

Înainte de pilot: ce decizie vrei să iei?

Alege un proces îngust, de exemplu clasificarea asistată a cererilor interne înainte ca o persoană să răspundă. „Să folosim IA în relația cu clienții” este prea larg: nu precizează cine folosește rezultatul, ce date intră sau ce înseamnă o îmbunătățire. Scrie o fișă de o pagină cu cinci întrebări.

1. Ce sarcină se schimbă? Notează intrarea, ieșirea, persoana care verifică și cazurile excluse. Dacă fluxul actual nu poate fi descris, desenează-l înainte să alegi modelul.
2. Care este punctul de plecare? Măsoară timpul pe caz, rata de eroare, corecțiile, costul și experiența utilizatorului într-o perioadă comparabilă. Fără această bază, o demonstrație rapidă nu dovedește câștigul.
3. Ce date se pot folosi? Revizuiește permisiunile, calitatea, contractele și păstrarea. Nu copia toate fișierele într-un serviciu doar pentru că integrarea este ușoară.
4. Ce rezultat justifică pasul următor? Stabilește dinainte praguri proprii pentru calitate, timp, cost și risc. Include un prag care obligă la oprire sau la întoarcerea la procesul manual.
5. Cine plătește și întreține sistemul? Numește responsabilul de proces, persoana tehnică, suportul și, când este relevant, responsabilul de securitate sau protecția datelor.

Pragurile diferă după utilizare. Un instrument care propune texte interne poate accepta erori diferite de un flux care influențează contracte, plăți sau persoane. Secțiunea Map din NIST (în engleză) ajută la descrierea contextului, utilizatorilor, limitelor și efectelor înainte de evaluare.

În timpul pilotului: testează fluxul complet

Nu evalua doar răspunsul modelului. Urmărește o sarcină din momentul primirii până când o persoană acceptă, modifică sau respinge rezultatul. Include exemple obișnuite, date incomplete și situații în care sistemul trebuie să spună „nu știu” ori să ceară ajutor.

• Calitatea: definește cum marchează un revizor un rezultat corect, incomplet, fals sau riscant. Raportează și numărul de cazuri evaluate, nu numai procentul celor reușite.
• Timpul net: include pregătirea, așteptarea, verificarea, corecțiile și rezolvarea erorilor. Timpul de răspuns al API nu este timpul economisit de echipă.
• Permisiunile: folosește utilizatori cu roluri diferite, surse retrase și intrări rău intenționate. Testează dacă un document poate determina sistemul să divulge date ori să sară o aprobare.
• Integrarea: verifică unde ajunge propunerea, ce rezultat a fost executat în realitate și dacă o eroare poate repeta o acțiune sensibilă.
• Adopția: observă cine folosește ieșirea și când se revine la metoda veche. Uneori problema este proiectarea fluxului, nu calitatea modelului.

Păstrează metrici agregate și exemple autorizate. Nu transforma toate întrebările și răspunsurile în jurnale accesibile tuturor. Secțiunea Measure din NIST (în engleză) oferă întrebări pentru alegerea măsurilor și documentarea limitelor.

Poarta de ieșire: continui, corectezi sau oprești?

Compară rezultatele cu pragurile scrise înainte de prima probă. Discuția de închidere nu poate înlocui această comparație.

Glisează tabelul pentru a vedea toate coloanele.

O decizie de continuare nu înseamnă lansare pentru întreaga organizație. Limitează utilizatorii și volumul, urmărește rezultatele, definește alerte și păstrează oprirea reversibilă. Secțiunea Manage din NIST (în engleză) include monitorizarea după lansare, răspunsul la incidente și retragerea sistemului.

Calculează valoarea fără să inventezi un ROI

Pornește de la timpul net pe caz: durata procesului actual minus timpul de pregătire, revizuire și refacere din fluxul nou. Aplică diferența unui volum comparabil, cu un cost al timpului potrivit organizației. Scade apoi licențele, infrastructura, suportul, formarea, securitatea și mentenanța. Notează separat îmbunătățirile de calitate pe care nu le poți transforma onest în bani.

Exemplu ipotetic: o echipă gestionează 100 de cereri pe lună și, după corectarea erorilor, economisește șase minute nete la fiecare cerere. Calculul dă zece ore lunare. Acest număr nu dovedește singur o economie financiară: trebuie să verifici dacă orele se eliberează în practică, ce alte sarcini se fac cu ele și cât costă operarea sistemului. Dacă un parametru se schimbă, rezultatul se schimbă.

Când poți, compară grupuri sau perioade asemănătoare și notează schimbările sezoniere. Într-o probă mică, prezintă rezultatul ca indiciu, nu ca certitudine statistică. Nu promite o rată de rentabilitate înainte să vezi ce se întâmplă după demonstrație.

Responsabilitățile după prima săptămână

O firmă mică nu are nevoie de un departament nou pentru fiecare pilot, dar are nevoie de roluri clare. Proprietarul procesului decide dacă rezultatul ajută. Persoana care întreține integrarea urmărește incidentele și costurile. Securitatea și protecția datelor verifică accesul când cazul o cere. Utilizatorii descriu excepțiile. Sponsorul oferă timp și buget, nu doar semnează proiectul inițial.

Scrie canalul pentru incidente, cine poate opri fluxul, cum se aprobă schimbarea modelului ori furnizorului, cât de des se măsoară calitatea și ce se întâmplă când o sursă de date este retrasă. Secțiunea Govern din NIST (în engleză) oferă repere pentru responsabilități și revizuire continuă.

Două scenarii ilustrative

Scenariu ipotetic care ar putea continua: echipa delimitează clasificarea asistată a cererilor, măsoară punctul de plecare, folosește date autorizate și verifică toate ieșirile pilotului. Dacă timpul net și calitatea ating pragurile, testează revenirea la fluxul vechi și extinde doar către un grup mic de utilizatori. Acesta este un exemplu de decizie, nu un rezultat de client sau o promisiune de economii.

Scenariu ipotetic care merită oprit: o firmă încearcă un chatbot „pentru orice” cu documente amestecate și fără responsabil de proces. Demonstrația arată bine, dar nu există drepturi pe utilizator, surse verificabile sau persoană care tratează erorile. Oprirea și alegerea unei singure întrebări de business pot fi mai utile decât schimbarea modelului.

Planul de lucru, fără un calendar universal

1. Descrie cazul, punctul de plecare, utilizatorii, excluderile și pragurile de continuare ori oprire.
2. Pregătește o mostră permisă și reprezentativă; verifică drepturile și calitatea datelor.
3. Construiește traseul minim cu verificare umană și o ieșire sigură la eroare.
4. Măsoară calitate, timp net, utilizare, cost și riscuri cu cazuri normale și excepții.
5. Decide pe baza dovezilor dacă repari, oprești sau încerci o lansare limitată; atribuie operarea și procedura de revenire.

Nu există o durată de opt sau douăsprezece săptămâni potrivită pentru toate proiectele. Accesul la date, integrările, riscul și disponibilitatea oamenilor schimbă calendarul. Fixează momentele de decizie și condițiile de ieșire, apoi estimează timpul pentru cazul real.

Următorul pas

Alege un singur proces care se repetă și completează fișa cu responsabil, date, punct de plecare și praguri de oprire. Dacă nu poți defini aceste elemente, investește întâi în clarificarea procesului. O decizie bazată pe dovezi poate economisi mai multă muncă decât încă o demonstrație.

Dacă vrei sprijin pentru a delimita pilotul și pentru a pregăti măsurile, contactează MoriahTech IA în română. Suportul este comun pentru clienții români și spanioli. Spune-ne ce proces ai, ce volum gestionezi și ce decizie trebuie să iei după test.