UISH

Sezione 5 – Verifica se i software prodotti sono qualificabili come Intelligenza Artificiale

a cura di CNR-IFAC

Valentina Colcelli, Nicola Zoppetti, Andrea Barucci, Andrea Manzi

La qualificazione del software come sistema di IA è il passaggio che determina l'applicazione dell'AI Act e dei conseguenti obblighi (in particolare la classificazione del rischio e gli obblighi di trasparenza, trattati nel seguito di questa sezione). Per orientare lo sviluppatore in questa verifica si propongono di seguito: la definizione normativa, una checklist a scorrimento sui sette elementi che la compongono, un vocabolario tecnico minimo derivato da ISO/IEC 22989:2022, un approfondimento sull'algoritmo deterministico (caso in cui la qualificazione come IA non sussiste) e una serie di esempi di applicazione della checklist.

5.1 Definizione di sistema di IA: checklist, vocabolario ed esempi

5.1.1 Algoritmo, modello e sistema: dal generale all'IA

Prima di applicare la checklist conviene fissare tre nozioni annidate — algoritmo, modello e sistema — dapprima nel loro significato generale e poi nel significato specifico che assumono per l'intelligenza artificiale ai sensi dell'AI Act e della norma ISO/IEC 22989:2022.

In generale

• Algoritmo: una sequenza finita e ordinata di istruzioni ben definite per risolvere un problema o elaborare dati. La giurisprudenza amministrativa lo ha definito come «una sequenza finita e ordinata di operazioni elementari e chiare di calcolo che permettono di risolvere, in maniera determinata, un problema» (Cons. Stato, Sez. VI, sent. n. 2270/2019; cfr. TAR Campania, Napoli, Sez. VII, 14 novembre 2022, n. 7003). In sé è una procedura astratta: non è né «IA» né «non IA».
• Modello: ai sensi della ISO/IEC 22989:2022 (punto 3.1.23) è la «rappresentazione fisica, matematica o comunque logica di un sistema, di un'entità, di un fenomeno, di un processo o di dati». È la rappresentazione su cui un sistema opera; nei sistemi di apprendimento è il costrutto che, dopo l'addestramento, produce inferenze o previsioni.
• Sistema: un insieme di componenti interagenti, organizzati per conseguire uno o più scopi (definizione generale di «sistema», ISO/IEC/IEEE 24765:2017). È l'artefatto ingegnerizzato che mette in esercizio uno o più algoritmi e modelli, con interfacce di input/output verso l'ambiente.

Per l'intelligenza artificiale

• Sistema di IA: ai sensi dell'art. 3, punto 1) del Regolamento (UE) 2024/1689 è «un sistema automatizzato progettato per funzionare con livelli di autonomia variabili […] che, per obiettivi espliciti o impliciti, deduce dall'input che riceve come generare output» (testo integrale al § 5.1.2); in termini tecnici la ISO/IEC 22989:2022 (punto 3.1.4) lo descrive come «sistema ingegnerizzato che genera output […] a fronte di un insieme di obiettivi definiti dall'uomo». L'elemento che lo distingue dal software tradizionale è l'inferenza, unita all'autonomia e all'adattabilità (considerando 12 dell'AI Act).
• Modello di IA: è il modello (nel senso ISO sopra) addestrato su dati, nucleo che genera le inferenze del sistema. L'AI Act non disciplina i modelli in quanto tali, ma dedica una disciplina specifica ai modelli per finalità generali (GPAI), «caratterizzati da una generalità significativa […] in grado di svolgere con competenza un'ampia gamma di compiti distinti» (art. 3, punto 63). Un modello, dunque, non è necessariamente un GPAI: il GPAI è solo il caso che fa scattare obblighi propri.
• Algoritmo nel contesto dell'IA: anche i sistemi di IA si fondano su algoritmi (ad es. algoritmi di apprendimento), ma ai fini della qualificazione rileva come l'algoritmo opera: se il sistema si limita ad applicare regole fissate manualmente è un algoritmo deterministico e resta fuori dalla nozione di IA; se invece un motore inferisce conclusioni non specificate puntualmente — anche con regole codificate — si ricade nell'IA (considerando 12 AI Act; Cons. Stato, Sez. III, sent. n. 7891/2021). L'approfondimento è al § 5.1.7.

Tabella sinottica — le tre nozioni nel significato generale e in quello specifico per l'IA.

5.1.2 Definizione normativa

Ai sensi dell'art. 3, punto 1), del Regolamento (UE) 2024/1689 (AI Act), si intende per «sistema di IA»:

«un sistema automatizzato progettato per funzionare con livelli di autonomia variabili e che può presentare adattabilità dopo la diffusione e che, per obiettivi espliciti o impliciti, deduce dall'input che riceve come generare output quali previsioni, contenuti, raccomandazioni o decisioni che possono influenzare ambienti fisici o virtuali».

Nota terminologica. La versione italiana dell'AI Act rende l'espressione inglese machine-based system con «sistema automatizzato». Gli Orientamenti della Commissione (parr. 11–12) chiariscono che il termine indica soltanto che il sistema opera per mezzo di macchine, cioè di componenti hardware e software che forniscono capacità di calcolo: «tutti i sistemi di IA sono automatizzati, in quanto richiedono macchine per il loro funzionamento». L'aggettivo non va quindi letto come sinonimo di automazione: l'elemento 1 è un presupposto comune a qualsiasi software e non è, da solo, indice di IA. Ciò che distingue un sistema di IA dal software tradizionale, per quanto automatizzato, è la capacità di inferenza (elemento 5).

Quando il software sviluppato è invece un modello (e non un sistema), rileva la definizione di «modello di IA per finalità generali» di cui all'art. 3, punto 63), dell'AI Act; in tal caso si rinvia al § 5.3 (Questionario definitorio di modello di IA).

5.1.3 Nozioni correlate

Le nozioni che seguono non sono oggetto della checklist del § 5.1.4, ma rappresentano riferimenti utili al lettore che, una volta qualificato il proprio software, intenda collocarlo correttamente nel quadro normativo dell'AI Act e dell'ordinamento nazionale.

Sistema di IA per finalità generali (GPAI) — art. 3, punto 66) AI Act. Sistema di IA basato su un modello di IA per finalità generali e in grado di perseguire varie finalità, sia per uso diretto sia per integrazione in altri sistemi di IA. La classificazione dei modelli GPAI con rischio sistemico è dettata dall'art. 51 dell'AI Act (soglie di capacità computazionale e criteri di cui all'allegato XIII).

Fornitore a valle — art. 3, punto 68) AI Act. Fornitore di un sistema di IA — anche per finalità generali — che integra un modello di IA, sia esso fornito dallo stesso soggetto e integrato verticalmente, sia fornito da un'altra entità sulla base di relazioni contrattuali. La nozione rileva per individuare gli obblighi lungo la catena del valore.

Fornitore e deployer — art. 3, punti 3) e 4) AI Act. Il fornitore sviluppa un sistema di IA, o lo fa sviluppare, e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio; il deployer utilizza un sistema di IA sotto la propria autorità, salvo l'uso personale non professionale. La distinzione è decisiva perché gli obblighi dell'AI Act sono ripartiti fra i due ruoli: l'ente che sviluppa e consegna alla PA un modulo di IA del GDU può assumere la posizione di fornitore, mentre la PA che lo impiega nei propri procedimenti è deployer di norma; la PA è invece fornitore se sviluppa o fa sviluppare un sistema e lo mette in servizio con il proprio nome o marchio (art. 3, punto 3), e lo diventa nei casi dell’art. 25, par. 1 (si vedano i riquadri nel seguito di questa sezione).

Disciplina nazionale sull'IA. La legge 23 settembre 2025, n. 132 (G.U. del 25 settembre 2025, codice redazionale 25G00143) reca i principi e le deleghe per l'adeguamento dell'ordinamento interno al Regolamento (UE) 2024/1689 e va consultata per gli aspetti di competenza nazionale (autorità competenti, sanzioni, ricerca, trattamento dati). Ai fini della legge si applica la stessa definizione di sistema di IA del regolamento (art. 2, comma 1, lett. a)).

Linee Guida AGID per l'adozione di IA nella PA. La Bozza di Linee Guida AGID (Determinazione n. 17/2025) recepisce la definizione di sistema di IA dell'art. 3, punto 1) dell'AI Act e ne articola in tabella le quattro caratteristiche distintive (capacità inferenziale, obiettivi, livelli di autonomia variabili, adattabilità). È il riferimento operativo per le pubbliche amministrazioni in fase di adozione.

5.1.4 Checklist a scorrimento — i sette elementi della definizione

La definizione si compone di sette elementi. Per ciascuno, lo sviluppatore valuta la ricorrenza nel proprio software rispondendo alla domanda guida e confrontando il criterio con la realtà del sistema; gli esempi forniti — articolati in due gruppi, rispettivamente per i sistemi che rientrano nell'elemento e per quelli che non vi rientrano — hanno funzione orientativa. Gli Orientamenti della Commissione (par. 9) precisano che non è necessario che i sette elementi siano presenti in modo continuativo: alcuni possono comparire solo nella fase di costruzione (training) e non in quella di utilizzo, e viceversa.

Elemento 1 — Sistema automatizzato (basato su macchina)

Domanda guida. Il software è implementato ed eseguito da una macchina, intesa come combinazione di componenti hardware (unità di elaborazione, memoria, archiviazione, rete) e software (codice, programmi, sistema operativo), che provvede al funzionamento senza necessità di esecuzione manuale dei singoli passi?

Criterio di ricorrenza. L'elemento ricorre quando l'esecuzione del software dipende interamente da una piattaforma computazionale capace di elaborare i dati e produrre i risultati: la nozione è deliberatamente ampia e comprende sistemi tradizionali, calcolo distribuito, calcolo quantistico e perfino sistemi biologici od organici, purché forniscano capacità computazionale (Orientamenti Commissione, parr. 11–13). Non ricorre, di converso, in presenza di procedure interamente manuali, anche se documentate.

Esempi di sistemi che rientrano nell'elemento:

• Servizio cloud che ospita un classificatore di immagini per riconoscere veicoli, pedoni e ciclisti dalle telecamere stradali del GDU.
• Microservizio backend che riceve i dati di una rete di sensori IoT urbani, li passa a un modello e restituisce un esito.
• Modulo embedded eseguito su edge device (es. centralina semaforica) che effettua inferenza on-device.
• Sistema ibrido che combina elaborazione classica e moduli di calcolo quantistico per problemi di ottimizzazione del trasporto pubblico.
• Pipeline di simulazione molecolare eseguita su cluster HPC per lo studio di sistemi biofisici.
• Pipeline di analisi di immagini di microscopia confocale eseguita su workstation con GPU dedicate.

Esempi di sistemi che non vi rientrano:

• Procedura di valutazione delle pratiche svolta interamente dall'operatore con strumenti cartacei o moduli da compilare a mano.
• Foglio di calcolo costantemente aggiornato dall'operatore, privo di componente di elaborazione automatica.
• Linea guida organizzativa scritta in un documento ma non tradotta in alcun applicativo.
• Esperimento di laboratorio con strumentazione manuale e annotazione dei risultati su quaderno, senza implementazione software della procedura.

Elemento 2 — Autonomia variabile

Domanda guida. Il software è progettato per produrre output con un grado, anche minimo, di indipendenza dall'intervento umano diretto e continuo?

Criterio di ricorrenza. L'elemento ricorre quando il sistema può generare almeno un output non puntualmente specificato dall'operatore: la relazione tra autonomia e coinvolgimento umano è un continuum (Orientamenti Commissione, parr. 15–17), per cui rileva anche il caso del sistema che riceve input manuali ma produce autonomamente l'output. Non ricorre quando ogni output del software è interamente determinato da un'azione umana puntuale e passo-passo, senza alcun margine di iniziativa del sistema.

Esempi di sistemi che rientrano nell'elemento:

• Sistema di rilevazione anomalie sui flussi di traffico del GDU che, ricevuti i dati in tempo reale dai sensori, emette un alert senza necessità di una conferma umana per ciascun caso.
• Modulo di trascrizione automatica del parlato in testo, che produce il trascritto senza che l'utente intervenga sulle singole parole.
• Pianificatore di percorsi che, ricevuti i vincoli di partenza, arrivo e disponibilità della rete, restituisce in autonomia un piano completo.
• Filtro anti-spam che etichetta i messaggi senza richiedere una decisione umana su ciascuno.
• Pipeline di osservazione astronomica che individua automaticamente candidati transienti nei flussi del telescopio, senza intervento per ciascuna immagine.
• Sistema di acquisizione automatica in fisica delle alte energie che applica un trigger di primo livello sui dati dei rivelatori senza intervento umano puntuale.

Esempi di sistemi che non vi rientrano:

• Editor di testo che esegue esclusivamente i comandi di formattazione attivati uno alla volta dall'utente.
• Calcolatrice scientifica.
• Macro o script che esegue una sequenza di operazioni rigorosamente identica a ogni invocazione.
• Workflow di approvazione in cui ciascun avanzamento richiede l'azione manuale puntuale dell'operatore e l'output di ciascun nodo è soltanto la registrazione della scelta umana.
• Sessione di analisi statistica in ambiente interattivo (R, Python notebook) in cui il ricercatore imposta e supervisiona ogni singolo passaggio.

Elemento 3 — Adattabilità dopo la diffusione

Domanda guida. Il software, una volta messo in servizio, può modificare il proprio comportamento sulla base dell'esperienza acquisita, fino a generare output diversi a parità di input?

Criterio di ricorrenza. L'elemento ricorre quando il sistema dispone di meccanismi di autoapprendimento o di aggiornamento dei propri parametri durante l'uso, anche limitatamente a fasi di ri-addestramento automatico al verificarsi di soglie. Non ricorre quando il modello è congelato al momento del rilascio e ogni modifica del comportamento richiede una nuova release. L'adattabilità non è requisito obbligatorio per la qualificazione come IA (AI Act, art. 3 e Orientamenti Commissione, parr. 22–23): la sua assenza non esclude di per sé la qualificazione, ma la sua presenza la corrobora.

