Where Should AI Sit in the Automation Process? Rethinking the Real Role of AI in AEC Workflows

AI is now being inserted into almost every conversation about AEC automation.

But in many cases, the question is still too vague.

The industry keeps asking:

“How can we use AI?”

A better question would be:

**Where exactly should AI sit inside the automation process?**

That difference matters because automation is not a single action. It is a chain of decisions, transformations, validations, and outputs. Some parts of that chain benefit greatly from probabilistic inference. Other parts require deterministic control. If AI is placed in the wrong layer, the workflow becomes unstable. If it is placed in the right layer, it can create real leverage.

This is the core issue.

The value of AI in AEC does not come from making everything intelligent.  

It comes from assigning intelligence to the right layer of the system.

In my view, that is where the conversation needs to mature.

AI should not be treated as a blanket replacement for automation.  

It should be treated as one component inside a larger process architecture.

And in that architecture, position is everything.

## The real problem: AI is often discussed without process decomposition

One of the biggest weaknesses in current AI discussions is that AI is often introduced before the workflow itself has been decomposed.

That creates confusion.

When teams say they want to “apply AI to automation,” they may actually be referring to completely different types of problems:

- interpreting visual information

- classifying room or object types

- predicting arrangement patterns

- detecting anomalies

- generating text summaries

- recommending options

- creating geometry

- validating model quality

- translating design intent into BIM actions

These are not the same tasks.  

They do not belong to the same computational layer.  

And they should not be solved with the same method.

This is why the first step is not choosing an AI model.

The first step is identifying the structure of the automation process itself.

A robust automation workflow in AEC usually contains several layers:

1. **Input capture layer**  

   Collecting drawings, images, model data, parameter data, schedules, and room/program information.

2. **Interpretation layer**  

   Understanding what the input means: object identity, relationships, categories, boundaries, room types, patterns, or constraints.

3. **Decision layer**  

   Evaluating alternatives, selecting options, comparing configurations, or prioritizing actions.

4. **Rule translation layer**  

   Converting interpreted information into explicit logic, structured parameters, and executable instructions.

5. **Deterministic execution layer**  

   Creating geometry, placing BIM elements, writing parameters, running transactions, extracting quantities, generating outputs.

6. **Validation and feedback layer**  

   Checking whether the output is acceptable, identifying errors, measuring performance, and feeding lessons back into the system.

The mistake happens when AI is placed without recognizing these layers.

In practice, AI is often strongest in layers 2, 3, and parts of 6.  

It is often weaker, or at least riskier, when used directly in layer 5.

That distinction is critical.

## AI is best used where interpretation is difficult but patterns exist

AI becomes useful when a task has three characteristics:

- the input is complex or noisy

- the logic is hard to express completely by hand

- useful patterns exist in historical or synthetic examples

That is why AI is powerful in tasks like:

- image-based layout interpretation

- object recognition

- room-type classification

- pattern extraction

- anomaly detection

- option scoring

- prediction of likely arrangement structures

- semantic understanding across messy project information

These are tasks where human experts can often do the work, but only slowly, inconsistently, or at limited scale.

In those situations, AI can become a pattern engine.

But this does **not** mean AI should replace deterministic modeling or rule-based execution.

It means AI should help the system understand or prioritize what should happen next.

That is a very different role.

## The wrong place for AI: deterministic execution without control

Many people are tempted to place AI at the last stage of the process.

That is understandable. It looks impressive to say:

“AI generates the model.”

“AI produces the BIM output.”

“AI automates the entire workflow.”

But in engineering workflows, this is often the most dangerous place to depend on AI.

Why?

Because the final execution layer usually demands:

- geometric consistency

- rule compliance

- category correctness

- transaction safety

- parameter reliability

- unit stability

- reproducibility

- auditability

These are not optional qualities.

They are required.

A probabilistic system may be useful in proposing or interpreting. But when the system reaches the point of actually generating BIM elements, writing quantities, or assigning classification logic, uncertainty becomes expensive.

This is why I strongly believe that AI should rarely be the final authority in deterministic execution.

That layer should remain controlled by rule-based logic, scripted workflows, or deterministic geometry reconstruction.

AI can guide the process toward execution.  

But execution itself should usually be explicit, traceable, and governed.

In other words:

**AI should suggest.  

Deterministic logic should commit.**

That is the architectural principle.

## The right place for AI: before execution, not instead of execution

So where should AI sit?

In many AEC automation systems, the best location is **between raw input and deterministic output**.

That means AI operates as a bridge layer.

It does not replace the workflow.  

It translates uncertainty into structured candidates.

This bridge role can take several forms.

### 1. AI as a perception layer

In many real AEC problems, the system first needs to understand what it is looking at.

Examples:

- reading raster floor plans

- identifying room boundaries from drawings

- classifying space types from spatial and textual signals

- detecting likely object locations

- recognizing repeated layout patterns

- extracting visual features from non-BIM information

These tasks are difficult to solve with only explicit rules, especially when the input is incomplete or noisy.

Here AI acts as perception.

It does not produce the final BIM model.  

It produces interpretable signals:

- heatmaps

- object proposals

- classified types

- ranked candidates

- detected anchors

- feature embeddings

- likely pattern structures

Those signals then become inputs for downstream rule-based processing.

This is exactly where AI creates value without taking unsafe control.

### 2. AI as a pattern-selection layer

In some workflows, the challenge is not seeing the input.  

It is choosing the right pattern among many possible ones.

Examples:

- selecting a room archetype

- recommending a layout set

- choosing a likely object assembly

- estimating the most probable arrangement class

- ranking optimization candidates

This is where AI can function as a pattern-selection engine.

Instead of generating the entire output directly, AI helps narrow the decision space.

That makes the workflow more scalable.

A human expert no longer has to inspect every case manually.  

The system can pre-sort, classify, and recommend.

Then the deterministic system can apply the corresponding layout logic, library mapping, and placement rules.

### 3. AI as an evaluation layer

AI can also be valuable after candidate options are created.

For example:

- comparing generated alternatives

- predicting which options are likely to create conflicts

- identifying unusual configurations

- detecting likely quality problems

- summarizing high-risk conditions across many outputs

In this case, AI does not produce the design.  

It produces a better lens for evaluation.

That is often a much safer and more productive role than direct generation.

### 4. AI as a feedback-learning layer

A mature automation system should not end when output is generated.

It should learn from:

- repeated exceptions

- recurring modeling failures

- quantity discrepancies

- layout-set instability

- parameter errors

- classification mismatches

- human correction patterns

This is another excellent location for AI.

Instead of forcing AI into the final execution step, we can use it to understand what the system keeps struggling with. That creates a feedback architecture.

And once the system begins to learn from exception history, it becomes easier to improve upstream logic.

## AEC automation should be designed as a hybrid system

The most stable automation architecture in AEC is usually not “AI-only” or “rules-only.”

It is hybrid.

That means each computational layer uses the method best suited to its problem.

A simplified version might look like this:

### Layer A — Input collection

Drawings, BIM models, room schedules, parameter tables, layout references, code dictionaries, image files, reports.

### Layer B — AI interpretation

Visual recognition, semantic classification, feature extraction, pattern detection, candidate scoring.

### Layer C — Structured translation

Convert AI outputs into explicit data structures:

- points

- boundaries

- room classes

- object codes

- archetype IDs

- ranked layout candidates

- confidence thresholds

### Layer D — Deterministic execution

Use Dynamo, Revit API, scripts, parametric logic, or reconstruction workflows to:

- place objects

- generate geometry

- populate parameters

- build model structure

- extract quantities

- produce reports

### Layer E — Validation and review

Check geometry validity, category consistency, exceptions, clash potential, parameter completeness, quantity reliability.

### Layer F — AI-assisted feedback

Analyze errors, classify exception types, detect recurring failure patterns, prioritize refinement areas.

This structure is important because it protects the system.

It allows AI to contribute where uncertainty is high, but keeps engineering-critical outputs inside a governed execution environment.

## Why this matters for BIM workflows specifically

BIM is not just a visual environment.  

It is a rule-sensitive information system.

That means errors in BIM automation are rarely isolated.

A wrong category assignment can break schedules.  

A wrong parameter mapping can break IFC exports.  

A wrong placement can affect quantities, routing, coordination, and maintenance logic.

Because BIM sits at the center of many downstream uses, AI should not be given uncontrolled authority over the final structured model unless the validation framework is extremely mature.

This is why I argue that the role of AI in BIM automation should be primarily:

- perception

- interpretation

- ranking

- recommendation

- feedback learning

and only secondarily, and very cautiously:

- geometry proposal

- direct generation

When the final output affects procurement, cost, classification, or compliance, the deterministic layer becomes even more important.

## The role of Generative Design in this architecture

Generative Design adds another important dimension.

In many workflows, Generative Design is viewed only as an option generator. But I think its role is broader.

Generative Design can also act as:

- a structured variation engine

- a synthetic data production system

- a pattern exploration environment

- a bridge between rule logic and AI training data

This matters because one of the hardest parts of applying AI to AEC is the lack of high-quality labeled data.

Real project data is often incomplete, inconsistent, or difficult to standardize. But Generative Design can produce controlled alternatives under explicit rules. That means it can generate training-ready pairs:

- input images

- geometry labels

- topological relationships

- metadata about design intent

- rule parameters

- seed-controlled variation

In this architecture, AI sits **after** a rule-based generative system and **before** deterministic reconstruction.

That creates a very important chain:

**Rule-defined variation → synthetic training data → AI interpretation/prediction → deterministic reconstruction/execution**

This is one of the most practical positions for AI in AEC.

It does not ask AI to invent the engineering logic from scratch.  

It asks AI to learn useful patterns from a controlled design universe.

That is a much stronger setup.

## AI should operate on uncertainty, not on certainty

This may be the most important principle in the entire discussion.

AI should generally be assigned to the part of the workflow where uncertainty still exists.

Examples:

- interpretation uncertainty

- classification uncertainty

- pattern ambiguity

- visual incompleteness

- option ranking difficulty

- exception prioritization

Once the workflow enters a stage where the logic is already known and must be executed correctly, AI usually becomes less necessary and sometimes harmful.

That means:

If the system already knows:

- which category to use

- where the placement anchor is

- which layout set applies

- which family should be instantiated

- which parameter must be written

- which quantity grouping rule must be used

then the job should move into deterministic execution.

Using AI after that point often adds instability where none is needed.

So the goal is not “use AI as much as possible.”

The goal is:

**use AI exactly where explicit logic becomes difficult, and stop using AI once explicit logic becomes available.**

That is how automation remains reliable.

## A process-based example

To make this more concrete, consider a generic AEC workflow involving spatial planning, BIM deployment, and downstream takeoff.

A process-based sequence may look like this:

### Step 1 — Collect structured and unstructured inputs

- room data

- drawings

- schedules

- images

- previous layouts

- code tables

- library definitions

### Step 2 — Use AI to interpret ambiguous inputs

- classify room or pattern types

- detect likely regions or anchors

- extract visual or semantic features

- estimate which archetype or layout family is most likely

### Step 3 — Translate AI output into explicit structured logic

- assign room archetype IDs

- map confidence-ranked layout candidates

- convert predictions into coordinate or boundary data

- establish valid object-code relationships

### Step 4 — Execute deterministic workflow

- apply layout rules

- place BIM objects

- populate parameters

- validate category logic

- perform quantity extraction

### Step 5 — Review exceptions

- detect failed placements

- identify quantity anomalies

- capture repeated override cases

### Step 6 — Use AI again in the feedback loop

- group exceptions by pattern

- identify weak archetypes

- refine training data

- improve upstream classification or scoring models

This is the workflow position AI should occupy.

It is not the whole engine.  

It is the intelligence layer inside a larger machine.

## Why this view is important for the future of AEC automation

The AEC industry is entering a period where many teams will try to add AI quickly.

Some of those efforts will fail, not because AI is weak, but because it is placed in the wrong process layer.

When AI is used to replace deterministic logic prematurely, trust breaks.  

When AI is used to support interpretation, ranking, and learning, the workflow becomes stronger.

This is why the future of AEC automation will depend less on who has the most advanced model, and more on who understands process architecture.

The real competitive advantage will come from teams that can answer:

- Which parts of the workflow are uncertain?

- Which parts are repeatable?

- Which parts need learning?

- Which parts need strict control?

- Where should intelligence stop and execution begin?

That is not an AI question alone.  

It is an automation design question.

## Final thought

AI should not sit everywhere in the automation process.

It should sit where the workflow still needs interpretation, prioritization, and pattern understanding. It should help reduce ambiguity, not introduce new ambiguity into the final execution layer.

In AEC, the most reliable systems will likely be the ones that combine:

- rule-based generation

- AI-based interpretation

- deterministic reconstruction or execution

- structured validation

- feedback-driven refinement

That is how AI can become useful without becoming unstable.

Not as a replacement for process design.  

But as a carefully positioned intelligence layer inside it.

---

A related paper on this topic has been presented at the Spring Conference, and the link will be added here after publication.

## Follow WeeklyDynamo

I write about AEC automation, BIM workflows, Generative Design, and AI integration from a process-architecture perspective.

- Blog: https://weeklydynamo.blogspot.com/

- LinkedIn: https://www.linkedin.com/in/weeklydynamo

- YouTube: https://www.youtube.com/@weeklydynamo

- YouTube (Generative Design): https://www.youtube.com/@GenerativeDesigner