Back to Blog

Treviso bans ChatGPT in city hall: right for sensitive data, but governance can't stop there

·5 min read
An isometric city hall behind a closed barrier blocking an AI chat icon, with a professional figure looking on thoughtfully — representing a ban with no governance framework behind it

On 6 September 2026 the city council of Treviso approved a regulation on the use of artificial intelligence in municipal offices, restricting the use of public generative AI tools — ChatGPT first among them — for handling sensitive data, case files and sanctioning procedures. Treviso is among the first Italian municipalities to legislate explicitly on the matter. It is a local story, but the logic behind it applies to any organisation, public or private, currently deciding what to do about generative AI.

The stated reason is clear and, on its face, reasonable: according to the responsible councillor, "the danger was violating privacy." A municipal employee who pastes the text of a sanctioning procedure, or the data of a citizen involved in a sensitive case, into a public chat tool is transferring personal data — at times special category data under Article 9 GDPR — to a third-party system whose processing terms, retention and possible use for training the municipality does not control. No extreme scenario is needed to see the risk: the everyday habit of using a convenient tool without knowing what happens to the data typed into it is enough.

Faced with that risk, Treviso's response was a ban. And it is worth saying plainly, with no ambiguity: this is not the wrong call. It is one of the risk treatments provided for by risk-management standards, and the most radical one.

A ban is a risk treatment, not a mistake

Reference standards — ISO 31000 on risk management, ISO/IEC 27005 for information security — list a handful of ways to treat a risk: mitigate it, transfer it, knowingly accept it, or eliminate it. Elimination removes the asset that carries the risk — and with it, inevitably, the benefits of the functions that asset provided. A municipality deciding that no employee may paste the text of a sanctioning procedure into a public chat is not improvising: it is choosing elimination for a category of data where the risk is high and concentrated, and where it is hard to picture a benefit that would justify keeping it.

The problem, then, is not the ban itself. It is treating it as the only available treatment, applied indiscriminately to every piece of data and every process, instead of as one option to be chosen case by case based on the risk level of the specific data category.

One treatment isn't enough for every risk

Elimination carries a cost the other treatments do not: giving up the benefit entirely. That makes sense when the risk is high and concentrated, as with sanctioning procedures. But most office work does not involve data at that level: summarising a public document, rephrasing a generic communication, looking up a regulatory reference are much lower-risk activities — and there, total elimination throws away a real benefit for a marginal risk.

For these activities the right treatment is not elimination, it is mitigation: reducing the risk to an acceptable level while keeping the benefit, through a framework that always answers the same question — which data, to which system, under which guarantees — regardless of which specific tool is under discussion today. Not a list of banned tools, which goes stale faster than any organisation can keep it updated (ChatGPT today, Gemini in Workspace and Copilot in Office tomorrow), but a grid that classifies data and assigns the matching treatment to each category. This is the logic behind ISO/IEC 42001, the reference standard for AI management systems, and in practice it comes down to a handful of concrete measures:

  • Data classification. Knowing, before even choosing a tool, which information is public, which is personal, which is special-category personal data or covered by official secrecy. Without this map, any AI policy is a list of specific cases that someone will eventually forget to update.
  • Contractual vetting of vendors (DPA). An AI vendor with whom the organisation has a Data Processing Agreement, no-training clauses on submitted data, and EU data residency offers guarantees that a free consumer tool, by definition, does not. The line is not between "AI yes" and "AI no": it is between a vendor with a verifiable contractual relationship and one without.
  • Minimisation. Even with an authorised tool, the right habit is to input the minimum necessary: anonymise or pseudonymise where possible, avoid pasting an entire case file when an excerpt will do.
  • Audit logging and accountability. Knowing who used which tool, for what, on which data — not for punitive control, but because in the event of an incident it must be possible to reconstruct what happened, which GDPR already requires in terms of accountability.
  • Targeted training. Most generative-AI incidents do not stem from bad faith but from people who do not know that what they are doing is a problem. Short, concrete training on "what should never go into a public chat" reduces risk more than most regulations do.

None of these measures requires giving up the benefits of generative AI. All of them require treating the question as something other than binary.

What a public body — or an SME — can do today

The point is not that Treviso got it wrong: for the most sensitive data, elimination is probably the right treatment. The point is whether that same treatment will be extended, for regulatory convenience, to low-risk activities too — routine emails, draft press releases, literature searches — where it costs more than it protects. A blanket ban that does not distinguish between risk categories eventually produces the same side effect wherever it shows up: whoever genuinely needs the tool for a low-risk use will use it anyway, from a personal device, entirely outside the organisation's visibility — the worst possible outcome for data protection, since it adds a total lack of control on top of the original risk.

A mature organisation applies different treatments to different risks: it eliminates where the risk is high and concentrated, and mitigates through a framework where the risk is low and diffuse and the benefits are real. The more solid path starts from the map of the data the organisation handles and the risk level of each category — not from "which tool to ban or allow across the board." The treatments follow naturally from there: elimination for high-risk data, framework-based mitigation for the rest. And it is work done once that remains valid regardless of which new AI assistant shows up next month.

Sources

  • Municipality of Treviso, city council resolution, 6 September 2026, regulation on the use of artificial intelligence in municipal offices (full text not publicly available at the time of writing).
  • Tribuna di Treviso — Uso dell'Ai in Comune, stop ai software gratuiti: «Dati sensibili a rischio», 6 September 2026.
  • Corriere del Veneto — Intelligenza artificiale, Treviso è uno dei primi comuni a vietare l'uso di ChatGPT, 5-6 September 2026 (source of the story; full text not accessible at drafting time).
  • Regulation (EU) 2016/679 (GDPR), Art. 9 (special categories of personal data).
  • ISO/IEC 42001:2023 — Artificial intelligence management system.

A risk treatment for every data category, not one for all of them

We help public bodies and SMEs build an AI risk-management framework aligned with ISO/IEC 42001 and GDPR — data classification, choosing the right treatment (elimination, mitigation, transfer, acceptance), vendor vetting, audit and training.

Talk to us →