Yoav Naveh, cofondatore e co-CEO di Reindeer – Intervista

Yoav Naveh è cofondatore e co-CEO di Reindeer e ha maturato esperienza nella creazione di aziende tecnologiche, nella crescita di imprese e negli investimenti in fondatori. Prima di Reindeer, ha fondato ConvertMedia, ha proseguito il suo lavoro in Taboola e ha investito tramite INT3. Oggi si dedica ad aiutare le aziende a passare da implementazioni isolate dell’IA ad agenti in grado di gestire attività operative complesse, apprendere dall’esperienza umana e mantenere la propria affidabilità quando cambiano i processi aziendali.

Reindeer sviluppa agenti di IA per le operazioni aziendali fondamentali in ambiti quali finanza, catena di approvvigionamento, logistica e servizi condivisi. La sua piattaforma combina l’esecuzione dei flussi di lavoro con il feedback degli esperti, la valutazione e l’approvazione umana, così che gli agenti possano adattarsi alle eccezioni e all’evoluzione delle politiche. In questa intervista, Naveh parla dei limiti dei modelli di implementazione che richiedono un intenso lavoro di ingegneria, di come le conoscenze istituzionali diventino contesto per gli agenti e della governance e delle misurazioni necessarie per ridurre nel tempo il carico di lavoro umano complessivo.

Dopo aver fondato ConvertMedia, aver contribuito alla crescita di Taboola e aver investito in altri fondatori tramite INT3, quale problema ti ha spinto a tornare a creare un’azienda e in che modo ha influenzato la decisione di cofondare Reindeer?

Il mercato dell’IA era troppo entusiasmante perché potessimo restare a guardare. Io e il mio cofondatore Yair ci siamo interessati molto al divario tra l’utilità che l’IA ha raggiunto quando la usiamo individualmente e la difficoltà che le aziende incontrano ancora nell’adottarla su larga scala. La tecnologia sta avanzando a una velocità incredibile, eppure la maggior parte delle organizzazioni fatica ancora a tradurre questo potenziale in un cambiamento operativo significativo.

L’IA trasformerà il modo in cui operano le aziende, ma per arrivarci non basta una tecnologia migliore. Servono dirigenti disposti a ripensare il modo in cui si svolge il lavoro e un approccio pratico per integrare l’IA nelle attività quotidiane senza creare nuovi livelli di complessità.

È stata questa sfida a plasmare Reindeer. Abbiamo creato una piattaforma che accompagna le aziende dal loro primo agente fino a un’intera mandria di agenti, capaci di apprendere dal feedback umano e migliorare nel tempo. Il nostro obiettivo è colmare il divario tra il potenziale dell’IA e la sua adozione nel mondo reale, aiutando le aziende a trasformare le proprie operazioni fondamentali in una forza lavoro composta da agenti di IA, senza dover ricostruire o mantenere costantemente ogni agente.

Hai sostenuto che il modello degli ingegneri integrati presso il cliente rischia di trasformare l’IA aziendale in un’attività di servizi ad alta intensità di manodopera. In quali casi l’ingegneria integrata crea valore duraturo e in quali diventa una dipendenza che impedisce ai clienti di crescere?

Gli ingegneri integrati presso il cliente sono utili per le integrazioni complesse e per portare in produzione i primi agenti. Il problema si presenta quando cambiano i processi di lavoro e gli FDE diventano indispensabili a tempo indeterminato per mantenere operativi gli agenti che li gestiscono. Soprattutto su larga scala. Il modello degli FDE funziona quando si hanno 5 agenti. Non regge quando gli agenti sono cento.

Se ogni nuovo flusso di lavoro o ogni eccezione imprevista richiede altro lavoro di ingegneria, non state ampliando il software: state aumentando il ricorso a costosa manodopera umana.

La maggior parte delle aziende che ricorre agli FDE sostiene che, prima o poi, i propri ingegneri passano ad altre attività. Prima di firmare un contratto che richiede la presenza di FDE, le aziende dovrebbero esigere prove che sia davvero così. Abbiamo già visto quanto l’RPA sia diventata fragile con l’evolversi dei processi aziendali. Non dovremmo aspettarci che gli agenti realizzati manualmente si comportino diversamente.

I flussi di lavoro aziendali spesso includono eccezioni non documentate e pratiche contrastanti tra i diversi team. Come fa Reindeer a rilevare come si svolge davvero il lavoro, distinguendo al contempo le conoscenze istituzionali utili dalle abitudini che non dovrebbero essere automatizzate?

La maggior parte delle aziende possiede un’enorme quantità di conoscenze istituzionali che non è documentata da nessuna parte: è custodita nella mente dei lavoratori. I nostri agenti partono da conoscenze parziali e imparano attraverso casi reali, chiedendo indicazioni agli esperti del settore quando si trovano di fronte a situazioni che non conoscono.

Ma imparare da un dipendente non significa replicarne ciecamente il comportamento. Il nostro sistema distingue le eccezioni individuali dagli schemi ricorrenti e propone modifiche più ampie da sottoporre all’approvazione umana.

Non cerchiamo di automatizzare ogni abitudine. Vogliamo trasformare le conoscenze istituzionali di valore in un’intelligenza affidabile, senza chiedere agli ingegneri di prevedere in anticipo ogni possibile situazione.

La maggior parte delle aziende che sviluppano sistemi di IA agentica inizia documentando e poi programmando il processo, attraverso interviste e un’analisi meticolosa dei dati passati. In realtà, però, il modo più efficace per imparare un processo è quello che si verifica ogni volta che entra in squadra una nuova persona: non memorizza un anno di dati né una procedura operativa standard di 3.000 pagine. Impara alcune competenze, osserva qualche esempio, comincia a lavorare, fa domande quando incontra qualcosa che non capisce e sviluppa le proprie conoscenze. È questo il processo che abbiamo creato.

L’IA agentica offre inoltre alle aziende l’opportunità di ripensare un processo, invece di limitarsi ad automatizzarlo così com’è. I team composti solo da persone, l’automazione basata su regole e il software tradizionale hanno plasmato ciascuno i processi in base ai propri limiti. Grazie ad agenti che apprendono insieme agli esperti, Reindeer aiuta le aziende a ripensare il modo in cui dovrebbe funzionare un processo, decidendo quali pratiche mantenere, quali abbandonare e in quali attività agenti e persone possono apportare il maggior valore.

Quando dite che gli agenti di Reindeer imparano continuamente in produzione, che cosa cambia concretamente: i pesi del modello, la memoria, la logica del flusso di lavoro o le policy esplicite? Potete illustrarci un’eccezione che insegna a un agente a gestire diversamente i casi futuri?

A cambiare sono il contesto e le competenze dell’agente: la logica del flusso di lavoro, le policy e le istruzioni su quando applicare ciascuna di esse.

Prendiamo un agente che gestisce le fatture. Riceve una fattura che supera del 4% l’ordine di acquisto e non trova una policy applicabile. Invece di elaborarla, l’agente sottopone il caso a un esperto. L’esperto spiega che per quel fornitore è stata approvata un’eccezione per i supplementi sul carburante. L’agente risolve il caso e la spiegazione viene salvata come contesto valido solo per quel fornitore.

Se lo stesso tipo di eccezione si ripresenta con altri fornitori e altri esperti la risolvono allo stesso modo, il sistema propone una modifica alla policy, per esempio: «I supplementi sul carburante fino al 5% sono accettabili quando il contratto lo consente». Prima che l’agente la applichi, la proposta viene sottoposta a test e all’approvazione di una persona. La risposta di un esperto risolve un singolo caso. Uno schema ricorrente tra più casi può diventare la base per una nuova regola.

La decisione di un dipendente può essere appropriata per un cliente o una transazione, ma non adatta come regola generale. Come stabilite se un feedback debba restare un’eccezione valida una tantum o diventare una proposta di modifica alla policy?

Teniamo distinta la risoluzione di un singolo caso dalla modifica del modo in cui un agente opera da quel momento in poi.

Un dipendente potrebbe autorizzare un’eccezione per un cliente, ma questo non significa che la stessa eccezione debba valere in generale. Direi addirittura che due dipendenti diversi potrebbero decidere diversamente di fronte alla stessa eccezione relativa allo stesso cliente. Il nostro sistema valuta le circostanze, individua gli schemi ricorrenti, risolve le contraddizioni e cerca potenziali conflitti con le policy esistenti.

Quando ci sono elementi a sostegno di una modifica più ampia, eseguiamo l’agente sulla nostra piattaforma di valutazione, una sorta di «The Truman Show» per agenti, e proponiamo un aggiornamento da sottoporre all’approvazione di una persona.

