Before You Buy the Bot | CloudVista Consulting

At a Glance

A Taiwan-headquartered company wants to roll out an AI screening tool across its offices in Berlin, Shanghai, and Los Angeles. It looks like a procurement decision. It isn't.

Deploying AI in recruitment across these four jurisdictions simultaneously activates three distinct compliance frameworks — data privacy, AI governance, and data governance — each with obligations already in force or arriving fast.

What this article covers:

The data privacy obligations in each jurisdiction: lawful basis, automated decision-making restrictions, cross-border transfer requirements, and retention limits
The AI governance obligations: EU AI Act high-risk classification, California's two overlapping frameworks, China's layered instrument-by-instrument approach, and Taiwan's emerging framework
The data governance foundation: why the architecture decisions made before procurement determine whether the compliance programme is achievable at all
Six pre-deployment steps — in sequence — that separate organisations that deploy these tools successfully from those that discover the compliance problems after go-live

The organisations that deploy AI screening tools successfully are not the ones that move fastest. They are the ones that do the governance work first — before the vendor is selected, before the contract is signed, and before the platform goes live.

Estimated reading time: 30 minutes

概覽

一家台灣總部的企業，計畫在柏林、上海及洛杉磯的辦公室全面導入AI篩選工具。這看起來像是一個採購決策，但實際上並非如此。

在這四個司法管轄區同步部署AI招募篩選工具，將同時觸發三個截然不同的合規框架——資料隱私、AI治理，以及資料治理——其中部分義務已然生效，其餘也即將到來。

本文涵蓋內容：

各司法管轄區的資料隱私義務：合法處理依據、自動化決策限制、跨境傳輸要求，以及資料保留期限
AI治理義務：歐盟AI法的高風險分類、加州兩套相互交疊的框架、中國逐一法規構建的多層次規範，以及台灣正在形成中的框架
資料治理基礎：為何採購前的架構決策，決定了合規計畫能否真正落地
六個部署前步驟——按照順序執行——區分出成功導入工具的組織與那些在上線後才發現合規問題的組織

成功導入AI篩選工具的組織，不是行動最快的，而是最先完成治理工作的——在選定供應商之前，在合約簽署之前，在平台上線之前。

預計閱讀時間：30分鐘

Section 1 — One Decision, Four Jurisdictions

The request comes from the Head of HR. The company — a Taiwan-headquartered technology manufacturer with regional offices in Berlin, Shanghai, and Los Angeles — is drowning in job applications. Volume has tripled in two years. The recruitment team is stretched. A vendor has demonstrated an AI-powered screening tool that ingests CVs, scores candidates against a job profile, and surfaces a ranked shortlist. It integrates with the existing applicant tracking system. The pricing is reasonable. The demo was impressive.

The proposal: roll it out globally, across all four locations, on a single platform. Standardise the process. Reclaim the hours. Make hiring faster and more consistent.

It is a reasonable business decision. And if the legal and compliance function doesn't get involved before the purchase order is signed, it is also a decision that activates four distinct regulatory regimes simultaneously — each with different requirements, different timelines, and different consequences for getting it wrong.

Taiwan — Headquarters

Where the company is headquartered and where HR processes are designed and administered, the Personal Data Protection Act (PDPA) governs how applicant data is collected, used, and retained. The draft AI Basic Act is still working its way through the legislative process, but existing PDPA obligations apply to automated processing of personal data regardless of whether specific AI rules are yet in force.

European Union — Berlin Office

Two frameworks apply at once. The GDPR (General Data Protection Regulation) imposes restrictions on automated decision-making that produces significant effects on individuals — automated CV screening that determines whether a candidate advances or is rejected is precisely the scenario its drafters had in mind. And the EU AI Act, which explicitly classifies AI systems used to filter job applications and evaluate candidates as high-risk under Annex III, has already banned certain practices outright since February 2025 and will impose a full compliance framework on deployers by August 2026.

California — Los Angeles Office

The regulatory picture is more layered than most compliance teams realise. The California Civil Rights Council's Employment Regulations Regarding Automated-Decision Systems (ADS) took effect on October 1, 2025, prohibiting the use of AI screening tools that produce discriminatory outcomes and requiring anti-bias testing and four years of record retention. Separately, the California Privacy Protection Agency has finalised automated decision-making technology regulations under the CCPA (California Consumer Privacy Act) — requiring pre-use notice to job applicants and risk assessments before AI is used in hiring decisions — with compliance required by January 1, 2027.

China — Shanghai Office

The Personal Information Protection Law (PIPL) requires a lawful basis for processing applicant data, separate consent before sharing that data with a third-party vendor, and a personal information protection impact assessment before any automated decision-making system is deployed. CV data that flows from Shanghai to a vendor's servers — or to HQ in Taipei for centralised processing — is a cross-border transfer that requires a lawful mechanism under Chinese law.

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.

第一節 — 一個決策，四個司法管轄區

需求來自人資部門主管。這家台灣總部的科技製造商，在柏林、上海和洛杉磯設有區域辦公室，正深陷求職申請的汪洋之中。兩年內，申請量暴增三倍。招募團隊不堪負荷。一家供應商示範了一套AI驅動的篩選工具——能夠讀取履歷、依據職缺條件為應徵者評分，並產出排名候選名單，且可直接整合現有的應徵者追蹤系統。定價合理，Demo令人印象深刻。

提案內容是：全球統一部署，涵蓋四個據點，使用單一平台。標準化流程，節省人力，讓招募更快速、更一致。

這是一個合理的商業決策。然而，若法務與合規部門未能在採購單簽核前介入，這個決策也將同時觸發四套截然不同的監管體系——各自有不同的要求、不同的時間表，以及不同的違規後果。

