Articolo 14 della legge dell'UE sull'IA: supervisione umana degli agenti di intelligenza artificiale

L'articolo 14 in una pagina¶

L'articolo 14 si trova nel capo III, sezione 2 del regolamento (UE) 2024/1689. Il suo campo di applicazione sono i sistemi di intelligenza artificiale ad alto rischio. Il sistema deve essere progettato e sviluppato con idonei strumenti di interfaccia uomo-macchina affinché le persone fisiche possano controllarlo efficacemente durante l'uso.

Lo scopo è prevenire o ridurre al minimo i rischi residui per la salute, la sicurezza o i diritti fondamentali quando il sistema funziona come previsto o in caso di uso improprio ragionevolmente prevedibile. Le misure devono corrispondere ai rischi, all’autonomia e al contesto del sistema. Il fornitore può integrare misure nel sistema, identificare misure da implementare per l'operatore o utilizzare entrambi i percorsi.

Il paragrafo 4 definisce la prova pratica di idoneità. La persona assegnata ha bisogno di visibilità e autorità sufficienti per comprendere, monitorare, interpretare, ignorare, ignorare, invertire, intervenire e interrompere. Un proprietario nominato e un documento politico supportano la governance. I controlli implementati devono ancora rendere possibili tali azioni.

La progettazione del provider e il funzionamento del distributore costituiscono un unico controllo¶

L'articolo 14 divide l'implementazione tra fornitore e distributore. Il fornitore identifica le misure, integra controlli tecnicamente fattibili e li descrive nelle istruzioni per l'uso. Articolo 13(3)(d) richiede che tali istruzioni coprano le misure di supervisione umana e le misure tecniche che aiutano gli operatori a interpretare i risultati.

Articolo 26(2) attribuisce all'operatore la responsabilità di assegnare la supervisione a persone fisiche dotate della necessaria competenza, formazione, autorità e supporto. L'utente che esegue la distribuzione configura inoltre i controlli per il proprio personale, i dati, le policy, il flusso di lavoro e l'ambiente operativo.

Scegliere l'intensità della supervisione in base al rischio dell'azione¶

L'articolo 14 nomina tre variabili di proporzionalità: rischio, autonomia e contesto d'uso. Lascia alle organizzazioni il compito di trasformarli in soglie di controllo. Human-in-the-loop, human-on-the-loop e human-in-command sono etichette operative utili per quel progetto. Non sono termini definiti nell'articolo 14.

Classificare l'azione individuale e il sistema di intelligenza artificiale complessivo. Un agente può redigere un riepilogo, interrogare un record, aggiornare uno stato e rilasciare un pagamento nello stesso processo. Ogni azione ha conseguenze e profili di reversibilità diversi.

Costruisci cancelli di approvazione attorno all'effetto collaterale¶

L'articolo 14(4)(d) conferisce al supervisore l'autorità in una situazione particolare di rifiutare l'uso, ignorare un output o ignorarlo o invertirlo. Per un'azione irreversibile dello strumento, un gate di pre-esecuzione è solitamente l'implementazione più forte. Il sistema costruisce l'azione proposta, valuta le regole applicabili e mantiene l'effetto collaterale finché la persona autorizzata non decide.

Il revisore ha bisogno del contesto decisionale in un unico posto. Mostrare l'azione, l'obiettivo, i parametri materiali, l'agente e il richiedente, la regola e la ragione applicabili, la fonte delle prove, l'incertezza e le limitazioni note, le conseguenze, il percorso di inversione e la scadenza della decisione. Un semplice pulsante di approvazione accanto a una frase generata fornisce al revisore troppe poche informazioni per esercitare una supervisione significativa.

Trattare il timeout, l'indisponibilità del revisore, le prove obsolete e la valutazione politica fallita come stati espliciti. Ogni stato ha bisogno di un risultato sicuro definito. Una richiesta in sospeso non deve mai diventare un'approvazione implicita perché una coda, un webhook o un revisore non è disponibile.

• Prima del gate: associa un identificatore di richiesta stabile all'esatta azione proposta e al set di parametri.
• All'ingresso: verifica l'idoneità del revisore e le regole sulla separazione dei compiti al momento della decisione.
• Durante la revisione: emergono le prove attuali, i limiti, le motivazioni politiche, le conseguenze e le alternative disponibili.
• Al momento della decisione: registra l'approvazione, il rifiuto, la richiesta di modifiche o l'escalation con identità, autorità, motivazione e timestamp.
• Prima che l'esecuzione riprenda: conferma che l'azione, la policy, le prove e lo snapshot dell'autorità rimangono aggiornati.
• Dopo l'esecuzione: allega il risultato reale o il fallimento downstream allo stesso record.

Override, inversione e arresto di sicurezza del progetto come controlli separati¶

