Q&A — Moving GenAI into Mission-Critical SAP: A Conversation with SAP’s Mukesh Kumar

The gap between what executives say about generative AI and what is actually running in production is wide, and most people are reluctant to admit how wide it is. Mukesh Kumar is a Premium Engagement leader and Midwest AI Champion at SAP America. He sits on the Technical Review Committee for SAP Sapphire and the ASUG Annual Conference 2026. Kumar recently designed and deployed an original automation framework that handles complex transactions in core enterprise systems. We sat down with him to hear what he is seeing across customers, how he built the framework, and what it delivered once it went live at volume.

SAPinsider (SAPi): You’ve been in the room with a lot of customers lately, including John Deere and Tapestry. What are those conversations revealing about the gap between public executive statements on generative AI and what is happening on the ground?

Mukesh Kumar (MK): There is a distinct gap right now, and it is wider than most people admit. In public, every leader has an AI strategy and a confident roadmap. However, the honest version can be heard in the room: many pilots, very little in production. The pattern I keep seeing is that ambition is set at the enterprise level, but value only shows up at the process level. Executives talk about sweeping transformations. The people who run these systems daily face a different reality. They care about eliminating manual transcription errors across thousands of daily orders, maintaining system stability, improving operational efficiency, and avoiding compliance risk.

The real lesson is that the organizations getting somewhere are not chasing a massive, enterprise-wide AI mandate on day one. They find a specific, high-friction bottleneck where an error carries direct financial or regulatory consequences. Then they fix that concrete problem using technology they already own, instead of chasing a theoretical future state.

SAPi: Many organizations first try to solve document processing and transaction workflows with traditional OCR or RPA. Why do those approaches tend to stall when applied to complex enterprise processes?

MK: OCR has been tried for years, but it breaks down because documents are unstable. OCR leans on fixed templates, so the moment a vendor switches format, your templates break, and you are back to rebuilding rules.

It also lacks contextual understanding. It might extract a local tax ID, but it cannot map that ID to an internal business partner in SAP S/4HANA. The team ends up matching and validating everything by hand anyway, as it has not saved the work.

Stitching RPA on top of OCR is the common fallback. Now you have two tools, two governance models, two sets of credentials, and a pipeline that breaks every time SAP ships an update. The IT team runs regression tests forever. That is not automation but a permanent maintenance contract you are funding.

SAPi: You designed and deployed an original automation framework for a global agricultural company. Walk us through the business problem, the high-level architecture, and which components you built from scratch versus reused from native SAP capabilities.

MK: That customer based in Argentina faced three stacked problems: operational bottlenecks, regulatory exposure, and an active audit finding. During peak season, consignment sales orders flooded in by email as PDFs, including messy scans and photos of handwritten sheets in multiple languages. Argentine regulations require that these chemical orders be posted and invoiced in the same calendar month in which they are delivered. No exceptions or rollovers. To keep pace, the company’s 15-member customer service team started collapsing multi-line dealer orders into a single product line just to close the books on time. The totals matched, but the line items did not tie back, and that triggered an internal audit finding.

We built an intelligent automation framework on SAP Business Technology Platform (BTP) to keep a clean core. It runs as a seven-step process from inbox to sales order posting, using SAP Build Process Automation to monitor inboxes and SAP Document AI for the extraction layer.

The critical shift was a custom extraction schema that tells the model what to find- customer, material, quantity- rather than where to find it. Because the system reads contextually, it does not break when a dealer changes their layout. We then used existing Identity and Access Management and a secure Cloud Connector for real-time validation against live master records in SAP S/4HANA. The custom schema, the validation logic, and the master data mapping rules were original work. The underlying infrastructure was native SAP.

SAPi: It is easy to generate impressive numbers in a sandbox. What did this framework deliver once it faced live transaction volumes in production?

MK: Production numbers are the only ones that matter. We deployed in Q3 2025, and the Q4 2025 results show the immediate impact. The system processed 5,780 sales orders in that quarter alone. Moreover:

• 70% of consignment sales orders now flow through the automated pipeline.

• Manual effort per order dropped by 90%.

• The same 15-member team absorbed a 30% increase in transaction volume without adding a single headcount.

• The company saved 1,050 annual person-hours and closed month-end two days earlier than before.

The operational metrics are good, but resolving the compliance risk was the real victory. Because the AI preserved every original line item exactly as submitted, it eliminated the shorthand data entry that caused the audit finding. That created a clean, end-to-end audit trail.

The most important part is what did not change. We did not build separate AI infrastructure, and the customer service team did not have to learn a new application. They kept using email.

SAPi: How can organizations balance automated execution with the governance controls that Finance expects, and where does this framework go next?

MK: Governance is designed in, not bolted on, and that is the whole point. We kept exactly one manual checkpoint, a human in the loop for validation exceptions. The step earns its place by training the model on edge cases during the pilot. Because we built on existing IAM and standard SAP S/4HANA APIs, every transaction inherits the same controls that Finance already trusts.

The next step we are prototyping is agentic. We want an AI agent to triage those exceptions, propose the correct fix, and route only the truly ambiguous cases to a person. That is where production generative AI is heading in 2026: more autonomy under the exact same platform governance.

SAPi: For leaders planning their own roadmap, should they start with an enterprise-wide AI strategy or a single high-impact use case?

MK: Start with one use case that has a dollar figure or a compliance penalty attached to it. I am blunt about this with clients. An enterprise-wide AI strategy that is not anchored to a funded, measurable process is just a very expensive opinion. Pick the most fundable use case, not the fanciest one.

The framework we built for the agriculture company did not begin as an AI program. It began as a mission to pull the enterprise out of serious regulatory trouble. An operational bottleneck during peak season, a hard Argentine deadline, and a live audit finding set it off. The AI was just the means. The audit finding was the reason anyone wrote a check.

Once that one process works and you can show production numbers, you have earned the right to talk about strategy. Do it the other way around, and you spend a year building slideware.

What This Means for SAPinsiders

Anchor the first GenAI project to a funded problem. Organizations do not need to scrub all their legacy master data before they start, and waiting until they do is how AI programs stall before they ship. Kumar’s framework validates incoming data in real time against live SAP S/4HANA records through the Cloud Connector. When something does not match cleanly, the system flags it for a human rather than guessing, and each flagged exception trains the model over time. For CIOs and AI leaders, the lesson is to stop treating data perfection as the gate. Pick the one process that carries a dollar figure or a compliance penalty, point real-time enrichment at it, and let live transactions surface the data issues that actually matter.

Plan for an 8- to 12-week native build, and protect the structure to make it fast. The timeline is tight when using a premium engagement delivery model: one to two weeks of discovery to map the business problem, six to eight weeks to build on SAP BTP, then a realize phase for testing, user training, go-live, and hypercare. The speed comes from configuring on top of native SAP capabilities instead of building and integrating a parallel stack. For enterprise architects and ERP program managers, that is the planning number to socialize with stakeholders, and the discipline to defend. Every week spent bolting on a separate toolchain adds to this timeline and the permanent maintenance burden.

Build governance in from day one, so Finance trusts the automation by default. The framework maintains exactly one manual checkpoint, a human-in-the-loop for validation exceptions, and, because it runs on existing IAM and standard SAP S/4HANA APIs, every transaction inherits the same controls Finance already trusts. That is what let the same solution clear a live audit finding rather than create a new one. For finance and compliance leaders, the takeaway is to make governance a design input, not a retrofit: insist that any AI touching transactions reuse the existing identity, access, and API controls. Then watch where the build goes next. Agentic triage that proposes fixes and routes only the genuinely ambiguous cases to a person, all under the same platform governance.