台灣 — 總部

公司總部所在地，人事流程的設計與管理均在此進行，《個人資料保護法》(Personal Data Protection Act, PDPA) 規範著應徵者資料的蒐集、使用與保存。《人工智慧基本法》(AI Basic Act) 草案仍在立法審查程序中，但現行個資法對於個人資料的自動化處理，無論AI專項法規是否到位，均已適用。

歐盟 — 柏林辦公室

兩套框架同時適用。《通用資料保護規則》(General Data Protection Regulation, GDPR) 對於會對個人產生重大影響的自動化決策設有限制——以自動化方式篩選履歷、決定應徵者是否晉級或遭到淘汰，正是其起草者所預設的情境。《歐盟人工智慧法》(EU AI Act) 依據附件三明確將用於篩選求職申請及評估應徵者的AI系統列為高風險，已於2025年2月起禁止特定做法，並將於2026年8月對部署者建立完整的合規框架。

加州 — 洛杉磯辦公室

法規現況比多數合規團隊所認知的更為複雜。加州公民權利委員會《自動化決策系統就業規定》(Employment Regulations Regarding Automated-Decision Systems) 已於2025年10月1日生效，禁止使用會產生歧視性結果的AI篩選工具，並要求進行偏差測試及保存四年相關記錄。另一方面，加州隱私保護局依《加州消費者隱私法》(California Consumer Privacy Act, CCPA) 制定的自動化決策技術規定，要求在以AI輔助招募決策前須向求職者發出預先告知，並於使用前進行風險評估，合規期限為2027年1月1日。

中國 — 上海辦公室

《個人信息保護法》(Personal Information Protection Law, PIPL) 要求處理應徵者資料須具備合法依據，在將資料提供給第三方供應商前須取得單獨同意，且在部署任何自動化決策系統前須進行個人信息保護影響評估。從上海傳輸至供應商伺服器或台北總部進行集中處理的履歷資料，屬於跨境傳輸，在中國法律下須具備合法機制。

供應商的Demo對上述任何一點隻字未提。提案將這視為單一採購決策，但它並非如此。這是四個合規問題同時到來，各自帶著截止期限、義務，以及不同的違規後果。

問題不在於是否要在招募中使用AI，而在於組織是否已做好準備，在每個業務所及的司法管轄區合法使用它。

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.

DATA
PRIV

The data privacy layer

Each jurisdiction where applicants are located imposes its own obligations on how their personal data is collected, processed, retained, and transferred. The lawful basis for processing applicant data is not uniform across Taiwan, the EU, California, and China. The restrictions on automated decision-making differ materially. The cross-border transfer obligations are substantive and in some cases require mechanisms that take time to put in place. The retention and deletion obligations for applicant data that never converts to employee data vary across all four jurisdictions. None of this is resolved by clicking through the vendor's data processing agreement.

AI
GOV

The AI governance layer

The EU AI Act explicitly classifies AI systems used to filter job applications and evaluate candidates as high-risk — not aspirationally, but as a matter of law, with obligations that apply to the company as deployer regardless of what the vendor provides. California now has two overlapping frameworks governing the use of automated decision-making in employment. China's obligations arrive through a layered set of instruments covering generative AI services, algorithm transparency, content labelling, and the PIPL's own impact assessment requirement. Taiwan's framework is still developing, but existing obligations already apply.

DATA
GOV

The data governance layer

This is where both of the above frameworks either become achievable or remain aspirational. A single centralised screening platform means applicant data from four jurisdictions is flowing somewhere — to a vendor's servers, to a regional hub, to headquarters — and being processed by a system that the company did not build and does not fully control. Before a single privacy obligation or AI governance requirement can be satisfied, the organisation needs answers to questions that are fundamentally architectural: Where does applicant data sit? Who controls it? What can the vendor do with it, including using it to train their model? These are not questions that compliance answers after procurement. They are questions that governance must answer before the contract is signed.

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.

第二節 — 三個框架，一個問題

人資部門主管將這件事定性為採購決策。法務團隊若有介入，可能會將其定性為資料隱私審查。兩種定性都不完整。

在四個司法管轄區同步部署AI篩選工具，將同時觸發三個截然不同的合規框架——而這三者之間的關係並非依序推進。這不是先滿足隱私法要求、再處理AI治理、最後才釐清資料架構的問題。三個框架是同步並行的，其中任何一個框架的決策，都會直接制約其他框架的可行選項。

資料
隱私

資料隱私層面

應徵者所在的每個司法管轄區，均對其個人資料的蒐集、處理、保存與傳輸設有各自的義務。在台灣、歐盟、加州和中國之間，處理應徵者資料的合法依據並不一致。自動化決策的限制存在實質差異。跨境傳輸義務內容實質，且在某些情況下需要提前建立機制。未能轉為員工的應徵者資料，其保存與刪除義務在四個司法管轄區各有不同。這些問題，無法靠點擊供應商的資料處理協議同意鍵來解決。

AI
治理

AI治理層面

《歐盟人工智慧法》(EU AI Act) 明確將用於篩選求職申請及評估應徵者的AI系統列為高風險——這不是期待中的分類，而是法律規定，對部署公司產生的義務，無論供應商提供什麼都一樣適用。加州現有兩套針對就業自動化決策的相互交疊框架。中國的義務透過多層次的法規呈現，涵蓋生成式AI服務、演算法透明度、內容標示，以及PIPL本身的影響評估要求。台灣的框架仍在發展中，但現有義務已然適用。

資料
治理

