Trasferire un agente AI dal partner al cliente: handover senza lock-in

Il progetto è live. L’agente risponde, i log girano, il primo report mostra numeri decenti. È esattamente il momento in cui la maggior parte dei progetti di AI aziendale inizia a morire: non per un difetto tecnico, ma perché nessuno ha deciso chi lo tiene in vita. Gartner prevede che oltre il 40% dei progetti di AI agentica sarà cancellato entro la fine del 2027, e le ragioni indicate non sono i modelli: costi che salgono, valore di business poco chiaro, controlli di rischio inadeguati. Tutte e tre sono questioni di gestione post go-live. Non a caso la lettura data alla previsione da chi l’ha commentata per primo, da MarTech a Search Engine Land, è che il presidio umano, invece di sparire, diventa indispensabile.

Per questo l’handover di un agente AI dal partner al cliente non è un adempimento burocratico di fine progetto: è la fase che decide se l’investimento produce valore per anni o si spegne in tre mesi. L’inventario di ciò che il partner deve materialmente consegnare, artefatti, accessi, documenti, sta nel pezzo dedicato: cosa deve consegnare il partner in fase di handover. Qui si parla del come si trasferisce: il processo, la proprietà degli artefatti, la matrice di escalation, i criteri con cui si dichiara chiuso il passaggio e le clausole che ti tengono libero di cambiare fornitore.

In questo articolo scoprirai:

• Perché un agente AI non si consegna come si consegna un software
• Handover progressivo o taglio netto: come si trasferisce un agente senza fermarlo
• Chi è proprietario dei prompt di sistema dopo la consegna
• Il runbook: cosa deve saper fare il cliente da solo il lunedì dopo
• Escalation matrix: chi risponde quando l'agente sbaglia di notte
• KPI di uscita: quando l'handover è finito davvero
• Vendor lock-in: le clausole da leggere prima di firmare

Perché un agente AI non si consegna come si consegna un software

Un gestionale, una volta collaudato, si comporta domani come si è comportato ieri. Un agente AI no. La documentazione MLOps di Google Cloud è esplicita su questo punto: «i modelli possono degradare in più modi rispetto ai sistemi software convenzionali», e non solo per errori di codice. I dati cambiano, i processi aziendali cambiano, il fornitore del modello rilascia una versione nuova e depreca la precedente. Un sistema che ieri rispondeva bene può iniziare a sbagliare senza che una riga di codice sia stata toccata.

Il perimetro reale della consegna: cosa c’è oltre l’agente

La seconda differenza è la proporzione tra ciò che si vede e ciò che regge. La stessa documentazione di Google Cloud ricorda che solo una frazione minima di un sistema ML reale è composta dal codice del modello: il resto è configurazione, verifica dei dati, automazione, monitoraggio, infrastruttura. Nel caso di un agente aggiungi i prompt di sistema, le definizioni degli strumenti, i permessi sulle fonti, le regole di fallback. Consegnare «l’agente» senza consegnare quel contorno significa consegnare la punta dell’iceberg.

Chi diventa responsabile: il deployer secondo l’AI Act

La terza differenza è normativa, e in Europa pesa. Dal momento in cui il cliente usa il sistema nel proprio contesto professionale diventa deployer ai sensi dell’AI Act, con obblighi propri che non può delegare al fornitore. Chi vuole il quadro completo lo trova nella nostra guida su cosa prevede l’AI Act e chi deve adeguarsi. Il punto per l’handover è semplice: il passaggio di consegne non è solo tecnico, è anche un passaggio di responsabilità, e va scritto da qualche parte prima che serva.

Handover progressivo o taglio netto: come si trasferisce un agente senza fermarlo

Il modello sbagliato è quello a data fissa: ultimo giorno di progetto, consegna delle credenziali, saluti. Il modello che funziona è graduale, e Microsoft lo scrive nella propria guida all’implementazione di Dynamics 365 con una frase che vale per qualsiasi sistema: «la transizione dalla modalità progetto alla modalità supporto non è un evento singolo: è un processo graduale», e va iniziata il più presto possibile, già in fase di realizzazione. Il trasferimento di conoscenza comincia mesi prima della consegna, non il giorno dopo.

Le tre fasi di un handover progressivo

La prima fase è l’affiancamento inverso: il partner opera, il team del cliente osserva e documenta insieme al partner. La seconda è l’affiancamento diretto: il cliente opera, il partner supervisiona e corregge. La terza è l’autonomia sorvegliata: il cliente opera da solo, il partner resta raggiungibile su escalation. Microsoft segnala anche il rischio da evitare: se le persone che erediteranno il sistema non hanno avuto esposizione regolare ed estesa durante la costruzione, arriveranno alla consegna con un divario di competenza che le renderà permanentemente dipendenti dai consulenti.

