• Tutta l'Informazione Ninja nella tua mail

  • AI Act e aziende: come capire se la tua azienda usa sistemi AI ad alto rischio

    28 Luglio 2026

    Un software filtra i curriculum ricevuti dall’azienda e suggerisce quali candidati convocare. Un altro assegna un punteggio alle prestazioni dei dipendenti. La banca usa un algoritmo per valutare la solvibilità di chi chiede un prestito. Una compagnia assicurativa calcola il rischio di una persona prima di proporle una polizza sanitaria.

    Sono applicazioni diverse, accomunate da un elemento: possono incidere sulla vita delle persone.

    È qui che entra in gioco la categoria dei sistemi AI ad alto rischio prevista dall’AI Act. Per le aziende, riconoscerli richiede un’analisi più articolata della semplice lettura della scheda tecnica di un prodotto. La classificazione dipende soprattutto dalla finalità dello strumento, dalle decisioni che contribuisce a prendere e dalle persone sulle quali produce effetti.

    Il nome commerciale del software dice poco. Anche le etichette “assistente AI”, “copilot” o “piattaforma intelligente” possono coprire funzioni molto diverse. La stessa tecnologia può essere impiegata per correggere una frase, ordinare documenti oppure selezionare chi avrà accesso a un lavoro, a un finanziamento o a un servizio essenziale.

    La prima attività utile consiste quindi nel ricostruire dove e come viene utilizzata l’intelligenza artificiale dentro l’organizzazione. Le aziende che faticano a ricostruire strumenti, funzioni e responsabilità possono partire da una consulenza gratuita con Ninja, utile per impostare la mappatura e valutare quali competenze servono ai diversi team.

    La classificazione parte dall’uso concreto del sistema

    L’AI Act individua due grandi percorsi attraverso i quali un sistema può rientrare nella categoria ad alto rischio.

    Il primo riguarda l’intelligenza artificiale utilizzata come prodotto o componente di sicurezza di prodotti regolamentati dalla normativa europea, quando è prevista una valutazione di conformità da parte di terzi. È il caso, per esempio, di alcune applicazioni integrate in macchinari, dispositivi medici, ascensori, giocattoli, robot o altri prodotti soggetti alle discipline indicate nell’Allegato I.

    Il secondo percorso interessa i casi d’uso elencati nell’Allegato III. Qui rientrano sistemi impiegati in settori nei quali una decisione automatizzata può incidere sulla sicurezza, sulle opportunità professionali o sui diritti fondamentali di una persona.

    La distinzione è contenuta nell’articolo 6 dell’AI Act, consultabile attraverso il Service Desk ufficiale della Commissione europea.

    La domanda corretta, quindi, è: per quale scopo stiamo usando questo sistema?

    Un modello generativo impiegato dal marketing per preparare la prima bozza di una newsletter presenta un profilo differente rispetto a un sistema che classifica le candidature ricevute dall’ufficio risorse umane. Nel primo caso l’output viene utilizzato per produrre un contenuto. Nel secondo contribuisce a determinare quali persone avranno accesso a un’opportunità professionale.

    La tecnologia potrebbe persino essere simile. Cambiano la funzione, il contesto e le conseguenze.

    Le domande da fare prima di classificare un sistema

    La mappatura può partire da una scheda dedicata a ogni strumento utilizzato. Il censimento dovrebbe comprendere anche le funzioni AI integrate in piattaforme già presenti in azienda: software gestionali, CRM, applicazioni HR, strumenti di cybersecurity, servizi cloud e soluzioni acquistate da fornitori esterni.

    Per ogni sistema servono almeno sette risposte:

    1. Qual è la sua finalità prevista?
    2. In quale processo aziendale viene utilizzato?
    3. Produce un risultato, una raccomandazione, un punteggio o una decisione?
    4. Il suo output influenza una persona fisica?
    5. Opera in una delle aree indicate dall’Allegato III?
    6. Analizza caratteristiche, comportamenti o dati personali per creare un profilo?
    7. Chi controlla e può correggere il risultato?

    La finalità dichiarata dal fornitore rappresenta il punto di partenza. Conta anche l’uso effettivo fatto dall’azienda. Una funzione progettata per supportare un’attività amministrativa può assumere un peso diverso quando viene inserita direttamente in un processo decisionale.

    Conviene inoltre ricostruire quali dati entrano nel sistema, chi riceve l’output, quanto margine decisionale rimane alle persone e quali verifiche vengono svolte prima di applicare il risultato.

    L’espressione “human in the loop”, spesso presente nelle presentazioni commerciali, ha un valore limitato quando il controllo umano si riduce a confermare sistematicamente quanto proposto dall’algoritmo. L’articolo 14 dell’AI Act richiama infatti anche il rischio di automation bias, cioè la tendenza ad affidarsi eccessivamente all’output del sistema.

    Una prima ricognizione può essere svolta internamente coinvolgendo IT, legal, HR e procurement. Quando strumenti e responsabilità risultano frammentati, la consulenza gratuita proposta da Ninja può aiutare a definire il perimetro dell’analisi prima di progettare il percorso formativo.

    I sistemi HR sono tra i primi da controllare

    Le risorse umane rappresentano una delle aree più esposte. L’Allegato III dell’AI Act include espressamente i sistemi utilizzati per pubblicare annunci di lavoro mirati, analizzare e filtrare le candidature, valutare i candidati e supportare la selezione del personale.

    Rientrano nella stessa area i sistemi che contribuiscono a decisioni relative a promozioni, cessazioni del rapporto e condizioni di lavoro. Anche l’assegnazione dei compiti sulla base di caratteristiche individuali, il monitoraggio dei lavoratori e la valutazione delle prestazioni possono ricadere nella categoria ad alto rischio.

    Gli esempi aiutano a distinguere.

    Un assistente generativo che migliora la leggibilità di un annuncio preparato dal recruiter svolge, in linea generale, un’attività editoriale di supporto. Un software che decide a quali utenti mostrare l’offerta in base a caratteristiche personali entra invece nell’area del targeting delle opportunità lavorative.

    Lo stesso vale per i curriculum. Estrarre nome, recapiti e titoli di studio per compilare automaticamente un database può configurarsi come attività procedurale. Attribuire un punteggio ai candidati, ordinarli in classifica o escluderne alcuni sulla base di una valutazione automatizzata incide direttamente sul processo di selezione.

    Il livello di attenzione cresce quando il sistema analizza video-colloqui, tono della voce, espressioni facciali, lessico o presunti tratti della personalità. In questi casi possono entrare in gioco, oltre all’AI Act, anche la disciplina sulla protezione dei dati personali e le norme applicabili ai rapporti di lavoro.

    Le aziende dovrebbero verificare anche le funzioni introdotte dopo l’acquisto del prodotto. Le piattaforme SaaS cambiano rapidamente e un aggiornamento può aggiungere strumenti di ranking, scoring o analisi predittiva che non erano presenti durante la valutazione iniziale.

    Credito, assicurazioni e servizi essenziali

    Un altro gruppo rilevante riguarda l’accesso a servizi considerati essenziali.

    L’Allegato III comprende i sistemi utilizzati per valutare l’affidabilità creditizia delle persone fisiche o stabilire un credit score. L’eccezione riguarda gli strumenti impiegati per individuare frodi finanziarie.

    Sono inclusi anche i sistemi destinati alla valutazione del rischio e alla determinazione dei prezzi nelle assicurazioni vita e salute. Per gli enti pubblici, la lista copre inoltre le applicazioni utilizzate per decidere l’accesso a prestazioni e servizi essenziali, compresa l’assistenza sanitaria.

    L’elenco ufficiale comprende anche i sistemi che classificano le chiamate di emergenza, attribuiscono priorità agli interventi di soccorso o supportano il triage sanitario. Le singole fattispecie possono essere consultate nell’Allegato III pubblicato dal Service Desk europeo.

    La distinzione tra persone fisiche e imprese ha un peso concreto. Un sistema utilizzato esclusivamente per valutare il merito creditizio di una società non rientra automaticamente nella voce dedicata al credit scoring delle persone. La situazione cambia quando la valutazione coinvolge un imprenditore individuale, un garante o altri soggetti fisici.

    Anche qui serve guardare oltre il nome del prodotto. Un software definito “antifrode” potrebbe limitarsi a segnalare transazioni anomale oppure elaborare un punteggio generale di affidabilità del cliente. Le due funzioni richiedono valutazioni differenti.

    Biometria, formazione e infrastrutture critiche

    La lista europea comprende anche determinati sistemi biometrici, tra cui identificazione biometrica remota, categorizzazione basata su caratteristiche sensibili ed emotion recognition, nei limiti in cui tali usi siano consentiti dalla legge.

    Nel campo dell’istruzione e della formazione professionale rientrano gli strumenti che determinano l’accesso a un percorso, valutano i risultati di apprendimento o stabiliscono il livello formativo appropriato per una persona. Sono compresi anche alcuni sistemi usati per controllare comportamenti vietati durante gli esami.

    Per le infrastrutture critiche, la categoria comprende l’AI impiegata come componente di sicurezza nella gestione di infrastrutture digitali, traffico stradale e fornitura di acqua, gas, riscaldamento o elettricità. Questi casi sono descritti nello stesso Allegato III del Regolamento.

    Queste aree interessano meno aziende rispetto ai software HR, ma presentano conseguenze potenzialmente più gravi. Una classificazione errata può coinvolgere sicurezza fisica, accesso all’istruzione e dati sensibili.

    L’Allegato III prevede alcune eccezioni

    La presenza di un sistema in un’area elencata dall’Allegato III richiede una verifica, ma non determina in ogni circostanza la classificazione finale.

    L’articolo 6 prevede che alcuni strumenti possano essere esclusi dalla categoria ad alto rischio quando non producono un rischio significativo per salute, sicurezza o diritti fondamentali e non influenzano materialmente il risultato della decisione.

    L’eccezione può riguardare:

    • un’attività procedurale circoscritta;
    • il miglioramento del risultato di un’attività umana già completata;
    • l’individuazione di schemi decisionali senza sostituire la precedente valutazione umana;
    • un compito preparatorio rispetto alla valutazione principale.

    I criteri sono indicati nel testo dell’articolo 6, paragrafo 3.

    La differenza si gioca sui dettagli.

    Un sistema che trasforma i curriculum ricevuti in file strutturati potrebbe svolgere un compito preparatorio. Un sistema che segnala quali curriculum meritano attenzione orienta già la valutazione. Se assegna punteggi e crea una graduatoria, la sua influenza sul risultato diventa ancora più evidente.

    La deroga ha inoltre un limite preciso: quando il sistema effettua profilazione di persone fisiche, la classificazione ad alto rischio resta applicabile nei casi previsti dall’Allegato III.

    Il provider che ritiene applicabile un’esclusione deve documentare la propria valutazione prima dell’immissione sul mercato o della messa in servizio. Per l’azienda cliente, una dichiarazione generica del fornitore offre poche garanzie. Servono informazioni sulla finalità prevista, sulle funzioni attive, sui dati analizzati e sul peso dell’output nelle decisioni.

    Usare un software esterno rende l’azienda un deployer

    Gran parte delle imprese italiane acquista sistemi sviluppati da altri. In termini AI Act, assume quindi il ruolo di deployer, cioè il soggetto che utilizza un sistema AI sotto la propria autorità per finalità professionali.

    Il provider sviluppa il sistema o lo immette sul mercato con il proprio nome. Il deployer lo utilizza all’interno dei propri processi. Le responsabilità cambiano, ma il secondo ruolo conserva obblighi concreti, soprattutto quando lo strumento è ad alto rischio.

    In alcuni casi, l’azienda utilizzatrice può diventare essa stessa provider. Può accadere quando appone il proprio nome o marchio sul sistema, introduce una modifica sostanziale oppure cambia la finalità di uno strumento esistente in modo da trasformarlo in un sistema ad alto rischio.

    Le responsabilità lungo la catena del valore sono disciplinate dall’articolo 25 dell’AI Act.

    Un esempio: un’impresa adatta un modello general purpose per classificare automaticamente i candidati e commercializza la soluzione come propria. In una situazione simile, definirsi semplice utente del modello di partenza potrebbe risultare insufficiente.

    La mappa dei sistemi dovrebbe indicare, accanto a ogni applicazione, anche il ruolo assunto dall’organizzazione, il fornitore, le personalizzazioni effettuate e l’eventuale impiego di modelli sviluppati internamente.

    Questa distinzione incide sia sulle procedure sia sulla formazione. Per verificare il ruolo dell’organizzazione e individuare le persone da coinvolgere, è possibile richiedere una consulenza gratuita a Ninja. L’analisi serve a impostare un percorso coerente con i sistemi realmente utilizzati, senza attribuire alla sola partecipazione a un corso una conformità automatica.

    Gli obblighi del deployer di un sistema ad alto rischio

    Quando un’azienda utilizza un sistema classificato ad alto rischio, l’articolo 26 le chiede di adottare misure tecniche e organizzative adeguate e di seguire le istruzioni fornite dal provider.

    La supervisione deve essere affidata a persone dotate di competenza, formazione e autorità. Chi controlla il sistema deve comprenderne limiti e modalità di funzionamento, avere accesso alle informazioni necessarie e poter interrompere o correggere il processo.

    Il deployer deve inoltre:

    • verificare pertinenza e rappresentatività dei dati di input sotto il proprio controllo;
    • monitorare il funzionamento del sistema;
    • informare provider, distributore e autorità quando emergono rischi;
    • sospendere l’utilizzo quando necessario;
    • conservare i log disponibili per almeno sei mesi, salvo diverse norme applicabili;
    • informare preventivamente lavoratori e rappresentanti quando il sistema viene impiegato sul luogo di lavoro;
    • informare le persone coinvolte quando l’AI contribuisce a una decisione che le riguarda.

    Gli obblighi completi sono riportati nell’articolo 26 dell’AI Act.

    La documentazione diventa parte del processo. Inventario degli strumenti, valutazioni, istruzioni ricevute, log, procedure interne e attività formative permettono di ricostruire come l’azienda ha governato l’utilizzo del sistema.

    La presenza di una persona incaricata della supervisione, da sola, offre poche garanzie. Occorre verificare che disponga del tempo, delle competenze e del potere necessari per contestare l’output, chiedere un controllo ulteriore o sospendere l’uso dello strumento.

    Le scadenze dell’AI Act dopo l’AI Omnibus

    Il calendario europeo è cambiato nel luglio 2026 con l’entrata in vigore dell’AI Omnibus.

    Le disposizioni dedicate ai sistemi ad alto rischio dell’Allegato III si applicheranno dal 2 dicembre 2027. Per i sistemi AI incorporati nei prodotti regolamentati indicati nell’Allegato I, la data è il 2 agosto 2028.

    Il calendario aggiornato è disponibile nella pagina ufficiale della Commissione europea sull’AI Act e nella comunicazione dedicata all’entrata in vigore dell’AI Omnibus.

    Il rinvio offre più tempo per preparare standard, procedure e strumenti di supporto. Per un’azienda, però, la mappatura può richiedere mesi, soprattutto nelle organizzazioni con numerose piattaforme, fornitori internazionali e acquisti software gestiti in modo decentralizzato.

    Le disposizioni sull’AI literacy sono entrate in applicazione il 2 febbraio 2025. Le organizzazioni devono valutare il proprio ruolo, i sistemi utilizzati, i rischi associati e le conoscenze necessarie alle persone che lavorano con questi strumenti. La Commissione adotta un approccio proporzionato al contesto e chiarisce che non esiste un identico livello di preparazione valido per ogni mansione.

    La formazione deve seguire rischi e ruoli

    L’AI literacy riguarda la capacità di comprendere il funzionamento essenziale dei sistemi, usarli con consapevolezza e riconoscerne limiti, rischi ed effetti.

    Un team marketing che utilizza strumenti generativi ha esigenze diverse da un gruppo HR che supervisiona un sistema di screening dei candidati. Chi lavora con un sistema ad alto rischio deve conoscere le istruzioni operative, gli errori prevedibili, le modalità di intervento umano e le procedure da seguire in caso di anomalie.

    Nelle proprie domande e risposte sull’AI literacy, la Commissione indica quattro passaggi utili:

    1. capire quali sistemi AI sono presenti nell’organizzazione;
    2. individuare se l’azienda opera come provider o deployer;
    3. considerare i rischi dei sistemi utilizzati;
    4. costruire le iniziative di AI literacy sulla base delle competenze del personale e del contesto d’uso.

    Le istruzioni del fornitore rappresentano una base operativa, ma possono risultare insufficienti. Per i sistemi ad alto rischio, la Commissione richiama la necessità di misure ulteriori affinché il personale sappia gestire lo strumento e garantire una supervisione umana efficace.

    Un attestato può documentare la partecipazione a un percorso. La conformità complessiva deriva dalla coerenza tra sistemi utilizzati, procedure, responsabilità, controlli e competenze.

    La stessa Commissione precisa che replicare una pratica presente nel repository europeo sull’AI literacy non attribuisce automaticamente una presunzione di conformità.

    Assessment, formazione e documentazione aiutano invece l’azienda a dimostrare di avere adottato misure coerenti con i propri sistemi, ruoli e livelli di rischio.

    È su questa logica che si basa il percorso AI Act Compliance Fast Track di Ninja: assessment delle competenze, formazione sull’AI literacy e, nei percorsi più avanzati, approfondimenti dedicati agli obblighi di provider e deployer e alla classificazione per livello di rischio. La consulenza iniziale è gratuita e serve a individuare il punto di partenza dell’organizzazione.

    Da dove partire per controllare i sistemi aziendali

    Il primo risultato della mappatura dovrebbe essere un registro aggiornato degli strumenti AI. Per ciascuno conviene indicare proprietario interno, fornitore, versione, finalità, dipartimento che lo utilizza, persone interessate, dati trattati e livello di autonomia decisionale.

    Segue la verifica dei contratti e della documentazione tecnica. Le aziende devono poter capire quali funzioni sono realmente presenti, come vengono generati gli output e quale controllo è previsto. Le formule commerciali generiche servono a poco quando bisogna distinguere una funzione amministrativa da un sistema che influenza una decisione sulle persone.

    Il terzo passaggio riguarda le competenze. La formazione generale crea un linguaggio comune, mentre i gruppi esposti a rischi più elevati richiedono contenuti specifici. HR, compliance, IT, procurement, legal e responsabili di funzione dovrebbero lavorare sulla stessa mappa.

    Una checklist iniziale può includere:

    • inventario degli strumenti acquistati e sviluppati internamente;
    • indicazione della finalità prevista;
    • verifica delle aree dell’Allegato III;
    • analisi dell’influenza dell’output sulle decisioni;
    • controllo dell’eventuale profilazione di persone;
    • attribuzione del ruolo di provider o deployer;
    • verifica dei dati di input e dei log disponibili;
    • nomina delle persone incaricate della supervisione;
    • definizione della formazione necessaria;
    • raccolta della documentazione prodotta dal fornitore.

    Il risultato non deve essere una fotografia statica. Il registro va aggiornato quando viene acquistato un nuovo software, cambia una funzione, viene attivato un modulo aggiuntivo o un reparto introduce autonomamente uno strumento generativo.

    Per impostare il lavoro, Ninja Business School mette a disposizione una consulenza gratuita sull’AI Act. Il confronto iniziale permette di ricostruire le esigenze del team e valutare un percorso che può comprendere assessment, AI literacy, classificazione del rischio e formazione sui ruoli di provider e deployer.

    L’AI ad alto rischio raramente si presenta con un’etichetta evidente. Può trovarsi dentro un software acquistato anni fa, in una nuova funzione attivata dal fornitore o in un progetto sviluppato internamente per rendere più rapido un processo.

    La verifica comincia da una domanda concreta: quali decisioni stiamo affidando, anche solo in parte, a un sistema AI?

    Tags: