Per tre anni il dibattito sul perché l'IA non atterra nelle aziende si è chiuso sempre guardando al modello. Che è il contesto, che sono le allucinazioni, che il prossimo sarà quello buono. E il prossimo è arrivato, e ne è arrivato un altro, e il processo della tua azienda si continua a fare a mano. Nel 2026 il mercato ha smesso di fingere che il problema fosse il modello e ha dato un nome a ciò che mancava: una persona.
La tesi in una frase: non devi assumere un forward deployed engineer. Ti serve la funzione che quel ruolo rappresenta, comprata a frazioni e legata a un workflow concreto invece che a una piattaforma. E quella distinzione, che sembra una sfumatura, è la differenza fra bruciare un budget annuale e avere un processo che gira in sei settimane.
Cos'è un forward deployed engineer e perché il nome esplode proprio adesso
Un forward deployed engineer è un ingegnere che lavora dentro il cliente: capisce il processo reale, costruisce la soluzione attaccata ai sistemi che già esistono e non se ne va finché quella cosa non gira in produzione. Metà ingegnere, metà consulente sul campo. Palantir lavora con questa figura da due decenni; la definizione canonica, con responsabilità, competenze e quando NON assumerlo, sta nella scheda di forward deployed AI engineer del nostro catalogo di ruoli, e qui non la ripetiamo.
Quello che vale la pena spiegare è perché il titolo sia esploso adesso, e la risposta ha una data. L'11 maggio 2026 OpenAI ha annunciato la OpenAI Deployment Company, un'unità di business indipendente creata, parole loro, per poter sviluppare il modello operativo, il ritmo e il focus sul cliente che questo lavoro richiede. La sua funzione dichiarata è incastrare forward deployed engineers in organizzazioni che risolvono problemi complessi in contesti esigenti. E per non partire da zero, nello stesso annuncio ha concordato l'acquisto di Tomoro, una società di consulenza di IA applicata che porta circa 150 FDE e specialisti di deployment dal primo giorno. Fonte: OpenAI launches the OpenAI Deployment Company, OpenAI, 11 maggio 2026.
Rileggilo, perché è una confessione. L'azienda che fabbrica il modello più venduto al mondo ha deciso che, perché il suo prodotto funzioni dentro un'azienda, bisogna montare un'altra azienda e comprare centocinquanta persone. Il collo di bottiglia ha smesso di essere l'intelligenza. È l'atterraggio.
Cosa il ruolo non è, e perché la confusione ti costa soldi
Oggi tre profili si vendono con lo stesso discorso e fanno cose diverse. Distinguerli è ciò che evita di comprare quello sbagliato:
- Non è un consulente. Il consulente consegna un documento con quello che dovresti fare. L'FDE consegna il processo fatto. Se alla fine dell'incarico quello che hai in mano è una presentazione, hai comprato consulenza con un nome nuovo.
- Non è un AI engineer. L'AI engineer costruisce il sistema; l'FDE costruisce il sistema e scopre qual era il problema, che è la parte che nessuno ha scritto da nessuna parte e quella che si mangia il 70% del calendario.
- Non è customer success. Customer success si assicura che tu usi quello che hai comprato. L'FDE cambia quello che hai comprato finché non combacia con come lavora davvero la tua gente, non con come dice il manuale che lavora.
La prova del nove è una domanda sola: questa persona scriverà codice contro i miei sistemi, o scriverà sui miei sistemi? Tutto il resto sono titoli.
Il problema: il formato enterprise non è fatto per te
Qui arriva la parte scomoda. Il ruolo è reale, è quello che funziona, e il modo in cui viene venduto è disegnato per l'altro capo del mercato. La versione enterprise è un team dedicato per mesi, incastrato nell'organizzazione, con un impegno pluriennale e —quasi sempre— legato alla piattaforma di chi lo dispiega. Funziona. E un'azienda da 50 a 500 persone non può comprarlo per due motivi diversi che conviene non mescolare.
Il primo è ovvio: il prezzo. Il secondo lo è meno ed è peggio. Anche se potessi pagarlo, non hai lavoro sufficiente per una posizione a tempo pieno, e un FDE senza una coda di problemi diventa un dipendente caro che aspetta. Il bisogno della tua azienda non è continuo: è intenso per sei o otto settimane per processo, e poi scende a manutenzione. Mettere in organico una domanda che ha quella forma è esattamente l'errore che ripeti da anni con altri profili.
E c'è un terzo motivo, silenzioso, che compare solo l'anno dopo: il legame con la piattaforma. Se chi si incastra nella tua operazione guadagna sul consumo del proprio prodotto, la soluzione che disegnerà girerà sul suo prodotto. Non per malafede —per gravità. È la stessa trappola spiegata in piattaforme per creare agenti IA: il costo di uscita non si paga quando firmi, si paga al mese 7.
Non ti serve la posizione, ti serve la funzione
L'uscita non è rinunciare al ruolo. È comprarlo con un'altra forma: a frazioni, per workflow e con una fine scritta. Invece di un ingegnere incastrato a tempo indeterminato, un incarico circoscritto a un processo —quello che fa più male— con una data in cui quel processo gira da solo e una persona di casa tua che resta come proprietario.
La differenza pratica è che l'oggetto dell'acquisto smette di essere il tempo di una persona e diventa un processo in produzione. Cambia chi si prende il rischio. Se il progetto si allunga, nel modello a ore paghi di più; nel modello a risultato, no. È la stessa logica che applichiamo quando montiamo agenti IA per le aziende, ed è il motivo per cui la prima conversazione è sempre sul processo e mai sul modello.
Il lavoro vero, poi, somiglia pochissimo a quello che promette la demo. La maggior parte del calendario se ne va a collegare l'IA ai sistemi che hai già —l'ERP del 2011, il CRM con campi che nessuno ricorda a cosa servano, l'Excel che in realtà è il database dell'azienda— e a scoprire che il processo documentato e il processo reale non si somigliano. Questo non lo risolve un modello migliore. Lo risolve qualcuno seduto lì.
Le tre cose da pretendere per iscritto prima di firmare
Non importa chi assumi —grande fornitore, boutique, freelance, noi—. Se queste tre non sono scritte prima di cominciare, quello che hai comprato è tempo, non risultato:
- Quale processo resta in produzione, con nome e cognome. Non «capacità di IA nell'area commerciale». Il nome del processo, con il suo innesco e la sua uscita: «la classificazione e la risposta iniziale delle email che arrivano al supporto». Se non sta in una frase, non è circoscritto.
- Come si misura, con il numero di oggi. L'indicatore e il suo valore attuale, presi prima di cominciare. Senza la linea di base, fra tre mesi la discussione su se abbia funzionato è una discussione di opinioni, e quella la vince sempre chi fattura.
- Chi lo opera quando chi è venuto se ne va. Nome e cognome dalla tua parte, formato durante l'incarico e non nell'ultima settimana. È quella che si salta più spesso ed è l'unica che decide se il sistema sarà ancora vivo l'anno prossimo.
La terza merita un paragrafo a parte, perché è lì che muore la maggior parte dei deployment tecnicamente riusciti. Un processo automatizzato senza proprietario interno non si rompe il primo mese: si rompe il giorno in cui cambia una regola di business e nessuno sa dove si mette mano. È tutto il problema di chi mantiene gli agenti IA, e non si risolve con la documentazione: si risolve con una persona che era lì davanti mentre si costruiva.
Cosa conferma questo nome nuovo
Che il mercato si inventi un titolo e monti un'unità di business per sostenerlo non è una moda di nomenclatura: è l'ammissione pubblica che il software da solo non si installa. Se il produttore del modello ha bisogno di centocinquanta persone incastrate dentro i suoi clienti perché il suo prodotto renda, la domanda da fare al tuo fornitore di IA smette di essere quale modello usa e diventa chi si siede con te e fino a quando.
Noi portiamo avanti quel modello dall'inizio, senza il titolo: dipendenti IA che consegnano un processo funzionante, con un proprietario interno e con la metrica scritta prima di cominciare. Se vuoi il vocabolario in ordine prima di quella conversazione, sta nel glossario di AI Operations. L'IA non si presenta. Si implementa —e qualcuno deve essere lì il giorno in cui si rompe.