Sobhan Daliry, CPO & AI Strategy Leader at Pipefy – Haastattelusarja

Sobhan Daliry, CPO & AI Strategy Leader at Pipefy, on kokenut tuote- ja teknologiatoimitusjohtaja, joka on johtanut yhtiön AI‑strategiaa vuodesta 2023, auttaen muuntamaan perinteisiä liiketoimintaprosesseja yhä älykkäämmiksi ja autonomisemmiksi. Uransa aikana Daliry on yhdistänyt tuotestrategian, organisaatiomuunnoksen ja teknologiavetoisen johtamisen startup-yrityksissä ja vakiintuneissa yrityksissä. Ennen Pipefyyn liittymistään hän perusti ja toimi Polen.me:n toimitusjohtajana sekä vietti yli viisi vuotta NZN:n toimitusjohtajana/CPO:n roolissa, jossa hän johti yhtiön käännekohdan ja tuotestrategian. Aikaisempiin tehtäviinsä kuuluvat Product Management -johtaja PSafe:lla, tuotehallinnan päällikkö Peixe Urbano:lla sekä tehtävät, jotka kattavat digitaalipalvelut, televiestinnän, konsultoinnin ja liiketoiminnan kehittämisen Oi/Telemarilla, Clarolla, AIRCOM Internationalilla ja Planeta Tecnologia:lla.

Pipefy on globaali prosessienhallinta- ja AI-alusta, jonka tarkoitus on auttaa organisaatioita automatisoimaan ja orkestroimaan liiketoimintaprosesseja. Vuonna 2015 perustettu yritys on kehittynyt no‑code‑prosessi‑automaatiosta AI‑keskeiseksi orkestrointialustaksi, joka yhdistää AI‑agentit, työnkulut, lomakkeet, portaalit, sovellukset, data, analytiikan, viestinnän ja integraatiot. Alusta mahdollistaa tiimeille AI‑agenttien luomisen ja hallinnan luonnollisen kielen ja no‑code‑työkalujen avulla samalla säilyttäen yritystason hallinnon, turvallisuuden ja näkyvyyden. Pipefyn AI‑ominaisuuksiin kuuluvat agentit, jotka voivat tulkita asiakirjoja, suorittaa työnkulun tehtäviä, tukea päätöksentekoa, olla vuorovaikutuksessa ulkoisten järjestelmien kanssa sekä orkestrointaa prosesseja eri alueilla, kuten talous, henkilöstöhallinto, hankinnat, asiakasoperaatiot ja vaatimustenmukaisuus.

Uraasi on vienyt sinut telekommunikaatioinsinöörinä yrityksissä kuten Claro ja Oi tuotantojohtoon Peixe Urbano ja PSafe -yrityksissä, NZN:n toimitusjohtaja/CPO -rooliin, Polen.me:n perustamiseen ja nyt tuotanto- ja AI‑strategian johtamiseen Pipefy:ssä. Miten tämä kehitys on muokannut tapaa, jolla ajattelet AI‑tuotteiden rakentamista, jotka ratkaisevat todellisia operatiivisia ongelmia sen sijaan, että ne vain esittelevät uutta teknologiaa?

Telekommunikaatio opetti minulle, että infrastruktuurin on toimittava jokaisella kerralla, massiivisessa mittakaavassa, ilman mitään tilaa sille, että “se toimii enimmäkseen”. Katkennut puhelu ei ole demo‑epäonnistuminen, se on asiakas, joka kävelee pois. Tämä ajattelutapa — luotettavuus ennen uutuutta — ei ole koskaan jättänyt minua. Peixe Urbano ja PSafe opettivat minulle päinvastaisen oppitunnin: kuinka nopeasti kuluttajatuotteet elävät tai kuolevat sen perusteella, ratkaisevatko ne todellisen, koetun ongelman tänään, eikä teoreettisen. NZN:n johtaminen toimitusjohtajana/CPO:na pakotti minut pitämään molemmat totuudet samanaikaisesti — et voi ylittää huonoa teesiä suorituksella, etkä voi ylittää huonoa toteutusta teorialla. Polen.me:n perustaminen opetti minulle kalleimman oppitunnin: pääoma ja aika ovat rajallisia, joten jokainen rakentamasi ominaisuus on ominaisuus, jota et rakennut, ja vaikuttavan demon tavoittelun kustannus todellisen työnkulun sijaan ilmenee kuukausia myöhemmin, ei lavalla. Kun pääsin Pipefyyn, kysymys, jonka esittelen jokaisesta AI‑ominaisuudesta, on sama kuin mitä kysyisin solutornista: kestääkö tämä tuotannossa, todellisessa kuormituksessa, kun kukaan ei tarkkaile? Jos AI‑agentti toimii vain kuratoidussa demo‑ympäristössä, se ei ole tuote — se on vain traileri tuotteelle.