Esempi di sistemi che rientrano nell'elemento:

• Motore di raccomandazione di servizi pubblici che riallinea i pesi del modello in produzione sulla base delle interazioni degli utenti (online learning).
• Sistema di rilevazione di frodi che esegue fine-tuning periodico automatico su dati raccolti durante l'esercizio.
• Agente di reinforcement learning che aggiorna la propria politica decisionale a seguito del feedback ricevuto dall'ambiente.
• Pipeline con retraining automatico innescato dal superamento di una soglia di drift dei dati.
• Classificatore di immagini istopatologiche ri-addestrato in continuo all'arrivo di nuovi casi etichettati dai patologi.
• Modello di analisi del segnale fisiologico che adatta i propri parametri al singolo paziente durante l'uso clinico.

Esempi di sistemi che non vi rientrano:

• Modello di classificazione i cui parametri restano invariati dopo il rilascio; eventuali aggiornamenti avvengono solo offline e tramite distribuzione di una nuova versione del servizio.
• Componente con logica codificata manualmente che non muta a meno di un nuovo deploy.
• Calcolatore di indicatori sintetici i cui pesi sono fissati a monte e non vengono mai rivisti senza intervento umano.
• Modello di simulazione climatica i cui parametri (fisici e calibrati) sono congelati al momento del rilascio del run di produzione e non vengono modificati in esercizio.

Elemento 4 — Obiettivi (espliciti o impliciti)

Domanda guida. Il software persegue, durante il proprio funzionamento, uno o più obiettivi — anche non dichiarati esplicitamente — ricavabili dal suo comportamento o dalle sue assunzioni di progetto?

Criterio di ricorrenza. L'elemento ricorre sia quando gli obiettivi sono codificati in modo dichiarato (ad esempio una funzione di costo o di ricompensa) sia quando emergono implicitamente dai parametri scelti, dai dati di addestramento o dalle metriche di valutazione. Va distinto dallo scopo previsto, che è esterno al sistema e descrive il contesto d'uso (Orientamenti Commissione, parr. 24–25). Non ricorre quando il software si limita a operazioni meccaniche prive di obiettivo interno: trasformazioni di formato, copie, conversioni di codifica.

Esempi di sistemi che rientrano nell'elemento:

• Classificatore addestrato a minimizzare l'errore su un set etichettato (funzione di perdita esplicita).
• Sistema di raccomandazione che, anche in assenza di una dichiarazione formale, ottimizza implicitamente metriche di engagement degli utenti.
• Assistente conversazionale al cittadino il cui obiettivo interno è massimizzare l'accuratezza delle risposte rispetto alle FAQ ufficiali della PA.
• Sistema di rilevazione anomalie sull'illuminazione pubblica il cui obiettivo è minimizzare i falsi negativi su un insieme ridotto di pattern di guasto noti.
• Modello per la previsione della struttura terziaria di proteine, addestrato a minimizzare l'errore rispetto a strutture risolte sperimentalmente.
• Modello di triage clinico il cui obiettivo interno è massimizzare la sensibilità nella rilevazione di casi a rischio.

Esempi di sistemi che non vi rientrano:

• Convertitore di file CSV in JSON senza alcuna valutazione interna.
• Funzione di hashing crittografico.
• Compressore lossless che applica una trasformazione deterministica priva di obiettivo proprio nel senso dell'AI Act.
• Job di backup pianificato che copia i dati su un'altra unità.
• Integratore numerico di equazioni differenziali ordinarie (es. metodo di Runge–Kutta) che applica una formula di quadratura senza obiettivo proprio.
• Codice di calcolo che risolve un sistema lineare con un metodo diretto (es. fattorizzazione LU): esegue una procedura matematica senza obiettivo interno autonomo.

Elemento 5 — Inferenza dall'input

Domanda guida. Il software deriva i propri output dagli input attraverso un processo inferenziale, ossia un ragionamento che porta a conclusioni a partire da premesse note (fatti, regole, modelli, feature, dati grezzi), andando oltre la mera esecuzione di regole esplicitamente codificate?

Criterio di ricorrenza. L'elemento ricorre quando l'output è prodotto da tecniche di machine learning (supervisionato, non supervisionato, auto-supervisionato, per rinforzo) oppure da approcci logico-simbolici dotati di motore di inferenza che derivi conclusioni non specificate puntualmente (Orientamenti Commissione, parr. 26–28; ISO/IEC 22989, 3.1.17). Non ricorre quando le regole sono interamente codificate da persone fisiche e applicate in modo deterministico, né nei casi di mera ottimizzazione matematica che migliora l'efficienza di metodi consolidati senza apprendimento. L'elemento è centrale: la sua assenza esclude di norma la qualificazione come IA. Non costituiscono inferenza neppure le interrogazioni su banche dati, i filtri o le macro di fogli di calcolo, per quanto complessi, i cui risultati sono determinati da criteri interamente impostati dall'operatore.

Esempi di sistemi che rientrano nell'elemento:

• Rete neurale convoluzionale che, dalle immagini delle telecamere del GDU, classifica i veicoli per categoria.
• Sistema esperto con motore di inferenza che applica regole logiche per supportare una diagnosi infrastrutturale.
• Albero di decisione addestrato su dati storici di consumo elettrico per stimare il fabbisogno energetico di un quartiere.
• Modello transformer (LLM) che genera risposte testuali in linguaggio naturale a partire dalla domanda dell'utente.
• Modello bayesiano che inferisce la probabilità di guasto di un componente partendo dai dati telemetrici.
• Rete profonda per l'identificazione di particelle in esperimenti di fisica delle alte energie a partire dai dati dei rivelatori.
• Modello transformer per la predizione di proprietà chimiche o biologiche di nuove molecole nel drug discovery.
• Modello generativo che propone candidati di sintesi retrosintetica in chimica organica.

Esempi di sistemi che non vi rientrano:

• Workflow if-then-else interamente scritto a mano dal progettista, in cui ogni condizione e azione è specificata puntualmente.
• Algoritmo di ordinamento (es. quicksort) o di ricerca su grafo (es. Dijkstra) usato in via deterministica, senza componente di apprendimento.
• Risolutore di programmazione lineare che migliora l'efficienza computazionale di un problema di ottimizzazione consolidato.
• Modello di previsione semplice (es. media mobile delle temperature) usato come benchmark statistico.
• Sistema di gestione database che applica filtri o aggregazioni su criteri esplicitamente impostati.
• Trasformata di Fourier veloce (FFT) applicata a un segnale sperimentale per il passaggio al dominio delle frequenze.
• Filtro di Kalman lineare per il tracking di traiettorie a partire da un modello dinamico specificato a priori dal progettista.

Elemento 6 — Output: previsioni, contenuti, raccomandazioni o decisioni

Domanda guida. Il software produce almeno una delle quattro categorie di output indicate dall'AI Act: previsioni (stime di valori sconosciuti), contenuti (materiali generati ex novo), raccomandazioni (suggerimenti) o decisioni (scelte assunte autonomamente)?

Criterio di ricorrenza. L'elemento ricorre quando l'output ricade in almeno una delle quattro categorie, indipendentemente dal grado di azione che ne consegue (Orientamenti Commissione, parr. 54–57). La nozione di previsione comprende anche risultati non riferiti al futuro: classificazioni, traduzioni, diagnosi di eventi passati (cfr. ISO/IEC 22989, 3.1.27). Non ricorre quando l'output è una mera rappresentazione descrittiva o visualizzazione di dati senza alcuna valutazione del sistema.

Esempi di sistemi che rientrano nell'elemento:

• Previsione della congestione di un'area urbana per le prossime sei ore a partire da serie storiche e dati in tempo reale.
• Generazione automatica di descrizioni testuali a corredo di immagini satellitari per la documentazione di interventi PA.
• Lista ordinata di interventi di manutenzione stradale prioritari, prodotta come raccomandazione all'ufficio competente.
• Decisione automatica di prolungamento del verde semaforico in funzione del flusso veicolare rilevato in tempo reale.
• Previsione della tossicità di un composto chimico a partire dalla sua struttura molecolare (previsione).
• Raccomandazione di candidati farmacologici prioritari da sintetizzare e testare in laboratorio.

Esempi di sistemi che non vi rientrano:

• Dashboard che visualizza le serie storiche di consumo idrico senza derivare valutazioni o suggerimenti.
• Esportazione di un report PDF contenente esclusivamente tabelle e grafici di dati grezzi.
• Tabella restituita da una query SQL, presentata all'operatore senza alcuna elaborazione valutativa.
• Funzione di anonimizzazione che si limita a pseudonimizzare i campi di un dataset.
• Visualizzazione di un diagramma di Hertzsprung–Russell calcolato da un catalogo stellare, senza valutazioni associate.
• Tabella dei parametri ricavati da un fit non lineare (es. coefficienti di un modello cinetico) presentata al ricercatore senza derivare alcuna raccomandazione o decisione.

Elemento 7 — Influenza su ambienti fisici o virtuali

Domanda guida. Gli output del software incidono concretamente su entità fisiche (oggetti, persone, infrastrutture) o virtuali (sistemi informativi, processi, decisioni)?

Criterio di ricorrenza. L'elemento ricorre quando gli output del sistema sono destinati ad essere consumati, esposti o eseguiti in un ambiente, producendo effetti tangibili o digitali (Orientamenti Commissione, par. 9 e considerando 12 AI Act). Non ricorre quando l'output rimane puramente interno al sistema, non viene esposto né consumato e non produce alcuna ricaduta. La nozione di influenza è ampia e include sia l'azione su oggetti fisici (attuatori, veicoli, infrastrutture) sia quella su ambienti digitali (modifica di informazioni, alimentazione di altri processi, condizionamento di scelte di utenti o operatori).

Esempi di sistemi che rientrano nell'elemento:

• Comando automatico a un attuatore stradale (apertura o chiusura di una sbarra, attivazione di un semaforo).
• Aggiornamento di un database operativo che governa l'erogazione di servizi pubblici (es. coda di prenotazioni).
• Modifica della prioritizzazione di chiamate a un call center comunale sulla base di una stima del rischio.
• Notifica al cittadino di una classificazione del proprio fascicolo (anche se la decisione finale è poi presa da un funzionario).
• Alimentazione di un sistema a valle (es. cruscotto di monitoraggio) che innesca azioni di altri uffici.
• Triage automatico di esami radiologici che riordina la coda di lettura del radiologo sulla base della probabilità di reperto.
• Comando a un microscopio robotico per acquisire ulteriori frame su una regione di interesse individuata dal sistema.

Esempi di sistemi che non vi rientrano:

• Risultato calcolato in un ambiente di test interno e mai esposto, persistito o consumato.
• Output scritto su un file di log temporaneo che non viene letto da alcun processo né da operatori.
• Esito di un benchmark eseguito sul modello in fase di valutazione prima del rilascio.
• Esito di una simulazione esplorativa archiviato, mai pubblicato né utilizzato per ulteriori elaborazioni o decisioni.

Regola di lettura della checklist

La verifica della ricorrenza dei sette elementi va condotta lungo entrambe le fasi del ciclo di vita del sistema, individuate dagli Orientamenti della Commissione (par. 9) nella fase precedente alla diffusione, o «di costruzione» del sistema, e in quella successiva alla diffusione, o «di uso». Sempre gli Orientamenti chiariscono che «non è necessario che i sette elementi indicati in tale definizione siano presenti in modo continuativo in entrambe le fasi di tale ciclo di vita»: la definizione riconosce «la possibilità che alcuni elementi specifici appaiano in una fase, ma non persistano in entrambe le fasi». In particolare, l'adattabilità (elemento 3) è tipica della sola fase di uso, mentre l'inferenza (elemento 5) può manifestarsi sia nella derivazione di modelli o algoritmi dai dati durante la costruzione, sia nella generazione di output sulla base degli input durante l'uso (Orientamenti, par. 28).

Fra i sette elementi assumono carattere necessario il sistema automatizzato (elemento 1), un grado anche minimo di autonomia (elemento 2), gli obiettivi, espliciti o impliciti (elemento 4), e la capacità di inferire (elemento 5): in loro assenza non si è in presenza di un sistema di IA ai sensi dell'AI Act. La capacità di inferenza non va intesa in senso restrittivo: il considerando 12 del Regolamento (UE) 2024/1689 specifica che «le tecniche che consentono l'inferenza nella costruzione di un sistema di IA comprendono approcci di apprendimento automatico che imparano dai dati come conseguire determinati obiettivi e approcci basati sulla logica e sulla conoscenza che traggono inferenze dalla conoscenza codificata o dalla rappresentazione simbolica». La nozione è coerente con ISO/IEC 22989:2022, 3.1.17, che definisce l'inferenza come «ragionamento mediante il quale si traggono conclusioni da premesse note», precisando che, in ambito IA, una premessa è «un fatto, una regola, un modello, una caratteristica oppure dati grezzi» (Orientamenti Commissione, par. 27).

Gli Orientamenti qualificano come condizione necessaria anche l'autonomia (2): «il livello di autonomia è una condizione necessaria per determinare se un sistema possa essere considerato un sistema di IA» (par. 20). La soglia è però bassa e strettamente legata all'inferenza, con cui «va di pari passo» (par. 15), bastando «un certo grado di indipendenza di azione dal coinvolgimento umano» (considerando 12 AI Act): in pratica, un sistema che inferisce dispone già del minimo di autonomia richiesto. In particolare, l'autonomia non è esclusa dalla presenza di intervento umano: il coinvolgimento umano può essere «diretto […] o indiretto, ad esempio attraverso controlli […] che consentono agli esseri umani di delegare o supervisionare» (par. 17), e «un sistema che richiede input manuali per generare un output […] è un sistema con un certo grado di autonomia», come pure il sistema che, su input umani, «produce da solo una raccomandazione» (par. 18). È esclusa solo l'esecuzione interamente manuale; la supervisione o la conferma umana sull'output non degradano la qualificazione, attenendo alla sorveglianza umana (art. 14 AI Act), che presuppone un sistema di IA. L'adattabilità (3) è invece facoltativa (parr. 22–23); gli obiettivi (4), espliciti o impliciti (parr. 24–25), sono necessari, perché la definizione li richiede senza alternative. Gli elementi 6 (output del tipo previsioni, contenuti, raccomandazioni, decisioni) e 7 (influenza su ambienti fisici o virtuali) qualificano l'effetto del sistema e perimetrano la categoria degli output rilevanti.

