Forward Deployed Engineer: anatomia di un ruolo che vive del proprio superamento

1. Un mestiere che si fa di persona

Il software aziendale si vende da remoto e si installa da solo. È il modello che ha costruito l’industria degli ultimi vent’anni: si compra un accesso, si configura, si parte. Eppure la figura professionale che i maggiori fornitori di intelligenza artificiale si stanno contendendo in questo momento fa il contrario. Va fisicamente dentro l’azienda del cliente, ci resta per mesi, e il suo lavoro finisce quando quell’azienda è in grado di cavarsela da sola.

La ragione di questa apparente arretratezza sta in una cosa che i modelli linguistici non sanno fare. Un sistema automatico che debba operare dentro un processo aziendale ha bisogno di sapere non solo che cosa significhino le parole di quel dominio, ma quali stati siano validi, quali azioni siano disponibili, chi possa compiere quali operazioni e che cosa succeda quando una regola cambia. Quel corpo di conoscenze non sta scritto in nessun posto. È disperso tra schemi di database, specifiche di interfacce, manuali di procedure, tabelle di permessi, fogli di calcolo e documentazione dimenticata, e una parte vive soltanto nella testa di chi lavora lì da quindici anni.

Ricomporlo è il mestiere. Nella letteratura scientifica quel corpo di conoscenze ha un nome, ed è l’oggetto di cui parla questo articolo.

Qui nasce la tensione che percorre tutto il testo. Quella ricomposizione manuale, costosa e lenta, è esattamente ciò che l’industria del software e la ricerca accademica stanno correndo ad automatizzare. Il ruolo esiste per colmare un vuoto che molti stanno lavorando per chiudere, e il suo obiettivo dichiarato è rendere il cliente autonomo, cioè rendersi non necessario. È un mestiere costruito attorno al proprio superamento. La domanda seria riguarda che cosa resterà quando la parte automatizzabile sarà stata automatizzata.

Che cosa contiene questo articolo

Le quattordici sezioni procedono in quattro tempi. Possono essere consultate anche separatamente, ma alcuni argomenti rimandano alla definizione operativa introdotta nella sezione tre.

Le prime ricostruiscono le origini del ruolo, il modo in cui Palantir lo descrive nei propri documenti societari e ciò che lo distingue dalle figure professionali vicine. Si entra poi nel merito del lavoro: quali competenze emergono dagli annunci, dalle fonti ufficiali e dai materiali disponibili sui processi di selezione, tenendo distinto il loro diverso grado di affidabilità; e quale parte di ciò che il FDE lascia nell’organizzazione del cliente può essere interpretata, attraverso la letteratura scientifica, come un livello di grounding operativo.

La parte centrale affronta la domanda sulla durata del ruolo da due lati indipendenti: quali sue attività si sta cercando di automatizzare, con quali risultati e quali limiti documentati; e quali investimenti, forme organizzative e posizioni di mercato sono osservabili in sei paesi dopo l’ingresso dei grandi fornitori.

L’ultima parte guarda all’Italia, dove il titolo sta iniziando ad arrivare negli annunci ma non ancora nelle codifiche professionali, e considera che cosa questo modello comporti per un’impresa media: chi assume la responsabilità dopo l’uscita dell’ingegnere e come valutare economicamente una proposta di deployment, adottando il direttore finanziario come potenziale interlocutore. Prima delle conclusioni, una sezione affronta il costo del mestiere per chi lo esercita: trasferte, reperibilità, burnout e codice senza casa, cioè la parte che gli annunci tendono a lasciare fuori.

Come sono stati trattati i dati

Su questo tema circolano parecchi numeri di seconda mano. Le cifre riportate qui sono state controllate alle fonti originali, e dove il controllo ha smentito il dato circolante l’articolo lo dice. Dove una fonte non è stata verificabile, oppure dove non è stato possibile consultare integralmente un documento non liberamente accessibile, il limite è dichiarato nel punto in cui il dato viene usato.

Due delle rilevazioni sulle offerte di lavoro sono mie e non vengono da fonti pubblicate. I dati grezzi, le query esatte e i criteri di inclusione sono riportati nell’appendice, così che chiunque possa verificare e replicare le rilevazioni.

Quasi tutte le fonti primarie di questo articolo sono in inglese. Le citazioni dai lavori scientifici e dal documento aziendale su cui si regge la sezione sette sono traduzioni mie, e chi volesse verificarle nell’originale troverà un testo inglese: dove la formulazione esatta conta, il termine originale è riportato accanto alla resa italiana. Le citazioni da documenti societari, annunci di lavoro e norme tecniche restano invece in lingua originale, perché in quei casi la formulazione letterale è essa stessa il dato.

I dati di mercato provengono da una rilevazione condotta il 28 luglio 20261Fonte 1fonte primaria×Rilevazione propria condotta il 28 luglio 2026 sugli annunci Indeed in sei paesi, con classificazione manuale dei risultati perché la ricerca per parole chiave restituisce falsi positivi. Metodo, query e criteri sono esposti nella sezione otto. Limite accertato: il censimento su questa sola piattaforma, per l'Italia, ha visto tre datori di lavoro su dodici, e quasi tutti quelli mancati erano già online. Va letta insieme alla rilevazione LinkedIn del 30 luglio.non disponibile onlineultima verifica il 28 luglio 2026 con un metodo esposto nella sezione otto, che ne dichiara anche i limiti. Le sezioni sulla governance e sulla valutazione economica attingono al lavoro di tesi magistrale che ho dedicato al ruolo del direttore finanziario nell’era dell’intelligenza artificiale, discusso nel luglio 2026.

Una precisazione di trasparenza, visto che scrivo di un ruolo che sto studiando. Non esercito questa professione e non mi presento come tale: quanto segue è la mappatura di un fenomeno in corso, fatta da chi lavora da vent’anni sui sistemi che quel fenomeno attraversa.

---

2. Le origini del ruolo

La più antica occorrenza pubblica che sono riuscito a individuare risale al 2010, in un articolo di TechCrunch che identifica un dipendente di Palantir con il titolo di forward deployed engineer. La denominazione arriva dal lessico militare, dove una forza forward-deployed è quella stanziata sul terreno invece che nella base di origine.

Che cosa dice Palantir di sé stessa

La descrizione più precisa del modello si trova nel documento con cui Palantir si è quotata in borsa, il Form S-1 depositato il 25 agosto 2020 presso la Securities and Exchange Commission (SEC), l’ente federale statunitense che vigila sui mercati finanziari. Merita attenzione per due ragioni: è un documento con conseguenze legali, quindi scritto con cura, e in tutto il testo l’espressione compare due volte soltanto.

La prima si trova tra i fattori di rischio, cioè nella sezione dove un’azienda che si quota elenca ciò che può far sbagliare le proprie previsioni:

Palantir dichiara agli investitori che la crescita dei contratti dipende dalla capacità di una specifica figura professionale. Poche aziende mettono un mestiere tra le variabili che condizionano i ricavi.

La seconda occorrenza definisce l’acronimo e dice, in una riga, che cosa significhi lavorare così:

Il passaggio prosegue con la frase che spiega perché il modello esista, e che viene quasi sempre trascurata da chi lo racconta: «Time in the field adds to the continuous improvement of our platforms. As FDEs help customers make the most of our software, they observe users’ challenges firsthand.»

Il punto che quasi tutti saltano

Il modello forward deployed viene di solito presentato come una scelta di servizio, un modo per far funzionare il prodotto presso clienti difficili. La descrizione di Palantir dice altro: il tempo passato sul campo torna dentro la piattaforma.

È un circuito, e la direzione conta. Un servizio professionale tradizionale consegna un progetto e chiude il rapporto; ciò che ha imparato può restare nella testa di chi vi ha lavorato. Nel modello descritto nell’S-1, invece, l’ingegnere sul campo è anche lo strumento con cui l’azienda scopre che cosa il proprio prodotto non sa ancora fare. Il costo di inserire professionisti altamente specializzati nelle organizzazioni dei clienti si giustifica perché quelle persone tornano con informazioni che nessuna ricerca di mercato produce.

Questa è anche la ragione per cui il modello si presta a essere copiato adesso. Un fornitore di modelli linguistici si trova esattamente nella condizione in cui era Palantir: un prodotto potente e generico, clienti che non sanno bene come applicarlo ai propri processi, e nessun modo di scoprire dove si inceppa senza andare a vedere.

Il ruolo è cresciuto per accumulo

C’è una periodizzazione interna che aiuta a capire perché oggi le offerte di lavoro per questa figura risultino così difficili da soddisfare. Natalie Meurer, che oggi guida l’ingegneria degli agenti in Sierra dopo cinque anni passati in Palantir, ha dedicato al tema una sessione all’AI Engineer World’s Fair del giugno 2026. Secondo la cronaca pubblicata da BigGo Finance, Meurer descrive quattro generazioni successive del ruolo dentro Palantir tra il 2008 e il 2020, ciascuna delle quali ha aggiunto responsabilità senza togliere le precedenti: prima l’integrazione dei dati, poi lo sviluppo su misura, poi la formazione degli utenti, poi la responsabilità sul risultato operativo3Fonte 3fonte secondaria×Redazione BigGo della sessione di Natalie Meurer all'AI Engineer World's Fair del giugno 2026. La registrazione della sessione non è reperibile: la periodizzazione in quattro generazioni arriva quindi da una ricostruzione di prima mano riportata da terzi, e va presa per quello che è.apri la fonteultima verifica il 29 luglio 2026.

La conseguenza è che il profilo si è stratificato invece di specializzarsi. Su questo punto esiste una fonte diretta e verificabile: nell’intervista che Latent Space le ha dedicato il primo luglio 20264Fonte 4fonte primaria×Intervista di Latent Space a Natalie Meurer, Head of Agent Engineering in Sierra e prima cinque anni in Palantir, pubblicata il 1 luglio 2026 attorno alla sua sessione all'AI Engineer World's Fair. È la fonte diretta e verificabile sulle sue affermazioni riguardo alla mancanza di una definizione consistente del ruolo.apri la fonteultima verifica il 29 luglio 2026, Meurer dichiara che il ruolo «lacks a consistent definition», che è definito «more clearly […] by accountability to customers than by the shape of the role or the work you are doing», e che «the range of associated skill sets has become so broad that it can almost become nonsensical». È da lì che nascono gli annunci che pretendono nella stessa persona anni di ingegneria, di vendita diretta e di architettura delle soluzioni. La sezione sulle competenze torna su questo punto.

Oltre Palantir

Il modello è stato analizzato come pattern organizzativo generale, indipendente dall’azienda che lo ha reso famoso, in particolare dal Silicon Valley Product Group. E la rassegna sul grounding operativo citata più avanti registra che programmi analoghi sono descritti da OpenAI, Anthropic, ServiceNow e Accenture, trattandoli come lo schema ricorrente con cui l’intelligenza artificiale aziendale viene portata in produzione.

Quello che Palantir costruiva materialmente dentro i clienti, e che dà il nome all’oggetto di questo articolo, è il tema della sezione sei.

---

3. Definizione operativa: embedded × delivery × transfer

Il titolo Forward Deployed Engineer non ha un significato uniforme. Negli annunci viene usato anche per posizioni che hanno in comune soltanto il rapporto diretto con il cliente e l’impiego di modelli linguistici. Per evitare di riunire sotto lo stesso nome lavori diversi, questo articolo adotta una definizione operativa fondata su tre condizioni, tutte necessarie: embedded, delivery e transfer.

È una definizione proposta per questa analisi, non uno standard professionale: uno standard condiviso non esiste e i tre criteri non derivano da una classificazione sistematica degli annunci. La definizione è stata costruita a partire dalle fonti raccolte perché permette di distinguere il FDE dai ruoli adiacenti. Il mercato usa lo stesso titolo in modo più ampio, anche per posizioni che non soddisfano tutti e tre i criteri; nella sezione nove ne vedremo un esempio italiano. Le classificazioni usate nel resto dell’articolo vanno quindi lette secondo questa definizione, non come applicazione di un criterio riconosciuto dal mercato.

Embedded. Il lavoro si svolge dentro il processo del cliente, non a distanza da un ufficio del fornitore. La posizione OpenAI descritta per esteso nella sezione sei prevede sede a San Francisco, tre giorni di ufficio a settimana e, condizione dichiarata nell’annuncio verificato il 28 luglio 2026, trasferte fino al 50% del tempo. Il dato, poco noto in Italia, dà una misura di quanto il datore metta in conto: un tetto, non una media, e nemmeno la garanzia che quel tempo si passi dal cliente invece che in viaggio. Resta il segnale più concreto disponibile su che cosa l’azienda intenda per lavoro dentro il processo di qualcun altro.

Delivery. L’output è un sistema che gira in produzione, non un piano, una raccomandazione o un prototipo dimostrativo. Che cosa debba contenere quel sistema, cioè il livello di grounding che lo regge, è materia della sezione sei. Qui basta il criterio di ammissione: c’è delivery quando l’incarico arriva al rollout in produzione, non quando si ferma alla diagnosi.

Transfer. Il successo si misura dopo che il FDE se ne va, sull’autonomia con cui il cliente continua a far funzionare quello che è stato costruito. È il criterio più facile da dichiarare e più difficile da verificare: richiede di tornare a guardare un cliente mesi dopo la fine dell’incarico, cosa che quasi nessuna delle fonti raccolte per questo articolo fa. Ma è il criterio che separa il modello dal servizio professionale tradizionale descritto nella sezione due: un consulente che consegna e si disimpegna soddisfa il primo requisito e forse il secondo, mai il terzo.

Questa definizione lascia fuori diverse figure che si autodefiniscono forward deployed. Chi produce solo raccomandazioni resta escluso sul criterio della delivery. Chi costruisce un sistema ma lo fa dall’ufficio del fornitore resta escluso sul criterio dell’embedding. Chi entra, costruisce e sparisce senza lasciare nessuno in grado di mantenere il sistema resta escluso sul criterio del transfer, anche quando il codice funziona il giorno della consegna.

Vale la pena affiancare a questi tre criteri la definizione per esclusione che ne dà un praticante, perché arriva dallo stesso posto per una strada diversa. Magesh Kasthuri, principal consultant in Wipro, la formula in un intervento su CIO del 29 luglio 20265Fonte 5dichiarazione di un fornitore×Magesh Kasthuri, «Forward-deployed engineering in the age of agentic AI», CIO.com, 29 luglio 2026, rubrica Opinion. L'autore è principal consultant e distinguished member of technical staff in Wipro, azienda che vende esattamente i servizi descritti. L'articolo cita Gartner, Forrester, IDC ed Everest Group senza collegamento ai documenti originali: quelle attribuzioni non sono state verificate e qui sono riportate come citazioni di secondo grado.apri la fonteultima verifica il 30 luglio 2026: «FDE is not conventional staff augmentation. It is also not advisory consulting that ends with a roadmap. FDE is outcome-oriented engineering in the field». Le due esclusioni corrispondono ai due criteri più facili da mancare: la somministrazione di personale soddisfa l’embedding senza la delivery, la consulenza che si chiude con un piano non soddisfa nessuno dei due.

Dallo stesso intervento viene un criterio operativo che rende la delivery verificabile invece che dichiarata. Il primo rilascio deve essere «a thin production slice rather than a detached proof of concept», e la differenza è che quella fetta sottile comprende autenticazione reale, dati reali, chiamate agli strumenti sotto osservazione, test ripetibili e possibilità di tornare indietro. Un prototipo dimostrativo non ha niente di tutto questo, ed è per questo che il passaggio dal prototipo alla produzione costa quanto costruirlo daccapo.

Una precisazione sulla fonte, coerente con il metodo dichiarato in apertura. Wipro vende esattamente i servizi di cui l’articolo parla, quindi questo intervento non vale come prova su come stia il mercato. Vale come articolazione di un praticante che il lavoro lo fa, e in quanto tale si cita con il nome di chi lo firma e di chi lo paga.

I tre nomi in circolazione

In circolazione non ci sono due varianti del titolo ma tre: Forward Deployed Engineer, usato da Palantir, OpenAI, Salesforce, Wipro, Google e dalla voce Wikipedia sull’argomento; Forward Deployed AI Engineer, usato da AWS, BCG X, Altimetrik e Smartsheet; Forward Deployment Engineer, usato da Infosys e dalla stampa economica indiana come The Hindu BusinessLine.

La distinzione non è casuale, anche se ha eccezioni: chi discende dal ceppo Palantir o tratta la figura come una funzione di ingegneria tende a usare la forma nuda; chi la presenta come una novità nata con l’AI generativa vi inserisce la A. Smartsheet, che assume con il titolo esteso pur essendo un’azienda di software gestionale senza legami con Palantir, è un controesempio dichiarato.

Il punto analitico vale più della tassonomia in sé: la scelta del nome dice se chi assume considera il ruolo un’invenzione dell’era dei modelli linguistici o una funzione di deployment che quei modelli hanno reso urgente, ma che esisteva prima di loro. È la stessa domanda sulla durata del ruolo che il resto dell’articolo pone sui dati di mercato, posta qui a livello lessicale. Da qui in avanti l’articolo adotta la forma nuda, Forward Deployed Engineer, perché è quella prevalente tra chi il modello lo ha originato e tra chi lo tratta come funzione stabile.

---

4. I ruoli adiacenti, e dove passa il confine

I tre criteri appena definiti separano il FDE da ruoli che gli somigliano e con cui viene confuso negli annunci e nelle conversazioni di selezione.

Dimensione	AI Engineer	Solution Architect	Consulente AI	Forward Deployed Engineer
Contesto di lavoro	interno o presso il fornitore	assessment, spesso da remoto	esterno, a incarico	embedded presso il cliente
Output primario	componente tecnico	architettura, piano di progetto	raccomandazioni	sistema in produzione
Relazione col cliente	indiretta	episodica, per fase	periodica	continua per la durata dell’incarico
Obiettivo dichiarato	componente conforme ai requisiti	design che regge	insight che orienta una decisione	autonomia del cliente dopo l’uscita
Orizzonte temporale	sprint o rilascio	fase di assessment	durata dell’incarico	incarico più handover
Dove si vede il valore	nel codice	nel documento di architettura	nella presentazione finale	nel processo del cliente che cambia

La riga che pesa di più è quella dell’obiettivo dichiarato, perché è l’unica costruita sul criterio di transfer definito nella sezione precedente. Un Solution Architect può progettare un sistema che regge e non essere mai valutato su che cosa succeda dopo che il cliente lo adotta. Un FDE, nella definizione adottata qui, lo è.

Il confronto non descrive una progressione di carriera. Questi ruoli possono corrispondere a livelli diversi a seconda dell’azienda e, in molti casi, seguono percorsi paralleli. La responsabilità sull’autonomia del cliente distingue il FDE nella definizione adottata qui, ma non basta a collocarlo sopra o sotto un AI Engineer o un Solution Architect, né a ricavarne una fascia retributiva.

Le competenze richieste per svolgere il ruolo, con la soglia minima necessaria per affrontare una selezione, sono il tema della sezione che segue.

---

5. Le competenze e la soglia di ingresso

Il modo in cui le aziende costruiscono i colloqui per questo ruolo può dire più di una job description su ciò che cercano davvero. Le informazioni sui processi di selezione circolano però soprattutto attraverso guide commerciali e racconti di candidati; per questo vanno distinte da ciò che le aziende dichiarano ufficialmente.

Come lo misurano, e con quale grado di certezza