資料治理層面

這決定了上述兩個框架是否真正可行，還是只停留在理想層次。單一集中式篩選平台，意味著來自四個司法管轄區的應徵者資料流向某處——供應商的伺服器、區域樞紐、或總部——並由一套公司未曾建置、也未完全掌控的系統加以處理。在能夠滿足任何一項隱私義務或AI治理要求之前，組織必須先回答一些本質上屬於架構層面的問題：應徵者資料究竟存放在哪裡？誰能控制它？供應商可以用它做什麼，包括用它訓練模型？這些問題不是採購後由合規部門回答的，而是治理機制必須在合約簽署前回答的問題。

三個框架並非各自獨立。一個資料治理決策——將所有應徵者資料集中於單一供應商平台——可能同時在PIPL下產生跨境傳輸問題，在GDPR下形成須簽訂資料處理協議的控制者—處理者關係，以及產生評估該供應商是否符合《歐盟人工智慧法》技術文件與符合性評估要求的義務。只解決其中一個而不顧其他，會產生一個文件上看似完整、實際上脆弱不堪的合規計畫。

以下將逐一深入探討這三個層面——在本情境中各有哪些要求、義務最為迫切的環節，以及組織在平台上線前需要建立什麼。

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.

第三節 — 各司法管轄區的資料隱私義務

資料隱私法不問企業是否有意蒐集個人資料，它問的是：蒐集了什麼個人資料、依據什麼理由、為了什麼目的、資料流向何處、保存了多久。AI篩選工具回答了這五個問題——在本情境中，它對每個應徵者所在的司法管轄區各回答一遍，共回答四次。

台灣、歐盟、加州和中國的義務並不相同。它們匯聚於同一底層邏輯——應徵者對其個人資料擁有權利，這些權利不會因為是演算法在進行處理而消失——但在具體要求上存在實質差異。以下並非詳盡的法規目錄，而是摩擦點的分布圖。

台灣——總部所在的司法管轄區

台灣總部在這件事中並非被動角色。平台很可能在此地管理，供應商關係在此地維護，來自多個地點的應徵者資料也在此地匯聚進行集中處理。台灣《個人資料保護法》(Personal Data Protection Act, PDPA) 適用於在台灣設立之公司對個人資料的蒐集、處理與利用，無論應徵者身處何地，總部對應徵者資料的處理均受其規範。

個資法要求蒐集個人資料須有特定目的，使用範圍限於該目的，並設有安全、保存與跨境傳輸義務。就應徵者資料而言，蒐集必須符合比例原則——透過篩選工具蒐集的資料，必須確實是評估應徵者所必要的，而非工具所能讀取的一切內容。台灣《人工智慧基本法》(AI Basic Act) 草案仍在立法程序中，但這並不形成現行義務的空白：個資法對個人資料的自動化處理，無論AI專項法規是否已到位，均已適用。

作為總部所在的司法管轄區，台灣也承擔著治理架構的責任——關於平台設計、供應商選擇和資料流向的決策，決定了其他每個司法管轄區的義務能否得到滿足。

歐盟——合規要求最高的司法管轄區

柏林辦公室負責整個歐洲業務的職缺招募。在該流程中提交履歷的每一位應徵者，其個人資料從蒐集之時起即受《通用資料保護規則》(General Data Protection Regulation, GDPR) 規範。

合法依據是第一道門檻。多數符合GDPR的招募資料處理，依賴第6條第1項第(b)款——履行合約所必要的處理。但這一依據有其限制：它涵蓋的是特定招募決策真正必要的處理，不涵蓋推測性的資料蒐集、將遭拒應徵者的資料保留超過特定招募周期，或使用應徵者資料訓練或改善AI模型。上述每項活動均需各自的合法依據。

第22條的自動化決策限制，是第二道、也是在操作上更為關鍵的門檻。GDPR賦予個人不受純粹自動化處理所作決定拘束的權利，GDPR序言第71條明確將未經人工介入的電子招募行為列舉為「類似重大影響」的例子。最具可辯護性的設計是：確保一位具備實質決策權限的人員，在任何影響應徵者的決定最終確定之前，審查工具的輸出結果並有權推翻它。

當應徵者資料離開歐盟——傳輸至歐洲經濟區以外的供應商伺服器，或傳輸至台灣總部進行集中處理——就需要傳輸機制。標準合約條款必須輔以傳輸影響評估。在部署高風險處理活動前，資料保護影響評估（DPIA）亦為強制性要求。

加州——兩套框架，一個合規計畫

加州的法規現況比多數合規團隊所認知的更為複雜，且已生效的部分也比許多人預期的更多。

加州公民權利委員會《自動化決策系統就業規定》(Employment Regulations Regarding Automated-Decision Systems) 依據《公平就業與住房法》(Fair Employment and Housing Act, FEHA) 已於2025年10月1日生效，釐清了FEHA如何適用於招募中使用的AI工具。實際義務包括偏差測試、保存ADS相關資料至少四年，以及明確禁止使用任何產生歧視性結果的ADS——無論是否出於故意，差別影響即已足夠。責任可延伸至供應商。

另一方面，加州隱私保護局 (California Privacy Protection Agency, CPPA) 依《加州消費者隱私法》(CCPA) 制定的自動化決策技術規定於2025年7月定案，要求發出預先告知、賦予求職者拒絕自動化決策的權利，並在部署前進行風險評估，合規期限為2027年1月1日。

