Consider a hypothetical AI-assisted billing explanation capability that performs well in its business demonstration. Customer-service representatives receive clear summaries of usage, rate components, and prior bills, and the functional sponsor wants it in production before the next peak billing period.
The technology team inherits a different set of questions. The capability needs approved read access to CIS billing data, a service account cleared by identity management, configuration that keeps pace with tariff changes, and a support handoff for the hours when the contact center is busiest. Each of these obligations continues long after the demonstration ends.
This is the portfolio decision at the center of technology-led modular AI adoption. Utilities need to weigh what a capability contributes against what the estate must maintain because of it, since the second capability, and the tenth, will inherit choices made for the first.
Modular AI within the utility technology estate
Modular AI places bounded capabilities around existing systems, each tied to a defined business purpose, on top of technical services that several capabilities can share. For utility IT modernization, the distinction matters because a capability that looks self-contained to its business sponsor may depend on components other teams also rely on. Tracing where the illustrative billing explanation capability runs, and what it calls, makes those relationships visible.
Domain capabilities and shared services
The business capability is the AI-generated billing explanation delivered to a representative. Beneath it sit models, retrieval services, integrations, identity controls, and hosting infrastructure.
An AI-assisted outage-communication capability may serve an entirely different function and still depend on the same identity service, model access, and logging. Packaging each capability independently does not make those layers independent, so a portfolio view has to look below the capability to the services it shares.
Relationships with existing core systems
CIS remains the system of record for billing, while ERP, EAM, OMS, and meter-data applications keep the functions already assigned to them. Modular capabilities operate as bounded capabilities around existing systems, reading approved data and returning outputs to people or workflows without assuming the transactional role of those platforms.
A capability can retrieve permitted context or prepare a recommendation. It should not change a billing transaction, customer status, or work order unless the workflow, approvals, and source-system behavior for that action are already defined.
Enterprise IT and operational boundaries
Enterprise and operational environments carry different availability, security, and change-management requirements. The illustrative capability operates entirely in the enterprise IT domain. Operational control systems that manage grid assets remain external to the AI portfolio, and a capability supporting customer or back-office work should have no path into them.
Stating this boundary early simplifies security review and keeps scope from drifting as capabilities accumulate. With placement settled, the capability can be judged against the priorities that govern the rest of the technology estate.
Technology priorities for modular AI adoption
The illustrative capability’s first real test within incremental modernization will likely come from an application change rather than a model failure. A scheduled CIS upgrade or a change to the identity platform can alter the interfaces it depends on. Three priorities determine whether the utility AI capability portfolio absorbs such changes predictably.
Compatibility with utility applications
Compatibility requires evidence that the interface, version, identity configuration, performance behavior, and support process work under the utility’s own conditions.
Each capability should document the application versions, interfaces, and permissions it assumes, so planned upgrades can be tested against it before they reach production.
Reuse across functional deployments
Reuse counts only when a later deployment demonstrably avoids duplicated implementation or support work. A shared connector that still needs separate testing for each capability delivers less than it appears to, which is why reuse across subsequent deployments should be measured rather than assumed.
Visibility into dependencies and costs
Delivery cost is only the first line of the budget. Continuing operating expenditure, including usage charges, monitoring, evaluation, and support effort, belongs in the same view from the start.
AI capabilities for utility technology work
Investigating an application change is itself work that AI can assist. The applications below are potential AI-assisted technology use cases across utility functions, each with distinct inputs, outputs, and validation requirements. None of them should make production changes on their own.
AI-assisted application dependency analysis
The inputs are approved application inventories, interface documentation, and integration logs. AI proposes candidate relationships, such as which customer-service applications consume a given CIS interface or which EAM integrations draw on the same asset data.
The output is a provisional dependency map. Application owners confirm each relationship before it informs planning, and unconfirmed relationships stay labeled as candidates, since configuration-specific dependencies, scheduled exchanges, and manual workarounds often escape automated analysis.
AI-assisted integration troubleshooting
When a meter-data feed into billing fails or an EAM work-order integration stalls, AI can summarize permitted diagnostic data and suggest investigation paths in order of likelihood.
The output is a starting point for the integration team rather than a confirmed root cause. Any explanation still has to be checked against diagnostic evidence and source-system status before a change is made. Diagnostic access stays limited to data the capability is approved to read.
AI-assisted technical knowledge retrieval
Interface specifications, runbooks, service tickets, and change documentation are often spread across repositories. AI-assisted retrieval returns relevant passages with source references, so engineers can verify the original document before acting.
Retrieval must respect existing access restrictions. A document an engineer cannot open directly should never surface through the capability.
AI-assisted change impact assessment
Before a CIS patch, AI can combine documented dependencies with the change description to suggest affected interfaces and a proposed regression-test scope. A change to customer account data, for example, may touch interfaces used by billing, contact-center, digital, and reporting workflows. The test lead approves the final scope.
The quality of each suggestion depends on how current the dependency documentation is. That reliance on shared, well-maintained inputs leads directly to the services every capability draws on.
Shared services across the AI portfolio
When a second capability is added, the same dependencies tend to recur: data access, model connections, monitoring, and configuration. Sharing these services can reduce duplicated work, but it also concentrates responsibility. AI lifecycle management at the portfolio level depends on treating each shared service as an owned component with its own change process.
Approved data access and identity
Shared access infrastructure provides consistent authentication, authorization, and logging. It should never become unrestricted access to utility data.
Each capability retains its own approved scope. The billing explanation capability reads billing and interaction data, while a dependency analysis capability reads technical inventories, even when both use the same access layer. One workflow’s approved access should never become an assumption for another.
Model access and orchestration
A shared service can manage model selection, routing, and execution coordination across capabilities. Orchestration can support coordination across connected utility workflows while ownership of each workflow stays with the function that uses its outputs. A shared service earns its place by meeting a repeated technical need with clear operating ownership.
Monitoring and performance evaluation
Technical availability is necessary but insufficient. Monitoring should also track whether AI outputs remain accurate and whether representatives, engineers, and analysts find them useful.
A model can be available while a source system is delayed or a retrieval source has gone out of date. A capability that stays available but is routinely overridden consumes support without contributing value, and portfolio review should connect those signals to remediation, continued operation, or retirement.
Configuration and version management
Configuration covers more than prompts. Source selection, access policy, routing behavior, thresholds, evaluation criteria, and model versions all change over time, and each change to a shared component should be versioned and regression tested against every capability that depends on it.
Shared standards help, but each change still needs validation in the context where it will run. That testing obligation grows with each addition, which is where reuse begins to reach its limits.
When does modularity add unnecessary complexity?
A utility can reach a point where it maintains far more components than it planned. Each deployment made sense on its own, yet the estate now carries overlapping services and dependencies that nobody has mapped as a whole.
Duplicated services and overlapping capabilities
Separate teams may acquire their own retrieval services, monitoring tools, or competing versions of the same summarization capability. Each duplicate adds support, security review, and renewal obligations without adding distinct value.
Shared dependencies and failure propagation
The opposite risk in modular and monolithic modernization also applies. When several capabilities rely on one retrieval or identity service, a failure there affects all of them at once, including the contact center during peak call volume.
Vendor constraints and exit costs
Data export alone rarely makes a capability portable. Configurations, integration logic, prompts, and evaluation assets can be difficult to move.
For a narrow, self-contained task, a native feature in an existing application may be the more supportable choice. It adds no new interfaces, and its support path is already established.
Evidence for evaluating modular AI suppliers
Before the illustrative capability is approved for production, it should demonstrate how it behaves under the conditions the utility actually operates in. The five portfolio criteria translate into specific evidence requests, extending the evidence required for production readiness from a single deployment to the portfolio as a whole.
| Criterion | Evidence to request |
| Operational contribution | Defined workflow, baseline, intended improvement, validation method, and accountable owner |
| Compatibility and dependencies | Supported interfaces, permissions, version assumptions, representative testing, and known limits |
| Supportability and recovery | Support ownership, diagnostic access, degraded-mode behavior, escalation path, and tested recovery procedures |
| Lifecycle cost | Implementation, integration maintenance, usage, monitoring, testing, evaluation, support, and retirement costs |
| Portability and retirement | Exportable assets, contractual restrictions, dependency removal, and transition responsibilities |
Utilities should request actual documentation and test results. Observed performance, contractual commitments, and proposed targets carry different weight, and evaluation teams should keep them separate.
Gigawatt, which provides modular AI capabilities that operate around existing CIS, ERP, and EAM platforms, should be assessed against the same criteria as any other supplier.
Compatibility under realistic utility conditions
Testing should reflect events the utility will actually face: a CIS version change, a source-interface outage, or a surge in call volume after a billing cycle or storm.
Without those results, compatibility gaps surface in production, usually during the periods when the contact center can least absorb an outage.
Support ownership and recovery procedures
Evidence should show who diagnoses which failures, what diagnostic access the utility retains, how the capability behaves in degraded mode, and whether recovery procedures have been tested.
In the billing explanation example, representatives should be able to return to existing CIS screens and approved reference material if the capability is unavailable. That fallback belongs in the workflow design from the start.
When support evidence is missing, a multi-party outage can stall while supplier and utility teams work out responsibility.
Data and configuration portability
Portability evidence covers exportable assets, contract restrictions, dependency removal, and transition responsibilities. Configurations and evaluation assets matter as much as the underlying data.
Without it, exit costs remain unknown, which weakens the utility’s position at renewal and makes retirement harder to justify.
Total cost across the lifecycle
Lifecycle cost should include implementation, integration maintenance, usage, monitoring, evaluation, support, and eventual retirement.
Proposals that price only implementation shift the remaining cost into future operating budgets. There it competes with other obligations under review by utility leadership and, where relevant, commission scrutiny of technology spending.
Expansion decisions across the technology portfolio
The evaluation framework supports four decisions for each proposed or existing capability: expand, defer, consolidate, or retire. Treating another deployment as low-cost expansion requires evidence that reuse and support capacity already exist. Each decision should be revisited as the portfolio changes.
- Business value and technical readiness: Expand when a defined workflow has a baseline and its dependencies have passed representative testing.
- Capacity for ongoing support: Defer when support teams cannot absorb another capability without diluting coverage for existing ones.
- Reuse demonstrated by subsequent deployments: Count reuse only after a second deployment has avoided duplicated work.
- Consolidation and retirement decisions: Consolidate overlapping capabilities, and retire those whose contribution no longer justifies their dependencies and cost, preserving the knowledge that remaining workflows still need.
A disciplined portfolio does not always grow. It concentrates investment where the utility can sustain the capability, keeps dependencies visible, and removes complexity that no longer supports a defined workflow.
Sustaining the portfolio with modular AI for utility technology
Each addition to a modular AI for utility technology portfolio should arrive with compatibility evidence, a lifecycle cost the utility can defend, and a known path to consolidation or retirement. That discipline keeps expansion tied to work the utility can sustain, rather than allowing support obligations and dependencies to accumulate outside a clear portfolio plan.
Over time, the portfolio should make technology decisions easier. Shared services should reduce repeated work where reuse is proven. Individual capabilities should retain the boundaries, fallback procedures, and ownership required by the workflows they support. When a capability no longer contributes enough to justify its dependencies, cost, or operating attention, retirement can be as valuable as expansion.
Which of your utility’s workflows would best expose its technology dependencies? Book a Gigawatt demo to evaluate that workflow, its dependencies, and its support requirements.