EU AI Act Workforce Monitoring Compliance Checklist (2026)

Who this checklist is for — and what it is not

If you run workforce-monitoring or productivity software across employees in the EU — or you are a UK employer with EU-based staff, contractors, or a single team in Dublin, Amsterdam, or Warsaw — the EU AI Act reaches you as a deployer. The deployer is the organisation using the AI system under its own authority, as distinct from the provider that builds it. Most of the operational obligations that turn into audit findings land on the deployer, not the vendor.

This is a checklist for the deployer side of the conversation. It does not score vendors — we have a separate EU AI Act vendor scorecard for that, and a 14-question vendor readiness list for the procurement call. This page is the work that stays your responsibility no matter which tool you pick: scoping the system, assessing fundamental rights, standing up human oversight, telling your workforce, gathering vendor evidence, and keeping the records that a market surveillance authority will ask for.

Treat the thirty-two items below as a running register. Assign each one an owner and a status. The single most useful artifact you can produce before 2 August 2026 is a one-page table that says, for each obligation, who owns it and where the evidence lives. This guide reflects gStride’s reading of the EU AI Act as of May 2026; verify every classification and obligation with your own counsel.

The deadline that matters and the ones that already passed

The EU AI Act phases in. Three dates frame the workforce-monitoring conversation:

Date	What applied	Relevance to workforce monitoring
2 Feb 2025	Prohibited practices (Article 5) and AI literacy duties (Article 4)	Emotion recognition in the workplace is in the prohibited band. Staff who operate or are affected by AI need a baseline level of AI literacy. Both are already live.
2 Aug 2025	Governance, notified bodies, GPAI provider obligations	Mostly upstream of deployers, but sets the enforcement machinery that will police the 2026 obligations.
2 Aug 2026	High-risk obligations for Annex III systems — including human oversight, transparency to affected persons, and deployer record-keeping	The gate for workforce monitoring. If your tool makes or materially informs decisions about workers, the deployer obligations bite here.

Two things follow. First, emotion-recognition features in monitoring tools are not a 2026 problem — they are a problem now, because the Article 5 prohibition is already in force. If your incumbent tool infers stress, mood, or sentiment from webcam or keystroke cadence, that is a live exposure, not a future one. Second, everything else on this checklist resolves to the 2 August 2026 date. Verify the applicable dates for your specific system class with counsel; the phase-in has nuances by product type.

Phase 1 — Scope the system (is it even high-risk?)

Half of compliance work is establishing what you actually have to do. Annex III of the EU AI Act lists employment and worker-management systems as high-risk: AI used for recruitment, task allocation, monitoring, or evaluation of workers. But not every tool with “productivity” in the name is in scope. The dividing line is whether the system makes or materially informs a decision about a worker, versus simply displaying activity data for a human to interpret.

SC-1Inventory every workforce AI system. List each tool that processes employee data and produces any score, ranking, flag, or classification. Include shadow deployments — the team that bought a monitoring tool on a corporate card counts.
SC-2Classify each against Annex III. For each tool, record whether it monitors or evaluates workers, and whether its output feeds a decision (appraisal, PIP, allocation, retention). Output-into-decision is the high-risk trigger.
SC-3Screen for prohibited features (Article 5). Confirm no tool performs emotion recognition in the workplace or other prohibited practices. This is already enforceable — treat any hit as a stop-ship.
SC-4Document borderline calls. Where a tool is arguably out of scope (raw time capture, no inference), write down the reasoning and have counsel sign it. A documented out-of-scope call is a defense; an undocumented one is a gap.
SC-5Map the data inputs. Record what each system ingests — keystrokes, screenshots, app/URL logs, calendar, project tickets, repository activity. Input type drives both AI Act scope and the GDPR overlap below.

Common mistake Assuming “we only track time” keeps you out of scope. Most modern monitoring suites bundle activity scoring, productivity grading, and idle classification into the same product. If any of those outputs reaches a manager who uses it to evaluate a worker, the evaluation use case pulls the deployment into Annex III — regardless of what the sales page called it.

Phase 2 — Fundamental rights and data protection assessment

Article 27 requires certain deployers of high-risk systems to complete a fundamental rights impact assessment (FRIA) before putting the system into use. The obligation is clearest for public bodies and providers of public services, but the prudent default for any workforce deployment is to run the assessment and let counsel decide whether it was strictly required. In parallel, almost every monitoring deployment triggers a GDPR data protection impact assessment (DPIA) under Article 35 of the GDPR, because systematic monitoring of employees is high-risk processing. The two assessments overlap heavily — run them together.

