AWS:n ratkaisukehityksen globaalin johtajan tekoälyvetoinen modernisointimalli

Saurabh Shrivastava toimii Amazon Web Servicesin ratkaisujen arkkitehtuurin ja asiakasympäristöön sijoitetun insinöörityön globaalina johtajana. Hänen työnsä keskittyy agenttipohjaiseen tekoälyyn ja yritysten modernisointiin.

Tapasimme Saurabhin saadaksemme tietää uusista insinöörityön malleista, joita hän käyttää työssään AWS:llä. Tässä hänen kertomansa asiat.

Tekoälyn vastuullinen teollistaminen

Olen teknologia- ja tekoälymuutosten johtaja, jolla on yli 20 vuoden kokemus yritysten auttamisesta monimutkaisten teknologiamuutosten muuttamisessa skaalautuviksi liiketoimintatuloksiksi. Urani on vienyt minut insinöörityön, yritysarkkitehtuurin, tuotteisiin linjattujen kenttäinsinöörien, pilvimuutosten sekä nykyisin AWS:n agenttipohjaisen tekoälyn ja ohjelmistotehdasmallien pariin.

Urani alkuvaiheessa rakensin ja johdin laajoja yritysalustoja televiestinnän, vähittäiskaupan, toimitusketjujen, finanssiteknologian sekä tutkimus- ja kehitysympäristöissä. Tämä antoi minulle vahvan ymmärryksen systeemiajattelusta, luotettavuudesta, integraatioiden monimutkaisuudesta ja teknologian käytön realiteeteista yrityksen mittakaavassa.

AWS:llä roolini laajeni infrastruktuurien ja sovellusten modernisoinnissa auttamisesta globaalin ratkaisujen arkkitehtuurin sekä asiakasympäristöön sijoitetun insinöörityön johtamiseen. Aloitteet keskittyivät tekoälyyn, modernisointiin ja agenttipohjaisiin alustoihin. Olen työskennellyt yritysjohtajien, kumppaneiden, tuote- ja insinööritiimien kanssa siirtyäksemme strategiasta ja kokeiluista hallittuihin, tuotantovalmiisiin alustoihin.

Tekoäly ei ole enää vain yksi teknologiavaihe muiden joukossa. Se muuttaa tapaa, jolla organisaatiot rakentavat ohjelmistoja, työntekijät työskentelevät, asiakkaat asioivat ja teknologiaorganisaatioiden on toimittava. Todellinen johtamisen haaste ei ole pelkästään mallien tai työkalujen valinta. Haasteena on luoda toimintamalli, arkkitehtuuri, hallintamalli, osaaminen ja tuotekehityksen kurinalaisuus, joiden avulla tekoäly voidaan teollistaa vastuullisesti.

AWS:n ratkaisujen arkkitehtuurin johtaminen

Ratkaisujen arkkitehtuurin ja FDE:n globaalina johtajana johdan AWS:n maailmanlaajuista ratkaisujen arkkitehtuurin ja asiakasympäristöön sijoitetun insinöörityön organisaatiota. Työ keskittyy agenttipohjaisiin tekoälyalustoihin, yritysten modernisointiin ja tuotantomittakaavan pilvimuutoksiin.

Organisaatio toimii yritysten mittakaavassa ja työskentelee suurten globaalien asiakkaiden, strategisten kumppaneiden, tuotetiimien, erikoistuneiden insinööritiimien ja alueellisten kenttäorganisaatioiden kanssa. Arkkitehtuurin kattama alue on laaja: tekoäly- ja koneoppimisalustat, agenttipohjaiset työnkulut, datan ja analytiikan perustat, sovellusten modernisointi, pilvinatiivi infrastruktuuri, tietoturva, hallinta sekä kumppaneihin integroidut ratkaisut.

Johdan, mahdollistan ja ohjaan maailmanlaajuisesti yli 200 asiantuntijaa, kumppani-insinööriä ja teknologia-alan kenttäjohtajaa. Työ on erittäin monimutkaista, koska emme rakenna erillisiä demonstraatioita. Autamme yrityksiä siirtymään varhaisista tekoälyideoista ja modernisoinnin liiketoimintaperusteluista toistettaviin, turvallisiin ja tuotantovalmiisiin alustoihin, joita voidaan skaalata liiketoimintayksiköissä, markkinoilla ja asiakasympäristöissä.

