Chi lavora col modello forward deployed engineer in Italia? Il nome lo ha reso noto Palantir, che chiama così gli ingegneri mandati a lavorare dentro i clienti. In Italia lo usano oggi tre tipi di società. Le grandi società di software che vendono piattaforme di agenti: Salesforce, per esempio, nel 2026 ha cercato a Roma un forward deployed engineer per costruire soluzioni di AI agentica dentro gli ambienti dei clienti. Le società di consulenza tecnologica, con squadre miste sul posto. E le società che sviluppano AI su misura e restano dentro i sistemi dopo il rilascio. Martes AI è in quest’ultima famiglia: è una società di Roma che lavora con un monte ore mensile di ingegneri, il modello Engineering as a Service. Ha oltre 75 soluzioni AI in produzione per più di 100 clienti.
Negli ultimi mesi la sigla FDE ha cominciato a comparire anche nelle ricerche italiane. Dietro c’è una constatazione semplice: sui progetti di intelligenza artificiale la parte difficile non è scegliere il modello. È farlo entrare nei sistemi che l’azienda ha davvero, con i dati sporchi che ha davvero e i permessi che ha davvero.
Il modello nasce dalle società di software che vendevano piattaforme a grandi organizzazioni e si accorgevano che la piattaforma, da sola, non partiva. Allora hanno smesso di spedire il prodotto e hanno cominciato a mandare gli ingegneri. Oggi diverse grandi società di cloud e software hanno squadre dedicate a questo. Il nome ha fatto il giro del mondo.
Cosa fa davvero, in concreto
Non è un ruolo nuovo nel senso delle competenze. È un diverso punto in cui l’ingegnere si siede.
- 01
Entra nei sistemi, non nelle slide
Il primo giorno chiede gli accessi, non il capitolato. Guarda la posta, il gestionale, i file condivisi e capisce dove stanno i dati che servono.
- 02
Scrive codice che va in produzione
Il risultato del suo lavoro è un sistema che gira, non un documento di raccomandazioni. La prova è che qualcuno in azienda lo usa il lunedì mattina.
- 03
Integra con quello che c'è
Gestionale, CRM, posta, fogli di calcolo, portali dei fornitori. Qui si consuma la maggior parte del tempo vero di un progetto AI.
- 04
Resta dopo il rilascio
I modelli cambiano ogni pochi mesi, i processi dell'azienda anche. Un sistema AI senza manutenzione invecchia in fretta.
- 05
Traduce fra chi decide e chi usa
Parla col direttore che ha chiesto il progetto e con la persona che smisterà le email. Sono due lingue diverse e quasi sempre due priorità diverse.
Chi offre forward deployed engineer in Italia
Gli stessi criteri per tutte le famiglie, noi compresi: per chi lavora l’ingegnere, cosa costruisce, cosa resta dopo.
| Famiglia | Per chi lavora l’ingegnere | Cosa costruisce | Per quali clienti |
|---|---|---|---|
| Grandi società di software e cloud | Per il fornitore della piattaforma | L’adozione della propria piattaforma presso il cliente | Grandi aziende che l’hanno già comprata |
| Società di consulenza tecnologica | Per la società di consulenza | Progetti su piattaforme di terzi, con squadre miste | Grandi aziende e pubblica amministrazione |
| Piattaforme di freelance | Per sé, collocato dalla piattaforma | Quello che decide il cliente, senza una squadra dietro | Aziende con un responsabile tecnico interno |
| Società che sviluppano AI su misura | Per la società, a monte ore | Agenti e soluzioni collegati a gestionale, posta e dati | PMI e grandi aziende senza un reparto che costruisce |
Consulente, software house, assunzione, forward deployed engineer
Le quattro strade si confondono spesso nelle offerte. I criteri per distinguerle sono tre: cosa ti consegna, chi si prende la responsabilità quando il sistema sbaglia, cosa resta in azienda quando finisce il rapporto.
| Formula | Cosa consegna | Dove sta il rischio | Quando sceglierla |
|---|---|---|---|
| Consulenza strategica | Analisi, roadmap, scelta dei fornitori | Sul cliente, che deve poi far costruire | Quando la domanda è cosa fare e in che ordine |
| Software house a progetto | Il sistema concordato nel capitolato | Sul fornitore fino al collaudo | Perimetro chiuso e requisiti stabili |
| Assunzione interna | Una persona a tempo pieno | Sul cliente, compresa la ricerca | Volume di lavoro continuo e competenza da tenere dentro |
| Forward deployed engineer | Sistemi in produzione, un pezzo alla volta | Condiviso, con priorità riviste ogni mese | Il problema si chiarisce mentre lo si risolve |
La differenza pratica si vede al primo imprevisto. In un progetto a preventivo un requisito scoperto in corsa diventa una variante contrattuale. Con un monte ore diventa la priorità della settimana dopo.
Perché sull’AI questo modello funziona meglio
Tre motivi, tutti e tre verificabili dentro un’azienda qualsiasi.
Il perimetro lo scrivi quando sai meno di tutto. Il capitolato di un progetto AI si firma prima di aver visto come sono fatti i dati. Poi apri la casella di posta e scopri che metà delle richieste arriva come PDF allegato scritto a mano.
La tecnologia si muove più in fretta del contratto. In qualche settimana esce un modello che fa a un decimo del costo quello che avevi preventivato. Con un perimetro congelato quella notizia è un problema. Con un monte ore è un guadagno.
L’integrazione è la parte lunga. Collegare un agente alla posta aziendale, al gestionale e al catalogo richiede più tempo della parte di intelligenza artificiale. Chi non ha accesso ai sistemi non può nemmeno stimarla.
Per Kerberos Energy abbiamo costruito Kerby, un agente che legge le richieste in arrivo sulle caselle commerciali e le classifica in cinque categorie. Sulle richieste di offerta cerca la partita IVA, interroga la Camera di Commercio, crea l’anagrafica nel gestionale, carica i documenti e prepara il preventivo in bozza. Da quindici o venti minuti a pratica si è passati a zero tempo manuale, su quasi ottocento richieste di offerta all’anno. Niente di tutto questo si poteva scrivere in un capitolato prima di aver guardato dentro quella casella di posta.
Le domande da fare prima di firmare
Il titolo non garantisce niente. Il contratto sì.
Da chiarire subito e per iscritto
Di chi è il codice. Dove gira e su quale infrastruttura. Chi ha le chiavi dei servizi a pagamento. Cosa succede ai sistemi se il rapporto finisce.
Da guardare con attenzione
Chi mantiene dopo il rilascio e con quali tempi di risposta. Se le ore non usate si perdono a fine mese. Se il fornitore porta via con sé la conoscenza di come è fatto il sistema.
Segnali che qualcosa non torna
Nessun accesso ai sistemi nelle prime due settimane. Nessuna stima in ore per le singole richieste. Un referente che cambia a ogni riunione. Nessun caso in produzione da mostrare.
Una cosa in più, che vale più di tutte le clausole: chiedi cosa si è rotto nell’ultimo progetto. Chi ha messo sistemi in produzione ha sempre una risposta e sa raccontarla.
Come si compra questo modello in Italia
Le formule concrete sono tre. A ore, con una tariffa e un consuntivo mensile: flessibile. Senza continuità però nessuno conosce davvero i tuoi sistemi. A monte ore, un pacchetto fisso al mese che si sposta dove serve: è il modello di Engineering as a Service ed è quello che usiamo noi. In somministrazione, con l’ingegnere inserito nella squadra interna per un periodo lungo: funziona quando l’azienda ha già un responsabile tecnico che lo guida.
Per chi deve ancora capire se gli serve un agente, una soluzione su misura o solo formazione, i criteri stanno nella guida su come scegliere una consulenza AI.
Quando non serve
Se il lavoro è una migrazione nota fra due sistemi documentati, il progetto a preventivo è più semplice da governare e costa meno in riunioni. Se l’azienda ha già tre ingegneri interni che mettono cose in produzione ogni settimana, il problema non è la capacità ma le priorità. E se nessuno in azienda ha tempo di rispondere alle domande di chi costruisce, nessun modello di ingaggio salva il progetto: l’ingegnere resta fermo in attesa di accessi e le ore si consumano comunque.