Security by design
Nel mondo digitale contemporaneo, sempre più dipendente da sistemi software complessi e interconnessi, il principio del security by design rappresenta un requisito imprescindibile per garantire elementi essenziali come la continuità operativa, la fiducia degli utenti e la conformità normativa.
La sua attuazione concreta passa attraverso il paradigma dello shift left, che sposta la sicurezza alle fasi iniziali dello sviluppo (nelle visualizzazioni grafiche di pianificazione, l'inizio è mostrato spesso a sinistra). In questo modo la sicurezza diventa un elemento architetturale e strategico e il rischio informatico può essere gestito in modo proattivo, riducendo i costi futuri, integrando le richieste normative (per esempio, AI Act e NIS) e rafforzando la resilienza complessiva.
Threat modeling per l'IA
Il primo passo consiste nell'analisi del rischio per l'IA. Il threat modeling serve a capire, prima di costruire o mettere in produzione un sistema, chi potrebbe attaccarlo, cosa potrebbe ottenere e da quali punti. A differenza del software tradizionale, qui il perimetro include anche prompt di sistema, pipeline RAG, dati, strumenti degli agenti e flussi di autorizzazione. Il risultato pratico è una lista di scenari credibili e delle mitigazioni prioritarie, così le difese da introdurre non sono generiche ma mirate.
Data security by design
Con l'IA, i dati non sono solo "input", ma diventano parte della capacità del sistema. Data security by design significa garantire, lungo tutto il ciclo di vita dei dati, la provenienza, l'integrità, la qualità e i controlli di accesso. Questo perché dati contaminati, incompleti o distorti possono introdurre bias, degradare le prestazioni o abilitare attacchi come il data poisoning. Questo richiede anche di tracciare versioni e trasformazioni, separare dati sensibili, applicare validazioni e controlli prima che entrino nel dataset di addestramento o nei corpus RAG. In poche parole, si rafforzano le misure di sicurezza e qualità dei dati di addestramento.
Sicurezza dei sistemi
Un sistema di IA va trattato come qualunque sistema informatico critico, quindi deve partire da una configurazione sicura dell'infrastruttura e dei servizi. I dati "a riposo" (dataset, indici, log, pesi e configurazioni) devono essere cifrati con algoritmi robusti, e tutte le comunicazioni tra componenti (API, servizi esterni, microservizi, front-end) e verso gli utenti devono avvenire su canali cifrati e protocolli aggiornati, così da ridurre il rischio di intercettazioni e manomissioni.
La resilienza operativa richiede anche pratiche di continuità: backup regolari e verificati di dati, modelli, configurazioni, codice e pipeline, oltre a procedure di ripristino testate. In parallelo serve osservabilità, come log centralizzati e metriche utili (accessi, cambi di configurazione, chiamate a strumenti, errori, anomalie), con alert che arrivino alle persone giuste e permettano di intervenire rapidamente.
Infine, come per altri sistemi critici, vanno previste ridondanze o alternative in caso di indisponibilità prolungata, perché l'IA può diventare un single point of failure (punto singolo di fallimento) per processi di business. Tutto questo deve essere coerente con i requisiti normativi applicabili e con le policy interne, affinché sicurezza tecnica, governance e compliance restino allineate.
Supply chain sicura
Una supply chain sicura per l'IA riguarda tutto ciò che "importiamo" nel sistema, come modelli pre-addestrati, librerie, dataset, container e servizi esterni. L'obiettivo è ridurre il rischio di componenti malevoli o vulnerabili, verificando origine e integrità (per esempio tramite checksum, firme, repository affidabili) e gestendo le dipendenze con pratiche di SCA (Software Composition Analysis, analisi automatica delle dipendenze e delle vulnerabilità note).
In più, passare da SBOM (Software Bill of Materials, inventario dei componenti software usati) a MBOM (Model Bill of Materials, inventario di modelli e relativi artefatti) o MLBOM (Machine Learning Bill of Materials, inventario esteso che include modelli, dati, pipeline e configurazioni) significa poter elencare e rendere disponibili per l'audit non solo i pacchetti software, ma anche modelli, versioni, pesi, dataset e configurazioni usate.
Secure prompt engineering
I prompt vanno trattati come "codice". Possono cambiare il comportamento del sistema e quindi devono essere controllati, revisionati e versionati. Secure prompt engineering significa impostare controlli di accesso ai prompt di sistema, registrare modifiche, evitare segreti nei prompt (che potrebbero filtrare a causa di errori nelle difese) e progettare template che riducano ambiguità e conflitti tra istruzioni.
Include anche test specifici contro prompt injection e jailbreak, perché un prompt non protetto può diventare un canale per aggirare regole o forzare con azioni indesiderate.
Monitoraggio continuo
Il monitoraggio continuo serve a vedere cosa succede davvero in produzione, perché molti rischi emergono solo con l'uso reale. Significa raccogliere telemetria su input, output, retrieval RAG, chiamate a strumenti e decisioni degli agenti, con log utili per investigare incidenti e fare miglioramenti. Su questi segnali si cercano anomalie, abuso, drift comportamentale e pattern sospetti, e si programma red teaming periodico per verificare che le difese restino efficaci nel tempo.
Governance e policy
La governance definisce chi decide, chi approva e chi risponde del rischio, evitando che l'IA venga gestita "per iniziative locali" senza controllo. Allinearsi a standard e normative come NIST AI RMF, EU AI Act e ISO/IEC 42001 aiuta a trasformare requisiti astratti in processi concreti, come valutazioni, documentazione, controlli, audit e responsabilità. La figura dell'AI Security Champion serve a portare queste pratiche dentro i team di sviluppo, mentre NIS2 spinge a rendere il top management realmente "accountable" sulla gestione del rischio.
Cultura organizzativa
La cultura organizzativa è ciò che rende le regole applicabili, perché nessuna policy funziona se le persone la aggirano o non la capiscono. In pratica significa formazione, processi semplici, canali per segnalare problemi e una responsabilità condivisa tra IT, sicurezza, legale, prodotto e business. Con una guida dall'alto, la sicurezza "by design" dovrà diventare parte del lavoro quotidiano.
Proposta operativa
Un'organizzazione può adottare un framework operativo ciclico. Le linee guida di ACN, NCSC UK e CISA propongono uno schema di quattro fasi. Qui è illustrato un processo in cinque fasi:1- Data pipeline
- Classificazione dei dati (sensibili, pubblici, proprietari).
- Controlli di accesso e logging.
- Validazione degli input per prevenire il data poisoning.
- Analisi dei rischi di data leakage e model inversion.
- Uso di dataset verificati e tracciati.
- Protezione crittografica dei pesi dei modelli.
- Autenticazione forte e autorizzazione; modello di accesso basato su ruoli o competenze certificate.
- Rate limiting e protezione delle interfacce applicative.
- Validazione automatica dei prompt e filtraggio degli output.
- Telemetria sugli output.
- Red teaming e penetration test specifici per IA (OWASP AI Security & Privacy Guide).
- Procedure dedicate a breach o misuse dell'LLM.
- Allineamento normativo (GDPR, EU AI Act, NIS2, NIST AI Risk Management Framework).
- Documentazione dei rischi e delle mitigazioni.
- Audit periodici indipendenti.
- Policy interne sull'uso sicuro degli strumenti AI.
- ProtectAI
- EU AI Act
- NIS2
- Standard ISO/IEC 42001
- MITRE ATLAS
- Adversarial ML Threat Matrix (Microsoft + MITRE)
- NIST AI Risk Management Framework
- OWASP AI Security & Privacy Guide
- GDPR
2- Training e fine-tuning
3- Deployment e utilizzo
4- Monitoraggio e incident response
5- Governance e compliance