Sobhan Daliry, CPO & AI Strategy Leader på Pipefy – Intervjuserie

Sobhan Daliry, CPO & AI Strategy Leader på Pipefy, är en erfaren produkt- och teknikchef som har lett företagets AI‑strategi sedan 2023 och hjälper till att omvandla traditionella affärsarbetsflöden till allt mer intelligenta och autonoma processer. Genom sin karriär har Daliry kombinerat produktstrategi, organisatorisk transformation och tekniskt ledarskap både i startups och etablerade företag. Innan han gick med i Pipefy grundade han och var VD för Polen.me och tillbringade mer än fem år som VD/CPO för NZN, där han ledde företagets vändning och produktstrategi. Hans tidigare roller inkluderar Produktchef på PSafe, Produktchef på Peixe Urbano samt positioner inom digitala tjänster, telekommunikation, konsultverksamhet och affärsutveckling på Oi/Telemar, Claro, AIRCOM International och Planeta Tecnologia.

Pipefy är en global plattform för processhantering och AI som är utformad för att hjälpa organisationer att automatisera och orkestrera affärsarbetsflöden. Företaget grundades 2015 och har utvecklats från en no‑code plattform för processautomatisering till en AI‑fokuserad orkestreringsmiljö som samlar AI‑agenter, arbetsflöden, formulär, portaler, applikationer, data, analyser, meddelanden och integrationer. Plattformen gör det möjligt för team att skapa och hantera AI‑agenter med naturligt språk och no‑code‑verktyg samtidigt som företagsstyrning, säkerhet och insyn upprätthålls. Pipefys AI‑funktioner inkluderar agenter som kan tolka dokument, utföra arbetsflödesteg, stödja beslutsfattande, interagera med externa system och orkestrera processer inom områden som ekonomi, personal, inköp, kundoperationer och efterlevnad.

Din karriär har tagit dig från telekomteknik på företag som Claro och Oi till produktledarskap på Peixe Urbano och PSafe, där du var VD/CPO på NZN, grundade Polen.me och nu leder produkt- och AI‑strategi på Pipefy. Hur har den utvecklingen påverkat ditt sätt att tänka kring att bygga AI‑produkter som löser verkliga operativa problem snarare än att bara visa upp ny teknik?

Telekom lärde mig att infrastruktur måste fungera varje gång, i massiv skala, utan någon marginal för ”det fungerar mestadels”. Ett avbrutet samtal är inte ett demo‑misslyckande, det är en kund som går därifrån. Den mentaliteten — pålitlighet framför nyhet — har aldrig lämnat mig. På Peixe Urbano och PSafe lärde jag mig den motsatta lärdomen: hur snabbt konsumentprodukter lever eller dör beroende på om de löser ett verkligt, upplevt problem idag, inte ett teoretiskt. Att leda NZN som VD/CPO tvingade mig att hålla båda sanningarna samtidigt — du kan inte överträffa en dålig tes, och du kan inte överträffa dålig genomförande. Att grunda Polen.me lärde mig den dyraste lärdomen av alla: kapital och tid är begränsade, så varje funktion du bygger är en funktion du inte byggde, och kostnaden för att jaga en imponerande demo istället för ett riktigt arbetsflöde visar sig månader senare, inte på scenen. När jag kom till Pipefy är frågan jag ställer om varje AI‑funktion densamma som jag skulle ställa om ett mobilmast: håller den upp i produktion, under verklig belastning, när ingen ser på? Om en AI‑agent bara fungerar i en kuraterad demo‑miljö är den inte en produkt — den är en trailer för en.

Du har lett formuleringen och implementeringen av Pipefys AI‑strategi sedan 2023. Vilka antaganden om företags‑AI hade du i början som har förändrats mest när generativ AI och AI‑agenter har mognat?

