Data readiness as a make-or-break factor

3. Integration: whether meter, SCADA, GIS (Geographic Information System, which maps grid assets spatially), and CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition → (Customer Relationship ManagementCustomer Relationship ManagementCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →) data can actually be joined on a common asset ID.

A vendor's forecasting model trained on clean, 15-minute AMI data with under 2% missing reads will outperform the same model fed monthly reads with 15% gaps, regardless of whether it's a gradient-boosted tree or a neural network. Utility ML teams often see this reflected in feature importance dropping sharply when data completeness falls, which is exactly what happened in the underperforming pilot above.

The US Department of Energy's Grid Modernization Lab Consortium has documented this repeatedly: pilots that fail attribute it to "AI limitations" in post-mortems, but forensic review usually finds data latency, missing meter pings, or unresolved asset ID mismatches as the root cause.

The two-utility comparison, unpacked

Utility A (successful pilot):

• AMI rollout completed years earlier, 15-minute interval data, over 98% meter ping reliability
• SCADA and AMI data joined via a common asset registry
• Historical outage logs cleaned and standardized before the pilot started

Utility B (failed pilot):

• Mixed meter fleet: some AMI, some older AMR (Automated Meter Reading, one-way communication, lower frequency) meters still being phased in
• SCADA data siloed in a separate system with no shared asset key
• Outage logs entered manually by field crews with inconsistent formatting

Utility B's model wasn't wrong. It was starved. The lesson generalizes: before evaluating any AI vendor, audit your own data estate first.

A practical data-readiness checklist

Before greenlighting a pilot, ask:

• Granularity: What's the read interval? Monthly billing data cannot support real-time load forecasting or fast outage detection, only AMI-level interval data can.
• Completeness: What percentage of meters report reliably? Below roughly 90-95% ping reliability, most vendors will tell you results degrade sharply, though the exact threshold varies by use case.
• Latency: Is data available in near-real time, or does it arrive in batch uploads hours or days later? Outage prediction needs the former.
• Asset linkage: Can a meter reading be joined to a specific transformertransformerA Transformer is a neural network architecture that uses self-attention to process sequences in parallel, powering most modern language and generative AI models.View full definition →, feeder, or substation in your GIS? Without this, root-cause analytics cannot localize problems.
• Historical depth: Do you have at least 12 to 24 months of clean historical data to train and validate a model against seasonal patterns?

A simple worked illustration

Say a utility wants to estimate potential savings from an AI-driven loss-detection tool that flags likely meter tampering or non-technical losses.

Assume (illustrative, not vendor-specific):

• Annual distribution revenue: $200 million
• Estimated non-technical losses: 3% of revenue = $6 million (loss rates vary widely by utility and country; US utilities typically report lower rates than some emerging markets, this is a simplified example)
• Vendor claims the tool can recover 30% of detected losses in year one

Naive expected recovery: $6M x 30% = $1.8 million.

But that 30% figure assumes clean, granular AMI data feeding the model. If only 60% of the service territory has AMI coverage (the rest still on manual read AMR meters), the realistic addressable base shrinks:

$6M x 60% (AMI coverage) x 30% (recovery rate) = $1.08 million.

That's a 40% haircut on the business case, driven entirely by metering infrastructure, not by anything the AI vendor controls. This is the calculation utilities routinely skip in ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.View full definition → (Return on InvestmentReturn on InvestmentReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.View full definition →) projections, and it is the single most common reason pilots underdeliver against vendor pitch decks.

What good data infrastructure looks like in practice

A minimal, illustrative schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → for joining meter and SCADA data around a common asset key:

The asset_id column is the linchpin. Without it, meter-level anomalies can never be traced back to a specific feeder or transformertransformerA Transformer is a neural network architecture that uses self-attention to process sequences in parallel, powering most modern language and generative AI models.View full definition → for root-cause diagnosis. This join is frequently the single biggest integration cost in a pilot, larger than licensing the AI software itself.

Regulatory and standards context

In the US, data granularity requirements are shaped indirectly through state Public Utility Commission (PUC) rate cases that approve AMI investment recovery, not through a single federal AI mandate. In Europe, the EU's Clean Energy Package pushed member states toward near-universal smart meter rollout, with countries like Italy and Sweden reaching high AMI penetration years ago (exact percentages vary by country and year, treat as estimates), while others lag. This uneven baseline means the same AI vendor pitching across US and EU markets faces wildly different data starting points, which should directly shape pilot scope and expected timelines.

Evaluating vendors against your actual data maturity

When a vendor demos results from their "reference customer," ask specifically:

• What was that customer's AMI coverage percentage?
• What ping reliability and read interval did the training data have?
• Will they run a data-readiness audit on your systems before quoting expected performance?

A vendor unwilling to caveat their performance claims against your data maturity is a red flag. Reputable ones (players like Itron, Landis+Gyr, and Oracle Utilities in the meter-analytics space) increasingly build a data-quality assessment phase into the pilot contract itself, precisely because this gap has burned so many prior deployments.

Key Takeaways

• Data readiness, not algorithm sophistication, is the primary determinant of AI pilot success in utilities. Audit granularity, completeness, latency, and asset linkage before evaluating vendors.
• AMI coverage gaps directly shrink realistic ROI. Build coverage percentage into your savings calculations, not just the vendor's headline recovery rate.
• The asset ID join between meter, SCADA, and GIS data is usually the hardest and most expensive integration step, often costing more than the AI software license itself.
• Regulatory context differs sharply between US (state-by-state PUC-driven AMI rollout) and EU (Clean Energy Package-driven near-universal smart metering), so pilot expectations should be calibrated to local metering maturity.
• Demand vendor transparency: ask for the data conditions behind any reference-customer result, and treat unqualified performance claims skeptically.