Che cosa risulta	Fonte	Statuto
Palantir dichiara che «our process is personalized to your skillset and the type of role that you’re looking for». Tutti iniziano con uno o due colloqui telefonici, poi si passa a una giornata onsite. HackerRank e Google Docs compaiono fra gli strumenti che possono essere usati nella fase telefonica	Pagina ufficiale Palantir sulla selezione6Fonte 6fonte primaria×Palantir, «Getting Hired» e «The Phone Interview», pagine ufficiali sul processo di selezione. Il processo è descritto come personalizzato in base al ruolo: prevede uno o due colloqui telefonici iniziali e, in caso di esito positivo, una fase onsite. HackerRank e Google Docs sono indicati tra gli strumenti che possono essere utilizzati nel colloquio telefonico.apri la fonteultima verifica il 31 luglio 2026	Ufficiale. Non esiste una sequenza fissa: numero e formato dipendono dal ruolo
Fra i round di valutazione degli FDE compaiono Learning & Reengineering e Decomposition, con criteri distinti: velocità di apprendimento, orientamento in un sistema sconosciuto, formazione di un modello mentale, scomposizione del problema, domande di chiarimento, consapevolezza dei vincoli	Materiali di Anjor Kanekar, che dichiara sette anni in Palantir come FDE e hiring manager7Fonte 7fonte primaria×Anjor Kanekar, «FDE Advisory Materials». L'autore dichiara sette anni in Palantir come forward deployed engineer e hiring manager e «1000+ technical interviews conducted and calibrated». Le schede di valutazione nominano i round «Learning & Reengineering» e «Decomposition», con i rispettivi criteri. Due avvertenze: il conteggio dei colloqui è un'autodichiarazione professionale, non un dato pubblicato da Palantir né verificato da terzi; e i materiali sono pubblicati da Platypus Technologies, che dichiara di aiutare le aziende «to build and run Forward Deployed Engineering functions», quindi vende consulenza sull'oggetto di cui parla.apri la fonteultima verifica il 31 luglio 2026	Autodichiarato. Ex dipendente, non Palantir. I materiali sono pubblicati da una società che vende consulenza sulla costruzione di funzioni FDE
TrueLayer: esercizio da svolgere a casa, colloquio video di due ore con due ingegneri, round finale da un’ora e mezza complessiva	Annuncio ufficiale del 16 luglio 20268Fonte 8fonte primaria×Annuncio ufficiale TrueLayer per «Agentic Enablement Engineer», pubblicato il 16 luglio 2026 e recuperato dall'API pubblica di Greenhouse. Il processo dichiarato è: take-home exercise, «2-hour video interview with two TrueLayer engineers», «1.5-hour total final round video interviews». È inoltre un ruolo interno adiacente, non un forward deployed engineer rivolto al cliente.apri la fonteultima verifica il 31 luglio 2026	Ufficiale e primario, ma riguarda un Agentic Enablement Engineer, cioè un ruolo interno adiacente e non un FDE rivolto al cliente

Il round più interessante è quello di decomposizione, e vale la pena descriverlo per quello che le fonti permettono. Al candidato viene posto un problema operativo formulato in modo volutamente vago, e la valutazione riguarda come lo scompone in parti verificabili prima ancora di proporre una soluzione: quali domande di chiarimento pone, quali vincoli riconosce, come articola i compromessi. Il round di apprendimento e re-engineering lo mette invece davanti a un sistema che non conosce, e misura la velocità con cui ci si orienta e si costruisce un modello mentale di come funziona. Nessuna delle due prove misura la conoscenza di un framework. Misurano come qualcuno si comporta davanti a un sistema mai visto, che è esattamente la condizione in cui un FDE si trova a ogni nuovo cliente.

Le guide per prepararsi ai colloqui indicano con grande precisione anche la durata dei singoli round. Non riporto queste cifre perché non ne ho trovato conferma in fonti primarie.

Cinque assi, due soglie per ciascuno

Le competenze del ruolo non si lasciano ridurre a una lista di tecnologie, e nessuna delle fonti raccolte per questo articolo prova a farlo. Conviene invece organizzarle su cinque assi, per ciascuno dei quali vale la stessa distinzione: una soglia minima che va posseduta per non essere scartati, e un fattore differenziante che separa chi fa il lavoro da chi lo fa bene.

1. Competenze tecniche

La soglia minima è ampia e trasversale: sviluppo software di livello produttivo in almeno un linguaggio generalista (Python, TypeScript, Go, Java compaiono tutti negli annunci raccolti), SQL avanzato e familiarità con pipeline dati (Spark, Airflow), e una base di infrastruttura cloud e containerizzazione (Docker, Kubernetes, Terraform su AWS, GCP o Azure). Nella generazione attuale del ruolo si aggiunge un blocco specifico di AI generativa: architetture RAG, database vettoriali, pipeline di valutazione dei modelli, gestione di agenti. I requisiti dichiarati dalle aziende che assumono confermano la soglia più che la definiscono: Accenture chiede almeno tre anni in data engineering, OpenAI almeno cinque anni di esperienza complessiva su sviluppo o deployment tecnico, Scale AI arriva a richiedere dieci anni per i ruoli di livello Staff.

Il fattore differenziante sta nella velocità con cui qualcuno si muove in uno stack che non conosce, più che nella profondità raggiunta in un singolo stack. Secondo i materiali di Kanekar, che non costituiscono una fonte ufficiale di Palantir, è quello che misura il round di apprendimento: si consegna al candidato la documentazione di un’API o di una libreria mai incontrata prima e gli si chiede di risolvere un problema pratico entro un’ora. Lo stesso principio vale sul campo. Un FDE che entra in un’azienda cliente eredita l’ERP che quell’azienda ha, non quello che conosce meglio, e la parte di competenza tecnica che conta davvero è la capacità di leggere un sistema estraneo e trovarne i punti di leva senza settimane di rampa.

Le certificazioni entrano qui come segnale, non come requisito assoluto. Nel percorso verso il ruolo compaiono con maggiore frequenza le certificazioni AWS, dal Cloud Practitioner base fino alle certificazioni professional su architettura e AI generativa, e nei contesti legati a Palantir le certificazioni specifiche su Foundry, Gotham o AIP. Danno un segnale di operatività immediata su una piattaforma, ma nessuna fonte raccolta le tratta come sostituto dell’esperienza.

2. Dominio e processo

La soglia minima è saper condurre una discovery, cioè estrarre da conversazioni con persone che non parlano il linguaggio tecnico un modello sufficientemente preciso del processo aziendale da poterlo tradurre in software. Un curriculum non la certifica, ed è per questo che i colloqui includono round di decomposizione invece di semplici prove di algoritmi.

Il fattore differenziante è riconoscere quale vincolo, tra i molti che un cliente elenca, è reale e quale è rumore organizzativo. Un FDE ascolta un problema di business espresso in termini generici e imprecisi, e deve scartare i requisiti superflui per arrivare al nucleo che conta davvero. È la stessa competenza che la sezione precedente ha descritto come costruzione del livello di grounding: qui viene guardata dal lato della persona che la esercita, non dell’oggetto che produce. Un FDE che si limita a raccogliere tutto quello che il cliente dice produce un sistema fedele ai desideri e inutilizzabile nella pratica: che un tirocinante non possa approvare pagamenti è un vincolo operativo reale, che il pulsante debba avere un certo colore è quasi sempre rumore.

3. Comunicazione e traduzione

La soglia minima è spiegare una scelta tecnica a chi tecnico non è, e farlo abbastanza bene da ottenere una decisione, non solo comprensione. Il livello di autonomia con cui un FDE opera è spesso paragonato a quello di un CTO di startup alle prime armi: nessuno stabilisce le priorità al posto suo, quindi deve saperle proporre e difenderle davanti a chi controlla il budget.

Il fattore differenziante emerge anche da una guida pubblicata da AI Codex e attribuita dal sito a un «AI Agent». La guida propone quattro competenze che si sovrappongono parzialmente ai cinque assi di questo articolo: profondità tecnica, acume imprenditoriale, comunicazione sotto pressione e capacità di iniziativa in condizioni di ambiguità. Fra queste isola la comunicazione sotto pressione come elemento distintivo9Fonte 9fonte secondaria×AI Codex, «How to become a Forward Deployed Engineer — the path nobody has written down yet», guida online alla transizione verso il ruolo. La pagina attribuisce il contenuto a un «AI Agent» e il sito dichiara «Built with Claude». Propone uno stack di quattro competenze, ma non indica un autore umano né espone un metodo.apri la fonteultima verifica il 31 luglio 2026.

Chi arriva a questo mestiere parte da due direzioni opposte, e lo squilibrio da colmare è speculare. Chi viene da ruoli rivolti al cliente, Solutions Architect, Customer Engineer, pre-sales, possiede già le doti relazionali e deve acquisire la profondità ingegneristica per scrivere codice destinato a restare in produzione, non solo prototipi di vendita. Chi viene da ruoli puramente tecnici, backend engineer, data engineer, data scientist, padroneggia il codice ma è abituato a lavorare con requisiti già definiti da un product manager, e deve imparare a condurre workshop di discovery e a tollerare l’ambiguità che nei ruoli precedenti qualcun altro assorbiva per lui. Nessuno dei due punti di partenza è più legittimo dell’altro: la convergenza tra le due direzioni è il ruolo stesso.

4. Governance e compliance

La soglia minima riguarda i meccanismi tecnici di controllo: single sign-on, SAML, OAuth, policy IAM, e la capacità di lavorare dentro reti segregate o air-gapped quando il cliente lo richiede, condizione comune nei contesti regolati o nella pubblica amministrazione.

Il fattore differenziante è tradurre un requisito normativo, spesso scritto in un linguaggio che non è pensato per essere eseguito da un sistema, in un vincolo implementabile. È la dimensione che la sezione precedente ha indicato come una delle due più deboli nell’automazione attuale, insieme alla manutenzione, e non è un caso: un validatore automatico sa verificare che una regola sia ben formata, non sa stabilire se sia la regola giusta per quel cliente in quel momento normativo. Su questo punto la sezione 11 tornerà nel dettaglio, applicato al momento in cui l’FDE lascia il cliente e il sistema deve continuare a rispettare quei vincoli senza di lui.

5. Business e valutazione economica

La soglia minima è capire il modello di business del cliente abbastanza da distinguere un intervento che genera valore misurabile da uno che produce solo attività. Il fattore differenziante è saper riconoscere quando fermarsi. Le organizzazioni che gestiscono il modello FDE con disciplina lo fanno perché temono una deriva specifica, la personalizzazione infinita: se ogni richiesta del cliente diventa codice su misura, il lavoro smette di essere scalabile e diventa consulenza a basso margine con un nome diverso. Un FDE che vale la propria retribuzione sa quando una richiesta va soddisfatta con un intervento locale e quando invece segnala un bisogno più ampio da riportare indietro come funzionalità di prodotto, la stessa logica di feedback che la sezione due ha ricostruito nei documenti societari di Palantir, dove il tempo passato sul campo torna dentro il prodotto.

La competenza che nessuna fonte editoriale nomina

C’è un sesto elemento che non appartiene a nessuno dei cinque assi e li attraversa tutti, ed è l’unico che compare in una fonte accademica e in nessun’altra delle fonti sulle competenze raccolte per questo articolo. La rassegna di Bai e colleghi, citata nella sezione precedente, lo chiama non generazione, e lo tratta come un requisito di prestazione al pari dell’accuratezza10Fonte 10fonte secondaria×AOGC significa Automated Operational Grounding Construction: l'uso di modelli linguistici per costruire, validare o mantenere gli artefatti strutturati che collegano entità, vincoli, azioni, governance e aggiornamenti al comportamento di un agente. Jiaxin Bai, Lihui Liu, Yisen Gao, Zihao Wang, Yangqiu Song, «Scaling Enterprise Agent Deployment: A Survey of LLM-Based Operational Grounding Construction». Hong Kong Baptist University, Wayne State University, TSY Capital, HKUST. Perimetro dichiarato: lavori pubblicati o pubblicamente disponibili da gennaio 2022 al 21 maggio 2026, trentadue metodi principali codificati. Preprint senza sede di pubblicazione dichiarata, senza arXiv e senza DOI: circola su ResearchGate e non è passato per revisione paritaria.apri la fonteultima verifica il 29 luglio 2026:

«Per AOGC, l’incertezza è un risultato di prima classe: un sistema che segnala soglie di approvazione contraddittorie e chiede una risoluzione è più implementabile di uno che emette una regola sicura ma non supportata.»

Tradotto fuori dal linguaggio dei sistemi automatici, è la capacità di riconoscere quando due fonti si contraddicono, o quando nessuna fonte autorizza la regola che il cliente sta chiedendo di implementare, e di fermarsi a chiedere piuttosto che consegnare qualcosa di plausibile. Nessuna guida al colloquio, nessun elenco di hard skill, nessuna descrizione di annuncio di lavoro tra quelle raccolte per questo articolo la nomina esplicitamente. Eppure è la stessa capacità che, con parole diverse, ricorre in ogni fonte sulle competenze comportamentali del ruolo: nei materiali sulla selezione degli FDE di Anjor Kanekar7Fonte 7fonte primaria×Anjor Kanekar, «FDE Advisory Materials». L'autore dichiara sette anni in Palantir come forward deployed engineer e hiring manager e «1000+ technical interviews conducted and calibrated». Le schede di valutazione nominano i round «Learning & Reengineering» e «Decomposition», con i rispettivi criteri. Due avvertenze: il conteggio dei colloqui è un'autodichiarazione professionale, non un dato pubblicato da Palantir né verificato da terzi; e i materiali sono pubblicati da Platypus Technologies, che dichiara di aiutare le aziende «to build and run Forward Deployed Engineering functions», quindi vende consulenza sull'oggetto di cui parla.apri la fonteultima verifica il 31 luglio 2026, che dichiara sette anni alla guida di questi team in Palantir e oltre mille colloqui condotti o calibrati, l’insistenza è sulla capacità di ammettere un limite invece di improvvisare una risposta. Fra i segnali negativi elencati nelle sue schede c’è il candidato che non porta esempi di lavoro in condizioni di ambiguità e quello che non ha mai obiettato a un committente. È la linea che separa un FDE che l’organizzazione cliente ricorderà come affidabile da uno che ha consegnato qualcosa di plausibile e se n’è andato prima che il problema emergesse.

---

6. Che cosa costruisce dentro l’organizzazione

Gli annunci di lavoro descrivono la posizione, non il prodotto del lavoro. OpenAI scrive che un Forward Deployed Engineer «lead complex end-to-end deployments of frontier models in production alongside our most strategic customers» e che possiede «discovery, technical scoping, system design, build, and production rollout». È il perimetro di un incarico, e dice dove si trova la persona e di cosa risponde. Non dice che cosa lascia dietro di sé.

La descrizione più precisa di quel lavoro arriva da un posto inatteso: un gruppo di ricercatori che sta cercando di automatizzarlo. Una rassegna della letteratura firmata da Jiaxin Bai, Lihui Liu, Yisen Gao, Zihao Wang e Yangqiu Song, tra Hong Kong Baptist University, Wayne State University, HKUST e TSY Capital, studia il collo di bottiglia del deployment degli agenti aziendali, e per poterlo attaccare ha dovuto definirlo con esattezza:

Gli autori chiamano quel livello operational grounding layer, il livello di grounding operativo. È la lente con cui questo articolo interpreta una parte centrale del lavoro forward deployed, e conviene dichiararne subito il limite: la rassegna definisce un problema di deployment degli agenti e include anche i team di piattaforma interni, quindi non dimostra che ogni posizione con questo titolo produca tutti e cinque gli artefatti. Che sia una lente utile lo si giudica da quanto rende leggibili gli annunci e i casi reali, cosa che le sezioni successive mettono alla prova.

Perché serve un umano

L’esempio usato dalla rassegna è assicurativo, e funziona bene perché nessuna delle cose che elenca è un problema di intelligenza del modello. Un agente che gestisce sinistri deve sapere che cosa significano sinistro, polizza e perito, ma quella è la parte facile. Deve anche sapere che un sinistro ha un richiedente e un incidente, che le richieste presentate esigono documentazione, che quelle di valore elevato passano da una revisione esperta, che i tirocinanti non possono approvare pagamenti, e che una modifica normativa può cambiare i requisiti documentali dopo che il sistema è già in produzione.

Nessuna di queste informazioni sta scritta in un posto solo. La rassegna elenca dove si trovano nella pratica: schemi di database, specifiche API, motori di workflow, tabelle di controllo degli accessi, manuali di policy, fogli di calcolo, documentazione legacy. Alcune non stanno scritte da nessuna parte e vivono nella testa di chi lavora lì da quindici anni.

Ricomporre quel materiale disperso in una struttura che un agente possa usare è il lavoro. Il resto dell’incarico, le riunioni di scoping, la scelta dello stack, il rollout, esiste per rendere possibile questa ricomposizione.

Le cinque dimensioni

La rassegna formalizza il livello di grounding come una struttura a cinque componenti, indicata come O = ⟨V, C, A, G, M⟩. Tradotta in termini aziendali:

	Componente	Che cosa contiene	Dove si trova già in azienda
V	Vocabolario	Classi, attributi, relazioni, identificatori	Schemi DB, oggetti CRM, tipi API
C	Vincoli	Stati validi, derivazioni, controlli di violazione	Vincoli SQL, JSON Schema, regole di business
A	Azioni	Operazioni richiamabili, parametri, precondizioni, effetti, modalità di errore	OpenAPI, schemi di strumenti, workflow, macchine a stati
G	Governance	Autorizzazioni, divieti, obblighi, ruoli, regole di audit	RBAC/ABAC, policy di conservazione, flussi di conformità
M	Manutenzione	Provenienza, versioni, deprecazioni, migrazioni, test di regressione	Migrazioni di schema, versioni API, GitOps

La colonna di destra è la ragione per cui questo lavoro non si fa da fuori. Ognuna di quelle cose esiste già nell’azienda, in forma parziale, sparsa e spesso contraddittoria. Chi arriva con un modello da installare deve prima trovarle, poi capire quale versione è quella vera, poi collegarle tra loro.

Il punto difficile è il collegamento

Gli autori insistono su una distinzione che chiarisce perché il mestiere non si riduce a estrarre informazioni:

«Il problema difficile non è trovare termini o relazioni candidati, ma produrre artefatti collegati che un agente, pianificatore, validatore o motore politico possa utilizzare direttamente.»

Le conseguenze pratiche di un collegamento sbagliato sono concrete, e la rassegna le elenca: una regola di policy generata è insicura se rimanda a un ruolo che non esiste nel vocabolario; una specifica API è incompleta se l’agente non può stabilire quando la chiamata sia lecita; una migrazione è rischiosa se aggiorna una regola lasciando in piedi i test di validazione vecchi.

Chi lavora in aziende medie riconosce la situazione senza bisogno del formalismo. Il campo che il gestionale chiama in un modo e il CRM in un altro, la deroga concessa nel 2019 che nessuno ha mai scritto, il permesso che sulla carta ha il responsabile e nei fatti ha la sua assistente. Il livello di grounding è la somma di queste cose messa in forma leggibile da una macchina.

Palantir aveva già un nome per questa cosa

La formalizzazione accademica è del 2026, l’oggetto no. La documentazione di Palantir Foundry descrive il proprio livello centrale in termini che si sovrappongono quasi parola per parola:

Gli elementi semantici corrispondono al vocabolario e ai vincoli, quelli cinetici alle azioni, la sicurezza dinamica alla governance. Palantir ha commercializzato la struttura che la letteratura ha definito dieci anni dopo, e il Forward Deployed Engineer è la figura che l’azienda ha inventato per costruirla dentro il cliente. Non è una coincidenza terminologica: è la stessa idea, arrivata prima dal lato commerciale e poi da quello accademico.

Questo chiarisce anche perché il ruolo nasce lì e non altrove. Un prodotto che si vende come livello operativo dell’organizzazione richiede qualcuno che vada a costruire quel livello sull’organizzazione specifica, perché il livello non esiste finché qualcuno non lo scrive.

Lo stesso lavoro, due mestieri

Il livello di grounding va costruito in ogni caso, e chi lo costruisce prende nomi diversi a seconda di dove punta.

TrueLayer, fintech dei pagamenti con sedi a Londra, Milano e Dublino, cerca a Milano un Senior Agentic Enablement Engineer12Fonte 12fonte primaria×Annuncio ufficiale TrueLayer per «Senior Agentic Enablement Engineer» a Milano. L'annuncio descrive le sedi di Londra, Milano e Dublino, le responsabilità del ruolo, la retribuzione di 85.000-110.000 euro lordi annui più equity e il CCNL commercio.apri la fonteultima verifica il 31 luglio 2026. Le mansioni elencate nell’annuncio ricalcano le cinque dimensioni una per una: mappe di sistema e convenzioni estratte dalla conoscenza tacita degli ingegneri, server MCP che danno agli agenti accesso ai sistemi interni, una libreria di strumenti versionata e testabile, un impianto di valutazione con suite di regressione, e regole di sorveglianza con checkpoint umani e permessi a privilegio minimo. La motivazione della parte di governance è esplicita: «in a regulated payments environment, ungoverned agent access to production systems is a liability».

Non ci sono clienti in questa posizione. Il lavoro punta verso l’interno, verso l’organizzazione di ingegneria dell’azienda stessa. Ma l’oggetto costruito è il medesimo, al punto che l’annuncio usa la stessa espressione che si trova nella letteratura di settore per il problema di partenza, tribal knowledge: «every piece of tribal knowledge locked in a Slack thread or an engineer’s head is an opportunity to unlock».

