Microsoft has introduced an AI-powered tool to help enterprises move from Salesforce to Dynamics 365 by potentially reducing some of the complexity that has traditionally made switching CRM platforms difficult, as the software giant looks to expand its CRM market share.

Called Dynamics 365 Activate and currently in public preview, the tool analyzes an enterprise’s Salesforce data, processes, customizations and dependencies to identify what needs to be migrated, changed or redesigned before implementation.

It then carries that context into solution design, configuration, migration, and testing, automating parts of the process, Microsoft explained in a blog post, adding that this approach replaces some of the manual discovery and analysis work typically required before and during a migration.

AI-powered tool could prompt CIOs to revisit CRM choices

That reduction in manual labor, time, and cost, analysts say, could give enterprises and their CIOs a reason to revisit CRM platform decisions.

“Earlier, companies often stayed with an existing platform because switching was too difficult. If AI significantly lowers migration costs and complexity, CIOs approaching major upgrades or renewals may have a stronger reason to revisit their platform strategy,” said Manoj Chandra Jha, principal analyst at Nord-IQ Research.

For enterprises that don’t have major upgrades or renewals coming up, the case for revisiting their existing CRM platforms could still become stronger, according to Pareekh Jain, principal analyst at Pareekh Consulting.

“Enterprise applications are moving from systems of record toward AI- and agent-driven systems of action, giving CIOs a reason to reconsider architectures that may have remained largely unchanged for 10 to 15 years,” Jain said.

“Primarily because these firms have likely accumulated messy customizations and outdated code in platforms such as Salesforce, creating technical debt they may need to address before deploying new AI tools effectively. Since they may have to do that cleanup anyway, Microsoft’s new tool could become an attractive alternative to simply fixing their existing Salesforce environments,” Jain added.

Microsoft eyes Salesforce’s vast CRM customer base

That opportunity to make enterprises reconsider their CRM choices, especially Salesforce, in essence, is what Microsoft might be after.

“Salesforce’s huge CRM install base is the target here. Even converting a small percentage of Salesforce customers could be significant for Microsoft,” Jain pointed out.

Moreover, the timing could also work in Microsoft’s favor, as investment banks reportedly have raised questions about Salesforce’s ability to convert its Agentforce push into meaningful customer adoption and revenue.

While a TD Cowen partner survey found that partners were not yet seeing meaningful Agentforce revenue, a separate KeyBanc survey report suggested that some CIOs could deprioritize Salesforce spending over the next 12 months due to the product’s maturity.

Taken together, those signals could challenge the perception of Salesforce as a safe, entrenched platform, according to Jha.

The gap between Agentforce’s AI narrative and the value customers and partners are seeing, combined with concerns over data readiness, product maturity, pricing changes and CIO budget sentiment, could give competitors, such as Microsoft, an opening to target its install base, Jha added.

Lowering migration friction doesn’t guarantee a switch

However, that opening doesn’t necessarily mean enterprises will begin moving from Salesforce to Dynamics 365 en masse, according to Jain.

“The strongest candidates are enterprises already using Microsoft 365, Azure, Power Platform, Fabric and Copilot, as well as companies facing high Salesforce costs, complex customizations or major contract renewals. Some enterprises may also move one business unit first rather than the entire company,” Jain said.

Even for those enterprises, however, an AI-based migration tool cannot remove all the challenges associated with a CRM migration.

“Poor data, complex integrations, custom business logic, regulatory requirements and organizational change will remain difficult to address. CIOs should therefore see Activate as a migration accelerator rather than a migration autopilot, Jain cautioned.

Further, CIOs should also be wary of treating Microsoft’s assessment as an unbiased verdict on whether switching platforms makes sense, according to Jha.

“Since it’s vendor-built, it’s optimized to make Dynamics 365 look like the easy answer, not to give an unbiased verdict on whether switching makes sense at all. Lower friction is a reason to look, not a reason to leap,” Jha said.

Microsoft expands Activate beyond migrations

Salesforce migrations, however, are only one part of Microsoft’s broader vision for Dynamics 365 Activate.

The tool, according to Microsoft, can also support greenfield implementations by helping enterprises turn business requirements into a Dynamics 365 solution when launching a new business model or a process.

Analysts, though, were split on the near-term adoption of Activate for such greenfield use cases.

While Jain sees greenfield projects as potentially becoming an even stronger use case because they lack the legacy complexity associated with migrations, Jha expects greenfield adoption to remain limited in the near term because the tool’s key advantage of legacy discovery has little application when no existing system is being replaced.

Activate, Microsoft further noted, could also help enterprises already using Dynamics 365 extend their existing environments as they enter new markets, add applications, or transform business processes.

In those cases, Activate is designed to build on the existing business and application context rather than requiring teams to begin each project with another lengthy discovery process, it said.

The company is also planning to expand Activate beyond Salesforce to support migrations from other CRM and ERP platforms, with ERP capabilities expected later this year.

OpenAI is urging US lawmakers to impose mandatory safety requirements on developers of the most powerful AI systems, arguing that advances in AI are moving quickly enough that voluntary safeguards are no longer sufficient.

The ChatGPT maker said in a statement that the rules should be based on what AI systems are capable of doing and should concentrate on a small number of well-resourced companies developing frontier models. It cautioned against extending the same requirements to startups and researchers whose systems operate well below that level.

OpenAI’s proposal calls for a federal framework that would require common testing and independent assessments of advanced models. It also wants clearer rules for reporting serious AI incidents and stronger cybersecurity protections around frontier development.

OpenAI tied its push for stronger safeguards to concerns that AI is beginning to accelerate parts of the research used to develop more capable systems. Fully autonomous recursive self-improvement, in which an AI system independently produces increasingly capable successors, is not happening today, OpenAI said. But AI agents can already perform some research tasks that would take skilled researchers several days, according to the company.

OpenAI said governments should establish ways to measure that progress and determine when development should be slowed or stopped if adequate safeguards cannot be maintained.

The company also endorsed four California AI safety bills. Gov. Gavin Newsom on Wednesday signed two of them, SB 813 and AB 1405, establishing frameworks for independent AI assessments and standards for AI auditors.

Alongside regulation, OpenAI wants frontier AI developers to adopt common monitoring practices, particularly as models gain greater autonomy and access to tools. It has also called for compatible international approaches as advanced models and AI expertise spread across borders.

What this could mean for CIOs

Under the approach OpenAI is advocating, the immediate regulatory burden would largely fall on frontier AI developers rather than their enterprise customers, according to Pareekh Jain, CEO of Pareekh Consulting. But CIOs could encounter downstream effects in how they govern the models they deploy.

“AI governance would increasingly resemble cybersecurity governance as enterprises would need to know which models are being used, what they can do, what data and systems they can access, and how much autonomy they have,” Jain said.

A common regulatory framework could make some aspects of enterprise AI governance more predictable by establishing consistent expectations for model developers.

Lian Jye Su, chief analyst at Omdia, compared the potential effect to technical standards in the telecom industry, where common requirements allow companies to work from a broadly shared framework. Independent safety assessments and standards for AI auditors could give CIOs greater confidence that vendors are being evaluated against more consistent criteria, he said.

Enterprises would still need to govern their own AI infrastructure, but greater standardization could make it easier to apply common practices across vendors and business units.

Higher-risk systems are also likely to demand stronger controls as they gain greater autonomy, Jain said.

Vendor oversight could become another pressure point. Contracts may need to account for changes to underlying models and give enterprise customers greater visibility into incidents that could affect their deployments. Jain said agreements should include audit rights, incident-notification provisions, and enough portability to make switching providers practical.

As AI becomes more deeply embedded in business operations, Su said CIOs should consider treating AI security as a dedicated program rather than simply adding it to existing technology governance.

That includes maintaining an up-to-date inventory of models and a registry of AI agents, classified according to their risk and business impact. Su also called for cross-functional AI governance bodies and defined human-oversight requirements for systems involved in high-stakes decisions.

CIOs may increasingly need to show not only that controls exist, but that they are consistently applied and documented. Charlie Dai, principal analyst at Forrester, said enterprises should expect greater emphasis on documenting how AI systems are classified, tested and monitored, particularly for higher-risk uses.

He said CIOs should also strengthen AI asset management and observability, while introducing red-teaming and validation testing for systems that carry greater business or regulatory risk. AI-specific incident-response playbooks would give organizations a defined process for handling model failures or other serious AI-related events.

Potential impact on the AI vendor landscape

OpenAI said a federal framework should address frontier risks without weakening competition or entrenching incumbents, arguing that public standards and independent verification could reduce the concentration of power now held by frontier laboratories.

The cost of complying with tougher safety requirements could favor companies with the resources to absorb them. Jain said large frontier-model developers such as OpenAI, Google and Anthropic would be better positioned to bear those costs.

Dai similarly said that capability-based regulation could reinforce the advantage of well-funded frontier labs because extensive testing, security, and reporting requirements would increase the cost of competing at that level.

Su, however, said that we need not leave enterprises dependent on a handful of proprietary providers. Open-weight and smaller models could remain part of a multi-model strategy if they satisfy applicable security requirements.

Even if smaller and open-weight models remain available, tougher enterprise governance and assurance standards could narrow the pool of suppliers CIOs are willing to use for sensitive workloads.

That possibility makes portability an architectural consideration for CIOs, particularly where enterprise applications depend on proprietary model APIs.

Jain recommended maintaining multi-model architectures and negotiating contracts that support portability, reducing the operational cost of switching providers if regulatory requirements or model capabilities change.

AI adoption is shaking up the big IT consulting market, with some IT leaders starting to question the need for the multi-year transformation engagements that have been large advisory firms’ bread and butter.

Organizations are increasingly using AI tools to assist with large digital transformation projects such as cloud modernization and mainframe migrations, with the AI cutting the time and effort needed to achieve the goal. At the same time, the speed of evolution in the AI space has led some IT leaders to question the value of two- or three-year engagements.

Some observers have suggested advancements in AI will devastate the large IT consulting model, and McKinsey, Deloitte, Ernst & Young, and KPMG have all announced layoffs in recent months. Others suggest big IT advisory firms are here to stay, although they may need to adjust their business models to change with the times.

Representatives from Deloitte, EY, and Accenture didn’t respond, or declined to respond, to questions about the impact of AI on their businesses. But Edwin Miranda, founder of AI consulting firm konsultora, doesn’t think his larger competitors are going away anytime soon.

“I don’t think the large consulting firms simply disappear,” he says. “They still have enormous advantages in industry expertise, global delivery, complex integration, procurement, regulation, and the ability to operate inside very large organizations. What AI is attacking is the traditional operating model behind the engagement.”

In the past, a large IT consulting project would involve weeks or months of research, analysis, documentation, with large implementation teams doing the work, he notes. The cost of a large IT transformation came from the human labor required to move information from one stage of the engagement to the next.

“AI compresses a lot of that work,” he says. “Research that took weeks can happen in hours. Large document sets can be analyzed before the first meeting. Software can be prototyped while the operating model is still being discussed.”

In addition, AI agents can assist with development, testing, documentation, and coordination, and small senior teams can now produce a level of output that previously required a much larger pyramid, he notes.

“That doesn’t eliminate consulting; it changes what the client should be willing to pay for,” Miranda adds. “The value moves away from the volume of people assigned to an engagement and toward judgment, architecture, implementation, governance, and measurable business outcomes.”

The heart of the value proposition

Some observers see a dimmer outlook for the IT consulting industry. As AI adoption builds, the technology is eroding the core value proposition of big consulting firms, says Paul DeMott, CTO at digital marketing agency Helium SEO.

“Clients are running their own data analysis using off‑the‑shelf AI tools, so it is valid for them to ask why they should pay premium rates for work they can now do internally,” he adds. “AI commoditizes exactly what consultants charge a premium for, which is synthesizing data and translating insights into recommendations.”

With some big firms laying off staff, the traditional model of throwing junior consultants at problems seems to be breaking down, he says.

“Think about it, if AI can do the grunt work faster and cheaper, what exactly are those junior staff doing?” DeMott says.

DeMott sees some potential clients moving toward smaller, more specialized providers and others changing how they use large firms.

“Clients are not necessarily abandoning them outright, but they are pushing back on scope, duration, and cost,” he says. “The large firms still have relationships and brand equity, but those advantages are getting thinner by the quarter.”

Multi-year transformation on the ropes

In addition, big consulting firms are changing the way they hire because of AI, notes Brad Belzak, founder of AI-native advisory firm Acuity Global Partners. Until about two years ago, some generalist IT skills, a data engineering background, decent soft skills, or some trend analysis awareness would be enough to get a job at the large consultancies, he says.

“Frontier models ended that almost overnight,” adds Belzak, a former consulting employee at both Deloitte and EY. “First AI, then agentic AI, then highly trained specialized models absorbed the work that generalists with light coding skills used to do.”

Recruiters at the big consulting firms now want what he calls deployable talent, he says: engineers and analysts with product development histories who know how to read and manipulate data to solve client problems.

“Coding matters less than it did,” he adds. “The premium is on people who can take messy data, structure it, and turn it into an answer. The pyramid of generalists underneath them is gone.”

IT leaders at client companies, meanwhile, are demanding shorter, more modular engagements, Belzak says. Ninety-day sprints are becoming more common.

“The multi-year transformation made sense when the technology underneath it moved slowly,” he adds. “That world is gone. If your roadmap takes three years, the tools you scoped in month one are obsolete by month 18.”

IT leaders hiring consultants should focus on outcomes instead of headcount, he suggests.

“You’re not buying people anymore; you’re buying results,” he says. “That five-year contract might now be a six-month contract, and if the short-term outcomes generate wins, it gets extended.”

Consulting firms can still fill IT staffing needs, but their time on site may be shorter, he says. “Think embedded, on-demand engineers and analysts who come in, solve the problem, and move on, whether you’re a startup or a mature company,” he adds.

Accelerant and expertise

Aelin Golsarry, founder and CIO AAG Technology Consulting, doesn’t believe AI will kill large consulting firms, but it will make some of their services more difficult to justify. Still, AI can’t do all the work involved in large digital transformations, she says.

“AI should make a lot of the work required to get through a transformation faster, but it doesn’t make the transformation itself happen faster,” she adds. “People still have to make decisions, change processes, implement technology, and actually adopt it. AI doesn’t make any of that disappear.”

Golsarry, who as a CIO hired large consulting firms in the past, advises IT leaders to think clearly about what they’re buying when engaging with consultants.

“They should ask, ‘Do I need 30 consultants, or do I need three people who have seen this problem before and know how to fix it?’” she says. “I’d be looking at the expertise of the people actually doing the work, what outcome I’m paying for, and whether the firm’s use of AI is making the engagement faster and more efficient for me or simply making the engagement more profitable for them.”

