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

Sobhan Daliry, CPO & AI Strategy Leader bij Pipefy, is een ervaren product‑ en technologie‑executive die sinds 2023 de AI‑strategie van het bedrijf leidt en helpt traditionele bedrijfsprocessen om te vormen tot steeds intelligenter en autonomer werkstromen. Gedurende zijn loopbaan heeft Daliry productstrategie, organisatie‑transformatie en technologische leiding gecombineerd bij startups en gevestigde bedrijven. Voordat hij bij Pipefy kwam, richtte hij Polen.me op en was hij CEO, en hij werkte meer dan vijf jaar als CEO/CPO van NZN, waar hij de turnaround en productstrategie van het bedrijf leidde. Zijn eerdere functies omvatten Directeur Product Management bij PSafe, Productmanager bij Peixe Urbano, en rollen op het gebied van digitale diensten, telecommunicatie, consultancy en business development bij Oi/Telemar, Claro, AIRCOM International en Planeta Tecnologia.

Pipefy is een wereldwijd proces‑beheer‑ en AI‑platform dat organisaties helpt hun bedrijfsprocessen te automatiseren en te orkestreren. Opgericht in 2015 is het bedrijf uitgegroeid van een no‑code proces‑automatiseringsplatform tot een AI‑gerichte orkestratie‑omgeving die AI‑agents, werkstromen, formulieren, portals, applicaties, data, analytics, messaging en integraties samenbrengt. Het platform stelt teams in staat AI‑agents te creëren en beheren met natuurlijke taal en no‑code tools, terwijl enterprise governance, beveiliging en zichtbaarheid behouden blijven. De AI‑mogelijkheden van Pipefy omvatten agents die documenten kunnen interpreteren, workflow‑taken uitvoeren, besluitvorming ondersteunen, met externe systemen communiceren en processen orkestreren op gebieden zoals financiën, personeelszaken, inkoop, klantoperaties en compliance.

Je carrière heeft je van telecom‑engineering bij bedrijven als Claro en Oi naar productleiderschap bij Peixe Urbano en PSafe geleid, waar je als CEO/CPO bij NZN werkte, Polen.me oprichtte en nu de product‑ en AI‑strategie bij Pipefy leidt. Hoe heeft die ontwikkeling de manier beïnvloed waarop je AI‑producten bouwt die echte operationele problemen oplossen in plaats van alleen nieuwe technologie te demonstreren?

Telecom leerde me dat infrastructuur elke keer perfect moet werken, op enorme schaal, zonder enige ruimte voor ‘het werkt meestal’. Een verbroken gesprek is geen demo‑fout, het is een klant die wegloopt. Die mentaliteit — betrouwbaarheid boven vernieuwing — heeft me nooit verlaten. Bij Peixe Urbano en PSafe leerde ik de tegenovergestelde les: hoe snel consumentenproducten leven of sterven afhankelijk van of ze vandaag een echt, gevoeld probleem oplossen, niet een theoretisch. Het leiden van NZN als CEO/CPO dwong me beide waarheden tegelijk te omarmen — je kunt een slechte hypothese niet sneller uitvoeren, en je kunt een slechte uitvoering niet overtreffen met een betere hypothese. Het oprichten van Polen.me gaf me de duurste les van allemaal: kapitaal en tijd zijn beperkt, dus elke functie die je bouwt, is een functie die je niet bouwt, en de kosten van het najagen van een indrukwekkende demo in plaats van een echte workflow komen pas maanden later naar voren, niet op het podium. Tegen de tijd dat ik bij Pipefy kwam, stelde ik bij elke AI‑functie dezelfde vraag als bij een zendmast: houdt dit stand in productie, onder echte belasting, wanneer niemand kijkt? Als een AI‑agent alleen werkt in een zorgvuldig samengestelde demo‑omgeving, is het geen product — het is een trailer daarvoor.

Je hebt sinds 2023 de formulering en implementatie van de AI‑strategie van Pipefy geleid. Welke aannames over enterprise‑AI had je aanvankelijk die het meest zijn veranderd naarmate generatieve AI en AI‑agents zijn volwassen geworden?

