SAP Community Utility Voice: The Answers That Came Back

Article 10 asked the questions and promised a report. Here is the report card, room by room, including the rooms that stayed silent.

The following Utility Voice was authored by Marc Rosson, Community Connector at Utility.Community.

On November 16, New York’s electric, gas and water utilities owe their regulator a written inventory of every AI use case they run, along with the policies that govern them. The Public Service Commission ordered it on September 17 in Case 26-M-0552. Con Edison, National Grid, NYSEG, RG&E, Central Hudson, O&R, National Fuel Gas, Liberty and Veolia Water New York all have to answer, and then answer again every six months.

That is the Regulator Test from this series, asked by an actual regulator, with a due date.

In September, The Questions We Need Answered sorted roughly fifty questions from nine articles into four rooms, according to who can answer them: the room only you can answer inside your own utility, the room only SAP can answer, the room where we answer each other, and the one nobody has answered. I promised to come back in November and report what came back from San Antonio. I also promised to publish the null result if nothing did. Here it is, a few weeks early.

I scored the sixty-six numbered questions I carried to the conference against everything I could document: the conference decks, SAP’s published material, SAP’s third-quarter results and, where the decks ran out, primary sources on the web.

Eleven questions have a documented answer. Twenty-seven have a partial one. Twenty-eight have none.

The surprise is where the answers came from. I expected SAP to answer the most and utilities to answer the least. It ran the other way. Utilities that have already shipped AI answered the governance questions on their own slides: owners, policies, approval gates, registries, where the data lives. Nobody, utility or SAP, answered the questions about agents acting on operations.

The governance answers exist. They stop exactly where autonomy starts.

How I Scored It

Three rules, so you can argue with the result. Every question and its score is on the scorecard.

Answered means a dated, documented answer to the question as asked: a slide, a filing, a published page. Partial means a documented answer to part of the question, or tooling that makes an answer possible without anyone having given it. No answer means nothing that addresses it.

A session that talked about a topic does not count as an answer. A vendor blog estimating SAP’s prices does not count as an answer. I read third-party commentary on several cost questions and none of it moved a score, because none of it came from SAP.

One more thing belongs at the top rather than buried in the caveats. I asked readers to bring answers back, and I built a simple way to log them on the spot. In four days in San Antonio, not one answer was logged that way, by me or by anyone. Everything below comes from what people put on screens and on paper. That is a finding too.

Layer One: The Regulator Test Got a Deadline

The Regulator Test asks five things about any AI agent in production: who authorized it to exist, what rules govern what it should be doing, who is watching what it actually does, where it sits in your organization, and how you would shut it down.

Three of the five now have a documented utility answer. OG&E’s chief IT architect, David Kenyon, described the AI his team built during its S/4HANA program and then turned into a platform: an incident-resolution tool that has analyzed more than 15,000 incidents, and a governed delivery workspace with more than 80 projects. His responsible-design slide reads like a Regulator Test answer key:

• every tool has a clear business purpose and an accountable owner;
• the AI is governed by a named corporate cyber security policy;
• it runs contained on OG&E’s network with least access;
• people review important results, and the tools are logged and monitored.

Who authorized it, what rules govern it, who watches it: answered, on a slide, by a utility.

Two caveats keep that honest. It is one utility. And it is AI for IT delivery and support, not an agent acting on the grid or a customer account. It still matters, because it proves the questions are answerable. This was the first time I saw a utility answer them in public.

The other two questions got nothing from anyone. Where does the agent sit in your organization? No utility said. How would you shut it down? SAP describes its Agent Gateway as the runtime enforcement point for agent access policies, but I found no published way to suspend an agent, quarantine its outputs or revoke its access as a security action. Nobody described a kill switch. I expect that to arrive in future versions of SAP LeanIX and SAP AI Agent Hub, but SAP has not published it yet.

