北京市轨道交通建设管理有限公司 2002 年 12 月成立，承担北京市轨道交通建设的专业管理任务。截至 2019 年，北京市轨道交通运营总里程从 2003 年的 114 公里扩展到 700 公里，期间这家公司管理了 4 号线、5 号线、6 号线、7 号线、8 号线、9 号线、10 号线、14 号线、亦庄线、昌平线、燕房线、西郊线、大兴机场线等线路的建设。一个 700 公里的轨道交通建设管理体系，每天产生数千份单据，年签署量累积到 200000+。这套年签署量级在 2023 年完成与 e签宝 的对接落地，整个项目的落地路径值得拆开看。

业务挑战：合规、数据安全、原有系统不替换

轨道交通建设是高强度的合规场景。地铁线路的招标、施工、监理、验收每一步都伴随大量单据签署。合同、变更单、验收单、安全协议、农民工工资保证书——这些单据签署的法律效力直接关系到工程交付与司法风险。

北京轨道交通建设管理对电子签名的核心要求集中在三点。第一点是合规底线：签署过程必须符合《电子签名法》对真实身份、真实意愿、签署原文未改、签名未改的全部要求，能够在司法举证场景独立成立。第二点是数据安全：签署的表单原文信息不出北京轨道交通本地服务器，保障内部数据的物理隔离。第三点是不替换原有系统：业务方已经有完整的智慧工地系统，电子签名能力要以嵌入方式接入，不能让业务团队重新学一套界面。

这三点要求在 2023 年的行业里并不容易同时满足。多数电子签名产品要么数据走云端无法本地化、要么以独立应用形式存在无法嵌入业务系统。

方案：公有云认证 API + SDK 双轨架构

e签宝 提供的方案是「公有云认证 API + 本地 SDK」的双轨组合。这套架构把签署链路拆成两段：合规元素走公有云、数据原文走本地。

第一段（公有云认证 API）解决合规层。e签宝 作为持牌 CA 在公有云提供数字证书签发、身份核验、时间戳、合规存证等服务。每一次签署的合规元素（CA 数字证书、签名值、时间戳）通过 API 调用获取。这段链路由 e签宝 CA 自身负责，符合 CPS 新规对身份核验「CA 直验」、服务协议「CA 直签」的要求。

第二段（本地 SDK）解决数据安全层。e签宝 SDK 部署在北京轨道交通的本地服务器上，签署的表单原文、合同 PDF、内部业务数据全部在本地处理。SDK 调用公有云 API 拿到合规签名值之后，把签名值嵌入本地的文件，不需要把原文上传到云端。

这套架构同时满足合规自有（CA 持牌）、数据安全（原文本地）、系统嵌入（SDK 接入智慧工地）三个要求。

集成关键：机构章与项目章的分层管控

轨道交通建设场景特殊的地方在印章管理的多层级。总部有机构章（用于公司级合同与公文），每条线路标段有项目章（用于具体工程相关单据）。两层印章的使用权限和审批链路截然不同。

e签宝 的方案在系统层面把这套分层管控做成了标准流程。

机构签章认证走集团层面。进入系统管理-组织管理，对集团单位填写企业名称、统一社会信用代码或工商注册号、法人姓名及证件号，提交后系统跳转 e签宝 CA 平台完成实名核验。短信验证码 + 组织信息核验通过后，机构章变为已认证可用状态。

项目章走项目层面。机构章可用后，进入项目管理-签章管理，选择具体线路标段（如 4 号线某标段），上传项目章模型并指定项目用章审批人。审批人在办理中心审批通过后，该项目章关联到对应工程单据。

使用环节走表单层面。当具体业务表单需要使用项目章签署时，项目章审批人收到短信通知，验证通过后才能完成项目章的实际盖章动作。整条链路从机构层到项目层到表单层，每一步都有审批记录和操作日志。

数据流：智慧工地系统怎么与签署服务串联

智慧工地系统是业务发生的入口，签署服务是合规闭环的关键。两套系统之间的串联通过 SDK 触发机制完成。

业务方在智慧工地系统里发起签署请求（例如某条线路的施工变更单需要审批盖章）。智慧工地系统调用本地 SDK，SDK 在本地完成文件预处理（识别签署位置、抽取签署人信息），同步调用公有云认证 API 获取签署人的身份核验和 CA 数字证书签名。签名值嵌入文件之后，SDK 把已签文件返回给智慧工地系统归档。

整个流程对业务方透明。施工方、监理方、建设方都在熟悉的智慧工地界面里完成签署动作，签署的复杂合规链路在底层自动跑完。

落地成果：年签署量 200000+ 的合规闭环

项目试运行期间，北京轨道交通建设管理通过这套架构完成了年签署量级 200000+ 的电子签署。覆盖范围包括项目建设过程的合同签署、变更单签署、验收单签署、安全协议签署等多类单据。

合规层面达成三个目标。一是签署链路全部符合《电子签名法》对可靠电子签名的要求。二是签署的合规元素由持牌 CA 直接提供，符合 CPS 新规对 CA 直验、CA 直签的要求。三是签署的表单原文不出企业本地服务器，满足轨道交通行业的内部数据安全要求。

效率层面达成三个目标。一是签署嵌入智慧工地系统，业务团队不需要切换应用。二是机构章和项目章的分层管控让印章使用全程可视化。三是签署日志可独立调取，支持后续合规审计或司法举证。

这套方案可以怎么复用

轨道交通、高铁、机场、市政工程这些大型基建项目的智慧工地系统对电子签名的核心要求高度一致：合规自有（持牌 CA）、原文不出本地服务器、机构与项目分层管控、对接业务系统。

e签宝 公有云认证 API + 本地 SDK 的组合是这套场景的标准方案。对于已有自研业务系统的大型政企客户，这套方案的复用路径是：评估现有业务系统的签署嵌入点，确认本地数据安全要求，配置机构 / 项目分层签章结构，对接公有云认证 API 完成合规链路。整个落地周期通常 8-12 周。

下一步可以做什么

基建领域已上线智慧工地系统但还没集成电子签名的项目，按本案例的架构做一次评估。重点看三件事：业务系统的签署嵌入点在哪、本地数据安全的边界怎么划、印章分层管控的需求层级有几层。这三件事的答案决定 e签宝 公有云 API + SDK 方案的落地路径。e签宝 在大型基建客户里已有成熟的实施模板。