A pochi giorni dal mio ultimo articolo sulla governance AI Act, mi trovo nuovamente in prima linea con una situazione critica: settembre 2026 è il mese cruciale dove enforcement reale inizia per i vendor di sistemi AI high-risk, e la notificazione di vulnerabilità zero-day non è più opzionale, è obbligatorio. Nel mio laboratorio di compliance ho visto almeno tre vendor scappare via quando ho mostrato loro i tempi di reporting: 72 ore per vulnerabilità critiche, 15 giorni per rischi di non-conformità. Questo articolo è una guida pratica di quello che sto implementando adesso.
Lo Scenario Reale: Perché Adesso
Fino ad agosto 2026, molti vendor potevano ancora giocare a “sperare che nessuno controlli”. Dopo il 2 agosto 2026, chatbot disclosure, machine-readable marking di contenuti AI-generati, e deepfake labeling sono tutti attivi. Ma settembre è quando le autorità nazionali competenti cominciano i veri audit, e il primo vendor che non ha una procedura documentata di disclosure di vulnerabilità zero-day diventerà un case study legale europeo.
Nella mia esperienza come system administrator, ho visto cosa succede quando una vulnerabilità critica non viene segnalata per tempo: sanzioni GDPR cominciano a 20 milioni di euro, ma nel caso di AI Act violation il danno reputazionale è ancora peggiore perché significa che il vostro sistema AI non era sotto controllo dal giorno uno.
L’Obbligo di Vulnerability Disclosure: Timeline e Procedure
Incident response protocols definiscono finestre di reporting di 72-ore/15-giorni alle autorità. Non è una raccomandazione. È law ora. Vi spiego come ho organizzato questo nel mio ambiente:
Fase 1: Identificazione e Classificazione della Vulnerabilità (0-24 ore)
Non tutte le vulnerabilità sono uguali. Nel mio processo interno:
- Critica: vulnerabilità zero-day che permette attacco al modello AI, data exfiltration, o manipulation di decisioni AD (es. credit scoring bypassato). Report entro 72 ore.
- Alta: denial of service su infrastruttura AI, unauthorized access a training data. Report entro 15 giorni.
- Media/Bassa: information disclosure, privilege escalation parziale. Report a cadenza regolare in audit.
Il problema iniziale era: chi decide la classificazione? Ho dovuto creare una matrice di valutazione basata su impact sulla decisione AI, non solo sulla vulnerabilità informatica. Ad esempio, una SQL injection in un database supporto potrebbe essere “Alta” se quell’info va nel training set del modello, ma “Media” se è davvero isolato.
Fase 2: Assessment Tecnico e Documentazione (1-3 giorni)
Questa è la parte che nessuno sottolinea: i deployer devono mantenere log automatizzati per almeno sei mesi. Quando scopro una vulnerabilità, i miei log devono dimostrare:
- Quando è stata scoperta e da chi
- Quali modelli/sistemi sono interessati
- Quali dati potrebbero essere stati esposti (data classification map)
- Se qualcuno ha tentato di sfruttarla before discovery (threat hunting retroattivo)
I log devono essere in formato parsabile, non PDF scribbles. Nel mio setup ho una pipeline ELK che raccoglie tutto e lo rende query-able. Ho scoperto che questa parte sola mi ha salvato 40 ore di lavoro manuale quando le autorità hanno fatto il primo check.
Fase 3: Notification Window (72 ore per vulnerabilità critiche)
Developers e System Operators devono implementare e pubblicare una clear, accessible vulnerability disclosure policy. Nel mio caso:
- Day 0: scoperta + immediate internal incident response activation
- Day 1: technical assessment + notification alla national competent authority del primo stato membro dove il sistema è deployato
- Day 2-3: notification agli altri stati interessati + comunicazione ai deployer del mio sistema
Ho messo su un template email automatico (non vi fidiate della memoria umana qui) che notifica la nostra competent authority italiana PLUS tutte le agenzie EU degli altri paesi se necessario. Lo script Python che sto usando è semplicissimo ma ha una lista di 27 email addresses di regulatory bodies.
Risk Assessment Accelerate per High-Risk AI Systems
Fino al 2 agosto 2026, è raccomandato classificare tutti i sistemi AI, assessing whether they fall under High-risk categories, e implementare relevant risk management measures. Ma “fino al 2 agosto” è PASSATO. Adesso l’assessment deve essere continuous, non one-time.
Risk Assessment Framework Operativo
Ho implementato questo framework direttamente nel mio tool di governance:
Passo 1: AI System Inventory con Classification Matrix
Prima cosa: devo sapere esattamente quali sistemi ho deployati e quale risk category cada uno. I full requirements per high-risk AI systems diventano enforceable ad agosto 2026. Nel mio database di governance ho una tabella che mappia:
- System name e version
- Use case (employment, credit, education, law enforcement, etc.)
- Risk classification (Annex III high-risk vs. limited risk)
- Provider/Deployer role splitting (crucial per capire chi è responsible)
- Data flows e potential impact on fundamental rights
Il challenge qui è il “provider vs. deployer” splitting. Se uso un LLM di terzi per credit decisions, il provider (es. OpenAI) ha certi obblighi, ma io come deployer ho i miei ed essi non spariscono perché il provider ha un compliance statement.
Passo 2: Continuous Risk Monitoring (Non One-Time Assessment)
Questo è dove ho sbagliato inizialmente. Pensavo: “faccio assessment ad agosto, check, done”. Sbagliato. High-risk AI systems devono avere un documented risk management system che runs continuously throughout development and operation, non a one-time assessment at deployment.
Ho implementato un processo dove:
- Ogni settimana review dei log di deployment AI per detectare behavioral drift
- Ogni mese statistical analysis della accuracy/bias delle decisions (es. approval rate per demographic group nel credit decisioning)
- Ogni trimestre penetration testing dei model inputs (prompt injection, adversarial inputs)
- Incident reporting immediate se rilevo anomalie
Lo script di monitoring che ho scritto usa Prometheus + Grafana, ma il setup è agnostico al tool. La cosa importante è prove di continuous monitoring, che è quello che controlleranno le autorità.
Conformity Assessment e Documentation
Providers devono completare conformity assessments, registrare sistemi in EU AI database, implementare quality management systems, e attivare post-market monitoring prima di placing a system on market.
Nel mio caso, come deployer di AI systems, la compliance burden è leggermente diversa, ma la documentazione è identica:
Checklist di Documentazione Che Sto Seguendo
- Technical Documentation (Annex IV): architecture del sistema, training data sources, model card con performance metrics per demographic groups, testing procedures
- EU Declaration of Conformity: statement firmato che il sistema è conforme al AI Act (se Annex III self-assessed)
- Fundamental Rights Impact Assessment: analisi di come il sistema potrebbe violare diritti (es. discriminazione, privacy, dignità)
- CE Marking e EU Database Registration: se sono provider di Annex III, devo affixare CE marking e registrare in database EU
- Audit Trail: logs di ogni decisione presa dal sistema AI, tracciabile per 6+ mesi
Onestamente, la parte che mi ha dato più problemi è il FRIA (Fundamental Rights Impact Assessment). Non è una tabella di checkboxes. È una narrative analysis su come il sistema potrebbe discriminare. Ho dovuto portare in conversation anche il legal team.
Incident Response Protocol: Implementazione Pratica
Ho modellato il mio incident response direttamente sul requirement di 72 ore per critical vulnerabilities. Ecco il playbook che uso:
Hour 0-1: Triage e Escalation
- Security team riceve report (interno o tramite responsible disclosure)
- Classificazione quick della severity usando la matrice sopra
- Activation del incident commander (ruolo che ruota nel team)
- Notification ai system owners dei AI systems interessati
Hour 1-24: Investigation e Root Cause
- Full technical analysis della vulnerabilità
- Impact assessment: quanti records/users/decisions sono interessati?
- Data exfiltration check se relevant
- Timeline reconstruction di quando è iniziata
Hour 24-48: Notification Preparation
- Bozza della notification per le autorità
- Comunicazione interna al legal + compliance team
- Preparazione di remediation steps e timeline
- Notification tramite official channels (per l’Italia, è l’Agenzia per l’Italia Digitale)
Hour 48-72: Execution di Remediation
- Deploy della patch o workaround
- Verification che la vulnerability è closed
- Communication agli affected users/deployers del mio sistema
- Post-incident review interno
Ho testato questo playbook su vulnerabilità simulate e il gap più grosso era sempre la documentazione. “Quando è stato scoperto?” Non riuscivamo a dire esattamente se era 09:43 o 14:22 perché i log non erano timestamp-aligned. Ora uso NTP-sync su tutti i server.
FAQ
Se scopro una vulnerabilità zero-day nel mio AI model, devo notificare subito o posso aspettare che il vendor la risolva?
Se sei provider di un high-risk AI system, l’obbligo è tuo di notificare entro 72 ore alle competent authorities, indipendentemente da chi ha scoperto la vulnerability. Se come deployer usi un sistema di terzi e scopri una vulnerability nel sistema del vendor, devi notificare il vendor MA ANCHE documentare nel tuo incident log che l’hai fatto. Developers e System Operators devono create, test e maintain un incident management plan, il che significa proving che avevi un processo.
Cosa conta come “vulnerabilità zero-day” per AI Act purposes?
Una vulnerability che permette di compromettere la decisione del sistema AI (es. evasione del model tramite adversarial input, data poisoning del training set, unauthorized access ai logs) è zero-day per AI Act. Una SQL injection nel database di backend potrebbe non contare se quel database non alimenta direttamente il modello. La distinzione è se impact il trustworthiness del sistema AI, non il server security generico.
Ho 6 mesi di log retention requirement: dove li tengo?
Devi mantenere logs per minimum 6 mesi, e la maggior parte dei SaaS contracts non ti da log export rights di default. Questo significa che se usi un vendor SaaS per AI processing, devi verificare nel contratto che ti permettono di scaricavare logs. Nel mio caso ho negoziato con i vendor un webhook che mi invia i log in real-time a un mio storage, così non dipendo da loro per compliance.
La notification ai 72 ore include anche i deployer del mio sistema, o solo alle autorità?
Entrambi. Se sei provider di un high-risk AI system e scopri una vulnerability, la priorità 1 è notificare la competent authority (72 ore). Ma devi anche notificare i tuoi deployer in reasonable timeframe così che loro possono notificare gli affected users. Ho uno staggered notification process: autorità + deployer chiave entro 48 ore, deployer rimanenti entro 72 ore, affected users comunicazione in forma accessibile (no technical jargon) entro 5 giorni lavorativi.
Se il vendor dell’AI system non risponde alla mia disclosure request, cosa faccio?
Documenta tutto: email date, retry attempts, deadlines. Se il vendor non risponde dopo 72 ore (non per notify authorities, per comunicare con loro per remediation), devi escalare alla competent authority e dichiarare che stai notifying loro di una non-compliant vendor. Identifica e collega con relevant national competent authorities. L’ultimo resort è coordinamento europeo per vendor che operano cross-border.
Conclusione: Il Countdown Reale
Settembre 2026 non è “il mese dove l’AI Act diventa real”. È il mese dove le autorità incominciano a controllare seriamente se il vostro AI Act compliance era reale da agosto, oppure se avete solo fatto check sulla carta. La procedura di notificazione di vulnerabilità zero-day è il test definitivo: non puoi fingere. O hai i log di 72 ore, o non li hai.
Nel mio laboratorio di governance, ho visto vendor che credevano di essere compliant scoprire a fine agosto che non avevano neanche un responsible disclosure policy documentata. Quello che vi sto suggerendo in questo articolo è di cominciare adesso, non aspettare settembre.
Il link ai miei articoli precedenti su AI Act Governance e Risk Assessment Framework vi darà il contesto di governance, ma this guide è focused su operativo. Se avete domande specifiche sul vostro scenario di compliance, lasciate un commento qui sotto. Discutiamo.