The Data Quality Crisis Nobody’s Talking About: Why Your AI Is Only as Good as Your BIM Data

The quiet reason your AI pilot underperforms

A firm buys an AI tool expecting it to reason cleanly over its own project data — pull a quantity from a schedule, check a clearance, summarize a spec — and instead gets output that’s subtly, confidently wrong. The instinct is to blame the AI. Usually the actual cause sits one level down, in the data the AI was handed in the first place.

Deloitte’s 2026 engineering and construction industry outlook says this almost exactly: “Poor-quality data continues to frequently undermine the reliability of analytics and AI solutions, reducing the return on investment and limiting both operational and competitive advantage.” It’s not a footnote in the report. It sits in the same section as agentic AI, computer vision, and IoT — the technologies firms are actually spending on — as the thing quietly capping what all of them can deliver.

That NIST figure is old — the study dates to 2004 — but the mechanism it describes hasn’t changed, and AI didn’t fix it. Data that doesn’t move cleanly between design, construction, and operations still doesn’t move cleanly. AI just made it obvious faster, because now something is actually trying to read all of it at once.

What “dark data” actually means inside a BIM file

AEC Business has been writing about a related idea under the name dark data — building information that technically exists somewhere in a firm’s systems but sits siloed, unindexed, and disconnected from everything else that could use it. Outdated networking infrastructure, a shortage of people who understand both the engineering side and the property-management side, and building systems that were never connected to begin with all feed the same outcome: information nobody can act on, because nobody can see all of it at once.

The example that made this concrete: a building’s occupancy data lives in one system, its CO2 readings live in another, and nobody had connected the two until a tool built an “influence graph” across them — at which point diagnosing a ventilation problem dropped from days to minutes. Nothing about the underlying sensors changed. What changed was whether the data could talk to itself.

The design side has its own version of the same problem, and it’s usually smaller and more mundane than a disconnected sensor network. A door gets modeled as Door_Ext_36 by one team and EXT-DOOR-36IN by another, on the same project. A fire-rating parameter gets left blank because the family template didn’t require it. A room schedule technically balances, but only because someone typed a number into a field instead of letting the model calculate it. None of this is dramatic. All of it is exactly the kind of inconsistency that a person catches instinctively and an AI tool, reading the file at face value, does not.

The cost was already there before AI showed up

The NIST interoperability study is worth sitting with because it breaks the $15.8 billion figure down by who actually pays it — and the answer isn’t the people making the data messy in the first place.

• Owners and operators — $10.6B a year (67% of the total)
• Specialty fabricators and suppliers — $2.2B a year (14%)
• General contractors — $1.8B a year (11%)
• Architects and engineers — $1.2B a year (8%)

Two-thirds of the cost lands on owners and operators, mostly during ongoing operation and maintenance — well after the design and construction teams who actually generated the data have moved on to the next project. An incomplete or inconsistent model at handover doesn’t just look untidy. It means someone downstream re-collects information that already existed once, because nobody trusted or could parse the version that was handed over.

A more recent example shows the same pattern playing out inside a single project instead of across an industry. Two Finnish research consortiums — Tampere’s Talotekniikka 2030 and Aalto’s Building 2030 — built an agentic AI system to automate bill-of-materials generation, because the source information was scattered across PDFs, drawings, Excel sheets, and schematics never built for a machine to read. The AI produced an estimate in hours instead of the days a human estimator would need, and caught details a person tends to miss — but only once the team solved the format problem the data arrived in. They also ran it on a locally hosted model rather than a paid API, specifically to avoid burning tokens re-processing the same messy inputs over and over. Their broader finding tracks with everything above: AI’s impact right now is largest in design, estimation, procurement, and management, and comparatively modest on site — precisely because on-site data capture is still the least structured part of the pipeline.

Two philosophies for fixing it — and why they answer different questions

There’s a real disagreement in the industry about what to do about this, and it’s worth naming because both sides have a point.

