Lead times of nine to 12 or even 18 months. Costs rising by 35%, 45%, even 50% to 200%. More than halfway through 2026, the market for IT infrastructure that’s crucial for enterprise projects, including those involving artificial intelligence, is strapped.

Memory is at the root of the shortages. Memory prices “have risen by 50% to 200%, resulting in PC prices increasing by 35% to 45% and some server prices rising over 125%,” according to Jon Forest, VP analyst at Gartner. Network switches also need memory, albeit in lesser amounts than servers, so they are not immune, with prices and lead times likewise rising dramatically.

Industry experts agree that most of the issues stem from hyperscalers gobbling up memory capacity, which trickles down to servers, storage systems, and networking devices. But while the source of the problem may be new, supply chain disruptions are far from unprecedented.

As a result, industry insiders are not short on advice on how best to deal with the situation, with tips including making better use of what you have, considering options beyond your usual scope, and lots of planning with your vendors and internal finance teams.

State of the problem

Just how bad is the current supply chain problem? “It’s pretty bad,” says Matt Kimball, vice president and principal analyst with Moor Insights & Strategy. Companies accustomed to 30- to 45-day lead times for various infrastructure are now looking at 6, 12, or even 18 months.

“It’s real, and I’m hearing it from companies of all sizes, from the 1000-server to the 10,000-server shops,” Kimball says.

“Memory costs are expected to rise sharply well into 2027 and will reach up to 25% of network hardware expenses by the end of 2027,” according to an email Gartner’s Forest sent to Network World. The figure below shows the timeline Gartner expects for memory prices, and Forest notes that the same timing applies across networking, storage, and compute infrastructure. 

“Enterprise network equipment pricing is projected to increase by over 20% in 2026. This upward trend is anticipated to continue with a further rise of 3% to 5% entering 2027, with no signs of price reduction until the end of 2027.”

But “reduction” will likely look more like “stabilization.”

“That’s something a lot of people don’t like to talk about. But let’s say prices went up 40%, they may come down five,” says Phillip Privett, senior vice president of vendor management with the global distributor and value-added reseller TD SYNNEX. “They’re not going to come down 40%.”

Perhaps worse, compared with past disruptions caused by issues such as fires in chip fabrication factories or the Covid pandemic, Kimball says this one is “durable” because its cause—the AI wave—is more long-lasting and just getting started.

“This AI inference wave we’re hitting is just beginning. It’s going to be longer and bigger than the training wave,” he says. “It’s impacting everything, from AI infrastructure to the traditional stuff that’s standing up your virtualization and cloud infrastructure.”

No vendors seem to be immune, not even the likes of Cisco, which makes its own Cisco Silicon One chips. Or, at least, it designs the chips; they’re actually manufactured by the Taiwan Semiconductor Manufacturing Company (TSMC), the same company that makes many of the other chips that are in such demand. And that’s only one component of many that comprise a switch.

On the other hand, the margins Cisco gets from enterprise sales are far greater than those from hyperscalers because Cisco sells mainly just hardware to hyperscalers, whereas enterprise sales generally include software and services as well. So, Cisco has incentive to keep enterprise customers happy and maintain the 66% margins it reported in Q3, its latest quarter.

Still, Cisco must deal with the same shortages as other vendors.

“I wouldn’t say any company is faring better than others,” says Neil Anderson, vice president and CTO for cloud, infrastructure, and AI solutions at World Wide Technology (WWT). “There may be nuances that some suppliers are employing to balance it to some extent, but I fail to recognize a supplier that’s not having almost the same issue.”

Cloud storage vendor Backblaze is one company that’s facing equipment cost and availability issues. “There are different types of shortages occurring in multiple places, all driven by unusual market demands, really by just a handful of very large buyers,” says James Rowell, senior vice president of operations with Backblaze.

Backblaze is constantly forecasting and monitoring demand triggers, Rowell says. That involves close alignment with the sales team to forecast client needs, as well as paying attention to historical trendlines to predict upcoming demand from new deals and growth with existing clients. But the company also looks for “unnatural market-related triggers” that would cause a spike in utilization.

With hyperscalers buying up vast amounts of capacity, “This is definitely an unnatural phase,” Rowell says. “For about for the last 12 months, I would say there’s been somewhere between a 15% and 30% uptick in costs,” especially in terms of servers and compute disks.

On the positive side, at least for Backblaze, the company is also seeing an uptick in business from an interesting source: AI companies. “We reported in the last earnings period a 70% increase in AI companies using our platform,” says Patrick Thomas, vice president of marketing at Backblaze. “That’s massive.”

On top of that, the company is seeing an uptick in deals from enterprises that can’t get the storage capacity they need or want on-prem. “There’s a general market nervousness where we’ve got potential deals coming our way because those organizations are concerned about being able to do it themselves,” Rowell says.

While some expect new chip fabrication plants currently under construction will ease memory supply constraints, Privett doesn’t buy it. “I don’t see it getting better anytime soon,” he says. “Building a new fab is a two-year process.”

Advice: Start with the basics

Enterprises, then, must play the cards they’re dealt. For Moore Insights’ Kimball, who did stints as an IT exec with the states of Florida and Oregon, that starts with making the most of what you have.

Such a strategy is “shockingly not implemented much” across the companies he sees. “A simple capacity planning exercise can free up a lot of resources.” That includes virtualized servers running at just 20% to 30% utilization as well as extending the life of existing servers. While 15 or 20 years ago it was common to refresh every four years or so, companies can often get six or seven years out of today’s servers.

While such strategies won’t solve your AI compute challenges, they can certainly help support your ongoing operations and free up budget for AI and other modernization projects, he says.

“Sweat your assets,” agrees Privett of TD SYNNEX. “Work them as much as you can, add only what you need, get extensions on your licensing, renewals on your services agreements and things like that. Just sweat it out a little longer.”

If you have budget to spend but can’t get the hardware you’re after, buy something else, says WWT’s Anderson. “Look at things that are not tied to those components, like software projects or SaaS licensing,” he says.

Get friendly with finance teams

Numerous experts recommend regular meetings with your CFO or finance teams to keep them apprised of what you’re up against so the company can plan accordingly.

Gartner’s Forest advises using rolling 12- to 24‑month forecasts and engaging early with suppliers to identify constrained components and SKUs. Committing to quarterly or monthly buys can help you avoid long-term agreements that extend past the rapid increases we’re seeing in 2026, he says.

Also engage with the financing arm of your equipment vendors, some of which are offering financing incentives, Privett says. Compute vendors in particular are offering subsidized financing, deferred payments, and low-cost financing for the first year or so. “Those are huge opportunities to take advantage of,” he says.

By engaging with finance teams, IT groups can conduct budget allocation exercises and try to come up with ways to make the financials work. The last thing you want to do is surprise them with additional budget requests out of the blue.

Kimball recalls his days with the state of Florida, when all budget requests were examined by a technical review working group—which was designed to be hostile.

“I can’t imagine going to them and saying, ‘Oh, did I say that was a million dollars? It’s actually $2 million. I need you to write me a bigger check,’” he says. “I would walk into one of the swamps in Tallahassee and get eaten by the alligators instead of doing that.”

Work with your vendors and VARs

As you put plans together, lean on your vendors for help, including channel partners such as value-added resellers (VAR) and national resellers. “Work with them to map things out and understand what your workloads will look like,” Kimball says.

That’s what Backblaze’s Rowell regularly does with his suppliers. He lays out his forecast for the year, with commitments on what Backblaze will definitely buy, as well as scenarios that account for rapid growth, say, 2x. “And they’ll come back with, ‘Well, okay, no problem,’ or maybe they say we need to put in an allocation right away, or we won’t be able to get what we may need,” he says.

Similarly, he sits down with his CFO regularly to map out predictive models that factor in inflation, price hikes, and the like. The idea is to plan out multiple scenarios, so you don’t get blindsided.

“If you don’t do that, you’ll get caught with your pants down, on the upside-down end of spectrum,” he said – meaning not having the capacity to take advantage of market opportunities.

Acquiring the capacity you need to meet project demand may also mean being flexible in terms of your equipment choices. If you’re a Dell shop but can’t get Dell servers, maybe you go with Lenovo, Kimball says.

“You’ve got to figure out how to use all this silicon and infrastructure in a heterogenous way to serve your needs,” he says. That’s especially true when it comes to AI infrastructure. “If you think you’re going to go with 100% Nvidia for everything from RAG [retrieval augmented generation] to inferencing at the edge, you’re kind of crazy, not because of cost but because of availability.”

Look at alternatives, including AMD and cloud solutions, while staying mindful of how it all plays together. You may not be able to get Nvidia GPUs, but AWS, Azure, and Oracle Cloud have them, Kimball notes.

Be strategic, perhaps by using cloud offerings to handle certain tuning or inference workloads, then bringing them back in-house when appropriate. “Have a better understanding of what absolutely has to be on prem and what can be in the cloud,” he says.

That’s good advice, says Backblaze’s Thomas. When it comes to AI, think about performance tiers and the range of use cases you have. They don’t all need top-tier performance.

“People get wrapped around axle of needing the top end. There’s a lot of flexibility in the edges, innovation in different hardware and software,” Thomas says.

Gartner likewise advises companies to increase configuration flexibility and expand sourcing paths. That may include buying from secondary markets and lease-return programs to preserve continuity with existing infrastructure until the shortages pass, Forest says.

Get started somewhere

Even if you can’t acquire or have to wait for the infrastructure you need, don’t let that keep you from getting started with AI or other modernization projects.

Options include public cloud and neocloud providers, Anderson says. WWT also provides capacity in its own lab so customers can get started with proof-of-concept projects. “Don’t just throw your hands up. We can help you find access to capacity,” Anderson says. “Production-scale AI may be delayed, but don’t let that derail your strategy.”

Colocation providers may likewise be an option, especially if enterprises are struggling to acquire high-end networking equipment. Networking is a key value proposition for colocation providers, in that they have built-in connections to various cloud providers and other ecosystem players.

Equinix, for example, has 280 data centers in 77 metropolitan areas, says Phil Read, senior director, colocation product management for the company. If you have the compute infrastructure, Equinix can help you with the high-end connectivity required both intra- data center and at edge facilities.

It also has partnerships with the likes of Cisco and Nvidia for “ready-to-go AI connectivity,” Read says. That means Equinix offers the right infrastructure to meet the requirements of high-end compute solutions in terms of power density and cooling. Such power densities are significant, requiring 120k VA per rack and up. “There’s plenty of talk about a megawatt rack,” he says.

Power is a significant issue in this entire discussion, Privett says. Older installed computing infrastructure likely consumes far more power than newer systems, which is an argument for upgrading as soon as possible.

“If you modernize today, you could substantially reduce the number of servers needed to support the same applications at a much lower power consumption rate,” Privett says. He advises sitting down with folks from the OT side of the house to make sure power is available for whatever you want to do. In many areas, power is at a premium.

If your plans include installing GPU environments in your own data center, WWT advises you not to delay. “We’re telling customers, you need to talk with us and get that designed, get that ordered, because it will take quite a bit of time until it actually ships and we’re able to install it,” Anderson says.

Moor Insights’ Kimball agrees. “You have to order these parts today if you want to see them hitting your dock, your warehouse, or your office 12 months from now.”

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

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.

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.

Lately most execs have been focused on making sure their AI projects pay off.

With good reason: The rate of failure for AI initiatives has been notoriously high.

But AI projects aren’t the only ones that need attention. In fact, CIOs and their executive colleagues should be putting that kind of focus into all IT projects, given that success on more conventional initiatives — from new software deployments to ERP implementations — is far from perfect.

Statistics vary. Some often-quoted reports about IT project failure rates of 70% date back several years, making them unreliable reflections of the landscape today. But project consultants say a good percentage of IT projects still fail, with estimates ranging from about a third to as much as high as that 70% mark.

In the Project Management Institute’s 2026 Pulse of the Profession report, researchers report that 31% of complex projects fail to achieve the full scope of their originally intended benefits.

CIOs, project leaders, researchers, and IT consultants generally define failure for an IT project as not delivering expected benefits within the expected timeframe. Failure can also mean a project doesn’t produce returns, runs so late as to be obsolete when completed, or doesn’t engage users who then shun it in response.

Why do IT projects continue to fail? Here are 12 common culprits.

1. Lack of project management expertise

Expensive and highly visible projects get the benefit of being led by professional project managers, but small and midsize projects often don’t, says Eric Bloom, executive director of the IT Management and Leadership Institute.

So those small and midsize projects are assigned to someone like a business analyst without any true training, he says. Those workers typically don’t have the expertise or experience necessary to succeed in the project manager role, nor are they given enough time to learn what it takes to manage a project or to complete the extra project management tasks.

