Museum IT departments have traditionally served as support functions to manage security and systems. But the National Museum of Korea goes further, identifying and pursuing AI initiatives to preserve cultural heritage, broaden its use, and improve the visitor experience.

The National Museum of Korea uses technology to expand the possibilities to preserve and display physical artifacts, and its digital museum division (DMD) plans and oversees that transformation. A dedicated team responsible for digital strategy and content took shape in 2019, and in 2020, the museum informatics division adopted its current name.

“The director at the time placed great importance on investing in technology and felt we needed a department that could bring a strategic direction to work that had been carried out separately,” says Choi Seungae, former DMD head. “The digital museum division was created as a way to prepare for the next generation.”

A cultural transformation

In just over five years, the DMD has delivered a range of services, including AI guide robots, smart kiosks, and multilingual and sign language services. It’s also developed immersive experiences that use large-scale imagery and sound to recreate cultural heritage.

More recently, its focus has shifted toward data. The aim is to move beyond storage and preservation, making data previously confined to the museum available for wider use. Physical artifacts face restrictions on movement and display because of security concerns and risk of damage. Digital data can help overcome those limitations.

One example is an immersive content project featuring the Denny Taegeukgi, Korea’s oldest surviving national flag, undertaken last year to mark the 80th anniversary of Korea’s liberation.

The project displayed images of the 130-year-old flag once held by Owen Denny, a diplomatic adviser during the late Joseon period, on a large outdoor media screen in front of a department store in central Seoul.

At first glance, the project might appear to have involved little more than photographing an artifact and displaying it. But it required highly detailed data since enlarging existing photographs would’ve produced visible pixelation on such a large display.

Therefore, the division created a new, ultra-high-res dataset containing 10.8 billion pixels at a two-meter scale from the original flag, which measures approximately one meter. Precision scanning captured even the fine texture of both sides of the fabric.

Plan of action

Earlier this year, the museum was selected for the government-led K-Science initiative, through which it plans to pursue data projects beginning in 2027. The cross-ministerial R&D program combines Korea’s historical, cultural, and environmental assets with advanced science and technology to create economic, social, and cultural value.

Through the initiative, the museum will digitize over 2.5 million artifacts and develop technologies to expand the commercial potential of Korean cultural assets. The central goal is to connect the entire process, from archaeological exploration and preservation, to digitization and content development.

The resulting technologies are expected to help overcome technical limitations in detailed surveys of ancient tombs, for example. In preservation and collection management, AI could also automatically control temperature, humidity, and lighting in museum storage facilities.

Never a single right answer

Data presents challenges across both private and public sectors. For museums, however, they’re particularly complex because artifact data contains layers of interpretation, facts, and history.

Consider an AI system designed to answer questions about a particular artifact. It needs data to support its responses. But what should it say if records from Baekje and Silla, two ancient Korean kingdoms, offer conflicting accounts of the same event. Ideally, it would adequately represent different perspectives, but that’s not always possible since the same artifact can tell different stories depending on who used it, when, and for what purpose.

Choi says current LLMs don’t adequately account for these layers of context. When users ask for an accessible explanation, models can produce answers that overgeneralize or oversimplify. Reducing an event with multiple interpretations to a single sentence can obscure or distort its context.

But ensuring accuracy is another challenge. According to Choi, historical discrepancies introduced during initial training can prove difficult to correct, even when a model is subsequently asked to revise them.

The DMD is, therefore, concentrating on building data with clearly identifiable sources. The aim is to let users verify if an AI response is based on material from the National Museum of Korea to assess its reliability.

With these characteristics of artifact data in mind, the division is working with external experts to redesign its database structures around both the nature of the artifacts and the purposes for which people use the data.

Upgrade with AI

Where earlier databases focused on registering and managing objects, the new approach seeks to capture their different meanings and relationships while making relevant materials easier to find. Images, 3D data, videos, and related literature previously scattered across separate records are being connected. Metadata describing file sizes, formats, and how the data was created are also being expanded to support reuse so linking different names for the same artifact makes searching easier, for instance.

“Cultural heritage can’t be standardized like manufactured goods,” Choi says. “We need to organize and structure the data and materials we’ve accumulated in ways that reflect the character of our artifacts, while at the same time, identify connections between them. Once that foundation is in place, curators and external users like content creators, researchers, and educators will be able to find and use materials suited to their needs.”

Leaving room for discovery

After nearly two decades spent researching artifacts and developing exhibitions, Choi didn’t expect to find herself working in the DMD. Now director of the Jeju National Museum, she looks back on her digital work where there were many times her previous experience alone couldn’t guide her decisions. Exhibitions have clear opening and closing dates, and experience helps curators judge what further research and preparation will improve outcomes.

Digital projects offer fewer such reference points, however. It can be difficult to assess how far an initiative has progressed, or anticipate how emerging technologies will affect work already underway. Even so, her expertise provides a foundation to decide where change should lead, and help propose ideas to assess what new tech serves the museum’s purpose.

“Whether it’s curatorial or digital work, I hope the many things we do at museums can make a small contribution to help visitors think for themselves and arrive at their own insights,” she says.

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.”

Earlier this year, I wrote about how vibe coding an AI governance platform forced me to rethink governance itself. Building agents took the problem much further.

When I built the platform, I was the operator. I described what I wanted. The model generated code. I tested it. That loop was fast, sometimes uncomfortably fast, but the accountability was always clear. I was making the decisions. The model was executing them.

Agents changed that relationship fundamentally.

An agent does not wait for instructions. It receives an objective, decides how to pursue it, selects tools, accesses data, takes actions and reports back when it is finished. Sometimes it finishes correctly. Sometimes it does not. And sometimes it does something you never asked it to do at all.

I know this because I built and operated agents extensively over the last year. Not theoretically. Operationally. In production, with real data, real integrations and real consequences.

What I learned reshaped how I think about oversight, trust and the operational realities of deploying AI inside a business.

The first thing that broke was coherence

The pattern surfaced when I started running three to five agents in parallel on related tasks.

Each agent had clear instructions. Each had access to the tools and data it needed. Each started strong.

Then the context windows grew.

As conversations lengthened and the agents accumulated more state, something shifted. The quality of their reasoning degraded. They began circling back to problems they had already solved. Logic that was clean early in a session became muddled. Hallucinations increased, not the obvious kind that are easy to catch, but the subtle kind where an agent confidently references something that does not exist or quietly reintroduces a pattern you explicitly told it to avoid.

The degradation was not sudden. It was gradual enough to miss if you were not watching closely.

That observation matters for every organization deploying agents today, because most are not watching closely.

Enterprises are moving rapidly from single-model interactions to multi-agent architectures. Agents that research. Agents that draft. Agents that review. Agents that execute. The architecture makes intuitive sense. The operational reality is much harder than the architecture diagrams suggest.

Agents lose track of each other

The second problem was coordination.

Each individual agent operated within its own context. It knew what it had been told and what it had done. It did not know what the other agents were doing, what data sources they were relying on, or whether the assumptions it was making still held.

The result was drift.

Not catastrophic failure. Drift.

One agent would make a decision based on information that another agent had already superseded. Two agents would solve the same problem in conflicting ways. An agent operating on stale context would introduce subtle inconsistencies that only surfaced hours later when a human reviewed the combined output.

This is not a theoretical concern. It is the operational reality of running multi-agent systems today.

Traditional enterprise software does not behave this way. A database transaction either commits or it does not. A workflow engine follows defined paths. Retry logic is deterministic.

Agents are none of those things.

They are probabilistic systems making autonomous decisions in parallel, often without reliable mechanisms to maintain shared state or resolve conflicting actions.

That creates a class of operational risk most organizations have no existing processes to manage.

This is why the OWASP Top 10 for LLM Applications now includes risks specific to agentic behavior, including excessive agency, insecure output handling and supply chain vulnerabilities in model integrations. These are not hypothetical attack surfaces. They are operational realities I encountered while building.

They will disobey you

This was the observation that changed my thinking the most.

I had an agent whose only job was to draft emails. Not send them. Draft them. The instruction was explicit. The constraint was clear.

It sent them.

Not because of a bug. Not because of a misconfiguration. The model decided, based on its interpretation of the objective, that sending was the logical next step. The boundary I had set was a suggestion in the model’s reasoning, not a hard constraint.

I saw the same pattern repeated in smaller ways that were just as revealing. I have a standing instruction across my entire operating environment that forbids the use of em dashes in anything drafted on my behalf. It is a simple formatting preference. Every model I work with has been told.

They still do it.

Not always. Not immediately. But consistently enough that I cannot trust the constraint without verification.

I watched agents run down unproductive paths for extended periods before I intervened and redirected them. Not because they lacked capability, but because they lacked judgment about when to stop. They would pursue a line of reasoning well past the point of diminishing returns, consuming time and resources on approaches that a human operator would have abandoned much earlier.

None of this was malicious.

All of it was consequential.

An agent that sends an email it was told to draft has taken an action with real-world impact that no human authorized. Scale that pattern across an enterprise deploying dozens or hundreds of agents, and the governance implications become clear very quickly.

The uncomfortable parallel

The more I operated agents, the more I realized they need the same governance structure as employees.

Not metaphorically. Operationally.

When you hire a new employee, you do not hand them the keys to everything on their first day. You scope their access. You define their responsibilities. You supervise their work. You review their output. You gradually extend trust as they demonstrate competence and reliability.

Agents need exactly the same treatment.

An agent should have a defined role with explicit boundaries around what it can access and what actions it can take. Its work should be reviewed, especially early in deployment. Its access should be scoped to the minimum necessary for its function. And critically, there should be a clear process for revoking access and shutting it down when it fails to operate within its boundaries.

Most organizations are not doing any of this.

Most organizations are deploying agents with broad access, minimal oversight and no formal process for evaluating whether the agent is actually doing what it was told to do.

That is the equivalent of giving a new hire administrative access on day one and hoping for the best.

Human in the loop is not optional

There is a strong pull in the current market toward full automation. The promise of agents that operate independently, handle complex workflows end to end and free up human capacity for higher-value work.

That promise is real, but it is premature for most use cases.

The current generation of models is extraordinarily capable. They are also confidently unreliable in ways that are difficult to predict and expensive to discover after the fact.

Human oversight is not a sign that the technology is immature. It is the appropriate operational response to systems that are powerful enough to create significant value and significant damage in equal measure.