Gli articoli 14(4)(d) e 14(4)(e) descrivono funzionalità correlate con effetti diversi. Una sostituzione modifica il modo in cui viene utilizzata un'uscita. Un'inversione ripristina o compensa un'azione già avvenuta. Un intervento modifica un'operazione in corso. Un'interruzione arresta il sistema tramite un pulsante di arresto o una procedura simile e lo porta in uno stato sicuro.

Un controllo di arresto ottiene tale etichetta quando la richiesta raggiunge ogni lavoratore, chiamata strumento, agente delegato, lavoro in coda e percorso di nuovo tentativo pertinente. Il sistema deve definire quali operazioni in volo possono terminare, quali vengono annullate, quali credenziali o contratti di locazione vengono revocati e quali dati rimangono affidabili. Necessita inoltre di un percorso di recupero controllato.

Testare la propagazione e lo stato finale in condizioni di guasto realistiche. Includere un'API esterna lenta, un heartbeat del lavoratore perso, un nuovo tentativo in coda, un'azione in più passaggi parzialmente completata e un servizio prove non disponibile. Registra il tempo trascorso dall'azione dell'operatore al contenimento e ogni operazione rimasta in volo.

Fornire ai supervisori competenza, formazione, autorità e supporto¶

L'articolo 26(2) fornisce lo standard del personale lato schieratore. Le persone fisiche assegnate necessitano della competenza, della formazione, dell'autorità e del supporto necessari per svolgere la supervisione. Il considerando 73 collega inoltre un controllo efficace alla competenza, alla formazione e all’autorità.

La competenza riguarda la decisione sul dominio e il sistema di intelligenza artificiale. Un revisore del credito può comprendere la politica di prestito pur non avendo la conoscenza del sistema necessaria per riconoscere lo spostamento della distribuzione, la mancanza di dati di origine o una richiesta fuori ambito. Un operatore della piattaforma può comprendere il sistema ma non avere l'autorità per decidere il risultato del cliente. La progettazione del ruolo deve colmare entrambe le lacune.

L'articolo 26(2) stabilisce uno standard basato sui risultati e nessun intervallo di allenamento fisso. Imposta una cadenza in base al rischio di azione, al tasso di modifica del sistema, al volume operativo, alla cronologia degli incidenti e alle prestazioni del revisore. Attivare una formazione rinnovata dopo modifiche al modello materiale, alle policy, ai dati, all'interfaccia o allo scopo previsto.

• Competenza: regole di dominio, diritti interessati, funzionalità e limitazioni del sistema, qualità dell'input e modalità di errore note.
• Formazione: bias di automazione, strumenti di interpretazione, criteri di escalation, esercitazioni di arresto e recupero e gestione delle prove.
• Autorità: accesso per rifiutare, ignorare, invertire, interrompere, intensificare e ritardare un'azione senza pressione operativa per l'approvazione.
• Supporto: tempo sufficiente, personale, escalation di specialisti, interfacce utilizzabili, istruzioni attuali e assistenza in caso di incidente.
• Garanzia continua: carico in coda, qualità delle decisioni, tasso di override, disaccordo, richieste obsolete, prestazioni dell'esercitazione e rinnovo della formazione.

Progettare contro i pregiudizi dell'automazione¶

L’articolo 14(4)(b) richiama espressamente la tendenza a fare affidamento o fare eccessivo affidamento sui risultati dell’intelligenza artificiale, soprattutto laddove il sistema fornisce informazioni o raccomandazioni per una decisione umana. Un revisore che approva ogni raccomandazione aggiunge latenza e un'apparenza fuorviante di controllo.

L'interfaccia e la procedura operativa dovrebbero consentire un giudizio indipendente. Presentare le prove della fonte e le limitazioni materiali prima della motivazione della raccomandazione. Distinguere i fatti osservati dall'inferenza del modello. Evitare impostazioni predefinite che preselezionano l'approvazione. Ruota o campiona i casi che espongono i revisori a errori. Misura l'accordo e le sostituzioni in base al tipo di azione, al revisore, alla policy e alla versione del sistema, quindi esamina sia la conformità insolita che il disaccordo insolito.

• Richiedere un motivo legato alle prove per approvazioni e sostituzioni consequenziali.
• Mascherare la raccomandazione del modello durante una revisione indipendente di primo passaggio in cui il rischio lo giustifica.
• Inserire casi di test noti e controfattuali controllati negli esercizi di garanzia dei revisori.
• Attenzione alle decisioni rapide, motivazioni identiche ripetute, elevato carico di revisori e accordo quasi perfetto prolungato.
• Fornisci ai revisori un percorso chiaro per verificare i dati di origine, richiedere input specialistici o sospendere il flusso di lavoro.

Raccogliere prove che dimostrino il controllo operato¶

