DPP Series | Part 3: 從 eCoC 到 QSeal：eSign.AI 如何支援 DPP 就緒準備

數位產品護照（DPP）正變得不只是產品資料專案。2026 年 7 月 17 日，歐盟發布了 Commission Implementing Regulation (EU) 2026/1778，為 Ecodesign for Sustainable Products Regulation 下的 DPP registry 建立詳細的實施安排。該法規使身分、授權、API、驗證與持久證明成為營運圖像的一部分。

對製造商與出口商而言，這改變了準備就緒的討論重點。問題不再只是產品資料是否存在。企業也需要知道是哪一個法律實體提交資料、如何驗證授權行為者、系統如何交換資料，以及哪些證據能證明登錄與提交事件已發生。

這篇 eSign.AI DPP 系列的最終文章說明，電子符合性證書（eCoC）、QSeal 交付、長期簽章與 API 工作流程，如何結合成實務 DPP 就緒解決方案。

2026 年 7 月 DPP registry 規則新增了什麼

Regulation (EU) 2026/1778 說明歐盟執委會將如何運作 DPP registry 與驗證平台。其涵蓋存取控制、經濟營運者註冊、驗證、唯一註冊識別碼、API 型介面、日誌與註冊證明。

對自然人而言，該法規提供高保證身分路徑，可包括合格電子簽章、高保證電子身分識別方案，或合格電子屬性證明。對法律人而言，其提供的路徑包括由合格信任服務提供者核發的合格憑證所支援的合格電子封章，或電子證明路徑。

該法規也指出，已驗證的經濟營運者仍須對其提交的資料負責。技術可以建立受控流程並保存證據，但不會將產品資訊的法律責任從營運者身上轉移出去。

在設計面向 registry 的控管時，應使用 Commission Implementing Regulation (EU) 2026/1778 的正式文本。

為什麼 eCoC 經驗具有相關性

電子符合性證書與數位產品護照是不同的工具。eCoC 支援車輛符合性與登記流程，而 DPP 則根據適用於某一產品群組的法規提供產品資訊。資料模型、主管機關與法律要求不可互換。

然而，兩者都揭示了相同的營運挑戰：受監管的產品資料必須從權威業務系統移入外部數位流程，同時保留身分、完整性與證據。已經將製造資料、核准工作流程與可信簽署連接到 eCoC 流程的企業，具備可用於 DPP 就緒準備的實用構件。

這些構件包括受控主資料、清晰的法律實體所有權、基於角色的核准、API 監控、例外處理、證據匯出與長期留存。重用控管比嘗試重用整個產品特定解決方案更有價值。

QSeal 是信任服務，而不是軟體標籤

合格電子封章，通常簡稱為 QSeal，是符合 eIDAS 合格狀態要求的電子封章。它使用合格電子封章建立裝置產生，並以電子封章的合格憑證為基礎。根據 eIDAS，它享有資料完整性與來源正確性的推定效力。

合格狀態不能由行銷聲明或工作流程設定創造。提供者及其合格服務必須出現在適用的歐盟國家信任清單中。eSign.AI 透過其 Registration Authority 服務及與 ANF AC 的整合處理此要求；ANF AC 核發合格電子封章，並在歐盟信任框架中列為合格提供者。

對客戶而言，這意味著 eSign.AI 可將 QSeal 申請與核發旅程作為 DPP 或 eCoC 解決方案的一部分交付：組織文件收集、身分驗證協調、憑證資料比對、封章啟用，以及整合進簽章工作流程。客戶不需要另外自行組建海外信任服務路徑。

eSign.AI 如何支援與 QSeal 相關的就緒準備

第一項能力是 QSeal onboarding。eSign.AI 可引導組織完成申請文件包與驗證流程，協調 Registration Authority 步驟，並將 ANF AC 核發的 QSeal 連接至所需的業務工作流程。

第二項能力是可信簽章。eSign.AI 支援 PDF 文件的 PAdES 工作流程，以及結構化 XML 或 JSON 資料的 XAdES/JAdES 長期簽章設定檔。合格時間戳記與留存的驗證證據，有助於讓紀錄在原始憑證生命週期之後仍可驗證。

第三項能力是系統整合。DPP 或 eCoC 流程可能始於 PLM、ERP 或其他記錄系統。eSign.AI 可接收業務事件、驗證必要工作流程欄位、路由核准、透過 SaaS、SDK 或 API 套用 QSeal 或簽章，並留存已簽署物件、時間戳記、交易日誌與完成證據。

