# The Data Wire

Industry news and thought leadership for all things data, storage, and enterprise AI.

## Data Primacy: Why Government's AI Ambitions Run Through Its Data Architecture
URL: https://www.thedatawire.com/news/data-primacy-government-ai-data-architecture
Published: 2026-10-13T21:38:08.791Z
Section: AI
Summary: Bill Wright, Head of Government Affairs at Everpure, says federal agencies keep calling data their most valuable asset while their systems still treat it as a byproduct of individual applications.
Full text:
Every major shift in computing has really been a shift in architecture: a change in how hardware, software, networks, and data relate to one another. Mainframes gave way to client-server, which gave way to the cloud. Through all of it, one assumption stayed put: Data existed to serve the application. The application sat at the center, and data came second.. In government, that assumption has had decades to settle in. Agencies built their systems one program at a time , and the public sector now runs on thousands of applications, each holding its own data, its own definitions, and usually several copies of both. The outcome is an odd contradiction. Agencies say, over and over, that data is essential to their missions, and they keep standing up infrastructure that treats it as a byproduct. AI is what’s finally exposing that contradiction, because an AI system is only as useful as the data feeding it, and a great deal of government data is still trapped inside the applications that created it. The cost of a fragmented foundation As applications multiplied, so did data, and the meaning of that data splintered along the way. Pull a piece of data out of the system that created it and it often becomes unreadable without the context that lived in that system. Making it usable somewhere else means extracting it, transforming it, and reloading it into a new shape, which is both slow and expensive. In the private sector, this played out through decades of application sprawl. The original vision behind large-scale ERP systems was a single enterprise application capable of modeling every business process within one unified semantic framework. That vision fractured as organizations carved out specialized domains and adopted best-of-breed tools. They gained speed and feature innovation. They lost semantic coherence across functions. SaaS accelerated the pattern further, and each new application brought its own definitions, its own data copies, and its own integration layer. Government followed the same arc, with an added layer of complexity. Agencies are autonomous and mission-focused by design, so application sprawl didn’t just fragment data across tools. It fragmented data across entire institutions. The same person can mean different things to the different agencies that serve them. A veteran’s information looks one way in VA systems and another in the Department of Defense’s. Across agencies, the same taxpayer or claimant or enrollee gets reassembled again and again, usually through one more copy, one more spreadsheet, one more reconciliation meeting. Each reassembly is a place where errors creep in, and in government an error can mean getting a decision about someone’s life wrong. So the accuracy bar in the public sector sits much higher than the usual talking points admit. In a business, “garbage in, garbage out” costs money. In government it costs trust. In high-stakes public sector applications—such as benefit adjudications—even a 95 percent accuracy rate leaves 5 percent of citizens subject to life-altering errors. Feed AI inconsistent data and you get inconsistent answers, and inconsistent answers chip away at the legitimacy that decisions need to hold up when they reach the people they affect. How we got here It wasn’t supposed to turn out this way. About seven years ago the Office of Management and Budget published the first Federal Data Strategy , with a vision of data managed as a strategic asset across the whole of government. While the strategic intent was sound, implementation encountered persistent architectural and structural barriers across autonomous agencies. Agencies are autonomous and mission-focused by design, so modernization followed the path of least resistance, with each office choosing the best tool for its own job. They gained speed and lost a shared vocabulary in the bargain. That's roughly how the federal government ended up with the patchwork it's still sorting out: sprawling, lightly governed stores of data scattered across legacy systems, clouds, and SaaS platforms, copies sitting everywhere, and a thicket of rules about what can be shared with whom. Each new wave of technology piled on more data without disturbing the assumption underneath it. The application remained primary. Data remained secondary. And the semantic layer, the meaning of data and its relationships, stayed locked inside the application. For a government trying to put AI to work at scale, this has become a serious obstacle. AI inverts the hierarchy The federal government has, to its credit, made AI a priority. America’s AI Action Plan treats AI adoption as a national goal and names data itself as a capability the government has to get right. Agencies are already in motion. The Department of Energy stood up its Genesis Mission for AI-driven research, the Department of Health and Human Services laid out a strategy to expand AI in areas like patient data analysis and drug development, and the Technology Modernization Fund is backing AI projects at agencies across government. Ambition alone won’t get them there, though. Federal IT leaders have started making a point that deserves more attention: when agencies try to scale AI and hit long security reviews, ballooning costs, and pilots that never graduate , the trouble usually gets blamed on governance when the real culprit is infrastructure. Governance writes the rules. The data architecture decides whether anyone can actually play. More than a few agencies have learned the unglamorous lesson that you have to get slow with your data before you can get fast with AI. That changes the question leaders should be asking. For IT leaders, AI transforms the architecture question from 'What can we automate?' to 'What can our agents accomplish for the mission?' When the application was the focus, the work was about optimizing tasks. When data becomes the focus, the work is about outcomes. This is a genuine change of model, not a refinement of the old one. Data primacy Scaling AI responsibly across government calls for a data-centric architecture, one where data comes first and applications follow. Data describes itself. Real-time data counts for more than stale copies. And every environment, whether operational, analytical, or agentic, works from the same authoritative source. In this model, data systems of operation and systems of record become the core foundational asset, and applications read from or write to those systems of record rather than storing authoritative information on their own. We call this data primacy. As we’ve argued elsewhere in our discussion of putting data first , organizations increasingly need architectures where data remains the enduring asset and applications become interchangeable layers built around it. Three principles hold it together, and each speaks to something the public sector is already wrestling with. The first is that meaning has to travel with the data instead of living inside the application. Operational data should carry enough context to be understood outside the system that produced it, which means building semantic descriptions alongside data and recording the relationships that define how a piece of data connects to everything else in the environment. A record should maintain consistent semantic meaning whether an agent encounters it at one agency or another—wherever inter-agency sharing is legally authorized and governed by privacy safeguards. That's what lets AI reason over the data accurately, and it's the basis for automation a government can audit and defend. The second is that data should be conserved rather than copied. Agencies have been trained to spin off a new copy for every system, every analytics environment, every AI experiment. Data primacy reverses the reflex. A single governed, secured, well-described source of real-time data can serve every application and every agent. Real-time data is more valuable than old data, and a system of record can’t be controlled by a single group; it has to be centrally governed as an enterprise resource. For government the benefit reaches accuracy, cost, and security at once, since every extra copy is one more attack surface, one more compliance headache, and one more version of the truth waiting to drift. The third is that governance belongs at the data layer. The old approach ties access to particular applications through role-based controls. But agents range across many systems at the same time , which is precisely the case those controls were never built for. As agencies stand up Zero Trust, access needs to become contextual: shaped by the nature of the data, the identity of the agent asking, and the purpose behind the request. Governance moves from something bolted on at the end to something built into the structure. A foundation worth funding This is the point where policy and architecture meet. If the aim is a government that uses AI securely and in service of the public, the most valuable investments are the ones made lowest in the stack. Modernization funding—whether through the Technology Modernization Fund or core appropriations—delivers the highest return when investments target foundational, interoperable data readiness alongside pilot applications. This is the work we've been building toward at Everpure for years: first by handling the complexity of storing data at scale, and now with an architecture that helps organizations find, classify, and make sense of data across their whole estate, on premises and in the cloud, with policy and meaning that follow the data wherever it goes. The goal is to keep what already works while moving toward something sturdier and more efficient underneath, a data-first foundation ready for the agents that will touch more and more of the work. Earning trust in the AI era AI is reshaping how the public sector serves people, and the ripple effects reach every part of the organization. Data stewards, CIOs and CDOs, infrastructure leaders, and the workforce keeping older systems running will all see their roles shift as AI changes what the work looks like and where the decisions get made. All of it starts with the data, though: data that carries its own context and meaning, that is governed and secured, that people across an agency can reach, and that an official can stand behind when a decision affects a citizen. Plenty of people in government talk about how much data matters. The agencies that turn that talk into architecture, that genuinely put data first, will be the ones deploying AI with confidence, running leaner, and keeping the public’s trust while they do it.

## Part 1: What Changes When AI Begins to Act?
URL: https://www.thedatawire.com/news/agentic-ai-banking-infrastructure-accelerate
Published: 2026-10-12T13:45:48.532Z
Section: AI
Summary: Identity sprawl, unpredictable workload patterns, and autonomous systems that can outrun their own guardrails. At Everpure's Accelerate, financial-services infrastructure leaders laid out five areas where agentic AI is forcing a rethink.
Full text:
Agentic AI changes a basic assumption behind banking technology: the user interacting with a system may no longer be human. An AI agent can interpret a goal, retrieve information, invoke tools, interact with systems, and take action. As financial institutions move these systems closer to production, controls designed around human users and predictable application behavior begin to face a different operating model. That shift is already underway. According to the Cambridge Centre for Alternative Finance's 2026 Global AI in Financial Services Report , 52% of surveyed financial-services industry respondents are actively adopting agentic AI, including 45% of traditional financial institutions and 57% of fintechs. The question is therefore no longer simply whether financial institutions can move AI from pilot to production. It is whether the operating environment is ready for AI systems that can act once they get there. Five areas deserve particular attention: identity and permissions, observability and traceability, execution controls, containment, and resilience and recovery. One request can become a chain of system activity Traditional banking applications are built around relatively predictable transaction patterns. Agentic systems introduce a different workload model. An agent investigating a suspicious transaction, for example, might retrieve customer history, query device information, review prior fraud cases, call external data sources, and invoke multiple internal systems before producing an answer or taking an action. The important change is the chain of activity. One request may touch APIs, databases, identity systems, payment platforms, fraud systems, risk engines, and other downstream services. The scale of agent activity is expected to grow rapidly. IDC forecasts 1.15 billion active AI agents across enterprises by 2029, executing 217 billion actions per day. That changes the unit of demand for banking infrastructure. One prompt is no longer one transaction. It can become a chain of autonomous activity across APIs, databases, identity systems, payment platforms, fraud systems, risk engines, and other downstream services. For infrastructure teams, the question becomes larger than whether the AI environment itself can absorb the load. It is whether autonomous activity can create unexpected pressure elsewhere in the institution. Five operating assumptions financial institutions need to rethink before scaling agentic AI If agentic AI changes how systems behave, financial institutions need to look beyond whether the model itself is ready for production. The operating environment around it matters just as much. In June, a discussion at Everpure's Accelerate summit surfaced five areas where assumptions built around human users and predictable applications begin to look very different when the actor is an autonomous system. 1. Identity and permissions Agentic AI changes the identity question from simply who or what has access to what an autonomous system could discover and do with the access already available to it. Financial institutions operate with machine identities, inherited permissions, service accounts, and privileges created for applications and workflows that may have existed for years. An agent introduces a different kind of actor capable of exercising that access across systems. CyberArk's 2025 identity-security research found that machine identities outnumber human identities 82 to 1 across surveyed organizations, with 42% of those machine identities carrying privileged or sensitive access. For identity teams, the question becomes: What could an autonomous system discover and do with the access already in the environment? 2. Observability and traceability Andrea Moccia , VP of AI and Data at Options Technology, brought the discussion back to another basic requirement: institutions need to understand what their agents actually do. “What breaks first when agents hit production infrastructure? Something's going to break, and you're not going to know what it was,” Moccia said. “A very good first step is going back to day one. Integrate observability and traceability in your systems, and also evaluation of outputs.” Traditional infrastructure monitoring can tell an organization whether a system is available or performing normally. Agentic observability raises different questions. What data did the agent access? Which identity or service account did it use? Which tools and systems did it invoke? What actions followed? What changed downstream? In financial services, being able to reconstruct that sequence becomes part of maintaining accountability and operational control. The question for institutions is straightforward: if an agent takes an unexpected action, can you reconstruct exactly what happened? 3. Execution controls Visibility alone doesn't constrain what an agent can do. When Mike Russo asked whether governance could keep pace as AI systems gained more autonomy, Moccia rejected the premise. “Governance can also be machines,” he said, pointing to policy as code and systems designed to confine agents within defined boundaries. The distinction matters. Governance cannot exist only as a policy document or a manual review after an action has occurred. Some controls may need to operate inside the execution path itself, constraining what an agent can access, which tools it can invoke, and which actions it is permitted to take. That doesn't eliminate human oversight. It changes where some controls have to live. For financial institutions , the question becomes: which controls need to operate while the agent is acting, rather than before or after? 4. Containment An agent doesn't have to be malicious to create an operational problem. It can be acting within legitimate permissions and still generate activity at a speed, scale, or breadth the institution did not anticipate. As agent activity moves across APIs, databases, identity systems, and other services, the effects may not remain confined to the AI environment itself. That makes containment an infrastructure question. If an agent begins generating unexpected activity, can its access be constrained? Can downstream systems be protected from unexpected demand? Can the activity be stopped without disrupting unrelated workloads? For financial institutions, the question is not simply whether an agent will behave unexpectedly. It's how far it can go before something stops it. 5. Resilience and recovery Richard Galvez brought the discussion back to what happens when AI moves beyond the pilot. The teams that succeed, he argued, take a focused use case all the way to production and pay attention to “all the things that are going to break along the way in your infrastructure.” That mindset becomes even more important with agentic systems. An autonomous system could create a sequence of legitimate actions across multiple interconnected systems before anyone realizes something has gone wrong. Resilience therefore needs to account for more than restoring a failed application. Financial institutions need to understand which systems were affected, what data or transactions changed, which actions need to be reversed or remediated, and whether the sequence can be reconstructed well enough to understand what happened. As institutions give AI systems greater ability to act, they also need confidence that unexpected outcomes can be contained, investigated, and recovered from. The question is: if an agent creates an unexpected chain of actions, can the institution contain it, recover from it, and explain what happened afterward? The disciplines are familiar. The operating model is not. Identity and access management are not new. Neither are observability, governance , workload containment, or recovery. Financial institutions have spent decades building controls around these disciplines. What is changing is the actor operating inside that environment. Agents can discover resources, invoke tools, interact with multiple systems, and pursue objectives with a speed and degree of autonomy that traditional applications and human users were not designed around. The challenge, then, is not to invent an entirely new infrastructure playbook for agentic AI. It's to determine where established controls and operating practices need to change when autonomous systems become another actor operating across the enterprise. Deploying more agents will not give a bank an advantage if it cannot control what those agents do. The advantage will come from building an environment where they can act, while the institution can see, constrain, and recover from their actions. Financial institutions will deploy agents. The institutions that move successfully will be the ones that understand what those agents can access, can see what they are doing, can constrain how far they can go, and can recover when something unexpected happens. As banks give AI systems more freedom to act, they need to know what those systems can access, see what they do, and step in when something goes wrong. And those controls are only part of the production challenge. In Part 2 , we look at why so many banking AI projects still stall between the demo and deployment.

## Part 2: What Keeps a Promising Banking AI Demo From Making It Into Production?
URL: https://www.thedatawire.com/news/banking-ai-pilot-production-accelerate
Published: 2026-10-12T13:45:12.884Z
Section: AI
Summary: An Everpure-hosted panel featuring Options Technology VP Andrea Moccia and financial services infrastructure leaders laid out the recurring failure patterns that trap AI pilots in permanent purgatory, and the architectural decisions that let a handful of firms break through.
Full text:
The statistic has become industry furniture at this point: more than half of AI proof-of-concept projects never make it into production . IDC research found that 88% of AI proof-of-concept projects never reach widescale deployment. S&P Global's 2025 survey put the average abandonment rate at 46% before production. The figures vary by study, but the direction is consistent. Organizations are investing heavily in demonstrating what AI can do and struggling to make it operational. A panel discussion recorded at Everpure's Accelerate summit in Las Vegas brought together practitioners who see this failure pattern from the inside. Andrea Moccia , VP of AI and Data at Options Technology , a technology partner serving more than 600 financial institutions including investment banks, hedge funds, and fund administrators, joined Everpure financial services leaders to dissect what separates the organizations that reach production from the ones stuck in what the panel repeatedly called "POC purgatory." The diagnosis was unanimous: the model is almost never the problem. The graveyard isn't full of bad models The panel's sharpest early insight came from the infrastructure side. When AI projects fail in financial services, the postmortem rarely points to the model itself. The algorithms worked. The outputs were accurate. The demo landed. What collapsed was everything around the model: the integration into existing business processes, the infrastructure to support production-scale workloads, and the data architecture required to feed the system reliably. "If you look at the AI graveyard today, 95% of the time it wasn't the model's fault," said Richard Galvez , Everpure's Director of Applied AI. "It was everything around it. People call it the harness, but it goes beyond that. Your data infrastructure, pipelines, your tests, your observability, your security. The good news is you don't have to build something new. Integrate AI into the systems you already have." That observation reframes the production challenge. Organizations that succeed don't build parallel infrastructure for AI. They figure out how to make AI workloads fit inside the operational and engineering patterns they already run. The ones that fail are often the ones that treated AI as a standalone system requiring its own dedicated stack, and discovered too late that the complexity of maintaining two operational environments exceeded the value the pilot was generating . Pilot economics can change at production scale One of the less discussed reasons pilots stall is economic. Galvez walked through a pattern he sees repeatedly: teams build and iterate in the cloud, which makes sense for experimentation. Data scientists can spin up environments, test hypotheses, and move fast. But when the time comes to scale to production, the natural instinct is to simply scale up the same cloud environment. That instinct is expensive , and not in the way most teams expect. "The costs don't normally scale linearly," Galvez said. "If you're running things at some particular calculation of volume, going up to 10 times that volume does not scale at 10 times the cost." The economics of cloud compute at production scale involve tiered pricing, data egress charges, GPU reservation costs, and throughput bottlenecks that don't surface during a pilot with 20 users and a bounded dataset. Worse, some organizations simply hit resource ceilings. "You literally might just run out of resources in the cloud that you're using. From the top down, leadership is telling you, 'deploy this AI.' All they see is you were succeeding at the pilot stage, but then when you went to production, it failed." The pilot died at a quota limit, not at a technical barrier, which he described as "almost the saddest way" for a promising project to end. The discussion points to the need to plan the production environment from the beginning, rather than assuming the infrastructure and economics of the pilot will scale unchanged. Data is the new programming surface Moccia offered what was arguably the panel's most durable conceptual contribution. Traditional software operates through explicit instructions: if-then logic, defined workflows, deterministic outcomes. AI systems operate differently. The behavior of the model is determined by the data it receives. Change the input, and you change the output. That makes data management an architectural concern of a different order than it was in the application era. "There's this shift where the input is becoming the problem," Moccia said. "The data is slow, it's incorrect, you have poisoning risks. The crucial part is controlling what you feed into the model: how fresh it is, what version, where it's coming from, what's the provenance." He connected this directly to the need for traceable, governed data pipelines . In the software era, organizations versioned their code. In the AI era, they need to version their data with the same rigor, because the data is the program. "You don't have software versioning. You need versioning of the program, which is the data," Moccia said. "Almost like a CI/CD aspect of data." The point carries particular weight in financial services, where regulatory obligations require institutions to explain the basis for decisions that affect customers, counterparties, and markets. If a fraud model flags a transaction, the bank needs to reconstruct not just which model produced the flag, but which version of the data the model was operating on when it made the determination. The organizational problem underneath the technical one Financial institutions have accumulated decades of data across lines of business, systems, and geographies. AI increases the pressure to work across those boundaries. That means the production challenge is not limited to where data resides. Institutions also have to determine who can access it, under what conditions, and how those access decisions are governed across business units. The organizations best positioned to move AI into production are therefore not solving only a model or infrastructure problem. They also need the governance and access frameworks required to work across organizational boundaries. Meet users where they work The panel's most practical advice came from Joel Ramirez , an Everpure Senior Systems Engineer, who argued that pilot adoption often fails because of the user experience. Teams build impressive AI capabilities and then deliver them through interfaces that don't match how the end user actually works. "Think about your users, the end user that's consuming whatever you're doing," Ramirez said. "How do they work day to day? If they're on the factory floor putting stuff together and need a quick answer, are they really going to pull out a tablet and chat with a chatbot?" His point was that the pilot-to-production journey includes an adoption problem that infrastructure teams frequently underestimate. An AI system that requires users to change their workflow to access it will face resistance regardless of how accurate its outputs are. The organizations that succeed design the AI interaction around existing user patterns , not the other way around. Production readiness is a design decision The through line across the panel's 40 minutes was consistent: production is not a stage that follows a successful pilot. It's a set of constraints that need to be designed for from the beginning. Infrastructure capacity, data versioning, governance, user experience, cost modeling, and integration architecture all need to be scoped during experimentation, not discovered after the demo succeeds. The panel acknowledged that the broader market trajectory is positive. Moccia pointed to growing evidence of real ROI emerging from organizations that have made it through the purgatory phase. "Enterprises are now beginning, many pockets around the industries, FSI included, beginning to derive real ROI from their investments in AI," he said. "There are some that are really fast, and there are a couple now that are out there in the lead. But many more are following suit." The gap between a successful pilot and production is rarely one thing. Infrastructure capacity, data architecture, economics, governance, integration, and user adoption all have to survive the transition. Production readiness therefore cannot begin after the demo succeeds. It has to shape the pilot from the beginning. And as we explored in Part 1 , that challenge becomes even more consequential when AI moves from answering questions to taking action across the institution.

## When Models Disagree, Causal Testing Helps Data Leaders See Which Results Will Hold At Scale
URL: https://www.thedatawire.com/news/causal-testing-model-disagreement-data-decisions-emily-nightingale-the-knot-worldwide
Published: 2026-10-09T05:00:51.733Z
Section: Leadership
Summary: Emily Nightingale, Director of Marketing Data Science at The Knot Worldwide, on how disagreement between sources becomes its own decision-grade signal.
Full text:
A dashboard can hand a leader a clean, confident answer , and that's what makes it dangerous. A model built on observational data will report that a channel or initiative is performing and attach a high confidence score to the result. The number starts to feel like the truth. That confidence reflects the math. It doesn't test the causal assumption underneath it, and a tidy output usually means something was left out. Data teams that read their models well treat a suspiciously clean answer as a reason to look harder. That discipline sits at the center of how Emily Nightingale approaches her work as Director of Marketing Data Science at The Knot Worldwide , the wedding-planning company whose demand is tied tightly to life events and a sharply seasonal engagement cycle. That structure makes her category an unusually strict test of any signal: the peaks are predictable, so the hard part is separating genuine marketing impact from demand that was always going to arrive. Her answer is to resist the single clean number wherever it appears, starting with the tool most teams lean on hardest. "If each of your models is telling you a different thing, that means you have no idea what the truth is. If you just choose one of those and make a decision, you may be spending money very inefficiently," she says. Why one attribution source can skew the picture The first place Nightingale wants leaders to lose confidence is any setup running on a single attribution source, especially a click-based one. "Whatever your CDP is, it's useful for decision making, but they are heavily biased to the bottom of the funnel," she says. Lean on them alone and the credit flows to paid search and other last-click channels, subtly steering spend toward the end of the journey while the demand-creating work upstream goes unmeasured. Her prescription is deliberately harder to live with than the alternative. She wants leaders using several sources at once and triaging between them, precisely because they will conflict. One will call a channel a winner; another will tell a different story. "I know that's so frustrating as a busy leader who just wants to know what to do next, but I actually think some of that noise is really important," she asserts. The friction is the point, and it produces the through-line of her whole approach: the disagreement is information, not noise to be resolved away. Where causal methods earn their place The reason Nightingale pushes past correlation is that only a causal answer tells her whether a result will hold up when she acts on it. A pattern pulled from observational data can be a real and interesting finding and still collapse at scale. "Any other non-causal model may not scale," she says. "If you roll it out to 100%, you may see no additional impact. You may see negative impact." A causal read, by contrast, tells her how a change will behave when it goes company-wide, which is the only version of the answer a budget decision can safely rest on. For a business where seasonality swamps almost everything, she gets that read through match-market testing, which is a form of causal inference. She illustrates with an intentionally oversimplified example comparing Los Angeles and New York. "Let's say LA and New York act very similarly and you run a marketing campaign in LA only. The only difference between those two cities is the campaign. So, you know that any difference in performance between New York and LA is due to your marketing campaign." Run such a test during the January engagement-season surge, and the method still isolates the marketing lift from the seasonal wave that would have arrived regardless. It's how she answers the question her category makes hardest: how much of what happened was actually the marketing? The blind spots you can name but can't measure The harder problem is the signal she knows exists but can't see cleanly in the data. New competitors and the rise of LLMs are both reshaping demand , and both are nearly invisible in her inputs. "It's a huge thing that we know is disrupting, but we really can't quantify it well," she says of AI search, where the platforms surface almost nothing about who's looking for a brand and third-party data is spotty at best. A confounding variable can be real, in other words, without being something you have a usable measurement of. Rather than paper over the gap with synthetic data or push ahead on a model she doesn't trust, Nightingale designs around it. She favors methods that don't require every confounding variable to be specified in the first place, like match-market testing, A/B testing, and propensity matching, because each one holds the unknowns steady instead of demanding she enumerate them. Propensity matching, for instance, controls for a user's underlying intent, so a campaign doesn't get credit for high-intent people who were coming back anyway. The choice of method is the safeguard against the blind spot. No model is finished, and that's the honest starting point Even a fully specified model offers no escape from uncertainty, because there's no version that accounts for everything. Nightingale points to the econometrics literature and the book Mastering Metrics , for the underlying truth: one economist builds a causal diagram capturing every input they believe matters, and another can always arrive to insist a different variable belongs. "Everyone is right and everyone is wrong at the same time. Schrödinger's model," she says. There are technical ways to test whether adding a variable improves the fit, but the search for a perfect, complete model is a category error. This is why she keeps returning judgment to the process rather than trying to engineer it out. Experimentation covers the high-stakes calls, the ones that could tank revenue if they go wrong. Everything below that threshold, where testing isn't worth it or isn't possible, comes down to decision-making, and she's blunt that the modeling never removed the human from it. "All of these inputs, all these assumptions, are just decisions about what the data scientist believes to be correct." Turning uncertainty into a signal instead of a distraction The instinct under pressure is to treat unresolved uncertainty as something to omit so a decision can be made. Nightingale takes the opposite view. "That uncertainty is a huge data point for what you should be doing, or how you should be thinking about it, or what you should prioritize," she says. When her sources diverge, that divergence tells her how confidently she can move, whether a call needs a test before rollout, and where to aim scarce experimentation. The gain is not resolution, but definition. "It's a known unknown now instead of an unknown unknown." Nightingale is clear-eyed about where the broader adoption of AI is heading, and she folds that into the same framework. Her expectation is a cycle: heavy, enthusiastic use , followed by visible failures born of over-reliance, followed by a swing back toward control, process, and oversight. The point isn't to sit out the efficiency AI offers. It's to know which signals to trust it with and which still need a person who can look at a clean, confident answer and ask what it left out.

## AI Is Still Waiting for the Clean Data That BI Never Got
URL: https://www.thedatawire.com/news/avon-ai-data-cleanliness-olga-sakka
Published: 2026-10-09T04:53:52.396Z
Section: AI
Summary: Avon's Head of Applied AI and Business Value has watched enterprises promise to replace people with tools once already. A decade on, the data underneath still isn't ready, and now the tools act on it without a human in the middle.
Full text:
The views and opinions expressed are those of Olga Sakka and do not represent the official policy or position of any organization. For a decade, enterprise data was allowed to stay messy because a person always sat between the data and the decision, catching what didn't add up before it went anywhere. Agents remove that person. They read whatever's in the warehouse, take it at face value, and act on it, with no instinct for when a number is wrong. The promise driving this year's AI budgets is that software can finally run that stretch on its own, and it's a promise the enterprise data world has heard, and broken, once before. That warning comes from someone who has spent 25 years inside the same company reading its numbers. Olga Sakka is Head of Applied AI and Business Value at Avon, the 140-year-old beauty business now operating globally under private-equity ownership , where she leads AI adoption across a deliberately lean organization with every project tied to a business outcome. Before the AI remit she spent more than two decades as a data scientist and strategic analytics leader in Avon's commercial function, sitting, as she puts it, between decisions and numbers. She still builds, turning ideas into working internal tools with platforms like Lovable and Claude Code. She keeps steering every AI conversation back to the one thing the tools can't fix for anyone: whether the data beneath them is clean enough to trust . After 25 years of asking, she's stopped expecting a yes. "Tell me one company that has clean data," she says. "Tell me one." But it doesn't leave her stuck. It sets the order of operations. A mess that predates the agents Olga keeps her team disciplined by sorting every AI project into three business values. "The first is cost, retiring something we used to pay for externally and building it in-house," she says. "The second is time and productivity, letting someone do more with less. The third is the biggest unlock, and it needs real agentic AI: revenue growth. Cost, time, and revenue, in three words." It's a framework built to keep spending honest against outcomes rather than novelty. None of it clears the bar, though, without the layer underneath, and that layer is where a quarter-century of enterprise habit catches up with the ambition. Enterprise data was rarely in good shape, Olga says, not even for the reporting it was first built to serve. For years the fix was a person. Experienced analysts carry the definitions that make a number mean something, which sales count and which don't, and most of that context has never been written down anywhere a system could find it. "The good AI today is still in one person's head," she says. The challenge lands because she isn't only describing Avon. It's a condition she sees across the enterprises she talks with , most of them further along in ambition than in readiness. "This isn't new with AI. It was already the problem in the BI era ten years ago, and it still is." When agents act without human review, the contextual checks people have traditionally supplied need to be built into the workflow. Governance as onboarding The most common request Olga fields is a swap. "'Can we replace Tableau with Claude?' That's the question I get, and it's the wrong one," she says. "Tableau is traditional software, a reporting machine. A language model isn't another reporting machine you swap in for the old one." Her reframe is to stop installing AI and start onboarding it like a hire . "I like people to view AI as an extra colleague. You don't just say, 'take that data and do the reporting.' You explain what the data means, where the semantic layers are, where it's hosted. Our whole data warehouse is a house, and you decide whether you're opening the door to the whole house or to one room." "I've seen this story before," she says. "Ten years ago, the CTOs said, 'we don't want ten analysts doing Excel reports, we'll bring in Tableau.' And the analysts said, 'fine, but once you connect Tableau to Snowflake, the dashboard shows the wrong information if the data isn't correct. So let's fix the data first.' This is the same. This is exactly the same." A wrong dashboard misinforms a person who can still catch the error. When an agent works from that same data without human review, the business knowledge that would have caught the error has to be documented in advance. That onboarding is where governance does its real work. Before an agent gets loose in the warehouse, Olga wants it sandboxed to a single room of well-understood data, with per-agent rules for what it can and can't touch, because a model optimizes for finishing the task and will fill an ambiguous gap with a confident guess rather than stop. "Now we need our agents to actually do good work, and nobody really knows what an agent is yet." Newer and more capable models keep shipping regardless, and the people signing off on them are often the furthest behind on what the systems can actually do. Building readiness, use case by use case Avon works through use cases one at a time. Each one has to show clear business value and carry the right safeguards before it goes anywhere, and that assessment sets the pace. Olga's method for keeping the pace honest is documentation. "I want everyone to document what actually needs doing, like writing a recipe. You list the ingredients, but sometimes the ingredients aren't good enough, so there's an extra step, and someone has to go shopping first." It resets what executives expect the technology to do for them. "There is no AI to save you," she says. "There is AI to serve you. You use it to help construct your thinking about what you should do to create the data." What makes that pace possible is a leadership team fluent enough to accept it, and Olga is clear that the fluency is still rare across the industry. She keeps raising it, tier by tier, because the ambition keeps outrunning what even a C-suite understands about the tools. Her own C-suite is further along, which is what makes the approach workable. The people signing off on her projects understand what the technology can do and what has to be built before it can do it. "I have a CTO, a CEO, and all of my C-level people who are AI native," Olga concludes. "It helps a lot to have leadership teams in this way."

