Industries/HR Tech & Recruiting/AI resume screening
AI resume screening
AI resume screening is squarely high-risk under EU AI Act Annex III §4 + GDPR Art. 22, and US EEOC + NYC Local Law 144 (AEDT) demand annual bias audits. Promethean records every screening decision as an L12 entry with the model identity + spec hash + reviewer verdict — the empirical evidence underneath disparate-impact analyses + Art. 22 challenges.
What this is
AI resume screening classifies submitted resumes against a job opening's profile, producing a fit-score + recommendation (advance / hold / reject). The substrate-relevant decision unit is the per-candidate verdict; volumes at HR-tech SMB scale run 1k–500k decisions per month per employer customer.
The regulatory perimeter is the densest in tech-HR: EU AI Act Annex III §4 makes employment AI high-risk (Articles 9-15 obligations); GDPR Art. 22 covers solely-automated hiring decisions; post-Schufa CJEU C-634/21, scoring-style processing that materially influences a downstream hiring decision is itself within Art. 22. In the US: EEOC's 2023 technical assistance on AI hiring; NYC Local Law 144 (AEDT) requires annual bias audits; multiple state laws (IL, NJ, MD) require candidate notice + consent.
Promethean records each screening decision as an L12 entry: spec hash (which rubric version), input hash (which resume), output canonical hash (the score + recommendation), model identity (provider/model/version), reviewer verdict where always-human gate fires on reject decisions. The chain export is the empirical data for any bias audit, disparate-impact analysis, or Art. 22 challenge.
Regulatory pressure specific to AI resume screening
EU AI Act Annex III §4 — employment + workers management
AI for recruitment, candidate filtering, evaluation, promotion/termination, task allocation, behaviour monitoring is high-risk. Articles 9–15 apply: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy.
Official source ↗GDPR Art. 22 — solely-automated decisions
Hiring decisions produce legal effects or similarly significant effects. Solely-automated decisions are prohibited unless an exception applies, and even then 'meaningful human intervention' is required (Recital 71 + EDPB Guidelines WP251). Schufa (CJEU C-634/21, 2023) further confirmed that an automated score is itself an Art. 22 decision when the downstream actor draws strongly on it — rubber-stamp human review on top doesn't cure the issue.
Official source ↗NYC Local Law 144 (AEDT) — annual bias audit
Employers using Automated Employment Decision Tools in NYC must conduct annual bias audits using protected-class data + provide notice to candidates. Audit results must be publicly published.
Official source ↗EEOC Technical Assistance on AI in Hiring (May 2023)
Employers using AI in selection procedures remain responsible for disparate-impact compliance under Title VII. Vendor's claim of validation does not shift employer liability.
Official source ↗How Promethean addresses this
Per-decision audit evidence for bias audits + Art. 22 challenges
Each L12 entry has specHash + modelIdentity + reviewerVerdict + recordedAtIso. Filter the chain export by tenantId (= employer) + time window; pair with the employer's separately-held demographic table (held separately for proportionality compliance) to compute adverse-impact ratios.
Meaningful human review on reject decisions (Art. 22 + Schufa)
Spec configured with reviewer-gate = always-human on reject. The L12 entry records the reviewer identifier + verdict (approved / rejected / amended). Override rate computable from the chain — the empirical proxy for 'is the human exercising meaningful authority'.
Rubric stability over time (AI Act Art. 12 + Annex IV)
Each rubric / spec version produces a unique specHash. Silent changes are detectable. The chain's specHash sequence is the structured evidence for the Annex IV technical documentation 'changes to the system over time' section.
NYC Local Law 144 annual bias-audit data
Time-bounded chain export filtered by tenantId (employer) gives the bias-audit firm the per-decision metadata: which candidates were screened, what verdict, what model. Joined with the employer's demographic table, the 4/5ths-rule statistics are computable.
Multi-employer-customer tenant isolation
R4 multi-tenancy: each L12 entry carries tenantId = employer-id. Each employer customer can be issued a per-tenant audit bundle for their own bias audits without seeing other employers' data.
What this looks like in practice
Hypothetical: GDPR Art. 22 complaint against a resume-screening SMB
A candidate files a GDPR Art. 22 complaint with their national DPA against an HR-tech SMB's resume-screening product: 'I was rejected by an AI without meaningful human review.' The DPA asks: 'Was the decision solely automated? What was the override rate across the candidate cohort? Demonstrate that human review was meaningful.' Without Promethean: weeks of log archaeology, no clean way to demonstrate override rate, defensive engagement. With Promethean: chain export filtered to the affected hiring period; reviewer-verdict distribution across 12,000 similar decisions shows an 18% override rate — material human intervention. Reviewer verdicts per decision are signed + chained — the DPA verifies independently with verify.mjs. The complaint is resolved on the merits in two weeks rather than six months; the DPA's findings are corrective rather than enforcement.
Frequently asked
We have an in-house bias-audit firm, not a vendor. Does Promethean still help?
Yes — Promethean provides the substrate the bias audit runs on, regardless of who runs the audit. The chain export gives the per-decision metadata (specId, modelIdentity, schemaValid, reviewerVerdict, recordedAtIso); the bias audit (in-house or third party) joins this with the demographic data held separately + computes disparate-impact metrics. Promethean is sectoral-evidence-neutral on the audit side; what changes is that your evidence is verifiable rather than reconstructed.
Candidate data is PII. Does any of it land on Promethean infrastructure?
No. Raw CV content, names, demographic data never enter the L12 chain — only SHA-256 hashes of inputs + outputs. GDPR Art. 5(1)(c) data minimisation is satisfied by construction. The employer (your customer) retains the source data per their own retention policy; Promethean holds the audit trail. This is materially different from competitors that proxy LLM calls and necessarily see the candidate data.
How does this work with our existing ATS (Greenhouse, Lever, etc.)?
Promethean integrates at the AI-call layer in your service, not at the ATS. When your resume-screening service receives a candidate from the ATS and runs the AI model, Promethean records that decision into the L12 chain. The ATS sees the verdict via your existing integration; nothing changes for it. The audit-trail layer is invisible to the ATS, visible to regulators when needed.
NYC Local Law 144 requires the bias audit to be by an independent auditor. Where does Promethean fit?
The audit firm is independent; Promethean is not the auditor. What Promethean provides is the empirical substrate the auditor inspects. Currently, AEDT bias audits often rely on internal logs + reconstructed datasets — the audit firm has to trust the operator's data hygiene. With Promethean's chain, the auditor verifies the data themselves with verify.mjs before running the disparate-impact statistics. The independence is stronger because the audit-trail layer isn't operator-editable.