Cloud vicino non significa piccolo: perché la prossimità operativa vale più dello sconto

La domanda sbagliata è: «quanto costa al mese?». La domanda giusta è: «chi risponde quando il gestionale non parte, i dati non si ripristinano e il ticket resta in coda?».

Per molte PMI italiane il cloud è stato comprato come si compra una commodity: un listino, una console, una carta di credito, qualche istanza accesa. Funziona finché tutto resta semplice. Poi arriva il primo incidente serio, la prima migrazione obbligata, il primo aumento di prezzo, il primo audit di un cliente più grande. A quel punto si scopre che la distanza non è geografica: è operativa.

Il punto non è scegliere «italiano» per patriottismo digitale, né fingere che gli hyperscaler non abbiano qualità tecniche enormi. Il punto è più concreto: una PMI senza un team cloud interno ha bisogno di infrastruttura, supporto e contratti che parlino la lingua del suo rischio. E questa combinazione si trova spesso meglio presso provider e system integrator vicini, competenti, raggiungibili, abituati a lavorare con aziende che non hanno un ufficio legale da trenta persone.

1. Il cloud non è una bolletta: è una catena di responsabilità

L’equivoco degli ultimi anni è stato trattare il cloud come una fornitura elettrica. Si accende, si paga, si consuma. In realtà il cloud è una catena di responsabilità tecniche e contrattuali: chi gestisce l’hardware, chi configura la rete, chi cifra i dati, chi controlla gli accessi, chi fa il backup, chi testa il ripristino, chi comunica un incidente.

La cosiddetta shared responsibility non è uno slogan da slide commerciale. È il punto in cui molte PMI si fanno male. Il provider mette a disposizione una piattaforma; l’azienda resta responsabile di gran parte delle scelte applicative, delle configurazioni, delle identità, della conservazione dei dati e della continuità operativa. Se nessuno presidia questa zona grigia, il cloud diventa solo un server remoto con una fattura più complicata.

Per una PMI il problema non è avere meno tecnologia: è avere meno persone per governarla. Un’azienda manifatturiera, uno studio tecnico evoluto, un distributore B2B o una software house di provincia possono essere molto più digitali di quanto sembrino. Ma raramente hanno un cloud architect, un security engineer, un responsabile della conformità e un ufficio acquisti specializzato. Il fornitore deve quindi coprire una parte di questa complessità, non nasconderla dietro una console.

Qui entra il tema della prossimità operativa. Non significa che il data center debba stare a dieci chilometri dall’ufficio. Significa che esiste qualcuno che conosce l’ambiente, sa com’è fatto il backup, sa leggere un log, può intervenire su firewall e storage, può spiegare all’amministratore delegato cosa sta succedendo senza aprire una catena infinita di ticket.

Il cloud «vicino» vale quando riduce il tempo tra problema e decisione. Se invece è solo un’etichetta commerciale sopra una rivendita anonima, non vale più di qualsiasi altra offerta.

2. Sovranità pratica: supporto, contratti, giurisdizione

La sovranità tecnologica non si misura con la bandierina sul sito del provider. Si misura nei contratti, nei subfornitori, nelle procedure di risposta agli incidenti e nella possibilità reale di uscire senza rifare l’azienda da zero.

Sui dati personali il GDPR è chiaro su alcuni snodi. L’art. 28 disciplina il rapporto tra titolare e responsabile del trattamento: il fornitore che tratta dati per conto dell’azienda deve essere vincolato da istruzioni, misure adeguate, regole sui sub-responsabili e assistenza al titolare. L’art. 32 richiede misure tecniche e organizzative adeguate al rischio, incluse riservatezza, integrità, disponibilità e resilienza dei sistemi. Gli articoli sui trasferimenti verso Paesi terzi (dall’art. 44 in poi) regolano i casi in cui i dati escono dallo Spazio economico europeo. Non sono dettagli da studio legale: sono domande operative da porsi prima di mettere ERP, file server, CRM o dati dei clienti su una piattaforma.

La localizzazione in Italia o in Europa non risolve tutto, ma semplifica molto. Un contratto soggetto al diritto italiano o comunque europeo, con data center dichiarati, subfornitori elencati, supporto in italiano e tempi di risposta comprensibili è più facile da governare per una PMI. Non perché il resto sia automaticamente sbagliato: perché quando qualcosa si rompe, la chiarezza contrattuale conta quanto la banda disponibile.

C’è poi un aspetto spesso ignorato: la giurisdizione del fornitore e del gruppo societario. Un servizio erogato da una società europea può essere più governabile di un servizio venduto da una controllata locale ma integrato in profondità con infrastrutture e processi extraeuropei. Non sempre questo comporta un divieto o un problema immediato. Però va capito, scritto e valutato. La sovranità non è una posa: è sapere chi può accedere a cosa, in base a quale legge, con quale procedura e con quale possibilità di opposizione o notifica.