Käyttöönottomallimme yhdistää asiakasympäristöön sijoitetun insinöörityön, globaalit alustamekanismit, kumppanivetoisen toimituksen sekä tuotteen ja kentän palautesilmukat. Tiimini rakentaa uudelleenkäytettäviä suunnitelmia, viitearkkitehtuureja, johtotason demonstraatioita, teknisiä toimintaohjeita, hallintamalleja ja koostettavia ratkaisumalleja, jotka nopeuttavat käyttöönottoa ja säilyttävät samalla laadun, tietoturvan ja toiminnan kurinalaisuuden.

Miksi asiakasympäristöön sijoitettu insinöörimalli on tekoälyn yhteydessä välttämätön

Otin viime vuonna käyttöön asiakasympäristöön sijoitetun insinöörimallin tekoälyvetoista modernisointia varten.

Pilviaikana meillä oli uudelleenkäytettäviä viitearkkitehtuureja, ratkaisusuunnitelmia, käyttöönottomalleja ja hallinnan tarkistuspisteitä. Ne olivat tarpeellisia, mutta tekoälyn yhteydessä riittämättömiä. Asiakkailla oli edelleen vaikeuksia siirtyä konseptitodistuksesta tuotantoon, koska vaikein työ tapahtui heidän todellisessa ympäristössään: datan, sovelluskannan, koodin monimutkaisuuden, tietoturvarajoitteiden ja toimintamallin parissa.

Siksi otin käyttöön FDE-mekanismin, joka sijoittaa insinöörit paljon lähemmäs asiakkaan todellisia työkuormia. Ulkopuolelta neuvomisen sijaan FDE-tiimi työskentelee asiakkaan datan, koodin, arkkitehtuurin ja toimitustiimien kanssa tunnistaakseen modernisoinnin kohteet, rakentaakseen käyttökelpoisia ratkaisuja ja siirtääkseen ensimmäisen työkuorman tuotantoon.

Otin käyttöön myös yksinkertaisen 3-3-3-mallin: 3 päivää kartoitukseen, 3 viikkoa arviointiin ja 3 kuukautta ensimmäisen työkuorman siirtämiseen tuotantoon. Tämä antoi johtajille selkeän polun tekoälytavoitteista mitattavaan arvoon.

Vaikutus oli merkittävä. Asiakkaat pystyivät nopeuttamaan modernisointimatkaansa 2–4-kertaisesti, pienentämään kustannuksia jopa puoleen ja siirtymään demonstraatioista saavutettuun sijoitetun pääoman tuottoon. Vielä tärkeämpää oli se, että tämä muutti johtotason keskustelua. Tekoäly ei enää ollut sivukokeilu, vaan käytännöllinen mekanismi todellisten työkuormien modernisointiin, insinöörien tuottavuuden parantamiseen ja mitattavan liiketoiminta-arvon luomiseen.

Kuinka modernisoida nopeammin luottamusta menettämättä

Käytän tekoälyä runsaasti teknisen ymmärryksen, hahmontunnistuksen ja suunnittelun läpimenon nopeuttamiseen, mutta en siirrä vastuuvelvollisuutta tekoälylle.

Monimutkaisissa yrityksissä liiketoiminta perustuu usein vuosikymmenten aikana kertynyttä koodia, teknistä velkaa, dokumentoimattomia riippuvuuksia ja järjestelmiin upotettuja liiketoimintasääntöjä sisältävälle perustalle. Tässä ympäristössä tarvitsemme sekä deterministisiä että probabilistisia lähestymistapoja. Mission kannalta kriittisiä järjestelmiä ymmärtäessämme emme voi luottaa yksinomaan probabilistiseen tekoälypohjaiseen selvitykseen.

Koodin selvityksessä, liiketoimintasääntöjen erottelussa, riippuvuusanalyysissä, ominaisuuksien kartoituksessa ja nykytilan arvioinnissa suosin deterministisempää lähestymistapaa. Tarvitsemme jäljitettävyyttä, toistettavuutta, näyttöä ja varmuutta siitä, mitä järjestelmä tekee. Tekoäly voi auttaa tiivistämällä, ryhmittelemällä ja nopeuttamalla analyysiä, mutta perustan on pohjauduttava koodista, lokeista, tietovirroista, ajonaikaisesta toiminnasta ja arkkitehtonisesta näytöstä saataviin todennettaviin faktoihin.

