Is your engineering data ready for AI, and how would you even know?
Many engineering organizations are hesitant to adopt AI out of fear their data isn’t ready. That’s a valid concern, but it shouldn’t prevent you from getting started. In this article, we discuss practical ways to start getting your data AI-ready, and present use cases to start on right away
The Expert
If you lead an engineering organization, you've probably been asked to come up with a strategy for AI. Somewhere early in working that out sits a question that's hard to get past: is our data even ready for this?
It's a fair question to be stuck on, and staying stuck gets expensive. Some teams decide the answer is no and start a data cleanup program with no application attached, so there's no way to know when they're finished. Others get a mediocre first result and read it as a verdict on AI rather than on their own material.
The trouble is there's no score you can check. "Ready" depends on the problem you're pointing at, and on whether the information that problem needs is there and usable. So I'd change the question. Not "is my data AI-ready," but "what's the smallest experiment that would show me where my data falls apart?" You get to that by pointing a tool at a real problem you care about and treating what comes back as the start of a discovery process.
What that experiment is really testing is narrower than it sounds. Not whether your data is “good” or “ready,” but whether the knowledge required to act on it actually lives in the data, or only in the heads of the people who wrote it. The clearest case I've seen started with a document everybody involved was sure was good.
What "not AI-ready data" actually looks like
A customer of ours uploaded an extensive standard for injection molding complete with part design, tool design, cost considerations, and more. All of it made sense to them. But when we instructed AI to reference that standard while reviewing a design, almost nothing from the document was considered in the analysis.
That outcome wasn't the fault of the tool, the model, or even the prompt. It was the input. The standards document was mostly images. There were parts circled in green, arrows pointing out different issues, and subjective guidance like "small" and "large" features, with nothing objective to act on. When our own engineers went back and looked at it, we couldn't really make sense of it either. The knowledge in the document was real, but it was subjective and assumed background knowledge that wasn't written down anywhere.
That's what "not AI-ready" looks like in practice: guidance a competent person can't act on unless they already know the answer.
When the first pass comes back inconclusive it may feel like a failure. But I'd be careful about thinking about it that way. That's the first real value you get out of a pilot, because it points out the unclear guidance that was already driving the rework and cost you brought AI in to help with.
Why the tool can't fill in the gap
When an engineer solves a problem, we work from two things at once. There's the explicit data set: the drawings, the specs, and the requirements. Then there's a second, implicit set we're mostly not conscious of. Things like knowledge of the decisions that have already been made and the tradeoffs that drove them, or why a tolerance got tightened two programs ago after something came back from the field.
We lean on that implicit layer constantly without noticing it. Which means we hand AI the explicit data, leave the implicit part out, and then treat the frustrating response as a problem with the tool. If I ask an AI tool to review a drawing for manufacturability without telling it lessons learned from previous programs, what cost I can tolerate, what's critical on the part, and what machine I have available, I never gave it enough context to reason through the problem.
The tool can't supply that context itself. These models learn from what's publicly available, and almost none of engineering is. General injection molding knowledge is out there. But your standards, your cost models, and the reasoning behind your last ten decisions are not.
What we're really asking AI to do is have the same kind of logic and reasoning as a really skilled engineer, just much quicker and much more consistently. If you can't track that logic yourself, it's not going to give you the answer you're looking for in a consistent way either.
The litmus test
I've alluded to the test I keep coming back to. If I gave the same problem and data to a competent engineer who was new to my organization, could they act on it in a reasonable way and land where the people with the tribal context would land?
If you can honestly say “yes”, you're probably in a good spot. If they'd have to walk down the hall to ask what a requirement really means, that's the gap. And it's the same gap the AI tool will run into.
When the answer to that test is “no”, in my experience it's for one of four reasons.
- The guidance assumes context the reader doesn't have.
Standards say "make this manufacturable," or point you at industry best practices without saying what that means in a given context. The molding standard example from above is the clearest example I've seen of this problem. More often it's a single line or a marked-up symbol in an otherwise solid document that only works if you already know what the author meant. Standards in that condition are common. When CoLab surveyed 250 engineering leaders in 2025, 45% said their design standards aren't documented, kept up to date, and consistently referenced in design reviews.
- The pieces were never connected.
Sometimes the knowledge is written down and still isn't usable because it's disjointed. Design intent lives in one document, requirements live in another, and the two were never made to speak to each other. That costs real money with no AI involved. At the part level, when engineers can't trace a design output back to its requirement and the risk attached to it, they inspect everything because they have no defensible basis for inspecting less.
On a big program, the same disconnect runs between disciplines. Each group keeps its decisions in its own system, and an interference nobody caught surfaces at installation instead of at design review. One organization we work with was losing seven figures and weeks of schedule on incidents like that.
- Nothing says which rule applies here.
Teams rarely catch this one because the people who matter already know the answer. We've seen it with GD&T, where the general standard allows three acceptable interpretations of the same callout and a company's own standard picks one. That choice is binding and it does exist in writing, but nothing tells a tool that the internal document outranks the general one, so it guesses.
It shows up as a scope problem too. Point a tool at a library of a few hundred guidelines with nothing indicating which apply to what, and we've watched a review pull in a guideline written for an entirely different class of part.
- The reasoning was never recorded.
Most organizations have a system of record for what changed and when. Far fewer have anywhere that captures why: the tradeoffs that were weighed or the risk somebody flagged in a review three years ago.
In the rare instances the rationale is captured, it often lands somewhere unreachable. One engineering organization we work with kept lessons learned in a legacy database. There were over a thousand approved entries, with two thousand more awaiting approval. Their own engineers called it difficult to search, and so it mostly went unused. None of it was missing, exactly. It just wasn't reachable by anyone who didn't already know it was there. That's why the same decisions get rehashed years later, and when asked why one was made, the answer usually comes from a person rather than a document.
To be clear, knowledge living in people's heads isn't negligence. It works fine while those people are in the building, but it's a single point of failure, and AI just exposes that. Research out of Rolls-Royce's civil aerospace division found nearly 80% of engineering queries get answered from memory with no document referenced. AI can only rise to the level of your written knowledge base.
How to make your data ready for AI
"Document better" isn't advice anyone can act on, so here's what actually changes when information goes from unusable to usable. We've done some version of this with almost every engineering organization we've onboarded.
Turn judgment into a checkable condition
"Avoid small features" can't be acted on by anybody, new hire included, because the number it represents lives in someone's head. Name the feature and the threshold, and say what the rule protects against. The same goes for guidance carried by green circles and arrows. Write the rule out in a sentence so it can be understood by somebody who wasn't in the room—or an AI.
Connect each check to the right source
One manufacturer we worked with wanted three checks running on drawings before release:
- Ensure enough material stock left for finish machining
- Correct hole sizing for the threaded insert going into it
- No references to specs that had been superseded
Making each run took work that had almost nothing to do with the checks themselves. Somebody had to write each condition out as an explicit release check, the applicable standards had to be loaded in as reference material, and a taxonomy had to say which standard governed which check so the review wasn't searching the whole library every time. The same applies when an internal standard overrides a general one. The hierarchy has to be written down rather than left to the reader's memory.
Fix the format
We also often have to change how manufacturers export drawings. In one instance, PDFs were arriving as flat scans with the text baked into the image. When this happens, the dimensions and callouts render not as text, but pixels shaped as text. This means that an AI tool reading the file needs to first decipher the characters, therefore increasing the likelihood of GD&T symbols, tolerances, or even words being misread. The fix sits upstream at the export step. Adjusting the settings ensures the files come out with their layers and searchable text intact.
Another team had the same problem one layer up. Their standards were searchable but structured inconsistently from one document to the next. Rebuilding them around standard headers and metadata tags gave AI the structure it needed to properly navigate reference material. Both of these examples sound like IT problems rather than engineering ones, which is why they're the last thing anybody checks. But they both point to the same core failure: the tool doesn’t have the context it needs, in this case because it simply can’t read it.
This work pays off. On one account, as we helped prepare the guidelines, the share of AI findings engineers marked as useful rose from about a quarter into the mid-forties. That isn't a universal readiness score, but it gave the team a practical way to see whether the documentation work was improving the output before they scaled anything.
This data discipline isn't glamorous, but it makes your data far more accessible and usable to both engineers and AI systems.
So where does that leave you?
Pick one real engineering problem and decide what a useful result would look like. Point AI at it in a way that lets you see what it pulled and what logic it followed. That's how you distinguish a traceable answer from one that merely sounds reasonable.
When the first answer comes back thin, don't reach straight for a better prompt. Use the result to work out which of those four things is missing underneath it. Fix one or two, run the same test again, and compare against the same measure. The second answer tells you whether you fixed the right thing.
That loop is about as close to a readiness score as you're going to get, and what it measures is whether the knowledge has moved out of your people and into your data.