Governance Guide for AI-Supported SAP Platforms

By Prof. Hernan Huwyler, MBA CPA CAIO · AI GRC Director · Academic Director, IE Law School
Published 9 November 2026 · Last reviewed 9 November 2026

In short

• SAP Business AI brings together Joule, Joule Studio, the Knowledge Graph, the AI Gateway and the Agent Hub. These capabilities can help move agent governance from written policies into platform-level controls. It is important, however, to distinguish generally available features from roadmap items.
• Approving an AI agent is an authority decision as much as a technical one. Before deployment, define which actions the agent is allowed to perform, which business data it can access and where human approval is required, especially in finance processes.
• Demonstrate that an agent is both useful and controlled through auditable evidence. Track traffic through the AI Gateway, actions performed by agents, exceptions and the frequency of human intervention.

Monday morning, a business owner asks for Joule Work to be switched on for four thousand users by the end of the month. The request cites a vendor announcement, and nobody in the room can say which parts of that announcement are live, which are in early access, and which are plans. The SAP and AI Architects have one question: who approves what an agent is allowed to do inside the finance system?

SAP told its developer conference that the SAP Business AI Platform, with Joule Work, Joule Studio, the Knowledge Graph and Business Data Cloud, is available to customers. General availability of a platform does not mean your governance is finished. It means the tooling now exists, and the decisions about ownership, autonomy limits, evidence, and cost remain yours. Some items in the same announcement, including the Enterprise AI Gateway and the AI Governance Assistant for the EU AI Act, were described as new or planned, with early adopters first.

This guide is for AI architects, Chief AI Officers, SAP enterprise architects, internal auditors, SOX control owners, and AI product owners. It separates what SAP has said is live from what is announced, explains what the announcements change for SAP as a vendor, and walks through the controls to put in place before agents act on SAP data: the tabular prediction model, the gateway, the agent inventory, the approval path for new agents, and the measures that show whether the agents help.

What SAP Announced and What General Availability Covers

SAP described the SAP Business AI Platform as one place to build, contextualize, and govern AI across SAP and third-party environments. SAP's press release lists the main pieces: new orchestration in Joule Work, an expanded Knowledge Graph, a governed gateway that lets third-party agents invoke Joule Agents, a new Enterprise AI Gateway, a new assistant and agent hub for governance, and an updated tabular model. Trade coverage of the event quoted SAP's chief technology officer saying that the platform, the Knowledge Graph, Business Data Cloud, Joule Studio, Joule Work, and the orchestration and integration capabilities are now generally available.

Read that statement as a summary, then check each component. SAP's own pages show different timing for different parts. The basic agent gateway is generally available, while the Enterprise AI Gateway was announced as a layer on top of it. The press release uses the future tense for the Enterprise AI Gateway and for the extended tabular model capabilities. The AI Governance Assistant goes first to customers in the early adopter care program in November. Customers in the Joule Studio early adopter program can run n8n workflows, with broader availability to follow. A separate SAP blog post from the same week described Joule Studio as soon to be generally available and Joule Work as rolling out later in the month, so tenant-level availability is a question for your account team and your system, not for a headline.

A practical way to hold this is a status register with one row per capability. For each row, record what SAP said, the source page, the status in your SAP estate, and the date you checked. Mark each capability as live in production, in early access, announced with a date, or announced without a date. The register becomes the input to your project plan, because a control you design around a capability that is still in early access has to survive a schedule change. It also gives auditors a record of what you knew when you approved a rollout, which matters if an assumption later proves wrong.

Capability	What SAP said	Status to verify in your tenant
Joule Work and SAP Business AI Platform	Available, with a staged rollout described on SAP pages	Is it provisioned for your users, and which features are on
Agent gateway for third-party agents calling Joule Agents	Generally available according to the keynote account	Which agents are allowed in, and under what access rules
SAP Enterprise AI Gateway	Announced as an overlay on the agent gateway, built on SAP Integration Suite	Release date, licensing, and which traffic it covers
SAP AI Agent Hub	Described as generally available at a company event	Which agents, models, and MCP servers it inventories for you
AI Governance Assistant	Early adopter care customers from November	Whether your organization is in the program
SAP-RPT-2.0 additions	Announced: anomaly detection and embeddings	Release date and the tasks your data supports
Joule Studio runtime	Free for select customers through December 2026, then priced	Eligibility, and expected spend after the promotion

One more reading discipline helps. Many numbers in the announcements describe results that SAP measured in its own testing or reported from customers: a faster path from idea to working agent, a lower cost per task, shorter month-end close, faster supplier risk response. Treat each as a hypothesis to test in your environment. Ask for the baseline, the measurement period, the data source, and the owner who can defend the figure, using the same discipline you apply to any internal benefit claim.

What the Announcements Change for SAP as a Vendor

