L’IA agentica incontra lo sviluppo dei database: cosa cambia quando l’IA può eseguire davvero le query

Negli ultimi anni, lo sviluppo di database assistito dall’IA ha seguito un modello piuttosto rassicurante. Uno sviluppatore descrive un requisito. L’IA genera il codice SQL. Lo sviluppatore lo legge, corregge ciò che non va e decide se eseguirlo.

Questo flusso di lavoro ha mantenuto intatto un confine importante: l’IA può suggerire un’azione, ma spetta ancora a una persona decidere se eseguirla sul database.

Con l’IA agentica, però, questo confine sta iniziando a scomparire. Oggi i sistemi di IA possono esaminare gli schemi, eseguire query, interpretare i risultati e decidere quale azione intraprendere. Secondo un recente sondaggio, il 62% delle organizzazioni sta già sperimentando agenti di IA, mentre il 23% ha dichiarato di aver esteso l’uso di un sistema agentico in qualche ambito dell’azienda.

I team che si occupano di database devono quindi rispondere a una questione architetturale piuttosto urgente. Non si tratta di chiedersi se l’IA sia in grado di eseguire codice SQL. Ne è capace. La vera domanda è cosa cambia quando un assistente smette di suggerire codice e inizia ad agire sul database, e quanto strettamente debba essere controllata la sua autonomia.

Dai suggerimenti alle azioni

Una semplice decisione sull’indicizzazione mostra perché questo cambiamento è importante.

Un agente rileva una query lenta, consulta lo schema, capisce che un indice potrebbe essere utile, lo crea, esegue di nuovo il carico di lavoro e verifica il risultato.

Potrebbe eseguire un’istruzione del tutto ordinaria, come:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Questa istruzione non ha nulla di insolito. Un assistente IA avrebbe potuto suggerire esattamente la stessa cosa. La differenza sta in chi prende la decisione finale.

Con un assistente, lo sviluppatore esamina il suggerimento, lo verifica e decide se eseguirlo. L’IA consiglia, ma è la persona ad agire. Se invece l’agente dispone dei permessi di esecuzione, il sistema può prendere quella decisione autonomamente e procedere senza attendere l’approvazione.

Se la decisione è giusta, il flusso di lavoro diventa più rapido. Ma gli agenti non hanno sempre il quadro completo. Possono non considerare le dipendenze dell’applicazione, le regole aziendali, gli andamenti dei carichi di lavoro, le finestre di manutenzione o altri aspetti del contesto che sono evidenti a chi gestisce il sistema.

Di conseguenza, un agente può prendere una decisione che sembra tecnicamente ragionevole e che, date le specifiche limitazioni e i requisiti dell’ambiente in cui opera, si rivela comunque sbagliata.

Il pericolo aumenta quando le azioni iniziano a concatenarsi. Una query sbagliata SELECT può semplicemente essere lenta. Una query sbagliata UPDATE può bloccare un’intera tabella di grandi dimensioni o interessare molte più righe del previsto. Un indice utile per una query potrebbe essere superfluo e aggiungere invece un sovraccarico alle altre. Una modifica allo schema può compromettere qualcosa da cui l’agente non sapeva che dipendesse, perché potrebbe non disporre del contesto operativo completo e non essere in grado di testare tutti i possibili casi d’uso.

Il problema, quindi, non è che gli agenti non sappiano prendere buone decisioni sui database. Spesso ne sono capaci. Il problema è che, una volta autorizzati ad agire in base a queste decisioni, i team devono definire con molta più chiarezza fin dove si estende la loro autorità, quale contesto è visibile all’agente, quando è ancora necessario l’intervento di una persona e chi resta responsabile del risultato.

Gartner prevede che oltre il 40% dei progetti di IA agentica verrà cancellato entro la fine del 2027, in parte a causa di controlli sui rischi inadeguati. Per i team che si occupano di database, la lezione è piuttosto semplice: i permessi di esecuzione devono arrivare dopo l’introduzione dei controlli, non prima.

Quali attività si possono delegare in sicurezza?

Alcune attività sui database si possono affidare molto più facilmente di altre.