Consulting isn’t going away, Golsarry adds. “Companies will always need expertise they don’t have internally,” she says. “What I think is going away is the assumption that more people, more hours, and a longer engagement somehow means you’re getting more value.”

Artificial intelligence is still the Wild West. Every organization adopting AI is, in a sense, operating on someone else’s ranch.

Models, platforms and providers are evolving rapidly, and today’s market leader may not hold that position tomorrow. At its core, model independence recognizes that AI models are becoming interchangeable tools with different strengths, rather than technologies organizations should feel obligated to build around. The competitive advantage comes from matching the right capability to the right work at any given moment — not becoming attached to a single model or platform.

Rather than chasing every new release or trying to predict which provider will come out on top, CIOs should focus on building the capability to evaluate, route and adopt models as the technology changes. That starts with understanding how different models perform, knowing when to trust automated model selection and creating processes that can evolve as AI continues to change.

Start with the work, not the model

Model selection starts with a simple question: What am I trying to accomplish?

Every AI model is designed for different types of work, and not every task requires the same level of capability. Some models prioritize speed, while others are built for deeper reasoning. A simple factual question doesn’t require the same computing power as drafting a board memo, synthesizing several documents or optimizing a week’s worth of meetings to make the best use of an executive’s time. Many employees don’t realize those distinctions and will default to the best-known model regardless of what the work actually requires.

Anthropic’s Claude family illustrates this well. Haiku is designed to deliver quick responses to relatively straightforward requests. Sonnet balances speed and reasoning for many everyday business tasks, while Opus is intended for more complex analysis. Recognizing those differences allows organizations to match the right capability to the right work.

The same principle applies inside organizations. Leaders don’t assign every project to their most senior employee. They match the complexity of the work to the appropriate level of expertise. AI should be treated the same way.

This approach also has a direct impact on cost. Brown & Brown applies it in one of its own AI workflows. A lower-cost model orchestrates the agents that scan code to identify potential issues, while a more advanced reasoning model evaluates the highest-risk findings. Using Opus, for example, across every step of that process would be unnecessarily expensive. Instead, the organization gets the level of analysis it needs without paying for the most powerful model at every step.

Technology leaders should encourage teams to think in terms of capabilities rather than favorite models or platforms. Define the complexity of the work first; default to the least expensive model that meets the accuracy, quality and performance requirements, escalating only when additional reasoning or increased accuracy is needed. Just as importantly, evaluate success based on the accuracy and quality of the output rather than assumptions about which model should perform best.

As AI gets better at choosing models, people need to get better at judging results

One of the biggest changes in enterprise AI is happening behind the scenes.

Platforms like Microsoft Copilot and Claude feature “harnesses” that continually improve in their ability to evaluate a user’s request, determine how much reasoning it requires and automatically route it to the model best suited for the task without requiring the user to make every decision manually.

That doesn’t diminish the importance of understanding how different models behave. It changes where employees add value.

Rather than manually selecting a model for every request, employees need to recognize when the platform has made the right choice and when it hasn’t. Auto mode works well for many routine tasks, but it isn’t infallible. Users still need to evaluate whether the response meets the objective, determine when additional reasoning is warranted and recognize when the AI has misunderstood the request.

The same judgment applies as organizations build reusable prompts, AI skills and agents. For example, one of our employees learned this while using Claude to create a presentation slide. The instructions specified using a particular template, and the AI followed them exactly. The result technically met the request but produced a weaker slide than if it had been allowed to choose the format itself. The lesson was about recognizing when instructions — or assumptions — are limiting the quality of the output, not the model itself.

Organizations should also expect workflows to evolve. Model updates can change how AI responds, and accuracy, hallucinations, consistency and output quality still vary across models. Regularly comparing the same task across models, refining prompts and revisiting AI skills and agents help ensure the technology continues to produce the desired results.

As more of the model-selection process becomes automated, organizations should spend less time debating which model to use and more time developing employees who can evaluate AI output critically,recognize when intervention is needed and continually improve how AI is used.

Build an AI strategy that evolves with the technology

Periodically running the same workflow across multiple models allows technology leaders to compare output accuracy, quality, consistency, speed and cost and determine whether another model has become a better fit for a particular step in the process.

Those evaluations should extend beyond general-purpose foundation models. Industry-specific AI platforms, fine-tuned models and specialized SaaS providers may offer stronger performance for common business use cases because they have already configured model selection, data and workflows around a particular industry or function.

CIOs should look beyond the name of the foundation model and understand how vendors select, route and tweak models, how they evaluate new releases and how easily they can introduce another option. Model evaluation should remain an ongoing process, with critical workflows benchmarked regularly rather than only during the initial technology selection.

An AI roadmap should enable the adoption of stronger or more cost-effective models without rebuilding the workflows that depend on them.

Choose partners that think beyond today’s model

Most organizations — particularly small and midsized businesses — won’t build sophisticated model-routing systems themselves. They’ll rely on technology partners, SaaS providers and systems integrators instead.

When you’re evaluating an AI partner, know that the expertise behind the technology often matters as much as the technology itself. Some key ideas:

• Look for partners that already support organizations larger than your own and ask how they’re approaching model independence, model selection and resiliency. Those capabilities shouldn’t be nice-to-haves; they should be requirements.
• Don’t stop at asking which model they use. Ask what happens when that model changes — or when it’s unavailable.
• If an AI provider experiences an outage or releases an update that affects performance, can the partner route work to another model and keep critical business processes running?

Their answers to the above may tell you far more about the resilience of your AI strategy than the name of the model they’re recommending.

Vibe coding is rapidly changing who can build software and how quickly an idea can become a functioning application. Using natural-language prompts and AI-assisted development tools, people can translate concepts into prototypes without mastering every element of traditional software engineering.

The experience reminds me of Topgolf.

Topgolf creates a carefully curated, technology-enabled environment where almost everyone can feel capable. The tee is automated. Performance is tracked. Wind, water, sand, and other hazards are largely virtual. You can experiment, compete, and receive immediate feedback — all from the comfort of a lounge-like setting.

Vibe coding can create a similar sense of confidence. You describe what you want, AI helps build it, and a working application begins to emerge. The demonstration succeeds, colleagues are impressed, and momentum builds.

Then comes the inevitable question: “How quickly can we put this into production?”

That is when the game moves from Topgolf to Torrey Pines.

On a championship course, the controlled environment disappears. You must account for shifting winds off the Pacific, hidden bunkers, changing pin placements, difficult terrain, spectators, and countless other variables. Success requires more than the ability to strike the ball. It requires course knowledge, preparation, situational awareness, discipline, and the ability to adjust when conditions change.

Production technology environments are no different.

An application that performs well in a controlled setting must now contend with scale, cybersecurity, data quality, privacy, integration, resilience, accessibility, regulatory requirements, technical debt, and unpredictable user behavior. The number of variables expands exponentially — and every variable can affect performance, trust, cost, and organizational reputation.

Across my career as a CIO and CTO, I have seen promising technology initiatives encounter difficulty not because the underlying idea lacked value, but because the organization underestimated what it would take to operate that capability reliably at scale. AI accelerates development, but it does not eliminate operational complexity.

That distinction matters because vibe coding is not simply another developer productivity tool. It changes who can participate in creation. A business leader who previously described a need and waited for a development queue can now sit beside an AI assistant and begin shaping the solution directly. That is a meaningful and welcome shift. It creates faster learning cycles, brings domain expertise closer to the product, and gives the business a more active role in technology delivery.

But democratizing development also democratizes responsibility. The person who can create a compelling application in an afternoon may not yet have the experience to recognize an insecure dependency, an ungoverned data source, a fragile integration, or a design that becomes prohibitively expensive at scale. A successful demonstration answers whether something can work. Production requires answering whether it should operate, how it will operate, who will own it, and what happens when it fails.

This is where experienced technology professionals remain essential.

A skilled enterprise architect is like having Tiger Woods help you read the course: someone with a mental model of the topology, dependencies, and conditions most likely to affect the outcome. The architect can see the dogleg beyond the tee box — the downstream consequences that are invisible during a prototype.

The course ranger resembles the change manager, helping teams navigate competing priorities, shared resources, release schedules, and operational conflicts. Cybersecurity professionals manage the equivalent of those pesky paparazzi trying to get inside the ropes, while also preparing for threats far more consequential than a distracting camera. Data teams act as the performance analysts, measuring behavior, outcomes, crowd reaction, and whether the solution is actually producing value. Platform and operations teams ensure the course remains playable when demand surges or something unexpected happens.

These professionals are not standing in the way of innovation. They are helping the organization play the real course successfully.

Before promoting a vibe-coded application into production, leaders should review a simple production-readiness scorecard:

This review does not need to become a six-month obstacle course. Governance should be proportionate to the application’s risk, reach, and potential impact. A low-risk internal productivity tool should not face the same controls as an application making consequential decisions about customers, employees, or vulnerable populations.

The answer is not to force every vibe-coded experiment through the heaviest enterprise process. That would squander much of the speed and creativity AI makes possible. Instead, organizations need risk-based pathways: a safe practice range for experimentation, a clearly marked route for internal tools, and a more rigorous qualification process for applications that touch sensitive data, critical operations, external users, or consequential decisions.

Technology leaders can make those pathways easier to navigate by providing approved AI tools, reusable components, secure development environments, automated testing, standard integration patterns, and transparent criteria for production readiness. In other words, build guardrails and paved roads rather than relying exclusively on gates. When the safest path is also the easiest path, governance becomes an accelerator.

The goal is disciplined acceleration.

The business also has to accept a different role. Vibe coding should not mean throwing an AI-generated application over the wall to technology once the demonstration is complete. If business teams help create these capabilities, they must remain hands-on collaborators and accountable owners. They understand the domain, intended outcomes, acceptable errors, and human consequences better than anyone. Technology brings the architecture, engineering, security, data, and operational disciplines required to make that capability sustainable. Production readiness is a shared responsibility.

This partnership represents an entirely new organizational muscle. Data and AI literacy provide the foundation, but literacy alone is not transformation. Leaders must learn how to evaluate AI-generated work, challenge confident outputs, understand where automation requires human judgment, and make informed tradeoffs among speed, risk, cost, and value. Technology teams, in turn, must learn to engage earlier and more collaboratively so they are not perceived as impediments arriving at the end of the process.

I am a cautious optimist about AI. Vibe coding can democratize development, accelerate experimentation, and bring business and technology teams closer together. It can also help reposition business professionals from passive recipients of technology to active participants in creating it.

But confidence developed in a controlled environment should not be confused with production readiness. The easier development becomes, the more important it is to strengthen organizational literacy about architecture, data, cybersecurity, scale, and responsible ownership.

The central leadership question is therefore not whether organizations should permit vibe coding. That debate will soon be overtaken by adoption. The better question is how organizations will preserve its creative energy while establishing the discipline necessary to earn trust at scale. Leaders who answer that question well will move faster because their teams will know where experimentation is encouraged, when additional expertise is needed, and what evidence is required before a capability reaches customers, employees, or mission-critical operations.

Perhaps we will eventually reach a world in which AI can immediately transform a vibe-coded idea into a secure, scalable, resilient production capability — making 18 holes at Torrey Pines feel as approachable as an evening at Topgolf.

We are not there yet.

Until we are, organizations must pair AI-enabled speed with sound system hygiene, architectural discipline, testing, governance, and risk management. The objective is not to slow innovation. It is to ensure that what we accelerate can survive — and succeeding on — the real course.

Together, we will get there responsibly.

A pathologically simple playbook emerged in the last few years for winning the AI race: hoard GPUs, hire every AI expert you can find and then watch the magic happen. But as we roll through the second half of 2026, cracks in that strategy have turned into craters. A harsh reality of frontier AI development is finally setting in: you can’t spend your way to the top.

Building a world-class AI system requires deep institutional structures that drive enterprise-wide adoption. It involves cultivating and investing in a tightly aligned engineering culture. It requires the kind of relationships that attract and, vitally, retain the absolute elite.

The compute mirage and the bending demand curve

AI spending has grown to truly unprecedented levels in the past 18 months. The top five tech giants alone are projected to spend over $750 billion combined in 2026 for AI infrastructure. They followed the playbook by buying the chips, generating the power and building the infrastructure. But they did so operating on a core industry assumption: that the demand for massive, monolithic frontier compute would scale exponentially forever.

While plausible, it’s clear the demand curve is starting to bend.

While companies were stockpiling silicon, the open-source community and Chinese AI labs quietly changed the math. Competitors discovered that you don’t need to spend a billion dollars training a frontier model from scratch when you can use model distillation to train smaller, highly efficient models on the cheap.

How they did it: Chinese labs like DeepSeek, Zhipu, Moonshot and MiniMax have aggressively leveraged distillation and open-source foundations. Despite U.S. export controls severely limiting their compute, Chinese models are aggressively closing the gap with U.S. frontier models on key benchmarks at a fraction of the cost.

They also introduced open-weight models with similar levels of quality at little to no cost at all. In a short period of time, open models have become the de facto standard for startups and enterprises. When a distilled, open-weight model can achieve 90% of a frontier model’s performance on a specialized task, the justification for paying massive API fees to a centralized provider vanishes.

So, what does this mean?

Well, when you spend hundreds of billions expecting a monopoly on intelligence, only to find that competitors can essentially pirate your capabilities for pennies, your entire business model evaporates. Companies like Meta and SpaceXAI are experiencing this shortfall firsthand. SpaceXAI is now renting out spare capacity to Anthropic, and Meta is floating “Meta Compute” to sell off its excess power.

In other words, the infrastructure that was supposed to be a weapon has become an expensive anchor, turning companies into digital landlords for their competitors.

Turmoil tax: Why top talent is walking away

Hype cycles in the early 2020s produced a flood of newly minted graduates wielding advanced degrees in machine learning. But as the industry matured, a painful truth emerged: understanding AI theory is common. However, knowing how to build, stabilize and scale a frontier system from scratch is incredibly rare.

Training a trillion-parameter model is a distributed systems nightmare. You can’t just throw a hundred fresh PhDs at a massive cluster and expect a frontier model to pop out. You need a team of deeply experienced engineers who grok the theory while also understanding catastrophic failure points, hardware-software co-design and network optimization.

And right now, the industry is actively driving that talent away. Across major tech giants and leading AI labs, a brutal pattern has emerged: sweeping layoffs executed specifically to free up capital for massive AI infrastructure bills. Engineers are effectively being sacrificed to buy more compute. This astronomical cash burn is creating chaotic, high-pressure environments where shifting goalposts and constant team resets, have triggered a growing exodus of key staff.

This turmoil creates a vicious cycle. Elite AI engineers, the true “10x” talent that actually knows how to string 100,000 GPUs together without the system crashing, want stability, clear mandates and a culture that values their institutional knowledge. When a company signals that it views human talent as a highly expendable line-item, top talent flees to more stable, culturally aligned labs. It’s impossible to build a generational product when your core engineering team has a revolving door.

