InfoVision does not charge for job offers or any kind of training. Beware of fraudulent fee requests and job offers.
Insights
Linkedin X-twitter Youtube Instagram Facebook

Category: Uncategorized

Why AI Pilots Don’t Scale and What Enterprise Leaders Are Doing Differently

Posted on by siteowner

Almost, every enterprise today has AI pilots.

Yet, very few have been able to transform those pilots into enterprise capabilities.

Over the past few years, organizations have invested heavily in AI experimentation. Teams have built proofs of concept, deployed copilots, tested large language models, and explored countless use cases. Yet despite the enthusiasm, many organizations remain stuck in the ‘value realization gap’, where promising pilots fail to evolve into scalable business capabilities.

The question is no longer whether AI works.

The real question is whether organizations can make AI deliver measurable business value, repeatedly, responsibly, and at scale.

That challenge formed the centerpiece of a recent webinar featuring leaders from financial services, consumer operations, life sciences, and technology services. While the industries represented were vastly different, the conclusions were remarkably similar.

The organizations creating value from AI are not necessarily building better models. They are building better systems, stronger operating models, and more disciplined approaches to decision-making.

About the webinar

The AI Outcome Imperative: How Enterprise Leaders Are Scaling Real Business Value

Moderator: Priya Reddy, Founder & CEO, AI & Data Strategy & Innovation, Priya Reddy Consulting

Panelists:

  • Rik Khurana, Head of Generative AI, OneMain Financial
  • Ipshita Chakraborty, Director Data Science & Applied AI, HelloFresh
  • Arpita Bhowmick, Life Sciences and Pharma, Head of Commercial & Patient Services IT, US, Alexion Pharmaceuticals
  • Abhilash Vantaram, VP of Emerging Tech & Global Head of Innovation, Infovision

Key Takeaways

  • AI creates value when it influences decisions, not when it produces outputs.
  • The model is rarely the hardest part of enterprise AI.
  • Governance must be embedded during design, not added after deployment.
  • Enterprise AI requires strong data foundations, operational discipline, and adoption.
  • Organizations that scale AI successfully treat it as an operating model transformation, not a technology project.

There Is Momentum. There Is Also a Gap.

One of the most interesting moments in the discussion came right at the beginning when panelists were asked to rate their industry’s readiness to scale AI.

Financial services rated itself an eight out of ten. Consumer operations and retail were cautiously optimistic at seven to eight. Life sciences reflected strong momentum but acknowledged heavier governance requirements. Technology services, meanwhile, viewed AI readiness as an existential necessity.

The takeaway was clear.  Across industries, AI enthusiasm is high. But enterprise readiness is uneven.

Many organizations are moving quickly from experimentation to implementation. The challenge is ensuring those implementations become repeatable business capabilities rather than isolated successes.

Lesson 1: The Model Is Rarely the Problem

Perhaps the most important lesson from the discussion was that AI projects rarely struggle because of the model itself.

The model is often the easiest part.  The real challenge begins when organizations attempt to operationalize AI within existing workflows, systems, and decision-making processes.

Ipshita Chakraborty shared a powerful example from a predictive customer lifetime value initiative. The model performed exceptionally well during validation. Stakeholders were excited. Results looked promising.

Yet the model created little value until the team built the operational infrastructure around it.  That meant automated retraining, performance monitoring, threshold-based promotions, governance controls, and delivering outputs directly into the workflows where decisions were being made.

The same pattern emerged in a large-scale customer feedback initiative powered by generative AI. Processing millions of customer signals required much more than an LLM. It required multilingual capabilities, privacy controls, real-time service levels, business taxonomy alignment, and integration into existing decision forums.

Only then did the AI become a business tool.

“The model isn’t done when the code runs. It is done when it is actually influencing a decision.”

– Ipshita Chakraborty

Businesses generate value when insights change into actions.

Lesson 2: AI Creates Value Only When It Changes Decisions

A recurring theme emerged throughout the discussion, regardless of industry.  The most successful AI programs are not measured by model accuracy.  They are measured by business outcomes.

In financial services, leaders are seeing value through decision intelligence, workflow automation, fraud detection, portfolio optimization, and personalized customer experiences.

In life sciences, AI is helping reduce administrative burdens, accelerate review cycles, improve patient services, and enable more targeted healthcare engagement.

In consumer operations, AI is transforming how organizations understand customers, prioritize products, and allocate resources.

What unites these examples is simple.

AI does not create value through reports, dashboards, or impressive demonstrations. It creates value when it changes decisions, influences actions, and improves business outcomes.  This shift from insight generation to decision enablement is where enterprise value begins.

Lesson 3: Build the Foundation Before You Scale

Many organizations begin their AI journeys by asking what a model or tool can do. But that often leads to scattered experiments rather than sustained business value.

Abhilash Vantaram offered a different way to think about AI value realization. He emphasized that enterprises should not build AI initiatives backwards by starting with a capability and then trying to construct a business case around it. The stronger approach is to begin with the business outcome and then determine how AI can improve it.

He highlighted two foundational principles that organizations should address before scaling AI.

The first is portfolio visibility. Before investing at scale, enterprises need a clear view of their AI initiative landscape. Every initiative should be mapped across two dimensions: “how noble is the problem, and how novel is the solution?” This exercise often reveals an uncomfortable truth. Many organizations have a heavy concentration of low-risk, incremental AI work and very little investment in frontier opportunities that can create transformational revenue impact.

The second principle is human-AI workflow design. Before AI is engineered into a workflow, organizations need to understand how humans and AI will actually work together. Not in theory, but workflow by workflow and decision by decision.

With these foundations in place, Abhilash introduced the 3I Flywheel (Implementation, Integration, Innovation) as a practical framework for connecting AI initiatives to sustained business value.

Implementation asks: Can we make AI work?

This is where organizations move from isolated pilots to production systems that deliver measurable value. The focus is not on what a model can do, but on which specific business outcome it will improve, by what metric, and over what time frame.

Integration asks: Can AI become part of how we work?

This is where AI moves beyond a single workflow and begins to connect adjacent decisions across product, pricing, operations, risk, and customer experience. Implementation may create islands of value. Integration creates ecosystems.

Innovation asks: Can AI change what we are capable of imagining?

This is where AI stops being a tool that accelerates existing processes and becomes a capability that enables new revenue streams, new customer propositions, and new business models.

The power of the 3I Flywheel lies in how each stage reinforces the next. Strong implementation builds credibility. Credibility enables deeper integration. Integration creates the connected infrastructure that makes innovation possible. Innovation then creates new applications that cycle back into implementation.

“Organizations winning aren’t the ones with the most AI initiatives. They’re the ones who achieve value realization of AI not as an additive factor, but as a multiplicative factor.”

– Abhilash Vantaram 

Lesson 4: Governance Is Not a Brake. It Is an Accelerator.

One of the strongest misconceptions surrounding AI is that governance slows innovation.  The panel argued the opposite.

The organizations moving fastest are often the ones embedding governance earliest.

Arpita Bhowmick shared examples from life sciences and pharmaceutical operations where AI is already reducing review cycles, improving patient experiences, and accelerating commercial operations.

But these successes depend on governance being incorporated from the beginning.

  • Privacy.
  • Compliance.
  • Transparency.
  • Accountability.
  • Explainability.

These cannot be post-production considerations.  They must be designed into the solution itself.

Another insight that stood out was the need for an AI orchestrator, a business and technology leader capable of connecting strategy, governance, execution, and adoption.  Without that orchestration layer, AI initiatives often become fragmented and struggle to scale.

“Outcomes are very important. Tying AI initiatives to larger business goals and objectives is the key.”

– Arpita Bhowmick

Governance is not simply about reducing risk.  It is about creating the trust required for scale.

Lesson 5: The Future Belongs to AI-Augmented Teams

The final lesson was perhaps the most human.  Technology alone does not scale AI.  People do!

As organizations deploy AI into everyday workflows, employee trust becomes a critical success factor.  When teams view AI as a threat, adoption slows.

Instead, if they view AI as a tool that removes repetitive work and enables higher-value contributions, adoption accelerates.  Rik Khurana described this shift as taking “the robot out of the human.”

AI handles repetitive tasks.  Humans focus on judgment, creativity, relationship-building, and strategic decision-making.

Organizations that embrace this mindset are creating AI-native workforces capable of continuously learning and adapting alongside technology.

“The winner in this era won’t be AI replacing humans. It will be humans using AI replacing humans who do not.”

– Rik Khurana

The future is not human versus AI.  It is human plus AI.

The Real Enterprise AI Differentiator

The panel represented four industries: Financial services, Consumer operations, Life sciences and Technology services.

Yet their conclusions converged around a single reality.  The organizations pulling ahead are not treating AI as a technology initiative.  They are treating it as an operating model transformation.  They understand that models alone do not create value.  Workflows do.  Governance does.  Trust does.  Adoption does.

And ultimately, business outcomes emerge when AI becomes embedded in how decisions are made, how teams operate, and how customers experience the enterprise.

The question for leaders is no longer whether AI works.

The question is whether their organizations are prepared to make it work repeatedly, responsibly, and at scale.

Watch the Full Webinar

At InfoVision, we help enterprises move beyond experimentation and build AI capabilities that deliver measurable business outcomes at scale. From AI strategy and engineering to governance, operationalization, and adoption, our focus is on turning AI potential into business performance.

AI, Automation, and the Human Advantage

Posted on by siteowner

AI has stopped being a future conversation. It is showing up in how teams actually work right now — in how decisions get made, how reports get built, and whether a manager spends Tuesday morning reviewing data or acting on it.

Moderating this conversation for AICoreSpot, an AI-focused community for leaders and technology experts, I kept coming back to one uncomfortable idea: this debate is almost never really about the technology. It is about understanding where it can support people, where human judgment must stay central, and how organizations can build a workplace where both actually work together.

The webinar, The Future of Work: Empowering People Through AI and Intelligent Automation, brought together Russ Felker, Chief Technology Officer at MegaCorp Logistics; Mu Qiao, Senior Director of Software Engineering at Hertz; and Pratyoosh Patel, Emerging Technology Practice Leader at InfoVision. What struck me listening to all three was that their starting points were completely different – logistics, consumer mobility, emerging tech consulting — but they kept landing in the same place: the organizations that will actually benefit from AI are the ones investing in their people, not just their tools.

AI Is Already Taking Over Pieces of Work

AI is not replacing entire roles – not yet, and probably not in the way most people fear. What it is doing is chewing through the parts of a job that nobody enjoys: reading through dashboards before a meeting, chasing status updates, moving information from one system to another.

That changes something fundamental about what a job is actually for. If the task-completion part is increasingly automated, what you are left responsible for is the thinking — knowing what to push back on, what to trust, and when a result that looks right is actually wrong.

That is why the future of work is not AI versus people. It is people working with AI, with more clarity about where each actually creates value.

Will AI replace jobs, or will it change the way people work?

The Real Shift Is From Doing Everything to Deciding Better

One of the most important changes AI brings is the movement of information work away from people.

AI can read dashboards, scan repositories, generate reports, summarize documents, analyze data, and bring useful inputs together much faster than traditional manual methods. This is already changing how teams prepare for decisions.

But that does not mean AI should own every decision.

Business decisions are rarely made from visible data alone. They also depend on context, experience, customer realities, operational constraints, relationships, risk appetite, and timing. Much of that knowledge still lives with people.

That is where human value becomes even more important.

AI can process information at speed. People still need to convert that information into judgment.

Every Employee May Need to Learn How to Manage AI

As AI becomes part of everyday work, employees will need more than familiarity with the tools, they will need a genuinely different operating mindset. Many people will have to manage not only their own time and priorities, but also how AI contributes to their work: giving it direction, checking its outputs, spotting the gaps it misses, and knowing when to step in.

The skills that made someone great at their job five years ago still matter. But there is a new layer now: knowing how to work alongside AI without either over-trusting it or ignoring it.

The future of work

What Should Organizations Automate First?

The strongest AI use cases do not always begin with the most exciting ideas, they often begin with the most repetitive work. Every organization has predictable tasks where people spend time collecting information, checking status, moving data, or completing steps that do not require deep judgment. That is where AI can create early value.

