Article 5(1)(f) emotion recognition at work and in schools

Does the EU AI Act ban emotion recognition at work and in school?

Yes, with one narrow exception. Article 5(1)(f) prohibits AI systems that infer the emotions of natural persons in the workplace and in education institutions. The exception covers systems intended for medical or safety reasons, such as a driver-fatigue or clinical monitoring tool used for those purposes. The prohibition has applied since 2 February 2025. If your HR platform, learning tool or workplace analytics product reads emotion from faces, voices or written text and any employee or student is exposed to it, you need to establish first whether the emotion inference can run at all in that setting, before anything else in the compliance program.

The risk the ban addresses is the power imbalance between an employer or school and the people it assesses, where an inferred emotional state can influence hiring, promotion, grading or discipline without the person knowing or being able to contest it. The hard part is evidence. A vendor may say the emotion feature is turned off, but a switched-off feature is not the same as an absent one. Ask the vendor and your own engineers to show which model versions, endpoints, SDK calls and configuration keys can produce emotion labels, and whether those outputs are written to logs, dashboards or downstream scoring. Confirm this against the actual deployed build, not the marketing sheet.

The prohibition binds both providers, who place such systems on the market, and deployers, who put them into service or use them. Fines for breaching it can reach EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(3)). Emotion recognition used outside these settings is not banned, but where its use is permitted by law it is high-risk under Annex III point 1(c), and from 2 August 2026 deployers must inform the people exposed to it under Article 50(3). Read the Article 5 text on EUR-Lex with your legal team before deciding how to scope the medical or safety argument.

Which systems, teams and vendors fall inside the ban

Article 5(1)(f) turns on three questions: what the system does, where it is used, and who is exposed to it. The cards below walk through the decisions that settle whether a system is banned, high-risk or outside both categories. Work through them in order, and record each answer in writing before any contract or deployment decision is made.

Inference of emotions, not face detection

The ban applies to systems that infer the emotions of people, such as concluding that a worker is stressed, bored or disengaged. A system that only detects a face, counts people or estimates age is not an emotion recognition system for this purpose. Ask the vendor for the output schema and the model's documented purpose. If the product returns an emotional state label, treat it as in scope even if the vendor describes it as <strong>engagement analytics</strong> or <strong>sentiment</strong>.

Workplace and education settings

The prohibition covers emotion inference of people in the workplace and in education institutions. Check whether the system is used on employees, job candidates during interviews, students, or staff of schools and training providers. Video interview tools, call-monitoring modules, meeting analytics and classroom attention tools all fall within these settings when used on the people concerned. Use outside these settings is a separate analysis.

Bundled features in HR and LMS platforms

Emotion features are often switched on inside a wider HR suite, recruiting tool or learning management system, sometimes by default or in a module that is not part of the core contract. Map every enabled feature in each platform, including those added by updates. Ask the vendor to confirm in writing which features infer emotions, and who configured them. Your organization is exposed as a deployer even when the vendor supplied the feature.

Medical and safety intent

Article 5(1)(f) excepts systems intended for medical or safety reasons. The exception depends on intent and documented purpose, not on the technology. Examples a reviewer will test include a system used by an occupational health service to detect fatigue in a driver, or a safety system that alerts a supervisor to distress in a hazardous role. Record the medical or safety purpose, the people it covers and the limits on use, and confirm that the system is not used for performance or hiring decisions.

Provider and deployer roles

The ban binds two parties: the provider that places the system on the market or puts it into service, and the deployer that uses it. A vendor cannot remove your exposure by contract, and you cannot rely on the vendor's assurance alone if you configure or use the feature. Document which party is the provider, which is the deployer, and who controls each setting, so that both sides can answer an authority's questions.

Fallback to high-risk and disclosure duties

If a system infers emotions outside these settings and its use is permitted by law, it may be high-risk under Annex III point 1(c). Emotion recognition that is not prohibited also triggers a duty to inform the people exposed to it, which applies from 2 August 2026. Where a system falls outside the ban, record the reason, the setting and the legal basis, then plan the high-risk and disclosure work that follows.