CIOs would see higher success rates if more projects have trained project managers, Bloom says. They’re better able to corral and schedule resources, coordinate staff schedules, and get everyone moving in the same direction — and do so across multiple projects. They’re also more capable of implementing the governance needed to keep projects on target to deliver what’s expected and not let scope creep run up costs and schedules without adding additional value.

2. No alignment with business objectives

Some projects still fail because IT teams and business teams aren’t on the same page about the organization wants to achieve. The result is misalignment between the project objectives and business goals, says Shane McDaniel, CIO for the City of Seguin, Texas, and a Project Management Professional.

That’s both avoidable and fixable with communication. CIOs, their project leaders, and even team members need to cultivate strong relationships and engage in ongoing conversations where “they have the ability to raise their hand and say, ‘We have to get our heads together,’” McDaniel says.

“It boils down to communication, awareness, being proactive, and holding people accountable,” he adds. “There is a whole ecosystem around it to make that investment worthwhile.”

3. Ambiguity around measures of success

It’s impossible to succeed if success is undefined, yet executives continue to launch projects without articulating clear, concrete metrics to meet, says George Reed, CIO at auntEDNA.ai and a Project Management Professional.

Project owners must think about their future state, Reed says. “They need to ask, ‘If we were already done, what does winning look like?’”

Then project teams can determine milestones, leading indicators, and metrics to evaluate their progress and their final product. “[Project teams] need to know what needs to be true and what are the tangible benefits they need to deliver. No project should be approved if you don’t have targets for measurable results,” Reed adds.

4. Not enough scrutiny of AI outputs

Project managers and IT teams are using AI to help with scoping, scheduling, and myriad other tasks. The technology helps them move forward fast, but maybe not more accurately or as precisely as if they had done the work themselves.

That can be a problem for project success, says Te Wu, CEO and chief project officer at PMO Advisory.

“If you use AI, you get something quickly and it may look good, but the problem with AI is it can make stuff up,” Wu says.

AI tools may not introduce big errors; it might just have minor mistakes or misalignments, he explains. But if AI creates lots of those that are riddled throughout the project, then they add up and can tank the whole initiative.

“So, you have to have a sharper eye to spot issues; the reviewer has to be super diligent in reviewing it,” Wu warns.

5. Failing to work at the pace of AI

Wu has spotted another problem when project leaders bring AI into the process: It works way faster than the humans on the team.

That’s a benefit in many ways, Wu says. But as AI speeds through tasks, humans still need to run with the outputs. And if there aren’t enough people assigned at that point, work can pile up and projects fall behind schedule or need more staff than anticipated to keep up.

Wu advises project managers to adjust processes to accommodate the speed that AI introduces to avoid bottlenecks.

“This is just the reality, that we humans are too slow to review all the AI,” Wu says. “You can certainly use AI to accelerate IT project delivery, but project managers can’t then treat IT projects in the traditional ways.”

6. Mismatch between assigned resources and planned projects

There’s a long history of projects failing due to a lack of needed resources, as projects suffer delays or quality issues if the right experts aren’t available at the right time to tackle the needed work.

That under-resourcing continues to plague IT projects, says Noah Fletcher, a partner in the operations excellence practice at consultancy West Monroe.

Moreover, AI may be making the problem worse. Yes, project teams can use AI to speed through certain tasks, such as coding, and the project leaders can use AI to reduce the number of people required to handle those tasks. But business and IT execs often overestimate the time and resource savings that AI brings to a project and as a result ask for faster project delivery while assigning fewer resources. In other words, Fletcher says, people are being asked to do more with less — and often too much more with too much less.

Many organizations can indeed reduce the time and people they’re assigning to projects, Fletcher says, but they must train project teams on how to optimize their use of AI tools. Even with fully trained teams capable of optimizing their use of AI in project delivery, organizational leaders must have realistic expectations about AI’s contribution to a project’s timeline and resource needs.

7. Poor prioritization practices

Unrealistic AI expectations isn’t the only reason project teams end up with more than they can do, Fletcher says. Poor prioritization also plays a role in many organizations.

“They’re not making hard choices on what are the really critical things to drive through,” he says. “They sometimes have to make hard choices about what to push forward, but that whole prioritization governance function is something I frequently see as very ineffective.”

The result is that too many people are working on too many things, with diluted efforts leading to poor business outcomes for multiple projects.

Business and IT execs must work together to prioritize projects based on each project’s anticipated business value and then shepherd projects to completion based on that priority list — “which means cutting out a lot of the lower priorities,” Fletcher says.

8. No business ownership

Even when IT is perfectly aligned with business objectives, a project can still tank when no business leader has accountability, says Eric Stettler, a partner in the digital practice at Kearney, a global strategy and management consulting firm.

A business owner with clear accountability is needed to ensure that business resources are available when required, and that process changes and worker adoption happen, Stettler says. Having CIOs instead of a business owner try to make those happen “would be a tail-wagging-the-dog scenario,” he adds.

“CIOs can make sure the right process ownership is in place, and that leaders are aligned to a common set of objectives, but ultimately the business has to decide whether it’s going to operate differently,” Stettler adds.

9. Lack of business sponsor engagement

Business leader ownership is not enough; the owner also must commit adequate time for involvement and oversight.

Otherwise, they can miss signs that the project is going off track, or they can fail to cultivate enough trust that project leaders feel comfortable escalating issues early enough.

Moreover, if sponsors aren’t actively involved, if they’re just looking at dashboards, and only attending briefings, then all the decision-making is left on the project team who may not have all the information needed to make the best choices, says Lenka Pincot, chief of staff to the CEO at PMI.

“What is really needed is active sponsorship and help,” Pincot says. “You need someone to stand behind the idea, ensure funding for the project in the beginning and then when it’s running, to help navigate the business alignment with other stakeholders.”

There can be more than one sponsor, she adds. And if it’s a business project with an IT component — as practically all are these days, then sponsors should be the CIO and someone from the business.

10. Not involving all stakeholders

IT project manager Krista Phillips recounts one case in which a large multinational corporation implemented a new technology across its companies but caught one division completely unaware of the ongoing implementation work.

Turns out that specific division had been left out of all the planning and project processes.

Phillips acknowledges that project teams don’t usually overlook entire divisions, but they sometimes fail to identify and include all the stakeholders they should in the project process. Consequently, they miss key requirements to include, regulations to consider, and opportunities to capitalize on.

11. Slow or no decision-making mechanisms

Another issue that can put a project at risk: slow or no decision-making mechanisms.

Rick Catalano, partner with AMIGO, which provides project management consulting, training, and software, says many organizations lack a strong decision-making muscle and as a result projects grind to a halt or go off-track.

“Too often there is no one empowered to make decisions, and too often project managers are left waiting for answers and then get asked why things are late,” says Catalano, author of the book The AI Project Manager.

Catalano explains that the executives in charge and the project’s governing board need to have the authority to make decisions and the capacity to make them at a pace that aligns with the project’s timeline. But execs and project sponsors also need to empower project leaders who in turn need to empower those beneath them to make certain decisions, too.

This isn’t a project problem, Catalano says; it’s a cultural one. The C-suite must recognize that delayed or failed IT projects imperil the business and that it is worth their effort to remove roadblocks to success. From there, they need to implement a decision-making matrix, empowering the right people at the right level to make the right decisions, emphasizing the importance of making calls in a timely manner. And project leaders must know how to provide guidance so team members can quickly make informed decisions.

“Build the decision-making into the governance model, so everyone knows exactly who owns what and who is empowered to do what,” Catalano adds.

12. Shortchanging change management

Projects need more than skilled project managers; they also need leaders skilled in change. If projects don’t have skilled change managers and a plan to drive adoption of new technology, they’ll likely fall short of expectations, Fletcher says.

Given how critical technology — and particularly AI — is for business transformation today, “the impact of not having a plan is high right now,” he says. “So leaders need to demand and prioritize change.”

That makes change management particularly important now, he says, as most workers are dealing with so much change they need guidance to absorb it all.

Skilled change managers know how to align incentives to get people to accept new ways of working, and they’re deft at identifying and counteracting obstacles that could hinder adoption of new technologies, says Nick Kramer, a principal for applied solutions at consulting firm SSA & Co. They’re often able to get reluctant workers to get over their hesitations by helping them understand the why behind change.

“Change management is often viewed as just a communications plan, and there’s lip service done to it, but change management is really difficult,” Kramer adds, noting that he has seen more projects fail because of poor change management than poor technology implementations. “To succeed, projects need a CIO or someone else to be an agent of change, they need someone who knows how to drive change.”

If you’ve ever watched a PMO do everything right and still lose the room, you already know the frustrating part: it wasn’t the framework. In nearly two decades building PMOs across UAE and GCC government, energy and enterprise organizations, I’ve learned that the PMOs that get defunded are rarely the ones with weak methodology. They’re the ones led by someone the room simply stopped believing. If you’re a CIO, or you sit above a PMO watching capable people struggle to hold executive trust, the fix rarely starts where you’d expect.

I still remember exactly where I was sitting when a senior leader at a multi-billion-dollar utilities and energy group in the UAE said something that reframed how I think about PMO leadership for good. His organization had invested heavily in digital transformation — multiple programmes, real budget, dedicated teams. Yet as he spread the latest portfolio report across the table, he told me the numbers reaching him had never travelled through anyone his own board actually trusted. He had the data. He didn’t have anyone downstream who believed it.

That’s not a data problem. It’s an authority problem — and once you see it, you start noticing it everywhere.

The real diagnosis is almost always this: The leader was not ready

Not in technical skill. Not in professional knowledge. In the internal readiness that determines whether skill and knowledge actually convert into organizational trust — the readiness neuroscience now confirms shapes whether a leader is experienced as credible before they’ve said a single word. Under real pressure, the amygdala, the brain’s threat-detection centre, can override the prefrontal cortex — the seat of reasoning and composed judgement — before conscious thought catches up. That is not a character flaw. It is biology — and it is exactly why readiness has to be built deliberately, not assumed.

It’s not what you know. It’s the state you’re leading from

I once worked with a PMO Director who was, by every conventional measure, exceptional. A master’s degree in project management. Multiple professional certifications. Complex programmes delivered across three countries. And still — nobody listened. Executives politely avoided her meetings. Sponsors gave formal approval while quietly withholding the access she needed to actually drive change.

Then, after a governance meeting where her entire thirty-slide portfolio update was dismissed in ninety seconds, she asked herself the question she’d been avoiding: “Maybe the problem is me. Not in what I know. In how I’m showing up.”

She wasn’t wrong. She was mentally scattered across 15 competing priorities, physically depleted from 18 months of overwork, and emotionally reactive in exactly the conversations that determined her PMO’s future. She was doing the right things from the wrong state — and in GCC organizations, where trust is assessed continuously and non-verbally, people respond to the state, not the credentials.

She changed, deliberately, across four dimensions. Within six months, she wasn’t the same leader in the same role. She was a different leader — and the organization around her changed with her.

The SMPE framework: four dimensions, one readiness state

This is the readiness model I now build into every PMO transformation I lead — Spiritual, Mental, Physical, Emotional. Not concepts borrowed from a wellness programme. Four measurable dimensions of a leader’s capacity to earn trust under pressure:

• Spiritual. Are you clear on your purpose as a leader? Leaders with spiritual clarity lead from conviction, not compliance — and executive sponsors notice the difference.
• Mental. Can you think strategically under pressure without becoming reactive? This determines whether you can advise in the exact moment your credibility is on the line.
• Physical. Do you have the resilience to sustain high performance for the length of a transformation, not just a sprint? Governance is endurance — and heart-rate variability, a marker of how well the nervous system recovers from stress, is one of the strongest known biomarkers of that resilience.
• Emotional. Can you stay genuinely present and regulated in difficult conversations? Your emotional state reaches the room before your words do — stakeholders feel it first, through the same mirror-neuron mechanisms that let any of us unconsciously catch a leader’s stress, or their calm.

The brain decides whether to trust a leader within the first hundred milliseconds of an interaction — before the agenda opens, before a single slide is shown. SMPE readiness is what that split-second assessment is actually detecting.

Evidence from the field

Three engagements. Three sectors. One pattern.

At a national energy company in the UAE, an AED 3.67 billion transformation programme was being tracked with no way to measure its return, and the PMO was seen as overhead. The development focus was Spiritual and Mental readiness — helping the leader claim a new identity, from reporting layer to investment governance mechanism. Within sixty days of that identity shift, the sponsor relationship changed. Result: an estimated 45% improvement in portfolio ROI.

At a multi-billion-dollar utilities and energy group, the gap was Mental and Emotional — a technically excellent leader who had learned to hedge under pressure. The shift was learning to say “the data is unclear” with executive authority, instead of “I don’t know” with a disclaimer. Executive decision cycles sped up by 20–30%.