Then the regulator answered in a way the series did not expect. New York is not asking about cost. It is asking what you run and how you govern it. The filings due November 16 will be the first written answers to the Regulator Test from real utilities to a real regulator. I will not guess at their contents, but I will read them when they are public.

Layer Two: The Room We Expected to Be Silent

The room only you can answer inside your own utility was supposed to be the quiet one. In September I argued that most of the silence in this series was ours, not SAP’s.

On the evidence, I was partly wrong, and I would rather say so than soften it. Utilities documented answers to five of the twenty-four questions in this room, more than SAP fully answered in its own.

If not SAP’s governance framework, then what? Article 1 asked it. Four utilities answered with their own.

• Nexus Water published the cleanest AI governance language at the conference: confirm guiding principles and “no-fly zones,” set decision rights, “keep humans accountable — place approvals around financial, customer and policy impacts,” and “start with standard — validate standard Joule capabilities before building agents.”
• PG&E described an agent lifecycle in four verbs: register, certify, supervise, adjudicate.
• OG&E answered with the named owner, named policy and least-access design above.
• Salt River Project wrote the principle for extensions, and it carries straight over to agents: “Partners advise, SAP advises… SRP makes the final decision — every time.”

Who is accountable when an agent acts? Article 7 asked it. The utilities’ answer was unanimous: a named human. OG&E requires an accountable owner. PG&E requires a named owner and a risk tier at intake. Nexus says keep humans accountable. In every production example I found, a person approves the result, so accountability never transfers to the software.

Who approved capability thirty-one? Article 7’s capability-creep question has the best one-line answer of the year, from PG&E: “No named SME, no plugin.” New capabilities enter through a register with an owner and a risk tier. Findings from the field return to intake. “No silent behaviour drift.”

Who is accountable for AI-generated code? Article 8 asked it. PG&E’s answer is the most quotable in this report. Under the heading “Governance did not have to change,” its slide reads: “Zero SDLC gates removed, 100% of approvals human-owned, 100% of reviews human-in-the-loop.” Elsewhere in the same deck: “AI changed the drafting engine, not the control points.” OG&E went further and pointed its AI at its integrator, using it to check the specifications, code and test scripts the integrator delivered. Notice the contrast with SAP’s own custom-code migration agent, which applies high-confidence AI fixes with “human oversight only if needed.” Two defaults, one transport path. Whose default governs yours is a question worth settling in writing.

Federate, replicate or leave alone? Article 3 said this was the right first data question. Avista answered it for a greenfield S/4HANA program: Business Data Cloud for the SAP domains, Databricks for GIS, outage and ADMS data, data products shared without re-replication, and a principle on the slide, “retire, don’t replicate.” Their verdict on the two platforms was “complementary, not competing.”

That is the good news. Here is the rest of the room.

Nobody described granting an agent write access to production. Every utility answer about write access was the same: not yet, and deliberately so. PG&E keeps every approval human-owned. Nexus places approvals around anything with financial, customer or policy impact. OG&E’s line was “Keep a human in the loop and let the results earn trust.” On SAP’s side, a point raised in one San Antonio session has stayed with me: that utilities deploying Joule are finding its security cannot yet be made granular enough to let specific users use some capabilities and not others. It was described to me as all or nothing. That is a report from the room, not something I have found in SAP’s documentation, and I would welcome a correction if it is out of date. Meanwhile, SAP’s own exception-resolution agent, dated Q2 2027, starts “upon user request.”

Nobody answered for the customer an agent sees. SAP’s Utilities Customer Self-Service Agent is available now. I could not find a utility named as running it.

Nobody answered the API questions from The Audit We Already Owe. No utility reported its integration sort or its modeled 2027 consumption. One data point sharpened the question instead. PG&E’s heaviest AI-assisted S/4HANA work runs on a hyperscaler’s coding agent and an SAP-specific MCP server built by that hyperscaler, not on Joule. Is that an endorsed lane under SAP’s API policy? I have not seen anyone ask.