Tekoälystä tulee tulevaisuuden työssä entistä tehokkaampi: se tuottaa modernisointivaihtoehtoja, ehdottaa uusia arkkitehtuureja, määrittelee palvelurajoja, kehittää migraatiomalleja, kirjoittaa koodia, tuottaa testejä ja nopeuttaa toteutusta. Tämä osa voi olla probabilistisempi, koska tekoäly voi tutkia vaihtoehtoja ja parantaa suunnittelun nopeutta.

Mutta tässäkin lopullinen päätös säilyy ihmisellä. Vastuuvelvollisten suunnittelijoiden ja johtajien on vahvistettava arkkitehtuurivalinnat, tietoturvan tason, tuotantovalmiuden, vaatimustenmukaisuusriskin, asiakasvaikutukset ja investointien väliset kompromissit.

Oma mallini on siis seuraava: deterministinen selvitys, tekoälyn nopeuttama suunnittelu ja toteutus sekä ihmisen ohjaama validointi. Tämä yhdistelmä antaa meille mahdollisuuden modernisoida nopeammin ilman, että menetämme luottamusta, hallintaa tai yrityksen vastuuvelvollisuutta.

Tekoälyn haittapuolet suunnittelun työnkuluissa

Saurabh jakaa

Kustannukset eivät ole ainoa haittapuoli (tekoälyssä). Tekoäly voi myös luoda väärää varmuutta, jos tiimit käyttävät sitä ilman hallintaa.

Suurin myönteinen tulos oli se, että tekoäly lyhensi merkittävästi selvityksestä tuotantoon johtavaa matkaa, kun se sisällytettiin kurinalaiseen suunnittelun työnkulkuun.

Tekoäly nopeutti myös koodin ymmärtämistä, liiketoimintasääntöjen erottelua, riippuvuusanalyysiä, testien luomista, dokumentointia ja modernisoinnin suunnittelua. Se vähensi manuaaliseen analyysiin kuluvaa aikaa ja auttoi suunnittelutiimejä keskittymään enemmän arkkitehtuuripäätöksiin, validointiin ja tuotantovalmiuteen.

Tekoälystä voi kuitenkin tulla hyvin nopeasti erittäin kallista, jos tiimit eivät suunnittele päättelyn taloudellisuutta. Suurissa yrityksissä, joissa on miljoonia käyttäjiä, edistyneiden mallien tunnuskustannukset voivat nousta miljooniin dollareihin, jos jokainen vuorovaikutus riippuu ulkoisista kolmansien osapuolten perusmalleista ilman optimointia.

Yksi opetus on, että tekoälyarkkitehtuurin on sisällettävä myös kustannusarkkitehtuuri. Joidenkin työkuormien osalta yritysten tulisi arvioida itse ylläpidettyä tai pilvipalvelussa ylläpidettyä päättelyä, jossa käytetään grafiikkaprosessoreita tai kiihdyttimiä, mukaan lukien esimerkiksi vLLM:n käyttö pilvi-infrastruktuurissa. Tämä antaa paremman hallinnan kustannuksiin, viiveeseen, tietorajoihin ja mallien palvelemisstrategiaan. Tekniikat, kuten KV-välimuisti, jatkuva eräajo, kvantisointi ja ytimen optimointi, voivat parantaa merkittävästi grafiikkaprosessorien käyttöastetta ja vähentää päättelyn kustannuksia.

Kustannukset eivät ole ainoa haittapuoli. Tekoäly voi myös luoda väärää varmuutta, jos tiimit käyttävät sitä ilman hallintaa. Riskiin kuuluvat puutteellinen koodin ymmärtäminen, hallusinoidut riippuvuudet, heikko testikattavuus, tietoturva-aukot ja tiimit, jotka siirtyvät liian nopeasti prototyypistä tuotantoon.

Miksi tekoälyllä on vaikeuksia päästä päähän ulottuvassa vanhojen järjestelmien modernisoinnissa

Tekoälyllä on ollut eniten vaikeuksia silloin, kun tiimit pyytävät sitä tekemään teknisiä arvioita ilman riittävää järjestelmäkontekstia.

