Most model teams that work in employment, credit, insurance, or housing can say, accurately, that their production features do not include race, ethnicity, sex, religion, national origin, disability status, or age as labeled fields. That statement is often true. It is also often insufficient. The question that matters in review is not whether the protected attribute appears by name. It is whether other variables in the feature set carry enough of the same information that the model can behave as if the attribute were present.
Those variables are proxies. They are ordinary features with legitimate business justifications that, under the conditions of the population and the market, correlate strongly enough with a protected class that a model can learn the association and use it. The correlation does not have to be intentional. It does not have to be the feature's primary purpose. It only has to be stable enough for the training process to exploit.
This distinction is where many otherwise careful teams lose the plot. They treat the absence of protected attributes as evidence that the model cannot discriminate along those lines. The absence removes one pathway. It does not remove the pathway through correlated inputs.
What counts as a proxy in practice
A feature is a proxy for a protected class when three conditions hold together. First, the feature is predictive of the outcome the model is trained to score. Second, the feature is correlated with membership in a protected class in the population the model serves. Third, removing or transforming the feature meaningfully changes how the model scores members of that class relative to others.
The third condition is the one teams skip. Correlation alone is not proof that the model is using the feature as a stand-in for class membership. Many variables correlate weakly with demographics and contribute little to the score. The audit-relevant question is whether the feature, once included, shifts predicted outcomes across groups in a way that is not explained by the legitimate business factor the feature was meant to capture.
That is a harder question than a correlation table. It requires held-out evaluation, controlled ablations, and an honest description of what the feature is supposed to measure. Teams that stop at "ZIP code correlates with race" have done the easy half of the work. Teams that show what happens to selection rates when ZIP is removed, binned differently, or replaced with a less geographic alternative have done the half that survives scrutiny.
Where proxies usually enter
In hiring and screening systems, proxies often arrive through education and geography. School name, graduation year ranges tied to typical age bands, commute distance from a headquarters, and home ZIP or city can each carry demographic signal in a given metro area. None of these fields is a protected attribute. Each can, in combination with others, reconstruct group membership more accurately than the model team expects.
In lending and insurance pricing, proxies often arrive through address history, device and channel metadata, time-of-day application patterns, and prior product relationships that track residential segregation or workforce composition. Again, each field can have a clean business rationale. The rationale does not erase the correlation.
Name-derived features deserve special care. Teams sometimes encode first-name rarity, linguistic origin hints, or string similarity to known name lists as soft signals for fraud, identity resolution, or "fit." Those encodings are especially hard to defend once challenged, because the legitimate business story is thin and the demographic association is often direct. If a name-derived feature cannot be justified without reference to identity patterns that track national origin or ethnicity, it should not be in the feature set.
The same caution applies to features built from free text: resume language, cover letters, chat transcripts, or customer notes. Embeddings and keyword scores do not list race or sex as columns. They can still encode dialect, culturally specific schooling language, gendered phrasing, and other markers that track protected classes. Treating text embeddings as demographically neutral because they are numeric is a category error.
Why "we excluded protected attributes" fails as a complete answer
Excluding protected attributes is still good practice. It reduces direct use of sensitive labels, reduces leakage through joins, and makes certain forms of intentional disparate treatment harder to implement by accident. The problem is the rhetorical leap from that exclusion to a claim that the model is fair, or that adverse impact analysis is unnecessary, or that feature review can stop once the protected columns are gone.
A model trained without protected attributes can still produce disparate outcomes if the remaining features encode group membership and the training objective rewards that encoding. Downstream decision rules can amplify the effect. A threshold applied to a score that embeds geographic segregation will often look neutral in the code and non-neutral in the population.
For documentation shared with counsel or a board committee, the useful framing is narrow. State which protected attributes were excluded. State which candidate features were reviewed for proxy risk. State how that review was done. State what was removed, transformed, or retained with a recorded justification. Do not claim that exclusion of protected attributes proves the absence of proxy effects. That claim is stronger than the evidence usually supports.
A workable review process
A feature review that takes proxy risk seriously does not require a research program. It requires a fixed checklist applied before a model version ships, and again when the population or the feature pipeline changes.
Start with an inventory of every feature that reaches the model, including engineered and embedding-derived features, not only the columns in the raw table. For each feature, record the business purpose in one sentence. If the purpose cannot be stated without circular reference to "it improves the score," the feature is not ready for production review.
Next, estimate association with available protected-class labels or carefully constructed proxies for those labels in a holdout population. Use methods appropriate to the data types: mutual information, standardized mean differences, or stratified rate comparisons. Flag features with strong association for deeper review. Do not automatically delete every correlated feature. Correlation without contribution to group score differences is less urgent than correlation with contribution.
Then run ablation or substitution tests on the flagged features. Compare group-level outcome metrics with the feature in, with the feature out, and with a transformed version that preserves the legitimate signal while reducing geographic or identity leakage where possible. Document the deltas. If the legitimate business purpose survives the transformation and the group gap shrinks, prefer the transformed version.
Finally, record retention decisions. A retained proxy-risk feature should have an explicit justification: what it measures, why alternatives are worse for the business purpose, what residual group association remains, and what monitoring will detect drift if the association strengthens. Features retained without that record are the ones that become difficult to defend later.
Limits worth stating plainly
Not every correlated feature is unlawful or inappropriate. Location can matter for delivery cost. Tenure can matter for attrition risk. Industry experience can matter for role fit. The work is to separate legitimate predictive content from content that mainly reconstructs class membership.
Nor is proxy removal a complete fairness program. A model can still produce disparate impact through legitimate features that differ in distribution across groups. Proxy review is one control among several: outcome measurement by group, threshold and rule review, data quality checks, and change control when features are added.
The teams that handle this well treat proxy risk as a feature-governance problem, not as a branding problem. They write down what entered the model, why it stayed, and what they measured when they worried about protected-class leakage. That record is more useful than a blanket assurance that protected attributes were never used. The assurance answers yesterday's question. The record answers the one reviewers actually ask.