L'intelligenza dei modelli è diventata una commodity: quello che manca è farla funzionare dentro sistemi legacy, processi mai scritti e team reali. Per questo in Datapizza strategia ed esecuzione entrano dal cliente insieme, con due figure: il Forward Deployed Engineer e il Deployment Strategist. E le stiamo cercando entrambe.

Da ottobre 2025 lavoriamo tutti con una consapevolezza nuova: i modelli hanno superato la soglia di sustained correctness - cioè la capacità di mantenere l'accuratezza fattuale o funzionale nel tempo, piuttosto che solo in un singolo punto di esecuzione o di verifica iniziale.

In sostanza, i modelli riescono a tenere catene di ragionamento lunghe senza degradare: gli agenti, finalmente, non sono più giocattoli.

La tua azienda se n'è accorta? Probabilmente sì, ma a metà.

Ha capito che il problema si è spostato: non è più "il modello è abbastanza intelligente?", è "riesco a farlo funzionare dentro i miei sistemi, sui miei processi, con le mie persone?".

L'intelligenza è diventata una commodity.

Quello che scarseggia è il lavoro sporco di farla atterrare in un'azienda vera, con trent'anni di sistemi legacy e un ERP che nessuno vuole toccare.

Oggi le aziende hanno una voglia di usare l'AI e di capire cosa farne. Ma manca una componente fondamentale: mettere a terra le cose, cambiare la quotidianità delle persone, vedere un impatto vero sui conti.

Il motivo è che la trasformazione AI ha bisogno di tre pezzi insieme, dosati bene - strategia, esecuzione e tecnologia.

Devi capire dove intervenire. Devi avere gli strumenti per farlo davvero. Devi riuscire a far entrare il cambiamento nel lavoro di tutti i giorni, non solo in una demo che il management applaude e poi nessuno usa più.

Se te ne manca uno, gli altri due non contano niente - anzi, hai speso soldi e tempo a scoprirlo sul campo.

Puoi avere la piattaforma più bella del mercato, gli ingegneri più bravi e il modello più intelligente disponibile.

Ma se hai capito tardi con chi dovevi lavorare e quale problema dovevi davvero risolvere, torni comunque indietro.

Il mercato ha due risposte pronte, e le conosciamo bene.

La prima è il software: compri una piattaforma, il tuo team IT la integra in qualche settimana, e da lì in poi ognuno per sé.

Funziona benissimo quando il problema è standard. Funziona malissimo quando il problema sono i tuoi sistemi stratificati in trent'anni, i tuoi vincoli di compliance, i processi che nessuno ha mai scritto perché "tanto lo sappiamo tutti come si fa".

La seconda risposta è la consulenza: qualcuno arriva, studia il processo, e fa una roadmap con analisi e raccomandazioni.

Ma qui il problema: in consulenza, analisi ed esecuzione restano quasi sempre affidate a team diversi, in fasi diverse dello stesso progetto.

C'è chi fa la discovery e scrive la roadmap, e poi c'è un team di delivery - interno alla stessa società o esternalizzato - che la deve costruire davvero.

La roadmap passa da chi l'ha pensata a chi dovrà eseguirla. Ma chi l'ha scritta non ha mai provato a costruire l'agente che dovrebbe reggere quella raccomandazione - e chi lo costruisce scopre, spesso solo in produzione, che l'ipotesi non teneva.

Prese separatamente, software e consulenza coprono metà del problema ciascuno. Messe insieme, restano comunque due metà. Non si parlano tra loro, e nel mezzo ci sei tu che devi far funzionare qualcosa lunedì mattina.

Ed è qui che nascono le due figure di cui ti voglio parlare.

In Datapizza, infatti, proviamo a fondere queste due cose invece di sommarle: la formula non è "consulenti + piattaforma", ma un modello dove chi decide la strategia e chi scrive il codice sono nella stessa stanza fin dal primo giorno.

Cos'è il Forward Deployed AI Engineer

Eredita l'idea da Palantir - ne abbiamo parlato in una guida su LinkedIn e in questa puntata di Commit - e ci aggiunge un pezzo: non porta in produzione un prodotto già scritto da altri, ma

• mappa i sistemi - dove vivono i dati, che vincoli di sicurezza e compliance ci sono, chi ha in mano cosa
• costruisce l'infrastruttura e gli agenti che servono a quel cliente specifico
• accompagna l'adozione finché il team interno non è autonomo

L'FDE entra in azienda e concretamente fa questo:

• installa la piattaforma dentro il perimetro del cliente - niente dati che escono, ogni operazione tracciata e verificabile (la Glass Box Architecture, un requisito dell'AI Act)
• collega i sistemi di record - CRM, DMS, ERP
• costruisce workflow agentici insieme a chi oggi fa quel lavoro a mano, definendo con loro gli eval set - i casi su cui il workflow deve reggere prima di andare in produzione - e mettendo lo human-in-the-loop dove serve
• e, prima di chiudere, forma il team IT del cliente perché il secondo e il terzo workflow li costruiscano senza di lui.

Il mix di competenze, se vuoi un numero: 40% software, 30% capacità di ragionare sul business, 30% AI applicata.

Cos'è il Deployment Strategist

E poi c'è il nostro nuovo ruolo, il Deployment Strategist, che invece nasce da un problema molto più recente e molto più attuale: se strategia ed esecuzione restano in mani diverse, la roadmap si rompe nel passaggio.

Il DS esiste per tenere quel passaggio chiuso.

Se l'FDE risponde a "come lo costruiamo", il DS risponde alla domanda prima: "cosa costruiamo, per chi, e perché conta davvero".

Il suo lavoro centrale è mappare gli stakeholder - chi ha comprato il progetto, chi lo userà ogni giorno, chi ne giudicherà la qualità, chi può sbloccare dati e accessi (quasi sempre persone diverse, con incentivi diversi) e ridisegnare il processo in ottica AI-native.

Insieme all'FDE costruisce i criteri di evaluation - cosa deve contenere un output, quali casi difficili vanno coperti, quando l'agente deve fermarsi invece di rispondere - e li porta agli esperti del cliente perché siano loro a validarli.

Serve un background tecnico solido (SQL, Python, la capacità di esplorare un dato in autonomia), ma non è lui a scrivere il codice di produzione: la sua responsabilità è capire se una soluzione è abbastanza robusta per andare live, e tenere il cliente dentro quella decisione.

(anche del DS abbiamo dedicato una guida su LinkedIn!)

In pratica: un Deployment Strategist e un Forward Deployed Engineer entrano insieme dal cliente, fin dalle prime conversazioni di discovery.

E mentre il DS guida la comprensione del problema - dove intervenire, con chi, cosa conta davvero per il business - l'FDE ha in mano la piattaforma e costruisce in parallelo.

Non c'è un passaggio di consegne, perché non c'è una separazione: la strategia si scrive sapendo cosa si può realizzare, e si aggiorna con quello che si impara realizzandolo.

Ok, ma perché dovrebbe funzionare meglio?

Perché elimina il punto in cui la roadmap tradizionalmente si rompe: qui chi l'ha pensata resta, e continua a risponderne mentre la soluzione entra nel lavoro vero delle persone.

Se un'ipotesi non regge al primo prototipo, non è un problema che scopri tre mesi dopo in un report: lo scopri martedì, e mercoledì cambi rotta.

Il risultato non è un software consegnato né una slide con su scritto "roadmap". È un'azienda che fa succedere la trasformazione mentre la progetta.

E Datapizza sta cercando entrambe le figure!

Sei un/una perfetto/a Forward Deployed Engineer se

• ti piace scrivere codice ma ti annoia farlo isolato da chi userà quello che costruisci
• hai già fatto consulenza tecnica ibrida - mani in pasta, non solo slide - e la parte che ti mancava era proprio stare dentro il problema del cliente
• leggendo com'è fatta una settimana nella guida su LinkedIn da FDE hai pensato "difficile ma eccitante"

Se invece hai pensato "troppo ampio, preferisco fare una cosa sola", in Datapizza ci sono ruoli più verticali che vale la pena guardare.

Sei un/una perfetto/a Deployment Strategist se sei abituato/a ad aggredire la realtà invece di aspettare che si sistemi da sola.

Il background conta meno del previsto - consulenza, prodotto, dati, ingegneria, anche aver fondato qualcosa.

Quello che conta è aver già affrontato un problema poco definito e seguito le conseguenze delle tue scelte fino in fondo.

Serve un solido strato tecnico (SQL, Python, capacità di muoverti da solo in un dataset), ma soprattutto serve saper scomporre una situazione confusa: qual è il problema tecnico, quale decisione manca, chi ha interesse a cambiare e chi rischia di perderci.

In entrambi i casi, una cosa non è negoziabile: se una cosa è una cavolata, la diciamo al cliente e a noi stessi.

Non stiamo cercando chi allunga i progetti, stiamo cercando chi vuole creare valore, far accadere la trasformazione AI e rendere l’Italia competitiva nell’era dell’AI.

Giacomo Ciarlini - CIO - Datapizza

Simone Conversano - AI Transformation & Marketing Specialist - Datapizza