For retail organizations, these opportunities may exist across store operations, inventory follow-ups, order status checks, workforce scheduling support, customer service triage, product availability checks, and back-office reporting.

The better question for leaders is not, where can we use AI? It is, where are our teams spending too much time on work that does not need deep human judgment?

Human-in-the-Loop Will Remain Critical

Human-in-the-loop is often treated as a technical safeguard, but in business, it is also a trust mechanism. Routine tasks like status checks or standard updates can be handled well through automation. But when the situation involves empathy, exception handling, or real accountability, people still expect a human.

This matters deeply in retail. A customer checking delivery status may accept an automated response. But a customer dealing with a failed delivery, a refund problem, or an urgent service issue needs someone who understands the situation beyond a policy. Automation can handle the transaction. It cannot handle the moment when a customer is frustrated enough to leave.

When should AI handle customer or employee interactions, and when should a human step in?

Scaling AI Needs More Than Experiments

AI adoption cannot stay trapped in experiments that never move forward. Organizations need to start small, learn quickly, and scale with purpose, but a small start is only useful when it is connected to a larger direction.

For some teams, moving slowly makes sense because customer impact or operational risk is high. For others, especially in internal or low-risk environments, moving faster is possible and sensible. Either way, scaling AI needs real structure: guardrails, adoption tracking, outcome measurement, and clear evidence of business value.

Too many AI pilots get approved because the demo looks good. What gets forgotten is whether it is actually solving a problem that matters.

Workforce Readiness Begins With Showing What Is Possible

AI adoption is not only a technology rollout – it is a people transition. Teams need access to tools, but they also need confidence: to see what good usage actually looks like, to understand where AI helps and where it fails, and to know that their own role becomes more valuable, not less.

There is a big difference between a leader who says “we are adopting AI” and one who shows up to a team meeting and says “I tried this last week – here is what worked and what did not.” Teams respond to the second version. It gives them permission to experiment without looking foolish.

Many employees may have tried AI once, got a poor result, and decided it was not useful. That is one of the most common adoption blockers, and the answer is not more hype – it is better examples, better playbooks, and better support. People trust outcomes more than theory.

How can leaders help teams become more confident in using AI?

The Fear Around AI Should Be Acknowledged, Not Ignored

There is something we do not say often enough in these conversations: a lot of people are genuinely scared. Organizations have spent years hiring and rewarding people for working in a certain way and now AI is asking those same people to change how they work, how they think, and how they prove their value.

Some employees will adapt quickly, some will be skeptical, and some will struggle. Leaders cannot dismiss this with motivational language. The future-ready workforce will need both willingness and capability, but organizations must also create the right environment for people to learn, experiment, and grow into this change. AI transformation cannot succeed if people feel left behind.

AI Should Scale People, Not Simply Shrink Teams

One of the most important risks in the AI conversation is treating productivity gains only as a headcount reduction opportunity. That is too narrow, and frankly short-sighted. The better use of AI productivity gains is not smaller teams – it is better teams. Teams that can handle more complexity, respond faster, and spend less time on the administrative weight that wears people down.

There is also a practical risk in removing human capability too aggressively. Every technology can fail, and when it does, organizations still need people who understand the process, the exceptions, and the customer impact. The stronger approach is to use AI to scale people.

For retail, this matters even more. Demand shifts quickly, customer expectations are high, and store and digital operations are tightly connected. If AI is used only to cut effort, businesses may end up weakening the very human capability that protects the experience.

What is the real opportunity for companies when AI makes teams more productive?

What This Means for Retail Leaders

For retail leaders, this is not a distant strategy topic. Store teams need faster support. Customer service teams need better context. Supply chain teams need stronger visibility. Digital teams need more personalization. Back-office teams need fewer manual delays. Leaders need better inputs for faster decisions.

AI and intelligent automation can support all of this – but only when applied thoughtfully. The opportunity is not to automate everything. It is to remove friction where it slows people down, improve decision-making where teams need better information, and protect human judgment where customer trust depends on it.

Retail runs on both efficiency and empathy.

AI can improve the first. People must continue to carry the second.

The Human Advantage in an AI-Enabled Workplace

As I reflected on the conversation, one idea stayed with me: the future of work is not about choosing between people and AI, it is about designing work more thoughtfully.

AI can automate repetitive tasks, surface patterns, and help teams move faster. But it does not know what a customer actually meant when they said they were “fine” with the service. It cannot sense that a team is burning out even though the output numbers look good. And it cannot take responsibility when something goes wrong. Those things still belong to people.

The future of work will not be less human. If anything, it will demand more of us — not more hours, but more judgment, more honesty, and more willingness to own the outcomes that automation cannot.

Watch the full webinar here:
The Future of Work: Empowering People Through AI and Intelligent Automation

Ambient AI Is Not the ROI. The Redesigned Clinical Workflow Is.

Posted on by Mark A. Johnston

Healthcare may finally be moving past the AI demo phase.

For the last two years, ambient AI in healthcare has mostly been sold as a documentation fix: less typing, fewer clicks, faster notes, reduced burnout, and more face time with patients.

That story helped drive adoption. It just is not the whole story anymore.

The bigger shift is operational.

Ambient AI is starting to change how work moves through the healthcare enterprise. The note is becoming less of a static record and more of a trigger for downstream action: coding review, referrals, follow-up instructions, prior authorization preparation, quality reporting, and revenue cycle workflows.

The organizations getting the most value out of ambient AI are not simply deploying digital scribes. They are redesigning workflows around continuously captured clinical context.

In Brief

Q: What is ambient AI in healthcare?

A: Ambient AI uses voice, natural language processing, and clinical context to capture conversations during care encounters and convert them into documentation or workflow inputs. Its broader value appears when that context supports downstream work such as coding, referrals, authorization, and follow-up.

The Early Results Are Promising, But They Need Context

The strongest evidence today supports documentation burden reduction and improved clinician experience. But the results are not uniform across every setting.

Some health systems are reporting meaningful improvements in after-hours work, note closure, and clinician focus. Others are seeing more modest gains at enterprise scale.

Early Data

What the Early Data Shows

Ambient AI is showing clear promise in documentation and clinician experience, but wider impact depends on adoption depth, specialty fit, and workflow redesign.

93%

More attention during visits

Physicians said ambient AI helped them give patients their full attention. [1,2]

41%

Less after-hours work

Reduction in after-hours documentation work reported by Mass General Brigham. [3]

66%

Fewer delayed notes

Reduction in delayed note closures through a hybrid ambient documentation model. [3]

13–16

Minutes saved

More modest time savings found across five academic health systems. [4]

The emerging pattern is simple: ambient AI can improve documentation workflows, but broader operational gains depend on how deeply it is adopted and how well the surrounding workflow is redesigned.

In Brief

Q: Why do ambient AI results vary across health systems?

A: Outcomes depend on adoption depth, specialty fit, clinician trust, training, EHR integration, and whether the surrounding workflow is redesigned. Light or inconsistent usage may reduce documentation effort but is unlikely to create wider operational gains.

The Real Opportunity Starts After the Note

Historically, the clinical note functioned mainly as documentation of what already happened.

Ambient AI changes that dynamic because clinical intent becomes structured and available much earlier in the process.

Ambient

The old workflow was retrospective. The visit ended, the note was closed later, and downstream teams often had to chase missing context.

With ambient AI, the workflow becomes more concurrent. The encounter can begin producing structured inputs for coding, referrals, authorization, patient instructions, and follow-up while clinical intent is still fresh.

That is a much bigger shift than faster transcription.

Much of the operational waste sits around the note: delayed signatures, coding clarifications, incomplete documentation, referral lag, authorization rework, repeated chart reviews, and avoidable patient call-backs.

Ambient AI changes the economics of clinical context availability. When information becomes structured earlier, workflows that were previously fragmented and reactive can start becoming more coordinated and automated.

In many organizations, the operational coordination enabled by ambient AI could become more valuable than the documentation efficiency gains that initially drove adoption.

In Brief

Q: Where does ambient AI create the strongest ROI?

A: The strongest opportunity often sits after the note: fewer coding clarifications, faster referral routing, cleaner authorization packets, clearer after-visit summaries, and less repeated manual chart review across teams.

Ambient AI Is Moving Beyond the Scribe Market

The ambient AI market has become crowded quickly, with Microsoft/Nuance, Abridge, Suki, Nabla, DeepScribe, Ambience, and others competing for health system adoption.

But the real buying decision is shifting.

What Will Matter More in Vendor Selection

As AI-generated notes become easier to deliver, health systems will likely evaluate ambient AI on workflow depth, not documentation alone.

Specialty Fit

Does the solution understand the documentation and workflow needs of different specialties?

Workflow Integration

Can it connect with coding, referrals, authorization, patient communication, and revenue cycle workflows?

Governance Readiness

Does it support consent, auditability, human review, attribution, privacy, and liability controls?

Operating Fit

Can it work across EHRs, specialty systems, payer portals, call centers, and analytics environments?

Bottom line: AI-generated notes are becoming table stakes. Workflow depth is becoming the real differentiator.

As AI-generated notes become more common, healthcare organizations will need to look beyond transcription quality alone. The next layer of differentiation will come from workflow integration, specialty depth, deployment speed, analytics, governance, and how well the solution connects with the broader operating environment.

Epic’s move into native ambient capabilities may accelerate that shift, especially for Epic-heavy organizations.[5] Third-party vendors will likely need to prove value beyond note generation by supporting downstream workflows across coding, referrals, prior authorization, patient communication, and revenue cycle operations.

In Brief

Q: Why is workflow depth becoming important in ambient AI vendor selection?

A: As AI-generated notes become more common, differentiation will depend on how well ambient AI connects with specialty workflows, EHRs, revenue cycle tools, payer processes, analytics, and governance models.

Governance Is Becoming a Strategic Requirement

As ambient AI moves from note generation into downstream workflow support, governance moves from checkbox to strategic enabler.

Governance cannot be treated as a side conversation anymore.

As ambient AI moves beyond documentation and starts influencing operational workflows, the risks become more consequential.

Governance Areas That Need Clear Ownership

Patient consent
Audio retention
HIPAA and third-party processing
State recording laws
Hallucination monitoring
Auditability and attribution
Human review points
Liability boundaries

Healthcare organizations now have to think through patient consent, audio retention policies, HIPAA and third-party processing requirements, state recording laws, hallucination monitoring, auditability, attribution accuracy, human review expectations, and liability boundaries.

This is not simply a compliance issue. It is an operational scaling issue.

If healthcare organizations cannot trust AI-assisted downstream workflows, the broader workflow redesign vision stalls.

Workflow redesign also does not mean handing clinical operations to an autonomous black box. The scalable model is AI-prepared work with clear human review points, especially for clinical decisions, coding, orders, patient instructions, and anything tied to liability or reimbursement.

No governance, no scalable orchestration.

In Brief

Q: What governance is needed for ambient AI?

A: Governance should cover patient consent, audio retention, HIPAA and third-party processing, state recording laws, hallucination monitoring, auditability, attribution accuracy, human review points, and liability boundaries.

Where Healthcare Leaders Should Focus

The better strategic question is not, “Where can we deploy ambient AI?”

It is, “Where does documentation friction create the most downstream operational waste?”

For many organizations, that means focusing first on high-friction environments like primary care, specialty referrals, oncology, chronic disease management, surgical documentation, discharge planning, and prior authorization workflows.

Metrics That Show Real Value

Clinician Impact

Note closure time, documentation lag, and after-hours EHR usage.

Operational and Financial Impact

Coding clarification volume, denial patterns, referral turnaround, and days in AR.

Patient Impact

Clearer after-visit summaries, fewer avoidable call-backs, and improved follow-up adherence.

That is the real shift happening underneath the surface.

Ambient AI is becoming less of a productivity tool and more of an operational redesign initiative.

In Brief

Q: What metrics prove ambient AI is creating value?