Olet johtanut Pipefyn AI‑strategian muotoilua ja toteutusta vuodesta 2023. Mitkä oletukset yritys‑AI:sta sinulla olivat alussa, jotka ovat muuttuneet eniten generatiivisen AI:n ja AI‑agenttien kehittyessä?

Suurin oletus, jonka jouduin hylkäämään, oli että malli olisi pullonkaula. Vuonna 2023 kaikki — myös minä — optimoivat “mikä LLM on älykkäin”. Todellisuudessa pullonkaulaksi osoittautui konteksti: tietääkö agentti, mikä prosessi oikeasti on, mitkä ovat rajoitteet, miltä “valmis” näyttää tämän tietyn asiakkaan ostolaskujen versiossa. Mallin laatu parani jatkuvasti kaikille nähtävissä olevalla käyrällä; prosessikonteksti ei kehittynyt itsestään, koska kukaan ei ollut jäsentänyt sitä. Toinen käännetty oletus koski autonomiaa. Oletin, että markkinat haluavat agentteja, jotka toimivat täysin itsenäisesti mahdollisimman nopeasti. Yritykset haluavat — ja edelleen haluavat — rajattua autonomiaa: agentteja, jotka tekevät todellisia päätöksiä sääntöjen puitteissa, joita ne eivät voi rikkoa, ja joilla on jälki, joka todistaa sen jälkikäteen. Täysi autonomia ilman hallintaa ei ole kunnianhimoa, se on vain riski paremmalla käyttöliittymällä. Markkinat kehittyivät nopeammin luottamuksen vaatimusten kuin raakojen kykyvaatimusten suhteen, ja tämä uudelleenjärjestely on suurin virhe, jonka tein alussa.

Pipefy erottaa toisistaan melko yksinkertaisen AI‑automaation ja AI‑agentit, jotka pystyvät järkeilemään epäselviä tilanteita, suunnittelemaan useita vaiheita ja toteuttamaan toimintoja työnkulun läpi. Miten yritysten tulisi määrittää, milloin tehtävä todella vaatii AI‑agentin sen sijaan, että deterministinen automaatio olisi parempi ratkaisu?

Testi, jota käytän, on yksinkertainen: jos osaat kirjoittaa säännön, kirjoita se. Deterministinen automaatio on yhä oikea ratkaisu kaikelle, missä päätöspuu on ennakkoon tiedossa eikä muutu — ohjaa tämä lasku tälle hyväksyjälle, jos summa on alle tämän rajan. Tämä ei ole agentin tehtävä, ja väittäminen toisin vain lisää viivettä ja ennustamattomuutta jo ratkaistuun asiaan. Agentti ansaitsee paikkansa heti, kun tilanteessa on epäselvyyttä, jota kiinteä sääntö ei pysty ratkaisemaan — lasku ei täsmää ostotilaukseen tarkalleen, jokin kenttä puuttuu, asiakkaan pyyntö ei sovi mihinkään olemassa olevaan kategoriaasi. Tässä päättelyn saa todellista arvoa: päätetään, mitä tehdä seuraavaksi, kun “next” ei ole vielä kirjattu. Virhe, jonka näen yritysten tekevän jatkuvasti, on rakentaa agentti 80 %:lle tapauksista, jotka olivat jo deterministisiä, koska se on näyttävämpää, ja jättää epäselvä 20 % — varsinainen vaikea osa — ihmisen ratkaistavaksi manuaalisesti. Käännä suhde, ja olet rakentanut jotain aitoa.

