Seuraava ohjelmistosi käyttäjä on tekoälyagentti. Onko arkkitehtuurisi valmis?

Kuvittele tekoälyagentti, joka käsittelee asiakkaan laskutusta koskevaa reklamaatiota. Se lukee reklamaation, tarkistaa tilihistorian ja päättelee, että hyvitys on aiheellinen. Kaikki tämä tapahtuu muutamassa sekunnissa.

Vaikuttavaa. Pyydäpä sitä nyt todella tekemään hyvitys.

Asiakassopimus on toisessa järjestelmässä. Hyväksymissäännöt ovat piilossa sovelluskoodissa. Laskutustyökalu edellyttää, että ihminen napsauttaa itsensä läpi useista näytöistä.

Agentti ymmärtää, mitä pitäisi tehdä, mutta arkkitehtuuri ei anna sen viedä työtä loppuun.

Tämä on ongelma, johon yhä useammat yritykset joutuvat törmäämään, kun agenttipohjainen tekoäly siirtyy tuotantokäyttöön. Erikoista kuitenkin on se, että tehtävän loppuun saattamisen esteellä on hyvin vähän tekemistä agentin älykkyyden kanssa.

Olemme vuosien ajan uudistaneet yritysohjelmistoja niitä käyttävien ihmisten tarpeisiin. Nyt meidän on uudistettava ne myös niitä yhä useammin käyttävien agenttien tarpeisiin.

Käyttöliittymä ei ole koskaan ollut koko tuote

Mieti, miten yritysohjelmistot toimivat nykyään. Ihmiset avaavat sovelluksia, selaavat koontinäyttöjä, tekevät päätöksiä ja siirtävät työtä järjestelmästä toiseen. Käyttöliittymän kautta he asioivat yrityksen kanssa.

Agentti ei välttämättä tarvitse näitä näkymiä. Se voi hakea tietoja ja käynnistää toimintoja rajapintojen, Model Context Protocol (MCP) -palvelinten ja muiden ohjelmallisten rajapintojen kautta. Tämä on osa siirtymää kohti käyttöliittymätöntä arkkitehtuuria.

Käyttöliittymättömyys ei kuitenkaan tarkoita, että sovellus katoaisi. Sen tiedot, liiketoimintasäännöt, käyttöoikeudet ja vaatimustenmukaisuusvaatimukset ovat yhä tärkeitä. Väittäisin, että ne ovat entistä tärkeämpiä.

Ohjelmistotoimittajat rakensivat vuosien ajan kilpailuetua viimeisteltyjen käyttöliittymien, käyttäjien tottumusten ja työntekijöiden uudelleenkoulutuksen kustannusten varaan. Nämä edut heikkenevät, kun agentit hoitavat yhä enemmän työtä avaamatta sovelluksen käyttöliittymää. Tällöin arvokkaammaksi nousee taustalla oleva rekisterijärjestelmä: luotettavat tiedot, validoitu toimialalogiikka, toiminnan hallinnointi ja jäljitettävät tapahtumat.

Tällä on myös kaupallinen seuraus: yrityssovelluksiin käytettävistä menoista jopa 234 miljardia dollaria voi joutua agenttipohjaisen tekoälyn aiheuttaman murroksen uhan alle vuoteen 2030 mennessä. Kyse on menoista, joita murros voi häiritä, ei menoista, joiden katoaminen olisi varmaa. Kun agentit tekevät töitä, joita ihmiset aiemmin hoitivat koontinäytöissä, käyttäjäkohtainen hinnoittelu saattaa yhä useammin väistyä käyttöön, suoritettuihin toimiin tai saavutettuihin tuloksiin perustuvien mallien tieltä.

Ohjelmistotoimittajille tämä on liiketoimintamalliin liittyvä haaste. Niille yrityksille, jotka ovat riippuvaisia toimittajien sovelluksista, kyse on arkkitehtuurin haasteesta.

Olemme uudistaneet osia, emme työnkulkua

Useimmat yritykset ovat uudistaneet toimintaansa jo vuosien ajan. Yksi tiimi päivittää vanhoja sovelluksia. Toinen kokoaa hajanaiset tiedot yhteen uudenaikaiselle alustalle. Kolmas rakentaa integraatioita tai vain uudistaa käyttöliittymän.

Jokainen hanke voi onnistua itsenäisesti. Ongelmia syntyy, kun agentin pitää suorittaa työnkulku niiden kaikkien läpi.

Agentille voi antaa tarkat asiakastiedot, mutta jos niiden pohjalta toimivan sovelluksen kriittiset säännöt ovat piilossa vanhassa koodissa, mitä tapahtuu seuraavaksi? Tai voit avata selkeän rajapinnan, vaikka sen taustalla olevat tiedot olisivat edelleen epäyhtenäisiä. Agentti voi ryhtyä toimeen, mutta voitko luottaa sen tekemään päätökseen?

Molemmissa tapauksissa olemme uudistaneet osan teknologiasta uudistamatta kuitenkaan itse työtä.

Agenttipohjaista tekoälyä ei kiinnosta, mikä uudistushanke onnistui. Sitä kiinnostaa, toimiiko koko työnkulku.

