AI for business starts with the data you already collect

The question we are asked most often now is some version of "where does AI fit in our business". It is a fair question and it is almost always asked backwards. AI is a way of acting on data at a scale a person cannot. If the data is thin, late or ambiguous, a model trained on it will be confidently wrong faster than a spreadsheet would have been slowly wrong.

So the useful version of the question is narrower: what do we already measure, how good is it, and what decision would we make differently if we could see it a week earlier?

Infrastructure is where this gets concrete

We build and run NordGryd IMS, our own maintenance platform for solar and power operators. It covers the unglamorous middle of that business: work orders, technicians, site maps, asset health and the tickets that connect them. That domain is a good place to think about AI because the data is physical and the consequences are countable.

An operator with sixty sites is already generating a great deal of signal. Inverter output, battery state of charge, controller faults, ambient and panel temperature, generator run hours, fuel level, door contacts, grid availability. Most of it is collected somewhere. Very little of it is anywhere a decision gets made.

What telemetry changes before any model is involved

The first return on collecting site data properly has nothing to do with AI, and it is worth saying so plainly, because it is the return that pays for the rest.

You stop finding out from the customer. A site that dropped out at two in the morning is a fact the platform can hold at two in the morning, rather than a phone call at nine. That single change compresses the response window more than any algorithm will.

The work order writes itself. When a fault code arrives attached to an asset that already has a service history, a location and a responsible technician, raising the job stops being data entry and becomes a decision. The person dispatching is choosing, not typing.

You can tell a bad site from a bad month. Reporting against a baseline turns "this site is always giving trouble" into a number somebody can act on, including the awkward case where it turns out to be the maintenance and not the hardware.

Then the model earns its place

Once telemetry is arriving continuously and is tied to assets rather than to spreadsheets, three things become possible that were not possible before. Each of them is ordinary machine learning applied to a specific decision, not a general intelligence sitting over the business.

Failure prediction. Battery degradation, inverter derating and generator wear all have signatures that appear in the data well before the failure. A model that has seen enough of them will flag the asset while it is still cheaper to service than to replace. This is the clearest financial case in the whole category, and it needs history: a model cannot learn a degradation curve from three weeks of readings.

Alarm triage. Any operator running enough sites drowns in alerts, and the usual response is to stop reading them. Ranking alarms by how likely they are to become an outage, learned from what previous alarms actually turned into, makes the queue readable again. The measure of success is not accuracy in the abstract. It is whether the first ten alerts of the morning are the right ten.

Scheduling and routing. Which technician, in what order, carrying which parts. This is an optimisation problem with real constraints, and it is one of the few places where a modest improvement compounds every single day.

Where language models actually help

Large language models are not the interesting part of this, but they have two honest uses in an operations platform.

The first is turning a question into a query. "Which sites have had more than two inverter faults this quarter and are still under warranty" is a question a manager can ask and a report nobody built. Letting somebody ask it in their own words, against data the platform already has, removes a bottleneck that has nothing to do with intelligence and everything to do with access.

The second is summarising history. A technician arriving at a site is better served by four sentences about what has gone wrong here before than by a list of nineteen closed tickets.

Both of these are useful precisely because they sit on top of structured data that is already correct. Neither of them fixes a system where the underlying records are wrong.

The order we recommend

• Instrument what you own. Get readings off the assets and into one place, with a timestamp and an asset identity you trust. Everything else depends on this and nothing else is a substitute for it.
• Fix identity before analysis. If the same inverter appears under three names across two systems, every figure downstream is quietly wrong. This is dull work and it is the work.
• Automate one decision. Not a strategy: one decision, with a person still in the loop, measured against what you were doing before.
• Keep the history. The value of today's telemetry is mostly in what it will let you learn in eighteen months. Storage is cheap and the readings you did not keep are gone.
• Then evaluate a model. By this point you will know which decision is worth improving, and you will have the data to judge whether it actually improved.

The honest caveat

Predictive maintenance is not a switch. It needs a reasonable volume of history, including failures, and an operator with a young fleet and excellent uptime has the happy problem of not having enough failures to learn from yet. In that case the right answer is to collect properly now and revisit the model later, and anybody telling you otherwise is selling something.

The same applies to the data itself. A sensor that has been reading three degrees high for a year does not announce itself. Calibration, gap handling and a clear record of what was estimated rather than measured are not details. They decide whether the output can be trusted when it matters.

Where to start

If you operate distributed infrastructure and you are considering AI, the first conversation worth having is not about models. It is about what you currently measure, how it reaches a human being, and which decision costs you the most when it is made a week late.

We are happy to have that conversation whether or not it ends with any software from us.