Skip to main content
Category: Fairness & Bias

Sensitive Attributes

Also known as: Protected Attributes, Protected Characteristics, Sensitive Features
Simply put

Sensitive attributes are pieces of information about a person, such as race, sex, age, disability, or religion, that many organizations treat with special care because using them improperly can lead to unfair or discriminatory outcomes. In AI systems, these attributes are often the focus of efforts to check whether a model treats different groups of people differently. The specific attributes considered sensitive can vary depending on the law, the jurisdiction, and the context in which a system is used.

Formal definition

Sensitive attributes are variables in a dataset or model that identify individuals as members of groups warranting heightened scrutiny for fairness, bias, or non-discrimination purposes, either because they are legally protected or because their use raises ethical or reputational concerns. In fairness analysis they are commonly used as the grouping variable against which disparities in model outcomes or error rates are measured; note that removing a sensitive attribute from a model's inputs does not necessarily prevent disparate outcomes, because correlated proxy variables can encode the same information. The set of attributes treated as sensitive is not universal: it is defined by applicable anti-discrimination law, sector-specific rules, organizational policy, and use-case context, so practitioners should scope the relevant attributes explicitly rather than assume a fixed list. This entry describes the concept generally and does not enumerate the protected classes of any specific legal regime.

Why it matters

Sensitive attributes sit at the center of most efforts to assess whether an AI system treats different groups of people equitably. Because these attributes often map to legally protected classes or to characteristics that carry ethical and reputational weight, their handling can determine whether a model exposes an organization to discrimination claims, regulatory scrutiny, or public criticism. Getting the treatment of sensitive attributes wrong, either by using them inappropriately or by failing to measure disparities across the groups they define, can undermine both the fairness of outcomes and the defensibility of the system.

A common and consequential misconception is that omitting a sensitive attribute from a model's inputs makes the model neutral. In practice, other variables can act as proxies that encode the same information, so disparities can persist even when the attribute itself is excluded. This means that decisions about whether to collect, retain, or use sensitive attributes are not simple, and that fairness assessment often requires access to sensitive-attribute data even when that data is not used as a model input. Organizations frequently face tension between data-minimization or privacy expectations and the need for sensitive-attribute information to test for disparate outcomes.

Because the set of attributes treated as sensitive is not universal, teams that assume a fixed or borrowed list risk scoping their fairness analysis incorrectly for their jurisdiction, sector, or use case. Which attributes matter is shaped by applicable anti-discrimination law, sector-specific rules, organizational policy, and the context in which the system operates, so the same variable may warrant heightened scrutiny in one setting and not in another.

Who it's relevant to

Data Scientists and Model Developers
Developers need to understand that excluding a sensitive attribute from model inputs does not necessarily produce a fair model, because proxy variables can encode the same information. They are typically responsible for structuring fairness testing so that outcomes and error rates can be compared across the relevant groups, which often requires access to sensitive-attribute data for evaluation even when it is not used as a feature.
Model Risk and Fairness Assessment Teams
Those measuring bias or disparate outcomes rely on sensitive attributes as the grouping variable for their analysis. They should scope which attributes are relevant explicitly, informed by applicable law and use-case context, rather than assuming a universal list, and account for the possibility that disparities persist through correlated proxies.
Legal and Compliance Professionals
Because the attributes treated as sensitive are defined in part by applicable anti-discrimination law and sector-specific rules that vary by jurisdiction, legal and compliance staff are often needed to identify which characteristics warrant heightened scrutiny for a given system, and to reconcile the tension between using sensitive-attribute data for fairness testing and other legal or privacy expectations.
AI Governance and Policy Owners
Governance functions typically set organizational policy on whether and how sensitive attributes are collected, retained, and used, and establish the expectation that fairness scoping be documented per use case. This helps ensure that fairness assessment is not undermined by an incorrectly scoped or borrowed list of attributes.

Inside Sensitive Attributes

Protected or Legally Recognized Characteristics
Attributes such as race, ethnicity, sex or gender, age, disability, religion, and national origin that are often afforded legal protection under anti-discrimination regimes in many jurisdictions. The specific set of protected characteristics varies by jurisdiction and sector, so what counts as a sensitive attribute is not uniform across contexts.
Proxy Variables
Features that are not themselves sensitive attributes but that correlate strongly with them (for example, postal code correlating with race, or purchase history correlating with pregnancy status). Proxies can reintroduce sensitivity even when the direct attribute is excluded from a model, which is why identifying proxies is typically treated as part of managing sensitive attributes.
Special Category and Contextually Sensitive Data
Data whose sensitivity arises from context or from data-protection frameworks rather than solely from anti-discrimination law, such as health, biometric, genetic, or sexual-orientation information. Whether a given attribute is treated as sensitive can depend on the applicable data-protection regime and the use case.
Use in Fairness Assessment versus Use in Prediction
A distinction between collecting or retaining sensitive attributes to measure and monitor disparate outcomes and using those same attributes as inputs that directly drive predictions. These two uses carry different risk and, in some contexts, different legal treatment; the terms should not be conflated.

Common questions

Answers to the questions practitioners most commonly ask about Sensitive Attributes.

