Ask ten engineering leaders whether their data is ready for artificial intelligence, and most will hesitate. That hesitation is understandable, but it's based on the wrong question. "AI-ready data" is not a single bar to be cleared just once by an organization. Data readiness depends entirely on the specific decision, review, or workflow you're pointing the AI at; and what's ready for one use case may not be ready for another.
To be "AI ready," engineering teams need to test the decision in front of them — not the organization as a whole — and prove it one use-case at a time.
A standard everyone trusted, but AI couldn't use
A manufacturer we work with recently uploaded an extensive injection-molding standard to guide an AI-assisted design review. The document covered part design, tool design, and cost considerations. The engineering team considered the document quite thorough. Yet, during a review when the AI agent was pointed at the injection molding standard, almost none of the guidance made it into the output.
Some engineering leaders may consider this evidence that current AI models are not ready for complex tasks like engineering design reviews. That’s not always the case.
In this particular case, the injection molding standard relied on markups in the form of circled features, arrows pointing at problem areas, and relatives like "small" and "large" instead of numbers or tolerances. That format works only when the person reading it already knows what the circle means, or what "small" refers to in that context. AI has no way to fill in that knowledge gap. It cannot ask a follow-up question, and it has no memory of the meeting where someone explained the reasoning out loud.
All the AI had was a page of visual shorthand with no objective criteria attached, so it skipped over most of it.
When our own engineers went back to read the standard after the AI failed, they had trouble reconstructing the logic too. The knowledge in that standard was real. But a few missing links lived in the heads of the people who wrote it, not on the page. Nobody else – human or machine – could act on it without asking them directly.
Why engineers know more than they write down
We see this same scenario playing out across the manufacturing sector as engineering organizations move past pilots and try to integrate AI into daily workflows.
Every design decision draws on two kinds of knowledge. There is explicit knowledge: drawings, specs, standards, and requirements. And there is implicit knowledge: the tradeoffs a senior engineer remembers from three programs ago, the reason a tolerance got tightened after a field failure, the context a junior engineer would get only by asking the right person at the right meeting.
Engineers move between both knowledge categories without noticing, while AI has access only to the first category.
It is because of this gap that so many engineering organizations get stuck asking whether their data is “ready” for AI. But, as noted, it's the wrong question because readiness is not a property a company's data either has or lacks across the board.
The only way to know if your data is AI-ready is to test it in a specific workflow; and even then you will only know if it’s ready for that workflow. Therefore, chasing a single, organization-wide standard of “AI readiness” keeps teams in planning mode indefinitely, because the target moves as fast as the organization generates new programs and new engineers.
Testing true readiness, one use case at a time
So, what actually works when it comes to determining readiness?
It’s narrower and less satisfying to plan around: pick one decision, one review, one recurring bottleneck, and test AI against it directly. In one pilot, a broad goal like "AI-assisted drawing review" was narrowed down to three specific checks: machining stock, threaded-insert hole size, and obsolete specifications.
That narrow scope revealed exactly which rules the AI needed and which ones it was missing, something a broader rollout would have obscured for months.
The fixes that result from that kind of test are specific and actionable, creating a roadmap that moves the organization toward AI-readiness. Guidance gets rewritten as criteria specific enough that an engineer outside the program, not just the original author, could apply it correctly.
Even where the right knowledge exists, AI can retrieve a valid document and still apply it to the wrong situation. For example, it might apply a generic industry standard even when an internal rule was meant to override it, simply because nothing tells it which one takes precedence.
Design intent and CAD data that lived in separate systems become connected. Internal rules that everyone on a team already knows - but nobody wrote down - get documented, so a new tool (or a new hire) does not have to guess. And the decision rationale that used to disappear into old meeting notes gets captured somewhere that the next program can actually find it.
The payoff goes beyond AI
None of that work is specific to AI. It is the same documentation discipline that has always made engineering teams faster to onboard, easier to audit, and less prone to relearning the same lesson on every new program. AI is just making the cost of skipping that work visible in a way it never was before.
The organizations pulling ahead on this are not the ones with a finished data-governance plan. They are the ones willing to run a small, specific test … take an unimpressive first result seriously… and use that to fix one real gap before moving to the next program that needs the same treatment.
Readiness was never a status to reach. It's a habit. Pick a use case, run the test, fix what breaks, and move to the next one. The engineering organizations that get this right have stopped waiting for perfection and started testing instead.