概念性的經濟營運者 onboarding 流程

工作流程說明：此 Word 來源圖示為概念性說明，並非 EU DPP Registry 介面。在 eSign.AI 的交付模型中，合格封章透過 ANF AC 核發，並透過 eSign.AI 的 Registration Authority 與整合服務納入客戶工作流程。實際身分方法、證明格式與授權步驟，均遵循適用的歐盟規則與最終 registry 設計。

onboarding 工作流程可以從相關公司來源收集的法律實體資訊與支援記錄開始。授權代表審查註冊文件包，並在管轄規則要求時，由已設定的信任服務步驟套用必要的簽章或封章。

接著，系統透過適用介面提交該文件包並保留回應。根據 Regulation (EU) 2026/1778，成功完成 registry 註冊會產生唯一註冊識別碼，以及一份透過歐盟執委會信任服務保護的安全電子文件中的註冊證明。

此流程必須將三類記錄分開：組織身分證明、行為者已獲授權的證明，以及外部系統接受或註冊提交的證明。將它們合併成一個籠統的「已簽署」狀態，會使後續稽核與疑難排解變得困難許多。

API 整合與批次處理

製造商可能需要註冊大量產品或實體，並大規模維護護照資料。對於高量方案而言，手動入口網站作業不能成為主要營運模式。API 整合應支援已驗證的請求、確定性識別碼、冪等性、驗證、回應追蹤與受控重試。

批次處理不應意味著一個不透明的批量作業。每個項目都需要可追蹤的狀態與證據軌跡，以便在不重新提交成功項目的情況下隔離失敗記錄。監控應區分資料品質錯誤、授權失敗、信任服務失敗與外部平台可用性。

eSign.AI 連接客戶業務系統、合格簽章與封章服務，以及面向 registry 的提交工作流程。歐盟執委會營運 DPP Registry；eSign.AI 提供客戶端的 QSeal、簽章、整合與證據能力，以準備並執行這些流程。

企業現在即可實施的就緒架構

企業不需要等到每一項授權法案完成後，才改善基礎。它們可以建立產品與規則登記冊、映射來源系統、定義識別碼治理、記錄法律實體所有權，並建立可重用的核准與證據控管。

合理的架構會將產品資料與工作流程控制分開，同時將兩者連接至可信簽章服務。產品資料保留在權威系統或受治理的資料服務中。eSign.AI 協調驗證與核准，交付 ANF AC QSeal 路徑，套用所需的 PAdES/XAdES/JAdES 簽章或合格時間戳記，並保存結果與脈絡。

這種分離避免供應商鎖定，並允許不同產品群組使用不同法律路徑，同時共享整合、監控與證據能力。

選擇解決方案前的三項檢查

首先，詢問該解決方案是否區分普通電子簽章或封章與合格服務。如果每個信任動作都被呈現為等同，法律與採購團隊便無法做出知情決策。

其次，詢問該解決方案是否同時提供合格服務路徑與有文件記載的 API。DPP 方案不應迫使客戶在彼此斷開的提供者與入口網站之間協調憑證核發、簽章與產品資料提交。

第三，詢問證據是否可以匯出並獨立驗證。如果工作流程平台、信任提供者或內部系統發生變更，合規記錄仍必須可用。

eSign.AI 在 DPP 就緒準備中的角色

eSign.AI 為 DPP 與 eCoC 周邊的信任層提供端到端客戶解決方案：透過其 Registration Authority 服務與 ANF AC 整合支援 QSeal 申請與核發、PAdES/XAdES/JAdES 簽章、合格時間戳記、SaaS/SDK/API 連接、面向批次的處理，以及長期證據留存。

對製造商而言，實務優勢在於從組織驗證到重複性產品資料簽章的一條交付路徑。客戶可在 eCoC 與 DPP onboarding 中使用同一套 QSeal 基礎，在需要時加入長期結構化資料簽章，並將流程連接至生產系統，而不必建立另一套信任服務技術棧。

完成 DPP 系列

從 第 1 部分：為什麼中國出口商需要為歐盟數位產品護照做好準備 開始，了解範圍、時程與產業背景。

接著閱讀 第 2 部分：DPP 深度解析：企業如何使用、規劃用途並進行整合，了解實務營運與整合模型。

第 3 部分：從 eCoC 到 QSeal：eSign.AI 如何支援 DPP 就緒準備（本文）