Non chiamatelo consulente: chi è il Forward Deployed Engineer e cosa devi sapere prima di ingaggiarlo

Le aziende AI e tutti i fornitori SaaS che ormai la integrano nelle proprie soluzioni hanno un problema enorme. Circa il 95% dei pilot di AI generativa non produce alcun impatto misurabile sul conto economico.  La maggior parte dei progetti pilota di intelligenza artificiale in azienda non fallisce per colpa del modello, ma nell’integrazione.

Uno studio del MIT del 2025 ha quantificato il fenomeno in modo brutale, indicando alcuni motivi. I progetti non falliscono perché la tecnologia sia immatura, ma perché l’adozione di un modello, da sola, serve a poco: qualcuno deve entrare nei sistemi, nei dati e nei processi reali e far funzionare la soluzione lì dove il lavoro avviene ogni giorno.

È esattamente in questo divario che si è inserita una figura professionale che nel giro di un anno è passata da curiosità di nicchia a una delle posizioni più contese del settore tech: il Forward Deployed Engineer (FDE).

Cos’è un Forward Deployed Engineer

In una riga: il Forward Deployed Engineer è un ingegnere che si integra nel team del cliente per costruire, configurare e mandare in produzione una soluzione tecnologica nel contesto concreto dell’organizzazione, restando coinvolto fino a quando quella soluzione non produce i risultati attesi.

Il termine nasce in Palantir all’inizio degli anni 2010, dove questi profili venivano chiamati Delta o Forward Deployed Software Engineer. Il termine è mutuato dal gergo militare: il soldato “forward deployed” non sta al quartier generale a disegnare strategie, ma è schierato sul campo e reagisce a ciò che accade davvero. Fino al 2016 Palantir contava più ingegneri di questo tipo che sviluppatori di prodotto tradizionali.

Quello che era un modello da contractor della difesa è esploso con l’AI generativa. Secondo i dati di Indeed citati da Business Insider, gli annunci di lavoro per il ruolo sono passati da 643 ad aprile 2025 a 5.330 ad aprile 2026, un balzo di oltre il 700% in dodici mesi. L’11 maggio 2026 OpenAI ha lanciato la OpenAI Deployment Company, iniziativa da 4 miliardi di dollari dedicata proprio a inserire ingegneri nelle aziende clienti finché l’AI non funziona in produzione. Salesforce si è impegnata a costruire un team di mille FDE; Anthropic e Google hanno costruito i propri team (in Anthropic il profilo è spesso chiamato Applied AI Engineer).

Perché proprio ora? Per tre ragioni convergenti. I contratti di AI enterprise valgono cifre tali da rendere sostenibile mandare ingegneri presso il cliente per mesi. I decisori, di fronte all’AI, sono ancora scettici e hanno bisogno di “vedere per credere” sui propri dati reali, non su una demo. E il valore per il fornitore è doppio, come vedremo: ed è qui che si annidano alcune insidie che ogni decisore dovrebbe mettere a fuoco.

Cosa fa un Forward Deployed Engineer, in concreto

Immaginiamo una grande azienda che voglia automatizzare un processo con agenti AI. L’FDE mappa come funziona l’informatica del cliente (cloud, accessi, database), installa la piattaforma, la collega al gestionale, agli archivi e ai sistemi già in uso, e costruisce insieme a chi quel lavoro lo fa ogni giorno il primo workflow automatizzato. Quando il risultato regge, lo porta in produzione su un campione limitato di casi reali e insegna al team interno a gestirlo e farlo crescere.

La differenza con un fornitore tradizionale non sta tanto nelle prime settimane quanto in quelle dopo: l’FDE non consegna la soluzione e sparisce dopo il go-live. Resta nella fase operativa per intervenire quando il sistema si rompe, quando emergono i casi limite che nessuna demo aveva previsto, quando il team del cliente fa resistenza al nuovo flusso di lavoro.

L’FDE non è un consulente. O meglio: non solo

Qui sta il cuore della questione per chi deve decidere se ingaggiarne uno. Il modello FDE viene spesso descritto come una via di mezzo tra consulenza e ingegneria, ma le differenze con entrambi gli approcci sono netti.

