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

Sobhan Daliry, CPO & AI Strategy Leader hos Pipefy, er en erfaren produkt‑ og teknologiekspert, som har ledet virksomhedens AI‑strategi siden 2023 og hjælper med at omdanne traditionelle forretningsprocesser til stadig mere intelligente og autonome processer. Gennem sin karriere har Daliry kombineret produktstrategi, organisatorisk transformation og teknologisk ledelse på tværs af startups og etablerede virksomheder. Før han sluttede sig til Pipefy, grundlagde han og var administrerende direktør for Polen.me og tilbragte mere end fem år som CEO/CPO for NZN, hvor han ledede virksomhedens turnaround og produktstrategi. Hans tidligere roller omfatter Direktør for produktstyring hos PSafe, Produktchef hos Peixe Urbano samt stillinger inden for digitale tjenester, telekommunikation, rådgivning og forretningsudvikling hos Oi/Telemar, Claro, AIRCOM International og Planeta Tecnologia.

Pipefy er en global processtyrings‑ og AI‑platform designet til at hjælpe organisationer med at automatisere og orkestrere forretningsarbejdsgange. Grundlagt i 2015 har virksomheden udviklet sig fra en no‑code procesautomatiseringsplatform til et AI‑fokuseret orkestreringsmiljø, der samler AI‑agenter, arbejdsgange, formularer, portaler, applikationer, data, analyser, beskeder og integrationer. Platformen gør det muligt for teams at skabe og administrere AI‑agenter ved hjælp af naturligt sprog og no‑code‑værktøjer, samtidig med at de opretholder virksomhedsstyring, sikkerhed og synlighed. Pipefy’s AI‑funktioner omfatter agenter, der kan fortolke dokumenter, udføre arbejdsgangopgaver, understøtte beslutningstagning, interagere med eksterne systemer og orkestrere processer på tværs af områder som økonomi, personale, indkøb, kundedrift og overholdelse.

Din karriere har ført dig fra telekommunikationsengineering i virksomheder som Claro og Oi til produktledelse hos Peixe Urbano og PSafe, hvor du har været CEO/CPO for NZN, grundlagt Polen.me og nu leder produkt- og AI‑strategi hos Pipefy. Hvordan har den udvikling formet din måde at tænke på, når du bygger AI‑produkter, der løser reelle operationelle problemer i stedet for blot at vise ny teknologi?

Telekommunikation lærte mig, at infrastruktur skal fungere hver eneste gang, i massiv skala, uden plads til “det fungerer mest”. Et tabt opkald er ikke en demofejl, det er en kunde, der går væk. Den mentalitet — pålidelighed frem for nyhed — har jeg aldrig mistet. Hos Peixe Urbano og PSafe lærte jeg den modsatte lektie: hvor hurtigt forbrugerprodukter lever eller dør afhængigt af, om de løser et reelt, følt problem i dag, ikke et teoretisk et. At lede NZN som CEO/CPO tvang mig til at holde begge sandheder samtidig — du kan ikke overgå en dårlig tese med hurtigere udførelse, og du kan ikke overgå dårlig udførelse med en bedre tese. At grundlægge Polen.me lærte mig den dyreste lektie af alle: kapital og tid er begrænsede, så hver funktion du bygger er en funktion, du ikke har bygget, og omkostningerne ved at jagte en imponerende demo i stedet for en reel arbejdsgang viser sig måneder senere, ikke på scenen. Da jeg kom til Pipefy, er spørgsmålet, jeg stiller om hver AI‑funktion, det samme, som jeg ville stille om et mobilmast: holder den i produktion under reelt belastning, når ingen ser på? Hvis en AI‑agent kun fungerer i et kurateret demomiljø, er den ikke et produkt — den er en trailer til et produkt.

Du har ledt formuleringen og implementeringen af Pipefy’s AI‑strategi siden 2023. Hvilke antagelser om enterprise‑AI havde du i starten, som har ændret sig mest, efterhånden som generativ AI og AI‑agenter er modne?

