AI interview compliance: how we approach the EU AI Act

Recruitment and candidate selection fall inside the high-risk category of the EU AI Act. Lantern is classified, documented and logged as a high-risk AI system, with SOC 2 Type II, ISO 42001 and the NIST AI Risk Management Framework underneath it.

This post describes how we approach that obligation as a vendor. It is not legal advice, and it is not a substitute for your own counsel's read of how the Act applies to you as a deployer — your obligations are yours, and they depend on facts about your organisation that we don't have.

Why is hiring classified as high-risk?

Because the consequences land on individuals who didn't choose the system and can't inspect it. An AI system used to filter applications, evaluate candidates, or inform selection decisions affects a person's access to work, which is the category of harm the Act's high-risk tier exists to govern.

We think that classification is correct, and we'd rather build for the strictest reading than argue about the boundary. Hiring is a regulated act whether or not software is involved; adding software doesn't lower the standard, it raises the documentation burden.

What does high-risk classification ask of a vendor?

In broad terms: know your risks, govern your data, document the system, log what it does, tell people it's being used, keep a human meaningfully in the loop, and hold the thing to a stated accuracy and security standard. Each of those turns into something concrete a customer can ask you for.

• Risk management as a continuous process, not a launch-day exercise.
• Data governance covering what the system is trained on, what it retains, and where it lives.
• Technical documentation that a reviewer outside the company can follow.
• Logging sufficient to reconstruct what the system did on a specific day for a specific person.
• Transparency to the people being assessed.
• Human oversight with real authority, not a rubber-stamp step.
• Accuracy, robustness and security held to a declared standard.

How does the audit trail work?

Every question, every answer, and every score is retained and exportable. Each score points to the exact moment in the transcript that produced it, so a reviewer can move from a number to the sentence behind it without asking us for an explanation.

That property does most of the compliance work in practice. When a regulator, a works council, or an internal audit team asks why a candidate scored what they scored, the answer is a quote and a timestamp rather than a model architecture diagram. It's also what makes internal disagreement productive: a hiring manager who thinks a rating is wrong can read the evidence and say so, and that disagreement is itself logged.

What does EEO-aware scoring mean in practice?

It means the rubric reads evidence, not accents, names, or schools. Scores come from what the candidate demonstrated against criteria defined in advance, and outcomes are monitored continuously across demographic groups so that drift is measured and reported rather than discovered later.

Two details matter more than the phrase. First, bias monitoring is ongoing: scoring drift is a metric we track, not an assertion we make once at procurement. Second, language is part of fairness. One rubric is audited for language drift so that nobody scores lower for interviewing in the language they think in — which, in a 40+ language product, is not a small piece of the fairness surface. We go into that in multilingual AI interviews.

Who makes the final decision?

The client's team, always. Lantern never rejects a candidate. It interviews, scores, ranks, and explains; humans read the evidence and decide.

This applies to the awkward cases too, which is where the design is actually tested. Deepfakes, cloned voices and AI-generated scripts are detected in real time, and a flag is never an auto-rejection — the evidence goes to the hiring team and a person makes the call. Negotiations, complaints, accommodation requests and anything the rubric doesn't cleanly cover escalate to the client with the full transcript attached. Human oversight that only activates on the easy cases isn't oversight.

What certifications sit underneath?

The list we hold, as it stands today:

• SOC 2 Type II
• ISO 27001, ISO 27018, ISO 27701
• ISO 42001 for AI management systems
• GDPR and CCPA
• EU AI Act — classified and documented as a high-risk AI system
• NIST AI Risk Management Framework
• EEO-aware scoring

Alongside those: regional data residency options, deletion SLAs, and no training on candidate data. Client data stays the client's. The compliance section of the landing page carries the same list, and a security pack is available on request. For how the same posture reads against US and Hong Kong expectations, see AI hiring compliance in Hong Kong, the US and the EU.

Common questions

Is an AI interviewer allowed under the EU AI Act?

Yes, when it's built and documented to be. High-risk doesn't mean prohibited; it means obligated. The question to ask a vendor isn't whether they're allowed, it's whether they can hand you the classification, the documentation and the logs when someone asks.

What should we ask a vendor during procurement?

Ask for the classification in writing, a sample audit export for a single candidate, the bias-monitoring methodology, the data residency and deletion terms, and a clear statement of who holds the reject decision. Any vendor that can't produce all five quickly is telling you something.

Do candidates have to be told an AI is interviewing them?

Transparency to the assessed person is a core expectation of the high-risk regime, and we design for candidates knowing. The precise notice and consent obligations that apply to you as a deployer are a question for your counsel, not for us.

If your legal team wants to go through the documentation before your recruiters go anywhere near a demo, that's the order we prefer too. Ask us for the security pack.