(3/3) We Built Our Preselection for the Law Before the Law Existed
In Part 1 I argued that the EU AI Act has quietly reclassified almost every AI hiring tool as high-risk. In Part 2 I walked through the obligations that fall on the employer who deploys those tools — human oversight, worker transparency, impact assessments, the GDPR overlay. Both posts circled the same conclusion: a hiring process is compliant only if a competent human genuinely owns the decision.
That conclusion isn't new to me. It's the thesis I've defended on this blog since the beginning — AI augments human judgment, it doesn't replace it — and it happens to describe, almost line for line, how we built candidate preselection at Conectia. So in this final post I want to do something more useful than another summary of the regulation. I want to show what a compliant, AI-aware hiring pipeline looks like from the inside, using the one I know best.
To be clear about the framing: this is not a claim that Conectia has a magic compliance certificate. The Act's high-risk obligations apply in phases, the Digital Omnibus may still move the dates, and any company's posture has to be assessed against its specific tools and use cases. What I can show is that when you design a hiring process around human accountability from the start, the regulation stops being a retrofit and becomes a description of what you already do.
Where the Regulation Touches a Remote Hiring Pipeline
Conectia preselects engineers for remote and nearshore roles. We run candidates through a vetting process, and we hand clients a shortlist of three to five validated people. That places us in two of the roles the AI Act cares about at once:
- We are a deployer of any AI we use inside our own preselection.
- The client who hires from our shortlist is also a deployer, making decisions that affect access to employment — squarely inside Annex III's employment category.
Both of us are accountable. Neither of us gets to point at a tool. The design question, then, is not "how do we avoid using AI" — that would be both impossible and foolish — but "how do we use AI so that a human is always, demonstrably, the one who decides?"
The Principle: AI on the Inputs, Humans on the Verdict
The cleanest way I can state our design rule is this: AI is allowed to shape the inputs to a decision; it is never allowed to be the decision.
That line maps directly onto the Article 14 and Article 26(2) oversight requirements from Part 2. A system can summarize, surface, draft, and flag. A human reads the work the AI did, brings judgment the AI doesn't have, and makes the call — and that call can, and sometimes does, contradict what the tooling suggested. The moment a candidate is advanced or rejected, a named person with the competence and authority to do so has made that choice. That's not a compliance feature we added. It's the spine of the whole process.
Our five-pillar vetting makes this concrete:
- Code quality is reviewed by a senior engineer, not scored by a machine. We deliberately don't use automated code scoring. A human reads the submission and writes feedback, accounting for language, framework, and context — because idiomatic Go doesn't look like idiomatic Python, and a number out of a model can't tell the difference. This is the single most important design choice for compliance and for quality, and they turn out to be the same choice.
- Architecture and trade-off reasoning is assessed in a structured human discussion. You cannot automate the evaluation of whether someone reasons well about failure modes. A person does it.
- Communication is judged by people who do the work. Written clarity and proactive problem-flagging are evaluated against real scenarios by reviewers who know what good remote collaboration looks like.
- Track record is verified by humans talking to humans. References are conversations, not form-fills.
There is plenty of room for AI to assist across all of this — organizing submissions, surfacing patterns, drafting first-pass notes. What there is no room for is AI rendering the verdict. The verdict belongs to a person, every time.
Why This Satisfies the Spirit of the Act
Walk back through the Part 2 obligations and check the process against each:
- Meaningful human oversight (Art. 14 / 26(2)). The decision-makers are senior engineers and CTOs who designed the criteria, understand any tooling involved, and have the authority to override it. Oversight here isn't a rubber stamp on a ranked list — it is the evaluation.
- No prohibited practices (Art. 5). We assess engineering ability, communication, and verified experience. We do not infer emotional state from faces or voices. The banned capability from Part 1 simply isn't in the pipeline.
- Transparency and the right to a human (GDPR Art. 22). No candidate is filtered out solely by an automated process with no human in the loop. The structure that makes our shortlist credible to clients is the same structure that keeps candidates' rights intact.
- Accountability you can reconstruct. Because humans make and document the decisions, there's a real answer to the question a rejected candidate is entitled to ask: why? "The algorithm said so" is not an answer the Act accepts — and it was never an answer we were willing to give.
This is the part I find genuinely satisfying. The regulation and the quality bar pull in the same direction. The reason we never trusted a model to score code wasn't legal foresight — it was that automated scoring produces worse hiring decisions. The Act now requires the thing that was already the right thing to do.
What This Means If You're Hiring in Europe
If you're a founder or engineering leader hiring in the EU, the three posts in this series collapse into a short, practical checklist:
- Audit your hiring stack against Annex III. Anything that filters, ranks, or scores candidates is presumptively high-risk. Know what you're running.
- Kill anything that infers emotion. It's already prohibited. This is the fastest exposure to close.
- Find the human in every decision — and if there isn't one, add it. Oversight has to be real, competent, and empowered to override. A reviewer who only ever agrees with the tool is not oversight.
- Be ready to explain a rejection. If your honest answer is "the system did it," you have both a compliance problem and a quality problem.
- Press your vendors and partners. Ask who's the provider, who's the deployer, what's logged, what's assessed, and where the human sits. The answers tell you a lot about whether they've actually thought about this.
When you receive a Conectia shortlist, you're not the first technical filter — you're the final fit check. Every engineer on it cleared a process built around human judgment, which means the decision you make at the end is one you can stand behind: to a candidate, to a works council, to a regulator, and to yourself.
The EU AI Act didn't make us redesign how we hire. It described what we'd already built. That's the position worth aiming for — not compliance as a scramble before a deadline, but a process so aligned with the principle that the law, when it arrived, simply agreed with you.
Want a shortlist built this way — AI-augmented, human-decided, designed by active CTOs? Request a CTO-vetted shortlist for your open role.
