AI is being attached to almost everything: video analytics, access control, intrusion detection, remote monitoring, weapons detection, license plate recognition, SOC workflows, visitor management, incident response and now autonomous agents. Some of it is useful. Some are early but promising. Some is automation with a better name. And some is being sold before it can be used in the field.

That does not make AI bad. It makes it dangerous to buy on a whim.

I have spent more than 25 years in this industry in several roles: software, video surveillance manufacturing, system integration, public-sector work, commercial facilities, schools, industrial sites, and long-term service. That experience matters. A system can look impressive in a demo, good on a proposal and clean on installation day. The truth shows up later, when the facility is busy, lighting changes, the network is under load and the system must help real people make real decisions.

Security leaders should not ask whether a product “has AI.” The better questions are: What is this AI being trusted to do? What evidence proves it can do it in our environment? What happens when it is wrong? And who is accountable for the decision that follows?

A demo does not answer those questions. Tested operational performance does.

AI Fails in the Scene, Not the Brochure

Most AI failures I see are not futuristic failures. They are ordinary security-design failures with a more expensive label.

A camera is mounted too high. The lens is too wide. A hallway behaves differently at school dismissal than it does at 10 a.m. A loading dock has forklifts, headlights, steam, pallets, delivery trucks and workers moving in patterns that look messy to software but normal to the operation. A parking lot analytics system works in daylight and struggles in snow, rain, glare, or wind.

Then someone says, “The AI doesn't work.”

Sometimes that is true. Sometimes the larger problem is that no one validated the camera position, lighting, network, detection zone, user workflow, response policy, permissions or human-verification process.

AI cannot rescue a poorly designed security system. It can only expose it faster.

I am careful with AI language because I have been on the manufacturer side, where the best-case scenario is often what gets shown. I have been on the integrator side, where technology has to work within imperfect buildings, budgets, and conditions. And I have been on the service side, where the question becomes: Does this system still help the customer six months later?

That is where hype dies. If AI is going to be trusted, it has to be tested in real buildings, not just controlled demonstrations.

Start With a Baseline

One weak habit in buying AI is accepting claims of improvement without a baseline.

A vendor may say a system reduces false alarms, improves detection, speeds investigations or allows one operator to monitor more locations. Those may be legitimate goals. But compared with what?

The current guard force? The existing monitoring center? Human video review? The customer's actual incident history? A controlled proof of concept?

Without a baseline, “better” is just a marketing word.

Before recommending or trusting an AI-enabled system, I want to understand the current state. How many alerts come in today? How many are real? How many are nuisance alerts? How often are alerts ignored? How long does it take to find video? How many incidents were missed because the right camera was not viewed at the right time?

A serious proof of concept should not run for an afternoon. It should run through the conditions that matter day and night, weather, shift changes, deliveries, after-hours activity and whatever else reflects the actual site.

AI should be bought against a test plan, not a promise.

For commercial video surveillance, that test plan should include more than whether a camera produces a clean image. It should examine placement, lighting, storage, network health, remote access, permissions, evidence retrieval, alert routing and whether the people responsible for responding can actually use the system under pressure.

False Positives Destroy Trust

False positives are often treated like a technical inconvenience. In the field, they are a trust problem.

If an AI system generates too many nuisance alerts, people stop believing it. They lower sensitivity, turn features off, route alerts to an inbox nobody checks or stop responding because the last 50 alerts were meaningless.

At that point, the system may still be technically running, but operationally it is dead.

There is no universal answer to how many false positives are acceptable. It depends on consequence. A nuisance alert in a low-risk exterior area is different from an alert that dispatches law enforcement, initiates a lockdown, affects an employee or escalates a threat response.

A real evaluation should measure false positives by camera, scene, schedule, condition and use case. A global accuracy number is not enough.

Ninety-five percent accurate at what? In what lighting? Against what real-world event set? And what happens when it is wrong?

Missed Detections Are Quiet Failures

False positives get attention because they are loud. Missed detections can be more dangerous because they are quiet. An AI system may appear clean because it produces fewer alerts. That does not prove it is better. It may simply be missing events.

Security executives need to ask both sides of the performance question: How often does the system alert when nothing meaningful happened, and how often did something meaningful happen without an alert?

That second question requires test footage, known events, human review and an honest look at failure. It may mean admitting that an analytic is useful for one purpose but not ready for another. That is not anti-AI. It is responsible security.

The best deployments I have seen do not treat AI like magic. They define what it is supposed to do, measure it against real conditions, adjust the design, train users, review exceptions and monitor performance over time.

