HR 团队如何部署 AI 构建的应用，同时避免泄露员工数据

安全公司 RedAccess 搜寻了使用 AI 编程工具构建并发布在这些工具自有托管平台上的应用，发现超过 5,000 个应用几乎没有任何安全防护或身份验证。它向 Wired 提供的截图中，有一张似乎展示了某家医院的工作安排，其中包含医生的个人信息。

AI 编程工具让构建应用变得容易。面向 HR 团队的 AI 构建应用，其数据暴露问题出现在之后：休假跟踪器或面试评分表按照演示时的方式上线，只有一个公开链接、一个管理员登录账户，背后却是完整的员工数据表。

TL;DR（太长不看版）

• 帮助决定招聘、晋升或人员评分的工具，在欧盟《人工智能法案》下可能属于高风险系统。在它为任何人评分之前，必须先交给 IT 部门以及法务或 DPO 审查。
• 员工记录绝不能存放在 AI 编程工具的自有托管平台上。默认应使用团队掌控的服务器，仅允许通过私有网络访问；一旦经理或全体员工需要访问，还应在入口配置公司账户登录。
• 修复工作由构建应用的同一个 AI 工具完成：缩减它读取的字段，为 HR 管理员、经理和员工提供不同视图，将凭据移出代码，减少向外部发送的数据，记录谁打开了哪些记录，并结合保留要求处理删除请求。每一项都要通过您亲自执行的检查来确认；AI 自己的报告不能作为确认依据。
• 员工离职当天就应终止其工具访问权限，应指定一名明确的负责人，而选择服务器位置本身并不能实现合规。

导致员工数据暴露的部署错误

AI 构建的 HR 工具会将员工数据暴露给找到链接的任何人、持有粘贴到聊天或代码中的凭据的任何人、打开他人记录的同事、接收其数据的外部服务，以及已经离职的人，却没有记录谁查看过数据。读取完整员工表，会扩大每一条泄露途径。

第一行的问题，正是 RedAccess 大规模发现的情况。在 Wired 关于 RedAccess 调查结果的报道中，四家 AI 编程公司中的三家反驳了研究人员的说法（第四家未回应），但并未否认 RedAccess 找到的这些通过氛围编程构建的应用处于暴露状态。我认为这是配置问题，也是跳过审查步骤的结果。

检查工具是否帮助决定招聘、晋升或评分

仅仅使用 AI 编程工具构建，并不会让 HR 工具自动成为欧盟《人工智能法案》下的高风险系统。决定因素是工具的用途。欧盟《人工智能法案》附件 III列出了用于招聘或选拔人员，以及用于决定晋升、解雇、任务分配，或监控和评估绩效的 AI 系统。

因此，在决定工具运行位置之前，先问一个问题：它是否作出或影响有关招聘、晋升、解雇、工作分配或绩效评分的决定？

休假跟踪器、入职清单或组织通讯录只是存储记录并展示，因此属于“否”的一侧。对候选人排名的面试评分表，或为人员评分的绩效工具（尤其是使用 AI 模型评分的工具），则可能属于“是”的一侧。如果无法判断，我会先按“是”处理，再由 IT 和法务判断是否可以排除。

该法案并非仅适用于欧盟公司：当 AI 系统的输出在欧盟使用时，第 2 条也涵盖位于欧盟之外的提供者和部署者。根据修订后的第 113 条，附件 III 高风险系统的义务自 2027 年 12 月 2 日起适用。这些义务包括风险管理体系、数据治理、技术文档、记录保存、对部署者的透明度以及人工监督（第 9 至 14 条），其评估应由 IT 和法务负责。

如果答案为是，在工具给任何一名真实候选人或员工评分之前就应停止。将工具交给 IT，以及您的法务或数据保护负责人（如设有 DPO，则交给 DPO）。这项检查不能确定某个具体工具是否属于适用范围；它用于确定应由谁作出判断。美国部分州也监管自动化招聘决策，相关规定见下文表格。

您可以提前为审查做好准备。我会要求 AI 工具质疑自己的评分，而不是为其辩护：

此应用会为求职候选人或员工评分或排名。列出参与评分或排名的每个数据字段及每个计算步骤。针对每一项，说明它是否可能直接或间接反映受保护特征：年龄、种族、性别、国籍、族裔出身、残疾、怀孕、宗教或性取向。不确定时请明确说明，不要猜测。然后指出有关评分公平性的问题中，还有哪些是我没有询问但应当询问的。