In sintesi, il software rientra nella definizione di sistema di IA quando ricorrono congiuntamente, almeno in una delle due fasi del ciclo di vita, gli elementi necessari 1 (sistema automatizzato), 2 (autonomia, a soglia minima), 4 (obiettivi espliciti o impliciti) e 5 (inferenza), con output riconducibile alle categorie indicate dall'elemento 6 e idoneo a incidere sull'ambiente fisico o virtuale (elemento 7); l'adattabilità (3) è facoltativa. Per converso, la sola esecuzione automatica di regole interamente fissate dal progettista, in assenza di un effettivo processo inferenziale, esclude la qualificazione come IA. In tale ipotesi il software ricade nella nozione di algoritmo deterministico: il Consiglio di Stato (Sez. III, sent. n. 7891/2021) ha espressamente chiarito che l'intelligenza artificiale ricorre quando «l'algoritmo contempla meccanismi di machine learning e crea un sistema che non si limita solo ad applicare le regole software e i parametri preimpostati (come fa invece l'algoritmo tradizionale) ma, al contrario, elabora costantemente nuovi criteri di inferenza tra dati e assume decisioni efficienti sulla base di tali elaborazioni, secondo un processo di apprendimento automatico». Si rinvia al § 5.1.7 per l'approfondimento. Qualificato il software come sistema di IA, i passi successivi — individuazione del proprio ruolo (fornitore o deployer), verifica delle esclusioni dell'art. 2 (in particolare ricerca e sviluppo, parr. 6 e 8), classificazione del rischio (artt. 5 e 6) e obblighi di trasparenza (art. 50) — sono trattati nel seguito di questa sezione.

5.1.5 Casi che non rientrano nella definizione

Il considerando 12 dell'AI Act precisa che la definizione deve distinguere i sistemi di IA dai «tradizionali sistemi software o dagli approcci di programmazione più semplici» e non riguarda i sistemi basati su regole definite unicamente da persone fisiche. Gli Orientamenti della Commissione (sez. 5.2, parr. 40–51) elencano le categorie che, pur potendo in qualche caso inferire in modo ristretto, restano fuori dalla nozione per la limitata capacità di analizzare modelli e adeguare autonomamente l'output. L'esclusione non è automatica: va verificata caso per caso applicando la checklist del § 5.1.4.

• Sistemi basati su regole definite unicamente da persone fisiche: eseguono operazioni in modo automatico applicando regole fissate dall'uomo, senza apprendimento, ragionamento o modellizzazione autonomi (considerando 12 AI Act; Orientamenti, par. 40). È il caso dell'algoritmo deterministico approfondito al § 5.1.7.
• Sistemi per migliorare l'ottimizzazione matematica: accelerano o approssimano metodi di ottimizzazione consolidati (es. regressione lineare o logistica): pur avendo capacità inferenziale, non trascendono «l'elaborazione di base dei dati» e mirano all'efficienza computazionale, non a decisioni che si adattano in modo intelligente (Orientamenti, parr. 42–45).
• Sistemi di elaborazione di base dei dati: seguono istruzioni predefinite ed esplicite, senza tecniche di IA (es. gestione di banche dati per filtrare record, fogli elettronici senza funzionalità IA) (Orientamenti, par. 46).
• Sistemi per analisi descrittiva, test di ipotesi e visualizzazione: sintetizzano e rappresentano i dati con metodi statistici (es. cruscotti di vendita, test di significatività) ma non «apprendono, ragionano o modellizzano» né raccomandano azioni (Orientamenti, par. 47).
• Sistemi basati sull'euristica classica: applicano regole o algoritmi predefiniti per soluzioni approssimate (es. minimax con valutazione euristica negli scacchi), senza apprendere dai dati (Orientamenti, par. 48).
• Sistemi di previsione semplici: le cui prestazioni si ottengono con una regola statistica elementare di base (es. previsione pari alla media storica), anche se tecnicamente basati su ML, sono esclusi per le prestazioni limitate; servono tipicamente come benchmark (Orientamenti, parr. 49–51).

Diversi di questi casi sono ripresi, con la compilazione esplicita della checklist, fra gli esempi del § 5.1.8 (in particolare i casi limite di ML); l'approfondimento sull'algoritmo deterministico è al § 5.1.7.

5.1.6 Vocabolario tecnico — voci essenziali da ISO/IEC 22989:2022

Le voci che seguono, tratte dalla clausola 3 della norma ISO/IEC 22989:2022 (Information technology — Artificial intelligence — Artificial intelligence concepts and terminology), costituiscono il ponte fra la definizione normativa e il piano implementativo del sistema. Si raccomanda l'uso coerente di questi termini nella documentazione tecnica.

La tabella seguente raccorda i sette elementi della definizione (art. 3, punto 1, AI Act) alle voci della ISO/IEC 22989:2022. Dove la norma ISO non offre una voce dedicata, l'elemento è precisato dagli Orientamenti della Commissione (i numeri rinviano ai paragrafi degli Orientamenti). Le definizioni ISO complete sono riportate subito dopo.

Tabella di raccordo — per ciascun elemento della definizione, la voce ISO/IEC 22989 corrispondente; dove la ISO non offre una voce dedicata, il riferimento è agli Orientamenti della Commissione.

Sistema di IA (AI system) — 3.1.4. Sistema ingegnerizzato che genera output quali contenuti, previsioni, raccomandazioni o decisioni a fronte di un insieme di obiettivi definiti dall'uomo. Per realizzarli può utilizzare tecniche e approcci diversi per costruire un modello che rappresenti dati, conoscenza e processi.

Inferenza (inference) — 3.1.17. Ragionamento mediante il quale si traggono conclusioni da premesse note; in ambito IA la premessa è un fatto, una regola, un modello, una feature o un dato grezzo. Il termine designa sia il processo sia il suo risultato.

Modello (model) — 3.1.23. Rappresentazione fisica, matematica o comunque logica di un sistema, di un'entità, di un fenomeno, di un processo o di dati. Nei sistemi di apprendimento, è il costrutto che, dopo l'addestramento, produce inferenze o previsioni a partire dai dati di input.

Autonomia (autonomy) — 3.1.5. Caratteristica di un sistema capace di modificare il proprio dominio d'uso o il proprio obiettivo senza intervento, controllo o supervisione esterni. Si distingue dalla mera automazione (3.1.7), che indica il funzionamento senza intervento umano in condizioni specificate.

Apprendimento automatico (machine learning, ML) — 3.3.5. Processo di ottimizzazione dei parametri di un modello tramite tecniche computazionali, in modo che il comportamento del modello rifletta dati o esperienza. Si declina in supervisionato (3.3.13), non supervisionato (3.3.18), semi-supervisionato (3.3.12) e per rinforzo (3.3.10).

Dati di addestramento (training data) — 3.3.17. Dati utilizzati per addestrare un modello di machine learning. La loro qualità, copertura e correttezza incidono direttamente sulla rappresentatività e sull'affidabilità del modello risultante.

IA simbolica e sub-simbolica (symbolic / subsymbolic AI) — 3.1.33, 3.1.34. L'IA simbolica si fonda su manipolazione di simboli secondo regole esplicite (output dichiarativi); l'IA sub-simbolica utilizza una codifica implicita derivata da dati o esperienza (output con probabilità d'errore). La distinzione è utile per argomentare la presenza dell'elemento 5 della definizione (inferenza).

Predizione (prediction) — 3.1.27. Output primario di un sistema di IA a fronte di dati di input. Non implica necessariamente un riferimento al futuro: comprende classificazione, traduzione, generazione, diagnosi di eventi passati.

5.1.7 Approfondimento: l'algoritmo deterministico (quando non si è in presenza di IA)

Se la verifica al § 5.1.4 esclude la qualificazione del software come sistema di IA, il software ricade tipicamente nella categoria dell'algoritmo deterministico. La giurisprudenza amministrativa lo ha definito (Cons. Stato, Sez. VI, sent. n. 2270/2019; cfr. anche TAR Campania, Napoli, Sez. VII, 14 novembre 2022, n. 7003) come «una sequenza finita e ordinata di operazioni elementari e chiare di calcolo che permettono di risolvere, in maniera determinata, un problema».

L'algoritmo deterministico è caratterizzato dalle seguenti proprietà:

• Finitezza: porta alla soluzione in un numero finito di passi;
• Generalità: risolve una classe di problemi e non un singolo problema isolato;
• Non ambiguità: le istruzioni sono specificate univocamente: l'esecuzione avviene sempre nello stesso modo, indipendentemente dall'esecutore;
• Ripetibilità (determinismo): a parità di input l'algoritmo fornisce sempre lo stesso output.

Differenza con il sistema di IA

Il Consiglio di Stato (Sez. III, sent. n. 7891/2021) ha chiarito che l'algoritmo, anche quando applicato a sistemi tecnologici, resta una «sequenza finita di istruzioni, ben definite e non ambigue»; l'intelligenza artificiale ricorre invece quando «l'algoritmo contempla meccanismi di machine learning e crea un sistema che non si limita solo ad applicare le regole software e i parametri preimpostati (come fa invece l'algoritmo tradizionale) ma, al contrario, elabora costantemente nuovi criteri di inferenza tra dati e assume decisioni efficienti sulla base di tali elaborazioni, secondo un processo di apprendimento automatico».

In termini operativi, la differenza si traduce nell'elemento 5 della checklist: l'algoritmo deterministico non inferisce, ma applica regole fissate manualmente; il sistema di IA inferisce, anche quando le regole sono codificate (purché vi sia un motore di inferenza che derivi conclusioni non specificate puntualmente).

Stesso algoritmo, due usi. La distinzione non riguarda lo strumento matematico in sé, ma l'uso che se ne fa. Una regressione o una rete neurale, anche di pochi neuroni, possono servire a descrivere un insieme di dati già noto — stimare parametri, interpolare, verificare un'ipotesi — oppure ad apprendere dai dati una funzione destinata a produrre output corretti su input mai osservati, secondo la pratica dell'apprendimento automatico (separazione fra dati di addestramento, validazione e test; misura dell'errore su dati non visti). Solo nel secondo caso il sistema «deduce dall'input come generare output» nel senso dell'elemento 5: gli Orientamenti descrivono l'apprendimento come l'acquisizione di una mappatura dagli input agli output «generalizzandola successivamente per dati nuovi e non visibili» (par. 33). Il primo uso ricade invece fra i casi esclusi del § 5.1.5 (ottimizzazione matematica, analisi descrittiva e test di ipotesi). Gli esempi 5 e 11 del § 5.1.8 illustrano il primo uso, gli esempi 2 e 12 il secondo. Il criterio è un ausilio pratico e non sostituisce le esclusioni degli Orientamenti: un modello che generalizza può comunque restare fuori dalla definizione se serve soltanto ad accelerare metodi consolidati (esempio 4; parr. 42–45).

Implicazioni per la Pubblica Amministrazione

La qualificazione come algoritmo deterministico esclude l'applicazione dell'AI Act, ma non i principi che la giurisprudenza amministrativa applica all'uso di procedure automatizzate da parte della PA (cfr. Cons. Stato, Sez. VI, sentt. n. 2270/2019 e nn. 8472–8474/2019; Sez. III, n. 7891/2021): conoscibilità della regola tecnica, trasparenza rafforzata (la «formula tecnica» deve essere corredata da spiegazioni che la traducano nella regola giuridica sottesa), individuazione del responsabile del procedimento, obbligo di motivazione, garanzie partecipative, non esclusività della decisione algoritmica (presenza di un controllo umano significativo nel circuito decisionale). Si rinvia alla sezione 7 (parr. 7.3, 7.4.1.2 e 7.4.2).

5.1.8 Esempi generali di applicazione della checklist

Si illustra di seguito la compilazione della checklist per dodici casi di studio, scelti in modo da coprire le quattro situazioni rilevanti per la qualificazione: sistemi di IA pienamente soggetti all'AI Act, sistemi di IA esonerati ai sensi dell'art. 2, par. 6 (ricerca scientifica), algoritmi deterministici ai sensi del § 5.1.7 e software che, pur impiegando tecniche di machine learning indicate dalla norma ISO/IEC 22989:2022, clausole 3.3 e 3.4, ricadono fra i casi limite espressamente esclusi dagli Orientamenti della Commissione (sez. 5.2). Per ciascun esempio si riporta la risposta agli elementi 1–7 della checklist e la conseguente motivazione dell'esito ai sensi della Regola di lettura.

Esempio 1 — Classificatore di immagini istopatologiche con fine-tuning continuo

