There’s no point building your own agentic AI stack for a non-core function when a vendor already has a product ready to go that meets your needs. For non-tech companies in particular, building from scratch can take time, money, and expertise they don’t have.

Take for example, Fertitta Entertainment, with more than 600 Landry’s restaurants and the Golden Nugget hotel and casino. After the pandemic, the company had problems adequately staffing its call centers, says its director of contact center operations Brian Jeppesen. “The agents didn’t want to come back,” he says.

The virtual assistants didn’t work because the user experience was bad, and with the incoming call volume, 40 to 50% of them were abandoned.

“Everybody wants AI, but nobody wants BS,” Jeppesen says. “I talked to my CFO. This is what we’re abandoning. This is the potential revenue we’re losing. I can’t throw bodies at it anymore.”

Agentic AI has upped their game for the virtual assistants. Instead of only answering simple questions like check-in hours, it allows the company to connect APIs and carry out more complicated tasks, like making reservations.

“My abandonments fell to under 10%,” says Jeppesen. “From waiting 45 minutes to an hour, they can get their questions immediately answered, or immediately transferred and taken care of.”

And turnover went down. Call centers typically see 100% turnover, says Jeppesen. Not because everyone quits, but because the bottom 25% quit and need to be replaced over and over again.

Now that bottom tier doesn’t have to be rehired, while the people who stay are the most knowledgeable. “They give a better experience for my customers,” he says. “And it reduced my attrition by 50%.”

Forrester did a total economic impact study for the specific vendor that Fertitta used, PolyAI, and the ROI came back at 391% over the course of three years, with a payback period of less than six months.

Jeppesen says he reviewed his own numbers and found that the automated reservations system alone brings in 3,000 reservations a month. “That’s $600,000 in revenue a month for us without the need to speak to an agent,” he says.

Next, Fertitta plans to expand it to handle to-go orders and web chats. There are also opportunities for agentic AI on the technical help desk, Jeppesen says.

Agentic AI on the menu

Fogo de Chão, a Brazilian restaurant chain with around 120 locations, is also deploying agentic AI in small, focused use cases, and sees ROI with some of the projects.

For instance, it deployed virtual call center agents from PolyAI, and saw positive ROI from day one since there were no significant up-front costs or usage-based pricing. After several months of testing and small-scale pilots in 2025, the system has been rolled out across the US, with 100% of calls now being answered instead of up to 25% being dropped, and a 10% increase in total bookings that wouldn’t have happened otherwise, says Michael Breed, the chain’s chief marketing officer.

“If we compared it to a media channel, it’d be twice the ROI from other media channels,” he says. “It’s almost like another customer acquisition vehicle.”

The company is also building agentic workflows for its team members.

“We’ve identified jobs that are very repeatable and time-consuming, and we’re training agents to take those tasks,” he says. These are low-risk jobs, like proofing menus or other text, or replacing manual processes, such as pulling data from one system into another that had no automatic integrations.

“The agent does a great job bringing in the data, then the human in the loop can inspect it,” says Breed. “Is it getting classified right? Is it getting to the right places? And when guests are dissatisfied, can we make it better?”

Built for SMBs

For smaller companies in particular, off-the-shelf agents make the most sense. AltaClaro, for example, builds training simulations for lawyers, and counts more than 100 of the top 200 US law firms as customers, all with just 10 employees.

One product is a deposition simulator, says CEO Abdi Shayesteh, a completely agentic, voice-based platform.

“It’s a fully simulated environment that creates the experience of doing the deposition,” he says. “Different agents play the role of the witness, opposing counsel, and the court reporter.”

He says it’s kind of like a Zoom call. The product is built on top of technology from Verbit, a legal tech company with a custom agentic platform.

“They’re taking care of the technical infrastructure and we have the material to ground the AI.”

A different vendor, Credal, provides a secure AI platform that allows AltaClaro to switch between different models. It can obfuscate names and keep other sensitive data from leaking out, Shayesteh says. “It ensures everything is anonymized and does secure calls,” he says. “We standardized on Credal because it’s highly flexible and secure. We serve law firms and we’re as invested in security as they are.”

But security isn’t the only issue that enterprises face when deploying agentic AI.

The hidden costs of buying AI

The temptation to jump into agentic AI is high, says Dana Simberkoff, chief risk, privacy, and information security officer at AvePoint Inc., a data security company. And off-the-shelf agentic AI can be so easy to adopt that companies deploy it before they’re prepared for it.

Enterprise vendors will often add the technology at no extra cost, just to get people using it, and companies turn it on for their employees before truly understanding what it does, and before systems and workflows are ready. “Then it immediately exposes problems that were already there,” she says.

Say, for example, an agent helps with research, normally considered a low-risk task.

“AI will follow sharing links across documents,” she says. “So if you haven’t taught your users how to properly use sharing links, the AI agent is just going to follow that path, and it could expose information that might have been obscured in the past. It’ll gobble up everything it can.”

The result is it could expose HR data, personal information, or proprietary information to people who shouldn’t have access to it. One company she knows had to shut down their AI project immediately and go back, classify, and label all their information, put governance controls in place, and teach people how to apply metadata.

According to Gartner, by next year, 40% of enterprises will demote or decommission autonomous AI agents due to governance problems that only show up after they’ve gone into production.

Token management

Another hidden cost of off-the-shelf AI? Token use. When agentic AI is embedded into a system that a company is already using, then the cost of switching it on can be as low as zero. But someone has to pay for all that token use.

When agentic AI comes out of pilots and goes into production, usage can change dramatically, and token costs can quickly spiral out of control. It doesn’t help that agentic AI use typically requires much more tokens than AI chatbots.

“A lot of the embedded AI should be utilized,” says Doug Vargo, head of the national AI and alliances team at consulting firm CGI. “If big parts of your business processes are living and breathing in ServiceNow, Salesforce, or another application, you should leverage that, but you need to understand the cost.”

This is playing out in the marketplace right now, he adds, as underlying model providers change their token costs.

“That changes the economics of the decisions,” he says. “And six months from now, it’s a different discussion, because they’re going to continue to move the needle.”

The employer’s prerogative

Another hidden cost that companies might miss is they need to put training and support systems in place for employees. Many off-the-shelf agentic AI tools might seem easy to use, but actual adoption still requires change management. CGI did offer training to employees when it rolled out GitHub Copilot, a popular coding platform with agentic functionality. “And we expected them to adopt and leverage it on day one,” says Vargo. But people quickly went back to their old ways of working, he says, and CGI had to pivot its strategy.

“It’s going from training programs to habit formation or transformation programs,” he adds. “And we’ve seen adoption skyrocket.”

The change isn’t in just how individuals adopt AI to improve their own work, though. “You’re now a manager of 10 to 20 specialized agents that are driving that work for you,” he says.

The error is when companies put the technology first. “They fall in love with the tech or a vendor, but they’re not really thinking about how they’re truly integrating these tools and technologies into the business.”

Embracing change

Change management is a particular challenge with agentic AI because the tools are changing at such a fast pace.

“It’s technology that’s constantly changed almost every month, or maybe every week,” says Scott Likens, chief AI engineer at PricewaterhouseCoopers. “The challenge I see is the timescale of change is much faster than what we’re used to.”

We’re still in the early stages of agentic AI, he adds, and waiting isn’t a good strategy. “You have to start, but keep flexibility over longevity in mind,” he says.

For Luis Huerta, group head of gen AI and agentic automation at International Airlines Group (IAG), change management is one of the most complex parts of agentic AI adoption, as it uses agentic AI to improve customer experience, operations, and efficiency.

“The technology is powerful, but the bigger shift is organizational,” he says. So the company isn’t just focusing on building agents, but also on business ownership, adoption, and governance, and helping colleagues understand how these capabilities change the way work gets done and how it can support them, rather than replace them.

Huerta says IAG also uses agentic capabilities embedded in enterprise platforms, but also builds its own agents, too.

They’re not alone. According to Anthropic’s 2026 State of AI Agents report, 47% of organizations take a hybrid approach to AI agents, while 21% rely entirely on pre-built agents, and 20% build their own.

“We take a technology-agnostic approach,” says Huerta. “Our priority is to select the right solution for each use case.”

Regulated industries have been dealing with the equivalent of sovereign data for a long time. And as the geopolitical situation makes it more broadly relevant, it doesn’t make it any easier to deal with.

From concerns about the reach of the US CLOUD Act and what telemetry or sensitive business data gen AI models might collect, to implications of the US government taking part ownership of a range of technology companies and the impact of EU regulations, the state of the world means more organizations need to think about where data is located.

The result is a flood of announcements from hyperscalers about new EU cloud regions, as well as pitches from regional and private cloud providers. The promised sovereignty may be anything from a local availability zone to more sophisticated approaches to ownership structure, compliance frameworks, where logs are stored, or where support staff work.

Actual data sovereignty involves legal, technical, contractual, governance, and infrastructure questions, but all too often, what’s on offer is what IDC research director Rahiel Nasir calls sovereignty washing. “When you look under the lid, all they’re really offering is a solution for data residency and data localization, keeping data in country,” he says. “That’s part of sovereignty, but not all of sovereignty.”

In his experience, in-country data centers are the first thing organizations ask for to support data localization and data residency, but they also require enhanced controls over identity and access management. That’s critical because data sovereignty is as much about who has access to the data and why, as where it lives.

“It’s really important the only people who touch my data in what is supposedly a sovereign cloud environment are those I give permission to,” he adds. “Because it’s my data, and I’m the only one who can give the authority to grant access to it. That also applies to support and admin staff.”

Companies want control through where they store data but also to restrict how users can interact with it that might expose that information outside an approved environment or jurisdiction, adds Acceldata SVP Ali Afsar.

Access and control

Don’t confuse the regulatory requirements of data residency with data sovereignty, Scality CMO Paul Speciale warns. “Residency is about geography,” he says. “Sovereignty is about control, jurisdiction, and who ultimately has the legal authority to access data.”

For CIOs, the question is no longer simply where the data is but who can access it, who controls the encryption keys, under which legal framework it operates, and can that control be proven. That includes being able to show who accesses data, from where, and for what purpose, which requires verifiable controls like jurisdiction-aware data placement, immutable backups, tightly governed admin access, and clear audit trails.

The UK government’s recent call for evidence on the impact of international data flows on sovereignty makes this explicit, referring to transfer by access where personal data remains in the UK but is accessed from overseas, including by a user located in another country. Access transfers include administrative access, backups, disaster recovery, support incidents and sometimes — depending on the specific regulations — processing the data.

GDPR doesn’t mean data has to stay in the EU but it does require data to be protected to EU standards wherever it goes. Data transfer obligations for other jurisdictions can be far more restrictive, so multinational organizations may need access controls limiting who can see what regulated data from different locations.

