Sapan Pandya, vanhempi ohjelmistosuunnittelija ja IEEE:n seniorijäsen – haastattelusarja

Sapan Pandya on New Jerseyssä asuva vanhempi ohjelmistosuunnittelija ja IEEE:n seniorijäsen, jolla on yli kymmenen vuoden kokemus vikasietoisista hajautetuista tapahtumajärjestelmistä. Hänen työnsä kattaa tapahtumien eheyden, ohjelmistojen ja fyysisten laitteiden integroinnin, tuotantoympäristön ongelmanratkaisun sekä käyttöönottojen validoinnin säännellyissä ympäristöissä. Hänellä on tietojenkäsittelytieteen maisterin tutkinto Stevens Institute of Technologysta, ja hän osallistuu tieteelliseen vertaisarviointiin ja tekniseen tutkimukseen.

Pandyan tutkimus käsittelee kioskien kyberturvallisuutta, reunatekoälyä ja tekoälyavusteista luotettavuustekniikkaa. Hänen kokemuksensa tuotantoympäristöistä puolestaan ohjaa hänen keskittymistään näyttöön, tapahtumien lopputuloksiin ja toiminnan vastuullisuuteen. Tässä haastattelussa hän puhuu idempotenssista, ristiriitaisista tapahtumatiedoista, palautumisjärjestelmien epävarmuudesta ja hallintakeinoista, joita tarvitaan ennen kuin tekoälyagentit voivat toimia kriittisessä infrastruktuurissa. Hän erottaa käytännön insinöörikokemuksen tutkimuksesta, jota tehdään kirjallisuusanalyysin sekä kontrolloidun tai synteettisen testauksen avulla.

Urasi on keskittynyt ohjelmistojen luotettavuuteen ja hajautettuihin tapahtumajärjestelmiin. Miten tämä kokemus on muovannut käsitystäsi luotettavuudesta, ja mitkä haasteet ovat vaikuttaneet näkemykseesi tekoälyn käyttämisestä monimutkaisten järjestelmien hallintaan?

Näkökulmani on muuttunut: en enää kysy, toimiiko yksittäinen komponentti, vaan sitä, onko asiakkaan tapahtuma saatettu loppuun ja voidaanko sen kulku selvittää.

Urani alkuvaiheessa keskityin suurelta osin sovelluksen toimintaan: syötteiden validointiin, vastausten käsittelyyn ja sen varmistamiseen, että käyttöliittymä noudatti suunniteltua työnkulkua. Kun vastuualueeni laajenivat järjestelmien integrointiin, tuotantoympäristön ongelmanratkaisuun ja käyttöönottojen validointiin, minun oli tarkasteltava yksittäisiä komponentteja laajempaa kokonaisuutta.

Palvelu voi saada työnsä valmiiksi, vaikka toinen palvelu vielä odottaa vahvistusta. Ohjelmisto voi kirjata toiminnon onnistuneeksi, vaikka fyysinen laite ei tuottaisi odotettua tulosta. Se, että kukin komponentti läpäisee testit, ei yksinään osoita, että koko vuorovaikutus toimii oikein.

Tämä kokemus on saanut minut kiinnostumaan erityisesti järjestelmien välisistä rajapinnoista. Mitä kukin komponentti tietää? Mitä se olettaa? Mitä tapahtuu, kun nämä oletukset eivät enää pidä paikkaansa?

Kokemus vaikuttaa myös siihen, miten ajattelen tekoälystä. Insinöörien auttamisesta näyttöaineiston kokoamisessa, mallien tunnistamisessa ja vikojen nopeammassa selvittämisessä on todellista hyötyä. Selitys siitä, mitä luultavasti tapahtui, on kuitenkin eri asia kuin varmennettu selvitys siitä, mitä todella tapahtui.

Haluan, että tekoäly vähentää ongelmien selvittämiseen kuluvaa työtä tinkimättä näytön tasosta, jota ongelman ratkaiseminen edellyttää.

