ChatGPT for Product Data? And Then What?

What if you pasted your supplier list into ChatGPT and an hour later had clean product titles, extracted attributes and finished descriptions? Anyone who has tried it knows that it works. That is exactly why one sentence comes up in so many teams, and at first glance it sounds perfectly reasonable. Why would we buy a PIM when we can build this ourselves?

This objection deserves an honest answer, not a defensive reflex. Building it yourself takes you further than some vendors admit, and less far than many teams hope. The difference is not in the answer, but in the process.

An image helps here. Cooking for twelve guests takes skill and good ingredients. Cooking for two hundred every day also takes a shopping plan, allergen labelling, hygiene records and a stand-in for the cook. The recipe has not changed. The operation has.

What ChatGPT and Excel can genuinely solve

Let us start with what is true. From a supplier list with free-text columns, a language model can extract attributes with surprising reliability. "Tile adhesive grey, 25 kg, C2 TE" becomes pack size, colour and product class in separate columns. Descriptions in the tone you want appear in seconds. And an Excel template with required fields, dropdown lists and validation formulas gives the whole thing a structure a team can actually understand.

For a manageable range, one sales channel and one person who has the workflow in their head, that is a sensible solution. You learn a lot along the way. Which attributes do you really need? Where do suppliers deliver unusable data? Which fields can never be filled automatically? Whoever starts this way ends up writing better requirements than any workshop would produce.

We say this deliberately and plainly. An objection you only talk away does not get smaller. Try it before you buy anything.

And then what?

The problem does not begin with the first run. It begins with the hundredth, when someone else starts it, a second channel is added and somebody asks where this number actually came from. These moments deserve a closer look.

Who changed this, and when?

At some point someone asks why an item has said "waterproof" since Monday. Was it the prompt? A manual correction? The supplier list? In an Excel file with a chat history, that is rarely reconstructable.

This is not about bureaucracy. Data provenance is the basis for trusting a value. For products with labelling obligations, warranty claims or complaints, it is also the basis for being able to prove a value. What you need is a log that records who changed which value and when, what stood there before, which source the new value came from and whether a person or a model set it. A "last modified" column does not replace that. Record where every value comes from before you have a hundred values.

Who is allowed to do what?

In a shared Excel file, everyone who can open it can do everything. You notice as soon as two people work at the same time, and you notice unpleasantly as soon as someone overwrites the price column.

Real product data work is divided by roles. Editorial maintains texts, purchasing maintains prices and supplier data, a marketplace manager approves for Otto but not for Amazon. Add tenants when several brands or legal entities are involved, channels with their own rules and languages with their own owners. Who may change categories, who may grant approvals, who may only read? Bolting these questions onto a grown home-made solution afterwards is the moment where many projects stall. There is simply no permission model to build on. Decide early who may do what.

When the ground shifts beneath you

A home-made solution is never finished. Marketplaces document required attributes, value lists and interface versions themselves, and they change them. Your shop gets updates. Your categories grow. And the prompt that delivered what you wanted in spring delivers something slightly different after the provider changes its model: shorter, formatted differently, with a new quirk in units of measure.

Nobody notices right away, because every single answer looks plausible. That is exactly what makes gradual prompt drift so treacherous. What helps is test cases, comparison runs, versioned prompts and someone for whom all of this is a job, not a side task. Plan upkeep as permanent working time, not as a leftover.

Every interface is a small product

The moment data has to leave the spreadsheet is the real stress test. The ERP delivers the item master, the shop expects a certain format, Amazon, eBay and Otto each expect their own. Every one of these connections means authentication, mapping your attributes onto foreign fields, handling error messages, retrying after an interruption and partial imports that do not create duplicates. And every connection has to be maintained when the other side changes.

A CSV export is quickly written. An export that gives the same result the third time, reports faulty rows cleanly and continues after an interruption without manual work is a small software project. Multiplied by the number of your channels, it becomes a large one. Estimate interfaces in developer days, not in prompts.

An answer is not a process

A chat window is excellent at reading data and giving an answer. By itself it is not built to write data back into a system reliably and with the right permissions. Whoever copies results from the chat into the database has moved the process to its most error-prone spot: the clipboard.

An answer is a text. A process is a chain of reading, checking, writing, approving and logging that runs the same way every time, even when nobody is watching. This is where MCP comes in, the Model Context Protocol, an open standard through which AI assistants can use defined tools of a system. What matters is who sets the rules. The system decides which tools exist, who may use them and what happens on a write. The assistant supplies the intelligence, the system supplies the reliability. For every tool, ask where the answer is written and who stands behind it.

Quality at scale

Generating one description is easy. Checking a thousand descriptions so that you can rely on them is not. Models occasionally invent properties that sound plausible and are not true, such as a material, a test standard or a compatibility. With single items you notice. With large volumes you only notice if validation rules, spot checks and an approval flow are in place. Who checks, who approves, what happens to objections? The check has to be part of the workflow and must not depend on one person's diligence.

Credentials and data leakage

Whoever feeds a chat window transfers product data to an external service, sometimes including purchase prices and supplier terms. Whether that is permitted depends on the contract, the plan and the data processing agreement under Art. 28 GDPR, and on whether personal data is involved, such as contact persons in supplier lists. Then there are credentials for shop, ERP and marketplaces that end up in scripts, spreadsheets and chat histories, where they do not belong. Clarify this before the first real data leaves the building.

Who owns the solution next year?

Last, the least spectacular point and perhaps the most consequential. Today the solution belongs to one person who understands it. They know why column M has to stay empty, which prompt applies to textiles and that the export does not run on Fridays. Then they change teams, go on parental leave or resign.

Their successor inherits a collection of files, prompts and habits that was never written down. This is not a reproach to anyone, but the normal case with home-built tools. It is a cost that appears in no calculation. A system differs from a hobby project in that it does not hang on one person. Document it while everything is still in your head.

How ainavio handles these points

ainavio is an agentic PIM (product information management) system, built as an agentic workspace for product data, and many of the points above are part of the system there instead of an extra task. Access runs through role-based access controls, and changes are recorded in audit-proof change logs. Required attributes prevent products from being published without complete data, and before every export the system checks completeness, consistency and channel conformity. Data can be imported and exported via Excel, CSV and a REST API, and connections to marketplaces and shops are part of the product.

The enrichment you start with ChatGPT today is handled there by agents with clear tasks. The Research Agent shows the source and a confidence rating for every attribute. The Quality Agent looks for missing information, duplicates and inconsistencies. The Workflow Agent manages approvals and tasks in the team.

The path from the chat window into the system is covered as well. Through ainavio's MCP Toolset, an AI assistant such as Claude can read products and write attribute values back via a connector, role-based. The conversation stays in the chat, the record stays in the PIM and the decision stays with you.

When building it yourself is enough and when it is not

Building it yourself is a good choice if all of the following apply.

• Your range is manageable and rarely changes.
• You supply one or two channels, and their requirements are stable.
• One person maintains the data and has enough time to also maintain the solution itself.
• Nobody needs to prove where a value came from, and no sensitive data leaves the company.

As soon as two of these points tip over, a shortcut turns into an operational risk. That is the case once a third channel is added, several people with different permissions work in the data, marketplaces change required fields or only one person still fully understands the solution.

If you are still hesitating, a simple test helps. Imagine the person who built your solution is unreachable for three weeks starting tomorrow. Does the next export run without them? If yes, your home-made solution is better than you thought. If no, you already know your answer to "And then what?".