← 吴兆华个人网站站内作者版本 · 本页为长期 canonical · 最近核验 2026-07-21

2026 · AI人社与可信劳动关系

政策解读 · 可信签约 · 企业落地

AI开始进入人社,电子劳动合同为什么不能只是一份PDF

2026年,人力资源社会保障部等四部门提出,到当年建设“人工智能+人社”应用基础设施,打造约20个基于行业大模型建设的应用场景;到2027年探索约50个高价值场景。文件把“智慧劳动关系”列入六类重大场景。但对企业来说,AI真正进入劳动关系之前,最先要补的可能不是模型,而是事实。

AI辅助、业务判断和可信签约三层劳动关系信息图
AI辅助信息图|AI可覆盖招聘、入职、调岗、续签与离职,但主体、版本、意愿、时间和验证方式必须先成为可信事实。

一场劳动争议发生后,企业把劳动合同PDF、OA审批截图、微信聊天和邮件打包交给法务。有人问:员工签的是哪一版?调岗通知什么时候送达?签署人当时是否有权限?合同变更是否经过双方确认?

文件很多,答案却不一定存在。

这时,即使把最强的大模型接进来,它也只能在不完整材料上生成一个看似完整的解释。AI可以读懂文字,却不能凭空补出一次没有记录的告知;可以找到相似条款,却不能证明员工真的看过;可以总结聊天,却不能替企业回答某个账号当时究竟由谁控制。

所以,“人工智能+人社”对企业最重要的启示,不是马上让AI判断谁对谁错,而是先建立一套可信、可验证、可调用的劳动关系事实。

电子劳动合同正处在这套事实底座的中心。

01 政策说了什么,也没有说什么

四部门人工智能加人社实施意见官方原页
真实政策原页|四部门联合印发,人社部发〔2026〕40号。政策提出行业建设目标和应用方向,并不等于要求所有企业立即上线AI劳动合同。

《关于加快推进“人工智能+人社”应用发展的实施意见》由人力资源社会保障部、国家发展改革委、工业和信息化部、国家数据局联合印发,文号为人社部发〔2026〕40号。

文件给出了一条清晰时间线:

  • 到2026年,相关应用体系、标准体系和保障体系等初步成形,基础设施落地,打造约20个基于人社行业大模型的应用场景及相应高质量数据集;
  • 到2027年,普及一批行业大模型和智能体,探索约50个高价值场景赋能路径;
  • 到2030年,形成人社行业领域人工智能普遍应用的创新局面。
2026约20个基于行业大模型的应用场景及相应高质量数据集
2027约50个高价值应用场景赋能路径
2030普遍应用应用体系基本健全

67个是随文件发布的细分场景全景图口径,不等于2026年当年必须完成67个场景。

文件同时发布了涵盖67个细分场景的全景图,并把重大场景分为数智就业、智慧社会保险、人才培养使用、智慧劳动关系、智慧人力资源服务和人社智慧治理六类。

与劳动关系直接相关的内容包括:智能化劳动用工指导、政策咨询和维权引导,争议调解助手,庭审笔录生成、类案推送、案由量裁辅助、仲裁文书生成、案卷自查,以及智慧执法、风险监测和预警等。

但这里必须划一条边界:文件提出的是行业建设目标和应用方向,并没有规定所有企业必须在某个日期上线AI劳动合同,也没有授权AI替代仲裁员、法官、企业法务或劳动关系负责人作出法律判断。

它还特别要求数据不出域、调用可追溯量化、使用全程闭环可控,并强调数据安全、科技伦理、风险预警和应急响应。换句话说,AI进入人社的同时,治理要求也在同步进入。

02 AI会先问企业七个问题

假设企业希望用AI做合同审查、用工风险提示或争议材料整理。模型真正开始工作前,至少会依赖七类事实。

身份谁签的版本签哪一版展示看到了什么 意愿确认了什么时间何时生效送达变化后来改了什么 调取多年后能否完整验证

1. 签署人是谁

