Puneet Khatri is Head of Services – Americas at Libelle, a global SAP software company, where he oversees delivery across more than 60 North American enterprise customers. With over 18 years of experience in SAP technology leadership, he specializes in disaster recovery, high availability, system resilience, and data anonymization. He is the originator of the “Five Levels of Autonomous SAP Operations” maturity framework, a published author with SAP PRESS and Disaster Recovery Journal, and serves as a judge for the Stevie and Globee international technology award programs. In this exclusive interview with TechBullion, he discusses how artificial intelligence is transforming SAP automation, why data masking has become a frontline cybersecurity discipline, and what enterprises get wrong when they try to combine the two.
Q1. Puneet, thank you for joining us. Can you start by telling our readers about your background and what you do today?
Thank you for having me. I have spent more than 18 years in the SAP technology space, almost entirely focused on one question: how do you keep mission-critical SAP landscapes running, recoverable, and secure at enterprise scale? Today I lead services delivery for the Americas at Libelle, a global SAP software company, where my teams support more than 60 North American enterprise customers across disaster recovery, high availability, system copy automation, and data anonymization. Before that, I spent years hands-on in SAP Basis and infrastructure roles, which shaped how I think – I have personally lived through failed failovers, botched refreshes, and 2 a.m. recovery calls. Everything I write and build now, including my maturity framework for autonomous SAP operations, comes from that operational reality rather than from a whiteboard.
Q2. You work at the intersection of two hot topics: AI-driven automation and data security. How did those two threads come together in your career?
Organically, because in real SAP landscapes they are the same problem. For years my world was resilience – making sure systems fail over cleanly and can be rebuilt fast. But every resilience workflow moves data: refreshes copy production data into test systems, DR drills replicate it across sites, automation pipelines touch it constantly. The moment you automate data movement at scale, you multiply the number of places sensitive data can land. So data masking stopped being a compliance checkbox and became a structural part of resilient architecture. AI accelerated that convergence. AI-driven operations need enormous amounts of system and business data to learn from, and AI-driven attackers are getting better at exploiting any copy of that data they can find. You cannot be a serious automation practitioner today without also being a data protection practitioner.
Q3. Let’s start with the automation side. How would you describe the current state of AI in SAP operations?
We are in a genuinely transitional moment. For two decades, SAP automation meant scripts and schedulers – deterministic tools that did exactly what they were told. What has changed is that AI can now handle the judgment layer: anomaly detection that understands what “normal” looks like for your specific landscape, predictive models that flag a database problem days before it becomes an outage, and increasingly, agentic systems that can plan and execute multi-step operational tasks. That said, I always caution people that the marketing is ahead of the median reality. Most enterprises I work with are still automating in fragments – a script here, a monitoring tool there – while their core operations remain manual. The technology has leapt forward; organizational adoption is moving much more slowly.
Q4. You created the “Five Levels of Autonomous SAP Operations” framework. Can you walk us through it?
I borrowed the mental model from autonomous driving because it gives people an honest vocabulary for where they actually are. Level 0 is fully manual operations – humans do everything. Level 1 is assisted operations: monitoring and alerting help humans react faster, but humans still execute. Level 2 is partial automation, where scripted routines handle repetitive tasks like system copies or kernel patches under human supervision. Level 3 is conditional autonomy – the system executes end-to-end workflows and only escalates exceptions to humans. Level 4 is high autonomy, where AI-driven operations handle prediction, prevention, and self-healing across defined domains. Level 5 is the aspirational end state: a self-managing SAP landscape. The framework’s real value is diagnostic. When a leadership team maps themselves honestly, they usually discover they are at Level 1 or 2 while their strategy decks assume they are ready for Level 4. That gap is where projects fail.
Q5. Where do most enterprises actually sit on that maturity curve today?
Across the enterprise customers I work with, the honest answer is Level 1 to Level 2, with islands of Level 3. Companies have invested heavily in monitoring and alerting, and many have automated specific high-pain workflows – system refreshes are a classic example, because doing them manually takes days of Basis effort and automation collapses that to hours. But very few have connected those islands into conditional autonomy, where workflows run end-to-end without a human babysitting them. The gap is rarely technological. It is trust, process, and organizational design. Teams that have been burned by a bad automated change are reluctant to remove the human from the loop, and honestly, sometimes that caution is warranted – which is exactly why I argue for climbing the levels deliberately rather than leaping.
Q6. What is the biggest misconception you encounter about AI in SAP automation?
That AI replaces the need for operational discipline. I see organizations that have messy, undocumented, inconsistent SAP operations hoping that an AI layer will absorb the chaos. It is exactly backwards. AI-driven automation amplifies whatever operating model you already have – if your processes are inconsistent, you get inconsistent automation at machine speed, which is worse than slow manual work. The second misconception is treating AI operations as a tooling purchase rather than a maturity journey. You cannot buy your way to Level 4 autonomy. You have to earn each level: standardize first, automate the standardized work, build trust in supervised automation, and only then hand over conditional autonomy. Every organization I have seen skip steps has paid for it, usually in the form of a very memorable outage.
Q7. Agentic AI is the buzzword of the moment. How real is it for SAP operations specifically?
It is real, but narrower than the hype suggests. Agentic AI – systems that can plan, decide, and execute multi-step tasks – maps naturally onto SAP operations because so much Basis work is procedural: assess, plan, execute, validate, document. An agent that can investigate a failed background job, correlate it with a recent transport, and propose or even apply a fix is genuinely valuable. Where I pump the brakes is on unsupervised agents touching production. SAP systems run payroll, manufacturing, and supply chains; an agent hallucinating its way through a production change is a business continuity event, not a software bug. My guidance is to give agents wide latitude in non-production and diagnostics, and tightly scoped, well-audited authority in production – essentially applying Level 3 conditional autonomy principles to agents. The technology will earn broader authority over time by demonstrating reliability, the same way a junior engineer does.
Q8. Your specialty for many years has been disaster recovery and high availability. How is AI changing that discipline?
Profoundly, in three ways. First, prediction: instead of reacting to failures, AI models trained on system telemetry can flag degrading storage, replication lag patterns, or memory pressure before they cascade into outages. Second, validation: the dirty secret of disaster recovery is that most DR plans are only tested once or twice a year, and the documentation is stale within weeks. Automation lets you rehearse failover continuously, and AI can analyze each rehearsal to find drift between your DR environment and production. Third, execution speed: in an actual disaster, humans under stress make mistakes – automated, pre-validated failover runbooks remove human error from the worst possible moment. My long-standing argument is that resilience must be designed in and continuously verified, not bolted on and annually audited. AI finally makes continuous verification economically feasible.
Q9. Let’s turn to the security side. Why has data masking become such an urgent cybersecurity topic?
Because attackers stopped caring which of your systems is labeled “production.” The average enterprise SAP landscape has one production system and four to eight non-production copies – development, QA, sandbox, training, project systems. Those copies routinely contain full production data: customer records, employee salaries, bank details, health information. But they get a fraction of production’s security investment – weaker access controls, broader user bases, contractors and offshore teams with wide authorizations, delayed patching. From an attacker’s perspective, that is the same crown-jewel data behind a much weaker door. I have called this “the non-critical lie” in my writing: we classify these systems as non-critical for availability purposes and then unconsciously treat them as non-critical for confidentiality, which is a completely different risk dimension. Masking breaks that equation – if the data in non-production is realistic but fake, breaching those systems yields nothing.
Q10. For readers unfamiliar with the technology, what does modern data masking actually involve?
At its core, masking replaces sensitive values with realistic but fictitious ones – real-looking names, addresses, bank accounts, national IDs – while preserving the data’s structure and business logic so applications still work. The hard part in SAP environments is consistency and referential integrity. A customer number might appear in hundreds of tables across ERP, CRM, and BW systems; if you mask it differently in each place, testing breaks. Modern masking maintains consistency across an entire landscape, so the same real customer becomes the same fictitious customer everywhere. There is also a critical distinction between static masking – permanently anonymizing data in non-production copies – and reversible techniques like encryption or tokenization. For test systems, you want true anonymization: if the transformation cannot be reversed, the data falls outside the scope of most breach notification obligations, which changes your risk profile fundamentally.
Q11. How is AI changing data masking itself?
In two directions – it is making masking both more necessary and more capable. On the capability side, the historical bottleneck in masking projects was discovery: finding every field, custom table, and custom program where sensitive data hides. In a 25-year-old SAP system with thousands of custom objects, manual discovery takes months and still misses things. AI-driven classification can scan schemas and content patterns to locate sensitive data far faster and more completely, including in the unstructured places humans forget – long-text fields, attachments, comment columns. On the necessity side, AI raises the stakes for unmasked data. Re-identification attacks powered by machine learning can correlate supposedly anonymized datasets with public information to unmask individuals, which means naive approaches like simply deleting the name column no longer count as anonymization. The bar for what constitutes “properly masked” is rising, and AI is what raised it.
Q12. There is a new wrinkle: enterprises want to train AI models on their SAP data. What risks does that create?
This is, in my view, the most underestimated data protection issue in the enterprise right now. Companies are extracting SAP data – orders, customers, HR records, financials – to train forecasting models, feed retrieval pipelines, and build copilots. Every one of those pipelines is a new copy of sensitive data living outside SAP’s authorization model, often in data lakes and vector stores with much looser governance. Worse, models can memorize training data; researchers have repeatedly demonstrated extraction of verbatim training examples from large models. So a model trained on raw HR data is itself a potential disclosure vector. The answer is to mask before data leaves the system of record. If your AI initiatives train on consistently anonymized data, you preserve the statistical patterns models need while removing the personal identifiers that create regulatory and breach exposure. Masking is becoming a prerequisite for responsible enterprise AI, not just for test systems.
Q13. How do regulations like GDPR, CCPA, and HIPAA factor into all of this?
They are usually what gets the budget approved, frankly. GDPR made the position explicit: properly anonymized data is no longer personal data, which means masked non-production systems largely exit the regulation’s scope – no data subject access requests against your QA system, no breach notification if a sandbox is compromised. CCPA and the growing patchwork of US state privacy laws push in the same direction, and HIPAA has long required minimum-necessary access to health information, which unmasked test systems violate almost by definition. What I tell executives is to stop thinking of masking as a compliance cost and start thinking of it as scope reduction. Every system you anonymize is a system you no longer have to defend, audit, and report on to the same standard. In an environment where regulators are also starting to scrutinize AI training data, that scope reduction is one of the highest-leverage security investments available.
Q14. Can you share a real-world example of what this looks like in practice?
Without naming clients, a representative case: a global manufacturer running a large SAP landscape needed to refresh its QA and development systems regularly from production, but every refresh copied hundreds of gigabytes of customer and employee data into systems accessed by contractors and offshore teams across multiple countries. Their old approach was a manual masking script that took days, covered only a fraction of the sensitive fields, and broke referential integrity often enough that test teams distrusted the data. We implemented automated, landscape-consistent anonymization integrated directly into the refresh workflow – so masking is not a separate project someone can skip under deadline pressure, it is simply how a refresh works. The refresh cycle got faster, not slower, because automation replaced the manual scripting, and the compliance team could demonstrate that no production personal data existed outside production. That last point transformed their audit conversations.
Q15. When enterprises combine AI-driven automation with data masking, what does the architecture look like?
The principle I push is “protection embedded in the pipeline, not appended to it.” Concretely: system copy and refresh automation should invoke masking as an integral workflow step, so anonymization happens before any human or downstream system touches the copied data. AI-driven data discovery should run continuously, because SAP landscapes change – new custom fields and tables appear constantly, and a masking rulebook from two years ago is guaranteed to have gaps. Monitoring and anomaly detection should watch non-production systems with the same seriousness as production, because that is where attackers increasingly go. And AI training pipelines should draw from anonymized extracts by default, with raw data access as the tightly controlled exception. When you assemble those pieces, you get something powerful: automation makes protection consistent and effortless, and protection makes automation safe to scale. Each one de-risks the other.
Q16. What is the right balance between automation and human oversight, especially in high-stakes SAP environments?
My framework answer is that oversight should be proportional to blast radius and inversely proportional to demonstrated reliability. Routine, reversible, well-rehearsed operations – refreshes, monitoring responses, non-production changes – should run at Level 3 conditional autonomy, with humans handling only exceptions. Irreversible or business-critical actions – production failover decisions, data deletions, emergency changes – should keep a human in the approval loop until the automation has a long, audited track record. The mistake I see in both directions: some organizations insist on human approval for everything, which means their expensive engineers spend their days clicking “approve” on routine tasks and automation delivers no leverage. Others flip the switch to full autonomy after one successful pilot. The disciplined path is graduated trust – expand the automation’s authority in measured steps, with metrics, exactly as you would expand a new team member’s responsibilities.
Q17. How should SAP Basis professionals and IT teams adapt their skills for this AI-driven era?
The honest message I give Basis teams is that the job is changing from executing operations to engineering and supervising the systems that execute operations. The person who manually performs system copies is automating themselves out of relevance; the person who designs, validates, and continuously improves the automated copy-and-mask pipeline is more valuable than ever. Practically, that means adding skills in scripting and orchestration, understanding how AI-driven monitoring and agents actually work well enough to challenge their outputs, and – this is underrated – developing data protection literacy. The Basis administrator who understands anonymization, regulatory scope, and secure data flows sits at the intersection of two budget lines, operations and security, and that person becomes very hard to replace. Deep SAP knowledge does not become obsolete; it becomes the judgment layer that makes automation trustworthy.
Q18. What are the most common mistakes companies make when implementing AI automation in their SAP landscapes?
Five recur constantly. First, automating broken processes – encoding today’s inconsistencies into software instead of standardizing first. Second, skipping maturity levels – attempting predictive, self-healing operations before basic runbook automation is stable. Third, ignoring non-production – pouring effort into production automation while test systems, where most changes and most data copies happen, stay manual and unprotected. Fourth, treating data protection as a later phase; retrofitting masking into established automated pipelines is dramatically more expensive than embedding it from the start. And fifth, underinvesting in the people side – automation initiatives are quietly sabotaged when teams fear they are automating their own jobs away, so leaders need to be explicit that the goal is elevating the work, and then actually follow through with reskilling. Notice that only one of those five is a technology problem. That ratio holds across every failed initiative I have reviewed.
Q19. Looking ahead three to five years, how do you see AI in SAP operations and data security evolving?
I expect Level 3 conditional autonomy to become the norm for well-run SAP operations – end-to-end automated workflows with humans on exceptions – and credible Level 4 capabilities in specific domains like performance management and refresh operations. Agentic AI will mature from demos into supervised operational colleagues with audited, scoped authority. On the security side, I expect the distinction between production and non-production security to largely dissolve; boards and regulators will ask where sensitive data exists, not which environment label it carries, and anonymization-by-default for every copy will become standard practice the way encryption-in-transit did. The wildcard is adversarial AI – attackers are automating too, and AI-powered reconnaissance will find exposed test systems and re-identify weakly anonymized data faster than ever. That arms race is precisely why I tell enterprises the cost of standing still is rising every quarter. Autonomous operations and rigorous data protection are becoming the price of admission, not a differentiator.
Q20. What advice would you give to technology leaders who are just beginning this journey?
Three things. First, be honest about where you are. Map yourself against a maturity model – mine or any other – with brutal candor, because the most expensive mistakes come from strategies built on flattering self-assessments. Second, pick the workflows where automation and protection reinforce each other, and start there. System refresh with embedded masking is my favorite starting point: it delivers visible speed gains for IT, measurable risk reduction for security, and audit evidence for compliance, which means three stakeholders defend the budget instead of one. Third, treat this as an operating model change, not a procurement exercise. Assign ownership, measure progress level by level, and celebrate the boring wins – the refresh that ran overnight without a human, the audit that closed without findings. Resilience, autonomy, and data protection are all built the same way: deliberately, incrementally, and by design. The organizations that internalize that are the ones that will still be standing when the next disruption – technical or adversarial – arrives.
About Puneet Khatri
Puneet Khatri is Head of Services – Americas at Libelle, where he leads SAP services delivery for more than 60 North American enterprise customers. He is the creator of the Five Levels of Autonomous SAP Operations maturity framework and a published author on SAP resilience, disaster recovery, and data anonymization. He serves as a judge for the Stevie Awards and Globee Awards technology programs.
Connect: linkedin.com/in/puneet-khatri-42969114 | puneetkhatri.netlify.app
