DPP Series | Part 2: Đi sâu vào DPP: Cách doanh nghiệp sử dụng, lập kế hoạch sử dụng và tích hợp

Hộ chiếu Sản phẩm Kỹ thuật số (DPP) thường được giới thiệu như một yêu cầu về thông tin sản phẩm. Đối với các công ty chuẩn bị bán các sản phẩm chịu quản lý tại Liên minh châu Âu, mô tả đó là chưa đầy đủ. Một chương trình DPP khả thi phải kết nối dữ liệu sản phẩm được quản trị với mã định danh sản phẩm, các tổ chức chịu trách nhiệm, kiểm soát truy cập, các bản gửi có thể xác minh và những hệ thống duy trì hồ sơ theo thời gian.

Bài viết thứ hai này trong loạt bài DPP của eSign.AI chuyển từ nhận thức quy định sang thiết kế vận hành. Bài viết giải thích nơi các công ty có thể sử dụng DPP, cách quyết định đội ngũ và hệ thống nào nên sở hữu từng nghĩa vụ, và nơi chữ ký điện tử, con dấu điện tử và lưu giữ bằng chứng có thể hỗ trợ một quy trình đáng tin cậy.

Bắt đầu với sự kiện kinh doanh, không phải mã QR

Mã QR hoặc một vật mang dữ liệu khác là điểm vào nhìn thấy được của hộ chiếu, nhưng đó không phải là mô hình vận hành của hộ chiếu. Câu hỏi thiết kế đầu tiên là sự kiện kinh doanh nào tạo ra hoặc thay đổi hồ sơ sản phẩm. Tùy vào sản phẩm và pháp luật áp dụng, sự kiện đó có thể là đưa một sản phẩm ra thị trường EU, đăng ký một nhà khai thác kinh tế, phát hành tài liệu về sự phù hợp, cập nhật thông tin sửa chữa hoặc ghi nhận một sự kiện vòng đời.

Mỗi sự kiện cần có một chủ sở hữu chịu trách nhiệm. Đội ngũ sản phẩm có thể sở hữu các thuộc tính kỹ thuật, đội ngũ tuân thủ có thể phê duyệt các tuyên bố chịu quản lý, đội ngũ vận hành có thể quản lý mã định danh, và đội ngũ IT có thể kết nối các hệ thống nguồn. Khi không ai sở hữu sự kiện, hộ chiếu có thể trở thành một bài tập xuất bản tĩnh thay vì một hồ sơ tuân thủ được duy trì.

Kế hoạch làm việc ESPR của Ủy ban châu Âu giúp các công ty xác định các nhóm sản phẩm ưu tiên, nhưng các đạo luật được ủy quyền theo từng sản phẩm sẽ quyết định dữ liệu, thời điểm và nghĩa vụ vận hành chi tiết.

Lập bản đồ bốn lớp sẵn sàng cho DPP

Các công ty có thể cấu trúc việc chuẩn bị quanh bốn lớp được kết nối:

1. Dữ liệu sản phẩm: xác định các thuộc tính bắt buộc, nguồn dữ liệu, chủ sở hữu dữ liệu, quy tắc cập nhật và kiểm soát chất lượng.
2. Định danh sản phẩm: xác định mã định danh duy nhất ở cấp sản phẩm, lô hoặc mặt hàng và kết nối mã định danh đó với vật mang dữ liệu vật lý phù hợp.
3. Tổ chức và thẩm quyền: thiết lập pháp nhân nào gửi thông tin, người hoặc hệ thống nào có thể hành động thay mặt pháp nhân đó, và cách các quyền đó được xác minh.
4. Tin cậy và tính liên tục: lưu giữ bằng chứng về người đã phê duyệt hoặc gửi thông tin, bảo vệ tính toàn vẹn, kiểm soát truy cập và giữ hồ sơ sẵn có trong khoảng thời gian bắt buộc.

Mô hình này ngăn một sai lầm lập kế hoạch phổ biến: mua một công cụ hộ chiếu giao diện trước khi xác nhận liệu công ty có thể tạo, phê duyệt và duy trì thông tin nền tảng một cách đáng tin cậy hay không.

