On-premise computer vision inference when the footage cannot leave the fence

The utility's security team said it in a Tuesday meeting. The refinery's said it in a written policy that predates the cameras. The shipping company's said it by pointing at the satellite link, which is metered by the megabyte and shared with the crew's email. Three sites, one sentence: no camera footage leaves this network. The vision project at each was, for a while, assumed to be over.

Each of the three now runs a model on its own footage. What changed was the shape of the deployment rather than the policy, and the shape is worth describing plainly because it is the first thing a security team asks for and the last thing a vision pitch explains.

The model runs on your servers, managed by us or run by you

The first shape is the refinery's. The model runs on servers inside the plant's network, in the same rack room as the recorder it reads from, and the streams from the cameras on the pipe racks and the loading bays never leave that room. Who runs those servers is a separate choice: we manage them, patching the software and rolling out versions over a connection the plant's team controls, or the plant's own team runs them and we ship the versions for them to install.

For the security review, the diagram is the argument. The video path starts at the camera and ends at the server, both inside the perimeter, and the only line that crosses the fence carries results: an alert to the plant's Slack, a doubted frame to review, a new model version coming in. The security page is that diagram in prose, and the refinery's team signed against it after a week with the document rather than a quarter of meetings.

A runner beside the recorder is the smaller version of the same answer

The utility's substations and the ship have no rack room. What they have is a recorder in a cabinet, and the second shape puts a runner beside it. The runner is a small box on the same network as the recorder that reads its streams, draws the boxes, applies the alert rules and fires the alerts, on site, without depending on the link out. On the ship the runner fires the alert to the bridge whether or not the satellite link is up, and sends the frame ashore when it is.

The runner is the same model, watching the same stream, applying the same rules. What differs is that there is one per site rather than one per fleet, and so the bookkeeping about which version each runner is on matters more, which the fleet manager learned in January. The deployment doc covers what leaves and what stays: the footage is processed where it is captured, and what leaves is the answer.

The shipping company's crew email photographs at thumbnail size because of that metered link, and the first question the fleet manager asked was how many megabytes a month the runner would send. The answer was the doubted frames and the alerts, which is a number that fits on the same line as the crew's email.

Only the doubted frames leave and they are the one thing that must

The traffic rule under both shapes is the same. Every frame the model is sure of stays on site and is never sent anywhere. The frames it is unsure of, a stain on a flange that might be a leak, a figure at the substation fence that might be a person, go to a review queue where a person confirms or corrects the box Lexi proposed. Those are the frames that leave. They are a small fraction of what the cameras see, and they are the ones a person needs to look at regardless.

This is the part of the design a security team should be shown rather than told, because it is also the part that keeps the model honest. The corrections made on those frames are what retrain it, and a model whose doubted frames never left the fence would be a model nobody could correct, drifting through its first winter with no way back. On the sites we run, the review queue is the single crossing point, and the review is done by the site's own people, on the site's own guideline, so that even the doubted frames are looked at first by someone inside the fence.

Sign-on is your identity provider and access is by role

The second question every security team asks is who can log in. Sign-on is through the customer's own identity provider, so an account that is disabled in the plant's directory on Friday afternoon is disabled in the review queue at the same moment, and nobody at the vendor holds a password for it. Access is by role: a substation technician sees the substation's cameras and its queue, a regional manager sees the region, and the person who approves alert rules is a named role rather than whoever was in the room.

Role-based access is also what makes the alert approval meaningful. A rule written as a sentence, with a severity and a cooldown, goes live only when someone with the approving role has read it, and the record of who approved it is a record the security team can read.

Ask a vendor for the diagram rather than the certificate

My own view, and I say it as the person who has to answer these reviews, is that a security team learns more from a network diagram with the video path drawn on it than from any certificate a vendor can attach. A certificate says a process exists. The diagram says where the pixels go, and a reviewer can check it against the switch configuration on a Friday afternoon. So ask for the diagram, ask which line crosses the fence and what travels on it, ask who holds the sign-on, and ask what the runner sends in a month in megabytes. Those four answers are what the refinery, the utility and the shipping company signed against.

Ask for the attestations too, with the paper attached, and score a plain no as a plain no. What does not belong on the scoring sheet is a promise.

Versions and the loop still cross the fence in one direction each

The last thing a security team needs to see is how the model changes. Under either shape, the corrections from the review queue count toward the project's threshold, and a new version trains on the original set plus the corrections. It is checked per class against the running version, then sent to the servers or the runner, where it replaces the old one with no downtime. The version travels inward, the doubted frames travel outward, and nothing else crosses in either direction.

LexData takes the model through its whole life inside that arrangement. You type what to look for, Lexi puts a box on every frame, and a person checks each label before anything trains on it. The model then watches the cameras the site already has, on your servers, or on a runner beside the recorder, or in the cloud where the policy allows it. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime.

The refinery's pipe rack model went through three versions in its first year without a frame of its footage leaving the rack room, which is the sentence the security team wanted to be able to write.