RBI-regulated payment-system data, for instance, must be stored in India, but can be processed outside India, Afsar explains, as long as it’s deleted from overseas systems within 24 hours. And with limited exceptions, personal data in Saudi Arabia must be processed within the Kingdom, and China treats overseas access to some categories of data stored in China as a cross-border data activity. Russian laws require similar strict data localization, and personal data of Russian citizens has to be stored, processed, and kept within the country’s borders at all times, which is why LinkedIn was blocked there.

Elsewhere, regulations are most restrictive for specific markets like healthcare, financial, and public services. Not everything needs to be transferred to a sovereign cloud, Nasir points out, as use of that data is subject to regulatory compliance, and the increasing need for AI training.

“This is the data that’s going to have catastrophic business impacts if leaked,” he says. “To give enhanced controls and security for that data, you’d consider wrapping sovereign controls around it. Everything else not subject to compliance nor sensitive data can be accessed by whomever you want and from wherever.”

Sovereignty and safety

Organizations typically know data sovereignty rules well but still experience incidents like data breaches, government data access requests, and unauthorized cross-border transfers caused by, for example, traveling employees or excessive admin access, according to Kiteworks’ 2026 Data Security and Compliance Risk report.

“Location only tells a regulator where the data rests, not who can still reach it,” says Kiteworks’ EMEA GM Dario Perfettibile. “Every real exposure we’ve seen so far happens through access not geography.”

Thinking data needs to stay in region because then it’s safe gives a false sense of security if practiced as a substitute for proper data management. Access, data labelling, and retention polices take more work but are what can prevent incidents. “If you have a data policy in place, it can force a reapproval of the access,” he adds. “It can restrict access to you only, or it can block you out immediately.”

Location isn’t everything

Using a service closer to home doesn’t automatically make any of that easier. “Many organizations still assume sovereignty can be achieved by moving data from one cloud provider to another, or by replacing one hyperscaler with another,” says Keepit Group CISO Kim Larsen. “That misses the bigger picture.” CIOs should treat sovereignty as an operational capability not a compliance exercise, he adds, since sovereignty isn’t about scale or ownership of infrastructure for its own sake, but maintaining control.

“If an organization doesn’t know who can access its data, which legal frameworks govern that access, or whether it can recover its data independently, simply changing where the servers are located does little to reduce risk,” he says.

Just because something is based in your region doesn’t automatically make it a good choice. The EC, for instance, has set up accounts on W Social, an independent social media platform based on the AT protocol designed for data mobility and user migration, which Bluesky uses but is hosted in Europe.

The Commission’s own open source strategy suggests open source promises more control over digital infrastructure by avoiding vendor lock in, and a recent policy brief positions digital sovereignty as a form of digital independence. But having servers in the EU isn’t the same as freedom of digital movement since unlike Eurosky, based in Europe and using the same protocol, W limits interoperability so it can require identity verification, and has closed its source code after security researchers pointed out vulnerabilities.

Most organizations will continue to use both global and local providers, though they might prioritize what Nasir called glocal options built on partnerships between the two. “Organizations want to use a mixture of local and global providers,” he says. “They want all the innovation capabilities that the Microsofts, AWSs, and Googles of the world give us, that they consider local providers can’t match.”

IDC figures suggest only 4% of European organizations plan to switch to purely local options. “We can’t live without US technology today and there’s no appetite to do that,” says Nasir. Availability matters and local providers may not have the same level of infrastructure as global options. They can offer low hanging fruit like video conferencing solutions, but not more complicated directory and database services, or productivity software that’s intertwined with those US-provided services.

Choices about where to store data, and the technical controls to enforce that, have their own operational implications.

“Redundancy and resiliency are key tenets of sovereignty,” he adds. “You want to make sure your operations are always available. In order to enable that, you want to spread the risk.”

AI systems do not make decisions from reality. They make decisions from representations of reality: records, observations, measurements, histories, labels, documents, and whatever else an organization has decided belongs in the data. That distinction sounds almost too obvious to be interesting, yet it becomes surprisingly easy to forget once an AI system can process thousands of records, identify patterns no person would notice, and return an answer that appears comprehensive. The sophistication of the analysis can distract us from a more basic problem: important information may never enter the decision process in a form the system can use.

Much of the responsible-AI conversation begins after that problem has already occurred. We ask whether a model is accurate, whether its recommendation can be explained, whether a human remains involved, and who is accountable when something goes wrong. Those are necessary questions, but they assume that the relevant evidence made it into the decision somewhere. If the AI and the human reviewer are both reasoning from the same incomplete representation, adding a person at the end does not necessarily repair what was missing at the beginning. I spend a great deal of time thinking about consequential AI decisions and the conditions organizations need in order to govern them responsibly, but what made me look at this particular problem differently was not another governance framework or model-risk paper. It was a small white parrot named Ellie.

Ellie is a Goffin’s cockatoo, a species known for sophisticated problem-solving. She has participated in a multiyear animal-computer interaction research program led by Jennifer Taylor-O’Connor, who previously published as Jennifer Cunha, and researchers from several universities. The work examines what happens when parrots are given access to tablets, speech boards, video communication, and other technologies that let researchers systematically observe their choices and behavior. The important part of this research is not the internet-friendly question of whether a bird can “talk” or “read.” The progression of the research is more useful than that because the questions become progressively more demanding.

A 2024 CHI paper, Ellie Talks About the Weather, examined the expressive and enrichment potential of a tablet-based speech board used by a single Goffin’s cockatoo. The work was not presented as proof that parrots possess human language; it examined the interaction itself and what could reasonably be inferred from it.

Later that year, Communication Functions in Speech Board Use by a Goffin’s Cockatoo examined Ellie’s speech-board behavior against recognized functions of communication. The researchers examined her persistence when requests were not fulfilled, her ability to locate displaced representations of preferred items, and her responses when she received something different from what she selected. The authors concluded that the combined findings aligned with recognized linguistic and biological communication functions and indicated intentional communication. The paper received an Honorable Mention Award at the 2024 International Conference on Animal-Computer Interaction.

The research has since moved into territory that should feel familiar to anyone designing or governing AI systems. A 2026 CHI study involving Taylor-O’Connor examines how different speech-board representations affect parrots’ selections. Humans determine which options are available, how those options are represented, what counts as a selection, what is recorded, and how the resulting behavior is interpreted. The signal does not arrive untouched; the interface shapes what becomes observable evidence.

Ellie may be exceptional. Her abilities, training history, environment, and years of interaction with these systems do not make her representative of cockatoos generally, much less animals as a whole. I do not think she needs to be representative for the case to matter. Edge cases are often useful because they expose assumptions that ordinary cases leave hidden. Ellie does not prove that animals generally can communicate through technology in the same way. She shows that changing the interface can change what information becomes available to us. For anyone responsible for enterprise AI, that should feel familiar, because organizations constantly decide not only what information is true or reliable, but what information can enter a system at all.

The record is not the subject

Organizations routinely translate complicated lives and situations into forms they can process. A patient becomes diagnoses, medications, laboratory values, codes, and clinical notes. An employee becomes performance measures, tickets, evaluations, attendance, and productivity data. An applicant becomes income, history, scores, documents, and eligibility fields. An animal in a veterinary or shelter environment becomes medical history, behavioral observations, intake information, caregiver notes, and disposition status. We cannot avoid representation; no human decision-maker or AI system can absorb reality in its entirety. The problem begins when the representation starts functioning as though it were sufficient for the reality it describes.

Consider an AI-assisted system supporting a consequential animal-care decision involving treatment, rehabilitation, social placement, or transfer to another facility. The system has medical information, behavioral observations, caregiver notes, placement history, environmental factors, and perhaps outcomes from similar cases. It analyzes those inputs and recommends a course of action. A veterinarian or experienced animal-care professional reviews the recommendation and retains final authority. Nothing about that arrangement sounds obviously irresponsible. Human judgment remains in the process, and the AI supports rather than makes the final decision.

Now suppose another source of information exists that does not fit comfortably into the established record. Repeated observations may indicate a social attachment that matters to the proposed placement. The animal may consistently avoid an environment that appears suitable on paper. In some future setting, a sufficiently validated communication interface may provide additional information about preference, discomfort, social interaction, or another state relevant to the decision. None of that should automatically override clinical judgment or an AI-supported recommendation. Animal-generated signals can be ambiguous, interfaces can shape responses, and welfare needs can conflict with preference. What matters is whether the decision process has a legitimate way to receive and consider that information once it becomes credible enough to matter.

The same problem exists in human settings, although it is easier to overlook because we tend to assume people can correct the record themselves. A patient can explain that symptoms have changed, an employee can challenge an evaluation, an applicant can provide additional circumstances, or someone denied a service can appeal. In practice, those pathways are uneven. Disability, language, age, institutional power, rigid forms, inaccessible processes, and simply not knowing what a system has inferred can all affect whether someone can put missing context back into a decision. Ellie makes the structural assumption easier to see because she cannot compensate for a poorly designed channel in the ways our institutions expect humans to. If an interface gives her no way to express something, she cannot add a note explaining what is missing. If humans misinterpret her behavior, she cannot request a meeting to clarify what she meant. Researchers therefore have to confront the channel’s design rather than assume the subject will repair whatever the system failed to capture.

The problem starts before the model does

This is where the issue becomes particularly relevant to CIOs and enterprise technology leaders. We often talk about an AI model as though it independently determines which information matters. In reality, many of those decisions are made long before inference begins. Someone decided what fields would exist, what could be measured, whose observations would be recorded, which systems would exchange information, what metadata would survive transformation, and which sources the model would be allowed to retrieve. By the time the AI appears, a large part of the evidence environment has already been designed.

That is why I do not think this is simply a conventional data-quality problem. A record can be accurate and still be incomplete. Every field can be populated correctly while the system remains incapable of receiving another category of information that could materially affect the decision. A medical intake system can add dozens of fields and still fail to capture an experience the form was never designed to describe. A workforce platform can generate increasingly detailed performance metrics while measuring only the work that is easy to quantify. An animal communication interface can record every available selection perfectly while still limiting the subject to choices humans decided to make available.

The 2026 parrot-interface research makes that mediation unusually obvious. The interface is not a transparent pipe carrying an untouched preference from animal to researcher. It is part of the process through which something becomes interpretable evidence. Enterprise systems work the same way, although the mediation is usually hidden inside familiar databases, APIs, forms, workflow rules, scoring systems, and integration decisions. Those systems do not merely store information; they define the channels through which information becomes visible and actionable.

For CIOs, that creates a question upstream of model selection and model evaluation. When designing an AI system for a consequential workflow, someone should ask not only whether the data is accurate, governed, secure, and traceable, but what materially relevant evidence has no pathway into the system at all. A high-performing model cannot compensate for information the surrounding architecture cannot receive, and human review does not automatically solve the problem if the reviewer is constrained by the same representation.