员工身份是否核验,企业签署主体是否准确,经办人是否获得授权。账号名称、手机号或一张手写签名图片,本身都不足以完整证明主体关系。

2. 签的是哪一版

合同模板、定稿文件、补充协议和签署文件是否一致。工资、岗位、工作地点、期限等关键内容如果在发起后被替换,系统能否发现。

3. 签署前看到了什么

员工是否能够查看完整文本,企业是否明确告知流程、操作方法、注意事项以及查看、下载途径。一个“点击同意”的结果,无法自动还原页面当时展示了什么。

4. 表达了什么意愿

身份认证证明“可能是这个人”,签署意愿回答“这个人是否认可这份具体文件”。两者需要关联到同一订单、同一版本和同一时间线。

5. 何时生效、何时送达

签署时间、可信时间、完成通知、下载和查看记录是否可追溯。很多争议并非合同不存在,而是无法清楚证明何时完成、何时通知对方。

6. 后来发生了什么变化

续签、调岗、调薪、请假、奖惩、解除或离职是否形成新的文件与事件;旧授权、旧模板和旧账号是否及时失效。

7. 多年后能否完整调取

原始文件、签名、证书、时间、身份与意愿记录能否一起导出;企业能否说明证据从哪个系统产生、是否被修改、如何验证。

如果这些问题没有结构化答案,AI的能力越强,反而越容易生成一种“材料已经很完整”的错觉。

03 现行《电子劳动合同订立指引》早已给出底线

人社部电子劳动合同订立指引通知官方原页
真实政策原页|2021年发布的《电子劳动合同订立指引》已经把身份认证、意愿确认、电子签名、可信时间和全过程证据作为一个整体。

2021年,人社部办公厅发布《电子劳动合同订立指引》。这份指引并不把电子劳动合同理解为“把纸质合同转成PDF,再贴一张章”。

它要求电子劳动合同订立平台具备身份认证、电子签名、意愿确认、数据安全防护等能力,使订立、生成、传递和储存满足真实、完整、准确、不可篡改和可追溯等要求。

指引还对整个流程提出了具体要求:

  • 订立前明确告知流程、操作方法、注意事项以及查看下载途径;
  • 通过数字证书、联网核验、生物特征识别、短信验证码等技术手段真实反映身份和签署意愿,并保存确认过程;
  • 使用符合《电子签名法》要求的数字证书和密钥进行电子签名;
  • 签署可靠电子签名后附带可信时间戳;
  • 完成后通知劳动者,并保证其可随时查看、下载和打印完整内容;
  • 留存身份认证、签署意愿、电子签名等全过程证据,确保可查询、可调用;
  • 非政府平台还应支持按当地人社部门公布的数据格式和标准提交相关数据。

这意味着,电子劳动合同从制度设计上本就应是一条完整过程,而不是一个孤立结果文件。

04 从“签完一份PDF”到“生成一组可信事实”

传统的电子合同项目经常只验收三个结果:文件能打开、章能看见、下载链接有效。

进入AI应用和数据协同时代,验收对象需要扩展为五组可关联事实。

主体事实

员工、企业、经办人、法定代表人或授权人的身份和关系;认证方式、结果、时间和授权范围。

文件事实

模板编号、版本号、定稿时间、文件摘要、签署前后哈希、补充协议及关联关系。

意愿事实

阅读、提示、勾选、验证码、刷脸或其他主动确认事件;这些事件究竟对应哪一版文件、哪一次业务。

过程事实

创建、发起、查看、签署、拒签、超时、撤回、重发、通知、下载、归档和失败重试的状态序列。

验证事实

数字证书、签名值、可信时间、验签结果、证据索引和验证报告。

AI真正需要的,不是把所有个人信息无限汇聚,而是让必要事实具有稳定的主键、清楚的来源、明确的状态和可验证的时间。结构化不等于过度收集。相反,合理的数据分层、权限和留存策略,是避免“为了以后分析,先把一切都存下来”的前提。

