AI Act, Art. 6(3) e Modello 231: rischi di compliance nei sistemi AI HR e job matching in Italia

1. L’Estetica della Compliance

Partiamo da una distinzione che l’analisi superficiale tende a perdere, perché senza di essa il ragionamento che segue può sembrare un’accusa indiscriminata.

Esistono tre scenari distinti, e confonderli è il primo errore da evitare.

Nel primo, l’esenzione ex Art. 6(3) è corretta e i presidi sono attivi e integrati tra loro: il deployer ha documentato puntualmente perché il sistema svolge un “compito procedurale ristretto”, ha attivato change management, riceve notifiche dal vendor sulle modifiche significative al modello, conduce revisioni collegate a trigger definiti. Questo è il funzionamento corretto dell’istituto. Non è compliance ornamentale.

Nel secondo scenario, l’esenzione è formalmente corretta ma i presidi sono assenti o non integrati: il documento è accurato rispetto all’AI Act, ma non ha generato nessun processo interno. Non esiste un change log. La DPIA non è stata aggiornata dall’adozione del sistema. L’OdV non riceve flussi informativi sul sistema. È questo il failure mode che questo articolo analizza — un pattern osservabile nel design dei controlli di alcune organizzazioni, indipendentemente dalla correttezza formale dell’esenzione, e indipendentemente dalla consapevolezza soggettiva di chi l’ha prodotta.

Nel terzo, l’esenzione è discutibile e i presidi sono assenti: il sistema incide materialmente sulla shortlist o sull’esclusione dei candidati, ma è stato classificato come “preparatorio” con un’argomentazione che non reggerebbe a un esame esterno. Qui il problema è al contempo normativo e organizzativo.

Il report EDPS del dicembre 2025 non distingue tra questi tre scenari — il che è, in sé, un limite metodologico del report oltre che un segnale diagnostico.

La tripartizione proposta qui è uno strumento analitico per leggere quel dato, non una pretesa classificatoria alternativa. La correlazione documentata tra identificazione di un sistema Annex III e contestuale dichiarazione di esenzione può riflettere una genuina incertezza definitoria — le stesse istituzioni UE faticano a distinguere “compito procedurale ristretto” da “compito preparatorio” — oppure può riflettere una tendenza a trattare identificazione ed esenzione come parte dello stesso gesto. Nella realtà, probabilmente, entrambe le dinamiche coesistono.

Il problema strutturale è che il self-assessment, nel secondo e nel terzo scenario, produce un documento che certifica la valutazione senza attivare i presidi che quella valutazione avrebbe dovuto generare.

La documentazione è condizione necessaria di una buona governance AI — ma non è sufficiente; il D.Lgs. 231/01 misura l’adeguatezza del Modello Organizzativo non sulla completezza del fascicolo, ma sulla sua capacità di prevenire il reato nelle circostanze in cui si è verificato.

2. Il Salto Ignorato: Dalla Classificazione all’Adeguatezza Organizzativa

La classificazione AI Act e l’adeguatezza del Modello Organizzativo ex D.Lgs. 231/01 rispondono a domande diverse.

Confonderle è un errore con conseguenze pratiche che emergono in modo misurabile: nel contenzioso, nei reclami non intercettati, negli incident log assenti che non permettono di ricostruire la catena di controllo, negli scostamenti di output rispetto a baseline che nessuno ha definito perché nessuno era responsabile di farlo.

L’AI Act chiede: questo sistema rientra nella categoria High-Risk secondo i criteri dell’Allegato III, e se sì, il deployer ha rispettato gli obblighi corrispondenti?

È una valutazione che si fissa — almeno formalmente — in un momento definito e si documenta. L’AI Act non è completamente statico: modifiche sostanziali al sistema o al contesto d’uso possono richiedere riesame della classificazione. Ma l’impulso a farlo raramente emerge spontaneamente dall’interno dell’organizzazione senza un trigger formale che lo attivi.

Il D.Lgs. 231/01 chiede qualcosa di strutturalmente diverso: l’organizzazione ha adottato e attuato un Modello Organizzativo idoneo a prevenire i reati commessi nell’interesse o a vantaggio dell’ente, e lo ha fatto in modo effettivo?

Non è una domanda sulla classificazione di un sistema. È una domanda sulla tenuta complessiva dell’organizzazione nel tempo, verificata retroattivamente rispetto al reato commesso.

Il CNDCEC (Consiglio Nazionale dei Dottori Commercialisti e degli Esperti Contabili), nelle linee guida 231 aggiornate all’AI, chiarisce che l’uso dell’AI nei processi gestionali introduce il rischio di colpa d’organizzazione non come conseguenza automatica, ma come conseguenza della mancanza di presidio adeguato al rischio che quel sistema effettivamente genera.

