Yuri Gubin, DataArtin CTO – Haastattelusarja

Yuri Gubin, DataArtin CTO on kokenut teknologiajohtaja ja ohjelmistoarkkitehti, joka on viettänyt yli 18 vuotta DataArtissa edeten rooleissa, jotka kattavat ohjelmistoarkkitehtuurin, ratkaisukarkkitehtuurin, pilviteknologian, innovaation ja johtajuuden, ennen kuin hänestä tuli pääteknologiajohtaja maaliskuussa 2026. Hänen työnsä on keskittynyt monimutkaisten teknologisten haasteiden ratkaisemiseen eri toimialoilla, kuten rahoituspalvelut, terveydenhuolto, matkailu ja IoT, erityisesti pilvilaskennan, tekoälyn, dataplattaformaattien ja yritysohjelmistojen arkkitehtuurin osa-alueilla. Ennen CTO‑roolia Gubin toimi yli viisi vuotta DataArtin Chief Innovation Officerina ja on ollut yrityksen Partneri‑hallituksen jäsen vuodesta 2021. Hän on myös ammatillinen jäsen Forbes Technology Councilissa, osallistuen sen tekoäly- ja pilvilaskenta‑asiantuntijaryhmiin, ja toimii Technology Advisorina Girls Who Code -ohjelmassa, jossa hän neuvoo arkkitehtuurista, tietosuojasta, alustan hallinnasta ja teknologiapolitiikasta. DataArt listaa hänet tällä hetkellä pääteknologiajohtajakseen, toimipisteenä New Yorkissa.

DataArt on globaali ohjelmistokehitys- ja data‑ ja tekoälymuutospalveluyritys, joka perustettiin New Yorkissa vuonna 1997. Yritys on kasvanut yli 6 000 teknologiayhteisön jäseneksi, jotka toimivat yli 20 maassa, ja se tekee yhteistyötä yli 400 asiakkaan kanssa tarjoten palveluita aloilla, kuten tekoäly ja koneoppiminen, data ja analytiikka, pilvimurros, räätälöity ohjelmistokehitys, kyberturvallisuus ja perintöjärjestelmien modernisointi. DataArt toimii sektoreilla kuten rahoituspalvelut, terveydenhuolto ja elintarvikeala, matkailu, media ja viihde sekä vähittäiskauppa, ja ylläpitää teknologiakumppanuuksia alustoilla, kuten AWS, Google Cloud, Microsoft Azure, Snowflake ja Databricks. Vuonna 2025 yritys ilmoitti 100 miljoonan dollarin, kolmen vuoden investoinnin data‑ ja tekoälykyvykkyyksiinsä, ja vuonna 2026 lanseerattiin Artisyn, tekoälyyn perustuva toimintamalli, joka on suunniteltu sisällyttämään tekoälyagentteja, uudelleenkäytettäviä kiihdyttimiä, hallintaa, turvallisuutta ja vaatimustenmukaisuutta yritysohjelmistokehitykseen.

Olet viettänyt lähes kaksi vuosikymmentä DataArtissa, edeten ohjelmistoarkkitehdista ja ratkaisukarkkitehdista Chief Innovation Officeriksi ja nyt CTO:ksi. Miten tämä matka on muokannut tapaasi erottaa aidosti mullistavat teknologiat hype‑sykleistä, ja miten se vaikuttaa nykyiseen “skeptiseen optimismiisi” tekoälyä kohtaan?

Olemme nähneet vuosien varrella monia erilaisia aaltoja, kuten pilvipalveluiden ja mobiilin nousun, eri tekoälygeneraatioita, automaatiota, DevOpsia ja SRE:tä, ja olen koodannut, suunnitellut ja neuvonut asiakkaitamme näissä aiheissa koko ajan. Tajusin, että kyllä, teknologialla voi tehdä lähes mitä tahansa, ja teknologia on varsin voimakas, mutta paholainen piilee yksityiskohdissa, ja sinun on tiedettävä, mitä teet, jotta se on järkevää ja toimivaa.

