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.

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.

At CIO100 in Frisco, Texas, roughly 100 rising technology leaders sat down for our “Next CIO” session. The group was asked to reflect on a single question: Are you ready to take on the role of CIO? Using the CIO Readiness Framework that we have developed and refined over years of advisory work, we asked each person in the room to score themselves across the five dimensions of the framework. The results point to a gap that should worry any organization building its next generation of technology leaders.

The CIO Readiness Framework

The CIO Readiness Framework organizes the CIO job into five dimensions. We asked each rising leader to score themselves on the same 1-to-5 scale, from “Emerging” to “CIO-Ready.” The five dimensions of the framework are:

• Enterprise leadership: the ability to lead beyond your own function, anticipate where the business is headed and mobilize people through change.
• Business value and financial acumen: understanding how the enterprise makes money well enough to connect technology decisions to growth, margin and risk.
• Influence, narrative and enterprise selling: building belief and support before a decision is ever formally proposed, not just presenting sound logic once it is. 
• Relationships, talent and operating leverage: building trusted executive relationships, developing successors and creating an organization that delivers beyond your own personal reach.
• Technology stewardship and digital judgment: the technical fluency and architectural judgment needed to make durable enterprise technology decisions.

Where the room stands

Across the five dimensions, the average self-assessment landed at 3.4 out of 5, squarely in ‘Proficient’ territory. Consider who was in the room: people already selected by their own organizations as ready to be developed for the next level. Even so, not one of the five dimensions averaged ‘Advanced’ or higher across the entire group. Technology Stewardship and Digital Judgment (the ability to make sound decisions on platforms, architecture and risk) came in as the most mature dimension in the room. At the bottom sat two dimensions in a near tie: Influence, Narrative and Enterprise Selling; and Relationships, Talent and Operating Leverage.

Much more interesting, however, is the spread between the highest- and lowest-rated dimensions. On these bottom two dimensions, ~65% of attendees rated themselves Proficient or below. Compare that to Technology Stewardship, where the number was only 36%. Put plainly, the people in that room are confident in their technical judgment. They are far less confident in the parts of the job that have nothing to do with technology at all.

Why the human dimensions lag, and what to do about it

This tracks with what we hear constantly in our advisory work. Most people who reach the doorstep of the CIO role got there by being excellent at the technical and operational core of IT. Few of them spent their first fifteen years being evaluated on stakeholder mapping, coalition-building, or developing a successor. Those muscles simply were not required until now.

The good news is that these are learnable skills. We recommend a simple approach to close these capability gaps: for the dimensions where you rated yourself lowest, identify a goal that targets your weaknesses, then attach a tactic (a concrete action or behavior) that moves you toward achieving your goal. Lastly, give the whole thing a timeframe. Six months is often a good starting point, as it is long enough to make real progress and short enough that you’ll actually check.

In this activity, the goal represents the destination – for example, to develop a brand of “enterprise leader,” rather than just “strong IT operator.” The tactic is how you get there, something specific enough that you’ll know in six months whether you did it or not. “Get better at influence” is a goal with no tactic attached, which is exactly why it rarely changes anything. “Hold pre-alignment conversations with three sponsors before my next major proposal” is a tactic, and it’s either done or it isn’t.

Here’s what that pairing looks like applied to the two lowest-scoring dimensions from the CIO100 room:

• For Influence, narrative and enterprise selling, a reasonable goal is building support for ideas before they ever reach a formal decision point. Tactics in service of that goal include identifying the informal decision-makers behind a priority and earning their support early, or taking on an external opportunity (e.g., industry panels, published point of views) to build credibility beyond the building.
• For Relationships, talent and operating leverage, a reasonable goal is creating executive capacity instead of personally absorbing more of the work. Tactics in service of that goal may include adding standing one-on-ones with two peers on the executive team, and delegating two recurring items off your own plate with clear decision rights attached.

The takeaway for CIOs building their bench

If you’re a sitting CIO developing your own successors, this data serves as a useful gut check. The people you’re grooming may already operate at an advanced level technically while carrying real gaps in the skills that determine whether they succeed once they have the title. Executive presence, coalition-building and delegation take years to build, so the earlier you start, the better.

The future leaders we worked with at CIO100 had no shortage of ability. What most of them lacked were the specific, practiced habits that turn a strong technology leader into an enterprise one, and the self-assessment data shows they already know it. Acknowledging that gap is the first step toward closing it.

Some of the most impactful engineering breakthroughs likely make for very boring marketing demos.

Over several decades spent leading development teams, I have seen firsthand how tempting it is to focus engineering efforts on highly visible, flashy new features. I’ve known many developers who get bogged down by the pressure to package every software update with a supremely marketable new element or two that’ll get people talking.

But in my experience, the features that most enhance a user interface are often completely invisible to users.

Performance, reliability and security are not the sexiest features, but they’re crucial elements to a satisfactory user experience. That’s especially true when you’re engineering for users working within complex vertical industries – such as architecture – who count on simple, dependable technology to bring their daily work to life as seamlessly as possible.

My foundational philosophy is that the absolute best software is the kind you can dig into without ever needing to pick up the user manual. Users shouldn’t have to spend valuable time fighting to navigate complex menus, acting as manual data routers who must convert one format to another just to connect the dots. When professionals can focus on using their tool as solely a means to an end rather than a puzzle they have to solve, that is when you know you have done your job well as a developer.

The unsung heroes of successful software: Speed, reliability and security

R&D teams often must fight to justify investing in foundational software improvements because they simply aren’t as visually marketable as shiny new capabilities. But performance is a hidden expectation that great developers cannot afford to ignore.

As a Chief Technology Officer guiding design software development for AEC professionals, I’ve learned modern users have incredibly high standards for speed. This is especially true for younger users just entering the workforce. If they have to wait more than a few seconds for their tool to function as directed, it will come at a cost to their sustained attention and workflow.

Reliability is also paramount for modern tech professionals, particularly as we integrate more automation and artificial intelligence into our workflows. When we implement automation to handle boring, repetitive tasks, our users need to know that the system is worthy of their rock-solid trust and can execute those tasks flawlessly.

To use an example relevant to my market, imagine you’re an architect designing a highly complex, multi-million-dollar project for a new hospital with thousands of rooms. You’re collaborating with dozens of other engineers from multiple disciplines, both structural and electrical, and all of you are working on the same model. If you direct the software to automatically update the wall weights across all the bathrooms in the entire hospital, you’re investing your absolute trust in that software accomplishing the task exactly right without interfering with other modeling being done simultaneously.

If the program is unsuccessful or hinders other parts of the project, the user loses trust in the software and the greater team loses trust in the user. That kind of trust is hard to build back.

And if the mistake is not addressed quickly, it could prove costly – potentially pouring significant additional spend into the project budget and contributing to the $2.1 trillion in project cost overruns that occur globally each year. What starts as a simple glitch in software performance can end with significant damage, the kind that could prevent users from ever going back to that tool.

For a similar reason, security is another pivotal foundational element developers must prioritize. In fact, data protection must be prioritized above all else – especially in fields like architecture where you’re dealing with a lot of precious intellectual property. A software user could not care less if an incredible new, time-saving feature is unveiled if, simultaneously, the software environment isn’t secure and their files are vulnerable to corruption.

Developers must focus primarily on protecting the complex digital assets and sensitive information handled with their software. To bring back our hypothetical architect, imagine a project to upgrade a government intelligence facility, with building floor plans that reveal the locations of secure rooms, surveillance locations, emergency exits and other privileged intel that, if put into the wrong hands, could jeopardize the safety of those working on-site.

Ensuring data is never lost, providing redundant storage and keeping sensitive information safe is our absolute baseline responsibility to users. While we might only briefly mention security enhancements in marketing collateral, it is a continual investment in a secure, reliable environment that keeps good software good.

Learning when what glitters isn’t gold

To measure the true return on investment for our R&D efforts here at Graphisoft, we rely heavily on product telemetry to see what users actually engage with. We recently introduced a brand-new, AI-ready data platform that allows us to analyze anonymized usage logs to see exactly which functions are being used and which are being ignored. This data is essential because if the product team convinces us to build something they believe is vital, we can calculate the development cost and then track if it delivers real value to our users.

A while ago, we unveiled a highly visual, flashy tool for our BIM software platform, Archicad, called the AI Visualizer. We were really proud of this tool. Essentially, users could start with a basic drawing or photo of random objects, such as a stack of boxes on a desk. They could then ask the AI Visualizer to create a skin based on the image or drawing, and the software would generate a high-tech office building or a beautiful wooden structure mimicking those shapes. It was an incredibly enjoying tool for creative work at the very beginning of a conceptual design phase.

Based on our continuous usage data analysis, we determined changes were necessary to retain long-term interest in the AI Visualizer – prioritizing enhancements that advanced open standards and seamless collaboration, rather than focusing too heavily on flashy UI additions. The biggest frustration they face is a lack of multidirectional collaboration capabilities and the tedious manual work required to transfer data between closed systems. So, in response, our team homed in on an open, cloud-agnostic environment where our users never feel trapped or dependent on a single provider.

Openness isn’t a flashy UI button, but allowing users to seamlessly connect their dots, export to any format and integrate with any technology is a massive differentiator for user satisfaction.

As a developer, you want users to choose your software every day because it is excellent – not because you have them locked into a closed ecosystem.

The future of intent-based software

I believe we are currently experiencing a paradigm shift away from traditional, click-heavy interfaces and toward what we call “intent-based design” that allows architects and engineers to specify a destination and letting the software itself figure out how to get there.

Across most vertical industries, R&D teams are building toward an AI-native nervous system that digitalizes common knowledge, allowing software to continuously learn and execute tasks based on a massive internal knowledge graph. This trend will contribute to increased intent-based design – and I believe that even in the near future, the user manual will become obsolete.

Rather than having to manually execute against each step in the engineering process, intent-based workflows allow a user to convey a vision and prompt the software to bring it to life based on the low-level functions and knowledge already built into its system. In architecture, for example, that means prompting your BIM modeling software to design a house within the specific parameters of Frank Lloyd Wright’s architectural style, rather than manually guiding it through each of those individual parameters yourself.

An argument for “boring” R&D

My ultimate goal is for our software to act as a quiet partner to great work. I think about it the same way as working with a great human colleague who you don’t have to over-explain every tiny detail to; instead, they understand where you’re headed as soon as you’re halfway there, understanding you in half the words and getting to work in half the time.

I want our software to behave the same way with, for example, intuitively predicting a user’s next step, seamlessly guiding them through new features without requiring any training. Our goal is to handle boring, repetitive tasks so users can remain fully immersed in their creative flow. With that we can provide immense value while demanding minimal attention, prioritizing what’s functional over what’s flashy.

When it comes to R&D, the sexy new features might get people in the door, but it is the invisible strength, the relentless reliability and the quiet partnership of the software that will keep them loyal.

In the summer of 2024, JPMorgan Chase deployed its internal AI platform LLM Suite, launching it very differently than most do: The company didn’t force anyone to use it.

When LLM Suite arrived at its first major division, asset and wealth management, employees were asked to think of it as a research analyst: someone to ask for data, a draft, or an idea. Leadership didn’t set usage objectives or provide a formal mandate.

Access was rolled out in phases and only to those who requested it, and the bank allowed the tool to circulate through word-of-mouth recommendations among colleagues. While half the industry rushed to count users and publish adoption rates, JPMorgan gave up on pursuing that number.

It became flooded with users. In eight months, 200,000 employees had signed up without a single order being issued, out of a workforce of over 300,000. In time, the bank established more than 450 use cases in production.

Two years after that summer launch, JPMorgan had everything to boast about. It had established itself as a global leader in the use of AI: It was the top bank on the Fortune AIQ 50 list, and the third company overall, ahead of all the tech giants except Alphabet.

