Before You Buy the Bot: The Compliance Reality of AI Screening Tools Across the EU, China, California, and Beyond

Section 1 — One Decision, Four Jurisdictions

The vendor's demo covered none of this. The proposal on the table treats it as a single procurement decision. It isn't. It is four compliance problems arriving at the same time, each carrying its own deadlines, obligations, and enforcement consequences.

The question is not whether to use AI in recruitment. The question is whether the organisation has done the work to use it lawfully across every jurisdiction where it will operate.

Section 2 — Three Frameworks, One Problem

The Head of HR has framed this as a procurement decision. The legal team, if they get involved at all at this stage, will likely frame it as a data privacy review. Both framings are incomplete.

Deploying an AI screening tool across four jurisdictions simultaneously activates three distinct compliance frameworks — and the relationship between them is not sequential. It is not a matter of satisfying privacy law first, then turning to AI governance, then sorting out the data architecture. The three frameworks are concurrent, and the decisions made in one directly constrain what is possible in the others.

The three frameworks do not exist in isolation. A data governance decision — to centralise all applicant data on a single vendor platform — can simultaneously create a cross-border transfer problem under PIPL, a controller-processor relationship that requires a GDPR-compliant data processing agreement, and an obligation to assess whether that vendor meets the EU AI Act's technical documentation and conformity requirements. Solving one without the others produces a compliance programme that is coherent on paper and fragile in practice.

What follows is a closer look at each of the three layers — what they require in this scenario, where the obligations are most acute, and what the organisation needs to have in place before the platform goes live.

Section 3 — The Data Privacy Obligations, Jurisdiction by Jurisdiction

Data privacy law does not ask whether a company intended to collect personal data. It asks what personal data was collected, on what basis, for what purpose, where it went, and how long it was kept. An AI screening tool answers all five questions — and in this scenario, it answers them four times over, once for each jurisdiction where applicants are located.

The obligations are not identical across Taiwan, the EU, California, and China. They converge on the same underlying logic — that applicants have rights over their personal data and those rights do not evaporate because an algorithm is doing the processing — but they diverge materially on the specific requirements. What follows is not an exhaustive regulatory survey. It is a map of where the friction is.

Taiwan — the HQ jurisdiction

The company's headquarters in Taiwan is not a passive participant in this exercise. It is likely where the platform is administered, where vendor relationships are managed, and where applicant data from multiple locations flows for centralised processing. Taiwan's Personal Data Protection Act (PDPA) applies to the collection, processing, and use of personal data by companies registered in Taiwan, and it governs the HQ's handling of applicant data regardless of where those applicants are located.

The PDPA requires a specific purpose for collecting personal data, limits use to that stated purpose, and imposes obligations around security, retention, and cross-border transfer. For applicant data specifically, collection must be proportionate — the data gathered through the screening tool must be necessary for the stated purpose of evaluating candidates, not simply everything the tool is capable of ingesting. Taiwan's draft AI Basic Act is still in legislative development, but it does not create a gap in current obligations: the PDPA applies to automated processing of personal data whether or not AI-specific rules are in force.

As the HQ jurisdiction, Taiwan also bears responsibility for the governance architecture — the decisions about platform design, vendor selection, and data flows that determine whether the obligations in every other jurisdiction can be met.

The European Union — the highest compliance bar

The Berlin office recruits for roles across European operations. Every applicant who submits a CV in that process is a data subject whose personal data is governed by the GDPR (General Data Protection Regulation) from the moment of collection.

The lawful basis question is the first hurdle. Most GDPR-compliant recruitment processing relies on Article 6(1)(b) — processing necessary for the performance of a contract, which courts and regulators have accepted as covering pre-contractual steps including evaluating job applications. But this basis has limits. It covers processing that is genuinely necessary for the specific recruitment decision; it does not cover speculative data collection, retention of rejected applicants' data beyond the specific hiring cycle, or using applicant data to train or improve the AI model.

The automated decision-making restriction under Article 22 is the second and more operationally significant hurdle. The GDPR gives individuals the right not to be subject to a decision based solely on automated processing that produces significant effects — and GDPR Recital 71 specifically cites e-recruiting practices without human intervention as an example. The more defensible design is to ensure that a human being with genuine authority reviews and can override the tool's output before any decision affecting the applicant is finalised.

Where applicant data leaves the EU — to a vendor's servers outside the EEA, or to the Taiwan HQ for centralised processing — a transfer mechanism is required. Standard contractual clauses must be accompanied by a transfer impact assessment evaluating whether the destination jurisdiction's laws undermine the protections the clauses provide. A Data Protection Impact Assessment (DPIA) is also mandatory before deploying high-risk processing activities of this kind.

