Sobhan Daliry, CPO & AI-strategileder i Pipefy – Intervjuserie

Sobhan Daliry, CPO & AI‑strategileder i Pipefy, er en erfaren produkt‑ og teknologiekspert som har ledet selskapets AI‑strategi siden 2023, og hjelper med å transformere tradisjonelle forretningsprosesser til stadig smartere og autonome prosesser. Gjennom karrieren har Daliry kombinert produktstrategi, organisatorisk transformasjon og teknologiledelse i både oppstartsbedrifter og etablerte selskaper. Før han begynte i Pipefy, grunnla han og var administrerende direktør i Polen.me og tilbrakte mer enn fem år som CEO/CPO i NZN, hvor han ledet selskapets turnaround og produktstrategi. Tidligere har han hatt roller som Director of Product Management i PSafe, Product Manager i Peixe Urbano, samt stillinger innen digitale tjenester, telekommunikasjon, konsulentvirksomhet og forretningsutvikling i Oi/Telemar, Claro, AIRCOM International og Planeta Tecnologia.

Pipefy er en global prosessstyrings‑ og AI‑plattform designet for å hjelpe organisasjoner med å automatisere og orkestrere forretningsarbeidsflyter. Selskapet ble grunnlagt i 2015 og har utviklet seg fra en plattform for automatisering uten kode til et AI‑fokusert orkestreringsmiljø som samler AI‑agenter, arbeidsflyter, skjemaer, portaler, applikasjoner, data, analyse, meldinger og integrasjoner. Plattformen gjør det mulig for team å opprette og administrere AI‑agenter ved hjelp av naturlig språk og verktøy uten kode, samtidig som de opprettholder bedriftsstyring, sikkerhet og synlighet. Pipefy sine AI‑kapasiteter inkluderer agenter som kan tolke dokumenter, utføre arbeidsflytoppgaver, støtte beslutningstaking, samhandle med eksterne systemer og orkestrere prosesser innen områder som økonomi, personal, innkjøp, kundedrift og etterlevelse.

Karrieren din har tatt deg fra telekom‑ingeniørarbeid i selskaper som Claro og Oi til produktledelse i Peixe Urbano og PSafe, der du har vært CEO/CPO i NZN, grunnlagt Polen.me, og nå leder produkt‑ og AI‑strategi i Pipefy. Hvordan har den utviklingen påvirket måten du tenker på når du bygger AI‑produkter som løser reelle driftsproblemer i stedet for bare å vise frem ny teknologi?

Telekom lærte meg at infrastruktur må fungere hver eneste gang, i massiv skala, uten rom for «det fungerer mesteparten av tiden». Et mistet anrop er ikke en demo‑feil, det er en kunde som går bort. Den mentaliteten — pålitelighet over nyvinning — har aldri forlatt meg. Hos Peixe Urbano og PSafe lærte jeg det motsatte: hvor raskt forbrukerprodukter lever eller dør avhengig av om de løser et reelt, følt problem i dag, ikke et teoretisk ett. Å lede NZN som CEO/CPO tvang meg til å holde begge sannhetene samtidig — du kan ikke overgå en dårlig tese, og du kan ikke overgå dårlig utførelse med en bedre tese. Å grunnlegge Polen.me ga meg den dyreste leksjonen av alle: kapital og tid er begrenset, så hver funksjon du bygger er en funksjon du ikke bygde, og kostnaden ved å jage en imponerende demo i stedet for en reell arbeidsflyt viser seg måneder senere, ikke på scenen. Da jeg kom til Pipefy, er spørsmålet jeg stiller om hver AI‑funksjon det samme som jeg ville stille om en mobilmast: holder dette i produksjon, under reell belastning, når ingen ser på? Hvis en AI‑agent kun fungerer i et kuratert demo‑miljø, er det ikke et produkt — det er en trailer for et produkt.

Du har ledet utformingen og implementeringen av Pipefy sin AI‑strategi siden 2023. Hvilke antakelser du hadde om bedrifts‑AI i starten, har endret seg mest etter hvert som generativ AI og AI‑agenter har modnet?