It was then that the bank’s head of analytics, Derek Waldron, the person best positioned to sell the success, pointed out what still wasn’t working: There was a gap between what the technology was capable of doing and what the bank was actually capturing in its business results.

That gesture is what distinguishes JPMorgan. Although it has much to celebrate, it knows what it lacks, it says so publicly, and it keeps searching for it. Behind that statement lies a way of innovating and measuring that the bank has been developing for years.

Giving up the number everyone was chasing

The first thing JPMorgan did right was not to make adoption the goal. By not forcing anyone, it turned platform usage into a barometer. If a tool worked, it was filled without any campaign; if it didn’t, it was emptied, and that emptiness provided valuable information. If adoption had become a target to be pursued, the organization would have optimized the number instead of understanding what the number represents.

The bank itself acknowledges that if a tool is broadly used, it means it’s popular, but not necessarily effective. To determine its effectiveness, something more was needed. The answer came from two decisions that only work together: linking each project to a business outcome, and creating the metrics to demonstrate that outcome.

First, to find initiatives that could have a real impact, instead of creating an agenda from the top down, the bank surveyed its business units, asking where there was a problem to solve. Within a few weeks, an internal portal gathered, according to the bank’s figures, nearly a thousand ideas. Of these, only a few hundred moved forward and reached production. An organization doesn’t open a funnel of that size if it expects most ideas to survive; it anticipates that many will be discarded.

The funnel’s filtering method was also different. Before launching each test, the outcome that would ensure the experiment’s survival was defined, along with the steps to be taken the day after the decision. By planning future actions in advance, indecision and the perception of failure were avoided.

A clinical approach to AI experimentation

But setting a threshold for each experiment requires verification, and that’s where the bank encountered an unexpected obstacle. Metrics have their own cycles. Bank customers conduct business on Mondays, not Sundays. They receive their paychecks at the end of the month. In August, they disappear. When an initiative generates a change and a figure rises the following week, there’s no way to know whether it increased due to the change or the calendar.

The solution was borrowed from clinical trials. Instead of rolling out the change to all users, it was rolled out to half, chosen at random. The other half (the control group) operated on the same Monday, the same payroll, and the same August, so that the experimental contribution (the attribution) could be separated.

The next step was to industrialize the experiments. Doing it properly required a specialist sitting alongside each product team, and with that method, they reached eight per year. A self-service platform increased the figure to around 300 tests annually.

The results are concrete. For example, tens of thousands of the bank’s engineers have gained between 10% and 20% efficiency thanks to an internally developed programming assistant.

Finally, the bank discovered that a figure can be accurate and yet mean nothing. Its head of analytics explained this with a simple example. They measure the hour that AI saves one employee, and the three hours it saves another. They add them up, and the result is accurate. But in a process that goes from beginning to end, those saved minutes often don’t appear on the bottom line: They merely shift the bottleneck to the next one.

It’s easy to get stuck on partial metrics because they’re more immediate and produce more impressive numbers. JPMorgan’s discipline consisted of not accepting a metric as valid until verifying its impact on the business at the end of the process.

The question then remains on Monday morning: What can a company that has neither the size nor the budget of a bank take home?

The method is what best exports

What’s most interesting about JPMorgan isn’t what it has done with AI, but how it has done it . Any company can replicate this approach, because it doesn’t depend on proprietary data, scale, or budget.

The following are some best practices that don’t require a €20 billion annual budget. They do require making decisions before starting and are within reach of any company:

Launch far more initiatives than will survive, and announce this clearly. If the organization discovers halfway through that most of its projects will be canceled, it may misinterpret this as a planning failure; if it knows from the outset, it understands it as the natural selection process. This is what makes making mistakes quick and cheap.

Decide in advance the threshold that will shut down a project and plan the next steps. Both aspects are necessary, not just the metric. If a certain figure isn’t reached, the team needs to know what will happen next. Applying a threshold without future planning leaves the team in limbo, and they’ll have to find a reasonable reason to wait another quarter before shutting down.

Work on business outcome metrics from the outset, not just when they’re requested. This tracking not only guides the initiative but also prevents having to reconstruct months of poorly documented decisions. Adoption, by the way, is the number the CFO won’t ask for. It serves as a signal while no one is pursuing it, and it ceases to be useful the day it becomes a target.

How to get it right

Whether metrics mean anything depends on where you focus your attention. It’s best to start with scope, because that’s the most common mistake. Saving three hours in one stage isn’t the same as improving time-to-market: If the entire process isn’t shortened, what you have is freed-up capacity, which is also valuable, but it’s something different, and it’s advisable to make that distinction clear.

Then it’s important to consider that value leakage occurs in two directions. The first is outward: The savings are passed on to the customer in the form of lower prices or better service. The second is inward: The savings in personnel are replaced by spending on computing. If these items fall into different budget categories, it’s easy to overestimate the actual savings.

Finally, there’s an excessive focus on cost savings, at the expense of revenue opportunities. Jamie Dimon, CEO of JPMorgan, put it more bluntly to his analysts than any consulting firm: No one benefits uniquely from AI. In other words, competitors will eventually incorporate those savings. The greatest potential for differentiation lies in revenue: using AI to uncover unmet demand.

The question a CIO will have to answer in a year’s time won’t be how much AI their company uses. It will be which of projects are still alive because they work, and not because no one has bothered to test them.

A few weeks ago, in these pages I argued that AI is repricing enterprise software faster than most vendors want to admit. Since then, the sharpest pushback I have gotten from peer CIOs has not been about the pricing thesis. It has been about the leaders navigating it. What does this shift actually ask of the people leading their organizations through it?

The honest answer, from where I sit, is uncomfortable. AI is the first enterprise technology in a generation where the leader’s personal experience of the tools has become part of the leadership instrument itself. Most senior IT leaders, including many I speak with regularly, have not yet caught up to what that means. For most of my career, my model for leading technology change was familiar: read deeply, talking to peers, pressure-test with my team, communicate direction, drive execution. That model does not work for AI. I did not figure this out because I was smarter than my peers. I figured it out because I stopped talking about AI and started using it, and the difference in my own judgment surprised me.

The credibility gap most IT leaders don’t see in themselves

The data is more revealing than the conventional commentary suggests. Gallup’s Q4 2025 workplace research found that frequent AI use among leaders had reached 44%, up from 17% in mid-2023. That sounds like progress. But 56% of senior leaders still do not use AI frequently in their own work. And frequent use does not necessarily mean sustained, real-stakes practice with the tools. More than half of the people setting enterprise AI direction are doing so from a distance.

Grant Thornton’s 2026 AI Impact Survey makes the problem visible from a different angle. Of 950 senior business leaders surveyed across ten industries, 78% reported they lacked confidence they could pass an independent AI governance audit within ninety days. The leaders setting direction on AI cannot, by their own admission, explain how their AI decisions get made or who is accountable for the outcomes. Articulation has run ahead of practice across most of the executive population.

I see the same pattern at closer range. In peer CIO conversations, on conference panels and in executive committee discussions inside other organizations, I keep meeting senior leaders who are the most articulate strategic voices on AI in their companies but have not personally used AI in their own work. They have read about it. They have been briefed. They have approved budgets. They have given speeches. They have not lived with it.

I call this the AI credibility gap. It runs from the CEO suite through the C-level and into mid-management. The failure mode it produces is specific: leaders talk fluently about AI strategy without being able to engage with the realities their teams encounter daily. The teams notice. They stop bringing real problems forward because the conversations skim the surface. They stop trusting prioritization because it does not reflect what they are actually experiencing. They start working around leadership rather than with it.

The credibility gap is not a knowledge problem. The leaders involved are intelligent and motivated. It is an experience problem, and experience cannot be briefed.

Why this shift is different from the ones ITDMs have led before

A reasonable objection: senior IT leaders have managed major technology transitions for decades without becoming hands-on practitioners. CIOs led cloud transformations without writing infrastructure-as-code. CFOs led ERP implementations without configuring modules. Why is AI different?

Three things have changed. AI tools are designed for direct human use in a way enterprise infrastructure never was, which means a leader who has not used them is unfamiliar not just with a technology but with a new mode of knowledge work. Second, AI capability changes faster than any leader’s briefing cycle can keep up with, so leaders working from quarterly briefings operate with a perpetually stale model of what the technology can and cannot do. Third, and hardest to communicate to leaders who have not lived it, AI works probabilistically. Knowing when to trust an output, when to verify, when to push back, when to escalate: these judgments accumulate through hours of personal use, the way clinical judgment accumulates in a physician. A leader who has not done that accumulation is asking their teams to do it instead, and to make the resulting calls without leadership cover.

Personal practice, in other words, is now a prerequisite for AI leadership rather than a complement to it.

What actually changed when I started building with the tools

I noticed the credibility gap in myself before I saw it in anyone else. Several months ago, I decided to stop talking about AI as a topic and start using it as a tool. Not the demo-and-show-off way most executives engage with AI, with a Copilot prompt here and a ChatGPT query there, but as a daily instrument in the actual work I do. Drafting strategy documents. Stress-testing arguments before taking them to the leadership team. Working through analysis I would previously have outsourced.

At one point I went further. Coming from a product and supply chain background, I built an inventory contextual model using AI, a working tool rather than a slide, to think through supply, demand, inventory levels, cash flow and downstream customer impact. I did this not because my team could not have built it, but because I wanted to live inside the problem myself. The act of building taught me more about AI’s strengths and limits in a few weeks than two years of vendor demos had. I saw where the model held up under real data, where it broke, where the judgment of an experienced operator was still load-bearing, and where AI genuinely extended what a human alone could see.

The change in my leadership was not what I expected. The efficiency was real but turned out to be the least interesting part. What changed was my judgment. I started understanding what these tools are genuinely good at, where the failure modes hide and where the value sits underneath the marketing layer. That judgment changed how I prioritize AI investments, which vendor demos I find credible, how I push back on enthusiastic recommendations from my own teams, and most importantly, how I talk to my organization about AI. The conversations moved from compliance to engagement. We started moving faster, not because I pushed harder, but because the team trusted the direction more.

You cannot direct an organization’s AI transformation with conviction if your own working life has not been transformed by it.

The advice that actually matters: Pick the work that scares you

If I could give one piece of advice to a peer IT leader trying to close their own credibility gap, it would be the opposite of what most AI-leadership pieces say.

The instinct of senior IT leaders is to start using AI on the parts of the job that are already routine. First-draft emails. Meeting summaries. Scheduling. The parts where the risk feel low and the productivity lift feels visible. That instinct is wrong. Routine work produces routine learning. It gives you exposure to the tools but not to the judgment that changes how you lead.

The judgment that matters develops when AI is sitting next to you at the work where your professional identity is most exposed. The analysis you used to outsource to consultants. The strategy memo where your reputation is on the line. The problem you privately believed only you could solve. That is the work that changes you, because it is the work where you must grapple honestly with what the tool can do that you cannot, and where you can still see clearly what you can do that the tool cannot.

This is uncomfortable for a senior leader. It should be. If you use AI only in the safe parts of your job, you are protecting your professional identity from the encounter that would actually update it. You get to keep believing the tool is a nice supplement to what you already know how to do. If you use AI on the parts of your job where your expertise is the whole point of your seat, the encounter is different. You find out where your judgment still holds. You find out where it does not. You find out how the tool and your expertise combine into something neither could produce alone. That is the learning that changes how you lead.

This is where the ITDM instinct gets in the way most. Many CIOs and IT leaders I speak with have started using AI in IT operations, which feels like home territory and where the productivity gains are visible. That is fine, but it is not where the credibility gap lives. The gap lies in strategic decision-making, board-level analysis, cross-functional trade-off calls and the judgment work leaders were promoted for being good at. Those are the areas where most leaders have never used it.

