Cameras That Are Monitored Versus Cameras That Are Watched

A camera that catches an intrusion on tape and fires an alarm that nobody reviews in time has not stopped a crime. It has documented one. That gap, between a system that records and signals and a system that confirms and acts, is the subject of this piece and the test every buyer of commercial security cameras should be running on their own property right now.

Why "monitored" and "watched" are not the same thing

Picture the scenario directly: a camera records an intrusion at 2 a.m., the sensor trips, an alarm signal leaves the building and lands in a queue somewhere, and the person breaking in is gone before anyone looks at the footage. The recording exists. The alarm fired. Nobody watched. That is the condition most buyers are sold under the word "monitored," and it describes a connection, not an outcome. Most commercial security cameras do only two things reliably: they record and store footage, and they generate alarm signals when a sensor trips. Whether a person or a system reviews that signal fast enough to matter before the threat concludes is a separate question, and it is the one vendors rarely answer directly. Being watched means something, a trained operator or an AI agent, is actually looking at the event as it happens and is positioned to act before the window closes. The test is simple to state: if a real intrusion happened tonight at 2 a.m., how many minutes would pass before a verified call went to police? That number, not the camera count on the proposal, is what separates a site with real coverage from one that only looks covered on paper. A property with a large number of cameras that are monitored but never watched has less actual protection than a property with far fewer cameras that are reviewed and verified every time they trigger.

The legacy "detect and notify" model and the gap between monitored and watched

The gap between monitored and watched is built into how traditional alarm monitoring works. The standard model is detect and notify: a sensor fires, the signal gets passed up the chain to a monitoring center, and an operator sees it, with no step in between that confirms whether a real threat is actually present. That missing confirmation step is the reason false alarm rates in this industry run as high as 98%. When nearly every signal in the queue is noise, no operator, however skilled, can tell the real one apart from the rest just by looking at the order they arrive in. It is a structure that treats a deer walking past a motion sensor, a truck passing on the street, a tree swaying in wind, and an actual break-in as functionally identical the moment they become alarms, because the architecture has no way to sort them before they reach a human, not a hiring problem or a training problem. Every operator shift starts already behind, because there is no point at which the queue resets to zero real threats and zero false ones. Static thresholds make this worse: a system that treats every motion event at the same priority level buries the one alarm that matters under dozens that don't, and operators adapt the only way people can under that pressure, by trusting the system less. Muting noisy cameras, moving operators overseas to cut costs, or charging a site more because it generates too many alarms treats the symptom and leaves the actual defect in place: the alarm still arrives unverified, still waits its turn, and the site that got muted now has a blind spot where its coverage used to be. Once operators stop trusting what the system tells them, the system has already failed, no matter how many alarms it technically processed.

What alarm verification requires to turn a monitored camera into a watched one

Turning a monitored camera into a watched one requires a different kind of signal than a raw sensor trip. It requires evidence, audio or video, reviewed by something capable of assessing it before anyone calls for a dispatch. A verified alarm is one where a monitoring professional has used that evidence to confirm a genuine threat is present before police get a call, and that confirmation step is the entire difference between a system that reacts to noise and one that protects a property. The industry sorts this into three tiers. Tier 1 is no verification: a raw sensor activation goes straight to a monitoring center and may get dispatched without anyone confirming anything, and it produces the highest false alarm rates in the industry. Tier 2 is basic verification, where a second trigger or a phone call adds a layer of confidence, reducing uncertainty without actually confirming a crime is in progress, and it usually does not qualify for priority police response. Tier 3 is a true verified alarm: real-time or near-real-time audio or video evidence that lets a monitoring professional make an actual judgment about whether unauthorized activity is happening before a call goes out. This is the tier a growing number of cities now require before they will dispatch officers at all, and some offer priority response only to alarms that clear it. A Tier 1 alarm from an unverified system may draw no police response whatsoever. Most traditionally monitored sites are at Tier 1 without realizing it: the footage exists, the signal fires, and no one confirms anything before the opportunity to stop the threat has passed. Audio adds something video by itself cannot: it covers the space outside a camera's field of view and can flag activity by sound before anything shows up on screen. None of this answers who or what is actually capable of doing that reviewing, at the volume a real deployment generates, fast enough for the confirmation to matter.

The limits of human operators watching every camera in a large deployment

Even a monitoring center committed to full Tier 3 review runs into a ceiling that has nothing to do with how dedicated its staff is. It is a throughput limit: alarm volume grows with the number of cameras connected to a system, and the number of events one human can actually review in a given minute does not grow with it. Monitoring providers already contend with unpredictable swings in event volume, staffing shortages, burned-out operators, overtime they can't always cover, and customers who expect faster responses every year, and all of that tends to collide at once during the exact periods when volume spikes. A storm that sets off dozens of motion alerts at once, or a Friday night at a retail site that generates hundreds of events in an hour, fills the queue faster than any team can clear it, and a real threat sits behind a pile of false ones with no way to jump the line. A center that handles an average Tuesday afternoon just fine will buckle during that Friday night spike, and that spike is usually when something real is actually happening. Pushing an operator to clear a backlog fast drops the quality of their judgment: someone skimming footage because forty more events are waiting is not doing Tier 3 verification in any way that holds up. A common objection here deserves a direct answer: providers often point to the UL 827 standard as proof of speed, but UL 827 governs how quickly a signal must be acknowledged, with its clock starting the moment the signal is received, well before a human actually looks at it and confirms a threat. A signal can sit open and logged in a queue for a long stretch while technically counting as acknowledged. The number a buyer should care about is time to verified dispatch, not time to acknowledgment, and those are not the same clock. None of this gets solved by hiring more people onto the same architecture. It gets solved by having something filter the noise before it ever reaches a human, so that every event an operator sees has already cleared the bar of being worth their time.

