SAP draws the line between AI usage and AI returns
Most enterprise AI consumption still goes to what SAP CFO Dominik Asam calls the low-hanging fruit: chatbots and coding assistants. In an interview reported by Reuters after SAP's second-quarter results, he argued that meaningful returns require AI to move into more complex processes such as finance and supply chain.
That sounds obvious, but it exposes a gap in many AI programmes. Buying more licences and generating more tokens proves usage. It does not prove that the company closes its books faster, resolves supply-chain exceptions sooner or reduces the effort needed to process an invoice.
The business case starts when AI changes the flow of work. It also gets harder at exactly that point.
In a core process, errors do not stay inside the chat window
A weak chatbot answer is usually visible and easy to discard. In a multi-step finance or operations workflow, one bad classification can affect the next calculation, approval or system update. Asam's warning is that errors can compound across steps, while compliance requirements raise the level of assurance expected from the system.
This changes the implementation question. Accuracy in a standalone demo is not enough. Companies need to know which sources the system used, which actions it may take, when a person must approve the result and how an exception is recovered. Permissions, logging, evaluation and rollback are part of the workflow, not optional controls added after launch.
The more valuable the process, the less sensible it is to treat AI as a plug-and-play model.
Messy data does not become trustworthy because a model can read it
Asam also challenges a persistent shortcut: the idea that AI will somehow resolve fragmented legacy data on its own. A model can search, summarize and combine information, but it cannot decide which duplicate customer record is authoritative or whether an outdated procedure still applies without rules and context.
For production AI, the knowledge layer has to make business information usable. That means identifying trusted sources, preserving permissions, handling versions and connecting the output to the process in which it is used. Data quality is not a preliminary clean-up project that has to be perfect before anything can start. It is a design constraint that must be made explicit for each workflow.
A focused implementation can therefore start small: one process, a bounded set of sources and a clear definition of what the system may prepare or execute. That creates measurable value while improving the knowledge layer around real work.
The best model is the cheapest reliable option for the task
The most powerful model is not automatically the best operational choice. According to Reuters, Asam expects companies to use the cheapest reliable tool that can produce the required outcome safely — whether that is conventional software, an open-source model or a frontier model.
That is a stronger buying principle than choosing one vendor for every use case. A document check, an exception classification and a complex investigation have different requirements for quality, speed, cost and data handling. The architecture should allow the tool to fit the task, while the company keeps one set of controls around the complete workflow.
Measure the economics at that same level. Cost per token says little on its own. Cost per correctly completed case, including human review and recovery from failures, tells the business whether the system can scale.
The practical route from chatbot to operating capability
SAP's own Q2 product update illustrates the direction of travel. It describes agents working across billing, expenses, contracts, order reliability, HR and manufacturing, often with business context and human oversight. The relevant signal is not that every company should buy the same suite. It is that enterprise AI is moving from a generic interface towards process-specific execution.
For a company deciding what to do next, four questions are more useful than another model comparison:
1. Which recurring process has enough volume, delay or error cost to justify intervention?
2. Which data and business rules make a result trustworthy?
3. Which steps may AI prepare, and which actions require approval?
4. What outcome will prove value: cycle time, error rate, capacity, cost per case or avoided leakage?
Answer those questions for one real workflow and AI becomes an operating capability. Skip them and even the strongest model remains an expensive chat window.
Laava's perspective
Moving beyond chatbots does not mean jumping straight to uncontrolled autonomy. It means connecting data, methods, tools, governance, channels and agents around a defined business outcome. That operating layer is what lets AI work safely inside existing systems instead of beside them.
The sensible first step is a bounded production use case with measurable value, explicit sources and clear approval gates. Build it as if it really has to run. Then reuse the knowledge, integrations and controls for the next process. That is how isolated experiments become an AI-native operation.