AI for Engineering Knowledge Management
Buy vs build for AI on PLM data: the honest total cost of an in-house RAG system, what a copilot actually buys, and how to decide with numbers.
·
⏱
8 min read
Dr. Maor Farid
Maor Farid is the Co-Founder and CEO of Leo AI, the first AI platform purpose-built for mechanical engineers. He holds a PhD in Mechanical Engineering and completed postdoctoral research at MIT as a Fulbright fellow. A Forbes 30 Under 30 honoree and former AI researcher and Mechanical Engineer in an elite military intelligence, Maor leads Leo AI's mission to transform how engineering teams design better products faster.
BOTTOM LINE
Building an internal AI copilot on PLM data is a legitimate engineering project, not a naive one. It is also five projects wearing a single name: connectors, geometry indexing, evaluation, access control, and permanent maintenance. Only the first is enjoyable, and only the last never ends. MIT's Project NANDA found that just 5% of custom enterprise AI tools reach production, which suggests most teams are pricing the prototype instead of the system. Build if retrieval over engineering data is your product, if you can name its owner 18 months out, and if you already have a graded question set to measure it with. Buy if the goal is simply that engineers stop losing hours to search. Either way, define the success metric first, and give the decision 90 days rather than nine months.
Somewhere in most engineering organizations there is a slide deck proposing an internal AI assistant that answers questions about the company's own parts, drawings, and past projects. The pitch is reasonable. The data already sits in PDM and PLM. Retrieval augmented generation is well documented. Two engineers and one quarter should do it.
Sometimes that is exactly right. More often the quarter becomes a year, and the prototype never becomes something an engineer trusts enough to rely on before releasing a drawing.
MIT Media Lab's Project NANDA measured this pattern. Its July 2025 report, The GenAI Divide: State of AI in Business 2025, drew on more than 300 disclosed AI initiatives, 52 structured interviews, and 153 surveys of senior leaders. One finding matters more than the rest for this particular decision: only 5% of custom enterprise AI tools reach production. Not 5% that deliver exceptional returns. 5% that ship at all.
That is not an argument against building. It is an argument for costing the build honestly before committing to it. What follows is the case for building, the five cost lines internal estimates routinely miss, why engineering data is harder than document search, and a decision test you can defend with numbers.
The case for building is stronger than vendors admit
Any honest version of this comparison has to start by taking the build option seriously, because there are real conditions under which it is the correct call.
You own the roadmap. Nobody deprioritizes the requirement that matters to your niche. If your parts are governed by an unusual internal standard or a customer-specific approval workflow, an internal team can treat that as the primary use case rather than a feature request.
No per-seat cost curve. Internal tools do not get more expensive as headcount grows. For a large organization with a long horizon, that arithmetic can eventually favor building.
Nobody knows your metadata better than you. Retrieval quality on engineering data depends heavily on understanding your own part numbering, revision conventions, and folder history. That knowledge is already inside the building.
Sometimes it is the product. If retrieval over engineering data is what your company sells, or a defensible part of how you sell hardware, building is the only sensible option.
Building is right more often than vendor marketing suggests, and considerably less often than internal enthusiasm suggests. The distance between those two estimates is where budgets go to die. The way to close it is not to argue about principles. It is to price the whole system rather than the prototype.
IN PRACTICE
It integrates directly with PLM and existing workflows, making past designs, standards, and calculations instantly available. The result is fewer errors, faster decision-making, and a more consistent process across teams.
- Sergey G., Board Member
The five cost lines internal estimates miss
A working prototype over a folder of PDFs takes a competent engineer about a week, which is exactly what makes this decision dangerous. The week-one demo creates the impression that production is close. These five items are what actually stands between the demo and something an engineer will trust.
Connectors and change capture. Reading from PDM, PLM, and ERP once is straightforward. Staying synchronised is not. You need incremental updates, deletion handling, revision state, and permission changes reflected within minutes rather than nightly. Every source system upgrade is a maintenance event on your side.
Geometry indexing. Text retrieval splits documents into passages. A solid model has no passages. Searching by shape needs geometric descriptors, feature recognition, and tessellation choices that affect what counts as similar. This is a specialist discipline, not a library import.
Evaluation infrastructure. Without a graded set of real questions with known correct answers, you cannot tell whether a retrieval change helped or hurt. Teams defer this because it is unglamorous, then spend months tuning blind. What goes into the index determines what comes out, which is the same reason the provenance of AI training data matters so much in engineering contexts.
Access control and security review. The assistant has to reproduce each user's effective PDM permissions exactly, per query, including inherited and project-scoped rules. Then it has to survive an internal security review, which is a slower and more thorough process than most project plans assume. Buyers apply the same standard to vendors, which is why SOC-2 certification carries weight in engineering AI.
Permanent maintenance. Corpora drift as projects close, models get deprecated, and query patterns shift as engineers learn what the tool can answer. This line item has no end date, and in most organizations it has no named owner either.
Project NANDA identified the root cause of stalled enterprise AI as a learning gap rather than an infrastructure gap: most systems do not retain feedback, adapt to context, or improve over time. Closing that gap is an ongoing engineering discipline. It is the fifth item on that list, and it is the one nobody budgets.
Engineering data breaks the assumptions document RAG is built on
Most published guidance on retrieval augmented generation assumes a corpus of text where every document has one version, one audience, and where semantic similarity is a good proxy for relevance. Engineering data violates all three assumptions at once.
A part has a revision history and a lifecycle state, so the most textually relevant document may describe a superseded design. Access is unevenly scoped, so the best answer may be one this particular engineer is not cleared to see. And relevance is not about word overlap at all. It is about fit, manufacturability, and approval status.
That produces three failure modes worth naming, because each one has a cost that a bad web search result does not:
The superseded revision. The system confidently returns rev B while manufacturing is building rev D. The answer reads as correct, which is what makes it expensive.
The permission leak. An assistant that flattens permissions to index more content will eventually surface a customer-restricted design to the wrong engineer. One occurrence ends the pilot.
The plausible non-substitute. A geometrically similar part comes back that is not an approved substitute for this application. The engineer reuses it and discovers the difference during qualification.
A wrong answer to "has anyone here designed a bracket like this" is not a poor search result. It is a duplicate part number, a new supplier qualification, and a procurement cost that persists for the life of the product. This is the same structural problem behind why PDM search leaves engineers unable to find parts, and it is why generic AI struggles against purpose-built engineering AI on exactly this class of question.
What buying gets you, and what it costs you
The honest summary of the buy option is that you are paying to skip four of the five cost lines above and to make the fifth someone else's permanent job. The connectors already exist and are maintained by a team whose only product they are. The evaluation infrastructure already exists. The security posture has already been audited by other buyers.
This is where Leo AI sits. Leo is an AI assistant built for mechanical engineers, trained on more than one million pages of standards, books, and technical articles, and connected to an organization's own knowledge base: PDM, PLM, local and network directories, and ERP. Leo offers integrations with leading PDM and PLM platforms, including SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, and Arena PLM. It operates as an intelligence layer on top of those systems rather than a replacement for them, so the systems of record stay where they are and keep doing their job.
On the two objections that stop most internal builds, the answers are concrete. Leo is SOC-2 certified and GDPR compliant, no AI is trained on customer data, and customer IP is protected. On technical trust, Leo cites the source behind each answer, which is what makes an answer checkable rather than merely fluent.
What you give up is roadmap control, and what you take on is dependency. That is worth managing deliberately rather than pretending it away. Ask where the index lives, whether your data improves the vendor's models, how export works, and what remains yours if you leave. Those questions are the substance of assessing AI lock-in risk in PLM, and a vendor who answers them precisely is telling you something useful about how they will behave in year three.
A decision test you can defend to a CFO
Most build-versus-buy arguments stall because both sides are comparing different things: a prototype against a subscription. These five questions force both options onto the same footing.
Is retrieval over engineering data your product, or support for your product? If it is the product, build. If it is plumbing that makes engineers faster, that is a strong signal to buy.
Can you name the person who owns retrieval quality in 18 months? Not the team. The person. If the answer is a shrug or a name that already owns three other systems, the maintenance line is unfunded.
Do you have a graded evaluation set yet? Between 150 and 300 real engineering questions with known correct answers, drawn from what your team already asks. Without it you cannot measure a vendor or your own work, so build it first regardless of which way you go.
Price the build over 24 months, not one quarter. Fully loaded engineering cost, including connector maintenance, security review, and the evaluation work. Compare against the bought option over the same 24 months, including integration and administration time on your side.
Set the success metric before you start. Time to find a qualified existing part, percentage of answers with a correct citation, or reduction in duplicate part numbers created per quarter. Pick one and instrument it.
One more finding from the NANDA data is worth carrying into this: mid-market organizations moved from pilot to full implementation in roughly 90 days, while large enterprises took nine months or longer. The variable that separated them was decision speed, not technical sophistication. A bounded 90 day pilot with one metric defined up front beats a nine month evaluation, whichever option you end up choosing.
FAQ
Price the build before you start it
See what purpose-built engineering AI does with your own PDM and PLM data
Leo connects to your PDM, PLM, and network directories and answers engineering questions with cited sources from your own data. Book a demo and test it on your parts.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
