How to Adopt AI in a Forma Structured in AEC

Gemini_Generated_Image_xjv7smxjv7smxjv7.jpg

Note: This article is written and published in Portuguese and is a translated version of the original published here.

 

Part 2 of 3 in "AI in AEC: Diagnosis, Playbook and Test." Part 1 diagnosed why AI initiatives in AEC are losing steam. Part 3 demonstrates a functional tool with Model Context Protocol connected to Revit.

Part 1 argued that the difficulties of AI adoption in AEC are structural, not motivational. This post shows you what to do about it, with four pillars that fit into how the AEC segment actually works, rather than how SaaS playbooks assume it works. The pillars are diagnosis of maturity by function, measurement of ROI linked to the economic logic of projects, change management designed for subcontracted execution, and a path from prototype to production that does not depend on having an internal development team.

DiegoFaria_0-1784772144651.png

Diagnose maturity by role, not company

Most maturity models assess the company as a whole. This framing is useful for executive presentations, but practically useless to put into practice. Roles within a AEC company have different data formats, different cultural frictions, and different ROI profiles. Treating them as a single block flattens decisions that should be made at the role tier.

Data from the 2025 State of Design & Make suggest this change. Between 2024 and 2025, the share of respondents who described themselves as in the "middle of the effort" to adopt AI rose from 25% to 31%, while those who reported being "close to the target" dropped from 48% to 31% [Source: Autodesk State of Design & Make, 2025]. The data is global, the reporting does not isolate this metric by segment, but nothing indicates that AECO deviates from the boilerplate. Companies that thought they were close to maturity realized that they were in the middle of a longer process. The chart by function was more confusing than any average suggests.

A function-by-function readout yields more accurate screening. Project authorship is mostly an alone work, tied to files and subject to the limitations of tools, while coordination is even more complex, being multidisciplinary and slow due to review cycles that involve people who do not share the same technology park. Design operations is a different problem, highly production-centric and constrained by the volume of review requests and submissions. Each of these roles requires a different first step, which explains why treating them as a single initiative produces the "we bought a tool and nothing happened" outcome mentioned in Part 1.

Measuring ROI according to the economic logic of AEC design

There is no clear public dataset about specific AI ROI for AEC. PwC's study of 1,217 companies found that the top 20% of AI achieves 7.2 times the AI-generated financial performance relative to the rest [Source: PwC AI Performance Study, 2025]. This number is from multiple market sectors and directional, coming from a consultancy with a commercial interest in reinforcing the urgency to act, so treat the 7.2x as a signal about the gap between leaders and the rest, not as a benchmark for AEC.

A more useful framework for AEC is to separate three categories of ROI and measure each by its own criteria.

Time savings in authoring. Easy to measure in hours per deliverable. The real strength is in aggregation, because the savings, multiplied by many users who save a few hours a week, become significant even at the executive tier. The problem is not magnitude, but conversion, since it is not possible to know for sure whether the hours saved become real productivity or dissipate in other tasks without generating measurable value.

Saving time in coordination. It directly reflects the economic logic of the project. Reduced clashes, reduced review requests, faster approval cycles. Average amount of money when the project is large, sometimes higher. The problem is attribution, because most companies don't keep comparison metrics, so even teams that achieve real coordination gains often can't prove that the gains came from AI rather than an improvement in the work itself.

Rework avoided. Highest value in money, the most difficult to measure accurately. The argument of "if we hadn't identified this, it would have cost X" is difficult to prove, but the magnitude matters.

DiegoFaria_1-1784772166314.png

A company that measures authoring time only at the workflow tier will find that AI has brought single-digit gains, while a company that tracks all three categories across their entire project portfolio sees the true picture.

Change management for an industry that subcontracts execution

The Wharton Blueprint for AI Agent Adoption identifies three psychological frictions to adoption: perceived competence, trust and delegation of control. Research shows that control concerns alone account for 26% of the adoption decision [Source: Wharton Blueprint for AI Agent Adoption, 2026]. People don't delegate to systems that they can't easily review, pause, or revert.

In AEC there is an extra nuance. The company that adopts AI is often not the one doing the work in the field. A design firm can automate clashes detection within Revit. The subcontractor that reads the revised drawings is in another technology park, with other incentives and performance metrics. Change management, therefore, happens twice: once within the company that adopts it, once in the transition to execution.

DiegoFaria_2-1784772185016.png

The BIM manager is right at this junction point. Treated as a filter, it slows adoption. Treated as a middle ground between design intent and execution layer, it accelerates adoption. Deloitte's framing of the State of AI Agents Report 2026 is straightforward: "workforce transformation will determine who wins" [Source: Anthropic State of AI Agents Report, 2026, citing Deloitte]. In AEC, workforce transformation is not just about your own people, but also about how the next link in the chain absorbs what the AI just produced.

The path from prototype to production

The playbook says: define a use case, fund a 12-month development cycle, evaluate the results, and only then scale. Few companies in the AEC segment outside the first echelon have the IT capacity to sustain this cycle, and this is what leaves the premise of "deploying AI across the enterprise" hiding a development backlog that, in practice, does not exist.

What has changed in the last year is how much cheaper prototyping has become. Frameworks such as the Model Context Protocol allow domain experts, including BIM managers, to build functional tools connected to current software, without going through a traditional development cycle. The Accenture team interviewed for the State of AI Agents Report 2026 by Anthropic describes MCP as a key piece of infrastructure for stateful and resilient agent communication [Source: Anthropic State of AI Agents Report, 2026]. In practice, this means that tools that once required quarters of IT effort can now be prototyped in a few days by the person who needs them.

This does not solve enterprise-scale deployment, but rather solves the bottleneck identified in Part 1: low IT capacity per company. A BIM manager capable of setting up a functional dashboard connected to the Revit in a week changes the cost logic of internal tool development.

More than the sum of its parts

Pillars implemented in isolation produce dashboards. Pillars implemented together produce capacity.

A company that diagnoses maturity by function but never adjusts how it measures ROI will report progress without seeing payback. A company that gets the measurement of ROI right, but ignores the transition to sub-contractor, will see authorship gains evaporate in the execution layer. And companies that solve both, but don't have a prototype-to-production path, continue to run into the wall of IT capacity in tools that should take a week to complete.

Part 3 of this series demonstrates what one of these tools looks like in practice: a dashboard connected to Revit, built like Claude's artifact using MCP, that tracks the evolution of a model throughout review cycles. It's a small slice of the deployment gap, but it shows the shape of what the playbook produces when the pillars are aligned.

Sources

1 Comment
sharafutdinov_di_dev
Contributor

Diego, the point about pilots dying at the "who owns the data" step matches what I see from the coordinator's chair: most AI initiatives in AEC never get a read path into the live model that the BIM lead is comfortable with, so they start from exports and stall there. I ended up building that read path as an MCP server for Revit 2022–2027 (read-only by default, actions behind two explicit gates, every mutation with a dry run and a verification), largely because the "just let it run scripts" approach never passed review. Looking forward to part 3; if your MCP tool covers model tracking, it would be interesting to compare which checks you exposed and which you deliberately left out.