Why the AI in most public-sector asset management software is still on the roadmap

Walk the vendor hall at any public works conference this year and you will see the word “AI” on nearly every backdrop. Ask the person at the booth to show it running — on live records, in the version their customers are using today — and the conversation changes. It’s coming next release. It’s in beta with a few agencies. It’s on the roadmap. The gap between the banner and the demo has become the defining feature of the category.

That gap is not a marketing problem. It is an engineering one, and it is worth understanding why, because it determines what you can reasonably expect from the system you already own.

What a legacy CMMS actually is, underneath

The computerized maintenance management systems that dominate municipal asset management were designed in the late 1990s and 2000s. Their architecture reflects the assumptions of that era: a relational database as the center of the universe, a thick client or a server-rendered web layer on top, integrations bolted on one at a time as customers asked for them, and configuration expressed through hundreds of screens that each know a little about the schema. Two decades of customer-specific customization, acquisitions, and platform migrations sit on top of that foundation.

None of this is a criticism. It is how durable software gets built. But it has a consequence that matters now: in these systems, the data model, the permission model, and the business rules are not exposed as something a program can reason about. They are spread across stored procedures, UI code, and institutional memory. A human who has used the product for ten years can navigate it. A language model cannot — because nothing in the system was ever written to explain itself.

Why that makes real AI so hard to retrofit

Useful AI in an asset management system needs three things the legacy architecture does not naturally provide.

First, a governed way to query the data. An assistant that answers “how many hydrants have failed inspection twice in the last year” has to translate that sentence into a safe, permission-aware query against real records. If the only path to the data is a decades-old report engine or direct SQL, there is no boundary the AI can be trusted inside. Every answer becomes either a security risk or a hand-written special case.

Second, a way to act. Creating a work order is not one database insert — it is number generation, type defaults, department routing, cost lines, notification rules, audit logging, and a dozen validations that live in the application layer. If those rules exist only in the create-work-order screen, an AI cannot reuse them without re-implementing them, and re-implementing them is exactly the kind of duplication that has already made these products fragile.

Third, a way to know what it may and may not touch. Role-based permissions in older systems are frequently enforced at the screen level — this user can see this page — rather than at the data level. An assistant that bypasses the screen bypasses the permission. Getting this right retroactively means re-plumbing authorization through an entire product while customers are running on it.

The shapes “AI” takes when it is added late

Once you know what to look for, the retrofit patterns are recognizable. The most common is a help bot that answers questions from documentation — how to create a record, where a setting lives — but has no access to the records themselves. Ask it how many work orders are overdue and it tells you how to run a report. The second is a single AI-labeled feature in one corner of the product, typically a text summarizer or description generator, that is genuinely convenient and entirely disconnected from the workflow around it. The third is a separately licensed “AI module” with its own data copy, its own sync schedule, and its own answers that don’t always match the system of record.

Each of these is a rational response to technical debt. Each is also a way of putting AI on the outside of the product because putting it on the inside would mean rebuilding the product.

What it looks like when AI is the foundation instead

A platform designed with AI as a first-class concern makes different choices from the start. The data model is declared once, in a registry that both the query engine and the AI read — so a new field is queryable, chartable, and available to the assistant the moment it exists. Every business rule lives in a service the UI and the AI both call, so a record the assistant creates is indistinguishable from one a person created, because the same code made it. Permissions are enforced on data, not screens, so the assistant runs as the person using it and can never see more than they can. And every AI answer carries its provenance — the records it came from — so a supervisor can check the work rather than trust it.

This is the model CentricityIQ was built on. The assistant is not a feature that was added; it is a consumer of the same governed query engine and the same record services as every screen in the product. It answers operational questions against live data and renders the result as a number, a chart, or a table you can drill into. It creates and updates work from a sentence, with the same validations a person would hit. It builds dashboards and reports on request. It proposes configuration from your existing documents and GIS layers. And when it acts, the action is logged and reversible.

What to ask a vendor — including us

You do not need to evaluate architecture diagrams to tell the difference. Four questions do it. Can the assistant answer a question about my actual records, right now, in production? Can it create or change a record, and does that record pass the same rules as one I create by hand? Does it see only what my role allows? And does it show me where an answer came from? A vendor whose AI is foundational will say yes to all four and offer to prove it on your data. A vendor whose AI is on the roadmap will explain why next year is different.

Technical debt is not a moral failing; every long-lived product carries it. But it does set the ceiling on what a system can become, and for most legacy asset management platforms that ceiling now sits well below where the marketing points. Agencies deciding what to run for the next decade are entitled to know the difference between AI a product has and AI a product was built around.

If you want to see the built-around version working on your own GIS, ask us for a demo at centricityiq.com. We’ll show it live — the same test we’d suggest you put to anyone.