Olen nähnyt pilviympäristöjen muuttuvan yhä kalliimmiksi, tekoälymallien toimimattomuuden odotusten mukaisesti, ja huonosti toteutettuja yrityksiä automatisoida julkaisusyklejä. Olen nähnyt sekä hyvien että huonojen päätösten vaikutukset, joten aina kun jokin uusi asia ilmestyy ja luet kaikki ilmoitukset, lupaukset ja hype, palaan samaan periaatteeseen: lähes kaikki on mahdollista teknologian avulla, mutta sinun täytyy tietää, mitä teet.

Hyvä käsitys teknologiasta syntyy tutkimus‑ ja kehitystyön (R&D) sekä, mikä tärkeintä, käytännön projektien kautta, sillä juuri näin opit, mikä on mahdollista, mikä ei, ja missä asiat voivat mennä pieleen. Otat nämä opit jokaisesta yhteistyöstä, puhut kollegoidesi, muiden arkkitehtien ja analyytikoiden kanssa, ja yrität ymmärtää, onko olemassa kaavoja ja voitko luoda niistä jonkinlaisen järjestelmän. Lopulta tästä syntyy ohjeistus, ja näet, tuottavatko ne päätökset, jotka koit hyviksi, todellakin hyviä tuloksia.

Juuri sieltä syntyy skeptinen optimismi. Mitä tahansa teknologia lupaa, sinun täytyy silti tietää, mitä teet, ja tämä tieto tulee kokemuksesta, yhteistyöstä ja jatkuvasta pyrkimyksestä oppia, kehittyä ja luoda jonkinlainen järjestelmä hypen taakse.

Yritys‑tekoäly näyttää siirtyvän vaiheesta, jossa kannustetaan kokeiluihin, siihen, että päätetään, mitkä kokeilut ansaitsevat skaalautumisen. Mitkä signaalit kertovat, että tekoälyn käyttötapaus on valmis laajempaan käyttöönottoon, ja mitkä varoitusmerkit osoittavat, että yritys skaalaa liian aikaisin?

Käytän kahta menetelmää ymmärtääkseni, voimmeko skaalata jotain vai pitääkö tehdä jotain muuta: omaksumiskäyrää ja oppimiskäyrää.

Jotta ymmärtäisit, toimiiko tekoälyn käyttötapaus, sinun on annettava sille aikaa ja selvitettävä, mitä arvoa se tuo ja miltä käyttäjäpolku näyttää, koska silloin näet ylä- ja alamäkiä sen sijaan, että keskityt vain välittömään ‘wow’-vaikutukseen tietyssä tiimissä tai työnkulussa. Sinun on tarkasteltava, mitä samojen ihmisten kohdalla tapahtuu muutaman viikon kuluttua. Käyttävätkö he sitä edelleen? Ovatko he edelleen tyytyväisiä kyseiseen käyttötapaukseen, automaatioon tai luomaansa tekoälyosaamiseen, vai oliko se vain lyhytkestoinen piikki, jota ei todellisuudessa pitäisi skaalata.

Jotkut näistä asioista voidaan vahvistaa vain ajan myötä. Aina on olemassa ensimmäiset pioneerit, yleensä teknisesti taitavimmat ihmiset ja erittäin uteliaat, ja sen jälkeen täytyy kokeilla sitä muiden segmenttien kanssa, niiden kanssa, jotka seuraavat varhaisia omaksujia ja sitten varhaista enemmistöä. Kun se on todistanut kykynsä siellä, kyllä, voit alkaa skaalata sitä ja laajentaa kyseisen käyttötapauksen muihin osastoihin.

Jokainen merkittävä mallijulkaisu voi aiheuttaa painetta organisaatiossa, jotta työntekijöille annettaisiin heti pääsy uusimpiin ominaisuuksiin. Miten teknologiajohtajien tulisi arvioida, edustaako uusi malli merkittävää parannusta vai onko se vain uuden kokeiluaallon ja kustannusten luomista?

