Agenti di IA che modificano registri: chi risponde sotto l'AI Act

Il caso: una richiesta, uno strumento e un registro modificato

Immaginiamo che una persona chieda di aggiornare l'indirizzo di un cliente. Un agente interpreta la richiesta, consulta un sistema aziendale, verifica alcuni dati e invia un'istruzione che modifica il registro. La domanda giuridica non si risolve chiamandolo «agente» né osservando che agisce senza una conferma a ogni passo. Prima di tutto, bisogna stabilire quale sistema è stato messo in servizio, con quale finalità e da quale entità.

Il Regolamento (UE) 2024/1689, noto come AI Act, non crea una categoria regolatoria separata per gli agenti. La Commissione indica che un agente contiene generalmente almeno un modello di IA a scopo generale e può costituire un sistema di IA. Questo non significa che ogni agente, come insieme tecnico o prodotto commerciale, abbia necessariamente una classificazione unica: possono intervenire diversi sistemi, componenti e organizzazioni con funzioni distinte.

Per analizzare l'esempio, bisogna descrivere il flusso concreto: chi offre il sistema, chi lo configura, quali strumenti collega, chi autorizza le istruzioni e quale decisione produce la modifica. Conta anche se l'agente prepara solo una proposta o esegue la modifica, e se la finalità è un compito amministrativo ordinario o un'attività inclusa in un ambito regolato dal Regolamento. L'azione esterna è un dato rilevante per l'analisi operativa, ma non basta da sola per concludere che il sistema sia ad alto rischio.

La spiegazione che segue è una mappa generale dell'AI Act, non una determinazione giuridica per un'implementazione specifica. La ripartizione dei ruoli dipende da fatti verificabili e dalla relazione tra i partecipanti, non solo da come si denomina internamente il prodotto.

Sistema, modello, agente e ruoli: concetti distinti

Il Regolamento definisce «sistema di IA» tenendo conto di caratteristiche come il suo funzionamento con diversi livelli di autonomia, la sua capacità di inferenza e la generazione di risultati —ad esempio, previsioni, contenuti, raccomandazioni o decisioni— che possono influenzare ambienti fisici o virtuali. La Commissione ha pubblicato linee guida per aiutare a interpretare quella definizione. L'analisi deve concentrarsi sulla soluzione concreta e sulle sue capacità, non su un'etichetta di mercato come «agente», «copilota» o «automazione intelligente».

Un modello di IA e un sistema di IA non sono sinonimi. Un modello può essere un componente del sistema; il sistema include il modo in cui il modello viene integrato, reso disponibile e utilizzato. A sua volta, «agente» descrive generalmente un'architettura o un modo di funzionamento che può combinare un modello, istruzioni, strumenti, memoria e meccanismi di esecuzione. Questa descrizione tecnica non sostituisce le definizioni del Regolamento.

Il «fornitore» è, in termini generali, chi sviluppa un sistema di IA o un modello di IA a scopo generale, o fa sì che venga sviluppato, e lo immette sul mercato o lo mette in servizio sotto il proprio nome o marchio, nelle condizioni previste dal Regolamento. Il «responsabile del dispiegamento» è chi utilizza il sistema sotto la propria autorità, salvo l'uso personale non professionale. La funzione dipende da ciò che l'entità fa e da come offre o utilizza il prodotto; può differire tra i componenti di una stessa soluzione.

«Integratore» non è, di per sé, una categoria generale di operatore equivalente a fornitore o responsabile del dispiegamento nell'AI Act. Un'azienda che collega strumenti può limitarsi a integrare un sistema, o le sue azioni potrebbero collocarla in un altro ruolo a seconda dei fatti. L'articolo 25 prevede casi in cui un distributore, importatore, responsabile del dispiegamento o un altro terzo passa a essere considerato fornitore di un sistema ad alto rischio, ad esempio se lo commercializza sotto il proprio nome, lo modifica sostanzialmente o ne cambia la finalità prevista in modo da renderlo ad alto rischio. Non ogni configurazione o integrazione produce automaticamente quell'effetto.

