Agentisk KI møter databaseutvikling: Hva endrer seg når KI faktisk kan kjøre spørringer

De siste årene har KI-assistert databaseutvikling fulgt en ganske komfortabel modell. En utvikler beskriver et behov. KI-en genererer SQL. Utvikleren leser gjennom koden, endrer det som ser feil ut, og avgjør om den skal kjøres.

Denne arbeidsflyten har bevart en viktig grense: KI kan foreslå en handling, men et menneske avgjør fortsatt om den skal utføres mot databasen.

Denne grensen begynner imidlertid å viskes ut med agentisk KI. I dag kan KI-systemer undersøke skjemaer, kjøre spørringer, tolke resultatene og avgjøre hva de skal gjøre videre. Ifølge en nylig undersøkelse eksperimenterer 62 % av organisasjonene allerede med KI-agenter, mens 23 % oppga at de skalerte opp et agentisk system et sted i virksomheten.

Databaseteam må derfor ta stilling til et ganske presserende arkitekturspørsmål. Ikke om KI kan kjøre SQL. Det kan den. Det egentlige spørsmålet er hva som endrer seg når en assistent slutter å foreslå kode og begynner å handle direkte mot databasen, og hvor stramt denne autonomien bør styres.

Fra forslag til handling

En enkel beslutning om indeksering viser hvorfor denne overgangen er viktig.

En agent oppdager en treg spørring, slår opp skjemaet, finner ut at en indeks kan hjelpe, oppretter den, kjører arbeidsbelastningen på nytt og kontrollerer resultatet.

Den kan for eksempel kjøre noe så vanlig som:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Det er ikke noe uvanlig ved den setningen. En KI-assistent kunne ha foreslått akkurat det samme. Forskjellen ligger i hvem som tar den endelige avgjørelsen.

Med en assistent gjennomgår utvikleren anbefalingen, tester den og avgjør om den skal kjøres. KI-en gir råd, men mennesket handler. Med en agent som har kjørerettigheter, kan systemet ta den avgjørelsen selv og gå videre uten å vente på godkjenning.

Hvis avgjørelsen er riktig, går arbeidsflyten raskere. Men agenter har ikke alltid hele bildet. De kan overse avhengigheter i applikasjonen, forretningsregler, mønstre i arbeidsbelastningen, vedlikeholdsvinduer eller annen kontekst som er åpenbar for dem som drifter systemet.

En agent kan altså ta en beslutning som virker teknisk fornuftig, men som likevel er feil for miljøet den opererer i, med tanke på de konkrete begrensningene og kravene der.

En dårlig SELECT kan bare kjøre sakte. En dårlig UPDATE kan låse en hel, stor tabell eller påvirke langt flere rader enn tiltenkt. En indeks som brukes av én spørring, kan være unødvendig og samtidig gi ekstra belastning for andre spørringer. En endring i skjemaet kan ødelegge noe agenten ikke visste var avhengig av det, fordi agenten kanskje mangler den fulle driftskonteksten og ikke kan teste alle mulige bruksområder.

Problemet er altså ikke at agenter ikke kan ta gode beslutninger om databaser. Det kan de ofte. Problemet er at når de får lov til å handle på grunnlag av beslutningene, må teamene være mye tydeligere på hvor langt myndigheten deres rekker, hvilken kontekst agenten kan se, hvor et menneske fortsatt må gripe inn, og hvem som fortsatt står ansvarlig for resultatet.

Gartner forventer at mer enn 40 % av prosjektene innen agentisk KI vil bli avlyst innen utgangen av 2027, delvis på grunn av mangelfulle risikokontroller. For databaseteam er lærdommen ganske enkel: Kjørerettigheter bør komme etter kontrollmekanismene, ikke før dem.

Hva kan trygt delegeres?

Noen databaseoppgaver er langt tryggere å overlate til andre enn andre.

Spørringsanalyse er et godt eksempel. En agent kan undersøke statistikk for spørringer, hente kjøreplaner, kontrollere indekser og tabellstrukturer og foreslå sannsynlige løsninger uten å endre produksjonsdata.

