Safety Case — Il Documento di Argomentazione della Sicurezza

Definizione di Safety Case

Il termine Safety Case indica un documento — o un insieme strutturato di documenti — che fornisce una dimostrazione ragionata del fatto che un sistema è sicuro per un determinato utilizzo in un determinato contesto operativo. La struttura logica di base si articola in tre elementi fondamentali:

• Claim (affermazione): un'asserzione di sicurezza che il sistema deve soddisfare (es. "Il sistema di frenatura garantisce la distanza di arresto entro i limiti normativi").
• Argument (argomento): il ragionamento — formale o narrativo — che collega le evidenze al claim, mostrando perché le prove siano sufficienti a supportarlo.
• Evidence (evidenza): i dati, i test, le analisi, le revisioni e le certificazioni che supportano l'argomento in modo oggettivo e verificabile.

Questa triade — spesso sintetizzata con l'acronimo CAE (Claim–Argument–Evidence) — costituisce il nucleo di qualsiasi Safety Case moderno. Il documento non si limita a elencare i rischi: dimostra attivamente che tali rischi sono stati ridotti a un livello tollerabile o che non esistono nelle condizioni operative previste.

Struttura GSN (Goal Structuring Notation)

La Goal Structuring Notation (GSN) è il linguaggio grafico standard più diffuso per rappresentare la struttura di un Safety Case. Definita originariamente dal gruppo di ricerca dell'Università di York e oggi standardizzata da GSN Community Standard (v3, 2021), la notazione prevede sei tipi di elementi:

• Goal (obiettivo di sicurezza): un claim che il Safety Case intende dimostrare, rappresentato graficamente con un rettangolo.
• Strategy (strategia): il modo in cui il Goal viene scomposto in sotto-obiettivi, rappresentata con un parallelogramma.
• Evidence (soluzione/prova): il dato o il documento che supporta direttamente un Goal foglia, rappresentato con un cerchio.
• Context (contesto): informazioni che delimitano l'interpretazione di un Goal o di una Strategy, rappresentate con un rettangolo arrotondato.
• Justification (giustificazione): una motivazione aggiuntiva che rafforza la scelta di una Strategy, rappresentata con un ellisse tratteggiato.
• Assumption (assunzione): un'ipotesi non dimostrata ma necessaria per la validità dell'argomento, rappresentata con un ellisse.

La struttura GSN consente di navigare il Safety Case in modo gerarchico: dal Goal di primo livello ("Il sistema X è sicuro per l'utilizzo Y") si scende progressivamente fino alle singole evidenze, mantenendo tracciabile l'intera catena argomentativa.

Differenza tra Safety Case, Risk Assessment e DVR

I tre strumenti rispondono a esigenze complementari ma distinte:

• Risk Assessment: identifica e valuta i rischi presenti in un sistema o processo, stima la probabilità e la gravità degli eventi indesiderati e definisce le misure di riduzione. È principalmente un atto puntuale di analisi.
• DVR (Documento di Valutazione dei Rischi): è il documento obbligatorio previsto dal D.Lgs. 81/08 per i luoghi di lavoro italiani. Recepisce il Risk Assessment e include il piano di miglioramento, ma non fornisce necessariamente un argomento formale sulla tollerabilità del rischio residuo.
• Safety Case: è più olistico e longitudinale. Non si limita a valutare i rischi, ma dimostra — attraverso argomenti e prove strutturate — che il rischio residuo è accettabile nel contesto specificato. Viene aggiornato continuamente durante il ciclo di vita del sistema e sopravvive alle singole revisioni periodiche del Risk Assessment.

In sintesi: il Risk Assessment misura il rischio, il DVR lo documenta per fini legali, il Safety Case lo argomenta con rigore formale davanti a un organo di accettazione indipendente.

Applicazioni tipiche per settore

Il Safety Case è richiesto o fortemente raccomandato in numerosi settori ad alto rischio:

• Ferroviario: la serie CENELEC EN 50126 / EN 50128 / EN 50129 definisce il ciclo di vita della safety e impone la produzione di un Safety Case formale (denominato anche "Safety Acceptance Record" in EN 50129) per sistemi e sottosistemi ferroviari.
• Aeronautico: DO-178C (software) e DO-254 (hardware) richiedono evidenze strutturate di conformità che alimentano il Safety Case dell'aeromobile, valutato dall'EASA in Europa.
• Nucleare: le Safety Guide IAEA (es. SSG-3 e SSR-2/1) richiedono un Integrated Safety Case per centrali e impianti di ciclo del combustibile.
• Medicale: IEC 62304 (software dispositivi medici) e ISO 14971 (gestione del rischio) compongono insieme le evidenze del Safety Case presentato agli organismi notificati per la marcatura CE.
• Sistemi autonomi e robotica: ISO/PAS 21448 (SOTIF) e ISO 26262 (automotive) richiedono argomenti strutturati sulla sicurezza funzionale e sull'assenza di comportamenti indesiderati in scenari operativi.
• Intelligenza Artificiale: l'approccio Safety Case è sempre più adottato per sistemi AI ad alto rischio, in linea con le raccomandazioni del BSI (PAS 1882:2024) e con i framework emergenti nell'ambito dell'EU AI Act 2024.

Safety Case in Italia: riferimenti normativi

Sebbene la normativa italiana non utilizzi sempre il termine "Safety Case", il concetto è presente in forma implicita o esplicita in diversi contesti regolatori:

• D.Lgs. 26 giugno 2015 n. 105 (Seveso III): per gli stabilimenti di soglia superiore, il Rapporto di Sicurezza (artt. 15 e 16) costituisce di fatto un Safety Case: deve dimostrare che i rischi di incidente rilevante sono stati identificati, valutati e ridotti a livelli ALARP, con argomenti tecnici e prove documentate sottoposte al parere del Comitato Tecnico Regionale (CTR).
• D.Lgs. 10 agosto 2007 n. 162 (sicurezza ferroviaria): recepisce la Direttiva 2004/49/CE e il Regolamento (UE) 402/2013 (CSM-RA), che impone l'uso di un processo strutturato di argomento di sicurezza per le modifiche significative ai sistemi ferroviari, in linea con la metodologia CENELEC.
• Settore offshore e minerario: il D.Lgs. 145/2015 (direttiva 2013/30/UE) impone un documento denominato "Relazione sui grandi rischi" per le installazioni in mare, che rispecchia la struttura logica di un Safety Case.

Safety Case e Intelligenza Artificiale: l'Assurance Case

Con la diffusione dei sistemi di Intelligenza Artificiale in contesti critici, il concetto di Safety Case si evolve in quello di Assurance Case: un argomento strutturato che dimostra non solo la sicurezza, ma anche l'affidabilità, l'equità e la spiegabilità di un sistema AI. Il Regolamento europeo sull'AI (EU AI Act 2024, in vigore progressivamente dal 2026) impone ai fornitori di sistemi AI ad alto rischio la predisposizione di documentazione tecnica e di un sistema di gestione della qualità che, nella prassi, assume la forma di un Assurance Case. Standard come ISO/IEC 42001 (AI Management System) e PAS 1882:2024 (BSI) forniscono i framework di riferimento. L'Assurance Case per l'AI affronta sfide specifiche: la difficoltà di testare esaustivamente sistemi basati su apprendimento automatico, la necessità di documentare i limiti operativi (Operational Design Domain) e di monitorare il comportamento in produzione come evidenza continuativa.

Come costruire un Safety Case

La costruzione di un Safety Case efficace segue un processo iterativo articolato in quattro fasi principali:

• 1. Identificazione dei Goal di sicurezza: a partire dall'analisi degli hazard (HAZOP, FMEA, FTA), si definiscono i claim di sicurezza di alto livello che il sistema deve soddisfare. Ogni Goal deve essere misurabile e verificabile.
• 2. Strutturazione dell'argomento: tramite GSN o notazioni equivalenti (come Arm — Assurance and Risk Management notation), i Goal vengono scomposti in sotto-obiettivi collegati da strategie esplicite, fino ai Goal foglia supportati direttamente da evidenze.
• 3. Raccolta e collegamento delle evidenze: test, analisi, simulazioni, ispezioni, certificazioni di terze parti e dati operativi vengono acquisiti e collegati formalmente ai Goal foglia corrispondenti. Ogni evidenza deve essere tracciabile, datata e verificabile da un revisore indipendente.
• 4. Aggiornamento nel ciclo di vita: il Safety Case non è un documento statico. Ogni modifica rilevante al sistema, al contesto operativo o alla normativa applicabile richiede una revisione dell'argomento e l'acquisizione di nuove evidenze. Il processo di safety case maintenance deve essere pianificato e governato nell'ambito del sistema di gestione della sicurezza dell'organizzazione.