Vale anche fuori dall'UE?

«Non siamo un'azienda europea, quindi a noi non si applica» è la lettura sbagliata più diffusa e più costosa del regolamento sull'IA. L'articolo 2 raggiunge fornitori e deployer indipendentemente da dove sono stabiliti. La sede legale non è il criterio. Contano il luogo in cui il tuo sistema è immesso sul mercato, il luogo in cui si trova il tuo deployer e - la clausola di chiusura che quasi tutti si perdono - il luogo in cui l'output viene usato.

L'articolo 2(1)(c) applica il regolamento a fornitori e deployer di paesi terzi «qualora l'output prodotto dal sistema di IA sia utilizzato nell'Unione». Un'azienda di San Francisco senza entità europee, senza server europei e senza personale europeo rientra nell'ambito di applicazione nel momento in cui un cliente di Dublino usa ciò che il suo modello produce.

I sette modi in cui rientri nell'ambito di applicazione

I casi che si presentano davvero

SaaS statunitense con clienti nell'UE. Rientra. Sei il fornitore delle funzioni di IA che spedisci, e l'uso che ne fanno i tuoi clienti porta l'output nell'Unione. Essere costituiti in Delaware è irrilevante. Le specificità SaaS.

Azienda britannica dopo la Brexit. Il Regno Unito è un paese terzo a questi fini, quindi l'analisi è identica a quella statunitense: utenti nell'UE significa rientrare nell'ambito di applicazione. Il Regno Unito non ha una legge equivalente propria, il che significa che le aziende britanniche si prendono gli obblighi del regolamento sull'IA senza un regime interno con cui allinearli.

Azienda dell'UE che vende solo fuori dall'UE. Rientra comunque come deployer ai sensi del 2(1)(b) per i sistemi che usa in proprio, perché quel criterio dipende da dove sei stabilito, non da dove sono i tuoi clienti. I tuoi strumenti di IA interni sono coperti anche se nessun cliente è europeo.

Azienda extra UE con personale nell'UE. L'uso che fai dell'IA su quei dipendenti è attività da deployer che riguarda persone nell'Unione. Gli strumenti per le risorse umane sono l'innesco tipico - e sono anche l'area dell'allegato III con gli obblighi più pesanti. Il dettaglio HR.

Trattamento di dati personali di persone nell'UE ma output usato altrove. È qui che il regolamento sull'IA e il GDPR si separano. Il GDPR segue i dati personali. Il regolamento sull'IA segue il sistema, il mercato e l'output. Puoi essere in pieno ambito GDPR e fuori dal regolamento sull'IA, o il contrario. La mappatura, per i team privacy.

I fornitori extra UE di sistemi ad alto rischio hanno bisogno di qualcuno nell'Unione

Ai sensi dell'articolo 22, un fornitore stabilito in un paese terzo deve nominare, con mandato scritto, un rappresentante autorizzato stabilito nell'Unione prima di mettere a disposizione sul mercato dell'Unione un sistema di IA ad alto rischio. Il rappresentante conserva la documentazione, coopera con le autorità e può porre fine al mandato se il fornitore agisce in contrasto con i propri obblighi.

Esiste un obbligo parallelo per i fornitori di paesi terzi di modelli di IA per finalità generali, ai sensi dell'articolo 54.

È l'obbligo che i team extra UE scoprono per ultimo, perché è amministrativo e non tecnico - ed è una condizione preliminare per l'accesso al mercato, non un adempimento da recuperare dopo. Vale però solo se qualcosa che spedisci è davvero ad alto rischio, e conviene stabilirlo prima di mettersi a cercare un rappresentante.

Che cosa è davvero fuori dall'ambito di applicazione

L'esclusione open source è quella che viene invocata a sproposito più spesso. Rilasciare un modello con una licenza permissiva non lo esenta se è messo in servizio come sistema ad alto rischio, se realizza una pratica vietata o se si applicano gli obblighi di trasparenza dell'articolo 50.

Rientrare nell'ambito di applicazione non significa essere gravato di obblighi

È la parte che si perde per strada. Ambito di applicazione e livello di rischio sono due domande distinte, e quasi ogni azienda extra UE che va nel panico per la prima scopre che la seconda è poco impegnativa.

La maggior parte delle aziende SaaS extra UE che rientrano finisce per essere fornitrice di sistemi a rischio limitato o minimo. In pratica significa: l'informativa dell'articolo 50 se il tuo prodotto dialoga con gli utenti, l'alfabetizzazione dell'articolo 4 per il personale e un controllo sull'articolo 5. Il capo III - valutazione della conformità, marcatura CE, registrazione nella banca dati dell'UE - si applica solo se qualcosa che spedisci è davvero ad alto rischio ai sensi dell'allegato III.

Il risultato che conta davvero, per un'azienda extra UE, è una posizione scritta e datata: quali dei tuoi sistemi rientrano nell'ambito di applicazione, sotto quale lettera dell'articolo 2, a quale livello di rischio e che cosa ne consegue. È quello che chiedono gli uffici acquisti delle grandi aziende europee, e di solito è il lavoro di una giornata, non un programma di conformità.

L'ambito di applicazione territoriale è deciso dall'articolo 2 sui fatti del tuo deployment, non da dove stanno i tuoi server. Ospitare negli Stati Uniti non ti toglie dall'ambito di applicazione, e ospitare nell'UE non ti ci mette. La verifica gratuita passa in rassegna le lettere dell'articolo 2 prima di guardare al livello di rischio, perché sbagliare l'ambito di applicazione rende sbagliato tutto quello che viene dopo.