有一點值得留意：川普政府於2025年12月頒布的AI治理行政命令，代表聯邦層面試圖挑戰州級AI法規的努力。國會的聯邦優先立法嘗試迄今均已失敗，相關規定目前仍有效施行。由於FEHA的AI規定是延伸適用既有民權法，其法律基礎比獨立的AI專項法規更為穩固。組織應持續追蹤聯邦動態，但不應將聯邦優先立法問題的不確定性，作為推遲遵守目前已生效義務的理由。

中國——同意、影響評估，以及跨境傳輸

上海辦公室在當地自行招募。這意味著應徵者資料在中國境內蒐集、在中國境內處理——若平台採集中式管理，還將從中國境內向外傳輸。上述每個環節均涉及《個人信息保護法》(Personal Information Protection Law, PIPL)。

依據PIPL處理應徵者資料的合法依據，最自然的選擇是合約必要性——依據第13條，為執行人力資源管理所必要的處理是明確的合法依據。但這一依據並不延伸至AI輔助篩選所涉及的所有活動。依據第23條，將應徵者資料提供給第三方供應商須取得單獨同意。若篩選工具會分析視訊面試、語音語調或面部表情，則處理生物特徵識別資訊屬於敏感個人信息，依據第28、29條須取得明確同意。

在部署任何使用個人信息的自動化決策系統前，PIPL要求進行個人信息保護影響評估（PIIA）。這不是換了名稱的GDPR DPIA——它有自己的必要內容、自己的文件要求，以及保存記錄至少三年的義務。因GDPR目的進行了DPIA就認為已滿足PIPL要求的公司，尚未完成分析。

跨境傳輸是平台架構直接成為法律問題的環節。若上海應徵者資料流向中國境外，該傳輸在中國法律下須具備合法機制——向有關機關備案的個人信息出境標準合約、針對較大量傳輸由網信辦進行的安全評估，或認證。這些機制均無法在上線當下到位。在簽署供應商合約後才發現這項要求的公司，面臨的選擇是要麼推遲上線，要麼在違反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.

第四節 — AI治理義務

資料隱私法告訴公司如何處理應徵者資料；AI治理法則告訴公司篩選工具本身應具備什麼條件，以及公司作為部署該工具的組織，負有哪些確保責任。兩者相關但有所區別。一套滿足所有資料隱私要求的工具，仍可能不符合AI治理框架的規定。而承擔AI治理義務的主體，在多數司法管轄區並非建置工具的供應商——而是選擇使用它的公司。

歐盟——依法列為高風險，無需自行評估

《歐盟人工智慧法》(EU AI Act) 不要求公司自行評估其招募AI是否屬於高風險，它已做出這一認定。依據該法附件三，用於分析、篩選求職申請及評估應徵者的AI系統被明確列為高風險。這一分類適用於柏林辦公室使用該篩選工具的情形，無論供應商如何描述產品、如何界定其在決策中的角色，或人工審查層面多麼健全。高風險是一個法律類別，不是風險評分。

這一分類所衍生的義務，同時落在供應商（作為提供者）和公司（作為部署者）身上，且無法透過合約完全轉嫁給對方。部署者必須進行自身的基本權利影響評估、建立人工監督機制、監控系統運作、向受影響的應徵者提供透明說明，並確保員工具備足夠的AI素養以有效監督工具的使用。

有兩項義務已經生效，無法等待2026年8月的期限。特定做法自2025年2月起已被全面禁止：就業情境中的情緒辨識，以及依據外貌特徵推斷受保護特徵的生物特徵分類系統。任何在視訊面試中分析面部表情、從語音語調評估情緒狀態、或從生物特徵信號推斷人格特質的供應商功能，現在就必須停用。AI素養義務同樣自2025年2月起適用——使用或監督高風險AI系統的員工，必須充分了解這些系統的運作方式、可能的失誤之處，以及何時應推翻其輸出結果。

境外適用的面向至關重要：《歐盟人工智慧法》適用於在歐盟境內使用其輸出結果的任何情形。一套由台灣總部管理、處理柏林職缺申請的篩選平台，無論平台託管地點或供應商所在地為何，均在其適用範圍內。

加州——反歧視法遇上演算法問責

加州的兩套框架匯聚於同一原則：在招募中部署AI工具，不能將對工具輸出結果的責任，或其失誤的法律責任轉嫁給供應商。

《公平就業與住房法》(Fair Employment and Housing Act, FEHA) 規定確立了：自動化決策系統的歧視性結果在加州民權法下屬於違法行為——包括並非出於故意歧視、但對受保護群體產生差別影響的結果。一套AI篩選工具若透過代理變數與種族、性別、國籍、身心障礙或其他受保護類別相關，即可能構成FEHA違規。與身心障礙相關的就業空缺。與種族相關的學歷院校。與國籍相關的地址模式。這些都是偏差稽核旨在發現的代理因素，其存在於訓練資料中，是雇主的合規問題，而非僅是供應商的問題。

CPPA的自動化決策技術規定增加了部署前風險評估、預先告知，以及求職者的拒絕權。拒絕權引發了一個架構問題：若求職者行使該權利，公司是否備有替代的非自動化處理流程？

FEHA規定在民權法的數十年法律基礎上建立，目前仍有效施行。對目前有效施行的法規不合規，其訴訟風險，比對一項日後可能被縮限的法規合規，更為直接且迫切。

中國——多項法規構成的多層次義務

中國針對招募工具的AI治理義務，透過多項法規而非單一法規呈現。