So, the question I would put to any IT leader reading this: what is the work you are best known for? The work you would not want anyone else to touch? That is exactly the work you should be doing with AI, this month, before you write the next AI strategy document your organization asks you for.

The stakes

The personal practice of the leader, more than strategy or budget or governance, is going to determine whether organizations succeed or struggle with AI transformation. Strategy without lived experience produces hollow direction. Budget without lived experience produces misallocated investment. Governance without lived experience produces over-correction or under-correction depending on which fear is loudest in the room.

The IT leaders I see doing this work quietly, on their own time, with their hands on the tools, are the ones I expect to define the next decade of enterprise transformation. The ones who keep articulating without practicing will find themselves increasingly disconnected from the organizations they lead. The teams will move on. The strategy will drift. And the leaders will not understand why, because the gap they have created is invisible from the seat they sit in. The question is not whether AI will reshape your organization. It will. The question is whether you will reshape yourself first, enough to lead the transformation rather than narrate it.

IT leaders have been making generative AI tools available across the enterprise for just three years, and a significant majority of their business users has already had enough.

According to a report from Adaptavist, 65% of 2,500 knowledge workers surveyed say they “regularly feel nostalgic about how work operated before the widespread adoption of AI.”

This “pre-AI nostalgia” appears to be due in part to business users feeling overwhelmed by the responsibility of learning how to use AI on top of their day-to-day job tasks. Moreover, 46% of workers say their concerns about AI have gone unaddressed by management.

“Transparency is critical to truly drive AI engagement; organizations must establish clear guardrails and maintain an open dialogue around AI use and employee choice where workers feel they are being listened to,” Jobin Kuruvilla, field CTO at Adaptavist, tells CIO.

Generational gaps in AI acceptance

Despite an assumption that younger workers are more intuitively adept with AI tools, Gen Z workers (42%) are more likely to prefer the pre-AI world compared to their Gen X colleagues (26%). This may support the growing concern that AI is quickly is hitting entry-level workers the hardest, while creating new career opportunities for more skilled workers who have been in the industry longer.

When asked about fears surrounding job obsolescence due to AI, 54% of all workers surveyed said they are “concerned AI could reduce the need for their role within the next five years.” Broken out by organizational level, junior employees (23%) and C-level executives (29%) expressed the most concern about AI job loss, compared to 13% for mid-level employees and 12% for senior employees.

Additionally, 47% of C-level executives and 36% of directors are looking to move industries, change careers, or step away entirely due to concerns of AI eliminating their positions. Still, plenty of workers are ready to face the new challenges of an AI-driven workplace, with 74% saying they are actively learning new skills to stay relevant, and 85% of C-level leaders saying the same.

Lack of transparency drives AI fatigue

One in three workers (36%) are already experiencing “AI fatigue,” leading to less frequent use of AI tools and active resistance to AI for day-to-day tasks. More than a third of workers (36%) also appears to be confused about AI use expectations in their role.

When implemented quickly without proper training and transparency, AI initiatives can lead to hidden productivity costs. Of those surveyed, 42% say they “spend more time verifying AI output than they save using it,” while 52% say they regularly spend time correcting AI-generated work from colleagues. Additionally, 49% say low-quality AI outputs slow down projects, 55% say AI-generated content reduces overall team efficiency, and 46% say it makes their work feel “more repetitive and less meaningful.”

Half of all workers also feel their performance is now “directly or indirectly compared to AI-generated output.” Providing clarity about how AI impacts or doesn’t impact an employee’s career is important to staving off AI fatigue.

For those chalking this all up to change resistance, know this: 67% of workers surveyed say they want their organization to increase the use of AI, and 69% say they believe AI is being used ethically within the organization. What they lack is a roadmap, guidance, and training to understand how to best implement AI at work, and to ensure it’s being used effectively.

“Ultimately, by automating the mundane tasks that make work feel repetitive —organizations can refocus their specialists on high-value creativity, transforming AI from a source of fatigue into a powerful engine for meaningful human achievement,” says Anand Unadkat, a senior solutions architect at Atlassian.

IT leaders and their executive colleagues need to focus more on the change management artistry necessary to help get them there.

Meta won’t judge employees by how much they use AI when it comes to annual performance reviews, despite early efforts to drive AI adoption focusing on so-called token maxing.

The company has told employees that it “will not use AI adoption dashboards or token counts to evaluate impact,” according to  a report by The Information.

The announcement came in an internal memo from executives Maher Saba and Santosh Janardhan, which said that instead of measuring AI usage, “managers should look at output quality, velocity, problem complexity and scope taken on.”

This marks a culture change for Meta, where engineers had previously competed to consume the most AI tokens, displaying their scores on a leaderboard. Meta then discovered that its employees were being diverted from regular work because they were using AI to carry out additional tasks to boost their scores.

Amazon had similar results when it implemented a leaderboard to track AI use; it also found that some employees were trying to game the system by using AI to complete unnecessary tasks, and it has now deleted it.

The company, however, does also monitor employees’ use of AI for training purposes, in a program introduced in April, but this is information was not used to measure employee performance.

Meta had already started to look askance at the concept of using AI metrics as a tool to assess employees. Earlier this year, Chief Technology Officer Andrew Bosworth told employees in a memo that “nobody should be using AI tools just for the sake of using them,” adding that “token usage alone is not a measure of impact of any kind.”

This article first appeared on InfoWorld.

As spending on cloud technologies grows, so does waste. The Flexera 2026 State of the Cloud Report found that 27% of organizations expect to spend more on cloud this year, with 17% already exceeding their budgets over the previous 12 months. The estimated share of wasted cloud spend has already crept up to 29%, undoing several years of progress, undoing several years of progress.

Companies are rapidly investing in cloud technology, but often understand less about how to use it fully and efficiently. That is not a coincidence, and it is exactly the gap FinOps is meant to close. It is also why the practice is moving out of the finance department and into the strategy conversation.

What is FinOps?

FinOps is a blended operational framework that maximizes technology value by uniting engineering (DevOps), finance, and business teams. It involves close collaboration to break down silos between tech and finance, with shared ownership of cloud spend across engineering, finance, and business teams.

What distinguishes FinOps is real-time visibility into what is being spent and why. It also treats optimization as continuous work rather than an annual cleanup exercise.

FinOps is important because cloud spending isn’t like a typical budget line. It’s more variable and usage-based, so relying on an annual review doesn’t work. Engineers can quickly create infrastructure, scale it, and tear it back down in a day, making forecasting more challenging than in the past.

What FinOps does is change who sees what. Engineers have more insight into the actual cost of a build. Finance gets numbers it can trust. Business leaders can tie spending directly to business outcomes. It removes much of the guesswork and turns cost data into a shared language rather than a monthly surprise.

As Siarhei Sukhadolski, Chief Delivery Officer & Head of Competence Center at Innowise, puts it, “For a long time, FinOps meant only cutting the bill: find the unused stuff, resize a few instances, and report the savings. That still matters, but it’s not what separates companies today. The ones pulling ahead are using FinOps to make faster, smarter calls about where their tech spend actually pays off. That’s a different job, and it shows up directly in how fast a company can move.”

How FinOps spending has changed

Only a few years ago, FinOps was mostly focused on cloud infrastructure spending. Today, that focus increasingly includes AI-specific investment. The FinOps Foundation 2026 State of FinOps Report found that 98% of organizations now manage AI spend specifically. FinOps has also expanded well beyond cloud infrastructure. It’s more common now to see FinOps coverage extend to licensing (64%), private cloud (57%), and data centers (48%). Around 90% also manage SaaS spend or plan to do so within the next year.

It’s also worth noting that the same FinOps Foundation report found that 78% of teams report directly to the CTO or CIO rather than operating solely within finance departments. To us, that reporting line says a lot. It suggests that companies increasingly see technology spending as a strategic lever rather than simply a line item to reconcile.

How AI and cloud spending are moving in the same direction

The trend toward bringing AI and a broader range of technology spending into FinOps is backed up by a Gartner report, which estimates that global IT spending will hit $6.31 trillion by the end of 2026. That’s up 13.5% from the previous year. Data center systems spending is expected to grow 55.8%, with generative AI model spending more than doubling over the same timeframe. Gartner, in a separate forecast, expects public cloud services to grow by 21.3% in 2026, with the market reaching $1.48 trillion in value by the end of 2029.

We see these figures as two sides of the same shift. AI workloads are also usage-based, which makes them more unpredictable, partly because some teams haven’t had to consider unit economics before. A fine-tuning run or a forgotten inference endpoint can quickly become one of the biggest items on a cloud bill. Most teams don’t have the tagging, forecasting, or accountability needed to catch those costs before they get out of control.

“AI spend just behaves differently from a normal application workload. It spikes, it’s hard to pin on one team or feature, and you often don’t know the real cost per outcome until the invoice lands. Companies that already had solid FinOps habits before AI adoption took off are adjusting faster because visibility and ownership were already part of how they worked. Companies that treated FinOps as an annual cleanup are the ones getting caught out.”

Siarhei Sukhadolski, Chief Delivery Officer & Head of Competence Center at Innowise

Why visibility and shared spend ownership create an advantage

Flexera numbers on discount usage point to the same issue: fewer than 50% of organizations are using the most basic cost optimization tools. The adoption of tools like reserved instances or savings plans is slow, with only 48% of companies using Google Committed Use Discounts and 45% using AWS Reserved Instances. Too many others are leaving low-risk savings on the table.

In many cases, the real problem is a lack of ownership and visibility. If no team owns the cost of a workload, no one has enough reason or enough information to choose the right pricing model. That is where the competitive gap starts to open: some companies can explain and act on their spend quickly, while others cannot.

“A mistake we still see a lot is trying to optimize the bill instead of the system behind it. Deleting unused resources saves money once. Redesigning how workloads scale, how environments get spun up, and who’s on the hook for what keeps costs under control for good. That’s the difference that turns into a real competitive edge later.”

Siarhei Sukhadolski, Chief Delivery Officer & Head of Competence Center at Innowise

What visibility and shared ownership look like

FinOps operates well when at least three structures are in place.

• Every workload or inference endpoint has a clear owner tied to its cost.
• Cost and usage data are shared and available to everyone who needs them before they have to ask.
• There is an ongoing review cadence designed around continuous optimization.

Teams that jump into dashboards before assigning ownership and establishing the data flow often end up with visibility but no accountability. Teams that start with ownership, even with basic tooling, get a different result. They tend to see savings stick instead of resetting every few months. That proper order is the single biggest predictor we have seen across cloud and AI cost engagements.

What business leaders need to know

There is a simple test a CEO or CFO should apply to FinOps. It’s whether the company can clearly state what a workload costs and whether it is worth that cost right now. Does it take finance three weeks to answer? Can the company provide an answer in real time? Are there live numbers and clear ownership behind every workload? That is what will enable leaders to make confident calls on where to invest and where to pull back.

FinOps is becoming a proxy for how well a company manages technology. With shared ownership comes high visibility. Add in continuous optimization and companies gain an advantage. These are not just cost-saving tactics. They represent operational discipline, separating those who can move quickly on AI from those who spend heavily only to find themselves still behind the rest of the pack.

While many organizations are still experimenting with AI and debating governance models, a small but growing group of market leaders is already operationalizing AI at scale. Marianne Johnson, executive vice president and chief product and technology officer at Cox Automotive, is one executive creating business impact today.

With responsibilities spanning product, technology, data, AI, engineering, and cybersecurity, Johnson is spearheading an integrated operating model that enables Cox Automotive to move, learn, and deliver customer value faster than the competition.

