Workforce, Labour & HR Compliance Reporting

Product guides for labour authority reporting, employee registration, HR compliance workflows, workforce data validation and public employment integrations.

Workforce, Labour & HR Compliance Reporting covers product workflows for employee registration, labour authority submissions, workforce data validation and HR compliance evidence.

Primary entities:
labour authority reporting, employee registration, HR compliance, workforce data, payroll-adjacent reporting, employment records.

10
Aug
2026

Telling staff about AI at work: the Article 26(7) duty

Article 26(7) of the EU AI Act (Regulation (EU) 2024/1689) requires employer-deployers of high-risk AI systems to inform workers’ representatives and the affected workers that they will be subject to the system, before it’s put into service or used at the workplace. That information is provided, where applicable, in accordance with the rules, procedures and practice on informing workers and their representatives laid down in Union and national law. One short clause routes the AI Act straight into works council law — and the procedure, the timing, and the leverage workers actually have are all determined nationally from there, not by the Act itself.

What the duty actually is

Read literally, the Act’s own text requires informing, not consulting. But that duty is expressly channelled through whatever national information rules and practice already exist — and in several Member States, those rules go further and require actual consultation before a workplace change like this. This distinction decides your real timeline: if you’re only reading Article 26(7) itself, you might plan for a notice sent shortly before go-live; if your national regime channels this into an existing consultation obligation, you’re planning for a process with its own lead time, and possibly its own points where workers’ representatives can push back before you’re clear to proceed.

Who has to be told

Both workers’ representatives and the affected workers themselves — not one or the other. “Affected workers” is a broader category than “users of the system.” A worker who is monitored, evaluated, or has decisions made about them by a high-risk system is affected by it whether or not they ever personally interact with its interface. Scoping this notice to the people who log into the tool, rather than everyone the tool is actually applied to, undercounts who the Act means to protect.

When

Before the system is put into service or used. For a phased rollout, that points toward informing each new population as it’s actually brought into the system’s scope, rather than a single blanket notice issued at the start that tries to cover populations not yet affected. A pilot counts — running a smaller-scale version of the system is still putting it into service or using it, and doesn’t get treated as exempt just because it’s temporary or limited. A vendor upgrade that changes what the system actually does to workers — new monitoring capability, a different basis for evaluation — is a fresh trigger in its own right; the original notice covered the original system, not whatever it becomes afterward.

The Article 2(11) fragmentation problem

Article 2(11) states plainly that the Regulation doesn’t prevent the Union or Member States from maintaining or introducing legislative or administrative provisions more favourable to workers regarding the protection of their rights in relation to employers’ use of AI systems, or from encouraging or allowing more favourable collective agreements. The AI Act sets the floor; national law and collective bargaining set the ceiling, and the ceiling varies. A rollout across the EU doesn’t have one answer to “what do we owe workers here” — it potentially has as many answers as there are Member States involved, and collective agreements can raise the bar further still in any one of them. Rather than attempting to summarise 27 different national positions here, the honest move is to point at the national implementation trackers directly and check the specific markets a rollout actually touches.

What else the employer-deployer owes

Article 26(7) doesn’t sit alone. The same Article requires using the system in accordance with its instructions for use, and assigning human oversight specifically to natural persons who have the necessary competence, training and authority, and who receive the necessary support to exercise it — not oversight assigned on paper to someone without the standing or resources to actually do it. Where the deployer controls the input data, that data has to be relevant and sufficiently representative for the system’s intended purpose. And deployers monitor the system’s operation against its instructions for use, retaining the automatically generated logs, to the extent under their control, for a period appropriate to the system’s purpose and at least six months, unless other Union or national law requires longer.

Separate from all of this, Article 4 AI literacy applies regardless of risk tier — it isn’t limited to high-risk deployments — and it explicitly reaches staff and other persons operating or using AI systems on the deployer’s behalf, not employees alone. A contractor or an external service provider running your systems for you falls inside this duty too.

A practical sequence

Inventory what AI systems are actually deployed at the workplace and where. Classify which are high-risk. Identify the affected population properly, beyond just the direct users. Map the specific national information and consultation route for each country involved, since this isn’t one process repeated identically everywhere. Brief workers’ representatives through that route. Document the date this happened, since it’s the fact you’ll need to point to later. Only then go live.

