Quando il Villaggio Olimpico non ha un solo perimetro

Quello che Milano Cortina 2026 mi ha insegnato sulla progettazione della sicurezza

Un Villaggio Olimpico, di norma, ha un perimetro: un complesso di edifici, accessi controllati, atleti e delegazioni all’interno. Dal punto di vista della security il vantaggio è evidente, perché separa fisicamente uno spazio protetto dall’ambiente esterno.

A Milano Cortina 2026 quel modello non poteva essere applicato ovunque. I Giochi Olimpici e Paralimpici invernali si sono svolti in un territorio vastissimo, con sei Villaggi distribuiti tra Lombardia, Veneto e Trentino-Alto Adige. A Milano e Cortina erano previste strutture dedicate; a Predazzo una struttura esistente riqualificata. A Bormio, Livigno e Anterselva, invece, gli atleti sarebbero stati ospitati in strutture ricettive esistenti e distribuite sul territorio.

Una scelta organizzativa ragionevole, che permetteva di utilizzare infrastrutture già presenti sul territorio. Ma per la sicurezza poneva un problema tutt’altro che banale.

Come si protegge un Villaggio Olimpico quando il Villaggio, inteso come un unico spazio fisico, non esiste?

Il problema del perimetro

Il perimetro, in un grande evento, organizza gli accessi, governa i flussi, distribuisce le responsabilità e stabilisce a quali condizioni persone, materiali e mezzi entrano in un’area protetta. Funziona, però, solo se racchiude qualcosa che si può davvero delimitare.

Un albergo non è un Villaggio progettato apposta: ha una propria architettura, un’organizzazione, servizi e dipendenze operative. Se gli alberghi sono più di uno e non sono adiacenti, il problema si moltiplica. Non bastava immaginare un confine più grande: un perimetro che avesse racchiuso intere porzioni di una località turistica avrebbe avuto conseguenze difficilmente sostenibili per la vita del territorio e per il funzionamento del sistema olimpico. D’altra parte, rinunciare al perimetro unico non poteva significare rinunciare ai requisiti di sicurezza.

Non era un problema quantitativo: non si trattava di moltiplicare i controlli. Era un problema di architettura.

La decisione a Livigno

Durante la progettazione a Livigno, come Security Manager per i Villaggi, mi fu chiaro che alcuni elementi del masterplan andavano rivisti. Non si trattava di spostare una barriera o modificare un accesso: stavamo cercando di applicare uno schema pensato per una struttura unitaria a un insieme di edifici separati.

Ne discussi con la responsabile della funzione Villaggi e quella di Venue Design & Overlay, la struttura incaricata della progettazione e degli allestimenti delle venue. Ne uscì una soluzione diversa: non considerare il complesso alberghiero come un unico spazio da racchiudere, ma organizzare la protezione in più ambiti autonomi, coordinati nello stesso sistema. Un modello a bolle multiple. Ogni struttura avrebbe avuto una propria configurazione di protezione, mentre la governance della security, le responsabilità e le relazioni con le altre funzioni sarebbero rimaste integrate.

Il modello è stato poi adottato anche nei villaggi alberghieri di Bormio e Anterselva, con gli adattamenti richiesti da ciascuna località.

La soluzione non significava semplicemente moltiplicare i costi. Cambiava il modo in cui la sicurezza veniva costruita. Ogni ambito richiedeva standard comuni e una governance capace di tenere insieme il sistema, ma il modello distribuito permetteva anche di evitare alcune misure proprie di una struttura centralizzata: niente strada “clean”, per esempio, e nessuna necessità di applicare lo stesso livello di controllo a ogni singolo trasferimento.

Non sostengo che fosse la prima volta in cui qualcuno immaginava una protezione distribuita. Per il nostro progetto fu una soluzione specifica a un problema concreto, nata dal confronto tra competenze diverse. Ed è questo, più dell’originalità della soluzione, l’aspetto che ritengo importante.

Il confine fisico non è scomparso. Ha smesso di essere il confine del rischio.

Proteggere senza fermare il Villaggio

Un Villaggio non è soltanto il luogo in cui gli atleti dormono: è un sistema che deve funzionare di continuo. Le persone si muovono, le forniture arrivano, i servizi vanno garantiti, le attività proseguono senza che ogni necessità diventi un’eccezione da gestire. Negli alberghi questa interdipendenza è ancora più evidente.

Prendiamo il trasporto degli atleti. La sicurezza del luogo di partenza, quella del trasferimento e quella della venue di destinazione sono un unico processo: se ogni funzione progetta il proprio pezzo senza confrontarsi con le altre, nascono discontinuità, responsabilità ambigue e procedure incompatibili. Lo stesso vale per la logistica: proteggere una struttura significa capire da quali servizi dipende e come garantirne la continuità. Una misura astrattamente efficace diventa un problema se impedisce il funzionamento delle attività che dovrebbe proteggere.

