“Edge AI” for real time CCTV alerts is mostly a story about the dispatcher, not the detector. If the part that decides who to page lives in the cloud, you do not have an edge alert system. You have a faster forensics tool.

The four pieces of any CCTV alert pipeline

Pulling the pipeline apart the right way is the prerequisite for the rest of this argument. The shape is the same whether the system is built on Verkada, on a smart NVR, on a hand-rolled Frigate stack, or on a sidecar box reading the recorder's HDMI output:

1. Detect.A model evaluates a frame and produces structured output: a person, a vehicle, a package, with a bounding box and a confidence. This is the part everyone talks about when they say “edge AI.” It is also the easiest part to put on the edge, because it does not need any state.
2. Dedup. The same intruder walking through four cameras produces four detections. Without dedup, that is four phone calls. Dedup needs short-lived per-zone tracks across the camera grid and a merge rule that respects spatial and temporal continuity. Dedup needs state.
3. Classify. Every event gets a threat tier (LOW or HIGH on Cyrano) based on zone, time of day, behavior, and context. The package room at 2 a.m. is not the leasing office at 11 a.m. Classification needs zone definitions, schedule rules, and the running track from dedup.
4. Dispatch. A HIGH event fires an SMS to the on-call manager and triggers an outbound phone call. A LOW event updates the dashboard and rolls into the daily portfolio digest. Dispatch needs the carrier gateway, the on-call rotation, and the tier output from classify.

The interesting question is not which of these the model can do. It is which of these have to live on the same box for the chain to remain intact when the property network is unhappy.

Where the rest of the market quietly leaves things in the cloud

Read the architecture pages on most edge AI camera products carefully and you will find the same shape: detection on the camera, everything else on the back end. The marketing reads as if “edge AI” means the whole pipeline is at the edge, but the implementation note in the small print says inferences are streamed to a cloud event bus and a server-side rules engine decides what becomes an alert. That is fine for forensics. It is not fine for alerts.

The reason vendors do this is structural. Cloud control planes are easier to build than on-device control planes. Pushing tier rules to a server lets a single team iterate on logic that affects every customer. Per-camera detector chips also have very little memory headroom for the on-device state machines that dedup and classify need. The cloud is where the easy answers go. So that is where they end up.

The cost shows up at exactly the moment you needed the system. A coastal property loses cable for nine minutes during a thunderstorm. A multifamily complex switches to cellular failover and an LTE re-association takes 40 seconds. An ISP rolls out a misconfigured BGP change at 2 a.m. on a Sunday. In all three cases the cameras kept working, the recorder kept recording, and the on-camera detector kept detecting. None of that produced an SMS, because the dispatcher was on the other side of the dead link. The forensic story is intact: tomorrow you can review what happened. The alert story is gone: you did not get the call.

What link-independence actually looks like in practice

On a properly local pipeline, the cameras and the recorder talk to each other on the LAN, the box reads the recorder over HDMI on the same LAN, and the box runs detect, dedup, classify, and dispatch on its own CPU and accelerator. The internet is only on the egress path. SMS, the outbound phone call, the dashboard event, and the digest entry all leave the building, but the decision that triggered them did not.

That has a specific operational consequence. When the uplink drops, detection keeps running. Events keep being generated. The dispatcher keeps writing to the local queue. SMS attempts fail and retry. As the uplink recovers, the queue drains in strict order. The dashboard backfills with correct timestamps. Nothing about the chain notices that the WAN was gone for nine minutes, except that the SMS arrival times are clustered.

The mechanism is intentionally boring. There is one outbox file. Events are appended one JSON line at a time. There is a monotonically increasing counter. A drain worker walks the file forward, posts events, and advances a checkpoint. If the uplink is healthy, the checkpoint is approximately current; if it is degraded, the checkpoint trails. There is no distributed state, no clever queuing, no reordering. Boring queues survive 2 a.m. better than clever ones.

Why dedup and classify also have to be local

It would be tempting to say only the dispatcher has to be local; ship raw detections to a cloud rules engine, dedup and classify there, and call it a day. That fails for two reasons.

First, dedup needs the running per-zone tracks the model is already maintaining. A cloud rules engine that tries to merge by event timestamp alone ends up either collapsing real distinct incidents or splitting one intruder's walk across four cameras into four phone calls. The merge logic that works uses spatial continuity across the tile grid, which is in-frame information the model already has and the cloud does not. Pushing dedup off the box means re-deriving state the box already knew.

Second, classify is the part the operator is most sensitive to. The difference between “HIGH means SMS plus a phone call” and “HIGH means an unread row in a dashboard” is the difference between an alert system and an inbox. If the classify decision lives in the cloud, then HIGH events have to round-trip to a remote control plane before the dispatcher fires. That round trip is not the bottleneck on a healthy day; it is the bottleneck on a bad day, and bad days are the only ones that matter for an alert pipeline.

The argument simplifies cleanly. Dispatch has to be local because that is where the alert leaves the building. Classify has to be local because dispatch depends on it. Dedup has to be local because classify and operator hygiene both depend on it. Detection has to be local because everything else does. The cloud is for analytics, fleet-wide rule updates, and the things that are allowed to be late.

What this looks like to a property manager who never wanted to think about edge AI

None of this matters to the operator at the level of architecture. What matters at the operator level is two things. One: when something HIGH happens, a phone rings, fast, even if the building's internet is having a bad night. Two: when something LOW happens, it is in the morning digest and not on the phone. Everything in this guide is plumbing in service of those two outcomes.

The HDMI ingestion path matters because it lets one box cover up to 25 feeds without a camera-replacement project. The on-device dispatcher matters because it is what makes the “phone rings, fast, even on a bad night” promise honest. The boring outbox matters because it is the difference between a system that drops 0.5 percent of alerts during weekly uplink hiccups and one that does not. None of these are the kind of feature that lives in a sales deck. They are the kind of feature that the operator notices, six months in, when they realize the alert app on their phone still works and they have not muted it.

The pricing follows the same shape: 450 dollars one-time for the device, 200 dollars a month after the first month, no camera replacement, no cloud minutes per feed. For comparison, an overnight security guard runs 3,000 to 5,000 dollars a month per property and one guard cannot watch 25 feeds at once. The alert channel is the part that compounds.

How to test whether a candidate “edge AI” system actually qualifies

The phrase “edge AI” is now in the marketing glossary of every camera vendor. The cheap version is the one this argument has been describing all along: detector on the camera, everything else in the cloud. The honest version puts detect, dedup, classify, and dispatch on the same device. Three concrete questions separate them.

First: pull the property uplink for ten minutes mid-pilot. Trip a known event during the outage. After the uplink returns, confirm an SMS arrives, the dashboard shows the event in the right slot in the timeline, and the event ordering is correct. If the answer is “the SMS never arrived” or “it arrived but timestamps are wrong,” the dispatcher and the queue are not actually local.

Second: walk a tester through four to five cameras in 90 seconds. Confirm that one incident, one phone call, and one thumbnail strip are produced, not four separate phone calls. If the answer is four phone calls, dedup is happening at the notification layer, not at the inference layer, and it is not going to scale to a real property.

Third: ask where threat-tier rules execute. If the answer is “in our cloud rules engine,” HIGH events are paying a WAN round trip on the way to the dispatcher. If the answer is “on the box, with central rule updates pushed nightly,” the chain is honest. The right answer is the second one. Both can be marketed as edge AI; only one keeps its promise on a thunderstorm Sunday.