Forward Deployed Engineer (FDE): perché le aziende di IA mandano gli ingegneri dai clienti

Negli ultimi due anni, tra le offerte di lavoro delle aziende di IA compare con sempre maggiore frequenza una nuova figura: il Forward Deployed Engineer (FDE), l'ingegnere schierato in prima linea. Non lavora in sede a un prodotto generico: entra nelle aziende clienti con modelli e piattaforme e, insieme ai team di business, collega l'IA ai dati, ai processi e ai sistemi reali. Il successo degli FDE dice una cosa chiara: la parte più difficile dell'adozione dell'IA non è il modello, ma l'«ultimo miglio» dentro l'azienda cliente.

Che cosa fa, in concreto, un FDE? Perché anche aziende come OpenAI e Anthropic costruiscono team di questo tipo su larga scala? In questo articolo vediamo che cos'è un FDE e come è nato, perché le aziende di IA stanno formando questi team, perché l'adozione dell'IA ha bisogno di un ruolo come questo, in che cosa gli FDE si distinguono da alcune figure affini e quali competenze servono, e come un'azienda può collaborare con gli FDE o far crescere i propri «FDE interni».

Che cos'è un Forward Deployed Engineer (FDE)?

L'FDE è un «ingegnere del software che lavora a fianco del cliente». Scrive codice, costruisce pipeline di dati, configura sistemi, ma non serve «tutti i clienti»: serve un cliente specifico, e il metro di giudizio è se i problemi di business di quel cliente sono stati risolti. Un ingegnere tradizionale sviluppa una funzionalità per molti clienti; un FDE combina molte funzionalità per un solo cliente.

Il ruolo è diventato noto soprattutto grazie a Palantir, azienda di software per l'analisi dei dati (fonte). Nel suo blog ufficiale, nell'articolo «Dev versus Delta», Palantir distingue due tipi di ingegneri: i software engineer del reparto di sviluppo prodotto (internamente detti «Dev»), che costruiscono un componente della piattaforma e si concentrano su «una capacità al servizio di molti clienti», e i forward deployed software engineer dell'area sviluppo del business (internamente detti «Delta»), che lavorano in squadra su un singolo cliente e si concentrano su «un cliente, molte capacità». Il loro successo si misura sui risultati di business del cliente, per esempio sulla riduzione dei difetti in linea di produzione (fonte). I Delta intervistati nell'articolo trascorrono ogni settimana una parte consistente del tempo presso la sede del cliente.

Un altro articolo del blog di Palantir elenca le attività quotidiane di un FDE: progettare, sviluppare e distribuire per il cliente processi di business e modelli di dati dedicati; costruire e mantenere pipeline di dati su larga scala a supporto delle operazioni; configurare i permessi di accesso in linea con i requisiti normativi e di conformità; garantire stabilità, aggiornamenti e monitoraggio dei sistemi di produzione, individuando la causa all'origine dei guasti; e infine riportare al team di prodotto ciò che si impara sul campo, in modo che le soluzioni di valore generale confluiscano nella piattaforma (fonte).

Va notato che Palantir tiene volutamente distinti gli FDE e i consulenti. Secondo la sua descrizione, l'FDE usa piattaforme e componenti software già pronti con l'obiettivo di costruire per il cliente sistemi destinati a durare, non report di analisi una tantum né soluzioni su misura assemblate cliente per cliente. È proprio questa la differenza di fondo rispetto alla consulenza tradizionale: si consegna un sistema che continua a funzionare, non un consiglio.

Perché le aziende di IA stanno formando team di FDE?

Le aziende che sviluppano modelli sono, in origine, quelle che più somigliano a chi vende un prodotto standard, eppure anche loro hanno iniziato a mandare ingegneri dai clienti. Il motivo è semplice: il cliente compra il modello, ma non è detto che riesca a metterlo in uso; e se non lo usa, è difficile che il contratto venga rinnovato o ampliato.

Alcune informazioni pubbliche illustrano questa tendenza:

• La domanda di questi ruoli cresce rapidamente. eWeek, nel novembre 2025, citando il Financial Times, riferisce che OpenAI, Anthropic, Cohere e altre aziende stanno ampliando i team di FDE; secondo i dati del portale di lavoro Indeed, tra gennaio e settembre 2025 le offerte per posizioni FDE sono cresciute di oltre l'800% (fonte). Va precisato che si tratta di una crescita relativa: non significa che il numero assoluto di queste posizioni sia già elevato.
• Le aziende di modelli ampliano gli organici. Lo stesso articolo ricorda che OpenAI ha creato il suo team FDE all'inizio del 2024 e prevede di portarlo a circa 50 persone nel 2025, mentre Anthropic intende quintuplicare nel 2025 il team di IA applicata, FDE compresi.
• Il deployment è diventato un business a sé. Nel maggio 2026 OpenAI ha annunciato la nascita di una società di deployment a gestione indipendente, la OpenAI Deployment Company, con un investimento iniziale superiore a 4 miliardi di dollari, guidato da TPG e con la partecipazione di 19 investitori, società di consulenza e system integrator; ha annunciato inoltre l'acquisizione della società di consulenza di IA applicata Tomoro, che dovrebbe portare circa 150 FDE ed esperti di deployment (fonte). Secondo la descrizione di OpenAI, questi FDE entrano nell'organizzazione del cliente, individuano le aree in cui l'IA può dare il massimo contributo, riprogettano attorno a esse processi e infrastruttura e collegano i modelli ai dati, agli strumenti e ai flussi di lavoro del cliente.
• I requisiti di selezione sono molto concreti. La pagina attuale di Anthropic dedicata alla posizione di FDE specifica che il ruolo fa parte del team di IA applicata, che l'ingegnere si inserisce all'interno dei clienti strategici per sviluppare con Claude applicazioni pronte per la produzione e che trascorre dal 25% al 50% del tempo in trasferta presso i clienti (fonte).

In un articolo del giugno 2025, la società di investimento a16z definisce questo approccio «services-led growth», la crescita guidata dai servizi: i prodotti di IA per le imprese richiedono molto lavoro di implementazione, e le startup possono accettare margini lordi più bassi nella fase iniziale, usando servizi approfonditi per integrare processi e dati del cliente (fonte). In altre parole, l'FDE è al tempo stesso uno strumento di delivery e il modo in cui un'azienda di IA mette radici dentro il cliente.

Perché l'adozione dell'IA ha bisogno di un ruolo come l'FDE?

I grandi modelli sono generici, mentre il business di un'azienda è specifico. Il modello sa che cosa significa «reso», ma non sa quante approvazioni richiede un reso nella tua azienda, in quale sistema risiedono i dati, né quali clienti godono di una politica in deroga. Portare dentro queste conoscenze concrete è l'«ultimo miglio» dell'adozione dell'IA.

Questo ultimo miglio si blocca di solito in tre punti:

• I dati. I dati aziendali sono sparsi tra ERP, CRM, sistemi di magazzino, fogli di calcolo e e-mail, con definizioni incoerenti e permessi diversi. Perché l'IA possa rispondere alla domanda «perché questo ordine non è ancora partito?», deve poter leggere in sicurezza i dati di ordini, scorte e logistica.
• I processi. I processi reali sono pieni di regole ed eccezioni non scritte. Per esempio, in una richiesta d'acquisto, oltre una certa soglia serve la firma dell'amministratore delegato, e per alcuni fornitori occorre un confronto di prezzi aggiuntivo. Regole di questo tipo emergono solo lavorando sul campo, fianco a fianco con chi opera in prima linea.
• I sistemi. Perché i suggerimenti dell'IA diventino azioni, devono essere riscritti nei sistemi gestionali: creare un ticket, aggiornare le scorte, generare una fattura. Se le interfacce siano stabili, come gestire i fallimenti, chi abbia l'autorità di eseguire: sono tutte decisioni che richiedono giudizio ingegneristico.

Anche l'articolo di a16z osserva che gli agenti di IA devono collegarsi in sicurezza ai database, alle interfacce e ai flussi di lavoro interni dell'azienda e devono conoscere la logica di business e lo storico; mettere al lavoro un agente somiglia molto all'inserimento di un nuovo collaboratore (fonte). La divisione tradizionale dei compiti qui spesso non basta: il team di prodotto è troppo lontano dal cliente per vedere i problemi concreti; il consulente di implementazione conosce i processi, ma non necessariamente sa scrivere codice o mettere a punto un modello; il team IT interno conosce i sistemi, ma non sempre le caratteristiche e i limiti dei grandi modelli. Il valore dell'FDE sta nel riunire in una sola persona, o in un piccolo team, tre cose: conoscenza del business, dei sistemi e dei modelli.