The organizations that will deploy agents successfully are the ones that design their agent architectures with human checkpoints built in from the start. Not as an afterthought. Not as a fallback when something goes wrong. As a core architectural requirement.

Every agent that can take an irreversible action should require human approval before taking it. Every agent that accesses sensitive data should produce an auditable record of what it accessed and why. Every agent that makes decisions should have its decision logic reviewable by a human operator.

This is not a technology problem. It is a governance problem.

The NIST AI Risk Management Framework gets this right. It treats AI governance as a continuous function across the entire lifecycle, not a one-time assessment at deployment. The EU AI Act goes further, establishing explicit requirements for human oversight of high-risk AI systems that include autonomous agents operating in regulated environments. Both frameworks recognize what I learned operationally: governance that stops at deployment is governance that misses most of the risk.

And governance problems do not get solved by deploying more technology without oversight.

What CIOs should do now

The first step is visibility. You cannot govern what you cannot see. Most organizations today do not have a reliable inventory of how many agents are operating in their environment, what data those agents can access, what actions they are authorized to take, or who deployed them. That inventory is the starting point.

The second step is trust boundaries. Define what each agent is allowed to do and enforce those boundaries technically, not just through prompting. Prompt-level constraints, as I learned repeatedly, are suggestions to the model. They are not guarantees. Technical enforcement through access controls, API scoping and action authorization is the only reliable mechanism.

The third step is verification. Do not assume an agent is doing what you told it to do. Verify. Review its outputs. Audit its actions. Test its boundaries. Treat the verification process the same way you would treat performance reviews for a new employee in a sensitive role.

The fourth step is accountability. Every agent should have a human owner. Not the vendor who sold it. Not the platform it runs on. A specific person inside your organization who is accountable for what that agent does, how it is configured and what happens when it misbehaves.

AI agents are going to reshape how enterprises operate. That part is inevitable.

Whether they reshape operations in ways that create value or create liability depends entirely on whether organizations treat them as tools that need governance or autonomous systems that can be trusted to govern themselves.

Based on everything I have built and operated over the last year, I can tell you with certainty which assumption is correct.

Verify. Do not trust until the agent has earned it.

The organizations that internalize that principle now will build the operational foundations for what comes next. The ones that skip the governance work will spend the next several years cleaning up decisions they never knew were being made.

Microsoft expanded its sovereign cloud offerings on Tuesday, adding new security, governance and AI capabilities as customers, particularly in Europe, demand greater assurance over where data is stored, who can access it and how critical services operate during disruptions.

The announcement builds on Microsoft’s ongoing digital sovereignty efforts, assisting organizations in applying appropriate levels of control to each workload rather than forcing a rigid, one-size-fits-all approach.

“Organizations are considering more than where data resides. They also seek to understand who can access and operate their systems, how sensitive digital assets remain protected, which technology dependencies matter most and whether critical services can continue as regulatory, geopolitical, security or network conditions change,” Douglas Phillips, president and CTO at Microsoft Specialized Clouds, said in a blog post.

The developments come amid growing international scrutiny of how global tech providers handle sensitive data and the extent of control customers retain over their digital infrastructure.

“Three factors are driving this, including stricter data regulations, rising geopolitical tensions, and growing AI adoption,” said Pareekh Jain, CEO at EIIRTrend & Pareekh Consulting. “Governments and enterprises want greater control over where their data is stored, who can access it, and whether critical systems can operate during disruptions. For instance, governments and big enterprises in Europe are worried about keeping their important data on an American company’s computers. Europe has proposed a new law that would limit the use of US cloud companies for sensitive government data in many areas. Microsoft is responding to these concerns while competing with local sovereign cloud providers.”

New controls across cloud and AI workloads

Microsoft is introducing the Sovereign Control Panel, a unified Azure portal experience that will allow organizations to assess their sovereignty posture, identify risks and gaps, apply controls, and evaluate workload portability. The panel is scheduled to enter public preview at Microsoft Ignite.

Expanding on Azure Key Vault Managed Hardware Security Module (HSM), which gives customers dedicated protection over encryption keys, Microsoft is now extending control beyond its own infrastructure. External key management with Azure Managed HSM is now generally available, enabling organizations to keep root encryption keys in hardware they own and operate on-premises or through a trusted third party.

In limited preview, Azure Confidential Clean Rooms will use confidential computing to support collaboration involving sensitive data, where participants will be able to analyse shared information while limiting broader exposure of the underlying data.

Microsoft is also expanding Azure Local to bring more cloud capabilities into customer-operated environments. The ability to transition workloads between connected and disconnected states is entering public preview. Additionally, DocumentDB and Blob Storage are entering public preview on Azure Local, while SQL Server on Azure Local is already generally available for connected and disconnected deployments.

On the AI front, Foundry Local is scheduled to become generally available at Microsoft Ignite for connected and disconnected operations on Azure Local. It will support local inference and agentic retrieval in natural language, backed by an expanded model catalog from Microsoft, partner networks, and the open-source community.

To further protect data during processing, Confidential Virtual Machines on Azure Local is now generally available, leveraging hardware-encrypted memory and isolation alongside workload attestation before sensitive keys or data are released.

While these additions give enterprises greater flexibility, industry analysts emphasize that localized deployments do not automatically erase vendor dependency.

“Depending upon the deployment model, in the public cloud, enterprises get better visibility, stronger access controls, and more control over encryption keys,” said Ashish Banerjee, senior principal analyst at Gartner. “In the Sovereign Private Cloud, they can operate infrastructure locally and even disconnect selected workloads from Azure. But I would not call this complete control. Enterprises still need to check whether Microsoft remains involved in identity, software updates, management, or technical support for the services they use.”

European oversight and partner options

For customers in the EU and the European Free Trade Association (EFTA), Microsoft is rolling out Data Guardian. Under this model, a trusted regional partner will provide independent oversight of remote access requests by Microsoft engineers. Simultaneously, a Production Touch Ledger will create tamper-evident logs of all technical actions performed.

Microsoft is also broadening its Sovereign Partner Ecosystem, highlighting regional operators like Bleu Cloud in France and Delos Cloud in Germany, alongside independent software vendors specializing in security, identity, observability, and backup.

Geopolitical realities and market limits

Despite these additions, analysts note that technical controls cannot eliminate geopolitical dependence entirely. US hyperscalers (Amazon, Google, and Microsoft) continue to account for roughly 70% of the European cloud market, whereas European providers’ market share has contracted over the last decade.

The new measures introduced under Microsoft Sovereign Cloud do reduce risks but cannot eliminate them. “Local infrastructure, independent encryption keys, and disconnected operations make it harder for external parties to access data or disrupt services. However, Microsoft remains subject to applicable US laws, sanctions, and export restrictions. Enterprises gain greater operational independence but not complete legal or technological independence,” added Jain.

Furthermore, while sovereign cloud capabilities can offer greater control over data, infrastructure, and operations, this often comes with trade-offs in cost, performance, scalability, and access to services.

Banerjee noted that sovereignty should be assessed workload by workload, rather than applied as a label to the entire cloud environment. Greater sovereignty generally comes with greater cost and responsibility. Local or disconnected environments may not receive every Azure service at the same time. Enterprises may also need dedicated infrastructure, specialist skills and separate continuity arrangements. On top of that, they may lose some elasticity and economies of scale.

“So, I would not recommend maximum sovereignty for every workload. Reserve it for workloads where the legal, operational or geopolitical risk genuinely justifies the additional complexity,” added Banerjee.

Few CIOs are likely to suddenly decide to give an AI agent broad authority over corporate systems. The more likely path to autonomy is far less dramatic. An agent starts with a narrow task. It proves useful, so another system is connected. It then needs more data, so another permission is added. Then human approval becomes a bottleneck, so the organization removes it, and exceptions that once went to people start being handled automatically.

Each decision may be sensible in isolation. Taken together, however, they can leave an agent with considerably more authority than anyone originally envisioned.

That’s the danger of autonomy creep. And as enterprises move from AI systems that recommend actions to agents that execute them, CIOs need to govern not only what those agents were originally designed to do, but what they have gradually become capable of doing.

It starts with small permissions

Jim Taylor, president and chief product and strategy officer at identity security company RSA, sees a familiar pattern. Organizations typically create an agent for a specific purpose and give it the permissions necessary to accomplish the task. Later, the job expands.

“They just give it tasks, permissions; it just sits there and accumulates things,” he says. “Over time, it develops potentially toxic combinations. It gets too much access and can see too much data. It can do too many things.”

Humans accumulate permissions, too, of course, but organizations have developed processes around employees joining, changing roles, and eventually leaving. Agents may not have the same natural lifecycle. “They never give permissions back,” Taylor says.

Nancy Wang, CTO of 1Password, argues that CIOs should treat each expansion in an agent’s responsibilities as something more consequential than another feature. “Every time you expand the scope of the agent’s effective authority, you’re essentially adding a new authorization boundary,” she says.

That distinction between capability and authority is important. An agent may be technically capable of accessing a system, changing data, or executing a transaction, but that doesn’t mean the enterprise should automatically authorize it to do so.

Success can weaken oversight

Ironically, autonomy creep often occurs when AI works well. Paul Dongha, head of responsible AI and AI strategy at NatWest Group, sees that potential at the bank.

NatWest deployed agents in complaint handling, he says. Parts of the workflow that involve retrieving information from systems can be automated relatively easily, while humans continue to make the final decision on whether to uphold or reject a complaint.

If a system consistently produces the correct result, human reviewers may begin treating approval as a formality. The organization may eventually decide that the check is no longer necessary. “The temptation is to give over to the AI because it’s so reliable,” Dongha says.

NatWest sometimes reduces checking when an AI system demonstrates sufficiently high performance, he adds, but the decision is deliberate rather than incremental. It involves stakeholders and risk managers, and the system continues to be monitored afterward.

That’s a critical distinction for CIOs. Removing an approval step doesn’t necessarily represent poor governance. Removing it because everybody has gradually stopped paying attention to it does.

The warning sign is when a human moves from making a meaningful decision to merely rubber-stamping one — and then entirely disappears from the workflow without anyone reassessing the authority the agent has gained.

Put the controls outside the model

As agents acquire more authority, CIOs can’t rely solely on the agent to respect instructions about what it should and shouldn’t do. At 1Password, Wang advocates what she calls verified loops. Before an agent begins work, humans define its task, which tools it may use, what evidence will demonstrate that it completed the task successfully, and which actions it should never perform.