FR-1Determine FRIA applicability. Record, per system, whether Article 27 requires a FRIA for your organisation type and use case. Where unclear, run it anyway.
FR-2Describe the deployment and its purpose. Document what the system does, the categories of workers affected, the frequency and duration of use, and the specific decisions the output informs.
FR-3Assess the rights at stake. Identify impacts on privacy, dignity, non-discrimination, and the right to fair working conditions. Note any group that could be disproportionately affected (shift workers, neurodivergent staff, those with caring responsibilities).
FR-4Run the GDPR DPIA in the same workstream. Cover lawful basis (legitimate interest is the usual route for employee monitoring, not consent — consent is rarely freely given in an employment relationship), necessity, proportionality, and the least-intrusive-means test.
FR-5Define mitigations and residual risk. For each identified risk, record the mitigation (data minimisation, aggregation, opt-outs, oversight) and the residual risk the business accepts.
FR-6Set a review cadence. Schedule reassessment on material change — new features, new data sources, a new worker population — and at least annually.

Proportionality is the whole game. The recurring question both the FRIA and the DPIA ask is whether the same legitimate purpose — capacity planning, fair workload, project profitability — could be met with less intrusive means. A deployment built on outcome signals (calendar, project, repository data) answers that question far more comfortably than one built on keystroke and screenshot capture. The choice of tool is, in effect, a choice about how hard your proportionality argument will be.

Phase 3 — Stand up human oversight (Article 14)

Article 14 is the obligation that catches deployers off guard, because it is not a document — it is a working process. High-risk AI must be designed and used so that a competent human can understand it, monitor it, interpret its output, decide not to use that output, and intervene or stop the system. For workforce monitoring this means an AI productivity score or flag cannot flow straight into an appraisal. A named person must be able to look at it, override it, and have that override recorded. We cover the mechanics in depth in the Article 14 human oversight workflow template; the checklist version is below.

HO-1Name the human reviewers. Assign, by role, who oversees each high-risk output. The reviewer must have the authority and the time to override — a reviewer who rubber-stamps fails the test.
HO-2Give reviewers the system’s limits in writing. Document known failure modes, accuracy caveats, and the situations where the output is least reliable. Reviewers cannot interpret what they do not understand.
HO-3Build the override path. Confirm a reviewer can reject or correct an AI output before it affects a worker, and that doing so is a normal, low-friction action — not a support ticket.
HO-4Log every override. Capture who overrode what, when, and why. The override log is the primary evidence that oversight is real rather than nominal.
HO-5Set the “do not use” conditions. Define when an output should be ignored entirely — e.g. insufficient data window, known anomaly, worker on leave — and make those conditions visible to reviewers.
HO-6Train the reviewers (and record it). Article 4 AI-literacy duties already apply. Document that reviewers have been trained on the system, automation bias, and their override authority.

Common mistake Treating “a manager sees the dashboard” as oversight. Visibility is not oversight. Article 14 asks whether the human can effectively intervene and whether automation bias is actively countered. A score that the manager glances at and pastes into the review form, with no override mechanism and no log, is exactly the pattern the article is written to prevent.

Phase 4 — Worker transparency and consultation (Article 26)

Article 26(7) requires deployers who put a high-risk system into use in the workplace to inform affected workers and their representatives that they will be subject to it, before it goes live. This sits on top of GDPR transparency duties and any national works-council, co-determination, or collective-agreement obligations — which in Germany, the Netherlands, France, and elsewhere can be more demanding than the AI Act itself.

TR-1Draft the worker notice. Explain in plain language what the system does, what data it uses, how outputs are used in decisions, and how a worker can contest an output. Avoid the vendor’s marketing framing.
TR-2Notify before go-live. The information duty is pre-deployment. Record the date the notice was issued and to whom.
TR-3Engage worker representatives and works councils. Where a works council or union exists, consult per the applicable national law — this is often a condition of lawful deployment, not a courtesy.
TR-4Align the GDPR Article 13/14 notices. Make sure the employee privacy notice reflects the monitoring, lawful basis, retention, and rights. Inconsistency between the AI Act notice and the privacy notice is an easy finding for a regulator.
TR-5Provide a contest and human-review route. Tell workers how to challenge an AI output and who reviews the challenge. This connects to the Article 14 override path and to GDPR rights around automated decisions.
TR-6Keep a transparency evidence pack. Retain the notice text, distribution records, and consultation minutes. Transparency you cannot evidence is transparency a regulator will treat as absent.

Phase 5 — Gather the vendor evidence

