DPP Series | Part 2: Pendalaman DPP: Bagaimana Perusahaan Menggunakannya, Merencanakan Penggunaan, dan Mengintegrasikannya

Digital Product Passport (DPP) sering diperkenalkan sebagai persyaratan informasi produk. Bagi perusahaan yang bersiap menjual produk teregulasi di Uni Eropa, deskripsi tersebut belum lengkap. Program DPP yang dapat dijalankan harus menghubungkan data produk yang dikelola dengan pengidentifikasi produk, organisasi yang bertanggung jawab, kontrol akses, pengajuan yang dapat diverifikasi, dan sistem yang memelihara catatan dari waktu ke waktu.

Artikel kedua dalam seri DPP eSign.AI ini beralih dari kesadaran regulasi ke desain operasional. Artikel ini menjelaskan di mana perusahaan dapat menggunakan DPP, bagaimana menentukan tim dan sistem mana yang harus memiliki tiap kewajiban, serta di mana tanda tangan elektronik, segel elektronik, dan retensi bukti dapat mendukung proses yang dapat dipercaya.

Mulailah dari peristiwa bisnis, bukan kode QR

Kode QR atau pembawa data lainnya adalah titik masuk yang terlihat ke sebuah paspor, tetapi itu bukan model operasional paspor. Pertanyaan desain pertama adalah peristiwa bisnis apa yang membuat atau mengubah catatan produk. Bergantung pada produk dan peraturan yang berlaku, peristiwa itu dapat berupa menempatkan produk di pasar UE, mendaftarkan operator ekonomi, menerbitkan dokumen kesesuaian, memperbarui informasi perbaikan, atau mencatat peristiwa siklus hidup.

Setiap peristiwa membutuhkan pemilik yang bertanggung jawab. Tim produk dapat memiliki atribut teknis, tim kepatuhan dapat menyetujui pernyataan teregulasi, tim operasi dapat mengelola pengidentifikasi, dan tim IT dapat menghubungkan sistem sumber. Ketika tidak ada yang memiliki peristiwa tersebut, paspor dapat menjadi sekadar latihan publikasi statis alih-alih catatan kepatuhan yang dipelihara.

Rencana kerja ESPR Komisi Eropa membantu perusahaan mengidentifikasi kelompok produk prioritas, tetapi delegated acts khusus produk akan menentukan data, waktu, dan kewajiban operasional yang terperinci.

Petakan empat lapisan kesiapan DPP

Perusahaan dapat menyusun persiapan di sekitar empat lapisan yang saling terhubung:

1. Data produk: mengidentifikasi atribut yang diwajibkan, sumber, pemilik data, aturan pembaruan, dan kontrol kualitas.
2. Identitas produk: menentukan pengidentifikasi produk, batch, atau item yang unik dan menghubungkannya ke pembawa data fisik yang benar.
3. Organisasi dan otoritas: menetapkan badan hukum mana yang mengajukan informasi, orang atau sistem mana yang dapat bertindak untuknya, dan bagaimana hak tersebut diverifikasi.
4. Kepercayaan dan kontinuitas: menyimpan bukti siapa yang menyetujui atau mengajukan informasi, melindungi integritas, mengontrol akses, dan menjaga catatan tetap tersedia selama periode yang diwajibkan.

Model ini mencegah kesalahan perencanaan yang umum: membeli alat paspor front-end sebelum memastikan apakah perusahaan dapat secara andal menghasilkan, menyetujui, dan memelihara informasi yang mendasarinya.

Skenario 1: onboarding operator ekonomi

Sebelum organisasi dapat mengajukan data teregulasi, sistem terkait mungkin perlu menetapkan identitas hukumnya dan otoritas orang atau sistem yang bertindak untuknya. Jalur yang tepat bergantung pada peraturan yang mengatur dan desain platform. Ini dapat melibatkan metode identifikasi elektronik, atestasi elektronik, bukti dokumenter, atau qualified electronic seal yang didukung oleh qualified certificate.

Perbedaan pentingnya adalah antara identitas dan izin. Membuktikan bahwa sebuah perusahaan ada tidak secara otomatis membuktikan bahwa karyawan tertentu, akun layanan, atau perwakilan eksternal tertentu dapat mengajukan data untuk perusahaan tersebut. Proses onboarding yang kuat mencatat baik identitas organisasi maupun delegasi atau peran yang mengotorisasi suatu tindakan.

