Answer capsule
Article 5(1)(f) prohibits workplace AI that infers a person's emotions or intentions from biometric data, except when the use is intended for medical or safety reasons. CHROs need a function-level record of the signal, intended purpose, configuration, affected people, and employment decision.
What the source establishes
- Regulation (EU) 2024/1689 Article 5(1)(f) prohibits placing on the market, putting into service for this purpose, or using AI systems to infer emotions of a natural person in workplaces and education institutions, except where the use is intended for medical or safety reasons.
- Article 3(39) defines an emotion recognition system as an AI system intended to identify or infer emotions or intentions of natural persons on the basis of their biometric data.
- Recital 18 says the definition does not include physical states such as pain or fatigue, or the mere detection of readily apparent expressions, gestures, or movements unless they are used to identify or infer emotions.
- Article 113 makes Chapters I and II, including the prohibited-practices chapter, applicable from February 2, 2025; other provisions in the Regulation follow different application dates.
Define the function before classifying the product
Start with the data and claimed inference. Article 3(39) ties emotion recognition to biometric data used to identify or infer emotions or intentions. Record the exact signal, asserted output, affected person, workplace context, intended purpose, decision influence, provider, configuration, and owner. Do not silently treat every sentiment label, self-report, physical-state alert, or detection of a visible expression as the same statutory function; preserve the facts and route classification to qualified review.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Keep the exception tied to intended medical or safety use
Article 5(1)(f)'s exception turns on a use intended for medical or safety reasons, not a broad product category or an untested vendor label. Record the intended purpose in design, configuration, and contract records; identify who determines it, how the output is used, and whether the same feature also influences hiring, performance, discipline, or access to work. Mixed purposes, secondary use, territorial scope, and the evidence supporting the exception require qualified review.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Stop affected employment paths while facts are reviewed
When a feature appears to infer emotion from biometric data in a workplace and an intended medical or safety use has not been established, isolate the feature, preserve its configuration and use record, and prevent the output from affecting an applicant or worker while qualified reviewers assess the facts. A human glance at the output does not by itself resolve Article 5 because the provision addresses placing on the market, putting into service for the prohibited purpose, and use.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Make disabling and change control testable
Contracts and configuration records should identify optional emotion-related features, defaults, biometric inputs, model or service dependencies, derived fields, exports, retention, deletion, and change notifications. Test that disabling the feature stops the relevant collection and inference across employee interfaces, administrator views, APIs, integrations, reports, and historical reprocessing. Preserve the Regulation, provider representation, observed configuration, exception analysis, decision owner, and review date as separate records so a renamed feature or product update cannot silently change the assessed use.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Decision test
Ask whether the source changes the decision itself, the evidence required, the implementation sequence, or only the language used to describe an existing capability. Record which claims are directly supported, which are provider statements, which require an independent test, and which remain unknown. A source-linked review should make uncertainty easier to see, not bury it inside a blended score.
Questions to take into review
- Does the tool materially influence who advances?
- What validated job criteria support the output?
- Which data is job-related and known to employees?
- How are context and accommodations represented?
- Could a person be reidentified?
- What was the stated collection purpose?
- Which roles and tasks change?
- How are workers or representatives involved?
The publication supports research and executive decision preparation. It does not provide legal, financial, accounting, employment, clinical, cybersecurity, investment, procurement, or implementation advice.