Digital product passport: collecting supplier data with AI for ESPR and battery passports

What the digital product passport is and who must build it

The digital product passport (DPP) is a digital record for a product, component or material with information on sustainability, circularity and legal compliance, reached through a data carrier such as a QR code; the economic operator that places the product on the EU market has the primary responsibility for creating it and for its accuracy, as the Commission's DPP FAQ puts it. Much of that information comes from suppliers, and an AI system on your own server can read their documents in many formats and languages into fixed fields that your team checks and confirms.

The European Commission's DPP page lists safety, origin, materials, repairability, environmental performance and reuse and recycling as the kinds of information a passport may hold, depending on the product category. This page is for managing directors and the heads of product management, sustainability, quality or purchasing at manufacturers of textiles, steel and aluminium products, tyres, furniture, batteries and, later, other product categories. The second half has notes for the IT team. Everything about the law is general information, read on Commission and EUR-Lex pages on 25 October 2026; your legal counsel confirms what applies to your products.

Which products need a passport, and when

The Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781, entered into force on 18 July 2024. It is a framework: the passport becomes mandatory for a product category only through a delegated act for that category, and the FAQ notes that being on the Commission's working plan "does not automatically mean" a passport is required. The Commission adopted its first ESPR working plan on 16 April 2025. Other EU laws bring their own passports.

European Commission, Digital Product Passport page (indicative timeline) and Digital Product Passport FAQ (manuscript completed February 2026), read 25 October 2026. ESPR years are those of the working plan for the delegated acts; the obligation applies after the transition each act sets.

The Commission's page gives economic operators a transition of at least 18 months after a delegated act is adopted, and calls the whole timeline indicative. For a textile or tyre maker that means the fields are not yet fixed, while the date is close enough to start preparing the supplier data. For iron and steel, a delegated act is on the timeline for the fourth quarter of 2026; we found no adopted text on 25 October 2026.

Our guide to ecodesign rules for servers and GPU servers covers the ecodesign rules that apply to the servers themselves.

What the passport will ask for

The data per product category comes from its delegated act. The general picture from the Commission's pages is this. The ESPR page gives as examples the product's technical performance, materials and their origins, repair activities, recycling capabilities and lifecycle environmental impacts. The FAQ adds that information on substances of concern present in a product "will be included in the DPP if a DPP is required for the product", with thresholds and exemptions set per delegated act. A unique product identifier ties the passport to the product, set at model, batch or item level as the act requires.

Access is split by role. Consumers see key product information free of charge, repairers and recyclers get the information they need for their work, and market surveillance authorities can check compliance. Some data is public and some restricted to entitled parties, per the FAQ.

Most of these fields start with a supplier. The composition of a fabric comes from the spinner and the weaver, the recycled content of an aluminium profile from the extruder's certificate, the steel grade and heat from a 3.1 certificate, the substances of concern from a supplier declaration. A manufacturer with a few hundred products and a few dozen suppliers per product holds thousands of such documents, in different layouts and languages, and few of them were written with a passport in mind.

How AI collects supplier data for the passport

An AI system turns those documents into structured, checked data. It does not create the passport and it does not decide whether a value is right.

1. Collect. Specification sheets, certificates, test reports, declarations and emails from suppliers land in one queue, each filed with supplier, date and the parts it covers.
2. Read. An OCR model turns scans into text and tables, and a language model fills a fixed form for each document: material, composition by percentage, origin, recycled content and its basis, substances named with their CAS or EC numbers, test standard and result. Each value keeps the page and position it came from. The form is a JSON schema that the inference software enforces.
3. Normalise. The model maps what suppliers write onto your own vocabulary: "PES", "polyester" and "Polyester" become one fibre code, a percentage range becomes a minimum and a maximum, units are converted. This is where a language model helps most, because suppliers describe the same thing in many ways and in many languages.
4. Check. Rules written by your team flag gaps and conflicts: compositions that do not add up to 100 per cent, a recycled-content claim without a certificate, a declaration older than the current Candidate List, a supplier value that differs from last year's.
5. Ask. For each gap, the system drafts a request to the supplier in the supplier's language; a person sends it.
6. Confirm. A person in product management or compliance confirms each record before it goes into the product database that feeds the passport.

The passport data itself belongs in a database, a product information management (PIM) or PLM system, run by you or a DPP service provider; the FAQ notes that the economic operator must also provide a backup copy through a third-party service provider. The model only prepares and checks what goes in. Our guides to supplier declarations for RoHS, REACH and SCIP and to EN 10204 certificates read by AI describe two of these document types in detail. The Commission's own proposal to end new SCIP submissions argues that passports will further limit the added value of the SCIP database, so the two strands of work meet.

We build AI servers that run this pipeline beside your other AI tasks; send us a few typical supplier documents and the product categories you sell in the EU, and our team replies with a configuration.

Why the supplier data should stay in-house

Supplier documents for a passport carry more than compliance facts. Specification sheets name the supplier, the exact recipe of a blend, and the same email threads may carry prices and order quantities; together they describe your supply chain. Many purchasing contracts and NDAs restrict who may see that information, as our guide on trade secrets, NDAs and AI tools explains. Running the models on a server you control keeps the documents and the extracted data inside the company until a person decides what goes into the passport and to whom it is shown.

