Agentisk AI møder databaseudvikling: Hvad ændrer sig, når AI faktisk kan udføre forespørgsler

I de seneste par år har AI-understøttet databaseudvikling fulgt en forholdsvis tryg model. En udvikler beskriver et behov. AI’en genererer SQL. Udvikleren læser koden, retter det, der ser forkert ud, og beslutter, om den skal køres.

Denne arbejdsgang har bevaret en vigtig grænse: AI kan foreslå en handling, men det er stadig et menneske, der beslutter, om den skal udføres på databasen.

Denne grænse er dog ved at forsvinde med agentisk AI. I dag kan AI-systemer undersøge skemaer, køre forespørgsler, fortolke resultaterne og beslutte, hvad de skal gøre som det næste. Ifølge en nyere undersøgelse eksperimenterer 62 % af organisationerne allerede med AI-agenter, mens 23 % oplyste, at de er ved at skalere et agentisk system et sted i virksomheden.

Databaseteams står derfor over for et ret presserende arkitektonisk spørgsmål. Ikke om AI kan udføre SQL. Det kan den. Det egentlige spørgsmål er, hvad der ændrer sig, når en assistent holder op med blot at foreslå kode og begynder at handle på databasen, og hvor stramt denne autonomi bør styres.

Fra forslag til handling

En enkel beslutning om indeksering viser, hvorfor denne ændring er vigtig.

En agent opdager en langsom forespørgsel, slår skemaet op, finder ud af, at et indeks måske kan hjælpe, opretter det, kører arbejdsbelastningen igen og kontrollerer resultatet.

Den kan udføre noget så almindeligt som:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Der er ikke noget usædvanligt ved den SQL-sætning. En AI-assistent kunne have foreslået præcis det samme. Forskellen er, hvem der træffer den endelige beslutning.

Med en assistent gennemgår udvikleren anbefalingen, tester den og beslutter, om den skal køres. AI’en rådgiver, men mennesket handler. Med en agent, der har adgang til at udføre handlinger, kan systemet selv træffe beslutningen og fortsætte uden at afvente godkendelse.

Hvis beslutningen er rigtig, går arbejdsgangen hurtigere. Men agenter har ikke altid det fulde overblik. De kan overse afhængigheder i applikationer, forretningsregler, mønstre i arbejdsbelastningen, vedligeholdelsesvinduer eller anden kontekst, som er indlysende for dem, der driver systemet.

En agent kan altså træffe en beslutning, der ser teknisk velbegrundet ud, men stadig være forkert for det miljø, den handler i, med dets specifikke begrænsninger og krav.

Risikoen vokser, efterhånden som handlingerne begynder at kæde sig sammen. En dårlig SELECT kan blot køre langsomt. En dårlig UPDATE kan låse en hel stor tabel eller påvirke langt flere rækker end tilsigtet. Et indeks, der bruges til én forespørgsel, er måske unødvendigt, men øger belastningen for andre forespørgsler. En ændring af skemaet kan ødelægge noget, som agenten ikke vidste var afhængigt af det, fordi agenten kan mangle det fulde driftsmæssige overblik og ikke kan teste alle tænkelige anvendelsestilfælde.

Problemet er altså ikke, at agenter ikke kan træffe gode beslutninger om databaser. Det kan de ofte. Problemet er, at når de får lov til at handle på baggrund af beslutningerne, skal teams være langt tydeligere om, hvor langt beføjelserne rækker, hvilken kontekst agenten kan se, hvornår et menneske stadig skal gribe ind, og hvem der fortsat er ansvarlig for resultatet.

Gartner forventer, at mere end 40 % af projekter med agentisk AI vil blive aflyst inden udgangen af 2027, blandt andet på grund af utilstrækkelig risikostyring. Læren for databaseteams er ret enkel: Adgang til at udføre handlinger bør først gives, når kontrollerne er på plads – ikke før.

Hvad kan man trygt overlade til en agent?

Nogle databaseopgaver er langt tryggere at overlade til andre end andre.

