Perché un overlay, non una sostituzione. La tesi.

Parte del framework AI IR Overlay™. Vedi CONTENT_MAP.md per la mappa completa del repository.

---

The AI IR Overlay: Panoramica del Framework

Versione attuale: v0.35.0 · 2026-07-09 · CHANGELOG

Una baseline pratica di incident response per agenti AI in produzione. Critica e adatta liberamente.

Perché un overlay, non una sostituzione

L'incident response tradizionale (codificata nella NIST SP 800-61 r3, che ha sostituito la r2 nell'aprile 2025) è stata costruita attorno a vettori di accesso non autorizzato: malware, exploit, furto di credenziali, movimento laterale. Gli agenti AI cambiano la modalità di guasto.

Gli incidenti AI spesso si manifestano attraverso canali autorizzati:

• Identità legittime. Account di servizio o concessioni OAuth delegate che eseguono azioni non intenzionali.
• API legittime. Chiamate a strumenti per email, CRM ed ERP che operano entro parametri consentiti ma producono comunque danni.
• Fonti legittime. Livelli di retrieval che attingono a conoscenze fidate ma obsolete o inappropriate.
• Workflow legittimi. Automazioni che eseguono la policy così com'è scritta, producendo però esiti dannosi.

Quando l'attore è autorizzato, la domanda passa da "chi è entrato?" a "cosa poteva toccare, e cosa ha fatto?" Le prove cruciali ora risiedono in prompt, chiamate a strumenti, tracce di retrieval e stato di configurazione. Non sugli endpoint.

Cosa rimane invariato

I meccanismi fondamentali di un'incident response efficace restano invariati:

• Comando e controllo chiari
• Disciplina basata sulle prove
• Contenimento rapido con minima interruzione
• Scoping tramite terminologia confermato versus sospetto
• Ripristino tramite riabilitazione controllata e per fasi
• Log decisionali difendibili

L'AI non riscrive le regole di un'IR efficace. Cambia la mappa.

Ambito

L'AI IR Overlay rende operative le obbligazioni del deployer per i sistemi AI in produzione. Un deployer è l'organizzazione che utilizza un sistema AI nelle proprie operazioni, sotto la propria supervisione (ai sensi dell'Articolo 3 dell'EU AI Act). Questo framework è destinato al team di sicurezza che risponde agli incidenti negli agenti gestiti dall'organizzazione deployer.

Fuori ambito:

• Obbligazioni del provider per l'immissione di sistemi AI sul mercato (Articoli 16-21 dell'EU AI Act)
• Obbligazioni dei provider di modelli AI per finalità generali (GPAI) (Articolo 51 e successivi dell'EU AI Act)
• Pratiche AI proibite (Articolo 5 dell'EU AI Act)
• Valutazione della conformità e marcatura CE (Articolo 43 dell'EU AI Act)

I copilot dei vendor che un'organizzazione implementa rientrano nell'ambito del deployer (lato cliente). Le obbligazioni del provider del vendor non vengono affrontate qui.

Il modello Overlay

L'AI IR Overlay aggiunge quattro controlli agent-aware (il Minimum Viable Overlay, o MVO) sopra il tuo programma IR esistente.

Nota: Le fasi mostrate di seguito si allineano alla NIST SP 800-61 r3 (aprile 2025), suddivise in sette colonne operativamente distinte secondo la Sezione 1 di MATRIX.md. La NIST SP 800-61 r3 ristruttura l'incident response attorno alle funzioni NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover); vedi la crosswalk AI IR Overlay verso CSF 2.0 in crosswalks/nist-csf-2.md per la mappatura a livello di funzione.```text ┌───────────────────────────────────────────────────────────────────────┐ │ AI IR Overlay Response Flow (NIST SP 800-61 r3, unpacked) │ │ │ │ Preparation → Detection → Triage → Containment → Evidence → │ │ Recovery → Closure │ └───────────────────────────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────────────────┐ │ AI IR Overlay · MVO Controls (4) │ │ │ │ 1. INVENTORY · Agents · Identities · Tools · Write Targets │ │ 2. SAFE MODES · Kill-Switch Ladder (M0–M5; 6 M3 + 2 M4 variants) │ │ 3. EVIDENCE · Minimum AI Evidence Set (Types A–F) │ │ 4. CONTROLLED · Staged, validated re-enablement │ │ RE-ENABLE │ └───────────────────────────────────────────────────────────────────────┘

Per la matrice completa fase-per-controllo, vedi [`MATRIX.md`](https://github.com/jacobideji/aiiroverlay/blob/main/MATRIX.md), Sezione 1.

## Ordine di lettura

**Se stai rispondendo a un incidente AI in questo momento**, inizia da [`RESPONSE-START.md`](https://github.com/jacobideji/aiiroverlay/blob/main/RESPONSE-START.md) per il percorso di navigazione in quattro file che ti porta dalla pagina delle 3 di notte a un checkpoint difendibile di 60 minuti.

**Nuovo qui? Inizia con [QUICKSTART.md](https://github.com/jacobideji/aiiroverlay/blob/main/QUICKSTART.md)** per il percorso di adozione standard di 30 giorni. Per startup e piccoli team di sicurezza (5 o meno persone, controllo limitato della piattaforma), [QUICKSTART-startup.md](https://github.com/jacobideji/aiiroverlay/blob/main/QUICKSTART-startup.md) è il percorso minimo vitale di 4 settimane mirato al Livello di Maturità 2. Per un esempio end-to-end completo, vedi [`examples/incident-walkthrough.md`](https://github.com/jacobideji/aiiroverlay/blob/main/examples/incident-walkthrough.md). Per esempi di codice funzionanti dei contratti API del framework, vedi [`reference-impls/`](https://github.com/jacobideji/aiiroverlay/blob/main/reference-impls).

Per l'ordine di lettura concettuale completo, gli elementi da 1 a 8 sono il nucleo, gli elementi da 9 a 15 sono gli artefatti operativi.

Per un riferimento tabellare autonomo (vista a matrice del framework: fasi, scala di kill-switch, tipi di evidenza, metriche, controlli MVO, livelli di maturità, indice dei playbook, crosswalk degli standard), vedi [`MATRIX.md`](https://github.com/jacobideji/aiiroverlay/blob/main/MATRIX.md).