On kasvava siirtymä itsenäisistä avustajista kohti “agenttiorkestrointia”, jossa tekoäly voi koordinoida useita järjestelmiä kattavia prosesseja. Mikä erottaa aitoa agenttiorkestrointia pelkästä suurikielimallin lisäämisestä olemassa olevaan automaatioalustaan?

LLM-solmun lisääminen olemassa olevaan automaatiovirtaan antaa sinulle älykkäämmän yhden askeleen. Aito orkestrointi tarkoittaa, että tekoälyllä on pysyvä, jäsennelty näkymä koko prosessiin — ei vain tähän tehtävään, vaan siihen, missä se sijaitsee sarjassa, mitä on jo tapahtunut ylävirrassa ja mitä on oltava totta alavirrassa, jotta se lasketaan valmiiksi. Ero on siinä, onko älykkyydellä muisti prosessista vai pelkkä muisti kehotteesta. Avustaja vastaa esittämääsi kysymykseen. Orkestrointi koordinoi toimintaa järjestelmien välillä, jotka eivät luonnollisesti puhu toistensa kanssa — ERP:si, CRM:si, kumppanin API — samalla perimällä samat säännöt, oikeudet ja auditointijäljen, jonka muu prosessi jo käyttää. Jos joudut rakentamaan erillisen hallintakerroksen AI-ominaisuutesi ympärille, koska alla oleva automaatioalusta sitä ei sisällä, sinulla ei ole agenttiorkestrointia — sinulla on chatbot, jolla on API-pääsy, eikä niiden riskiprofiilit ole lainkaan samat.

Koodittomat AI-agentit voivat mahdollistaa liiketoimintatiimien automatisoida yhä monimutkaisempia prosesseja odottamatta insinööriresursseja. Kuinka demokratisoida tämä kyky ilman, että syntyy uusi varjotekoälyn sukupolvi, huonosti suunniteltuja agenteja tai turvallisuusriskejä?

Et saa turvallista demokratisaatiota pyytämällä liiketoimintakäyttäjiä olemaan varovaisempia — saat sen tekemällä

tekemällä turvavälit osaksi päällystystä, eikä erilliseksi kaistaksi, jonka ihmiset joutuvat valitsemaan ajettavakseen. Jokainen liiketoimintakäyttäjän rakentama agentti perii samat roolipohjaiset käyttöoikeudet, saman auditointijäljen ja samat liiketoimintasäännöt, jotka jo hallitsevat prosessia, jossa se on rakennettu — ne eivät ole valinnaisia asetuksia, vaan rakenteellisia. Tämä on varjotekoälyn todellinen ratkaisu: kyse ei ole politiikkaongelmasta, vaan arkkitehtuuriongelmasta. Varjotekoäly syntyy, kun hyväksytty työkalu on vaikeampi käyttää kuin kielletty, jolloin ihmiset rakentavat agenttinsa henkilökohtaiselle ChatGPT-tilille tai satunnaiseen automaatiotyökaluun, jonka IT:llä ei ole näkyvyyttä. Jos kooditon kokemus on aidosti nopea ja hallinta on näkymätön, koska se on automaattinen, ei liiketoimintatiimillä ole syytä kiertää sitä. Heti kun teet hallinnasta manuaalisen vaiheen, jonka joku joutuu muistamaan, olet jo menettänyt.

Kun AI-agentit saavat kyvyn tehdä päätöksiä ja toteuttaa toimia pelkästään suositusten sijaan, miten organisaatioiden tulisi päättää, missä täysi autonomia on sopivaa ja missä ihmiset tulisi pitää mukana prosessissa?