Tässä on jälleen skeptinen optimismini. Oletetaan, että sinulla on jo malli käytössä ja useita tuhansia ihmisiä käyttävät tekoälyä päivittäin, eri mallit ja työkalut ovat jo saatavilla. Kun uusi malli julkaistaan, hypyn ja luonnollisen uteliaisuuden vuoksi voit odottaa, että kaikki haluavat kokeilla sitä, mikä on hyvä, mutta tuo kokeilu ei välttämättä ole ohjattua tai suuntautunutta kohti mitään erityistä tulosta, eikä joskus edes pysty mittaamaan eroa.

Skaalassa tämä on merkittävää. Kyse ei ole vain yhdestä tai kahdesta henkilöstä, jotka kurkistavat nähdäksensä, miten uusi malli suoriutuu vanhaan verrattuna. Se voi olla tuhansia ihmisiä, jotka käyttävät aikaa kokeiluun, vaikka tietyn käyttötapauksen tulos ei olisikaan kovin merkittävä. Samanaikaisesti, jos jokin toimii todella hyvin, oppiminen siitä, mikä organisaatiossasi toimii, ei välttämättä ole selkeästi selitetty tai näkyvissä kaikille.

Siksi ensimmäinen ryhmä, joka arvioi uutta mallia, ei saisi olla koko organisaatio. Sen tulisi olla T&K‑ryhmä, joka tekee tiivistä yhteistyötä asiaankuuluvien tiimien sekä oikeudellisen ja turvallisuusosaston kanssa. Arvioimme mallin kattavasti, teemme nopean arvioinnin ja sen jälkeen tuomme sen laajemmalle yleisölle kommenttien ja ohjeiden kera koskien turvallisuutta, sääntöjen noudattamista ja teknologiaa. Kun uudet mallit ja merkittävät päivitykset tulevat jatkuvasti, sinun täytyy olla valmis tähän malliin ja ajattelutapaan. Se ei todellakaan ole kertaluonteinen tai satunnainen harjoitus.

DataArt on luonut poikkitoiminnallisen “AI SWAT” -ryhmän, joka sisältää teknologiaa, oikeudellista, sääntöjen noudattamista, InfoSec‑tiimin ja muita ryhmiä. Miten tämä ryhmä toimii käytännössä, ja millaisia riskejä tai kysymyksiä on ratkaistava ennen kuin uusi tekoälytyökalu hyväksytään laajempaan käyttöön?

Sen perustamisesta lähtien mielestäni olemme asettaneet tälle ryhmälle erilaisia tavoitteita noin neljän tai viiden kuukauden välein. Muutamme prioriteettia, tavoitetta ja joskus tehtävää, ja monet näistä tavoitteista liittyvät tekoälyyn. Se voi olla työntekijöiden osaamisen kehittäminen, markkinoillemeno ja uudet kyvykkyydet, kumppanuudet tai tekoälyn laajempi mahdollistaminen organisaatiossa ja ADLC:n läpi.

Tarkat aihealueet kehittyvät ajan myötä, ja mielestäni se on terveellistä, koska sinun on jatkuvasti tarkistettava oma strategiasi, vahvistettava oletuksiasi ja ymmärrettävä, tarvitseeko tehdä suunnanmuutos ja mikä seuraava teema tiimille tulisi olla.

Ryhmä koostuu eri osastojen edustajista, ja yksi sen tarkoituksista on yksinkertaisesti pitää kaikki informoituna. Aina kun on uusi ilmoitus, kysymys tai mahdollisuus, joku voi tuoda aiheen yhteen säännöllisistä kokouksistamme. Vaikka se vaikuttaisi pelkästään kapealle tiimille relevantilta teknologia‑kysymykseltä, nykypäivänä nämä aiheet voivat vaikuttaa moniin organisaation osiin.