Johnson joined me on a recent Tech Whisperers podcast episode to discuss how she’s rewriting her leadership playbook to orchestrate one of the largest business transformations in the industry. Reinventing how her company thinks, operates, and creates value in the AI era, Johnson offers a blueprint for a new kind of leader, an “AI operating executive.”

Johnson and I spent time after the podcast exploring this leadership model and what it takes to transform the way the business creates value. What follows is that conversation, edited for length and clarity.

Dan Roberts: Why is a leadership model that encompasses all of product and technology becoming so important today?

Marianne Johnson: When those roles are combined, your ability to get out of your own way is unprecedented. I talk to peers who have a different product leader, a different CIO, maybe a chief data officer in security; only a few have the flywheel spinning at full speed because they’re aligned and on the same page. By having it all in one org, we have one common vision we shape and execute together, continually creating an environment where we feel comfortable to challenge things.

When you think about pre-agentic and agile software delivery, product couldn’t say engineering wasn’t delivering, and engineering couldn’t say product wasn’t giving them the right “what” if you were on one team. You had one vision, one outcome, and you could go as fast as you possibly could.

Then agentic comes in, and everybody can be a builder. Now the lines are blurred. An agent becomes a role on the team. The fact that we’ve had a unified team for eight years now gave us a jump-off point four years ago, and an accelerated jump-off point two years ago. When the big disruption in how software gets created happened, we were already aligned as a team. That allowed us to break down those next-level barriers.

We’re still redefining what that looks like: How do you rethink team size and shape? What are the roles on the team? Who requires what skill set? These questions led us to stop looking at traditional roles. We’re looking at what key activities need to happen, asking who does those activities, including an agent as part of the “who.”

It’s also about flexibility. Your ability to take any talent and say, “You don’t have to just work on that tech stack because that’s your domain expertise, or this product line because that’s your domain expertise.” It’s the ability to create context fast by having your data together and then forming new teams to take on this crazy idea and rapidly move it. Then maybe you go back to your home base, work on another one. Needs are rapidly changing, so you have to have that lens to make competitive advantage happen.

What do CEOs need to do to build a more future-ready organization capable of sustaining that competitive advantage?

The CEO or senior leadership team needs to redefine what leadership you need in place so you don’t limit your opportunity. A year or two from now, everybody in the company can be a builder. But you have to have a control plane to do that safely, reliably, and without creating tech debt, especially in a token economy. Because you could have unintended expenses without the return on investment.

What you put together now to accelerate that opportunity — and do it while managing risk — has to be super intentional. I don’t think a lot of leaders have that map yet, or even the first five steps of that map right now. What an organization’s structure looks like and how work gets done in the future is going to fundamentally shift.

Companies that move in that direction intentionally and lift up to see what’s the next shift will have sustained advantage in the future. There will be very clear delineations for those who don’t do that, and it will be significantly disruptive to the viability of their business model.

I don’t know that I would call that leadership role the chief product and technology officer anymore. The right leader role redefines the current disciplines to get to different outcomes in the future. And depending on what your business is and what roles you have today, you need to determine what that is.

What’s your advice to a CEO who wants to develop this kind of leader, or for someone who wants to grow into this role? What are the essential leadership muscles tomorrow’s AI operating executives need develop today?

They need to look for a leader who has multidisciplinary skills and has executed at scale. That matters, because your business needs to scale fast. These capabilities are changing so fast, you have to have somebody that’s dealt with high change.

What’s challenging is that there is no resume that says this person has successfully operationalized AI at the scale necessary today and has a track record to prove it. You have to seek indications of managing high change, AI fluency, and then the attributes of a leader who can help you navigate through that.

I’ve had a lot of consultants come in and say, we can help you, and I’m like, well, let’s talk about that, because there is no playbook. We’re writing the playbook. If you want to come along beside me and give me extra arms and legs and brains to contribute, you can do that. I’m not going to pay you for that, but you can learn and go on that journey with me.

There will be maps down the road, but you can’t wait for that map to be so clear that you’re doing exactly what somebody else will do. Some business models might be okay with that, but depending on your posture and your current business model and the health of your business, you might not be able to wait. So you need to think about the attributes of your leadership team, their technical fluency, their AI fluency. Even if you’re not a pure tech company, you better have more of your leadership team with that aptitude than not.

Every leader needs to ask what they’re doing to equip themselves. Yes, I had all these experiences with software, data, security, IT, transactional systems, multiple industries, healthcare, credit risk, fraud, payments, now automotive. But it really goes back to curiosity, the aptitude to learn and apply. I spent hours and hours of my own personal time in the evenings learning, listening, asking questions, and putting my hands on keyboard. If I was going to lead this transformation, I had to have a point of view that was grounded in signals and some reality.

If you’re a CFO, a chief marketing officer, the tools are available for you to practice and learn. But you have to make the commitment. If you do that, then you’re preparing your organization to follow you. As a CEO, if you have all your leaders doing that, your opportunities are going to be unlimited. It doesn’t require the background. It requires an aptitude to lean in towards technology.

You mentioned maps. The journey’s not always straight and clear. Can you think of any moments where you realized, we have to redraw the map?

I’ll give you two that are applicable to everybody right now. When Mythos came out, that was a whoa moment. And it’s not just Mythos. It’s any model that has the power and intelligence to find vulnerabilities that have never been found before and, the scariest part, chain them together. The next scariest part is that you could have a bad actor take advantage of those.

So, now how you architect and approach security has to change. Many enterprises scanned monthly; that cadence is now obsolete. Who you partner with has to change or be evaluated to make sure they’re on top of these pivots and changes.

Another example is the fact that models are doing exactly what they have the ability to do, but humans aren’t putting the necessary guardrails around that. We’ve recently seen reports of models in controlled testing attempting to act outside their intended boundaries, behaving in ways their designers didn’t intend. To use a house analogy, if you want a child to stay safely in the house, do you leave the doors unlocked? Are the windows open? Do you put a toddler gate at the top of the stairs?

When we’re seeing signals of model behavior, we better have human on the loop, not just human in the loop. On the loop is, when you see behaviors and signals, you better have enough guardrails and frames so that the model is doing only what you’re allowing it to do. Many models are so goal-oriented, they’re moving mountains to get to that goal. If you say, this is a mountain I don’t want you to climb over, and then you’re not giving them the equipment to climb it, it’s not going to climb it. But if you give them the equipment, and you don’t tell them not to go climb the mountain, it’s going to climb that mountain.

The pace at which these types of realizations and signals are moving requires you to be able to call plays, call actions, and try to think ahead, knowing that you’re not going to think of everything ahead. But you need to be nimble, and the more foundational components you put in place, the easier it’s going to be to react, take action, and put yourself into a posture that’s safe and reliable.

As an executive who owns product, engineering, data, AI, cybersecurity, and technology, what are some of the biggest breakthroughs you’ve seen?

I think the big unlock is alignment and vision. All these functions have interdependencies across each other in a more historical way of working, and that allowed us, for example, to go to the cloud in a transformation journey at an unprecedented pace. It allowed us to unlock our data across the whole company, because it wasn’t somebody trying to talk somebody into adopting the data standards and contribute to our data intelligence engine.

All those things combined allowed us to take advantage of this massive change with generative AI four years ago and agentic two years ago. We didn’t know that when we made those decisions, but it allowed outcomes to be achieved more easily without having an organizational alignment challenge.

It’s exciting to think how the work is changing, how the roles are blurring, what’s possible now as my entire organization moves from an AI-enhanced model to an AI-transformed model. Team sizes are changing, roles are changing. Even if you’re not in that agentic development lifecycle, we’re asking, what are the jobs to be done? If you put an agentic lens on it, how does that work change? We’re starting from an agentic mindset first, and we will reimagine that entire function. Our goal is to be able to give choices back to the business: Where is our margin expansion, where are there reinvestment opportunities, how can we go faster?

Companywide transformation is the hardest part. We are actively engaged in that, focused on the biggest use cases across every function. How do you help your partners transform your call center, your customer engagement platform, your sales effectiveness, your marketing effectiveness, all of those things? We’ve been focused on the everyday AI that helps every employee be better at their job, but the biggest use case is bifunctional areas that have the opportunity to be transformed.

Tell us about your AI Credo, which includes ideas like “Code is no longer the bottleneck,” and how you came up with the product creator role.

We all said we never have enough engineers. Well, now you have this unlimited supply with agents being able to create code. That changes the opportunity but also shifts the bottleneck to ideation, discovery, whether you’re working on what matters most.

Now that you can code faster, how many more ideas do you have? How do you have enough people with the critical thinking skills that can do the right discovery and voice of customer and see around the corner and look at the signals for what the white space opportunities are? Any resource we have that may have been more heads-down coding in the past and has the aptitude to be a critical thinker and do the upfront business part, we want to make sure we equip them to do that and that we are going to be self-funding with the actions we’re taking.

It’s about being able to create more creators. We had a lot of debate around the product creator title, and we realized, it’s not just about building; it’s about creating a higher order opportunity.

Regardless of whether you’re building with agents, the bottom line is you better have a good methodology to think about what matters and why, what you’re building, and what problem and opportunity you’re solving. That front end has never been more important, because that’s going to be your gate in the future.

What should we be telling our people as they move into this next chapter? Why should they be optimistic amid so much uncertainty?

If you’re a software engineer and you know the majority of code is going to be created by agents, you have to find your joy in different places and different ways. As a leader, you have to help people through that change curve, encourage them to choose to be part of it. I’ve asked my team to lean in and make a choice to invest in yourself.

My commitment to them is to equip them as fully as I can with the most advanced tools and cutting-edge approaches so they are equipped no matter what changes down the road. I know the shape of my org will change, I know the work is going to change, but I always say, go with me on this journey, because whatever that change is, you will be more ready and more equipped than anybody else. Make that decision and investment choice for yourself, and I’ll be right alongside you, because I care about you as an individual, and we’re working on the same purpose.

Marianne Johnson is proving that leaders courageous enough to create their own AI operating executive playbooks today are setting the stage for organizational advantage in the years to come. For more from Marianne Johnson on how she’s rewriting the leadership playbook for the AI era, tune in to the Tech Whisperers.

See also:

• How AI takes flight at GE Aerospace
• AI success requires a full-stack CIO
• What next-generation IT leadership looks like

Organizations often celebrate an AI launch at the moment the real work begins. The platform is available, the policy is published and employees have completed training. But none of those milestones tells a CIO whether work has improved, decisions are stronger or employees know when human judgment must override an AI recommendation.

This gap is visible in Kyndryl’s 2026 People Readiness Report. In a survey of 1,100 senior business and technology leaders across eight countries, 57% said AI was embedded in core processes or deployed broadly, while only 23% described their workforce as fully ready to use it successfully. Just 32% said their organizations had achieved at least one of their top two AI objectives. Technology deployment is advancing faster than the organizational capacity needed to turn it into value.

In transformation work, I have learned to be cautious when activity is presented as evidence of adoption. License activation, training attendance and prompt volume are easy to count. They do not show whether people can apply AI responsibly in a workflow or whether that workflow produces a better outcome.

Many CIOs now recognize that usage does not equal value. The next challenge is more difficult: creating an evidence chain that explains not only whether results changed, but why. That chain connects four layers – readiness, demonstrated capability, workflow behavior and business results.

Why deployment measures are insufficient

Many programs still treat workforce readiness as a downstream activity. Leaders select a platform, configure technical controls and announce availability. Training is then expected to solve every remaining problem: unclear use cases, employee anxiety, weak manager support, policy uncertainty and processes that were never redesigned.

When employees hesitate, leaders may interpret that hesitation as resistance. In my experience, it is often a rational response to ambiguity. People may not know which data they can use, whether an output must be verified, who remains accountable for a decision or how AI will affect the value of their role. A generic demonstration cannot answer questions that are specific to a job and workflow.

