Forward Deployed Engineering, perché le big tech mandano gli ingegneri dentro le aziende

In meno di due mesi, quattro protagonisti dell’intelligenza artificiale hanno annunciato iniziative costruite attorno alla stessa intuizione: per trasformare una demo in un sistema che produce risultati economici non basta fornire un modello o una piattaforma cloud. Servono ingegneri capaci di lavorare direttamente con il cliente, integrare dati e applicazioni esistenti, ridisegnare i processi e assumersi responsabilità sull’arrivo in produzione.

Anthropic e OpenAI si sono mosse a maggio 2026. AWS ha seguito il 30 giugno con un investimento da 1 miliardo di dollari; Microsoft ha annunciato il 2 luglio Microsoft Frontier Company, sostenuta da 2,5 miliardi e circa 6.000 tra ingegneri ed esperti di settore. Sommando anche il capitale iniziale delle iniziative di Anthropic e OpenAI si superano i 9 miliardi di dollari. Non si tratta di risorse tutte destinate direttamente agli stipendi degli ingegneri, né di quattro organizzazioni identiche dal punto di vista societario. Ma la direzione industriale è comune: il deployment è diventato uno dei principali colli di bottiglia dell’AI aziendale.

Che cos’è un Forward Deployed Engineer

Il Forward Deployed Engineer, o FDE, non nasce con l’AI generativa. Il ruolo è stato sviluppato e reso popolare da Palantir oltre dieci anni fa, inizialmente in progetti per organizzazioni governative, della difesa e grandi imprese con ambienti tecnologici complessi.

L’idea è portare l’ingegnere vicino al problema operativo. Invece di partire da una roadmap astratta, l’FDE lavora con responsabili di business, sviluppatori, sicurezza e infrastrutture del cliente. Analizza dati e processi reali, costruisce software, lo testa nelle condizioni effettive di utilizzo e segue il passaggio in produzione.

Nell’AI enterprise questo ruolo comprende normalmente attività molto diverse: selezione dei casi d’uso, integrazione con dati e sistemi legacy, costruzione di agenti e strumenti di valutazione, definizione delle autorizzazioni, monitoraggio degli output, gestione delle eccezioni e formazione del team interno. È proprio questa combinazione di capacità tecniche e comprensione del contesto organizzativo a rendere gli FDE difficili da trovare e costosi da impiegare su larga scala.

FDE, consulente o solutions architect?

La sovrapposizione con consulenti tecnologici, professional services e solutions architect è ampia. Presentare queste figure come categorie completamente separate sarebbe fuorviante: molte società di consulenza sviluppano software destinato alla produzione, mentre diversi solutions architect accompagnano il cliente ben oltre il disegno iniziale dell’architettura.

La differenza è soprattutto nel modo in cui il ruolo viene organizzato. Un Forward Deployed Engineer accompagna infatti l’intero ciclo del progetto: individua insieme al cliente il problema operativo da risolvere, sviluppa e porta in produzione il sistema nell’ambiente reale e riporta ai team di prodotto del vendor le conoscenze maturate durante il deployment, contribuendo all’evoluzione della piattaforma stessa. Quest’ultimo punto è particolarmente importante. Il lavoro sul campo diventa un ciclo di feedback per il fornitore: i problemi ricorrenti, gli strumenti di valutazione e i pattern di integrazione possono essere trasformati in funzioni riutilizzabili della piattaforma. OpenAI descrive esplicitamente questo ciclo come “build, prove, generalize”: costruire per un caso concreto, dimostrarne il valore e generalizzare ciò che può diventare prodotto.

Il confine con la consulenza rimane quindi poroso. “Forward Deployed Engineer” identifica meno una professione completamente nuova che un diverso equilibrio tra sviluppo, delivery e prodotto. Anche proprietà del codice, responsabilità operativa, riuso dei componenti e trasferimento della conoscenza dipendono dal contratto: non sono conseguenze automatiche del titolo professionale.

Perché il modello torna centrale proprio ora