Un annuncio singolo non è una tendenza, e va preso per quello che è: un caso documentato che apre una domanda. La domanda è se la competenza che il mercato sta prezzando come Forward Deployed Engineer non sia in realtà una competenza sul livello di grounding, che assume il nome del contesto in cui viene esercitata. Verso il cliente diventa un ruolo di delivery. Verso la propria azienda diventa platform engineering. Nelle organizzazioni medie, come vedremo più avanti, non prende alcun nome e resta attaccata alla persona che per caso la possiede.

---

7. Si può automatizzare questo mestiere?

Se il lavoro consiste nel costruire il livello di grounding, allora la domanda sulla durata del ruolo diventa precisa e verificabile: quella costruzione si può automatizzare?

Su questa domanda esistono due risposte pubbliche, opposte, e con uno status molto diverso. Vale la pena esaminarle nell’ordine, perché la differenza tra le due è essa stessa il risultato più interessante.

La risposta di chi vende l’automazione

Un documento di Stephane H. Maes, datato 19 febbraio 2026, presenta il motore Real-Time Discovery and Self-Coding, RTDC, della piattaforma Zenera. L’abstract contiene questa frase:

Nell’introduzione l’affermazione viene riferita esplicitamente al modello Palantir: «alcune aziende, come Palantir, e iniziative come IFS Nexus Black si basano su team ad alta intensità di lavoro umano composti da forward deployed engineer per implementare l’AI aziendale». Con RTDC, sostiene il documento, gran parte di quel lavoro passa ad agenti che eseguono la scoperta degli schemi e la scrittura autonoma del codice di integrazione.

L’argomento è costruito su una diagnosi che merita attenzione a prescindere dalla soluzione proposta. Il documento la chiama Stitching Trap, la trappola del collegamento: i team scrivono a mano wrapper API per connettere modelli probabilistici a sistemi legacy deterministici, e questo lavoro si deteriora per tre motivi. Le API pulite nei sistemi legacy non esistono, quindi costruirle richiede reverse engineering su cicli lunghi. Gli schemi degli ERP personalizzati sono opachi, e chi implementa l’AI raramente conosce il contesto. E ogni aggiornamento del fornitore rompe l’integrazione, trasformando gli ingegneri in manutentori a tempo pieno.

Chiunque abbia integrato sistemi aziendali riconosce la descrizione. Sulla soluzione, però, servono tre precisazioni.

Che documento è. Non è un lavoro sottoposto a revisione paritaria. L’autore descrive e raccomanda il prodotto di un’azienda specifica, e dei ventisei riferimenti citati tredici sono suoi, pubblicati sul proprio blog, su Zenodo, su OSF e in due casi su viXra, archivio senza revisione. Il riferimento che sostiene le affermazioni tecniche centrali è una sua domanda di brevetto. Il testo dichiara inoltre di essere parziale: «parte degli elementi proprietari e delle informazioni riservate è stata rimossa», e la versione completa è disponibile «con le credenziali appropriate» sul sito dell’azienda. Nulla di tutto questo rende il documento privo di valore, ed è la formulazione più esplicita e argomentata della tesi della sostituibilità che sia disponibile. Ma la sua forza probatoria è quella di una posizione commerciale argomentata.

L’affermazione tecnica più forte non è misurata. Il documento sostiene ripetutamente un’accuratezza «del 100%» o «prossima al 100%» grazie al modello dei vincoli. Non accompagna quel numero con alcun benchmark, protocollo di valutazione o misurazione.

Il documento si indebolisce da solo. La tesi compare tre volte in tre formulazioni che non coincidono. Abstract e conclusioni parlano di team «in larga misura sostituiti»; il corpo del testo dice qualcosa di più circoscritto, e cioè che si sostituisce «gran parte del lavoro di questi team». Quando poi il documento descrive un’implementazione reale, gli esseri umani restano: una nota riporta che il lavoro sarebbe stato consegnabile in poche settimane «con meno di una manciata di developer manager, impegnati soprattutto a gestire il ciclo di vita della piattaforma». Due sezioni sono dedicate al perfezionamento con umano nel ciclo e alla correzione esperta dei percorsi di ragionamento.

Anche accettando per buone tutte le affermazioni del fornitore, quindi, la tesi che ne risulta è che la squadra si comprime e il lavoro cambia natura, passando dalla costruzione manuale delle integrazioni al governo del ciclo di vita di una piattaforma che le costruisce. È una tesi diversa e più moderata di quella dell’abstract.

La risposta di chi ha cercato l’automazione senza venderla

Prima di riportarla, la stessa cautela applicata sopra vale anche qui: al momento in cui scrivo la rassegna di Bai e colleghi circola come preprint e non dichiara una sede di pubblicazione. Nessuno dei due documenti è passato per una revisione paritaria. A distinguerli sono altre due cose: l’assenza di un prodotto da vendere, e la presenza di criteri di inclusione dichiarati su un perimetro verificabile.

Quella rassegna ha esaminato la letteratura pubblicata o pubblicamente disponibile da gennaio 2022 al 21 maggio 2026, codificando trentadue metodi principali di costruzione basati su LLM. Li classifica per quanta autonomia viene delegata al modello:

Livello	Ruolo del modello	Ruolo umano	Stato
1. Strumento per sottoattività	Esegue una fase predefinita di estrazione, traduzione o validazione	Sceglie gli input, integra e accetta l’output	Maturo
2. Motore di pipeline	Esegue un flusso di costruzione e controllo fisso in più fasi	Definisce l’ambito, accetta o rifiuta le bozze	Frontiera attuale
3. Agente di costruzione	Pianifica, valida, revisiona e mantiene autonomamente il livello collegato	Nessuno stabilito	Non trovato

Sul terzo livello la rassegna è netta:

Quello che il documento Zenera dichiara di fare corrisponde alla definizione di terzo livello.

Come si tiene insieme questa contraddizione

Con precisione, e senza forzare. Zenera è un prodotto commerciale e non un metodo pubblicato in letteratura, quindi non rientra nel perimetro di codifica della rassegna. Gli autori dichiarano esplicitamente tra i limiti che «alcuni sistemi di settore e implementazioni recenti potrebbero non essere completamente visibili nella letteratura pubblica». La rassegna, formalmente, non smentisce Zenera.

Quello che si può affermare è più modesto e più solido: la sola evidenza pubblica dell’esistenza di una capacità di terzo livello è prodotta da chi quella capacità la vende, mentre la ricerca indipendente che l’ha cercata in modo sistematico, con criteri dichiarati e fino a tre mesi dopo la pubblicazione di quel documento, non l’ha trovata da nessuna parte. Su una questione che decide se un mestiere sopravvive, questa asimmetria nelle prove è essa stessa il risultato.

Perché il divario resiste

La rassegna dedica una sezione alle cause, e sono strutturali più che contingenti. Le comunità di ricerca coinvolte sono frammentate tra ingegneria ontologica, elaborazione del linguaggio, pianificazione, ingegneria del software, gestione dei processi e AI legale. I benchmark puliti con riferimenti dati sono più facili da pubblicare delle valutazioni disordinate. Le metriche accademiche premiano la somiglianza a un riferimento, mentre il successo aziendale si misura sul fatto che un agente compia azioni valide, consentite e verificabili.

La causa più interessante per chi lavora in azienda è la terza: la documentazione aziendale è proprietaria, e questo spinge i ricercatori verso materiali pubblici che non presentano le caratteristiche difficili. Il corollario è che il materiale su cui lavora un Forward Deployed Engineer, per come è fatto, non entra nei dataset su cui vengono addestrati e valutati i sistemi che dovrebbero sostituirlo. Non è una barriera tecnologica e non si supera con modelli migliori.

Dove l’automazione avanza e dove incontra ancora limiti

L’analisi delle lacune contenuta nella rassegna è la parte con le implicazioni più dirette. L’estrazione di entità e relazioni, la prima dimensione, è la più matura, ma con un limite che gli autori formulano bene: i metodi attuali estraggono «ciò che è saliente, non ciò che un agente deve distinguere per agire correttamente». Un sistema può quindi riconoscere persone, documenti, prodotti e collegamenti senza identificare le differenze che determinano se un’azione sia consentita. Restano fuori proprio ruoli, periodi fiscali, code di lavorazione, stati di eccezione ed entità di controllo: informazioni che possono sembrare secondarie nella descrizione di un processo, ma diventano decisive quando il sistema deve agire.

La costruzione dei vincoli migliora ma resta frammentata. I metodi disponibili riescono a rappresentare singole regole, mentre faticano a ricomporre regole disperse tra procedure, configurazioni e conoscenza tacita, soprattutto quando esistono eccezioni, precedenze o fonti in conflitto. La specificazione delle azioni è indicata come il divario critico di integrazione. Riconoscere che nel sistema esistono un ordine, una fattura e un’approvazione non basta: occorre stabilire quali operazioni siano disponibili, chi possa eseguirle, in quale sequenza e a quali condizioni.

Le due dimensioni più deboli sono la governance e la manutenzione. I sistemi di conformità, scrivono gli autori, producono rapporti di qualità o di scostamento «piuttosto che livelli di governance applicabili». In termini concreti, possono segnalare che una regola è stata violata, ma questo non equivale a impedire l’azione, richiedere un’autorizzazione o attribuire la responsabilità della decisione. La manutenzione presenta un problema diverso: un grounding corretto oggi può diventare errato quando cambiano un’API, una procedura, un ruolo aziendale o una norma. Mantenerlo significa accorgersi del cambiamento, stabilire quali artefatti ne siano interessati e aggiornarli senza introdurre nuove incoerenze. È una capacità che i sistemi esaminati non dimostrano di possedere in modo autonomo e affidabile.

Vale la pena fermarsi su questo punto, perché rovescia l’intuizione comune. L’automazione della costruzione del grounding è più avanzata dove le conseguenze di un errore sono contenute, e più arretrata dove sono gravi. Questo non significa che un errore nell’estrazione di entità sia innocuo. Significa che le capacità più mature lavorano su artefatti circoscritti, per i quali è possibile costruire verifiche relativamente stabili; governance e manutenzione richiedono invece di interpretare responsabilità, eccezioni e cambiamenti che appartengono all’organizzazione prima ancora che al sistema tecnico.

Governance e manutenzione sono esattamente le due aree su cui il regolamento europeo, per i sistemi ad alto rischio, carica obblighi in capo al deployer, cioè all’azienda che il sistema lo usa. È l’impresa a dover organizzare la supervisione umana, controllare il funzionamento e reagire quando il sistema o il contesto cambiano. Chi conta di automatizzare la parte di handover e di sorveglianza sta contando sulla porzione meno matura della tecnologia.

Il confine che le macchine non attraversano

C’è un limite tecnico che la rassegna documenta con chiarezza, e che spiega meglio di qualunque elenco di competenze che cosa resti umano in questo mestiere. I sistemi del secondo livello funzionano perché accoppiano la generazione a controllori non neurali: parser, ragionatori, validatori SHACL o ShEx, pianificatori, verifiche di solidità dei modelli di processo. Quei controllori però hanno una portata limitata:

Gli strumenti automatici sanno verificare che una regola sia ben formata. Non sanno stabilire se sia la regola giusta. Distinguere le due cose richiede di conoscere il dominio del cliente, ed è il nucleo non automatizzato del mestiere.

Da qui discende una competenza che nessun elenco di requisiti nomina mai e che la rassegna indica come mancante nei sistemi attuali:

«Nelle distribuzioni, la risposta corretta potrebbe essere che due fonti non sono d’accordo o che nessuna fonte concede in licenza una regola richiesta. I sistemi AOGC dovrebbero essere valutati non solo sull’accuratezza della generazione ma anche sulla non generazione: astenersi, chiedere chiarimenti, isolare passaggi contrastanti o produrre un artefatto parziale con presupposti espliciti irrisolti.»

Sapere quando non produrre una risposta, e chiedere invece un chiarimento a un essere umano, è la capacità che separa un sistema utilizzabile da uno pericoloso. È anche, con una simmetria che non sfuggirà a chi ha lavorato con dei consulenti, la capacità che separa un buon Forward Deployed Engineer da uno che consegna qualcosa di plausibile e se ne va.

C’è un corollario che riguarda il modo in cui questo mestiere si esercita oggi, e che merita di essere detto perché tocca uno strumento che quasi tutti usano. Kasthuri lo mette al centro del suo intervento: la generazione di codice guidata dal linguaggio naturale accelera la prima parte del lavoro, cioè abbozzare integrazioni, produrre impalcature e creare banchi di prova, e su quella parte è genuinamente utile. Quello che non porta con sé è la disciplina che rende il risultato consegnabile. «An enterprise agent cannot rely on generated code that nobody has reviewed, tested or secured», scrive, e il seguito è un elenco di cose che restano manuali: revisione, test unitari e di integrazione, controlli di sicurezza, validazione rispetto alle politiche aziendali, monitoraggio in esercizio.

La conseguenza per chi valuta il mestiere è che la velocità di generazione non erode la competenza che conta. La sposta: meno tempo a scrivere, più tempo a verificare che quello che è stato scritto sia difendibile davanti a chi risponde del sistema.

La ricerca che non si occupa di questo mestiere

Fino a qui la domanda è stata affrontata attraverso le poche fonti disponibili che nominano esplicitamente il forward deployed engineer. Sono pertinenti, perché affrontano direttamente la possibilità di automatizzare quel lavoro, ma non bastano, da sole, a sostenere una tesi sulla durata del mestiere.

Per allargare la base delle prove bisogna smettere di cercare il titolo professionale e guardare alle attività che lo compongono: estrazione e ricomposizione della conoscenza, uso degli strumenti, modellazione dei processi, verifica, governance e monitoraggio. Su queste attività esiste una letteratura più ampia che il ruolo non lo nomina mai, e che proprio per questo pesa di più. Chi la scrive non ha una posizione da difendere sul destino degli FDE, perché non si sta occupando di loro. Quando converge lo stesso, la convergenza non è costruita.

Il solo risultato con revisione paritaria dice che le professioni si ricompongono invece di sparire. Uno studio pubblicato su Humanities and Social Sciences Communications nel maggio 202614Fonte 14fonte primaria×Soohyoung Lee, Dawoon Jeong, Jeong-Dong Lee, «Contrasting pathways of automation: routine task substitution vs. AI complementarity», Humanities and Social Sciences Communications, 5 maggio 2026, DOI 10.1057/s41599-026-07415-5. L'unica fonte sottoposta a revisione paritaria fra quelle raccolte su questo punto. Simula la rimozione di 332 compiti su 736 professioni del database O*NET. Limite dichiarato dagli autori stessi: «the model is not designed to forecast labour market outcomes or to conduct counterfactual tests». È un modello di simulazione su una banca dati di compiti, non una misurazione di esiti occupazionali osservati.apri la fonteultima verifica il 31 luglio 2026 modella l’automazione come erosione sequenziale di compiti e simula la rimozione di 332 attività su 736 professioni della banca dati O*NET. La conclusione è che, nonostante l’erosione, la maggior parte delle professioni conserva competenze residue che permettono l’adattamento invece dell’estinzione, e che l’automazione cognitiva crea ponti fra domini eterogenei. Va però letto per quello che è: un modello di simulazione su una banca dati di compiti, non una misurazione di quello che è successo davvero ai lavoratori. Gli autori lo scrivono da sé, e la loro cautela merita di essere riportata invece che smussata.

I banchi di prova dicono dove cade il confine. DeskCraft valuta diciotto agenti su 538 compiti professionali: il migliore si ferma al 31,6%, e scende al 27,6% quando il compito richiede di interagire15Fonte 15fonte primaria×Wenkai Wang e altri, «DeskCraft: Benchmarking Desktop Agents on Professional Workflows and Human-in-the-Loop Collaboration», arXiv 2606.03103, 2 giugno 2026. Diciotto agenti valutati su 538 compiti professionali. Il migliore, GPT-5.4, raggiunge il 31,6% sui compiti standard e il 27,6% su quelli interattivi. Preprint non sottoposto a revisione paritaria.apri la fonteultima verifica il 31 luglio 2026. Gli errori si concentrano nelle attività lunghe e nei casi in cui bisognerebbe fermarsi a chiedere un chiarimento. EnterpriseClawBench, costruito su sessioni di lavoro reali, si ferma a 0,663 nella configurazione migliore16Fonte 16fonte primaria×Jincheng Zhong e altri, «EnterpriseClawBench: Benchmarking Agents from Real Workplace Sessions», arXiv 2606.23654, 22 giugno 2026. Ottocentocinquantadue compiti ricavati da sessioni di lavoro reali; la configurazione migliore, Codex con GPT-5.5, ottiene 0,663. Limite rilevante: gli autori non pubblicano i dati del benchmark, perché proprietari, ma solo il protocollo di costruzione e valutazione. Il risultato non è quindi replicabile da terzi. Preprint.apri la fonteultima verifica il 31 luglio 2026, con l’avvertenza che i dati non sono pubblicati e il risultato non è quindi replicabile da terzi.

Il più eloquente dei tre è WorkSurface-Bench17Fonte 17fonte primaria×Hao Liang e altri, «WorkSurface-Bench: Benchmarking Enterprise Agents on Multi-Surface Knowledge Routing», arXiv 2607.25765, 28 luglio 2026. Millecentocinquantuno compiti atomici su documenti, tabelle e grafi. Gli agenti individuano la fonte giusta con una F1 di instradamento fra 98,7 e 99,8, mentre la qualità della risposta resta fra il 56,1% e il 75,3%. Preprint pubblicato tre giorni prima della consultazione: è la fonte più recente dell'articolo e anche la meno sedimentata.apri la fonteultima verifica il 31 luglio 2026, perché separa due cose che di solito vengono misurate insieme. Trovare la fonte giusta fra documenti, tabelle e grafi è ormai un problema risolto, con una F1 di instradamento fra 98,7 e 99,8. Rispondere bene una volta trovata resta fra il 56,1% e il 75,3%. Sapere dove guardare e sapere che farsene sono due capacità distinte, e solo la prima è stata automatizzata.

Sulla modellazione dei processi il confine cade nello stesso punto. La ricerca sulla generazione automatica di modelli di processo da descrizioni testuali18Fonte 18fonte primaria×Xiaoxuan Li e altri, «LLM-based Business Process Models Generation from Textual Descriptions», in Findings of IJCNLP-AACL 2025, dicembre 2025. Sottoposto a revisione paritaria. Valuta cinque approcci di generazione di modelli di processo da descrizioni testuali e la loro tenuta con input incompleti.apri la fonteultima verifica il 31 luglio 2026 mostra che i modelli linguistici producono strutture plausibili. Un framework di valutazione dedicato19Fonte 19fonte primaria×Chantale Lauer, Peter Pfeiffer, Alexander Rombach, Nijat Mehdiyev, «Assessing the Business Process Modeling Competences of Large Language Models», arXiv 2601.21787, 29 gennaio 2026, seconda versione 29 giugno 2026. Il framework BEF4LLM valuta i modelli su sintassi, pragmatica, semantica e validità: i modelli reggono il confronto sui primi due assi, gli esperti umani restano avanti sulla qualità semantica. Preprint.apri la fonteultima verifica il 31 luglio 2026 scompone però il giudizio su quattro assi e trova che i modelli reggono il confronto su sintassi e pragmatica, mentre gli esperti umani restano avanti sulla validità semantica. È esattamente la distinzione che la rassegna di Bai formulava per i validatori: una regola ben formata e la regola giusta sono cose diverse, e la seconda richiede di sapere come funziona quell’organizzazione. Due filoni di ricerca che non si citano a vicenda arrivano allo stesso confine partendo da problemi diversi.

L’economia cambia prima della qualità. Uno studio che confronta agenti e lavoratori umani su cinque ambiti professionali20Fonte 20fonte primaria×Zora Zhiruo Wang, Yijia Shao, Omar Shaikh, Daniel Fried, Graham Neubig, Diyi Yang, «How Do AI Agents Do Human Work? Comparing AI and Human Workflows Across Diverse Occupations», arXiv 2510.22780, 26 ottobre 2025. Gli agenti completano il lavoro l'88,3% più in fretta e a un costo inferiore fra il 90,4% e il 96,2%, ma con qualità inferiore, e gli autori rilevano che «often mask their deficiencies via data fabrication and misuse of advanced tools». Preprint.apri la fonteultima verifica il 31 luglio 2026 misura una qualità inferiore degli agenti, con uso improprio degli strumenti e fabbricazione di dati, e insieme tempi inferiori dell’88,3% e costi inferiori fra il 90,4% e il 96,2%. Il punto non riguarda la sostituzione. Riguarda il fatto che uno scarto di costo di quell’ordine sposta il modo di lavorare molto prima che la qualità diventi sufficiente a lavorare senza supervisione, e questo è il meccanismo per cui un mestiere può cambiare composizione mentre nessuno perde il posto.