若篩選工具使用大型語言模型來解析履歷、生成應徵者資料摘要或產出評分說明，則《生成式人工智慧服務管理暫行辦法》(Interim Measures for the Administration of Generative Artificial Intelligence Services)適用。《互聯網信息服務算法推薦管理規定》(Administrative Provisions on Recommendation Algorithms in Internet-based Information Services) 要求受影響者能夠了解演算法的作用——直接適用於對求職者進行評分和排名的工具。已於2025年9月成為強制性國家標準的AI生成內容標示要求，規定向招募人員或應徵者呈現的任何AI生成的應徵者資料摘要、評估敘述或評分說明，均須標明為AI生成輸出結果。

自2026年1月1日起生效的《網路安全法》(Cybersecurity Law, CSL) 修正案，首次將AI明確納入中國國家法律框架，強化了AI治理義務與《個人信息保護法》(PIPL) 及《數據安全法》(Data Security Law, DSL) 的整合。全面性AI法律在中國2025年立法議程中仍付之闕如——但這在實務上意味著的不是義務減少，而是複雜度增加：義務分散在由不同機構管理的多項法規中。

所有這一切之下，是PIPL個人信息保護影響評估要求——它同時作為資料隱私義務和AI治理工具發揮作用，必須專門評估自動化決策系統的風險，且無法以GDPR DPIA或CPPA風險評估替代。

台灣——現行義務已然存在，框架仍在成形

台灣《人工智慧基本法》(AI Basic Act) 草案仍在立法程序中。個資法對招募中個人資料自動化處理的現行義務已然適用，且草案法律的方向清楚表明，影響評估、透明度和人工監督要求即將到來。現在就將這些納入平台設計的公司，等到AI基本法通過時不需要進行改造。

部署者責任的落差

在所有四個司法管轄區，一個一致的規律正在浮現：部署工具的公司承擔著獨立的治理義務，這些義務無法透過合約轉嫁給供應商。

依據《歐盟人工智慧法》，部署者的基本權利影響評估、人工監督機制和員工AI素養義務，是部署者的責任，無論供應商提供什麼、合約如何約定，均不例外。依據加州FEHA規定，雇主無法以指向供應商來逃脫責任。依據PIPL，公司仍須負責確保處理活動的合法性，並監督處理者的活動。

一家供應商提供了技術能力完備的系統、一份資料處理協議，以及一套服務條款，這並未履行部署公司的治理義務，而只是為履行這些義務提供了輸入要素。剩餘的合規工作——影響評估、偏差稽核、人工監督設計、面向應徵者的告知、持續監控——屬於決定使用該工具的公司。

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.

第五節 — 資料治理基礎

第三節和第四節描述了法律的要求。本節描述組織需要建立什麼，才能滿足這些要求——以及為何對多數公司而言，資料治理工作是決定合規計畫是否真實可行、還是僅停留於文件記錄的關鍵路徑。

資料治理不是合規交付物，而是讓合規成為可能的運營基礎設施。在跨國AI招募篩選平台的情境下，它回答的是隱私法和AI治理法所預設已解決的問題：應徵者資料究竟流向哪裡？誰能控制它？供應商可以用它做什麼？平台架構是否能讓各司法管轄區的法律義務同時得到滿足？這些問題的答案，不在供應商的隱私政策裡。

採購前先確立資料架構

在本情境中，影響最深遠的資料治理決策，往往是公司在不知不覺中就已做出的那個：採用全集中式平台架構。

一套由台灣總部管理、接收來自柏林、上海和洛杉磯應徵者資料的統一平台，同時製造了四個跨境資料流問題。上海應徵者資料流向集中式系統，在第一場面試尚未安排之前，就已觸發《個人信息保護法》(PIPL) 的跨境傳輸要求。歐盟應徵者資料流出歐洲經濟區，需要在《通用資料保護規則》(GDPR) 下具備傳輸機制和傳輸影響評估。供應商本身的資料存放地點，決定了以現有架構能否滿足傳輸義務。

這些問題都無法在上線當下回答。選定供應商、簽署合約後才開始進行資料治理分析的公司，工作順序錯了。架構問題必須在採購前解決，而非在實施過程中。

值得評估的替代方案是模組化架構：一套共用工具搭配各司法管轄區的專屬配置，歐盟和中國業務採用獨立的資料環境，並以與各司法管轄區可用傳輸機制相符的方式明確界定資料流向。這種設計以部分運營效率換取大幅降低的跨境傳輸風險，以及更易於記錄和辯護的合規計畫。

以資料最小化作為治理工具

一份履歷所含的資訊，遠不止篩選標準。出生日期。家庭地址。可能與身心障礙、照顧責任或服役經歷相關的就業空缺。可能與種族或社經背景相關的學歷院校。個人照片中可見的外貌特徵。從寫作風格推斷的人格特質。

讀取原始履歷的AI篩選工具，會讀取這一切——而且多數工具正是被設計來提取和加權這類信號，因為它們與歷史招募資料中的規律相關。在讀取點進行資料最小化——明確界定工具接收什麼資料、以何種形式接收、經過何種前處理——是一項同時回應隱私義務、AI治理義務和偏差風險的資料治理控制措施。

治理框架必須界定工具接收什麼。供應商合約必須約束工具對資料的使用。兩者都不會自動發生。

供應商治理——合約作為合規工具

AI篩選工具是一個第三方處理者，同時接收來自四個司法管轄區的個人資料、管理一套《歐盟人工智慧法》列為高風險的系統，並產出對被評估應徵者具有法律後果的輸出結果。附著於這層關係的治理義務，無法靠一份標準資料處理協議來履行。

供應商合約必須處理：是否明確禁止使用應徵者資料訓練或改善模型；與各司法管轄區要求一致的資料保存和刪除義務；與所依賴傳輸機制相符的資料存放規範；《歐盟人工智慧法》技術文件和稽核查閱義務；PIPL處理者義務；加州FEHA供應商責任條款；以及合約終止時應徵者資料的處理規定。

