The chemical industry has talked itself into a set of beliefs about AI that sound careful but in most cases are wrong in a costly way. They get repeated in meetings, on stages, on LinkedIn, until they harden into conventional wisdom and most of them are costing companies opportunities. Here are seven worth retiring.

1. "We're not ready for AI because our data isn't clean."

The logic is responsible: get the house in order, then bring in the AI. For some companies there's history behind it too, where messy data really did break the initiatives they tried before.

But the data is never clean. There is always another taxonomy to fix, another batch of TDS files to update, another field someone wants to standardize first. The cleanup is a horizon that moves as you walk toward it, and the whole time you're walking, you're forgoing the leverage you could have had. Most companies have a use case or two sitting right there the entire year, reps losing hours a week answering the same product substitution questions the old slow way.

There's a deeper problem with cleaning first. Any cleanup effort forces a group of people to make assumptions up front about users, applications, and what the data is for, before anyone has actually used the thing. Assumptions made that early are the classic way software goes wrong.

A deployed application flips the order. Real usage shows you which data actually matters, what's wrong, and what to fix first, at a scale and quality that manual cleanup can't reach. The application becomes the lever that cleans the data, not the reward you get after.

None of this means data doesn't matter. It matters enormously, which is exactly why you shouldn't waste a year guessing at it. The data work worth doing is the kind shaped by real use: the product attributes people actually query, the gaps that surface when an answer comes back wrong, the structure that earns its place because a workflow needed it. That's a different discipline from cataloguing everything to a standard nobody asked for.

This isn't just my read. MIT's 2025 State of AI in Business study found that about 95% of corporate generative AI pilots deliver little to no measurable impact on the bottom line, and the cause isn't model quality or messy data, it's that generic tools stall when they don't learn from how a team actually works. Readiness prep isn't what creates value. Deploying into a real workflow is.

So I'd ask a different question. Which commercial workflow creates measurable value fastest? Pick one. Sales enablement, lead qualification, customer-facing assistants, document generation, whatever has the biggest opportunity. Deploy it on the best data you have today and let the usage pull the data in the right direction. It's faster and cheaper than the cleanup project, and the companies pulling ahead are compounding real workflows while their competitors are still scoping a data effort that will never declare itself finished.

2. "We need a PIM in place before we can benefit from AI."

This one has the same shape as the first. Before AI can do anything useful with our products, the thinking goes, we need the product information management system stood up, the catalogue loaded, the taxonomy locked. For years, a clean PIM was in fact the precondition for doing anything at scale with product data.

But a PIM implementation is a long project, not a quick prerequisite. Enterprise rollouts routinely run a year or two, with a dedicated team hand-mapping thousands of attributes into a target model someone defined up front. That's the cleaning-first trap wearing a different hat: a group of people making assumptions about structure before anyone has used the thing, while the workflow that would have paid for itself sits unbuilt behind it.

The sequencing is wrong now because the hard part of a PIM has moved. The expensive work was never the database. It was turning messy source material into clean structured form: TDS and SDS PDFs, supplier spreadsheets with three names for the same attribute, legacy fields nobody remembers defining. That job was manual and slow, and it's exactly what modern AI is good at, reading an unstructured spec sheet, extracting the attributes, normalizing the units, mapping them into a schema. A chemical-specific platform does this natively, because it already knows what a viscosity spec or a REACH flag or a discontinued grade should look like. We've seen structuring work that took a person days happen in minutes. The onboarding that made the PIM a year-long prerequisite is now the fast part, which means AI produces the structured data rather than waiting in line behind it, and it can start doing commercial work off your existing sources while the structuring happens underneath.

Structure and governance still matter, and someone still owns the taxonomy, the validation, the drift as the catalogue changes. That's a system you tend continuously next to something that's already running and already showing you which data matters, rather than one giant up-front project with all the value locked on the far side. If you already run a PIM or you're mid-rollout, the practical pattern is an AI layer working alongside it, feeding it structured data faster than manual onboarding could.

