L’AI aziendale si ferma come tutto il resto: il backup del modello non basta

La prima applicazione AI di una PMI nasce quasi sempre in fretta. Si collega un modello via API, si caricano un po’ di documenti, si monta un’interfaccia decente e in tre settimane qualcosa che funziona c’è. Poi quel prototipo diventa lo strumento con cui l’assistenza prepara le risposte, il commerciale consulta i listini, i tecnici cercano nei manuali.

A quel punto non è più una dimostrazione: è un servizio aziendale. Solo che nessuno lo ha ancora scritto nel piano di continuità operativa, perché quando il piano è stato fatto quel servizio non esisteva.

Il riflesso più comune è applicare all’AI l’idea di backup presa dai server tradizionali: copiare la macchina virtuale, esportare il database, mettere i file al sicuro. Ma un’applicazione AI è una catena di componenti, versioni e fornitori diversi. Se si salva solo il modello — ammesso che sia possibile — si conserva la parte più facilmente sostituibile e si perde quella che contiene il lavoro fatto in azienda.

La tesi di questo articolo è semplice: nel ripristino di un servizio AI il modello viene per ultimo. Prima vengono le fonti autorevoli, i permessi, le configurazioni, la logica applicativa e la capacità di lavorare in modalità ridotta.

1. Il servizio AI non coincide con il modello

Un assistente documentale sembra un prodotto unico, ma sotto l’interfaccia ci sono almeno: un sistema di identità, un archivio di documenti, una procedura di indicizzazione, un database vettoriale, i prompt di sistema, le regole applicative e uno o più servizi cloud. Spesso si aggiungono i connettori verso CRM, gestionale, ticketing e posta.

Il modello linguistico è un anello della catena. Nella maggior parte dei casi arriva da un’API esterna e non appartiene all’azienda: può cambiare versione, prezzo, limiti di utilizzo o disponibilità senza che voi possiate farci nulla. Anche quando gira su server vostri, in caso di ripristino restano da rimettere in piedi runtime, driver, parametri, dipendenze e integrazione con il resto.

La prima domanda di continuità operativa, quindi, non è «abbiamo una copia del modello?», ma «quale processo si ferma se questo servizio smette di rispondere?». La risposta determina tutto il resto: quanto tempo potete stare fermi, quanti dati potete permettervi di perdere, come si lavora nel frattempo.

Se l’AI propone bozze che una persona può scrivere a mano, qualche ora di fermo è un fastidio gestibile. Se smista richieste urgenti, assegna ticket o alimenta un passaggio di produzione, la tolleranza è un’altra. Gli obiettivi di ripristino vanno assegnati al servizio reso al business, non alla tecnologia che compare nella fattura del fornitore.

È anche la lettura coerente con il quadro normativo. L’articolo 32 del GDPR chiede la capacità di ripristinare tempestivamente disponibilità e accesso ai dati personali in caso di incidente, e in più una procedura per verificare e valutare regolarmente l’efficacia delle misure adottate. Dichiarare che un backup esiste non basta: va dimostrato che da quel backup il servizio torna utilizzabile.

2. Che cosa va conservato davvero (e che cosa si ricostruisce)

Per ripristinare un’applicazione AI non serve copiare tutto con la stessa frequenza. Serve distinguere ciò che è autorevole, ciò che è ricostruibile e ciò che è meglio non conservare affatto.

Un database vettoriale contiene migliaia di rappresentazioni numeriche dei vostri documenti. Copiarlo ogni ora può essere costoso e inutile, se l’indice si rigenera dai file originali. Ma la rigenerazione è possibile solo se avete conservato anche il modello di embedding usato e la sua versione, le regole con cui i testi sono stati spezzati, i metadati che collegano ogni frammento al documento di origine e ai relativi permessi. Senza quei dettagli, l’indice non si ricostruisce: si rifà da zero, con risultati diversi.

Il patrimonio da proteggere si riduce a cinque gruppi:

• le fonti autorevoli, con versioni, metadati, classificazione e diritti di accesso;
• i prompt di sistema, le regole applicative, i flussi di lavoro e le configurazioni dei connettori;
• i manifesti di installazione, le versioni dei modelli, i parametri di generazione e le dipendenze software;
• i casi di test usati per verificare qualità, permessi e comportamento dopo il ripristino;
• la documentazione per ricreare identità tecniche, segreti e collegamenti — senza archiviare credenziali in chiaro.

Questa separazione tiene bassi i costi. Una PMI non deve duplicare GPU, database e capacità cloud in tempo reale: conserva gli elementi non sostituibili, automatizza la ricostruzione di quelli derivati e si tiene pronta la capacità aggiuntiva da attivare solo in caso di incidente.

Un avvertimento che vale più di molti altri: non affidate tutto a uno snapshot opaco della stessa piattaforma che ospita il servizio. Se il problema riguarda l’account, il piano di controllo o il contratto, la copia diventa irraggiungibile insieme all’ambiente primario. Un backup utile attraversa almeno uno dei confini che possono causare il fermo: account, regione, piattaforma o fornitore.

3. Dati, permessi e indice devono tornare insieme

Il ripristino di un sistema AI non è riuscito quando l’assistente ricomincia a produrre testo. È riuscito quando risponde basandosi sulle fonti corrette e rispetta gli stessi confini di accesso che esistevano prima dell’incidente.

È il punto critico dei sistemi che recuperano contenuti dagli archivi aziendali per poi passarli al modello. Se nel ripristino tornano i documenti ma non i permessi, l’assistente può mostrare a un commerciale i dati dell’amministrazione, o restituire a un cliente informazioni di un altro cliente. Tecnicamente il servizio è disponibile; di fatto avete aperto un incidente di protezione dei dati mentre ne state chiudendo un altro.

Anche l’ordine conta. Prima torna il sistema di identità. Poi le fonti autorevoli con i loro metadati. Poi la logica di orchestrazione, poi l’indice, infine il modello. Riaccendere l’interfaccia prima di aver verificato permessi e provenienza delle fonti produce solo un servizio che sembra funzionare.

Il principio di minimizzazione del GDPR aiuta a evitare un altro errore frequente: trattare l’intera cronologia delle conversazioni come materiale indispensabile. Molte sessioni possono essere effimere; altre vanno conservate per ragioni operative, per gestire contestazioni o per controllare la qualità delle risposte. La scelta deve essere esplicita e con tempi definiti, non ereditata dall’impostazione predefinita della piattaforma.

Per i sistemi classificati ad alto rischio, l’AI Act è più prescrittivo: prevede la registrazione automatica degli eventi e requisiti di accuratezza, robustezza e cybersicurezza. La maggior parte delle applicazioni AI di una PMI non rientra in quella categoria. Ma versionare le configurazioni e conservare log leggibili resta utile anche quando non è un obbligo: senza, dopo un incidente nessuno saprà dire quale versione del sistema è stata effettivamente rimessa in piedi.

4. Ripristinare la stessa identica versione potrebbe non essere possibile

Un database si riporta alla versione di ieri. Con un servizio AI esterno non è garantito: il fornitore può aver ritirato un modello, modificato un endpoint o cambiato il comportamento di una versione che continua a chiamarsi allo stesso modo.

Per questo il piano di ripristino deve prevedere la sostituzione di una dipendenza, non solo il suo riavvio. L’applicazione va costruita tenendo separata la logica aziendale dall’interfaccia specifica del modello: prompt, chiamate agli strumenti e formati di risposta versionati e modificabili, non sparsi nel codice o configurati a mano nella console del fornitore.

Sostituibilità non significa che due modelli diano risposte identiche. Significa che il secondo regge il processo entro una soglia accettabile, misurata con domande prese dal lavoro vero: correttezza dei riferimenti, rispetto dei permessi, presenza dei campi obbligatori, quante volte serve passare la mano a un operatore, tempo di risposta.

Qui si vede la differenza tra backup e continuità. Il backup conserva. La continuità permette di lavorare anche quando il componente originale non è più disponibile.

