Globaali kenttä-CTO kehottaa johtajia keskittymään data-infrastruktuuriin ennen tekoälyä

Kai Waehner on Confluentin maailmanlaajuinen kenttä-CTO, ja hän on neuvonut suuria yrityksiä, kuten BMW:tä ja Siemensia. Hänen painopistealueitaan ovat datainfrastruktuuri, integraatiostrategia ja tekoälyn käyttöönotto.

Haastattelimme Kaita ymmärtääksemme, miksi niin monet yritysten tekoälyhankkeet epäonnistuvat. Tässä hänen näkemyksensä.

Kaavojen tunnistamisen etu

Nimeni on Kai Waehner. Olen toiminut viimeiset yhdeksän vuotta Confluentin maailmanlaajuisena kenttä-CTO:na ja työskennellyt satojen yritysten kanssa Pohjois-Amerikassa, Euroopassa ja Aasian ja Tyynenmeren alueella. Olen neuvonut BMW:n, Volkswagenin, Lufthansan, Siemensin, DISH Networksin ja Globe Telecomin kaltaisia yrityksiä. Työskentelen johtajien kanssa teknologiastrategian, markkinoillemenon toteutuksen, toimittajien arvioinnin, yritysarkkitehtuurin ja sisällöntuotannon parissa.

Kenttä-CTO:n rooli eroaa yhden teknologiaorganisaation johtamisesta. Työskentelen samanaikaisesti kymmenien asiakasympäristöjen parissa ja neuvon arkkitehteja sekä ylimmän johdon johtajia datainfrastruktuurista, integraatiostrategiasta ja tekoälyn käyttöönotosta. Tämä laaja-alaisuus antaa minulle kaavojen tunnistamisen edun, jota on vaikea saavuttaa yhden yrityksen sisältä käsin.

Taustani kattaa yritysten dataintegraation koko historian: ETL:n, ESB:n, iPaaS:n ja API-hallinnan, minkä jälkeen keskityin yhdeksän vuoden ajan datan suoratoistoon, jossa Apache Kafka ja Flink toimivat tapahtumapohjaisten arkkitehtuurien perustana. Viime aikoina olen keskittynyt yhä enemmän prosessien orkestrointiin ja tekoälyyn koko kirjolla ennakoivasta koneoppimisesta generatiiviseen ja toiminnalliseen tekoälyyn. Esittelen näkemyksiäni säännöllisesti Gartnerin ja Forresterin analyytikoille ja julkaisen omaa tutkimustani, joka käsittelee toimittajakenttiä, arkkitehtuurimalleja ja käytännön tapaustutkimuksia eri toimialoilta. Olen myös julkaissut kirjan datan suoratoistosta.

Teknologiajohtajien kanssa käymäni keskustelu tekoälymuutoksesta ei ensisijaisesti koske malleja. Se koskee niiden alla olevaa infrastruktuuria. Jotta autonomisia toimia yritysten työnkuluissa toteuttavat toiminnalliset tekoälyjärjestelmät toimisivat luotettavasti, ne tarvitsevat kolme asiaa:

• reaaliaikaista dataa, jotta ne toimivat ajantasaisen todellisuuden pohjalta
• prosessitietoa, joka määrittää, mitä ne saavat tehdä
• arkkitehtuuriin sisäänrakennettua luottamusta, ei vain malliin perustuvaa luottamusta

Ajatteluni keskittyy tähän lähentymiseen.

Miksi arkkitehtuurikerrosten on lähennyttävä tekoälyn onnistumisen varmistamiseksi

Eri toimialoilla näen jatkuvasti, kuinka yritykset investoivat voimakkaasti kolmeen erilliseen kerrokseen: dataintegraation runkoon, prosessiautomaatiokerrokseen ja yhä useammin tekoälyhankkeeseen. Ongelmana on, että näitä kolmea ei juuri koskaan suunnitella toimimaan yhdessä. Dataintegraatio siirtää dataa, mutta ei yhdistä sitä liiketoimintapäätöksiin. Prosessiautomaatio valvoo työnkulkuja, mutta toimii vanhentuneen kontekstin varassa. Tekoälyagentit tuottavat suosituksia tai toteuttavat toimia, mutta niiltä puuttuu hallittu raja sille, mitä ne voivat tehdä. Kukin kerros toimii erillään. Yhdistetty arkkitehtuuri puuttuu.