## Mapping Data Movement Before Buying Hardware Keeps Inference Spend On The Real Constraint
URL: https://www.thedatawire.com/news/nagarjun-rajendran-bosch-digital-gpu-bottlenecks
Published: 2026-10-08T14:50:48.497Z
Section: AI
Summary: Nagarjun Rajendran, Cloud and Technology Solutions Manager at Bosch Digital, shares why GPU utilization alone cannot tell a team what is limiting its production inference.
Full text:
A GPU benchmark reports raw compute, and production inference rarely behaves the way that number predicts. A live serving path can be held up inside the chip, by how fast it reads its own memory. The same path can stall between chips, on how quickly two cards exchange data or how long a hop between nodes takes, and fixing whichever one binds typically exposes the next bottleneck. Software efficiency is worth examining before buying more capacity, since the bottleneck a team measured last quarter has usually been replaced by a different one. Nagarjun Rajendran is Cloud and Technology Solutions Manager and Principal Architect at Bosch Digital , where he owns end-to-end architecture for a cloud platform that a dozen or more engineering teams build on. Rajendran joined Bosch in 2017 as an IoT consultant across the ASEAN region, then spent three years as a senior cloud and IoT architect on its industrial platforms. His earlier work runs from a microelectronics foundation at the National University of Singapore through embedded automotive software to multi-region cloud design. He holds professional or expert-level certification across AWS, Azure, and Google Cloud, and writes about system design and architecture tradeoffs. "Most infrastructure decisions get made assuming the previous bottleneck is still the current one, but that's not the case. The bottleneck keeps moving," says Rajendran. A team that assumes otherwise spends money on hardware for a bottleneck that's already gone. Rajendran wants a team to work out how data moves through its system before it buys anything, because fixing the movement can remove the need for more hardware. Compute, bandwidth, and data movement Adding GPU power is the first move most teams make, and it helps while compute is what's running short. The next limit is how fast the chip can pull data out of its own memory, and buying more processing power doesn't change it. "If your inference workload is slow, you just start adding a lot of compute. Basically you improve the GPU power," says Rajendran. "But then the team starts to discover there is a memory bandwidth bottleneck that surfaces. Memory bandwidth is nothing but how the memory is accessed within a chip." One request needs both, at different moments and in different amounts. Reading the prompt pushes all of it through the model at once and loads the processing cores. Producing each token after that means fetching what the model stored about every earlier token, and that traffic runs through memory on the same card. "The LLM serving is having two aspects. One is first the prompt gets understood by the LLM, and then it starts generating the first token. That is actually compute bound," explains Rajendran. "But once you start generating tokens from the second token onwards, every time it has to look back to the previous token, how it has been generated. That aspect is actually memory bound." The bottlenecks tend to arrive in that order. How soon a particular team runs into them is a different question, and Rajendran ties it to how fast the system is growing, so growth rate is the thing to watch. "It purely depends on how their roadmap looks like, how much they want to sell, and what their customer pipeline looks like," he notes. "If the team is small and they are growing at a slower pace, maybe all of this bottleneck surfaces once they reach a particular milestone." Three numbers worth monitoring GPU utilization is the number most teams watch, and Rajendran says they lean on it almost entirely. A consumption dashboard hides the cost of output that has to be generated twice, and a utilization figure hides a card sitting idle while another component in the path saturates. "The majority of people always look at compute in the dashboard," Rajendran adds. "They tend to use only GPU power as a monitoring mechanism for their entire inference." A utilization figure describes one card. Two of the three measurements Rajendran wants describe what happens between cards. "One is the compute power, flops. Then second is the network connectivity, how fast and how efficiently you are connecting two hardware when you serve for a larger audience," he says. "Then third is how efficiently you are moving data from one hardware to another." Rajendran is most insistent about the order. A team maps how data moves before it buys hardware and before it stands up an inference server, because what the map shows changes what's worth buying. "I would say start with the data movement, how exactly the data is moving. That is where people have to start before they do anything on the inference," he says. "If they solve that, they don't even need to add computation power." Splitting cache from compute The KV cache holds the keys and values for every token a model has already processed, the prompt included, and each new token consults it. Running the cache and the generation together puts two jobs on one piece of silicon that can only be tuned for one of them. "Often they oversee that both KV cache as well as inference can be put into the same GPU. It shouldn't be the case," explains Rajendran. "They have to design the cache and the computation in two different hardware, optimize both for those specific purposes, and link them with a high-efficiency networking protocol." Published work from the vLLM team on paged attention took the same waste to how GPU memory gets handed out. Reserving one contiguous block per request leaves the unused portion of that block stranded inside it. Handing out small pages keeps that memory available for other work. "Instead of addressing that KV cache in the traditional way, they have to come up with an out-of-the-box solution, where they switch it to work the way an operating system like Windows or Linux handles memory," notes Rajendran. "Whenever they need cache they use the entire memory available and keep adding pages instead of reserving a full block. If you split and use it page by page, you free up a lot of GPU capacity." Kubernetes assumes a workload it can destroy and recreate. Rajendran says that's fine for general compute, while an inference platform is assembled from particular hardware in a particular arrangement. Where a workload runs depends on which hardware sits where, and he expects orchestrators to start reading that before they provision anything. "Maybe in the next two years all of these players would understand the full picture of how to host inference in a more efficient way, and they would have solutions to address all of this off the shelf," he concludes. "But for now, the engineering team has to put in the effort to understand the finer details before they serve inferencing with maximum utilization of the hardware."

## Utilities Can Meet Much Of AI's Power Demand By Upgrading Infrastructure They Already Have
URL: https://www.thedatawire.com/news/bureau-veritas-brendan-andrews-data-center-demand
Published: 2026-10-06T19:06:57.589Z
Section: Leadership
Summary: Brendan Andrews, Vice President of Energy and Infrastructure at Bureau Veritas, on why upgrading existing infrastructure beats waiting a decade for new capacity.
Full text:
The debate over AI's electricity appetite has settled into two camps: the forecasts warning that data centers will overwhelm the grid, and the pushback insisting the fear is overblown. Both skip the harder question. U.S. data center electricity use has more than doubled since 2018, and federal analysts now project it could reach nearly 12% of the national total by 2030. Yet a large share of the demand now being quoted hasn't been built, financed, or even sited. The work in front of utilities, regulators, and operators is to separate the load that's real from the load that's speculative, then move enough power to meet it without waiting a decade for entirely new infrastructure. Brendan Andrews is Vice President of Energy and Infrastructure at Bureau Veritas , a testing, inspection, and certification firm that advises clients across power generation, grid modernization, and mission-critical facilities. He has spent more than 25 years in energy and infrastructure markets, with a focus on power generation, battery energy storage, renewables, and the data centers now reshaping demand. His work puts him alongside the developers and utilities navigating the technical, regulatory, and supply-chain questions that come with building at this scale. For Andrews, the starting point is honesty about the numbers. "There's a lot of speculative demand, and that's where we need to be really careful," he says. "We're hearing power requests from AI and data center developers that add up to hundreds of gigawatts over the next five to seven years." Sorting real demand from speculation The forecasting problem isn't that demand is small. It's that the headline figures bundle firm projects together with speculative ones, and the industry lacks the components and the technology to deliver everything on the list at once. Treating every announced gigawatt as certain load is how utilities over-build, ratepayers absorb the cost, and planners lose the ability to tell which projects to prioritize. Andrews is quick to add that the demand isn't abstract, either. It comes from the same consumers who expect instant, always-on digital services, and who rarely connect those services to the power and infrastructure behind them. That gap between quoted demand and real demand is starting to shape policy at the state level. Andrews points to a wave of jurisdictions that have moved to pause new projects while they study the impact on grids, water, and local budgets, a posture that now reaches well beyond the states people expect. "Even in red states, you're seeing moratoriums or a pause on development, and I don't think that's a bad thing," he says. The value of a pause, in his view, is that it forces a real local forecast instead of a national one. "What's good for one area isn't good for another. It really needs to be an understanding of what each state, each city, each town is going to deal with." A grid built for a smaller load Even where the demand is firm, the physical grid wasn't sized for it. Much of the transmission network carrying power today was designed for loads it was never meant to serve , and the age of the equipment shows the moment you look up. "The future of energy isn't just about adding more wires," Andrews says. "It's about building the infrastructure that allows the grid to carry more power, more efficiently, and at a scale never seen before." He's careful to separate the engineering reality from the public fear that tends to attach to it. The prospect of new load near a neighborhood gets read as a threat to reliability and household bills, when the actual requirement is investment in the network that's already there. "People hear this and think it means higher utility bills, blackouts, brownouts," he says. "That's not the case. What it requires is upgrades to the existing infrastructure." The distinction shapes who should carry the cost, and Andrews argues the investment belongs with the parties consuming the power rather than the families living around it. Upgrade before you build new Here Andrews makes the point that matters most for anyone trying to move quickly: a lot of headroom is already sitting in the system. "There is a great deal of underutilized capacity within existing infrastructure , and opportunities exist to unlock additional capacity through optimization and modernization rather than solely relying on new construction," he says. Reconductoring older lines with higher-capacity conductors, pulling them across existing towers, and building along existing rights-of-way all add throughput without the multi-year fight that greenfield transmission triggers. "When permitting takes years, existing rights-of-way become one of the most valuable assets for expanding grid capacity." The logic runs parallel to the efficiency case being made on the compute side of the same problem, where the priority is getting more useful work out of every watt and rack before adding raw capacity. Upgrading a line the industry already owns puts far less strain on a stretched supply chain than sourcing everything new, and it keeps power flowing while the work happens. That last part matters more than it sounds. "The last thing you want to do is shut people's power down," Andrews says, because an hour-long outage is enough to turn a community against the entire buildout. When the data center becomes the utility The other release valve is generation that sits at the load. Rather than wait years for a grid connection, developers are building power directly into their campuses. "We're seeing power generation integrated on site, whether that's renewables, fuel cells, or reciprocating engines, and it's happening at light speed," Andrews says. The scale has changed what that means. The early data centers were small buildings; the ones going up now are multi-gigawatt campuses that can draw more power than a small city, and increasingly they produce it on site instead of pulling it all from the grid. At that scale, the facility stops being a pure consumer of electricity. "These large data centers are becoming their own power producers. For all intents and purposes, they become their own utility," Andrews says. The surplus doesn't have to stay behind the fence. "They're producing a large amount of power that can be used not just at the data center but across the surrounding community as a backup if there are any issues." A campus built to guarantee its own reliability can end up shoring up the grid around it, which reframes the "not in my backyard" reaction that has slowed wind, solar, and now data centers alike. The supply chain sets the pace None of it moves faster than the equipment allows, and the equipment is the constraint. "With transformers, you're looking at three years, 36 to 48 month lead times," Andrews says. "And these developers are building data centers quickly." The mismatch is structural: securing a large power transformer can take up to four years , with lead times having nearly doubled since 2021, while the campuses those transformers serve are being financed and committed to cloud providers before they break ground. A domestic manufacturing base is growing to close the gap, but not on the timeline the buildout wants. Lead time is only the visible part of the risk. "You've got supply chain risks, and I'm not just talking about long lead times," Andrews says. "There are security and cybersecurity risks, and there are now regulations tied to this." He points to recent moves to restrict foreign-made grid hardware, including the decision to add networked power inverters to a federal covered list over national-security concerns. This is the seam where third-party verification of a component's safety and compliance becomes part of the timeline, the kind of assessment work his firm does across the sector. For all the constraints, Andrews lands on the opportunity, and he expects it to run for a decade. He's an "all of the above" advocate on generation, arguing that a global society this dependent on compute needs every source it can bring online. The pressure also runs past data centers entirely. "We're just talking about data centers," he says. "Think about all the EVs coming into play, and the fact that everything in your house is connected now. All of it requires more power." The buildout that answers that demand, in his read, is less a crisis to manage than a generational investment. "I'm excited about what this will do for generations to come. It's a game changer, and it's already changing the world."

## AI Agents Earn Autonomy Process By Process As Companies Verify The Data Behind Them
URL: https://www.thedatawire.com/news/ai-autonomy-governance-challenges
Published: 2026-10-05T03:06:59.086Z
Section: AI
Summary: As more AI systems act without real-time oversight, leaders are weighing what a wrong decision would cost before handing over more work.
Full text:
The opinions expressed in this article are those of Sanjay Choubey alone and do not necessarily reflect those of any organization. AI agents at many large companies already act without a person approving each step, running code, placing inventory orders, and detecting security threats on their own. The pressing question for data and technology leaders is whether they can trust the data behind the decisions an agent makes, since that trust sets how much autonomy the agent should get. A system that routes customer emails and one that adjusts a production line both make decisions from data, but the cost of a wrong decision differs between them, as does how easily someone can verify the inputs. In one survey of senior AI executives at large US companies, 85% of those using agentic AI said at least a handful of their systems act without real-time human involvement, and 49% said their governance frameworks haven't been updated to cover agentic AI. Leaders who set limits on these systems often start with the data. They grant autonomy one process at a time, based on how far they can trust the quality and lineage of the inputs and what's at stake if the output is wrong. The data behind the decision Many executives worry they can't accurately trace or audit the data lineage and inputs feeding critical AI decision models. Sanjay Choubey , Global Chief Digital and Information Officer at Sylvamo , oversees AI programs that draw on both customer records and production data. "Can you trust the underlying data?" he asks. "Many of the decisions AI makes are based on that data, so what is your cross-check mechanism?" A system that acts on years of records can inherit whatever errors those records carry, and those errors then affect every decision the system makes from them. The first step in data intelligence is knowing where those records came from and how they were collected. Enterprises are beginning to recognize that data provenance can help determine how much authority they can safely give an AI system. "When you use AI, the real deal is how good or bad your data is," Choubey explains. "Your historical data will tell you mostly how you behave. That's why we look at people's experience when we hire: what have you done in the past?" Autonomy by what's at stake Deciding how much autonomy to grant starts with the workflow itself. An agent added to one step of a process affects the steps before and after it, including where its input data comes from, what context the agent needs to interpret that data, and who checks its output. For each process, Choubey's teams weigh how far they trust the data at each step, then decide which steps the system can complete alone and which need a person to review the output before the work passes to the next step. Lower-stakes back-office work is often where companies start. Tasks that run on well-documented data, follow set rules, and leave a record a person can check afterward let a company test an AI system on real work, since someone can catch and correct a mistake before it causes much harm. Some companies now onboard agents much as they would a new hire , starting them on well-defined work before trusting them with more. Agents working on live operational data need credentials and controls that limit what they can access and let a team stop them quickly. Some decisions can't be reversed once an agent has acted on them, such as a shipment released or a production run started. "Can you let AI manage your banking for you?" Choubey asks. "Can you trust AI with your life?" Comfort levels differ Some companies have already seen what a poorly governed AI deployment can cost, including lost data, financial damage, and disrupted operations. After a problem like that, executives often want more proof that the underlying data can be trusted before they approve another system that acts on its own. "Every organization has a different level of comfort," notes Choubey. "Some organizations that are almost entirely white collar may be more comfortable letting AI make some decisions on its own." Formal AI assurance reviews, the audits companies run on their AI systems, often lead companies to change systems they've already deployed. In the same survey of senior AI executives, 64% of those whose organizations ran one significantly modified a quarter or more of their AI systems, and 29% paused a quarter or more. Companies that decide how much autonomy each process gets before a system goes live, based first on the quality and provenance of its data and then on what a mistake would cost, can avoid some of those corrections later. "Even if you have the smartest and best AI, you may want a human in the loop who says, 'You do this much, but I need to review it,'" Choubey concludes.

## The Ultimate Shift Left: Embedding Security Into The AI That Writes Your Code
URL: https://www.thedatawire.com/news/shift-left-ai-code-security-ratinder-ahuja-everpure
Published: 2026-09-25T15:54:26.943Z
Section: Cyber Resilience
Summary: Dr. Ratinder Paul Singh Ahuja, Everpure's Chief Technology Officer and Vice President for Security and Networking, argues that when anyone can build an application in an afternoon, security has to move inside the AI tools themselves and prove its work before code reaches production.
Full text:
The distance between having a business problem and shipping software used to be measured in engineering headcount and months of work. Now, it's an afternoon and a prompt. Someone in legal, marketing, or finance can describe what they need, watch an AI assistant assemble a working application, and put it in front of colleagues before lunch. The catch sits in what that application carries: embedded credentials, standing permissions, and connections to systems of record that no security team ever reviewed. Speed like that is a real productivity gain, and it's also a new and fast-multiplying way for an enterprise to get breached. On the latest episode of The Data Wire's Beyond the IT Headlines podcast, Dr. Ratinder Paul Singh Ahuja laid out what that shift demands of security teams. Ahuja is Chief Technology Officer and Vice President for Security and Networking at Everpure , a serial security entrepreneur who has founded four companies and holds more than 70 patents. His argument starts from a premise most enterprises haven't caught up to: the age of the citizen developer has already arrived, and the security model built for professional engineers doesn't stretch to cover it. "This is the ultimate shift left. A team of five security engineers can't review code generated by thousands of citizen developers, so the standards have to be enforced programmatically, before anything ships," Ahuja said. When anyone can ship an app, the attack surface follows He doesn't treat any of this as a coming trend. It's already ordinary. "The age of the citizen developer is here. Anyone with an idea can use available tools to build applications." He offered a close-to-home example: a colleague on Everpure's legal team who turned a complex audit process into an automation using Claude Code, no engineering background required. That's the upside working as intended. The trouble starts when the same person hosts the result on a platform like Replit and takes it live without passing through any of the gates a secure software development lifecycle would normally impose: threat modeling, scanning for embedded secrets, sanctioned access to systems like Salesforce, penetration testing, and hardened deployment. "If you're building a small prototype to share a concept, that's fine," Ahuja said. "But as you take real business processes dealing with restricted data and want to use them widely, you need governed processes around a formal secure software development lifecycle." On platforms where users spin up new applications a day by the tens of thousands, only a fraction are enterprise-relevant, but his arithmetic is still sobering. A thousand a day is 365,000 a year, many of them wired into corporate data and running outside any governance process. The exposure compounds because this code doesn't stay put. Citizen developers publish snippets and whole projects to public repositories, where other builders download and reuse them. "It creates a worm effect that continues to fan out with a broader impact," Ahuja said. Speed makes an old failure mode worse. "People will build an app, embed the data file directly inside the application, and hardcode the secrets to connect the two right into the code," he said. Assistants have grown savvier about catching this, he noted, but the human stays in charge of ignoring them. "Claude's gotten a bit smarter about it, it'll try to mask secrets, but if you override it and say just hardcode it, it will," Ahuja said. "And most people don't even read the security alerts. They just click accept on everything." The permissions problem runs deeper than leaked keys. As enterprises move from building apps to deploying agents and agent swarms, those agents act directly on live data with administrative access and automated authority granted without much human thought. Every new connector, skill, and integration widens the ground they defend . The waste can pile up even without an adversary. "Badly written code can create infinite loops that call business systems, exhaust API tokens, or rack up $20,000 in unexpected cloud consumption," Ahuja said. The common thread, he added, is that nobody stops to ask where the data actually goes. If a security team can't review this volume of code by hand, the obvious responses are to abandon review or to slow everything down. Ahuja rejects both. His answer is to stop treating security as a stage that code reaches after it's written, and to build it into the tools doing the writing instead. That reframing is where his central idea lives. Security moves inside the coding tool, not the deployment gate Professional security has long had disciplined methods for this. Teams use structured frameworks to harden code against spoofing, tampering, and privilege escalation before it ships. What citizen developers lack, Ahuja argued, is any of that discipline, because a plain-language prompt almost never instructs the model to follow rigorous security standards. His fix is to move the discipline into the tool. "I built a fully governed development system that wraps around coding harnesses like Claude Code, Cursor, or Codex," he said. "It programmatically enforces the secure software development lifecycle without relying on the user to request it." In practice, the system performs threat modeling, writes security tests, and sets up least-privilege access as the code is generated, folding standards like industry hardening benchmarks directly into the tool. "This is the ultimate shift left," said Ahuja. "By embedding security standards like CIS benchmarks directly into the AI harness, security is enforced programmatically before deployment." Rather than letting developers build unhardened code and throw it over a fence to deployment engineers, the standards live in the harness itself. The piece that makes this trustworthy is what he calls a mechanical checker, a deterministic validator, not another AI, that sits between the coding agent and production. "It acts like an automated program manager with a checklist, refusing to let code pass to the next stage until every security requirement is validated." It exists because the coding agents can't be taken at their word. "You ask for ten things, they say all ten are done. What's the proof? You check, and only five are done." The checker's proof is concrete rather than declarative. "It requires positive and negative testing proof, for example, intentionally stripping out a security patch to verify that the test fails," Ahuja said. Every validated output is signed and timestamped, which he described as "a verifiable, auditable, and provably correct deployment outcome with a complete audit trail," rather than ten thousand lines of code nobody fully understands. He's candid that natural language alone won't get there. "You need a method to precisely capture your intent, not just 'I want a dashboard,' but a mathematically precise definition of that dashboard, so the coding agent can be verified against it," he said. "Natural language is open to interpretation, even between two humans, let alone a machine." The risk this contains is not hypothetical. Ahuja recounted an incident he traced to an AI system's test run that got loose. "It scanned 9,000 public-facing web apps, broke into some of them, and created a malicious Python package," the kind of AI-orchestrated attack that turns an organization's own tooling against it. The irony he drew out was that a security company that scans packages for a living then pulled that same malicious package into its own environment. Part of what makes these attacks land, he added, is that few teams actually know what they've connected . "Do you actually know what data access you've granted to that app, skill, or connector in your toolchain?" he asked. Building security into the harness handles the code an enterprise creates from here on. It says nothing about the systems already running, already connected, and, by Ahuja's reckoning, already compromised. For everything downstream of the coding tool, he leans on a different principle, one that assumes the worst has happened and plans around it. Assume the breach, then contain what an intruder can reach "There are two kinds of enterprises. Those that have been breached, and those that don't know they've been breached yet." Treat everything as already compromised, he argued, and prevention alone stops looking like a strategy. "Detection and protection alone are futile because breaches happen 99.9% of the time due to simple mistakes." What follows is zero trust and least privilege. "Once two parties authenticate, they're authorized to talk about exactly one approved topic, nothing more," Ahuja said. If that identity is later spoofed, the intruder still can't pivot elsewhere, because it was never permitted to reach those systems in the first place. The damage stays boxed into a narrow, defined lane. These ideas aren't new, and that's Ahuja's point about why they went unrealized. Enforcing least-privilege access was nearly impossible to implement at scale by hand. AI changes the economics. "Now AI can be used to discover the right policy and generate the least-privilege policy templates automatically," he said, which is what moves zero trust into a practical modernization step rather than a standing aspiration. Ahuja pairs containment with the assumption that recovery will be needed. Detection that fails silently isn't a plan, which is why security leaders have been shifting toward resilient data and provable recovery instead of prevention alone, and toward treating recovery as more than a disaster-recovery checkbox . The two halves reinforce each other: least privilege limits how far an incident spreads, and provable recovery gives the organization a way back from the incidents that get through. The outlook isn't purely grim. "Security has historically been asymmetric," Ahuja said. "Threat actors focus entirely on attacks, while thin internal teams defend vast enterprise assets. AI magnifies threat actors' capabilities by 10x." But those same capabilities can be aimed the other way, he said. "Leveraging these same AI capabilities and extreme shift-left methodologies levels the playing field. It gives defenders the same scale and intelligence to match the threat landscape."

## Energy and Cooling Join The Variables That Decide Where An AI Workload Runs
URL: https://www.thedatawire.com/news/fernando-faustino-grupo-souza-lima-ai-energy-efficiency
Published: 2026-09-24T17:22:00.118Z
Section: AI
Summary: Fernando Faustino, Executive Advisor for Digital Transformation and AI at Grupo Souza Lima, on the half of the AI energy story that gets less attention, where the models help generate the power.
Full text:
A single AI data center campus can draw 20 or 100 megawatts of power, and the grid has to supply it . AI can also help manage that power. It can forecast how much a region will need and match generation to it, and it can get more out of renewable plants that would otherwise run below capacity. The question worth asking is whether the power available at a given location should help decide where a workload runs. Fernando Faustino is Executive Advisor for Digital Transformation and AI at Grupo Souza Lima , reporting to the group presidency on IT modernization, data, and generative AI. He was previously Executive Head of IT at Sabesp, the São Paulo state sanitation company, and IT Executive Director at Grupo Petrópolis. Faustino's earlier roles span logistics, mining, energy, and software. Earlier in his career he built and ran data centers, including a Tier III facility certified by the Uptime Institute. "'Where will I put my workloads?' will be the question of the future. It's not just about the technology, it's about availability and price. To be the cheapest, I need to put my workloads in a place where I can have energy, cooling, and technology. All these three pieces need to work together," said Faustino. Energy and cooling depend on where the data center sits , and vary between countries more than most procurement models account for. Producing the power: Faustino points to Brazil's sugarcane sector, where Raízen produces ethanol alongside bioenergy made from the fibrous residue left after crushing. Optimizing that residue is the kind of problem machine learning handles well, and the electricity it generates can run the same infrastructure the models sit on. "All the people that I know think that AI is a big consumer of energy," Faustino said. "I think the opposite, that AI can create algorithms that help to generate energy more efficiently." What hyperscalers are asking: The question of what a given workload costs in electricity has barely reached the enterprises running those workloads. Faustino sees the accounting happening at the top of the market and almost nowhere else. The largest platform companies negotiate directly with generation and distribution firms , because their model training depends on securing the supply. "The enterprises aren't thinking about how my consumption of AI will affect the energy produced," Faustino noted. "I think just the biggest ones are, because they need this to put the models to work." Brazil makes the argument easy to see. Most of the country's electricity comes from renewable sources , with hydropower carrying the largest share and wind and solar close behind. Wind output peaks between June and November, while hydro reservoirs sit at their seasonal low. The combination has drawn hyperscale investment, including two Microsoft AI data centers that opened in January. Faustino reads the position as one Brazil has not fully claimed yet. "Here the energy is not a problem," Faustino explained. "If Brazil can be a bit smart, we can be a big market for data centers and take some of the opportunity." Energy enters the price: Leaders already compare cloud prices region by region when they decide where to run something. What sits behind those price differences includes the cost of electricity in each location. "When you add a machine in AWS cloud, if you put your workload in Virginia there will be one price, and if you put it in Brazil there will be another price," Faustino said. "I think that energy will be a variable of this calculation." Latency, residency, redundancy: Energy joins a list of constraints that already pull against each other, and Faustino hit all of them at Sabesp. Brazilian law required the data stay in the country, and the Azure regions available locally didn't give him the redundancy he needed for certain components. Running the contingency out of the United States solved redundancy and broke latency. "I talked with GCP and put the workload as a contingency to work in one region here in Brazil," Faustino said. "I had Azure and GCP working together." Placement decisions come with too many competing constraints to settle at once, so Faustino works through them in order. Residency comes first, since data sovereignty is a legal constraint and not a preference. Redundancy follows, then consumption, and he treats consumption as three separate quantities. Price lands at the end, after the constraints have narrowed the field. "When I am talking about consumption, it is energy, water, and cooling," Faustino said. "The last one is the price. The price is either okay or not okay for me." What convinces Faustino that power belongs in the architecture conversation and not in facilities is the scale of what a building draws . He built a data center more than fifteen years ago and remembers what it drew, before anyone was training models in one. Cooling compounds the problem, since moving and chilling water costs power of its own. "A small data center, we're talking about three megawatts, five megawatts," Faustino added. "It's too much for just one company." Those figures predate AI training entirely, and he has yet to form an estimate for where the demand settles. "I don't know when we will stop," Faustino concluded. "I don't know how we will be in five, even ten years, because AI is changing a lot of things."

## Restore Testing Gives Database Teams Proof Their Recovery Plan Works
URL: https://www.thedatawire.com/news/mariyan-clement-ibm-advocates-restore-testing
Published: 2026-09-15T22:37:44.165Z
Section: Future of Data Management
Summary: Mariyan Clement, Database Architect at IBM, explains why monitoring a backup job proves nothing about recovery, and why he destroyed his own database to find out what a restore really involves.
Full text:
Database teams monitor backup jobs the way they monitor any scheduled task: the job ran, the file landed in storage, and the dashboard is green. However, these signals say nothing about what happens when someone has to bring the database back, how long that takes, or whether the application on top of it starts cleanly. Enterprises running production data on that assumption often learn the difference during an incident . Mariyan Clement is a Database Architect at IBM who has spent two decades in database architecture across banking, telecom, manufacturing, and energy. Recent engagements cover PostgreSQL performance tuning on AWS and a Sybase to PostgreSQL migration for an Australian bank. He also led a Siebel to PostgreSQL migration that cut a batch process from 48 hours to 45 minutes. To date, Clement has trained more than 1,000 engineers in database technologies. "A backup isn't a recovery strategy until you've actually restored from it. Most teams check whether the backup job succeeded and whether the backup is sitting safely in storage. The real questions are: Can you restore it? How long does that take? How much data could you lose? And does the application come up cleanly afterward?" says Clement. He treats the restore as the only evidence that counts. A monitoring stack can report success on every backup job in an estate and still leave a team without an answer to any of those questions. Proving the restore works Clement tests his own recovery before telling other teams to test theirs. Object storage sits at the end of most backup chains , and pulling a database back out of it is the step teams write into a runbook and skip in practice. "I built a small lab around exactly this," says Clement. "It is a PostgreSQL and S3 setup where I deliberately dropped the database and rebuilt it from object storage, just to go through the full recovery process myself." Two of the questions he asks map to numbers most teams already carry on paper. Recovery time objective and recovery point objective appear in continuity plans as targets, agreed with the business and signed off. A completed restore turns them into measured figures, and many teams have never compared the two . "A backup gives you a file," he notes. "A restore test gives you confidence." Learning in the pool Clement argues for a standing environment where teams can run scenarios, separate from production and available before anyone needs it. Recovery procedures get written once and run rarely , so the first attempt is usually also the first time anyone has read them closely. "Teams should have a safe environment to practice things like accidental deletion, corruption, point in time recovery, failover, and other recovery scenarios before they happen for real," says Clement. "I think of it as learning in the pool before you're in the ocean." Clement prefers each drill to end with figures attached to it. The scenario has to run far enough to produce them, past the point where a tabletop exercise usually stops. "DR drills shouldn't just live in a document," Clement explains. "Run the scenario, measure how long recovery actually takes and how much data you'd really lose, see what breaks, and document the gaps." A team that has worked through a failover twice knows which steps take longest and where the written procedure and the live system disagree. Both of those take more than one run to find. "Each drill should make the next real recovery better," he adds. "You don't want your first rehearsal to be the day production is down." New workloads, same fundamentals AI workloads land on the same platforms and change what a database team is asked to guarantee. Clement sees the job widening past uptime and latency to the condition of the data itself. "AI workloads bring new data types, vector search, embeddings, higher concurrency, and new data access patterns," says Clement. "Database professionals increasingly need to ask not just 'Is the database up?' but also 'Is this data reliable, governed, secure, performant, and fit for what's consuming it?'" Clement argues older work carries more weight now, and the controls teams already built are the ones AI systems inherit. "The fundamentals don't go away. Transactions, indexing, query optimization, backup and recovery, security, data quality, and governance remain important," he says. "If anything, those fundamentals matter more, because AI just raises the cost of getting them wrong." When asked what a company should fix first, Clement returns to the restore. Monitoring reports on each piece separately, and an incident is the first time they all run at once. "You can have backup jobs succeeding, replicas running, and monitoring dashboards looking great, and still find out during a real incident that recovery doesn't work the way you assumed," Clement concludes. "Don't wait for a production incident to find out your recovery plan only worked on paper."

## Enterprises Solved the Easy Half of AI Cost Discipline but Still Struggle to Measure Value
URL: https://www.thedatawire.com/news/ai-token-costs-enterprise-llm-usage
Published: 2026-09-15T19:19:04.418Z
Section: AI
Summary: AT&T's Ashok Kumar argues that enterprise AI maturity depends on looking beyond token consumption to the value produced, the context required, and the infrastructure costs underneath it.
Full text:
Most enterprises can now put a number on what AI costs them, and tokens are the unit that makes it possible. Because billing runs on tokens, teams can look disciplined by staying within allocation even when the quality or usefulness of the output remains unclear. Token spend is increasingly being used to compare models, price projects, and decide which programs deserve continued funding. Ashok Kumar , Principal Data Scientist at AT&T, leads generative AI, LLM, and agentic AI initiatives from strategy through production, which puts him close to the infrastructure costs behind enterprise AI. He spent more than two decades in the field, including work in classical machine learning, and makes the case for better measures of LLM value. "The intelligence produced from the same number of tokens can be completely different," Ashok argues. "Two models given identical budgets are not necessarily doing comparable amounts of work. A cheaper per-token rate can produce a higher cost per completed task when the output needs a second pass, and none of that appears in a consumption dashboard." Why LLM usage stopped being the automatic default When LLMs first reached employees at scale, the instruction from leadership was to use them. Teams were encouraged to build solutions around GenAI, and adoption itself was treated as the metric worth moving. Nvidia's Jensen Huang gave the maximalist version of that position publicly, saying he would be “deeply alarmed” if a $500,000 engineer consumed less than $250,000 worth of AI tokens in a year. Then the invoices landed. Organizations started seeing what the projects cost and how quickly the numbers could climb. "Because these projects are affecting the balance sheet, LLM usage is no longer becoming the automatic default," Ashok explains. Teams started asking if each step required a model call at all. Ashok argues that repetitive jobs and workflow-based tasks are where AI earns its place, particularly when the alternative is significant human resource cost or the work absorbs too much of a team's time. More demanding work calls for a different allocation. "If something is highly complex and requires human intelligence, that's where you should focus your team's bandwidth." Context as the invisible line item Once a model does belong in the workflow, the next question is how much context it needs. Much of the resulting spend accumulates without an explicit decision, which is why it can survive rounds of optimization aimed at the wrong layer. "Data is really the context component," Ashok explains, and the cost consequence follows directly from how much of it gets passed. A chatbot working through a conversation window may resend the entire history every time the model is called, paying repeatedly for information the system has already seen. "That consumes tokens unnecessarily," he notes. "You should only pass the information that is relevant at a given point in time, instead of passing everything available by default and absorbing the difference." The business value behind the token count Reducing excess context lowers consumption, but the value produced by that consumption remains unresolved. The industry settled on tokens as a unit early, largely because they were easy to count. "Tokens are primarily used as a unit for measuring consumption," Ashok explains. “From my perspective, we should think about them as a way of measuring AI productivity too.” Billing reinforces the flattened view because companies pay for tokens, not intelligence. The same misalignment appears within individual organizations. Give two employees identical token allowances, and the question becomes what each gets out of them. "They may both be spending the same amount, but the value they produce can be completely different," Ashok notes. Organizations should also account for the compute underneath the output to extend measurement beyond API usage to the infrastructure supporting the system. Memory architecture for reduced token spend Multi-agent systems often need access to more information than a context window can hold. Ashok describes context engineering as a hierarchy of memories. Recent and relevant information stays close to the agent, less frequently needed data sits in a knowledge graph or database, and a metadata layer helps the agent determine what exists and where to find it. "It's similar to the way we design operating systems, with hierarchies of memory and mechanisms for determining which information should be available at a particular moment." The structure varies by use case, but the goal is to keep only the right information within immediate reach and reduce the tokens needed to complete a task. The broader cost of AI infrastructure Enterprises are still building, but they're starting to price the whole system, not just the model call, and that's the maturity signal worth tracking. "I wouldn't say they're underestimating it, but they are becoming much more cautious about cost," Ashok says. Data movement, storage, retrieval, and the compute environment underneath all belong in that calculation. Once those costs are included, efficiency per unit of consumption becomes a more useful measure of AI maturity than consumption volume alone. The outer boundary of that accounting is the one the industry has been slowest to price. Data centers require significant water and energy, the buildout continues, and current rates depend on financial support that cannot continue indefinitely. "I'm not sure the current model is sustainable because of the level of subsidization we're seeing," Ashok cautions, "and you cannot simply continue putting data centers and compute infrastructure everywhere without consequences."

