The AI Feature Is Not the Product

A fire chief and an officer reviewing a laptop across a station table with a skeptical eye

Every public safety software company now describes itself as AI-powered. I say it about some of my own products, so I am not throwing stones from outside the glass house.

But the phrase has stopped meaning much. It shows up on splash pages, in RFP responses and in sales decks whether the underlying system runs a large language model, a basic rules engine written five years ago, or nothing more than a search bar with a new label.

Chiefs and administrators are being asked to evaluate a claim that vendors themselves are not always being precise about. That is a problem, because the decision in front of you is not really about AI. It is about whether a specific capability solves a specific problem in your department, reliably, and at a cost you understand.

Here is how I would take that claim apart before I believed it.

Ask What It Actually Does, In One Sentence

Do not accept "AI-powered scheduling" or "AI-driven reporting" as an answer. Ask the vendor to finish this sentence: "Our AI looks at __ and produces __."

A vendor who has a real capability can answer that in ten seconds. Something like: "It looks at certification expiration dates, shift history and staffing minimums, and produces a ranked list of members eligible to fill an open shift."

A vendor who is stretched can only answer in adjectives. "It intelligently optimizes your workflow" is not an answer. It is a sentence built to sound like one.

If you cannot get a concrete input and a concrete output, you have not found an AI feature. You have found a marketing decision.

Find Out What Kind Of AI It Actually Is

"AI" now covers several very different things, and the difference matters more than the label.

Some of it is a large language model, the kind of technology behind the general-purpose chat tools everyone has heard of, applied to a narrow task like summarizing an incident narrative or answering a question about a policy document.

Some of it is a classic rules engine or decision tree, the same logic that has existed in software for decades, wearing a new name because "if this, then that" does not sell as well as "AI-powered" in 2026.

Some of it is genuine machine learning, a model trained on historical data to predict something, like which members are at risk of lapsing or which apparatus is trending toward a maintenance issue.

And some of it is a thin wrapper around a general AI service, where the vendor's real contribution is the interface and the prompt, not anything proprietary underneath.

None of these are automatically bad. A well-built rules engine can be more reliable than a model, precisely because it is predictable. But you should know which one you are buying, because each carries different risks around accuracy, explainability and what happens when it is wrong.

Ask What Happens When It Is Wrong

This is the question that separates a serious vendor from a marketing page.

AI-driven features, especially anything built on a language model, will occasionally produce an answer that is confident, well-formatted and incorrect. That is true of the best systems available anywhere, not just smaller public safety vendors. The question is not whether that will happen. It is what the system does about it.

Does it show its work, so a human can see why it reached a conclusion? Is there a human step before anything the AI produces affects a schedule, a report, a certification record or a member's status? Can a user correct it, and does that correction improve anything going forward?

A vendor who has thought seriously about this will have a real answer. A vendor who has not will tell you the AI is "highly accurate" and change the subject.

Separate Where AI Genuinely Helps From Where It Is Decoration

I do think AI is doing real things in this industry right now, and I do not want this to read as blanket skepticism. There are places where it earns its place: summarizing long documents so a member does not have to read forty pages to find one answer, drafting a report from structured data that already exists so a person edits instead of starting from a blank page, answering plain-language questions against your own department's policies with a link back to the source, or flagging a pattern in data a human would take hours to notice, like a member drifting toward missed shifts before it becomes a real problem.

Compare that against decoration: a chatbot bolted onto a product that already had a perfectly good search function, an "AI insight" widget that restates numbers you can already see in a chart, a feature that generates text without changing any decision you actually make.

The test is simple. If you removed the AI label and just described the feature plainly, would you still want it? If yes, it probably has real value. If the feature only sounds interesting because of the label, it is decoration.

Ask Who Trained It, And Where Your Data Goes

If a vendor's AI produces recommendations based on data, ask what data trained it, and whether it came from departments like yours or a small internal dataset that may not generalize to your size or call volume.

Then ask, directly, what happens to your data once it touches the feature. Is it used only to serve your department, or pooled to improve the vendor's model generally? Is it sent to a third-party AI provider, and under what agreement? This is the same question you would ask about any vendor handling personnel information, and AI features do not get a pass on it just because the answer is complicated.

A vendor with a clear, written answer has taken the responsibility seriously. A vendor who has not thought about it yet is telling you something important about how the feature was built.

Judge The Product, Not The Label

None of this means you should distrust every AI claim on sight. Some of it is real, useful and worth paying for. Some of the most meaningful improvements to public safety software in the next few years will come from exactly this kind of technology.

But the label on the box is not the product. The product is what it does, how it fails, who trained it and where your information ends up. Ask the questions above before the demo becomes the decision. If a vendor cannot answer them plainly, that tells you as much as any feature list would.

For the broader questions to ask any vendor building on AI, especially the smaller and newer ones entering this market quickly, see AI Is Creating a New Generation of Public Safety Entrepreneurs. Ask the Hard Questions.. And before you get to features at all, start with Stop Buying Features. Start Solving Department Problems.

Free interactive tools to put this into practice.

Part of the seriesVendor EvaluationExplore the series