Olet korostanut, ettei teknisesti oikea koodi aina takaa tapahtuman oikeaa lopputulosta. Voitko kertoa konkreettisen esimerkin tilanteesta, jossa tapahtuma näyttää aikakatkaisun vuoksi epäonnistuneen, vaikka se onkin suoritettu loppuun? Mikä voi mennä pieleen, kun järjestelmä yrittää suorittaa toiminnon automaattisesti uudelleen, ja miten insinöörien pitäisi estää päällekkäiset tapahtumat?

Kuvitellaan hypoteettinen 50 dollarin maksu. Sovellus lähettää pyynnön, maksupalvelu kirjaa sen onnistuneesti ja vastaus katoaa ennen kuin se ehtii sovellukseen.

Asiakas näkee aikakatkaisuilmoituksen, vaikka maksu on jo mennyt läpi. Jos sovellus lähettää uuden maksupyynnön, asiakkaalta voidaan veloittaa uudelleen.

Aikakatkaisu kertoo, ettei vastaus saapunut ajoissa. Se ei kerro, onnistuiko varsinainen tapahtuma.

Yksi yleinen suojakeino on idempotenssi: sama looginen pyyntö voidaan toistaa aiheuttamatta uutta taloudellista vaikutusta. Sovellus säilyttää toiminnon tunnisteen uudelleenyritysten ajan, ja vastaanottava palvelu tunnistaa pyynnön alkuperäiseksi eikä uudeksi ostoksi.

Oleellista ei ole pelkästään tunnisteen liittäminen pyyntöön. Palvelun on valvottava tunnisteen yksilöllisyyttä ja säilytettävä riittävästi tietoa, jotta se pystyy erottamaan loppuun suoritetun toiminnon yhä kesken olevasta. Tunniste ei suojaa jatkokäsittelyn toimintoa, jos se ei huomioi tunnistetta.

Jos lopputulos jää epävarmaksi, palautumismenettelyssä pitäisi tarkistaa olemassa oleva tapahtuma ja täsmäyttää asiaankuuluvat tiedot sen sijaan, että luotaisiin heti korvaava tapahtuma.

Rajoittaisin myös uudelleenyritysten määrää ja määrittelisin, mitä tapahtuu, jos automaattinen palautuminen ei pysty selvittämään lopputulosta. Asiakas tarvitsee selkeän tiedon siitä, että tapahtuma on kesken, sekä keinon saada asia ratkaistua – ei toistuvia veloituksia tai loputtomasti pyörivää käsittelyruutua.

Hajautetuissa järjestelmissä tietokanta, taustapalvelu ja fyysinen kioski voivat ilmoittaa samasta tapahtumasta keskenään ristiriitaisia tietoja. Oletko kohdannut tuotantoympäristössä tällaista epäjohdonmukaisuutta, ja miten sitä selvitettiin ja miten se ratkaistiin? Mikä rooli tekoälyllä voisi olla näiden ristiriitaisten tietojen täsmäyttämisessä, jos sellainen rooli olisi?

Kyllä, tapahtumien tilaan liittyvien epäjohdonmukaisuuksien selvittäminen on kuulunut työhöni tuotantoympäristöissä. Jotta voin selittää päättelyä käsittelemättä työpaikalla sattunutta tapausta, käytän hypoteettista esimerkkiä.

Ajatellaan tavanomaista itsepalvelukassaa. Maksupalvelu kirjaa ostoksen onnistuneeksi, tulostin ilmoittaa vastaanottaneensa kuitin tulostustyön, ja näytölle ilmestyy sen jälkeen virheilmoitus. Havainnot voivat kuvata vuorovaikutuksen eri vaiheita, eivätkä ne välttämättä todista, että koko ostotapahtuma epäonnistui.

Selvittäisin ensin tapahtumien kulun tapahtumatunnisteen sekä asiaankuuluvien palvelu- ja laitetietojen avulla. Sen jälkeen määrittäisin, mitä kukin havainto todistaa. Se, että tulostin vastaanottaa tulostustyön, ei välttämättä osoita, että kuitti päätyi asiakkaalle. Pyynnön vastaanottaminen ei myöskään välttämättä osoita, että sen taloudellinen vaikutus toteutui.

Ratkaisu riippuu siitä, missä vaiheessa virhe tapahtui. Koko tapahtuman toistaminen voi olla sopimatonta, jos korjausta tarvitaan vain tulostusvaiheessa. Jos käytettävissä olevien tietojen perusteella ei voida selvittää, mitä tapahtui, kyseinen toiminto on pidettävä hallinnassa selvityksen ajan.

Pysyvän korjauksen on myös puututtava siihen, miksi tällainen epäjohdonmukaisuus oli mahdollinen, eikä vain korjattava yhtä tietuetta.

Tekoäly voisi auttaa yhdistämään tapahtumia ja tunnistamaan puuttuvia tietoja. Pyytäisin sitä esittämään vaihtoehtoisia selityksiä ja kunkin tueksi saatavilla olevat todisteet. Sen pitäisi auttaa rajaamaan selvitystä, ei ratkaista ristiriitaisia tietoja valitsemalla selitys, joka kuulostaa vakuuttavimmalta.

Kun tekoälyagentit kehittyvät tuotantoympäristön häiriöiden diagnosoinnista palautustoimien suosittelemiseen tai suorittamiseen, millaisia suojatoimia pitäisi ottaa käyttöön ennen kuin tekoälyjärjestelmä voi yrittää tapahtumaa uudelleen, peruuttaa sen tai muuttaa sitä? Miten deterministiset hallintakeinot, kuten idempotenssiavaimet, tapahtumalokit ja täsmäytysmekanismit, voivat estää tekoälyä aiheuttamasta uusia virheitä?

Erottaisin toiminnon ehdottamisen sen hyväksymisestä ja suorittamisesta.

Tekoälyagentti voisi ehdottaa uutta yritystä, mutta erillisen hallintamekanismin pitäisi ratkaista, sallitaanko se. Mekanismin pitäisi tarkistaa tapahtuman senhetkinen tila, toiminnon yksilöivä tunniste, agentin käyttöoikeudet sekä ehdot, joiden täyttyessä toiminto on turvallinen.

Tarkistus on tehtävä toiminnon suorittamisen yhteydessä, ei vain silloin, kun malli ensin tarkasteli häiriötä. Toinen prosessi on saattanut saada tapahtuman valmiiksi sillä välin.

Agentin käytettävissä olevien työkalujen pitäisi olla myös tarkasti rajattuja. Oikeus hakea tapahtuman tila on eri asia kuin oikeus peruuttaa maksu tai muuttaa taloustietuetta. Agentti ei saa voida laajentaa omia valtuuksiaan vain siksi, että sen suosima ratkaisu edellyttää laajempia käyttöoikeuksia.

Idempotenssi rajoittaa päällekkäisiä vaikutuksia. Lokit säilyttävät selvityksessä tarvittavan tapahtumahistorian. Täsmäytyksellä tarkistetaan, vastaavatko asiaankuuluvat tietueet toisiaan. Mikään näistä ei yksin osoita, että ehdotettu toiminto olisi asianmukainen.

Kirjaisin myös käytetyt todisteet, suosituksen, valtuutuspäätöksen ja toteutuneen lopputuloksen. Näin toimenpiteen voi arvioida jälkikäteen.

Nämä hallintakeinot pitäisi toteuttaa mallin ulkopuolisessa, testattavassa ohjelmistossa. Agenttia huolellisuuteen kehottavat ohjeet ovat hyödyllisiä, mutta ne eivät ole valtuutusmekanismi.

Ajatellaan tilannetta, jossa tekoälypohjainen valvontajärjestelmä havaitsee ilmeisen tapahtumavirheen ja suosittelee toiminnon automaattista peruuttamista. Jos tapahtuma onnistuikin mutta vahvistus viivästyi, toimenpide voisi aiheuttaa uuden ongelman. Miten suunnittelutiimien pitäisi rakentaa tekoälypohjaisia palautusjärjestelmiä niin, että ne tunnistavat epävarmuuden eivätkä tee korjaavia toimia puutteellisten tietojen perusteella?

