Large Language Models for RFI Response Drafting in Construction Projects
LLMs cut RFI response time by 60% when grounded in project documents, not general training data.
Data center construction spending in a major national market hit an annualized rate of $40 billion as of June 2025, up 30% year-over-year, on top of a 50% surge in 2024. Every dollar of that is running through an RFI process that was already slow before the boom started. This piece looks at where large language models actually help that process, where they don't, and why the document environment underneath the model produces most of the results attributed to the model itself.
What RFI workflows cost project teams today
ConstructConnect tracking shows nearly 100 projects worth more than $101 billion sitting in preconstruction with anticipated 2026 start dates, and that figure excludes the separately monitored $100 billion Project Kestrel. That's a lot of concurrent work competing for the same estimators, superintendents, and project engineers. Schedules are compressing. Staff are not multiplying to match.
Against that backdrop, the average RFI takes 9.7 days to get a response. A typical project generates 9.9 RFIs. When that scales up to a data center job with hundreds of RFIs in flight, the queue turns into a genuine bottleneck, not a paperwork inconvenience.
Part of the problem is sheer volume of paper. A typical commercial project produces more than 10,000 documents. Finding the right spec section isn't the hard part on any single search, it's navigating a document environment too large for any one person to hold in their head, across drawings, submittals, change orders, and meeting minutes that all reference each other in ways nobody wrote down clearly.
Construction professionals spend 35% of their working hours on non-optimal activities, a significant portion of which involves information and document management. This is structural. It happens on well-run jobs with good superintendents just as often as on troubled ones, because the volume of documentation outpaces any manual filing system. Research on construction workflows has put a number on it: construction professionals lose roughly 5.5 hours a week hunting for project information alone. These are senior, expensive people, and their time is going to search, not judgment.
What an LLM does in an RFI response workflow, and what it does not
Stripped of the hype, an LLM does three things well: it reads, it writes, and it reviews text against other text. Applied to RFIs, that means drafting a structured response from source documents, checking a submittal against spec requirements and flagging what's missing, and pulling relevant facts out of a document set too large to read end to end.
The workflow, when it's built correctly, takes this shape. An RFI comes in. The model classifies it by discipline, urgency, and likely downstream impact. Semantic retrieval goes and finds the relevant spec sections, drawing details, prior RFIs, and submittals tied to that question. The model drafts a response with citations back to those sources. A human reviewer approves it or kicks it up the chain.
That last step doesn't go away, and it shouldn't. What changes is where the project manager's hour goes. Instead of spending an hour researching the answer and drafting language from scratch, the PM spends roughly ten minutes reviewing a draft that's already accurate. The judgment stays with the person. The blank-page work and the manual digging get handed off.
On projects running 200 or more RFIs, teams using LLM-assisted drafting have reported cutting response preparation time by 60 to 70%. Those gains are largest on routine, spec-reference RFIs, the kind where the answer already exists somewhere in the document set and just needs to be found and cited. Complex technical RFIs, the ones involving actual design trade-offs, see smaller gains, because those still require engineering judgment no model should be making unsupervised.
Why generic LLMs fail on project-specific RFIs, the document-grounding problem
A generic LLM, the kind trained on public text and nothing else, doesn't have access to a given project's documents. It has no idea what's in this spec, this drawing set, this change order history. So when it drafts an RFI response, it is answering from pattern-matching against similar-sounding language it saw somewhere in training, not from project knowledge. It's answering from pattern-matching against similar-sounding language it saw somewhere in training. That's a fundamentally different thing, and it doesn't hold up.
AI output is only as reliable as the records feeding it. When it is fed partial or stale inputs, the output looks complete, reads confidently, and is quietly wrong. That's a worse failure mode than a slow manual process, because a slow process announces itself. A confidently wrong RFI response doesn't.
Picture the specific ways this breaks. A response cites a spec version that's since been superseded by a change order nobody fed into the model. Or it misses a drawing revision entirely, answering against an earlier revision when the field is already working off a later one. Or it answers a question that a prior RFI already resolved three months earlier, contradicting the record instead of matching it. Each of these looks fine on the page. Each one costs real money when someone builds off it.
The fix is retrieval-augmented generation, RAG, run against the live project document stack rather than general training data. Under RAG, the model answers from retrieval, not from what it "knows." It's running semantic retrieval across drawings, specs, submittals, prior RFIs, and meeting minutes for that specific project, pulling the actual current documents, and drafting against those. Grounding is the whole game here. Without it, the rest of the workflow is theater.
What separates a drafting tool from a governed RFI workflow
A model that drafts fast is not the same as a workflow that's safe to run at scale. The comparison comes down to six things: retrieval quality, role-based access, workflow orchestration, source citation, approval controls, and integration with the systems of record already running the project. Missing any of those turns speed into a liability instead of an asset.
AI and rules aren't interchangeable, and treating them that way is where a lot of implementations go wrong. AI belongs where language and flexibility matter: drafting a response, summarizing a document, classifying an incoming RFI by discipline. Deterministic rules belong where precision and compliance are non-negotiable: escalation triggers, confidence thresholds, approval routing based on role and risk. A model should never be the one deciding whether an issue is serious enough to escalate. A policy rule decides that, every time, the same way, regardless of how the model happens to phrase its draft that day.
Escalation logic works like a gate. If an RFI touches contractual terms, safety, design liability, or cost, the system routes it automatically to a designated approver, no exceptions, no judgment call left to the model. That's what makes the AI safe to deploy in the first place, not a limitation on its usefulness. It's what makes the AI safe to deploy in the first place.
Source citation isn't optional polish, either. Every draft response ought to carry a citation back to the specific document, section, and revision it pulled from. That's the traceability layer, and it's what turns a fast draft into a defensible one, the kind a reviewer can actually check in thirty seconds instead of re-deriving from scratch.
What current platforms offer
Judge a platform against the criteria the last section laid out, not against a marketing slide. Grounding responses in the actual project document stack is another question it needs to answer. Does it enforce governance rules around escalation and approval? Does it cite sources? Does it talk to the systems of record already in use on the job? Those four questions determine how a platform actually performs, more than any feature list does.
Procore Assist, previously branded Copilot, works as an AI assistant that answers project questions directly from a project's own data set and flags open items. Its usefulness scales with how much of the project's data actually lives inside Procore's system, since the assistant can only ground answers in what it can see.
Autodesk Construction Cloud has built AI capabilities across its suite, targeting document-heavy workflows and construction project management tasks. Across the industry, document management and RFI processing have emerged as among the highest-impact AI applications currently running in production, ahead of flashier use cases.
Trunk Tools launched its Cortex intelligence layer in June 2026, aimed specifically at RFI drafting and impact assessment. Cortex flags roughly 20% of incoming RFIs as questions already answered somewhere else in the project record, helping teams avoid unnecessary review cycles for those items. That's a fifth of the RFI queue that shouldn't have needed a human in the first place, on the projects where that number holds.
Why the document environment has to be solved before the AI is deployed
The model was never the bottleneck. The document environment underneath it is. A well-built model pointed at a fragmented, siloed document stack doesn't fail loudly, it fails quietly, producing wrong answers faster and with more apparent confidence than a human would.
Data center projects have a particular version of this problem. The same underlying information, rack layouts, power models, cooling specs, cable schedules, gets rebuilt manually across multiple documents and systems that don't talk to each other. Moving one rack means that change has to be hand-carried into every one of those documents separately. An RFI response touching any of that is only as good as the most current version the model happens to have access to, and if one system is behind on revisions, nobody finds out until something doesn't fit in the field.
That's the argument for connected data architecture as a prerequisite, not a nice-to-have layered in later. Cost entries need to talk to document control. Field reports and RFI logs need a live connection to the schedule. Change order history needs to feed directly into whatever the model retrieves from, so an old drawing never gets treated as current. Without this step, the AI works from fragments no matter how good the underlying model is.
Get the document environment right, though, and the payoff extends well past faster drafting. Every RFI answer can trace back to its exact source document and revision. Prior RFIs that already resolved a question get flagged automatically instead of re-litigated. And the audit trail that traceability builds doesn't stop at construction close-out, it carries forward into commissioning and operations, where the next several years of a facility's life depend on getting that record right the first time.