The deployer does not build the high-risk system; the provider does. But the deployer must use it in line with the provider’s instructions for use, ensure input data is relevant and representative for the intended purpose, and rely on the provider’s documentation for its own records. A provider that ships a complete deployer pack — instructions for use, human-oversight design, logging capabilities, and transparency materials — collapses a large part of this checklist into a procurement decision. A provider that ships a binary and a privacy policy leaves the deployer to reconstruct all of it.

VE-1Obtain the instructions for use. The provider must supply instructions covering the system’s intended purpose, performance, and human-oversight measures. File them with your records.
VE-2Confirm the provider’s conformity status. Ask for the declaration of conformity and CE marking position for the high-risk system, and the provider’s timeline to it.
VE-3Verify logging capability. Confirm the system automatically logs events over its lifetime to the extent within your control, and that you can retain those logs.
VE-4Check the data-input fit. Confirm the input data you feed the system is relevant and sufficiently representative for your intended purpose — the deployer owns this obligation.
VE-5Get the human-oversight design. Confirm the provider has built oversight measures the deployer can actually operate — an override path, not just a read-only dashboard (ties to HO-3).
VE-6Confirm the surveillance defaults. Record whether monitoring features are on or off by default, whether keystrokes and screenshots are captured, and whether prohibited inferences are architecturally excluded rather than toggled off.

The highest-leverage line on the whole checklist. The difference between a vendor that ships oversight, logging, and transparency-ready documentation and one that does not is the difference between a procurement decision and a six-month build. If you are early in the cycle, weight EU AI Act readiness heavily in the selection — it is cheaper to buy compliance-by-design than to bolt oversight onto a keystroke logger.

Phase 6 — Records, monitoring, and incidents

The final phase is the one auditors actually inspect: can you produce, on request, the documentation that shows the rest of this checklist was done? Deployers must keep the logs the system generates, monitor the system in operation, and report serious incidents and malfunctions to the provider and the relevant authority.

RC-1Retain system logs. Keep the automatically generated logs for the period required for your purpose and at minimum the statutory period, with access controls.
RC-2Maintain the compliance register. Hold the FRIA, DPIA, worker notices, oversight design, override logs, vendor instructions, and conformity evidence in one indexed location.
RC-3Monitor operation against the instructions. Track that the system is used within its intended purpose and the provider’s instructions, and that performance has not drifted.
RC-4Define the serious-incident process. Document how you report serious incidents and malfunctions to the provider and the market surveillance authority, with timelines.
RC-5Assign the accountable owner. Name the person accountable for ongoing AI Act compliance for each system — not a committee, a person.

Done well, this phase produces a single binder — physical or digital — that answers every question a market surveillance authority can ask, in the order they will ask it. The teams that struggle in an inquiry are rarely the ones that did the work; they are the ones who did the work and cannot find the evidence.

What is at stake if you skip it

The EU AI Act’s administrative fines are tiered. Breaches of the prohibited-practice rules carry the highest band — up to 35 million euro or 7 percent of total worldwide annual turnover, whichever is higher. Breaches of most other obligations, including the high-risk deployer duties on this checklist, carry up to 15 million euro or 3 percent of turnover, whichever is higher. National authorities apply these with proportionality, and the turnover-linked ceilings mean the largest employers carry the largest exposure. These are statutory ceilings, not expected fines — verify your exposure with counsel.

The faster-moving exposure, as with the DPDP Act in India, is rarely the headline fine. It is the works-council dispute that stalls a deployment, the GDPR complaint that lands in parallel, and the enterprise customer whose own compliance audit now includes a column for whether their vendors’ vendors are AI Act ready. For an employer of EU staff, “our monitoring tool is not AI Act compliant” is the kind of finding that travels.

How gStride shortens this checklist

gStride is an AI productivity intelligence platform built so the deployer-side checklist is mostly answered by the architecture rather than by your team’s overtime. The design choices map directly onto the phases above.

Phase 1 · Scoping

Outcome signals, not input capture

gStride reads work outcomes from calendar, project, and repository tools rather than keystrokes or screenshots. That keeps the data-input footprint (SC-5) narrow and makes the proportionality argument in your FRIA and DPIA materially easier to write.

Phase 2 · FRIA / DPIA

No prohibited inference to assess

Emotion recognition, stress scoring, and wellbeing prediction are excluded by architecture, not by an admin toggle. The product cannot perform them regardless of configuration — which removes the most dangerous line item from your Article 5 screen and your assessment.

Phase 3 · Human oversight

Override path and audit log built in

Every AI-generated score or flag is reviewable and overridable by a named human, and every override is logged with actor, timestamp, and reason — the HO-3 and HO-4 evidence ships with the product, not as a process you assemble afterwards.

Phase 4-6 · Transparency, vendor, records