Den største antakelsen jeg måtte kvitte meg med, var at modellen skulle være flaskehalsen. I 2023 optimaliserte alle — meg inkludert — for «hvilken LLM er smartest». Det som faktisk viste seg å være flaskehalsen, var kontekst: vet agenten hva prosessen egentlig er, hva retningslinjene er, hvordan «ferdig» ser ut for denne spesifikke kundens versjon av leverandørgjeld. Modellkvaliteten fortsatte å forbedre seg langs en kurve alle kunne se komme; prosesskonteksten forbedret seg ikke av seg selv, fordi ingen hadde strukturert den. Den andre antakelsen som snudde, handlet om autonomi. Jeg antok at markedet ønsket agenter som handlet helt uavhengig så raskt som mulig. Det bedrifter faktisk ønsket — og fortsatt ønsker — er begrenset autonomi: agenter som tar reelle beslutninger innenfor regler de ikke kan bryte, med et spor som beviser det i etterkant. Full autonomi uten styring er ikke ambisjon, det er bare risiko med et bedre brukergrensesnitt. Markedet modnet raskere på krav til tillit enn på krav til rå kapasitet, og denne omprioriteringen er den største feilen jeg gjorde i starten.

Pipefy skiller mellom relativt enkel AI‑automatisering og AI‑agenter som kan resonere gjennom tvetydige situasjoner, planlegge flere trinn og utføre handlinger på tvers av en arbeidsflyt. Hvordan bør bedrifter avgjøre når en oppgave faktisk krever en AI‑agent, versus når deterministisk automatisering fortsatt er den beste løsningen?

Testen jeg bruker er enkel: hvis du kan skrive regelen, skriv regelen. Deterministisk automatisering er fortsatt det rette svaret for alt der beslutningstreet er kjent på forhånd og ikke endres — rute denne fakturaen til denne godkjenneren hvis den er under dette beløpet. Det er ikke en oppgave for en agent, og å late som om det er det legger bare til latens og uforutsigbarhet til noe som allerede var løst. En agent fortjener sin plass i det øyeblikket situasjonen har tvetydighet en fast regel ikke kan løse — fakturaen samsvarer ikke nøyaktig med PO-en, det mangler et felt, kundens forespørsel passer ikke inn i noen av dine eksisterende kategorier. Det er her resonnering har reell verdi: å bestemme hva som skal gjøres neste når «neste» ikke allerede er skrevet ned. Feilen jeg ser bedrifter gjøre konstant er å bygge en agent for de 80 % av tilfellene som allerede var deterministiske, fordi det er mer imponerende, og la den tvetydige 20 % — den faktiske vanskelige delen — til et menneske som må løse manuelt. Snur du den fordelingen, har du bygget noe reelt.

Det er en økende overgang fra frittstående copilot‑løsninger til «agentisk orkestrering», der AI kan koordinere prosesser som spenner over flere systemer. Hva skiller ekte agentisk orkestrering fra bare å legge til en stor språkmodell i en eksisterende automatiseringsplattform?

Å slippe inn en LLM‑node i en eksisterende automatiseringsflyt gir deg et smartere enkelttrinn. Ekte orkestrering betyr at AI har en vedvarende, strukturert oversikt over hele prosessen — ikke bare denne oppgaven, men hvor den sitter i sekvensen, hva som allerede har skjedd oppstrøms, hva som må være sant nedstrøms for at dette skal regnes som fullført. Forskjellen er om intelligensen har minne om prosessen eller bare minne om prompten. En copilot svarer på spørsmålet du stiller den. Orkestrering koordinerer handlinger på tvers av systemer som ikke naturlig snakker med hverandre — ditt ERP, ditt CRM, en partners API — samtidig som den arver de samme reglene, tillatelsene og revisjonssporene som resten av prosessen allerede kjører på. Hvis du må bygge et eget styringslag rundt AI‑funksjonen fordi automatiseringsplattformen under den ikke har ett, har du ikke agentisk orkestrering — du har en chatbot med API‑tilgang, og de har helt andre risikoprofiler.

No‑code AI‑agenter kan potensielt la forretningsteam automatisere stadig mer komplekse prosesser uten å vente på ingeniørressurser. Hvordan demokratiserer du den evnen uten å skape en ny generasjon av shadow AI, dårlig designede agenter eller sikkerhetsrisikoer?

