This guide defines precisely what a vendor should supply when responding to an audit or tender for an AI recruitment assessment platform. It is written for procurement leads, legal counsel, HR directors, and CHROs who need to evaluate vendor documentation quickly, defensibly, and across the full hiring workflow, from initial candidate intake through pre-screening, role matching, interview support, and final evaluation.
The documentation requirements described here reflect current regulatory frameworks: the EU AI Act (Article 11 and Annex IV), the NIST AI Risk Management Framework, ISO/IEC 42001:2023, and jurisdiction-specific rules such as New York City's Local Law 144. Where a vendor cannot produce documentation against these standards, that gap is itself a risk signal.
Before reviewing individual documents, ask the vendor to supply a one-page audit response index. This single table maps each buyer question to a specific downloadable artifact, a document version number, and a date. Without it, procurement teams spend hours locating evidence that may or may not exist.
A well-structured audit package uses a folder hierarchy similar to this:
/00-ExecutiveSummary
/01-SystemDocumentation
/02-DataGovernance
/03-BiasAuditReports_vX.Y
/04-ModelCards_vX.Y
/05-RemediationAndMonitoring
/06-PrivacySecurity
/07-IntegrationAndAPIs
/08-ChangeLogAndNextAudit
Each folder contains versioned artifacts. Auditors can then map a question about, say, disparate impact testing to /03-BiasAuditReports_v2.1/methodology.pdf without chasing the vendor for clarification.
The vendor's executive summary (folder /00) should also define where AI is actually active in the workflow. A platform like Selection Lab covers a multi-stage selection flow: conversational SmartChat intake, psychometric and game-based assessments, role-match scoring, and structured interview question generation. Each stage has a different risk profile, different data inputs, and different fairness exposure. The executive summary must state which stages are AI-driven, which are human-controlled, and where the handoff occurs.
The bias audit section is where most vendor documentation packages are weakest. A checklist of compliance topics is not a bias audit. What buyers need is a downloadable audit methodology document that answers these questions specifically:
Who conducted the audit? An independent audit is preferable. If the audit was conducted internally, the vendor must provide a signed attestation from a named data scientist or ethics officer and describe the review controls applied.
What method was used? The standard approach for employment decisions is disparate impact analysis using the four-fifths (80%) rule, comparing selection rates between a reference group and each protected group. Vendors should state explicitly whether they used selection-rate-based testing, predictive parity, equalized odds, or a combination. Each choice has different implications for which group bears the cost of model error.
What data was tested? The dataset summary should cover:
The "not tested" disclosure matters as much as what was tested. A vendor that tested only the scoring model but not the conversational intake stage (SmartChat) or the role-match algorithm has an incomplete audit. Buyers should request scope boundaries in writing.
Technical documentation artifacts (system architecture overview, data flow diagram, logging approach, and a version/change log) belong in /01-SystemDocumentation. These are required under the EU AI Act's Annex IV for high-risk AI systems and align with NIST's AI Risk Management Framework guidance on documenting testing results for repeatability and accountability.
This is the section most vendor documentation either omits entirely or presents in vague terms. Buyers should require a structured metrics table, not a summary statement.
For each protected group (gender, age group, ethnicity/national origin, disability status where applicable), the report should include:
These figures should appear in the downloadable bias audit report in /03-BiasAuditReports_vX.Y, not only in a sales slide or a summary email. An executive summary interpretation section within the same document should explain what the numbers mean for hiring decisions: for instance, whether a 0.78 disparate impact ratio at the pre-screening stage means that a specific demographic group is being rejected at a meaningfully higher rate before a human ever reviews their application.
NYC Local Law 144 sets a directly applicable precedent here: employers using automated employment decision tools must commission an annual, independent bias audit and publish the results publicly, with candidate notification at least ten days before the tool is used. Even organizations outside New York should treat LL 144 as a de facto minimum standard for what a published bias audit looks like.
A bias audit that has never triggered a remediation action is either a well-performing system or an audit that hasn't found anything yet. Buyers should ask explicitly: "What has changed in the model, data, or workflow as a result of your bias audits?"
The vendor's remediation documentation (in /05-RemediationAndMonitoring) should list:
Ongoing monitoring is a separate but related requirement. Post-deployment monitoring drift is a real risk: a model that passes bias testing on historical data can degrade in fairness as the applicant pool shifts, as job requirements change, or as economic conditions alter who applies. The vendor should define:
Governance documentation should include a RACI chart identifying who owns each control. ISO/IEC 42001:2023 requires exactly this kind of continual improvement structure within an AI management system.
Candidate notification procedures also belong here. Where regulation requires candidates to be informed that an automated tool is being used (as under NYC LL 144, or as good practice under GDPR Article 13/14), the vendor should document how that notice is delivered and stored.
Model cards are a structured transparency artifact that has become standard practice for operationalizing the documentation requirements of frameworks like the EU AI Act. Each AI component in the platform should have its own model card covering:
These belong in /04-ModelCards_vX.Y. When a model is updated, a new versioned model card replaces the previous one, and the old version is archived. Auditors can then confirm that the version of the model in production during any given period corresponds to a specific documented artifact.
The change log in /08-ChangeLogAndNextAudit should record every change event that could affect model behavior or fairness outcomes: model retrains, prompt updates (for conversational AI components), threshold changes, new assessment types added, and integration changes that alter data inputs. Each entry should note whether the change triggered an ad-hoc re-audit.
The next scheduled audit date must be stated explicitly. Annual audits are a minimum. Any of the following events should trigger an unscheduled re-audit: a significant change to the model or scoring logic, a change in the applicant population that materially alters subgroup representation, a regulatory update in an applicable jurisdiction, or a candidate complaint that implies systematic scoring error.
Procurement and legal teams often include questions in RFP documents that require non-technical answers. Vendors should provide a Q&A document in /00-ExecutiveSummary that covers the following:
Why are bias audits performed? AI models trained on historical hiring data can reproduce past patterns of under-selection for certain demographic groups. Bias audits test whether the model's outputs disadvantage any protected group at a statistically meaningful level, and document what was done when they do.
What does "disparate impact" mean in practice? If the platform selects candidates from one demographic group at a rate less than four-fifths (80%) of the rate for the highest-selected group, that is a disparate impact finding requiring investigation. It does not automatically mean the tool is discriminatory, but it does require documented review and a response.
Where is personal data stored? The vendor must name the data residency location and the legal basis for any cross-border transfer. Selection Lab, for example, stores personal data in Frankfurt, operates under GDPR, and uses local LLMs to strip personal information from conversational transcripts before processing.
What are the retention and consent terms? The vendor should provide a data retention schedule, a description of the candidate consent flow, and evidence of how consent is recorded and revoked. Data processing agreements with sub-processors should be available on request.
Is the audit independent? "Independent" means conducted by an organization with no financial interest in the outcome. Where the audit is internal, the vendor should describe the separation of duties between the team that built the model and the team that evaluated it.
What happens during an incident? The vendor should provide an incident response procedure covering detection, classification, notification timelines, and remediation steps. This belongs in /06-PrivacySecurity.
Can data be exported? ATS integration documentation and data portability specifications belong in /07-IntegrationAndAPIs. Buyers should confirm that candidate data, assessment results, and audit logs can be exported in a standard format if the contract ends.
Where does human oversight occur? The vendor must define which decisions are made solely by the AI system and which require human review before action is taken. For a platform that spans conversational intake, scoring, match-per-role ranking, and interview question generation, the handoff points between automated and human judgment must be documented at each stage.
The following documents constitute a complete audit-ready documentation package. Each item should be available for download, version-labeled, and dated:
[ ] Vendor Audit Response Summary (index page mapping questions to documents)
[ ] System architecture overview and data flow diagram
[ ] Bias audit report (methodology, dataset summary, subgroup metrics, remediation actions, executive interpretation)
[ ] Model card(s) per AI component (version-matched to current deployment)
[ ] Performance metrics by protected group (selection rates, DI ratios, FP/FN rates, sample sizes)
[ ] Remediation log (issues found, actions taken, re-audit results)
[ ] Monitoring plan (KPIs, frequency, drift thresholds, escalation path, RACI)
[ ] Version and change log with next audit date
[ ] GDPR compliance documentation (data residency, retention schedule, DPA with sub-processors)
[ ] Candidate consent flow documentation
[ ] Incident response procedure
[ ] ATS integration spec and data portability documentation
[ ] Non-technical Q&A (plain-language responses to standard tender questions)
A vendor that produces all of these artifacts in a structured, versioned folder is demonstrating operational maturity. One that responds with a compliance badge and a one-page overview is signaling that the audit infrastructure does not yet exist.
The regulatory pressure to maintain this documentation is only increasing. The EU AI Act's Article 11 and Annex IV requirements for high-risk AI systems, NIST's AI RMF guidance on quantitative fairness indicators, and ISO/IEC 42001:2023's lifecycle governance controls all point toward the same expectation: documented, repeatable, independently verifiable evidence that the system behaves fairly and that someone is accountable when it doesn't.
When evaluating vendors, request this package before any product demonstration. If the documentation exists and is well-organized, it reflects how the vendor operates. If it has to be assembled from scratch in response to your request, that tells you something equally important.
.png)
This guide defines precisely what a vendor should supply when responding to an audit or tender for an AI recruitment assessment platform. It is written for procurement leads, legal counsel, HR directors, and CHROs who need to evaluate vendor documentation quickly, defensibly, and across the full hiring workflow, from initial candidate intake through pre-screening, role matching, interview support, and final evaluation.
The documentation requirements described here reflect current regulatory frameworks: the EU AI Act (Article 11 and Annex IV), the NIST AI Risk Management Framework, ISO/IEC 42001:2023, and jurisdiction-specific rules such as New York City's Local Law 144. Where a vendor cannot produce documentation against these standards, that gap is itself a risk signal.
Before reviewing individual documents, ask the vendor to supply a one-page audit response index. This single table maps each buyer question to a specific downloadable artifact, a document version number, and a date. Without it, procurement teams spend hours locating evidence that may or may not exist.
A well-structured audit package uses a folder hierarchy similar to this:
/00-ExecutiveSummary
/01-SystemDocumentation
/02-DataGovernance
/03-BiasAuditReports_vX.Y
/04-ModelCards_vX.Y
/05-RemediationAndMonitoring
/06-PrivacySecurity
/07-IntegrationAndAPIs
/08-ChangeLogAndNextAudit
Each folder contains versioned artifacts. Auditors can then map a question about, say, disparate impact testing to /03-BiasAuditReports_v2.1/methodology.pdf without chasing the vendor for clarification.
The vendor's executive summary (folder /00) should also define where AI is actually active in the workflow. A platform like Selection Lab covers a multi-stage selection flow: conversational SmartChat intake, psychometric and game-based assessments, role-match scoring, and structured interview question generation. Each stage has a different risk profile, different data inputs, and different fairness exposure. The executive summary must state which stages are AI-driven, which are human-controlled, and where the handoff occurs.
The bias audit section is where most vendor documentation packages are weakest. A checklist of compliance topics is not a bias audit. What buyers need is a downloadable audit methodology document that answers these questions specifically:
Who conducted the audit? An independent audit is preferable. If the audit was conducted internally, the vendor must provide a signed attestation from a named data scientist or ethics officer and describe the review controls applied.
What method was used? The standard approach for employment decisions is disparate impact analysis using the four-fifths (80%) rule, comparing selection rates between a reference group and each protected group. Vendors should state explicitly whether they used selection-rate-based testing, predictive parity, equalized odds, or a combination. Each choice has different implications for which group bears the cost of model error.
What data was tested? The dataset summary should cover:
The "not tested" disclosure matters as much as what was tested. A vendor that tested only the scoring model but not the conversational intake stage (SmartChat) or the role-match algorithm has an incomplete audit. Buyers should request scope boundaries in writing.
Technical documentation artifacts (system architecture overview, data flow diagram, logging approach, and a version/change log) belong in /01-SystemDocumentation. These are required under the EU AI Act's Annex IV for high-risk AI systems and align with NIST's AI Risk Management Framework guidance on documenting testing results for repeatability and accountability.
This is the section most vendor documentation either omits entirely or presents in vague terms. Buyers should require a structured metrics table, not a summary statement.
For each protected group (gender, age group, ethnicity/national origin, disability status where applicable), the report should include:
These figures should appear in the downloadable bias audit report in /03-BiasAuditReports_vX.Y, not only in a sales slide or a summary email. An executive summary interpretation section within the same document should explain what the numbers mean for hiring decisions: for instance, whether a 0.78 disparate impact ratio at the pre-screening stage means that a specific demographic group is being rejected at a meaningfully higher rate before a human ever reviews their application.
NYC Local Law 144 sets a directly applicable precedent here: employers using automated employment decision tools must commission an annual, independent bias audit and publish the results publicly, with candidate notification at least ten days before the tool is used. Even organizations outside New York should treat LL 144 as a de facto minimum standard for what a published bias audit looks like.
A bias audit that has never triggered a remediation action is either a well-performing system or an audit that hasn't found anything yet. Buyers should ask explicitly: "What has changed in the model, data, or workflow as a result of your bias audits?"
The vendor's remediation documentation (in /05-RemediationAndMonitoring) should list:
Ongoing monitoring is a separate but related requirement. Post-deployment monitoring drift is a real risk: a model that passes bias testing on historical data can degrade in fairness as the applicant pool shifts, as job requirements change, or as economic conditions alter who applies. The vendor should define:
Governance documentation should include a RACI chart identifying who owns each control. ISO/IEC 42001:2023 requires exactly this kind of continual improvement structure within an AI management system.
Candidate notification procedures also belong here. Where regulation requires candidates to be informed that an automated tool is being used (as under NYC LL 144, or as good practice under GDPR Article 13/14), the vendor should document how that notice is delivered and stored.
Model cards are a structured transparency artifact that has become standard practice for operationalizing the documentation requirements of frameworks like the EU AI Act. Each AI component in the platform should have its own model card covering:
These belong in /04-ModelCards_vX.Y. When a model is updated, a new versioned model card replaces the previous one, and the old version is archived. Auditors can then confirm that the version of the model in production during any given period corresponds to a specific documented artifact.
The change log in /08-ChangeLogAndNextAudit should record every change event that could affect model behavior or fairness outcomes: model retrains, prompt updates (for conversational AI components), threshold changes, new assessment types added, and integration changes that alter data inputs. Each entry should note whether the change triggered an ad-hoc re-audit.
The next scheduled audit date must be stated explicitly. Annual audits are a minimum. Any of the following events should trigger an unscheduled re-audit: a significant change to the model or scoring logic, a change in the applicant population that materially alters subgroup representation, a regulatory update in an applicable jurisdiction, or a candidate complaint that implies systematic scoring error.
Procurement and legal teams often include questions in RFP documents that require non-technical answers. Vendors should provide a Q&A document in /00-ExecutiveSummary that covers the following:
Why are bias audits performed? AI models trained on historical hiring data can reproduce past patterns of under-selection for certain demographic groups. Bias audits test whether the model's outputs disadvantage any protected group at a statistically meaningful level, and document what was done when they do.
What does "disparate impact" mean in practice? If the platform selects candidates from one demographic group at a rate less than four-fifths (80%) of the rate for the highest-selected group, that is a disparate impact finding requiring investigation. It does not automatically mean the tool is discriminatory, but it does require documented review and a response.
Where is personal data stored? The vendor must name the data residency location and the legal basis for any cross-border transfer. Selection Lab, for example, stores personal data in Frankfurt, operates under GDPR, and uses local LLMs to strip personal information from conversational transcripts before processing.
What are the retention and consent terms? The vendor should provide a data retention schedule, a description of the candidate consent flow, and evidence of how consent is recorded and revoked. Data processing agreements with sub-processors should be available on request.
Is the audit independent? "Independent" means conducted by an organization with no financial interest in the outcome. Where the audit is internal, the vendor should describe the separation of duties between the team that built the model and the team that evaluated it.
What happens during an incident? The vendor should provide an incident response procedure covering detection, classification, notification timelines, and remediation steps. This belongs in /06-PrivacySecurity.
Can data be exported? ATS integration documentation and data portability specifications belong in /07-IntegrationAndAPIs. Buyers should confirm that candidate data, assessment results, and audit logs can be exported in a standard format if the contract ends.
Where does human oversight occur? The vendor must define which decisions are made solely by the AI system and which require human review before action is taken. For a platform that spans conversational intake, scoring, match-per-role ranking, and interview question generation, the handoff points between automated and human judgment must be documented at each stage.
The following documents constitute a complete audit-ready documentation package. Each item should be available for download, version-labeled, and dated:
[ ] Vendor Audit Response Summary (index page mapping questions to documents)
[ ] System architecture overview and data flow diagram
[ ] Bias audit report (methodology, dataset summary, subgroup metrics, remediation actions, executive interpretation)
[ ] Model card(s) per AI component (version-matched to current deployment)
[ ] Performance metrics by protected group (selection rates, DI ratios, FP/FN rates, sample sizes)
[ ] Remediation log (issues found, actions taken, re-audit results)
[ ] Monitoring plan (KPIs, frequency, drift thresholds, escalation path, RACI)
[ ] Version and change log with next audit date
[ ] GDPR compliance documentation (data residency, retention schedule, DPA with sub-processors)
[ ] Candidate consent flow documentation
[ ] Incident response procedure
[ ] ATS integration spec and data portability documentation
[ ] Non-technical Q&A (plain-language responses to standard tender questions)
A vendor that produces all of these artifacts in a structured, versioned folder is demonstrating operational maturity. One that responds with a compliance badge and a one-page overview is signaling that the audit infrastructure does not yet exist.
The regulatory pressure to maintain this documentation is only increasing. The EU AI Act's Article 11 and Annex IV requirements for high-risk AI systems, NIST's AI RMF guidance on quantitative fairness indicators, and ISO/IEC 42001:2023's lifecycle governance controls all point toward the same expectation: documented, repeatable, independently verifiable evidence that the system behaves fairly and that someone is accountable when it doesn't.
When evaluating vendors, request this package before any product demonstration. If the documentation exists and is well-organized, it reflects how the vendor operates. If it has to be assembled from scratch in response to your request, that tells you something equally important.