Prendiamo un'azienda di distribuzione all'ingrosso che vuole far elaborare all'IA, in automatico, gli ordini che i clienti inviano via e-mail. In fase di demo, il modello estrae con precisione prodotti e quantità da un'e-mail ben strutturata; sul campo, però, l'FDE scopre che ogni cliente usa le proprie sigle per i prodotti, che alcuni ordini arrivano con scansioni di documenti scritti a mano e che altri richiedono prima una verifica del fido. Solo dopo aver integrato la tabella di corrispondenza dei prodotti, le regole di credito e il processo di passaggio a un operatore per i casi anomali, questa IA diventa davvero utilizzabile.

In che cosa l'FDE si distingue da software engineer, consulenti di implementazione e pre-sales engineer?

L'FDE si confonde facilmente con alcune figure affini. In breve: l'FDE è vicino al cliente come un consulente di implementazione, costruisce i sistemi con le proprie mani come un software engineer e risponde dei risultati di business dopo il go-live.

La tabella seguente confronta i quattro ruoli lungo diverse dimensioni:

Le aziende non definiscono questi ruoli in modo del tutto uniforme: la tabella riflette la ripartizione più comune ed è solo indicativa.

Quali competenze servono a un buon FDE?

Il profilo richiesto a un FDE è «a T»: competenze ingegneristiche profonde, comprensione del business e capacità di comunicazione ampie. La cosa più rara non è una singola competenza, ma la capacità di portare avanti il lavoro in autonomia in ambienti cliente ambigui e in continuo cambiamento.

Dalle descrizioni di ruolo di Palantir e dai requisiti di selezione di Anthropic, si possono ricondurre a cinque tipi di competenze:

• Solida capacità ingegneristica. Saper scrivere codice per ambienti di produzione, costruire pipeline di dati e realizzare integrazioni di sistema. La pagina di selezione di Anthropic richiede esperienza nell'uso dei grandi modelli in produzione, compresi progettazione dei prompt, sviluppo di agenti e metodi di valutazione, oltre a una buona padronanza di Python (fonte).
• Imparare in fretta ambiti sconosciuti. Oggi si tratta del processo di controllo qualità di un'azienda manifatturiera, il mese prossimo potrebbe essere il sistema di pianificazione di una società di logistica. Palantir elenca tra le capacità necessarie a un FDE quella di «padroneggiare rapidamente sistemi, domini e codebase poco familiari» (fonte).
• Tradurre i problemi di business in soluzioni tecniche. Capire le lamentele di chi lavora nel business, risalire con le domande al problema reale che c'è dietro e poi valutare che cosa affidare all'IA, che cosa risolvere con regole e che cosa non fare affatto.
• Comunicazione e costruzione della fiducia. L'FDE si confronta allo stesso tempo con il personale operativo, con il reparto IT e con il management, e deve anche coordinare il team di prodotto della propria azienda. La pagina di selezione di Anthropic si aspetta esplicitamente che l'FDE lavori in autonomia, mantenga il ritmo anche nell'incertezza e comunichi bene.
• Responsabilità sul risultato. Il lavoro dell'FDE non finisce quando la demo riesce: deve seguire la stabilità del sistema dopo il go-live e gli effetti sul business, e trasformare le pratiche riutilizzabili in metodo, da riportare al team di prodotto.

Come collaborare con gli FDE o far crescere i propri «FDE interni»? Guida passo passo

Per la maggior parte delle PMI, gli FDE delle aziende di modelli non busseranno necessariamente alla porta. Ma il loro modo di lavorare si può benissimo prendere a modello: che si collabori con un team esterno o si cresca internamente, il punto è far lavorare fianco a fianco, su uno stesso problema concreto, chi conosce il business e chi conosce la tecnologia.

Passo 1: scegli un problema di business concreto e misurabile. Non partire da «vogliamo usare l'IA», ma da criticità precise come «l'inserimento degli ordini impegna tre persone ogni giorno» o «la riconciliazione di fine mese richiede una settimana». Anche OpenAI descrive il proprio servizio di deployment come una diagnosi mirata, seguita da un lavoro concentrato su pochi processi prioritari (fonte).