無法回答文件問題、不願提供技術規格、或提供的資料處理協議未能處理跨境傳輸義務的供應商，是一個無法支持合規全球部署的供應商。在供應商選擇階段發現這一點需要付出時間；在上線後才發現，代價要高得多。

影響評估——三個司法管轄區，三份不同文件

《歐盟人工智慧法》要求部署者進行基本權利影響評估。GDPR要求在部署高風險處理活動前進行DPIA。PIPL要求在部署任何自動化決策系統前進行個人信息保護影響評估（PIIA）。加州CPPA (California Privacy Protection Agency) 規定要求在部署前進行風險評估。

這些不是同一份文件。進行了GDPR DPIA就認為已滿足PIPL PIIA要求，或將兩者合併為一份以《歐盟人工智慧法》基本權利評估為框架的文件，可能產生一份實際上未能完整滿足其中任何一項要求的文件。

關鍵是，這些評估並非一次性工作。一次平台上線若擴展至新地區、增加新篩選標準，或升級至新版本模型，可能同時觸發多個司法管轄區的重新評估義務。

記錄、日誌與稽核記錄

《歐盟人工智慧法》要求高風險AI系統維護日誌，足以支持事後審查和監管調查。加州FEHA規定要求保存ADS相關資料至少四年，包括輸入資料、輸出結果、決策標準和稽核結果。PIPL要求影響評估記錄保存至少三年。GDPR要求記錄處理活動及DPIA文件。

上述每一項保存義務，都要求平台實際產生相關記錄，並以可查閱、在必要時按司法管轄區分別存放且具可辯護性的方式加以儲存。這是基礎設施設計，而非文件工作——必須在平台配置前加以規範。

單一平台問題的再思考

集中式平台帶來運營效率，同時也製造了一個必須同時滿足所有司法管轄區最嚴苛要求的單一節點——以及若任何一個要求未能滿足，就成為單點失效的風險。

資料治理分析或許得出結論，認為統一平台是可行的——但這一結論需要證據支撐，而非假設。它也可能得出結論，認為各司法管轄區的要求與單一集中式架構確實不相容。在這種情況下，治理分析完成了其使命：它在合約簽署前識別了制約條件，此時架構仍可調整。

這就是資料治理的意義——不是產生一份描述合規計畫的文件，而是回答決定合規計畫能否實現的架構問題。

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.

Map the data flows before you evaluate the vendors

Before a vendor is assessed, before a demo is scheduled, the organisation needs a clear picture of what happens to applicant data in the proposed deployment model. Where does data originate? Where does it go? In what form? What does the vendor do with it — process it, store it, train on it? When is it deleted?

This data flow map is the foundation for every subsequent analysis. The PIPL transfer mechanism analysis cannot be done without it. The GDPR transfer impact assessment cannot be done without it. The vendor contract cannot be drafted without it. A vendor that cannot or will not specify where data is stored, how long it is retained, and whether it is used for model training is not a vendor that can support a compliant deployment.

Assess vendors as high-risk AI deployers, not just data processors

Vendor due diligence in this context has two distinct dimensions that are frequently conflated. The first is the data processor assessment — the standard privacy due diligence. The second is the AI governance assessment — and this is where most companies have significant gaps.

For EU deployment, the deploying company is entitled to ask — and should require as a condition of procurement — for the technical documentation the EU AI Act mandates providers to maintain, the risk management system documentation, evidence of conformity assessment, the system's logging architecture, and the vendor's timeline for CE marking. For California deployment, the assessment should include the vendor's bias testing methodology: what was tested, when, against what demographic groups, with what results, and what corrective actions were taken.

These two assessments should be conducted before vendor selection is finalised — not as a post-selection compliance exercise, but as a procurement criterion.

Conduct the jurisdiction-specific impact assessments before configuration

The GDPR DPIA, the PIPL PIIA, and the CPPA risk assessment are pre-deployment obligations. They are designed to inform the design of a system that has not yet been deployed — to identify risks before they materialise. Conducting these assessments after the platform is configured means conducting them in a context where the architecture, the vendor, and the data flows have already been determined. The assessment then functions as a documentation exercise rather than a design input — and regulators reviewing the document will be able to see the difference.

The EU AI Act's fundamental rights impact assessment is a fourth document that should be developed in parallel. It informs and is informed by the GDPR DPIA — but it cannot be substituted by it.

Build human review into the architecture by design

Human oversight is not a compliance add-on. Under GDPR Article 22, the most defensible design is one where a human being with genuine decision-making authority reviews the tool's output before any consequential action is taken. Under the EU AI Act, meaningful human oversight is a mandatory requirement for high-risk systems. Under California's FEHA regulations, meaningful human involvement is what determines whether the employer can demonstrate algorithmic accountability.

But human oversight must be genuine to function as a compliance control. A process in which a recruiter clicks through an AI-generated ranked list without reviewing the scoring rationale, the underlying data, or the rejected candidates' profiles is not meaningful human oversight. Designing genuine human oversight means specifying what the reviewer sees, what they are expected to evaluate, what authority they have to override the tool's output, and how their decision is documented.

Draft the applicant-facing notices before launch

Transparency obligations exist in all four jurisdictions, and they are not satisfied by a generic privacy notice buried in the application portal's terms and conditions. GDPR Articles 13 and 14 require applicants to be informed at the point of collection of the legal basis for processing, the purposes for which their data will be used, whether automated decision-making will be applied and what logic is involved, and their rights including the right to human review. The EU AI Act adds an obligation to inform individuals when a high-risk AI system is being used in a process that affects them. California's CPPA regulations require a pre-use notice. China's algorithm transparency requirements mean applicants must be able to understand the algorithm's role in decisions affecting them.