检查：将回答作为供审查人员使用的初始清单，而非结论，并与工具本身一起交给他们。执行此提示词不等于偏见审计，也不满足任何法律要求。

HR 工具应在哪里运行

不要将员工记录放在 AI 工具的自有托管平台上。对于仅由 HR 团队使用的工具，默认应使用团队掌控的服务器，并且只能通过私有网络访问；一旦经理或员工需要使用，再在入口配置公司账户登录。未通过招聘决策检查，或没有人负责其服务器的工具，应交给 IT。

在 AI 编程工具的自有托管平台发布，会让应用获得供应商域名下的地址；除非将可见性设为私有，否则找到该地址的任何人都能访问。RedAccess 通过对这些域名进行普通的 Google 和 Bing 搜索，发现了数千个这样构建的应用。私有网络的机制相反：工具只响应已加入网络的设备。公司账户登录（单点登录）意味着同事用现有的公司账户打开工具，由身份提供者，也就是管理这些账户的服务，进行验证。

在工具运行于团队自己的服务器之前，应使用合成数据构建和测试，即外观与真实数据相似、但虚构的姓名、薪资和休假日期。从笔记本电脑连接到公开地址的免费隧道与供应商托管一样属于公开访问，因此也只适合演示阶段。

为什么要使用私有网络，而不是应用现有的登录页面？私有网络意味着工具完全不响应外部请求，因此外部人员无法加载、探测工具或猜测密码。AI 工具编写的登录页面本身并不足够。任何人都能访问它，其安全性取决于背后的生成代码。Veracode 2025 年生成式 AI 代码安全报告发现，在来自超过 100 个模型的受测代码样本中，45% 因存在 OWASP Top 10 漏洞而未通过安全测试（这些漏洞来自广泛采用的最关键 Web 应用安全风险清单）。因此，我更愿意在应用入口加一道锁，而不是依赖 AI 写出的那一道。

交接时，工具应运行在 VPS（由团队完全掌控的租用服务器）上，并由 Coolify 或 Dokku 等部署工具从代码运行应用；Coolify 还可通过仪表盘将有问题的更新回滚到较早版本。在 Coolify 和 Dokku 之间选择，主要取决于服务器要运行多少个应用，以及 IT 支持人员是否偏好仪表盘。私有网络由 Tailscale 或 WireGuard 提供。Tailscale 设置更快，但其协调服务由 Tailscale 运营，而 WireGuard 完全由自己托管。公司账户登录由 Authentik 或 Keycloak 等身份提供者提供。当登录入口面向 Web 时，Caddy 或 Nginx Proxy Manager 等反向代理会添加 HTTPS。这部分应连同文末清单一起交给 IT 支持人员。

将修复要求写成您自己的 AI 工具提示词

安全部署 AI 构建的 HR 应用，大部分工作可由构建它的工具完成，但必须明确提出要求。安全研究人员 Joel Margolis 对 Wired 表示，AI 编程工具“会按你的要求做。如果你没有要求它们安全地完成，它们不会主动额外去做安全工作。”

将下列每个提示词作为起点，并修改字段名和角色以匹配您的工具。我将 AI 工具视为工程师，将自己视为审查者，因此它报告变更已完成时，那仍只是草稿。每个提示词下方的检查才是证明，而且所有检查都不要求您阅读代码。检查失败时，将修复工作交回 AI 工具，并把经验写入AI 工具的规则文件，让下一次会话以此为起点。每个提示词也要求工具标记不确定之处；承认缺口的助手比听起来十分肯定的助手更有用。针对代码和虚构记录执行这些提示词，绝不要将真实记录或密码粘贴到聊天中。

找出工具接触的员工字段，再禁止访问其余字段

如果不知道工具存有哪些字段，就无法禁止其访问，因此第一个提示词用于审计：

检查此应用的数据库、代码、页面和导出内容。列出可能保存员工或求职候选人个人数据的每个字段：姓名、员工 ID、SSN 或国家身份证件号码、税号、出生日期、家庭住址、健康信息、残疾状态、合理便利安排记录、移民或工作许可文件、薪资、奖金、股权、绩效评分和纪律处分备注。对每个字段，说明哪个页面或功能使用它，以及应用的主要用途是否需要它。如果无法判断，请标记为不确定，不要猜测。