Il periodo di hypercare, e perché non si misura in settimane

Tra il go-live e l’operatività ordinaria si colloca l’hypercare: una finestra di supporto rinforzato, con SLA più stretti e monitoraggio quotidiano. Le durate che si ritrovano più spesso, in una rilevazione di prassi ITSM pubblicata da un vendor di supporto, sono di 2, 6 settimane, ma il dato interessante è un altro: l’hypercare finisce quando i criteri sono soddisfatti, non quando scade il calendario. È la stessa logica dell’early life support nella pratica ITIL, dove l’uscita è governata da criteri misurati e non da una data. Su un agente AI questo è ancora più vero, perché i primi utilizzi reali producono casi che nessun collaudo aveva previsto. Se ti interessa il rovescio della medaglia, cosa fa il partner nella fase iniziale, abbiamo raccontato in dettaglio i primi 30 giorni con un agente AI.

Chi è proprietario dei prompt di sistema dopo la consegna

È la domanda che divide gli handover seri da quelli decorativi. Il prompt di sistema di un agente non è un dettaglio di implementazione: è la codifica del processo aziendale, del tono, dei limiti e delle regole di sicurezza. Chi lo possiede possiede il comportamento del sistema.

La risposta corretta è che prompt, definizioni degli strumenti e set di valutazione appartengono al cliente, in formato leggibile e versionato, nel suo repository. Non «su richiesta», non «in un allegato PDF a fine contratto». Un’analisi sulle clausole di uscita nei contratti con le agenzie AI lo formula in modo che vale la pena citare: «la proprietà senza operabilità è un archivio costoso». Avere il diritto sui prompt e non essere in grado di modificarli, testarli e ridistribuirli non è proprietà: è un souvenir.

Il prompt è un artefatto versionato, non un file

Operativamente questo significa tre cose. Primo: storico delle versioni, con il motivo di ogni modifica, un prompt cambiato senza traccia è un incidente che non saprai ricostruire. Secondo: una suite di valutazione, cioè un insieme di casi di prova con la risposta attesa, che permetta di verificare se una modifica ha rotto qualcosa. È l’equivalente dei test automatici e, senza di essa, ogni intervento futuro è una scommessa. Terzo: la mappa delle fonti a cui l’agente accede e con quali permessi, perché è lì che si concentrano i rischi di esposizione dei dati, tema che tocchiamo nella guida su come funziona il RAG.

Lo stesso documento sulle clausole di uscita indica quali obblighi vanno definiti prima: chi documenta, chi esporta, chi verifica, chi assiste e quali obblighi sopravvivono alla fine del contratto. Sono quattro verbi e una data. Se il contratto non li contiene, l’handover dipenderà dalla buona volontà di qualcuno che, a quel punto, sarà su un altro progetto.

Il runbook: cosa deve saper fare il cliente da solo il lunedì dopo

Il runbook non è il manuale utente. È il documento operativo di chi tiene in piedi il servizio, e la sua qualità si misura su una domanda sola: una persona competente ma non presente al progetto riesce a gestire un’anomalia leggendolo? Per un agente AI le voci minime sono quattro.

Le quattro voci minime del runbook di un agente AI

La prima è la procedura di degrado controllato: cosa succede se il modello è irraggiungibile o un tool non risponde. Un agente senza fallback definito non si degrada: si spegne, in mezzo a una conversazione con un cliente. La seconda è la gestione delle risposte errate, come si riconosce un’allucinazione in produzione, chi la segnala, con quale modulo, in quanto tempo si corregge e chi approva la correzione. La terza è la procedura di rollback: tornare alla versione precedente di un prompt o di una configurazione deve essere un’operazione di minuti, documentata, non un’archeologia.

La quarta è il monitoraggio, e qui la normativa detta un pavimento minimo. L’articolo 26 dell’AI Act stabilisce, per i sistemi ad alto rischio, che il deployer conservi i log generati automaticamente per un periodo adeguato e comunque non inferiore a sei mesi, sorvegli il funzionamento secondo le istruzioni per l’uso, informi per primo il fornitore in caso di incidente grave e assegni la supervisione umana a persone che abbiano «la competenza, la formazione e l’autorità necessarie». Tradotto in termini di handover: se al termine del passaggio nessuno in azienda ha nome, formazione e autorità per fermare l’agente, il requisito non è soddisfatto, indipendentemente da quanto sia bello il runbook. Per impostare il monitoraggio in modo sostenibile, il riferimento metodologico più usato è il NIST AI Risk Management Framework, costruito sulle quattro funzioni Govern, Map, Measure, Manage.

