Ihmiset pitävät henkeään kiinni, kun tekoäly kiihdyttää ohjelmistotoimitusta

Suurimman osan ohjelmistokehityksen historiasta ihmiset ovat olleet hallinnan keskiössä. Kehittäjä tekee muutoksen, toinen henkilö tarkastaa sen, joku hyväksyy sen, ja lopulta se otetaan käyttöön.

Tekoäly kiihdyttää koko järjestelmää, vaikka yritämme yhä pitää ihmiset sen keskellä. Kehittäjät voivat nyt luoda koodia ja muutoksia sekunneissa. Agentit voivat toimia eri varastoissa, työkaluissa, infrastruktuurissa ja muissa järjestelmissä vähemmän ihmisen osallistumista vaativalla tavalla.

Instinktimme on palauttaa ihmiset prosessiin. Tarkastelemme pull requestin, hyväksymme työkalukutsun, tarkistamme muutoksen ja vahvistamme käyttöönoton, koska haluamme varmistaa, että tekoäly ei tehnyt jotain, mitä sen ei olisi pitänyt tehdä. Pidämme kiinni henkeämme.

Se instinkti on järkevä. Ihmisen tarkastus on antanut meille tavan ylläpitää hallintaa, kun ohjelmisto siirtyy tuotantoon. Mutta tekoäly alkaa toimia nopeudella ja volyymilla, jonka vuoksi ihmiset eivät enää pysty olemaan hallinnan mittayksikkö.

Tekoäly liikkuu jo nopeammin kuin ihmisen tarkastus

Generatiivisen tekoälyn ensimmäinen aalto ohjelmistokehityksessä keskittyi lähinnä auttamaan kehittäjiä kirjoittamaan koodia nopeammin. Tämä yksinään muuttaa ohjelmistotoimitusta. Enemmän koodia tarkoittaa enemmän sovellusmuutoksia, infrastruktuurimuutoksia ja tietokantamuutoksia, jotka kulkevat testauksen, turvallisuuden, tarkastuksen, käyttöönoton ja tuotannon läpi.

Ongelma ei ole välttämättä se, että tekoäly tuottaa huonompia muutoksia. Se tuottaa enemmän muutoksia, nopeammin. Jos kaiken tämän uuden tuotoksen hallinta on toisen henkilön tarkastaa jokainen muutos, matemaattinen tasapaino lopulta horjuu.

Olemme jo näkemässä merkkejä siitä. Anthropic raportoi äskettäin, että Claude Code -käyttäjät hyväksyvät noin 93 % käyttöoikeuskehoituksista. Yritys havaitsi, että toistuvat kehotukset voivat aiheuttaa hyväksymiskylmyyttä, kun ihmiset kiinnittävät vähemmän huomiota hyväksymisten määrän kasvaessa. Anthropic käyttää nyt automaattista luokittelijaa arvioidakseen toimia ja pysäyttääkseen mahdollisesti vaaralliset sen sijaan, että pyytäisi henkilöä hyväksymään kaiken.

Mieti, mitä tämä kertoo ihmisen valvonnasta. Jos joku klikkaa hyväksy 93 % ajasta, toisen hyväksynnän lisääminen ei välttämättä anna sinulle enemmän hallintaa. Jossain vaiheessa ihminen muuttuu prosessin seuraavaksi askeleeksi.

Voimme käyttää tekoälyä luomaan enemmän ohjelmistoja. Emme kuitenkaan voi vastata luomalla yhtä suuri ihmistarkastusoperaatio sen taakse.

Tekoäly siirtyy koodin luomisesta toiminnan toteuttamiseen

Koodausavustajat antoivat tekoälylle roolin kehityksessä. Agentit antavat tekoälylle kyvyn osallistua paljon laajemmin ohjelmistokehityksen elinkaareen (SDLC). Agentti voi vastaanottaa tavoitteen, päättää miten sen toteuttaa, käyttää työkaluja, tarkkailla tuloksia ja säätää seuraavaa toimintaansa.

