Sobhan Daliry, CPO e responsabile della strategia AI di Pipefy – Serie di interviste

Sobhan Daliry, CPO e responsabile della strategia AI di Pipefy, è un dirigente esperto di prodotto e tecnologia che guida la strategia AI dell’azienda dal 2023, contribuendo a trasformare i flussi di lavoro aziendali tradizionali in processi sempre più intelligenti e autonomi. Nel corso della sua carriera, Daliry ha unito strategia di prodotto, trasformazione organizzativa e leadership tecnologica sia in startup sia in aziende consolidate. Prima di entrare in Pipefy, ha fondato Polen.me e ne è stato CEO, oltre ad aver trascorso più di cinque anni come CEO/CPO di NZN, dove ha diretto il rilancio dell’azienda e la sua strategia di prodotto. In precedenza è stato Director of Product Management presso PSafe, Product Manager presso Peixe Urbano e ha ricoperto ruoli nei servizi digitali, nelle telecomunicazioni, nella consulenza e nello sviluppo aziendale presso Oi/Telemar, Claro, AIRCOM International e Planeta Tecnologia.

Pipefy è una piattaforma globale per la gestione dei processi e l’AI, progettata per aiutare le organizzazioni ad automatizzare e orchestrare i flussi di lavoro aziendali. Fondata nel 2015, l’azienda si è evoluta da piattaforma no-code per l’automazione dei processi a ambiente di orchestrazione incentrato sull’AI, che riunisce agenti AI, flussi di lavoro, moduli, portali, applicazioni, dati, analisi, messaggistica e integrazioni. La piattaforma consente ai team di creare e gestire agenti AI con il linguaggio naturale e strumenti no-code, mantenendo al contempo governance, sicurezza e visibilità di livello enterprise. Le capacità AI di Pipefy comprendono agenti in grado di interpretare documenti, eseguire attività nei flussi di lavoro, supportare le decisioni, interagire con sistemi esterni e orchestrare processi in aree quali finanza, risorse umane, approvvigionamento, operazioni con i clienti e conformità.

La sua carriera l’ha portata dall’ingegneria delle telecomunicazioni in aziende come Claro e Oi alla leadership di prodotto presso Peixe Urbano e PSafe, ai ruoli di CEO/CPO in NZN, alla fondazione di Polen.me e, oggi, alla guida della strategia di prodotto e AI di Pipefy. In che modo questo percorso ha plasmato il suo approccio alla costruzione di prodotti AI che risolvono problemi operativi reali, invece di limitarsi a mostrare una nuova tecnologia?

Le telecomunicazioni mi hanno insegnato che l’infrastruttura deve funzionare ogni singola volta, su scala enorme, senza alcuno spazio per il “funziona quasi sempre”. Una chiamata interrotta non è il fallimento di una demo: è un cliente che se ne va. Quella mentalità, affidabilità prima della novità, non mi ha mai abbandonato. In Peixe Urbano e PSafe ho imparato la lezione opposta: i prodotti consumer vivono o muoiono rapidamente in base alla loro capacità di risolvere oggi un problema reale e percepito, non uno teorico. Dirigere NZN come CEO/CPO mi ha costretto a tenere insieme entrambe le verità: non si può compensare una tesi sbagliata con un’esecuzione eccellente, né una cattiva esecuzione con una tesi eccellente. Fondare Polen.me mi ha insegnato la lezione più costosa: capitale e tempo sono limitati, quindi ogni funzione che si costruisce ne esclude un’altra, e il costo di inseguire una demo impressionante invece di un flusso di lavoro reale emerge mesi dopo, non sul palco. Quando sono arrivato in Pipefy, la domanda che pongo su ogni funzione AI era la stessa che farei su una torre cellulare: regge in produzione, sotto un carico reale, quando nessuno la osserva? Se un agente AI funziona soltanto in un ambiente dimostrativo curato, non è un prodotto: è il trailer di un prodotto.

Dal 2023 ha guidato la definizione e l’attuazione della strategia AI di Pipefy. Quali ipotesi iniziali sull’AI aziendale sono cambiate di più con la maturazione dell’AI generativa e degli agenti AI?