Yleinen esimerkki on vanhojen järjestelmien nykyaikaistaminen. Tekoäly voi tehdä yhteenvedon koodista, tuottaa siirtymäideoita ja jopa luoda uutta koodia nopeasti. Suurissa yrityksissä todellinen monimutkaisuus ulottuu kuitenkin koodia laajemmalle. Siihen kuuluvat vuosikymmenten aikana muodostuneet liiketoimintasäännöt, dokumentoimattomat integraatiot, eräajot, tietoriippuvuudet, toiminnalliset poikkeukset, tietoturvarajoitteet ja organisaation omistajuus. Jos tekoälyä pyydetään nykyaikaistamaan tällainen ympäristö vain osittaisen näkymän perusteella, se voi tuottaa itsevarmoja mutta puutteellisia vastauksia.

Tuotantovalmius on toinen alue, jossa tekoälyllä on vaikeuksia. Tekoäly voi luoda prototyyppejä hyvin nopeasti, mutta monista prototyypeistä ei automaattisesti tule turvallisia, havainnoitavia, vikasietoisia ja kustannustehokkaita tuotantojärjestelmiä. Tiimit aliarvioivat joskus testaukseen, hallintamalleihin, häiriötilanteisiin vastaamiseen, valvontaan, mallien arviointiin, datan laatuun ja elinkaaren hallintaan tarvittavan työn määrän.

Miten insinöörit voivat parantaa tuotteita ja samalla hallita päättelyn kustannuksia ja luotettavuutta

Tässä on esimerkki suuresta media- ja markkinointisisällön luontialustasta, jossa tekoäly auttaa käyttäjiä siirtymään tavoitteesta valmiisiin digitaalisiin aineistoihin yrityksen mittakaavassa.

Työnkulku alkaa, kun käyttäjä kuvailee, mitä hän haluaa luoda: tuotteen julkaisukampanjan, sosiaalisen median mainosmateriaalin, myyntiesityksen, videokatkelman tai lokalisoidun markkinointiaineiston. Tekoäly tulkitsee käyttäjän tarkoituksen, mukaan lukien kohderyhmän, muodon, sävyn, brändiohjeet, vaaditut aineistot, kanavakohtaiset rajoitteet ja vaatimustenmukaisuusvaatimukset.

Siitä eteenpäin alusta käyttää agenttipohjaista työnkulkua. Yksi agentti hakee brändin hyväksymät mallipohjat, logot, fontit, värit ja kampanja-aineistot. Toinen luo tekstiä ja luovia muunnelmia. Kolmas ehdottaa asetteluja. Neljäs tarkistaa brändinmukaisuuden, saavutettavuuden, käytännöt ja sisällön turvallisuuden. Lopullinen orkestrointikerros kokoaa tuloksen muokattaviksi aineistoiksi ja ohjaa sen hyväksyntä- tai julkaisutyönkulkuihin.

Tässä mittakaavassa insinöörit kohtasivat haasteita, jotka liittyivät paitsi mallien laatuun myös päättelyn taloudellisuuteen, viiveeseen, luotettavuuteen ja hallintamalleihin. Tiimi optimoi erittäin laajamittaista päättely-ympäristöä, joka tuki noin 10 000 laskentasolmua ja noin 80 000:ta grafiikkasuoritinta. Arkkitehtuurissa yhdistettiin useiden pilvipalveluntarjoajien ja hyväksyttyjen kolmansien osapuolten grafiikkasuoritinkapasiteettia, ja ympäristöt yhdistettiin hybridiverkkokerroksen kautta. Tämä antoi alustalle joustavuutta sijoittaa työkuormia kustannusten, viiveen, saatavuuden ja datan sijainnin perusteella.

Tiimi otti käyttöön myös kurinalaisemman mallien tarjoilustrategian. Sen sijaan, että jokainen pyyntö lähetettäisiin kalleimmalle edistyneelle mallille, alusta ohjasi pyynnöt käyttötarkoitukseen sopivien mallien välillä, mukaan lukien Kimin ja Qwenin kaltaiset avoimet mallit, joita tarjottiin vLLM:n ja Ollaman kaltaisten optimoitujen ajonaikaisten ympäristöjen kautta. Tiimi sovelsi myös päättelyn optimointitekniikoita, kuten KV-välimuistia, jatkuvaa eräkäsittelyä, kvantisointia, muistin optimointia ja ydintasolla tehtävää hienosäätöä, parantaakseen grafiikkasuorittimien käyttöastetta ja vähentääkseen kustannuksia.

