ISO/IEC JTC 5: pregătirea arhitecturii pentru interoperabilitate DPP

De ce ajunge acum arhitectura pe ordinea de zi

Pașaportul digital al produsului este introdus treptat în Europa prin acte legislative sectoriale. Pentru companii apare ușor impresia că fiecare grupă de produse are nevoie de propriul model de date, de propriul suport de date și de propria logică de integrare. Tocmai la această interfață începe activitatea ISO/IEC JTC 5: comitetul tehnic comun a fost înființat în 2026 și urmează să elaboreze bazele unei interoperabilități DPP între sectoare și sisteme. Prima sa reuniune anunțată va avea loc între 7 și 9 septembrie 2026, la Berlin. ISO/IEC JTC 5 își descrie explicit mandatul ca pe un cadru pentru sistemul DPP și ecosistemul DPP; standardele specifice sectoarelor rămân în responsabilitatea comitetelor de specialitate competente.

Aceasta nu este o nouă obligație legală și nici un standard ISO publicat. Este însă un motiv solid pentru a separa arhitectura proprie de câmpurile de date pe termen scurt. Primul punct de lucru, ISO/AWI 25534-1, se află încă în etapa de proiect 10.99; proiectul a fost aprobat la 12 februarie 2026. Potrivit ISO, este vorba despre termeni, principii de bază, categorii de date, precum și mecanisme de guvernanță și de încredere. Înregistrarea publică a proiectului menționează explicit „under development”. Cine deduce de aici astăzi o obligație de certificare sau un format de schimb finalizat se grăbește.

Ce separă cadrul internațional de cerințele UE

UE stabilește deja repere concrete. Comisia explică faptul că DPP face accesibile informațiile despre produse într-un model descentralizat: datele complete rămân la operatorul economic sau la furnizorul de servicii DPP; registrul gestionează identificatori unici și datele de înregistrare obligatorii. Un suport de date, precum un cod QR, conectează produsul fizic la pașaportul său. Pagina DPP a Comisiei menționează, de asemenea, niveluri diferite de acces pentru roluri și calendare sectoriale.

În plus, există standardele europene armonizate. Decizia de punere în aplicare (UE) 2026/1736 din 14 iulie 2026 face trimitere la șase standarde DPP, printre altele privind identificatorii, interoperabilitatea, suporturile de date, API-urile, schimbul de date și stocarea datelor. Rolul lor este concret: pentru cerințele acoperite de acestea, respectarea lor poate susține prezumția de conformitate în temeiul articolelor 10 și 11 din ESPR.

JTC 5 nu înlocuiește aceste niveluri. El lucrează deasupra lor: un cadru neutru din punct de vedere sectorial ar trebui să ajute la explicarea modului în care se raportează între sisteme termenii, categoriile de date, încrederea și guvernanța. Consecința practică este importantă. Un producător nu ar trebui să aștepte o viitoare ediție ISO pentru a-și pune la dispoziție informațiile despre baterii, textile sau oțel. Ar trebui însă să evite să fixeze câmpurile actuale ale industriei ca nucleu imuabil al unui model DPP la nivelul întregii companii.

Trei decizii de arhitectură utile astăzi

1. Separarea identității stabile de profilurile de specialitate

Un pașaport are nevoie de o identitate tehnică durabilă: produs, variantă, lot sau piesă individuală; operatorul economic responsabil; rezoluția prin intermediul suportului de date. Temeiul juridic stabilește apoi ce informații de specialitate sunt necesare pentru aceasta. Aceste informații trebuie organizate în profiluri versionate. Prin urmare, un modul de baterie pentru date privind CO₂ sau starea de sănătate nu este o schemă de bază generală. La fel, datele despre materiale, reparații sau reciclare nu trebuie să ajungă într-un pașaport general doar sub forma unui text liber nestructurat.

Practic, acestea trebuie să includă împreună un identificator central stabil, un identificator de profil documentat și o versiune a profilului. Fiecare vizualizare furnizată a pașaportului ar trebui să indice ce profil și ce versiune au determinat conținutul. Astfel, echipele pot integra ulterior un act legislativ, o regulă de sector sau, mai târziu, un standard, fără a rescrie datele istorice sau URL-urile.

2. Modelarea separată a provenienței datelor și a accesului

Interoperabilitatea nu înseamnă doar un format JSON. Ea depinde de posibilitatea ca un destinatar să evalueze originea, valabilitatea și rolul unei informații. De aceea, pentru fiecare element de date sau pachet de date, stocați cel puțin sursa, domeniul de aplicare, momentul colectării, partea responsabilă și versiunea de specialitate. O valoare internă de calitate este altceva decât o declarație de conformitate cu caracter juridic obligatoriu; o informație furnizată de un furnizor este altceva decât o valoare măsurată.

A doua componentă este accesul. Comisia descrie niveluri diferite de acces la informații pentru consumatori, ateliere de reparații, reciclatori și autorități. Acest lucru impune separarea conștientă a vizualizării publice a pașaportului, a accesului de specialitate autorizat și a spațiului intern de lucru. Un URL nu trebuie să devină un drept de acces. Rolurile, mandatele, categoriile de date și deciziile care pot fi înregistrate trebuie verificate pe server.

3. Testarea limitelor de schimb ca acorduri

Un sistem DPP are mai multe puncte de tranziție: ERP sau PLM furnizează datele de bază, furnizorii transmit dovezi, un furnizor de servicii găzduiește datele, un registru primește metadate, iar utilizatorii externi citesc o vizualizare publică sau protejată. Pentru fiecare tranziție este necesar un acord care poate fi citit automat: câmpuri permise, identificatori, semantică, cazuri de eroare, versionare și compatibilitate retroactivă.

Acest lucru poate fi testat chiar de acum. Cazurile de test utile includ versiuni de profil necunoscute, dovezi expirate, proveniență lipsă a datelor, roluri nepermise, înregistrări duplicate și un suport de date care indică spre un pașaport care nu mai este disponibil. Testul nu dovedește încă respectarea unui viitor standard ISO. El creează însă trasabilitatea care lipsește la schimbarea ulterioară, atunci când modelul de date și drepturile au fost deja amestecate inseparabil.

Un plan de lucru pe 90 de zile, fără speculații

În următoarele 30 de zile merită realizată o imagine de ansamblu: ce identificatori de produs există, ce profiluri de date sunt folosite efectiv și ce date se află doar în documente? Urmează o decizie de arhitectură: modelul de bază, registrul de profiluri, modelul de proveniență și matricea de acces. Într-o a treia etapă, un produs real ar trebui să parcurgă toate tranzițiile — de la sistemul-sursă, prin pașaport, până la rolul atelierului de reparații sau al autorității.

Limitele rămân clare. ISO/AWI 25534-1 nu este un standard finalizat; nu există clauze publicate pe care echipele să le poată implementa. Nici calendarul Comisiei nu este definitiv și nu înlocuiește verificarea actului legislativ aplicabil grupei de produse respective. Prin urmare, beneficiul monitorizării nu constă într-o bifă anticipată pe o listă de conformitate, ci într-o arhitectură care poate integra ordonat noi profiluri, roluri și reguli de schimb.