Sobhan Daliry, produktchef og leder af AI-strategien hos Pipefy – Interviewserie

Sobhan Daliry, produktchef & leder af AI-strategien hos Pipefy, er en erfaren produkt‑ og teknologileder, 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 produktledelse 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. Pipefys 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 regelefterlevelse.

Din karriere har ført dig fra arbejde som telekommunikationsingeniør hos virksomheder som Claro og Oi til produktledelse hos Peixe Urbano og PSafe, rollen som CEO/CPO for NZN, grundlæggelsen af Polen.me og nu ansvaret for 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 for det meste”. Et tabt opkald er ikke en demofejl, det er en kunde, der går væk. Den mentalitet — pålidelighed frem for nyhedsværdi — 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 bedre eksekvering, 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 en mobilmast: holder den i produktion under reel 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 ledet formuleringen og implementeringen af Pipefys 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 blevet mere 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 ændring i prioriteringen er det, jeg tog mest fejl 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, og 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 virker mere imponerende, og efterlade de tvetydige 20 % — den egentlige svære del — til et menneske, der manuelt skal rede trådene ud. 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 et eksisterende automatiseringsflow giver dig ét smartere 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

gøre sikkerhedsrammerne til en del af selve vejbelæ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 problem med retningslinjer, 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 fortsat skal være inddraget i processen?

Aksen, jeg bruger, er ikke “hvor smart er agenten”, men muligheden for at gøre beslutninger om og omfanget af deres konsekvenser. Hvis en forkert beslutning er billig at opdage og billig at fortryde — routing, kategorisering, udkast — så lad agenten handle, og gennemgå derefter beslutningerne samlet. Hvis en forkert beslutning er dyr, svær at reversere eller berører penge, compliance eller et kundeforhold direkte, så behold et menneske i processen for netop dette trin, selvom agenten har truffet de sidste tusinde beslutninger korrekt. Fejlen er at behandle autonomi som en enkelt indstilling, du skruer op for hele arbejdsflowet. Reelle processer er en sekvens af trin med vidt forskellige risikoprofiler, og det 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 menneskelig inddragelse, når den er tilrettelagt rigtigt, ikke er en belastning for hastigheden — det er måden, du opbygger tilliden til efterhånden at fjerne den menneskelige inddragelse fra trinene med lav risiko, 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 tilsynsmyndighed 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 produktionens 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 hvor fuldstændigt beslutningernes ophav og forløb er dokumenteret i revisionssporet — 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å ledet organisatoriske forandringsinitiativer hos Pipefy, mens du introducerede nye AI‑funktioner. Ud fra din erfaring, hvor meget af en vellykket enterprise‑AI‑adoption er faktisk en teknologisk udfordring frem for 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 egne værktøjer til softwareudvikling — 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, på, 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å et fællesmøde.

Når du ser fremad, forventer du så, 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 den måde, 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 det autoritative registreringssystem faktisk befinder sig. Registreringen lå tidligere i en database, der blev opdateret, når noget allerede var sket uden for den. I et orkestreringslag er registreringen og udførelsen ét og det samme — processen bliver selve grænsefladen, tilgængelig ikke kun gennem en skærm, men gennem et API, en MCP‑server, en kommandolinjegrænseflade, 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 selvforstærkende 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.