Ihmiset säilyivät päätöksenteon keskeisissä kohdissa ohjausvastuussa. Tekoäly tuotti vaihtoehtoja, ehdotti asetteluja, kirjoitti tekstiä ja nopeutti tuotantoa, mutta käyttäjä tai brändin omistaja hyväksyi lopullisen aineiston. Insinööritiimit vastasivat suojakaiteista: tietoturvasta, datan käyttöoikeuksista, mallin valinnasta, havainnoitavuudesta, viiveestä, kustannusten hallinnasta, turvallisuustarkistuksista ja palautesilmukoista.

Tuloksena oli tekoälytyönkulku, josta tuli osa tuotteen käyttökokemusta eikä vain sisäinen tuottavuustyökalu. Se lyhensi ideasta aineistoksi etenemiseen kuluvaa aikaa, paransi personointia, lisäsi hyväksyttyjen brändikomponenttien uudelleenkäyttöä ja loi palautesilmukan, jossa käyttäjien muokkaukset ja sitoutumistiedot paransivat tulevia suosituksia. Samalla arkkitehtuuri antoi liiketoiminnalle huomattavasti paremman hallinnan päättelyn kustannuksista, luotettavuudesta ja hallintamalleista.

Miksi tekoälyn käyttöönotot edellyttävät tuotemallista ajattelutapaa

Tekoälytyökalujen käyttöönotossa on vähemmän kyse työkalujen omaksumisesta ja enemmän insinöörityön toimintamallin muuttamisesta.

Aluksi monet organisaatiot ajattelevat, että haasteena on antaa insinööreille pääsy apuohjelmiin, koodausavustajiin, mallirajapintoihin tai sisäisiin tekoälyalustoihin. Se auttaa, mutta ei riitä. Ilman selkeitä toimintamalleja tiimit käyttävät tekoälyä epäjohdonmukaisesti. Jotkut käyttävät sitä vain koodin tuottamiseen. Jotkut käyttävät sitä dokumentointiin. Jotkut luottavat siihen liikaa. Toiset välttelevät sitä, koska ovat epävarmoja tietoturvaan, immateriaalioikeuksiin tai laatuun liittyvistä riskeistä.

Jos aloittaisin alusta, määrittelisin tekoälyavusteisen insinöörityönkulun vielä aikaisemmin: missä tekoälyä pitäisi ja ei pitäisi käyttää, mitä näyttöä vaaditaan, mitä ihmisten on tarkistettava ja miten tuotokset testataan, suojataan ja viedään tuotantoon.

Tämä olisi välttänyt muutamia ongelmia. Ensinnäkin olisimme voineet vähentää käytön epäjohdonmukaisuutta tiimien välillä. Toiseksi olisimme voineet välttää perusteettoman luottamuksen tekoälyn tuottamaan koodiin tai analyysiin, joka näytti oikealta mutta josta puuttui riittävä konteksti. Kolmanneksi olisimme voineet hallita kustannuksia aiemmin ottamalla mallien reitityksen, token-budjetoinnin, välimuistin ja päättelyn hallinnan käyttöön alusta alkaen. Neljänneksi olisimme voineet luoda parempia uudelleenkäytettäviä malleja sen sijaan, että jokainen tiimi kehitti oman lähestymistapansa.

Suurin oppi on, että tekoälyn käyttöönotto edellyttää tuote- ja alustalähtöistä ajattelutapaa. Tarvitaan käyttöönoton tukea, suojakaiteita, havainnointia, kustannusten hallintaa, tietoturvatarkastuksia, uudelleenkäytettäviä kehotteita ja agentteja, arviointimalleja sekä selkeää ihmisten vastuuta. Muuten tekoäly lisää tekemistä ilman, että se aina parantaa ohjelmistokehityksen laatua tai liiketoiminta-arvoa.

Miksi SDLC:n on muututtava AI-DLC:ksi

Saurabh jakaa

CTO:iden pitäisi suunnitella aktiivisesti itse ohjelmistojen toimituksen elinkaari uudelleen.

CTO:iden pitäisi suunnitella aktiivisesti itse ohjelmistojen toimituksen elinkaari uudelleen. Ajattelen tätä siirtymänä perinteisestä SDLC:stä AI-DLC:hen eli tekoälyn tehostamaan toimituksen elinkaareen agenttisen tekoälyn aikakaudella.