One practical readiness test I use is to ask people in different roles to describe the same AI-enabled workflow. Can they agree on its purpose, the information the system may use, the person who owns the outcome and the point at which a human must intervene? If not, the organization is not ready to scale. That disagreement is valuable evidence: It gives leaders a specific agenda for process design, communication, governance or learning.

Human involvement also should not be defined uniformly. A Stanford Digital Economy Lab study collected preferences from 1,500 domain workers and assessments from AI experts covering more than 844 tasks across 104 occupations. It found varied expectations for the level of human agency different tasks should retain. The practical implication is that leaders should not frame every use case as a choice between full automation and no automation. They should define the degree of human judgment each task requires.

Build an evidence chain for changed work

A useful AI adoption scorecard should answer four executive questions.

1. Readiness: Do people understand the purpose and boundaries? Readiness is more than awareness that a tool exists. Employees should be able to explain what the use case is intended to improve, which data is permitted, what outputs require validation, who owns the final decision and how to escalate a concern. Measure this with short scenario-based checks rather than confidence surveys alone. Present a realistic situation involving restricted data, an uncertain output or an exception to the normal process. Ask employees what they would do and why. A high self-reported comfort score is not a substitute for a correct decision.
2. Capability: Can people demonstrate the required judgment? Enterprise AI literacy provides a common foundation, but adoption requires role-based practice. A finance analyst, field supervisor and HR partner may share responsible-use principles, but they should not receive identical exercises or be assessed against identical criteria. Capability evidence should come from a demonstration in a realistic environment. Can the employee identify a plausible error, validate an important claim, document the basis for a decision and recognize when the case exceeds the system’s approved scope? This moves measurement from course completion to observable proficiency.
3. Behavior: Is the approved workflow being followed? Behavior measures whether the new practice has become part of the work. Platform analytics can contribute evidence, but they are not enough. CIOs also need to know whether people are completing required reviews, documenting decisions, escalating exceptions and avoiding unapproved workarounds. The target should not automatically be maximum usage. Some cases should remain human-only, and a high override or escalation rate may signal good judgment rather than poor adoption. Metrics must be interpreted in the context of the workflow and its risk.
4. Results: Did performance improve without unacceptable tradeoffs? Results should be defined before a pilot begins and compared with a credible pre-AI baseline or control group. Depending on the workflow, the relevant measures might include cycle time, first-pass quality, rework, error rates, cost, safety, risk events or stakeholder experience. Efficiency should always be paired with a quality or risk guardrail. Faster output is not progress if it creates more corrections, weakens decisions or transfers hidden work to another team.

In practice, consider an AI-assisted security-alert triage workflow. The desired outcome might be a reduction in the time required to classify high-priority alerts. The human accountability point is explicit: An analyst approves the severity classification and response action.

Readiness means analysts understand which information may enter the system and when escalation is mandatory. Capability means they can detect a plausible but incorrect severity recommendation. Behavior means eligible alerts move through the approved review path, with overrides and escalations recorded. Results mean triage time improves without increasing false negatives or delaying containment.

I recommend assigning an owner, evidence source, review cadence and decision threshold to each layer. The pilot should scale only when the desired behavior appears and the business outcome improves without breaching its quality, safety or risk guardrail. If usage rises but capability or results do not, the response should not automatically be more training. The use case, workflow, controls or management support may need to change.

This approach also makes cross-functional accountability clearer. IT enables the platform, data and controls. Business leaders define the work and desired result. Human resource and learning leaders build capability. Legal, compliance and security clarify boundaries. Managers reinforce behavior, while employees contribute the operating knowledge needed to make the workflow effective. The CIO’s orchestration role is to keep those contributions connected to the same outcome.

A 30-day test CIOs can start now

The World Economic Forum’s Future of Jobs Report 2025 found that 63% of surveyed employers viewed skills gaps as a leading barrier to business transformation. In response to expected AI disruption, 77% planned to reskill or upskill existing employees by 2030. More learning activity alone will not close the gap. Leaders must determine whether learning changes decisions, practices and results.

Over the next 30 days, ask each participating business unit to select one workflow and do six things:

1. Establish its current performance baseline.
2. Define one outcome AI is expected to improve.
3. Name the person accountable for the workflow result.
4. Identify one behavior that must change and one human decision that must remain.
5. Set a quality, safety or risk guardrail that cannot be traded for speed.
6. Review evidence from all four layers weekly and decide whether to scale, redesign or stop.

This creates a much stronger management conversation than reporting licenses, course completions or prompt counts. It shows where the evidence chain is breaking. A team may understand the rules but cannot challenge outputs. Employees may be capable but unable to use the approved tool within the actual process. The behavior may change while the business result remains flat. Each pattern calls for a different intervention.

Durable AI value will not come from the highest volume of activity. It will come from making expectations clear, giving employees realistic opportunities to practice, instrumenting how work changes and holding each use case to an explicit outcome and guardrail. A deployment turns the system on. Adoption changes how work is done. The evidence chain tells a CIO whether that change deserves to scale.

It is Q3 of the fiscal year.

The VP of sales walks into the revenue forecast meeting confident. The pipeline is strong, conversion rates are up and the sales team has been running at full velocity. The revenue intelligence motion is working.

But something is off. The VP of customer success sees it first. Accounts that converted quickly are renewing at lower expansion rates. New customers are hitting support escalations that sales didn’t predict. Churn is accelerating in segments that looked promising three months ago.

Meanwhile, marketing has just launched a campaign targeting a specific buyer persona. But Sales has no way to track whether those leads convert differently than other sources. Finance can see the cash collected, but not the relationship between engagement patterns and deal velocity. Support can see the friction, but it doesn’t flow back to sales to suppress outreach until the customer issue is resolved.

All the signals exist, but they sit in different systems and tell different stories. By the time anyone assembles the full picture, the moment to act has passed.

This is the revenue intelligence gap I’ve seen: when go-to-marketing departments operate in silos and don’t understand (or don’t communicate) trends in their data throughout an organization. This leads to misalignment and a mistaken sense that go-to-market efforts are working, when they may not be. And it can cost enterprises billions in missed growth, wasted motion and lost customer relationships.

At every company I’ve worked at, the revenue funnel has been our organizing principle. Marketing at the top, sales in the middle and customer success at the handoff. It worked because it was linear and sequential, with clear accountability. It was a useful model for an era when work moved slowly and decisions happened in meetings.

But AI has fundamentally changed the game.

Today’s revenue organizations can no longer think in funnels. They must think like learning loops. As I explored in Operate like a Formula 1 team: The new AI operating model, the enterprises that win are those that redesign how work senses, decides, acts and learns, not those that simply add more tools.

The enterprises that recognize this and apply that framework specifically to revenue will create compounding advantages their competitors cannot catch.

Those still running on funnel logic risk handing their competitive future to organizations that understand the new model.

The automation plateau: Why faster isn’t smarter

Most enterprises spent the last decade automating revenue work.

CRM systems track accounts. Marketing platforms manage campaigns. Sales engagement tools automate outreach sequences. Analytics tools report on pipeline. Each delivered value, but also created fragmentation.

The problem is that each organization has different vantage points. Marketing sees different leads than sales. Sales sees different opportunities than customer success. Customer Success sees churn risk that sales never anticipated. Finance sees payment patterns that hint at account distress. Every system holds a piece of the truth. No system holds all of it.

The result is a revenue organization with lots of data but little context.

An account manager spends two hours assembling information from seven different systems to answer a single question: “Is this account at risk?” That account is at risk. But the account manager is either too slow or doesn’t have all the information.

Automation can solve the speed problem, but doesn’t fix the underlying disconnected workflow. Most employees are automating tasks, but few have integrated workflows. It may just accelerate an incomplete or incorrect answer.

The gap is architectural. And it exposes a fundamental truth: You must build a revenue system that learns and improves with every customer interaction, not just automating more activities.

The 5 motions of an AI-native revenue operating model

Transforming from fragmented automation to unified intelligence requires redesigning how revenue work operates across five interdependent motions. The same framework applies to the enterprise as a whole, but is now applied specifically to revenue generation.

1. Sensing is the foundation. That means connecting the right signals across customer data, product usage, engagement patterns, support interactions and market intelligence into a coherent view. This could be a new Chief AI Officer announcement at a target account, a delayed renewal conversation, a support escalation or a product launch at a prospect. These signals exist throughout the enterprise, but most fail to connect them to something actionable.

2. Reasoning is where connected signals become actionable intelligence. This is semantic reasoning: understanding what a signal actually means for this account in this specific moment. A prospect’s VP who consistently engages with business value messaging but ignores technical content tells the system something important about how to approach that buyer. A support escalation that preceded a sales conversation signals account risk. Prior objections that resurface become early warning signals. Timing becomes clarity.

3. Execution turns intelligence into coordinated action. Based on what we know, did we initiate the right workflow? The next-best action surfaces to the seller with context embedded so the next communication has the right information. An account is routed to the right team. Critically, a customer with an open support escalation does not receive sales outreach while they are frustrated. Execution integrates into tools teams already use, but transforms how the work itself is structured to produce smarter, more contextual and more effective actions.

4. Governance is the layer I’ve seen too many organizations underinvest in until something breaks. Revenue AI must operate within clearly defined guardrails. Who can be contacted? What data can be used? When does a human need to approve? These checkpoints are the foundation of organizational trust that allows AI to operate in high-stakes customer workflows at scale. Organizations that build governance from the start create speed with control. Those that skip it create scale with risk.

5. Learning is the most important motion, and the one that separates an AI-native revenue system from sophisticated automation. Every interaction should improve the system. Which signals correlated with booked meetings? Which sequences are converted by segment? Which objections surfaced most often? Which customer moments generated the highest-quality pipeline? The system identifies patterns and continuously refines audience, messaging, trigger logic and policy design based on outcomes rather than assumptions.

From systems of record to systems of customer memory

The CRM was built as a system of record. It captures what happened: the opportunity is at stage three, and the last activity was two weeks ago. Then we layered hundreds of additional tools on top of it to try to make that record useful.

But a system of record is not the same as a system of memory.

A customer record knows that a contact opened an email. A customer memory understands the context, synthesizing all the information we have about the customer. Did the company announce a strategic initiative the week before? Did the VP of engineering ask specifically about certain product capabilities? Are we highlighting a pricing plan that they objected to in a meeting 6 months ago?

This is the power of semantic intelligence. It enables AI to understand enterprise meaning, not just retrieve data. This is what I described as moving toward the intent-driven future of work, where enterprise systems understand not just what is happening, but why it matters and who needs to act.

Customer memory is a strategic differentiator. It includes account history, contact preferences, relationship strength, prior objections, engagement patterns, buying committee changes, executive signals, product interests, support history and the accumulated context of every interaction the enterprise has had with that account.

Without semantic intelligence, AI can summarize what happened. With it, AI understands what matters, why it matters, who needs to act and what action is most likely to improve the outcome. Everything that happens with a customer or prospect needs to be part of a living customer memory that deepens with every interaction and improves every recommendation that follows.

The organizations building this capability now — investing in the data architecture and semantic layer required to support genuine customer memory are making an investment that compounds. Every interaction makes the next recommendation smarter. Every outcome refines the next signal interpretation. The gap between them and organizations still treating CRM as a data entry system will widen with every quarter.

What it takes to win

The enterprises that recognize this moment, and build unified data architecture, semantic intelligence, proper governance and feedback, will optimize their AI investments and actually realize productivity gains.

The funnel had a good run. But now revenue needs to be a learning loop.

And the CIOs who architect that loop will be the ones who define the next decade of competitive advantage in enterprise revenue.