L’obiettivo è imparare dagli esseri umani, non replicare ciecamente le loro decisioni. Altrimenti, si finisce semplicemente per automatizzare gli errori.

Un agente può migliorare sui casi recenti e al contempo diventare meno affidabile nelle situazioni che prima gestiva correttamente. Quali test e procedure di approvazione deve superare una modifica proposta prima di entrare in produzione? E come individuate e annullate eventuali regressioni?

L’apprendimento continuo senza governance è pericoloso, perciò ogni modifica proposta deve superare tre salvaguardie: i test di regressione, l’approvazione di una persona e una soglia di affidabilità che determina quando l’agente può agire autonomamente.

I test vengono per primi e sono più difficili di quanto sembri, perché il lavoro operativo non ha risposte sempre univoche. Selezioniamo casi rappresentativi sulla base dei feedback degli esperti, definiamo criteri per confrontare i risultati e riproponiamo quei casi sia all’agente attuale sia alla versione proposta. Le azioni con effetti collaterali, come l’invio di un’e-mail, vengono eseguite in un simulatore creato a partire dalle esecuzioni passate; i casi di test che non corrispondono più alla policy vigente vengono ritirati. Per misurare l’effetto reale di una modifica, gli agenti devono credere di operare nel mondo reale e che le loro azioni abbiano conseguenze concrete: per esempio, l’inserimento di un record in SAP o l’invio di un’e-mail a un cliente. È l’unico modo per creare un vero quadro di valutazione per ciascun agente.

Un responsabile umano esamina quindi la modifica, gli elementi che la giustificano e i risultati dei test, e può approvarla, modificarla o respingerla. Il modo in cui opera l’agente non cambia finché non arriva l’approvazione.

Dopo che una modifica entra in vigore, la soglia di affidabilità tutela l’azienda. L’agente agisce autonomamente solo quando il suo livello di affidabilità supera la soglia; i casi al di sotto vengono sottoposti a un esperto. I team operativi regolano direttamente questa soglia, così possono iniziare con un approccio prudente e concedere all’agente maggiore autonomia man mano che consolida la propria esperienza.

Se la qualità peggiora dopo una modifica, il sistema rende automaticamente più severi i criteri di revisione, così un numero maggiore di casi viene sottoposto agli esperti; i loro feedback fanno emergere il problema attraverso lo stesso ciclo che ha portato alla proposta di modifica. Ogni modifica alle policy ha una versione, un responsabile identificabile e un registro, in modo che il team possa vedere che cosa è cambiato, chi lo ha approvato e perché, e ripristinare la versione precedente.

Ridurre il lavoro di ingegneria può comunque lasciare ai team operativi una mole significativa di attività, tra cui la revisione delle eccezioni e la correzione degli agenti. Come misurate se Reindeer riduce l’impegno umano complessivo necessario, invece di trasferirlo a un altro team?

La realtà è che la maggior parte delle aziende ha già un team di persone che svolge manualmente questo lavoro. Il nostro obiettivo non è trasferire quel carico a un altro team, ma ridurlo nel tempo. Affidiamo alle persone più esperte di quel team il compito di insegnare all’agente a gestire le eccezioni e a prendere decisioni migliori in autonomia.

Il problema del modello FDE è che spesso trasferisce il lavoro da dipendenti operativi relativamente poco costosi a ingegneri costosi. Non risolve il problema del costo del lavoro: lo rende più oneroso. Reindeer non introduce ingegneri in questo processo. Misuriamo invece il successo in base a quanto aumenta nel tempo il lavoro che gli agenti riescono a risolvere autonomamente e a quanto diminuisce l’intervento umano necessario nell’intero processo.

Monitoriamo tre aspetti: la percentuale di casi che l’agente risolve dall’inizio alla fine senza intervento umano, il numero di interventi degli esperti per caso e il tempo totale di gestione per caso, considerando insieme agenti e persone. Se il terzo dato non diminuisce, stiamo solo spostando il lavoro da una parte all’altra.

Potrebbe raccontarci un’implementazione presso Hellmann Worldwide Logistics o Papaya Global e spiegare che cosa è cambiato dal lancio alla gestione quotidiana? Che cosa è successo all’accuratezza, al tasso di eccezioni, ai tempi di evasione e alla quantità di intervento umano necessaria?

Hellmann Worldwide Logistics è un ottimo esempio di come gli agenti possano migliorare nel tempo le operazioni nel mondo reale. Il team addetto alle tariffe dedicava moltissimo tempo all’elaborazione manuale delle richieste di spedizione, tra e-mail, fogli di calcolo e altri documenti; spesso occorrevano giorni per preparare un preventivo.