That raises an obvious challenge: how would an organization ever know whether it has enough information? In most consequential decisions, it probably cannot know that the picture is complete. Complete information is not a realistic governance standard. Decisions are made under uncertainty all the time, and waiting for perfect knowledge can itself create harm. Organizations can become much more explicit about decision sufficiency: whether the available evidence is adequate for the consequence at stake, what meaningful uncertainty remains, and what kinds of new information would be important enough to reopen the decision.

That distinction matters because sufficiency should be proportional to consequence. The evidence required to recommend a playlist should not resemble the evidence expected before denying medical treatment, terminating employment, transferring a vulnerable animal, or making a high-consequence public-sector decision. As consequences become more serious, harder to reverse, or more dependent on assumptions about an affected subject, the case for actively looking for missing evidence becomes stronger. The organization does not need omniscience, but it should be able to explain why the available information was considered adequate and what would have changed that judgment.

In practice, that means asking questions that sit slightly outside traditional model evaluation. What evidence, if it existed, could materially change this recommendation? Which perspectives or sources are missing from the current record? Are there known channels through which contradictory or contextual information can enter the workflow? What assumptions are being made because certain information is unavailable? How reversible is the decision if those assumptions prove wrong? Answers will vary by domain, but the discipline of asking them shifts the standard from “the model had enough data to run” to “the organization had enough evidence to justify acting.”

This is where the governance conversation becomes more useful. Model performance can tell us whether an AI system performs well against the information it receives. It cannot tell us whether the evidence environment itself was sufficient for the decision. That question belongs partly to data architecture, partly to workflow design, partly to governance, and partly to the domain professionals who understand what the record may be leaving out.

A second mirror

Something else about Ellie’s research has stayed with me because it creates an unusual contrast with the way we talk about AI. We are building artificial systems whose language is so fluent that people routinely have to be reminded not to confuse convincing output with understanding. We worry, appropriately, about assigning too much intelligence, intention, confidence, or authority to a machine because it communicates in a form humans find natural.

At the same time, researchers are developing technologies that may allow us to perceive forms of animal communication that humans have historically struggled to recognize. There, the error can run in the opposite direction. Scientific caution about anthropomorphism is essential, but unfamiliar communication can also be discounted because it does not arrive in a form our institutions naturally recognize as evidence. The useful comparison is not whether AI and animals “really understand” in some equivalent sense. They are not equivalent, and forcing the discussion there would turn a governance problem into a philosophical argument it does not need. What connects them is human judgment. We decide when a signal appears meaningful, which sources deserve credibility, what becomes part of a record, and how much weight different forms of evidence receive.

Once those judgments are encoded into enterprise systems, AI can reproduce them with tremendous consistency. That consistency is useful when the underlying assumptions are sound, but much less reassuring when they are not. A system can appear technically sophisticated while remaining blind to information that never fit the architecture. In that sense, Ellie’s value to this conversation is not that she tells us something universal about animal intelligence. She makes one hidden assumption visible: changing the channel can change what information becomes available, and information that cannot enter a system cannot influence the decision no matter how sophisticated the analysis becomes.

As AI moves deeper into healthcare, employment, financial services, public services, animal care, and other consequential environments, we will continue improving model evaluation, explainability, human oversight, contestability, accountability, and data governance. We should. But those safeguards begin too late if the evidence architecture around the decision was insufficient from the start.

The practical standard is not that organizations must somehow know everything before an AI-supported decision can proceed. That would be impossible. The more defensible standard is that they should know why they believe they have enough, what uncertainty they are accepting, and what new evidence would require them to reconsider. Sometimes the model will process the available record correctly, the human reviewer will do exactly what policy requires, and every formal control will operate as designed. The decision may still rest on an incomplete picture, but an organization that has explicitly considered evidentiary sufficiency is in a very different position from one that simply assumed the record was the whole story.

That may be the quieter governance lesson hiding inside an unusual cockatoo experiment. Better AI will help us extract more meaning from the information we already possess. Responsible AI also requires enough humility to ask what the system was never designed to receive—and whether that missing piece is important enough that we should go looking for it before we act.

AI models are becoming short-term tenants in long-lived enterprise data estates. Yet many organizations are remodeling the building around each new occupant.

The market keeps asking which model enterprises should trust: open or closed, domestic or foreign, one frontier provider or another. These are legitimate questions. They are also questions with a very short shelf life. Model rankings change by the month. Providers change terms, regulators redraw boundaries and capabilities that looked scarce six months ago become commodities.

In my experience, enterprise data doesn’t move at that speed. Neither do the controls, applications and business processes built around it. That mismatch is why the most important AI architecture decision for CIOs is no longer which model to choose. It is whether the enterprise can absorb continuous change without fragmenting its data estate or surrendering control.

The winners in enterprise AI will be those who build a data foundation extensible enough to accommodate it ,build a data foundation extensible enough to accommodate that ongoing change and sovereign enough to remain in control.

Extensibility is now a production requirement

During experimentation, architectural limits are easy to hide. A team can connect a new model to a copied dataset, prove a use case and call the pilot successful. Production exposes the real architecture: identity, permissions, data residency, lineage, latency, recovery and cost.

Every time those controls are rebuilt around a model, the model becomes a dependency. Adding or changing capabilities can mean moving data, recreating access policies, revalidating pipelines and reopening compliance reviews. What looked like speed at the pilot stage becomes a maze of point-to-point architecture that is difficult to extend and even harder to govern.

This isn’t a hypothetical. A Harris Poll surveying 600 CIOs found that 81% expect to rely on two or more large language model providers in 2026, and 93% say different models perform better for different use cases, requiring ongoing evaluation. More than half also noted they’ve switched providers at least once already, mostly to cut costs. This is consistent with our observations in the field: Multi-model is not a future scenario CIOs plan around. It is the operating condition they’re already managing now, whether or not the architecture underneath was built for it.

The gap between expectation and architecture is where the real cost surfaces. When a model is deeply embedded in application logic, data pipelines and prompt structures, replacing it with another provider turns into a multi-quarter engineering project rather than a simple configuration change. Teams end up paying twice, once to adopt the new model and yet again to unwind everything wired to the old one.

This helps explain why AI experimentation remains far ahead of AI value. CIO.com’s 2026 State of the CIO survey found that only 19% of respondents said their AI initiatives had met or exceeded business goals. Architecture is not the only reason, but systems optimized for the first model demo rarely become durable production systems by accident.

I recommend that CIOs add extensibility and control to the familiar measures of performance, security and cost. Can a team introduce a new model without relocating governed data? Can it change the deployment environment without rebuilding the application? Can it add a new way to query data without creating another synchronized copy? If the answer is no, the enterprise is extending its AI capability by fragmenting its control.

Put control where the durable value lives

Models are increasingly interchangeable. Enterprise context is not. The distinctive asset is the governed body of customer history, operational state, intellectual property and institutional knowledge that gives a model something useful to reason over.

That makes the data layer the durable control point. Identity, access, locality, audit and policy should be enforced as close to the data as possible, inside an environment the enterprise can operate, extend and move. The model can then be inspected, sandboxed or replaced within those boundaries.

A common pattern shows why. A team wires retrieval and access controls directly against one model’s embedding format and API to get to production faster. A year or two later, a new regulatory requirement or a stronger-performing model prompts a switch. Governance fenced around the original model will result in rebuilding access policies, revalidating pipelines and, ultimately, reproving compliance inside the new vendor’s environment. Governance enforced at the data layer, on the other hand, allows the new model to inherit the operating policies and audit trail from day one, maintaining the existing fence even as the model changes.

This does not make model provenance or security irrelevant. It makes those risks containable. Governance attached separately to every model is a collection of fences that must be rebuilt whenever the vendor changes. Governance anchored in the data layer is the property line: The tenant can change and the building can expand without changing who controls the grounds.

That is what sovereignty means in operational terms. It is not only where data is hosted but who can govern, move and extend the environment on their own terms.

Ask what the enterprise still controls

Before approving the next AI platform, CIOs should ask three questions:

1. Can this architecture absorb a new model or workload without moving governed data?
2. Which governance controls remain ours if the provider, region or deployment model changes?
3. Does adding this capability extend the foundation or create another data copy, control plane and dependency?

These questions become more urgent as agents move into production. Agents multiply quickly; they act across systems and they need the governed data the enterprise already holds. When controls are enforced where that data lives, every new agent inherits them by default. Without that foundation, each agent brings its own pipeline, permission model and place to store what it needs, and the governance burden grows with every agent added.

IBM’s Institute for Business Value surveyed 2,000 technology executives in 2026 and found that businesses building control into their AI systems deploy 16 times more AI agents than those relying on manual governance, while spending a fraction of the budget to get there. This research is consistent with what I’ve seen in the field. In our research report with MIT Technology Review, we found that 95% of enterprises are planning to establish their own AI and data platforms within the next three years, and the 13% most committed to sovereignty are already delivering 2x more agentic and generative AI applications in mainstream production.

Businesses designing for adaptability early on are more likely to keep their workloads portable and have an easier time replacing models, instead of getting locked into hard dependencies. These businesses also reported a meaningfully higher return on their AI investment. There’s a clear gap that traces back to architecture. Whichever model a business happens to select matters less than whether the foundation underneath can absorb the next one.

The next model announcement will attract the headlines. The more consequential work sits underneath it: building an extensible data foundation that can accommodate the next model, the next regulation and the next workload while keeping data under consistent enterprise control.

The smartest AI strategy is not a perfect bet on today’s model. It is a data foundation that can keep extending without ceding authority over the data it serves. The building should outlive the tenant, and no model or platform should ever hold the deed to the enterprise’s data.

Alternative clouds have emerged amid major cloud providers such as AWS, Google Cloud, and Microsoft Azure, and often specialize in niche areas like AI-native computing, and sovereign and edge deployments, while professing to provide cost reductions and best-of-breed performance.

“Many organizations are rebalancing away from all-in hyperscaler strategies to avoid lock-in and concentration risk,” says Kyle Campos, CTPO at CloudBolt, a cloud management platform. “At the same time, alternative clouds are often purpose-built for specific advantages.” To him, benefits include lower-cost object storage at scale, better edge performance for latency-sensitive apps, and faster access to dedicated GPUs for AI workloads. Data sovereignty is also pushing adoption of localized providers.

But as alternative clouds, also called neoclouds, make headlines and amass considerable funding rounds, their use in enterprise environments remains relatively nascent. While enterprise executives see the potential in using alternative clouds, especially for GPU workloads, many are skeptical, taking a balanced approach to assessing maturity, costs, and whether it’s worth sacrificing continuity with existing clouds.

