Share with your CDO
Most enterprise analytics programs stall not because the technology fails but because the decision architecture around it was never built, according to Raghunandan Pulijala, Assurance Digital Leader at EY Global Delivery Services India. In an interview at DQ India, Pulijala lays out where the value actually leaks: analytics teams optimize for technical accuracy while business teams need actionable recommendations, pilots succeed in controlled conditions that don’t survive contact with the broader enterprise, and AI in assurance workflows flags anomalies that still require human accountability to resolve.
What this means for your business
The CDO who reads this and feels validated is probably the one with the problem. Pulijala’s core claim is that the disconnect between analytics investment and business outcomes isn’t a data quality problem or a tooling problem, it’s a decision-loop design problem. If your organization measures analytics success by dashboard opens or report cycle times, you’re measuring the input, not the output. The organizations on the right side of this gap have assigned a named business owner to every insight that’s supposed to change a decision, and they track what actually changed.
The argument about AI in assurance workflows carries the sharpest edge here. Pulijala draws a hard line: AI can rank exceptions, surface patterns, and draft documentation, but it cannot assume professional responsibility for the conclusion. That distinction matters beyond audit teams. Any enterprise deploying AI agents, automated underwriting, or algorithmic pricing faces the same structural question, which is not whether the model is accurate but whether the decision rights are explicit. What can the model recommend, what can it execute within guardrails, and what requires a named human to sign off? Most organizations haven’t written that down, which means accountability is diffuse until something goes wrong and suddenly it’s very concentrated.
The scaling argument should make any CDO running a GCC nervous in a useful way. Pulijala’s diagnosis of why pilots don’t scale, incompatible data definitions, divided ownership, short-term funding that ignores change management, describes almost every enterprise transformation program that ended quietly. The falsification condition for his framework is simple: if your last three pilots that “succeeded” didn’t produce documented changes to a business decision and a measurable outcome tied to it, the framework wasn’t applied. That’s worth knowing before the next budget cycle, not after.
Concept deep-dive: Decision-loop design
Decision-loop design is the practice of engineering an analytics program backward from a specific business decision rather than forward from available data. Instead of building a dashboard and hoping someone acts on it, you start by naming the decision, identifying who owns it, and defining what a better outcome looks like in measurable terms. The business connection is direct: it’s the difference between analytics as a reporting function and analytics as an operating input that changes what the enterprise does next.
Based on reporting from How enterprises can turn data analytics into better business decisions, originally published 2026-10-31 07:05:00.
