人資資料可以用 AI API 處理嗎？履歷、薪資、考核資料的風險邊界
- 2天前
- 讀畢需時 8 分鐘
人資資料不是完全不能用 AI API，但完整履歷、薪資明細、考核紀錄與勞資爭議文件，不適合在沒有去識別化、權限控管與明確用途限制的情況下直接送進外部 AI API。
OpenAI、Anthropic、Google 都對商業 API 提供不同的資料使用與留存規則；台灣《個人資料保護法》與 GDPR 也都把可直接或間接識別個人的資料納入保護範圍，所以 HR 資料進 AI API，風險通常比一般客服、行銷或 SEO 內容更高。
很多企業導入 AI 時，人資部門往往是最早看到效率提升的單位之一。履歷初步整理、面試題目設計、教育訓練內容生成、制度說明改寫，這些都很適合用 AI 幫忙。但 HR 也是最容易踩線的部門之一，因為它日常接觸的不是一般內容，而是高度集中、可識別、且會直接影響員工權益 的資料。
先講結論：HR 資料最不該做的，不是用 AI，而是把原始資料直接丟進去
人資資料的關鍵，不在於能不能碰 AI，而在於是不是直接把原始資料送給外部模型處理。履歷、薪資、績效、獎懲、勞資爭議與在職紀錄，幾乎都同時具備三種特性：
有明確個資
常含敏感或高度私密資訊
可能影響錄用、升遷、薪酬或勞資關係
這和一般行銷文案、商品描述、FAQ 或公開知識整理完全不同。HR 場景一旦踩錯，通常不是只有資料外送風險，還會連動到信任、內部公平與勞動關係爭議。
為什麼 HR 資料風險特別高？重點不只是個資而已
幾乎全部都涉及可識別個人資料
履歷、員工主檔、應徵表單、薪資資料、請假紀錄，幾乎都直接包含姓名、電話、Email、地址、學經歷、身分資訊或可交叉識別內容。GDPR 對個人資料的定義包含可直接或間接識別；Google Gemini API 也明確提醒不要在可用於改進模型的 datasets 中放個人、敏感或機密資訊。
不只是個資，還常常牽涉敏感判斷資訊
HR 資料的特殊之處，在於它不只告訴你「這是誰」，還常常告訴你：
這個人值多少薪資
這個人表現好不好
這個人是否被懲處
這個人是否正在申訴或爭議中
這個人是否適合錄用或晉升
這類資料即使不一定都屬於法定特種個資，實務上仍然是高敏感資料。只要外流或被不當使用，傷害通常比一般聯絡資料更大。
會直接影響員工或求職者權益
客服資料送錯，可能是客訴。HR 資料送錯，可能直接變成：
招募公平爭議
內部歧視爭議
薪酬外洩
考核不透明
勞資爭議升高
所以 HR 用 AI 的問題，不只是資安，而是權益影響風險。
這篇最重要的分法：HR 資料不是一種，而是至少要分三級
這篇為了避免和你前面那些泛企業資料文章互打，我不再講大而廣的「哪些資料能不能送」，而是直接用 HR 專屬分級法 來看。
Level 3：高風險，不應直接送進外部 AI API
這一層通常包括：
完整履歷
薪資明細
績效評估原文
考核表
獎懲紀錄
勞資爭議文件
員工申訴內容
離職或資遣評估資料
為什麼這一層不適合直接送
因為這些資料通常同時有：
明確個資
高敏感資訊
對個人權益的直接影響
內部信任與勞動風險
這類資料若要進 AI，不應該是「直接上傳原文」的路線，而應先做資料轉換。
Level 2：中風險，只能在條件下使用
這一層通常包括：
去識別化履歷摘要
匿名考核趨勢
匿名薪酬區間分析
部門級人才流動統計
不含姓名與識別資訊的面談摘要
這一層真正的關鍵
不是「可以直接丟」，而是：
先去識別
先去掉關鍵欄位
先降到只保留必要資訊
只保留和當前任務有關的片段
這類資料可以讓 AI 幫忙，但前提是企業先把資料轉成較低風險形式。
Level 1：低風險，可作為 HR 優先導入 AI 的場景
這一層通常包括：
招募文案
面試題目
onboarding 說明
教育訓練內容
內部制度文件改寫
HR FAQ
通用職缺描述
為什麼這一層適合先導入
因為這些內容通常不需要員工原始資料，也不會直接碰到高敏感個資。這也是 HR 最適合先開始用 AI 的位置。
哪些 HR 場景比較適合用 AI API？哪些最好不要碰？
履歷初篩：可以做，但不該直接丟完整履歷
履歷初篩是很多 HR 第一個想到的 AI 應用，但真正安全的做法不是直接把完整履歷交給模型，而是先把資料轉換成：
去掉姓名與聯絡方式
去掉住址與個人識別欄位
只保留技能、經歷、職務需求對應資訊
這樣做的好處
仍可讓 AI 做初步比對
可降低識別風險
Token 也通常會下降，因為送進去的欄位更少
面試問題生成：相對安全
這類通常不需要帶員工原始資料。像是：
幫我設計產品經理面試題
幫我生成客服人員情境題
幫我整理工程師技術題方向
這些都屬於低風險、很適合先導入的 HR 用法。
薪資分析：不要用原始資料，改用匿名或區間資料
薪資本身不是不能分析，而是不能直接把完整薪資明細、姓名、職級、部門、年資全套一起送進外部 AI API。
比較穩的做法
改成：
區間資料
匿名統計
部門平均值
人數分布
不可回推個人的摘要
這樣仍然可以做 HR 分析，但風險低很多。
員工培訓與制度文件：很適合用 AI
這類內容通常不含特定個人的高度敏感資訊，HR 可以比較放心地用來：
生成教材
改寫制度說明
做新進員工 onboarding 文件
整理內部課程大綱
這類場景不只風險低，也很容易看出效率提升。
哪些 HR 使用方式絕對不建議？
這篇既然要做到不互打，我就不重講一般企業資料邊界，而只講 HR 專屬的不能碰區。
直接丟完整履歷
完整履歷通常同時含姓名、聯絡方式、學經歷、工作歷程與可識別資訊。這類資料不應直接丟進外部 AI API。
直接丟薪資資料
薪資本來就是內部高敏感資料。尤其和姓名、職級、部門綁在一起時，風險更高。
直接丟績效與考核資料
因為這類資料一旦外流或被誤用，會直接影響員工信任與管理正當性。
直接丟勞資糾紛文件
這類文件往往同時有高度敏感事實、個資與法律風險，絕對不適合拿來當一般 AI 測試素材。
HR 導入 AI，最容易犯的 5 個錯誤
第一，HR 直接把原始資料拿去問聊天版 AI
這是最常見的錯誤。很多風險不是因為 HR 惡意，而是因為覺得「只是先請 AI 幫我整理一下」。
第二，沒有先做 HR 資料分級
只要沒有分級，團隊就很難知道：
哪些可以直接用
哪些一定要轉換
哪些完全不能送
第三，用免費或一般版工具處理敏感資料
不同產品線的資料使用、保留與治理規則本來就不同。商業 API 與一般聊天產品不能混為一談。
第四，沒有 HR 專屬 AI 使用規範
企業即使有全公司 AI Policy，也常常不夠。因為 HR 的資料類型和風險就是和其他部門不一樣。
第五，沒有記錄誰用過、怎麼用
對 HR 這種高敏感資料部門來說，沒有基本操作紀錄和權限控管，後面很難管理。
企業要怎麼安全導入 HR × AI API？最務實的順序是這樣
先定義哪些 HR 場景可以先做
建議先從：
招募文案
面試題目
培訓內容
FAQ
制度說明
這些低風險場景開始。
再建立資料轉換流程
不要讓原始資料直接進模型，先走一層：
原始資料 → 去識別化 / 摘要化 → AI API
這是 HR 最需要的一道保護線。
再做權限控管
至少要清楚：
誰可以碰 HR AI 工具
誰可以上傳資料
誰可以看結果
哪些資料類型禁止送出
最後才考慮把 AI 用到中風險資料分析
例如匿名履歷摘要、匿名薪酬趨勢或匿名考核統計。不要一開始就直接碰完整履歷、薪資原文與績效原文。
Token 在 HR 場景裡要怎麼自然理解？
在 HR 場景裡，Token 不是只有費用問題，也是資料暴露範圍問題。
你送越多原始欄位、越長的履歷、越完整的考核與附件，Token 用量會變大，代表：
成本更高
傳出的資料更多
可識別性更強
logs / retention 風險也跟著增加
所以 HR 的正確思路不是「怎麼把更多資料交給 AI」，而是：
怎麼先把 HR 資料縮到必要範圍，再讓 AI 幫忙。
一句話總結
人資資料不是不能用 AI API，但完整履歷、薪資、考核與勞資爭議資料，不應在沒有去識別化、分級處理與權限控管的情況下直接送進外部模型。 HR 最適合先導入 AI 的，不是高敏感原始資料，而是招募文案、面試題目、培訓內容、制度說明與去識別化後的摘要型任務。只要先把資料邊界畫清楚，HR 其實可以用 AI，而且能用得比很多部門更有價值。
FAQ
履歷可以丟進 AI API 嗎？
完整履歷不建議直接丟。比較穩的做法是先去掉姓名、聯絡資訊與其他識別欄位，再處理成摘要版。
薪資資料可以用 AI 分析嗎？
可以做匿名或區間分析，但不建議把完整薪資明細與個人識別資料直接送進外部 AI API。
考核資料可以交給 AI 整理嗎？
原始考核與績效資料屬高風險內容，不建議直接處理。較安全的做法是改成匿名統計或摘要後再用。
小公司也需要控管 HR 資料和 AI 的使用嗎？
需要。風險不會因為公司規模小就消失，反而越小越需要先訂清楚規則。
HR 最安全的 AI 導入起點是什麼？
先從不含原始個資的場景開始，例如招募文案、面試題目、培訓教材與制度說明。
資料來源與可信度聲明
本文根據 OpenAI、Anthropic、Google 官方資料使用與留存政策，以及 GDPR 與企業資料治理原則整理撰寫，主要參考以下來源：
內容以「HR 資料特性 × 風險分級 × 可用邊界」三層方式整理，目的是幫企業把 HR 資料導入 AI API 這件事，看成一個部門專屬的資料邊界問題，而不是泛泛的 AI 合規問題。
想先看懂 企業 AI 導入與資料安全 這條主題線，建議先從這篇開始 企業內部資料可以用 AI API 嗎？導入前先看懂風險與邊界
本篇文章屬於《企業 AI 導入與資料安全》分類。
此分類主要整理企業在導入 AI API、AI 工具與模型平台前，最常碰到的資料治理、法務條款、採購風險、台灣企業實務問題與內部資料邊界，幫助法務、資訊、採購與管理層用同一套語言評估風險，而不是等到上線後才補漏洞。
留言