Frequently asked questions

Is a works council agreement required before we can proceed?

Not under the AI Act’s own text, which only requires informing. Whether a formal agreement, or consultation with a real chance to object, is required depends entirely on whether your national information and consultation regime already demands that for a change like this — in jurisdictions with strong co-determination rights, it very well might be.

Does this apply to a tool we already use?

The duty attaches to putting the system into service or using it — a tool already in continuous use presumably triggered it at that original point. A material change to what the tool does, or who it’s applied to, is a fresh trigger in its own right, even for a system that’s been running for years.

What if the system isn’t high-risk?

Article 26(7) specifically is a high-risk deployer obligation, so it doesn’t apply on its own terms to a non-high-risk system. Article 4 AI literacy still applies regardless of risk tier, and separate national employment or data protection law may independently require informing workers about workplace monitoring tools whether or not the AI Act’s own high-risk trigger is met.

Can workers object once informed?

The Act’s own text gives an information right, not an explicit objection right. Whether workers or their representatives have real leverage to push back depends on the national regime Article 26(7) channels this through — some Member States’ consultation frameworks give workers’ representatives genuine influence over the outcome; others may limit the right to notice itself.

What’s the penalty for skipping it?

Article 26 obligations, including this one, sit in the same fine tier as the rest of the Act’s high-risk operator duties: up to €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher, with the lower of the two figures applying to SMEs and start-ups instead.

Posted by admin in Workforce, Labour & HR Compliance Reporting
08
Aug
2026

Targeted job ads are high-risk AI under Annex III

Annex III point 4(a) of the EU AI Act (Regulation (EU) 2024/1689) covers AI intended to be used for recruiting or selecting natural persons, “in particular for placing targeted job advertisements, analysing and filtering applications, and evaluating candidates.” Targeted job advertising is named first, ahead of application filtering and candidate evaluation, in the operative text itself. Most HR compliance programmes classify the applicant tracking system and the interview-scoring tool without ever looking at the ad-targeting stack behind a recruitment campaign — because that stack usually sits with marketing, not HR, and nobody told marketing this Annex applies to them too.

What Annex III point 4 actually lists

Point 4(a) covers recruiting or selecting natural persons, with three named examples: placing targeted job advertisements, analysing and filtering applications, and evaluating candidates. Point 4(b) covers a separate category — decisions affecting the terms of a work-related relationship, promotion or termination of a work-related contract, allocating tasks based on an individual’s behaviour or personal traits, and monitoring or evaluating the performance and behaviour of people already in that relationship.

Why the ad stack is the blind spot

Follow where ownership actually sits inside a typical organisation. The applicant tracking system has an HR owner, and by now usually has an AI Act classification attached to it. The audience-targeting model deciding who sees a given job advertisement — built into or bolted onto a recruitment marketing campaign — has a marketing owner, and in most organisations no classification has ever been attempted. Both sit inside the same legal category. Annex III point 4(a) doesn’t distinguish between the system that decides who to interview and the system that decides who gets shown the ad in the first place; it names the second one first.

Can you exempt out under Article 6(3)?

Article 6(3) lets a provider treat an Annex III system as not high-risk where it poses no significant risk of harm and meets one of four conditions: it performs a narrow procedural task; it improves the result of a previously completed human activity; it detects decision-making patterns or deviations from them without replacing or influencing a previously completed human assessment without proper human review; or it performs a preparatory task for an assessment relevant to an Annex III use case.

Test an ad-targeting model against these honestly rather than reaching for whichever sounds closest. Deciding which individuals see a job advertisement, based on inferred interests, behaviour, or demographic proxies, is not a narrow procedural task — it’s a substantive targeting decision, arguably the central function of the model. It’s a weak fit for “improving a previously completed human activity” unless a human already decided the exact audience and the model only optimises delivery mechanics within that fixed audience. It doesn’t detect patterns or deviations from prior decisions in the way the third ground contemplates. And it’s a stretch to call the core targeting decision merely “preparatory” to some later assessment, when the targeting decision is often the entire point of the system.

