为何绝不该用LLM直接处理人力资源数据

你的员工 AI 底层的架构比上面的模型更重要

在过去一年的某个时候，你可能听到过组织里的人说：“我们为什么不把所有数据都加载到 ChatGPT 里？”一开始可能很小。这里一些 HR 数据表，那里一个“快速”的电子表格分析。有什么害处呢？

问题是，HR 数据与你组织持有的几乎所有其他数据都不同。它是易变的、时间性的，而且安全和治理的需求具有重大的法律分量。此外，诸如留任、管理幅度和离职风险等术语，根据具体上下文，含义完全不同。

而通用型 LLM 并不擅长处理这些上下文或细微差别。它会自信地基于猜测抛出答案。在企业规模下，这种猜测很快会转化为风险。

标普全球 最近询问企业技术领导者，生成式 AI 在哪些方面存在不足。首要答案是数据隐私和安全、回答准确性以及系统集成。当数据涉及员工时，这些不是抽象的问题。

我在 Visier 工作了十多年，帮助组织构建使员工数据为 AI 做好准备的数据基础。在那段时间里，相同的架构缺口反复出现。

问题很少出在 AI 模型本身。用新技术运行旧流程只是昂贵的旧流程。破坏员工数据和 AI 的不是智能——而是它下面的东西。

决定你的员工 AI 战略成败的部分

大多数组织在处理员工数据和 AI 时，正在做两件事中的一件。他们要么一切都保持人在环中——点击、审查、批准——这很慢。或者，比任何人愿意承认的更常见的是，员工已经在没有治理的情况下将敏感的员工数据加载到通用 AI 工具中。我们与希望提前解决这个问题的组织合作，提供像我们这样的安全、受治理的空间。

做得正确的组织正在找到中间路线。他们将 AI 的速度和推理能力与可观察、受治理且专为员工数据复杂性而构建的系统相结合。

当底层基础稳固时，上面的 AI 才能真正发挥作用。

是什么让中间路线成为可能？一个理解你的组织实际如何运作的上下文层。不仅仅是原始数字，还有它们之间的关系：谁向谁汇报，你的公司对“留任”的实际含义，上一季度的重组如何影响你今天看到的数字。

没有这层，你的 AI 产生的每个答案都是自信的猜测。

如果你正在评估用于员工决策的 AI 工具，最重要的问题是关于它下面的一切：定义、治理、使员工答案可信而非仅仅快速的时间逻辑。

你的 AI 的可靠性取决于其背后的上下文

原始 HR 数据并不附带理解。当经理问为什么敬业度下降时，答案不在于一个数字。而在于该数字与几十个其他数字之间的关系，并通过正确的时间窗口、正确的人群以及你的公司如何定义关键术语来过滤。

这就是上下文层的工作。它将所有员工数据整合成一个完整的画面，用语义建模以便有共享的含义，并安全地将见解、答案和指导分发给提问的任何人或任何事物。当有人说“敬业度”或“留任”时，系统确切地知道他们在你的组织中指的是什么，而不是通用模型可能推断的内容。

AI 的可靠性取决于其背后的上下文，但为了获得该上下文，你需要一个上下文引擎，将所有员工数据整合成一个完整的画面。它还必须在语义上建模，以便有意义，然后安全地分发见解和答案。

这就是模型上下文协议（MCP）发挥作用的地方。MCP 是一种将那些受治理的答案标准化地传递给 AI 代理和使用它们的人类的方式。通过 MCP 连接到相同的员工上下文，每个工具和每个用户都从相同的地方获取——相同的定义、相同的安全规则、相同的逻辑。当经理在 Teams 中提出员工问题，分析师在其分析平台中提出相同问题，他们得到相同的答案。不是因为工具相互集成，而是因为它们都从一个受治理的源中提取。正如我们的首席运营官 Steve Holder 今年早些时候在 Visier 的 Outsmart 会议上所说：

“问 AI 代理你的留任率是多少，它会给你一个答案。但该答案是否反映你公司对留任的定义——你的时间窗口、你的人口排除、你的内部逻辑——完全是另一个问题。这就是一个完全受治理的上下文层所弥合的差距。”

内部构建和维护上下文层可能导致代价高昂的失败

在几乎所有关于上下文层的讨论中，都会有人问：我们为什么不能自己构建这个？毕竟，上下文层涵盖了组织理论上已经内部持有的知识、定义和逻辑的广度。

然而，员工上下文层不是你的工程团队几个月就能拼凑起来的数据模式。定义员工概念如何与业务成果相连接，需要多年的知识积累。

这种专业知识只有通过跨数百个组织工作、看到模型在哪里崩溃、修复它们并再次这样做才能获得。

打破标准 SQL 管道的那种时间逻辑（追溯晋升、追溯修正和年中重组）已经解决。但大多数团队在构建六个月之前不会偶然遇到这些技术挑战。

劳动力上下文引擎不会替代你现有的技术栈。它承担了使劳动力数据可信的艰巨、无差别的工作，这样你技术栈的其他部分就不必为此操心。语义建模、时间逻辑、治理——这些都已经处理好了。Visier的Databricks集成就是一个很好的例子。Databricks处理统一存储、计算和治理。Visier作为劳动力数据层位于其上，应用劳动力特定的语义，并将增强的数据产品返回给湖仓或通过MCP直接提供给AI代理。你的团队时间最好花在重要的工作上。

你的团队时间最好花在重要的工作上。

关键的AI安全能力

在AI部署中，能力得到了所有关注：系统能做什么、回答有多快、听起来有多聪明。但除非治理将其转化为组织实际能使用的东西，否则这些都不重要，而不仅仅是拥有。

根据IBM的数据，63%经历AI相关泄露的组织要么没有治理政策，要么仍在起草中。

安全扩展代理式AI的组织不仅仅是在锁定能力。他们在指导能力，决定其用途、适用范围和停止边界。这是我已经在与微软、AWS、Anthropic和OpenAI团队进行的对话。

在部署任何代理式能力之前，我会推动四个问题：

• 需要哪些护栏？答案总是特定于用例的。向管理者展示洞察的代理与支持HR业务伙伴或高管规划的代理需要不同的约束。
• 它们如何实现？这是一个架构问题，必须在上下文层回答，而不是事后附加。在模型级别应用的护栏是脆弱的。嵌入在受治理的数据访问和语义定义中的护栏是持久的。
• 它们如何测试？这是大多数组织尚未提出的问题。护栏测试需要对抗性思维——用应该被拒绝的那类问题探查系统，以确认它们确实被拒绝了。
• 随着用例的发展，迭代过程如何运作？早期试点合适的护栏几乎肯定不是六个月后合适的护栏。从一开始就构建迭代过程。

所有这些指向的是一个层，处理AI对劳动力数据所需的上下文、治理和语义基础，从开始就内置而不是在顶层配置。

在Visier，我们花了15年与客户共同构建，迎接这一刻。这段历史意味着我们客户依赖的数据是统一、增强和受治理的，为任何工具、AI代理或提出劳动力问题的人提供准确的劳动力上下文。

这就是我们所说的劳动力上下文引擎，它区分了听起来正确的AI和你真正能信任的AI。

你的劳动力数据准备好迎接AI了吗？从基础开始。

了解Visier的劳动力智能平台如何将混乱、复杂的HR数据转化为受治理、AI就绪的洞察。看看劳动力转型是什么样子。