What data does a building need before AI can be useful?

No single list fits every building. The data a building needs depends on the decision the AI is meant to support, and an energy forecast, a fault-detection tool, a document assistant and a predictive-maintenance model each want different inputs, at different frequencies, with different depths of history. So work backwards from the use case to the minimum reliable evidence it requires. Collecting everything and hoping value turns up later is the expensive alternative.

A reading without context is just a number

A point reads "37". It might be a valve 37% open, a command to open it that far, or a return-water temperature in degrees Celsius. For a model to use it, someone has to record which device it comes from and what that device serves, its unit, whether it is a measurement, a set point or a command, and when and how often it was sampled. What the plant was doing at the time matters too.

Semantic models such as Brick hold that context in a form software can read, so an application can ask for "all supply-air temperature sensors on air-handling units serving the third floor" without an engineer first deciphering point names by hand.

Different questions, different data

Treat the table as a starting point: the supplier of any specific application should state its own requirements, and you should test them against what the building actually holds.

Test the data against the job it will do

Completeness, accuracy, timeliness and consistency all matter, but they need to be judged over representative periods, since a convenient week can make almost any dataset look sound. NIST's AI Risk Management Framework (AI RMF 1.0) says accuracy measurements should be paired with clearly defined, realistic test sets that represent the conditions of expected use. For a building, the question is whether the history covers what the application will actually meet: every season, holidays, changes in occupancy, plant failures. A dataset drawn from one mild spring cannot support claims about summer peaks.

Tolerances differ by use case as well, so agree acceptable gaps and latency for each one. A monthly energy trend can live with a few missing hours; an operational alert cannot.

Record what changed, and when

Buildings do not stand still. Sensors are replaced, recalibrated or moved; schedules change; point names are revised after a BMS upgrade. Any of these can change what a dataset means without a single value looking wrong, so a change log belongs alongside the data. NIST's framework notes that maintaining the provenance of training data supports transparency and accountability. In a building it also lets an engineer explain why a model's output shifted.

The unglamorous work needs a budget and an owner

Data preparation is often the largest task in an early building AI project, and the one most likely to be missing from the budget. Someone has to map points to assets and spaces, set quality checks and their thresholds, correct errors at source as well as in the analytics copy, log changes to sensors, schedules and systems, and keep the mapping current as the building evolves. Unless each of those tasks has a named owner, the model inherits the gaps.