AI governance in construction: A practical framework

TL;DR

• A construction AI framework covers the whole lifecycle, from planning and data collection through deployment, maintenance and archiving, not just the moment someone types a prompt.
• Accountability stays human. ASCE’s roadmap is explicit that AI cannot hold responsible charge or seal work, and IPMA says a designated individual should answer for AI-related decisions.
• The practical core is five things: an approved-tool register, a risk assessment before production use, human verification proportionate to consequences, decision records, and a risk review at least quarterly.
• Start from NIST’s four functions (Govern, Map, Measure, Manage), then add the construction-specific guidance from ASCE, ACEC, CIOB, RICS and IPMA.

What an AI governance framework means on a construction project

Most pages that rank for this topic describe governance in general terms: fairness, transparency, board oversight. Those principles apply, but a contractor or engineering firm needs them translated into project terms. Who may upload a geotechnical report to an AI tool? Who checks a quantity takeoff before it goes into a bid? Where is the record showing which assumptions the system made?

An academic study of on-site AI implementation in the buildings journal MDPI argues that a construction framework should guide trustworthy and responsible AI design, development and implementation across planning, data collection, algorithm development, deployment, maintenance and archiving. The same study identifies 13 principles: proportionality, reliability and robustness, safety, explainability, transparency, accountability, contestability and redress, oversight, human agency, harmlessness, privacy and data management, fairness, and environmental well-being.

Thirteen principles are too many to administer as a checklist, so most firms collapse them into a smaller operating model. The following sections do that in the order a project actually meets them: why it matters, who is accountable, which controls apply, and how to roll them out.

Why governance matters more here than in an office-software setting

Construction output is not advisory text. A calculation becomes a foundation, a compliance review becomes a permit, a tender comparison becomes a contract award. The consequence of an unnoticed error scales with the physical and contractual weight of the deliverable, which is the reasoning behind ASCE’s position. Its AI Roadmap for Application in Civil Engineering says responsible adoption matters because civil engineers must preserve accountability for engineering decisions and protect public health, safety and welfare while using AI to deliver infrastructure more efficiently.

Three groups feel this differently:

• Contractors carry delivery and cost risk. An AI-generated quantity or schedule that nobody verified becomes their margin problem.
• Engineering consultancies carry professional liability. The licensed professional’s signature is the product, and a tool cannot share it.
• Project owners carry the long tail: data rights, records that must survive for the asset’s life, and the consistency of quality across many suppliers.

Governance is what lets all three use AI at volume. Without it, adoption stays in the hands of a few enthusiasts using unapproved tools, which is precisely the exposure that ACEC’s member guidance addresses when it lists approvals and authorisations, unapproved AI uses, confidential information, accuracy, IP rights, bias and cross-border considerations.

Accountability: The part that cannot be delegated

Every credible framework in this sector arrives at the same place: a person answers for the output. The disagreement is only about how formally that is written down.

ASCE’s five human red lines

The ASCE roadmap says AI governance in civil engineering spans the infrastructure lifecycle and must preserve a licensed professional’s “responsible charge”; where licensure does not apply, a named competent person remains accountable. It sets out five lines that current practice should not cross:

1. Accountability is never delegated.
2. AI cannot hold responsible charge or seal work.
3. Outputs require verification by a competent person, in proportion to the consequences of error.
4. Engineering judgment on code intent, assumptions and risk remains human.
5. People set the limits and keep override authority.

The third line is the useful one for day-to-day work, because it implies a sliding scale. A meeting summary needs a skim. A load calculation or a clearance check needs an independent engineer working through it. Proportionality is something a governance policy should state in a table, not leave to individual mood.

IPMA on project management

For project managers, IPMA’s 2025 guidelines say a designated individual should be accountable for AI-related decisions. Project managers should keep records of AI systems, decision-making processes and data sources, maintain human control of critical decisions, and provide fallback protocols for failures. IPMA also recommends explainable outputs and fallback mechanisms so teams can understand AI recommendations and intervene manually when the system fails or behaves unexpectedly.

The practical reading: explainability is not an abstract virtue. It is the property that makes verification possible. A reviewer who cannot see which source document, which clause or which assumption produced a figure can only accept or reject it wholesale.

The standards worth building on

No single document covers the whole construction value chain, so firms combine a general risk framework with professional-body guidance. The table maps what each contributes.

NIST’s four functions in construction terms

ENR’s guide explains the NIST structure as follows: Govern establishes policies and accountability; Map identifies use-case context and risks; Measure evaluates accuracy, robustness and fairness; and Manage implements mitigations and continuous monitoring. Applied to a contractor:

• Govern: a named owner for AI, an approved-tool list, and a policy on what data may enter which tool.
• Map: for each use case (tender analysis, quantity takeoff, compliance review, reporting), who consumes the output and what happens if it is wrong.
• Measure: a sample check of outputs against a known answer, repeated when the tool or the document type changes.
• Manage: escalation when an error is found, and a log of corrections that feeds back into the policy.

What RICS shows about documentation

The RICS standard governs surveyors, but its structure is a useful template for anyone. It requires RICS-regulated firms to record an appropriateness assessment before using AI with material impact on services, considering the task, alternatives, environmental and stakeholder impacts, data risks, bias, erroneous outputs and consequences. It also requires a risk register covering bias, erroneous outputs, information limitations and data retention or use. Each risk needs likelihood, impact, mitigation, risk appetite and status, and the register must be reviewed at least quarterly. Firms must also carry out supplier due diligence and document the decision of a qualified professional on the reliability of output.

One point deserves emphasis for international firms: RICS notes that relevant legislation in the jurisdiction takes precedence if it conflicts with the standard. A professional-body standard is a floor for conduct, never a substitute for the law of the country where the project sits.

Seven controls every construction AI policy needs

Synthesizing the sources above, a policy that holds up in an audit or a dispute usually contains these seven controls.

1. An approved-tool and use-case register. GIRI’s January 2026 consultation draft for construction proposes exactly this, alongside an AI Governance Panel, risk-assessment templates, sign-off thresholds, periodic audits, annual board reporting and project-director accountability. It is a UK draft, so treat it as a model rather than a requirement.
2. A risk assessment before production use. The GIRI draft covers task criticality, data provenance, bias, human oversight, verification controls, cybersecurity and data protection, and decision records or audit trails.
3. Data boundaries. CIOB warns construction organisations to address opacity, consent, data rights, ethical data collection, bias and hallucinations. In practice this means classifying documents (public, project-confidential, client-restricted) and stating which classes may be processed by which approved tool. A closer look at what to protect and what to ask vendors is in our guide to AI data security in construction.
4. Proportionate human verification. Written as a table: output type, consequence of error, who verifies, how.
5. Traceability. Every figure should point back to a source document and a stated assumption. This is the single control that makes the fourth one affordable.
6. Cybersecurity. IPMA says project managers should protect systems with controls such as encryption and access controls.
7. Review cadence. The Institution of Structural Engineers advises including AI risk and mitigation assessments in the digital policy, continuously assessing risks such as structural safety and data security, and setting review intervals, quarterly or annually depending on organisational need.

A worked example of proportionality

Consider three outputs from the same tool in the same week, and how a policy might treat each.

The point of the table is that governance does not slow the first row. It concentrates attention where the cost of error sits, which is also where our article on keeping human sign-off with AI for BIM focuses.

Rolling it out: A sequence that works

Two professional bodies publish adoption sequences that agree more than they differ. CIOB’s 2024 playbook gives an eight-step checklist: educate, form a cross-functional team, identify use cases, launch pilots, draft an initial policy, evaluate tools, train staff and prioritize data governance. ACEC’s October 2025 primer recommends process mapping, impact assessment, documented standard operating procedures covering inputs, interpretation, human oversight and quality control, training, pilots with SMART goals, an initial AI-use policy and stronger data governance.

Merged into one path:

1. Inventory current use. Find out which tools staff already use, approved or not. This is usually the least comfortable step and the most informative.
2. Form a small cross-functional group. Engineering, project delivery, legal, IT and one commercial lead are enough. The group owns the register.
3. Map processes and rank use cases by consequence. Use the proportionality table above.
4. Write standard operating procedures for the high-consequence uses first. ACEC specifies inputs, interpretation, human oversight and quality control as the headings.
5. Run scoped pilots with measurable goals. CIOB and ACEC both recommend SMART goals; define what accuracy and time saving would count as success before starting, and who checks.
6. Draft the policy from what the pilots taught you, not from a template alone.
7. Train staff on the policy and on failure modes, notably hallucination and over-trust.
8. Review on a fixed cadence. CIOB advises updating policies and training as technology and practice evolve; the RICS quarterly cycle is a sensible default for material uses.

For teams working out the commercial side of this sequence, our pieces on turning AI pilots into project gains and proving AI return on investment cover measurement in more depth.

Bring in counsel early

ACEC says engineering firms should involve legal counsel in reviewing internal policies, client and partner agreements, and AI procurement contracts, because mistakes involving contract language, intellectual property, data handling or liability allocation can create financial, legal and reputational exposure. For a US firm this is the step most often skipped until a client questionnaire arrives. Ask counsel specifically about indemnities, how client data may be used by vendors, and whether the client contract restricts AI use on its documents.

Governing specific workflows

Document processing and tenders

Tender analysis fails quietly: a clause missed in a 600-page package does not announce itself. Governance here means the tool must show where each extracted requirement came from, and a named bid manager must confirm the high-risk clauses (liquidated damages, warranties, scope exclusions). The workflow is described in our note on tender document analysis with human sign-off.

Compliance and engineering review

Here the ASCE red lines apply directly. The tool may flag, cross-reference and draft; the engineer judges code intent and owns the result. Our overview of how AI civil engineers fit with ASCE rules addresses where that boundary falls for engineers in practice.

Risk management

AI that scans documents for risk signals is only as useful as the review process that follows. The construction risk AI workflow explains how to wire findings into an existing risk register instead of creating a parallel one.

Perspective: What we think the frameworks underweight

Most governance material treats the AI as a black box to be fenced in. We build from the opposite premise: the safest system is one whose work can be reviewed the way a colleague’s work is reviewed. That changes what governance should demand of a tool.

First, assumptions must be written down. An engineer who inherits a calculation needs to see what was assumed about soil class, load case or currency, not only the result. Yesper records its assumptions so a reviewer can challenge them, which is also what makes the proportionality table workable: verification takes minutes when the reasoning is on the page and days when it is not.

Second, general-purpose models degrade as complexity rises. Producing a geotechnical report from raw CPT protocols, extracting quantities from a BIM model, or building one comparable set of numbers from a dozen tenders in three currencies are tasks where a generic assistant breaks down. Governance that assumes all AI is interchangeable will under-control the hard cases and over-control the easy ones.

Third, the aim is not to remove people. It is to move them from retyping and searching to judging, with source verification attached to every output. A policy that cannot distinguish those two roles will either ban useful work or wave through unreviewed work.

Where Yesper fits

Yesper is an AI civil engineer for construction and infrastructure teams. It searches project documents, checks regulatory compliance, creates deliverables such as reports, tenders and spreadsheets, takes off quantities from BIM and drawings, and records its assumptions with source traceability so a human reviewer can verify the work. Companies such as AFRY, NRC Group and Netel use it across their organisations. If you are drafting a policy and want to see how traceable, reviewable output looks in practice, explore Yesper.

Common failure modes to design against

Frameworks usually fail in recognisable ways, and each one maps to a control above.

• Policy without a register. A PDF that tells staff to “use AI responsibly” but names no approved tools and no owner is unenforceable.
• Sign-off as ritual. If a reviewer cannot see sources and assumptions, the signature becomes a formality. CIOB’s call for transparency about model reasoning and probability, where possible, addresses this.
• Pilots that never end. A pilot without SMART goals and a decision date becomes permanent shadow use.
• One-time assessment. Models, document types and regulations change. A risk register reviewed once is a historical document.
• Ignoring the contract. Client agreements may restrict AI use or data handling, and the firm learns this at the worst time.