California — two frameworks, one compliance programme

The California picture is more layered than most compliance teams realise, and more is already in force than many expect.

The California Civil Rights Council's Employment Regulations Regarding ADS (Fair Employment and Housing Act, FEHA) took effect October 1, 2025. These regulations clarify how California's long-standing anti-discrimination law applies to AI tools in hiring. The practical obligations are anti-bias testing, four-year retention of ADS-related data, and an express prohibition on any ADS that produces a discriminatory outcome based on protected characteristics — whether or not that discrimination was intentional. Disparate impact is sufficient. Liability extends to the vendor when an employer delegates employment decision-making functions to it.

Separately, the California Privacy Protection Agency's automated decision-making technology regulations (CCPA), finalised July 2025, require pre-use notice to applicants, the right to opt out of automated decision-making, and a risk assessment before deployment — with a compliance deadline of January 1, 2027.

One nuance worth noting: the Trump administration's December 2025 executive order on AI governance represents a federal attempt to challenge state-level AI regulations. Congressional attempts at preemption have so far failed, and the FEHA regulations are currently in force. Because they extend existing civil rights law rather than creating novel AI-specific obligations, they are on stronger legal footing than standalone AI statutes. Organisations should monitor federal developments, but should not treat uncertainty about preemption as a reason to defer compliance with currently operative obligations.

China — consent, impact assessments, and cross-border transfers

The Shanghai office recruits locally. That means applicant data is being collected in China, processed in China, and — if the platform is centralised — transferred outside China. Each of those activities engages the Personal Information Protection Law (PIPL).

The lawful basis for processing applicant data under PIPL is most naturally contract necessity — processing necessary for HR management is an express basis under Article 13. But this basis does not extend to every activity involved in AI-assisted screening. Sharing applicant data with a third-party vendor requires separate consent under Article 23. Processing biometric data requires explicit consent for sensitive personal information under Articles 28 and 29.

Before any automated decision-making system is deployed that uses personal information, PIPL requires a personal information protection impact assessment (PIIA). This is not a GDPR DPIA by another name — it has its own required content, documentation requirements, and a three-year retention obligation. A company that conducts a DPIA for GDPR purposes and assumes it satisfies the PIPL requirement has not completed the analysis.

Cross-border transfer is where the architecture of the platform becomes a direct legal question. If Shanghai applicant data flows outside China, that transfer requires a lawful mechanism — a standard contract filed with the relevant authority, a security assessment conducted by the Cyberspace Administration of China for higher-volume transfers, or certification. None of these can be put in place at the moment of go-live. The company that discovers this requirement after signing the vendor contract either delays the rollout or proceeds in breach of PIPL.

Section 4 — The AI Governance Obligations

Data privacy law tells the company how to handle applicant data. AI governance law tells it what the screening tool itself must be — and what the company, as the organisation deploying it, is responsible for ensuring. The two are related but distinct. A tool that satisfies every data privacy requirement can still be non-compliant under AI governance frameworks. And the entity that bears the AI governance obligations is not always the vendor who built the tool. In most jurisdictions, it is the company that chose to use it.

The European Union — high-risk by law, not by assessment

The EU AI Act does not ask a company to evaluate whether its recruitment AI is high-risk. It has already made that determination. Under Annex III of the Act, AI systems used to analyse and filter job applications and evaluate candidates are explicitly classified as high-risk. That classification applies regardless of how the vendor describes the product, how limited its role is framed, or how robust the human review layer is. High-risk is a legal category, not a risk score.

The obligations that flow from that classification fall on both the vendor — as provider — and the company — as deployer. They are not the same obligations, and they cannot be fully contractually transferred. The provider must deliver a system that meets the Act's technical requirements. The deployer must conduct its own fundamental rights impact assessment, implement human oversight mechanisms, monitor the system's operation, provide transparency to affected candidates, and ensure staff have sufficient AI literacy to supervise the tool effectively.

Two obligations are already in force and cannot wait for the August 2026 deadline. Certain practices are prohibited outright since February 2025: emotion recognition in the context of employment, and biometric categorisation systems that infer protected characteristics from physical attributes. Any vendor feature that analyses facial expressions during video interviews, assesses emotional state from voice tone, or infers personality traits from biometric signals must be disabled now. The AI literacy obligation also applies from February 2025 — staff who use or supervise high-risk AI systems must have sufficient understanding of how those systems work, where they may fail, and when to override their outputs.

