IA agentică și dezvoltarea bazelor de date: ce se schimbă când IA poate executa efectiv interogări

În ultimii ani, dezvoltarea bazelor de date asistată de IA a urmat un model destul de comod. Un dezvoltator descrie o cerință. IA generează cod SQL. Dezvoltatorul îl citește, modifică ce pare în neregulă și decide dacă să îl ruleze.

Acest flux de lucru a păstrat intactă o limită importantă: IA poate sugera o acțiune, dar tot un om decide dacă aceasta ajunge în baza de date.

Totuși, odată cu IA agentică, această limită începe să dispară. În prezent, sistemele de IA pot inspecta scheme, rula interogări, interpreta rezultatele și decide ce acțiune să întreprindă în continuare. Potrivit unui sondaj recent, 62% dintre organizații experimentează deja cu agenți IA, în timp ce 23% au declarat că extind utilizarea unui sistem agentic în cadrul companiei.

Prin urmare, echipele care gestionează baze de date au de răspuns la o întrebare de arhitectură destul de urgentă. Nu dacă IA poate executa SQL. Poate. Întrebarea reală este ce se schimbă atunci când un asistent nu se mai limitează la a sugera cod, ci începe să acționeze asupra bazei de date, precum și cât de strict ar trebui controlată această autonomie.

De la sugestii la acțiuni

O decizie simplă privind indexarea arată de ce contează această schimbare.

Un agent observă o interogare lentă, consultă schema, își dă seama că un index ar putea ajuta, îl creează, rulează din nou sarcina de lucru și verifică rezultatul.

Ar putea executa o comandă la fel de obișnuită precum:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Această instrucțiune nu are nimic neobișnuit. Un asistent IA ar fi putut sugera exact același lucru. Diferența constă în cine ia decizia finală.

În cazul unui asistent, dezvoltatorul analizează recomandarea, o testează și decide dacă să o ruleze. IA oferă recomandări, dar omul acționează. În cazul unui agent cu drepturi de execuție, sistemul poate lua singur decizia și poate continua fără să aștepte aprobarea.

Dacă decizia este corectă, fluxul de lucru devine mai rapid. Însă agenții nu au întotdeauna imaginea completă. Este posibil să le scape dependențele aplicației, regulile de business, tiparele sarcinilor de lucru, ferestrele de mentenanță sau alte detalii evidente pentru persoanele care gestionează sistemul.

Așadar, un agent poate lua o decizie care pare rezonabilă din punct de vedere tehnic și totuși să fie greșită pentru mediul în care acționează, având în vedere constrângerile și cerințele specifice ale acestuia.

Pericolul crește pe măsură ce acțiunile încep să se înlănțuie. O interogare greșită SELECT poate doar să ruleze lent. O comandă greșită UPDATE poate bloca un tabel mare întreg sau poate afecta mult mai multe rânduri decât s-a intenționat. Un index folosit pentru o singură interogare poate fi inutil și, totuși, poate adăuga o sarcină suplimentară altor interogări. O modificare a schemei poate defecta ceva despre care agentul nu știa că depinde de ea, deoarece este posibil ca agentul să nu aibă contextul operațional complet și să nu poată testa toate cazurile de utilizare posibile.

Așadar, problema nu este că agenții nu pot lua decizii bune privind bazele de date. Adesea, pot. Problema este că, odată ce li se permite să acționeze în baza acestor decizii, echipele trebuie să definească mult mai clar cât de departe se extinde această autoritate, ce context poate vedea agentul, când este necesară intervenția unui om și cine rămâne responsabil pentru rezultat.

Gartner estimează că peste 40% dintre proiectele de IA agentică vor fi anulate până la sfârșitul anului 2027, parțial din cauza controalelor de risc insuficiente. Pentru echipele care gestionează baze de date, lecția este destul de simplă: drepturile de execuție ar trebui acordate după implementarea controalelor, nu înainte.

Ce se poate delega în siguranță?

Unele sarcini legate de bazele de date pot fi încredințate mult mai în siguranță decât altele.

Analiza interogărilor este un bun exemplu. Un agent poate inspecta statisticile interogărilor, extrage planurile de execuție, verifica indexurile și structurile tabelelor și sugera remedieri probabile, fără să modifice datele din mediul de producție.