La domanda di FDE cresce perché l’adozione dell’AI corre molto più velocemente della capacità delle aziende di trasformarla in risultati misurabili.

Il rapporto The GenAI Divide del progetto NANDA del MIT, pubblicato nel 2025, ha rilevato che la grande maggioranza dei progetti pilota esaminati non aveva prodotto un impatto misurabile sul conto economico. Il dato, spesso sintetizzato come “il 95% dei pilot fallisce”, richiede cautela: misura l’impatto P&L, non il successo tecnico o l’utilità percepita dagli utenti.

Un’analisi McKinsey dell’aprile 2026, basata sul precedente State of AI 2025, indica che quasi nove organizzazioni su dieci utilizzano l’AI in almeno una funzione, ma il 94% dei rispondenti non vede ancora un valore “significativo” a livello aziendale. Un’indagine RAND del 2024, più ampia e non limitata all’AI generativa, ricorda inoltre che secondo alcune stime oltre l’80% dei progetti AI non raggiunge gli obiettivi, circa il doppio rispetto ai progetti IT senza AI.

Sono misurazioni diverse e non vanno sommate o trattate come equivalenti. Convergono però su un punto: la disponibilità di modelli più potenti non risolve da sola problemi come qualità e accessibilità dei dati, integrazione con applicazioni legacy, ridisegno dei workflow, sicurezza e gestione del cambiamento.

Quattro iniziative, non un unico modello societario

Anthropic e OpenAI

A maggio 2026, Anthropic ha partecipato con Blackstone, Hellman & Friedman, Goldman Sachs e altri investitori alla creazione di una società di servizi AI rivolta in particolare alle medie imprese. La nuova realtà è stata dotata di circa 1,5 miliardi di dollari di capitale impegnato. Anthropic risulta avere una partecipazione di minoranza: il modello è quindi quello di una joint venture sostenuta da investitori finanziari e collegata alla diffusione di Claude nelle aziende partecipate.

Pochi giorni dopo, OpenAI ha annunciato OpenAI Deployment Company. La società, controllata a maggioranza da OpenAI e sostenuta da 19 partner finanziari, società di consulenza e system integrator, parte con oltre 4 miliardi di dollari di capitale iniziale. Contestualmente OpenAI ha concordato l’acquisizione di Tomoro, società specializzata nell’AI applicata, dalla quale dovrebbero arrivare circa 150 FDE e deployment specialist dopo il completamento dell’operazione.

OpenAI disponeva già di un’attività di Forward Deployed Engineering e presenta come casi di riferimento il lavoro svolto con organizzazioni come BBVA e John Deere. Deployment Company amplia questo approccio, combinando capacità tecniche, capitale e accesso alle aziende presenti nei portafogli degli investitori.

AWS

Il 30 giugno AWS ha annunciato una propria organizzazione interna di Forward Deployed Engineering, sostenuta da un investimento iniziale di 1 miliardo di dollari e guidata da Francessca Vasquez, vicepresidente Frontier AI Engineering and Services.

AWS prevede migliaia di professionisti e ingaggi organizzati in piccoli pod. Reuters ha riferito di periodi iniziali di circa 45 giorni. L’azienda non descrive questi interventi come consulenza fatturata semplicemente a ore, ma come progetti costruiti intorno a obiettivi condivisi e risultati di business.

La metodologia utilizzata è l’AI-Driven Development Lifecycle di AWS. Nella fase di Inception vengono definiti requisiti, contesto e architettura; nella Construction gli agenti generano codice, test e configurazioni sotto revisione umana; nella fase Operations automazione e agenti assistono deployment, monitoraggio e gestione degli incidenti. Il principio dichiarato è lasciare al cliente sistemi, documentazione, runbook e competenze sufficienti per operare in autonomia.

Allen Institute, Cox Automotive, NBA, NFL, Ricoh e Southwest Airlines figurano tra le organizzazioni che AWS indica come già coinvolte con i team FDE.

Microsoft

