Case study · anonymised

AI-assisted surveillance: cloud for meaning, edge for frames

A video surveillance and access-control platform where detection is computed on site and only events leave the perimeter, never the video stream. The operator gets a short list of what actually needs a decision instead of a wall of tiles.

31.8 ms
p95 detector inference on the on-site node
3.3×
throughput headroom at the observed motion peak
−37%
detection latency after changing the node class
0
skipped detection frames in steady state
00

In brief

Who it is for
  • Companies with several sites and cameras already installed: retail chains, warehousing and logistics, manufacturing.
  • Sites with no decent link and no staff on watch: remote locations, construction, energy assets, car parks.
  • Facility managers and office landlords, plus integrators and surveillance operators who need an AI layer over an existing fleet.
What it does and why it helps
  • Recognises events on site and delivers a short list of facts instead of a video wall.
  • A shift digest, access-to-video pairings, and alerts on anomalies.
  • Response at the moment, not during review; link and storage cost an order of magnitude less; frames never leave the site; every site and vendor lands in one picture.
How it works (detail in the cards)
  • Detection runs on an edge node next to the cameras: x86 with hardware decode, an NPU board, or an edge GPU module — chosen by measurement, not by datasheet.
  • Only hundreds of bytes per event cross the link; the journal is written before delivery, so the tail catches up by itself once the link returns.
  • The platform is multi-tenant: isolation enforced by database privileges, de-identification before any model call.
Delivery timeline
  • 1–2 weeks — measurements on your streams and the node class decision, before any hardware purchase.
  • 3–6 weeks — a pilot on one site: edge node, events, digest and alerts.
  • days — rolling out to the next site from the proven template.
  • 2–4 months — a multi-tenant platform with AI analysis, roles and billing, up to pilot operation.
The timeline reflects our own deployments; a firm estimate appears once we have measured your streams. Below is the same case in detail: the architecture, measurements across three node classes, model acceptance, and the honest limits.

This case is assembled from several deployments and internal engineering contours. Customer names, vendors, addresses and infrastructure parameters are withheld; every figure quoted is our own measurement on real streams.

01

The situation: cameras everywhere, surveillance nowhere

A typical site has between ten and a hundred cameras, a recorder, an access-control log and one person who physically cannot watch every stream at once. In practice the video works as a post-mortem archive: people open it after an incident to understand what already happened.

Once there is more than one site, a second problem appears: each has its own recorder, its own account, its own camera and controller vendor. Neither the security team nor the owner has a single picture.

  • Retrospective response. The event is discovered during review, not while it unfolds.
  • Link cost. Pushing streams to the cloud from a remote site is expensive, and over a cellular link it is prohibitive.
  • Privacy. The more frames leave the site, the wider the personal-data perimeter becomes.
  • Vendor zoo. Cameras and access controllers from different manufacturers do not add up to one picture.

The job we took on: not "show more video", but reduce the amount a human has to look at down to a list of facts that require a decision.

02

Architecture: three layers instead of one cloud

The "everything in the cloud" reflex breaks against physics: a video stream is the most expensive possible way to transmit a fact. So the contour is split into three layers, and each one solves its part where it is cheapest.

 SITE (edge)                      LINK             PLATFORM (cloud or private)
 ─────────────────────────────    ──────────       ───────────────────────────────
 cameras ─► hardware decode         events           multi-tenant storage
            detection (NPU/GPU/CPU) ~hundreds    ─►  AI shift analysis (agents)
            event journal on disk   of bytes         video-to-access correlation
 access  ─► local rules             instead of       digest, alerts, roles, audit
            │                     Mbit/s                  │
            └─ frames and recordings stay on site         └─ only de-identified data leaves
        
  • The edge sees frames, computes detection, keeps recordings and keeps working when the link drops.
  • The event gateway turns a stream of detections into a stream of facts and guarantees their delivery.
  • The platform merges sites and vendors into one picture, analyses the shift with an AI pipeline, enforces roles, and keeps the audit trail and billing.

The layer rule: only what cannot be computed below is passed upward. A frame is the lowest layer; meaning is the highest.

03

The edge: local inference next to the cameras