Per le PMI tutto questo non deve diventare un romanzo burocratico. Bastano documenti essenziali ma leggibili: contratto principale, accordo sul trattamento dei dati, elenco dei subfornitori, SLA, procedura di notifica degli incidenti, condizioni di uscita. Se il provider non riesce a produrli, o li produce solo in forma generica e non negoziabile, il prezzo basso va riletto per quello che è: un trasferimento di rischio.

3. L’AI rende il problema più urgente, non più astratto

L’arrivo dell’AI in azienda sposta il baricentro della scelta cloud. Finora molte PMI hanno messo nel cloud posta, documenti, backup, gestionali, qualche database. Ora iniziano a volerci portare knowledge base, contratti, offerte commerciali, ticket di assistenza, disegni tecnici, dati di produzione. Non sono solo «file»: sono il patrimonio informativo dell’azienda.

Una chat interna sui manuali tecnici, un motore di ricerca semantico sui documenti, un assistente per il customer care o un sistema di classificazione automatica delle email possono creare valore reale. Ma se per farli funzionare si copiano dati sensibili dentro servizi non governati, il beneficio iniziale si paga con una perdita di controllo. Il problema non è l’AI in sé: è l’architettura frettolosa con cui viene introdotta.

Un cloud vicino e ben gestito può offrire una via intermedia molto concreta. I dati restano in uno storage controllato, il database vettoriale è separato dal modello, i log sono configurati con criterio, gli accessi passano dall’identità aziendale, le chiamate verso modelli esterni sono tracciate o filtrate. Se domani conviene cambiare modello, si cambia il motore, non tutto il sistema.

È un approccio particolarmente utile per le PMI che non vogliono costruire un laboratorio AI interno. Non serve comprare GPU a caso o inseguire ogni modello uscito la settimana prima. Serve un ambiente gestito dove fare inferenza, retrieval e automazioni con regole chiare. Un buon system integrator può predisporre un layer applicativo sopra modelli diversi, anche open source quando ha senso, evitando che ogni reparto apra account personali su strumenti scollegati.

L’AI Act aggiunge un motivo in più per ragionare bene dall’inizio. Il Regolamento (UE) 2024/1689 chiede a fornitori e deployer di sistemi di AI di garantire un livello adeguato di alfabetizzazione (AI literacy) del personale coinvolto. Tradotto per una PMI: non basta «mettere il chatbot». Bisogna sapere chi lo usa, per cosa, con quali limiti, su quali dati e con quale supervisione. Un’infrastruttura governata rende la formazione più semplice, perché riduce la giungla degli strumenti.

4. Le cinque domande che separano un fornitore da un rischio nascosto

La prossimità operativa si verifica con domande precise. Non con una visita al data center, non con la brochure, non con la promessa «siamo flessibili». Prima di rinnovare o migrare, una PMI dovrebbe mettere sul tavolo cinque punti.

• Chi risponde durante un incidente e con quali tempi? Serve distinguere tra help desk commerciale, supporto tecnico di primo livello e persone autorizzate a intervenire davvero sull’infrastruttura. Uno SLA generico al 99,9% non dice abbastanza se non chiarisce tempi di presa in carico, escalation e canali di emergenza.
• Come vengono fatti e testati backup e ripristino? Il backup non è una casella verde nella console. Conta dove viene conservato, con quale retention, se è immutabile, chi può cancellarlo, quanto tempo serve per ripristinare un sistema e quando è stato fatto l’ultimo test.
• Come si esce dal servizio? I dati devono essere esportabili in formati documentati. Immagini, database, oggetti e configurazioni devono avere una strada d’uscita. Anche i costi di egress e le attività professionali di dismissione vanno chiariti prima, non quando la relazione è già deteriorata.
• Quali subfornitori entrano nella catena? Hosting, backup, monitoraggio, ticketing, logging, antispam, strumenti di amministrazione remota: ogni pezzo può introdurre un rischio. L’elenco dei sub-responsabili previsto dall’art. 28 GDPR non è burocrazia, è una mappa della dipendenza.
• Come viene comunicato un incidente di sicurezza? La NIS2 insiste su misure di gestione del rischio cyber, continuità operativa, sicurezza della supply chain, controllo degli accessi e gestione degli incidenti. Anche quando una PMI non rientra direttamente tra i soggetti essenziali o importanti, può essere fornitore di qualcuno che invece vi rientra. E la catena chiederà evidenze.

Queste domande hanno un pregio: non richiedono un grande ufficio acquisti. Richiedono solo di smettere di comprare infrastruttura come se fosse un abbonamento telefonico. Il fornitore serio non si offende. Anzi, spesso apprezza un cliente che sa distinguere tra costo e rischio.

5. Ibrido non significa confuso: cosa tenere vicino e cosa lasciare dove conviene

L’alternativa al lock-in non è rifare tutto in casa. Questa caricatura ha fatto danni. Una PMI può usare SaaS globali, cloud europei, provider italiani e infrastruttura on-premise nello stesso disegno, purché ci sia un criterio. Il problema non è l’ibrido: è l’ibrido casuale.

Alcuni servizi possono restare dove il mercato ha già creato economie di scala difficili da replicare: posta elettronica, collaboration, strumenti verticali molto maturi, piattaforme con ecosistemi forti. Anche qui servono backup indipendenti, gestione delle identità e clausole decenti, ma non sempre ha senso cercare alternative artigianali.