Commission Implementing Regulation (EU) 2026/1778 memberikan contoh konkret untuk registri DPP UE. Regulasi ini menetapkan pengaturan identitas dan akses untuk operator ekonomi dan aktor lainnya, termasuk jalur dengan tingkat kepastian tinggi untuk orang perseorangan serta qualified electronic seals atau atestasi elektronik untuk badan hukum. Operator ekonomi yang telah diverifikasi tetap bertanggung jawab atas data yang diajukannya.

Skenario 2: menyetujui dan mengajukan informasi DPP

Informasi produk biasanya berasal dari beberapa sistem: manajemen siklus hidup produk, perencanaan sumber daya perusahaan, eksekusi manufaktur, manajemen kualitas, portal pemasok, dan repositori dokumen. Alur kerja DPP sebaiknya tidak meminta pengguna membuat ulang informasi tersebut secara manual di antarmuka lain jika sumber otoritatif sudah ada.

Sebagai gantinya, desain operasional dapat menyusun dataset yang diwajibkan, memvalidasi bidang wajib, mengarahkan pengecualian ke pemilik yang tepat, dan menangkap persetujuan sebelum pengajuan. Ketika tanda tangan atau segel diwajibkan, alur kerja harus memanggil layanan kepercayaan yang sesuai tanpa mencampuradukkan persetujuan bisnis dengan tanda tangan atau segel yang qualified secara hukum.

eSign.AI dapat mendukung lapisan alur kerja dengan menghubungkan sistem sumber, mengarahkan tugas persetujuan, menerapkan jalur penandatanganan atau penyegelan yang diwajibkan, dan mencatat bukti transaksi yang dihasilkan. Melalui layanan Registration Authority dan integrasi dengan ANF AC, eSign.AI dapat menyediakan jalur pengajuan dan penerbitan QSeal sebagai bagian dari solusi pelanggan, sehingga pelanggan tidak perlu mengoordinasikan penyedia luar negeri secara terpisah.

Skenario 3: menjaga keterverifikasian dari waktu ke waktu

Kewajiban DPP tidak terbatas pada momen publikasi. Informasi produk mungkin perlu tetap tersedia, dapat dipahami, dan dapat dipercaya sepanjang siklus hidup produk yang panjang, perubahan kepemilikan, dan migrasi sistem. Oleh karena itu, perusahaan harus merencanakan bukti yang tahan lama, bukan memperlakukan respons API yang berhasil sebagai akhir proses.

Desain bukti dapat mencakup dataset yang diajukan atau representasi kanonisnya, timestamp, materi validasi tanda tangan atau segel, konteks penanda tangan atau operator, catatan otorisasi, tanda terima pengiriman, riwayat versi, dan log sistem. Periode retensi dan metode validasi harus disesuaikan dengan aturan produk dan kebijakan catatan yang berlaku.

Kerangka UE memberikan qualified electronic seals praduga hukum atas integritas data dan kebenaran asal, sementara qualified timestamps dapat mendukung bukti bahwa data ada pada waktu tertentu. Hanya layanan yang terdaftar sebagai qualified dalam daftar tepercaya nasional UE yang memiliki status qualified.

Catatan perencanaan: ilustrasi sumber Word ini menyajikan peta jalan sektor dan waktu untuk diskusi. Ini bukan jadwal hukum untuk setiap produk yang digambarkan. Cakupan yang mengikat, jalur identitas, format bukti, persyaratan data, dan tanggal penerapan ditetapkan oleh peraturan produk UE yang relevan, delegated acts khusus produk, dan desain sistem final.

Lima pertanyaan perencanaan untuk setiap lini produk

1. Apakah produk termasuk dalam cakupan?

Bangun register produk-ke-aturan yang mengidentifikasi peraturan UE yang relevan, status saat ini, delegated act yang diharapkan, dan badan hukum yang bertanggung jawab. Jangan berasumsi bahwa program DPP tingkat perusahaan berarti setiap produk mengikuti jadwal yang sama.

2. Siapa yang memiliki setiap elemen data yang diwajibkan?

Tetapkan sistem sumber dan pemilik bisnis untuk setiap atribut wajib. Jika suatu nilai berasal dari pemasok, tetapkan aturan validasi, eskalasi, dan kontrol perubahan alih-alih menerima file yang tidak diverifikasi melalui email.

3. Bagaimana produk diidentifikasi secara unik?

Putuskan apakah aturan berlaku pada tingkat model, batch, atau item. Konfirmasi bagaimana pengidentifikasi dibuat, bagaimana duplikasi dicegah, dan bagaimana pembawa data fisik tetap terhubung ke catatan digital yang benar.

4. Siapa yang dapat menyetujui dan mengajukan?