Den kan oppdage at en spørring som denne gjentatte ganger skanner en stor Orders tabell:

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

Derfra kan den forklare skanningen, foreslå en indeks og generere DDL. Den trenger ikke tillatelse til å kjøre CREATE INDEX for å være nyttig.

Det samme gjelder oppgaver som:

• Beskrive kjøreplaner;
• Identifisere manglende eller unødvendige indekser;
• Varsle om SELECT * spørringer eller ikke-søkbare predikater;
• Gjennomgå nedskyving av sammenføyninger og filtre;
• Gjennomgå avhengigheter og skjemaer;
• Feilsøke SQL-feil;
• Optimalisere SQL-skript.

Den praktiske arbeidsdelingen er enkel: Gi agenten nok tilgang til å forstå problemet, men ikke automatisk nok tilgang til å endre databasen. Bred innsynstilgang kan være nyttig, men brede kjørerettigheter er en annen beslutning.

Der menneskelig kontroll fortsatt er viktig

Noen beslutninger om databaser krever fortsatt at et menneske er med i prosessen. Tenk deg at en agent finner en AuditLog tabell med hundrevis av millioner rader og bestemmer at gamle poster bør slettes:

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

SQL-koden kan være helt gyldig og likevel føre til en svært dårlig beslutning.

Kanskje regelverket krever at dataene oppbevares i sju år. Det kan hende en applikasjon er avhengig av disse oppføringene. Kanskje slettingen bør utføres i puljer for å unngå at transaksjonsloggen vokser. Det kan hende oppføringene må arkiveres før de fjernes.

Ingen av disse kravene trenger nødvendigvis å være definert i skjemaet.

Dette er en av begrensningene ved å behandle databasearbeid som et kodegenereringsproblem. Databaser inneholder tekniske strukturer, men beslutningene rundt dem er ofte forretningsmessige beslutninger som kommer til uttrykk gjennom tekniske operasjoner. Den samme forsiktigheten bør gjelde for operasjoner som:

• DROP og destruktive ALTER setninger;
• produksjons UPDATE og DELETE operasjoner;
• omfattende datamigreringer;
• endringer i roller og tillatelser;
• endringer i integritetsbegrensninger;
• endringer som påvirker replikering eller tilgjengelighet;
• utrulling av lagrede prosedyrer som inneholder forretningslogikk.

En teknisk korrekt handling er ikke nødvendigvis en hensiktsmessig handling. Menneskelig godkjenning bør derfor ikke ses på som en upraktisk begrensning for agentisk KI. Ved databaseoperasjoner med stor innvirkning er den en del av arkitekturen.

KI-agenter trenger også minste privilegium

En snarvei databaseteam bør unngå, er å la en agent bruke en utviklers eksisterende påloggingsinformasjon. Det er enkelt, men gir agenten all tilgangen utvikleren allerede har.

Den tryggere tilnærmingen er den samme som brukes for brukere og tjenester: minste privilegium. Microsoft anbefaler å bare tildele tillatelsene som er nødvendige for oppgaven, og å overvåke privilegert aktivitet.

En agent for ytelsesanalyse kan for eksempel trenge:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Den trenger sannsynligvis ikke:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Ulike agenter kan også ha ulike identiteter. En rapporteringsagent kan få SELECT tilgang til noen få skjemaer. En migreringsagent kan begrenses til utviklings- eller testmiljøet. En produksjonsagent kan få strengt avgrensede tillatelser og likevel måtte innhente godkjenning før den kan utføre operasjoner.

OWASP anbefaler det samme grunnleggende mønsteret for KI-agenter: Skill lese- og skrivetilgang, begrens verktøy og ressurser, og krev uttrykkelig godkjenning for sensitive handlinger.

Regelen er enkel: Gi agenten tillatelsene den trenger for å utføre jobben, ikke tillatelsene til personen som startet den.

Bygg menneskelig medvirkning inn i arbeidsflyten

