Aplicații interne făcute cu AI: păstrați, înlocuiți sau refaceți?

Echipa a făcut o aplicație cu AI și acum o parte din activitate trece prin ea. Cine răspunde de ea și cum alegeți: o păstrați, o înlocuiți sau o refaceți?

Dragoș NiculaiFondator și CEO

Lorelai NiculaiFondator și Managing Business Partner

Pe scurt

Când o aplicație internă făcută cu AI ajunge să susțină un flux real de lucru, viitorul ei trebuie decis în mod asumat. Lămuriți mai întâi ce activități depind de ea și cine răspunde de ea. Apoi alegeți: o păstrați pe platformă, cu reguli clare de acces și control; o înlocuiți cu un produs existent; sau o refaceți ca software la comandă, atunci când fluxul de lucru ori integrările sunt cu adevărat specifice companiei.

În multe companii, cineva a făcut deja o aplicație cu ajutorul AI. Un coordonator a descris unui instrument AI cum ar trebui urmărite solicitările clienților și a obținut o aplicație funcțională. Un responsabil de vânzări a transformat un fișier Excel într-un mic portal. Totul a durat câteva zile, a funcționat, iar colegii au continuat să lucreze cu ele.

A fost o alegere rezonabilă. O aplicație făcută repede de oamenii care cunosc munca surprinde adesea fluxul de lucru mai bine decât ar fi reușit un caiet de sarcini.

Întrebarea apare mai târziu și, de regulă, nu o pune nimeni explicit. Aplicația conține acum datele clienților. Un alt departament lucrează zilnic în ea. Cineva cere să fie legată de programul de contabilitate sau colegul care a făcut-o urmează să treacă pe alt post. Din acel moment, aplicația face parte din felul în care funcționează compania, dar nimeni nu a hotărât ce este: un experiment, ceva de înlocuit cu un produs sau un sistem pe care compania și-l asumă.

Ghidul de mai jos vă ajută să luați această decizie. Pornește de la două lucruri de lămurit, ce activități depind de aplicație și cine răspunde de ea, apoi compară trei variante: o păstrați pe platforma pe care a fost făcută, cu reguli clare de acces; o înlocuiți cu un produs existent; sau o refaceți ca software la comandă. La final arată și când merită costul celei de-a treia variante.

Când devine o aplicație făcută rapid parte din activitate

Tratați aplicația ca parte din activitatea companiei, nu ca experiment, de îndată ce cel puțin două dintre situațiile de mai jos sunt adevărate:

O folosesc și oameni din afara echipei care a făcut-o. Alte departamente, parteneri sau clienți au cont în ea.
Conține date personale, date despre clienți sau date financiare. Nume, adrese, contracte, prețuri, informații de plată.
Prin ea se iau sau se înregistrează decizii despre bani ori despre clienți. Aprobări, alocări de lucrări, oferte, rambursări.
Un alt sistem sau proces se bazează pe ce produce. Rapoartele, facturarea sau o ședință săptămânală pornesc de la datele ei.
O singură persoană o poate modifica. De regulă, colegul care a făcut-o, pe lângă atribuțiile lui de bază.

Pragul de două situații este o regulă practică, nu una juridică. Datele personale aduc obligații chiar și singure, iar o singură situație poate conta dacă aplicația susține o activitate critică.

Niciuna dintre aceste situații nu înseamnă că aplicația a fost o greșeală. Înseamnă că activitatea companiei depinde acum de ea, iar această dependență merită o decizie asumată.

De ce se pune întrebarea tocmai acum

Aplicațiile făcute astfel nu mai sunt o excepție, iar atât platformele, cât și directorii IT au observat asta.

Pe 28 septembrie 2026, Lovable a anunțat că aplicațiile create pe platforma sa pot fi publicate în mediul Microsoft Entra al unei companii: angajații intră cu contul de serviciu, iar aplicațiile apar în inventarul de aplicații al companiei. Funcția folosește o componentă Microsoft aflată încă în etapa de previzualizare publică, iar autentificarea cu Entra pentru întregul spațiu de lucru este inclusă în abonamentele Business și Enterprise. În august, Replit a extins jurnalele de audit și controalele de administrare pentru clienții săi Enterprise. Direcția este limpede: platformele încep să aducă aceste aplicații sub regulile pe care IT-ul le aplică deja, mai ales în abonamentele superioare.

