# Smart Glasses in the Workplace: DPIA, Procurement and Policy Checklist

Canonical URL: https://xpertdpo.com/smart-glasses-workplace-dpia-procurement-policy-checklist/

Content type: Article

Published: 2026-08-27T21:13:16+01:00

Updated: 2026-08-27T21:13:17+01:00

Author: Philipa Jane Farley, Head of Legal and Operations

Summary: A practical checklist for assessing smart-glasses use cases, suppliers, DPIAs, workplace controls, accessibility needs, restricted environments, retention, incidents and ongoing organisational oversight before approving a deployment or beginning a pilot.

## Article

*A practical approval route for DPOs, AI officers, security, HR, accessibility, procurement and operational teams considering smart glasses at work.*

 Smart-glasses governance becomes difficult when an organisation begins with a product demonstration rather than a defined use case.

 The same device may offer captions, translation, photography, live streaming, remote support, scene analysis and AI memory. Those functions do not share one purpose, one data flow or one legal answer. Approval should therefore describe exactly what the organisation is permitting, not merely identify the make and model it has purchased.

 Our companion guide, [Smart Glasses at Work: A Governance Guide for DPOs and AI Officers](https://xpertdpo.com/smart-glasses-work-governance-dpo-ai-officers/), explains the wider legal and governance position. This article turns that analysis into a practical assessment, procurement and policy route.

### Start with a Smart Glasses Use-Case Record

 Complete one record for each materially different function. Captioning, remote expert support and recording a training session should not be bundled into one approval simply because the same glasses can perform all three.

| Field | What to record |
| --- | --- |
| Function | The exact feature being requested, including sensor and AI capabilities |
| Purpose | The operational or accessibility outcome the organisation is trying to achieve |
| People | Wearers, colleagues, customers, visitors, patients, residents, children and other bystanders |
| Environment | Countries, sites, rooms, public areas, vehicles and remote-work settings |
| Frequency | Occasional, session-based, shift-based or continuous use |
| Data | Raw, inferred, generated and logged information |
| Data path | Glasses, phone, app, organisational tenant, vendor, cloud, model provider and support access |
| Roles | GDPR controller, joint controller, processor and subprocessor; AI Act provider or deployer; operational owner |
| Benefit | Evidence supporting the expected outcome and who benefits |
| Alternatives | Less intrusive ways to achieve the same result |
| Boundaries | Functions, locations, people and secondary uses that are not approved |
| Owner | Named service owner with authority to pause or stop the use |
| Review | Pilot end date, approval date, review date and change triggers |

 If the requester cannot complete the first four fields without using phrases such as "general productivity" or "AI assistance", the use case is not ready for assessment.

### Apply the hard-stop screen first

 Some proposals should not proceed to balancing or procurement until the organisation has resolved a basic legal or control problem.

 Stop and escalate where the proposed function involves:

- covert or disguised recording;
- workplace emotion inference outside a narrowly evidenced medical or safety exception;
- biometric categorisation intended to infer protected or sensitive characteristics;
- facial identification or other biometric identification without a separately approved lawful use case;
- continuous memory of workplace conversations, documents or environments without defined activation and retention boundaries;
- performance scoring or employment decisions using first-person sensor data without AI Act and Article 22 assessment;
- recording in toilets, changing areas, clinical treatment spaces or other places carrying a strong expectation of privacy;
- personal accounts or unapproved cloud services that the organisation cannot configure, audit or offboard;
- use that conflicts with local recording, interception or employee-representation law; or
- a device that is incompatible with required PPE or introduces an uncontrolled safety risk.

 The hard-stop screen is not the whole assessment. It prevents the organisation from spending weeks reviewing vendor terms for a use it cannot lawfully or safely approve.

> **Approval rule:** A prohibited or uncontrollable function does not become acceptable because the wider device has a useful feature.

### Decide whether a DPIA is required

 Camera-enabled and AI-enabled smart glasses will commonly combine several indicators of likely high risk identified in the Article 29 Working Party’s WP248 DPIA guidelines, which were subsequently endorsed by the EDPB: innovative technology, systematic monitoring, vulnerable data subjects, sensitive information, evaluation or scoring and people who may not reasonably expect the processing.

 The screening record should answer:

1. Does the function monitor a worker, customer or publicly accessible area systematically?
2. Does it process or infer biometric, health, disability or other special-category information?
3. Are children, patients, residents, workers or other potentially vulnerable people affected?
4. Does AI evaluate behaviour, attention, pace, safety, mood or performance?
5. Does the function combine data sets or build a persistent memory about individuals?
6. Can affected people avoid the processing or use an equivalent service without disadvantage?
7. Is the technology new to the organisation, sector or affected population?
8. Could an error, disclosure or misuse cause discrimination, employment effects, confidentiality loss, physical harm or significant distress?

 Two or more recognised high-risk criteria will ordinarily point strongly towards a DPIA. National supervisory-authority lists must also be checked. Where the organisation concludes that no DPIA is required, it should retain the screening rationale and revisit it when the function, environment or affected people change.

 The DPIA should produce decisions. It may require removal of a feature, local rather than cloud processing, shorter retention, a restricted zone, an alternative route for affected people, consultation, a smaller pilot or refusal of the deployment. A DPIA that merely repeats the product description has not done the work.

 If the DPIA still identifies high risk that cannot be sufficiently mitigated, Article 36 GDPR requires prior consultation with the competent supervisory authority before processing begins. The accountable owner should not treat referral as permission to leave avoidable risk in the design.

### Complete the AI classification and role check

 For every AI-enabled function, record:

- the intended purpose stated by the provider;
- the purpose adopted by the organisation;
- whether the organisation is acting as deployer or may acquire provider obligations through modification or changed intended purpose;
- whether a prohibited practice is engaged;
- whether the function falls within an Annex III high-risk area, including employment and worker management;
- whether the AI is embedded in a product covered by Annex I;
- whether Article 50 transparency duties apply;
- the human oversight and safe-failure arrangements; and
- the evidence and date supporting the classification.

 Do not defer classification because some high-risk rules have later application dates. The exact timetable, including the amendments made by Regulation (EU) 2026/1744, is set out in the [companion governance guide](https://xpertdpo.com/smart-glasses-work-governance-dpo-ai-officers/). Prohibited-practice and relevant transparency requirements are already applicable, while GDPR, employment, equality and safety duties apply independently. This timing position is correct as at 27 August 2026.

### Map roles and data flows before reading the contract

 Draw the actual path for each data type. Include the glasses, paired phone, local network, app, account, vendor cloud, model provider, analytics, support access, exports and backups.

 For each step, record:

| Question | Evidence needed |
| --- | --- |
| What is received? | Sensor and permission documentation, test results and network or architecture evidence |
| Why is it processed? | Approved purpose, vendor terms and product documentation |
| Who decides? | Role analysis against factual control of purposes and essential means |
| Where is it processed? | Hosting, support, subprocessor and transfer documentation |
| How long is it kept? | Retention settings, backup position and deletion evidence |
| Is it reused? | Model-training, product-improvement, safety, telemetry and feedback terms |
| Can the organisation act on rights? | Search, export, correction, objection, restriction and deletion procedures |

 A vendor may be a processor for hosted functionality and a separate controller for accounts, telemetry or product improvement. A third-party model provider may sit behind the visible supplier. The assessment must not force the whole relationship into one label for convenience.

 Our [AI Act role-mapping guide](https://xpertdpo.com/ai-act-role-mapping-provider-deployer-importer-and-distributor/) and [cloud AI due-diligence guidance](https://xpertdpo.com/cloud-ai-due-diligence-privacy-security-governance/) provide fuller routes for these two analyses.

### Smart-glasses supplier evidence checklist

 Procurement should obtain and preserve evidence, not only questionnaire answers.

 Request:

- the exact hardware, firmware, operating-system and app versions;
- a capability and sensor list, including which functions can be disabled;
- permission behaviour for the camera, microphones, location, motion sensors and third-party apps;
- architecture and data-flow documentation;
- privacy notices, product terms, AI terms, data-processing agreement and security schedule;
- the complete subprocessor and third-party model-provider position;
- hosting, remote-support and international-transfer details;
- data-retention, backup, deletion and account-closure procedures;
- terms for prompts, captures, outputs, feedback, telemetry, model training and product improvement;
- enterprise account, configuration, logging, access-control and offboarding capability;
- encryption, secure pairing, device-lock, remote-wipe and lost-device controls;
- vulnerability management, update policy, support period and end-of-life process;
- incident notification and assistance arrangements;
- app-store governance, developer review and permission revocation;
- accessibility information, prescription-lens options and compatibility limits;
- physical safety, environmental and PPE evidence for the intended setting;
- audit or assurance reports covering the actual smart-glasses service; and
- change-notification commitments for hardware, models, apps, terms, subprocessors and processing locations.

 Compare the evidence with product behaviour during the pilot. A statement that sensor data is collected only when a feature is activated is useful only if the organisation knows which voice commands, gestures, apps and background processes count as activation.

### Set a minimum technical-control baseline

 The approved configuration should be recorded before the device reaches the user.

 At minimum, consider:

- enterprise-managed accounts rather than unmanaged personal accounts;
- multi-factor authentication and controlled pairing;
- the ability to disable or physically block camera and microphone functions;
- allow-listed apps and permissions;
- local processing where it materially reduces risk;
- no model training or product improvement using organisational content;
- minimum capture quality and field of view necessary for the purpose;
- session-based activation with a visible and understandable indicator;
- no background recording, streaming or persistent memory unless separately approved;
- short, enforced retention with deletion verification;
- encryption in transit and at rest;
- restricted exports, sharing and social-media connections;
- device inventory, ownership and named user assignment;
- remote lock, wipe and access revocation;
- firmware and security-update monitoring;
- logs sufficient to investigate activation, access, export and deletion;
- tested offline and connectivity-failure behaviour; and
- a controlled method for applying litigation holds without turning all routine capture into permanent storage.

 Where the product cannot support the controls required by the use case, the answer is not to place them in a policy that the device cannot enforce. The organisation should change the product, configuration or purpose.

> **Procurement rule:** Do not approve a policy control that the organisation cannot configure, test or evidence on the selected device.

### Define permitted, restricted and prohibited environments

 A zone model should be simple enough for workers, visitors and managers to apply.

| Zone | Examples | Default position |
| --- | --- | --- |
| Permitted | Approved training area; non-sensitive field site; accessibility use with capture disabled | Use the approved function and configuration |
| Controlled | Customer floor; warehouse; remote-support task; care or clinical administration area | Named session, local conditions, visible activation and retention limit |
| Restricted | Board meeting; legal discussion; HR investigation; research lab; source-code area; production line with trade secrets | Device removed, capture physically disabled or specific senior approval |
| Prohibited | Toilets, changing rooms, intimate care, covert recording, unlawful biometric or emotion-inference use | No use and no local exception |

 The table must be adapted for sector and jurisdiction. A care provider should distinguish administrative work, ordinary communal space, private bedrooms, clinical activity and intimate care. A retailer should distinguish stock rooms, customer areas, payment points, staff rooms and incident response. A manufacturer should map prototypes, production methods, quality records and third-party confidential material.

 Visitors and contractors also need a route. Signage alone may be insufficient where the organisation knows that sensor-enabled devices present a trade-secret, safety or recording risk. Reception, contractual terms, lockers, escorts or physical lens covers may be appropriate depending on the environment.

### Build accessibility into the approval route

 The policy should not force a worker to choose between disclosing unnecessary medical information and surrendering a useful assistive tool.

 The accommodation route should record the functional need, not an excessive medical history. It should consider whether display-only operation, local captions, limited microphones, disabled recording, approved apps or particular zones can deliver the benefit. HR, accessibility specialists, the worker and the relevant technical teams should be involved without treating the DPO as the decision-maker on the accommodation itself.

 The result may be a personal configuration that differs from the general rule. It should still define allowed functions, environments, data handling and review. A reasonable accommodation is not an exemption from security or confidentiality, but a blanket ban is not a substitute for considering proportionate alternatives.

### Run a bounded pilot

 The word `pilot` does not suspend legal obligations. It should reduce exposure and generate evidence.

 Set:

- a named owner and limited user group;
- a defined function, site and duration;
- approved device and software versions;
- training and consultation completed before use;
- technical settings and restricted zones;
- the information given to workers and bystanders;
- measurable benefit, privacy and safety criteria;
- complaint, incident and stop routes;
- review of false activations, unexpected capture and workarounds;
- no-go criteria requiring immediate suspension; and
- a formal decision to stop, change or approve at the end.

 Do not let a pilot become business as usual because the devices remain in a cupboard or users have become accustomed to them.

### Prepare rights, incidents and evidence handling

 The operating procedure should answer what happens when:

- a colleague or customer asks whether they were recorded;
- a data subject makes an access, objection, restriction or deletion request;
- a device is lost, paired to the wrong phone or accessed through a compromised account;
- a recording or transcript is shared outside the approved route;
- confidential, privileged or trade-secret information is captured;
- the vendor introduces a new model, permission or retention setting;
- a worker reports distraction, fatigue, unfair monitoring or accessibility failure;
- an investigation or litigation hold requires preservation; or
- the organisation needs to suspend the entire deployment quickly.

 The logs and retained records should be sufficient to reconstruct what happened without creating continuous surveillance for the sake of auditability. The organisation should identify the system of record, retention period, redaction process and decision owner before an incident occurs.

 The breach procedure must also support the GDPR decision clock. Article 33 requires notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours after the controller becomes aware of a personal data breach, unless the breach is unlikely to result in a risk to people’s rights and freedoms. Article 34 requires communication to affected people without undue delay where the breach is likely to result in a high risk, subject to its exceptions. Supplier escalation and evidence access must be fast enough for the organisation to make and document those decisions.

### Minimum acceptable-use policy structure

 The policy should contain:

1. Scope and definitions based on capabilities, not brands.
2. Approved organisational purposes and devices.
3. Personal-device and BYOD rules.
4. Permitted, controlled, restricted and prohibited environments.
5. Activation, notification and bystander requirements.
6. Prohibited recording, biometric, emotion-inference and performance-monitoring uses.
7. Accessibility and reasonable-accommodation route.
8. Confidentiality, privilege, IP and trade-secret rules.
9. Account, app, export, sharing and social-media restrictions.
10. Retention, deletion, rights and records requirements.
11. Safety and PPE requirements.
12. Incident and complaint reporting.
13. Training, monitoring and proportionate enforcement.
14. Review triggers and ownership.

 Avoid wording that simply prohibits "recording devices" while managers routinely approve phones, meeting assistants or body-worn cameras through other routes. The smart-glasses rule should align with the organisation’s wider recording, AI, BYOD, workplace-monitoring and information-security policies.

### Final approval questions

 Before approving deployment, the accountable owner should be able to answer:

1. What exact function are we authorising, and what are we not authorising?
2. Which people can be captured or affected, including those who cannot realistically avoid the device?
3. Why is this function necessary, and what less intrusive options were tested?
4. Where do raw data, inferences, logs and outputs travel?
5. Who holds each GDPR, AI Act, product and operational role?
6. Which prohibited-practice, high-risk, DPIA and local-law checks were completed?
7. What settings, zones and organisational rules make the approved use real?
8. How are accessibility, consultation and physical safety addressed?
9. Can the organisation respond to rights, incidents, investigations and legal holds?
10. What vendor, software, purpose or environment change requires reassessment?
11. Who can pause or stop the deployment?
12. What evidence will show that the expected benefit was actually achieved?

 If those answers depend on the phrase "the vendor handles that", the approval is not ready.

### The XpertDPO view

 The practical objective is not the longest possible smart-glasses policy. It is a bounded decision that staff, technical teams and senior leaders can understand and enforce.

 Good governance permits useful functions, including accessibility support, while stopping uncontrolled capture, unlawful inference, weak supplier models and unsafe deployment. The use-case record, DPIA, supplier evidence, configuration and workplace rules should describe the same system. If they describe different systems, the organisation does not yet know what it has approved.

 Our [AI Governance and DPIA Lifecycle Support](https://xpertdpo.com/ai-governance-dpia-lifecycle-support/) can help organisations assess the use case, evidence and lifecycle together. [DPO Support](https://xpertdpo.com/dpo-support/) provides senior challenge for in-house teams working through a difficult deployment or accommodation decision.

### Sources and further reading

- [European Commission, AI Act regulatory framework and application timeline](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
- [Regulation (EU) 2024/1689, Artificial Intelligence Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)
- [Regulation (EU) 2026/1744, Digital Omnibus on AI](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32026R1744)
- [Regulation (EU) 2016/679, General Data Protection Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng)
- [EDPB, Guidelines 07/2020 on controller and processor concepts](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en)
- [EDPB, endorsed WP29 guidelines, including WP248 rev.01 on DPIAs](https://www.edpb.europa.eu/endorsed-wp29-guidelines_en)
- [EDPB, DPIA guidance for organisations](https://www.edpb.europa.eu/sme/be-compliant/be-compliant_en)
- [Irish DPC, processing operations requiring a DPIA](https://www.edpb.europa.eu/sites/default/files/decisions/ie_dpc_data-protection-impact-assessment.pdf)
- [Irish DPC, Employer Vehicle Tracking](https://dataprotection.ie/en/dpc-guidance/employer-vehicle-tracking)
- [ICO, Data protection and monitoring workers](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/monitoring-workers/data-protection-and-monitoring-workers/)
- [European Commission, European Accessibility Act](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en)
- [European Commission, Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)
- [EU-OSHA, Assisted-reality devices for remote OSH assessment](https://healthy-workplaces.osha.europa.eu/sites/hwc/files/hwc/publication/Assisted-reality-device-remote-OSH-assessments-audit_case-study_EN.pdf)
- [European Commission, Trade secrets](https://single-market-economy.ec.europa.eu/industry/strategy/intellectual-property/trade-secrets_en)
- [XpertDPO, AI Vendor Due Diligence Questionnaires and Evidence Packs](https://xpertdpo.com/ai-vendor-due-diligence-questionnaires-and-evidence-packs/)
- [XpertDPO, AI Governance Registers and Technical Documentation](https://xpertdpo.com/ai-governance-registers-and-technical-documentation/)

## General Information Only

This article is provided for general information and does not constitute legal, regulatory, or professional advice. Data protection obligations depend on the specific facts, context, and jurisdiction involved. You should not rely on this content as a substitute for advice tailored to your organisation.

If you would like support with a specific issue, please contact us: https://xpertdpo.com/contact/