## Product Portfolio Discipline Makes Data Retention A Measurable Decision
URL: https://www.thedatawire.com/news/sahar-mirmahmoodi-eppendorf-discusses-ai-buildout-challenges
Published: 2026-09-15T15:10:05.748Z
Section: AI
Summary: Sahar Mirmahmoodi, Digital Product Lead for Laboratory Automation at Eppendorf, argues that transformer shortages and power limits give enterprises a reason to decide which data earns its storage.
Full text:
The volume of data a company generates, moves, and keeps has started to carry a cost measured in megawatts and delivery dates. The constraint on enterprise AI has moved from chips to electrical equipment. Data center operators are competing for factory slots on high-voltage transformers and substation gear, and the wait for those units now runs into years. Enterprises are finding that what they choose to retain has become a decision with a number attached. Sahar Mirmahmoodi is a global product and business leader in instrumentation, sensors, and industrial and building automation, focused on the shift from hardware to SaaS and AI-enabled platforms. She has led product, P&L, and commercial strategy across the sector, including running a global business unit for water-quality instruments, software and services, with earlier roles spanning industrial components and building-automation/IoT platforms. Her career has run through the equipment layer that now constrains AI buildouts. "We're at that level to think, 'Do we really need to create so much data?' The cost of creating data is no longer abstract. It's going through the whole physical layer, and it tangles into everything behind it: power, equipment, and lead times," says Mirmahmoodi. The electricity bill is the visible end of that physical layer, and equipment that takes years to build sits behind it. Her argument is that the amount of data driving both deserves the same scrutiny a company applies to anything else it funds. Transformers set the pace Lead times on high-capacity transformers have stretched to four years , and those dates now set the schedule for new grid capacity. Transformer production is capital-heavy and low-margin, and several manufacturers sold or wound down those lines over the last decade. Mirmahmoodi was inside that industry while it happened, and took part in one of the exits herself. "Within the last decade most of the players wanted to move more into the use case of the software, sensory intelligence, which makes sense," says Mirmahmoodi. "But the industry didn't think about the heavy duty elements of this supply chain. Transformers are one of them. It takes years and multi-hundred millions to build a capacity." Enterprises that can't add capacity on demand have to decide which workloads justify the capacity they can get. Mirmahmoodi counts that as a benefit. "The physical limitation that is happening right now is going to slow down the expansion," she explains. "I'm not saying AI is going to slow down, but the bottleneck gives us a moment of pause as leaders, to think about how meaningful and insightful we can be about the choices we make regarding the data." Physical cost and buildout budget Enterprises budget each stage of their own buildout separately, and Mirmahmoodi's argument is that the compounding never appears in a single business case. "If you want to have more data centers, then you need more physical layers, and the physical layers need to be more intelligent," says Mirmahmoodi. "When you ask for more intelligent sensors and more chips to be integrated in your system, then you're collecting more data, and the more data you're collecting, the more data centers you need." Capacity kept pace with production for most of the last decade, so the question of whether a given dataset should exist rarely came up. Mirmahmoodi describes teams reaching for more AI without pricing the request, and she believes the correction arrives through cost. "At ten euros a month, then fifty, you start thinking," she says. The business case for data The first question is whether a dataset can support AI work at all, and Mirmahmoodi wants people with the right expertise answering it. A dataset that can't be used consumes the same storage as one that earns its place. Migration adds a second bill on top of that, and in some industries the alternative is to generate the data again from scratch. "In life science they're using AI in drug discovery, and they already have a lot of patient information," she notes. "But it's much more costly for them to transfer them into a new AI ready form than to start a new experiment with new patients and new data." Mirmahmoodi applies the discipline she used on product portfolios, where a line gets reviewed, repriced, and eventually retired when the business case stops holding. She spent years making those calls on instruments and sensors. "Product discipline isn't only about retiring what doesn't work, it's asking, up front, whether something's worth creating at all," she adds. "Data is no different: is it worth generating? Does it still earn its keep? It's a product, so apply the same principle end to end." Catching up the KPIs Every solid business case needs a metric behind it. Data lifecycle decisions pay back over years, while the numbers executives report on land every quarter. The same mismatch runs through hiring, where the skills a company rewards steer people away from work that later turns out to be scarce. "The technology has been advanced a lot, but in my opinion, the financial and HR KPIs relevant to these technologies still measure success according to the standards set 100 years ago, built for heavy, factory-era industry," she says. Sustainability reporting gives Mirmahmoodi a precedent, and she poses the same scenario for data. "Think about how the CO2 footprint evolved. A decade ago almost no one measured it. Today it's a standard part of corporate reporting, with targets and disclosure," she concludes. "Data is on the same path. Its cost and footprint will move from something we ignore to something leadership has to measure and answer for. And once you have to report it, you think very differently about how much data you create."

## AI Turns Enterprise Memory Into A New Data Layer The CISO Must Defend
URL: https://www.thedatawire.com/news/ai-memory-enterprise-risk-management-maria-luisa-redondo-tk-elevator
Published: 2026-09-15T14:59:42.296Z
Section: AI
Summary: AI memory increases what a system can connect, not just what it knows. María Luisa Redondo Velázquez, Global CISO at TK Elevator, says that's where the new risk lives.
Full text:
Much of the value enterprises are seeking from AI increasingly sits below the model. It sits in what a company can retrieve from its own accumulated knowledge, like its documents, decisions, and institutional context, and then feed back into the systems making decisions. That accumulated knowledge increasingly functions as a form of organizational memory. Once an organization treats it that way, a set of questions opens up that the storage conversation never had to answer. What should the system be allowed to remember, on whose behalf, and how does anyone prove that this memory hasn't been tampered with ? Working to tackle these questions is María Luisa Redondo Velázquez , Global CISO at TK Elevator, where she leads cybersecurity strategy across an industrial manufacturer operating in more than 100 countries. Over two decades in the field she's built security functions from the ground up across IT, cloud, and OT environments, and now advises executive committees and boards on how technology risk translates into business decisions. Her approach to AI draws a line most enterprises miss: the risk in giving it memory isn't mainly about what it stores, but about what it can join together. "AI memory doesn't just increase what AI knows. It increases what AI can connect. That's where the new risk appears," she says. Redondo Velázquez is clear that this isn't an argument against memory. She's quick to share that she uses AI daily herself for tasks like moving from a blank page to a first draft. The value to an enterprise, in her account, is the same accelerant scaled up, but only if the thing the AI reaches into has been built for that purpose. Memory needs permissions along with capacity The temptation, as memory becomes the differentiator, is to give AI more of it. Redondo Velázquez pushes back on the premise. "I don't think enterprise AI should have unlimited memory. The challenge is not giving AI more memory. It's giving the right memory, with the right permissions, for the right purpose, at the right time." That assertion reframes a capacity question as a governance one. Memory, in her model, needs the same foundational controls security teams already apply elsewhere: ownership, permissions, retention limits, provenance, and traceability. An employee should be able to retrieve only what they're authorized to see, even when the underlying system technically holds far more. The point where information from across the business gets connected is exactly the point where access has to be governed most carefully, because things that look harmless on their own can become sensitive once stitched together. The attacker doesn't need to steal anything The sharper risk in Redondo Velázquez's view is not exposure, but manipulation, and it changes what security teams have to defend. For years the priorities were confidentiality and availability: keep data from being read, keep it from being locked up. AI retrieval makes a third priority—integrity—far more consequential. "If an attacker can manipulate the data an AI system retrieves, they may not need to encrypt anything," she points out. "They could just influence the decisions or the outputs of the AI." That's a different threat model from ransomware. An adversary who can poison what a model pulls from doesn't have to take the database hostage. They can bend its outputs by altering the knowledge underneath. Defending against it, she believes, means controls aimed at integrity rather than just access: provenance, versioning, and continuous validation. "We need to know where information came from, who changed it, when it was changed, and whether the AI is relying on trusted information or not." It's also why she now treats a robust data infrastructure as part of the security perimeter rather than a layer beneath it. Rather than repairing a weak data foundation, AI exposes it and acts on it. "The system uses what you already have. If that information is inaccurate, outdated, or compromised, the AI can reproduce—or amplify—the problem." Distribute the data, centralize the governance Because AI-connected systems can increasingly reach across silos in a business, Redondo Velázquez doesn't believe prevention alone holds. She frames the alternative as active defense. An environment can't be trusted just because it was secured once. "We continuously challenge the environment looking for anomalous behavior, manipulation, or attempts to compromise the integrity of the information," she shares. Continuous monitoring, deception, provenance validation, and isolating compromised data all sit inside that posture. Paired with this is an architectural choice. Consolidating all of an organization's knowledge into one repository, she warns, creates both a concentration risk and an attractive target. Her prescription is to spread the information out while keeping a single grip on the rules around it. "Distribute the information, standardize governance, and continuously defend the integrity," she says. Recovery extends beyond restoring data The part of this approach that Redondo Velázquez views as the least resolved is recovery. The old playbook assumes that if you can restore the data, you're whole again. AI memory breaks that assumption, because the thing being restored is the context the business now reasons from. The questions she wants teams asking are where the memory actually lives, how it gets backed up, and how anyone knows a restored version is trustworthy and hasn't been manipulated while stored. "For traditional systems, recovery often means getting the data back. For AI memory, recovery also means restoring trust in the information and infrastructure," she says. This perspective reframes recovery as a resilience, security, and governance problem at once, and it's a growing reason CISOs are moving into conversations that used to belong to storage and infrastructure teams. Ransomware taught enterprises to think about recovering availability. Memory, in Redondo Velázquez's account, makes them think about recovering integrity—and proving that integrity has been restored.

## Software Efficiency Gives Infrastructure Teams Another Lever Beyond Adding Capacity
URL: https://www.thedatawire.com/news/ai-energy-consumption-software-waste-janne-kalliola-coonti
Published: 2026-09-15T14:59:23.160Z
Section: Future of Data Management
Summary: Janne Kalliola, Founder of Coonti, argues that software waste compounds across the technology stack and becomes more costly as AI scales.
Full text:
Inefficient code is easy to dismiss when an application feels fast. Modern infrastructure can absorb a slow function or bloated dataset without creating an obvious problem for the end user, but the cost spreads through the stack. Unnecessary computation generates data that must be moved, stored, and processed again, turning the application waste into infrastructure demand that organizations keep paying for long after the original inefficiency is forgotten. Janne Kalliola , Founder of Coonti , has been making this argument since 2019, well before AI energy consumption brought the issue into boardrooms. His experience across software architecture, product development, and commercial leadership has shaped his view of IT sustainability as an engineering problem measured in energy and efficiency. He sees today's AI boom as an existing problem amplified by far greater amounts of compute and data. "Waste is energy consumption that doesn't add value," Kalliola says. Applied to computing, it turns a question usually framed in moral terms into a testable one: does a given unit of infrastructure produce a proportional return? Abundant infrastructure made software waste easy to hide For most of the last two decades, computers have been fast enough to make bad code invisible. "Computers are so powerful nowadays that you can't really distinguish whether something's poorly made," Kalliola says. "It has to be extremely badly made before it stutters or has visible lag." That wasn't always true. When Kalliola started programming in the 1980s, poorly written software simply wouldn't run. It wouldn't fit into memory, or it'd be too slow to be useful. Those constraints forced discipline. "Today, almost anything runs, or at least limps along well enough that users don't notice," he notes. Kalliola attributes this shift to the cornucopian paradigm , in which IT design and development practices assume there will always be more power available in the future because of Moore's Law and that the cloud offers unlimited computing power. Scaling becomes somebody else's problem, so nobody has to see the cost of ignoring it. "Computers are so much faster than human senses that we simply can't see what's happening behind the scenes," he says. "We can't see that fast or think that fast, so it stays hidden." When infrastructure feels unlimited, inefficiency doesn't register as a decision at all. Software waste cascades across the stack Efficient software reduces demand across the technology stack. "They're usually faster, so you get a better user experience," Kalliola says. "In the web context, search engines value speed, so you get better SEO. They typically transfer less data, so you need less network capacity. They have lower storage requirements, so you need less disk space. Less is less. It cascades." The same applies in reverse. Inefficient software consumes more compute, and that waste spills into the rest of the infrastructure, increasing the amount of data that has to be moved and stored. What starts as a compute problem can quickly become a networking and storage problem too. Storage tends to be treated as the passive part of the stack, where data sits until someone needs it. The energy cost comes down to how much data exists and how efficiently the system handles it. "Either you have too much data that needs to be processed, or you have inefficient ways of processing that data, or you have a combination of both," Kalliola says. He illustrates the point with an analogy. "Imagine you're diving for pearls. If the ocean becomes ten times bigger but contains the same number of pearls, you simply have to dive much more. That takes energy." As bandwidth and storage became less scarce, the incentive to optimize weakened. Storing more data is only half the cost. What the system does with that data afterward, again and again, is the more expensive half. AI raises the cost of inefficient software AI accelerates the tendency to throw more compute at more data instead of asking whether the same outcome could be reached more efficiently. More data and heavier processing methods compound each other, and the risk grows when AI starts writing the software itself. A model trained on decades of code written during an era of assumed abundance is unlikely to produce lean output by default because it has little lean output to learn from. "If we lose the craft and people no longer know how to optimize software themselves, there's a chance the AIs won't be able to do it either," Kalliola warns. That's a harder problem than any single inefficient model, because it suggests the industry's baseline for "acceptable" code is quietly moving in the wrong direction, at the exact moment AI is scaling how much code gets produced. Why measure inefficiency before scaling If AI makes inefficient software easier to produce at scale, teams need to measure that waste before infrastructure expands around it. "I think the only really good metric at the end of the day is energy consumption," Kalliola says. The method is straightforward. Establish a baseline, then check it with every release. A sudden increase in consumption after a change is a reason to revisit that change rather than quietly absorb the cost and scale around it. Most organizations don't have energy-consumption data readily available, so Kalliola points to execution time as a useful proxy. Tracking whether software gets faster or slower gives teams a practical way to spot inefficiency without specialized measurement infrastructure. "This requires discipline, and it requires somebody from the technical side to say, 'This is important,'" Kalliola says. "Otherwise, it's like Don Quixote fighting windmills. You won't win because nobody is supporting you." Optimization as part of infrastructure design Every unnecessary computation creates work elsewhere, from additional data movement and storage to more capacity that has to be provisioned. Even genuine efficiency gains don't necessarily stay banked . "When we save something, we run into Jevons paradox. We use those savings to invest in something new, and then we end up consuming more energy," Kalliola notes. The goal is to keep infrastructure use proportional to the value it creates. Two approaches that deliver comparable outcomes aren't equivalent if one costs an order of magnitude more to run. That puts efficiency alongside latency, availability, and security as a constraint worth designing for from the start. "If we're doing something that doesn't add value, or if we could get the same value with ten times less energy consumption, then we should choose the option that consumes less energy," Kalliola concludes.

## As AI Uncouples Data From Applications, Storage Becomes The Foundation For Sovereign AI
URL: https://www.thedatawire.com/news/ai-redefines-enterprise-data-management-prakash-darji-everpure
Published: 2026-09-14T18:07:36.533Z
Section: Future of Data Management
Summary: Prakash Darji, GM of Digital Experience at Everpure, on why data primacy and corporate sovereignty are the new foundations of enterprise architecture.
Full text:
For four decades, enterprise data has lived inside the applications that produced it. Finance data belonged to the finance system, sales data to the CRM, and the work and the data traveled together as a single unit. AI breaks that arrangement. An agent asked to approve a profitable sales order needs sales data, finance data, credit-check data, and support logs at once, none of which sit in one place. The question that defines modern data management is no longer how to store what an application generates, but how to find what's relevant across everything the enterprise already has, and expose it safely. Prakash Darji is General Manager of the Digital Experience Business Unit at Everpure . He came to infrastructure by way of the application and data layers above it, with earlier stints at SAP building applications and working on the HANA in-memory database and business intelligence products. That vantage point shapes his read of the current moment as a structural inversion of the relationship between data and the software that uses it—a shift Everpure CEO and Chairman Charles Giancarlo , and board member Andy Brown , frame as the move from data processing to data primacy . "Data, if you look at its story arc, was once subservient to applications. Now it's going to stand on its own," he says. The reversal cascades through everything downstream: how enterprises find the data that matters, who controls it, and what the storage layer underneath is being asked to do. The work and the data come apart Darji frames the shift with a look backward at the relationship between work and the data that has historically enabled it. "Data and work used to happen in the same place," he says. "The shoemaker had knowledge of how to make a shoe, and he made the shoe. The data and the work went together." Applications inherited that pattern: the finance application created finance data, which was used in the finance application, in a closed loop. AI severs it. "AI completely inverts the pyramid. The work is whatever the agent does, and the data is whatever it needs to do the work, regardless of where the data sits. They're no longer together," Darji explains. The inversion retires an older definition of the data management discipline. It once meant integration, copying data out of silos into a warehouse to query and analyze it. In an agent-driven enterprise, the first problem is different and more basic. "The most fundamental question is which data is relevant," Darji says. It's not an abstract concern. Feeding a model more than it needs can actively degrade the outcome. "The more data you give a model that isn't related to the problem you're solving, the more it hallucinates, and the more it token-maxes and spends your AI budget for a worse result." Getting the answer wrong in either direction, with too much data or the wrong data, is expensive, which puts a premium on knowing precisely what to retrieve. Intelligence is how the enterprise finds what matters Answering "which data?" at enterprise scale is the job Darji assigns to data intelligence, and it's the connective tissue between the architecture he describes and the governance it requires. The function, as he defines it, finds data wherever it lives and classifies it along several axes at once . It identifies the business domain a given dataset belongs to, whether finance or HR or sales. It builds a knowledge graph of what relates to what, mapping how a purchase order in one system corresponds to a record in another. It also flags what carries privacy or regulatory weight, like the personally identifiable information that can't cross a border or the transaction data that must stay secured. This is where the primary-source problem becomes acute, and Darji reaches for an everyday analogy to make the point. "In an enterprise, Salesforce could have the primary-source information about my sales orders, or a spreadsheet on someone's desktop could. Typically the spreadsheet is a copy, but AI doesn't know the difference. Data is data." Without a way to distinguish the authoritative record from its derivatives, an AI system reasons over whatever it finds, copies included. That same visibility layer is what different stakeholders each reach for from their own angle. Darji has watched a CISO start building the catalog out of concern that proprietary information is leaking into AI, only for the chief data officer and the application owners to discover they need the same map for their own purposes. "Each persona is looking at that lens from a different facet, but the answer is the same technology—a knowledge graph of all of the entities and relationships in my organization, with semantic context or shared context that can be used for multiple personas in multiple places." Sovereignty is about ownership, not geography The thread running underneath all of this is ownership, and it leads Darji to the word he thinks is most often misread in these conversations: sovereignty. In his view, sovereignty goes beyond its usual association with where data physically sits. "I'd define sovereignty not as geopolitical sovereignty, but corporate sovereignty," he says. "How do you own your data ? It's not about a locale. It's not about time. It's that this is mine, and the moment I give it to someone else, they're going to think it's theirs." Hosting a copy inside a hyperscaler's in-country region, he argues, doesn't settle the ownership question that matters. The remedy Darji proposes is to make data, rather than the application, the thing the enterprise builds around . "Applications should be workflows that consume data you own. You shouldn't have to buy the data container and the application together," he asserts. Treating data as primary in this way, he says, links sovereignty to efficiency: it cuts the endless copying that moves the same record into system after system, each copy a fresh chance to lose lineage and introduce error. "Data doesn't like being moved. It likes being accessed." Find and remediate over lock and prevent This philosophy puts Darji at odds with a governance style built on restriction. From his vantage point, locking data down until it can't be used defeats the reason for keeping it. "If you have your data and can't use it, what's the point of even having it?" The alternative he favors starts from total visibility rather than blanket prevention. "There's no start to governance if you don't know where your data is ," he says. Once an enterprise can see everything, compliance becomes a matter of detection and response rather than pre-emptive lockdown. If a scan turns up PII that was supposed to stay in Europe now sitting in Australia, that surfaces a conversation and a remediation, isolating or moving the data, rather than a wall that would have blocked legitimate work in the first place. "It's going to be more find-and-remediate, not control," he notes. Storage moves up the stack The architectural payoff Darji points to is a storage layer that understands the business meaning of what it holds. Historically, storage knew only technical primitives, like volumes, file systems, and blocks, with no notion of what the data was for. He describes an emerging model in which policies attach to semantic data groups, defined in business terms. An enterprise, for example, could designate all finance data related to approving purchase orders as a group and set its availability, resiliency, and recovery policies against that business definition rather than against raw storage constructs. "That's coming. That's not a thing that exists today, but it's emerging as a new capability that's now required in the world of AI," he says. Underneath the architecture is a problem Darji identifies as the real driver of change: integration cost . "The single largest human-capital line item in the IT budget isn't software spend or hyperscaler spend. It's the integration cost of all the things you bought." A common, governed data foundation that AI, applications, and analytics can all work from, without copying, is his answer to that cost, and the reason he expects the shift to happen quickly. "The only reason anything ever happens is customer need," he says. "The pain point here is real."

## Small Modular Reactors Turn Data Center Operators Into Owners Of Their Own Generation
URL: https://www.thedatawire.com/news/small-modular-reactors-data-center-power-cooling-husam-mohammed-jacobs
Published: 2026-09-11T10:45:55.044Z
Section: Future of Data Management
Summary: Husam Mohammed, MEP Design Director at Jacobs, on why the campuses being designed now are expected to produce their own power, water, and cooling on site.
Full text:
Data centers running AI workloads need far more electricity than conventional computing requires, and large volumes of water to carry away the heat the servers generate. When the local utility can't deliver that much power and water fast enough, developers generate their own electricity and produce their own water on site rather than wait years for a grid connection. Small modular reactors are one option. A compact nuclear unit installed beside a data center can power the servers, run a desalination plant for the water, and pass its leftover heat into equipment that converts it into cooling. Husam Mohammed is MEP Design Director at Jacobs , a global engineering and professional services firm that designs and delivers major infrastructure programs. He's based in Riyadh, where his team designs data centers and giga-projects across Saudi Arabia, a market with limited fresh water and constant pressure on the power grid. He rejoined the firm after nearly 11 years there earlier in his career, having helped deliver projects across offices on several continents. "Now you can have the power source next to the data center. That creates a local ecosystem that is very sustainable," Mohammed says. A campus built beside its own reactor doesn't need the transmission lines, substations, and access roads that link a remote site to a distant power plant. It can also produce water on the same ground, which is what solves the cooling problem. Power buys water Two questions decide whether a data center project happens at all. "If a client comes and says I want to build a data center, the first thing we ask is, do you have power? And do you have the water?" Mohammed says. Power gets answered first. A site with electricity can make its own water, because desalination and recycling both run on power. A site with water has no way to turn it into electricity. That's why the reactor, not the treatment plant, sits at the center of the design. Both questions have gotten harder because of a change in the hardware. Racks in AI facilities now run hotter than moving air can handle, and the liquid systems that replace air cooling put water directly against the equipment instead of into a tower at the far end of the process. That moves water further up the list of things a site has to secure before it breaks ground. "Now with AI, the cooling load for these data centers is extremely high. So air-cooled solutions on their own are no longer sufficient for these densities," Mohammed notes. A reactor's heat drives a desalination unit, and the site's wastewater can be cleaned and used again instead of discharged. Across the Gulf, that thinking shows up in water security investment rising alongside compute capacity. "You can have a nearby desalination plant that includes water reuse, black water recycling and gray water recycling. You can also use absorption chillers," he says. Absorption chillers turn the reactor's waste heat into cooling. Most chillers use electricity to produce cold air. Absorption chillers use heat, so what the reactor throws off becomes the input that cools the servers. Two problems cancel each other out. Operators who pair that setup with closed-loop liquid cooling cut their water draw and their electricity draw at once. "Because you have a demand for cooling and you have waste heat at the same time, you can take some of that heat to absorption chillers and produce your own cooling," Mohammed adds. Building without reactors Small modular reactors are years away. The data centers are going up now. None of the campuses Mohammed's team is designing will have a reactor to draw on when they open, and the first units in Saudi Arabia are not expected to run until sometime in the 2030s at the earliest. Developers aren't waiting. Mohammed describes local builders putting up facilities with capacity already committed to large cloud providers before the doors open, the financing settled ahead of construction. Every project built that way runs on whatever is available today, which in practice means the grid or gas. Interest in reactors is real, and the volume of conditional offtake agreements between data center operators and reactor developers has nearly doubled in under two years. These are advance commitments to buy power that doesn't exist yet. That leaves an open question about what the market looks like when the first reactors finally arrive. If conventional supply has already served most of the demand, the case for building reactors weakens. Mohammed expects the opposite, that demand will outrun the grid and make the alternative worth paying for. "There needs to be this balance where you have so much investment happening in data centers, but at the same time the infrastructure is not able to meet the demand. So at that point SMRs would be very attractive," he adds. The buyers those reactors would serve are already feeling the pressure. In a survey of 300 executives , MIT Technology Review Insights found that nearly all expect their AI-related energy use to climb over the next year and a half, and two-thirds had already absorbed energy cost increases of 10% or more. Connecting a large facility to the grid takes years in most major markets, and long connection delays have made the utility something developers work around. Gas generators on site have filled most of that gap so far, because they can be installed quickly. Reactors take longer to build and longer to license, which is why they show up in long-range plans while the buildings finished this year run on something else. Rules lag hardware The engineering is further along than the paperwork. Buying a reactor, moving it across a border, licensing it, handling the waste, and selling the surplus all depend on rules that are still being written, and each one sits with a different government body. "There's a lot of discussion that needs to happen between these technology leaders about the procurement of these, how do you install them, how do you run them, operate them," Mohammed says. Where a country can buy from gets settled before any of that. Nuclear technology only crosses borders under a formal agreement between the two governments, and each supplier country requires its own. A buyer that has negotiated with one has no access to another's reactors until it negotiates again, which can take years. So the list of who can sell into a given market is shorter than the list of who builds reactors, and the most advanced design in the world may not be the one on offer. Staffing is another open piece. Running a reactor takes licensed operators , and in early projects those people usually arrive with the technology instead of being hired locally, which makes staffing part of what a developer buys. Waste is a third. Until there's a clear process for disposing of it, no private developer can treat a reactor the way it treats a generator or a chiller. Ontario shows how long the sequence runs once the rules are settled, with a reactor under construction at Darlington after years of regulatory work before any concrete was poured. "They have to talk more often, they have to dedicate the budgets and they have to streamline the process in terms of governance and regulations," Mohammed adds. Governments have their own reasons to move slowly. A private reactor changes who controls generation inside a country's borders, which raises questions about energy security that a gas turbine never does. The rule with the clearest effect on the economics is what happens to leftover power, because a site producing more than it uses needs an agreement with the utility about selling the surplus back, and those terms decide whether building your own supply is an expense or a source of income. Utilities want in A data center that makes its own power stops being a customer. Large industrial sites are among the most valuable accounts a utility has, and losing several of them takes revenue off the books. Mohammed expects utilities to want a stake in the reactors instead of watching the business go. "If these power companies are worried about the revenue that comes with the power connection and the grid, they may want to be part of the SMRs because they might lose customers from grid consumption to the SMR," Mohammed says. The pattern shows up in how projects get planned, with a rising share of new facilities including some form of onsite generation . The same math works elsewhere. A development with a hotel, a mall, and a few residential towers draws enough steady load to justify its own reactor, and it can sell the surplus back on the same terms. The grid these sites would be leaving is under more strain than it used to be. Summers have gotten hotter across the Gulf and Europe, and a house that runs air conditioning can use roughly twice the electricity of one that doesn't. Every one of those homes draws from the same supply the data centers are waiting on.

## Tokenized Finance Turns Data Quality Into A Real-Time Systemic Risk Control
URL: https://www.thedatawire.com/news/stablecoins-tokenization-data-architecture-trust-grace-wu
Published: 2026-09-08T17:57:33.031Z
Section: Future of Data Management
Summary: Grace Wu, former Head of Product and Account Data Asset at HSBC, explains why stablecoins and tokenized assets are forcing financial institutions to redesign enterprise data architecture around real-time trust, governance, and accountability.
Full text:
Financial infrastructure is shifting from batch settlement and paper-based ownership records into continuous transaction networks where every asset creates live data at the moment of exchange . Tokenized real-world assets led by Treasuries and tokenized funds, with private credit, commodities, and a still-tiny real estate segment behind them have reached roughly $38 billion on-chain, up from about $14 billion at the start of 2026. Stablecoin supply tells a subtler story: it crossed $300 billion , peaked at $322 billion in May, then contracted for the first time in four years to around $303 billion, even as June settlement volume hit a record $1.79 trillion. Fewer dollars are circulating faster and more often. Hong Kong granted its first two stablecoin issuer licenses on April 10 to HSBC and to Anchorpoint, a joint venture backed by Standard Chartered Hong Kong, HKT, and Animoca Brands, and regulators elsewhere are at four different stages of maturity. Japan already licenses fiat-backed stablecoins under its amended Payment Services Act. Singapore's MAS finalized its framework in 2023, with implementing legislation expected around mid-2026. The UK is still in draft: the Bank of England's Code of Practice for systemic issuers is out for consultation until September 22, carrying a temporary per-issuer holding cap and a short-term gilt reserve floor. The US enacted the GENIUS Act in July 2025 but is mid-rulemaking, with enforcement due no later than January 2027. The data architecture underneath most financial institutions was not designed for any of this. Grace Wu is a global data and AI transformation leader with over 15 years in financial services, including 11.5 years of progressive international experience at HSBC across investment banking, global markets, securities services, and wholesale banking. She most recently led the design and development of HSBC's global product and account data assets and previously built the bank's master data management and governance framework. She is currently a PhD candidate researching emerging technology and AI. "We're moving from paper-based systems to a new collection of data points," Wu says. "We need to document ownership, valuation, legal status, risk profile, transaction history. Data quality used to be treated as a back-office problem. Because everything is moving into real-time environments, it becomes a systematic risk." AI becomes the compliance engine When a cross-border payment settles in seconds rather than days, every compliance decision that used to happen across multiple review cycles has to happen within that same window. That work now falls to AI, which prices assets in real time , monitors KYC and money laundering signals, and clears tokenized transactions across jurisdictions. "In the past we used the SWIFT mechanism," Wu says. "In the future, that will be stablecoins in real time. AI becomes the compliance engine for the tokenized economy." The speed creates a new kind of consequence. "When you execute a transaction within a second, all the decision-making has to happen in that second. If it's wrong, the consequences are immediate. Once someone receives the money, it's too late." That pressure moves governance toward real-time , policy-as-code models. Governance is the bottleneck, not infrastructure Wu frames trust in three layers: building it, running it, and defending it. Building trust means proving reserves and tracing every dollar end to end through independent audit. Running trust means ensuring that data, AI operations, and product teams have clear accountability when something breaks. Defending trust means writing resolution playbooks and incident management processes before incidents happen rather than responding after the fact. "In the past, we ran weekly, quarterly, monthly governance forums," Wu says. "That is not sufficient anymore. We have to do real-time governance with policies coded into the architecture." The organizational model matters as much as the technical one. Many institutions still run data, AI, and digital assets as separate functions. Wu argues that all three need to operate as a unified function at the enterprise level with shared ownership and accountability. Optimize the pipeline instead of buying new infrastructure Wu warns against treating tokenized assets as a standalone project that justifies new data centers and GPU purchases. The compute demands of real-time AI compliance are real, but the answer is optimizing existing workloads. "If the client onboarding team won't use computing power overnight, we can shift that capacity to other AI use cases like cross-border data transfer," Wu says. That infrastructure orchestration is now core engineering work. "GPUs are super expensive, and the demand for AI computing power is huge," Wu says. "Not every use case runs in parallel at the same time. How we best manage the pipeline to fully utilize what we've bought and support the enterprise in the most effective way is now one of the top agenda items." The reallocation argument has a limit. Real-time compliance is latency-critical, so that capacity cannot be borrowed. The pool that can float is everything else: model training, back-testing, reconciliation, batch analytics. "You ring-fence what has to answer in a second," Wu says, "and you treat the rest as a shared pool."