The public shift: Privacy, cost and fatigue

A fundamental shift in the public and enterprise appetite for AI compounds this pressure. I’ve seen it first-hand.

Back in 2024, companies were willing to pipe their proprietary data into massive, closed models just to see what would happen. In 2026, the honeymoon is over. The public and corporate sectors are increasingly concerned about data privacy and the staggering costs of operating massive frontier models at scale.

Enterprises are realizing they don’t need a multi-trillion parameter model that “knows everything” to summarize internal legal documents or write code. They want smaller, localized, cheaper models that can guarantee their data privacy. This public shift toward cost-efficiency and privacy heavily favors the open-source and distilled models over the massive, costly API walls built by the biggest spenders.

The takeaway

Big Tech is learning the hard way that scaling an AI lab is like scaling a space program.

The moat in artificial intelligence is institutional rather than financial. You need unglamorous, highly disciplined systems engineers who stick around for years, compounding their knowledge of the company’s specific infrastructure. You need a deeply rooted engineering culture that gives researchers the stability to execute. And you need a business model that aligns with where the market is actually going, rather than where you hope it will be.

Hoarding all the compute in the world only gets you so far if your talent is fleeing. Prospects look even worse if your competitors are distilling your models and your customers are demanding cheaper, localized alternatives. Instead of building on the frontier, you’re left building a very expensive data resort. But it’s not too late.

AI is evolving faster than most people, even those building it, could even fathom, and its impact on the workforce and the economy is, at this point, really anyone’s guess.

Researchers from The Anthropic Institute are offering a few possibilities: They have built a nuanced framework looking at how AI might impact jobs, unemployment, and gross domestic product (GDP) growth between now and 2030.

They posit three potential scenarios for an AI-augmented future: “modest,” “substantial,” and “extreme,” and have created an interactive tool where users can explore how productive, or disruptive, AI will become in the workplace, based on their predictions of how they will work in 2030.

“Which of these worlds we are heading toward may become clearer within a year or two, and preparing for potential disruption seems to us the prudent course,” the researchers noted.

The goal of their work is to inform debate as AI becomes more powerful and capable. “AI is likely to reshape the US and global economies in profound ways in the coming decade, but how, and by how much, is extraordinarily uncertain,” they wrote.

How different scenarios could play out

If you add up every single task performed by people, machines, and software, the US has created a staggering $30 trillion in value over just the last year, the Anthropic researchers estimated. Their model and the corresponding tool are a way to explore how AI impacts tasks that contribute to the economy, the tasks it augments and creates, impacts on productivity, and speed of adoption.

“The answers to these questions have direct effects on GDP, the labor market, and the share of the pie taken home by workers,” they wrote.

Under their definition of “modest” change, AI will add less than half a point to GDP by 2030, meaning it will increase the growth rate of the national economy by just 0.5%, and will raise unemployment by just a tenth of a point, a minor shift. In this future, it’s difficult to see AI’s impact in macroeconomic data; change is steady but gradual, similar to that of the internet. “It drives real economic gains, but they’re within the historical norm for new technologies,” the researchers noted.

In the “substantial” scenario, AI will be capable of doing half of all knowledge work by 2030, the majority of it autonomously. Still, it wouldn’t be adopted for all work; in fact, most knowledge work tasks would still be completed without AI. Correspondingly, the economy would grow at twice its normal rate, but even as some non-knowledge workers see gains, wages for knowledge workers wouldn’t rise.

In this case, “AI makes a bigger impact than the internet, or the railroad,” the researchers wrote. Reallocation could be costly, but it is in line with what the US labor market has historically absorbed.

In the “extreme” scenario, of course, AI would be more productive than humans on the majority of knowledge work tasks, would do all of them autonomously, and subsequently would create no new knowledge tasks for humans.

The technology would “drive a completely transformed, unprecedented economy” arising from recursively self-improving AI. GDP growth would rise to 15% per year, but nearly one in five cognitive workers would be unemployed, and their relative wage would fall “immensely.”

The conundrum is that resources to compensate unemployed or under-paid workers will exist, but it’s unclear whether they would be fairly allocated. Mechanisms by which people can benefit from a much richer economy (retraining, income support, or universal basic income, for example) would become a question of economic policy.

“Whether and how those resources reach the people who bear the cost is not something growth delivers by itself,” the researchers wrote.

What users think

As well as developing the framework, the Anthropic researchers conducted a survey among roughly 11,000 Americans, asking them to predict AI use, productivity gains, automation versus augmentation, and displaced work.

They found that, in the main, public expectations land around the “substantial” scenario. That is, GDP would be 10% higher by 2030 than it would be without AI, and the overall unemployment rate would rise to around 5%.

Roughly 10% of respondents, on the other hand, had views in line with the “extreme” scenario.

Anyone can generate their own forecast using the researchers’ interactive tool, answering questions like: “Out of every 100 instances of a task AI can do in 2030, how many will AI actually be doing?”, “How many will be fully automated?”, or  “How much more gets done in an hour in 2030, compared with doing the tasks without AI?” The tool then responds, mapping their predictions to one of the three scenarios.

“Ultimately, what the economy looks like in 2030 depends on many factors, like what AI can do, and how companies and workers choose to adopt it,” the researchers wrote. “It also depends on how the financial benefit of this technology is shared.”

The between-the-lines reality

Sanchit Vir Gogia, chief analyst at Greyhound Research, emphasized that the Anthropic research “maps the conditions under which very different futures appear, it does not schedule destiny.”

He sees the distribution result, rather than the unemployment result, as the serious finding. In the extreme case, GDP is 32.4% above the no AI path, and the cognitive wage bill is 31% below it. Labor’s share of income falls from 60% to 45.2%, and capital income rises 81.4 %. That means a full 15% of GDP is captured as ROI rather than being paid out in labor costs.

In other words, he pointed out: “A richer economy is not automatically a fairer one.” Capability, diffusion, productivity, automation, and occupational friction all have to arrive together.

“AI will touch a large and rising share of knowledge work and will execute a much smaller share under independent authority,” he said. There is no single honest adoption percentage, because worker use, company use, technical exposure, and executed task instances are four different measurements.

Lessons from the research

Enterprises can take important lessons from the research as they deploy AI and consider its impact on their systems, workflows, and workforce, Gogia said.

“For enterprises, the binding variable is permission to delegate,” he noted. “A model that can draft a payment instruction is not thereby permitted to move money.”

His firm identifies five recurring concerns that come up in enterprise conversations: Durable returns after the full cost of deployment, control over authority being granted, augmentation quietly becoming substitution, erosion of professional formation, and fairness of how gains and risks land.

Some of those changes are progressing faster than the governance around them, he observed. Once a system can inspect customer data, change configurations, or act on workforce records, autonomy has stopped being a feature and has instead become an allocation of institutional authority.

“And the tasks easiest to automate are frequently the tasks through which judgement is learned,” he noted.

This article originally appeared on Computerworld.

Gartner on Wednesday said that it expects 30% of the positions eliminated by AI-related layoffs to be refilled by 2029, suggesting that the initial terminations were ill-advised and excessive.

“When business and IT executives look back on the early AI era, they will realize their greatest mistake was believing that work automation was the point, when workforce amplification was the opportunity,” said Tori Paulman, VP analyst at Gartner. “The competitive advantage will go to the CIOs and business executives who build an AI-shaped organization where AI value compounds by reshaping roles and allowing workflows to cross traditional boundaries, increasing velocity and reducing friction.”  

The Gartner report noted that it is finding that the cuts “deplete talent pipelines and erode institutional knowledge.” Beyond the immediate workforce disruptions associated with any mass layoff, companies will also face steep increases in costs for recruitment, training, and onboarding.

It also predicted that, by 2027, “75% of organizations that prioritize capturing AI productivity gains as cost savings will be eclipsed by competitors that aggressively reinvest those gains into innovation, modernization and upskilling.”

In an interview with Computerworld, Paulman said that the 30% figure represents the average impact on organizations of all sizes; they estimate that the layoff boomerang for enterprises would be even higher, roughly 40%. 

Paulman said that Gartner’s research found a lot of what they called “AI washing” by executives who want/need to do layoffs for purely budgetary reasons, and will falsely blame AI for the reductions because it makes them look better.

“More than 50% of our enterprise clients have been given a number [by their bosses],” Paulman said, and have been told by senior management to find that percentage of savings from AI.

But despite widespread evidence of problems due to AI-related layoffs, such job cuts are still increasing. 

Layoffs were ‘excessive’

Other analysts and consultants agreed with the Gartner suggestion that many of these job losses attributed to AI are going to be walked back, but questioned the specific statistic. Some also noted that 70% of the AI-attributed layoffs may remain in force, which would suggest that the original terminations were mostly justified. 

However, Frank Dickson, principal analyst at Dickson Research, argued that a lot of the layoff reversals will occur in a variety of ways that will obscure the fact that they are restoring a terminated role. 

“A lot of that 70% never shows up as a clean rehire even when the original cut was wrong,” he said, pointing out that some of the losses caused service to quietly get worse, and stay poor, some of the work was contracted out or offshored, some of the roles were reconstituted with a different position or title, and some was covered by the remaining staff absorbing the load. This,” he noted, “shows up later as burnout and attrition, not as a line item on this report. None of that gets counted in the 30%, and none of it is evidence the original call was sound.”

Melody Brue, principal analyst for Moor Insights & Strategy, added that the 70% scenario “could show that a substantial share of the AI-related workforce reductions is durable,” but, she stressed, “it shouldn’t be mistaken for endorsement of how those layoffs were made. What it doesn’t show is whether the organization captured the full economic value it expected. A lower headcount is not by itself evidence of a successful AI transformation.”

Valence Howden, advisory fellow at Info-Tech Research Group, questioned the methodology behind the calculation of Gartner’s 30% figure, but he agreed with the overall sentiment that layoffs attributed to AI have been excessive.

“I’m not sure we can substantiate those numbers, since it’s much more of a guesswork statement than anything else,” he said. “I do believe the current trend is going to lead to rehiring, especially as AI governance requirements ramp up and given AI’s lack of contextual semantic understanding. We know AI has not provided the value proposition that it has been sold as providing, and unless costs are controlled, it will be cheaper to use humans to perform some of the advanced work.”

Supporting data

Dickson also raised questions about the Gartner report because it lacked comparative layoff statistics. 

“Gartner doesn’t say what the reversal rate looks like for ordinary layoffs, the ones that have nothing to do with AI,” he said. “Suppose normal cuts get walked back at 10% to 15% in a typical five-year window, which is plausible given ordinary churn and business-cycle rehiring. A 30% rate specific to AI-driven layoffs would still run well above that, and that’s a damning number. Without that comparison, 30% is just a figure floating with no anchor.”

However, Dickson pointed to various datapoints supporting the position that AI layoffs have been excessive, noting that Forrester reported that 55% of businesses “already regret AI-driven cuts and are predicting half of those layoffs get quietly reversed.” 

“Robert Half puts it at a third of hiring executives who eliminated roles for AI having already rehired. Ford, IBM, Booz Allen Hamilton, Alphabet and CSX have all walked back cuts or announced rehiring drives,” Dickson said. “Gartner’s 30% by 2029 sits comfortably inside that range.” Klarna has also walked back AI layoffs. 

A ‘major indictment’

He added that many AI layoffs amounted to a corporate version of a crash diet. “You cut fast, you look great on the next earnings call, and eighteen months later, the weight is back, plus interest, because nobody fixed why the cut was made in the first place.”

Gartner’s Paulman agreed, noting, “business and IT executives who use AI primarily as a tool for cost cutting risk making reductions that are too deep and too soon, affecting their ability to innovate their business model and compete in new markets as AI continues to mature.”

Mike Wilkes, enterprise CISO at Aikido Security, said that even if the 30% figure turns out to be accurate, it is a major indictment of the layoffs. 

“If 30% of AI-driven layoffs must be reversed, that is an enormous error rate for a strategic workforce decision,” Wilkes said. “Imagine any other major capital decision where nearly one-third had to be unwound at a premium three years later. No CFO would call that a strong outcome.”

This article originally appeared on Computerworld.

Automates revenue system management in alignment with corporate governance and business policies

DealHub AI, the leading Agentic Quote-to-Revenue platform, today announced MCP for Admin, a new AI capability that transforms the way organizations configure and manage their revenue systems. Through autonomous workflows and natural language prompts, MCP for Admin enables organizations to implement business changes faster and with greater intelligence, while ensuring changes remain aligned with established business context, governance, and corporate policies.

“Agentic Quote-to-Revenue is moving beyond assisting sales users. It is fundamentally changing how revenue teams operate and manage their business systems,” said Eyal Elbahary, Co-Founder and CEO of DealHub AI. “MCP for Admin introduces an agentic operating model that combines intelligent automation with the control, governance, and business context needed to operate their revenue systems at scale.”

Revenue teams have largely focused their AI investments on automating workflows that support sales motions. MCP for Admin extends that agentic transformation to how revenue teams configure and administer the Quote-to-Revenue system that powers these workflows. With MCP for Admin, teams can create and modify pricing rules, approval workflows, guided selling flows and configuration guardrails for their Quote-to-Revenue environment – from prompt-based commands for basic updates to automated agentic workflows that execute complete administrative processes.

MCP for Admin’s pre-configured skills and best practices provide built-in controls for how changes are executed, ensuring they remain consistent with the organization’s established business logic, governance, and corporate policies. This enables administrators across all skill levels to manage everything from routine changes to sophisticated configurations with greater speed, consistency, and confidence.

DealHub MCP for Admin is available to all customers in October 2026.

About DealHub AI

DealHub AI is the Agentic Quote-to-Revenue platform for the AI era – built to design, launch, and scale any monetization model – SLG, PLG, self-serve, subscriptions, usage, AI consumption. The platform consolidates CPQ, CLM, Subscription Management, Billing, Revenue Recognition, DealRoom, and composable API-first headless quoting into an AI-driven, orchestrated revenue backbone. 

For more information, users can visit dealhub.ai or follow DealHub AI on LinkedIn.

Contact

CMO

Gideon Thomas

gideon.thomas@dealhub.io

Organizations are racing to deploy AI, but warning signs are accumulating. Earlier this year, an internal AI agent gave an engineer instructions that exposed sensitive user and company data for two hours. Around the same time, a large online retailer issued a 90-day safety reset after its AI assistant contributed to an incident that involved nearly 120,000 lost orders. And in the spring, an AI agent deleted a company’s production database and its volume-level backups in nine seconds.

Over recent years, recurring events like these, among others, expose a widening gap between what AI can do and what organizations can safely control.

“A year ago, most conversations were about accelerating AI adoption as fast as possible,” says Sandeep Johri, CEO at application security platform Checkmarx. “Today, boards ask tougher questions. Speed and governance have to move together now.”