A: Useful metrics should cover clinician, operational, financial, and patient impact, including note closure time, documentation lag, coding clarification volume, denial patterns, referral turnaround, days in AR, avoidable call-backs, and follow-up adherence.

The Scribe Is the Wedge

Ambient AI will not transform healthcare simply because it writes cleaner notes.

Its long-term value is that the clinical conversation itself becomes usable operational data.

A clinician finishes the visit. The note is drafted. Coding review starts earlier. The referral already contains better context. Patient instructions and after-visit summaries are generated faster and at a more understandable reading level. An authorization packet requires less manual cleanup. Another downstream team avoids yet another chart review cycle.

None of that feels particularly futuristic.

That is probably the point.

The most valuable healthcare AI may not be the flashiest. It may simply remove the friction healthcare organizations had quietly learned to tolerate.

References

[1] Stults CD, et al. An Ambient Artificial Intelligence Documentation Platform for Clinicians. JAMA Network Open. Published May 2, 2025.
View source

[2] American Medical Association. With ambient AI, 93% of doctors can give patients “full attention.” Published Nov. 5, 2025.
View source

[3] Mass General Brigham. Hybrid Ambient Documentation Decreases After-Hours Work, Note Delays for Physicians. Published Nov. 25, 2025.
View source

[4] Rotenstein LS, et al. Changes in Clinician Time Expenditure and Visit Quantity Associated With AI Scribes. JAMA. Published 2026. DOI: 10.1001/jama.2026.2253.
View source

[5] KLAS Research. Epic’s Ambient Speech Announcement 2025: How Epic’s Move into Ambient Speech May Shape Customer Strategies. Published September 26, 2025.
View source

Azure SRE Agent Vs. AWS DevOps Agent – A Technical Deep Dive

Posted on by Raghavendra Kamble
The era of autonomous operations is no longer a roadmap item - it is in production. Microsoft's Azure SRE Agent reached General Availability in March 2026. Amazon's AWS DevOps Agent followed on March 31, 2026. For the first time, engineering and platform teams have two production-grade, cloud-native AI operations agents to evaluate side by side. This is not a feature checklist. This analysis covers every dimension that matters to enterprise DevOps and SRE decision-makers: architecture, capabilities, integrations, autonomy controls, pricing, maturity, and strategic fit — benchmarked against the broader AIOps competitive landscape. All findings reflect the GA state of both products as of April 2026. If you are evaluating either platform for production deployment, or determining which fits your cloud footprint and team workflows, this guide is built for that decision.
$14.6B
Global AIOps market size (2024)
Grand View Research
$36B
Projected AIOps market by 2030 (15.2% CAGR)
Grand View Research
~$292/mo
Azure SRE Agent baseline cost / agent (est.)
Microsoft Docs
$0.0083
AWS DevOps Agent cost per agent-second (GA)
AWS Pricing Page

Market Context

Modern cloud infrastructure has outgrown human-speed incident management. Microservices sprawl, multi-cloud dependencies, and 24×7 uptime demands have rendered alert-driven on-call rotations unsustainable. The industry's response: AI agents that investigate, correlate, and remediate autonomously — at machine speed. The global AIOps platform market was valued at $14.6B in 2024 and is projected to reach $36.1B by 2030, at a 15.2% CAGR (Grand View Research). Enterprise adoption of AI-powered monitoring grew from 42% to 54% between 2024 and 2025 alone, driven by microservices generating tenfold more telemetry than monolithic stacks (Mordor Intelligence).

AIOps Market Growth (2024–2030)

$14.6B
2024
$17.8B
2025 est.
$21.0B
2026 est.
$24.2B
2027 est.
$31.5B
2029 est.
$36.1B
2030

Source: Grand View Research — AIOps Platform Market Report 2024–2030 | CAGR: 15.2%

Both cloud giants identified this inflection point simultaneously. Microsoft announced Azure SRE Agent at Build 2025 and reached General Availability by March 2026. Amazon launched AWS DevOps Agent at re:Invent 2025, reaching General Availability on March 31, 2026. These are not incremental feature additions. They represent a new category of autonomous operations tooling for enterprise infrastructure teams.

Product Overview & Positioning

Two cloud giants, one converging mission; but meaningfully different philosophies. Microsoft leans into the SRE discipline with maturity-model language that resonates with platform engineering teams. Amazon leads with 'frontier agent' autonomy, signalling a product designed to operate independently for hours or even days.

Azure SRE Agent

"Your AI teammate for operations"

STATUS: Generally Available (GA) Announced: Build 2025 (May) Billing started: September 1, 2025 GA Date: March 2026 Primary Focus: Azure-native SRE AI Engine: Azure OpenAI + AI Foundry Portal: sre.azure.com

AWS DevOps Agent

"A frontier agent that resolves & prevents incidents"

STATUS: Generally Available (GA) Announced: re:Invent 2025 (Dec 2) GA Date: March 31, 2026 Billing starts: April 10, 2026 Primary Focus: AWS + Azure + Multi-cloud + On-prem AI Engine: Amazon Bedrock (frontier) Regions: 6 regions: US, EU, AP

Architecture Overview

Understanding the underlying architecture reveals capability ceilings, integration patterns, and long-term product trajectories. The two products take fundamentally different structural approaches.

Azure SRE Agent — Dual-Mode Architecture

Always-On Flow (4 AAU / hour)
Continuous background monitoring · baseline learning · pattern recognition · persistent memory building
Active Flow (0.25 AAU / second)
Triggered by: PagerDuty / ServiceNow / Azure Monitor alert · conversational prompt · scheduled task
AI Reasoning Core + Code Interpreter
Python execution environment · multi-signal correlation · log + metrics + traces + deployment history simultaneously
Subagent Model (unique to Azure)
Domain-specific subagents: DB Expert · Security Agent · Custom agents — all coordinated by primary SRE Agent
Connectors (Built-in + MCP)
Azure Monitor · Log Analytics · PagerDuty · ServiceNow · Teams · Outlook · GitHub · Azure DevOps + any MCP tool
Plugin Marketplace (GA)
One-click installable capabilities from Microsoft and third-party ISVs

AWS DevOps Agent — Topology-Graph Architecture

Agent Space (logical container)
AWS account configurations · third-party tool integrations · access permissions · cross-account visibility
Application Topology Graph (auto-built)
Automatically maps resources and relationships · tracks blast radius · persists across investigations
4-Plane Correlation Engine
Telemetry (metrics/logs/traces) + Code (commits/PRs) + CI/CD (pipelines) + Infrastructure (configs/topology)
Frontier AI Reasoning Engine
Amazon Bedrock-powered · extended autonomous operation (hours/days) · hypothesis generation and validation
Dual-Console Access
AWS Management Console (Admin: manage spaces/access) + DevOps Agent Web App (Ops: investigate/resolve)
Proactive Prevention Module (unique to AWS)
Dedicated pipeline for: observability gaps · infra optimization · pipeline enhancement · continuous feedback learning

Capabilities Comparison

The table below maps each operational capability side by side. Where one product holds a meaningful advantage, it is noted in the 'Recommendations' section.
Capability
Azure SRE Agent
AWS DevOps Agent
Incident Detection & Triage
Always-on monitoring; triggers on PagerDuty, ServiceNow, Azure Monitor
Triage Agent (GA): auto-assesses severity, deduplicates tickets; triggers on CloudWatch, PagerDuty, ServiceNow, Slack
Root Cause Analysis
Multi-signal correlation: logs + metrics + traces + deploys simultaneously
4-plane correlation: telemetry + code + CI/CD + infra; 94% root cause accuracy reported in preview
Autonomous Remediation
YES — configurable (Reader to Privileged). Executes within guardrails
YES (GA) — detailed mitigation plans + code-level fixes via Kiro/Claude Code; validated fixes applied back to system
Proactive Prevention
Pattern learning + emerging risk surfacing; no dedicated prevention pipeline
Dedicated Prevention module: observability gaps, infra optimization, pipeline enhancement; feedback-driven learning
Conversational Interface
Full conv. ops + Python Code Interpreter; complex ad-hoc analysis via NL
On-demand SRE Tasks (GA): query architecture/health; create, save, share custom charts and reports
Scheduled / Automated Tasks
YES — daily health reports, weekly trends, any recurring task
On-demand SRE tasks available; no time-scheduled recurring tasks yet
Custom Skills / Runbooks
Documents, runbooks, arch diagrams, subagent instructions, Plugin Marketplace
Custom Skills (GA): add org procedures and best practices, targeted per agent type (Triage, RCA, Mitigation, Evaluation)
Learned / Adaptive Skills
Knowledge accumulation per investigation
Learned Skills (GA): agent learns from org's investigation patterns and topology over time
Code-Level Analysis & Fixes
Deploy history awareness; no direct code indexing
Code Indexing (GA): indexes repos, understands structure, detects bugs, suggests and generates code-level fixes
Triage Agent
Handled within primary agent flow
Dedicated Triage Agent (GA): auto-assesses severity, detects duplicates, links to primary investigation
Domain-Specific Subagents
Full subagent model (DB Expert, Security, Custom domains)
Custom Skills per agent type (functional equivalent); no separate named subagent model
Cloud Support Escalation
Not available
One-click AWS Support case with full investigation context pre-loaded
Azure & Multi-Cloud Support
Deep Azure-native; non-Azure resources via MCP
Native Azure workload investigation; on-premises via MCP; unified AWS + Azure + on-prem
Cross-Account Visibility
Within Azure tenant; MCP for external
Native multi-account topology; built-in cross-account resource mapping
Custom Charts & Reports
Python Code Interpreter generates charts/analysis
Create, save, share custom charts and reports via on-demand SRE tasks
Private MCP / Secure Tooling
MCP + custom Python HTTP tools
Private MCP: connect to private MCP servers securely, no internet routing
Enterprise Security (IdP/Keys)
RBAC, Azure AD, tenant-level controls
Customer managed keys + Okta and Microsoft Entra ID (IdP) direct integration
Localization
English only (current limitation)
Multi-language: responds in browser locale for global teams
Plugin / Skill Marketplace
Plugin Marketplace at GA (one-click install)
Custom Skills at GA; no public third-party marketplace yet

Integrations & Connectivity

The integration ecosystem is often the deciding factor in enterprise adoption. Both agents support MCP (Model Context Protocol) for extensibility, but their native integration catalogs reflect different strategic priorities. Azure leads on Microsoft-ecosystem depth. AWS leads on third-party observability breadth: Datadog, Dynatrace, New Relic, and Splunk are all native integrations, not MCP workarounds.
Integration
Azure SRE Agent
AWS DevOps Agent
Azure Monitor / CloudWatch
Native (deep — all Azure resources)
Native (deep)
App Insights / X-Ray
Azure Application Insights — native
AWS X-Ray — native
Datadog
Via MCP
Native built-in
Dynatrace
Via MCP
Native built-in
New Relic
Via MCP
Native built-in
Splunk
Via MCP
Native built-in
Grafana
Via MCP
Native (GA NEW) — Grafana Cloud, self-managed, Amazon Managed Grafana
Prometheus
Via MCP
Native via Grafana integration
PagerDuty
Native built-in
Native (GA NEW — was MCP in preview)
ServiceNow
Native built-in
Native built-in
Microsoft Teams
Native built-in
Via MCP
Slack
Via MCP
Native built-in
GitHub
Native (repos + Actions)
Native (repos + GitHub Actions)
GitLab
Via MCP
Native (repos + GitLab CI/CD)
Azure DevOps
Native built-in
Native (GA NEW — Azure Pipelines + code changes)
Azure Workloads
Native — full Azure resource plane
Native (GA NEW) — investigate Azure incidents alongside AWS
Jira
Via MCP
Via MCP
Amazon EventBridge
N/A
Native (GA NEW) — investigation events for custom automation
AWS Support Integration
Not available
Native — unique differentiator
On-Premises
Via MCP (custom Python tools)
Native on-prem support (GA NEW) via MCP, including topology discovery
Scheduled Tasks
Native recurring task scheduling
On-demand; no scheduled recurring task scheduling
Python Code Interpreter
Built-in Python execution engine
Custom charts/reports via on-demand chat; no raw Python interpreter
Plugin / Skill Marketplace
Plugin Marketplace at GA
Custom + Learned Skills at GA; no public marketplace
Private MCP
MCP + custom HTTP tools
Private MCP (GA NEW) — no internet routing for sensitive tools
IAM / IdP Integration
Azure AD, RBAC, tenant-level controls
AWS IAM + Okta + Microsoft Entra ID direct IdP (GA NEW)
Customer Managed Keys
Azure platform key management
Customer managed keys (GA NEW)

