AI Agents for the Digital Product Passport: How Manufacturers Compile ESPR Data Without a New Department

A German component manufacturer sells industrial gear units into machines that end up all over Europe. In 2026 a large OEM customer sends a new clause with its purchase order: from a fixed date, every part must arrive with a compliant Digital Product Passport - material composition, substances of concern, recycled content, end-of-life data - readable from a QR code on the part. The Geschäftsführer forwards it to the quality manager, who forwards it to whoever seems least busy, and everyone quietly assumes the answer is to hire a small team to chase this data across a few hundred products and a few dozen suppliers.

That instinct is expensive and wrong. The data the DPP demands already sits inside the company - in the ERP, the PLM, the quality system, the supplier declarations. It is just scattered, inconsistent, and never assembled into one machine-readable record per product. The real task is not collection from scratch. It is aggregation, validation and formatting to a standard, repeated across every product and kept current forever. That is a data-plumbing problem, and standing up a permanent department to solve a data-plumbing problem is how compliance costs quietly become a fixed line on the P&L.

This guide is for the Geschäftsführer, the head of product compliance, or the PLM lead at a manufacturer who has just realised the DPP is coming and is deciding how to meet it. Below is a concrete look at what the ESPR actually requires, why the data - not the QR code - is the hard part, and how a custom AI agent aggregates DPP data across your existing systems into a compliant passport per product, with the 90-day pilot, the compliance reality, and the build-vs-department maths.

The Department You Cannot Afford

When a regulation lands on a manufacturer, the reflex is organisational: name an owner, staff a team, buy a tool. For the Digital Product Passport, that reflex leads straight to a cost centre that never shrinks - because the DPP is not a one-off project, it is a permanent per-product data obligation. The cheaper answer is to treat it as a data problem, not an org-chart problem.

• The data is already inside the company - Material composition, part numbers, recycled content and supplier declarations live in your ERP, PLM and quality system; the DPP mostly re-uses existing data, it does not invent it⁵.
• The volume kills manual work - A passport per product, per variant, kept current across the lifecycle, is thousands of records that no reasonable headcount can hand-assemble and maintain¹⁷.
• The hard field is scattered - Material composition is held across multiple systems, collected inconsistently, and rarely verified, which is exactly why teams underestimate it¹⁶.
• Sub-tier data is missing - Full material disclosure needs data from sub-tier suppliers that most firms do not collect systematically today¹⁶.
• A department cannot keep pace - Every engineering change, new supplier or reformulation ripples into the passport; a manual team is always behind the change log.
• The liability sits with you - The economic operator placing the product on the market is responsible for the passport, so the answer has to be auditable, not just staffed⁵.

The pattern is the same one that shows up with every data-heavy regulation: the work is not the judgement, it is the plumbing. An agent does not decide your compliance strategy. It removes the thousands of hours of copying, chasing and reformatting that a new department would otherwise absorb.

What a DPP Must Actually Contain

Before you can automate the passport, you have to know what goes in it. The ESPR sets the frame in Articles 9 to 15 and Annex III; the detailed fields come per product group through delegated acts. Across groups, the same families of data recur - and they map cleanly onto systems you already run.

The core data families

• Product identity and identifier - A unique product identifier and a data carrier (QR code or NFC), registered so the EU Registry can resolve it to your data⁴
• Material composition - A detailed breakdown of materials, including recycled content and any critical raw materials¹⁶
• Substances of concern - Name, concentration and location in the product of substances above defined thresholds, tied to the ECHA SCIP database^{10, 11}
• Durability and reparability - Expected lifetime, reparability information, spare-parts availability and disassembly instructions¹²
• End-of-life handling - Disassembly maps, recyclability assessment and routing instructions for recyclers¹²
• Compliance and documentation - Links to conformity information and technical documentation to the extent the delegated act requires

Where each field already lives

The point of the table is not that the data is easy. It is that the data has a home. The DPP work is closing the gap between a field that exists somewhere and the same field, verified and structured, in a passport a machine can read.

The ESPR Timeline That Is Already Moving

The DPP does not arrive on one date. It arrives group by group through delegated acts, which is why some manufacturers think they have years and others are already contractually on the hook via their OEM customers. Here is the map that matters in 2026.

The fixed dates