L’analisi delle query è un buon esempio. Un agente può esaminare le statistiche delle query, recuperare i piani di esecuzione, controllare gli indici e la struttura delle tabelle e suggerire possibili correzioni senza modificare i dati in produzione.

Potrebbe individuare una query che esegue ripetutamente una scansione su una grande Orders tabella:

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

A quel punto, può spiegare la scansione, suggerire un indice e generare il DDL. Non ha bisogno del permesso di eseguire CREATE INDEX per essere utile.

Lo stesso vale per attività come:

• Descrivere i piani di esecuzione;
• Individuare indici mancanti o superflui;
• Segnalare SELECT * query o predicati non sargabili;
• Esaminare il pushdown di join e filtri;
• Esaminare dipendenze e schemi;
• Risolvere gli errori SQL;
• Ottimizzare gli script SQL.

La distinzione pratica è semplice: dare all’agente accesso sufficiente per comprendere il problema, ma non automaticamente anche quello necessario per modificare il database. Un’ampia visibilità può essere utile, ma concedere ampi permessi di esecuzione è una decisione diversa.

Dove il controllo umano resta importante

Alcune decisioni sui database richiedono ancora l’intervento di una persona. Supponiamo che un agente trovi una AuditLog tabella con centinaia di milioni di righe e decida che i record meno recenti vadano eliminati:

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

Il codice SQL può essere perfettamente valido e rappresentare comunque una pessima decisione.

Forse la normativa impone di conservare i dati per sette anni. Può darsi che un’applicazione dipenda da quei record. Forse la cancellazione dovrebbe avvenire in batch per evitare che il log delle transazioni cresca troppo. Può darsi che i record debbano essere archiviati prima della rimozione.

Nessuno di questi requisiti deve necessariamente essere presente nello schema.

Questo è uno dei limiti del considerare il lavoro sui database come un problema di generazione del codice. I database contengono strutture tecniche, ma le decisioni che le riguardano sono spesso decisioni aziendali espresse attraverso operazioni tecniche. La stessa cautela dovrebbe applicarsi a operazioni come:

• DROP e distruttive ALTER istruzioni;
• di produzione UPDATE e DELETE operazioni;
• migrazioni di dati di grandi dimensioni;
• modifiche a ruoli e autorizzazioni;
• modifiche ai vincoli;
• modifiche che incidono sulla replica o sulla disponibilità;
• distribuzione di procedure memorizzate contenenti logica aziendale.

Un’azione tecnicamente corretta non è necessariamente appropriata. L’approvazione umana, quindi, non dovrebbe essere considerata un limite scomodo dell’IA agentica. Per le operazioni sui database ad alto impatto, è parte integrante dell’architettura.

Anche gli agenti IA devono rispettare il principio del privilegio minimo

Una scorciatoia che i team che gestiscono database dovrebbero evitare è consentire a un agente di usare le credenziali già in uso a uno sviluppatore. È facile, ma così l’agente ottiene tutti i privilegi di cui dispone già quello sviluppatore.

L’approccio più sicuro è lo stesso adottato per utenti e servizi: il principio del privilegio minimo. Microsoft raccomanda di concedere solo le autorizzazioni necessarie per svolgere il compito e di monitorare le attività privilegiate.

Per esempio, un agente di analisi delle prestazioni potrebbe aver bisogno di:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Probabilmente non ha bisogno di:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Anche agenti diversi possono avere identità diverse. Un agente per la creazione di report potrebbe ottenere SELECT accesso a pochi schemi. Un agente per le migrazioni potrebbe operare solo negli ambienti di sviluppo o di staging. Un agente di produzione potrebbe ricevere autorizzazioni strettamente circoscritte e richiedere comunque un’approvazione prima di poter eseguire le operazioni.

OWASP raccomanda lo stesso principio di base per gli agenti IA: separare gli accessi in lettura e in scrittura, limitare strumenti e risorse e richiedere un’autorizzazione esplicita per le azioni sensibili.

La regola è semplice: concedere all’agente le autorizzazioni necessarie per il suo compito, non quelle della persona che lo ha avviato.

Integrare l’intervento umano nel flusso di lavoro