检查：打开工具的主要页面和导出内容，确认其中可见的每个个人数据字段都在清单中。如果某个可见字段未被列出，说明审计有所遗漏，应再次要求检查。

第二个提示词会移除工具不需要的数据。它依靠数据库登录账户（应用与数据库通信时使用的账户），该账户可以限制为只访问特定字段。

修改此应用，使其只读取以下字段：[列出工具所需字段]。从应用的数据副本、代码、每个页面和每项导出内容中移除所有其他个人数据字段。然后为应用创建独立的数据库登录账户，只能读取这些字段，并且只能修改工具自身写入的数据，例如休假申请。让应用改用该账户。逐个文件准确报告所做的修改，并说明所有未能完成的事项。

只修改页面并不足够。如果应用的数据库登录账户无法读取薪资列，那么 AI 编写代码中的其他错误也无法显示它。数据是否在静态存储时加密，应询问 IT，因为这取决于服务器和磁盘配置，阅读代码的助手无法可靠判断。

检查：以普通用户登录，打开每个页面和每项导出内容；被移除的字段都不应出现。然后要求管理服务器的 IT 支持人员（或 AI 工具，但需向您展示输出）使用应用的数据库账户连接，并请求读取已移除的字段。出现权限被拒绝或字段不存在的错误才算通过。连接、语法或其他无关错误不算通过。出现空列或实际值都算失败。保留审计清单，因为删除工具还要使用它。

为 HR 管理员、经理和员工提供不同视图

员工数据也会向内部泄露，例如同事打开另一人的薪资或队友的合理便利安排备注。基于角色的访问控制可以解决这个问题，下列提示词明确规定检查必须在哪里进行：

添加基于角色的访问控制，设置三种角色，并在服务器上对每个请求检查，而不是仅在页面中隐藏按钮或链接。

- HR 管理员：可读取和编辑所有员工记录。

- 人员经理：只能读取自己的直属员工记录，且绝不能看到薪资、医疗、合理便利安排、纪律处分或移民字段。

- 员工：只能读取自己的记录。

所有其他请求均以“访问被拒绝”（403）响应拒绝。每个用户的角色必须从其已登录账户获取，绝不能来自用户可在页面或地址栏输入或修改的内容。列出添加检查的每一处位置，并标记无法确定是否被覆盖的页面或导出内容。

有些公司允许经理在薪酬评审期间查看薪资；如果您的公司如此，应修改经理角色的那一条要求。

检查：创建测试经理和测试员工。以经理登录，打开一名直属员工的记录，复制其地址，将记录编号改为团队外某人的编号并加载：应得到“访问被拒绝”。再以员工登录，用同事的记录编号重复测试。随后确认经理视图绝不会显示薪资、合理便利安排或移民字段。

将凭据移出代码和聊天

数据库密码、HRIS 或薪资系统的 API 令牌（系统登录另一系统时使用的长密钥）即使已从当前代码移除，仍可能存在于项目较早保存的版本中，因此提示词也要求检查历史。环境变量可以解决代码层面的问题。它是服务器在应用启动时传入的值，代码只通过名称引用，而不包含值本身。

找出此项目中的所有密码、API 密钥、访问令牌和数据库连接字符串，包括 HRIS、薪资或邮件系统使用的凭据。将代码中的每一项替换为环境变量，并提供变量名清单。确保 .env 等保存实际值的文件被排除在代码仓库之外。然后列出旧值仍出现在项目历史中的所有位置，让我知道需要更换哪些凭据。

提示词无法完成最重要的一步。对于曾出现在聊天或仓库中的每个凭据，都应在 HRIS 或数据库管理控制台签发新凭据，并停用旧凭据。

团队自己保存的密码副本应放在密码管理器中，例如自托管的 Vaultwarden 服务器（哪种方案适合团队需要另行决定）。它为人们存储凭据，不负责向运行中的应用提供值；应用从部署工具获取这些值。对于运行中的应用自身读取的秘密，HashiCorp Vault 是更重型的方案，为有需求的团队提供集中策略和轮换。

检查：要求 AI 工具在当前文件中搜索旧值，并阅读它展示的搜索结果，而不是结果摘要。当前文件应没有任何匹配。历史中的匹配属于预期情况，无需清除；它们就是需要更换的凭据清单。每个旧凭据已经失效的证明应来自 HRIS 或数据库管理控制台：所有旧凭据均显示已撤销，或 IT 确认系统拒绝接受它们。