Ar putea observa o interogare care scanează în mod repetat un tabel mare Orders de acest fel:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

Apoi, poate explica scanarea, sugera un index și genera instrucțiunea DDL. Nu are nevoie de permisiunea de a rula CREATE INDEX pentru a fi util.

Același lucru este valabil și pentru sarcini precum:

• Descrierea planurilor de execuție;
• Identificarea indexurilor lipsă sau inutile;
• Semnalarea SELECT * interogărilor sau a predicatelor nesargabile;
• Analizarea împingerii condițiilor de îmbinare și filtrare;
• Analizarea dependențelor și a schemelor;
• Depanarea erorilor SQL;
• Optimizarea scripturilor SQL.

Împărțirea practică este simplă: oferă-i agentului acces suficient pentru a înțelege problema, dar nu neapărat și accesul necesar pentru a modifica baza de date. Vizibilitatea extinsă poate fi utilă, însă acordarea unor drepturi extinse de execuție este o decizie diferită.

Unde contează în continuare controlul uman

Unele decizii privind bazele de date necesită în continuare intervenția unui om. Să presupunem că un agent găsește un tabel AuditLog cu sute de milioane de rânduri și decide că ar trebui șterse înregistrările vechi:

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

Codul SQL poate fi perfect valid și, totuși, decizia poate fi dezastruoasă.

Poate că reglementările impun păstrarea datelor timp de șapte ani. Poate că o aplicație depinde de aceste înregistrări. Poate că ștergerea ar trebui să se facă în loturi, pentru a evita creșterea volumului jurnalului de tranzacții. Poate că înregistrările trebuie arhivate înainte de eliminare.

Niciuna dintre aceste cerințe nu trebuie neapărat să fie prevăzută în schemă.

Aceasta este una dintre limitele abordării muncii cu baze de date ca pe o problemă de generare a codului. Bazele de date conțin structuri tehnice, însă deciziile legate de acestea sunt adesea decizii de afaceri exprimate prin operațiuni tehnice. Aceeași prudență ar trebui să se aplice și unor operațiuni precum:

• DROP și distructive ALTER instrucțiuni;
• de producție UPDATE și DELETE operațiuni;
• migrări de date de mari dimensiuni;
• modificări ale rolurilor și permisiunilor;
• modificări ale constrângerilor;
• modificări care afectează replicarea sau disponibilitatea;
• implementarea procedurilor stocate care conțin logică de afaceri.

O acțiune corectă din punct de vedere tehnic nu este neapărat și potrivită. Prin urmare, aprobarea umană nu ar trebui privită ca o limitare incomodă a IA agentice. În cazul operațiunilor cu impact major asupra bazelor de date, ea face parte din arhitectură.

Și agenții IA au nevoie de privilegiul minim

O scurtătură pe care echipele care gestionează baze de date ar trebui să o evite este să-i permită unui agent să folosească acreditările existente ale unui dezvoltator. Este simplu, dar îi oferă agentului toate drepturile de acces pe care le are deja dezvoltatorul.

Abordarea mai sigură este aceeași ca în cazul utilizatorilor și serviciilor: privilegiul minim. Microsoft recomandă acordarea doar a permisiunilor necesare pentru sarcina respectivă și monitorizarea activităților privilegiate.

De exemplu, un agent de analiză a performanței ar putea avea nevoie de:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Probabil că nu are nevoie de:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Agenții pot avea și identități diferite. Un agent de raportare ar putea primi SELECT acces la câteva scheme. Un agent de migrare ar putea lucra numai în mediul de dezvoltare sau de testare. Un agent de producție ar putea primi permisiuni strict delimitate și tot ar avea nevoie de aprobare înainte de a putea executa operațiuni.

OWASP recomandă aceeași abordare de bază pentru agenții IA: separarea accesului de citire de cel de scriere, limitarea instrumentelor și resurselor și solicitarea unei autorizări explicite pentru acțiunile sensibile.

Regula este simplă: acordați agentului permisiunile de care are nevoie pentru sarcina sa, nu permisiunile persoanei care l-a lansat.

Integrați intervenția umană în fluxul de lucru