Du får ikke sikker demokratisering ved å be forretningbrukere være mer forsiktige — du får det ved

å gjøre rekkverkene til en del av veibanen, ikke en egen fil folk må velge å kjøre i. Hver agent en forretningsbruker bygger arver samme rollebaserte tilgang, samme revisjonsspor og samme forretningsregler som allerede styrer prosessen den er bygget i — de er ikke valgfrie konfigurasjoner, de er strukturelle. Det er det egentlige svaret på shadow AI: det er ikke et policy‑problem, det er et arkitekturproblem. Shadow AI oppstår når det godkjente verktøyet er vanskeligere å bruke enn det uautoriserte, så folk bygger sin agent i en personlig ChatGPT‑konto eller et tilfeldig automatiseringsverktøy uten synlighet for IT. Hvis no‑code‑opplevelsen er genuint rask og styringen er usynlig fordi den er automatisk, er det ingen grunn til at et forretningsteam skal gå rundt den. I det øyeblikk du gjør styringen til et manuelt trinn noen må huske, har du allerede tapt.

Når AI‑agenter får evnen til å ta beslutninger og utføre handlinger i stedet for bare å anbefale dem, hvordan skal organisasjoner avgjøre hvor full autonomi er passende og hvor mennesker bør forbli i sløyfen?

Aksen jeg bruker er ikke «hvor smart agenten er», men reversibilitet og sprengningsradius. Hvis en feil beslutning er billig å oppdage og billig å angre — ruting, kategorisering, utkast — la agenten handle og gjennomgå i aggregat. Hvis en feil beslutning er dyr, vanskelig å reversere, eller berører penger, etterlevelse eller et kundeforhold direkte, behold et menneske i sløyfen for akkurat det steget, selv om agenten har tatt de siste tusen beslutningene riktig. Feilen er å behandle autonomi som en enkelt innstilling du skrur opp for hele arbeidsflyten. Reelle prosesser er en sekvens av trinn med svært ulike risikoprofiler, og riktig design plasserer mennesket akkurat på det steget hvor en feil er kostbar — ikke overalt og ikke ingen steder. Det er også grunnen til at menneske‑i‑sløyfen, gjort riktig, ikke er en skatt på hastighet — det er hvordan du bygger tilliten til etter hvert å fjerne den fra lav‑risikosteg, fordi du har bevisene som viser hvilke beslutninger agenten konsekvent tar riktig.

Pipefy legger vekt på styring gjennom mekanismer som revisjonsspor, rollebaserte tilgangskontroller, forretningsregler og sporbarhet innen selve arbeidsflyten. Blir innbygging av styring direkte i orkestreringslaget essensielt etter hvert som selskaper flytter AI‑agenter fra eksperimenter til produksjon?

Det er ikke noe som blir viktig — det er allerede viktig, og selskapene som oppdager dette på den harde måten er de som først satte agenter i produksjon og nå bygger revisjonssporet i etterkant. Det er baklengs, og det er dyrt å rette opp i ettertid. Hvis revisjonsspor, rollebasert tilgang og sporbarhet ikke er innebygd i orkestreringslaget selv, blir hver ny agent du distribuerer et nytt sted hvor styring kan svikte stille — og du vil ikke oppdage det før en revisor, en regulator eller en hendelse stiller spørsmålet. Å bygge styring inn i orkestreringslaget betyr at hver handling en agent utfører automatisk arver de samme reglene og etterlater samme bevis som en menneskelig handling ville gjort, uten at noen må huske å konfigurere det separat. Bedrifter som går fra AI‑eksperimenter til AI i produksjon oppdager at pilotens suksesskriterier og produksjonens suksesskriterier er forskjellige: en pilot må fungere, produksjon må være forsvarlig. Styring er forskjellen mellom de to nivåene.

Mange selskaper kan demonstrere en imponerende AI‑pilot, men sliter med å omsette den til målbar forretningsverdi. Hvilke måleparametre bør ledere fokusere på når de skal avgjøre om en AI‑automatiseringsinitiativ virkelig leverer avkastning, og hva er de vanligste årsakene til at lovende piloter mislykkes i skalering?