How an assessor tests the prohibition

This table walks through the checks a market surveillance authority or independent assessor would run against the Article 5(1)(f) ban, with the evidence each step requests and the findings that most often cause problems. Read each row as a test step: what the assessor does, what proof they ask for, and where organizations usually fail. The main takeaway is that a vendor claim of no emotion recognition is not enough without configuration proof.

Test step	What the assessor checks	Evidence requested	Common finding
Inventory review	Whether any workplace or school system infers emotions, including features bundled into video interview, meeting, proctoring or engagement tools	Current AI system inventory with feature-level entries, owners and deployment locations	Emotion features omitted from the inventory because they sit inside a larger product
Vendor documentation	Whether the vendor's technical documentation states that emotion inference is present, disabled or absent in the version deployed	Vendor documentation for the installed version, release notes and written vendor statements	Marketing material says no emotion analysis, but the product documentation lists it as a feature
Configuration check	Whether emotion inference is turned on in production, including by default settings and optional modules	Configuration exports, feature flags, admin console screenshots and change logs with dates	Features enabled by default and never reviewed after installation
Deployment sampling	Whether the feature runs in a sample of workplaces and schools, across departments, campuses and pilot groups	Deployment register listing sites, user groups and go-live dates for each sampled location	Pilots run in one team or campus without being recorded as deployments
Setting and recipient check	Whether the people exposed are employees, workers, contractors, students or pupils in an education institution	Organization charts, enrollment context and records of who the system analyzes	Use cases described as customer research or candidate screening that still analyze staff or students
Medical or safety justification	Whether any claimed medical or safety purpose is genuine, specific and documented for the system as deployed	Written purpose statement, risk assessment, clinical or safety rationale and the controls limiting use to that purpose	Broad safety wording with no link to a specific hazard, or the output used for performance management
Undocumented exceptions	Whether local teams, integrations or third-party plugins create emotion inference outside the approved configuration	Integration inventory, API logs, plugin lists and attestations from business owners	Custom scripts or analytics add-ons that infer mood from voice or facial data without a central record
Transparency and governance	Whether any permitted emotion recognition outside these settings is disclosed to the people exposed, and whether governance approves it	Notices given to affected people, approval records and periodic reviews of configuration	No approval trail, and disclosure missing for systems that fall outside the ban

Steps to show the system stays outside Article 5(1)(f)

This sequence shows, with dated records, that no AI feature in the platform infers emotions of people at work or in education institutions, or that any such feature falls under the medical or safety purpose and is controlled as a result. It gives an auditor a traceable path from inventory to decision.

Inventory every AI feature that touches people
Start with a complete list of AI features in the self-hosted platform, including vendor models, open-source components, analytics modules, meeting or call tools, chat assistants and any plugin that processes video, audio, text or biometric signals. Engineering and the product owner compile the list, and each entry records the feature, its inputs, its outputs and the deployment it runs in. The step is done when a named owner has signed off that the list matches the running configuration, not just the design documents.
Flag features that could infer emotions
Review each inventory entry against the question of whether it could infer emotional states such as anger, stress, boredom, engagement or distress from facial expressions, voice, physiological signals or body movement. Compliance and the technical lead do this together, and they test outputs, not only labels, since a sentiment score on text can also be read as an emotion inference depending on its design and use. The output is a flagged register with a short reason for each flag and for each entry cleared.
Confirm the setting where each flagged feature runs
For every flagged feature, record whether it is used on people at work, in an education institution, or in another setting such as a retail, public or home context. Ask the business owner which teams, sites and student or staff groups receive the output, and check the deployment records for the actual users. The check closes when each flagged feature is tied to a setting and an owner, and any feature with unclear use is treated as in scope until the facts are confirmed.
Document any medical or safety purpose and its limits
Where a feature in a workplace or education setting is claimed to serve a medical or safety purpose, the organization documents the specific purpose, the people it applies to, the evidence that the purpose is genuine, and the limits on use. The document should state what the system must not be used for, such as performance rating or disciplinary action. Legal and the relevant safety or occupational health lead approve the record. Ask counsel to confirm the exception's reach, because the exception is narrow and should not be assumed from a general safety claim.
Disable or restrict non-compliant features
Any flagged feature that infers emotions in a workplace or education setting without a documented medical or safety purpose is switched off in production, and the configuration change is recorded. Where a feature serves a permitted purpose outside those settings, restrict it to that use through access controls, feature flags or separate deployments. Engineering keeps the configuration diff, and the owner confirms in writing that the feature no longer runs for prohibited users. Check logs afterward to show that the feature has stopped processing those inputs.
Assess high-risk and disclosure duties for other settings
Where a flagged feature is used outside the workplace and education settings, determine whether it is an emotion recognition system whose use is permitted by law, which makes it high-risk under Annex III point 1(c), and whether Article 50(3) disclosure applies to the people it reaches. Note that the disclosure duty applies from 2 August 2026. Record the conclusion, the legal basis relied on, and any high-risk obligations the organization must then meet, with counsel confirming the classification.
Record the decision and keep it under review
Bring the register, configuration evidence, purpose documents and classification conclusions into one signed decision record for each system. The record states that the system is outside Article 5(1)(f), or explains how it is controlled if it falls under the medical or safety exception, and names the owner and reviewer. Schedule a re-review whenever a feature, dataset or user group changes. The record is the evidence an assessor or market surveillance authority will ask to see first.