Directorii IT descriu același fenomen din partea lor. Într-un sondaj Harris Poll realizat pentru Dataiku în rândul a 685 de directori IT din opt țări și publicat pe 24 septembrie 2026, 84% au spus că angajații creează agenți și aplicații AI mai repede decât poate IT-ul să le țină sub control. În sondajul Retool din iunie 2026, doar 5% dintre cei 307 lideri din tehnologie și securitate chestionați, majoritatea din companii cu cel puțin 200 de angajați, se declarau foarte siguri că au o imagine completă asupra aplicațiilor interne care rulează în mediul de producție. Niciunul dintre sondaje nu include România și nu se concentrează pe companiile mai mici, iar ambele vin de la firme care vând soluții de guvernanță sau de aplicații interne. Le puteți citi ca semn al direcției, nu ca măsurători ale pieței în care lucrați.

Apoi, datele. La sfârșitul lui septembrie, firma de securitate UpGuard a publicat un studiu care a identificat 16.326 de baze de date găzduite pe Supabase, o platformă de backend folosită des de aplicațiile făcute cu AI, cu tabele pe care le putea citi oricine de pe internet; peste jumătate conțineau indicii de date personale. Cauza ține de configurare: tabelele create prin API-ul Supabase, calea folosită de obicei de instrumentele AI de programare, nu primesc implicit protecția de acces la nivel de rând. TechCrunch a relatat pe larg rezultatele. Pentru o companie din Uniunea Europeană, datele personale dintr-o aplicație aduc obligații GDPR, indiferent cum a fost făcută aplicația.

Mai întâi, lămuriți ce depinde de aplicație

Înainte să comparați variantele, răspundeți la șase întrebări împreună cu oamenii care folosesc aplicația. De multe ori ajung o oră sau două, iar răspunsurile restrâng de obicei alegerea la una sau două variante.

Întrebarea	De ce contează
Ce activități ale companiei depind acum de această aplicație?	Definește fluxul de lucru, nu lista de funcții.
Cine o folosește și cine o vede din afara companiei?	O aplicație internă și una folosită de clienți au obligații diferite.
Ce date conține și unde sunt stocate?	Datele personale aduc obligații, oricum ar fi fost făcută aplicația.
Din ce sisteme preia date și în ce sisteme scrie sau ar trebui să scrie?	Integrările concentrează de obicei cea mai mare parte a efortului și a riscului.
Cine o poate modifica și cine răspunde când nu funcționează?	O aplicație fără un responsabil numit este un risc, oricare ar fi varianta aleasă.
Cât ar costa o zi fără ea?	Arată câtă protecție și câtă investiție se justifică.

Trei variante și când se potrivește fiecare

	O păstrați pe platformă, cu reguli clare	O înlocuiți cu un produs existent	O refaceți ca software la comandă
Se potrivește când	Fluxul de lucru este intern, abonamentul dumneavoastră include conturi individuale, reguli de acces, jurnale de audit și export de date, iar integrările sunt puține sau acoperite de conectorii platformei	Fluxul de lucru se dovedește standard și un produs îl acoperă fără improvizații importante	Fluxul de lucru este specific felului în care lucrați, schimbul de date cu sistemele de bază trebuie să fie fiabil într-un mod pe care platforma sau produsele nu îl asigură, ori clienții depind de aplicație la un nivel pe care soluția actuală nu îl poate susține
Ce presupune	Un responsabil numit, conturi individuale, reguli de acces verificate, un backup și un export testate, un abonament care include controalele necesare	Alegerea produsului pe baza cerințelor dumneavoastră, migrarea datelor, instruirea echipei	O etapă scurtă de analiză, apoi o primă versiune gândită în jurul fluxului de lucru, cu aplicația existentă drept punct de plecare pentru cerințe
Costuri recurente	Abonamentul platformei, adesea per utilizator sau pe nivel de abonament	Licențele produsului, de obicei per utilizator	Găzduirea, mentenanța și suportul pentru un sistem care vă aparține
Riscul principal	Aplicația depășește pe nesimțite ce poate oferi platforma sau se schimbă prețurile ori condițiile platformei	Improvizațiile reapar acolo unde produsul nu acoperă cazurile dumneavoastră speciale	Dezvoltați mai mult decât are nevoie fluxul de lucru
Pasul următor obișnuit	O verificare internă, uneori o integrare mică	O listă scurtă de produse și un test pe date reale	O analiză de 1-2 săptămâni care stabilește prima versiune și un interval de investiție