At EY MENA, commissioned to bring governance to fifteen government units across the Kingdom, full SMPE readiness was required — especially Emotional Readiness, navigating the politics of fifteen sovereign entities without losing credibility or relationships. I remember the first week vividly: a room of 15 director-generals who had already sat through two consultancies that promised transformation and delivered PowerPoint. Nobody owed me credibility. What earned it in the first ninety seconds wasn’t my CV — nobody had read it yet. It was presence. Three of those Director-Generals later told me directly that this was the moment they decided to grant access that would otherwise have taken months to earn. The EPMO went live across all fifteen units within three months.

Why this looks different in the GCC

The SMPE Framework wasn’t built in a Western consulting practice and adapted for the region — it was built here. The majlis tradition of open consultation means decisions that appear to be made by a single executive are almost always the product of conversations that happened before the meeting you attended. A recommendation met with silence isn’t a rejection — it’s a signal that consultation is still underway, and a leader who reads it as “no” damages the relationship the PMO’s credibility depends on. Reading that room correctly is a readiness skill, not a cultural instinct you either have or don’t.

From project police to strategic business partner

SMPE readiness makes one identity shift possible: from the PMO that enforces process compliance to the one that enables outcome delivery. From reporting on what happened, to advising on what to do next. From reacting to issues to anticipating them before they land on the sponsor’s desk.

That shift doesn’t come from a new template. It comes from a leader who has done the internal work — and whose presence in the room communicates it before the agenda is even opened.

The chain, rebuilt

The organization from that first conversation is a different place today. The numbers didn’t change. What changed is that they finally travelled through people who believed them — and the data backs up why that matters at scale: PMI’s own research has found that organizations with consistently engaged executive sponsors report roughly 40% more successful projects than those without. Sponsor engagement isn’t a soft metric. It’s the clearest predictor we have.

That is the work I now do with PMO and transformation leaders across the GCC — not another framework to memorize, but the readiness to walk into the room your framework has already earned. If you’ve ever watched a strong plan lose the room anyway, I’d love to hear your experience.

Mohan Sankararaman calls the old approach to technology-driven transformation — the kind of change that lands every few years and reshapes the organization in one push — a trap. As executive vice president and CIO of First Horizon, a regional bank headquartered in Memphis, he’s focused on driving digital transformation the way a bank funds risk: incrementally with room to pull back.

Every CIO is under similar pressure to rethink change management for the AI era. Wanda Wallace, managing partner at Leadership Forum, has advised CIOs on change management for years, and she thinks the job itself hasn’t changed much.

“The hardest and most critical aspect of making change happen and stick is convincing people to adopt a new approach,” she says. “AI doesn’t change that need or that process. It is a human-to-human dynamic.”

Talk to the practitioners and researchers closest to the work, and a version of her view emerges again and again. What has changed is how many things are competing for an organization’s limited capacity to absorb them — AI chief among them. Here are five hard truths IT leaders face about change management today.

1. There’s no finish line

Ashish Parmar, CIO of Standard Industries, a global industrial conglomerate with more than 20,000 employees across roughly 50 countries, has watched the nature of transformation shift beneath him. In the past, he says, change was treated like a project with a start date and an end date — whether the trigger was a new ERP system, a reorg, or a cost-cutting mandate. That model doesn’t hold anymore.

“Today, change is continuous,” Parmar says. “Our strategy is focused on building resilience and adaptability rather than getting to a single destination.”

AI is the clearest example of how the old model breaks down, says Fran Maxwell, who leads Protiviti’s people and change practice, though he’s quick to note it isn’t the only one. Unlike an ERP rollout, which lands as a discrete event, an AI transformation keeps moving.

“The technology evolves continuously, use cases emerge rapidly, and the impact on roles is often uncertain,” Maxwell says. The common misstep is treating any major shift, AI-driven or not, like a one-time project with a training curriculum and a communications plan, he says. The fix is building a permanent capability for adaptation rather than staffing up for a single push.

None of that continuous adaptation is possible if the underlying systems can’t support it, notes Manosiz Bhattacharyya, CTO of Nutanix.

“Technology is not the barrier to transformation; application modernization is,” he says. Years of accumulated dependencies, legacy integrations, and fragmented data are what actually slow an organization down. And layering new tools on top doesn’t make that debt disappear.

“Applying AI blindly does not remove technical debt,” Bhattacharyya says. “It amplifies it.”

2. Bandwidth isn’t just a network problem

A 2026 survey of roughly 3,000 HR leaders by talent firm LHH found that no single cause dominates why companies reshape their organizations: AI and automation, skills mismatches, M&A activity, and strategic shifts were each cited as drivers in the previous year by about a fifth of respondents. In other words, most organizations are contending with several forms of change at once, not just AI.

All that change at once runs into a hard limit: An organization can absorb only so much at a time.

“Every organization’s capacity for change is finite, so leaders cannot endlessly stack new initiatives on top of existing workloads,” Parmar of Standard Industries says.

Rather than treat that ceiling as a constraint, he argues CIOs should use it to force discipline. IT leaders should determine their non-negotiables and point the team’s energy there instead of spreading it thin across AI pilots, reorganizations, and everything else competing for attention.

Sankararaman arrived at nearly the same conclusion at First Horizon. Banking used to reward slow, occasional overhauls, the kind that could take years to prove out, he says. But that approach has become untenable.

“It’s tempting to treat transformation as one big initiative, but with technology evolving this fast, that’s a trap,” he says. Instead, Sankararaman releases funding in stages, each tied to a measurable result before the next is approved. Then, the organization can adapt and build confidence as it goes rather than betting everything on a single multi-year plan. “We reward progress, not perfection,” he says.

Kevin Martin, chief research officer at the Institute for Corporate Productivity (i4cp), has data that supports the value of incremental improvements. When leaders want to move faster, the reflex is to restructure: delayer, widen control, redraw reporting lines. i4cp’s research found no statistical relationship between those structural moves and organizational agility or market performance. What separates agile organizations are routines: scenario planning, faster resource reallocation, clear decision rights, continuous workforce planning, targeted reskilling, and disciplined execution.

“You don’t reorganize your way to agility,” Martin says. “You build it into how the organization operates.”

3. Shadow IT doesn’t belong in the shadows

Employees finding their own tools to get work done isn’t new. Shadow IT has taken on various forms over the years, from personal file-sharing accounts to unsanctioned SaaS subscriptions.

Today, it’s shadow AI, and Sankararaman argues most CIOs still treat it as a security or compliance issue rather than what it really is: information about what the organization needs and isn’t getting.

“Shadow AI is already happening in every organization. If you’re not addressing it through your change management strategy, you’re addressing it too late,” Sankararaman says.

Sankararaman’s approach starts with curiosity rather than restriction: understanding what employees are trying to accomplish with the tools they’ve found on their own, which makes it easier to agree on how the business should govern those tools.

“That’s a change management conversation, not just a policy conversation,” he says.

4. Trust has to be designed in, not repaired later

Every new system that changes how decisions get made must earn trust before it achieves adoption. Agentic AI raises the stakes because it doesn’t just inform decisions; it takes actions on its own within workflows.

That’s a fundamentally different dynamic from anything change leaders have managed before, Sankararaman says. The resistance it produces is often quieter, showing up in questions about how a system reached a conclusion, who’s accountable when it’s wrong, and whether it’s replacing what someone does. “Those questions deserve real answers, not reassurance,” he says.

At First Horizon, IT is building trust into the foundation with permissioned access, centralized guardrails, human oversight, and outputs that are consistent, reviewable, and explainable. “If people can’t understand how the technology reached a conclusion, you haven’t earned their trust,” Sankararaman says. “And without trust, adoption doesn’t hold.”

Employees today worry less about learning a new tool than about what it means for their role, their skills, and how their performance will be judged once a machine does part of the job.

“They worry about career relevance, accountability, job security, and how performance will be evaluated,” Protiviti’s Maxwell says. Closing that gap, in his view, takes more than a rollout plan. It demands transparency about what’s changing, what isn’t, and how people add value once the tool is in place.

5. Tired isn’t the same as unwilling

Ask IT leaders about change fatigue, and they frame it as a capacity problem rather than resistance. Late 2025 saw a wave of five-day return-to-office mandates that landed on top of continued layoffs. Tech companies alone cut more than 66,000 jobs between May and November, according to Newsweek and TechCrunch, exactly the kind of concurrent disruption that erodes an organization’s capacity for change.

Among what i4cp calls “coasting incumbents” — companies that still perform well despite low organizational agility — 51% of employees report finding change fatiguing, and just 8% say change management is an organizational strength. At “agile pacesetters” — the highest-agility, highest-performing organizations in i4cp’s research — only 12% report high fatigue.

“AI is an accelerant,” Martin says. “But organizational friction is the fuel.”

Protiviti’s Maxwell argues that change fatigue is often less about resistance and more about capacity. “Employees are far more likely to embrace change when leaders are clear about what matters most, what success looks like, and just as importantly, what is not a priority right now,” Maxwell says. His advice to CIOs: Empathize and prioritize before accelerating.

One structural fix most CIOs underuse is shared ownership. “Don’t go at it alone,” advises First Horizon’s Sankararaman. “Partner with others across the business, your CHRO, CFO, COO, and make them co-champions of the change, not just stakeholders who get updates.” A message that arrives from multiple leaders, he’s found, carries more weight and lasts longer than one delivered by IT alone.

The absence of fatigue, in Wallace’s view, is its own warning sign. “If your organization isn’t change-fatigued,” she says, “then I am worried about what you have been doing.”

I often hear the same types of complaints from leaders struggling with underperforming AI projects. Things started out great but then tailed off. They’re not seeing the ROI they expected. Maybe AI wasn’t a good fit for their organization.

These leaders are not alone. But whatever their specific underlying issue, I usually respond with the same question: How are you handling change management?

And the answer, in most cases, is not very well. It’s not that they’re not including any change management in their AI efforts. It’s just not getting the attention it should.

They’re using outdated methods and techniques. They’re treating change management as a commodity instead of a strategic advantage. They’re checking a box.

But that approach won’t work for AI.

AI is transformative by definition. It’s technology that makes change part of what organizations do. And when change is constant, change management needs to be constant as well. You can’t just run through the same standardized list of stakeholder interviews, communication plans and training regimens that you used for the last software rollout and hope for the best.

But what you can do, ironically enough, is use AI itself to reinvent change management for the age of AI by making your process more continuous, employee-centered and measurable. And in doing so, you’ll be transforming change management from a one-time project into an ongoing organizational capability.

Why traditional change management is breaking down

Here’s the paradox. When asked, every one of those leaders who told me about their AI issues would describe change management as essential. Yet when budgets get tight, it’s likely the first thing to be pared back. So how “essential” is it, really? If we thought it had real value, we wouldn’t be so quick to give up on it.

The truth is, change management hasn’t changed much over the past two decades. As a result, many of us are probably still relying on longstanding programs or disciplines that haven’t kept up with the pace of change. For example, we may be listening to the wrong people. Most programs still collect feedback through a handful of our colleagues and time-tested methods, including:

• Small interview groups
• Executive stakeholders
• Representative committees
• Broad but shallow surveys

The problem with this approach, particularly when it comes to AI, is that the people actually doing the work often have little voice. In other words, frontline employees are expected to change their behavior without helping to shape the solution.

Think about trying to use AI to redesign your sales function. If all of your change management effort is focused solely on the input of your sales operations team instead of your actual sellers, you’re likely to wind up with technology that looks good on paper but doesn’t fit real workflows.

And that’s why you see the familiar sparkle-and-fade patterns when it comes to AI adoption:

• Initial compliance, as everybody is willing to give the new tech a try.
• Post-launch celebration, as the organization sees early adoption as a sign of long-term success ahead.
• Steadily declining usage, as users begin to realize that AI doesn’t fit well with their work.
• A frantic after-the-fact scramble, as the organization attempts to diagnose problems and salvage its investment.

You can just hear the air coming out of the balloon as you read down that list. Listening to the wrong people – or not listening to enough of the right ones – is a recipe for discovering adoption barriers after the rollout instead of while the change is happening.

In most cases, that’s way too late.

How AI can reinvent change management

I can picture those leaders with their stalled AI projects shaking their heads at me. Even if we wanted to upgrade our change management process and listen to more employees, they might  say, how are we supposed to do that?

It’s not a bad question. After all, they probably weren’t just being stubborn by not interviewing their thousands of employees for previous rollouts. It was simply a prohibitively expensive proposition.

But AI makes continuous listening possible. AI voice agents, for example, can conduct simultaneous conversations at enterprise scale.

The result? We can now work with organizations to compile feedback from hundreds of employees in under a week, a task that previously would have required months of interviews and surveys. AI gathered the information, and human change leaders interpreted it and made decisions.

