How a 600-person SaaS built its AI hiring conformity file in 28 days

Context

A 600-person B2B SaaS company hiring across the US and EU. Two AI hiring tools in production: HireVue for early-stage interview scoring, Eightfold for candidate sourcing and matching. Headcount split was roughly 70/30 US vs. EU, with EU hires concentrated in engineering and product roles based in Berlin and Dublin.

The engagement was triggered by a board question: "Can we defend our use of AI in hiring under the EU AI Act?" The general counsel concluded that the answer was effectively no — the company had a NYC Local Law 144 bias audit from the prior year and a vendor security assessment for each tool, but nothing that mapped to Annex IV or Article 27.

What we found

Discovery surfaced a familiar pattern:

• The vendor materials were there, but not the deployer’s. HireVue had produced a model card, an internal bias-audit summary, and SOC 2 reports. Eightfold had produced similar artifacts. Neither vendor had produced anything that mapped to the deployer’s Article 26 obligations.
• The NYC LL 144 audit was usable but not sufficient. The audit computed selection rates and impact ratios for race and sex categories on the screening tool. It did not address the EU AI Act’s broader fundamental-rights framing, did not cover the sourcing tool, and was on a one-year refresh cadence rather than a continuous monitoring posture.
• Human oversight was informal. Hiring managers reviewed AI-scored candidates, but there was no documented criteria for when a hiring manager should override the system, and no logging of overrides.
• Logs existed but were vendor-controlled. HireVue retained interview-recording metadata for a defined period; Eightfold retained scoring records for a different period. Neither retention period was documented in the deployer’s records management policy.

What we built

Four weeks, four deliverable threads:

• Conformity file mapping each Annex IV section to the system artifacts that existed (cross-referenced to vendor materials) and to the gaps where the deployer needed to produce something new (about one-quarter of the file).
• Fundamental Rights Impact Assessment built on the Article 27 framework. The hardest part of the FRIA was the affected-persons analysis: candidates from EU member states, candidates with disabilities being assessed by video, and protected categories under national law.
• Risk management documentation (Article 9) enumerating the risks identified during discovery, the severity scoring, the mitigation measures already in place, and the gaps requiring remediation.
• Remediation roadmap for the gaps that could not be closed in writing: a documented oversight protocol with override logging, a retention schedule that captured both vendors’ data flows, and a vendor coordination plan for the next NYC LL 144 refresh.

Outcome

The conformity file, FRIA, and RMS documentation were delivered at the end of week four. The client’s general counsel signed off on the file two weeks later, after one round of revisions. The remediation roadmap became the basis for a six-month internal project owned by the Chief People Officer.

The work product subsequently appeared in two customer RFP responses, in both cases shortening the security-and-compliance review cycle.

What we’d do differently

The hardest part of the engagement was the vendor coordination. Both vendors were responsive but operated on multi-week SLAs for ad-hoc documentation requests. Were we engaging this client again, we would trigger the vendor coordination add-on at kickoff rather than at week two, and have the vendor materials in hand before drafting started.