The second AI deployment tests the architecture more thoroughly than the first. A billing capability and a field planning capability may both need account, meter, and work order data, but for different decisions and under different permissions. If each team rebuilds access and rules independently, adding another capability multiplies dependencies instead of extending a shared foundation.
The challenge sits at the center of modular AI architecture for utilities. Separate AI capabilities are only as coherent as the architecture connecting them: the data they draw from, the intelligence services they share, the workflows they act within, and the boundaries they keep with ERP, CIS, and operational systems.
To see how the design works, follow the shared services from utility data into AI-assisted workflows and across six functions. The tradeoffs and review criteria then show where modularity needs deliberate coordination.
The structure of modular AI architecture
Modularity in utility AI describes a relationship among components, and the ability to deploy capabilities separately is only its most visible feature. The architecture decides which services every function reuses, which logic belongs to a single workflow, and where AI stops and a system of record takes over.
Shared services and distinct capabilities
Shared services establish common patterns for governed data access, intelligence services for models and business logic, identity and permissions, and monitoring. Distinct capabilities are the functional workflows built on top of them, such as billing validation or work prioritization, each with its own rules, users, and measures of success.
Boundaries between modules and core systems
Each module also needs an explicit boundary with the systems that remain authoritative. CIS remains authoritative for the customer account, ERP for the financial transactions it manages, and work management for its work orders.
A module reads from and writes back to those systems through defined interfaces. That separation helps the utility change or retire a capability while preserving the transaction boundary it depends on.
Utility data across architectural boundaries
Most AI-assisted workflows need data that lives in several places. A single billing inquiry can touch the customer account in CIS, interval reads from the meter data platform, a field order from work management, and a PDF of prior correspondence. The architecture has to assemble that context without creating an unmanaged copy of each source.
Approved sources and data ownership
The first rule is that each data element comes from an approved source with a named owner. Customer service may consume billing data, but the billing team still decides what the data means and when it is correct.
Clear lines of data ownership and governance across utility systems allow a shared service to expose data to several modules without each module reinterpreting it.
Structured and unstructured data
Utility work depends on more than tables. Rate schedules, inspection photos, interconnection documents, call transcripts, and correspondence often carry the context a recommendation needs.
An architecture that handles only relational data forces AI to reason from partial information, so the data layer must support documents, images, and voice alongside interval and transactional data. Access alone does not make a document authoritative. The architecture still has to reconcile conflicting inputs and trace each answer to the information behind it.
Integration with systems of record
The data layer connects to systems of record rather than replacing them. In practice, a shared data layer that spans existing systems gives modules governed access to current context, while updates flow back through each source system’s own interfaces and validation rules.
That design keeps a single authoritative version of each transaction, even when several modules read from it, and it makes both the read path and the write path visible to operators and reviewers.
AI within utility workflows
Data access only matters once it supports a decision. In a well-designed workflow, AI contributes a specific, bounded step, while the surrounding rules, approvals, and system actions stay explicit. Tracing one example makes those boundaries visible.
AI recommendations and business rules
Consider a high-bill inquiry. An AI capability reviews the account’s interval data, recent estimated reads, and rate changes, then recommends a likely explanation and whether a meter reread is warranted. It never adjusts a charge on its own because a generated explanation sounds plausible.
Business rules then apply the utility’s own policy: jurisdictional requirements for disputed bills, eligibility for payment arrangements, and limits on the adjustments a representative can offer. The AI recommendation informs the decision, and the rules define which decisions are permissible.
Human approval and workflow execution
The representative reviews the recommendation, the supporting data, and the options the rules allow. If a reread is appropriate, the representative approves it, and the workflow creates the service order in work management through its standard interface.
Decision rights stay with the designated role, and orchestration across the systems involved handles sequencing so the representative does not rekey the request.
Evidence of completed actions
The final step is evidence. The architecture should retain the data the AI used, what it recommended, who approved which option, and which system actions followed.
That audit trail lets supervisors review quality, helps compliance teams answer commission inquiries, and shows whether the AI-assisted workflow shortened resolution time or reduced repeat calls against baseline.
The same pattern applies across the utility. What changes is the data, the rules, and the consequences of a wrong decision.
Shared capabilities across utility functions
Reuse is the practical test of a modular design. When functions draw on the same governed data access, intelligence, and audit services, each new capability starts from an established foundation.
The value of each function still depends on what varies at its boundary: the inputs it trusts, the decisions AI may inform, and the system that must act on the result.
Service: Coordinate field work and context
Field service draws on work orders, crew availability, asset history, and appointment data. An AI capability can rank open work by urgency and suggest sequencing that accounts for crew qualifications, travel, and customer commitments.
The boundary sits with dispatch. Supervisors approve schedule changes, and work management remains the system that assigns and closes orders.
The distinct implication is timing. Service recommendations lose value within hours, so the shared data layer must deliver current crew and order status, and the monitoring service must flag recommendations drawn from stale context.
Customer: Connect interactions and account context
Customer workflows depend on CIS account data, billing and payment history, outage status, and prior calls. An AI capability can detect the reason for a call and assemble relevant context before the representative responds, or draft a proactive outage or billing notice for review.
What changes here is exposure. Customer-facing outputs carry regulatory and reputational consequences, so rules governing disclosures, payment options, and protected customer data must apply before anything reaches the customer.
The same shared services can support field and customer work, but customer communication requires its own review and disclosure rules.
Power: Support grid and asset decisions
Grid and asset planning relies on asset condition patterns, operational sensor data, inspection results, outage history, and weather exposure. An AI capability can identify assets whose condition and history suggest elevated failure risk and propose candidates for inspection or inclusion in the capital plan.
The boundary is decisive in this function. AI in this architecture supports planning and prioritization decisions made by engineers, and it issues no commands to grid equipment.
These recommendations also feed capital plans that commissions may scrutinize, so the evidence behind each ranking has to survive review. Linking each inspection or maintenance action back to the original signal lets the utility judge whether the rankings deserve continued trust.
Market: Coordinate market participation workflows
Utilities in wholesale markets manage scheduling submissions, settlement statements, and reconciliation against internal meter data. An AI capability can compare settlement data with internal volumes, flag discrepancies above a defined tolerance, and assemble supporting data for the analyst who decides whether to dispute a charge.
The distinct implication is deadlines. Settlement disputes follow fixed windows, so the workflow must route exceptions to the right analyst early and retain evidence of every decision.
The AI capability contributes comparison and triage. Submission and dispute decisions stay with the market operations team.
Procurement: Connect supply and project needs
Procurement workflows connect material demand from capital and maintenance plans with inventory, supplier performance, and contract terms held in ERP. An AI capability can forecast material needs from planned work and highlight suppliers whose delivery performance places a project schedule at risk.
This function shows how modules depend on each other. Procurement demand originates in service and grid plans, so shared definitions of work and asset data matter more here than anywhere else.
Purchase approvals and contract commitments still follow the utility’s delegation rules in ERP.
Revenue: Improve billing and payment workflows
Revenue workflows draw on meter reads, tariff structures, billing determinants, and payment history. An AI capability can validate bills before release, flag reads or rate applications that fall outside expected patterns, and suggest collections approaches consistent with policy.
The boundary here is financial control. Billing adjustments can have financial and regulatory consequences, so AI-flagged exceptions route to billing analysts, and CIS remains responsible for calculating and issuing the bill.
Evidence of each correction becomes part of the utility’s financial audit trail.
The tradeoffs behind modular design
Modularity carries real costs. Separating capabilities multiplies interfaces, and each interface becomes a commitment the utility must maintain as systems, models, and regulations change.
The argument for incremental capability deployment remains strong for regulated utilities, because it limits validation scope and operational risk at each step.
Integration and version management
Every module connects to some combination of CIS, ERP, meter data, work management, and document repositories. When a CIS release changes a field definition, each dependent module needs testing. When a shared intelligence service updates a model, every workflow that consumes it may behave differently.
Utilities should expect to maintain integration contracts, regression tests, and a release calendar tied to core-system changes. Adding a module always involves integration and validation work, even when shared services reduce it.
Independent deployment has limits as well. A module may be technically separable yet depend on a transaction interface whose change window another team controls.
The fair comparison weighs that recurring effort against the cost of rebuilding data access and governance separately for every function.
Shared standards versus local flexibility
Shared services only deliver reuse when functions accept common definitions for customers, premises, assets, and work. Yet each function has legitimate reasons to configure its own thresholds, rules, and review steps, and customer disclosure rules and settlement tolerances should not be forced into one template.
The design question becomes where to draw the line. A practical approach standardizes data definitions, identity, audit, and monitoring, while allowing each function to configure business rules and approval thresholds within documented limits.
Governance then determines who can change a shared standard and how dependent modules are notified before the change takes effect.
What to evaluate in an architecture review
A review is most revealing when it follows one real workflow, such as a billing inquiry, from input to completed action, then repeats the exercise for a field or procurement workflow. Differences between those paths show where shared services end and functional responsibility begins, and the questions below help a utility test both against its own systems and regulatory obligations.
System boundaries and portability
Start with ownership. For each capability, the utility should be able to name the system of record for every data element it reads or writes, the interface it uses, and the team accountable for that interface.
If a module stores its own copy of account or asset data, the review should establish how that copy is reconciled and when it expires.
Next, examine what happens when something changes or fails. Can a module be updated, paused, or retired without modifying CIS or ERP? How does it handle stale data, a failed integration, or conflicting inputs? Can the functional team configure business rules, or does each change require custom code?
The review should establish the conditions and procedures for moving workloads between environments if continuity requires it.
Portability means knowing which configurations, rules, and audit data the utility can export, and in what form.
Consistency with AI-native design principles matters here, because intelligence embedded inside governed workflows can be inspected and controlled in ways that external add-ons often cannot.
Security, monitoring, and measurable outcomes
Security review should focus on how AI reaches data. Broad external agent access into core systems creates exposure points, while governed internal access scoped by role and workflow keeps permissions narrower and auditable.
Monitoring should cover technical and operational behavior alike: data freshness, model drift, rule changes, and recommendation acceptance rates, with alerts when a module operates outside expected ranges.
A recommendation that representatives override most of the time signals a problem as clearly as a failed integration.
Each capability also needs a baseline before it expands. Resolution time, billing exceptions caught before release, inspection hit rates, or recovered settlement disputes can all serve, provided they were measured before deployment.
The review should name the owner of each measure and the system that supplies the evidence. Expansion to a new function should follow results from the previous one, with governance confirming that ownership, integration, and performance held up.
ANA connects intelligence and modular capabilities
ANA is an AI-native architecture for regulated utilities built around the relationships this article has traced. It brings intelligence, data access, and workflow execution into a shared architecture so functional capabilities can use common services while retaining their own operational rules and decisions.
Centralized Intelligence Services coordinate business logic, models, and AI agents across the architecture. This gives functional capabilities access to relevant utility rules, including tariff, billing, and jurisdiction logic, without treating each workflow as a separate intelligence project. The shared layer supports reuse; the workflow still determines how a recommendation is reviewed and acted on.
The Utility Data Fabric supplies the context those services need. ANA’s published architecture describes support for PDFs, images, JSON, voice interactions, and enterprise operational data. Bringing structured and unstructured information into an approved access path helps modules work from relevant context while CIS, ERP, and other existing systems retain responsibility for their transactions.
ANA then connects intelligence and data to execution through an intent-based model. An AI capability operates against a defined utility question, relevant rules, and a validated workflow path. That boundary matters because a useful recommendation still needs the appropriate review, approval, and system action before work is complete.
Containerized deployment adds flexibility in where ANA runs and supports operational continuity across utility environments. It does not remove the need to plan integrations, validate changes, or manage dependencies among modules.
Together, these elements explain how ANA supports incremental deployment across functions without requiring ERP or CIS replacement. The practical evaluation remains workflow-specific: which capability uses the shared services first, which system owns the resulting transaction, and what evidence shows the work improved?
How modular AI architecture connects utility functions
A modular design earns its value when shared data and intelligence services support distinct utility workflows, and each workflow keeps clear boundaries with the systems and people accountable for its decisions. Six functions can share one foundation only if the architecture makes the differences between them explicit.
The soundness of the design shows up in its handoffs: from approved data to an AI recommendation, from review to an approved action, and from completion to evidence. For a utility preparing its next architecture discussion, tracing those handoffs in one workflow shows what can be shared and what must stay local.
How do data, intelligence services, and workflows connect across your utility’s existing systems? Explore ANA’s architecture to examine the shared services and boundaries.