AI Act e sistemi ad alto rischio: la vera scadenza è l’inventario, non il calendario

Luglio 18, 2026
Riccardo Petricca

Le scadenze dell'AI Act possono cambiare, ma per le imprese il lavoro utile comincia subito: mappare sistemi, casi d'uso, fornitori, dati e responsabilita.

AI Act e sistemi ad alto rischio: la vera scadenza e l'inventario, non il calendario

Per molte imprese l'AI Act rischia di diventare l'ennesimo tema affrontato partendo dalla domanda sbagliata: "da quando si applica?". La domanda e comprensibile, perche il calendario regolatorio conta. Ma quando si parla di sistemi di intelligenza artificiale potenzialmente ad alto rischio, il punto decisivo non e solo segnare una data in agenda. Il punto e capire, con sufficiente anticipo, quali strumenti AI siano gia entrati nei processi aziendali, quali siano ancora in sperimentazione, quali siano incorporati in software di terzi e chi abbia davvero il controllo su dati, decisioni, log, responsabilita e supervisione umana.

La Commissione europea ha aggiornato a luglio 2026 la propria pagina sulle linee guida per provider e deployer di sistemi AI ad alto rischio, ricordando che le linee guida servono a chiarire la classificazione dei sistemi e a fornire esempi pratici. La bozza, pubblicata il 19 maggio 2026, non e giuridicamente vincolante, ma riflette l'interpretazione della Commissione e orientera l'applicazione uniforme dell'articolo 6 dell'AI Act. Inoltre, dopo l'accordo politico sul cosiddetto AI Omnibus, la Commissione indica un nuovo calendario per alcune regole sui sistemi ad alto rischio: 2 dicembre 2027 per aree come biometria, infrastrutture critiche, istruzione, lavoro, migrazione, asilo e controllo delle frontiere; 2 agosto 2028 per sistemi integrati in prodotti come robotica e macchine industriali.

Queste date non devono indurre le aziende a rinviare tutto. Al contrario, danno una finestra utile per fare ordine. Chi aspetta la pubblicazione definitiva delle linee guida o degli standard armonizzati per cominciare rischia di scoprire troppo tardi che l'AI non e piu un progetto isolato, ma una funzione distribuita dentro ERP, CRM, strumenti HR, sistemi di manutenzione, piattaforme documentali, soluzioni di cybersecurity, automazioni commerciali e applicazioni verticali.

Perche la classificazione e un problema di governance

L'AI Act adotta un approccio basato sul rischio. Non tutte le applicazioni di intelligenza artificiale sono trattate allo stesso modo: alcune sono vietate, molte restano a rischio minimo o limitato, altre possono diventare ad alto rischio quando incidono su salute, sicurezza o diritti fondamentali. La Commissione richiama esempi come infrastrutture critiche, educazione, gestione del personale, accesso a servizi essenziali, identificazione biometrica, applicazioni in ambito giudiziario o processi collegati a migrazione e frontiere.

Per un'impresa, pero, la difficolta non e solo leggere un elenco normativo. La difficolta e collegare quell'elenco ai casi d'uso reali. Un sistema di scoring interno puo sembrare un semplice supporto decisionale, ma cambia natura se influenza l'accesso a un servizio, una selezione del personale, una valutazione di performance o un processo con impatti economici rilevanti sulle persone. Allo stesso modo, un modulo AI acquistato da un fornitore puo essere percepito come "funzione standard del software", mentre sul piano operativo produce suggerimenti, classificazioni o priorita che qualcuno in azienda usa per decidere.

Ecco perche la prima attivita non e compilare una checklist astratta, ma costruire un inventario. Senza inventario non esiste classificazione. Senza classificazione non esiste piano di conformita. Senza piano di conformita, il rischio diventa contrattuale, organizzativo e reputazionale prima ancora che sanzionatorio.

Cosa mappare davvero

Un inventario AI utile non puo limitarsi al nome del software. Deve descrivere almeno cinque elementi.

Il primo e il caso d'uso. Bisogna indicare quale processo e supportato, quali decisioni vengono influenzate, quali utenti interni o esterni sono coinvolti e se l'output dell'AI e consultivo, automatico o semi-automatico.

Il secondo e il ruolo dell'impresa. L'azienda sta sviluppando un sistema, lo sta integrando in un prodotto, lo sta distribuendo o lo sta semplicemente usando come deployer? La risposta cambia gli obblighi, i documenti da chiedere e le responsabilita da assegnare internamente.

Il terzo e la base dati. Un modello che lavora su dati aziendali, dati personali, dati di produzione, dati HR o dati di clienti non puo essere governato allo stesso modo di un assistente generico per bozze testuali. Vanno chiariti provenienza, qualita, aggiornamento, autorizzazioni, retention e tracciabilita.

