(2/3) Il conto dell'AI Act lo paga il datore di lavoro, non il fornitore

C'è un assunto comodo radicato nel modo in cui la maggior parte delle aziende pensa all'EU AI Act: è un problema di chi costruisce l'IA. I fornitori hanno addestrato i modelli, i fornitori faranno le valutazioni di conformità, i fornitori porteranno il peso della compliance. Noi abbiamo solo comprato una licenza.

Per l'IA ad alto rischio usata nelle assunzioni e nelle HR, quell'assunto è sbagliato in un modo che crea esposizione reale. L'Act divide la responsabilità tra due ruoli — il provider che sviluppa e immette il sistema sul mercato, e il deployer che lo usa sotto la propria autorità. Sì, i provider portano il carico progettuale più pesante. Ma l'Act pone deliberatamente un insieme distinto e non delegabile di obblighi sul deployer. E se sei un'azienda che fa girare uno strumento di IA per la selezione sui propri candidati, il deployer sei tu. La conformità del fornitore non assorbe la tua.

Questa è la Parte 2 di una serie in tre parti. La Parte 1 ha mappato perché quasi tutta l'IA per le HR è classificata ad alto rischio e cosa è vietato del tutto. Qui ripercorro cosa l'Act richiede davvero al datore di lavoro che impiega questi sistemi — e perché gran parte non può essere esternalizzata a una clausola di approvvigionamento.

Gli obblighi del deployer, in parole povere

I doveri fondamentali vivono nell'Articolo 26 ("Obblighi dei deployer di sistemi di IA ad alto rischio"). Togli il legalese e si riducono a una manciata di impegni operativi, non teorici:

• Usare il sistema come previsto (Art. 26(1)). Devi operarlo in linea con le istruzioni del provider. Riutilizza uno strumento di selezione candidati per qualcosa per cui non è stato progettato o documentato, e potresti essere passato da deployer a provider — ereditando nel frattempo l'intero insieme di obblighi del provider.
• Assegnare una supervisione umana reale (Art. 26(2)). La supervisione deve essere affidata a persone fisiche che abbiano la competenza, la formazione e l'autorità per esercitarla. Non un nome su un organigramma. Una persona che capisce il sistema e che può davvero agire su ciò che vede.
• Conservare i log (Art. 26(6)). I deployer devono conservare i log generati automaticamente dal sistema per un periodo appropriato — almeno sei mesi, salvo diversa disposizione di legge. Se non puoi ricostruire cosa ha fatto il sistema e perché, non puoi dimostrare la conformità.
• Informare le persone che vi sono sottoposte (Art. 26(11)). Gli individui soggetti a decisioni prese o assistite da un sistema ad alto rischio devono esserne informati.
• Avvisare prima la forza lavoro (Art. 26(7)). Questo merita una sezione a sé.

L'obbligo su cui le aziende inciamperanno: informare i lavoratori

L'Articolo 26(7) è breve e facile da non notare, ed è dove mi aspetto che più aziende vengano colte in fallo. Prima di mettere in uso un sistema di IA ad alto rischio sul luogo di lavoro, i deployer che sono datori di lavoro devono informare i rappresentanti dei lavoratori e i lavoratori interessati che vi saranno sottoposti.

Non è una cortesia. È una precondizione per un impiego lecito, e si innesta direttamente nel tessuto esistente del diritto del lavoro europeo — che ha già forti diritti di informazione e consultazione per consigli aziendali e rappresentanti dei dipendenti. In diversi Stati membri, introdurre un sistema che monitora o valuta il personale senza passare per quella consultazione non è solo una questione di AI Act; è una questione di diritto collettivo del lavoro.

Il Belgio è l'esempio più pulito di questa sovrapposizione. Molto prima che l'AI Act esistesse, la Convenzione collettiva di lavoro n. 39 (1983) obbligava già i datori di lavoro a informare e consultare quando introducevano nuove tecnologie che incidono in modo significativo sull'occupazione o sulle condizioni di lavoro. L'AI Act non la sostituisce — vi si sovrappone. Quindi un'azienda che impiega uno strumento di IA per le HR in Belgio risponde ora a due regimi contemporaneamente, e sovrapposizioni nazionali simili esistono in tutto il blocco.

La conclusione strategica: non puoi accendere di nascosto un sistema di valutazione basato sull'IA. La trasparenza verso la forza lavoro è parte dell'impiego, e "glielo diremo se lo chiedono" non è ciò che dice la legge.

Una supervisione umana che conta davvero

"Human in the loop" è diventata una delle espressioni più abusate nell'IA. L'Act prova a darle dei denti, attraverso due articoli che lavorano insieme.