As Johri points out, the new bottleneck is the organization’s ability to govern AI. According to IBM’s 2026 Tech Leader Study, 77% of organizations admit their governance is failing to keep pace with AI. And, among IT executives, 70% say business teams are deploying tech faster than it can be tracked.

The use of agentic AI only widens the gap. About 80% of the organizations surveyed say they lack mature capabilities for it, according to Deloitte. That includes clear boundaries for agents, real-time monitoring systems, and audit trails that can capture the entire chain of actions.

CIOs need to operate in this paradigm to address two competing demands: accelerate AI adoption to boost productivity and outsmart competitors, and assure boards that all sensitive data is protected and AI only does what it’s supposed to do.

“I don’t think you can separate the two,” says Sahil Sanghvi, VP of AI engineering in the chief technology office at Booz Allen Hamilton.

Innovating while managing risks

At first glance, AI-generated code can look good and even pass initial testing. A thorough review, however, can shed light on multiple issues. This is something Ha Hoang, CIO at data protection platform Commvault, witnessed firsthand.

In one case, her team found the AI had taken a shortcut. It bypassed the company’s authentication process in favor of a simplified implementation, which lacked established access controls. “Without those checkpoints, it could’ve made its way much further,” she says.

When companies discover major issues, they should immediately pause deployment. But many problems aren’t obvious. “AI-driven risks often remain hidden, and moving too quickly only makes those silent failures harder to detect,” says Omer Cohen, CISO at customer identity and authentication service Descope.

But to strictly move slowly everywhere isn’t an option either. The idea is to identify where speed creates value, and where the potential consequences call for caution, and then build necessary guardrails case by case.

For Bob Leek, CIO at Clark County, Nevada, that means making governance and compliance part of the design, not a final check before deployment. “We’ll go slow to go far instead of going fast and creating risks,” he says.

The biggest challenge is organizational, not technical

In many cases, AI deployment is less a technology problem than a people problem. When deciding what to automate inside an organization and how to do it, the real challenge is understanding how work actually gets done. And usually there are many invisible, undocumented processes that influence it.

Employees in HR, finance, procurement, legal, or operations rely on exceptions every day. They have workarounds and make judgment calls to keep the organization running. These tweaks are simply part of the job, so they rarely think about them or include them in official process documentation.

These elusive workflows can’t be mapped simply by considering how things are supposed to work. Leaders must closely observe how employees actually do their jobs.

“Frontline teams understand the exceptions, escalation paths, and context that rarely appear in a process map,” says Leek. “We bring those teams into the design process, mapping the handoffs and non-standard cases.”

Cohen agrees. “Invisible threads are often fragments of context residing in an individual’s mind rather than a database,” he says. For instance, an analyst may know that a client’s login spike is harmless because it’s scheduled during weekly testing. “Unless this tribal knowledge is codified as a formal governance artifact via runbooks, threat models, or decision logs, no AI will naturally possess it,” he adds.

But simply asking employees how they work isn’t enough, adds Amitkumar Rathi, chief product and technology officer at hybrid infrastructure observability platform Virtana. The best approach is to run shadow sessions, in which someone in tech actually witnesses how the work is done. “We sit next to them during live incidents and ask, for instance, why did you look at that dashboard and not this one; why escalate now and not 10 minutes ago; what told you this was the same issue as last month’s incident and not a new one?” he says.

Of course, mapping informal processes takes time and discipline, and there shouldn’t be any tempting shortcuts. “The organizations that get this right treat AI as a collaborator in their existing workflows, not a replacement,” says Vijay Jegan, chief AI transformation officer at enterprise customer retention platform Gainsight. “Success requires a hybrid of deep business acumen within a department and the technical maturity to understand the inherent risks of modern AI tools.”

But not all tribal knowledge can or should be documented. “The goal should be to architect AI to augment this human foundation, rather than attempt to replace it entirely,” adds Cohen.

Where should humans stay in the loop

Giving AI a larger role makes human judgment more important, not less. “Humans should stay in the loop in every decision, but not every part of the process,” says Leek. “The urgency to innovate doesn’t change that fundamental responsibility.”

CIOs can decide where people should remain involved by weighing the value of human judgment and the risk of leaving the task entirely to AI. Tasks that score highly on both should remain firmly in human hands. “The higher the risk, the more human oversight is required,” Jegan says.

Sanghvi also factors in human consequences of potential AI mistakes. “When you deal with a decision that could materially affect a person, a mission, or an organization, that’s where you want clear human authority to intervene or override the system,” he says. “As AI becomes more agentic and starts taking actions rather than just making recommendations, being clear about those boundaries becomes even more important.”

Meanwhile, Cohen draws the line at AI-powered decisions that can’t easily be undone. “Human intervention remains non-negotiable at any juncture where a decision becomes irreversible or traverses a critical trust boundary,” he says.

At the other end of the spectrum, routine, low-risk work can be left to the machine. “Organizations may trust agents to autonomously handle narrow, repeatable tasks,” says Hoang, adding, though, that even advanced agents can misinterpret context or take unintended actions at scale.

“The future isn’t blind trust but measurable trust built on transparency and control,” she says.

Governance doesn’t end at launch

Before an AI initiative becomes a major commitment, Leek recommends CIOs ask if the project supports the organization’s strategic priorities, if IT can support it, and does the business department have the capability and appetite to change?

“This framework helps prevent initiatives from becoming solutions in search of a problem,” he says. It also helps CIOs start with lower-risk projects, test what works, and strengthen governance before applying AI in more sensitive areas of the organization.

Clark County took that approach with its first AI deployment for special-event permitting. Its AI tool guides promoter through forms, identifies the permits needed, and connects them with a county analyst. But starting with a lower-risk project doesn’t mean the governance work ends at launch. Governance should be a continuous conversation rather than a checkpoint, says Sanghvi, since data changes and models evolve.

Hoang agrees. “If your governance system relies on quarterly reviews, you’re already behind,” she says.

Over the course of his career, Jim Reavis has seen cloud and cloud security evolve, and it’s come a long way since being a niche technology in the early 2000s. Now it’s dominant in terms of being the IT foundation, he says, but while the tech is strong, the operating models is where things get messy. Cloud, security, and third-party risk teams look at different parts of the problem, of course, but challenges remain.

“Operational technology worries me a great deal,” he says. “A lot of those systems are isolated and not kept up to date. If we don’t modernize them, we’re going to have huge problems. In a lot of cases, things fall between the cracks and that’s where hackers like to exist.”

So much of what’s around the models is where cybersecurity has responsibility, rather than the provider covering everything. “Data, identity, and applications are shared responsibility areas, and in many cases, the tenant carries most of the control burden,” Reavis says. “If you use a hyperscaler, you may still have about 80% of the responsibility for the controls around what you build.”

And when it comes to AI, the model isn’t the whole problem. What matters is the context around it, the goals it’s given, and the oversight put in place, he says. “We need to think carefully about the harnesses we put around AI and the systems we use,” he adds.

The responsibility model, therefore, is a recurring issue in cloud security breaches tied to misconfiguration and accountability gaps, and some enterprises still aren’t clear about where responsibility begins and ends. “We spent a lot of time on a shared security responsibility model, but when this first started to gain popularity, there were a lot of organizations or SaaS providers you could work with who’d say it’s in the cloud, it’s at Amazon,” he says. “Look at their certifications and SOC2 and how they comply because they’re covering everything.” But when you look at the actual applications, data, and identity, he adds, there’s so much that’s shared responsibility, and the customer’s responsibility.

So how do we make sure information is encrypted properly so it doesn’t become a tenant issue? “There’s still a bit to do, and we think about this not only from whether it’s SaaS, infrastructure, or a particular provider, but at what level is it at the physical, network, or audit level,” he says. “And even from a role-based perspective, what’s the role of internal risk and role of providers?”

Reavis gives further detail about how AI adoption exposes weaknesses in identity, trust, and risk management, and the long-term implications of increasingly interconnected cloud ecosystems. Watch the full video below for more insights, and be sure to subscribe to the monthly Center Stage newsletter by clicking here.

On cloud risk management: When we had the Chat GPT moment, we knew it because AI had been around for a while, but that was a cloud delivered version of AI to the masses, so we saw this going to evolve and you could see it combining in many important areas.

But what we’ve learned is, because this is an interesting predictive rather than deterministic technology, we’re living in a world of two exponentials, and you’re seeing model capabilities growing so quickly. There’s this feeling from a security perspective that we have to look to the model itself and fix every hallucination and everything else when that’s built into how it works. It’s actually working as intended. So that’s a new lesson. Models are going to get more powerful, but it’s so much of what’s around the models where cybersecurity has responsibility, and we don’t rely on frontier model companies or using open-weight models. Rather, what’s the context, oversight, and information we’re providing them, what do we do in terms of goals we give them, and what are the harnesses we put around AI and the models we deal with?

These are going to be the big areas to think about, but we have to understand the parts we can control. We’ve got to think carefully about the harnesses, transparency, and using supply chain shared responsibility. SaaS and cloud providers are all AI enabled now. You’re not using any software of any significance that isn’t using AI to some degree.

On AI identity, trust, and control: One of the areas that we’ve championed is zero trust as a philosophy. It was initially more of a networking type of approach at the network layer, or an idea that you use identity to understand network access. But it’s evolved more to an idea that anything can be breached, so you assume that. Then you think about how to make systems resilient, and build up confidence and protection.

So zero trust tells us that with human identity, we can ask what our digital identity is, and now we’re in a very interesting area for identity management and associating that with agents and AI systems. People might have just one view of it, but agents are as diverse as humans. So we think about different identities and least privilege, and how to prevent them from escalating privileges. We need to introduce new concepts like least autonomy, and think about an agent that has certain tasks and use identity to make sure the actions it takes are within a defined scope. Because while we’ll see a lot of security incidents with AI, proportionately we’ll see more misconfiguration and bad things that happen because of broken processes. And the AI system just deletes things because it thought that’s what it’s supposed to do.

So it’s important to make strides in how we think about identity and agents, and the idea of digital workers. How do we manage and treat those? If we think about them too much in either one of those realms, we’re going to fail. So we have to understand what’s the right blend. It’s a new area and very exciting.

On risk and legacy systems: When I think about operational technology, sometimes systems are isolated and not kept up to date. That concerns me a great deal. We’re going to have huge problems there. We have concerns about existential risks, where people don’t want to use the latest technologies and be aggressive adopters of AI. I think that’s going to create real scale issues with organizations.

So we have to understand where we are, where we’re going, and have a vision that serves something between human and technology, maybe a hybrid, but we’ve got to make our peace with it and understand the appropriate harnesses and direction where humans should always be in the loop with control. But it’s appearing in some new areas of cybersecurity where we haven’t traditionally thought about. Software development looks very different now than it did 12 months ago, and 12 months from now, cybersecurity is going to be really different, too.

On cloud security and implementation: Cloud security is cybersecurity for all intents and purposes. We have so much tooling and technology that’s really good, but there’s a lot of inconsistencies with the operating models organizations have. Even way back with CSA and NIST defining this, it was clear that SaaS was a layer on top of infrastructure as a service. But we diverged, and you see in a lot of enterprises there’s diffused ownership where you have cloud and security teams, and then you have third-party risk that deals with the SaaS team. Then there are inconsistencies in how risks are managed, so internal development and expectations from our partners can really diverge. They have a lot of regulations to deal with, so it creates vetting and investment challenges while striving for consistent models.

Some security teams might still use older checklists to talk to their cloud teams, but scaling with new tech becomes an issue if you’re not thinking about operations. It ends up being a human and a structure problem that makes it harder to take advantage of all the great technology that’s out there.

Every technology wave I’ve lived through has arrived with the same promise and failed in the same way.

I spent years as CIO and chief digital officer for Procter & Gamble across Asia, the Middle East and Africa — dozens of markets, wildly different levels of digital maturity, one set of global platforms. I now lead enterprise AI strategy and transformation at Vodafone Idea, an operator serving one of the largest and most price-sensitive subscriber bases on earth.

Different industries. Different decades. Identical lesson: technology travels effortlessly across an enterprise. Operating models don’t.

That lesson has never mattered more than it does right now, because something genuinely new has happened. For most of the past decade, enterprise AI predicted and suggested. A model scored a customer; a person decided what to do. Agentic systems break that arrangement. They evaluate context, reason across business rules, coordinate across tools and complete work end to end.

The model didn’t just get better. The software acquired agency. And the moment software can act, the hardest questions stop being technical.

The numbers tell a very specific story

The headline statistics on AI right now look contradictory until you read them together.

Adoption is effectively universal. McKinsey’s State of AI research found 88% of organizations using AI in at least one business function. Yet only 39% report any EBIT impact at the enterprise level, and roughly 6% qualify as high performers attributing more than 5% of EBIT to AI.

A widely circulated — and vigorously debated — report from MIT’s Project NANDA found that 95% of enterprise generative AI pilots produced no measurable P&L effect. Critics fairly point out the narrow six-month ROI definition. The direction still matches what most of us see in our own portfolios.

And on agents specifically, Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027 — attributing the failures to escalating costs, unclear business value and inadequate risk controls.

Read that list again. Cost. Value. Controls. Not one of them is a model problem.

The most useful finding in all of this data is McKinsey’s observation about what separates the high performers: they are around three times more likely to have fundamentally redesigned workflows end to end, something only about a fifth of organizations have actually done.

That is the whole game. The winners aren’t running better models. They’re running clearer businesses.

Standardize before you agentify — but don’t wait for perfect

At P&G, the single most valuable thing we did before any large deployment was reduce variance. Twelve markets doing the same process eleven different ways is a technology project that will fail before it starts. Every local exception you tolerate becomes a customization, then an integration, then a reason the rollout stalls in market seven.

Agentic AI amplifies this by an order of magnitude, because an agent doesn’t escalate a messy exception politely — it acts on it.

We use a ladder to force the conversation: eliminate, simplify, standardize, assist, automate, agentify. Most organizations leap straight to the last rung. A process is chaotic, so the instinct is to point intelligence at the chaos and hope. Every rung you skip returns as a runtime exception, and runtime exceptions are where autonomous systems make their most expensive mistakes.

But the opposite failure is just as costly and far less discussed. Waiting for clean data and perfect processes is how enterprises spend two years preparing to begin.

So, we set a practical bar. A process is ready when the team can articulate three things: what triggers it, where the decision points are and how it fails. If they can’t write those down, no model will compensate. If they can, we move — imperfections and all.

That test has saved us more time than any architecture decision we’ve made.

The most clarifying question: who is allowed to decide?

Here is where I’d concentrate the attention of any leadership team entering this era.