AI, in other words, makes it possible to move beyond the limitations of traditional surveys and instead build an organizational nervous system. It allows for things like:

1. Continuous employee listening through voice agents that enable open-ended conversations to yield rich sentiment and clear identification of pain points.
2. Organizational network intelligence that uses data analytics to identify informal influencers, communication patterns, key adoption champions and disconnected teams that might need additional support.
3. Behavioral monitoring and real-time feedback to identify where users get stuck, detect adoption friction early and recognize patterns before they become widespread problems.

For example, if sales reps consistently abandon an AI assistant before generating customer proposals, leaders can detect the pattern within days instead of discovering it months later through adoption reports.

These are the kinds of upgrades that can help organizations move from reactive change management to proactive adjustment. And with AI automating everything from data collection to synthesis to ongoing monitoring, experienced change leaders can use their expertise to focus on broader, more impactful activities like executive coaching and strategic communication.

In other words, less time and effort managing large administrative teams and more time influencing outcomes.

From change management project to continuous capability

I’m sure all of those leaders looking to reverse their slumping AI projects are probably thinking that while this approach to change management sounds great, what can they do about it right now? Well, Rome wasn’t built in a day, but those builders didn’t have AI. Here are three practical principles leaders can start using immediately:

1. Give every employee a voice

The old playbook of relying solely on representative groups doesn’t cut it anymore, particularly if you’re not getting feedback from those who will be directly affected by the change. At the end of the day, those are the groups that will actually be responsible for operating in a new system, so if you want it to stick, you need to hear their pain points.

Fortunately, getting input from everybody is possible now, so it’s time to create scalable mechanisms that continuously capture those frontline experiences.

2. Anchor every decision to measurable business outcomes

Start with your desired KPIs – whether sales effectiveness, marketing performance, customer satisfaction, productivity or employee experience – and then work backward. If a proposed change doesn’t support your chosen outcomes, reconsider it.

3. Embed change management into operations

For far too long, many organizations have made the mistake of treating change management as a parallel workstream or something tacked onto a project plan. Now it’s time to start integrating everything – listening, enablement, measurement and communications – to help make change management part of how the organization operates.

Of course, in order to use AI to make real progress in any of these areas, you have to have buy-in. And employees may initially distrust something like AI-driven listening. That’s why it’s important to focus on…

• Transparency about data use.
• Anonymity where appropriate.
• Personalized, contextual communications.

Most importantly, employees are more likely to come around on AI if they see that the organization is actually responding to what they’re sharing. Don’t tell them how AI makes things better, show them.

AI gives organizations the change management they’ve always wanted

For years, too many organizations neglected change management. Why? Because they could get away with it for many projects. But not AI.

AI demands a change management process that is continuous, measurable, adaptive, employee-centered and embedded in daily work. Ambitious, sure, but also impractical with yesterday’s technology.

But AI changes that equation.

It may seem ironic, but AI is what can enable change management to become what it was always intended to be. That is, an ongoing capability that continuously listens, learns, adapts and helps organizations evolve alongside their workforce.

And just in time for the massive AI changes that have arrived.

When Sastry Durvasula joined TIAA in early 2022, he saw an organization fighting against outdated legacy technologies and in need of a major IT refresh.

Since then, the financial services organization has completed two phases of a comprehensive transformation initiative called Technology Ecosystem Transformation, or TETRIS, leading to a huge reduction in tech debt and a major expansion of functionality for customers.

The ongoing project, anchored in cloud and AI technologies, started in 2023 with phase one that modernized the core technology stack with 10 new enterprise platforms. Phase two, launched in late 2024, went further by enabling 87 use cases across all major lines of the business.

The project, for example, allowed TIAA to launch its MyChoice Multi-Year Guaranteed Annuity product, and helped create the TIAA Gateway portal, an API-based suite that integrates with partners in retirement and wealth planning using industry standards.

TIAA Gateway took home a CIO 100 Award in 2025, and phase two received a CIO 100 Award in 2026.

Durvasula, TIAA’s chief operating officer, pitched the multimillion-dollar TETRIS project to the board as a three-pronged strategy, with empowering business growth, fueling innovation, and transforming the IT core as its key goals.

Not only did TETRIS need to modernize the company’s IT systems, decommission legacy processes, and automate other processes, but Durvasula pitched it as the way to expand the reach of TIAA’s products and move the company into the future.

“As you expect in a company of our size, we have problems of yesterday, today, and tomorrow being solved at the same time,” he says.

Focus on business use cases

As TETRIS moved into phase two, project leaders shifted their goals from pure technology modernization to business outcome-driven prioritization. So once phase one delivered needed IT platforms like a data cloud and design studio, TIAA pivoted toward enabling business use cases.

This business-first approach ensured continuing executive support and clear ROI at every key milestone, TIAA says.

In 2022, just before the project launched, more than 80% of TIAA’s IT workloads resided in fragmented, end-of-life platforms, which created operational risk, compromised security and resilience, and constrained its ability to innovate. Through TETRIS phase two, however, the organization has cut that tech debt nearly in half.

And consolidating 17 design systems also led to digital products looking and behaving differently, depending on the team that designed them, and accelerated product launches by 35%, enabled multi-lingual capabilities, and increased accessibility to more than 185,000 customers who don’t speak English.

In addition, TETRIS allowed TIAA to combine multiple middleware systems and data lakes, Durvasula says, and the organization moved mainframe applications and data center infrastructure to the cloud.

A giant leap forward

TETRIS has been a huge project, with the company saying it empowered TIAA to have one of the largest leapfrog moments in company history in its submission for the 2026 CIO 100 Award.

Despite the reported failure rates of large transformation projects — some estimates suggest up to 95% fail to meet their goals — TETRIS was essential to keep TIAA competitive and move it forward in the market, Durvasula says.

A big part of the project has been workflow modernization, he says, because TIAA were using some technologies and workflows that were decades old.

“There’s your classical platform and application rationalization, and then there’s your end-of-support, end-of-life stuff that should’ve been remediated long ago,” he says. “Some of the processes we have, because we’re such a large, old company, were designed when the internet just came along.”

Stick to the metrics

Two keys to pulling off such a large project are establishing metrics for success and transparency with leadership, Durvasula says. Project leaders set milestones to indicate when things went well, and they planned for bumps in the road so the TIAA board knew when setbacks happened.

“Not everything is as pretty as it sounds in an awards application, but the success measures we established with our board were based on both phases,” he says. “For the first one, we said we’d deliver enterprise-grade platforms and accomplish migration objectives, but not tied to any specific business objectives.”

Phase two metrics focused more on business objectives, and the project team kept the TIAA board updated as TETRIS moved forward. Setting realistic goals was important, he says, with the team determined not to overpromise results.

“Large programs have a range of objectives, and if you publish the outcomes you’re looking for, people start looking for them, especially stakeholders, the C-suite, and board,” he says. “You have to be honest about which metrics or KPIs you can deliver in the first and second year, and when you’ll start seeing real business scale and impact, which definitely won’t be that soon in a large program like this.”

Goals also need to be flexible, Durvasula says, so transparency with leadership sometimes means telling them the project needs to reset. “If something doesn’t go well, what’s the level of fungibility you have?” he says. “We pick this tool, but what if it doesn’t work? You need to have a plan B.”

So TIAA’s IT team is heavily focused on flexible systems, and what was contemporary three years ago is probably legacy now, especially thanks to AI.

The power of change management

Another big lesson from a project of this size is the need to focus on change management. Retiring old IT systems requires the organization to bring employees along on the journey and convince them the changes are for the better.

TIAA established a multi-disciplinary team to implement a change management program focusing on breaking down silos and setting common adoption goals across the organization and its lines of business. Stakeholder forms and a huge focus on continuous collaboration helped employees understand the need for the changes.

“It’s a big organizational change,” Durvasula says. “If you’re working on a legacy system, and you think at some point it’s going to be modernized, then you become a legacy talent, and won’t have a job.” But the right change management program can convince these employees they can upskill and bring value to the new systems.

“You can bring your functional knowledge of the business and learn new technical skills,” he says. “It’s a massive culture- and people-change initiative as much as tech initiative.”

TIAA’s change management efforts were also made easier because TETRIS happened at the same time as the recent AI boom and involved AI elements. So it wasn’t hard to convince employees they needed to improve their AI skills.

“Because of AI, everybody woke up to this new reality,” he says. “We rode that wave when transformation drove from a cultural and organizational change management point.”

At their deepest level, LLMs are still a kind of magic. Even the developers who build them find them to be, channeling Winston Churchill, “a riddle, wrapped in a mystery, inside an enigma.”

That’s why everyone working with LLMs in their enterprise stack needs a way to peer into the dark mass of weights to help make sense of these numerical beasts.

Lately there’s been an explosion of tools that can assist. Companies are building platforms that sit in an agentic AI niche market that might be called “Evaluation and Benchmarking.” This tools track the best performing LLM or agentic options, testing their fit and watching over them as they chew through tokens.

With agentic AI still an emerging technology class, the boundaries between its nascent market niches are far from set. There are other sets of tools for tracking raw performance, an area that some call “AgentOps” or “Observability.” (See “19 AgentOps tools for monitoring AI activity, issues, and costs.”) And still more tools that focus on maintaining our faith in agent answers and on building controls to keep agents from straying, a niche that’s starting to be called “Trust and Guardrails.”

Some of the vendors operating in these spaces are starting in one category and then expanding into another. Others are diving as deeply as they can into their niche. The next year — no, let’s say the next few months — are bound to be fascinating as the tools improve and the various markets evolve and intermix.

For now, here’s a list, in alphabetical order, of some of the best options for any enterprise team that needs to evaluate agents and benchmark their performance. 

Braintrust

Big projects require tools that can scale to handle the large amount of dataflows required to trace and pinpoint errors. Braintrust is built to support enterprise-size efforts to deliver meaningful answers to a large collection of users. The tool’s sales literature promises to “trace everything” in order to have the right data available when it’s time to dissect a failed response. Braintrust also delivers a helpful dashboard that aggregates all this data so large errors in latency, cost, or quality can be identified quickly. An automated set of evaluation tasks can track answers and compile useful metrics for ensuring the agent stack is answering the needs of a large set of end-users.

Pricing: A free plan comes with $10 of credits. Pro plan starts at $250 and comes with more credits and a longer retention period.

Standout feature: Loop agent tracks behavior through multiple iterations for deeper debugging power.

Best suited for: Fast-moving teams iterating on prompts and product

Confident AI

Developers who rely on DeepEval but don’t want to host the code can turn to Confident AI, a cloud-based platform for fast, simple, and seamless deployment. The system adds a sophisticated UI that includes a dashboard for tracking and archiving all tests. This collaborative environment enables teams to work swiftly together without worrying about the troubles of exchanging problematic traces or other telemetry files. This makes it easier to extend the power of tools such as DeepEval to handle the continuous tracing and testing necessary in production environments. 

Pricing: A “forever free” plan offers a taste. The pay plan starts at $200 and includes features such as better automation and simulation.

Standout feature: Automated red-teaming and on-demand pen-testing helps build more secure results.

Best suited for: Enterprise teams building on established stacks that need the convenience of a collaborative environment

DeepEval

When a model finds a home in a production environment, it’s time to add unit tests that will double and triple check its behavior so the developers can iterate and the CI/CD pipeline can catch any mistakes or regressions. DeepEval delivers a set of Pytest-native Python scripts that run either locally or as part of the deployment pipeline. The tests check simple issues as well as more complicated and ephemeral problems such as hallucinations, drift, role adherence, knowledge retention, and conversation completeness. If the LLM starts to act up or turn into a toxic rogue, these tests will flag them.

Pricing: The open-source version of Confident AI’s tool is available with an Apache 2.0 license.

Standout feature: Full complement of PyTest modules watch for problems such as hallucinations or worse.

Best suited for: Teams with the depth and ability to fully embrace open-source tooling

LangSmith (from LangChain)

As agentic approaches begin to dominate, dev teams need a deep debugging tool like LangSmith, which tracks not just inputs and outputs, but all the steps an agent takes as well as the context that evolves along the way. This enables developers to pinpoint the stage or mechanism deep in the agent where latency, quality, coherence, or other agent parameters go wrong. The tool can be integrated with Python, Go, Java, or TypeScript applications or be used from a cloud-based app that offers a sophisticated UI.

Pricing: Solo accounts start for free. Paid tier ($39 per month per seat) unlocks more tracing and better support.

Standout feature: Complex agent graphs can be tracked with automated surveillance. 

Best suited for: Teams invested in the Langfuse tool stack

Langfuse