Det största antagandet jag var tvungen att släppa var att modellen skulle vara flaskhalsen. År 2023 optimerade alla — inklusive jag — för ”vilken LLM är smartast”. Det som i själva verket visade sig vara flaskhalsen var kontexten: vet agenten vad processen faktiskt är, vilka ramar som gäller, hur ”klart” ser ut för just den kundens version av leverantörsreskontra. Modellens kvalitet fortsatte att förbättras på en kurva som alla kunde se komma; processkontexten förbättrades inte av sig själv, eftersom ingen hade strukturerat den. Det andra antagandet som vände på sig handlade om autonomi. Jag antog att marknaden ville ha agenter som agerade helt självständigt så snabbt som möjligt. Vad företag faktiskt ville — och fortfarande vill — är begränsad autonomi: agenter som fattar verkliga beslut inom regler de inte får bryta, med ett spår som bevisar det i efterhand. Full autonomi utan styrning är inte ambition, det är bara risk med ett bättre UI. Marknaden mognade snabbare på krav på förtroende än på rena kapabilitetskrav, och den omordningen är det största misstaget jag gjorde i början.

Pipefy skiljer mellan relativt enkel AI‑automatisering och AI‑agenter som kan resonera i tvetydiga situationer, planera flera steg och utföra åtgärder över ett arbetsflöde. Hur bör företag avgöra när en uppgift faktiskt kräver en AI‑agent kontra när deterministisk automatisering fortfarande är den bättre lösningen?

Testet jag använder är enkelt: om du kan skriva regeln, skriv regeln. Deterministisk automation är fortfarande rätt svar för allt där beslutsträdet är känt i förväg och inte förändras — dirigera den här fakturan till den här godkännaren om den är under detta belopp. Det är inte ett jobb för en agent, och att låtsas att det är det lägger bara till latens och oförutsägbarhet till något som redan är löst. En agent förtjänar sin plats så snart situationen har en tvetydighet som en fast regel inte kan lösa — fakturan matchar inte inköpsordern exakt, det saknas ett fält, kundens begäran passar ingen av dina befintliga kategorier. Det är där resonemang har verkligt värde: att besluta vad som ska göras härnäst när “nästa” inte redan är nedskrivet. Misstaget jag ständigt ser företag göra är att bygga en agent för de 80 % av fallen som redan var deterministiska, för att det är flashigare, och lämna de tvetydiga 20 % — den faktiska svåra delen — åt en människa att manuellt reda ut. Vänder du på förhållandet har du byggt något riktigt.

Det sker en växande övergång från fristående copilot‑lösningar till “agentisk orkestrering”, där AI kan samordna processer som spänner över flera system. Vad skiljer äkta agentisk orkestrering från att bara lägga till en stor språkmodell till en befintlig automationsplattform?

Att släppa in en LLM‑nod i ett befintligt automationsflöde ger dig ett smartare ensteg. Äkta orkestrering innebär att AI har en bestående, strukturerad vy över hela processen — inte bara denna uppgift, utan var den sitter i sekvensen, vad som redan har hänt tidigare i kedjan, och vad som måste vara sant längre ner för att detta ska räknas som slutfört. Skillnaden är om intelligensen har minne av processen eller bara minne av prompten. En copilot svarar på den fråga du ställer till den. Orkestrering koordinerar handlingar över system som inte naturligt kommunicerar med varandra — ditt ERP, ditt CRM, en partners API — samtidigt som den ärver samma regler, behörigheter och spårningslogg som resten av processen redan kör på. Om du måste bygga ett separat styrningslager runt din AI‑funktion eftersom automationsplattformen under den inte har ett, har du ingen agentisk orkestrering — du har en chatbot med API‑åtkomst, och de har helt annan riskprofil.

No‑code AI‑agenter kan potentiellt låta affärsteam automatisera allt mer komplexa processer utan att vänta på ingenjörsresurser. Hur demokratiserar du den förmågan utan att skapa en ny generation av skugg‑AI, dåligt designade agenter eller säkerhetsrisker?

Du får inte säker demokratisering genom att be affärsanvändare vara mer försiktiga — du får den genom

