When an employee monitoring tool is deployed: what to do first
The first step is classification, not configuration. Establish whether the tool evaluates or monitors workers' performance or behaviour through automated means. If it does, treat it as a high-risk AI system before rollout, gather the vendor's conformity documentation, and confirm which internal function owns the decision to deploy.
Legal basis
Three EU instruments frame the decision, each for a different reason. Regulation (EU) 2024/1689 (AI Act) sets rules for AI systems that monitor or evaluate workers, and its high-risk obligations for that category apply from 2 August 2026 (position as of the verification date below). Directive (EU) 2022/2555 (NIS2) requires in-scope entities to secure the network and information systems that carry monitoring data, including logging and access controls. Directive 96/9/EC addresses who holds rights in the database that the tool compiles once monitoring records accumulate.
None of the three instruments regulates the employment relationship itself. That question sits under national employment and data protection rules, which are not covered on this page.
What changes once the tool is live
For most organisations, the practical consequence is a compressed timeline. Once the tool is live, workers are already being monitored, and any gap in documentation, security controls, or data ownership becomes harder to correct without disrupting a system already in use. The classification decision should be made and recorded before switch-on, not retrofitted afterwards.
A tool procured as a simple productivity dashboard can turn into a high-risk AI system the moment it starts scoring behaviour rather than counting hours. That shift is often gradual, driven by a vendor update rather than a new procurement decision, which is why the classification check needs a scheduled repeat rather than a one-off sign-off.
What to do first
- Confirm whether the tool performs automated evaluation or monitoring of worker behaviour or performance, and record the answer with a date.
- If the answer is yes, request the vendor's technical documentation and conformity evidence for the high-risk category before deployment continues.
- Map the tool's connection to your network and information systems, and check whether your organisation falls within the scope of cybersecurity risk-management duties.
- Review the vendor contract for rights over the compiled monitoring database, including extraction, re-use, and portability terms.
- Assign an internal owner for the file and set a fixed date to repeat the classification check.
Vendor dependency is worth checking early, since support does not always continue at the level assumed at purchase. A related pattern applies when the licensor stops maintaining the right and its consequences fall on the organisation still relying on the software.
Who decides
| Question | Decision-maker | Basis |
|---|---|---|
| Is the tool a high-risk AI system? | The function deploying the tool | Regulation (EU) 2024/1689 (AI Act) |
| Are cybersecurity duties triggered? | The function responsible for network and information systems | Directive (EU) 2022/2555 (NIS2) |
| Who owns the compiled monitoring database? | The function reviewing the vendor contract | Directive 96/9/EC |
None of these three decisions belongs to the same person by default. Splitting them keeps the classification check independent of the person who approved the purchase.
If your situation differs
If the tool only records login times or device activity without scoring behaviour, it will typically sit outside the high-risk category, though the logging system itself may still need securing under NIS2.
If the underlying technology is patent-protected and that protection is later contested, a related question is when prior art surfaces after grant and the deadline for opposition, since instability in the underlying right can affect long-term vendor support.
If deployment starts as a limited pilot before wider rollout, the shift resembles when a proof of concept becomes production in detail, because obligations that applied lightly during the pilot tend to tighten once the tool runs across the whole organisation.
If the approval sits with a committee that also reviews the vendor relationship, the internal process can raise the same kind of question seen when the issuer is asked about conflicts step by step, since approval and review should not rest with the same person.
What this page does not cover
This page does not certify a specific monitoring tool as high-risk or compliant; that determination depends on the tool's actual function and the vendor's own documentation. It does not cover employee consultation procedures, which are set at national level and are not addressed here. It does not set out article-by-article obligations under any of the three instruments named above.
Related reading
A related classification question arises before procurement rather than after deployment: When a vendor questionnaire asks about certification in practice covers the earlier stage of the same file.
Verified
Position as of 18 March 2025. Sources: Regulation (EU) 2024/1689 (AI Act); Directive (EU) 2022/2555 (NIS2); Directive 96/9/EC.
FAQ
What is the first step when an employee monitoring tool is deployed?
Establish whether the tool performs automated monitoring or evaluation of worker behaviour or performance. That answer determines whether the high-risk regime under Regulation (EU) 2024/1689 (AI Act) applies before the tool goes live.
Which deadline is already running?
The AI Act's high-risk obligations for employment-related monitoring systems apply from 2 August 2026 (position as of 18 March 2025). Organisations preparing a qualifying tool should treat documentation and oversight steps as running now.
Who decides, and on what evidence?
The function deploying the tool decides on classification, based on the vendor's technical documentation. The function responsible for network and information systems decides on security measures, based on the scope test under Directive (EU) 2022/2555 (NIS2).