Järjestelmässä on oltava todellinen tila ”lopputulos tuntematon”. Muuten puuttuvat tiedot tulkitaan todennäköisesti virheellisesti merkiksi epäonnistumisesta.

Viivästynyt vahvistus on syy selvittää tilanne, ei automaattisesti syy peruuttaa tapahtuma. Peruuttaminen on uusi taloudellinen toimenpide, jolla on omat seurauksensa. Sille on oltava erikseen selvitetty peruste ja asianmukainen valtuutus.

Jakaisin toimintatavan kahteen polkuun. Selvityspolussa voidaan hakea tila, kerätä puuttuvat tapahtumatiedot, vertailla tietueita ja ilmoittaa asiasta vastuutiimille. Taloudelliset toimenpiteet pysyvät estettyinä, kunnes niiden edellytykset täyttyvät.

Näin estetään tekoälyn varmuuspisteytystä korvaamasta tapahtumaa koskevia todisteita. Malli voi olla erittäin varma selityksestä, joka perustuu puutteellisiin tietoihin.

Myös eskaloinnille on määritettävä selkeä kohta. Tapahtuman jättäminen odottamaan määräämättömäksi ajaksi ei ole asiakkaalle tyydyttävä lopputulos. Jonkun on otettava vastuu ratkaisemattomasta tapauksesta, ja hänellä on oltava riittävästi taustatietoja voidakseen päättää seuraavasta turvallisesta vaiheesta.

Palautusprosessin on siis pystyttävä sanomaan sekä ”En voi vielä perustella tämän tapahtuman muuttamista” että ”Näin asia saadaan ratkaistua”.

Epävarmuuden tunnistamisesta on hyötyä vain, jos järjestelmä pystyy käsittelemään sitä käytännössä.

Yksi autonomiseen tekoälyyn liittyvistä keskeisimmistä kysymyksistä on, milloin ihmisen hyväksyntä on edelleen välttämätön. Mitkä tuotantoympäristön palautumistoimet tekoälyn pitäisi mielestäsi voida suorittaa itsenäisesti, ja mitkä pitäisi aina edellyttää ihmisen hyväksyntää? Miten organisaatioiden tulisi määritellä nämä rajat, kun vaakalaudalla ovat rahansiirrot, sääntelyn noudattaminen tai asiakkaiden luottamus?

Asettaisin rajan sen mukaan, mitä väärässä olemisesta seuraisi, en sen mukaan, kutsutaanko toimintoa ”tekoälyksi”.

Vain lukuoikeuksin tehtävä tutkinta on järkevä lähtökohta, kunhan agentti pääsee käsiksi ainoastaan tietoihin, joiden käyttöön sillä on valtuutus. Se voi kerätä diagnostiikkatietoja, ryhmitellä toisiinsa liittyviä hälytyksiä ja laatia yhteenvedon häiriöstä ilman, että se saa muuttaa itse tapahtumaa koskevia tietoja.

Myös joidenkin ennalta määriteltyjen palautumismenettelyjen automatisointi voi olla tarkoituksenmukaista, jos niiden edellytykset tarkistetaan riippumattomasti ja niiden vaikutukset ovat rajalliset.

Edellyttäisin ihmisen hyväksyntää, jos ehdotettu toimenpide ei kuulu hyväksyttyyn menettelyyn, jos tietueet ovat ristiriidassa keskenään eikä taloudellista lopputulosta ole saatu selville tai jos toimenpide muuttaisi tietoturvan hallintakeinoja tai agentin omia käyttöoikeuksia. Agentin ei pitäisi voida hyväksyä tällaisia päätöksiä itse.

Tämä ei tarkoita, että jokainen rutiininomainen rahoitustoimi vaatisi ihmisen hyväksynnän. Vakiintuneiden sääntöpohjaisten käsittelymenettelyjen käyttö on eri asia kuin se, että mallin annetaan keksiä korjaustoimi häiriön aikana.

Ihmisen tekemän tarkastelun on myös oltava mielekäs. Hyväksyntänäkymässä pitäisi esittää asiaa tukeva näyttö, jäljellä oleva epävarmuus, odotettavissa oleva vaikutus ja käytettävissä olevat vaihtoehdot. Jos jotakuta pyydetään hyväksymään vakuuttavasti muotoiltu tekstikappale ilman näitä taustatietoja, suoja on vähäinen.