Il consulente tradizionale non è una figura superata. Per le domande di pura strategia, per le analisi di mercato, per gli audit normativi, dove il collo di bottiglia non è l’implementazione, quel modello resta la scelta giusta. L’FDE risulta un’opzione più efficace quando il problema è far funzionare una tecnologia complessa dentro operazioni reali.

Un’estraneo nei sistemi aziendali. E la governance?

Se già per il consulente tradizionale si pone la questione della governance dei dati aziendali, della protezione della proprietà intellettuale e della compliance normativa, con un FDE che è completamente embedded nello staff e accesso ai sistemi aziendali, la preoccupazione si alza.

Partiamo da ciò che è quasi scontato ma va comunque verificato accuratamente nei contratti di fornitura: la proprietà dei dati e dei prodotti del lavoro. I contratti dei principali vendor sono abbastanza chiari a riguardo.

• Palantir stabilisce nei propri Terms of Service che il cliente mantiene tutti i diritti, inclusa la proprietà intellettuale, sui propri contenuti, e dichiara che ogni cliente conserva piena proprietà e controllo dei dati, e che l’azienda non rivende i dati di un cliente a un altro (termini Palantir).
• OpenAI, nel suo Services Agreement per i clienti business, assegna al cliente la proprietà di input e output e si impegna a non usare i contenuti del cliente per sviluppare o migliorare i servizi, salvo esplicito consenso (Services Agreement OpenAI).
• Anthropic, nei Commercial Terms, assegna al cliente la proprietà degli output e si impegna a non addestrare i propri modelli sui contenuti del cliente provenienti dai servizi a pagamento (commercial terms Anthropic).

Tradotto: il timore che “i nostri dati finiscano nel modello AI”, riferito al dato in sé, è in larga parte gestito dal contratto, almeno sui piani enterprise e via API. Su questo fronte la diligence è doverosa ma il rischio è contenuto e mitigabile. Quelle salvaguardie tutelano anche la componente gestita dal Forward Deployed Engineer.

C’è poi un piano che per un’azienda europea pesa quanto la proprietà intellettuale: la governance del dato in ottica GDPR. Il principio da fissare a contratto è semplice e va difeso in fase di negoziazione: l’azienda cliente resta il titolare del trattamento, mentre il fornitore è — al massimo — responsabile del trattamento (data processor), mai contitolare. Significa che il vendor tratta i dati personali solo sulla base di istruzioni documentate del cliente, secondo quanto previsto dall’art. 28 del GDPR, e dentro un Data Processing Agreement (DPA) che ne definisca finalità, sub-responsabili, misure di sicurezza, gestione delle richieste degli interessati e cancellazione dei dati al termine del rapporto.

È esattamente la configurazione che i tre vendor dichiarano: Palantir si qualifica di norma come responsabile e non titolare; OpenAI e Anthropic incorporano un DPA che inquadra il cliente come titolare e il fornitore come responsabile, con le clausole contrattuali standard (SCC) per i trasferimenti fuori dallo Spazio economico europeo.

Per il decisore questo si traduce in due verifiche concrete. La prima: assicurarsi che il DPA esista, sia sottoscritto. La seconda, spesso trascurata, riguarda proprio l’FDE: un ingegnere che lavora dentro l’ambiente del cliente ha accesso operativo a dati personali, e quell’accesso deve ricadere sotto le stesse istruzioni documentate, non muoversi in una zona grigia. Restano da presidiare i due punti deboli tipici: la residenza dei dati (sui piani standard il trattamento avviene spesso negli Stati Uniti) e le finestre di retention, da allineare alle proprie politiche.

Il vero nodo: l’esperienza, non il dato

Ed eccoci al punto che merita lo spazio maggiore, perché è quello che i contratti coprono molto meno e che quasi nessuno mette a fuoco prima di firmare.

Una cosa sono i dati e gli artefatti (i tuoi dati aziendali, il codice scritto, gli output prodotti, la soluzione costruita…). Questi sono governati dal contratto, come abbiamo visto. Un’altra cosa è l’esperienza, cioè  l’insieme di approcci, schemi e best practice che il fornitore matura risolvendo il nostro problema specifico. Questa parte è trattata molto meno nei contratti e dove lo fanno, spesso, è proprio per attribuire al fornitore diritti specifici.

