DPP Series | Part 2: DPP 深度解析：企業如何使用、規劃用途並整合

數位產品護照（DPP）常被介紹為一項產品資訊要求。對於準備在歐盟銷售受監管產品的企業而言，這種描述並不完整。一套可運作的 DPP 方案，必須將受治理的產品資料與產品識別碼、負責任的組織、存取控制、可驗證的提交，以及長期維護紀錄的系統連接起來。

這是 eSign.AI DPP 系列的第二篇文章，將重點從法規認知推進到營運設計。本文說明企業可能在哪些情境使用 DPP，如何決定哪些團隊與系統應負責各項義務，以及電子簽章、電子封章與證據留存可在何處支援可信賴的流程。

從業務事件開始，而不是從 QR code 開始

QR code 或其他資料載體是護照的可見入口，但並不是護照的營運模式。第一個設計問題，是哪一個業務事件會建立或變更產品紀錄。視產品與適用法規而定，該事件可能是在歐盟市場投放產品、註冊經濟營運者、核發符合性文件、更新維修資訊，或記錄生命週期事件。

每個事件都需要一位負責任的所有者。產品團隊可能負責技術屬性，合規團隊可能核准受監管聲明，營運團隊可能管理識別碼，IT 團隊可能連接來源系統。當沒有人負責該事件時，護照可能會從一份持續維護的合規紀錄，變成一次性的靜態發布作業。

歐盟執委會的 ESPR 工作計畫可協助企業識別優先產品群組，但產品專屬的授權法案將決定詳細的資料、時程與營運義務。

對應 DPP 準備度的四個層面

企業可以圍繞四個相互連接的層面來安排準備工作：

1. **產品資料：**識別必要屬性、來源、資料所有者、更新規則與品質控制。
2. **產品身分：**定義唯一的產品、批次或單品識別碼，並將其連接至正確的實體資料載體。
3. **組織與主管機關：**確立哪個法律實體提交資訊、哪些人員或系統可代表其行事，以及這些權利如何被驗證。
4. **信任與持續性：**保留誰核准或提交資訊的證據、保護完整性、控制存取，並在所要求的期間內保持紀錄可用。

這個模型可避免常見的規劃錯誤：在確認企業是否能可靠產出、核准並維護底層資訊之前，就先購買前端護照工具。

情境 1：經濟營運者 onboarding

在組織能夠提交受監管資料之前，相關系統可能需要確立其法律身分，以及代表其行事的人員或系統的權限。確切路徑取決於主管法規與平台設計。這可能涉及電子識別方法、電子證明、文件證據，或由合格憑證支持的合格電子封章。

重要的區別在於身分與許可。證明一家公司存在，並不會自動證明某位特定員工、服務帳號或外部代表可代表該公司提交資料。一套穩健的 onboarding 流程，會同時記錄組織身分，以及授權某項行動的委任或角色。

Commission Implementing Regulation (EU) 2026/1778為歐盟 DPP registry 提供了一個具體範例。它規定了經濟營運者及其他參與者的身分與存取安排，包括自然人的高保證路徑，以及法律人的合格電子封章或電子證明。經驗證的經濟營運者仍須對其提交的資料負責。

情境 2：核准並提交 DPP 資訊

產品資訊通常來自多個系統：產品生命週期管理、企業資源規劃、製造執行、品質管理、供應商入口網站與文件儲存庫。如果已有權威來源存在，DPP 工作流程不應要求使用者在另一個介面中手動重新建立該資訊。

相反地，營運設計可以組合所需資料集、驗證必填欄位、將例外情況路由給正確的所有者，並在提交前擷取核准。當需要簽章或封章時，工作流程應呼叫適當的信任服務，而不應將業務核准與法律上的合格簽章或封章混淆。

eSign.AI 可透過連接來源系統、路由核准任務、套用所需的簽章或封章路徑，並記錄產生的交易證據，來支援工作流程層。透過其 Registration Authority 服務及與 ANF AC 的整合，eSign.AI 可提供 QSeal 申請與核發路徑，作為客戶解決方案的一部分，而不讓客戶自行協調另一家海外提供者。

情境 3：長期保存可驗證性

DPP 義務並不限於發布當下。產品資訊可能需要在漫長的產品生命週期、所有權變更與系統遷移期間，保持可用、可理解且可信賴。因此，企業應規劃耐久的證據，而不是把一次成功的 API 回應視為流程終點。

證據設計可包括已提交的資料集或其標準表示、時間戳記、簽章或封章驗證材料、簽署者或營運者背景、授權紀錄、送達回執、版本歷史與系統日誌。留存期間與驗證方法必須與適用的產品規則及紀錄政策相匹配。

歐盟框架賦予合格電子封章資料完整性與來源正確性的法律推定，而合格時間戳記則可支援資料在特定時間已存在的證明。只有列於歐盟國家信任清單中且具合格身分的服務，才具有合格狀態。

規劃說明：這張來自 Word 來源的示意圖呈現供討論用的產業與時程路線圖。它並非每一項所示產品的法律時程。具約束力的範圍、身分路徑、證明格式、資料要求與適用日期，均由相關歐盟產品法規、產品專屬授權法案與最終系統設計確立。

每條產品線的五個規劃問題

1. 產品是否在範圍內？

建立產品對應規則的登錄表，識別相關歐盟法規、目前狀態、預期授權法案與負責的法律實體。不要假設公司層級的 DPP 方案代表每項產品都遵循相同時程。

2. 誰負責每個必要資料元素？

為每項強制屬性指定來源系統與業務所有者。如果某個值來自供應商，應定義驗證、升級處理與變更控制規則，而不是接受透過電子郵件寄來的未驗證檔案。

3. 產品如何被唯一識別？

決定規則是在型號、批次或單品層級運作。確認識別碼如何產生、如何防止重複，以及實體資料載體如何保持與正確數位紀錄的連接。

4. 誰可以核准並提交？

記錄所涉及的法律實體、負責角色、委任模型與機器憑證。將內部核准、外部提交，以及法律所要求的任何 qualified trust service 區分開來。

5. 哪些證據必須在系統變更後仍然保留？

在實施前定義證據包。答案將決定儲存架構、匯出格式、驗證依賴關係與遷移控制。

實務實施的整合藍圖

實務架構通常從來源系統開始，而不是從新的獨立資料庫開始。資料服務擷取已核准的產品屬性，工作流程服務驗證完整性並路由例外情況，身分與授權層驗證行為者，而 API 層則將正確的 payload 提交至相關 registry 或護照服務。

證據層應擷取每個重大事件，而不儲存不必要的個人資料。它也應支援依產品、交易、法律實體與期間進行擷取，使合規團隊能有效回應稽核或爭議。

分階段實施通常更安全。選擇一個產品系列，對應其資料與法律要求，與代表性使用者測試完整工作流程，然後再擴展。這會建立可重複使用的控制，同時讓產品專屬差異保持可見。

eSign.AI DPP 解決方案中的兩條簽章路徑

第一條路徑是經濟營運者驗證。eSign.AI 透過其 Registration Authority 能力與 ANF AC 整合，支援 QSeal 申請、身分驗證協調與組織資料比對。這對需要歐盟信任清單合格電子封章以完成面向 registry 身分流程的非歐盟製造商尤其相關。

第二條路徑是重複性的產品資料工作流程。eSign.AI 支援 PDF 文件的 PAdES，以及 XML 和 JSON 紀錄的 XAdES 或 JAdES 長期簽章設定檔，包含合格時間戳記與證據留存。確切格式與保證等級應遵循產品特定規則、registry 介面與客戶的法律評估；並非每一個 DPP 事件都使用相同簽章。

對於較高交易量，客戶可透過 SDK 或 API 連接，而不是手動逐筆簽署紀錄。在接收流程支援批次提交時，一次操作即可封裝多筆 DPP 紀錄，同時保留紀錄層級的識別碼與證據。eSign.AI 也支援 SaaS 工作流程，供需要在完成系統整合前先取得營運介面的團隊使用。

eSign.AI 的定位

eSign.AI 支援電子簽章與數位簽章工作流程、核准編排、API 整合與證據留存。對於 DPP 方案而言，這些能力可協助將業務系統連接至簽章或封章步驟、擷取營運者事件，並保存可追溯的工作流程紀錄。

eSign.AI 的交付範圍可包括 QSeal 申請與核發支援、registry onboarding 指引、PAdES/XAdES/JAdES 簽章、合格時間戳記、SaaS 與 API 整合，以及長期證據。產品資料治理仍由客戶負責，而 eSign.AI 提供所需的信任與執行層，使正確資料能透過正確的簽章路徑流轉，並保留日後驗證所需的證據。

繼續閱讀 DPP 系列

閱讀第 1 篇：為什麼中國出口商需要為歐盟數位產品護照做好準備，了解法規與產業背景。

第 2 篇：DPP 深度解析：企業如何使用、規劃用途並整合（本文）

繼續閱讀第 3 篇：從 eCoC 到 QSeal：eSign.AI 如何支援 DPP 就緒準備，深入了解可信任工作流程、QSeal 整合與 eSign.AI 的角色。