AI and surveillance is a debate about capability. It should be a debate about the byte budget.

The byte budget is the concrete volume and content of data that leaves the watched property per unit time. It is the only part of an AI surveillance system that is actually visible from outside the property, and it is what decides whether a system can be subpoenaed, correlated across sites, retained by a cloud vendor, or leaked in a breach. A system that uploads every camera's continuous stream to a cloud region at 2 to 6 Mbps per camera has a byte budget measured in tens of gigabytes per day and retains frames indefinitely. A system that emits only a per-event thumbnail, a short clip, and a JSON metadata blob has a byte budget measured in hundreds of kilobytes per event and retains nothing at rest off-property. The first is mass surveillance by construction. The second cannot be, because the bytes required to do mass surveillance never left the building. Features do not decide this. The byte budget does.

Approximately 240 KB, in three parts. One JPEG event thumbnail at roughly 18 KB (a single still frame captured at the moment of detection, labeled with the tile coordinate it came from). One H.264 event clip of roughly 6 seconds at roughly 220 KB (the window around the detection, not continuous footage). One JSON metadata blob of roughly 612 bytes (event id, property id, timestamp, detection class, bounding box, confidence, tile index). That payload lands in an operator's WhatsApp or the Cyrano dashboard. No frames before or after the event window leave the device. No full-resolution multiview frame leaves the device. No biometric embedding of any person or vehicle in that frame leaves the device. The 240 KB is the entire off-property footprint of one detection.

Five things are out of scope by design. One, face embeddings against an enterprise gallery (no face-matching index is built or uploaded). Two, license plate OCR vectors (plate text is not extracted into a searchable index). Three, gait or pose signatures across time (no re-identification vectors are produced). Four, cross-site correlation identifiers (no shared person id is issued across properties). Five, indefinite retention of frames at rest off-property (no full-frame archive is kept in a cloud region). The detections the pipeline does run (person present, person in a restricted zone, loiterer, package left unattended, tailgating at an entry, after-hours presence) are class and zone rules on the composite HDMI multiview frame. These run, they trigger the 240 KB event payload, and the source frames are discarded on-device.

Inference location decides where pixels live. A cloud-AI system opens an RTSP or ONVIF session per camera, uploads every frame continuously to a cloud region, and runs inference on the cloud. Every pixel crosses the property boundary, and every frame is at rest somewhere in the vendor's storage. An edge-AI system runs inference on-device, on-property, on the composite HDMI frame the DVR already renders. The source pixels never cross the property boundary. Only the small, human-readable derivatives of an actual detection (a still, a short clip, a metadata blob) cross the boundary. The byte budget is smaller because inference is local. That is the single architectural choice that converts the shape of the system from mass surveillance to event detection.

Five checks. One, ask the vendor to publish the per-event payload schema in bytes and the per-frame upload rate in bits per second. A vendor that cannot quantify both has not measured its own byte budget. Two, measure the upstream bandwidth on the property's WAN before and after install; an edge-inference system should not move the baseline by more than the event rate times the event size. Three, read the vendor's data processing agreement for the words biometric, embedding, gallery, retention, and correlation; these are the words that separate event detection from mass surveillance. Four, run a Wireshark capture on the device's uplink for one hour and sum the outbound bytes; compare against the vendor's claimed budget. Five, ask whether the frames at rest in the cloud can be retrieved on demand. If yes, the byte budget is effectively continuous. If the vendor says no frames are retained, the budget is event-bounded.

Because the literature on AI and surveillance is mostly produced by policy researchers, not by people who install the systems. Brookings, the ACLU, the AJL, Carnegie, and the Decision Lab frame the debate at the level of capability (can the system recognize faces, can it predict behavior, can it target a population). That is the right level for a law or a norm. It is the wrong level for a property-scale procurement decision, because every vendor in the AI surveillance category has roughly the same capabilities on paper, and what actually separates them is whether they exfiltrate the source pixels that a capability would need. The byte budget makes the abstract capability argument concrete. A system that does not upload face pixels cannot match faces, regardless of what its marketing page claims.

Yes, for the detections that a mid-market multifamily, construction, or small commercial property actually needs. Those are class and zone detections, not identity detections. Was there a person in the trash area at 3 AM, was a package left unattended for 40 minutes, did someone tailgate through the gate, was the pool occupied after hours, is the construction site awake when it should be asleep. All of those are answerable from the composite multiview frame with class detection plus a zone rule, and all of them trigger a 240 KB event payload that is useful to the operator in real time. The detections that require a full-identity pipeline (matching a specific individual by face across thirty sites, building a retail customer profile from gait) are out of scope, because they are the detections that require mass surveillance bytes.

The apartment-security-cameras.com/llms.txt spec publishes the hardware and software contract, including the edge-AI data path. The install write-up on /t/ai-surveillance-company and /t/ai-surveillance-companies shows the five-cable install sequence on a running DVR and identifies the exact uplink path used (ethernet on the device's LAN port, for the control plane and event egress only). The public demo at cal.com/cyranohq/s4l-demo walks through a live event delivery end to end, from composite frame to WhatsApp message, in roughly 1.1 seconds of latency. The event payload is visible in the delivered notification itself (thumbnail plus short clip plus metadata); there is no hidden second channel.

Latency and byte budget trade off against each other on cloud-AI systems (more frames uploaded faster means more bytes leaving the property) and are independent on edge-AI systems. Cyrano's end-to-end detection to operator notification latency is roughly 1.1 seconds, because inference runs on-device and only the 240 KB event payload needs to egress. That is measured from the moment a person enters a zone to the moment a WhatsApp notification buzzes on an operator's phone. A cloud-AI system that moves frames continuously also achieves low alert latency, but at a byte budget two to three orders of magnitude larger, because the inference happens on the other side of the upload. Edge inference is the architecture that produces both low latency and a small byte budget at the same time.