Smartsheet CIO and CISO Ravi Soin is one of these executives taking a measured approach. “We’ll grow our use of alternative clouds, but within a clearly defined perimeter,” he says. “That discipline is what separates considered adoption from sprawl.” For Soin, many neoclouds still fail early in the evaluation process, especially for regulated workloads where a mature compliance posture is non-negotiable.

In order to fully evaluate alternative clouds, the platforms must be treated with the same vigilance as any other IT acquisition. “This remains consistent across any tech stack: fit, form, and function,” says Nigel Gibbons, director and senior advisor at the NCC Group, a cybersecurity consulting firm. “This means alignment of the cloud to workload performance, security, and sovereignty needs.”

Overall, CIOs aren’t rushing into alternative clouds. It’ll take a serious proof spanning regulatory impact, auditability, resilience, and total cost planning in order to convince large organizations to migrate away from well-established cloud infrastructure. More realistically, such clouds will be evaluated on a per-workload basis.

Compliance and transparency

When evaluating neoclouds, compliance is top of mind for enterprise executives. “Compliance posture such as SOC 2, ISO 27001, and sovereign-specific certifications like FedRAMP or IRAP is the first filter and, for most neoclouds, an early exit,” says Soin.

Smartsheet runs AI on enterprise customer data and therefore requires strict compliance and sovereignty frameworks. “That defines a hard boundary where regulated workloads stay with certified providers,” he adds. “Workload identity doesn’t federate natively across clouds, so every trust relationship must be hand-built and audited. For a platform where data sensitivity varies enormously, that governance gap isn’t theoretical.”

Gibbons adds that trust validation is becoming a pressing requirement from regulators and the overall market. “The uncomfortable truth is that most organizations have operated on deferred risk captured in registers, softened in board narratives, and tolerated due to limited visibility,” he says. The pattern of tumultuous changes in the AI market, he adds, is encouraging more of a resilience mindset among technical executives assessing new technologies.

Operational transparency is another pressing area to evaluate. For Soin, the infrastructure that supports AI workloads requires granular auditability. “Can the provider give you end-to-end observability across the inference layer: tamper-evident logs, model versioning, the ability to trace what happened to customer data from input to output?” he asks.

Smartsheet’s enterprise customers also ask how AI is applied to their data and what controls exist, and that answer has to be defensible. “A neocloud that can’t support it isn’t just an operations risk, it’s a risk to the customer trust our business is built on,” he says.

Per-workload evaluation

Although neoclouds are often framed as a replacement to hyperscalers, they’re more often complementary infrastructure, purpose-built for individual use cases. “A neocloud isn’t a type of cloud, but more a design principle,” says Gibbons. “We can think of it as infrastructure optimized for a specific workload, trust model or control requirement, rather than general-purpose scale.”

Their usage hinges on the project at hand, which typically involves AI/ML projects. “We work with a mix of alternative providers depending on workload fit,” says CloudBolt’s Campos. “We’ve used alternative cloud providers for VMware as part of a cloud migration strategy.” Their customers use alternative clouds for object storage, edge and low-latency needs, AI/ML GPU capacity, and legacy virtualization workloads that don’t map cleanly to hyperscaler-native services.

Executives must determine which environment makes sense for the workload at hand, and act accordingly. “CIOs should begin by clarifying the specific workload opportunity an alternative cloud is meant to accelerate, then evaluate providers against developer and operator experience inclusive of ability to scale with business need,” adds Campos. “From there, the priorities are whether the platform can be governed and operated alongside existing clouds, with strong visibility into usage and unit economics. Security, compliance posture, and credible SLAs for reliability and performance should be evaluated at the same bar as hyperscalers. The goal is to add flexibility without creating a new operational silo.”

Not all workloads are a fit for neoclouds or alternative providers, however. While these platforms benefit numerous workload-specific options, they’re not viewed as wholesale replacements for hyperscalers. For general-purpose enterprise functions, hyperscalers may still retain advantages around integrated services, discounts, operational maturity, and the availability of relevant job skills.

For this reason, many technology leaders are still in an exploratory phase. “Our infrastructure today runs on hyperscalers, and that’s been the right choice for where we’ve been,” says Smit Shanker, global CIO of Xebia, a global IT consulting and software engineering company. Still, he encourages CIOs to begin actively evaluating alternatives. “We’re now in that evaluation phase, looking at where specialized providers, sovereign options, or hybrid approaches make more sense for specific workloads.”

Shared responsibility model

CIOs require a high-degree of enterprise-grade trust that must be codified beyond empty promises and proven under real-world stress tests. As such, before diving headfirst into a newfangled cloud, Smartsheet’s Soin advocates verifying its shared responsibility model, which stipulates commitments the cloud provider has to uphold, and where responsibility lies with consumers.

For Soin, it’s especially critical to understand how a cloud provider acts when incidents occur. “Request post-incident reviews before signing anything, not templated RCAs but the real communication timeline,” he says. “Shared responsibility models are well-documented until they’re tested. Find out what happened the last time they were tested.”

Ultimately, alternative clouds need to meet the same enterprise maturity bar as established cloud providers. “Assurances must include auditability, compliance, resilience, transparent SLAs, interoperability, portability, and independently validated trust, not vendor assertions,” says NCC Group’s Gibbons.

Total cost analysis

Understanding the economic impact is necessary to determine whether an alternative cloud is worth it for the business. This is an area where alternative clouds shouldshine, with reports estimating savings of up to 70% compared with hyperscaler GPU instances. Traditional cloud computing pricing models are often opaque, and charges related to add-ons, upsells, and hidden fees around egress and ingress are notoriously known to surprise cloud computing consumers.

For certain workload categories, the economics can favor alternative clouds. “Traditional cloud providers often impose substantial data egress fees that inflate the total cost of ownership for data-heavy architectures,” says Dave McCarthy, VP of cloud and infrastructure services at global market intelligence and advisory firm IDC. “Alternative providers frequently minimize or eliminate these bandwidth penalties entirely, offering a more transparent cost structure,” he says.

Still, a full cost audit is necessary before going all-in on an alternative cloud. “What I’d recommend to anyone is do the full-cost model before you commit,” says Shanker. He suggests conducting a comprehensive analysis of cloud compute, inference, API volumes, and maintenance costs for things like infrastructure upgrades projected against the actual demand curve. When viewed together, he says, they create compounding costs that most C-suites haven’t modeled.

“Most enterprises are still modeling cloud economics on implementation costs alone, and that’s incomplete,” he adds. “The organizations getting AI right are the ones treating infrastructure economics as a first-class design decision, not a footnote.”

As cloud infrastructure choices can produce vendor lock-in, CIOs should use all the criteria at their disposal to plan and inform a neutral decision-making process. “Whatever path you choose — hyperscaler, alternative, sovereign, or some combination — the discipline that matters is vendor-agnostic, framework-led design,” adds Shanker. “Don’t let infrastructure choices constrain what’s possible.”

Where the market is heading

Neoclouds have made a mark for themselves by offering direct access to latest-generation hardware, which is important for AI-focused workloads requiring high performance. There’s also the argument that opting for alternative clouds aids a distributed multi-cloud strategy, which can benefit resilience and meet certain regional sovereign cloud mandates.

Nearly 90% of IT leaders say an organization should never commit to one cloud provider for their entire architecture, according to a HostingAdvice survey from last year. The same study found 73% of leaders use two or more alternative cloud providers, underscoring a clear interest in alternative clouds.

Still, while some industry reports are favorable, enterprise executives express more of a cautious reality of selective evaluation, not wholesale migration. For Soin, a top concern is the compliance posture and observability capabilities for alternative clouds, especially when hosting workloads that run AI inference. “The question isn’t just where inference happens but whether we can see what happened, explain it, and stand behind it,” he says. “That obligation shapes which providers are even in the conversation.”

While state-of-the-art cheap GPU compute is alluring, CIOs should keep an eye on the full governance picture when evaluating alternative clouds. “The neoclouds that earn more of our workload won’t just be the ones with the best GPUs,” says Soin. “They’ll be the ones that have seriously invested in model governance infrastructure and can demonstrate it. That’s a higher bar than most currently clear, but it’s where the market needs to go.”

A focus on inference

IDC forecasts that by next year, the computational demands of AI will force 80% of organizations to modernize legacy cloud environments by switching to platforms designed for AI workloads, with half of this being processed locally on endpoints or edge nodes by 2030.

“Enterprises are increasingly looking beyond major hyperscalers to avoid vendor lock-in and optimize specialized workloads,” says IDC’s McCarthy. “Rather than relying on a single, centralized infrastructure, organizations are adopting these alternatives into a broader portfolio.”

Much of this new computing paradigm will center on inference, or the post-training execution of AI models in production, using live customer or enterprise data. As inference moves into more business-critical workflows, decisions about where those workloads run, and what criteria guide those decisions, will have long-term implications.

Alt and neo clouds will likely have their place in inference, as well as in future sovereign and decentralized cloud models, and it’s not a decision CIOs should take lightly or without an informed evaluation framework. “Where workloads run becomes one of the most consequential decisions a leader makes,” says Shanker.

Data is the fuel for AI since generative, agentic, and ML systems are only as effective as the information they consume. Across all stages of the data lifecycle, including creation, storage, usage, archival, and destruction, CIOs and their business peers must consider how information feeds AI services.

Almost two-thirds of organizations are unsure whether they have the right data management practices for AI, says Gartner. The tech analyst predicts organizations will abandon 60% of AI projects by the end of the year due to a lack of data readiness. In such circumstances, a potential competitive advantage quickly becomes an innovation cul-de-sac.

CIOs who want to exploit AI will need a way to improve data management across the lifecycle, and it’s here where AI itself can play a crucial role. Gartner recommends organizations build on their existing practices by iteratively adding AI-specific services that extend and improve data management techniques.

Stephen Wood, COO at Rathbones Asset Management recognizes this opportunity, and he and his firm’s staff are eager to avoid lifting and shifting information from one place to another in its data management efforts. AI could help.

“Our people want to run models to look at the data, whether that’s the shape, structure, value, or whatever it happens to be,” he says. “If that task becomes something AI can do, I’m not sure yet. But given its power, it seems obvious you’ll be able to manage elements of the data lifecycle.”

Digital leaders suggest AI can improve information management processes, but there are limitations. First, they must recognize that emerging technology needs high-quality data, and then they need to identify key challenges, particularly around governance and trust. Then they must carefully explore where AI can play a key role.

Establishing data quality

For some digital leaders, a clear direction for data lifecycle management is already part of the operating process, including using AI.

Alwin Bakkenes, head of software engineering at Volvo Cars, says his company’s driver assistance systems (ADAS) rely on high-quality information. With a strong heritage in vehicle safety, Volvo has collected millions of data points since 2020, all with customer consent, to improve its collision-avoidance systems.