De grootste aanname die ik moest afschaffen was dat het model de bottleneck zou zijn. In 2023 optimaliseerde iedereen — inclusief ik — voor ‘welk LLM is het slimst’. Wat uiteindelijk de bottleneck bleek te zijn, was context: weet de agent wat het proces werkelijk is, wat de richtlijnen zijn, hoe ‘klaar’ eruitziet voor de specifieke versie van crediteurenadministratie van die klant. De modelkwaliteit bleef verbeteren volgens een curve die iedereen kon zien aankomen; de procescontext verbeterde niet vanzelf, omdat niemand het had gestructureerd. De tweede aanname die omdraaide ging over autonomie. Ik ging ervan uit dat de markt agents wilde die volledig onafhankelijk en zo snel mogelijk handelden. Wat bedrijven werkelijk — en nog steeds — willen, is begrensde autonomie: agents die echte beslissingen nemen binnen regels die ze niet mogen overtreden, met een spoor dat dit later bewijst. Volledige autonomie zonder governance is geen ambitie, maar enkel risico met een betere UI. De markt is sneller volwassen geworden op het gebied van vertrouwenseisen dan op ruwe capaciteitsvereisten, en die herordening is het grootste ding dat ik in het begin verkeerd had.

Pipefy maakt onderscheid tussen relatief eenvoudige AI‑automatisering en AI‑agents die kunnen redeneren over ambiguïteiten, meerdere stappen kunnen plannen en acties over een workflow kunnen uitvoeren. Hoe moeten bedrijven bepalen wanneer een taak daadwerkelijk een AI‑agent vereist versus wanneer deterministische automatisering de betere oplossing blijft?

De test die ik gebruik is simpel: als je de regel kunt schrijven, schrijf dan de regel. Deterministische automatisering is nog steeds het juiste antwoord voor alles waarbij de beslissingsboom van tevoren bekend is en niet verandert — route deze factuur naar deze goedkeurder als het onder dit bedrag ligt. Dat is geen taak voor een agent, en doen alsof dat wel zo is voegt alleen latentie en onvoorspelbaarheid toe aan iets dat al opgelost was. Een agent verdient zijn plaats op het moment dat de situatie ambiguïteit bevat die een vaste regel niet kan oplossen — de factuur komt niet exact overeen met de inkooporder, er ontbreekt een veld, het verzoek van de klant past niet in een van je bestaande categorieën. Dat is waar redeneren echte waarde heeft: bepalen wat je vervolgens moet doen wanneer “volgende” nog niet is vastgelegd. De fout die ik constant zie bij bedrijven is dat ze een agent bouwen voor de 80 % van de gevallen die al deterministisch waren, omdat het er opvallender uitziet, en de ambiguë 20 % — het echte moeilijke deel — overlaten aan een mens om handmatig te ontwarren. Draai je die verhouding om en je hebt iets echt gebouwd.

Er is een groeiende verschuiving van zelfstandige copilots naar “agentische orkestratie”, waarbij AI processen kan coördineren die zich over meerdere systemen uitstrekken. Wat onderscheidt echte agentische orkestratie van simpelweg een groot taalmodel toevoegen aan een bestaand automatiseringsplatform?

Het plaatsen van een LLM‑knooppunt in een bestaande automatiseringsstroom geeft je een slimmer enkele stap. Echte orkestratie betekent dat de AI een blijvend, gestructureerd overzicht heeft van het hele proces — niet alleen deze taak, maar waar het zich bevindt in de volgorde, wat er al stroomopwaarts is gebeurd, wat er stroomafwaarts waar moet zijn om als voltooid te gelden. Het verschil is of de intelligentie geheugen heeft van het proces of alleen geheugen van de prompt. Een copilot beantwoordt de vraag die je stelt. Orkestratie coördineert acties tussen systemen die niet van nature met elkaar communiceren — je ERP, je CRM, een API van een partner — terwijl dezelfde regels, permissies en audit‑trail worden geërfd die de rest van het proces al gebruikt. Als je een aparte governance‑laag moet bouwen rond je AI‑functie omdat het onderliggende automatiseringsplatform er geen heeft, heb je geen agentische orkestratie — je hebt een chatbot met API‑toegang, en dat heeft een heel ander risicoprofiel.

No‑code AI‑agents kunnen zakelijke teams in staat stellen steeds complexere processen te automatiseren zonder te wachten op engineering‑resources. Hoe democratiseer je die mogelijkheid zonder een nieuwe generatie shadow AI, slecht ontworpen agents of beveiligingsrisico’s te creëren?

Je krijgt geen veilige democratisering door zakelijke gebruikers simpelweg voorzichtiger te laten zijn — je krijgt die wel door