Per questo non basta chiedersi «Quanto è protetta questa struttura?». Bisogna chiedersi anche «Come funziona questa struttura quando le misure di protezione sono attive?». Le due domande devono avere una risposta coerente. Non significa sacrificare la sicurezza alle esigenze organizzative: significa progettare misure adeguate al rischio e praticabili nel contesto reale.

La Security dentro il progetto, non alla fine

C’è un errore ricorrente: si progetta, si costruisce, si organizza, e alla fine arriva la Security a verificare se tutto sia sufficientemente protetto. È un po’ come chiamare l’ingegnere strutturista quando i muri sono già finiti. Una funzione coinvolta solo a valle può ancora trovare criticità e imporre controlli, ma difficilmente darà il massimo valore.

Quando invece entra nella progettazione, può contribuire a scegliere una soluzione più sicura e più sostenibile fin dall’inizio, individuare un collo di bottiglia prima che diventi un problema, mettere in evidenza una dipendenza che nessun’altra funzione aveva considerato.

A Milano Cortina 2026 uno degli aspetti più impegnativi è stato il raccordo continuo con le altre funzioni: Logistica, Villaggi, Trasporti, Venue Management, Protocollo, Safety, ciascuna con obiettivi, vincoli e responsabilità propri. All’inizio seguivo direttamente molti aspetti, dalla revisione del masterplan alla definizione delle esigenze di security; con la costituzione della struttura e l’arrivo dei collaboratori il lavoro è diventato sempre più coordinamento. La necessità di integrazione, però, non è cambiata.

Il compito della Security non era sostituirsi a quelle competenze, ma assicurare che i requisiti di protezione entrassero nelle decisioni progettuali e operative. E tradurre: trasformare un rischio in una conseguenza operativa comprensibile agli altri, e capire come una decisione presa altrove potesse modificarlo.

Affrontato solo dalla Security, il problema dei villaggi alberghieri avrebbe prodotto richieste difficilmente realizzabili. Affrontato solo dal punto di vista logistico o alberghiero, avrebbe trascurato esigenze di protezione essenziali. La soluzione è nata dall’incontro di queste prospettive, non da una procedura applicata meccanicamente.

La Security non dovrebbe essere il collaudo finale del progetto. Dovrebbe essere una parte del progetto.

Una lezione che va oltre i Giochi

Il ragionamento che ha prodotto il modello dei villaggi alberghieri riguarda molte altre organizzazioni: un’azienda con sedi distribuite, un campus di edifici non contigui, un evento che usa strutture diverse, un’organizzazione in cui persone, servizi e attività dipendono da soggetti differenti. La tentazione è applicare a tutto lo stesso schema. Eppure ciò che funziona in una sede può essere inadeguato in un’altra, una misura efficace non coordinata con quelle adiacenti può creare nuove vulnerabilità, un requisito introdotto troppo tardi può costringere a modifiche costose o a compromessi evitabili.

A Expo Milano 2015 avevo descritto la necessità di conciliare rigidità e flessibilità nella gestione dei controlli logistici. Avevo chiamato questo approccio flexgidity: regole rigide, applicazione flessibile.

A Milano Cortina ho ritrovato lo stesso principio in una forma diversa. Non si trattava di rendere flessibile una procedura, ma di ripensare l’architettura stessa della protezione. I requisiti di sicurezza dovevano restare fermi; era la forma con cui li soddisfacevamo a dover diventare flessibile. Il perimetro non poteva essere unico, ma la governance doveva restare integrata.

In questo senso, considero la flexgidity non come una tecnica legata a un singolo problema, ma come un principio più generale: mantenere rigido ciò che deve esserlo e rendere flessibile ciò che deve adattarsi al contesto.

Da qui traggo tre convinzioni:

• Uno standard guida la progettazione, non la sostituisce. Prima si comprende il contesto, poi si individuano rischi, dipendenze e responsabilità, infine si definiscono le misure, verificando che funzionino nel sistema reale.
• Si può distribuire la protezione senza frammentare la responsabilità. Ambiti autonomi, governance integrata.
• La sicurezza si progetta insieme a chi fa funzionare il sistema. Servono competenze tecniche, certo, ma soprattutto la capacità di far sedere allo stesso tavolo persone che vedono lo stesso problema da prospettive diverse.

Perché la sicurezza non nasce soltanto da ciò che proteggiamo.

Nasce anche da come facciamo lavorare insieme tutto ciò che deve essere protetto.

Francesco di Castri
Security Manager, Villaggi, Cerimonie, IOC e IPC, Fondazione Milano Cortina 2026.

Le considerazioni riportate sono di carattere professionale e personale. Non costituiscono una comunicazione ufficiale della Fondazione Milano Cortina 2026 né descrivono nel dettaglio i dispositivi di sicurezza adottati.