AI is already changing how software is built. Google Cloud’s DORA research, based on nearly 5,000 technology professionals, found that 90% now use AI at work, spending a median of two hours a day with it, which translates to roughly a quarter of the working day.

In many organizations, the focus is on what happens at the end of the lifecycle: how much code is generated, how many steps are automated, how quickly code is shipped. While those are visible signals of progress, they can be divorced from actual value. Google’s DORA research found that while AI adoption lifts delivery throughput, it also increases instability: more software shipped less predictably.

The more impactful change is happening earlier in the lifecycle. Requirements, design and test strategy shape everything that follows. When those stages are structured correctly, downstream execution becomes faster, more consistent and easier to control. When they are not, issues tend to carry through the entire system, regardless of how much automation is applied later.

The Standish Group’s CHAOS research has consistently put insufficient user involvement and incomplete and changing requirements at the top of the list of reasons projects fail, with only around 31% delivered on time, within the budget and matching the intended scope.

Generalist models are good at producing plausible early-stage work, but can fall flat when outcomes are measured holistically. Setting off in the wrong direction can have lasting consequences. It carries through design, into code, into test cases written against the same flawed assumption.

This is why building AI into software engineering is less about adding tools to existing workflows and more a wholescale reconsideration of the product development lifecycle.

Building narrow agents into the lifecycle

The most effective approach is to break the product development lifecycle into modular agents with narrow scope: one converts discovery material into structured requirements, another produces technical design, the other generates and runs test strategies. Narrow scope keeps each agent’s context manageable and its output consistent.

Importantly, this creates clear points of control. At each stage, AI proposes and progresses the work, while human roles review, challenge and approve before it moves forward. As a result, features can move from discovery to production-ready code far faster than before: design cycles compress, and test scripting that took four engineers can be handled by one, freeing up time for higher value work.

Those checkpoints matter because plausible output is the hardest kind to catch. Stack Overflow’s 2025 survey found 66% of developers name “AI solutions that are almost right, but not quite” as their single biggest frustration, and 45% say “debugging AI-generated code is more time-consuming.”

Without a review gate at each stage, that cost compounds rather than surfacing. GitClear’s  AI Code Quality research shows the trade-off more clearly: refactoring line moves are down 70%, and long-term legacy maintenance is down 74% versus 2022 levels, yet copy-paste, code block duplication and other indicators of technical debt continue to rise.

Governance calibrated to risk

None of this is safe without governance designed in from the first step and calibrated to risk. In practice, that means deploying agents in read-only mode before they are given authority to act. It means setting confidence thresholds before any routing decision is automated. This requires human sign-off on novel exception types even after an agent has proven reliable, and keeping a full audit trail across every decision point.

Much of the market is not there yet. The Cambridge Centre for Alternative Finance’s 2026 Global AI in Finance Services report found 78% of regulators rate explainability as critical or important to their objectives, while only around half of industry firms have adopted explainable AI methods. That gap illustrates how governance expectations continue to outpace implementation.

This discipline runs in two directions. We hold ourselves to it internally, in how we engineer, because anything we build for a regulated market has to survive that scrutiny first. It also must hold in the client’s environment: the firms we build for answer to regulators for every automated decision, so governance cannot be bolted on at the end – it needs be present at every step.

Clients in regulated markets need determinism and explainability. A system that runs end-to-end without a traceable, governed path is hard to put into production, however well it performs in a demo.

Measure the outcome, not the output

Counting volume is easy: more agents, more generated code, more automated steps feel like demonstrable progress. The metrics that matter include quality, real-world outcomes and cost to build.

One example: building connectors between Xceptor and third-party platforms through a conventional engineering process could take around two weeks. Running the same build through the AI-native product development lifecycle – agents generating requirements, design documentation, code and test strategies, with engineers reviewing and steering at each stage rather than producing from scratch – took two days. For clients, that difference means integrations stop being a bottleneck on go-live. Total cost to build also fell 83 per cent, including AI token spend.

Another example is the first agent we built for financial institutions, focused on extracting data from trade confirmations. Firms are often managing large volumes of confirmations which arrive in unstructured formats across document types, such as emails, PDFs and SWIFT messages – and extracting this data is where AI agents excel, delivering significant efficiency and accuracy gains.

From doing to directing

Building an AI-native product development lifecycle changes what engineering work looks like. As agents absorb repeatable execution, the human work concentrates on judgement: architecture, edge cases and steering output rather than generating it.

We found that after a short time, our engineers were no longer producing first drafts; they were reviewing and refining agent output. Sometimes they corrected the outputs, but more and more they were able to approve what was generated. The cognitive load moved from production to verification. This shift from making to directing and validating is the clearest sign of a maturing AI-native engineering model.

Eventually, we will think less as fixed teams and more as cells – product roles and builder roles working alongside AI, each person operating above the task they used to own. The role of a QA Engineer will shift towards creating the paved roads and guardrails that humans and agents use, enabling quality to be built in consistently across every cell.

It would be dishonest to frame this only as acceleration. When work you have done for years becomes something you direct rather than do, that is a real adjustment, and leaders who pretend otherwise may lose their best people to organizations that manage the transition better. Mandating tools is not the same as helping people use them well; in our experience it produces more licenses installed, not more work changed. Adoption comes from champions, role-specific playbooks and measuring delivery outcomes: a people-first approach rather than a procurement one.

None of this works without both sides. True AI-native product development depends on continual, close collaboration between humans and machines. Years of domain knowledge, paired with the speed and pattern-recognition of these systems, is what makes the outcomes better, not the technology on its own. That combination is what makes the process repeatable at scale.

For the past few years, enterprise AI programs have focused on making models more useful, accurate, and autonomous. In that phase, a bad answer was still usually something a human could accept or reject before taking action. But once agents start invoking tools and acting inside business workflows, success should no longer be measured only by how much work they complete. A more important metric is how well an agent recognizes when it lacks the authority, context, or judgment to continue.

When helpful becomes risky

According to Allan Dabre, technology compliance and AI lead at PwC, a behavior that has to be deliberately designed into the system is, “I don’t know.” AI is built to be helpful, so an agent will generally try to do something useful unless it’s been configured not to.

“The fact that AI systems can hallucinate illustrates that tendency,” Dabre says. “When they lack enough information, they may still produce an answer. In an agentic workflow, that impulse can become more dangerous because the output may become an action, rather than remain a suggestion.”

He adds that many enterprises still test AI primarily for completeness and accuracy. That made sense when the central question was if the model could produce a reliable response. But as models improve and agents gain more operational authority, he argues that CIOs need to prioritize something else: restraint.

“Can it stop at the exact moment you want it to stop?” he asks. “Are you testing for that?”

Confidence is not authority

Dabre makes a simple but important distinction. An AI agent may be 99% confident a record should be updated, a refund should be approved, or a legacy database can be decommissioned. But that doesn’t mean the agent has the authority to act. Confidence is about the probability the system believes it’s right. Authority is about whether the organization has delegated that action to the system in the first place.

He gives the example of an agent asked to analyze legacy software and recommend what can be decommissioned. The agent may conclude, with high confidence, that several databases have little user impact and can be deleted. But even if the system is confident, most organizations wouldn’t want it to delete those databases on its own.

The same logic applies across business processes. An agent may be confident a customer record should be updated, an opportunity in a CRM system should be closed, or a transaction appears legitimate. But once that action flows into other systems, the potential consequences expand.

That’s why Dabre argues for what he calls an agent harness: a controls or orchestration layer outside the model that defines what the agent can and can’t do. In a refund workflow, for example, a company might let the agent approve small refunds, require human approval for larger ones, and stop the process entirely above a defined threshold. The agent may gather the relevant context, explain the request, and prepare the case for review, but the decision is governed by the authority boundary encoded into the system.

“It’s not a policy document and it’s not a prompt,” Dabre says. “It’s software or a configuration you can apply to an agent.”

The case for least agency

Matt Graney, chief product officer at Celigo, a business automation and integration platform provider, approaches the same problem through a principle he calls least agency. The idea is to give an agent the least amount of autonomy required to complete a job.

According to him, there’s a temptation to throw AI at broad, nebulous problems. But many business processes are still largely deterministic. They follow established rules and perform repeatable work. Within those workflows, AI may be useful at the point where rigid rules give way to interpretation. But that doesn’t mean the agent should own the entire workflow. “The smaller you make that surface area, the better,” he says.

Graney says the same logic applies to tools. An agent with too many tools can become confused, especially as context windows grow and the task becomes more complex. “Because Celigo is an integration platform,” Graney says, “the company’s approach is to expose agents to fewer, more powerful tools that reach enterprise systems through governed connections.”

That’s another form of restraint. Instead of letting an agent reach into enterprise systems ad hoc, the business gives it a narrow, governed toolset designed for the task at hand.

Graney also argues that guardrails should sit outside the model. If the same agent that makes a decision is also responsible for judging whether the decision is acceptable, the control is weaker. A separate guardrail can check the agent’s inputs and outputs before a downstream action occurs.

That same design discipline applies to escalation. “I don’t know” shouldn’t be treated as a chatbot phrase. In an enterprise workflow, it’s a handoff path that should be defined before the agent reaches it.

Make escalation part of the workflow

Turning uncertainty into a handoff is where Matt Quinn, CTO at CarGurus, an automotive marketplace, sees agentic AI becoming less a pure technology challenge and more a management challenge. At CarGurus, Quinn says agents are evaluated according to what they know, what they can do, and what data they operate on.

CarGurus receives a high volume of cases from dealers, and each one needs to be classified and routed. The company now uses an agent to review incoming cases, draw on account history, and route them to the appropriate next step. Quinn says the agent handles about 70% of those cases end to end without human involvement.

But when agents move toward consequential actions, he says the consensus is having a human approval step. The agent may return with a simple prompt like, I’m about to do this. Do you want me to proceed? That simplicity matters because a handoff shouldn’t bury the reviewer in complexity.

Quinn says the human remains ultimately accountable for the work. That principle is especially important in engineering, where agents may help write code or fix bugs. Quinn adds that CarGurus still expects engineers to follow the practices they’d use for any other production change, which includes running quality checks.

The company has adopted the phrase healthy speed to describe the balance it wants. The goal is to move faster without letting quality degrade. An agent can accelerate work, but if teams abandon the practices that make work safe, the speed becomes reckless.

This is also where human judgment remains difficult to replace. Quinn describes it as high judgment people develop through experience. A human may look at an AI-generated output and sense something’s wrong, even before fully articulating why. “Agents are improving,” he says. “But humans still play a critical role in deciding when the system shouldn’t continue.”

That doesn’t mean every workflow needs the same level of review. Quinn says CarGurus doesn’t have a target percentage of work to automate. The right level depends on the job and the task. A simple bug fix may require a lighter review than a change to a sensitive backend service, and a personal summary may carry little risk. But a document sent under someone’s name still needs human review.

Make autonomy accountable

That kind of pragmatic approach may be the best lesson for CIOs, making the goal of agentic AI appropriate rather than maximum autonomy.

That also means ownership has to be clear. Dabre argues ownership should be divided before deployment. The business defines the outcome, technology builds and configures the agent, risk and compliance set the guardrails, and governance monitors whether the system still behaves as intended. The authority to pause, stop, or retire an agent should be defined before production, not negotiated during an incident.

Graney makes the same point with a simple analogy. If a company hires an untrained intern, gives that intern access to the crown jewels of a business process, and something goes wrong, the intern isn’t the real problem. The process is. The same applies to agents. Accountability belongs with the person who owns the workflow.

That may be the shift CIOs need to make as enterprises move from pilots to production. AI agents shouldn’t be treated as magical workers that absorb accountability. They’re components in business processes, and those processes need accountable owners.

As AI adoption increases, the next phase of enterprise maturity won’t be defined by agents that always answer or always complete the task. It’ll be agents that know when not to act.

