Treviso vieta ChatGPT in Comune: giusto per i dati sensibili, ma la governance non può fermarsi lì

Il 6 settembre 2026 la giunta del Comune di Treviso ha approvato un regolamento sull'uso dell'intelligenza artificiale negli uffici comunali, restringendo l'impiego di strumenti di IA generativa pubblici — ChatGPT in testa — per la gestione di dati sensibili, pratiche e procedimenti sanzionatori. Treviso è tra i primi comuni italiani a normare la materia in modo esplicito. È una notizia locale, ma la logica che la regge riguarda qualsiasi organizzazione, pubblica o privata, che oggi si trova a dover decidere cosa fare con l'IA generativa.

La motivazione dichiarata è chiara e, nella sostanza, condivisibile: secondo l'assessore competente, "il pericolo era di violare la privacy". Un dipendente comunale che incolla in una chat pubblica il testo di un procedimento sanzionatorio, o i dati di un cittadino coinvolto in una pratica delicata, sta trasferendo informazioni personali — a volte particolari, ai sensi dell'art. 9 del GDPR — a un sistema di terzi di cui l'ente non controlla le condizioni di trattamento, la conservazione, l'eventuale uso per addestramento. Non serve immaginare uno scenario estremo per capire il rischio: basta la prassi quotidiana di chi usa uno strumento comodo senza sapere cosa succede ai dati che vi inserisce.

Di fronte a questo rischio, la risposta di Treviso è stata il divieto. Ed è importante dirlo subito, senza ambiguità: non è una scelta sbagliata. È uno dei trattamenti del rischio previsti dagli standard di risk management, ed è quello più radicale.

Il divieto è un trattamento del rischio, non un errore

Gli standard di riferimento — ISO 31000 sulla gestione del rischio, ISO/IEC 27005 per la sicurezza delle informazioni — elencano alcune strade per trattare un rischio: si può mitigarlo, trasferirlo, accettarlo consapevolmente, oppure eliminarlo. L'eliminazione rimuove l'asset che porta con sé il rischio — e con esso, inevitabilmente, anche i benefici delle funzioni che quell'asset offriva. Un Comune che decide che nessun dipendente può incollare il testo di un procedimento sanzionatorio in una chat pubblica non sta improvvisando: sta scegliendo l'eliminazione per una categoria di dati dove il rischio è alto, concentrato, e dove è difficile immaginare un beneficio che lo giustifichi.

Il problema non è quindi il divieto in sé. È trattarlo come l'unico trattamento disponibile, applicato indistintamente a ogni dato e a ogni processo, invece che come una delle opzioni da scegliere caso per caso in base al livello di rischio della singola categoria di informazioni.

Un solo trattamento non basta per tutti i rischi

L'eliminazione ha un costo che gli altri trattamenti non hanno: la rinuncia totale ai benefici. Ha senso quando il rischio è alto e concentrato, come nel caso dei procedimenti sanzionatori. Ma la maggior parte del lavoro d'ufficio non riguarda dati di quel livello: sintetizzare un documento pubblico, riformulare una comunicazione generica, cercare un riferimento normativo sono attività a rischio molto più basso — e lì l'eliminazione totale butta via un beneficio reale per un rischio marginale.

Per queste attività il trattamento più adatto non è l'eliminazione, è la mitigazione: ridurre il rischio a un livello accettabile mantenendo il beneficio, tramite un framework che risponda sempre alla stessa domanda — quali dati, verso quale sistema, con quali garanzie— indipendentemente da quale strumento specifico sia in discussione oggi. Non un elenco di strumenti vietati, che invecchia più in fretta di quanto un ente riesca ad aggiornarlo (ChatGPT oggi, Gemini in Workspace e Copilot in Office domani), ma una griglia che classifica i dati e assegna a ciascuna categoria il trattamento coerente. È l'impianto su cui è costruita la ISO/IEC 42001, la norma di riferimento per i sistemi di gestione dell'intelligenza artificiale, e che nella pratica si traduce in poche misure concrete:

