Agenttinen tekoäly kohtaa tietokantojen kehittämisen: mitä muuttuu, kun tekoäly pystyy todella suorittamaan kyselyitä

Viime vuosina tekoälyavusteinen tietokantojen kehittäminen on noudattanut melko selkeää toimintamallia. Kehittäjä kuvailee tarpeen. Tekoäly luo SQL-koodin. Kehittäjä lukee sen, korjaa havaitsemansa virheet ja päättää, suorittaako koodin.

Tämä toimintatapa on säilyttänyt yhden tärkeän rajan: tekoäly voi ehdottaa toimintoa, mutta ihminen päättää yhä, päätyykö se tietokantaan.

Agenttisen tekoälyn myötä tämä raja on kuitenkin alkanut hämärtyä. Nykyään tekoälyjärjestelmät voivat tarkastella skeemoja, suorittaa kyselyitä, tulkita tuloksia ja päättää, mitä tehdä seuraavaksi. Tuoreen kyselyn mukaan 62 % organisaatioista kokeilee jo tekoälyagentteja, ja 23 % ilmoitti ottaneensa agenttisen järjestelmän käyttöön laajemmin jossakin osassa yritystä.

Tietokantatiimien on siis vastattava melko välittömään arkkitehtuurikysymykseen. Kyse ei ole siitä, pystyykö tekoäly suorittamaan SQL-koodia. Se pystyy. Todellinen kysymys on, mitä muuttuu, kun avustaja lakkaa ehdottamasta koodia ja alkaa toimia tietokannan parissa, ja kuinka tiukasti tätä autonomiaa pitäisi valvoa.

Ehdotuksista toimintaan

Yksinkertainen indeksointipäätös havainnollistaa, miksi tällä muutoksella on merkitystä.

Agentti havaitsee hitaan kyselyn, tarkistaa skeeman, päättelee, että indeksistä voisi olla apua, luo sen, suorittaa kuormituksen uudelleen ja tarkistaa tuloksen.

Se voi suorittaa niinkin tavanomaisen komennon kuin:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Komennossa ei ole mitään erikoista. Tekoälyavustaja olisi voinut ehdottaa täsmälleen samaa. Ero on siinä, kuka tekee lopullisen päätöksen.

Avustajaa käyttäessään kehittäjä tarkistaa suosituksen, testaa sen ja päättää, suorittaako sen. Tekoäly neuvoo, mutta ihminen toimii. Suoritusoikeudet omaava agentti voi tehdä päätöksen itse ja jatkaa odottamatta hyväksyntää.

Jos päätös on oikea, työnkulku nopeutuu. Agenteilla ei kuitenkaan aina ole kokonaiskuvaa. Niiltä voi jäädä huomaamatta sovellusten riippuvuuksia, liiketoimintasääntöjä, kuormitusmalleja, ylläpitoikkunoita tai muuta sellaista, mikä on järjestelmää ylläpitäville ihmisille itsestään selvää.

Agentti voi siis tehdä teknisesti järkevältä vaikuttavan päätöksen, joka on silti väärä siinä ympäristössä, jossa se toimii, kun otetaan huomioon ympäristön erityiset rajoitteet ja vaatimukset.

Vaara kasvaa, kun toiminnot alkavat ketjuuntua. Huono SELECT voi vain toimia hitaasti. Huono UPDATE voi lukita koko suuren taulun tai vaikuttaa paljon useampiin riveihin kuin oli tarkoitus. Yhdessä kyselyssä käytetty indeksi voi olla tarpeeton ja silti hidastaa muita kyselyitä. Skeemamuutos voi rikkoa jotakin, jonka riippuvuudesta agentti ei tiennyt, sillä agentilta voi puuttua kattava operatiivinen tilannekuva eikä se pysty testaamaan kaikkia mahdollisia käyttötapauksia.

Ongelma ei siis ole se, etteivät agentit pystyisi tekemään hyviä tietokantaan liittyviä päätöksiä. Usein ne pystyvät. Ongelma on se, että kun niiden sallitaan toimia päätöstensä perusteella, tiimien on määriteltävä paljon tarkemmin, kuinka pitkälle niiden valtuudet ulottuvat, mitä tietoja agentti voi nähdä, missä tilanteissa ihmisen on yhä puututtava asiaan ja kuka vastaa lopputuloksesta.

Gartner arvioi, että yli 40 % agenttisista tekoälyhankkeista perutaan vuoden 2027 loppuun mennessä, osittain puutteellisen riskienhallinnan vuoksi. Tietokantatiimeille opetus on melko yksinkertainen: suoritusoikeudet tulee myöntää vasta hallintakeinojen käyttöönoton jälkeen, ei ennen sitä.

Mitä voidaan siirtää agentin tehtäväksi turvallisesti?

Jotkin tietokantatehtävät on paljon turvallisempaa antaa agentin hoidettavaksi kuin toiset.