Nel caso del registro, il fornitore potrebbe essere chi offre il sistema agentico sotto il proprio marchio; l'azienda cliente potrebbe essere responsabile del dispiegamento se lo utilizza sotto la propria autorità; e una società tecnologica potrebbe fornire servizi di integrazione. Ma queste etichette sono ipotesi di lavoro, non conclusioni: contratti, presentazione al mercato, controllo sul design e modifiche effettuate possono alterare l'inquadramento.

La finalità, non l'autonomia isolata, guida la classificazione

L'AI Act non classifica come ad alto rischio ogni sistema che abbia autonomia, acceda a uno strumento o produca un effetto esterno. La classificazione dipende dai criteri e dagli ambiti definiti nel Regolamento, in particolare se il sistema è un componente di sicurezza di un prodotto coperto dalla legislazione elencata o se appartiene a uno dei casi d'uso dell'allegato III, tenendo conto delle condizioni e delle eccezioni applicabili.

Nell'esempio, modificare una scheda cliente non permette da solo di affermare che il sistema sia ad alto rischio. Bisognerebbe identificare lo scopo previsto del sistema e il settore e il processo in cui opera. L'analisi potrebbe cambiare se il sistema viene utilizzato, ad esempio, per una funzione inclusa espressamente in un ambito dell'allegato III, o se fa parte di un prodotto regolato nei termini del Regolamento. Non basta che un'azienda usi dati personali, che esista automazione o che un'azione sia importante dal punto di vista commerciale.

La finalità prevista si determina a partire da ciò che il fornitore intende che il sistema faccia, come riflesso in istruzioni, documentazione tecnica e materiale di commercializzazione, oltre al contesto d'uso pertinente. Bisogna anche distinguere quello scopo da un uso reale che si discosti da quanto previsto. Se il responsabile del dispiegamento modifica il sistema o ne cambia la finalità, potrebbe essere necessario rivedere sia la classificazione sia chi assume gli obblighi di fornitore.

La Commissione indica che gli agenti contengono generalmente almeno un modello a scopo generale e possono costituire un sistema di IA. La conseguenza pratica è esaminare separatamente le regole applicabili al modello e quelle del sistema integrato, senza inferire che la presenza di un modello a scopo generale determini da sola la classificazione dell'intero sistema.

L'autonomia è rilevante per descrivere il funzionamento e valutare i controlli adeguati. Ad esempio, non è equivalente che il sistema suggerisca una modifica che una persona esegue, che la applichi dopo un'approvazione specifica o che la realizzi automaticamente. Questa differenza può cambiare la valutazione operativa, ma non sostituisce i criteri giuridici di classificazione dell'AI Act.

Responsabilità: separare obblighi del sistema e uso aziendale

Il Regolamento distribuisce gli obblighi in base al ruolo svolto e alla categoria del sistema. Per questo non è corretto attribuire tutti gli obblighi allo sviluppatore del modello, né trasferirli senza più all'azienda cliente. Un flusso può implicare obblighi per più di un'entità, ma solo dopo aver determinato quale sistema si analizza, quali regole gli sono applicabili e chi soddisfa ciascuna definizione.

Per i sistemi ad alto rischio, l'articolo 16 stabilisce obblighi del fornitore, tra cui garantire la conformità ai requisiti applicabili, disporre di un sistema di gestione della qualità, conservare la documentazione e soddisfare gli obblighi di valutazione di conformità, registrazione e altre esigenze indicate nell'articolo. Questo riferimento non trasforma qualsiasi agente in un sistema ad alto rischio né implica che l'azienda che lo integri ne sia sempre il fornitore.

L'articolo 26 regola gli obblighi dei responsabili del dispiegamento di sistemi ad alto rischio. Tra gli altri aspetti, richiede di utilizzare il sistema in conformità alle istruzioni d'uso, assegnare la supervisione umana a persone con competenza e autorità adeguate, e monitorarne il funzionamento nelle condizioni previste. L'ambito concreto dipende dal fatto che si tratti effettivamente di un sistema ad alto rischio e dalle disposizioni applicabili. Non va esteso come obbligo generale dell'AI Act per ogni azione automatizzata.

