Guadagni:
- Capacità di classificare tipi di incidenti specifici dell'intelligenza artificiale e progettare un ciclo di risposta
- Capacità di definire ruoli, autorità e obblighi di reporting legale prima dell'evento
- Capacità di stabilire un miglioramento permanente con continuità aziendale e post mortem senza colpe
Non importa quanto bene lo difendi, un giorno qualcosa andrà storto: una chiave perderà, un'iniezione funzionerà, un fornitore fallirà o un output danneggerà un cliente. Ciò che rende matura un'istituzione matura non è l'assenza di eventi, ma l'essere preparati e veloci quando un evento si verifica. In questa unità impareremo un piano di risposta agli incidenti specifico per l'intelligenza artificiale, i ruoli, i passaggi e la continuità aziendale.
Perché la risposta agli incidenti è diversa nell’intelligenza artificiale?
In un classico incidente di sicurezza, spesso è sufficiente “spegnere il sistema e isolarlo”. Esistono dimensioni aggiuntive per gli eventi dell'IA: l'evento potrebbe non trovarsi in un codice ma nel comportamento del modello (ad esempio output sistematico errato/distorto); la prova è nei registri di richiesta/risposta; e "annullare" a volte non è possibile perché l'output errato è già diventato una decisione. Pertanto, il piano di incidente dell’IA dovrebbe coprire sia la sicurezza classica che il comportamento del modello.
Attenzione: al momento dell'incidente il piano non viene scritto, viene attuato. Chi chiamerà chi, chi avrà l'autorità di "fermare il sistema" e come verrà effettuata la comunicazione dovrà essere deciso prima dell'evento.
Tipi di eventi IA
- Perdita di dati: informazioni personali o dati riservati trapelati (tramite prompt, registro o output).
- Violazione della sicurezza: chiave trapelata, iniezione riuscita, accesso non autorizzato.
- Risultati dannosi/distorti: il modello ha prodotto sistematicamente una risposta errata, discriminatoria o pericolosa.
- Interruzione del servizio: il provider si è bloccato o ha raggiunto il limite di velocità; Il sistema non può rispondere.
- Abuso: il sistema è stato utilizzato per uno scopo dannoso per il quale non era stato progettato.
Passo dopo passo: ciclo di risposta agli incidenti
- Rilevamento. Un allarme di monitoraggio, un reclamo dell'utente o un risultato di audit rivelano l'incidente.
- Ordina e stabilisci la priorità. Fornire livelli basati sull'impatto e sulla diffusione (ad esempio P1 critico – P3 basso).
- Contenere. Ferma la diffusione: revoca la chiave, disattiva la funzione, imposta il sistema in sola lettura.
- Sradicare e recuperare. Risolvi la causa principale e torna allo stato sicuro.
- Segnalalo. Informare tempestivamente gli obblighi di notifica legali/contrattuali (come KVKK 72 ore) e le persone interessate.
- Esame post-evento (autopsia). Senza dare la colpa, documenta la causa principale e la soluzione permanente.
Ruoli e responsabilità
Dovrebbe essere chiaro chi fa cosa in un incidente: comandante dell’incidente (l’unica persona che prende la decisione), risposta tecnica (arresto/riparazione del sistema), comunicazioni (cliente/gestione/autorità di regolamentazione), legale/conformità (obbligo di segnalazione). Nei piccoli team, una persona può assumere più ruoli, ma i ruoli devono essere scritti.
Quattro modelli copiabili
Richiesta di classificazione degli eventi:
Classificare il seguente evento: {{ event_description }} Identificare:- Tipo: perdita di dati/violazione della sicurezza/output dannoso/interruzione/abuso- Impatto: quante persone/record, quale classe di dati, conseguenze finanziarie/di conformità?- Propagazione: interrotta o in corso?- Priorità: P1 / P2 / P3 + giustificazione- Primo passaggio di controllo: cosa dovrebbe essere fatto immediatamente?
Lista di controllo di prima risposta (contenimento):
Nei primi 30 minuti in cui l'incidente viene confermato:- [ ] Disattiva la funzionalità/lo strumento interessato o impostalo in sola lettura- [ ] Annulla chiavi/sessioni sospette- [ ] Conserva le prove (congela i registri pertinenti, registra trace_id)- [ ] Avvisa il comandante dell'incidente e i ruoli richiesti- [ ] Distribuisci una modalità provvisoria/flusso di backup temporaneo
Richiesta di bozza di notifica:
Scrivi una bozza di notifica interna per il seguente incidente: {{ incident_summary }} Deve includere: cosa è successo (in linguaggio non tecnico), quando è stato notato, quali dati/chi è stato interessato, cosa è stato fatto finora, i passaggi successivi, da chi è possibile ottenere ulteriori informazioni. Non includere speculazioni o accuse.
Scheletro post-mortem:
Revisione post-evento (nessuna colpa):- Cronologia: rilevamento -> controllo -> ripristino (minuziosamente)- Causa principale: tecnica + dimensione del processo- Cosa è andato bene/cosa è andato male- Correzioni permanenti (chi, quando)- Monitoraggio/controllo per individuare questo evento il prima possibile
Prompt debole / Prompt forte
approccio scadente
Approccio forte
Improvviso all'evento senza un piano
Piano, ruoli e autorità pre-scritti
Prima di' "chi è il colpevole"
Prima il contenimento, poi l'autopsia senza colpa
Notifica ritardo/salto
Notifica entro il termine legale (es. 72 ore)
In attesa che lo stesso evento si ripeta
Estrarre il controllo permanente dall'autopsia
Tre mini custodie
Caso 1 – Intrappolato nella regola delle 72 ore. Un dipendente di un'azienda ha notato che 1.200 record di clienti erano rimasti esposti in un registro a causa di un'errata configurazione. Grazie al piano scritto, il comandante dell'incidente era chiaro; Il team ha chiuso l'accesso in 40 minuti e la legge ha notificato la KVKK entro 72 ore. La segnalazione tempestiva ha ridotto significativamente il rischio penale e il danno reputazionale.
Caso 2: la modalità provvisoria di sola lettura ha gestito l'interruzione. Il principale fornitore di modelli è uscito per 3 ore. Il piano di continuità aziendale dell'azienda prevedeva il passaggio a un fornitore di backup e la "modalità provvisoria" (solo funzioni critiche). Sebbene gli utenti perdessero la piena funzionalità, il sistema è sopravvissuto; le operazioni critiche non si sono fermate.
Caso 3: l'autopsia ha impedito il ripetersi. Un'iniezione indiretta riuscita ha fatto trapelare i dati di un altro utente a un assistente. L'autopsia senza accusa ha dimostrato che la causa principale era la mancanza di isolamento dei <dati>. Aggiunta correzione permanente (isolamento + scansione dell'output + test di regressione); La stessa classe di attacco non ha avuto successo ancora una volta.
Suggerimento: conduci l'autopsia senza alcuna colpa. L’obiettivo non è trovare persone, ma rafforzare il sistema in modo che non si ripeta lo stesso incidente. Una cultura della colpa porta le persone a nascondere le cose, e questa è la cosa più pericolosa.
Errori comuni
- Non preparare un piano scritto e la distribuzione dei ruoli prima dell'evento.
- Entrare in una discussione/incolparsi prima di prendere il controllo.
- Mancati obblighi di notifica legale (scadenze KVKK/GDPR).
- Reimpostare il sistema senza conservare le prove (log).
- Non considerare un provider di backup/modalità sicura per la continuità aziendale.
- Non fare un'autopsia e lasciare spazio affinché lo stesso evento si ripeta.
In sintesi
- La maturità non è assenza di eventi; Vuol dire essere preparati e veloci quando succede.
- Gli eventi dell'intelligenza artificiale possono trovarsi nel comportamento del modello piuttosto che nel codice; la prova è nei registri di richiesta/risposta e l'inversione non è sempre possibile.
- Ciclo di risposta: rilevare, classificare, contenere, recuperare, riportare, post-mortem.
- I ruoli e le autorità (comandante dell'incidente, tecnico, comunicazioni, legale) dovrebbero essere scritti per iscritto prima dell'evento.
- Provider di backup/modalità sicura per la continuità aziendale; Un'autopsia senza colpa e una correzione permanente sono essenziali per le conseguenze dell'evento.
Compito dell'applicazione
Scrivi una bozza di piano di risposta agli incidenti per il tuo sistema di intelligenza artificiale: elenca i tre tipi di incidenti più probabili, identifica una lista di controllo di contenimento iniziale di 30 minuti e i ruoli per ciascuno. Quindi esegui un esercizio da tavolo: riproduci passo dopo passo lo scenario della "chiave trapelata" e sottolinea e correggi eventuali punti mancanti/ambigui nel tuo piano.
lista di controllo
- [] Esiste un piano scritto di risposta agli incidenti e una distribuzione dei ruoli.
- [ ] È chiaro chi ha l'autorità di "fermare il sistema".
- [ ] La lista di controllo per il contenimento dei primi 30 minuti è pronta.
- [ ] Sono definiti i termini di notifica legale e la persona responsabile.
- [ ] Provider di backup/modalità sicura pianificata per la continuità aziendale.
- [] Per ogni incidente vengono eseguite un'autopsia senza colpa e una correzione permanente.