telodico.io

Cloud

Cloud indipendente: il piano d’uscita che le PMI dovrebbero scrivere prima di entrare

Il cloud rende veloci finché non devi cambiare rotta. Per una PMI, la vera scelta non è il logo del provider ma quanto costa e quanto tempo serve per uscire. Ecco come progettare architetture portabili, clausole contrattuali utili e un DR realistico — senza ideologia, con numeri.

9 min

Cloud indipendente: il piano d’uscita che le PMI dovrebbero scrivere prima di entrare

La scelta cloud non è ideologica: è un esercizio di gestione del rischio e del conto economico. Il lock-in non è un incidente, è un modello di business. Per una PMI italiana il tema non è “quale hyperscaler”, ma “quanto mi costa e quanto tempo serve per uscire tra 18 o 36 mesi quando cambiano prezzi, compliance o priorità?”. Chi progetta oggi con un exit plan domani compra flessibilità, negozia meglio e dorme più sereno il sabato notte del disservizio.

1. Non è una crociata: è TCO, tempo e continuità

L’indipendenza dal fornitore non significa rinunciare al cloud, ma conoscere dove la comodità si trasforma in dipendenza costosa. I segnali sono chiari: servizi gestiti proprietari non sostituibili, costi di egress che scoraggiano la migrazione, configurazioni non esportabili, identità legate a un account chiuso.

Scegliere un database “gestito” può essere sensato finché l’engine è standard (PostgreSQL, MySQL) e la configurazione è documentata ed esportabile; è meno sensato quando funzioni proprietarie ti bloccano. Discorso analogo per lo storage: un bucket compatibile S3 è utile, ma la vera portabilità sta nei dati cifrati con chiavi sotto il tuo controllo e in un secondo target di replica fuori dal perimetro del fornitore principale.

Il TCO reale include ciò che non appare nel preventivo: egress, snapshot a lungo termine, inter-region, log retention, supporto premium in emergenza, ore-uomo per rimediare a configurazioni opache. Nella pratica, l’“economia” del managed ha senso se insieme progetti la via d’uscita: tool di infrastruttura come codice davvero portabili, formati aperti, backup testati verso un secondo provider.

2. Il quadro normativo non ti chiede il marchio: ti chiede controllo

  • La direttiva NIS2 (UE) 2022/2555 impone a entità essenziali e importanti misure di gestione del rischio e controlli sui fornitori. Anche se una PMI non rientra direttamente, il requisito “a cascata” arriva con le richieste contrattuali del cliente regolato. Non serve il timbro di un brand; serve dimostrare che sai governare fornitori, dati e continuità.
  • Il GDPR (Reg. UE 2016/679) all’art. 28 obbliga a pattuire con il responsabile del trattamento la restituzione o cancellazione dei dati a fine servizio, e all’art. 32 chiede misure tecniche e organizzative adeguate, inclusi backup e ripristino. Sono riferimenti pratici per pretendere esportabilità, formati leggibili, piani di uscita.
  • Dopo la sentenza Schrems II (C-311/18, 2020) e la decisione di adeguatezza per l’EU–US Data Privacy Framework (2023), il tema delle giurisdizioni extra-UE non è chiuso: va valutato in concreto, anche alla luce del CLOUD Act statunitense (2018). Questo non vieta l’uso di provider globali; richiede però consapevolezza su localizzazione, cifratura, ruoli e trasferimenti.

La morale: indipendenza significa poter dimostrare “controllo effettivo” su dati e ripristino, più che sventolare un’etichetta.

3. Architettura portabile: scegliere gli strati giusti