• ESPR in force - Regulation (EU) 2024/1781 entered into force on 18 July 2024, establishing the DPP framework filled in per group by delegated acts¹
• Working plan adopted - The Commission adopted the 2025-2030 ESPR working plan on 16 April 2025, naming textiles as a first priority group^{3, 9}
• EU DPP Registry live - Under Article 13, the central Registry of product identifiers must be set up by 19 July 2026⁴
• Battery passport mandatory - From 18 February 2027, EV, light-means-of-transport and industrial batteries above 2 kWh need a battery passport under the Batteries Regulation - the first mandatory DPP^{6, 7}
• Textiles delegated act - Expected around 2027, with compliance roughly 18 months later, around mid-2028⁸
• Electronics, furniture and more - Prioritised in the working plan for the second half of the decade⁹

Why the OEM clause beats the delegated act

For most Mittelstand suppliers, the binding deadline is not the delegated act - it is the day a large customer makes a DPP a condition of the purchase order. OEMs preparing their own passports push the data requirement straight down the supply chain, often ahead of the legal date.

Why the Data, Not the QR Code, Is the Problem

Vendors love to demo the easy 10 percent: printing a QR code and hosting a web page. That part is solved. The hard 90 percent is getting correct, complete, structured data behind the code - and keeping it there. This is where DPP projects actually stall.

The five data problems

1. Scatter - The same product’s data lives in ERP, PLM, quality, supplier portals and lab certificates, in different formats and units¹⁶.
2. Sub-tier blindness - Full material and substance disclosure needs data from suppliers-of-suppliers that most firms never systematically collected¹⁶.
3. Inconsistency - Fabric or alloy content on one document does not match another; the same field has three values¹⁶.
4. Verification - Substances of concern need name, concentration and location, tied to SCIP - a step beyond a rough declaration^{10, 11}.
5. Drift - A passport is right on launch day and wrong three engineering changes later unless something keeps it current.

Why aggregation is an AI-shaped job

• Many sources, one record - The agent reads ERP, PLM, quality and supplier data and reconciles them into a single passport per product
• Messy inputs - Supplier declarations arrive as PDFs, emails and spreadsheets; extracting structured fields from unstructured documents is exactly what a language-model agent does well
• Matching and normalisation - Aligning material names, CAS numbers and units across sources is repetitive pattern work, not judgement
• Gap detection - The agent flags which DPP fields it cannot source, so humans chase only the true gaps, not everything
• Continuous re-assembly - When a source changes, the agent rebuilds the affected passports instead of waiting for a person to notice

What the AI Agent Actually Does

A DPP agent is not a chatbot bolted onto a product page. It owns a workflow: pull the required fields from your systems, reconcile and validate them, format to the data model, expose them through the identifier and data carrier, and keep them current - escalating the liability calls to a human.

The agent loop for a Digital Product Passport

1. Map - Reads the DPP field list for the product group and locates where each field lives across your ERP, PLM, quality and supplier systems.
2. Pull - Extracts material composition, part data, recycled content and technical documentation from those systems through approved integrations.
3. Ingest declarations - Reads supplier declarations and lab certificates - PDFs, emails, spreadsheets - and extracts the structured fields.
4. Reconcile - Normalises material names, CAS numbers and units, and resolves conflicts where a field has more than one value.
5. Match substances - Aligns substances of concern to your SCIP declarations and the regulatory thresholds, with name, concentration and location.
6. Detect gaps - Flags every DPP field it cannot yet source and routes it to the right owner or supplier to fill.
7. Assemble and format - Builds the passport to the DPP data model, attaches the identifier and data carrier, and registers it.
8. Validate and sign off - Presents the liability-bearing fields for human approval before the passport goes live.
9. Track change - Watches the source systems and rebuilds the affected passports when a part, supplier or formulation changes.

What it does versus what the alternatives do

The category matters. A QR tool shows a passport but does not build the data behind it. A generic chatbot has no live connection to your systems. A custom agent does the aggregation, keeps a trail, and never publishes a liability-bearing field without a human pressing approve.

The DPP-Agent Architecture

A DPP agent only works if it sits on top of where your product data already lives and never becomes a parallel system of record. The decentralised design of the ESPR is a gift here: you keep your data, and the agent exposes it.

The five layers

1. Source systems - ERP (material master, BOM), PLM, quality system, supplier portal and document store stay the source of truth for product facts.
2. Aggregation and extraction - The agent reads structured data through integrations and extracts structured fields from unstructured supplier documents.
3. Reconciliation and validation - Names, units and CAS numbers are normalised; conflicts are resolved; substances are matched to SCIP and thresholds.
4. Passport assembly - The DPP is built to the data model, given its identifier and data carrier, and registered so the EU Registry can resolve it.
5. Governance and change - Every field is linked to its source and approver; change-tracking rebuilds passports when the source data moves.

