Transformare digitală cu AI: ce se schimbă

Transformarea digitală cu AI înseamnă că o parte din munca repetitivă cu documente, date și tichete trece la sisteme care citesc, extrag și propun, iar oamenii verifică și decid. Pentru o companie din România, asta pornește de obicei de la datele care există deja în ERP, SAP, SharePoint sau e-mail, nu de la un proiect nou de digitalizare.

Articolul ăsta descrie ce se schimbă concret într-o companie: în procese, în date, în roluri, în riscuri și în felul în care măsori rezultatul. Îl scriem din perspectiva Ran·AI, o firmă din România care construiește sisteme AI peste Claude pentru companii: agenți pe procese de back-office, asistenți pe documentele interne, integrări cu SAP și cu sistemele de HR.

Ce diferă față de digitalizarea clasică?

Digitalizarea clasică a mutat hârtia în sisteme. Facturile au intrat în ERP, contractele în SharePoint, cererile interne în aplicația de tichete, raportările fiscale în formatele cerute de ANAF, cum ar fi SAF-T. Informația a devenit digitală, dar a rămas citită, interpretată și copiată dintr-un sistem în altul tot de oameni.

AI lucrează peste conținutul din aceste sisteme, mai ales peste partea nestructurată: e-mailuri, PDF-uri, contracte, proceduri interne scrise în Word, notele libere din tichete. Un model de limbaj poate citi un contract și extrage termenul de plată, poate găsi în proceduri răspunsul la întrebarea unui angajat și poate propune o clasificare pentru un tichet nou. Ce nu se schimbă: sistemele de evidență rămân aceleași, iar regulile de business rămân ale companiei, scrise explicit, nu deduse de model.

De aici o diferență practică: o transformare digitală cu AI nu cere de obicei un sistem nou care să înlocuiască ERP-ul. Cere un strat care se conectează la ce există deja, cu permisiuni, evaluări și jurnal de acțiuni. Cum arată acel strat construit pentru producție, nu pentru demonstrație, e descris pe pagina de implementare AI pentru companii.

Ce procese se schimbă primele?

Primele procese care se schimbă sunt cele documentare, repetitive și verificabile, de regulă în back-office. Patru tipare apar des:

• Facturi și e-Factura: sistemul preia facturile primite, extrage câmpurile, le confruntă cu comanda și cu contractul și pregătește înregistrarea în ERP. Omul primește doar diferențele, evidențiate, și decide. Regulile fiscale rămân la contabilitate.
• Rapoarte recurente: sistemul adună datele lunii din ERP, din aplicația de HR și din uneltele de proiect, le aduce în același format și scrie prima versiune a raportului, cu sursa fiecărei cifre. Omul verifică și semnează, în loc să copieze din cinci exporturi.
• Răspunsuri din proceduri interne: un asistent răspunde la întrebările angajaților din proceduri, regulamente și politici, cu trimitere la documentul sursă. Persoana care deține procedura rămâne responsabilă de conținut; asistentul doar o face ușor de găsit.
• Tichete de back-office: sistemul clasifică tichetele de IT, HR sau financiar, caută răspunsul în documentația internă și propune un răspuns. Cererile repetitive se închid repede, iar cele ambigue ajung la un om cu contextul deja adunat.

Tiparul comun: sistemul citește, extrage și propune, iar acțiunile cu consecințe, adică scrierea în sistemele de evidență, comunicarea în afara firmei sau depășirea unui prag, trec printr-o confirmare umană. Cum se construiesc astfel de fluxuri, cu o listă explicită de unelte, permisiuni ca ale unui angajat și jurnal complet, găsești pe pagina despre agenți AI și automatizarea proceselor.

Ce nu se schimbă primele: fluxurile deterministe, cu intrare structurată și reguli stabile. Acolo automatizarea clasică, prin reguli, scripturi sau RPA, rămâne mai ieftină și mai ușor de verificat decât un model de limbaj.

Ce date trebuie să existe înainte?

Partea mai puțin vizibilă a transformării digitale e pregătirea datelor. Un sistem AI nu poate fi mai bun decât documentele la care are acces, iar patru condiții decid dacă un proces e pregătit:

• Acces: o cale tehnică prin care sistemul citește datele (API, conector, export programat) și cineva care o aprobă. Conturile tehnice și aprobările de la proprietarii datelor sunt, de regulă, cea mai lungă întârziere dintr-un proiect.
• Permisiuni: regulile despre cine vede ce trebuie să existe deja în sistemele sursă. Un asistent pe documente le respectă, nu le reinventează: un angajat care nu are acces la un dosar de HR nu primește un răspuns construit din el.
• Locul documentelor: un singur SharePoint ordonat e alt punct de plecare decât documente împrăștiate între file servere, atașamente de e-mail și foldere personale. Fiecare sursă în plus înseamnă un conector și un set de permisiuni de verificat.
• Calitatea datelor din ERP: furnizori duplicați, câmpuri completate inconsecvent, nomenclatoare neactualizate. Un agent care confruntă facturi cu comenzi dă exact peste aceste probleme, iar o parte din ele trebuie rezolvate înainte de lansare, nu după.

Arhitectura care leagă aceste date de un model, cu regăsire hibridă, filtrare pe permisiuni și citări către sursă, e descrisă pe larg în ghidul nostru despre RAG enterprise.

Cine conduce schimbarea în companie?