Autonomy & Human-in-the-Loop Controls

How much autonomy to grant an AI operations agent is one of the most consequential decisions in enterprise adoption. Both products take a graduated approach but differ in how they structure and label the autonomy spectrum.

Azure SRE Agent — Full Configurable Autonomy Spectrum

Review Mode (Supervised/Default)

The agent investigates, proposes a fix, and waits for your explicit approval before executing any remediation action.

Best for: Production systems, critical infrastructure, and security alerts.

Autonomous Mode

The agent investigates and executes approved actions immediately, reporting what it did afterward.

Best for: Non-production/staging environments and routine, trusted tasks.

AWS DevOps Agent — Investigative Focus (Preview)

At GA, AWS DevOps Agent moves beyond recommendation-only operation. The agent produces detailed mitigation plans with agent-ready specifications and — working with tools such as Kiro and Claude Code — generates validated code-level fixes that are applied directly back into the system. Operators retain the ability to steer active investigations via conversational chat. The autonomy model is maturing rapidly, with each release expanding the scope of unassisted execution. For enterprises with strict change management requirements, both products support human-in-the-loop checkpoints. The practical difference is that Azure SRE Agent makes this a named, configurable mode, while AWS DevOps Agent embeds operator steering as a continuous option throughout the investigation lifecycle.

Pricing & Commercial Model

Both products now carry production pricing. Azure SRE Agent uses a dual-component AAU billing model (baseline + active). AWS DevOps Agent uses pure active-time billing at $0.0083 per agent-second — no idle baseline charge — with a 2-month free trial for new customers and monthly credits for AWS Support plan holders. Billing starts April 10, 2026.

Azure SRE Agent — AAU Billing

  • Billing UnitAzure Agent Unit (AAU)
  • Always-On Baseline4 AAU / hour (continuous)
  • Active Task Rate0.25 AAU / second
  • Estimated Unit Price$0.10 per AAU
  • Monthly Baseline / Agent~$292 / month
  • Low-Activity (1 agent)~$322 / month
  • High-Activity (5 agents)~$6,110 / month
  • Free TierNone
  • Billing StartedSeptember 1, 2025

AWS DevOps Agent — Active-Time Billing (GA)

  • StatusGenerally Available
  • Billing ModelPay per agent-second
  • Rate$0.0083 / agent-second
  • Idle / Baseline Cost$0 — no idle charge
  • Free Trial2 months for new customers
  • Business Support+ Credit30% of AWS Support spend
  • Enterprise Support Credit75% of AWS Support spend
  • Unified Ops Credit100% of AWS Support spend
  • Example (10 inv. x 8 min)~$39.84 / month
  • Billing Start DateApril 10, 2026

Maturity & Enterprise Readiness

As of April 2026, both products are Generally Available and carry production SLAs. The maturity gap that existed during the preview period has narrowed considerably. Azure SRE Agent has a longer GA track record and broader compliance documentation at this point. AWS DevOps Agent's GA launch on March 31, 2026 brings six-region availability, enterprise security features, customer managed keys, and full compliance program eligibility.
Readiness Dimension
Azure SRE Agent
AWS DevOps Agent
Lifecycle Stage
Generally Available (GA — March 2026)
Generally Available (GA — March 31, 2026)
Production SLA
Yes — full Azure SLAs
Yes — GA SLAs apply
Regional Availability
Multiple Azure regions
6 regions: US East, US West, EU Frankfurt, EU Ireland, AP Sydney, AP Tokyo
Enterprise Support
Full Azure Support tiers
Full AWS Support tiers; credits against Support spend
Compliance Certifications
SOC 2, ISO 27001, GDPR, HIPAA scope
In scope under AWS compliance programs at GA
No-Training Data Commitment
Explicitly stated in documentation
Covered under AWS data handling policies at GA
Customer Managed Keys
Azure platform key management
Customer managed keys (GA NEW)
IdP / SSO Integration
Azure AD, RBAC, tenant-level controls
Okta + Microsoft Entra ID direct IdP integration (GA NEW)
Localization
English only
Multi-language support based on browser locale (GA NEW)
Plugin / Skill Ecosystem
Plugin Marketplace available
Custom Skills + Learned Skills at GA
Feature Stability
Committed GA feature set
Committed GA feature set

GA Customer Results: AWS DevOps Agent

Western Governors University (191,000 students) Investigation time reduced from ~2 hours to 28 minutes — 77% MTTR improvement
Zenchef (restaurant tech platform) ~75% investigation time reduction, from 1–2 hours to 20–30 minutes
T-Mobile (140M+ subscribers) Live design partner; integrated with Splunk across multi-cloud and on-premises
Granola Integrated into automated incident response with high-severity CloudWatch alarms

Source: AWS GA announcement, March 31, 2026.

Security, Governance & Compliance

Both products are built on enterprise-grade AI platforms — Azure OpenAI Service and Amazon Bedrock respectively — with strong data handling commitments. For regulated-industry procurement, both are now viable choices. The final differentiator on security will be your existing cloud governance posture and toolchain.

Azure SRE Agent

Microsoft explicitly states: 'Azure SRE Agent does not use your data to train AI models.' It inherits the full Azure platform compliance portfolio (SOC 2, ISO 27001, GDPR, HIPAA). Default Reader mode minimizes blast radius. RBAC-aligned user roles.

AWS DevOps Agent

AWS DevOps Agent now supports customer managed keys, direct Okta and Microsoft Entra ID (IdP) integration for operator portal access, and Private MCP (no confidential traffic routes over the internet). As a GA service, it is in scope under AWS compliance programs. AWS IAM governs all access controls — a mature, well-understood enterprise control plane.

Competitive Landscape

Neither tool operates in isolation. A mature AIOps ecosystem exists, with several established players holding meaningful advantages in specific dimensions. The table below positions Azure SRE Agent and AWS DevOps Agent against the broader market.
Tool
Best For
AI Maturity
Lock-in Risk
Approx. Cost
Azure SRE Agent
Azure-native, Microsoft shops
High (GA)
Azure ecosystem
~$300-700/mo
AWS DevOps Agent
AWS, Azure, multi-cloud, on-prem
High (GA — March 31, 2026)
Low-Medium
$0.0083/agent-sec
Dynatrace Davis
Enterprise, complex distributed
Very High (7+ yrs)
High (proprietary)
Premium/custom
Datadog Bits AI
Datadog-native shops
High
High (Datadog)
~$30/invest.
PagerDuty AIOps
Alert noise, coordination
High
Medium
$415+/mo *
Rootly
Incident lifecycle, post-mortems
Medium
Low
Custom
BigPanda
Event correlation, NOC teams
High
Medium
Custom
Incident.io
Collaborative incident management
High
Low
Custom

* PagerDuty annual commitment required. Source: PagerDuty published pricing | Dynatrace ARR $1.97B (Dec 2025): Dynatrace IR

Both Azure SRE Agent and AWS DevOps Agent are now formidable competitors to purpose-built AIOps platforms. Dynatrace Davis AI retains an edge in depth and maturity for complex distributed enterprise environments, built on seven-plus years of production refinement. Datadog Bits AI remains the natural choice for teams already standardised on Datadog's observability stack. For enterprises already running Dynatrace or Datadog, the relevant question is not whether to adopt AI-driven operations — it is whether a cloud-native agent adds sufficient incremental value to justify additional toolchain complexity and operational overhead.

Decision Framework & Recommendations

Both products are now GA. The decision is no longer about readiness - it is about fit. The following criteria are intended to guide that evaluation based on cloud footprint, observability stack, team workflows, and commercial model.

Choose Azure SRE Agent if...

  • Your production workloads run primarily on Azure
  • You are deeply embedded in the Microsoft ecosystem (Teams, Outlook, Azure DevOps, PagerDuty)
  • Eliminating toil from scheduled, recurring operational tasks (daily health reports, weekly trend analysis) is a priority
  • You need the Python Code Interpreter for complex ad-hoc analysis and reporting through natural language
  • You want domain-specific subagents with full customisation via the Plugin Marketplace
  • Your incident management discipline relies on the SRE methodology — SLOs, error budgets, runbook-driven workflows
  • Data sovereignty and an explicit no-training commitment are non-negotiable for your compliance team

Choose AWS DevOps Agent if...

  • Your primary workloads run on AWS with Datadog, Dynatrace, New Relic, Splunk, or Grafana as your observability stack
  • You operate in a genuine multi-cloud environment spanning AWS and Azure — the GA native Azure workload investigation support makes AWS DevOps Agent uniquely suited here
  • Your applications span AWS and on-premises infrastructure — native on-prem support via MCP is a GA differentiator
  • AWS Support escalation with pre-loaded investigation context is operationally valuable for your team
  • GitLab CI/CD is your primary pipeline tool (native integration at GA)
  • Code-level investigation, bug detection, and automated code fix generation (Code Indexing + Kiro/Claude Code) are priorities
  • You have an AWS Support plan — credits (30%–100% of Support spend) can substantially offset or eliminate DevOps Agent costs
  • You need localization for global teams operating in non-English environments

Hybrid Strategy — Recommended for Large Enterprises

For large enterprises running significant workloads on both Azure and AWS, a purposeful hybrid deployment warrants serious consideration over selecting a single platform.

  • Deploy Azure SRE Agent for Azure workloads — leverage its SRE-discipline design, scheduled tasks, Code Interpreter, and deep Microsoft ecosystem connectivity
  • Deploy AWS DevOps Agent for AWS and multi-cloud workloads — leverage native Azure investigation, on-prem support, code indexing, and superior third-party observability integrations
  • Use PagerDuty or a neutral incident platform as the cross-cloud coordination layer — both agents integrate natively with PagerDuty at GA
  • Standardize on Datadog or Dynatrace as the cross-cloud observability backbone — both agents integrate natively with these platforms
  • Account for the cost asymmetry: Azure SRE Agent carries a ~$292+/mo baseline regardless of activity; AWS DevOps Agent is pure active-time at $0.0083/sec with AWS Support credits potentially zeroing the cost

Conclusion

As of early April 2026, both Azure SRE Agent and AWS DevOps Agent are Generally Available, production-grade, and enterprise-ready. The preview-era maturity gap has closed. These are no longer experimental tools — they are deployable operations platforms with documented customer outcomes and production SLAs.

Azure SRE Agent still leads on:

Scheduled recurring task automation, Python Code Interpreter for ad-hoc analysis, the Plugin Marketplace ecosystem, SRE-discipline design language, a longer GA track record, and deep Azure-centric integration.

AWS DevOps Agent leads on:

Native integrations with all major observability platforms — Datadog, Dynatrace, New Relic, Splunk, and Grafana — true multi-cloud and on-premises reach including native Azure workload investigation, Code Indexing with automated fix generation, a dedicated Triage Agent, pure active-time pricing with no idle baseline, AWS Support credits, and localisation for global teams. Customer-reported outcomes include up to 75% MTTR reduction, 80% faster investigations, and 94% root cause accuracy.

Both products are now formidable competitors to purpose-built AIOps platforms like Dynatrace Davis AI and Datadog Bits AI. For enterprises already running these platforms, the question is not whether to adopt AI ops — it is whether a cloud-native agent adds enough incremental value to justify additional toolchain complexity. The decision is now entirely a question of fit: your cloud footprint, observability stack, team workflows, and budget model. There is no longer a technical or maturity-based reason to defer evaluation. Instrument your guardrails, define your autonomy thresholds, and begin deployment.

References & Sources

All statistical claims, pricing estimates, and market data include source links below. Verify with current vendor documentation before procurement decisions.

