{"id":2410,"date":"2026-06-19T15:08:57","date_gmt":"2026-06-19T13:08:57","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/eu-ai-act-readiness-agosto-2026-classification-matrix-prohibited-categories\/"},"modified":"2026-06-19T15:08:57","modified_gmt":"2026-06-19T13:08:57","slug":"eu-ai-act-readiness-agosto-2026-classification-matrix-prohibited-categories","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/eu-ai-act-readiness-agosto-2026-classification-matrix-prohibited-categories\/","title":{"rendered":"EU AI Act Readiness Agosto 2026: La Mia Procedura Classification Matrix, Prohibited AI Categories Detection e Conformit\u00e0 per PMI Tech"},"content":{"rendered":"

Agosto 2026 rappresenta il momento cruciale per la conformit\u00e0 all’EU AI Act<\/em>. Il 2 agosto 2026, la maggior parte delle restanti regole dell’Atto entrano in vigore.<\/cite> Da mesi raccoglievo le specifiche tecniche della regolamentazione europea sull’IA, e ho deciso di condividere con voi il mio framework operativo costruito in questi mesi di ricerca. Non si tratta di una semplice guida teorica: \u00e8 la procedura che sto implementando concretamente nelle infrastrutture tech delle PMI che mi affidano i loro sistemi AI.<\/p>\n

La sfida principale per le piccole e medie imprese non \u00e8 capire cosa<\/strong> dice la legge, ma piuttosto come mappare i propri sistemi AI<\/strong> all’interno della matrice di rischio e come documentare la conformit\u00e0 senza paralizzare l’innovazione. In questa guida vi condivido gli strumenti concreti che utilizzo quotidianamente: la matrice di classificazione, le checklist per identificare le categorie vietate, il template di valutazione dell’impatto e i modelli verticali specifici per il settore tech.<\/p>\n

La Matrice di Classificazione: Il Cuore della Conformit\u00e0 AI Act<\/h2>\n

Il primo passo nella mia procedura \u00e8 sempre la classificazione sistematica. L’EU AI Act definisce quattro categorie: rischio inaccettabile (proibito), alto rischio (obblighi di conformit\u00e0 rigorosi prima dell’immissione sul mercato), rischio limitato (divulgazione di trasparenza agli utenti) e rischio minimo (nessun obbligo obbligatorio).<\/cite><\/p>\n

Ho strutturato una matrice di decisione che utilizzo per ogni sistema:<\/p>\n

    \n
  1. Rischio Inaccettabile (Proibito)<\/strong>: Il sistema deve essere immediatamente disattivato. Questi includono: sistemi di scoring sociale gestiti dal governo basati sul comportamento; IA che sfrutta vulnerabilit\u00e0 di gruppi specifici (bambini, persone con disabilit\u00e0) per distorcere il comportamento in modo da causare danni; identificazione biometrica remota in tempo reale in spazi pubblici per l’applicazione della legge (con eccezioni ristrette per terrorismo, persone scomparse e crimini gravi); sistemi di riconoscimento delle emozioni nei luoghi di lavoro e nelle istituzioni educative; e scraping senza target di immagini facciali da internet o CCTV per costruire database di riconoscimento facciale.<\/cite><\/li>\n
  2. Rischio Alto (Annex III)<\/strong>: Richiede conformit\u00e0 completa entro agosto 2026 con documentazione tecnica, valutazione della conformit\u00e0 e registrazione nel database EU.<\/li>\n
  3. Rischio Limitato<\/strong>: Obblighi di trasparenza (disclosure all’utente che sta interagendo con un’IA).<\/li>\n
  4. Rischio Minimo<\/strong>: Nessun obbligo obbligatorio, ma best practice consigliate.<\/li>\n<\/ol>\n

    Nella mia pratica quotidiana, ho scoperto che la maggior parte dei sistemi PMI tech rientra nelle categorie alto rischio o limitato rischio. I sistemi a rischio minimo sono rari\u2014persino uno spam filter potrebbe richiedere una valutazione se integrato in un contesto critico.<\/p>\n

    Individuazione delle Categorie Proibite: Procedure Pratiche<\/h2>\n

    Il mio workflow per identificare sistemi proibiti segue questi step:<\/p>\n

      \n
    1. Audit del Codice e della Configurazione<\/strong>: Esamino se il sistema utilizza modelli biometrici, riconoscimento emotivo o classificazione biometrica per attributi sensibili (razza, opinioni politiche, affiliazione sindacale, credo religioso, vita sessuale, orientamento sessuale).<\/li>\n
    2. Valutazione dell’Intento d’Uso<\/strong>: Anche se il sistema potrebbe tecnicamente<\/em> fare qualcosa di proibito, importa l’intento dichiarato. Se documentato correttamente per un use case legittimo (es. sicurezza medica), la classificazione cambia.<\/li>\n
    3. Documentazione del Criteri Esclusione<\/strong>: Se il sistema rientra in Annex III (es. biometria per l’accesso ai voli), devo dimostrare per iscritto che NON pone rischio significativo. Senza questa documentazione, \u00e8 automaticamente high-risk.<\/li>\n<\/ol>\n

      Nel mio ambiente di lavoro, ho incontrato il caso di una PMI che utilizzava emotion recognition per l’engagement analysis su social media. L’emotion recognition nei luoghi di lavoro e nelle istituzioni educative \u00e8 proibita.<\/cite> Anche se non era usata direttamente in azienda, il sistema era stato addestrato con dataset che includevano contesti lavorativi. Abbiamo dovuto disattivare immediatamente il feature e documentare l’azione.<\/p>\n

      Il Template di Impact Assessment (DPIA AI-Extended)<\/h2>\n

      Per i sistemi high-risk, ho sviluppato un template esteso di Data Protection Impact Assessment specifico per l’AI Act. La struttura che utilizzo comprende:<\/p>\n

        \n
      1. Identificazione del Sistema<\/strong>:\n