Finding the best model means feeding the same prompt to the same model, a process that’s getting only more complicated as developers build out multilayered agents that break tasks into multiple steps. Langfuse is an open-source AI tracking tool from Clickhouse, a company that specializes in curating oracular tools like databases. Teams can work together through the Langfuse platform to juggle the various prompts, traces, and answers. The system nurtures an LLM evaluation loop so that teams can find the best combinations of models and agents to solve the problem at hand.

Pricing: Open-source versions offer starter support. Core version starts at $29 per month and includes more traces, longer retention, and better support.

Standout feature: Open Telemetry functionality offers modularity and flexibility.

Best suited for: Budget-focused teams with the ability to leverage open-source ecosystems

LiveBench

Developers who want to send a set of questions to an LLM and then evaluate the performance turn to LiveBench, an open-source tool kit that’s routinely used to benchmark many models during development. Answers are deliberately not graded by other LLMs but compared against hard-coded answers. The tool can be extended, but there’s no fancy GUI. The work is done with configuration text files that specify the ground truth for evaluating the result. When you’re done, you can even contribute your questions to the general open-source project so that others can use them to guide LLM development.

Pricing: Open source

Standout feature: Frequently updated benchmarks offer contamination-free evaluations of models.

Best suited for: Teams evaluating a wide range of models in search of the best performance for their applications

Maxim AI

As the workloads grow more complex and combine multiple steps through workflow graphs, tools such as Maxim AI become more useful. Maxim AI tracks results with an end-to-end tool for evaluating and simulating agents. Prompts and agents and the trajectory they take to an answer can be endlessly simulated prior to deployment and then observed through deployment. The framework-agnostic tool links datasets and data providers to give teams the best insight into how well an agent is delivering.

Pricing: Free model offers one workspace with three-day retention. Pro plan starts at $29 per person per month with longer retention period, more logs, and features such as simulations.

Standout feature: Full simulator can test a wide range of uses and users.

Best suited for: Teams focused on delivering conversational agents

MLflow

Much of the work of developing a useful agentic solution is a long slog through endless combinations and iterations. The MLflow open-source platform is designed to optimize this process and speed it up as much as possible. It is part of a larger tool collection that follows the entire lifecycle of a model from training to deployment. The later stages of development, for instance, rely on systems such as the Prompt Registry, a kind of version control that allows prompt engineers to work through various approaches and linguistic tropes. The goal of the entire process is to deliver the evaluation cycles necessary to deliver a model up to its set of targeted tasks.

Pricing: Free and open source for self-hosted. Cloud computing charges for hosted versions.

Standout feature: Full lifecycle tracking for following models and tracking their costs

Best suited for: Enterprise teams watching a collection of machine learning and AI-based algorithms

Onyx

One of the simplest ways to build a basic chat system that incorporates local retrieval-augmented generation (RAG) knowledge bases is to download Onyx, a front-end tool that’s available as either an MIT-licensed community edition or as a commercial product with a few more features useful to larger enterprises. The RAG layer guides search, and Onyx’s developers built an open-source framework for testing RAG performance. Onyx administrators can also track what users are asking and how well they like the final result.

Pricing: A free starter plan offers limited storage and one database. Pro plan starting at $49 per month offers many more traces, larger storage, and access to features such as saved workflows.

Standout feature: Real-time search for monitoring production environments at scale

Best suited for: Enterprise with larger challenges with substantial RAG integration

Promptfoo

LLMs can fail in a number of ways. Promptfoo iterates through various tests that simulate real user interactions to simulate the types of issues an LLM might face each day. Promptfoo also focuses on some of the biggest security problems and specializes in red teaming to detect any failure points that might be exposed by a malicious user. From toxic edge states to personally identifiable information (PII) leaks, the goal is to deliver tests that will expose potential jailbreaks and failures in the guardrails.

Pricing: “Free forever” means an open-source tool with community-based support. An enterprise version offers custom deployment options and better support.

Standout feature: Automated red-teaming and prompt scrutiny helps lock down implementations.

Best suited for: Security-focused teams that are constantly evaluating and re-evaluating their product’s security.

RAGAS

When RAG databases are a key part of the agentic stack, developers turn to RAGAS to stress test the deeper mathematical corners of the retrieval mechanism. The Python library offers standard and custom metrics for evaluating the performance of the RAG storage-and-retrieval mechanism at the level of vector mathematics. These measure behaviors such as faithfulness, relevance, and totality of recall. The philosophy begins with experiments to speed development but ends with fast integration with the deployment pipeline. Instead of just doing a “vibe check” on the RAG database, developers are using a more scientific approach to test and converge on better total performance.

Pricing: Fully open source under Apache 2.0 license

Standout feature: RAG focus helps teams relying on vector databases for knowledge curation.

Best suited for: Teams with a substantial reliance on RAG databases

Rhesis AI

Many of tools in this evolving market niche are designed for hard-core developers. Rhesis AI wants to bring other stakeholders into the development cycle so they can create tests and evaluate performance, too. That means domain experts, product managers, and even C-suite suits can track how the LLMs behave in conversations. Adversarial or confrontational engagements that devolve into the edge cases that bring headaches are easy to simulate repeatedly to optimize responses. The platform is designed to test all stages of development in a way that’s accessible to all stakeholders.

Pricing: Said to be “open source first” but with enterprise plans for those that need it.

Standout feature: The focus on putting humans in the loop is ideal for applications that require input from meat-based intelligence.

Best suited for: Applications requiring more collaboration with domain experts

Vellum

Anyone who needs a personal assistant can turn to Vellum to help build one that is trained on your data. Along the way, you will evaluate performance using its elaborate testing framework that tracks performance against any of the metrics and use cases you supply. Real-time dashboards track performance using metrics such as token usage costs, latency, or response quality. Multiple teams can work in parallel with version controls that allow iteration and competition. The end result is an agent that’s tuned to your needs.

Pricing: A basic free tier for experimentation. The Mighty starts at $30 per month and comes with more storage and compute credits.

Standout feature: End-to-end integration simplifies managing new development.

Best suited for: Cross-functional teams looking for a centralized solution with wide integration

Enterprises of all sizes in all industries are rapidly deploying generative and agentic AI to automate processes. But the efforts aren’t always panning out.

Some reasons are new and unique to this technology. But others are related to issues we should’ve been prepared for because we saw them during the age of RPA. And in the rush to adopt new tech, some of these lessons are being forgotten.

“This new era of agents puts the same challenges again in front of us, and we need to think about the things we faced back when that revolution happened years ago,” says Agustin Huerta, SVP of digital innovation and VP of technology at Globant, a digital transformation company.

Those challenges often include selecting the right processes for automation, setting up systems to manage those processes, making sure automated processes get the right inputs, and managing the wider impacts of automation, including cultural.

1. Automating the right processes

All the lessons of RPA are carrying over, says Stephanie Bova, digital transformation officer at Novo Nordisk, including the biggest one that just because you can automate something, does it mean you should.

“We think hard before we start creating something,” she says. “Who’s going to maintain it, and where is it documented?”

And of course, is the process itself a good process. “Nothing gets built on a process that hasn’t been optimized anymore,” she adds. “We haven’t done a technology deployment on an unoptimized process for two years.”

And the company is now a lot more selective about how much automation it rolls out, but that wasn’t always the case with RPA. “At one point, everyone who wanted a piece of automation could get something built for them,” she says. “That’s not the case on how we’re approaching agents.”

There has to be real business benefit to the project, she says. “If you can show me the business outcome, we’ll consider it,” she continues. “But we don’t want or need hundreds or thousands of agents deployed. We want them all standardized and monitored, controlled, and auditable.”

Something similar happened a decade ago with RPA, says Huerta, when easy-to-use automation tools became available to people.

“When they were deployed without proper governance, systems got exposed,” he says. “They started stressing the overall infrastructure of the company, and some robots weren’t created in a way for a return on investment. The process ran faster, but consumed more in the cloud, so you ended up putting all the money you saved in the process into your cloud infrastructure, and the total ROI was zero.”

2. It’s not “set and forget”

Legal services company Purpose Legal uses the same basic approach for gen AI-based automation as it did with the previous generation of automation, based on ML, human oversight, and careful validation of the automated processes.

Take for example legal discovery, where documents are produced and shared with the opposing party in a legal case.

“Inadvertent production of sensitive data is a nightmare,” says Jeff Johnson, Purpose Legal’s chief innovation officer. “We always have to evaluate the data. Especially in the legal services context, we need people in the guardrails to make sure the process is on track.”

Without that oversight, problems can escalate quickly.

“If you make a bad decision you may get chastised by the court, lose the case, or lose the client entirely,” he says. “That happened in the past if you trusted automation too much.”

The AI tools today may be more sophisticated, he says, but they’re not perfect. “Even in the world of gen AI, it’s still something we need to watch out for,” he adds.

If anything, the oversight is even more important because of the scale at which AI can work, and how authoritative it can seem.

“Attorneys are more inclined to trust automation now because it interacts with them much more like a person would,” Johnson says. “It’s actually giving attorneys summaries of documents that look like another attorney wrote it, but that doesn’t mean it’s right.”

3. Reaping what’s sown

The need for good inputs goes back to the beginning of the computing era, if not earlier. “If we aren’t proving good inputs and putting good guardrails in place about where the AI gets its input, we get bad decisions,” says Johnson.

After all, data quality is a concern for any company rolling out automation, whether RPA or gen AI.

“Agentic AI won’t solve the entire data quality issue,” says Sabrina Joos, director of program and lifecycle management for new systems for the Americas at Siemens. But there are some differences, she says, in how it plays out.

In the RPA world, data quality was mostly about structured data and stable inputs. So, for example, if the data was formatted in a way the RPA didn’t expect, it might not execute.

“With agentic AI, the data quality issue becomes much more complex,” she says. “It’s no longer just about whether the data is correct, but if it’s complete and meaningful in context.”

AI systems can accept unstructured inputs or ambiguous data and make sense of it, but it doesn’t always interpret that data correctly.

“We don’t care too much about the format or typos since that’s not as much of an issue anymore,” Joos says. “But if there are assumptions that aren’t right, the process or workflow will still be executed. And this is where you have a risk that it will scale.”

For example, an AI can mix up two projects because they sound similar, she says. “Or, working on manufacturing solutions, it might not recognize the physical constraints of a system and will try to optimize and do something that a machine can’t do.”

Or two people might have a different understanding of an issue, and there might not even be an objective truth.

“You need to know where the interpretations are going to be made because there’s not enough information,” she says. “If we can identify this, we can trigger clarification questions. If I get a description from a customer, I might have a different view of it than you.” Solving the problem could involve additional conversations with the sales team, or double-checking with the original sources.

These data quality issues need to be considered early, says Jon Knisley,

director of AI value management at ABBYY.

“It’s really easy to run a pilot when it’s not in production,” he says. “But when you try to move it there, you get data issues. Where is the data coming from, and what’s the risk component?”

That’s also when the governance problems arise, as well as other challenges. These are all fundamentals that companies needed to learn in the previous era of automation and RPA, he says, since we’ve seen this technology cycle before.

4. Respecting change management

The biggest thing being forgotten about is change management, says Knisley.

“An AI project isn’t going to fail because of the model,” he says. “It’ll fail based on people and process. And there’s not that balance yet between the technology, people, and the process. Especially in North America, we want to solve every problem with technology. And that’s just not how the world operates.”

Back in 2019, according to a Forrester survey conducted on behalf of UiPath, 82% of respondents said change management was a challenge for RPA deployments. The same is true today. In a recent Kyndryl survey of over 1,100 business leaders, the speed of AI has outpaced workforce, governance, and operating models for 79% of organizations, and only 9% of organizations have implemented change management, redesigned roles around AI, and built workforce readiness.

“The biggest challenge we had in any digital transformation — and still have — is change management,” says Rahul Chhabra, director of applied AI at Herbert Smith Freehills Kramer, a leading global law firm.

And it’s gotten harder. With AI in particular, the technology is evolving so fast that change management is a quickly moving target.

“With RPA, it was sort of simple,” Chhabra says. “We had frameworks we could use to train people. We still have those learnings, but we have to enhance those processes.”

Something that works today might no longer work tomorrow, either. “You have to constantly iterate,” he adds. “What has worked can fail fast and only work in modules. So don’t try to solve the entire problem in one go.”

And employees don’t just have to keep learning new skills and adapting their work processes. Knowledge workers in particular also have to face the constant fear that AI will make them irrelevant. It doesn’t help when AI leaders amplify these fears. For example, Dario Amodei, CEO of Anthropic, predicted that AI will be capable of doing most or all jobs, not just entry level, in less than five years.

“Today, if lawyers do 10 tasks, maybe four of them will become obsolete,” says Chhabra. But that doesn’t mean four out of every 10 lawyers will be laid off. Even if most of the work is automated, Chhabra adds, there’ll be more for lawyers to do, not less.