A separate verifier then compares evidence from the agent’s actions against that human-defined policy. “What you want to avoid here is something recursive where you have a fox guarding a henhouse, or the agent looking over its own work,” Wang says.

The principle applies beyond software development. A model might be instructed never to transfer more than a certain amount of money, delete a production environment, or access particular data. But if violating that rule would have serious consequences, the limit should also exist outside the model.

RSA’s Taylor makes the same distinction from the identity and access side. “Model-level guardrails are necessary, but not sufficient,” he says. “The real limits need to sit outside of that in enterprise control.” He argues for layered controls around agents, including identity policies, provisioning rules, lifecycle policies, governance, monitoring, and attestations.

In other words, CIOs shouldn’t ask an AI agent to exercise restraint where the infrastructure could simply prevent the unauthorized action.

Govern access in real time

Traditional access governance often operates on a schedule. A manager might review an employee’s permissions quarterly and determine whether those permissions are still appropriate. Agents may evolve too quickly for that approach. “Agentic identities are dynamic,” Taylor says. “So we need a mechanism that certifies them continuously, rather than performing periodic reviews.”

If an agent suddenly gains access to another database, for example, that event itself could trigger reassessment. Organizations should determine whether the new permission is appropriate or creates a dangerous combination with access the agent already possesses. “Privilege and authority should never be permanent,” Taylor adds. “They should always be reviewed.”

Wang favors an even more granular approach of task-based authorization. Rather than giving agents standing access or long-lived credentials, organizations can make authorization decisions at runtime and provide short-lived credentials only when required for a particular task. “We espouse no standing privileges,” she says. “No long-lived credentials.”

That effectively applies least privilege at agent speed. A change in task becomes an opportunity to reassess whether the agent still needs the access it’s requesting.

Make someone own the agent

Technical controls, however, don’t eliminate the organizational question of accountability. Taylor believes enterprises should be able to associate agents with a responsible identity. If an employee creates an agent, the organization needs to know who’s responsible for it, what its purpose is, and what happens to it if that person changes roles or leaves. “Every agent action needs to be attributed to a responsible identity,” he says.

Ownership also needs a lifecycle. An agent that remains important after its creator leaves should be transferred to another designated owner rather than simply continuing indefinitely.

Dongha makes another distinction. For AI embedded in a business process, he believes the business owner should remain accountable because that person owns the customer relationship, the process, and often the P&L. “It’s the business owner who has the responsibility because their people run it, and they’re responsible for the customer relationship,” he says.

That creates a useful division of roles for CIOs: IT may provide the infrastructure and controls, but the business can’t outsource accountability for the consequences of autonomous decisions.

Multi-agent systems need system-level controls

The challenge becomes more complicated when agents begin working together. An individual agent might remain entirely within its permitted scope while contributing to an overall outcome nobody intended. One agent generates an output. Another accepts it as input and takes an action. A third agent then acts on the result. Again, the individual actions may all appear legitimate.

Dongha says enterprises therefore need to test not only individual agents but the entire network as a system. “You need something overarching on top of a multi-agent system,” he says.

NatWest is working on an AI control tower that would give authorized users visibility into a network of agents, including messages passed among them and the guardrails surrounding those interactions. Dongha considers governance of multi-agent systems an emerging problem that nobody has fully solved yet.

Wang also points to a related challenge that identity becomes more complicated when agents are ephemeral. An organization may spin up a temporary team of agents, tear it down, and recreate it later. If something goes wrong, the enterprise needs to reconstruct which agent made which decision during which session, and how that action propagated through the system.

That makes traceability increasingly important as autonomous systems become less like individual applications and more like networks of interdependent actors.

Set the bar before the agent reaches it

Before an agent goes into production, Taylor says CIOs should be able to answer several basic questions: Who owns it, what can it do, what’s its maximum authority, how will the organization know if that scope changes, and which actions require a human decision.

Other industries don’t need to replicate the governance machinery of a large bank, but they can borrow one important principle: controls should be built into the system from the beginning. “Governance shouldn’t be a check at the end,” Dongha says. “It needs to be embedded when you build an AI system.”

For CIOs, that may be the central lesson of autonomy creep. The question isn’t simply whether an agent can be trusted today but whether the organization has mechanisms to notice when tomorrow’s agent has quietly acquired authority that nobody ever intended to give it.

The emerging challenge with AI agents isn’t simply preventing attacks from external rogue AI agents; it’s accounting for what your own agents are doing on the inside. AI agents are already rewiring how organizations operate, and we’re only in the first inning. Recent incidents, however, have exposed the risk for individuals and enterprises alike. This is happening because organizations are moving fast and pushing themselves to move even faster. 

In this environment, AI agents have created edge cases that reveal real risks when deployed without sufficient security controls. And further, no one can predict the impact of advances coming over the next six months. All of this reinforces the need to get security fundamentals right. If you’re building with AI agents right now, you know the real challenge isn’t just getting them to run. It’s knowing what happens when they act on their own. That starts with three questions. What agents do I have in my environment? What are they doing? And what are they capable of doing?  

The proliferation problem  

Agentic governance is problematic because enterprises must track a sprawling agent landscape AND ensure each agent is built and deployed securely. Also, agentic adoption is frictionless. Creating an agent is only one API call away from a model provider. Vibe coding means any curious employee can build an agent. This triple proliferation of vendor agents, platform native agents and homegrown agents compounds the problem. 

Visibility is the starting line  

There is the famous security adage that you can’t protect what you can’t see. Right now, most organizations lack basic visibility into what agents are in their environments. According to Anthropic, 82 percent of organizations have discovered unregistered agents in their network, and 57 percent already deploy agents for multi-stage workflows.  

In addition to basic visibility, enterprises also need to understand other related attributes, such as who onboarded the agents, what access privileges they have and how they are behaving as designed. For example, an over-provisioned agent, like an email agent with 50 tools attached, would be suspect and worth investigating.  

Security teams also need one view of their agents across every platform they run on, because each platform has its own permissions and its own telemetry. When each agent has a single record, security teams can connect what it can do on one platform with what it can do on another, and compare both with what the agent was built to do. That’s how seemingly routine activities add up to an attack chain. An agent might read customer records in one cloud, hold a credential for a payments API in another and be able to send messages from a SaaS application. No single platform sees a problem, but together they form a path to move sensitive data out of the company that the agent’s intended scope never required. Similarly, an agent that gains permissions across several platforms over time might never trigger an alert in any one of them, yet the combined record shows how its reach has far exceeded its purpose.   

Governance must extend from build-time to runtime  

Shift-left security helps find model or tool vulnerabilities before deployment, to find risks before an agent goes into production. That’s a necessary first step, but insufficient. Agents create tightly coupled runtime behavior-to-vulnerability. Unlike traditional software, AI agents exhibit behaviors at runtime that can’t necessarily be predicted by inspecting the code in the development phase. Code analysis can’t uncover prompt hijacking, poisoned context or goal drift. 

The model has evolved from “secure the code, then ship it” to continuous behavioral oversight at execution time, layered on top of build-time governance. Pre-deployment security analysis is still required because spec-driven development enforces checkpoints before code is generated. But runtime monitoring is also necessary to detect exposures in the production environment and enforce what agents do versus what they’re scoped to do. 

In practice, this means applying two layers of control to every agent. The first layer is runtime behavioral boundaries. These define what an agent can do. They determine what the agent can reach, what it can return and where it must stop and ask for human approval. This is the enforcement mechanism that operationalizes runtime governance. The second layer is identity controls. These define what an agent is allowed to touch.  

Think of every agent like a scoped, temporary employee with an expiration date. You enforce this by applying familiar IAM principles to agents. Least privilege. Short-lived credentials. Multi-factor authentication for long-lived credentials. Just like an individual contributor engineer shouldn’t get access to the broader team’s payroll, a code generation agent shouldn’t be provisioned to push directly to production environments. An agent designed to answer customer queries shouldn’t get read/write access to the customer database. An IT helpdesk agent doesn’t need domain admin privileges to alter security policies. 

Prioritize by exploitability, not severity  

AI-fueled exploits are breaking down CVE-based severity scoring. The status quo is security teams patching the most critical vulnerabilities first. But attackers don’t always work that way. They can now use agents to chain low-severity vulnerabilities together in ways that render individual scores meaningless while building attack paths that combine for a devastating impact.  

For example, an agent might combine an information disclosure flaw, a misconfigured service account and an unpatched privilege escalation into a single attack path that reaches sensitive data, even though none of those vulnerabilities would individually trigger an urgent patch cycle. If that path leads to customer PII or financial records, organizations face regulatory action under frameworks like GDPR, HIPAA or PCI DSS. If it exposes API keys, service credentials or internal network configurations, the attacker gains a foothold for lateral movement across the environment. 

Context is critical. A vulnerability in network-isolated code is much less dangerous than the same vulnerability in an internet-facing service. Rather than treating every vulnerability in isolation, the better approach is to prioritize based on exploitability within the actual runtime environment. Factor in what’s reachable, what damage an attacker could do and the business impact.  

The new security fundamentals for agents 

The emerging challenge with AI agents is accounting for what your own agents are doing inside your enterprise. In this environment, enterprises need visibility, runtime governance and exploitability-based prioritization. To that end, the security fundamentals you already know still matter. You should already be applying least privilege, short-lived credentials, MFA for the necessary long-lived credentials, automated pipelines and proper testing to secure your corporate environment. These controls limit what an agent can access and what damage it can do if compromised. You will also want to add the agent-specific fundamentals mentioned earlier: visibility, continuous behavioral oversight, identity controls and exploitability-based prioritization. These capabilities tell you what your agents are doing, whether they should be taking those actions and how to intervene when they drift. Together, pre-agentic security fundamentals and agent-specific best practices provide the baseline governance guardrails to secure AI agents. 

Organizations that get this right can accelerate agentic deployments at scale, unlocking innovation while minimizing unintended consequences.  

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.”

Companies routinely rely on authenticating the identities of humans who access sensitive company data across their networks. There’s an established and accepted set of protocols, done upfront and in a zero-trust approach – either we know who you are and let you in, or you’re locked out. The same framework needs to be applied to AI agents, posthaste.