Where the medical and safety exception stops and high-risk rules start

The ban in Article 5(1)(f) does not reach emotion recognition systems intended for medical or safety reasons, but that carve-out only works if you can show the intent behind the system and its boundaries. Start by writing down the specific medical or safety purpose the system serves, who it is used on, and where it is used. A general claim that a tool "improves wellbeing" or "supports staff" will not hold up. If the intended purpose is a medical or safety function, record the clinical or hazard context, the people responsible for that context, and the conditions under which the output may and may not be used. Keep that record with the system's technical documentation so an assessor can trace the purpose from design to deployment.

Where the intent is not medical or safety, or the system is used in a workplace or education setting beyond that intent, the analysis changes. Emotion recognition systems outside the prohibited settings are high-risk under Annex III point 1(c) where their use is permitted by law, which brings in the high-risk obligations covered elsewhere in this guide. Separately, Article 50(3) requires deployers of emotion recognition systems that are not prohibited to inform the people exposed to them, and this duty applies from 2 August 2026. Treat the disclosure notice as a deployment task with an owner, a wording review and a record of when each affected group was informed.

The line between the exception and the rules that follow is a legal question with consequences, and this page does not settle it for your system. Ask counsel to confirm three things in writing: whether the medical or safety purpose falls within the exception as your use case describes it, whether the system is used in a setting the prohibition covers, and which high-risk and disclosure duties apply to the residual uses. Ask for the reasoning, not only the conclusion, and keep it with the classification record. Because the fine for breaching the prohibition is up to EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(3)), the cost of a wrong classification is much higher than the cost of a careful review.

Evidence that shows the prohibition is respected

An assessor will not take the absence of emotion recognition on trust. The records below show what the system does, where it is switched off, who can change that, and why any exception applies. Each artifact needs an owner and a refresh cadence, because a setting that was off at the last audit can change with the next vendor release.

AI system inventory entries

Record every feature that infers emotions as its own entry, including features that are bundled into video meeting, call analytics, HR survey or learning platforms. For each entry, note the vendor, the deployment tenants, the settings where the feature is present, and whether it is enabled for workplace or education users. Review the inventory at each release cycle and whenever a new tenant is onboarded, so that an unlisted emotion feature cannot slip through.

Vendor attestations and configuration exports

Ask each vendor in writing whether its product infers emotions, which modules do so, and how that capability can be disabled. Keep the attestation with the contract and date it. Export the actual configuration from each workplace and school tenant, rather than relying on the vendor's default documentation, and store the export with a timestamp so the assessor can compare it with what the attestation says.

Feature flags and model capability records

