Handover agente AI: cosa deve consegnare il partner

C’è una domanda che nelle riunioni di valutazione arriva sempre per ultima, spesso a bassa voce, quando il pilot ha già funzionato e i numeri convincono: «e se poi ci lasciano soli?». È la domanda che blocca più decisioni di quanto blocchi il budget, perché tocca un punto che nessuna demo risolve: un agente in produzione è un sistema vivo, che va sorvegliato, aggiornato e riparato anche il martedì di agosto in cui il partner non risponde al telefono. Ed è la domanda che rende l’handover di un agente AI, il passaggio di consegne dal fornitore al team IT del cliente, la parte del progetto che decide se il sistema sopravvive al primo anno.

L’handover di un agente AI è esattamente questo passaggio: il momento in cui la responsabilità operativa di un sistema costruito da un fornitore esterno si trasferisce, in tutto o in parte, al team interno dell’azienda che lo usa. Non è una consegna di file. È il trasferimento di una capacità: sapere cosa fa il sistema, perché lo fa, cosa guardare quando smette di farlo bene e chi chiamare quando serve. Questo pezzo prova a mettere per iscritto cosa deve contenere quel passaggio, documentazione, runbook, credenziali, playbook di incident, e perché il modello che adottiamo in Mimir non prevede un giorno di consegna secco, ma una discesa graduale accompagnata.

In questo articolo scoprirai:

• Handover di un agente AI: perché la parola significa due cose diverse
• Cosa deve consegnare il partner: il pacchetto documentale minimo
• Il runbook: cosa fa il team interno quando l'agente sbaglia
• Credenziali, identità dell'agente e principio del minimo privilegio
• Playbook di incident: chi risponde, in quanto tempo, fino a dove
• Prompt, configurazioni e dati: chi resta proprietario dopo la consegna
• Il modello Mimir: handover graduale, non consegna secca
• Serve davvero un team IT dedicato per tenere in piedi un agente AI

Handover di un agente AI: perché la parola significa due cose diverse

Se cerchi «handover» insieme a «agente AI» trovi quasi solo una cosa: il passaggio di una conversazione dal bot all’operatore umano. È il significato dominante nella documentazione dei vendor di customer care, ed è un tema legittimo, ma è un altro tema. Lì l’handover avviene dentro una singola conversazione, dura secondi e riguarda un cliente che ha perso la pazienza.

Handover dell’agente AI dal fornitore al cliente: il significato che costa di più

Qui parliamo del secondo significato, molto meno documentato e molto più costoso da sbagliare: il passaggio di consegne dal fornitore al cliente, cioè il momento in cui l’agente smette di essere un progetto del partner e diventa un sistema aziendale. Due handover diversi, due rischi diversi. Il primo, se fallisce, produce un cliente scontento. Il secondo, se fallisce, produce un sistema che nessuno sa più toccare, e che quindi, silenziosamente, viene spento.

Vale la pena tenere a mente il contesto: secondo Gartner oltre il 40% dei progetti di AI agentica sarà cancellato entro fine 2027, e la causa indicata non è la tecnologia ma il fatto che «le organizzazioni distribuiscono agenti senza una strategia chiara, senza comprendere la complessità e senza la governance per gestire i problemi» (comunicato Gartner, 25 giugno 2025; la previsione poggia su un sondaggio condotto su oltre 3.400 organizzazioni, ripreso anche da MarTech). La governance per gestire i problemi è precisamente ciò che un handover fatto bene consegna. Se il tuo pilot è ancora fermo prima di questa soglia, abbiamo raccontato altrove le quattro cause per cui i POC si bloccano: la mancanza di un piano di consegna è una di quelle che si vedono più tardi e fanno più danni.

Cosa deve consegnare il partner: il pacchetto documentale minimo

