The Hidden Risk of Incomplete AI Answers: Why AEC Cannot Afford Half-Truths

The risk, in ten slides

Save it, share it, or send it to whoever is signing off your AI deployment.

Swipe to preview · 10 slidesDownload the PDF

The most dangerous moment in deploying artificial intelligence is not when systems fail catastrophically. It is when they give partial truths with complete confidence. In the architecture, engineering, and construction (AEC) sectors, this difference matters a great deal. Incomplete information doesn’t just underperform. It kills.

Incomplete information doesn’t just underperform. It kills.

Why AI Produces Dangerous Incomplete Answers

Today’s large language models and generative AI systems work by statistical pattern matching rather than real understanding or reasoning. When they meet an incomplete dataset, a new scenario, or a gap in knowledge, these systems don’t admit what is missing. They make things up. Scaling the model doesn’t fix this. It is built into how probabilistic AI works.

Research shows this consistently. The hallucination and coding-accuracy figures above hold across both general-purpose and task-specific models, and the two problems make each other worse. The critical failure is how confidently wrong the answer sounds, more than the error rate itself. These systems don’t signal uncertainty. They present conjectures as certainties because the model optimises for fluency and coherence. The fix is architectural, not aspirational: building systems that can abstain when uncertain.

These systems don’t signal uncertainty. They present conjectures as certainties.

Construction and engineering work is not a question-and-answer chat. They are deterministic domains where half-answers are half-failures. Incomplete structural load calculations mean the structure fails. If a geotechnical assessment leaves out soil conditions, foundations fail. Missed edge cases (seismic activity, thermal expansion, material degradation) cause operational and safety harm that cannot be undone. Generative AI systems are built for probabilistic inference, so they give different outputs for the same input. In creative work, people welcome that variety. In deterministic domains, it is a liability. The construction industry has seen this risk and taken a cautious “wait and see” approach, precisely because AI lacks the reasoning needed for safety-critical work.

The Liability and Regulatory Reality

AI takes no responsibility for its outputs. Responsibility stays with the operator, the deployer, and the engineering firm. Under existing law in most jurisdictions, construction companies owe a legal duty of care. If a firm deploys an AI system without rigorous testing, validation, and human oversight, negligence claims attach to the firm, not to the system. This creates an imbalance in accountability: the firm bears unlimited liability whilst the AI system bears none. The system cannot be held negligent. It cannot defend its reasoning. It cannot give evidence in court about what information it considered or rejected. Contracts with AI vendors rarely settle this properly. Most vendor agreements include clauses that disclaim liability, require indemnification from the deployer, and limit the kinds of claims construction firms can bring.

New regulatory frameworks are starting to recognise this danger. The European Union AI Act places specific duties on providers and deployers of “high-risk” AI systems. That class includes AI systems used as safety components in construction and built-environment systems. Its requirements include an iterative risk management system across the whole AI system lifecycle. They also cover data governance, with training data that is representative and checked in a systematic way. They set accuracy and robustness requirements with declared metrics. Explainability must let people understand and check how decisions are made. Systems that keep learning after deployment need constant monitoring. These requirements exist because regulators see that probabilistic AI is a poor fit for work with deterministic requirements.

Requirements for Safe Deployment

The alternative to probabilistic AI is a deterministic architecture. Such systems give the same output for the same input and follow explicitly defined rules. They can be audited and traced, and they say plainly when they lack enough information to give an answer. In AEC, four tasks must run this way: structural design optimisation, load-bearing checks, checks on material choices, and safety assessment. Generative AI can help them in the early, exploratory phases. It can suggest design options, find new mixes of materials, and draft planning scenarios. But the moment the output enters safety-critical decision-making, it must move into a space that is deterministic, auditable, and open to human review.

Before deploying any AI system in AEC, firms must put explicit, verified, and enforceable safeguards in place. Structured human-in-the-loop oversight is a must. AI outputs do not go directly into construction or engineering decisions. Qualified domain experts must review, validate, and either approve or reject each material output. Research shows structured human oversight increases error detection from 18.9% to 91.5%. I cover how to design that oversight layer on purpose in Redesigning Oversight Architectures. Before deployment, set clear targets for how accurate and complete outputs must be. Every step must stay traceable and open to audit across the lifecycle, from data ingestion through model training, validation, deployment, and ongoing operation. Every material decision needs an explanation that stands up technically and that engineers without AI expertise can follow. Monitoring and assurance must carry on after deployment. Any deviation should trigger an investigation and a fix. Finally, contracts with AI vendors must state who bears liability if the system fails, what warranties are given, and what audit rights the deployer keeps over model training and data.

The Path to Accountability

These requirements do not exist to impose a regulatory burden for its own sake. They exist because the stakes are unforgiving. When AI systems fail in low-consequence settings, the cost is inconvenience and rework. When AI systems fail in AEC, the consequences can include injury, death, or catastrophic infrastructure failure. AI will not be held responsible for these outcomes. The operator will. The firm will. The engineers who deployed and supervised the system will face scrutiny, liability, and possibly criminal negligence charges if the failure could have been foreseen and was not properly guarded against.

The path is neither “embrace AI without reservation” nor “abandon AI entirely.” It is this: deploy AI in AEC only within a governance framework that respects the domain’s deterministic safety requirements and sets verification practices above regulatory minimums. That means using probabilistic generative AI only to explore, never for binding analysis. It means moving to deterministic systems for all safety-critical decisions. It means a structured human-in-the-loop check on every material output. It means keeping complete audit trails and explainability mechanisms. And it means making clear, in contracts and in operations, who is responsible when things fail.

The most dangerous phrase in AI-enabled engineering is “the system said so.”

That is not professional engineering judgment. That is an abdication of responsibility. The required phrase is: “We have reviewed the system’s analysis, considered the underlying data and logic, conducted independent verification, and determined this conclusion is sound.”

The guard cannot be lowered. It must be installed, tested, documented, and continuously monitored. AI is a powerful tool. But in AEC, it is a tool that requires more, not less, expert human oversight.

AI is a powerful tool. But in AEC, it is a tool that requires more, not less, expert human oversight.