Una PMI non ha bisogno di soluzioni esoteriche. Servono scelte sobrie che riducono attriti futuri.

  • Dati prima di tutto: preferire engine standard (PostgreSQL, MySQL) e formati aperti (Parquet/CSV per data lake, JSON/Avro per eventi). Scrivere nel contratto il diritto a un export completo e documentato.
  • Storage e cifratura: oggetti compatibili S3 sono diffusi; la differenza la fa la chiave di cifratura in tuo possesso (KMS con “bring your own key” o, meglio, chiavi gestite on-prem/da HSM di fiducia) e la replica asincrona verso un secondo provider europeo.
  • Identità: SAML/OIDC con un Identity Provider sotto il tuo controllo. Evita directory proprietarie non federabili; quando possibile, applicazioni legate a gruppi/ruoli standard, non a utenti locali del provider.
  • Deploy: container dove ha senso, ma senza religione. Kubernetes è utile se il carico lo giustifica; altrimenti VM con IaC bastano. Il punto non è la moda, è poter riprodurre l’ambiente su un secondo fornitore con tempi e costi noti.
  • Osservabilità: log e metriche in un formato portabile, con un endpoint alternativo pronto (anche solo un’istanza dedicata in un secondo datacenter). Niente telemetria chiusa.

Questo è l’asse: dati portabili, identità federata, infrastruttura riproducibile, log fuori da gabbie.

4. Backup e disaster recovery: sovrani perché verificabili

Le PMI spesso rinviano il DR perché “costoso”. È più costoso il fermo non pianificato, o pagare egress e consulenza nel mezzo di una crisi. Il DR indipendente non è necessariamente attivo-attivo; per molte realtà italiane ha senso una combinazione di backup immutabili e cold/warm standby.

  • Obiettivi realistici: RPO di 4–12 ore e RTO di 8–24 ore per applicazioni core sono comunque una svolta rispetto a “si spera”. Mettili nero su bianco e verifica ogni trimestre quanto costa rispettarli.
  • Backup immutabili: snapshot a prova di manomissione (WORM/Object Lock) con chiavi sotto tuo controllo e retention coerente con i tuoi obblighi. Copia offsite presso un secondo provider in Italia o UE. Verifica mensile di ripristino su un ambiente isolato; è l’unica prova che conta.
  • Standby su secondo provider: database secondario promosso on demand, immagini delle VM pronte da avviare, segreti sincronizzati. Il costo è prevedibile: storage + una finestra di compute per i test trimestrali + roadmap di automazioni.

La differenza operativa sta nella prova: un sabato mattina a trimestre si simula la perdita del sito principale e si misura cosa non funziona. È anche la migliore assicurazione contro l’errore umano.

5. Contratti: le clausole che valgono più di uno sconto

Le architetture si rompono sulle clausole mancate. Alcune richieste sono negoziabili con qualsiasi attore, grande o piccolo, se arrivano preparate e motivate da norme e rischio reale.

  • Diritto di audit/assurance: possibilità di ricevere evidenze (rapporti di test, pen test, certificazioni aggiornate) e di condurre audit documentali. Il tema “pre-NIS2”: per contratti già in essere, chiedere un addendum all’atto del rinnovo con un diritto di audit proporzionato e un impegno a colmare gap di sicurezza e continuità secondo un piano condiviso. È una richiesta ragionevole perché le obbligazioni di sicurezza sulla supply chain si stanno standardizzando nella pratica di mercato.
  • Portabilità dei dati: export completo in formati aperti, incluse configurazioni (policy, ruoli, template infrastrutturali), senza costi punitivi. Prevedere un “servizio di handover” a tariffa chiara.
  • Egress e lock-in economico: tetti massimi ai costi di uscita proporzionati ai volumi, e preavviso minimo su cambi tariffari che impattano egress/storage di lungo periodo.
  • Residenza e giurisdizione: localizzazione primaria in UE, indicazione dei subfornitori e delle giurisdizioni coinvolte, notifica in caso di cambiamenti sostanziali. Se usi provider extra-UE, inserire misure aggiuntive (cifratura end-to-end, gestione chiavi) e impegni su contestazione delle richieste di accesso non compatibili con il diritto UE.
  • Continuità operativa: RPO/RTO contrattuali, finestre di manutenzione dichiarate, tempi di escalation, penali o crediti di servizio legati alla capacità di ripristino.
  • Terminazione: obbligo di restituzione o cancellazione certificata dei dati a fine rapporto (eco del GDPR art. 28), supporto alla migrazione per un periodo definito.