05 把签约做成状态机:成功不是一个布尔值

企业系统经常只收到一个结果:signed=true。这对展示“合同已签”也许够用,对劳动争议还原、系统补偿和AI分析却远远不够。

一笔劳动合同订单至少应经历:合同定稿、主体校验、身份通过、证书申请或调用、完整展示、意愿确认、文件签名、验签成功、完成通知、归档与证据生成。每个状态都要关联同一业务主键、同一文件版本和明确时间。

01 定稿模板与文件哈希锁定02 身份员工与企业主体通过 03 展示/意愿完整阅读与主动确认04 签名/验签证书、签名值与可信时间 05 通知/归档可下载、可查询、可验证

项目更应该测试失败路径:

  • 文件换版。 发起后合同正文改变,旧任务必须失效,不能继续在旧阅读记录上签新文件;
  • 身份或授权过期。 员工认证超时、企业经办授权被撤销,应转入重新核验或人工处理;
  • 设备切换与重复回调。 多端继续签署、网络重试、重复通知不能生成两份冲突结果;
  • 通知失败。 签署完成但短信、邮件或站内通知失败,应进入补发和人工兜底,而不是把“签完”当作全流程结束;
  • 存证或归档失败。 文件签名成功但证据生成、业务归档失败时,系统要保留补偿状态,不能静默丢失;
  • 员工拒签。 拒签理由、发生时间和后续沟通应独立留痕,不得把拒签包装成系统异常。

只有成功和异常都能解释,AI才可能在后续提示“缺哪一个事实”,而不是根据一堆不一致状态猜测发生了什么。

06 电子劳动合同将变成员工全生命周期的一条主线

劳动关系并不止于入职当天。更适合AI时代的设计,是把合同与员工全生命周期连接起来。

招聘录用。 录用主体、岗位、薪酬和入职条件形成可追溯的录用事实;AI可辅助检查信息是否一致,但不替企业决定录用条件是否适当。

入职签约。 业务系统校验员工和组织,锁定合同模板与定稿版本,再进入身份、意愿和电子签名流程。

在职变更。 调岗、调薪、工作地点变化、保密或竞业安排,不应只存在聊天记录里,而应形成与原合同关联的变更文件和生效事件。

日常履行。 考勤、休假、培训、绩效、奖惩等数据可能成为劳动关系证据,但应按目的、权限和保留期限治理,不能为了模型训练无限扩张使用范围。

续签与解除。 系统要能识别合同期限、通知节点、授权状态和送达结果。AI可以提醒遗漏、聚合材料,但终止关系的事实判断和程序责任仍由企业承担。

争议举证。 证据不应在争议发生后临时拼接,而应能按同一业务主键导出原文、版本、身份、意愿、签名、时间与过程索引。

录用主体・岗位・薪酬
入职版本・身份・意愿
在职履行・授权・变更
续签/解除通知・送达・失效
争议原文・时间・证据索引

07 三层架构:企业保留判断,专业能力提供可验证输入,AI负责辅助

要防止“AI越权”,最清楚的办法不是在页面上写一句免责声明,而是把系统分层。

03 AI应用层

辅助发现与解释

条款比对、材料分类、缺口提示、政策检索、证据目录

不自动作出解除、处罚或争议裁判
02 可信签约层

提供可验证输入

身份、证书、意愿、签名、可信时间、文件完整性、证据输出

可由e签宝等专业服务按项目承接
01 业务控制层

企业保留主体责任

合同内容、岗位薪酬、适用模板、授权、顺序、沟通和异常处置

决定该不该签、签什么、由谁签

第一层:业务控制层

由企业掌握劳动规则、合同内容、岗位与薪酬、签署主体、授权范围、适用模板、流程顺序、员工沟通和异常处置。这一层决定“该不该签、签什么、由谁签”。

第二层:可信签约层

负责身份核验、数字证书、签署意愿、电子签名、可信时间、文件完整性、过程记录和证据输出。这一层证明“谁在何时对哪一版文件作出了什么动作”。