These notices are not interchangeable. The notices need to be drafted jurisdiction by jurisdiction, reviewed for legal sufficiency in each jurisdiction, and built into the applicant-facing experience before the platform launches.

Review the vendor contract as a governance instrument, not a procurement formality

The vendor contract determines, in legally binding terms, what the vendor can do with applicant data from four jurisdictions, how compliance obligations are allocated between the parties, and what happens when something goes wrong. At minimum, the contract should address: explicit prohibition on using applicant data to train or improve the vendor's model without separate consent; jurisdiction-specific data retention and deletion obligations; clear data residency specifications consistent with the transfer mechanisms being relied upon; EU AI Act technical documentation and audit access; PIPL processor obligations including supervision rights; California FEHA vendor liability provisions; and provisions governing applicant data if the contract ends.

The cross-border transfer mechanisms — GDPR standard contractual clauses, PIPL standard contract for cross-border transfers — are legal instruments that must be executed as part of the contractual package, not referenced and executed later.

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.

The sequence matters because each step informs the next. A company that starts at Step 6 and works backwards will produce a compliance programme that is coherent on paper and fragile under scrutiny. A company that starts at Step 1 and works through the sequence will have done the governance work that makes the compliance programme real.

第六節 — 簽約前，好的準備應該是什麼樣子

發現合規問題最昂貴的地方，是在部署之後。供應商合約已簽。平台已上線。來自上海的應徵者資料，正流向法務團隊從未審查過的伺服器。柏林的招募團隊，在沒有人工審查層的情況下發送著自動拒絕通知。沒有人進行過DPIA。偏差稽核沒有安排，因為沒有人知道這是必要的。

這不是假設情境，而是將全球AI工具上線視為採購決策而非治理工作時的預設結果。

以下並非一份清單，而是一個順序——工作需要發生的次序，以及為何順序本身和各個步驟同樣重要。

在評估供應商之前，先梳理資料流向

在評估任何供應商之前、在安排任何示範之前，組織需要清楚了解應徵者資料在擬議部署模式下將發生什麼。資料源自何處？流向哪裡？以何種形式？供應商對資料做什麼——處理、儲存、還是用於訓練？何時刪除？

這份資料流向圖，是所有後續分析的基礎。沒有它，PIPL傳輸機制分析無從進行。沒有它，GDPR傳輸影響評估無從進行。沒有它，供應商合約無從草擬。一個無法或不願說明資料存放地點、保存期限，以及是否用於模型訓練的供應商，無法支持合規部署。

以高風險AI部署者的標準評估供應商，而非僅作為資料處理者

本情境中的供應商盡職調查，涵蓋兩個截然不同的面向。第一個是資料處理者評估——標準隱私盡職調查。第二個是AI治理評估——而這正是多數公司存在重大缺口的地方。

針對歐盟部署，部署公司有權要求——且應將其作為採購條件——供應商提供《歐盟人工智慧法》(EU AI Act) 規定的技術文件、風險管理系統文件、符合性評估的證據、系統日誌架構，以及CE標誌取得時間表。針對加州部署，評估應包括供應商的偏差測試方法論：測試了什麼、何時進行、針對哪些族裔群體、結果如何，以及採取了哪些糾正措施。

這兩項評估應在供應商選擇最終確定之前進行——不是作為選擇後的合規工作，而是作為採購標準。

在配置前進行各司法管轄區的影響評估

GDPR DPIA、PIPL個人信息保護影響評估，以及CPPA (California Privacy Protection Agency) 風險評估，均是部署前的義務。它們的設計目的是為尚未部署的系統設計提供參考——在風險發生前識別它們。在平台配置完成後才進行這些評估，評估於是成為文件工作，而非設計輸入——審查文件的監管機構將能看出其中的差異。

《歐盟人工智慧法》要求部署者針對高風險系統進行的基本權利影響評估，是應並行開展的第四份文件——它與GDPR DPIA相互參照，但無法以後者替代。

將人工審查設計進架構，而非事後添加

人工監督不是合規附加項目。依據GDPR第22條，最具可辯護性的設計，是在任何後果性行動最終確定之前，由具備實質決策權限的人員審查工具的輸出結果。依據《歐盟人工智慧法》，有意義的人工監督是高風險系統的強制要求。依據加州FEHA規定，有意義的人工參與是雇主能否展現演算法問責的關鍵。

但人工監督必須是確實的，才能作為合規控制措施發揮作用。招募人員逐一點擊AI生成的排名名單、卻未審查評分說明、底層資料或遭拒應徵者的個人資料——這不是有意義的人工監督。設計確實的人工監督，意味著明確規定審查人員看到什麼、預期評估什麼、有哪些權限推翻工具的輸出結果，以及其決定如何被記錄。

在上線前草擬面向應徵者的告知

四個司法管轄區均存在透明度義務，且這些義務無法靠埋在申請入口網站條款細則中的一份通用隱私聲明來履行。GDPR第13、14條要求在蒐集時告知應徵者：合法依據、處理目的、是否適用自動化決策及其邏輯，以及包括獲得人工審查的各項權利。《歐盟人工智慧法》增加了在高風險AI系統被用於影響個人程序時的告知義務。加州CPPA規定要求發出預先告知。中國演算法透明度要求意味著應徵者必須能夠了解演算法的作用。

這些告知不可互換。它們需要按司法管轄區逐一草擬、審查其法律充分性，並在平台上線前納入面向應徵者的使用體驗中。

