After 15 years selling and building technology for enterprises and public administrations, I've learned that AI projects almost never fail in the demo. They fail afterwards, for reasons that have little to do with the model.

Introduction

I have sat through hundreds of technology demos. Servers, storage, cloud, cybersecurity, and now AI agents. And I can count on one hand the projects that failed because the technology didn't work.

AI is no exception. The demo is almost always impressive. The agent answers questions, summarises documents, drafts responses. Everyone in the room nods.

Then, six months later, the project is still a pilot. Or it went live and nobody uses it. Or it's stuck waiting for a tender, a data agreement, or a legal opinion.

When that happens, the first reaction is often to blame the model: "it hallucinates", "it's not accurate enough", "maybe we need a better one". In my experience, that's rarely the real problem. Models improve every few months. The obstacles I see in the public sector are much older, and much more human.

Here are the ones I see most often.

1. Fragmented Data

Every public administration I've worked with has enormous amounts of data. The problem is that it lives in silos: one application per office, one database per procedure, decades of legacy systems, documents in shared folders, knowledge in people's heads.

An AI agent is only as good as what it can reach. If the agent can't see the case status, it can't tell the citizen where their request is. If the knowledge base is outdated, the agent will confidently give outdated answers.

This is where my infrastructure background makes me almost stubborn: AI doesn't fix messy data. It amplifies it. A fragmented data landscape with an AI layer on top doesn't become intelligent. It becomes faster at being confused.

The administrations that succeed usually did the unglamorous work first: unifying channels, cleaning the knowledge base, connecting systems, deciding who owns which data.

2. Starting From the Technology, Not the Problem

"We need a chatbot." "We need to do something with AI."

I hear these sentences often, and I understand them. There is pressure to innovate, and AI is visible. But a project that starts from a technology instead of a problem has no clear way to measure success, and without that, it rarely survives its first budget review.

The better starting point is always a concrete pain:

  • Citizens wait too long for an answer on their case.
  • Our staff spend half their day answering the same ten questions.
  • Requests get lost between offices.

From there, the AI becomes a means, not the goal. And you can measure it: response times, cases resolved at first contact, hours given back to staff.

This is also how projects escape pilot purgatory: the endless proof of concept that works, impresses, and never reaches production because nobody defined what "success" meant at the start.

3. The Organisation Doesn't Change

Introducing an AI agent changes who does what. Who answers the citizen first? Who handles the cases the agent can't solve? Who updates the knowledge base when a regulation changes? Who owns the agent itself?

If the organisation doesn't answer these questions, the technology fills the gap badly. The agent escalates cases to an office that doesn't know it's supposed to handle them. The knowledge base goes stale because updating it is nobody's job.

The best summary I've read of this comes from the team at the Comune di Genova, describing their citizen relationship platform: "It wasn't enough to adopt the best technology; we had to rethink the organisation to solve thousands of problems."

That sentence should be printed on the first slide of every public sector AI project.

4. Change Management Is an Afterthought

Public servants are often skeptical of new tools, and frankly, they have good reasons. Many have lived through "transformations" that added work instead of removing it.

With AI there is an extra layer: fear. Will this replace me? Will I be blamed if it makes a mistake?

Projects fail when these concerns are ignored, or handled with a single training session the week before go-live. They succeed when staff are involved from the beginning: helping define what the agent should and shouldn't do, testing it, pointing out its mistakes, seeing their workload actually improve.

The same applies to citizens. An assistant nobody knows about, or nobody trusts, won't be used. Communication isn't a detail of the project. It's part of the project.

5. Procurement Moves Slower Than AI

This is the part I know best, after years of tenders, framework agreements, and long contracts.

Public procurement was designed for a world where you buy a defined thing, with a defined specification, for a defined period. That works well for servers. It works less well for AI, where:

  • The models and capabilities change every few months.
  • The value is discovered while using the system, not fully known in advance.
  • Costs are often based on consumption, while public budgets are planned annually.

The result is a familiar pattern: by the time a tender is written, published, awarded, and contracted, the specification describes a technology that has already moved on.

