McKinsey's analysis of AI in architecture, engineering and construction is thorough, balanced, and ultimately too polite about one thing. The $228 billion in annual U.S. value the report identifies by 2030 is real. The report handles carefully — and firms making technology decisions in 2026 need to hear without the diplomatic framing — who is positioned to capture it and who is positioned to give it away.

The answer turns on a question most procurement teams are not asking: what happens to your project data after it enters the platform?

The Moat Description

Read the medium-term section of the McKinsey report as a technical specification rather than a strategic recommendation, and it becomes unusually specific. Data only becomes an advantage, they write, when firms capture it at the point of creation, structure it so it can be reused, track its origins and meaning, and retain the rights to learn from it over time.

Four clauses. Each one names a thing most firms are currently not doing, and each one names a thing several major platforms are doing on their behalf, under terms the firms haven't read carefully.

Structuring data for reuse is a knowledge layer – a connective tissue between the specification, the detail it governs, and the comparable detail from the project three years ago that established the precedent. Tracking origins and meaning is a provenance trail – the audit record that shows where a conclusion came from, what data it was derived from, and who reviewed it. Retaining the rights to learn from the data over time is vendor neutrality – the ability to use your project history to train your own tools, rather than having it automatically incorporated into a platform model that also trains your competitors.

These are the things the report identifies as the structural source of medium-term competitive advantage in AEC. They are also precisely the things several of the sector's largest platforms are designed to prevent their customers from doing unilaterally.

What the Contracts Say

The legal picture has clarified considerably in the eighteen months since AI entered mainstream AEC procurement discussions. A Clifford Chance analysis of AI vendor agreements found that 92% claim broad rights over the data processed through the platform. AEC Magazine documented the systematic rewriting of end-user licence agreements – crafted, in their analysis, specifically to prevent customers from using their own data to train competing tools or build competing intelligence layers.

McKinsey cites a version of this in their own language: "technology vendors are pushing harder to access project data and the rights to learn from it and reuse it to create new products." The practical test they set – can you move your data, keep it separated from other customers, and exit the platform without losing what you've built – is currently failing at several of the dominant platforms in the sector.

In mid-2026, the argument moved from contractual to operational. A major construction platform restricted bulk data access for a third-party AI agent that had been operating on customer data, a dispute reported by ENR that clarified exactly how quickly a platform can fence off access a firm assumed was stable. The episode demonstrated that data access is not a feature. It is a policy, and policies change when incentives change.

The uncomfortable conclusion McKinsey implies but leaves the reader to finish: if the platform you feed with project data serves your direct competitors on the same infrastructure, your project history is improving their tools. Not theoretically. Operationally, in the next tender, on the next job you're both chasing.

Why the Near-Term Tools Won't Save You

There is a second argument in the McKinsey report that the vendor community will not amplify, because it applies to most of what they are currently selling.

Near-term AI productivity gains from design, modelling and workflow automation – faster drafting, automated RFI triage, spec review assistance – will, McKinsey states, "likely soon be table stakes." The framing is deliberate. A tool that is available to every firm by subscription is not a source of competitive advantage. It is the cost of staying level. Every firm in your market buys the same tool, the margin it temporarily creates is competed away in the next bidding cycle, and the industry lands at a higher productivity baseline where no individual firm is better off relative to its competitors.

The only layer that doesn't commoditise this way is the firm-specific data layer: built from your projects, encoding your standards, improving with your work, owned entirely by your firm. McKinsey places this layer at the medium-term horizon, eighteen to forty-eight months. That reflects how long it typically takes firms to fund and staff an internal program. It does not reflect how long it takes to build the layer on real project data with purpose-built architecture.

Where Generalist AI Breaks Down

The commoditisation argument above describes what happens to tools over time. There is a more immediate problem that surfaces before any of that plays out: generalist AI does not work on real AEC project data.

The pattern is consistent enough to have a name inside most AEC technology teams: the PoC honeymoon. You drop a set of drawings and a specification into Copilot, Claude, or ChatGPT. You ask a few questions. The results look promising — the model surfaces relevant clauses, connects terminology across documents, gives you something that reads like insight. Two months later, you are measuring the outputs against expert review criteria on a real project scope, and what looked like understanding turns out to be fluent approximation. The PoC becomes another failed experiment. The usual diagnosis is that AI "isn't ready" for AEC, or that your documents are too complex, or that you need a better prompt. The actual problem is structural.

Generalist models cannot understand AEC-native data the way a project requires. A design-build contractor pricing a fixed-price scope is not reading documents — they are navigating them. Cross-referencing the geotechnical report against the structural specification. Holding the contract terms against the scope assumptions in the drawings. Tracing a building code requirement through three layers of design detail to confirm it is resolved. That navigation is the work, and the risk being priced is exactly the gap between what the document set implies and what the project actually requires. A model with no memory of the relationships between those documents does not reduce that risk. It adds to it, and the error compounds silently until it surfaces at the point in the project where fixing it is most expensive. Research published in 2023 by Zhejiang University and Newcastle University quantified what structure changes. Knowledge graph-enhanced LLMs achieved 89% accuracy on construction contract risk and responsibility classification. Plain LLM querying on the same documents was not close. The performance gap is not explained by model capability. It is explained by structure: the graph encodes the relationships between clauses, obligations, and entities that the contract implies but does not state explicitly. A model without that structure is reading the words. A model with it is reading the contract.

This is what a structured knowledge substrate does: it gives AI the same navigational architecture a senior project manager uses, with complete traceability the project manager cannot provide. The implication for design-build contractors and developers taking on fixed-price risk is not abstract. Every AI tool your firm deploys on proposal documents, contract reviews, or coordination sets is either working from that structure or not. If it is not, the responses are built on an incomplete reading of the document set. The error rate compounds silently, and it surfaces at the point in the project where fixing it is most expensive.

The Accountability Architecture

McKinsey's governance section is worth reading alongside their data rights analysis, because the two arguments reinforce each other.

AI reduces effort, they write, but not accountability. Firms that deploy AI in production workflows will face increasing regulatory expectation – from building authorities, professional indemnity insurers, and engineering licensing bodies already updating their codes of conduct – that they can document how AI was used, what data it drew on, what human review was applied, and where the output came from.

The practical constraint this creates is specific. An AI system that produces outputs without a traceable path back to source documents is unusable at the highest-stakes points in the project lifecycle. A submission facing a building authority, a review carrying professional liability, documentation that might be read in a dispute – these require not just a correct answer but a verifiable one. The provenance trail McKinsey identifies as a medium-term data advantage is simultaneously the audit trail the same report identifies as an immediate governance requirement.

That is not a coincidence. It is the same architectural requirement showing up from two directions simultaneously. The system that shows its working is the only kind that belongs near work a licensed professional has to sign, and it is the only kind that builds the institutional knowledge the medium-term advantage depends on.

The Strategic Division

McKinsey's build-buy-partner guidance is the clearest framework in the report, and it draws a line that most AEC firms are currently on the wrong side of.

Build where you are genuinely distinctive. For an architecture or engineering firm, that is project delivery knowledge – the firm-specific judgment about how to handle a coordination problem, the specification approach that reflects years of working with a particular building type, the quality standard that defines your work in the market. That is worth encoding. It is not worth building the infrastructure underneath it from scratch.

Partner on the substrate. The document intelligence layer, the provenance tracking, the model-agnostic architecture that lets you move between AI tools without losing your accumulated data – this infrastructure exists at higher quality from purpose-built providers than it will from an internal build. The partnership model McKinsey describes as optimal – "a supportive partner proving value on a small number of real deployments with clear outcome targets" – is the right governance structure for technology that is moving faster than any firm's internal engineering capacity can track.

The firms that read McKinsey's medium-term horizon as an invitation to plan are not being strategic. They are ceding ground to the firms reading it as a build brief.

McKinsey sets a concrete test for technology partnerships: can you move your data, keep it separated, and leave without losing what you've built? Before your next software decision, apply that test to every platform your firm currently feeds with project data.

If you want to see what turning your AEC-native data into a structured knowledge base for agentic AI looks like, we run a zero-cost pilot. Just send us a project pack, we'll sign an NDA if you need us to, and we'll show you what AI that understands AEC actually looks like. Get in touch to discuss.