For SAP SE, the announcements move the company from selling systems of record to selling the layer that acts on them. SAP says it will deliver assistants and agents out of the box across five horizontal domains, and it describes the platform underneath as the foundation for both its own agents and those customers build. This is a change in what the company expects to be paid for. A system of record earns revenue through licenses and subscriptions tied to users, modules, or transactions. A layer that executes work earns revenue through consumption: models called, agents run, tasks completed. The free promotion on the Joule Studio runtime through December 2026 shows the direction. After it ends, customers will pay for usage, and SAP is shipping spend and model-usage visibility in Joule Studio at the same time.

The second change is where SAP hopes to hold its advantage. A public model does not know your master data, your approval rules, or your process variants. SAP's argument is that a context layer built from decades of process knowledge, the Knowledge Graph, domain models, and Business Data Cloud, makes its agents more accurate inside SAP workflows than a general model reached over an API. If customers accept that argument, the context layer becomes the point of dependence, and the company owns the audit trail that agents generate. Governance products reinforce this. An agent inventory, a gateway that enforces policy, and a verification rule that blocks agents not registered in the hub all place SAP in the control plane for AI activity, including activity by non-SAP agents. A control plane is harder to replace than an application, because your evidence, your policies, and your classifications live in it.

The third change concerns openness, and the picture is mixed. SAP supports the open agent-to-agent and tool-access protocols and describes a gateway where agents from other providers can call Joule Agents with access control enforced. Trade press and an integration consultancy's analysis describe a more restrictive side: an API policy published in April 2026 that restricts autonomous AI systems from calling SAP APIs outside endorsed pathways. I have not verified the policy text against SAP's own page in this review, so read the current version before you plan any integration. If the reports are accurate, then third-party agents will reach SAP data through SAP's gateways and its assistants, which suits SAP's business model and raises cost and design questions for customers who run agents from several providers.

The fourth change is a bet on trust as the limiting factor. SAP's governance executives argued at the event that governance should not be an afterthought and that no established industry benchmarks exist for AI governance yet. That is a vendor view, and it is also a fair description of a field where standards such as ISO/IEC 42001 and the NIST AI Risk Management Framework give structure but not product-level benchmarks. By shipping governance as part of the platform, SAP is trying to make the compliant path the easy path for its customers. If it works, governance becomes a reason to buy. If it does not, customers will assemble their own controls around the platform, and SAP's governance features will be one input among several.

What are the risks for SAP? Staggered availability invites disappointment when the headline says generally available and a customer's tenant says otherwise. Accountability is another: when an agent inside an SAP process approves an order wrongly, the customer, the partner who configured it, and the vendor will each point at a different layer, and contracts will be tested. Concentration is a third, because a customer that runs finance, supply chain, HR, and agent governance on one vendor's platform has a single point of failure and a single negotiating counterpart. None of this predicts commercial results. It describes the questions that determine whether the strategy produces durable revenue or short-lived pilots.

How the Platform Layers Fit Together

Start with the user-facing layer. Joule Work is the interface where people state intent and receive answers, reports, or actions, and it connects SAP applications and some third-party tools. It keeps conversation context and offers shared spaces that assemble data into dashboards around a business goal. Behind it, orchestration plans the steps an assistant or agent needs for a multi-step task. For a governance reviewer, the interface matters less than a single fact: it is where users will experience agents, so it is where user permissions, approval prompts, and audit trails must be visible.

Next comes the build layer. Joule Studio lets business users describe an agent in natural language and lets developers refine it with code, with a command-line tool for developers who prefer their own environment. SAP describes a built-in sandbox with execution traces and generated tests, and planned offline evaluations for accuracy, agent-to-agent correctness, and resistance to prompt injection. Agents deploy to a managed runtime and appear in the agent hub. Role-based access separates people who define requirements from those who refine code, and administrators can see all solutions in a tenant. The build layer is where most of your approval controls belong, since it is the last point before an agent can act.

The context layer sits underneath. The Knowledge Graph gives agents a structured map of business entities and their relationships. Business Data Cloud supplies data from SAP and other sources, and a new ontology manager is intended to let customers add their own domain concepts. Domain models combine SAP-trained models with third-party language models. For control purposes, this layer determines what the agent knows. Wrong or stale context produces confident wrong actions. Ask who owns the ontology, who approves changes to it, how freshness is measured, and what happens to agent behavior when a source is unavailable. One SAP tutorial notes that Joule reports a data gap when a requested live data source is not connected, instead of inventing an answer. That is a behavior to test in your own tenant, with a deliberately missing source.

