Teknologiajohtaja sanoo, että tekoäly tarvitsee uuden hallintamallin

Tyrone Grandison on toiminut uransa 35 vuoden aikana useissa teknologia-alan johtotason tehtävissä, ja tällä hetkellä hän on Cornerstone Assurance Corporationin teknologiajohtaja. Hän on myös teosten The AI Revolution ja Culture That Lasts kirjoittaja.

Keskustelimme Tyronen kanssa siitä, miten tekoäly muuttaa teknologiaorganisaatioiden hallintaa. Tässä on, mitä hän kertoi meille.

35 vuotta teknologia-alalla

Johdan pientä teknologiaorganisaatiota, joka tukee kasvavaa vakuutus- ja rahoituspalveluyritystä nimeltä Cornerstone Assurance Corporation. Tehtävästä tekee erityisen kiinnostavan se, että rakennamme modernia teknologiaperustaa samalla, kun toimimme alalla, jolla on merkittäviä sääntelyvaatimuksia, arkaluonteisia taloustietoja, monimutkaisia integraatioita vakuutuksenantajiin ja hyvin vähän sietokykyä virheille.

Aloitin urani tietojenkäsittelytieteilijänä kauan ennen kuin tekoälystä tuli jokaisen johtoryhmän keskustelun ja konferenssin pääpuheenvuoron aihe. Vuosien varrella työni vei minut teknologian rakentamisesta organisaatioiden johtamiseen aikana, jolloin teknologia vaikutti niihin voimakkaasti. Olen toiminut tekoälyjohtajana, teknologiajohtajana, tietohallintojohtajana ja tietodatajohtajan sijaisena. Olen työskennellyt julkishallinnossa, akateemisessa maailmassa, startup-yrityksissä, konsultoinnissa, voittoa tavoittelemattomissa organisaatioissa ja suuryrityksissä.

35 teknologia-alalla vietetyn vuoden jälkeen minulla on ollut etuoikeus seurata, kuinka useita asioita on esitelty ”teknologiana, joka muuttaa kaiken”. Ja jotkin niistä todella muuttivatkin.

Jokainen suuri muutos pakottaa johtajat tekemään päätöksiä ennen kuin heillä on täydelliset tiedot. Se haastaa liiketoimintamallit, toimintamallit, kulttuurin, osaamisen, hallinnon ja joskus käsityksemme siitä, mitä omien tehtäviemme pitäisi olla. Tekoäly tekee kaiken tämän samanaikaisesti.

Mutta erityisen kiehtovaa tässä hetkessä on se, että olemme siirtyneet tekoälystä, joka auttaa meitä yksinkertaisesti analysoimaan tietoja, järjestelmiin, jotka pystyvät tuottamaan sisältöä, päättelemään, suunnittelemaan, luomaan, kirjoittamaan koodia, käyttämään työkaluja ja yhä useammin toimimaan itsenäisesti. Tämä muuttaa johtamiseen liittyvää keskustelua perusteellisesti.

Aiemmin kysyttiin: ”Mihin tekoäly pystyy?”

Mielestäni siitä on nopeasti tulossa vähiten kiinnostava kysymys. Jopa väärä kysymys.

Paljon tärkeämpiä kysymyksiä ovat: Mitä meidän pitäisi antaa sen tehdä? Missä ihmisen harkinta on edelleen välttämätöntä? Miten organisaatiot pitäisi suunnitella uudelleen, kun oivalluksista tulee ylenpalttisen runsaita? Ja miten voimme hyödyntää tämän teknologian poikkeuksellisen potentiaalin luomatta riskejä, joita emme ymmärrä, tai järjestelmiä, joita emme pysty hallitsemaan?

Tähän työni tällä hetkellä keskittyy. Työskentelen johtajien ja organisaatioiden kanssa auttaakseni heitä erottamaan tekoälyyn liittyvän huomattavan kohinan keskeltä olennaisen, ymmärtämään, mikä todella muuttuu, ja muuttamaan tämän ymmärryksen strategiaksi, hallinnoksi, tuotteiksi ja mitattaviksi liiketoimintatuloksiksi.

Miten tekoäly muuttaa ohjelmistokehityksen elinkaaria

