Cloud exit plan: se non sai uscire, non hai scelto un fornitore

La domanda giusta sul cloud non è “quanto costa entrare?”. È “quanto costa uscire, e in quanti giorni?”. Nelle PMI italiane questa domanda arriva quasi sempre tardi: quando il listino cambia, quando il supporto non risponde, quando un servizio è diventato indispensabile e nessuno ricorda più quali dati siano finiti dove.

Il cloud non è un matrimonio. È un rapporto industriale, regolato da contratti, dipendenze tecniche e responsabilità operative. Se l’uscita non è prevista all’inizio, diventa una trattativa in emergenza. E in emergenza vince quasi sempre chi possiede la piattaforma, non chi possiede i dati.

La sovranità tecnologica, per una PMI, non significa costruirsi un data center in cantina. Significa poter cambiare fornitore senza bloccare fatturazione, produzione, posta, CRM, e-commerce, backup e strumenti AI. Significa sapere quali pezzi sono sostituibili, quali no, e quali richiedono un piano di rientro realistico. Non è ideologia: è continuità operativa.

1. Il lock-in non è un difetto: è una scelta commerciale

Il vendor lock-in non nasce perché i grandi provider siano “cattivi”. Nasce perché il modello economico del cloud premia l’adozione di servizi sempre più integrati. Storage, database gestiti, identità, monitoraggio, AI, automazioni, sicurezza, backup: ogni servizio risolve un problema reale, ma aggiunge una dipendenza.

Per una PMI questa dinamica è seducente. Si parte con una migrazione rapida, magari spinta da un’esigenza concreta: liberarsi del server vecchio, far lavorare meglio il commerciale, mettere in sicurezza la posta, introdurre un sistema di ticketing. Poi arrivano automazioni, analytics, AI generativa, integrazioni con il gestionale. Dopo due anni non si ha più “un cloud”: si ha un ambiente operativo che parla una lingua specifica.

Il punto non è evitare ogni servizio proprietario. Sarebbe una posizione comoda da convegno e inutile in azienda. Alcuni servizi gestiti fanno risparmiare tempo, competenze e incidenti. Il punto è decidere consapevolmente dove accettare il lock-in e dove no.

Un database proprietario per un’applicazione marginale può essere un compromesso accettabile. L’identità aziendale, il backup, i log di sicurezza e gli archivi documentali critici sono un’altra storia. Se quei componenti non sono esportabili, replicabili o leggibili fuori dalla piattaforma, la PMI non ha comprato efficienza: ha ceduto leva negoziale.

La differenza si vede al rinnovo. Il fornitore che sa di essere sostituibile discute. Il fornitore che sa di essere diventato infrastruttura inevitabile manda un nuovo listino.

2. La normativa apre spazio, ma non fa il lavoro al posto vostro

L’Europa ha capito che il lock-in infrastrutturale non è solo un tema commerciale. Il Data Act (Regolamento UE 2023/2854) dedica un capo specifico al passaggio tra servizi di trattamento dei dati, cioè anche ai servizi cloud. L’obiettivo è ridurre gli ostacoli contrattuali, tecnici ed economici che impediscono a un cliente di cambiare provider.

È un segnale importante: il mercato del cloud non può funzionare se l’uscita è formalmente possibile ma praticamente ingestibile. La norma, però, non trasforma da sola un’architettura confusa in un sistema portabile. Se un’applicazione è costruita su funzioni proprietarie, API specifiche, formati non documentati e automazioni sparse, nessun regolamento la renderà magicamente migrabile in un weekend.

Anche la NIS2 va letta in questa chiave. Impone misure di gestione del rischio cyber che includono continuità operativa, sicurezza della supply chain e gestione degli incidenti. Non dice alle PMI “fate un exit plan cloud” con queste parole, ma la sostanza è quella: se un fornitore critico si ferma o diventa inadeguato, l’azienda deve poter reagire.

Il GDPR aggiunge un altro pezzo, spesso sottovalutato. L’art. 28 richiede che il rapporto con il responsabile del trattamento sia regolato da un contratto con istruzioni documentate, misure adeguate e condizioni per i sub-responsabili. L’art. 32 parla di sicurezza del trattamento e include la capacità di ripristinare la disponibilità e l’accesso ai dati personali in tempi congrui in caso di incidente. Anche qui non basta dire “i dati sono nel cloud”: bisogna sapere come si recuperano, in che formato, con quali tempi e con quali responsabilità.

La normativa crea spazio negoziale. Ma quello spazio va usato nei contratti, nei rinnovi e nei progetti tecnici. Altrimenti resta una bella citazione nel documento del consulente.

3. L’exit plan non è un documento: è una prova di sostituibilità

Molte aziende credono di avere un piano di uscita perché nel contratto c’è scritto che i dati saranno restituiti. È un inizio, non una garanzia. “Restituire i dati” può voler dire un export CSV incompleto, un dump di database senza schema applicativo, un archivio enorme consegnato con costi di traffico in uscita, oppure un insieme di file che nessuno sa reimportare.

