Agentische AI en databaseontwikkeling: wat verandert er wanneer AI daadwerkelijk queries kan uitvoeren

De afgelopen jaren volgde AI-ondersteunde databaseontwikkeling een vrij vertrouwd patroon. Een ontwikkelaar beschrijft wat er nodig is. De AI genereert SQL. De ontwikkelaar leest de code, past aan wat er niet goed uitziet en beslist of die wordt uitgevoerd.

Die werkwijze hield één belangrijke grens intact: AI kan een actie voorstellen, maar een mens beslist nog altijd of die de database bereikt.

Met agentische AI begint die grens echter te vervagen. AI-systemen kunnen tegenwoordig schema’s inspecteren, queries uitvoeren, de resultaten interpreteren en beslissen welke actie ze vervolgens moeten ondernemen. Volgens een recent onderzoek experimenteert 62% van de organisaties al met AI-agents, terwijl 23% aangaf ergens binnen de onderneming een agentisch systeem op te schalen.

Dat betekent dat databaseteams al snel een architectuurvraag moeten beantwoorden. Niet of AI SQL kan uitvoeren. Dat kan. De echte vraag is wat er verandert wanneer een assistent geen code meer voorstelt, maar zelf aan de slag gaat met de database, en hoe strak die autonomie moet worden ingeperkt.

Van suggesties naar acties

Een eenvoudige beslissing over indexering laat zien waarom die verschuiving ertoe doet.

Een agent merkt dat een query traag is, raadpleegt het schema, komt erachter dat een index kan helpen, maakt die aan, voert de workload opnieuw uit en controleert het resultaat.

De agent kan iets heel gewoons uitvoeren, zoals:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Aan die instructie is niets bijzonders. Een AI-assistent had precies hetzelfde kunnen voorstellen. Het verschil zit in wie de uiteindelijke beslissing neemt.

Bij een assistent beoordeelt de ontwikkelaar de aanbeveling, test die en beslist of de code wordt uitgevoerd. De AI adviseert, maar de mens handelt. Een agent met uitvoeringsrechten kan die beslissing zelf nemen en verdergaan zonder op goedkeuring te wachten.

Als die beslissing juist is, verloopt het werk sneller. Maar agents hebben niet altijd het volledige beeld. Ze kunnen afhankelijkheden van applicaties, bedrijfsregels, workloadpatronen, onderhoudsvensters of andere context missen die vanzelfsprekend is voor de mensen die het systeem beheren.

Een agent kan dus een beslissing nemen die er technisch gezien redelijk uitziet, maar toch verkeerd uitpakt voor de omgeving waarin de agent werkt, met de specifieke beperkingen en vereisten daarvan.

Het gevaar neemt toe wanneer acties op elkaar beginnen voort te bouwen. Een slechte SELECT kan gewoon langzaam draaien. Een slechte UPDATE kan een hele grote tabel vergrendelen of veel meer rijen beïnvloeden dan de bedoeling was. Een index die voor één query wordt gebruikt, is misschien overbodig, maar zorgt wel voor extra belasting bij andere queries. Een schemawijziging kan iets kapotmaken waarvan de agent niet wist dat het ervan afhankelijk was, omdat de agent mogelijk niet over de volledige operationele context beschikt en niet elk mogelijk gebruiksscenario kan testen.

Het probleem is dus niet dat agents geen goede beslissingen over databases kunnen nemen. Dat kunnen ze vaak wel. Het probleem is dat teams, zodra agents die beslissingen mogen uitvoeren, veel duidelijker moeten bepalen hoe ver die bevoegdheid reikt, welke context de agent kan zien, wanneer een mens nog moet ingrijpen en wie verantwoordelijk blijft voor het resultaat.

Gartner verwacht dat tegen eind 2027 meer dan 40% van de projecten met agentische AI wordt stopgezet, deels door onvoldoende risicobeheersing. Voor databaseteams is de les vrij eenvoudig: geef pas uitvoeringsrechten nadat de benodigde controles zijn ingericht, niet ervoor.

Wat kan veilig worden gedelegeerd?

Sommige databasetaken zijn veel veiliger om uit handen te geven dan andere.

Queryanalyse is een goed voorbeeld. Een agent kan querystatistieken inspecteren, uitvoeringsplannen ophalen, indexen en tabelstructuren controleren en waarschijnlijke oplossingen voorstellen zonder productiegegevens te wijzigen.

De agent kan bijvoorbeeld een query opmerken die herhaaldelijk een grote Orders tabel doorzoekt:

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

Vervolgens kan de agent uitleggen waarom die tabel wordt doorzocht, een index voorstellen en de DDL genereren. De agent hoeft geen toestemming te hebben om die uit te voeren CREATE INDEX om nuttig te zijn.

Hetzelfde geldt voor taken zoals:

• Uitvoeringsplannen beschrijven;
• Ontbrekende of overbodige indexen identificeren;
• Signaleren van SELECT * queries of niet-SARGbare predicaten;
• Join- en filter-pushdown beoordelen;
• Afhankelijkheden en schema’s controleren;
• SQL-fouten oplossen;
• SQL-scripts optimaliseren.

De praktische taakverdeling is eenvoudig: geef de agent voldoende toegang om het probleem te begrijpen, maar niet automatisch voldoende toegang om de database te wijzigen. Ruime inzage kan nuttig zijn, maar ruime uitvoeringsrechten zijn een heel andere beslissing.

Waar menselijke controle belangrijk blijft

Bij sommige beslissingen over databases moet een mens betrokken blijven. Stel dat een agent een AuditLog tabel met honderden miljoenen rijen vindt en besluit dat oude records moeten worden verwijderd:

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

De SQL kan volkomen geldig zijn en toch een bijzonder slecht idee.

Misschien schrijft regelgeving voor dat gegevens zeven jaar worden bewaard. Misschien is een applicatie afhankelijk van die gegevens. Misschien moet het verwijderen in batches gebeuren om te voorkomen dat het transactielogboek groeit. Misschien moeten gegevens worden gearchiveerd voordat ze worden verwijderd.

Geen van die vereisten hoeft noodzakelijkerwijs in het schema te staan.

Dit is een van de beperkingen van de benadering waarbij databasewerk wordt beschouwd als een codegeneratieprobleem. Databases bevatten technische structuren, maar de beslissingen daarover zijn vaak zakelijke beslissingen die worden uitgedrukt in technische handelingen. Dezelfde voorzichtigheid is geboden bij bewerkingen zoals:

• DROP en destructieve ALTER instructies;
• productie- UPDATE en DELETE bewerkingen;
• grote datamigraties;
• wijzigingen in rollen en machtigingen;
• wijzigingen in beperkingen;
• wijzigingen die van invloed zijn op replicatie of beschikbaarheid;
• implementatie van opgeslagen procedures met bedrijfslogica.

Een technisch correcte handeling is niet per se een passende handeling. Menselijke goedkeuring moet daarom niet worden gezien als een hinderlijke beperking van agentische AI. Bij databasebewerkingen met grote impact maakt die goedkeuring deel uit van de architectuur.

Ook AI-agents hebben minimale toegangsrechten nodig

Een kortere weg die databaseteams moeten vermijden, is een agent de bestaande inloggegevens van een ontwikkelaar laten gebruiken. Dat is eenvoudig, maar geeft de agent alle toegangsrechten die die ontwikkelaar al heeft.

De veiligere aanpak is dezelfde als voor gebruikers en services: minimale toegangsrechten. Microsoft adviseert alleen de machtigingen toe te kennen die voor de taak nodig zijn en activiteiten met verhoogde rechten te monitoren.

Een agent voor prestatieanalyse heeft bijvoorbeeld mogelijk het volgende nodig:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Waarschijnlijk heeft die niet het volgende nodig:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Verschillende agents kunnen ook verschillende identiteiten hebben. Een rapportageagent kan bijvoorbeeld SELECT toegang krijgen tot enkele schema’s. Een migratieagent kan alleen in ontwikkel- of stagingomgevingen werken. Een productieagent kan zeer beperkte machtigingen krijgen en moet nog steeds goedkeuring hebben voordat die bewerkingen mag uitvoeren.

OWASP adviseert dezelfde basisaanpak voor AI-agents: scheid lees- en schrijftoegang, beperk de beschikbare tools en bronnen en vereis expliciete toestemming voor gevoelige handelingen.

De regel is eenvoudig: geef de agent de machtigingen die nodig zijn voor zijn taak, niet de machtigingen van degene die hem heeft gestart.