Käytän akselia, joka ei ole “kuinka älykäs agentti on”, vaan palautettavuus ja räjähdysalue. Jos virheellinen päätös on halpaa havaita ja halpaa kumota — reititys, luokittelu, luonnostelu — anna agentin toimia ja tarkastaa tulokset yhdessä. Jos virheellinen päätös on kallis, vaikea peruuttaa tai koskettaa suoraan rahaa, sääntelyä tai asiakassuhdetta, pidä ihminen mukana kyseisessä vaiheessa, vaikka agentti olisi tehnyt viimeiset tuhat päätöstä oikein. Virhe on käsitellä autonomiaa yhtenä säätönä, jonka nostaa koko työnkululle. Todelliset prosessit ovat sarja vaiheita, joilla on hyvin erilaiset riskiprofiilit, ja oikea suunnittelu asettaa ihmisen juuri siihen vaiheeseen, jossa virhe on kallis — ei kaikkialle eikä missään. Tämä on myös syy siihen, miksi ihmisen mukanaolo, oikein toteutettuna, ei ole nopeuden vero — se on tapa rakentaa luottamus poistaa se lopulta matalariskisistä vaiheista, koska sinulla on todisteet, jotka osoittavat, mitkä päätökset agentti johdonmukaisesti tekee oikein.

Pipefy korostaa hallintaa mekanismeilla, kuten auditointijäljillä, roolipohjaisilla käyttöoikeusvalvonnilla, liiketoimintasäännöillä ja jäljitettävyyden itse työnkulussa. Tuleeko hallinnan upottaminen suoraan orkestrointikerrokseen olennaiseksi, kun yritykset siirtävät AI-agentteja kokeiluista tuotantoon?

Se ei ole vasta tuleva välttämättömyys — se on jo välttämätöntä, ja ne yritykset, jotka huomaavat sen kovan kautta, ovat ne, jotka siirsivät agentit tuotantoon ensin ja rakentavat nyt auditointijäljen jälkikäteen. Se on takaperin, ja korjaaminen jälkikäteen on kallista. Jos auditointijäljet, roolipohjainen pääsy ja jäljitettävyys eivät ole natiivisti orkestrointikerroksessa, jokainen uusi käyttöösi ottamasi agentti on uusi paikka, jossa hallinnointi voi hiljaisesti epäonnistua — eikä siitä selviä ennen kuin tarkastaja, sääntelijä tai tapaus nostaa kysymyksen. Hallinnoinnin upottaminen orkestrointikerrokseen tarkoittaa, että jokainen agentin tekemä toimenpide perii automaattisesti samat säännöt ja jättää samat todisteet kuin ihmistoimenpide, ilman että kenenkään tarvitsee muistaa konfiguroida se erikseen. Yritykset, jotka siirtyvät AI‑kokeista AI‑tuotantoon, huomaavat, että pilotin menestyskriteerit ja tuotannon menestyskriteerit ovat erilaiset: pilotin on toimittava, tuotannon on oltava puolustettavissa. Hallinnointi on se ero näiden kahden välillä.

Monet yritykset voivat osoittaa vaikuttavan AI‑pilotin, mutta kamppailevat sen muuttamisessa mitattavaksi liiketoiminta‑arvoksi. Mitä mittareita johtajien tulisi tarkastella määriteltäessä, tuottaako AI‑automaatiohanke todella ROI:ta, ja mitkä ovat yleisimmät syyt siihen, että lupaavat pilotit eivät skaalaudu?

En luota mihinkään AI‑ROI‑keskusteluun, joka alkaa sanoilla “säästetyt tunnit”, koska kuka on säästänyt tunteja ja miten se on varmistettu? Mittarit, jotka todella kestävät talousjohtajan tarkastelun, ovat asioita, jotka tarkastajat voivat itsenäisesti vahvistaa: tietyn prosessin läpimenoaika ennen ja jälkeen; virhe‑ tai uudelleentyöstöaste; sen työnkulun prosenttiosuus, joka nyt valmistuu ilman ihmisen kosketusta; sekä auditointijäljen kattavuus — voitko näyttää jokaiselle agenttipäätökselle, miksi se tehtiin. Jos et pysty tuottamaan tätä jälkeä, sinulla ei ole ROI‑lukua, vaan anekdootti. Pilotit epäonnistuvat skaalaamaan lähes aina samasta syystä: ne rakennettiin todistamaan mallin toimivuus, ei prosessin toimivuutta päästä‑päähän tuotannossa, integroituna järjestelmiin, joihin muu yritys jo luottaa. Hiekkalaatikossa elävä pilotti, joka on irti todellisesta tietojärjestelmästä, näyttää aina paremmalta kuin se suoriutuu, kun se kytketään kaikkiin jo käynnissä oleviin järjestelmiin. Skaalaus on järjestelmäintegraatio‑ongelma pukeutuneena AI‑asuun.

