I Tested AI Tools on Real Construction RFPs. Here Is What I Found.

I took a set of real public construction RFPs. The kind a trade contractor would actually bid on. Plumbing work for a school district. HVAC for a municipal building. Electrical for a transit agency. Documents between 40 and 120 pages.

For each one, I asked ChatGPT to identify the high-risk clauses: liquidated damages rates, prevailing wage requirements, insurance limits, pay-when-paid language, notice requirements. Then I compared what it found against a line-by-line review of each document.

I ran the same documents through a purpose-built extraction engine designed specifically for construction RFPs. Same test. Same ground truth.

On documents with clear, prominent language, ChatGPT performed well. When a liquidated damages clause appeared in a section labeled 'Liquidated Damages' with a clear dollar figure, it found it.

Scope summaries were generally accurate. Deadlines that appeared in a formatted table were extracted correctly. The model is genuinely capable when the information is well-organized and the terminology is standard.

If you have a simple RFP and you just need a quick read of the obvious content, a general AI assistant does that reasonably well.

The problems started on documents where the important language was buried, labeled unexpectedly, or written in the kind of dense legalese that public procurement lawyers prefer.

A prevailing wage requirement embedded in a Section 00800 Special Conditions with a cross-reference to an attached federal wage determination was missed entirely on two of the five documents. ChatGPT summarized those documents as having standard labor requirements.

A pay-if-paid clause written as 'Contractor's obligation to pay Subcontractor is expressly contingent upon and subject to receipt by Contractor of payment from Owner' was paraphrased back as 'payment will be made upon receipt.' The key risk transfer was lost in the summary: the sub might not get paid at all.

On one document, ChatGPT identified a liquidated damages rate that did not exist in the document. It generated a number that was plausible for the project type. When I asked where it found it, the response explained the clause in confident detail, referencing a section of the document that contained no such clause.

General AI tools are trained to be helpful and fluent. When they do not find something, they often produce a confident-sounding response anyway. This is useful when you are brainstorming or drafting. It is dangerous when you are relying on the output to make a bid decision.

A summary that says 'no liquidated damages clause found' when there is one means you priced the job without accounting for the exposure. A summary that invents a clause that does not exist means you may spend time chasing a risk that is not there.

Both failure modes look the same in the output: a confident, well-written sentence. There is nothing in a general AI response that tells you whether the finding is real or generated.

The issue is not that the underlying models are bad. They are not. The issue is what the task actually requires.

Reading a construction RFP for risk is not the same as reading a document for comprehension. It requires knowing specifically what to look for, recognizing the same concept across dozens of different phrasings, and, critically, being able to point to the exact text in the source document that supports each finding.

General AI tools are optimized to produce useful responses. A purpose-built extraction engine is optimized for something different: it either finds the verbatim language in the document or it reports that the clause was not found. There is no middle ground where it generates a plausible-sounding summary.

The engine built into BidTerms requires every finding to be backed by a direct quote from the source document. If it cannot produce a verbatim excerpt, the finding is dropped. This is the constraint that eliminates hallucination. It also means the engine will sometimes miss things a skilled human reviewer would catch. But it will not invent things that are not there.

Construction RFPs have specific vocabulary that carries specific legal meaning. 'Condition precedent' means something precise in a payment clause. 'Substantial completion' triggers specific rights and obligations. 'Sealed envelope' in a submission requirement means something different than an online portal submission, and the distinction matters for whether a sealed-envelope red flag fires.

A general AI tool sees these phrases and produces a reasonable summary of what they mean in plain English. A purpose-built engine knows which phrases trigger which risk categories and has been calibrated on real construction documents to recognize the variants.

The difference between 'pay when paid' and 'pay if paid' is one word. The legal difference between them is whether you get paid at all. Calibration on that specific distinction, across the range of phrasings used in real contracts, is something you build through iteration on real documents, not something that comes out of a general model by default.

For quick, low-stakes reading, a general AI tool is fine. If you want to understand the general shape of a project before deciding whether to spend estimating time on it, ChatGPT will give you a useful summary.

For the clauses that actually determine whether a job makes or loses money, the output needs to be grounded in the document. You need to see the exact language, know where it came from, and have confidence that what the tool did not find is not just something the model decided to skip.

The test I ran did not find a general AI tool that consistently met that standard on construction documents. The gap was not in the sophistication of the model. It was in what the tool was designed to do.