“Today, a litigation matter might be worth $1 million,” he says. “But if it’s just $150,000, then a lot more matters are brought forward. So there’s going to be an increase in litigation and, therefore, more work for lawyers.”

RPA isn’t dead

So is RPA over? RPA wasn’t smart, says Traci Gusher, data and analytics leader at EY Americas. “It was useful, but it wasn’t intelligent. You couldn’t rewrite the process with RPA because it wasn’t technologically advanced enough.”

So, about 15 years ago, during the big RPA wave, organizations looked for ways to use RPA inside their processes, but the benefits were extremely limited.

“It was never so demonstrative that it would catch investors’ eyes,” she says. “It never got to that level of impact.”

Today, many companies are making the same mistakes with AI, she says. Instead of adding AI to existing processes, they need to rebuild them from scratch. “If you’re chunking it, you’re not going to get the results you want because it’s too small and incremental. That’s why I think over a period of time, RPA died a slow death.”

But AI can actually bring RPA back to relevance, she adds.

“There’s still very much a place for RPA in the AI wave,” she says. “You can use RPA for tasks and transaction-level activities, and integrate with agents. That might be the most cost-effective way.”

Unlike agentic AI, RPA is deterministic and completely predictable, it can run on-prem without leaking any sensitive data, and it incurs no token costs.

“We’ve seen consultants say we need to do this with agentic AI,” says ABBYY’s Knisley. “And they don’t have any reliability or governance. What they’re ultimately trying to do they could’ve done with regex for a tenth of the price, and 10 times the efficiency. You’ve got to figure out when you need to use agentic, script, or regex.”

So instead of throwing out RPA and going all-in on agentic AI, many companies are taking a more nuanced approach, using traditional RPA for processes that don’t require intelligence. Meanwhile, they use AI to help set up, test, manage, and upgrade the RPA, getting the best of both worlds.

“I think RPA is a very powerful technology and it has a place in the world today,” says Chhabra. “Especially on things that need to be deterministic, or you’re automating high risk or compliance workloads. You can mask the PII, but it’s still a risk to the company, so I’d rather use a script or some form of RPA automation.”

And a lot of governance will be rules-based, he adds, or based on RPA.

“There’s a lot of marketing speak that RPA is dead,” he says. “I don’t think that. Even the AI vendors are using RPA in the back, but now they’re calling it workflow automation.”

Most enterprises are rushing toward autonomous AI. They shouldn’t. Autonomy you haven’t earned doesn’t speed you up. In fact, it slows you down.

Here’s what I’ve moved our organization toward: a five-stage set of AI adoption maturity benchmarks. It’s a practical framework for understanding where employee development, decision-making and business value intersect. Each stage provides value for your organization. Some roles and functions may only ever reach Stage 1 or 2, while others should be fast-tracked to Stage 5. By understanding this progression, leadership can stop viewing AI as a tool for task delegation and treat it as a catalyst for developing stronger, more decisive and more valuable teams.

Stage 1: Research assistance

You hand people a premium ChatGPT account. Employees stop Googling and start prompting. Their experience improves: no ads, paragraph-form answers instead of blue links. But the underlying dynamic hasn’t changed. Output quality depends on input quality. A vague Google search returns a mess of links. A vague ChatGPT prompt returns a well-formatted mess of paragraphs. If your team didn’t know how to ask a precise question before, they still don’t.
           
The real danger at Stage 1 isn’t the bad answers – it’s the confident-sounding ones. A hallucinated statistic arrives in the same calm, authoritative prose as an accurate one. Teams that don’t verify sources in Google don’t suddenly fact-check ChatGPT. Before moving to Stage 2, your team needs to develop the instinct to ask, “How do I know this is true?”

Stage 2: Task assistance

The next stage uses AI tools to complete tasks. It starts simply: “I need to write this email,” or “Make a spreadsheet to track open items.”

The average employee takes what AI produces and passes it off without revision. At best, their efforts pass muster, with only a dash of workslop. At worst, the flood of unchecked AI outputs creates rework for teammates and clients.

Another employee further along in Stage 2 may augment what AI produces. That impulse serves them well. But if they default to editing AI output rather than dictating the rules for what AI should produce, they can easily spend more time editing AI’s work than creating work from scratch.

For employees whose work will largely remain in Stage 2, the focus should be on writing more precise prompts. The instinct to edit AI output isn’t wrong. The problem arises when the prompt is a rough starting point rather than a detailed spec. AI cares that your instructions are clear, specific and unambiguous. Get the spec right up front.

Stage 3: Workflow integration

My daughter’s class recently had an assignment: write a paper on the causes of the Civil War.

Her teacher knew what was going to happen. Every 11-year-old would go home and use ChatGPT to write a five-paragraph essay. So, she changed the exercise. The class generated and printed out the essay. Then, the teacher explained how to annotate, how to ask follow-up questions and how to revise in ChatGPT using the marked-up draft.

The same three-step sequence — assemble context, build the prompt, edit hard — applies when someone writes a post-mortem. The temptation is to skip straight to the draft. Pull the incident data, ask Gemini for a timeline and root cause analysis, clean it up, get a quick peer review and send it.

An engineer working at Stage 3 does what the teacher did. First, they assemble context: the Slack thread where someone flagged the anomaly two hours before the alert fired, the Jira ticket, the gap in monitoring that nobody documented. Then they build a prompt that reflects the full context and generate a draft. Now the red pen comes out: push back on the root cause analysis, add the institutional context Gemini couldn’t know, tighten the remediation steps until they’re actionable.

The result is a better document — and an engineer who understands what failed and builds a better repeatable process. Saving time on a first draft is a fine side effect. The goal is to produce a final draft that’s worthy of review.

Stage 4: Guided automation

The fourth stage is where collaboration becomes self-sustaining. You’re no longer asking AI to help you do a task. You’re asking it to run the task and surface the decisions that require your judgment.

My LinkedIn workflow is a good example of what this looks like in practice.

A couple of years ago, I would read an article, develop a point of view, write two or three paragraphs and publish. Not bad, but dependent on me having the time and cognitive bandwidth.

The friction was the 15 decisions that came before drafting: Which angle is worth pursuing? Does this use my voice? Have I said this before?

So, I started researching my patterns. First, I fed Claude my prior LinkedIn posts and prompted it to analyze my tone, sentence patterns and structural habits. I didn’t ask it to “describe my voice” – that gets you a paragraph of flattering generalities. This analysis became the base layer of the tool.

Then I added a second layer: LinkedIn-specific rules and AI writing patterns to avoid. That context got embedded alongside the voice analysis.

Now the workflow runs like this. I click a link, save the article, highlight and annotate the sections that interest me. My Claude Managed Agent picks up the annotation, infers what I found worth engaging with and writes four drafts with meaningfully different angles on the source material. It compares each draft against my post history and proposes two. I read the proposals, pick one, edit and authorize publication with Buffer.

The automation didn’t remove my judgment from the process. It freed me from work that didn’t depend on judgment. Now I do the work that matters: deciding what to say, identifying patterns and sharing my point of view.

That shift in what I’m accountable for is where the ROI changes. The value isn’t in the time saved on any single post. It’s that the workflow no longer depends on me having the bandwidth to start from zero. The capacity was always there; the system makes it consistent and repeatable.

Stage 5: Full automation

The most advanced stage of maturity is when the system largely runs on its own. You’re no longer managing step-by-step actions; you’re defining goals, setting guardrails and measuring outcomes.

We have one running in our engineering org right now. When a ticket gets escalated from our support team to engineering, the agent triages it and routes it to the team responsible for the fix. When an engineering manager reassigns the ticket – because the routing was wrong – the agent picks up that correction, feeds it back into its prompt tooling and updates its model of who owns what. We’re now extending it further: the agent is learning which parts of the codebase need to change and which engineers are likely to own the fix.

There’s a critical catch: this stage only works if you’ve earned your way there. We learned this firsthand. When we first rolled out the routing agent, we used a static map of application areas to engineering teams and assumed that was enough. It wasn’t. We couldn’t reliably distinguish front-end bugs from back-end ones, so the front-end team kept getting tickets caused by a misbehaving API. Features were split between teams in ways the map didn’t capture — one team owned exports, another owned reports. Before the routing could work, the knowledge had to exist somewhere it could be used. An autonomous system is only as good as the foundation beneath it – the clarity of your workflows, the health of your data, the alignment of your teams. Deploy an autonomous agent into a broken process and you get bad results at scale. You cannot safely delegate what you don’t fully understand.

This is why racing straight to Stage 5 often fails. You need to know what “good” output looks like (Stages 2 and 3) and how to orchestrate the pieces (Stage 4) before you can confidently take your hands off the wheel.

Where business value emerges

The evolution from a premium search engine to an autonomous system is an organizational challenge, not a technology one. Realizing the value of AI is determined not by the sophistication of the underlying model, but by the maturity of the team wielding it.

The practical move isn’t to audit your whole organization’s AI readiness. Start with one workflow. Push it one stage higher. Measure what changes. That’s how you find out if this matters in your specific context – not in theory, but in the work your team actually does.

Over the past decade, I have worked through multiple technology transitions, from virtualization and cloud adoption to containers and large-scale automation. Each changed how enterprise IT operated, but they all shared one characteristic: production systems still behaved in broadly predictable ways. AI is the first shift I have seen that changes the behavior of production itself.

In the infrastructure environments I have worked with, production has always depended on a few basic assumptions. Workloads are tied to applications. Applications have owners. Traffic patterns are reasonably predictable. Change windows are planned. Incident response starts with a known service, a known dependency or a known user action.

AI agents challenge each one of those assumptions.

An AI agent may initiate work without a human clicking a button. It may call APIs at machine speed, move across systems to complete a task, retry failed actions aggressively or generate unusual traffic patterns that look nothing like a traditional application flow. The individual action may be legitimate, but the operational behavior is different.

That is the shift CIOs should pay attention to. The question is not only whether AI can be useful in enterprise operations. The harder question is whether production environments are ready for AI-driven activity that behaves less like an application and more like an autonomous participant in the enterprise.

Production was built around predictable workloads

For years, production operations have been built around patterns that are easier to manage because they are relatively stable. A user logs in. An application receives a request. A service calls another service. Monitoring tools evaluate latency, errors, saturation and availability. Incident teams look for deviations from known baselines.

This model worked because most production systems had a recognizable shape. Even in complex environments, teams could usually identify the application owner, the expected request flow, the normal volume range and the rollback path when something failed.

AI workloads do not always behave that way. A single agent completing a business task may generate a burst of API calls, invoke several backend services, open and close sessions quickly and repeat requests in a pattern that looks abnormal when compared with human activity. From a traditional monitoring perspective, this can look like abuse, instability or an integration defect even when the agent is doing exactly what it was asked to do.

The opposite problem is just as serious. If teams relax controls broadly to avoid blocking legitimate AI activity, they may also create room for real abuse to hide inside higher-volume machine traffic. That is not a model issue. It is an operational assumption issue.

The NIST AI Risk Management Framework emphasizes that AI risk must be understood across the full lifecycle of AI systems, including design, deployment, use and evaluation. For CIOs, that lifecycle needs to include production operations, not just model selection or application launch.

In practice, this means AI cannot be treated as a normal application feature once it begins triggering workflows, touching data, generating traffic or interacting with operational systems. It becomes part of the production environment. That requires a different level of readiness.

I have seen similar transitions before with cloud and automation. The first wave is usually tool-focused. Teams ask what the technology can do. The second wave is operational. Teams discover what the technology changes. AI is entering that second phase now.

AI changes incident response and observability

When production breaks, teams need to answer a few basic questions quickly. What changed? What system is affected? What users are impacted? Which dependency is failing? Can we roll back safely?

AI makes those questions harder because the cause of an incident may not be a code deployment, infrastructure outage or human-initiated workflow. It may be an agent making a decision that is technically allowed but operationally unexpected.

For example, an AI-enabled support workflow might retry a failed backend request repeatedly because it is trying to complete a customer task. A human operator may have stopped after one or two failures. The agent may continue until it exhausts a threshold, creates noise across monitoring systems or triggers downstream rate limits. The failure is not that the agent is malicious. The failure is that production systems were not designed to interpret that behavior correctly.

This is where observability becomes critical. Traditional dashboards may show traffic growth, error spikes or latency changes, but they may not explain whether the behavior came from a user, application, script, automation job or AI agent. If those categories are not visible, incident response teams are forced to guess.

Google’s Site Reliability Engineering guidance on monitoring distributed systems is useful because it frames monitoring around symptoms that require action, not just raw system signals. That distinction becomes even more important when AI-driven workflows introduce new behaviors into production.

CIOs should expect AI to change what good observability means. It is no longer enough to monitor infrastructure health and application performance. Teams also need visibility into AI-initiated actions, agent-driven traffic patterns, tool usage, retries, failed task loops and dependency chains.

