Why Document AI Won't Fix Your Product Data

IBM and NVIDIA just dropped a massive announcement at GTC 2026. Docling, Nemotron, GPU-accelerated everything. Nestle cut query runtime from 15 minutes to 3 minutes across 186 countries. 83% cost savings. Jensen Huang called it “redefining data processing for the AI era.”

And honestly, they’re right.

But here’s the part nobody wants to talk about: general-purpose document extraction - no matter how fast or how cheap - will not solve your product data onboarding problem. Not even close.

I’ve led over 70 PIM implementations across industries, and the pattern is always the same. A company invests in document AI, extracts text from PDFs and supplier sheets, and then watches in horror as their PIM fills up with garbage. Clean garbage, mind you. Beautifully extracted garbage. But garbage nonetheless.

The problem isn’t extraction. The problem is that product data has rules that no document parser understands.

What does document AI actually extract from supplier files

Let’s get specific. IBM’s Docling can parse PDFs, slide decks, spreadsheets, and convert them into structured JSON or Markdown. It’s brilliant for turning annual reports into searchable data. For making legal contracts machine-readable. For feeding RAG pipelines with corporate knowledge.

But open a typical supplier product sheet and you’ll find something different:

See the gap? Document AI extracts text. Product data onboarding requires semantic transformation - mapping unstructured supplier language into structured PIM attributes with validation rules, unit conversions, taxonomy alignment, and completeness checks.

That’s not a parsing problem. That’s a domain intelligence problem.

Why 80% of enterprise data stays trapped despite better tools

The 80-90% unstructured data statistic gets thrown around constantly. Gartner says 85% of AI projects fail to deliver expected business value due to poor data quality. And now we have Docling processing 2.1 million PDFs from Common Crawl alone.

So why isn’t the problem getting smaller?

Because extraction without transformation is just moving the mess from one format to another. In product data, this shows up as:

• Attribute explosion: Document AI pulls 200 fields from a supplier sheet. Your PIM expects 47 specific attributes mapped to a product family. Who decides what maps where?
• Unit chaos: One supplier sends dimensions in inches, another in centimeters, a third uses “L x W x H” while the fourth uses “W x D x H.” Document AI faithfully preserves all four formats. Your PIM rejects three of them.
• Taxonomy mismatch: The supplier calls it “Outdoor Furniture > Garden Chairs.” Your PIM taxonomy says “Exterior > Seating > Chairs > Garden.” Close enough? Not for automated downstream channels.
• Completeness blindness: Document AI tells you what’s there. It can’t tell you what’s missing against your PIM’s required attribute set. And what’s missing is usually what kills your product listings on marketplaces.
• Locale and channel gaps: Your PIM needs product data in 5 languages, with marketplace-specific attributes for Amazon, Zalando, and your own webshop. The supplier sent one language. Document AI extracted it perfectly - in one language. Now multiply that gap across 200 product families.

From our implementation data, the average supplier file arrives with only 34% of required PIM attributes filled correctly. Document extraction bumps that to maybe 40% - you’ve digitized the text, but you haven’t solved the other 60%.

The real cost isn’t in extraction. It’s in the transformation, validation, and enrichment that happens after. And that’s where teams burn EUR 14,000 per 1,000 products in manual labor.

How Akeneo and others are approaching this differently

Credit where it’s due - the market is starting to recognize this gap. Akeneo’s Supplier Data Manager just shipped AI-powered mapping suggestions in beta (March 9, 2026), with confidence scores for attribute matching. They’ve also added email-to-job workflows so suppliers can submit data by simply emailing a CSV.

Pimcore has been working on their Copilot features. SKULaunch positions itself as handling “whatever suppliers send” with validation and normalization.

These are all steps in the right direction. But look closely and you’ll notice a pattern: each solution is locked to one PIM. Akeneo SDM maps to Akeneo. Pimcore Copilot maps to Pimcore. If you’re running Ergonode, or a custom PIM, or migrating between systems? Back to Excel hell.

The thing is, product data onboarding is a cross-PIM problem by nature. Suppliers don’t know or care what PIM you’re using. They have their data in their format and they’re sending it to you regardless. The onboarding layer needs to sit above the PIM, not inside it.

What does a product data onboarding pipeline actually need

After 70+ implementations, I can tell you the minimum viable pipeline. And it’s not “better OCR”:

1. Schema awareness. The system must know your PIM’s data model - product families, required vs. optional attributes, validation rules, allowed values, measurement units. Without this, every transformation is guesswork.

2. Supplier-to-schema mapping. Not just column-to-column matching. Real mapping handles synonyms (“colour” vs. “color”), unit conversions (inches to cm), taxonomy alignment (supplier categories to your categories), and composite field splitting (“30x40x15” into three separate dimension fields).

3. Completeness scoring. Before any human touches the data, the system should report: “This file covers 72% of required attributes for the Outdoor Furniture family. Missing: weight, country_of_origin, care_instructions, warranty_period.”

4. Cost estimation before processing. Here’s something almost nobody offers: telling you before you start how much the onboarding will cost in time and money. If you know that a particular supplier’s file will take 4 hours of AI processing plus 2 hours of human review, you can plan. You can negotiate with the supplier to improve their data quality. You can build a defensible business case for your CFO.