第三层:AI应用层

在权限和数据边界内进行条款比对、材料分类、缺口提示、政策检索、风险线索聚合和争议材料整理。这一层可以“辅助发现和解释”,不能越过业务事实直接生成处理决定。

三层之间最好用明确状态机连接:文件未定稿,不进入签署;身份失败,不进入意愿确认;文件换版,旧签署任务失效;验签失败,不把流程标记为完成;归档失败,进入可追踪补偿而不是悄悄丢单。

08 e签宝如何接入人社场景:SaaS API V3是主路线

从e签宝开放平台和公开产品材料看,可承接的专业能力包括:

e签宝SaaS API V3版对接指南公开页面
真实产品公开页|e签宝SaaS API V3对外提供实名认证与授权、合同文件签署、流程模板、印章、合同管理和回调通知等服务;页面截图核验于2026年7月20日。
  • 个人与企业身份信息核验、实名认证;
  • 数字证书与电子签名服务;
  • 合同文件或模板签署,以SaaS API V3接入既有HR、OA或业务系统;
  • 签署意愿、签署过程、文件摘要、可信时间和验签;
  • 存证、证据报告、验签报告等验证与证据输出。

在企业架构中,更合理的接入方式不是把员工全生命周期搬到一个孤立的签约后台,而是由HR系统掌握人员、组织、模板、流程和状态,通过SaaS API V3调用实名认证、合同生成、签署流程、回调和合同管理能力,再把结果写回企业系统形成完整记录。

01 HR定稿主体、人员、模板、条款与审批
02 生成文件上传合同或按模板填充
03 发起签署参与人、顺序与签署位置
04 H5/PC签署身份核验、阅读确认与签名
05 回调查询进度、异常、幂等与补偿
06 下载归档签署文件、证据与HR台账

例如,一次劳动合同签署至少应关联:员工业务主键、企业主体、合同模板与版本、文件哈希、认证流水、证书标识、意愿事件、签名结果、可信时间、通知和归档状态。只返回一个“签署成功=true”,无法支撑后续AI分析和争议还原。

同时必须说明,e签宝不能替企业决定劳动合同条款是否合法,不能判断调岗调薪是否合理,不能替代员工沟通、工会程序、劳动仲裁或法院判断,也不能保证“用了电子签名就一定胜诉”。技术与证据服务提高的是可验证性,不是把企业责任转移出去。

e签宝存出证公开文档中的证据报告样例
真实产品公开页|证据报告、验签报告等产品可辅助还原身份、意愿、签名和文件完整性;报告本身不替代仲裁或司法机构对全部证据的综合判断。

09 人社接入路线:默认SaaS API V3,SDK按特定条件评估

企业应先看数据控制、用户体验和证据责任,再选择接入形态。

平台化签署。 适合希望快速上线、流程相对标准的团队。企业通过后台或标准页面发起签署,实施成本低,但要确认人员与合同数据如何同步、页面是否满足本企业告知要求、归档如何回到HR系统。

SaaS API V3编排(人社默认推荐)。 适合已有HR、OA或自研用工平台的企业。企业掌握合同生成、审批、状态和异常编排,e签宝通过V3服务提供实名认证与授权、合同文件签署、流程模板、合同管理和回调通知等能力。项目重点是业务主键、幂等、回调补偿、合同版本和归档一致性。

SDK 3.0(特定项目备选)。 它不应成为普通人事合同的默认路线。当项目对终端交互深度嵌入、本地文件自持或摘要签署有明确要求时,再由产品、安全、法务和实施共同评估。金融、物流、医生处方签字等对终端嵌入、高频操作或文件本地控制要求较高的场景,通常更值得评估SDK 3.0;最终仍以客户架构、安全边界和当期产品条件为准。

对多数人社项目,路线应当很清楚:标准签署需求可快速使用平台能力;需要与HR/OA深度串联时,优先SaaS API V3;只有出现明确的终端嵌入或本地文件控制要求时,才进入SDK方案评估。关键不是接口越多越好,而是企业能否始终说明:哪一步由谁控制,失败后由谁补偿,最终材料如何独立验证。

