制度口径负责人
这个人决定假期、考勤、报销与福利的解释口径，也决定知识库里哪些条款可以对外。为什么不能交给 IT：制度条款随时调整，口径一变，问答与模板都要跟着改，没人拍板就会出现多个版本同时在用。建议由 HR 负责人或 HRBP 主管担任，并对每次变更留痕。
知识运营与更新
把员工手册、流程、常见问题拆成可检索条目，标注生效日期与适用范围，按月清理过期内容。怎么做：按主题建目录，每条附来源文件与责任人，问询量高的主题优先补。这个角色适合共享服务中心的专员兼任，工作量按问询量与制度变更频率估算。
复核与争议处理
答复涉及个案时必须转 HRBP，由人判断并记录结论。为什么不能让模型处理争议：争议往往牵连劳动关系与证据，答复本身就是管理动作，需要有人负责。复核人还要定期抽检问答记录，把答错与答非所问的类型统计出来，反馈给知识运营。
数据与权限管理
负责员工数据的分类、授权、日志与删除，决定哪些字段可以进问答库。边界很清楚：敏感信息不进通用库，权限按岗位最小化，访问留日志。这个职责可以与信息安全或法务共管，但不能只挂在项目组名下，否则上线后无人对数据负责。
适用与不适用
适合谁
- 员工规模较大、日常问询集中在共享服务中心的企业
- 有 HRBP 或员工关系岗位、能承接争议处理的公司
- 愿意把制度维护写进岗位职责的 HR 负责人
不适合谁
- 制度尚未成文、口径随人变化的企业
- 希望由模型直接答复劳动争议的团队
典型场景
某集团 HR 共享中心上线前先定岗：HR 负责人管制度口径，共享中心专员做知识运营，两名 HRBP 轮流处理争议与申诉，信息安全同事兼管权限。四类职责写进岗位说明书，每月联席复盘一次答错类型与申诉数量，全程没有新增编制。
可执行步骤
- 把四类职责写成岗位说明，明确每一类的交付物、投入工时与验收人
- 指定制度口径负责人，约定条款变更须书面留痕，并在同一天同步到知识库
- 按主题整理知识底稿，逐条标注生效日期、适用范围与来源文件并指定维护人
- 设置争议转人工规则与申诉入口，指定 HRBP 轮值并记录处理结论
- 按季度检查权限与访问日志，及时清理离职人员、转岗人员与过期授权
常见坑
- 把制度解释权交给项目组或供应商，条款调整后知识库长期不更新，员工按旧口径主张权利。
- 争议答复也交给模型，员工收到的结论无人背书，小问题容易升级为投诉或仲裁，处理成本更高。
- 权限一次给到底，离职或转岗人员仍能查询员工信息，出事时也无法证明谁看过哪些记录。
自检与验收清单
- 四类职责是否落到具体岗位，并写明交付物与验收人
- 制度条款变更是否有留痕与同步机制，由谁签认
- 争议转人工规则与申诉入口是否书面化并公布
- 权限是否按岗位最小化，访问是否保留可查日志
- 是否按季度清理离职、转岗人员与过期授权记录
常见问题
小团队怎么配这几类职责？
可以由 HR 负责人兼口径、共享中心兼知识运营、HRBP 兼争议处理，数据权限与信息安全共管。关键不是人数，而是每类职责都有名字和交付物；完全不设维护人，制度库通常在半年内失效。
需要专职 AI 运营岗吗？
多数企业不需要独立岗位。知识整理与话术维护是 HR 工作的延伸，学两周即可上手；只有员工规模大、多地域多制度并行时才值得设专职，且应由懂制度的人担任，而不是技术人员。
答错的答复由谁负责？
由复核人负责，而不是模型或供应商。做法是每次争议答复留结论与依据，按月抽检并把错误分类；同一类错误反复出现，就要回到知识库与流程上修，而不是只更换模型。