## The Agentic Enterprise Needs Credentials and Kill Switches Before Software Starts Acting On Live Data
URL: https://www.thedatawire.com/news/peter-corless-redpanda-agentic-data-plane-security
Published: 2026-09-08T17:52:23.465Z
Section: AI
Summary: Peter Corless, Principal Product Marketing Manager at Redpanda, says agents need tightly scoped access and audit trails they can’t alter.
Full text:
Enterprise data pipelines were built to end at a person. Records moved from source systems into a warehouse, a dashboard refreshed, and an analyst decided what to do about the number on screen. Agents now occupy that endpoint, approving payments, rerouting logistics, and querying production systems at machine speed . The access controls and audit practices governing those pipelines assumed a human behind every query, and enterprises connecting agents to live operational data are working through what both should look like when the requester is software. Peter Corless , Principal Product Marketing Manager at Redpanda , covers AI policy, governance, and regulation for the streaming data company's agentic data plane. He previously served as Director of Product Marketing at StarTree, where his focus was real-time analytics for data-driven enterprises. Today, his work centers on the identity, access, and audit controls enterprises apply to agents running against live systems. "We want to give agents just enough access to do their job, but not too much access, and certainly not to the same degree as the human," says Corless. Redpanda has been building an internal methodology for managing agents, and Corless starts it at the sizing of permissions. He places that decision alongside credential separation and guardrails among the conditions he considers necessary for security in agentic systems. The credential problem comes first Corless measures agent rollout in headcount. A company standing up a thousand agents faces a thousand onboardings, each one requiring its own decisions about what that agent may see and do. "The agents are kind of a new workforce," he explains. "Human resources type policies and procedures aren't going to work for agents. There's a lot of non-predictiveness, the kinds of things you would never expect from an employee you can get out of an agent." The model he recommends starts with the credential itself. "The agent should be working on behalf of a human," Corless notes. "They're not just running like a service account. They're tied back to some human user who ultimately made the request for this kind of information or data." Enterprises are treating agent identity as an unsolved problem. The link between an agent and the person who requested the work is what makes narrowing possible, because a credential attached to one person can be measured against one job. Corless puts the choice in terms a data team would recognize, and the answer moves with the task in front of the agent. "This allows you to scope down to the least privileged access what the agent might need to do," he adds. "Does it need read-write privileges to the gold table, or should it have read-only privileges because you're just running an analysis?" Credential separation also changes what a security team can establish after the fact. Attribution depends on the credential that carried the action, and Corless keeps the two populations apart so that a review can tell them apart without guesswork. "Because of disambiguation, you want to be able to tell what actions the agent took as opposed to a human," he says. "There are nefarious human behaviors that are going on inside of a system, but you want to be able to segregate that from an agent that's just coloring outside the lines." Setting the proper guardrails Scoping settles what an agent may reach , and a second set of controls settles what leaves the system in the answer. The same query needs a different response depending on who receives it, because a record that suits one requester can be inappropriate for the next. "A good guardrail system isn't just keeping an agent from doing nefarious activities," Corless explains. "Even with the read only that it has, you also want to make sure that it has masking of that data, like a kind of a redaction, so the data you get back is not untoward data to hand back to a public user. Maybe you need to provide an aggregate rather than individual transactional sums." Corless locates the weak point in where many deployments keep their own records. An agent running locally writes its transcripts and holds its guardrail configuration on the machine it operates, which gives the process being audited write access to the audit. "A nefarious agent would be able to delete any transcripts so it could clean up any sort of untoward activities it took," he points out. "It could potentially change data, exfiltrate data, and then hide any evidence that it did." The architecture Corless describes moves policy enforcement and audit logging out of band , into infrastructure that neither the agent nor its operator can write to. The second half of that arrangement concerns permissions on the policy itself. "The humans who may be able to pilot an agent would not necessarily be the people that are putting down the guardrails for those agents," Corless notes. "There could be a higher level of privilege or security of who can change those guardrails." Kill switches and immutable logs The same organization runs two requirements that work against each other. Corless describes people who are all gas and no brakes, opening one new tool after another , while the enterprise around them carries conservative requirements and executives with no appetite for becoming a public example. "They're inundated, they're drowning in agents, but they're all being brought in as shadow AI," Corless observes. "If you think about a governor in a car or in an engine, a governor allows things to move as fast as they could without being dangerous. The enterprise needs to set what progress looks like and make sure that we're moving fast but no faster than that." Guardrails shape behavior while an agent runs, and Corless wants a separate control that ends the run. He argues for a list of operations agreed on in advance, so that spotting one in progress is enough to trigger the stop. "There are certain processes that I might be taking that you need to have corporate kill switches about," says Corless. "It's deleting prod, shut it down." Immutable logs cover what the guardrails miss, and Corless plans for that gap as a given. Reconstructing an incident depends on a record the agent couldn't have edited while producing it, and Corless treats the handling of that record as a procurement question. "Audit trails are going to be critical, so look for vendors that are committed to these kinds of safety mechanisms and are looking to do this with open standards," he concludes.

## Data Intelligence Depends On Capturing The Knowledge Analysts Already Carry
URL: https://www.thedatawire.com/news/robert-alvarez-everpure-enterprise-ai-data-strategy
Published: 2026-09-02T11:27:53.428Z
Section: AI
Summary: Robert Alvarez, Principal AI Solutions Architect at Everpure, argues that enterprises need documented context, a data intelligence layer, and sensitivity-based model routing before scaling AI.
Full text:
Enterprise AI programs get budgeted around data access . Teams inventory the systems they have, connect a model to them, and wait for the outcomes to arrive. What often gets overlooked is the knowledge held by the people who have run those systems for years. Enterprises scaling past their first pilots are finding that the volume of data on hand predicts very little about what they can build with it. Robert Alvarez, PhD , is a Principal AI Solutions Architect at Everpure , where he designs AI systems for enterprise customers. He previously led AI projects at NASA's Frontier Development Lab, developing computer vision models for radiation detection, and built data science curricula at universities and bootcamps. Today, his work centers on what an organization has to capture about its own operations before a model can use its data well. "It's not just about having a little bit of data that you use for AI, but leveraging all the data as long as it's context-aware. You need that context for it to be useful, otherwise you're just going to get gibberish out," says Alvarez. He treats the missing context as a documentation problem. A model with access to every system in the company still has no way to tell which one answers the question. Recording tribal knowledge For Alvarez, context is the reasoning behind a choice of data . "You've got business analysts that know exactly what table to query for some specific function, even though there are three other tables that look like they have the exact same data, but they can tell you why it's that one and not the other two," he says. He points to project documentation as the place that knowledge can live, under a reading pattern that has changed completely. A document written for the new pattern has to carry what a human reader would once have inferred, because anything left implicit never reaches the model. "An engineer would read that maybe once or a few times while they were starting up, but then they got a sense of it," Alvarez notes. "You've got to remember that now for AI, that doc is being read every single time AI does a query." A document read that often can't remain a one-time deliverable. Alvarez describes a standing artifact, revised whenever a team or agents learn something worth keeping. A spec written once and closed leaves the model working from the business as it looked on the day it was written. "Whenever you're going to do any analysis, read this doc first," he says. "This doc is going to be a running version of that team's knowledge or that organization's knowledge." Design backward from the outcome A team can agree a running document is worth building and still not know what belongs in it. Alvarez answers that from his background in education, where a teacher who builds the course before writing the exam finds the gap only after the material has been taught. "The way I think about it is backward design for curriculum," he explains. "It's basically start with the test, and then go back to the syllabus, and then build the curriculum." Applied to AI work, the exam is the spec document and the build is everything a team assembles to satisfy it. Alvarez wants the sequence proven on one project first. "Before you start having AI build, spend a sprint with your engineering team designing all of the features that you want out of that project and writing them down in a doc," says Alvarez. "From there you can figure out how you scale that out to many more projects running in parallel, but small bites at first." Sensitivity decides the route Alvarez treats the specification as one half of the problem and the location of the model as the other. An enterprise operating its own data center still sends requests outward unless something inspects them first. "If you've got very sensitive data and you're making a request to do some analysis on it with AI, you need to have an on-prem model that you trust and can route that to it," says Alvarez. Routing depends on open models being close enough in capability to take the work, and Alvarez puts the remaining distance below what most people assume. Cost enters the same decision, since a large share of enterprise requests don't need frontier-scale inference to answer well. "Your inference stack as enterprises grow and AI matures is going to be leveraging this hybrid of both frontier models and open models," he notes. "I don't think people are going to be fine-tuning models the way they were a year and a half ago. Models are much more capable now that they just need the right context, the right data and a good prompt." Owning the intelligence layer A model that needs the right data depends on someone knowing the data is there. Access frequency counts too, since a table queried constantly signals where a model should look first. "The team or the person building the functionality and AI may not have known about that data," Alvarez says. "But being able to have an MCP server or some sort of integration with an enterprise data intelligence layer allows you to find the data that you need, using role-based access control, so that those AI initiatives have a lot more weight and a lot more context." Asked where accountability for the intelligence layer belongs, Alvarez names the security dimension first, which pulls the CIO and CISO in before the data organization takes it on. "The Chief Data Officer and an AI VP are kind of the two tag teams," he says. "The VP of AI helps with the infrastructure and building of that knowledge base using LLMs, but the Chief Data Officer surfaces all the data they need for each of those organizations." Siloed data limits what any layer above it can return. An intelligence layer can only index the systems it can reach. "Unify your data silos, get an intelligence layer, and then have that additional context from your subject matter expertise, because they're the ones who understand the business, not the AI," Alvarez concludes.

## Data Governance Assets Become The Context Layer For Enterprise AI Agents
URL: https://www.thedatawire.com/news/trideep-patra-apex-ai-data-governance-strategy
Published: 2026-08-31T14:21:07.291Z
Section: AI
Summary: Trideep Patra, Chief Technology and Transformation Officer at Apex Technology Systems, argues that agents need lineage, classification, and policy as code before they touch enterprise data.
Full text:
Enterprise data governance has produced a large body of documentation. Active metadata, data classifications, and lineage records were built to document controls and standardize definitions across systems. An agent querying that same data has no colleague to ask and no memory of how the business works, leaving those records as the only description of what the data means. Enterprises deploying agents against governed data are now finding a second use for artifacts they built for compliance. Trideep Patra is Chief Technology and Transformation Officer at Apex Technology Systems , where his work covers cloud data management, AI governance, and total cost of ownership advisory for financial and insurance clients. He previously ran global data management at Everest Insurance, leading an Azure migration and a centralized master reference data platform, and previously set enterprise data strategy at AmeriHealth Caritas. He is also the author of Governing the Autonomous Frontier , a reference guide to autonomous data governance. "A lot of people are talking about AI governance , which reduces cost and risk. That has to be done, but in order for AI to be adopted, the first thing is the raw input, which is data, and that has to be organized," says Patra. He spent three decades on the IT and data side before turning to how agents should be introduced to it. Patra puts the readiness question ahead of the build question, and his answer points at material most enterprises already own. Governance output, agent input Patra points to the output of two decades of governance programs as the material an agent needs. Those programs ran on a schedule set by auditors, and the engineers building systems had faster ways to get the same answers. "By the process of governance, we have created a lot of data dictionaries, business glossaries, taxonomies, so many things," says Patra. "But go and ask any technologist how many times they have gone back and referred to that reference data , that master data, that business taxonomy." He sees the same omission repeating with agents. Most large enterprises already hold the artifacts, which makes this a question of exposing what exists to a machine reader. "People are trying to build the agent without understanding how it should be organized, how the business contextual organization of the data should be," Patra notes. "And to do that, the first thing that you need is the governance." Lineage before the first decision Patra's model for how an agent should investigate a problem comes from production support. The path runs the same way every time, and it depends on a record of which system fed which. "If a production ticket has been raised, we are assigning it to a production support person," says Patra. "They go by the lineage one step at a time and understand what is really causing the particular issue. Similarly, the agent has to also function." The lineage record has to be in place before the agent starts. Older estates make it harder to assemble, since a mainframe pipeline can carry two decades of accumulated transformations . "Before AI starts working, it has to understand the lineage," Patra explains. "Where should I look for the data? What code or transformation are you currently applying? Before AI takes a decision, it has to be provided the whole lineage harvesting as an input." Lineage tells an agent where a value came from, classification tells it what the value is, and policy expressed as code tells it what to do about it. "On the basis of the Social Security number, I see the policy as a code, the Rego code, is like this," says Patra. "On the basis of that I am going to stop, or I am going to mask the data. First is the identification. Second is what the policy is talking about. And depending on the policy, what kind of action the agent has to take." Humans make the call Patra separates the work an agent does from the accountability for it. An agent produces code, analysis, and recommendations, and a named person stays answerable for what ships. "An agent is your peer, your worker whom you are asking to do some work," says Patra. "Once they deliver some work, you are the one who is going to be responsible. An agent cannot be responsible for whatever output it gives." He applies that split to data asset certification, where the agent assembles the evidence and a steward makes the call. Patra puts the difference in hours. "If a person will be given all these tasks, it will take him at least three days of work," he says. "But with all this information, the agent can do it in 30 minutes." The operating unit Patra describes puts those roles together by domain, with a data engineer, a steward, a business product owner, and a member of the security team working alongside the agent. A customer-domain squad draws different people than a claims or corporate finance squad, and Patra notes that data and security organizations typically run on separate objectives. "It is not about only the agents solving the problem, or the human, or the data engineer and the data steward," he concludes. "It is all about how they all work collaboratively to address a specific issue."

## Why Capital Markets Firms Are Rethinking Data Infrastructure for Production AI
URL: https://www.thedatawire.com/news/mike-russo-everpure-financial-data-orchestration-ai
Published: 2026-08-28T08:56:43.031Z
Section: Future of Data Management
Summary: Everpure's Mike Russo and Richard Galvez on the orchestration, governance, and resilience gaps that separate AI experimentation from production in capital markets.
Full text:
Capital markets firms are not short on data. They have tick data, time series, structured trade records, PDFs, spreadsheets, sentiment feeds, and growing volumes of unstructured research content. The problem is turning that data into AI systems that can operate reliably at production scale. A model may work in a pilot. Users may see value. But moving from experimentation and training into production inference introduces demands that a pilot was never designed to test. The question facing firms now is not simply whether they can build an AI use case. It is whether they can operationalize it . Mike Russo is General Manager of Financial Services at Everpure , with experience spanning capital markets, banking, quant trading, cloud, and operational resilience. Richard Galvez is Everpure's Director of Applied AI and Field Solutions Architect. He holds a PhD in computational physics and focuses on scaling AI systems into production. "The bottleneck is no longer collecting the data," says Russo. "It’s turning that massive amount of data into usable insight and getting things to go from testing and training into production, inference, and revenue-generating outcomes." The magnifying glass effect Russo says AI has changed how capital markets firms evaluate their data infrastructure. “AI has made a huge difference. It’s really put things under the magnifying glass on the data side. What does our data look like? Is that data clean? Is it ready?” That scrutiny becomes more important as firms move beyond experimentation. Galvez says firms can suddenly encounter capacity constraints, higher data-movement requirements , and costs that were difficult to see at pilot scale. Firms that invested heavily in GPU capacity are now confronting that distinction. Compute may get a model trained, but it does not by itself create a production-ready AI environment. As Russo puts it, firms are increasingly asking: “How do we go from training to inference?” Data complexity grows with the use case Structured trade data remains foundational, but AI increasingly draws on PDFs, spreadsheets, research content, sentiment feeds, and other unstructured sources. That changes the governance challenge . Firms need to know what data is being used, where it came from, who can access it, and whether it is appropriate for model training or production use. Russo points to a common problem: teams copy production data into non-production environments for model training, only to discover later that some of that data was never cleared for the intended use. Sensitive information may need to be tagged, certain datasets may be restricted by geography, and access controls have to follow the data as it moves between environments. The issue is no longer simply making data available. It is making the right data available under the right conditions. Production introduces a different operating challenge Moving from a successful pilot to production changes the operating environment, and the accompanying pressures also expose friction between teams and tools. Russo says every handoff adds time and complexity. “Every time you have to pass an item from one team to another, from one tool to another, that introduces time and complexity.” Firms need repeatable processes for moving data into production environments without recreating those handoffs for every new use case. That's where orchestration becomes part of the production equation. “You can have all the data you want, clean and structured,” Russo says. “But if you don’t have the correct processes making sure it’s getting to your models fast enough, and making sure the data being used is actually cleared for training, it doesn’t get you very far.” AI resilience becomes part of production readiness As AI moves into production workflows, resilience is no longer only about recovering systems after an outage or cyberattack. Firms also have to consider what happens when an AI system behaves unpredictably or is given the ability to interact with production systems. Galvez uses the term “AI resilience” to describe part of this challenge. Because AI systems can be less deterministic than traditional applications, he says firms need guardrails around what models and agents are allowed to do. That means limiting permissions, narrowing their scope, and designing for the possibility that a system can be highly capable in one situation and unexpectedly unreliable in another. Observability and traceability become part of that resilience strategy. Galvez says firms need enough visibility to understand how an AI system is performing, reconstruct what happened when something goes wrong, and determine whether it is still operating within acceptable boundaries. “What does ‘it works’ mean?” he asks. Firms need to evaluate whether a system is actually better, faster, less expensive, or more effective than the process it's replacing. The readiness gap widens Russo frames the competitive challenge in terms of velocity. “What’s one step behind today is three steps behind tomorrow and ten steps behind next week.” As more firms move AI from experimentation into production workflows, the gap will increasingly be defined by how quickly they can repeat that transition across new use cases. Galvez says simplicity matters because complexity that seems manageable during a pilot becomes harder to control as systems scale. Firms that design for repeatability early are better positioned to expand successful AI use cases without recreating the same operational friction each time. For capital markets firms , the advantage will not come from running the most AI experiments. It will come from building an environment where a successful experiment can become a reliable production system, and where the next one does not require starting over.

## Kubernetes Becomes The Enterprise Standard As Storage Catches Up To AI Demand
URL: https://www.thedatawire.com/news/kubernetes-storage-bottleneck-greg-muscarella-portworx-everpure
Published: 2026-08-26T17:58:54.359Z
Section: Future of Data Management
Summary: Greg Muscarella, GM of Portworx at Everpure, explains why storage, not compute or networking, is the constraint holding enterprises back as Kubernetes absorbs virtualized, containerized, and AI workloads onto a single platform.
Full text:
Kubernetes is absorbing workloads from every direction. Virtual machines once locked into legacy hypervisors, containerized microservices, and an expanding wave of AI applications are all landing on the same platform. Compute orchestration and networking have kept pace with that convergence. Storage has not. Greg Muscarella is GM of Portworx , Everpure's cloud-native storage business unit. A career product and general management executive with stints leading business units at Nutanix, SUSE's Rancher, Veritas, and Symantec, Muscarella brings deep technical experience across Kubernetes, virtualization, and enterprise infrastructure. He frames storage as the defining constraint in whether enterprises can actually deliver on the promise of a unified platform. "Organizations are growing and expanding both their virtualized workloads and, increasingly, their containerized workloads. They want a unified platform , at least a single platform that they can use to run both of these. AI workloads are one of the big ones that are really causing a lot of demand to increase on the containerized side as well," says Muscarella. Data carries weight that compute and networking do not The convergence is accelerating. Kubernetes production use hit 82% in 2025 according to CNCF's annual survey, and the platform now handles virtual machines alongside containers as enterprises push to consolidate onto a single infrastructure layer . But while compute and networking translate well to Kubernetes, storage carries inherent friction. Muscarella uses a simple analogy to explain why. "As anyone who's wanted to download a movie from Netflix before their flight knows, it takes too long," he says. "Compute things basically run everywhere. But that mass of data has what makes the challenge a lot more difficult to address." Volumes get trapped on specific arrays, capacity runs out and requires manual intervention, and IOPS overloads force administrators to rebalance workloads by hand . Portworx abstracts that layer, automating volume expansion, workload migration, and performance balancing natively within Kubernetes and platforms like Red Hat OpenShift. AI agents are multiplying the data problem AI is compounding the pressure. Muscarella breaks the storage challenge into three parts: training, which most enterprises skip beyond some fine-tuning; inference, which creates its own demands at scale; and context retrieval, which he identifies as the overlooked driver. "To get real value out of your AI application, it has to have access to your emails, your Slack messages, your PowerPoints, your Google Sheets," Muscarella says. Every agent query requires finding, indexing, and ingesting scattered data, whether it is a transcript, a chat log, or a product manual. That indexing layer creates an architecture challenge that sits upstream of inference and exposes how fragmented enterprise data remains. And the consumption is growing fast. "Your usage of data is going to look minimal compared to what your several agents running in the background are going to be using," Muscarella says. "The load is going up exponentially." The cultural shift matters as much as the technical one Beyond storage, Muscarella points to a cultural challenge that determines whether enterprises capture the operational gains Kubernetes offers. Legacy virtualization grew up around what he calls "click ops," where administrators name, monitor, and manually update individual VMs through a GUI. That approach produces a low administrator-to-machine ratio. Kubernetes inverts the model, managing workloads en masse by policy. "I may have 1,000. I change a single configuration, and it applies," he says. "My concern is that people try to bring the old style of one-by-one management over with their virtual machines into the Kubernetes realm." Organizations that make the shift report significant efficiency gains. Those who resist end up running a modern platform with legacy habits. The migration itself is still maturing. Muscarella estimates 80% of VM workloads move without significant issues, but the remaining edge cases, legacy Windows workloads, old drivers, application data format conversions, expose the fact that Kubernetes was not originally built for virtual machines. That maturation is ongoing, even as AI infrastructure investment surges and data center power consumption doubles under the weight of new demand. Success, in Muscarella's framing, comes down to three things: uptime and performance as table stakes, portability between on-prem and cloud without significant rework, and the capacity to absorb new workloads as AI-driven infrastructure demands scale. "Computers and applications are tremendously powerful, and now that we're able to write software faster, we want more of it, and we're using more of it," Muscarella says. "Performance, reliability, uptime, and then scaling out to handle more applications or more usage of those applications."

## Smart Building Growth Pushes Tech Leaders To Separate Sensor Traffic From Business-Critical Systems
URL: https://www.thedatawire.com/news/smart-buildings-private-5g-network-peter-wilson-fujitsu
Published: 2026-08-24T04:50:29.173Z
Section: Leadership
Summary: Peter Wilson, Chief Technology Architect at Fujitsu, shares why sensor data pays off only when it answers a cost, space, or productivity decision the business already faces.
Full text:
The modern workplace is filled with connected devices . Occupancy sensors, environmental controls, desk monitors, and building management systems now report into the network, and each smart-building upgrade adds to what is becoming a sensor estate in its own right. Each device draws little on its own, but together they take enough bandwidth to slow the business systems employees rely on. Those devices were often installed one project at a time, and few organizations decided in advance which network the sensor traffic should run on or what the readings would be used for. Peter Wilson is Chief Technology Architect at Fujitsu , where he is the senior technical authority on a large public sector account and works directly with the client's CTO. He is a Fellow of the British Computer Society, a Chartered IT Professional, and a TOGAF-certified architect. His career has run through major transformation programs across UK government, and his work now covers technical strategy, innovation, and mentoring the technologists on his team. "You're seeing the smart building take off, and a lot of that is driven by sensors and other devices that need connecting into the network but have the potential to consume significant bandwidth. The value of 5G is being able to separate those devices so the important networks people use for their day-to-day work do not suffer under that load," says Wilson. The dedicated channel he describes is private 5G , kept clear of the corporate network that carries email, applications, and calls. Wilson wants technology leaders to make that split early, while the number of connected devices is still small enough to plan around. The devices themselves are already doing more than a network diagram would suggest. Presence, not just booking Occupancy sensing already does more in most buildings than the people working in them notice. "Many organizations are managing their shared meeting rooms not just by how you book them but by what the presence is in those rooms. Is it booked, are there people in there, how many people are we detecting? Is it an appropriate use for the right size of office, or is it just somebody camping out doing calls?" Wilson says. Desks and shared equipment carry the same kind of sensing, and it joins the building management data on power use, temperature, and cooling that facilities teams already collect. Facilities teams put that building management data to work on energy consumption first. Heating, cooling, and lighting often run on schedules set long before anyone had occupancy data, so a building spends money conditioning empty rooms. Sensor coverage replaces that schedule with a record of use, and it gives property teams the same record for space by showing which floors fill up and which stay half empty through the week. Wilson attaches a limit to the savings available. "You're always going to want to reduce costs in terms of your building management, within the boundary of the regulatory aspects about the range of temperature that building should be for human use." Data with a purpose A sensor estate produces far more data than most teams have questions for, and Wilson begins with the decision a team needs to make before looking at what the sensors report. "There is a massive data opportunity to understand and optimize the use of space and the productivity of the humans working in it. Having a really good view of the cost base, the data points being collected, and how those data points support your understanding of that cost base is pretty important," Wilson notes. Tuning the building Occupancy and environmental readings also support finer decisions about how the space runs day to day. "The more information you have about the way people use the space, what time they come in, how that relates to the time of year, and what rooms they're using, the more you can optimize the environment in all those spaces and, in theory, the utility bill side of things," Wilson explains. Heating, lighting, and space each improve on their own once a team can see how they are used. Pulling all three into one model of the building is the larger step, and that model has a name and a history outside the office. Manufacturers built the first digital twins around a large machine or a ship's engine. Sensors tracked the condition of the equipment against the readings a healthy unit produces, which let engineers predict failures early enough to service it before it stopped. Wilson applies the same construction to any environment worth understanding. "It's about being able to model the environment that you're interested in and then understand what the behavioral cues are," he notes. "What does normal operation look like, and what are the parameters for that?" The digital twin A workplace introduces far more variables than a ship's engine, though the construction carries over. "A digital twin models the environment and captures the behavior taking place within it. In an office, that means understanding where people congregate, which entrances and exits they use, and how different areas should be heated and lit based on actual use," Wilson explains. The model is only as detailed as the sensor coverage behind it, which brings the question back to device density and the network that carries it. Wilson points to public sector organizations running facilities for their staff, transport organizations operating stations, and water companies managing sewage and drainage networks. The water industry is where he first saw the case for private 5G, with sensor technology monitoring leaks and flood warnings across infrastructure spread over a wide area. Each of those organizations runs a physical operation at a cost, with people moving through it and equipment that has to keep working. "Any organization that has to manage resources of a human and non-human nature is going to get some value out of understanding how those resources interact with each other and how they're used," Wilson concludes.

## An AI-Native Supply Chain Requires The Right Foundation, Says One Volkswagen Group Engineering Department Head
URL: https://www.thedatawire.com/news/ai-supply-chain-continuous-adaptation-praveen-mishra-volkswagen-group
Published: 2026-08-21T19:40:02.962Z
Section: AI
Summary: Volkswagen Group's Dr. Praveen Mishra on shifting supply chains from reactive recovery to continuous prediction, and the foundation of baselines, oversight, and data residency it requires.
Full text:
For decades, supply chain management has been built around the assumption that a disruption is an exception. Something breaks, the organization absorbs the shock, recovers, and returns to normal. That model is failing because the exception has become the condition. Companies now face multiple simultaneous disruptions rippling across suppliers, plants, logistics networks, and demand at once, and the old absorb-and-recover posture can't keep pace. AI offers a way to shift from reacting to disruption toward continuously sensing, predicting, and adapting ahead of it, but that shift only pays off if the underlying foundation , the baseline, the human oversight model, and the data architecture are built deliberately before the intelligence layer goes on top. Advocating for a different approach is Dr. Praveen Mishra , Senior Department Head of Engineering R&D at Volkswagen Group's India technology hub, who has more than a quarter-century of experience spanning automotive manufacturing, supply chain, and digital transformation, and a Doctorate in Business Administration. He recently authored a white paper on AI-native synchronized supply chains for automotive operations , which argues that the value of AI in the supply chain depends less on the sophistication of the models than on the discipline of the groundwork beneath them. "The mindset of recovering after a disruption should change to a mindset of continuously sensing, predicting, and adapting," Mishra says. That reframing is the starting point, and it changes what the supply chain is fundamentally designed to do. From one-off disruption to continuous adaptation The core problem Mishra identifies is that the traditional model treats every disruption as an isolated event. Whether it's a single supplier issue, a weather delay, or a transportation problem, it's to be absorbed and recovered from individually. That framing, he asserts, no longer matches reality. "One of the biggest problems of supply chain is treating everything like a one-off disruption. That approach doesn't work anymore." The disruptions organizations face now are interconnected and simultaneous, and a problem in one area ripples across the entire chain . His proposed answer is a system that doesn't wait for the shock. Built on a real-time synchronization layer, digital twins, AI agents, and a reinforcement learning loop, it continuously monitors events, tests scenarios, and evaluates alternatives before a problem materializes. The goal is a supply chain that recommends actions in advance rather than scrambling to recover after the fact, turning raw operational signals into usable data intelligence the business can act on early. Measure before you model The discipline Mishra is most emphatic about is establishing a baseline before promising any AI-driven savings, a lesson he's learned the hard way. "One of the biggest mistakes is approving AI projects based on forecasts. Even I have made mistakes on this, and I've learned with time and experience that is not the best way." The reason is that without an established baseline, there's nothing legitimate to measure the result against. His alternative is to instrument the operation first. Before launching a program, he collects months of data across concrete operational metrics: production downtime, inventory levels, logistics cost per vehicle, equipment efficiency, on-time delivery, yard unloading and docking. Only once that data exists can a mature baseline be negotiated and a program's real benefit be proven afterward. "If anyone comes and asks me what benefit I've obtained, I have baseline data and a result I can compare. The principle is to measure before you model," he says. The point goes beyond technical rigor. Credibility hinges on it. A savings claim without a baseline is unfalsifiable, and the discipline of baselining is what lets a leader defend the investment when results come due. Keep the human in the loop where the stakes are high Mishra is direct about the limits of autonomy in an environment where a wrong call has physical, immediate consequences. His framing, which he's presented at industry leadership forums, is that AI is an intelligent advisor rather than a decision maker. "Absolutely, AI can help make decisions, but the moment it comes down to the final say that can have a significant operational risk or a financial risk, that's where the human has to be there ." The distinction becomes especially concrete in a manufacturing context. "We're talking about stopping a production line or rescheduling production, switching a carrier, or changing a delivery commitment. In these cases I would recommend human in the loop," he notes. The division of labor is deliberate. Routine, low-risk tasks that sit within predefined rules are exactly where AI should operate freely, because there it delivers speed and efficiency without introducing meaningful risk. AI's genuine strengths, like analyzing vast data, simulating many scenarios quickly, and recommending strong options, are best pointed at those decisions, while the consequential calls stay with people. Design data residency from day one The point Mishra frames as most fundamental, and most often underestimated in global manufacturing, is where data can legally live and how it can move . "One thing that must be decided very early on is the data architecture and data residency," Mishra advises. Building the integrations, pipelines, models, and dashboards first, then discovering a regional or sovereignty constraint later, is where projects unravel. The stakes are specific to global operations. Different regions carry different homologation, sovereignty, privacy, and compliance requirements, which means the data itself is governed differently depending on where it originates and where it flows. Mishra wants those questions answered before anything is built: what can leave the plant, what must stay in the country, what can stay within a region, what can be centralized. "The data-residency-first approach is very important, because then I'm able to pin the data to regional architecture," Mishra says. Reverse that order and the cost of adaptation and migration becomes so high it can unwind the entire strategy. This isn't theoretical for a global OEM. Mishra notes that his organization operates geographically defined cloud tenants across regions, with clear rules about which data belongs to which region, precisely because the data governance has to hold across Europe, China, India, and beyond. The payoff, honestly scoped Mishra is careful not to oversell the returns of his proposed approach, which itself reflects the measure-before-you-model discipline. Rather than promising dramatic figures, he scopes the benefit realistically. "If it's properly deployed, I'm seeing efficiency gains of 15 to 27%," he shares, noting that the upper end reflects gains compounding over the next few years as more of the architecture matures. He says the number isn't higher because many of those efficiencies have already begun to be realized, so the projection reflects genuine incremental gain rather than headline inflation. The through-line of Mishra's argument is that the intelligence layer is the easy part. What determines whether an AI-native supply chain actually delivers is the unglamorous groundwork beneath it: a real baseline to measure against, a clear line between what AI advises and what humans decide, and a data architecture that respects where information is allowed to live. Get that foundation right, and the shift from reacting to disruption toward anticipating it becomes durable rather than aspirational. The supply chain that continuously senses, predicts, and adapts is within reach, but only for the organizations disciplined enough to build the foundation first.

