社團法人台灣循環經濟與創新轉型協會 理事 劉坤興博士
1. 引言：DPP 導入瓶頸，常是溝通落差
在國際推動循環經濟的脈絡中，「產品數位護照（DPP）」經常被視為提升回收效率、促進再生料使用、強化合規與揭露的一項新工具。目前環境部資源循環署亦將產品數位護照的推動，列入10大關鍵推動項目之中。
然而，筆者協助推動資源循環署產品數位護照計畫，在試行了三年後，認知許多組織在真正啟動 DPP 導入時，最先遇到的阻力往往不是資料格式、不是系統選型，而是跨部門之間缺乏共同語言：ESG/永續、法遵、供應鏈、品質單位，與 IT/資訊單位看待「DPP 專案」的問題框架不同，導致工程化需求規劃困難、不好規劃交付項目。
ESG人員通常以政策與治理語彙描述目標，例如「要可追溯」「要可揭露」「要能支援回收端」「要可以稽核/具備第三方查證資訊」。這些描述在永續治理上非常正確，但對IT人員而言仍然過於抽象，例如：可追溯到什麼粒度(Granuality)？追溯的是材料、批次、單品序號，還是流向事件？可揭露的範圍是全部公開，還是分成公開與受限？回收端要用到的是拆解指引、危害警示、材料成分、或維修事件？稽核是要追溯護照內容「何時由誰更新」，還是要記錄「誰讀取過哪些資料」？
反過來，IT人員在提出設計選項時，會回到系統工程問題：身分驗證、權限控管、API、資料庫、版本控制、稽核留痕、資安與可用性（availability）。但這些語彙如果沒有對應到ESG方面的治理需求，也容易被誤解成「把問題複雜化」或「做太多」。於是專案常出現兩種典型結果：一種是做出「能展示的頁面」，但缺少資料治理與更新機制，難以支撐循環治理；另一種是進入「過度設計」與不斷地系統重新規劃討論，成本與時程失控。
因此，DPP 導入的第一個關鍵不是立刻決定要用哪個平台，而是建立一套能工程化的ESG目標、可治理化之 IT 交付項目的共同語言。本文接下來的目的，就是根據過去試行經驗，嘗試提供一個可操作的對齊框架：先把 DPP 的「可用」定義為可驗收的條件（第2節），再提出 ESG人員與IT人員對齊時必答的六個核心問題（第3節），讓跨部門討論能落在同一張地圖上，在第4節中整理了一個翻譯表，期望降低ESG與IT人員在DPP建置時的落差。
2. 聚焦一句話：DPP 的「可用性」到底指什麼？
在跨部門協作中，「可用性」是最容易造成誤解的詞。對ESG人員而言，「可用性」可能意味著外部利害關係人看得懂、符合揭露要求、能支援回收維修決策；對IT人員而言，「可用性」則首先意味著系統穩定、資料可查、權限可控、變更可追溯。若不先對齊，「可用性」就會在會議中被反覆引用，卻無法形成具體的工作項與里程碑。
建議在 DPP 專案啟動時，用一句話把「可用性」翻譯成同時涵蓋治理與工程的定義，例如：
一個可用的 DPP，是能以唯一識別碼被掃描定位、同時提供人可讀與機器可讀資訊，並具備公開/受限分層、版本可回溯與稽核留痕的資料服務。
這句話的重點在於，它把DPP從「內容」拉回到「服務」：不是只問「要揭露哪些資料」，還要問「資料如何使用、如何更新、如何信任」。以此定義為基礎，跨部門可以更容易建立共識：
- ESG/法遵可以把焦點放在：哪些欄位是必揭露、哪些需受限、資料責任與審核流程如何設計；
- IT/資安可以把焦點放在：識別碼與路由(Route)策略、API介面、權限控管、版本策略、稽核記錄與營運可用性。
更重要的是，這句話形成「可驗收」的方向：例如掃碼能否穩定導到護照？是否同時有頁面與 JSON/API？是否能分層[1]？更新是否會產生版本？是否能查出誰在何時做了更動？一旦可用被定義成可驗收條件，ESG 與 IT 的討論就有機會從抽象的討論，落到可交付成果與風險控管。
3. ESG人員與IT人員的共同語言：把需求拆成 6 個問題（溝通骨架）
為了避免「ESG人員講目標、IT人員講技術」各據一詞，筆者認為有效的方法，可能是建立一組固定問題，讓每一次討論都能把需求「工程化」。筆者透過AI協助，整理以下六題建議作為DPP導入討論的最小骨架；每一題都同時包含 ESG 決策點與 IT 設計輸入。
3.1 要覆蓋哪些產品與層級？
- ESG要決策：先從哪些產品、哪些市場、哪些生命周期階段開始（製造、使用、維修、回收）？
- IT要釐清：護照是「型號層（model）」還是「單品層（item）」？若要到單品層，必須有序號/UID 與事件資料模型，工作量與資料責任會顯著增加。
3.2 哪些資料公開？哪些資料受限？
- ESG要決策：揭露義務與商業敏感度如何平衡？哪些欄位對消費者/回收端必須公開？哪些應只對主管機關、驗證機構或合作回收商開放？
- IT要落地：需不需要權限控管（RBAC/ABAC[2]）？受限資料如何存取與加密？如何記錄存取行為（audit of access）？
3.3 資料從哪裡來？誰是 source of truth？
- ESG要決策：每個欄位由哪個部門/供應商負責？哪些數據需要第三方證明或文件佐證？
- IT要釐清：資料來源系統是 ERP、MES、PLM、LCA 平台、文件管理系統，還是人工上傳？若 source of truth 不明，DPP 很容易變成「另做一份」的資料孤島。
3.4 資料多久更新？更新流程與審核如何設計？
- ESG要決策：哪些欄位是一次性（例如材料宣告），哪些會定期更新（例如碳足跡、回收料含量），哪些是事件型（維修、回收）？審核流程由誰負責？
- IT要落地：是否需要「草稿—審核—發布」流程？更新是否自動產生新版本？是否需要通知機制與變更紀錄？
3.5 要追溯到什麼程度？版本與事件的邊界是什麼？
- ESG要決策：追溯需求是為了合規稽核、為了回收拆解、還是為了供應鏈透明？不同目的對粒度要求不同。
- IT要落地：版本控制（immutable versions）如何設計？事件資料（event log）如何追加、如何查詢、如何避免被事後改寫？
3.6 要做到可驗證嗎？需要哪些信任機制？
- ESG要決策：哪些資訊需要被外部信任（例如再生料含量、碳足跡方法、限制物質聲明）？是否需要第三方驗證？
- IT要評估：要做到哪種程度的可驗證性（例如 hash、數位簽章、可驗證憑證 VC）？信任機制會影響資料模型、證據文件管理與整合方式。
以上六題的用意，是把DPP導入從「概念認同」拉回到「治理與工程的可執行問題」。當 ESG人員能以這六題釐清需求，IT人員才能進行架構設計、估時估工與資安評估；而當IT人員能用這六題回應交付內容，ESG人員才能判斷是否符合揭露與循環治理目的。換言之，這六題本身就是跨部門的共同語言，也是後續建立驗收條款、導入路線圖與責任分工（RACI）的基礎。
後續在第4節中整理了一個翻譯表，期望降低ESG與IT人員在DPP建置時的落差。
敬請期待下篇專欄文章的精彩內容！
[1] 能分層是指：同一份 DPP 的資訊要能被系統按資料敏感度與使用者身分拆成不同層級來提供，而不是「全部公開」或「全部不公開」。
[2] RBAC（Role-Based Access Control） 是以「角色」分配權限的存取控制方法：使用者被指派到某個角色（如 public、verifier、admin），系統依角色決定可讀寫哪些資料與功能。 ABAC（Attribute-Based Access Control） 是以「屬性＋規則」決定權限的存取控制方法：系統綜合使用者屬性、資源屬性與環境條件（例如公司別、合約有效、資料分類、地區、時間）來判斷是否允許存取。在 DPP 等跨部門/跨組織情境中，實務上可採「先 RBAC 後 ABAC」：先用角色建立最小可行的權限邊界，再逐步加入屬性規則以支援更細緻的供應鏈協作與合規需求。
精選圖片來源：https://digital-link.com/