In sintesi: La maggior parte dei progetti di IA nelle aziende non fallisce perché il modello è debole. Fallisce nell’ultimo miglio: il collegamento con i sistemi, i dati, i permessi e le persone reali. Questo lavoro non si fa a distanza. Servono ingegneri dentro la vostra organizzazione finché il sistema non funziona nell’operatività quotidiana, e un piano perché se ne vadano.
1. La domanda che un CEO dovrebbe porsi
Guardo l’IA come qualsiasi investimento. Si ripaga? Quando? E di chi è il risultato quando il fornitore se n’è andato?
La maggior parte dei progetti pilota di IA non supera questo test. Non perché la demo fosse scarsa. La demo di solito è la parte facile. Falliscono perché nessuno ha messo a budget il lavoro tra «funziona su un portatile» e «le persone lo usano ogni mattina».
Questo divario ha un nome nel settore. Palantir ci ha costruito il proprio modello anni fa, con ingegneri che lavorano presso ogni cliente per installare e adattare le sue piattaforme. Oggi laboratori di IA come OpenAI e Anthropic assumono per lo stesso ruolo: il forward deployed engineer.
2. Dove si perdono i soldi
L’ultimo miglio non ha niente di affascinante. Sono permessi che nessuno ha documentato. Un campo del CRM che significa tre cose diverse. Un ufficio legale che deve approvare i prompt. Un processo che funziona solo perché una persona conosce le eccezioni.
Niente di tutto questo rientra nel perimetro del pilota. Così il pilota finisce, la slide dice «successo» e il budget per la produzione diventa una nuova trattativa. Passano i mesi. Lo sponsor cambia priorità.
| Cosa presuppone il piano di progetto | Cosa succede davvero nell’ultimo miglio | Chi paga |
|---|---|---|
| I dati sono pronti una volta estratti | Accesso, qualità e significato si negoziano sistema per sistema | Il vostro team, in ritardi |
| L’integrazione è un compito tecnico | È organizzativa: responsabili, approvazioni, sicurezza | Lo sponsor, in credibilità |
| Gli utenti adottano un buon strumento | Gli utenti adottano quello che si adatta a come già lavorano | Il business case |
| Il passaggio di consegne è un documento | Il passaggio di consegne sono persone che l’hanno costruito loro | Voi, a ogni cambiamento |
3. Cosa cambia con ingegneri sul campo
Un forward deployed engineer lavora dove sta il problema. Nei vostri sistemi. Con le vostre persone. Finché non funziona.
Questo cambia tre cose che mi interessano.
- Tempo al valore. La soluzione si costruisce nell’ambiente in cui vivrà, quindi non serve un secondo progetto per «industrializzarla».
- Rischio. Integrazione, permessi e controlli si risolvono nelle prime settimane, non si scoprono dopo il collaudo del contratto.
- Proprietà. Il vostro team costruisce accanto. Quando l’incarico finisce, può gestire e modificare ciò che è stato costruito.
Non è economico a settimana. Il lavoro è senior e operativo. Ma il confronto che conta non è la tariffa settimanale. È il costo fino a un sistema in uso quotidiano. Un progetto più economico che non arriva mai in produzione è l’opzione più cara. Confrontiamo i due modelli nella nostra guida alle decisioni (EN).
4. Come ingaggiarli senza creare dipendenza
I team integrati hanno la loro trappola: possono diventare permanenti. Prima di firmare, chiedete quattro cose.
- Un responsabile con nome e cognome dalla vostra parte, che prenderà in carico il sistema.
- Tutto nei vostri repository dal primo giorno: codice, prompt, set di valutazione e documentazione.
- Successo misurato sull’uso, non sui deliverable: chi lo usa, quanto spesso, con quale risultato.
- Un’uscita con data, con procedure operative e un passaggio di consegne che il vostro team ha provato.
Se un fornitore resiste su uno di questi quattro punti, prendetelo come un segnale.
5. Domande frequenti
D: Che cos’è un forward deployed engineer?
R: Un ingegnere software che lavora dentro l’organizzazione del cliente, sui suoi sistemi e dati, finché una soluzione non funziona in produzione. Il modello è stato reso popolare da Palantir ed è oggi comune nelle aziende di IA.
D: È come affidarsi a una società di consulenza?
R: Non proprio. Un progetto tradizionale viene spesso progettato e realizzato dal team della società e consegnato alla fine. I forward deployed engineer costruiscono nel vostro ambiente, accanto alle vostre persone, e restano finché non funziona.
D: Quanto deve durare un incarico del genere?
R: Il tempo necessario per avere un primo caso d’uso funzionante nell’operatività quotidiana e il vostro team in grado di gestirlo, con un passaggio di consegne datato. L’assenza di una fine prevista è un campanello d’allarme.
D: Quando conviene un modello a progetto?
R: Quando il perimetro è chiaro e autonomo, l’integrazione è leggera e serve un prezzo fisso. Non ogni esigenza di IA richiede ingegneri sul campo.
6. Conclusione
L’IA non crea valore in una demo. Lo crea quando funziona dentro il business, ogni giorno, nelle mani di chi la usa.
È così che lavoriamo in Thinkia: come un’unica squadra con la vostra, dentro i vostri sistemi, con l’uscita pianificata fin dall’inizio. Se avete progetti pilota che non sono mai arrivati in produzione, ecco il nostro approccio (EN).