## As The AI Model Becomes A Commodity, Enterprise Data Becomes The Moat
URL: https://www.thedatawire.com/news/enterprise-ai-data-governance-sovereignty-jayashankar-attupurathu-cloudifyops
Published: 2026-08-21T19:39:31.735Z
Section: Future of Data Management
Summary: Jayashankar Attupurathu, Technology Strategy Advisor to Boards and CXOs, on why the golden source, the pipeline, and sovereignty rules decide what a model can do.
Full text:
Companies buying AI now choose from the same handful of model providers, and few build their own. The difference between one AI program and another comes from the data underneath . Ownership of that data and control over how it moves through the business decide what any model can produce. Jayashankar Attupurathu is a Technology Strategy Advisor to Boards and CXOs. He has spent more than two decades in enterprise technology, working as a developer, an Enterprise Architect, and a head of engineering before moving into CTPO roles. The questions buyers bring him now start below the model. "Enterprises are focusing on who owns the data, where the golden source is, how the pipeline works, and who governs it," Attupurathu says. A golden source is the single copy of a record an organization treats as correct when its systems disagree. Deciding which copy earns that status, and who is allowed to change it, predates AI. The work stalls in most companies. Pressure on the pipeline The systems drawing budget now have no user interface. They handle what happens between a company's records and the model. "Two years back, people were investing in chatbots or replacing RPA with AI. Now enterprises are keen on the second layer, the data pipelines, vector stores, orchestration frameworks, and observability tools. Even the board is asking how you govern this and how you find the ROI on AI," Attupurathu notes. A vector store holds documents in the numerical form a model can search, so its contents set the outer limit of what any answer can draw on. Observability tools capture what the model did and why, which is the record auditors ask for . Both now fall inside the scope of a compliance review. A company cannot always use the records it already has. Where the data lives can rule that out. "Data sovereignty has been there for ages. In financial services, countries have regulations in place that data cannot go outside their borders, and you cannot use our citizens' data in some other country," Attupurathu explains. Those rules are workable while data stays in one place. A model improves as it takes in more material, and the data with the most value is often the most restricted. That sends protected records toward wherever the model runs. Where those records travel becomes an architecture question, along with who operates the systems handling them. Both carry data sovereignty risk . Those decisions have to satisfy laws that are still being written. India's data protection rules took effect in November 2025, with full compliance required by May 2027. The EU continues to revise its framework, and health information in the United States remains under HIPAA. A business operating in all three markets answers to each at once, and the requirements keep diverging . Context outlives identifiers Organizations that run models on hardware they control keep every record in-house. Everyone else sends data to an outside service. "Some companies are anonymizing the data before pushing it into the model. That safeguards the PII, but the context is still there," Attupurathu says. A record with the name and account number removed still carries the balance, the transaction history, and the branch. Those details are often enough to identify a person. "If I push someone's bank balance, the amount in that account is still visible, and you never know how far the AI can go to connect it back," he adds. Any limit on what a model may read depends on an accurate inventory. Platforms that classify sensitive data across storage systems, clouds, and SaaS applications show teams which systems contain regulated records. Who owns the decision? Someone has to own the decision about what a model can read, and answer for it. At most organizations, no one does. It passes between the CIO, the data team, and legal, depending on the project. "If you have 10 departments, is that data aligned and mature enough to run into AI, and which of it is ethical to expose? What if you expose something and it creates insider trading? Those failsafes and gatekeeping methods have to be there," Attupurathu says. Ten departments mean 10 sets of records in different shapes. The consequences of exposing the wrong one reach the company and its officers, not the team that built the pipeline. "Why not have a committee for AI data? Get independent directors who have exposure to AI and bring them into the fold," he continues. Boards have started formalizing AI oversight , usually by adding it to existing risk or audit agendas and naming which directors are accountable. A dedicated committee would give the question its own members and a standing place on the calendar. Attupurathu expects the chief data officer title to widen into a chief data and ethics officer, with authority to rule specific datasets out of AI use entirely. The board sets the mandate, and that role enforces it request by request. All of that structure is internal. A customer deciding whether to hand over its data has no way to check any of it. "We have ESG certification, ISO, and SOC 2, which tell shareholders and the public that a company is ethical," Attupurathu says. Data handling has no equivalent that customers recognize. The closest standard, ISO/IEC 42001, covers how organizations manage AI systems , and certification remains voluntary, which leaves buyers nothing consistent to compare. Agents raise the stakes Companies once licensed a separate platform for each business function. Now they ask what an agent could do with the customer accounts and claims files those platforms were built to manage. Attupurathu expects ready-made agents, sold through marketplaces, to take over that work. One agent can work across all of those systems at once, which gives it reach no single application had. It also acts without a person checking each step. Teams that move agents into production inside processes designed for human review have found the gaps show up quickly. An agent bought off a marketplace comes with its own data requirements, so someone inside the business still has to approve what it can read. Investors set the clock on all of this. "There is an impatience about returns. They are looking at the dollar value they can get, without the long-term vision," Attupurathu notes. Spending on pipelines and controls pays back on a slower schedule, which is a hard case to make when budgets draw scrutiny . His advice for teams under that pressure is to spend where the differentiation actually is. "Do not create your own models. The models are all out there. Customize them for your needs, and then build something that creates something new in this world," he concludes.

## Data Intelligence Becomes The Dividing Line For Enterprise AI Maturity, Says One Of Cisco's Field CTOs
URL: https://www.thedatawire.com/news/data-intelligence-ai-maturity-sovereignty-bogdan-muraru-cisco
Published: 2026-08-20T12:17:58.823Z
Section: Future of Data Management
Summary: Bogdan Muraru, a Field CTO working with UK enterprises, argues that AI maturity now shows up in six-month business cases, sovereign data fabrics, and the unsolved problem of agent identity rather than in pilot counts.
Full text:
The views and opinions expressed are those of Bogdan Muraru and do not represent the official policy or position of any organization. The question that sorts enterprises on AI has stopped being whether they've adopted it. The sorting questions sound like audits now: where does the data live, on whose hardware, under which law, reachable by which agents? Answering them takes a data layer smart enough to know itself, and most infrastructure was never built for one. Bogdan Muraru is a Field CTO for UK enterprise at Cisco, advising large customers on technology strategy, cyber security, and operating models. He holds an NCSC-certified master's in advanced cyber security from King's College London and a second in systems thinking, after twenty years across engineering, architecture, and transformation. From his seat, AI demand has met the physics. "Everything they do with AI will not only amplify the business value they're looking for, but also amplify the burden on the infrastructure," Muraru says. "Most of the enterprises are not built for that." The six-month business case His clearest signal is how short plans have gotten. "Ten years ago there were five-year business cases. Then it was two, three years. Five years ago my VPs were saying 'If it's longer than two years, we're not going to talk about it,'" Muraru says. "Now nobody wants to talk about anything more than six months." He reads that compression as realism. "We might have made some money with it. What we can count on is the experience to scale out or reshuffle and stay relevant. You just need to be faster and much more flexible." The operating model has to absorb that pace. An agentic mesh that responds too slowly misses the window it was built to catch. What mature looks like from the field Mature organizations split the work. "You get at least two divisions. One is busy onboarding technology for production workloads, with value in the near term," he says. "And then an innovation team, folks able to build their own labs and hack something, without affecting anything in production." His fastest test is whether the company has established its own "front door" to AI. That could mean building an internal AI portal using proprietary or open-source models and agent-based tools, or providing governed access to leading frontier-model providers such as OpenAI’s ChatGPT or Anthropic’s Claude. "For most of the companies I work with, that is a clear maturity indicator," Muraru says. "It's not just the Copilot round. That's maybe the lowest one you can get these days." A company at that stage knows the difference between training a model and using one, worries about shadow AI, and protects intellectual property along with function. A value chain with no common language What's missing, in his view, is vocabulary. ITSM frameworks gave enterprises a shared process language, a way for the left hand to see the right. "For AI, the common language is not there yet. From acquiring data, cleaning data, training, getting tools to use the data, that common language is still missing," he says. "Right now the value chain is drawn in our heads more than anywhere else." The usual translators trail too. "Usually it's the consultants, but the consultants now are also a few steps behind, because everything is moving so fast." An ISO standard for AI management exists now, and EU cyber rules keep arriving, but he finds even large enterprises unsure how to digest them. Sovereignty goes all the way down The sharpest conversations run through sovereignty, and he insists they run the full stack. "Data fabrics are the way forward. Like we had cloud fabrics in the past, data fabric is what will rule," he says. "You have to understand how that data fabric brings you the intelligence that you need." Classification settles nothing alone. "It doesn't matter that I've classified data as strictly confidential, accessible only from London, if my data center is in Berlin." A clean design still inherits its vendors' geopolitics. "If somebody decides to unplug Microsoft, Google, or Alibaba, what does that mean for the sovereignty we've just designed?" He's watching conversations swing from cloud-first toward neoclouds and private AI, and he calls admitting you can't hold everything sovereign its own maturity sign. "If I'm building the next recipe for Cadbury chocolate in the UK, I'd better do it on a Cadbury server. And the same for Coca-Cola. They'd better do it in the States." The frontier he has no clean answer for is identity . "You have a workflow that spins off agents, and those agents spin off other agents. You only know what to start with," Muraru says. "What if a US agent reaches out to a UK agent that is connected with a French agent? Is that part of the sovereignty piece? Do we have a way to confirm identities and control these workflows? That's a very complex issue right now."

## Energy Companies Once Competed on Assets and Now Compete on Data Quality
URL: https://www.thedatawire.com/news/energy-trading-data-quality-compliance-arnab-ray
Published: 2026-08-20T12:17:58.823Z
Section: Future of Data Management
Summary: Arnab Ray, a Product Owner at Shell working in energy trading data, traces how two decades of market crises turned regulatory reporting into the data foundation that algorithmic trading and AI now run on.
Full text:
Every large energy trader is rebuilding its data plumbing at the same time, and the push didn't come from the AI teams. It came from regulators who got tired of watching crises unfold without the numbers to understand them. The surprise is what the compliance spend turned into: the clean, centralized, auditable data that algorithmic trading and AI were going to demand anyway. Arnab Ray is a Product Owner at Shell , leading the strategic delivery of counterparty lifecycle management applications and enterprise data products that enable secure, compliant, and efficient trading operations, and he spoke in a personal capacity about patterns he sees across the industry. He's spent 14 years in enterprise digital delivery across energy trading, data analytics, and IT operations, and the question that started his research was why every energy company seemed to be making the same data changes at once. "The foundation for AI is good data," Ray says. "For AI to deliver stronger outcomes, we need high-quality data that is accurate, complete, consistent, and trusted. Better data doesn't just improve AI, it builds confidence in every decision AI makes." Two crises wrote the rules The answer he found was regulatory, and it runs on a crisis cycle. Europe's REMIT framework for wholesale energy market integrity arrived in 2011, after the 2008 financial crisis exposed how little visibility regulators had into energy trading. A decade of relative calm ended with the 2021-22 gas shortage. "The regulators saw a huge gap in trading, the prices and the volume being traded," Ray says. "They did not have proper data to see what the demand in the market was, what was being supplied by each company, what the actual price was." The revised REMIT that took effect in May 2024 answers that gap by demanding better data, not just more of it, with reporting obligations that now reach storage and hydrogen. The American version, in his reading, traces to the California electricity crisis of 2000 and 2001, and points inward at market abuse rather than at cross-border trade. Different geography, same conclusion. Regulators want data good enough to reconstruct a crisis. Seventeen requests for one customer What that demand exposed inside energy companies was fragmentation. A large trader might run 20 different trading applications across regions and lines of business, each with its own version of the same customer. Ray felt the cost personally. “A few years ago, we faced a significant challenge. A single counterparty was engaging with multiple lines of business across three regions. Because counterparty data was not centralized, there was no enterprise-wide visibility into those interactions. As a result, different regional and business teams independently requested KYC documents before executing trades, with some counterparties being contacted as many as 17 times." The fix is master counterparty data, one verified record per customer mapped across every system and region, feeding a single source of truth. Sanctions turned that plumbing into a trading requirement. "When Russian companies were gradually sanctioned, how would we know that this particular counterparty I'm trading with is compliant to be traded? That data helps us to know." Standard tools, borrowed trust Regulators also standardized the industry by accident. Because every company must report the same fields, market-standard trading platforms built around those fields have displaced homegrown systems, and shared data structures do the trust-building. "My line of business can be different, my ways of working can be different, but whatever tool you use, you will be compliant with the data the regulator wants," Ray says. "That builds the trust." Transparency compounds from there. "When I share my data transparently, other energy companies share their market data transparently. When the data is available, we know where we are heading," he says. "Earlier we did not have good data, so there were more failed projects. Now we make business investment decisions with more data behind them." Algorithmic trading, already the norm, runs entirely on that trusted, traceable data . Fix it at the source His sharpest advice for industries following the same path is about where quality gets made. "Getting bad quality data and making it correct doesn't work that much. I have seen it in my day-to-day work," Ray says. "Go two or three steps back to where the data is being generated, correct the issue at the source, and then intake that data." The payoff is structural: fewer manipulation steps, better insights from the same data, and lower infrastructure cost, since processing bad data demands heavier tooling than ingesting clean data ever will. He frames the stakes in the industry's own history. "Oil powered the industrial revolution. Electricity powered the digital revolution," Ray says. "The next revolution is the data revolution." The views and opinions expressed are those of Arnab Ray and do not represent the official policy or position of any organization.

## The Smartest AI Business Cases Put Freed Capacity Back to Work
URL: https://www.thedatawire.com/news/redeployment-business-case-prashant-parida-ibm
Published: 2026-07-30T04:08:28.973Z
Section: Leadership
Summary: IBM AI strategy leader Prashant Parida joins the Data Wire podcast to explore what companies can create with the capacity AI releases.
Full text:
The template is familiar to anyone who has sat through an AI investment review: automate 40 percent of a team’s workload, remove 40 percent of the cost, book the savings. The slide is clean and the math looks persuasive. The problem emerges when it reaches the approval room, because the person best positioned to write that business case is usually the person who manages the team it would eliminate. Efficiency cases get built, then slow-walked by the people who built them. Prashant Parida leads AI strategy, transformation, and portfolio management at IBM and has advised and operated inside Fortune 15 organizations. He has spoken with over 15 executives running AI adoption at large enterprises, including a pharmaceutical company north of $80 billion in revenue and a media company around $120 billion, each approaching the same problem from a different direction. He previously discussed why enterprise AI stalls as a systems problem rather than a mandate problem. On a recent episode of The Data Wire's Beyond the IT Headlines podcast, Parida turned to the document where most of those programs actually break. The 40 people nobody releases Parida pointed to an application integration team of roughly 100 people inside a large enterprise. AI-assisted coding and specification work cut the team's effort by about 40 percent, which is exactly the result the program was funded to produce. "That means you get rid of 40 people," said Parida. "The guy who is working on the business case will never release those people, because then you're firing your own team. Why would you do that?" The arithmetic isn't wrong, which is part of why it's hard to dislodge. A savings case gets approved at the top, then meets a middle layer with every reason to keep the pilot small, the scope contained, and the headcount conversation permanently scheduled for next quarter. The aggregate result shows up in the spending data. The share of enterprises whose AI returns still haven't outpaced their investment is holding at 57 percent , a plateau that has now persisted across two years of improving production capability. What IKEA did with the other 53 percent Ingka Group, the largest IKEA franchisee, ran into the same fork and stopped somewhere else. Its customer service assistant, Billie, absorbed roughly 47 percent of inbound inquiries, the delivery tracking and order status volume that never needed a person. Around 8,500 call center workers sat on the other side of that number. Rather than size a reduction, the company looked at what customers were asking for in the half the bot couldn't resolve. "Somebody has a question about furniture, about a carpet, about interiors. These guys have domain expertise because they answer calls day in, day out," said Parida. "So they retrain them in interior design." The remote design channel those advisors now staff generated about 1.3 billion euros, against roughly 13 million euros in customer service operating savings from the automation itself. Nobody had to defend a headcount number to get there. "They produced $1.3 billion in revenue with these people. The capacity that you release can be repurposed to produce new revenue. That is where it becomes a safe place." When everyone has the same kitchen Redeployment only pays if the work people move into is worth more than the work they left behind, and Parida expects the tooling advantage that funds these programs to compress quickly. "When people use AI tools ahead of others, they have this unfair advantage. But when the dust settles, everything becomes the same," he said. His comparison is two restaurants. "A chef is a better chef because you understand the recipe. More than that, you understand your audience. You may have a brilliant kitchen, but the kitchen doesn't make you a better chef," explained Parida. "When everybody has AI, then your differentiation comes back to being human." Picking the first function Getting to redeployable capacity means starting with a scope small enough to measure. Parida is working with an early-stage venture that took marketing as its first target, on the logic that content and media creation sit closest to what current models do well. "If you spend $100 in marketing, there are components that AI can do," he said. The venture isolated about $40 of that spend, covering intelligence gathering, campaign strategy, and media creation through to channel deployment, and now runs the sequence for closer to $20 with no human intervention in the middle. From there the pattern repeats outward. Four or five contained pilots connect into a function, a function into a cross-functional chain from marketing through sales, delivery, and solutioning. "Then you could have a bigger impact across the enterprise." The sequencing matters for approvals as much as for delivery. A 30 percent cycle-time reduction inside one function is small enough that nobody has to litigate their own team's future to get it funded. The version that gets signed None of this makes the productivity math disappear. The 40 percent is still 40 percent and the capacity is still real. What changes is what the business case commits to doing with it, and whether anyone inside the building has to lose for the program to succeed. "You start small, but then create a business case in terms of reinventing the business, as opposed to saying 'Let's release productivity and let's release people from their jobs.' That's not going to work," said Parida. "Look at a revenue upside while you're releasing productivity. That'll be a good way to scale while deploying AI and creating a win-win game for everyone."

## The AI Era’s Scarcest Resource Is the Human Expertise That Keeps It Running
URL: https://www.thedatawire.com/news/human-capital-deficit-nabeel-mahmood-nomad-futurist
Published: 2026-07-30T04:08:28.973Z
Section: AI
Summary: On the Data Wire podcast, Nomad Futurist Foundation CEO Nabeel Mahmood explains why AI’s labor pipeline matters as much as its compute.
Full text:
Every megawatt of AI capacity under construction assumes a supply of electricians, pipefitters, controls engineers, and commissioning specialists that doesn't yet exist. Capital isn't the constraint. Land isn't the constraint. The constraint is a workforce the industry spent two decades recruiting from and almost no time building. The projects get announced anyway, and the people who have to energize, cool, and maintain them are being sourced from a pipeline that was never designed to feed this sector at this speed. Nabeel Mahmood is a technology executive, futurist, and Co-Founder and CEO of the Nomad Futurist Foundation , a 501(c)(3) that works to demystify digital infrastructure for students and career changers. His career spans CITO roles, board directorships, and two decades inside global technology organizations. He has previously discussed the physical constraints that determine whether high-density environments actually run. On a recent episode of The Data Wire's Beyond the IT Headlines podcast, Mahmood made the case that the labor side of that equation is the one the industry keeps deferring. The demand curve nobody staffed The public conversation about AI and employment runs in one direction, toward what gets eliminated. Mahmood's read of the data runs the other way. Korn Ferry's Future of Work research projects a global talent deficit of more than 85 million workers by 2030, concentrated in exactly the knowledge-intensive and manufacturing sectors that AI infrastructure depends on. Mahmood cites the figure often, and he's specific about what those roles look like. "We are entering into a phase where a different set of skill sets are needed," said Mahmood. "We need metal fabricators, we need people that can build chillers and air conditioners and air handlers and electrical mechanical equipment servers." Those categories map directly onto current hiring pain. Demand for trade workers tied to data center construction has outpaced supply badly enough that recruiters now describe specialized talent, rather than chips or capital, as the real ceiling on build-out speed. What the build-out leaves behind Part of the recruiting problem is reputational. Mahmood argues the sector has let others write its story, and the version that circulates is one of extraction rather than construction. He pointed to the rural communities in Oregon and Washington that hyperscale campuses landed in fifteen years ago, places that had more cattle than residents. "They built roads and byways, they provided connectivity, they cleaned out water, they built animal shelters," said Mahmood of the operators who moved in. "Quality of life that did not exist in those cities before." Those towns are now cities with modern infrastructure, and the through line matters for hiring. A high schooler who has only encountered data centers as a story about water usage and land grabs has no reason to picture a career inside one. Exposure before curriculum The Foundation's answer is physical. Rather than running awareness campaigns, it takes students into facilities, semiconductor plants, thermal management shops, and metal fabrication floors, and lets the environment do the recruiting. One recent group of about 60 students asked to see the data center that hosts Roblox, a platform they use daily and had never thought about as a building full of equipment and people. "The first touch point really is to take them out to these facilities to expose them to what the world is behind the curtains," said Mahmood. He compared it to walking a dealership lot, where the click comes from proximity rather than a brochure. What students look for once they're inside is rarely technical. "What they're really looking at is, okay, do I have a similar background, similar experience, similar schooling. And then you start connecting these dots." That model reflects a broader conviction about how credentials work now. "Education is not necessarily going to go get a degree from a college. It's based on exposure, experiences, and opportunities." The Foundation has since committed to a free training platform open to anyone globally, built on the same premise that access, not admission, is the gating factor. The pipeline starts before the job opening Mahmood sees the range of possible entry points in his own family. His son left college for aviation but remains interested in weather models and travel technology. His 17-year-old daughter is drawn to the regulation, policy, and standardization of compute. Their paths support his larger point: the industry cannot recruit only for predefined technical roles. It has to expose young people to the systems behind their digital lives and let them discover where they fit. That approach will not resolve the immediate labor shortage. Data centers being built on schedules measured in months depend on a workforce that takes years to develop. But Mahmood argues that the industry has spent too long drawing from that workforce without replenishing it. Nomad Futurist now operates across six continents and is building a free educational platform intended to turn early exposure into durable career pathways. "If we expose them to opportunities and the idea of innovation, they’ll find their swim lane," said Mahmood.

## Digital Twin Pilots Fail When Organizations Rush Past the Data Foundation
URL: https://www.thedatawire.com/news/operational-digital-twin-asset-data-tahir-applus
Published: 2026-07-30T04:08:28.973Z
Section: Future of Data Management
Summary: Abdourahmane Tahir, Head of Digital Services at Applus, explains why operational digital twins depend on rebuilding fragmented asset information into a governed, connected data layer before anything else.
Full text:
Organizations investing in digital twins tend to focus on the platform: the dashboards, the AI layer, the real-time views that promise better decisions. But the projects that fail share the same root cause. The asset data underneath was never trustworthy to begin with. For buildings and infrastructure built decades ago, the gap is not a technology problem. It is a data recovery and governance problem . Abdourahmane Tahir , Head of Digital Services at Applus + in the Middle East, leads the establishment and growth of the company's digital services department across the energy and construction sectors. Applus+ is a global testing, inspection, and certification company operating in more than 65 countries. His team drives asset digitization, digital twin, and reality capture initiatives for large-scale built environments. Across engagements, he finds that digital twin outcomes depend less on the platform and more on whether the asset data underneath has been recovered and governed. "Most of the time, the information is there, but organizations do not know where it is, what format it is in, or who owns it. If you do the assessment and validation properly, you can usually reach about 98% accuracy," says Tahir. The typical starting point Tahir's team works primarily with built environments: assets constructed ten, twenty, or even a hundred years ago. The engagement almost always begins with the same discovery. "Forget about 3D BIM, which is the foundation for the digital twin. The biggest problem in these assets is normally the simplest information, like accurate as-builts. They don't have it," Tahir says. Maintenance records, work orders, and asset attributes are either missing entirely, stored locally on someone's desktop, or scattered across incompatible formats with no consistent structure. New construction projects tend to have the data, but rarely have a strategy in place to maintain it through design, construction, and into operation. Recovering the information The recovery starts with reality capture. Tahir's team uses laser scanning, drones, and related technologies to digitize the physical environment and produce a 3D BIM model. That solves the geometry problem. The harder work is making that model intelligent by gathering, validating, and unifying the scattered asset data around it. "We do site validation when it comes to asset attributes or asset labels that are already on site. That gives us a lot of information. When it comes to manuals, sometimes we have to reach out to manufacturers," Tahir says. Third-party inspection, on-site verification, and manufacturer outreach combine to fill the gaps that block a trustworthy data foundation. Before any of that data enters a model, Tahir's team establishes the governance layer. "Sometimes we start with setting up the strategy and standards, because there is not even a standard naming convention in some scenarios." Existing information is converted into one unified format , loaded into the BIM model, and the result is an intelligent model with all asset attributes in one place. From model to operational digital twin A clean 3D model with unified data is not yet a digital twin . The distinction, for Tahir, is operational. A true digital twin connects all existing systems into a single platform where teams make decisions in real time. That means integrating BIM with maintenance platforms, ERP, facility management, GIS, and IoT data through a knowledge graph that maps each asset to a unique tag, pulling from multiple sources. "I would say 50% automated, but it is still human-involved to make sure that the right information goes into the right place," Tahir says. Without consistent naming and clear data ownership already established, automation breaks down. The payoff is measurable. Tahir describes a public water agency in Saudi Arabia where procurement teams previously spent two to three weeks gathering documents for a tender. "Now they don't need to talk to anyone. They just download it from the platform with the right permissions. It's a lot of time saved, and they get the right information, not outdated information." Management teams replace monthly reports that arrive already stale with real-time dashboards and KPIs. AI on a governed foundation Once the integrated data layer is in place, AI adds immediate value. Tahir's team deploys LLMs that allow asset owners to ask natural-language questions like "What is the maintenance plan for the next three months?" Predictive maintenance models become more accurate because they draw from multiple connected systems rather than a single source. Operators also use AI to summarize lengthy inspection reports and answer targeted questions about specific findings. "Instead of you going through a 200-page report, the system can find it for you," says Tahir. Tahir's advice to any organization starting this work is direct. "Get your strategy, your standards, your naming conventions, your governance right at the beginning. Start small. Get your first pilot right. Scalability is easy once you have your foundation right ." Organizations that rush past this step end up paying more in rework, and that pattern is a primary reason digital twin pilots fail across the industry.

## The Competitive Edge in Enterprise AI Shifts From Owning Data to Governing It at Speed
URL: https://www.thedatawire.com/news/enterprise-ai-moat-semantic-governance-ashish-yadav
Published: 2026-07-30T04:08:28.973Z
Section: AI
Summary: Ashish Yadav, Senior Data Engineer at The Modern Data Company, argues that with models and platforms available to everyone, the advantage moves to semantic rules, governed model access, and how fast a company can turn its own data into decisions it trusts.
Full text:
Everyone can rent the same models and platforms now. Frontier intelligence, the lakehouse, the compute, all a credit card away, and raw data edges toward table stakes. The durable advantage is migrating a layer up, into the semantic rules, governance, and speed that turn proprietary data into decisions a business trusts, a shift already forcing a rethink of data management . Ashish Yadav is a Senior Data Engineer at The Modern Data Company , the company behind DataOS, a platform that packages data into governed, AI-ready data products. He builds petabyte-scale pipelines and lakehouses with an eye on job time and cloud spend, engineers real-time telemetry for sub-second analytics, and mentors the teams doing the same. The moat conversation reaches him from inside the plumbing. "A lot of people say you can just give AI agents access to your data and it will make sense. It works in some cases and it doesn't in others. To plant those facts somewhere, you need a semantic model where all your rules are defined," Yadav says. An analytical engine next to the database Infrastructure is already reorganizing around agents. The newest architecture out of the Databricks AI Summit is LTAP , which unifies transactions and analytics on one copy of data in the lake, following a wave of hybrid designs like AliSQL, which drops a DuckDB columnar engine inside MySQL . The logic is agent fluency. "AI agents are well versed with working with databases, be it Postgres or MySQL. You want a system that is very quick to adopt these changes, because with your Iceberg or data lake, each time you make a change, metadata files get created. It's a lengthy process, plus the operational work of compacting it." Enterprises are still catching up with lakehouse formats from five years ago, he notes, so the hybrid story is where investment is going. Compute is not cheap anymore The hesitation he sees is cost fear more than doubt. "Previously with Hadoop, the costs were fixed. You buy the infrastructure once and you're done," he says. "Now, with Databricks charging on the basis of DBUs, the cost can balloon like anything, so they're skeptical." His prescription is a cloud mindset: know your jobs and durations, then buy accordingly. "On AWS you can pay upfront for a year of infrastructure, and that's relatively cheaper than running it on the fly. Compute is not cheap anymore." The same math is pushing enterprises back toward hybrid setups and architectures that span cloud and on-prem. He points to Basecamp, which bought hardware for repetitive jobs but kept shared data on S3, and to DuckDB resetting the floor for smaller shops. "Today, with 16GB of RAM and a decent laptop, you can process a terabyte of data. You can start with DuckDB, and only when it's not sufficient anymore, scale out to Databricks, Snowflake, or MotherDuck." Rules written once, used everywhere The semantic layer is where trust gets manufactured. A vendor coalition just finalized the Open Semantic Interchange specification , an open format that lets semantic models travel between platforms so a metric means the same thing everywhere. Portability matters because of who writes the rules. "The people with the domain expertise set up those rules once, your entire organization utilizes the same information, and you can always come back to your agent and make sure it's giving the same result to everybody." Model access gets the same discipline. "Enterprises are locking down to specific models. Say you're using Claude. You buy Amazon Bedrock for your company, and because it's in AWS, you can set IAM-level policies and lock users down to the models you provision," says Yadav. Inside Databricks, Unity Catalog splits teams by geography and regulation. "If you're in Europe, you have to follow GDPR, and in the US you have those rules, so you can separate that entirely." That's governance embedded in the platform rather than paperwork, with data readiness gating production AI . The one digit that breaks trust The failure mode he keeps seeing is wiring agents straight to raw data. "A lot of people are giving AI agents direct access to their data and expecting magic analytics, without accounting for hallucination, without guardrails, without a person who validates the data." When AI disappoints, the mess is usually the data underneath , and finance shows why. "The financial industry is holding back because they don't trust the data that much. If you're a CFO and somebody submits an AI-generated report to you and even one digit goes wrong, I don't think you will ever trust that report again. That's the kind of trust people need to bake into these products." The data is still the real moat, in his view. Winning with it is speed. "Take Coca-Cola and Pepsi, two of the same powerhouses. If one makes decisions based on data and is very quick to channel it, the one making the quicker moves has a better chance to operationalize that data than somebody who's sleeping on it."