Nobody answered the rate case question from The Meter Is On. New York asked for an inventory, not a cost.

So the room was not silent. It answered for the AI utilities already run, in delivery and support, under human approval. It stayed silent at exactly the point where an agent would act on its own.

Layer Three: What SAP Answered, and What It Didn’t

SAP answered more than I expected, almost all of it about platform, inventory and dates. It answered almost nothing about cost per process or the operational boundary.

What is generally available today? Answered, with dates, on SAP’s own utilities roadmap slides. I covered the detail in Agents on the Slides, Migrations in the Room. In short:

• the self-service agent and the Service Cloud case-management assistant are available now;
• billing-document and asset-health agents are dated Q4 2026;
• the exception-resolution, BPEM and tariff agents are dated Q2 2027;
• billing error, bill analysis, meter-read analysis and every distributed-energy agent remain at ideation.

Field service and asset management run ahead of meter-to-cash, and several of those agents are marked as available on ECC.

How many agents are live against SAP’s year-end target? Answered. SAP’s target was more than 400 agents by the end of 2026. On its October 21 earnings call it cited about 300 agents and 40 assistants across its autonomous suite, framed as “quality over quantity,” according to the earnings-call transcript. No utility was named in any win or go-live on that call.

How will SAP build utility-specific agents? Partly answered, and more concretely than at any point in this series. SAP’s utilities slides show “Industry AI / FDE Agents,” built by forward-deployed engineers, alongside SAP’s packaged agents and customers’ own. The commercial path is:

1. a ten-week proof of concept;
2. a flat fee credited against a value-based annual subscription;
3. productization, so that one customer’s work becomes product for others.

Article 12 described where that work starts. What stays open is how the rest of us review, contribute to and export the utility ontology it produces.

Who governs agent identity and inventory? Partly answered. SAP’s AI Agent Hub reference architecture gives agents their own identities in SAP Cloud Identity Services, a registry with an owner and governance status per agent, runtime policy enforcement through the Agent Gateway, and EU AI Act risk classification. A LeanIX AI governance assistant is dated Q4 2026. What the architecture does not say is how credentials rotate, how agents are deprovisioned, or how an agent’s action is distinguished from a human’s at every hop.

What does an agent cost? Answered at the unit level, partly answered on control, and not answered where it matters most. SAP’s commercial guide, Understanding SAP’s Business AI Commercial Model (published October 2026), sets “a fixed, two-tiered pricing structure” for Joule Agent actions: 0.02 AI Units for a Standard action, 0.05 for an Advanced one. AI Units are bought annually into one shared pool, and “unused AI Units expire after 12 months.” An action is “a single step executed by an AI agent as it completes a task—for example, calling a service, triggering a workflow, or generating a response,” and “a task may require multiple actions depending on complexity.”

That pricing moved while I was writing. When I first read the guide in early October, it described one price per action for 2026. The October edition, still labeled version 10.2026, has two tiers, and it does not say what makes an action Advanced or who decides. That is now the first question I would put to an account team.

The guide does answer one of the six cost questions from The Meter Is On. There is no automatic hard ceiling. If you are approaching or past your purchased units, you “can proactively deactivate agents or features directly in SAP for Me”; keep running, and SAP bills the overage “under excess-use terms at the applicable AI Unit rate.” Visibility is “near-real-time.” A switch you throw by hand is a control. It is not a cap.

The rest are where they were:

• how many actions a real utility process generates;
• how retries, branches and tool calls count;
• whether consumption can be attributed to a process or cost center;
• whether an estimate can come back before an agent runs.

None of those has a published SAP answer. I found estimates from licensing advisers; I did not use them.

Is n8n generally available inside Joule Studio? Not as of this writing. It was a third-quarter target.

Master data. SAP now calls MDG and Reltio complementary, and says Reltio’s matching is coming very soon. Which one owns business partner, premise, device and connection object for an IS-U utility is still unanswered.

Layer Four: Can We Answer Each Other?

