Forward Deployed Engineering— perché l’AI ha bisogno di un ingegnere in azienda, non di un altro progetto pilota

Che cos’è un forward deployed engineer

Il termine viene da Palantir. L’azienda invia i propri ingegneri direttamente presso enti pubblici e grandi aziende, perché il suo software funzioni davvero con i sistemi già presenti. Un annuncio di lavoro di Palantir paragona la responsabilità a quella del CTO di una start-up.

McKinsey definisce il ruolo nello studio “The AI-centric imperative” del 16 ottobre 2025 così: esperti tecnici inseriti direttamente presso il cliente per garantire implementazione, integrazione e adozione su larga scala dell’AI. Avviano progetti pilota, adattano gli agenti ai processi del cliente e ottimizzano l’esercizio nel tempo. Secondo McKinsey accorciano il tempo per ottenere valore e aumentano la probabilità che una soluzione venga usata a lungo e ampliata.

La differenza rispetto ai ruoli noti sta nella responsabilità. Il consulente raccomanda e consegna. Il sales engineer mostra cosa è possibile. L’FDE lo costruisce nell’ambiente reale e resta finché funziona. Non si misura sul collaudo, ma sul fatto che le persone usino il sistema nel lavoro di tutti i giorni.

Cosa dice lo studio, e cosa non dice

Chi cita lo studio dovrebbe sapere su cosa si basa. Si rivolge ai produttori di software, non alle aziende che usano l’AI. I dati del sondaggio provengono dal McKinsey Software CxO AI Impact Survey, Q2 2025, con 81 dirigenti di aziende software. Ai forward deployed engineer è dedicato un paragrafo all’interno di uno dei sette cambiamenti, quello che riguarda vendite e relazione con i clienti. Non è uno studio sugli FDE. I numeri che contano per il nostro tema:

Il resto dello studio tratta i modelli di prezzo (dalle licenze per utente alla fatturazione per consumo o per risultato), le infrastrutture pronte per l’AI e la trasformazione del personale. Per una PMI è comunque istruttivo, perché mostra dall’altra parte del tavolo come i fornitori intendono vendere e introdurre l’AI.

La trappola del progetto pilota

Il numero più importante dello studio è un limite. Le aziende software riportano nei progetti pilota un aumento della produttività nello sviluppo del 30–50%. Questi guadagni, scrive McKinsey, raramente si traducono in un impatto equivalente su ricavi o utili. Il motivo: gli strumenti sono stati inseriti nei vecchi processi invece di ridisegnare i processi.

Chi ha introdotto l’AI in una PMI conosce lo schema. Il pilota convince nella presentazione. Poi deve collegarsi al sistema reale, e si scopre che i codici articolo esistono in due grafie, che l’approvazione passa da una persona che nel pilota non c’era e che il team non riesce a inserire il nuovo passaggio nella propria giornata. Nessuno è responsabile, perché il team del pilota ha finito e quello dell’esercizio non ha ancora iniziato.

È esattamente in questo spazio che lavora un forward deployed engineer. Ha costruito il pilota e resta per il tratto successivo.

Perché il lavoro presso il cliente cresce invece di diminuire

Un risultato dello studio va contro il racconto abituale secondo cui l’AI automatizza tutto. Nei servizi professionali, cioè il lavoro presso il cliente, l’uso dell’AI è al 26%, il secondo più basso su dieci funzioni; solo gli acquisti sono più in basso. Anche la riduzione dei costi attesa, 10–20%, è la più piccola. McKinsey lo spiega in modo esplicito: i risparmi vengono in parte assorbiti dal crescente bisogno di personalizzazione. Nel modello del personale futuro, i servizi professionali sono tra le aree che tornano a crescere dopo i tagli.

Dietro c’è una seconda tesi dello studio. Le applicazioni uguali per tutti vengono sostituite da soluzioni su misura per settore, ambiente del cliente e problema. McKinsey la chiama “service-as-software”: piattaforma, agenti, automazione e competenza in un unico pacchetto che consegna un risultato invece di uno strumento. Più si personalizza, più lavoro serve presso il cliente. E, secondo lo studio, il vantaggio si sposta dalle funzionalità ai dati: le funzionalità si copiano, l’accesso ai propri dati di qualità no.

Cosa significa per le PMI

Secondo Lightcast, negli Stati Uniti un forward deployed engineer ha uno stipendio mediano offerto di oltre 188.000 dollari l’anno. I produttori impiegano queste persone dove conviene: presso i grandi clienti. Una PMI con 80 licenze non ne avrà uno. Non è una critica, è aritmetica.

Secondo McKinsey, quasi il 60% degli acquisti di piattaforme AI avviene già in modo ibrido, con partner esterni per consulenza e implementazione. Lo studio descrive anche come cambiano queste collaborazioni: meno partner, che entrano prima, sviluppano insieme al cliente e restano dopo la vendita per garantire l’adozione. È il modo di lavorare di un FDE, solo al di fuori del produttore.

La nostra conclusione, esplicitamente non quella dello studio: chi vuole collegare l’AI ai propri dati e ai processi centrali dovrebbe chiedere al proprio partner di implementazione proprio questo modo di lavorare. Non il titolo, ma ciò che significa.

Come capire se il tuo partner AI lavora così

Cinque domande da fare prima dell’incarico. Le risposte mostrano in fretta se qualcuno arriva fino all’esercizio o si ferma al pilota:

• Si costruisce nei tuoi sistemi o in un ambiente demo? Un pilota su dati di esempio dimostra poco. I problemi stanno nelle tue anagrafiche reali, nei permessi e nelle interfacce.
• Chi è responsabile dal requisito all’esercizio? Se il team cambia tra concetto e realizzazione, in quel punto si perde conoscenza. Chiedi un nome, non un reparto.
• Come si misura il successo? “Collaudato” non è un indicatore. Risposte buone sono: quante pratiche a settimana passano dal sistema, quante richieste di chiarimento spariscono, quanto spesso qualcuno deve intervenire.
• A chi appartengono codice, configurazione e dati? Se la soluzione gira solo nell’account del partner, sei vincolato. Tutto dovrebbe stare nei tuoi account ed essere documentato.
• Cosa succede dopo il go-live? Le prime settimane di esercizio mostrano cosa mancava nel pilota. Un FDE pianifica questa fase e resta finché il tuo team va avanti da solo.

Quando non serve

Non ogni introduzione dell’AI richiede un ingegnere in azienda. Chi acquista uno strumento pronto che funziona senza collegarsi ai propri sistemi, come uno strumento di scrittura, traduzione o trascrizione, ha bisogno di una buona introduzione e di regole chiare, non di integrazione. Questo modo di lavorare conviene quando l’AI deve accedere ai propri dati, scrivere nei sistemi esistenti o preparare decisioni in un processo centrale. Lì è l’integrazione a determinare il valore, non il modello. Come scegliere un partner per progetti di questo tipo è spiegato nella nostra guida alla scelta di un’agenzia AI.

Come lavoriamo noi

Lavoriamo così perché ne abbiamo bisogno noi stessi. La nostra azienda funziona con gli stessi agenti che costruiamo per i clienti, e conosciamo il divario tra pilota ed esercizio dal nostro lavoro quotidiano. Come funziona in concreto lo trovi in Come lavoriamo. Costruiamo nei tuoi account, il codice è tuo e i modelli restano sostituibili.

Domande frequenti: Forward Deployed Engineering