Siksi, kun arvioimme uutta kumppanuutta, työkalua tai kiihdyttämistä, keskustelemme siitä avoimesti, jotta kaikki ymmärtävät, mihin asiat ovat menossa, ja saavat mahdollisuuden esittää kysymyksiä tai antaa valvontaa. Uuden tekoälytyökalun osalta teknologia ei voi arvioida sitä eristyksissä. Turvallisuus, oikeudellinen ja sääntöjen noudattaminen tarvitsevat myös ymmärtää, miten se käsittelee yrityksen tai asiakkaan dataa, mitä rajoituksia on, ja voidaanko sitä käyttää turvallisesti mittakaavassa.

Joskus AI SWAT -tiimi työskentelee myös erityisohjelmien parissa, kuten osaamisen kehittämisen, jossa asetamme tavoitteita, laadimme tiekarttoja ja päätämme, miten eri ryhmät otetaan mukaan. Näin se todella toimii: pitää ihmiset informoituna, tehdä yhteistyötä erityisohjelmissa ja tarjota hallitukselle näkyvyyttä siitä, mitä tekoälyn kanssa tapahtuu koko yrityksessä.

Näet hyvin erilaisia asenteita AI-avusteista ohjelmistokehitystä kohtaan, joillakin organisaatioilla on aktiivisesti laajennettu agenttipohjaista kehitystä, kun taas toiset edelleen kieltävät AI:n luoman koodin. Mikä selittää tämän jakautuman, ja mitä on muutettava, ennen kuin riskitietoisemmat yritykset tuntevat olonsa mukavaksi, kun tekoäly näyttelee suurempaa roolia ohjelmistosuunnittelussa?

Luultavasti sen, mikä ajaa eron niiden välillä, jotka sanovat ei, ja niiden, jotka sanovat kyllä, on heidän riskinsietokykynsä ja asenteensa epäselvyyttä ja epävarmuutta kohtaan. Molempia organisaatioita auttavat jatkuva koulutus, kokeilu ja arviointi. Vaikka monien niiden organisaatioiden joukossa, joiden kanssa työskentelemme ja jotka omaksuvat tekoälyn ja sisällyttävät sen kaikkialle, on edelleen haasteita tulosten ja vaikutusten mittaamisessa. Rehellisesti sanottuna kysymys siitä, miten mittaat tekoälyn vaikutusta ja miten arvioit tiimin suorituskykyä, tulee joskus melkein kuin kukaan ei olisi aiemmin siitä ajatellut.

Kun alat arvioida AI-hanketta perusteellisemmin, alat ymmärtää sen vaikutuksen ja todellisen arvon, mikä johtaa parempiin päätöksiin siitä, missä teknologia on järkevää. Yrityksille, jotka sanovat ei AI:lle, on silti oltava jatkuva prosessi tarkastella, mitä teknologia voi tehdä ja missä se tällä hetkellä seisoo. Et halua, että kolme vuotta sitten tehty päätös pysyy yrityskäytäntönä pelkästään siksi, että kukaan ei ole tarkastellut sen taustalla olevia oletuksia uudelleen.

Agenttinen AI tekee yhä helpommaksi yksittäisten tiimien luoda omia agentejaan, mikä voi johtaa siihen, että useat agentit suorittavat lähes identtisiä tehtäviä. Missä vaiheessa kokeilu muuttuu agenttien leviämiseksi, ja millaista hallintakerrosta tarvitaan omistajuuden, käyttöoikeuksien, kaksoiskappaleiden ja elinkaaren hallintaan?

Kun näemme tyypillisen tilanteen, jossa AI-lisenssi annetaan jokaiselle kehittäjälle ja kokeilu muuttuu ohjaamattomaksi, kaikki alkavat luoda omia ratkaisujaan ja työskennellä omalla tavallaan. Tämä johtaa yleensä alisuoriin tiimeihin, odotusten alittamiseen, laadun viivästymiseen ja kasvaviin kuluihin. Lopputulos on, että se ei tee sitä, mitä kaikki odottavat sen tekevän, laatu on huono ja siitä tulee kallista. Tämän lieventämiseksi sen on oltava tiimityötä, joka on osa laajempaa osasto- tai organisaatiotoimintaa, ja juuri tähän hallinto tulee mukaan.