What sits where

The principle is simple: your systems stay the source of truth for product facts, and the agent is the operator that turns those facts into a compliant, current passport. Any architecture that copies your product master into a parallel store breaks both data governance and the audit trail.

Where the data lives

• Product and supplier data - In your systems, untouched; the agent works through approved integrations
• Agent state - In an EU-resident environment, operated under a DSGVO-compliant Auftragsverarbeitungsvertrag
• LLM inference - Via EU-resident endpoints (Azure OpenAI EU, AWS Bedrock EU, or Mistral) or a private deployment for the most sensitive product data
• Prompt and output retention - Logged for audit, not used for vendor model training - the AVV must say so explicitly
• Passport data - Hosted on your chosen DPP host, with the EU Registry holding only the identifier that resolves to it^{4, 19}

The 90-Day Pilot Playbook

The biggest mistake manufacturers make with the DPP is starting with a company-wide rollout deck. The right path is the opposite: start with one product group, one set of passports, and 90 days.

The phases

1. Days 1-15: Field mapping and gap report - Pick one product group, list the DPP fields it needs, and map each field to where it lives in your systems. The output is a gap report showing exactly which fields you cannot yet source.
2. Days 16-30: Connect the sources - Integrate the agent with your ERP, PLM, quality system and document store, read-only first. Confirm it can read the product master, BOM and technical documentation.
3. Days 31-45: Assemble first passports - The agent aggregates and reconciles the data into draft passports for a sample of products, formatted to the DPP data model.
4. Days 46-60: Substances and validation - Add substances-of-concern matching against your SCIP declarations and thresholds, and run the first human validation of the liability-bearing fields.
5. Days 61-75: Identifier and carrier - Assign identifiers and data carriers, register with the DPP Registry approach, and confirm a scan resolves to the correct passport.
6. Days 76-90: Change-tracking and go/no-go - Turn on change detection so passports stay current, agree the data-quality standard, and decide go or no-go for the next product group.

Checklist before you start

What to measure

• Field coverage - Share of required DPP fields the agent can source automatically - target 80 percent or better after the pilot
• Passports assembled - Number of complete, validated passports produced in the pilot group
• Gap-closure time - Time from a flagged missing field to a filled one, versus the manual baseline
• Supplier response - Share of sub-tier gaps closed through structured declaration requests
• Currency - Whether a change in a source system correctly triggers a passport rebuild

Compliance: ESPR, DSGVO and the EU AI Act

Compliance is the make-or-break of DPP work. The technology is the easy part; the responsibility frame is where careless firms get hurt. Three rule sets touch a DPP agent: the ESPR itself, the DSGVO, and the EU AI Act. Each has a concrete answer; none is a blocker.

ESPR - the responsibility rule

The spine of DPP compliance is that the economic operator placing the product on the EU market is legally responsible for the passport. The agent aggregates and formats; a human validates and signs the fields that carry liability. Getting a substances-of-concern declaration wrong is a market-surveillance and market-access risk, not a formatting quibble.

• The operator stays responsible - The agent drafts the passport; a human validates every liability-bearing field before it goes live⁵
• Substances need precision - Name, concentration and location above threshold, tied to SCIP - the agent structures it, a human confirms it^{10, 11}
• Traceability is the defence - Every field linked to its source document and approver, so a challenged figure is traced in minutes
• Access rights matter - Different roles see different fields; the passport must respect the ESPR access rules, not expose everything to everyone²
• Currency is an obligation - A passport that drifts out of date is non-compliant; change-tracking is not optional

DSGVO - the data side

Most DPP data is product data, not personal data - but supplier contacts, sign-offs and some technical documentation can contain personal data, and the agent processes commercially sensitive information regardless.

• EU-resident processing - Product and supplier data stays in EU data centres, with no transfer to non-EU models without a valid legal basis
• Auftragsverarbeitungsvertrag - An AVV governs the agent provider and the model endpoint, covering purpose limitation and deletion
• No training on your data - The vendor agreement includes an explicit no-training clause for prompts and outputs
• Data minimisation - The agent processes only the product data needed for the passport, not the whole company drive
• Access control and logging - Who read which product or supplier data, and when, is logged - useful for both DSGVO and market-surveillance audits

EU AI Act - the tool you use