Olet myös johtanut organisaatiomuutoshankkeita Pipefyssa samalla kun olet ottanut käyttöön uusia AI‑ominaisuuksia. Kokemuksesi perusteella, kuinka suuri osa onnistuneesta yrity‑AI‑omaksumisesta on itse asiassa teknologia‑haaste versus prosessi‑, kulttuuri‑ ja muutosjohtamishaaste?

Jos olen rehellinen, onnistunut yritys‑AI‑omaksuminen on 20 % teknologiaa ja 80 % kaikkea muuta. Teknologia toimii suurimmaksi osaksi nyt — se ei ole se, mikä pitää minua hereillä yöllä. Se, mikä todella määrää, pysyykö AI‑hanke, on se, luottavatko työnsä muutoksesta vaikuttavat ihmiset järjestelmään riittävän paljon luopuaan kymmenen vuoden ajan tekemästään manuaalisesta tarkastuksesta, ja onko johto valmis suunnittelemaan prosessin uudelleen sen sijaan, että vain liimaisi AI:n vanhan päälle. Kävimme tämän läpi sisäisesti rakentaessamme omaa insinöörityökalupakettia — teknologia automatisoida osia siitä, miten rakennamme ohjelmistoja, oli olemassa pitkään ennen kuin tiimi todella luotti siihen riittävästi lopettaakseen kaiken manuaalisen kaksinkertaisen tarkistuksen. Avain ei ollut parempi malli, vaan näkyvä todiste, toistettuna riittävän monta kertaa, että järjestelmän arvio vastasi heidän omaansa. AI:n muutosjohtaminen ei ole viestintäharjoitus, vaan todisteiden keräämisharjoitus — ansaitset luottamuksen pienissä, todennettavissa olevissa erissä, etkä julista sitä yleiskokouksessa.

Kun katsomme tulevaisuutta, odotatko perinteisen työnkulku‑ ja liiketoimintaprosessiohjelmiston kehittyvän orkestrointikerroksiksi, joissa ihmiset, AI‑agentit ja yritysjärjestelmät tekevät jatkuvaa yhteistyötä? Jos kyllä, mikä muuttuu olennaisesti siinä, miten yritykset suunnittelevat ja hallinnoivat toimintaansa?

Kyllä, ja mielestäni muutos on suurempi kuin useimmat ihmiset arvioivat. Työnkulkuohjelmisto oli aiemmin paikka, jossa dokumentoit, miten työ tulisi suorittaa. Se on muuttumassa paikaksi, jossa työ todella tapahtuu — elävä suoritusympäristö, jossa ihmiset, agentit ja yritysjärjestelmät toimivat samassa hallitussa prosessissa samanaikaisesti, sen sijaan että ihminen käyttäisi ohjelmistoa passiivisena tietojen tallentajana jälkikäteen. Olennaisesti muuttuu se, missä “tietojärjestelmä” oikeasti sijaitsee. Aikaisemmin tietue oli tietokanta, joka päivittyi sen jälkeen, kun jokin tapahtui sen ulkopuolella. Orkestrointikerroksessa tietue ja suoritus ovat sama asia — prosessi itsessään muuttuu käyttöliittymäksi, johon pääsee käsiksi ei vain näytön kautta vaan myös API:n, MCP‑palvelimen, CLI:n kautta, jolloin mikä tahansa agentti, sisäinen tai kumppanin, voi toimia sen sisällä samoilla säännöillä kuin ihminen. Yritykset, jotka näkevät tämän muutoksen “lisää AI nykyisiin työkaluihini”, kohtaavat edelleen aiemmin kuvaamani rajan. Ne, jotka pitävät prosessikerrosta itse tuotteena — investoinnin arvoisena rakenteellisesti, ovat ne, jotka moninkertaistavat edun, jota kukaan ei voi kopioida pelkästään ostamalla saman AI‑mallin.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa käydä osoitteessa Pipefy.