A utility’s warehouse or lakehouse may already contain much of the data an AI capability needs. CIS account data, meter reads, billing history, and service orders may support reporting, while their suitability for a particular AI capability still needs assessment.
An AI capability asks a narrower question of the same data. To explain a bill correctly, it needs to know which meter served the premise during the billing period and which tariff version applied on each day of it. To rank open service orders, it needs their status as of this morning. Availability settles neither requirement.
How modular AI and utility data platforms divide that work determines what the existing investment can carry, what each new capability has to supply for itself, and what must be repaired before an output reaches a customer, an analyst, or a crew.
How do modular AI and utility data platforms work together?
Three kinds of components sit along the path from source data to an operational action: shared data services, domain-specific AI capabilities, and the operational systems that execute transactions. The initial path runs from operational source systems to shared data services, then to a domain-specific AI capability, an approved AI-assisted workflow, and a measured outcome. Modular AI integration holds up when the interfaces between these components are explicit, so that each one can change without quietly altering what the others depend on.
| Component | Responsible for | Outside its responsibility |
| Shared data services | Data access, entity mappings, definitions, lineage, permissions, freshness monitoring | Deciding what an output means for a customer, analyst, or crew |
| Domain-specific AI capability | Models, domain logic, and testing against its own acceptance criteria | Executing transactions in systems of record |
| Operational systems (CIS, meter data management, billing, work management) | Approved transactions and system-of-record data | Authorizing AI actions outside approved controls |
Shared data services
A warehouse, lakehouse, or integration platform may support some of these services; the utility should assess which are available and which require additional integration. Its purpose is to make governed data available through the shared foundation supporting AI applications so that each team is spared from rebuilding the same pipelines.
Domain-specific AI capabilities
An AI capability applies models and domain logic to one operating question, such as explaining a bill or ranking open service orders. The architecture governing how modules connect to shared services determines how much of each capability has to be built from scratch and how much it can consume.
Connections to operational systems
CIS, meter data management, billing, and work management keep their application responsibilities. Workflow actions return through approved connections to operational applications that carry each system’s own validation rules. A read connection to the data platform grants no permission to change a bill, an account, or a work order.
What makes platform data usable for an AI capability?
Data can be present, current, and well documented and still be unsuitable for a particular decision. Suitability depends on what the capability does with the data, who sees the output, and what happens when an input is missing. Each condition below is tested one capability at a time.
Consistent customer and asset identifiers
Utility data describes several entities that are easy to collapse into one. An account holder is a party with a financial relationship to the utility. A premise is a service location. A service agreement ties the two to a rate and a commodity, and a meter measures consumption at that premise until it is exchanged, sometimes partway through a billing period.
A bill explanation that joins the account directly to meter, skipping premise and service agreement, can attribute a removed meter’s reads to the current bill or ignore a move-in date. The explanation would read fluently and still be wrong.
Utility data interoperability, at this level, requires every consuming capability to resolve these relationships the same way, with effective dates attached to each link.
Business definitions and context
Raw values rarely carry their own meaning. Consumption may arrive as register readings that require a multiplier, and demand values depend on the interval length used to calculate them.
Tariff logic adds another layer. A rate change effective mid-cycle may require proration, depending on the applicable tariff and billing rules. A capability explaining that bill needs the rate versions and calculation rules used for the billed period, rather than only the schedule published today.
Centralized storage leaves these semantics unresolved on its own. Definitions have to travel with the data, have a named owner in billing or rates, and carry a version whenever they change. Subject matter experts in billing should confirm those meanings with the data team, because technical consistency cannot show whether a field supports the interpretation a customer will hear.
Data quality and freshness
Quality thresholds depend on the use. A billing anomaly model trained on history can tolerate some estimated reads if they are flagged as estimates. A bill explanation offered to a customer during a call cannot present an estimated read as an actual one.
Freshness follows the same logic. Overnight loads may be adequate for explaining last month’s bill and inadequate for prioritizing service orders that arrived this morning. The requirement should come from the decision itself, and each input’s update interval should match that requirement.
Missing inputs need explicit handling as well. A capability should never read absent payment data as no payment, or a missing status update as unfinished work. Depending on the task, the right response may be to request a refresh, restrict the output, or route the work to a person.
Access permissions and lineage
Permitted use belongs with the data. Payment history may be appropriate for a contact center capability and inappropriate for an analytics model, and some customer data is restricted by commission rules or consent requirements. Keeping decisions about ownership and permitted use of utility data with accountable business owners prevents each new capability from setting its own access terms.
Lineage serves a different purpose. When a customer disputes an explanation, the utility needs to trace it back to the reads, tariff version, and billing determinants it used, and show that those matched the issued bill.
The illustrative readiness matrix below captures these conditions for an AI-assisted bill explanation.
| Input | Source | Owner | Freshness | Quality threshold | Permitted use | Failure response |
| Account, premise, service agreement, and meter relationships | CIS | Customer data owner | Reflects move-ins and meter exchanges through bill date | Complete and effective-dated for the billing period | Read-only, contact center | Withhold explanation and route to the representative |
| Interval and register reads | Meter data management | Meter data team | Through bill date | Estimated reads flagged | Read-only, contact center | Label estimated values explicitly |
| Tariff version | Rates and billing configuration | Rates team | Effective-dated | Matches the version used to calculate the bill | Read-only | Stop and escalate to billing |
| Billing determinants | CIS billing | Billing operations | As of bill issue | Reconciles to the issued bill | Read-only, contact center | Stop and escalate to billing |
From shared data to utility outcomes
The same account, meter, billing, and service data can support capabilities that make very different kinds of decisions. Following that shared foundation into three hypothetical walkthroughs shows where the data stays common and where validation and workflow requirements diverge. None of the scenarios describes a specific utility deployment.
AI-assisted bill explanations
A residential customer calls about a bill noticeably higher than the previous month’s. As the representative opens the account, the AI capability draws the billing determinants, interval reads for the period, the applicable tariff versions, and any estimated reads or meter exchanges from the shared data services.
It generates a draft explanation: for instance, that an applicable rate changed during the cycle and that billed consumption increased compared with the previous period. Every statement in the draft traces to a specific value. The representative reviews it against the bill on screen and decides what to tell the customer. If a reread or adjustment is warranted, the request goes through CIS or work management as it would without AI.
Without the draft, the representative assembles the same picture from bill detail, usage history, and rate information while the customer waits. With it, the review shifts to confirming a few sourced statements. When a required input is missing, such as an unmapped meter exchange, the capability should say so and stop instead of producing a plausible explanation.
The platform supplies the mappings, reads, tariff versions, and lineage. The capability adds explanation logic, a check that each claim matches its source value, and a rule to withhold a draft when inputs are incomplete. Accuracy is measured against subject matter expert review of sampled explanations, alongside customer-service outcomes such as handle time, repeat calls, and escalations. Handle time needs careful reading: shorter calls say little if explanations grow less accurate or more customers call back about the same bill.
AI detection of billing anomalies
This capability runs before bills are released. It compares each bill against the premise’s consumption history, rate class, and similar premises, and flags patterns outside expected ranges, such as zero consumption at an occupied premise or a sudden change in a meter multiplier.
A flag marks a pattern for review. Confirmation belongs to billing analysts, who investigate and decide whether to hold, correct, or release the bill. The useful measures here are the share of flags analysts confirm, the errors found before release, and the analyst time spent per confirmed error. The team also needs a way to estimate what the model misses, and dispositions should keep confirmed errors, valid bills, and inconclusive reviews distinct, so later evaluation does not count every investigated flag as a success.
The capability reuses the same mappings and reads but needs a longer history, no customer-contact permissions, and freshness aligned with the billing cycle.
False positives carry a cost that is easy to underestimate. Each one consumes analyst time inside the window before bills release, and a model that flags too much soon gets bypassed. Thresholds are therefore an operational decision for the billing team, revisited as confirmed and dismissed flags accumulate.
AI-assisted service order prioritization
Here the capability ranks open service orders using approved criteria, such as safety conditions, regulatory response deadlines, scheduled customer appointments, and crew qualifications. It draws on the same premise and account data, plus work management status and asset information. The capability applies the criteria; operations leadership owns them and approves any change to them.
Dispatchers accept or override the recommended order, and work management continues to assign, schedule, and close the work. Turning a ranking into dispatched work depends on moving AI recommendations into operational work through the work management system’s own interfaces, with each override and its reason retained for review.
Freshness requirements are much tighter. An order received at 7:00 a.m. has to appear in the ranking before the morning’s assignments, and an order completed overnight has to drop out of it.
Useful measures include overdue eligible orders, manual reprioritization effort, and performance against service commitments. Acceptance rate is weak evidence by itself, since a planner may accept a convenient sequence that does nothing for the operating result.
| Dimension | Bill explanations | Billing anomalies | Service prioritization |
| Shared inputs | Account, premise, meter, reads, billing history | Account, premise, meter, reads, billing history | Account, premise, meter, service orders |
| AI role | Generates an explanation | Flags bills for review | Recommends priority |
| Human decision | Representative communicates with the customer | Analyst confirms or dismisses | Dispatcher assigns work |
| Freshness | Through bill date | Billing cycle | Intraday |
| Primary validation | Factual accuracy against the issued bill | Share of flags confirmed | Adherence to approved criteria |
| System that acts | CIS or work management | CIS billing | Work management |
Across the columns the first row barely changes, and every row beneath it does. An AI data platform for utilities can carry the shared inputs once, while acceptance criteria, freshness, and decision rights remain specific to each capability.
Reuse the foundation, validate each capability
Reuse lowers the cost of later capabilities only for the parts that genuinely travel between them. Separating those parts from requirements tied to a specific operating task keeps reuse from becoming an untested assumption.
| Shared across capabilities | Specific to each capability |
| Account, premise, and meter mappings | Acceptance criteria and accuracy thresholds |
| Interfaces to CIS and meter data management | Workflow integration and write-back path |
| Metadata, definitions, and lineage | Failure response when inputs are missing |
| Permission mechanism | Permitted use for this capability |
| Freshness monitoring | Freshness requirement for this decision |
Reusable mappings and data services
Built once and maintained by a named owner, the services in the left column spare each new capability from rebuilding joins that billing teams have already reconciled.
Workflow-specific acceptance criteria
Each capability still requires its own tests for accuracy, failure behavior, and operational acceptance, including missing inputs, stale data, conflicting values, and integration failures. A validated bill explanation capability says nothing about whether anomaly flags justify an analyst’s time.
Even a shared mapping can be adequate for one use and insufficient for another. The same customer-to-meter relationship may support both capabilities, while the anomaly model needs a longer history and the contact center capability needs access rights the anomaly model should never hold.
Ownership across platform and operations
Shared infrastructure creates dependencies, and dependencies carry cost. A mapping change made for one capability can alter another’s outputs, so platform owners need release coordination with every consuming team, and operational owners need a way to hold a change that would break their acceptance criteria. That coordination is ongoing work and belongs in the business case. A defect that crosses the platform, the model, and the application still needs a single named owner.
Where existing data platforms need additional capabilities
A platform built for reporting may meet some requirements of an AI capability while needing extensions for others. Each extension should answer to a named deployment requirement.
Operational latency and availability
Overnight refreshes suit trend analysis and month-end reporting. A prioritization capability working from the previous night’s load would rank orders crews have already completed and miss those received at the start of the shift.
Approved workflow actions
The utility should verify whether its analytical platform has an approved path back into CIS or work management, rather than assuming that data access includes transaction permissions. Actions belong in interfaces the system of record validates.
Feedback from completed work
Evaluation needs outcomes: whether a flagged bill was corrected, or whether a prioritized order met its deadline. The utility should assess whether its reporting pipelines return those results in a form the AI capability can use.
When should a utility strengthen the platform first?
Sequencing turns on whether a gap blocks the capability’s core decision or only limits its scope. Seven factors usually settle the question: availability of critical data, mapping quality, access controls, required latency, integration feasibility, operational ownership, and remediation cost.
Dependencies that block deployment
Some gaps cannot be worked around. If account-to-meter relationships are missing or unreliable for a meaningful share of premises, a bill explanation capability will produce confident statements that are inaccurate, and no model choice repairs that.
The blocker should be written in operational terms. “Poor data quality” cannot be assigned or tested; “billed consumption cannot be reliably tied to the applicable service period” can. The mapping then has to be corrected in the platform. Every later capability that depends on it benefits, which strengthens the argument for funding it as shared work.
Access controls can block deployment as well. If the platform cannot restrict payment history to the roles permitted to see it, the contact center capability should wait for that control rather than rely on a filter inside the application.
Targeted integration for bounded workflows
Other gaps allow a narrower start. A read-only capability that explains bills for a single rate class, connected to CIS through a controlled interface, may proceed while broader platform work continues. Read-only scope limits direct transaction changes: a representative must act through CIS to change a bill or account. Customer communications and data exposure still require validation and controls, even when the AI capability cannot write to operational systems.
The discipline involved in planning a bounded deployment applies directly here. The scope boundary, the exit criteria, and the platform service that will eventually replace the interim interface should all be documented before launch.
Costs of duplicated infrastructure
A point-to-point extract built for one capability tends to acquire a second consumer, its own mapping logic, and an owner who has since moved to other work.
Each such extract adds maintenance and creates a second version of the account-to-meter relationship that can drift from the platform’s. An interim path should carry a retirement date and a named owner from the day it is built.
| Conditions | Decision |
| Critical data available, mappings meet the acceptance threshold, permissions defined, latency adequate, operational owner named | Proceed |
| Gaps limited to a definable scope, controlled interface available, remediation funded with a date | Proceed with bounded remediation |
| Critical mappings missing or unreliable, no approved path for required actions, or no accountable owner | Resolve foundational blockers first |
Measure the value of each deployment and the shared foundation
Three measures belong in separate columns: the outcome a capability improves, the cost of delivering and maintaining it, and the reuse it actually demonstrates. Combining them obscures which one is carrying the business case.
Operational outcome baselines
Baseline the specific result before deployment, such as validated bill-explanation accuracy, repeat calls, or reviewed billing exceptions confirmed before release.
Integration and maintenance costs
Count integration effort, validation work, ongoing maintenance, and each capability’s share of shared-service costs, attributing shared savings only once across capabilities.
Evidence of reuse across modules
Track which services each new capability consumed without modification. Deployment count alone proves nothing about return, and established methods for measuring operational and financial value can combine all three measures into a funding decision.
Connect modular AI and utility data platforms around operational outcomes
The sequence that holds up begins with an operational outcome. Select the result to improve, identify the data services it depends on, validate the capability-specific requirements no shared service can supply, and measure performance before expanding.
Data-platform value then becomes demonstrable: an AI capability working inside an approved AI-assisted workflow, services the next capability consumed without rebuilding, and costs counted once.
Which of your utility’s workflows could put existing data-platform investments to work first? Assess readiness, dependencies, and outcome measures with the AI implementation framework for utilities.