Näistä rajoista pitäisi sopia ennen käyttöönottoa. Katkos ei ole oikea hetki päättää, kuinka paljon toimivaltaa automatisoidulla järjestelmällä pitäisi olla.

Olet työskennellyt laajasti vikasietoisten taustajärjestelmien, järjestelmien havainnoitavuuden työkalujen sekä ohjelmistopalvelujen ja fyysisten laitteiden välisten integraatioiden parissa. Millaista tuotantotelemetriaa ja näyttöä tekoälyagentti tarvitsisi häiriön luotettavaan diagnosointiin? Miten insinööritiimit voivat erottaa hyödylliset tekoälyn tuottamat suositukset uskottavilta mutta virheellisiltä päätelmiltä, jotka saattaisivat pahentaa käyttökatkoa?

Aloittaisin näytöstä, joka yhdistää asiakkaan toiminnan eri järjestelmissä: tapahtumatunnisteista, palvelutapahtumista, pysyvistä tilanmuutoksista, laitteiden vastauksista ja tiedonsiirron häiriöistä.

Myös ohjelmistoversioilla ja kokoonpanomuutoksilla on merkitystä. Jos häiriö alkaa ohjelmistojulkaisun jälkeen, se antaa tutkijalle hyödyllisen johtolangan, mutta pelkkä ajallinen yhteys ei todista syy-yhteyttä.

Agentin on myös ymmärrettävä näytön rajoitukset. Lokit voivat olla puutteellisia, tietueet voivat saapua viiveellä ja kellot voivat näyttää eri aikoja. Kuittauksen puuttuminen ei todista, ettei mitään toimenpidettä tapahtunut.

Hyödyllisen diagnoosin pitäisi erottaa havainnot tulkinnoista. ”Asiakasohjelma kirjasi aikakatkaisun” on havainto. ”Taustajärjestelmä ei ollut käytettävissä” on selitys, joka vaatii tuekseen lisänäyttöä.

Odottaisin, että suosituksessa yksilöidään sen perustana olevat tietueet, kerrotaan, mikä jää epäselväksi, ja täsmennetään, millä lisätarkistuksella päätelmä voitaisiin vahvistaa tai kumota.

Insinöörien pitäisi sen jälkeen tarkistaa merkittävät suositukset alkuperäisistä tietueista sen sijaan, että he luottaisivat pelkästään agentin yhteenvetoon. Tämä on erityisen tärkeää silloin, kun yhteenveto tiivistää pitkän tai ristiriitaisen tapahtumahistorian.

Käyttäisin yksinkertaista mittapuuta: pystyykö toinen insinööri seuraamaan näyttöä ja päätymään perusteltavissa olevaan johtopäätökseen? Jos selitys ei kestä tällaista tarkistusta, sen perusteella ei pidä vielä tehdä muutoksia tuotantoympäristöön.

Arvioit julkaistussa tutkimuksessasi lottopeli- ja vedonlyöntikioskien kiristysohjelmakestävyyttä tekoälyavusteista tietoturvakehystä synteettisessä ympäristössä, jossa simuloitiin 500 kioskia. Mitkä olivat tärkeimmät havainnot, ja mitä rajoituksia lukijoiden pitäisi ottaa huomioon tuloksia tulkitessaan? Mitä lisävalidointia tarvittaisiin, ennen kuin ehdotettua arkkitehtuuria sovellettaisiin tuotantokäytössä olevaan ympäristöön?

Halusin tarkastella häiriönsietokykyä havaitsemista laajemmin: miten päätelaiteympäristö voisi rajoittaa hyökkäystä, tunnistaa sen ja palautua siitä säilyttäen samalla näytön tapahtuneesta.

Tuloksena syntyneessä Resilient Security Framework -kehyksessä yhdistyivät ennaltaehkäisevät hallintakeinot, tekoälyavusteinen poikkeamien havaitseminen sekä määritellyt reagointi- ja palautumismekanismit. Tekoälyn tehtävänä oli havaita epäilyttävää toimintaa. Kokeessa ei annettu kielimallia käyttävälle agentille lupaa muuttaa itsenäisesti rahansiirtoja.