“In our ADAS stack, data curation is one of the most important elements,” he says. “There’s a lot of data coming in from a large fleet, and we curate it and figure out what information we need to make model training more efficient.”

Bakkenes gives the example of collecting data from vehicles to help understand traffic hotspots, such as large Parisian roundabouts. His team sends triggers to sensors to collect more data, which is then used to train AI models and test whether they behave as expected.

“It’s quite an open loop but that’s our data management strategy,” he says. “And this insight must be maintained and curated over time. Crucially, more data isn’t always the best data. Instead, data quality matters, and we’ve had good data for a long time.”

This strategic approach to information collection chimes with Ankur Anand, group CIO at recruiter Harvey Nash. He says successful data lifecycle management in the age of AI involves four underlying processes. “First, the data has to be findable, which means AI can locate the relevant information without relying on a professional’s knowledge,” he says.

Second, data must be understandable. He gives the example of multinational companies using different definitions across the business. “If there’s no common language or consistent terms, the context will vary, the AI will interpret the data differently, and that can have a big impact on the decision-making processes,” he says.

The third core element is data must be trustworthy. “The cleanup stage is very important,” Anand says. “The data must be permissioned appropriately so you don’t have an issue with people seeing information they shouldn’t be seeing. Confidentiality is crucial, because if the trust is broken, people won’t use AI.”

Finally, data must be usable at speed, which relies on the three previous processes. “It shouldn’t take people long to get a proper summarization, comparison, or reasoning from AI.”

Recognizing the potential, with limitations

Once data quality is established, digital leaders can start to consider how emerging technology can be inserted into stages of the data lifecycle.

Take Emmanuel Frenehard, chief digital officer at biopharmaceutical giant Sanofi. “I think AI can help surface gaps in data,” he says, referring to emerging technology, such as Snowflake’s agents, to scan information and identify areas where decision makers lack detailed insights.

Frenehard adds that AI can also help correct data. Most of his firm’s clinical trial data involves some element of human correction, and emerging technology can spot anomalies. “That’s very useful,” he says. “We use AI as a data governance methodology for clinical trials, where we review everything that comes in and self-heal the data.”

However, while these capabilities exist, Frenehard says there are limits. In a heavily governed industry like biopharmaceuticals, a probabilistic AI model that uses statistics to predict likelihoods and manage uncertainty can be helpful, but it can also create risks. His firm isn’t prepared to use AI to manage data without human input.

“The potential is there, but the trust would have to be there, too,” he says. “I always have concerns with probabilistic models. Probabilities are never 100%. There may be areas of business where it’s okay not to be 100% certain, yet there are also areas where it’s not, such as patient data and treatment recommendations.”

That sentiment resonates with Bernhard Seiser, VP of digital, data, and IT at AOP Health, who says his firm isn’t using AI to manage the full data lifecycle. He says discussions about data often cover similar concerns in big, heavily governed sectors, especially when considering whether AI is ready for information management.

“In our industry, 99% certainly doesn’t help me in a data space that needs to be 100% accurate,” he says. “But of course there are areas where you can leverage AI. For example, if you bring in new data sources, having somebody from the business available to describe each field is tough. For that task, gen AI tools can do a fantastic job.”

Seiser says his organization will continue to explore emerging technologies, but temper expectations. More AI might mean a degree of uncertainty that’s unpalatable, and right now, pioneering developments that could push AI-enabled data lifecycle management to new heights seem a long way off.

“For the more sophisticated stuff, like creating data products, writing queries, and so on, you always need to live with the fact that it’s not 100% certain,” he says. “I’ve spoken with technology experts, and people are unsure the technology will be ready for managing the full data lifecycle in five or even 10 years.”

Exploring solid use cases

While digital leaders aren’t eager to automate the data lifecycle in its entirety, pioneers recognize AI brings new efficiencies to specific stages of the process.

Michael Cole, chief technology officer at the DP World Tour, has spent the past two years working with key partners, such as HCLTech and AWS, to digitize his organization’s historical archive of over 50 years of data, covering 20,000 tapes, 27,000 hours, and 1.2 petabytes of content. This process has helped highlight the value of AI-enabled data management.

“That’s only the start of the journey,” he says, referring to the transformation. “We’re about to announce a new platform for media asset management, which means we’ll not only have all archived content in a digital format, but it’ll be easily accessible for internal resources, media, broadcasters, partners, and ultimately fans as well.”

Cole says this work illustrates the organization’s focus on digitizing information and making it available to younger fans who want to consume sports content in myriad ways. As this process gathers pace, emerging technology will play an important role in data management.

“We already use AI to automate the clipping of player shots, and we’ll continue to use AI for metadata tagging because that process is critical to creating an efficient way to source content and data,” he says. “Everything must be tagged accurately to enable that efficiency. We think gen AI and agentic technology will evolve to boost the efficiency of not only producing content but making it accessible to our fans.”

Freshworks CIO Ashwin Ballal is another digital leader who says AI can help manage stages of the lifecycle, such as the manually intensive data-cleansing process. An AI agent should be able to speed up that laborious process exponentially.

However, Ballal also suggests the key point isn’t whether AI can do data management work quickly, but whether tools work effectively to improve data integrity and quality. The good news is model training can help boost effectiveness. Now his firm is looking to insert agentic AI into the data management lifecycle.

“We’re just beginning that process,” he says. “We have a Databricks platform and have built LLMs and agents on top of the data. So if you’re a salesperson, you’ve got a sales agent, a marketing agent, and a product agent. This technology taps into the power of the data.”

Every other week, there’s a new story about AI solving a math problem that took mathematicians decades to touch. Most recently, it was a conjecture that had sat unsolved since 1939, cracked with an assist from an AI model. Meanwhile, the typical team still can’t ask ChatGPT what we sold last week without pulling three dashboards and arguing over whose number is right. That begs the question: why is AI intelligent enough to outsmart MIT professors, but it can’t outsmart the sales intern?

Here’s part of the answer. AI doesn’t get to guide a real business decision until it can answer with real accuracy, not 95%, not 99%, all the way. Getting there means clearing three hurdles: context, determinism and cost. Solve those three and you get accuracy. Right now, none of them are solved, which is why accuracy, not intelligence, is the actual blocker nobody wants to admit.

Grounding is the first wall

Ask an AI model a question about your company and it doesn’t actually know your company. It doesn’t know who owns which decision. It doesn’t know why your warehouse manager overrides the forecast every October, or which of two conflicting reports your team trusts. A new hire picks this up by working somewhere long enough. AI needs it handed over, deliberately, in layers.

The first layer is your teams, roles and workflows: who does what, and who is allowed to change it. The second is your industry and business context; the reason a service outage means something different for a bank than it does for a media company. The third is your data itself, the tables, definitions and history that make an answer true rather than plausible. All three have to be handed over deliberately. None of them show up on their own.

What I have observed is that companies skip straight to buying an agent and skip this grounding work entirely, which doesn’t end well. The agent still sounds confident. It’s also wrong in ways nobody catches until a decision has already been made on top of it.

Businesses do not want a coin flip

A client once told me something I have not stopped thinking about. We proposed solving their facility allocation problem with a classic optimization algorithm, deterministic and auditable, the kind where the same input always produces the same output. They were disappointed, stating, “I hired you because you are AI experts. Classic optimization gives us deterministic results. We want AI that gives us indeterminate results.”

I understood what they meant. They wanted something that felt like AI. But indeterminate is not a feature you want in a system telling you how much inventory to order. In the pursuit of using AI for the sake of using AI, it is easy to lose sight of the outcome the business actually needs.

That conversation still shapes how I scope every new engagement. When a client asks for AI without naming the decision it needs to support, I ask what happens the day it’s wrong. If the answer is a bad number in a board deck, we’re not talking about the same kind of AI they think they’re asking for. Sometimes that conversation ends the engagement before it starts. More often, it reshapes it into something smaller and more useful, an agent that handles the easy 80% of questions and flags the rest for a human, instead of one system trying to do everything at once.

Here is a number to think about. Anthropic recently published how it automated its own internal business analytics queries using Claude, and even with a purpose-built system, aggregate accuracy landed around 95%. That is one of the best AI labs in the world, building for its own internal use, still getting roughly one answer in twenty wrong. Tell any CFO that number and watch how fast they walk back to their deterministic BI dashboard.

I don’t think 95% is close enough. Not when the number ends up in a board deck. Not when a wrong answer becomes a real decision with real money behind it. In my experience, executives will forgive AI for being slow to learn. They will not forgive it for being confidently wrong. AI doesn’t earn a seat at the decision table by being right most of the time. It earns it by being right every time, the same way the deterministic system it’s replacing was. That’s not a popular thing to say in a market excited about what AI can do, but popularity was never the bar a business decision needed to clear.

Cost swings before the ROI math holds still

The variance in the cost of running an AI agent is enormous. I have watched the same agent perform the same task use up to 30 times as many tokens in one run as in another. Try defending a Well Architected Framework, or any ROI model, against a cost that swings that hard.

The trend lines pull in opposite directions at the same time. The price per token has generally been falling, which should make agents cheaper over time. At the same time, multi-agent architectures are burning through more tokens to do the same job. And an agent genuinely grounded in your teams, industry context and data — the grounding I described above — will use even more tokens than a shallow one. Full accuracy costs more, not less. The good news, if the trend holds, is that this improves rather than worsens over time. But “if the trend holds” is doing a lot of work in that sentence.

Not every question your business asks needs the same level of AI maturity. How many customers are in the system is easy, and I’ll trust an agent’s answer. How revenue has changed over time is medium. Forecasting future demand by product, week and store gets harder. Figuring out how to allocate demand across factories and manufacturing lines is super hard. Crafting a strategy that takes into consideration the three layers of context plus macroeconomic trends is, honestly, impossible for AI or a human to answer with certainty. The higher you climb that ladder, the more a wrong answer costs you, and the less I’m willing to accept anything short of fully right.

The mistake I see most often is a company jumping from easy straight to hard, expecting an agent that can answer “how many customers do we have” to also handle causal questions like “why did we stop selling a product.” Context requirements, accuracy requirements and token cost all climb together as you move up that ladder. That’s also the difference between handing an agent a task and handing it a role; the judgment a planner, buyer or analyst brings to a job every day sits at the top of the ladder, not the bottom.

The mathematician who cracked that 87-year-old conjecture and the CFO who wants last week’s sales are asking for different things. The mathematician wanted a collaborator: someone to try a thousand wrong paths and surface one interesting idea, where a 5% hit rate is a triumph. The CFO wants a number she can put in front of a board, where a 5% miss rate is a liability. AI has earned the first seat. It hasn’t earned the second.

