Claude Is in the Hub. Where's Your Governance?

SAP Note 3437766 dropped quietly, but the implications are loud: Claude, Gemini, and GPT models are now available through SAP AI Core's Generative AI Hub. SAP Joule for Consultants is already running Claude through this layer — RAG over 25 million documents and 12 terabytes of SAP knowledge, according to the AWS blog post that confirmed it.

Good architecture. Seriously. The Orchestration Service handles data masking, content filtering, and prompt orchestration inside BTP. SAP did the internal governance piece correctly.

But here's what I keep seeing in the field that concerns me.

The Part Nobody Wants to Talk About

Every SAP-on-Azure customer I've worked with has AI workloads touching SAP data from outside BTP. Copilot pulling SAP data through Graph connectors. Azure OpenAI endpoints hitting OData services. ML models on Azure ML querying SAP tables for training data. Custom agents triggering BAPIs through Logic Apps.

SAP's Orchestration Service doesn't see any of that traffic. It can't. Those workloads never enter the BTP perimeter.

So when a CISO asks "is our AI governed?" the honest answer in most environments is: the 20-30% running through Joule is governed by SAP. The other 70-80% has no governance layer at all. And the new API Policy from April 2026 makes this worse, not better — SAP now explicitly prohibits autonomous multi-step agent execution against SAP systems, but they can only enforce that prohibition for workloads that route through their own infrastructure.

Your Azure OpenAI agent running Plan → Select → Execute sequences against SAP BAPIs? SAP's policy says that's not allowed. SAP's technology can't stop it. That's your problem to solve.

What "Context Engineering" Actually Means in Practice

The LinkedIn discourse around SAP AI Core has fixated on "Context Engineering" as the next frontier. I agree with the framing but not with how most people define it.

Context Engineering isn't just connecting a model to the right SAP tables. It's ensuring the entire chain — from the user's identity, through the authorization model, across the BTP/Azure boundary, to the specific BAPI or OData endpoint, and back — maintains semantic integrity and audit trail at every hop.

Specifically: when a Copilot user in Toronto asks about a customer's payment history, does the system verify that the user has SAP authorization for FI-AR data in company code 1000? Does it enforce that the query routes through Canada Central infrastructure? Does it log the interaction with enough detail that an auditor can reconstruct why that data was accessed six months later?

In the SAP-on-Azure environments I've assessed, the answer to all three questions is usually no. The model works fine. The governance doesn't exist.

The Three-Front Problem

This isn't happening in a vacuum. SAP customers are dealing with three enforcement actions at once:

The ODP extraction ban — SAP Note 3255746 killed RFC-based data extraction. If you're still running ADF CDC connectors or custom RFCs against SAP, you're non-compliant. Roughly 80% of SAP customers are, and most don't know it.

The ECC 2027 deadline — mainstream maintenance ends in 18 months. Extended maintenance costs 2% more every year with no feature updates. The migration window is closing fast.

The AI Agent API Policy — April 2026. AI can assist SAP. It cannot run SAP. Autonomous multi-step execution is explicitly prohibited.

Each of these independently creates work. Together, they create a governance problem that can't be solved piecemeal. Your data extraction compliance affects your migration architecture which affects your AI agent boundaries. They're coupled, and treating them as three separate projects is how you end up with three separate failures.

What I'd Check First

If I were walking into your environment this week, here's where I'd start:

Where are your BTP subaccounts provisioned? If any are outside Canadian regions, your Joule interactions are routing through non-sovereign infrastructure regardless of where S/4HANA sits. I see this in about half the Canadian enterprises I talk to — the S/4HANA instance is in Canada Central, but the BTP subaccount was set up in US East during a proof of concept two years ago and never moved.

How many service principals and managed identities govern your AI workloads? In a typical SAP-on-Azure environment, there are hundreds — most created during proof-of-concept projects that ended years ago, still carrying the same broad permissions they were given for rapid testing. This is the Non-Human Identity sprawl problem, and it's the easiest high-value finding in any governance assessment.

Can you produce a cost-per-decision metric for your AI workloads? Not cost per Azure subscription. Cost per actual business decision the AI supported. If you can't — and I've yet to meet a customer who can — you're spending on AI with no way to measure return.

Do you have a single document that shows which AI models access which SAP data, through which integration path, with which authorization model? If that document doesn't exist, your AI governance is informal at best, and non-existent at worst.

These aren't theoretical concerns. They're the specific findings that show up in the governance assessments we run. Most organizations land between 30 and 45 out of 100 on our Governance Readiness Score — firmly in the "Developing" band. Partial controls exist, but the gaps are significant enough that a compliance auditor or a determined AI agent could walk right through them.

The SAP AI Core announcement gives you more models. It doesn't give you more control. Those are different problems, and only one of them is solved.

---

We run a 2-week Governance Readiness Assessment that scores your environment across 9 domains — from AI sovereignty to data extraction compliance. The output is a quantitative score, three board-ready evidence packages, and a 90-day remediation roadmap.

Book a Governance Briefing if you want to know where you actually stand.