Il modo più solido per definire il contenuto della consegna non è chiederlo al fornitore: è guardare cosa la normativa già impone a chi fornisce un sistema di AI. L’articolo 13 dell’AI Act, dedicato alla trasparenza verso i deployer, elenca cosa devono contenere le istruzioni per l’uso di un sistema ad alto rischio: identità e contatti del fornitore, finalità prevista, livello di accuratezza e robustezza, circostanze note che possono degradare le prestazioni, misure di sorveglianza umana implementate, risorse hardware necessarie, aspettativa di vita del sistema, manutenzione richiesta e frequenza degli aggiornamenti, e i meccanismi per raccogliere e interpretare i log (testo dell’articolo 13).

Anche se il tuo agente non ricade nella categoria ad alto rischio, quella lista è il miglior capitolato che esista, perché è stata scritta pensando a un lettore che deve poter usare il sistema senza averlo costruito. Su come cambia il quadro quando l’obbligo scatta davvero, abbiamo dedicato un pezzo intero ad AI Act e agenti AI in azienda, e la mappa generale delle scadenze sta nella guida all’AI Act.

I documenti che devono esistere prima del go-live

Tradotto in pratica, il pacchetto minimo che un partner serio consegna prima di passare in produzione contiene: una descrizione architetturale del sistema (quali modelli, quali tool, quali fonti dati, quali integrazioni); l’inventario dei prompt e delle configurazioni con la loro cronologia; la mappa dei permessi e delle utenze tecniche; i criteri di valutazione con cui l’agente è stato testato e i risultati ottenuti; i limiti noti, scritti come limiti e non come nota a piè di pagina. Anthropic, nella sua guida ingegneristica sugli agenti, insiste su un punto che vale come criterio di accettazione: la documentazione dei tool a disposizione dell’agente va curata «con la stessa attenzione della documentazione di un’API», esempi e casi limite compresi (Building effective agents). Se quella parte manca, il team interno erediterà un sistema di cui conosce il comportamento ma non il perimetro.

Il runbook: cosa fa il team interno quando l’agente sbaglia

La documentazione spiega com’è fatto il sistema. Il runbook, o playbook, nel lessico SRE, spiega cosa fare quando qualcosa non va, ed è il documento che distingue una consegna reale da una consegna simbolica. Il Google SRE Workbook lo definisce senza ambiguità: i playbook contengono «istruzioni di alto livello su come rispondere agli alert automatici», descrivono gravità e impatto dell’alert e includono suggerimenti di debug e le azioni possibili per mitigare e risolvere. E soprattutto: ogni alert deve essere immediatamente azionabile, cioè deve esistere un’azione che ci si aspetta che un umano compia subito (SRE Workbook, capitolo On-Call). La ragione per cui il runbook conta è misurabile: riduce lo stress, il rischio di errore umano e il tempo medio di ripristino.

Le cinque domande a cui il runbook di un agente AI deve rispondere

Per un agente AI, il runbook ha voci che un runbook applicativo classico non ha. L’agente risponde ma male: come si riconosce una degradazione di qualità, che non genera errori né 500? Chi guarda le conversazioni campione, con che cadenza, e qual è la soglia oltre la quale si interviene? Come si mette l’agente in modalità ridotta, solo risposte da knowledge base, niente azioni sui sistemi, senza spegnerlo del tutto? Come si fa rollback di un prompt che ieri funzionava? Chi autorizza la riattivazione?

Un runbook che non risponde a queste cinque domande è un documento di facciata. E va scritto durante il pilot, non dopo: le procedure che funzionano sono quelle nate dagli incidenti veri già capitati in fase di test. È la stessa logica che descriviamo parlando di manutenzione degli agenti dopo il deployment: la fase operativa non è il dopo del progetto, è il progetto.

Credenziali, identità dell’agente e principio del minimo privilegio

