"AI" is not a specification. It is a word that appears on datasheets, and the range of things it describes is enormous.
At one end it means a genuine object classifier running on a processor inside the camera, deciding whether the thing in frame belongs to a category you asked about. At the other end it means the same pixel-difference motion detection that cameras have had for twenty years, with a new label on the box and a new line on the quote. Both are printed in the same typeface. Neither is a lie, exactly, because "AI" has no agreed definition that a vendor could breach.
So the word cannot be evaluated. Only the claim underneath it can. This article is a set of questions that pull that claim out into the open, and they work on any brochure, from any manufacturer, without you needing to know anything about machine learning.
If you have not read the difference between motion detection, VMD and classification, start there — it explains the three mechanisms this article helps you tell apart on paper. This one is the companion to how to read a camera spec sheet: same document, different section, same principle that the number in bold at the top is a sales decision.
Question one: what does it classify, and into what categories?
The first question is the one most likely to end the conversation early, because a great many "AI" features cannot answer it.
A real classifier outputs a category. Ask which categories. The honest answer is a short, fixed list — person, vehicle, perhaps vehicle sub-types, perhaps an animal class — and the list is short for a good reason. Each category has to have been trained, tested and shipped. A vendor who can hand you the list is describing something specific that was built.
Watch for three answers that are not that list.
"It detects anything unusual." Open-ended anomaly language is the single strongest tell that there is no category list, because there is nothing to enumerate. Unusualness is not an object class; it is a statistical statement about a scene, and the scene it was calibrated on is not yours.
"It has smart motion." This is often, genuinely, VMD — zones, sensitivity, object size, dwell time — filtering pixel change more cleverly. That is a real feature and worth configuring properly. It is not classification, and the difference is that a filter on pixel change can never tell you what changed.
"It supports over a hundred detection types." A long list is usually a list of rules built on a small number of classes — line crossing, loitering, entering an area, leaving an area, each multiplied by person and vehicle. That multiplication is useful and it is not the same as a hundred things the camera can recognize. The glossary of analytic event types untangles which of those names describe a new capability and which describe a new rule over the same two classes.
The follow-up that settles it: what happens to something that is not in any category? If the answer is "it still alerts", you have a classifier bolted on top of motion detection, and the motion detection is what will actually be reaching your phone at three in the morning.
Question two: where does it run?
This is the question with the largest consequences and it is almost never asked, because it sounds like an implementation detail. It is not. It decides what you pay, what your network carries, and where your video lives.
There are three answers.
On the camera. The classifier runs on a processor in the camera housing, and what leaves the camera is video plus a small amount of metadata saying what was found. Your network carries what it would have carried anyway. There is usually no separate subscription, because the capability was bought when the camera was bought. The constraint is that the analytic is tied to that camera: replacing the camera replaces the analytic, and the camera you bought three years ago will not gain a new class because the vendor trained one.
On the recorder. The analytic runs on the NVR or a server, examining streams from cameras that may be quite ordinary. This lets older cameras participate, which is a genuine advantage. The costs are that the recorder now has finite analytic capacity shared across channels — a number of streams it can process, often at a reduced frame rate — and that the analysis quality depends on the compressed stream the camera sent, not on what the camera's own sensor saw. Ask how many channels can be analyzed simultaneously, and what happens to the others.
In a cloud service. Video, or clips of it, leaves your site and is analyzed elsewhere. Four things follow, and all four belong in the decision. Your upload bandwidth is now load-bearing, permanently, during business hours. The capability is a subscription, so the cost is recurring and the feature can be repriced or retired by someone who is not you. When the link drops, the analytic stops even though the camera keeps recording. And your video is now in someone else's custody, in a location you should be able to name — which for a business in British Columbia is a privacy question with a paper trail attached, not a technical footnote.
None of the three is wrong. But a datasheet that says "AI-powered" without saying which one has left out the entire cost structure of the feature. Ask plainly: where does the processing happen, what leaves the building, and what stops working if the internet does?
Question three: what was it trained on?
A classifier learns from labelled examples. What it saw during training is what it is good at, and this is the least visible property of the whole system.
You are not going to be given a training set, and you should not expect one. What you can reasonably ask is whether the vendor has deployment evidence that resembles your site. A model whose examples were overwhelmingly daytime, pedestrian-height, unobstructed and shot from a modest mounting height is being asked to do something different when you point it down a lane at night, from a high corner, at people in dark rain gear moving between parked vehicles.
The specific mismatches worth naming out loud, because they are the common ones in this climate: heavy rain and the reflections it puts on every surface; people wearing hoods and high-visibility gear that changes their outline; unusual poses — crouching, climbing, lying down, sitting in a doorway; a person half behind a vehicle; a camera mounted high enough that it sees the tops of heads rather than bodies; and headlight glare washing out one side of the frame every time a vehicle turns in.
None of these break a classifier in an obvious, reportable way. They just quietly lower its performance in exactly the conditions you bought it for, and nothing on the datasheet moves.
A bare accuracy number on a brochure is not a specification. It is a marketing number until it carries three things with it, and you should ask for all three.
At what confidence threshold? A classifier outputs a score expressing how strongly the model matched what it saw to a category, and you choose where to set the bar. Raise it and you get fewer false alerts and more missed people. Lower it and the reverse. Every accuracy claim is a point on that curve, and quoting a single number without the setting is like quoting a camera's minimum illumination without the shutter speed.
Measured against what test set, in what conditions? Daylight, one target, no occlusion, at an ideal distance is a legitimate test and a meaningless prediction of a wet January night in a loading bay.
Measuring which error? "Accuracy" collapses two failures that are not remotely equal in cost. A false alert wastes attention. A missed person is the thing you bought the system to prevent. A system tuned to look impressive in a demonstration is usually tuned toward the first, because nobody in a demonstration notices what was never reported.
And the deeper point: a confidence score is a property of the model's response to one image under particular conditions. It is not a probability that the world is a certain way, and it is not a percentage of correctness anyone can be held to. Anyone offering a single accuracy figure for your site, sight unseen, has told you about their sales process rather than about the equipment.
Question five: what happens at night, in rain, and at distance?
Every property discussed above degrades together, and they degrade in the conditions under which the system is most likely to be earning its keep.
At night the image the classifier receives has less information in it: more noise, less colour, an infrared illuminator that flattens texture and throws rain into bright streaks near the lens, and often a slower shutter that smears anything moving. At distance the subject occupies fewer pixels, and there is a point on every install where a person becomes too few pixels to classify — a point that no datasheet states because it depends on your lens and your geometry.
So the question is not whether the analytic degrades. It does. The question is whether anyone has watched it degrade here, on your site, on your worst camera, at the hour that matters. That is a measurement, not a specification, and nobody can do it from an address.
The structural point: analytics inherit the view
This is the part that gets lost in every conversation about AI features, and it is the one that decides whether the money was well spent.
Analytics do not improve an image. They apply judgement to whatever the lens delivered.
If the camera is too far from the subject, mounted too high, aimed into a sunrise, or pointed at a lit doorway from a dark yard, the classifier is working with the same smudge a human would be. A model cannot recover detail that never landed on the sensor. What it will do instead is produce an output anyway, with a confidence figure attached — and a confident wrong answer is worse than no answer, because it is actioned.
Good analytics on a badly placed camera equals confident nonsense, delivered on schedule.
This is also why "add AI" is rarely the fix for a system that is not working. If your alerts are useless because a camera is looking at a hedge, a classifier will reliably report that there is no person in the hedge. The problems that placement causes are solved by placement — see camera placement and face height and what enough resolution actually means — and only then is a classifier being given something to work with.
There is a related limit worth keeping in view. Detection and identification are separate design problems. Axis, describing thermal cameras, puts the distinction in its own product literature: "Unlike conventional cameras, this technology only allows for detection." The same split applies to any detector, however clever. A classifier tells you that a person is there and roughly what kind of thing it is. Producing an image good enough to establish who they were is a different camera, with different requirements, usually pointed at a different place.
The question worth asking any vendor
You do not need to evaluate a model, read a benchmark, or learn what any of the processor names mean. One request does the work of all of it:
"Show me this running on our site, on our worst camera, at night."
It is a fair request and a cheap one. It cannot be answered with a brochure, a demonstration reel, or a figure. It collapses every question above — categories, processing location, training relevance, threshold behaviour, night degradation — into a single observation you can make with your own eyes, at the hour you actually care about.
An answer of "we can arrange that" tells you a great deal. So does any other answer.