AI is not set-it-and-forget-it. Facilities change, schedules change, camera views get blocked and software updates can change behavior.

AI Can Detect. It Cannot Be Allowed to Decide

This is the point I believe our industry must be very clear about.

AI can detect. AI can classify. AI can prioritize. AI can search faster than a person. AI can put an event in front of the right human faster than that human might find it manually. But AI should not be allowed to make consequential security decisions on its own.

A system may identify a person, vehicle, behavior, door event, possible weapon, crowd or unusual pattern. That does not mean it understands intent or the full policy context. It may not know that a person is authorized because of a maintenance window, medical concern, school event, custody issue, disability accommodation, tenant dispute or law-enforcement instruction.

AI detects patterns. Humans verify meaning. Those are not the same thing.

We should use AI to improve awareness, speed, investigation, search, review and verification. We should not allow AI to become the final authority on decisions affecting access, discipline, employment, emergency response, law enforcement, reputation or someone's freedom of movement.

That is not fear of technology. I believe in good technology. But security cannot outsource judgment to a tool simply because the tool is fast. The safest future is not an autonomous security system. It is human-verified security strengthened by AI.

Agentic AI Raises the Stakes

The discussion around OpenClaw and Agentic AI matters because it illustrates where the risk is heading.

Traditional analytics may classify video or generate alerts. Agentic AI may have tools, memory, permissions, integrations, credentials and the ability to take action across systems. That changes the risk profile. If an AI agent can read files, access platforms, execute workflows, communicate across systems, use stored credentials and act on behalf of a user, it is no longer simply software. It becomes an operational actor.

Physical security is moving in the same direction. Cameras, access control, identity, remote monitoring, investigations, APIs and eventually automated response are becoming connected.

This does not mean organizations should reject modern platforms. It means they should govern them like enterprise systems, not isolated security devices. A camera is not just a camera once it's connected to the network. An AI analytic is not just a feature once people act on its output.

Security, IT, legal, operations and executive leadership need to be involved before deployment, not after the first incident.

The Integrator's Role Has to Mature

Security integrators cannot simply repeat manufacturer claims.

If an integrator recommends AI, they should explain where it fits, where it does not, how it should be tested, what infrastructure it depends on, what policies must be in place and what ongoing service will be required.

That includes camera placement, bandwidth, storage, licensing, permissions, cybersecurity, retention, remote access, alert routing, firmware planning, operator training and human verification. It also means telling the customer when an AI feature is not the right tool for the problem.

I have sat with customers who wanted the newest analytics when what they actually needed was better camera coverage, access-control discipline, lock hardware, intercom workflow, network reliability, or after-hours procedures.

I have also seen skeptical customers whose use cases showed that analytics genuinely reduced investigation time. The point is not to be pro-AI or anti-AI.

It is to be honest.

What Leaders Should Measure

Security leaders should require metrics that map to outcomes, not marketing language.

Measure detection performance by use case. Measure false positives by camera and condition. Measure missed detections against known events. Measure alert-to-action rates. Measure time saved against the old process, not against a sales claim.

Measure operator trust, too, because if responders do not believe the system, the deployment has failed operationally.

Measure governance as well:

• Are roles defined?
• Are permissions reviewed?
• Are vendor accounts controlled?
• Are logs audited?
• Are AI settings documented?
• Are retention rules followed?
• Are exceptions reviewed?
• Is human verification required before consequential action?

That last question may be the most important. AI effectiveness is not only technical. It is organizational.

Buy Capability, Not Theater

The security industry has always been tempted by theater: visible cameras, impressive dashboards, dramatic demos, big words, and clean promises. AI can make that temptation stronger because the language sounds advanced even when operational proof is thin.

Executives should resist it.

Ask simple questions until the answers become specific:

What exactly does it detect? Under what conditions? What does it miss? How do we know? What happens when it is wrong? Who verifies it? Who can change thresholds? Who can export video? Who has access? What evidence proves performance in our environment?

Good vendors and integrators should welcome those questions.

I often return to a principle that guides how I think about security: We should care about the reality of good, not its perception.

AI can make the appearance of safety more convincing because it suggests the system is watching, thinking and deciding. But if the design is poor, governance is weak, alerts are ignored or decisions are not human-verified, the organization has not improved security. It has only improved the appearance of sophistication.

AI will become a normal part of security. The winners will not be the organizations that buy the most AI. They will be the organizations that test it, govern it, measure it and keep human judgment where the consequence demands it.

If the system cannot prove the outcome, it is not capable yet. It is a claim.