Siamo partiti da circa 20 richieste di esempio per comprendere il flusso di lavoro e addestrare l’agente. In seguito, gli esperti tariffari di Hellmann hanno iniziato a lavorare direttamente con il sistema, fornendo riscontri e aiutandolo a gestire le eccezioni. Durante i test abbiamo monitorato accuratezza e velocità, continuando a controllare le prestazioni anche dopo l’entrata in produzione dell’agente.

Oggi le richieste di routine vengono gestite automaticamente, mentre i casi più complessi vengono inoltrati al team. È fondamentale che l’agente riconosca quando mancano informazioni, invece di fare supposizioni, così i dipendenti possono intervenire quando è davvero necessaria la loro competenza.

Il risultato è stato una riduzione dei tempi di evasione dei preventivi, con meno attività manuali di inserimento dati e più tempo da dedicare ai clienti. Hellmann ha inoltre registrato un aumento del tasso di successo dei preventivi. L’obiettivo non è eliminare le persone dal processo, ma ridurre continuamente la quantità di lavoro di routine che richiede il loro intervento.

Che cosa avete imparato sui limiti di questo approccio? Quali caratteristiche di un flusso di lavoro indicano che è pronto per un agente adattivo, e quali suggeriscono che l’azienda dovrebbe prima riprogettare il processo o mantenere l’automazione tradizionale?

Non tutti i processi hanno bisogno di un agente di IA. Le opportunità più promettenti riguardano flussi di lavoro ripetitivi e ad alto volume che richiedono valutazioni contestuali, soprattutto quando le informazioni sono distribuite su più sistemi e i dipendenti gestiscono regolarmente delle eccezioni.

La lezione più chiara che abbiamo tratto dalle nostre implementazioni è che nelle aziende sta emergendo una nuova funzione, proprio come è successo con il revenue operations insieme ai CRM e con il DevOps insieme al cloud. Quando le aziende passano da pochi agenti a un’intera flotta, hanno bisogno di una persona o di un team che li gestisca come un responsabile di reparto gestisce il personale: assumendosi la responsabilità dei KPI e del ROI, decidendo quali attività affidare agli agenti e quali no, e approvando le modalità con cui vengono modificati. Le aziende che stanno già creando questa funzione avanzano più rapidamente e sono quelle meglio posizionate per vincere.

Le divergenze nelle pratiche non sono un motivo per aspettare. Gli esperti non sono d’accordo in quasi tutte le attività operative e il nostro sistema è progettato per far emergere queste contraddizioni e trasformarle in proposte di policy. Risolverle rientra nelle responsabilità di chi ricopre quel ruolo: un altro motivo per istituirlo prima di ampliare l’uso degli agenti.

Anche l’approccio in sé ha dei limiti. Le operazioni fondamentali non saranno completamente automatizzate e non è questo il nostro obiettivo. Gli agenti ampliano gradualmente il proprio ambito di intervento e, per scelta progettuale, i casi ad alto rischio restano affidati alle persone.

Con il miglioramento dei modelli di fondazione e degli strumenti per creare agenti, quali aspetti dell’implementazione nelle aziende prevedi che diventeranno soluzioni standard e in quali ambiti Reindeer sta costruendo un vantaggio che si rafforza a ogni messa in produzione?

I modelli di base diventeranno sempre più intercambiabili man mano che saranno più economici, veloci e capaci. Anche creare agenti di base e collegarli ai sistemi aziendali sta diventando più semplice.

Ma creare un agente non equivale a renderlo affidabile nel tempo all’interno di un’azienda complessa.

Il vero vantaggio competitivo consiste nella conoscenza proprietaria di come opera concretamente un’azienda, una realtà in continua evoluzione. Ogni caso gestito in produzione offre ai nostri agenti l’opportunità di imparare, risolvere le eccezioni future e ridurre l’intervento umano.

I modelli diventeranno più economici. Creare agenti sarà più facile.

Le aziende vincitrici elimineranno la costosa infrastruttura di ingegneria umana necessaria per mantenere questi agenti operativi e pertinenti nel tempo.

Grazie per la bella intervista. I lettori che desiderano saperne di più sugli agenti di IA adattivi per le aziende, sull’automazione operativa e sull’apprendimento guidato dalle persone possono visitare Reindeer.