Using an AI agent to aggregate and format product data is a low-risk, transparency-level use as long as a human stays responsible for the regulated declarations²².

• Low-risk use - The agent assembles data you already hold; it is not making high-risk decisions about people
• Human responsible - The economic operator signs the liability-bearing fields; the agent never publishes them unchecked
• Article 4 (AI literacy) - Staff who operate the agent receive basic, documented AI literacy²³
• Provider obligations - The LLM vendor carries the general-purpose model obligations; your firm is the deployer, not the provider
• Transparency - It is clear internally that the passport draft is machine-assembled and human-approved

Build vs Buy vs New Department

There are three ways to meet the DPP: stand up a compliance department, buy a generic DPP SaaS tool, or build a custom agent on top of your systems. Most manufacturers end up combining, and the right mix depends on how many products and how much data scatter you have.

The three options compared

The honest combination

• Agent for aggregation at scale - The agent does the pulling, reconciling and formatting across the whole portfolio, where a department would be permanent cost
• People for judgement and suppliers - A small compliance function validates thresholds, sets the data standard, and handles the suppliers who will not declare
• SaaS for hosting, agent for data - A DPP host can serve the passport; the agent is what fills it with correct, current data
• Never the generic tool alone - A QR tool with no live data connection just moves the manual work behind the code
• The maths flips with volume - A single niche product: a person can manage it. A portfolio of hundreds across variants: build the agent

How Superkind Fits

Superkind builds custom AI agents that sit on top of the systems a manufacturer already uses - ERP, PLM, quality system, supplier portal, document store - without forcing a switch. The deployment model is process-first: we map how your product data flows and where each DPP field lives before we touch a line of code. The agent is built around your product reality, not a generic passport template.

What sits in the Superkind DPP agent

What Superkind brings to DPP work

• Process-first deployment - We map how your product data flows and where each DPP field lives before we build, so the agent fits your reality
• Reads your systems - The agent aggregates from ERP, PLM, quality and supplier data through approved integrations, not a blank upload form
• Unstructured extraction - Supplier declarations and lab certificates in PDFs, emails and spreadsheets are turned into structured DPP fields
• Substances-of-concern matching - Substances aligned to your SCIP declarations and thresholds with name, concentration and location
• Gap detection built in - The agent tells you exactly which fields it cannot source, so your team chases only the true gaps
• Change-tracking by design - When a part, supplier or formulation changes, the affected passports rebuild instead of quietly going stale
• DSGVO-ready compliance - EU hosting, AVV, no-training guarantees, and a full field-level audit trail
• 90-day pilot scope - One product group, a field-gap report, validated passports, written success criteria - go or no-go after 90 days

Decision Framework

Not every manufacturer needs a DPP agent, and not every one is ready. The framework below helps locate which one you are.

Staff a small function for one product if

• You have one product group - A single niche line does not justify a build
• The data is already clean - Everything sits in one system, verified, in one format
• The passport rarely changes - Little engineering change means little drift to manage
• You need judgement, not volume - The task is deciding thresholds, not aggregating thousands of fields

Build a custom agent if

• You have a real portfolio - Hundreds of products across variants generate the aggregation load that produces the ROI
• Your data is scattered - The DPP fields live across ERP, PLM, quality and supplier declarations
• An OEM has set the clock - A customer has made the DPP a condition of the purchase order
• Passports must stay current - Frequent engineering change means drift you cannot manage by hand
• You want flat cost - You do not want a compliance cost that scales with your SKU count

Wait if

• Your product master is a mess - Clean the obvious gaps first; vague source data produces a vague passport
• No internal sponsor - Without an owner in product compliance or PLM, the project stalls
• No budget for the AVV and legal review - The compliance foundation is non-negotiable
• No deadline in sight - If neither a delegated act nor an OEM touches your products yet, map the fields but hold the build

Frequently Asked Questions

Related Articles

• The EU AI Act for the Mittelstand: What German SMEs Actually Have to Do
• AI as a Compliance Assistant: How the Mittelstand Automates Audit Trails, Policies, and Reporting
• Intelligent Document Processing: How the Mittelstand Replaces OCR With AI Agents
• AI in Procurement: How the Mittelstand Tames Suppliers, Prices, and Risk
• AI in Quality Management: How the Mittelstand Cuts Defects and Documentation Load
• AI in Mechanical Engineering: How the Mittelstand Builds Smarter Machines

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI agents that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. He believes the Mittelstand has everything it needs to lead in AI - it just needs the right approach.