AI Employee Monitoring as High-Risk AI Under the EU AI Act
Under Regulation (EU) 2024/1689, AI systems used in employment and worker management, including monitoring and evaluating people in work-related relationships and allocating tasks based on individual behaviour or traits, are treated as high-risk. An Annex III system can escape that status only if it poses no significant risk of harm, including by not materially influencing decision outcomes. It can never escape if it profiles individuals. As of November 2026, the Commission states that these employment rules apply from 2 December 2027.
A classification path for each use case
- 1
Document intended purpose
State what the system does, which workers it affects, and how its outputs are used.
- 2
Screen for prohibited capability
Counsel determines whether any function is prohibited before high-risk analysis begins.
- 3
Compare to recital 57 functions
Check for monitoring, evaluation, task allocation by individual behaviour, promotion, or termination support.
- 4
Test the Article 6 derogation
Assess risk of harm and whether outputs materially influence decisions about workers.
- 5
Check for profiling
If the system profiles individuals, the derogation is unavailable and the system is high-risk.
- 6
Record and re-review
Store the conclusion, its basis, and a review trigger for changes in purpose or in the legal text.
- Inventory every AI system that monitors, evaluates, ranks or allocates work to individual employees.
- Write down the intended purpose and function of each system before classifying it.
- Flag any system that profiles individuals, since the Article 6 derogation cannot apply to it.
- Pin your plan to the consolidated text dated 27 July 2026 and the 2 December 2027 application date stated by the Commission as of November 2026.
- Separate duties that runtime policy and evidence can support from those needing organizational owners.
- Test whether you can produce, for a single interaction, what was permitted, what occurred, and who approved or blocked it.
Which obligations runtime controls can support
Human oversight in an individual workflow
Runtime: an escalation step can require human approval before an action proceeds and record the outcome. Organizational: assigning competent people with authority to intervene.
Evidence of what a system was permitted to do and did
Runtime: each interaction and tool call produces a record of the policy decision. Organizational: defining retention needs and who reviews the evidence.
Handling of input data
Runtime: sensitive fields can be redacted or blocked before reaching a model. Organizational: deciding which data is relevant to the purpose.
Risk management
Runtime: enforcement outcomes show where controls triggered. Organizational: the documented risk management system itself.
Worker information and impact assessment
Runtime: not an execution-path function. Organizational: notices to workers and assessment processes owned by the business.
Classification, conformity and provider duties
Runtime: none. Organizational: legal determination, provider documentation and conformity processes.
What the regulation treats as high-risk in the workplace
Recital 57 states that AI systems used in employment and worker management should be classified as high-risk. The functions it names include recruitment and selection, decisions affecting the terms of the work-related relationship, promotion and termination, allocating tasks on the basis of individual behaviour, personal traits or characteristics, and monitoring or evaluating persons in work-related contractual relationships. The stated reason is the appreciable impact on future career prospects, livelihoods and workers' rights.
Recital 52 adds the logic that governs classification: a stand-alone AI system is high-risk in light of its intended purpose, where it poses a high risk of harm to health, safety or fundamental rights and is used in one of the pre-defined areas in the Regulation. Classification therefore follows what a system is for and what it does to individuals, not the technology underneath.
In practice, two tools with similar analytics can land in different places. A dashboard that aggregates team throughput for capacity planning is a different proposition from a tool that scores each worker and feeds the score into task allocation or review. The first question for any use case is which of the recital 57 functions it performs, if any.
The Article 6 derogation and the profiling limit
Article 6 provides that an AI system is considered high-risk where both of its listed conditions are fulfilled. It then provides a derogation from Article 6(2): an Annex III system is not considered high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making.
Two consequences follow for compliance teams. First, the derogation turns on influence over decisions. A record of how system outputs feed into decisions about individual workers is the evidence that any "not high-risk" conclusion depends on. If a manager routinely accepts a ranking without independent review, the claim that the output does not materially influence the decision becomes difficult to defend.
Second, the derogation has a hard limit. An Annex III system is always considered high-risk where it performs profiling of natural persons. Any tool that ranks, scores or predicts individual employee behaviour needs a profiling analysis before anyone reaches a derogation conclusion. Legal classification, including whether a capability is prohibited outright, is a determination for the deployer's counsel and compliance function.
Where enforcement in the execution path fits
Runtime evidence answers one specific question: what was this system permitted to do at the moment it acted, and what did it do. That is the question a regulator or auditor asks once a use case is in scope. It does not establish classification, intended-purpose documentation, or anything on the provider side.
Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each individual interaction or tool call can be allowed, redacted, blocked, rate limited, or escalated for human approval. Enforcement generates audit-ready evidence mapped to the EU AI Act and other frameworks. Deployment is self-managed in the customer cloud, with configurable retention and data residency.
The limits matter. Trussed does not determine legal classification. It does not replace conformity assessment, provider obligations, or worker-notification processes. It does not provide model or dataset provenance, transaction-level governance, or end-to-end tracing of agentic workflows. Its scope is individual interactions and tool calls, and its evidence supports the oversight and record-keeping parts of a compliance programme without standing in for the rest.
Classification decision path for an employee-monitoring system
Label: 1. Purpose and function
Description: Document what the system does to or about individual workers.
Label: 2. Prohibited, high-risk or neither
Description: Counsel determines which of the three outcomes applies.
Label: 3. Article 6 derogation
Description: Tested only if the system is in an Annex III area.
Label: 4. Profiling check
Description: Profiling of individuals removes the derogation.
Label: 5. Controls and evidence
Description: Map deployer duties to runtime enforcement or organizational process.
Show what your AI was allowed to do and what it did
See how enforcement in the execution path produces audit-ready evidence for individual interactions and tool calls.
See How Evidence Is Produced