Cambiare fornitore agente AI: quando conviene e cosa rischi

Nel 2023 e nel 2024 molte aziende italiane hanno firmato il loro primo contratto per un assistente conversazionale o un agente automatico con la prima realtà che si è presentata: un’agenzia digitale, un freelance, una software house che stava imparando anche lei. Tre anni dopo, quel fornitore magari non risponde più nei tempi, il progetto è fermo alla versione consegnata il primo giorno, e la fattura mensile arriva puntuale. La domanda che si fanno in tanti è la stessa: cambiare fornitore agente AI conviene davvero, o si rischia di perdere tutto quello che è stato costruito?

È una domanda seria, e merita una risposta che non sia né un invito automatico a cambiare né la difesa di uno status quo comodo. Cambiare costa: tempo, denaro, attenzione dei team. Non cambiare, quando i segnali ci sono tutti, costa più a lungo e in modo meno visibile. Questo articolo prova a dare dei criteri per distinguere i due casi, e soprattutto a spiegare come si porta via ciò che è vostro, prompt, memoria, integrazioni, dati, senza ricominciare da zero. Se invece state ancora capendo cosa sanno fare davvero questi sistemi, abbiamo scritto una guida completa agli agenti AI e una su come si costruiscono su misura per un’azienda.

In questo articolo scoprirai:

• I segnali che dicono a un'azienda che è ora di cambiare fornitore
• Cosa possedete davvero: prompt, memoria e integrazioni sotto esame
• Data Act e portabilità: cosa potete pretendere per legge
• Come si progetta la migrazione senza fermare l'azienda
• Compliance: cosa si riusa e cosa va rivalutato

I segnali che dicono a un’azienda che è ora di cambiare fornitore

Il momento giusto per farsi la domanda non è quando qualcosa si rompe in modo clamoroso. È quando si accumulano segnali piccoli e ripetuti, che presi uno a uno sembrano incidenti e messi in fila raccontano una storia. Il primo segnale è lo scarto sistematico tra SLA promessi e SLA rispettati: non il singolo ritardo, ma la ripetizione. Se il contratto dice quattro ore e la risposta arriva in due giorni per tre mesi di fila, non è un problema di organico del fornitore, è il livello di servizio reale che state comprando.

Il secondo segnale è la roadmap ferma. Un agente AI non è un sito vetrina: il modello sottostante cambia ogni pochi mesi, cambiano i prezzi delle API, cambiano gli strumenti di integrazione. Un fornitore che in dodici mesi non ha proposto un solo aggiornamento sostanziale non sta mantenendo il vostro sistema, lo sta lasciando invecchiare mentre vi fattura la manutenzione.

Costi che salgono senza valore aggiunto: come si riconosce

Il terzo segnale è il più insidioso perché si traveste da normale inflazione dei prezzi. Chiedete al fornitore una cosa semplice: quali metriche di utilizzo sono cambiate rispetto all’anno scorso. Conversazioni gestite, tasso di risoluzione senza intervento umano, ore di lavoro risparmiate. Se il canone è salito, poniamo, del 15% e nessuna di queste metriche esiste, non è peggiorata, proprio non viene misurata, state pagando di più per un servizio di cui nessuno conosce il rendimento. Vale la pena confrontare la fattura con ciò che un canone mensile dovrebbe includere. Questo è esattamente il punto in cui i progetti AI si arenano: non perché la tecnologia non funzioni, ma perché manca il presidio che trasforma la tecnologia in risultato misurabile. Vale la pena ricordare che Gartner prevede che oltre il 40% dei progetti di AI agentica venga cancellato entro la fine del 2027, e le cause indicate sono proprio queste tre: costi in crescita, valore di business poco chiaro e controlli di rischio inadeguati.

La dipendenza da una sola persona del fornitore

Il quarto segnale è quello di cui si parla meno e che fa più danni. Se esiste una sola persona, dentro la struttura del fornitore, che sa come funziona il vostro agente, che conosce i prompt, ricorda perché una certa integrazione è stata fatta così, sa dove guardare quando qualcosa si comporta in modo strano, allora il vostro sistema non è documentato. È ricordato. E la memoria di una persona si dimette, si ammala, cambia azienda. Un fornitore sano sa rispondere alla domanda «se domani il vostro referente non c’è, chi prende in mano il nostro progetto e con quali documenti» senza esitare. Se l’esitazione c’è, il rischio operativo è già a bilancio, semplicemente non l’avete ancora contabilizzato.