So don't sequence it PIM first, AI second. Point AI at the product information you have, in whatever shape it's in today, and let it both do the structuring and run the workflow that pays for it. The PIM, if you decide you want one, gets built better and faster on the other side, shaped by real use instead of a year of guesses.

3. "It's just a fancy Q&A. We could build this ourselves."

Most AI products look the same. A box, you type, an answer comes back. It looks simple, and it looks identical to the last three tools you saw, so the natural reaction is that it's a thin wrapper over a model anyone can call. From there it's a short step to "we can build this in house in a few months," or "whatever agent builder ships with the stack we already own will get us there."
The interface is the smallest part. The simplicity you're seeing is the output of the hard work, not the absence of it. Behind that box is the data modeling, the retrieval that knows your products from your noise, the validation that catches a discontinued SKU before it reaches a customer, the evaluation infrastructure, the drift correction as your catalogue changes. Two tools with the identical text box can be 70% right and 99% right, and nothing on the front end tells you which one you're looking at.

The gap shows up on the invoice too. When a system skips the work of preparing context, the model has to reconstruct that context itself on every single query: which grade is current, which spec sheet supersedes which, what a cryptic field in your legacy export actually means. It burns tokens doing detective work that a structured product library would have settled once, and it burns them at frontier-model prices, on every question, forever. Give the model a semi-structured base to reason over and the same question comes back more accurate and cheaper at the same time. There's a rule of thumb worth internalizing here: if a system is routinely filling most of its context window, something upstream is wrong. Effort skipped in development shows up later as a stuffed context window, worse answers, and a bigger bill, and those three travel together.

The same accumulated experience decides which model even sees a question. A system that has benchmarked thousands of real chemical queries knows which ones need a frontier model and which can be handled by something far cheaper without losing accuracy. A generic wrapper sends everything to the most expensive model, because it has no basis for doing anything else.

The MIT study I mentioned earlier found that buying from a specialized vendor succeeded about 67% of the time, while building in house worked only about a third as often. Judging an AI tool by how simple it looks is how you talk yourself into a build that runs two years and never reaches the last mile, or into stretching a generic tool to do a job it was never shaped for. The part that's easy to copy is the box. The part that's hard, and the part that decides whether the answers can be trusted and what they cost you to run, is everything you can't see.

4. "We should trim our product data down so AI can find it."

I heard a clean version of this recently. A large manufacturer was reworking its product pages for AI search engines, taking long, detailed TDS and distilling each product down to a few bullet points on page one, so AI could find and surface the product faster. It sounds reasonable. Shorter, tidier, easier for a machine to parse.

However, it’s an outdated approach. The instinct treats AI like the search engines of the last twenty years, where you trimmed and tagged your content to feed a keyword index. That's not how these systems read. Models don't need you to pre-digest your data; they reason over it, and they do better with more of it. Every bullet point you cut is a technical detail, an application note, a constraint that some buyer's query was going to match against.

Here's the part that should worry a commercial leader. Discoverability in AI search rewards information, not brevity. If you spend the next year summarizing your catalogue into bullet points, a competitor with worse products but richer data about them will surface above you, because the AI has more to match on. You'd be disarming yourself in the exact channel you were trying to win. Reducing your data to be "AI-friendly" makes you harder to find, not easier.

So keep the depth. Point AI at the full, messy richness of what you know about your products, and let it do the reasoning. The detail you were about to throw away is the thing that makes you findable and makes the answer right.

5. "We need to pick a winner: Copilot, ChatGPT, or a vertical tool."

This shows up in nearly every evaluation I'm part of. A company treats AI as a single decision: choose Copilot, or ChatGPT, or a vertical tool, deploy it, and that's "doing AI." It's a natural assumption, because that's how enterprise software used to work. You picked an ERP, a CRM, and you lived with it.

AI doesn't arrive as one system you standardize on. It shows up in many places at once, and the right move is usually several of them together. Some of it bakes into tools you already run, and the AI features landing inside modern CRMs are a good example, useful right where your team already works. Some of it is an entirely new workflow that didn't exist before, like a customer-facing assistant that answers technical product questions the moment they're asked. These aren't competing choices. A company can have AI quietly improving the CRM and a purpose-built assistant running a workflow no off-the-shelf tool covers, at the same time. It's already the norm at the companies furthest along: in Andreessen Horowitz's 2025 survey of 100 enterprise CIOs, running several models in production at once was standard, with 37% running five or more, up from 29% the year before. They aren't picking one tool, they're matching tools to jobs.