Analysis current as of April 3, 2026. AWS DevOps Agent reached GA on March 31, 2026. Verify with current official documentation before procurement decisions.

The Hardest Part of Enterprise AI Isn’t Technology, It’s the Operating Model

Posted on by Girish Hirde

 

“Most enterprises are not failing at AI because of technology; they’re failing because of operating model gaps.”

That thought stayed with me after a recent NASSCOM roundtable on accelerating enterprise AI adoption. I had walked in expecting a conversation around models, tools, and benchmarks. I walked out with a very different observation.

Across industries, across scales, and across maturity levels, the pattern seems to be consistent. The gap between an impressive pilot and durable business value isn’t a technology problem. It’s an operating model problem.

At InfoVision, we see this every day in our conversations with clients. That is the lens I want to share here – not as theory, but on the basis of what we’ve learned building and delivering AI at scale for enterprises across Retail, BFSI, healthcare and technology.

Beyond the Pilot

Almost every enterprise AI program I encounter starts the same way: excitement, experimentation, a handful of promising POCs. Very few cross the chasm to scaled, measurable value.

The maturity curve, as I’ve come to see it, runs something like this:

Beyond the Pilot

The most important shift in that journey is the move from a System of Work, where AI simply executes tasks, to a System of Context, where AI understands the business nuance in which it operates: the processes, the policies, the customer, the risk posture, the institutional memory. A chatbot that can answer questions is a capability. An AI that knows how your organization actually works is a strategic asset.

In Brief
What is ‘System of Context’ in enterprise AI?

A System of Context is an AI implementation that understands the business it operates in rather than simply executing generic tasks. A couple of parameters to understand the business would be the processes, policies, customers, risk posture, and institutional memory. Moving to a System of Context is what separates enterprise AI programs that stay stuck in pilot from those that scale into durable business value.

Why do 95% of AI Initiatives Never Scale?

The most common failure mode I see is deceptively simple: there is no clear end goal. Teams jump into AI without first defining what success looks like, how ROI will be measured, or what “scale” actually means for the problem they are solving.

Without that clarity, even the best pilots remain pilots. Budget gets spent, demos get built, and the organization learns a lot; however, nothing meaningful ends up in production. Clarity of outcomes is the single highest-leverage input to an AI program, and it is almost always the cheapest to get right.

The Seven Pillars of Enterprise AI Adoption

From the hundreds of conversations our delivery and consulting teams have had with enterprise leaders, a consistent set of foundations has emerged. I think of them as the seven pillars of serious AI adoption:

  • AI as a delivery model, not just a capability. AI must reshape how work gets done, not sit alongside it as a feature.
  • Tool discipline. Fewer tools, used exceptionally well, beat a sprawling toolchain every time.
  • Customer trust as a design principle. Trust is not a compliance checkbox but an architectural decision.
  • Governance and accountability. Clear ownership of models, data, and outcomes across the lifecycle.
  • Requirement engineering. Prompting, context design, and automation are the new SDLC skills.
  • Human-in-the-loop testing as non-negotiable. Oversight is not friction; it is the thing that lets you scale responsibly.
  • Reinvented service delivery models. Pods, pricing, and SLAs all have to change. Otherwise, AI just subsidises old ways of working.

In short, this is the point: enterprise AI is not a technology transformation. It is an operating model transformation.

The Seven Pillars of Enterprise AI Adoption

Where AI Actually Creates Value

For all the discussion around AI, the business conversation is surprisingly limited. The value almost always shows up in four places: engineering productivity, revenue differentiation & customer retention, outcome-based delivery improvements, and clearer trade-offs between traditional and AI-driven ways of working.

At InfoVision, one of the practical ways we de-risk this for clients is through what we call the Parallel Pod Model — roughly 30% AI-first delivery running alongside 70% traditional delivery for the same program. The split is not dogma; it is a structure. It lets our clients compare apples to apples, generate real performance data, and scale what works. We’ve seen this model cut through months of “will it work in our context” debates by producing evidence inside a single release cycle.

Underpinning this is our AI Center of Excellence and a growing library of platform accelerators – reusable assets for document intelligence, RAG-based knowledge systems, OCR-driven data extraction, and domain-specific evaluation harnesses. These accelerators exist for one reason: to compress the distance between a promising idea and a production-grade outcome. The enterprises that win with AI are the ones that don’t rebuild the same plumbing on every engagement.

Data extraction, retrieval-augmented generation, and OCR are no longer novelties – they are the competitive differentiators of the next five years.

Seven Checks Before You Go to Production

Before any AI workload moves from pilot to production, we ask our delivery teams and clients to stress-test against seven checks. None of them are glamorous. All of them are non-negotiable:

  • Security embedded early — not bolted after launch.
  • Regulatory alignment from day one, especially in regulated industries.
  • Clear ownership between pilot teams and production teams.
  • An MVP tied to a specific business outcome, not to a technology demo.
  • A deliberate integration strategy with existing systems and data.
  • Defined KPIs, agreed with the business before the build starts.
  • Clarity on the end goal — what “done” looks like, and how we’ll know.

And sitting above all seven: human-in-the-loop governance. That is how you scale AI in an enterprise context without scaling risk at the same rate.

In Brief
What should enterprises check before moving AI workloads into production?

At InfoVision, we stress-test every AI workload against seven checks before it goes live: security embedded from day one, regulatory alignment, clear ownership between pilot and production teams, an MVP tied to a specific business outcome, a deliberate integration strategy with existing systems and data, agreed KPIs, and unambiguous clarity on the end goal. Sitting above all seven is human-in-the-loop governance, a mechanism that lets enterprises scale AI without scaling risk at the same rate.

The Real Transformation

If I had to distil what I’ve learned, from our own AI CoE, from our Parallel Pod engagements, and from conversations like the Nasscom roundtable, it would be this:

AI transformation is not about doing more with AI. It is about redefining how value is created and delivered.

Trust, governance, and clarity of outcomes are the three inputs that compound. Human oversight is the enabler of scale, not the thing slowing you down. And tool overload, left unchecked, will quietly eat your productivity gains before you ever see them.

At InfoVision, we are choosing to build that discipline into our delivery model, our accelerators, and the way we engage with our clients. It is, in every sense, how we are adopting AI ourselves – by changing how we deliver, not just what we deliver.

The most honest conversations I’ve had about AI aren’t about what’s possible, they’re about what’s actually working, and what quietly isn’t.

Why Organizations Are Moving from Adobe Analytics to Adobe Customer Journey Analytics

Posted on by Surendra Mummini

It is not just a technology upgrade but a fundamental rethink of how you understand your customers

For years, Adobe Analytics was the gold standard for digital measurement. It answered the questions that mattered most in a web-centric world: Which campaigns drove conversions? Where are visitors dropping off? Which pages perform best?

Those are still valid questions. But they’re no longer sufficient.

Today’s customer doesn’t live in a single session. They discover your brand on Instagram, research on desktop, call your support center, walk into a store, and finally convert on mobile — often over days or weeks. If your analytics only captures what happens on your website, you’re seeing a fraction of the story and making decisions on incomplete information.

That is precisely the gap Adobe Customer Journey Analytics (CJA) was built to close.

From Session Data to Customer Understanding

Adobe Analytics is a session-based measurement tool. It is exceptionally good at what it was designed to do: track visitor behavior across your digital properties and surface patterns in that data.

But session data has inherent limits:

  • It treats each visit as a standalone event, disconnected from the customer’s broader journey
  • It cannot natively reconcile a logged-in desktop user with a mobile app visitor and an in-store purchase
  • It reflects digital interactions only, leaving out the CRM records, call center logs, loyalty data, and offline transactions that often explain why customers behave the way they do

CJA shifts the unit of analysis from the session to the person. Rather than asking what happened on the website, it asks what did this customer experience end-to-end – and what drove their decision?

Built on Adobe Experience Platform: A Different Foundation

The reason CJA can do what Adobe Analytics cannot comes down to what it is built on: Adobe Experience Platform (AEP).

AEP acts as a unified data foundation, bringing together all customer data, online and offline, into a standardized framework called the Experience Data Model (XDM). This is not cosmetic. It fundamentally changes what analysis is possible.

With CJA on AEP, organizations can:

  • Ingest any data source — web behavior, mobile events, CRM records, POS transactions, call center interactions, loyalty platforms, and more — unified into a single schema
  • Stitch identities across channels, connecting anonymous browsing to known customer records to create a coherent, person-level view of every interaction
  • Process data flexibly at report time, meaning teams can create new segments, dimensions, and metrics without going back to change data collection or rewrite implementation code

That last point is easy to underestimate. Traditional analytics architectures lock you into whatever questions you anticipated when you built them. CJA lets your analytics evolve as fast as your business questions do — without requiring an engineering sprint every time.

Seeing the Full Journey, Not Just a Chapter of It

One of the most practical shifts CJA enables is the ability to build cross-channel journey views that actually reflect how customers behave.

With Adobe Analytics, you might have separate dashboards for your website, your app, and your contact center — each telling a partial story, with no easy way to connect them. CJA allows analysts to:

  • Build end-to-end funnel and journey visualizations that span web, mobile, CRM, and offline touchpoints in a single analysis
  • Identify where customers fall through the cracks between channels — the moments where a great web experience hands off to a frustrating call center interaction, for example
  • Apply flexible attribution models that reflect the complexity of multi-touch, multi-day journeys rather than forcing last-click logic on non-linear behavior

The insight shift is significant: instead of optimizing individual channels in isolation, teams can start optimizing the overall experience customers have as they move between them.

Analytics That Grow with Your Business

Legacy analytics architectures can become a constraint over time. As business questions evolve, teams often find themselves limited by the dimensions and metrics baked into their original implementation.

CJA removes that constraint:

  • Unlimited dimensions and metrics — build the views your business needs today, not just the ones you anticipated when you went live
  • Flexible schema design — adapt your data model as new sources, channels, or product lines come online
  • Report-time processing — re-analyze historical data with new logic without re-collecting it, which is invaluable when business definitions change or new questions emerge retroactively

For analytics teams, this means less time waiting on implementation changes and more time generating actual insight.

This Is a Migration — Plan It That Way

It would be a disservice to suggest that moving to CJA is straightforward. Because it uses a different data processing model, identity framework, and analytical structure than Adobe Analytics, organizations that approach it as a simple swap typically run into friction.

Migration Plan It That Way

A well-planned migration involves:

  • Building a modern XDM-based data layer that can accommodate your current sources and scale to future ones
  • Running CJA alongside Adobe Analytics during the transition period to validate results, reconcile metric differences, and build team confidence before decommissioning
  • Reconsidering your measurement framework — not just migrating old reports into a new tool, but asking what questions matter now and designing your analytics to answer them

Done well, this transition is an opportunity to retire years of accumulated technical debt, consolidate fragmented analytics investments, and build a foundation that actually serves the business for the next decade.

The Bottom Line

The case for moving to Adobe Customer Journey Analytics is not primarily about features. It’s about the kind of organization you want to be.

If your analytics are still session-centric, channel-siloed, and tied to a rigid data architecture, you’re not just missing insight — you’re making decisions about customer experience with information that doesn’t reflect how your customers actually behave.

CJA gives you:

  • A person-centric view, not a session count
  • Online and offline data in one place, not three separate dashboards
  • The flexibility to ask new questions without rebuilding your implementation
  • The foundation to act on insight, not just report it

The shift from Adobe Analytics to CJA is a shift from measurement to understanding — and for organizations competing on customer experience, that distinction increasingly determines who wins.

Considering a move to Adobe Customer Journey Analytics?  InfoVision’s Adobe practice has helped organizations design and execute this transition. Contact our expert to talk through what it would mean for your data environment.

The CMS Prior Auth Rule Explained: Scorecards, APIs, and What Comes Next

Posted on by Mark A. Johnston

For years, prior authorization lived inside the payer’s walls. Providers felt it. Patients waited through it. Executives managed it as a cost center. But the market could not really compare it. That changed on March 31, 2026, when impacted payers under CMS-0057-F had to begin publicly posting certain prior authorization metrics for the previous calendar year. The first scorecard reflects calendar year 2025 – meaning the market is judging payers on pre-rule performance, not on how they are operating today.1