Perinteisessä SDLC:ssä noudatamme usein lineaarisia vaiheita: vaatimukset, suunnittelu, kehitys, käyttöönotto ja tuki. Tämä toimi kohtuullisen hyvin silloin, kun päätavoitteena oli deterministisen ohjelmiston rakentaminen jäsenneltyjen siirtymien avulla. Tekoälyn, erityisesti agenttisen tekoälyn, myötä elinkaaresta tulee kuitenkin iteratiivisempi ja tiiviimpi.

Yksinkertaistan AI-DLC:n kolmeen päävaiheeseen: käynnistys, rakentaminen ja käyttö.

• Käynnistysvaiheessa tekoäly auttaa selvitystyössä, koodin ymmärtämisessä, liiketoimintasääntöjen erottelussa, riippuvuusanalyysissä, vaatimusten täsmentämisessä, riskien tunnistamisessa ja tavoitetilan suunnittelussa.
• Rakentamisvaiheessa tekoäly avustaa arkkitehtuurivaihtoehdoissa, palvelujen hajottamisessa, koodin ja testien luonnissa, dokumentoinnissa, tietoturvatarkastuksissa, infrastruktuurimalleissa ja modernisoinnin toteutuksessa.
• Käyttövaiheessa tekoäly tukee havainnointia, häiriöiden ensiarviointia, palautesilmukoita, mallien arviointia, kustannusten optimointia, hallintaa ja jatkuvaa parantamista.

Oleellista on, ettei AI-DLC ole vain SDLC, johon on lisätty koodiavustaja. Se on uudistettu ohjelmistokehityksen toimintamalli. Se yhdistää tekoälyagentit, deterministisen selvitystyön, ihmisen suorittaman validoinnin, tietoturvaportit, tuotantovalmiuden ja kustannusten hallinnan yhdeksi työnkuluksi.

Miten tekoäly muuttaa ohjelmistokehitystiimejä

Tekoäly on siirtänyt ohjelmistokehitystiimejä roolipohjaisesta, vaiheittaisesta toteutuksesta kohti integroidumpia ja tuloskeskeisempiä ryhmiä.

Aiemmin organisoiduimme erillisten roolien ympärille: arkkitehdit, sovelluskehittäjät, data-insinöörit, DevOps, tietoturva, laadunvarmistus ja operointi. Nämä roolit ovat edelleen tärkeitä, mutta tekoäly tiivistää elinkaarta ja vähentää pitkien siirtymien arvoa. Parhaiten suoriutuvat tiimit ovat monialaisempia ja lähempänä liiketoimintaongelmaa.

Tekoälyvetoisessa modernisoinnissa ja tuotekehityksessä etsin nykyään tiimejä, joissa yhdistyvät useat kyvykkyydet: vahvat ohjelmistokehityksen perusteet, pilvi- ja alustakehitys, data- ja tekoälyosaaminen, tietoturvatietoisuus, tuotelähtöinen ajattelu ja operatiivinen harkinta. Arvostan myös insinöörejä, jotka työskentelevät epäselvissä ympäristöissä, päättelykyky perustuu perusperiaatteisiin ja jotka validoivat tekoälyn tuotokset sen sijaan, että hyväksyisivät ne sokeasti.

Eteen sijoitettujen insinöörien toimintamalli on hyvä esimerkki. Sen sijaan, että arkkitehtuuri, tekoälykehitys, DevOps ja tietoturva pidettäisiin erillisillä peräkkäisillä linjoilla, tuomme nämä taidot lähemmäs asiakas- tai liiketoimintaympäristöä. Tiimi työskentelee todellisen koodin, datan, rajoitteiden ja onnistumisen mittareiden kanssa.

Myös rekrytointi on muuttunut. Tekninen syvällisyys on minulle edelleen erittäin tärkeää, mutta etsin myös systeemiajattelijoita: ihmisiä, jotka ymmärtävät arkkitehtuuria, käyttävät tekoälyä vastuullisesti, viestivät liiketoiminnan sidosryhmien kanssa ja vastaavat tuotantotuloksista. Tekoälyn aikakaudella parhaat insinöörit eivät ole vain koodin tuottajia. He ovat ongelman määrittelijöitä, validoijia ja toistettavien järjestelmien rakentajia.

Miten tekoälyn vaikuttavuutta mitataan

Yksi kysymys, jonka toivoisin useampien esittävän, on tämä: Miten CTO:iden pitäisi mitata sitä, luoko tekoäly yritykselle kestävää arvoa?