The governance layer has two halves. At design time, the AI Agent Hub keeps an inventory of agents, language models, and MCP servers, regardless of platform, and records lifecycle status and verification. At run time, the gateways enforce policy on traffic: who may call what, how often, through which route, and with what logging. SAP's keynote described the pairing as the link between oversight and enforcement, and said agents not verified in the hub cannot be invoked. The practical question for a risk owner is whether the design-time record and the runtime rule actually agree, so that an agent marked unapproved in the inventory cannot run in production.

Finally, there is the model layer. Joule Studio offers more than seventy models, SAP's own foundation models handle code generation and predictions on structured data, and SAP announced access to curated sovereign-cloud language models through its AI core service. Model choice is a control decision. Different models carry different costs, data-handling terms, and error profiles. Define which models are approved for which classes of use, and record the approval. Where a use case involves personal data or regulated decisions, include the model's hosting location and the contractual terms in the approval record, since those facts change the risk assessment.

What SAP-RPT-2.0 Means for Predictions on Business Tables

SAP-RPT is a tabular foundation model, a model pretrained to make predictions directly from rows and columns of business data. SAP's learning material describes it as table-native and able to produce predictions and classifications from structured data using in-context learning, without custom model training for each task. In practice you hand it a table with historical examples, and it predicts the missing value for new rows. The appeal is speed: a forecasting or classification use case that once needed a data science project can start from a table and a question. The risk is the same as the appeal, because a model that needs little setup also needs little deliberate evaluation unless you insist on it.

The announcement extends the model family in three directions. SAP-RPT-2.0 is announced to move beyond classification and regression into anomaly and outlier detection and into richer analysis through embeddings, with native handling of several related tables. A time-series variant, SAP-RPT-TS, targets forecasting on time-indexed business metrics in SAP's planning product without custom machine learning. A third variant, SAP-RPT-Decisions, is meant to help automate decisions inside agentic workflows, with examples such as approving orders or routing supply chain exceptions. SAP also announced plans to run the model on a hardware partner's system aboard the International Space Station to triage anomalies and reconstruct missing sensor values. That deployment is a stated plan, and it tells you about the model's design goals, not about how it performs on your data.

Treat each use of the model as a model approval, whatever the setup effort. Write the decision it supports and the owner of that decision. Define the target variable and the time window the prediction covers. Split historical data by time, with the earlier period as context and the later period as the test, and record precision and recall at the threshold you intend to use, along with the cost of each false positive and each missed case. For forecasts, record the error against a naive baseline such as last year's value or a moving average, because a forecast that does not beat the baseline adds cost and no value. Keep the data extract, the test script, and the results as evidence an auditor can request.

Anomaly detection needs a different standard, since there is often no labeled truth. A model that flags the one percent of postings that look unusual has produced a worklist, and the question is whether the worklist contains more real problems than a random sample of the same size. Set up a review protocol: analysts examine a sample of flagged items and a sample of unflagged items, record what they find, and calculate how much more often flagged items turn out to be genuine. Repeat the check every quarter, and after any change in the underlying process or source system. Model drift in anomaly detection often looks like a falling hit rate, or like a rising flag volume that nobody can review.

The decision variant raises the control bar the most, because it moves from predicting to acting. When a model output can approve an order or route an exception, the same questions apply as for any automated control. Define the authority limit: the maximum order value or exception class the model may decide alone. Define the escalation rule: which scores or conditions send the case to a person. Log the input, the score, the version of the model, and the action, so a reviewer can reconstruct any decision. Test the control against historical cases, including cases where the right answer was to refuse. If the use falls under financial reporting controls, involve the control owner early, since an automated approval is part of the control environment and its design and operating effectiveness will be tested.

One more caution concerns the claim that a model works with little data preparation. Fewer manual features does not remove the need for data quality checks. Missing values, changed codes, duplicate records, and inconsistent units still distort predictions. Run completeness, validity, and timeliness checks on the input tables, record the thresholds, and stop the prediction run when a check fails. A model that silently produces output from a broken extract is worse than one that fails loudly.

How the Enterprise AI Gateway Controls Agent Traffic

Start with the problem the gateway addresses. When people use AI through a handful of approved tools, governance is a policy and a training session. When agents call APIs, tool servers, other agents, and language models on their own, every call is a decision that someone should be able to explain. Authentication tells you who or what is calling. Policy enforcement decides whether the call is allowed. Routing sends it to the right model or service. Monitoring and usage tracking show volume and cost. Auditing keeps the record. SAP describes the Enterprise AI Gateway as a single place that consolidates these functions, and says it controls traffic across tool-access servers, APIs, agent-to-agent connections, and language models.

Be precise about what is available. The basic agent gateway, which connects agents and endpoints across system boundaries, was described in the keynote as generally available. The Enterprise AI Gateway was announced as an overlay for more complex cases that need rate limiting, routing, protocol translation, and advanced access control, and it is built on SAP Integration Suite. SAP's press release uses the future tense for it. Your plan should therefore separate what you can configure today on the agent gateway from what you intend to add when the enterprise gateway ships. Do not design a control that depends on a gateway feature before you have seen it in your tenant and tested it.