Yksi suurimmista Cornerstone Assurance Corporationissa tekemistäni muutoksista oli ohjelmistokehityksen elinkaaren uudistaminen sen oletuksen pohjalta, että tekoäly kirjoittaa merkittävän osan koodistamme.

Ennen tätä muutosta noudatimme melko perinteistä ohjelmistokehityksen työnkulkua. Kehittäjä otti vaatimuksen käsiteltäväkseen, suunnitteli ratkaisun, kirjoitti koodin, loi testit, lähetti yhdistämispyynnön, ja toinen insinööri tarkisti sen. Hyödynsimme tietenkin automaatiota, mutta ihmiset tekivät edelleen suurimman osan vaatimuksesta käyttöönottoon ulottuvasta ajattelutyöstä.

Tekoäly muutti tämän mallin taloudellisen perustan täysin.

Niinpä otimme käyttöön tekoälyavusteisen kehitysputken, jossa GitHub Copilotia käytetään koodin tuottamiseen ja uudelleenmuotoiluun, ChatGPT:tä ja Claudea tekoälyavusteiseen arkkitehtuurin tutkimiseen, vaatimusten jakamiseen osiin, virheenkorjaukseen ja testitapausten luomiseen. Tavalliset jatkuvan integraation ja jatkuvan toimituksen sekä tietoturvan työkalumme tarjoavat tekoälyn tuottaman työn ympärille deterministiset valvontamekanismit.

Miksi tekoälyn tuottama koodi edellyttää uutta hallintamallia

Mutta tärkeä muutos ei ollut se, että ”Hei kaikki, teillä on nyt Copilot.” Muutimme hallintamallia.

Hyväksyntävaiheet

Käsittelemme tekoälyn tuottamaa koodia nykyään lähes samalla tavalla kuin erittäin nopean juniorikehittäjän lähettämää koodia: tämä kehittäjä ei koskaan nuku, on lukenut järjettömän määrän dokumentaatiota ja sanoo toisinaan täysin vääriä asioita suunnattoman itsevarmasti.

Tämä tarkoittaa, että tekoäly voi tuottaa koodia, yksikkötestejä, API-sopimuksia, dokumentaatiota, tietokantakyselyitä, infrastruktuurin määrityksiä ja ehdotettuja korjauksia, mutta se ei voi hyväksyä omaa työtään tai päästä hallitsemattomasti tuotantoon.

Otimme käyttöön ihmisen suorittamat hyväksyntävaiheet tietoturvan kannalta arkaluonteisille muutoksille, tunnistautumiselle ja valtuutuksille, asiakas- ja taloustietojen käsittelylle, ulkoisille integraatioille sekä tuotantoinfrastruktuurille.

Automaattinen testaus

Laajensimme myös automaattista testausta ja koodikatselmointeja, koska pullonkaula siirtyi. Kun tekoäly kasvattaa dramaattisesti koodin tuottamisen nopeutta, ongelmasi ei enää ole koodin luominen. Ongelmasi on sen osoittaminen, että koodi ansaitsee tulla suoritetuksi.

Yksinkertainen esimerkki on testien luominen. Aiemmin insinööri saattoi toteuttaa ominaisuuden ja kirjoittaa sitten ilmeiset yksikkötestit. Nyt voimme pyytää tekoälyä luomaan vastakkaisasetteluun perustuvia testitapauksia myös. Mitä tapahtuu virheellisen syötteen kohdalla? Mitä tapahtuu, kun API palauttaa odottamattoman vastauksen? Mitä tapahtuu käyttöoikeusrajalla? Mitä tapahtuu, kun asiakastietue sisältää puutteellisia tietoja?

Tämä antaa insinöörille uudenlaisen tehtävän. Sen sijaan, että hän käyttäisi kaiken aikansa tuotosten tekemiseen, hän käyttää enemmän aikaa oletusten haastamiseen ja koodin toiminnan validointiin.

Tekoälyn hallinta

Muutimme myös itse tekoälyn hallintatapaamme. Kirjaamme tekoälyavusteisen toiminnan tarvittaessa, pidämme arkaluonteiset asiakastiedot poissa kuluttajille tarkoitetuista tekoälytyökaluista, hallitsemme, mitkä mallit ja palvelut voivat käyttää yrityksen tietoja, ja pidämme kokeilut erillään tuotantokäyttöoikeuksista. Vakuutus- ja rahoituspalveluissa ”malli ajatteli tämän olevan hyvä idea” ei koskaan muodosta hallintastrategiaa.