Cortney Pagel has learned to expect a particular question whenever she proposes changing how work gets done. Pagel, a senior business analyst and change manager at ENGIE Impact, often hears it from the digital side of the organization before she has finished explaining the change: How much money are we looking to save here? “I don’t always have an answer,” she says. “And so that is very frustrating for me.”

The frustration comes from a familiar structural problem. Most financial systems connect money to departments, accounts, cost centers and, in more mature implementations, activities; however, they rarely connect economics to the anatomy of the work itself. Pagel describes processes that are still too manual to be tracked cleanly, while in other cases the financial detail exists but was never tied to the process model. For a period, she resorted to putting cost estimates in comment bubbles on process diagrams because there was no systematic place for them. “There’s been no great system or method to do it,” she says. “It’s definitely not just me.”

The question she keeps being asked therefore exposes a broader lacuna in management accounting. Finance can usually explain what a process consumes, and it can often estimate what a proposed change might save. Yet it is far less equipped to show which process components contribute value, which destroy it, which absorb risk and which create information or options whose economic effects may surface much later. Consequently, a transformation business case can become highly precise about one side of the equation while leaving the other largely narrative.

A ledger on the ledge of usefulness

The general ledger reports what a department or cost center consumes. Activity-based costing (ABC), where organizations have implemented it with sufficient discipline, pushes that resolution further by assigning costs to activities. Both approaches remain useful; nonetheless, their analytical center of gravity is consumption rather than contribution. They can tell management where resources were spent with increasing granularity, while offering much less visibility into what an individual activity economically produced.

Double-entry accounting, dating back 500 years to Venetian merchants, earns its reputation for symmetry, although the symmetry belongs primarily to bookkeeping. The two sides of an entry describe the same financial event, while revenue generally appears when a transaction is recognized rather than carrying a lineage back through the many process components that helped create it. A renewal, expansion, avoided loss, faster decision or improved customer relationship may depend on dozens of steps, yet the contribution of any one step rarely has an account to which it can be posted.

This creates an analytical asymmetry that can influence investment decisions more than finance leaders may realize. When a CFO or operating executive evaluates a proposed process change, the cost side often arrives quantified while the value side arrives as prose, judgment or a collection of indirect metrics. The quantified side therefore tends to carry disproportionate weight because it is already denominated in the unit in which the decision is made: money. Indeed, acknowledged uncertainty may be safer than one-sided precision, because the latter can carry the authority of a number while obscuring what the model omitted.

One process, many economic artifacts

Consider the process of customer onboarding. Operationally, it is a sequence of tasks needed to establish a customer, configure services, obtain approvals and move the relationship into a steady state. Economically, however, those same steps may establish relationship patterns that influence retention, create the account depth that enables a later cross-sell, generate behavioral and preference data whose usefulness compounds over the customer lifecycle, and reduce churn risk through investments made well before the customer has a reason to leave.

Embedded in that same process may be approval controls whose original compliance rationale has waned, manual handoffs between systems that were never integrated, duplicate checks and wait times that gradually erode the loyalty the process was intended to build. Some components may therefore create value; others may protect it and still others may quietly consume it. Yet a conventional cost model compresses this heterogeneous mesh (or mess!) of economic activity into a single process cost, which is useful but incomplete.

Improving or transforming the process requires a more discriminating account of what each component is doing economically: which steps build value, which erode it, which create unnecessary friction, which absorb risk, which generate ancillary benefits and which perform economic work that becomes visible only after the step is removed. Without that component-level view, an efficiency initiative can readily eliminate something valuable simply because its cost was easier to suss than its contribution.

LINQ.it

Putting economics on the process map

Economic process modeling (EPM) supplies that missing layer. As I described in a recent column, Business Transformation Needs a True Economic Approach Rather Than Guesswork, EPM decomposes a process into its constituent components—the information flows, human decisions, system actions and organizational touchpoints that make up the actual work—and then attributes economic effects to each across five dimensions: revenue contribution, cost and friction, risk exposure, option value and information value.

The component level matters because the economically significant finding often sits buried within the process as a whole. Two steps that look roughly equivalent on a process diagram may carry very different economic profiles once attribution is applied. A seemingly minor validation step, for example, may generate information that reduces downstream risk, while a more conspicuous approval step may be largely vestigial. A cost-only review can easily misread the two because it sees effort more readily than consequence.

Pagel describes the capability she wants in similarly practical terms: the ability to see processes at an organizational level, understand what they cost in aggregate and then break those economics down step by step. That level of resolution helps because process transformation decisions are rarely made at the level of an abstract end-to-end flow; they are made by automating, eliminating, combining, outsourcing or redesigning individual components. Consequently, finance needs an economic view at the same level where the design decision is actually being made.

The oft-ignored value of information itself

Information value is where this analytical oversight may be most acute, particularly because most processes today generate data as a byproduct of execution. For example, a credit review produces repayment-behavior signals, a claims intake creates fraud indicators, and a procurement approval accumulates supplier-performance evidence. Those outputs may have future utility well beyond the transaction or process that generated them, even though conventional cost accounting typically has no place to represent them.

Most organizations, however, still treat much of this data primarily as documentation, exhaust or a compliance burden rather than as a potentially monetizable asset. A process redesign can therefore appear efficient while externalizing, degrading or destroying information whose economic contribution was absent from the business case. Infonomics, the discipline of treating information as an economic asset with attributable value, provides the grounding for this dimension of EPM and helps expose value that can otherwise disappear during an ostensibly sensible transformation.

From cost review to capital allocation

EPM extends cost accounting by adding an economic perspective the ledger wasn’t designed for. Sure, cost remains an indispensable computation. However, the business case becomes materially more complete when the components proposed for automation or elimination are also evaluated for revenue contribution, risk absorption, optionality, information yield and the friction they create or remove.

This can change the quality of the capital-allocation discussion. A step that costs $500,000 annually certainly may be a strong automation candidate, yet the savings figure is incomplete if the same step prevents $2 million in avoidable losses, preserves a customer relationship, generates valuable information or creates an option the business may need later. Conversely, a relatively inexpensive step can still be economically destructive if it adds delay, rework or customer attrition. The point is not to manufacture spurious precision around every benefit; rather, it is to make the relevant sources of value visible, estimable and subject to the same scrutiny as cost.

Which brings us back to Pagel and the question she hears whenever she proposes a change: “How much money are we looking to save here?” Savings are only one side of the economic case. The more consequential question may be what each affected component contributes today, what value may disappear if it is changed, and what new value the redesigned process could create.

Indeed, a transformation can look compelling when the savings are visible and the value at risk remains invisible. Economic process modeling gives finance a way to juxtapose both in the analysis, so that a proposed change can be judged not merely by what the organization expects to spend less, but by what the work itself is actually worth.

I’ve always thought it was interesting that we’re willing to fight and die to live in a democracy, but everyone is happy to work in a company which is structured like a dictatorship. This thought feels even more pertinent given the rise of AI. As AI continues to transform the world of business, we’re starting to notice a clear gap between those implementing a ‘throw it at the wall and see if it sticks’ approach, and those examining the fundamental changes that need to be made to a business.

While we don’t need to get into the pros and cons of oligarchy, over the past year of leading consultation and training sessions for over 80 organizations, I’ve realized that, if you introduce AI by working from the middle out, you can actually move a lot faster.

I’ve seen organizations try to bolt AI onto their existing workflows, and while there may be initial productivity gains, this generally doesn’t work out in the long term. We often see scattered pilots which don’t go the distance, duplication of tools or inefficient processes. The organizations setting themselves up for success are redesigning how teams experiment with and implement solutions.

We can use the transition from steam to electricity as an example. Paul A. David notes that there was a 40-year lag between the electric dynamo’s introduction and its productivity impact. When factories first adopted electricity, many simply replaced their steam engines with electric motors, while leaving the rest of the factory unchanged. Productivity gains were modest. David argues that the bottleneck was organizational structure. It was only when engineers redesigned factories around small electric motors throughout the factory that we began to see the benefits. General purpose technologies, like electricity — or, in this case, AI — require co-invention and firm restructuring before we can see the benefits.

It’s time to restructure.

AI is developing fast and it’s difficult for companies to keep pace

While most companies are built with a top-down model, this is not an effective way to identify and roll out technology, particularly when it’s moving as quickly as AI is.

We’re already seeing the impact that the speed of AI development is having. Companies are struggling with things like AI sprawl and shadow AI. AI sprawl is when employees are using tools everywhere, without shared norms or strategy. Gartner estimates that by 2028, an average global Fortune 500 enterprise will have over 150,000 agents in use, up from less than 15 in 2025. This creates significant agent sprawl, IT complexity and management challenges. Take a retail company for example, if sales uses one AI chatbot, support uses another and marketing uses a third we could start to see inconsistent customer experiences, where customer-facing AI chatbots give conflicting answers about pricing or return policies.

Shadow AI is the unauthorized use of AI tools by employees without IT or security approval. Common examples include employees pasting code into ChatGPT, uploading customer data to public web apps or using unvetted browser extensions to speed up daily work. Today, over one-third (38%) of employees say they share sensitive work information with AI tools without their employers’ permission. This introduces severe risks like intellectual property leaks, data privacy violations and non-compliance.

Building the assembly line of the AI era

The companies solving these challenges are finding ways to convene subject matter and AI experts from every part of the company to create a center of excellence, steering committee or a power user group. Once assembled, this group should be empowered to experiment, vet and validate new technology for the company. This is what I’m calling the new ‘assembly line’ of the AI era.

This assembly line is a dedicated team with the power to implement new solutions. They can vet any tools being used and compare them to systems already in place. They can then make decisions on whether the identified tools should be rolled out across the company, and the training and processes that need to be in place to make this rollout a success.

Some of the companies I’m working with are already putting this into practice. One water pumping company in Minnesota wanted to figure out how AI could be used to educate, train and inform employees, as well as preventing AI sprawl or shadow AI usage. Together we have mapped out who should be part of their center of excellence, who owns what and how to set up approvals. With the model we’re creating, we are establishing AI as a force for empowerment, education, training, tooling and most importantly change management.

On the flipside, I’m also working with a healthcare company that has an existing center of excellence trying to oversee ALL AI projects at the business unit level. This recreates a hierarchical problem that slows adoption, since it doesn’t empower individual units to move on their own. It makes sense, given HIPAA compliance means healthcare companies have to be cautious, but the focus of a Centre of excellence should be enabling teams through approved AI tools, not taking complete ownership of every project themselves.

By giving these teams authority to make AI specific decisions, you prevent the bottleneck which usually happens at the executive level either due to busy schedules or a less in-depth technical understanding. The center of excellence can redirect sprawl, combat shadow AI usage and escalate things when necessary.

Turning individual experiments into company decisions

A center of excellence gives AI adoption a working rhythm instead of leaving it to Slack threads, scattered pilots or executive guesswork. Each team should have someone close enough to the work to spot where AI is useful and where it’s a distraction. A finance lead might see value in automating invoice checks. A legal lead might reject a tool because it mishandles client data. A customer service manager might test whether an AI assistant actually improves response quality or just produces faster, worse answers.

That group can then turn individual experiments into company decisions. They can test tools, compare them against existing systems, check the security risks and decide what needs training before anything is rolled out. They can also stop bad habits early, like teams uploading sensitive documents into public tools because nobody gave them a safer option.

If companies want AI to work, they need to completely overhaul their processes. The companies that move fastest will be the ones that give people in the middle the authority to test, challenge, approve and teach. That’s where the real work happens: close enough to daily operations to know what’s useful, and connected enough to turn that knowledge into practice across the business.

CIOs are increasingly expected to drive IT adoption in their organizations, with change management becoming a huge — and more challenging — imperative in the age of AI.