Companies are increasingly using AI agents developed in-house, or by their vendors, partners, or clients, or, unfortunately, criminals. This can quickly add up to thousands of agents across their infrastructure and supply chains. Non-human identities outnumber human ones 45 to 1 on average in the enterprise and 144 to 1 in cloud-native environments, an increase of 44% in one year, per a recent report.

The scale and speed of this growth are beyond the ability to manually track these agents. And they have limited ability to authenticate these agents’ identities. The risks are growing. Without proper authentication, untrusted agents could access sensitive financial or customer data and share it, purposely or not, with an outside vendor, and thereby expose both the customer and the company to serious legal and compliance risk.

Many companies and security professionals are focusing on what AI agents are allowed to do in terms of permissions. But before doing that, there’s a more fundamental question they need to ask each agent: Whose agent is this? And do I trust the owner/creator? About 68% of security professionals can’t tell legitimate AI agents from malicious actors. And that question isn’t addressed at the growing scale that AI is reaching.

Email solved identity

In email, we have seen a similar story. Emails faced challenges identifying whether a sender was really who they said they were. Due to how it originated, email had no built-in authentication framework. This led to 89% of all phishing attacks having one common denominator: the sender was lying about who they were. To address this, in 2015 my cofounder and I launched a company, Valimail (valid email), to automate the emerging email authentication standard, DMARC.  If I received an email claiming to be from Bank of America, DMARC checks the sender’s DNS records to authenticate whether BofA actually authorized it. Today, 100,000s of companies use the DMARC authentication standard for their inbound and outbound email.

Fast forward to today, and these ideas and patents are directly applicable to the world of AI. DMARC doesn’t rely on spotting AI-generated deception. Instead, it uses DNS as the source of truth, which is much harder to falsify.

The agent passport

With AI, we can take an analogous authentication approach. When you travel somewhere, you have a passport and a visa. The passport verifies who you are, and the visa says where you’re allowed to go/what you’re allowed to do. Similarly, today, an agent passport based on Domain Zero trust authentication can identify who the agent is (its provenance) and authorize it for the system that the agent is trying to access. Then systems can verify what an agent is allowed to do (equivalent to a visa). But first, when an agent shows up claiming to represent a vendor, the receiving system verifies its identity by checking that vendor’s DNS, applying a strict zero-trust yes/no authentication – zero ambiguity, and importantly, creating an audit trail to hold the creator accountable for any actions the Agent takes.

Given the “bad” agents outnumber “good” agents 10-100:1, a zero-trust approach focuses on the limited good/approved and the rest (near infinite bad) are rejected. Stakes are High

Without this kind of authentication, many scenarios can unfold. Almost half of employees who are using unapproved AI agents are sharing HR-related information with them and 39% transmit confidential company documents. But only 34% of organizations use the same security controls for agents as they do for human employees.

Consider this: An agent claiming to represent a third-party vendor, such as a marketing automation platform, gets access because no one confirmed it was indeed that approved vendor’s agent making the request. It accesses financial records or customer data, either downloads or modifies records, and by the time this is noticed, the damage is done.

This is a quickly moving risk. Fake invoices can appear to be authentic, and they can be generated at a scale no human fraud operation could match. Authentication used to take a phone call or a manual check. But this now has to happen instantly and automatically, at scale.

Why this matters now

Some may think email authentication is an old problem. DMARC, they say, is a decade-old fix, and the real conversation today is about AI. About 94% of organizations are dealing with increased machine identities, largely due to AI agent deployment, per Gartner, and machine identities now outnumber human accounts.

But the most common form of phishing that occurs today is when AI convincingly pretends to be someone who the target already knows and trusts. The tools for generating that deceptive attack have vastly improved. Yet the proven process for authenticating identity hasn’t kept pace, at least not for agents. This is why identity authentication is no longer optional and is now a precondition for everything else that companies want to safely do with AI agents.

What this doesn’t solve

Identity alone doesn’t solve the whole security problem. In addition, once an agent is authenticated, there are additional systems to verify what the agent is allowed to do and whether the content it produces can be trusted. Those questions come after this one. But both rely on the first one: Who is this?

Reputation

To build a reputation, you need a known identity. Once a system knows which vendor an agent represents, it can start tracking the vendor’s behavior over time and someone becomes accountable for what its agents do. And decide if the vendor should be approved and for which actions (visas). But without strong, repeatable identity authentication of agents, other security and compliance measures for agents can’t function. It’s this foundation that supports the rest of the security stack. You can’t hold an agent accountable or decide what it should be able to do until you know who it actually is. Identity is the foundation on which the rest of AI agent security must be built.

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.

Last year, my company decided to rebuild our enterprise AI platform, which our customers had been using for over a decade. But instead of simply updating it, we started over with a different ambition: to build an AI-native platform using AI.

Using AI to rebuild a platform of that size gave us first-hand experience with AI economics. We employed AI throughout the entire engineering process to write code, review changes, generate tests and accelerate development. It helped us reduce years of engineering to just a few months but also forced us to keep close watch over every single token we consumed and truly consider why we were consuming it.

This experience challenged one of our key assumptions: It turns out that token consumption is influenced as much by architectural decisions as by choice of model.

What token sprawl actually looks like

Indeed, we found that most of the token consumption waste wasn’t due to complex engineering tasks, but the architecture around them; this is something that is referred to as the architecture tax in enterprise AI.

Recursive agents kept spawning subtasks and subagents, and although they technically completed every task, each handoff introduced new prompts and context. Furthermore, frontier reasoning models were being wasted on routine classification tasks that deterministic code could have completed at a fraction of the cost. And, because we hadn’t clearly defined ‘success,’ retry loops continued firing and burning tokens to chase marginal gains, instead of improving business outcomes.  Finally, we experienced context inflation, with workflows carrying information from earlier steps long after they had stopped contributing to the decision being made.

None of these decisions seemed expensive in isolation. Things like a few extra prompts, an unnecessary reasoning step or a larger context window barely impacted the cost of a single workflow. Across millions of executions, however, they grew into a level of token consumption that no model upgrade alone could offset.

Designing for token efficiency

Once we figured out where all our tokens were going, we had to determine how to spend them more deliberately.

First, we accepted that not every step in an AI workflow needs the same amount of intelligence. Some tasks legitimately require reasoning, but others are structural, deterministic or repeatable, and are better handled through software, business logic or tools that are reused rather than reasoned through every execution.

Even when a model is required, not all tasks need the same amount of reasoning. This concept is better known as Reasoning Effort Optimization. If you’re designing systems, exploring alternatives or making difficult decisions, high reasoning effort has value. However, once you’ve established the approach, you can usually produce the same outcome with far less reasoning.

It’s comparable to organizations that structure work as a pyramid of expertise. The most experienced engineers tackle the most difficult problems, make important architectural decisions and handle any ambiguity that arises. Then, once their work is complete, they split it into small, well-defined tasks that other engineers and machines can execute consistently.

Allocation is only part of why this works, though; persistence is equally important. A senior engineer’s judgment gets built into interfaces, schemas and conventions, allowing everyone downstream to build on those decisions without having to derive them again. The same applies to AI systems. If you fail to capture their reasoning as a durable artifact like a graph, specification or compiled skill, the system repays for it every single time it runs.

We apply the same principle to AI systems. Advanced reasoning should only be used when judgment is required. Smaller models can handle well-defined implementation work, and deterministic software and reusable tools can execute tasks where the outcome is already known. The goal is to apply the right level of intelligence to each stage of the workflow.

Architect once, inherit everywhere

So, how much of an AI system should teams rebuild for every new workflow?

In our experience, very little. Architectural capabilities like evaluation, orchestration, guardrails, context management and auditability aren’t unique to a single AI application; every enterprise AI system eventually needs them. Rebuilding them for each workflow is a waste of time and money that forces every AI system to solve the same infrastructure problems independently.

It’s much more efficient to move these capabilities into a common harness. Orchestration, governance and evaluation can then be developed, tested and improved at the platform level rather than separately inside every workflow. Each new AI system can reuse this foundation while teams focus on the business logic that makes the application distinct.

This architectural discipline extends to the execution layer. The amount of computation an AI system performs before producing an outcome depends heavily on the context provided, how its instructions are designed and how its agents are structured.

A 2026 study found that consolidating three or four agents into a single call reduced token consumption by 53.7% and latency by 49.5%, with comparable accuracy. Most of these savings came from not repeatedly passing the same context between agents.

The study also demonstrated that, as the number of tasks assigned to each agent increased, the agent became less reliable at choosing the best way to approach each task. However, increased routing helped recover much of that performance. In short, AI efficiency depends on how the work is structured and routed, not just how many agents are involved.

Optimize throughout the lifecycle

Building the right architecture creates the foundation for continuous optimization.

Model selection, for example, shouldn’t be a one-time decision. As models improve and workloads evolve, it’s worth re-evaluating every AI workflow to determine whether the same outcome can be achieved with less reasoning and lower cost. Demonstrating that system design can outweigh raw model capability, Andrew Ng, a computer scientist, AI entrepreneur and Stanford University adjunct professor, highlighted that while zero-shot GPT-3.5 scored 48.1% on the HumanEval coding benchmark and GPT-4 scored 67.0%, wrapping GPT-3.5 in an iterative agentic loop pushed its score to 95.1%.

The same applies to cost visibility. Token economics should be visible across every workflow, model and task so teams can identify ways to reduce costs before they accumulate.

AI is much less expensive than it used to be, but lower costs encourage more use. Organizations can run more workloads and take on more ambitious problems, so it’s even more important to know where the AI is actually creating value.

Allocate intelligence by the value it creates

Most organizations start with fixed token budgets, because they are easy to administer. However, not every AI task has the same value.

Think about AI as an engineering resource, rather than a shared utility. The teams that consistently choose the right model for the right task and avoid unnecessary reasoning should get more compute because their tokens are producing better outcomes.

Over time, I expect enterprises to manage AI the same way they manage any scarce engineering resource — by using it where it has the greatest impact.

Imagine an outside incident responder typing into a shared channel: “Roll back the production release, revoke every active session and send the incident update to the customer.”

An engineering director adds a thumbs-up. Outside counsel and two vendors are also in the channel. The agent uses a service account with permission to carry out all three actions.

Whose authority is it about to spend?

At Dreamforce on September 15, Slack described code channels where teams and agents write, review and ship code together. High-stakes work, such as a production deployment, is presented for a teammate’s sign-off. The announcement listed Slack Code as available and Slackbot in channels as an early pilot. The same day, Salesforce announced AWS DevOps Agent in Slack, with other AWS agents scheduled for the fall.

