EU AI Act Article 6: Is the Workforce-AI System High-Risk? A Decision Tree (2026)

Why Article 6 is the procurement gate of 2026

The EU AI Act is the world's first horizontal AI regulation. It came into force on 1 August 2024 with staged application. The flagship moment for workforce AI is 2 August 2026 — the date the high-risk obligations of Chapter III Section 2 begin applying to Annex III systems. Workforce systems sit squarely in Annex III point 4. From that date, an employer using a workforce-AI vendor whose system is classified high-risk inherits Article 26 deployer obligations and, for many deployers, Article 27 fundamental rights impact assessment. The vendor as provider inherits Articles 9 through 15.

The single most consequential question in a 2026 workforce-AI procurement is therefore: is this system high-risk under Article 6? If yes, the entire compliance stack lights up. If no, the system sits in the Article 50 transparency band — a much lighter regime. Vendors with skin in the game have an incentive to argue “no”; deployers with skin in the game have an incentive to test the answer carefully and document it. Verify with counsel.

The decision is not a one-line check. Article 6 has two limbs — Article 6(1) covers safety components of products under existing EU harmonisation legislation listed in Annex I, and Article 6(2) sweeps in stand-alone systems listed in Annex III. For workforce AI, Article 6(2) plus Annex III point 4 is the operative path. Then Article 6(3) introduced narrow exemptions where the system performs a procedural task or improves the result of human activity. Whether those exemptions apply is the actual decision tree.

Annex III point 4 — the workforce categories

Annex III point 4 is titled “Employment, workers management and access to self-employment.” The point lists categories of AI systems that are classified high-risk under Article 6(2). The substantive language (as published in Regulation (EU) 2024/1689) covers AI systems intended to be used:

• 4(a) — For the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates.
• 4(b) — To make decisions affecting terms of work-related relationships, the promotion or termination of work-related contractual relationships, to allocate tasks based on individual behaviour or personal traits or characteristics, or to monitor and evaluate the performance and behaviour of persons in such relationships.

The phrase to underline is “monitor and evaluate the performance and behaviour of persons in such relationships.” That language is the regulatory anchor that sweeps in most workforce productivity, monitoring, and evaluation AI. The Recitals (Recital 57 in particular) make plain that the legislator was concerned about employer power asymmetry and the fundamental rights at stake (privacy, non-discrimination, dignity at work). The high-risk classification is the regulatory response.

The Article 6 decision tree for a workforce-AI system

The decision tree below walks the Article 6 analysis in five steps. At each step the answer is yes, no, or assessment-required. The vendor and deployer should each be able to point to the documented answer with citations to the AI system's technical documentation. Verify with counsel.

Article 6(3) exemptions — why they rarely save workforce AI

Article 6(3) was the late addition that worried civil society and gave vendors a possible escape. The exemptions are narrowly drafted and the burden is on the provider to document the exemption assessment in technical documentation under Article 11 before relying on it. The four exemptions:

(a) Narrow procedural task

The system performs a narrow procedural task — for example, converting unstructured data into structured data, classifying incoming documents into categories, detecting duplicates. A productivity score, behaviour evaluation, or performance signal is not a narrow procedural task. The exemption is unlikely to apply to evaluative workforce AI.

(b) Improves the result of a previously completed human activity

The system improves the result of a previously completed human activity — for example, polishing language, formatting suggestions. A scoring system that runs in parallel with manager judgement and the manager subsequently relies on does not improve a previously completed activity; it influences a future activity. Exemption unlikely.

(c) Detects decision-making patterns without replacing or influencing human assessment

The system detects decision-making patterns or deviations from prior patterns — for example, surfacing anomalies for review. The condition is that the system does not replace or influence the human assessment. A workforce-AI vendor whose product is sold to managers as an evaluation input by definition influences the manager's assessment. Exemption unlikely.

(d) Preparatory task to an assessment

The system performs a preparatory task in an assessment — for example, summarising documents. If the system summarises an employee's signals into a digest for review, the summary is the assessment in operational terms. Exemption unlikely.

Beyond the narrow drafting, Article 6(3) has the explicit override: if the AI system performs profiling within the meaning of Article 4(4) GDPR (any automated processing of personal data to evaluate certain personal aspects relating to a natural person), the exemption does not apply and the system stays high-risk. Most workforce-AI involves profiling. The override is the practical end of the exemption argument for workforce productivity and monitoring tools.

What high-risk triggers — the obligation cascade

Once high-risk attaches under Article 6, the obligation set lights up. The provider (vendor) carries the bulk of the design-time obligations; the deployer (employer) carries the use-time obligations. Both should expect Article 99 penalty exposure.

The Article 14 human-oversight requirement is the operational anchor that decides whether the deployment can withstand audit. We covered the deployer workflow in EU AI Act Article 14 Human Oversight Workflow Template; the obligation, in short, is that the deployer must be able to intervene, override, and disregard the system's output in real workflow, and the design of the system must make this operationally feasible.

The Article 27 fundamental rights impact assessment is the documentary anchor that gives the deployer's audit defense its substance. Public bodies and certain categories of private deployers (notably credit and insurance deployers) must complete the FRIA before deployment; the FRIA is a written assessment of the categories of natural persons affected, the categories of harms that may occur, specific risks identified, governance measures, oversight measures, complaint mechanism. Many private workforce-AI deployers will not be required to complete a FRIA under Article 27 strictly but most legal advisers recommend conducting an equivalent assessment as defensive documentation. Verify with counsel.

The penalty band

Article 99 sets the EU AI Act penalty structure. The bands are tiered by severity of violation.

