夜雨聆风学习资料网

ARTICLE · 1225931

央国企HR软件系统自研,AI应该放在哪里?一个架构师的判断

央国企HR软件系统自研,AI应该放在哪里?一个架构师的判断

图1:当技术变化越来越快,做HR系统的人反而更想知道:AI到底该放哪里。

做HR系统设计的人,最近几乎都被同一个问题追着问:AI到底该怎么进入HR系统?

厂商的发布会一场接一场,有的说“AI原生”,有的讲“AI Family”,听着都很有道理。可真到自己做项目的人,反而更困惑了——尤其是做HR系统国产化替代自研的团队,本来就要啃HR软件自主研发这块硬骨头,现在又冒出个AI,到底该把AI放在系统的哪个位置?是嵌入现有的业务流程的某些节点可以辅助系统或者业务人员做一些事情,还是打造独立的功能模块实现AI对业务的赋能?

这些年我参与大型集团HR系统国产化自研的架构设计,越来越确认一件事:AI进HR系统,难的从来不是模型,而是位置和方式。你把它放错了地方,再强的模型也落不了地;放对了地方,AI就成了架构里自然长出来的一部分。

这篇文章不讲模型、不追热点,只讲清楚三件事:AI在HR系统里应该落在哪里、哪些场景真值得做、传统功能应用和AI的边界在哪里。给做HR软件自研的人一套能参考和借鉴的判断框架。

一、先纠正一个误区:AI不是给HR系统“加一个模块”

一说“HR系统引入AI”,很多人第一反应是:加个AI模块,或者接个大模型接口,让它能聊天、能写报告。

这个理解不是全错,但它把AI想狭隘了。如果AI只是系统的“外挂”,那它和核心系统之间就是两套数据、两套逻辑。系统里的人员、组织、岗位、职级、部门、单位这些数据,AI要用的时候得重新对接、重新清洗;业务一变,AI的理解又对不上号了。这样的AI,看着热闹,用起来鸡肋。

更准确的说法是:AI能力设计,要从数据同源、能力服务化、场景产品化三个层面,把它当成HR架构的内嵌流程节点和系统功能点来设计。

——数据同源:AI要用的“事实”只有一个版本。组织(单位和部门)、岗位、职级、人才、绩效这些核心数据口径统一了,AI才不会讲出和系统矛盾的话。

——能力服务化:语义理解、画像建模、报告生成这些能力,封装成可复用的服务,而不是绑死在某一个功能上。

——场景产品化:每个AI能力都对应一个明确的HR业务场景和验收口径,根据用户输入给出输出,不为炫技而做。

这三件事,就是AI能不能在HR系统里真正立足和发挥价值的底座。

二、三层架构:AI到底落在哪里

要把AI设计进架构,先要给它找到“座位”。我参与的自研项目里,常用的是三层落位:

第一层,应用层(场景层)。这是员工和HR每天打交道的地方——岗位画像、干部管理、智能问答、薪酬解释、合规校验。AI在这里体现为“好用”,用户无感,任务被悄悄完成。

第二层,能力层(AI服务层)。这里是AI的“发动机”——语义理解、画像建模、班子推演、报告生成、智能问答服务。这些能力封装成可复用的服务,任何场景需要都能调用,避免每个功能各搞一套。

第三层,数据层(数据中台)。这是AI的“粮仓”——组织、岗位、职级、薪酬、考勤、人才、绩效、培训这些核心数据。没有统一的数据口径(数据字典和码表),AI就是空中楼阁。

图2:数据底座、能力服务、业务场景——AI在HR系统里的位置,就在这三层之间。

这三层的顺序不能乱。很多人一上来就在应用层堆砌AI功能,结果数据不统一、能力不沉淀,最后全部返工。先有数据底座,再有能力服务,最后才是业务场景——这个次序,比任何单个AI功能都重要。

三、四类场景:AI在央国企HR里,哪些真值得做