Un model mai bun pentru lucrul cu baze de date prin IA agentică este un flux de lucru controlat:

Observare → Analiză → Propunere → Revizuire → Executare → Validare → Înregistrare

Să presupunem că un agent investighează un punct final API lent. Acesta găsește interogarea SQL din spatele lui, verifică planul de execuție și statisticile tabelelor, identifică un index probabil lipsă și pregătește un script de migrare.

Scriptul poate fi rulat mai întâi în mediul de testare. Agentul execută din nou volumul de lucru, verifică rezultatul și pregătește modificarea pentru mediul de producție.

Apoi se oprește.

Un dezvoltator sau un administrator de baze de date revizuiește migrarea, verifică dependențele și impactul asupra afacerii și o aprobă înainte ca orice să ajungă în mediul de producție.

Agentul poate prelua în continuare o mare parte din munca repetitivă. Omului îi revine responsabilitatea finală pentru o modificare cu impact major.

Măsurile de control al tranzacțiilor pot adăuga un nivel suplimentar de siguranță. De exemplu, punctele de salvare din PostgreSQL permit anularea unei părți a unei tranzacții fără a pierde tot ce s-a făcut înainte. Acest lucru poate fi util pentru modificări automatizate strâns corelate, însă anularea nu înlocuiește permisiunile și aprobarea corespunzătoare.

Instrumente precum dbForge AI Assistant se integrează firesc și în acest context. Acesta poate folosi contextul schemei pentru a genera și explica interogări SQL, a depana erori, a compara DDL, a identifica indexuri ineficiente și a pregăti scripturi de optimizare, păstrând în același timp interogările SQL rezultate la vedere pentru revizuirea de către dezvoltator.

Scopul este automatizarea activităților de rutină, păstrând în mâinile oamenilor deciziile importante.

Adevăratul obiectiv este autonomia controlată

IA agentică nu înseamnă că trebuie să alegem între „IA doar face sugestii” și „IA gestionează baza de date”. Există multe opțiuni între cele două extreme.

Echipele pot începe cu sarcini cu risc mai redus, precum explicarea interogărilor SQL, revizuirea schemelor și efectuarea verificărilor doar în citire. Apoi, agenții pot prelua treptat mai multe activități în mediile de dezvoltare și de testare.

Accesul de scriere ar trebui acordat mult mai târziu și însoțit de limite clare privind numărul de rânduri afectate, tranzacțiile, anularea, monitorizarea și aprobările. Modificările complet autonome în mediul de producție ar trebui să fie rare.

Acest lucru este similar și cu recomandările Deloitte: începeți cu fluxuri de lucru cu risc mai redus și cu date necritice, mențineți implicarea oamenilor și consolidați guvernanța pe măsură ce agenții dobândesc mai multă autonomie.

Scopul nu este autonomia absolută, ci să-i oferiți agentului suficientă libertate pentru a fi de ajutor, fără a-i acorda mai mult acces decât îi este necesar.

Concluzie: Dezvoltarea bazelor de date încă necesită discernământ

Agenții AI pot prelua o mare parte din munca repetitivă din ingineria bazelor de date. Ei pot observa sarcinile de lucru, analiza interogările, corela schemele, planurile, erorile și datele despre performanță și pot acționa în funcție de ceea ce observă.

Însă, odată ce un sistem AI poate modifica starea bazei de date, problema se schimbă. Echipele au nevoie de reguli clare privind identitatea, permisiunile, limitele tranzacțiilor, aprobările, observabilitatea, revenirea la o stare anterioară și pistele de audit.

De aceea, dintre cele 88% dintre organizațiile care folosesc AI în 2025, doar 7% au declarat că AI fusese implementată la scară largă în întreaga organizație. Problema mai dificilă este să facem AI suficient de fiabilă pentru a funcționa la scară largă.

Dezvoltarea bazelor de date se îndreaptă în aceeași direcție. Cel mai util agent nu va fi cel căruia i se permite să facă cel mai mult, ci cel ale cărui atribuții sunt clar înțelese și controlate.

Întrebarea nu mai este dacă AI poate executa sarcini legate de baze de date, ci în ce sarcini ar trebui să avem încredere că o poate face și în ce condiții.