There’s a question I tell engineering leaders to ask any AI extraction vendor, and it isn’t about accuracy or price per sheet. Ask them whose drawings their model was trained on.
There are two honest answers, plus a non-answer that comes up more often than either. All three should change how you buy.
“Public data and synthetic examples.” Then the model has never seen your legend, your tag conventions, or the drafting habits of the EPC that built your facility in 1987. I’ve measured what that gap looks like: generic vision models scored 39% on industrial engineering drawings, where a tuned pipeline reached over 93%: same task, same drawings. A vendor whose model starts generic will be learning on your project, and you’ll pay production prices for those lessons.
“Our other clients’ drawings.” Now ask whether yours will join the pile. Your P&IDs describe your process: line sizes, control philosophy, trip settings, and facility layout. Feeding them into a model that also serves your competitors is a trade-secret decision, not a software purchase, and your legal team will treat it as exactly that.
Then there’s the non-answer: “That’s proprietary.” Push on it. Two specific questions usually settle things: do all your customers run on the same model weights, and does our data go into training them? A vendor with clean answers gives them in one sentence. The one who has to loop in the product team, then get back to you, has already answered both questions, just not out loud.
The Problem Nobody Prices In
When you route a P&ID through a cloud extraction API, you send facility blueprints to a third-party server. Export controls, cross-border data access laws, and the confidentiality clauses in your own EPC contracts can each stop that on their own. In my experience, legal kills these projects before engineering ever gets to evaluate accuracy.
A second issue rarely comes up in sales conversations: derivative model weights. A model fine-tuned on Company A’s drawings can encode Company A’s drafting conventions and tag patterns. Whether that ever becomes a real leak depends on the vendor’s training isolation and retention policies, which is exactly why those policies are worth asking about. I have yet to see a vendor raise the topic on their own.
The industry’s default answer to all of this is a platform. Load your drawings into the vendor’s cloud, and the intelligence stays there. For some owners, that’s the right call, because they wanted a document management platform anyway. But many teams need an instrument index, a line list, and an alarm register that their existing systems can import, with sufficient verification to act on the numbers. A multi-year subscription is a strange price to pay for data that came from your own drawings.
Stop Asking How Good the Model Is. Ask How Fast I Can Build Yours.
In Part 4 of this series, I argued that the data is the model, and everything else is a commodity. There’s a conclusion buried in that argument that I kept running into on real projects: if the data is the model, then whoever owns the data should own the model outright, not license it from someone who trained it on who-knows-what.
Ownership settles the legal questions. It raises a practical question, though: custom models have a reputation for taking months, and months kill ROI. That changes what you should be asking a vendor. Not how good their model is, but how fast they can build yours.
I now build data-extraction models this way, and the honest answer to “how fast?” surprised me.
What Building Your Model Actually Looks Like
None of the mechanics is exotic. They’re the data practice from Part 4, applied end to end, and three of them carry most of the weight.
The build starts with choosing what to annotate, because an operator’s drawing set is mostly repetition, and annotating repetition is paying twice. I let the model’s own uncertainty pick the sheets. The ones it finds confusing carry the new information; the ones it breezes through teach it nothing. Published active-learning case studies report labeling reductions of 40-60%, which aligns with my experience.
Extraction itself runs on a pair of models rather than one. A detector proposes every symbol, an independent classifier checks each proposal, and any crop they disagree on goes to a human reviewer instead of being guessed at. In Part 4, I called this disagreement signal the highest-value data in the pipeline. It’s also what keeps review affordable: the system knows when it doesn’t know, so your experts only see the cases that need them.
The corrections those experts make don’t evaporate. Each one lands in a verdict ledger: who verified what, when, and what changed. The ledger feeds the next training round, and it turns out to be the QA trail an auditor would have asked for anyway. I’ve watched engineers spend an afternoon correcting a chat model’s output, only for that effort to disappear by the next morning. Here the same afternoon becomes part of the model.
The Numbers, Measured
I’ll give you two, from my own project logs, because I haven’t seen anyone else publish theirs.
The first time I ran this playbook end-to-end, on roughly 330 drawings for a SAGD producer, it took 16 working days from cold start to delivering a model. That covered nine detector generations, six classifier generations, an expert review loop, and delivery across three facilities.
The second corpus came from a major pipeline operator: 105 scanned sheets of varying quality. That job took 5 working days from receiving the raw PDFs to handing over an evidence-linked dataset, and about seven of those hours were hands-on expert review. I want to be careful about what those five days measured. There was no model training in them. An interim detector proposed the symbols, humans verified every one of them, and what the client received was a verified dataset. No weights changed hands.
So when corpus two ran three times faster than corpus one, none of that speed came from reusing a model. It came from tooling I had already built and mistakes I had already made once: a review interface that had been through one war, rules that catch failure patterns I’d already paid to discover, and the habit of routing disagreements instead of eyeballing every symbol. All of that carries from client to client. Weights don’t, and they can’t, because a vendor whose weights travel between clients is running the exact business model this article told you to interrogate.
Every extracted value in both deliverables links back to the pixels it came from. When an engineer doubts a tag, they click it and see the crop on the original drawing. That’s what lets a reviewer trust the output enough to correct it rather than redo it.
Why the Platforms Won’t Sell You This
Platform economics point away from all of this. A standardized product across thousands of seats, and a cloud strategy that wants your data inside their walls: “we build your model, hand it over, and keep nothing” breaks both halves of that business. I don’t blame them. If I were running a platform company, I’d build it the same way. Some enterprise vendors do offer isolated tenants or on-prem deployments, usually at enterprise price points. If you’re evaluating one, the same questions apply. Ask what happens to the weights and who else benefits from them.
A small specialist can afford the opposite structure. I work with one client at a time, and their data never mixes with anyone else’s. The tooling improves with every engagement while the models stay put. In the procurement conversations I’ve been part of, the sticking points were ownership, retention, and where the data goes, and almost never accuracy. A per-client model answers the questions that actually stall a purchase order.
The Question Cuts Both Ways
You should ask me the same thing, so here’s my answer. Your model starts from a base built on data I own outright, learns only from your drawings, and belongs to you when we’re done. Ownership covers the verified dataset and the evidence ledger behind every value, the model weights trained from them, and an offline runtime that works air-gapped on your side of the fence. The dataset outlives any model generation. This is a handover, not a license, and if you walk away, the model goes with you.
Whether you talk to me or not, ask your current vendor whose drawings trained their model, and comment with the answer you get. The replies will be more educational than this article.
And if you have a drawing backlog and a deadline, a DCS migration, an alarm rationalization, a records request: I run a free proof. Send five representative P&IDs and get back an evidence-linked interactive dataset within 48 hours. Details at royabes.com/services/pid-extraction.
Industrial AI Series
- I’ve Trained AI on Engineering Drawings. The Model Was Never the Hard Part.
- You’re Buying AI Like Software. That’s Why It’s Failing.
- Your AI Model Works. Your Organization Doesn’t.
- Your Data Is the Model. Everything Else Is a Commodity.
- The $31.5 Billion Walk-Out: Your Best AI Training Data Is About to Retire
- Build, Buy, or Die: The AI Decision That Will Define Your Next Five Years
- Whose Drawings Trained Your Model? (you are here)