Arviointi tehtiin synteettisessä ympäristössä, joka kuvasi 500 kioskia 72 tunnin simulaation aikana. Kiristysohjelmahyökkäyksiä jäljiteltiin käyttäytymismallien avulla; tutkimuksessa ei otettu järjestelmää käyttöön 500 fyysisessä päätteessä.

Tutkimuksen pelkkään virustorjuntaan perustuvaan vertailutasoon nähden keskimääräinen havaitsemisaika lyheni 52 minuutista 31 minuuttiin ja keskimääräinen palautumisaika 120 minuutista 56 minuuttiin.

Nämä ovat yhdistetyn viitekehyksen tuloksia kokeellisissa olosuhteissa. Niitä ei pidä lukea yksinomaan tekoälyn ansioksi eikä pitää suorituskykytakuuna todellisessa käyttöympäristössä. Yksi hyödyllinen havainto oli, ettei aiempi havaitseminen yksinään tuonut samanlaista parannusta palautumiseen. Myös uhkien rajaamisen ja palautumisen suunnittelulla oli merkitystä.

Rajoitukset ovat tärkeitä. Simuloidut kuormitukset, verkkoyhteydet, hyökkäystavat ja vertailussa käytetyt suojaukset eivät edusta kaikkia toimintaympäristöjä. Erilaiset laitteet ja sovellukset vaatisivat uutta validointia.

Ennen tuotantokäyttöä haluaisin testata järjestelmää edustavalla laitteistolla, teettää siitä riippumattoman tietoturva-arvioinnin, arvioida sitä pidempään sekä mitata huolellisesti väärät hälytykset ja käsittelyn aiheuttaman lisäkuormituksen.

Testaisin palautumisprosessia myös normaalin maksutapahtumaliikenteen aikana. Toimivan ohjelmiston palauttaminen ei riitä, jos prosessissa menetetään tiedot, joita tarvitaan suoritettujen tapahtumien kirjaamiseen.

Tutkimus tarjoaa pohjan jatkotestaukselle. Turvallisen toiminnan osoittaminen todellisessa toimintaympäristössä on erillinen vaihe.

Näkemyksesi perustuu sekä vuosien kokemukseen tuotantojärjestelmien suunnittelusta ja toteutuksesta että ohjelmistojen luotettavuutta ja tekoälypohjaista tietoturvaa käsittelevään akateemiseen tutkimukseen. Voitko erottaa toisistaan luotettavuusmekanismit, joita olet itse toteuttanut tai käyttänyt todellisissa tuotantojärjestelmissä, ja lähestymistavat, joita olet tutkinut tutkimustyössä tai simuloiduissa testeissä? Mitkä tekoälypohjaiset palautumiskyvykkyydet ovat mielestäsi jo käytännössä toteutettavissa, ja mitkä ovat yhä pääosin kokeellisia?

Tuotantotyöhöni on kuulunut ohjelmistokehitystä ja integrointia, tapahtumien validointia, vianmääritystä, testausta sekä julkaisujen validointia.

Julkaistu tutkimustyöni on erillinen osa työtäni, ja kutakin tutkimusta on tarkasteltava siinä kuvattujen menetelmien ja rajoitusten mukaisesti.

Lunnasohjelmia käsittelevässä tutkimuksessa arvioidaan ehdotettua tietoturvakehystä synteettisessä testiympäristössä. Reunatekoälyä käsittelevässä artikkelissani analysoidaan kirjallisuuteen perustuen laitteessa tapahtuvaa älykästä käsittelyä ja sen mahdollista soveltamista maksupäätteisiin. IEEE FeedForward -artikkelissani tarkastellaan tekoälyavusteista luotettavuusarkkitehtuuria hallitussa simulaatiossa, johon sisältyvät valvonta, eskalointi ja varatoimintatavat.