The extraterritorial dimension matters: the EU AI Act applies wherever its outputs are used in the EU. A screening platform administered from Taiwan HQ, processing applications for Berlin roles, falls within scope regardless of where the platform is hosted or where the vendor is incorporated.

California — discrimination law meets algorithmic accountability

California's two frameworks converge on a common principle: that deploying an AI tool in hiring transfers neither the responsibility for its outputs nor the liability for its failures to the vendor.

The FEHA (Fair Employment and Housing Act) regulations establish that discriminatory outcomes from automated decision systems are unlawful — including outcomes that were not intentionally discriminatory but produced a disparate impact on protected classes. An AI screening tool that systematically ranks candidates of a particular demographic lower can constitute a FEHA violation if the output correlates with race, gender, national origin, disability, or other protected categories through proxy variables. Employment gaps that correlate with disability. Educational institutions that correlate with race. Address patterns that correlate with national origin. These are the kinds of proxies that bias auditing is designed to detect, and their presence in training data is the employer's compliance problem, not only the vendor's.

The CPPA's automated decision-making regulations add a pre-deployment risk assessment, pre-use notice to applicants, and the ability for applicants to opt out. The opt-out right raises an architectural question: if an applicant exercises it, does the company have an alternative non-automated pathway ready?

The FEHA regulations are legally grounded in decades of civil rights law and are currently in force. The litigation risk of non-compliance with a currently operative regulation is more proximate than the legal risk of compliance with a regulation that may later be narrowed.

China — layered obligations across multiple instruments

China's AI governance obligations for a recruitment tool arrive through several instruments rather than a single statute.

If the screening tool uses a large language model to parse CVs, generate candidate summaries, or produce scoring rationales, the Generative AI Interim Measures (生成式人工智慧服務管理暫行辦法, Interim Measures for the Administration of Generative Artificial Intelligence Services) apply. The Algorithm Recommendation Rules (互聯網信息服務算法推薦管理規定, Administrative Provisions on Recommendation Algorithms in Internet-based Information Services) require that affected persons be informed of the algorithm's role — directly applicable to a tool that scores and ranks job applicants. The AI Content Labelling Measures, now a mandatory national standard effective September 2025, require that AI-generated content be labelled as such: any AI-produced candidate summary, assessment narrative, or scoring rationale must be identified as AI-generated output.

The Cybersecurity Law (網路安全法, CSL) amendments effective January 1, 2026 bring AI explicitly into China's national legal framework, reinforcing the integration of AI governance obligations with PIPL and the Data Security Law (數據安全法, DSL). A comprehensive AI law remains absent from China's 2025 legislative agenda — but what this means in practice is not reduced obligation but increased complexity: obligations are distributed across instruments administered by different authorities, with different documentation requirements and different enforcement postures.

Underlying all of this is the PIPL personal information protection impact assessment requirement. It functions simultaneously as a data privacy obligation and an AI governance instrument — it must evaluate the risks of the automated decision-making system specifically, and cannot be substituted by the GDPR DPIA or the CPPA risk assessment.

Taiwan — existing obligations, incoming framework

Taiwan's draft AI Basic Act is still working through the legislative process. Existing obligations under the PDPA already apply to automated processing of personal data in recruitment, and the direction of the draft legislation makes clear that impact assessment, transparency, and human oversight requirements are coming. A Taiwan-headquartered company that builds these into its platform design now will not need to retrofit them when the AI Basic Act is enacted.

The deployer responsibility gap

Across all four jurisdictions, a consistent pattern emerges: the company deploying the tool bears independent governance obligations that cannot be contracted away to the vendor.

Under the EU AI Act, the deployer's fundamental rights impact assessment, human oversight mechanisms, and staff AI literacy obligations are the deployer's responsibilities regardless of what the vendor provides or what the contract says. Under California's FEHA regulations, the employer cannot escape liability by pointing at the vendor. Under PIPL, the company retains responsibility for ensuring the processing is lawful and must supervise the processor's activities.

A vendor that provides a technically capable system, a data processing agreement, and a set of terms of service has not discharged the deploying company's governance obligations. It has provided inputs to those obligations. The compliance work that remains — the impact assessments, the bias audits, the human oversight design, the candidate-facing notices, the ongoing monitoring — belongs to the company that decided to use the tool.

Section 5 — The Data Governance Foundation

Sections 3 and 4 describe what the law requires. This section describes what the organisation needs to have built in order to satisfy those requirements — and why, for most companies, the data governance work is the critical path that determines whether the compliance programme is real or merely documented.