Ohjelmistotekniikassa tämä voi tarkoittaa tiedostojen muokkaamista, komentojen suorittamista, varastojen kanssa vuorovaikuttamista, API‑kutsujen tekemistä, koodin testaamista tai infrastruktuurin kanssa työskentelemistä. Ihmiset tulevat myös yhä mukavammiksi antamaan agenttien toimia itsenäisesti. Miljoonien ihmisen ja agentin vuorovaikutusten tutkimuksessa Anthropic löysi, että kokeneet Claude Code -käyttäjät hyödynsivät täyttä automaattihyväksyntää yli 40 % istunnoista, mikä on suunnilleen kaksinkertainen määrä kuin uusilla käyttäjillä.

Tämä ei tarkoita, että autonomiset agentit toimisivat tuotantoympäristöissä kaikkialla tänään. Niin ei ole. Mutta ohjelmistokehitys antaa meille varhaisen katsauksen siihen, minne tämä on menossa.

Tänä päivänä tekoäly luo enemmän muutoksia, ja ihmistarkastus alkaa rasittua. Seuraavaksi tekoäly osallistuu laajemmin ohjelmistokehityksen elinkaareen. Lopulta agentit luovat, validoivat, ottavat käyttöön, tarkkailevat ja korjaavat muutoksia paljon vähemmän ihmisen osallistumista vaativalla tavalla.

Jokaisessa vaiheessa poistamme toisen paikan, jossa henkilö aikaisemmin antoi hallintaa. Kysymys siirtyy siitä, pystyykö tekoäly tekemään työn, siihen, mitä tekoälyn tulisi saada tehdä itsenäisesti.

Lupa ei ole valtuus

Agentit tarvitsevat pääsyn suorittaakseen hyödyllistä työtä. Ohjelmiston käyttöönottoa avustava agentti saattaa tarvita pääsyn varastoon, CI/CD‑järjestelmään, pilviympäristöön tai tietokantaan. Jos poistat tämän pääsyn, otat myös pois suuren osan siitä, mikä tekee agentista hyödyllisen.

Mutta pääsy eikä valtuus ole sama asia. Antamalla agentille luvan päästä järjestelmään, ei automaattisesti tarkoita, että sillä pitäisi olla valtuus tehdä kaikki järjestelmässä mahdollisesti olevat toiminnot.

Perinteinen pääsynhallinta voi kertoa, onko agentilla lupa päästä johonkin. Tarvitsemme myös tavan määrittää, tulisiko se erityinen toiminto tapahtua. Tämä korostuu, kun päätöksen tekevällä järjestelmällä on eri tulkinta tehtävästä kuin sen antaneella henkilöllä, se kohtaa esteen ja valitsee toisen reitin tai käyttää laillista työkalua tavalla, jota kukaan ei odottanut.

OWASP kuvaa tätä ongelmaa versiona, jota kutsutaan Liialliseksi toimivallaksi. Se osoittaa liiallisen toiminnallisuuden, käyttöoikeudet ja autonomian aiheuttavan vahingollisia toimia ja suosittelee itsenäistä hyväksyntää korkean vaikutuksen toimille.

NVIDIA lähestyy samaa ongelmaa arkkitehtuuritasolla. Sen Open Agent Safety Platform asettaa politiikan toteutuksen agentin ulkopuolelle ja tekee yksinkertaisen huomautuksen: agentilta ei voida odottaa, että se hallitsee täysin omaa käyttäytymistään.

Tämän tulisi ohjata, miten rakennamme AI‑SDLC:n. Agentti saattaa tarvita luvan päästä käsiksi tietokantaan, infrastruktuuriympäristöön tai käyttöönottojärjestelmään. Se ei kuitenkaan tarkoita, että agentin pitäisi itse päättää, että jokainen sen tekemä muutos on turvallinen.