Un vero exit plan risponde a una domanda più scomoda: se domani si decide di cambiare fornitore, quali servizi devono ripartire, dove, e con quali perdite accettabili?

Per una PMI non serve un piano da cento pagine. Serve una mappa concreta. Posta e identità. File e documenti. Gestionale. CRM. E-commerce. Database. Backup. Log. Sistemi di produzione. Strumenti AI collegati ai dati aziendali. Per ciascun elemento bisogna sapere chi lo gestisce, dove risiedono i dati, come si esportano, quali dipendenze esterne esistono e quanto tempo serve per rimetterlo in piedi altrove.

La parte decisiva è la prova. Non si testa tutta l’azienda ogni mese, ma almeno un servizio critico va provato davvero. Un export reale. Un restore reale. Una replica parziale. Un login su un provider di identità alternativo. Un set di documenti reindicizzato in un ambiente diverso. Solo così emergono i problemi veri: permessi sporchi, file senza proprietario, API non documentate, licenze non trasferibili, backup cifrati con chiavi controllate dal vecchio fornitore.

L’exit plan è una disciplina di igiene aziendale. Non nasce per “scappare” dal provider, ma per evitare che la relazione diventi sbilanciata. Paradossalmente, le aziende che possono uscire sono quelle che possono restare con più serenità.

4. I quattro punti da mettere nel contratto prima del rinnovo

Il momento migliore per negoziare l’uscita è prima di firmare. Il secondo momento migliore è il rinnovo. Aspettare l’incidente o l’aumento di prezzo significa presentarsi al tavolo senza alternative.

Ci sono clausole che una PMI dovrebbe chiedere senza imbarazzo, anche quando il contratto sembra “standard”. Se il fornitore è serio, non si scandalizza. Se si scandalizza, l’informazione è già utile.

• Export dei dati in formato documentato. Non basta la promessa di restituzione. Servono formati, tempi, eventuali costi, limiti di volume e modalità operative indicati per iscritto. Dove possibile, meglio formati aperti o comunque importabili da strumenti terzi.
• Assistenza alla migrazione. L’uscita non è solo la consegna dei file. Serve un periodo di transizione, con accesso agli ambienti, supporto tecnico e chiarimento sulle dipendenze. Il Data Act spinge proprio sulla rimozione degli ostacoli al cambio di fornitore: va tradotto in pratica contrattuale.
• Cancellazione verificabile. Dopo l’uscita, i dati residui devono essere cancellati secondo tempi e modalità chiare, tenendo conto di backup, log e obblighi di conservazione. Per i dati personali, questo dialoga direttamente con il contratto ex art. 28 GDPR.
• Separazione tra servizio e dati aziendali. Le chiavi di cifratura, gli account amministrativi, i log e i backup non devono diventare ostaggi. Se tutto passa da un solo pannello proprietario, la migrazione sarà più difficile e più costosa.

Questi punti non richiedono una guerra legale. Richiedono metodo. Anche un system integrator italiano ben organizzato può aiutare a tradurre queste esigenze in allegati tecnici semplici, leggibili, collegati al servizio reale. Il vantaggio di lavorare con operatori a misura d’uomo è proprio questo: spesso si parla con chi disegna e gestisce l’ambiente, non solo con un portale di ticket.

Non è una questione di nazionalismo tecnologico. Un grande hyperscaler può essere la scelta giusta per alcuni carichi. Un provider italiano o europeo può esserlo per altri. Il criterio non è la bandiera: è la capacità di governare costi, dati, supporto e uscita.

5. AI e cloud: il nuovo lock-in passa dagli indici, non solo dai modelli

Le PMI stanno introducendo l’AI in modo pragmatico: assistenti per i documenti, ricerca interna, supporto clienti, generazione di offerte, analisi dei ticket. La discussione pubblica si concentra quasi sempre sul modello: quale LLM usare, quanto costa il token, quale risponde meglio in italiano. È una parte del problema, non la più importante.

Il lock-in dell’AI spesso nasce negli strati laterali: connettori, embeddings, database vettoriali, prompt salvati, log delle conversazioni, sistemi di autorizzazione, pipeline RAG, cruscotti di valutazione. Se questi componenti sono costruiti tutti dentro l’ecosistema di un solo fornitore, cambiare modello diventa irrilevante. Si può anche sostituire il motore, ma l’auto resta del noleggiatore.

Una PMI che vuole usare l’AI senza regalare il futuro deve tenere separati alcuni livelli. I documenti aziendali devono restare governati dal sistema documentale e dai permessi esistenti. Gli indici devono essere ricostruibili. I log devono essere esportabili. Le policy di conservazione devono essere chiare. Gli utenti devono accedere tramite identità aziendale, non con account personali o scorciatoie create dal reparto più entusiasta.