Passo 2: prepara in anticipo l'accesso a dati e sistemi. L'attesa più comune per un FDE è quella di dati e permessi. Prima di iniziare la collaborazione, chiarisci quali sistemi vanno collegati, chi approva gli accessi e quali dati non possono uscire dall'azienda, così che gli ingegneri non si trovino senza nulla da fare appena arrivati.

Passo 3: nomina un responsabile di business che partecipi per tutto il percorso. Per quanto bravo, un FDE esterno non conosce le tue eccezioni e le tue regole implicite. Serve un responsabile di business che conosca il processo e abbia potere decisionale, e che ogni settimana segua con l'FDE l'avanzamento, risponda alle domande e decida i compromessi.

Passo 4: costruisci insieme sul campo, a piccoli passi. Fai sedere l'FDE accanto al reparto di business, realizza prima una versione minima in grado di gestire documenti reali, poi perfezionala in base al feedback di chi lavora in prima linea. Ogni iterazione va verificata con dati reali, non solo giudicata dall'effetto della demo.

Passo 5: al go-live, definisci subito manutenzione e passaggio di consegne. Chiarisci chi interviene quando il sistema ha un problema, chi decide le modifiche al modello o al processo e dove sono conservati i log delle operazioni. Prima che il team esterno si ritiri, vanno completati documentazione, formazione e trasferimento dei permessi, in modo che il sistema non dipenda da una singola persona esterna.

Passo 6: fai crescere gli FDE interni a partire dalla collaborazione. Scegli una o due persone che conoscano il business e abbiano voglia di imparare la tecnologia (per esempio un ingegnere IT che frequenta spesso le sedi operative, oppure una risorsa di business che conosce bene i dati), falle seguire il team esterno per tutto il progetto e, dal secondo progetto, falle guidare gradualmente. Il valore dell'FDE interno è che il prossimo progetto di IA non deve ripartire da zero.

Domande frequenti sui Forward Deployed Engineer (FDE)

Qual è la differenza tra un FDE e lo sviluppo in outsourcing? Lo sviluppo in outsourcing di solito consegna funzionalità sulla base di un documento di requisiti, che il cliente deve scrivere con chiarezza; l'FDE invece scopre e definisce i problemi insieme al cliente, risponde dei risultati di business e costruisce la soluzione su piattaforme e prodotti già pronti, anziché sviluppare da zero.

Una PMI deve assumere un FDE? Non necessariamente. Per una PMI è più realistico coinvolgere a fondo le persone chiave interne quando si collabora con un team esterno, facendo crescere gradualmente uno o due «FDE interni» con competenze sia di business sia tecniche.

Con una domanda che cresce così in fretta, quella degli FDE è solo una moda passeggera? Il nome del ruolo potrebbe cambiare, ma la necessità che sta dietro difficilmente scomparirà: finché i modelli saranno generici e il business sarà specifico, servirà qualcuno che li colleghi. Con la maturazione degli strumenti, parte del lavoro di integrazione diventerà più semplice, ma la comprensione del business e la responsabilità sul risultato continueranno a richiedere le persone.

Su che cosa valutare se una collaborazione con un FDE ha avuto successo? Contano tre aspetti: se il sistema è davvero entrato nell'uso quotidiano, se gli indicatori di business concordati sono migliorati e se, dopo l'uscita del team esterno, l'azienda è in grado di mantenere ed estendere il sistema in autonomia. Guardare soltanto l'effetto della demo o il numero di funzionalità consegnate porta spesso a sopravvalutare i risultati.

Riferimenti

• Dev versus Delta: Demystifying engineering roles at Palantir, blog ufficiale di Palantir, data di pubblicazione non indicata (consultato a novembre 2026)
• A Day in the Life of a Palantir Forward Deployed Software Engineer, blog ufficiale di Palantir, data di pubblicazione non indicata (consultato a novembre 2026)
• Why Forward-Deployed Engineers Are in High Demand, eWeek, novembre 2025
• OpenAI launches the Deployment Company, OpenAI, maggio 2026
• Forward Deployed Engineer (pagina di selezione), Anthropic, consultato a novembre 2026
• Services-Led Growth, a16z, giugno 2025