Le strade praticabili sono tre, e nessuna richiede un budget da multinazionale: un secondo modello cloud già configurato e testato; un modello più piccolo ospitato presso un provider italiano, sufficiente a tenere in piedi le funzioni essenziali; oppure una modalità ridotta che non usa affatto AI generativa — ricerca tradizionale nei documenti, risposte precompilate, coda verso un operatore. Per molti processi la terza opzione è più sensata di un failover costoso che nessuno ha mai provato.

5. Mezza giornata di prova vale più di un piano da trenta pagine

La verifica utile non richiede un progetto annuale. Si può partire da un’esercitazione circoscritta: l’API del modello principale non risponde e, nello stesso momento, l’indice vettoriale risulta corrotto. L’ambiente di produzione non si tocca; il team ricostruisce il servizio in uno spazio separato usando solo backup, repository e documentazione disponibili.

Serve un obiettivo dichiarato prima di iniziare. Per esempio: rimettere in funzione entro quattro ore la consultazione dei manuali tecnici, accettando di perdere le conversazioni delle ultime due ore. Quattro ore e due ore non sono valori universali: servono a trasformare l’esercizio in una misura, invece che in un’impressione.

Il team ricrea l’infrastruttura dai manifesti, recupera i documenti, riapplica i permessi, rigenera l’indice. Poi collega un modello alternativo e lancia una ventina di domande già valutate in precedenza. Alcune servono a controllare la qualità delle risposte; altre devono provare deliberatamente ad arrivare a contenuti non autorizzati. Se l’assistente risponde benissimo ma ignora i permessi, la prova è fallita.

Alla fine contano pochi numeri: tempo impiegato, quanti passaggi manuali sono serviti, quali credenziali mancavano, quali dipendenze non erano documentate, quali differenze di comportamento sono emerse. Da lì esce un elenco di cose da sistemare molto più concreto di qualsiasi checklist copiata da un framework.

Per chi rientra nella NIS2 questo lavoro non è un extra: la direttiva (UE) 2022/2555, recepita in Italia con il decreto legislativo 138/2024, include esplicitamente continuità operativa, gestione dei backup, ripristino in caso di disastro e gestione delle crisi tra le misure di gestione del rischio. L’applicazione AI non è fuori da quel perimetro solo perché è stata introdotta dopo l’ultimo aggiornamento del piano.

6. Il fornitore vicino è quello che partecipa al ripristino

Avere i server in Italia conta per contratti, latenza, giurisdizione e trattamento dei dati. Ma la vicinanza geografica, da sola, non produce continuità operativa. Un provider è davvero vicino a una PMI quando rende esportabili dati e configurazioni, documenta le dipendenze e accetta di partecipare a una prova di ripristino con le vostre persone.

Nel contratto devono essere leggibili almeno: dove stanno i dati e dove stanno i backup, quali subfornitori sono coinvolti, come si esportano i contenuti, con quali tempi arriva l’assistenza durante un incidente e che cosa succede alla cessazione del servizio. Per le componenti gestite va chiarito chi può ricreare indici, pipeline e identità tecniche. Un impegno generico di disponibilità al 99,9% non risponde a nessuna di queste domande.

È qui che un system integrator italiano di dimensioni umane offre un vantaggio reale: non perché sostituisca d’ufficio i grandi cloud, ma perché può tenere insieme applicazione, infrastruttura e processo aziendale. Può custodire i runbook in uno spazio che resta vostro, automatizzare le ricostruzioni e presentarsi alla prova di ripristino insieme a chi quel servizio lo userà davvero durante un fermo.

L’assetto più equilibrato non è quasi mai «tutto in casa». Più spesso è una combinazione: modello esterno per il lavoro quotidiano, archivio documentale sotto controllo aziendale, backup separati dalla piattaforma, modalità alternativa pronta altrove. L’obiettivo non è replicare ogni componente, ma evitare che un singolo account o una singola API possano azzerare l’intero servizio.

Un’applicazione AI diventa adulta quando smette di dipendere dalla speranza che il fornitore sia sempre disponibile. Non si tratta di prepararsi a una catastrofe improbabile: si tratta di sapere quali pezzi ricostruire, in che ordine e con quale risultato minimo accettabile. Per una PMI questa disciplina non aggiunge burocrazia — toglie ore di improvvisazione proprio nel momento in cui improvvisare costa di più.