5. Validation against the target PIM. Not just “is this valid JSON?” but “will Pimcore accept this value for this attribute in this locale for this product family?” That’s PIM-specific logic that no document AI can replicate.

6. Traceability and audit trail. With EU Digital Product Passports arriving in 2026-2027, regulatory pressure on product data provenance is about to get real. You’ll need to prove where every product attribute came from. Which supplier file? Which version? What transformation was applied? When was it validated, and by whom? Document AI gives you the raw extract. You need the full chain of custody from source to PIM to marketplace.

Companies that figure this out early won’t just meet compliance requirements - they’ll have a competitive advantage in every RFP that asks about data governance. And trust me, those RFPs are already showing up.

Skipping any of these steps means you’re still doing manual work downstream. And manual work at EUR 14 per product adds up fast when you’re onboarding catalogs of 10,000+ SKUs. Multiply that by 5 supplier onboardings per quarter and you’re burning through an entire FTE salary just on data entry that should be automated.

The real ROI math behind product data onboarding automation

Let me walk through the numbers we see in real implementations. These aren’t projections - they come from actual projects across retail, manufacturing, and distribution.

Manual onboarding (the baseline):

• Average time per product: 45 minutes (mapping, entering, validating, correcting)
• Cost per product at EUR 35/hour loaded rate: ~EUR 26
• 1,000 products: EUR 26,000 and roughly 750 person-hours
• Error rate: 8-12% requiring rework cycles

Document AI extraction only:

• Extraction time per product: near zero
• Manual correction, mapping, and validation: 30 minutes per product
• Cost per product: ~EUR 17.50
• 1,000 products: EUR 17,500 and 500 person-hours
• Savings vs. manual: 33%
• Error rate: 5-8% (fewer typos, same mapping issues)

Domain-specific AI onboarding (schema-aware, PIM-targeted):

• AI processing per product: seconds
• Human review and approval: 3-5 minutes per product
• Cost per product: ~EUR 1.40 (including AI compute + human review)
• 1,000 products: EUR 1,400 and roughly 60 person-hours
• Savings vs. manual: 95%
• Error rate: under 2% with confidence scoring

That gap between “document AI” and “domain-specific onboarding AI” is where the real money sits. Document extraction gets you a third of the way there. The last two-thirds - the expensive two-thirds - require intelligence that understands product data semantics.

And for a CFO reading this: the payback period on proper onboarding automation is typically under 3 months when you’re processing more than 2,000 SKUs per year. After that, it’s pure margin improvement. Not “potential savings.” Not “projected efficiency.” Actual money staying in your business every single quarter.

Here’s what makes this even more interesting: the companies that automate onboarding don’t just save money on data entry. They also cut their time-to-market by weeks. A product that takes 6 weeks to onboard through manual mapping and validation can go live in days with the right tooling. In seasonal retail, that’s the difference between catching the sales window and watching it close. Can your margin afford that gap?

What IBM and NVIDIA got right and what they missed

Look, I’m not here to trash the IBM-NVIDIA partnership. What they announced at GTC 2026 is genuinely important. GPU-accelerated analytics, Docling for document processing, Nemotron for content extraction - these are foundational building blocks.

But they’re solving the infrastructure layer. The “how do we process documents fast” problem. They’re not solving the domain layer. The “how do we turn this supplier PDF into PIM-ready product data” problem.

Actually, scratch that - they’re not even trying to solve the domain layer. And they shouldn’t be. That’s not their business.

The businesses that will win in 2026 are the ones that combine:

1. Fast extraction (Docling, Nemotron, or whatever comes next)
2. Domain-specific transformation (product data AI that knows PIM schemas)
3. Pre-run cost transparency (so you know the business case before you commit)
4. PIM-agnostic output (because your PIM choice shouldn’t dictate your onboarding tooling)

If you’re evaluating document AI solutions for your product data, ask this one question: “After extraction, who maps the data to my PIM schema?” If the answer is “your team, manually” - you’ve just automated the easy 30% and left the expensive 70% on the table.

That’s not transformation. That’s decoration.

Ready to stop decorating and start transforming

If your onboarding still runs through a cycle of “extract, manually map, manually validate, manually correct, pray” - the problem isn’t your extraction layer. It’s everything that comes after.

Book a demo with openProd.io and see what PIM-aware, schema-driven onboarding actually looks like. Pre-run cost estimates included. No Excel required.

Or start with a quick supplier data quality audit - 15 minutes can tell you whether you’re looking at 2 hours of onboarding or 18 hours of cleanup. That number alone might change how you negotiate with your next supplier.

Sources and Further Reading

• IBM and NVIDIA Expanded Collaboration at GTC 2026 - IBM Newsroom, March 16, 2026
• 80% of Enterprise Data Is Unstructured - Ertas AI, March 2026
• Docling: A New Tool to Unlock Data from Enterprise Documents - IBM Research
• What’s New in Akeneo Supplier Data Manager 2026 - Akeneo Help Center
• From PDFs to PIM: How Distributors Tame Supplier Data Chaos - Start with Data / SKULaunch
• Enterprise AI in 2026 Will Fail Without Data Readiness - LinkedIn
• The End of ‘We’ll Build It In-House’: Document Processing Predictions - AnyFormat.ai