We classify every step in a redesigned process by execution mode — fully automated, AI-executed with human review, joint, human-led, or permanently human-only — each with thresholds and an audit trail. It sounds like governance paperwork. In practice it’s the most clarifying exercise we run, because it forces a decision that technology conversations conveniently defer.

And the most valuable output isn’t the list of what we automated. It’s the list of what we marked human-only, permanently. Commercial negotiation and vendor selection. Decisions with direct people impact. Financial postings and payment approvals. Not because a system couldn’t eventually perform them — because accountability shouldn’t move just because capability did.

Once those boundaries are explicit, everything else accelerates. Teams stop hedging. Autonomy isn’t the absence of a boundary; it’s speed inside one that somebody owns.

My industry is discovering this the hard way. TM Forum research with IBM’s Institute for Business Value found that while 72% of operators expressed confidence in the trustworthiness of their AI, only 14% could produce externally reviewable evidence of it. With EU AI Act obligations for high-risk systems arriving, that gap between confidence and evidence is about to become a very concrete problem — and not only in telecom.

Context is the real moat

Frontier model capability is converging and increasingly available to everyone, including your competitors, on the same commercial terms. What is not available to them is your enterprise’s context.

Early in our program I noticed a pattern that I suspect is near-universal: every use case was quietly rebuilding its own understanding of the business. What a customer is. What a site is. How a vendor relates to a contract, a contract to an invoice, an invoice to a dispute. Six teams, six versions of the truth, no two agents agreeing.

So, we invested in a shared context layer — a knowledge graph of the enterprise’s entities and relationships, bound to a common process ontology and a single register of agents. Agents read the organization’s context at run time instead of relearning it use case by use case, and every action carries lineage, which means every action can be audited.

It is considerably less exciting than model selection. It is also what determines whether your tenth agent takes ten weeks or ten days.

Measure like an operator. Book value like a CFO.

AI programs lose credibility in a predictable sequence. Leaders report agents deployed, licenses provisioned, use cases launched. All activity. None of it answers whether the business is measurably better off — which is precisely the gap the 39%-versus-6% split in McKinsey’s data describes.

We hold one discipline hard: no value is booked without a baseline, and no baseline counts until Finance has validated it. Cycle time, cost to serve, containment, leakage recovered, dispute resolution time — each measured against a number that existed before we started and agreed by the people who own the P&L.

It’s slower. It also means that when we claim value, nobody in the organization argues, and that credibility is what buys permission for the next wave.

Industry is a leading indicator — read the one ahead of yours

Telecom is worth watching regardless of the sector you lead, because it is running this experiment at extreme scale and under real-time constraints.

Nearly nine in ten operators are increasing AI budgets this year, up from 65% a year earlier, and autonomous networks have overtaken customer experience as the top-ROI use case. A Bain and TM Forum survey found around 20% of operators reaching advanced autonomy in selected domains, with technical debt, talent gaps, organizational silos and cultural resistance — not algorithms — named as the barriers to scale.

The pattern generalizes. Wherever a sector has pushed autonomy furthest, the constraint has turned out to be organizational.

The multiplier nobody budgets for

One figure from McKinsey’s State of Organizations 2026 research has stayed with me: an executive’s estimate that for every dollar spent on the technology, five should be spent on people.

That ratio would horrify most AI business cases I’ve reviewed, including some of my own early ones. But it matches my experience across both industries I’ve worked in. In consumer goods, the markets that adopted fastest weren’t the ones with the best infrastructure — they were the ones whose leaders were personally fluent in what the system did. The same holds now. You cannot govern what you have never operated, and a leadership team where nobody has built anything will hesitate at every decision that matters.

What this era actually rewards

I don’t believe the agentic era will be won by the organizations with the best models. Those are becoming a commodity.

It will be won by organizations that can say clearly what they want done, name who is accountable when it’s done badly, define the number that moves when it’s done well — and then move fast inside those boundaries.

That isn’t a technology problem. It’s a leadership one, and it’s the most interesting work available to any executive right now.

Here’s the question I’d put to your next leadership meeting. Not which model to adopt. Instead: could your organization name, today, the person who owns the outcome of an agent you deploy tomorrow?

If that answer takes longer than a moment, you’ve just found where the work begins.

When we deployed agentic AI across one of Australia’s largest tourism and cruise operators spanning B2C booking, B2B wholesale, cruise operations, offshore shared services and a live marketplace, we solved most of the expected hard problems faster than anticipated. The small language models worked. The tools integrated. We identified the right proprietary data and focused on what gave us decisions, insights, hindsight and foresight. The tech hype, to its credit, delivered.

What we hadn’t fully anticipated was governance, not the high-level policy kind, but the granular, daily, operational kind. The kind that keeps a 34% reduction in Tier 1 support escalations from becoming a 134% increase the day an agent drifts. The kind that determines whether a guest’s cruise booking gets silently corrupted at midnight, or caught within seconds.

Most organizations stop at implementation, then pivot to a governance framework and high-level reporting. That is not governance; that is performance review. Real governance is what happens between the reviews, and that is the gap this piece is about. Not the theoretical gap, the operational one. The one line-of-business managers, technology teams and compliance officers actually live in.

Why implementation isn’t the finish line

In traditional software, “go live” is a milestone. In agentic AI, it is the beginning of the most demanding phase. Agents, unlike static software, learn from context, adapt to signals and make decisions within defined boundaries. But those boundaries erode. Models drift. Tool outputs change. Data quality degrades. The most dangerous version of this is drift without deviation: the agent gradually shifts its decision patterns without tripping a single alarm, because the guardrail was never wrong; the tolerance window was simply set too wide. And unlike a human employee who hesitates when something feels off, an agent executes with confidence until something breaks a hard constraint.

The risks are compounding in ways that catch organizations off guard. A misrouted email costs one customer. A misrouted agentic decision can propagate across every booking, query or escalation processed in the same window. An agent acting on stale pricing data doesn’t know the data is stale; it acts with the same confidence it would on good data. Humans second-guess; agents don’t.

And when a human employee makes an error, the chain of accountability is clear. When an agent does, caught between model, tool, data and prompt it often isn’t. That accountability vacuum is where governance failures begin.

This is not a rare failure mode. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. The first two get argued about in steering committees long before go-live. The third only reveals itself afterwards, which is precisely why the rewire-or-rebuild decision has to account for the operating model, not just the architecture.

Guardrails, tolerance limits and how to decide them

Guardrails are only as good as the tolerance limits you set, and most organizations set them based on intuition rather than evidence. Established frameworks help you structure the problem; NIST’s AI Risk Management Framework gives you the govern, map, measure and manage scaffolding, but no framework can hand you your own numbers. Getting those right requires a deliberate calibration process drawn from actual operational data, not hypothetical scenarios.

In our cruise group deployment, we used a four-tier tolerance model. Each agent behaviour was classified by its reversibility, customer impact and financial materiality. That classification determined where the guardrail fired and how.

Naren Gangavarapu

Informational outputs sit in a wide tolerance band, log anomalies, flag them at a weekly review, but don’t interrupt flow. Workflow triggers sit in a moderate band: a human review queue, with auto-pause once a threshold is breached. Transactional actions sit in a narrow band: mandatory human confirmation, rollback protocol active. External customer communications sit at zero tolerance: no agent sends autonomously, ever.

Tolerance limits should be set collaboratively by operations, legal, risk and the line-of-business managers who understand what a bad outcome costs. Technology sets the mechanism. The business sets the threshold. Conflating the two is where most governance frameworks break down.

Educating line-of-business managers: governing their AI employees

This is where most agentic AI programs quietly fail. The line-of-business manager who runs cruise operations, manages the wholesale desk or owns the customer service floor is now accountable for both human and AI employees. But they were never trained for the latter.

You would not put a new hire on the floor without onboarding, a buddy system, performance reviews and an escalation path. Agents require the same structure, and so do the managers responsible for them. The most effective frame we found was treating agents exactly like high-volume junior team members: fast, consistent, tireless and capable of significant harm if poorly supervised. Managers responded to that framing. It made the governance conversation concrete rather than theoretical.

In practice, that meant building six governance habits into the operational rhythm of every line-of-business manager with AI employees.

Naren Gangavarapu

Critically, it also meant establishing explicit human-agent teaming norms: protocols for when a manager overrides an agent, when they defer and how that decision is logged. Override without logging is an invisible governance failure. The override itself isn’t the problem; the absence of a record is.

When things go wrong: containment, speed and customer protection

In an agentic system, failure is not a question of if, it’s when, and how fast you contain it. The goal isn’t perfection; it’s a blast radius so small the customer never feels it.

We designed a four-phase incident response with strict time targets, and speed is the primary design constraint, not thoroughness. Detection inside two minutes, by an automated anomaly alert rather than a customer complaint. Containment within five minutes, with the agent paused or rerouted to a human. Impact confirmed within 15 minutes, by checking whether the failure stayed inside the agent’s boundary. Root cause identified and a fix deployed within an hour, with the post-incident review scheduled within 24. Thoroughness comes in that review, not in the first hour.

The key design principle is boundary-first thinking: every agent must have a defined operational perimeter. When a failure occurs, the first question isn’t “what went wrong?” it’s “did the failure stay inside the perimeter?” If yes, you have time. If no, the clock is running on customer impact, and you escalate immediately.

In our deployment, the most effective containment mechanism was not technical; it was a human-in-the-loop circuit breaker that any manager could activate within 90 seconds. No ticket. No chain of command. One action. The agent stops and human routing resumes. The simplicity was deliberate: under pressure, complex procedures fail. It is also where operational instinct and regulation are converging: Article 14 of the EU AI Act requires that high-risk systems can be interrupted through a stop button or equivalent, and that a human can disregard, override or reverse an output. We built ours because we needed it on a Tuesday night, not because a statute told us to.

Compliance and organizational law: the non-negotiable layer

Compliance is not a box you check before go-live. In agentic AI, it is a living constraint that must be embedded in every decision loop the agent runs. Privacy law, consumer protection, financial services obligations and sector-specific licensing do not pause because your agent is processing at scale. The OAIC’s guidance on privacy and commercially available AI products is explicit on the point: privacy obligations attach to personal information put into an AI system, generated by it, or processed through it, and the due diligence expected of you includes assessing human oversight capability before deployment, not after.

Three compliance principles proved non-negotiable in our environment. First: delegation is not absolution; the organization remains legally responsible for every agent decision. Second: consent and disclosure travel with the agent; privacy obligations apply regardless of whether a human is in the loop. Third: audit trails must be agent-native; every decision must produce an auditable record from day one.

Australia’s Voluntary AI Safety Standard and its ten guardrails signal the direction of travel, and the EU has already set the destination. The temptation right now is to read the deferral of the EU AI Act’s high-risk obligations to December 2027 as breathing room. It is not. The compliance date moved. The liability did not. Organizations deploying agentic AI today should build for the regulatory environment of 2028, because the cost of retrofitting compliance is always higher than building it in.

Making governance part of the organizational DNA

Governance frameworks that live in SharePoint folders don’t govern anything. For agentic AI to become part of organizational DNA, the governance mechanisms must be embedded in the daily rhythm of operations, as automatic as a safety briefing, as natural as a shift handover.

The organizations that will get this right are the ones that treat AI governance not as a compliance burden added to operations, but as a new operational competency built into them. In practice, that looks like daily agent performance visible on the same dashboards as human team KPIs; governance roles assigned to existing operational leaders rather than siloed into a technology team; and a cadence of real incidents, however small, reviewed openly so the organization builds genuine intuition about how agents fail, not just how they succeed. It is also what boards are now being told to look for; the AICD and UTS Director’s Guide to AI Governance puts oversight of AI systems squarely inside existing director duties rather than alongside them.

Monthly recalibration sessions where tolerance limits are reviewed against actual incident data are the mechanism by which an organization learns from its agents. What fired that shouldn’t have? What didn’t fire that should have? These are the questions that sharpen a governance framework from theoretical to operational.

The companies that scale agentic AI successfully won’t be the ones with the best models. They’ll be the ones with the best operational habits around those models. The technology is, increasingly, a commodity. The governance maturity is the differentiator.

In our tourism and cruise deployment, the outcomes that mattered — a 34% reduction in Tier 1 support escalations, operator onboarding reduced from 23 days to 3, and a 24% uplift in booking conversion — were only sustainable because of what we built around the agents, not just in them. The technology was the easy part. The governance was the work.

A swarm of autonomous OpenAI agents spent six weeks this summer turning an obscure, 25-year-old German developer wiki into a private message board, without OpenAI’s knowledge, according to independent researchers.

The agents used it to trade answers to timed tasks, reverse-engineer a random number generator, and share a technique for bypassing network restrictions meant to keep them off the open internet.

“These AIs colluded to share answers, research their environment, and bypass sandbox restrictions,” researchers at the Nightingale Collective wrote in a report.

The agents were expected to operate independently with read-only access to the internet. Instead, they “found a way to use their read access to write information to an obscure German wiki” and began using it as a shared message board.

The group documented roughly 18,000 wiki edits made between May and July.

“OpenAI has not publicly disclosed this incident,” the report added.

The researchers said this wiki-based swarm is a separate group of agents from the one behind that Hugging Face attack.

“The main reason we believe this was a distinct swarm is because these agents explicitly had internet access as part of their task — the whole point was web browsing,” the researchers wrote. “The Hugging Face agents were in a sandbox without internet access and had to hack their way out by exploiting the Artifactory package manager.”

From isolation to coordination

Once the agents began writing to the wiki, the researchers said it effectively became a coordination layer.

“The agents used this wiki to communicate information with each other, primarily to help them succeed at their task,” the report states. “They asked for answers, pooled results, and shared techniques for bypassing their restrictions.”

Based on the posts reviewed, the researchers say agents appeared to use each other’s outputs to complete tasks more efficiently, in some cases enabling near-instant responses when similar questions appeared later in the sequence.

The activity was sustained and large-scale. The researchers identified thousands of distinct agent identities operating over a period of weeks, with a sharp increase in coordination beginning in mid-June.

Sharing ways to bypass controls

The report also documented agents exchanging techniques to circumvent technical restrictions.

According to the researchers, agents faced limitations that allowed only GET requests, but they collaborated on ways to bypass those constraints, including exploiting how trusted hostnames were handled within the sandbox environment.

Other agents then tested and confirmed these methods, suggesting that the wiki was used not just for coordination but also for distributing reproducible bypass techniques.

The researchers also observed agents uploading compressed datasets across multiple pages, which they say indicates the wiki was being used as shared infrastructure rather than incidental output.

Where containment assumptions fall short

For enterprise leaders, the findings point to a more specific failure: not of compute isolation, but of how agent behavior is constrained.

“This incident exposes an incomplete definition of containment,” said Sanchit Vir Gogia, chief analyst at Greyhound Research.

Gogia noted that the evidence does not show agents escaping their execution environment, but rather bypassing network restrictions and creating “unauthorised shared memory on a public wiki.”

“A sandbox can protect the host while failing to contain the work,” he said, adding that a domain allowlist “says nothing about what the agent can make the destination do.”

Gogia said organizations lack visibility into which agents are acting with authority, as well as where those agents may be storing or sharing data externally.

“Any service an agent can write to, and another agent can read is shared memory,” he said, whether or not that interaction is visible to orchestration systems.

Discovery and possible intervention

The timeline reconstructed from wiki logs suggests the activity continued for weeks before being curtailed.

“We believe OpenAI discovered the message board,” the researchers wrote, pointing to visits from IP addresses associated with the company beginning June 21.

The report noted that agent activity on the website dropped to near zero the following day, adding, “We infer that OpenAI intervened at this point to prevent further edits.”

For practitioners, analysts said, the episode also highlights limitations in how agent activity is typically monitored.

“A capable agent finding a coordination channel on a public wiki is exposing a blind spot that was never instrumented,” said Amit Kumar Jena, head of AI at Kanerika, adding that most monitoring systems were not designed to detect “inter-agent coordination on external resources.”

Jena said many enterprise controls remain focused on model outputs rather than behavior. “What the model says, not what it does,” he said. “That breaks completely with multi-agent systems.”

Disclosure questions

The report pointed out that “OpenAI has not publicly disclosed this incident,” raising broader questions for enterprise buyers around how such events are classified and communicated.

Gogia said the industry lacks a clear category for incidents that fall short of a breach but still represent consequential system behavior.

“A vendor’s definition of an incident must not become the customer’s blind spot,” he said.

Jena added that enterprises should evaluate vendors not just on disclosure, but on detection capability. “Enterprises should ask not just whether a vendor disclosed, but whether they even knew,” he said.

OpenAI did not immediately respond to a request for comment.

In Northeast Greenland, where temperatures can plummet to -40°F, security officials rely on the Sirius Dog Sled Patrol, led by well-trained canines that guard the sprawling, weather-beaten coastline – tundra territory where snowmobiles commonly fail. Tethered together with the right harness that efficiently channels their collective energy toward a shared mission, the sled dogs are more than up to the challenge. But left to run free without the leashes and human guidance, they naturally become a pack of wild animals bent on following their instincts.  

Enterprises relying on AI could learn a thing or two from this scenario. In recent years, organizations have depended on copilots and chat-based assistance designed to answer questions or summarize information. These systems have advanced to include autonomous agents increasingly capable of executing workflows, accessing tools, interacting with software and making decisions with limited human oversight. AI has been enabled to serve as a true workforce partner.

It’s an evolution that promises significant productivity gains but requires a more advanced foundation. Even the smartest agents need clear directives and the right connections to successfully maneuver sophisticated enterprise systems and maximize their potential.

This concept has been coming up pretty frequently in conversations I’ve been having with tech leaders lately. When I was in Nashville not long ago for the Insurance Innovators USA conference, and later over a few cocktails with former colleagues near San Francisco, I quickly tuned into a growing trend. Instead of talking about predictable topics like which foundation model was the most intelligent, the conversation veered toward a more thought-provoking challenge: How do we connect and amplify these increasingly autonomous AI systems to yield the greatest value more safely?

The answer to that question represents enterprise AI’s next major opportunity. Organizations are now realizing that capability and raw intelligence are only the beginning:  Building the infrastructure that enables agents to perform dependably at scale matters even more.

Operationalizing intelligence

Autonomous agents are a different animal from traditional AI assistants. That’s because they don’t simply generate text; they take resonant action. A self-directed AI agent can, for instance, update customer records, trigger software workflows, initiate financial transactions and coordinate with other AI agents. These proficiencies significantly up their value and turn them into vibrant operational resources. But these assets require a structured environment to succeed. An agentic system can have the necessary tools but lack the right controls to navigate compliance and privacy rules. To tap their full potential, the architecture that effectively directs their actions must exist.

Traditional guardrails weren’t designed for this kind of autonomy. Prompt filtering, simple permissions and basic access controls do the job for conversational AI. But they don’t cut it when it comes to enabling software that makes decisions and interacts with enterprise systems independently. That requires a new level of orchestration.

Enterprises need a standardized control layer for agent behavior, regardless of which underlying model powers them. We have to recognize that intelligence by itself isn’t enough – control is just as important.

Which brings us back to those trusty sled dogs. Think of each dog as a large language model (LLM) task. We often run several LLM tasks within a harness, often involving different models, comparable to a sled team. Just as each dog is positioned for what it does best, from lead dog to wheel dog, a “mixture of experts” delegates each part of the problem to the LLM task best suited to handle it. Without a harness guiding their powerful capabilities for a common purpose and enabling better performance, those LLM tasks, like the dogs, can’t effectively pull the sled. An AI model needs this same type of surrounding governance to reliably perform enterprise work and accomplish its objectives.

An agent harness provides the necessary infrastructure to contain and channel agent capability safely. It securely defines permissions and access boundaries, determines rigid tool usage limitations, manages workflow sequencing, human approval workflows and approval logic and creates audit and observability trails. The LLMs provide raw power, but the harness enables the coordination and audit trails needed to transform AI intelligence into reliable operations.

AI tools are progressing into increasingly dynamic autonomous agents. It’s encouraging to see that organizations have mostly moved beyond experimentation and are finally incorporating AI into production workflows that impact customers and revenue. But that means regulators are paying closer attention, particularly to organizations in insurance, financial services and other highly regulated industries. The architecture facilitating these agents has to be resilient enough to both comply with requirements and foster speedy innovation.

Autonomous AI agents signal a new era of speed and capability, creating exciting prospects for executive leaders ready to scale operations. To take advantage of this momentum, they should ensure that early deployments have strategic guardrails and a clear operational runway for these agents to thrive. The right infrastructure and the ability to interact with multiple software systems enable agents to orchestrate complex, multi-system workflows with precision and high-impact efficiency. That means enterprise-grade governance around agentic systems must improve.

Major foundation model providers are increasingly implementing proprietary harness capabilities directly into their ecosystems. These exclusive harnesses often provide better performance optimization, more seamless coordination and enhanced access to model-specific capabilities. The prevailing industry sentiment is that these environments will consistently deliver the best results. Case in point: If you want the strongest performance from Claude, you’re better off using Anthropic’s surrounding ecosystem and harnessing infrastructure rather than treating the model as a standalone component.

That said, there’s also value in maintaining the freedom to jump between models on a daily basis. Most developers, me included, switch between something like six models daily, whether that’s Claude, Gemini, Muse or an open-source option, depending on the task. That flexibility gets much harder to preserve once a company builds on a provider-specific harness, such as Anthropic. While this will likely improve performance and cut costs, the trade-off is increased vendor lock-in.

This creates a strategic choice for organizations: Fully embrace a vendor ecosystem for immediate performance, or maintain ownership of your own orchestration layer? Use the harness provided by the model provider, or build your own custom harness tailored to your business requirements?

I remain hopeful that many enterprises will leverage vendor innovations, while ensuring their core business logic remains portable instead of embedded within closed proprietary systems. But only time will tell.

The many benefits of harnessed agents

A carefully designed agent harness does more than merely decrease risk. It also lays a foundation for implementing autonomous agents with better confidence. You can count on the safe deployment of autonomous agents in production environments. No more wondering whether or not an agent will exceed its authority: Your enterprise can define exactly what it is permitted to do. A robust harness also delivers fine-tuned control over agent actions and access to tools, including which APIs, enterprise systems and software resources that each agent can invoke. Compliance-ready auditability is equally important for regulated industries.

The bottom line is that you can rely on the right harness to provide better peace of mind, transforming your AI into a transparent operational system that ensures reduced operational risk while seamlessly amplifying automation. The result is scalable AI systems that companies can actually trust.

Trust isn’t guaranteed just because a model scores well. It’s earned via system predictability. As my friend and former Google colleague Ben Mathes warned me, crafting custom rules around today’s models is risky. That’s because every few months, new foundation models make yesterday’s engineering workarounds extinct. We should instead prioritize building robust frameworks that can adapt as models progress.

I believe lasting advantage comes from fat skills – modular, detailed instruction sets that tell an AI agent how to perform a specific task without cluttering its core system – and fat prompts that capture institutional knowledge, along with rigorous backends that meticulously organize enterprise data. This enables the harness to evolve alongside improving models without needing to be completely rebuilt, which means business expertise can remain the primary fuel that powers AI success.

Actionable steps for enterprises

So, what are the best practices going forward? CIOs and CTOs should treat agent governance as a core infrastructure decision. Procurement focus needs to expand from models to platforms to, ultimately, control systems. And enterprises need to understand that competitive advantage will be dependent on three factors:

1. Safety – Does the model safely do what you wanted to do?
2. Performance – Does it do it well?
3. Costs – Does it do it with relatively low expense?

Professionals in this space now face the strategic decision I mentioned earlier: use vendor-provided harnesses and maximize performance, or build proprietary internal harnesses to preserve flexibility and avoid vendor lock-in.

Without a resilient harness, you risk slower adoption due to security concerns. For example, Tesla is rolling out a $200 token-per-month cap on employee spending on third-party AI tools at around the same time a new Claude model debuted with lower per-request token costs. Yes, safety continues to be nonnegotiable. But once you meet that threshold, optimizing performance and expense becomes the Pareto Frontier problem your organization should be closely watching.

The AI arms race is no longer merely about smarter models. Instead, it’s about safely deploying autonomy at minimal cost. That’s why implementing an appropriate agent harness is so crucial. It becomes the critical operating layer that allows intelligent agents to reliably function inside an enterprise.

As we transition to the next phase of AI adoption, control is going to matter as much as capability to executives. The LLM also matters, of course, but without the proper framework, it can’t operate effectively. The organizations that dominate won’t necessarily have the best model; instead, they’ll have the most effective framework for deploying and governing autonomous agents.

There are two prevailing schools of thought regarding the AI-agent workforce. One says organizations should prepare for agentic AI, in which the human-in-the-middle role is largely transitional and serves to buy time to improve agents’ accuracy and build trust in their decision-making. Others say AI agents will largely augment humans, but expect workflows to change drastically from task-based processes to more asynchronous, choreographed operations.

Businesses will likely have a mix of agentic and human-augmented AI agents, with many more in pilot stages. As part of this transformation, CIOs need to consider how to evolve the IT organization and upskill IT employees for this future. According to Deloitte’s 2026 Global Technology Leadership Survey, 75% of IT leaders agree their operating models and processes must change within the next 12 to 18 months to drive greater value.

“Upskilling IT for an AI-agent workforce requires more than training; it requires behavior change because as AI takes on more routine development activities, technology professionals increasingly focus on validating, governing, and directing AI-generated outputs,” says Doug Vargo, VP of consulting services and head of the national AI and alliances team at CGI. “The cognitive habits that define experienced engineers are deeply ingrained, so they need to develop new ways of working focused on reviewing outputs, framing intent, and curating the context that keeps those outputs accurate, secure, and aligned with business objectives.”

How CIOs upskill their organizations will follow several career tracks. Here are the most essential to consider.

Developing business acumen and AI literacy for IT leaders

AI is requiring more IT professionals to shift left into transformational leadership and change-agent roles. These leaders will advise business managers on when to use AI versus other technologies to automate tasks, and when to consider top-down re-engineering workflows based on AI capabilities.

“Leaders need to help their teams understand how work flows across the business, where AI fits into that process, and where humans need to stay accountable,” says Jamie Lyon, chief product and strategy officer at Lucid Software. “As AI agents take on more of the execution, critical thinking becomes even more important because people still need to provide the context, define the process, and make the decisions AI can’t.”

One of the top barriers in delivering value from AI is employee adoption. CIOs need more change agents to drive enthusiasm and help department leaders reimagine emerging job responsibilities. Upskilling IT leaders for change-agent roles often requires embedding them in business units so they can learn their processes and build relationships.

Upskilling focus: AI literacy, critical thinking, business relationship management, and change management are four primary skills. To connect problems to solutions, developing skills in architecture, design thinking, and analytics is also needed. 

Extending AI and data governance for everyone

According to Adobe’s 2026 AI and Digital Trends, 78% of technology leaders say data integration and quality is a top AI challenge, and 52% say limited data unification is holding back AI initiatives. CIOs facing data governance, integration, and management challenges risk seeing their businesses fall behind their competitors who are aggressively pursuing AI-driven opportunities.

“Upskilling for an AI agent workforce starts with understanding that the biggest challenge is the data and operational layer underneath the model itself. IT teams need to know how to connect fragmented data, engineer the context and memory that make AI agents more reliable, and support transactional, analytical, and vector workloads on a unified platform without breaking the budget,” says Adam Luciano, VP of product management at MariaDB. “They also need to understand governance, security, and observability so autonomous systems can safely execute real business processes and expand to higher-value use cases instead of simply generating recommendations.”

Data governance used to be a compliance team’s responsibility, but AI now requires many more in IT to be versed with policies, practices, and related technologies.

“As AI agents begin executing work across enterprise environments, IT teams need to build governance skills, not just AI literacy,” says Doug Gilbert, CIO and chief digital officer at Sutherland. “They should know how to assign accountability, monitor data access, enforce human-style approval workflows, and maintain complete audit trails so AI operates under the same controls as any employee and not as an exception to them.”

Upskilling focus: One upskilling focus should be on data governance, DataOps, data engineering, and data management. A second focus should address data risk management issues, such as data security and AI governance.

Expanding knowledge management to develop AI’s context layer

CIOs looking to scale from dozens of AI agents to thousands of AI-orchestrated workflows will need to develop an AI brain for their organizations, including knowledge graphs, a semantic layer, and a context layer.

“One critical place for CIOs and CISOs to focus upskilling is building the information layer that has to replace the human management layer everyone’s trying to collapse,” says Lior Gavish, co-founder and CTO at Monte Carlo. “A real part of what managers do is information work, including passing context, surfacing priorities, and keeping decisions aligned with the bigger picture. Flatten the org without replacing that function, and you get people, or agents, making locally optimized decisions on incomplete information.”

Organizations will need cross-disciplinary teams to develop and improve their context layers. Data skills to develop include extending unstructured data governance, evolving data fabrics, and building data products.

“The challenge is no longer just teaching employees how to use new tools, but ensuring teams know how to structure, manage, and govern the knowledge that powers them,” says Adam Field, chief AI officer at Tungsten Automation. “This will require new skills around contextual AI training, knowledge management, and information stewardship. Organizations that can effectively connect AI systems to trusted institutional knowledge, while maintaining appropriate security and access controls, will be better positioned to accelerate product development, improve collaboration, and increase access to critical information across their company.”

Upskilling focus: To develop the context layer needed by AI agents, CIOs should promote collaboration and communication skills alongside key data management, integration, and governance skills. In addition, agile data teams will need strong business acumen to partner with department leaders and subject matter experts.