Primele două variante sunt adesea cele potrivite și costă de obicei mai puțin la început. Păstrarea aplicației pe o platformă care oferă acum conturi individuale și audit este o decizie întemeiată, cu condiția să existe cineva care răspunde de ea. Înlocuirea cu un produs este alegerea mai bună ori de câte ori fluxul de lucru este suficient de comun încât un furnizor l-a rezolvat deja bine. Fiecare variantă vine și cu o dependență: de platformă, de furnizorul produsului sau de cei care întrețin sistemul la comandă. Face parte din decizie să știți pe care o alegeți.

Când se justifică software-ul la comandă

Un sistem la comandă costă de obicei mai mult la început decât celelalte două variante. Își justifică investiția în situații clare:

Fluxul de lucru este cu adevărat distinctiv. Regulile de preț, tipurile de lucrări sau circuitele de aprobare fac parte din felul în care vă diferențiați, iar produsele standard readuc pași manuali în jurul lor.
Schimbul de date cu sistemele de bază trebuie să fie fiabil. Citirea datelor dintr-un fișier Excel este simplă. Scrierea corectă a înregistrărilor într-un ERP, într-un CRM sau în programul de contabilitate, de fiecare dată, și revenirea la o stare corectă atunci când ceva nu merge cer cel mai mult efort tehnic. Un proces încheiat fără eroare nu dovedește că rezultatul este corect. În benchmarkul ThinkingBox, realizat de cercetători de la Microsoft și din trei universități americane, agenți AI au lucrat în fluxuri de business simulate; în aproximativ două treimi dintre încercările eșuate, agentul a terminat normal, modificase deja date și nu primise nicio eroare. Studiul a măsurat agenți AI, nu aplicații făcute cu AI, dar concluzia rămâne valabilă: un flux care „a mers la demonstrație” spune puțin despre corectitudinea datelor de fiecare dată.
Clienții sau partenerii depind de el. Utilizatorii externi au nevoie de reguli de acces, suport și disponibilitate. Unele platforme și produse le oferă bine; când soluția dumneavoastră nu le poate asigura la nivelul pe care îl așteaptă clienții, un sistem la comandă merită luat în calcul.
Aveți nevoie de control asupra evoluției, operării sau proprietății. Aplicația a devenit parte din produsul sau serviciul dumneavoastră, iar viitorul ei nu poate depinde de prețurile ori de prioritățile unei platforme.

Atunci când un sistem la comandă se justifică, aplicația făcută de echipă este un punct de plecare valoros, nu o pierdere. Arată cum vor să lucreze oamenii cei mai apropiați de activitate, iar folosirea reală arată ce contează cu adevărat. Sistemul nou pornește de la ea și adaugă ce a lăsat deoparte versiunea rapidă: roluri și permisiuni, excepțiile, proprietatea asupra datelor, integrările, monitorizarea, backupurile și o cale clară de revenire după o problemă. Dacă se reutilizează ceva din codul generat se stabilește de la caz la caz, în etapa de analiză.

Serviciul nostru de dezvoltare software personalizat pornește exact de aici. Analiza durează de obicei 1-2 săptămâni și stabilește ce intră în prima versiune. Prima versiune funcțională urmează, de regulă, în 6-10 săptămâni, în funcție de integrări și de cât de multe lucruri sunt încă neclare. Codul, documentația și conturile proiectului aparțin companiei dumneavoastră.

Un exemplu ipotetic: aplicația de dispecerat

Să luăm o companie inventată pentru acest ghid. O firmă de mentenanță a clădirilor, cu aproximativ șaizeci de angajați, trimite tehnicieni la sediile clienților. Coordonatorul de dispecerat a făcut cu un instrument AI o aplicație de urmărire a lucrărilor: intră solicitările clienților, lucrările se alocă, iar tehnicienii le marchează ca finalizate. În câteva luni, patru echipe lucrează în aplicație, care conține adresele și persoanele de contact ale clienților. Acum departamentul financiar vrea ca lucrările finalizate să ajungă automat în facturare, în programul de contabilitate.

