Vai al contenuto
Capitolo 07 · 11 min

Governance e assurance

Le difese tecniche mantengono sicuro il sistema. La governance lo dimostra, ai tuoi clienti, ai tuoi auditor e ai tuoi regolatori, e rende la sicurezza ripetibile man mano che il team e il sistema cambiano. Per un'azienda che vende a grandi imprese europee, questo strato è spesso ciò che chiude l'affare. Questo capitolo collega il tecnico all'organizzativo.

Le serrature tengono onesta la gente onesta. La governance è la documentazione che dimostra che le serrature le hai montate.

Modella di proposito le minacce del tuo sistema di IA

Prima dei framework, la pratica fondamentale: siediti e ragiona sul tuo sistema specifico. Quali sono gli asset (dati, capacità, reputazione)? Chi potrebbe attaccarlo e perché? Dove sono i confini di fiducia? Qual è la cosa peggiore che un modello compromesso potrebbe fare? I metodi classici di modellazione delle minacce come STRIDE si adattano facilmente all'IA: stai semplicemente aggiungendo all'elenco le modalità di guasto del modello.

Il risultato è un elenco prioritizzato di rischi legati alla tua architettura, che ti indica dove investire le difese del capitolo precedente. Una checklist generica ti dice cosa è possibile; un modello delle minacce ti dice cosa conta qui. Fai il modello delle minacce.

I framework da conoscere

Non devi memorizzare gli standard, ma dovresti conoscere la mappa, perché clienti e auditor vi faranno riferimento:

  • NIST AI Risk Management Framework: un framework statunitense volontario per identificare e gestire i rischi dell'IA lungo tutto il ciclo di vita di un sistema. Un punto di riferimento comune; in Europa fanno autorità l'AI Act e le linee guida del Garante per la protezione dei dati.
  • OWASP Top 10 per le applicazioni LLM: l'elenco del professionista delle vulnerabilità LLM più critiche; corrisponde direttamente ai capitoli da 2 a 5.
  • MITRE ATLAS: una base di conoscenza delle tattiche avversariali reali contro i sistemi di IA, modellata sul framework ATT&CK.
  • SOC 2: non specifico dell'IA, ma il report di fiducia che le grandi imprese europee richiedono; le tue funzionalità di IA rientrano nel suo perimetro.
  • Regole settoriali e regionali: GDPR e l'AI Act, regole per la sanità e per la finanza, e CCPA/CPRA e HIPAA se tocchi il mercato statunitense.

Assurance: dimostrarlo a qualcun altro

L'assurance è la prova che la tua sicurezza esiste e funziona. Per un acquirente aziendale, "fidatevi di noi" non è una risposta; ha bisogno di vederlo. Questo significa policy (regole scritte su come l'IA viene costruita e usata), controlli documentati (cosa fai e perché), piste di audit (i log e le tracce del capitolo 6, che fanno da prova) e uno storico di test (le tue scoperte di red team e le relative correzioni).

È qui che il posizionamento di SDEN incontra il lavoro tecnico: la conformità con SOC 2 e con il GDPR non è un sovraccarico burocratico imbullonato alla fine. È il risultato naturale di aver fatto bene il lavoro di ingegneria e di averlo documentato. Un sistema costruito con i controlli di questo corso produce le prove quasi come sottoprodotto. Un sistema che non lo ha fatto non può fingerle.

La governance come processo vivo

La governance fallisce quando è un documento scritto una volta e archiviato. I sistemi di IA cambiano ogni settimana (nuovi prompt, nuovi modelli, nuovi tool, nuovi dati), e ogni cambiamento può modificare il quadro dei rischi. La governance deve essere un processo che tiene il passo: una fase di revisione dei cambiamenti che chiede "questo influisce sui nostri rischi o controlli", una rivalutazione periodica, e una responsabilità chiara perché la sicurezza non sia il compito di tutti e quindi di nessuno.

  • Responsabilità: una persona o un team nominato responsabile della sicurezza dell'IA, non un vago "ci teniamo tutti".
  • Revisione dei cambiamenti: i cambiamenti di modello, prompt, tool e dati passano per una verifica leggera dei rischi, non solo per una valutazione della qualità.
  • Rivalutazione periodica: il modello delle minacce e i controlli vengono rivisti secondo un calendario, non solo dopo un incidente.
  • Risposta agli incidenti: un piano collaudato per quando qualcosa passa, incluso chi decide di ritirare la funzionalità.
  • Gestione dei fornitori: le decisioni di fiducia verso i fornitori e i tool del capitolo 5, tracciate e riviste.

Dove andare da qui

Ora hai l'arco completo: la nuova superficie di attacco, le minacce che vi risiedono, le difese a strati che funzionano, e la governance che le dimostra e le rende durature. Il filo conduttore è semplice: non puoi fidarti del modello, quindi lo vincoli, lo sorvegli e lo documenti. Abbina questo al corso Costruire con l'IA per l'ingegneria, e il lavoro di sicurezza di SDEN è esattamente questa disciplina applicata a sistemi reali sotto obblighi reali.

Una riga per ciascuno

  • Modella le minacce del tuo sistema specifico (STRIDE più le modalità di guasto degli LLM). Una checklist generica dice cosa è possibile; un modello delle minacce dice cosa conta qui.
  • Conosci la mappa dei framework, NIST AI RMF, OWASP LLM Top 10, MITRE ATLAS, SOC 2, come struttura condivisa, non come sostituto dei veri controlli.
  • L'assurance consiste nel dimostrarlo con policy, controlli documentati, piste di audit e uno storico di test: il sottoprodotto naturale di un'ingegneria ben fatta.
  • La governance deve essere un processo vivo: responsabilità chiara, revisione dei cambiamenti, rivalutazione periodica e un piano d'incidente collaudato.
Governance e assurance · Corsi di IA · SDEN