Show that inference is off at the technical layer, not only in a policy statement. Keep the feature-flag state, the model or API capability list, and the deployment manifests for each environment. Confirm that emotion outputs are not written to logs, dashboards or downstream databases. Re-run this check after every vendor update, since updates sometimes re-enable features that were turned off.

Medical or safety justifications

Where a system is used for medical or safety reasons, the exception needs its own written justification. Document the specific medical or safety purpose, the people affected, the reason no less intrusive method was adequate, and the approval by the accountable owner. Keep the justification separate from general product documentation, and review it whenever the use case, the setting or the population changes. Without it, the exception cannot be shown.

Access and change logs

Log who can enable, disable or configure emotion-related features, and every change made to those settings. Retain the logs in a system that administrators cannot silently edit, and export them for each assessment period. Reconcile the change history against the configuration exports, because a gap between the two is the first thing an assessor will look for.

Periodic re-checks after vendor updates

Schedule a documented re-check of each workplace and school tenant after every vendor release, and at a fixed interval in between. The re-check repeats the configuration export, the flag review and a sample of outputs, and records the result and the person who signed it off. Confirm the cadence with your own change management process, and keep the dated results so that the record shows continuous control rather than a single point-in-time check.

What meeting Article 5(1)(f) costs in money and effort

This table breaks down the cost components of showing that an AI system avoids the workplace and education emotion recognition ban, who is paid for each one, and whether it is one-time or recurring. Read it as a checklist for building a quote, since no fee figures are supplied and the main cost of getting it wrong is the fine ceiling in Article 99(3).

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Inventory of AI features that infer emotions	Internal product and engineering staff, sometimes with an implementation partner	One-time, then recurring with each release	More tenants, customer sites and feature releases raise the effort. A clear feature register keeps it down.
Classification of each feature against Article 5(1)(f)	Legal or compliance lead, with product owners	One-time per feature, then on every change	Vague feature names and unclear output use cases increase review time. Written intended-purpose statements reduce it.
Vendor due diligence on third-party models and APIs	Procurement, legal and security teams; vendors answer questionnaires	One-time per vendor, then at renewal	Number of vendors and whether vendors disclose emotion-inference features. Ask vendors to confirm this in writing.
Configuration engineering to disable or fence emotion inference	Engineering, often with a self-hosted platform implementation partner	One-time build, then recurring maintenance	Number of tenants and deployment environments. Central configuration with tested switches keeps it down.
Documentation of the medical and safety exception, if relied on	Clinical, safety or legal experts and compliance staff	One-time per use case, reviewed periodically	Number of distinct exception claims. Each claim needs its own justification, so fewer claims are cheaper to defend.
Transparency notices under Article 50(3) for permitted emotion recognition	Product, legal and communications teams	One-time build, recurring review	Number of deployment contexts and languages. Reusable notice templates lower the cost.
Periodic re-testing of the emotion inference block	Security testers, internal or external	Recurring, usually tied to releases	Frequency of model updates and feature changes. Automated regression tests lower repeat effort.
External review or assessor engagement	Independent auditors or legal advisers; only an independent auditor issues reports	Recurring at the frequency the organization sets	Scope complexity and the number of systems reviewed. Ask for a fixed-scope written proposal.
Cost of getting it wrong	Regulator, through fines	Potential one-time exposure	Fines under Article 99(3) reach EUR 35 million or 7% of total worldwide annual turnover, whichever is higher.

Who owns the ban, who prepares evidence and who tests it

Your organization owns the decision. It is the party that places the system on the market or puts it into service or use, so the prohibition in Article 5(1)(f) binds it directly, whether it builds the system or buys it. Leadership must decide whether any system in use infers emotions of staff, contractors, candidates or students, and must sign off that the ban is met or that a narrow medical or safety purpose applies. That sign-off is an internal governance record, not a legal opinion.

Decision ownership: a named executive accepts the classification of each system and the reasons for it.
Product configuration: your teams turn off or remove emotion inference features in HR, meeting, proctoring and learning tools.
Contract terms: procurement requires vendors to state whether emotion inference is active and to notify you of changes.
Staff and student communication: you keep records of any disclosure made under Article 50(3) where emotion recognition is lawful outside these settings.
Sign-off record: you keep dated approvals showing who reviewed each system.