A deployer documentation pack

Instructions for use, a human-oversight design summary, transparency-ready worker-notice templates, and exportable system logs are provided as a deployer pack — covering VE-1, VE-3, VE-5, TR-1, and RC-1 from a single source.

Verify, do not take our word. The architectural claims above should be checked against the gStride documentation and your own counsel before they go into a regulatory submission. The point of compliance-by-design is that the verification is straightforward — ask to see the override log, the exclusion architecture, and the deployer pack, and confirm they exist before you sign.

Get the full 32-point checklist as a working register

Book a founder-led walkthrough and we will map this checklist to your current monitoring stack — which obligations your incumbent tool already covers, which it forces you to build, and where the proportionality gaps sit. For EU and UK HR, IT, and DPO teams preparing for 2 August 2026.

Book the 30-min EU AI Act walkthrough Or read the 7-vendor EU AI Act scorecard

Frequently asked questions

Is workforce monitoring software high-risk under the EU AI Act?

AI systems intended to be used for the recruitment, selection, task allocation, monitoring, or evaluation of workers are classified as high-risk under Annex III of the EU AI Act. Whether a specific monitoring product falls in scope depends on whether it makes or materially informs decisions about workers, rather than simply displaying raw activity data. Pure time capture without inference may sit outside Annex III, while AI that scores, ranks, or evaluates workers is typically in scope. Verify the classification of your specific deployment with counsel.

What is the EU AI Act deadline for workforce monitoring?

The high-risk obligations relevant to Annex III workforce systems — including human oversight, transparency to affected persons, and deployer record-keeping — apply from 2 August 2026. Prohibited-practice rules (Article 5) and AI literacy duties applied earlier, from 2 February 2025. Deployers should treat 2 August 2026 as the gate for having human oversight, transparency, and fundamental rights documentation operational. Verify the applicable dates for your system class with counsel.

Do employers need a fundamental rights impact assessment for workforce AI?

Deployers that are bodies governed by public law, or private entities providing public services, and deployers of certain high-risk systems, must complete a fundamental rights impact assessment (FRIA) before putting a high-risk AI system into use, under Article 27. Many private employers will additionally need a data protection impact assessment under the GDPR. The two assessments overlap but are not identical. Most workforce-monitoring deployments should plan for both. Verify your specific obligation with counsel.

What human oversight is required for employee monitoring AI?

Article 14 requires that high-risk AI systems be designed so that natural persons can effectively oversee them — understanding the system's capabilities and limits, monitoring for anomalies, correctly interpreting outputs, deciding not to use the output, and intervening or stopping the system. For workforce monitoring this means a named reviewer must be able to override an AI productivity score or flag, with that override logged. A score that auto-feeds an appraisal with no human in the loop fails Article 14. Verify your oversight design with counsel.

Do employees have to be told they are monitored by AI under the EU AI Act?

Yes. Under Article 26, deployers using a high-risk AI system in the workplace must inform workers and their representatives that they will be subject to its use before it is put into operation. This is in addition to GDPR transparency duties and any national works-council or co-determination requirements. The notice should explain what the system does, what data it uses, how outputs are used in decisions, and how a worker can contest an output. Verify the transparency package with counsel and works council.

What are the penalties for EU AI Act non-compliance?

The EU AI Act sets administrative fines up to 35 million euro or 7 percent of total worldwide annual turnover for prohibited-practice breaches, and up to 15 million euro or 3 percent of turnover for breaches of most other obligations, whichever is higher. National authorities apply the figures with proportionality. The turnover-linked ceiling means large employers carry the greatest exposure. These are statutory ceilings, not expected fines. Verify your exposure with counsel.

Can choosing the right vendor reduce EU AI Act compliance work?

Yes, substantially. A vendor that ships human-oversight controls, an override audit log, transparency-ready documentation, and a deployer instructions-for-use pack does much of the technical and documentary work the deployer would otherwise build alone. A vendor that captures keystrokes and screenshots by default and produces AI scores with no override path forces the deployer to bolt oversight on top, which is harder to evidence. Vendor selection is the single highest-leverage line on this checklist.

Disclaimer. This checklist reflects gStride AI's current interpretation of the EU AI Act (Regulation (EU) 2024/1689) and its phased application as of May 2026. Implementing acts, harmonised standards, and national transposition measures may change the operational obligations described here. Article and date references are provided for orientation, not as legal advice. Penalty figures cited are statutory ceilings, not expected enforcement values. Verify with your own counsel and, where relevant, your works council before relying on any item in a regulatory submission, vendor RFP, or board document. Questions about this guide: press@gstride.ai.