The edge layer has been built and measured on three node classes. The class is picked from an end-to-end measurement on the site's real streams — decode, pre-processing, inference, post-processing — not from the datasheet TOPS number.

Node class Typical role Measured behaviour When we choose it
x86 node with hardware decode
4 cores · iGPU
On-site recorder: a group of cameras, recording, detection p95 31.8 ms per detector across two parallel workers, zero skipped frames; the GPU video engine sits at 3.3%, and recording is a stream copy with no transcoding There is a rack and power; an on-site archive is required
SoC board with a ~1 TOPS NPU
1 core · 180 MB RAM
Autonomous point: one camera, poor link, cabinet or pole mount A light specialised model at 26.6 ms (the camera frame rate is the limit), a general-purpose detector at 88.5 ms ≈ 10 frames/s; capping the NPU branch dropped core load from 87% → 47% No room or power for a server; the link is cellular or satellite
Edge GPU module
tens of TOPS · CUDA
Heavy models: recognition, embeddings, archive search Optimised engines are built on the device itself, and accelerator attestation is fail-closed: the node refuses to start when the GPU is held by another workload instead of silently falling back to CPU Complex models and semantic search are needed on site

Three engineering lessons that save hardware

  • The cheapest win is not decoding what you will throw away. Camera sub-streams were set at the source to 5 frames/s instead of the stock 15–25: the decoder must unpack a frame before the frame-rate filter can drop it. One camera-side setting cut decode work roughly threefold, with no accelerator purchase.
  • Sensor to NPU with no decode at all. Where the camera is attached to the board directly, frames go from the image pipeline straight into the NPU while a hardware encoder serves the live view. Nothing in the contour decodes, and showing the picture costs no CPU time.
  • Headroom is sized against the peak, not the average. A single detector would leave only 1.6× headroom over the observed motion peak; two detectors give 3.3×. Saving one worker would have cost dropped frames at exactly the moment the system exists for.

A trap we paid for: on some budget vendors the standard camera-management protocol silently rewrote the codecs of both streams while continuing to report the old values. The cure: drive the change through the vendor channel, preserve the entire settings object, require an exact read-back, and reboot cameras one at a time with verification against the real stream.

04

Events, not frames: what actually crosses the link

Storing and shipping per-frame detections is pointless: at 15 frames per second that is a stream, and on a metered link it is a line item. Between the detector and the platform sits an aggregator that reduces detections to state changes: an object appeared, how long it stayed, what the peak count was.

  1. Hysteresis in both directions

    An appearance is confirmed by three consecutive frames, a disappearance by three seconds of absence. Without the first rule, one bad frame invents an event; without the second, detector flicker produces a queue of them.

  2. Disk first, network second

    The event is written to a local journal before any delivery attempt. With no link, the data stays on the device; the unsent tail is caught up from a stored offset and survives a reboot. A dropped link never costs an event.

  3. Fallback link with no manual switching

    The interface is never forced: routing metrics make the cellular network an automatic backup for the wired link. Verified by removing the wired routes — the event went out over the cellular interface, and the event itself records which link delivered it.

  4. The device does not carry a human password

    TRUST BOUNDARY

    Event ingestion is authorised by a dedicated device token rather than an operator account. The web interface and the ingestion endpoint use different authentication mechanisms, so compromising a board on site does not hand over the console.

What this changes economically: the link carries hundreds of bytes per fact instead of megabits per second per stream. The cost of connecting a remote site stops scaling with the number of cameras and starts scaling with the number of events.

05

The platform: multi-tenancy and AI shift analysis

The top layer is a multi-tenant SaaS: video and access-control events from different customers' sites merge into one picture where AI agents proactively tell the operator what deserves attention.

Isolation lives in the database, not in the application

  • A schema per tenant — every customer's data lives in its own database schema.
  • A role per tenant — the application connects with a service account and switches role on every transaction. A cross-tenant query fails on database privileges even when the application code has a bug.
  • Source adapters — cameras and access controllers from any vendor connect through one adapter layer, so replacing a vendor does not rewrite the product.

The analysis pipeline: five agents, one result