Il 2 luglio Microsoft ha presentato Microsoft Frontier Company, una nuova unità operativa alla quale destina 2,5 miliardi di dollari e più di 6.000 tra esperti di settore e ingegneri. La guida è stata affidata a Rodrigo Kede Lima.

Microsoft sostiene che l’iniziativa vada oltre il modello FDE tradizionale, integrando ingegneria, competenze di settore, change management e miglioramento continuo. Tra i clienti citati compaiono LSEG, Land O’Lakes, Unilever e Novo Nordisk. Accenture, Capgemini, EY, KPMG e PwC fanno parte dell’ecosistema di delivery.

Un elemento centrale della proposta è l’apertura a modelli diversi: OpenAI, Anthropic, Microsoft, open source e modelli verticali. Microsoft dichiara inoltre che dati, proprietà intellettuale e conoscenza distintiva del cliente non saranno usati per addestrare modelli in modi che ne riducano il valore competitivo. Questa promessa non elimina il rischio di lock-in, perché l’architettura può comunque dipendere da Azure e dagli strumenti di gestione Microsoft, ma sposta la competizione dal singolo modello alla piattaforma che governa l’intero sistema.

Anche Google Cloud segue la stessa direzione

La tendenza non riguarda soltanto i quattro investimenti considerati. Già il 22 aprile Google Cloud aveva annunciato un fondo da 750 milioni di dollari per accelerare lo sviluppo e il deployment di AI agentica attraverso il proprio ecosistema di partner. Il piano comprende FDE Google affiancati ai team di Accenture, Capgemini, Cognizant, Deloitte, HCLTech, PwC e TCS.

È un’ulteriore conferma che il Forward Deployed Engineering sta diventando una componente del go-to-market dei principali fornitori cloud e AI, non un’iniziativa isolata.

Perché conviene alle big tech

La crescita degli FDE risponde a diversi interessi industriali. La motivazione più immediata è economica. Un progetto che resta in fase pilota consuma poche API e poca infrastruttura; un sistema integrato nei processi aziendali genera invece utilizzo continuativo di modelli, cloud, database, sicurezza e strumenti di osservabilità. Anche quando il deployment è un servizio pagato dal cliente, per il vendor può funzionare come investimento nell’espansione futura dell’account.

La posta in gioco, tuttavia, non si esaurisce nei consumi. Chi aiuta il cliente a organizzare dati, agenti, identità, valutazioni e monitoraggio finisce per influenzarne anche le successive scelte tecnologiche. La relazione diventa così molto più profonda di quella costruita con una semplice licenza software.

Il lavoro sul campo agisce inoltre come un sensore per lo sviluppo del prodotto. Gli FDE osservano dove i modelli falliscono, quali integrazioni si ripetono e quali controlli mancano. Queste informazioni possono tornare ai team centrali e trasformarsi in funzioni scalabili.

Resta infine il controllo della relazione commerciale. Nel software enterprise, società di consulenza e system integrator hanno storicamente gestito gran parte dell’implementazione. Portare propri ingegneri sul campo consente ai vendor tecnologici di partecipare direttamente alle decisioni operative, senza delegare completamente l’ultimo miglio.

La conseguenza è anche un potenziale conflitto di interessi: chi vende il modello o il cloud partecipa alla scelta dell’architettura che determinerà il consumo futuro di quello stesso modello o cloud. La neutralità dichiarata rispetto ai modelli non coincide necessariamente con una piena neutralità infrastrutturale.

Che cosa cambia per consulenti e system integrator

Gli annunci non indicano la scomparsa dei system integrator. Al contrario, il modello prevalente è la co-delivery.

Microsoft lavorerà con i principali global system integrator. AWS ha previsto team FDE dedicati anche presso partner selezionati, con una metodologia e una soglia tecnica definite dal vendor. Google Cloud incorpora i propri ingegneri nei programmi gestiti insieme alle grandi società di consulenza.

La vera tensione riguarda chi controlla il rapporto con il cliente e chi conserva la conoscenza accumulata durante il progetto. Se il vendor guida architettura e sviluppo, il system integrator rischia di diventare un fornitore di capacità aggiuntiva. Se invece è il partner a possedere il contesto di settore, gli strumenti di valutazione e i componenti riutilizzabili, può conservare un ruolo centrale anche quando il modello sottostante cambia.