Den største antagelse, jeg måtte afvise, var, at modellen ville være flaskehalsen. I 2023 optimerede alle — inklusiv mig — for “hvilken LLM er smartest.” Det, der i virkeligheden viste sig at være flaskehalsen, var kontekst: ved agenten, hvad processen egentlig er, hvad begrænsningerne er, hvordan “færdig” ser ud for netop denne kundes version af leverandørregnskab. Modelkvaliteten fortsatte med at forbedre sig på en kurve, som alle kunne se komme; proceskonteksten forbedrede sig ikke af sig selv, fordi ingen havde struktureret den. Den anden antagelse, der vendte, handlede om autonomi. Jeg antog, at markedet ønskede agenter, der handlede fuldstændig uafhængigt så hurtigt som muligt. Hvad virksomheder faktisk ønskede — og stadig ønsker — er begrænset autonomi: agenter, der træffer reelle beslutninger inden for regler, de ikke kan bryde, med et spor, der beviser det bagefter. Fuld autonomi uden styring er ikke ambition, det er blot risiko med en bedre brugerflade. Markedet modnede hurtigere på tillidskrav end på rå kapabilitetskrav, og denne omrokering er det største, jeg gik glip af i starten.

Pipefy skelner mellem relativt simpel AI‑automatisering og AI‑agenter, der kan ræsonnere gennem tvetydige situationer, planlægge flere trin og udføre handlinger på tværs af en arbejdsgang. Hvordan skal virksomheder afgøre, hvornår en opgave faktisk kræver en AI‑agent, versus hvornår deterministisk automatisering stadig er den bedste løsning?

Den test, jeg bruger, er enkel: hvis du kan skrive reglen, så skriv reglen. Deterministisk automatisering er stadig det rette svar på alt, hvor beslutningstræet er kendt på forhånd og ikke ændrer sig — diriger denne faktura til denne godkender, hvis den er under dette beløb. Det er ikke en opgave for en agent, og at foregive andet tilføjer blot latenstid og uforudsigelighed til noget, der allerede er løst. En agent får sin plads i det øjeblik, situationen har tvetydighed, som en fast regel ikke kan løse — fakturaen matcher ikke indkøbsordren præcist, der mangler et felt, kundens anmodning passer ikke ind i nogen af dine eksisterende kategorier. Det er her, ræsonnement har reel værdi: at beslutte, hvad der skal gøres næste gang, når “næste” ikke allerede er skrevet ned. Den fejl, jeg konstant ser virksomheder begå, er at bygge en agent til de 80 % af sager, der allerede var deterministiske, fordi det er mere flashy, og efterlade de tvetydige 20 % — den egentlige svære del — til et menneske, der manuelt skal opløse dem. Vend forholdet, og du har bygget noget ægte.

Der er en voksende bevægelse fra selvstændige copilots mod “agentisk orkestrering”, hvor AI kan koordinere processer, der spænder over flere systemer. Hvad adskiller ægte agentisk orkestrering fra blot at tilføje en stor sprogmodel til en eksisterende automatiseringsplatform?

At indsætte en LLM-node i en eksisterende automatiseringsflow giver dig et smartere enkelt trin. Ægte orkestrering betyder, at AI har et vedvarende, struktureret overblik over hele processen — ikke kun denne opgave, men hvor den befinder sig i sekvensen, hvad der allerede er sket opstrøms, hvad der skal være sandt nedstrøms for at dette kan betragtes som færdigt. Forskellen er, om intelligensen har hukommelse om processen eller kun hukommelse om prompten. En copilot svarer på det spørgsmål, du stiller den. Orkestrering koordinerer handlinger på tværs af systemer, der ikke naturligt taler sammen — dit ERP, dit CRM, en partners API — mens den arver de samme regler, tilladelser og revisionsspor, som resten af processen allerede kører på. Hvis du er nødt til at bygge et separat governance‑lag omkring din AI‑funktion, fordi automatiseringsplatformen under den ikke har et, har du ikke agentisk orkestrering — du har en chatbot med API‑adgang, og de har helt andre risikoprofiler.

No-code AI-agenter kan potentielt give forretningsteams mulighed for at automatisere stadig mere komplekse processer uden at vente på ingeniørressourcer. Hvordan demokratiserer du denne evne uden at skabe en ny generation af shadow AI, dårligt designede agenter eller sikkerhedsrisici?

Du får ikke sikker demokratisering ved at bede forretningsbrugere om at være mere forsigtige — du får den ved at

