Are protected classes the same everywhere?

No. Coverage varies with jurisdiction and the activity being regulated.

Must a protected class be a minority group?

No. Protection should not be inferred from numerical minority status; the applicable rule determines coverage.

Can one person belong to several relevant classes?

Yes. Intersecting characteristics can matter, and a review should consider whether broad categories conceal meaningful differences.

AI Glossary / Governance, ethics and safety / Intermediate

Protected class

Definition

A protected class is a category of people covered by particular protections against discrimination in a specified legal context. Membership is defined through a characteristic or condition recognized by the applicable law. In AI governance, the concept helps identify whose treatment and outcomes require attention, but the legal scope depends on the jurisdiction, activity, and protection involved.

What it means

A protected attribute is the characteristic used to describe a relevant dimension; a protected class refers to people within the legally relevant category. The terms should not be reduced to a software label. A database can contain a group field without correctly capturing the people protected by a rule, and people may qualify for several protections at once. Protection is also not limited to whichever group is numerically smaller in a dataset. The precise coverage must come from the applicable framework rather than assumptions about demographic size, disadvantage, or a model's available columns.

How it works

A responsible assessment begins by identifying the decision context and applicable protections. It then considers how people encounter the full process: access, data collection, model scoring, human review, and final outcomes. Analysts may compare groups using suitable metrics, but those comparisons are evidence for investigation rather than automatic legal verdicts. Records can omit or misclassify class membership, and broad group averages can conceal problems affecting intersecting categories. Technical fairness definitions may provide useful measurements, yet they do not replace interpretation of the governing rules or an assessment of the real treatment people receive.

Three practical examples

A hiring-tool review considers the people covered by applicable employment-discrimination protections when examining screening outcomes.
An accessibility review checks whether a service process excludes people with disabilities before an AI recommendation is even produced.
A team examining automated service decisions looks at intersections of relevant characteristics because a broad comparison can miss a problem affecting a smaller combination of groups. These examples show assessment scope, not legal conclusions about a particular organization.

Think of it this way

Think of a protected class as a category named in the rules governing a decision process. The rules specify whose protection is relevant; a spreadsheet then provides an imperfect way to examine what happened. The analogy is limited because legal coverage can involve more than a simple category label, and a person's experience cannot be fully summarized by one row or one group average. Human context remains important.

Worked example

Suppose an illustrative application process has four equally sized audit groups, each with 100 applicants. In Region 1, 80 applicants from Group A and 60 from Group B advance. In Region 2, 60 from A and 80 from B advance. Aggregating across regions gives 140 of 200 for each group, or 70%, apparently equal. Within each region, however, there is a 20-percentage-point difference in opposite directions. This example does not establish that A or B is a legally protected class or that any difference is unlawful; those facts must be specified separately. It demonstrates that even after identifying relevant classes, aggregate parity can hide process differences that deserve investigation. Region-specific practices, sample variation, and other explanations require evidence.

Illustrative case study

Fictional case: Summit Services evaluates an AI-assisted intake process using only organization-wide averages. Feedback from users prompts a review of individual locations and accessibility conditions. The team discovers that different local procedures produce different barriers and updates its assessment accordingly. This invented case illustrates why identifying protected classes is the beginning of an inquiry into treatment, not the end. A single fairness chart cannot establish whether the full process respects every applicable protection.

Common misconceptions and mistakes

Protected class does not mean a group is automatically entitled to every requested outcome. It means the relevant protection must be understood and respected. A class is not necessarily a statistical cluster learned by an algorithm, and a model cannot decide legal coverage simply by discovering similar records. The absence of a recorded membership field does not erase a person's protection. A disparity is not by itself a complete legal analysis, while equal average outcomes do not rule out all discriminatory treatment. Technical fairness and legal nondiscrimination overlap but have different purposes and requirements.

Business use

Establish the applicable context before commissioning a fairness audit. Ask legal and policy specialists to clarify relevant coverage and ask affected people about barriers that the available data may miss. Document how audit groups correspond to the intended protections, including missing or uncertain membership information. Use suitable privacy and access controls, and avoid unnecessary inference of sensitive characteristics. Report findings at an appropriate level of detail, balancing useful detection with small-group privacy and statistical uncertainty. Maintain correction and review routes for individuals rather than relying exclusively on group metrics.

Check your understanding

An organization finds equal overall selection rates for two relevant groups. Does that establish that every location and stage treats them equally?

Answer: No. Differences can be hidden by aggregation or arise in aspects not measured by selection rates. The assessment should examine relevant stages, contexts, and individual experiences.

Related terms

Protected attribute
Nondiscrimination
Disparate treatment
Disparate impact
Group fairness
intersectionality
accessibility
fairness assessment
aggregation bias

Learn next

For a hypothetical AI-assisted process, identify the jurisdiction and activity before naming relevant protections. Map each stage where people might be excluded or treated differently. Then determine which evidence can reveal those problems and which questions require legal interpretation.

Sources

U.S. EEOC, protected applicants and employees in its employment context: https://www.eeoc.gov/employers/small-business/3-who-protected-employment-discrimination U.S. EEOC, prohibited employment policies and practices: https://www.eeoc.gov/prohibited-employment-policiespractices Fairlearn, assessment of fairness harms: https://fairlearn.org/main/user_guide/assessment/perform_fairness_assessment.html

Previous: Protected attribute Next: Proto-agent