AI in AEC is only as good as the context it stands on

It is Thursday afternoon on a residential job. The site manager needs to release the door order and asks the project's AI assistant a simple question: what fire rating do the doors on the third-floor escape corridor need?

The answer comes back in seconds: EI30, with a reference to the door schedule. It cites a real document and sounds right.

The document is revision C, attached to an email from March. In May the fire engineer commented on the escape strategy, the corridor became a protected route, and revision E of the schedule moved those doors to EI60. The change sits in meeting minutes and in a markup that nobody linked back to the schedule. The assistant found the first file that matched the question and answered from it.

Nobody on this project did anything unusual. That is the point.

Artificial intelligence tools answer confidently from whatever they find. On most construction projects, what they find is scattered: federated models, PDF sets, email attachments, meeting notes, markups, and a large share of knowledge that lives only in people's heads.

The tool can read all of it. What it cannot do on its own is tell which version is current, why a decision was made, which regulation applies to this building, or who is allowed to approve a change.

In most industries a wrong answer is a typo. In ours, a wrong fire rating, a wrong setback distance or a dimension taken from a superseded drawing is a liability. The assistant in the opening scenario did not fail at reading. It failed at knowing what counts.

Adoption is still early. In the RICS artificial intelligence in construction report 2025, just under 12% of respondents said they use AI regularly in specific processes, and only around 20% said their organisation is engaged in strategic planning around AI. That makes this a good moment to fix the foundations first.

Knowing what counts has to live outside people's heads before any tool can use it. I call it the context layer: a well-organised, versioned, permissioned memory of the project and the firm. Think of it like a federated model, but for information. Many sources, one coordinated view, and every piece knows where it came from and what state it is in. That is information management, a discipline AEC already knows, and it is now becoming the foundation for AI.

Ask three people on a project what a "room" is. The architect means an enclosed space with a number on the plan. The mechanical engineer means a zone served by a terminal unit. The facility manager means a lettable area with an occupant and a cost centre. Same word, three meanings.

People resolve this in conversation without noticing. Machines match words, and if the words mean different things in different documents, the answer will be confidently wrong.

AEC already has the tools for this. Classification systems, naming conventions and agreed definitions in the building information modelling (BIM) execution plan have been part of good information management for years. In database language this is called a schema, the agreed structure that says what kinds of things exist and what they are called. If your project has a file naming standard and a classification table, you already have a small schema.

The same thinking applies when information moves between parties. Exchange information requirements define the agreed format for passing information from one team to another. Software people call that an API. Same idea: agree the format and nobody has to guess.

Extend that discipline to the words that cause trouble: room, space, zone, level, and above all "approved" and "issued". An AI that sees "approved" in a casual email and "approved" as a document status will treat them as the same thing unless someone has written down that they are not.

Construction projects record what was decided far better than why. The drawing shows that the stair moved 600 mm. It does not show that it moved to keep a transfer beam clear, or that the client accepted a smaller lobby in exchange at a meeting in June.

Six months later someone sees the odd geometry and "fixes" it. An AI tool is even more likely to, because it works only from what it can see. If it cannot see the reasoning, a deliberate choice looks like a mistake, and an option that was rejected for good reasons looks like a fresh idea.

Experienced project teams catch this because they remember. The tool remembers nothing you did not write down.

A useful decision record answers five questions: what was decided, who decided, when, based on which information, and what was rejected. Decision logs, RFI registers and change control already support decision making on most projects. What is usually missing is the link between the decision and the elements and documents it affects.

Checking a design against regulations or client standards is one of the more promising uses of AI in the construction industry, and the one where false confidence does the most damage.

A rule like "minimum corridor width 1200 mm" is useless on its own. You need to know which document it comes from, which clause, which edition, whether it applies to this building type, and whether a person has confirmed that reading of it.

So every rule in a checking set should carry its source clause, its edition or date, its scope, and a verification status: extracted by a tool, or checked by a named person on a given date. An unverified rule should be labelled as such, in the same way a drawing marked "for information" is not used for construction.

Trust comes from being traceable, not from sounding sure.

It is worth being sceptical here. Current tools are good at finding candidate clauses. They are much weaker at exceptions, cross-references between documents, local amendments and the judgement calls that a building control officer will actually make. That is exactly where a person has to stay in the loop.

The responsible pattern is simple. Agents suggest changes, run checks and draft answers. A qualified person reviews them and approves or rejects. The approval is recorded.

Professional responsibility in AEC sits with named, qualified people: the architect who signs the drawings, the engineer who signs the calculations. Insurance and liability follow those signatures. A tool cannot hold professional liability, so it cannot be the last step before something is issued.

The record should show what the tool proposed, what the person changed, who approved it and when. It works like a check-and-approve step on a drawing issue, where the tool is one more author whose work gets checked. It also protects the firm: two years later, you can show that a competent person reviewed the output.

Not everyone should see or change everything. In a common data environment (CDE), folder permissions decide who can read, who can upload and who can move a document from work in progress to shared or published. ISO 19650 describes these states, and most firms that work to it already use them.

An AI assistant needs the same rules. If it can read work-in-progress folders, it will quote unchecked design as fact. If it can read commercial folders, it may show fee information to a subcontractor who asked an innocent question. Access rules for AI are CDE folder permissions, nothing more exotic.

Versioning works the same way as model revisions and drawing issue status. By default, the tool should answer from the latest published revision, say which revision it used, and flag when a newer one exists. The same applies after handover, when the information about a built asset has to stay current for the rest of its life cycle.

Go back to the door. If the assistant had said "EI30 per door schedule rev C (published March). Rev E (published May) shows EI60 for this corridor", the site manager would have caught the problem in ten seconds. The technology to answer that way exists. What is usually missing is clean status data underneath it.

None of this requires buying anything.

1. 1Clean up naming. Take the naming convention you already have and enforce it on live projects. Fix status and revision codes on the current sets first.
2. 2Write down decisions with their reasons. A simple log per project: date, decision, who, why, which documents and elements it affects. One line each is enough.
3. 3Link rules to their sources. For checklists you already use (fire, accessibility, client standards), add the clause reference, the edition and who verified it.
4. 4Define who approves what. A short responsibility matrix: which roles can approve which kinds of change. Most BIM execution plans have one. Check it matches what really happens. (More on keeping that plan usable in BEP without the bureaucracy.)
5. 5Agree a vocabulary. One page of definitions for the terms that cause arguments on your projects.

Anyone who has worked to ISO 19650, the international standards series for information management using BIM, will recognise every item here. The difference is who reads the information. Until now it was mostly people, who fill gaps with experience. From now on it is also machines, which do not.

• AI in AEC is limited less by the model than by the context it can see.
• Naming, classification and agreed definitions are your schema. Without them, machines match words, not meaning.
• Record decisions with their reasons, or tools will quietly undo them.
• Every rule needs a clause, an edition and a verification status.
• AI proposes, a qualified person decides, and the approval is recorded.

Which of these is the weakest link on your current project: naming, decisions, sources, approvals or permissions?

FAQ