Dokumentasikan badan hukum, peran yang bertanggung jawab, model delegasi, dan kredensial mesin yang terlibat. Pisahkan persetujuan internal dari pengajuan eksternal dan dari layanan kepercayaan qualified apa pun yang diwajibkan oleh hukum.

5. Bukti apa yang harus tetap bertahan saat terjadi perubahan sistem?

Tentukan paket bukti sebelum implementasi. Jawabannya menentukan arsitektur penyimpanan, format ekspor, dependensi validasi, dan kontrol migrasi.

Blueprint integrasi untuk implementasi praktis

Arsitektur praktis biasanya dimulai dari sistem sumber, bukan database mandiri yang baru. Layanan data mengambil atribut produk yang telah disetujui, layanan alur kerja memvalidasi kelengkapan dan mengarahkan pengecualian, lapisan identitas dan otorisasi memverifikasi aktor, dan lapisan API mengajukan payload yang benar ke registri atau layanan paspor yang relevan.

Lapisan bukti harus menangkap setiap peristiwa material tanpa menyimpan data pribadi yang tidak diperlukan. Lapisan ini juga harus mendukung pengambilan berdasarkan produk, transaksi, badan hukum, dan periode waktu agar tim kepatuhan dapat merespons audit atau sengketa secara efisien.

Implementasi biasanya lebih aman dilakukan bertahap. Pilih satu keluarga produk, petakan data dan persyaratan hukumnya, uji alur kerja lengkap dengan pengguna representatif, lalu perluas. Ini menciptakan kontrol yang dapat digunakan kembali sambil menjaga perbedaan khusus produk tetap terlihat.

Dua jalur penandatanganan dalam solusi DPP eSign.AI

Jalur pertama adalah verifikasi operator ekonomi. eSign.AI mendukung pengajuan QSeal, koordinasi verifikasi identitas, dan pencocokan data organisasi melalui kapabilitas Registration Authority dan integrasi ANF AC. Ini sangat relevan bagi produsen non-UE yang membutuhkan qualified electronic seal dari daftar tepercaya UE untuk proses identitas yang berhadapan dengan registri.

Jalur kedua adalah alur kerja data produk berulang. eSign.AI mendukung PAdES untuk dokumen PDF dan profil tanda tangan jangka panjang XAdES atau JAdES untuk catatan XML dan JSON, termasuk qualified timestamps dan penyimpanan bukti. Format dan tingkat jaminan yang tepat harus mengikuti aturan khusus produk, antarmuka registri, dan penilaian hukum pelanggan; tidak setiap peristiwa DPP menggunakan tanda tangan yang sama.

Untuk volume yang lebih tinggi, pelanggan dapat terhubung melalui SDK atau API alih-alih menandatangani setiap catatan secara manual. Ketika proses penerima mendukung pengajuan batch, satu operasi dapat mengemas beberapa catatan DPP sambil tetap mempertahankan pengidentifikasi dan bukti pada tingkat catatan. eSign.AI juga mendukung alur kerja SaaS bagi tim yang membutuhkan antarmuka operasional sebelum integrasi sistem selesai.

Di mana eSign.AI berperan

eSign.AI mendukung alur kerja tanda tangan elektronik dan tanda tangan digital, orkestrasi persetujuan, integrasi API, dan retensi bukti. Untuk program DPP, kemampuan ini dapat membantu menghubungkan sistem bisnis ke langkah penandatanganan atau penyegelan, menangkap peristiwa operator, dan menyimpan catatan alur kerja yang dapat ditelusuri.

Cakupan implementasi eSign.AI dapat mencakup dukungan pengajuan dan penerbitan QSeal, panduan onboarding registri, penandatanganan PAdES/XAdES/JAdES, qualified timestamps, integrasi SaaS dan API, serta bukti jangka panjang. Tata kelola data produk tetap menjadi tanggung jawab pelanggan, sementara eSign.AI menyediakan lapisan kepercayaan dan eksekusi yang diperlukan untuk menggerakkan data yang tepat melalui jalur penandatanganan yang tepat dan menyimpan bukti untuk verifikasi di kemudian hari.

Lanjutkan seri DPP

Baca Part 1: Mengapa Eksportir Tiongkok Perlu Mempersiapkan Diri untuk Digital Product Passport UE untuk konteks regulasi dan sektor.

Part 2: Pendalaman DPP: Bagaimana Perusahaan Menggunakannya, Merencanakan Penggunaan, dan Mengintegrasikannya (artikel ini)

Lanjutkan ke Part 3: Dari eCoC ke QSeal: Bagaimana eSign.AI Mendukung Kesiapan DPP untuk melihat lebih dekat alur kerja tepercaya, integrasi QSeal, dan peran eSign.AI.