Altri carichi meritano invece una prossimità maggiore. Database gestionali, documentale, repository tecnici, sistemi di produzione, ambienti di AI sui dati aziendali, backup, disaster recovery, VPN, directory e log di sicurezza sono componenti dove controllo, reversibilità e supporto fanno la differenza. Non perché debbano stare tutti nello stesso posto, ma perché vanno governati con un disegno unico.

Una buona architettura per PMI non è necessariamente sofisticata. Può partire da pochi principi: database su tecnologie standard, storage compatibile con API diffuse, backup separato dal tenant principale, identità centralizzata, logging conservato fuori dalla macchina applicativa, documentazione minima ma aggiornata. Chi usa Kubernetes senza competenze interne spesso sta solo spostando complessità. Chi usa una VM ben gestita, con backup testato e monitoraggio serio, a volte sta facendo una scelta più matura.

Il disaster recovery va trattato allo stesso modo. Non serve promettere ripartenze miracolose in quindici minuti se nessuno ha mai provato la procedura. Meglio definire RPO e RTO realistici: quanti dati si possono perdere e per quanto tempo si può restare fermi. Per alcune applicazioni bastano quattro ore; per altre ventiquattro sono accettabili; per il gestionale in piena stagione magari no. La maturità sta nel decidere, non nel comprare la sigla più costosa.

6. Migrare senza fare un progetto faraonico

La buona notizia è che una PMI non deve trasformare la scelta cloud in un programma triennale. Può procedere in modo incrementale, con un system integrator che conosce il territorio e un provider capace di assumersi responsabilità precise. La velocità resta un vantaggio delle PMI, finché non diventa improvvisazione.

Il primo passo è l’inventario. Non un censimento perfetto da grande gruppo, ma una lista onesta dei sistemi: applicazione, dati trattati, utenti, dipendenze, backup, criticità, contratto in essere. In molte aziende questa mappa non esiste. Farla emergere produce valore già prima della migrazione, perché rende visibili servizi dimenticati, account personali, licenze duplicate e backup solo presunti.

Il secondo passo è scegliere un perimetro pilota. Non si migra tutto insieme. Si parte da un’applicazione importante ma non letale, da un ambiente di test, oppure da un nuovo servizio AI interno che non trascina il passato. L’obiettivo è verificare supporto, procedure, prestazioni, costi e qualità della relazione. Un fornitore che brilla in prevendita ma sparisce al primo problema tecnico va scoperto presto.

Il terzo passo è fissare standard minimi riutilizzabili: naming, rete, firewall, backup, gestione degli accessi, monitoraggio, documentazione, ruoli di amministrazione. Così ogni migrazione non diventa un caso a sé. Anche qui la prossimità aiuta: un integratore che conosce l’azienda può costruire un modello operativo sostenibile, non una cattedrale cloud che nessuno saprà mantenere.

Il quarto passo è provare l’uscita. Sembra paradossale, ma è il test più serio. Esportare un database, ripristinare una macchina in un ambiente diverso, recuperare un bucket, ricostruire una configurazione dalla documentazione: sono attività che mostrano subito quanto l’infrastruttura sia davvero sotto controllo. Se l’uscita è impossibile dopo tre mesi, lo sarà ancora di più dopo tre anni.

Questo percorso non richiede di rinunciare ai grandi vendor. Richiede di non consegnare loro ogni leva decisionale. Una PMI può tenere servizi SaaS globali, usare un hyperscaler per workload specifici, appoggiarsi a un cloud provider italiano per dati e applicazioni core, e farsi accompagnare da un system integrator locale. L’importante è che qualcuno tenga il disegno complessivo e che i contratti non raccontino una realtà diversa dall’architettura.

7. Il criterio finale: chi ti aiuta a decidere quando il manuale non basta

Nel cloud la differenza tra piccolo e grande non coincide con quella tra debole e forte. Ci sono provider locali improvvisati e grandi piattaforme gestite in modo eccellente. Ci sono system integrator che vendono ore senza assumersi responsabilità e altri che diventano un’estensione sana del reparto IT. La scelta va fatta con la stessa scala per tutti: evidenze, contratti, competenze, reversibilità, supporto.

Per una PMI italiana, però, la prossimità operativa ha un valore spesso sottostimato. Quando cambia una norma, quando un cliente chiede garanzie NIS2, quando un auditor domanda dove sono i dati, quando un ransomware colpisce un fornitore, quando un modello AI inizia a trattare documenti riservati, serve qualcuno che non si limiti a indicare una pagina di documentazione. Serve qualcuno che aiuti a decidere.

Il cloud migliore non è sempre quello con più servizi a catalogo. È quello che permette all’azienda di crescere senza perdere il controllo. Se il provider è vicino solo nel marketing, non basta. Se è vicino nei contratti, nelle persone, nelle procedure e nella capacità di ripristinare i dati quando serve, allora la prossimità non è un dettaglio: è una misura concreta di resilienza.