Miten tekoäly siirtää ohjelmistokehityksen pullonkaulaa

Suurin tekoälyn integroimisesta ohjelmistokehityksen työnkulkuihimme saamani hyöty on nopeus, mutta lisään vastaukseeni aina varauksen, koska väärään suuntaan kulkeva nopeus ei ole tuottavuutta.

Tekoäly on lyhentänyt kehityssykliämme huomattavasti. Näemme työn, jonka tekemiseen kehittäjältä kului aiemmin useita päiviä, siirtyvän vaatimuksesta testattavaksi toteutukseksi tunneissa. Erityisesti prototyyppien osalta arvioisin, että olemme lyhentäneet läpimenoaikaa noin 50–70 prosenttia.

Dokumentaatio on todennäköisesti tuottanut vähiten näyttävän mutta välittömimmän tehokkuushyödyn. API-dokumentaation, julkaisutietojen, testidokumentaation, koodin selitysten ja teknisten määritysten ensimmäisten luonnosten ei enää tarvitse alkaa vilkkuvasta kursorista. Tekoäly tuottaa ensimmäiset 70–80 prosenttia, ja tiimini käyttää aikansa korjaamiseen ja parantamiseen sen sijaan, että loisi kaiken alusta asti.

Mutta tällä on myös kääntöpuolensa, ja mielestäni teknologiajohtajien pitäisi puhua siitä enemmän: tekoälyn avulla huonon koodin tuottaminen nopeasti on uskomattoman halpaa.

Huomasimme, että rajoittava tekijä siirtyy myöhempään vaiheeseen. Jos pystyn tuottamaan viisinkertaisen määrän koodia, mutta ihmisten on edelleen ymmärrettävä, katselmoitava, testattava, suojattava, otettava käyttöön, valvottava ja ylläpidettävä sitä, en ole välttämättä kasvattanut järjestelmän läpimenoa. Olen saattanut vain luoda ruuhkan koodikatselmointiin.

Se on todennäköisesti ollut minulle arvokkain oppitunti. En enää optimoi ohjelmistokehitysorganisaatiotani ensisijaisesti sen mukaan, kuinka nopeasti pystymme kirjoittamaan ohjelmistoja. Tekoäly tekee tästä osasta nopeasti hyödykkeen. Optimoin sen mukaan, kuinka nopeasti pystymme osoittamaan ohjelmiston ansaitsevan tulla suoritetuksi tuotannossa. Kyseessä on hyvin erilainen ohjelmistokehitysorganisaatio.

Missä tekoälyllä on puhevalta ja missä äänivalta

Olen suhtautunut melko tietoisesti kahden asian erottamiseen toisistaan: missä AI saa äänensä kuuluviin ja missä AI saa äänestää. Organisaatiossamme AI:lla on nykyään ääni lähes kaikissa teknologiakehityksen elinkaaren vaiheissa. Se ei kuitenkaan saa äänivaltaa jokaisessa päätöksessä.

Joitakin esimerkkejä:

• Arkkitehtuuri: Käytämme ChatGPT:tä ja Claudea arkkitehtuurin sparrauskumppaneina. Jos suunnittelemme uutta palvelua, voin antaa mallille vaatimuksemme, rajoitteemme, olemassa olevat rajapinnat, tietoturvarajat, odotetun tapahtumamäärän ja vikatilanteet. Pyydän sitä ehdottamaan useita arkkitehtuureja, tunnistamaan kompromissit, haastamaan oletuksemme ja jopa argumentoimaan omaa suositustaan vastaan. En kuitenkaan kysy: ”Mitä arkkitehtuuria meidän pitäisi käyttää?” ja rakenna sitten sitä, mitä vastaukseksi tulee. Lopullinen arkkitehtuuripäätös pysyy ihmisillä, koska arkkitehtuuriin liittyy konteksti, joka ulottuu paljon teknistä optimointia laajemmalle. Minun on otettava huomioon liiketoimintastrategiamme, sääntelyvelvoitteemme, toiminnallinen kypsyytemme, riskinsietokykymme, kustannukset, tekninen velka ja se, mitä tiimini pystyy käytännössä tukemaan kello 2.00 aamuyöllä.
• Koodi: Annamme AI:lle tässä huomattavasti enemmän liikkumavaraa. Käytämme GitHub Copilotia koodin tuottamiseen, uudelleenjärjestelyyn, dokumentointiin ja yksikkötestien luomiseen. Käytämme myös ChatGPT:tä ja Claudea vikojen selvittämiseen, toteutustapojen tutkimiseen ja vastakkaisasetteluun perustuvien testitapausten tuottamiseen. AI pystyy kirjoittamaan ensimmäisen toteutuksen uskomattoman nopeasti. Ihmisinsinööri vastaa silti pull-pyynnöstä ja hyväksyy sen, mikä lopulta yhdistetään koodikantaan.
• Testaus: Tämä on luultavasti siirtynyt kaikkein pisimmälle AI:n suuntaan. Pidän siitä, että voin kysyä AI:lta: ”Miten rikkoisit tämän?” Voimme löytää tapauksia, jotka ominaisuuden rakentamiseen juuri kaksi päivää käyttänyt kehittäjä saattaisi tiedostamattaan jättää huomiotta. AI:sta tulee erittäin edullinen ja äärimmäisen sinnikäs vastustaja.
• Tietoturva: Tässä kohtaa käännän yhtälön tarkoituksellisesti toisinpäin. AI auttaa meitä tunnistamaan haavoittuvuuksia, tarkastelemaan koodimalleja, mallintamaan uhkia ja tuottamaan hyökkäysskenaarioita, mutta kuten sanoin, ihmisillä säilyy päätösvalta tietoturvan hyväksymisestä, identiteetti- ja käyttöoikeuspäätöksistä, arkaluonteisten tietojen käsittelystä ja poikkeuksista. Kehotteen injektointi ja arkaluonteisten tietojen paljastuminen ovat edelleen tunnistettuja riskejä suurten kielimallien sovelluksissa, joten AI:n yhdistäminen yritysjärjestelmiin edellyttää enemmän valvontatoimia, ei vähemmän.
• Häiriötilanteisiin reagointi: Tämä sijoittuu jonnekin keskivaiheille. AI voi käsitellä lokeja, yhdistää tapahtumia, tiivistää tuhansia rivejä telemetriatietoja, ehdottaa todennäköisiä perimmäisiä syitä ja suositella korjaavia toimia. Tämä voi lyhentää häiriön ensimmäisiä 30 minuuttia huomattavasti. Mutta jos joku haluaa poistaa tuotantopalvelun käytöstä, palauttaa kriittisen käyttöönoton aiempaan versioon, muuttaa tietoturvakäytäntöä tai tehdä toimenpiteen, joka vaikuttaa asiakkaisiin, päätöksen tekee ihminen.
• Työjonon priorisointi: Käytän tässä samaa sääntöä. AI voi analysoida tukipyyntöjä, teknistä työmäärää, riippuvuuksia, tuotteen käyttöä ja liiketoimintatavoitteita ja sanoa: ”Näin priorisoisin nämä 40 asiaa ja tässä ovat perusteluni.” Se on uskomattoman hyödyllistä. AI ei kuitenkaan ymmärrä strategiaamme paremmin kuin me. Tuote- ja teknologiajohtajat tekevät lopullisen priorisointipäätöksen.

Sääntöni on siis melko yksinkertainen: AI saa enemmän autonomiaa, kun toimenpide on peruttavissa, havaittavissa, testattavissa ja vaikutuksiltaan vähäinen. Ihmisen päätösvalta kasvaa, kun toimenpidettä on vaikeampi perua tai kun sillä on suurempi vaikutus asiakkaisiin, talouteen, tietoturvaan, sääntelyyn tai maineeseen.

Käytännönläheinen suunnittelutyön työnkulku

Tässä on esimerkki työnkulusta, jossa ”vaatimuksesta tuotantoon AI:n ollessa mukana”. Oletetaan, että meidän on lisättävä uusi toiminnallisuus agentin työnkulkuun, joka hakee asiakas- ja vakuutustietoja, soveltaa liiketoimintasääntöjä ja suosittelee sopivaa seuraavaa toimenpidettä:

1. Kaikki alkaa vaatimuksesta. Sen sijaan että insinööri vastaanottaisi ylimalkaisesti kirjoitetun työpyynnön ja alkaisi heti koodata, käytämme ChatGPT:tä tai Claudea vaatimuksen tarkentamiseen. Annamme sille käyttäjätarinan, hyväksymiskriteerit, olennaiset liiketoimintasäännöt, API-sopimukset ja tekniset rajoitteet. Sitten pyydämme sitä tunnistamaan epäselvyydet, puuttuvat poikkeustapaukset, riippuvuudet, tietoturvaan liittyvät huolenaiheet sekä kysymykset, joihin meidän tulisi vastata ennen kuin kukaan kirjoittaa koodia. Tämä kuulostaa yksinkertaiselta, mutta se paljastaa yllättävän paljon kallista sekaannusta jo varhaisessa vaiheessa.
2. Seuraavaksi vuorossa ovat arkkitehtuuri ja tehtävien jakaminen. Käytämme Claudea ja ChatGPT:tä toteutusvaihtoehtojen tutkimiseen ja vaatimusten jakamiseen komponenteiksi. Malli saattaa tunnistaa API-muutoksen, tietomallin muutoksen, integraatioriippuvuuden, valtuutusvaatimukset, telemetrian ja tarvittavat testitapaukset. Pyydämme sitä myös perustelemaan, miksi sen ehdottama arkkitehtuuri ei toimisi. Ihmisinsinööri tekee arkkitehtuuripäätöksen. Tekoäly tarjoaa vaihtoehtoja. Me vastaamme seurauksista.
3. Sitten siirrymme toteutukseen. Käytämme GitHub Copilotia kehitysympäristössä vakiokoodin luomiseen, hyvin määriteltyjen funktioiden toteuttamiseen, koodin uudelleenjärjestelyyn, API-asiakkaiden luomiseen, koodikannan tuntemattomien osien selittämiseen ja dokumentaation tuottamiseen. Insinööri siirtyy jokaisen rivin kirjoittamisesta toteutuksen ohjaamiseen, tarkistamiseen ja hiomiseen. Tällä erolla on merkitystä. En halua kehittäjistä tulevan erittäin kalliita automaattisen täydennyksen käyttäjiä. Haluan heidän ajattelevan järjestelmää.
4. Sitten annamme ChatGPT:lle tai Claudelle vaatimuksen ja toteutuksen ja sanomme käytännössä: ”Hienoa. Riko se nyt.” Tekoäly auttaa tuottamaan vastakkainasetteluun perustuvia skenaarioita, ja Copilot auttaa muuttamaan ne automatisoiduiksi yksikkö- ja integraatiotesteiksi.
5. Sitten deterministinen koneisto ottaa vallan. Pull request siirtyy CI/CD-putkeemme. Suoritamme automatisoidut testit, staattisen analyysin, riippuvuus- ja haavoittuvuustarkistukset sekä tavanomaiset laatukynnyksemme. Ihmisinsinööri tarkistaa pull requestin.
6. Sitten otamme muutoksen käyttöön vaiheittain. Muutos etenee kehitysympäristön ja testiympäristön kautta tuotantoon. Käytämme tarvittaessa ominaisuuslippuja tai hallittuja käyttöönoton malleja, jotta voimme rajoittaa vaikutusalaa, seurata toimintaa ja palauttaa muutoksen nopeasti.
7. Eikä tekoälyn työ ole vieläkään valmis. Kun ominaisuus on käytössä, tekoälystä tulee havainnointiavustaja. Käytämme sitä lokien tiivistämiseen, virhemallien yhdistämiseen, odottamattoman toiminnan analysointiin ja insinöörien auttamiseen siirtymisessä ”jokin on vialla” -tilanteesta uskottavaan perimmäiseen syyhyn paljon nopeammin.

Miten tekoäly muuttaa insinöörityön toimintatapoja

Olisinpa ymmärtänyt aiemmin, että tekoälytyökalujen antaminen insinööreille on helppoa. Insinöörityön toimintatapojen muuttaminen on vaikea osa.

