Responsible AI in Engineering: A Leadership Framework

AI adoption inside an AEC firm rarely waits for a formal strategy. Someone begins summarizing meetings, drafting reports, exploring design alternatives or automating repetitive documentation. Early results can look promising. Then leadership confronts the harder questions.

What information entered the system? Which decisions did the output influence? Could another reviewer reconstruct how the answer was produced? If something is wrong, who remains accountable?

The strategic question is no longer whether an engineering organization will use AI. It is whether the organization can use AI without weakening professional judgment, confidentiality, quality control or client trust.

Responsible AI in engineering is therefore not primarily a software-selection exercise. It is an operating-model decision. The organization must decide where experimentation is encouraged, where controls are required and where the consequences are too serious for ungoverned use.

Move the Decision from “Can We Use AI?” to “Under What Conditions?”

A single organization may use AI for low-risk administrative work, knowledge discovery, coordination support and activities that sit much closer to technical judgment. Treating every use case as equally safe or equally dangerous produces poor governance.

Blanket prohibition can push experimentation into invisible channels. Unrestricted adoption can expose data and create unreviewed dependence. Leaders need a model that supports useful experimentation while preserving clear boundaries.

The more useful leadership question is not whether AI is permitted in the abstract. It is whether a specific use case is acceptable under defined conditions. For responsible AI in engineering, those conditions should reflect the sensitivity of the data, the consequence of error, the ability to verify the output and the person who remains accountable for the result.

This distinction matters because AI risk is contextual. The same tool may be suitable for organizing public information but unsuitable for processing confidential project documentation. It may help generate early questions but require a much stronger control environment before its output influences a technical, contractual or client-facing decision.

The NIST Generative AI Profile is a voluntary resource intended to help organizations incorporate trustworthiness considerations into the design, development, use and evaluation of AI systems. Translating that principle into an AEC operating context requires four leadership tests: Data, Decision, Detectability and Duty.

1. Data: What Is the System Allowed to See?

The first risk often appears before an AI tool produces any output. It appears when information is entered.

Project documents can contain client intellectual property, commercially sensitive assumptions, personal information, contractual material or data governed by specific access requirements. A useful tool does not automatically have permission to process that information.

Leadership should define data boundaries before defining approved use cases:

• What information is public, internal, confidential or restricted?
• Which tools are approved for each data class?
• Is submitted data retained, reused for training or accessible to a third party?
• What client or contractual permissions apply?
• How should users remove identifying or sensitive context?

These boundaries should be understandable at the point of work. A policy that only legal, IT or governance specialists can interpret will not reliably guide someone who must make a decision in a few minutes. Teams benefit from practical examples showing what may be entered, what must be anonymized and what must remain outside an AI system entirely.

Data classification also needs to follow information across the workflow. Removing a client name may not be sufficient if project location, technical details, drawing references or commercial assumptions still reveal the identity of the work. Responsible use therefore requires more than superficial anonymization.

Leaders should also examine how the provider handles submitted data. The questions include whether prompts are retained, whether information can be used to improve a model, which administrators can access the environment and what happens when an account or contract ends.

The practical rule is simple: convenience does not change information ownership. If the organization cannot explain where data goes and how it is handled, the use case is not ready to scale.

2. Decision: What May AI Influence?

AI can assist a decision without owning it. That distinction must remain visible.

Leaders should classify use cases by the consequence of error, not by how impressive the technology appears. Drafting an internal agenda and influencing a safety-related engineering decision do not require the same control environment.

This classification prevents a common mistake: applying one generic AI policy to use cases with fundamentally different consequences.

Reversibility is a useful additional test. If an output can be corrected quickly before it affects another person or system, the control burden may be lower. If the output could shape a contractual position, technical decision, external commitment or safety-related judgment, review should become more formal before anyone relies on it.

Leaders should also distinguish between generating options and recommending action. AI may help a team widen the range of alternatives, identify questions or organize information. The risk increases when an output is treated as a conclusion without independent evaluation of the sources, assumptions and constraints behind it.

Another distinction is whether AI affects an internal working step or a formal deliverable. A draft may be provisional, but once the result enters a client communication, project record or approved process, the consequences of error can extend beyond the person who generated it.

Clear decision boundaries make experimentation more useful because employees understand what they may explore independently and what requires escalation. Without those boundaries, teams either avoid valuable tools or take risks that leadership cannot see.

3. Detectability: Can the Organization See and Test AI’s Contribution?

Human review is not meaningful when the reviewer does not know where AI was used, what input shaped the output or which claims require verification.

Detectability requires enough evidence to inspect the contribution:

• the purpose of the AI-assisted step;
• the source material or approved data boundary;
• the person responsible for checking the output;
• the verification method;
• the material changes made after review;
• the conditions that trigger escalation.

Not every low-risk use requires a complex audit trail. The evidence should be proportionate to the consequence of error. However, if an output materially influences project, client or business decisions, “a person looked at it” is not a sufficient control description.

Detectability should help the organization learn, not merely document compliance. When teams record where AI contributed and where reviewers found problems, leadership can identify recurring failure patterns, improve guidance and decide whether a use case should remain limited, be redesigned or be discontinued.

For example, a use case may perform well with structured source material but become unreliable when the input is incomplete or ambiguous. That is valuable operational knowledge. It allows the organization to define conditions under which the tool is useful instead of making a broad claim that it either works or does not work.

Detectability also supports better incident response. When a problematic output is discovered, the team should be able to identify which source material was used, who reviewed the work, where the output travelled and whether similar results may exist elsewhere.

The organization should be able to explain what was checked and why the reviewer was qualified to check it.

4. Duty: Who Remains Accountable?

AI does not absorb professional responsibility from the people or organizations using it.

ASCE’s policy on artificial intelligence and engineering responsibility states that AI cannot replace the training, experience and judgment of a professional engineer or the engineer’s responsibility for protecting public health, safety and welfare.

This principle should shape decision rights throughout the organization. AI may support analysis, coordination or documentation, but accountable people must remain identifiable.

Leadership should define:

• who owns the use case;
• who approves the tool and data boundary;
• who reviews the output;
• who may rely on the output;
• who stops or changes the process when risk emerges.

In practice, accountability may sit across several roles. A process owner may decide how AI is used, a qualified reviewer may validate the output and a governance owner may set organization-wide controls. These roles can be different, but their responsibilities should not overlap so loosely that everyone assumes someone else is in charge.

Tool ownership is not the same as decision ownership. IT may approve a platform from a security or procurement perspective, but that does not determine whether its output is appropriate for a particular engineering or business decision. Subject-matter responsibility must remain with people qualified to understand the consequence of error.

Accountability also includes the authority to stop a use case. A team should know who can suspend the workflow when the tool changes, a new failure pattern appears or the data environment becomes more sensitive.

If responsibility becomes less clear after introducing AI, the operating model has moved in the wrong direction.

Human Oversight Must Be Designed, Not Merely Declared

Many AI policies rely on the phrase “human in the loop.” The phrase sounds reassuring but says little about the quality of control.

A reviewer may lack time, context or the expertise required to detect a plausible error. Repeated exposure to acceptable outputs can also create automation bias: people begin to approve rather than evaluate.

Effective human oversight requires four conditions:

• Authority: the reviewer can reject or stop the AI-assisted process.
• Competence: the reviewer understands the subject and the tool’s limitations.
• Evidence: the reviewer can inspect relevant sources and assumptions.
• Time: the workflow allows real evaluation rather than ceremonial approval.

Oversight can fail even when a reviewer is formally assigned. A person may be asked to approve an output without seeing the sources, may assume the system is more reliable than it is or may feel pressure not to slow the workflow. These are operating-design failures, not simply individual shortcomings.

A review step should therefore specify what the reviewer must test. Depending on the use case, that may include factual accuracy, completeness, technical assumptions, source reliability, confidentiality, consistency with approved standards and whether the output exceeds the intended role of the tool.

Independence can also matter. When the same person prepares the prompt, selects the source material and approves the result, blind spots can remain hidden. Higher-consequence use cases may benefit from a second qualified reviewer or a defined escalation point.

The trade-off is unavoidable. Stronger review can reduce speed; weaker review can increase risk. The solution is not to review every use case identically. It is to align review depth with data sensitivity, decision consequence and reversibility.

From Isolated Pilots to Organizational Capability

A successful demonstration does not prove that a use case is ready for organization-wide adoption.

Scaling requires ownership, approved tools, user guidance, quality controls, incident handling, periodic review and a method for retiring tools or use cases that no longer meet requirements.

ISO/IEC 42001 approaches AI through an organizational management-system perspective. Reference to the standard does not imply that AXANH is certified. Its strategic relevance is that responsible AI depends on coordinated policies, roles, objectives and improvement mechanisms—not only individual user caution.

A practical scale path has four stages:

1. Explore: test a bounded, low-risk problem with non-sensitive data.
2. Validate: compare output against trusted sources and define failure conditions.
3. Govern: assign ownership, data rules, review requirements and escalation paths.
4. Scale: expand only when controls remain effective across more users and contexts.

The transition between stages should depend on evidence, not enthusiasm. A pilot should not scale simply because users like it or because it appears to save time. Leaders need to understand what kinds of failure occur, whether reviewers can detect those failures and whether the workflow remains manageable when more people participate.

Scaling changes the risk environment. A controlled experiment may involve one experienced user working with carefully selected information. Organization-wide use introduces different experience levels, more varied data, inconsistent prompts and greater dependence on the output.

This means governance must be tested under realistic conditions. Controls that work for a specialist may not work when dozens of users apply the tool to unfamiliar situations. Training, guidance and escalation paths should therefore be part of the scale decision rather than added after adoption.

Leaders should also define retirement criteria. A use case may need to be paused when the provider changes its terms, the model behaves differently, the organization introduces a new data classification or the benefits no longer justify the review burden.

Leaders should not ask only whether a pilot saves time. They should also ask whether the process becomes more reliable, visible and manageable when additional people use it.

The Partnership Question: Can Both Organizations Explain the AI Boundary?

AI governance becomes more complex when work crosses organizational boundaries. A client and an external team may have different approved tools, data classifications, retention rules and disclosure expectations.

Responsible collaboration requires explicit alignment before AI touches shared work:

• Which use cases are permitted, restricted or prohibited?
• May project information enter an AI system?
• What evidence or disclosure must accompany AI-assisted work?
• Who reviews the output on each side?
• How will incidents or policy changes be communicated?

A general statement that both organizations use AI responsibly is not enough. The practical boundary should be translated into project-level expectations that the people doing the work can understand.

One organization may approve a tool for internal administrative use but prohibit project information from entering it. Another may permit specific use cases inside an enterprise environment but require disclosure before AI-assisted content becomes part of a deliverable.

Alignment should continue after the initial approval. Tools change, provider terms change, project information becomes more sensitive and workflows evolve. A responsible partnership therefore needs a way to revisit the boundary when the context changes.

This is where technology strategy meets partnership governance. Shared standards reduce ambiguity and help both organizations innovate without quietly transferring risk to the other party.

AXANH publicly describes technology, automation and AI-enabled support as part of a broader capability system rather than an isolated toolset. That positioning is consistent with its stated belief that quality comes from disciplined workflows, process control and accountability.