AI in AEC 2026: AI is becoming a workflow question, not just a tooling question
AI in AEC 2026 was held in Helsinki on March 18-19. The event focused on the use of AI in architecture, engineering, and construction, and on the practical realities of applying it in day-to-day work.
The program included many impressive demos, plenty of talk about agents, software vendor perspectives, and academic presentations. But beyond the individual solutions, one broader point stood out most clearly: AI in AEC is increasingly becoming a question of workflows, information management, and operating models, not just a question of new tools.
There were many demos, but broader adoption looked harder
Many examples followed a familiar pattern. A small team combining domain expertise, coding ability, and AI fluency had built a compelling pilot or internal tool. The demos were often genuinely impressive.
But once the discussion moved to whether these solutions were already in widespread use across real projects and day-to-day engineering work, the tone often became more cautious. In many cases, the solutions were still in limited testing or early deployment.
That is an important distinction: a successful demo does not yet mean that the way engineering work gets done has actually changed.
Tools alone do not solve much if the surrounding process stays the same
Several talks returned to the same point from different directions. Companies may already have access to Copilot, GPT-based tools, or various agent-style systems, but the impact remains limited if information is scattered, processes are inconsistent, and responsibilities are unclear.
In other words, the practical bottleneck does not seem to be model capability alone. Quite often, the bigger issue is that the organization still works according to structures that were not designed around these new technologies. In that situation, AI gets inserted into an old system instead of the workflow itself being reconsidered.
The word agent was used very broadly
Another clear observation was how loosely the term agent was used. Almost any solution built around retrieving, transforming, or moving information from one place to another could be described as an agent.
This is not only a semantic issue. If every part of a pipeline is called an agent, the discussion quickly becomes imprecise. In practice, it would be more useful to distinguish between conventional automation, retrieval, orchestration, and genuinely flexible agent-based behavior. Otherwise, technical theater can start to hide the more important question: what does the system actually do, and how reliably can it be used as part of an engineering process?
The software vendor view was also notable: software operation itself may stop being the bottleneck
One of the recurring themes from software vendors was that in the future, users may not need to operate engineering software in the same way as before. If BIM models, detailing tasks, or other design actions can increasingly be directed through natural language, then mastering the interface itself may no longer be such a central part of professional skill.
That also raises a strategic question. Not every engineering organization may need to build a growing stack of bespoke internal AI tools.
It is entirely possible that some of the most useful capabilities will become part of the core software platforms themselves. In that case, the competitive advantage will come less from every company building its own small tool ecosystem, and more from how well experts use evolving software and, above all, evaluate the quality of the outputs it produces.
Engineering responsibility does not disappear even if the interface becomes easier
Even if software can eventually produce steel detailing or make model changes from a prompt, that does not remove professional responsibility. Someone still needs to understand whether the output is technically sound, appropriate to the input conditions, and fit for delivery.
The main conclusion is not that design engineering is about to become fully autonomous any time soon. A more credible direction is that tools improve, but the importance of expert judgment grows alongside them. The easier software becomes to operate, the more important it is to distinguish a good solution from a bad one. So it also matters to make sure that the subject-matter expertise of the people doing the work stays at a high level in the future too.
What this reinforced for Crestia
For Crestia, the event reinforced the view that the most interesting role of AI is not just building isolated eye-catching features. The greater value comes when information flows better, alternatives can be evaluated faster, and expert time is freed up for the parts of the work where judgment matters most.
That is why we see AI primarily as part of workflows, decision support, and practical engineering work rather than as a separate layer of technology.
Looking for expert solutions? Discover Crestia's professional services today.