Analyse af forespørgsler er et godt eksempel. En agent kan undersøge statistik om forespørgsler, hente eksekveringsplaner, kontrollere indekser og tabelstrukturer og foreslå sandsynlige løsninger uden at ændre produktionsdata.

Den kan få øje på en forespørgsel som denne, der gentagne gange gennemgår en stor Orders tabel:

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

Herfra kan den forklare gennemgangen, foreslå et indeks og generere DDL-koden. Den behøver ikke tilladelse til at køre CREATE INDEX for at være nyttig.

Det samme gælder opgaver som:

• Beskrivelse af eksekveringsplaner;
• Identifikation af manglende eller unødvendige indekser;
• Markering af SELECT * forespørgsler eller ikke-sargbare prædikater;
• Gennemgang af pushdown af joins og filtre;
• Gennemgang af afhængigheder og skemaer;
• Fejlfinding af SQL-fejl;
• Optimering af SQL-scripts.

Den praktiske opdeling er enkel: Giv agenten tilstrækkelig adgang til at forstå problemet, men ikke automatisk tilstrækkelig adgang til at ændre databasen. Bred indsigt kan være nyttig, men brede beføjelser til at udføre ændringer er en anden beslutning.

Hvor menneskelig kontrol stadig er vigtig

Nogle beslutninger om databaser kræver stadig, at et menneske er involveret. Forestil dig, at en agent finder en AuditLog tabel med hundredvis af millioner af rækker og beslutter, at gamle poster skal slettes:

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

SQL-koden kan være helt gyldig og stadig føre til en katastrofal beslutning.

Måske kræver lovgivningen, at data opbevares i syv år. Måske er en applikation afhængig af disse poster. Måske bør sletningen ske i batches for at undgå, at transaktionsloggen vokser. Måske skal poster arkiveres, før de fjernes.

Ingen af disse krav findes nødvendigvis i skemaet.

Det er en af begrænsningerne ved at behandle databasearbejde som et kodegenereringsproblem. Databaser indeholder tekniske strukturer, men beslutningerne om dem er ofte forretningsmæssige beslutninger, der kommer til udtryk gennem tekniske handlinger. Den samme forsigtighed bør gælde for handlinger som:

• DROP og destruktive ALTER sætninger;
• produktions UPDATE og DELETE handlinger;
• store datamigreringer;
• ændringer af roller og tilladelser;
• ændringer af begrænsninger;
• ændringer, der påvirker replikering eller tilgængelighed;
• udrulning af lagrede procedurer, der indeholder forretningslogik.

En teknisk korrekt handling er ikke nødvendigvis en passende handling. Menneskelig godkendelse bør derfor ikke betragtes som en uhensigtsmæssig begrænsning af agentisk AI. Ved databasehandlinger med stor indvirkning er den en del af arkitekturen.

AI-agenter har også brug for mindst mulige privilegier

En genvej, som databaseteams bør undgå, er at lade en agent bruge en udviklers eksisterende legitimationsoplysninger. Det er nemt, men giver agenten al den adgang, som udvikleren allerede har.

Den sikrere tilgang er den samme, som bruges for brugere og tjenester: mindst mulige privilegier. Microsoft anbefaler kun at tildele de tilladelser, der er nødvendige for opgaven, og at overvåge privilegerede aktiviteter.

En agent til performanceanalyse kan for eksempel have brug for:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Den har sandsynligvis ikke brug for:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Forskellige agenter kan også have forskellige identiteter. En rapporteringsagent kan få SELECT adgang til nogle få skemaer. En migreringsagent kan arbejde udelukkende i udviklings- eller stagingmiljøet. En produktionsagent kan få nøje afgrænsede tilladelser og stadig skulle have godkendelse, før den kan udføre handlinger.

OWASP anbefaler det samme grundlæggende mønster for AI-agenter: adskil læse- og skriveadgang, begræns værktøjer og ressourcer, og kræv udtrykkelig godkendelse af følsomme handlinger.

Reglen er enkel: Giv agenten de tilladelser, dens opgave kræver, ikke de tilladelser, som den person, der startede den, har.

Indbyg menneskelig involvering i arbejdsgangen