It will, but not by getting smarter. It gets there when someone does the unglamorous work of grounding it in the company’s context, constraining it to be right the same way twice, and paying for that at a cost the ROI math can survive. Intelligence was never the blocker. Accuracy is. So, until an agent can clear all three hurdles, give it the easy 80% of the ladder, keep a human on the rest and don’t let the fact that it disproved a conjecture convince you it’s ready to order your inventory.

For most of the IT era, technology leaders have treated information as an asset. It is something to be stored, secured, processed and monetized. Organizations generated vast amounts of data, and technology processed that wealth and made it useful.

Then AI arrived, and the framing broke.

AI changes the relationship with information. It interprets it, compresses patterns within it, and generates new language from those patterns. It does so with such fluency that it converts accumulated human expression into outputs that are coherent, meaningful, and often persuasive in ways that are difficult to examine or trace. The arrival of AI is a deeper shift in how organizations produce language, remember knowledge, establish authenticity and decide what deserves trust.

Generally, the discussion about AI’s impact on language, memory and meaning gets swept into the social or philosophical bucket too quickly. But these are not just philosophical questions. They are enterprise questions, because they directly affect knowledge management, brand trust, customer engagement, regulatory exposure, institutional memory, decision-making and employee learning. CIOs who brush this dimension aside will govern AI infrastructure competently and miss its deeper institutional consequences entirely.

Language is humanity’s most powerful mechanism for collective learning. We speak not only about what is present, but about what is absent, imagined, remembered, feared and hoped for. That capacity is what allowed us to preserve experience, transmit it across generations and convert it into culture, knowledge, law, philosophy, science and enterprise memory.

CIOs must govern meaning, not just data

This is why large language models are consequential in a way that earlier software was not. LLMs train on enormous volumes of text. They learn patterns, structures, associations, idioms and contextual relationships within language. By doing this, they create a dynamic simulation of human language itself. Unlike traditional software that executes defined instructions, LLMs operate within encoded human expression. They observe documents, reports, messages and public knowledge, and they generate responses that sound almost like understanding.

Almost. And that almost is where the situation gets hairy.

The power is real. AI can widen access to sophisticated knowledge. It can digest complexity, translate across domains and reveal patterns invisible to a single analyst. Inside an organization, the impact can be significant: a junior employee can consume decades of internal documents in minutes; a manager can synthesise thousands of customer interactions before a single meeting; a compliance team can identify patterns across audit data that would take months by hand. Knowledge work has a new definition.

But it is precisely this power that creates the crisis of synthetic culture.

While writing “The AI Codex: Power, Ethics and the Human Future in the Age of Intelligent Machines,” I chose to leave the engineering largely aside and follow the subtler human consequences that are easier to ignore.

Synthetic culture is one of those consequences, and it should concern CIOs immensely.

Culture is not office decoration, value posters or elaborate town halls. Culture is how an organization thinks, decides, explains, rewards and justifies its actions. It lives not only in documents but in stories, habits, unwritten rules, leadership behaviours, institutional scars and the memory of battles won or lost. It is what people have lived through and passed on. Your document management system and knowledge management system are not the custodian of your culture. The people around you are.

AI preserves the digital residue of culture. It cannot preserve the lived meaning behind it. That distinction matters enormously.

Consider what happens in practice. If AI generates a memo in the style of a CEO, does it carry the judgment of that leader, or does it merely carry the pattern of her language? When generative AI summarises a complex customer dispute, does it carry the flavour of the relational history, or does it just compress text? When it drafts a new policy, does it reflect institutional accountability, or does it mimic the average structure of similar policies? When AI produces a cultural narrative for employees, is it transmitting memory or manufacturing a convincing imitation of the same?

These are not rhetorical questions. They describe a genuine ambiguity that is already embedded in enterprise operations.

AI takes what is human, learns from it, and produces something that comes close to human expression. But proximity is not identity. AI can sound human without being human. It can produce language without emotion. It can generate meaningful output without moral agency. It can create efficiency without bearing responsibility for the consequences.

And this is where authenticity begins to fracture.

There was, until recently, something like a one-to-one relationship between content and its source. A document had an author. A speech had a speaker. A photograph recorded an event. A policy had an accountable authority behind it. These relationships were not perfect, but they were there, and they allowed organizations and societies to trace meaning back to a human being who could be questioned, challenged or held responsible.

AI can weaken or obscure that link. It can produce synthetic truths that spread rapidly, appear credible and influence decisions without being anchored to any lived reality. Deepfakes are the obvious example. But the real danger is subtler and already present inside organizations: the synthetic summary, the automated narrative, the AI-generated recommendation that nobody can fully trace. A synthetic truth is not a lie. But it can be more dangerous than one, because it poses as a plausible construction with no real thing behind it.

The new enterprise risk: synthetic truth

For CIOs, this is a new category of risk for which many organizations have no mature controls. The question is no longer only whether organizational data is secure. The question is also whether organizational meaning is secure. Can employees distinguish between original knowledge and synthetic synthesis? Can customers trust that they are interacting with accountable institutional communications, or with an automated approximation? Can leadership trace the lineage of a recommendation or a decision?

These are operational questions. The failure mode is not just a data breach but more of a memory breach.

When AI systems generate from enterprise knowledge, they shape what the organization remembers and how it remembers it.

AI is changing what organizations remember

The consequences follow from the quality of what goes in. If the underlying data reflects poor documentation, AI amplifies that poverty. If institutional knowledge records only dominant voices, dissenting experience is subdued and eventually forgotten. If past mistakes have been quietly buried, AI may reproduce the organization’s confidence without preserving its caution. The organization becomes more efficient at forgetting what it should have remembered.

CIOs also need to rethink what knowledge management means. For years, KM was treated as a repository problem: store, tag, search, retrieve. AI retrieves knowledge and generates new formulations from it. Each time a model runs, it can produce a slightly different answer. Knowledge becomes fluid and unstable. A document may be old, but it is static and accountable. An AI-generated answer may be elegant but untraceable. Both can exist in the same organization, and most people cannot tell them apart.

Those who complained about information overload in the internet age have no idea about the blizzard the AI age is about to bring. AI can identify patterns invisible to humans, but it can also manufacture alternative truths that are difficult to challenge. It can reduce noise, but it can also generate noise at industrial scale.

This is why AI governance cannot be a downstream compliance exercise. It must be a first-principle commitment. Not just checking whether the model works but asking what kind of institutional memory the model is helping to create. Where did the information come from? Who approved its use? What has been included, and more importantly, what has been excluded? Where does the audit trail begin? Where does human judgment remain mandatory and non-negotiable? These questions belong on the Post-it notes sitting on every CIO’s desk as the AI agenda gathers speed.

The search for truth cannot be a human pursuit alone in this environment, but it cannot be outsourced to machines either. It must be a governed exercise, with explicit architecture and explicit accountability.

The crisis of synthetic culture will not announce itself dramatically. It will arrive quietly, in the form of convenience: automated memos, summarised knowledge, AI-generated reports that nobody has the time or the inclination to question. Machines will not become human. But organizations will gradually grow comfortable accepting machine-generated statistical approximations as human judgment, institutional memory or cultural truth. That comfort is the real risk.

The CIO now carries an institutional mandate: scale intelligence without surrendering trust. Productivity matters and must be pursued. But the real challenge is building trust while scaling intelligence. This means ensuring AI output is traceable, sources are visible, human authority is explicit and institutional memory is always protected from synthetic distortion.

CIOs have to become not just custodians of organizational systems, but of organizational memory. In the new Badlands of the AI age, the CIO is the morally upright gunslinger. Organizational memory is the line she must defend.

Generative AI is notoriously eager to help, to the point that if it can’t find something matching what you ask for, it’ll create it. So the problem with relying on guardrails is that all too often, a model will be wrong, showing a high confidence score for an incorrect answer because it’s relying on stale or non-canonical data.

Not only do you need to be able to track the lineage of data your model uses from source to token, something the EU AI Act requires, you also need to be able to take into account where the data came from, whether it’s out of date, if it changed in a way that affects the result, or if it was never really relevant or authoritative in the first place.

Gartner expects organizations will abandon 60% of AI projects because they don’t have the right metadata management, data quality, and data observability. IBM’s acquisition of Confluent also highlights the importance of real-time data with lineage, governance, and policy for AI agents, and one of IBM’s 2026 predictions was the importance of smarter data.

The usual approach is adding metadata and validation later in the data pipeline. That’s similar to the way the bronze, silver, and gold tiers of typical lakehouse architecture are supposed to represent how filtering, cleaning, and augmenting data improves structure and quality until it’s ready to use. That can mean an enormous amount of work since nearly three quarters of the CPU work in training a frontier model is data cleansing and validation.

But that can also remove a lot of the context crucial for gen AI. Rather than cleaning data and losing the original context, it’s often more effective to keep as much information about the original state of the data, says David Aronchick, open-source platform Kubeflow founder, and CEO of distributed data pipeline vendor Expanso. “You can’t pursue exactly purely clean data; that’s just not possible,” he says. “As you pull data into your ML model, every line should have some mechanism saying where it came from. Otherwise, you’re never really going to know because you can’t mix them together and tease them apart later. You can search your raw content, your raw logs, but it’s just not going to be there.”

IoT digital twin systems often tag data all the way back to the device capturing it so you can see whether a temperature spike is a critical failure, which you want to react to, or a routine calibration, which you don’t. But that information may well be relevant down the line when you want to use that data more broadly. So unless you capture at least some elements about the source of data before you move it, you’re not going to be able to easily reconstruct the context later, or at all sometimes.

Ulrik Hansen, co-CEO of Encord, a platform for managing and annotating data, calls this in-stream labelling and cautions it’s not an alternative to cleansing data. “Dirty conflates two things: actual corruption you should fix, and context dependence, where a reading only looks anomalous because you threw away the frame that explained it,” he says. “Cleansing kills both. The point isn’t to stop cleaning, it’s to stop normalizing away context you can never recover.”

Context can be cheap to capture at the source and nearly impossible to recover after, he adds. “The question isn’t whether to keep it,” he says, “it’s about curating what actually helps.”

Raw but not rancid

Aronchick characterizes the state of most bronze tiers as toxic waste because raw data doesn’t get validated before ingestion, or have a metadata wrapper on each data point. “You’ve taken raw data and stripped it of context,” he says.

Take a wind farm operator, for instance. When sensor data about the turbines is generated, it comes from a particular turbine at a particular position in a specific wind farm at a known location, running at a specific speed in specific weather conditions, at a particular time. “If you have other turbines also working in the field, the performance of your turbine will go down, but the field performance will go up,” says Aronchick. “The performance of your turbine going down isn’t a negative, but unless you have the context at the point of data collection, you’re going to make your life much harder later on, when someone asks about the efficiency.”

