AI in Construction Management: What’s Actually Useful (and What’s Hype)

I’ve been hearing a lot of skepticism about AI in the construction industry lately. And honestly? I get it.

If you’ve ever asked a generic AI tool to review a set of plans, or help you respond to a contractor claim without giving it any context, you probably got something that looked vaguely right but was actually kind of useless. Maybe confidently wrong? That’s a real experience, and it’s earned some of the skepticism I’m hearing.

But I don’t think the problem is AI. I think the problem is setup.

The Smartest Person in the Room Who Knows Nothing About Your Job

Here’s the analogy I keep coming back to:

Imagine you could hire the smartest person in the world as your assistant,

✅Encyclopedic knowledge

✅Instant recall

✅Able to synthesize hundreds of pages in seconds

One catch — they know absolutely nothing about what you do, who you work for, or how your industry operates.

That’s AI right now. The capability is real. The gap is context.

And there’s a specific context problem for those of us on the owner and construction management side of public works projects that I'm not hearing being talked about enough: AI defaults to contractor-brain.

When you ask a generic AI tool about "construction costs", it thinks cost-to-build — labor, materials, equipment. When you mention "schedule", it wants to help you build a CPM. When you talk about "progress", it’s thinking field production.

But that’s not our world.

Our world is:

• Costs measured in bid items and pay requests, in relation to the contract.

• Schedule means contract time — reviewing the contractor’s schedule, tracking working days, not authoring a critical path ourselves.

• Progress means contract compliance, quality oversight, risk management. We’re managing the contract, not the work.

If the AI doesn’t understand that distinction going in, everything it produces is subtly off — and it’s the kind of off that’s hard to put your finger on but immediately obvious to anyone who has actually stood on a public works job site.

📣So before you ask for anything, you have to tell it who you are.

74Where AI is Actually Useful: Three Real Examples

1. Making Sense of a Document Pile

One of the places I’ve found AI genuinely valuable is pulling together multiple complex documents and finding where they don’t agree.

Think about what you’re working with on a public works project that has environmental requirements: you’ve got the specifications, multiple permit documents from different regulatory agencies, and probably a mitigation monitoring matrix or appendix. Each one has requirements. Some have dates attached. Some are redundant. Some conflict. And often, ownership of a specific requirement isn’t clearly assigned — is that the contractor’s scope, or ours?

Going through those manually is hours of work, and the risk of missing something is real.

With AI, you can upload those documents and ask it to: summarize the environmental requirements, flag any conflicting dates or requirements between documents, and identify any requirements where the responsible party is unclear. In a fraction of the time, you have a working list of the inconsistencies you need to resolve — and you’ve already done the synthesis work before a problem surfaces in the field.

The key is giving it the actual documents and asking specific questions. “Tell me about the environmental requirements on this project” is okay. “Here are four documents. Identify every instance where the requirements conflict or where the responsible party is ambiguous” is much better.

2. Generating Your Weekly Report (and Why the Example Matters)

Weekly reports are the perfect use case for AI assistance — and also the perfect example of how a bad prompt produces useless output.

⛔Bad prompt: "Write me a weekly construction report".

What you get is something generic, probably organized the way a contractor would organize it, with language that sounds like someone managing the work rather than someone managing the contract.

✅Better prompt: Here’s an example of the format and tone I use. "Here are this week’s daily reports. Generate a draft weekly report that follows my format". ** Note: I’m a construction manager on the owner side — I’m not directing the work, I’m overseeing the contract. I'm avoiding language that puts me in charge of field production decisions.

❗That last instruction matters more than most people realize. If you don’t tell the AI whose perspective it’s writing from, it will default to contractor-brain. Your weekly report will suddenly have you “directing crews” and making production decisions you have no business making — and that kind of language in an official project document can create problems you really don’t need.

The example report is the most important input. Give it your format, your tone, your level of detail. The AI is pattern-matching to what you show it. Show it something good.

3. Working Through a Claim — One Issue at a Time

This is the one I find most valuable, and also the one most people get completely wrong.

When a claim comes in — especially one with multiple issues bundled together — the instinct is to hand the AI everything and say: Here’s the claim. Here’s the contract. Write me a response".

Don’t do that. You’ll get something that sounds like a response, covers the issues at a surface level, and misses the actual argumentation that matters. The AI hasn’t done the work. It’s just produced words.

Here’s a better approach, and the one I actually use:

✅Step one: Verify what it can see. Literally ask: "What documents do you have access to in this conversation?" AI tools can sometimes miss an attachment, or partially process a document. Confirm it before you rely on it.

✅Step two: Verify what it understands. Ask it to demonstrate comprehension before you ask it to produce anything. "Based on the contract documents I’ve provided, what specification sections apply to this issue? What RFIs have been submitted that relate to this condition?" If its answers are wrong or incomplete, fix that before you move forward.

✅Step three: Workshop one issue at a time. Don’t tackle the whole claim at once. Pick the first issue. Ask the AI: "What do we know from the documentation about this issue? What would we need to know that we don’t have in front of us? What would strengthen our position on this point?"

This is where it gets genuinely useful — it will often surface information gaps you hadn’t thought of, or flag documentation you haven’t pulled yet. You’re not asking it to write a letter. You’re using it to think through your position before you commit anything to paper.

Then, and only then, do you ask for a draft response on that single issue.

From there, you move to the next one.

It’s slower than dumping everything in and hitting go, BUT it’s also about ten times more useful.

What This Takes

None of this is magic. It requires knowing what you want, giving the AI the right materials to work with, and not skipping the verification steps. You still have to read what it produces and catch what it gets wrong. It’s not a shortcut. It’s a force multiplier — if you know how to use it.

The good news is that the skills compound quickly. Once you’ve done this a few times — once you’ve trained yourself to frame who you are, what documents matter, and what you’re actually trying to accomplish — the setup becomes second nature.

Where Is This Going?

What I’ve described above still requires you to do the setup work every time:

• Uploading documents

• Establishing context,

• Framing the prompts correctly

We know this approach works, and it’s worth developing the skill regardless.

But it’s also the problem we set out to solve with BridgeDoc InSite. The idea behind it is that your project documents are already there, the system already understands the owner/CM context, and the prompting is built into the workflow. Essentially, you avoid having to start from scratch every time — the setup has already been done. The AI assistance is embedded in the work, not bolted on top of it.

And, yes, we’re still building it, but the use cases above are exactly what it’s designed for.

In the meantime — if you’re not experimenting with this yet, start small. Pick one of these three scenarios. Give it the right context. See what you get.

And remember: The tool isn’t the problem. It's the setup.

Kelly Wheeler is a PE and QSD with 25 years of experience in construction management for public agencies. She is the founder and CEO of BridgeDoc, a construction management software company built for public works CM teams.

Book your FREE demo with me HERE!