att göra skyddsräcken till en del av vägen, inte en separat körbana som folk måste välja att köra i. Varje agent som en affärsanvändare bygger ärver samma rollbaserade åtkomst, samma spårningslogg och samma affärsregler som redan styr processen den byggs i — de är inte valfria konfigurationer, de är strukturella. Det är det faktiska svaret på skugg‑AI: det är inte ett policyproblem, det är ett arkitekturproblem. Skugg‑AI uppstår när det godkända verktyget är svårare att använda än det oauktoriserade, så folk bygger sin agent i ett personligt ChatGPT‑konto eller ett slumpmässigt automationsverktyg utan någon synlighet för IT. Om no‑code‑upplevelsen verkligen är snabb och styrningen är osynlig eftersom den är automatisk, finns det ingen anledning för ett affärsteam att gå runt den. Så snart du gör styrning till ett manuellt steg som någon måste komma ihåg, har du redan förlorat.

När AI‑agenter får förmågan att fatta beslut och utföra handlingar snarare än bara rekommendera dem, hur bör organisationer avgöra var full autonomi är lämplig och var människor bör behålla kontrollen?

Den axel jag använder är inte “hur smart agenten är”, utan återhämtningsförmåga och sprängradie. Om ett felaktigt beslut är billigt att upptäcka och billigt att återkalla — dirigering, kategorisering, utkast — låt agenten agera och granska i aggregat. Om ett felaktigt beslut är dyrt, svårt att återkalla, eller berör pengar, efterlevnad eller en kundrelation direkt, behåll en människa i loopen för just det steget, även om agenten har gjort de senaste tusen besluten rätt. Misstaget är att behandla autonomi som en enda ratt du vrider upp för hela arbetsflödet. Verkliga processer är en sekvens av steg med mycket olika riskprofiler, och rätt design placerar människan exakt vid det steg där ett misstag är dyrt — inte överallt och inte ingenstans. Det är också därför människa‑i‑loopen, när det görs rätt, inte är en hastighetsskatt — det är så du bygger förtroendet för så småningom att ta bort den från låg‑risk‑steg, eftersom du har bevisen för att visa vilka beslut agenten konsekvent får rätt.

Pipefy betonar styrning genom mekanismer som spårningsloggar, rollbaserade åtkomstkontroller, affärsregler och spårbarhet inom själva arbetsflödet. Blir det avgörande att bädda in styrning direkt i orkestreringslagret när företag flyttar AI‑agenter från experiment till produktion?

Det blir inte bara viktigt — det är redan så, och de företag som får detta på den hårda vägen är de som först skickade agenter i produktion och nu bygger revisionsspåret i efterhand. Det är baklänges och dyrt att åtgärda retroaktivt. Om revisionsspår, rollbaserad åtkomst och spårbarhet inte är inbyggda i orkestreringslagret självt, blir varje ny agent du distribuerar en ny plats där styrning tyst kan misslyckas — och du kommer inte att upptäcka det förrän en revisor, en regulator eller en incident ställer frågan. Att bädda in styrning i orkestreringslagret innebär att varje handling en agent utför automatiskt ärver samma regler och lämnar samma bevis som en mänsklig handling skulle, utan att någon behöver komma ihåg att konfigurera det separat. Företag som går från AI‑experiment till AI i produktion upptäcker att pilotens framgångskriterier och produktionsens framgångskriterier är olika: en pilot måste fungera, produktionen måste vara försvarbar. Styrning är skillnaden mellan dessa två staplar.

Många företag kan visa upp en imponerande AI‑pilot men har svårt att omvandla den till mätbart affärsvärde. Vilka nyckeltal bör ledare fokusera på när de avgör om ett AI‑automatiseringsinitiativ verkligen levererar avkastning, och vad är de vanligaste orsakerna till att lovande piloter misslyckas med att skala?

