Home / Blog / Physical AI memory boundary

Physical AI Needs a Memory Boundary

The privacy question is no longer just whether video is stored. It is what the system chooses to remember about the physical world.

Ashish SyalFounder, EdgentikUpdated September 27, 2026

What is a memory boundary in Physical AI?

A memory boundary defines which observations from cameras or other sensors become retained records, why they are kept, how long they survive, and whether they can be linked to a person. For industrial safety AI, it should preserve the evidence needed to find recurring conditions and measure change after action, while limiting unnecessary worker histories.

Illustrative concept. A memory boundary is not just about deleting footage; it defines what the system keeps after the observation is over.

The most important privacy question for camera-based AI is not simply whether the video is stored. It is what the system remembers after the video is gone.

Modern computer vision can turn a few seconds of footage into records about movement, location, proximity, dwell time, interactions and repeated behaviour. Those records may survive even when the original images do not. A system can therefore retain meaningful information about what people did without retaining their faces, names or continuous video.

Retail computer vision makes the issue especially clear. A system can observe that an unidentified person entered an aisle, stopped at a shelf, appeared to face one product for twelve seconds, moved to another display and then left. It may never know the person's name, never store their face and never retain the video. But it has still created a record of behaviour.

That does not make the technology inappropriate. It does mean that “we don’t store the video” is not, by itself, a complete privacy answer.

Why does deleting video not settle camera AI privacy?

We have mostly talked about camera privacy in terms of images: whether the video is stored, how long it's kept, whether a face can be identified, who has access. Those questions still matter. But the most valuable output of a modern camera system may not be the video at all. It may be the representation built from it.

Camera-based systems raise this in a particular way. Most operational software, an ERP included, knows about the physical world through what someone scanned, keyed in or confirmed. A camera can capture activity that nobody entered into any system: the pedestrian who cut across the aisle, the forklift that waited, the pallet staged in the walkway. That is its value, as I argued in The Undigitized Layer of Operations, and it is also why what gets kept matters.

One vision stack, three records: a condition at a place, estimated viewing at a shelf, flow at a dock.

The computer vision underneath is similar. The purpose of the record is not, and that purpose should decide what gets kept.

How do condition records differ from worker histories?

Take two systems watching the same warehouse. One asks what a particular worker did today. The other asks where pedestrians and forklifts keep coming close. They can start from many of the same observations, but they build different records. The first builds a history of a person: where they went, how often, and how they compare with a coworker. For that recurring-condition question, the second need not retain a persistent worker identity. It can keep the condition: a forklift and a pedestrian shared this space at this time.

The difference gets sharper over time. Suppose a system logs twenty forklift-pedestrian proximity events at one intersection. The same observations could be built into either of two records.

Illustrative data, not from an Edgentik deployment. Two possible records built from the same twenty events.

Grouped by person, the finding is that Worker 37 had six of them. Grouped by time at the location, the finding is that twelve of the twenty happened between 1 and 3 p.m. The first points attention at a person. The second points it at the operation. A person-level pattern might also reveal that someone’s assigned task repeatedly exposes them to a poorly designed route. The narrower point is that finding a recurring condition at this intersection does not require a lasting history of each worker.

Changing the chart alone does not create a memory boundary. A dashboard can group events by location while the underlying system still retains a detailed history of each person. The boundary must also govern the records beneath the chart: what is kept, how long it survives, and whether separate events can be linked to the same person.

The count alone doesn't say why, or even whether proximity is more likely in that window. If that is simply when the most forklifts and people move through the intersection, the count may be following traffic. So the first check is volume through the same window. After that, the questions worth investigating are operational: whether the route is badly designed, whether pallets block sightlines, whether a shift change brings a surge of traffic, whether staging pushes people into the forklift path. A barrier or a routing change might remove the condition entirely, and nobody needed to be named to find it.

For many recurring-condition safety questions, knowing who someone is is not necessary to identify the problem or choose a change. A specific incident investigation may require identity; finding where exposure keeps repeating is a different task. Edgentik’s design principle is to measure the condition, with records organized around the places and operating windows a site can act on.

Is anonymous tracking enough to protect worker privacy?

Not by itself. An unnamed identifier that persists for months can still build a detailed behavioural history. A temporary track used to establish that one event happened serves a different purpose. Calling either one “anonymous” does not explain what the system remembers. A buyer should be able to ask:

What is retained about people, events and locations, and why?
Can observations from different days be linked to the same person?
How long are video and the records derived from it retained?
Who can access evidence, and for what purposes?
What is deleted automatically, and what requires a separate action?
How can the customer verify that access and deletion rules work as agreed?

How does Edgentik turn safety events into evidence for action?

Edgentik uses suitable existing fixed cameras and an on-site Edge AI appliance to measure visible safety conditions. Its three views connect what is happening now, what keeps repeating, and what changed after action.

Edgentik is designed to help a site move from an isolated event to a recurring condition it can act on. A forklift-pedestrian proximity alert shows that a pedestrian and forklift came close. Records organised by location and operating window help reveal whether the same intersection repeatedly produces that exposure. After the site changes a route, moves staging or installs a barrier, those records support a comparison of what happened before and after action.

That is why Edgentik’s memory is organised around conditions. Temporary tracking establishes the event. Short evidence clips let someone check what was counted. Counts and durations support comparison of recurring safety patterns over time, with traffic volume and observation coverage considered when interpreting change. The lasting value is a record of where exposure repeats and whether it changes after action. Edgentik does not identify, rank or score workers; each type of record needs retention and access limits suited to its purpose.

Three types of records, three operational purposes
Record type	Operational purpose	Boundary to define
Temporary tracking	Connect observations long enough to establish an event.	When the track expires and whether it can link separate events.
Evidence clips	Let a reviewer check what the system counted.	Who can access clips, for what purpose, and when they are deleted.
Condition records	Find recurring exposure by place and time, then compare observations after action.	Retention, time and location detail, and potential linkage back to people.

Before deployment, retention, access and deletion rules for these records need to be agreed with the site and verified in the system. A policy statement alone is not enough. Identification risk also extends beyond video: on a small shift, a timestamp and location may be enough to recognize someone. Condition records need the same care as the clips behind them. See Edgentik’s security and trust overview for the wider deployment discussion.

What should industrial safety AI remember?

A safety system should retain the event evidence and condition history needed for its stated operational purpose, with limits on retention, access and person-level linkage. More detail is useful only when it improves the decision the site needs to make.

Technology tends to assume that more information makes a better system. Knowing the name of the person standing near a forklift does not, by itself, explain why proximity keeps recurring at that location. A well-designed safety system understands enough of the physical world to answer the operational question, then limits what it retains to that purpose.

This will matter more over time, not less. Multi-camera tracking, spatial reconstruction and activity recognition are all improving. The question will increasingly shift from "can we measure this?" to "should this become part of the system's memory?"

Every Physical AI application, whether in warehouses, plants, ports or stores, carries the same responsibility: a clearly drawn memory boundary. What does the system need to know? What does it need to remember? For how long? And about whom, or about what? Written down, that boundary is also the document a site can put in front of its joint health and safety committee or union representative before the first camera goes live.

For industrial safety, our answer is deliberately narrow. Understand the physical condition. Find where it keeps repeating. Help the site act. Then measure whether the condition changed.

What a system remembers shapes what it can later be used to do.

See the condition, the pattern and the change

Explore how Edgentik connects current observations, recurring exposure and follow-up after a site takes action.

Explore the illustrative safety operations view · Book a demo