Se manca lo spazio per trattare tutto, scegliere due priorità: portabilità ed egress. Senza queste, il resto è retorica.

6. AI senza catene: modelli, dati e gateway

Integrare funzionalità AI non deve significare cedere il controllo. Tre principi pratici:

  • Separare il modello dai dati: i prompt, i contesti e gli output vanno nel tuo database; il fornitore AI non deve diventare il tuo archivio operativo. Questo aiuta anche la conformità al GDPR, perché governi conservazione e cancellazione.
  • Usare un gateway di inferenza: un livello intermedio che ti permette di cambiare modello (proprietario o open source) senza riscrivere l’applicazione. È il corrispettivo AI dell’astrazione infrastrutturale.
  • Scegliere ibrido con criterio: modelli chiusi per use case generici a basso rischio, modelli open source/self-hosted per dati sensibili o dove la latenza di rete e la riservatezza contano. La buona notizia è che modelli compatti specializzati spesso rendono meglio di un generalista costoso su task verticali.

L’AI Act pubblicato nel 2024 rende più chiari ruoli e responsabilità lungo la filiera. Anche senza entrare nella tassonomia, un principio operativo già oggi vale: sapere chi è “fornitore” e chi è “deployers” del sistema e conservare evidenze di come il sistema è stato addestrato, configurato e valutato. Sono informazioni che devono restare di tua proprietà, portabili e auditabili.

7. Da dove iniziare lunedì: 90 giorni per guadagnare indipendenza

Non serve rifare tutto. Serve impostare basi che non si buttano via.

  • Inventario e mappa dipendenze: elencare servizi gestiti, dati critici, costi attuali (incluso egress medio mensile), RPO/RTO desiderati. Identificare le dipendenze proprietarie “dure”.
  • Secondo provider: selezionare un fornitore alternativo in Italia o UE, con cui attivare subito storage di replica e un ambiente minimo di test. Piccolo ma vero.
  • Backup immutabili e test di restore: impostare WORM su dataset critici e provare un ripristino end-to-end su ambiente separato. Documentare tempi e colli di bottiglia.
  • IaC e documentazione: catturare l’infrastruttura esistente in codice o template riproducibili; dove non è possibile, creare runbook dettagliati. Versionare tutto.
  • Clausole al rinnovo: presentare al fornitore un addendum con portabilità, egress cap e audit proporzionato. Ancorare la richiesta a obblighi già noti (GDPR art. 28/32, pratiche NIS2).

Dopo 90 giorni non si è “sovrani”. Ma si è in controllo dei dati, si è ridotto il rischio, si è guadagnato potere negoziale e si sa quanto costa davvero cambiare.

8. Cosa non racconta la slide, ma paga il sabato notte

Il mercato venderà sempre la nuova funzione che semplifica tutto. È legittimo: l’innovazione riduce complessità. Ma un conto è semplificare, un conto è nascondere l’attrito finché uscire diventa antieconomico. L’indipendenza cloud è una postura: progettare dati e identità per restare portabili, pretendere clausole chiare, allenare il ripristino, scegliere partner che capiscono il contesto italiano e parlano la lingua dei tuoi vincoli.

ENISA da anni pubblica guide pratiche sulla sicurezza della supply chain e del cloud per PMI: sono una buona griglia per misurare progressi, non un alibi per rinviare. Le norme europee — NIS2, GDPR e l’AI Act — non chiedono di rinunciare al cloud o all’AI: chiedono che tu sappia dimostrare controllo. Il resto è esecuzione.

La differenza, alla fine, non è il logo sul datasheet. È la tua capacità di scollegarti senza panico quando il contesto cambia. Questo è l’unico “cloud sovrano” che conta davvero per una PMI: quello che puoi lasciare, e riprendere, senza chiedere permesso.

Discussione (0)

Carico…


Per commentare serve un'identità verificata. Inserisci la tua email: riceverai un link per accedere senza password.