Article 10 ended on that question. The honest answer is: in presentations, partly; in numbers, not yet.

The venues exist now and are documented. The IBM AI Lighthouse Council launched in June with seven utility members and, by IBM’s own count for the third quarter, two proofs of value in flight. It is the actual scale of agentic AI at utilities right now. SAP’s Service Cloud team reported 64 customer improvement requests delivered in a single quarter, and its advice to utilities was to vote together. Southern California Edison put it on a slide: “Take advantage of the opportunity we have as a public utility to benchmark!”

PG&E’s register-certify-supervise-adjudicate lifecycle is the capability registry Article 7 asked for, built. Whether it survives a real backlog is the next question. Avista showed why the registry is harder than it looks: an estate of roughly 1,500 applications, “almost none of it documented in processes.” You cannot inventory AI on applications and processes you cannot see, which is exactly what New York is now asking for.

What did not come back is anything numeric. No utility shared a negotiated consumption cap and what it cost elsewhere in the agreement. No one reported taking the accountability question to internal audit. No one reported asking a vendor whether its standard is cited in the Official Journal. If you have numbers, even rough ones, this is still the room that needs them.

Layer Five: The Room Nobody Answered, and the Regulator Who Walked In

The question this series has asked most often is where agent authority stops at the operational-technology boundary: SCADA, ADMS, OMS. It appeared in seven of ten articles. SAP has not answered it.

What changed is that the boundary got crowded.

SAP is moving toward it. On SAP’s own utilities slides, SCADA inputs, sensor telemetry and DER performance are “customer-managed data products,” meaning your job to bring in. The distributed-energy agents are all at ideation. The utility agent roadmap has no grid-operations agents with dates. Meanwhile the lighthouse customer’s own Utility Canvas puts grid operations on the same page as meter-to-cash.

The working control-room example is not SAP’s. CAISO’s outage-management AI, built on OATI’s platform, reviews more than 500 next-day outage requests in under eight minutes each night. Daily processing fell from six hours to thirty minutes. Operators keep final decision authority and the AI is advisory. That is a production answer to where authority stops: advisory below the line, human above it.

And then the regulator walked in. On October 13, FERC staff published Lessons Learned from Commission-Led CIP Reliability Audits. It contains a full section on AI tools, which the report calls “super intelligence (SI) tools” and illustrates with ChatGPT, Google Gemini and Microsoft 365 Copilot. Audit staff “observed increased adoption of SI tools across registered entities’ CIP-networked environments.” The report says the CIP standards “do not explicitly allow or prohibit the use of SI tools,” and it warns that their growing sophistication “may enable these tools to perform actions that mimic user behavior, increasing the difficulty of distinguishing legitimate activity from malicious use.”

Then it does what the series asked SAP to do in Articles 2 and 7. It maps AI onto CIP, requirement by requirement:

• grant, verify and revoke the access these tools facilitate under CIP-004;
• understand and monitor their communications outside the electronic security perimeter under CIP-005;
• inventory them as generic service accounts under CIP-007;
• limit their access to BES Cyber System Information under CIP-011;
• assess AI products from vendors in your CIP-013 supply-chain plan, using NIST’s AI Risk Management Framework.

It also tells entities to consider the business need for deploying these tools inside a CIP-networked environment at all.

It is a staff report, and it says plainly that it is not binding on the Commission. It does not mention agents by name or SAP at all. But it is the first CIP mapping for AI I have seen from a regulator, and it arrived from the regulator’s side of the table rather than the vendor’s. The vendor mapping, SAP’s Agent Gateway, Agent Hub and identity services set against those five requirements, is still missing.

One more date belongs in this layer. On October 14, the day after FERC’s report, the European Commission cited EN 18286, the AI quality-management standard, in the Official Journal. It is the first harmonised standard under the AI Act. Europe Certifies the Artifact asked vendors what their plan was for the day that happened. The day has happened. I have not seen SAP’s answer.