Cosa possedete davvero: prompt, memoria e integrazioni sotto esame

Prima di valutare qualunque alternativa serve un inventario onesto di cosa è vostro e cosa è del fornitore. La guida pratica di Master of Code sull’AI vendor lock-in propone un censimento per ogni applicazione: modello e provider usati, API e SDK, prompt, sorgenti RAG e infrastruttura vettoriale, framework degli agenti, strumenti esterni collegati, data di rinnovo del contratto e stima dello sforzo di migrazione. Poi un punteggio semplice: criticità del processo moltiplicata per difficoltà di sostituzione. Quello che esce in cima è la vostra priorità.

Lo stesso lavoro identifica sei livelli in cui la dipendenza si annida, modello e API, prompt, workflow degli agenti, dati, infrastruttura, contratti, e la parte più difficile da portare via non è quasi mai il modello: sono i prompt calibrati e la memoria accumulata. Il modello si sostituisce cambiando un endpoint. I prompt sono il risultato di mesi di aggiustamenti su casi reali, spesso mai scritti in un documento. La memoria dell’agente, le conversazioni passate, gli embedding, gli indici vettoriali costruiti sui vostri documenti, è il patrimonio informativo che avete generato voi, con i vostri dati, e che troppo spesso vive dentro un formato proprietario.

Le integrazioni: dove lo standard MCP cambia le regole

Sul fronte delle integrazioni qualcosa si è mosso. Il Model Context Protocol è uno standard aperto che serve a collegare applicazioni AI a fonti dati, strumenti e workflow esterni: la documentazione ufficiale lo paragona a una porta USB-C per l’AI, ed è supportato da un ecosistema ampio di client e server. Se il vostro agente parla con il gestionale, il CRM e il magazzino attraverso connettori MCP anziché tramite codice scritto su misura per una singola piattaforma, una parte consistente del lavoro di integrazione sopravvive al cambio di fornitore. Va detto con onestà: MCP riduce l’accoppiamento agli strumenti, non ai modelli, ai prompt o al livello dati. È un pezzo della soluzione, non la soluzione.

Data Act e portabilità: cosa potete pretendere per legge

Qui c’è una notizia che molte PMI italiane non hanno ancora messo a fuoco. Il Data Act europeo, applicabile dal 12 settembre 2025 secondo la pagina ufficiale della Commissione europea, introduce un quadro vincolante per il passaggio tra fornitori di servizi di trattamento dati. Non è una raccomandazione di buone pratiche: sono obblighi contrattuali, e in Italia Agenda Digitale li legge proprio come un diritto alla portabilità azionabile dal cliente quando decide di cambiare fornitore. Una precisazione sul perimetro, perché il tema confina con un altro: sul vendor lock-in sugli agenti AI abbiamo scritto come si fa prevenzione nel momento in cui si firma il contratto; qui parliamo invece di uscita da un rapporto già in corso, con le clausole che ci sono e non quelle che avreste voluto.

L’analisi di Alston & Bird sui requisiti di switching riassume i punti operativi: il contratto deve contenere una specificazione esaustiva di tutte le categorie di dati e asset digitali trasferibili, deve descrivere procedure, restrizioni e limiti tecnici del passaggio, e deve prevedere l’obbligo del fornitore di sostenere la strategia di uscita del cliente con assistenza ragionevole. Sui tempi, l’approfondimento di Deloitte Legal sul cloud switching precisa che il preavviso non può superare i due mesi e che il periodo di transizione è di norma trenta giorni, estendibile fino a sette mesi solo in casi eccezionali. L’ambito coperto è ampio: IaaS, PaaS e SaaS, quindi buona parte delle piattaforme su cui gira un agente aziendale.

Quanto costa uscire, e perché dal 2027 costerà meno

Sui costi il calendario è scritto: fino al 12 gennaio 2027 il fornitore può applicare switching charges ridotte, che non devono superare i costi effettivamente sostenuti e direttamente collegati al passaggio; da quella data in poi le switching charges sono vietate, come ricostruiscono sia Alston & Bird sia Deloitte Legal. Restano possibili le penali proporzionate di recesso anticipato, e resta un’area grigia, la segnala Deloitte Legal, sulla distinzione tra costo di switching e «funzionalità premium», per esempio la conversione dei dati in un formato specifico o l’estensione del periodo di recupero sul vecchio ambiente. Traduzione pratica per chi sta negoziando oggi: chiedete che il contratto elenchi nero su bianco formati di export e tempi di restituzione, perché è lì che si decide se l’uscita sarà una procedura o una trattativa.

