Why AI maintenance in a data centre starts with the alarm log

AI maintenance tools learn from the records a site already keeps, so they inherit every gap in them. In 2026, 65% of data centre operators said they would let an adequately trained AI system make predictive maintenance decisions, down from 70% a year earlier (Uptime Institute, 2026).

In a small data centre specifically, the person deciding is the operations manager who holds a building management system (BMS), an asset spreadsheet and a folder of contractor reports. Since September 2024, UK data centres have been classed as Critical National Infrastructure, which raises the cost of a missed warning (DSIT, 2024). The vendor demo runs on someone else’s data.

This article argues that the alarm log and the maintenance history decide whether an AI alert is worth acting on, well before any model does. It gives you a five-question scorecard and three fixes to make before you buy, within AI and data in operations.

Predictive maintenance readiness is a data structure issue

Whether a predictive maintenance tool works on your site depends mostly on how your records are structured. Such tools set maintenance schedules from historical sensor data and failure rates (Uptime Institute, 2025), so a model can only find the patterns your records hold together.

• Names drift between systems. One cooling fault can carry a name in the BMS, another in the monitoring software and a third in the work order, so a model counts three rare events where there was one.
• Completeness is the weakest score. Only 35% of operators are very confident their operational data is complete, the lowest of the four quality measures Uptime tracked in 2026.
• Failures hide among planned work. In a study of a Google cluster, only 2,298 of 8,957 machine removals could be counted as failures, since the rest might have been routine updates (Sîrbu and Babaoglu, 2015).

In summary, the model reads the structure of your records before it reads a single sensor.

Why does clean data matter for AI maintenance alerts?

Clean data matters because an alert is useful only when most of its warnings turn out to be real. In a study of 12,453 machines in a Google cluster, 50% to 72% of failure warnings were real failures when false alarms were held to 5% (Sîrbu and Babaoglu, 2015). That study worked from 29 days of consistently logged data.

A small site starts from a weaker position. Its records sit in several systems, and a few dozen critical assets produce few failures, so each mislabelled event weighs more in what a model learns. Operators already sense the limit: the share who expect AI to lower the risk of human error fell 11 percentage points to 40% in a year (Uptime Institute, 2026).

What goes wrong when confidence in the data goes untested?

The data looks strongest exactly where a model is weakest. More than 90% of operators say they are very or mostly confident in their operational data, yet 14% doubt that it is complete (Uptime Institute, 2026). Uptime adds that many operators privately admit distrust, and that confidence counts only when governance and validation back it.

Call the mechanism the memory patch. When an engineer reads an alarm with an odd name, they correct it from memory and move on, so the shift goes well while the record stays wrong. A model receives the unpatched record and learns from what was written down.

The relief engineer: reading a site through its records

Imagine a relief engineer covering a night shift at an unfamiliar site. They have the alarm list, the asset spreadsheet and last year’s service reports, and the day manager is asleep. Every renamed alarm and every repair filed under the wrong unit costs them time.

An AI maintenance tool is that relief engineer on every shift, minus the morning phone call. It reads only what the records say.

Three actions for operators to make maintenance data ready for AI

Naming — giving every alarm and asset one name and one record

Give each alarm point one agreed name and tie it to a unique asset ID. Start with the cooling and power plant. AI is trusted to prioritise alarms in place of hand-coded rules (Uptime Institute, 2025), but it ranks what the records call things, so three names for one fault split the evidence three ways. When we map an alarm workflow, we first count how many names one asset produces across systems.

History — linking every repair to the asset it touched

Record each maintenance visit against an asset ID and mark it planned or unplanned. A model learns what failure looks like from the readings before a repair, and the Google study shows the cost of a missing label: most removals might have been planned updates (Sîrbu and Babaoglu, 2015). Made Smarter’s guidance to manufacturers agrees: predictive maintenance usually follows a working schedule and basic data collection (Made Smarter, 2021).

Ownership — naming who closes each alert and how

Give every alert type a named owner who records how it was closed. Failure to follow established procedures remains the leading driver of human-error outages (Uptime Institute, 2026), and an unowned alert tends to close without a note, which deletes the outcome a model needs. The closing code supplies that label, and an alert closed without one leaves the model guessing at the outcome.

How ready is your maintenance data for AI?

Score each question 0, 1 or 2 for your site, then add the scores. Read your band underneath.

Question	0	1	2
Does each alarm point carry one agreed name across your BMS, monitoring software and work orders?	No	Partly	Yes, documented
Does every asset that raises alarms have a unique ID in one asset register?	No	Partly	Yes, documented
Do your critical assets have continuous sensor history that covers at least one past failure or major repair?	No	Partly	Yes, documented
Does every alert type have a named owner who records how it was closed?	No	Partly	Yes, documented
Is each maintenance visit linked to an asset ID and marked planned or unplanned?	No	Partly	Yes, documented

0–3: Fix alarm names and the asset register before any vendor conversation, because a model would learn mostly from noise. 4–7: Pilot on your best-recorded assets only, and fix the lowest-scoring question in parallel. 8–10: Ask vendors to test their model on your own history and report its false-alarm rate.

What to do next

This scorecard stops at your own records. It shows whether your data can teach a model, while judging a vendor’s model needs that vendor’s validation on comparable sites, and Uptime notes how few operators publish results (Uptime Institute, 2026).

Cleaning the alarm log and the maintenance history first is what turns an AI alert into a warning worth acting on. This week, export the last 90 days of alarms and count how many different names each critical asset produces.