## Government Missions Require Mission-Ready Data
URL: https://www.thedatawire.com/news/government-ai-data-modernization-katherine-hennessey-everpure
Published: 2026-07-30T04:08:28.973Z
Section: Future of Data Management
Summary: Katherine Hennessey, Head of U.S. Government Strategy at Everpure, explains why federal AI adoption depends less on model selection and more on modernizing the aging data infrastructure, storage architecture, and interoperability frameworks.
Full text:
If AI is to deliver for government mission owners, data readiness is the non-negotiable first step. The U.S. government wants, and needs, to utilize artificial intelligence (AI) to further its missions, from citizens services to autonomous defense systems. AI empowers agencies to achieve unprecedented efficiency, speed, and decision-making superiority, unlocking capabilities that were unimaginable just a few years ago But, across the federal landscape, data sits in legacy storage , fragmented across cloud environments and siloed at various agencies—exactly the conditions that prevent AI from working optimally, or at all. Katherine Hennessey is Head of U.S. Government Strategy at Everpure , whose enterprise data cloud provides a unified data and management plane, and supports hybrid cloud infrastructure across commercial and government environments. Before joining Everpure, she spent five years at NightDragon, a national security and defense-focused venture capital firm, leading government services. Her background includes professional staff roles on the U.S. Senate Committee on Appropriations, faculty positions at Georgetown and Rice, and a senior fellowship at Auburn University's McCrary Institute for Cyber and Critical Infrastructure Security. She frames a critical federal AI challenge as a data management and governance problem that no foundation model can solve on its own . "The government needs to implement AI, but we need to be realistic about the hurdles that it faces in optimizing that data to support AI," Hennessey says. "Incomplete or inaccurate data doesn't just deliver poor outputs. It could introduce catastrophic risk to the mission and result in real-world tragedies." Data unification is a national security requirement The evolution from Joint Enterprise Defense Infrastructure (JEDI) to Joint Warfighting Cloud Capability (JWCC) taught the government a critical lesson about the dangers of entrusting data to a single provider . Ironically, this pivot away from a single-vendor approach happened back when we were only just beginning to grasp the true value of that data and the analytical capabilities required to unlock it. Now that we're in the AI era, we shouldn't have to relearn these lessons. All agencies want to harness the power of AI, but effective implementation of AI isn’t only dependent on which foundation model they choose. It's also based on how difficult and expensive it is to move that data from cloud providers to foundation models, and then back to its own control if the agency later moves in a different direction. The question of who actually owns and governs that data becomes central to whether agencies can implement AI effectively to meet their missions, or whether it ends up locked into cloud providers’ ecosystems. "You want to create an architecture that lets you hold your own data, ensure continuity of operations, and then choose the foundation models that are best for your mission," Hennessey says. "A scenario in which the Department of War (DoW) is beholden to one of the frontier model companies is problematic because they then have control over the data you give them, and getting it back out may not be so easy." The Golden Dome missile defense program represents a near-term test case. Golden Dome is a planned U.S. homeland missile defense initiative designed as a multi-layered, AI-driven shield that integrates real-time sensor data across all domains—sea, air, land, space, and cyber—to detect and destroy advanced ballistic, cruise, and hypersonic threats. At its full scope, Golden Dome intends for there to be data-sharing amongst military services that have historically struggled to share data effectively. "We have to envision a world in which Golden Dome unifies data across air, space, land, and sea," Hennessey says. Without this unified data layer, aggregating the vast sensor telemetry across disparate service-owned programs and achieving true multi-domain interoperability remains an elusive goal. AI will fail without a modern data infrastructure Beyond the specter of vendor lock-in, the path to a unified data plane is frequently obstructed by the rigid economics and inefficiencies of legacy infrastructure. By shifting to flexible, high-efficiency architectures, such as hardware-as-a-service or pooled compute and storage resources to offset supply chain cost increases, agencies can finally decouple their operational capacity from these fiscal and physical constraints. This transition to modern data infrastructure can slash power consumption and reduce physical footprint by orders of magnitude. It also creates the high-speed, portable foundation required for true multi-domain visibility. Ultimately, modernizing data infrastructure for defense agencies extends far beyond equipment upgrades. It is a strategic necessity, building the resilience and agility required to scale AI and sustain mission success in an increasingly unpredictable global environment. Everpure Data Cloud allows agencies to manage their data on their own terms, establishing a unified data plane that delivers the efficiencies and cross-domain capabilities described above. By enabling full sovereignty and control, Everpure prevents data from becoming locked within proprietary cloud ecosystems or surrendered to third-party models. This platform empowers agencies to maintain data with near-zero friction while ensuring the high availability required for mission operations, ultimately providing a governance-first foundation that scales seamlessly with AI initiatives. "A modern data infrastructure that can support AI goals of our government faces some hurdles, which include policy and cultural hurdles. But if that data exists and can be managed the way I've described, then implementing analytics, orchestration, and AI technologies becomes much easier." The data layer, in Hennessey's framing, becomes critical to the program’s success, and makes the ecosystem interoperable. “Without it, every new capability faces the same integration friction," she says. Data silos stifle innovation The defense innovation community grapples with a phenomenon called the 'Valley of Death.' This refers to the critical gap where innovative startups and prototypes fail to transition into official programs of record or secure long-term production contracts because the DoW’s funding cycles move too slowly, causing companies to run out of capital. Hennessey is all too familiar with the challenge of getting the government to adopt and scale the innovative technology it needs, given her past work with defense startups. "At its core, the Valley of Death exists when investors cannot validate that a company can scale from pilots to production contracts at DoW. It then becomes difficult for those companies to obtain capital to grow in order to scale to compete for the defense programs of record. It’s a chicken-and-egg problem," Hennessey says. But, as Hennessey points out, data silos within the DoW directly contribute to the Valley of Death. When critical data is trapped in isolated enclaves, the smaller innovators can be locked out, unable to access foundational information required to design next-generation solutions. Data silos therefore can act as a formidable barrier to entry for the very tech companies we need most and stifle innovation at those companies. To solve this, we must shift our focus toward unifying our data while governing it robustly, ensuring it remains a secure, sovereign asset rather than blindly turning it over to AI models. By establishing a unified, governed data environment, we can democratize access for young, innovative companies, empowering them to build, iterate, and deliver the cutting-edge capabilities necessary to maintain our strategic edge. Siloed and inefficient data infrastructure directly threatens our ability to implement AI, thereby jeopardizing critical strategic priorities like the Golden Dome initiative and the essential need for sustained innovation. This disconnect undermines program goals and delays the progress required to secure our future. Given the profound national security implications and the significant taxpayer investment at stake, we cannot afford to wait. Fortunately, these technical barriers are surmountable today; we do not need to search for a breakthrough. The technologies to unify our data, remove these obstacles, and ensure mission readiness exist, are proven, and are ready to deploy.

## Data Architecture Takes Center Stage As Enterprises Build For Production-Ready AI
URL: https://www.thedatawire.com/news/data-readiness-enterprise-ai-bloomberg-accelerate
Published: 2026-07-30T04:08:28.973Z
Section: Future of Data Management
Summary: At Accelerate 2026, a Bloomberg Businessweek Radio broadcast surfaced a consistent diagnosis from CTOs, product leaders, a CFO, and a pharmaceutical platform engineer: the data layer is what separates AI experiments from AI that works.
Full text:
Three years into the AI wave, most enterprises have the models, the budget, and the executive mandate. What they don't have is data that's ready for production . That tension ran through five back-to-back segments on Bloomberg Businessweek Radio , recorded live at Everpure's Accelerate summit in Las Vegas in June 2026. The executives and practitioners who sat down with anchors Carol Massar and Tim Stenovec came from different vantage points: enterprise architecture, product development, R&D, pharmaceutical operations, finance. But across roughly 100 minutes of broadcast, the same diagnosis kept resurfacing. The bottleneck isn't models, and it isn't compute. It's the data. The readiness gap in numbers The Bloomberg segments gave voice to a pattern the data validates at scale. A 2026 readiness index from Fivetran , based on a survey of 400 data professionals, found that only 15% of organizations are fully prepared to deploy agentic AI in production, even as nearly 60% report investing millions. A separate Deloitte study found that 42% of companies believe their strategy is prepared for AI adoption, but feel less prepared on infrastructure, data, and risk than they did a year ago. The gap between investment and readiness is widening, not closing. Rob Lee , Everpure's Chief Technology and Growth Officer, framed the problem as architectural. The enterprise was built in an era where compute was assigned to applications, and data sat behind those applications in silos. AI, and agentic AI in particular, demands a fundamentally different arrangement. "To make agents effective, you have to make those decisions in real time," Lee told Bloomberg's hosts. "The only way you're going to do that is through a data primacy model where you can get the applications out of the way and work on the data directly." It's a point that resonates beyond the storage industry. Organizations that built their technology stacks around hundreds or thousands of discrete applications now face a structural problem: the data those applications generate and consume is fragmented, contextually isolated, and ungoverned at the pace AI requires . When a human worker encounters inconsistent data, they pause, ask questions, find a workaround. An AI agent does none of that. It ingests what it receives and executes. Raw materials before machinery Shawn Rosemarin , Everpure's Global VP of R&D and Customer Engineering, offered what was arguably the broadcast's most durable framing. He described the emerging class of AI-driven infrastructure as "AI factories," and argued that most organizations are approaching them in the wrong order. They're selecting machinery (models, GPUs, cloud services) before confirming they have the raw materials (clean, contextualized, accessible data) to produce anything useful. The factory metaphor reframes the ROI conversation that has intensified across the enterprise since late 2025. If data is the raw material and AI is the production line, then the bottleneck isn't the factory's output capacity . It's whether the inputs are fit for purpose. Rosemarin connected this directly to operational economics . "I want to minimize token usage because ultimately I am moving to a price per token. I want to maximize inference," he said. When data is properly indexed, vectorized, and enriched with context, models need less input to produce better output. The cost structure improves, latency drops, and the gap between a prototype and a production-grade system gets narrower. The inflection point, as Rosemarin described it, is the shift from experimentation to production at scale. "We're now seeing organizations taking those solutions, those prototypes, and wanting to roll them into production. And then the question becomes: is it affordable? Is it manageable?" What production AI looks like in pharma The most concrete answer came from outside Everpure's own ranks. Pradeep Bandaru , Head of Platforms and AI Workflows at Sanofi, described what it takes to operationalize AI in an environment where the data is among the most heterogeneous in any industry. Pharmaceutical data spans sequencing reads, cryo-EM videos, pathology images, manufacturing process records, and lab telemetry. These artifacts are produced by different instruments, stored in different systems, and described by different metadata schemas. AI can't operate on this data until it's captured, contextualized, and structured into something models can traverse. At Sanofi, that means building a pipeline that runs from real-time lab telemetry through a semantic knowledge graph to vectorization, indexing, and inference. "The data that we work with is incredibly heterogeneous, and it has a lot of metadata that needs to be captured and contextualized in order to make AI actually work," said Bandaru. The payoff, though, is measurable. Drug discovery timelines that historically spanned years are compressing to months. "AI really has proven out its value in understanding the search space for new drug molecules. That's one of the most powerful applications of AI we've seen so far." The pharma use case is instructive beyond life sciences. The challenge Bandaru described, where data exists in volume but lacks the contextual connections that make it usable, is a version of the same problem every enterprise faces. Context, not volume , is what separates stored data from decision-grade data. Shared context as an architectural requirement Chadd Kenney , Everpure's VP of Product Development, narrowed the diagnosis further during his segment. The shift to agentic workflows raises the bar because agents don't just consume data from one system. They need context drawn from across the enterprise: supply chain, manufacturing cost, quoting, approvals. That context is currently siloed in separate applications and stitched together by human judgment. "These agents only effectively execute with consistent shared context," he said. "People are realizing: while the power is there, the data is not ready for this, and they need that shared context." He also flagged a governance problem that intensifies as agentic adoption accelerates. Organizations are connecting agents directly to applications without security or governance frameworks in place. A shared context model, by contrast, creates a layer where access controls and governance policies can be applied before agents act on data. The alternative is a sprawl of ungoverned agent-to-application connections, each one a potential exposure point. Kenney also addressed the velocity of change that makes architectural agility essential. "AI, pretty much every six months, is a completely different world. You have to build a framework that's super agile and can move with you. You definitely don't want to lock yourself into a corner." For data leaders evaluating infrastructure investments, the implication is that flexibility matters as much as performance. A platform that locks an organization into a fixed architecture today may not accommodate the workflows AI demands six months from now. The investment scale behind the readiness question Tarek Robbiati , Everpure's CFO, placed the data readiness challenge inside a financial frame that resonated with Bloomberg's investor audience. The cumulative capital expenditure of the hyperscalers alone is projected at roughly $3 trillion over the next three years, a figure Robbiati noted is about two times the U.S. defense budget. That estimate excludes the AI-native companies (Anthropic, OpenAI, Cohere) and neocloud providers (CoreWeave, Crusoe). The investment is significant, and it's accelerating. But capital alone doesn't produce returns. Robbiati pointed to a "flight to quality" among enterprises facing sharp component price increases, arguing that when budgets are under pressure, organizations converge toward platforms that will endure. "If you invest today, choose carefully and choose the best possible product from a quality standpoint. One that will stand the test of time," he said. The structural supply constraints in NAND and DRAM , driven by the same AI demand that's fueling the CapEx supercycle, make infrastructure decisions harder to reverse and more consequential to get right. The financial picture reinforces the readiness argument from a different angle. If the industry is pouring trillions into AI infrastructure, the organizations that capture returns will be the ones whose data layers can actually absorb and operationalize that investment. Compute without data readiness is, as Everpure executive Kaycee Lai has described it , like buying a race car and parking it in rush hour traffic. From experiments to evidence The consistency of the diagnosis across the five Bloomberg segments, from practitioners operating at very different altitudes, points to something concrete. The enterprise AI market is crossing a threshold where the constraint isn't ambition, models, or capital. It's whether the data foundation can support what the technology is now capable of doing. Sanofi's production pipeline offers early evidence that it can. Drug discovery timelines measured in years are compressing to months. Real-time lab telemetry flows through a semantic knowledge graph into model training and inference. The loop is closing, and it's closing faster as context accrues. For data leaders watching the market, the signal from Las Vegas is unmistakable. Increasing the model budget won't cut it. For an organization to truly lead, they must invest in the data layer first , build shared context across their systems, and treat AI readiness as an infrastructure commitment rather than a mere technology experiment.

## AI’s CapEx Supercycle Turns Infrastructure Choices Into Long-Term Enterprise Bets
URL: https://www.thedatawire.com/news/ai-infrastructure-economics-bloomberg-accelerate
Published: 2026-07-30T04:08:28.973Z
Section: AI
Summary: A Bloomberg Businessweek Radio broadcast at Accelerate 2026 exposed the financial and operational pressure now shaping infrastructure decisions, from a CFO navigating a component supercycle to a federal cloud CEO modernizing under compliance constraints.
Full text:
The capital flowing into AI infrastructure in 2026 is staggering in both scale and concentration. Hyperscaler spending alone is on track to approach $700 billion this year , with cumulative projections over the next three years reaching into the trillions. That figure doesn't include the AI-native companies or the neocloud providers that have emerged as a distinct infrastructure tier. Component costs have surged in parallel: NAND flash contract prices climbed 55% to 60% quarter-over-quarter in early 2026, and the supply-demand imbalance isn't expected to ease before the first half of 2027. For enterprise data leaders, this creates a decision environment that punishes indecision and rewards architectural clarity. Infrastructure choices made today carry higher price premiums than at any point in the last decade, and the components going into those systems aren't getting cheaper on any near-term timeline. Against that backdrop, Bloomberg Businessweek Radio's broadcast from Everpure's Accelerate summit in Las Vegas surfaced two related but distinct threads: how the economics of the AI buildout are reshaping infrastructure strategy, and what happens when that strategy has to operate under the strictest compliance constraints in the market. A CFO's case for discipline over speed Tarek Robbiati , Everpure's CFO, delivered the broadcast's sharpest macro framing . His $3 trillion capex supercycle figure gave Bloomberg's investing audience a number to anchor on, but the more instructive insight was his description of how the supply shock is changing buyer behavior. When component costs spike, Robbiati argued, enterprises don't stop buying. They get more selective. "What tends to happen with customers who still have the need to spend is there's a flight to quality," he said. The logic is financial: if you're paying a premium for infrastructure that will anchor your AI and data operations for years, the total cost of a wrong decision compounds. Organizations converge toward platforms they believe will hold up over the full lifecycle of the investment, not just the first year. That flight-to-quality dynamic matters because it cuts against the experimentation mindset that dominated enterprise AI spending in 2024 and 2025. Chadd Kenney , Everpure's VP of Product Development, reinforced the point from the product side. "AI, pretty much every six months, is a completely different world," he said. "You have to build a framework that is super agile and can move with you. You definitely don't want to lock yourself into a corner." The tension between committing capital now and preserving architectural flexibility for what comes next is the core dilemma infrastructure buyers face in a supercycle. Robbiati also offered a rare public window into how Everpure has managed the pricing pressure internally. The company absorbed a significant portion of the component cost increase rather than passing it through in full, deliberately operating at the lower end of its historical gross margin range. "Our price increases were more gradual than the competition, and they were also of a lesser magnitude on a cumulative basis," he said. "We didn't want to profiteer from the crisis." Whether other infrastructure vendors took the same approach is a question enterprise buyers should be asking their account teams directly. The consumption model as a financial hedge One of the less obvious themes from the broadcast was how subscription and consumption-based infrastructure models are functioning as financial risk-management tools during a period of volatile AI demand. Robbiati described a customer base that's split: some organizations have defined AI plans and are buying high-quality systems with long time horizons, while others are still searching for the right use cases and need flexibility to experiment without overcommitting capital. For the second group, consumption-based models shift the risk. The buyer subscribes to a performance outcome rather than purchasing a hardware configuration, which means they can scale usage up or down without sitting on stranded capacity. That flexibility has direct budget implications. Organizations that overbuilt on-premises infrastructure for AI workloads that never materialized end up carrying both the depreciation and the opportunity cost. Rob Lee , Everpure's CTO, drew a parallel to consumer technology. The lag between searching for a product online and receiving a targeted ad is measured in days, not seconds. Agentic AI workflows are supposed to collapse that latency to real time. But most enterprises don't know yet how much infrastructure that real-time capability will require, or how fast the demand curve will ramp. Consumption models let them start building without betting the budget on a demand forecast that may not hold. Modernization under constraint If the CFO perspective showed how financial pressure shapes infrastructure decisions, the broadcast's final segment showed what happens when compliance requirements constrain the decision space even further. Michael Cardaci , CEO of FedHIVE, operates a federal cloud environment where every infrastructure choice must satisfy FedRAMP, ATO requirements, and the security mandates that come with handling classified and personally identifiable data. "The government requires everything inside of a boundary," Cardaci said. "You have a playground and you can do everything in the playground, but nothing can leak out." That boundary creates a fundamentally different modernization calculus. The "move fast and break things" culture that characterizes much of the commercial tech world isn't available in environments where the data is sensitive enough that an incident response timeline measured in weeks is no longer acceptable . "You can't really afford to make that 'break fast, move forward' kind of move because the data is too sensitive." That constraint, though, doesn't mean the federal sector is standing still. Cardaci told Bloomberg's hosts that the government is moving faster on compliance and security than at any point in his decade working in the space. The pressure is real: AI-accelerated threats are compressing attack timelines, zero-trust architectures are becoming standard requirements, and the competitive landscape with China and Gulf nations adds geopolitical urgency to infrastructure modernization. The enterprise relevance of Cardaci's perspective goes beyond government. Regulated industries across financial services, healthcare, and energy face versions of the same constraint: they need to modernize infrastructure to support AI-driven workloads, but they can't sacrifice compliance, auditability, or data sovereignty to do it. Traceable, governed data pipelines aren't optional in these environments. They're prerequisites. The infrastructure decision that compounds The through line across both the financial and the compliance perspectives is the same: infrastructure decisions made in 2026 carry more weight than they did a year ago, and they'll carry more weight a year from now than they do today. Component costs are elevated and projected to remain so through at least mid-2027. AI workloads are shifting from experimentation to production, and the infrastructure that supported pilots may not be the infrastructure that supports scale . Compliance requirements are tightening across sectors, and platforms that lack built-in governance will require increasingly expensive retrofits as autonomous agents take on more decision-making authority. The broadcast didn't prescribe a single answer. But the collective argument, from a CFO managing a supercycle, a product leader navigating six-month innovation cycles, and a federal cloud CEO operating under the most demanding compliance requirements in the market, points in a consistent direction. The organizations that treat infrastructure as a strategic, long-horizon investment, rather than a quarterly procurement exercise, will be better positioned to absorb whatever AI demands next.

## Physical AI Forces Data Teams To Rebuild Architecture Around The Real World
URL: https://www.thedatawire.com/news/an-phan-hippo-harvest-physical-ai-data-infrastructure-challenges
Published: 2026-07-30T04:08:28.973Z
Section: AI
Summary: An Phan, Senior Data Infrastructure Engineer at Hippo Harvest, explains why physical AI forces data teams to rebuild pipelines around reality, replay, and edge compute.
Full text:
Enterprise data teams are hitting a wall with physical AI, deploying the same Python scripts, orchestration frameworks, and cloud architectures that power the digital SaaS world and watching them break in production. The problem starts with how data originates. In traditional enterprise software, business events are first captured inside digital systems, where databases become the primary system of record. In physical environments, data is merely an observation of something that has already happened in the real world. A dusty camera lens, a robot tripping over a rock, or a layout changing without a system update can turn a data bottleneck into an infrastructure problem, forcing teams to adapt their architecture to physical reality rather than simply optimize the code. An Phan , Senior Data Infrastructure Engineer at Hippo Harvest , a robotics-driven agriculture startup that recently announced a $30 million Series C to support its next phase of growth, builds systems that have to survive intermittent internet and unpredictable physical environments. He brings more than a decade of experience bridging data infrastructure and physical systems to the work, including a tenure as a data engineer at AITOMATIC, where he built production data infrastructure supporting AI systems across manufacturing, maritime, and other industrial domains. Phan recently delivered a talk on cloud-edge data backbones at the IEEE Cloud Summit, with his core argument being that physical AI forces teams to completely rethink how data is collected, stored, and reconstructed. "The data is not the end. You have to go back more and more to reality," says Phan. Physical AI is still the Wild West, with no Stack Overflow thread waiting when standard tech stacks behave unexpectedly in the field. Phan treats the absence of documented solutions as the operating condition, with localized domain expertise becoming the most practical asset teams can deploy when something breaks. The disconnect explains why rethinking data management for the AI era keeps surfacing underneath so many failed AI platform readiness pilots , with physical anomalies introducing data that traditional digital infrastructure was never built to process. Designing for the historical replay Engineers working in physical AI often have to rewind reality months after the fact, rebuilding the timeline of why something went wrong or why a robot failed from whatever was logged in the moment. The infrastructure underneath that work has to support historical replay, which Phan says is less about analytical complexity than about discipline at the point of collection. "The solution is actually straightforward: capture enough context to reconstruct what happened," Phan says. "That means preserving different timestamps, such as when the event occurred, when the device recorded it, when it reached the server, and when it was processed. You also need the location. Once you capture enough context, you can reconstruct the history behind every data point." Preserving that level of context creates a downstream problem, with the volume and velocity of the data forcing infrastructure teams to deliver on timelines that traditional batch processing was never designed to handle. As physical AI deployments expand across larger facilities and eventually multiple sites, replay also becomes a fleet-wide capability rather than a local debugging tool. Engineers increasingly need to compare behavior across different environments, hardware generations, and operating conditions. The model development cycle has accelerated to a point where any historical replay request can become an emergency, and the underlying systems have to be ready to run before the request even arrives. "When you experience something new, you have to figure something new out," says Phan. "A scientist might suddenly need to rerun months or even years of historical data, compare different deployments, or reconstruct what happened under new operating conditions. From the infrastructure side, the question immediately becomes how quickly we can deliver those answers. Waiting weeks isn't an option." The pressure to preserve that level of context runs into a different problem at the modeling layer, where the industry conversation around generative physical AI and the headlines coming out of CES often suggest that modeling the entire physical world is within reach. Phan reads the operational reality differently, with the boundary of each system defined by the boundary of its environment. A physical AI system doesn't need a model of the universe. It needs a model of the environment in which it operates. "In the digital world today, embedding models mostly just capture text and images," he explains. "In physical AI, the challenge is deciding how much of the real world we can realistically capture and represent. There is simply too much reality to model, so you have to scope the problem first." Engineering the cloud-edge data backbone Architecture for physical AI has to account for intermittent internet connectivity, a constraint that shows up across agriculture, aerospace, and maritime deployments where remote operating environments cannot pause when the connection drops. Phan frames the cloud-versus-site decision not as choosing one over the other, but as determining how responsibilities should be divided between centralized cloud infrastructure and on-site systems, with the answer driven by operational requirements rather than technology trends. "Mission-critical operational control must remain on-site whenever an interruption could affect the physical system," he explains. "It depends entirely on the operational requirements. For each activity, you have to decide whether it needs centralized infrastructure or can operate autonomously on-site. That operational requirement should drive the technical architecture." Keeping certain workloads on-site forces a second discipline around two-way synchronization, with historical telemetry flowing up to the cloud and new models pushed back down through dedicated robotics IDE and developer tooling . As organizations scale from individual deployments to fleets of physical AI systems, the cloud also becomes the coordination layer for centralized observability, model rollout, and version management across every site. Engineering that pipeline introduces real AI growth constraints, with infrastructure teams under pressure to minimize the edge hardware footprint anywhere they can. The trade-off shapes the operating model: cloud as the single pane of glass for fleet-wide management, local systems for anything that cannot fail. "From the cloud, you should be able to see every deployment. Operators should be able to monitor the entire fleet centrally without requiring manual access to each site," Phan says. "That centralized visibility becomes increasingly important as physical AI systems scale." Scope holds the architecture together Replay workloads are where traditional data architectures start to break under physical AI, with the demand to rerun years of historical data through a modeling pipeline in a matter of hours sitting outside what traditional relational databases are optimized for. The result is a structural pattern where AI strategy gets stuck behind architecture the rest of the business has already moved past, with the ingestion layer becoming the bottleneck that nothing downstream can fix. The move teams are making is to keep the messy ingestion layer in object storage and let relational databases handle the clean, structured serving layer, which lines up with the broader case for a new data architecture built specifically for physical AI workloads. Unlike traditional enterprise software, where databases often serve as the system of record, physical AI treats the physical world as the source of truth. The role of data infrastructure is to preserve enough context to faithfully reconstruct that reality as models, algorithms, and our understanding of the physical system evolve. The clearest evidence appears in how teams now manage versioned datasets. Rather than treating relational databases as the system of record for every stage of the pipeline, many physical AI architectures preserve raw observations in object storage while using modern table formats such as Apache Iceberg to organize them into versioned, queryable datasets. Relational databases remain valuable for serving clean, structured application data, but the ingestion layer increasingly lives in object storage, where historical replay and large-scale reconstruction become much more practical. "For versioning, we use Apache Iceberg on top of object storage. At the site, we use MinIO as the local object store. Iceberg provides snapshots and version history, while MinIO stores the underlying data objects. Together, they provide a versioned data foundation that feels much more like Git for data than managing records inside a traditional transactional database." Taken together, these architectural decisions all serve the same purpose: preserving enough context to faithfully reconstruct reality as the physical world, models, and scientific understanding evolve. As physical AI systems expand across larger facilities and geographically distributed deployments, that same architecture must also preserve consistency across the entire fleet while allowing each site to adapt to its own physical environment. The constraint that holds all of it together is scope, with practitioners modeling the specific environment the system actually operates in rather than the world it sits inside. "Even today, every successful physical AI system succeeds because it focuses on a well-defined environment and a specific task," Phan concludes. "The reality we want to capture is only the part of the physical world that matters for that task."

## Traditional Data Pipelines Were Built for One Direction and Production AI Needs Feedback Loops
URL: https://www.thedatawire.com/news/production-ai-feedback-loops-architecture-shivali-naik-snowflake
Published: 2026-07-30T04:08:28.973Z
Section: AI
Summary: Shivali Naik, Senior Technical Architect at Snowflake, explains why traditional linear data pipelines break once AI moves toward production.
Full text:
Most enterprise data pipelines were designed to do one thing well: move data from point A to point B. That linear architecture works for traditional analytics. It does not work for production AI, where the system needs to learn from its own outputs, absorb new data sources on the fly, handle schema drift without breaking, and feed results back into the pipeline to improve over time. The gap between what most organizations have built and what production AI actually requires is architectural. Shivali Naik is a Senior Technical Architect at Snowflake , where she leads post-deployment AI architecture engagements with Fortune 500 clients across insurance, healthcare, and regulated technology industries. With experience spanning dozens of enterprise AI implementations, she is one of the architects Snowflake deploys on its most complex, high-stakes engagements where regulatory constraints, PII exposure, and multi-system integration make standard approaches unworkable. Her role sits at the point where strategy meets production: after the deal closes, she is the person responsible for making the architecture actually function at enterprise scale. Across nearly every engagement, she encounters the same foundational gap . "A lot of organizations have a streamlined approach with their data pipelines, where data comes in and goes out in a traditional format," Naik says. "But with AI, there's so much feedback loop and how you can train your data and ingest it again to make informed decisions. That type of architecture is where we are lacking with a lot of customers." Naik has formalized this distinction between static, directional pipelines and feedback-loop-capable architectures into a diagnostic framework she applies at the start of every enterprise engagement to assess whether an organization's data infrastructure can support production AI at all. Clean data and ownership come first Naik describes a consistent pattern across her client base. Organizations want to implement AI, but the data foundation underneath it is not ready. Data is not clean, governance is not in place, and ownership is not defined. "Creating a model is not the most difficult part," Naik says. "The main key points are people and data. When I say people, I mean who owns what. If something goes down, who should they be calling at 2 am so the whole infrastructure stays tight?" That ownership question becomes acute when multiple systems are integrated . When a failure occurs across two connected platforms, diagnosing which side caused the problem involves significant back-and-forth before anyone reaches a resolution. "There has to be proper ownership and governance in place," Naik says. "This person with this role owns this part of the data. Anything that fails in this integration, this person has to go in and fix it. That's still the hardest piece." Test the failure modes before production For Naik, the POC is where failure modes should surface. "You have to lock in how you're building your failback mechanism," she says. "If there's schema drift happening, how is your model going to handle that and still keep running? Those things need to be taken care of initially when you're doing a POC rather than waiting for production data and then failing in production." She also pushes for compressed build-crawl-run cycles . "It doesn't have to be six months. You can have one month of development and testing, then test whatever is wrong and move to the second phase with more users." Speed is fine as long as the coverage holds. "We're identifying issues faster," Naik says. "It depends on how your test cases are and how comfortable you feel. If they're not covering enough, take your time and build that variety." Skipping best practices guarantees a rebuild Many of the data deployment frameworks that would prevent architectural rework already exist, but Naik finds that most clients do not follow them. "A lot of clients that I work with, none of them follow any of the industry best practices," she says. "Then we come in as architects and we have to guide them through what becomes a rebuild of the whole system." For organizations handling PII and PHI, the trust barrier is even steeper. Naik sees insurance companies and healthcare organizations hesitate to engage with AI at all because they fear data will be shared with external models. The architectural answer is to bring the model to the data instead of sending the data out. "There are so many guardrails in place now," Naik says. "The data doesn't go to the model. That's how you can have the governance framework around it." The divide comes down to sequence. Teams that get the architecture right up front avoid the rebuild the others walk straight into. "If you follow basic frameworks when developing your architecture, even when something is added on, it's not going to be a major redo," Naik says. "It's just going to be a small tweak, and the pipeline is still going to run." For enterprises now on their second or third attempt at deploying production AI, Naik's diagnosis is consistent: the failure was architectural, and it was preventable. The organizations that got it right did so not because they had better models, but because they worked with architects who identified the structural gaps before the first line of production code was written.

## The Federal Government's AI Problem Is Really A 50-Year-Old Data Architecture Problem
URL: https://www.thedatawire.com/news/data-primacy-essential-for-government-ai
Published: 2026-07-30T04:08:28.973Z
Section: Future of Data Management
Summary: For decades the public sector has called data its most strategic asset, even as the systems treat data as an afterthought. AI is changing that, and in government what's at stake is public trust.
Full text:
The U.S. government buys more IT than any other entity on Earth — and that scale means when it moves, its purchasing power sets standards the rest of the market tends to follow. Right now, government is running headfirst into the same wall private-sector enterprises have already hit: application silos built for a world where data quietly followed the app that created it. For 50 years and like the enterprises that support them, government agencies built IT systems around application silos, discrete tools bought to solve discrete problems, each generating its own copy of data with its own definitions, formats, and access controls. That model worked when human analysts were the primary consumers of information. It breaks down when AI agents need to nimbly move across dozens of systems at once to produce useful results. That’s what makes the federal government’s data architecture struggle a market-wide bellwether rather than a bureaucratic footnote: it’s not a story about one large, slow-moving buyer. It’s a preview of what every organization with decades of application-centric IT is about to hit. Bill Wright is Head of Government Affairs at Everpure , where he translates the company's data-centric technical framework into federal policy. Before joining Everpure, Wright served as Staff Director on the U.S. Senate Homeland Security & Governmental Affairs Committee, held senior operations roles at the ODNI's National Counterterrorism Center, and worked as Special Assistant to the Coordinator for Counterterrorism at the State Department. He also led global policy efforts at Elastic and Symantec. "For 50 years the government has built IT systems with the applications at the center, data itself an afterthought," says Wright. "AI is finally forcing that correction because an AI agent is only going to be as good as the data that it can actually understand." Definitions that don't travel The inconsistency starts with something as basic as a shared vocabulary. The word "customer" in a sales system often refers to a different object than "customer" in billing. Multiply that mismatch across hundreds of applications and reconciliation becomes a constant, manual burden. In government, the stakes sharpen because those fragmented records often represent real people. "The same individual is a record in one agency and then you go over to the other agency and they're just a case number, and in the third one they're defined as a beneficiary," Wright says. A veteran's information takes one shape at the VA, another at the Department of Defense, and something different again at HHS. Each reconciliation cycle generates duplication, and each duplicate expands the digital attack surface. That fragmentation also undermines AI readiness . Agencies can announce pilots, but if the underlying data can't be understood consistently across systems, those pilots sit on an unstable foundation. Wright argues that federal modernization funding should reflect that reality. "They need to do a better job of funding the foundation," he says, "not just the demos that are sort of on top of it." Data primacy as operating principle Wright sees a significant opportunity for governments to realign themselves around Everpure’s vision of data primacy. This framework is built around three fundamental shifts in how organizations handle information. The first: definitions should travel with the data rather than living inside individual applications. A record should carry the same meaning whether an AI agent reads it in one system or in three others. That consistency is what makes AI outputs auditable and defensible , which matters enormously in a government context. The second: organizations should conserve data instead of copying it. One governed, well-described source serves everyone, cutting the duplication that drives up cost and introduces error. The third: governance should sit at the data layer, not the application layer. That last shift addresses a structural gap in how most agencies currently operate. The legacy model ties access controls to individual applications, but AI agents can query dozens of systems at once. That kind of lateral movement is exactly what application-level controls weren't designed for. "Agencies have a fiduciary responsibility to protect data and access has to be contextual. It has to be based on the data itself, who's asking it and why they're asking it," says Wright. The private sector has been hitting this wall for some time. Enterprises working to move AI from pilot to production are encountering their own versions of fragmented definitions, duplicated records, and governance models built for human-speed workflows. Given the government's outsized purchasing power, Wright sees its pivot toward data primacy — and the standards it sets in pursuit of it — as a potential blueprint for how the broader commercial landscape addresses the same problem. The cheapest watt you never generate Behind the architecture debate sits a growing infrastructure pressure point. AI compute and cooling represent the largest power draws at data centers, and energy consumption tied to these workloads is projected to grow sharply through the end of the decade. Communities nationwide are starting to feel the impact. During a recent visit to New Jersey, Wright sat next to county commissioners who flagged data center expansion and local energy affordability as top constituent concerns. Everpure sees examples where storage can account for up to 25% of the data center power draw, a smaller slice than compute or cooling, and Wright doesn't claim storage alone will solve the grid challenge. But efficiency gains across all three categories compound. "The cheapest watt of energy is the one that you never have to generate," he says. Federal policy can accelerate that correction by linking grants, tax incentives, and procurement rules to measurable energy reduction benchmarks rather than simply funding more capacity. The gap between voluntary commitments and actual enforcement makes that policy lever more urgent. Hyperscalers signed a White House pledge in March to cover their own power costs and keep them off household bills, but there's no enforcement mechanism behind the promise. Wright sees that gap as precisely where demand-side efficiency standards can do real work, rewarding organizations that reduce consumption rather than subsidizing continued expansion across an already strained grid. With Congress largely gridlocked on comprehensive legislation, much of the near-term policy work is happening agency by agency, even as Wright continues pressing lawmakers directly. He plans to spend the coming months bringing the data primacy framework both to policymakers on Capitol Hill and to the agency and executive-branch leaders shaping day-to-day implementation. "If there's one truism in Washington, it's that innovation will always outpace public policy," he says. "But when government does move and set the blueprint, the impact reshapes the surrounding commercial landscape far beyond the agencies directly involved."

