Regulation: EU AI Act (biometrics/emotion as high-risk), GDPR, FDA

"I inferred the shopper's mood from her gait and served her a discount. Legal informs me that in a European store this is not a feature, it is Article 5, and that nobody asked me to feel clever about it."

A Recently Regulated AI Agent

The EU AI Act: risk tiers, and why biometrics and emotion sit near the top

The AI Act is structured as a pyramid of risk. At the base, minimal-risk systems (a spam filter, a thermostat controller) carry no specific obligations. Above them, limited-risk systems carry transparency duties: a user must be told they are interacting with an AI system or viewing synthetic content. Near the top sit high-risk systems, which carry the full compliance load. At the apex are prohibited practices, banned outright.

Sensory AI is unusually exposed to the top two tiers because so much of it senses bodies. Article 5 prohibits, among others, emotion recognition in the workplace and in educational institutions (with narrow medical and safety exceptions), biometric categorization that infers sensitive attributes such as race or sexual orientation, and untargeted scraping of facial images to build recognition databases. Real-time remote biometric identification in publicly accessible spaces for law enforcement is banned save for tightly drawn exceptions. Everything that survives the prohibition list and still identifies, categorizes, or reads emotion from people generally lands in high-risk (Annex III). That classification is what turns the activity recognition of Chapter 26 and the neuromotor and affect signals of Chapter 27 from research demos into regulated products the moment they attach an identity or an emotional label to a real person.

High-risk status is not a warning label; it is a checklist. The provider must operate a risk-management system across the lifecycle, meet data-governance requirements on the training set (relevance, representativeness, bias examination), keep technical documentation and automatic logs, guarantee meaningful human oversight, and demonstrate accuracy, robustness, and cybersecurity. The system must pass a conformity assessment, carry CE marking, and be registered in an EU database before it goes on the market. Two of those duties, data governance and robustness, are exactly the leakage-safe datasets of Chapter 5 and the calibrated-uncertainty discipline of Chapter 18, now made mandatory rather than merely wise.

GDPR: personal data, special categories, and the impact assessment

The AI Act governs the system; the GDPR governs the data flowing through it, and the two overlap heavily for anything that senses people. Under the GDPR, any processing of personal data needs a lawful basis from Article 6 (consent, contract, legitimate interests, and so on). Sensory AI routinely produces special-category data under Article 9, which is more tightly restricted: biometric data processed for the purpose of uniquely identifying a person, and data concerning health. A gait embedding used only to count people is ordinary personal data; the same embedding used to recognize a returning individual becomes special-category biometric data and needs an Article 9 condition on top of the Article 6 basis. Health inferences from the PPG and ECG pipelines of Chapter 30 are special-category by their nature.

Two GDPR mechanisms bite hardest on sensor systems. First, purpose limitation and data minimization (Article 5) forbid collecting more than the declared purpose needs and forbid quietly repurposing it later, which is the proportionality rule of Section 70.1 given legal force. Second, a Data Protection Impact Assessment (Article 35) is mandatory before large-scale biometric processing or systematic monitoring of public spaces; the DPIA is a written analysis of necessity, proportionality, and mitigations that a regulator can demand to see. Article 22 adds a further constraint: a person has the right not to be subject to a solely automated decision with legal or similarly significant effects, which reaches any sensing system that automatically gates access, employment, or credit.

FDA and medical-device pathways: when a wearable becomes regulated

The FDA regulates Software as a Medical Device (SaMD): software intended to diagnose, treat, cure, mitigate, or prevent disease. The dividing line is intended use, expressed through your claims. "Track your resting heart rate" is a general-wellness feature outside FDA jurisdiction; "detect atrial fibrillation" is a diagnostic claim that pulls the product into device regulation. Once inside, the pathway depends on risk. 510(k) premarket notification clears a device by showing substantial equivalence to an existing legally marketed predicate. De Novo classification serves novel low-to-moderate-risk devices with no predicate. PMA (premarket approval) is the most stringent route, reserved for high-risk devices and demanding clinical evidence of safety and effectiveness.

Machine-learning devices raise a problem fixed pathways were not built for: the model changes after clearance. The FDA's answer is the Predetermined Change Control Plan (PCCP), which lets a manufacturer specify in advance the modifications a model may undergo (retraining on new sites, threshold updates) and the validation protocol each must pass, so a routine update does not require a fresh submission. A PCCP is only credible if you already run the fleet discipline of Chapter 69: versioned data, reproducible retraining, and monitoring for the distribution shift of Chapter 66. Regulation here rewards the teams that already treat deployment as an engineered, evidenced process.

Engineering compliance triage into the pipeline

Regulatory classification fails the same way proportionality reviews fail: it happens once in a meeting and then drifts as the product changes. The fix is the same. Encode the triggering questions as data and evaluate them in code, so that adding an emotion output or an identity join forces the regulatory tier to be recomputed and logged. The function below is a first-pass triage: it does not replace counsel, but it turns "which regime are we in?" into a repeatable check that fires on every change to the declared use.

from dataclasses import dataclass

@dataclass(frozen=True)
class UseCase:
    infers_identity: bool     # recognizes a specific person
    infers_emotion: bool      # reads affective state
    context_workplace: bool   # deployed in work or education setting
    infers_health: bool       # produces a health/physiological inference
    diagnostic_claim: bool    # marketed to detect/treat a disease

def regulatory_triage(u: UseCase):
    flags = []
    # EU AI Act
    if u.infers_emotion and u.context_workplace:
        flags.append("AI_ACT: PROHIBITED (Art. 5 emotion recognition at work)")
    elif u.infers_identity or u.infers_emotion:
        flags.append("AI_ACT: HIGH-RISK (Annex III biometrics/emotion)")
    # GDPR special category
    if u.infers_identity:
        flags.append("GDPR: Art. 9 biometric-for-identification + Art. 35 DPIA")
    if u.infers_health:
        flags.append("GDPR: Art. 9 health data (special category)")
    # FDA / medical device
    if u.diagnostic_claim:
        flags.append("FDA: SaMD -> clearance pathway (510k / De Novo / PMA)")
    elif u.infers_health:
        flags.append("FDA: wellness boundary -> avoid disease claims to stay exempt")
    return flags or ["No special regime triggered (minimal-risk)"]

manager_stress = UseCase(infers_identity=True, infers_emotion=True,
                         context_workplace=True, infers_health=True,
                         diagnostic_claim=False)
for f in regulatory_triage(manager_stress):
    print(f)

Code 70.6.1 makes the point of this section executable: the regime is a function of the inference and the context. Flip infers_emotion and context_workplace to False and the prohibited-practice flag disappears; add diagnostic_claim=True and an FDA pathway appears. The tool is deliberately conservative and never downgrades a risk, because in triage a false alarm costs a lawyer's hour while a missed trigger costs a recall.

What's Next

In Section 70.7, we turn the regulatory obligations of this section into the artifacts that prove them: the documentation and accountability trail (model cards, decision logs, audit records, and clear ownership) that lets a team demonstrate, after the fact and to a skeptical outsider, that a sensory AI system did what it claimed and only what it was allowed to.