Descrizione. Sistema impiegato in un'azienda ospedaliera: una rete neurale convoluzionale, eseguita su workstation con GPU, classifica le immagini di biopsie istologiche in categorie diagnostiche (es. tessuto normale, lesione benigna, lesione sospetta) e fornisce al patologo una probabilità associata a ciascuna classe. I pesi del modello sono soggetti a fine-tuning periodico automatico sui nuovi casi etichettati.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Il software è eseguito da macchina (workstation con GPU) su input digitali provenienti dallo scanner istologico.
• Elemento 2 (autonomia variabile) — SÌ. Per ciascuna immagine il sistema produce la classificazione senza intervento dell'operatore sul singolo caso.
• Elemento 3 (adattabilità dopo la diffusione) — SÌ. I parametri del modello sono aggiornati in esercizio tramite fine-tuning sui nuovi casi etichettati.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivo esplicito: minimizzare l'errore di classificazione rispetto al gold standard prodotto dal patologo.
• Elemento 5 (inferenza dall'input) — SÌ. L'output è ottenuto per inferenza tramite rete neurale (ISO/IEC 22989, cl. 3.4) addestrata in modalità supervisionata (3.3.13).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Genera una previsione (classe) e una raccomandazione implicita di priorità di refertazione.
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. L'output alimenta la cartella clinica del paziente e incide sul percorso diagnostico-terapeutico.

Esito: sistema di IA. Ricorrono congiuntamente gli elementi necessari (1, 2, 4 e 5) nonché gli elementi 3, 6 e 7. Trattandosi di un impiego in ambito sanitario, si rinvia inoltre, per la valutazione del rischio (art. 6, par. 1, e allegato I dell'AI Act – dispositivi medici), al riquadro «Valuta se il tuo sistema è intelligenza artificiale ad alto rischio» in questa sezione. Per gli sviluppi confinati all'ambito di ricerca può applicarsi l'esclusione dell'art. 2, parr. 6 e 8, dell'AI Act (riquadro «Sei un ente pubblico di ricerca o un'università che sviluppa software per il GDU…»).

Esempio 2 — Previsore della congestione viaria del Gemello Digitale Urbano

Descrizione. Modulo del GDU che, a partire dai dati di sensori spire e telecamere, prevede la congestione di un'area urbana per le prossime sei ore mediante un modello sequenziale (rete ricorrente o transformer) e ne restituisce l'esito al sistema di gestione semaforica. I parametri del modello sono congelati al rilascio e aggiornati solo offline tramite rilascio di una nuova versione.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Il modulo gira su un'infrastruttura server del GDU e consuma flussi di dati di sensori e telecamere.
• Elemento 2 (autonomia variabile) — SÌ. Produce le previsioni periodiche senza alcun intervento umano puntuale.
• Elemento 3 (adattabilità dopo la diffusione) — NO. I pesi del modello sono congelati al rilascio; l'aggiornamento avviene unicamente con una nuova release. L'elemento non è obbligatorio per la qualificazione.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivo esplicito: minimizzare l'errore di previsione sulla serie storica di addestramento.
• Elemento 5 (inferenza dall'input) — SÌ. L'output deriva da un processo inferenziale di apprendimento automatico (ISO/IEC 22989, 3.3.5; rete neurale, cl. 3.4).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Output di tipo previsione e raccomandazione (priorità di intervento sui semafori).
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. L'output condiziona la gestione semaforica reale dell'area e quindi la mobilità urbana.

Esito: sistema di IA. Ricorrono gli elementi necessari (1, 2, 4 e 5) e gli elementi 6 e 7; l'assenza dell'elemento 3 (facoltativo) non è ostativa (Orientamenti della Commissione, parr. 9 e 22–23; v. Regola di lettura).

Esempio 3 — Workflow per la valutazione automatica di una pratica amministrativa

Descrizione. Software della PA che valuta l'ammissibilità di una pratica (es. concessione di un'agevolazione) sulla base di un albero decisionale interamente codificato dal progettista: ogni condizione, soglia ed esito è specificato in modo esplicito in regole if-then-else e nei parametri di configurazione. Il sistema non utilizza modelli addestrati su dati.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Il software è eseguito da un'infrastruttura applicativa della PA.
• Elemento 2 (autonomia variabile) — SÌ. Per ogni pratica produce automaticamente l'esito senza intervento umano sul singolo caso.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Le regole e le soglie sono congelate e modificabili solo con una nuova release del software.
• Elemento 4 (obiettivi espliciti o impliciti) — NO. Il sistema applica regole esplicite, senza un obiettivo interno proprio nel senso dell'AI Act.
• Elemento 5 (inferenza dall'input) — NO. Manca un effettivo processo inferenziale: le regole sono interamente codificate dalla persona fisica del progettista (Orientamenti della Commissione, par. 40).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Produce una decisione (ammissione o rigetto).
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. La decisione incide direttamente sulla posizione amministrativa del cittadino.

Esito: software non qualificabile come IA. Mancano gli elementi 4 e 5, necessari insieme agli elementi 1 e 2 per la qualificazione ai sensi dell'AI Act. Il software ricade nella nozione di algoritmo deterministico (§ 5.1.7); restano applicabili i principi della giurisprudenza amministrativa (trasparenza rafforzata, conoscibilità, non esclusività della decisione: Cons. Stato n. 2270/2019 e n. 8472/2019).

Esempio 4 — Modello surrogato a rete neurale per simulazioni di fluidodinamica computazionale

Descrizione. Un gruppo di ricerca addestra una rete neurale feed-forward (ISO/IEC 22989, cl. 3.4) a riprodurre l'output di un solutore tradizionale delle equazioni di Navier–Stokes su un dominio aerodinamico, allo scopo di ridurre di due ordini di grandezza il tempo di calcolo. Il modello è poi usato come componente accelerato all'interno della stessa pipeline di simulazione fisica.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Il modello è eseguito su cluster HPC.
• Elemento 2 (autonomia variabile) — SÌ. Produce i valori previsti senza intervento per ciascuna valutazione.
• Elemento 3 (adattabilità dopo la diffusione) — NO. I pesi sono congelati dopo l'addestramento.
• Elemento 4 (obiettivi espliciti o impliciti) — PARZIALE. L'obiettivo interno è la minimizzazione di una funzione di perdita rispetto al solutore di riferimento; tuttavia la finalità del sistema è esclusivamente l'efficienza computazionale del calcolo fisico.
• Elemento 5 (inferenza dall'input) — SÌ (formalmente). Si tratta a tutti gli effetti di apprendimento automatico (ISO/IEC 22989, 3.3.5) attuato tramite rete neurale (cl. 3.4).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Output numerico assimilabile a una previsione.
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ (mediato). L'output è consumato dal solutore fisico a valle.

Esito: software non qualificabile come IA (caso limite ML). Pur ricorrendo formalmente l'elemento 5 (inferenza tramite ML), il sistema rientra fra le esclusioni espresse degli Orientamenti della Commissione (parr. 42–43): «i sistemi basati sulla fisica [che] possono utilizzare tecniche di apprendimento automatico per migliorare le prestazioni computazionali, accelerando le simulazioni tradizionali basate sulla fisica o stimando parametri, che vengono poi immessi nei modelli fisici consolidati». Il modello «non trascende l'elaborazione di base dei dati»: l'esclusione va documentata nel fascicolo tecnico.

Esempio 5 — Regressione lineare per stima di un'associazione in uno studio epidemiologico

Descrizione. In uno studio osservazionale viene stimata, mediante regressione lineare multipla (machine learning algorithm, ISO/IEC 22989, 3.3.6), l'associazione fra esposizione a un fattore di rischio e un indicatore biomedico, controllando per fattori confondenti. L'output è il vettore dei coefficienti di regressione con relativi intervalli di confidenza, presentato al ricercatore.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. L'analisi è eseguita in un ambiente software statistico (R, Stata, Python).
• Elemento 2 (autonomia variabile) — NO. Il ricercatore conduce e supervisiona l'analisi a ogni passaggio.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Nessun meccanismo di aggiornamento dei coefficienti dopo la stima.
• Elemento 4 (obiettivi espliciti o impliciti) — NO. L'obiettivo è puramente statistico-descrittivo (criterio dei minimi quadrati), non un obiettivo del sistema nel senso dell'AI Act.
• Elemento 5 (inferenza dall'input) — SÌ (formalmente). La regressione lineare è classificata come machine learning algorithm (ISO/IEC 22989, 3.3.6).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — NO. L'output non è una previsione, raccomandazione o decisione operativa, ma una statistica descrittiva.
• Elemento 7 (influenza su ambienti fisici o virtuali) — NO. L'output è destinato all'analisi del ricercatore, non a incidere su un ambiente fisico o virtuale.

Esito: software non qualificabile come IA (caso limite ML). Pur impiegando una tecnica formalmente di machine learning, il caso ricade in una doppia esclusione degli Orientamenti: par. 42 («i sistemi utilizzati per migliorare l'ottimizzazione matematica o per accelerare e approssimare metodi di ottimizzazione tradizionali e consolidati, quali i metodi di regressione lineare o logistica» non rientrano nella definizione) e par. 47 (analisi descrittiva, test di ipotesi e visualizzazione). Manca inoltre l’elemento 4 (obiettivi), necessario per la qualificazione.

Esempio 6 — Analisi delle componenti principali (PCA) su dati genomici per visualizzazione esplorativa

Descrizione. Su un set di profili di espressione genica si applica l'analisi delle componenti principali (unsupervised machine learning, ISO/IEC 22989, 3.3.18) per ottenere una rappresentazione bidimensionale dei campioni, utile a individuare visivamente cluster di pazienti. L'output è uno scatterplot consegnato al ricercatore.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. L'elaborazione è eseguita in un ambiente software bioinformatico.
• Elemento 2 (autonomia variabile) — NO. Il ricercatore imposta i parametri (numero di componenti, pre-processing) e interpreta la rappresentazione.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Nessun aggiornamento dei parametri della trasformazione dopo l'esecuzione.
• Elemento 4 (obiettivi espliciti o impliciti) — NO. Nessun obiettivo del sistema nel senso dell'AI Act: la PCA minimizza una funzione obiettivo statistica orientata alla varianza spiegata, ad esclusivi fini esplorativi.
• Elemento 5 (inferenza dall'input) — SÌ (formalmente). La PCA rientra nell'apprendimento non supervisionato (ISO/IEC 22989, 3.3.18).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — NO. L'output è una rappresentazione grafica esplorativa, non una previsione, raccomandazione o decisione.
• Elemento 7 (influenza su ambienti fisici o virtuali) — NO. Nessuna ricaduta operativa diretta su un ambiente: la visualizzazione è di supporto interpretativo.

Esito: software non qualificabile come IA (caso limite ML). Pur impiegando una tecnica di unsupervised machine learning, il sistema ricade nell'esclusione espressa dalla sez. 5.2 degli Orientamenti della Commissione e in particolare dal par. 47: «i sistemi destinati esclusivamente all'analisi descrittiva, al test di ipotesi e alla visualizzazione non rientrano nella definizione di sistema di IA». Mancano peraltro gli elementi 4, 6 e 7 della checklist.

Esempio 7 — Sistema esperto simbolico per il supporto alla diagnosi di dissesti strutturali

Descrizione. Sistema impiegato nell'ufficio tecnico di un ente locale: una base di conoscenza codificata da ingegneri strutturisti (regole, fatti, ontologia di lesioni e quadri fessurativi) è interrogata da un motore di inferenza che, a fronte di un rilievo dell'edificio inserito dall'operatore, restituisce una rosa ordinata di ipotesi diagnostiche con il corrispondente percorso di deduzione. Si tratta di IA simbolica (ISO/IEC 22989, 3.1.33; expert system, 3.1.13), senza alcuna componente di machine learning.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Il sistema esperto è eseguito su un server applicativo dell'ente.
• Elemento 2 (autonomia variabile) — SÌ. L'output è derivato automaticamente dal motore di inferenza, senza supervisione puntuale sull'esito.
• Elemento 3 (adattabilità dopo la diffusione) — NO. La base di conoscenza è statica e aggiornata solo per interventi manuali dei curatori del dominio.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivo interno: individuare l'insieme di ipotesi più coerenti con i fatti osservati secondo le regole della base di conoscenza.
• Elemento 5 (inferenza dall'input) — SÌ. Il considerando 12 dell'AI Act e il par. 30 degli Orientamenti includono espressamente fra le tecniche di inferenza gli «approcci basati sulla logica e sulla conoscenza che traggono inferenze dalla conoscenza codificata o dalla rappresentazione simbolica».
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Output del tipo raccomandazione (ipotesi diagnostiche ordinate per plausibilità).
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. L'output orienta le ispezioni successive e gli interventi di consolidamento.

Esito: sistema di IA. Ricorrono gli elementi necessari (1, 2, 4 e 5) e gli elementi 6 e 7 (assente solo l'adattabilità, facoltativa). Il caso evidenzia che la qualificazione come IA non richiede l'impiego di machine learning: anche l'IA simbolica rientra nell'ambito dell'AI Act, in coerenza con il considerando 12 dell'AI Act e con la definizione ISO/IEC 22989 di inferenza (3.1.17).

Esempio 8 — Assistente conversazionale al cittadino basato su un Large Language Model

Descrizione. Servizio del Comune che mette a disposizione del cittadino, tramite un'interfaccia web, un modello linguistico di grandi dimensioni (transformer, ISO/IEC 22989, cl. 3.4; sub-symbolic AI, 3.1.34) con architettura di retrieval-augmented generation su delibere, regolamenti e modulistica comunali. Il sistema produce risposte in linguaggio naturale e indica i riferimenti agli atti pertinenti.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Servizio cloud che esegue il modello su GPU dedicate.
• Elemento 2 (autonomia variabile) — SÌ. Per ciascuna richiesta produce in autonomia la risposta.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Il modello di base è congelato; gli aggiornamenti (es. fine-tuning periodico) avvengono offline con nuove release.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivo del sistema: massimizzare l'aderenza della risposta alle fonti normative reperite, minimizzando le fabbricazioni.
• Elemento 5 (inferenza dall'input) — SÌ. Il modello è una rete neurale profonda addestrata in modalità auto-supervisionata su grandi corpora di testo.
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Output del tipo contenuto (testo generato) e raccomandazione (suggerimento di procedure o uffici).
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. L'output orienta le scelte del cittadino in merito ai servizi della PA.

Esito: sistema di IA. Ricorrono gli elementi necessari (1, 2, 4 e 5) e gli elementi 6 e 7. Trattandosi di un sistema che interagisce direttamente con persone fisiche e che genera contenuti sintetici, si applicano gli obblighi di trasparenza dell'art. 50 dell'AI Act (informazione dell'utente che sta interagendo con un sistema di IA; marcatura dei contenuti generati). Per la valutazione del rischio si rinvia al riquadro «Valuta se il tuo sistema è intelligenza artificiale ad alto rischio».

Esempio 9 — Calcolatore automatico dell'Indicatore della Situazione Economica Equivalente (ISEE)

Descrizione. Modulo della piattaforma INPS che, sulla base dei dati anagrafici e patrimoniali dichiarati dal cittadino e dei dati fiscali acquisiti dall'Agenzia delle Entrate, calcola l'indicatore ISEE applicando le formule e le scale di equivalenza stabilite dal DPCM 159/2013 e successive modificazioni. Il risultato è restituito al cittadino e consumato da altri sportelli digitali per la valutazione di ammissibilità a misure agevolative.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Esecuzione su infrastruttura applicativa INPS.
• Elemento 2 (autonomia variabile) — SÌ. Calcolo prodotto automaticamente, senza supervisione puntuale per ciascuna pratica.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Le formule sono fissate dalla normativa e aggiornate solo con nuovi atti normativi o release del software.
• Elemento 4 (obiettivi espliciti o impliciti) — NO. Il sistema applica integralmente regole normative, senza alcun obiettivo interno proprio.
• Elemento 5 (inferenza dall'input) — NO. Nessun processo inferenziale: l'output è il risultato deterministico delle formule normative.
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Output del tipo decisione (valore ISEE che condiziona soglie di accesso).
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. L'esito incide sull'accesso del cittadino a prestazioni sociali e fiscali agevolate.

Esito: software non qualificabile come IA. Mancano gli elementi 4 e 5: si tratta di applicazione automatica di regole normative interamente codificate, quindi di algoritmo deterministico (§ 5.1.7). Restano applicabili integralmente i principi della giurisprudenza amministrativa (Cons. Stato n. 2270/2019 e n. 8472/2019) in tema di trasparenza rafforzata, conoscibilità della regola tecnica (qui coincidente con la regola giuridica), motivazione e non esclusività della decisione.

Esempio 10 — Previsore meteorologico di base come benchmark (media settimanale)

Descrizione. All'interno di una valutazione comparativa di sistemi di previsione meteorologica, viene utilizzato un previsore elementare che stima la temperatura del giorno successivo come media della settimana precedente. La procedura è tecnicamente classificabile come machine learning algorithm (ISO/IEC 22989, 3.3.6) con un'ipotesi statistica banale, ed è impiegata esclusivamente come termine di confronto.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Esecuzione su ambiente di calcolo scientifico.
• Elemento 2 (autonomia variabile) — SÌ. Produce la previsione senza intervento puntuale.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Nessun aggiornamento dei parametri al di fuori della stima statica.
• Elemento 4 (obiettivi espliciti o impliciti) — PARZIALE. Obiettivo statistico ridotto: replicare l'ipotesi della media; manca un obiettivo del sistema nel senso pieno dell'AI Act.
• Elemento 5 (inferenza dall'input) — SÌ (formalmente). Inferenza minima da regola di apprendimento statistico di base.
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ (formalmente). Output del tipo previsione.
• Elemento 7 (influenza su ambienti fisici o virtuali) — NO. L'output è destinato a fungere da termine di confronto in una valutazione tecnica, non a incidere su un ambiente.

Esito: software non qualificabile come IA (caso limite ML). Il caso è espressamente escluso dagli Orientamenti, parr. 49–50: «tutti i sistemi automatizzati le cui prestazioni possono essere conseguite mediante una regola di apprendimento statistico di base, sebbene possano essere tecnicamente classificati come basati su approcci di apprendimento automatico, non rientrano nell'ambito di applicazione della definizione di sistema di IA, a causa delle loro prestazioni», con il riferimento specifico alla previsione della temperatura tramite la media settimanale.

Esempio 11 — Rete neurale feed-forward per l'approssimazione di funzioni speciali in libreria scientifica

Descrizione. All'interno di una libreria di calcolo scientifico, una rete neurale feed-forward (ISO/IEC 22989, cl. 3.4) è addestrata in modalità supervisionata (3.3.13) a riprodurre con buona accuratezza una funzione analitica nota — ad esempio una funzione di Bessel, un integrale ellittico o un kernel di integrazione gaussiana — per essere richiamata in luogo dell'implementazione classica al fine di ridurre il costo computazionale. L'output della rete è consumato come valore della funzione da altri moduli numerici.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. La rete è eseguita all'interno di un ambiente di calcolo numerico (workstation, cluster).
• Elemento 2 (autonomia variabile) — SÌ. Restituisce automaticamente il valore approssimato a ciascuna chiamata, senza supervisione puntuale.
• Elemento 3 (adattabilità dopo la diffusione) — NO. I pesi sono congelati al termine dell'addestramento.
• Elemento 4 (obiettivi espliciti o impliciti) — PARZIALE. L'obiettivo interno è puramente statistico (minimizzare l'errore di approssimazione rispetto alla funzione analitica di riferimento); la finalità d'uso è esclusivamente l'efficienza del calcolo.
• Elemento 5 (inferenza dall'input) — SÌ (formalmente). Si tratta di una rete neurale (ISO/IEC 22989, cl. 3.4) addestrata su dati: tecnicamente, apprendimento automatico nel senso di ISO/IEC 22989, 3.3.5.
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ (formalmente). Restituisce un valore numerico, formalmente assimilabile a una previsione, ma corrispondente al valore di una funzione analitica nota.
• Elemento 7 (influenza su ambienti fisici o virtuali) — NO. Non orienta decisioni e non incide su un ambiente: il valore restituito è funzionalmente intercambiabile con l'implementazione classica della stessa funzione, di cui costituisce un mero acceleratore.

Esito: software non qualificabile come IA (caso limite ML). Pur ricorrendo formalmente l'elemento 5, mancano l'elemento 7 e, in termini sostanziali, l'elemento 4: l'impiego della rete è esclusivamente strumentale alla velocità del calcolo, senza un processo decisionale o predittivo proprio. Il caso rientra fra le esclusioni del par. 42 degli Orientamenti della Commissione («i sistemi utilizzati per migliorare l'ottimizzazione matematica o per accelerare e approssimare metodi di ottimizzazione tradizionali e consolidati»), in quanto il modello «non trascende l'elaborazione di base dei dati»: l'esclusione va documentata nel fascicolo tecnico.

Esempio 12 — Rete neurale profonda per l'identificazione di particelle in esperimenti di fisica delle alte energie

Descrizione. Nell'ambito di un esperimento al CERN, una rete neurale profonda (deep learning, ISO/IEC 22989, cl. 3.4; supervised machine learning, 3.3.13) è addestrata a classificare gli eventi registrati dai rivelatori (es. discriminazione segnale-fondo) ai fini dell'analisi scientifica. Il modello è impiegato sui dati dell'esperimento e i risultati sono destinati alle pubblicazioni della collaborazione scientifica.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Esecuzione sul Worldwide LHC Computing Grid (cluster distribuiti, GPU).
• Elemento 2 (autonomia variabile) — SÌ. Classifica autonomamente miliardi di eventi senza supervisione puntuale sul singolo dato.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Modello congelato all'avvio della campagna di analisi.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivo esplicito: massimizzare l'accuratezza di classificazione segnale/fondo.
• Elemento 5 (inferenza dall'input) — SÌ. Inferenza pienamente nel senso dell'AI Act tramite rete neurale profonda.
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Output del tipo previsione (classe dell'evento) e dati derivati per l'analisi statistica.
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. L'output alimenta l'analisi statistica e quindi le pubblicazioni della collaborazione scientifica.

Esito: sistema di IA, ma esonerato dall'AI Act in quanto attività di ricerca scientifica. Ricorrono gli elementi necessari (1, 2, 4 e 5) e gli elementi 6 e 7: la qualificazione formale come sistema di IA è quindi positiva. Tuttavia, l'art. 2, par. 6 dell'AI Act esclude dall'ambito di applicazione del Regolamento «ai sistemi di IA o modelli di IA, ivi compresi i loro output, specificamente sviluppati e messi in servizio al solo scopo di ricerca e sviluppo scientifici», come illustrato nel riquadro «Sei un ente pubblico di ricerca o un'università che sviluppa software per il GDU…» in questa sezione. Restano comunque applicabili i principi etici e i diritti fondamentali per i partecipanti alla ricerca.

5.1.9 Esempi specifici per i Gemelli Digitali Urbani

Un Gemello Digitale Urbano è tipicamente un «sistema di sistemi»: integra moduli eterogenei (sensoristica, modellazione 3D, simulazione, analisi dei dati, modelli predittivi, supporto alle decisioni). Per questo non si qualifica «in blocco»: la checklist del § 5.1.4 va applicata componente per componente, perché alcuni moduli sono sistemi di IA e altri no. Gli esempi che seguono — desunti da casi reali documentati nel report «Italia città intelligenti» e nel documento «COMTem — Casi d'uso di Digital Twin» — illustrano questo spettro nel contesto del supporto alla Pubblica Amministrazione cittadina. Poiché tali fonti sono divulgative, gli esempi vanno letti come casi-tipo: la qualificazione definitiva dipende dal «come» ciascun modulo è effettivamente realizzato.

Esempio GDU-1 — Nucleo decisionale del GDU (modelli predittivi, sistema esperto, ottimizzazione)

Descrizione. Nel modello di GDU come «sistema di sistemi» (Urban Intelligence, CNR-DIITET; casi Matera e Catania), il nucleo di supporto alle decisioni integra modelli di machine learning per la previsione (es. domanda di mobilità, qualità dell'aria), un sistema esperto che ragiona con regole «if-then» (Urban Sensing Engine) e algoritmi di ottimizzazione multi-obiettivo, producendo per la PA scenari e raccomandazioni operative e strategiche; il sistema apprende in modo continuo dai dati della città.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Software eseguito su infrastruttura di calcolo e data lake.
• Elemento 2 (autonomia variabile) — SÌ. Genera autonomamente scenari e raccomandazioni che l'amministrazione valuta.
• Elemento 3 (adattabilità dopo la diffusione) — SÌ. Il «loop continuo di apprendimento e ottimizzazione» adatta i modelli ai nuovi dati dopo il rilascio.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivi espliciti di governance (ridurre congestione, emissioni, consumi).
• Elemento 5 (inferenza dall'input) — SÌ. Inferenza sia sub-simbolica (ML) sia simbolica: il motore «if-then» deriva conclusioni non specificate puntualmente (considerando 12 AI Act; Orientamenti, par. 30).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Previsioni, scenari e raccomandazioni decisionali.
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. Incide sull'ambiente urbano orientando le decisioni di governance.

Esito: sistema di IA. Ricorrono gli elementi necessari (1, 2, 4 e 5) e tutti gli altri. Si noti che anche il sistema esperto a regole è IA, perché vi è un motore di inferenza (a differenza dell'algoritmo deterministico, § 5.1.7). Questo è però solo il nucleo inferenziale del GDU: i moduli di sola simulazione (GDU-2), di rappresentazione 3D (GDU-3) o di cruscotto (GDU-6) vanno qualificati a parte.

Esempio GDU-2 — Modulo di simulazione fisico-numerica (scenari «what-if»)

Descrizione. Modulo del gemello digitale che simula scenari «what-if» risolvendo modelli fisici noti — propagazione del rumore da traffico (caso Pilsen/DUET), flussi energetici di una comunità energetica (caso +PADOVAxCHANGE), impatti climatici (caso Amiens) — per valutare l'effetto di un intervento prima di realizzarlo.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Software di calcolo.
• Elemento 2 (autonomia variabile) — NO. Esegue il calcolo secondo i parametri impostati dall'operatore, senza autonomia operativa.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Non apprende dopo il rilascio: a parità di input restituisce lo stesso risultato (ripetibilità).
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Ha l'obiettivo di stimare l'impatto di uno scenario.
• Elemento 5 (inferenza dall'input) — NO. Non inferisce: applica leggi fisiche e regole definite dall'uomo. Gli Orientamenti (parr. 42-43) escludono i sistemi basati su modelli fisici consolidati, anche quando accelerati o approssimati con ML.
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Produce previsioni e scenari.
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. Gli scenari influenzano le scelte di pianificazione.

Esito: non è un sistema di IA (simulazione). Manca l'elemento 5 (inferenza): pur essendo «predittivo», il modulo calcola con regole fisiche fissate, è ripetibile e non apprende. È un algoritmo deterministico (§ 5.1.7). Si contrappone a GDU-5, dove la previsione è invece appresa dai dati.

Esempio GDU-3 — Modello digitale 3D del territorio o di un bene culturale

Descrizione. Replica digitale tridimensionale ad alta precisione del territorio o di un bene culturale, navigabile e interrogabile (es. gemello dell'Oratorio di San Giorgio a Padova; modello geometrico-topografico di Rennes), usata per consultazione, valorizzazione e come base per la pianificazione.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Software di rappresentazione geospaziale.
• Elemento 2 (autonomia variabile) — NO. Restituisce ciò che è stato rilevato e modellato, su comando dell'utente.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Non apprende né si adatta.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ (formalmente). Ha il fine di rappresentare fedelmente l'oggetto.
• Elemento 5 (inferenza dall'input) — NO. Non inferisce: espone dati geometrici misurati e memorizzati.
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — PARZIALE. Produce visualizzazioni, non previsioni, raccomandazioni o decisioni.
• Elemento 7 (influenza su ambienti fisici o virtuali) — NO. È uno strumento di consultazione.

Esito: non è un sistema di IA (rappresentazione). È un «Digital Model» privo di inferenza e adattabilità: un sistema informativo geospaziale, non un sistema di IA. Mancano gli elementi necessari 2 e 5, nonché gli elementi 3 e 7.

Esempio GDU-4 — Videosorveglianza urbana con visione artificiale

Descrizione. Sistema che analizza in tempo reale i flussi video della rete di telecamere cittadine con modelli di deep learning per rilevare eventi (incidenti, assembramenti, oggetti abbandonati), classificare e tracciare veicoli e leggere le targhe (OCR), allertando gli operatori della sicurezza urbana (cfr. control room di Venezia).

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Software su infrastruttura di videoanalisi.
• Elemento 2 (autonomia variabile) — SÌ. Segnala gli eventi rilevanti senza monitoraggio umano costante e può innescare azioni.
• Elemento 3 (adattabilità dopo la diffusione) — PARZIALE. I modelli sono riaddestrabili, non necessariamente in continuo.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivi di sicurezza e controllo del territorio.
• Elemento 5 (inferenza dall'input) — SÌ. Inferenza tramite deep learning (classificazione, rilevamento, riconoscimento).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Allerte, identificazioni, decisioni operative.
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. Incide sulla sicurezza e sullo spazio fisico urbano.

Esito: sistema di IA. Ricorrono gli elementi necessari (1, 2, 4 e 5) e tutti gli altri. È tipicamente ad alto rischio (allegato III AI Act) e, per eventuali funzioni di identificazione biometrica, soggetto ai divieti e limiti dell'art. 5 e alla disciplina sui dati personali (DPIA): rinvio al riquadro «Valuta se il tuo sistema è intelligenza artificiale ad alto rischio» e alla sezione 4 sui dati personali.

Esempio GDU-5 — Manutenzione predittiva delle infrastrutture (machine learning)

Descrizione. Modello di machine learning che, dai dati storici e in tempo reale dei sensori su ponti, edifici o reti (idrica, elettrica), apprende i pattern di degrado e prevede i guasti per programmare interventi preventivi (casi Espoo, Chorus Life Bergamo, GDU Matera).

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Software su infrastruttura di analisi dati.
• Elemento 2 (autonomia variabile) — SÌ. Produce allerte e priorità di intervento senza intervento puntuale.
• Elemento 3 (adattabilità dopo la diffusione) — SÌ. Riaddestrabile e aggiornabile sui nuovi dati.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivo di prevenire guasti e ottimizzare la manutenzione.
• Elemento 5 (inferenza dall'input) — SÌ. Inferenza appresa dai dati (ML): deriva previsioni non specificate puntualmente.
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Previsioni di guasto e raccomandazioni di intervento.
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. Incide sulla manutenzione delle infrastrutture.

Esito: sistema di IA. Ricorrono gli elementi necessari (1, 2, 4 e 5) e tutti gli altri. A differenza di GDU-2, l'output è inferito da pattern appresi dai dati e non calcolato da leggi fisiche fissate: la differenza sta nel «come» (considerando 12; § 5.1.7). Se invece la «previsione» si riducesse a una regola statistica elementare (es. media storica), ricadrebbe fra i casi esclusi (§ 5.1.5; Orientamenti, parr. 49-51).

Esempio GDU-6 — Piattaforma di integrazione dati / control room urbana

Descrizione. Cruscotto che raccoglie, integra e visualizza in tempo reale i dati della città (presenze, traffico, parcheggi, meteo, mezzi pubblici) su base geolocalizzata, con eventuale telecontrollo a regole degli impianti (es. Roma Data Platform; control room di Firenze; Nottingham), a supporto delle decisioni degli operatori.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Software di integrazione e visualizzazione dati.
• Elemento 2 (autonomia variabile) — NO. Esegue raccolta, visualizzazione e comandi predefiniti.
• Elemento 3 (adattabilità dopo la diffusione) — NO. Non apprende né si adatta.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ (formalmente). Ha il fine di rappresentare lo stato della città.
• Elemento 5 (inferenza dall'input) — NO. Non inferisce: aggrega e presenta dati (analisi descrittiva e visualizzazione; Orientamenti, par. 47).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — PARZIALE. Output informativi (dashboard), non raccomandazioni inferite.
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ (mediato). Supporta le decisioni degli operatori umani.

Esito: non è un sistema di IA (sistema informativo). Manca l'elemento 5: è un sistema informativo/di supervisione riconducibile all'analisi descrittiva e alla visualizzazione escluse dagli Orientamenti (§ 5.1.5, par. 47). Diventa IA solo se vi si innestano moduli inferenziali (es. previsione, GDU-5).

Esempio GDU-7 — Servizi IoT urbani a regole (parcheggi, illuminazione adattiva)

Descrizione. Servizi del GDU basati su sensori e regole: smart parking che indica gli stalli liberi e calcola percorso e tariffa; illuminazione pubblica adattiva (TAI/FAI) che regola l'intensità in base a movimento, traffico e luminosità; raccolta rifiuti con ottimizzazione dei percorsi.

Compilazione della checklist:

• Elemento 1 (sistema automatizzato) — SÌ. Software su sensoristica IoT.
• Elemento 2 (autonomia variabile) — PARZIALE. Regolazione automatica entro condizioni specificate: è automazione, non autonomia (ISO/IEC 22989, 3.1.7).
• Elemento 3 (adattabilità dopo la diffusione) — NO. L'«adattività» è reazione a soglie, non apprendimento dopo il rilascio.
• Elemento 4 (obiettivi espliciti o impliciti) — SÌ. Obiettivi di efficienza del servizio.
• Elemento 5 (inferenza dall'input) — NO. Applica regole fisse su input sensoriali; l'eventuale ottimizzazione dei percorsi è ottimizzazione matematica esclusa (Orientamenti, parr. 42-45).
• Elemento 6 (output: previsioni, contenuti, raccomandazioni, decisioni) — SÌ. Output operativi (indicazioni, regolazioni).
• Elemento 7 (influenza su ambienti fisici o virtuali) — SÌ. Incide sull'ambiente fisico (sosta, illuminazione, raccolta).

Esito: non è un sistema di IA (automazione a regole). Manca l'elemento 5: applica regole fisse e, al più, ottimizzazione matematica esclusa. Caso utile per distinguere l'adattività tecnica (a soglie) dall'adattabilità dell'AI Act (apprendimento) e l'ottimizzazione matematica dall'inferenza (§ 5.1.5).

5.2 Questionario definitorio di Sistema di IA

La definizione di sistema di IA adotta una prospettiva basata sul ciclo di vita che comprende due fasi principali: la fase precedente alla diffusione o di "costruzione" del sistema e la fase successiva alla diffusione o di "uso" del sistema⁴⁸.

Non è necessario che i sette elementi indicati nella definizione siano presenti in modo continuativo in entrambe le fasi di tale ciclo di vita. La definizione riconosce invece la possibilità che alcuni elementi specifici appaiano in una fase, ma non persistano in entrambe le fasi».⁴⁹

Sebbene non sia possibile determinare automaticamente quali sistemi rientrino o meno nella definizione di sistema di IA o redigere elenchi esaustivi, si invita a far ricorso a una valutazione meramente preliminare che possa aiutare a qualificare il sistema in consegna alla PA.

ANNOTAZIONE

La valutazione non è meccanica

Va fatta caso per caso

La capacità inferenziale è fondamentale per conseguire l'autonomia50.

AVVIA IL TOOL

Questionario definitorio sistema di IA

⚠️ Attenzione: la qualificazione come sistema di IA non implica automaticamente l'applicazione di obblighi normativi specifici. Gli obblighi dipendono dalla classificazione di rischio (alto rischio, rischio limitato, ecc.) ai sensi degli artt. 5, 6, 50 del Regolamento. Resta fermo, per i fornitori e i deployer di qualunque sistema di IA, l’obbligo di alfabetizzazione in materia di IA (art. 4, nel testo sostituito dal regolamento (UE) 2026/1744).

5.3 Questionario definitorio di modello di IA

Sebbene non sia possibile determinare automaticamente quali sistemi rientrino o meno nella definizione di modello di IA per finalità generali (art. 3, punto 63) o redigere elenchi esaustivi, si invita a far ricorso a una valutazione meramente preliminare che possa aiutare a qualificare il modello in consegna alla PA.

ANNOTAZIONE

La valutazione non è meccanica

Va fatta caso per caso

Valuta se un sistema rientra nella definizione di modello di IA per finalità generali e se presenta rischio sistemico, secondo la Comunicazione della Commissione europea C(2025) 5045 final, Bruxelles, 18 luglio 2025, recante gli Orientamenti relativi all’ambito di applicazione degli obblighi per i modelli di IA per finalità generali previsti dal regolamento (UE) 2024/1689 (regolamento sull’intelligenza artificiale).

AVVIA IL TOOL

Test di classificazione modello GPAI

FOCUS BOX

Sei un’impresa che sviluppa il GDU?

Le imprese che sviluppano GDU per la PA (si vedano il § 5.1.3 e la sezione 9 del Vademecum) sono tenute a rispettare quanto stabilito dal Regolamento (Ue) 2024/1689 del Parlamento europeo e del Consiglio (il c.d. AI Act) e gli obblighi da esso derivanti.

Le date di applicazione del regolamento, come modificato dal regolamento (UE) 2026/1744 («Omnibus digitale sull’IA», GU L del 24 luglio 2026, in vigore dal 27 luglio 2026), sono riassunte nel prospetto che segue, al quale rinviano le altre Sezioni del Vademecum (artt. 111 e 113 AI Act, come modificati dal reg. (UE) 2026/1744, art. 1, punti 39 e 40): 2 febbraio 2025: capi I e II (disposizioni generali, compreso l’obbligo di alfabetizzazione in materia di IA dell’art. 4, riformulato dal reg. (UE) 2026/1744 con effetto dal 27 luglio 2026; pratiche vietate dell’art. 5 nel testo originario); 2 agosto 2025: obblighi dei fornitori di modelli di IA per finalità generali (capo V); i modelli già immessi sul mercato prima di tale data vi si adeguano entro il 2 agosto 2027 (art. 111, par. 3); 2 agosto 2026: applicazione generale del regolamento, compresi gli obblighi di trasparenza dell’art. 50 e le sanzioni dell’art. 101 per i fornitori di modelli per finalità generali; 2 dicembre 2026: nuovi divieti dell’art. 5 introdotti dal reg. (UE) 2026/1744 (par. 1, lett. b bis) e b ter): contenuti intimi non consensuali e materiale di abuso sessuale su minori generati con IA); 2 dicembre 2027: capo III, sezioni 1–3 (classificazione, requisiti e obblighi per l’alto rischio, compresi gli artt. 26 e 27 e la FRIA), per i sistemi dell’allegato III; 2 agosto 2028: capo III, sezioni 1–3, per i sistemi dell’allegato I; 2 agosto 2030: termine di adeguamento per i sistemi ad alto rischio destinati a essere usati da autorità pubbliche e immessi sul mercato o messi in servizio prima della data di applicazione del capo III (art. 111, par. 2). Fonti: regolamento (UE) 2024/1689, testo consolidato su EUR-Lex (comprende le modifiche del regolamento (UE) 2026/1744); AI Act Service Desk della Commissione europea. https://artificialintelligenceact.eu/implementation-timeline/ Ai sensi dell'art. 2, par. 1, Reg. 2024/1689, il regolamento si applica a:

a)fornitori che immettono sul mercato o mettono in servizio sistemi di IA o immettono sul mercato modelli di IA per finalità generali nell'Unione, indipendentemente dal fatto che siano stabiliti o ubicati nell'Unione o in un paese terzo; b)deployer dei sistemi di IA che hanno il loro luogo di stabilimento o sono situati all'interno dell'Unione; c)fornitori e deployer di sistemi di IA che hanno il loro luogo di stabilimento o sono situati in un paese terzo, laddove l'output prodotto dal sistema di IA sia utilizzato nell'Unione; d)importatori e distributori di sistemi di IA; e) fabbricanti di prodotti che immettono sul mercato o mettono in servizio un sistema di IA insieme al loro prodotto e con il loro nome o marchio; f)rappresentanti autorizzati di fornitori, non stabiliti nell'Unione; g)persone interessate che si trovano nell'Unione. Ai sensi del Considerando n.13 del regolamento sull'IA, la nozione di «deployer» dovrebbe essere interpretata come qualsiasi persona fisica o giuridica, compresa un'autorità pubblica, un'agenzia o un altro organismo, che utilizza un sistema di IA sotto la sua autorità, salvo nel caso in cui il sistema di IA sia utilizzato nel corso di un'attività personale non professionale.

Controlla a quali obblighi ai sensi dell’AI Act è sottoposto il tuo sistema di IA

Puoi utilizzare questo strumento interattivo per determinare se il tuo sistema di IA sarà soggetto o meno a questi obblighi seguendo il test che ha sviluppato il team del Future of Life Institute. https://artificialintelligenceact.eu/

Segui: https://artificialintelligenceact.eu/it/assessment/controllo-della-conformita-dell-ue-alla-legge-ai/ https://artificialintelligenceact.eu/wp-content/uploads/2025/07/AI-Act-Compliance-Checker-Flowchart-v1.0_compressed.pdf Oppure usa il tool che segue che riporta in sintesi il precedente controllo della conformità alla legge IA: Utilizza il Compliance Checker AI Act che è un tool che adatta il sistema sopra richiamato per determinare gli obblighi applicabili

ATTENZIONE:

Sei un ente pubblico di ricerca o un'università che sviluppa software per il GDU, classificabile come intelligenza artificiale (IA)?

Questa parte del documento è dedicata agli enti di ricerca e alle università che supportano lo sviluppo di un GDU, affinché alla pubblica amministrazione siano fornite tutte le informazioni necessarie, così da poterle utilizzare a supporto della propria attività.

Come sopra ricordato, l'ambito soggettivo di applicazione del regolamento comprende, tra gli altri, i fornitori e i deployer dei sistemi di IA, includendo anche le pubbliche amministrazioni, laddove utilizzino tali sistemi nell’esercizio delle proprie funzioni istituzionali.

Il Regolamento (UE) 2024/1689 (AI Act) si applica agli sviluppatori e a chi implementa i sistemi durante tutto il ciclo di vita dell'IA, ma prevede deroghe distinte per l'esplorazione accademica e scientifica

Nel contesto delle collaborazioni tra enti di ricerca e pubbliche amministrazioni, emerge una questione centrale: quando un sistema algoritmico, sviluppato originariamente per finalità scientifiche, entra nell’ambito di applicazione dell’AI Act e diventa soggetto agli obblighi previsti dal regolamento?

Dal punto di vista oggettivo, il regolamento “non si applica ai sistemi di IA o modelli di IA, ivi compresi i loro output, specificamente sviluppati e messi in servizio al solo scopo di ricerca e sviluppo scientifici” (art. 2, par. 6)

Specificatamente, il regolamento “non si applica alle attività di ricerca, prova o sviluppo relative a sistemi di IA o modelli di IA prima della loro immissione sul mercato o messa in servizio. Tali attività sono svolte in conformità del diritto dell'Unione applicabile. Le prove in condizioni reali non rientrano in tale esclusione (art. 2, par. 8)”.

Per «immissione sul mercato» si intende: la prima messa a disposizione di un sistema di IA o di un modello di IA per finalità generali sul mercato dell'Unione (punto 9, art. 3)

Per «messa in servizio» si intende: la fornitura di un sistema di IA direttamente al deployer per il primo uso o per uso proprio nell'Unione per la finalità prevista (punto 11, art. 3)

Per «prova in condizioni reali» si intende: la prova temporanea di un sistema di IA per la sua finalità prevista in condizioni reali al di fuori di un laboratorio o di un ambiente altrimenti simulato al fine di raccogliere dati affidabili e solidi e di valutare e verificare la conformità del sistema di IA ai requisiti del presente regolamento e che non è considerata immissione sul mercato o messa in servizio del sistema di IA ai sensi del presente regolamento, purché siano soddisfatte tutte le condizioni di cui all'articolo 57 o 60 (punto 57, art. 3).

Per cui il Regolamento (UE) 2024/1689 (AI Act) delinea due principali esclusioni incentrate sulla ricerca. Ciò include la ricerca condotta non solo da organizzazioni senza scopo di lucro, ma anche da aziende private:

• Esenzione per la ricerca scientifica (articolo 2, paragrafo 6): Esclude i sistemi di IA (compresi i loro output) specificamente sviluppati e implementati al solo scopo della ricerca e dello sviluppo scientifici.
• Esenzione per lo sviluppo pre-commercializzazione (Articolo 2(8)): Esenta qualsiasi sistema o modello di IA sottoposto a ricerca, test o sviluppo prima di essere immesso sul mercato o messo in servizio⁵¹.

Le due esclusioni hanno presupposti distinti:

• per l’art. 2, par. 6, il sistema o il modello deve essere specificamente sviluppato e messo in servizio al solo scopo di ricerca e sviluppo scientifici;
• per l’art. 2, par. 8, deve trattarsi di attività di ricerca, prova o sviluppo svolte prima dell’immissione sul mercato o della messa in servizio, escluse le prove in condizioni reali;
• l’esclusione copre anche la ricerca e sviluppo orientata ai prodotti (considerando 25), ma non l’uso, a fini di ricerca, di un sistema già immesso sul mercato o messo in servizio.

Tuttavia, la portata dell’esclusione è limitata. Si perde l'esenzione e si dovrà ottemperare alle norme standard dell'AI Act se:

• Commercializzazione: il modello o il sistema viene venduto, concesso in licenza o immesso sul mercato interno.
• Implementazione nel mondo reale: L'IA viene messa in servizio in condizioni reali con utenti finali effettivi (ad esempio, implementando uno strumento diagnostico medico sperimentale in un ospedale anziché in laboratorio).
• Pubblicazione open-source: Sebbene l'AI Act preveda condizioni favorevoli per l'IA a uso generico rilasciata con licenze libere e open-source, la semplice pubblicazione di un modello o di un codice al pubblico può comportare degli obblighi se viene considerata come “messa a disposizione sul mercato” (art. 3, punto 10, AI Act). L’esclusione per i sistemi rilasciati con licenza libera e open source è prevista dall’art. 2, par. 12, e non opera per i sistemi ad alto rischio né per quelli degli artt. 5 e 50.

Nel caso in cui un ente di ricerca sviluppi un algoritmo e lo trasferisca a una pubblica amministrazione, si determinano due possibili assetti giuridici.

Uso nell’ambito della ricerca

Qualora il sistema sia utilizzato dalla PA:

• esclusivamente nell’ambito di un progetto di ricerca;
• senza incidenza su procedimenti amministrativi;
• senza effetti diretti sulle posizioni giuridiche dei cittadini,
• esso può continuare a rientrare nell’ambito dell’esclusione per la ricerca scientifica.

Uso operativo nell’attività amministrativa

Diversamente, qualora il sistema:

• sia impiegato per supportare o automatizzare decisioni amministrative;
• incida su diritti, interessi o aspettative legittime dei cittadini;
• sia integrato stabilmente nei processi organizzativi della PA,
• si configura una messa in servizio effettiva, con conseguente applicazione dell’AI Act.

In tale ipotesi, il sistema esce dalla sfera della ricerca e si inserisce nel circuito regolato, determinando:

• la qualificazione dell’ente di ricerca quale fornitore;
• la qualificazione della PA quale deployer.

Requisiti che è comunque necessario rispettare anche quando si opera rigorosamente nell'ambito dell'esenzione per la ricerca, le attività devono comunque svolgersi in conformità del diritto dell'Unione applicabile (art. 2, par. 8) e delle norme etiche e professionali riconosciute (considerando 25); in particolare, è opportuno che i ricercatori e gli istituti di ricerca:

• Garantiscano che lo sviluppo e l'uso del sistema di IA rispettino i diritti fondamentali e i valori dell'Unione.
• Garantiscano che qualsiasi test al di fuori di condizioni puramente di laboratorio comporti una governance responsabile

ANNOTAZIONE

La dimensione etica dell'IA non è una caratteristica aggiuntiva o esotica: deve essere parte integrante dello sviluppo dell'IA, sia che operi o non operi l’esenzione

Anche in caso di eccezione, è essenziale rispettare i diritti fondamentali dei partecipanti alla ricerca prima che tali sistemi o modelli siano immessi sul mercato o messi in servizio. Ciò significa che, secondo le fonti giuridiche europee sopra citate, per evitare i rischi dell'IA e aumentarne i benefici, l'IA deve essere lecita, ovvero deve rispettare le leggi e i regolamenti applicabili e deve anche essere "etica" nel senso che non deve compromettere gli interessi e i valori tutelati dall'ordinamento giuridico e quindi rispettare un "quadro etico", come lo definisce il documento Orientamenti etici 2019 per un’IA affidabile (High-Level Expert Group on AI – HLEGAI) Ethics Guidelines for Trustworthy AI (DG CONNECT).

L’Assessment List for Trustworthy AI (ALTAI) è la lista di autovalutazione pubblicata nel luglio 2020 dal gruppo di esperti ad alto livello sull’IA (AI HLEG) istituito dalla Commissione europea, per verificare l’aderenza ai 7 requisiti dell’IA affidabile definiti negli Orientamenti etici del 2019. Lo strumento del Vademecum ne propone una selezione adattata: 28 domande riformulate, contro le 126 dell’originale, distribuite in 7 sezioni. Rispondi e ottieni un quadro dell’aderenza autovalutata ai sette requisiti; punteggio e soglie sono di questo strumento: l’ALTAI non assegna punteggi. L’autovalutazione è volontaria e non misura la conformità giuridica: in particolare non è uno strumento di conformità al regolamento (UE) 2024/1689, che richiama i sette requisiti come principi etici non vincolanti (considerando 27). L’ALTAI raccomanda di compilarla in un gruppo multidisciplinare e dopo una valutazione d’impatto sui diritti fondamentali, che nell’ALTAI è una valutazione generale, diversa dalla FRIA dell’art. 27 AI Act. Fonte: AI HLEG, The Assessment List for Trustworthy Artificial Intelligence (ALTAI) for self assessment, 2020, doi:10.2759/002360. Fai riferimento a: https://altai.insight-centre.org/Home/HowToComplete

AVVIA IL TOOL Assessment List for Trustworthy AI (ALTAI): ALTAI — Assessment List for Trustworthy AI

FOCUS BOX

Se un progetto di ricerca si espande e passa all’uso commerciale o a un’implementazione “ad alto rischio” (come l’IA nel reclutamento, nelle infrastrutture critiche o nei dispositivi medici autonomi), gli sviluppatori e gli implementatori devono conformarsi, prima dell'immissione sul mercato o della messa in servizio, ai requisiti dell’AI Act. Ciò comporta la registrazione dell'IA, l'istituzione di sistemi di gestione dei rischi, la conservazione della documentazione e il sottoporsi a valutazioni di conformità52.

Controllo della conformità alla legge sull'AI dell'UE Come nel caso del GDU sviluppato dalle imprese, puoi utilizzare questo strumento interattivo per determinare se il tuo sistema di IA sarà soggetto o meno a questi obblighi

Per le date di applicazione del regolamento si rinvia al prospetto riportato nel focus box «Sei un’impresa che sviluppa il GDU?» (§ 5.3). https://artificialintelligenceact.eu/implementation-timeline/ Ai sensi dell'art. 2, par. 1, Reg. 2024/1689, il regolamento si applica a:

a)fornitori che immettono sul mercato o mettono in servizio sistemi di IA o immettono sul mercato modelli di IA per finalità generali nell'Unione, indipendentemente dal fatto che siano stabiliti o ubicati nell'Unione o in un paese terzo; b)deployer dei sistemi di IA che hanno il loro luogo di stabilimento o sono situati all'interno dell'Unione; c)fornitori e deployer di sistemi di IA che hanno il loro luogo di stabilimento o sono situati in un paese terzo, laddove l'output prodotto dal sistema di IA sia utilizzato nell'Unione; d)importatori e distributori di sistemi di IA; e) fabbricanti di prodotti che immettono sul mercato o mettono in servizio un sistema di IA insieme al loro prodotto e con il loro nome o marchio; f)rappresentanti autorizzati di fornitori, non stabiliti nell'Unione; g)persone interessate che si trovano nell'Unione. Ai sensi del Considerando n.13 del regolamento sull'IA, la nozione di «deployer» dovrebbe essere interpretata come qualsiasi persona fisica o giuridica, compresa un'autorità pubblica, un'agenzia o un altro organismo, che utilizza un sistema di IA sotto la sua autorità, salvo nel caso in cui il sistema di IA sia utilizzato nel corso di un'attività personale non professionale.

Controlla a quali obblighi ai sensi dell’AI Act è sottoposto il tuo sistema di IA

Puoi utilizzare questo strumento interattivo per determinare se il tuo sistema di IA sarà soggetto o meno a questi obblighi seguendo il test che ha sviluppato il team del Future of Life Institute. https://artificialintelligenceact.eu/

Segui: https://artificialintelligenceact.eu/it/assessment/controllo-della-conformita-dell-ue-alla-legge-ai/ https://artificialintelligenceact.eu/wp-content/uploads/2025/07/AI-Act-Compliance-Checker-Flowchart-v1.0_compressed.pdf Oppure usa il tool che segue che riporta in sintesi il precedente controllo della conformità alla legge IA: Utilizza il Compliance Checker AI Act che è un tool che adatta il sistema sopra richiamato per determinare gli obblighi applicabili

Valuta se il tuo sistema è intelligenza artificiale ad alto rischio

Il Regolamento (UE) 2024/1689 (AI Act), introduce un approccio basato sul rischio per garantire il rispetto dei diritti fondamentali sanciti dalla Carta UE. Particolare attenzione è dedicata ai sistemi di IA ad alto rischio.

Un sistema di intelligenza artificiale ad alto rischio è definito dal Regolamento (UE) 2024/1689 (AI Act) come un sistema che, per il suo impatto potenziale su diritti fondamentali, sicurezza o interessi pubblici, è soggetto a obblighi più stringenti di conformità e controllo.

Caratteristiche principali

• Elevato potenziale di danno per individui o società (es. discriminazione, violazione della privacy, rischi per la salute).
• Impiego in settori sensibili o in processi decisionali che incidono su diritti fondamentali.

Un sistema IA è considerato ad alto rischio (Art. 6 AI Act) se, a prescindere dal fatto che sia immesso sul mercato o messo in servizio indipendentemente dai prodotti di cui alle successive lettere a) e b), sono soddisfatte entrambe le condizioni seguenti:

a)il sistema di IA è destinato a essere utilizzato come componente di sicurezza di un prodotto, o il sistema di IA è esso stesso un prodotto, disciplinato dalla normativa di armonizzazione dell'Unione elencata nell'allegato I dell’AI Act⁵³;

b)il prodotto, il cui componente di sicurezza a norma della lettera a) è il sistema di IA, o il sistema di IA stesso in quanto prodotto, è soggetto a una valutazione della conformità da parte di terzi ai fini dell'immissione sul mercato o della messa in servizio di tale prodotto ai sensi della normativa di armonizzazione dell'Unione elencata nell'Allegato I.

Oltre ai sistemi di IA ad alto rischio di cui sopra (art. 6, par. 1, e allegato I: sistemi che sono prodotti disciplinati dalla normativa di armonizzazione dell’Unione, o loro componenti di sicurezza, come dispositivi medici e diagnostici in vitro, macchine, giocattoli, apparecchiature di sicurezza), sono considerati ad alto rischio anche i sistemi di IA di cui all'Allegato III dell’AI Act (art. 6, par. 2).

Si considerano ad alto rischio in particolare i sistemi di IA che:

• Compiono azioni qualificabili come biometriche:
  • • Identificazione remota di persone.
    • Categorizzazione basata su caratteristiche sensibili (salvo i casi vietati dall’art. 5, par. 1, lett. g)).
• Sono usati come componenti di sicurezza nella gestione e nel funzionamento delle infrastrutture digitali critiche, del traffico stradale o della fornitura di acqua, gas, riscaldamento o elettricità (punto 2).
• Riguardano la istruzione e formazione professionale e sono destinati a essere utilizzati:
  • • per determinare l'accesso, l'ammissione o l'assegnazione di persone fisiche agli istituti di istruzione e formazione professionale a tutti i livelli;
    • per valutare i risultati dell'apprendimento;
    • per valutare il livello di istruzione adeguato che una persona riceverà o a cui potrà accedere, nel contesto o all'interno di istituti di istruzione o formazione professionale a tutti i livelli;
    • per monitorare e rilevare comportamenti vietati degli studenti durante le prove nel contesto o all'interno di istituti di istruzione e formazione professionale a tutti i livelli.
• Si utilizzano nel settore dell’occupazione:
  • • Reclutamento, selezione, valutazione delle performance.
• Si applicano all’accesso a servizi essenziali:
  • • Sanità, credito, assicurazioni.
• Sono impiegati dalle Forze dell’ordine:
  • • Prevenzione reati, valutazione prove.
• Sono utilizzati nelle attività di migrazione e controllo frontiere.
• Supportano processi di giustizia e processi democratici:
  • • Supporto a un'autorità giudiziaria nella ricerca e nell'interpretazione dei fatti e del diritto e nell'applicazione della legge o a essere utilizzati nella risoluzione alternativa delle controversie;
    • Utilizzati per influenzare l'esito di un'elezione o di un referendum o il comportamento di voto delle persone nell'esercizio del loro diritto di voto alle elezioni o ai referendum.

Un sistema dell’allegato III che effettua la profilazione di persone fisiche è sempre considerato ad alto rischio (art. 6, par. 3, ultimo comma). Per gli altri sistemi dell’allegato III l’art. 6, par. 3, consente una deroga quando il sistema non presenta un rischio significativo di danno per la salute, la sicurezza o i diritti fondamentali, alle condizioni del secondo comma; il fornitore che se ne avvale documenta la valutazione (art. 6, par. 4) e registra il sistema (art. 49, par. 2).

FOCUS BOX

Ti invitiamo a valutare se il tuo sistema è ad alto rischio seguendo la Valutazione d'impatto dell'intelligenza artificiale (AIIA) sviluppata dal Ministero delle Infrastrutture e della Gestione delle Acque dei Paesi Bassi, a cui si rimanda per una lettura completa, e qui si riporta la parte operativa con una traduzione non ufficiale: https://www.government.nl/documents/2023/03/02/ai-impact-assessment

Abbiamo realizzato un tool operativo in ragione del contenuto delle Appendici 1 e 2 e delle Domande per gli operatori contenute nel testo sopra richiamato:

AVVIA IL TOOL

Valutazione del livello di rischio

Focus box

Realizza la FRIA

Utilizzando il Template Excel per la Valutazione dell'Impatto sui Diritti Fondamentali (Art. 27 AI Act), che accompagna la guida «A Guide to Fundamental Rights Impact Assessments (FRIA)» dell’European Center for Not-for-Profit Law (ECNL) e del Danish Institute for Human Rights (DIHR), 12 dicembre 2025 (https://ecnl.org/publications/guide-fundamental-rights-impact-assessments-fria). Il modello è in lingua inglese e va inteso come modello di lavoro: il modello di questionario che l’ufficio per l’IA deve mettere a disposizione (art. 27, par. 5, nel testo sostituito dal regolamento (UE) 2026/1744) al 16 ottobre 2026 non risulta pubblicato, e la Commissione lo indica fra gli orientamenti in preparazione (https://digital-strategy.ec.europa.eu/en/news/supporting-implementation-ai-act-clear-guidelines).

5.4 Obblighi di Trasparenza dei sistemi di IA

L'AI Act europeo impone requisiti di trasparenza per determinati sistemi di IA, indipendentemente dalla loro classificazione di rischio (per quelli ad alto rischio, in aggiunta ai requisiti del capo III). Questi obblighi sono definiti in modo specifico all'Art. 50. Dal 2 agosto 2026, sia i fornitori (provider) che gli utilizzatori (deployer) sono soggetti a precisi obblighi di notifica e marcatura

Alla luce del quadro normativo, si dovrebbe avviare un percorso di adeguamento strutturato.

Ogni organizzazione che utilizzi sistemi di IA che rientrano nelle categorie di cui all’art. 50, dovrebbe:

• Comunicare la natura artificiale dell’interazione (art. 50, par. 1)
• Garantire la marcatura tecnica dei contenuti sintetici (art. 50, par. 2)
• Informativa per riconoscimento delle emozioni e categorizzazione biometrica (art. 50, par. 3)
• La disclosure dei deepfake e dei testi di interesse pubblico (art. 50, par. 4)

Di seguito alcune indicazioni pratiche su alcuni aspetti rilevanti da tenere in considerazione.

1. 1.In primo luogo, è necessario mappare i sistemi di IA in uso e identificare il proprio ruolo (fornitore o deployer)
2. 2.Un secondo elemento che si dovrebbe considerare è la mappatura delle modalità di comunicazione esistenti dei sistemi già in uso a contatto con gli utenti per verificare il livello di maturità rispetto agli obblighi che diventeranno applicabili.
3. 3.Inoltre, per quanto riguarda i fornitori di sistemi di IA che generano contenuto, è opportuno altresì avviare la valutazione delle soluzioni tecniche di marcatura per la segnalazione dei contenuti 
4. 4.il personale dell’organizzazione che utilizza strumenti di IA tra quelli descritti sopra deve essere formato sugli obblighi di disclosure. In particolare, è importante che anche i soggetti all’interno dell’organizzazione che utilizzano tali soluzioni di IA siano a conoscenza delle casistiche viste sopra e dei relativi obblighi⁵⁴.

Regola di trasparenza se il tuo sistema interagisce con le persone e per i contenuti generati dall’IA

L'art. 50 del Regolamento (UE) 2024/1689 (AI Act) delinea un articolato sistema di obblighi di trasparenza applicabili sia ai fornitori (provider) sia agli utilizzatori professionali (deployer) di sistemi di intelligenza artificiale, indipendentemente dalla loro classificazione di rischio. L’Art. 50 AI Act impone obblighi di trasparenza per sistemi di intelligenza artificiale che interagiscono con le persone, anche se non sono ad alto rischio

Quando si applica:

• Il sistema di IA interagisce con un essere umano (es. chatbot, assistenti vocali, avatar).
• Il sistema genera contenuti (es. testo, immagini, audio) apparentemente umani.
• Il sistema è usato per rilevare emozioni o inferire caratteristiche personali (es. età, sesso, stato emotivo).

Nel loro complesso, gli obblighi di trasparenza dell’AI Act perseguono un obiettivo fondamentale: garantire che le persone siano sempre consapevoli dell’origine artificiale dell’interazione o del contenuto quando tale origine può incidere sulla loro capacità decisionale.

La trasparenza si configura dunque non solo come requisito tecnico o informativo, ma come presupposto essenziale per la tutela dell’autonomia individuale, della fiducia e della correttezza dell’ecosistema informativo.

Codice di buone pratiche sulla trasparenza dei contenuti generati dall'IA

La Commissione europea ha pubblicato il 10 giugno 2026 la versione definitiva del Codice di buone pratiche in materia di marcatura ed etichettatura dei contenuti generati dall’IA (comunicato IP/26/1328), uno strumento volontario che definisce misure pratiche per aiutare i fornitori e gli utilizzatori di sistemi di IA generativa ad adempiere agli obblighi di trasparenza previsti dall’art. 50 dell'AI Act, applicabili dal 2 agosto 2026. L’8 luglio 2026 la Commissione ha concluso che il codice copre adeguatamente gli obblighi dell’art. 50, parr. 2, 4 e 5, e il giorno successivo il Comitato europeo per l’intelligenza artificiale ha adottato la propria valutazione di adeguatezza. Il codice è distinto dal Codice di buone pratiche per i modelli di IA per finalità generali, pubblicato il 10 luglio 2025, richiamato al § 5.5.

Il codice di buone pratiche sostiene il rispetto degli obblighi di trasparenza previsti dal Regolamento (UE) 2024/1689 (AI Act) relativi alla marcatura e all'etichettatura dei contenuti generati dall'IA. Aiuta i fornitori e gli operatori di sistemi di IA generativa a rispettare gli obblighi della legge sull'IA in materia di etichettatura e marcatura dei contenuti generati dall'IA (articolo 50, paragrafi 2, 4 e 5, della legge sull'IA). Sebbene l'adesione al codice sia volontaria, i requisiti di trasparenza previsti dall'articolo 50 della legge sull'IA costituiscono obblighi giuridici.

Consulta il Codice di buone pratiche sulla trasparenza dei contenuti generati dall'IA di cui vi riportiamo un estratto

https://ec.europa.eu/newsroom/dae/redirection/document/129555

5.4.1 Lista di controllo pratica

Tutte le organizzazioni

• Effettuare un inventario di tutti i sistemi di IA in uso all’interno dell’organizzazione e identificare quelli che rientrano nell’ambito di applicazione dell’articolo 50.
• Verificare se si applicano eventuali esenzioni o deroghe.
• Monitorare l'attuazione del Codice di buone pratiche sui contenuti generati dall'IA e le Linee guida della Commissione.
• Richiedere contrattualmente la conformità ai fornitori di IA.
• Tenere conto dell’obbligo di alfabetizzazione in materia di IA (art. 4 AI Act, nel testo sostituito dal regolamento (UE) 2026/1744): vale per i fornitori e i deployer di qualunque sistema di IA, indipendentemente dal livello di rischio, e si applica dal 2 febbraio 2025.

Fornitori

• Per i sistemi che interagiscono direttamente con le persone, garantire una chiara informativa sull'IA al momento della prima interazione, in modo da soddisfare i requisiti di accessibilità.
• Per i sistemi di IA generativa (inclusa la GPAI), implementare una marcatura leggibile da macchina dei risultati sintetici in tutte le modalità (audio, immagine, video, testo).

Deployer

• Per il riconoscimento delle emozioni o la categorizzazione biometrica, vagliare ogni caso d’uso alla luce del divieto dell’articolo 5 prima di considerare la divulgazione ai sensi dell’articolo 50, paragrafo 3.
• Per gli usi consentiti, progettare meccanismi di notifica che informino le persone interessate in forma chiara e distinguibile.
• Per i sistemi in grado di generare deepfake, mappare tutti i casi d'uso che producono contenuti di immagine, audio o video che potrebbero rientrare nella definizione di “deepfake” e progettare un'informativa adeguata.
• Inventariare i risultati testuali pubblicati e identificare quelli pubblicati con lo scopo di informare il pubblico su questioni di interesse pubblico. Per i testi che rientrano nell'ambito di applicazione, attuare l'informativa o stabilire il processo di revisione umana e responsabilità editoriale per avvalersi dell'esclusione.

Trasparenza tecnica per i sistemi ad Alto Rischio (Art. 13)

Per i sistemi di IA ad alto rischio (es. quelli usati nella selezione del personale, nei dispositivi medici o nella valutazione del credito), la trasparenza serve a garantire tracciabilità e controllo:

• Documentazione tecnica: Deve essere redatta prima dell'immissione sul mercato e mantenuta aggiornata. Include l'architettura del modello, le logiche di funzionamento e i sistemi di calcolo. (Art. 11 si veda https://ai-act-service-desk.ec.europa.eu/it/ai-act/article-11; allegato IV, «Documentazione tecnica di cui all'articolo 11»)
• Istruzioni per l'uso: I fornitori devono fornire agli utilizzatori (aziende e professionisti) un manuale chiaro, dettagliato e comprensibile sulle capacità e i limiti del sistema.
• Registrazione: Alcune categorie di IA ad alto rischio devono essere registrate in una banca dati pubblica dell'UE gestita dalla Commissione Europea.

5.5 Obblighi di Trasparenza dei Modelli di IA

Trasparenza per i modelli di IA per finalità generali

(General Purpose AI)

I modelli di IA per finalità generali (GPAI) sono alla base di molti sistemi di IA diversi. Per garantire un'IA sicura e trasparente, il Regolamento (UE) 2024/1689 (AI Act) stabilisce obblighi per tutti i fornitori di modelli GPAI e obblighi aggiuntivi per i fornitori dei modelli più avanzati o ad alto impatto (ossia modelli GPAI con rischio sistemico). Tali obblighi si applicano dal 2 agosto 2025 (per i modelli immessi sul mercato prima di tale data, entro il 2 agosto 2027); le sanzioni dell’art. 101 si applicano dal 2 agosto 2026.

Segui gli “Obblighi in materia di IA per finalità generali a norma del Regolamento (UE) 2024/1689 (AI Act)” facendo riferimento al sito della CE:

https://digital-strategy.ec.europa.eu/it/factpages/general-purpose-ai-obligations-under-ai-act

Per adempire ai tuoi obblighi di trasparenza compila questo documento. Il testo condiviso è tratto dal GPAI Code of Practice (versione finale, 10 luglio 2025), Capitolo Trasparenza, Measure 1.1. Si tratta del modello che i fornitori di modelli di IA per uso generale (GPAI) aderenti al Codice possono utilizzare per dimostrare conformità agli obblighi di documentazione previsti dall'Art. 53(1)(a)(b) AI Act.

La pagina ufficiale con tutti i PDF scaricabili (Code of Practice completo + Model Documentation Form) è: https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai

Note importanti

• Il Form non si applica ai fornitori di modelli rilasciati con licenza libera e open source i cui parametri sono resi pubblici, a meno che il modello presenti rischio sistemico (Art. 53(2) AI Act).
• Le informazioni devono essere aggiornate e conservate per 10 anni dopo la messa sul mercato.
• Il Capitolo Trasparenza comprende 3 misure: 1.1 (documentazione), 1.2 (comunicazione delle informazioni ai fornitori a valle e all'Ufficio per l'IA), 1.3 (qualità e integrità).