Manu Shukla

Posted on Jul 16 • Originally published at ecorpit.com

Data platform engineering for agentic AI in 2026: why 83% of enterprises must upgrade first

#dataplatform

Data platform engineering for agentic AI in 2026: why 83% of enterprises must upgrade first

Summary. Google Cloud surveyed more than 1,400 senior IT leaders for its 2026 State of AI Infrastructure report, published on 7 July 2026, and found that 83% of organisations say they require infrastructure upgrades to support production-grade agentic AI. In the same study, 62% report a significant inference tax driven by data egress fees, storage bloat and idle specialised hardware, 81% cite operational complexity as a hidden cost, and 79% name security, governance and MLOps as their top challenge to scaling inference. Separately, researchers at Princeton University evaluated 14 agentic models and found reliability improved only modestly across 18 months of releases. The pattern behind all 4 numbers is the same: the agent is rarely the problem. The data layer underneath it is. For Indian enterprises, a DPDP penalty of up to ₹250 crore for a security failure makes that layer a legal question too, and 48% of leaders now prioritise strict data residency controls.

Most agentic AI pilots that stall do not stall because the model is not clever enough. They stall because the agent asked the organisation a question and the organisation could not answer it consistently.

What the 83% number actually says

Drew Bradstock, Senior Director, Product, Orchestration and Kubernetes at Google Cloud, put the finding plainly when the report landed: "83% of organizations say they require infrastructure upgrades to support production-grade agentic AI."

Read the qualifier carefully. Not "to try agentic AI". To support it in production. The gap being measured is between a pilot that demos and a system that runs, and that gap is infrastructure, not model choice.

The report is specific about why the old architecture buckles. A single agentic prompt "can trigger hundreds of downstream actions, requiring massive context windows to be held in memory". A chatbot answers a question. An agent interrogates your business, repeatedly, in a loop, and every hop touches data.

Which leads to the sentence in that report that should be on the wall of every enterprise AI programme: "Agents perform reasoning, meaning they constantly run heavy queries across your organization. If your data is fragmented across silos, your AI is effectively flying blind."

That is the whole problem in one line. An agent's output quality is bounded by the worst data it can reach, and unlike a human analyst, it will not tell you the source looked wrong.

The reliability multiplier nobody budgets for

There is a second finding that compounds the first, and it comes from outside the vendor ecosystem.

In "Towards a Science of AI Agent Reliability", researchers at Princeton University (Stephan Rabanser, Sayash Kapoor, Peter Kirgis, Kangheng Liu, Saiteja Utpala and Arvind Narayanan) evaluated 14 agentic models across two benchmarks using 12 metrics grouped into four dimensions: consistency, robustness, predictability and safety. Their conclusion: "despite steady accuracy improvements over 18 months of model releases, reliability only shows modest overall improvement."

They are explicit that these are separate properties: "improving capability does not automatically improve reliability, and evaluating one does not suffice for evaluating the other."

Put the two findings together and the engineering priority inverts. Waiting for a better model does not fix an unreliable agent, because capability and reliability are not the same axis. What you can control is the input. Feed an agent inconsistent, unlabelled, ungoverned data and you have added variance to a system that is already, by independent measurement, less consistent than its benchmark scores imply.

The Princeton authors also make a point that maps directly onto data work: "Accuracy cannot distinguish an agent that fails on a fixed, identifiable subset of tasks from one that fails unpredictably with the same rate. Yet the former permits systematic debugging while the latter does not."

An agent that fails on your one badly-modelled table is debuggable. An agent that fails randomly because four systems disagree about what a customer is cannot be debugged at all. Clean data does not just improve the average. It converts random failure into fixable failure.

What the data layer actually needs before an agent is worth deploying