10 企业六周怎么做:先搭事实底座,再选AI场景

第1周盘点一条真实链路系统、角色、输入、输出、失败处理
第2周建立字段与证据清单主键、来源、权限、留存与删除
第3周补齐状态与异常换版、拒签、失败、重试、归档
第4周试点低风险AI任务可复核、有引用、留痕、人工负责
第5周全链路异常验收换版、拒签、超时、重试、归档
第6周灰度上线与回退真实订单、指标、培训、应急预案

第1周:盘点一条真实链路

选择一个最常见场景,例如新员工入职。画出从录用、合同生成、审批、通知、身份核验、阅读、签署、下载到归档的完整路径。标出每一步的系统、负责人、输入、输出和失败处理。

第2周:建立字段和证据清单

确定主体、文件、意愿、过程和验证五类字段。检查是否能用同一业务主键关联;明确哪些字段属于个人信息、谁可查看、保留多久、何时删除。

第3周:补状态与异常

至少测试文件换版、认证失败、授权过期、重复回调、通知失败、员工拒签、系统中断和归档失败。一个系统是否可信,往往不是看成功页面,而是看失败后是否还能准确解释发生了什么。

第4周:用AI做“低风险辅助”试点

优先选择条款差异比对、材料分类、缺失字段提示、到期提醒或证据目录生成等可复核任务。要求输出引用来源、保留人工复核、记录模型版本和调用日志。不要一开始就让AI自动作出解除、处罚或争议处理结论。

第5周:按真实故障做验收

由HR、法务、信息安全、IT和服务商共同执行异常用例。每个用例不仅看页面提示,还要核对业务状态、回调、原文、日志、证据和人工工单是否一致。对于失败后可能产生劳动关系后果的环节,必须明确谁可以重试、谁可以作废、谁可以人工放行。

第6周:灰度上线并准备回退

用少量真实订单检验成功率、完成时长、失败分布、员工投诉与证据完整性;完成HR和客服培训,准备旧流程回退、文件补签、通知补发和数据修复预案。上线不是项目结束,而是持续监测版本、规则和异常的开始。

验收时同时看两套结果:业务流程是否正确,专业服务输出是否可验证。只有两者同时通过,才适合扩大到调岗、续签、解除和争议管理。

结语:AI不会替企业补上从未留下的事实

“人工智能+人社”打开了一个很大的想象空间:更精准的就业服务、更高效的争议调解、更及时的风险预警、更便捷的政务办理。

但对企业而言,最有价值的第一步可能非常朴素——让每一份劳动关系文件都能回答:谁、以什么身份、在什么时间、对哪一版内容、表达了什么意愿、后来发生了什么、现在如何验证。

当这些事实真实、完整、可追溯,AI才有资格成为助手;当这些事实缺失,AI只会把材料的空白包装得更像答案。

电子劳动合同的下一站,因此不是“更快点一下签字”。

而是成为劳动关系里一份可以被人看懂、被系统调用、被独立验证,也能在多年后还原的可信原件。


主要公开来源

  1. 国家数据局:人社部等四部门《关于加快推进“人工智能+人社”应用发展的实施意见》
  2. 中国人力资源市场网:四部门印发《实施意见》新闻稿
  3. 人力资源社会保障部办公厅:《电子劳动合同订立指引》
  4. 中国人大网:《中华人民共和国电子签名法》
  5. e签宝开放平台
  6. e签宝开放平台:SaaS API V3版对接指南
  7. e签宝开放平台:电子合同签署API一体化对接指南
  8. e签宝开放平台:存出证产品相关文件说明

注:本文以2026年7月19日可公开核验的信息为准。涉及具体产品能力、接口、配置与适用范围,以项目评估和当期正式产品文件为准;AI输出不替代劳动法专业判断、企业管理责任或有权机构裁判。