AI tekee päätöksiä todennäköisyyksiin perustuen. Emme saa antaa jokaisen tällaisen päätöksen muuttua automaattisesti toiminnaksi kriittistä järjestelmää vastaan.

Ihminen silmukassa ei voi olla koko vastaus

Ilmeinen vastaus on pitää henkilö mukana merkittävissä AI‑toiminnoissa. Joissakin päätöksissä se on juuri se, mitä meidän tulisi tehdä. Virhe on muuttaa “ihminen silmukassa” ratkaisuksi kaikkiin päätöksiin.

Jos jokainen agentin toiminto vaatii jonkun tarkistavan sen ja klikkaavan hyväksy, olemme luoneet uudelleen sen pullonkaulan, jonka AI:n oli tarkoitus poistaa. Pahimmillaan riittävä määrä hyväksyntöjä muuttaa valvonnan tavaksi. Henkilö, joka klikkaa hyväksy koko päivän, ei välttämättä harjoita harkintaa.

Meidän on oltava tarkempia siitä, missä päätökset tehdään. AI voi tehdä päätöksiä sille annetussa tehtävässä. Politiikka voi hoitaa päätökset, joissa säännöt ovat jo tiedossa. Ihmiset voivat hoitaa poikkeuksia ja päätöksiä, jotka todella vaativat harkintaa.

Alhaisen riskin muutos, joka täyttää vakiopolitiikan, ei saisi vaatia ketään tarkkailemaan sitä. Muutos, joka rikkoo politiikkaa, tulisi pysäyttää automaattisesti. Poikkeus, jolla on merkittäviä liiketoiminta‑, turvallisuus‑ tai operatiivisia seurauksia, saattaa vaatia henkilön tekemään päätöksen.

Tämä on hyvin erilainen malli kuin pelkkä ihmisen asettaminen jokaisen silmukan keskelle. Tavoitteena ei ole poistaa ihmisiä, vaan lopettaa ihmisen huomion asettaminen jokaisen toiminnon riippuvaiseksi ja tehdä hallitusta polusta helpoin polku.

Aseta hallinta sinne, missä toiminta tapahtuu

Yritykset eivät tule standardoimaan yhtä AI‑mallia tai yhtä agenta. Kehittäjät käyttävät erilaisia avustajia. Tiimit kokeilevat eri malleja. AI ilmestyy kehittäjätyökaluihin, turvallisuustuotteisiin, dataplatformeihin ja sisäisiin sovelluksiin.

Erillisen hallintaprosessin rakentaminen jokaiselle AI‑työkalulle ei skaalaudu. Hallinnan täytyy sijaita lähellä sitä toimintaa, jonka AI haluaa suorittaa.

Jos AI‑luotu muutos siirtyy käyttöönotto‑putkeen, sen tulisi kohdata samat politiikat kuin ihmisen luoma muutos. Jos agentti haluaa muokata infrastruktuuria, dataa tai tuotantotietokantaa, kyseisen järjestelmän hallinnan ei tulisi kadota, koska toimija vaihtui.

Muutoksen lähde ei määritä riskiä. Riski syntyy itse muutoksesta. Kehittäjä, koodausavustaja, automatisoitu prosessi tai autonominen agentti voivat kulkea eri reittiä samaan toimintaan, mutta kyseinen toiminto voi silti kohdata saman politiikan ennen kuin siitä tulee merkittävä.

Tämä myös mahdollistaa teknologian kehittymisen ilman, että yritysten täytyy rakentaa hallintaa uudelleen joka kerta. Mallit muuttuvat. Agentit tulevat kykenevämmiksi. Hallinta kriittisten järjestelmien ympärillä voi pysyä johdonmukaisena.

NIST käyttää samankaltaista riskiperusteista lähestymistapaa AI Risk Management Framework-ssa, jossa hallintaa pidetään elinkaaren läpi toimivana eikä pelkkänä lopullisena hyväksyntänä. Ohjelmistotoimituksessa tämä tarkoittaa hallintojen sijoittamista AI:n jo kulkemaan polkuun sen sijaan, että lisättäisiin toinen manuaalinen prosessi.