Governance e monitoraggio non si risolvono generando codice. Il NIST ha pubblicato nel marzo 2026 un rapporto sugli ostacoli al monitoraggio dei sistemi di AI in esercizio21Fonte 21fonte primaria×NIST, «Challenges to the Monitoring of Deployed AI Systems», pubblicazione NIST AI 800-4, 9 marzo 2026. Documento di un ente pubblico di normazione, non un preprint: è la fonte istituzionalmente più solida fra quelle raccolte sul monitoraggio. Individua sei categorie di sorveglianza e, fra gli ostacoli trasversali, la registrazione frammentata nei sistemi distribuiti, l'assenza di linee guida affidabili e la difficoltà di scalare la sorveglianza umana durante adozioni rapide.apri la fonteultima verifica il 31 luglio 2026: registrazione frammentata nei sistemi distribuiti, deriva dei modelli, assenza di linee guida affidabili, difficoltà di scalare la sorveglianza umana quando l’adozione corre. È un documento di un ente pubblico di normazione, e su questo punto è la fonte più solida raccolta per l’articolo. Uno studio di caso sull’adozione di un sistema agentico dentro una grande società di servizi informatici22Fonte 22fonte primaria×Nelly Dux, Cristina Alaimo, Philippe Roussiere, Abhishek Kumar Mishra, «Governance by Design: Architecting Agentic AI for Organizational Learning and Scalable Autonomy», arXiv 2605.20210, 17 aprile 2026. Caso qualitativo sull'adozione graduale di un sistema agentico, nel 2025, presso «a large IT services company» che il paper non nomina. Conflitto di interesse da dichiarare: uno degli autori, Philippe Roussiere, è Global Lead for Innovation and AI di Accenture Research, cioè appartiene a una grande società di servizi informatici che vende esattamente il lavoro di governance e deployment di cui il paper argomenta il valore. Accenture compare inoltre nella sezione nove di questo articolo fra i datori di lavoro italiani. Preprint, caso singolo, azienda non nominata.apri la fonteultima verifica il 31 luglio 2026 mostra come la governance finisca incorporata nell’architettura e negli accordi di lavoro, cioè in decisioni su quali strumenti il sistema può usare e come viene gestita la memoria. Su quest’ultima fonte va detto che uno degli autori dirige la ricerca su innovazione e AI in Accenture, azienda che vende esattamente questo tipo di lavoro e che compare nella sezione nove fra i datori italiani. Il caso resta informativo, il conflitto va tenuto presente.

Niente di tutto questo è definitivo. Le misurazioni di METR sull’orizzonte temporale dei compiti portati a termine con affidabilità23Fonte 23fonte primaria×METR, «Measuring AI Ability to Complete Long Software Tasks», 19 marzo 2025. Stima un raddoppio dell'orizzonte temporale dei compiti portati a termine con affidabilità ogni sette mesi circa, su sei anni. Il titolo va letto per intero: i compiti misurati sono di software e di ragionamento ben specificato, non il lavoro organizzativo e relazionale di cui si occupa questa sezione. Gli autori segnalano da soli che parte del testo e delle figure è superata e che le stime dipendono dai compiti scelti e dagli esseri umani presi a riferimento.apri la fonteultima verifica il 31 luglio 2026 indicano un raddoppio ogni sette mesi circa su sei anni, il che vieta di trattare i limiti attuali come permanenti. Il titolo di quel lavoro però contiene una parola che va conservata: i compiti misurati sono software tasks, attività di programmazione e ragionamento ben specificato. Sono la parte del mestiere che questa sezione dà già per comprimibile, non quella che sostiene sia difficile.

Che cosa queste fonti non dicono

Vale la pena essere espliciti anche sul limite, perché è ampio. Nessuna delle fonti appena citate misura l’occupazione dei forward deployed engineer. Non dicono che ne servano meno per cliente, che gli incarichi si siano accorciati, che i team si siano ridotti o che le posizioni junior stiano sparendo. Non dicono nemmeno il contrario. I banchi di prova misurano capacità tecniche, lo studio peer-reviewed simula un meccanismo generale, il rapporto NIST descrive il lavoro che resta da fare: nessuno dei tre osserva questa professione.

Manca uno studio longitudinale sul mestiere, e finché manca ogni previsione sul numero di persone che lo eserciteranno resta una previsione. Sei delle dieci fonti raccolte qui sono inoltre preprint, una delle quali pubblicata tre giorni prima di questa consultazione. La letteratura tecnica del 2026 su questi temi è in larga parte ancora in quella forma, ed è una condizione che va dichiarata invece che aggirata scegliendo le fonti che suonano più autorevoli.

La risposta provvisoria

Alla domanda se il ruolo si possa automatizzare, lo stato delle prove al 31 luglio 2026 consente una risposta articolata e nessuna risposta netta.

Il lavoro non viene automatizzato in blocco. Viene eroso per attività successive, e le attività non cadono nello stesso ordine. L’estrazione di entità e relazioni, la traduzione di requisiti in vincoli locali, la prima stesura di un modello di processo e la produzione degli artefatti formali risultano già automatizzabili, e su questo fronte la frontiera avanza in fretta. Decidere quali artefatti servano, sciogliere le contraddizioni fra fonti, stabilire chi possa fare che cosa, governare il sistema in esercizio e rifarlo quando l’organizzazione cambia: qui i risultati peggiorano in modo consistente, in cinque filoni di ricerca indipendenti che non si citano a vicenda.

Il ruolo, quindi, cambia composizione. La quota di produzione manuale si riduce, mentre cresce il peso di specificazione, verifica, giudizio e responsabilità sul sistema. Più il costo di produrre software scende, più il collo di bottiglia si sposta verso il lavoro che rende quel software corretto per una specifica organizzazione, ed è in quello spostamento che il mestiere trova il proprio valore.

Che questa ricomposizione porti a più forward deployed engineer, a meno, o agli stessi con incarichi diversi, le fonti raccolte non lo dicono. Un’attività difficile da automatizzare può diventare più importante e insieme essere concentrata in meno persone: le due cose non si escludono, e chi sostiene il contrario sta vendendo una rassicurazione.

---

8. Che cosa succede dopo l’ingresso dei grandi

La sezione precedente guarda al ruolo dal lato della tecnologia. Questa lo guarda dal lato del mercato, e la domanda è la stessa: quanto dura.

Quattro annunci in due mesi

Tra maggio e luglio 2026 quattro tra le maggiori società di software occidentali hanno costruito un’iniziativa attorno a questa figura. I dati qui sotto vengono dai comunicati originali, non da chi li ha ripresi.

Data	Chi	Che cosa	Cifra dichiarata
4 maggio 2026	Anthropic24Fonte 24fonte primaria×Anthropic, annuncio dei propri servizi AI per le imprese. Il controllo alla fonte ha smentito la cifra che circolava sulla stampa: nell'annuncio non compare alcun importo.apri la fonteultima verifica il 28 luglio 2026	Società di servizi AI enterprise con Blackstone, Hellman & Friedman, Goldman Sachs, General Atlantic, Leonard Green, Apollo, GIC e Sequoia	nessuna nel comunicato
11 maggio 2026	OpenAI25Fonte 25fonte primaria×OpenAI, annuncio della propria deployment company. Il controllo alla fonte ha smentito la cifra che circolava sulla stampa: l'azienda dichiara oltre quattro miliardi di dollari, non dieci.apri la fonteultima verifica il 28 luglio 2026	OpenAI Deployment Company, 19 partner guidati da TPG con Advent, Bain Capital e Brookfield	oltre 4 miliardi di dollari
fine giugno 2026	AWS26Fonte 26fonte primaria×Amazon, annuncio dell'investimento di un miliardo di dollari in una organizzazione dedicata di forward deployed AI engineer. Fonte primaria: la sala stampa dell'azienda, non le testate che la riprendono.apri la fonteultima verifica il 28 luglio 2026	Organizzazione dedicata di Forward Deployed Engineering, «thousands of experts» presso i clienti	1 miliardo di dollari
2 luglio 2026	Microsoft27Fonte 27fonte primaria×Microsoft, annuncio di Frontier Company del 2 luglio 2026, con la cifra di circa 6.000 esperti in ruolo embedded. Fonte primaria: il blog ufficiale dell'azienda.apri la fonteultima verifica il 28 luglio 2026	Frontier Company, 6.000 esperti di settore e ingegneria	2,5 miliardi di dollari

Due precisazioni, perché su questi numeri circola parecchia imprecisione.

La prima riguarda le cifre. Le somme di 1,5 miliardi per Anthropic e 10 miliardi per OpenAI compaiono in diversi contenuti sul tema. Nessuna delle due trova riscontro nelle fonti primarie: il comunicato di Anthropic non contiene alcun importo, e OpenAI parla di «more than $4 billion of initial investment». Possono riferirsi a impegni successivi o a valori complessivi di partnership, ma così come circolano non sono verificabili.

La seconda riguarda il tempo. La finestra va dal 4 maggio al 2 luglio, quindi due mesi, e non le poche settimane che si leggono in giro.

C’è poi un punto che quasi nessuno rileva: quei quattro non sono tutti. Dalla rilevazione delle offerte descritta più avanti emergono anche Google, con una posizione Google Cloud pubblicata il 27 luglio 2026, e soprattutto Salesforce, che assume forward deployed engineer contemporaneamente a Milano, Monaco e Parigi, con doppio livello di seniority in ciascuna sede. I grandi che si stanno muovendo su questo ruolo sono almeno sei.

Si compra la squadra invece di assumerla

Il dato più eloquente dell’intera ondata sta in una riga del comunicato di OpenAI. Per avere forward deployed engineer operativi dal primo giorno, l’azienda ha comprato una società di consulenza: l’acquisizione di Tomoro le porta in casa «approximately 150 experienced Forward Deployed Engineers and Deployment Specialists».

Un’organizzazione che può assumere praticamente chiunque ha comprato una società intera per avere quelle persone. Il comunicato non dice perché, e le spiegazioni possibili non si equivalgono: scarsità di candidati sul mercato, velocità di ingresso, il portafoglio clienti che viene insieme alla squadra, o competenze organizzative che non si ricostruiscono assumendo uno alla volta. Quello che il fatto documenta è la fretta, non l’impossibilità di reclutare. Come vedremo tra poco, la stessa scelta la sta facendo, sull’altro lato del mondo, chi da questo ruolo si sentirebbe minacciato.

Il ruolo si sta industrializzando

L’ipotesi che una figura tanto contesa sia effimera si scontra con il modo in cui le organizzazioni la stanno incasellando. Tre casi indipendenti, tre paesi, tre strutture diverse.

OpenAI non ha un ruolo, ha una funzione. Alla data del 28 luglio 2026 il sito careers dell’azienda28Fonte 28fonte primaria×Pagina delle posizioni aperte di OpenAI, filtrata su «forward deployed», al 28 luglio 2026. Le posizioni vengono ritirate e la pagina cambia: il rilievo qui non è il singolo annuncio ma la struttura, cioè la presenza simultanea di verticali di dominio, di un livello manageriale e di una posizione di recruiting dedicata.apri la fonteultima verifica il 28 luglio 2026 espone posizioni forward deployed articolate per verticale di dominio, con annunci distinti per semiconduttori, scienze della vita e settore pubblico, oltre a un livello di piattaforma e a uno di ingegneria del progetto fisico. Sopra di esse c’è un Manager, Forward Deployed Engineering. Accanto, un Recruiter, Forward Deployed Engineering.

Wipro lo ha messo in una scala. L’azienda indiana assume sotto il titolo “FORWARD DEPLOYED ENGINEER L3”, dove L3 è un livello del proprio inquadramento tecnico interno.

Infosys lo ha messo in un’altra scala. L’annuncio “Palantir Forward Deployment Engineer” corrisponde internamente a Lead Consultant e a un ruolo di Domain Project Lead 1, con competenze richieste su Palantir Foundry, PySpark e data modeling. Le sedi sono negli Stati Uniti, non in India.

Un ruolo che si articola in specializzazioni settoriali, si dota di una linea gerarchica, apre una posizione di recruiting dedicata e viene assorbito nelle griglie di inquadramento di due multinazionali dei servizi si sta stabilizzando, non dissolvendo.

A margine c’è un indicatore secondario che punta nella stessa direzione. In meno di due anni è nato un intero mercato di preparazione al colloquio per questa figura: guide, corsi, simulazioni di intervista, servizi di ottimizzazione del curriculum per i sistemi di screening automatico. Nessuno di questi contenuti è una fonte, ma la loro esistenza dice qualcosa. Un mestiere sviluppa un’industria della preparazione quando smette di essere una casualità di percorso e diventa una destinazione che le persone perseguono deliberatamente.

Chi assume, e dove

Per capire dove stia andando il ruolo oltre i comunicati stampa, ho confrontato le offerte pubblicate su Indeed in sei paesi il 28 luglio 20261Fonte 1fonte primaria×Rilevazione propria condotta il 28 luglio 2026 sugli annunci Indeed in sei paesi, con classificazione manuale dei risultati perché la ricerca per parole chiave restituisce falsi positivi. Metodo, query e criteri sono esposti nella sezione otto. Limite accertato: il censimento su questa sola piattaforma, per l'Italia, ha visto tre datori di lavoro su dodici, e quasi tutti quelli mancati erano già online. Va letta insieme alla rilevazione LinkedIn del 30 luglio.non disponibile onlineultima verifica il 28 luglio 2026 e, per l’Italia, su LinkedIn il 30 luglio29Fonte 29fonte primaria×Seconda rilevazione propria, LinkedIn, 30 luglio 2026, ricerca «Forward Deployed Engineer» con località Italia. Dodici datori di lavoro distinti dopo la deduplicazione degli annunci ripetuti e promossi. Esclusi due intermediari (K2 Partnering Solutions, società di ricerca e selezione, e Jobgether, aggregatore) perché non è verificabile per chi cerchino: stesso criterio applicato altrove nell'articolo. Come per Indeed, restano fuori le assunzioni che non passano da un annuncio pubblico.non disponibile onlineultima verifica il 30 luglio 2026.

Questi dati descrivono chi assume e in quali contesti, non quanto sia grande la domanda. Indeed restituisce al massimo una decina di risultati per ricerca e richiede di escludere manualmente gli annunci non pertinenti. In Italia ha individuato tre datori di lavoro, mentre LinkedIn ne ha mostrati dodici; soltanto tre degli annunci aggiuntivi erano stati pubblicati dopo la prima rilevazione. La differenza dipende quindi soprattutto dalla copertura delle piattaforme.

I casi riportati di seguito vanno letti come esempi documentati e non come un censimento. I risultati cambiano con la query, la piattaforma e la data, e non comprendono le assunzioni che non passano da un annuncio pubblico.

Negli Stati Uniti la figura è già uscita dai laboratori di intelligenza artificiale. Tra chi assume compaiono Smartsheet, ShipBob, Rippling e IntegriChain: software gestionale, logistica, piattaforme per le risorse umane, applicativi verticali per il settore farmaceutico. Le retribuzioni dichiarate negli annunci vanno da 91.000 a 350.000 dollari sotto lo stesso titolo, il che dice che il mercato ha deciso di volere questa figura prima di aver deciso quanto vale. Le date di pubblicazione coprono da gennaio a fine luglio senza vuoti evidenti, il che dice che le posizioni hanno continuato a essere aperte lungo tutto il periodo. Non dice quante siano state chiuse con un’assunzione, che è la cosa che misurerebbe davvero la domanda.

In Germania il ruolo è sceso nel tessuto locale. Oltre a OpenAI, presente a Monaco da ottobre 2025, e alle multinazionali, assumono aziende tedesche di piccola e media dimensione: paretos a Heidelberg, 2pi IT Solutions a Colonia, Adago a Mannheim, Otherworldly a Berlino. È il controfattuale che serve al confronto con l’Italia, di cui si parla nella sezione seguente: dimostra che il passaggio della figura dal mondo enterprise a quello delle imprese medie è già avvenuto in un mercato europeo comparabile.

In Francia la novità è che una società di servizi informatici, Talan, ha creato la posizione in organico con contratto a tempo indeterminato.

L’India non subisce il modello: lo rilancia

Sul mercato indiano circola una lettura che vale la pena esaminare, perché è plausibile e risulta sbagliata.

La lettura è questa: il modello forward deployed minaccia l’industria indiana dei servizi informatici, perché sostituisce squadre numerose e remunerate poco con singoli ingegneri costosi e presenti fisicamente dal cliente. È il contrario del modello che ha costruito quel settore.

Guardando gli annunci si arriva a una seconda ipotesi, diversa. Wipro e Infosys stanno assorbendo la figura dentro le proprie griglie di inquadramento, come si è visto sopra, quindi la stanno metabolizzando invece di subirla.

Poi si guardano le dichiarazioni societarie, e cade anche questa.

Il 12 luglio 2026, presentando i risultati del primo trimestre dell’esercizio, l’amministratore delegato di Tata Consultancy Services K Krithivasan30Fonte 30fonte secondaria×Tata Consultancy Services, risultati del primo trimestre dell'esercizio 2027, presentati il 12 luglio 2026. La dichiarazione dell'amministratore delegato K Krithivasan sulla quota di organico da portare al modello forward deployed è ripresa dalla stampa economica: la pagina ufficiale risponde 403 al recupero automatico e non è stata letta direttamente.apri la fonteultima verifica il 28 luglio 2026 ha dichiarato l’obiettivo di portare tra l’1% e l’1,5% del proprio organico a operare come forward deployed engineer. Su 593.798 dipendenti a fine giugno, si tratta di una cifra compresa tra 5.900 e 8.900 persone. In parallelo l’azienda ha dichiarato di essere alla ricerca di acquisizioni nel campo dell’intelligenza artificiale.

Vale la pena mettere quel numero accanto agli altri.

Organizzazione	Persone dedicate al modello	Data della dichiarazione
TCS	fino a 8.900 (piano dichiarato)	luglio 2026
Microsoft Frontier Company	6.000	annuncio 2 luglio 2026
AWS	«thousands of experts»	annuncio giugno 2026
OpenAI	circa 150, acquisiti con Tomoro	annuncio 11 maggio 2026

Un confronto diretto fra queste cifre sarebbe però scorretto, e conviene disinnescarlo subito. TCS dichiara un obiettivo futuro ricavato da una quota del proprio organico; Microsoft annuncia un numero che aggrega esperti di settore e di ingegneria; OpenAI comunica persone che arrivano da un’acquisizione, sotto due titoli diversi. Sono unità di misura differenti e stati di realizzazione differenti, e metterle in classifica darebbe una precisione che nessuna delle tre possiede. Quello che indicano tutte e tre è l’ordine di grandezza dell’investimento organizzativo. A questa scala l’ipotesi dell’assorbimento difensivo non regge più. Si tratta di una contromossa sullo stesso terreno, alla dimensione maggiore tra quelle annunciate pubblicamente fino al 28 luglio 2026, e la stampa economica la inquadra come competizione diretta con OpenAI, Anthropic e Microsoft.

Come già anticipato nelle sezioni precedenti, a queste mosse se ne aggiunge una quarta, di natura diversa. Il 29 luglio 2026 CIO ha pubblicato un intervento di Magesh Kasthuri, principal consultant e distinguished member of technical staff in Wipro, che apre dichiarando il forward deployed engineering «one of the most important operating patterns for enterprise artificial intelligence».

Le prime tre mosse sono assunzioni, inquadramenti e un piano industriale annunciato agli investitori. Questa è un’altra cosa: è la rivendicazione di una paternità intellettuale sul modello, pubblicata su una testata che i responsabili dei sistemi informativi occidentali leggono per decidere a chi affidare i progetti. Un settore che temesse di essere disintermediato da questa figura non ne scriverebbe il manuale operativo per il proprio mercato di sbocco.

La contesa non è solo indiana

Mettere il piano TCS accanto agli annunci dei fornitori suggerisce un confronto tra il settore indiano dei servizi e i grandi laboratori. È una lettura incompleta, e a chiarirlo è un annuncio di lavoro.