不是说所有HR业务场景都适合上AI。结合央国企和大型集团企业的实际,真正高价值、也真正能落地的,主要是四类:

场景

为什么值得做

关键前提

干部管理与班子推演

数据最敏感、价值最高

私有化部署、模型本地推理

岗位画像与任职资格

基于组织主数据和岗位/人员能力框架

岗位任职标准明确且统一

智能问答与政策解释

大幅降低HR事务性负担

政策口径准确

数据治理与合规校验

口径统一、规则校验

规则明确可执行

这四类有个共同点:它们都建立在统一的数据口径之上,而不是靠某个单点模型。这也是自研架构相比“买现成商业产品”更该下功夫的地方。

04 两条路径:增强式还是原生式

现在行业里谈AI进入HR系统,基本是两条路。

路径

做法

优势

局限

增强式

现有自研系统上加AI服务层

稳妥、能落地、风险小

AI潜力受原有架构束缚

原生式

从系统设计第一天起将AI嵌入业务架构

彻底、上限高,原生支持AI

推倒重来、投入大周期长

我见过不少团队在这两条路之间纠结。

我的判断是:做国产化HR软件自研替换的项目,先走增强式最务实——在现有业务和应用架构里把AI服务层做好、把数据口径统一,先把业务跑通。但架构设计上,要给原生式留出演进空间:AI服务层和业务层解耦,将来系统换代,能力可以平滑迁移,不推倒重来。

一句话:当前已有系统用增强式落地,全新设计系统其架构按原生式设计。

05 三条边界:AI管效率,架构管正确性

这是我最想和做HR软件自研的人分享的一点,也是AI进HR系统最容易被忽略的地方。

AI很擅长提升效率——帮你按岗位说明书寻找适配的候选人或者员工,撰写岗位说明书、根据外部公有和内部私有数据撰写干部廉政和回避监督报告、帮你回答政策制度、帮你整理数据生成分析报表。但HR系统里有一类东西,AI不该碰最终裁决:薪酬计算、考勤计算、劳动用工合规、干部任免合规、政策口径。这些是强规则、高敏感、要负责的业务,错了就是大事。

设计的时候,要守住三条边界:

第一,AI讲效率,架构讲正确性。强业务规则和内部控制场景里,AI只做辅助解释和预填,最终裁决一定由规则引擎和人来完成。

第二,数据安全与私有化。央国企的人事数据高度敏感,模型的推理必须跑在私有云或本地化部署的数据库上,数据不出域。

第三,可解释、可审计。AI输出的每个结论,都要能追溯它的数据口径和推理依据。尤其干部管理和干部监督这类场景,AI可以辅助,但绝不能“黑箱决策”。

守住这三条,AI才不是来添乱的,而是来帮忙的,来给业务人员减轻负担的。这也是自研架构相对“外购产品”真正的价值所在——正确性、适配性和边界,是买不来的。

写在最后

回到开头那个问题:AI 到底该怎么进入HR 系统?是嵌入新的业务流程节点,还是做成独立的功能模块? 

答案不是二选一。AI 的位置,既不是简单嵌进某一个业务节点,也不是做成一个孤立的 "大模型模块"—— 而是要有独立的 AI 服务引擎,负责统一、复用、可演进;也要有嵌入业务流程的触点,负责好用、有场景。

数据同源做底座、能力服务化做 AI 服务引擎、场景产品化做入口,再守好 "AI 管效率、架构管正确性" 这条边界 ——AI 就能从 "附加项" 变成架构里自然长出来的一部分。

做 HR系统国产化替代自研的专业人士,正处在一次难得的窗口期:既要替换原有的国际化HR系统,又要迎接 AI 接入。这两件事叠加,考验的恰恰是架构设计的基本功,以及把 AI 嵌入业务架构的能力。谁把位置摆对了、抓准了业务痛点,谁就先走一步,也才能真正给业务带来价值。

相关学习资料