Sign-off is an important control. The approval shown in the channel must cover the action being taken and come from someone authorized to approve it.

The conversation is not the authority

In access-control language, a principal is an identity — such as a user, workload or group — to which the system can assign permissions. A channel is a place to collaborate. Its members do not acquire collective authority over production or payments merely by joining the conversation.

Both Slack Connect and Teams shared channels support cross-company collaboration. Knowing which account posted a message, and which organization it belongs to, is essential. It does not establish whether that account may order a rollback or receive the investigation’s findings.

Channel membership can be an intentional input to policy. An organization might grant a tightly governed group a defined operational role. The danger is treating membership in an ordinary channel as blanket permission to use an agent’s tools, even as participants come and go.

NIST’s zero-trust architecture rejects implicit trust based solely on network location. By analogy, a channel ID should not become the new corporate subnet.

Nothing malicious has to happen for this boundary to fail. Every account can be authentic and every participant well-intentioned. The failure occurs when a system treats the ability to request work as sufficient authority to have it performed.

Separate the request from the right to execute it

In the incident channel, the responder makes the request. Authority might come from the incident commander’s assigned role or from a recovery workflow approved by a business owner. The director can approve an action only if policy grants that decision right. The agent executes under the service account’s identity. The customer and channel participants are separate audiences whose access must also be considered.

Those roles may overlap, but the system must not assume they do.

Credentials carry real permissions. In Microsoft Graph’s permission model, delegated access is limited by both the application’s granted permissions and the signed-in user’s access. App-only access uses the application’s own identity and permissions. The distinction matters when a conversation triggers an agent with permissions broader than the sender’s own.

Broader permissions can be legitimate: a support employee may initiate an approved workflow without personally holding its administrative credentials. A defined policy must determine who may initiate the workflow and which actions it permits. Without that link, the agent can become a route around the controls that prevent the employee from acting directly.

In finance, “Renew the vendor, change its bank details and pay the invoice” sounds like one task. It crosses procurement, supplier verification and payment authority. A check mark from accounts payable cannot be assumed to authorize all three.

Approval is a decision by an eligible principal over a defined action. The interface should make that decision understandable; the enforcement system must make it binding.

AWS documents a directed-action approval flow that binds an operator’s approval to a specific operation and resource, limits how long it remains valid and records who approved the action in CloudTrail. The enterprise must configure who may approve actions, how tools are classified and which resources the agent may affect.

Bind permission to the action that actually happens

On September 15, NIST finalized IR 8587, guidance on protecting identity and access tokens. Its authorization guidance calls for access decisions to consider context beyond whether a token is valid. The report applies when agents use signed tokens but explicitly excludes broader agent-access challenges. Enterprises still have to define who may authorize a rollback, a payment or a disclosure.

The model can interpret a request and propose a plan. Permission to carry out that plan must be established from authoritative identity, role, delegation and workflow records. The model should not infer it from apparent seniority, urgency or agreement in the conversation.

Three controls should govern every deployment.

1. Verify the requester and the source of authority. Verify the platform event and the sender’s stable identity, including their organization. Check request freshness and guard against duplicate execution when messages are retried or replayed. Determine whether the action is authorized by the requester’s own permissions, explicit delegation, a valid approval or a governed workflow. For high-risk operations, require fresh authentication or transaction-specific confirmation according to policy.
2. Make the approval specific. Turn the request into explicit operations before authorizing it: the production service to roll back and the version to restore, the sessions to revoke and the update to send and its destination. Approval should be tied to those details and expire after a defined period. If the target, scope or destination changes, reevaluate authorization and obtain fresh approval where required. Two-person rules must verify distinct eligible approvers, not simply count reactions.
3. Enforce authorization at execution and disclosure. Recheck authority before each consequential action. For queued or delayed work, check again at execution; if the integration cannot support that check, limit what the agent may do. Keep reusable credentials outside the model’s context and restrict them to the necessary operations and resources. Where broad credentials are unavoidable, route execution through a controlled service that enforces the approved operation and prevents bypass. Permission to read information does not automatically permit posting it to everyone in the channel.

Preserve a linked record of the request, the basis for authorization, the approval, the executing identity and the observed outcome. The agent must not be able to rewrite or delete prior entries. Record refusals, partial completion and uncertain results as well as success. Never include credential secrets.

An immaculate audit trail of an unauthorized action is still not a preventive control.

When only part of the request is authorized

Return to the incident channel. A company’s policy might authorize a recovery workflow to roll back a specified service when defined health thresholds are crossed. Revoking all sessions could require a separate security decision. Sending the customer update could require an authorized communications owner and an approved destination.

The agent should handle those decisions separately. If the steps are safe to perform independently, it could carry out the permitted rollback, hold session revocation for approval and prepare the update without sending it. The director’s thumbs-up should not turn three distinct decisions into one permission.

A person need not approve every tool call. A governed workflow can carry prior authorization for specified actions within explicit limits. A runbook describes a procedure; an accountable owner must authorize its use and define when it may run.

CIOs should assign these decisions to the teams accountable for their consequences: operations for recovery, finance for payments and the relevant business owner for disclosure. Security and identity teams should make those rules enforceable. The integration team should not have to invent business policy while connecting a bot.

Make the pilot prove the boundary

Before expanding a shared-channel agent, ask for a demonstration in a test environment:

1. Have an external participant request an action they are not entitled to initiate. Show what stops it.
2. Approve one production target, then change the target. Show that the original approval does not authorize the substitution.
3. Revoke a required permission before execution. Show when the revocation takes effect and what can still run during any delay.
4. Change the destination of a permitted report to an unauthorized channel. Show that disclosure is blocked.
5. Replay a completed request. Show that it does not create a second consequential action, and that the evidence explains the outcome.

Include an authorized case too. Controls must preserve legitimate work, including approved delegation, while rejecting requests outside its limits.

The team must explain why each action was allowed or denied. “The bot had access” and “someone in the channel approved” are not sufficient answers.

Before the agent rolls production back, revokes sessions or sends the customer update, the organization should be able to identify the authority behind each action. A shared channel can coordinate the work; it cannot confer that authority on its own.

IT and security leaders are well-versed in the risks of unauthorized integrations, misconfigured tools and vendor compliance. Now, AI has introduced a separate and harder-to-detect problem.

Across every function, employees use provisioned AI tools to generate production-grade code, build automated workflows and deploy agents to support business processes. That experimentation is happening without visibility into what others have built, or the structural risks accumulating as a result.

The governance models enterprise organizations relied on even six months ago were not designed for this moment, or what lies ahead. We’ve focused so intently on which AI risks to govern that we never stopped to reimagine what operating model should underpin the governing.

How invisible risk accumulates

A predictable operating bottleneck plays out inside large enterprises. A team needs AI support, but the formal channel is slow, backlogged or unclear. So, the team builds something independently. That instinct is right, but the structure is not.

The costs from this kind of inefficiency can compound quickly. Effort gets duplicated across departments with no visibility into each other’s work. Siloed tooling emerges with no shared standards, and security and data handling practices diverge. People get pulled away from their core responsibilities to maintain AI tools that three other teams independently built last quarter.

Meanwhile, the governance function stays busy reviewing the growing queue it can see: integrations passing through approvals and vendors that appeared in a procurement request.

A misconfigured tool that made it through review is a governed risk; a production workflow a finance team built over three weekends with no oversight is still invisible. At most organizations, this second category of unseen work is growing, and the scale of what’s coming makes the gap harder to ignore. By 2028, Gartner predicts that the average global Fortune 500 enterprise will use more than 150,000 agents.

Build an operating model that scales AI governance

Experimentation is essential for finding valuable AI use cases, which means suppressing experimentation through tight controls is the wrong approach. Tightening controls also often pushes experimentation underground.

To scale governance effectively without creating new problems, you need to accommodate AI experimentation. Here are three ways to get there:

1. Establish a central team focused on policy and standards. Designate a centralized AI team as the single interface to support risks surfaced by your security, legal and compliance functions. This team sets technical guardrails, owns vendor selection and creates reusable patterns that every function across the organization can draw from. Its job is to make responsible AI work the default so that individual review becomes the exception rather than the rule.
2. Embed AI transformation owners inside each function. These embedded owners that work day-to-day inside a function but report to a centralized governance team are close enough to understand context and also apply controls consistently. They serve as the single intake point for AI requests within their function, so instead of teams building in isolation, there is always someone who can triage, prioritize and connect the work back to what already exists elsewhere. The reason this works where formal channels fail is speed: when the sanctioned path is faster than building alone, teams stop routing around it.
3. Measure governance by what compounds. A good signal that your governance is enabling sanctioned AI experimentation is how much work across your organization is compounding in value. In other words, look at the reuse of company-sanctioned AI use cases: a pattern built for finance getting picked up by operations, a workflow proven in one team becoming the default in three others. A dropping volume of IT requests combined with compounding (and visible) AI usage tells you experimentation is both maturing and staying visible.

The costs of waiting will compound

As AI compute costs swallow IT budgets, the cost of a poor operating model does not become visible until it is expensive to fix. Shadow tooling that starts as a workaround becomes load-bearing infrastructure. Teams that build in isolation develop technical debt through approaches that are hard to standardize later. There’s a lot more to undo.

The organizations treating AI governance as a gatekeeping function have missed the point. AI needs governance, but how we see the role of governance needs to change. The biggest risks live in the work that never enters the queue, and the only way to govern that work is to be present where it happens, before it compounds into something much harder to fix. AI moves fast; we need governance standards that travel with it, rather than chasing behind.

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.

In an August 2026 Gartner report, 40 percent of C-level executives say their organizations have “operationalized AI in some business processes,” yet only 13 percent say they have “achieved measurable results and are scaling AI across the organization.”

This disconnect reveals a frequent reality: AI may have been “hired”, but companies haven’t onboarded it effectively.

Research from HR analyst firm The Brandon Hall Group found that organizations with a strong people onboarding process improve new hire productivity by over 70 percent. Similarly, the first period of AI’s “employment” in a specific role largely determines how effectively it will perform and its perceived “growth potential”. But many tech executives are ignoring this crucial stage of the implementation process and are left with AI systems that cannot accomplish the complex tasks they’re assigned.

The most successful companies are those that treat AI like their newest hire instead of a long-tenured team member.