A useful way to specify the gateway's job is to list four traffic types and the policy each needs. For API calls, define which services an agent may reach, with which scopes, and with what rate limits. For tool-server calls, define which servers are approved, who owns each, and which tools on each are allowed for which agents. For agent-to-agent calls, define which external agents may invoke which Joule Agents, with what identity, and what the called agent may return. For model calls, define which models are approved for which data classes, the routing rule when a model is unavailable, and the spend limit per agent or per team. Each of the four lists is a policy document that someone owns and reviews on a schedule.

Identity deserves its own paragraph. An agent that acts in a finance system should have its own identity, with permissions limited to its task, not a shared technical user with broad rights. Segregation of duties applies to agents in the same way it applies to people: an agent that can create a vendor and also approve a payment to that vendor is a control failure, whatever its accuracy. Review agent permissions against your segregation of duties rules before deployment, and again whenever the agent's tools change. Keep credentials and endpoints out of the agent's instructions, as SAP's own development tutorial advises, and use the managed connectivity instead.

Then consider the evidence. The gateway's audit records are only useful if someone can search them. Decide the retention period with your legal and audit teams, and test retrieval: pick an agent action from last week and reconstruct who called it, what data it read, what it returned, and what changed in the system of record. If the reconstruction takes days, the control does not work for an investigation. Also set alerts for the patterns that matter, such as a sudden rise in calls by one agent, calls outside business hours, repeated denied requests, or a model route that changed without an approved ticket.

A note on policy and cost. Trade reports describe an API usage policy that limits autonomous AI calls to endorsed pathways, and they describe per-call charges for some of those pathways. Whatever the exact terms are, agent traffic has a price, and the price changes design choices: whether an external agent calls SAP directly, calls through a gateway, or asks a Joule Agent to do the work. Build a simple cost model before committing to an architecture. Estimate calls per task, tasks per month, price per call or per model token, and the share of tasks that need two model invocations because one agent hands work to another. Compare the monthly figure with the cost of the manual process it replaces.

How AI Agent Hub and the AI Governance Assistant Support EU AI Act Work

The AI Agent Hub is an inventory first. SAP describes it as a record of agents, language models, and tool servers across SAP and non-SAP environments, with lifecycle status, verification, and value tracking, and it grew out of governance features in SAP's architecture management product. An inventory is the foundation of any AI governance program, and both ISO/IEC 42001 and the NIST AI RMF assume you know what AI you operate. The EU AI Act also depends on it, since you cannot classify or document a system you have not found. Start by loading every agent you know about, then look for the ones you do not: agents built by business teams, agents embedded in vendor products, and external agents calling your systems.

The AI Governance Assistant is SAP's attempt to speed the documentation. According to SAP's governance article, it audits the inventory for incomplete documentation, pre-fills fields from assessments already completed, flags systems that look high-risk but lack a classification, and triggers a reassessment when a fact sheet changes materially. The keynote said it guides the agent owner through the remaining questions and produces an audit-ready risk classification, and SAP's article says its outputs appear as drafts for legal and compliance review. Those two descriptions fit together if you read audit-ready as well structured and draft as not final. The release goes first to early adopter care customers in November, so most organizations will see it later.

What does the assistant not do? It does not decide your legal position. The EU AI Act classifies systems by intended purpose and context of use, and the same agent can be low risk in one process and high risk in another. For example, an agent that summarizes supplier questionnaires differs from one that ranks job applicants or evaluates workers, and the Act treats employment uses as a high-risk area. A classification tool can only work from the purpose someone recorded. If the recorded purpose is vague or out of date, the classification is too. One analyst guide on SAP's agent catalogue makes the same point: use the output as a structured starting point and still document the specific intended purpose the customer configured around the agent.

Build a classification procedure around the tool. The agent owner writes the intended purpose in one paragraph: what the agent does, for whom, on what data, and with what decision rights. A second person from legal or compliance reviews it against the Act's categories and records the reasoning. If the agent may touch employment, credit, education, essential services, or other areas the Act lists as high risk, escalate to a formal assessment. Record who approved the classification and when, and set triggers for reassessment: a change of purpose, a new data source, a new model, or a change in autonomy. The assistant's reassessment trigger helps here, and your procedure should not depend on it alone.

Keep the legal timeline out of your own memory. The EU AI Act has been amended since its adoption, and its obligations apply in phases, so state a date only after reading the current consolidated text or an official Commission page. Some vendor and trade writing in circulation gives specific enforcement dates for high-risk obligations without a primary source, and I could not confirm those in this review. Put the check on a calendar owned by your legal team, and link your program plan to the official text, not to a summary.