Kun ihminen poistuu, todisteet eivät voi poistua hänen mukana

Ihmisen tarkistusmallissa piilee toinen ongelma. Kun poistat henkilön prosessista, et menetä vain tarkistusta. Saatat myös menettää henkilön, joka auttoi todistamaan tarkistuksen tapahtuneen.

Tämä muodostaa vakavan haasteen yrityksille, joilla on turvallisuus‑, vaatimustenmukaisuus‑ ja auditointitarpeita. Niiden on edelleen tiedettävä, mitä muutettiin, kuka tai mikä sen aloitti, mitä politiikkaa sovellettiin, läpäisikö se, kuka hyväksyi poikkeuksen, missä muutos suoritettiin ja mitä sen jälkeen tapahtui.

Et voi automatisoida muutosta ja jättää todisteet manuaalisiksi. Ihmisohjatussa prosessissa tiimit voivat myöhemmin rekonstruoida todisteet tiketeistä, hyväksynnöistä, putkilokin, kuvakaappauksista ja keskusteluista. Tämä lähestymistapa käy yhä vaikeammaksi, kun muutosten määrä kasvaa, ja siitä tulee epärealistista, kun koneet luovat ja toteuttavat muutoksia jatkuvasti.

Todisteiden täytyy sisältyä toimitusprosessiin. Politiikkapäätökset, hyväksynnät, poikkeukset, käyttöönotot ja tulokset tulisi luoda tallenteina työn edetessä. Auditointitodisteet muuttuvat ohjelmistotoimituksen sivutuotteeksi sen sijaan, että tiimit kokoaisivat ne jälkikäteen.

Tämä jättää kaksi erillistä tehtävää hallinnolle AI‑ohjatussa SDLC:ssä. Ennen toimintaa määritetään, tuleeko se toteuttaa. Toiminnan jälkeen todistetaan, mitä tapahtui.

Ihmiset eivät katoa. Tehtävämme muuttuu.

On ymmärrettävää mitata hallintaa sen perusteella, kuinka monta kertaa henkilö osallistuu. Useammat tarkistukset tuntuvat turvallisemmilta. Useammat hyväksynnät tuntuvat turvallisemmilta. Ihmisen pitäminen jokaisessa silmukassa tuntuu turvallisemmalta.

AI testaa tätä oletusta. Jos AI jatkaa ohjelmiston määrän kasvattamista, ihmiset eivät pysty tarkistamaan jokaista muutosta, hyväksymään jokaista toimintoa, seuraamaan jokaista käyttöönottoa ja rekonstruoimaan jokaista päätöstä jälkikäteen. Yrittäminen joko hidastaa AI:ta tai muuttaa ihmisen valvonnan kumipainikkeeksi.

AI:n SDLC tarvitsee erilaisen työnjaon. AI voi hoitaa enemmän työtä, kun taas politiikka ohjaa toistettavia päätöksiä ja ihmiset puuttuvat, kun jokin todella vaatii harkintaa. Todisteet tulisi luoda automaattisesti matkan varrella.

Annamme AI:lle enemmän pääsyä, koska näin se muuttuu hyödylliseksi. Annamme agenteille enemmän autonomiaa, koska näin saamme heiltä enemmän vaikutusvaltaa. Haasteena on varmistaa, että suurempi pääsy ja autonomia eivät hiljaisesti muutu rajoittamattomaksi valtuutukseksi.

Ihmiset eivät tarvitse pitää kiinni tiukemmin. Tavoitteena ei ole vähemmän hallintaa. Kyse on hallintamallista, joka ei riipu siitä, että pidämme jokaisen päätöksen itse käsissämme. Meidän täytyy rakentaa hallintamekanismit, jotka antavat meidän löysätä otetta ilman, että hallinta katoaa.