The operational question becomes simple: when an AI system causes a production symptom, can the organization trace the action from the agent to the service to the business impact? If the answer is no, AI is already ahead of the operating model.

The CNCF observability whitepaper describes observability as a way to understand complex system behavior from external outputs. That idea applies directly here: AI-driven systems will require observability that explains behavior across workflows, not just infrastructure components.

Production readiness needs to change before AI scales

The mistake many organizations make is preparing AI for production without preparing production for AI.

“The mistake many organizations make is preparing AI for production without preparing production for AI.”

A pilot can succeed with limited users, narrow workflows and close supervision. Production is different. Production introduces volume, concurrency, exceptions, outages, retries, partial failures, support queues and business pressure. AI agents will encounter all of that, and they will do so at a speed that traditional operational processes may not be ready to absorb.

This is why CIOs should treat AI readiness as a production discipline. Before scaling AI-enabled workflows, teams should define what normal AI activity looks like, what abnormal behavior looks like and what evidence is required to troubleshoot the difference. They should know which systems an agent can touch, how agent traffic is labeled, how rate limits apply, how errors are escalated and how failed workflows are stopped.

This is not about slowing AI adoption. It is about preventing production from becoming the testing ground for assumptions that were never validated.

The 2024 DORA Accelerate State of DevOps Report noted that AI can improve individual productivity while also creating tradeoffs for delivery stability and throughput. That is a useful warning for CIOs: productivity gains do not automatically translate into operational maturity.

The organizations that will handle this transition well will not be the ones that simply deploy the most AI tools. They will be the ones that adjust production operations early. That means treating AI activity as something to be observed, tested, limited, measured and supported like any other production workload, but with the added recognition that it may behave differently from traditional software.

Capacity planning will also need to change. AI workflows may create irregular demand patterns, especially when agents run multi-step tasks across internal systems. A workload that looks small in a pilot can create meaningful load when hundreds or thousands of users trigger agents throughout the day. The cost impact may appear in compute, API calls, storage, logs, monitoring systems or downstream service usage.

Change management will need to account for model behavior, prompt updates, tool integrations and workflow changes. A small update to an agent’s instructions may alter how it calls systems, how often it retries, which APIs it uses or how it handles exceptions. In production, that is not merely a content update. It is an operational change.

Rollback planning will also need to evolve because reverting an AI-enabled workflow may involve more than restoring application code. It may require disabling agent actions, reverting prompts or temporarily removing tool integrations while preserving business continuity.

Incident response will need clearer playbooks. Teams should know how to pause an agent, isolate a workflow, disable a tool integration, reduce task volume or route activity back to human handling when production behavior becomes unsafe or unstable.

The larger point is that AI is not just entering the enterprise as another user-facing capability. It is entering the operating fabric of the enterprise. That makes it a CIO concern, not only an AI team concern.

Every major technology shift eventually becomes an operational discipline rather than a technology project. AI is reaching that point now. Organizations that recognize this early will be better positioned to scale AI with confidence instead of discovering its operational consequences through production incidents. The next challenge for CIOs is not deploying AI. It is preparing production environments for how AI actually behaves.

AI agents are performing roughly 1 in 3 actions in enterprise IT workflows (but that share is rising quickly), while human analysts are rejecting about one-quarter of AI-proposed actions (but that rate is falling), according to a new study of tens of thousands of human-AI interactions. Operational data, rather than underlying AI infrastructures, is often the culprit when things go wrong.

Human analysts are approving the most consequential actions, managing exceptions, and supervising and shaping agentic systems, while AI agents are carrying out routine tasks and executions, automation platform provider Fixify found in the study.

“That may sound less dramatic than replacing the help desk,” Matt Peters, Fixify’s co-founder and CEO, wrote in a blog post. “It’s also a much more credible path to changing how IT work gets done.”

Building scaffolding

Fixify identified four steps of agentic work: Planning, proposing, approving or declining, then acting on approved steps.

It analyzed nearly 18,000 plans and over 147,000 actions executed by agents across 40 companies over a three-month period, finding that agents are taking over one-third of IT actions, most notably in software, applications, security, and collaboration work where requests tend to be “repeatable and easy to reverse.”

Tasks that are well understood and that present low risk are best suited for the current generation of agents, Peters wrote. Human analysts remain closely involved in higher-stakes areas like identity verification, setting up and removing IT access (onboarding and offboarding), and hardware environments.

However, AI’s share of the work is increasing as feedback loops improve: Over the three-month period, human approval of AI-proposed actions rose from 23% to 41%, and rejection fell from 27% to 16%, Fixify found.

The company identified six types of actions in AI automation. Running a skill — actually doing something — accounted for 39.4% of all actions). Most of the rest were coordination: sending a message to the human requester (27.7% of actions), leaving an initial comment (13.2%), giving instructions to a human analyst (9.8%), or waiting (8.8%). Running entire workflows accounted for just 1.1% of actions.

AI is building “scaffolding” that wraps around meaningful changes, often planning far more scenarios than the agent will execute. Typically, agents map out 15 possible actions but run only two, Fixify said.

“The agent maps the paths a request could take, then walks down the path that makes the most sense as it meets reality,” the study said.

Peters pointed to one example where an AI agent identified which team needed access to process a high-volume type of ticket. Rather than fully automating the process, the agent did the initial triage, asked questions, then routed tickets to the team that had the information to act immediately.

“We didn’t need a world-ending hive mind,” he said. “We just needed to point a little conversational intelligence in the right direction.”

When AI breaks down

IT automation typically involves analyzing tickets and moving them along; in other words, low-risk tasks.

But agents do participate in areas like security (albeit only about 6%), most notably adding and removing people from groups or channels, unlocking accounts, resetting passwords, analyzing multi-factor authentication (MFA), provisioning (or deprovisioning) accounts, and assigning software licenses.

However, this identity-lifecycle work is where agents failed the most, particularly in onboarding and offboarding and identity-access management (IAM), the study found. “Hardware and connectivity changes rarely fail; identity-lifecycle changes fail three-to-nine times as often.”

Why AI breaks down

Thanks to human-in-the-loop controls, Fixify was able to analyze scenarios where agent recommendation diverged from human judgment. This occurred about 23% of the time.

The largest failure category (nearly 50%) was ‘target not found,’ meaning the agent couldn’t uncover what it needed. This typically comes down to poor data: A user, group, account, or resource was not where the system expected it to be. When people change teams, groups are restructured, accounts are renamed, or work has already been done but not reflected in the system, this is more of an identity hygiene problem than an AI problem. The system needs cleaner and more current data.

Invalid inputs accounted for around 29% of failures, followed by unhandled errors, denied permissions, or invalid operations or configurations. The latter signal “real breakage” in integrations, according to Fixify.

AI becomes more sophisticated over time

The good news is that AI automation improves over time, even if it might take a while. In hybrid systems, humans keep the most consequential changes under their own control, and iterative rejection and approval helps AI learn.

Over time, agents’ plans get leaner and they start to re-plan when conditions change, rather than pre-planning all kinds of scenarios that may never occur. “That’s a sign of sophistication,” the study said. “Adapting in the moment is a more advanced behavior than trying to pre-script every contingency.”

In turn, humans second guess the system less often and feel comfortable handing off more work. Instead, they control how agents behave, make high-impact decisions, and handle exceptions. “The hardest requests remain human-heavy, especially those that require repeated replanning or contextual judgment,” the study said.

How teams can adapt to AI agents

As agentic AI becomes embedded in more workflows — and at deeper levels — enterprises must evolve to accommodate, Fixify emphasized.

This means investing in clean identity data and building strong playbooks, review workflows, and reliable integrations.

Teams should judge agentic tools by their supervision loop and view rejections as a training process, Fixify advised. Analyst time, queues, and metrics should be built around reviewing proposals. Agent replanning can be seen as a routing signal: A single replan might indicate healthy adaptation, while repeated replanning means ambiguity, irrelevance, or unclear policies.

“Make the review surface easy to understand so analysts can assess proposed actions and make quick decisions about how to proceed,” the study advised. “This is where the analyst’s attention belongs.”

This article first appeared on Computerworld.

Projects are becoming more complex, with higher stakes and faster delivery times.

At the same time automation and AI are changing how projects are designed, managed, and delivered. Indeed, some pieces of project management are now routinely handled by machines.

Some may think that AI and automation will make project managers obsolete, or at least less critical to project success. Executives say that’s not the case. Project managers are as important now as they ever were to project success.

“As we move forward, the role of project manager is actually becoming increasingly important for finding the right things to invest in, defining scope, and staying focused on value,” says Noah Fletcher, a partner in the operations excellence practice at consultancy West Monroe. “As we continue to accelerate, their value is really about quality — quality of what you’re trying to accomplish.”

That doesn’t mean that the role of project manager is static. Rather, the role is evolving, with what it takes to be successful is changing to meet the needs of the moment.

To thrive, project managers need to hone a complex combination of technical, business, and interpersonal skills. The Project Management Institute attempts to decode what it takes to be a successful project manager with its PMI Talent Triangle, comprising Ways of Working, Power Skills, and Business Acumen.

Not surprisingly, there’s a lot packed into those three areas. Effective project managers must know how to define the scope of a project, identify necessary resources, and schedule those resources — all part of the technical aspect of the job. They must also manage stakeholders and ensure projects align with business goals — skills that fall under the other two talent buckets.

As lengthy as the PMI’s list of required skills is, experienced project leaders say that’s not enough to rise to the top of the profession; highly effective project managers today bring even more to their jobs.

They’re curious, flexible, and adaptive — and they learn from and know how to right their mistakes. They’re empathetic, persuasive, and visionary. They know how to play to their own and others’ strengths.

Leading project professionals say the most successful PMs are those who know the academic parts of the job — that is, the elements that are taught — but they also bring finesse to the work.

So, what characteristics distinguish the most effective project managers? Longtime project leaders list the following key traits and skills as vital to succeeding at a high level.

1. They serve as a strategic business partner

Top-level project managers are more than good managers. They have high-level strategic leadership skills and know how their projects fit within overall strategic goals, making them well equipped to make the right decisions for the project and the organization as a whole.

“A project exists because it responds to a need of the business. That might be due to trends impacting the business or a challenge in running the business, but without understanding that, it will be hard for the project manager to deliver a successful project,” says Karla Eidem, a Project Management Professional (PMP) and PMI’s global head of transformation and project delivery.

2. They know the business

The most effective project managers aren’t just great leaders; they’re also business-savvy.

“They understand strategy and business context,” Fletcher says. As they deal with shifting resources and changing market dynamics that happen during many projects, they focus on what work will bring business value — not merely what will tick off items on a task list. “That ability to work on the right thing is one of the most important things that a project manager can have,” Fletcher adds.

3. They’re strong technologists

Projects today nearly always involve technology, making it essential to have technology skills. But standout project managers are true technologists, too.

“Increasingly IT is touching so many different area, and we’re seeing systems and architecture getting more connected, so understanding how business and operations fit together is critical,” Fletcher says.

4. They’re financially astute

Project management always involved budget management, but the task today requires more than balancing the books. It also involves understanding how projects and the core components of any given initiative bring value to the business. That takes financial acumen and the ability to make smart decisions during project execution to ensure the business sees returns on its investment.

“The best project managers know the business drivers and can get depth on how the project impacts the business financially,” Fletcher says. “They have a good value management framework, that end-to-end process that can take the business case all the way through.”

5. They possess extraordinary organizational skills

Top-notch project managers are highly organized individuals. But it’s not just about making a list and sticking with it. They understand how project plans and resources are intertwined with other goings-on within the organization. That organizational capacity enables them to adjust their plans and resources when needed.

Lenka Pincot, chief of staff to the CEO at PMI, says today’s top-notch project managers are “orchestrators” who can pull together the complex components of modern projects and get them to work in harmony.

“Organizations need orchestrators who can synchronize all the changes happening so the results all make sense,” she says. She notes that orchestration takes systems thinking as well as the ability to identify and plan for unintended consequences.

6. They’re problem-solvers

The best project managers are good at delving into and solving for the “why” behind projects.

“They enjoy problem-solving,” Pincot says. “[As project managers], we’re not handed projects; we are handed problems to solve. So we need to get to the bottom of what’s not working. We need to ask questions and really listen for what someone’s true interests are.”

7. They thrive in fast-paced environments

Executives constantly talk about the speed of change today. Teams must work fast to keep up with shifting technology and business contexts, and project managers must be able to facilitate that, Fletcher says.

“The ability to quickly identify the right tools, assign the right resources, accelerate testing, and to move things forward fast without compromising quality is a huge thing today,” he adds.

8. They are flexible

Similarly, highly effective project managers are flexible, so they themselves aren’t flummoxed when project plans need adjustments — something that happens increasingly more often in the modern digital world.

