Sensor data needs a specific purpose
A camera prompt names a device but seldom explains what the product will infer. Placing a wheel, tracking a hand and matching a face to an account serve distinct purposes and carry different risks. Follow each signal from capture through use, storage, access and deletion.
Separate raw from derived data: frame, voice, pose, gaze, face embedding and event log may need different access and retention. A vector can remain sensitive if linked to a person or used to infer identity. Test a vendor's anonymity claim against actual identifiers and access paths.
Inventory purposes before selecting sensors. Check whether a less intrusive input works. If a button can confirm a financial action, gaze data is unnecessary for it; if a room anchor can be calculated on-device, sending room images needs a separate justification.
New Zealand distinguishes biometric processing from general sensing
New Zealand's Biometric Processing Privacy Code 2025 sits under the Privacy Act and covers automated use of biometric information to verify identity, identify someone or categorise them. The Privacy Commissioner includes physical and behavioural features such as face, fingerprint, voice, gait and typing patterns.
Moving a panel with a headset gesture differs from identifying an account by face. Commissioner guidance gives examples of basic detection or consumer immersion outside biometric categorisation under the Code, while the Privacy Act may still cover personal data. Review actual purpose rather than a marketing label.
By October 2026, the Commissioner said the Code had operated since November 2025 and the transition for existing users ended in August 2026. A 2026 amendment also addressed a new information privacy principle. Check the current Code and guidance rather than an older vendor assessment.
Necessity, effectiveness and proportionality
For covered processing, state the lawful purpose and why data is necessary. Test effectiveness, less intrusive alternatives and impacts on players and staff. Faster check-in or better operator analytics alone do not establish that the privacy cost is justified.
Complete a privacy impact assessment before deployment. Map collection, use, storage, vendors, overseas transfers and deletion. Include every person visible in video, including family, flatmates or workers who did not choose to use the game.
Privacy design record for immersive sensors
- What is the purpose?
- Evidence to retain:Named user task and system function tied to each sensor.
- Is biometric processing involved?
- Evidence to retain:Definition check against verification, identification and categorisation.
- Is collection necessary?
- Evidence to retain:Alternative-input assessment and effectiveness evidence.
- What data leaves the device?
- Evidence to retain:Network map, vendor list, destination and access roles.
- How long is it retained?
- Evidence to retain:Retention schedule by raw sample, derived feature and incident record.
- How can a person exercise rights?
- Evidence to retain:Access, correction, complaint and deletion workflow where applicable.
Minimise and secure every data layer
Where reliable, process locally to reduce transfer; crop to relevant objects, blur unrelated faces or avoid storing video if event records suffice. Separate samples from account IDs, encrypt data and restrict access by role. Log privileged searches.
Assign retention a purpose and expiry. Routine frames may be short-lived; disputes or legal duties may require a defined hold. Apply deletion to backups and vendor copies too, and audit exceptions so a legal hold does not become indefinite storage.
Review overseas transfers and subcontractors. Headset SDKs may send telemetry, crashes or derived motion. Document control, use, incident notice timing and deletion when service ends.
Notice should describe the system people encounter
When a camera or microphone is active, tell users which feature needs it and whether raw data leaves the device. Explain optionality and what refusal changes. Replace vague wording about improving experience with the actual data use.
Place short notices near the interaction, with further detail in the policy. Explain the current camera, hand or voice feature, provide permission review and deletion for optional data, and update notice before software starts collecting a new signal.
Give separate notices to account users, staff and live dealers, whose rights and expectations differ. A studio sign may not explain collection to a remote headset user.
Keep biometric outputs away from gambling-risk inference
Gaze, face, voice and motion can be used to infer attention, emotion or fatigue, but those conclusions may be inaccurate and intrusive. Do not personalise wagers or classify readiness to continue without a necessary, lawful and evidence-supported purpose.
Gaze may aim a cursor but cannot show a player read odds; expression may shift with lighting or headset fit and cannot establish gambling harm. Define the required signal and limit processing to that purpose instead of building a broad profile.
Keep people involved in high-impact reviews. A score should not automatically restrict an account or change game access without legal basis, accuracy evidence, notice and an appeal path.
Privacy controls are part of the game interface
If users refuse camera, voice, hand or gaze data, retain an ordinary route to play and manage accounts. Offer button authentication when adequate. Keep account settings outside the renderer so scene failure cannot block privacy or support requests.
Use credentials, multifactor options and logged recovery for account security where they suffice. Do not gather body data for a job handled by ordinary authentication. Document method and retention separately from game analytics.
- List sensors and SDKs in a maintained inventory.
- Check permissions in production builds on each supported device.
- Verify that declining optional sensor access does not disable unrelated account functions.
- Test access and correction requests against both primary and vendor stores.
- Review the data map after every runtime, analytics or identity-provider change.
Data minimisation governs collection; account access logs govern who can inspect or alter retained records. Keep those functions related but distinct.
Prepare for access, correction and deletion requests
Maintain a locator for samples, vectors, events and vendor copies using identifiers the organisation actually holds. Staff need to know each record's owner and retention duty. Requests should not depend on searching informal backups.
For inaccurate biometric records, preserve a correction process. Where audit requires it, retain old and corrected values, reason and time, and update downstream services that used the first value.
Exercise correction before launch with an example account, vendor, analytics store and incident archive. The Commissioner's Code addresses access, correction, accuracy, retention, security and disclosure for in-scope processing.
Separate consent records from sensor output
Represent sensor permission as a versioned choice tied to purpose. Retain that a choice occurred without retaining the image or motion stream. Withdrawal should halt future collection and propagate to recipients. Debug with synthetic or minimised records. Privacy and security teams need to trace device capture through use, storage, access, vendor processing and deletion.