L'Articolo 14 obbliga i provider a progettare i sistemi ad alto rischio in modo che possano essere efficacemente supervisionati da un essere umano — con le interfacce, le informazioni e i controlli di arresto che rendono possibile la supervisione. L'Articolo 26(2) obbliga poi il deployer a dotare effettivamente quella supervisione di qualcuno competente e con potere d'azione.

L'asticella che l'Act fissa è una supervisione significativa: la persona deve essere in grado di comprendere l'output del sistema, interpretarlo correttamente, decidere di non usarlo, e annullarlo o ribaltarlo. Un essere umano che timbra una lista di candidati classificata perché lo strumento l'ha prodotta non è supervisione — è automazione con un testimone. Supervisione significa che il giudizio umano può, e a volte effettivamente, cambiare l'esito.

È il punto preciso in cui legge e buona ingegneria convergono. La supervisione che puoi dimostrare è la supervisione che hai progettato: un punto decisionale in cui un essere umano rivede, un registro di cosa ha deciso, e un percorso reale per dissentire dalla macchina.

Le due valutazioni d'impatto

I sistemi HR ad alto rischio attivano due distinti obblighi di valutazione, e le persone li confondono di routine.

• La valutazione d'impatto sui diritti fondamentali (Art. 27). Alcuni deployer di sistemi ad alto rischio devono valutare l'impatto sui diritti fondamentali prima dell'impiego — chi è interessato, cosa potrebbe andare storto, quali mitigazioni e misure di supervisione umana sono in essere. Per i sistemi che decidono chi viene assunto o promosso, non è un esercizio ipotetico.
• La valutazione d'impatto sulla protezione dei dati (GDPR Art. 35). L'IA per le assunzioni tratta dati personali — spesso molti, a volte sensibili. L'Articolo 26(9) dell'AI Act dice esplicitamente ai deployer di usare le informazioni fornite dal provider ai sensi dell'Articolo 13 per svolgere la propria DPIA ai sensi del GDPR. I due regimi sono progettati per incastrarsi.

Se questo suona come due documenti che si sovrappongono, in parte lo è — e la mossa intelligente è gestirli come un'unica valutazione coordinata anziché due esercizi di carta scollegati.

Lo strato GDPR che già dovevi

L'AI Act non è arrivato in un vuoto. Il GDPR governa il trattamento automatizzato dei dati personali dal 2018, e una delle sue disposizioni è sempre stata puntata dritta all'IA per le assunzioni: l'Articolo 22, il diritto a non essere sottoposto a una decisione basata unicamente sul trattamento automatizzato quando produce effetti giuridici o similmente significativi.

Una decisione di rifiuto completamente automatizzata — nessun essere umano coinvolto — è il caso da manuale che l'Articolo 22 è stato scritto per limitare. I candidati hanno diritto all'informazione, all'intervento umano e a contestare la decisione. I requisiti di supervisione umana dell'AI Act e l'Articolo 22 del GDPR sono ora due ragioni che si rafforzano a vicenda per tenere un essere umano competente dentro la decisione, non attorno a essa.

Il proposto Digital Omnibus che ho menzionato nella Parte 1 è in parte un tentativo di chiarire come questi due regimi si articolino. Finché non si assesta, assumi la lettura più rigorosa: una persona, non solo una pipeline, è titolare dell'esito.

Cosa ne risulta

Metti gli obblighi uno dopo l'altro ed emerge una forma chiara. Per impiegare l'IA nelle assunzioni in modo lecito nell'UE, un'azienda deve:

1. Confermare lo strumento e il caso d'uso, e operarlo come documentato.
2. Mettere a capo della supervisione un essere umano competente e con potere d'azione — e rendere quella supervisione reale.
3. Informare i lavoratori e i loro rappresentanti prima dell'impiego.
4. Svolgere una valutazione sui diritti fondamentali e una DPIA coordinata.
5. Conservare i log ed essere in grado di spiegare qualsiasi decisione che il sistema ha toccato.
6. Onorare i diritti GDPR dei candidati all'informazione, all'intervento umano e alla contestazione.

Nessuno di questi è soddisfatto da un badge di conformità del fornitore. Ognuno di essi è qualcosa che il datore di lavoro che impiega il sistema deve possedere, presidiare e documentare.

È un onere — ma è anche un progetto. Le aziende che trattano questo elenco come una specifica di progettazione anziché come una scocciatura legale finiscono con processi di assunzione non solo conformi, ma genuinamente migliori: più trasparenti verso i candidati, più responsabili internamente e più difendibili quando un candidato respinto chiede perché.

Nella Parte 3 entro nello specifico su come appare tutto questo in pratica — usando l'unico processo che conosco intimamente: come abbiamo costruito la preselezione dei candidati remoti di Conectia in modo che l'IA faccia ciò in cui è brava, gli esseri umani restino responsabili della decisione, e il tutto fosse già modellato come la legge prima che la legge lo richiedesse.