En bedre model for agentisk databasearbejde er en kontrolleret arbejdsgang:

Observer → Analysér → Foreslå → Gennemgå → Udfør → Validér → Registrér

Forestil dig, at en agent undersøger et langsomt API-slutpunkt. Den finder SQL-koden bag det, kontrollerer eksekveringsplanen og tabelstatistikkerne, opdager et sandsynligvis manglende indeks og udarbejder et migreringsscript.

Scriptet kan først køres i stagingmiljøet. Agenten kører arbejdsbelastningen igen, kontrollerer resultatet og forbereder ændringen til produktion.

Derefter stopper den.

En udvikler eller DBA gennemgår migreringen, kontrollerer afhængigheder og forretningsmæssige konsekvenser og godkender den, før noget når produktionen.

Agenten kan stadig håndtere meget af det gentagne arbejde. Det, der fortsat påhviler mennesket, er det endelige ansvar for en ændring med stor indvirkning.

Transaktionskontroller kan give et ekstra lag af sikkerhed. Savepoints i PostgreSQL gør det for eksempel muligt at rulle en del af en transaktion tilbage uden at kassere alt det, der gik forud. Det kan være nyttigt ved tæt sammenknyttede automatiserede ændringer, men tilbagerulning kan ikke erstatte korrekte tilladelser og godkendelse.

Det er også her, værktøjer som dbForge AI Assistant passer naturligt ind. Værktøjet kan bruge konteksten fra skemaet til at generere og forklare SQL, fejlfinde problemer, sammenligne DDL, finde ineffektive indekser og udarbejde optimeringsscripts, samtidig med at den resulterende SQL-kode er synlig, så udvikleren kan gennemgå den.

Målet er at automatisere rutinearbejdet, samtidig med at vigtige beslutninger forbliver menneskelige.

Det egentlige mål er kontrolleret autonomi

Agentisk AI behøver ikke at betyde, at man skal vælge mellem »AI foreslår kun« og »AI styrer databasen«. Der er mange muligheder imellem de to yderpunkter.

Teams kan begynde med opgaver med lavere risiko, såsom at forklare SQL, gennemgå skemaer og udføre skrivebeskyttede kontroller. Derefter kan agenterne gradvist påtage sig flere opgaver i udviklings- og stagingmiljøer.

Skriveadgang bør først indføres meget senere og med klare begrænsninger for berørte rækker, transaktioner, tilbagerulning, overvågning og godkendelser. Fuldt autonome ændringer i produktionen bør være sjældne.

Det ligger også tæt på Deloitte’s anbefalinger: Begynd med arbejdsgange med lavere risiko og ikke-kritiske data, hold medarbejderne involveret, og styrk governance, efterhånden som agenterne får mere.

Målet er ikke fuldstændig autonomi. Det handler om at give agenten frihed nok til at hjælpe, men ikke mere adgang, end den har brug for.

Det vigtigste: Databaseudvikling kræver stadig dømmekraft

AI-agenter kan overtage meget af det gentagne arbejde inden for databaseudvikling. De kan se arbejdsbelastninger, undersøge forespørgsler, sammenholde skemaer, planer, fejl og ydelsesdata og handle på baggrund af det, de ser.

Men når et AI-system først kan ændre databasens tilstand, ændrer problemet sig. Teams har brug for klare regler for identitet, tilladelser, transaktionsgrænser, godkendelser, observerbarhed, tilbagerulning og revisionsspor.

Det er derfor, at blandt de 88 % af organisationerne, der brugte AI i 2025, sagde kun 7 %, at AI var blevet fuldt implementeret på tværs af organisationen. Den større udfordring er at gøre AI pålidelig nok til at kunne fungere i stor skala.

Databaseudviklingen bevæger sig i samme retning. Den mest nyttige agent vil ikke være den, der får lov til at gøre mest, men den, hvis beføjelser er klart defineret og kontrolleret.

Spørgsmålet er ikke længere, om AI kan udføre databaseopgaver, men hvilke opgaver vi bør have tillid til, at den udfører, og under hvilke begrænsninger.