de guardrails onderdeel te maken van de verharding, niet van een aparte rij die mensen moeten kiezen om in te rijden. Elke agent die een zakelijke gebruiker bouwt erft dezelfde role‑based access, dezelfde audit‑trail en dezelfde bedrijfsregels die het proces waarin hij is ingebouwd al beheersen — ze zijn geen optionele configuratie, ze zijn structureel. Dat is het echte antwoord op shadow AI: het is geen beleidsprobleem, maar een architectuurprobleem. Shadow AI ontstaat wanneer het goedgekeurde hulpmiddel moeilijker te gebruiken is dan het niet‑goedgekeurde, zodat mensen hun agent bouwen in een persoonlijk ChatGPT‑account of een willekeurig automatiseringstool zonder zichtbaarheid voor IT. Als de no‑code‑ervaring echt snel is en de governance onzichtbaar omdat deze automatisch is, is er geen reden voor een zakelijk team om er omheen te gaan. Op het moment dat je governance een handmatige stap maakt die iemand moet onthouden, ben je al verloren.

Naarmate AI‑agents het vermogen krijgen om beslissingen te nemen en acties uit te voeren in plaats van alleen aanbevelingen te doen, hoe moeten organisaties bepalen waar volledige autonomie gepast is en waar mensen in de lus moeten blijven?

De as die ik gebruik is niet “hoe slim de agent is”, maar omkeerbaarheid en blast‑radius. Als een verkeerde beslissing goedkoop te detecteren en goedkoop ongedaan te maken is — routing, categorisatie, concept‑opstelling — laat de agent dan handelen en in bulk beoordelen. Als een verkeerde beslissing duur is, moeilijk ongedaan te maken, of direct geld, compliance of een klantrelatie raakt, houd dan een mens in de lus voor die specifieke stap, zelfs als de agent de laatste duizend beslissingen goed heeft genomen. De fout is autonomie behandelen als één enkele schuifregelaar die je voor de hele workflow omhoog zet. Werkelijke processen zijn een reeks stappen met sterk uiteenlopende risicoprofielen, en het juiste ontwerp plaatst de mens precies op de stap waar een fout duur is — niet overal en niet nergens. Dat is ook waarom human‑in‑the‑loop, goed uitgevoerd, geen belasting op snelheid is — het is hoe je het vertrouwen opbouwt om het uiteindelijk te verwijderen uit de laag‑risicostappen, omdat je het bewijs hebt dat de agent consequent de juiste beslissingen neemt.

Pipefy benadrukt governance via mechanismen zoals audit‑trails, role‑based access controls, bedrijfsregels en traceerbaarheid binnen de workflow zelf. Wordt het embedden van governance direct in de orkestratielaag essentieel nu bedrijven AI‑agents van experimenten naar productie verplaatsen?

Het wordt niet pas essentieel — het is al essentieel, en de bedrijven die dit op de harde manier ontdekken, zijn degenen die als eerste agents in productie hebben gebracht en nu de audittrail achteraf moeten opbouwen. Dat is omgekeerd, en het is duur om achteraf te corrigeren. Als audittrails, rolgebaseerde toegangscontrole en traceerbaarheid niet native zijn in de orchestratielaag zelf, is elke nieuwe agent die je inzet een nieuwe plek waar governance stilletjes kan falen — en je zult het niet ontdekken totdat een auditor, een regelgever of een incident de vraag stelt. Governance in de orchestratielaag embedden betekent dat elke actie van een agent automatisch dezelfde regels erft en hetzelfde bewijs achterlaat als een menselijke actie, zonder dat iemand het apart moet configureren. Bedrijven die van AI‑experimenten naar AI in productie gaan, ontdekken dat de succescriteria van de pilot en die van productie verschillend zijn: een pilot moet werken, productie moet verdedigbaar zijn. Governance is het verschil tussen die twee balken.

Veel bedrijven kunnen een indrukwekkende AI‑pilot aantonen, maar hebben moeite om deze om te zetten in meetbare bedrijfswaarde. Op welke metrics moeten leiders zich richten bij het bepalen of een AI‑automatiseringsinitiatief daadwerkelijk ROI oplevert, en wat zijn de meest voorkomende redenen waarom veelbelovende pilots niet opschalen?