Mitään näistä julkaisuista ei pidä tulkita todisteeksi siitä, että olisin ottanut käyttöön autonomisen tekoälyagentin, jolla on valtuudet käsitellä todellisia rahoitustapahtumia.

Käytännön sovelluksissa asettaisin etusijalle avustavat toiminnot, joiden tuloksia insinöörit voivat tarkastella: lähdetietueisiin linkitetyt häiriöyhteenvedot, hälytysten väliset yhteydet ja ehdotetut vianmääritystarkistukset. Niiden hyödyllisyys on silti mitattava siinä ympäristössä, jossa niitä käytetään.

Vaikeampi ongelma on ennakoimaton palautuminen, jossa malli valitsee ja toteuttaa muutoksia ennalta arvaamattomissa olosuhteissa. Se edellyttää huomattavasti vahvempaa näyttöä kuin hyödyllinen vianmääritysehdotus.

Näen tuotantokokemukseni ja tutkimukseni toisiaan täydentävinä: toinen auttaa määrittämään toiminnalliset ongelmat, jotka tunnen, kun taas toisessa tutkitaan lähestymistapoja, joiden on vielä ansaittava paikkansa validoinnin kautta.

Miten arvelet autonomisten järjestelmien ja insinöörien välisen suhteen kehittyvän, kun tekoälyagentit kykenevät yhä paremmin havaitsemaan poikkeamia, diagnosoimaan vikoja ja koordinoimaan palautumista hajautetuissa järjestelmissä? Millaisia teknisiä suojatoimia, käytännön näyttöä ja vastuumekanismeja tarvittaisiin, ennen kuin organisaatiot voisivat luottavaisin mielin antaa tekoälylle enemmän valtuuksia kriittisessä tuotantoinfrastruktuurissa?

Uskon, että tekoäly ottaa hoitaakseen yhä suuremman osan häiriötilanteen kokonaiskuvan kokoamisesta. Insinöörit voisivat aloittaa hyödyllisen aikajanan, vaikutuksen alaiset komponentit, keskenään kilpailevat selitykset ja puuttuvat todisteet sisältävästä yhteenvedosta sen sijaan, että käyttäisivät niin paljon aikaa näiden tietojen keräämiseen käsin.

Näin ihmisille jäisi enemmän aikaa päätöksentekoon, joka edellyttää järjestelmän velvoitteiden ja siihen tehtävien muutosten seurausten ymmärtämistä.

Laajentaisin suoritusvaltuuksia vähitellen. Agentti voisi ensin toimia varjotilassa ja tuottaa suosituksia toteuttamatta niitä. Tiimit voisivat verrata suosituksia tarkistettuihin lopputuloksiin ja testata, miten agentti toimii, kun tiedot ovat puutteellisia, ristiriitaisia tai vanhentuneita.

Arvioinnissa tulisi huomioida virheelliset toimenpiteet, huomaamatta jääneet ongelmat, tarpeettomat eskaloinnit ja agentin omista virheistä palautuminen. Nopeasta suosituksesta ei ole hyötyä, jos se ohjaa vastetiimin väärään suuntaan.

Laajempien valtuuksien tulisi olla myös ehdollisia. Mallin päivitys tai suuri järjestelmämuutos voi mitätöidä aiemmat testitulokset. Tiimeillä on oltava keino rajoittaa agentin käyttöoikeuksia tai poistaa ne, jos sen toiminta ei enää täytä vaatimuksia.

Ihmisten vastuu ei katoa automaation kehittyessä. Jonkun on vastattava toimintaperiaatteista, muutoksilta vaadittavasta näytöstä ja virheiden tutkintaprosessista.

Uskon, että insinöörit käyttävät jatkossa vähemmän aikaa tietojen keräämiseen ja enemmän aikaa niiden ehtojen määrittelyyn, testaamiseen ja ylläpitoon, joiden täyttyessä automatisoidut toimet ovat perusteltuja.

Kiitos hienosta haastattelusta! Lukijat, jotka haluavat seurata hänen työtään hajautettujen transaktioiden luotettavuuden ja vastuullisen tekoälyavusteisen palautumisen parissa, voivat ottaa yhteyttä Sapan Pandyaan.