Provider-Side Governance · Booklet II of II
How the compliance tooling itself is built, tested, monitored, and held accountable — the provider-side counterpart to your own deployer obligations.
CognitivFusion maintains a quality and risk-management program for its own platform that mirrors the structure the EU AI Act requires of a provider of high-risk AI — a quality management system, technical documentation, accuracy declarations, post-market monitoring, and serious-incident reporting.
This is not a claim of provider status under Article 25
Your organisation is the deployer of your own recruitment AI system. CognitivFusion is the provider of governance and audit tooling, not the provider of your high-risk hiring AI within the meaning of the Act — that positioning is deliberate and is set out in full in our standing legal-role documentation. This booklet describes voluntary provider-grade practice applied to the tooling itself, because the discipline is worth having regardless of which party the Act formally assigns it to. It does not transfer, and should not be read as accepting, Article 16 provider obligations for a system CognitivFusion does not operate.
Scope note: this booklet, and the disclaimer above, describe CognitivFusion's relationship to your own hiring AI when you are our direct customer and the deployer of that system. It does not describe CognitivFusion's role when embedded inside a third party's screening or sourcing product that is then resold to you or to others — that is a separate relationship (potentially Art 25(4) component supplier to that product's own provider), under active review, and not yet determined. If you are an HR-tech vendor evaluating CognitivFusion for your own product, ask your account contact for the current status of that determination before relying on this document.
Every request — a prompt, a résumé, a job description — passes through the same pipeline before a decision is returned.
53 semantic clusters of regex patterns, each mapped to a specific statute or standard. Fully reproducible: identical input always produces identical output, stamped with a version fingerprint on every decision.
A discrimination-focused judge (the only one permitted to soften a rules-layer decision) and a specialist judge covering employment law, AI-integrity, and process-integrity risks the rules alone can't classify. Both can only make a decision stricter on their own; softening requires a second, independent judge call that must reach the same conclusion before it takes effect.
Structured identifiers (national insurance numbers, cards, emails) are scrubbed by regex with checksum validation; unstructured personal data is scrubbed by a named-entity model. Nothing reaches an external AI provider, and nothing is written to the audit ledger, unscrubbed.
Every decision, its reasoning, and the version of the engine that made it are appended to a hash-chained record. Rows cannot be edited or deleted — only key-destroyed at the end of a retention window.
Risk management is treated as continuous, not a one-time assessment before launch.
| Channel | What it does | Cadence |
|---|---|---|
| Corpus review | HR-practitioner and legal review of every rule against its primary source | Per release |
| Bug-finder scripts | LLM-assisted generation of paraphrases and minimal pairs designed to find false positives and false negatives before a customer does | Periodic, plus every judge-prompt change |
| Cross-path parity check | Identical content run through every route into the platform (direct API, bulk upload, live-integration gateway, ATS webhook) — any two routes disagreeing on the same content is treated as a defect, not a quirk | Before any governance-behaviour change |
| Post-market sweep | Automated daily re-evaluation of a sample of recent decisions, watching for accuracy drift | Daily |
| Risk | Treatment |
|---|---|
| A clean document wrongly blocked | Narrow, evidence-based exemptions to the rules layer — never a blanket loosening — each with a permanent regression test |
| A real violation wrongly passed | Two independent detection layers must agree before anything passes; a single layer's miss doesn't reach the customer |
| An AI judge softening something it shouldn't | A fixed denylist of security-sensitive categories — prompt injection, fabricated references, unauthorised commitments — that no single AI opinion may ever soften, enforced identically everywhere the softening logic exists |
| An AI judge giving an inconsistent answer under load | A second, independent confirming call is required before any block is softened; if that confirmation can't be obtained, the system falls back to its prior behaviour rather than guessing in either direction |
| Rule changes silently altering past decisions | Every rule set is fingerprinted; every audit row carries the fingerprint that produced it, so any historical decision can be reproduced exactly |
Residual risk, disclosed rather than hidden
Heavily obfuscated evasion attempts (leetspeak, artificial letter-spacing) are not yet caught by the rules layer with full reliability. They surface as a flagged item for human review rather than a silent pass — the compensating control is the review queue, not a claim that the rules layer alone is unbeatable.
Any change to a rule's pattern, its weighting, or its published explanation produces a new engine fingerprint — a short hash embedded in every decision made under that version. This is what makes the accuracy declaration in the next section defensible: a customer disputing an old decision can have it re-run against the exact rule set that made it, not the current one.
A change to a judge's system prompt is tracked the same way, through a separate prompt hash carried on every decision — because the AI judge's behaviour is just as capable of drifting as the deterministic rules, and a compliance record that only tracked one of the two would be misleading about which layer actually decided a case.
Published, versioned accuracy figures for the deterministic layer are available at the platform's public accuracy endpoint, tied to the engine fingerprint in force at the time. Because the rules layer is fully deterministic, any published figure is reproducible against the exact rule version it describes — not a one-time benchmark that quietly goes stale.
| Attack surface | Mitigation |
|---|---|
| Prompt injection targeting the AI judge | Hard-blocked before the judge is ever consulted |
| Character-level obfuscation (homoglyphs, invisible characters, full-width text) | Text is normalised to a canonical form before any pattern is tested; normaliser version is part of the fingerprint |
| Single-layer evasion | Requires defeating both the deterministic layer and the AI judge, not either alone |
| Model drift from continuous learning | Not applicable — the deterministic layer has no learning path, and the judge model is fixed and versioned, not fine-tuned |
For a recruitment governance system, the practically reachable serious-incident categories are a fundamental-rights infringement the system caused or failed to prevent, and — in the most severe edge case — a documented, serious harm connected to a discriminatory outcome. Once a causal link between the platform and an incident is established, not merely suspected, a fixed reporting clock starts: as short as two days for the most severe categories, fifteen for the others. That clock cannot be extended, which is why deployers reporting suspected incidents promptly (see Booklet I, §6) matters — a late report from the field is a late-starting clock on our side too.
Oversight is exercised by the deployer, not by CognitivFusion — this section describes what is built for that exercise, not a claim of performing it. The platform provides: a review queue with SLA-tracked deadlines and breach alerting; a reviewer-diversity safeguard so a single reviewer's pattern of approvals cannot silently become an auto-approve rule; an immediate per-tenant halt switch reachable in one call, with human-review routes staying reachable even while halted so oversight itself is never interrupted by the halt; and a requirement that softening a rules-layer block needs two independent AI opinions in agreement before it's even offered to a human reviewer.
Prompt and document text is encrypted at the moment it's written, with a key scoped to the customer and the month. When a retention window ends, the key — not the row — is destroyed: the hash chain stays intact and verifiable, but the underlying text becomes permanently unreadable. The destruction event is itself an immutable ledger entry, so erasure is provable rather than merely asserted. A floor of 180 days is enforced in code, matching the Article 26(6) minimum, and cannot be configured below it by any tenant.
| Role | Responsibility |
|---|---|
| Engineering | Engine accuracy, test coverage, fingerprint integrity, regression probes |
| Compliance | Rule-corpus review, this program's maintenance, regulatory-change monitoring |
| Founder | Decisions on open governance items; custody of retention key-encryption material |
| Customer (deployer) | Reviewer staffing and training; candidate and worker-representative notices; the decision to suspend use |