The override that ends the argument

Even where one of the four grounds might plausibly fit, Article 6(3) closes with an override that applies notwithstanding all of them: an Annex III system is always considered high-risk if it carries out profiling of natural persons. No exemption survives that. An audience model built on individual behavioural traits — inferred interests, browsing history, demographic signals used to decide who sees what — is profiling by any ordinary reading of the term. That ends the Article 6(3) argument regardless of how well the model might otherwise have fit one of the four narrow grounds.

The price of claiming the exemption anyway

If you conclude your ad-targeting model genuinely clears Article 6(3) despite this, the exemption doesn’t make the system invisible. You keep the underlying assessment, and you register the system in the EU database with a summary of the grounds you relied on — and that summary sits in the database’s public section, readable by anyone, including a competitor or an advocacy group. The mechanics of that registration duty, and what happens if a market surveillance authority later disagrees with your classification, are covered in full in a companion piece on Article 6(3) registration and Article 80 enforcement rather than repeated here.

When this bites

Annex III obligations now apply from 2 December 2027, following the Digital Omnibus deferral, once the amending regulation is actually published in the Official Journal. Recruitment and employment systems sit in the Annex III categories that go through internal-control self-assessment rather than a notified body, so unlike biometric AI, there’s no third-party capacity bottleneck standing between now and that date. The sixteen-odd months between now and then are for inventory and classification work specifically — finding every system that touches recruitment, including the ones marketing owns — and that work doesn’t depend on any external standard or authority being ready first. Nothing about the extended timeline changes what needs to be found; it only changes how much time there is to find it.

Frequently asked questions

Does using LinkedIn’s ad targeting make us a deployer?

Likely yes. The platform is ordinarily the provider of the underlying targeting system, and the business running a recruitment campaign through it is the deployer — deployer obligations attach to you regardless of who built the model underneath the campaign tool you’re using.

What if the vendor says their tool isn’t high-risk?

Verify it yourself rather than relying on that assurance. The classification decision, and the consequences if a market surveillance authority later disagrees with it, attach to whoever is actually making the call — a vendor’s own marketing claim about its product’s risk tier doesn’t relieve you of that.

Are we the provider or the deployer?

Ordinarily the deployer, using a system someone else built. You become a provider yourself only if you put your own name or branding on the system, substantially modify it, or change a non-high-risk system’s intended purpose in a way that makes it high-risk — the same test that applies to importers and rebranders elsewhere in the Act.

Does a job board’s own matching algorithm count?

To the extent a job board’s algorithm recruits, selects, or filters candidates on an employer’s behalf, that function sits inside Annex III 4(a) in its own right — with the job board as a plausible provider of that specific functionality and the posting employer as its deployer.

Does an internal mobility tool count?

That sits closer to Annex III 4(b) than 4(a) — assessing existing employees for promotion or transfer eligibility is a decision affecting the terms of an employment relationship, not external recruitment. The same profiling override applies equally regardless of which limb of point 4 the tool falls under.

Posted by admin in Workforce, Labour & HR Compliance Reporting
04
Aug
2026

ISO 42001 Annex A: 38 controls, not 39

Annex A of ISO/IEC 42001:2023 contains 38 controls across nine control objectives, numbered A.2 through A.10. The count matters less than what it’s for: Annex A is a reference set an organisation selects from through its own risk assessment, not a checklist to complete in full.

The answer

38 controls, nine control objectives, running A.2 to A.10:

Objective Covers Controls
A.2 Policies related to AI 3
A.3 Internal organisation 2
A.4 Resources for AI systems 5
A.5 Assessing impacts of AI systems 4
A.6 AI system life cycle 9
A.7 Data for AI systems 5
A.8 Information for interested parties 4
A.9 Use of AI systems 3
A.10 Third-party and customer relationships 3

That totals 38. A.6 is the one objective worth extra care if you’re counting these yourself: it’s the only control objective with a nested, two-level structure — A.6.1’s management-guidance controls, then A.6.2’s system-lifecycle controls beneath it — rather than the flat A.X.Y pattern every other objective uses. It’s the easiest place to miscount by one.

Why the number is the least useful fact about Annex A