La colpa d’organizzazione è strutturalmente indifferente alla classificazione regolatoria: può esistere anche quando il sistema è correttamente classificato come non High-Risk, se l’ente non ha strutturato supervisione, tracciabilità e meccanismi di segnalazione proporzionati all’impatto concreto delle sue decisioni.

Qui occorre una precisazione sul perimetro dei reati-presupposto, perché la tesi perde credibilità se il catalogo è impreciso.

Il D.Lgs. 231/01 non include la discriminazione lavorativa ex D.Lgs. 216/2003 tra i reati-presupposto in senso tecnico.

I rischi penalmente rilevanti in un contesto HR con AI sono più circoscritti:

• il trattamento illecito di dati personali nelle fattispecie ex art. 167 Codice Privacy — trattamento in violazione delle disposizioni sui dati particolari, o effettuato con finalità di profitto o danno a danno dell’interessato;
• i reati informatici connessi a sistemi che accedono o elaborano dati senza base giuridica adeguata.

Il collegamento tra i presidi di processo proposti — change log, incident log, vendor notification, revisione periodica — e questi reati-presupposto non è indiretto:

• la conservazione di log operativi inadeguati,
• l’assenza di procedure che verifichino la base giuridica del trattamento automatizzato, e
• la mancata rilevazione di accessi non autorizzati

sono precisamente il tipo di carenza organizzativa che, in presenza di condotta illecita, trasforma l’inadeguatezza del controllo in responsabilità dell’ente.

Nei contesti di piattaforme con lavoro subordinato mediato da algoritmi — dove il controllo algoritmico gestisce accesso alle opportunità lavorative e applicazione di misure disciplinari — possono rilevare ulteriori fattispecie, ma il perimetro va valutato caso per caso con il penalista che assiste l’ente, non presupposto come regola generale.

Va detto con chiarezza: colpa d’organizzazione non equivale a colpa morale e i presidi richiesti sono proporzionati alla dimensione e complessità dell’ente. Non si chiede a una PMI lo stesso apparato di governance di un gruppo multinazionale. Si chiede che i presidi esistenti siano effettivi — non solo nominali.

Il caso Deliveroo (Trib. Bologna, ordinanza 31 dicembre 2020, R.G. 2949/2019) è richiamato qui come pattern organizzativo, non come precedente 231.

La decisione si fonda sul diritto antidiscriminatorio civile. Ma la dinamica descrive qualcosa di istruttivo: un algoritmo che penalizza l’accesso ai turni per chi ha esercitato diritti sindacali produce effetti giuridicamente rilevanti che nessuno nell’organizzazione era nelle condizioni di rilevare prima del contenzioso.

Non perché il sistema fosse segreto, ma perché non erano stati strutturati flussi informativi capaci di intercettare l’anomalia nel suo formarsi progressivo.

3. Il Rischio Invisibile: Self-Assessment Statico, Sistema Dinamico

Il self-assessment è una fotografia. I sistemi AI sono processi in evoluzione. L’invecchiamento del documento non è un destino inevitabile: è la conseguenza prevedibile dell’assenza di trigger formali che colleghino le modifiche operative al riesame della valutazione.

I sistemi AI esposti a popolazioni di input che cambiano nel tempo sono soggetti a concept drift o distribution shift.

Il distribution shift indica uno spostamento nella distribuzione statistica degli input rispetto a quella su cui il modello è stato addestrato: il sistema riceve, nel tempo, candidati con profili diversi da quelli del dataset originale, e risponde con output calibrati su una realtà che non esiste più.

Il concept drift è più sottile: cambia la relazione stessa tra input e output attesi — ciò che conta come “buon candidato” si modifica per ragioni esterne al modello (mercato del lavoro, evoluzione del ruolo, nuovi requisiti regolatori), ma il modello non lo sa.

In entrambi i casi, la degradazione avviene in modo graduale e non immediatamente visibile, senza che nessuna modifica esplicita al codice abbia avuto luogo.

La relazione tra gli input del modello e gli output attesi, quindi, cambia spesso in modo graduale e non immediatamente visibile, senza che nessuna modifica esplicita al codice abbia avuto luogo.

Un self-assessment prodotto al momento dell’adozione del sistema non cattura questa dinamica per definizione.

