Negli enti l’intelligenza artificiale è già entrata, e quasi mai da una porta principale. Un assistente documentale attivato in un ufficio, uno strumento di sintesi incluso in una suite già in uso, un modulo di classificazione delle istanze fornito dall’attuale gestore del protocollo. Nessuno di questi passaggi ha attraversato un’istruttoria: sono arrivati come funzionalità, non come sistemi.

Il problema che ne deriva non è l’uso in sé. È che quando l’ente deve rispondere — a un interessato, al Garante, a un ricorso — non è in grado di ricostruire chi ha deciso, sulla base di quale valutazione e con quale presidio.

Il regolamento interno serve a questo: non a vietare, ma a rendere l’adozione un atto tracciabile con un responsabile.

Chi deve adottare il regolamento e con quale atto?

L’adozione segue la normale competenza organizzativa dell’ente. Nei Comuni è tipicamente una delibera di Giunta su proposta del Segretario generale o del responsabile della transizione digitale; negli enti sanitari una deliberazione del Direttore generale; negli enti strumentali un atto dell’organo di amministrazione.

La forma conta meno della sostanza istruttoria. Un regolamento adottato senza il coinvolgimento del DPO, del responsabile della transizione digitale e delle strutture che l’IA la useranno produce un testo che nessuno applicherà. Il coinvolgimento del DPO nella fase di costruzione non è formalità: è la funzione che conosce dove il trattamento si incrocia con il sistema.

Quali obblighi ha un ente pubblico che usa sistemi di IA?

L’ente pubblico che acquista e utilizza un sistema di IA è, nella quasi totalità dei casi, un deployer ai sensi del Regolamento (UE) 2024/1689 — l’AI Act — e non un fornitore. La distinzione è decisiva perché determina quali obblighi si applicano.

Gli obblighi del deployer riguardano l’uso: verificare la conformità del sistema prima di metterlo in esercizio, garantire una supervisione umana effettiva, assicurare che i dati immessi siano adeguati alla finalità, segnalare gli incidenti seri.

Su questo si sovrappone il ruolo di titolare del trattamento ai sensi del Regolamento (UE) 2016/679 — il GDPR. Lo stesso ente è quindi simultaneamente deployer sotto l’AI Act e titolare sotto il GDPR, con due catene di obblighi che si intersecano. Il regolamento interno è il luogo dove quella doppia veste viene assegnata a funzioni identificate, invece di restare implicita.

Va aggiunto un punto che gli enti sottovalutano: l’AI Act prevede per i deployer pubblici di sistemi ad alto rischio una valutazione d’impatto sui diritti fondamentali, distinta dalla DPIA. Sono due processi separati, con fondamenti e oggetti diversi. Chi produce un documento unico non soddisfa né l’uno né l’altro.

Cosa deve contenere il regolamento?

Il contenuto utile è procedurale. Un regolamento che elenca principi — trasparenza, non discriminazione, centralità della persona — e si ferma lì non governa nulla: nessuno viene messo in condizione di fare qualcosa di diverso da prima.

Gli elementi che reggono:

Ambito e definizione. Cosa l’ente considera sistema di IA ai fini del regolamento. Senza questo, ogni discussione futura diventa una discussione sul perimetro.

Registro dei sistemi di IA. Un elenco dei sistemi in uso con finalità, struttura utilizzatrice, fornitore, classificazione di rischio, referente interno. È il documento che permette di rispondere alla prima domanda di qualsiasi verifica: cosa avete in funzione.

Procedura di adozione. Chi può proporre l’introduzione di un sistema, quale istruttoria è obbligatoria prima dell’attivazione, chi autorizza. Il punto critico è collocare la valutazione prima della messa in esercizio: una DPIA redatta a sistema già attivo non mitiga il rischio, lo certifica.

Classificazione del rischio. Il momento in cui l’ente verifica se il sistema ricade tra quelli ad alto rischio ai sensi dell’AI Act. Per gli enti pubblici questa verifica è tutt’altro che teorica: l’accesso a servizi pubblici essenziali, la gestione del personale e i sistemi biometrici rientrano nelle categorie ad alto rischio dell’Allegato III.

Supervisione umana. Non l’affermazione che esiste, ma l’indicazione di chi la esercita, con quale competenza e con quale potere. Una supervisione umana priva del potere di sospendere il sistema non è supervisione.

Uso dell’IA generativa da parte del personale. È il caso più frequente e meno regolato. Cosa può essere inserito in un prompt, cosa no, quali strumenti sono ammessi, cosa succede ai dati immessi.

Monitoraggio e riesame. Con quale periodicità i sistemi in esercizio vengono rivalutati, e cosa attiva un riesame straordinario. Un sistema che si comporta diversamente dopo sei mesi non è più il sistema descritto nella valutazione iniziale.

Responsabilità e formazione. Chi risponde di cosa, e chi deve essere formato prima di poter utilizzare determinati sistemi.

Il regolamento sostituisce la DPIA?

No, e la confusione è frequente. Il regolamento è un atto organizzativo generale: stabilisce il processo. La DPIA è una valutazione su uno specifico trattamento, obbligatoria quando ricorrono le condizioni previste dall’art. 35 del GDPR.

Il rapporto tra i due è di innesco: il regolamento definisce in quale momento della procedura la DPIA va condotta, chi la conduce, chi la valida e chi la aggiorna. Senza regolamento, la DPIA arriva quando arriva — cioè spesso dopo.

L’errore che rende inutile il regolamento

Un regolamento adottato e archiviato produce l’effetto opposto a quello voluto: crea la convinzione di avere governato un rischio che continua a non essere governato, e formalizza l’assenza di presidio.

Il segnale per riconoscerlo è semplice. Se sei mesi dopo l’adozione nessun sistema è stato inserito nel registro, nessuna istruttoria è stata avviata e nessuna struttura ha chiesto un’autorizzazione, il regolamento non sta funzionando. Non perché sia scritto male, ma perché non è stato collegato ai processi reali dell’ente — l’acquisto, l’attivazione di una nuova funzionalità, il rinnovo contrattuale con un fornitore.

Da dove partire

L’ordine che funziona negli enti è questo: prima la ricognizione di ciò che è già in uso, poi il regolamento, poi le valutazioni sui singoli sistemi.

Scrivere il regolamento senza sapere cosa l’ente sta già utilizzando produce un testo teorico. La ricognizione, di solito, restituisce un numero superiore alle attese — ed è già di per sé l’informazione più utile che l’ente ottiene in tutto il percorso.

La domanda con cui misurare il risultato non è se l’ente ha un regolamento. È: se domani una struttura volesse attivare un nuovo sistema di IA, saprebbe a chi rivolgersi e cosa deve produrre prima di partire?


Ivano Pecis
DPO/RPD — Advisor in Governance, Privacy & Compliance
I&P Partners — Milano | ivano.pecis@partnerprivacy.it