DPP Series | Part 2: DPP 深度解析：企业如何使用、规划应用并进行集成

数字产品护照（DPP）常被介绍为一项产品信息要求。对于准备在欧盟销售受监管产品的企业而言，这种描述并不完整。一个可运行的 DPP 方案必须将受治理的产品数据与产品标识符、负责组织、访问控制、可验证提交以及长期维护记录的系统连接起来。

这篇 eSign.AI DPP 系列的第二篇文章，将从监管认知推进到运营设计。文章说明企业可能在何处使用 DPP，如何决定哪些团队和系统应负责各项义务，以及电子签名、电子印章和证据留存可在何处支持可信流程。

从业务事件开始，而不是从二维码开始

二维码或其他数据载体是通向护照的可见入口，但它不是护照的运营模型。第一个设计问题是：什么业务事件会创建或变更产品记录。根据产品和适用法律，该事件可能是将产品投放欧盟市场、注册经济运营商、签发符合性文件、更新维修信息，或记录生命周期事件。

每个事件都需要一个负责所有者。产品团队可能负责技术属性，合规团队可能批准受监管声明，运营团队可能管理标识符，IT 团队可能连接源系统。如果没有人负责该事件，护照就可能变成一次性的静态发布工作，而不是持续维护的合规记录。

欧盟委员会的 ESPR 工作计划有助于企业识别优先产品组，但产品特定的授权法案将决定详细的数据、时间安排和运营义务。

映射 DPP 就绪的四个层面

企业可以围绕四个相互连接的层面来组织准备工作：

1. **产品数据：**识别所需属性、来源、数据所有者、更新规则和质量控制。
2. **产品身份：**定义唯一的产品、批次或单件标识符，并将其连接到正确的实体数据载体。
3. **组织与主管机构：**确定哪个法律实体提交信息，哪些人员或系统可以代表其行动，以及这些权利如何被验证。
4. **信任与连续性：**保留谁批准或提交信息的证据，保护完整性，控制访问，并在所需期间内保持记录可用。

该模型可避免一个常见的规划错误：在确认企业是否能够可靠地产出、批准和维护底层信息之前，就购买前端护照工具。

场景 1：经济运营商入驻

在组织可以提交受监管数据之前，相关系统可能需要确认其法律身份，以及代表其行动的人员或系统的权限。具体路径取决于适用法律和平台设计。它可能涉及电子身份识别方式、电子证明、文件证据，或由合格证书支持的合格电子印章。

重要的区分在于身份与许可。证明一家公司存在，并不自动证明某位特定员工、服务账户或外部代表可以代表该公司提交数据。稳健的入驻流程会同时记录组织身份，以及授权某项操作的委派或角色。

Commission Implementing Regulation (EU) 2026/1778 为欧盟 DPP 注册系统提供了一个具体示例。它规定了经济运营商和其他参与者的身份与访问安排，包括面向自然人的高保障路径，以及面向法人的合格电子印章或电子证明。经验证的经济运营商仍对其提交的数据负责。

场景 2：批准并提交 DPP 信息

产品信息通常来自多个系统：产品生命周期管理、企业资源计划、制造执行、质量管理、供应商门户和文档库。如果权威来源已经存在，DPP 工作流不应要求用户在另一个界面中手动重新创建这些信息。

相反，运营设计可以汇总所需数据集，验证必填字段，将例外情况路由给正确的负责人，并在提交前捕获批准。在需要签名或印章的情况下，工作流应调用适当的信任服务，同时避免将业务批准与法律上的合格签名或合格印章混淆。

eSign.AI 可以通过连接源系统、路由审批任务、应用所需的签名或加盖印章路径，并记录由此产生的交易证据，来支持工作流层。通过其 Registration Authority 服务以及与 ANF AC 的集成，eSign.AI 可将 QSeal 申请和签发路径作为客户解决方案的一部分提供，而不是让客户自行协调单独的海外提供商。

场景 3：长期保留可验证性

DPP 义务并不限于发布时刻。产品信息可能需要在漫长的产品生命周期、所有权变更和系统迁移过程中保持可用、可理解且可信。因此，企业应规划持久证据，而不是把一次成功的 API 响应视为流程结束。

证据设计可以包括已提交的数据集或其规范表示、时间戳、签名或印章验证材料、签署人或运营商上下文、授权记录、交付回执、版本历史和系统日志。留存期限和验证方法必须与适用的产品规则和记录政策相匹配。

欧盟框架赋予合格电子印章对数据完整性和来源正确性的法律推定，而合格时间戳可以支持证明数据在特定时间已经存在。只有列入欧盟国家信任列表且具有合格状态的服务才属于合格服务。

规划说明：这张源自 Word 的插图呈现了一个用于讨论的行业与时间路线图。它并不是适用于每一种所示产品的法律时间表。具有约束力的范围、身份路径、证明格式、数据要求和适用日期，由相关欧盟产品法律、产品特定授权法案以及最终系统设计确定。

每条产品线的五个规划问题

1. 产品是否在适用范围内？

建立产品与规则对应登记表，识别相关欧盟法律、当前状态、预期授权法案和负责法律实体。不要假设企业层面的 DPP 方案意味着每种产品都遵循相同的时间表。

2. 谁负责每个必需的数据元素？

为每个强制属性分配源系统和业务负责人。如果某个值来自供应商，应定义验证、升级和变更控制规则，而不是通过电子邮件接受未经验证的文件。

3. 产品如何被唯一识别？

决定规则是在型号、批次还是单件层面运作。确认标识符如何生成、如何防止重复，以及实体数据载体如何始终连接到正确的数字记录。

4. 谁可以批准和提交？

记录所涉及的法律实体、负责角色、委派模型和机器凭证。将内部批准、外部提交以及法律要求的任何合格信任服务区分开来。

5. 系统变更后必须保留哪些证据？

在实施前定义证据包。答案将决定存储架构、导出格式、验证依赖和迁移控制。

面向实际实施的集成蓝图

实用架构通常从源系统开始，而不是从一个新的独立数据库开始。数据服务检索已批准的产品属性，工作流服务验证完整性并路由例外情况，身份与授权层验证行为者，API 层将正确的载荷提交到相关注册系统或护照服务。

证据层应捕获每个重大事件，同时避免存储不必要的个人数据。它还应支持按产品、交易、法律实体和时间段检索，以便合规团队能够高效回应审计或争议。

分阶段实施通常更安全。选择一个产品系列，映射其数据和法律要求，与代表性用户测试完整工作流，然后再扩展。这可以创建可复用的控制措施，同时让产品特定差异保持可见。

eSign.AI DPP 解决方案中的两条签名路径

第一条路径是经济运营商验证。eSign.AI 通过其 Registration Authority 能力和 ANF AC 集成，支持 QSeal 申请、身份验证协调和组织数据匹配。这对于需要使用欧盟信任列表中的合格电子印章来完成面向注册系统身份流程的非欧盟制造商尤其相关。

第二条路径是重复发生的产品数据工作流。eSign.AI 支持面向 PDF 文件的 PAdES，以及面向 XML 和 JSON 记录的 XAdES 或 JAdES 长期签名配置文件，并包括合格时间戳和证据留存。确切格式和保障级别应依据产品特定规则、注册系统接口以及客户的法律评估确定；并非每个 DPP 事件都使用同一种签名。

对于更高交易量，客户可以通过 SDK 或 API 连接，而不是手动签署每条记录。当接收流程支持批量提交时，一次操作可以打包多条 DPP 记录，同时保留记录级标识符和证据。对于在完成系统集成前需要运营界面的团队，eSign.AI 也支持 SaaS 工作流。

eSign.AI 的作用

eSign.AI 支持电子签名和数字签名工作流、审批编排、API 集成和证据留存。对于 DPP 方案，这些能力可以帮助将业务系统连接到签名或加盖印章步骤，捕获运营商事件，并保留可追溯的工作流记录。

eSign.AI 的交付范围可包括 QSeal 申请与签发支持、注册系统入驻指导、PAdES/XAdES/JAdES 签名、合格时间戳、SaaS 与 API 集成，以及长期证据。产品数据治理仍由客户负责，而 eSign.AI 提供所需的信任与执行层，帮助正确的数据通过正确的签名路径流转，并留存证据以供后续验证。

继续阅读 DPP 系列

阅读第 1 部分：中国出口商为何需要为欧盟数字产品护照做好准备，了解监管和行业背景。

第 2 部分：DPP 深度解析：企业如何使用、规划应用并进行集成（本文）

继续阅读第 3 部分：从 eCoC 到 QSeal：eSign.AI 如何支持 DPP 就绪，进一步了解可信工作流、QSeal 集成和 eSign.AI 的作用。