Foundations 03Technical ArticleGaitAI Research5 min read
Can AI Understand Movement Without Identifying the Person?
Many movement-intelligence tasks do not inherently require identity. A privacy-aware architecture starts by asking what information the task actually needs — and then declines to retain the rest.
Before you scroll: this essay separates two things that are usually bundled together — sensing movement, and identifying a person.
Drag the track, tap a stage, or use ← →
Raw RGB. Movement information High. Identity-bearing visual information High.
Text description
A seven-stage slider from identity-rich to movement-minimised. Raw RGB: a camera frame of a person walking past a wall — high identity-bearing visual information, high movement information. Face redacted: the same frame with the head blocked out; still high identity (clothing, build, gait visible), high movement. Silhouette: the walker's foreground mask cut from that frame — medium identity, high movement. Pose landmarks: low identity, high movement. Skeleton: lower direct visual identity, high structural movement information — but pose and gait can themselves carry identifying information. Trajectory: minimal image information, medium temporal movement information retained. Minimised output: low identity, low movement — a count, a flow or an event leaves the system. Privacy properties depend on implementation, storage and deployment context, not on the diagram.
Short on time? Read the 2-minute version
- For most movement questions, identity is not the objective.
- Sensing and identification are separable stages, and separating them is an architectural decision, not a setting.
- Skeleton-only processing, face blur, retention limits and access control belong in the pipeline rather than on top of it.
- Identity-bearing capability exists for cases with lawful authority, consent and an audit trail — and is governed accordingly.
- More privacy does not have to mean less intelligence: most of the signal survives the abstraction.
The full article follows, with the diagrams and the caveats.
Computer vision has historically been rewarded for seeing more.
Higher-resolution images. More visual detail. Longer retention. More identifiers. Each of those has been treated, at various points, as an unambiguous improvement.
Privacy-aware movement intelligence begins with a different question:
What is the minimum information required to solve the task?
It is a design question before it is a compliance question, and answering it honestly changes the architecture rather than the wording of a policy page.
Identity is not always the objective
A surprising share of movement-analytics problems turn out to be questions about motion in a space rather than questions about people:
- Crowd-density estimation does not inherently require anyone's name
- Queue analysis does not inherently require face recognition
- Fall-event detection does not inherently require persistent identity
- Movement-flow analytics generally require motion patterns, not personal identity
Where identity is not required by the task, collecting it is not a bonus. It is an unnecessary liability attached to a system that would work without it.
Separate sensing from identification
The practical move is to place a deliberate transformation between the sensor and everything that follows it, so the analytics layer never receives identifying detail in the first place.
Depending on what the deployment permits and what the task requires, that transformation can draw on:
- Face blurring or redaction at or near the point of capture
- — retaining geometry while discarding appearance
- Pseudonymous track references instead of direct personal references; linkage and movement may still permit identification
- Short-lived track identifiers that maintain continuity within a sequence, then expire
- Aggregated metrics where only counts, flows or rates leave the system
Each of these is appropriate in some contexts and not in others. The point is not that a single technique solves privacy — it is that the choice belongs in the architecture, and should be made explicitly, for a stated purpose.
What exists here
Face redaction, skeleton extraction, short-lived track identifiers, aggregation — applied at or near the edge.
Why it exists
So the analytics layer never receives identifying detail in the first place, rather than filtering it out at the end.
What could be removed
Appearance: face, clothing, colour, background. Persistent identifiers where the task needs only continuity within a sequence.
Where privacy risk remains
The transformation itself must be trustworthy and applied before storage. A skeleton is not anonymous; pose and gait can carry identity.
Text description
Six pipeline stages: raw sensing, privacy transformation, movement representation, analysis, minimised output, human decision. Each stage lists what exists there, why it exists, what could be removed, and where privacy risk remains. Risk is highest at raw sensing and never reaches zero: even a minimised output can be joined with other data, and a human decision can over-trust a confident-looking output.
Privacy by architecture
Privacy properties that depend on operator discipline tend not to survive contact with production. Properties enforced by the structure of the system are more durable. The principles we design against:
- Data minimization — capture and retain only what the task requires
- Purpose limitation — a system built for one question should not quietly answer others
- Configurable retention — retention as an explicit, reviewable setting, not an accident of storage
- Access control — who can see what, enforced rather than assumed
- Auditability — a record of what was accessed, and by whom
- Role separation — operating a system and re-identifying individuals are different privileges
When identity may legitimately matter
It would be dishonest to argue that identification should never exist. Access control, authorized investigation and consented clinical records are real requirements, and pretending otherwise simply pushes them into tools with weaker safeguards.
The argument is narrower and firmer: identification is a distinct capability with distinct obligations. Where an application genuinely requires it, it should carry:
- A legitimate, stated purpose — documented before deployment, not inferred afterwards
- Explicit governance — a named owner and a defined review process
- Appropriate authorization — for the specific setting and jurisdiction
- Stronger access controls than the surrounding analytics
- Stricter retention — shorter, enforced and auditable
The mistake is not building identification. The mistake is building it by default, into systems whose actual task never asked for it.
More privacy does not have to mean less intelligence
The assumed trade-off — that protecting privacy necessarily costs analytical power — holds far less often than it is invoked.
Often sufficient
Movement representations
- Pose and joint geometry
- Trajectory through a space
- Motion dynamics over time
- Aggregated flow and density
Rarely required
Full visual identity
- Recognizable facial imagery
- Persistent personal identifiers
- Long-lived raw video retention
A fall event has a movement signature. A queue has a flow signature. A crowd has a density signature. None of those signatures is made sharper by knowing a name. The PrivacyGuard capability within SecureVision exists to make that separation a configuration rather than a promise.
Privacy-aware AI is not AI that sees less intelligently.
It is AI designed to retain only what the task actually needs.
Written by GaitAI Research. GaitAI produces movement measurements and decision-support outputs for research, clinical and operational teams — not diagnoses. Published research is listed in the publications library.
GaitAI Foundations · 3 of 5
You now know that sensing movement and identifying a person are separable stages, and that the separation is an architectural choice.
Next
If one reading is never the whole story, what does change over time tell us?
Foundations 04A Fall-Risk Score Is Not EnoughWhy change over time mattersContinue