Il quarto e il fornitore. Molte imprese non comprano "AI" in modo esplicito: comprano un gestionale, una suite documentale, un modulo predittivo, un sistema di ticketing, una piattaforma di marketing automation o un servizio cloud che include funzioni AI. Nei contratti devono comparire informazioni su documentazione tecnica, auditabilita, cybersecurity, log, subfornitori, aggiornamenti del modello, gestione degli incidenti e possibilita di disattivare o limitare la funzione.

Il quinto e la supervisione umana. Se l'output dell'AI entra in un processo decisionale, bisogna sapere chi lo controlla, con quali competenze, con quali poteri di override e con quale evidenza documentale. "C'e una persona nel processo" non basta se quella persona si limita a confermare automaticamente cio che propone il sistema.

Standard e documentazione: il lavoro da anticipare

La Commissione ricorda che gli standard armonizzati serviranno a tradurre requisiti legali in linguaggio tecnico comune. Le aree indicate includono risk management, governance e qualita dei dataset, registrazioni, trasparenza, supervisione umana, accuratezza, robustezza, cybersecurity, quality management e valutazione di conformita. L'adozione degli standard resta volontaria, ma quando uno standard armonizzato viene pubblicato e citato nella Gazzetta ufficiale dell'Unione europea puo offrire una presunzione di conformita.

Questo passaggio e importante per le imprese perche segnala dove si spostera il lavoro operativo. Non bastera dire che il sistema "funziona". Serviranno evidenze: descrizione dell'uso previsto, analisi dei rischi, controlli sui dati, registri di funzionamento, procedure di monitoraggio, gestione degli aggiornamenti, istruzioni agli utenti, misure di cybersecurity e criteri di escalation.

Chi ha gia sistemi di gestione maturi, ad esempio in ambito qualita, sicurezza informatica, privacy o continuita operativa, parte avvantaggiato. Non perche l'AI Act coincida con ISO 9001, ISO/IEC 27001, GDPR o NIS2, ma perche molte imprese possono riusare logiche gia note: ownership, risk assessment, documentazione, controllo dei fornitori, audit trail, formazione e miglioramento continuo.

Il rischio nascosto: l'AI acquistata senza saperlo

Nelle PMI il problema piu frequente non sara il laboratorio interno di machine learning, ma l'AI embedded nei software gia in uso. Un ERP puo introdurre previsioni di domanda, classificazione automatica dei documenti o suggerimenti di approvvigionamento. Un CRM puo assegnare score ai lead. Una piattaforma HR puo filtrare candidature o suggerire percorsi di crescita. Un sistema di cybersecurity puo prioritizzare alert e incidenti. Un software di manutenzione puo predire guasti e indicare priorita operative.

Molte di queste funzioni saranno lecite e utili. Il punto e non usarle in modo cieco. Ogni volta che una funzione AI influenza una decisione significativa, l'impresa dovrebbe chiedersi: il sistema rientra in una delle aree sensibili? Produce effetti su persone, sicurezza o diritti? Il fornitore documenta limiti e prestazioni? Gli utenti sanno quando stanno interagendo con AI? Esiste un modo per contestare, correggere o verificare l'output?

Queste domande non rallentano l'innovazione. La rendono difendibile.

Una checklist pratica per partire

Per trasformare il tema in un'azione concreta, l'impresa puo avviare un censimento in quattro settimane.

Prima settimana: raccogliere da IT, HR, operations, vendite, compliance e amministrazione l'elenco dei software che dichiarano funzioni AI, predittive, generative, automatiche o di scoring.
Seconda settimana: descrivere per ogni strumento il processo interessato, gli utenti, il tipo di dati trattati e l'impatto dell'output sulle decisioni.
Terza settimana: chiedere ai fornitori documentazione su modello, dati, sicurezza, log, aggiornamenti, subfornitori, responsabilita e funzioni di controllo.
Quarta settimana: assegnare una classe preliminare di rischio, separando strumenti a rischio minimo, funzioni con obblighi di trasparenza e casi da analizzare come potenzialmente ad alto rischio.

Il risultato non deve essere perfetto al primo giro. Deve essere governabile. Un inventario imperfetto ma aggiornabile e molto meglio di una valutazione rimandata per mesi in attesa di certezze assolute.

La conclusione per manager e responsabili IT

L'AI Act non va letto solo come una norma per sviluppatori di tecnologia. Per molte aziende sara una prova di governo dei processi digitali. Le scadenze, gli standard e le linee guida aiuteranno a definire meglio gli obblighi, ma non sostituiranno il lavoro interno di mappatura, responsabilizzazione e controllo.

La domanda utile da portare nel prossimo comitato direzionale non e "siamo gia obbligati?". E questa: "sappiamo dove l'AI sta influenzando i nostri processi, i nostri dati, le nostre persone e le nostre decisioni?".

Se la risposta e no, il primo progetto AI del 2026 dovrebbe essere proprio questo: costruire l'inventario, assegnare responsabilita e rendere verificabile cio che oggi spesso resta nascosto dentro i software.

Fonti

Condividi Articolo