That timing nuance matters. The first public scorecard is being judged under a new transparency regime, but it reflects a period before the rule’s new process requirements were fully in force. Beginning in 2026, impacted payers other than Qualified Health Plan issuers on the federally facilitated exchanges must send prior authorization decisions within 72 hours for expedited requests and 7 calendar days for standard requests. Beginning in 2026, payers also have to provide a specific reason for denial for medical items and services, regardless of how the request was submitted.2

That is why this rule is bigger than compliance. CMS did not just add another reporting obligation. It made prior authorization more legible. Once CMS forces the numbers into public view, prior auth stops being just an internal process problem and starts becoming a market signal. That is an inference, but it follows directly from CMS requiring impacted payers to publicly post comparable prior authorization metrics on a recurring basis.1

The first scorecard is real, but it is still blurry

CMS is specific about what must now be posted publicly for medical items and services subject to prior authorization, excluding drugs. Impacted payers must publish approval and denial percentages, appeal outcomes, extended-review approvals, and average and median decision times for both standard and expedited requests.1

But the first year of public reporting is still pretty blunt. KFF says the new data offers limited insight, there is no breakdown by service type, no explanation of why denials happened, and prescription drugs are excluded entirely. You can compare payers at a high level, but you cannot yet cleanly separate clinical value from administrative noise. The last point is inference from KFF’s description of the data limits.3

That is the first year. It gets sharper from here.

At a Glance

What prior authorization metrics must health insurers publicly report under CMS-0057-F?

Under CMS-0057-F, impacted payers must annually publish key prior authorization metrics on their websites. These include the list of services requiring prior authorization (excluding drugs), approval and denial rates for both standard and expedited requests, appeal overturn rates, instances where review timelines were extended, and the average and median time taken to reach decisions.

The first reports, covering 2025 data, were due by March 31, 2026. However, the data is aggregated across all services, without breakdowns by service type, denial reasons, or prescription drugs, which limits its usefulness for deeper performance comparisons.

The smarter executive question is not “How often do you deny?”

The sharper question is this: How much friction do you create per clinically useful intervention?

Call it a Utilization Friction Index if you want shorthand. The point is simple: a process can approve a very high share of requests and still impose major operational drag through documentation churn, status checking, appeals, and wait time. The public reporting requirement does not calculate that index for you, but it does create the raw ingredients for the market to start asking the question. That conclusion is an inference from the metrics CMS requires payers to publish.1

How often do you deny

KFF’s Medicare Advantage analysis shows why this matters. In 2024, Medicare Advantage insurers made 52.8 million prior authorization determinations and 4.1 million were denied in full or in part. Only 11.5% of denials were appealed, but 80.7% of appealed denials were partially or fully overturned. Those overturned requests represent medical care that was ordered by a clinician and ultimately deemed necessary, but potentially delayed because of the extra step of appealing the initial decision.4

A high approval rate and a high-friction process are not mutually exclusive. That is the paradox the new transparency regime starts to expose.

2026 is the public scorecard. 2027 is the operational reckoning

CMS’s timeline makes the next inflection point clear. Impacted payers generally had to implement certain provisions by January 1, 2026, but have until primarily January 1, 2027 to meet the API development and enhancement requirements in the final rule. Those API-related requirements include the Patient Access API, Provider Access API, Payer-to-Payer API, and Prior Authorization API.5 The Prior Authorization API specifically must be populated with the list of items and services requiring prior auth, the payer’s documentation requirements for those items and services, and must support the creation and exchange of prior authorization requests from providers and responses from payers.

2026 is the public scorecard. 2027 is the operational reckoning

CMS also separately finalized the 2026 process requirements for denial specificity and faster turnaround times.6 That is why 2027 is the real operational test. In 2026, a payer can still argue that the public numbers reflect a transition-year baseline. In 2027, the architecture itself starts getting exposed. Once prior auth has to move through more standardized digital rails, the gap between a payer with a modern operating model and one still leaning on portals, phone trees, faxes, and exception queues gets harder to hide. That is inference, but it is grounded in the rule’s shift from public reporting to API-enabled exchange.5

At a Glance

What is the Prior Authorization API required by CMS in 2027, and how does it change the process?

Starting January 1, 2027, CMS-0057-F mandates a Prior Authorization API built on the HL7 FHIR R4 standard. This API enables providers to identify services requiring prior authorization, access documentation requirements, submit requests electronically, and receive decisions digitally.

This is CMS’s push to move prior auth off fragmented manual channels and onto more standardized digital exchange. While real-time decisions are not required, the automation introduced by the API is expected to significantly reduce turnaround times and streamline prior authorization processes.

Compliance is the mandate. PAS is the path.

There is one technical distinction worth keeping clean. CMS mandates the Prior Authorization API. CMS does not separately mandate PAS as a standalone fifth requirement. But it  strongly recommends that impacted payers develop their APIs to conform with certain implementation guides, and its own overview deck lists the Da Vinci CRD, DTR, and PAS implementation guides as recommended for the Prior Authorization API. That is the difference between compliance and architecture.6

From static scorecard to more liquid data

The transparency story also does not stop at a web page. The Patient Access API allows a third-party software application of the enrollee’s choosing to access the data made available through the API. CMS also requires reporting on how many unique patients had their data transferred through the Patient Access API to a health app selected by the patient, including how many had data transferred more than once.7

CMS’s 2024 overview deck further says that, beginning in 2027, impacted payers must include certain information about patients’ prior authorization requests and decisions, excluding drugs, in the Patient Access API. That does not create a consumer-grade comparison app overnight. But it does move prior auth away from static website disclosure and closer to app-accessible data in the patient’s hands. The second and third sentences are inference from CMS’s API requirements.6

Transparency creates pressure for exemption

The gold-carding angle is real, but it has to be stated carefully. KFF notes that some insurers waive prior authorization requirements for certain providers, including through gold-carding programs, and points to UnitedHealth Group’s decision to launch a national gold-card program that exempts certain providers from prior authorization requirements. KFF also notes that some insurers exempt providers through risk-based contracts.4

Separately, the American Medical Association says the federal GOLD CARD Act would exempt physicians from Medicare Advantage prior authorization requirements so long as 90% of their requests were approved in the preceding 12 months, and says the legislation was based on a similar Texas law.9

CMS-0057-F does not create gold-carding. But once payers are forced to publish aggregate prior auth performance, the pressure grows to explain why predictably approved care is still being pushed through the same tollbooth.

At a Glance

How does public reporting of prior authorization data affect health plan competition?

Public reporting under CMS-0057-F transforms prior authorization performance into a visible competitive factor. Metrics such as denial rates, turnaround times, and appeal outcomes are now accessible to providers, employers, and policymakers.

This transparency allows providers to use PA data in negotiations, employers to evaluate plans beyond premiums, and researchers to benchmark payer performance. It also increases scrutiny, especially when high appeal overturn rates highlight potential issues in initial decision-making.

CMS-0057-F does not itself create gold-carding. But transparency makes the logic behind gold-carding harder to ignore. If a provider or service line is predictably approved over time, the market has more reason to ask why the tollbooth is still there. That is inference based on KFF’s description of gold-carding programs and the public reporting regime CMS now requires.1,4

What this means for health plans and their technology partners

The cleanest way to read CMS-0057-F is not as a narrow compliance story. It is a market-structure story. The first public posting in 2026 reflects calendar year 2025 performance. The API build-out lands primarily in 2027. In between, prior authorization is shifting from a hidden workflow to a more visible, more measurable signal of operational maturity.

Payers that treat this as a documentation exercise will find themselves on the wrong side of that comparison. The ones that use the 2026 window to modernize their prior auth architecture — standardizing decision logic, reducing manual touchpoints, building toward API-ready infrastructure — will be better positioned when 2027 makes the operational gaps legible to the entire market.

2026 is the setup year. By 2027, excuses get a lot thinner.

References

  1. Centers for Medicare & Medicaid Services. Prior Authorization API. Accessed April 8, 2026.
    Source
  2. Centers for Medicare & Medicaid Services. CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) Fact Sheet. Accessed April 8, 2026.
    Source
  3. KFF. Insurers’ Prior Authorization Data Offers Little Insight Into What Gets Approved or Denied. Accessed April 8, 2026.
    Source
  4. KFF. Medicare Advantage Insurers Made Nearly 53 Million Prior Authorization Determinations in 2024. Accessed April 8, 2026.
    Source
  5. Centers for Medicare & Medicaid Services. CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Accessed April 8, 2026.
    Source
  6. Centers for Medicare & Medicaid Services. CMS Interoperability and Prior Authorization Final Rule Presentation. Accessed April 8, 2026.
    Source
  7. Centers for Medicare & Medicaid Services. Patient Access API. Accessed April 8, 2026.
    Source
  8. Centers for Medicare & Medicaid Services. General Interoperability / Prior Authorization FAQs. Accessed April 8, 2026.
    Source
  9. American Medical Association. “Gold card” approach to prior authorization introduced in Congress. Accessed April 8, 2026.
    Source

Is AI Rewriting the Rules of Retail Supply Chain?

Posted on by Sushma Joshi

With AI dominating and reshaping every industry conversation, it is natural to wonder: is this technology mere hype, or is it truly here to stay? Are we still experimenting, or have we crossed into implementations that genuinely bolster AI’s game-changing claims?

Insights from the Webinar

The Future of AI-Driven Retail Supply Chain & Transportation Management

Moderated by: Monica Umesh, Director of Retail, InfoVision

Panelists:

  • Ravi Thatavarthy, CISO, Empiric Health

  • Sameer Bhavanibhatla, Data & AI Leader


Watch the full webinar →

Retail has made real strides in AI adoption, with measurable impact for both workers and customers. This article focuses on a critical piece of that journey: supply chain and transportation management.

Most supply chain systems were built for a predictable world, steady rhythms of demand forecasting and inventory management. That world no longer exists. Margin pressure, global disruption, sustainability goals, and rising customer expectations are reshaping how retailers plan, move goods, and respond to change.

What’s needed now isn’t isolated automation but a layer of intelligence powering smarter, more resilient supply chains. The retailers who win the next decade won’t just have the best products, they’ll have the smartest supply chains behind them.

This blog shares insights from a webinar on The Future of AI-Driven Retail Supply Chain & Transportation Management, where the consensus was clear: start now, don’t wait for a perfect AI strategy.

At a Glance

How is AI changing the way you think about demand forecasting day to day?

The industry is moving from traditional demand forecasting based on historical patterns to always-on predictions. Instead of relying on static history and fixed daily updates, AI enables real-time rerouting and dynamic carrier selection.

For example, if the East Coast sees lower store traffic because of a regional holiday, AI can help teams reroute inventory to the Midwest instead of continuing to follow last month’s plan.

Ravi Thatavarthy

Challenges in AI Adoption

As against periodic forecasting, continuous prediction is the need of the hour for retailers.  Traditional supply chains looked backwards. AI-powered ones do not. They scan in every direction at once – picking up signals from traffic patterns, local events, weather disruptions, and live browsing behavior. The result: decisions that are near-real-time, not days or weeks after the fact.  The engine behind all of this? Clean, well-structured data.

This is why the panellists emphasize thinking through the lens of data first. The fundamental question to answer is: how clean is your data?

Both Ravi Thatavarthy and Sameer Bhavanibhatla make this point emphatically: AI is only as intelligent as the data feeding it. Organizations that have built well-structured, accessible data lakehouses are certainly leading the way, both for now and the future. Those still working with fragmented, siloed, or inconsistently maintained data will find that AI amplifies their problems rather than solving them.

Legacy infrastructure is also a formidable challenge. Many of these systems, while still functional, are not scalable and simply not built for the demands of the new world.  “This is a definite pain point that we need to look at”, says Sameer.  Many warehouse management and transportation systems in use today were not designed to integrate with modern AI platforms. Addressing that technical debt, in small progressive steps is critical to steering the organization in the right direction.

At a Glance

What do organizations get wrong when they try to adopt AI without the right data foundation?

