AI hiring compliance in Hong Kong, the US and the EU

Buyers hiring across Hong Kong, the US and Europe want one answer to a three-region question. The honest version: one engineering posture, three sets of expectations it has to satisfy, built for the strictest reading rather than the local minimum. Lantern holds SOC 2 Type II, ISO 27001, ISO 27018, ISO 27701, ISO 42001, GDPR and CCPA compliance, EU AI Act classification as a high-risk system, NIST AI RMF alignment, and EEO-aware scoring.

This describes how we approach the obligation as a vendor. It isn't legal advice, and it isn't a substitute for your counsel's read of what applies to you as a deployer.

Does one posture really cover three regions?

At the engineering layer, largely yes. Logging, audit trails, human oversight, bias monitoring and data governance are the same controls whichever regulator is asking. What differs is which a given regime names explicitly and how it wants them evidenced.

What doesn't transfer is the deployer's duty. Notice, consent, works-council consultation, record retention and candidate requests sit with the employer and vary by jurisdiction, sometimes by city. A vendor claiming their certifications discharge your duties is telling you something inaccurate.

What does the EU expect?

The most specific treatment of the three. Recruitment and candidate selection fall inside the high-risk category of the EU AI Act, and Lantern is classified, documented and logged as a high-risk AI system, with ISO 42001 for AI management systems and the NIST AI RMF underneath.

High-risk means obligated rather than prohibited, and the obligations become artefacts a customer can ask for: continuous risk management, data governance, technical documentation an outside reviewer can follow, logging sufficient to reconstruct what happened to one person on one day, transparency to the assessed person, meaningful human oversight, and stated accuracy and security standards. GDPR sits alongside it and covers the personal data itself. We go through each in how we approach the EU AI Act.

What does the US picture look like?

Layered rather than unified. Federal equal-employment law sets the substance, state privacy statutes such as CCPA set the data rules, and a growing set of state and municipal requirements govern automated employment decision tools specifically.

Our side of that is EEO-aware scoring and the monitoring that makes it checkable: rubrics that read evidence rather than accents, names or schools, with outcomes monitored continuously across demographic groups. NIST AI RMF is the framework we hold the risk process to. But what usually decides whether a US deployment is defensible isn't a certification at all — it's whether you can produce, for one named candidate, the questions asked, the answers given, the scores assigned and the human who decided. Lantern's audit trail is exportable for exactly that.

What about Hong Kong?

Hong Kong's expectations are set by the Personal Data (Privacy) Ordinance, which is a statute rather than a certification scheme. There is no PDPO badge to hold, and we don't claim one — for any vendor, the useful question is not "are you PDPO certified" but "which of your controls would I point at if the Privacy Commissioner asked."

The controls that answer it are ones a buyer can verify directly. Where does candidate data live, and are regional residency options available? What is retained, for how long, and what is the deletion SLA? Is candidate data used to train models? Lantern offers regional data residency options, deletion SLAs, and zero training on client candidates — those are our answers, and they're the ones you should require from anyone. Being built in Hong Kong is why the question reaches us early; it isn't a compliance claim by itself.

What should you ask any vendor, in any region?

Six questions. They're region-independent because they test whether a posture exists rather than which flag it flies under.

1. Who holds the reject decision? If the system can decline a candidate on its own, the regulatory character of the deployment changes. Lantern never rejects anyone.
2. Can I see a single-candidate audit export? Ask for a real one. The gap between "we have an audit trail" and a file you can read is where procurement surprises live.
3. How is bias monitored, and how often? Continuous measurement of scoring drift across demographic groups, or an assertion made once at procurement — very different products.
4. Where does the data live and when does it leave? Residency options, retention periods, deletion SLAs, and whether candidate data trains anything.
5. What's the classification, in writing? Under the EU AI Act specifically, but the general form — what does the vendor say this system is — is the question.
6. What happens on an edge case? Complaints, accommodation requests, fraud flags. If the answer isn't "a human at your organisation decides," ask what the answer is.

Why does human-in-the-loop keep appearing in every region?

Because it's the one control that converts an automated decision into a documented human one, and every regime cares about that boundary.

In our design it's absolute. Lantern interviews, scores, ranks and explains; the client's team decides. That holds for the awkward cases too, which is where the commitment is actually tested — fraud flags go to a human with evidence attached, and complaints, negotiations and accommodation requests escalate with the full transcript. Oversight that only activates on easy cases isn't oversight. A plain-language account of how scoring, bias monitoring and human oversight work sits on the AI explainability page.

Common questions

We only hire in one region. Does the strictest-reading approach cost us anything?

Not in obligations — building to the strictest reading doesn't create duties your jurisdiction doesn't impose. It creates documentation you may not need yet, which becomes useful the first time you open a req somewhere else.

Can you sign our data processing agreement and complete our security review?

That's the normal path, and we'd rather your legal and security teams go through it before your recruiters see a demo. A security pack is available on request.

Does compliance work differently for admissions?

Yes — student records bring FERPA into scope, which doesn't apply to hiring. That's part of why admissions runs as a separate product; see AI proctoring for university admissions.

If your legal team wants the documentation before anyone books a demo, that's the order we prefer too. Ask us for the security pack.