Evangelism of the latest technologies has long been part of the job, but many CIOs now say resistance to AI adoption and the fast-paced evolution of IT tools have raised the stakes.

Change fatigue has become a major challenge as Andrea Ballinger, CIO of Rensselaer Polytechnic Institute, tries to update the IT systems and provide a tech-driven ultra-personalized student experience at the university, she says.

“It’s not even inside of our institutions or our private companies, but the world is throwing so much at us,” she adds. “What you heard today, you’re being told something else tomorrow.”

For CIOs, change management means recognizing that some employees are on a slower journey and, at the same time, encouraging staff to embrace progress, Ballinger says. Good leaders will recognize that some employees will resist, but it’s their responsibility to help employees navigate the changes, she adds.

“Change management is understanding where people are at,” she says. “It’s having that sense of urgency, but a sense of urgency does not mean running without a parachute or without a plan. It means you act today.”

Change management was a big topic of conversation at the CIO 100 Awards and Conference in Frisco, Texas, in mid-August. Several speakers mentioned the challenge, with Ravi Malick, global CIO at cloud-based content sharing service Box, saying change management now represents about 80% of the job, far outpacing pure IT issues.

The change management aspects of a major digital transformation are often what makes or breaks the effort, he says.

AI in particular has forced CIOs to pay more attention to change management because it fundamentally changes the way employees work, he adds. Some past technologies, like the internet and mobile computing, largely started in the consumer space, then leaked over into the enterprise, giving employees time to get comfortable, he notes.

“AI is something that’s reshaping both the consumer space and the enterprise at the same time,” Malick says. “Both the enterprise and individual people are trying to figure out how to get the most value out of it.”

Some revolution, some evolution

As a company, Box is moving forward quickly on some AI initiatives while taking a wait-and-see approach on others, in part to manage the changes required, notes Malick, who sees adoption of AI and other new technologies as a major challenge.

“There are parts of this that are revolutionary, and there are parts that need to be evolutionary,” he explains. “The best way to get somebody pointed in a different direction is to make them realize they haven’t done an 180-degree turn. Get them to realize, ‘I turned on my own, and I actually like the direction that I’m pointed in.’”

To encourage adoption, Box has pitched AI to employees as an enabler and amplifier, not as a technology that will replace their jobs, Malick says.

“We’re asking, What are the things that we can do now that we weren’t able to do before?” he says. “How can we apply your years of the experience and intellectual power toward other areas that we just couldn’t get to before?”

Box isn’t closely tracking how employees are using the time saved through AI tools, he adds. If employees are using the extra time to improve their quality of life, that’s ok, he says.

“Maybe they’re not working on the weekends at the end of the month closing the books,” he says. “Maybe they actually have weekends now and can spend more time with their families.”

Change across the organization

Other CIOs say the change management piece of the job has increased significantly in the past two to three years.

In recent years, CIOs have been pulled into change management roles within other parts of the business as teams identify AI opportunities, says Orla Daly, CIO at skills management company Skillsoft.

“As AI blurs the lines between technology, operations, and people strategy, the CIO role is becoming closer to that of a COO,” she adds. “Workforce strategy is folding in alongside technology strategy, so leading change now sits at the center of the role rather than being one piece of it.”

The rapidly changing technology landscape has also thrust change management to the forefront of the CIO role, she says. “The pace at which decisions need to be made has increased so dramatically that you can’t lead at a distance and expect strategy to translate cleanly into action,” Daly says.

Daly also notes that slow adopters aren’t always active resisters. Skillsoft’s 2026 Workforce Readiness Report found that while 86% of employees use AI tools at work only 24% feel fully equipped to use them effectively, and just 16% receive training before a new tool is introduced.

“That gap suggests an over rotation on tooling without understanding how it changes how work is executed,” she says. “In most cases, it’s uncertainty and a lack of confidence to take the first step, not a lack of interest.”

Daly and other CIOs suggest that mandating the use of a new tool is rarely the right approach.

“Requiring it can create activity, but activity isn’t the same as adoption,” she explains. “If you hand people tools without clear use cases, guardrails, and training, a mandate just accelerates inconsistent use, and you mistake activity for progress.”

NTT DATA focuses on employee AI fluency instead of mandated activity, and the CIO has a huge role to play, says Barry Shurkey, CIO at the company. The CIO role increasingly sits at the intersection of technology, business strategy, and people, he says.

“AI success is not just about moving quickly; it is about helping people understand the change, embrace it, and move forward with confidence,” he adds.

NTT DATA’s own research suggests that AI front-runners use AI to amplify the impact of experienced, highly skilled employees rather than to replace them, Shurkey says.

“As AI accelerates transformation, CIOs are doing more than implementing technology,” he adds. “They are redefining how people work, make decisions, create value, and just as importantly, managing the intensified resistance that’s driven by fear of job loss or control.”

What changes when AI becomes part of how the business runs

The more I speak with CIOs and technology leaders, the more I realize most of us are working through variations of the same AI challenge.

How quickly should we move? Which opportunities are worth pursuing? What risks are acceptable? And how do we move from an impressive demonstration to something the business can reliably use?

Enterprise AI began with possibility and experimentation. Now the conversation is changing.

The harder question is not whether AI can perform a task. It is what changes once the business begins depending on it. At that point, the conversation expands beyond technical capability. Value, capacity, security, ownership, change management and operational resilience all become part of the equation.

The demo is not the operating environment

A strong AI demonstration can be compelling. The data is clean, the use case defined and the operator knows the technology. The result can look effortless.

Real environments rarely behave that way.

I have seen intelligent automation use cases appear straightforward until actual business data and processes were introduced. Documents varied, requirements evolved and manual workflows contained accumulated exceptions. What looked like one process turned out to be several versions held together by human judgment.

The technology may be capable, but it does not resolve unclear requirements, inconsistent inputs or a process that was never standardized.

I prefer to test with real enterprise data as early as practical. Vendor demonstrations naturally emphasize the happy path. Your own data exposes the conditions the solution will actually have to survive.

Watching an expert operate a platform is different from asking employees to use it every day. Users have to understand the capability, trust the result and know what to do when the output is wrong or incomplete.

Change management cannot be treated as the last step. It affects the timeline, effort and whether the expected value shows up.

McKinsey’s State of AI research continues to show broad adoption while enterprise-wide scaling remains much less common. That gap is understandable. The distance between an interesting use case and a production capability is where data, process design, testing, security, integration and adoption all become real.

Value has to compete with capacity

Once a use case survives the technical question, the discussion has to become more pragmatic.

What is the value?

Within an enterprise, that should translate into something leadership can evaluate: cost reduction, increased throughput, greater efficiency, less manual work, more time redirected toward higher-value activities, better customer outcomes, revenue opportunity or the ability to absorb growth without adding proportional headcount.

Not every AI initiative needs an immediate hard-dollar return. But leadership should know the intended outcome and how it will determine whether further investment is justified.

AI does not create unlimited organizational capacity. Technology teams still have roadmaps and operational priorities to deliver. Business subject matter experts still have day jobs. Someone has to define requirements, provide data, validate the process, test the outcome and help employees adopt a different way of working. And when the organization chooses to build rather than buy, additional work may be required to prepare data, evaluate model performance and, where appropriate, fine-tune models for the specific use case.

That is why being able to build a use case does not automatically make it the right priority. The value, effort, timing and business readiness still have to justify the investment.

Sometimes the smaller opportunity is better because it produces value sooner and builds reusable experience.

The same discipline should apply to whether the organization builds internally or brings in external expertise.

AI is evolving too quickly for most internal teams to master every emerging capability while operating the rest of the enterprise. A proven external partner can sometimes add expertise, speed or capacity.

The test is whether that partner accelerates internal capability or creates an unsustainable dependency.

Board expectations are also increasing, and rightfully so.

AI now touches competitive positioning, investment priorities, workforce decisions and enterprise risk. Boards should ask where value is emerging and whether the organization is moving with enough urgency.

BCG research on CEO and board perspectives has highlighted a useful tension: in some organizations, boards are pushing for greater urgency around AI, while management teams may take a more measured view of what can realistically be delivered and sustained.

The better question is not simply how fast the organization is moving. It is how fast it can move while still producing something it can support, protect and sustain.

That is where risk stops being only an IT discussion.

Before an AI capability moves deeper into the environment, CIOs need to understand what it touches. What data can it access? Does information leave the enterprise? What permissions does it require? Could it introduce a new attack path? What happens when the capability begins taking actions across systems instead of simply producing an answer?

The control model should reflect the consequence.

An AI tool used for everyday productivity does not require the same oversight as one that can modify records, interact with customers or access sensitive enterprise data. The NIST AI Risk Management Framework provides a useful structure for thinking about risk in context rather than applying the same controls everywhere.

For CIOs, that is the balance: we are still responsible for protecting the enterprise, but protection cannot become an excuse to make every new capability unnecessarily difficult to adopt.

Guardrails should be strong enough to protect the business and flexible enough to evolve with the technology.

Sometimes that requires more common sense than textbook governance.

The stakes change when AI moves beyond the office

For many organizations, AI adoption starts with office productivity: summarization, knowledge search, coding assistance, meeting support and other relatively contained uses.

Eventually, the question changes.

When can AI move deeper into operations?

That can include intelligent document processing, computer vision, IoT and sensor-driven capabilities, drones or other technologies that begin influencing operational decisions and physical processes.

Some companies will move there gradually. Others may move sooner when the capability sits inside an established vendor-managed solution with defined controls, support and accountability.

If an AI tool used for everyday productivity produces a poor response, an employee can usually identify and correct it. If an AI-enabled capability begins influencing an operational process, reliability, cybersecurity, fallback procedures and ownership become much more important.

That progression from experimentation to deeper enterprise dependence is not new. We have seen it in other technology cycles.

Cloud, SaaS and mobile all moved through periods of enthusiasm, rapid adoption and eventual normalization.

AI will likely follow parts of the same pattern, but the cycle is moving faster.

It did not enter primarily through the traditional IT corridor. Employees, business teams, vendors and executives gained access almost simultaneously. The technology continues advancing while organizations are still deciding how it should be used and controlled.

Much like smartphones and the internet became embedded into daily life, AI is already becoming part of the applications people use every day. Capabilities are being built into enterprise platforms, whether users think of them as AI or not. The next shift is deeper dependence as AI becomes part of workflows, decisions and operating processes.

The difference is that AI can operate at a higher altitude. It can influence decisions, interact with enterprise data and increasingly take actions across systems, which raises the consequence when something goes wrong.

That should change the questions boards and CEOs ask. The conversation should move beyond “What are we doing with AI?” to questions that expose whether the enterprise is actually ready to depend on it:

• How do we move faster without putting the business at unnecessary risk?
• What are we asking AI to compensate for that we should be fixing ourselves?
• Where are process ambiguity, system fragmentation or operating habits creating unnecessary friction?

AI can automate around a weak process for a while, but eventually the exceptions catch up with it. It can work around inconsistent information only so long before confidence in the output becomes the problem.

CIOs will need to hold firm on responsibilities that do not change while staying flexible in how those responsibilities are carried out.

We also have to be realistic about what our organizations can absorb. Trying to boil the ocean can create more activity than value. There is nothing wrong with narrowing the focus, proving an outcome and using specialized expertise when internal capacity or experience is not there yet.

The first phase of AI rewarded experimentation and curiosity.

The next will reward judgment.

The organizations that navigate it well will not necessarily be the ones with the most pilots, the largest budgets or the boldest promises. They will be the ones that know where to move quickly, where to hold the line, what needs to be fixed internally and when an idea has earned the right to scale.

That is when AI stops being another technology experiment and starts becoming part of how the enterprise actually runs.