編輯筆記
唯一讀者：任職於台灣本國企業、正負責「招募系統＋多線進人」的 TA／人資營運負責人；需同時面對內部職缺釋出、用人主管、以及獵頭或 RPO 推單的協調者。
唯一場景：下一季有多個職缺與校招或專案型大量履歷同時湧入，高階管理層要求面試 SLAs 與可追溯評分，但 AI 初篩與舊有 ATS 步調不一致，導致同一候選人在兩邊出現不同狀態、報表對不起來。
主問題：如何把 AI 初篩與非同步面談變成 ATS 的「延伸管線」，而不是另一套雙寫的候選人池，讓企業 HR 能在台灣常見的勞基法實務與個資作業下，仍維持單一候選人主檔與審批軌跡。
三個驗收門檻（與失敗徵兆）：
單一身份鍵：用 email、手機或內部候選人 ID 能在各系統對到同一人。失敗徵兆：盤點名單時出現同姓名不同案號、或獵頭與內部投遞各算一次。
狀態可寫回：從初篩完成到用人主管可覆核，狀態在 ATS 可讀。失敗徵兆：用人主管在 ATS 仍顯示「新進履歷」，實則已在外部平台面完一輪。
題本可稽核：評分標準或題本變更能對應到職缺版本。失敗徵兆：出現勞資爭議或內部稽核要求時，只能說「當時面試官自己改的題」而無留痕。
三個踩雷反例：
- 先買初篩工具、半年後才開 ATS 欄位對照會，導致歷史資料永遠對不齊。
- 讓各廠獵頭以 Excel 丟人，不經主檔，年終報表上「到職人數」與實際留任數脫節。
- 把含影音或敏感備註的權限全開給實習生或外包，事後難以符合公司個資內規與職安／性平議題的內部調查需要。
讀者應採取的動作：在讀正文前，與專案贊助者（人資處主管或營運副總）共同確認上列三項門檻與你司現況的落差；責任角色：專案贊助者＋TA Lead；產出物：一頁的「主檔與邊界」共識備忘錄，作為導入專案 charter。
決策表：何時做深整合、何時只先做輕量銜接
下列決策表協助企業 HR 在台灣內部資源、獵頭條件與 ATS 成熟度之間做取捨（非產品推銷、亦非法律意見）。
| 適用情境 | 前置條件 | 主要風險 | 不適用時機 |
|---|---|---|---|
| 多職缺、內部與獵頭並行、需即時在 ATS 看進度 | 有 API 或中台、IT 與人資有固定窗口；主檔鍵定義已定案 | 變更管理負擔、測試環境與上線期程拉長 | 僅 1–2 個臨時職缺、無內部 IT 可支援，且年內不打算擴編 |
| 人資團隊小、先求快有「單一檔案夾」真相 | 匯出範本、週期對帳的責任人與週幾關帳日說清楚 | 狀態落後半日到數日、尖峰期易有抄錯 | 高流量校招、金融／上市櫃內控已要求系統層次軌跡 |
| 以獵頭為主導的關鍵職、仍要內部公平比較 | 合約內定義名單回寫方式、分潤爭點不影響主檔寫入 | 邊界糾紛導致停更候選人狀態 | 與供應商關係不穩、且無法在合約內要求資料格式 |
讀者應採取的動作：由 TA Lead 召開一次跨 IT、獵頭窗口（若有）、內部用人主管代表，勾選上表一列作為 90 天試點模式；責任角色：TA Lead；產出物：經簽核的「整合深度決策一頁紙」存於專案 folder。
釐清候選人主檔、狀態機與勞基法實務邊界
主檔是「人」的單一視圖；狀態機是「該人對該職缺／專案」的進度。兩者搞混時，年終報人頭、資遣前考核或留任專案會對不起來。台灣實務上，僱用與個資處理仍應內部與法遵顧問確認保存年限與刪除請求，本文不代為裁示。
讀者應採取的動作：畫一張從投遞到核薪／婉拒的最短合法路徑，標出哪些節點牽涉個資蒐集同意與內部簽核；責任角色：人資法遵或委外顧問（內部窗口）＋ TA Lead；產出物：帶欄位註解的狀態機初稿，附「非最終法解」之聲明供內部留存。
建立外部 ID 與寫回規則，消滅雙軌
不論是內部於徵才網投遞，或獵頭自管道推薦，進入公司評估體系時應盡快對齊同一候選人鍵。常見作法是 ATS 產生主檔 ID，初篩平台、獵頭報表帶上該 ID 或成對的 mapping table；寫回事件至少包含：初篩完成、分數帶、待用人主管覆核、退回補件。
讀者應採取的動作：寫一版「欄位對照與寫回觸發條件」規格，含錯誤重試及人工補單；責任角色：人資系統／MIS 管理員＋ TA；產出物：欄位對照表＋寫回事件 API／批次排程的技術手冊 v0.1。
設計權限與審批矩陣，讓覆核有名字
誰可看非同步面談影音、誰能改職等 評分標準、誰在 ATS 釋出錄用或啟動薪資審批，應在表上寫明。關鍵是「一個變更對應一責任主管」，避免只有「系統有紀錄」卻沒有真人承擔的灰色地帶。
讀者應採取的動作：用試算表做角色×資料類型（履歷、測驗、影音、分數、薪資意見）矩陣，並在 ATS 內實作對應角色群；責任角色：人資夥伴（HRBP）或內部控制窗口；產出物：簽核版權限矩陣＋在職訓練 10 分鐘版簡報。
維持 評分標準 與題本版本，銜接校招與常態職缺
同一份「工程師面試」在春節前後校招與社招若共用題本，版本混用會導致公平性爭議。改題或改權重時，應留下 changelog，並在 ATS 以職缺標籤或專案代碼綁定。用人主管的責任是確認職能對應，TA 的責任是讓系統上找得到那個版本。
讀者應採取的動作：定義職系－題本版號規則與凍結週；變更時由用人主管提需求、TA 在 ATS 與測評平台掛鉤；責任角色：用人主管（職能負責）＋ TA（流程與版號負責）；產出物：評分標準 變更單＋在系統內可搜尋的版號庫。
個資、保存與刪除：台灣實務上須內部對齊（非法律意見）
涉及影音、測驗分數、獵頭備註時，建議內部明定保存目的、地點、與刪除或匿名化請求之承辦序。職安法、性平工作平等法、以及個人資料保護法之適用，應以貴司法遵與顧問意見為準；本文僅提供人資作業上常與之並行的檢查點，不作為法律結論。
讀者應採取的動作：盤點候選人資料在 ATS、初篩、獵頭三邊的保存位置與責任人；責任角色：個資／法遵人員與人資處；產出物：內部草擬的「招募資料處理一覽表」與刪改申請 SOP 草案，供法遵審閱用。
上線前驗收與持續對帳
在正式讓內部與獵頭全面改用新流之前，以一小撮職缺做關帳實測：同一候選人走完整條，確認狀態、審批與 評分標準 版號在 ATS 端一致。之後用週期對帳表檢查 API 遺失筆數與欄位 null 比例。
讀者應採取的動作：訂 2 週的試營運期，列出必測劇本（內部投遞、獵頭推薦、婉拒、轉職內轉等）；責任角色：專案 PM（或在 HR 內的 Release owner）；產出物：go／no-go 簽到表＋上線後首月對帳儀表板截圖存證。
常見問題
以下為企業主與 HR 最常詢問的重點：
一定要 API 整合嗎？
不一定。少職缺試點可用匯出與欄位對照；職缺量大、內部／獵頭多線並行時，再以 API 或中台寫回狀態較能維持單一真相來源。
誰擁有候選人主檔？
通常以 ATS 或 HRIS 為權威來源；初篩平台應帶可追蹤的外部 ID 寫回，避免同一人多編號。獵頭推薦名單也應併入同一套對照規則。
狀態機要細到什麼程度？
至少能區分：已投遞、初篩中、待用人主管覆核、面談中、薪資／核決中、婉拒等；細分程度應與內部簽核與留用／資遣前流程討論一致，再請內控背書。
題本變更如何記錄？
評分標準 與題本須有版本號、生效日、負責人及變更摘要，並盡量與職缺、職系或校招專案綁定，以利事後說明。
與稽核就緒的關係？
ATS 治理是軌跡的一環；另需分數依據、覆核紀錄與權限日誌，與可稽核招募專文一併檢視。