Under Clause 6.1.3 of ISO/IEC 42001:2023, organisations select which Annex A controls to implement through their own risk treatment process, document every inclusion and every exclusion with justification in a Statement of Applicability, and may design or implement additional controls beyond Annex A entirely where their risk assessment calls for it. Annex A is a reference set to select from, not an exhaustive checklist to complete.

The practical consequence cuts against the instinct to just implement everything. An organisation that has all 38 controls in place but no documented reasoning behind its selections fails an audit on the Statement of Applicability alone. An organisation with 30 controls implemented, and clear, risk-based justification on record for the eight it excluded, passes. The count of controls implemented was never the thing being tested.

Is Annex B normative?

Annex B gives implementation guidance for each Annex A control — practical detail on how to satisfy a control you’ve selected, not a further set of obligations sitting alongside it. What that means in an audit: an organisation doesn’t have to document or justify its use of Annex B guidance in the Statement of Applicability the way it must for the Annex A controls themselves. Whatever Annex B is formally classified as, it doesn’t carry the audit-tracked weight Annex A does, and that’s the fact worth building a compliance programme around.

On the formal classification itself, the honest position is that the full standard text sits behind ISO’s paywall, and the clearest secondary description available labels Annex B “(normative)” rather than informative. Treat that label as directional rather than fully confirmed, and build your programme around the practical distinction above regardless of how the annex is formally classified.

What the other annexes are for

Annex C sets out potential AI-related organisational objectives and common risk sources — bias, security, misuse, explainability, data quality — functioning as an idea bank when populating the standard’s planning clauses, rather than a set of controls in its own right. Annex D addresses using the AI management system across different domains and sectors, including how the AIMS integrates with ISO/IEC 27001, ISO/IEC 27701, ISO 9001, and sector-specific standards such as ISO 13485 for medical devices.

How this compares to ISO 27001

ISO/IEC 27001:2022‘s Annex A runs to 93 controls across four themes — considerably larger than ISO/IEC 42001:2023’s 38, and organised around a completely different risk object: information security generally, rather than AI specifically.

ISO/IEC 42001:2023 ISO/IEC 27001:2022
Annex A controls 38 93
Number of themes 9 4
Theme breakdown Policy, org, resources, impact assessment, lifecycle, data, information, use, third parties Organisational (37), people (8), physical (14), technological (34)
Risk object AI system behaviour and impact Information confidentiality, integrity, availability

The two annexes genuinely overlap on general governance ground — policy-setting, roles and responsibilities, supplier and third-party management, documented risk treatment discipline. Where ISO/IEC 42001:2023 adds something ISO/IEC 27001:2022 was never built to cover is the AI-specific territory: bias and fairness, transparency to affected people, human oversight of automated decisions, and structured AI impact assessment. An organisation already running an ISO/IEC 27001:2022 ISMS is extending familiar governance machinery into new subject matter, not starting from nothing.

Frequently asked questions

Are all 38 controls mandatory?

No. Annex A is a reference set selected against your own risk assessment, not a checklist every organisation implements in full.

Can we exclude a control?

Yes, provided the exclusion is documented and justified in the Statement of Applicability. An undocumented exclusion is the actual audit risk, not the exclusion itself.

Do we need to implement Annex B?

Not as a separate, SoA-tracked obligation — it’s guidance to help implement the Annex A controls already selected, not an additional layer of controls sitting alongside them.

Is the Statement of Applicability actually audited?

Yes, and it’s the document an auditor checks against far more closely than a raw control count. The SoA is where the risk-based reasoning is supposed to live; an auditor testing an AIMS is testing whether that reasoning holds up, not counting how many of the 38 boxes are ticked.

Does ISO 42001 certification make us compliant with the EU AI Act?

No — they’re separate instruments, and certification under a management-system standard isn’t the same thing as the AI Act’s own presumption-of-conformity mechanism, which attaches specifically to harmonised standards cited in the Official Journal. An ISO/IEC 42001:2023 certificate is strong evidence of AI governance maturity; it isn’t itself a legal finding of AI Act compliance.

Posted by admin in Digital Operational Compliance & EU AI Act Knowledge Base, Workforce, Labour & HR Compliance Reporting