Deployer Handbook · Booklet I of II
What your organisation must do under the EU AI Act to lawfully deploy AI in hiring and HR — and exactly which parts CognitivFusion's platform does for you.
This booklet is written for the people inside your organisation who will actually carry the obligations below — not for lawyers drafting the contract. It maps each obligation to the person who owns it and, where CognitivFusion's platform does part of the work, exactly what that part is.
Not legal advice
This is an operational and technical guide, not a legal opinion. CognitivFusion has not engaged compliance counsel to review the current text against the finalised AI Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026). Before relying on this document for a conformity assessment, notified-body submission, or regulator correspondence, have it reviewed by your own qualified counsel.
If your organisation uses an AI system to screen CVs, rank candidates, draft or personalise job adverts, decide who advances to interview, or make any recommendation that influences a recruitment or promotion outcome, that system is almost certainly high-risk under Annex III, point 4 of the EU AI Act — "employment, workers management and access to self-employment."
This applies whether the AI system is something you built, a feature inside your ATS, or a general-purpose model your recruiters use directly. CognitivFusion does not replace that system — it sits between your people and it, inspecting what goes in and what comes out.
The Act splits obligations by role. A provider — whoever built and placed the high-risk AI system on the market — carries the heavy obligations: conformity assessment, CE marking, technical documentation, post-market monitoring, serious-incident reporting.
A deployer — an organisation using that system under its own authority — carries lighter, operational obligations: assign human oversight, keep the logs the system generates, monitor for malfunction, and tell the people affected.
Where CognitivFusion sits
Your organisation is the deployer of your own recruitment AI. CognitivFusion is a provider of governance and audit tooling that supports your deployer obligations — it does not decide whom you hire, and it is not the provider of your hiring AI system within the meaning of the Act. Keep this distinction in your contract and in your notified-body correspondence; conflating the two shifts obligations no one intended to shift.
Article 26 sets the deployer's operational duties. The table below is your working checklist — who owns it inside your organisation, and what CognitivFusion already provides toward it.
| Obligation (Art 26) | Stays yours | CognitivFusion provides |
|---|---|---|
| Assign competent, trained human oversight | Naming the reviewers; their training records; their authority to act | The review queue, SLA-deadline tracking, and reviewer-diversity safeguards on auto-approval |
| Use the system per its instructions for use | Configuring thresholds appropriate to your risk appetite | Documented default thresholds and a changelog of every threshold edit, flagged if it deviates >20% |
| Monitor operation; suspend on malfunction | Deciding to suspend, and acting on the decision | A per-tenant kill switch that halts every governance-touching route in one call, immutably logged |
| Keep automatically generated logs, minimum 6 months (Art 26(6)) | Setting your retention window if longer than default | A tamper-evident, hash-chained ledger with a 180-day floor enforced in code, not policy |
| Inform workers' representatives before deployment (Art 26(7)) | Actually notifying them, on your timeline | A generated worker-notification pack — cover sheet, populated notice, evidence, manifest |
| Inform affected candidates their application involves an AI system | Adding the notice to your own candidate communications | A per-decision, candidate-safe explanation artifact you can link or embed |
| Cooperate with market-surveillance authorities | The relationship with the authority | An evidence pack assembled on request: engine version history, accuracy metrics, audit statistics for your tenant |
One obligation that changed
Article 27's Fundamental Rights Impact Assessment was narrowed by the AI Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026) to public-sector bodies and private bodies exercising public functions. If you are a private-sector employer, the FRIA no longer applies to you. If you are a public authority or exercise a public function, it still does — CognitivFusion's evidence pack supports that assessment without CognitivFusion performing it for you.
Article 14 requires oversight that can genuinely intervene — not a rubber stamp. That means the people you assign need real authority to overturn a decision, real time to review it, and a real mechanism to stop the system if something is wrong.
Your reviewers need to understand what a flagged decision is asking them to judge, and what a blocked decision already refused to let through. The platform's review queue presents each item with a plain-English reason — not just a code — specifically so a non-engineer reviewer can act on it correctly.
If a reviewer approves a previously blocked item, that approval now has real effect: the identical request will pass on resubmission within a 7-day window, rather than being blocked again for no reason your team can explain to the candidate.
Article 12 requires traceability; Article 26(6) sets your floor at six months; GDPR's storage-limitation principle eventually requires you to stop holding candidate data you no longer need. These three requirements pull in different directions, and the platform resolves the tension for you rather than leaving you to choose one.
| What's kept | Retention | Why |
|---|---|---|
| The decision, codes, and risk metrics | Indefinite | This is the governance record itself — Art 12 traceability |
| The prompt or document text | 180–3650 days, tenant-configurable, encrypted at write | Art 26(6) floor, then GDPR storage limitation |
| The tamper-evidence chain | Indefinite (hashes only, no personal data) | Proves the record wasn't altered after the fact |
When a candidate's retention window lapses, or you receive a valid erasure request, the encryption key for that data is destroyed — the record stays in the chain (so nothing breaks and the decision history stays intact) but the underlying text becomes permanently unreadable. The act of destroying it is itself logged, so you have evidence the erasure happened.
Article 26(5) requires you to inform the provider and relevant authorities without undue delay if you identify a serious risk or a serious incident. In practice: