Most construction firms are already using AI. Far fewer can point to the value it is delivering. The gap is rarely the technology. It is the data, the culture and the business case behind it.
That was the premise of the panel I moderated on September 29 in Boston at the AI & Data Transformation in Construction Summit. Joining me were Jeffrey Picoraro of Consigli Construction, Danielle O'Connell of Skanska USA, Luke Reeve of TwinKnowledge and Jeff Danley of Burns & McDonnell. The conversation kept returning to one point I made near the end: after 30 years in technology, the technology is the easy part. The hard part is communicating it.
The stakes are concrete. According to FMI and PlanGrid's Construction Disconnected research, 35% of an average week, more than 14 hours, goes to looking for project information, resolving conflicts and rework. In the US, that adds up to $177 billion a year in labor spent on non-productive activity, including $31.3 billion in rework caused by poor project data and miscommunication.
For twenty-five years, construction has mostly bought software and lived with the gaps between the systems. That no longer has to be the case. The data layer, the workflows and the AI on top of them are now things a contractor can build for itself, on its own data. Much of the panel's conversation was about what it takes to get there.
Jeff Danley described data as the rocket fuel of an AI ecosystem. Without it, the productivity gains stay limited. At Burns & McDonnell, 11 global practices grew independently, each with its own data. Their response is an enterprise AI data strategy, with a data ontology that maps information across the organization.
Jeffrey Picoraro was candid about the industry context. Construction is one of the most siloed industries there is, and for some contractors, keeping information close is part of the nature of the work. Danielle O'Connell added that AI opens a new opportunity for transparency, but only when people understand what is in it for them. Collaboration follows when the value is explicit.
I pushed on a pattern I see often: asking people to enter more data as part of a process. No one wants to do it, because the payoff is not immediate.
Large language models change that equation, because they can synthesize data from almost any text. In our software development work at Forte Group, we capture requirements from recorded conversations, then kick off agents that create tickets, eventually code and eventually deployments. No one takes notes. When I asked the room how many organizations routinely record and transcribe meetings, not every hand went up. I see that as an opportunity.
How do you show a fast return? Please, not by handing everyone a copilot. Jeff Danley argued that any technology has to solve a human problem first. His framework is a Venn diagram of corporate goals, technology trends and industry trends such as labor shortages or supply chain issues. Ideas that touch all three tend to create value.
Luke Reeve focused on people. The key is a champion user with enough pain to justify the extra effort. He described one user who tested his platform on nights and weekends because the problem she faced was that significant.
Small wins matter regardless of company size. With small and medium-sized businesses, we have started with an AI tool for salespeople, because it ties directly to revenue and helps fund larger modernization efforts. One panelist described a safety assistant that began as a way to get people into the EHS manual and is now used daily to develop site safety plans. At Consigli, Jeffrey Picoraro explained, every initiative is tested against one question: does this help the people putting the work in place?
In software, we build failure into the process. When you build buildings, that is much harder. So I asked the panel whether AI initiatives can fail and still build momentum.
Luke Reeve estimated that deploying AI is roughly half technical work and half change management. Jeff Danley shared a concrete example. An early agent for evaluating RFPs was an immediate success, so more teams were onboarded, with all of their training data flowing into the same database. When the third team joined, the first team reported that the output had collapsed. The data was polluting across teams. Because the failure surfaced quickly, the fix was simple: each team received its own containerized deployment. The lesson is to take risks where the stakes are low, never with client deliverables or work in the field.
What we call shadow IT is a real concern. It is too easy to build with consumer AI tools outside any organizational control. Jeff Danley offered the sharpest example of the session. In regional office after regional office, someone had built a custom GPT to perform contract risk analysis, because no corporate-approved agent existed. The result was 30 different interpretations of risk. Not deploying a sanctioned tool introduced risk.
The panel's answer combined governance with literacy. One team works in close partnership with IT and uses the same repositories and data lake IT already understands. When I asked the audience who had someone responsible for data governance, roughly a quarter raised their hands. Panelists also noted that most misuse is not malicious; people simply do not know the risks. Danielle O'Connell suggested framing it personally: if you would not hand your own information to a personal cloud account, why do it with company data? She also stressed speaking in terms project teams understand. Telling a field team a tool lacks SOC 2 compliance means nothing until it is translated into a concrete risk. As a technologist, I will admit we are guilty as charged. It took me 30 years to figure out that technology is the easy part. The hard part is communicating it.
None of this is fast or free.
The first insight is that integration is the first project, and it is engineering work. Burns & McDonnell's 11 independent practices are a familiar pattern. Design models live in Revit and Autodesk Construction Cloud, submittals and RFIs in Procore, schedules in Primavera P6, cost codes and payroll in ERP systems such as Sage or Viewpoint Vista, and much of what other firms contribute arrives as email and PDFs. Every AI tool added to a disconnected stack becomes one more system someone has to reconcile by hand. This is why our work at Forte Group starts with the data layer: connectors into each system of record, including the ERP, with governance and access control built in from the start.
The second is that data collection works best as a byproduct of work rather than an additional task. Asking people to enter more data rarely succeeds. Letting AI capture and structure what already exists does. Model metadata that was entered inconsistently across firms and projects can now be classified by language models, and documents from other firms can be extracted, classified and reconciled against the model. We apply the same principle in our own delivery, where recorded conversations feed agents that create tickets and code.
The third is that value starts where the pain is greatest, and in construction, that is often document work. It is bounded by codes, specifications and contracts, which makes it the category that automates reliably and can be measured. According to a16z, pre-bid document review today takes three to six weeks and $50,000 to $100,000 per project, and catches around 30% of the issues that later become change orders. Our recommendation is to start with one live project: a fixed-cost diagnostic that pulls design, field, schedule and cost data for one job into one model, followed by a single document workflow chosen by cost and priced against the outcome it produces, whether that is review time, change orders caught or hours returned to the project team. For one agricultural buildings manufacturer, field estimating ran on fragmented tools and spreadsheets. Consolidating them into one quoting application connected to the ERP and engineering data means estimates are now produced on site, with fewer errors.
The fourth is that people will build their own tools if the organization does not provide them, and sanctioned tools have to earn trust. The 30 contract risk agents at Burns & McDonnell are evidence of demand, not just a compliance problem. Luke Reeve compared deploying AI to trusting a new colleague with real work. That trust has to be earned with evidence, which is why we build an evaluation harness alongside the data layer, so every automated output is measured against a human baseline. Combined with data governance and access control, it is also what keeps a tool that works for one team working for the tenth, the lesson of the RFP agent story.
The last is that adoption depends on communication. Governance frameworks and well-built tools still fail if people do not understand the value or the risk in their own terms. Whatever we build with clients, the conversation has to happen in the language of the people doing the work, whether that is an estimator, a project manager or a superintendent in the field.
I closed the panel with a simple wish: that AI be seen more as a tool and less as magic. Software development and construction share that discipline. A tool can do excellent work, or, as happens whenever I attempt anything in construction, you can hit your thumb with a hammer. The difference is in how deliberately you use it.
83% faster delivery. Under 10% rework. See exactly how Xceptor got there.
.jpg)
