Two proposals can promise you the same thing — "person detection with alerts to your phone" — and commit you to two completely different systems. Not different brands. Different machines doing the arithmetic, in different buildings, sometimes in different countries.

Analytics are software. Software runs on a processor somewhere. There are only three somewheres: inside the camera, on a server in your building, or on a provider's infrastructure reached over your internet connection. Which one a quote assumes is often the single most consequential fact in it, and it is frequently the fact nobody states.

This article is about that choice. It assumes you already know what an analytic actually is — that classification is a different technology from pixel-change detection — and it is a different question from where your footage is recorded, although the two decisions interact and are often made at the same table.

The edge: computation inside the camera

Edge analytics means the camera itself runs the model. Video is captured, analyzed, and turned into an event by a processor a few centimetres from the lens. What leaves the camera is a stream, plus a small message saying a person crossed a line.

The appeal is that there is nothing else to buy. No analytics server, no additional licence to renew, no second machine to keep alive. The camera you already paid for does the work, and it does it whether or not your internet connection is up, because nothing has to travel anywhere for the decision to be made.

It is also the strongest privacy posture available, and this matters more than it usually gets credit for. If the analysis happens on the camera, the video does not leave the site in order to be analyzed. There is no copy of your footage on someone else's disk for the purpose of running a model over it. You have not added an organization to the list of organizations that hold images of the people who walk past your door.

The costs are structural and they are not obvious on a datasheet.

You are limited by the processor in the camera. A camera's analytics chip has a fixed capability, chosen when the model was designed. It will run the analytics the manufacturer shipped, at the performance the manufacturer achieved, and that is the ceiling. There is real headroom in modern cameras — this is not a weak option — but it is a ceiling that arrives with the box.

The analytic is locked to that camera's view. The model sees exactly what that lens sees, and nothing else. An analytic that would benefit from combining two overlapping views, or from following a person from the parking lot camera to the door camera, cannot do it from inside one camera. Each unit is analyzing in isolation.

Replacing the analytic means replacing cameras. This is the sharp edge, and it is the one owners under-weight. If the on-camera analytic turns out to be wrong for your site — it misses what you needed, or it fires on what you asked it to ignore — your remedy is not a software change. Firmware updates improve what is there; they do not install a capability the chip was not built for. On a site with a meaningful number of cameras, "we will upgrade the analytics later" quietly means "we will replace the cameras later."

Ask, before the order goes in, exactly which analytics the camera runs today, because that list — not the manufacturer's roadmap — is what you are buying. Our article on reading an AI claim on a datasheet is largely about extracting that answer from a spec sheet that would rather not give it.

The server: computation on a machine in your building

Server-side analytics means video arrives at an on-premise machine — often the recorder, often a dedicated box beside it — and that machine runs the models for many cameras.

The capability is genuinely higher. A server has more processing power than a camera and can be specified with more, so the models can be larger and the analytics more demanding. Because the server receives every stream, it can do things no single camera can: apply an analytic to a camera that has none of its own, correlate two views of the same area, or run several analytics over the same footage. And when you want a better analytic, you upgrade software on one machine rather than replacing hardware on twenty walls.

It also keeps the video on site. Like edge analytics, server-side analysis means footage does not leave the building to be examined, which keeps the privacy question small and local.

What you have bought, though, is a machine. Somebody owns it.

That machine needs patching, because it runs an operating system and analytics software, and both accumulate vulnerabilities. It needs monitoring, because a server that has stopped analyzing looks exactly like a server that is analyzing and finding nothing. It needs its licences maintained, because most server-side analytics are licensed per camera or per channel and the licence has a renewal date. And in some number of years it needs replacing, because it is a computer and computers do not last as long as cameras or cabling.

None of that is a reason to avoid the model. It is a reason to name the owner. The failure we see is not a bad server — it is an unassigned one: handed over at commissioning, never patched, and discovered years later doing nothing at all.

The cloud: computation on somebody else's infrastructure

Cloud analytics means video, or a processed derivative of it, travels over your internet connection to a provider's platform, where the analysis happens.

This is the most capable option and it is the only one that improves after you buy it. Models are retrained and redeployed on the provider's side; capability that did not exist when you signed can appear without anyone visiting your site. For analytics that benefit from very large training sets, or that need more computation than is reasonable to put in a building, this is where they live.

The trade-offs are real, and each of them is a design constraint rather than a footnote.

