Today, a citizen who needs to renew an ID card doesn't open the municipality's website. They open ChatGPT and ask. The answer arrives in three seconds, and it is often wrong: it comes from a forum post from 2019, from a page about a different agency, from a site that copies other sites. The citizen doesn't know that and trusts it anyway.

This is happening now, not five years from now. People have already changed the way they search: they no longer scroll through ten blue links, they ask a question and expect an answer. The portal, as we know it, has already become the second choice.

The PA has realized that something has shifted, and the answer it has given so far is almost always the same: it puts a chatbot on top of its own portal. The problem isn't a lack of goodwill. It's the form.

A digital silo solves nothing

That chatbot only answers within its own agency's domain. It's a silo. It is often just FAQ automation with a coat of natural language, and above all it assumes that citizens already know which agency to contact.

But citizens don't think in terms of agencies: they think in terms of problems. "My child was just born, what do I need to do?" That question involves several administrations at once, and a chatbot bolted onto a single portal will never be able to handle it. We are building lots of little digital counters when what citizens wanted was a person to guide them.

The assistant must belong to the citizen, not the agency

The idea that flips the perspective is simple. The agency doesn't build the assistant: it exposes its own content and data so that any assistant, including the one citizens already use every day, can query them and answer by citing the source. The administration stops owning the interface and focuses on what only it can guarantee: reliable data.

It's a change of mindset before it's a change of technology. Today every agency wants its own app, its own portal, its own chatbot. Tomorrow, the agency provides a trustworthy source and lets citizens choose which tool to use to talk to it.

Two different assistants, two levels of difficulty

It's worth separating two cases, because confusing them leads to projects that don't work.

  • The first is the informational assistant: it answers general questions about procedures, requirements, and deadlines. It doesn't need to know who the citizen is. Its source is public, authoritative content: current legislation, official pages, circulars. It's the easier case and can be tackled right away.
  • The second is the personal assistant: it answers about an individual's situation, the status of a case, how much is owed, when a document expires. This requires the citizen's identity, hence SPID, CIE and, looking ahead, IT-Wallet. It touches personal data in the agency's systems, and it is much harder.

Anyone who tries to build the second right away without having solved the first is building something fragile.

The three issues nobody wants to look at

Before writing a single line of code, there are three concrete problems to address.

  • The first is hallucination. It's often said that connecting the model to reliable data is enough to get true answers. It isn't. Grounding in sources greatly reduces errors, but doesn't eliminate them: the model may answer a different question from the one asked, may forget a condition, may give the right deadline based on the wrong premise. That's why the goal isn't the true answer. The goal is the traceable answer. Every statement must be able to show where it comes from, so that errors become visible and correctable.
  • The second is accountability. If the assistant gets a deadline wrong and the citizen loses a right, who is responsible? It's the first question any executive asks, and a fair one. Without a clear answer to it, the project remains a demo forever. We need to decide up front what the assistant can say as information and what it can never say as an official act.
  • The third is identity. The personal assistant lives or dies on the level of authentication. Without a serious way to prove who the citizen is, and to limit what the assistant can see and do on their behalf, that part simply won't happen.

The principle matters more than the brand

The assistant queries certified sources through an open protocol. Today that protocol has a name that is gaining traction, MCP, and it lets an assistant talk to external tools and data in a standard way. It's the example of the moment, but we shouldn't tie the PA to a brand: what matters is the principle, namely an open standard that anyone can build on.

A clarification on a point that's easy to get wrong. PDND, as of today, is not built to be the source the assistant queries. PDND does its job elsewhere and does it well: it allows one agency to use another agency's data without bilateral agreements. It works behind the scenes, in the personal path, when answering requires data that lives in another administration. It's plumbing between agencies, not the interface toward citizens. Nothing prevents it from evolving in that direction: the trust infrastructure it has built is exactly the kind of foundation on which the assistant could one day rest as well.

What to do now

The concrete thing to do isn't yet another agency chatbot. It's to expose content and data in a structured, versioned, signed, and queryable way: make the official source readable by a machine even before it's readable by a person.

Compose instead of build. The citizen's assistant is composition: it brings together sources that already exist and makes them useful. The agency chatbot is yet another thing built from scratch, that half works and gets thrown away in two years.

Citizens have already stopped opening the portal. The question isn't whether to build the assistant. The question is whether the answers they receive will come from a reliable source or from a random site found in three seconds.