Näkemäni käyttöönottomallit vaihtelevat huomattavasti. Jotkin organisaatiot käyttävät täysin hallittua pilvinatiivia infrastruktuuria AWS:n, Azuren tai GCP:n päällä, ja suuret kansainväliset yritykset sisältävät usein myös Manner-Kiinan käyttöönottoja Alibaba Cloudissa. Ne pidetään tarkoituksella erillään oikeudellisista, sääntelyyn liittyvistä ja tietosuojasyistä. Toiset käyttävät hybridiarkkitehtuureja, joissa paikalliset datakeskukset on yhdistetty pilveen. Tätä ohjaavat tietojen sijaintia koskevat vaatimukset tai vanhat järjestelmät, joita ei voida siirtää nopeasti. Säännellyillä toimialoilla, kuten rahoituspalveluissa ja terveydenhuollossa, on lähes aina usean alueen tai usean pilven vaatimuksia. Tämä ei johdu valinnasta vaan sääntelyn velvoitteista. Valmistavan teollisuuden asiakkailla on usein reunalaskennan käyttöönottoja, joissa data käsitellään lähellä tuotantolaitosta ennen sen keskitettyä kokoamista.

Kaikissa näissä ympäristöissä tapahtumapohjaisesta arkkitehtuurista on tullut liiketoimintakriittistä infrastruktuuria. Apache Kafkasta on muodostunut tosiasiallinen standardi järjestelmien todelliseen irtikytkentään, reaaliaikaiseen käsittelyyn missä tahansa mittakaavassa sekä hybridi- ja monipilvi-integraatioon. PayPal käsittelee yli biljoona Kafka-viestiä päivittäin. New Relic vastaanottaa miljardeja datapisteitä minuutissa. Nämä eivät ole kokeellisia käyttöönottoja. Ne ovat liiketoiminnan toiminnallinen selkäranka.

Monilla yrityksillä on jo kolme luotettavan toiminnallisen tekoälyn tarvitsemaa osaa. Niiltä puuttuu arkkitehtuuria koskeva sitoutuminen, jonka avulla osat saadaan lähentymään toisiaan.

Miksi datavalmius edeltää tekoälyvalmiutta

Kain ajatuksia

Tekoälyvalmius on datavalmiutta.

Tässä on se, mitä olen havainnut: tekoäly ei ole vaikein osa. Sen alla oleva datainfrastruktuuri on.

Useimmat näkemäni yritysten tekoälyhankkeet, jotka ovat viimeisten yhdeksän vuoden aikana onnistuneet tai epäonnistuneet, riippuivat vähemmän valitusta mallista ja enemmän siitä, oliko organisaatiolla luotettava, hallittu ja reaaliaikainen perusta, joka pystyi syöttämään mallille ajantasaista, täsmällistä ja luotettavaa dataa.

Hyvin kohdistettu malli, joka saa vanhentunutta tai epäjohdonmukaista dataa, tuottaa epäluotettavia tuloksia. Agenttinen tekoälyjärjestelmä, jonka prosessikerros ei määritä, mitä se voi tehdä, ryhtyy lopulta toimeen, jota kukaan ei pysty selittämään tai peruuttamaan. Nämä eivät ole malliongelmia. Ne ovat infrastruktuuri- ja arkkitehtuuriongelmia. Ja nämä voidaan ennakoida täysin ennen yhden ainoan tekoälykoodirivin kirjoittamista.

Käytännössä tämä tarkoittaa, että tekoälyvalmius on datavalmiutta. Ennen mallin valitsemista, ennen tekoälytoimittajan valintaa ja ennen pilottihankkeen käynnistämistä CTO:n pitäisi pystyä vastaamaan rehellisesti kolmeen kysymykseen.

1. Onko organisaatiolla luotettava pääsy reaaliaikaiseen dataan operatiivisista järjestelmistään?
2. Onko käytössä hallinnoituja prosesseja, jotka määrittävät, mitä tekoälyjärjestelmä voi ja ei voi tehdä itsenäisesti?
3. Onko arkkitehtuuritasolla, ei vain mallin sisällä, käytössä luottamuskehys, joka pystyy valvomaan näitä rajoja tuotannossa?

Jos vastaus yhteenkään näistä kolmesta kysymyksestä on ei, tekoälymatkan pitäisi alkaa siitä, ei mallista.

Miksi tekoäly on integroitava olemassa oleviin liiketoimintaprosesseihin