Per l’azienda cliente il problema non è scegliere tra vendor e consulente, ma progettare un equilibrio che eviti dipendenze unilaterali. Il team dovrebbe capire quali componenti rimangono al cliente, quali al partner e quali al fornitore della piattaforma.

I benefici per l’impresa

Il vantaggio più immediato è la velocità. Un piccolo gruppo con accesso diretto agli esperti di prodotto può risolvere problemi che, distribuiti tra funzioni diverse, richiederebbero mesi di passaggi e approvazioni.

La velocità avrebbe però poco valore se il risultato restasse una dimostrazione. Un sistema AI aziendale deve gestire autenticazione, autorizzazioni, dati incompleti, errori del modello, monitoraggio, audit e rollback. Gli FDE vengono impiegati proprio per affrontare questi vincoli nel contesto reale e ridurre la distanza tra prototipo e produzione.

Un ingaggio ben costruito può produrre anche apprendimento interno. Gli ingegneri del cliente passano da osservatori a co-autori e infine a operatori autonomi. Il risultato non dovrebbe essere soltanto un’applicazione, ma anche documentazione, strumenti di valutazione e capacità di manutenzione.

Va però distinta la promessa dalla prova. Le iniziative annunciate nel 2026 sono troppo recenti per consentire una valutazione indipendente dei risultati su larga scala. Molti esempi disponibili sono casi selezionati e raccontati dagli stessi fornitori. La velocità dichiarata e l’autonomia finale del cliente devono quindi diventare metriche contrattuali, non semplici affermazioni di marketing.

I rischi da governare

Il rischio più evidente è il lock-in tecnologico. Un sistema costruito su servizi proprietari, identità, database e strumenti di osservabilità di un singolo cloud può essere formalmente compatibile con modelli diversi e, allo stesso tempo, molto costoso da spostare.

A questa dipendenza infrastrutturale se ne aggiunge una meno visibile: quella della conoscenza. Se decisioni, eccezioni e logiche operative restano nella memoria degli ingegneri esterni, l’azienda continua a dipendere dal vendor anche quando possiede formalmente il codice.

C’è poi il tema del debito tecnico. Un numero crescente di FDE può segnalare una forte domanda, ma anche un prodotto che richiede personalizzazioni continue. Per il cliente, la domanda decisiva è se l’ingaggio stia trasformando problemi ricorrenti in componenti riutilizzabili oppure accumulando software su misura difficile da mantenere.

La prossimità ai sistemi del cliente apre infine una questione di sicurezza. Gli FDE possono entrare in contatto con dati personali, segreti commerciali, credenziali e ambienti di produzione. Identità nominative, privilegi minimi, segregazione degli ambienti, registrazione delle attività e procedure chiare di revoca degli accessi diventano quindi condizioni essenziali dell’ingaggio.

GDPR e AI Act: le responsabilità non scompaiono con l’outsourcing

Quando il progetto tratta dati personali, il primo passaggio è definire correttamente i ruoli GDPR. L’impresa cliente sarà spesso titolare del trattamento e il vendor responsabile, ma non è una regola automatica: la qualificazione dipende da chi determina finalità e mezzi essenziali del trattamento. Se il fornitore opera come responsabile, il contratto previsto dall’articolo 28 deve coprire esplicitamente anche l’attività degli ingegneri embedded e gli eventuali sub-responsabili.

Per i trattamenti che possono produrre un rischio elevato per le persone può inoltre essere necessaria una valutazione d’impatto sulla protezione dei dati, prevista dall’articolo 35 del GDPR (Data Protection Impact Assessment, DPIA). La valutazione deve precedere l’entrata in produzione e includere l’intero sistema: modello, fonti dati, strumenti utilizzabili dagli agenti, intervento umano e conseguenze degli errori. Sul fronte dell’AI Act, la tempistica richiede attenzione. Il regolamento è entrato in vigore il 1° agosto 2024. I divieti e gli obblighi di alfabetizzazione AI sono applicabili dal febbraio 2025; gli obblighi per i modelli general purpose hanno iniziato ad applicarsi nell’agosto 2025, mentre varie regole di trasparenza si applicano dall’agosto 2026.

