Un partner per l’implementazione AI
che vende giudizio, non ore-uomo.
Ogni fornitore di ingegneria embedded offre la stessa cosa: ingegneri senior nel tuo repository, a partire dalla settimana prossima. È una risposta di staffing a un problema di giudizio. Noi lavoriamo accanto a chi fa il lavoro per decidere quali parti devono diventare un modello, quali normale codice e quali restare in mano a una persona. Di solito, la maggior parte del sistema non dovrebbe essere AI.
- Cinque deliverable con un nome, non un numero di persone
- Costruito sopra il tuo gestionale. Mai una migrazione.
- Prima la mappatura, a pagamento: così il preventivo di sviluppo è un risultato, non una stima a occhio
Sprint di Mappatura Operativa di cinque giorni · Primo flusso operativo in 6 settimane · Europa
Un team di ingegneri
Ingegneri senior inseriti nel tuo repository. Partenza in sette giorni. Da quattro a otto settimane per il rilascio. Prezzo per ingegnere al mese. Cosa costruire lo decidi ancora tu, e il rischio di costruire la cosa sbagliata resta tuo.
La decisione su dove serve l’AI
Percorriamo il processo reale insieme a chi lo gestisce, troviamo le eccezioni che nessuno ha documentato e tracciamo il confine tra ciò che deve essere un modello, ciò che deve essere codice e ciò che deve restare umano. Poi costruiamo la piccola parte che va davvero costruita.
Le piattaforme lo hanno già ammesso.
Il modello del forward deployed engineer nasce in Palantir, e i laboratori di AI lo hanno adottato: OpenAI e Anthropic hanno entrambe unità di forward deployed engineering. A giugno 2026 AWS ha annunciato un investimento da 1 miliardo di dollari per affiancare ai clienti forward deployed engineer specializzati in AI, parlando di migliaia di esperti al lavoro negli ambienti dei clienti e dell’autonomia del cliente come condizione di uscita.
Se le aziende il cui intero business è il modello spendono un miliardo di dollari per inserire ingegneri nei team dei clienti, il collo di bottiglia non è il modello. Sono i tuoi dati, i percorsi delle eccezioni, le catene di approvazione e i tre sistemi che non hanno un’API. Niente di tutto questo si vede in una demo, e niente è scritto nella documentazione dei processi.
Fonti: AWS, “AWS invests $1 billion to embed AI forward deployed engineers with customers” (2026); Databricks, “Forward Deployed Engineering”.
Come acquistarlo senza un miliardo di dollari (in inglese) →Cinque deliverable, ognuno con un nome.
Un team di ingegneri non si può ispezionare. Un documento sì. Ognuno di questi ha una definizione, un responsabile e una data di consegna: è questo che rende l’ingaggio verificabile, invece che una questione di fiducia.
Aprine due, anonimizzati, da un ingaggio reale (in inglese) →Il Registro delle eccezioni
Un documento scritto che raccoglie ogni scostamento reale dal processo documentato. Per ciascuno: quanto spesso si verifica, chi oggi se ne fa carico e dove risiede davvero la logica che lo gestisce. L’ultima colonna è quella utile, perché la risposta non è quasi mai “la documentazione”. È la testa di una persona, e sta lì da undici anni.
L’unico modo per produrlo è osservare il processo reale mentre gira, eccezione per eccezione, insieme a chi le gestisce, e continuare a chiedere perché finché la regola non viene fuori. Un team che lavora dal tuo repository con una call settimanale di avanzamento non lo fa. L’informazione non sta nel repository, e nessuno la tira fuori spontaneamente in una call, perché a nessuno viene in mente di citare ciò che ha sempre saputo e basta. Non è una lacuna della documentazione. È così che appare la competenza vista da fuori.
- Ogni scostamento, con la frequenza osservata e non stimata
- La persona che oggi se ne fa carico, con nome e cognome
- Dove risiede la regola decisionale, e se si può mettere per iscritto
- Quali eccezioni devono restare umane, e perché
La Mappa dei confini AI
Il tuo flusso di lavoro, annotato passaggio per passaggio: codice deterministico, vero giudizio del modello o approvazione umana. Il numero chiave è il rapporto di determinismo, e la conclusione chiave è quasi sempre la stessa. La maggior parte del sistema non dovrebbe essere AI.
Nel flusso di gestione degli ordini di un’azienda manifatturiera europea che abbiamo mappato, tre passaggi su undici richiedevano davvero un modello. Gli altri otto erano parsing, lookup, validazioni e instradamento: lavoro che il software tradizionale fa a costi più bassi, più velocemente e con un risultato che domani puoi riprodurre identico. (Dati di ingaggio SUPALABS.)
Per questo un fornitore AI-first è il tipo sbagliato di fornitore per questo problema. Se la risposta a “quanta parte di questo dovrebbe essere AI” determina l’importo della fattura, una risposta onesta non la avrai.
La suite di valutazione e il report mensile di accuratezza
Un golden dataset costruito sui tuoi casi storici, i tassi di superamento per ogni passaggio misurati su quel dataset e avvisi quando un passaggio peggiora. Viene quotata come voce separata, mai assorbita nello sviluppo, perché una capacità che non vedi in fattura è una capacità che viene tagliata in silenzio quando i tempi si stringono.
- Golden dataset costruito sui tuoi casi reali, compresi quelli scomodi
- Tassi di superamento per passaggio, non un unico punteggio aggregato per tutto il sistema
- Avvisi di regressione quando il comportamento del modello cambia dopo un aggiornamento del fornitore
- Un report mensile scritto per chi deve approvare il sistema
È anche il motivo onesto per cui la collaborazione continua dopo lo sviluppo. I fornitori di modelli cambiano il comportamento senza chiedertelo. Qualcuno deve accorgersene.
Il registro delle decisioni
Ogni azione dell’agente, i suoi input, il livello di confidenza e chi l’ha approvata, in una schermata che un responsabile compliance può aprire senza chiedere aiuto a un ingegnere.
È normale ingegneria, e non diremo il contrario. Il punto non è che sia ingegnoso: è che la maggior parte dei fornitori lo salta, e un sistema che ne è privo non ottiene il permesso di avvicinarsi alla produzione in un ambiente regolamentato o soggetto a controlli. Tutto il motivo per costruirlo sta qui: è ciò che permette al sistema di entrare in funzione.
L’impegno a costruire sopra il gestionale
Costruiamo sopra i sistemi che hai già. Non ne proponiamo la sostituzione. Non richiediamo migrazioni. È un impegno che mettiamo per iscritto all’inizio dell’ingaggio, non una preferenza che vale finché non diventa scomoda.
Un progetto di cambio piattaforma è il rischio di carriera più grande che un responsabile delle operations o dell’IT possa assumersi, e quasi mai è ciò che il problema richiede davvero. Il flusso è lento per le eccezioni, i passaggi di mano e le approvazioni, non per il database che ci sta sotto. Cambiare database non risolve nulla di tutto questo, e ci vogliono due anni per scoprirlo.
L’impegno ha una seconda metà: interrompi il servizio, il sistema resta tuo. Ciò che costruiamo gira nei tuoi account, sopra il software che già possiedi, ed è documentato per il tuo team dalla prima settimana, perché il passaggio di consegne è un deliverable dello Sviluppo e non una cortesia finale. Se interrompi la fase di Gestione, il flusso continua a funzionare e il golden dataset resta a te.
Per programmi estesi a tutta l’organizzazione, vedi l’AI Efficiency Programme (in inglese) →Quattro gradini. Puoi fermarti dopo ognuno.
Tre livelli, definiti per tipo di attività. Le soglie le fissi tu.
Ogni attività automatizzata opera a uno di tre livelli di autonomia. Il livello si definisce per tipo di attività e non per sistema, quindi lo stesso flusso di lavoro può preparare una bozza in un passaggio, attendere un’approvazione in un altro e agire da solo in un terzo. Un’attività sale di livello solo quando la suite di valutazione mostra il tasso di superamento che hai fissato come soglia, e torna giù nel momento in cui il report mensile rileva una regressione.
Nessuna attività sale di livello sulla nostra parola. Le soglie sono tue, il report che le verifica è una voce separata in offerta e il registro delle decisioni mostra ogni azione eseguita, a ogni livello.
Il metodo completo: cinque deliverable, tre livelli, quattro gradini (in inglese) →Quando non dovresti comprarlo.
Ci sono tre situazioni in cui un ingaggio con un embedded operator è l’acquisto sbagliato, e per entrambi costa meno stabilirlo in una call di trenta minuti che al secondo mese.
Se ti riconosci in una di queste tre situazioni, te lo diremo nella call di qualifica e non dopo la fattura. A noi costa un contratto, a te risparmia un programma.
Domande frequenti
Trenta minuti per capire se c’è qualcosa che valga la pena mappare.
La call è gratuita, e se la risposta è no te lo diciamo. Porta un flusso di lavoro che ti esaspera.