Un proiect AI condus doar de IT ajunge des la un sistem corect tehnic pe care nu îl folosește nimeni. Schimbarea are nevoie de un proprietar de proces din interior: persoana care răspunde azi de fluxul de facturi, de raportare sau de suportul intern, care are mandat să decidă schimbări în el și buget de operare după lansare.

Împărțirea rolurilor, așa cum o vedem noi:

• La tine rămân: alegerea procesului, regulile de business, criteriile de succes, aprobarea accesului la sisteme, oamenii care verifică ce ajunge la om și decizia de a extinde sau de a opri.
• Echipa externă face: maparea procesului real, integrarea cu sistemele, evaluările, pragurile de încredere, monitorizarea, documentația și predarea codului și a runbook-urilor.
• IT-ul intern asigură: identitatea și conturile tehnice, mediile, securitatea și, după predare, operarea curentă.

Oamenii care fac munca zilnic trebuie implicați de la început. Ei știu excepțiile, pașii nedocumentați și locurile unde procesul scris diferă de cel real, adică exact punctele unde un sistem AI ajută sau greșește.

Cum arată primele trei luni?

Un calendar realist pentru primul proces are trei etape, fiecare cu un rezultat care se poate arăta:

1. Analiză, două săptămâni. În prima săptămână se mapează procesele și datele; în a doua se testează ipotezele pe date reale, în volum mic, și se scriu harta de oportunități, planul de infrastructură și estimările pentru primii pași. Detaliile sunt pe pagina despre analiza AI, care e și primul pas pe care îl recomandăm.
2. Pilot pe un singur proces, de regulă patru până la opt săptămâni. Utilizatori reali, date reale, criterii de succes scrise înainte de start. Dacă nu sunt atinse, pilotul se oprește.
3. Producție. Integrare în sistemele companiei, permisiuni, monitorizare, cost per operațiune și plan de escaladare. Ritmul acestei etape depinde mai mult de organizație decât de echipa tehnică: accesul la sisteme și aprobările interne.

Bugetul se fixează pe baza a ce iese din analiză, nu înainte. Ce anume influențează costul unui astfel de proiect, inclusiv costurile recurente pe care le subestimează aproape toată lumea, am descris în articolul despre costul AI într-o companie din România.

Ce lipsește intenționat din calendar: cinci piloți în paralel. Un flux dus până în producție îți spune mai mult despre organizație decât zece demonstrații.

Ce riscuri apar și cum le ținem sub control?

Patru categorii de risc apar în aproape orice transformare digitală cu AI, iar fiecare are un răspuns concret, tehnic sau organizațional.

Date personale și GDPR

GDPR se aplică în continuare, indiferent de AI, iar evaluarea de impact (DPIA), acolo unde e necesară, nu dispare și nu e înlocuită de EU AI Act. Practic: procesare și găzduire în Uniunea Europeană, acces minim necesar, jurnale de acces și o decizie explicită despre ce date au voie să ajungă la model.

Date care nu pleacă din companie

Pentru date sensibile există trei variante: API cu termeni de zero-retenție, deployment privat în infrastructura companiei sau pseudonimizare la gateway, astfel încât modelul să nu vadă niciodată valorile reale. Datele nu se folosesc la antrenarea modelelor. Alegerea se face pe clase de date, nu o dată pentru toată firma.

EU AI Act

Din 2 august 2026 se aplică cea mai mare parte a obligațiilor din regulament. O companie care folosește AI fără să îl vândă are rol de deployer, iar lista ei e operațională: inventarul sistemelor AI, clasificarea pe risc, transparența față de persoanele care interacționează cu un AI și alfabetizarea AI a personalului, aplicabilă deja din februarie 2025. Sistemele folosite la recrutare și în decizii de HR intră de regulă la risc ridicat și cer supraveghere umană și păstrarea log-urilor. Pașii, în ordine, sunt în articolul despre EU AI Act pentru companiile din România.

Erori în cazurile-limită

Riscul cel mai banal e și cel mai frecvent: sistemul greșește discret la excepția rară, la furnizorul cu contract atipic, în luna în care s-a schimbat regula. Răspunsul ține de arhitectură: evaluări automate pe cazuri reale înainte de producție, praguri sub care sistemul nu răspunde, ci escaladează, și o coadă de verificare umană în care omul vede diferența, sursa și acțiunea propusă.

Cum măsurăm dacă a funcționat?

Rezultatul unei transformări digitale cu AI se măsoară pe pilot, cu cifrele companiei, nu se promite dinainte. Condiția e ca procesul să fie măsurat înainte de start; altfel nu ai cu ce compara. Patru indicatori acoperă de obicei tot ce contează:

• Timp pe proces: cât durează de la factura primită până la înregistrarea în ERP, sau de la tichetul deschis până la răspuns, înainte și după.
• Erori: câte cazuri procesate automat au fost greșite, câte au ajuns corect la verificare umană și ce tipuri de erori se repetă.
• Adopție: câți oameni folosesc sistemul fără să li se ceară, săptămână de săptămână. Un sistem impus și ocolit nu a schimbat procesul.
• Cost per operațiune: consumul de modele și costul de operare, raportate la volumul real.

Criteriile se scriu înainte de pilot, împreună cu pragul de la care proiectul continuă. Dacă pilotul nu le atinge, concluzia corectă e să oprești sau să alegi alt proces. Și asta e un rezultat util: afli pe date reale ce nu merită automatizat, înainte să plătești pentru o implementare completă.