Every trade show this year has the same floor. Half the booths say AI on the banner, most of them mean something different by it, and a few mean “we added a settings toggle.” The people who have to live with the results — the dispatcher, the field supervisor, the officer holding the phone at 04:00 — were not in the room when any of it was bought.
This is an honest ledger, not a verdict: what a contract security company can buy in 2026 that will still be earning its keep in two years, and what is being sold on a promise the technology cannot currently meet.
The test used throughout is narrow. Does it reduce work, or move the work somewhere else? Most of what fails, fails on that second clause.
Works, with caveats: video classification
Modern video analytics genuinely distinguishes a person from a vehicle from an animal from a wind-blown branch, reliably enough that the old motion-detection generation is obsolete. Draw a line, get an event when a classified object crosses it. That works, and everything else in video rests on it.
The caveat is the part the demo skips: false positives do not go away, they get reassigned. Rain, headlights sweeping a wall, a reflective surface, a spider building a web across a lens at 02:00 — the system fires, and somebody has to look. That somebody is usually your officer or your dispatcher, and that work is new. It did not exist before you installed the analytics.
So the honest way to evaluate a video-analytics deployment is not “how good is the detection” but “how many events per night, who looks at them, and what are they not doing while they look.” The full argument, including what it does to the officer’s job, is worth having with the client before the cameras go in.
Related and equally real: license-plate recognition at a controlled gate. Constrained problem, fixed camera angle, known lighting, a finite list to match against. That is the profile of a machine-learning problem that actually works, and it works at a gate in a way it does not in an open parking lot at night.
Works: drafting and summarizing text
This is the least glamorous item on the list and probably the most valuable one for a guard company.
Officers write badly. Not from carelessness — report writing is a skill nobody taught them, they are doing it at the end of a twelve-hour shift, and English is a second language for much of the workforce. The result is a DAR that is technically complete and functionally unreadable, and an incident narrative missing the one detail an adjuster will ask for.
Language models are good at exactly this shape of problem: a rough account in, a clean one out; twelve shift logs in, a paragraph out. No prediction, no claim about the world, and the person who knows the facts is right there to check it.
Two guardrails, and they are not optional:
The officer’s account stays the record. A model can restructure a narrative; it must not add facts. If a report comes back with a detail the officer did not write, that detail is fabricated, and a fabricated detail in an incident file is worse than a badly written one. The generated version is a draft the author approves, not a replacement for what he said.
It does not fix training, it exposes it. If your officers cannot tell you what happened, cleaner prose will not help. Report-writing training is still the actual fix; the tooling makes a trained officer faster, and makes an untrained one produce polished nonsense.
Works: finding patterns in data you already have
The third genuinely useful category is the most boring: pointing analysis at records you are already generating and have never read.
You have months of incidents with sites, times, classifications and outcomes; tour data showing which checkpoints get missed and when; attendance data with every late clock-in on it. Almost nobody reads any of it beyond a monthly total, and what is in there is not subtle — the same gate three times before it failed for real; callouts clustering on one supervisor’s Sundays; a post throwing an exception every Thursday since June.
None of this requires a clever model. It requires the data in one structured place, which is the real precondition and the reason most companies cannot do it: an operation running on paper and WhatsApp has no dataset to analyze. Once events are captured as structured cases rather than free text in a notebook, the pattern work becomes tractable — with or without AI in the loop.
Be clear-eyed about what this is, though. It is retrospective analysis of things that already happened. It is not prediction, and the moment a vendor describes the same capability as predictive, ask which of those two they are actually shipping.
Does not work: predicting crime
This is the largest claim on the market and the weakest.
The pitch is that a system will tell you where an incident is likely to occur so you can post an officer there. The problems compound. Crime data reflects where enforcement went, not where crime was; a model trained on it learns patrol history and returns it as a forecast. Base rates on a single commercial property are tiny, and no model produces a useful probability estimate from a handful of events. And the output is unfalsifiable in the direction that matters: if you post an officer and nothing happens, was the prediction right, or was it wrong and the officer irrelevant?
There is a defensible version that predates AI and does not need it: put more coverage where you have had more incidents, at the times you had them. That is a spreadsheet. If a vendor’s prediction product resolves to that, you are paying a premium for a chart.
Does not work as sold: facial recognition
The technology exists and it functions. The problem is not accuracy in a lab; it is everything around deployment.
Recognition degrades sharply under the conditions real security cameras operate in — angle, motion, low light, partial occlusion, a hat. A match confidence that looks excellent on a passport photo means something very different on a frame from a lobby camera at ceiling height. And the failure mode is not symmetric: a false match means a person is approached, questioned or removed on the strength of a machine’s opinion, by an officer with no way to evaluate it.
Then there is the legal exposure, which varies by jurisdiction and is moving faster than any vendor’s slide deck. Biometric collection is separately regulated in some US states and in a number of other countries, and the rules keep changing. Any deployment has to be evaluated against the statute that applies in the actual place, by your own counsel, before it is switched on — never on the strength of a vendor’s compliance claim.
As an after-the-fact investigative aid, where a human treats the result as a lead: reasonable. Live, as a trigger for an officer to act on: not something a contract security company should underwrite.
Does not work: “suspicious behavior detection”
The most oversold category on the floor, and the one to walk away from fastest.
Systems claiming to detect loitering, aggression, intent or “anomalous behavior” are making a claim about a person’s state of mind from pixels. Loitering detection is dwell-time-in-a-zone — a timer — and it fires on the smoker, the person waiting for a ride and the driver reading a manifest. Aggression detection is rapid-motion detection. Neither reads intent, because intent is not visible.
This matters more than a wasted line item: these products generate events an officer is expected to act on, about specific people, on a basis nobody can explain. When the interaction goes wrong — and it will, on whoever the system finds unusual — “the camera flagged him” is not a defense.
What this means for our own assistant
Since this site sells software, the same skepticism has to point inward.
CGuardPro’s assistant, VigIA, is an office tool for the CRM — not a perception system and not a predictor. What it does is bounded and stated on its own page: answer questions about your operation, and carry out CRM actions you confirm first. Every action that writes appears as a confirmation card naming the real people it affects, and nothing runs until someone presses confirm. It acts with the permissions of whoever is typing, and the whole exchange is logged, including the attempts that failed.
It also does not serve the field apps. It is not watching video, not scoring anybody, and not deciding where to put an officer. That narrowness is the design, and the reason its claims are checkable.
The questions to ask before you sign
Five, and they will separate the two lists above faster than any demo.
- What exactly does the model output, and what does a human do with it? If the answer skips the human, ask again.
- How many events per night on a site like ours, and who reviews them? Get a number from an existing deployment, not a lab figure.
- What happens when it is wrong? Both directions. Who is affected, and what is the recourse.
- Can it act without a person confirming? For anything that touches a record, a person, or a client, the answer should be no.
- What is the audit trail? If it cannot show who asked for what, when, and what happened, it cannot be used in an operation where “the system did it” has to become a sentence someone can defend.
Those are the same questions worth asking about any vendor’s software, which is the point: the AI label does not change what a purchase has to justify. The categories that pass in 2026 are the unglamorous ones — classification on constrained problems, drafting under human review, and finally reading the data you already had. Everything else is asking you to buy a claim about the future, and the rest of the toolkit that runs a guard operation is not waiting on it.