AI-ul nu este problema. Implementarea fără responsabilitate este.
Alpar TorokInteligența artificială nu mai este un subiect de viitor. Este deja în business, în marketing, în website-uri, în automatizări, în aplicații, în suport clienți, în generare de conținut și, tot mai des, în dezvoltare software.
Și asta nu este o problemă.
Problema apare când oamenii confundă accesul la AI cu competența. Faptul că poți genera cod cu AI nu înseamnă automat că știi să construiești software. Faptul că poți genera un landing page nu înseamnă că înțelegi securitate, GDPR, infrastructură, date personale, deployment, testare sau mentenanță. Faptul că un tool îți dă un rezultat în câteva minute nu înseamnă că acel rezultat poate fi pus direct în producție, conectat la sisteme reale și folosit de clienți reali.
Aici intervine partea mai puțin spectaculoasă, dar mult mai importantă: responsabilitatea.
La Dalbe, folosim AI. Îl folosim pentru idei, structură, analiză, texte, cod, automatizări, documentație, verificări și eficientizare. Dar diferența esențială este că îl folosim ca oameni care au experiență în software, e-commerce, SEO, securitate, date și procese digitale. AI-ul ne ajută să lucrăm mai rapid, dar nu înlocuiește judecata tehnică. Și nici nu ar trebui.
Pe scurt
- AI-ul poate accelera munca, dar nu înlocuiește competența tehnică.
- Codul generat cu AI trebuie verificat, securizat, testat și deployat corect.
- Datele personale nu trebuie expuse niciodată în frontend sau în cod public.
- O automatizare reală nu înseamnă doar un demo generat în câteva minute.
- În următorii ani, testarea și verificarea vor deveni mai importante, nu mai puțin importante.
- AI-ul trebuie folosit cu reguli clare, mai ales când atinge date, clienți sau procese reale de business.
Ce s-a întâmplat în această săptămână
În aceeași săptămână, am avut trei situații diferite care arată foarte clar unde suntem cu AI-ul în practică. Nu în teorie. Nu în prezentări frumoase. Nu în articole care spun că AI-ul va schimba totul, ca și cum asta nu s-ar fi spus deja despre fiecare tehnologie nouă din ultimii 25 de ani.
Prima situație: câteva proiecte realizate cu integrare AI prin Google AI Studio au fost atacate. Nu am fost hackuiți. Sistemele nu au fost compromise. Nu au fost expuse date ale clienților. Dar am văzut foarte clar o creștere a tentativelor de abuz.
Atacatorii au încercat să forțeze sistemele, iar în proces au fost consumate o parte din tokenurile AI integrate înainte ca problema să fie prinsă, marcată și oprită împreună cu mecanismele de protecție Google.
Concluzia este simplă: când AI-ul este integrat într-o aplicație reală, nu mai vorbim despre joacă. Nu mai este doar un prompt într-o interfață. Devine parte dintr-un sistem software, cu costuri, limite, acces, securitate, monitorizare și responsabilitate.
Un sistem AI integrat într-o aplicație trebuie tratat ca orice altă resursă expusă: cu limitări, monitorizare, loguri, alerte și posibilitatea de a opri rapid accesul atunci când apare un comportament suspect. Dacă nu există aceste lucruri, costurile pot crește înainte ca cineva să observe problema.
A doua situație: pentru un client pe care nu îl putem menționa, o altă companie a implementat un landing page. Faptul că landing page-ul părea generat cu AI nu era problema. Nu avem nimic împotriva folosirii AI-ului. Problema era că implementarea arăta clar că echipa respectivă nu înțelegea lucruri fundamentale de dezvoltare software.
În codul de frontend erau hardcodate informații care nu aveau ce căuta acolo: elemente de logică, locul unde se salvează datele și zone legate de informații personale. Pentru cine nu este tehnic, traducerea este simplă: risc de data leak, risc de încălcare GDPR și risc serios de imagine pentru client.
Un fișier .env este folosit, în mod normal, pentru a ține separat configurații sensibile: chei API, date de conectare, endpointuri private sau alte informații care nu trebuie să ajungă în codul public. Când astfel de informații sunt puse direct în frontend, ele pot deveni vizibile pentru oricine știe unde să se uite.
Dacă am fi conectat acel landing page direct la sistemul nostru fără verificare, clientul ar fi putut ajunge într-o situație foarte neplăcută. Nu pentru că AI-ul a fost folosit, ci pentru că rezultatul a fost tratat ca produs final fără ca cineva competent să îl verifice.
Am explicat situația clientului, am refăcut componenta și am deployat-o corect. Asta a fost posibil pentru că folosim AI, dar avem și cunoștințe de programare, securitate și implementare. Diferența este mare. Uneori diferența dintre „pare că funcționează” și „este sigur de pus în producție” este exact partea pe care utilizatorul final nu o vede.
A treia situație a fost mai umană, deci evident mai obositoare. O persoană a venit la birou pentru o ofertă. Era vorba despre o automatizare. Am estimat aproximativ 8 ore de lucru, cu un cost de 500 EUR + TVA. Reacția a fost furioasă. Persoana respectivă ne-a spus că știe AI, că a văzut că astfel de lucruri se pot face în câteva minute și că nu este normal să avem nevoie de o zi.
A plecat supărată.
Probabil nu era clientul potrivit pentru noi. Și este în regulă. Nu orice lead trebuie transformat în client. Uneori cel mai bun proiect este proiectul pe care nu îl iei.
AI-ul poate genera cod. Dar codul generat nu este automat software bun.
În 2026, oricine poate încerca să scrie cod cu AI. Întrebarea mai importantă este: ar trebui oricine să pună acel cod în producție?
Răspunsul sincer este: nu fără verificare.
AI-ul poate genera o funcție, o pagină, un formular, un script, o automatizare sau chiar o aplicație aparent funcțională. Dar o aplicație reală nu înseamnă doar cod care rulează o dată pe laptop. O aplicație reală trebuie deployată corect, securizată, testată, monitorizată și gândită pentru edge cases.
Ce se întâmplă dacă utilizatorul introduce date greșite? Ce se întâmplă dacă un bot atacă formularul? Ce se întâmplă dacă API-ul răspunde lent? Ce se întâmplă dacă cineva încearcă să consume tokenuri AI în mod abuziv? Ce se întâmplă dacă datele personale sunt vizibile în frontend? Ce se întâmplă dacă cheia API ajunge publică? Ce se întâmplă dacă un workflow automat trimite informații greșite către client?
Aceste întrebări nu sunt detalii. Sunt diferența dintre un demo și un sistem real.
AI-ul poate ajuta foarte mult la generarea codului, dar nu își asumă responsabilitatea pentru ce se întâmplă după. Nu merge la client să explice scurgerea de date. Nu răspunde la notificări GDPR. Nu plătește costurile generate de un API abuzat. Nu repară imaginea firmei după ce un landing page prost implementat expune informații personale.
Responsabilitatea rămâne la oameni.
Un demo nu este același lucru cu o soluție funcțională
Aici este una dintre cele mai mari confuzii create de AI: oamenii compară timpul necesar pentru a genera un demo cu timpul necesar pentru a livra o soluție funcțională.
Un demo poate dura câteva minute. O soluție care trebuie să funcționeze corect pentru un business real are nevoie de analiză, verificare, integrare, testare și asumare.
Când estimăm 8 ore pentru o automatizare, nu spunem că scrierea primului draft de cod durează 8 ore. Spunem că un rezultat utilizabil, verificat și potrivit pentru business poate necesita 8 ore.
Poți cere AI-ului să îți genereze un script în 3 minute. Dar cine verifică dacă scriptul tratează cazurile greșite? Cine îl conectează la sistemele existente? Cine se asigură că datele nu sunt expuse? Cine verifică logica? Cine testează scenariile reale? Cine repară problema când ceva nu merge? Cine își asumă responsabilitatea față de client?
AI-ul poate reduce timpul de execuție. Nu elimină nevoia de competență.
Asta este o diferență pe care piața va trebui să o învețe. Uneori ușor. Alteori după câteva incidente costisitoare, pentru că aparent așa învață civilizația cel mai bine.
De ce testerii vor deveni tot mai importanți
Vedem tot mai multe aplicații, landing page-uri și automatizări generate rapid cu AI. Unele sunt utile. Unele sunt acceptabile. Altele sunt un dezastru îmbrăcat frumos.
Din acest motiv, credem că rolul testerului va deveni unul dintre cele mai importante roluri din următorii ani.
Nu vorbim doar despre testare clasică, în sensul de „apasă pe buton și vezi dacă merge”. Vorbim despre oameni care înțeleg produsul, utilizatorul, riscurile, fluxurile de date, edge cases, securitatea de bază și impactul unei erori asupra businessului.
Cu cât AI-ul va produce mai mult cod, mai multe texte, mai multe automatizări și mai multe interfețe, cu atât verificarea va deveni mai importantă. Dacă producția devine mai rapidă, controlul calității trebuie să devină mai serios. Altfel doar producem greșeli mai repede.
Un tester bun nu va fi doar persoana care găsește buguri. Va fi persoana care pune întrebările incomode înainte ca problema să ajungă la client.
- Unde se salvează datele?
- Cine are acces la ele?
- Ce se întâmplă dacă formularul este atacat?
- Ce se întâmplă dacă AI-ul răspunde greșit?
- Ce se întâmplă dacă utilizatorul introduce date neașteptate?
- Există limitări de consum?
- Există loguri?
- Există mecanisme de oprire?
- Există verificare umană acolo unde este nevoie?
Aceste întrebări nu omoară inovația. O fac utilizabilă.
Problema nu este că AI-ul este folosit în marketing
Să fim clari: nu este greșit ca o agenție de marketing să folosească AI. Ar fi chiar ciudat să nu îl folosească în 2026. AI-ul poate ajuta la texte, idei, layouturi, mesaje, variații de reclame, structură de landing page, analiză de audiență și multe alte lucruri.
Problema apare când o echipă care nu înțelege partea tehnică începe să livreze componente tehnice ca și cum ar fi produse sigure.
Un landing page care colectează date nu este doar design. Este un punct de intrare într-un sistem. Dacă acel formular colectează nume, emailuri, telefoane, preferințe sau alte date personale, deja intrăm în zona GDPR. Dacă acele date sunt salvate greșit sau expuse în frontend, problema nu mai este estetică. Este juridică, tehnică și de reputație.
Aici se vede diferența dintre „arată bine” și „este bine făcut”.
Un client non-tehnic nu are de unde să știe ce este un fișier .env, unde trebuie ținute cheile API, de ce datele sensibile nu se hardcodează în frontend sau de ce logica de business nu trebuie expusă public. Clientul plătește specialiști tocmai pentru ca aceste lucruri să fie gândite corect.
Dacă specialistul nu știe, AI-ul nu îl salvează. De multe ori îi dă doar un rezultat suficient de convingător încât greșeala să pară profesională.
România este în urmă, dar riscurile nu așteaptă
În România, multe companii încă sunt în urmă la digitalizare. Unele nu au procese clare, nu au CRM folosit corect, nu au date curate, nu au proceduri interne, nu au o strategie reală pentru website, SEO, automatizări sau customer support.
Apoi apare AI-ul și toată lumea speră că problema se rezolvă magic.
Nu se rezolvă.
AI-ul nu repară haosul. De cele mai multe ori îl accelerează.
Dacă datele sunt greșite, AI-ul va lucra cu date greșite. Dacă procesul este neclar, AI-ul va automatiza un proces neclar. Dacă echipa nu știe ce verifică, AI-ul va produce rezultate care par bune, dar pot fi complet greșite. Dacă nimeni nu își asumă responsabilitatea, AI-ul devine o scuză comodă.
În același timp, cei care fac abuzuri nu așteaptă ca piața să devină matură. Vedem tot mai multe tentative de fraudă, conținut fals, reclame false, mesaje automate, deepfake-uri, pagini construite rapid și mecanisme care exploatează lipsa de educație digitală. În timp ce unele firme încă se întreabă dacă AI-ul merită folosit, scammerii l-au integrat deja în procesele lor.
Acesta este unul dintre motivele pentru care responsabilitatea nu mai este opțională. Dacă folosim AI în business, trebuie să înțelegem și riscurile.
AI Act schimbă discuția
La nivel european, AI Act a intrat în vigoare la 1 august 2024. Unele obligații se aplică deja, inclusiv cele legate de AI literacy și de practicile interzise, începând cu 2 februarie 2025. Aplicarea completă vine progresiv, cu termene importante în 2026 și 2027.
Pentru firme, mesajul este destul de clar: nu mai putem trata AI-ul ca pe o jucărie fără reguli. Dacă o companie folosește AI în procese, produse, decizii, automatizări sau interacțiuni cu utilizatorii, trebuie să înțeleagă unde îl folosește, ce date procesează, cine verifică rezultatele și cine răspunde pentru efecte.
Asta nu înseamnă că fiecare firmă mică trebuie să devină peste noapte departament juridic cu servere în subsol. Dar înseamnă că trebuie să existe un minim de bun-simț și control.
Cu alte cuvinte: józan paraszti ész. Bun-simț practic.
Dacă AI-ul atinge date personale, trebuie tratat serios. Dacă AI-ul generează decizii sau recomandări care afectează oameni, trebuie verificat. Dacă AI-ul este integrat într-un produs software, trebuie securizat. Dacă AI-ul scrie conținut public, trebuie verificat pentru acuratețe, ton, promisiuni și surse. Dacă AI-ul este folosit de angajați, echipa trebuie să știe ce are voie și ce nu are voie să facă.
AI literacy nu înseamnă doar să știi să scrii un prompt frumos
AI literacy înseamnă să înțelegi limitele AI-ului, riscurile, datele pe care le introduci, rezultatele pe care trebuie să le verifici și situațiile în care AI-ul nu ar trebui folosit fără control uman.
Într-o firmă, asta poate însemna reguli simple, dar importante:
- ce date nu introducem niciodată într-un tool AI;
- ce rezultate trebuie verificate înainte de publicare;
- ce tooluri sunt aprobate pentru echipă;
- cine răspunde pentru automatizările AI;
- unde este permis AI-ul și unde este nevoie de verificare umană;
- cum tratăm informațiile personale, comerciale sau confidențiale;
- ce facem când AI-ul greșește.
Nu este nevoie ca fiecare angajat să devină expert în machine learning. Dar este nevoie să înțeleagă că AI-ul nu este un spațiu fără reguli.
Ce înseamnă folosirea responsabilă a AI-ului într-o firmă
Folosirea responsabilă a AI-ului nu înseamnă să încetinim inovația. Înseamnă să nu confundăm viteza cu progresul.
O firmă care vrea să folosească AI corect ar trebui să înceapă cu întrebări simple:
- Ce problemă concretă vrem să rezolvăm?
- Putem măsura rezultatul?
- Ce date folosim?
- Sunt date personale sau sensibile?
- Cine verifică rezultatul AI?
- Ce se întâmplă dacă AI-ul greșește?
- Unde se oprește automatizarea și unde intervine omul?
- Ce costuri poate genera sistemul?
- Cum prevenim abuzul?
- Cine este responsabil pentru mentenanță?
Aceste întrebări par simple. Tocmai de aceea sunt ignorate atât de des.
Într-un proiect software cu AI, trebuie gândite limitări de consum, autentificare, protecție împotriva abuzului, loguri, monitorizare, mesaje de eroare, fallback-uri, testare și proceduri clare pentru situațiile în care ceva merge prost.
Într-un proiect de marketing cu AI, trebuie verificate promisiunile, sursele, legalitatea afirmațiilor, modul în care sunt colectate datele și impactul asupra imaginii clientului.
Într-un proiect de e-commerce, trebuie verificat dacă AI-ul nu inventează beneficii de produs, nu creează descrieri înșelătoare, nu generează afirmații medicale sau tehnice nevalidate și nu afectează conformitatea legală.
Checklist minim înainte să pui un proiect AI în producție
Înainte ca un proiect AI să fie conectat la date reale, clienți reali sau procese reale de business, ar trebui verificate cel puțin următoarele lucruri:
- Există autentificare și control de acces?
- Există limitări de consum pentru API-uri și tokenuri?
- Există loguri și monitorizare?
- Există alerte pentru comportamente suspecte?
- Datele personale sunt salvate corect și protejate?
- Cheile API și configurațiile sensibile sunt ținute în backend sau în variabile de mediu?
- Au fost testate cazurile greșite, nu doar scenariul ideal?
- Există fallback dacă AI-ul răspunde greșit sau nu răspunde?
- Este clar ce face AI-ul și ce verifică omul?
- Există o persoană responsabilă pentru verificare și mentenanță?
Acest checklist nu rezolvă toate problemele, dar este un început sănătos. Și, sincer, este deja mai mult decât vedem în unele proiecte livrate cu multă încredere și puțină verificare.
Ce ar trebui să facă firmele înainte să implementeze AI
Nu toate firmele au nevoie de proiecte AI complexe. De multe ori, primul pas este mult mai simplu: să înțeleagă unde AI-ul poate aduce valoare fără să creeze riscuri inutile.
Un început sănătos poate arăta așa:
- identificarea proceselor repetitive;
- stabilirea zonelor în care AI-ul poate ajuta fără acces la date sensibile;
- definirea regulilor interne de utilizare;
- instruirea echipei;
- testarea pe procese mici;
- măsurarea timpului economisit;
- verificarea calității rezultatelor;
- extinderea treptată doar acolo unde există rezultate reale.
O politică internă minimă de AI poate fi foarte utilă chiar și pentru o firmă mică. Nu trebuie să fie un document complicat. Trebuie doar să clarifice lucrurile esențiale:
- ce tooluri pot fi folosite;
- ce date nu se introduc niciodată în AI;
- ce tipuri de rezultate trebuie verificate de om;
- cine aprobă conținutul public;
- cine răspunde pentru automatizări;
- ce se întâmplă în caz de eroare;
- cum se documentează procesele importante.
Este mai puțin spectaculos decât să spui că firma ta este „AI-powered”, dar este infinit mai util.
Cum vedem noi AI-ul la Dalbe
Pentru noi, AI-ul nu este magie. Este un instrument. Un instrument foarte puternic, dar tot instrument rămâne.
Ca echipă care dezvoltă website-uri, magazine online, aplicații mobile și automatizări, vedem AI-ul dintr-o zonă foarte practică: nu ca prezentare, ci ca sistem care trebuie să funcționeze pentru clienți reali.
Îl folosim acolo unde ajută: în structurarea ideilor, în analiză, în generarea de variante, în documentație, în debugging, în SEO, în texte, în planificare, în automatizări și în reducerea muncii repetitive.
Dar nu îl folosim ca scuză pentru lipsa de gândire. Nu punem cod în producție doar pentru că „a fost generat de AI”. Nu conectăm formulare fără să verificăm unde ajung datele. Nu tratăm securitatea ca pe un detaliu. Nu considerăm că un landing page este gata doar pentru că arată bine. Nu promitem clientului că totul se face în câteva minute doar pentru că un demo arată frumos.
Din proiectele pe care le dezvoltăm și mentenăm, vedem tot mai des aceeași diferență: AI-ul poate produce rapid o variantă inițială, dar calitatea finală depinde de oamenii care verifică arhitectura, securitatea, datele și scenariile reale de utilizare.
AI-ul poate accelera munca unei echipe bune. Dar poate amplifica greșelile unei echipe nepregătite.
De aceea, credem că următorii ani nu vor fi doar despre cine folosește AI. Vor fi despre cine îl folosește responsabil, măsurabil și cu suficientă competență încât rezultatul să nu devină un risc pentru client.
Concluzie
AI-ul nu este problema. Implementarea fără responsabilitate este.
Nu este greșit să folosești AI pentru cod, marketing, automatizări sau conținut. Greșit este să livrezi rezultate neverificate, să expui date, să ignori securitatea, să nu înțelegi ce ai generat și să vinzi clientului impresia că un sistem real se face în câteva minute.
În business, viteza este importantă. Dar încrederea este mai importantă.
Un software trebuie să funcționeze, dar trebuie să fie și sigur. Un landing page trebuie să arate bine, dar trebuie să trateze corect datele. O automatizare trebuie să economisească timp, dar trebuie să fie controlabilă. Un sistem AI trebuie să ajute oamenii, nu să creeze probleme pe care nimeni nu știe să le repare.
Dacă ai o automatizare, un landing page, o aplicație sau un flux AI pe care vrei să îl folosești în business, merită verificat înainte să fie conectat la date reale sau la clienți reali. Uneori o verificare tehnică simplă poate preveni probleme mult mai scumpe.
AI-ul este util atunci când este folosit cu cap. Cu proces. Cu verificare. Cu testare. Cu responsabilitate. Și, poate cel mai important, cu bun-simț.
Pentru că în final, tehnologia se schimbă. Toolurile se schimbă. Modelele AI se schimbă.
Tehnologia se schimbă. Toolurile se schimbă. Modelele AI se schimbă. Dar bunul-simț practic rămâne obligatoriu.