Va però mantenuta la distinzione tecnica: il drift operativo è un fenomeno diverso dal collasso del modello per sostituzione sistematica di dati reali con dati sintetici ricorsivi (Shumailov et al., Nature 2024), che riguarda processi di re-training su larga scala. Confondere i due fenomeni è un errore che apre fronti tecnici evitabili e indebolisce l’argomentazione complessiva.

La diagnosi del failure mode si basa sull’identificazione di tre indicatori minimi la cui compresenza segnala un presidio isolato anziché integrato:

• assenza di trigger formale di riesame collegato agli aggiornamenti del sistema;
• assenza di clausola contrattuale di vendor notification sulle modifiche significative al modello;
• assenza di incident log che colleghi le segnalazioni ricevute a revisioni documentate.

Una “DPIA aggiornata” in questo contesto non significa, quindi, una semplice revisione annuale automatica, ma un aggiornamento event-driven collegato ad almeno tre categorie di eventi sempre rilevanti:

• una release del vendor che modifica parametri o logica del modello;
• un cambio nel perimetro d’uso del sistema rispetto a quello valutato;
• la comparsa di segnali di anomalia negli output.

Gli eventi discrezionali — aggiornamenti minori, modifiche di interfaccia — possono essere gestiti, invece, con una logica di soglia definita internamente.

Molte organizzazioni non partono da zero, avendo pezzi di controllo sparsi (DPIA una tantum, policy HR generiche, vendor due diligence al momento dell’acquisto).

Il problema non è l’assenza totale di presidi, ma la loro mancata integrazione:

• strumenti che non si parlano,
• responsabilità non assegnate su chi li tiene vivi nel tempo,
• nessun canale che li colleghi all’OdV.

Su questo punto è utile distinguere tre livelli di presidio, perché non tutto è esigibile nelle stesse condizioni.

• Il livello minimo di governance — ragionevolmente esigibile in qualsiasi organizzazione che utilizzi sistemi AI con impatto su selezione o gestione del personale — comprende i tre elementi già citati come indicatori diagnostici, più una procedura di review periodica documentata collegata a quei trigger. Sono presidi di processo, non di algoritmo. Non richiedono competenze tecniche avanzate. Sono il prerequisito senza il quale i livelli successivi non hanno senso, e la loro assenza è già, di per sé, un indicatore di inadeguatezza organizzativa.
• Il livello di controllo operativo aggiunge:
• campionamenti degli output con revisione umana su un sottoinsieme definito per volume e impatto del rischio — non necessariamente un campione statisticamente rappresentativo in senso tecnico, ma un sottoinsieme selezionato su base risk-based che copra le categorie di decisione ad alto impatto;
• procedure di escalation documentate per i casi borderline;
• meccanismi di override con traccia delle motivazioni.

I segnali che giustificano l’attivazione di questo livello non richiedono dati demografici: un aumento anomalo del tasso di esclusione rispetto alla baseline, spike di reclami, variazioni significative nella distribuzione degli output sono indicatori sufficienti.

3. Il livello di valutazione degli impatti — che include analisi di equità su categorie demografiche — solleva un problema reale che non va minimizzato. Raccogliere metriche demografiche sugli output di un sistema di screening richiede o di trattare dati particolari con base giuridica dedicata, o di lavorare su proxy e subset volontari, con limiti di rappresentatività che devono essere documentati. È uno strumento da attivare in presenza di segnali provenienti dal livello operativo, con DPIA dedicata che valuti esplicitamente il trade-off tra rischio di discriminazione non rilevata e rischio privacy del monitoraggio stesso. Non è il default.

L’OdV non ha bisogno del livello tre per vigilare. Ha bisogno che esista il livello uno, che sia integrato, e che i suoi flussi informativi lo riflettano.

4. La Prova Contro l’Ente: Quando il Documento Diventa Indizio

In determinate condizioni — non come regola automatica — il documento di esenzione smette di essere uno scudo e diventa un elemento di valutazione sfavorevole nell’analisi dell’idoneità del Modello Organizzativo.

La logica è questa.

La documentazione in un sistema 231 è condizione necessaria ma non sufficiente: contribuisce a dimostrare l’idoneità del modello, ma non la esaurisce.

Quando un ente produce un self-assessment ex Art. 6(3) e questo documento è l’unico presidio formale attivato — non ha generato change management, non ha prodotto flussi informativi verso l’OdV, non è stato riesaminato al mutare del contesto — emerge un’asimmetria tra l’onere documentale sostenuto e l’onere organizzativo non sostenuto.

Il fascicolo attesta che una valutazione è stata effettuata; l’assenza di tutto il resto attesta che quella valutazione non ha prodotto attuazione.

