Why don't construction AI pilots scale?

A lot of construction AI pilots don’t fail. They just never leave the desk of the person who started them.

You know the pattern. One PM uses ChatGPT to clean up owner emails. An APM built a folder of prompts on her personal account, and half the office borrows them. IT turned on Copilot and sent one email about it. Procore keeps adding AI features. Leadership asks about “the AI plan” in every meeting. And a year later the P&L looks exactly like it did before.

Nobody did anything wrong here. That’s what makes it frustrating.

What is a pilot, really?

A pilot is a mockup.

Most commercial jobs with a serious envelope have one. The crew builds a section of the exterior wall out in the laydown yard. Brick, window, flashing, sealant joint, the whole assembly. The architect walks it, the owner’s rep takes photos, everybody argues about the mortar color, and eventually somebody signs off.

The mockup is genuinely useful. It proves the detail works. It sets the standard.

But nobody on that job thinks the mockup is the building. The mockup was built by your best mason, with the super watching, with all the time in the world. It doesn’t tell you whether the regular crew can lay up every elevation on the building, on schedule, in February. That’s a different problem, and it needs a different plan: sequencing, crew size, material deliveries, inspections, who checks the work.

AI pilots are mockups. Your sharpest APM, babysitting a tool, on a workflow she personally cares about, proves AI can draft a submittal register. Great. It doesn’t prove the register gets drafted on every job by people who never asked for the tool. Nobody planned the install.

Why don’t construction AI pilots scale?

Four things stop them. A stalled pilot often has more than one.

1. Nobody owns it

The pilot belongs to whoever started it. The rollout belongs to nobody.

In a poll of Tyler Campbell’s LinkedIn audience (n=72), 24% said a dedicated tech leader owns technology decisions at their company. 47% said “the leadership team.” 11% said nobody, that it’s reactive.

My read: “the leadership team” is a polite way of saying everybody can veto it and nobody has to push it. AI spreading across a company is a project. Projects without a PM don’t get built. You’d never run a job that way.

At FieldProof we call the space between departments the Ownership Gap Model. AI rollouts fall right into it, because they touch precon, operations, accounting, and IT at once, and none of them owns the seams.

2. It sits on a broken process

AI on top of a broken process just makes a faster mess.

If your submittal process is “every PM does it their own way,” an AI submittal workflow has to pick one of those ways. Whichever one it picks, the other PMs won’t use it. If your change order backup lives in a foreman’s camera roll and a “yeah, go ahead” in the hallway, AI can’t assemble backup that doesn’t exist.

The pilot works because the person running it has a clean process in her head. The company doesn’t. So the order matters: fix the process, then build the foundation, then automate. That’s the Sequencing Principle, and I’d bet skipping the first step is the most common way good AI work dies.

3. There’s nothing under it

A pilot usually runs on one person’s account, reading documents that person dragged into a chat window. That’s fine for a mockup. It’s not a foundation.

To spread, AI needs company accounts with rules about what data goes in. It needs access to the actual project data: the spec book, the RFI log, the submittal register, the job cost report. And your job doesn’t live in one place. It lives in Procore, your accounting system, Outlook, Bluebeam, a file share, and a group text with the super and the foremen.

Every vendor’s AI only sees its own system. Somebody has to decide what connects to what, and what never leaves the building. That’s the work of connecting it to the systems you already run, and it’s the least exciting part of this whole thing. It’s also why the second team can go faster than the first.

Note: none of this means you need a giant data project before you start. It means the first workflow should be built on the foundation the second one will use, even if that foundation starts small.

4. Nobody put a number on it

When the pilot ends, somebody asks whether it was worth it. If nobody measured the before, the honest answer is “people seem to like it.” That doesn’t win budget.

In a separate poll of Tyler Campbell’s LinkedIn audience (n=65), 31% said the biggest barrier to fixing their tech was that it’s hard to prove the ROI. Another 37% said there’s no time to fix it.

My read: those two answers feed each other. No number means no priority. No priority means no time. A pilot without a dollar figure is competing for budget against a new skid steer, and the skid steer has a dollar figure.

What does a first workflow that scales look like?

A first workflow that scales is planned like an install, not a mockup. It’s picked because it repeats on every job, measured before anybody builds it, built on company accounts and company data, and handed to a named owner with a written standard.

In practice, that looks like this:

1. Pick a workflow that happens on every job or every month. Pay apps, submittal registers, daily reports, change order backup. Not the cool demo. The boring one that repeats.
2. Measure it as it runs today. Hours, people, how often. Put a number on it.
3. Fix the process first. Pick the one way your company does it, and write it down.
4. Build it on company accounts, reading company data, with a person reviewing everything before it goes out.
5. Name an owner who isn’t the person who built it.
6. Train the next team. Then measure again.

Step 6 is where most plans run out of pages. Getting your people actually using it is its own job, and it’s the one a lot of firms skip. Two people figuring it out on their own isn’t adoption. It’s two people. Training the team is how the install crew learns the detail the mockup crew already knows.

Should contractors stop running AI pilots?

Yes. Or at least stop calling them that.

“Pilot” tells everybody it’s temporary. It gives the PMs permission to wait it out, and it gives leadership permission to never decide. Call it your first workflow instead, and plan the second one before the first one ships. If you want help with the first one, a Workflow Sprint maps it end to end, builds a working prototype, and shows what it’s worth in hours before the full build.

Build the mockup. Absolutely. Just don’t stand in the laydown yard admiring it while the building waits.

Sources

• Poll of Tyler Campbell’s LinkedIn audience, n=72, Q1 2026: who owns technology decisions.
• Poll of Tyler Campbell’s LinkedIn audience, n=65, Q1 2026: biggest barrier to optimizing your tech stack.
• Full results, method, and sample sizes: Construction tech stack poll results.