Per i sistemi ad alto rischio, il calendario è stato modificato nel quadro dell’AI Omnibus. Secondo l’accordo politico raggiunto nel maggio 2026 e la tempistica pubblicata dalla Commissione europea, le regole per aree come biometria, infrastrutture critiche, istruzione, occupazione, migrazione e controllo delle frontiere si applicheranno dal 2 dicembre 2027; per i sistemi incorporati in prodotti regolamentati, dal 2 agosto 2028. Poiché l’iter di semplificazione è ancora recente, le date devono essere ricontrollate al momento dell’avvio di ciascun progetto.

Anche la distribuzione delle responsabilità è più articolata di quanto suggerisca la semplice distinzione tra cliente e fornitore. L’AI Act assegna obblighi differenti a provider e deployer. Un’impresa che utilizza il sistema deve garantirne uso corretto, monitoraggio e sorveglianza umana; chi sviluppa o commercializza un sistema ad alto rischio deve invece rispettare gli obblighi previsti per il provider. Un cliente o integratore che appone il proprio nome sul sistema o lo modifica sostanzialmente può, in determinate circostanze, assumere a sua volta il ruolo di provider.

Non ogni chatbot o sistema di assistenza clienti è automaticamente ad alto rischio. Le categorie dipendono dalla finalità e dall’effetto sulle persone: selezione del personale e valutazione del merito creditizio sono esempi tipici; un chatbot di assistenza ordinaria è normalmente soggetto soprattutto agli obblighi di trasparenza, salvo che partecipi a decisioni ricadenti in una categoria regolata.

Una fase di transizione o il nuovo modello del software enterprise?

La crescita del Forward Deployed Engineering può essere interpretata in due modi.

Da un lato, gli FDE rappresentano una risposta alla fase attuale dell’intelligenza artificiale enterprise. Modelli, agenti e infrastrutture evolvono con una rapidità tale che molte organizzazioni non riescono ancora a sviluppare internamente tutte le competenze necessarie. Portare sul campo ingegneri con esperienza diretta consente di accelerare il deployment e di ridurre la distanza tra sperimentazione e produzione.

Dall’altro, un ricorso sempre più esteso a team dedicati può anche evidenziare i limiti delle piattaforme attuali. Se ogni progetto richiede un numero elevato di personalizzazioni e competenze specialistiche, la scalabilità del modello diventa più difficile e aumenta il rischio di creare una dipendenza permanente dal fornitore.

La differenza tra questi due scenari dipenderà dall’evoluzione delle piattaforme. Un’organizzazione di Forward Deployed Engineering efficace dovrebbe trasformare progressivamente i problemi affrontati sul campo in funzionalità, strumenti e pattern riutilizzabili, riducendo nel tempo la necessità di interventi personalizzati. Se invece organico, durata degli ingaggi e sviluppo su misura continuassero a crescere senza aumentare l’autonomia del cliente, il deployment rischierebbe di trasformarsi in un servizio permanente anziché in un acceleratore dell’adozione.

La novità, in ogni caso, non è che gli ingegneri lavorino presso i clienti: consulenti, system integrator e professional services lo fanno da decenni. A cambiare è il ruolo che i principali fornitori di modelli e cloud attribuiscono a queste competenze. L’ingegneria sul campo diventa parte integrante della strategia di prodotto e del vantaggio competitivo.

Nel software enterprise, la competizione non si giocherà soltanto sulla qualità dei modelli o sui benchmark. Si giocherà soprattutto sulla capacità di trasformare rapidamente quei modelli in sistemi affidabili, governabili e realmente utilizzati dalle imprese. È su questo terreno che Microsoft, AWS, OpenAI, Anthropic e Google Cloud stanno concentrando investimenti miliardari.