## America Won’t Win the AI Race Without Data Center Efficiency
URL: https://www.thedatawire.com/news/ai-data-center-efficiency-ratepayer-protection
Published: 2026-07-30T04:08:28.973Z
Section: Leadership
Summary: Bill Wright, Head of Government Affairs at Everpure, makes the case for AI-ready data infrastructure that supports national innovation without burdening taxpayers.
Full text:
The United States is currently locked in a global sprint to define the future of artificial intelligence—a race that depends on the ability to store, move, protect, and analyze massive amounts of data in real time. From mission-critical databases to large-scale machine learning training, the demand for data is insatiable. As the nation builds the data centers required to win the AI race, we face a grim truth: our national power grid risks buckling under the strain. As importantly, we cannot allow the energy requirements of our digital expansion to be financed by American families already strained by rising costs of living. To train, secure, and deploy AI at scale, the federal government and industry must make data center infrastructure efficiency a national priority. Protecting taxpayers must be part of the data center buildout The White House’s recently enacted Ratepayer Protection Pledge is a landmark commitment to this challenge. By ensuring that the AI boom does not drive up electricity costs for American families, the government is asking the technology sector to do more than just innovate. It is asking for better stewardship of critical national resources. The scale of the AI-driven data center expansion is staggering; the projected 800 TWh surge in U.S. electricity demand through 2030 is equivalent to 1.5 times the total power currently consumed by Germany. With AI workloads alone expected to drive 60% of this growth, the nation has entered a structural 'supercycle' of energy demand that requires a fundamental build-out of new infrastructure. The good news is that the technology required to meet this challenge already exists. American innovation has already produced data platforms capable of unleashing the power of data without the massive environmental or fiscal tax of legacy systems. However, achieving the White House’s goals requires a fundamental rethink of how we manage the nation's digital infrastructure, and how we can do so efficiently. How legacy infrastructure creates a hidden tax For too long, the hidden tax of the digital age has been physical and energy inefficiency. Legacy data storage technology is notoriously power-hungry and bloated, forcing government agencies and industry to over-provision energy capacity, maintain complex hardware footprints, and execute costly replacement cycles that consume budget, resources, time, and energy. If we continue to build AI infrastructure using yesterday’s inefficient standards, the industry will inevitably fail the Ratepayer Protection Pledge. AI workloads require speed and access to high-quality data . Building tomorrow’s AI capabilities on yesterday’s infrastructure assumptions will ultimately increase operating costs, intensify energy demand, and slow mission delivery across government. We must utilize AI-ready infrastructure that prioritizes density and efficiency by design. Advanced architectures now allow the public and private sectors to scale capacity on demand and support data-intensive workloads without the rip-and-replace cycles that generate such massive amounts of e-waste and taxpayer money. Policy can further accelerate the shift to deployment of high-performance compute that align with measurable efficiency outcomes. Federal grants, for example, can require specific energy-reduction benchmarks. Winning the AI race without passing the bill to citizens As the effort to modernize federal information technology and streamline government efficiency continues, a service-based model for storage allows the government to consume data management as a managed service that stays current without disruptive, energy-intensive upgrades. The race for AI is a marathon of efficiency. We must build a digital foundation that is policy-driven, autonomous, and, above all, sustainable for the American citizen. By championing these existing technological standards, we can ensure that the most advanced data infrastructure in the world is also the most responsible. Together, we can power the next century of American innovation without leaving the American ratepayer behind. The views and opinions expressed are those of Bill Wright and do not represent the official policy or position of any organization.

## Industrial AI Readiness Starts at the Sensor and Most Organizations Are Not There Yet
URL: https://www.thedatawire.com/news/sensor-integrity-industrial-ai-readiness-oliver-inseal-parker
Published: 2026-07-30T04:08:28.973Z
Section: Future of Data Management
Summary: Oliver Inseal, Divisional NPD Engineering Manager at Parker Hannifin, explains why industrial AI is only as trustworthy as the physical sensor producing the data underneath it.
Full text:
The conversation around industrial AI tends to focus on the intelligence layer: smarter analytics, predictive maintenance, automated decision systems built on streaming data. But in condition monitoring for marine engines, the bottleneck is not the algorithm. It is whether the physical sensor can produce measurements that are clean, stable, and repeatable enough for anyone to trust what comes after it. Without that, every downstream system fails at the source. Oliver Inseal , Divisional NPD Engineering Manager at Parker Hannifin , leads new product development for the condition monitoring team, which is part of Parker’s Hydraulic Industrial Filtration Europe (HIFE) Division. His team designs and validates sensors for marine, hydraulic, and industrial applications, with a current focus on continuous online wear monitoring for two-stroke marine engines. Inseal is a Chartered Engineer with over 20 years of experience in sensor development across marine, pharmaceutical, aviation, and petrochemical industries. "At the end of the day, the heart of it is always going to be the sensor and the reliability of that sensor. If that's off, all your data's off. You're only as good as your data, and to be as good as your data, you need sound hardware," says Inseal. A decade to get online The marine industry's transition from offline measurement to continuous monitoring has taken roughly a decade of engineering work. Operators historically sent oil samples to labs or relied on periodic offline analysis. That process was slow by design, and maintenance was reactive by default. Inseal says the shift has been gradual and challenging, but the recent launch of Parker’s Online FWM (Ferrous Wear Meter) sensor is expected to accelerate this transition. "There are a lot of legacy products, very archaic products that people don't want to move away from because it's bread and butter. We're now having to try to change that mindset. Condition monitoring is a hard sell. Why do I need to invest in this? Well, it's going to potentially save you half a million on cylinder liners. But until it happens, there's no reality." The engineering challenge is that accuracy alone does not solve the problem. When measuring parts-per-million iron content in oil, there is no universal "right" number. An older engine might run at 90 ppm while a newer one sits at 5 ppm. Neither is wrong. "The chief engineers are just looking at this data to say, if all of a sudden you get a spike, something has changed. Go and investigate. Maybe you've got a new fuel on board, maybe a different cylinder lubrication oil, maybe a different flow rate." The value comes from trending against established baselines , not from hitting a predetermined threshold. Every application is different. Hardware first, intelligence later Inseal is clear about where Parker's core competency sits. The company designs, develops, and manufactures condition monitoring instrumentation and sensors. The software and interpretation layer is a different problem that Parker supports through partnerships rather than building in-house. Major marine OEMs are already exploring how to integrate sensor outputs into engine management control systems, where rising PPM measurements could automatically adjust cylinder lubrication flow rates. "They want to develop their own control software where this is feeding in. They can integrate it by CANopen industrial standard protocol and write software around our sensors so it becomes a smart sensor. But that's not our skill set." Parker has developed companion software that lets users define their own warning levels, recognizing that bespoke thresholds are necessary given how much applications vary. But Inseal positions that as a support tool, not the product. "The customer just wants to know: when do I need to stop? How long have I got left? That's the next step." Zero defects as the real AI prerequisite Inseal frames zero-defect engineering as the actual prerequisite for industrial AI readiness, not smarter models or better platforms. If the sensor is blocked, chemically incompatible, affected by electronic noise, or producing inconsistent measurements, the entire data infrastructure collapses. "If one of those fails, you have no product. Everything falls down." His team follows robust product development lifecycles to ensure thorough product validation and has invested heavily in process automation, including fully automated calibration, leak testing, and laser marking, in support of zero-defect principles. "What does a customer want? They want performance, accuracy, repeatability, reproducibility, and confidence in the product’s functionality and service life. Ideally, we just want to install this, and they never have to think about it again." On AI's role in his own engineering process, Inseal is measured. AI is a tool, useful in the right context but not transformative for the kind of bespoke, low-volume sensor development his team does. "AI coming along and supporting us, it's only a tool at this present time. I'm still figuring out where it sits with what we do." The constraint on industrial intelligence is not the software sitting above the data. It is whether the physical signal underneath is trustworthy enough to build on. "You're only as good as your data. And to be as good as your data, you need sound hardware."

## How Certified Data Is Eliminating Duplicate Pipelines Across Enterprises
URL: https://www.thedatawire.com/news/att-gangadhar-thumu-modern-data-ecosystems
Published: 2026-07-08T06:31:20.765Z
Section: Future of Data Management
Summary: Gangadhar Thumu, Lead Data Engineer at AT&T, breaks down why the hidden cost of data platform modernization is the duplicate work happening across business units that lack shared visibility.
Full text:
Across enterprise data teams, the same scenario keeps playing out: two business units pull near-identical datasets from the same warehouse, build adjacent pipelines, and ship dashboards that show roughly the same numbers to different stakeholders. The pitch for modern, unified data platforms is supposed to solve this problem by collapsing the stack into a single environment, where shared consumption and centralized storage eliminate the duplicate work underneath the surface. The pattern is harder to dislodge than the architecture suggests, with consolidated tooling rarely fixing what is fundamentally a governance and ownership problem . Engineering leaders working through these migrations are learning that the platform decision is the easier half of the equation. Gangadhar Thumu , Lead Data Engineer at AT&T, is working through exactly these kinds of migrations inside one of the largest enterprise data environments in the country. With more than 14 years of IT experience and a stack of Azure and Fabric certifications, Thumu approaches the modern data ecosystem through a strictly pragmatic lens. Culture is part of the equation, but the plumbing has to work before anything else can. When evaluating infrastructure choices, Thumu relies on a straightforward heuristic to cut through the marketing layer that surrounds most platform discussions. "It's all about the data duplication, it's about the processing power, and more importantly, the same work being done by multiple teams. That's a big challenge," says Thumu. The first decision in Thumu’s framework is choosing between a warehouse and a Lakehouse. Structured, tabular data aligns well with traditional warehouse architectures, while environments handling APIs, JSON payloads, and unstructured data require the flexibility of a Lakehouse. Connectivity is the next consideration, since a unified platform only delivers on its consolidation promise when it can actually reach the source systems that feed it. Legacy orchestration tools tend to break down as the source list expands, with coverage caps that force teams to bolt on secondary connectors for the systems the main tool cannot reach. A single platform able to handle a project drawing from ten sources alongside another drawing from five is what makes the consolidation pitch work in practice. Invisible infrastructure as the goal While business users often see little change during backend migrations, the burden shifts heavily to engineering teams responsible for migrating pipelines, datasets, and integrations . Large-scale migrations involving Synapse, ADF, Fabric, Snowflake, Power BI, Power Automate, and OneLake can take months. However, automated readiness and assessment tools are reducing this effort significantly. In one case, Thumu’s team analyzed 75–80 pipelines and leveraged built-in readiness tooling to streamline migration. “It shows everything is intact. To move to Fabric, the assessment portal provides the blueprint and effectively turns technical validation into a one-click confirmation, even though the deployment orchestration still requires a structured rollout,” he explains. Solving problems for one team often creates duplication elsewhere. Thumu describes a recurring scenario: his team automates backend analysis and distributes results via email, eliminating manual effort. Meanwhile, other departments request the same data through custom Power BI dashboards. The result is parallel pipelines, duplicated processing, and increased infrastructure costs without shared visibility across teams. “With disparate tooling , data duplication becomes inevitable,” Thumu notes. Invisible infrastructure as the goal This is not simply a communication issue; it’s an architectural one. Thumu advocates for governance-driven solutions centered on certified and endorsed data models. These mechanisms enable teams to reuse trusted datasets instead of rebuilding pipelines, significantly reducing redundant processing across the enterprise. As platforms mature, infrastructure is increasingly abstracted. Dynamic scaling models, such as F64 or F128 capacities, replace granular infrastructure decisions, shifting focus toward cost optimization rather than system configuration. “When the infrastructure layer becomes invisible, the platform simplifies. The only thing we track is cost—before and after Fabric,” Thumu explains. The next governance frontier The reliability of baseline infrastructure is finally stabilizing across enterprises that have invested in serious data modernization work . With core data movement operating without daily failures, engineering teams are freed up to focus on what to build with the data rather than fighting to keep it flowing. The era of daily pipeline and ETL failures is largely behind the industry, with foundational technology delivering reliable, near-instant data on a consistent basis. "A couple years back, we used to have pipeline failures, ETL failures, many daily. I haven't seen any pipeline failures in the past few years," Thumu says. The attention is now turning toward speed of AI adoption, with the same governance discipline that solved the duplication problem applied to the question of how fast and how safely AI can be brought into the enterprise. Many companies are balancing aggressive adoption with stricter guidelines around token usage, applying the same operational mindset to AI workloads that data engineering teams have been applying to core pipelines for years. The combination of reliable infrastructure underneath and disciplined governance on top is reshaping what enterprise data engineers can realistically deliver. "A project that used to take three months can now be completed in 10 days with more quality," Thumu concludes. The views and opinions expressed are those of Gangadhar Thumu and do not represent the official policy or position of any organization.

## Data Teams Catch Silent AI Failures By Tracing Systems Before Locking Them Down
URL: https://www.thedatawire.com/news/silent-ai-failures-visibility-before-guardrails-sathish-kumar-subramani-fineline
Published: 2026-07-06T15:26:40.579Z
Section: AI
Summary: Sathish Kumar Subramani watches enterprise AI systems closely before governing them, since the costliest failures pass every check while quietly handing customers wrong answers.
Full text:
The AI failures that do the most damage in production are the ones nothing catches. The dashboards look healthy, and the model still gives a customer the wrong answer with full confidence. Stopping that starts with watching how a system behaves before adding any controls on top. The common instinct is to put guardrails in first, before a team has any clear picture of what the system is doing in the wild. Sathish Kumar Subramani is a Senior Software Engineering Manager in the RFID and packaging industry. With more than two decades in software, he still works close to the code, and that hands-on view shapes how he approaches anything heading into production. "We think the system's working fine. Technically it's functioning, but logically it's failing. We can't govern what we can't see," Subramani says. The analogy he reaches for comes from manufacturing. "When you build a car, once the factory inspection is complete and it's out on the road, we still trace its performance through dashboards, monitoring range and other metrics. That has to continue through the entire life of the car. We have to implement architectural governance the same way, across every layer," Subramani says. For an AI system, that means wiring visibility into the API gateway, the data layer, and the points where users send input and get a response. Trouble can surface at any of them, so a single checkpoint leaves the rest exposed. A check built into the runtime catches it as it happens, while the same issue written into a policy document just sits there until someone thinks to look. When nothing looks broken To show the kind of error he means, Subramani describes a customer-support tool running on retrieval-augmented generation (RAG), pulling answers from a company's return policy. That policy covers physical goods. The company later adds digital products and no one revises it. So when a customer asks whether a digital purchase can be sent back, the model tells them to mail it in for a refund. Nothing errors out and the logs stay clean, so nothing prompts the team to look. A crash gets noticed in minutes. An error like this can run for weeks, repeating the same wrong answer to everyone who asks, and it usually surfaces only when a complaint or a mistaken refund reaches the team. By then the damage sits in lost trust, well outside anything a dashboard tracks. "When we move an application into production, we have to trace every piece of data. We track whatever input the user provides, and we audit the response the AI gives," Subramani says. In practice, that means logging the question a user asks next to the answer the model returns, then checking that the two line up against the current rules. The model follows the data it's given. What no one catches is the gap between a rule written for one kind of product and a question about another. Guardrails come last for a reason Most teams reach for controls the moment a system goes live. The sequence Subramani recommends runs the other way. "In phase one we implement basic log tracing. In phase two we expand those logs to observe what's happening across the system. Only in phase three, once we have full visibility, do we bring in the guardrails," he says. A control added before a team understands the system tends to guard the wrong thing. The early phases earn that understanding, and they do double duty. Logging and observation also show where the data comes from and which version of a policy the model is drawing on, the lineage that decides whether an answer holds up. When the source data is stale or skewed, the model's output follows it, so the data and the model end up governed as one . Once that view exists, the guardrails have somewhere sensible to sit. The highest-leverage spot is the entry point, since anything that gets past it is already inside the model's reach and harder to pull back. "Sometimes a user mistakenly enters their credit card or personal information, and that data should be masked before it ever reaches the LLM," Subramani says. A rail at the input catches that kind of slip and masks the sensitive field before the model processes it, so it never lands in a log or gets repeated back later. The same approach covers the response on the way out, and the handoff between the model and any tool it calls. Those checkpoints carry more weight once systems start acting on their own. Zero trust becomes the only workable posture Security has long pointed outward. Firewalls keep attackers out, and whatever sits inside the perimeter is trusted by default. An autonomous agent breaks that logic. It can call APIs and act on databases on its own, so the power to do damage now sits inside, in a component the system is built to trust. "With agentic AI, the agent itself can cause harm through its own actions. It can damage the application or delete the entire database. Because the agent creates the harm, we have to govern every action it takes," Subramani says. The risk grows when agents start calling each other . One hands a task to a second, the second passes part of it to a third, and no person reviews any of those handoffs. The fix is to drop that default trust. Each agent gets only the access its task needs, and any action that is hard to reverse stays with a person. "Even if an agent drafts an email, sending that message has to remain a manual, human decision. Applying strict governance at that stage stops the system from autonomously sending out incorrect information," Subramani says. An unsent draft can always be deleted, while a delivered message cannot be recalled. The deeper shift is in what the default looks like. Access is granted narrowly and widened only as an agent proves itself, drawing on the same visibility those earlier phases produce. "We have to prioritize zero-trust and least-privilege implementations, and add guardrails wherever possible. In the agentic era, the landscape has completely changed, so our approach to keeping systems safe has to change with it," Subramani adds. Keeping the model in-house settles the risk For all the complexity surrounding AI architecture, the primary hurdle stalling enterprise adoption is straightforward. The core anxiety for many leaders is what happens if their sensitive data gets out, and that worry frequently outweighs their confidence in the technology itself. "If data is exposed to the public, it's a massive issue. That's the exact point where everyone holds back on bringing LLMs into their production applications. I discuss this with multiple technology leaders, and many simply don't want to cross that line," Subramani says. His answer removes the part that scares them. Running an open-source model on the company's own infrastructure significantly reduces the risk of data exposure, keeping sensitive information within the organization's controlled environment. "We can take a powerful open-source LLM like Llama and deploy it entirely within our own environment. It runs strictly on our own servers, which keeps sensitive data from being transmitted to third-party AI providers. This local framework has to be explained to mid-market technology leaders so they can finally move forward with AI adoption," Subramani says. For the engineering and product teams he advises, this local framework is often what moves stalled projects off the whiteboard and into development. It gives wary technology leaders access to powerful AI capabilities without requiring sensitive data to leave their controlled environment, providing the reassurance needed for a successful first deployment. However, it does not eliminate risk entirely. Instead, it shifts the responsibility from the AI vendor to the organization's internal technology teams. The views and opinions expressed are those of Sathish Kumar Subramani and do not represent the official policy or position of any organization.

## The Paradox Of Simplicity: Maintaining A Data Platform Is Harder Than Building It
URL: https://www.thedatawire.com/news/data-platform-maintenance-simplicity-manoj-anugu-country-financial
Published: 2026-07-06T15:18:56.844Z
Section: Future of Data Management
Summary: Manoj Kumar Anugu, Senior Data Platform Engineer at COUNTRY Financial, explains how steady discipline keeps a data platform from sliding into a costly mess as it scales.
Full text:
Building a data platform is hard. Keeping it simple afterward is harder. As the business adds features and new data sources, quick fixes pile up as technical debt, and a clean design slowly turns messy and expensive to run. Holding that line takes steady discipline, the kind that keeps the data behind a company's analytics and AI reliable. Manoj Kumar Anugu is a Senior Data Platform Engineer and Data Scientist at COUNTRY Financial , an Illinois-based insurance and financial services group. He builds and maintains hybrid cloud systems , linking older on-premises Hadoop setups to newer cloud data warehouses in regulated, data-heavy industries. Earlier, he helped build enterprise data lakes at Novo Nordisk in healthcare. Years of running these systems have shaped how he thinks about keeping them simple. "Keeping a data platform simple over time is more challenging than the initial build," he says. His answer is structural. He leans on standardized patterns like a medallion architecture to keep data organized as a platform grows , and refuses to let technical debt sit unbudgeted. Debt comes due The trouble usually starts during fast development cycles, when quality slips and quick workarounds pile up. The cost shows up later as fragile pipelines and rising cloud bills. On many teams, maintaining and reworking what already exists eats up a quarter to a third of engineering time, and that share climbs as a platform ages. Agreeing on clear standards and governance rules early sets a baseline the team can follow as the platform expands. The cleanup also needs a place on the roadmap. "Allocate dedicated sprint capacity to address technical debt, refactoring, and optimization tasks," Anugu notes, treating it as a priority alongside new features. Teams that handle it this way keep their momentum, with fewer fires to fight later. Regular code and architecture reviews spot trouble early, before it compounds. Let the bots build Some of that upkeep is better handed off to machines . Routine, error-prone tasks are the first things Anugu automates. Infrastructure as code lets a team stand up and configure environments the same way every time, which removes a common source of drift between development and production. "This helps maintain environment consistency and simplifies multi-environment deployments," he says of tools like Terraform and AWS CloudFormation. Automated data validation and monitoring extend that to data quality, catching problems before they reach a business user. Automation has limits. "Avoid over-automation that adds unnecessary complexity," Anugu says, steering teams toward high-impact work that improves stability and frees people from toil. The point of the time saved is judgment, the room to weigh ideas that a script will never surface. Map before you move Not every engineer gets to set these habits from scratch. Many inherit a platform someone else built, often patched in a hurry and short on documentation, with no obvious place to start. The first job is to slow down and look before touching the code. That means figuring out what runs and how, including the undocumented steps and the bottlenecks no one ever flagged. "Begin by thoroughly reviewing the existing platform components, the data pipelines, the workflows, and the documentation ," he says. From there, risk sets the order of work. A pipeline that fails every night does more damage than an awkward block of code, so unstable jobs and bad data get fixed before anything cosmetic. Splitting the cleanup into small, sequenced sprints keeps a daunting platform from feeling impossible. Through all of it, documentation does the quiet, heavy lifting. Mapping data lineage and source-to-target dependencies gives a team the mental model it needs to troubleshoot and to build on what it inherited. "Documentation is very important, but it remains the underdog," Anugu adds. The human layer The hardest part of a cleanup is rarely the code. "Cleaning up a data platform is not just a technical challenge but also a people challenge," Anugu says. A platform stays reliable when the team behind it shares what it knows and owns its work, and standards hold up that way even as the stack changes. Cost puts a number on that culture. As cloud spending grows, a messy architecture stops being an abstract worry and starts showing up on the bill, which makes efficiency a plain test of how mature a platform has become. The same goes for AI. The advice is to stay curious about new tools and be ready to learn them. "Don't be scared of AI. Learn how to work with it," he notes. A platform that stays simple is never finished. It gets rebuilt sprint by sprint as the company shifts around it. The engineers who keep at that work earn the trust of the people who rely on their data, and the standing to take on whatever the business needs next. His rule for getting there is short: "Do enough, don't drag it."

## Inference Economics Will Decide Whether Next-Generation Recommendation Systems Reach Production
URL: https://www.thedatawire.com/news/generative-recommendation-systems-inference-economics-mukul-surajiwale-etsy
Published: 2026-07-06T15:18:56.844Z
Section: AI
Summary: Surajiwale, Staff Machine Learning Scientist at Etsy, explains why recommendation systems are shifting from pointwise prediction to LLM-based generative architectures.
Full text:
The recommendation systems running in production at most major tech companies are the final, most refined version of an architecture that has been incrementally improved for over a decade. The underlying approach, matching a query and a set of user signals against items to predict click or purchase likelihood, has stayed consistent even as the models underneath it grew more powerful. That paradigm is now changing. A new generation of recommendation systems uses the same autoregressive architecture that powers LLMs, predicting the next item a user will want the same way a language model predicts the next word. The infrastructure required to serve these systems at scale looks nothing like what came before, and the question of whether they reach production depends almost entirely on inference economics . Mukul Surajiwale is a Staff Machine Learning Scientist at Etsy , the global marketplace for handcrafted and unique goods. He was a founding member of HubSpot's AI group, led applied LLM research at Shopify, and built multimodal retrieval systems at Writer. His career spans the full arc from classical ML recommendation systems through deep learning to the current generative frontier. "The future of serving next-generation recommendation systems comes down to one thing," Surajiwale says. "Can you make the economics work from an inference standpoint?" The paradigm shift Surajiwale describes current production systems as the "ultimate V10, final edition" of what he calls the Gen 2 architecture: deep neural networks making pointwise predictions about whether a user will engage with a specific item given a query and user history. That approach has served the industry well, but the contours of the problem itself are now changing. "We're kind of on this new frontier," Surajiwale says. "These recommendation systems use the same architecture that things like ChatGPT or Claude use in order to predict the next token. We use that same methodology to predict items or things that people would want to view." The shift moves model parameter counts from tens of millions or hundreds of millions into single- and double-digit billions . That makes the inference infrastructure fundamentally different : GPU-based compute, specialized inference chips distinct from training hardware, and architecture designed specifically for fast serving. Surajiwale expects that within one to two years, every company doing recommendations will have at least invested in this approach, if not shipped it. Long-term meets short-term at the buyer profile Etsy's recommendation challenge illustrates why the shift matters for production systems . The marketplace carries handcrafted inventory that buyers often do not know exists. Effective recommendation requires understanding not just what someone searched for in the current session, but their long-term aesthetic preferences, purchase history, and latent interests. "It's actually a very difficult problem," Surajiwale says. "The better buyer profile that we can have, the better we can do proactively suggesting things that you didn't even know you wanted or didn't even know to search for." His team models long-term and short-term intent separately, with distinct models contributing to the final ranking. Feature freshness matters, but not uniformly: some signals need real-time updates while others can refresh weekly or monthly. "Any amount of feature drift is potentially a missed opportunity," Surajiwale says. "But not everything needs to be refreshed immediately." Migration only makes sense when it enables the impossible Surajiwale applies the same pragmatism to infrastructure decisions. When evaluating whether to migrate from a proven database to a vector-oriented system, the bar is not marginal improvement. It is whether the new system enables capabilities that are technically impossible on the current stack. "The return on investment can't just be that it makes the existing system a little bit better," Surajiwale says. "It needs to allow you to build new capabilities or features that your current system doesn't allow because of a technical limitation." Vector databases designed for scalable embedding search and approximate nearest neighbor retrieval clear that bar for retrieval-augmented generation use cases. Incremental speed improvements on existing workflows do not. The constraint that determines whether the generative recommendation paradigm reaches production is not model quality. The models already work. It is whether the inference layer can serve them at production scale, at production latency, at a cost that the business can sustain. "You can have the best model architecture," Surajiwale says. "But if you can't serve it at scale in production , then it's not going to work. Models have always been limited by infra."

## Green Dashboards, Red Outcomes: How XLAs Fix The Gap Between SLA Compliance and Business Success
URL: https://www.thedatawire.com/news/slas-xl-as-business-outcomes-paul-neuman
Published: 2026-07-06T15:18:56.844Z
Section: Leadership
Summary: Paul Neuman, Founder and Head of GTM Services at IT Services Demystified, explains why the industry's most common performance metric is also its most misleading, and what it takes to close the gap between technical delivery and business outcomes.
Full text:
SLAs were built to measure whether a provider held up its end of the deal. By that standard, most providers are doing fine. The problem is that technical compliance and business success aren't the same thing, and the contract rarely accounts for the difference. When the metric is uptime but the pain is a broken workflow, the agreement becomes a watermelon: green on the outside, red on the inside. As enterprises shift to consumption-based models and layer AI into service delivery, the gap between technical metrics and business outcomes is getting harder to ignore. A service can be available, a model can respond, a platform can be running. But if the business process broke, the agreement didn't do its job. Paul Neuman is the Founder and Head of Go-To-Market Services at IT Services Demystified . He spent more than two decades at HP, has authored two books on IT services contracts and AI governance, and created the Contractual Value Architecture (CVA), a framework for aligning commercial promises with measurable business outcomes. He has previously discussed how service agreements are evolving from technical checkboxes to business risk mitigation. On a recent episode of the The Data Wire: Beyond the IT Headlines podcast, SLAs, XLAs, and the Watermelon Dashboard: What Boards Must Ask Their IT Leaders , Neuman outlined why the metric enterprises rely on most tells them the least about whether the business actually succeeded. The operational floor SLAs aren't going anywhere, and Neuman is clear that they shouldn't. They remain essential for measuring response time, escalation paths, operational baselines, and supplier accountability. The problem is scope. "We usually use SLAs as proof of business value," Neuman said. "They are not designed for that." An SLA measures whether a provider delivered on a technical promise. It says nothing about whether the business outcome was achieved. The distinction sharpens in the cloud. A hyperscaler can guarantee 99.99% availability, but that guarantee covers the infrastructure layer, not the application running on it. Recent cloud outages have demonstrated how a single provider failure can cascade across an entire ecosystem, costing enterprises billions even when individual component SLAs were technically met. Neuman pointed to a failure on his own assessment application as a practical example. "My website was working. The internet was working. But my customers were not able to run their assessment," he said. "That's where the difference really is important. Making the distinction between the SLA and the XLA ." The gap comes down to measurement vocabulary. Every organization tracks KPIs. Almost none track what Neuman calls KBIs, or key business indicators. "Everybody's talking about KPI, but nobody talks about KBI," he said. "That's probably what's missing. That's where the disconnect is." Without a metric that connects technical performance to business impact , the dashboard can stay green while the business bleeds. When green means red Experience level agreements are designed to close that gap. Where SLAs measure whether the provider met a technical threshold, XLAs measure whether the service actually mattered to the business. The concept originated as an internal counterpart to Net Promoter Scores: a way for IT to understand how users experience the service, rather than relying on operational metrics that can create the appearance of control without changing underlying behavior . But Neuman draws a hard line between useful XLAs and surveys. "A useful XLA has to be tied to a real workflow. It must trigger governance action when it goes red. It must trigger investigation when it becomes yellow. If you can't act on an XLA, what you're doing is a survey." He used the Amazon purchase experience as an illustration. The XLA isn't whether the site is up. It's whether a customer can complete a purchase end to end, in a reasonable time, securely. That's the difference between measuring availability and measuring business function. The end-to-end view introduces its own complexity. When multiple suppliers each handle a slice of the delivery chain, each one can report green while the total experience is red. A printer fulfills the order on time. A shipper delivers within their window. But the customer waited too long and the NPS is negative. "That's the perfect example of the watermelon dashboard," Neuman said. "It might be red end to end, even though some slices are green." The goal, he stressed, isn't to replace SLAs with XLAs. "Both have their own use and their own usage." The point is to connect them. The partnership bible Connecting them requires contractual architecture, and Neuman sees the contract itself as the most underused tool in the vendor-customer relationship. He calls it the partnership bible: the mechanism that aligns what the client expects with what the supplier can deliver. He developed his Contractual Value Architecture framework specifically to explain how a strong contract can still fail in execution when governance, accountability, and escalation paths aren't designed into the architecture from the start . The failure mode he sees most often is absence. "You cannot imagine the number of customers who told me, 'I've been working with this supplier, and then I had an escalation and I didn't know how to handle it,'" Neuman said. "Why? Because it was not in the contract." Clear RACI assignments, defined swim lanes, and documented escalation procedures aren't optional governance overhead. They're the structural prerequisite for making accountability operational rather than aspirational . The correction happens in the quarterly business review. Neuman sees the QBR as the point where the supplier's view and the customer's experience get reconciled. The supplier should ask whether they helped the client achieve their goals. The client should surface new needs and flag where perceived value has drifted from the original business case . "That's where you can realign," Neuman said. "The contract is a partnership bible, nothing else." Running a contract without these conversations, what he called operating on "free will," is the fastest path to failure. The most successful contracts he's signed, out of close to 200 over his career, had one thing in common. "I was able to sit with my account execs in front of the customer, in front of the C-level, in front of IT, and say, 'What did we do right? Where did we fail? Having that open and honest conversation really helps both sides improve, make things better, run more smoothly, and at the end of the day, make the business achieve their goals more easily," said Neuman.