Verificarea dependenței. Dispeceratul funcționează acum prin aplicație, aceasta conține date personale, trebuie să scrie într-un sistem de bază și doar coordonatorul o poate modifica. Patru dintre cele cinci situații se aplică.

Cele trei variante.

O păstrați. Este posibil pentru dispecerat, dacă platforma permite conturi individuale, reguli de acces și export. Facturarea rămâne întrebarea deschisă: varianta funcționează doar dacă platforma poate trimite fiabil lucrările finalizate în programul de contabilitate și cineva răspunde de această legătură.
O înlocuiți. Merită o analiză serioasă: există produse pentru echipele de intervenții pe teren care acoperă dispeceratul și se conectează la programele de contabilitate uzuale. Dacă unul dintre ele acoperă tipurile de contracte ale firmei fără improvizații, acesta este răspunsul.
O refaceți ca software la comandă. Se justifică doar dacă tipurile de lucrări și regulile de preț din contracte sunt suficient de specifice încât produsele standard să readucă pași manuali. În acest caz, aplicația coordonatorului devine punctul de plecare pentru cerințe.

Exemplul arată raționamentul, nu un verdict. Varianta potrivită depinde de informații pe care doar compania respectivă le are.

Ce faceți luna aceasta, oricare ar fi varianta

Patru pași protejează compania până la luarea deciziei și sunt utili oricare ar fi rezultatul:

Numiți un responsabil. O singură persoană care răspunde de aplicație, de datele și de utilizatorii ei.
Dați fiecărui utilizator propriul cont. Conturile comune fac imposibilă gestionarea și verificarea accesului.
Verificați unde sunt stocate datele și cine le poate citi, inclusiv ce a rămas accesibil public din cauza setărilor implicite.
Restaurați un backup, ca test. Un backup care nu a fost restaurat niciodată este o presupunere, nu o protecție.

Dacă aplicația urmează să ajungă la clienți sau într-un pilot mai larg, ghidul nostru despre ce mai are nevoie un prototip vibecoded înainte să poată susține o afacere detaliază verificările necesare. Dacă păstrarea sau înlocuirea aplicației devine o linie în bugetul de anul viitor, cele șase întrebări din înainte să aprobați bugetul IT pe 2027 se aplică direct.

Întrebări frecvente

Putem păstra aplicația făcută de echipă și doar să o securizăm mai bine?

De multe ori, da. Dacă fluxul de lucru este intern, iar abonamentul la platformă include conturi individuale, reguli de acces, jurnale de audit și export de date, păstrarea aplicației, cu un responsabil numit, poate fi varianta potrivită. Merită reevaluată atunci când aplicația are nevoie de o integrare fiabilă, în ambele sensuri, cu sistemele de bază sau când clienții încep să depindă de ea. Verificați însă mai întâi ce poate oferi platforma.

Dacă refacem aplicația la comandă, se pierde munca echipei?

Nu. Aplicația arată cum vor să lucreze oamenii cei mai apropiați de activitate, iar folosirea reală arată ce contează. Sistemul nou pornește de aici. Dacă se reutilizează ceva din codul generat se stabilește în etapa de analiză, de la caz la caz.

Cât durează și cui îi aparține rezultatul?

Analiza durează de obicei 1-2 săptămâni și stabilește ce intră în prima versiune. Prima versiune funcțională urmează, de regulă, în 6-10 săptămâni, în funcție de integrări și de cât de multe lucruri sunt încă neclare. Costul depinde de amploarea proiectului, de integrări și de calitatea datelor, iar după analiză primiți o estimare pentru fiecare etapă. Codul, documentația și conturile proiectului aparțin companiei dumneavoastră.

Dacă o aplicație făcută cu AI susține deja o parte din activitate

Dacă doriți o părere despre situația dumneavoastră, trimiteți-ne prin formularul de contact patru informații: ce face aplicația, cine o folosește, ce date conține și cu ce sisteme trebuie să comunice. Vă spunem pe care dintre cele trei variante am analiza-o mai întâi și ce ar trebui să confirme etapa de analiză.