Kịch bản 1: onboarding một nhà khai thác kinh tế

Trước khi một tổ chức có thể gửi dữ liệu chịu quản lý, hệ thống liên quan có thể cần thiết lập danh tính pháp lý của tổ chức đó và thẩm quyền của người hoặc hệ thống hành động thay mặt tổ chức. Lộ trình chính xác phụ thuộc vào pháp luật điều chỉnh và thiết kế nền tảng. Nó có thể liên quan đến một phương thức định danh điện tử, một chứng thực điện tử, bằng chứng tài liệu hoặc một con dấu điện tử đủ điều kiện được hỗ trợ bởi chứng thư đủ điều kiện.

Điểm phân biệt quan trọng là giữa danh tính và quyền. Việc chứng minh rằng một công ty tồn tại không tự động chứng minh rằng một nhân viên, tài khoản dịch vụ hoặc đại diện bên ngoài cụ thể có thể gửi dữ liệu cho công ty đó. Một quy trình onboarding vững chắc ghi nhận cả danh tính tổ chức và việc ủy quyền hoặc vai trò cho phép một hành động.

Commission Implementing Regulation (EU) 2026/1778 cung cấp một ví dụ cụ thể cho EU DPP registry. Quy định này đặt ra các sắp xếp về danh tính và truy cập cho nhà khai thác kinh tế và các chủ thể khác, bao gồm các lộ trình bảo đảm cao cho thể nhân và con dấu điện tử đủ điều kiện hoặc chứng thực điện tử cho pháp nhân. Nhà khai thác kinh tế đã được xác minh vẫn chịu trách nhiệm đối với dữ liệu mà họ gửi.

Kịch bản 2: phê duyệt và gửi thông tin DPP

Thông tin sản phẩm thường bắt nguồn từ nhiều hệ thống: quản lý vòng đời sản phẩm, hoạch định nguồn lực doanh nghiệp, thực thi sản xuất, quản lý chất lượng, cổng thông tin nhà cung cấp và kho tài liệu. Một quy trình DPP không nên yêu cầu người dùng tạo lại thủ công thông tin đó trong một giao diện khác nếu đã có một nguồn có thẩm quyền.

Thay vào đó, thiết kế vận hành có thể tập hợp bộ dữ liệu bắt buộc, xác thực các trường bắt buộc, định tuyến ngoại lệ đến đúng chủ sở hữu và ghi nhận phê duyệt trước khi gửi. Khi bắt buộc có chữ ký hoặc con dấu, quy trình nên gọi dịch vụ tin cậy phù hợp mà không nhầm lẫn phê duyệt kinh doanh với chữ ký hoặc con dấu đủ điều kiện về mặt pháp lý.

eSign.AI có thể hỗ trợ lớp quy trình bằng cách kết nối các hệ thống nguồn, định tuyến tác vụ phê duyệt, áp dụng lộ trình ký hoặc đóng dấu bắt buộc và ghi nhận bằng chứng giao dịch phát sinh. Thông qua dịch vụ Registration Authority và tích hợp với ANF AC, eSign.AI có thể cung cấp lộ trình đăng ký và phát hành QSeal như một phần của giải pháp khách hàng, thay vì để khách hàng phải tự điều phối một nhà cung cấp ở nước ngoài riêng biệt.

Kịch bản 3: duy trì khả năng xác minh theo thời gian

Nghĩa vụ DPP không chỉ giới hạn tại thời điểm công bố. Thông tin sản phẩm có thể cần duy trì sẵn có, dễ hiểu và đáng tin cậy qua các vòng đời sản phẩm dài, thay đổi quyền sở hữu và di trú hệ thống. Do đó, các công ty nên lập kế hoạch cho bằng chứng bền vững thay vì xem một phản hồi API thành công là điểm kết thúc của quy trình.