Merkittävin ajamani muutos on ollut siirtyminen tekoälyn rakentamisesta erillisenä hankkeena sen integroimiseen olemassa oleviin liiketoimintaprosesseihin. Tähän panostetaan aivan liian vähän, vaikka vaikutukset ovat merkittäviä. Itse asiassa sanoisin, että useimpien CTO:iden pitäisi siirtyä uusien tekoälyjärjestelmien suunnittelusta sen suunnitteluun, miten tekoäly osallistuu olemassa oleviin työnkulkuihin, mitä rajoja prosessikerros valvoo ja miten hallinnointi ja auditointikelpoisuus rakennetaan osaksi kokonaisuutta — ennen yhden ainoan mallin käyttöönottoa.

Ennen tätä muutosta toimintamalli oli lähes aina sama. Tekoälyhanke aloitettiin erillään operatiivisista järjestelmistä. Malli toimi hyvin laboratorio-olosuhteissa. Tuotannossa siltä puuttui luotettava pääsy ajantasaiseen dataan, määritellyt rajat sen toimille sekä integraatio liiketoiminnan tarvitsemiin hyväksyntätyönkulkuihin. Vaikuttava esittely. Epäonnistunut käyttöönotto.

Muutos, jota nyt johdonmukaisesti edistän, on kaksiosainen.

• Ensinnäkin olemassa olevaa tapahtumapohjaista arkkitehtuuria on pidettävä tekoälyn käyttöönoton perustana eikä korvattavana kohteena. Järjestelmät säilyvät. Liiketoimintaprosessit säilyvät. Tekoäly osallistuu jo käynnissä oleviin työnkulkuihin, kuluttaa reaaliaikaisia tapahtumia ja toimii prosessikerroksen määrittämien rajojen puitteissa.
• Toiseksi tekoälyn suojakaiteet on siirrettävä mallista prosessien orkestrointikerrokseen. Hyvin kohdistettu malli ei riitä. Luotettava tekoäly tuotannossa tarkoittaa, että työnkulkujen kerros valvoo hyväksyntävaiheita, eskalointipolkuja ja auditointijälkiä jokaiselle agentin suorittamalle itsenäiselle toimelle.

Alpian, Sveitsin ensimmäinen täysin toimiluvallinen digitaalinen yksityispankki, on vahva esimerkki siitä, miten tämä tehdään oikein alusta alkaen. Alpian rakensi koko alustansa tapahtumapohjaiseksi, ja Apache Kafka toimii keskushermostona, joka yhdistää mikropalvelut, toimialueen datatuotteet ja tekoälyagentit. Kun he toivat agenttisen tekoälyn ja RAG:n asiakasvuorovaikutuksen työnkulkuihin, arkkitehtuuri oli jo valmis. Kafka-tapahtumat antoivat agenteille reaaliaikaisen kontekstin. Prosessikerros valvoi vaatimustenmukaisuuden kontrolleja. He rakensivat kenttätason salauksen ja skeemahallinnan osaksi kokonaisuutta heti alusta lähtien.

Tuloksena oli säännelty rahoituslaitos, joka käyttää itsenäisiä tekoälyagentteja hallinnoiduissa ja auditoitavissa työnkuluissa. Juuri tätä toimintamallia useimmat perinteiset yritykset yrittävät nyt sovittaa järjestelmiinsä jälkikäteen.

Organisaatiot, jotka onnistuvat tässä, käsittelevät tekoälyn käyttöönottoa arkkitehtuurikurina eivätkä projektisprinttinä.

Miksi datavalmius määrittää tekoälyn käyttöönoton onnistumisen

Nähtyäni yhdeksän Confluentilla vietetyn vuoden aikana satoja yritysympäristöjä olen havainnut tekoälyn tulosten vaihtelevan suuresti. Hyvien ja huonojen tulosten välinen ero johtuu lähes aina yhdestä asiasta: siitä, oliko datainfrastruktuuri valmis ennen tekoälyn käyttöönottoa.

Myönteisenä puolena hyvin suunniteltujen arkkitehtuurien käyttöönottojen luvut ovat vakuuttavia. BMW estää yli 500 minuuttia suunnittelematonta tuotantoseisokkia vuodessa yhdessä tehtaassa. Alpian ylläpitää täysin säänneltyä digitaalista pankkia, jonka hallinnoituihin ja auditoitaviin asiakkaiden työnkulkuihin on upotettu agenttipohjainen tekoäly. Onnistuneiden käyttöönottojen laadullinen kaava on yhdenmukainen: nopeampi markkinoilletulo, pienemmät operatiiviset kustannukset suuren volyymin toistuvissa työnkuluissa ja merkittävästi parempi asiakaskokemus, kun tekoäly käyttää reaaliaikaista kontekstia vanhentuneen eräajodatan sijaan.