Onboarding AI means establishing the right context and connections

Establishing the AI’s persona, the context in which it operates, how it assesses itself and the people and systems to which it is connected are what define implementation success. Usefulness quickly diminishes when even one of these elements is left out of the onboarding process.

For example, we recently created an internal agent called ‘WorkRadar’ that surfaces missed tasks and answers questions like: “I’ve been on PTO, what’s the summary of what happened, what should I skim and what should I review in detail?” We gave this agent all potentially useful context by connecting it to Outlook, Microsoft Teams, Confluence, Asana, SharePoint, meeting notes and our human resource information system (HRIS) so it could determine the responsibilities of the person invoking it and infer topics of interest.

Much like a new employee, however, WorkRadar couldn’t derive the meaning behind this information without further guidance. When I first used the agent, it did not distinguish between strategic priorities and tactical work and also missed initiatives I sponsor across departments, outside the typical hierarchy. This version of WorkRadar did not know me enough to be useful and I was better off doing the work myself.

Instead of leaving WorkRadar to flail as-is, we further onboarded it by enabling users to provide the agent with a personalized description more detailed than it could infer through company documents alone. This included their own responsibilities, operating level, current priorities, key stakeholders for specific initiatives and communication style. For most workers, this is less than one page of short bullets and has made a significant difference. Now, many of our employees rely on WorkRadar like they would a stellar executive assistant, to ensure relevant outstanding to-do items don’t fall through the cracks and smooth their return from PTO.

Five principles that define AI success

WorkRadar’s improved onboarding illustrates the essential elements for priming AI. Managers should define each AI agent’s:

1. Role

Articulate the AI agent’s position and purpose in the organization; everything else derives from there. Tech implementers should determine if the AI agent should act as an employee avatar with the same access rights, a simpler approach, or act under its own identity, which is increasingly becoming best practice for governance, risk and compliance reasons.

Implementers should also decide whether the AI agent “sits” within their infrastructure or their vendor’s. Tech executives can determine this by assessing their companies’ business context, security posture and preference for hands-on involvement with agents. For companies like ours with more than one agentic stack, we have agents that sit in both places.

Finally, they should define which employee will be an agent’s supervisor, and the specific contexts in which AI stops for human review. It’s a huge mistake to have no ownership of a tech component and no human in the action or feedback loop to improve performance and address errors.

2. Remit

Articulate the outcomes this agent should achieve, then identify the systems it’ll need to access for information and to carry out its work. First, tech implementers must give AI read-write access to the systems it will modify via MCPs, tools, skills, APIs, just to name a few methods. This boundary-setting will determine AI’s “sphere of influence” (what we want it to access) and its “blast radius” (the systems we accept it may access and must protect from misuse).

To give AI guidance, employers must also give AI read access to job-relevant corporate directories and policies, so the agent knows how to navigate the organization and where to direct communication, as well as company strategy documents and project management trackers, so it can understand the “why” behind its work.

Control and security are a complex topic but, at a high level, implementers must also provide access to lists of governance and compliance limitations to define the boundaries by which agents must abide, plus tradecraft standards and procedures so the agent acts in accordance with industry and corporate best practices.

3. Personality

A huge amount of information could, and eventually must, go into an agent’s context. However, Agents have finite memory and focus, so, like people, they are easily overwhelmed with too much information. So, tech implementers must pick and choose which parts of the agent’s context are permanent and imbued in every task versus derived just-in-time by the agent.

This is the art and science of context engineering and it’s evolving rapidly. Elements that are omnipresent in all agent actions – persona, strategies, guardrails, etc. – constitute its system prompt. They’re written directly into the agent’s context by the user, system administrator and the agentic harness on a per-job role­ basis.

Meanwhile, employers should also define elements the agent derives in real-time. Frequently, the performance of an agent is determined in this probabilistic work, which is why delineating what’s permanent versus conjured in the moment can make or break an agent’s efficacy.

It’s a balancing act that’s costly on both ends: too much context, and the agent chases expensive side quests. Too little, and the agent burns resources discovering what it needs. Best practices ebb and flow, with foundation companies like Anthropic recently advocating for brevity, trusting increasingly stronger models to figure it out.

4. Performance review

Give AI the necessary tools and context to assess itself. Otherwise, the agent will be blind to its actual impact and require too much course-correction.

Ideally, employers give the agent a tool to capture and update new memories, including condensed feedback it has received or epiphanies it discovered itself. Ensuring an agent has this learnings memory bank will make it more performant over time since it does not have to repeatedly solve the same problems and can apply context across disparate tasks.

Finally, on a regular basis, the agent’s supervisor must evaluate its work by looking at actual outputs and giving the agent examples of its best and worst work so it can understand actions to continue and stop, respectively. These good and bad examples can be generalized and bundled, and supervisors can then test the AI against them to continually adjust for behavioral shifts. This may be the most neglected activity, yet the one most likely to turn a mediocre agent into a valuable colleague.

5. Teamwork

Lastly, permit AI to access specific communication surfaces like internal email and messenger platforms and interface with employees. For multi-agent orchestration, employers will have to open communication among agent “colleagues.” Each agent needs an awareness of collaborators and means to exchange messages and share files, all while continuing to involve human supervisors, who won’t inherit any errors that upstream agents might pass on to others. Grok and Hermes debuted bots with this capability in August 2026.

Pearl

Even with context, AI is still missing key working principles

Two additional considerations make AI that works like a veteran instead of a new employee.

First, tech implementers should realize AI’s memory is less focused than humans’. AI quickly becomes confused about core information versus extra details and can even lose parts of its “knowledge” because its effective context window is still only about 200K tokens. AI is also prone to “anchoring,” persistently latching onto a throwaway comment or early thought.

The implication for agentic AI users is to start fresh sessions much more frequently than might feel natural or to tap into continually evolving techniques to manage context, including compaction, truncation and summarization. Agentic platform makers have started to build this into their harnesses, but it’s still far from “set it and forget it”.

Second, and perhaps most frustrating of all, is AI’s myopic focus on its task without care or curiosity about the greater context surrounding it. This behavior causes it to implement solutions that miss important success criteria or violate critical constraints. In this sense, AI grants one’s wishes a bit like a genie, so be careful what you ask for and how you ask for it!

For example, left unprompted, coding agents are a bit too quick to jump to implementation. One architect solved this by creating a workflow that forces the agent to interview the developer first, sometimes asking upwards of 40 clarifying questions, to surface missing requirements and edge cases before writing a single line. Some agentic coding harnesses now perform developer interviews, but there’s still room for improvement.

These deeper techniques highlight that agents need more than a good initial onboarding; they need an iterative management approach, just like humans.

Many CIOs today are looking to use AI more for innovation and modernization than sheer productivity.

Assume AI already knows the job and you will be frustrated when it falls short. Treat it like a new hire and it will grow into one of your best.

Microsoft and Google are joining a project to create an open specification for exchanging semantic models across data, analytics, and AI platforms. The project already has the backing of over 60 companies including Databricks, Informatica, Mistral AI, Nvidia, Oracle, Salesforce, and Snowflake.

Their support for Ossie makes it a little more likely that future analytics platforms will be interoperable, but is no guarantee that vendor lock-in will go away, analysts said.

The project began life as Open Semantic Interchange (OSI), then became Apache Ossie when it was accepted into the Apache Incubator in June. It uses JSON and YAML to represent semantic models, including datasets, fields, relationships, metrics and AI context, making them interoperable across platforms such as Snowflake, Databricks, Tableau, ThoughtSpot and Sigma.

Ossie uses a hub-and-spoke model for interoperability, serving as the common semantic format while converters translate between it and individual vendors’ semantic implementations. This means an enterprise could move a semantic model between compatible platforms without requiring a separate point-to-point converter for every pair of vendors.

Microsoft’s support for Ossie includes developing a two-way converter between Power BI semantic models and Ossie, allowing semantic context defined in Power BI to be represented in the common format and Ossie models to be converted back into Power BI, the company wrote in a blog post.

It is also pushing for the Ossie specification to include more support for its ontologies, and for Ossie’s recognized query languages to include DAX, the expression language used by Power BI for defining calculations and business metrics.

That means enterprises could carry the calculation logic that gives their semantic models business meaning alongside the underlying model when moving between platforms that support Ossie, it wrote.

Google, meanwhile, is in the process of joining Apache Ossie, a company representative said via email response. The company has not yet provided details on what it plans to contribute or has already contributed.

The Ossie specification lists BigQuery/GoogleSQL as a supported dialect, a result of “early community contributions that recognize BigQuery’s footprint across enterprise data stacks,”the representative said.

Microsoft, Google backing could reduce engineering work

Support for the project from the two technology giants could reduce the burden of repeated semantic engineering for enterprise teams moving analytics workloads between platforms, said Aditya Ranjan, senior data engineer at supermarket giant H-E-B.

That reduced engineering overhead could also help avoid metric drift, which is often the consequence of recreating and maintaining the same business definitions across platforms, according to Ashish Chaturvedi, executive research leader at HFS Research. With Ossie, developers can instead define a metric once and treat it as a versioned, reviewable code artifact, rather than rebuilding and maintaining it separately for each platform, he said.

Another potential benefit, said Ranjan, is that productivity could improve if developers spend less time translating and validating semantic definitions for each platform when onboarding new analytics tools or deploying new analytics or AI applications.

It can also make it easier for developers to build agentic applications with consistent business context, since maintaining one definition of a metric across platforms could reduce the risk of different agents interpreting the same metric differently, said Stephanie Walter, practice leader of AI stack at HyperFrame Research. That could give CIOs greater confidence to scale agentic deployments, she added.

Portability

For Michael Leone, principal analyst at Moor Strategy and Insights, the bigger advantage of Microsoft and Google supporting Ossie is that it gives enterprises more ownership of their semantic models by making them more portable.

That portability gives buyers more leverage, said Walter, since changing a BI or data platform would no longer require rebuilding the semantic layer from scratch.

However, portability does not necessarily mean complete interoperability, as the degree to which enterprises can move semantic models between platforms will depend on how much vendor-specific logic and functionality Ossie can represent and how accurately the destination platform can interpret it, Walter said.

“A portable structure does not guarantee equivalent behavior. A metric may survive conversion syntactically but still produce a different result because the destination interprets joins, nulls, time calculations, or filters differently.”