Put the three dates together: New York’s order on September 17, FERC’s staff report on October 13, the Official Journal on October 14. In four weeks, two North American regulators and the European Commission told utilities what they expect of AI. Each one landed on the questions this series has been asking.

Honest Caveats

The logging failed, mine included. Not one answer was logged on the spot in San Antonio. The answers in this report came from slides and published documents, not from anyone bringing an answer back to the series. That makes the report more defensible and less personal than I hoped.

Slides are not conversations. The most candid things at any conference are said in hallways. This report scores what was put on screen or on paper. One panel on secure AI, with SAP NS2, EPRI and Dominion, published only its questions, including “Where should humans remain in the loop?” The answers were in the room, and I cannot score them.

Utility answers have a scope. The answers in Layers One and Two govern AI in project delivery and IT support. That is real, and it is not the same as an agent posting to a customer account or touching a switching order. Read “answered” as answered for that scope.

One working draft. One utility deck I quote was still a working draft, with placeholders and savings figures its own authors flagged as needing reconciliation. I have quoted its governance language, not its percentages.

Regulatory weight. FERC’s report is staff guidance, not a Commission order. New York’s filings are not due until November 16. California’s human-in-the-loop bill for utility AI, SB 1011, passed a Senate committee in May and was then moved to the inactive file at its author’s request. It is not law.

Earnings-call quotes come from a published transcript of the call, not from SAP’s own webcast.

My own involvement. I served as a strategic content advisor to ASUG for the conference, moderated one session, and work with SAP and its partners in ways I listed in full in Agents on the Slides, Migrations in the Room. Weigh what I say about SAP with that in mind.

What We Still Need to Influence

• Map the agent stack to CIP. FERC staff has now written down the CIP requirements AI tools touch. SAP should publish how Agent Gateway, Agent Hub and Cloud Identity Services satisfy CIP-004, -005, -007, -011 and -013 for agents operating in or near a CIP environment.
• Draw the operational boundary in product. Say where SAP agent authority stops relative to SCADA, ADMS and OMS, and give utilities a hard deny they author themselves.
• Make agents distinguishable from people. FERC names the risk. Show how every agent action is identifiable as an agent action at every hop, in the audit trail a utility hands its auditor.
• Give us authorization we can describe to a regulator. Per-role, per-capability scoping for Joule and agents, documented, so it can appear in a New York filing as a control.
• Count the actions. Publish which actions are Advanced, how many actions a real utility process generates, how retries and tool calls count, and how consumption is attributed to a process before we are asked to put it in a rate case.
• State a position on EN 18286. It is cited now. Tell utilities what that does and does not cover in SAP’s AI offerings.
• Govern the utility ontology in the open. If one customer’s work becomes product for all of us, publish how public power, co-ops, water and gas-only utilities review it and contribute to it.

The Webinar We Promised

Article 10, and the posts that went with it, promised a November wrap-up webinar alongside this report. We are not holding it in November, and I owe you the reason.

A webinar that walks through this scorecard would be more slides. What this community needs is a utility that has an agent in production on SAP, able to talk directly about the process of getting there and the value it delivered. We will hold the Autonomous Enterprise webinar when that is possible, and not before. If your utility is close, I would like to hear from you.

Your Turn

New York’s utilities file their answers on November 16. FERC has told every registered entity what it expects. The rest of us can answer the same questions now, before we are asked.

• Pick one question from Layer One and answer it for one AI tool you already run. Who owns it, what policy governs it, who watches it. If it takes more than a page, that is useful to know.
• Put FERC’s five requirements against your AI inventory. If you have no inventory, that is your first item.
• Bring a number. A consumption figure, a cap you negotiated, a count of actions for one process. Anonymous is fine. This is the room that is still empty.
• Tell me what I scored wrong. If you answered a question in San Antonio and it is not in this report, I want to correct the record.

Find me on Utility.Community, or reply here.