CTO:t eivät saa arvioida tekoälyä ainoastaan käyttöönotettujen pilottien tai apureiden määrän tai mallin erillisen tarkkuuden perusteella. Nämä ovat hyödyllisiä signaaleja, mutta ne eivät todista muutosta.

CTO:iden pitäisi arvioida tekoälyä neljän ulottuvuuden kautta:

1. Tuotantotekniikan tuottavuus: Lyhentääkö tekoäly läpimenoaikaa, parantaako se koodin laatua, lisääkö se testikattavuutta, nopeuttaako se modernisointia ja vähentääkö se teknistä velkaa?
2. Liiketoimintavaikutus: Parantaako tekoäly asiakaskokemusta, työntekijöiden tuottavuutta, tuloskonversiota, kustannustehokkuutta tai markkinoillepääsyn nopeutta?
3. Tuotantokypsyys: Ovatko tekoälyjärjestelmät turvallisia, havainnoitavia, luotettavia, hallittuja ja kustannuksiltaan valvottuja? Onko niillä selkeä ihmisten vastuuvelvollisuus ja tuotantovalmiuden tarkistuspisteet?
4. Uudelleenkäytettävyys ja skaalautuvuus: Rakentavatko tiimit uudelleenkäytettäviä tekoälypalveluja, agentteja, kehotteita, malleja, datatuotteita ja alustakyvykkyyksiä vai luovatko ne erillisiä demoja?

Tämä on tärkeää, koska tekoäly voi synnyttää paljon näkyvää toimintaa ilman kestävää arvoa. CTO:iden on muutettava tekoälytoiminta toistettavaksi kyvykkyydeksi. Tämä tarkoittaa strategian, arkkitehtuurin, toimintamallin, hallinnan ja talouden yhdistämistä.

Miksi CTO:iden on erotettava kokeilu teollistamisesta

Tässä ovat neuvoni.

Ensinnäkin, älä käsittele tekoälyä sivukokeiluna. Käsittele sitä uutena liiketoiminnan toimintakerroksena. Tekoäly vaikuttaa siihen, miten ohjelmistoja rakennetaan, miten työntekijät työskentelevät, miten asiakkaat ovat vuorovaikutuksessa yrityksen kanssa ja miten päätöksiä tehdään. CTO:n tehtävä on siirtää organisaatio hajanaisista piloteista hallittuun ja skaalautuvaan tekoälyalustastrategiaan.

Toiseksi, erota kokeilu teollistamisesta. Nopeasti kokeileminen on hyvä asia, mutta tuotannossa toimiva tekoäly tarvitsee arkkitehtuurin, tietoturvan, datan hallinnan, arvioinnin, havainnoitavuuden, kustannusten hallinnan ja selkeän ihmisten vastuuvelvollisuuden. Monet yritykset ovat jumissa, koska niillä on paljon demoja mutta ei toistettavaa polkua tuotantoon. CTO:iden on rakennettava tämä polku.

Kolmanneksi, keskity liiketoiminta-arvoon, älä mallin uutuuteen. Menestyviä organisaatioita eivät ole ne, jotka yksinkertaisesti käyttävät uusinta mallia. Niitä ovat ne, jotka sisällyttävät tekoälyn todellisiin työnkulkuihin, modernisoivat teknologiapohjaansa, parantavat tuotantotekniikan tuottavuutta ja mittaavat tuloksia, kuten läpimenoaikaa, kustannustehokkuutta, asiakaskokemusta, vaikutusta liikevaihtoon ja riskien vähentämistä.

Ja neljänneksi, käytännön neuvoni on luoda tekoälyalusta ja etulinjaan sijoitettujen insinöörien toimintamalli yhdessä. Alusta mahdollistaa uudelleenkäytön, hallinnan ja skaalan. FDE-malli tuo tekoälyn todellisiin asiakas- ja yritystyökuormiin todellisen datan, todellisen koodin ja todellisten rajoitteiden avulla. Näin CTO:t voivat siirtyä tekoälyä koskevista tavoitteista toteutuneeseen sijoitetun pääoman tuottoon.

Seuraa mukana

Seuraa Saurabh Shrivastavan työtä LinkedInissä ja hänen Amazon-kirjailijasivullaan.

Lisää asiantuntijahaastatteluja on luvassa The CTO Clubissa!