Il passaggio delle credenziali è la parte dell’handover che si tende a sbrigare in fretta e che invece merita più attenzione di tutte le altre. Un agente in produzione non è un utente: è un’identità tecnica che accede a CRM, caselle di posta, database, API di pagamento, e lo fa senza qualcuno che guarda lo schermo. L’iniziativa OWASP dedicata alla sicurezza agentica classifica proprio queste come le minacce caratteristiche della categoria, memory poisoning, tool misuse, privilege compromise e identity spoofing, e indica tre contromisure di base: gestione robusta di identità e credenziali, principio del minimo privilegio, logging completo e verificabile delle attività dell’agente (OWASP Agentic AI: Threats and Mitigations).

Le regole non negoziabili sulle utenze tecniche dell’agente

Nel concreto dell’handover questo significa alcune regole non negoziabili. Le utenze tecniche dell’agente sono intestate all’azienda cliente, mai al partner: se il fornitore ha creato account con la propria email o le proprie chiavi API, quelle vanno rigenerate e riassegnate prima della consegna, non dopo. I segreti non viaggiano in un foglio condiviso ma in un gestore di segreti, e la configurazione che cambia tra ambienti sta in variabili d’ambiente, è la regola che Microsoft mette nero su bianco tra le sue «golden rules» di ALM per gli agenti: usare variabili d’ambiente per impostazioni e segreti che cambiano tra ambienti, e non personalizzare mai fuori dall’ambiente di sviluppo (Microsoft Learn, ALM strategy).

Va fatto anche l’inventario inverso: quali accessi il partner conserva dopo la consegna, con quale motivazione, per quanto tempo e con quale tracciamento. Un partner che ha bisogno di accesso permanente e non sa dirti a cosa serve è un rischio di governance, non un servizio. Il perimetro corretto di policy e audit lo trattiamo nel pezzo su governance degli agenti AI in azienda.

Playbook di incident: chi risponde, in quanto tempo, fino a dove

Un incident su un agente AI ha una caratteristica scomoda: spesso non è un guasto. Il sistema è online, risponde in tempi normali, e sta dicendo cose sbagliate a persone reali. Nessun monitoraggio infrastrutturale se ne accorge. Per questo il playbook di incident va scritto separatamente dal runbook operativo, e va scritto prima.

Il riferimento metodologico più solido resta l’impianto NIST: la revisione 3 della SP 800-61 imposta la gestione degli incidenti dentro il ciclo di risk management, con la preparazione come fase che determina tutto il resto, ridurre numero e impatto degli incidenti, migliorare rilevamento, risposta e ripristino (NIST SP 800-61r3, aprile 2025). Sul lato specificamente AI, il playbook dell’AI Risk Management Framework è ancora più esplicito: la sottocategoria MANAGE 4.1 chiede piani di monitoraggio post-deployment che includano «meccanismi per raccogliere e valutare l’input degli utenti, appeal e override, decommissioning, incident response, recovery e change management»; la 4.3 aggiunge che incidenti ed errori vanno comunicati agli attori rilevanti e che i processi di tracciamento e recupero vanno seguiti e documentati (NIST AI RMF Playbook, funzione Manage).

Le clausole di incident response da concordare nell’handover

Tradotto in clausole verificabili da mettere nero su bianco con il partner: chi è il primo livello di risposta nelle ore lavorative e chi fuori; qual è il tempo di presa in carico dichiarato per un incidente che coinvolge dati personali o decisioni verso clienti; chi ha l’autorità di spegnere l’agente senza chiedere permesso, e la risposta giusta è «il team interno, sempre»; come si fa il post mortem e dove finisce, perché una lezione appresa che non rientra nelle procedure non è una lezione appresa. Il diritto di override, che l’AI RMF nomina esplicitamente, è la garanzia sostanziale: chi usa il sistema deve poterlo fermare.

Prompt, configurazioni e dati: chi resta proprietario dopo la consegna