There are also real risks on the other side, like vendor lock-in. It's no coincidence that AgID's draft guidelines on AI procurement focus on open standards, model portability, data ownership, and audit rights, and propose a cost metric across the whole lifecycle.

From my side of the table, I've learned that the best procurement for AI:

  • Buys outcomes and capabilities, not a frozen list of features.
  • Includes a clear path from pilot to scale, so success doesn't require a new tender.
  • Protects the administration's data and freedom to change supplier or model.

6. Skills and Training Are Underestimated

Most AI projects budget for licences and implementation. Very few budget seriously for skills.

Yet the law points clearly in this direction. Since February 2025, the EU AI Act's AI literacy provision (art. 4) has applied to providers and deployers, public bodies included. The Digital Omnibus has since softened its wording into a duty to take measures to support AI literacy, rather than to ensure it, but the expectation remains. In Italy, Law 132/2025 (art. 14.3) asks public administrations to adopt technical, organisational, and training measures for a responsible use of AI and to develop users' skills.

There's a catch: art. 14.4 also says this must happen with existing resources. So training can't be a separate, expensive programme that arrives "later". It has to be built into the project itself: in the interface, in the onboarding, in the daily work with the agent.

Training also isn't only for the people using the agent. Managers need to understand what AI can and can't do, so they can set realistic goals. Procurement officers need to know what to ask for. Legal and DPO teams need enough technical understanding to give useful advice early, not blocking advice late.

7. Compliance Arrives at the End

A pattern I've seen too many times: the project team builds a solution, and then asks legal, the DPO, and security for approval. They find issues, the project stops, and everyone is frustrated.

With AI in the public sector, the questions are predictable: personal data and GDPR, transparency towards citizens (now required by Article 50 of the AI Act), the supporting-only role of AI and human responsibility under Law 132/2025, security, accessibility.

None of these are surprises. So they shouldn't arrive as surprises. Compliance by design means having those people in the room from the first workshop, and turning their requirements into design choices, not into late-stage blockers.

So Where Does the Model Fit?

The model matters, of course. Accuracy, cost, language quality, and where data is processed are all real decisions.

But in my experience, the model is the part of the project that improves on its own. Every few months there is a better, cheaper, faster option. Data, organisation, skills, and procurement don't improve on their own. They improve only when someone takes responsibility for them.

That's why I've stopped asking "which model?" as the first question. The first questions are: what problem, which data, who owns it, and how will we know it worked?

What Works: A Short Playbook

If I had to summarise what I've seen work in the public sector:

  1. Start from one concrete citizen or staff problem, with a measurable goal.
  2. Fix the data needed for that problem first, not all the data in the organisation.
  3. Go small, but go to production. A narrow use case in real use beats a broad pilot in a sandbox.
  4. Involve staff from day one, and show them how their work gets better.
  5. Bring legal, DPO, and security in at the start, not at the end.
  6. Procure for evolution: outcomes, a path to scale, data portability.
  7. Build training into the project, not next to it.
  8. Measure, publish, iterate. Share results internally and with citizens. Success builds trust, and trust builds adoption.
  9. Find a sponsor at the top. Every successful project I've seen had someone senior who protected it.

A Note From the Sales Side

I'll end with something I've learned as a salesperson, because it's relevant here.

Early in my career, I thought a signed contract was the finish line. It isn't. In the public sector especially, the only deal that matters is the one that gets adopted. A project that fails to reach citizens doesn't just hurt the administration; it makes the next good project harder to approve.

That means vendors have a responsibility too: not to oversell, to be honest about what the technology can and can't do, and to invest in the unglamorous parts (data, change, skills) as much as in the demo.

Conclusion

AI in the public sector has enormous potential: shorter waits, clearer answers, public servants freed from repetitive work. The technology is ready. The models are good, and getting better.

What decides success is everything around the model.

AI projects in the public sector rarely fail because the machine isn't smart enough. They fail because the organisation around it wasn't ready to change.

The good news is that every one of these obstacles is solvable. None of them requires a breakthrough in artificial intelligence. They require something harder, and more human: leadership, patience, and the willingness to change how we work.

Sources: