Where to Start

Most deployments in this field start with a demonstration. The order that works starts with counting what you already have.

The sequence

One: inventory. Every camera, every analytics deployment, what each does, who owns it. Expect surprises.

Two: check the vendor consoles for features enabled that nobody chose — demographic estimation and face detection are commonly on by default.

Three: define the question. What decision needs informing, and what is the least capable system that could inform it.

Four: establish the base rate. How often does the condition actually occur? Reviewing footage answers this and it is frequently the finding.

Five: survey the cameras against the intended task. Pixels on target, angle, lighting, occlusion.

Six: pilot, with ground truth and criteria written first.

Seven: then decide.

Nothing before step six requires a purchase.

The first ninety days

Weeks one to three: the inventory and the console check. This alone usually produces actionable findings — unowned deployments, unrequested features, notices that do not match reality.

Weeks four to six: define the question and establish the base rate by review.

Weeks seven to nine: the camera survey, and the arithmetic on alert volume using vendor figures.

Weeks ten to twelve: decide whether to pilot, and design the pilot so it can fail.

What the inventory finds

Consistently, and it is worth doing even if no new deployment is planned.

Deployments nobody owns.

Features enabled by default that would require an assessment nobody has done.

Pilots still running years later.

Notices describing recording where analysis happens.

Retention at vendor defaults.

Access held by people who changed role.

These are cheap to fix once visible and invisible until counted.

What to avoid early

Buying from a demonstration.

Starting with real-time alerting, which produces an unusable rate and no baseline.

Starting with an application involving identification, which is the hardest case and the worst place to learn.

Assuming existing cameras will do, which is the most common reason deployments underperform.

Treating a pilot as exempt from notice and assessment obligations, which is the most common compliance failure.

The governance to put in place first

The register, which makes everything else possible.

A gate: nothing goes live without a purpose, an owner, an assessment where required, and a notice.

A written position on identification, emotion inference and covert use, decided before it is requested.

An owner for the register.

None of this is expensive and all of it is much harder to introduce after a deployment exists.

The gate

The control that stops the inventory decaying the moment it is built.

Nothing goes live without: a stated purpose, a named owner, a tier classification, an assessment where required, a notice, a retention period, and a review date.

Owned by whoever approves operational changes, not by the person maintaining the register, or it becomes advisory.

With an exception route that records the reason and a remediation date.

Track exceptions, because a growing list means the gate is decorative.

What the first ninety days should produce

The output that justifies a second phase, or honestly ends it.

The inventory, with the findings it produced.

The console check result, including features disabled.

The stated question and the tier it requires.

The base rate, established by review.

The camera survey, with which positions can support the task.

The alert arithmetic.

A recommendation, which may be not to proceed.

No purchase required for any of it, and a recommendation not to proceed is a successful ninety days.