Finally, connect the hub to the runtime rule. SAP says agents not verified in the hub cannot be invoked. Test that claim in your own tenant: register a test agent, leave it unverified, and try to call it from Joule Work and from an external agent through the gateway. Then verify it, call it again, and check the logs. The difference between a registry that documents agents and a registry that blocks them is the difference between a record and a control. Auditors will ask which one you have, and you should have a test result to show them.

How to Approve an Agent Before It Reaches Production

Use the build workflow as your approval path, because it already has stages and checkpoints. SAP's developer tutorial describes six stages in Joule Studio: intent, requirements, specification, solution, testing, and deployment, with the option to revisit earlier stages. At each stage the platform generates an artifact: a requirements document, a technical specification, code, test results. Each artifact is evidence, and each stage is a place to put a human decision. Map your approval roles onto the stages: the business owner signs the intent and the requirements, the architect signs the specification, a developer reviews the code, a tester and the risk owner sign the test results, and an administrator releases to production.

At the intent stage, require a statement that covers five things: what the agent does, which systems and data it touches, which persona it serves, what output or action it produces, and what business outcome justifies it. Add three governance fields that the platform will not supply: the intended purpose in a form legal can classify, the autonomy level, and the named owner who answers for the agent's behavior. The autonomy level is the field that does the most work. Define it as one of a few levels, for example recommend only, act with human approval, or act alone within stated limits, and tie each level to evidence requirements that rise with autonomy.

At the requirements and specification stages, review what the platform generated against your own rules. The generated document lists the APIs the agent will use. Check each against the principle of least privilege and against your segregation of duties matrix. The tutorial itself calls the requirements review one of the most important checkpoints, and suggests confirming that the user stories reflect real business needs, that the architecture is appropriate, that the identified interfaces are relevant, and that scope and limits are stated. Add one question that generated documents rarely answer: what should the agent refuse to do, and how will it behave when it cannot complete a task?

At the solution stage, review generated code like code from a junior colleague. The tutorial states that AI-generated code must be reviewed like code contributed by another developer, and that is the right standard. Have a second developer check the business logic, the handling of invalid input, the use of tools, and the way credentials and endpoints are referenced. Instructions written in plain language count as code for review purposes, since a vague or contradictory instruction changes behavior as surely as a coding error. SAP's guidance on writing instructions favors ordered steps, explicit priorities when rules conflict, and conditional language over absolute words like always and never.

At the testing stage, define pass criteria before you run the tests. The platform runs unit tests and AI-assisted evaluations and offers a preview interface. Add your own test set: normal cases, edge cases, invalid inputs, cases that should be refused, and cases designed to manipulate the agent, such as instructions hidden in a document or a message. SAP described planned offline evaluations for accuracy, agent-to-agent correctness, and resistance to prompt injection, which are not yet a substitute for your own adversarial testing. Record the number of cases, the pass rate, the failures and their fixes, and the version tested. An agent changes behavior when its instructions, tools, or model change, so a test result belongs to a specific version.

At the deployment stage, keep the production gate. SAP's tutorial describes a Git-based approval step for promoting an agent to production, triggered by a Joule Studio administrator who packages the code and deploys it to the production runtime. That gate is a control, so protect it: limit who can trigger it, require a recorded approval from the business owner and the risk owner, and make sure development environments cannot reach production data. After release, register the agent in the hub, verify it, and set monitoring: the activity traces, the usage dashboard, and alerts on the metrics from the next section.

Decision rules help the approval board stay consistent. Approve a recommend-only agent when the owner can show test results on a representative sample and a named reviewer for the output. Approve an act-with-approval agent when, in addition, the approval prompt shows the reviewer the evidence behind the recommendation and the log keeps the reviewer's decision. Approve an act-alone agent only when it has a stated authority limit, a stop condition, a rollback procedure, and monitoring that would detect a wrong pattern within a day. Refuse any agent whose owner cannot say what it must never do. Escalate any agent that could fall under a high-risk category to legal before it moves to testing.

How to Measure Whether Agents Deliver Value and Stay Safe

Measurement serves two purposes that share the same data: proving value to the people who pay and proving control to the people who audit. SAP's governance team made the same point, saying that the observability needed for governance can also serve performance management. The platform's agent mining capability is meant to show agent behavior in the context of business processes, so you can check compliance and capture business impact together. Decide in advance which numbers belong to the value story and which to the control story, then assign each an owner and a data source before the agent goes live.

Define every metric in a way an auditor could recompute. A metric needs a name that says what is counted, a numerator and denominator, a baseline with its period, a result with its period, a data source, an owner, and the evidence you retain. Be careful with baselines. A touchless processing rate measured on the easiest quarter of the year overstates the benefit, and a handling time taken from a time study of your best clerk understates the cost of the manual process. Use a baseline period long enough to include a normal range of variation, and write down any adjustment you make.

