Data Centres & AI Infrastructure
What data does a building need before AI can be useful?
The data, context and history different building AI use cases need, and how to test quality against the task.
Data Centres & AI Infrastructure
A building is AI-ready for a specific use case, not in general; assess one use case at a time.

Readiness is always readiness for something. A building can be ready for an energy-forecasting tool and nowhere near ready for predictive maintenance. It is AI-ready for a particular use case when three things are true: the information the application needs exists and can be reached reliably; the interfaces that deliver it are secure and maintained; and the organisation knows who will act on the outputs and how mistakes will be caught.
Installing more sensors, buying a platform or reserving space for computing equipment does not make a building AI-ready. Any of those may turn out to be necessary, but only once the use case has shown which gap they close.
The first test is whether the data means something to a machine. Assets need consistent identities. Measurements need units, timestamps and known locations, and the relationships between equipment, systems and spaces need to be recorded. Semantic models such as Brick exist precisely for this: they let software work out that a given temperature sensor is in a given room served by a given air-handling unit. Whether the choice is Brick, Project Haystack or another approach, the requirement is the same: context that a machine can read.
A one-off data export proves that the data exists. It does not prove that an application can rely on it. The questions that matter are how data will flow continuously from the BMS and other systems, who will maintain the interface when those systems change, and how the flow is secured.
Every output needs a recipient and a purpose. Who receives it, what do they do with it, and what happens if it is wrong? Advisory use, with a person making the decision, is the usual first step; automatic action comes later, if at all.
Models, data sources and building systems all change over time, so the owner needs to know when inputs or model behaviour have shifted, and who has the authority to suspend the application. NIST's AI Risk Management Framework (version 1.0, now being revised) includes, in its Manage function, mechanisms to supersede, disengage or deactivate AI systems whose performance is inconsistent with intended use. It is a good test of whether an organisation is ready to operate AI, not just to install it.
| Step | Output |
|---|---|
| Choose one priority use case | A one-paragraph statement of the decision it supports and who makes it |
| List the information it needs | Data items, history, frequency, context required |
| Check what exists | Availability, quality and gaps per item, with evidence from a sample |
| Check access and security | Interfaces, ownership, segregation from operational networks |
| Define the operating process | Who uses the output, verification, escalation, suspension |
| Prioritise the gaps | Improvements ranked by how much they unblock the use case |
The result is a short roadmap that an AI supplier can price against and an owner can judge.
Some buildings announce that they are not ready yet. Point names differ from one building to the next with no mapping between them. Nobody can say which system holds the authoritative asset register. Data can only be extracted by hand. No one has been named to act on the outputs, and no one has asked what happens when the model is wrong.
An honest assessment of one priority use case is a better guide to an AI budget than the most polished proposal. The warning signs above are where it begins, and each one cleared is a gap the supplier no longer has to price.
This article connects to our work on Our services.
We can discuss infrastructure and data readiness.
Contact Pagin Consulting