From SAP BTP to EIC: Where SUSE Can Help Define Agentic AI Governance

SAP teams migrating from PI/PO to SAP Integration Suite are making a second decision at the same time, where sensitive SAP data can be exposed to AI. In hybrid scenarios, that decision tends to land at the edge, on the Kubernetes runtime beneath SAP Business Technology Platform (BTP). For shops already standardized on SUSE, SUSE AI belongs in that conversation as a private, hybrid infrastructure layer.

SAPinsider research has found that SAP Integration Suite adoption jumped to 80% in 2025 from 63% in 2024, propelled by the mainstream maintenance of PI/PO, which ends in 2027. That deadline is approaching just as these organizations begin piloting generative AI and agent use cases that demand operational data. Thus, integration leaders must now drive cloud innovation while defending residency, compliance, and clean-core principles. SAP Edge Integration Cell (EIC) is where those two pressures meet.

EIC Becomes a Residency Line

The mechanics are simple. Integration flows are designed in SAP BTP and then transferred via the cloud connector running in the user’s k8s cluster. The cloud connector is then deployed via ELM, which uses a kubeconfig. An HTTP protocol is used between the cloud connector and SAP BTP. This approach ensures that design stays in the cloud while execution moves closer to the systems and data it touches.

That split sounds like an operations detail until AI enters the flow. Take the example of a finance reconciliation process that handles payment records, vendor master data, and customs information, all bound by local residency rules. The iFlow may be modeled in SAP BTP, but the actual data movement happens at the edge. Add an AI capability that summarizes exceptions, classifies transactions, or recommends remediation, and the compliance question is suddenly shaped by where that runtime physically sits. As a result, middleware, a layer that rarely asks for attention, is being asked to referee AI policy.

Why SUSE Matters Beneath SAP BTP

SUSE AI is built for enterprise AI infrastructure, which maps neatly onto the familiar SAP instinct of keeping sensitive workloads close to governed systems, and using cloud and modern integration where they genuinely fit.

The production credentials back that up. SUSE cites more than 25 years of partnership with SAP, reliance by more than 60% of the Fortune 500, and many SAP and SAP S/4HANA environments running on SUSE.

Additionally, at SUSECON 2025, it announced SUSE Rancher for SAP applications, packaging SAP-validated components, including SUSE Rancher Prime, SUSE Rancher Kubernetes Engine (RKE2), Linux, and databases, delivered with priority support. SUSE also flagged agent-based AI on its SAP roadmap.

The takeaway is that the Kubernetes layer beneath EIC is no longer plumbing. In a hybrid SAP architecture, it becomes the point where integration logic, security controls, operational data, and AI access policy all converge. SUSE AI fits there as infrastructure for the data protection, performance, and cost demands of private AI.

AI Governance Is Now a Runtime Question

The urgency shows up in the numbers. Among organizations adopting AI, 53% cite security and compliance controls to protect data exposed to AI models, and 42% weigh GDPR, HIPAA, or industry-specific compliance when choosing providers, per SAPinsider research. These are procurement filters and architecture inputs.

Caution shapes the rollout, too. SAPinsider research found that 47% of organizations start with small-scale pilots to validate use cases and ROI. In comparison, 28% specifically target AI within SAP BTP to improve returns on existing SAP investments. Pilots begin small, but the moment they encounter production-like SAP data, the runtime becomes a governance boundary.

That is because there is an organizational fault line underneath all this. Edge Integration Cell typically resides within the SAP competency center as an integration tool, while AI governance sits with security, legal, or the CIO. Yet the cluster moving a customer record or invoice toward an AI process is still logged as middleware. As SAP cloud and AI security strategies fold in Kubernetes tooling, anomaly detection, zero trust, and consistent cross-environment protection, that mismatch becomes harder to ignore.

Finally, SUSE AI does not replace SAP governance. It is positioned for the private, hybrid layer where SAP data, the integration runtime, and AI controls must finally meet.

What This Means for SAPinsiders

Treat EIC as a residency and governance boundary. Enterprise Architects must map every hybrid iFlow that could later call AI, flag those carrying regulated data, and document where execution occurs before any model is wired into the system.

Assign a single owner for the Kubernetes layer. CIOs must ensure that a single person owns the Kubernetes layer beneath hybrid SAP BTP and that it is folded into the AI trust perimeter. This will ensure that data-exposure decisions get made while pilots are small rather than after they hit production.

Run the PI/PO migration and AI-governance hardening as a single program. For systems integrators, the priority should be to run AI governance so that it scopes cluster hardening and identity, and models access policy into the statement of work. They must also confirm whether a customer’s EIC will run on SUSE-powered Kubernetes before committing to a direct SUSE-to-runtime design.