The AEC industry may be asking the wrong question about AI.
The useful question is no longer, “What can the tool generate?” It is, “What project context can it understand, and what is it allowed to do with that context?”
That distinction matters because a project does not live in one file.
Consider a common coordination question: What changed since the last review, and who does it affect? A dependable answer requires more than the current model. It may require the previous model version, the latest drawing set, the relevant specification, open and closed issues, answered RFIs, approved submittals, schedule milestones and the record of who reviewed or approved each change.
Most project teams already have this information. The problem is that it sits across different systems, formats and ownership structures. The model may be current while the issue log is not. A drawing may have been issued, but the reason for the change remains in an RFI. An approval may exist in an email that the rest of the team cannot see.
AI working on top of that environment may still produce a fluent answer. Fluency, however, does not make the answer safe to use.
Project intelligence raises the standard
At Autodesk University 2026, Autodesk described its next generation of Assistant as an agentic experience that brings project information, tools and specialized capabilities together around the outcome a team is trying to achieve. Autodesk used the term “project intelligence” for this direction.
The phrase is useful because it moves the conversation beyond visualization, document search and meeting summaries. Project intelligence suggests that AI understands enough of the project’s current state and history to support a decision or a controlled action.
That is a much higher standard. It requires the system to know not only what information exists, but which version is authoritative, how different records relate to one another, who is permitted to access them and where human approval is required.
The distinction also helps explain why AI adoption and measurable value are moving at different speeds. Deltek’s 2026 research found that 78% of North American architecture and engineering firms use generative AI, while only 38% report measurable business impact. Access to AI is widespread. Reliable integration into real workflows is much harder.
Five tests for trustworthy AI in a project workflow
1. Can it identify the source and version?
An answer should point back to the model version, drawing revision, specification section, RFI, submittal or issue record on which it is based. If the source cannot be inspected, the answer should be treated as an unverified draft.
2. Can it connect the model to the wider project record?
BIM provides geometry, object data and relationships. It does not, by itself, contain every contractual instruction, approval, schedule consequence or discussion that shaped the project. Useful AI needs access to the connected record, not the model alone.
3. Does it respect permissions and responsibility?
Project information is not equally visible or editable to everyone. Owners, designers, contractors, trades and consultants have different roles. AI should inherit those boundaries rather than bypass them.
4. Can it communicate uncertainty?
When a record is missing, duplicated or contradictory, the system should say so. A qualified answer with citations is more useful than a confident response built on incomplete context.
5. Does human approval remain part of the workflow?
The closer AI moves toward changing a record, routing an instruction or affecting a deliverable, the more important approval and auditability become. The AIA AI Firm Toolkit is direct on this point: professional responsibility cannot be delegated, and quality control remains human.
BIM is part of the context, not the complete context
BIM remains one of the strongest foundations for AI in AEC because it gives project information structure. Objects, properties, systems, locations and relationships provide context that ordinary documents do not.
But trustworthy project intelligence also depends on information management. The National Institute of Building Sciences describes effective management of structured information as essential to the delivery and operation of built assets. Its NBIMS-US Version 4 guidance covers project requirements, BIM execution planning and information exchange between project participants.
Interoperability therefore becomes an AI requirement, not simply a software preference. buildingSMART’s IFCX work is being developed to support more connected, data-driven and AI-enabled workflows through modular and implementation-friendly openBIM standards.
If information remains trapped inside disconnected systems, AI may help people search each system faster. It will not automatically understand how the records relate or which record should govern a decision.
What building CUBE has reinforced for Techture
Techture works across engineering delivery and software development. That combination makes the project-information problem very tangible.
CUBE, Techture’s cloud-based platform for managing design, construction and maintenance projects, was built around the reality that project work depends on connected information, clear responsibilities and a usable record of decisions. The CUBE MCP server was launched in July 2026, followed by the release of CUBE AI to a select group of customers in September.
The work reinforced a simple lesson: AI becomes useful only after the project record is usable. Live records, access permissions, citations, uncertainty and human approval are not secondary governance features. They are part of the product problem.
It has also reinforced the value of building technology alongside delivery teams. Real projects expose the handoffs, exceptions and recurring decisions that a software-only view can miss. Delivery experience shows where information breaks down. Product development creates a way to address those problems repeatedly and at scale.
This does not mean every project needs another platform. It means every AI initiative needs to begin with an honest review of the information process it will rely on.
Where AEC teams should begin
Before selecting another AI tool, choose one bounded project question or workflow and map what a reliable answer requires.
- Identify the project records that contain the required context.
- Define which source is authoritative when records disagree.
- Confirm naming, revision and version-control practices.
- Map access permissions, decision rights and approval points.
- Decide how the system will cite evidence and report missing information.
- Measure the outcome through review time, error rates, rework or decision cycle time, not tool usage alone.
Starting with a bounded workflow makes the weaknesses visible without putting a critical deliverable at risk. It also gives the team a practical basis for deciding whether the information foundation is ready for a larger AI deployment.
The real foundation for AI in AEC
The next stage of AI in AEC will not be defined by the number of assistants available to a project team.
It will be defined by whether those systems can work from information that is current enough to use, connected enough to understand and controlled enough to trust.
That requires better project records, stronger interoperability, clear permissions and human accountability. Once those foundations are in place, AI has a real opportunity to improve how project teams find information, understand change and make decisions.
That is where the serious work in project intelligence begins.