Kyselyiden analysointi on hyvä esimerkki. Agentti voi tarkastella kyselytilastoja, hakea suoritussuunnitelmia, tarkistaa indeksit ja taulujen rakenteet sekä ehdottaa todennäköisiä korjauksia muuttamatta tuotantodataa.

Se voi havaita kyselyn, joka käy toistuvasti läpi suurta Orders taulua:

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

Tämän jälkeen se voi selittää, mistä läpikäynti johtuu, ehdottaa indeksiä ja luoda DDL-komennon. Sen ei tarvitse saada oikeutta suorittaa CREATE INDEX komentoa ollakseen hyödyllinen.

Sama pätee esimerkiksi seuraaviin tehtäviin:

• Suoritussuunnitelmien kuvaileminen;
• Puuttuvien tai tarpeettomien indeksien tunnistaminen;
• Havaitseminen SELECT * kyselyissä tai ei-sargable-ehdoissa;
• Liitosten ja suodatusten siirtämisen tarkastelu;
• Riippuvuuksien ja skeemojen tarkastelu;
• SQL-virheiden selvittäminen;
• SQL-komentosarjojen optimointi.

Käytännön jako on yksinkertainen: anna agentille riittävästi käyttöoikeuksia ongelman ymmärtämiseen, mutta älä automaattisesti niin paljon, että se voi muuttaa tietokantaa. Laajasta näkyvyydestä voi olla hyötyä, mutta laajat suoritusoikeudet ovat erillinen päätös.

Missä ihmisen valvontaa tarvitaan yhä

Joihinkin tietokantaan liittyviin päätöksiin tarvitaan yhä ihminen. Kuvitellaan, että agentti löytää AuditLog taulun, jossa on satoja miljoonia rivejä, ja päättää, että vanhat tietueet pitäisi poistaa:

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

SQL-koodi voi olla täysin kelvollista ja päätös silti surkea.

Sääntely voi esimerkiksi edellyttää tietojen säilyttämistä seitsemän vuoden ajan. Jokin sovellus saattaa riippua näistä tietueista. Poisto voi olla tarpeen tehdä erissä tapahtumalokin kasvun välttämiseksi. Tietueet on ehkä arkistoitava ennen poistamista.

Kaikkia näitä vaatimuksia ei välttämättä ole määritelty skeemassa.

Tämä on yksi tietokantatyön tarkastelun koodin generointina aiheuttamista rajoituksista. Tietokannat sisältävät teknisiä rakenteita, mutta niihin liittyvät päätökset ovat usein liiketoimintapäätöksiä, jotka toteutetaan teknisillä toimenpiteillä. Samaa varovaisuutta on syytä noudattaa myös seuraavissa toimissa:

• DROP ja tuhoisat ALTER lauseet;
• tuotanto- UPDATE ja DELETE toiminnot;
• suuret tietomigraatiot;
• roolien ja käyttöoikeuksien muutokset;
• rajoitteiden muutokset;
• replikointiin tai käytettävyyteen vaikuttavat muutokset;
• liiketoimintalogiikkaa sisältävien tallennettujen proseduurien käyttöönotto.

Teknisesti oikea toimenpide ei välttämättä ole asianmukainen. Siksi ihmisen hyväksyntää ei pidä pitää agenttisen tekoälyn hankalana rajoitteena. Vaikutuksiltaan merkittävissä tietokantatoiminnoissa se on osa arkkitehtuuria.

Myös tekoälyagenttien on noudatettava vähimmän oikeuden periaatetta

Tietokantatiimien tulisi välttää oikopolkua, jossa agentin annetaan käyttää kehittäjän olemassa olevia tunnistetietoja. Se on helppoa, mutta antaa agentille kaikki samat käyttöoikeudet kuin kyseisellä kehittäjällä on.

Turvallisempi lähestymistapa on sama kuin käyttäjien ja palveluiden kohdalla: vähimmän oikeuden periaate. Microsoft suosittelee myöntämään vain tehtävän edellyttämät käyttöoikeudet ja valvomaan etuoikeutettua toimintaa.

Suorituskykyä analysoiva agentti saattaa esimerkiksi tarvita:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Se ei luultavasti tarvitse:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Myös eri agenteilla voi olla eri identiteetit. Raportointiin käytettävä agentti voi saada SELECT käyttöoikeudet muutamaan skeemaan. Migraatioagentti voi toimia vain kehitys- tai testiympäristössä. Tuotantoympäristössä toimivalla agentilla voi olla tarkasti rajatut käyttöoikeudet, ja sen suorituksille voidaan silti vaatia hyväksyntä.

OWASP suosittelee tekoälyagenteille samaa perusmallia: luku- ja kirjoitusoikeudet erotetaan toisistaan, työkalujen ja resurssien käyttöä rajoitetaan ja arkaluonteiset toimet edellyttävät nimenomaista valtuutusta.

Sääntö on yksinkertainen: anna agentille sen työtehtävän edellyttämät käyttöoikeudet, älä sen käynnistäneen henkilön käyttöoikeuksia.

Ota ihminen mukaan työnkulkuun

Agenttiseen tietokantatyöhön sopii paremmin hallittu työnkulku:

Havainnoi → Analysoi → Ehdota → Arvioi → Suorita → Vahvista → Kirjaa

Oletetaan, että agentti tutkii hidasta API-päätepistettä. Se etsii sen taustalla olevan SQL-kyselyn, tarkistaa suoritussuunnitelman ja taulukoiden tilastot, havaitsee todennäköisesti puuttuvan indeksin ja laatii migraatioskriptin.

Skripti voidaan suorittaa ensin testiympäristössä. Agentti ajaa työkuorman uudelleen, tarkistaa tuloksen ja valmistelee tuotantoon vietävän muutoksen.

Sitten se pysähtyy.

Kehittäjä tai tietokannan pääkäyttäjä tarkistaa migraation, arvioi riippuvuudet ja vaikutukset liiketoimintaan sekä hyväksyy muutoksen ennen kuin mitään viedään tuotantoon.

Agentti voi silti hoitaa suuren osan toistuvasta työstä. Vaikutuksiltaan merkittävän muutoksen lopullinen vastuu säilyy ihmisellä.

Transaktioiden hallintakeinoilla voidaan parantaa turvallisuutta entisestään. Esimerkiksi PostgreSQL:n tallennuspisteiden avulla osa transaktiosta voidaan peruuttaa hylkäämättä kaikkea sitä edeltävää. Tästä voi olla apua tarkasti rajatuissa automaattisissa muutoksissa, mutta palautus ei korvaa asianmukaisia käyttöoikeuksia ja hyväksyntää.

Myös dbForge AI Assistant sopii luontevasti tähän kokonaisuuteen. Se voi hyödyntää skeeman kontekstia SQL-kyselyiden luomiseen ja selittämiseen, virheiden selvittämiseen, DDL-määritysten vertailuun, tehottomien indeksien havaitsemiseen ja optimointiskriptien valmisteluun. Tuloksena syntyvä SQL pysyy samalla kehittäjän nähtävillä tarkistusta varten.

Tavoitteena on automatisoida rutiinityöt mutta jättää tärkeät päätökset ihmisille.

Todellinen tavoite on hallittu autonomia

Agenttinen tekoäly ei tarkoita, että pitäisi valita vain kahdesta vaihtoehdosta: tekoäly ainoastaan ehdottaa tai tekoäly käyttää tietokantaa. Näiden väliin mahtuu paljon.

Tiimit voivat aloittaa pienemmän riskin tehtävistä, kuten SQL-kyselyiden selittämisestä, skeemojen tarkistamisesta ja vain luku -tarkistuksista. Sen jälkeen agentit voivat vähitellen ottaa hoitaakseen enemmän töitä kehitys- ja testiympäristöissä.

Kirjoitusoikeudet tulisi ottaa käyttöön vasta paljon myöhemmin, ja niihin tulisi liittää selkeät rajat muutosten kohteena olevien rivien määrälle, transaktioille, palautuksille, valvonnalle ja hyväksynnöille. Täysin autonomisten muutosten tulisi olla tuotannossa harvinaisia.

Tämä vastaa myös Deloitten ohjeistusta: aloita pienemmän riskin työnkuluista ja epäolennaisista tiedoista, pidä ihmiset mukana ja vahvista hallintaa agenttien saadessa lisää tehtäviä.

Tavoitteena ei ole täydellinen autonomia. Agentille halutaan antaa riittävästi vapautta avustamiseen, mutta ei enempää käyttöoikeuksia kuin se tarvitsee.

Yhteenveto: Tietokantojen kehittäminen vaatii edelleen harkintaa

Tekoälyagentit voivat vähentää huomattavasti tietokantatekniikkaan liittyvää toistuvaa työtä. Ne voivat tarkastella työkuormia ja kyselyitä, yhdistellä skeemoja, suoritussuunnitelmia, virheitä ja suorituskykytietoja sekä toimia havaintojensa perusteella.

Kun tekoälyjärjestelmä kuitenkin pystyy muuttamaan tietokannan tilaa, ongelma muuttuu. Tiimit tarvitsevat selkeät säännöt identiteeteistä, käyttöoikeuksista, transaktiorajoista, hyväksynnöistä, havainnoitavuudesta, palauttamisesta ja auditointijäljistä.

Siksi niistä 88 prosentista organisaatioita, jotka käyttivät tekoälyä vuonna 2025, vain 7 % ilmoitti ottaneensa sen täysimääräisesti käyttöön koko organisaatiossa. Vaikeampaa on tehdä tekoälystä niin luotettava, että sitä voidaan käyttää laajassa mittakaavassa.

Tietokantojen kehitys kulkee samaan suuntaan. Hyödyllisin agentti ei ole se, jolla on eniten toimintavapautta, vaan se, jonka toimivaltuudet tunnetaan ja jota valvotaan selkeästi.

Kysymys ei enää ole siitä, pystyykö tekoäly suorittamaan tietokantatehtäviä, vaan siitä, mitkä tehtävät voimme luottaa sen suoritettaviksi ja millaisin rajoituksin.