Kun aloimme ensimmäisen kerran käyttää GitHub Copilotin, ChatGPT:n ja Clauden kaltaisia työkaluja, lähestyin käyttöönottoa samalla tavalla kuin monet teknologiajohtajat. Annetaan lahjakkaille insinööreille tehokkaat työkalut, luodaan järkevät suojakaiteet ja odotetaan tuottavuuden kasvavan.

Niin kävikin, mutta ei yhdenmukaisesti eikä aina odottamillani tavoilla.

Ensimmäinen oppimani asia oli, että käyttöoikeus ei tarkoita käyttöönottoa, eikä käyttöönotto tarkoita pätevyyttä.

Kahdella insinöörillä voi olla täsmälleen sama tekoälytyökalu ja silti täysin erilaiset tulokset. Toinen käsittelee tekoälyä automaattisena täydennyksenä ja säästää muutaman näppäinpainalluksen. Toinen oppii antamaan kontekstia, pilkkomaan ongelmia, haastamaan tuloksia, luomaan testejä, tutkimaan vaihtoehtoja ja käyttämään mallia teknisenä ajatustenvaihtokumppanina. Näiden kahden ihmisen välinen tuottavuusero voi kasvaa valtavaksi.

Olisin investoinut tekoälylukutaitoon ja työskentelytapoihin paljon aiemmin. En tarkoita ”tässä on kahden tunnin kehotesuunnittelukurssi” -tyyppistä lähestymistapaa, vaan käytännön esimerkkejä, jotka perustuvat todelliseen insinöörityöhömme.

Tyronen kommentit

Olisin investoinut tekoälylukutaitoon ja työskentelytapoihin paljon aiemmin. En tarkoita ”tässä on kahden tunnin kehotesuunnittelukurssi” -tyyppistä lähestymistapaa, vaan käytännön esimerkkejä, jotka perustuvat todelliseen insinöörityöhömme.

Miten tekoäly muuttaa teknologiajohtamista

Käytämme paljon aikaa kysyen, mitä tekoäly tekee kehittäjille, arkkitehdeille, analyytikoille ja muissa teknisissä tehtävissä työskenteleville. Mielestäni CTO:iden on käännettävä tämä kysymys toisinpäin ja kohdistettava se itseemme.

Suurimman osan urastani teknologiajohtamisessa minua on palkittu siitä, että tiesin asioita, joita muut eivät tienneet. Kokemus antoi kyvyn tunnistaa toimintamalleja. Tekninen asiantuntemus antoi auktoriteettia. Pystyit astumaan huoneeseen ja antamaan vastauksen, jonka löytäminen olisi voinut viedä joltain toiselta päiviä.

Nyt voin antaa kaikkien käyttöön uskomattoman kyvykkään tekoälyjärjestelmän. Se muuttaa johtamista.

En enää ajattele, että arvoni CTO:na tulee vastausten tietämisestä. Arvoni syntyy parempien kysymysten esittämisestä, kontekstin tarjoamisesta, kompromissien tekemisestä, harkintakyvyn käyttämisestä ja sellaisen ympäristön luomisesta, jossa ihmiset ja koneet tekevät toisistaan parempia.

Se vaatii nöyryyttä. Tekoäly tunnistaa joskus lähestymistavan, jota en tullut ajatelleeksi. Nuorempi insinööri, jolla on erinomaiset tekoälytaidot, saattaa kyseenalaistaa oletuksen, jota 25 vuoden kokemuksen omaava henkilö pitää itsestään selvänä. Mielestäni erinomaisten teknologiajohtajien on otettava tällainen vastaan.

Tekoälyn aikakauden CTO ei voi olla yksinkertaisesti huoneen älykkäin tekninen henkilö. Meidän on ryhdyttävä ihmisiksi, jotka suunnittelevat huoneen. Kuka saa äänensä kuuluviin? Mitä tekoäly saa päättää? Missä ihmisen harkinta on edelleen välttämätöntä? Mistä tiedämme, milloin olemme väärässä?

Siinä on johtamisen muutos.

Miksi CTO:iden tulisi suhtautua tehokkuushyötyihin varovaisesti

Suurin neuvoni CTO:ille tällä hetkellä on tämä: Älä sekoita nopeaa etenemistä edistymiseen.