Jag litar inte på någon AI‑ROI‑diskussion som börjar med ”sparade timmar”, för vem sparade timmarna och hur verifieras det? De nyckeltal som faktiskt håller upp under CFO‑granskning är sådant som revisorer kan bekräfta oberoende: cykeltid för en specifik process, före och efter; fel‑ eller omarbetningsgrad; andelen av ett arbetsflöde som nu slutförs utan mänsklig inblandning; och täckning av revisionslinjer – kan du visa, för varje agentbeslut, varför det fattades. Om du inte kan producera det spåret har du ingen ROI‑siffra, du har en anekdot. Piloter misslyckas nästan alltid med att skala av samma anledning: de byggdes för att bevisa att modellen fungerar, inte för att bevisa att processen fungerar end‑to‑end i produktion, integrerad med de system som resten av företaget redan är beroende av. En pilot som lever i en sandlåda, frånkopplad från det verkliga systemet av register, kommer alltid att se bättre ut än den presterar när den väl är kopplad till allt annat som redan körs. Skalning är ett systemintegrationsproblem klätt i en AI‑kostym.

Du har också lett organisatoriska förändringsinitiativ på Pipefy samtidigt som du introducerade nya AI‑funktioner. Utifrån din erfarenhet, hur stor del av framgångsrik företags‑AI‑adoption är egentligen en teknisk utmaning jämfört med en process‑, kultur‑ och förändringshanteringsutmaning?

Om jag är ärlig, så är framgångsrik företags‑AI‑adoption 20 % teknik och 80 % allt annat. Tekniken fungerar i stort sett nu – det är inte där jag förlorar sömnen. Vad som faktiskt avgör om ett AI‑initiativ håller är om de personer vars arbete förändras litar på systemet tillräckligt för att släppa den manuella kontroll de har gjort i tio år, och om ledningen är villig att omdesigna processen istället för att bara klistra AI ovanpå den gamla. Vi gick igenom detta internt när vi byggde våra egna ingenjörsverktyg – tekniken för att automatisera delar av hur vi bygger mjukvara fanns långt innan teamet faktiskt litade på den nog för att sluta dubbelkolla allt för hand. Genombrottet var inte en bättre modell, utan ett synligt bevis, upprepat tillräckligt många gånger, att systemets bedömning matchade deras. Förändringshantering för AI är inte en kommunikationsövning, det är en evidens‑ackumuleringsövning – du tjänar förtroende i små, verifierbara batcher, du deklarerar det inte i ett town hall‑möte.

Ser du framåt, förväntar du dig att traditionell arbetsflödes‑ och affärsprocessprogramvara utvecklas till orkestreringslager där människor, AI‑agenter och företagssystem kontinuerligt samarbetar? Om så är fallet, vad kommer fundamentalt att förändras i hur företag designar och hanterar sina verksamheter?

Ja, och jag tror att skiftet är större än vad de flesta räknar med. Arbetsflödesprogramvara brukade vara där du dokumenterade hur arbete skulle utföras. Den blir nu platsen där arbete faktiskt sker – ett levande körningsmiljö där människor, agenter och företagssystem alla agerar inom samma styrda process samtidigt, istället för att en människa använder programvaran som en passiv registerhållare i efterhand. Det som förändras fundamentalt är var “systemet av rekord” faktiskt finns. Rekordet var tidigare en databas som uppdaterades när något redan hade hänt utanför den. I ett orkestreringslager är rekordet och exekveringen samma sak – processen blir själva gränssnittet, tillgängligt inte bara via en skärm utan via ett API, en MCP‑server, en CLI, så att vilken agent som helst, intern eller från en partner, kan agera i den under samma regler som en människa skulle. Företag som behandlar detta skifte som ”lägg till AI i mina befintliga verktyg” kommer fortsätta stöta på den tak som jag beskrev tidigare. De som ser sitt processlager som den faktiska produkten – det som är värt att investera i att strukturera ordentligt – är de som kommer att bygga en fördel som ingen kan kopiera bara genom att köpa samma AI‑modell.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka Pipefy.