## Healthcare's 'Silos of Silence' Are The Biggest Barrier To Clinical AI At Scale
URL: https://www.thedatawire.com/news/clinical-ai-data-fragmentation-shammy-narayanan-welldoc
Published: 2026-07-06T15:18:56.844Z
Section: AI
Summary: Shammy Narayanan, SVP of Data, AI, and Platform Architecture at Welldoc, explains why clinical AI depends on breaking down the data silos that leave half of healthcare's information stale, fragmented, or inaccessible.
Full text:
Healthcare generates mountains of data, yet the systems holding it fundamentally fail to communicate with one another. Instead of waiting for a universal standard that may never arrive, the industry is turning to AI orchestration layers to act as real-time translators, bridging the legacy platforms, inconsistent taxonomies, and fragmented records that leave roughly half of healthcare's data stale or inaccessible. Shammy Narayanan is the Senior Vice President of Data, AI, and Platform Architecture at the healthcare tech provider Welldoc . He has spent 25 years moving artificial intelligence from concept to production across the healthcare and BFSI sectors. Today, he leads executive AI experimentation and clinical operations, focusing on how clinical AI can serve as a translation layer for systems of record that don't speak the same language. On a recent episode of the Beyond the IT Headlines podcast, Welcome to the Agentic Era: Healthcare's Next AI Transformation , Narayanan outlined what that translation layer looks like in practice and where the technology is heading next. More inputs, more confusion The scale of the disconnect starts with something as basic as a blood pressure reading. A single patient might register a reading on a home app, take another at a pharmacy kiosk, and have a third recorded in an electronic health record, all within a span of two hours. "Which is the right source of truth? We don't know," Narayanan said. Blood pressure alone can be represented in four different ways within a single healthcare system, and much of the data underpinning clinical decisions still hasn't made the leap to digital. "Some of this data we're talking about is still on paper, which has to be converted into a digital format through OCR," he explained. Even where digitization has occurred, legacy platforms carry significant technical debt, and the explosion of consumer IoT devices has compounded the problem. As wearables, pharmacy kiosks, and clinical instruments all generate readings for the same biomarker, each source creates its own version of the truth. Without a strategy for aligning fragmented data sources , more inputs often mean more confusion. "The systems don't speak the same language. You need an orchestration layer to convert and map the data so it all aligns," Narayanan said. "Today we're in silos of silence where you have data that is either too vast, fragmented, or unavailable. And even if it is available, it doesn't talk to each other effectively." From ambient scribes to agentic workflows Breaking through that fragmentation requires more than better integration. Narayanan outlined a three-stage progression that moves clinical AI from a documentation tool to an autonomous care coordinator. The first stage— ambient scribes —is already in production. These systems listen to patient-physician conversations and generate clinical notes in real time, freeing up face time for actual care. "The system is not new. But its accuracy has gone up, its efficiency has gone up, and that will continue to happen as the models progress." The second stage is multimodal reasoning. Rather than analyzing a single data source in isolation, multimodal AI synthesizes inputs from across the patient's ecosystem, including imaging, wearable data, activity patterns, and genomic profiles. "Am I just reading your X-ray? No, I have access to your Fitbit, so I can understand your activity pattern," Narayanan explained. "Can I combine all this information and make a very accurate judgment far better than what we used to do in the past?" This kind of cross-system synthesis is already reshaping how organizations think about data pipelines , though healthcare's regulatory and interoperability requirements make the implementation uniquely complex. The third stage, and the one Narayanan sees arriving before the end of 2026, is agentic AI . In this model, AI agents don't just analyze data. They act on it. An agent reads a patient's treatment plan, schedules physician visits, communicates with pharmacies about prescriptions, and handles medication adherence follow-ups. "Earlier we used to do all this as a point solution," Narayanan said. "Now I'm going to look at it in a comprehensive way." The regulatory green light Moving these capabilities from pilot into production requires regulatory backing, and the FDA has been adjusting its guidance to keep pace. Narayanan pointed to several 2026 regulatory changes that signal a meaningful shift in how the agency views clinical AI, with the most significant involving diagnostic confidence. Previously, even when an AI algorithm was highly certain about a patient's condition, it was required to present multiple possible diagnoses. That requirement has been relaxed. If the system can explain its reasoning, it can deliver a single conclusion. "If you are very clear, just say 'this is what it is,' as long as you're able to explain it," Narayanan said. "The algorithm should be able to explain how it arrived at this conclusion." The changes extend to emergency care and consumer devices. In critical situations like emergency triage, AI systems can now bypass traditional human review requirements, provided the algorithm is classified as a high-risk medical device and can document its reasoning. "There is a critical condition where you don't have time. You can depend on the AI as long as that explainable AI is there," he explained. Meanwhile, consumer wearables like the Apple Watch and Oura Ring can now cover a broader range of health factors, including glucose trends and blood pressure, as long as they stop short of definitive diagnostic claims. "It can give you trends, it can give you insights. Still, a physician has to confirm it. But they have expanded that ambit." Taken together, the regulatory direction suggests that the era of treating clinical AI purely as a risk factor is giving way to a framework that views it as a capable copilot for clinical decision-making. Care without the calendar The convergence of better data infrastructure, multimodal reasoning, and regulatory flexibility opens the door to a fundamentally different model of chronic care. Narayanan describes a near-future scenario in which AI copilots manage the daily routines of patients with conditions like heart failure and diabetes, and some components are already technically possible. Using AI-enabled smart glasses, for instance, a patient could look at a restaurant menu and receive real-time guidance calibrated to their caloric intake and medication schedule. "That recommendation will come to you in real time as you look at the menu," said Narayanan. The broader industry is already moving toward ambient, personalized health guidance , suggesting the vision isn't as far off as it sounds. But the most consequential shift may be in how patients interact with the healthcare system itself. Today, physician visits are scheduled on fixed intervals. 'Come back in a month.' 'Come back in a quarter.' Narayanan envisions a model where that cadence becomes event-driven rather than time-driven. An agent from the patient's side continuously shares data with an agent at the physician's office. If everything looks good, the visit gets deferred automatically. If something looks off, the system flags it. "You're not even involved here," he noted. "There's an exchange of information, data-driven decisions are made, and you're free to do what you're doing unless the AI decides otherwise." Further out, the same data infrastructure could enable digital twin simulations for individual patients, allowing organizations to simulate treatments against a digital replica of the patient's unique biomarkers rather than relying on real-world trial and error. "With the digital twin, we will be able to make more accurate predictions." The same approach could compress drug discovery timelines for rare diseases, where small patient populations have historically made R&D economics prohibitive. "It will create an equalizing field where even rare diseases can be addressed with the same efficiency as common diseases today," he said. The infrastructure challenges between here and autonomous care copilots are real, but the building blocks are coming together faster than most observers expected. For Narayanan, the trajectory points toward a healthcare system that finally treats its data as a connected asset rather than a collection of isolated readings. "Prescriptive medicine, personalized medicine, is not too far away. Given that each one of us is unique and our biomarkers are unique, why shouldn't the medicine be unique?" he concluded.

## Production AI Demands Statefulness That Might Require a Whole New Approach to the Inference Layer
URL: https://www.thedatawire.com/news/inference-state-management-kv-cache-infrastructure
Published: 2026-07-06T15:18:56.844Z
Section: Future of Data Management
Summary: An Intel AI engineer and the CEO of a YC-backed inference startup are converging on the same conclusion: inference is becoming a state management problem, and the engineering required to solve it has been around for decades.
Full text:
The most widely deployed open-source inference server in production today solved its core scaling problem by borrowing from a 1960s operating system textbook. vLLM's PagedAttention found that inference systems were wasting 60 to 80 percent of GPU memory on fragmentation, and fixed it by treating the KV cache the way an OS treats RAM: partition into blocks, allocate on demand, reclaim what's idle. The insight came from virtual memory paging , not from ML research. That's probably the most useful signal available right now about where production AI infrastructure is actually going. The inference layer was built to be stateless: request in, tokens out, cache discarded. That held for chatbots. It buckles under multi-turn agents, long-context RAG where prefill dominates the inference bill , and real-time voice applications where 200 milliseconds of added latency breaks the product. Inference is becoming a state management problem, and the practitioners solving it are reaching for engineering that predates the models by decades. Vamshi Nagireddy is a Senior Software Engineer at Intel, where he works on AI workload optimization and inference performance across the company's hardware stack. He's published technical deep-dives on vLLM architecture , GPU hardware fundamentals, and KV cache quantization techniques , and to him, the vLLM precedent isn't a one-off. The most consequential architecture decision in modern inference serving was borrowed from OS design, and the engineers who made it were thinking about memory management. "That's the meaningful signal about where the field is headed. The inference problems that matter at scale are systems problems," Nagireddy says. Storage engineering in disguise Teams are conflating two fundamentally different optimization problems, Nagireddy argues, and the confusion is costing them. "Quantization is a representation problem. You're asking how few bits you can use to approximate weights without destroying model quality. It's static, an offline decision." KV cache optimization, he says, is a different animal entirely. "You're asking how to manage the memory lifecycle for activations that are dynamically generated at runtime. There's no offline calibration phase. The pressure is on latency, memory bandwidth, and concurrency." The KV cache doesn't behave like model weights. Weights are relatively stable. Activations drift as context grows, and in RAG settings they're highly input-dependent. Standard calibration techniques assume a stable distribution, and that assumption breaks at exactly the moment it matters most: under long contexts and heavy load. "You need a block allocator. You need reference counting. You need an eviction policy. You need to understand bandwidth characteristics, working set versus cold data." The building blocks, says Nagireddy, are storage engineering. The data just happens to be attention keys and values. Old caching toolkit, new caching contract Traditional database caches operate on byte-level locality. Two queries that access adjacent rows share physical proximity, and the cache exploits that proximity for speed. KV cache access patterns work differently. Two requests that share a system prompt share meaning , not just bytes. Nagireddy argues that this semantic structure is what makes the state management challenge genuinely new, even as the engineering toolbox remains familiar. "Prefix sharing isn't just an optimization hint. It's a semantic property of the data," he says. "The architecture question becomes how you build a cache that's aware of semantic locality, not just byte-level data." That's where concepts like prefix hash trees start to matter, along with eviction policies informed by the model itself about what context it actually needs. The optimization target shifts from "what data was accessed recently" to "what data is semantically relevant to the current computation." The engineering patterns are decades old. The data they're operating on is brand new. "Teams need to stop treating KV cache as an implementation detail inside the inference server and start treating it as an infrastructure component. Something you monitor, something you tune, something you have an operational model for. The same way you have a caching strategy for your database layer, you need an explicit KV cache strategy for your inference," says Nagireddy. He points to where chip manufacturers are placing their bets as further evidence. Nvidia is investing in NVLink bandwidth scaling and high-bandwidth memory . AMD and Intel are doing the same. "The compute ceiling is rising faster than the memory bandwidth ceiling," Nagireddy says. "That imbalance is going to force the software stack to catch up." Orchestration is the last mile If Nagireddy sees the problem from the memory hierarchy up, Arko Chattopadhyay sees it from the customer deployment down. As Co-Founder and CEO of Pipeshift , a YC-backed startup providing managed inference infrastructure for real-time AI workloads, Chattopadhyay works with production teams whose inference costs and latency SLAs show up on the P&L. "Orchestration is the core problem here. A much bigger bottleneck than people understand today," Chattopadhyay says. He compares it to logistics. "Everything can be great, with nearly everything solved. But if the last mile isn't solved, consumers aren't happy." That last mile covers a sprawling surface area: capacity management across multiple cloud providers, cold start optimization, disaster recovery pools, distributed proxies that keep routing within the same region as the deployment, and shared KV cache pools across scaling replicas so that adding a new node doesn't mean warming up the cache from scratch. Real-time workloads multiply every one of these problems. "You won't see a 200-millisecond increase in latency if it's not a real-time use case," Chattopadhyay says. "As soon as you move to real time and it's a voice agent or code generation where you're rendering React components, you notice that difference." Add spiky usage patterns that shift from morning to night, and the challenge compounds further. Chattopadhyay sees a market shift underway. For the last two years, most teams accepted whatever SLA their inference provider gave them. Now the conversation has flipped. "We're seeing companies say, 'We do not want to deliver the SLA to our end customer that our inference provider is giving us. We want to deliver an SLA to our end customer and we need an inference provider that can orchestrate the infra toward that.'" That shift moves inference from a commodity API call to a state management problem teams need to own. When the model disappears That kind of shift doesn't happen in a vacuum. Real incidents are driving it. Chattopadhyay describes a customer who came to Pipeshift after a model deprecation went wrong. OpenAI has retired more models in 2026 than in all prior years combined , and the pace has caught teams off guard. "They didn't miss the deprecation notice," says Chattopadhyay. "They worked on it. They literally pushed their sprints for two weeks to move between model versions. But they ended up not integrating it in one piece of the product, and that went down the next day when the deprecation happened." The fallback strategy most teams rely on, routing to a different model when the primary one disappears, doesn't actually solve the problem. "Swapping the model means new prompts. Swapping the model means quality differences. Swapping the model means different performance numbers," Chattopadhyay says. He calls model fallbacks "a band-aid for a bullet hole." That fragility, combined with unpredictable cost growth as inference spend climbs faster than revenue , is pushing production teams toward dedicated deployments on open-source models. Chattopadhyay estimates that 80 to 90 percent of most teams' workloads can run on open-source at lower cost and with controlled SLAs, leaving only a thin edge-case layer on frontier models. The metrics gap that keeps teams guessing The most surprising thing Chattopadhyay encounters when onboarding new customers is a visibility problem. Teams that spent two years building sophisticated eval frameworks to measure model quality have almost nothing equivalent for their inference infrastructure. "The most common thing we see is they don't know what their P90 usage is like, what their P99 usage is like," Chattopadhyay says. "How does their workload pattern shift through the day? Do they have cache metrics? How much of their input is actually being replicated across queries?" Chattopadhyay frames the gap as a maturity problem the industry hasn't reached yet. "People had to spend two years burning their hands to get to a point where everybody has their own harness, everybody is building their own eval frameworks. This will be two more years of work for people to understand that they have to track all of these metrics on the infra layer." When he does get a customer who has invested in inference observability, the onboarding is dramatically faster. "I take all of this data, go back and benchmark different GPUs and models, and I'll exactly know what to give them," he says. "When they don't have it, it becomes a test cycle." The next inference server holds state Nagireddy doesn't hedge on what comes next. "The inference server gets rebuilt first," he says. "And it's already starting." Current inference serving systems, vLLM and TensorRT-LLM included, were designed with the assumption that KV cache is ephemeral and local. It lives on the GPU. It dies with the request. That assumption, Nagireddy argues, is now "load-bearing in the wrong direction." Production demands state persistence, prefix sharing across requests, and cache-aware routing. None of that bolts onto a system that was never designed to hold state. "I think we'll see a new generation of inference servers in coming months that looks much more like a database runtime than a model serving framework," Nagireddy says. Serving logic and memory management become equal concerns. Routing becomes a data locality problem: send the request to the instance that already has the relevant prefix cached, rather than round-robin load balancing across nodes that each start cold. The orchestration layer , whether Kubernetes or a custom scheduler, currently has no visibility into KV cache state when making those decisions. That has to change. Nvidia is already treating this as a product requirement. At GTC 2026, the company announced CMX, a context memory storage platform that introduces a new storage tier between GPU memory and traditional network storage, built specifically for persisting KV cache and agent state across inference sessions. The shift Nagireddy describes isn't speculative. The largest chip company in the world is building infrastructure around the assumption that inference state needs to survive the request that created it. "The team that wins in this space comes from someone who deeply understands storage systems, distributed systems, distributed caching," he says. "Someone who built a CDN, who looks at the problem and says, 'This is actually a solved problem. We're just applying it to a new data type.'" The inference layer was designed to be stateless. Production AI demands state. The engineering required to close that gap is the oldest kind of infrastructure work in the stack, applied to the newest data type the industry has ever had to serve.

## Industrial Leaders Turn Unified Data Pipelines Into A Scalable AI Advantage Across Plants
URL: https://www.thedatawire.com/news/industrial-ai-unified-data-jan-hoscan-everpure
Published: 2026-07-06T15:18:56.844Z
Section: Future of Data Management
Summary: Jan Hoscan, VP and Head of Industrial at Everpure, argues that industrial AI succeeds or fails on whether companies can turn fragmented IT and OT data estates into unified, governed, AI-ready infrastructure.
Full text:
Industrial companies are pouring money into AI models and GPU clusters, then watching much of that capacity sit idle. The reason is rarely the algorithm. It's that manufacturing, R&D, operations, and enterprise IT have grown up as separate data estates that don't talk to each other, and AI cannot run at scale on top of that fragmentation. The work of unifying those estates is what now separates the industrial firms pulling ahead from the ones falling behind. Jan Hoscan is Vice President and Head of Industrial at Everpure , where he leads strategy across automotive, manufacturing, energy, and process industries. His career spans general management, engineering, and dealmaking roles at Intel, Intel Capital, Red Hat, and Everactive, giving him a view of the industrial stack from both the technology and the investment side. He sees the convergence of information technology and operational technology as the defining shift of the moment. For most of industrial history, every use case carried its own bespoke or segregated stack. Hoscan argues that AI is forcing those walls down because machine learning only works when the data underneath it is unified. "There is a great convergence to take advantage of the AI and machine learning and analytics emergence, because that requires unifying the data lakes, creating a single data plane, a single control plane, a single data pipeline," he says. He maps the territory across five domains, from product engineering and validation through autonomous-driving data pipelines, smart-plant architecture, enterprise IT, and the cross-domain analytics layered on top. Each plant, in his framing, is a mini enterprise, and the push toward unified architecture is what lets all of them feed the same models. Data as the bottleneck The industry's attention is misallocated, in Hoscan's view. Teams obsess over algorithms while the constraint sits upstream in how data is stored, moved, and prepared. "The real bottleneck is data. It's not the algorithms," he says. The consequences are expensive. Fragmented storage and weak throughput starve the most costly assets a company owns. "If you can't process and present your data fast enough to the GPU clusters, you're not training your models effectively," he says, describing farms worth hundreds of millions of dollars left half idle while they wait to be fed. Engineers stall the same way, sitting on their hands while a simulation finishes before they can resume work. Fragmentation also widens the attack surface . Hoscan points to the ransomware attack that halted a major UK automaker for weeks, an incident later estimated to have cost the broader economy billions , as what happens when OT and IT stacks are too splintered to patch effectively. Cost compounds it from a third direction. As data volumes explode, storage, egress, and GPU fees can become the second-largest line item after salaries, a pressure that mirrors the broader race to scale compute . Governance, non-negotiable Before any of this scales, Hoscan insists governance be treated as foundational rather than an afterthought. Without a verifiable chain of custody, the data feeding a model cannot be trusted. "If you don't have a strong chain of custody in your data, your data quality cannot be guaranteed. As a matter of fact, it may even be corrupted," he says. Feeding raw or uncontrolled data into a model risks poisoning it, while careless labeling can bake in bias that changes how the system behaves. The discipline spans provenance, authorization, labeling, curation, storage, and protection, and it has to be enforced from day one, an approach consistent with how others frame automated data governance for AI . "You can evolve it, but it needs to be based on enforced rules." One lighthouse, then scale The execution failure Hoscan sees most often is ambition without structure. Large enterprises run hundreds of disconnected pilots and call themselves AI-forward, when they're really experimentation-forward without selection criteria. "You need to have one ambitious but well-scoped lighthouse initially. Don't try to boil the ocean," he says. The pattern he advocates is a single cross-functional use case built with expansion in mind, then standardized into repeatable AI pods, units that bundle hardware, software, pipelines, and models, with governance and cyber resilience built in. The harder discipline is pace. Pin a decision today, and the technology may shift in six months, so an organization's architecture has to absorb improvements continuously, which Hoscan calls moving at the line rate. Lag too far, and the frontier pulls away. Chase it constantly, and nothing gets proven, a tension visible across the intelligent industrial operations shift now underway. That balance is the real test of industrial AI maturity. The companies that endure, Hoscan argues, will be the ones with the discipline and the balance sheet to keep unifying their data while staying close to the frontier. The rest face a harder fate. "Those who don't either are going to fall behind and become uncompetitive, or they're simply not going to exist in a few years."

## Sovereign Compute and Shadow Grids Reshape Where AI Workloads Actually Run
URL: https://www.thedatawire.com/news/ai-growth-constraints-data-energy-sovereignty-abdulkader-khouja-artefact
Published: 2026-07-06T15:18:56.844Z
Section: AI
Summary: Abdulkader Khouja, Data Engineering Consultant at Artefact, on how enterprises are confronting the physical layer beneath AI.
Full text:
The cycle of AI adoption that followed the pandemic was built on the assumption that compute and models would do the heavy lifting. That assumption is breaking in three places at once. Enterprises are finding that their data is not clean enough to feed the models they've already bought. Data centers are running into hard energy limits that have halted projects, raised electricity prices, and triggered community pushback. And the strategic value of data has climbed high enough that data center placement is now a sovereignty question rather than a cost-and-latency question. At the center of these challenges is Abdulkader Khouja , a Data Engineering Consultant at Artefact , where he advises enterprise clients in the UAE on data engineering, data quality, and analytics infrastructure across finance, securities, and government. His career bridges supply chain analytics, financial reporting, and large-scale data engineering, with hands-on experience across SAP, Informatica, Microsoft Purview, and modern cloud data platforms. That practitioner view shapes how he interprets the current moment, where the deployments succeeding are those with the cleanest foundations. "The real bottleneck isn’t the model anymore. It’s whether the underlying data is usable," he says. The remediation work must happen because the alternative is worse. AI scales whatever foundation it sits on, and a contaminated foundation produces contaminated answers at machine speed. Data quality is the first constraint The pattern Khouja sees across his UAE clients is consistent. After the generative AI bubble drove a wave of model investment, organizations discovered that their data could not support what they had bought. "After COVID, everybody started building models, and this ended with generative AI. After that, customers started seeing a trend in data quality itself. Now all the clients we are working with in the UAE are building first under data quality." Informatica and Microsoft Purview are being used to set explicit rules, scores, and remediation workflows that establish what good data looks like before pipelines move it downstream. "We're setting data quality rules and scores, and those columns must not be empty," he explains. "They must be the same data type. People are not careful about data, so we have to do data remediation before going to data engineering." That sequencing matters, Khouja says, because data engineering teams that skip remediation end up automating the dysfunction. The cost of cleaning bad data after AI has propagated it across an organization is dramatically higher than cleaning it beforehand. Energy is becoming a hidden design input The second constraint operates one layer down, at the compute infrastructure that data quality work eventually feeds. Energy shows up inside enterprise data teams indirectly, through resource decisions no one frames as energy-driven. "When we, as data teams, request increasing cluster memory or timeout, a lot of those requests come back with reduction because we don't have memory. Data teams are not being told directly that this is an energy issue, but you can see that through rejection of requests," Khouja shares. The scale that makes those refusals routine is significant. Khouja's current UAE engagement involves thousands of tables, with individual tables running 1.9 to 2 billion rows. The short-term enterprise response is data pruning. Teams are no longer processing every column by default, which compresses compute load and energy draw simultaneously. "We must not pick all the tables or all the columns and fields. We must pick the important columns we are using and process them to save on resources, time, requests, and timeouts." Hyperscale data centers are running into hard limits The supplier side of the same problem is more visible. AI's energy demand has outpaced grid capacity in multiple regions, and projects have stalled. "The most famous example was the Jupiter data center in the UK, halted by OpenAI because of the energy issue," Khouja says. "In Singapore, data center consumption is expected to reach 20 percent of the grid, and that's leading electricity prices higher. Some communities are leading marches against data centers . We've seen that in the USA." The hyperscaler response is to bypass the grid entirely. Khouja describes shadow grids, dedicated energy plants attached to specific data center campuses, built to provide power directly to hyperscale workloads outside the regulatory framework that governs shared grid consumption. "They're called shadow because they are not legalized yet. Their consumption will not follow the same rules as on the grid. We will need new regulations, especially in the USA, in one to three years," he asserts. The same pressure shows up in unusual procurement patterns. Microsoft is sourcing 2.5 megawatts of energy from Chevron for specific data center workloads, and the corporate ESG commitments that defined the prior decade are being deprioritized as the competitive stakes overtake them. "Spend on AI and data centers is expected to be $3 trillion by 2030, and the economic value will be $30 trillion. Those companies know this is a historical opportunity, and they were ready to sacrifice some of their environment-friendly policies." Sovereignty is rewriting where data centers get built The third constraint is political. Data has crossed from operational asset to strategic infrastructure, and governments are treating data centers the way they once treated oil refineries. "During the Iran war, Iran started threatening to hit data hubs," Khouja says. "Everybody knows now, data is an important asset." The institutional response has been to localize. Khouja describes working near server rooms at the Abu Dhabi Securities Exchange that no one, including the CEO, could enter without clearance. The same impulse is driving sovereign-compute product launches, including Microsoft's Azure Local services, which let governments download models to their own infrastructure rather than upload sensitive data to public cloud. National infrastructure projects are shifting in the same direction. Khouja notes that Saudi Arabia's NEOM has been subtly transformed from a futuristic city concept into a major data center initiative. The location independence that defined cloud computing for fifteen years is being unwound in favor of localized control. "Data is not location independent anymore. It's not about latency. It's about having our own data infrastructure, because this is the future." Quantum is the long answer, but 2026 is about the foundation The supplier-side response to all three constraints is to leap forward at the compute layer. Google's Willow quantum processor and Microsoft's Azure Quantum Development Kit signal that the hyperscale providers see quantum as the layer that eventually relieves the pressure classical compute cannot. For enterprises, however, that future is not the work of 2026. "This is how it will get solved. In the short term, from the consumer side, they are processing only the important data attributes. On the supplier side, for the long term, they are preparing for faster technologies for compute, which is quant," Khouja says. "In five years, quantum compute will be the norm."

## Enterprises Lead The Next Phase Of AI By Squeezing More From Existing GPUs
URL: https://www.thedatawire.com/news/ai-control-plane-gpu-efficiency-enterprise-bijit-ghosh-atlas-cloud
Published: 2026-07-06T15:18:56.844Z
Section: AI
Summary: Bijit Ghosh, board chair at Atlas Cloud, made the case for a control plane that coordinates compute, memory, and data over the systems enterprises already run.
Full text:
When companies moved AI agents into real production work, the agents quickly overwhelmed infrastructure that was never built for them. A single employee could have five or 10 agents running at once, each one firing off far more requests than a person ever would. Servers tuned for steady, human-paced traffic buckled, response times slipped, and the GPU bill climbed. By the time most teams noticed, the systems running beneath the model had become the bottleneck. It was the kind of breakdown Bijit Ghosh spent much of his career watching unfold. The Chair of the Board of Directors at Atlas Cloud , a model-agnostic AI cloud built for high-trust industries, he formed his view of enterprise AI over two decades in financial services. He's an Advisory Board Member for Kubex, the operating layer for accelerated computing that turns efficiency, performance, and reliability into a continuously self-optimizing control loop where AI agents optimize AI infrastructure at scale. He previously led AI, cloud, and data platform engineering as a managing director at Wells Fargo, served as a global cloud and AI/ML CTO at Deutsche Bank, and helped run payments technology at BNY Mellon. From that vantage point, he kept returning to one conclusion about where the answer actually lay. "The real problem is getting better yield and efficiency out of the infrastructure you already own," Ghosh said. Paying for idle GPUs For years, the hard part of AI was training, the work of gathering enough compute to build a model in the first place. That has changed. The bigger cost now is inference , the day-to-day work of running models in production, and agents run it constantly, often several calls deep for a single task. That load looks nothing like what most infrastructure was built to handle, and the gap shows up first in the economics. Companies wait months for new GPUs and pay a premium for the ones they secure, yet those machines run far below capacity, with average use across enterprise fleets in the single digits. The shortage is genuine, but distribution matters just as much. Firms pay for compute that sits largely idle, unable to route enough work to it. That allocation problem comes down to scheduling. Older systems hand out compute in fixed blocks, an approach that works when demand stays steady and a job either runs or it does not. Agent traffic behaves the opposite way, spiking and dropping minute to minute, and fixed scheduling cannot keep pace. "Traditional systems like legacy applications and relational databases such as Postgres rely on static Kubernetes or bare-metal scheduling. As you move to the top of the stack where we need everything in real time, our traffic patterns are changing because now we have dedicated agents running," Ghosh said. The goal was to release compute as fast as the agents consumed it. The context tax Allocating compute well goes only so far. A large share of the spend covers work the system has already done. Anyone who runs an AI coding assistant hard has seen the pattern. A few hours into heavy use, the tool warns that the token allowance is almost gone. The remedy sat one layer above the model. "Every time an engineer or a product team opens a tool like Codex or Claude Code, it starts the interaction from scratch. The cache logic has to change. With KV-cache reuse, we absorb context across sessions so it isn't reevaluated from the beginning, and we can route to the model with the lowest cost per token," Ghosh said. Caching lets the system hold onto context instead of recomputing it for every request . The harder problem is getting the right context to an agent in the first place, and that grows tougher when one job is split across several agents. "The whole economy of context comes down to one thing. Better context produces a better answer. In our SDLC, separate agents handle PRD reviews, writing code, and testing, and each works across a different context. As the work changes in the system of record, we have to refresh that context to keep them current," Ghosh said. Postgres holds the line That system of record was usually Postgres, the relational database that quietly ran a large share of enterprise workloads and stored a company's most sensitive data. Decades of hardening had made it reliable and exact, the reason so many companies built on it. The trouble was that agents had started asking it to do a different job. "As you're scaling AI workloads that need more semantic search, embeddings, long-context memory, and real-time retrieval with agent reasoning, Postgres cannot extend to that functionality. That's the bottleneck," Ghosh said. The reflex was to solve it with a migration, swapping the old database for a newer platform built for AI. Ghosh pushed back on the idea. Tearing out a working system carried enormous risk, and most of what made data useful to an agent did not require moving it at all. "As long as you have the data product defined, it supersedes what is needed as part of your layer stack. So rather than completely restacking and moving Postgres to a shiny lakehouse, we need to find a hybrid model where Postgres and unstructured data are working cohesively, simultaneously, as a runtime layer," Ghosh said. The better path left the database in place and built around it, adding a layer that handled semantic search and retrieval while the original system kept doing what it did well. The data stayed trustworthy and became usable for agents at the same time, without betting the business on a rebuild. The case for a control plane Each of those fixes solved one piece of the problem. Tying them together called for something new. Ghosh called it a control plane, a single tier that sits over the whole arrangement and separates the systems that store the truth from the systems that act on it. "The good architecture should be a distributed architecture where we have a system of record, but at the same time a system of action. We have an AI data layer where we are doing constant retrieval, and we have a harness where the mechanics of combining memory, inference, optimization, and orchestration with your agents all work in a cohesive form," Ghosh said. The point is to take the moment-to-moment decisions off human operators. Instead of engineers adjusting each part by hand, the system makes those calls itself, keeping data, compute, and context aligned as the work shifts underneath it. The control plane is becoming a permanent tier of the stack rather than a temporary fix that folds back into the database over time. As agents multiply and the cost of running them keeps rising, the alternatives are thin. "This control plane logic is already conceptualized in the industry, and it's becoming the platform for coordinating the model, Postgres, context, routing, data locality, economics, governance, and agents . Instead of humans tuning all of it by hand, the control plane bakes everything together," Ghosh said.