Which models and how much computing

The reading step needs a model that handles many languages and long tables; the normalisation step benefits from a larger model.

Hugging Face model cards and "Files" pages of zai-org/GLM-OCR, Qwen/Qwen3-14B-FP8 and openai/gpt-oss-120b, read 25 October 2026.

gpt-oss-120b has 117B parameters with 5.1B active, and its card states that it fits "into a single 80GB GPU". Its card gives no language list, so test it on documents from your suppliers' countries before you rely on it; Qwen3-14B's card claims more than 100 languages and dialects, and our comparison of open LLMs for European languages covers others.

By our users-per-card rule, which takes 90 per cent of the 95.6 GiB the driver reports on an RTX PRO 6000 Blackwell Server Edition, less 3 GiB and less the weights, gpt-oss-120b at 60.8 GiB leaves 22.2 GiB of cache: with a 16-bit cache, 39 documents of 16,384 tokens in flight on one card. For speed, MLPerf® Inference v6.1 entry 6.1-0050 lists 15,256 tokens per second for gpt-oss-120b offline on eight RTX PRO 6000 Server Edition, 1,907 per card by our division, and we plan with half.

Our estimates. MLPerf® Inference: Datacenter v6.1, closed division, available category, gpt-oss-120b, offline scenario, entry 6.1-0050 (HPE ProLiant Compute DL380a Gen12, eight RTX PRO 6000 Blackwell Server Edition), 15,256 tokens per second, retrieved from mlcommons.org on 24 October 2026, result verified by MLCommons Association; 1,907 per card is our division of the system result, not an MLPerf metric, and we plan with half of it; volumes and tokens per document are example values. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

The backlog is the only large job, and a night or two clears it. After that the load is small, so the same server carries the company's other AI work, from an internal assistant to order entry and datasheet search for distributors.

Server options

Reference configurations on our AI servers page; power by our estimate (cards at full power, processors, plus 15 per cent for the rest of the server), as in our guides to four RTX PRO 6000 Server Edition cards and four RTX PRO 4500 Server Edition cards in 2U.

Two RTX PRO 6000 Server Edition. The entry server on our AI servers page has two RTX PRO 6000 Server Edition, two AMD EPYC processors, 384 GB of DDR5 ECC and two NVMe drives. One card runs gpt-oss-120b; the other is split by MIG into isolated instances of 24 or 48 GB for the OCR model, the 14B model and a search index, as our page on RTX PRO 6000 MIG profiles explains. At about 1.8 kW by our estimate it fits one 230 V 16 A feed, which carries 2.94 kW at 80 per cent.

Four RTX PRO 6000 Server Edition. The inference node with 768 GB and four NVMe drives clears a large backlog faster and gives an internal assistant and other departments their own cards. It draws about 3.4 kW with the cards at 600 W and needs 32 A or three-phase, or about 2.7 kW with the cards capped at 450 W, as our guide to GPU server power on 16 A, 32 A and three-phase feeds works through.

RTX PRO 4500 Server Edition. Where documents are short and come in few languages, two or four of these 32 GB cards run OCR and the 14B model at about 0.84 or 1.4 kW by our estimate. For mixed languages and messy supplier data we would start with the RTX PRO 6000 Server Edition. A measurement on the delivered system confirms the power figures.

We set up the models, the rules and the connection to your PIM, PLM or ERP through our Private AI/ML service; tell us which product categories and systems are involved, and we propose a pilot on one product line.

Notes for the IT team

1. Data model first. Define the product data model with fields, units, allowed values and the evidence each field needs, before choosing models. When a delegated act is adopted, map its fields to yours. The Commission's timeline lists an implementing decision on six DPP standards for July 2026 and one on the remaining two for November 2026; align identifiers and formats with them.
2. Identifiers. Decide whether you identify products at model, batch or item level, per the delegated act; item level needs serial numbers in production data.
3. Serving. vLLM serves the three models with an OpenAI-compatible API and structured outputs for the fixed forms; --gpu-memory-utilization is a per-instance limit, so small engines can share a card or a MIG instance.
4. Evidence. Store every extracted value with the source file, page, model version, rule version and the person who confirmed it. A passport value you publish must be traceable to a supplier document.
5. Security. Supplier documents are untrusted input: text inside them must never act as an instruction to the model, as our guide to prompt injection and LLM security explains. Keep the engines on an internal network behind an LLM gateway with keys and a query log.
6. Software on delivery. The server arrives on request with the operating system, the NVIDIA driver, CUDA and a container runtime, as our AI servers page states.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build the servers to order with RTX PRO 6000 Server Edition or RTX PRO 4500 Server Edition cards, assembled and tested before delivery, delivered anywhere in the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Our Private AI/ML service, with our engineering partner Vixen.UNO, deploys the models, the rules and the connections to your product systems; the passport platform itself stays with you or your DPP service provider. Our guide to buying a GPU server for LLMs lists every configuration.

FAQ