Many organizations treat data as something to solve later, when in reality data is a byproduct of process. If the process itself is not coherent, the data it generates will not be reliable enough to support meaningful AI outcomes.

The better approach is to evaluate processes from the beginning and make sure each step generates the right data. When the process is sound, the data becomes usable, and AI can deliver more reliable insights on top of it.

Too often, organizations try to layer AI onto broken or poorly designed workflows and then wonder why the results fall short.

Sameer Bhavanibhatla

The Business Case: Communicating the AI Value

“I don’t see supply chain as a logistics problem. It’s more about customer experience”, emphasizes Sameer.

The moment a customer places an order, a promise is made. Every link in the supply chain, from warehouse to last-mile delivery, either honors that promise or erodes it. When retailers frame AI investment through this lens, the ROI conversation with the board becomes significantly more convincing. The question shifts from “what does this technology cost?” to “what does a broken customer promise cost us in lifetime value, repeat purchase, and brand trust?” Logistics is therefore not about moving inventory, it is about delivering on a commitment, and the organic customer loyalty that follow when that commitment is consistently kept.

For executives building the internal case for AI investment, the most effective approach is to let business owners and not IT, champion the use cases. Survey your teams to identify the highest friction, most repetitive workflows. Build targeted, high-ROI pilots such as automating contract reviews, enabling intelligent inventory replenishment, or deploying Microsoft Copilot across back-office functions. Let the results speak and let the business leaders who benefit present those results to the board.

At a Glance

How do you actually get Board buy-in for AI investment in supply chain?

One practical way to build support is to form an AI innovation group and start by identifying real pain points from across the business. From there, organizations can develop use cases with clear ROI and tie them directly to measurable business outcomes.

For example, contract review work that once required significant manual effort can be completed in under an hour using an AI agent. That kind of efficiency is easier for leadership to understand when the impact is clearly demonstrated.

The most important part is who presents the value. When business unit leaders speak about the benefits, the case for investment becomes much stronger than when it is framed only as a technical initiative.

Ravi Thatavarthy

Addressing Concerns About Trust & Governance

Trust and governance are non-negotiable, particularly given the prevalence of legacy infrastructure and understandable organizational fear around AI. The good news: both are solvable with the right architecture and the right mindset.

Education about ‘what AI is and what AI is not’, is the most powerful tool for overcoming resistance. Much of the fear around AI stems from misunderstanding: the assumption that AI bypasses access controls or exposes data that should be protected. In reality, as Ravi explains, “AI is a technology that impersonates the access of the user, meaning it surfaces only what the user is already authorized to see, nothing more.”

Role-based access control is therefore the cornerstone of trustworthy AI architecture. Any AI system deployed across supply chain operations must respect and enforce the same permission boundaries that govern human access. Beyond that, guardrails around token consumption, particularly for generative AI tools, prevent accidental cost overruns and ensure accountability across the organization.

Sameer introduced an architecture principle worth adopting broadly: micro-agent orchestration. Rather than building large, monolithic AI systems, the most resilient architectures break intelligence into small, focused agents, each responsible for a discrete task, that hand off to one another in sequence. This reduces hallucination risk, improves decision accuracy, and makes systems far easier to audit and govern.

At a Glance

How do you build trust in AI systems, especially when legacy infrastructure and compliance concerns are in the mix?

Trust in AI starts with security-first design. Architecture decisions need to account for role-based access, permissions, and guardrails before features are considered.

Without those controls, AI systems can access information they should not, creating both compliance and operational risk. Clear boundaries are essential to make these systems dependable.

Trust also improves when AI is designed as a set of smaller, focused agents that hand tasks off cleanly to one another. The more targeted each agent is, the lower the risk of hallucination and the stronger the overall system becomes.

Sameer Bhavanibhatla

Where to Start: A Practical Roadmap

Moving from discussion to action requires more than a technology decision.  The panel is united in the belief that change management is the most critical factor, and how you approach it will determine the outcome.  Getting buy-in from people at every level is integral to AI adoption. With that foundation in place, the panellists recommend the following roadmap:
ai-retail-roadmap-infographic

  1. Employee productivity first. Deploy enterprise AI tools across your organization. Build familiarity, reduce fear, and generate early wins.
  2. Target back-office functions. Inventory management, smart replenishments, contract analysis, adding intelligent dimensions to predictive analytics are good starting points.
  3. Clean your data infrastructure. As AI matures across your back-end operations, simultaneously invest in the data quality and scalability that will eventually support customer-facing intelligence.
  4. Move to the customer experience layer. Dynamic personalization, real-time inventory alignment across online and in-store channels, and AI-optimized last-mile delivery are the competitive differentiators.

Emerging Capabilities to Watch

Beyond the foundational work, the panel highlighted several areas where AI is advancing rapidly and where retailers should direct their attention:
emerging-capabilities-infographic
The conversation is just beginning. Watch the full webinar for a deeper dive.

The Rise of Specialist GCC: Rethinking Capability, Not Scale

Posted on by Sushma Joshi

India has firmly established itself as a preferred destination in the Global Capability Center (GCC) landscape. The numbers tell this story clearly.

The country today accounts for more than half of the global GCC footprint, with over 1,700 centers operating across the country and a workforce exceeding 1.9 million professionals supporting this ecosystem. The scale continues to expand, with the sector projected to grow at 12–14% CAGR towards a $110 billion market by 2030.

Yet the most important shift underway is not numerical. It is structural.  Close observers of the ecosystem are noticing the emergence of a new model: the Specialist GCC.

India is no longer just a location where enterprises extend operational capacity. It is increasingly where they build and concentrate strategic capability. This steady transition from cost-led delivery centers to capability-led innovation hubs is reshaping how organizations design their global operating models.

The narrative is shifting from extending operational capacity to building strategic capability, and from cost arbitrage to innovation-led value creation as the primary drivers behind choosing India as a GCC destination.

This evolution, particularly the rise of more specialized, capability-driven GCC models, is explored in greater depth in our eBook on the future of GCCs.  This blog distils some of the key insights driving that shift.

Moving Beyond the Scale Paradigm

The GCC model began with a clear enterprise need: optimize supply chains, digitize core systems, and consolidate shared services. The early generation of GCCs was therefore built with a defined intent: to centralize operations, standardize processes, improve control, and drive cost efficiency through scale.

These centers often scaled rapidly, supported by structured service lines, layered governance, and well-defined operational maturity frameworks. For that phase of enterprise transformation, the model worked well.

Moving Beyond the Scale Paradigm

Over time, however, the enterprise environment became far more dynamic and demanding. Innovation cycles shortened. Platform modernization became continuous. Cloud-native architectures required tighter integration. Artificial intelligence initiatives began cutting across functions. And product engineering teams increasingly operated in distributed environments.

In such a landscape, the primary challenge was no longer scale. It was coherence.

When capabilities are fragmented across geographies and vendors, architectural continuity begins to weaken. When decision-making is spread across multiple layers, responsiveness slows. And when knowledge is not retained within a stable ecosystem, innovation becomes reactive rather than intentional.

Scale without alignment introduces complexity.

Specialist GCCs are a response to that complexity

At a Glance

What is a Specialist GCC?

A Specialist GCC in India is a focused, capability-led Global Capability Center, typically structured with 25–200 experts and designed to own engineering, product, data, or AI domains rather than operate as a large-scale delivery extension.

Unlike traditional GCCs built primarily for cost efficiency and workforce scale, Specialist GCCs prioritize architectural ownership, innovation velocity, and long-term capability retention within India’s mature GCC ecosystem.

A Specialist GCC is defined not by its size, but by its architectural discipline. These centers are built around concentrated expertise and clear ownership of capability domains, enabling continuity in design, product thinking, and decision-making.

They operate less as distributed execution arms and more as embedded capability hubs within the enterprise ecosystem.

Why Mid-Sized Enterprises Are Leading This Model

A significant portion of new GCC setups now originate from mid-sized enterprises. These organizations typically operate with leaner structures and closer alignment between strategy and execution, allowing them to move with greater speed and clarity.

Unlike large enterprises that often replicate scale, mid-sized organizations are more deliberate in how they build global capability. Their focus is not on workforce volume, but on creating tightly aligned hubs that can own product stacks, advance data and AI capabilities, and lead platform, cloud, and cybersecurity initiatives.

For such enterprises, control and depth matter more than workforce volume.  Specialist GCCs offer a mechanism to build capability without inheriting bureaucratic weight of traditional models.

As the shift becomes more visible, a natural question emerges:

At a Glance

Why are mid-sized enterprises building Specialist GCCs in India?

Mid-sized enterprises are building Specialist GCCs in India to create concentrated innovation hubs without inheriting the complexity of large-scale operations.

India offers access to a deep and growing talent pool, strong digital infrastructure, and a mature GCC ecosystem, enabling organizations to build and scale high-value capabilities efficiently.

Purpose as the Primary Structural Lever

The durability of any GCC begins with absolute clarity on mandate.  A sharply articulated charter ensures structural alignment.

A Specialist GCC typically begins with a clear articulation of its role within the enterprise operating model. It may be tasked with owning a specific product line, leading AI deployment across platforms, consolidating cloud engineering expertise, or strengthening data governance architecture.

The eBook underscores that the early phase of a GCC’s journey determines its long-term trajectory . Purpose clarity at inception prevents mid-phase fragility.

Structural coherence is not accidental. It is designed.

Expertise Density as a Competitive Advantage

While traditional GCCs often scaled through headcount growth, Specialist GCCs are built around concentrated expertise. This difference may appear subtle, but its impact is significant.

Higher expertise density leads to faster decision cycles, reduced architectural rework, clearer accountability, and stronger cross-functional integration.

In distributed enterprise environments, where time zones and digital collaboration introduce friction, this concentration of expertise helps reduce coordination overhead and improve alignment. This becomes especially critical in AI-driven transformations, where data engineers, machine learning specialists, cloud architects, and product teams must work in close sync.

The mandate for Specialist GCCs therefore goes beyond efficiency or cost advantage. Their primary goal is to drive product development, strengthen data engineering capabilities, lead platform and digital transformation, and apply artificial intelligence in meaningful business contexts.

As organizations evaluate this shift, another important question emerges:

At a Glance

What is the difference between a traditional GCC and a capability-led GCC?

A traditional GCC is typically scale-driven and process-oriented, focusing on operational efficiency and throughput.

A capability-led GCC, often structured as a Specialist GCC, emphasizes expertise density, architectural continuity, and ownership of high-value domains such as AI, cloud, cybersecurity, and data engineering.

What is the difference between a traditional GCC and a capability-led GCC

AI Integration and Architectural Ownership

Specialist GCCs are structurally well-suited to embed AI into core systems because of their concentrated expertise model. Rather than layering AI experiments onto fragmented systems, they can integrate machine learning capabilities directly within architectural frameworks.

AI adoption introduces new structural demands. It requires integrated data pipelines, scalable cloud infrastructure, secure architecture, and cross-functional collaboration.

This approach reduces duplication and enhances long-term maintainability, making AI adoption more systematic rather than opportunistic.

As enterprises accelerate their AI journeys, a key question arises:

At a Glance

How do Specialist GCCs support AI-led digital transformation in India?

Specialist GCCs support AI-led transformation by embedding data engineering, cloud architecture, and machine learning expertise within tightly aligned teams.

India’s mature GCC ecosystem enables enterprises to integrate AI directly into core platforms, improving innovation velocity and long-term architectural stability.

India’s Ecosystem Maturity

India’s appeal as a GCC destination extends beyond cost differentials.

Major hubs such as Bengaluru, Hyderabad, Chennai, Pune, and NCR host mature ecosystems supported by academia, startups, and industry networks. In 2024 alone, GCCs leased 77.2 million square feet of workspace, reflecting infrastructure readiness at scale.

India’s Ecosystem Maturity

State governments including Telangana, Karnataka, and Tamil Nadu have implemented structured policy initiatives offering streamlined approvals and skill development support.

The workforce exceeds 1.9 million professionals and continues to grow.  The ecosystem is not nascent. It is institutionalized.