La domanda arriva sempre in ritardo rispetto a quando andrebbe fatta, cioè in fase di contratto. I prompt di sistema, le catene di strumenti, le knowledge base curate, i set di valutazione costruiti sui casi aziendali: sono il vero patrimonio del progetto, spesso valgono più del codice. Se il contratto non dice a chi appartengono, la risposta di default è quella scomoda.

La regola che consigliamo è semplice e va scritta in tre righe: tutto ciò che è stato costruito sui processi e sui dati del cliente appartiene al cliente, esportabile in un formato leggibile e riutilizzabile, in qualsiasi momento e senza chiedere. Il framework che il partner usa per costruire può restare suo; la configurazione che descrive la tua azienda no. È anche la direzione del legislatore europeo: il Data Act, applicabile dal 12 settembre 2025, introduce un quadro di regole «per consentire ai clienti di passare efficacemente da un fornitore di servizi di trattamento dati a un altro», con l’obiettivo dichiarato di ridurre il lock-in (Commissione europea, pagina ufficiale del Data Act).

L’esportabilità va provata, non descritta

C’è poi la prova pratica, che vale più di qualsiasi clausola: l’esportazione va provata almeno una volta prima della fine del contratto, non descritta. Chiedi al partner di consegnare il pacchetto completo, configurazioni, prompt versionati, dataset di valutazione, documentazione, e verifica che qualcuno interno riesca a leggerlo e capirlo senza assistenza. Se serve una call per spiegare l’export, l’export non è pronto. Questo criterio, tra l’altro, è uno dei più discriminanti quando si valuta quale fornitore scegliere, e cambia radicalmente il calcolo tra soluzione chiavi in mano e self-service.

Il modello Mimir: handover graduale, non consegna secca

Su un punto siamo espliciti perché è la parte del nostro lavoro che viene fraintesa più spesso: in Mimir non esiste un «giorno della consegna». Esiste una curva, lungo la quale la responsabilità operativa si sposta dal nostro team al vostro mentre il sistema è già in produzione e sotto osservazione. Il motivo non è commerciale, è tecnico: un agente si conosce vedendolo sbagliare, e il team interno impara davvero solo affrontando incidenti veri con qualcuno accanto che li ha già visti.

Le tre fasi dell’handover graduale di un agente AI

La struttura ricalca la logica degli ambienti separati che è ormai standard nell’ALM degli agenti, sviluppo, test, produzione, con promozione controllata e versionamento, applicata però alle persone e non solo agli artefatti. Nella prima fase gestiamo noi e il team interno osserva, con accesso completo ai log e alle decisioni. Nella seconda il team interno gestisce e noi restiamo in seconda linea: il vostro referente prende in carico, noi rispondiamo se serve. Nella terza il team interno gestisce da solo e noi restiamo disponibili su richiesta, con revisioni periodiche programmate e non a chiamata.

Il criterio scritto con cui si passa da una fase all’altra

Il passaggio di fase non è una data sul piano di progetto: è un criterio contato, e lo scriviamo nel documento di handover prima di partire. Dalla prima alla seconda fase si passa quando il referente interno ha assistito ad almeno tre incidenti reali gestiti da noi, ha il runbook completo davanti e ha eseguito almeno una volta, in autonomia ma sotto osservazione, le due manovre che servono sempre: mettere l’agente in modalità ridotta e fare rollback di un prompt.

Dalla seconda alla terza si passa con un conto: cinque incidenti consecutivi chiusi dal team interno senza escalation verso di noi, in una finestra di sessanta giorni. Consecutivi conta: se al terzo il referente ci chiama, il conteggio riparte da zero. Se in sessanta giorni gli incidenti sono meno di cinque, e succede spesso, quando l’agente lavora bene, la finestra si estende fino a raggiungere il numero, perché il criterio è l’esperienza accumulata, non il tempo passato. La firma del passaggio è doppia e sta a verbale: il referente interno dichiara di sentirsi in grado di gestire, il nostro tecnico di riferimento conferma che i cinque incidenti sono stati chiusi bene, non solo chiusi. Se le due firme non coincidono, si resta in fase due: chi ha il dubbio ha ragione per definizione, perché è chi risponderà al telefono il martedì di agosto.