Layer	The question an agent asks of it	What it needs before deployment
Identity and entity resolution	"Which of these 4 records is the same customer?"	One resolved definition per business entity, with a stable key the agent can traverse. Silos that disagree produce confident wrong answers.
Access and permission scope	"Am I allowed to read this?"	Read and write scopes defined per agent, not per human. Google's Agent Gateway exists precisely to give "a single system of record for agent permissions, identity, and workflows".
Unstructured content	"What is in these 40,000 PDFs?"	Annotation and searchability. Google's approach is Smart Storage, which "automatically annotates unstructured data to make it searchable".
Data location	"Where does this row physically live?"	A residency map. 48% of leaders now prioritise infrastructure with strict data residency controls, and in India this is a legal constraint, not a preference.
Lineage and audit	"Where did this number come from?"	Full audit trails of every interaction. Without lineage you cannot answer a regulator or debug a bad output.
Freshness and contracts	"Is this current?"	Contracts and SLAs per dataset. An agent cannot infer that a table stopped updating three weeks ago.
Cost attribution	"What did that reasoning loop cost?"	Per-workload attribution. 62% report an inference tax from egress fees, storage bloat and idle hardware.

Six of those seven rows are data engineering. One is model work. That ratio is the honest picture of an agentic AI programme, and it is the opposite of how most budgets are drawn.

The inference tax is mostly a data architecture bill

The report's cost findings deserve a closer read, because they are usually misfiled problem.

62% of leaders report a significant inference tax "driven by data egress fees, storage bloat, and idle specialized hardware". Look at the three drivers. Egress fees are a data placement decision. Storage bloat is a data lifecycle decision. Idle specialised hardware is a capacity planning decision. None of the three is a model decision.

81% cite operational complexity as a hidden cost of scaling AI. 79% name security, governance and MLOps as their top challenge to scaling inference, which is notable given they were asked about scaling inference, an activity that sounds like it should be about compute.

The report also records a consolidation: 78% of organisations now source their gen AI solutions directly from their primary cloud partner, "a 30 point increase from 2025". Teams are giving up on assembling this themselves. That is a reasonable response to complexity, though it moves the lock-in question rather than answering it, and it is worth being clear-eyed that a single-vendor path is a trade, not a free win. Our note on cloud FinOps as a managed service covers the spend side of the same decision.

India-specific considerations

For Indian enterprises the data layer carries obligations that a global architecture diagram will not show you.

The Digital Personal Data Protection Act, 2023 attaches real numbers to getting it wrong. A failure to take reasonable security safeguards leading to a personal data breach carries a penalty of up to ₹250 crore. Failure to notify a breach carries up to ₹200 crore. Other contraventions carry up to ₹50 crore. The DPDP Rules were notified in November 2025 with a phased runway, and full substantive compliance is due by 13 May 2027.

Now put an agent into that picture. An agent that reads mail, queries databases and executes workflows across the business is a processing activity that touches personal data across systems that were never assessed together. Three consequences follow:

An agent needs its own identity and its own scope. Giving an agent a service account with a human's permissions inherits every over-permission that human accumulated in nine years at the company. Define read and write scopes per agent and keep audit trails of every interaction.

Residency has to be designed, not discovered. 48% of leaders now prioritise strict data residency controls, and the report is direct that hybrid is where this lands: 52% of organisations now use a hybrid multicloud architecture, driven by "digital sovereignty and data gravity". If your agent's reasoning loop quietly ships Indian personal data to a region you did not choose deliberately, you will find out during an incident.

Consent state is data. Under DPDP the lawful basis for processing is not a static flag set at signup; it changes, and it has to be readable by anything that acts on the data. An agent that cannot see current consent state cannot honour it. Teams working through this should start with our DPDP consent manager framework readiness guide.

What eCorpIT builds

eCorpIT is a Gurugram technology consultancy, founded in 2021, assessed at CMMI Level 5 and MSME certified, with partnerships across AWS, Microsoft, Google and Shopify. Our senior engineering teams do the unglamorous layer that decides whether an agentic programme works.

What the engagement covers:

A data readiness assessment against the seven layers in the table above. We map what your agent will actually reach, and where the answers disagree. This usually produces the first honest picture a leadership team has seen of its own data estate, and it is frequently uncomfortable.

Entity resolution and modelling. One definition per business entity, stable keys, documented contracts per dataset. This is the work that converts unpredictable agent failure into debuggable agent failure.

Agent identity and access design. Scoped read and write permissions per agent, audit trails, and human-in-the-loop approval gates on actions with external consequences. We build this before the agent ships, because retrofitting permissions onto a deployed agent means turning it off.

Residency and DPDP-aligned architecture. We design deployments aligned with DPDP Act requirements, including where personal data comes to rest, how consent state is represented, and what an audit trail has to show. We design aligned with the framework; we do not certify you against it, and any partner who says otherwise is selling something.