Non basta documentare la valutazione: occorre documentare anche i trigger e i processi che la mantengono viva nel tempo.

Quando questi mancano, il documento non contraddice l’idoneità in senso logico ma ne espone la mancata attuazione in modo che il successivo giudizio di adeguatezza ex D.Lgs. 231/01 non può ignorare.

Va però introdotta una distinzione operativa che la tesi richiede per non dilatarsi fino a coprire ogni uso di AI.

Il sistema che decide e il sistema che raccomanda non sono categorie nette nella pratica: esiste una terza condizione, quella del sistema che raccomanda ma domina, dove il ranking prodotto dall’algoritmo è nominalmente non vincolante ma, per effetto dell’automation bias (la tendenza documentata degli operatori umani ad accettare acriticamente le raccomandazioni algoritmiche) diventa de facto determinante.

In questi casi, la “revisione umana” dichiarata non è sufficiente senza presidi procedurali che ne verifichino l’effettività.

Non si tratta di sorvegliare i decisori né di costruire un controllo disciplinare mascherato: si tratta di documentare, su un campione risk-based di decisioni ad alto impatto, che la motivazione finale non coincide meccanicamente con l’output algoritmico e che esiste una procedura accessibile per contestare la raccomandazione.

L’audit di coerenza ha dunque una finalità di qualità del processo, non di valutazione individuale: verifica che il sistema di controllo funzioni, non che il singolo decisore si sia comportato in un certo modo.

Per “revisione sistematica” si intende quindi una revisione che copra, su base risk-based, le categorie di decisione ad alto impatto, con documentazione delle motivazioni quando la decisione finale diverge dalla raccomandazione algoritmica.

La tesi sulla responsabilità organizzativa è più solida quando il sistema incide materialmente sull’esclusione o sulla shortlist senza questo tipo di presidio procedurale documentato.

Quando l’AI è genuinamente assistiva — con override documentati e procedura di contestazione accessibile — il ponte verso la colpa d’organizzazione si allunga considerevolmente.

Il caso iTutorGroup (EEOC, Charge №846–2023–00088) è richiamato con le cautele necessarie: è extra-UE, si fonda su un framework antidiscriminatorio diverso, e vale come pattern, non come precedente applicabile.

Un sistema AI che rifiuta sistematicamente candidature di donne oltre i 55 anni e uomini oltre i 60 produce discriminazione per età documentabile.

Il settlement non nasce dall’uso dell’AI in sé: nasce dall’assenza di qualsiasi meccanismo di monitoraggio degli output, dall’incapacità organizzativa di rilevare l’anomalia prima che fosse un’autorità esterna a farlo.

5. Il Nuovo Ruolo dell’OdV: Validare il Processo, Non il Codice

L’obiezione più frequente a questo impianto argomentativo è tecnica: l’OdV non ha le competenze per valutare un sistema AI.

Non può leggere il codice sorgente, non può interpretare i pesi di un modello, non può condurre autonomamente un test di equità algoritmica.

L’obiezione è giusta come premessa. La conclusione che spesso ne deriva — “quindi l’OdV non può fare molto sui sistemi AI” — è sbagliata.

Il compito dell’OdV non è validare il codice. È validare il processo di validazione.

Sul piano del process monitoring — change log, incident log, vendor notification, procedure di riesame — l’OdV può e deve verificare che questi strumenti esistano, siano operativi, e alimentino i flussi informativi che lo riguardano.

Sul piano dell’output monitoring — indicatori di drift, distribuzione degli output nel tempo, tasso di scostamento dalla baseline — l’OdV può attendersi che esista una funzione tecnica interna che lo conduca e che i risultati arrivino in forma leggibile e azionabile.

Non è richiesto che l’OdV interpreti un grafico di distribuzione: è richiesto che sappia a chi chiederlo, con quale frequenza riceverlo, e con quale soglia attivare un approfondimento.

“Audit indipendente” va definito operativamente:

• Può indicare la funzione internal audit con mandato formale di revisione periodica sui sistemi AI HR, indipendente dalla funzione che li gestisce.
• Può indicare una terza parte specializzata per i contesti di maggiore complessità o impatto.
• Può indicare una verifica condotta con accesso ai log del vendor su base contrattuale.

Il minimo ragionevolmente esigibile in un contesto di media complessità è il primo — una funzione interna con mandato formale e canale documentato verso l’OdV.

Il 52% degli enti mappati dall’EDPS si dichiara esclusivamente utente di sistemi AI sviluppati da terzi. Il potere negoziale con vendor dominanti — intendendo per tali quei fornitori, di qualsiasi dimensione, che non includono come standard contrattuale clausole di audit, log access o notifica delle modifiche — è spesso limitato, e questo va detto esplicitamente. La distinzione operativa è però utile e va resa concreta.

Quali sono le clausole ragionevolmente esigibili come standard minimo contrattuale, anche nei confronti di vendor con forte posizione di mercato?

• notifica delle modifiche significative al modello o alla configurazione entro un termine definito;
• accesso ai log operativi per finalità di monitoraggio interno;
• incident reporting su anomalie rilevate dal vendor.

Solitamente queste tipologie di clausole sono presenti nelle licenze Enterprise messe a disposizione dai vendor.

Ci sarebbero, poi, altre clausole, strutturalmente difficili e negoziabili solo in presenza di rapporti tra parti di dimensioni comparabili o in contesti ad alto impatto regolatorio:

• accesso ai dati di training,
• disclosure dell’architettura del modello,
• audit tecnico completo del codice.

L’assenza delle prime può essere un indicatore di inadeguatezza organizzativa ex ante — indipendentemente da chi sia il vendor. L’assenza delle seconde è un limite strutturale del mercato, da gestire attraverso i presidi di processo interni piuttosto che attraverso pretese contrattuali irrealistiche.

Il contratto è il momento in cui questa distinzione va affrontata. Spesso non viene affrontata ex ante perché il problema viene percepito come tecnico — e quando diventa organizzativo, il vendor non ha più incentivi a rinegoziare.

Conclusioni: Il Default Organizzativo

La tesi di questo articolo è più precisa di come potrebbe apparire dal titolo — e vale la pena renderla esplicita prima di chiudere.

Non sostiene che l’AI Act sia scritto per essere aggirato. Non sostiene che il self-assessment sia strutturalmente elusivo. Non sostiene che ogni uso di AI in HR generi rischio 231.

Sostiene che, in presenza di tre condizioni diagnosticabili e auditable — esenzione ex Art. 6(3) trattata come presidio isolato, sistema che incide materialmente su esclusione o shortlist senza presidio procedurale anti-automation bias, assenza dei tre indicatori minimi di governance integrata — la compliance AI Act e l’adeguatezza organizzativa ex D.Lgs. 231/01 divergono.

Quella divergenza non è visibile nel fascicolo. Diventa visibile nel contenzioso, nei reclami non intercettati, negli scostamenti di output che nessuno ha rilevato perché nessuno era responsabile di farlo.

Le tre tensioni che strutturano questo articolo non si risolvono con uno strumento solo.

Il self-assessment statico di fronte a un sistema dinamico non si risolve imponendo revisioni formali periodiche — ma senza trigger event-driven che colleghino le modifiche operative al riesame della valutazione, il documento invecchia prima della scadenza.

Il disallineamento DPIA-OdV non si risolve aumentando il volume di reportistica — senza flussi informativi che traducano i segnali operativi del sistema in indicatori leggibili dall’OdV, la vigilanza si ferma alla superficie.

La dipendenza dal vendor non si elimina per via legislativa ma si gestisce, per il perimetro delle clausole ragionevolmente esigibili, nelle trattative contrattuali che spesso non avvengono ex ante perché il problema viene classificato come tecnico anziché organizzativo.

L’EDPB e l’EDPS, nel Joint Opinion 1/2026 on the Proposal for a Regulation as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI) del 20 gennaio 2026, si sono opposti alla proposta di eliminare l’obbligo di registrazione per i provider che concludano, sulla base di un self-assessment ex Art. 6(3), che il proprio sistema non è ad alto rischio.

Le autorità avvertono che questa eliminazione ridurrebbe la trasparenza e la tracciabilità esterna del processo di classificazione, ostacolando la risposta tempestiva delle autorità di sorveglianza del mercato e producendo un effetto prevedibile: ridurre la trasparenza aumenta l’asimmetria informativa tra provider e autorità, aumenta la probabilità di valutazioni non riesaminate, riduce la pressione a documentare i trigger e i processi che tengono viva la valutazione nel tempo.

Non è un’accusa di malafede. È la descrizione di un meccanismo di incentivi con effetti prevedibili.

La vera domanda non è se il documento di esenzione sia valido.

È se, in assenza di tutto il resto, valga qualcosa. E se nel fascicolo finisce solo il documento — senza i presidi del livello minimo di governance integrata, senza flussi informativi verso l’OdV, senza trigger event-driven che colleghino le modifiche del sistema al riesame della valutazione — la risposta, in determinate condizioni, è già scritta nel D.Lgs. 231/01.

Basta saperla leggere prima che la legga qualcun altro.