Projektitasolla voitte sopia tietopohjasta ja kontekstista sekä käyttötapauksista, joissa AI:ta alkaa hyödyntää. Sen jälkeen luodaan taitoja ja agenteja, jotka ovat osa kehitysprosessia ja joita kaikki voivat uudelleenkäyttää, jolloin kerätään tietoa ja parhaita käytäntöjä sen sijaan, että ne luotaisiin alusta alkaen joka kerta. Tämä projektitasoinen ponnistus tulisi sitten orkestroimaan esimerkiksi yritysarkkitehtuurilautakunnan, teknologia‑ryhmän, CTO:n tai AI:n käyttöönotosta vastaavan tiimin toimesta. Halutaan uudelleenkäyttää hyvin toimivia agenteja, varmistaa prosessin vankkuus ja saada se toimimaan koko organisaatiossa sen sijaan, että siitä tulisi kaaosta ja melua.

Joten mielestäni sen on oltava synkronoitu ponnistus projektitasolla, mahdollisesti ohjelmatasolla, ja sitten myös osasto- ja organisaatiotasoilla.

Token‑kulutus ja inferenssikustannukset voivat vaikuttaa suhteellisen pieniltä pilotissa, mutta muuttua merkittäviksi, kun AI‑järjestelmiä otetaan käyttöön tuhansien työntekijöiden tai autonomisten agenttien keskuudessa. Miten yritysten tulisi ajatella AI‑kustannusten hallintaa, ja odotatko, että AI‑työkuormille syntyy erityisesti FinOps‑malli?

Aloitan sanomalla, että lähes ihanteellinen tilanne on, kun AI‑kustannukset nousevat, saavuttavat tasanteen ja alkavat sitten hieman laskea ajan myötä. Tämä kertoo, että voit ennustaa, hallita kustannuksia, ymmärtää, mihin todella kulutat AI:hin, ja nähdä tekemiesi päätösten tulokset. Huonot tilanteet ovat, kun kustannukset jatkuvasti nousevat ja laskevat, koska se yleensä merkitsee, että jokin ei ole kestävää, tai kun kustannukset nousevat ja sitten pudottavat täysin, koska käyttöönotto ei ehkä tapahdu, jokin ei toimi, tai ihmiset käyttävät jotain muuta eikä sitä yksinkertaisesti näe.

Joten FinOps on olemassa, ja AI‑FinOps on myös olemassa. Jotkut tekniikat ovat hyvin teknisiä, kun taas toiset ovat melko yksinkertaisia. Se voi olla niin perusasia kuin suosikkimallin valitseminen, jotta et aina turvaudu kalleimpaan, ja näiden päätösten kerroin kerrallaan alkaa säästää rahaa. Samalla kustannusten säästämisen ja hallinnan tunteminen on vain puolet yhtälöstä. FinOps, niin kuin näen sen, on disciplina ja metodologia, joka sisältää myös tuote‑ ja liiketoimintajohtajia, koska on määritettävä, mitä mitataan AI‑pyrkimyksiä arvioitaessa.

Joten kyllä, mielestäni AI‑FinOps on hyvä aihe AI‑SWAT‑tiimin kaltaiselle keskustelulle: kuinka paljon kulutat, kuinka paljon saat takaisin, miten hallitset sitä ja mistä mahdollisuudet löytyvät.

Monia yrityksiä pyydetään osoittamaan AI:n ROI, vaikka ne eivät ole koskaan luoneet luotettavaa lähtötilannetta siitä, kuinka tuottavia tiimit olivat ennen AI:n käyttöönottoa. Mitä organisaatioiden tulisi oikeasti mitata, jos ne haluavat selvittää, luoko AI merkittävää liiketoiminta‑arvoa?

Riippumatta siitä, millainen asenne sinulla on AI:ta kohtaan tai missä olet juuri nyt, ehkä käytät jo agenteja kaikkialla tai ehkä ajattelet, että ensi vuonna aloitat AI:n käytön – perustason määrittäminen on nykyään ehdoton vaatimus.

Metrikoita on useita luokkia. Jotkut ovat subjektiivisia, ja ne voivat olla pelkästään kehittäjiesi tai työntekijöidesi palautetta, koska työskentelet ihmisten kanssa ja on tärkeää ymmärtää, miten he kokevat AI:n arvon. Objektivisempia mittareita voivat olla mekaaniset tai synteettiset mittarit, vaikka kehottaisin kaikkia olemaan liikaa sidottuja niihin. Tarkoitan esimerkiksi koodikommitteja tai tarinapisteitä. Nämä mittarit osoittavat, että työtä tapahtui, mutta ne eivät oikeastaan näytä arvoa tai vaikutusta.

Merkittävämpiä ovat mittarit, jotka selittävät, kuinka nopeasti tai kuinka hyvin työ saatiin toimitettua. Mieti DORA‑mittareita, kuten läpimenoaikaa tai MTTR:ää, kuinka nopeasti voit toipua epäonnistumisesta, kuinka nopeasti voit korjata tuotantovirheen, tai miten nämä mittarit muuttuvat ajan myötä. Yksi luku ei kerro sinulle kehityskulkua. Yksi arkkitehdeistamme mainitsi äskettäin, että ohjelmistokehityksessä hyvä mittari voi olla myös se, kuinka luotettavia arviot ovat AI:n käyttöönoton kasvaessa, koska se kertoo näiden ponnistelujen kestävyydestä ja tiimien todellisesta tuottavuudesta. Sinun on myös seurattava kustannuksia, sillä jos puhut vain hyödyistä ilman, että ymmärrät, mitä niiden saavuttaminen maksaa, sinulla ei ole täyttä kuvaa.

Ohjelmistokehityksen ulkopuolella ajattelen asiaa samalla tavalla. Jokaisessa työnkulussa tai prosessissa on jokin työyksikkö ja jokin valmiusmääritelmä. Olipa kyse vaatimusten käsittelystä, asiakirjojen tarkastamisesta tai asiakaspyyntöjen hoitamisesta, määrittele, mitä toimitat, ja mittaa sitten, kuinka kauan se kesti ennen AI:ta, kuinka nopeasti ja kuinka hyvin voit tehdä sen nyt, ja mitä se maksaa. Tämä antaa sinulle hyvän lähtökohdan sekä peruslinjalle että mittariston rakenteelle.

DataArt on sisällyttänyt AI:n ohjelmiston toimituselinkaaren eri vaiheisiin esimerkiksi Artisyn‑aloitteiden kautta. Kun AI ottaa yhä enemmän toteutus-, testaus- ja työnkulutehtäviä, mitkä ohjelmistotekniikan osat ovat arvokkaampia ihmisille ja mitkä taidot ovat vaarassa tulla vähemmän merkityksellisiksi?

Voit käyttää AI:ta tehokkaasti kehityksessä vain, jos muistat, mitä hyvä tarkoittaa. Tarvitset tätä asiantuntemusta ohjaamaan agentteja, tarkistamaan tuloksia, asettamaan rajoituksia ja määrittelemään säännöt. Sinun on ymmärrettävä, mikä on paras käytäntö ja miltä hyvä arkkitehtuuri näyttää, sillä ilman tätä et välttämättä tiedä, mitä kehitetään, ja tämän asiantuntemuksen arvo nousee erittäin, erittäin merkittävästi.

Arkkitehtonisten mallien ymmärtäminen on tärkeää, samoin kuin sen, mikä on sopivaa tietyssä toimialassa, sovelluksessa tai ratkaisuluokassa. Sinun on tiedettävä, millainen arkkitehtuuri on hyvä juuri nyt ja millainen on edelleen hyvä, kun ratkaisu skaalautuu, sillä joskus sama arkkitehtuuri ei toimi ratkaisun tai alustan koko elinkaaren ajan.

Tasapaino siitä, mikä on sopivaa tietylle ratkaisulle, on inhimillinen osa. Tämä on maku, käsityöläisyys palveluissa ja ohjelmistokehityksessä. Sinun on tiedettävä, mitä teet, ja se perustuu myös asiakkaan ja toimialan ymmärtämiseen.

Mitkä taidot ovat vähemmän tärkeitä? Minun on todella vaikea sanoa, vaikka ehkä kuinka nopeasti pystyt kirjoittamaan koodia. Vitsailen, mutta koodia voidaan nyt luoda paljon, paljon nopeammin, ja tietyn kirjaston tai kielen erityistuntemus voidaan myös oppia paljon nopeammin AI:n avulla.

Olen nähnyt .NET‑kehittäjien siirtyvän Java‑kehittäjiksi erittäin nopeasti, ja viisi‑tai kymmenen vuotta sitten olisin sanonut, että tällainen mittakaavassa tapahtuva siirtyminen oli lähes mahdotonta. Nykyään se on mahdollista. Vahva seniorikehittäjä voi yhä enemmän siirtyä kielten välillä, koska olennaista on heidän ymmärryksensä teknologiasta, arkkitehtuurista, ratkaisun parhaista käytännöistä, SDLC:stä ja ADLC:stä.

Kun yritykset siirtyvät kymmenistä AI‑pilotteista tuotantojärjestelmiin, jotka voivat itsenäisesti tehdä toimia, missä vastuullisuus lopulta tulisi olla, kun AI‑agentti tekee kalliin virheen: kehittäjän, liiketoiminnan omistajan, mallin tarjoajan, hallintotiimin vai niiden yhdistelmän?

Pidän sokean yhteistyön ja jaetun vastuullisuuden ideasta, koska jokainen organisaatiossa osallistuu parhaiden käytäntöjen, arkkitehtuurikehysten ja ratkaisujen luomiseen. Vaikka yksi kehittäjä luo koodia AI:n avulla tai ilman sitä, toinen kehittäjä tarkistaa sen, tiiminvetäjät antavat ohjausta, arkkitehdit tarjoavat arkkitehtuurin ja rajoitukset, ja hallintotiimi osallistuu päätöksiin budjeteista, aikatauluista ja julkaisuista. Kaikki ovat jotenkin mukana.

Usein, kun jokin menee pieleen, prosessi on se, joka ei toimi, joten siinä mielessä vastuullisuus on jaettu eri roolien kesken. Mutta jos vain sanot, että vastuullisuus on jaettu ja siten sokea, se ei riitä. Se on silti jaettava tarkemmin määriteltyihin vastuisiin.

Kehittäjät ovat vastuussa koodista, jonka he lähettävät pull‑requestina, ja heidän on ymmärrettävä, mitä siellä tapahtuu. Arkkitehdit ovat vastuussa tekemistään päätöksistä ja arkkitehtuuripäätöksistä, jotka annetaan agenteille ja kehittäjille. Alustatiimi on vastuussa ratkaisun luotettavuudesta riippumatta siitä, kuka tai mikä on luonut tietyn koodirivin.

Vastuullisuus on siis olemassa, mutta se on määriteltävä tarkasti tiimin, roolin ja osaston mukaan. Et voi pysäyttää analyysiä väitteeseen “AI teki tämän”. Sinun on kysyttävä, mitä valvontaa, testejä tai tarkastuksia salliivat kyseisen vian päätyä tuotantoon.

Jos yksikkötestien puute salli huonon koodin päätyä tuotantoon, tai valvonnan ja tarkastuksen puute salli sen tapahtua, et voi siirtää vastuuta AI:lle. Et myöskään voi syyttää pelkästään mallin tarjoajaa tai pilvipalvelun tarjoajaa jokaisesta bugista tai katkoksesta.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa käydä DataArt -sivustolla.