ved at gøre sikkerhedsskinnerne til en del af belægningen, ikke en separat bane, folk skal vælge at køre i. Hver agent, som en forretningsbruger bygger, arver den samme rollebaserede adgang, det samme revisionsspor og de samme forretningsregler, der allerede styrer den proces, den er bygget i — de er ikke valgfrie konfigurationer, de er strukturelle. Det er det egentlige svar på shadow AI: det er ikke et politikproblem, men et arkitekturproblem. Shadow AI opstår, når det godkendte værktøj er sværere at bruge end det uautoriserede, så folk bygger deres agent i en personlig ChatGPT-konto eller et tilfældigt automatiseringsværktøj uden synlighed for IT. Hvis no‑code‑oplevelsen er virkelig hurtig, og governance er usynlig, fordi den er automatisk, er der ingen grund til, at et forretningsteam skal omgå den. I det øjeblik du gør governance til et manuelt trin, som nogen skal huske, har du allerede tabt.

Efterhånden som AI‑agenter får evnen til at træffe beslutninger og udføre handlinger i stedet for blot at anbefale dem, hvordan skal organisationer afgøre, hvor fuld autonomi er passende, og hvor mennesker skal forblive i kredsløbet?

Aksen, jeg bruger, er ikke “hvor smart er agenten”, men reversibilitet og eksplosion radius. Hvis en forkert beslutning er billig at opdage og billig at fortryde — routing, kategorisering, udkast — lad agenten handle og gennemgå i samlet form. Hvis en forkert beslutning er dyr, svær at reversere eller berører penge, compliance eller en kundes forhold direkte, behold et menneske i kredsløbet for netop dette trin, selvom agenten har truffet de sidste tusinde beslutninger korrekt. Fejlen er at behandle autonomi som en enkelt indstilling, du skrue op for hele arbejdsflowet. Reelle processer er en sekvens af trin med vidt forskellige risikoprofiler, og den rette design placerer mennesket præcis på det trin, hvor en fejl er dyr — ikke overalt og ikke ingen steder. Det er også grunden til, at menneske‑i‑kredsløbet, gjort rigtigt, ikke er en skat på hastighed — det er måden, du opbygger tilliden til efterhånden at fjerne den fra lav‑risiko‑trinene, fordi du har beviserne for, hvilke beslutninger agenten konsekvent træffer korrekt.

Pipefy lægger vægt på governance gennem mekanismer såsom revisionsspor, rollebaserede adgangskontroller, forretningsregler og sporbarhed inden for selve workflowet. Bliver det essentielt at indlejre governance direkte i orkestreringslaget, efterhånden som virksomheder flytter AI‑agenter fra eksperimenter til produktion?

Det er ikke ved at blive essentielt — det er allerede det, og de virksomheder, der opdager dette på den hårde måde, er dem, der først sendte agenter i produktion og nu bygger revisionssporet efterfølgende. Det er omvendt, og det er dyrt at rette retroaktivt. Hvis revisionsspor, rollebaseret adgang og sporbarhed ikke er indbygget i orkestreringslaget selv, er hver ny agent, du implementerer, et nyt sted, hvor styringen stille kan fejle — og du opdager det først, når en revisor, en regulator eller en hændelse stiller spørgsmålet. At indlejre styring i orkestreringslaget betyder, at enhver handling en agent udfører automatisk arver de samme regler og efterlader den samme dokumentation, som en menneskelig handling ville, uden at nogen behøver at huske at konfigurere det separat. Virksomheder, der bevæger sig fra AI‑eksperimenter til AI i produktion, opdager, at pilotens succeskriterier og produktions succeskriterier er forskellige: en pilot skal fungere, produktion skal kunne forsvares. Styring er forskellen mellem de to niveauer.

Diverse virksomheder kan demonstrere en imponerende AI‑pilot, men har svært ved at omsætte den til målbar forretningsværdi. Hvilke målinger bør ledere fokusere på, når de skal afgøre, om et AI‑automatiseringsinitiativ virkelig leverer ROI, og hvad er de mest almindelige årsager til, at lovende piloter mislykkes med at skalere?

