Candidate screening and AEDT-governed hiring

The trust layer for AI agents screening candidates and making hiring recommendations.

Autonomous hiring decisions are high-stakes and regulator-watched. NYC Local Law 144 treats every candidate-facing automated decision tool as an AEDT and requires an annual independent bias audit; the EU AI Act classifies recruitment automation as a high-risk system under Annex III §4 with mandatory human oversight under Article 14 and a deployer-side fundamental rights impact assessment under Article 27. The HR and recruitment sector pack governs the actions an agent may take across the candidate funnel, gates the rejection and hire decisions behind human approval, tokenises candidate PII so the agent can reason about the candidate without seeing raw identifiers, and signs every decision into an audit chain an external bias auditor can read against the operator's evidence pack.

Which frameworks the hr and recruitment pack maps to today.

Framework
Jurisdiction
Coverage
Notes
EU AI Act
vortalis_proxy/compliance/frameworks.py (build_eu_ai_act_sections)
tests/conformance/regulators/eu_ai_act/
EU
Full
Annex III §4 classifies recruitment automation as high-risk. Article 14 human oversight is wired to the require_human flow on candidate.rejected and candidate.hired. Article 27 fundamental rights impact assessment evidence sits in the FRIA section of the pack.
NYC Local Law 144
vortalis_proxy/compliance/us_states.py (build_nyc_ll144_sections)
tests/conformance/regulators/nyc_ll_144/
US-NY-NYC
Full
The bias-audit obligation (§ 20-871(a)) and candidate-notice obligations (§ 20-871(b)) are both reflected in the audit-trail shape. Bias-audit data itself is deployer-supplied; the pack captures the audit-trail evidence an independent bias auditor uses.
Colorado AI Act
vortalis_proxy/compliance/us_states.py (build_colorado_ai_act_sections)
US-CO
Full
SB 24-205 deployer impact assessment, algorithmic discrimination prevention, and consumer notification obligations. Demographic monitoring evidence is deployer-supplied; controls the platform cannot reach are surfaced as NOT_AVAILABLE_IN_PLATFORM honestly rather than NON_COMPLIANT silently. Colorado-specific conformance bindings track behind the NYC LL 144 ones; the platform-only honest framing is exercised by the existing tests under tests/conformance/regulators/colorado_ai_act/test_colorado_ai_act.py.
ASA Code (CAP and BCAP)
tests/conformance/regulators/asa_uk/
UK
Planned
Advertising standards apply to candidate-sourcing campaigns (job advertising, sponsored outreach). Binding is on the Phase 1 backlog; the policy template names candidate.communication_sent today and the regulator binding lands with the first sourcing-led engagement.
FTC Endorsement Guides
tests/conformance/regulators/ftc_us/
US (Federal)
Planned
Disclosure obligations on sponsored candidate-sourcing content. Same shape as the ASA binding; planned for Phase 1.

Upstream services Vortalis adapts for this vertical.

No Vortalis-side adapters ship for HR and recruitment. The calling system holds the ATS credentials (Greenhouse, Lever, Workday Recruiting, Ashby, or the tenant's bespoke ATS), the background-check provider credentials, and the email-provider tokens directly. Vortalis governs the action at the agent boundary; the operator's existing integrations carry the action through to the live ATS.

The policy template for this vertical.

Actions allowed

12

Each action gated by policy at the hot path.

Anticipated require_human actions

  • candidate.rejected
  • candidate.hired

Rate-limit posture

Two hundred scores per rolling 24-hour window on candidate.scored; one hundred outbound messages per 24-hour window on candidate.communication_sent; fifty rejections per 24-hour window on candidate.rejected. Defensible for a single-requisition engagement; raise after agreeing the volume with the tenant's recruiting lead.

Template path: policies/sectors/hr-recruitment/candidate-screening-template.yaml

The implementation guide your engineers read first.

Available

docs/governance/integration-briefs/hr-recruitment.md

What this sector pack does not do.

Vortalis does not perform the bias audit itself; it produces the audit-trail evidence that an independent bias auditor uses.

NYC Local Law 144 § 20-871(a) requires an independent bias audit conducted by an entity that has no role in developing, distributing, or deploying the AEDT. Vortalis is the governance layer that records every candidate-facing action into a tamper-evident chain; that chain is what the bias auditor reads, alongside the operator's demographic data and outcome data. The auditor's selection, scope, and findings remain the operator's responsibility, and the auditor's report is published on the operator's website per the bias-audit obligation, not on the Vortalis surface.

Counterparty certification with ATS providers, background-check vendors, and email providers is the operator's responsibility.

Per the public limitations page, Vortalis ships adapters as code, not as counterparty-certified production integrations. The HR and recruitment pack relies on the operator's existing ATS, background-check, and email-provider credentials; the conformance and data-processing terms of those upstream services are governed by the operator's contract with each one, not by Vortalis. The candidate's data-protection rights under GDPR Article 22 (where the candidate sits in scope) flow through the operator's controllership relationship with each upstream service.

Decisions on protected categories appear in the audit trail; the determination of which categories are protected is jurisdiction-specific and is the operator's responsibility to encode in policy.

The candidate-screening policy template marks candidate.date_of_birth and candidate.protected_characteristic as redacted at the policy boundary, so the agent does not see them on the scoring path. The set of categories that count as protected (race, sex, age, disability, religion, sexual orientation, gender reassignment, marital status, pregnancy and maternity, in UK Equality Act 2010 terms; equivalent under federal Title VII and state laws in the US; equivalent under EU non-discrimination directives) depends on the jurisdiction the candidate sits in. The operator encodes the right set into Tenant.config and the policy template's data_access.fields block; Vortalis enforces the policy as encoded. The annual bias audit reads the audit trail against demographic data the operator supplies separately.

candidate.rejected and candidate.hired always require human approval.

Both are listed in the policy template's anticipated Tenant.config['require_human_actions']. The require_human flow in Section 7 of the integration brief is mandatory before the engagement goes to production. A calling system that does not implement the four-part flow (persistent resumption state, approval discovery via polling, resume execution, post-hoc record) will appear functional during early testing and will fail silently the first time the agent reaches the funnel's end. The EU AI Act Article 14 human oversight requirement and the NYC LL 144 treatment of AEDTs as decision-support rather than decision-replacement both rest on this gate.

agent.action_blocked records client-side rejections; it does not enforce them.

The client-side rejection vocabulary lets the calling system tell Vortalis it refused an action the agent proposed. The audit chain logs that rejection so a bias auditor sees the complete decision history including the actions that never reached the upstream API (a candidate the agent considered scoring but skipped under a calibration band rule, a rejection the agent considered drafting but blocked under a fairness check). The enforcement itself sits in the calling system; Vortalis records the client-side decision, it does not duplicate it.

The general-purpose honest limits sit at /security/limitations; this list is specific to the hr and recruitment pack.

Bring Vortalis to your hr and recruitment agents.

Read the integration brief if you would rather start with the engineering detail. Talk to us first if you would rather start with a conversation about your threat model.