En bedre modell for agentisk databasearbeid er en kontrollert arbeidsflyt:

Observer → Analyser → Foreslå → Gjennomgå → Utfør → Valider → Registrer

Tenk deg at en agent undersøker et tregt API-endepunkt. Den finner SQL-koden bak det, sjekker kjøringsplanen og tabellstatistikken, oppdager en sannsynlig manglende indeks og klargjør et migreringsskript.

Skriptet kan først kjøres i testmiljøet. Agenten kjører arbeidsbelastningen på nytt, kontrollerer resultatet og klargjør endringen for produksjon.

Deretter stopper den.

En utvikler eller databaseadministrator gjennomgår migreringen, kontrollerer avhengigheter og konsekvenser for virksomheten og godkjenner den før noe settes i produksjon.

Agenten kan fortsatt håndtere mye av det repetitive arbeidet. Det mennesket fortsatt har ansvar for, er den endelige beslutningen om endringer med stor innvirkning.

Transaksjonskontroller kan gi et ekstra lag med sikkerhet. Lagrede punkter i PostgreSQL-transaksjoner kan for eksempel brukes til å rulle tilbake deler av en transaksjon uten å forkaste alt som skjedde før dette punktet. Det kan være nyttig ved tett sammenknyttede automatiserte endringer, men tilbakerulling er ingen erstatning for riktige tillatelser og godkjenning.

Det er også her verktøy som dbForge AI Assistant passer godt inn. Verktøyet kan bruke kontekst fra databaseskjemaet til å generere og forklare SQL, feilsøke problemer, sammenligne DDL, oppdage ineffektive indekser og klargjøre optimaliseringsskript, samtidig som SQL-koden det genererer, forblir synlig for utviklerens gjennomgang.

Målet er å automatisere rutinearbeidet, samtidig som viktige beslutninger forblir menneskelige.

Det virkelige målet er kontrollert autonomi

Agentisk KI trenger ikke å bety at man må velge mellom «KI foreslår bare» og «KI kjører databasen». Det finnes mange muligheter mellom disse ytterpunktene.

Team kan begynne med oppgaver med lavere risiko, som å forklare SQL, gjennomgå skjemaer og utføre skrivebeskyttede kontroller. Derfra kan agentene gradvis overta flere oppgaver i utviklings- og testmiljøer.

Skrivetilgang bør komme mye senere, og være underlagt tydelige begrensninger for berørte rader, transaksjoner, tilbakerulling, overvåking og godkjenninger. Helautonome endringer i produksjon bør være sjeldne.

Dette ligner også på anbefalingene fra Deloitte: Begynn med arbeidsflyter med lavere risiko og ikke-kritiske data, hold folk involvert, og styrk styringen etter hvert som agentene får mer.

Målet er ikke fullstendig autonomi. Det handler om å gi agenten nok frihet til å være til hjelp, men ikke mer tilgang enn den trenger.

Hovedpoeng: Databaseutvikling krever fortsatt skjønn

KI-agenter kan ta seg av mye av det repetitive arbeidet innen databaseutvikling. De kan se arbeidsbelastninger, undersøke spørringer, sammenholde skjemaer, planer, feil og ytelsesdata og handle ut fra det de observerer.

Men når et KI-system først kan endre databasens tilstand, endrer problemstillingen seg. Teamene trenger tydelige regler for identitet, tillatelser, transaksjonsgrenser, godkjenninger, observerbarhet, tilbakerulling og revisjonsspor.

Derfor var det av de 88 % av organisasjonene som brukte KI i 2025, bare 7 % som sa at KI var fullt utrullet i hele organisasjonen. Den vanskeligere utfordringen er å gjøre KI pålitelig nok til å kunne brukes i stor skala.

Databaseutviklingen går i samme retning. Den mest nyttige agenten er ikke den som får gjøre mest, men den hvis myndighet er tydelig definert og kontrollert.

Spørsmålet er ikke lenger om KI kan utføre databaseoppgaver, men hvilke oppgaver vi bør stole på at den utfører, og under hvilke begrensninger.