Jeg har ingen tillid til nogen AI‑ROI‑diskussion, der starter med “sparede timer”, fordi timer sparet af hvem, og hvordan verificeret? De målinger, der faktisk holder stand under CFO‑gennemsyn, er ting, som revisorer kan bekræfte uafhængigt: cyklustid på en specifik proces, før og efter; fejl‑ eller genarbejdsrate; procentdelen af et workflow, der nu fuldføres uden menneskelig indgriben; og dækning af revisionslinje — kan du vise, for hver agentbaseret beslutning, hvorfor den blev truffet. Hvis du ikke kan producere dette spor, har du ikke et ROI‑tal, men en anekdote. Piloter mislykkes næsten altid med at skalere af samme grund: de blev bygget for at bevise, at modellen virker, ikke for at bevise, at processen fungerer fra ende til anden i produktion, integreret med de systemer, resten af virksomheden allerede er afhængig af. En pilot, der lever i en sandkasse, frakoblet det reelle system of record, vil altid se bedre ud end den præsterer, når den er koblet til alt det andet, der allerede kører. Skalering er et systemintegrationsproblem i et AI‑kostume.

Du har også ledt organisatoriske forandringsinitiativer hos Pipefy, mens du introducerede nye AI‑funktioner. Ud fra din erfaring, hvor meget af en vellykket enterprise‑AI‑adoption faktisk er en teknologisk udfordring versus en proces‑, kultur‑ og forandringsledelsesudfordring?

Hvis jeg er ærlig, er vellykket enterprise‑AI‑adoption 20 % teknologi og 80 % alt andet. Teknologien fungerer for det meste nu — det er ikke det, der holder mig vågen om natten. Det, der faktisk bestemmer, om et AI‑initiativ holder, er, om de mennesker, hvis job ændres, har tillid til systemet nok til at slippe den manuelle kontrol, de har udført i ti år, og om ledelsen er villig til at redesigne processen i stedet for blot at sætte AI oven på den gamle. Vi gik igennem dette internt ved at bygge vores eget ingeniørværktøj — teknologien til at automatisere dele af, hvordan vi bygger software, eksisterede længe før teamet faktisk stolede på den nok til at stoppe med at dobbelttjekke alt manuelt. Løsningen var ikke en bedre model, men synligt bevis, gentaget nok gange, at systemets dømmekraft matchede deres. Forandringsledelse for AI er ikke en kommunikationsøvelse, men en evidens‑opsamlingsøvelse — du opbygger tillid i små, verificerbare portioner, du erklærer det ikke på en town hall.

Ser du fremad, forventer du, at traditionel workflow‑ og forretningsproces‑software vil udvikle sig til orkestreringslag, hvor mennesker, AI‑agenter og virksomhedssystemer løbende samarbejder? I så fald, hvad vil grundlæggende ændre sig i måden, hvorpå virksomheder designer og styrer deres drift?

Ja, og jeg mener, at forskydningen er større, end de fleste indregner. Workflow‑software plejede at være stedet, hvor du dokumenterede, hvordan arbejdet skulle foregå. Det bliver nu stedet, hvor arbejdet faktisk sker — en live runtime, hvor mennesker, agenter og virksomhedssystemer alle handler inden for den samme styrede proces på samme tid, i stedet for at et menneske bruger softwaren som en passiv journalfører efterfølgende. Det, der grundlæggende ændrer sig, er, hvor “systemet af rekord” faktisk befinder sig. Rekorden var tidligere en database, der blev opdateret, når noget allerede var sket uden for den. I et orkestreringslag er rekorden og udførelsen den samme ting — processen bliver selve grænsefladen, tilgængelig ikke kun gennem en skærm, men gennem en API, en MCP‑server, en CLI, så enhver agent, intern eller fra en partner, kan handle inden for den under de samme regler, som et menneske ville. Virksomheder, der betragter denne forskydning som “tilføj AI til mine eksisterende værktøjer”, vil fortsat ramme loftet, jeg beskrev tidligere. De, der ser deres proceslag som det egentlige produkt — det, der er værd at investere i at strukturere korrekt —, er dem, der vil opbygge en fordel, som ingen kan kopiere blot ved at købe den samme AI‑model.

Tak for det gode interview, læsere der ønsker at lære mere, bør besøge Pipefy.