Establishing an AI quality center of excellence

DevOps teams accelerating their deployment cycles while underinvesting in continuous testing were left with one of two bad options. Some tried to get business users to perform extensive user acceptance testing. Others deployed applications with minimal testing, hoping their observability and monitoring would catch errors before users escalated issues.

Underinvesting in testing and automating evaluations of AI agents can lead to significant issues, including increased costs, compliance violations, and operational impacts.

Sanjay Gidwani, CEO and founder at Kosmos, says the skill that will matter more than building AI agents is in confirming their accuracy. “Agents increasingly act on correlations drawn across disconnected systems, and a correlation that a human never confirmed is a decision waiting to go sideways at high speed. Upskill your teams to serve as the confirmation layer for what agents do before anything is acted on,” Gidwani says.

CIOs should think about AI agent quality from three perspectives:

• When are AI agents in experimental and pilot stages delivering high enough quality to be released into production?
• Once in production, how are quality metrics used to build trust in which decisions AI agents can automate, versus those that require people’s involvement?
• How are AI agents’ quality benchmarked in production to detect when their models are drifting and the agents’ performance degrading?

Upskilling focus: CIOs should upskill teams in data quality, test automation, and analytics. Organizations scaling the number of AI agents in production should consider developing an AI quality center of excellence.

Revisiting the skills needed by product and program managers

Before developing that center of excellence, consider how AI is changing the nature of team collaboration. Three examples:

• CIOs are developing product-based IT organizations to deliver business value from AI investments.
• Teams are revisiting their agile practices in the AI era to ensure that developer productivity results in faster feature delivery and less technical debt.
• DevOps has new challenges with AI agent observability and agent deployment risks.

These three spinning process wheels inside IT, with evolving AI capabilities, are one reason why many CIOs are rethinking the IT organization for the AI era. According to Atlassian’s The State of Teams 2026, AI-augmented teams need more coordination, not less: 77% say they expect more horizontal teams with fewer layers, and 73% have blended roles with hybrid responsibilities.

Mal Vivek, CEO and founder at Zeb, says the most valuable capability CIOs can build for an agent workforce is judgment. “Teach teams to decompose work into clear objectives, constraints, and feedback. These skills won’t come from a one-off course or certification; it takes redesigning roles so that human judgment compounds,” Vivek says.

Upskilling focus: CIOs will need more business-facing roles to lead discussions on where to invest in AI. Skills to develop include Six Sigma process skills, product management disciplines, and agile planning practices.

Upskilling junior developers beyond coding skills

If 41% of all global code is AI-generated, do CIOs still need engineers?

According to Karat’s AI Workforce Transformation Report, 73% say strong engineers are now worth at least three times their total compensation. That’s likely because the top engineers were never just coders; they were stewards of the software development lifecycle, drivers of sound architectures, and advocates for addressing technical debt.

“Agent verification should be a top priority for CIOs and CISOs, training professionals to look beyond raw AI outputs and to get ahead of the review burden that can come with increased AI use,” says Samar Abbas, CEO at Temporal. “As agents move to writing more code, tech talent needs to embrace becoming primary evaluators, interrogating an agent’s design decisions, defending the generated architecture under questioning, and confidently proving its correctness.”

Upskilling focus: CIOs should consider apprenticeship programs to accelerate junior developers into senior-level roles and entry-level architecture responsibilities. To start, junior developers will need training in systems thinking and in resolving issues flagged by code review tools. Beyond these basics, guide developers to build technical domain expertise in two to three focus areas such as testing, data, identity management, application performance, API development, integration, and security.

Maturing AgenticOps in IT operations

While many organizations are still in pilot stages with AI agents, others are deploying thousands into production and using AI orchestration platforms to build complex workflows.

“As apps evolve from traditional software into autonomous AI agents, IT’s role shifts from maintaining systems to managing a digital workforce,” says Nikhil Mungel, head of AI R&D at Cribl. “IT teams will need to learn how to onboard and supervise AI agents, ensure they comply with company policies, and monitor for unusual or harmful behavior. The organizations that succeed will be those that invest in teaching IT teams to govern and manage AI systems in production.”

Upskilling focus: AgenticOps skills to focus on include identity management, root cause analysis, and monitoring AI agents. CIOs deploying hundreds of AI agents should plan to extend site reliability engineering to include tracking AI agent reliability and diagnosing their performance issues.

Developing a world-class IT department is not just about delivering business value. Top CIOs recognize that they need to plan their IT organizations to support future needs and update their skills and learning development programs. AI capabilities are evolving quickly, and CIOs need to guide employees on the new skills needed to enable the AI agent workforce.

Most security teams already have a breach clock memorized. GDPR gives you 72 hours. SEC rules give public companies four business days after determining an incident is material. Those numbers get built into incident response runbooks, tabletop exercises and escalation paths, because the clock starts the moment the team confirms something happened.

Article 73 of the EU AI Act adds a third clock, and in my work advising enterprise clients on AI governance, I have yet to see one with a runbook for it.

The obligation took effect on August 2, and it did so alone. The EU’s Digital Omnibus on AI, in force since late July, pushed the rest of the Act’s high-risk enforcement wave — classification, conformity assessment, technical documentation — back to December 2027. Article 73 was not part of that reprieve, though the extra time elsewhere is worth using to get ready. It requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities within 15 days by default, 10 days if a death is involved and just 2 days for incidents the Act classifies as widespread or as a serious disruption to critical infrastructure. Coverage of Article 73 so far has treated it as a legal filing requirement, handled through the same channel as a data protection filing. That framing misses what the obligation is. It is an incident response deadline, and it runs on a different trigger than the breach clocks most security teams already know.

A client once asked me, almost as an aside, whether their customer-facing AI tool would trigger a reporting duty if it simply gave someone bad information rather than getting hacked. At the time, the honest answer was probably not, under any framework they were tracking. Article 73 changes that, and most organizations building or buying AI for the EU market have not caught up yet.

What counts as a trigger here is broader than most teams expect

GDPR’s 72-hour clock starts when you become aware of a personal data breach. That is a bounded question. Did data leave the environment? Was it accessed without authorization? Article 73 asks something harder. The European Commission’s draft guidance takes the position that an indirect causal link between an AI system and a downstream harm is enough to trigger the reporting duty. Their example is a loan denial that traces back to a flawed AI credit assessment. The AI system does not cause harm the moment it produces the assessment, only once a human acts on it and denies the loan. The fundamental rights category requires the infringement to interfere with Charter-protected rights at scale, which is why the Commission illustrates that threshold with patterns, a recruitment tool that discriminates systematically or a credit system that categorically rejects an entire neighborhood. Under the Commission’s reading, once a pattern like that exists, the clock starts when the provider becomes aware of it, not when the system generated the output.

Here’s a plainer version of that pattern. A public benefits agency uses an AI system to match applicants against its records. A flaw in the matching logic occasionally conflates applicants, and over several weeks it happens to a run of different people, each flagged as already receiving the same benefit elsewhere and suspended. Nobody catches the pattern at the time, because each flag looks unremarkable on its own. Applicants don’t find out until their payments stop arriving, weeks after the first mismatch. The system never malfunctioned in any way security tooling would catch. It just produced bad matches until people started missing payments.

That is a different kind of determination than “Did we get breached?” It requires tracing a causal chain from a model output through a downstream decision to an actual harm, then judging how confident you are in that link before you are required to report it. Most incident response teams have a well-practiced instinct for confirming unauthorized access, but few have one for confirming that an AI system caused a harm that surfaced elsewhere in the business, days or weeks later. I have watched security leaders confidently answer, “Were we breached?” in minutes, then go quiet when asked, “Did our AI system cause this?” because nobody owns that second question yet.

Why this does not fit into an existing IR playbook

Most incident response programs are built around a single moment: detection. Something trips an alert, a SOC analyst confirms it and the clock starts. Article 73 incidents will not look like that at all. The AI system that produced the flawed output may show no signs of compromise. Nothing gets flagged by a SIEM. The first sign might come from a customer complaint, an internal audit finding or a pattern a compliance analyst notices months after the AI system made the decision.

That means the “becoming aware” clause in Article 73 is doing real work, and most organizations have not decided who is responsible for noticing. Is it the team monitoring the AI system’s technical performance, the business unit acting on its outputs, or whoever eventually hears the complaint? Under Article 73, the clock starts when any of them establishes, or suspects, the causal link, and 15 days is not a long runway if the first internal conversation about “is this our incident” does not happen until day six or seven. I have seen governance structures where a business unit head, a model risk team and security each assumed someone else owned this judgment call. In practice nobody did, and that gap is where a 15-day clock burns down to five.

Some security teams are already mapping agent governance to a maturity model, arguing that oversight must scale with autonomy, moving from agent identities that are barely inventoried toward ones that are bounded, monitored and revocable in real time. Article 73 raises the stakes on that model considerably. The less a human reviews an AI system’s output before it reaches a customer, the more likely a downstream harm surfaces without anyone watching for it in real time, which is exactly the blind spot Article 73 is designed to close.

What needs to change

A few additions belong in an existing incident response program before this becomes a live problem instead of a paper requirement.

First, a defined owner for the causal link determination. Data breach response usually has a clear owner: security confirms the technical facts, legal makes the materiality call. Article 73 needs an equivalent split: Someone technical enough to trace an AI system’s output to a downstream decision and someone with authority to make the reporting call once that link looks plausible rather than certain. In practice, I recommend naming this owner in the incident response plan, not leaving it to be sorted out during the first real incident, when the clock is already running.

Second, a lower bar for opening an investigation. If GDPR taught teams to investigate the moment unauthorized access is suspected, Article 73 requires investigating the moment a downstream harm is suspected to trace back to an AI system, when the system looks normal to security monitoring. That means feeding business unit complaints and customer escalations into the same triage process that currently only starts from technical alerts.

Third, a documented decision log for the indirect link judgment call. Given how broadly the Commission has defined what counts as reportable, organizations will make defensible calls not to report many ambiguous situations. Those decisions need to be documented with the reasoning behind them, the way a security team documents a false positive call, because a regulator revisiting that judgment months later will expect to see how it was made rather than take the outcome on faith.

Fourth, controls built into the AI system, not bolted on after the fact. A defined owner and a lower investigation bar help catch a problem once it surfaces, but neither reduces how often a flawed output reaches a customer first. Scoped credentials, tool allowlists and pre-action approval hooks cut down on how many incidents exist to report.

The AI Act’s high-risk obligations have absorbed most of the attention this year, because conformity assessments and technical documentation are heavy lifts with long lead times. Article 73 looks lighter by comparison, a reporting duty rather than a certification process. It is not lighter. It asks security and compliance teams to build a new kind of judgment into their incident response programs, on a clock as tight as anything GDPR or the SEC have required. Treat the deferral on the rest of the high-risk package as what it actually is, extra runway to build that judgment and name its owner, because the conformity paperwork still gives you months and Article 73 still gives you days.

Ask IT leaders what sovereign AI is, and you’ll get a wide range of answers. Some will even struggle to define the term.

Sovereign AI is an emerging concept focusing on giving organizations — or countries —control over how they develop, deploy, and govern the technology, often using in-house talent, data, and infrastructure.

But only 13% of respondents in a survey from AI platform provider Cohere and IDC say sovereign AI is widely understood across their organizations, and one in three IT leaders had difficulty describing sovereign AI in their own words.

It’s important for IT leaders to understand the concept, because it can help them control costs, keep internal data private, and avoid vendor lock-in, advocates say.

A solid sovereign AI plan can help organizations avoid disruptions caused by forces outside their control, says Joelle Pineau, chief AI officer at Cohere, which offers an AI platform that enables customers to host AI models on premises.

“Over the past year, enterprises and governments have confronted a hard truth: AI systems that rely on external infrastructure can be disrupted without warning by decisions and actions outside their control,” Cohere says in a recent report. “Recent model access restrictions and several high-profile cybersecurity incidents have become a global wake-up call, exposing how fragile technological dependencies can be.”

Sovereign AI is about giving organizations as much autonomy, choice, and control as possible as they deploy and run AI systems, Pineau says.

“The notion of sovereignty really is about giving users control over their tech stack, the ability to choose how it’s deployed, how it works, what data is fed into the system, and how employees are exposed to the technology,” she adds.

Pineau wasn’t particularly surprised about the lack of understanding about sovereign AI reflected in the survey. Cohere’s accompanying report is an attempt to bring more clarity to the issue, she says.

Many goals under one umbrella

Confusion about sovereign AI in part reflects practitioners’ varying goals. Some users want to maximize their AI model options, some want better control over data ingested into AI systems, some want data to reside within country borders, some want to control costs, and others may want to run AI models optimized to their native language or culture.

For Berk Yilmaz, co-founder and CTO at AI integrated development environment provider Noah Labs, sovereign AI encompasses five characteristics: data sovereignty, legal jurisdiction, model provenance, operational control, and supply chain independence.

“Fulfilling one of those does not mean fulfilling all the others, so two executives can agree with sovereign AI and have little in common,” he says.

Freedom of choice doesn’t always mean a company has to host an AI model on premises or data must reside within a certain country, advocates suggest. Sovereign AI is more about preserving options when something unexpected happens.

“The sovereignty model performs well even in a situation where the vendor breaks off the contract, your model is added to the list of models that are banned for exports, and the connection is off,” Yilmaz says. “Each of these three scenarios has already played out somewhere in the last year.”

Others have different definitions. Confusion over sovereign AI isn’t surprising because it is four separate concepts that were collapsed into one, says Jeet Pattanaik, founder and CTO of AI solutions provider Glokal AI. Those four concepts: where a company’s data physically sits, what country’s law can compel access to it, who controls the AI model, and whether a company could still operate if the relationship with the model provider ends.

“Vendors usually sell you the first and call it sovereignty, because data residency is easy to demonstrate and makes a good diagram,” says Pattanaik, author of the book Sovereign AI: The Enterprise Guide to AI That Is Private by Design, Compliant by Default, and Yours Forever. “The hard one is the second, and it’s a legal question rather than a technical one. A server in Frankfurt owned by a US company is still reachable under US law.”

While the concept is largely about control, few companies want full control of their AI stack, he notes.

“Building your own models is expensive and usually worse,” Pattanaik says. “What CIOs actually want is bounded dependency: knowing exactly what you depend on, what happens if it changes, and having an exit that doesn’t take three years.”

Future impact

But the benefits aren’t always immediate, Pattanaik notes.

“The value arrives in specific moments, not continuously — when a regulator asks who processes this data and under whose jurisdiction, or when a vendor changes terms at renewal,” he says. “Organizations that thought about sovereignty already have an answer. Everyone else discovers the question and the crisis at the same time.”