Clean the data first

The data-governance position: structure the data lake, standardize naming and parameters, and build the discipline before scaling AI on top of it. This is what a UK contractor did over two years with its safety data before any AI system found it useful.

Let AI work with the mess

The opposite instinct: don’t wait for pristine data, because it’s never coming. Extract and load first, transform after — let AI characterize the data as it actually is and pull out signal despite the imperfection, the way an influence graph found a ventilation issue in messy sensor data.

Both are right, for different jobs. “Work with the mess” makes sense when AI is making a diagnostic or exploratory judgment call from data that’s already imperfect and always will be — spotting a pattern across sensor feeds nobody expected to be perfectly clean. It makes much less sense when the AI’s job is to be the gatekeeper deciding whether a specific door clearance, fire rating, or egress width actually complies. There’s no “characterize the imperfection” version of that question. Either the modeled dimension satisfies the rule or it doesn’t, and an AI that approximates its way to an answer there is worse than useless — it’s confidently wrong in a way nobody catches until the resubmission.

This is why QA/QC agents exist in the first place

Every AI tool a firm adds after the model is built inherits whatever that model already contains — good or bad. An AI proposal-writer pulling square footage from a mislabeled room schedule, or a scheduling agent reading quantities off an uncurated bill of materials, will produce confident, wrong output, because it has no way to know the input it was handed was already broken. The fix for that isn’t a smarter tool further down the pipeline. It’s catching the inconsistency at the one point everything else depends on: the model itself.

That’s the actual argument for AI-driven QA/QC, underneath the compliance framing. Vitru connects directly to a firm’s live Revit file and checks the elements against a ruleset, element by element, with every finding tracing back to a specific ID rather than a plausible-sounding summary. A firm’s rules live in versioned workspaces instead of one senior reviewer’s memory, so the definition of “correct” is the same for every project, not whatever the last person modeling a door happened to call it. The by-product of that — beyond catching code violations — is a model that’s actually consistent enough for the next AI tool in line, or the next engineer, or the owner three years into operating the building, to trust without re-checking it by hand.

Book a demo → See how Vitru works

FAQ

Do I need clean BIM data before I can use AI at all?

It depends what the AI is doing. Exploratory or diagnostic tools can work with imperfect data. A tool deciding whether a model complies with code needs a grounded, element-level check — that’s a different job, and it’s the one most worth fixing first, because everything else inherits its output.

What is “dark data” and do I have it?

Information that technically exists in your systems but sits siloed and disconnected — sensor data nobody’s linked to your BIM model, O&M records disconnected from design data, or a model with parameters that are technically filled in but inconsistent across teams. Almost every firm has some version of this.

Why does an AI proposal or scheduling tool sometimes give confidently wrong numbers?

Because it read a value off a schedule, model, or export that was already inconsistent, and it has no mechanism to know that. The output looks confident because the tool isn’t aware anything was wrong upstream.

How does Vitru’s QA/QC agent help with data quality, not just code compliance?

Every check runs against the live model, element by element, and every finding traces to a specific element ID. Fixing what it finds doesn’t just clear a compliance issue — it makes the underlying data consistent enough for the next tool, team, or owner to trust it.

What’s the most common source of BIM data inconsistency inside a single firm?

Naming and parameters, not geometry. The same door type gets modeled correctly but named differently by different teams, or a required parameter gets left blank because the family template didn’t force it — small, boring inconsistencies that compound across a project.

The takeaway

The firms getting real value out of AI right now aren’t the ones with perfect data. Perfect data isn’t coming, and waiting for it is its own way of never scaling past a pilot. They’re the ones treating “check the model” as a permanent, automated step at the one point in the pipeline where every other tool’s accuracy depends on it — instead of either fixing it once by hand and hoping it holds, or ignoring it and trusting the AI to compensate for input it never had a reason to doubt.

Start with the model you already have. Book a demo and we’ll show you what’s actually in it.