Bouw de mens in de workflow in

Een betere aanpak voor agentisch databasewerk is een gecontroleerde workflow:

Observeren → Analyseren → Voorstellen → Beoordelen → Uitvoeren → Valideren → Vastleggen

Stel dat een agent een trage API-eindpunt onderzoekt. De agent vindt de SQL-query erachter, controleert het uitvoeringsplan en de tabelstatistieken, ontdekt een waarschijnlijk ontbrekende index en stelt een migratiescript op.

Dat script kan eerst in staging worden uitgevoerd. De agent voert de werklast opnieuw uit, controleert het resultaat en bereidt de wijziging voor productie voor.

Daarna stopt de agent.

Een ontwikkelaar of DBA beoordeelt de migratie, controleert de afhankelijkheden en de gevolgen voor de bedrijfsvoering en keurt de wijziging goed voordat er iets in productie wordt doorgevoerd.

De agent kan nog steeds een groot deel van het repetitieve werk uitvoeren. De uiteindelijke verantwoordelijkheid voor een wijziging met grote impact blijft bij de mens.

Transactiebeheer kan een extra veiligheidslaag bieden. Savepoints in PostgreSQL maken het bijvoorbeeld mogelijk een deel van een transactie terug te draaien zonder alles wat eraan voorafging ongedaan te maken. Dat kan helpen bij nauw afgebakende geautomatiseerde wijzigingen, al zijn terugdraaiacties geen vervanging voor de juiste machtigingen en goedkeuring.

Ook tools zoals dbForge AI Assistant passen hier goed bij. De tool kan de context van het schema gebruiken om SQL te genereren en uit te leggen, fouten op te sporen, DDL te vergelijken, inefficiënte indexen te signaleren en optimalisatiescripts voor te bereiden, terwijl de gegenereerde SQL zichtbaar blijft voor beoordeling door een ontwikkelaar.

Het doel is het routinewerk te automatiseren en belangrijke beslissingen bij mensen te laten.

Het echte doel is gecontroleerde autonomie

Agentische AI hoeft niet te betekenen dat je moet kiezen tussen ‘AI doet alleen suggesties’ en ‘AI beheert de database’. Daartussen is veel mogelijk.

Teams kunnen beginnen met taken met een lager risico, zoals SQL uitleggen, schema’s beoordelen en alleen-lezencontroles uitvoeren. Daarna kunnen agents geleidelijk meer werk in ontwikkel- en stagingomgevingen overnemen.

Schrijftoegang moet pas veel later worden verleend, met duidelijke beperkingen voor het aantal betrokken rijen, transacties, terugdraaiacties, monitoring en goedkeuringen. Volledig autonome wijzigingen in productie moeten zeldzaam zijn.

Dat sluit ook aan bij het advies van Deloitte: begin met workflows met een lager risico en niet-kritieke gegevens, houd mensen betrokken en versterk het toezicht naarmate agents meer kunnen.

Het doel is niet absolute autonomie. Het gaat erom de agent genoeg vrijheid te geven om te helpen, maar niet meer toegang dan nodig.

Conclusie: databaseontwikkeling vereist nog steeds oordeelsvermogen

AI-agenten kunnen veel repetitief werk in de database-engineering uit handen nemen. Ze kunnen workloads bekijken, query’s onderzoeken, schema’s, uitvoeringsplannen, fouten en prestatiegegevens met elkaar in verband brengen en actie ondernemen op basis van wat ze zien.

Maar zodra een AI-systeem de toestand van de database kan wijzigen, verandert het probleem. Teams hebben duidelijke regels nodig voor identiteit, toegangsrechten, transactiegrenzen, goedkeuringen, observeerbaarheid, terugdraaiacties en audittrails.

Daarom gaf slechts 7% van de 88% van de organisaties die in 2025 AI gebruikten aan dat AI volledig binnen de organisatie was opgeschaald. De moeilijkere opgave is AI betrouwbaar genoeg maken om op schaal te kunnen opereren.

Databaseontwikkeling beweegt zich in dezelfde richting. De nuttigste agent is niet degene die het meest mag doen, maar degene waarvan de bevoegdheden duidelijk zijn vastgelegd en beheerst.

De vraag is niet langer of AI databasetaken kan uitvoeren, maar welke taken we AI kunnen toevertrouwen en onder welke voorwaarden.