AI for manufacturing: document AI and product assistants

Where does AI help in manufacturing and industrial work?

Where skilled people spend their time copying information from one format into another. Engineering drawings, parts lists, bills of quantities, datasheets and certificates arrive as PDFs, scans and CAD files; ERP systems need clean, validated records. The gap between the two is usually filled by engineers typing. That is slow, it is expensive, and a single wrong field can create a bad record that spreads through procurement.

Language models are now good at reading those documents, including tables, callouts and scanned pages. They are not good enough to be trusted blindly. The systems Mirai Minds builds for industrial clients pair a model that does the reading with a person who signs off, and with validation rules that stop impossible values before anyone has to catch them.

How does document AI handle engineering drawings?

For an Indian public-sector refinery, we built a system that reads equipment drawings and produces SAP-ready material-master data. An engineer uploads a drawing of up to 500 MB. Gemini finds the bill-of-materials table and extracts every row, plus the drawing number, item numbers and maker. Roughly 200 lines of engineering rules steer the extraction: keep the reading order, never drop a row, preserve gaps in part numbering, and shorten component names with a dictionary so text fits SAP's length limits.

Two details matter on real drawings. When the parts list omits a part number, the model reads the numbered callouts on the drawing itself. And the cost is controlled with two tiers: a fast Gemini model does the first pass on every drawing, and the premium model runs only when a reviewer asks, with a plain-English hint such as "the quantity column is on the right".

Why keep an engineer in the loop?

Because the output feeds procurement, and procurement trusts it. In the refinery system a reviewer sees the drawing beside the extracted table, edits only the fields that are wrong, and can re-run extraction with a hint instead of retyping. Cascading validation encodes about 370 SAP picklist values: choosing a material type narrows valuation class to the legal values, so impossible combinations can't be entered at all. Nothing is exported until a person signs off, and the export is the exact 16-column upload sheet the SAP team loads.

Review is also where accuracy data comes from. Every correction says which field the model got wrong. Logged per field, those corrections show where review can safely shrink, and where it can't.

What about catalogs and customers?

Manufacturers also sell, and their catalogs are often hard to search. For a resin manufacturer in India we built a pilot catalog assistant: shoppers ask in plain language or upload a photo, an agent decides whether to search the catalog, and product cards appear only from real search results. Hybrid semantic and keyword ranking keeps search working even if embeddings fail. The pilot runs on a 15-product sample, which is enough to test behavior and not yet enough to measure retrieval quality.

What do we need to start?

Twenty to fifty representative documents, including the messy ones, the target format (for example your SAP upload sheet or the fields your quality system needs), and a domain expert who can answer "is this right?" questions for about an hour a week. We turn those into a test set before building, so every later change can be measured against it.

What does it cost to run?

Mostly model usage per document: pages and images in, structured text out, multiplied by retries and premium re-runs. Hosting is small for hosted models and larger if open-weight models run on your own GPUs. We estimate both on your sample documents before launch. Build cost depends on the review tooling, the validation rules and the ERP integration. For the technology behind this work, see custom LLM and document AI and computer vision.