Check that the sign-off names an owner who can stop a feature, because the ban applies to use as well as to purchase.

Questions buyers ask about the emotion recognition ban

Does a sentiment analysis tool count as emotion recognition under the AI Act?

It can, and the answer depends on what the tool infers rather than what the vendor calls it. Article 5(1)(f) covers AI systems that infer the emotions of natural persons, so a tool that labels a person's messages, calls or video as angry, anxious or happy is in scope when it is used in a workplace or education institution. Marketing terms such as sentiment, engagement or tone do not change the analysis. Ask the vendor to state exactly which emotional states the system outputs, which data it reads (text, voice, face, physiology) and which people it scores. Then map each feature against the ban and against the Annex III point 1(c) high-risk category that applies outside those settings.

Is an anonymous wellbeing survey covered by the emotion recognition ban?

A plain survey that asks employees or students to self-report how they feel is generally not an AI system inferring emotions from their biometric or behavioral data, so it sits outside the ban on its own. The picture changes when the survey is paired with AI that analyzes free-text answers, voice recordings or webcam footage to deduce emotional states. Check three points: whether the AI infers emotion from the person's data, whether the output is linked to individuals or groups in a way that exposes them, and whether the survey operator and the people using results are in a workplace or education setting. Document the analysis, since assessors will test the boundary rather than accept a label.

Does a feature from our HR or learning platform vendor make us compliant?

No. Under the AI Act, the prohibition binds both providers and deployers, so a vendor's feature does not transfer your obligations to the vendor. If your organization switches on or uses an emotion inference feature in the workplace or in education, you are the deployer and carry your own exposure to the ban. Ask the vendor in writing whether the feature is disabled by default, whether it can be turned off per tenant, what data it processes and whether it has a documented medical or safety purpose. Keep the vendor's answers as evidence, and confirm the configuration yourself rather than relying on the contract.

Does the medical or safety exception cover a fatigue detection system for drivers?

It may, but the exception is narrow and must be shown, not assumed. Article 5(1)(f) excludes systems intended for medical or safety reasons, so a driver monitoring system built to detect fatigue or drowsiness for road safety is a candidate for the exception when the purpose is documented and the system is limited to that purpose. Assessors will ask what the system infers, who it monitors, what it does with the output and whether the same data also feeds performance or disciplinary decisions. Any use beyond the stated safety or medical purpose removes the exception. Record the intended purpose, the design limits and the safeguards in your risk documentation, and have counsel confirm how the exception applies to your jurisdiction and sector.

How long does it take to prepare, and what do we need from staff?

Preparation time depends on how many systems you must review, how well they are documented and how many people must be interviewed. Drivers include the number of workplace and education tools with any emotion or affect feature, whether vendors can explain their outputs, and whether a system inventory already exists. Staff inputs usually cover HR, legal, works councils or employee representatives where they apply, IT owners who can confirm configurations, and data protection leads who can assess lawful processing. Ask any partner to state the timeline and the staff hours in the written scope, and confirm which of those items your team must deliver before the work starts.

Can our own team handle this review without an outside partner?

Often yes for a small, well-documented environment, and the decision turns on capacity and independence rather than on the law alone. An internal team needs a clear inventory of AI-enabled tools, someone who can read vendor technical documentation, legal input on the Article 5 boundary, and a way to test configurations. A partner can help with technical testing of self-hosted tools, configuration evidence and readiness documentation, but the organization keeps ownership of the decisions. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports or certificates. Where an independent view is required, bring in an assessor or counsel separately. Decide early which tasks you will keep in-house, and write those responsibilities down.

What are the fines if we breach the emotion recognition ban?

Breaching Article 5 carries the highest tier of penalties in the Act. Under Article 99(3), fines can reach EUR 35 million or, for an undertaking, 7% of total worldwide annual turnover for the preceding financial year, whichever is higher. The prohibition covers placing on the market, putting into service and use, so deployers as well as providers can be exposed. National market surveillance authorities enforce the Act for AI systems. Because the ban has applied since 2 February 2025, there is no transition period to rely on for prohibited practices. Treat any emotion inference feature in a workplace or school as a priority item for review.