L’ipotesi più importante che ho dovuto abbandonare era che il modello sarebbe stato il collo di bottiglia. Nel 2023 tutti, me compreso, ottimizzavano pensando a “quale LLM è il più intelligente”. In realtà il collo di bottiglia si è rivelato il contesto: l’agente sa davvero come funziona il processo, quali sono i vincoli e che cosa significa “completato” per la specifica versione della contabilità fornitori di quel cliente? La qualità dei modelli continuava a migliorare lungo una curva prevedibile; il contesto dei processi non migliorava da solo, perché nessuno lo aveva strutturato. La seconda ipotesi capovolta riguardava l’autonomia. Pensavo che il mercato volesse agenti completamente indipendenti il più rapidamente possibile. Ciò che le imprese volevano, e vogliono ancora, è un’autonomia delimitata: agenti che prendono decisioni reali entro regole che non possono violare e lasciano una traccia che lo dimostri. La piena autonomia senza governance non è ambizione, è semplicemente rischio con un’interfaccia migliore. Il mercato è maturato più rapidamente nei requisiti di fiducia che in quelli di capacità pura, e questo riordino è il più grande errore che ho commesso all’inizio.

Pipefy distingue tra un’automazione AI relativamente semplice e agenti AI capaci di ragionare in situazioni ambigue, pianificare più passaggi ed eseguire azioni in un flusso di lavoro. Come dovrebbero stabilire le imprese quando un’attività richiede davvero un agente AI e quando l’automazione deterministica resta la scelta migliore?

Il criterio che uso è semplice: se si può scrivere la regola, bisogna scrivere la regola. L’automazione deterministica resta la risposta giusta per tutto ciò in cui l’albero decisionale è noto in anticipo e non cambia: inviare questa fattura a questo responsabile dell’approvazione se è inferiore a un certo importo. Non è un compito per un agente; fingere il contrario aggiunge soltanto latenza e imprevedibilità a qualcosa che era già risolto. Un agente si guadagna il suo posto quando la situazione contiene un’ambiguità che una regola fissa non può risolvere: la fattura non corrisponde esattamente all’ordine di acquisto, manca un campo, la richiesta del cliente non rientra in nessuna categoria esistente. È lì che il ragionamento ha un valore reale: decidere che cosa fare dopo quando il “dopo” non è già stato scritto. Vedo continuamente imprese costruire un agente per l’80% dei casi già deterministici, perché è più appariscente, e lasciare a una persona il compito di districare manualmente il 20% ambiguo, cioè la parte davvero difficile. Invertendo quel rapporto si costruisce qualcosa di reale.

Si osserva un crescente passaggio dai copiloti autonomi all’“orchestrazione agentica”, in cui l’AI può coordinare processi che attraversano più sistemi. Che cosa distingue una vera orchestrazione agentica dalla semplice aggiunta di un grande modello linguistico a una piattaforma di automazione esistente?

Inserire un nodo LLM in un flusso di automazione esistente rende più intelligente un singolo passaggio. Una vera orchestrazione significa che l’AI possiede una visione persistente e strutturata dell’intero processo: non soltanto dell’attività corrente, ma anche della sua posizione nella sequenza, di ciò che è già accaduto a monte e di ciò che deve essere vero a valle perché l’attività possa considerarsi completata. La differenza sta nel fatto che l’intelligenza abbia memoria del processo oppure soltanto del prompt. Un copilota risponde alla domanda che gli viene posta. L’orchestrazione coordina le azioni tra sistemi che non comunicano in modo nativo, come ERP, CRM o API di un partner, ereditando le stesse regole, autorizzazioni e tracce di audit che governano il resto del processo. Se occorre costruire uno strato di governance separato attorno alla funzione AI perché la piattaforma di automazione sottostante non ne possiede uno, non si ha un’orchestrazione agentica: si ha un chatbot con accesso alle API, che presenta un profilo di rischio completamente diverso.

Gli agenti AI no-code possono consentire ai team aziendali di automatizzare processi sempre più complessi senza attendere risorse di ingegneria. Come si democratizza questa capacità senza creare una nuova generazione di shadow AI, agenti progettati male o rischi per la sicurezza?