Accenture, che indiana non è, cerca forward deployed engineer in Italia su due livelli di inquadramento e dichiara nel testo dell’annuncio di stare costruendo «the largest FDE capability in the services industry»31Fonte 31fonte primaria×Annunci Accenture Italia per Forward Deployed AI Engineer, livelli Specialist e Manager, Milano e Roma, pubblicati il 24 luglio 2026. Contengono la definizione per esclusione del ruolo, il criterio del trasferimento al cliente, l'esclusione esplicita dei falsi positivi e le fasce retributive dichiarate ai sensi della normativa sulla trasparenza.non disponibile onlineultima verifica il 30 luglio 2026. Non è una nota interna: è una rivendicazione scritta in una pagina pubblica, rivolta a chi sta valutando dove andare a lavorare.

Il quadro che ne esce è più semplice e più duro di quello con l’India al centro. Una parte rilevante dei maggiori operatori globali dei servizi informatici sta correndo sullo stesso ruolo, e tra i due che hanno dichiarato pubblicamente un obiettivo di scala uno è indiano e l’altro no. Quattro aziende, per quanto grandi, non sono un settore, e nessuna delle fonti raccolte fornisce un denominatore. La domanda su chi vincerà quella corsa non ha oggi una risposta verificabile, e questo articolo non prova a darla. Il fatto rilevante è che la corsa sia cominciata.

Resta una simmetria che merita attenzione. OpenAI compra una società di consulenza per avere centocinquanta di questi ingegneri; TCS, che di consulenti ne ha mezzo milione, cerca a sua volta acquisizioni per costruire la propria squadra. Chi ha i modelli compra le competenze di delivery, chi ha le persone compra le competenze sui modelli. Nessuno dei due ritiene di poter formare o assumere abbastanza in fretta, e questo dice qualcosa sulla scarsità reale della combinazione.

Che cosa dice tutto questo sulla durata

Il mercato si sta muovendo in due direzioni contemporaneamente, e vanno tenute insieme.

In estensione cresce. Sei paesi con posizioni aperte alla data della rilevazione, un’espansione dal software di frontiera al gestionale di fascia media negli Stati Uniti, la discesa nelle imprese medie in Germania, piani da migliaia di persone in India, e un’industria della preparazione ai colloqui che si è formata attorno alla figura.

In profondità si comprime. La sezione precedente ha mostrato che la parte bassa del lavoro, l’estrazione delle strutture e la traduzione dei requisiti in vincoli locali, risulta automatizzabile con gli strumenti censiti fino al maggio 2026. Qui si vede la seconda compressione: dove negli Stati Uniti il titolo indica una figura scarsa e pagata molto, in India diventa un livello di una piramide di delivery, con il volume che ne consegue.

Un ruolo che cresce di numero mentre viene automatizzato dal basso e industrializzato di lato è un ruolo che sta cambiando forma sotto i piedi di chi lo esercita. Che è una cosa diversa dallo sparire, e per chi deve decidere dove investire il proprio tempo conta più della domanda sulla scomparsa.

---

9. L’Italia: il ruolo c’è, la norma non lo vede

Il 30 aprile 2026 l’Italia è diventata il primo paese europeo a codificare in una norma tecnica32Fonte 32fonte primaria×UNI 11621-8:2026, Attività professionali non regolamentate - Profili di ruolo professionale per l'ICT - Parte 8: Profili di ruolo professionale relativi all'Intelligenza Artificiale (IA). Le dodici schede del punto 6 e le correlazioni riportate nelle appendici C e D sono quelle richiamate nell'articolo. Il primato europeo è dichiarato dal Dipartimento per la trasformazione digitale, che ha coordinato l'elaborazione della norma.apri la fonteultima verifica il 1 agosto 2026 i profili professionali dell’intelligenza artificiale. La UNI 11621-8 definisce dodici profili di terza generazione, ciascuno con missione, compiti, risultati attesi, competenze, conoscenze, abilità e indicatori di prestazione. Si applica a chi partecipa alla progettazione, allo sviluppo, all’addestramento, all’integrazione, alla valutazione o alla fornitura di sistemi e servizi basati sull’AI, ed esclude esplicitamente il semplice utilizzatore di strumenti esistenti.

Quattro giorni dopo Anthropic ha annunciato la propria società di servizi per l’AI aziendale. Sette giorni dopo OpenAI ha lanciato la Deployment Company acquisendo centocinquanta forward deployed engineer.

I dodici profili, e chi manca

Chief AI Officer, AI Consultant, AI Product Manager, AI Prompt Engineer, AI Algorithm Engineer, AI Deep Learning Engineer, AI Data Engineer, AI Data Scientist, AI Security Specialist, AI Machine Learning Engineer, AI Natural Language Processing Engineer, AI Research Scientist.

Il forward deployed engineer non compare né tra i dodici profili né tra i titoli alternativi dell’appendice normativa. Questa assenza va interpretata nel perimetro corretto: la UNI riguarda attività professionali non regolamentate, non istituisce titoli riservati e dichiara che i profili possono essere esercitati in modo non esclusivo, indipendentemente dall’inquadramento lavorativo. Non dice quindi che il mestiere non esista; dice che quella combinazione di compiti non è isolata in un profilo dedicato.

La norma, però, non ignora il deployment. Ne distribuisce le componenti fra più figure.

L’AI Consultant è il profilo più vicino sul versante organizzativo. Analizza le esigenze, definisce requisiti funzionali, coordina l’adozione nei processi esistenti, progetta la formazione, accompagna il cambiamento e monitora le prestazioni. Supervisiona lo sviluppo, ma non è responsabile della costruzione tecnica degli artefatti né di un passaggio finale di autonomia al cliente.

L’AI Product Manager governa roadmap, co-design, criteri di rilascio, sorveglianza umana e miglioramento post-lancio. Copre quindi il ciclo di vita e il raccordo fra funzioni, ma coordina la delivery invece di realizzarla.

L’AI Machine Learning Engineer è il più vicino sul versante tecnico. Porta modelli in produzione, sviluppa API e servizi per integrarli nei processi aziendali, valida prototipi end-to-end, costruisce monitoraggio e manutenzione e produce la documentazione per il trasferimento in produzione. La sua responsabilità resta però centrata sul ciclo di vita del machine learning: la scheda non prevede presenza nell’organizzazione di un cliente né il compito di renderne autonomo il personale.

I pezzi del mestiere, dunque, sono presenti. Quello che manca è il loro accorpamento nella stessa persona: lavoro dentro il contesto del cliente, responsabilità del risultato in produzione e trasferimento finale della capacità operativa.

Dai profili AI ai profili ICT

La UNI 11621 è una serie, e le altre parti codificano i profili ICT generali. La stessa Parte 8 fornisce il raccordo: dichiara l’allineamento con l’e-Competence Framework europeo e correla ciascuno dei dodici profili ai profili di seconda generazione della UNI 11621-2. L’appendice precisa che la correlazione è indicativa e non rende identiche le rispettive abilità e conoscenze.

I profili di seconda generazione derivano dal CWA 16458-133Fonte 33fonte primaria×CWA 16458-1:2018, documento CEN-CENELEC sui profili professionali ICT europei. È il termine di paragone rispetto a cui si misura che cosa la norma italiana aggiunga.apri la fonteultima verifica il 28 luglio 2026:2018, un accordo di workshop del CEN liberamente scaricabile, che ne definisce trenta. Le quattro schede più vicine alle funzioni del forward deployed engineer coprono anche qui parti diverse del lavoro.

Profilo	Funzione descritta dalla norma	Perché non descrive il ruolo
Digital Consultant	Aiuta a comprendere come le tecnologie digitali creino valore per un’impresa	Fa sorveglianza tecnologica e supporta l’individuazione di bisogni e soluzioni. Consiglia, non costruisce
Solution Designer	Traduce i requisiti aziendali in soluzioni IT end-to-end	Il più vicino di tutti, ed è responsabile della «Solution in Operation». Ma la missione si ferma a proporre e progettare, senza permanenza dentro l’organizzazione del cliente né trasferimento di autonomia
Developer	Progetta o scrive componenti conformi alle specifiche della soluzione	Costruisce e integra, ma non ha la responsabilità della scoperta organizzativa né del trasferimento al cliente
DevOps Expert	Applica processi e strumenti di deployment lungo l’intero ciclo di sviluppo	Integra, testa e distribuisce soluzioni, ma non assume la responsabilità del dominio del cliente o della sua autonomia

Sommando le due generazioni si arriva a quarantadue profili codificati tra ICT e AI. Nessuno porta il titolo di forward deployed engineer e nessuna scheda riunisce le tre condizioni della definizione operativa usata in questo articolo. La conclusione è però meno binaria: la normazione vede le attività, ma le distribuisce fra consulenza, prodotto, sviluppo, integrazione e operations. Il mercato le sta ricomponendo in un ruolo di confine che la tassonomia non nomina ancora.

Che cosa succede intanto nel mercato reale

La rilevazione su LinkedIn del 30 luglio 202629Fonte 29fonte primaria×Seconda rilevazione propria, LinkedIn, 30 luglio 2026, ricerca «Forward Deployed Engineer» con località Italia. Dodici datori di lavoro distinti dopo la deduplicazione degli annunci ripetuti e promossi. Esclusi due intermediari (K2 Partnering Solutions, società di ricerca e selezione, e Jobgether, aggregatore) perché non è verificabile per chi cerchino: stesso criterio applicato altrove nell'articolo. Come per Indeed, restano fuori le assunzioni che non passano da un annuncio pubblico.non disponibile onlineultima verifica il 30 luglio 2026 restituisce dodici datori di lavoro distinti, tre dei quali italiani. Il dato più informativo non è il totale, che dipende dalla copertura della piattaforma, ma la composizione: il ruolo entra in Italia in quattro forme diverse, non in una.

Il fornitore che porta il proprio prodotto. Salesforce cerca a Milano un Forward Deployed Engineer e un Senior, e a Roma due posizioni dedicate a settore pubblico, non profit e istruzione. Accanto ci sono Kong a Milano, GitLab per l’area EMEA e l’irlandese Nearform da remoto. In questa categoria rientra anche una startup francese, bonx, che cerca il proprio «first Forward Deployed Engineer for Bonx’s Italian market» con uno stack costruito su n8n e LangChain: strumenti alla portata di un’impresa media, non infrastrutture da laboratorio di ricerca.

E qui c’è la prima azienda italiana. indigo.ai, nata al Politecnico di Milano nel 2016 e oggi una scale-up finanziata, cerca a Milano un Forward Deployed AI Engineer. Passando l’annuncio ai tre criteri della sezione tre, li soddisfa tutti: sta con il cliente, risponde del risultato in produzione, e sul trasferimento è esplicito, perché tra i compiti elenca formazione e documentazione «perché il cliente possa gestire e ottimizzare i propri AI Agent in autonomia»34Fonte 34fonte primaria×Annuncio indigo.ai per Forward Deployed AI Engineer, Milano. indigo.ai è una scale-up italiana nata al Politecnico di Milano nel 2016. L'annuncio soddisfa i tre criteri della sezione tre, dichiara il trasferimento al cliente fra i compiti, e chiede esplicitamente la capacità di far astenere l'agente quando non sa.non disponibile onlineultima verifica il 30 luglio 2026.

Due dettagli di quell’annuncio meritano di essere segnalati, perché arrivano dal lato di chi assume e confermano due punti che questo articolo argomenta dal lato delle fonti. Il primo è che tra le competenze richieste c’è saper decidere quando l’agente «deve dire “non lo so” invece di inventare una risposta plausibile»: è la non generazione della sezione sette, chiesta in un annuncio di lavoro. Il secondo è che l’uso di strumenti di generazione di codice è un requisito, non un vezzo, e serve «per dirigere e valutare ciò che viene costruito, non per scriverlo riga per riga».

La consulenza che lo mette in organico. Accenture Italia cerca a Milano e a Roma su due livelli distinti, Specialist e Manager, ciascuno con il proprio inquadramento contrattuale. BCG X ha una posizione aperta a Milano. Accenture non si è limitata a creare la posizione: l’ha inserita in una scala di carriera.

L’annuncio Accenture merita una lettura anche per come è scritto. Apre dichiarando che cosa il ruolo non è: «This is not a consulting role. It is not a project delivery role. It is not a research position»31Fonte 31fonte primaria×Annunci Accenture Italia per Forward Deployed AI Engineer, livelli Specialist e Manager, Milano e Roma, pubblicati il 24 luglio 2026. Contengono la definizione per esclusione del ruolo, il criterio del trasferimento al cliente, l'esclusione esplicita dei falsi positivi e le fasce retributive dichiarate ai sensi della normativa sulla trasparenza.non disponibile onlineultima verifica il 30 luglio 2026. Sul trasferimento è più preciso di quanto sia stata finora la letteratura citata in questo articolo, e chiede di costruire artefatti «that the client owns after you leave, enabling the client team to run it without you». Ed esclude esplicitamente i falsi positivi: «internal projects, vendor labs, or team-only deployments do not qualify».

I servizi informatici indiani che lo esportano qui. HCLSoftware cerca a Roma. È la sezione otto vista dall’Italia: il settore che secondo la lettura corrente doveva subire il modello lo sta portando dentro un mercato europeo.

L’impresa che se lo costruisce dentro. Duferco, gruppo siderurgico ed energetico con attività industriali italiane, cerca a Milano un Forward Deployed Engineer per il proprio Corporate Innovation Team35Fonte 35fonte primaria×Annuncio Duferco per Forward Deployed Engineer nel Corporate Innovation Team, Milano. Duferco è un gruppo siderurgico ed energetico con quartier generale a Lugano e stabilimenti italiani, attivo su acciaio, energia, trading, logistica e assicurazioni. È la variante interna del ruolo: nessun cliente esterno, nessuna data di uscita.non disponibile onlineultima verifica il 30 luglio 2026: una variante interna, non rivolta a clienti esterni, che la sezione dieci esamina nel dettaglio.

La quinta forma è quella che la definizione esclude

Un annuncio dei dodici non passa i criteri della sezione tre, ed è utile proprio per questo.

altermAInd, società milanese nata a fine 2024 come scorporo della divisione tecnologica di un gruppo bancario, cerca cinque persone per un’unità che lavora «dentro il cliente», su banche, assicurazioni e sanità. Il primo criterio è soddisfatto. Gli altri due no, e lo dichiara l’annuncio stesso: il compito è portare le soluzioni «da zero a una prova funzionante», mentre «le altre squadre prendono ciò che noi proviamo sul campo e lo rendono solido, scalabile, industriale»36Fonte 36fonte primaria×Annuncio altermAInd per Forward Deployed AI Engineer, Milano. Società milanese nata a fine 2024 dallo scorporo della divisione tecnologica del gruppo bancario Illimity. L'annuncio soddisfa il criterio embedded ma dichiara di fermarsi alla prova funzionante, con l'industrializzazione affidata ad altre squadre: è il caso che la definizione della sezione tre esclude.non disponibile onlineultima verifica il 30 luglio 2026.

Non c’è produzione e non c’è trasferimento al cliente. È un’unità di prototipazione avanzata presso il cliente, che è un mestiere reale e difficile, e non è quello descritto in questa sezione. Averlo trovato in un annuncio italiano vale più di qualunque tabella comparativa: mostra che la distinzione della sezione tre non è un esercizio definitorio, perché separa due lavori che sul mercato portano lo stesso nome.

Quanto viene pagato, adesso che si può sapere

Fino a poco tempo fa una sezione come questa avrebbe dovuto accontentarsi di stime. Il recepimento italiano della direttiva europea sulla trasparenza retributiva, con il decreto legislativo 96 del 7 maggio 202637Fonte 37fonte primaria×Decreto legislativo 7 maggio 2026, n. 96, «Attuazione della direttiva (UE) 2023/970 [...] volta a rafforzare l'applicazione del principio della parità di retribuzione tra uomini e donne per uno stesso lavoro o per un lavoro di pari valore attraverso la trasparenza retributiva e i relativi meccanismi di applicazione». Il capo II, articoli 5-11, è quello dedicato alla trasparenza retributiva. Verificata su Normattiva l'esistenza, il titolo e l'oggetto del decreto; le fasce riportate in questa sezione restano comunque prese dagli annunci, non dalla norma.apri la fonteultima verifica il 31 luglio 2026, ha cambiato la situazione: gli annunci dichiarano la fascia, e quelle che seguono sono cifre pubblicate, non ricostruite.

Posizione	Fascia lorda annua	Contratto
Accenture, Specialist	32.000 - 54.900 €	livello B2
Accenture, Manager	50.000 - 86.700 €	livello A1
altermAInd	40.000 - 55.000 €	CCNL credito

Due osservazioni. La prima è che non emerge una fascia unica: i valori dipendono dal livello e dal datore di lavoro, e gli intervalli si sovrappongono. La seconda è che il ruolo, in Italia, viene inquadrato nei contratti collettivi esistenti: il credito per chi nasce dentro una banca, i livelli interni della consulenza per chi nasce in una società di servizi. Nessuno ha dovuto inventare una categoria, il che è coerente con quanto dice la prima metà di questa sezione a proposito della norma tecnica.

Il lavoro però si fa, sotto un altro nome

Sarebbe sbagliato concludere che in Italia questo mestiere non venga esercitato. Viene esercitato, e in almeno un caso documentato viene anche pagato bene.

Il caso TrueLayer, già analizzato nella sezione sei, mostra che la stessa competenza può ricevere un titolo diverso. A Milano la società cerca un Senior Agentic Enablement Engineer rivolto all’organizzazione interna, non ai clienti12Fonte 12fonte primaria×Annuncio ufficiale TrueLayer per «Senior Agentic Enablement Engineer» a Milano. L'annuncio descrive le sedi di Londra, Milano e Dublino, le responsabilità del ruolo, la retribuzione di 85.000-110.000 euro lordi annui più equity e il CCNL commercio.apri la fonteultima verifica il 31 luglio 2026. Il dato nuovo, in questo contesto, è economico: la retribuzione dichiarata è di 85.000-110.000 euro lordi annui più equity, con contratto del commercio.

Vale la pena affiancare quel dato alle fasce dichiarate negli annunci, riportate poco sopra. La versione rivolta all’interno, senza il titolo internazionale e senza trasferte, viene prezzata sopra tutte quelle rivolte al cliente, compreso il livello manageriale della consulenza.

Che cosa significa questo scarto

Nel mercato italiano convivono tre cose che raccontano la stessa storia da tre angoli diversi.

Il primo: quarantadue profili professionali codificati. Le attività del mestiere sono distribuite tra più schede, ma nessuna le riunisce in un profilo dedicato, nel paese che per primo in Europa ha sistematizzato quelle codifiche.

Il secondo: dodici datori di lavoro che assumono con questo titolo sul territorio, tre dei quali italiani, ed entrano in quattro forme diverse, dal fornitore che porta il proprio prodotto all’impresa che se lo costruisce in casa. Le loro mansioni attraversano più profili normati senza coincidere con uno solo.

Il terzo: almeno un’azienda che quel lavoro lo compra davvero, a Milano, con una retribuzione superiore alla scala di riferimento del ruolo, chiamandolo in un altro modo.

Questo scarto ha una conseguenza pratica: competenze già presenti nelle imprese possono restare implicite, fuori dagli inquadramenti e senza un termine di paragone sul mercato. Il vocabolario per descriverle esiste, ma vive soprattutto in inglese e in annunci pubblicati altrove.

Va segnalato, per correttezza, che il tema ha iniziato a circolare anche nella stampa tecnica italiana: il 14 luglio 2026 01net.it ha pubblicato un’analisi sull’ondata di investimenti dei grandi fornitori attorno a questa figura38Fonte 38fonte secondaria×Marcello Oddini, «Forward Deployed Engineering, perché le big tech mandano gli ingegneri dentro le aziende», 01net.it, 14 luglio 2026. L'articolo ricostruisce le iniziative annunciate da Anthropic, OpenAI, AWS e Microsoft e le colloca nella più ampia crescita del modello forward deployed nell'AI aziendale.apri la fonteultima verifica il 1 agosto 2026. La distanza da colmare riguarda il passaggio successivo, cioè il riconoscimento della figura dentro le organizzazioni e negli inquadramenti, non più la sua semplice notizia.

---

10. Nelle imprese medie la figura c’è già, senza titolo

Le sezioni precedenti hanno guardato il ruolo dove il mercato lo nomina: laboratori di intelligenza artificiale, grandi fornitori di software, società di servizi con decine di migliaia di dipendenti. Resta da guardare dove il titolo non arriva.