Consider an illustrative scenario, with assumptions stated and numbers invented for the example. A mid-sized manufacturer deploys an agent that proposes a resolution for invoice exceptions, such as a price mismatch between the purchase order and the invoice, at the act-with-approval level. The company handles about 3,000 exceptions a month, and a clerk spends an average of 22 minutes on each. After 90 days, the agent's proposal is accepted without change on 55 percent of exceptions, and the team reviews a random sample of 500 agent proposals each month.

Metric	Definition	Baseline	After 90 days	Owner
Accepted without change rate	Exceptions where the reviewer accepted the proposal as is, divided by all exceptions	Not applicable, 0 percent	55 percent, or about 1,650 of 3,000	Accounts payable manager
Wrong proposal rate in sample	Proposals judged wrong by a second reviewer, divided by sampled proposals	Not measured before	12 of 500, or 2.4 percent	Internal control owner
Handling time for accepted proposals	Minutes from exception creation to resolution, measured in the workflow log	22 minutes	4 minutes, assumed from review time	Accounts payable manager
Agent run cost per exception	Runtime and model charges divided by exceptions processed	Not applicable	0.35 dollars, assumed	Finance business partner

The arithmetic reconciles. If 1,650 exceptions each save 18 minutes of handling time, the saving is 29,700 minutes, or about 495 hours a month. Runtime cost at 0.35 dollars on 3,000 exceptions is 1,050 dollars. The wrong proposal rate of 2.4 percent in the sample means that, if the sample is representative, roughly 40 of the 1,650 accepted proposals a month could be wrong, so the real question is whether reviewers catch them. The second reviewer's sample is therefore the control that matters, and its trend, not the headline savings, tells you whether to widen or narrow the agent's autonomy. What did not improve? The remaining 1,350 exceptions still go to people, and they are probably the harder ones, so the average handling time of the manual cases may rise.

Cost deserves a standing report of its own. Joule Studio now offers visibility into model usage and spend, and SAP's promotion that keeps the managed runtime free for select customers runs through December 2026. Treat the free period as a pilot, not as a price. Measure usage during the promotion, project the monthly charge at consumption rates once you have them, and compare it with the benefit figures above. Set a spend alert per agent, and a rule for what happens at the limit: pause, throttle, or escalate to the owner.

Safety metrics need thresholds that trigger action. Define the wrong proposal rate above which the agent drops back one autonomy level. Define the number of denied gateway calls per day that opens a review. Define the share of inventory entries with a named owner and a current classification, and report it monthly to the person accountable for AI governance. Track incidents in the same register you use for other operational incidents, so patterns across agents are visible. Review the metrics quarterly with the approval board, and retire agents that no longer pay for themselves, since an unused agent with live permissions is a risk with no benefit.

Generally Available Capabilities

SAP offers several cloud-based AI components:

• Joule Work serves as the primary conversational and agentic workspace for users.

• Joule Studio provides the managed development and build environment on SAP BTP.

• Agent Gateway handles runtime connectivity, routing, and governance.

• SAP Knowledge Graph supplies business semantics, backed by the HANA Cloud graph engine for custom graph operations.

• SAP Business Data Cloud delivers trusted data products and sharing platforms.

The administrators rely on support component codes, diagnostic functions, and technical development interfaces:

• Support Routing: Issues are reported using components such as CA-JOULE-WORK-SH for the shell, CA-JOULE-WORK-CON for conversations, and CA-PAB for agentic features.

• Diagnostics: Technical traces and message histories are retrieved directly within Joule Work by navigating to Settings, selecting Conversations, opening System Info, and downloading System Traces.

• Development Interfaces: Building and deploying custom agents utilizes the SAP Cloud SDK for AI, the VS Code extension, and the command-line interface, leveraging parameters like JOULE_AUTH_APP_TID.

• Semantic Querying: Graph data in SAP HANA Cloud is queried using standard SPARQL and transactional commands like SQL COMMIT.

• Integration: Model Context Protocol (MCP) and agent-to-agent (A2A) protocols connect external tools and third-party agents.

Transaction codes only apply to the underlying SAP business applications that Joule invokes, such as S/4HANA transactions, Fiori applications, or backend reports. Joule orchestrates tasks, retrieves business data, and directs users to the appropriate modules, but the specific T-codes depend entirely on the underlying business scenario rather than the AI platform itself.

Practical Access Map

• Ask Joule to perform work: Joule Work

• Build or test agents: Joule Work Develop area and Joule Studio

• Connect external systems: SAP Integration Suite via MCP and A2A

• Access governed data products: SAP Business Data Cloud console

• Inspect semantic context: SAP Knowledge Graph and domain models

