What I learned building an AI-powered document analysis tool for industrial procurement
While researching how AI could solve real problems in traditional industries, I came across an interesting sector: industrial equipment procurement. EPC contractors and equipment vendors deal with hundreds of RFQ documents annually — each one containing complex technical specifications, engineering standards, and compliance requirements buried in 30-100 page PDFs.
I wanted to understand the problem deeply, so I spent a few days building a focused prototype: an AI-powered deviation analysis tool for industrial equipment RFQs.
Here’s what I learned — both technically and strategically.
When a valve manufacturer receives an RFQ from an EPC contractor, they need to:
Today this is done manually. An experienced engineer spends 2-4 hours per RFQ, with a high error rate on complex specifications. Missed deviations mean lost money or lost bids. One overlooked NACE compliance requirement can mean quoting the wrong materials, delivery delays with penalty clauses, or — worst case — safety issues and liability exposure.
The cost of a single error often exceeds the annual cost of software that could have caught it.
An open-source prototype that analyzes RFQ documents and identifies specification deviations from standard product offerings, running entirely on local AI.
The processing flow is straightforward:
A key design choice: 100% local inference using Ollama. Documents never leave the user’s machine. Zero marginal cost per analysis. Works completely offline. For sensitive industrial documents containing proprietary specifications, this tradeoff matters.
| Parameter | RFQ Requirement | Standard Spec | Deviation | Severity |
|---|---|---|---|---|
| Pressure Rating | PN63 | PN40 | Upgrade Required | Major |
| Material | CF8M (ASTM A351) | CF8M | Match | — |
| Test Standard | API 598 | API 598 | Match | — |
| Fire Safe | API 607 | Not Standard | Addition Required | Major |
RFQ specifications live in tables, but PDFs don’t preserve structure well. The prototype uses PyMuPDF, which handles machine-generated PDFs adequately but struggles with merged cells, complex layouts, and multi-column formats. Scanned documents fail entirely without OCR.
AI-powered extraction (like GPT-4 Vision) can achieve near-perfect results on hard cases, but at $0.50-$2.00 per document versus $0.00 for the local approach. For high-value RFQs worth $100K+, that cost is trivial. For bulk screening, it adds up fast. This isn’t just a technical decision — it’s a product decision about where accuracy matters most.
More detailed LLM prompts yield higher accuracy but slower processing. The right balance depends on context: for $5M bids, engineers want maximum accuracy. For initial screening of 50 RFQs to prioritize the top 10, speed and cost matter more. A production system should offer both modes.
Engineers won’t trust “AI says NACE required.” They need to see where it’s stated — the page number, the section, the exact text. Maintaining source metadata through the processing pipeline added complexity but proved essential. Without it, users verify everything manually and the tool provides no time savings.
| Consideration | Local (Ollama) | Cloud APIs |
|---|---|---|
| Cost per document | $0 | $0.10–$0.50 |
| Privacy | Documents stay on your machine | Sent to third-party servers |
| Offline use | Full functionality | Requires connectivity |
| Setup effort | Install Ollama + download model (5-40GB) | API key only |
| Quality ceiling | Approaching but not exceeding frontier models | Highest available accuracy |
For industrial RFQ analysis with proprietary documents, privacy and zero marginal cost often outweigh the quality gap. But this is ultimately a business decision, not a technical one. A production system should probably support both — local inference for routine analysis, cloud APIs for critical high-value bids where maximum accuracy justifies the cost.
My initial hypothesis was “save proposal teams 30% of their time.” The actual insight is different: missing one deviation can cost more than a year of software. The reframe is important — from “process RFQs faster” to “catch what you’d miss.” Proposal teams under pressure make mistakes. AI doesn’t get tired or rushed. One prevented error means positive ROI.
This has pricing implications too. Value-based pricing tied to bid size may make more sense than per-document or per-seat models.
AI needs historical data — past proposals, product specs, customer preferences — to work well. But new customers don’t have digitized archives. Realistically, a system like this takes 3-6 months to become truly valuable as it builds a useful library of specs and learns from outcomes.
Pre-loading industry templates (API standards, common specifications) can provide immediate value and bridge the gap, but the cold start problem explains why validation periods for this kind of tool need to be measured in months, not weeks.
To be truly valuable, a deviation analysis tool needs to connect to ERP systems for product specs and pricing, CRM for customer history, document management for templates, and email for receiving RFQs. An early-stage product can’t build 50 custom integrations — the strategy has to be: focus on 3 universal integrations, offer an API for everything else, and partner with ERP consultants for complex cases.
Generic RFP tools struggle with engineering standards (ASME, API, NACE), technical specifications (pressure ratings, materials), and complex datasheets. Building AI-native for a narrow vertical like industrial equipment creates defensible positioning that horizontal tools retrofitting AI can’t easily replicate.
This is an MVP that demonstrates core concepts. A few things worth noting:
These aren’t minor gaps — they’re fundamental requirements for production use. But the prototype successfully proves that local LLMs can extract structured data from technical documents, that the privacy/cost tradeoff of local inference works for this use case, and that the core deviation detection logic produces useful results.
The prototype is open-source. If you have Python 3.11+ and can install Ollama, you can be running your first analysis in about 15 minutes.
ollama pull llama3.3:latest)streamlit run src/ui/app.pyFull installation instructions are in the README.
A few days of building taught me more than I expected about this sector and about B2B AI in general.
Technically, working with LLMs requires thinking about accuracy, cost, and speed tradeoffs as product decisions — not just engineering problems.
Strategically (but not validated), in B2B the real value may not be in what you initially think. Time savings sound good in a pitch, but risk reduction may guide buying decisions.
About the sector, I understand why industrial procurement can result resistant to digitization — the workflows are intricate, the compliance requirements vary by geography and application, and one mistake can have real consequences. That complexity is also where AI could add the most value.
If you’re working on AI for B2B or industrial workflows or even public sector processes, I’d love to connect.
Interested in future projects? Join a small list to hear about new explorations.
Built by Alessio Fiorentino · GitHub · Report an Issue