Escalation matrix: chi risponde quando l’agente sbaglia di notte

La matrice di escalation è il documento che nessuno legge fino alle 23:40 di un venerdì. Serve a rispondere a tre domande senza discussione: quanto è grave, chi interviene, entro quanto. La struttura consolidata prevede un primo livello che riceve e classifica, un secondo livello che indaga su applicazione e integrazioni, un terzo livello specialistico che tocca prompt, modelli e codice, durante la transizione, quasi sempre il partner.

Le prassi di hypercare mostrano quanto la differenza sia concreta: per un incidente di severità 1 il target ordinario è tipicamente di un’ora, mentre nella finestra di hypercare scende a 15, 30 minuti. Sono due servizi diversi, e vanno prezzati e contrattualizzati come tali: pretendere tempi da hypercare a tempo indeterminato senza un contratto di servizio è il modo più rapido per ottenere, di fatto, nessuno dei due.

Classificare gli errori di un agente AI per severità

Su un agente AI la classificazione va adattata al tipo di errore, perché i sintomi non somigliano a quelli di un software tradizionale. Un agente che risponde in modo plausibile ma sbagliato è un incidente di severità alta pur essendo il sistema perfettamente «up»: non c’è alcun allarme tecnico che scatti. Va quindi definito chi ha l’autorità di sospendere l’agente e in quali casi, l’AI Act, per i sistemi ad alto rischio, lo pretende. Google, nel proprio manuale di Site Reliability Engineering, descrive il presidio complementare: percorsi di escalation chiari e la possibilità del team operativo di «restituire il pager» a chi ha costruito il sistema se questo non regge gli standard di affidabilità. È un’ottima clausola da tenere a mente in fase di consegna, e vale in entrambe le direzioni. Sul perché tanti progetti non arrivino mai a questo livello di maturità operativa, abbiamo analizzato le quattro cause per cui i POC si bloccano.

KPI di uscita: quando l’handover è finito davvero

Senza criteri di uscita l’handover finisce quando finiscono le giornate vendute. Con i criteri finisce quando il servizio sta in piedi da solo, e la differenza si vede sei mesi dopo. Le prassi ITSM sull’uscita dall’early life support chiedono che i criteri valgano per cinque giorni lavorativi consecutivi, non in un giorno fortunato: volume di ticket entro una soglia definita, nessun incidente critico aperto, arretrato in calo, nessun nuovo difetto ricorrente, workaround tutti documentati e assegnati, e approvazione formale del riepilogo di consegna da parte del referente del cliente.

I tre indicatori specifici di un handover agente AI

Su un agente AI vanno aggiunti tre indicatori specifici, e la loro definizione va concordata prima del go-live, non trattata alla fine. Il primo è la percentuale di casi che l’agente chiude senza intervento umano, misurata sui volumi reali e non sul campione di collaudo. Il secondo è l’esito della suite di valutazione: una soglia di risposte corrette su un set di casi congelato, che il cliente deve poter rieseguire da solo. Se non può rieseguirla senza il partner, il criterio non è verificabile e quindi non è un criterio. Il terzo è la capacità del team interno di gestire un’anomalia reale end-to-end senza scalare al partner: si prova, non si dichiara.

Vale la pena aggiungere un criterio di natura organizzativa, spesso decisivo: l’esistenza di un proprietario nominale del servizio, con tempo assegnato e non solo un titolo. Un agente senza un referente interno che lo presidi torna a essere un progetto orfano nel giro di un trimestre, e nessuna documentazione compensa quel vuoto. Su come si costruisce quella competenza interna abbiamo scritto una guida dedicata alla formazione del team dopo il go-live.

Vendor lock-in: le clausole da leggere prima di firmare

La paura del lock-in è la ragione più frequente per cui un buyer B2B rallenta un progetto già approvato. È una preoccupazione legittima, ma spesso mal indirizzata: si concentra sul modello, mentre il vincolo si forma altrove. L’analisi del panorama enterprise agentico 2026 di Kai Wähner elenca i livelli su cui il lock-in si accumula, API del modello, livello di orchestrazione, ambiente di esecuzione gestito, abitudini del team, integrazioni di ecosistema, e osserva che «il lock-in dell’AI agentica è più duraturo del lock-in sulle API perché si accumula su più livelli contemporaneamente». Cambiare modello è un’operazione di configurazione; cambiare orchestrazione è un progetto, ed è anche il motivo per cui, su un sistema in produzione, il servizio conta più del modello.

Cosa chiedere per restare liberi di cambiare partner

Quattro richieste coprono la maggior parte del rischio. Una: una finestra di recupero dati definita nel contratto, con formati di export specificati, non «formato concordato tra le parti». Due: proprietà esplicita di prompt, configurazioni e set di valutazione, con il diritto di riutilizzarli con un altro fornitore. Tre: credenziali intestate al cliente su tutti i servizi terzi, con inventario degli accessi. Quattro: assistenza alla transizione già inclusa e quantificata, non da negoziare nel momento peggiore.

Sul piano tecnico, la difesa migliore è l’adozione di standard aperti al posto di integrazioni proprietarie. Il Model Context Protocol è oggi uno standard open source per collegare le applicazioni AI a dati e strumenti, «una porta USB-C per l’AI», nella metafora della documentazione ufficiale, supportato trasversalmente da client e fornitori diversi, ed è stato donato alla Agentic AI Foundation della Linux Foundation. Un agente costruito su integrazioni MCP mantiene il proprio valore anche se cambi modello o partner; se ti serve il quadro tecnico, lo abbiamo trattato nella guida completa a MCP Server. E se stai valutando quanto internalizzare, il confronto tra agente chiavi in mano e self-service aiuta a inquadrare la scelta.

Il modello Mimir: handover progressivo, con managed service opzionale

Il nostro approccio nasce da un’osservazione ripetuta: il momento in cui un agente si rompe non è il go-live, è il terzo mese, quando il partner è già altrove e in azienda nessuno ha ancora capito bene come si mette mano ai prompt. Per questo in MIMIR l’handover non è un evento di fine progetto ma una linea che corre lungo tutto il lavoro: il repository, i prompt versionati, il set di valutazione e il runbook sono del cliente dal primo giorno, non dall’ultimo. Ciò che scriviamo lo scriviamo dove resterà.

Criteri di uscita e reversibilità dopo l’handover

Dopo il go-live si apre una finestra di supporto rinforzato con criteri di uscita concordati in anticipo, non con una data. Quando i criteri sono soddisfatti il cliente può scegliere: prendere in carico l’operatività con il proprio team, oppure lasciare a noi la gestione continuativa in managed service. È una scelta reversibile, e questo è il punto: chi ha documentazione, artefatti e credenziali in casa può cambiare idea, e cambiare fornitore, senza rifare il progetto. Un contratto di gestione che si regge sulla difficoltà di uscirne non è un servizio, è un vincolo.

Se stai valutando un progetto su agenti AI o hai un agente già in produzione di cui nessuno, internamente, si sente proprietario, è una conversazione che vale la pena fare prima che diventi un problema. Su mimir.bot puoi chiedere una consulenza e portare il tuo caso: guardiamo insieme cosa serve per l’autonomia del tuo team e cosa conviene lasciare gestito. Se invece stai ancora scegliendo con chi lavorare, i criteri li abbiamo messi nella guida su come scegliere un partner AI in Italia.

Fonti:

• Gartner — oltre il 40% dei progetti di AI agentica sarà cancellato entro la fine del 2027 (comunicato ufficiale)
• MarTech — la previsione Gartner e il ruolo indispensabile del presidio umano
• Search Engine Land — 40% dei progetti di AI agentica destinati a fallire
• Google Cloud MLOps — «i modelli possono degradare in più modi rispetto ai sistemi software convenzionali» e la composizione reale di un sistema ML
• Microsoft — «la transizione dalla modalità progetto alla modalità supporto non è un evento singolo: è un processo graduale»
• Supportbench — hypercare: durata tipica 2–6 settimane e SLA a 15–30 minuti
• ITILigence — early life support, hypercare e criteri di uscita nella pratica ITIL
• ContentGrip — «la proprietà senza operabilità è un archivio costoso»: le clausole di uscita nei contratti AI
• AI Act — articolo 26, obblighi del deployer di sistemi ad alto rischio
• NIST AI Risk Management Framework — Govern, Map, Measure, Manage
• Google SRE Book — percorsi di escalation chiari e restituzione del pager
• Kai Wähner — «il lock-in dell’AI agentica è più duraturo del lock-in sulle API perché si accumula su più livelli contemporaneamente»
• Model Context Protocol — introduzione allo standard open source