Come si progetta la migrazione senza fermare l’azienda

Una migrazione riuscita non è un weekend di lavoro con lo switch acceso il lunedì mattina. È un percorso in fasi, dove il vecchio sistema resta in piedi finché il nuovo non ha dimostrato di funzionare sui vostri casi reali. La sequenza che regge alla prova dei fatti è questa.

Prima l’estrazione, poi la trattativa. Esportate tutto ciò che è esportabile mentre il rapporto è ancora sereno: prompt e loro versioni, log delle conversazioni, documenti indicizzati nella knowledge base, mappa delle integrazioni attive, configurazioni. Farlo dopo aver annunciato il recesso è legittimo ma più lento, e vi mette in posizione debole.

Poi il parallel running: il nuovo agente lavora in ombra sugli stessi input del vecchio, senza rispondere ai clienti, per un periodo che permetta il confronto su volumi veri e non su una demo. Si misurano le stesse cose, tasso di risoluzione, escalation verso l’operatore, errori fattuali, latenza, e si passa solo quando i numeri del nuovo sono almeno pari a quelli del vecchio. La guida di Master of Code suggerisce un test diagnostico che vale la pena adottare come metrica permanente: se il fornitore primario sparisse oggi, quanto tempo servirebbe per rimettere in piedi questo processo altrove? Il benchmark proposto è trenta giorni senza ricostruire l’applicazione. Se la vostra risposta è «non lo sappiamo», quello è già il risultato del test.

Cosa si recupera e cosa va rifatto nella migrazione

Serve realismo su cosa sopravvive. Sopravvivono i contenuti: documenti, procedure, FAQ, storico delle conversazioni, se avete i file sorgente. Sopravvive la logica di business, cioè la descrizione di cosa l’agente deve fare e in quali casi passare la mano a una persona. Sopravvive la mappa delle integrazioni come specifica funzionale, anche quando il codice va riscritto. Vanno invece ricalibrati i prompt, perché un prompt ottimizzato per un modello rende diversamente su un altro, e vanno rigenerati gli embedding se cambia il modello di embedding. È la stessa dinamica che si incontra nella migrazione da un chatbot a un agente AI: il patrimonio di conoscenza si porta dietro, l’accordatura si rifà. Chi vi promette una migrazione «trasparente al 100%» sta vendendo una semplificazione.

Compliance: cosa si riusa e cosa va rivalutato

C’è un timore che blocca molte migrazioni: ricominciare da capo con l’intero impianto privacy e conformità. È un timore in larga parte infondato, e l’analisi di heyData sul cambio di provider AI lo spiega con un principio utile: a contare è il caso d’uso, non il fornitore. Se l’uso resta lo stesso, restano validi la policy AI interna, la valutazione del caso d’uso, i processi di supervisione umana e la formazione generale del personale.

Cosa va rifatto quando si cambia fornitore agente AI

Va invece rifatto ciò che è legato al soggetto: il contratto di nomina a responsabile del trattamento con il nuovo fornitore, la verifica delle certificazioni di sicurezza, le impostazioni di retention e soprattutto l’opt-out dall’addestramento dei modelli sui vostri dati. Vanno aggiornati il registro dei trattamenti e la parte di DPIA che riguarda le misure tecniche cambiate. Sul fronte AI Act, l’azienda utilizzatrice è quasi sempre deployer e non provider, e cambiare strumento raramente sposta i suoi obblighi: l’articolo 26 del regolamento impone al deployer di affidare la sorveglianza umana a persone con competenza, formazione e autorità adeguate, di monitorare il funzionamento secondo le istruzioni del fornitore e di conservare i log generati automaticamente per un periodo adeguato, comunque non inferiore a sei mesi. Chi porta la responsabilità, in Italia, lo abbiamo approfondito parlando di AI Act e agenti aziendali.

Un dettaglio pratico da mettere nel nuovo contratto, suggerito dal playbook sui fornitori AI terzi: l’obbligo di notifica preventiva quando il fornitore cambia il modello sottostante. Un cambio di modello non annunciato può spostare accuratezza e comportamento del vostro agente da un giorno all’altro, e scoprirlo dai reclami dei clienti è il modo peggiore.