Does removing sensitive attributes from a model's inputs make the model fair or free of bias?
No. Excluding sensitive attributes such as race, sex, or age from the feature set does not, on its own, ensure fairness or eliminate bias. Other features can act as proxies that correlate with sensitive attributes, so a model can still produce disparate outcomes even when the attributes are not used directly. This is a common misconception often called 'fairness through unawareness.' In many frameworks, detecting and measuring proxy effects typically requires access to the sensitive attribute data for testing purposes, even if those attributes are not used as inputs. Note that bias (a systematic skew in data or outputs) and fairness (a normative judgment about acceptable outcomes) are distinct concepts, and neither is resolved simply by dropping columns.
Are sensitive attributes defined the same way across all regulations and jurisdictions?
No. What counts as a sensitive attribute varies by legal and sector context, and the terminology is not uniform. Data protection regimes, anti-discrimination law, and sector-specific rules (for example, fair lending contexts versus general enterprise settings) may enumerate different categories and impose different obligations. Some frameworks use terms such as 'special category data' or 'protected characteristics,' which are not necessarily coextensive with what a data scientist informally labels a sensitive attribute. Because definitions and regulatory treatment differ and continue to evolve, practitioners should scope the term to the specific jurisdiction and use case rather than assuming a single universal list.
If we are prohibited from using a sensitive attribute as a model input, can we still collect it for bias testing?
This depends on the applicable legal and regulatory regime, which can differ by jurisdiction and sector, so it should be confirmed with legal and compliance functions. In many contexts there is a recognized tension: measuring disparate outcomes across groups typically requires the group data, yet using or collecting that data may be restricted. Organizations often address this through controls such as separating attributes used for testing from those available to the model, restricting access, and documenting the lawful basis and purpose. Because treatment varies and is evolving, the specific permissibility of collection and use for testing cannot be stated as a universal rule.
Where should responsibility for handling sensitive attributes sit within an organization?
Responsibilities are commonly distributed across the lines of defense without collapsing their distinct roles. The first line (model developers and business owners) typically handles the operational decisions about whether and how attributes are collected and used, subject to policy. The second line (independent risk and compliance functions) typically sets policy, challenges those decisions, and reviews bias testing. Third-line functions such as internal audit typically provide independent assurance that controls operate as intended. This division is an AI governance matter, concerning accountability and oversight structures, and it interacts with, but is not the same as, the model risk management activities of measuring and controlling model risk.
What is the difference between validating a model's use of sensitive attributes and verifying that attribute-handling controls are implemented?
These are distinct activities that practitioners are careful not to blur. Verification typically asks whether the controls and specifications were built as designed, for example, confirming that a prohibited attribute is genuinely excluded from the input pipeline or that access restrictions are enforced. Validation typically asks whether the model and its handling of attributes are appropriate for the intended purpose, for example, assessing whether excluded attributes are effectively reintroduced through proxies or whether outcomes differ across groups. Verifying that a control exists does not establish that the underlying fairness or bias concern has been adequately addressed.
How should the treatment of sensitive attributes be documented in model risk artifacts?
Documentation commonly records which attributes were identified as sensitive in the relevant context, whether they were used as inputs, how proxies were assessed, what bias or disparity testing was performed, and the lawful basis and access controls governing the data. It is generally useful to distinguish assumptions and limitations, for example, noting that certain groups could not be measured due to data availability or legal constraints, and to state what is out of scope. Because definitions and requirements vary by jurisdiction and evolve over time, documentation should describe the framework relied upon rather than implying a single settled standard, and should present controls as measures that reduce or manage risk rather than eliminate it.

Common misconceptions

Removing sensitive attributes from a model's inputs makes the model unbiased or fairness-compliant.
Excluding a sensitive attribute does not remove its influence when correlated proxy variables remain, a pattern sometimes described as 'fairness through unawareness' having limited effectiveness. Disparate outcomes can persist without the attribute being an explicit input, so exclusion is not equivalent to eliminating bias or achieving fairness.
The list of sensitive attributes is fixed and universal across regulations and industries.
What qualifies as a sensitive attribute varies by jurisdiction, sector, and applicable framework. Attributes protected under anti-discrimination law may differ from those treated as special-category data under data-protection regimes, and sector-specific rules may add or narrow the set. Practitioners should scope the definition to their applicable context rather than assume a single authoritative list.
Collecting sensitive attributes is always prohibited, so organizations should never gather them.
In many contexts, collecting sensitive attributes may be permitted or even useful for measuring and monitoring disparities, while using them as direct predictive inputs may raise separate concerns. The permissibility depends on purpose, applicable law, and safeguards, so a blanket prohibition on collection can undermine the ability to detect unequal outcomes.

Best practices

Scope the definition of sensitive attributes to the specific jurisdictions, sectors, and frameworks that apply to your use case rather than relying on a single generic list.
Actively identify and assess proxy variables that correlate with sensitive attributes, since excluding the direct attribute alone typically does not remove its influence.
Distinguish clearly between retaining sensitive attributes for fairness measurement and monitoring versus using them as direct predictive inputs, and document the rationale and safeguards for each.
Confirm the legal basis and applicable data-protection or anti-discrimination requirements before collecting, storing, or processing sensitive attributes, using qualified assessment where the regulatory treatment is unsettled or context-dependent.
Establish ongoing monitoring for disparate outcomes rather than treating the removal of a sensitive attribute as a one-time compliance step.
Record the limitations of your approach, including which attributes were treated as sensitive, why, and any residual risk that governance controls reduce but do not eliminate.