Data governance is not a compliance deliverable. It is the operational infrastructure that makes compliance possible. In the context of a global AI screening platform, it answers the questions that privacy law and AI governance law assume have already been resolved: Where does applicant data actually go? Who controls it? What can the vendor do with it? Does the architecture of the platform make it possible to satisfy the legal obligations in each jurisdiction simultaneously? These questions are not answered by reading the vendor's privacy policy.

Data architecture before procurement

The single most consequential data governance decision in this scenario is one the company may not realise it is making: choosing a fully centralised platform architecture.

A unified platform administered from Taiwan HQ, receiving applicant data from Berlin, Shanghai, and Los Angeles, creates four simultaneous cross-border data flow problems. Shanghai applicant data flowing to a centralised system triggers PIPL's cross-border transfer requirements before a single interview has been scheduled. EU applicant data flowing outside the EEA requires a transfer mechanism and a transfer impact assessment under GDPR. The vendor's own data residency — where the platform's servers are located, and whether that location is disclosed in the contract — determines whether the transfer obligations are even satisfiable with the architecture as designed.

None of these questions can be answered at go-live. A company that selects a vendor, signs a contract, and then begins the data governance analysis is working in the wrong sequence. The architecture question must be resolved before procurement, not during implementation.

An alternative worth evaluating is a modular architecture: a common tool with jurisdiction-specific configurations, separate data environments for EU and China operations, and clearly defined data flows that match the transfer mechanisms available in each jurisdiction. This design trades some operational efficiency for significantly reduced cross-border transfer exposure and a compliance programme that is easier to document and defend.

Data minimisation as a governance instrument

A CV contains more than screening criteria. Date of birth. Home address. Employment gaps that may correlate with disability, caregiving, or military service. Educational institutions that may correlate with race or socioeconomic background. Physical characteristics visible in a profile photograph. Psychological traits inferred from writing style.

An AI screening tool that ingests a raw CV ingests all of this — and most tools are designed to extract and weight precisely these kinds of signals, because they correlate with patterns in historical hiring data. That correlation is the source of both the tool's predictive power and its legal exposure. Data minimisation at the point of ingestion — defining precisely what data the tool receives, in what form, and with what pre-processing — is a data governance control that simultaneously addresses privacy obligations, AI governance obligations, and bias risk.

The governance framework must define what the tool receives. The vendor contract must constrain what the tool does with it. Neither happens by default.

Vendor governance — the contract as compliance instrument

The AI screening tool is a third-party processor receiving personal data simultaneously from four jurisdictions, administering a system that the EU AI Act classifies as high-risk, and producing outputs that carry legal consequences for the individuals whose applications it evaluates. The governance obligations that attach to that relationship are not discharged by a standard data processing agreement.

The vendor contract must address: whether using applicant submissions to train or improve the model is explicitly prohibited; data retention and deletion obligations aligned with the requirements in each jurisdiction; data residency specifications consistent with the transfer mechanisms being relied upon; EU AI Act technical documentation and audit access obligations; PIPL processor obligations including supervision rights; California FEHA vendor liability provisions and bias testing disclosure obligations; and provisions governing what happens to applicant data when the contract ends.

Under the EU AI Act, the deployer is entitled to certain documentation from the provider of a high-risk AI system as a matter of law. Under PIPL Article 23, the processor agreement must specify the purpose, period, and method of processing, the types of data involved, the protective measures to be taken, and the rights and obligations of both parties. A vendor that cannot answer the documentation questions, will not provide the technical specifications, or offers a DPA that does not address cross-border transfer obligations is not a vendor that can support a compliant global deployment.

Impact assessments — three jurisdictions, three distinct instruments

The EU AI Act requires a fundamental rights impact assessment from the deployer of a high-risk AI system. The GDPR requires a DPIA before deploying high-risk processing activities. PIPL requires a personal information protection impact assessment (PIIA) before any automated decision-making system is deployed. California's CPPA regulations require a risk assessment before deployment for significant employment decisions.

These are not the same document. A company that conducts a GDPR DPIA and assumes it satisfies the PIPL PIIA, or that combines both into a single EU AI Act fundamental rights assessment, has produced a document that may satisfy none of them fully. The data governance programme must map which assessment is required in which jurisdiction, what each must contain, and who is responsible for conducting it.

Critically, these assessments are not one-time exercises. The EU AI Act requires ongoing monitoring. PIPL requires reassessment when the processing purpose, method, or data type changes materially. A platform rollout that expands to new territories, adds new screening criteria, or upgrades to a new model version may trigger reassessment obligations in multiple jurisdictions simultaneously.