Teknologiajohtajiin kohdistuu valtava paine “tehdä jotain tekoälyllä”. Hallitukset kysyvät siitä. Toimitusjohtajat kysyvät siitä. Työntekijät käyttävät sitä jo, olipa teillä käytäntöä sen suhteen tai ei. Jokainen toimittaja on yhtäkkiä huomannut, että heidän tuotteensa on ollut “tekoälypohjainen” koko ajan.

Reaktiiviseksi ryhtyminen on hyvin helppoa. Mutta mielestäni CTO:n tehtävänä on tällä hetkellä luoda selkeyttä kaiken tämän melun keskellä.

• Ensimmäiseksi käytä teknologiaa itse. Ja tarkoitan todella sen käyttämistä. Älä rakenna tekoälystrategiaasi kokonaan analyytikkoraporttien ja toimittajien esittelyjen varaan. Käytän ChatGPT:n, Clauden ja GitHub Copilotin kaltaisia työkaluja, koska tarvitsen omakohtaista kokemusta siitä, missä ne ovat poikkeuksellisen hyviä, missä ne epäonnistuvat ja kuinka nopeasti nämä rajat muuttuvat. Et voi johtaa tehokkaasti teknologista muutosta, jonka koet vain PowerPointin kautta.
• Toiseksi aloita liiketoiminnan rajoitteista, älä tekoälyn kyvykkyyksistä. Olen paljon vähemmän kiinnostunut kysymään: “Missä voimme käyttää generatiivista tekoälyä?” kuin kysymään: “Missä olemme hitaita, kalliita, epäjohdonmukaisia tai kapasiteetiltamme rajoittuneita tai missä asiakkaat turhautuvat?” Sen jälkeen voin määrittää, kuuluuko tekoäly todella ratkaisuun.
• Kolmanneksi korjaa perustasi. Tekoäly ei pelasta huonoa dataa, heikkoja ohjelmointirajapintoja, puutteellista havainnointia, olematonta dokumentaatiota tai toimimattomia ohjelmistokehityksen käytäntöjä. Se usein vahvistaa niitä. Tekoäly toimii taustalla olevan organisaation ja teknisen järjestelmän vahvistimena.
• Neljänneksi suunnittele hallinta seurausten, älä pelon ympärille. En halua 47-sivuista tekoälyohjetta, joka käytännössä sanoo: “Älä tee mitään kiinnostavaa.” Haluan riskin suhteuttamia valvontakeinoja. Anna ihmisten kokeilla rohkeasti silloin, kun toimet ovat peruttavissa ja niiden seuraukset vähäisiä. Lisää ihmisen valvontaa, kun päätökset alkavat vaikuttaa asiakastietoihin, rahaan, turvallisuuteen, sääntelyvelvoitteisiin tai tuotantojärjestelmiin.
• Viidenneksi, ja tämä saattaa olla tärkein kohta, suunnittele työ uudelleen sen sijaan, että vain lisäät tekoälyn osaksi työtä. Jos kehitysprosessissani on kaksitoista vaihetta ja tekoäly tekee vaiheesta neljä 70 prosenttia nopeamman, en ole muuttanut ohjelmistokehitystä. Olen nopeuttanut vaihetta neljä.
• Ja lopuksi suojele ihmisen harkintaa ja poista samalla ihmisten puuduttavat rutiinityöt mahdollisimman tehokkaasti.

Mielestäni CTO:illa on tällä hetkellä harvinainen mahdollisuus. Älä kysy vain, miten tekoäly tekee nykyisestä organisaatiostasi tehokkaamman. Kysy, millaisen organisaation rakentaisit, jos aloittaisit tänään. Se on epämukavampi kysymys. Se erottaa myös yritykset, jotka yksinkertaisesti käyttävät tekoälyä, yrityksistä, jotka todella muuttuvat sen ansiosta.

Seuraa mukana

Voit seurata Tyrone Grandisonin työtä LinkedInissä ja hänen henkilökohtaisella verkkosivustollaan. Voit myös tutustua hänen kirjoihinsa Tekoälyvallankumous ja Kestävä kulttuuri.

Lisää asiantuntijahaastatteluja on tulossa The CTO Clubiin!