# Who is liable when AI gets structural design wrong?

aistructuralreview.com · September 16, 2026

> The Short Answer: Liability Follows the Human Chain, Not the Model There is no separate legal category for AI liability in structural design as of 16...

## The Short Answer: Liability Follows the Human Chain, Not the Model

There is no separate legal category for AI liability in structural design as of 16 September 2026. The engineer of record, the design firm, and the checking engineer remain the parties who sign and seal calculations, drawings, and reports. If an AI tool produces a beam size, foundation depth, or connection detail that later fails, the first question is not what the model knew but who accepted the output and put it into a construction package. Professional liability law asks whether the engineer met the standard of care. Using AI does not lower that standard. It may raise the evidence burden because the engineer must show how the output was verified, what assumptions were fed in, and why the result was reasonable. Vendor contracts, indemnities, and insurance policies can shift money after a loss, but they rarely remove the engineer from the primary liability chain. The practical rule is simple: if a human signs it, a human owns it.

**Also worth reading:** [How can structural engineering firms mitigate liability risks when integrating AI into design and analysis workflows?](https://aistructuralreview.com/knowledge/how_can_structural_engineering_firms_mitigate_liability_risks_when_integrating_ai_into_design_and_analysis_workflows.php) · [How do I accurately determine column effective length for modern structural design?](https://aistructuralreview.com/knowledge/how_do_i_accurately_determine_column_effective_length_for_modern_structural_design.php) · [How are physics-informed neural networks changing structural design in 2026?](https://aistructuralreview.com/knowledge/how_are_physics-informed_neural_networks_changing_structural_design_in_2026.php)

## Why AI Changes the Liability Map

Traditional structural software is deterministic. A finite element solver may be wrong, but it repeats the same wrong answer with the same inputs. AI systems, especially large language models and generative design tools, are probabilistic. They can produce different answers on different runs, fill gaps with plausible text, and hide errors in fluent explanations. That matters in structural design because the cost of a wrong answer is not a bad paragraph. It is a collapsed roof, a cracked foundation, or a bridge closure. Research from ASCE Library has asked whether chatbots can design and analyze steel structures, and the answer is usually not to a professional standard without heavy checking. Nature has published work on AI-assisted structural realignment of high-rise buildings through lifting, grouting, and reinforcement, which shows the technology can support complex work. But the same capability creates traceability problems. If the model changes, the data drifts, or the prompt is lost, the audit trail breaks. IBM has argued that human-in-the-loop alone is not a governance strategy. That warning applies directly to structural design. A human who clicks approve without independent calculation is not a control. They are a rubber stamp.

## The Four Liability Buckets in Practice

Liability in AI-assisted structural design usually falls into four buckets: professional negligence, product liability, contract liability, and regulatory liability. Professional negligence sits with the engineer and firm. Product liability can reach software vendors if the tool is sold as a safety-critical component, though most vendors write contracts to avoid this. Contract liability comes from warranties, indemnities, and limitations of liability. Regulatory liability comes from building codes, professional registration boards, and safety regimes such as the UK Building Safety Act 2022 or Singapore's construction governance rules. The table below compares how liability shifts across three design modes.

| Feature | Deterministic CAD/FEA | AI-assisted generative design | Autonomous agentic design |
| --- | --- | --- | --- |
| Output predictability | Same input, same output | Probabilistic, run-dependent | Goal-driven, may change path |
| Default liability holder | Engineer of record | Engineer of record plus vendor contract | Unclear, likely engineer and integrator |
| Verification burden | Check model inputs and results | Check data, prompt, model version, output | Continuous monitoring and kill switch |
| Insurance treatment | Standard E&O | Increasingly questioned by insurers | Often excluded or specially endorsed |
| Best use in 2026 | Final analysis and code checks | Concept options, clash detection, early sizing | Research and non-safety-critical tasks |

This table is not a legal opinion. It is a risk map. The more autonomy a tool has, the more the engineer must document why the output was accepted or rejected.

## Contract Terms That Decide Who Pays

Key contract issues in agentic AI deals, as discussed by Mayer Brown and others, often turn on allocation of risk. Vendors may promise that a tool is fit for a particular purpose, but their standard terms usually disclaim accuracy, limit liability to fees paid, and exclude consequential damages. For a structural firm, that means a $500 monthly subscription may cap recovery at $6,000 even if a design error costs millions. The firm should push for clear warranties on training data, model updates, and known failure modes. It should also define what happens when the vendor changes the model without notice. Indemnities should cover third-party claims caused by the vendor's defect, not by the engineer's misuse. Data rights matter too. If project data trains the vendor's model, confidentiality and security risks grow. Audit rights allow the firm to inspect logs after an incident. Insurance clauses should require the vendor to carry technology E&O and cyber coverage. Without these terms, the engineer carries the risk while the vendor keeps the upside.

## Practical Steps Before Using AI on a Live Project

The first step is classification. Decide whether the AI tool is advisory, assistive, or autonomous. Advisory tools suggest options; assistive tools produce calculations or drawings; autonomous tools make decisions. Most firms should stay in advisory or assistive mode for safety-critical elements. The second step is validation. Run the tool against known benchmark problems, compare its output with hand calculations or established software, and record the results. The third step is independent check. A qualified engineer who did not create the AI output must review it, and that review must be documented. The fourth step is version control. Record the model name, version, date, prompt, input files, and random seed if available. The fifth step is training. Engineers need to know what the tool can and cannot do, including hallucination, data bias, and unit errors. The sixth step is insurance notification. Tell your professional liability insurer that you use AI, and ask whether your policy excludes it. The seventh step is incident reporting. If an AI output is wrong, log it, correct it, and tell the vendor. These steps cost time, but they are cheaper than a claim.

## Common Mistakes That Create Liability

The most common mistake is treating a chatbot as a calculator. A language model can write a convincing paragraph about load combinations while using the wrong load factor. Another mistake is failing to keep the prompt and model version. If the output cannot be reproduced, the engineer cannot show how the design was reached. A third mistake is assuming the vendor's insurance covers the firm. Vendor policies usually protect the vendor, not the engineer. A fourth mistake is silent use. If the contract requires the engineer of record to perform all design work, delegating to an AI tool without disclosure may breach the contract. A fifth mistake is over-reliance on human review. IBM's warning about human-in-the-loop is relevant here: a reviewer who lacks the time, data, or expertise to challenge the model is not a real control. A sixth mistake is ignoring data governance. If the AI tool was trained on outdated codes or foreign standards, its suggestions may not comply with local law. A seventh mistake is using AI for final code compliance without a second independent path. Codes change, and models do not automatically update.

## Cost, Insurance, and Pricing in 2026

AI design tools range from free chatbot tiers to enterprise platforms costing $20,000 to $200,000 per year. Per-seat generative design add-ons often run $50 to $500 per month. The larger cost is not the subscription. It is the verification labor. A reasonable rule of thumb is to budget 10% to 20% of the design fee for independent checking when AI is used on safety-critical elements. Insurance is the harder number. Professional liability insurers are still developing AI endorsements. Some ask detailed questions about model governance, while others add exclusions for AI-generated outputs. Premium increases for firms with weak controls can range from 5% to 25%, though pricing varies by region, project type, and claims history. Data center expansion has its own hidden liability risks, as Insurance Business has reported, because these projects combine high structural loads, fast schedules, and complex supply chains. A structural firm that uses AI to speed up data center design may save weeks but create a concentrated error that affects many identical buildings. The cost of a recall or retrofit can dwarf the design fee.

## When to Act

Act before the first AI-assisted submittal, not after a failure. If the firm already uses AI informally, run an audit now. List every tool, every project, and every output that reached a client or contractor. Check contracts for AI clauses, insurance policies for exclusions, and project records for traceability. If a project is high-risk, such as an occupied building, a bridge, a hospital, or a data center, apply stricter controls or avoid autonomous AI entirely. If a regulator or client asks how AI was used, the firm should have a written answer. If the firm cannot answer, it is already exposed. The date 16 September 2026 is not a deadline in law, but it is a practical line. Building safety regimes in the UK, Singapore, and the EU are moving toward more traceability for digital design tools. Waiting for a clear statute may mean waiting until after a claim.

## How Courts and Codes Treat AI Output

No court has created a new AI liability standard for structural design as of 2026. Courts apply existing negligence rules. They ask whether the engineer used the skill and care of a reasonably competent practitioner in the same field. If AI is common in the field, using it may become part of the standard of care. If it is not common, using it without extra checks may be negligent. Codes are also silent on AI in most jurisdictions. The International Building Code, Eurocodes, and British Standards set performance requirements, not tool requirements. That means the engineer cannot point to a code clause that approves an AI output. The engineer must show the output meets the code through calculation, testing, or engineering judgment. The EU AI Act adds another layer. It treats AI used as a safety component in critical infrastructure as high-risk, which brings obligations for risk management, data governance, technical documentation, and human oversight. Structural design for bridges, buildings, and energy infrastructure may fall into that category depending on the use. The UK's Building Safety Act 2022 puts more responsibility on the principal designer and the accountable person for higher-risk buildings. If an AI tool contributes to a design decision, the duty holder still needs to demonstrate that the decision was safe. Singapore's Pinsent Masons commentary on its AI construction boom notes data and governance challenges. The pattern is consistent: regulators care about outcomes and evidence, not whether the tool was called AI.

## Alternatives to AI-Only Design

Firms do not have to choose between full AI autonomy and no AI. A safer path is hybrid design. Use AI for option generation, clash detection, cost estimating, and repetitive detailing. Keep final sizing, load paths, and code compliance in deterministic software with independent checks. Another alternative is a two-model approach. Run the AI suggestion, then rebuild the critical elements in a conventional finite element model. A third alternative is a human-led review board. For high-risk projects, a senior engineer who did not use the AI tool reviews the output and signs a separate check sheet. A fourth alternative is parametric design with explicit rules. Parametric tools are not generative AI, but they can automate variation without probabilistic output. They are easier to audit and insure. The trade-off is speed. AI can explore more options faster, but the verification cost may erase the savings on small projects. On large projects, the savings can be real if the firm has a governance system. The worst option is to use AI silently, skip the check, and hope the vendor's contract covers the loss. That is not a strategy.

## What Good Governance Looks Like

Good governance in structural AI is boring. It looks like a model registry, a sign-off sheet, a version log, and a named engineer who owns each output. It includes a policy that says which tools are approved, which tasks they can perform, and which tasks require independent calculation. It includes training records and incident logs. It includes contract terms that push vendor liability where it belongs. It includes insurance disclosure and, where needed, a dedicated AI endorsement. It also includes a culture where engineers can say no to a fast AI answer. The technology can improve early-stage options, reduce repetitive drafting, and help with structural realignment and retrofit studies. It cannot replace the professional judgment that codes and courts expect. The firms that manage AI liability well will not be the ones with the most advanced models. They will be the ones with the clearest paper trail and the strongest checking culture.

## Quick answers

### Does using AI transfer liability away from the structural engineer?

No. The engineer of record still signs and seals the design, so professional liability remains with the human and the firm. Vendor contracts may shift some money after a loss, but they do not remove the engineer from the primary duty to verify the output.

### What should a structural firm document when using AI?

Record the tool name, model version, date, prompt, input files, assumptions, and any random seed. Keep the independent check calculations and the name of the reviewing engineer. This record is what proves the standard of care was met.

### Will professional liability insurance cover AI-related structural errors?

It depends on the policy and the insurer. Many policies now ask about AI use, and some add exclusions or endorsements. Firms should notify their insurer before using AI on live projects and get the answer in writing.

### Is human-in-the-loop enough to manage AI risk in design?

Not by itself. IBM and other governance researchers warn that a human reviewer without time, data, or expertise is not a real control. The review must be independent, documented, and backed by benchmark testing.

### When should a firm avoid autonomous AI in structural design?

Avoid autonomous AI for final sizing, load paths, and code compliance on high-risk projects such as occupied buildings, bridges, hospitals, and data centers. Use it for early options or non-safety-critical tasks with human checks.

Canonical: https://aistructuralreview.com/knowledge/who_is_liable_when_ai_gets_structural_design_wrong.php
Markdown: https://aistructuralreview.com/knowledge/who_is_liable_when_ai_gets_structural_design_wrong.php/index.md