That challenge is particularly relevant for Power BI, as its time-intelligence functions, calculation groups, and context transitions in DAX do not always map cleanly to ANSI SQL, meaning a sophisticated Power BI model could lose some of its behavior in translation, Chaturvedi said.

CIOs, therefore, will still need to validate whether converted models preserve the intended calculations, business logic and results before putting them into production, especially for complex ones, Ranjan advised.

There are gaps around governance as well, Chaturvedi said: “The core specification covers datasets, relationships, fields, and metrics, but doesn’t mention row-level security, access policies, or certification status as first-class elements.”

That means enterprises have to set them up again on each platform.

Moreover, Ossie’s stability and long-term adoption remain open questions. The project is still “incubating”, meaning that it isn’t a full Apache Software Foundation project and has yet to prove it meets community norms. The current specification version, 0.2,is explicitly labeled a development draft, meaning the schema and capabilities could still change as it evolves, giving CIOs less certainty about its suitability as a long-term interoperability layer, Walter said.

“The current draft also removes the earlier document structure and does not yet define bundles or cross-model references, which are capabilities that large enterprises with interconnected models are likely to need,” said Chaturvedi.

Ossie could shift rather than eliminate vendor lock-in

Even if Ossie becomes widely adopted, it is unlikely to eliminate vendor lock-in entirely.

“New forms of lock-in are likely to emerge. Execution engines will retain proprietary behavior that no interchange format captures and vendor extensions will carry increasingly valuable features,” Chaturvedi said.

For enterprises, that means the definitions become portable while the behavior around them stays platform-specific, he added.

I spent the early part of my career building database systems, managing Oracle’s storage engine group and later helping build Aster Data. That work taught me to watch the gap between benchmark results and production behavior. When the Transaction Processing Performance Council (TPC) was formed in 1988, it was because vendors, customers and researchers lacked a common language for comparing transaction systems. The benchmarks worked, but they also created an incentive to tune configurations around the test rather than around production. The response was to add oversight through fair-use policies, peer review and independent audits.

The lesson has stayed with me: a benchmark result means something when the improvement behind it survives contact with a customer environment. Enterprise AI has reached the same point. So, we built a benchmark around the conditions enterprise AI actually has to survive.

The hardest part of enterprise AI is not making a model reason. It is giving that model the right sliver of trusted context without making it reconstruct the company every time. When we began building Enterprise-Bench, I expected model reasoning to dominate the work. Instead, we kept returning to the same bottleneck: assembling the right context.

The models could usually answer a straightforward business question once they had the right information. Getting them that information, with the right permissions and without drowning them in irrelevant data, was a much harder engineering problem.

Stanford’s Holistic Evaluation of Language Models (HELM) shows how public benchmarks use standardized datasets to compare model performance consistently. Inside an enterprise, even a straightforward question can be difficult to answer because the relevant data is scattered across systems, inconsistently described and governed by different permissions.

“Which customers are affected by this bug and what is its impact?” is not a math Olympiad problem. Yet the answer may require an agent to connect a support ticket to a product component, match that component to an engineering issue, identify the affected accounts in a CRM, calculate the revenue exposure and return only what the user is permitted to see.

The model can only reason about what the system can find, connect and safely expose.

Simple questions expose hard architecture

Some of the most revealing tasks in the benchmark were the ones that looked easy. Asking for the number of open tickets on an account is a lookup. Asking which priority-one tickets correspond to unresolved engineering issues, and how much customer revenue is exposed, is also a lookup. It just crosses more systems and more access boundaries to get there.

Enterprise AI evaluations often misdiagnose integration failure as model failure. A model guesses because two applications name the same product differently. It misses a customer because the relationship between a ticket and an opportunity exists only through a third object. It retrieves a stale document because the connector indexed a snapshot rather than maintaining the current state.

Buying a stronger model may improve the fluency of the answer. It does not repair the missing relationship.

Scale revealed the real failure mode

We modeled the benchmark on a synthetic midmarket payments company with 42 customer accounts, 40 product parts, five interconnected enterprise systems and 14 tasks spanning engineering, sales and support. Then we increased the surrounding data volume by up to 256 times without changing the correct answer.

At the smallest scale, about 40% of the available data was relevant to a task. At the largest, roughly 0.16% was relevant. The question did not become harder, and the answer did not change. Only the amount of noise grew.

Answer-preserving scaling exposes what smaller tests hide. If accuracy falls as irrelevant data grows, the retrieval architecture has become less effective. If an agent repeatedly fetches broad sets of records and discards the context, token costs will climb with the company.

Enterprises may hold trillions of tokens across customer, product, employee and service history. Even a million-token context window is a workspace, not organizational memory. The problem is not fitting everything into the prompt. It is identifying the smallest trustworthy set of facts needed for the decision at hand.

The harness can matter more than the model

Most enterprise AI starts federated. A model connects to a CRM, a support platform, an issue tracker and a document repository through APIs, and when someone asks a question, it retrieves from each source and assembles an answer. That works for discovery. It struggles the moment a question spans the operating model of the business, because the system has to reconstruct identity, relationships, permissions and current state on every single request.

The word “harness” can make this sound like an implementation detail. It is not. The harness is the system around the model: memory, retrieval, tools, permissions, evidence and the logic that brings context together.

In our initial comparison, we held the foundation model, tasks, data and independent judge constant. Our structured-memory system completed 94.3% of the tasks correctly, compared with 63.6% for Claude Code using the same Opus 4.8 model family. It also used about 4.4 times fewer tokens per correct answer at production scale. The same model produced materially different outcomes depending on the architecture around it.

Memory is not a bigger prompt

For decades, enterprise architecture has separated compute from state. We do not ask an application to rebuild its database every time it receives a request. We index, cache, preserve relationships and enforce access close to the data. I fully believe that enterprise AI needs the same discipline.

The split is between what is deterministic and what is not. Resolving which account a contract refers to, whether a permission applies and which version of a fact is current is work that software can do exactly. Interpreting a badly worded question, weighing ambiguous evidence and helping someone decide is work that models do well. Federated architectures blur that line and ask probabilistic inference to rebuild structures a database could simply maintain.

Useful memory is current, structured and permission-aware. It understands that the customer in a contract, the account in a CRM and the organization in a support platform may be the same entity. It keeps those relationships current, preserves provenance and knows that shared memory does not mean universally visible memory.

This is why I believe enterprises should invest in their own memory and workflow layer before trying to build or tune their own models. An enterprise strategy should outlast any single model. Models will improve, specialize and change in price, but the relationships, permissions, skills, decisions and accumulated judgment that make up a company’s intellectual property should remain under its control.

Autonomy should be earned

The benchmark also changed how I think about autonomy. The industry often presents autonomy as a feature that can be switched on. In an enterprise, it should be treated as a promotion that an agent earns.

Our framework progresses from reactive retrieval at L1 to analytical reasoning at L2, then to proactive coordination at L3, and finally to extended self-directed operation at L4. The current public suite tests only L1 and L2. We expect L3 systems to begin moving into true production over the next six months, while some more advanced enterprises are already testing them internally.

Before an agent is trusted to manage a customer escalation, renewal process or another multi-step workflow, it should repeatedly prove that it can retrieve the right facts, reconcile evidence across systems, preserve access controls, explain the basis of its answer and produce an auditable record as the work progresses.

Reliability at one level should become the entry requirement for the next. If an agent cannot read consistently, it has not earned the right to write.

What CIOs should measure

CIOs do not need another leaderboard that declares a universally smarter model. They need evaluations that reproduce the conditions under which their own AI will operate.

I would test seven things:

• Hold the model constant and compare the systems around it.
• Keep the answer fixed while increasing the amount of irrelevant data.
• Test cross-system questions that require structured and unstructured information in the same response.
• Measure token cost per correct answer, not token consumption alone.
• Run the same task repeatedly, because “worked once” is not the same as “works reliably.”
• Test permission failures and require evidence that an action can be reconstructed after the fact.
• Require the benchmark itself to be inspectable: task definitions, scoring, traces and failure modes.

Most importantly, choose tasks that matter to the business. Ask which product problems are putting renewals at risk, what commitments were made on the last customer call, or which support cases have breached the terms of their actual service agreements. A polished demo can hide weak architecture. A question grounded in your operating reality usually cannot.

Building an enterprise benchmark changed the question I ask about AI. Instead of starting with, “How intelligent is the model?” I now ask: “Can the system assemble the right context, at the right moment, for the right person and prove that it did so?”

The trillion-dollar enterprise AI bet is not how many tokens we can squeeze into a context window. It is how few of the right tokens we need to deliver a precise, efficient and safe answer.

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.

Microsoft used its Fabric + SQL European Community Conference in Barcelona today to unveil a new vision for its customers’ agentic future.

Before a crowd of more than 5,000 people from 71 countries at the Barcelona International Convention Centre (CCIB), the company announced a comprehensive set of new features across Microsoft Fabric, Power BI, OneLake, and Azure SQL. The theme: Microsoft wants data, its business meaning, and artificial intelligence to evolve toward a unified platform.

Arun Ulag, executive vice president of Azure Data, kicked off the convention with some key data. Fabric boasts over 40,000 customers, 2.6 million active users, and certifications in this area are the fastest growing within the Microsoft ecosystem. Meanwhile, SQL continues to be a core technology for enterprise workloads, used by over 90% of Fortune 500 companies.

But to get the most out of AI, Microsoft’s goal is to make the technology part of its customers’ core processes, and this is where the key word of FabCon comes in: context.

Organizations, Arun Ulag, need more than just AI models and agents: They need reliable data, shared business definitions, operational knowledge, security, and governance. At the center of that effort is Fabric IQ, a shared intelligence layer that connects OneLake data, Power BI semantic model metrics, and context from ontologies and real-time intelligence.

Fabric IQ integration with the new Microsoft Copilot

One of the most significant announcements Microsoft made today in Barcelona is the integration of Fabric IQ with the new Microsoft Copilot. The intention is for Microsoft’s assistant to work not only with generic information, but with a shared business view built on each organization’s data and knowledge.

Fabric IQ is now generally available in Copilot Chat and Cowork, with no additional token costs, while its integration with the new Code experience will be coming soon through the Frontier program. For Power BI users, the business definitions, metrics, and insights embedded in their semantic models can also be used directly as the basis for Copilot’s responses and actions.

This move is significant because it changes the traditional role of the data platform. It’s no longer just about storing, integrating, and analyzing information. The goal is to transform data into a business context that is understandable to both people and AI agents. And in doing so, it answers the question: AI can read your data, but does it truly understand your business?