Jeg har liten tillit til noen AI‑ROI‑diskusjon som starter med «timer spart», fordi hvem har spart timer, og hvordan er det verifisert? De målene som faktisk holder seg under CFO‑granskning er ting revisorer kan bekrefte uavhengig: syklustid på en spesifikk prosess, før og etter; feil‑ eller omarbeidingsrate; prosentandelen av en arbeidsflyt som nå fullføres uten menneskelig inngrep; og revisjonslinjedekning — kan du vise, for hver agentbaserte beslutning, hvorfor den ble tatt. Hvis du ikke kan produsere det sporet, har du ingen ROI‑tall, bare en anekdote. Piloter mislykkes i skalering nesten alltid av samme grunn: de ble bygget for å bevise at modellen fungerer, ikke for å bevise at prosessen fungerer ende‑til‑ende i produksjon, integrert med systemene resten av selskapet allerede er avhengig av. En pilot som lever i en sandkasse, frakoblet fra det virkelige systemet av poster, vil alltid se bedre ut enn den presterer når den er koblet inn i alt annet som allerede kjører. Skalering er et systemintegrasjonsproblem med et AI‑kostyme på.

Du har også ledet organisasjonsendringsinitiativer i Pipefy samtidig som du introduserte nye AI‑funksjoner. Basert på din erfaring, hvor mye av vellykket bedrifts‑AI‑adopsjon egentlig er en teknologisk utfordring versus en prosess‑, kultur‑ og endringsledelsesutfordring?

Hvis jeg er ærlig, er vellykket bedrifts‑AI‑adopsjon 20 % teknologi og 80 % alt annet. Teknologien fungerer stort sett nå — det er ikke det som holder meg våken om natten. Det som egentlig avgjør om en AI‑initiativ holder, er om folkene hvis jobb endres, stoler på systemet nok til å slippe den manuelle sjekken de har gjort i ti år, og om ledelsen er villig til å redesigne prosessen i stedet for bare å lime AI på toppen av den gamle. Vi gikk gjennom dette internt ved å bygge våre egne ingeniørverktøy — teknologien for å automatisere deler av hvordan vi bygger programvare eksisterte lenge før teamet faktisk stolte på den nok til å slutte å dobbeltsjekke alt manuelt. Løsningen var ikke en bedre modell, men synlig bevis, gjentatt nok ganger, at systemets vurdering samsvarte med deres. Endringsledelse for AI er ikke en kommunikasjonsøvelse, det er en bevis‑akkumuleringsøvelse — du tjener tillit i små, verifiserbare batcher, du erklærer det ikke i en allmøte‑tale.

Ser du for deg at tradisjonell arbeidsflyt‑ og forretningsprosess‑programvare vil utvikle seg til orkestreringslag hvor mennesker, AI‑agenter og bedriftsystemer kontinuerlig samarbeider? I så fall, hva vil fundamentalt endre seg i hvordan selskaper designer og styrer sine operasjoner?

Ja, og jeg tror skiftet er større enn de fleste innregner. Arbeidsflyt‑programvare pleide å være stedet hvor du dokumenterte hvordan arbeid skulle foregå. Den blir nå stedet hvor arbeidet faktisk skjer — en levende kjøretid hvor mennesker, agenter og bedriftsystemer alle handler innenfor samme styrte prosess samtidig, i stedet for at et menneske bruker programvaren som en passiv arkivfører i ettertid. Det som endrer seg fundamentalt, er hvor «systemet av poster» faktisk befinner seg. Posten var tidligere en database som ble oppdatert etter at noe allerede hadde skjedd utenfor den. I et orkestreringslag er posten og utførelsen én og samme ting — prosessen blir selve grensesnittet, tilgjengelig ikke bare via en skjerm, men via et API, en MCP‑server, en CLI, slik at enhver agent, intern eller fra en partner, kan handle innenfor den under de samme reglene som et menneske ville gjort. Selskaper som behandler dette skiftet som «legg AI til mine eksisterende verktøy», vil fortløpende treffe taket jeg beskrev tidligere. De som ser prosesslaget som selve produktet — det som er verdt å investere i å strukturere riktig — er de som vil forsterke en fordel ingen kan kopiere bare ved å kjøpe den samme AI‑modellen.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Pipefy.