“Adaptability is huge,” says Krista Phillips, a PMP holder and project management consultant. “Things are always going to change, priorities adjust, resources adjust, timelines change. Project managers must be able to successfully manage all that.”

9. They are persuasive

Project managers typically manage teams but aren’t the boss of any of them, meaning they must be capable of leading and workers without having to lean on any official authority, explains Julie Butcher, a fractional CIO work and transformation principal consultant with Butte Information Group. The best project managers are masters of this skill.

10. They have ‘extreme awareness’

Barry Cousins, a distinguished analyst and research fellow specializing in project portfolio management, project management, and organizational change management at Info-Tech Research Group, says top project managers possess what he calls “extreme awareness of resource capacity and utilization.”

“Savvy project managers in the modern era have immediate implicit awareness of the capacity around them, so then they’re going to know right off the bat when their projects are going to fall short,” Cousin adds. Furthermore, they’re more comfortable alerting business leaders to that situation because they’re able to quantify the shortfall.

Others agree, saying this all speaks to the need for project managers to have strong emotional intelligence.

11. They have highly tuned stakeholder management skills

Project managers work with numerous stakeholders from various departments within and outside their organizations, and those who manage those relationships best understand each stakeholder’s perspectives, say Te Wu, CEO and chief project officer at PMO Advisory.

Wu adds that stakeholders can now also include AI agents.

For example, some stakeholders may be more risk adverse than others, or more resistant to change, or more prone to panic when problems arise.

Veteran project leaders say managers who can identify and empathize with those perspectives can tailor their communications, plans, and training to address each stakeholder’s unique points of view.

12. They understand who has authority

Organizations today have distributed authority, so project managers must know who has say over what pieces — whether they’re dealing with 10 IT architects who each control a piece of the IT environment or 10 executives who have responsibilities for separate areas of the enterprise impacted by a project.

“The savvy project manager knows to give them all room to succeed,” Cousins explains. That means staying on top of what each person’s realm of authority needs for the project to succeed, identifying who has ownership for what pieces, and knowing which person has true authority and can get others to line up behind him or her.

“It often requires getting to know people who are at a layer of the company that you don’t play in,” Cousins says.

13. They can navigate office politics

In addition to being good at stakeholder management, elite project managers also know how to navigate office politics. That means navigating not only individual stakeholder’s needs and expectations but also understanding how those stakeholders interact with each other, who has influence over the others, and who has power to override the authority of others.

“They know when to apply what type of pressure to get something accomplished,” Wu adds.

14. They’re decisive

Given the speed, complexity and fluidity of project work today, project managers must be critical thinkers and decisive decision-makers. Otherwise, they risk falling into analysis-paralysis and bringing work to a halt.

Varun Bijlani, global managing partner for solutions and delivery at IBM Consulting, says the best project managers can confidently and consistently make good calls even in the face of ambiguity.

“IT projects are rife with it, even though everyone walks in expecting full clarity and specificity: requirements shift, priorities compete, expectations are unclear, unplanned technical issues arise,” he says. “AI can surface options and synthesize information fast, but it can’t apply the contextual judgment, reasoning, and organizational awareness needed to weigh trade-offs and commit to a direction when the path isn’t clear. That’s still a human call.”

15. They communicate effectively

Considering communication plays a significant role in managing projects, teams, and other stakeholders, it is one of the essential skills for effective project managers, according to longtime project managers.

Communication doesn’t just mean being a stellar facilitator, speaker, or writer; it requires good listening skills, too. As such, top managers actively listen to what’s said — and not said — and can take context into account.

These skills enable project managers to synthesize information and then clearly and concisely sharing that information back with all those involved, Pincot explains.

“They have to be able to translate business needs to technology teams and explain how technology creates value for the business so that everyone can understand and trust that information,” she adds.

16. They build community

“I believe the ‘P’ in PM is for the people: You can’t do a project without a team. And the team might not report to the project manager, so you have to have collaborative leadership, problem-solving, and communication skills to activate your team. Without that you can’t really move the needle,” Eidem says. “But in a project, you’re working with people who might have different priorities and different understanding of the goals of the project, so it’s the project manager’s responsibility to make sure everyone is aligned and knows where they’re going.”

Butcher agrees, saying that the best project managers know how to build a sense of community among the teams as well as with the workers on the periphery of projects so that everyone is willing to work toward a shared objective.

17. They build rapport

Top project managers are also skilled at developing strong rapport with those around them — even for short-lived projects — knowing that good connections and solid relationships lead to success.

“When you build rapport, there’s a shared understanding,” Phillips says. That shared understanding pays dividends. Project managers who take time to build up relationships are more likely to have others share information that could impact their projects, and they’re more likely to get help from others if they make difficult requests — such as staying late or coming in on a weekend to catch up.

18. They’re confident leaders

According to Wu, effective project managers must possess confidence.

“They have a can-do attitude, and that attitude needs to be a bit infectious,” he says. “They don’t have the be cheerleaders, but they do have to have a mindset that sees what’s possible and not just the issues and what’s at risk.”

That allows them to present an optimistic attitude that can propel teams forward even during difficult stretches, Butcher adds. Project managers who possess such confidence are those with a track record of success and are competent in foundational project management skills such as planning and team-building, she says.

19. They serve as change agents

Change is inevitable and can be highly disruptive to all areas of business and personal life; project management is no exception. Highly effective project managers understand this, embrace it, and build elements of uncertainty into their project plans. They also recognize the need to work closely with change management experts to help stakeholders adapt to change and better prepare for the future state of things.

20. They possess an even-keeled demeanor

Even well-planned projects run into problems, and even highly skilled project managers can hit significant setbacks. But the best project managers don’t display panic, anger, or despair even under pressure; they keep their cool.

“Projects can create a lot of pressure, and there can be seemingly conflicting priorities, so staying calm is an essential trait for project managers,” Pincot says.

More on project management:

• Top 20 project management methodologies
• Project management guide: Tips, strategies, best practices
• What is a project manager? The lead role for project success
• Top 15 project management certifications
• 7 must-have project management skills

A few weeks ago, I found myself in yet another demonstration of an application that was not built by my team or my technology partners. The demonstration lasted 20 minutes and by the end of it, everyone in the room agreed that the application solved a genuine business problem. There was genuine admiration for the business team’s initiative, a few questions about future enhancements and the inevitable congratulations that accompany any successful AI story. Then somebody asked, almost casually, “Can IT roll this out quickly across the organization?” It was a short question that unfortunately needed a long and unpopular answer.

I am sure almost every technology leader reading this has experienced some variation of this moment. The application itself is rarely the problem. In fact, many of the applications I’ve seen over the past year have been remarkably good. What concerns me most is something rather different. Somewhere along the way, we’ve started confusing the act of building software with the responsibility of running it. AI has dramatically reduced the effort required to create an application, but it has done little to reduce the effort required to own and operate one sustainably.

That distinction may sound subtle, but it is not. I think this might be one of the most significant leadership challenges of the AI era.

The success nobody planned for

None of this should come as a surprise. For years, we have been telling the business to become more digitally savvy. We invested in low-code platforms and citizen development initiatives, organised hackathons and innovation challenges, and repeatedly argued that technology shouldn’t become a bottleneck to solving business problems. The rapid emergence of AI coding assistants has simply completed that journey. Today, anybody from finance, marketing or operations can turn an idea into a working application faster than most technology teams can schedule a requirements workshop.

Personally, I think that’s amazing. Some of the most interesting ideas I’ve seen this year didn’t emerge from tech teams. They came from people who understood the business problem intimately and no longer needed permission to begin experimenting. That’s a future I would much rather embrace than resist.

The problem isn’t that business teams are building software. The problem is that successful prototypes have a habit of raising enterprise expectations quickly. Yesterday it was a departmental experiment. Today it is being demonstrated to the executive committee. Tomorrow someone is asking why the rest of the organization isn’t using it. The application hasn’t changed; the expectation has. In many ways, this feels like the next evolution of what we’ve traditionally called shadow IT. The difference is that these applications are often better engineered, solve genuine business problems and, ironically, are being built with the very experimentation that technology leaders have spent years encouraging.

The thin line between building and running

This is the point where discussions between business leaders and technology leaders begin to fall apart. The business sees an application that works. Technology sees an application that now needs to survive outside the protected environment in which it was created. Those are fundamentally different things.

A prototype rarely worries about things like identity management, resilience, audit trails, backup policies, API versioning, support models or regulatory obligations because none of those questions matter while an idea is still being tested. However, they become important once the organization decides that the application has graduated from an experiment to an enterprise capability. In many ways, this is the point where software engineering gives way to software operations—a discipline that organizations like Google have spent years formalising through practices such as Site Reliability Engineering (SRE).

This is the point where many organizations are beginning to underestimate the challenge. AI has democratised software development. It has not democratised enterprise operations. Running software is an entirely different discipline. It is less visible, less celebrated and considerably less exciting than building it, but it is also the reason enterprise technology exists. Every application that enters production quietly accumulates obligations. Someone has to secure it. Someone has to integrate it. Someone has to monitor it, patch it, support it and explain it to an auditor. Eventually, someone has to retire it. None of those responsibilities disappear simply because the first version happened to be created in forty-eight hours using an AI.

Walking the tightrope

The temptation for technology functions is to respond in one of two ways. The first is to become the organization’s brake pedal. Every application must now navigate governance committees, architecture reviews, security assessments and operational checklists before it is allowed anywhere near production. The enterprise is undoubtedly safer, but enthusiasm evaporates quickly when innovation feels like it needs intricate planning and convoluted permissions.

The second temptation is more subtle, and in many ways more dangerous. We become so determined not to discourage innovation that every successful prototype quietly becomes another production application. We congratulate ourselves on enabling the business while gradually accumulating a software estate that nobody really owns or understands. Six months later, the original creator has moved to another project, the AI prompts have disappeared, users have doubled, integrations have multiplied and suddenly the technology team is required to support something it neither designed nor approved.

Neither extreme is sustainable.

This, I suspect, is the balancing act that leadership will increasingly be judged on. Not whether we can prevent people from building software—that battle has already been lost, and rightly so—but whether we can encourage experimentation without allowing enthusiasm to become tomorrow’s operational burden.

I’ve discovered that the tone of these conversations changes entirely if we begin with curiosity instead of governance. Rather than asking why technology wasn’t involved earlier, we now ask what problem the team was trying to solve. It sounds like a small change, but it transforms the discussion. People become far more willing to talk about security, resilience and operational ownership once they know those questions are intended to preserve what they’ve built rather than prevent it from succeeding.

Stewardship, not gatekeeping

Interestingly, this isn’t simply a challenge that individual technology leaders are experiencing. Recent research points in the same direction. The 2025 DORA State of AI-assisted Software Development report concludes that AI acts primarily as an amplifier. It magnifies the strengths of organizations with mature engineering practices and exposes the weaknesses of those without them. In other words, the greatest returns from AI don’t come from the coding tools themselves, but from the quality of the underlying engineering and operational system.

Gartner arrives at a similar conclusion from a different perspective. In its analysis of enterprise AI coding agents, the firm argues that the market is rapidly evolving beyond developer productivity towards operational excellence and enterprise readiness. As organizations begin operationalising AI-generated software at scale, governance, operational ownership and long-term lifecycle considerations become just as important as the tools themselves.

None of this should really surprise us. We’ve spent the last couple of years asking whether AI can help us build software faster. That question has largely been answered. The more interesting question now is whether organizations are prepared for the consequences of making software creation almost frictionless. Every successful application creates an obligation that lasts far longer than the weekend it took to build.

Technology leaders have traditionally thought about technical debt as ageing platforms, deferred upgrades, architectural compromises and code that has outlived its original design. CIO.com has written extensively about the long-term business impact of technical debt. I believe AI is quietly introducing another form of debt that deserves equal attention—operational debt.

Operational debt begins the moment an application is promoted from a successful prototype to a business-critical service without a clearly defined operating model. Every application that is enthusiastically pushed into production quietly becomes another long-term obligation. It needs monitoring, support, ownership, governance, funding, documentation and, eventually, retirement. Unlike technical debt, operational debt is rarely visible until something fails, an audit raises uncomfortable questions or the person who originally built the application has long since moved on.

The role of leaders may no longer be to decide who gets to write software. AI has already democratised that capability. Our responsibility is something altogether more nuanced. We have to preserve the excitement, curiosity and initiative that AI has unlocked across the business while ensuring that the enterprise remains secure, resilient and supportable. Push too hard and we become the one that quietly kills innovation. Push too little and we inherit an estate of applications that nobody is truly prepared to operate.

This isn’t a governance problem. It’s a leadership one…and I suspect it may well become one of the most defining responsibilities of enterprise technology for years to come.

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