L'articolo 25 può alterare la ripartizione quando un'entità cambia il ruolo che svolge rispetto a un sistema ad alto rischio: ad esempio, se lo immette sul mercato sotto il proprio nome o marchio, effettua una modifica sostanziale o ne cambia la finalità prevista in modo da renderlo ad alto rischio. La valutazione richiede di esaminare quale modifica è stata fatta e come influisce sul sistema; collegare un'API o cambiare un template non equivale necessariamente a quei casi.

L'articolo 4 dispone che fornitori e responsabili del dispiegamento adottino misure per garantire, nella misura più ampia possibile, un livello sufficiente di alfabetizzazione in materia di IA per il proprio personale e altre persone che operino o utilizzino sistemi in loro nome, tenendo conto di conoscenze, esperienza, formazione, contesto d'uso e persone interessate. L'obbligo non sostituisce l'analisi dei ruoli né trasforma le raccomandazioni di design di questa guida in mandati legali.

Possono risultare pertinenti anche altre norme europee o nazionali, a seconda dei dati trattati, della decisione automatizzata, del settore e delle conseguenze. Questa analisi si limita a collocare le questioni all'interno dell'AI Act e non determina obblighi derivanti da altri quadri.

Permessi, conferma e registri: controlli prudenziali

Sebbene l'AI Act non trasformi automaticamente in obbligo generale ogni controllo tecnico immaginabile, un agente con la capacità di scrivere in sistemi aziendali merita limiti operativi proporzionati. Restringere gli strumenti disponibili, l'ambito dei dati e le operazioni consentite riduce l'impatto potenziale di errori, istruzioni mal interpretate o guasti di integrazione. Queste sono raccomandazioni di design e sicurezza, non affermazioni che ciascuna di esse sia richiesta dall'AI Act in ogni dispiegamento.

Una pratica utile è concedere permessi minimi: permettere all'agente di consultare solo i campi necessari e separare lettura da scrittura. Se un aggiornamento può causare un pregiudizio significativo o è difficile da invertire, potrebbe essere richiesta l'approvazione umana prima di eseguirlo. Per modifiche routinarie, il design potrebbe consentire l'esecuzione automatica entro limiti stretti, con validazioni preliminari e un meccanismo di inversione. La decisione dipende dall'impatto e dal contesto, non da una formula unica.

I registri operativi possono aiutare a ricostruire quale richiesta ha originato un'azione, quali dati o strumenti sono stati usati, quale istruzione è stata inviata, quale risultato ha restituito il sistema e se è intervenuta una persona. È opportuno fissare accesso, conservazione e protezione di quei registri conformemente alle norme applicabili. Registrare un'azione non dimostra da solo che il dispiegamento sia conforme, né sostituisce documentazione o registri legalmente richiesti quando dovuti.

L'escalation umana è una misura di design appropriata quando il sistema rileva dati incompleti, un'istruzione ambigua, un'operazione fuori dal modello autorizzato o un guasto dello strumento. Bisogna definire chi riceve il caso, quali informazioni ottiene e se può interrompere o correggere l'operazione. Nei sistemi ad alto rischio, l'articolo 26 contiene requisiti specifici di supervisione umana per i responsabili del dispiegamento; in altri casi, la raccomandazione prudenziale non deve essere presentata come un obbligo equivalente dell'AI Act.

Queste misure servono a governare le azioni esterne, ma non risolvono la classificazione giuridica. Un'implementazione tecnicamente controllata può richiedere comunque un'analisi di finalità e ruoli; e una classificazione ad alto rischio non è soddisfatta dal mero fatto di limitare i permessi.

Date di applicazione e limiti temporali