How AI agents fit into a monitoring workflow

The architecture that fixes the throughput bottleneck puts an AI agent in front of the queue, not a bigger queue with more people behind it. Early AI systems in video surveillance handled repetitive work like object detection, tracking, and generating the alarm itself, but the actual decision about whether a threat was real still landed on a human, and the workload went down without the underlying structure changing. A more capable version of this looks different in practice: an AI agent assesses an intrusion on its own, takes a preliminary step like sounding an alarm, and then presents an operator with a decision, such as whether to call police, alongside a report built from real-time video, access records, a log of what the AI itself already did, and a recommended response. The operator's job shifts from figuring out whether something is real to deciding what to do about something that has already been confirmed, and that is a faster, clearer decision to make under pressure. This is the structural fix for the gap between monitored and watched: the human queue only ever contains confirmed events, not raw noise, so staffing doesn't need to scale with alarm volume the way it does under the old model. Verdun applies this architecture directly: its AI agents review every alarm before an operator ever sees it, and trained operators step in once a threat has been verified, the applied version of filtering noise at the signal level before it reaches a person. There is a hard boundary that has to hold here regardless of how capable the AI gets. An AI agent should never be the one making the final call, whether to dispatch police, issue a voice-down warning over a speaker, or decide that an event is authorized activity and needs no response at all, because those decisions carry legal weight, safety consequences, and a need for accountability that has to sit with a human being.

How site-specific context determines whether AI verification is meaningful

None of this works unless the AI agent doing the filtering actually knows the site it's watching. An agent that doesn't know a property's operating hours, its list of authorized people and vehicles, its normal after-hours traffic, or where its own cameras have blind spots will produce a faster version of the exact false-alarm problem it was built to solve, just with more confidence attached to the wrong answer. A delivery truck parked in a yard after hours might be completely routine at a logistics site and a clear sign of a break-in at a warehouse two miles away, and an AI agent only gets that distinction right if someone has told it which site it's looking at and what the rules at that site actually are. A provider doing this well should be able to show operating schedules, lists of authorized personnel and vehicles, documented patterns of normal after-hours activity, known camera coverage gaps, escalation contacts, and response protocols broken out by the type of event, all loaded into the system before an alarm ever fires. A monitoring agreement worth signing spells out site-specific requirements, communication protocols, and response procedures in terms specific enough to hold the provider to, instead of a generic response-time number that reads the same across every property in the provider's book. The ANSI/TMA AVS-01 standard, revised in 2024, lays out best practice for sorting alarm events by verification tier, moving a system from raw sensor trips toward true verified alarms backed by visual or audio confirmation, but that framework only delivers what it promises if the site context behind it is accurate. A buyer evaluating an AI monitoring provider should ask to see the documented protocol for their specific site and ask how the AI actually uses it, not just take a sales pitch about "AI-powered monitoring" at face value. A provider with nothing more specific to offer than that phrase is selling a label, not a working system.

The functional test buyers can apply to determine whether their cameras are truly being watched

It's how long it would take for a verified threat to reach a human who can actually act on it, and what happens to every other alarm in the meantime, not how many cameras sit on a property or whether they're connected to a monitoring center somewhere. That question breaks down into four things a buyer can ask their own provider directly, and the answers are checkable. The first is what tier of verification the system actually runs at: is the monitoring center getting raw sensor signals with no confirmation step, a Tier 1 setup, does it require a second trigger before anyone acts, which is Tier 2, or does a human or AI actually review video or audio evidence before a dispatch call goes out, which is Tier 3. The second is time to verified dispatch, not time to acknowledgment, and a buyer should ask the provider to separate those two numbers explicitly; if a provider can't tell you when a signal was opened versus when a human actually confirmed a threat and called police, the number they're quoting isn't measuring the thing that matters. The third is what happens to the system during peak alarm volume, during a storm or a busy weekend night, because a provider who can't explain how they maintain review speed when dozens of alarms land at once is quietly telling you that real threats wait in line behind false ones during exactly the moments threats are most likely. The fourth is whether the provider's system actually knows what's normal at that specific property, its schedule, its authorized vehicles, its usual patterns, because a generic model running the same rules across every site in a portfolio is just producing noise more quickly, not catching more real threats. A camera that holds up against all four of these questions is genuinely watched. One that fails even a single question is monitored in the narrow sense only: it records, it signals, and then it waits, with no guarantee anyone will look in time. Verdun's architecture, AI agents reviewing every alarm continuously and trained operators responding once a threat clears verification, is built to answer these four questions directly, close to what a system has to look like if it's going to pass this test. Monitoring is a threshold a system either clears or doesn't; watching is the guarantee that sits above it, and now the test for telling the two apart belongs to the buyer running it.