Quando invece non conviene cambiare fornitore

Ci sono situazioni in cui la migrazione è una reazione emotiva travestita da decisione strategica, e vale la pena nominarle.

Non conviene cambiare se il problema è un singolo incidente, per quanto fastidioso, in un rapporto che negli altri dodici mesi ha funzionato. Non conviene se il malcontento nasce da aspettative mai messe per iscritto: se nessuno ha mai definito cosa l’agente doveva fare e con quali soglie di qualità, il fornitore successivo vi deluderà esattamente allo stesso modo, perché il vuoto è a monte. Non conviene se il vero problema è interno, nessuno in azienda presidia il progetto, i contenuti non vengono aggiornati, le segnalazioni non arrivano mai al fornitore, perché un cambio di fornitore non compra un presidio interno che non esiste.

E non conviene, banalmente, quando il conto non torna: se il costo stimato di migrazione supera il risparmio annuo atteso e il fornitore attuale è solo mediocre, non disastroso, la mossa razionale è rinegoziare con dati alla mano. Portate al tavolo le metriche mancate e chiedete che entrino nel contratto. Se il fornitore rifiuta di farsi misurare, avete ottenuto comunque l’informazione che vi serviva. Su come impostare questa valutazione, sono utili i sette criteri per scegliere un partner per gli agenti AI, applicati al fornitore che avete già.

Come si sceglie il prossimo fornitore di agente AI

Se la decisione è di cambiare, il criterio guida è semplice da enunciare e scomodo da applicare: valutate il nuovo fornitore sulla facilità con cui potreste lasciarlo. Un partner che risponde bene a questa domanda in fase di vendita è lo stesso che vi darà documentazione leggibile, export in formati standard e nessuna sorpresa contrattuale.

Le tre domande da fare al nuovo fornitore di agente AI

Tre domande da fare al primo incontro. La prima: in che formato mi restituite prompt, knowledge base e log, e in quanti giorni? La seconda: quante persone della vostra struttura conoscono il mio progetto, e dove sta scritto ciò che sanno? La terza: se cambiate il modello sottostante, come me lo comunicate e con quale preavviso? La strategia multi-modello descritta da AvePoint aggiunge un punto spesso trascurato: la diversificazione va pensata a livello di modello e non solo di fornitore, perché prezzi e capacità si spostano anche all’interno del catalogo di uno stesso provider. Lo stesso principio di governance vale nel procurement più in generale, dove l’analisi di Ivalua ricorda che la supervisione umana resta necessaria perché le raccomandazioni automatiche restino allineate alla strategia aziendale.

Export e documentazione: cosa deve garantire un fornitore di agente AI

Su questo noi di Mimir abbiamo una posizione dichiarata, ed è il motivo per cui questo articolo esiste. Chi lavora con noi riceve dall’inizio ciò che rende possibile una migrazione futura: documentazione del sistema leggibile da chiunque, dati e configurazioni esportabili, integrazioni costruite su standard aperti dove possibile. E riceve una cosa che il prodotto da solo non dà mai: un affiancamento dedicato nella fase di onboarding, perché un agente AI che nessuno in azienda sa governare diventa un costo fisso nel giro di sei mesi. Vendiamo un servizio oltre al software, è la differenza tra un agente chiavi in mano e uno self-service, e quella differenza si vede proprio nei momenti come questo.

Se state valutando un cambio di fornitore e volete un parere su cosa si può salvare del lavoro già fatto, potete parlarne con noi: una consulenza iniziale serve soprattutto a capire se cambiare conviene davvero, e in diversi casi la risposta onesta è che conviene prima rinegoziare. Trovate come contattarci su mimir.bot.

Fonti:

• Gartner, oltre il 40% dei progetti di AI agentica cancellati entro il 2027
• Master of Code sull’AI vendor lock-in
• Model Context Protocol, documentazione ufficiale
• Commissione europea, pagina ufficiale del Data Act
• Alston & Bird sui requisiti di switching del Data Act
• Deloitte Legal sul cloud switching e il Data Act
• Agenda Digitale, diritto alla portabilità e cambio fornitore
• heyData sul cambio di provider AI e compliance
• AI Act, articolo 26, obblighi del deployer
• Playbook sulla gestione dei fornitori AI terzi
• AvePoint, strategia multi-modello contro il lock-in
• Ivalua, agenti AI nel procurement