The evolution of GCCs in India reflects a deeper shift in how enterprises think about capability, ownership, and innovation. The move from scale-driven models to capability-led structures is not incremental, it is foundational.

Specialist GCCs represent this next phase. They are not extensions of global operations, but integral nodes of enterprise capability designed to deliver coherence, speed, and long-term strategic value.

For organizations evaluating how to design or evolve their GCC strategy, understanding this shift is critical.

Our eBook explores the Specialist GCC model in detail, covering structural design, operating principles, and real-world application of capability-led centers.

SAP Disaster Recovery: Why Resilience Is a Boardroom Conversation Now

Posted on by Rajashekar Pendyala

SAP sits at the core of most of the enterprises.  Modern organizations depend on SAP to synchronize their mission-critical operations across finance, supply chain, procurement, HR, billing, manufacturing, customer operations and a complex ecosystem of integrated applications.  The impact of any disruption to this ecosystem, whether stemming from outages, cyber incidents, infrastructure failures, or natural disasters, extends beyond IT, resulting in measurable business disruption and financial disaster.

This reality mandates that leaders make a serious note of building ‘resilience’ into this tightly integrated ecosystem because DR, particularly in the context of SAP, is no longer about bouncing back from an outage. It is about synchronizing recovery with business continuity.

What is SAP disaster recovery and why it matters?

SAP disaster recovery is a structured approach that combines processes, technology, and architecture to restore SAP systems when disruptions occur. Because SAP runs real-time, business-critical transactions, even brief downtime can ripple across the enterprise impacting revenue, regulatory compliance, customer experience, and employee productivity.

A well-designed disaster recovery strategy safeguards the reliability, availability, and integrity of SAP workloads, ensuring business continuity when it matters most.

Key Objectives of SAP Disaster Recovery

SAP disaster recovery is not just a technical safeguard; it is a business continuity imperative. Its objectives include:

  • Minimizing operational disruption and downtime
  • Restoring SAP production systems quickly and reliably
  • Protecting data integrity across all modules and interfaces
  • Maintaining compliance with organizational SLAs and legal requirements

To achieve these objectives, SAP DR strategies are built around clearly defined response workflows that map directly to the nature of the disruption. Common SAP downtime scenarios and their corresponding DR actions include:

  • System failure:  Automated failover to standby SAP systems to restore application availability.
  • Hardware or power outage: Controlled switchover to a secondary data center to maintain business operations.
  • Cyberattack: Activation of secured backups and immutable snapshots to recover clean system states.
  • Network disruptions: Traffic redirection to an alternate region to sustain user access and transaction flow.

Together, these scenario-driven workflows ensure SAP environments remain resilient, recoverable, and aligned with business continuity commitments, even in high-impact failure situations.

Resilient SAP Architecture

Architecture That Assumes Disruption Will Happen

Resilient SAP landscapes are designed with the assumption that failures are inevitable. The differentiator is not whether disruption occurs, but how quickly and cleanly the organization responds.

Modern SAP environments leverage real-time data replication, automated failover, and disciplined backup strategies to ensure transactional consistency across primary and secondary systems. The focus is on controlled recovery.

Equally critical is the ability to return operations back to the primary environment once stability is restored, without introducing additional risk or downtime.

Disaster Recovery and Business Continuity Must Move Together

A common failure pattern across enterprises is treating Disaster Recovery (DR) and Business Continuity (BC) as parallel but disconnected initiatives. In reality, one enables the other.

Disaster Recovery restores SAP systems. Business Continuity ensures the organization can operate while restoration is underway and immediately after systems come back online. When these plans are aligned, recovery workflows support enterprise-wide response protocols, clear communication flows, and visibility and control during disruption.

This alignment is what separates technical recovery from business resilience.

  • DR restores systems; BCP ensures the business continues to operate
  • DR workflows support organization-wide recovery procedures
  • RTO (Recovery Time Objective)/RPO (Recovery Point Objective) targets map directly to operational continuity needs

Core Elements of an Effective SAP Disaster Recovery Plan

An effective SAP DR strategy is built on a combination of clearly defined recovery objectives, resilient technical architecture, and well-documented operational processes. Together, these elements ensure that recovery is not improvised during a crisis but executed with precision and predictability.

1. Defining RTO and RPO

At the foundation of any SAP disaster recovery plan are clearly articulated recovery objectives that align IT capabilities with business tolerance for disruption.

  • Recovery Time Objective (RTO) defines the maximum acceptable duration of SAP downtime after a disruption.
  • Recovery Point Objective (RPO) defines the maximum acceptable window of data loss, measured in time.

Establishing realistic RTOs and RPOs ensures that disaster recovery investments are proportionate to business risk and operational criticality.

2. Replication approaches

Replication plays a central role in meeting defined RTO and RPO targets. The choice of replication strategy depends on distance, performance requirements, and data loss tolerance.

  • Synchronous replication enables real-time write operations across primary and secondary sites, resulting in near-zero data loss.
  • Asynchronous replication offers lower latency and is more suitable for long-distance disaster recovery sites.

Selecting the right replication model is a balance between performance, resilience, and business risk appetite.

3. Documentation of the disaster recovery framework

Even the most robust technical setup can fail without clear documentation and execution clarity. A comprehensive DR framework should include:

  • Detailed architecture diagrams that illustrate system dependencies and recovery paths.
  • Clearly defined backup, restore, and replication schedules.
  • Step-by-step recovery runbooks and escalation plans to guide teams during high-pressure scenarios.
  • Established communication workflows to ensure stakeholders are informed and coordinated throughout the recovery process.

4. High availability vs. disaster recovery

While often discussed together, high availability and disaster recovery serve distinct but complementary purposes within SAP landscapes.

  • High Availability (HA) focuses on ensuring continuity by eliminating single points of failure within the same site, using clustering and redundancy to prevent localized outages.
  • Disaster Recovery (DR) focuses on recoverability, enabling SAP systems to be restored in the event of large-scale failures by activating a geographically separate environment.

In essence, HA minimizes disruption, while DR ensures the business can recover when disruption exceeds the limits of local resilience.

Testing Is Where Most Strategies Break Down

A Disaster Recovery plan that exists only on paper is not a plan. It is an assumption.

Regular DR drills expose the gaps that architecture diagrams may not show, such as, hidden integration dependencies, manual steps that slow recovery, performance or data consistency issues that surface only under load.

Organizations that test rigorously treat each drill as a learning cycle.

Cloud-native and On-prem

Approaches for SAP Disaster Recovery, Testing and Metrics

SAP disaster recovery approaches vary based on deployment models, risk tolerance, and business criticality. Whether operating in the cloud, on premises, or across hybrid environments, organizations must align recovery architecture with operational objectives, testing rigor, and measurable outcomes.

Cloud-native and On-prem DR Approaches 

Cloud-native DR Options
(AWS, Azure, Google Cloud)
On-prem Backup and Restore Stategy
Automated provisioning of DR systems
Full/incremental/differential backups
Region-to-region replication
Encrypted storage
High-speed storage for backups
Automated verification and restore tests
Elastic scale-up during fallover
Support for point-in-time recovery

Benefits of multi-region replication

Multi-region replication plays a critical role in strengthening SAP resilience, particularly for globally distributed enterprises. Key benefits include:

  • Greater resilience against large-scale regional outages
  • Reduced recovery time and recovery point objectives
  • Improved compliance with data residency and regulatory requirements

By decoupling recovery from a single geography, organizations can better absorb systemic disruptions.

Challenges in hybrid or on-premises deployments

While hybrid and on-premises DR models provide flexibility, they also introduce complexity that must be actively managed:

  • Complex network configurations and identity management across environments
  • Mixed replication and backup tooling, increasing operational overhead
  • Difficulty maintaining consistent SLAs across disparate platforms

Without careful design and governance, these challenges can erode recovery predictability.

Testing and maintaining SAP disaster recovery

A disaster recovery strategy is only as strong as its testing discipline. Regular DR drills are essential to validate both technical readiness and organizational coordination.

Effective testing programs typically include:

  • Table-top simulations combined with full-scale DR drills
  • Verification of achieved RTO and RPO targets
  • Data consistency and integrity checks post-recovery
  • Validation of automated versus manual recovery steps
  • Performance benchmarking after failover

Monitoring tools commonly used

Continuous monitoring provides visibility into SAP health, replication status, and recovery readiness. Commonly used tools include:

  • SAP HANA Cockpit for database-level monitoring and performance insights
  • SAP Landscape Management (LaMa) for system orchestration and lifecycle management
  • Cloud-native monitoring tools such as Amazon CloudWatch and Azure Monitor for infrastructure and service-level observability

These tools support proactive detection and faster response during failure scenarios.

Disaster recovery testing metrics

To assess the effectiveness of SAP disaster recovery, organizations should track measurable, outcome-driven metrics, including:

  • Achieved RTO and RPO during DR drills
  • Time required to verify data consistency
  • Number of manual steps involved in recovery execution
  • System stability and performance benchmarks following failover

Metrics convert DR readiness into quantifiable assurance.

Common pitfalls to avoid

Despite significant investment, SAP disaster recovery initiatives often fall short due to avoidable gaps:

  • Relying solely on backups without validating end-to-end DR workflows
  • Outdated or incomplete documentation
  • Lack of coordination across infrastructure, application, and business teams
  • Underestimating dependencies across integrated SAP and non-SAP applications
  • Infrequent or superficial DR testing

Avoiding these pitfalls is essential to ensuring that disaster recovery performs as expected when disruption occurs.

Checklist for a Resilient SAP Disaster Recovery Framework

Readiness is built through disciplined preparation and rigorous validation. A resilient SAP Disaster Recovery framework balances both.

Pre-Disaster Preparation

  • Updated SAP DR architecture and recovery runbooks
  • Verified backup and replication health across systems
  • DR infrastructure provisioned and tested
  • Clear communication and escalation plans

Post-Recovery Validation

  • End-to-end system and data integrity checks
  • Application and integration testing across the SAP landscape
  • Documentation of recovery outcomes and lessons learned

Continuous Improvement Is Non-Negotiable

  • SAP Disaster Recovery is not a one-time implementation. It is an evolving capability that must mature alongside business complexity.
  • Organizations that build sustained resilience continuously update recovery runbooks after every test, expand automation to reduce manual intervention, and conduct periodic architectural reviews to address new risks, integrations, and scale requirements.
  • Over time, this discipline reduces recovery effort, shortens downtime, and increases confidence across both IT and business leadership.

The SAP Disaster Recovery Maturity Model

Not all SAP Disaster Recovery strategies are created equal. In practice, organizations fall across a clear maturity spectrum. Understanding where you are on this curve is the first step toward building true resilience.

SAP disaster recovery maturity model

  • Level 1: Reactive and Backup-Driven
    Disaster Recovery relies primarily on backups with manual, untested recovery procedures. Downtime and recovery outcomes remain unpredictable.
  • Level 2: Structured but Fragmented
    Basic RTO and RPO targets are defined, with limited replication and documentation in place. Recovery efforts are still siloed, with gaps across integrations and business coordination.
  • Level 3: Automated and Repeatable
    Replication and failover processes are partially automated and supported by updated runbooks. DR drills are conducted regularly with measurable recovery outcomes.
  • Level 4: Business-Aligned Resilience
    SAP DR is aligned with business continuity priorities, with automated failover and clear visibility into readiness. Cross-application dependencies are well understood and tested.
  • Level 5: Adaptive and Resilience-Led
    Disaster Recovery is continuously optimized through automation, frequent testing, and architectural evolution. Resilience becomes a strategic enabler for scale and transformation.

Where Expertise Makes the Difference

Across complex SAP landscapes, resilience is not limited by technology. It is limited by design decisions, operational discipline, and execution maturity.

Organizations that succeed treat SAP Disaster Recovery as an engineering problem and a business transformation initiative. They design for failure, automate aggressively, test continuously, and evolve architecture as business priorities shift.

This approach requires deep SAP domain understanding, hands-on experience across cloud and on-premises environments, and the ability to translate business risk into technical outcomes.

Not sure where to start? Ask IVY.
IVY