Tältä se näyttää käytännössä. Eräs asiakas tarvitsi nopeamman tarjousprosessin monimutkaisiin moottorikorjauksiin, joissa sopimukset määräävät, mitkä osat voidaan korjata, vaihtaa tai kunnostaa. Jokaisen tarjouksen laatimiseen kului päiviä, joskus viikkoja, kun sopimuksia ja huolto-oppaita tutkittiin käsin. Asiakas oli jo uudistanut tietoalustansa, mutta tarjoukset eivät valmistuneet yhtään nopeammin, sillä pullonkaulana eivät koskaan olleet tiedot. Pullonkaulana oli niiden tutkiminen. Rakensimme työnkulun uudelleen tutkimusagenttien kokonaisuuden varaan, lyhensimme tutkimukseen kuluvaa aikaa 80 % ja saimme tarjoukset etenemään aivan eri tahtiin.

Siksi sovellusten ja tietojen uudistamista ei voi suunnitella kahdeksi toisistaan riippumattomaksi työvirraksi. Arkkitehtuurin on tuettava liiketoiminnallisen tavoitteen saavuttamista kokonaisuudessaan.

Rajapinta ei tee järjestelmästä agenttivalmista

Voi olla houkuttelevaa ajatella, että ratkaisu on yksinkertainen: avaa rajapintapisteet, yhdistä agentti ja homma on hoidettu.

Kunpa se olisikin niin helppoa.

Tietojen hakeminen on yksi asia. Hyvityksen tekeminen, taloustiedon päivittäminen tai varaosan tilaaminen ovat aivan eri asioita. Nyt puhumme suorittamisesta, emme pelkästä pääsystä tietoihin.

Tässä yhteydessä käytän termiä agenttien ohjauspinta: rajattu ja hallitusti ohjattu rajapinta, jonka kautta agentit lukevat tietoja rekisterijärjestelmistä ja kirjoittavat niihin.

Rajapinnat ja MCP-palvelimet voivat tarjota agenteille työkaluja ja dataa. MCP ei kuitenkaan automaattisesti valvo liiketoimintasääntöjäsi eikä päätä, kenellä on oikeus toimia. Nämä valvontamekanismit on edelleen suunniteltava osaksi taustalla olevia järjestelmiä ja työnkulkuja.

Pystyykö agentti hakemaan luotettavaa, virallista tietoa? Onko liiketoimintasäännöt määritelty selkeästi ja sovelletaanko niitä johdonmukaisesti? Voiko agentti suositella toimenpidettä mutta toteuttaa vain sellaisia, joita se on valtuutettu toteuttamaan? Jos jokin menee pieleen, pystymmekö jäljittämään toiminnan, käsittelemään poikkeuksen ja mahdollisuuksien mukaan peruuttamaan sen?

Nämä eivät ole ongelmia, jotka parempi malli ratkaisisi yksin. Kyse on työnkuluista, sovellussuunnittelusta, data-arkkitehtuurista, integraatioista ja hallinnasta. Näihin kysymyksiin on vastattava yhdessä.

Aloita työstä, älä teknologiasta

Mistä siis pitäisi aloittaa?

En aloittaisi muuttamalla kaikkia sovelluksia käyttöliittymättömiksi tai avaamalla kaikkia käytettävissä olevia rajapintoja. Aloittaisin yhdestä merkityksellisestä liiketoimintatyönkulusta.

Käy se läpi alusta loppuun. Missä järjestelmissä tiedot ovat? Missä liiketoimintalogiikka sijaitsee? Mitä tietoja agentti voi pitää luotettavina? Mitkä päätökset edellyttävät ihmisen hyväksyntää? Mitä tapahtuu, jos järjestelmä vikaantuu kesken kaiken? Miten hallinta varmistetaan?

Löydät olennaiset puutteet. Niiden pohjalta syntyy modernisoinnin etenemissuunnitelmasi: sovellukset, data, integraatiot ja ohjausmekanismit kattava koordinoitu kehitysjono, jota ohjaa liiketoiminnallinen tavoite irrallisten teknologiahankkeiden sijaan.

Mittaa onnistumista sen mukaisesti. Älä sen perusteella, kuinka monta rajapintaa olet avannut tai kuinka paljon dataa olet siirtänyt, vaan sen perusteella, toimiiko työnkulku luotettavasti, miten poikkeukset ratkaistaan ja paranevatko liiketoiminnan tulokset.

Tavoitteena ei ole autonomia kaikkialla, vaan toimintavarma ja luotettava toteutus sekä ihmisen harkinta siellä, missä sitä tarvitaan.

Todellinen muutos ulottuu käyttöliittymätöntä arkkitehtuuria pidemmälle

Minua ei innosta koontinäyttöjen poistaminen. Minua innostaa se, ettei ihmisten enää tarvitse siirtää työtehtäviä manuaalisesti toisistaan irrallisten järjestelmien välillä saadakseen työn tehdyksi.

Emme kuitenkaan pääse tähän lisäämällä agenttia sellaisen arkkitehtuurin päälle, jota ei ole koskaan suunniteltu sitä varten.

Yritysohjelmistojen seuraavaa sukupolvea ei määritä vain se, mitä ne antavat ihmisten nähdä. Sen määrittää se, mitä ne antavat agenttien tehdä luotettavasti ja vastuullisesti.