Bring SAP business context to enterprise AI, wherever AI creates value

AI doesn’t have to live in SAP to understand SAP. 

Yet we see two assumptions shaping many SAP + AI discussions. One is that AI should live in SAP because the data is there. The other is that once SAP data is made available somewhere else, AI will understand what it means. 

Both assumptions are expensive. The first leads to overlapping AI capabilities and licenses. The second leaves AI with access to SAP data but without enough of the business context behind it. 

Consider a sales manager trying to understand why an important customer delivery is at risk. The answer needs order and inventory information from SAP, customer history from CRM, recent emails and Teams conversations, and contract terms from a document management system. SAP is essential to the answer, but it is one source among several. Meanwhile, the sales manager spends the working day in Microsoft 365. 

Where should that person interact with AI? 

Paying for AI twice 

Many large SAP customers already have Microsoft 365 Copilot while evaluating Joule and SAP’s growing portfolio of AI capabilities. CRM, service management and HR platforms are adding their own assistants and agents at the same time. 

If every platform brings its own AI, customers end up paying several times for overlapping capabilities. They also integrate each one separately and ask employees to adopt yet another interface. 

For the sales manager above, Joule would need to deliver incremental value compared with Copilot equipped with the right SAP context. The fact that some of the required data comes from SAP is not a business case on its own. 

There are use cases where staying close to SAP makes much more sense. If SAP provides a ready-made capability with process logic, semantics, authorizations and actions already built in, recreating it elsewhere simply adds cost. For a controller working through period-end close inside SAP, for example, Joule may be the natural choice. 

The comparison needs to include the full cost of delivery: licenses, implementation, integration, maintenance, governance and adoption. AI capabilities and commercial models are changing quickly as well, so choices made today should leave room for what becomes available next. 

Data without meaning 

The second assumption is harder to spot. SAP business context goes beyond the data itself: it includes the business objects, relationships, processes, authorizations and semantics that give that data meaning. 

Getting SAP data to an AI platform is technically solvable. Getting AI to understand what that data means in a business process is harder. 

Take a WBS element, for example. Creating one is not simply about filling in a set of fields. AI needs enough context to determine where it belongs in the project structure, which information is required and which SAP rules apply. 

Moving the underlying data to a data platform does not automatically bring all of that meaning with it. For reporting, this can sometimes be addressed through modelling. For AI that is expected to support decisions or trigger business processes, preserving the right context becomes even more important. An AI system can otherwise produce a plausible answer while misunderstanding what the SAP data actually represents. 

This is one reason SAP Business Data Cloud is worth watching. SAP is putting increasing emphasis on governed data products and preserving SAP semantics as business data becomes available across a broader data and AI landscape. 

From understanding to action 

Context is only half of the picture. As agents move from answering questions to doing work, they also need ways to interact with SAP. This is where APIs and MCP become relevant. 

At Vivicta, we have already built this for a customer. An MCP-based connection allows Microsoft Copilot to create WBS elements in SAP S/4HANA. The user works through Copilot, while SAP remains responsible for executing the business process with its rules and controls. 

The example is small, but the architecture behind it is significant. SAP can remain the trusted transactional core without being the place where every AI interaction happens. 

The control requirements also change once AI starts taking action. Reading an order status and creating a project structure carry very different risks. Identity, authorizations and auditability therefore need to be part of the architecture from the beginning. 

An SAP-deep, ecosystem-open approach to AI 

SAP customers need deep a understanding of SAP business objects, processes and controls. At the same time, their AI landscape increasingly extends across Microsoft, SAP, data platforms and other enterprise technologies. 

Connecting those worlds requires more than SAP expertise or AI expertise in isolation. 

At Vivicta, we combine deep SAP understanding with the ability to work across the wider data and AI ecosystem. We make the right SAP context and capabilities available where they create the most value. 

The broader maturity challenge is clearly visible. Vivicta’s Nordic AI Navigator found that only 14% of surveyed Nordic organizations had reached strategic levels of AI maturity. Moving from individual experiments to business value at scale requires more deliberate decisions about use cases, architecture, governance and economics. 

Start with the work 

For us, the starting point is the work itself. Define the business problem and the user’s workflow first. Then determine what business context AI needs and what it needs to be able to do. Only then design the AI experience and architecture, with economics and governance shaping those choices. 

This can lead to Joule, Copilot, another platform or a combination of them. More importantly, it prevents the platform decision from coming before the business problem. 

AI does not need to live in SAP to make SAP more valuable. But when AI relies on SAP data, the business meaning behind that data needs to travel with it.