Non si ottiene una democratizzazione sicura chiedendo agli utenti aziendali di fare più attenzione: la si ottiene rendendo i vincoli parte della pavimentazione, non una corsia separata che le persone devono scegliere di percorrere. Ogni agente costruito da un utente aziendale eredita lo stesso accesso basato sui ruoli, la stessa traccia di audit e le stesse regole aziendali che governano già il processo in cui viene creato. Non sono configurazioni facoltative, sono elementi strutturali. Questa è la vera risposta alla shadow AI: non è un problema di policy, ma di architettura. La shadow AI nasce quando lo strumento autorizzato è più difficile da usare di quello non autorizzato, così le persone costruiscono il proprio agente in un account ChatGPT personale o con uno strumento di automazione casuale, senza alcuna visibilità per l’IT. Se l’esperienza no-code è davvero rapida e la governance è invisibile perché automatica, un team aziendale non ha motivo di aggirarla. Nel momento in cui la governance diventa un passaggio manuale che qualcuno deve ricordare, si è già perso.

Quando gli agenti AI acquisiscono la capacità di prendere decisioni ed eseguire azioni, invece di limitarsi a formularne raccomandazioni, come dovrebbero decidere le organizzazioni dove è appropriata la piena autonomia e dove le persone devono restare nel ciclo?

L’asse che uso non è “quanto è intelligente l’agente”, ma reversibilità e raggio d’impatto. Se una decisione errata è facile da individuare e poco costosa da annullare, come nell’instradamento, nella classificazione o nella redazione di bozze, si può lasciare agire l’agente e verificare i risultati in aggregato. Se una decisione errata è costosa, difficile da invertire o coinvolge direttamente denaro, conformità o il rapporto con un cliente, occorre mantenere una persona nel ciclo per quello specifico passaggio, anche se l’agente ha preso correttamente le ultime mille decisioni. L’errore consiste nel trattare l’autonomia come un unico comando da aumentare per tutto il flusso di lavoro. I processi reali sono sequenze di passaggi con profili di rischio molto diversi, e il progetto corretto colloca la persona esattamente nel punto in cui un errore è costoso, non ovunque e non da nessuna parte. È anche il motivo per cui il human-in-the-loop, se realizzato bene, non è una tassa sulla velocità: permette di creare la fiducia necessaria per rimuoverlo in futuro dai passaggi a basso rischio, perché si dispone delle prove che indicano quali decisioni l’agente prende correttamente con costanza.

Pipefy sottolinea la governance attraverso meccanismi come tracce di audit, controlli di accesso basati sui ruoli, regole aziendali e tracciabilità nel flusso di lavoro. Incorporare la governance direttamente nello strato di orchestrazione sta diventando essenziale mentre le aziende portano gli agenti AI dagli esperimenti alla produzione?

Non sta diventando essenziale: lo è già. Le aziende che lo stanno scoprendo nel modo più difficile sono quelle che hanno portato per prime gli agenti in produzione e ora costruiscono la traccia di audit a posteriori. È l’ordine sbagliato ed è costoso correggerlo retroattivamente. Se tracce di audit, accesso basato sui ruoli e tracciabilità non sono nativi dello strato di orchestrazione, ogni nuovo agente distribuito diventa un nuovo punto in cui la governance può fallire silenziosamente, e non lo si scoprirà finché un revisore, un’autorità di regolamentazione o un incidente non imporrà la domanda. Incorporare la governance nello strato di orchestrazione significa che ogni azione compiuta da un agente eredita automaticamente le stesse regole e lascia le stesse prove di un’azione umana, senza che qualcuno debba ricordarsi di configurarle separatamente. Le imprese che passano dagli esperimenti all’AI in produzione scoprono che i criteri di successo di un progetto pilota sono diversi da quelli della produzione: un pilota deve funzionare, la produzione deve poter essere difesa. La governance è la differenza tra queste due soglie.

Molte aziende riescono a mostrare un progetto pilota AI impressionante, ma faticano a tradurlo in valore aziendale misurabile. Su quali metriche dovrebbero concentrarsi i leader per stabilire se un’iniziativa di automazione AI produce davvero un ritorno sull’investimento, e quali sono le ragioni più comuni per cui progetti promettenti non riescono a scalare?

Diffido di ogni discussione sul ROI dell’AI che inizi con “ore risparmiate”: risparmiate da chi e verificate in che modo? Le metriche che resistono davvero all’esame di un CFO sono quelle che i revisori possono confermare in modo indipendente: il tempo di ciclo di uno specifico processo, prima e dopo; il tasso di errore o di rilavorazione; la percentuale del flusso che ora si completa senza intervento umano; la copertura della provenienza di audit, cioè se per ogni decisione agentica si può dimostrare perché è stata presa. Se non si può produrre quella traccia, non si ha un numero di ROI, ma un aneddoto. I piloti non riescono quasi sempre a scalare per la stessa ragione: sono costruiti per dimostrare che il modello funziona, non che il processo funziona da un capo all’altro, in produzione e integrato con i sistemi da cui il resto dell’azienda già dipende. Un progetto pilota in un ambiente isolato e scollegato dal vero sistema di registrazione apparirà sempre migliore di quanto sarà una volta collegato a tutto ciò che è già in funzione. La scalabilità è un problema di integrazione dei sistemi travestito da AI.

Ha inoltre guidato iniziative di cambiamento organizzativo in Pipefy mentre introduceva nuove capacità AI. In base alla sua esperienza, quanto dipende il successo dell’adozione dell’AI aziendale dalla tecnologia e quanto invece da processi, cultura e gestione del cambiamento?

Se devo essere sincero, l’adozione efficace dell’AI aziendale dipende per il 20% dalla tecnologia e per l’80% da tutto il resto. Oggi la tecnologia per lo più funziona; non è questo a togliermi il sonno. A determinare se un’iniziativa AI attecchisce davvero sono la fiducia delle persone il cui lavoro cambia, sufficiente ad abbandonare il controllo manuale svolto per dieci anni, e la disponibilità della dirigenza a riprogettare il processo invece di incollare semplicemente l’AI sopra quello vecchio. Lo abbiamo sperimentato internamente costruendo i nostri strumenti di ingegneria: la tecnologia per automatizzare parte dello sviluppo software esisteva ben prima che il team si fidasse abbastanza da smettere di ricontrollare tutto a mano. La svolta non è stata un modello migliore, ma una prova visibile, ripetuta abbastanza volte, che il giudizio del sistema coincideva con il loro. La gestione del cambiamento per l’AI non è un esercizio di comunicazione, ma di accumulo delle prove: la fiducia si guadagna in piccole porzioni verificabili, non la si proclama in una riunione generale.

Guardando al futuro, si aspetta che i tradizionali software per flussi di lavoro e processi aziendali si evolvano in strati di orchestrazione in cui persone, agenti AI e sistemi aziendali collaborano continuamente? Se sì, che cosa cambierà fondamentalmente nel modo in cui le aziende progettano e gestiscono le proprie attività?

Sì, e credo che il cambiamento sia più grande di quanto la maggior parte delle persone stia mettendo in conto. Il software per flussi di lavoro era il luogo in cui si documentava come il lavoro avrebbe dovuto svolgersi. Sta diventando il luogo in cui il lavoro si svolge davvero: un ambiente di esecuzione vivo, nel quale persone, agenti e sistemi aziendali agiscono contemporaneamente nello stesso processo governato, invece di avere una persona che usa il software come registro passivo a posteriori. Ciò che cambia radicalmente è dove risiede il vero “sistema di registrazione”. In passato era un database aggiornato dopo che qualcosa era già accaduto altrove. In uno strato di orchestrazione, registrazione ed esecuzione coincidono: il processo stesso diventa l’interfaccia, accessibile non soltanto attraverso uno schermo, ma tramite API, server MCP o CLI. Così ogni agente, interno o appartenente a un partner, può agire al suo interno secondo le stesse regole applicate a una persona. Le aziende che interpreteranno questo cambiamento come “aggiungere l’AI ai miei strumenti esistenti” continueranno a incontrare il limite descritto prima. Quelle che tratteranno il proprio strato di processo come il vero prodotto, meritevole di investimenti per essere strutturato correttamente, accumuleranno un vantaggio che nessuno potrà copiare semplicemente acquistando lo stesso modello AI.

Grazie per l’ottima intervista. I lettori che desiderano saperne di più possono visitare Pipefy.