Metadata needs to be much richer, and it needs to be added as early in your data pipeline as possible when you have the most detail available to make sense of the structure and complexity of the data, Aronchick adds. “You want to capture as much about the data you’re collecting as possible, where it doesn’t require insane activity to do so.”

But not all the metadata you need will be generated with the data, he says. You almost certainly need to augment and annotate your data, and provide extra structure, especially for something like a point of sale system with very light metadata. “Data comes off these things in poor structure,” he says. “It’s not OpenLineage, it’s often a CSV or a text record, and you have to reconstruct them into a full structured log. So do smart things where you’re creating data. That might be compressing, sampling, converting, appending metadata to it, and enforcing schema and lineage all before you start moving anything.”

That doesn’t have to mean bloating your data, Hansen points out. He suggests capturing what’s free and unrecoverable. “The system of origin is the label,” he says. “You don’t tag HR policy, you capture that it came from the HR system. Anything a model can derive later, you can skip.”

Structure isn’t static

Routine changes to APIs, schemas, and how data is collected or stored happen in every organization, and need to be reflected in metadata that lives alongside the data or added as data is collected, not reconstructed later in a fragile process that depends on knowing about all those changes. Google’s research into these data cascades shows how easily context gets lost and how badly it affects data quality.

Shifting schema enforcement further left in your data pipeline so you deal with it as soon as possible allows you to make more effective downstream decisions. For a sensor recording temperature and humidity, you need to know the temperature scale it uses, readings, and how the timestamp is recorded. Checking that against the schema before ingesting the data lets you route it differently depending on whether it validates or triggers alerts about data quality.

“Maybe I’ll delete it, or send it off to some place where a human being or other tooling can reconstruct it into something valuable,” says Aronchick. “But what it doesn’t do is allow the polluted or bad data into my pipeline. Saying whether or not something passed your schema makes your downstream systems much more reliable.”

Sensing structure

Unstructured and semistructured data needs more augmentation. A PDF or Word document has an author and a creation date, but doesn’t necessarily include any context about the job title and department of the author, whether it’s up to date, only applies to a particular group of customers, or is based on accounting regulations that can change. If that information is available, it needs to travel with the document, not be left in a compliance spreadsheet.

Data platforms like DataHub and SurrealDB both capture and create context. The latter can analyze a photo, for instance, using vision AI to understand what’s in the image. “From completely unstructured data, we get as much structure as possible,” says the company’s CEO Tobie Morgan Hitchcock.

That’s paired with other data potentially useful for an AI agent down the line. “Understanding what happened around an event becomes a lot easier if you’re tracking the conversation, telemetry, tool and model usage, geospatial data, and the vector search and relationships,” he says. “You’re going to have a far better chance of getting an accurate understanding of that data, which started off completely unstructured, than if you weren’t capturing anything.”

Metadata about document authors, which might come from the company directory, can show how much authority a document has. He describes that as building an understanding of what trust and provenance is over time by the weight and authority of who’s updating the information. After all, he says, company-generated information has more trust or can have traced provenance compared to conversational inputs from a user.

Incentives for annotating

DataHub CTO Shirshanka Das saw how much of a mess data can be even with strong guidelines as former architect of LinkedIn’s GDPR strategy. “The data was a swamp, despite us having had pretty good data-first and schema-first practices,” he says. As well as cleaning up the data governance, they added in the first nuggets of the DevOps’ ‘shift left’ approach.

LinkedIn already required data checked in to its Kafka ecosystem to have a schema, and ran CI/CD pipelines to check backward compatibility. “I attached metadata attribution and collection around compliance metadata into that pipeline, where developers weren’t able to check in a schema until they had declared what every column meant.”

The extra work was unpopular until teams who didn’t participate saw the flood of tickets that came their way, which allowed him to extend that same proactive governance and annotation at source approach to pretty much every data set being produced.

“The starting point of data at most companies is a lot more swampy,” he says. “Many people are using Kafka, which is a very schema forward system, and yet they’re just shoving in JSON and unstructured stuff.”

That’s common, agrees Megha Kumar, research VP for analytics and AI at IDC, because while collecting more metadata provides better context and cleaner data lineage, it’s hard in practice. “Most organizations batch process data, so real-time context capture rarely happens,” she says. “Even the ones that process in real-time tend to have pre-defined schemas, so adding context requires changes to the data, which unfortunately happens later.”

People don’t know how to start, says Das, so DataHub Cloud tries to add back context by collecting operational metadata from multiple systems, including queries and BI tools to extrapolate a semantic model. “We confront the mess by giving them something they can react to,” he says. “They can quickly validate, and then it starts becoming a governance layer on top where humans annotate at source.”

Online whiteboard provider Miro, for example, dramatically improved AI agent query accuracy from about 50% to 90% using DataHub. Then they applied GitOps principles on top of what was inferred with a human in the loop for approvals.

So getting people to do the work happened the same way at LinkedIn, says Das. “When a data scientist gets 10 times more requests because they didn’t document their work well, resulting in the AI making lots of mistakes and stakeholders constantly pinging them for answers, they have the incentive to add the annotation when they produce an analysis, because then they get out of the critical path.”

DBOMs and data contracts

Provenance and lineage of data is critical, Aronchick says, so you can preserve details like who collected the data, when, from where, if the source was authoritative or canonical, what transformations were run, and exactly what the model saw.

“It’s not just about the version and the metadata,” he says. “Where things really start to change is when you can say along the way this data has gone through these steps, this is the root source, and these were the other elements.” You want to be able to find out if there were any experimental flags, like a new customer campaign running when it was collected, as well as what claims the data contributes to.

Aronchick advocates for a SLSA-style data bill of materials using a tool like Makoto, which can add signed provenance and attestation to simplify applying central concepts of governance and structure to upstream data.

The notion of a data contract or a data product spec is starting to become common in the financial sector says Das, defining it as a data set, or a group of data sets, bound together by a contract that defines expectations which aren’t just cosmetic but machine verifiable. They can also include operational SLOs for APIs as contracts describe not just the shape of the data but operational characteristics and guarantees.

Document graph markup language (DGML), a new open source specification from Docugami, promises provenance down to individual data points automatically extracted from documents.

“It’s critical to know the validity and provenance of the information your AI is relying on,” Docugami CEO and XML co-creator Jean Paoli says. “Establishing the validity of data right from the start, at scale, is vital and far more efficient than trying to clean up bad data later.” DGML combines semantic tags describing what content means in its business context with bounding boxes showing exactly where in the document the content comes from, with attestation to prove it.

AI demands provenance

All this context is the kind of metadata Anthropic’s context engineering guide recommends feeding to agents for accuracy. Developers are already used to giving coding agents more context, Das argues. “The same thing is happening with data, as when people realize when AI agents can’t make sense of what they’re doing, hallucinations happen,” he says.

Kumar agrees that organizations realize agents need context to provide better insights. “In many cases, it has to do with ensuring the existing data had clear semantics and relationships,” she says.

If you want to make sure the purchase return window an AI chatbot promises customers is based on your own policy, not a wish list from a user forum, you need rich context. It’s not just metadata. Organizations need to have semantics, data lineage, and ontologies. “Many are also building knowledge and ontology graphs,” adds Kumar. “By ensuring the systems understand what the data means, it’ll be able to provide a better response.”

And if you’re going to the expense of fine tuning, which needs relevant and domain- or task-specific examples, you don’t want noise, duplication, or irrelevant content in your data. You can, of course, exclude poor data if it’s annotated and verified earlier, but you can also improve model performance with extra information, Aronchick points out. “The augmentation of the existing data makes the data you pull out more valuable,” he says.

Expanso recently won an Edge AI award for fine tuning a base level model with only about 3,200 images by augmenting them with metadata. “The reason it worked on that few is because I could tell it deterministically what was in the frame,” he adds. “It’s labeling at the point of capture instead of paying somebody to label it later. What if I developed models for predictive analytics of store behavior on a per city, region, or country basis? If I’m able to take the raw point of sale information and augment it with additional metadata, I’m turning this into a much easier thing to fine tune.”

Or you might even avoid the expense of fine tuning entirely, suggests Das. “You get the short-term advantage by fine-tuning and getting great performance at much cheaper cost on a smaller model, and it gets stripped away in a couple of months as a new model shows up,” he says. “You have to always run that calculus of when’s the right threshold to fine tune an existing model, distil it, and then run it for a fair amount of time to recoup the costs of fine tuning.”

Although regulated or slow-moving industries will see benefits from fine tuning a model they can run for six to 12 months on data with higher quality and better provenance, many organizations may use the improved data quality to get good results without fine tuning.

“We’re taking a more knowledge graph-oriented approach to grounding the model, and betting on the fact that because the knowledge graph is changing often, it’s better to keep it as a runtime artifact than a baked-in one.”

The meeting that changed my perspective

I remember sitting there and realizing I wasn’t thinking about the model at all. I was thinking about the data feeding it.

One discussion stands out in particular. We were evaluating how predictive analytics could improve sales forecasting for a national portfolio of opportunities. Leadership wanted greater confidence in projected outcomes so resources could be prioritized earlier in the sales cycle. As conversations turned toward model accuracy, we discovered something more important. Different teams weren’t consistently recording opportunity stages, probability scores and client attributes. The model wasn’t struggling because it lacked sophistication. It was learning from business processes that had never been standardized in the first place. That meeting changed how I approached every AI initiative that followed.

Throughout my career leading enterprise business intelligence initiatives, I’ve repeatedly watched organizations blame the algorithm when the real issue was inconsistent data, fragmented ownership across departments and business definitions that meant different things to different teams. AI doesn’t distinguish between disciplined and inconsistent business processes. It learns from both with equal confidence.

I’d built and defended executive dashboards for years before that meeting, and dashboards had trained me to believe imperfect data was a manageable, even routine problem. Experienced leaders read a dashboard with context. They know which numbers to trust, which ones need a caveat and which gaps to mentally fill in based on what they already know about the business. Predictive AI doesn’t have that judgment. Machine learning assumes the historical data it’s trained on represents reality as it actually is. If two departments define “active customer” differently, or if a critical field has been silently incomplete for two fiscal years, the model doesn’t notice or compensate. It learns the inconsistency as ground truth, and it repeats that mistake at scale, with confidence, every single time it runs.

That moment fundamentally changed how I approach every AI initiative. I stopped starting with technology and started with data integrity instead.

5 questions I ask before any AI platform conversation