Your video leaves the building. That is the mechanism, not a side effect. Analysis in the cloud requires the images to be in the cloud.

You inherit a subscription. Cloud analytics are an operating cost that continues for as long as the capability does, scaling with cameras and with what you ask them to do. There is nothing wrong with an operating cost — it buys you continuous improvement and no hardware to own — but it is permanent, and if it lapses the capability stops. Compare it over the years you expect to run the system, not against the first invoice.

Bandwidth becomes a design constraint. Sending video upstream, continuously, from every analyzed camera is a load on a connection that most commercial internet plans size for downloads. This is not a problem you discover at commissioning on a quiet afternoon; it is a problem you discover when several cameras are busy at once. Some platforms reduce it by doing the first stage of detection on the camera and sending only clips or metadata upward — a hybrid that is often the sensible answer, and worth asking for by name.

Latency stops being theoretical. Round-trip time to a provider and back is small, but it is not zero, and it is only as reliable as the connection under it. For a review-later alert, this is irrelevant. For an analytic that has to do something immediately — hold a door, trigger a deterrent, gate a vehicle — the decision needs to happen close to the event. Anything that must act in the moment belongs on the camera or on the local server, and the question to ask about any cloud analytic is what it is allowed to control, not just what it can see.

And the internet drops. When the connection fails, cloud analytics stop. Not degrade — stop. Recording may well continue locally, and a good design ensures it does, but the analysis and the alerts do not happen while the link is down. In parts of BC where winter storms take out power and connectivity together, the honest question for any cloud-analytics proposal is: what is watching during the outage, and what happens to the events that occurred during it?

The factor owners rarely weigh: where the video is processed and stored

Every dimension above is a technical trade. This one is not, and it is the one that gets skipped.

Surveillance video of identifiable people is personal information. Sending it somewhere to be analyzed is a decision about where personal information about your staff, your customers, and passers-by is processed and held — and in British Columbia that engages the Personal Information Protection Act, not just your network diagram.

Two provisions are worth having in mind before you sign anything. PIPA s.34 requires an organization to protect personal information in its custody or under its control by making reasonable security arrangements — and video sitting on a third party's platform is still under your control, which means their arrangements are effectively yours. PIPA s.35 governs retention and destruction, which means you need to know how long the analytics platform keeps what it receives, and what "delete" means on their side.

Neither section is satisfied by a reassuring sentence in a brochure. Practical questions, asked before purchase and answered in writing:

  • Does the platform receive full video, or only clips and metadata? These are very different exposures.
  • Where is it processed, and where is it stored — which country, and is Canadian storage available?
  • How long is it retained after processing, and is deleted data actually deleted?
  • Who inside the provider can view customer video, and is that access logged?
  • Does the provider use customer footage to train models, and can you decline?

A provider with good answers gives them quickly. Vagueness on that last one in particular is itself an answer.

This is also where the three options separate most cleanly. Edge analytics answer the whole list with "the video did not leave the site". Server-side analytics answer it the same way, with the caveat that you own the security of the machine. Cloud analytics require you to actually ask — and the answer belongs in the contract, not the sales call. If your cameras also overlook areas beyond your own property, read where your cameras may and may not look alongside this, because the two questions compound: footage you should not have collected is worse when it is also footage you have exported.

How to make the decision

Start from the analytic, not the architecture. Decide what you actually need detected — the event-type glossary is the vocabulary for that conversation — and then ask where that specific analytic runs in the system being proposed.

Then apply three tests. If the analytic must act on something in the moment, it runs on the camera or the local server. If the site cannot rely on its internet connection, the detection that matters most cannot depend on it either. And if the footage is sensitive — residents, patients, staff areas, anywhere you would struggle to justify an export — keep the processing on site, where the privacy question stays a question about your building.

Most commercial sites end up mixed, and that is a legitimate design rather than a compromise: on-camera detection doing the immediate, connection-independent work, a local server handling what needs more capability, and a cloud layer for management and review where its improvement curve earns the subscription.

What you should refuse is a proposal that does not say. "AI analytics included" is not a specification. Where the computation happens decides what the system costs forever, what it does when the line goes down, and who else holds pictures of the people who walk past your door.

Sources

  • Personal Information Protection Act (SBC 2003, c. 63), s.34 (protection of personal information) and s.35 (retention and destruction) — https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03063_01