Il meccanismo legittimo, scritto nero su bianco, è la clausola sul feedback. Nei termini di OpenAI, se il cliente fornisce feedback, OpenAI può usarlo e sfruttarlo senza restrizioni né compensazione. In Palantir, suggerimenti, richieste di miglioramento e feedback relativi alla tecnologia rientrano nei diritti del fornitore, che mantiene inoltre la proprietà di ogni opera derivata, modifica o miglioramento della propria piattaforma. Anthropic, allo stesso modo, può utilizzare il feedback ricevuto senza vincoli.

Lo stesso vendor lo racconta apertamente come una virtù del modello. Anthropic, descrivendo la logica del ciclo di feedback, spiega che le interazioni del mondo reale forniscono segnali preziosi su quali risposte siano più utili e accurate, segnali che aiutano a migliorare i modelli futuri (Anthropic, aggiornamento ai termini). Nel gergo del settore lo si chiama “fare ricerca e sviluppo sullo strato applicativo”: per soddisfare l’esigenza del cliente, l’ingegnere dispiegato sul campo chiede al team centrale di fare modifiche al prodotto generico.

Per il fornitore è un vantaggio competitivo enorme. Per il cliente è un costo potenziale, quasi invisibile finché non lo si nomina: il modo in cui si risolve la classe di problema del cliente (il playbook scoperto sui processi e sui dati aziendali) può entrare a far parte del patrimonio del fornitore ed essere esteso ai clienti successivi. Concorrenti inclusi, se condividete la stessa piattaforma.

E c’è un livello che nessuna clausola governa davvero: la conoscenza tacita che una persona si porta in testa. Una clausola di riservatezza protegge le informazioni confidenziali, non l’esperienza che un ottimo ingegnere accumula sul tuo caso e poi applica, in buona fede, al cliente che incontra il mese dopo.

Cosa controllare prima di firmare

Spostato il focus dove serve, la checklist per un decisore enterprise cambia di conseguenza.

Primo, distinguere a contratto due piani diversi: la proprietà di dati e artefatti (di norma a posto) e l’uso del feedback e dei metodi derivati. Su quest’ultimo non sempre si può negoziare, ma è opportuno almeno verificare come siano le cose e, possibilmente, provare a vincolare il riuso degli insight specifici del proprio caso d’uso a favore di concorrenti diretti.

Secondo, pretendere un trasferimento di competenze reale, perché la capacità resti in casa e non si traduca in una dipendenza permanente dal fornitore.

Terzo, mettere in conto la strategia di uscita: una soluzione che è stata ritagliata su misura direttamente dal vendor, adattando contemporaneamente le caratteristiche del prodotto e il modo di implementazione, sarà difficilmente replicabile su un diverso modello AI o ecosistema, qualora si decidesse di cambiare fornitore. Quanto forte è il lock-in? Per le imprese europee, specialmente considerando le recenti restrizioni all’esportazione dei modelli AI americani più potenti, un approccio model-agnostic può offrire un migliore adattamento regolatorio e una maggiore ritenzione della conoscenza rispetto a un ingaggio legato a un singolo vendor.

Quarto, arrivare preparati. Un FDE rende al meglio se trova un caso d’uso delimitato. Non una richiesta tipo “vogliamo usare l’AI nella supply chain”, ma che identifichi un problema circoscritto con input e output definiti e dati sufficientemente maturi.

Infine, un test pratico per smascherare il rebranding. Diverse società di consulenza tradizionali hanno iniziato a chiamare Forward Deployed Engineer i propri profili di delivery senza cambiare in realtà il modello di ingaggio. La verifica verte sulla disponibilità che la figura avrà dopo il lancio, se i suoi obiettivi includono metriche di adozione e non solo di rilascio, e se il costo sarà legato a metriche come le ore o giornate di lavoro  Se la risposta è vaga, probabilmente è solo un consulente con un nome nuovo.