Kielteisenä puolena epäonnistumisten kaava on yhtä johdonmukainen. Tekoälyhankkeet, joiden perustana ei ole hallittu data-alusta, tuottavat lähes aina saman tuloksen: vaikuttavia esittelyjä mutta epäonnistuneita tuotantokäyttöönottoja. Malli toimii laboratoriossa. Tuotannossa se saa vanhentunutta tai epäyhtenäistä dataa, tuottaa hallusinaatioita poikkeustapauksissa, suorittaa toimia ilman auditointijälkeä ja rapauttaa sen sijaan, että rakentaisi liiketoiminnan luottamusta tekoälyyn. MIT:n tutkimuksen mukaan noin 95 % yritysten tekoälypiloteista ei tuota mitattavaa liiketoimintavaikutusta. Tämä luku vastaa kentällä tekemiäni havaintoja.

Viimeisin epäonnistumismalli, jonka olen havainnut, on hallinnan lisääminen liian myöhään. Organisaatiot ottavat käyttöön agenttipohjaista tekoälyä ja huomaavat yleensä vasta tapahtuman jälkeen, ettei mikään prosessikerros määritellyt, mitä agentti sai tehdä, epävarmoille mallin tuotoksille ollut määriteltyä eskalointipolkua eikä auditointijälkeä tapahtumien rekonstruoimiseksi. Tämä ei ole tekoälyongelma. Se on arkkitehtuuriongelma. Ja se on täysin ehkäistävissä.

Miksi tekoäly tukee päätöksentekoa mutta ihmiset vastaavat vastuullisuudesta

Näen jatkuvasti saman kaavan: tekoäly tukee ja nopeuttaa toimintaa. Se tekee itsenäisiä päätöksiä määriteltyjen rajojen puitteissa. Ihmiset kuitenkin kantavat vastuun tärkeimmistä päätöksistä.

Tekoälyn tukemalla puolella tutkimusten syntetisointi, sisällöntuotanto, koodin tuottaminen tarkasti rajattuihin ongelmiin, automaattinen testaus ja tietoturvaskannaus tuottavat selvää arvoa. Omassa työssäni tekoälytyökalut tiivistävät analyytikkoraporttien, asiakaskeskustelujen ja teknisen dokumentaation syntetisointiin aiemmin kuluneita päiviä. Tuotos vaatii edelleen asiantuntijan harkintaa sen validoimiseksi, mutta lähtökohta on paljon pidemmällä.

Itsenäisten päätösten osalta tekoälyagenttien pitäisi päättää itsenäisesti, kun riski on rajattu ja prosessi on hyvin hallittu. Petosten havaitseminen rahoituspalveluissa on selkein esimerkki. Määritellyn riskikynnyksen alapuolella tekoälyagentti estää tapahtuman automaattisesti ilman ihmisen osallistumista. Kun tapahtuman koko kasvaa ja sääntelyyn liittyvä riski lisääntyy, prosessien orkestrointikerros ohjaa tapauksen ihmisanalyytikolle ennen minkään toimenpiteen suorittamista. Raja ei ole kiinteä. Liiketoiminta määrittelee sen, työnkulku koodaa sen ja prosessikerros valvoo sen noudattamista – ei itse malli.

Nimenomaisesti ihmisille kuuluvalla alueella vedän rajan päätöksiin, joilla on merkittäviä arkkitehtonisia seurauksia, strategista liiketoimintariskiä tai huomattavaa sääntelyyn liittyvää vastuuta. Perustavan arkkitehtuurimallin valitseminen, strategisen teknologiatoimittajan valinta ja agenttipohjaisen tekoälyjärjestelmän hallintamallin suunnittelu ovat edelleen ihmisten päätöksiä. Nopeampi eteneminen ei korjaa väärien päätösten seurauksia.

Miksi tekoäly ei täytä odotuksia kolmella pääalueella

Tekoäly ei ole tuottanut asiakkaiden alun perin odottamaa teknistä tai teknisen suunnittelun vaikutusta kolmella alueella.