Quello che non finisce mai, se l’azienda lo vuole, è l’affiancamento: modelli nuovi, normativa che si muove, processi aziendali che cambiano. Questo è il senso di quello che intendiamo quando diciamo che offriamo un servizio e non solo un prodotto, lo stesso principio che governa i primi trenta giorni di onboarding e che regge tutta la transizione da pilot a produzione.

Serve davvero un team IT dedicato per tenere in piedi un agente AI

No: serve una persona sola, identificata con nome e cognome, che dedichi all’agente circa due-quattro ore a settimana a regime. Non un data scientist, non un presidio h24, non un team.

Quelle ore hanno un contenuto preciso: una lettura settimanale di un campione di conversazioni (mezz’ora scarsa, venti-trenta scambi presi a caso più tutti quelli finiti male), il controllo degli alert e delle segnalazioni arrivate dagli utenti, e la manutenzione delle eccezioni, i casi nuovi che l’agente non sa gestire e che vanno o insegnati o esclusi. Le competenze richieste sono quattro, tutte apprendibili in una giornata di formazione: leggere i log delle conversazioni, riconoscere una degradazione di qualità prima che la segnalino i clienti, applicare il runbook nelle due manovre di base (modalità ridotta e rollback di prompt), decidere quando chiamare il partner. Nelle settimane di incidente le ore salgono, ovviamente; nelle settimane normali spesso ne bastano meno di due.

In una PMI questa persona esiste già: è chi conosce il processo che l’agente automatizza, non necessariamente chi conosce i modelli, ed è il primo interlocutore quando si definisce cosa aspettarsi da un partner.

Le competenze da costruire per gestire un agente AI in autonomia

La competenza da costruire, quindi, è più di lettura che di costruzione: capire cosa può fare un agente e cosa no, e riconoscere quando sta uscendo dal suo perimetro. Se il concetto è ancora sfumato nel team, il punto di partenza è la nostra guida su cosa sono gli agenti AI e come funzionano davvero.

Sul lato organizzativo, la parte difficile non è tecnica ed è quella che descriviamo parlando di change management per l’agentic AI e del ruolo del partner nella formazione. Un handover senza formazione è un trasferimento di rischio, non di competenza: consegnare i documenti a chi non è stato messo in condizione di usarli sposta solo la responsabilità.

Se state valutando un progetto su agenti AI e la domanda che vi frena è proprio «e dopo?», è la domanda giusta e merita una risposta scritta, non rassicurazioni. In Mimir lavoriamo esattamente su questo: costruire l’agente e insieme costruire la capacità dell’azienda di gestirlo, con un piano di handover concordato prima di iniziare. Se volete capire come si applicherebbe al vostro caso, parliamone, anche solo per definire cosa dovreste pretendere in consegna, da noi o da chiunque altro.

Fonti:

• AI Act, articolo 13: trasparenza e istruzioni per l’uso verso i deployer
• NIST AI RMF Playbook, funzione Manage (MANAGE 4.1 e 4.3)
• NIST SP 800-61r3, Incident Response Recommendations and Considerations (aprile 2025)
• Google SRE Workbook, capitolo On-Call: playbook e alert azionabili
• Microsoft Learn, strategia ALM per gli agenti: ambienti, variabili e segreti
• Anthropic, Building effective agents: documentare i tool come un’API
• OWASP, Agentic AI: Threats and Mitigations
• Gartner, comunicato stampa sulla cancellazione di oltre il 40% dei progetti di AI agentica entro il 2027
• MarTech su dati Gartner, sondaggio su oltre 3.400 organizzazioni
• Commissione europea, pagina ufficiale del Data Act