A mid-size SaaS company's ATS quietly stopped surfacing a specific kind of candidate to recruiters: anyone with an 18-to-24-month gap in their work history. Nobody configured that rule. The model had been trained on a decade of the company's own hiring outcomes, and in that decade, candidates with gaps, mostly people who had taken parental leave, cared for a family member, or been laid off in a downturn, were hired less often. The model didn't learn "avoid caregivers." It learned a correlation and applied it at scale, silently, to every resume that came in after. Nobody noticed until a rejected candidate asked, in writing, what criteria the tool had used to screen her out. As of August 2026, that question isn't just awkward. It's a compliance obligation with a legal deadline attached.
How does AI resume screening actually work under the hood?
Modern screening tools don't match keywords, they match meaning. Older ATS filters did literal token matching, so a resume that said "software engineer" could get passed over for a role listed as "software developer" purely on wording. Transformer-based models like BERT changed that by generating embeddings, numerical vectors that encode a phrase's semantic meaning rather than its exact wording, so the model represents "built scalable data pipelines" and "Python development" as sitting close together in vector space even though they share no words.
The scoring step is the same mechanism that powers RAG retrieval: the job description gets embedded, every resume gets embedded, and the system computes cosine similarity between them and aggregates the results into a weighted overall score. That's a meaningful accuracy improvement over keyword ATS. It is also exactly where an unaudited model quietly encodes whatever pattern sat in its training data, because cosine similarity has no concept of which correlations are legitimate signal and which are proxy discrimination.
Where does the bias actually enter the pipeline?
Almost always through the training data, not the algorithm. A documented, widely-cited example: a major technology company trained a resume-screening model on a decade of its own hiring data, and the system learned to systematically downrank resumes containing the word "women's" (as in "women's chess club captain"), because the company's historical hiring had favored men in technical roles. The model wasn't told to discriminate. It was told to predict who the company would hire, and it learned the company's own past bias as ground truth.
Employment-gap penalization is the same failure mode with a subtler trigger. Tools that flag a resume gap as a negative signal disproportionately catch women who took parental leave, caregivers, and candidates laid off during an economic downturn, not because the model was built to target those groups, but because a gap correlates with lower historical hire rates in the training set, and the model has no mechanism to distinguish a legitimate reason for a gap from an illegitimate one unless someone explicitly builds that distinction in.
What does the EU AI Act actually require for hiring AI now?
It classifies almost any hiring-adjacent AI as high-risk, not a narrow subset. Annex III of the EU AI Act designates AI systems intended for recruitment or selection, including placing targeted job ads, filtering applications, and evaluating candidates, as high-risk, which sweeps in resume screening, candidate ranking, AI interview agents, and even promotion and task-allocation tools once they touch a person's career outcome.
The deadline already passed for most obligations: high-risk systems had to reach conformity, complete technical documentation, implement a risk-management system, and register by 2 August 2026. Penalties for violations reach up to €35 million or 7% of global annual turnover, whichever is higher, and critically, the Act applies to any organization whose AI outputs affect people located in the EU, regardless of where the company is headquartered. A US or Indian company screening candidates for a Berlin-based role is in scope even without an EU office.
What does NYC's Local Law 144 require, and does it reach beyond New York?
It applies by candidate location, not company address. Local Law 144 requires an employer or employment agency using an automated employment decision tool for a NYC-based or NYC-associated role to have an independent bias audit conducted no more than one year before the tool is used, publish a summary of that audit publicly, and give candidates at least 10 business days' notice before the tool is used on them. Violations run $500 to $1,500 per day, and the auditor legally cannot be an employee of the vendor or the company, or hold any financial stake in either.
The audit itself has a specific, testable method: calculate the selection rate for each protected category, then divide the lowest-scoring group's rate by the highest-scoring group's rate to get an impact ratio, benchmarked against the EEOC's four-fifths rule. An impact ratio below 0.80 signals likely adverse impact, and under the law it still has to be published, not quietly fixed and hidden. A remote-first UK or Dubai-based company hiring one NYC-based engineer through the same screening tool it uses everywhere else is in scope for this exact requirement.
So what does an actually defensible hiring-AI architecture look like?
- **An independent bias audit before deployment and refreshed annually**, run by a party with no financial or employment relationship to the vendor or the employer, calculating selection rates and impact ratios by protected category.
- **Explainability logging on every scoring decision**, not just the final rank, so a rejected candidate's specific score and the features that drove it can be reconstructed and defended months later.
- **Candidate notice built into the pipeline**, not bolted on as a legal afterthought, since Local Law 144's 10-business-day window has to be operational, not just written into a policy document.
- **Human-in-the-loop review on the reject path, not just the shortlist**, because most audit failures surface in who a tool silently filters out before a human ever sees them, and structured escalation for consequential automated decisions is exactly the pattern regulators are asking for across every jurisdiction tightening AI oversight in 2026.
- **A maintained technical file**, mapped to whichever high-risk framework applies, EU AI Act Annex III documentation, ISO/IEC 42001, or both, so a conformity claim can survive an actual audit instead of existing only in a vendor's marketing page.
How AIBOOTSTRAPPER helps
This is the same architectural discipline we've already shipped for a client where the entire product is the audit trail. ComplySpark, the compliance document copilot we built for ComplyNexus, bakes human-in-the-loop review and version control into the pipeline itself rather than adding it after the fact, which is exactly why it ships with zero off-policy language slip-ups and a single traceable source of truth. A hiring-AI pipeline that needs to survive an NYC bias audit or an EU AI Act conformity check needs the identical property: every decision traceable back to what the model saw and why it scored the way it did.
If you're deploying, or already running, an AI tool anywhere in your hiring funnel and aren't certain it would survive an audit request today, talk to us about a compliance-aware AI readiness review, or see how we design agent architecture with this kind of oversight built in at our AI consultancy services.
Want this done for you?
Book a free strategy call and we'll show you how to build and market your business with AI.
Sources and further reading
- 1.EU Artificial Intelligence Act — Annex III: High-Risk AI Systems
- 2.NYC Department of Consumer and Worker Protection — Automated Employment Decision Tools
- 3.Airbyte — AI Resume Screening: How It Works, Risks, and Compliance
- 4.MDPI Electronics — Resume2Vec: Intelligent Resume Embeddings for Candidate Matching