Ik vertrouw elk AI‑ROI‑gesprek dat begint met “bespaarde uren” niet, want bespaarde uren door wie, en hoe geverifieerd? De metrics die daadwerkelijk standhouden onder CFO‑scrutinie zijn zaken die auditors onafhankelijk kunnen bevestigen: cyclustijd van een specifiek proces, vóór en ná; fout‑ of herbewerkingspercentage; het percentage van een workflow dat nu voltooid wordt zonder menselijke tussenkomst; en audit‑lineage‑dekking — kun je voor elke agent‑beslissing aantonen waarom deze is genomen. Als je die trace niet kunt leveren, heb je geen ROI‑cijfer, maar een anekdote. Pilots schalen bijna altijd niet om dezelfde reden: ze zijn gebouwd om te bewijzen dat het model werkt, niet om te bewijzen dat het proces end‑to‑end werkt, in productie, geïntegreerd met de systemen waar de rest van het bedrijf al op vertrouwt. Een pilot die in een sandbox leeft, losgekoppeld van het echte systeem‑van‑record, zal er altijd beter uitzien dan hij presteert zodra hij is aangesloten op al het andere dat al draait. Schaalbaarheid is een systeem‑integratieprobleem met een AI‑kostuum.

Je hebt ook organisatorische veranderingsinitiatieven geleid bij Pipefy terwijl je nieuwe AI‑functionaliteiten introduceerde. Vanuit jouw ervaring, hoeveel van succesvolle enterprise‑AI‑adoptie is eigenlijk een technologische uitdaging versus een proces‑, cultuur‑ en change‑management‑uitdaging?

Als ik eerlijk ben, bestaat succesvolle enterprise‑AI‑adoptie voor 20 % uit technologie en voor 80 % uit alles andere. De technologie werkt nu grotendeels — dat is niet waar ik me zorgen over maak. Wat echt bepaalt of een AI‑initiatief blijft, is of de mensen van wie het werk verandert, het systeem genoeg vertrouwen om de handmatige controle die ze tien jaar hebben uitgevoerd, los te laten, en of het leiderschap bereid is het proces opnieuw te ontwerpen in plaats van simpelweg AI bovenop het oude te plakken. We hebben dit intern doorgemaakt door onze eigen engineering‑tools te bouwen — de technologie om delen van onze software‑bouw te automatiseren bestond al lang voordat het team het genoeg vertrouwde om te stoppen met alles handmatig dubbel te controleren. De doorbraak was geen beter model, maar zichtbaar bewijs, genoeg herhaald, dat het oordeel van het systeem het hunne overeenkwam. Change‑management voor AI is geen communicatie‑oefening, maar een bewijs‑opbouw‑oefening — je wint vertrouwen in kleine, verifieerbare batches, je kondigt het niet aan in een town‑hall.

Als we vooruitkijken, verwacht je dat traditionele workflow‑ en business‑process‑software evolueert naar orchestratielagen waarin mensen, AI‑agents en enterprise‑systemen continu samenwerken? Zo ja, wat zal er fundamenteel veranderen in de manier waarop bedrijven hun operaties ontwerpen en beheren?

Ja, en ik denk dat de verschuiving groter is dan de meeste mensen in rekening brengen. Workflow‑software was vroeger de plek waar je documenteerde hoe werk zou moeten verlopen. Het wordt nu de plek waar werk daadwerkelijk gebeurt — een live runtime waarin mensen, agents en enterprise‑systemen allemaal tegelijk handelen binnen hetzelfde beheerde proces, in plaats van een mens die software gebruikt als een passieve archiefbewaker achteraf. Wat fundamenteel verandert, is waar het “record‑of‑record” daadwerkelijk woont. Het record was vroeger een database die werd bijgewerkt zodra iets al buiten het systeem was gebeurd. In een orchestratielaag zijn het record en de uitvoering één en dezelfde — het proces zelf wordt de interface, toegankelijk niet alleen via een scherm maar via een API, een MCP‑server, een CLI, zodat elke agent, intern of van een partner, erin kan handelen onder dezelfde regels als een mens. Bedrijven die deze verschuiving zien als “voeg AI toe aan mijn bestaande tools”, zullen steeds tegen het plafond aanlopen dat ik eerder beschreef. Degenen die hun proceslaag behandelen als het daadwerkelijke product — het ding waarin het de moeite waard is om goed te structureren — zijn degenen die een voordeel zullen opbouwen dat niemand kan kopiëren door simpelweg hetzelfde AI‑model te kopen.

Bedankt voor het geweldige interview, lezers die meer willen weten, kunnen terecht op Pipefy.