將供應商合約視為治理工具，而非採購程序

供應商合約是以具有法律約束力的條款，確定供應商可以如何使用來自四個司法管轄區的應徵者資料的文件。合約至少應涵蓋：明確禁止在未取得另行同意的情況下使用應徵者資料訓練或改善模型；與各司法管轄區要求一致的資料保存和刪除義務；清晰、具有合約約束力且與所依賴傳輸機制相符的資料存放規範；《歐盟人工智慧法》技術文件和稽核查閱義務；PIPL處理者義務；加州FEHA供應商責任條款；以及合約終止時應徵者資料的處理規定。

跨境傳輸機制——GDPR標準合約條款、PIPL個人信息出境標準合約——是必須作為合約文件組成部分執行的法律文件，而非在合約中引用後再另行執行。

管理這一順序本身就是一項法務運營挑戰。六個相互依存的工作流程——資料流向梳理、供應商盡職調查、影響評估、人工監督設計、應徵者告知，以及合約談判——每一個都有外部依賴、內部利害關係人，以及作為下一步輸入的產出。在典型的採購周期中，時間表從兩端受到壓縮：業務方希望工具盡快上線，供應商希望合約盡快簽署，合規工作被擠壓到所剩的空間裡。成功部署AI篩選工具的組織，將部署前階段視為結構化專案：界定工作流程、指定負責人、明確依賴關係，以及在合約執行前設置一個通過/不通過關卡。這個關卡不是法律否決權——它是治理工作已充分完成、足以有把握而非帶著僥倖心理簽約的節點。建立和管理這一結構，是法務運營的工作，是將合規清單轉化為真正能夠運行的流程的關鍵。

最後，關於順序還有一點：供應商合約談判不應在資料流向圖、供應商盡職調查和影響評估框架尚未充分發展到足以指導合約內容之前開始。在治理工作完成前談判的合約將有所欠缺——而欠缺的條款，通常恰恰是在合規問題被認真追究時最為關鍵的那些。

順序至關重要，因為每一步都為下一步提供輸入。從步驟六倒推的公司，會產出一個文件上看似完整、在審查下卻脆弱不堪的合規計畫。從步驟一開始、按順序推進的公司，完成的治理工作，使合規計畫成為真實的。

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.

How CloudVista Can Help

CloudVista advises multinational companies on the intersection of data privacy, data and AI governance, and legal operations — the three practice areas this decision requires to work together.

If your organisation is considering deploying AI tools in recruitment or other employment decisions, we can help with:

›Data privacy advisory — assessing lawful basis, automated decision-making obligations, cross-border transfer mechanisms, and impact assessment requirements across the jurisdictions where you operate. Explore our Data Privacy practice →
›Data and AI governance — evaluating vendor AI governance readiness, designing human oversight frameworks, and building the compliance architecture that makes responsible AI deployment operationally achievable. Explore our Data & AI Governance practice →
›AI vendor assessment — structured due diligence on the privacy and AI governance posture of the tools your organisation is considering. Try our AI Vendor Assessment tool →

This article is for informational purposes only.

第七節 — 那個尚未做出的決策

人資部門主管依然面對同樣的問題。每週四百份履歷。一個不堪負荷的團隊。一家有著令人印象深刻Demo和合理定價的供應商。AI輔助招募篩選的商業理由是真實的，而且不會消失。

本文的論點不是不應該部署這套工具，而是在台灣、歐盟、加州和中國全球部署這一決策，從採購桌上看起來並非其表面所呈現的那樣。這同時是一個資料隱私決策、一個AI治理決策，以及一個資料架構決策——在部分司法管轄區已然生效、在其他司法管轄區快速到來的義務之中，同步做出。

成功部署這些工具的組織，不是行動最快的，而是最先完成治理工作的——在評估供應商之前先梳理資料流向、以高風險AI部署者而非資料處理者的標準評估供應商、在配置前進行影響評估、將人工監督設計進架構而非事後疊加，以及草擬能夠真正滿足各司法管轄區披露義務的面向應徵者告知。這些工作沒有一項複雜到難以完成，但全部都需要採購時間表通常不允許的時間——除非組織內有人了解需要做什麼，並確保以正確的順序完成。

這正是法務運營、資料隱私和AI治理匯聚於單一商業決策的地方。不是三個並行運作的獨立合規工作流程，而是對法律要求、架構所能實現的可能，以及組織在合約簽署前需要建立什麼的整合分析。

將這種匯聚視為優勢而非需要事後管理的複雜性的公司，是那些能夠在其業務所及的司法管轄區，以合法、有效且可辯護的方式部署AI工具的公司。

CloudVista 如何提供協助

CloudVista為跨國企業提供資料隱私、資料與AI治理，以及法務運營交匯處的顧問服務——本決策所需的三個實務領域協同運作。

若您的組織正在考慮在招募或其他就業決策中部署AI工具，我們可以在以下方面提供協助：

›資料隱私顧問 — 評估您業務所及司法管轄區的合法處理依據、自動化決策義務、跨境傳輸機制及影響評估要求。探索我們的資料隱私服務 →
›資料與AI治理 — 評估供應商的AI治理整備程度、設計人工監督框架，以及建立使負責任AI部署在運營上切實可行的合規架構。探索我們的資料與AI治理服務 →
›AI供應商評估 — 針對您的組織正在考慮的工具，進行結構化的隱私和AI治理盡職調查。試用我們的AI供應商評估工具 →

本文僅供參考，不構成法律建議。

別急著簽約：跨國企業導入AI招募篩選工具的跨境合規挑戰