Il calendario va letto dal Regolamento ufficiale e distinguere l'entrata in vigore dall'applicazione effettiva di ogni obbligo. Il Regolamento (UE) 2024/1689 è entrato in vigore il 1° agosto 2024. La sua regola generale stabilisce che sarà applicabile dal 2 agosto 2026, ma l'articolo 113 stesso fissa date precedenti per parti specifiche e una data successiva per determinati sistemi ad alto rischio integrati in prodotti regolati.

Dal 2 febbraio 2025 si applicano il capitolo I e il capitolo II, secondo l'articolo 113. Questo include, tra altre disposizioni, le definizioni del capitolo I, l'alfabetizzazione in IA dell'articolo 4 e le pratiche vietate dell'articolo 5. La data non significa che il regime completo dei sistemi ad alto rischio si applichi da allora.

Dal 2 agosto 2025 si applicano, tra le altre, le disposizioni del capitolo V sui modelli di IA a scopo generale, nonché le norme istituzionali e le regole sanzionatorie indicate nell'articolo 113. Per i fornitori di modelli a scopo generale immessi sul mercato prima del 2 agosto 2025, l'articolo 111 stabilisce una disposizione transitoria: devono soddisfare gli obblighi applicabili al più tardi il 2 agosto 2027.

L'applicazione generale inizia il 2 agosto 2026. Per i sistemi ad alto rischio contemplati nell'articolo 6, paragrafo 1, che siano componenti di sicurezza di prodotti o siano prodotti soggetti alla legislazione di armonizzazione elencata nell'allegato I, la data indicata dall'articolo 113 è il 2 agosto 2027. L'articolo 111 contiene anche regole transitorie per sistemi ad alto rischio già immessi sul mercato o messi in servizio prima del 2 agosto 2026; la loro portata dipende da se si producono cambiamenti significativi nel design e da altre condizioni del testo.

Pertanto, non basta citare una data generale in una pianificazione aziendale. Bisogna associare ogni obbligo al suo articolo, categoria e disposizione transitoria, e verificare se il sistema o il modello era già sul mercato o in servizio nella data rilevante. Questo riepilogo riflette il testo del Regolamento (UE) 2024/1689 disponibile nelle fonti fornite; una modifica legislativa successiva, se presente, richiede di ricontrollare la versione ufficiale vigente prima di prendere decisioni.

Checklist di verifica prima del dispiegamento

Inizia delimitando l'oggetto: si analizza un modello, un sistema che lo integra o un flusso di più sistemi? Disegna la catena dalla richiesta alla modifica del registro e indica quale componente genera ogni risultato. Identifica se esiste un'azione esterna e quale entità ne controlla l'esecuzione.

Poi, fissa i ruoli con prove concrete: marchio sotto il quale viene offerto il sistema, contratti, documentazione, chi commissiona o effettua modifiche, chi decide la finalità e chi lo utilizza sotto la propria autorità. Verifica in particolare se una modifica può essere sostanziale o se la finalità prevista è stata cambiata in un modo che influisca sulla categoria del sistema.

Valuta la classificazione senza scorciatoie: identifica la finalità prevista, consulta i criteri dell'articolo 6 e gli ambiti pertinenti degli allegati, e rivedi eccezioni o condizioni. Se le informazioni non permettono di risolverlo, registra la questione come aperta e chiedi una revisione giuridica o regolatoria prima di affermare che il sistema sia o non sia ad alto rischio.

Infine, separa ciò che è richiesto legalmente dalle misure prudenziali: determina quali disposizioni si applicano al ruolo di ogni entità e al sistema specifico; annota date e transizioni; e definisci permessi, approvazioni, registri e escalation come controlli operativi con responsabili e criteri verificabili. Il risultato deve poter essere rivisto quando cambiano il modello, gli strumenti, la finalità, il settore o il modo d'uso.

Questa checklist organizza la verifica iniziale, ma non sostituisce il consulenza giuridica per un prodotto o dispiegamento specifico. Non è nemmeno una guida completa di gestione dei rischi, conformità dei fornitori, valutazione d'impatto o documentazione delle decisioni. Il suo obiettivo è evitare che l'autonomia dell'agente venga usata come sostituto di un'analisi basata sul testo legale e su fatti accreditabili.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.