§1 — General description (Annex IV §1)
Intended purpose: Assist recruiters and hiring managers in candidate screening and assessment workflows. Provides candidate ranking signals based on submitted application materials (CV/resume, screening responses, optional video or voice interview transcripts) measured against a customer-defined competency framework. Enterprise tier: unlimited candidates, dedicated infrastructure, per-tenant SLA, on-prem deployment option.
Deployment context: Employment and recruitment within EEA, UK, and Turkey. Deployed by hiring teams of customer organisations (employers and recruitment agencies). The system supplements, but does not replace, human judgement for any rejection or selection decision.
Affected persons: Job candidates submitting applications through customer recruitment platforms. Affected persons are entitled to: (i) be informed an AI system processes their application, (ii) human review of any consequential decision, (iii) reasons for any adverse outcome derived from the AI signal, (iv) right to request reassessment by a human reviewer alone.
Prohibited uses:
- Final hiring or rejection decision without human review (Article 14 oversight mandatory)
- Use as sole basis for adverse employment action
- Profiling based on protected characteristics (race, religion, gender, age, disability, etc.)
- Mass screening without per-candidate human reviewer designation
- Cross-jurisdictional use without local recruitment law review (UK Equality Act 2010, EU GDPR Article 22, TR İş Kanunu)
§2 — Detailed description: data + model + dev process (Annex IV §2)
Model provider: Anthropic (Claude family) for text reasoning; Deepgram (Nova-3) for speech-to-text on voice products; OpenAI for embeddings fallback. All model providers configured with zero-data-retention enabled.
Model family: Foundation models with structured prompt scaffolding. No SBH-trained model weights. Custom prompt templates + retrieval-augmented context.
Training data: SBH does NOT train models. We rely on Anthropic/Deepgram/OpenAI base models trained by those providers per their documented training data policies. SBH-side context comes from customer-provided competency frameworks, anonymised internal benchmarks, and public regulatory guidance (UK Equality Act, EU GDPR Article 22, OECD recruitment AI principles).
Validation data: Pre-deployment validation: SBH internal test suite of 200 anonymised candidate profiles spanning EN/TR/DE locales, balanced across demographic axes. Acceptance criteria documented in /opt/sbh-hq/COMPLIANCE/HUMAN-OVERSIGHT/humanbaseiq-*.md.
Test data: Per-customer validation: each customer onboarding includes a calibration phase where 50-100 historical applications (anonymised by customer) are scored by the system and compared against historical human reviewer outcomes. Calibration deviation thresholds documented per tenant.
Development process: SBH-internal development follows Constitution v10 + working-style P1-P16 (see ~/sbh-mind/claude-md/). All prompt templates versioned in git, peer-reviewed before deployment. Per-tenant prompt overrides require operator approval. AuditLog (entityType=AI_DECISION) records every model call.
§3 — Monitoring, functioning, control (Annex IV §3, Article 14)
Human oversight measures:
- Article 14 §2(a): system limitations documented in this card and visible to operator before deployment
- Article 14 §2(b): automation bias awareness training delivered to customer hiring leads at onboarding
- Article 14 §2(c): every AI output presented to a human reviewer with confidence score and rationale snippet
- Article 14 §2(d): one-click override button on every candidate decision; override reason captured in AuditLog
- Article 14 §2(e): per-tenant "stop" button to disable the system globally; takes effect within 60 seconds
Override mechanism: Customer admin can override any AI signal via the portal candidate detail view. Override is logged in AuditLog with reviewer email, timestamp, prior AI suggestion, new decision, and reviewer-supplied reason. Override frequency is reported to customer monthly.
Logging: Hash-chained AuditLog (SHA-256, immutable). Every AI decision recorded with: tenantId, candidateId, inputs hash, AI output, confidence, reviewer email, final decision, override reason. Retention indefinite.
§4 — Performance metrics (Annex IV §4)
| Metric | Target / current | Measurement method |
|---|---|---|
| Demographic parity (DP) ratio per protected class | target ≥ 0.80 | Customer-supplied calibration set + monthly recompute |
| Equal opportunity (EO) difference | target |EO| ≤ 0.10 | Calibration set with ground-truth outcomes |
| Reviewer override rate | tracked; threshold > 30% triggers prompt review | AuditLog aggregation monthly |
| False positive rate (over-recommend hire) | measured per customer cohort | Compare AI score ≥ threshold vs. post-hire 90-day retention |
| Latency p99 | ≤ 30 seconds for screening, ≤ 90 seconds for voice analysis | Live latency monitoring + SLA reporting |
Accuracy + robustness: Quarterly re-validation against per-customer calibration set. Drift threshold: > 10% deviation triggers operator review + customer notification. Robustness tested against adversarial inputs (CV with intentional spelling variations, multi-language candidates, atypical career paths). Outputs reviewed for spurious correlation with protected characteristics.
Cybersecurity: Tenant-isolated storage (Frankfurt, Hostinger DC). All data encrypted at rest (AES-256-GCM). Customer PII (notes, metadata) encrypted with Prisma $use middleware (transparent). API access requires tenant-scoped JWT. Rate-limited per tenant. Hash-chain AuditLog tamper-evident.
§5 — Risk management (Annex IV §5, Article 9)
Demographic disparate impact (protected class members systematically lower-scored)
Mitigation: Monthly DP/EO measurement, calibration set rebalancing, prompt template revision if threshold breached
Residual risk: Cannot guarantee zero bias in foundation models; relies on customer-side calibration + reviewer judgement
Prompt injection via candidate-submitted content (CV with instructions to bypass)
Mitigation: Input sanitisation + structured prompt scaffolding + Constitution v10 §0..§21 enforced
Residual risk: Novel prompt injection techniques may bypass guards; AuditLog allows post-hoc detection
Model API outage causing recruitment pipeline disruption
Mitigation: Multi-provider fallback (Anthropic → OpenAI), customer notified within 5 minutes, manual reviewer override path always available
Residual risk: Provider concurrent outage rare but possible; manual fallback adds latency
False confidence — AI output presented as authoritative when uncertain
Mitigation: Confidence score displayed alongside every output; low-confidence outputs flagged with explicit "Reviewer required" tag
Residual risk: Reviewer may still over-rely on AI; offset by mandated reviewer training
Adverse interpretation of voice or video signals (accent, disability, mood)
Mitigation: Voice/video products exclude analysis of vocal traits beyond content; reviewer-only review of any non-textual signal
Residual risk: Some products may infer signal from delivery; per-tenant configuration controls scope
Risk acceptance: Residual high-severity risks acceptable only when (a) reviewer training documented, (b) override mechanism verified per quarter, (c) calibration set DP/EO within threshold. Customer signs DPA acknowledging these conditions before activation.
§6 — Lifecycle changes (Annex IV §6)
Version history:
- v1.0 · 2026-06-05 · Initial model card publication (response to ARIA Cybersec Brief)
Change control: Material changes to prompt templates, model providers, or feature scope require: (i) operator approval, (ii) re-validation against customer calibration set, (iii) customer notification 14 days before deployment, (iv) re-publication of this model card. Version bump tracked in git.
§7 — Harmonised standards (Annex IV §7)
- ISO/IEC 23894:2023 — AI risk management
- ISO/IEC 42001:2023 — AI management systems
- ENISA AI Cybersecurity Recommendations (2023)
- OECD AI Principles + recommendations
- UK Equality Act 2010 (anti-discrimination in employment)
- EU GDPR Article 22 (automated decision-making)
§8 — Declaration of conformity (Annex IV §8, Article 47)
Conformity assessment route: Annex VI (internal control) intended; under review pending notified body availability for Annex III §4 systems.
A formal EU Declaration of Conformity will be issued by SummitBridge Horizon Ltd (Companies House 16419201) at point of placement on EU market. Conformity assessment will reference this model card.
§9 — Post-market monitoring (Annex IV §9, Article 72)
Plan: Monthly: aggregate override rate, DP/EO measurement, customer feedback channel review. Quarterly: full validation against per-customer calibration. Annually: this model card refresh + harmonised standards review. Incident reporting to operator within 24h of detection; serious incidents to AI Office within 15 days per Article 73.
Incident reporting: Per Article 73: serious incidents reported to AI Office within 15 days of awareness. Operator notifies all affected customers within 24h. Public disclosure on /status if customer-facing impact.
Article 13 — Transparency to affected persons
Transparency statement: Article 13 disclosure: end users (job candidates) are informed at the point of application that an AI system is used in screening. The disclosure is delivered by the customer (recruiter) and includes the right to request human review of any consequential decision.
Consent: Customer is responsible for obtaining candidate consent under their applicable jurisdiction (GDPR Article 6/22, KVKK Article 10/11, UK GDPR). SBH provides consent template language but does not collect candidate consent directly.
Last reviewed: 2026-06-05
Next review due: 2026-09-05 (quarterly)
Owner: SBH Director (UK) — operator of SummitBridge Horizon Ltd
SummitBridge Horizon Ltd · Companies House 16419201 · ICO ZC112810 · 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ
Questions about this model card: [email protected]