In un’impresa italiana strutturata, diciamo tra i cinquanta e i cinquecento dipendenti, il lavoro descritto nella sezione sei viene svolto comunque. La conoscenza necessaria è distribuita fra chi governa processi, sistemi ed eccezioni, e spesso resta implicita nella pratica quotidiana. Nei termini usati fin qui, è un livello di grounding operativo che nessuno ha ancora formalizzato.

Un caso in cui il titolo invece c’è

Duferco mostra che questa funzione può essere riconosciuta anche all’interno di un’impresa che non vende tecnologia. Il gruppo siderurgico ed energetico, con quartier generale a Lugano e stabilimenti italiani, cerca a Milano un forward deployed engineer per il proprio Corporate Innovation Team. L’annuncio descrive qualcuno che «works close to business teams, understands messy operational problems» e attraversa domini diversi «not as an external consultant, but as part of the group itself, with the ownership and continuity of an internal product and engineering team»35Fonte 35fonte primaria×Annuncio Duferco per Forward Deployed Engineer nel Corporate Innovation Team, Milano. Duferco è un gruppo siderurgico ed energetico con quartier generale a Lugano e stabilimenti italiani, attivo su acciaio, energia, trading, logistica e assicurazioni. È la variante interna del ruolo: nessun cliente esterno, nessuna data di uscita.non disponibile onlineultima verifica il 30 luglio 2026.

Il caso si colloca al confine della definizione operativa adottata nella sezione tre. L’ingegnere lavora dentro il contesto in cui il sistema verrà usato e ne segue la costruzione, ma non è dispiegato presso un cliente esterno. Il trasferimento non coincide quindi con la restituzione del sistema al termine di un incarico: avviene fra persone e funzioni della stessa organizzazione. Manca anche l’uscita programmata che caratterizza l’ingaggio presso un cliente.

Restano identici l’oggetto costruito e il modo di costruirlo: stare vicino a chi lavora, comprendere problemi operativi disordinati, prototipare, misurare e iterare. Assumendo questa figura, l’impresa internalizza la competenza e la conoscenza accumulata. Accetta il costo di formarle e mantenerle per ridurre il rischio che escano dall’organizzazione insieme al fornitore.

Perché in un’impresa media è distribuito

Nel modello enterprise il forward deployed engineer arriva da fuori, con un mandato e una data di uscita. Nell’impresa media la stessa funzione è quasi sempre interna e frammentata su più persone: il responsabile IT che conosce l’infrastruttura, il capo dell’amministrazione che conosce le regole vere, lo sviluppatore che ha scritto le integrazioni e ricorda perché quella tabella ha quel vincolo.

La differenza rispetto al modello descritto nella sezione due è che nessuna di queste persone ha il compito esplicito di rendere quella conoscenza leggibile a un sistema. La possiede e la usa, ma la tiene dentro la propria pratica quotidiana. Finché il lavoro lo fanno gli esseri umani, quella forma è sufficiente. Quando si prova a mettere un agente sopra un processo, smette di esserlo, perché un agente non può chiedere in corridoio.

Che cosa cambia quando la figura viene riconosciuta

Il punto pratico non è introdurre un ruolo nuovo. È accorgersi che la competenza esiste già, che è concentrata su poche persone e che nessuno l’ha mai descritta.

Le conseguenze del mancato riconoscimento sono tre, e nessuna è teorica. La prima è che la competenza resta legata alle persone invece che all’organizzazione: quando quelle persone escono, il livello di grounding esce con loro, ed è la stessa dinamica che il documento Zenera descrive come conoscenza tribale in uscita per pensionamento. La seconda è che non essendo descritta non viene pagata come tale, perché il mercato non ha un termine di paragone per una cosa senza nome. La terza è che, come si è visto nella sezione nove, in Italia il titolo arriva quasi solo da datori di lavoro stranieri, quindi anche chi volesse riconoscerla non trova un riferimento locale.

Vale la pena notare che il caso TrueLayer descritto nella sezione nove è esattamente la versione riconosciuta di questo lavoro. Una società di dimensione media decide che quella funzione le serve, la descrive in un annuncio, la colloca in un contratto e la paga sopra la fascia di riferimento del ruolo internazionale. Il lavoro è lo stesso che in molte imprese resta implicito.

Lo strumento non è più il vincolo

Fino a poco tempo fa esisteva un’obiezione ragionevole: costruire questa roba richiedeva risorse fuori scala per un’impresa media.

L’annuncio bonx citato nella sezione nove indica uno stack fatto di n8n e LangChain, strumenti che un team interno di due o tre persone può usare senza infrastrutture dedicate. La rassegna conferma dal lato opposto che gli strumenti di primo e secondo livello, quelli che estraggono strutture e traducono requisiti in vincoli, sono maturi e disponibili.

Quello che resta scarso è la capacità di decidere quali artefatti servano e quali regole siano quelle giuste, che la sezione sette ha identificato come la parte non automatizzabile. In un’impresa media quella capacità coincide con conoscere l’azienda, e chi la possiede è già dentro.

Il che porta a una conclusione poco intuitiva per chi guarda gli annunci internazionali. In alcune imprese medie la parte più difficile da comprare è già dentro, perché la conoscenza situata di processi, eccezioni e responsabilità non si assume dall’esterno. Nelle organizzazioni che assumono forward deployed engineer sul mercato accade il contrario: la competenza tecnica si trova, la conoscenza del dominio del cliente va costruita ogni volta da capo.

Detta così, però, sarebbe una mezza verità, e i dati italiani obbligano a completarla. Possedere quel sapere e saperlo trasformare in specifiche, controlli e software mantenibile sono capacità complementari, non due gradini ordinabili in facile e difficile. Istat rileva che nel 2025 la mancanza di competenze adeguate è il primo ostacolo dichiarato, indicato dal 58,6% delle imprese che l’intelligenza artificiale l’avevano valutata senza adottarla39Fonte 39fonte primaria×Istat, «Imprese e ICT - Anno 2025». Perimetro da leggere con attenzione: la graduatoria degli ostacoli (competenze 58,6%, chiarezza legislativa 47,3%, dati 45,2%, privacy 43,2%, costi 43,0%) riguarda soltanto l'11,5% di imprese che hanno valutato l'intelligenza artificiale senza adottarla, non tutte le imprese italiane. I confronti fra classi dimensionali riguardano le imprese con almeno dieci addetti: analisi dei dati 41,9% nelle PMI contro 83,6% nelle grandi, adozione dell'IA 15,7% contro 53,1%.apri la fonteultima verifica il 31 luglio 2026, seguito da chiarezza legislativa, disponibilità e qualità dei dati, privacy e costi. Quel dato riguarda un sottoinsieme ristretto, cioè l’11,5% che ha valutato e rinunciato, e va citato con il suo perimetro. Nella stessa rilevazione la distanza fra classi dimensionali resta ampia: analisi dei dati al 41,9% nelle PMI contro l’83,6% delle grandi imprese, adozione dell’IA al 15,7% contro il 53,1%. Un’indagine dell’OCSE sulle piccole e medie imprese di dodici paesi40Fonte 40fonte primaria×OECD, «Empowering SMEs in the age of AI», OECD SME and Entrepreneurship Papers, 13 aprile 2026, DOI 10.1787/bf5a9816-en. Indagine D4SME. Il campione non è rappresentativo e non consente stime per le PMI italiane: converge con Istat nel mostrare che disporre dello strumento, integrarlo in modo affidabile e saperlo far funzionare sono problemi distinti.apri la fonteultima verifica il 31 luglio 2026 trova ostacoli ricorrenti dello stesso tipo, fra cui competenze, tempo per la formazione, costi di manutenzione e incompatibilità fra sistemi.

L’opportunità quindi esiste, e non è una proprietà generale delle imprese medie. Si realizza quando conoscenza interna, mandato organizzativo, tempo e capacità ingegneristica si trovano nello stesso posto, e nessuna delle fonti raccolte misura quanto spesso questo accada. Quello che si può dire è che la componente scarsa in senso stretto, cioè sapere come funziona davvero quell’azienda, è la sola che non si può acquistare.

11. Chi risponde quando l’ingegnere se ne va

Ogni sezione fin qui ha guardato la costruzione. Questa guarda quello che succede dopo.

Il modello forward deployed prevede un’uscita. La definizione operativa della sezione tre pone il trasferimento di autonomia come uno dei tre elementi costitutivi, e la descrizione che Palantir dà di sé nell’S-1 parla di aiutare i clienti a ottenere il massimo dal software, non di restare per sempre. Il sistema, però, resta.

Le domande che restano senza titolare

Quando l’ingegnere esce, tre responsabilità cambiano proprietario senza che quasi mai qualcuno lo scriva.

Chi sorveglia il comportamento del sistema, cioè chi si accorge se un agente inizia a produrre decisioni diverse da quelle attese. Chi risponde se quelle decisioni causano un danno. Chi aggiorna il livello di grounding quando l’organizzazione cambia, e cambia sempre: una nuova normativa modifica i requisiti documentali, una riorganizzazione sposta le autorizzazioni, un aggiornamento del gestionale rinomina i campi.

La terza è la più insidiosa perché è silenziosa. Un sistema che smette di funzionare si nota. Un sistema che continua a funzionare su presupposti diventati falsi produce risultati plausibili e sbagliati, ed è precisamente lo scenario che la rassegna indica come rischio della dimensione di manutenzione.

Il quadro normativo non lascia la domanda aperta

Sul piano giuridico europeo la risposta esiste già, e ricade sull’impresa che il sistema lo usa. L’articolo 26 del regolamento europeo sull’intelligenza artificiale, il 2024/1689 del 13 giugno 202441Fonte 41fonte primaria×Regolamento (UE) 2024/1689 del 13 giugno 2024, articolo 26: obblighi dei deployer. Uso conforme alle istruzioni, sorveglianza sul funzionamento, conservazione dei log per almeno sei mesi, informazione delle persone sottoposte al sistema, assegnazione della supervisione umana a persone con competenza, formazione e autorità necessarie. Gli obblighi valgono per i sistemi classificati ad alto rischio, non per qualunque impiego di intelligenza artificiale.apri la fonteultima verifica il 29 luglio 2026, attribuisce al deployer, cioè a chi impiega un sistema sotto la propria autorità, obblighi che non si esauriscono con la messa in produzione: sorveglianza sul funzionamento secondo le istruzioni d’uso, conservazione dei log generati automaticamente per almeno sei mesi, informazione delle persone sottoposte al sistema nei casi previsti, e assegnazione della supervisione umana a persone dotate della competenza, della formazione e dell’autorità necessarie. Vale la pena essere precisi sul perimetro, perché è la prima obiezione che arriva in riunione: quegli obblighi ricadono sui sistemi classificati ad alto rischio, non su qualunque impiego di intelligenza artificiale. Chi propone un deployment dentro un processo aziendale che decide su persone o su sicurezza dovrebbe però sapere che la classificazione va verificata prima di firmare, non dopo.

La conseguenza pratica per un’impresa che ingaggia un forward deployed engineer è che gli obblighi del deployer non si trasferiscono insieme al progetto. Il fornitore consegna e conserva obblighi propri, distinti, in quanto fornitore. Quelli che l’articolo 26 mette in capo a chi il sistema lo usa restano invece dove sono, e ingaggiare qualcuno per costruirlo non li sposta di un millimetro. Come si distribuisca il resto, cioè la responsabilità civile verso chi subisce un danno, dipende dal contratto e dal caso concreto: l’articolo 26 da solo non risponde a quella domanda, e sarebbe un errore leggerlo come se lo facesse.

Cinque strati su cui la responsabilità si può appoggiare

Gli obblighi di legge dicono che qualcuno deve rispondere, non come organizzare la risposta. Su questo la letteratura professionale è più avanti di quella scientifica, e la formulazione più compatta che ho trovato viene dall’intervento di Kasthuri già citato nella sezione tre. Distingue cinque strati di governo, e il pregio è che ciascuno corrisponde a una domanda diversa.

Il governo dell’intento verifica che il sistema stia risolvendo un problema autorizzato. Il governo dei dati controlla qualità, accessi, conservazione e tracciabilità delle fonti. Il governo degli strumenti limita le azioni che il sistema può compiere: scrivere su un gestionale, mandare una comunicazione, eseguire codice, modificare una registrazione contabile. Il governo delle decisioni stabilisce dove un essere umano deve approvare o poter ribaltare. Il governo di esercizio sorveglia derive, guasti ricorrenti, costi, latenza e violazioni di policy.

Messi accanto ai cinque componenti del livello di grounding della sezione sei, quegli strati compongono una scaletta utilizzabile in una riunione. Vale la stessa cautela di prima: l’autore lavora per un’azienda che vende questi servizi, quindi lo schema si prende per quello che è, una articolazione professionale e non un risultato di ricerca.

C’è un punto in cui quello schema incontra la letteratura da una direzione inattesa. Kasthuri riporta che Gartner, nella propria guida del 2026, avverte che applicare un governo uniforme a tutti gli agenti produce insieme un rischio di eccesso e uno di difetto di restrizione, e che il livello di controllo va reso proporzionato al grado di autonomia e all’ampiezza degli accessi. È la stessa struttura della tassonomia a tre livelli della sezione sette, arrivata da una casa di analisi di mercato invece che da una rassegna accademica. Le due cose sono state prodotte per scopi che non hanno niente in comune, e concordano su quale sia la variabile che decide.

Dove l’automazione aiuta di meno

C’è una coincidenza spiacevole tra ciò che serve in questa fase e ciò che la tecnologia sa fare.

La sezione sette ha riportato l’analisi delle lacune della rassegna: le due dimensioni più deboli nella costruzione automatica del livello di grounding sono la governance e la manutenzione. I sistemi di conformità, scrivono gli autori, producono rapporti di qualità o di scostamento piuttosto che livelli di governance applicabili.

Sono esattamente le due dimensioni che servono dopo l’uscita. L’automazione è avanti dove il rischio è basso, cioè nell’estrazione delle strutture, e indietro dove il rischio è alto. Chi conta di risolvere la fase di handover con gli strumenti disponibili conta sulla parte meno matura.

L’osservazione riguarda i tempi più che la direzione, e la stessa rassegna indica la strada di ricerca da percorrere. Resta che la parte del lavoro destinata a essere automatizzata per ultima è quella che comincia il giorno in cui il progetto si chiude.

Le condizioni del passaggio di consegne

Da tutto questo discendono quattro condizioni da definire prima dell’ingaggio, indipendentemente dalla dimensione dell’impresa.

Quali artefatti restano all’impresa alla fine, in una forma leggibile da chi non ha partecipato al progetto. Chi, con nome e ruolo, esercita la supervisione umana dopo l’uscita, e con quale formazione. Che cosa succede quando cambia una regola aziendale: esiste una procedura per aggiornare il sistema, o si riapre un progetto. Come si accorge l’impresa che il comportamento sta derivando, con quali indicatori e con quale frequenza di controllo.

Una proposta che lascia indefinite queste quattro condizioni può essere ottima sul piano tecnico e spostare comunque sull’impresa un rischio che non è stato calcolato. La formulazione di TrueLayer citata nella sezione nove dice la stessa cosa dal lato di chi costruisce: in un ambiente regolamentato, l’accesso non governato degli agenti ai sistemi di produzione è una passività.

---

12. Il direttore finanziario davanti a una proposta di deployment

In un’impresa media, chi decide se un progetto di questo tipo si fa quasi mai è chi lo capisce sul piano tecnico. È chi ne risponde sul piano economico.

Questa sezione guarda il ruolo dalla parte opposta del tavolo. Nell’analisi confluisce parte della ricerca che ho svolto per la mia tesi magistrale sul ruolo del CFO nell’era dell’intelligenza artificiale. La letteratura economico-aziendale esaminata in quel lavoro ha già formalizzato il problema che un’impresa affronta quando introduce un sistema autonomo in uno dei propri processi.

Perché il direttore finanziario è l’interlocutore

Una proposta di deployment tocca contemporaneamente quattro cose che stanno tutte sulla sua scrivania: un investimento da giustificare, un ritorno da stimare, un rischio da classificare e un obbligo normativo da rispettare. Nelle imprese medie italiane, dove spesso non esiste una figura dedicata alla trasformazione digitale, il direttore finanziario è quindi un interlocutore probabile, e in molti casi lo sponsor economico della decisione.

Non è però il titolare necessario, e presentarlo come tale sarebbe un salto. A seconda della struttura e del caso d’uso la responsabilità può stare sulla direzione generale, sul consiglio di amministrazione, su chi guida i sistemi informativi, sulle operazioni, sul presidio rischi o su un gruppo di lavoro che tiene insieme più funzioni. Né il quadro di gestione del rischio del NIST né l’articolo 26 dell’AI Act assegnano il compito a una funzione aziendale precisa: chiedono responsabilità documentate e persone che abbiano competenza, autorità e mezzi per esercitare la sorveglianza. Il requisito riguarda le condizioni, non il titolo sul biglietto da visita. Questa sezione adotta il punto di vista economico perché è quello da cui la domanda si vede meglio, non perché sia l’unico legittimo.

Il problema è che gli strumenti per valutare quella proposta in gran parte non ci sono. La rilevazione McKinsey sullo stato dell’intelligenza artificiale42Fonte 42fonte primaria×McKinsey, «The state of AI: How organizations are rewiring to capture value». Survey online dal 16 al 31 luglio 2024, 1.491 rispondenti in 101 paesi, il 42% dei quali in organizzazioni sopra i 500 milioni di dollari di ricavi.apri la fonteultima verifica il 29 luglio 2026, condotta tra il 16 e il 31 luglio 2024 su 1.491 rispondenti in 101 paesi, misura dodici pratiche di adozione e ne verifica la correlazione con l’impatto sul margine operativo. Il risultato è duplice, e vale la pena leggerlo in coppia. La pratica che correla di più con il risultato economico è il monitoraggio di indicatori ben definiti sui sistemi in uso, quello che il rapporto chiama tracking well-defined KPIs for gen AI solutions. Ed è anche la pratica che meno di un’organizzazione su cinque dichiara di applicare.

Lo strumento che più di ogni altro si accompagna al ritorno economico è, tra i dodici rilevati, quello che quasi nessuno adotta. La stessa rilevazione riporta che oltre l’80% dei rispondenti non registra alcun impatto tangibile sul margine operativo a livello aziendale. Prima ancora di valutare una proposta nuova, più di quattro organizzazioni su cinque fra quelle che hanno risposto non dichiarano un ritorno misurabile su quello che hanno già. Se non sappiano misurarlo, o se lo misurino e il ritorno non ci sia, la rilevazione non lo distingue: sono due diagnosi molto diverse e portano a decisioni opposte.

Che cosa si sta comprando, in termini economici

Nella letteratura di finanza aziendale esiste una categoria che descrive con precisione questa situazione, e viene dall’Agency Theory: il costo che si sostiene quando si delega a un agente che agisce con informazioni che il delegante non possiede.

Un sistema autonomo dentro un processo è un agente in questo senso. Decide, e lo fa in un modo che chi ne risponde non osserva direttamente. La letteratura chiama costi di agenzia algoritmici quelli che nascono da questa opacità, e il caso che li rende tangibili è Knight Capital.

Vale la pena raccontarlo come lo racconta l’autorità di vigilanza, perché la versione che circola è più drammatica e meno utile. Nell’ordine amministrativo del 201343Fonte 43fonte primaria×Securities and Exchange Commission (SEC), l'ente federale statunitense che vigila sui mercati finanziari, ordine amministrativo nei confronti di Knight Capital Americas LLC, Release n. 70694 del 16 ottobre 2013: «SMARS routed millions of orders into the market over a 45-minute period, and obtained over 4 million executions in 154 stocks for more than 397 million shares», e «Knight lost over $460 million from these unwanted positions». Fra le carenze contestate c'è l'assenza di «technology governance controls and supervisory procedures sufficient to ensure the orderly deployment of new code or to prevent the activation of code no longer intended for use». La perdita accertata dall'ordine è superiore a 460 milioni di dollari; la cifra di 440 milioni proveniva dal comunicato della società del 2 agosto 2012. L'ordine descrive controlli mancanti e procedure di risposta agli incidenti assenti, non un sistema che nessuno poteva fermare.apri la fonteultima verifica il 31 luglio 2026 la SEC ricostruisce che il primo agosto 2012, mentre trattava duecentododici ordini al dettaglio ricevuti dai clienti, il sistema automatico di instradamento della società immise milioni di ordini sul mercato in quarantacinque minuti, con oltre quattro milioni di esecuzioni su centocinquantaquattro titoli e più di trecentonovantasette milioni di azioni. La perdita accertata è di oltre 460 milioni di dollari, non i 440 della prima stima diffusa dalla società il giorno dopo e ancora oggi più citata.

Il punto che interessa qui però non è la cifra. È che la SEC non descrive un algoritmo impossibile da fermare. Descrive controlli che mancavano: nessun presidio in grado di impedire l’immissione di ordini errati, nessun limite aggregato sull’esposizione di capitale, e soprattutto l’assenza di «technology governance controls and supervisory procedures sufficient to ensure the orderly deployment of new code or to prevent the activation of code no longer intended for use» rimasto sui server. Mancavano anche procedure che dicessero al personale come reagire a un incidente tecnologico grave: mentre i tecnici cercavano di capire, l’azienda restò connessa ai mercati e continuò a inviare ordini.

È un caso di negoziazione automatizzata del 2012, non di intelligenza artificiale generativa, e non prova nulla sugli agenti di oggi. Serve come precedente su una cosa sola, che però è esattamente quella di questa sezione: il costo di sorvegliare un sistema fa parte del sistema, e quando non viene comprato il conto arriva lo stesso.

Detto in termini utilizzabili in una riunione: una proposta di deployment non compra soltanto un sistema che funziona. Compra anche la necessità di un apparato che lo sorvegli. Quel secondo costo può non comparire nel preventivo, e conviene chiedere dove sia scritto.

Le domande che spostano la trattativa

La sezione undici ha indicato le condizioni operative da definire per il dopo. Sul piano economico servono tre domande, che un responsabile finanziario può porre senza competenze tecniche.

Come si misura il risultato, e da quando. Un progetto che promette efficienza deve dichiarare rispetto a quale rilevazione di partenza. Se quella rilevazione non esiste, il primo lavoro non è costruire il sistema ma misurare lo stato attuale, e va messo a preventivo.

Che cosa succede al secondo anno. Il costo di un sistema di questo tipo non si esaurisce con la messa in produzione: la letteratura sulla manutenzione dei modelli documenta il fenomeno del deterioramento silenzioso, per cui un sistema continua a produrre risultati plausibili su presupposti diventati falsi. Il preventivo del primo anno dice poco sul costo di possesso.

Quanto siamo legati a chi ce lo costruisce. La dipendenza da un singolo fornitore, con la difficoltà di verificare e di portare altrove il lavoro fatto, è un rischio finanziario prima che tecnico. È anche il punto su cui il modello descritto in questo articolo si distingue: un ingegnere che lascia dietro di sé artefatti leggibili produce un’impresa meno dipendente di uno che lascia un sistema funzionante e opaco.

La governance non è una scelta

C’è un punto su cui la dottrina giuridica italiana è più netta di quanto molti si aspettino. Diritto delle imprese e intelligenza artificiale. Dalla Fintech alla Corptech, il volume di Niccolò Abriani e Giovanni Schneider uscito per il Mulino nel 202144Fonte 44fonte secondaria×Niccolò Abriani e Giovanni Schneider, «Diritto delle imprese e intelligenza artificiale. Dalla Fintech alla Corptech», Bologna, Il Mulino, 2021.non disponibile onlineultima verifica il 29 luglio 2026, sostiene che la supervisione dei sistemi automatici rientri negli obblighi di diligenza degli organi societari, quindi non appartenga alla sfera delle scelte discrezionali. Sul piano regolamentare europeo, i sistemi classificati ad alto rischio comportano obblighi di tracciamento, supervisione umana e verificabilità, con sanzioni commisurate al fatturato.

La conseguenza pratica per chi valuta una proposta è che la voce di costo relativa alla governance non si può trattare come opzionale da attivare in un secondo momento. Se il sistema entra in un processo che ricade in quelle categorie, l’apparato di controllo entra con lui.

Che cosa cambia negli indicatori

Un progetto di questo tipo introduce grandezze che il cruscotto tradizionale non contiene. La letteratura di settore ne indica alcune che si possono adottare senza attrezzature particolari: la quota di sistemi sottoposti a revisione periodica, il numero di incidenti rilevati e risolti, il tempo medio di risposta agli allarmi, il grado di conformità agli obblighi applicabili.

Sono indicatori di sorveglianza, e servono a rispondere alla domanda che il consiglio di amministrazione porrà prima o poi, cioè come facciamo a sapere che sta ancora funzionando come deve.

Il punto che chiude il cerchio

Nella letteratura economica sull’intelligenza artificiale esiste un argomento, formulato da Ajay Agrawal, Joshua Gans e Avi Goldfarb in Prediction Machines (Harvard Business Review Press, 2018)45Fonte 45fonte secondaria×Ajay Agrawal, Joshua Gans, Avi Goldfarb, «Prediction Machines: The Simple Economics of Artificial Intelligence», Harvard Business Review Press, 2018.non disponibile onlineultima verifica il 29 luglio 2026, secondo cui questi sistemi abbassano il costo della previsione. La conseguenza che ne traggono è meno ovvia della premessa: quando la previsione costa poco, il valore del giudizio umano aumenta, perché diventa la risorsa scarsa nella catena decisionale.

È la stessa struttura che la sezione sette ha trovato dal lato tecnico. Gli strumenti automatici sanno verificare che una regola sia formulata correttamente e non sanno stabilire se sia la regola giusta, e quella distinzione richiede di conoscere il dominio. Un argomento nato per descrivere il lavoro del direttore finanziario e un’analisi della letteratura sulla costruzione automatica del contesto operativo arrivano, per strade indipendenti, alla stessa conclusione su dove si sposta il valore.

---

13. Il mestiere visto dalla porta d’uscita

Tutto quello che precede descrive come si entra in questo lavoro. Gli annunci raccontano l’ingresso, i processi di selezione misurano l’ingresso, le retribuzioni dichiarate riguardano l’ingresso. Sull’uscita non esiste quasi niente, e un articolo che si propone come riferimento sulla carriera non può fermarsi dove si ferma il materiale promozionale.

Su questa parte del mestiere le prove disponibili sono limitate. Nessuna delle fonti raccolte misura quante persone lascino il ruolo, per quale motivo o dopo quanto tempo. La sezione distingue quindi tre livelli di evidenza: ciò che i datori di lavoro mettono per iscritto, ciò che la ricerca permette di dire sui meccanismi generali e ciò che resta affidato alle testimonianze individuali.

Quello che i datori mettono per iscritto

Le trasferte compaiono nei contratti, non nei racconti. Un annuncio pubblicato per un’azienda di tecnologia per la difesa nell’area di Washington definisce il modello di lavoro come «On-site with customer (50% travel)» e più avanti ripete «Up to 50% travel may be required», a fronte di una retribuzione di 155.000-225.000 dollari di base più bonus ed equity46Fonte 46fonte primaria×Annuncio «Forward Deployed Engineer - Logistics Programs» pubblicato da Sitreps per conto di un'azienda di tecnologia per la difesa, area di Washington DC. Dichiara il modello di lavoro come «On-site with customer (50% travel)» e, più avanti, «Up to 50% travel may be required». Retribuzione dichiarata 155.000-225.000 dollari di base più bonus del 30% e equity. Recuperato dall'API pubblica di Greenhouse. Gli annunci scadono.apri la fonteultima verifica il 31 luglio 2026. È lo stesso tetto dichiarato dalla posizione OpenAI citata nella sezione tre.

Sarebbe però scorretto trasformare questo in una regola del mestiere, e la verifica lo mostra bene. Un annuncio di Restate per lo stesso ruolo dichiara «Travel approximately one to two weeks per quarter»47Fonte 47fonte primaria×Annuncio «Forward Deployed Engineer» di Restate, Stati Uniti. Dichiara «Travel approximately one to two weeks per quarter». Serve da controesempio: una revisione critica lo indicava fra gli annunci con reperibilità ed escalation post-vendita, ma il testo recuperato dall'API pubblica di Ashby non contiene né l'una né l'altra, e il carico di trasferte è un ordine di grandezza sotto quello degli annunci al 50%.apri la fonteultima verifica il 31 luglio 2026, che è un ordine di grandezza sotto. La trasferta è un requisito di posizioni specifiche, con una dispersione enorme fra un caso e l’altro, e chi valuta un’offerta deve leggerla in quell’offerta invece di ricavarla dal titolo.

La seconda cosa che compare per iscritto è la reperibilità. Synapse Analytics chiede di «participate in an on-call or escalation rotation for critical client-facing production environments»48Fonte 48fonte primaria×Annuncio «Forward Deployed Engineer II» di Synapse Analytics, Maadi (Egitto), ibrido. Chiede di «participate in an on-call or escalation rotation for critical client-facing production environments» e di produrre «deployment runbooks, environment handover documents, update and rollback procedures».apri la fonteultima verifica il 31 luglio 2026. Nuon è più esplicita di chiunque altro sul contenuto operativo: collaborare con il team reperibile su «follow-the-sun handoffs», eseguire «customer-initiated break-glass operations», rispondere agli allarmi «before customers notice» e saper condurre «an incident bridge»49Fonte 49fonte primaria×Annuncio «Forward Deployed Engineer» di Nuon, San Francisco. Chiede di «partner with the IST-based on-call team on follow-the-sun handoffs», di «execute customer-initiated break-glass operations with the auditability and time-bound access controls our customers expect», di «respond to alerts before customers notice» e di saper condurre «an incident bridge». Recuperato dall'API pubblica di Ashby, perché la pagina è generata da JavaScript e non restituisce testo.apri la fonteultima verifica il 31 luglio 2026.

Qui c’è un punto che riguarda la definizione adottata nella sezione tre e che vale la pena esplicitare. Un ruolo che prevede reperibilità sull’ambiente di produzione del cliente dopo la messa in esercizio è un ruolo in cui il trasferimento di autonomia, se avviene, avviene più tardi di quanto la definizione lasci immaginare. Il criterio di transfer descrive un obiettivo di delivery. Non descrive che cosa succede al calendario di chi lo persegue.

Quello che la ricerca permette di dire, e quello che non permette

Nessuno ha misurato il burnout dei forward deployed engineer. Chiunque affermi una percentuale se la sta inventando, e in questa sezione non ne comparirà nessuna.

Quello che esiste è una letteratura su meccanismi, costruita su popolazioni vicine. Sulle trasferte, uno studio del 2021 su venditori che viaggiano frequentemente collega l’attrito dei viaggi al conflitto tra lavoro e famiglia e all’esaurimento emotivo50Fonte 50fonte primaria×Scott C. Ambrose, Blaise P. Waguespack, Brian N. Rutherford, «The negative effects of travel friction among road warrior salespeople», Journal of Air Transport Management, 2021, DOI 10.1016/j.jairtraman.2021.102087. Studio peer-reviewed su venditori che viaggiano frequentemente: collega l'attrito delle trasferte al conflitto tra lavoro e famiglia e all'esaurimento emotivo. La popolazione è vicina per esposizione ai clienti e ai viaggi, ma non è composta da ingegneri.apri la fonteultima verifica il 1 agosto 2026. Un secondo studio, condotto su 134 viaggiatori d’affari internazionali di paesi diversi, individua nel carico di lavoro il predittore più solido dell’esaurimento e nel supporto organizzativo una risorsa per il coinvolgimento51Fonte 51fonte primaria×Lucy Rattrie, Markus G. Kittler, Scott Cohen, Jason Li Chen, «Does Job Demands-Resources Theory work for international business travel?», Journal of Transport & Health, 2022, DOI 10.1016/j.jth.2022.101366. Studio peer-reviewed su 134 viaggiatori d'affari internazionali di paesi diversi. Il carico di lavoro emerge come predittore dell'esaurimento e il supporto organizzativo del coinvolgimento; gli altri effetti di moderazione considerati risultano misti.apri la fonteultima verifica il 1 agosto 2026. Le altre forme di supporto e adattamento considerate producono risultati misti: la trasferta non è un danno automatico, e l’esito dipende anche da come il lavoro viene organizzato.

Sulla reperibilità, uno studio sperimentale sul campo rileva che il sonno nelle notti di turno è meno ristoratore anche quando non arriva alcuna chiamata, soprattutto quando la possibilità di essere chiamati viene vissuta come stressante52Fonte 52fonte primaria×Carla M. Ziebertz, Debby G. J. Beckers, Madelon L. M. Van Hooff, Michiel A. J. Kompier, Sabine A. E. Geurts, «The effect on sleep of being on-call: an experimental field study», Journal of Sleep Research, 2017, DOI 10.1111/jsr.12519. Studio sperimentale sul campo con disegno entro-soggetto: rileva una qualità e un valore ristoratore del sonno inferiori nelle notti di reperibilità, anche senza una chiamata effettiva.apri la fonteultima verifica il 1 agosto 2026. Una revisione sistematica del 202553Fonte 53fonte primaria×H. Bumpstead e altri, «How should we manage fatigue in on-call workers? A review of guidance materials and a systematic review of the evidence-base», Sleep Medicine Reviews, 2025, DOI 10.1016/j.smrv.2024.102012. La revisione esamina 65 documenti di orientamento e 17 studi originali sulle strategie di gestione della fatica. Le prove sugli interventi restano limitate e le professioni considerate non comprendono il forward deployed engineering.apri la fonteultima verifica il 1 agosto 2026, basata su 65 documenti di orientamento e 17 studi originali, conferma il problema della fatica ma trova ancora poche prove sull’efficacia delle contromisure. Anche qui le professioni studiate sono diverse e nessuna è l’ingegneria forward deployed.

Sugli sviluppatori esiste materiale più diretto. Uno studio su 3.281 persone collega cultura organizzativa, appartenenza e clima di apprendimento alla soddisfazione e al burnout54Fonte 54fonte primaria×Bianca Trinkenreich e altri, «A Model for Understanding and Reducing Developer Burnout», arXiv 2301.09103, 22 gennaio 2023. Campione di 3.281 persone, ma proveniente da una sola azienda, Globant, e non isola i ruoli forward deployed.apri la fonteultima verifica il 31 luglio 2026, ma proviene da una sola azienda e non isola i ruoli forward deployed. Una rassegna sistematica pubblicata nel 2025 sintetizza 44 studi quantitativi, per un totale di 16.086 professionisti in almeno 42 paesi55Fonte 55fonte primaria×Povilas Godliauskas, Darja Smite, «The well-being of software engineers: a systematic literature review and a theory», Empirical Software Engineering, volume 30, 2025, DOI 10.1007/s10664-024-10543-8. Rassegna sistematica peer-reviewed di 44 studi quantitativi, con 16.086 professionisti in almeno 42 paesi. Il benessere dipende da fattori individuali, di squadra e organizzativi, e fra gli esiti associati c'è l'intenzione di lasciare.apri la fonteultima verifica il 1 agosto 2026: conferma che il benessere dipende da fattori individuali, di squadra e organizzativi, e che fra gli esiti associati c’è l’intenzione di lasciare.

Messe insieme, queste fonti autorizzano una sola affermazione, e conviene formularla con esattezza. Il ruolo mette in capo alla stessa persona un insieme di condizioni che la ricerca collega separatamente all’esaurimento: trasferte frequenti in alcune posizioni, reperibilità in altre, pressione commerciale e tecnica nello stesso giorno, ambiguità di ruolo per definizione del mestiere. Che questo produca più abbandoni che in altri ruoli di ingegneria nessuno l’ha verificato.

L’unico soggetto che lo dichiara un problema strutturale è un fondo di venture capital56Fonte 56dichiarazione di un fornitore×CRV, «Forward Deployed Engineer», pagina di contenuti del fondo di venture capital. Nella sezione «Burnout and Retention Risk» descrive il rischio come strutturale, per la combinazione di lavoro tecnico profondo, relazione con il cliente e viaggi frequenti, e propone rotazioni fra incarichi presso il cliente e periodi interni. Statuto della fonte: non dichiara autore, non cita studi, non espone alcun metodo, e proviene da un investitore che finanzia aziende che questo modello lo adottano. Vale come ipotesi formulata da chi osserva molte aziende, non come misura.apri la fonteultima verifica il 31 luglio 2026, che parla di rischio dovuto alla combinazione di lavoro tecnico profondo, relazione con il cliente e viaggi, e propone rotazioni fra incarichi esterni e periodi interni. La proposta è sensata. La fonte non dichiara autore, non cita studi, non espone alcun metodo, e finanzia aziende che questo modello lo adottano.

Una pausa: che cosa dicono quelli che ci sono passati

Se siete arrivati fin qui, vi meritate una pausa dal linguaggio degli studi, delle norme e degli annunci.

Il materiale che segue è raccolto, senza pretesa di rappresentatività, da una discussione pubblica frequentata da sviluppatori esperti57Fonte 57fonte secondaria×Discussione pubblica su r/ExperiencedDevs dedicata al ruolo di forward deployed engineer, aperta circa sei mesi prima della consultazione da uno sviluppatore con oltre otto anni di esperienza, con una trentina di risposte. Gli originali inglesi delle citazioni sono disponibili nel thread. Limiti: sono commenti anonimi, non verificabili uno per uno, e chi partecipa a una discussione del genere si autoseleziona. Valgono come voci di prima mano su un ruolo di cui non esiste letteratura occupazionale, non come campione di alcunché. Da qui non si ricava nessuna frequenza.apri la fonteultima verifica il 31 luglio 2026. Serve a far emergere esperienze individuali che annunci e studi non registrano. Fra una trentina di risposte compaiono il racconto di chi ha lasciato un lavoro analogo dopo il burnout da trasferte e quello di un senior forward deployed engineer oggi in attività. I commenti sono anonimi e non verificabili individualmente: valgono come testimonianze, non come campione.

L’obiezione più diffusa non riguarda la fatica. Riguarda il nome, e ritorna in almeno sei interventi indipendenti. «Questo è semplicemente fare consulenza di implementazione, ma con un titolo nuovo, giusto?». «Un nome altisonante per un consulente». «Per me FDE sembra un rebranding dei titoli Solution Engineer, Integrator e Consultant. In sostanza, lavori con i clienti per rendere operativo il prodotto dell’azienda. Nulla di nuovo sotto il sole.» Chi la formula più per esteso lo colloca in una genealogia precisa: «Forward Deployed Engineer è solo il modo oggi alla moda per dire Consulting Architect o Consulting Engineer: quello che prima consisteva nell’affiancare le aziende nell’adozione del cloud oggi consiste nell’affiancarle nell’introduzione dell’AI applicata o di altre tecnologie recenti». È l’obiezione che la sezione quattro affronta dal lato delle definizioni, formulata da chi il lavoro l’ha fatto.

Il rischio che preoccupa di più è la traiettoria, non le trasferte. È il punto che nessuna delle fonti istituzionali raccolte per questo articolo nomina, e che qui ricorre con insistenza:

Va preso per quello che è, cioè un parere. Ma è il rovescio esatto della sezione otto: là il ruolo si articola in specializzazioni e linee gerarchiche, qui qualcuno che ci è passato avverte che quelle scale portano altrove rispetto a una carriera di ingegneria. Le due cose possono essere vere insieme, e l’articolo non ha i dati per dire quale pesi di più.

Chi ha lasciato lo ha fatto per le trasferte. Una persona racconta di aver ricoperto un ruolo analogo «circa diciotto anni fa, prima che si chiamasse FDE»: viaggi in tutto il mondo, «è stata un’esperienza straordinaria», con una precisazione che pesa, «non è stata straordinaria per le mie competenze tecniche, ma per tutto il resto». Lo consiglia a chi si stanca in fretta, perché permette di cambiare progetto di continuo. E chiude così: «Alla fine le trasferte mi hanno portato al burnout e ho dovuto trovarmi un lavoro normale». È la traiettoria che gli annunci non mostrano mai, ed è anche la ragione per cui va maneggiata con prudenza, perché parla di due decenni fa e di un mercato del lavoro che non è questo.

Chi ci sta adesso racconta qualcosa di diverso. Un senior forward deployed engineer in un’azienda di prodotti AI con oltre mille dipendenti, cinque mesi nel ruolo, riferisce che le trasferte dal cliente sono state poche: «Quanto alle trasferte dai clienti, davvero poche. La maggior parte dei viaggi è stata per partecipare a conferenze in tutto il mondo». Era arrivato da un ruolo di staff engineer in una società fintech, e la ragione del passaggio rovescia l’ordine che ci si aspetterebbe: «Ho accettato questo ruolo perché ero in burnout nel lavoro precedente». L’esaurimento stava nel lavoro precedente, quello ordinario. Descrive una squadra fatta in maggioranza di ex sviluppatori che scrivono codice su misura per i clienti, e contesta la lettura dominante del thread: «non è sicuramente solo consulenza».

