Agentisk AI möter databasutveckling: Vad förändras när AI faktiskt kan köra frågor

Under de senaste åren har AI-assisterad databasutveckling följt en ganska bekväm modell. En utvecklare beskriver ett behov. AI:n genererar SQL-kod. Utvecklaren läser igenom den, ändrar det som verkar fel och avgör om den ska köras.

Det arbetsflödet har bevarat en viktig gräns: AI kan föreslå en åtgärd, men det är fortfarande en människa som avgör om den ska utföras i databasen.

Den gränsen börjar dock suddas ut med agentisk AI. I dag kan AI-system granska scheman, köra frågor, tolka resultaten och avgöra vilken åtgärd de ska vidta härnäst. Enligt en färsk undersökning experimenterar 62 procent av organisationerna redan med AI-agenter, medan 23 procent uppgav att de skalar upp ett agentbaserat system någonstans i företaget.

Databasgrupper står därför inför en arkitekturfråga som de behöver besvara ganska omgående. Frågan är inte om AI kan köra SQL. Det kan den. Den verkliga frågan är vad som förändras när en assistent slutar föreslå kod och börjar agera direkt i databasen, och hur strikt den självständigheten bör styras.

Från förslag till åtgärder

Ett enkelt beslut om indexering visar varför den här förändringen spelar roll.

En agent upptäcker en långsam fråga, slår upp schemat, drar slutsatsen att ett index kan hjälpa, skapar det, kör arbetsbelastningen igen och kontrollerar resultatet.

Den kan köra något så vanligt som:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Det är inget ovanligt med den satsen. En AI-assistent hade kunnat föreslå precis samma sak. Skillnaden är vem som fattar det slutgiltiga beslutet.

Med en assistent granskar utvecklaren rekommendationen, testar den och avgör om den ska köras. AI:n ger råd, men människan agerar. Med en agent som har körrättigheter kan systemet fatta beslutet självt och gå vidare utan att invänta godkännande.

Om beslutet är rätt går arbetsflödet snabbare. Men agenter har inte alltid hela bilden. De kan missa beroenden i applikationen, affärsregler, arbetsbelastningsmönster, underhållsfönster eller annat sammanhang som är uppenbart för dem som sköter systemet.

En agent kan alltså fatta ett beslut som verkar tekniskt rimligt och ändå vara fel för den miljö där den agerar, med tanke på just den miljöns begränsningar och krav.

Risken ökar när åtgärderna börjar kedjas ihop. En dålig SELECT kan gå långsamt. En dålig UPDATE kan låsa en hel stor tabell eller påverka långt fler rader än avsett. Ett index som används för en fråga kan vara onödigt, men ändå öka belastningen för andra frågor. En schemaändring kan få något att sluta fungera eftersom agenten inte kände till dess beroenden; agenten kanske saknar hela den operativa kontexten och kan inte testa alla tänkbara användningsfall.

Problemet är alltså inte att agenter inte kan fatta bra beslut om databaser. Det kan de ofta. Problemet är att när de väl får agera utifrån besluten måste grupperna vara mycket tydligare med hur långt mandatet sträcker sig, vilken kontext agenten kan se, när en människa fortfarande behöver ingripa och vem som ytterst ansvarar för resultatet.

Gartner räknar med att mer än 40 procent av projekten inom agentisk AI kommer att läggas ned före utgången av 2027, delvis på grund av otillräckliga riskkontroller. För databasgrupper är lärdomen ganska enkel: körrättigheter bör komma efter kontrollerna, inte före dem.

Vad kan delegeras på ett säkert sätt?

Vissa databasuppgifter är betydligt säkrare att överlåta än andra.

Frågeanalys är ett bra exempel. En agent kan granska frågestatistik, hämta exekveringsplaner, kontrollera index och tabellstrukturer samt föreslå sannolika lösningar utan att ändra produktionsdata.

Den kan upptäcka att en fråga som den här upprepade gånger genomsöker en stor Orders tabell:

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

Därefter kan den förklara genomsökningen, föreslå ett index och generera DDL-koden. Den behöver inte ha behörighet att köra CREATE INDEX för att vara till nytta.

Detsamma gäller uppgifter som:

• Beskriva exekveringsplaner;
• Identifiera saknade eller onödiga index;
• Flagga SELECT * frågor eller icke-sargbara predikat;
• Granska pushdown av kopplingar och filter;
• Granska beroenden och scheman;
• Felsöka SQL-fel;
• Optimera SQL-skript.

Den praktiska uppdelningen är enkel: ge agenten tillräcklig åtkomst för att förstå problemet, men inte automatiskt tillräcklig åtkomst för att ändra databasen. Bred insyn kan vara användbar, men breda körrättigheter är ett separat beslut.

Där mänsklig kontroll fortfarande behövs

Vissa beslut om databaser kräver fortfarande att en människa är med i processen. Anta att en agent hittar en AuditLog tabell med hundratals miljoner rader och beslutar att gamla poster ska raderas:

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

SQL-koden kan vara helt giltig och ändå leda till ett mycket dåligt beslut.

Kanske kräver regelverket att uppgifterna sparas i sju år. Det är möjligt att ett program är beroende av dessa poster. Kanske bör raderingen göras i omgångar för att undvika att transaktionsloggen växer. Kanske måste poster arkiveras innan de tas bort.

Inget av dessa krav behöver nödvändigtvis framgå av schemat.

Det här är en av begränsningarna med att se databasarbete som ett problem för kodgenerering. Databaser innehåller tekniska strukturer, men besluten kring dem är ofta affärsbeslut som uttrycks genom tekniska åtgärder. Samma försiktighet bör gälla för åtgärder som:

• DROP och destruktiva ALTER kommandon;
• produktions- UPDATE och DELETE driftåtgärder;
• stora datamigreringar;
• ändringar av roller och behörigheter;
• ändringar av begränsningar;
• ändringar som påverkar replikering eller tillgänglighet;
• driftsättning av lagrade procedurer som innehåller affärslogik.

En tekniskt korrekt åtgärd är inte nödvändigtvis lämplig. Mänskligt godkännande bör därför inte ses som en besvärlig begränsning av agentisk AI. Vid databasåtgärder med stor påverkan är det en del av arkitekturen.

AI-agenter behöver också bara minsta möjliga behörighet

En genväg som databasteam bör undvika är att låta en agent använda en utvecklares befintliga inloggningsuppgifter. Det är enkelt, men då får agenten samma åtkomst som utvecklaren redan har.

Det säkrare tillvägagångssättet är detsamma som för användare och tjänster: minsta möjliga behörighet. Microsoft rekommenderar att man bara beviljar de behörigheter som krävs för uppgiften och övervakar privilegierad aktivitet.

En agent för prestandaanalys kan till exempel behöva:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Den behöver förmodligen inte:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Olika agenter kan också ha olika identiteter. En rapporteringsagent kan få SELECT åtkomst till ett fåtal scheman. En migreringsagent kan arbeta enbart i utvecklings- eller testmiljöer. En produktionsagent kan få strikt avgränsade behörigheter och ändå behöva godkännande innan den får utföra åtgärder.

OWASP rekommenderar samma grundprincip för AI-agenter: skilj på läs- och skrivåtkomst, begränsa verktyg och resurser och kräv uttryckligt tillstånd för känsliga åtgärder.

Regeln är enkel: ge agenten de behörigheter som arbetet kräver, inte de behörigheter som personen som startade den har.

Bygg in människan i arbetsflödet

En bättre modell för agentiskt databasarbete är ett kontrollerat arbetsflöde:

Observera → Analysera → Föreslå → Granska → Utför → Validera → Dokumentera

Anta att en agent undersöker en långsam API-slutpunkt. Den hittar SQL-frågan bakom den, granskar exekveringsplanen och tabellstatistiken, upptäcker ett sannolikt saknat index och förbereder ett migreringsskript.

Skriptet kan köras i testmiljön först. Agenten kör arbetsbelastningen igen, kontrollerar resultatet och förbereder ändringen för produktion.

Sedan stannar den.

En utvecklare eller DBA granskar migreringen, kontrollerar beroenden och affärspåverkan och godkänner den innan något når produktionen.

Agenten kan fortfarande ta hand om mycket av det repetitiva arbetet. Det som förblir människans ansvar är det slutliga ansvaret för en förändring med stor påverkan.

Transaktionskontroller kan ge ytterligare ett säkerhetslager. Sparpunkter i PostgreSQL gör det till exempel möjligt att återställa en del av en transaktion utan att kasta bort allt som hänt tidigare. Det kan vara till hjälp vid tätt sammankopplade automatiserade ändringar, men återställning ersätter inte korrekta behörigheter och godkännande.

Det är också här verktyg som dbForge AI Assistant passar in. Verktyget kan använda schemakontext för att generera och förklara SQL, felsöka fel, jämföra DDL, upptäcka ineffektiva index och förbereda optimeringsskript, samtidigt som den resulterande SQL-koden förblir synlig för utvecklargranskning.

Målet är att automatisera rutinuppgifterna och låta viktiga beslut förbli mänskliga.

Det verkliga målet är kontrollerad autonomi

Agentisk AI behöver inte innebära att man måste välja mellan ”AI föreslår bara” och ”AI styr databasen”. Det finns gott om utrymme däremellan.

Team kan börja med uppgifter med lägre risk, som att förklara SQL, granska scheman och utföra kontroller med enbart läsåtkomst. Därefter kan agenter gradvis ta sig an fler uppgifter i utvecklings- och testmiljöer.

Skrivåtkomst bör införas mycket senare, med tydliga begränsningar för berörda rader, transaktioner, återställning, övervakning och godkännanden. Helt autonoma ändringar i produktion bör vara sällsynta.

Det ligger också i linje med Deloittes rekommendationer: börja med arbetsflöden med lägre risk och icke-kritiska data, håll människor informerade och stärk styrningen i takt med att agenterna får mer.

Målet är inte fullständig autonomi. Det handlar om att ge agenten tillräcklig frihet för att kunna hjälpa till, men inte mer åtkomst än den behöver.

Slutsats: Databasutveckling kräver fortfarande gott omdöme

AI-agenter kan ta över många repetitiva arbetsuppgifter inom databasteknik. De kan se arbetsbelastningar, granska frågor, koppla samman scheman, exekveringsplaner, fel och prestandadata samt agera utifrån det de ser.

Men när ett AI-system kan ändra databasens tillstånd förändras problemet. Team behöver tydliga regler för identitet, behörigheter, transaktionsgränser, godkännanden, observerbarhet, återställning och revisionsspår.

Därför uppgav endast 7 % av de 88 % av organisationerna som använde AI 2025 att tekniken hade skalats upp fullt ut i hela organisationen. Den svårare utmaningen är att göra AI tillräckligt tillförlitlig för att kunna användas i stor skala.

Databasutvecklingen går i samma riktning. Den mest användbara agenten är inte den som får göra mest, utan den vars befogenheter är tydliga och kontrollerade.

Frågan är inte längre om AI kan utföra databasuppgifter, utan vilka uppgifter vi bör låta den utföra och under vilka begränsningar.