查看哪些员工数据离开了工具

一旦某次调用将候选人的面试备注发送至外部服务，在自己的工具中删除记录，并不会删除该服务可能保留的副本。因此，修复方法是从一开始就减少发送的数据。

审计此应用的每一次外部调用：向 OpenAI、Anthropic 或其他 AI API，向 HRIS 或 ATS 等 HR 系统，向分析或错误跟踪工具，以及向任何 webhook 发出的调用。针对每次调用，准确列出发送内容包含哪些员工或候选人字段。标记可能存储或记录所接收内容的服务，并说明哪些调用可以使用更少的数据。标记所有不确定之处。

检查：创建具有独特虚构姓名的假员工或候选人，然后使用每个会发起外部调用的功能（生成面试摘要、触发 webhook、打开加载分析脚本的页面）。打开各外部服务自己的仪表盘，例如分析工具、错误跟踪器、ATS 接收 webhook 的日志，或会显示请求的 AI 提供商使用日志，并搜索该姓名。它只应出现在调用确实需要它的地方。如果出现在其他地方，就要求 AI 工具减少该调用的数据，并重新检查。有些仪表盘不显示收到的内容。对于这些服务，以及任何必须持续接收员工数据的服务，请将其数据保留条款交给公司负责签署供应商合同的人。

记录谁打开了哪条员工记录

某位员工询问上个季度是谁导出了薪资表。如果没有审计日志（持续记录谁对哪条记录做了什么），就无人能回答。

添加审计日志。每当用户查看、编辑、导出或删除员工记录时，添加一行，包含用户 ID、员工记录 ID、操作、发生变更的字段和时间。配置数据库，使应用的数据库登录账户只能向日志添加行，不能编辑或删除。应用内只有 HR 管理员能读取日志。告诉我禁止编辑和删除的规则如何执行，以及在哪里执行。

“只能追加”必须通过数据库账户权限实现，不能依赖应用承诺按规则行事。日志本身也是个人数据，因为它显示谁查看了谁的记录，因此只有 HR 管理员能够读取。

检查：以 HR 管理员身份打开一条记录，然后查看日志，确认对应条目存在。让 IT 或 AI 工具（需向您展示输出）尝试使用应用的数据库登录账户删除日志行；您应看到实际的权限错误。

处理删除请求，同时遵守保留规则

当员工要求删除数据，而其中有些记录是公司必须保留的薪资文件时，会发生什么？直观的提示词（“删除每个表中该员工的所有个人数据”）仍会删除这些文件，造成两个问题。雇主通常必须保留某些记录，常见例子包括薪资、税务和工作许可文件；而在处理数据是履行法律义务或应对法律请求所必需的范围内，GDPR 的删除权不适用（第 17(3)(b) 和 (e) 条）。随意留下一个“全部删除”按钮，本身也是危险功能。更安全的版本会区分“应请求删除”和受保留要求约束的记录，即无论是否提出请求，公司都必须保留的记录，并在删除任何内容前展示计划：

构建只有 HR 管理员能打开的删除请求工具。输入员工 ID 后，先展示存储该员工数据的每个表和字段，并按字段审计中的类别分组。每个类别由 HR 管理员设置保留选项：“应请求删除”或“保留：强制保留”。HR 管理员确认后，工具只删除设为“应请求删除”的类别。日志仅记录员工 ID、时间、确认人，以及删除或保留了哪些类别，不记录此人的任何其他信息。任何非 HR 管理员都应收到“访问被拒绝”。

保留设置应由合规负责人或 DPO 决定，而非 AI 工具或构建者的猜测。告诉他们，删除后审计日志仍保留员工 ID，以便决定该标识符应保留多久。备份和外部服务持有的副本，需要各自的保留或删除流程。

检查：创建一个测试员工，在两个类别中各有记录，一个设为“应请求删除”，另一个设为强制保留。以 HR 管理员运行工具，确认只有第一类被删除。然后用经理账户打开工具，应得到“访问被拒绝”。

应向 DPO 或合规负责人提出的雇佣规定

HR 工具涉及的雇佣规定取决于其用途和存储谁的数据，而非它如何构建。这是供您与 DPO 或合规负责人讨论的规定清单，不构成法律建议，也不判断其中任何规定是否适用于您。