• Classificazione dei dati. Sapere, prima ancora di scegliere uno strumento, quali informazioni sono pubbliche, quali sono personali, quali sono personali particolari o coperte da segreto d'ufficio. Senza questa mappa, ogni policy sull'IA è una lista di casi specifici che qualcuno prima o poi dimenticherà di aggiornare.
• Verifica contrattuale dei fornitori (DPA). Un fornitore di IA con cui l'ente ha un accordo di trattamento dati (Data Processing Agreement), clausole di non-addestramento sui dati inseriti e residenza dei dati in UE offre garanzie che uno strumento consumer gratuito, per definizione, non offre. La differenza non è tra "AI sì" e "AI no": è tra un fornitore con cui l'ente ha un rapporto contrattuale verificabile e uno con cui non ce l'ha.
• Minimizzazione. Anche con uno strumento autorizzato, l'abitudine corretta è inserire il minimo indispensabile: anonimizzare o pseudonimizzare dove possibile, evitare di incollare interi fascicoli quando basta un estratto.
• Audit log e responsabilità. Sapere chi ha usato quale strumento, per fare cosa, su quali dati — non per controllo repressivo, ma perché in caso di incidente serve poter ricostruire cosa è successo, ed è un requisito che il GDPR chiede comunque in termini di accountability.
• Formazione mirata. La maggior parte degli incidenti da IA generativa non nasce da malafede, ma da chi non sa che quello che sta facendo è un problema. Una formazione breve e concreta su "cosa non va mai inserito in una chat pubblica" riduce il rischio più di molti regolamenti.

Nessuna di queste misure richiede di rinunciare ai benefici dell'IA generativa. Tutte richiedono di smettere di trattare la questione come binaria.

Cosa può fare un ente (o una PMI) oggi

Il punto non è dire che Treviso ha sbagliato: sui dati più sensibili l'eliminazione è probabilmente il trattamento giusto. Il punto è se quello stesso trattamento verrà esteso, per comodità normativa, anche alle attività a basso rischio — email di routine, bozze di comunicati, ricerche bibliografiche — dove costa più di quanto protegga. Un divieto generalizzato che non distingue tra categorie di rischio, prima o poi, produce lo stesso effetto collaterale ovunque si presenti: chi ha davvero bisogno dello strumento per un uso a basso rischio lo userà comunque, da un dispositivo personale, fuori da qualunque visibilità dell'ente — la condizione peggiore possibile per la protezione dei dati, perché somma il rischio originario all'assenza totale di controllo.

Un'organizzazione matura applica trattamenti diversi a rischi diversi: elimina dove il rischio è alto e concentrato, mitiga con un framework dove il rischio è basso e diffuso e i benefici sono reali. Il percorso più solido parte dalla mappa dei dati trattati e dal livello di rischio di ciascuna categoria — non da "quale strumento vietare o permettere in blocco". Da lì derivano naturalmente i trattamenti: eliminazione per i dati ad alto rischio, mitigazione via framework per il resto. Ed è un lavoro che si fa una volta e resta valido indipendentemente da quale nuovo assistente IA arriverà il mese prossimo.

Fonti

• Comune di Treviso, delibera di giunta, 6 settembre 2026, regolamento sull'uso dell'intelligenza artificiale negli uffici comunali (testo integrale non pubblicamente disponibile alla data di scrittura).
• Tribuna di Treviso — Uso dell'Ai in Comune, stop ai software gratuiti: «Dati sensibili a rischio», 6 settembre 2026.
• Corriere del Veneto — Intelligenza artificiale, Treviso è uno dei primi comuni a vietare l'uso di ChatGPT, 5-6 settembre 2026 (fonte della notizia; testo integrale non accessibile in fase di redazione).
• Regolamento (UE) 2016/679 (GDPR), art. 9 (categorie particolari di dati).
• ISO/IEC 42001:2023 — Sistema di gestione dell'intelligenza artificiale.