Cost attribution and evaluation harness. Per-workload cost visibility, plus the measurement that tells you whether the agent is actually reliable on your tasks rather than on a benchmark. Our note on catching silent failures in agent evals covers the testing discipline, and Kubernetes AI platform as a managed service covers the runtime.

Indicative engagement model: a scoped assessment first, typically a few weeks, producing a prioritised remediation plan you can act on with or without us. Then a build phase against that plan, and an optional managed phase. We price the assessment separately and deliberately, so the diagnosis is not a sales instrument for a predetermined build.

Who this is for, and who it is not for

It is for enterprises whose agentic pilot produced a good demo and then stopped, and where the honest diagnosis is that nobody trusts the outputs. It is for teams with data spread across systems that disagree, and for organisations processing Indian personal data who now have an autonomous system reading it.

It is not for teams who have not yet identified a real workflow worth automating. If you do not have the use case, data platform work is premature and we will say so. It is also not for anyone looking for a certification stamp; the work is engineering, and the compliance benefit follows from the engineering rather than the other way round.

The uncomfortable version: if your agent programme is failing, the fix is mostly not AI work. It is the data work you deferred for six years, now with a deadline attached. That is a harder budget conversation than buying a model, which is exactly why so many programmes stall at the pilot.

FAQ

Why do agentic AI projects fail on data rather than models?

Google Cloud's 2026 report puts it directly: agents constantly run heavy queries across an organisation, and if data is fragmented across silos the AI is effectively flying blind. An agent's output is bounded by the worst data it can reach, and unlike an analyst it will not flag that a source looked wrong.

What does the 83% figure from Google Cloud actually mean?

Google Cloud surveyed more than 1,400 senior IT leaders for its State of AI Infrastructure report, published 7 July 2026. 83% said they require infrastructure upgrades to support production-grade agentic AI. The qualifier matters: the gap measured is between a pilot that demos and a system that runs in production.

Will a better model fix an unreliable agent?

Probably not. Princeton researchers evaluating 14 agentic models found reliability improved only modestly across 18 months of releases despite steady accuracy gains, and state that improving capability does not automatically improve reliability. Capability and reliability are separate properties, so waiting for the next model release is not a remediation plan.

What is the inference tax?

Google Cloud reports that 62% of leaders see a significant inference tax driven by data egress fees, storage bloat and idle specialised hardware. All three drivers are data architecture decisions rather than model decisions, which is why the cost usually cannot be fixed by switching models or negotiating a better token rate.

Why does DPDP matter for an AI agent project?

An agent reading mail, querying databases and executing workflows is a processing activity touching personal data across systems never assessed together. Under the DPDP Act, 2023, a security safeguard failure leading to a breach carries a penalty of up to ₹250 crore, and full substantive compliance is due by 13 May 2027.

Should an AI agent use a human's credentials?

No. An agent inheriting a long-serving employee's service account inherits every over-permission accumulated over years. Define read and write scopes per agent with full audit trails. Google built Agent Gateway for exactly this, describing it as a single system of record for agent permissions, identity and workflows.

How long does a data readiness assessment take?

Our scoped assessment typically runs a few weeks and produces a prioritised remediation plan mapped against seven layers: entity resolution, access scope, unstructured content, data location, lineage, freshness and cost attribution. We price it separately from any build work so the diagnosis stays independent of what follows.

Is hybrid multicloud necessary for agentic AI in India?

Not necessary, but common. Google Cloud reports 52% of organisations now use hybrid multicloud, and 48% of leaders prioritise strict data residency controls, driven by digital sovereignty and data gravity. For Indian enterprises processing personal data, residency is a designed constraint rather than an outcome you discover later.

How eCorpIT can help

eCorpIT builds the data layer that agentic AI programmes need and rarely get. Our senior engineering teams run the readiness assessment, resolve the entity models, design per-agent identity and access with audit trails, and put cost attribution and a real evaluation harness in place before an agent touches production. We design deployments aligned with DPDP Act requirements, including data residency and consent state, and we will tell you honestly if the data work is premature for where you are. If your agentic pilot has stalled and you suspect the data is why, talk to our team.