Thiết kế bằng chứng có thể bao gồm bộ dữ liệu đã gửi hoặc biểu diễn chuẩn của bộ dữ liệu đó, dấu thời gian, tài liệu xác thực chữ ký hoặc con dấu, bối cảnh của người ký hoặc nhà khai thác, hồ sơ ủy quyền, biên nhận giao hàng, lịch sử phiên bản và nhật ký hệ thống. Thời hạn lưu giữ và phương thức xác thực phải được khớp với các quy tắc sản phẩm áp dụng và chính sách hồ sơ.

Khung EU trao cho con dấu điện tử đủ điều kiện sự suy đoán pháp lý về tính toàn vẹn dữ liệu và tính chính xác của nguồn gốc, trong khi dấu thời gian đủ điều kiện có thể hỗ trợ bằng chứng rằng dữ liệu đã tồn tại tại một thời điểm cụ thể. Chỉ các dịch vụ được liệt kê là đủ điều kiện trong một danh sách tin cậy quốc gia của EU mới có trạng thái đủ điều kiện.

Ghi chú lập kế hoạch: minh họa nguồn Word này trình bày lộ trình theo lĩnh vực và thời điểm để thảo luận. Đây không phải là lịch trình pháp lý cho mọi sản phẩm được mô tả. Phạm vi ràng buộc, lộ trình danh tính, định dạng bằng chứng, yêu cầu dữ liệu và ngày áp dụng được thiết lập bởi pháp luật sản phẩm EU liên quan, các đạo luật được ủy quyền theo từng sản phẩm và thiết kế hệ thống cuối cùng.

Năm câu hỏi lập kế hoạch cho từng dòng sản phẩm

1. Sản phẩm có thuộc phạm vi áp dụng không?

Xây dựng một sổ đăng ký sản phẩm-theo-quy tắc xác định pháp luật EU liên quan, trạng thái hiện tại, đạo luật được ủy quyền dự kiến và pháp nhân chịu trách nhiệm. Không giả định rằng một chương trình DPP cấp công ty có nghĩa là mọi sản phẩm đều theo cùng một lịch trình.

2. Ai sở hữu từng yếu tố dữ liệu bắt buộc?

Gán một hệ thống nguồn và chủ sở hữu kinh doanh cho mọi thuộc tính bắt buộc. Nếu một giá trị đến từ nhà cung cấp, hãy xác định các quy tắc xác thực, leo thang và kiểm soát thay đổi thay vì chấp nhận các tệp chưa được xác minh qua email.

3. Sản phẩm được định danh duy nhất như thế nào?

Quyết định liệu quy tắc vận hành ở cấp mẫu, lô hay mặt hàng. Xác nhận cách mã định danh được tạo, cách ngăn chặn trùng lặp, và cách vật mang dữ liệu vật lý vẫn được kết nối với hồ sơ số phù hợp.

4. Ai có thể phê duyệt và gửi?

Ghi lại pháp nhân, vai trò chịu trách nhiệm, mô hình ủy quyền và thông tin xác thực máy liên quan. Tách biệt phê duyệt nội bộ với việc gửi ra bên ngoài và với bất kỳ dịch vụ tin cậy đủ điều kiện nào được pháp luật yêu cầu.

5. Bằng chứng nào phải tồn tại sau một thay đổi hệ thống?

Xác định gói bằng chứng trước khi triển khai. Câu trả lời quyết định kiến trúc lưu trữ, định dạng xuất, phụ thuộc xác thực và kiểm soát di trú.

Một blueprint tích hợp cho triển khai thực tiễn

Một kiến trúc thực tiễn thường bắt đầu từ các hệ thống nguồn thay vì một cơ sở dữ liệu độc lập mới. Một dịch vụ dữ liệu truy xuất các thuộc tính sản phẩm đã được phê duyệt, một dịch vụ quy trình xác thực tính đầy đủ và định tuyến ngoại lệ, một lớp danh tính và ủy quyền xác minh tác nhân, và một lớp API gửi payload chính xác đến registry hoặc dịch vụ hộ chiếu liên quan.

Lớp bằng chứng nên ghi nhận từng sự kiện trọng yếu mà không lưu trữ dữ liệu cá nhân không cần thiết. Lớp này cũng nên hỗ trợ truy xuất theo sản phẩm, giao dịch, pháp nhân và khoảng thời gian để đội ngũ tuân thủ có thể phản hồi kiểm toán hoặc tranh chấp một cách hiệu quả.