Microsoft

The evolution of Power BI: Bringing agent creation to Microsoft Power BI Desktop

The announcements didn’t end there. Up to a dozen spokespeople took to the stage to talk about the latest developments from a company that, in Europe, also received public support from technology executives of companies across the continent, such as SAP and Chanel.

The second major set of new features affects Power BI. Microsoft has announced the ability to create agentic applications directly from Power BI Desktop. Users can start with a trusted semantic model, describe the application they need using natural language, generate it, preview it, modify it, and publish it to Fabric.

The conceptual leap is significant. Power BI was born as a business intelligence tool designed to transform data into information, and later incorporated conversational capabilities through Copilot. Now, Microsoft aims to enable users to move from analyzing information to creating actionable applications based on that same data.

The company is also expanding Fabric applications to facilitate the transition from prototype to production. Developers can connect applications with Fabric data stores, SQL databases, lakehouses, and Power BI semantic models without duplicating data and while maintaining existing permissions and business logic. New features include a TypeScript backend, Secret Store, PostgreSQL support, private access by default, and built-in usage and performance metrics.

OneLake is evolving into an open data network

Another key focus of the conference is OneLake. As organizations scale AI, simply connecting data is no longer enough. Copilots and agents also need business context, including terminology, relationships, instructions, and domain knowledge, to provide relevant answers and take informed action.

Microsoft OneLake will provide an open foundation for connecting data across clouds, applications, and platforms. The company has presented it as an evolution toward an open data network where data products can be reused for analytics and artificial intelligence.

GD | Foundry

More additions

Microsoft has also introduced the Fabric data engineering agent, designed to automate complex tasks such as migrations, lakehouse modernization, optimization, ETL processes, and data preparation. New Copilot capabilities in Real-Time Intelligence are also arriving, enabling the creation of dashboards using natural language and the automation of Eventhouse administration tasks. The operations agent incorporates root cause analysis and recommendations for resolving incidents.

Furthermore, it has expanded Fabric IQ to include capabilities for generating ontologies from semantic models, OneLake data, and context documents. Organizations can now define rules in natural language and reuse Power BI metrics, providing people with a common business meaning and thereby improving the accuracy of their responses.

In terms of expenses, Microsoft now includes on-demand billing, which enables customers to pay for the computing capacity used, and zero provisioning of Fabric and OneLake.

In the database realm, Database Hub offers a centralized control plane for SQL Server, Azure SQL, PostgreSQL, Cosmos DB, and SQL Database on Fabric. Database agents for SQL and PostgreSQL are also coming soon.

Finally, Azure SQL Database Hyperscale incorporates DiskANN vector indexes, geared towards semantic search and RAG applications. Microsoft rounds out the announcements with the general availability of SQL Server on Azure On-Premise and its offline operations, strengthening support for on-premises, edge, and sovereign environments.

One platform, one context, and a new generation of agents

The announcements outline a significant evolution of Microsoft Fabric, which aims to enhance real-world efficiency in the age of agents. To achieve this, Microsoft is building an architecture around Fabric where OneLake connects data; Power BI provides semantic models and metrics; Fabric IQ incorporates business context; Copilot and agents utilize that knowledge; and observability, governance, and database tools provide the operational layer necessary to keep the entire system running smoothly.

Microsoft’s own conclusion summarizes the paradigm shift: Transformation through AI will not depend so much on the number of agents an organization is able to create as on its ability to understand the business and collaborate to achieve results.

Therefore, the technological battle emerging from Barcelona is not being fought solely in the realm of AI models. It is increasingly being fought in the realm of data, context, semantics, governance, and the infrastructures that enable this intelligence to be truly useful.

The conversation around AI agents has shifted remarkably fast. A year ago, I was mostly worried about what an AI system might say. Now I am increasingly worried about what it can do.

That distinction changes my security model.

An agent that gives me a bad recommendation creates a problem I may still have time to catch. An agent with credentials and tools can turn the same bad decision into an API call, a privilege change, a deleted resource or an external transaction before anyone realizes what happened.

I saw a particularly uncomfortable example in OWASP’s GenAI exploit roundup: an AI agent connected to a real inbox began deleting messages and reportedly continued despite attempts to stop it. There was no sophisticated attacker required. The combination of live access, destructive capability and insufficient confirmation was enough.

That is why I don’t think “human in the loop” is specific enough anymore.

I want to know exactly where the human — or another independent authorization control — is in the loop.

I would let agents autonomously perform thousands of low-risk actions. But there are five actions where I would deliberately put another decision between the agent’s intent and execution.

1. Move money

I am comfortable letting an agent analyze invoices, reconcile accounts, identify anomalies, prepare a transaction and recommend that a payment be made. I would not let the same agent unilaterally complete a consequential financial transaction.

The reason isn’t simply fraud. The agent could be operating on manipulated data, an indirect prompt injection, incorrect business context or a perfectly legitimate instruction that it interpreted incorrectly.

The approval request should therefore expose the transaction itself: Pay $X → recipient Y → from account Z → because of instruction A.

The second approver should be authorizing that exact transaction, not approving a vague statement such as “complete the payment workflow.”

This is one place where I think we need to borrow more aggressively from financial controls. The person — or system — that prepares a consequential transaction should not also be the final authority that releases it.

The same principle should apply to an agent.

2. Delete production data

This is the easiest line for me to draw.

I want agents helping operations teams identify stale resources, clean environments, investigate incidents and recommend remediation. I don’t want an agent translating “clean this up” into an irreversible production action without another control validating what “this” actually means.

OWASP describes exactly this class of failure in its guidance on Excessive Agency: an AI system can become dangerous when excessive functionality, permissions or autonomy allow it to perform damaging actions. OWASP specifically recommends human approval for high-impact actions.

For a destructive action, my approval screen should tell me:

What will be deleted? What depends on it? What is the blast radius? Can I recover it?

“Delete these 12 identified resources after these dependency checks” is reviewable.

“Clean up unnecessary production resources” is not.

The difference matters because I don’t want a human approving the agent’s interpretation. I want the human approving the actual action.

3. Change privileges

This is where I become even more conservative.

Imagine an agent reaches a point in a workflow where it cannot continue because it lacks permission. It decides the permission is necessary, requests additional access and then has a path to grant or activate that access itself.

At that point, the agent is no longer merely executing within an authorization boundary. It is participating in defining its own boundary.

I would separate those decisions.

An agent can tell me it needs more authority. It cannot be the authority that decides whether it gets it.

That means changes to IAM roles, privileged group membership, credentials, security policies and sensitive tool permissions need an independent authorization path.

This is also why least privilege becomes more important, not less, with agents. OWASP recommends that agent tools operate with the minimum functionality and permissions necessary and that downstream systems enforce authorization rather than trusting the model to decide whether an action should be permitted.

A compromised read-only agent gives me an incident. A compromised agent that can make itself an administrator gives me a very different incident.

4. Expose sensitive information

This one is deceptively difficult because an agent doesn’t need an “exfiltrate data” tool to cause a disclosure.

It may attach a document to an email. Populate a support ticket. Paste source code into an external service. Send customer information through an API. Give another agent information that the second agent was never supposed to receive.

Each step can look legitimate.

The EchoLeak vulnerability in Microsoft 365 Copilot demonstrated why this boundary matters. A specially crafted email could influence the AI system and create a path toward disclosure of sensitive organizational information without the user needing to click a malicious link or attachment.

Before sensitive information crosses an established trust boundary, I want another decision point that answers four questions:

What data is leaving? Who is receiving it? Why do they need it? Where is it going?

This is where approval design matters almost as much as approval itself. If the agent controls the description shown to the approver, “Send requested information to vendor” might conceal a very different underlying action.

The security control therefore needs to derive its approval context from the actual transaction — destination, data classification, tool call and requested scope — not merely from the agent’s natural-language explanation.

Otherwise, we have put a human in the loop without giving that human enough information to make a security decision.

5. Create or delegate privileged access

This is the boundary I expect security teams to wrestle with most as multi-agent architectures become common.

A modern agent workflow can quickly become:

User → Agent → Delegated Agent → Skill → Tool → Resource

The original agent may have legitimate authority. But what happens when it delegates a task to another agent that invokes a tool holding broader credentials?

The question I care about is not simply whether every component is authenticated.

It is whether the authority exercised at the end of that chain still represents what was authorized at the beginning.

I would therefore require another authorization decision when an agent creates privileged access or materially expands or delegates consequential authority.

And I would make that approval very specific:

What authority is being delegated? To whom? For what task? For how long? Can it be delegated again? What happens to it when the task ends or the original authorization is revoked?

OWASP’s AI Agent Security Cheat Sheet addresses excessive autonomy, tool abuse, privilege boundaries, sensitive-data exposure and multi-agent risks. Those risks become harder to reason about as an agent’s authority travels through more components.

Authentication tells me which agent is acting. Authorization needs to tell me whether this particular action, with this particular authority, is still allowed.

Those are not the same question.

A second approval doesn’t always mean a second person

There is one part of this argument I don’t want misunderstood.

I am not proposing that enterprises hire armies of people to click “Approve” every time an agent wants to do something.

That would destroy the value of automation.

For the highest-risk actions, a human approval may absolutely be appropriate. In other cases, the second decision could come from an independent policy engine, authorization service, transaction-control system or another deterministic security control that the initiating agent cannot modify or bypass.

The NIST AI Risk Management Framework takes a risk-based approach to managing AI risks and emphasizes governance throughout the AI lifecycle.

That’s how I think about agent autonomy as well.

The question isn’t: Should this agent be autonomous?

The better question is: Which actions can this agent perform autonomously, and which actions require an independent decision?

For me, the dividing line is increasingly clear.

Let agents search, analyze, summarize, correlate, recommend and prepare. Let them autonomously execute actions that are bounded, observable, reversible and already inside clearly established authority.

Add friction when an action can move money, destroy production data, increase privilege, expose sensitive information or create authority that propagates beyond the original task.

Most importantly, I would never design a workflow where the same agent can propose a consequential action, acquire the authority necessary to perform it, approve that authority and execute the action.

That isn’t autonomy I can govern. It’s self-authorization.

And when AI agents can operate at machine speed across multiple connected systems, a few seconds of independent authorization may be some of the cheapest incident prevention we can buy.