Where teams fall short on the emotion recognition ban

Most organizations that breach Article 5(1)(f) do not intend to. Emotion inference usually arrives inside tools bought for other reasons, switched on by someone outside compliance, or extended to groups nobody reviewed. The gaps below are where an assessor or regulator is most likely to find the problem first.

Emotion features hidden in bundled analytics

Workplace and learning platforms often ship sentiment, engagement or attention scoring as one checkbox inside a broader analytics suite. Teams buying the suite for scheduling or course completion may never read the feature list that describes inference from faces, voices or keystroke patterns. Before go-live, list every module the product can run, and mark each one that infers emotional state from biometric or behavioral signals.

No record of who enabled it

A feature flag, admin setting or pilot toggle can turn emotion inference on without a ticket, approval or owner. When a regulator asks who decided to deploy the system and when, a team without a change log has to reconstruct the answer from memory. Keep a dated record of each enablement, the person who approved it, and the workplace or education setting in which it runs.

Vendor updates re-enabling inference

A vendor release can add emotion analysis to a product that was previously clean, or change defaults so that a feature turns on after an upgrade. Organizations that treat software updates as routine patching may not review the release notes for new inference capabilities. Require the vendor to list new analytics features in every release, and test each upgrade against a written list of prohibited functions before it reaches production users.

Medical or safety claims without documentation

The exception for systems intended for medical or safety reasons is narrow, and a bare statement that a tool is for wellbeing or safety does not establish it. Teams that rely on the exception should document the specific medical or safety purpose, the clinical or safety basis for it, and why the inference is needed to achieve it. Where that case cannot be written down clearly, treat the system as prohibited, not as a permitted exception.

Students and contractors missed in scope

The prohibition covers the workplace and education institutions, which include more people than salaried staff. Contractors working on site, interns, apprentices, trainees and students on placement can be exposed to the same system without appearing in the HR roster that drives the scope review. Map every population that passes through the premises or the platform, including visitors and agency workers, and confirm each one is covered by the decision.

No disclosure process for permitted uses

Where emotion recognition is lawfully used outside the banned settings, the deployer must inform the people exposed to it, and that duty has applied from 2 August 2026 under Article 50(3). Many teams have no notice text, no point in the user journey where the notice appears, and no owner who checks that it still runs after a change. Assign an owner, write the notice, place it before exposure, and retain proof that it was shown.

How DeployOpen prepares evidence for this prohibition

DeployOpen works on Article 5(1)(f) by helping organizations show that AI systems in their own workplaces and education institutions do not infer emotions, or that any exception is documented and bounded. We prepare the systems, records and evidence in the client's own infrastructure, while the organization owns its compliance decisions and independent assessors issue any formal conclusions.

How we scope

Written scope names each AI system, its vendor, its inputs and where it is deployed.
Scope confirms whether any system could infer emotions of staff, candidates, students or pupils.
Scope records any claimed medical or safety purpose so the exception can be reviewed on its facts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We inventory AI features in self-hosted platforms and flag any emotion or affect inference capability.
We configure logging of inputs, outputs and tool calls with Langfuse so model behavior can be traced.
We test systems for emotion inference with garak probes and keep every attempt and result as records.
We document disabled or blocked features and the configuration that keeps them off in production.

How we hand over

Handover includes a dated register of AI systems, their settings and the owner of each decision.
Evidence packs map each control to the artifacts that show it, held in CISO Assistant where the client uses it.
Deliverables include notes on what the organization must confirm with vendors and legal counsel.
We do not issue audit reports, attestations or certifications; independent assessors perform that role.

How we support

Ongoing support is available as a retainer for configuration drift, upgrades and new AI features.
Periodic re-testing can confirm that emotion inference stays disabled after platform changes.
Support covers re-running evidence collection ahead of an assessor's review or an internal audit.
Retainer scope, frequency and response expectations are set out in the written agreement.