存储德国和加利福尼亚州员工合理便利安排备注的休假跟踪器，与仅存储职位名称的人员编制规划工具，涉及的规定不同。欧盟《人工智能法案》的问题应在招聘决策检查中处理。

服务器位置决定记录在物理上存放在哪里；它本身并不能满足上述任何规定。对于这些地区之外的员工，应先咨询相关国家、州或地方的隐私或雇佣监管机构，或者您的法务或合规负责人。

离职时终止访问权限

离职员工的公司账户在最后工作日停用时，邮件、日历和文件的访问会一步关闭。HR 工具也应在同一步关闭；配置公司账户登录后，只要离职流程同时撤销活动会话，就能实现这一点。任何未配置公司账户登录的工具，都应在离职清单中单列一项，由专人手动移除账户。

构建者最终也可能离职。当构建工具的人离职或转岗时，应将责任移交给一名明确指定的继任者；继任者能够以管理员登录，并知道服务器在哪里，同时关闭构建者自己的管理员账户。我会在上线前就指定继任者，因为离职通知期并不适合临时寻找人选。

按固定周期审查各角色由谁持有，以及工具是否仍在使用。当访问范围需要扩大时，逐级开放（先 HR 团队，再经理，最后全体员工），并在每一级重新执行地址栏测试。工具不再使用时，应将其退役：停用数据库登录账户和凭据，按照删除工具的保留设置删除数据，停止运行，并将其从私有网络或登录系统中移除。

指定的继任者会接手一台此前由人搭建的服务器，其中有部署工具、私有网络，以及扩大访问时所需的公司账户登录。我们的 Linux VPS 提供 root 访问权限，Coolify、Tailscale 和 Authentik 均可作为一键应用部署，让 IT 支持人员把时间用于检查。机房位置包括欧盟的法兰克福和阿姆斯特丹、英国伦敦及美国多个城市。这确定了服务器所在国家，是与 DPO 沟通时的一项依据，不能替代该沟通。

上线检查清单

在输入员工记录之前，下列各项都应明确完成或尚未完成；这份清单应交给负责设置服务器的人。

1. 已回答招聘决策问题，所有“是”的情况均已交给 IT 和法务。
2. 工具运行在团队掌控的服务器上，而非 AI 工具的托管平台。
3. 只能通过私有网络或公司账户登录访问。
4. 应用的数据库登录账户只读取列出的字段。
5. 测试经理和测试员工在地址栏测试中都收到“访问被拒绝”。
6. 所有曾出现在聊天或代码中的凭据均已更换，旧凭据均已撤销。
7. 已完成对外发送数据的审计，并移除不需要的字段。
8. 审计日志记录查看操作，应用账户不能编辑或删除日志。
9. 保留设置和雇佣规定已由 DPO 或合规负责人审查。
10. 已指定一名负责人和一名备用负责人。

常见问题

HR 中的影子 AI 是什么？

HR 中的影子 AI，是指在 IT 不知情或未批准的情况下，使用 AI 工具或由其构建的应用处理 HR 数据。根据 Cornerstone OnDemand 对 Sapient Insights 2026 年度 HR 系统调查的报道，超过 80% 的 HR 专业人员每天使用个人 AI 工具，而使用 HR 系统内置 AI 的比例为 3%。

构建工具时可以使用真实员工记录吗？

不可以。构建通过氛围编程实现的 HR 工具时，不要将真实记录输入聊天。将记录粘贴到聊天助手中，是独立于应用部署的另一项风险；粘贴的瞬间风险就已发生，无论工具最终是否上线。在工具运行于团队掌控的服务器之前，使用虚构记录进行构建。

HR 工具使用员工数据，必须取得员工同意吗？

通常，同意并不是合适的依据。EDPB 的同意指南指出，它“认为雇主基于同意处理现有或未来员工的个人数据存在问题，因为这种同意不太可能是自由作出的”。GDPR 第 6 条下应适用哪种合法依据，应询问您的 DPO。

HIPAA 涵盖 HR 工具中的医疗备注吗？

通常不涵盖。HIPAA 对受保护健康信息的定义，排除了受覆盖实体以雇主身份持有的雇佣记录中的信息（45 CFR 160.103）。这并不意味着这些备注不受监管，因此应咨询合规负责人，确认哪些规定涵盖它们。