Triển khai thường an toàn hơn theo từng giai đoạn. Chọn một họ sản phẩm, lập bản đồ dữ liệu và yêu cầu pháp lý của họ sản phẩm đó, kiểm thử toàn bộ quy trình với người dùng đại diện, rồi mở rộng. Cách này tạo ra các kiểm soát có thể tái sử dụng trong khi vẫn cho phép các khác biệt theo từng sản phẩm được nhìn thấy rõ.

Hai tuyến ký trong giải pháp DPP của eSign.AI

Tuyến thứ nhất là xác minh nhà khai thác kinh tế. eSign.AI hỗ trợ đăng ký QSeal, điều phối xác minh danh tính và đối chiếu dữ liệu tổ chức thông qua năng lực Registration Authority và tích hợp ANF AC. Điều này đặc biệt phù hợp với các nhà sản xuất ngoài EU cần một con dấu điện tử đủ điều kiện thuộc danh sách tin cậy của EU cho quy trình danh tính hướng tới registry.

Tuyến thứ hai là quy trình dữ liệu sản phẩm lặp lại. eSign.AI hỗ trợ PAdES cho tài liệu PDF và hồ sơ chữ ký dài hạn XAdES hoặc JAdES cho hồ sơ XML và JSON, bao gồm dấu thời gian đủ điều kiện và lưu giữ bằng chứng. Định dạng và mức bảo đảm chính xác nên tuân theo quy tắc theo từng sản phẩm, giao diện registry và đánh giá pháp lý của khách hàng; không phải mọi sự kiện DPP đều sử dụng cùng một chữ ký.

Đối với khối lượng cao hơn, khách hàng có thể kết nối qua SDK hoặc API thay vì ký từng hồ sơ theo cách thủ công. Khi quy trình tiếp nhận hỗ trợ gửi theo lô, một thao tác có thể đóng gói nhiều hồ sơ DPP trong khi vẫn bảo toàn mã định danh và bằng chứng ở cấp từng hồ sơ. eSign.AI cũng hỗ trợ quy trình SaaS cho các đội ngũ cần một giao diện vận hành trước khi hoàn tất tích hợp hệ thống.

eSign.AI phù hợp ở đâu

eSign.AI hỗ trợ quy trình chữ ký điện tử và chữ ký số, điều phối phê duyệt, tích hợp API và lưu giữ bằng chứng. Đối với một chương trình DPP, các năng lực này có thể giúp kết nối hệ thống kinh doanh với các bước ký hoặc đóng dấu, ghi nhận các sự kiện của nhà khai thác và lưu giữ một hồ sơ quy trình có thể truy vết.

Phạm vi triển khai của eSign.AI có thể bao gồm hỗ trợ đăng ký và phát hành QSeal, hướng dẫn onboarding registry, ký PAdES/XAdES/JAdES, dấu thời gian đủ điều kiện, tích hợp SaaS và API, cùng bằng chứng dài hạn. Quản trị dữ liệu sản phẩm vẫn là trách nhiệm của khách hàng, trong khi eSign.AI cung cấp lớp niềm tin và thực thi cần thiết để chuyển đúng dữ liệu qua đúng lộ trình ký và lưu giữ bằng chứng cho việc xác minh sau này.

Tiếp tục loạt bài DPP

Đọc Phần 1: Vì sao các nhà xuất khẩu Trung Quốc cần chuẩn bị cho Hộ chiếu Sản phẩm Kỹ thuật số của EU để biết bối cảnh quy định và lĩnh vực.

Phần 2: Đi sâu vào DPP: Cách doanh nghiệp sử dụng, lập kế hoạch sử dụng và tích hợp (bài viết này)

Tiếp tục đến Phần 3: Từ eCoC đến QSeal: Cách eSign.AI hỗ trợ sự sẵn sàng cho DPP để xem xét kỹ hơn các quy trình đáng tin cậy, tích hợp QSeal và vai trò của eSign.AI.