Ensimmäinen on yritysdatan integrointi. Tekoälyn luvattiin yksinkertaistavan merkittävästi heterogeenisten järjestelmien yhdistämistä: skeemojen yhdistämistä, datan laadun valvontaa, muunnoslogiikkaa ja hallintaa monimutkaisissa hybridiympäristöissä. Käytännössä tekoäly auttaa näissä tehtävissä, mutta ei ratkaise niitä. Malli ei voi päätellä tietään ulos taustalla olevasta arkkitehtuurivelasta, dokumentoimattomilla datamalleilla varustetuista vanhoista järjestelmistä, liiketoimintayksiköiden epäyhtenäisistä semantiikoista, puuttuvista metatiedoista ja hajautuneesta omistajuudesta. Insinöörien on edelleen tehtävä vaikea työ.

Toinen on agenttipohjainen tekoäly monimutkaisissa, monivaiheisissa yritysten työnkuluissa. Esittelyt ovat vakuuttavia. Tuotannossa agentit epäonnistuvat ennakoimattomasti kohdatessaan poikkeustapauksia, joita koulutusdata ei kattanut, kun konteksti-ikkunassa ei ole riittävästi ajantasaista tilatietoa tai kun prosessikerros ei havaitse ja käsittele agentin virheitä hallitusti. Ero sen välillä, mitä agentti voi tehdä valvotussa ympäristössä ja mitä voimme luottaa sen tekevän itsenäisesti säännellyssä tuotantotyönkulussa, on edelleen merkittävä.

Kolmas on arkkitehtuuripäätöksenteko. Tekoälytyökalut ovat nopeuttaneet merkittävästi rutiininomaista koodausta, testien kirjoittamista ja dokumentointia. Ne eivät kuitenkaan paranna luotettavasti perustavan arkkitehtuurin päätöksiä. Mallit heijastavat aiempia toimintamalleja. Yritysarkkitehtuuri edellyttää harkintaa tulevista rajoitteista, sääntelyn kehityssuunnista ja teknologiavalinnoista, joita mallit eivät pysty tekemään hyvin. Tiimit, jotka tukeutuvat arkkitehtuuripäätöksissä liikaa tekoälyyn, tuottavat yleensä järjestelmiä, jotka ovat paikallisesti johdonmukaisia mutta kokonaisuutena hauraita.

Kaikkia kolmea yhdistää tämä: tekoäly tuottaa tuloksia, kun ongelma on tarkasti rajattu, data on puhdasta ja ajantasaista ja mukana on toimialan asiantuntemusta omaava ihminen. Se jää tavoitteistaan aina, kun ongelma edellyttää kontekstuaalista harkintaa, organisatorista muutosta tai arkkitehtonista ajattelua, joka ulottuu historiallisten tietojen hahmontunnistusta pidemmälle.

Miten tekoäly kamppailee koodin tietoturvan ja skaalautuvuuden kanssa

Johdonmukaisin haaste, jonka näen, liittyy tekoälyn tuottaman koodin ja tuotantotasoisen ohjelmistosuunnittelun harkinnan rajapintaan.

Tekoälypohjaiset koodinluontityökalut ovat aidosti hyödyllisiä tarkasti rajatuissa, toistuvissa tehtävissä: runkokoodin, testitapausten, dokumentaation ja suoraviivaisten muunnosten tuottamisessa. Ongelmat alkavat, kun tiimit ulottavat luottamuksensa arkkitehtuuripäätöksiin, tietoturvan kannalta herkän koodin tai skaalautuvuuden kannalta kriittisten komponenttien tuottamiseen ilman perusteellista ihmisen tekemää tarkastusta.

Tietoturvan osalta tekoälyn tuottama koodi sisältää usein hienovaraisia haavoittuvuuksia, jotka läpäisevät automaattisen tarkistuksen mutta paljastuvat vastustajan toimiessa niitä vastaan. Kehotteen syöttäminen on tällä hetkellä selkein esimerkki agenttipohjaisissa tekoälyjärjestelmissä. Agentti, joka tuottaa tai suorittaa käyttäjän syötteeseen perustuvaa koodia ilman asianmukaista syötteen validointia ja eristystä, luo hyökkäyspintoja, jotka on helppo jättää huomaamatta ja vaikea havaita jälkikäteen. Olen nähnyt tämän toimintamallin ilmenevän agenttipohjaisen tekoälyn varhaisissa käyttöönotoissa, joissa tiimit keskittyivät toiminnallisuuteen ja nopeuteen ja siirsivät tietoturvatarkastuksen myöhempään vaiheeseen.