So the question isn't which single tool wins. It's how you can reimagine your organization with AI earning its place across different functions, and what each job actually needs. When a buyer frames it as picking one tool to solve everything, they end up forcing one product to do work it was never built for, and getting a mediocre version of several things at best instead of a strong version of each.

6. "We need to own our model."

Somewhere along the way, owning the model became a proxy for being serious about AI. I understand the instinct. If this technology is going to be core to your business, owning it sounds like control.

For almost every chemical company, owning the model is a liability that looks like a capability, at least for now. There is effectively one frontier model for a given task in a certain period, the best one from OpenAI or Anthropic or any other lab in the future, and that badge rotates every few months. Stanford's 2025 AI Index shows how thin and how mobile that lead has become: the performance gap between the best model and the tenth-best fell from 11.9% to 5.4% in a single year, and the top two are now separated by 0.7%. The frontier is crowded, and the leader keeps changing.

The model is not where your advantage lives, similar to your cloud provider. It does not really matter if you are on GCP, AWS or Azure or any other set up. What matters is the applications built on top. What you'd actually be signing up to own is the system around it: the data modeling and taxonomy, the source governance, the validation logic, the evaluation infrastructure, the drift correction, and the change management as your catalogue and your business keep shifting; forever. Software is gardening, not manufacturing. You don't finish it and walk away; you prune it for the rest of its life.

Almost no chemical manufacturer's edge is in AI architecture. It's in formulations, product knowledge, services and relationships. Own the commercial layer where that edge lives, and buy the infrastructure underneath it. The companies that get this spend their scarce engineering attention on the things only they can build, and treat the model as a fast-moving input they can swap as the lead changes hands.

7. "If the answer sounds smart, the AI is working."

Fluency is a reasonable bar for a lot of knowledge work. For technical sales it's the beginning of a failure mode. A general tool returns a clean, confident product recommendation, it gets passed to a customer because it reads like a real one, and only later does someone notice the product was discontinued months ago or violates a constraint that should have ruled it out immediately. The answer was wrong and nothing about it felt wrong.

This is why a polished demo proves almost nothing. A demo runs on a handful of friendly questions in a controlled room. The real test is the thousandth question from a real customer, the edge cases, the messy phrasing, the product that was discontinued last week. You don't find out whether a system that complex actually works until it's run in the world long enough to be trusted, and a smarter model doesn't shortcut that clock. Noam Brown, who pioneered OpenAI's reasoning models, made a version of this point recently: the only sure way to know how an AI agent behaves over a year may be to run it… for a year. Correctness earned that way is the kind a competitor can't buy or copy overnight.

In chemical work, 70% right and 99% right aren't close, they're different products, and the gap is invisible until it costs you a customer's trust. So judge a system on whether it's right on your hardest real questions over time, not on whether it dazzled you in a demo. I've written before about what good actually looks like, so I won't repeat it here.

What these have in common

Look at the seven together and the same misconception runs through all of them. Each one puts the attention on the model, or on getting "ready" for the model, and treats the actual work, your products, your workflows, your customers, as something to tidy up on the side or assume away. The data has to be perfect first. The system of record has to be stood up first. The tool has to be simple enough to build yourself. The data has to be stripped down. The model has to be chosen, or owned, or judged by how impressive it sounds. The real commercial workflows, where value actually shows up, keep getting deferred.

The companies that are winning with AI in this industry have flipped that. They start from an opportunity that matters, they accept that their data will not be perfect, and they treat the model as a commodity input to a system they're building around their users. That's the bet we've made at Kimia, and it's the pattern I keep seeing in the teams that pull ahead regardless of what tools they use.

If you take one thing from this: stop getting ready for AI, and put it to work on the most expensive hour of your week. The readiness you're waiting for is something you build by starting, not before.