Records, logs, and audit trails

The EU AI Act requires high-risk AI systems to maintain logs sufficient to enable post-hoc review and regulatory investigation. California's FEHA regulations require four-year retention of ADS-related data including inputs, outputs, decision criteria, and audit results. PIPL requires a three-year retention of impact assessment records. The GDPR requires documentation of processing activities and the DPIA.

Each of these retention obligations requires the platform to actually generate the records — and to store them in a way that is accessible, jurisdiction-specific where necessary, and defensible in regulatory and litigation contexts. This is infrastructure design, not documentation work — and it must be specified before the platform is configured, not extracted from the system after deployment.

The single-platform question, revisited

A centralised platform creates operational efficiency. It also creates a single point at which every jurisdiction's most demanding requirements must be simultaneously satisfied — and a single point of failure if any one of them is not.

The data governance analysis may conclude that a unified platform is achievable. That conclusion requires evidence, not assumption. It may alternatively conclude that the jurisdictional requirements are genuinely incompatible with a single centralised architecture. In that case, the governance analysis has done its job: it has identified the constraint before the contract was signed, when the architecture can still be adjusted, rather than after deployment, when the options are limited and the exposure is live.

That is what data governance is for — not to produce a document that describes the compliance programme, but to answer the architectural questions that determine whether the compliance programme is possible.

Section 6 — What Good Looks Like Before You Sign the Contract

The most expensive place to discover a compliance problem is after deployment. The vendor contract has been signed. The platform is live. Applicant data from Shanghai is already flowing to servers the legal team has never reviewed. The recruitment team in Berlin is sending automated rejections without a human review layer. Nobody has conducted a DPIA. The bias audit has not been scheduled because nobody knew it was required.

This is not a hypothetical. It is the default outcome when a global AI tool rollout is treated as a procurement decision rather than a governance exercise.

What follows is not a checklist. It is a sequence — the order in which the work needs to happen, and why the sequence matters as much as the individual steps.

Managing this sequence is itself a legal operations challenge. Six interdependent workstreams — data flow mapping, vendor due diligence, impact assessments, human oversight design, applicant notices, and contract negotiation — each with external dependencies, internal stakeholders, and outputs that feed into the next step. In a typical procurement cycle, the timeline compresses from both ends: the business wants the tool live, the vendor wants the contract signed, and the compliance work gets squeezed into whatever space remains. The organisations that deploy AI screening tools successfully treat the pre-deployment phase as a structured project: defined workstreams, assigned owners, clear dependencies, and a go/no-go gate before the contract is executed. That gate is not a legal veto — it is the point at which the governance work is complete enough to sign with confidence rather than with fingers crossed. Building and managing that structure is legal operations. It is what turns a compliance checklist into a process that actually runs.

One final point on sequence: the vendor contract negotiation should not begin until the data flow map, the vendor due diligence, and the impact assessment framework are sufficiently developed to inform what the contract needs to say. A contract negotiated before the data governance work is done will be missing terms — and the terms that are missing are typically the ones that matter most when the compliance question is asked in earnest.

Section 7 — The Decision That Hasn't Been Made Yet

The Head of HR still has a problem. Four hundred CVs a week. A team that is stretched. A vendor with a compelling demo and a reasonable price. The business case for AI-assisted screening is real, and it is not going away.

The argument this article makes is not that the tool should not be deployed. It is that the decision to deploy it globally, across Taiwan, the EU, California, and China, is not the decision it appears to be from the procurement table. It is a data privacy decision, an AI governance decision, and a data architecture decision — made simultaneously, with obligations that are already in force in some jurisdictions and arriving fast in others.

The organisations that will deploy these tools successfully are not the ones that move fastest. They are the ones that do the governance work first — that map the data flows before evaluating vendors, assess vendors as high-risk AI deployers rather than data processors, conduct the impact assessments before configuration, build human oversight into the architecture rather than layering it on afterwards, and draft applicant-facing notices that actually satisfy the disclosure obligations in each jurisdiction. None of that work is prohibitively complex. All of it takes time that the procurement timeline typically does not allow for — unless someone in the organisation understands what needs to happen and ensures it happens in the right sequence.

That is where legal operations, data privacy, and AI governance converge on a single business decision. Not as three separate compliance workstreams running in parallel. As an integrated analysis of what the law requires, what the architecture enables, and what the organisation needs to have built before the contract is signed.

The companies that treat that convergence as a strength — rather than a complication to be managed after the fact — are the ones that deploy AI tools that work legally, operationally, and defensibly across the jurisdictions where they operate.