C’è un dettaglio in quel racconto che vale più del resto, e torna utile fra poco. Una funzionalità nata dall’osservare che cosa i clienti chiedessero, di cui lui ha costruito la versione zero, è poi passata di mano: «il lavoro è stato trasferito a una squadra che ne curerà lo sviluppo e la manutenzione nel lungo periodo». È il circuito della sezione due che si chiude, con il lavoro su misura che rientra nel prodotto invece di restare appeso al cliente per cui era nato.

Il codice senza casa

C’è un costo che non riguarda la salute e che gli annunci non nominano mai, perché ricade dopo.

Il lavoro forward deployed produce adattatori, connettori, script, integrazioni e flussi costruiti per un cliente solo. Synapse, nell’annuncio già citato, accompagna quegli artefatti con «deployment runbooks, environment handover documents, update and rollback procedures»: la prescrizione è ragionevole, e rende visibile il rischio opposto. Quel codice funziona in produzione senza avere una casa organizzativa chiara. Non è evidente se appartenga al prodotto del fornitore, al repository del cliente o alla squadra temporanea che l’ha scritto.

«Codice senza casa» è una formula mia e non un termine della letteratura, e va distinta da una nozione tecnica che le somiglia. La ricerca sul turnover usa orphaned code in un’accezione precisa, cioè codice scritto da persone che non fanno più parte del progetto, e ne misura la perdita di conoscenza conseguente58Fonte 58fonte primaria×Daniel Izquierdo-Cortazar e altri, «Using Software Archaeology to Measure Knowledge Loss in Software Projects Due to Developer Turnover», Hawaii International Conference on System Sciences, 2009, DOI 10.1109/HICSS.2009.498. Usa orphaned code in un'accezione precisa, cioè codice scritto da chi non fa più parte del progetto, e misura la perdita di conoscenza che ne consegue. Citato qui per marcare la differenza da «codice senza casa», che è una metafora di questo articolo e non un termine della letteratura.apri la fonteultima verifica il 31 luglio 2026. È un fenomeno affine e non lo stesso.

Il codice su misura non è per definizione usa e getta. Lo diventa quando mancano insieme un proprietario, un budget di manutenzione, una procedura di aggiornamento e una decisione esplicita su che cosa trasferire, che cosa generalizzare nel prodotto e che cosa dismettere. È anche il punto in cui questa sezione tocca la sezione due: il circuito che Palantir descrive nei propri documenti societari, dove il tempo passato sul campo torna dentro il prodotto, funziona solo se quel ritorno avviene davvero. Quando non avviene, resta la personalizzazione e si perde l’apprendimento.

La testimonianza citata poco sopra mostra come si presenta il caso riuscito, ed è utile proprio perché non è drammatico: una funzionalità nata su richiesta di un cliente, passata a una squadra che se ne assume sviluppo e manutenzione. Nessuna delle fonti raccolte dice quanto spesso finisca così invece che nell’altro modo.

Prima di accettare l’offerta

Per chi valuta questo mestiere, la conseguenza pratica della sezione sta in quattro verifiche concrete, nessuna delle quali riguarda lo stack tecnico.

Quante trasferte ha fatto davvero il team nell’ultimo anno, non quante ne prevede il contratto. Come funziona la reperibilità e come viene compensata. Quanti incarichi simultanei porta ogni persona. E chi possiede il codice specifico del cliente dopo il passaggio di consegne.

Sono verifiche a cui un datore serio risponde con numeri e condizioni precise.

---

14. Che cosa resta aperto, e che cosa si può già dire

Le domande senza risposta consolidata

Un articolo che si propone come riferimento deve dichiarare dove il riferimento non arriva. Alla data di questa rilevazione restano aperte sei questioni, e nessuna delle fonti raccolte ne risolve una.

Quanto dura un incarico. Non esiste un consenso, e nemmeno una statistica pubblica. Le descrizioni disponibili parlano di mesi, i piani di assunzione dei grandi fornitori suggeriscono rapporti continuativi, gli annunci non dichiarano quasi mai una durata.

Che cosa un’impresa media riesca davvero a mantenere dopo l’uscita. La sezione dieci ha argomentato che lo stack tecnico richiesto dagli annunci del luglio 2026 è alla portata, con le riserve che i dati Istat e OCSE impongono, ma non esiste letteratura sulla sostenibilità reale nel tempo per organizzazioni senza una funzione tecnica strutturata.

Con quale forma contrattuale, in Italia. Gli annunci dichiarano l’inquadramento, e il ruolo entra nei contratti collettivi già esistenti invece di crearne uno. Resta fuori dal quadro tutto ciò che non passa da un annuncio di lavoro subordinato, cioè consulenza e partita IVA, che è il modo in cui una parte di questo mestiere viene con ogni probabilità comprata.

Se le certificazioni contino qualcosa. Questa domanda va posta in modo diverso da come circola. Qualcosa che usa esplicitamente il titolo esiste già: alla verifica di fine luglio 2026 ho individuato quattro offerte, di enti diversi. Chiamarle tutte certificazioni sarebbe però impreciso, perché non sono la stessa cosa: ci sono credenziali con esame acquistabili da chiunque, un percorso articolato su tre livelli il cui primo ciclo online è annunciato per l’autunno, e un programma formativo che rilascia un attestato. Nessuna costituisce uno standard professionale condiviso, e uno degli operatori del settore lo scrive da sé. La questione aperta riguarda il riconoscimento: in nessuna delle offerte di lavoro raccolte per questo articolo un datore le richiede o le menziona. È un’osservazione sul corpus raccolto qui, non una prova che nessun datore le consideri. Resta il fatto che un mercato formativo si è formato prima che esistesse una domanda documentabile di quel titolo.

Per quanto tempo lo si fa, e perché lo si lascia. È la lacuna più grande. La sezione tredici l’ha affrontata con gli unici strumenti disponibili, cioè i requisiti che i datori mettono per iscritto, la ricerca su popolazioni vicine e una manciata di voci di prima mano raccolte in una discussione pubblica. Continuano a mancare dati su permanenza media, turnover e destinazioni di chi esce, e una decina di commenti anonimi non li sostituisce.

Se sia un ruolo stabile o una fase. È la domanda che dà il titolo all’articolo, e merita più di un rinvio.

Che cosa si può già dire

Le prove raccolte convergono su una risposta articolata, che vale la pena tenere insieme in tutte le sue parti.

Il ruolo non sta scomparendo. La sola formulazione esplicita della tesi della sostituibilità, fra quelle raccolte, viene da un documento che promuove un prodotto e non pubblica prove indipendenti. Un conflitto del genere abbassa il peso di una fonte senza chiudere la questione, e trattarlo come una confutazione sarebbe scorretto quanto ignorarlo. A pesare di più è la convergenza dal lato opposto: cinque filoni di ricerca che non si citano a vicenda incontrano lo stesso confine partendo da problemi diversi, e l’unico risultato con revisione paritaria fra quelli raccolti descrive le professioni erose dall’automazione come professioni che si ricompongono, non che si estinguono. Sul fronte del mercato, alla rilevazione del 30 luglio 2026 il ruolo veniva assunto in sei paesi.

Cambia però composizione, e la spinta arriva da tre lati simultanei. Questa è la lettura di chi scrive, non un risultato delle fonti, e conviene dirlo prima di esporla. Dal basso, perché gli strumenti che estraggono strutture e traducono requisiti in vincoli sono maturi e disponibili, e la quota di produzione manuale si riduce di conseguenza. Di lato, perché nei mercati dei servizi il titolo viene assorbito dentro griglie di inquadramento esistenti e industrializzato su volumi che ne cambiano la natura. E per costruzione, perché un incarico svolto come si deve termina con il cliente autonomo, quindi ogni buon lavoro riduce il bisogno di chi lo ha fatto.

Che il saldo di queste tre spinte sia più posizioni, meno posizioni o le stesse con un contenuto diverso, nessuna delle fonti raccolte lo stabilisce, e questo articolo non lo stabilisce al posto loro.

Quello che resta è la parte che richiede di conoscere l’organizzazione. Questo articolo ha incontrato lo stesso confine tre volte e da tre angoli diversi: nelle competenze richieste dalle selezioni, nell’analisi delle lacune della letteratura scientifica, e negli obblighi che ricadono su chi il sistema lo usa. Ogni volta la linea cadeva nello stesso punto. La correttezza formale di una regola si verifica con un algoritmo; la sua pertinenza a quella azienda, in quel momento, richiede di sapere come quell’azienda funziona davvero. E la decisione più difficile resta quella di non produrre nulla, quando le fonti si contraddicono o quando nessuna autorizza ciò che il cliente sta chiedendo. Quella capacità di giudizio richiede di sapere come funziona davvero quell’azienda, e quel materiale, come la rassegna scientifica fa notare, è proprietario e per questo non entra nei dati su cui vengono addestrati i sistemi che dovrebbero sostituirlo.

La stessa conclusione arriva anche dal lato economico. Art Zeile59Fonte 59fonte secondaria×Art Zeile, amministratore delegato di DHI Group, gruppo proprietario del portale di annunci tecnologici Dice, citato da Forbes il 28 luglio 2026.apri la fonteultima verifica il 29 luglio 2026, amministratore delegato di DHI Group, il gruppo che possiede il portale di annunci tecnologici Dice e che i dati sul mercato del lavoro IT li osserva per mestiere, la formula così: «that role sits exactly where the value is moving, inside the customer, close to the proprietary data, owning the result». Un’analisi di mercato e una rassegna di letteratura scientifica, con metodi e finalità del tutto diversi, indicano lo stesso fossato.

Per chi legge da un’impresa media

La conseguenza pratica è meno spettacolare del dibattito che circola, e più utile.

Per un’impresa media, il punto di partenza è individuare dove risieda già la conoscenza di processi, eccezioni e responsabilità, quindi renderla esplicita e trasferibile. Quella conoscenza da sola non basta: deve essere affiancata da capacità ingegneristiche, tempo e mandato. I dati sulle imprese italiane citati nella sezione dieci mostrano infatti che competenze, qualità dei dati, integrazione e sicurezza restano ostacoli frequenti.

Il vantaggio, semmai, sta nel riconoscerla mentre il vocabolario per descriverla si sta formando altrove. In Italia quel vocabolario è arrivato negli annunci prima che nelle codifiche: dodici datori di lavoro lo usano già per assumere, mentre le quarantadue figure professionali codificate tra profili informatici e profili per l’intelligenza artificiale non lo contemplano.

Chi lo riconosce adesso lo fa con un anticipo che non durerà.

---

Appendice: i dati delle due rilevazioni

Le sezioni otto e nove poggiano su due rilevazioni fatte da me, non su fonti pubblicate. Qui sono riportati i dati, le query e i criteri necessari per replicarle e valutarne i limiti.

Metodo

Prima rilevazione. 28 luglio 2026, Indeed1Fonte 1fonte primaria×Rilevazione propria condotta il 28 luglio 2026 sugli annunci Indeed in sei paesi, con classificazione manuale dei risultati perché la ricerca per parole chiave restituisce falsi positivi. Metodo, query e criteri sono esposti nella sezione otto. Limite accertato: il censimento su questa sola piattaforma, per l'Italia, ha visto tre datori di lavoro su dodici, e quasi tutti quelli mancati erano già online. Va letta insieme alla rilevazione LinkedIn del 30 luglio.non disponibile onlineultima verifica il 28 luglio 2026, interrogato tramite la sua API di ricerca. Query usate, da riutilizzare identiche per una replica:

Query	Località	Paese
forward deployed engineer	United States	US
forward deployed AI engineer	remote	US
forward deployed engineer	Italia	IT
forward deployed	Milano	IT
AI engineer	Milano	IT
forward deployed engineer	Deutschland	DE
forward deployed engineer	France	FR
forward deployed engineer	United Kingdom	GB
forward deployed engineer	India	IN

Seconda rilevazione. 30 luglio 2026, LinkedIn29Fonte 29fonte primaria×Seconda rilevazione propria, LinkedIn, 30 luglio 2026, ricerca «Forward Deployed Engineer» con località Italia. Dodici datori di lavoro distinti dopo la deduplicazione degli annunci ripetuti e promossi. Esclusi due intermediari (K2 Partnering Solutions, società di ricerca e selezione, e Jobgether, aggregatore) perché non è verificabile per chi cerchino: stesso criterio applicato altrove nell'articolo. Come per Indeed, restano fuori le assunzioni che non passano da un annuncio pubblico.non disponibile onlineultima verifica il 30 luglio 2026, ricerca «Forward Deployed Engineer» con località Italia.

Criterio di inclusione. È conteggiata l’offerta il cui titolo contiene «forward deployed», più la denominazione originaria Palantir «deployment strategist», segnalata a parte. Sono escluse le offerte che il motore restituisce per affinità semantica del corpo dell’annuncio: la corrispondenza è approssimativa e ha prodotto anche uno sviluppatore blockchain, un tecnico assemblatore e un’offerta di ristorazione.

Esclusi come intermediari. K2 Partnering Solutions, società di ricerca e selezione, e Jobgether, aggregatore: non è verificabile per conto di chi cerchino.

Come vanno letti questi dati

Due limiti che cambiano il significato dei numeri.

Non è un conteggio. L’interrogazione restituisce al massimo una decina di risultati per query. Le tabelle dicono chi assumeva, non quanti posti fossero aperti, e non esiste un denominatore che permetta di dire se siano tanti o pochi.

Le retribuzioni sono dichiarate quasi solo negli Stati Uniti. Negli annunci europei e indiani il campo è di norma vuoto, per prassi locale. Il confronto transnazionale sui compensi non è sostenibile con questa fonte, e infatti l’articolo non lo fa.

Rilevazione Indeed, 28 luglio 2026

Paese	Datore	Titolo	Data	Retribuzione dichiarata	Tipo
US	Edison Scientific	Forward Deployed AI Engineer	01/07/2026	$200.000-350.000	startup AI
US	Smartsheet	Senior Principal Forward Deployed AI Engineer	22/04/2026	$235.000-315.000	SaaS mid-market
US	Fredrin	Forward Deployed Engineers (FDE)	23/07/2026	$150.000-250.000	n.d.
US	Corepass	Forward Deployed Engineer	23/07/2026	$140.000-200.000	startup, Menlo Park
US	ShipBob	Forward Deployed Engineer III	23/06/2026	$134.162-223.603	logistica/SaaS
US	IntegriChain	AI Engineer, Forward Deployed	21/05/2026	$91.866-143.801	SaaS verticale pharma
US	Altimetrik Corp	Forward Deployed AI Engineer, Lead	10/07/2026	n.d.	servizi, origine indiana
US	Rippling	Forward Deployed Software Engineer	13/01/2026	n.d.	SaaS
US	Edisyl	Forward-Deployed AI Data Engineer	27/04/2026	n.d.	n.d.
US	CURSOR	Forward Deployed Engineer, EMEA	03/06/2026	n.d.	startup AI
IT	Salesforce	Senior Forward Deployed Engineer, Italian Speaking	08/07/2026	n.d.	multinazionale US
IT	Salesforce	Forward Deployed Engineer, Italian Speaking	01/07/2026	n.d.	multinazionale US
IT	Boston Consulting Group	Visiting Forward Deployed AI Engineer, Italy, BCG X	18/02/2026	n.d.	consulenza
DE	Otherworldly, Berlino	Forward Deployed Engineer (f/m/x)	27/07/2026	n.d.	startup DE
DE	2pi IT Solutions, Colonia	Forward-Deployed AI Engineer (m/w/d)	20/07/2026	n.d.	PMI DE, part-time
DE	Adago, Mannheim	Forward-Deployed Engineer (m/f/d)	17/07/2026	n.d.	PMI DE
DE	Salesforce, Monaco	Forward Deployed Engineer + Senior	26/06/2026	n.d.	multinazionale
DE	paretos, Heidelberg	Forward Deployed Engineer Applied AI	22/04/2026	n.d.	scale-up DE
DE	Boston Consulting Group	Forward Deployed AI Engineer, Germany & Austria, BCG X	17/02/2026	n.d.	consulenza
DE	OpenAI, Monaco	Forward Deployed Engineer, Munich	15/10/2025	n.d.	laboratorio AI
FR	Salesforce, Parigi	Senior Forward Deployed Engineer	24/07/2026	n.d.	multinazionale
FR	Salesforce, Parigi	Forward Deployed Engineer	23/07/2026	n.d.	multinazionale
FR	Cleo Labs, Parigi	Forward Deployed Engineer	17/07/2026	n.d.	startup FR
FR	Talan, Parigi	Forward Deployed Engineer IA & Data (H/F), CDI	29/06/2026	n.d.	ESN francese, tempo indeterminato
FR	Palantir, Parigi	Deployment Strategist, Internship	11/05/2026	n.d.	denominazione originaria
FR	HappyRobot	Deployment Strategist	15/03/2026	n.d.	startup
GB	Google	Senior Partner Forward Deployed Engineer, Google Cloud	27/07/2026	n.d.	hyperscaler
GB	RS UK, Londra	Forward Deployed Engineer	20/07/2026	n.d.	n.d.
GB	Workato, Londra	Forward Deployed Engineer	05/05/2026	n.d.	SaaS integrazione
GB	PMG UK, Londra	Forward Deployed Engineer III	22/04/2026	n.d.	n.d.
IN	Wipro, Bengaluru	FORWARD DEPLOYED ENGINEER L3	14/07/2026	n.d.	servizi informatici
IN	Accenture, Hyderabad	Forward Deployed Engineer	30/06/2026	n.d.	consulenza globale
IN	Sarvam, Bengaluru	Forward Deployed Engineer	07/07/2026	n.d.	laboratorio AI indiano
IN	Kognitos, Bengaluru	Forward Deployed Engineer	14/07/2026	n.d.	startup AI
IN	Lenovo, Bengaluru	Forward Deployed Engineer	18/06/2026	n.d.	hardware e servizi
IN	Pattem Digital, Bengaluru	Forward Deployed Engineer	18/06/2026	n.d.	servizi digitali
IN	Cartesia, Bengaluru	Forward Deployed Engineer (India)	25/02/2026	n.d.	startup US con sede indiana
IN	Peaq Labs	Forward Deployed Engineer	17/07/2026	n.d.	tirocinio, da remoto

Con la query forward deployed engineer e località Italia il risultato è stato zero. Le tre righe italiane qui sopra sono comparse solo cercando forward deployed su Milano. Quello zero era un artefatto della formulazione, non un dato di mercato, ed è la prima avvisaglia del problema che la rilevazione successiva ha reso evidente.

Rilevazione LinkedIn, 30 luglio 2026, Italia

Dodici datori di lavoro distinti dopo la deduplicazione degli annunci ripetuti e promossi, contro i tre visti da Indeed due giorni prima.

Datore	Forma di ingresso	Note
Salesforce	fornitore	Milano, più due posizioni a Roma per settore pubblico, non profit e istruzione
Kong	fornitore	Milano
GitLab	fornitore	area EMEA
Nearform	fornitore	irlandese, da remoto
bonx	fornitore	startup francese, primo FDE per il mercato italiano, stack n8n e LangChain
indigo.ai	fornitore, azienda italiana	Milano. Nata al Politecnico di Milano nel 2016
Accenture Italia	consulenza in organico	Milano e Roma, due livelli distinti: Specialist 32.000-54.900 €, Manager 50.000-86.700 €
BCG X	consulenza in organico	Milano
HCLSoftware	servizi informatici indiani	Roma
Duferco	impresa che se lo costruisce dentro	Milano, Corporate Innovation Team. Gruppo siderurgico ed energetico
altermAInd	esclusa dalla definizione	Milano, 40.000-55.000 €, CCNL credito. Embedded sì, ma si ferma alla prova funzionante: niente produzione, niente trasferimento
TrueLayer	titolo diverso, lavoro affine	Milano, Senior Agentic Enablement Engineer, 85.000-110.000 € più equity

Di questi, solo tre annunci erano stati pubblicati dopo il 28 luglio. Tutti gli altri erano online da sei giorni a due mesi, ed erano quindi già raggiungibili quando ho fatto la prima rilevazione, che non li ha visti. È il motivo per cui la sezione otto parla di conclusione sbagliata e non di errore di campionamento.