• Log a support incident: SAP for Me using component codes like CA-JOULE-WORK-CON

Certain advanced capabilities involve phased releases. Bidirectional communication with third-party and self-hosted agents through Agent Gateway depends on specific software release cycles, and deeper integrations between Joule Studio and SAP Business Data Cloud roll out across early 2027. Availability varies by tenant, region, and product edition.

The Context Behind the SAP Joule Roadmap Confusion

The SAP Joule roadmap is notoriously difficult to navigate not due to a lack of documentation, but because information is dense, fragmented, and frequently conflicting. SAP introduced 14 new Joule agents at its October 2025 event alongside projections of exceeding 400 embedded AI use cases by the end of 2025. Yet, organizations routinely struggle to determine which specific features are accessible in their current tenant.

This complexity stems from structural factors: SAP delivers Joule across multiple products on varying release cadences. Joule operates as an engagement layer spanning SAP Cloud ERP, Ariba, Fieldglass, SuccessFactors, and the SAP Business Technology Platform (BTP). Consequently, a single feature may appear as live production functionality in one source and a future roadmap item in another, depending on the software edition and product line. Effective planning requires shifting from asking generic questions about availability to auditing specific agents across distinct products, editions, and quarterly releases.

The Three Status Levels: Distinguishing Availability

To evaluate the portfolio accurately, organizations must categorize capabilities using three distinct status definitions rather than treating vendor announcements as implementation readiness:

• Generally Available (GA): Fully released features that can be activated immediately within entitled environments and editions.

• Early Adopter Care or Beta: Limited pilot programs, often restricted by closed registrations or selective onboarding.

• Roadmap: Timelined development targets subject to schedule shifts and dependency gating.

Generally Available Capabilities

A robust set of Joule features is live in production environments as of mid-to-late 2026 across order management and procurement workflows:

• Sales Order Creation: Reached general availability in Q1 2026 for SAP Cloud ERP, automatically generating orders from unstructured PDF or image purchase orders.

• AI-Assisted Contract Creation: Reached general availability in Q2 2026 within SAP Ariba Contracts.

• Statement of Work (SOW) Worker Role Recommendations: Reached general availability in Q2 2026 in SAP Fieldglass.

• Ariba Intake Management Agent: Industry press reported general availability in June 2026 for capturing and routing procurement requests automatically, though verification against specific tenant editions is recommended.

• Joule Work Mobile App: Reached general availability in Q2 2026 as the initial surface for SAP's outcome-driven interaction model, where users define goals and the system orchestrates underlying workflows and agents.

Capability	Product Area	Status Source & Timeline
Sales order creation from PDF/image POs	Order management (Cloud ERP)	GA, Q1 2026
AI-assisted contract creation	SAP Ariba Contracts	GA, Q2 2026
AI-assisted SOW worker role recommendations	SAP Fieldglass	GA, Q2 2026
Joule Work mobile app	Joule engagement layer	GA, Q2 2026
Joule Agent for Ariba Intake Management	Procurement	Reported GA June 2026 (Confirm by edition)

Limited Pilots and Development Environments: Joule Studio

The primary focal point for organizations looking to build custom agents is Joule Studio, SAP's low-code and no-code agent builder.

• Timeline Shifts: Initially guided toward a December 2025 general availability, Joule Studio transitioned into Early Adopter Care through Q2 2026, targeting general availability in Q3 2026. SAP provides twelve months of free design-time access through this Early Adopter Care initiative.

• Joule Studio 2.0 Enhancements: Unveiled at Sapphire 2026, the updated release features a fully managed deployment model requiring minimal infrastructure setup alongside native interoperability with external developer tools like Cursor and Claude Code. This aligns the platform with broader developer ecosystems to ground custom agents securely in enterprise business data.

Roadmap Milestones

Vision keynotes highlight several advanced orchestration capabilities slated for future delivery windows:

• Joule Work Web and Desktop Clients: Targeted for release to expand outcome-driven workspaces beyond mobile devices.

• Agent-to-Agent (A2A) Interoperability: Currently split by direction. Outbound execution (Joule invoking an external agent) is functional, while inbound execution (third-party orchestrators calling Joule agents as peers via the pre-GA Agent Gateway) .

• Future Workstreams: Advanced order management agents. Additionally, SAP is building a central AI Agent Hub to serve as a governance and discovery marketplace for multi-vendor enterprise agents.

Practical Implementation Actions

Because roadmaps and target quarters frequently shift, organizations should adopt a phased, disciplined sequence:

1. Inventory Existing GA Entitlements: Audit current cloud subscriptions to activate live capabilities in order management and procurement rather than waiting for future releases.

2. Leverage Joule Studio Early Access: Utilize the 12-month free Early Adopter Care design window for Joule Studio to build internal competency in agent design ahead of broader commercial pricing and talent competition.