Today, I rarely begin AI discussions by talking about technology. Before any conversation about platforms or vendors, I ask five questions of the leadership team. Can we explain, in plain language, where this data actually comes from? Do the business leaders in the room agree on what our core definitions mean, or does “revenue” or “active account” shift depending on who’s presenting? Would we rely on this data to make a multimillion-dollar decision without a human manually double-checking it first? Is there a specific, named person accountable for every critical dataset, or does ownership dissolve the moment something goes wrong? And underneath all of it, are we actually solving a business problem, or are we chasing a technology because it’s the thing everyone else is talking about this quarter?

I remember one initiative where these questions prevented us from moving too quickly. During an early assessment, we discovered that two operational systems treated the same customer differently because each had evolved around separate business processes. Executive reports appeared consistent because manual reconciliation had become part of the monthly reporting routine. Once we identified the inconsistency, the project paused while business stakeholders agreed on common definitions and ownership. That decision delayed the AI initiative by only a few weeks, but it likely prevented months of troubleshooting after deployment. More importantly, it strengthened confidence in every analytics initiative that followed.

These conversations reveal far more about whether an organization is genuinely ready for AI than any vendor demonstration ever will. A polished proof-of-concept can make almost any dataset look production-ready for the ten minutes it’s on screen. These five questions don’t have that luxury. They tend to surface, quickly and uncomfortably, where an organization’s data confidence actually breaks down, and that’s the information leadership needs before committing budget and reputation to a rollout.

This lines up with what the NIST AI Risk Management Framework has argued for a while now: governance and accountability belong at the foundation of an AI initiative, not layered in after a model is already in production. Governance built in retroactively tends to be theater, built to explain a failure that’s already happened rather than to prevent one.

Leadership before technology

The organizations I’ve seen actually succeed with AI invest first in governance, ownership and shared business definitions, and only then in the platform itself. They clean up master data before they scale a model against it. They remove duplication in customer and product records. They assign accountability for datasets the same way they’d assign accountability for a budget line, with a name attached and consequences if it slips. This work rarely shows up in a demo, which is probably why it gets skipped so often in the rush toward deployment.

One lesson I’ve seen repeatedly is that assigning ownership changes behavior almost immediately. Once business leaders understood they were accountable for the quality of specific datasets, not just the reports generated from them, conversations shifted. Instead of asking why dashboards looked different, teams began discussing why the underlying business process produced inconsistent information. Governance stopped being viewed as documentation and became part of everyday decision-making. The improvements weren’t dramatic overnight, but they were sustainable, and that consistency ultimately mattered more than any individual technology upgrade.

I saw this firsthand during an executive reporting initiative where multiple leadership teams relied on the same performance dashboard but interpreted one KPI differently, because ownership had never been clearly assigned. Once the business designated a single owner for the metric and standardized its definition across reporting systems, disagreements disappeared almost overnight. More importantly, that same governance work later allowed predictive analytics to be introduced with confidence, because everyone was working from the same version of the truth.

I’ve learned that AI projects rarely fail in the data science team. They fail months earlier, when leadership assumes the organization already understands its own data.

McKinsey’s research on scaling AI reinforces this pattern at scale: the organizations that generate lasting value from AI are consistently the ones that pair the technology with real changes to their operating model and governance, rather than simply layering AI on top of how things already worked. That finding matches what I’ve observed leading enterprise analytics initiatives directly. The technology was rarely the constraint. The organization’s relationship with its own data was.

It’s tempting to frame AI adoption as an engineering problem with a leadership footnote, when in practice it’s closer to the reverse. CIOs reporting on rebuilding an AI-ready data strategy make a related point: treating data ownership as a purely IT issue stops working once business units, product teams and AI platforms are all generating and transforming data continuously, which is exactly why accountability has to sit with named business leaders, not a technical team working in isolation. A related piece on building an AI-ready data culture puts it more bluntly: an organization can’t scale AI without first scaling trust in its own data, and that trust starts with culture and ownership, not tooling.

I no longer ask whether an organization is AI-ready. I ask whether its leaders would bet on their own data without a human checking behind the model first. If the honest answer is no, the next investment shouldn’t be another AI platform or a more sophisticated model. It should be a stronger data foundation, built deliberately, with clear ownership, before a single additional AI use case gets greenlit.

If another executive asked me for one piece of advice before approving a major AI investment, I’d tell them this: spend one day interrogating your data before spending another dollar on your model. What that conversation reveals will tell you more about your organization’s readiness than any vendor demonstration ever could.

Organizations rarely fail because their AI isn’t intelligent enough. They struggle because they ask AI to learn from data that was never prepared to support intelligent decisions in the first place. The organizations that lead in this next era won’t be the ones with the most advanced models. They’ll be the ones that got their own house in order first, and knew it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

I have spent enough time building cloud and AI infrastructure to know one thing: Efficiency problems never show up where teams expect them. They tend to sit just beneath the surface, quietly shaping outcomes long before they appear in the metrics anyone is tracking. Most enterprise conversations still center on token pricing. That focus makes sense. The per-unit cost of using models has fallen quickly, and organizations want to understand whether AI can scale without pushing budgets out of bounds.

That question has become more complicated than it looks. At the same time, the nature of each interaction has changed. What used to resemble a straightforward exchange now involves retrieval and ongoing reasoning that unfolds across multiple steps. Even with lower unit costs, total consumption continues to rise because each request requires more underlying work. This creates a contradiction. Tokens are cheaper, yet overall compute demand keeps increasing. That compute demand has to go somewhere, and where it goes is a growing problem. 

The answer, increasingly, is the power grid. The International Energy Agency has warned that AI and data centers are becoming a major source of electricity demand, and Goldman Sachs Research has projected that data center power demand could rise 165% by 2030 compared with 2023 levels. Today, electricity consumption from data centers already amounts to roughly 415 terawatt hours, or about 1.5% of global electricity use, and has been growing at roughly 12% annually over the past five years. Much of the response has focused on models or hardware. Both matter, but they do not explain the full picture. In enterprise environments, a meaningful share of inefficiency begins before a model processes anything at all. It begins in the data layer.

The paradox: Cheaper tokens, more total compute

I have seen this pattern play out before. When unit costs drop, usage expands and everyone is surprised, every time. AI is following that same trajectory.

Lower token pricing has made it easier to integrate models into more workflows. Those workflows have also become more involved. Systems retrieve broader context and revisit outputs before returning a result. The additional activity outweighs the savings from lower pricing. In many cases, a system prompt alone can consume 2,000–5,000 tokens before a user even contributes input, which means the baseline cost of each interaction has already expanded. This is no longer just a financial consideration. Increased compute demand brings increased energy consumption, which is becoming a central constraint for enterprise AI.

Why agentic AI changes the energy equation

Average load: It rarely tells the full story. A platform can appear stable while quietly absorbing constant internal work that never surfaces to users. Agentic AI introduces that kind of persistent demand.

An agent continues operating in the background even after a user interaction ends. It checks for new inputs, revisits its internal state, then prepares the next action. That ongoing loop changes how infrastructure is consumed. Instead of handling activity in bursts, systems begin to carry a steady baseline load. Compute usage becomes continuous rather than intermittent.

This shift exposes inefficiencies that might otherwise go unnoticed. A slow query or a fragmented data source affects far more than a single request. The same issue repeats continuously, which increases both cost and energy consumption over time. This matters even more as inference workloads scale, with projections suggesting they could account for more than 40% of data center demand by 2030.

The overlooked source of energy growth: The data layer

In almost every architecture review I’ve sat through, attention gravitates toward model performance or infrastructure spend. The data layer gets treated as an afterthought. That assumption falls apart the moment you move into retrieval-heavy AI. 

Agents depend on access to reliable context. They pull information from operational systems as well as analytical platforms. When those sources are disconnected, each interaction requires additional effort to assemble a usable view.

That effort accumulates quickly. Data must first be located before it can be used. It often needs to be moved into another environment, then reshaped into a format the model can process. Only after that does it become useful for decision-making. Each step introduces overhead that consumes compute and energy. In practice, engineers can spend up to 40% of their time preparing data before it is even usable for downstream systems. The model remains the most visible part of the system, but the surrounding data work often determines how much energy the system ultimately uses.

Fragmentation as the root cause

Enterprise architectures evolve over time, and fragmentation usually reflects a series of reasonable decisions rather than a single mistake. The challenge appears when AI systems need to operate across all environments at once.

Fragmentation forces repeated work. Systems retrieve overlapping datasets because no single source is trusted as authoritative. Pipelines reprocess information that already exists elsewhere. Teams build parallel structures instead of relying on shared ones.

This pattern increases demand in ways that are easy to overlook. When retrieval becomes inconsistent, applications compensate by sending more context than necessary. Models then process larger inputs, which increases token usage without improving the quality of the outcome. What appears to be a model efficiency issue often traces back to data architecture. It also helps explain why as many as 60% of AI projects are abandoned before reaching production, often due to gaps in data readiness rather than model capability.

Why sovereign, unified architecture changes the math

I have seen organizations improve efficiency without changing models simply by reducing friction in how data is accessed. The good news is that the fix is closer than most teams assume. 

A more unified architecture shortens the path between a question and the data needed to answer it. When systems can access authoritative data directly, they avoid repeated transformations and unnecessary duplication. Retrieval becomes more precise, which allows models to operate with less excess input.

This does not require consolidating everything into a single system. Enterprises will continue to operate across multiple environments. The objective is to reduce unnecessary movement and make data easier to use wherever it resides. Sovereignty and control play an important role as well. Organizations operating across different environments need a clear understanding of where data resides and how it can be used. When governance is built into the architecture, systems spend less time reconciling access and more time producing results. Reducing friction at this layer has a direct effect on both cost and energy use.

What 2026 will expose

The next phase of enterprise AI will shift attention from access cost to operating cost. Early efforts focused on whether organizations could use advanced models. The next stage focuses on whether those systems can run continuously across real workflows without creating unsustainable demand.

That shift will make energy consumption more visible. It will also make inefficiencies harder to ignore. Some increase in demand reflects real value. Systems that improve decision-making or streamline operations will naturally require more compute. The more difficult question is whether additional consumption reflects useful work or avoidable overhead.

When systems repeatedly move and reprocess the same data, the increase in energy use does not correspond to better outcomes. It reflects architectural inefficiency. CIOs will need to examine that distinction more closely.

The takeaway for tech leaders

Before adding infrastructure, ask an honest question: Is this capacity supporting real growth, or is it just hiding inefficiencies that should have been fixed first? Start with the data layer.

Review how systems retrieve context. Look for duplication across environments. Identify where data is repeatedly transformed before it becomes usable. These patterns reveal whether the architecture is enabling efficient AI or creating unnecessary demand.

Enterprise systems will always involve complexity. The objective is to ensure that complexity does not translate into avoidable work. In the agentic era, the efficiency of AI systems is closely tied to how much work happens before the model produces an answer. Data architecture plays a central role in determining whether that work remains controlled or expands beyond what is necessary.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?