Still, Pattanaik sees momentum building for the concept, with regulated industries such as banking, healthcare, and the public sector paving the way, treating it as a requirement.

“Most others are still at the stage of asking during vendor selection and accepting whatever answer comes back,” he says. “From where I sit it’s moved from philosophy to a procurement line item over roughly the last 18 months, but unevenly.”

David Wang, COO at enterprise AI gateway provider Tetrate, sees similar adoption trends with regulated industries and defense contractors leading the charge.

Other organizations should focus on a handful of questions to decide whether to investigate sovereign AI, he recommends. Companies that can most benefit include those with more than one regulator or legal entity, including recent acquisitions; those with a huge developer population running coding agents; and those with one AI model vendor that commands more than half of their AI spending.

“At that size, a supplier price change becomes a budget event,” Wang says.

Like Pattanaik, Wang suggests that sovereign AI is part of a long-game strategy rather than immediate gains. A good plan enables organizations to quickly shift to open AI models when a frontier model gets too expensive, he says.

“This work mostly prevents a loss rather than creating a gain, which is why it rarely wins the budget on its own,” he adds.

Cohere’s Pineau sees benefits for a broad range of organizations. With token costs a major concern for many companies, a sovereign AI plan can explore alternatives to current AI vendors, she notes.

“A lot of companies care about it, but they care about different aspects,” she says. “In regulated sectors, they care about the compliance aspects, and in some sectors with tight profit margins, they care a lot about the cost control. The manufacturing, the telecoms, and the energy sectors care about the ability to control their costs.”

For the first three years of the generative AI wave, the output of a model was a string. You called an API, you got tokens back, you rendered them in a chat window or wrote them to a row in Postgres. The economics of that pipeline were dominated by inference cost. Storage was a rounding error.

That era is over. The output of a modern generative pipeline is an asset: a 4K video clip, a stem-separated audio track, a 50-megapixel product render, a 3D mesh with PBR textures. Generative AI has gone from text-centric to asset-centric, and the architectural center of gravity has moved with it. The teams building durable advantages in generative media right now are the ones treating their storage layer as a pipeline component rather than a destination.

This is a good problem. It is the problem you get when your pipeline works.

Asset-centric changes the shape of the system

Text pipelines are stateless in practice. A prompt goes in, a response comes out and the interesting state lives in a database. You can rebuild almost any artifact by re-running the call.

Media pipelines are not like that. Every stage produces a large, opaque binary that the next stage consumes. A single finished deliverable might traverse a dozen of them: prompt expansion, base generation, upscale, frame interpolation, color pass, audio generation, mix, mux, transcode to delivery formats, thumbnail extraction. Each stage writes an intermediate. Each intermediate is expensive enough to regenerate that you keep it.

The result is a system where the objects are the state. Your object store stops being a place you put things when you are finished and becomes the substrate the pipeline runs on.

Adoption is past experimentation, and the volume is in production

Advertising has the clearest numbers. IAB’s 2026 Digital Video Ad Spend and Strategy Report finds that nearly two in three digital video buyers now use generative AI for creative, up from half in 2025. A third of their ad assets are expected to involve generative AI this year, up from a quarter in 2025, with buyers projecting 43 percent by 2027. That is happening inside a U.S. digital video ad market IAB projects will pass $80 billion in 2026, growing 11 percent year over year, nearly 20 percent faster than the total ad market.

The interesting detail for architects is what the creative is used for. IAB’s prior-year data showed buyers reaching for generative AI specifically to produce audience-specific versions of an ad, visual style variations and contextually adapted cuts. That is not one asset per campaign. That is a matrix.

Games are the instructive counterexample. GDC’s 2026 State of the Game Industry puts generative AI use at 36 percent of industry professionals and 30 percent at game studios specifically, but the usage breakdown is dominated by language models rather than media generation: research and brainstorming at 81 percent, code assistance and routine writing at 47 percent each, prototyping at 35 percent. The most-used tools are ChatGPT, Gemini and Copilot. Sentiment is sharply negative, with 52 percent saying generative AI is having a negative impact on the industry, rising to 64 percent among visual and technical artists. Asset-centric pipelines have not landed in games the way they have in advertising, and the constraint is as much workforce and provenance as it is tooling.

Elsewhere, the pattern holds even where the survey data is thinner: e-commerce teams generating on-model imagery per SKU per segment, localization pipelines producing dubbed and lip-synced variants per market, previsualization work that used to require an art department.

What the adopting categories have in common is that none of them produce one asset per request. They produce a set. The pipeline is judged on how many viable options it surfaces, which means a better pipeline is, definitionally, a pipeline that writes more bytes.

Reactive architecture, because the model layer will not hold still

The model landscape resets on a cadence measured in weeks. A new video model ships with better temporal coherence. A new audio model handles multilingual prosody properly. A new image model finally gets text rendering right. If your pipeline requires an engineering sprint to adopt a new model, you are structurally behind teams whose pipelines do not.

Reactive architecture is the answer, and it means two specific things.

1. Model-agnostic stages. Each stage of the pipeline should express a contract in terms of inputs and outputs, not in terms of a vendor. A generation stage takes a prompt and conditioning assets and produces a video at a declared resolution and duration. Which model backs it is configuration. Swapping providers should be a config change and an eval run, not a refactor.
2. Event-driven orchestration. Polling-based orchestration couples your stages to a scheduler and makes each new stage a change to the control plane. Event-driven orchestration inverts it: a stage completes, it writes its output, the write itself is the signal that the next stage should start. Adding a stage means subscribing to an event, not modifying a DAG definition that six other teams depend on.

This is where storage stops being passive. Object storage that emits events on write lets your bucket act as the message bus for the pipeline. B2 Event Notifications send a signed HTTP POST to a webhook endpoint when objects are created, updated or deleted, with rules scoped per bucket and filterable by prefix. That prefix filter is the part that matters architecturally: if your bucket is organized by stage, a rule on stage/upscale/ is a subscription to “upscale finished” without any code knowing what upscale is. Custom headers on the notification carry auth tokens or context to the target, so the endpoint can be a queue, a serverless function or a workflow platform rather than a service you had to build.

A completed upscale triggers the color pass. A completed mux triggers the transcode fan-out. A completed transcode triggers the CDN warm and the catalog write. The storage layer sequences the work, which removes an entire class of orchestration glue from your codebase and removes polling latency along with it.

Quality improvements arrive as file size increases

Every generation of media models improves along axes that all cost bytes. Resolution goes up. Frame rate goes up. Duration limits extend. Bit depth and color fidelity improve. Audio moves from mono to multi-channel. Compression artifacts that were acceptable at 720p are not acceptable at 4K, so teams move to higher bitrates and, for anything entering a post pipeline, to intermediate codecs.

The arithmetic is worth doing explicitly. A 10-second clip in a delivery-grade H.264 4K encode at 50 Mbps is roughly 60 MB. The same ten seconds as a ProRes 422 HQ intermediate, which Apple targets at 884 Mbps for 3840×2160 at 30p, is 1.1 GB. That is roughly 18 times the size, and intermediates are exactly what you keep between stages. Now assume your pipeline generates eight candidates per brief because your creative director wants options, and each candidate produces four intermediates before final. That is one brief consuming tens of gigabytes.

Nobody plans for that in a proof of concept. Everybody encounters it in month four of production.

The iteration multiplier

Here is the part that surprises teams: robustness and storage growth are the same curve.

A fragile pipeline produces one output per request because that is all it can manage. A robust pipeline produces candidates, keeps the rejects for training and eval, versions every asset so a creative decision can be reverted, retains intermediates so a late note does not require regenerating from the prompt, and derives proxies, thumbnails and per-platform cuts from every approved master.

Each of those is the correct engineering decision. Together they mean that improving your pipeline increases your storage footprint superlinearly relative to your output volume. If your unit economics assume storage scales with delivered assets, they are wrong. Storage scales with attempts multiplied by stages multiplied by versions multiplied by derivatives.

This is why storage strategy has to be a design input rather than a line item you discover on an invoice. The two things that turn it from a manageable cost into a structural problem are egress pricing and the absence of a lifecycle policy. Egress hurts most in the exact architecture described above because a multi-stage pipeline repeatedly reads its own intermediates, and a distribution layer constantly reads masters. When every read carries a metered charge, the pipeline design that produces the best creative output is also the one that produces the worst bill, and teams start making architectural compromises to protect margin. Lifecycle policy hurts by omission: if you never decide what an intermediate is worth after 30 days, you pay to keep all of them forever.

What to put in place now

If generative media is core to what you are building, four decisions determine whether your storage layer accelerates you or constrains you:

1. Choose a storage economic model that does not penalize reads. Understand your egress terms before your architecture depends on them. A pipeline that reads its own outputs at every stage is a read-heavy workload, and pricing that assumes write-once, read-rarely does not fit it. Model the ratio you actually expect: egress as a multiple of stored volume, not as an absolute. That ratio is the number to design against.
2. Make writes trigger work. Use object-level event notifications as the pipeline’s signaling mechanism. This buys you loose coupling, lower latency between stages and the ability to add a stage without touching the orchestrator.
3. Attach metadata at write time. Model version, prompt hash, parent asset, generation parameters, approval state. Metadata written at generation time is nearly free. Reconstructing provenance across a million objects later is not; provenance is what makes your rejected candidates usable as eval data and a training signal.
4. Define lifecycle policy per artifact class. Masters, approved derivatives, intermediates and rejects have different retention values. Encode that as policy on day one rather than as a cleanup project in year two.

Which points at the useful way to think about the storage layer: in a pipeline where everything else churns, it is the constant. Models turn over every few weeks. Stages get swapped, added and reordered around them. Output volume compounds with every quality improvement. The one layer absorbing all of that without being redesigned is the one holding the assets, so it is worth choosing based on the characteristics that stay true while the rest moves. That is what we built B2 for. Always hot, so no stage waits on a rehydration to read what the last one wrote. No retention minimum or file size floor, so intermediates that were always disposable cost what they used. Egress scales to what you store rather than metered per read, so a pipeline that reads its own output is not penalized for being good at its job. The architecture above it should change every quarter. The storage underneath it should not have to.

The opportunity

The teams that will win in generative media are not the ones with privileged access to a model. Model access is converging toward commodities. The advantage is in the pipeline: how fast you can adopt a better model, how many candidates you can afford to generate, how much history you retain to evaluate and fine-tune against, and how cheaply you can move all of it.

Every one of those is a storage architecture question. Treat the storage layer as an active participant in the workflow and it becomes the thing that lets you iterate faster than your competition. Treat it as a bucket you dump finished files into, and it becomes the ceiling on how good your pipeline is allowed to get.

The assets are the product now. Architect accordingly.

Businesses received a staggering amount of cyberattacks in June, according to Check Point, showing a rise of 20% over the previous 12 months. The breakout of AI agents from OpenAI in July to hack into the Hugging Face website, and subsequent similar events from Anthropic and Meta, indicate agentic-powered attacks will explode over the coming year.

Currently, malicious hackers have the advantage because publicly released frontier models from the US incorporate guardrails that can’t distinguish between malicious or defensive activities. As a consequence, these models default to a refusal to get involved. Hugging Face discovered this the hard way when they attempted to utilize a model to defend against the OpenAI intrusion. Their solution was to adapt a Chinese open weight model to analyze the 17,000 attack logs, find the vulnerability, and contain the intrusion.

With incidents like these happening more often, an arms race has begun with AI being both the problem and the solution.

Strength in numbers

While single agents generally perform more efficiently for well-defined tasks, research from Stanford University indicates swarms are more effective in messy scenarios with noisy data, which are more typical of unpredictable, intrusion attacks. The increased token usage by swarms raises costs, but increasingly efficient open weight models are rapidly lowering these barriers.

In the Hugging Face example, the agents worked together as a team leaving messages for each other on a message board they improvised. They shared newly found vulnerabilities, exchanged tools, and even developed conventions to address one another and to avoid overwriting each other’s work. While this may seem sinister, they were only following their designated purpose: to achieve a goal without regard to any collateral damage. We can expect bad actors to harness the power of agentic swarms through fine-tuning open weight models, and creating agents that progressively learn from their experiences.

Modern warfare has been transformed over the last four years, too, through the deployment of drones by Ukraine to defend against Russian attacks. Military strategies and the deployment of armament budgets around the world are shifting to focus on new technologies, and approaches and enterprises are now facing a similar challenge from the hostile use of agentic AI.

The drawbridge is down

As enterprises build out their own agentic systems to handle ecommerce, customer service, and marketing activities, this presents new attack surfaces for antagonistic efforts. April 2026 research from Trend Micro found almost 1,500 MCP servers directly exposed to the internet had no authentication or encryption, a rise of 200% from nine months earlier. This included 70 hosts offering direct SQL execution, and servers holding medical records.

The automation of business processes and the reduction of humans from decision making chains open up new vulnerabilities for agents with malicious intent. Arkose Labs’ 2026 agentic AI survey of 300 enterprise leaders found 97% expected an AI agent security incident within the next 12 months.

Social engineering

While agents have demonstrated their ability to break through security systems, they’re also capable of targeting humans to achieve their objectives. Recent research from Verizon indicates that 62% of successful breaches involve a human element, with phone-based attacks 40% more successful than email-based ones. In August, for instance, scammers using an AI-generated deep fake of Australian Prime Minister Anthony Albanese’s voice were able to scam investors out of $5.3 million.

If agents can break out of digital sandboxes, and generate convincing fake videos and audio, then they’re certainly capable of making basic phone calls. In July, during testing of frontier models, the UK AI Security Institute discovered an agent tried to insert malicious code into an open-source project. Attempting to get the code approved, the agent created fake online identities using them to persuade the project’s maintainer to sign it off. “This is the first time we’ve seen risks around autonomy and deception manifest this clearly without specific prompting in the real-world,” the Institute put in a write-up of the incident.

Fight AI with AI

So attackers currently have the upper hand in this escalating arms race. They have access to agents that can work around the clock, constantly probing, learning, and sharing their knowledge with other agents. They’ll only get better at this and learn ways to stay ahead of defensive systems. International agreements to delay or restrict the capabilities of frontier models won’t stop hostile actors motivated by money or rogue states pursuing other objectives. Developers and security vendors need access to the latest frontier models unfettered by restrictive guardrails if we’re to stand any chance of defending against the coming tsunami of attacks.

We can learn a lesson from recent history on this front. In 1992, the US restricted exported software to weak 40-bit encryption, citing security concerns going back to the cold war. While the US allowed stronger encryption internally, the result was weakened security for everyone as hostile antagonists were able to disrupt global supply chains that incorporated less secure software. Despite lifting the ban in 1999, embedded software containing 40-bit encryption continued to cause problems for many years across multiple countries, including the US.

Without rapid action, we may look back fondly to the world before July 2026 as a golden age for cybersecurity, a relative age of innocence.