3. Treat Milestones as Design Assumptions: Keep upcoming capabilities, such as inbound A2A protocol support and advanced governance assistants, on a watchlist for architectural planning rather than committing capital budgets prematurely.

What SAP Customers Should Do First

Begin with the inventory and the status register. In the first two weeks, list every AI assistant and agent already in use, including those embedded in SAP applications, those built in Joule Studio during early access, and those that external tools run against your systems. Record the owner, the systems touched, the data classes, the model, and the autonomy level of each. Create the status register for SAP capabilities described earlier, and agree with your SAP account team on the dates for anything announced. The output of this first step is a baseline you can measure progress against, even if it is incomplete.

In weeks three to six, set the rules. Write a short AI use policy that defines autonomy levels, the approval path, and the minimum evidence for each level. Define the four traffic policies for the gateway: which APIs, which tool servers, which external agents, and which models, with owners. Set the segregation of duties rules for agents and review them with the SOX control owners. Draft the classification procedure for the EU AI Act with legal, and put the legal schedule on a calendar owned by a named person. Decide who sits on the approval board and how often it meets; a board that meets every two weeks while the number of agents is small keeps the queue short.

In weeks six to ten, run two pilots with different risk profiles. Choose one recommend-only agent in a low-risk process and one act-with-approval agent in a process that has a real control, such as invoice exceptions or purchase requisition routing. Take both through the full approval path, including adversarial tests and the production gate. Record how long each stage took, where reviewers disagreed with generated documents, and what the logs let you reconstruct. Test the claim that unverified agents cannot be invoked, and test your ability to switch an agent off within minutes. The pilots produce the evidence and the process improvements that a policy cannot.

In weeks ten to thirteen, report and decide. Present the status register, the inventory, the pilot results, the metrics, and the spend forecast to the executive sponsor and the audit committee. Ask for decisions on the three items that need them: the autonomy levels you will allow in the next quarter, the budget for consumption after the promotional period, and the owner of the AI governance program. Explain what you will not do yet, such as letting agents act alone in financial posting, and what evidence would change that. A short list of conditions for expanding autonomy gives the business something to work toward, and it gives auditors a reason to trust the pace.

Throughout, keep the human side in view. People who work with agents need to know what the agent can do, what it cannot, and how to report a wrong result. Train reviewers on what a good review looks like: checking the evidence behind a recommendation instead of clicking approve, and recording a reason when they reject. Measure reviewer behavior too. An approval rate near one hundred percent with very short review times suggests the review has become a formality, and the control is weaker than the logs make it look.

Final Perspective

SAP's announcements shift the question for customers from whether to use agents in SAP processes to who decides what those agents may do. The platform now supplies much of the plumbing: an inventory, gateways, a build workflow with gates, and an assistant to speed EU AI Act paperwork. It does not supply your risk appetite, your segregation of duties rules, or your tolerance for a wrong approval. The next decision you make about a Joule Work rollout should start from a status register of what is live in your tenant and an approval path with named owners, and not from the headline.

For the vendor, the commercial test arrives when the free promotion ends and customers see consumption bills next to measured results. For you, the test arrives earlier, the first time an agent does something unexpected in a finance or supply chain process and someone asks who approved it. Choose one agent already in use, trace it end to end through the inventory, the identity it uses, the gateway log, and the approval record, and write down where the trail breaks. That gap list is your first real governance backlog.

References

1. SAP News Center, press release on developer AI announcements at SAP TechEd, October 27, 2026, https://news.sap.com/2026/10/sap-teched-ai-developers-build-what-matters-autonomous-execution/
2. SAP News Center, SAP TechEd in 2026: SAP Tells Developers You Can Build the Autonomous Enterprise, October 28, 2026, https://news.sap.com/2026/10/sap-teched-developers-you-can-build-autonomous-enterprise/
3. SAP News Center, SAP Shows How to Lead with AI Governance at SAP TechEd, October 30, 2026, https://news.sap.com/2026/10/sap-teched-shows-how-to-lead-with-ai-governance/
4. Techzine, SAP blocks external AI agents, Salesforce and ServiceNow don't, https://www.techzine.eu/blogs/applications/141323/sap-blocks-external-ai-agents-salesforce-and-servicenow-dont/ (trade press report, read the current SAP API policy to confirm)
5. SAP Insider, SAP TechEd 2026: New Tools to Build and Govern AI Agents, https://sapinsider.org/blogs/sap-teched-2026-new-tools-to-build-and-govern-ai-agents
6. Regulation (EU) 2024/1689, Artificial Intelligence Act, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2024/1689/oj (link to verify)
7. ISO/IEC, ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system, https://www.iso.org/standard/42001 (link to verify)
8. NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), https://www.nist.gov/itl/ai-risk-management-framework (link to verify)