Qui l’AI Act entra come contesto, non come spauracchio. Introduce obblighi differenziati in base al rischio e regole specifiche per determinati usi e per i modelli per finalità generali. Ma per molte PMI il primo problema non sarà classificare un sistema ad alto rischio: sarà sapere quali dati sono stati indicizzati, con quali permessi, da quale fornitore, e come spegnere o migrare il servizio senza perdere conoscenza aziendale.

La scelta intelligente è progettare una piccola architettura AI portabile. Non serve complicarla: un ambiente documentale ordinato, un motore di indicizzazione sostituibile, un modello scelto in base al caso d’uso, log consultabili, contratti che escludano l’uso dei dati aziendali per addestramenti non autorizzati. È meno spettacolare di una demo, ma regge meglio il secondo anno.

6. La prossimità operativa vale quando qualcosa non torna

Il cloud è globale finché tutto funziona. Quando qualcosa non torna, diventa improvvisamente locale: chi risponde, in che lingua, con quale autorità, su quale contratto, entro quali tempi. Per una PMI questa differenza pesa più di molti benchmark.

Un provider vicino non è automaticamente migliore. Esistono fornitori locali improvvisati, contratti deboli, infrastrutture poco documentate. Ma la prossimità operativa ha un valore concreto quando si traduce in responsabilità chiare: persone raggiungibili, architetture comprensibili, report leggibili, disponibilità a fare prove di ripristino, trasparenza sui subfornitori, capacità di lavorare con il gestionale e con i processi dell’azienda.

Il mercato italiano ha una rete di system integrator, MSP e provider infrastrutturali che spesso conosce bene le esigenze delle PMI: budget realistici, tempi stretti, poche persone interne, necessità di non fermare il business. Questa rete può essere un vantaggio competitivo, se non viene usata solo per “mettere una pezza” sopra decisioni prese altrove.

La relazione sana è diversa: il fornitore aiuta l’azienda a costruire una piattaforma usabile, documentata e sostituibile. Non promette indipendenza totale, perché non esiste. Promette invece dipendenze visibili. Ed è già molto.

La domanda da fare non è “siete sovrani?”. È troppo generica, troppo facile da trasformare in brochure. Le domande utili sono più semplici: dove sono i dati? chi può accedervi? quali subfornitori usate? come esportiamo tutto? quanto costa uscire? possiamo provare un ripristino? chi decide in caso di incidente? Se le risposte sono vaghe, il problema non è la dimensione del provider. È la maturità del rapporto.

7. Un piano pratico in 60 giorni, senza fermare l’azienda

Una PMI non deve trasformare l’exit plan in un progetto infinito. Deve partire dai sistemi che, se fermi, bloccano fatturato, produzione o reputazione. Il resto viene dopo.

Il primo passo è un inventario essenziale dei servizi cloud e SaaS realmente usati. Non quello teorico approvato tre anni fa: quello effettivo. Account attivi, repository, storage, backup, database, AI, automazioni, integrazioni con il gestionale, strumenti del marketing, piattaforme usate dai consulenti esterni. Lo Shadow IT non si governa fingendo che non esista.

Il secondo passo è scegliere tre servizi critici e chiedere al fornitore una procedura di export. Non una frase commerciale: una procedura. Chi apre il ticket, quanto tempo serve, che formato si ottiene, dove viene consegnato, quanto costa, come si verifica l’integrità, come si reimporta altrove. Questa sola richiesta spesso rivela più di un audit formale.

Il terzo passo è fare una prova piccola. Un sottoinsieme di documenti, un database non enorme, una casella di posta campione, un backup applicativo, un indice AI ricostruito in un ambiente separato. L’obiettivo non è migrare davvero: è misurare l’attrito. Se emergono problemi, meglio scoprirli il martedì mattina con il fornitore disponibile, non il sabato notte durante un incidente.

Il quarto passo è portare le evidenze al rinnovo contrattuale. Non serve riscrivere tutto. Si possono aggiungere allegati tecnici, procedure di uscita, impegni sui formati, tempi di supporto, responsabilità sui backup, obblighi sui subfornitori. Gli artt. 28 e 32 del GDPR danno già una base solida quando ci sono dati personali. La NIS2 rafforza il discorso per le organizzazioni che rientrano nel suo perimetro o lavorano nella loro supply chain.

Il quinto passo è decidere dove ridurre il lock-in. Non tutto insieme. Magari si parte dai backup fuori piattaforma. Poi dai log. Poi dall’identità. Poi dall’AI documentale. Ogni pezzo reso portabile aumenta la libertà aziendale e migliora anche la negoziazione con il fornitore attuale.

Il risultato non è un’azienda “anti-cloud”. È un’azienda più adulta. Usa il cloud perché conviene, non perché non può più farne a meno.

La verità è semplice: se non sapete uscire, non avete davvero scelto. Avete solo iniziato un percorso sperando che prezzo, contratto e supporto restino ragionevoli per sempre. Nella tecnologia, come nei mercati, la speranza non è una strategia. La portabilità sì.