For SMEs (defined per Commission Recommendation 2003/361/EC), the penalty ceiling is the lower of the absolute amount or the percentage. For mid-cap and large enterprises, the percentage often dominates. The 3-percent worldwide-turnover tier is the operational anchor for workforce-AI penalty exposure; a 1 billion euro turnover company faces up to 30 million euro per violation. Penalty interpretation will vary by Member State competent authority; the values above are statutory ceilings, not expected enforcement values. Verify with counsel.

Two other Article 99 features matter for procurement risk. First, Member State competent authorities have wide discretion on whether to impose, and may impose lower amounts in light of mitigating factors including cooperation and self-disclosure. Second, the same conduct may trigger separate liability under GDPR for the data-protection dimension; the AI Act penalty does not displace GDPR penalty.

The vendor-scoring lens — how procurement uses Article 6 classification

The Article 6 classification is not the end of procurement; it is the gate that decides which procurement track to run. Two tracks.

Track A — The vendor classifies the system NOT high-risk

The vendor will produce an Article 6(3) assessment (or an argument that the system is not Annex III). The procurement file must capture the assessment in writing as a contract schedule. The deployer's counsel must independently validate the classification — or document disagreement. Article 6(3) classification by the vendor does not bind the deployer; the deployer can take a different view and document its own assessment.

In practice, only a narrow band of workforce-adjacent tooling (a job-description grammar checker, a meeting-transcript formatter, a calendar reminder bot) plausibly survives Article 6(3) scrutiny. Anything that scores, ranks, evaluates, or monitors employees should be assumed high-risk for procurement purposes even if the vendor claims otherwise.

Track B — The system is high-risk

Track B is the default and the documentation pack the procurement file demands is substantial. Eight written disclosures form the minimum vendor evidence pack:

1. Article 6(3) assessment (if the vendor claims any exemption, the documented analysis).
2. Annex III point 4 sub-category positioning — which of 4(a) and 4(b) sub-clauses the system falls under and why.
3. Article 9 risk-management system documentation — the risk management plan, identified risks, mitigation measures, residual-risk acceptance.
4. Article 10 data and data governance documentation — dataset provenance, governance, examination for bias, representativeness.
5. Article 11 technical documentation — the full TDC including system description, monitoring, performance metrics, foreseeable misuse.
6. Article 13 instructions for use — what the deployer is told to do and not do, human-oversight measures.
7. Article 14 human-oversight workflow design — how the system supports intervention, override, disregarding.
8. Conformity assessment route — internal (Annex VI) or notified body (Annex VII), and the EU declaration of conformity per Article 47.

The free EU AI Act Vendor Scorecard converts these eight disclosures plus six operational anchors into a 14-question score band: Aligned, Aligned-with-gaps, Procurement Hold, or Re-evaluate. Run any vendor through the scorecard before committing to a contract that takes effect after 2 August 2026.

To classify your own workforce-AI system rather than a vendor's, run the free EU AI Act Article 6 High-Risk Classifier — seven yes/no questions return an indicative band (Not high-risk, Likely high-risk under Annex III point 4, or Definitely high-risk + obligations) mapped to the Article 9/10/14/27 cascade. Indicative only; verify with counsel.

For India IT services exporters with EU customers

India IT services firms exporting workforce-AI or building EU-customer-facing platforms inherit the EU AI Act compliance posture of their customers. Three Article 6 considerations specific to the India IT exporter context.

Provider-or-importer position. If the India firm develops the AI system and places it on the EU market under its own name, it is the provider under Article 3(3) and carries the full provider obligation stack. If the EU customer integrates a generic India component into a larger system placed on the EU market, the EU customer may become the provider with respect to the integrated system, leaving the India firm as a downstream supplier. The contract should clarify the boundary.

Authorised representative obligations. Article 22 requires non-EU providers of high-risk AI systems to designate an authorised representative established in the Union. The representative carries documentation, cooperation, and incident-reporting duties on behalf of the non-EU provider. India providers serving EU customers must factor in the authorised representative cost as a structural compliance overhead, not an optional add-on.

India DPDP parallel. Many India IT exporters are simultaneously building DPDP-compliant workforce systems for India deployments. The architectural decisions (consent ledger, purpose-limited capture, human oversight) translate across both regimes, but the regulatory language differs. A vendor whose EU AI Act Article 14 workflow doubles as the DPDP Section 11 grievance route is an efficient architectural answer. See the EU AI Act-compliant productivity intelligence solution page for the gStride architecture.

What the EU compliance officer should do this quarter

Four operating-level actions for the EU-side compliance officer in the run-up to 2 August 2026.

1. Map every workforce-AI tool in the stack against Annex III point 4. Build a single-page register identifying each system, the sub-category it falls under (4(a) or 4(b)), and whether the vendor has provided an Article 6(3) assessment. Schedule the register as a board-level compliance artefact.
2. Demand the vendor evidence pack on every contract taking effect after 2 August 2026. The eight written disclosures listed above should be a contract precondition, not a post-signing best efforts. A vendor that cannot produce them is signalling either architecture gap or no assigned compliance owner.
3. Conduct the deployer Article 27 fundamental rights impact assessment (or equivalent) for high-risk systems. Even if the strict Article 27 obligation does not attach, the defensive documentation value of the FRIA exceeds the cost. Use a template aligned to Article 27(1) categories.
4. Design the Article 14 human-oversight workflow with the deployer's operations team, not just legal. The oversight must be operationally feasible inside the manager's workflow. A legal-team designed flow that the manager bypasses is not oversight.