Your AI pilot is not blocked by technology. It is blocked by the fact that no one can name who owns the outcome.
The following Utility Voice was authored by Marc Rosson, Community Connector at Utility.Community.
Connecting an AI model to SAP takes an afternoon. Give it a service account, wire an OData call through an MCP server, and by dinner you have something that can look up a sales order, check a delivery status, pull a customer record. It works, and it demos beautifully.
Then someone asks who is accountable for what it just did, and the room goes quiet.
That silence is the actual constraint on utility AI adoption — not model quality, not integration difficulty, not budget. We have been circling this since SAP announced the Autonomous Enterprise, so let me state it plainly: the organizations that do not answer the accountability question first will not get AI into production at all. Not because someone stops them, but because the first serious audit, incident, or rate-case discovery request will, and by then the architecture will be forty tools deep.
Layer One: The Scaling Gap Is an Accountability Gap
Start with the industry data, because it contradicts the conference narrative. Eighty-eight percent of organizations report regular AI use in at least one business function — but only seven percent report fully scaled enterprise deployment, and sixty-two percent remain in experimentation or pilots. On agents, no individual business function shows more than ten percent scaling.
Read that gap carefully. It is not an access problem; everyone has access. It is not a capability problem; the demos work. What sits between pilot and production is the set of questions nobody wants to own: who authorized this, what rules govern it, who watches it, where does it sit, who answers for it when it is wrong. Utilities are not behind on AI. Everyone is stuck at the same gate.
Layer Two: Security by Ignorance Is Dead
Here is why this lands harder on us than on most industries. For thirty years, incomplete authorization models in SAP were shielded by friction: you had to know the transaction code existed, know how to navigate to it, have the training. That friction was never a control, but it behaved like one, and it quietly papered over role concepts that were never complete.
Natural language collapses that barrier. A user asks Joule a plain-English question and Joule faithfully returns whatever their roles technically permit — including everything the role concept accidentally grants. AI does not create the security hole. It industrializes discovery of the holes you already have.
And it is not one channel. Fiori spaces are generated from business roles. Enterprise Search results are authorization-trimmed. BTP applications ride on federated identity and role collections from Cloud Identity Services. Joule and agents inherit the same model wholesale. These are not four security models — they are four consumers of one model, and each new layer amplifies whatever is wrong underneath. Which makes “we will clean up roles after the Fiori project, before the AI project” architecturally incoherent. The authorization model is now an AI-readiness deliverable, and belongs on the transformation critical path rather than in a parallel security workstream.
The threat clock has stopped being patient about this. CVE-2025-31324 carried a CVSS of 10.0 and was exploited in the wild before a patch existed. Onapsis Research Labs counted fourteen HotNews notes in the first half of 2025 alone, averaging CVSS 9.8, with weaponization measured in hours. Mandiant’s M-Trends now names SAP applications a top attacker target. We are critical infrastructure, not a random victim pool.
Layer Three: The Fourth Word Changes Everything
Chandan K., an SAP RISE and BTP solution architect, put this well in a recent piece on connecting AI models to SAP: every use case sits somewhere on a spectrum of read, understand, recommend, act. An agent that reads a sales order is low risk. One that recommends which disconnection accounts need attention is genuinely useful — and now a human is making a decision informed by something they did not personally verify.
An agent that executes the transaction is a different animal. The moment “act” enters, the question stops being whether the API call was correct and becomes: would we have let a new employee do this on day one, unsupervised? For a disconnect, a rate adjustment, a switching order — the honest answer is no.
The critical point is that risk does not rise gradually across that spectrum. It jumps — and because all four tiers flow through the same connector, the tooling hides the jump. Treating read and act as one governance problem because they share a plumbing layer is how organizations end up explaining themselves to an audit committee.
This is also where capability creep does its damage. Nobody decides to expose forty tools across a dozen systems. It happens one reasonable-sounding request at a time, until SAP has become SAP plus the CRM plus the work management system plus SaaS platforms nobody named in the original meeting, and no one can say who approved capability thirty-one. SAP’s framing calls the result shadow agents. That is accurate but incomplete: shadow agents are the symptom; the disease is authority accumulating without anyone deciding.
Layer Four: The Unclassified Control Plane
The four-box whiteboard diagram — user, model, MCP, SAP — looks like an integration project, and gets scoped like one. That, as Chandan argues, is the mistake. The tool layer is where authority actually gets decided. Which tools exist, what each may touch, which are safe reads and which should require three approvals — that line gets drawn deliberately by an architect, or by accident, by whoever built the tool fastest. A connector is something you build once and maintain. A capability layer is something you govern continuously as it grows.
And it is worth being precise about why authentication is not the answer here. A request can be perfectly authenticated, hit a properly secured API, pass every network control, and still be an entirely inappropriate thing for an AI to do: data reaching someone who should not see it, a transaction skipping a business rule, an action a human would have paused on. None of that registers as a security failure. The logs look clean. Everything is working as designed. That is a governance gap wearing a working integration, and it is the one most AI-to-SAP conversations skip straight past.
I have argued before that Company Memory is one of the most security-critical assets in the agentic architecture, because whoever can write your rules can steer your agents. The tool layer is its sibling: whoever defines your tools scopes your agents. SAP’s MCP Gateway in Integration Suite is not plumbing. It is a control plane, and should be governed like one.
Notice what this exposes that process atoms do not cover. Atoms give us the unit of least privilege within the process model — a transaction code rather than SAP_ALL, which is the right construct. But an agent correctly scoped to an atom can still be handed a tool that reaches further than the atom does. Tool-level authorization is a distinct boundary, and not yet a first-class object in the published architecture.
Layer Five: The Regulator Asks in a Language You Don’t Expect
Europe resolves obligation through artifacts. The Cybersecurity Act framework certifies products, ISO/IEC 42001 certifies your management process, and AI Act conformity with CE marking governs the system as placed on the market. Three instruments at three layers, routinely presented as interchangeable proof of the same thing — and a vendor holding one has not demonstrated the other two. The Digital Omnibus moved the high-risk deadlines to December 2027 and August 2028, but the requirements did not shrink; only the machinery was unready.
North America resolves obligation through audit. NERC CIP puts it on you, the registered entity, and settles it with evidence and penalties. There is still no AI-specific NERC standard; your exposure runs through CIP-010 change management and CIP-013 supply chain.
Which produces the question CIP-013 was never drafted to answer: who is accountable for the integrity of AI-generated code accumulating in your internal tooling right now — code no single developer wrote or reviewed line by line? Extend that to the tool definitions themselves. An MCP tool is third-party supply chain, arriving without the artifact trail a vendor product carries.
One cross-regime detail worth carrying into architecture review. The proposed CIP-013-4 adds reassessment intervals — twenty-four months for high impact, thirty-six for medium. SAP’s LeanIX Verification Seal, runtime-enforced so unverified agents do not run, is the strongest governance-as-control mechanism on the table. But a seal granted once is a point-in-time attestation, and a tool approved eighteen months ago under different assumptions does not get to run forever unreviewed. The CIP drafters are fixing exactly that defect in supply chain; the agent stack should not reintroduce it.
What the Operating Model Actually Needs
None of this requires inventing new governance. It requires applying discipline we already know, to a new kind of actor: clear ownership for every capability before it ships; data classification deciding what an AI may touch at all; least privilege applied to AI as we apply it to people; tool-level authorization, not just system-level; human approval wherever the action tier justifies it; auditability detailed enough to reconstruct what happened and why; a capability registry — Chandan’s term, and the right one — recording every tool, its owner, and its risk tier; and lifecycle management with a reassessment clock.
The architectural half is further along than most of our community realizes: a hardened RISE foundation with LogServ and RAVEN feeding your SOC, a published ETD-to-SIEM/SOAR reference architecture where the agent kill switch already lives, Signavio modeling agents as a BPMN swimlane, SuccessFactors placing agents in the org structure with a named owner.
The organizational half is what is missing from most project plans: the architect who sees the whole ecosystem rather than the SAP piece or the AI piece; whoever decides what separates a safe read-only tool from one requiring approvals; the functional owner who answers the question a technical review never will — does this data mean what the AI thinks it means; the process owner who owns the outcome and the risk, not the demo.
What We Still Need to Influence
Our community has both the standing and the responsibility to push here, and the asks are specific.
Extend the published security operations pattern to agents — agent-specific detection content, agent activity log sources, and the explicit guarantee that agent actions are distinguishable from human actions at every hop, from application log to SIEM event to SOAR case.
Publish agent identity lifecycle guidance: provisioning, credential rotation, certification, and deprovisioning, integrated with the IAM and PAM investments we already made.
Document SAP-aware response actions for agents in SOAR connectors — suspend an agent, quarantine its outputs, revoke its verification seal — as the counterparts to the session termination and account locking already documented for humans.
Make Verification Seal criteria transparent and customer-auditable, with a defined revocation and reassessment process. A runtime-enforced seal is only as trustworthy as the verification behind it.
Confirm whether agent inventory extends to tool-level dependencies. The Agent Hub inventories agents; what we have to govern is tools, and one agent can hold many. Whether that inventory reaches the tool boundary determines whether it answers an auditor’s question or merely gestures at it.
Publish explicit mapping between the agent governance stack and NERC CIP requirements around access management, change control, and evidence generation, so every utility is not reinventing that analysis alone.
And give us architectural guidance on where agent authority stops at the OT boundary. ADMS, SCADA, and OMS sit outside SAP’s perimeter but inside many of the workflows agents will touch.
Honest Caveats
Several things here are less settled than a clean structure makes them look.
“Accountability first or no production” is stated more forcefully than the evidence strictly supports. The correlation between security maturity and AI readiness is one I find persuasive; the causal sequence is not proven. It is entirely possible to run narrow, read-only AI on a mediocre foundation, and many of us are doing it now. The narrower claim I will defend: at the “act” tier, in a regulated utility, the organization that has not assigned ownership will stall before production or discover the gap during an audit.
Several load-bearing components are roadmap, not product. The Agent Gateway, SuccessFactors agent capabilities, and the LeanIX Agent Hub are announced or next-quarter. Plan against the architecture; commit against shipped functionality.
The shared responsibility line has not moved. RISE explicitly leaves application-layer identity, authorizations, process configuration, and compliance with the customer. Agents are application-layer actors. There is no vendor to whom this can be shipped.
Watch the commercial fine print. SAP Enterprise Threat Detection, the engine at the heart of the published security operations pattern, carries separate cost. Security for the autonomous enterprise cannot become an upsell.
Nobody has run this end-to-end yet. There is no body of practice showing how any of it performs in an actual CIP audit. The first utility to test it will teach the rest of us more than any article can.
The Regulator Test
If your utility deployed an AI agent into production tomorrow, could you tell your regulator who authorized it, what rules it follows, who monitors it, where it sits in your organization, and how you would shut it down? If more than one of those gets a shrug instead of a name, the technology is ready well before the organization is. That is not a reason to avoid the autonomous enterprise. It is the project plan.
So: has anyone built the capability registry — a living inventory of every AI tool, its owner, and its risk tier — and did it survive a real integration backlog? Has anyone drawn the line between the read tier and the act tier in writing, before an incident forced it? Has anyone taken the accountability question to an internal auditor and gotten a useful answer back?
Bring it into the community. The organizations that navigate the next eighteen months well will be the ones that compared notes rather than each solving it alone. I will be at ASUG’s SAP for Utilities conference in San Antonio in October, and this is the thread I most want to pull on there. Find me.