Un modello migliore per il lavoro agentico sui database è un flusso di lavoro controllato:

Osservare → Analizzare → Proporre → Esaminare → Eseguire → Convalidare → Registrare

Supponiamo che un agente stia esaminando un endpoint API lento. Individua l’SQL alla base, controlla il piano di esecuzione e le statistiche delle tabelle, rileva un probabile indice mancante e prepara uno script di migrazione.

Lo script può essere eseguito prima nell’ambiente di staging. L’agente esegue nuovamente il carico di lavoro, verifica il risultato e prepara la modifica per la produzione.

Poi si ferma.

Uno sviluppatore o un DBA esamina la migrazione, verifica le dipendenze e l’impatto aziendale e la approva prima che qualsiasi modifica raggiunga la produzione.

L’agente può comunque occuparsi di gran parte del lavoro ripetitivo. Ciò che resta in capo alla persona è la responsabilità finale per una modifica ad alto impatto.

I controlli sulle transazioni possono aggiungere un ulteriore livello di sicurezza. Per esempio, i savepoint di PostgreSQL consentono di annullare una parte di una transazione senza scartare tutto ciò che è avvenuto prima. Questo può essere utile per modifiche automatizzate strettamente correlate, anche se il rollback non sostituisce autorizzazioni e approvazioni adeguate.

È anche in questo contesto che strumenti come dbForge AI Assistant si inseriscono naturalmente. Può usare il contesto dello schema per generare e spiegare query SQL, risolvere errori, confrontare DDL, individuare indici inefficienti e preparare script di ottimizzazione, mantenendo visibile l’SQL risultante affinché lo sviluppatore possa esaminarlo.

L’obiettivo è automatizzare le attività di routine, lasciando alle persone le decisioni importanti.

Il vero obiettivo è un’autonomia controllata

IA agentica non significa necessariamente dover scegliere tra «l’IA si limita a dare suggerimenti» e «l’IA gestisce il database». C’è molto spazio tra queste due opzioni.

I team possono iniziare con attività a basso rischio, come spiegare l’SQL, esaminare gli schemi ed eseguire controlli in sola lettura. Da lì, gli agenti possono assumersi gradualmente più compiti negli ambienti di sviluppo e di staging.

L’accesso in scrittura dovrebbe arrivare molto più tardi, con limiti chiari riguardo alle righe interessate, alle transazioni, al rollback, al monitoraggio e alle approvazioni. Le modifiche completamente autonome in produzione dovrebbero essere rare.

Questo approccio è simile anche alle raccomandazioni di Deloitte: iniziare con flussi di lavoro a basso rischio e dati non critici, mantenere le persone coinvolte e rafforzare la governance man mano che gli agenti acquisiscono maggiori capacità.

L’obiettivo non è l’autonomia assoluta. Si tratta di concedere all’agente libertà sufficiente per essere d’aiuto, ma non più accesso di quanto gli serva.

In sintesi: lo sviluppo dei database richiede ancora capacità di giudizio

Gli agenti di IA possono ridurre notevolmente il lavoro ripetitivo nell’ingegneria dei database. Possono visualizzare i carichi di lavoro, esaminare le query, correlare schemi, piani, errori e dati sulle prestazioni e intervenire in base a ciò che rilevano.

Ma quando un sistema di IA può modificare lo stato del database, il problema cambia. I team hanno bisogno di regole chiare per identità, autorizzazioni, confini delle transazioni, approvazioni, osservabilità, ripristino e registri di audit.

Ecco perché, tra l’88% delle organizzazioni che nel 2025 utilizzavano l’IA, solo il 7% ha dichiarato che era stata implementata su vasta scala in tutta l’organizzazione. La sfida più difficile è rendere l’IA abbastanza affidabile da poter operare su larga scala.

Lo sviluppo dei database si sta muovendo nella stessa direzione. L’agente più utile non sarà quello a cui è consentito fare di più, ma quello la cui autorità è definita e controllata con chiarezza.

La domanda non è più se l’IA sia in grado di eseguire attività sui database, ma quali attività dovremmo affidarle e a quali vincoli dovrebbe sottostare.