L'Allegato IV inserisce le misure di supervisione umana, comprese le misure di interpretazione tecnica, nella documentazione tecnica del fornitore. L'articolo 13 riporta le misure nelle istruzioni per l'uso. L'Articolo 12 richiede che i sistemi ad alto rischio supportino la registrazione automatica degli eventi per tutta la loro durata, mentre l'Articolo 19 e l'Articolo 26 assegnano compiti di conservazione dei registri sotto il controllo del fornitore e del distributore.

Un pratico pacchetto di prove dell'articolo 14 trae quindi origine da diversi compiti collegati. Dovrebbe mostrare la progettazione, le persone assegnate, le decisioni e gli interventi in tempo reale, lo stato risultante e i test di controllo. L'integrità crittografica può mostrare se un record esportato è cambiato. Non può dimostrare che ogni evento rilevante sia stato catturato o che il controllo scelto fosse giuridicamente sufficiente.

Come KLA implementa il percorso di controllo governato¶

Il Piano di controllo dell'KLA governa le azioni degli agenti strumentati nei punti decisionali. Il KLA Policy Engine valuta la chiamata di uno strumento proposto rispetto alle regole pubblicate e restituisce allow, warn, require_approval o block. Un risultato require_approval mantiene la chiamata proposta e crea una Richiesta di decisione per Decision Desk. Un blocco impedisce alla chiamata governata di raggiungere lo strumento.

Per le Richieste decisionali del piano di controllo, Decision Desk controlla l'autorizzazione decisionale, il ruolo di revisore richiesto, lo stato in sospeso, l'identità del richiedente e del produttore e il tempo dovuto. Impedisce ai richiedenti e ai creatori registrati di decidere la propria richiesta e rifiuta le azioni di approvazione o rifiuto dopo il tempo dovuto. Un controllore idoneo può inoltrare una richiesta scaduta. Registra l'attore decisionale, l'istantanea del ruolo, la decisione, la ragione e il tempo. Questi controlli di separazione e scadenza si basano sulla richiesta che trasporta le identità attuali del produttore e una scadenza. Assicurarsi che ogni percorso di produzione li fornisca e testare l'intero percorso di controllo. Lineage Explorer e Audit Trail mostrano le policy e i record delle decisioni umane collegati all'esecuzione regolamentata. Evidence Room può raggruppare i record selezionati in un Sealed Evidence Bundle le cui firme di servizio e tenant, hash degli artefatti e root Merkle del bundle possono essere controllati offline.

Queste funzionalità implementano parti di un modello operativo dell'articolo 14. L'organizzazione possiede ancora la classificazione legale, la proporzionalità, l'assegnazione fornitore-distributore, la competenza del revisore, il personale, le procedure operative e l'ingegneria dello stato sicuro specifica del sistema. Un blocco preventivo ad un checkpoint non ferma tutti i lavoratori né inverte ogni effetto collaterale esterno. Analizza ogni percorso consequenziale e verifica l'interruzione nel sistema distribuito.

A 10-step Sequenza di implementazione dell'articolo 14¶

Inizia con un'azione consequenziale dell'agente e dimostra il percorso completo. Espandersi dopo che il controllo funziona in condizioni nominali, di guasto e di ripristino.

• 1. Conferma l'ambito. Registra la classificazione del sistema, il ruolo del fornitore o dell'addetto alla distribuzione, lo scopo previsto, il contesto e la data applicabile.
• 2. Azioni di inventario. Elenca ogni lettura, raccomandazione, scrittura, comunicazione esterna, azione finanziaria, modifica di autorizzazione, delega e azione di ripristino.
• 3. Rischio azione punteggio. Conseguenza dell'uso, reversibilità, diritti interessati, volume, rilevabilità, autonomia e uso improprio prevedibile.
• 4. Assegna la supervisione. Scegli la revisione pre-esecuzione, il monitoraggio attivo con intervento o l'operazione limitata con campionamento ed escalation.
• 5. Progetta la visualizzazione del revisore. Presenta l'azione proposta, le prove, la politica, l'incertezza, i limiti, le conseguenze, le alternative e la scadenza.
• 6. Autorità di implementazione. Applica l'idoneità del revisore, la separazione dei compiti, l'escalation, il comportamento di timeout e l'invalidazione delle richieste obsolete.
• 7. Intervento del tecnico. Crea percorsi di disprezzo, override, inversione, interruzione, stato sicuro e riavvio controllato.
• 8. Preparare le persone. Valutare le competenze, formare sui pregiudizi del sistema e dell'automazione, concedere l'autorità e fornire supporto operativo.
• 9. Cattura il record. Correla la richiesta, il risultato del controllo, l'azione umana, il risultato a valle e le prove di integrità.
• 10. Efficacia del test. Esegui esercizi di bypass, interruzione, sovraccarico, azione parziale, lavoratore perso, prove obsolete, arresto della propagazione e recupero; tracciare la bonifica.