A nightly run turns the shift's event stream into a report: normalisation and de-duplication, then anomaly hunting against a seven-day baseline, then correlation of access events with video within a ±10-second window, then a written "what happened today" narrative, and finally operational suggestions such as dead cameras or overloaded doors.

Privacy at the model boundary

  • De-identification before the call. Card identifiers, employee names, phone numbers, e-mail and IP addresses are replaced with stable tokens before anything leaves the application contour.
  • A remote model never receives raw names — this is enforced in code, not in a prompt. A local model may see real names when narrative quality justifies it.
  • Audited invocations with a bounded retention window, encrypted secrets at rest, a per-tenant token budget with warning and blocking thresholds, a response cache, and a circuit breaker that trips on a failing provider.

Abuse testing: an adversarial prompt-injection suite (zero-width characters, encoded payloads, "ignore previous instructions") asserts two invariants — no personal data in the output, and no agent action outside the declared tools.

06

Acceptance: how we reject our own hypotheses

The most valuable part of this case is not what we shipped but what we did not. We tested the hypothesis that a specialised person / vehicle / bicycle model would beat the current lightweight detector.

  • We built a private corpus of 32 real site frames — eight per camera, all with genuine detections.
  • The incumbent model matched 30 of 32 boxes. The candidate, in its best configuration, matched 20 of 32.
  • Through the product's stock output parser the candidate matched 0 of 32: an incompatible output tensor layout that would have required a dedicated adapter.
  • The quantised variant of the candidate was faster than its own full-precision version but still three times slower than the incumbent.

Decision: candidate rejected, production untouched. The acceptance rule is now written down — a new model ships only if it beats the incumbent through the real path, including the product's pre-processing and parser, on a held-out day / night / infrared / rain sample, with false positives evaluated separately.

The same principle governs the accelerator layer: a node does not "try" the GPU, it demands evidence that the accelerator really initialised and the model really loaded onto it — otherwise the launch is refused. A silent fallback to CPU is forbidden, because it turns a measurable system into an unpredictable one.

07

Outcomes and honest limits

What the contour delivers

  • Response no longer depends on the link. Detection is local, so a connectivity failure postpones synchronisation instead of switching surveillance off.
  • Connecting a site costs an order of magnitude less — the link carries events, not video.
  • The personal-data perimeter shrinks. Frames stay on site; a de-identified description of the fact is what travels.
  • The operator reads a list instead of scanning a wall. A shift collapses into a digest with anomalies and access-to-video pairings.
  • Tenant isolation is demonstrable because it rests on database privileges rather than developer discipline.
  • Hardware is chosen by measurement. Three node classes cover everything from a single pole-mounted camera to a rack with an archive.

What we do not promise

  • "The AI sees everything" is never true. A model detects what has been confirmed on your own corpus, in your lighting and weather. Without that sample, any accuracy figure is marketing.
  • Datasheet TOPS is not a camera count. Capacity comes from an end-to-end measurement, not from arithmetic on an accelerator spec sheet.
  • We do not replace your recorder or access-control system — we add a meaning layer on top and a single picture across sites.
  • The promise equals the delivery. If a capability fails acceptance on your data, it ships neither to production nor to the slide deck.

The first step is usually cheap: one site, the cameras you already own, an edge node and two weeks of observation — enough to get measurements on your streams and decide which hardware class you need before purchasing any.

Five principles of the contour

The engineering rules everything above rests on.

PRINCIPLE 01

Compute where the data is

The frame is processed on site. Only what cannot be computed below is passed up the contour.

PRINCIPLE 02

An event, not a stream

The unit of exchange is a fact with hysteresis and duration, not a frame. The link stops being the bottleneck.

PRINCIPLE 03

Journal first, network second

An event survives a dropped link and a reboot. Delivery catches up from the stored offset.

PRINCIPLE 04

Fail-closed by default

With no proof that the accelerator initialised or the data was de-identified, the operation is refused rather than performed on a best-effort basis.

PRINCIPLE 05

Measurement beats specification

Models and hardware are accepted on an end-to-end measurement against real site frames. Datasheet figures are not acceptance.

Let us look at your surveillance contour

We review the cameras and links you already have, measure your real streams, and show which edge node class closes the job — before any hardware is purchased.

info@ai-automation.llc How security works