Skaalautuvuuden osalta tekoälytyökalut tuottavat yleensä ratkaisuja, jotka toimivat oikein pienessä mittakaavassa mutta sisältävät piileviä oletuksia datan määrästä, samanaikaisuudesta tai viiveestä. Nämä oletukset tulevat esiin vasta tuotantokuormassa. Luotu Kafka-kuluttaja, joka toimii testauksessa hyvin, voi kaatua ennalta arvaamattomasti 10 000 tapahtuman sekuntivauhdilla, jos tuotettu koodi ei huomioi osioiden uudelleenjakoa, siirtymien hallintaa tai kuormituksen hallintaa. Malli ei tunne tuotantoympäristöäsi. Se tuntee koulutusdatassa esiintyviä malleja.

Käytännön ratkaisu ei ole lopettaa tekoälyn käyttöä koodin tuottamiseen. Tekoälyn tuottamaa koodia on kohdeltava samalla tavalla kuin pätevän mutta kokemattoman ohjelmistosuunnittelijan kirjoittamaa koodia, jos hän ei ole koskaan nähnyt tuotantojärjestelmääsi. Tarkasta se. Testaa se realistisissa olosuhteissa. Äläkä koskaan päästä sitä tietoturvan tai skaalautuvuuden kannalta kriittisiin osiin, ellei kokenut ohjelmistosuunnittelija ole hyväksynyt sitä.

Mitä teknologiajohtajien on tehtävä seuraavaksi

Kain ajatuksia

Investoi data-alustaasi ennen tekoälytavoitteitasi…käsittele tekoälyn hallintaa arkkitehtuuriongelmana, älä politiikkaongelmana…ajattele samanaikaisesti molempiin suuntiin.

Tässä on kolme neuvoa niiden tärkeysjärjestyksessä:

Ensinnäkin investoi data-alustaasi ennen tekoälytavoitteitasi. Mitattavia tekoälytuloksia saavuttavat organisaatiot eivät ole niitä, jotka siirtyivät nopeimmin uuteen malliin. Niillä oli puhdasta, reaaliaikaista ja hallittua dataa virtaamassa järjestelmiensä läpi jo ennen tekoälykeskustelun alkamista. Jos datasi on siiloutunutta, vanhentunutta tai hallitsematonta, korjaa asia ensin. Mikään malli ei kompensoi huonoa dataa suuressa mittakaavassa.

Toiseksi käsittele tekoälyn hallintaa arkkitehtuuriongelmana, älä politiikkaongelmana. Vastuullista tekoälyn käyttöä koskevien ohjeiden kirjoittaminen on tarpeellista mutta ei riittävää. Prosessikerros ohjaa agentin toimintaa tuotannossa: työnkulun portit, hyväksymiskynnykset, eskalointipolut ja tarkastusjäljet, jotka valvovat rajojen noudattamista riippumatta siitä, mitä malli suosittelee. Rakenna nämä arkkitehtuuriin alusta alkaen. Hallinnan lisääminen jälkikäteen käyttöönoton jälkeen on kallista ja epäluotettavaa, ja yleensä se tapahtuu vasta jonkin ongelman ilmenemisen jälkeen.

Kolmanneksi ajattele samanaikaisesti molempiin suuntiin. Alhaalta ylöspäin suuntautuva paine julkaista tekoälyn käyttötapauksia nopeasti on todellista ja oikeutettua. Samoin on ylhäältä alaspäin suuntautuva tarve strategiselle arkkitehtuurille, joka estää hajanaisten pistemäisten ratkaisujen syntymisen, joiden selvittämiseen kuluisi vuosia. Näen tämän hyvin hallitsevien teknologiajohtajien pystyvän pitämään molemmat näkökulmat mielessä samanaikaisesti: he etenevät nopeasti tiettyjen käyttötapausten kanssa ja säilyttävät samalla selkeän arkkitehtuurisen suunnan, joka pitää käyttötapaukset koostettavina ja hallittavina ajan mittaan.

Organisaatiot, jotka katsovat tähän ajanjaksoon taaksepäin kilpailuetuna, eivät ole niitä, jotka ottivat tekoälyn käyttöön ensimmäisinä. Ne rakensivat infrastruktuurin, joka teki tekoälystä luotettavan, ja etenivät sitten nopeasti tämän perustan varaan.

Pysy mukana

Voit seurata Kai Waehnerin työtä hänen verkkosivustollaan, blogissaan ja LinkedInissä.

Lisää asiantuntijahaastatteluja on luvassa The CTO Clubissa!