AI is writing more code than ever. Software specialist Sonar’s 2026 State of Code Developer Survey, based on more than 1,100 professional developers, found that 72% of those who’ve tried AI coding tools now use them every day, and that today, AI now accounts for 42% of committed code, a number that’s expected to reach 65% by next year.

But while developers embrace AI-enabled coding services, many professionals are uncertain about how their businesses will cope with this influx of AI-generated code. Sonar’s research additionally discovered that 96% of developers don’t fully trust it, and only 48% always verify it before committing.

In fact, 38% of developers told the researchers that reviewing AI code requires more effort than analyzing code written by human colleagues. That’s a pattern recognized by Tim Chilton, a managing geospatial consultant at UK mapping agency Ordnance Survey (OS). “There’s truth in the headlines that AI can get carried away, and developers spend more time fixing the code that’s been created than not,” he says.

While that’s not a pattern he sees at the OS, Chilton says his organization is cautious about how developers use AI coding tools, and conversations with other digital leaders suggest a similar approach. AI-enabled coding is indeed almost ubiquitous, and it can allow developers to reach new, higher levels of productivity, but more doesn’t necessarily mean better code.

To ensure that such coding services produce business benefits, CIOs must take control of the development process. They should exploit agents carefully, set professional responsibilities, and establish guidelines, policies, and organization-wide training.

Exploiting the agents

Snowflake co-founder and president Benoît Dageville suggests there are two ways to view AI-powered coding. One is the scary way, where AI takes over your tasks without human input. The second is the efficient way, where AI helps you do the same things as before, but at a fraction of the cost. He’s a big believer in the latter, both for himself and his teams.

“The route depends on the organization; their application of AI coding depends on their priorities,” he says. “However, I hope that overall, AI will have a positive effect on humans. I’m using AI every day to code, and if I compare myself to one or two years ago versus now, I’m more efficient and productive, but I’m also writing five times more code.”

Steve Lucas, CEO of integration technology specialist Boomi, also notes the increase in output. He quotes research that suggests 4% of GitHub public commits are already being authored by Claude Code. That proportion is expected to rise to 20% of all daily commits by the end of this year. Staff at Boomi already use AI tools to produce more code.

“We’re writing 10 times the amount today than we did two years ago,” says Lucas. The increase in AI-enabled coding is so significant that he’s spoken with Boomi chief product and technology officer Ed Macosky about goals for the proportion of self-modifying code.

“I believe AI should recursively modify 80% of a software organization’s code,” Macosky says. “Infinite improvement is demanded. If AI is extraordinarily good at breaking security protocols, the only way to keep up isn’t the kind of accordion model of human code design. AI use must be linear in scale and continuous.”

Crucially, Lucas suggests using AI to check and modify that AI doesn’t mean coders go away. “In fact, I think we’ll need more engineers, not fewer,” he says. “We need these professional experts to ensure the quality of the code that’s written.”

At OS, Chilton uses Coco, Snowflake’s coding agent. The tool does as much as 90% of a development task that he would otherwise complete from scratch. “It’s taken an hour to finish, instead of weeks or never,” he says, reflecting on the power of AI coding services.

However, the tool’s influence is carefully constrained. The agent doesn’t work in isolation, and Chilton checks its output in detail. He says all organizations need a similar process and should value experienced professionals who can use AI coding tools effectively.

“If you’re giving a tool to someone who isn’t capable of checking an agent’s work, as a digital leader, you run the risk of putting too much faith in AI just running with its output,” he says. “I think that’s a big risk, so there’s still a need for experienced developers.” 

Setting clear responsibilities

While placing humans in the loop can help ensure AI-enabled code is safe and effective, developers shouldn’t be weighed down by their new management responsibilities.

Gill Haus, CIO at Chase, the consumer banking arm of JPMorgan Chase & Co, says AI coding benefits can only be realized when agents are introduced with a strong focus on automating supporting technology and processes, which reduces the need for too much human input.

“If you have 12,000 engineers, they can write 12,000 engineers’ worth of code in a day,” he says. “If those 12,000 engineers have agentic technology, they can write much more. But if you don’t have automation left to right with confidence, you create more manual processes. You can’t move as quickly since there are only so many humans you can put in the middle.”

Haus says Chase never releases services in production that don’t pass its high bar for quality and security. Strong engineering practices, pipelines, and architecture, plus a tried-and-tested approach to automation, can help ensure AI coding produces solid outputs without a burdensome amount of human intervention.

“We’re focused on effective automation so we’re able to unleash this technology safely and effectively,” he says. “This is something many other companies should be focused on if they aren’t already, because otherwise you can’t keep up with the pace of change.”

François-Xavier Pierrel, group chief data and ad tech officer at French TV network TF1, is another digital leader who says maintaining control as AI writes more code means keeping the human in the loop in a clearly defined manner. His team documents agentic processes using Atlassian project management and collaboration tools, such as Confluence.

Pierrel says policy management is crucial as the agentic transformation gathers pace.  One key step is ensuring professionals who use agents conform to internal standards. Smart businesses set policies that state clearly when staff can explore an agent, delegate work to it, or release it in production.

“We don’t have hundreds of agents deployed yet,” he says. “But the moment you reach a certain level of volume, if you don’t have compliance and policies in place, AI becomes a critical mess, and then it can be disruptive in a negative way.”

Building strong foundations

Kirsty Roth, chief operating officer at content and technology specialist Thomson Reuters, agrees digital leaders must be proactive. Her firm’s explorations with models and agents suggest that AI can help with time-intensive coding processes, such as writing. This capability means her organization carefully considers the roles people fulfil.

“In the last 12 months, we’ve put lots of thought into where we’re seeing benefits,” she says. “It’s great AI can do some of the coding work, but what does that mean for people’s jobs? We used to have thousands of engineers. Do we now need more architects or product people?”

Roth refers to security. While cyber is always a priority for Thomson Reuters, the firm dedicates significant resources to controlling threats in the AI age. Developing high-level development and security skills requires a concerted effort. Yet Roth says ensuring people have the right skills to manage AI is in many ways a familiar IT trend.

“All this effort is no different than digital, cloud, mobile, social, or other big tech trends,” she says. “They all take several years to have an impact as the initial hype comes, and then you’ve got to work through the reality and think about how you upskill people for the new world.”

Crucially, coding is no longer the sole preserve of the software developer. AI coding tools make it much easier for non-IT professionals to vibe code applications. Tal Carmi, CIO at technology specialist WalkMe, says non-developers can create useful tools. However, effective outputs rely on a careful balance between enablement and guidance.

He adds that most of these employees don’t need in-depth capabilities, such as a database or a content delivery network. Instead, non-IT staff require a dedicated place to upload their products. WalkMe’s engineering specialists ask key questions to ensure their outputs are safe, considering credentials and potentially problematic packages.

“You need to add guardrails,” he says. “A lot of the work for in-house engineers is shifting from building to testing. The people who aren’t coders don’t necessarily have security in mind.”

The key takeaway, suggests Emmanuel Frenehard, chief digital officer at biopharmaceutical giant Sanofi, is that digital leaders must help professionals feel comfortable. Successful digital leaders ensure the business generates value from agents, and his firm is helping its staff, particularly its developers, to embrace these tools.

“I genuinely worry for professionals who don’t use AI to code, because in five years, they may not have jobs,” he says. “So we’re guiding, coaching, and training them, but people must take the journey. The train has left the station. You can decide to be on it, or just look at it.”

In Foundry’s 2026 State of the CIO survey, 83% of CIOs say their role is becoming more of a hybrid to lead both business and tech initiatives, rather than simply manage IT. As the two become more inseparable, the CIOs who see collaboration as a competitive advantage are putting daylight between them and those who see it as a cursory soft skill. And C-suites are responding as they rely more on IT to drive growth and accelerate efficiencies. So the CIOs who deliver the most value will bring collaboration skills to drive change and technical expertise.

Silos between IT and the business are falling

As the World Economic Forum notes, not every tech initiative requires deep collaboration. But as businesses move beyond routine IT investments into cross-functional, innovation-focused transformations, collaboration becomes essential.

For example, how can IT decisions help an organization open new markets faster, or emerging technologies reduce risk in areas like data privacy. It’s no surprise, then, that Deloitte found that 65% of CIOs reported directly to CEOs in 2025, up from 41% in 2015.

Because tech is now part of almost every business decision, it takes everyone’s expertise and insights — from the CIO to the CFO — to see the full picture of how an initiative will affect the company. Shared knowledge leads to better-informed decisions that give tech its biggest impact.

When silos persist, CIOs struggle to get buy-in for their initiatives. Protiviti’s Global Transformation survey found that while 61% of CIOs report being confident in their tech transformation outcomes, only 34% of CEOs and boards feel the same — and the gap is even wider for AI implementations.

That gap is, at its core, a collaboration problem. Without effective collaboration and communication, others can’t see the value of transformation efforts. CIOs who excel in these areas can more easily demonstrate value, win buy-in and keep their organizations at the forefront of technology.

Delivering speed and innovation

Collaboration goes well beyond getting buy-in. While it may be thought to slow IT down, it actually brings in the insights that make change more effective and faster.

As I’ve highlighted in the past, when organizations move away from rigid data ownership, cross-functional teams can share what drives further innovation.

The same holds across the C-suite. Perspectives from outside IT show CIOs how a tech implementation works for the company as a whole, and where new opportunities lie. That lets CIOs test, refine, and reshape solutions faster.

Most importantly, when teams share a common purpose and goals, everyone stays aligned on the best overall outcome for the business. Iteration happens much quicker because everyone is focused on the big picture rather than individual agendas. With increasingly rapid tech cycles, that speed is a competitive advantage in its own right.

Building your collaborative abilities

For CIOs used to the old way of doing things, shifting to a collaborative mindset can be a challenge. But like any capability, it can be developed and improved by applying some fundamental principles.

Earn trust through follow-through. Trust isn’t built at a kickoff meeting or with a mission statement. It’s built when people see you do what you said you would, again and again. For CIOs, that means delivering on commitments or flagging early when you can’t. Clear and consistent communication is one of the most reliable ways to build trust across an organization.

Make transparency the default, especially when news is bad. Transparency means more than status reports. It means being candid about costs, risks, trade-offs, and setbacks before they surprise anyone. When leaders sidestep difficult discussions, trust erodes and goals drift. And in technology programs, small unspoken issues have a way of becoming expensive ones.

Seek cultural fit in how you work, not who you are. Cultural fit isn’t about sameness or shared backgrounds. It’s about compatibility in management philosophy, values, decision-making, and communication. A CIO who values speed and experimentation, and a CFO who prioritizes predictability and control will clash unless both recognize the difference and agree on how to bridge it. The same is true when it comes to finding the best technology providers.

Focus on the what, not the how. Few things undermine collaboration faster than micromanagement. When leaders dictate how a colleague or partner should work, they signal distrust, stifle creativity and innovation, and tie up their own time policing activities instead of driving results. The better approach is to agree on clearly defined, measurable outcomes, and then step back. Letting go of the how isn’t giving up control but building enough trust that everyone gets there together.

This requires adjusting your workflows and skills, but the payoff is valuable insight from your collaborators and wins that lift the entire organization.

The new life of the CIO

The days when the CIO could simply be the tech expert behind the scenes are long gone. With AI and other technologies ingrained in every aspect of the business, the CIO must lead well beyond IT.

By making collaboration a priority, you can gain critical insights across teams to guide your tech strategy, and deliver the greatest value to your organization.

In Part 1 of this two-part series, I argued that the moat is dry. When NotPetya hit Merck in 2017, it didn’t climb a wall. It came in through trusted vendor software, the routine traffic every perimeter is built to admit, and Merck put the damage at more than $1.4 billion. Its insurers then tried not to pay, and after that fight, underwriters started asking much harder questions.

AI has since made attacks like that cheaper and faster. In IBM’s 2026 Cost of a Data Breach report, one in four malicious breaches was AI-enabled, and breaches that took more than 200 days to find and contain cost about $1.3 million more than those that didn’t. Deepfaked executives, software that can be talked into things and AI agents holding credentials are attacks on trust first and technology second.

Yet the people we hold responsible are set up to lose. Some 64% of CISOs still report into IT leadership, only 10% influence financial decisions, and only a quarter say board discussions of cyber risk run longer than 30 minutes. They are accountable for the breach without budget authority, and they check the work of the people they report to.

The organizations that feel safest about the next two years are not the ones with the most tools. They are the ones where leadership understands AI risk, someone clearly owns it, and the security team has the authority to act. That is a governance problem, and it has a governance fix.

A roadmap for reconstruction

1. Take security out of IT, and do it before the breach

No company lets the finance department audit its own books. That is why internal audit reports to the board’s audit committee rather than to the CFO. Security deserves the same independence for the same reason: the people who build and run the systems should not vouch for them. The CISO’s job is not to run technology. It is to govern how people, partners and machines behave around the things the organization cannot afford to lose, and to tell leadership the truth about that risk.

That does not make the job less technical. A CISO who can’t read an architecture diagram, question an engineer or spot a vendor’s overstatement will be steamrolled in the first meeting. The role needs an engineer’s depth. It is just bigger than engineering, the way a general counsel needs to know the law but is hired for judgment.

In practice, that means a direct line to the CEO and a board committee. Equifax did this after its 2017 breach. Its new CISO, Jamil Farshchi, called the direct line to the CEO and board the key to the turnaround, and noted that it costs nothing. Vertex Pharmaceuticals took a different route: its CISO reports to the Chief Scientific Officer, which puts security next to what the company actually protects, its research. Choose a model deliberately. Most organizations never choose; they inherit one.

2. Hand the CISO the AI governance pen

Only 19% of organizations report coordination between their AI governance and security teams. Every AI tool the business adopts is a security design decision, and it needs one accountable owner. Otherwise, you have a committee that approves tools and a security team that finds out later. But accountable doesn’t mean alone, which brings us to the most important step.

3. Give everyone a voice

A CISO knows security. A CISO does not know research, or claims processing, or the manufacturing line. Elevating the CISO works only if decisions get made with the people who live with them: research leaders, business owners, legal, finance and the CIO. Build a standing risk council where those voices shape controls before they’re imposed, and where a scientist can say “this will break my work” and be taken seriously. The point of elevating the CISO isn’t to put one person in charge of everyone else’s work. It’s to make sure the person who owns the risk is in the room, and that everyone affected by the decision is in the room too.

Security decisions made in isolation get worked around. Decisions made together get followed.

4. Define “ready,” then hire and develop to it

New York’s cybersecurity regulation for financial firms calls the CISO “a qualified individual” but never says what qualified means. Here’s a working definition, in the form of two tests a board can give. The first is technical, and it is not optional:

• Can you tell us what we own, who can reach it, and how fast we can recover, and when did we last test that?
• Have you personally used the AI tools our employees use? Can you explain prompt injection and agent permissions to us in plain English?
• Where does your threat knowledge come from besides vendors: peer networks, industry information-sharing groups, red-team results?

The second test is about judgment and behavior. It is the one most security leaders are never given:

• What do our people actually do when a request seems urgent and comes from someone senior?
• Which risks have you advised us to accept, and why? A CISO who never recommends accepting a risk is a gatekeeper, not a risk officer.
• Can you translate a risk into dollars and days of downtime?
• Which research and business leaders do you consult before a control changes how they work?

And one question for the board itself: Have we given this person authority that matches their accountability?

👉 Click here to download a sample CISO job description👈

5. Make sure AI agents are governed like employees

The CISO doesn’t provision these accounts; the CISO makes sure someone is accountable for every one of them. Every non-human identity needs an owner, the least privilege it needs, monitoring, and a kill switch. Among organizations that had an AI-related incident, 92% lacked proper AI access controls.

6. Hold everyone to the clock, not the checklist

Ask every part of the organization for time to detect, time to contain and time to recover, using tested numbers rather than estimates, and report them to the board. The 200-day line in IBM’s data is worth more than a million dollars per breach.

7. Make sure the boring things get done

Encryption, multi-factor authentication, asset inventory and network segmentation are not glamorous, but they are exactly what insurers began requiring after the Merck case. Doing this work belongs to the technology teams. The CISO’s job is to verify that it’s done and to tell the board plainly when it isn’t. If your underwriter is asking for these controls, your board should be too.

8. Give the board more than 30 minutes

Make cyber a budget conversation rather than a status update. If the CISO’s board time is spent on regulatory trends instead of business trade-offs, the board is being briefed, not governed.

A word to CIOs

I know how this reads to a CIO: someone telling you to give up a direct report. But a CISO who reports to the CIO is grading the boss’s homework. The CIO is measured on availability and speed of delivery. The CISO is measured on risk. That tension is healthy only between peers. Elevating the CISO doesn’t diminish the CIO; it frees the CIO to build without also serving as auditor of what they built. The two roles aren’t a senior and a junior version of the same job. One builds and runs the organization’s technology. The other is responsible for whether the organization, its people included, can be trusted.

A good CIO should lean on the CISO and also be a little afraid of the CISO, the way a good CFO relies on the auditor and is a little afraid of what the auditor will find. That fear is not hostility; it is the reason the books stay clean. Pair it with the partnership described above, and the CIO gets something no direct report can offer: someone with the standing to say “no, not like that” before the board has to hear it from an attacker.

The CIO’s seat at the table appeared when technology became the business. The CISO’s is appearing because trust has become the business, and AI has made that impossible to ignore. Some organizations are already moving. In IBM’s follow-on research, 85% said they plan to increase security spending after learning what frontier AI models can do to their systems, compared with 64% who planned to spend more after suffering a breach. Learning from the threat is far cheaper than learning from the post-mortem, and the organizations that get there first will be the ones where security, research and the business decide together.

The moat is dry. Stop dredging it, and give the person defending the castle a seat at the table.

In June 2017, a piece of malware called NotPetya got into Merck & Co. without climbing a single wall. It arrived through a backdoor in accounting software supplied by a Ukrainian vendor, the kind of trusted, routine traffic every perimeter is built to let through. It spread to some 40,000 of the drugmaker’s computers, and Merck put the damage at more than $1.4 billion.

Then several of Merck’s insurers argued they owed nothing, because the attack was attributed to Russian military intelligence and their policies excluded acts of war. The fight ended in a confidential settlement in January 2024.

Two lessons sit in that story. The moat didn’t matter, because the threat came in with the traffic the moat was designed to admit. And the people who price risk for a living were the first to notice and the first to send the bill.

That was 2017, when attackers still needed humans at the keyboard. Increasingly, they don’t.

Here is the argument of this two-part series in two sentences. Security stopped being a technology problem with business consequences; it is now a business risk with a technology component. Most organizations are still organized the other way around, and the person they hold responsible for that risk sits inside the IT department, reporting to the people whose work they are supposed to check.

What AI actually changed

IBM’s 2026 Cost of a Data Breach Report, based on 602 breached organizations, found that one in four malicious breaches was AI-enabled, a 56% jump in a single year. Those breaches averaged $6 million, about $1 million above the global average of $4.99 million. In the U.S., the average breach now costs $11.5 million.

You don’t need a computer science degree to understand what changed. Three things matter:

• The con got a better voice. Deepfake impersonation was the most common AI-driven attack in IBM’s data, at 45%. The oldest scam in business, the urgent wire transfer, now arrives in the CFO’s actual voice on a video call.
• Your software can be talked into things. “Prompt injection” means hiding instructions inside an email, document or web page that an AI assistant reads and then obeys. It is social engineering aimed at the software instead of the employee, and no amount of annual phishing training protects against it.
• You’ve hired employees with no background check. Every AI agent holding credentials is, in effect, a new hire with keys to your systems, no manager and no HR file.

Notice what those three have in common. Each one is an attack on trust, on whom we believe, what we obey and whom we let in, and only then on technology. That distinction matters for everything that follows.

Meanwhile, employees aren’t waiting for permission. Shadow AI, meaning tools staff use without sanction, showed up in 43% of breached organizations this year, up from 20% the year before. Breaches involving AI systems themselves rose to 21% of all incidents, and the most common way in wasn’t the model at all. It was the plumbing around it: compromised APIs and plug-ins, and misconfigured cloud workloads.

Why the moat is dry

Moat security is easy to recognize. There’s a perimeter, a couple of expensive appliances, an annual training module, and a binder of procedures nobody reads until the auditor visits. It assumes the enemy is outside.

Today, much of the risk has been invited in the assistant reading the email, the agent holding the credentials, the vendor pushing the update. When Johnson Controls was hit by ransomware in 2023, the attackers first got into the company’s Asia offices and spread from there across the network. The company confirmed data theft and more than $27 million in costs, net of insurance. One breach in a distant office, and the moat was irrelevant.

Moat organizations measure activity. Attackers measure time. IBM found the average time to identify and contain a breach rose to 247 days, the first increase in five years. Breaches contained in under 200 days cost $4.32 million; those that ran longer cost $5.65 million. And 53% of breached organizations hadn’t encrypted sensitive data at rest and in transit. The basics still aren’t done.

My email signature reads “Process is the evil twin of progress.” Moat security is process mistaken for protection.

Prepared versus old school: the numbers

In fairness, IBM sells security tools, and I’m aware of the irony of citing a vendor in a piece that warns against learning from vendors. The fieldwork is done by the Ponemon Institute, though, and the pattern matches what independent CISO surveys show. The gap between prepared and unprepared organizations is not subtle:

What separates them	Prepared	Old school
AI and automation in security operations	Breach costs nearly $2M lower	One in four still without
Breach found and contained	Under 200 days: $4.32M	Over 200 days: $5.65M
Employee use of unsanctioned AI	Low: $4.63M per breach	Widespread: $5.39M per breach
AI security maturity (CISO self-rated risk)	3.7 out of 10	7.8 out of 10
AI governance and security teams coordinated	19% of organizations	Everyone else

Sources: IBM/Ponemon, Cost of a Data Breach 2026; IANS/Artico Search, CISO Perspectives on AI Risk 2026.

The most revealing finding comes from the IANS survey of 113 CISOs. Mature AI security programs explained why some security chiefs feel safer today. But confidence about the next two years tracked something else: whether leadership understood AI risk, whether someone clearly owned AI governance, and whether the security team had budget authority and enough staff. In other words, the factor that matters most is governance, not technology.

The CISO problem: under-trained and under-armed

Under-trained. Many of today’s security leaders learned the job defending against people, not software that behaves like people, and much of what they know about AI came from the companies selling the cure. When IANS released its research this year, one of its partners pointed out that most AI risk data comes from vendors and so reflects the supply side. If your threat briefings, your training and your tools all come from the same sales channel, you’ll end up with a well-funded blind spot. Only 53% of CISOs in a LevelBlue survey said they felt prepared to defend against AI-enabled adversaries.

This is not about age. A veteran who keeps learning beats a newly certified buyer of AI-branded appliances every time. What matters is whether someone is still learning now, not when they first learned.

Under-armed. The IANS 2026 board engagement study found that 95% of CISOs brief their boards regularly, but only 10% influence financial decisions. Only a quarter say board discussions of cyber risk run longer than 30 minutes. And 64% of CISOs still report into IT leadership. That leaves the CISO accountable for the breach without authority over the budget.

The lab is not the accounting department

Everything above gets harder in a research organization. Research runs on unpredictable workflows, tools adopted the week they appear, enormous data transfers and outside collaborators. A control that slows a scientist doesn’t stop the work. It moves the work somewhere security can’t see.

The stakes are rising at the same time. Google’s threat intelligence group reported that in the second quarter of this year it investigated extortion cases involving stolen AI research, including one in which a healthcare organization lost drug research and an AI model. It also tracked a China-linked group targeting academic, medical and military research institutions in North America.

R&D doesn’t need an exemption. It needs a different deal: wide freedom in how the work gets done, in exchange for a short list of fixed rules around the assets that matter most. In practice, that means protecting around the lab rather than inside it:

• Make the safe path the fast path. Offer pre-approved sandboxes, compute environments and AI tools that are quicker to use than the workarounds. Researchers don’t resist security; they resist friction.
• Watch instead of block. Monitor what leaves the lab and how, rather than putting a checkpoint in front of every action. Unusual data movement and odd access patterns are how theft gets caught without slowing discovery.
• Classify by value, not by department. Open science, pre-publication results and proprietary or controlled work need different protection. Lock down the crown jewels, not the whole lab.
• Borrow from the research networks. The research and education networking community solved a version of this years ago with the Science DMZ, a design that moves high-performance research traffic outside the enterprise firewall and secures it with targeted controls and monitoring instead.

Some rules don’t bend: federal research-security requirements, defense contracting standards, export controls. But that list should be short, explicit and explained, not a binder of procedures nobody in the lab can name.

We regulate security by tax status, not consequence

Public companies must describe board oversight of cyber risk to the SEC, though the final rule dropped a proposal to disclose whether they even have a CISO. New York’s financial regulator requires the CISO to report to the board in writing every year, and the board must understand and fund the program, public or private. Hospitals still operate under a HIPAA Security Rule written in 2003; its overhaul has slipped to July 2027. A privately held research firm can fail as badly as any public company, and the rules barely notice. Don’t wait for a regulator to tell you what your risk already has.

That is the diagnosis. In Part 2, the prescription: an eight-step roadmap for rebuilding, starting with the reporting line that most organizations never chose and simply inherited.

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

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

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

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

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

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

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

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

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

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

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

Agentic AI on the menu

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

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

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

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

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

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

Built for SMBs

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

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

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

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

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

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

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

The hidden costs of buying AI

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

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

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

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

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

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

Token management

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

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

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

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

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

The employer’s prerogative

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

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

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

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

Embracing change

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

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

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

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

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

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

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

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

CIOs are dealing with a lot of change, from the rapid rise of AI and cloud modernization, to cybersecurity and workforce transformation. Many are sharing what they’re learning as they tackle these challenges, including what’s working, what isn’t, and how they’re implementing new technologies in their organizations. Here, a select group of tech leaders reveal the CIOs they follow and why.

Suma Nallapati, chief AI and information officer, City and County of Denver

I follow Suma Nallapati primarily through public technology and AI leadership discussions. She regularly discusses AI adoption, responsible AI, digital transformation, technology strategy, AI governance, human-centered technology, and using AI to improve public services. I find her perspective particularly valuable because she connects AI strategy with practical organizational and citizen outcomes. She also emphasizes responsible and human-centered AI rather than viewing AI simply as a technology implementation exercise. One initiative I found particularly interesting was Denver’s use of AI through its multilingual Sunny chatbot and other city services. Her current role includes scaling AI across areas such as resident engagement, internal automation, permitting, and emergency response while maintaining governance, transparency, and public trust. – Sachin Gupta, senior IT manager, Arrow Electronics

Jennifer Hartsock, chief information and digital officer, Cargill

I follow Jennifer Hartsock through the CIO community, as well as through her thought leadership, interviews, and LinkedIn. I especially enjoy hearing her perspective in longer-form conversations where she talks candidly about the realities of leading technology and transformation in a large, complex organization. Hartsock talks about many of the issues CIOs are navigating right now, including AI, digital transformation, technology operating models, talent, and leadership. A consistent theme in her perspective is connecting tech decisions back to the business, including how tech teams work with the business, and how you create greater ownership closer to the outcomes you’re trying to achieve. – Kathy Kay, EVP and CIO, Principal Financial Group

Fletcher Previn, SVP and CIO, Cisco

Fletcher Previn’s profile shows how a modern technology leader can discuss change without reducing it to a narrative about vendors. He explores AI, culture, talent, and productivity, with an emphasis on conditions that determine whether transformation lasts. The insight worth returning to is his focus on adoption as a leadership responsibility. New technology fails when teams lack learning time, managers lack clarity, and incentives reward behavior that no longer serves the business. CIOs can apply that lens to modernization, security initiatives, and data governance. It encourages an honest definition of progress based on decisions and outcomes rather than launch dates or dashboards. – Sherif Koussa, CEO, Software Secured

Kellie Romack, CDIO, ServiceNow

What makes Kellie Romack’s perspective valuable is she talks about AI from inside a large enterprise IT organization, not the outside. Her posts regularly cover enterprise AI, AI governance, autonomous IT, workforce transformation, cybersecurity, digital transformation, and how the CIO role is changing.

The point that stayed with me was her argument that CIO organizations now have to redesign jobs, teams, and workflows around AI while building new human skills at the same time. That’s a useful distinction. It frames successful AI adoption as an organizational and leadership problem as much as a technology one. Her seat at ServiceNow also gives her a view of what happens after the experiments stop. ServiceNow has reported that its internal AI use cases grew from 15 to more than 200. That makes her worth reading about for any CIO trying to understand what scaling enterprise AI actually looks like. – Tapabrata Biswas, project manager, InfluxIQ Tech Pvt. Ltd.

Mike Blandina, CIO, Snowflake

I follow Mike Blandina for his practical perspective on enterprise AI adoption and the operational realities behind digital transformation. His commentary consistently connects emerging technology with the governance, workforce skills, and measurable outcomes needed to make it useful. One insight that particularly resonates with me comes from this CIO.com article.

He makes the case for building an editing culture rather than a writing culture. As AI increasingly handles first drafts of code, reports, and other work, he argues that the critical human skill becomes evaluating outputs, identifying mistakes, and knowing when to challenge the system. I also appreciate his emphasis on data lineage, access permissions, and measuring actual productivity improvements instead of AI tool logins. Those are the less visible decisions that determine whether enterprise AI adoption delivers lasting value. – Parth Patel, director of operations, Shaligram

Deepa Soni, EVP and CIO, New York Life Insurance Company

Deepa Soni’s insights are particularly valuable because she oversees AI in one of the most critical and regulated sectors of financial services, a Fortune 100 life insurance company where AI decisions have real consequences for policyholders and regulators.

Soni frequently shares in-depth thoughts on what responsible AI adoption truly looks like within a large financial institution. She discusses the delicate balance between the speed of innovation and the readiness of governance, as well as how tech leaders can foster cultures that promote both agility and accountability. What sets her apart is that her approach to AI strategy is rooted in operational realities rather than just vendor hype, which is a rare and precious perspective for CIOs facing similar challenges. – Viren Meghani, technical architect and independent researcher in AI governance

Sears Merritt, CIO and head of enterprise technology and experience, MassMutual

I follow Sears Merritt on LinkedIn and through his interviews. He talks about what enterprise AI costs to run and how to keep the option to change your mind. Merritt also discusses why AI vendor contracts should be capped at 12 months to maintain flexibility, how success metrics are defined before AI pilots begin to determine whether they should be scaled, and the data platform he spent three years building before the AI wave arrived. This is useful to other CIOs because he’s one of the few CIOs at a regulated insurer who talks about AI in the language of procurement and measurement rather than vision. – Egiziago Cioffi, IT/enterprise architect and CEO, SynSphere Italia

Ganesh Ariyur, CIO and head of enterprise technology, Gainwell Technologies

I follow Ganesh Ariyur for his insightful views on AI, enterprise architecture, transformation, tech strategy, governance, and ways CIOs can link tech investments to quantifiable business value. What I find particularly helpful is his content extends beyond just talking about new technologies. He continually positions technology choices in relation to business results, operational frameworks, financial discipline, and implementation. This is particularly important for CIOs facing pressure to showcase ROI from AI and modernization efforts.

An example is his work, The 2026 CIO Operating Model: Architecture, AI, and Enterprise Value. His main point is that tech strategy must be viewed more like capital strategy, with CIOs assessing issues like if cloud expenditures enhance unit economics, and if architecture facilitates quicker decision-making. That viewpoint is important as it transitions the dialogue from which technology to implement, to what ways technology should transform the enterprise’s operations and value creation. – Ketan Patel, digital marketing manager, WeDoWebApps

Jim Swanson, EVP and CIO, Johnson & Johnson

I’m interested in how Jim Swanson thinks about the relationship between technology and the business, particularly where innovation carries considerable responsibility. For example, he recently discussed how AI agents are changing the way people interact with enterprise software. What caught my attention was his emphasis on the complexity that comes with that change — the integration, oversight, and accountability required to make it work. Those are questions that deserve as much attention as the technology itself. – Bill Huber, partner, ISG

Kimberly Basile, CIO, Kyndryl

I follow Kim Basile along with her bylined pieces on Kyndryl’s newsroom and interviews in the business press. She discusses enterprise AI adoption, workforce readiness, AI governance, platform modernization, and security leadership, informed by her earlier role as SVP and CISO at Leidos. Basile speaks from inside a transformation few CIOs have experienced, having helped guide Kyndryl’s technology separation from IBM and consolidate its application portfolio. She treats governance and people readiness as part of AI adoption from the start, and she’s candid about what hasn’t worked. In a recent feature on agentic AI, for instance, she said Kyndryl initially focused on counting agents, and the number didn’t tell the true story. Her team pivoted to measure business process flows. She also identified automating a process that hadn’t been properly validated as one of the company’s biggest mistakes. Activity metrics are easy to report, so organizations default to them. Her lesson pushes CIOs to validate a process before automating it.

She matters beyond the technology because women remain underrepresented in IT leadership, and she uses her visibility to lift others. When she was named to Women We Admire’s Top Women CIOs of 2026, her second year on the list, she used her post to congratulate the other honorees by name and highlight how these leaders help employees embrace technology. That generosity matters in a field where women CIOs are still too few. As the co-founder of Girl Power Talk, I pay attention to leaders who open doors for the next generation of women in tech. Basile does that consistently. – Sameer Somal, founder and CEO, Blue Ocean Global Technology

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

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

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

It starts with small permissions

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

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

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

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

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

Success can weaken oversight

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

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

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

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

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

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

Put the controls outside the model

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

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

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

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

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

Govern access in real time

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

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

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

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

Make someone own the agent

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

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

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

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

Multi-agent systems need system-level controls

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

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

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

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

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

Set the bar before the agent reaches it

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

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

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

CIOs bring a lot to their new jobs: decades of leadership, transformation, pattern-recognition, and outcomes. But none of that matters in your new job. During a time of generalized uncertainty, your team — and every stakeholder — needs to trust you more than anything. But how do you build that trust in a new environment, and as quickly as possible? For Cengage CIO Ken Grady, the best approach is an architectural one.

What is a trust architecture, and why did you develop it?

I’ve been a CIO for almost 20 years, and when I joined Cengage six months ago, while I had roughly 7,300 days of evidence that I knew how to do this job, not one person in that building had ever seen any of it. The proof existed on my résumé. The trust did not.

On day one as a new CIO, you have no shared experience with your team, so you have no trust. Your team might have respect for your background, and hope you’ll succeed, but personal trust is something you must build from scratch.

So how do you do that when the currency of trust for your team can shift depending on the situation? Establishing trust with the people in your new business requires an intentional approach, an architecture.

What are the different currencies of trust?

The first is technical currency. My team needs to know that as a new CIO, I’ll respect their technical expertise, have enough of my own to be helpful, and engage in healthy technology discussions. To solve for that, I sat down and led an open conversation early on about whatever was on their minds, and I showed them that their technical expertise is valued.

The second is investment currency. Can I, a technology leader, speak to ROI or NPV? Can I explain why we should invest in this technology, or address this technical debt, or move from this version to that one? My team needs to respect my ability to guide our investments.

The third is human currency, which addresses the questions people are afraid to ask. Why did we move our offices? Why are we incentivized this way and not that way? IT people are people, and they have non-technical questions.

Technical, investment, and human currency get exchanged in a cadence of conversations, and that cadence almost matters more than the content itself. People value leaders who are steady.

How are you using the trust architecture now?

People have questions when a new leader comes on board, and they need a safe place to ask them. That’s why we built a monthly Enterprise Architecture Review, an open meeting with no agenda where technical people talk through hard problems concerning what we’re trying and learning, what’s working, and what isn’t.

We’ve also built a monthly portfolio review called Steps-to-Green. We talk about the yellow and red projects, and how we can help each other move them to green. There’s no punishment in this room, only encouragement. If your product is yellow, that means you’re one step closer to green.

But the fear is wondering if it’s okay to say what you really think, so the senior leadership team holds a monthly anonymous Q&A. Ask us anything, what you’re worried, frustrated, or even angry about. We might not have all the answers, but we’ll try. If you give your team that kind of safety, they’ll use it.

What’s the benefit of this safety?

You get a high-functioning team willing to challenge existing norms and continuously improve. There’s no such thing as a perfect organization, and safety creates an environment where anyone can suggest an improvement, try it, test it, and report back.

What you get with safety is democratic governance. If there’s a quality problem, anyone in IT can hit the big red button to say we’re not doing this release, we have a quality problem. Anyone on the team can know more than I do about this technology, migration, or this HR issue, and hit the button.

It doesn’t mean there’s no bandmaster. I still need to lead the band since that’s my job as CIO. But the trombone player has to trust me enough to tell me we’re not playing it right.

What advice do you have for CIOs building a trust architecture in a generally anxious workforce?

I cure prosciutto in my basement. Every time I start a new one, I remind myself it takes 18 months, regardless of how many years I’ve been doing it. Trust doesn’t care about your résumé. It’s earned, not given. Before your next conversation, ask yourself if you’re building trust in the currency this person accepts, or the currency I’m most comfortable spending.

Empathy should be your lens. With my team, I show up ready to learn something, connect with them, not to perform leadership. With my stakeholders, I understand they don’t care about my migration strategy. They care whether I’m making their life easier. With my board, empathy isn’t warmth. It’s precision on knowing they need confidence from me, not just an update.

Each direction takes a different currency for team, stakeholders, and customers. As a CIO, you can’t be comfortable in one lane and neglect the other two. You must invest in all three.

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

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

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

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

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

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

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

Access and control

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

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

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

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

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

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

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

Sovereignty and safety

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

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

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

Location isn’t everything

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

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

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

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

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

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

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

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

Companies are moving fast to put AI into chatbots, virtual assistants, and other customer service tools. But for CIOs, that comes with a risk: if the technology gives customers the wrong information, makes biased recommendations, or mishandles data, it can immediately damage the trust companies have worked hard to build.

Unlike conventional software, gen AI doesn’t always give the same answer to the same question. An answer can sound confident and convincing while still wrong. And when customers rely on AI for information about their finances, insurance, or health, a mistake can have much greater consequences.

Sumit Johar, CIO at cloud-based software company BlackLine, understands that inaccurate AI responses hurt the customer experience, force companies to spend money and resources to fix problems, damage the brand, and create regulatory risks. AI systems can also expose confidential information, making it important for companies to understand the data sources behind their responses.

“An AI failure creates a massive trust issue around the core solution being provided,” Johar says. “In the financial sector, bad AI advice or outputs can compromise balance sheet accuracy and lead to severe legal and personal liabilities.”

For Citizen Health CTO Daniel Wang, for instance, the stakes are particularly high because the company’s users include rare disease patients and caregivers.

Citizen Health works to ensure that important information provided by its AI can be traced back to the original source, such as patient records, clinical information, or medical studies. The company also reminds patients to talk with their healthcare providers before making medical decisions.

Wang says one of his biggest concerns isn’t just that AI can make a mistake, but that a wrong answer can sound right.

“An AI system can present an answer that sounds caring, informative, and authoritative, even when the underlying information is inaccurate,” he says.

That risk has affected how Citizen Health releases AI products, and has delayed AI launches when the company needed more time to understand how the technology was coming up with its answers, or to make sure those answers were accurate. So instead of rolling out new AI tools to everyone at once, smaller groups of patients might be tested first, and their feedback used to make improvements before a wider launch.

Citizen Health also tests its AI tools before launch using questions with known answers, and uses both automated testing and human review, watches for unusual AI responses, limits what the AI can answer, and gives patients ways to provide feedback.

Moving at the speed of trust

Other tech leaders are taking a similarly cautious approach. Jonathan Tushman, CTO and CAIO at Hi Marley, an insurance technology company, says it’s had tech that was ready to ship for years but chose to spend more time on testing, observability, legal review, and training before releasing it.

“If it weren’t for that trust-and-governance bar, we’d have gone live a year earlier and had faster adoption,” Tushman says. “We chose not to.”

Hi Marley calls that approach working at the speed of trust. For Tushman, releasing customer-facing AI also requires the ability to see what the system is doing once it’s running. That includes monitoring individual conversations as well as looking for patterns across tens of thousands of interactions. Companies also need kill switches that can shut down a system, and the ability to roll back changes if something goes wrong.

But technology alone isn’t enough. Customer service, IT, DevOps, and CloudOps teams all need procedures to respond to AI problems, Tushman adds.

Udaya Bhaskar, senior application security analyst at global farming company Corteva Agriscience, says one mistake companies make is moving too quickly after seeing an impressive AI demonstration without fully testing how the tech will perform with actual customers.

He adds that companies can also run into problems when they rely too heavily on vendor claims, or launch AI tools without giving customers an easy way to reach a person when something goes wrong.

The hidden cost of AI mistakes

The pressure to deploy AI is often tied to the promise of greater efficiency. A chatbot that handles more customer questions, for example, can reduce employee workloads. But those time and cost savings can shrink quickly if employees have to spend their time checking and correcting the AI, something referred to as the hallucination tax.

Companies may budget for developing the technology without fully accounting for ongoing costs of running and monitoring it.

Jess Lampe, global lead technologist at Launch Consulting says those hidden costs can include employees spending time checking AI responses and redoing work when the technology gets something wrong, as well as regulatory and legal risks. Another cost can be harder to measure: loss of customer trust.

Chris Slovak, global field CTO at managed enterprise AI delivery platform Unframe, sees the resulting damage to a company’s reputation as one of the largest hidden costs.

“Anything customer-facing is a representation of your brand,” Slovak says. “Yes, poor implementations with bad experiences have a material cost from the perspective of tokens. However, the impact on your brand is far more costly. Often, companies add AI to deflect customer support. Consider you have a customer who’s already frustrated, and meeting AI makes it worse. The loss in trust can be massive.”

But Kevan Yalowitz, global software and platforms lead at Accenture, says mistakes are going to happen whether work is performed by people or technology.

“The true hidden cost is destroying user trust when mistakes happen, regardless of the source,” Yalowitz says. “The most successful organizations quickly admit when these mistakes happen, provide a transparent explanation, and explain how it was an opportunity to learn and ensure the mistake doesn’t happen again.”

Human oversight remains critical

For CIOs, preventing those problems means putting controls around AI before it reaches customers.

Johar says human oversight is particularly important for critical decisions. In highly regulated industries such as finance, AI shouldn’t independently handle decisions where accuracy is essential. Companies also need reliable data feeding their AI systems, and the ability to audit what happens when something goes wrong.

Lampe says the level of oversight should depend on what an AI system is allowed to do. An AI tool that summarizes information, for example, doesn’t pose the same risk as one that can take action involving a customer’s money or account.

Companies should also continue testing after launch. AI behavior can change over time, meaning a system that performed well when it was first released may not continue performing at the same level later on.

Toyan Espeut, chief customer officer at cloud-based work management and collaboration platform Smartsheet, says companies also need strong rules around customer data.

“It can’t be mixed across tenants or used to train third-party models, and AI can never operate outside a customer’s existing permission structure,” she says. “If a person can’t access something, the AI acting on their behalf shouldn’t be able to either. Every AI action needs to be fully auditable, and customers should always have transparency into when AI is involved, and the ability to review or validate AI-generated outputs.”

Who’s responsible when AI gets it wrong?

Even with extensive controls, companies need to prepare for their AI to make mistakes, but the AI itself can’t be solely to blame.

At Citizen Health, Wang says a problem involving customer trust quickly becomes a company-wide issue. The company has support and on-call procedures, but serious concerns are also brought to leadership. Citizen Health also maintains direct channels for users to report problems so they can be investigated quickly.

Tushman at Hi Marley makes a distinction between the person who initially handles an AI problem and the executive ultimately responsible for it. A customer success or help desk team might receive the first complaint, but he says accountability for customer-facing AI rests with him as CTO. “It isn’t something you outsource to the system or hand to the vendor,” he says.

Corteva Agriscience’s Bhaskar similarly says the company deploying the AI remains responsible for what it does since AI is a tool rather than a decision-maker, and companies can’t shift responsibility to the technology when something goes wrong.

And Lampe adds that every customer-facing AI system should have a named person responsible for its behavior and performance, along with a clear process for escalating problems, and allow customers to challenge incorrect outcomes and reach a human.

Speed: only one measure of success

The push to adopt AI is unlikely to slow down. But tech leaders say companies need to be careful about the standards those investments work by. Simply counting how many customers use an AI tool may not say much about whether it’s making their experience better.

Espeut says companies should look at whether customers are solving problems faster, making better decisions, and getting better business results.

“Companies should also expect fewer support tickets because that tells you customers are actually succeeding with the tool, not just using it,” she says. “Expanded engagement across the organization is also an indicator instead of staying siloed in one buying center. They should pay attention to the quality of customer feedback and feature requests as well. When customers actively help shape your product, it’s a strong signal they trust the technology and see its long-term value.”

With a career built at companies like Visa, Ellie May, and Blackhawk, Selim Aissi, a 2026 CSO hall of fame inductee, understands how boards and executives demand a clear justification for cyber security investment, especially considering today’s difficult economic climate.But getting security leaders to communicate tech debt, operational fragility, and long-term cyber risk in business terms the board can actually act on isn’t always straightforward.

A lot of organizations add tools, and more platforms and controls in response to new threats. Yet that doesn’t necessarily address underlying complexities. Security investment can actually increase operational and strategic risk.

“I think there’s a tipping point once a reasonable depth of defense is in place,” he says. “When there’s a reasonable level of automation of security controls and cross integration of security tools, anything beyond that could potentially be overspend and could potentially add risk to the entire organization.”

So the challenge is to know when an environment exists and functions without the need for a sudden budget spike.

“All of the KRIs and KPIs in place should be able to indicate the level of resiliency,” he adds, “in addition to other controls such as making sure there are processes that would allow for detection of, let’s say, API abuse, cloud-level abuse, and, increasingly these days, AI as it adds yet another threat vector.”

Understanding risk also lies in recognizing the distinction between organizations that are genuinely resilient, and those that appear mature on paper, focused on fine-tuning policies, compliance, governance, and frameworks.

“These are all important but they shouldn’t be the main focus,” he says. “The first step is knowing where the data is and once in transit, how it needs to be protected with the most updated protocols.”

Aissi expands on how organizations unintentionally create risk through tool sprawl and operational complexity, how boards should think about long-term cyber resilience, and why AI and cloud expansion are accelerating security debt faster than many enterprises can manage. Watch the full video below for more insights, and be sure to subscribe to the monthly Center Stage newsletter by clicking here.

On resiliency: A security organization that’s mature — and I’ve seen many and have built several — is one that’s architecturally designed to be resilient. But resiliency means different things to different people. To me it means that recoverability is tested often, making sure that in case of an event or breach case of lateral movement, the company can react according to a very clear playbook that’s been thoroughly tested. I also think a resilient organization is one that has the right controls of the right places, and one that also has metrics around them that indicate if there’s an event, and how well the tools work.

An area which I’m really passionate about is data protection. But how do you know the data is protected? A resilient organization doesn’t look at whether the data is encrypted at rest or not. It looks at the entire lifecycle of that PII. Meaning the organization has a very clear discovery mechanism to know exactly where the data is. It could be on laptops, servers, or in a public cloud. It could be in many different places, and it can be structured or unstructured.

On organizational risk: My definition of security debt is the accumulation of risk because of investment in areas where complexity is added, where a lack of automation is exaggerated, and where there’s overcompensation for some controls that aren’t needed. So if an organization spends money without effectively simplifying security controls, and automating more than what needs to be automated, that is tech debt.

Most commonly, tech debt in security is defined as the accumulation of vulnerabilities that aren’t patched, the over complexity of identity exposure management (IEM), and a lack of understanding of where data is. So most significant organizations, especially in fintech, have a huge volume and velocity of PII, and in health tech, PHI and security debt is not knowing where all the data is, or that it’s potentially not protected in some areas. So in addition to the data itself, IEM, and lack of automation and overlaying security tools are other forms of tech debt.

On managing board expectations: The board really wants to understand the risk of cyber security investment, and anything else could potentially be perceived as noise. I see many CISOs taking metrics upon metrics, and dashboards upon dashboards of all sorts of variations of vulnerability management. But what the board really cares about is what the risk is to the business if the most critical systems aren’t patched. Anything else could be perceived as not a concern or a business risk.

CISOs should speak in terms of impact of any real or perceived threat on the business, and be specific. So going back to vulnerability management, let’s say there’s a zero day that was patched or maybe multiple ones that were patched. How do you explain that to the board? You say we patched five zero day vulnerabilities. And honestly, the reaction is probably, who cares. The story should sound like these five vulnerabilities if unpatched, could have put certain systems down for three days, or it would’ve been much easier for an adversary to attack this revenue generating system. That’s what the board cares about, the impact on the revenue. And that’s how CISOs need to speak to them.

On AI: Security didn’t get a seat from the beginning when it comes to AI. So how do we explain to the board that developers might start sharing the company’s source code with Claude and it could potentially leak? This is something we’re all trying to figure out. But we should start speaking from a business perspective about the benefit of AI to the security organization, to the security tooling, to security operations, how it could be more efficient and effective, and at the same time, highlighting some of the risks to the organization — not theoretical risks, but risk related to the organization. If it’s a financial institution and AI agents are deployed in some transactional application, I think the CISO should speak to the board about the business risk of not deploying the necessary security tools to ensure that those AI agents don’t go rogue, that the LLMs are protected. So those are the business terms we need to be speaking about.

Most enterprises govern AI the way they would any other IT rollout: deploy dashboards, institute policies, and conduct periodic reviews. Having the right AI governance tools in place and addressing gaps is important, but IT executives should be more concerned about rethinking workflows and establishing ownership.

“Accountability usually breaks down first,” says Beena Ammanath, executive director of the Global Deloitte AI Institute. “Teams deploy AI faster than their organizations can define who owns risk, approvals, monitoring, and outcomes,” she adds, which results in inconsistent use, fragmented controls, and limitations in scale.

Enterprises need to redesign jobs and workflows, not just the tooling, yet 84% of organizations the Institute surveyed haven’t adjusted jobs for AI, and just 21% have a mature AI governance framework in place despite rapid adoption, according to Deloitte’s 2026 State of AI in the Enterprise report.

“Technology can provide visibility and controls, but it can’t replace leadership,” says Rajesh Arora, chief data and analytics officer at Principal Financial Group. “The organizations that scale AI most effectively are the ones that treat accountability as a business responsibility, not a technology responsibility.”

One year ago Principal was focused on building its ethical and responsible AI framework, its inventory, and governance processes to support responsible adoption. Today the firm has assessed nearly 200 use cases. “Governance is increasingly embedded in those investment and operating decisions, rather than applied as a separate review at the end,” he says.

Costly, compounding mistakes

Some organizations have already run into issues with respect to inadequate governance. A 2024 Stanford RegLab study found that AI-assisted research tools offered by LexisNexis (Lexis+ AI) and Thomson Reuters (Westlaw AI-Assisted Research and Ask Practical Law AI) hallucinated between 17% and 33% of the time when working on legal queries, while the Damien Charlotin AI Hallucination Cases Database has identified some 2,041cases of fabrications so far. In at least one legal case (Couvrette v. Wisnovsky) this resulted in nearly $95,000 in sanctions.

Cases like this one are likely the result of an accountability failure. It may be that no one actually owned the job of verifying the AI’s output before it went to the court. But if a single instance of a static AI output could get past a review today, how will organizations deal with autonomous, multi-step agentic AI systems going forward?

Most use cases at Principal are still human-led, with AI providing decision support only, says Arora. “But we’re preparing for a future where agentic and more autonomous capabilities become increasingly common, and those systems raise new questions around accountability, monitoring, and control,” he says. “The goal isn’t to predict every future use case, but to build adaptable governance processes that can support innovation while maintaining trust and transparency.”

Agentic automation raises the stakes

When things go south with agentic AI today, the consequences usually aren’t devastating because in most cases, the outputs are designed to provide insights, rather than take automated actions. That’s already starting to change, however.

Today, many AI failures are like the one described above where someone failed to catch a single bad output. But agentic AI will gradually take more control of workflow tasks in the enterprise, according to Forrester Research. As those agents act autonomously, crossing multiple process steps along the way, small errors will compound before any periodic review can catch them, so governance must be built into every step in the process.

According to Microsoft Research’s VeriTrail project, catching hallucinations in a single final output isn’t sufficient in multi-step AI workflows. The provenance must be traced back through the intermediate outputs, because an agent chains one call into the next, and an error early in that chain can propagate through several steps before a human sees the finished result. Traditional review, built to check outputs rather than the chains that produced them, isn’t designed to catch that.

So business teams can’t be accountable for agent deployments if they can’t verify performance at runtime. “If the agent is goal-oriented, there could be errors in the workflow process that indicate unwanted behavior or skipped steps that the business wouldn’t be able to detect if they only look at the outcome,” says Lauren Kornutick, senior director analyst, AI governance at Gartner.

Power management company Eaton, for instance, has already deployed multi-step agentic workflows without a human in the loop. “We tend to be risk-conscious, not risk-averse, about autonomous workflows,” says Ross Schalmo, the company’s VP and chief data and AI officer. For example, one autonomous agent responds to supplier payment status inquiries by authenticating the requestor, matching purchase orders and invoices, and returning payment information.

Schalmo’s team engineers such applications to be as deterministic as possible, while the non-deterministic, LLM parts of the program are isolated and continuously evaluated against expected outputs to catch model drift. “When there’s a human in the loop, we can be a lot more permissive,” he says. “Anything autonomous, without a follow-on human step takes longer to develop because we have to think about where to use the generative portion of AI versus where we can still use deterministic tooling.”

Breakthru Beverage Group is still early in its AI journey, but EVP and CIO Glenn Remoreras is well aware of the issues around autonomous agentic AI. “It’s people, process, and culture first — to me that’s the bigger play,” he says. The beverage wholesaler has updated use policies, instituted mandatory AI e-learning programs, and is blocking use of unsanctioned AI tools.

But to successfully manage active, agentic AI, where the AI takes actions autonomously across multi-step workflows, users will need more than basic training in AI, says Craig Le Clair, VP and principal analyst at Forrester Research. “AI will take on more of the work and move the human out of duct tape roles that patch around vague systems, poorly designed interfaces, and poorly integrated data,” he says. “The end game is the agent managing and orchestrating the process — that’s the redesigned operating model.”

Humans, of course, will still need to play a role, although today many employees don’t yet have the required skill sets, and currently that point isn’t getting a lot of attention.

AI supervision skills will be needed for agentic oversight, threshold management, confidence intervals, and root cause analysis, for instance. “Figuring out why an agent hallucinated or got stuck in an execution loop — whether due to poor input data or contradictory rules — and how to refine instructions, that’s the direction,” Le Clair says.

Who’s governing anyway?

AI governance is also complicated by the fact that AI projects exist both inside and outside the IT organization. That leaves governance work distributed across CIOs, data and analytics leads, AI leads, IT security, legal, and other players, with no consistent owner, says Kornutick. “It becomes a multi-role orchestration problem of how to govern this, who owns this, and who’s responsible for which component,” she says.

In response, some organizations have brought in a chief AI officer. Twenty-one percent of organizations now have already done so, says Le Clair, adding that roughly 24% of enterprises will move AI and automation governance outside the CIO’s office over the next year to deal with the risk of fragmentation.

Arora, who reports to CIO Kathy Kay, is the focal point at Principal. “My team establishes the standards, oversight, and governance process, but AI is too embedded in the business to be owned by a single function,” he adds. They collaborate with leaders from the business as well as the legal, compliance, risk, and technology organizations.

The challenge, therefore, lies in deciding who’s responsible for controls, model sprawl, and token economics. “We’re seeing a cooperative, co-model where IT focuses on the hard rails — cybersecurity, performance management, infrastructure reliability, and availability,” Le Clair says, while the CAIO focuses on soft rails, such as context engineering, the effects on employees as agents move to the center of the process and start taking over the middleware function humans used to perform, and connecting disparate systems and poorly designed interfaces.

At Eaton, governance is built on a three-legged stool between Schalmo’s organization, cybersecurity, and legal, while enterprise architecture weighs in on tech foundation decisions. The company also assigns ownership of an AI project only after a successful pilot, while IT performs a custodian or stewardship role. “Once that agent is live and operational, it shows up in an org chart, reporting to someone in the organization,” he says.

At Breakthru Beverage, Remoreras formed and leads an AI governance team that reports to the board and co-leads with the VP of data and AI a governance council that reviews and approves AI projects from SVP- and VP-level product owners. “I’m seen as the owner of our AI portfolio, but it’s co-leadership with my peers on the executive team,” he says.

Closing the tools gap

With regard to AI management platforms, says Le Clair, none of the platforms building AI agents have an adequate control plane today to give the visibility needed to move to truly agentic solutions. The most advanced planes are walled gardens. For example, Microsoft’s agent registry will show every agent built across its own platforms, says Le Clair, but not agents built on Salesforce or AWS.

“You’ve got maybe 50 vendors trying to be pure-play control-plane providers, plus the hyperscalers, portfolio companies, and startups building agentic frameworks,” he adds. “There’s no consensus yet on what’s even most important to control, and there’s confusion about requirements.”

Most AI governance tools available today are limited, Schalmo says. “We’ve looked at four or five different external vendors for AI governance and AI control-tower-type solutions, and a lot of them fall down on discovery of AI built by someone else’s solutions,” he says. “That’s a huge gap for me. Either I have to buy governance solutions from almost every piece of software we interact with, which gets really expensive, or I have major gaps in my portfolio I just don’t have visibility into.”

Currently, he’s looking at using a cyber vendor’s AI component for discoverability, going with at least one major firm that provides control-tower capability, and using AI to build another governance layer on top of that.

Organizations clearly need agent registries and agent lifecycle management but it’s less clear what they require beyond that. “How deep does explainability need to go when decisions are made at runtime that weren’t articulated at design time?” Le Clair asks. “There’s real vagueness in the requirements. Vendors have very well-tuned pitches that promise to do anything you want, but buyers often don’t know what they need in the first place, and there are real tool gaps. This is the major problem the industry is actively trying to solve. It’ll just take time.”

But those aren’t Arora’s biggest concerns. “Most organizations can acquire tools,” he says. “Far fewer have clear ownership, decision rights, and accountability embedded across the business.”

Speed versus governance

There’s a perception that governance slows down AI projects because it can’t keep up with the rapid pace of adoption and advancement. A 2026 GitLab AI accountability survey of developers and technology buyers found that 92% of organizations reported some form of governance challenge with respect to governing AI-generated code, and 34% of organizations that experienced an AI-related incident couldn’t determine after the fact whether AI-generated code was the cause.

Similarly, Faros AI’s telemetry analysis of 22,000 developers in its 2026 Engineering Report discovered that developers with high AI adoption rates completed 34% more tasks and 66% more epics, but the median pull-request review time rose by 441%, a nearly five-fold increase.

Is it the case that governance and speed are inherently at odds, and that human review simply can’t keep up? That’s a false choice, says Ammanath. Rather, it shows what happens when both aren’t designed together. “When done well, governance accelerates scaling by giving teams clear guardrails from the start,” she says. “What slows organizations down is retrofitting governance after broad deployment.”

Arora adds that controls don’t slow down innovation but protect the conditions that allow innovation to scale responsibly. “Our approach has always been to move with urgency, but not at the expense of trust,” he says.

How to proceed

For Principal, investing in workforce readiness was one of its biggest investments, helping employees understand both the opportunities and responsibilities that come with these tools, Arora says.

But organizations shouldn’t stop there. Redesigning workflows and decision-making structures is essential before scaling, says Ammanath. “Many organizations have policies and technology in place but lack clear decision rights or governance embedded into daily work,” she says.

Operating model changes take more time than training, and require executive sponsorship and cross-functional coordination. “Without workflow redesign, a workforce may understand AI but lack clarity on when to use it, how to govern it, and how daily responsibilities change,” she adds. “The organizations seeing the strongest results pair broad AI education with role-specific training, workflow redesign, and clear accountability for outcomes.”

Make sure you’ve thoroughly considered the organizational change management aspect of agentic AI projects, says Schalmo at Eaton. His team developed an automated workflow for processing complex bid requests to save the sales team time, but piloted it in a country with lower labor costs than the US. That challenged the economics of the project, and those individuals only dealt with higher-volume, lower-complexity cases.

The lesson: “Lead from a people-first standpoint, and understand the workflow and what’s impacted — whether it’s relieving drudgery and freeing someone for higher-order thinking or customer time, or impacting an actual support function’s role,” he says. “And make sure there’s a viable path to business value.”

An adaptive governance process is key to keeping up with the technology, Kornutick at Gartner adds. She recommends categorizing AI projects following a stoplight approach. Green light projects, such as for personal assistants, present acceptable risks. “We know there’s risk associated with it, but we’re willing to take it,” she says. Yellow-light projects need guardrails in place around such things as PII, or for those triggering a privacy-by-design process, or a security review of a new application. Red light projects need an architectural review before proceeding.

“Think about those use cases as business-transformation processes where you’re fully redesigning workflows, or considering replacing tasks individuals do and shifting them to supervising the AI doing those tasks instead,” she says.

Schalmo’s team does risk tiering based on the EU AI Act’s four-tier risk framework to determine the appropriate level of governance scrutiny for each project. Low-risk requests are automatically provisioned after the requestor fills out a questionnaire, while high-risk cases get a full architectural review.

“Treat governance as the foundation for scaling, not a constraint on speed,” says Ammanath. “Before expanding agentic AI, organizations should define what decisions agents can make, where human oversight is required, who’s accountable, and how performance and risk will be monitored.”

The hardest part, says Arora, is helping an entire organization evolve at the pace of technology. “Successful AI adoption is ultimately a business transformation challenge,” he says. “It requires leadership alignment, clear accountability, workforce readiness, strong governance, and ongoing change management. Long-term trust will belong to organizations that can translate technology into sustainable business value.”

Most CIOs can easily describe their AI initiatives, but struggle to demonstrate and report on AI value and ROI. This is evidenced by Gartner’s AI ROI Vendor Sentiment survey, which found that 27% of respondents strongly agree that ROI from AI initiatives is difficult to quantify. In addition, only one in four had a clear process to evaluate success of AI initiatives.

In the digital transformation era, compute costs were relatively cheap, and the focus was less on FinOps and more on user experience, and the classic software attributes of availability, reliability, scalability, performance, and security.

AI-native and AI-enabled applications still bring these considerations, along with a host of new ones, such as accuracy, validity, explainability, safety, and all the other trust attributes like those in the NIST AI RMF. But as AI scales, it’s quicky becoming a FinOps exercise, too.

I’ve discussed techniques CIOs can apply to improve AI value and ROI such as architectural decisions related to controlling efficiency at the data layer, fine-tuning the application layer, and closing the gap between AI strategy and governance.

Here, we’ll look at three best practices for CIOs looking to formalize their process to evaluate the effectiveness of their AI initiatives through approaches, frameworks, and techniques that support measurement and ROI reporting across the entire AI portfolio.

1. Take a portfolio approach in line with AI ambition

The first step to AI value is to take a portfolio approach and look across your entire AI estate and how it supports your AI strategy and broader organizational strategy. This means thinking about your AI innovation ambition and how you’d like to move the needle year-over-year by adjusting your percentage of spend across quick wins versus must haves, internal (employee-facing) versus external (customer-facing) applications, near-term versus long-term initiatives, and cost savings and productivity versus revenue generation.

This AI innovation ambition approach is a best practice in innovation management as organizations work to gain quick wins early on to prove value, and then get more ambitious in subsequent years and allocate a larger percentage of their spend on more strategic, longer-term, and externally focused initiatives for revenue generation.

For example, an early maturity organization might focus 80% of its AI investment on internal-facing initiatives and 20% on external-facing ones in the first year. Then, it moves to a 70/30 split in year two, and so on. While many organizations may not track these spend allocations, it’s a valuable discipline and one which often differentiates AI leaders from the rest of the pack. In PwC’s 2026 AI Performance Study, the top 20% of companies capture 74% of all AI-driven economic value, delivering a 7.2 performance multiplier over peers.

Deploying focused pilots alongside quick wins is a great way to capture early insights into AI value and ROI before scaling applications. According to Joe Vaccaro, SVP and GM of Network Platform and Assurance at Cisco, networks have become distributed, continuously changing systems that produce far more signal than any human-led operating model was designed to interpret.

“Our survey of 1,000 IT and NetOps leaders found more than half believe a failure to automate will open critical security gaps and elevate enterprise risk,” he says. “For CIOs seeking to demonstrate ROI from AI investments, a credible path is to start with targeted, measurable, and reversible workflows. Focused pilots can validate outcomes and strengthen governance before broader deployment.”

At this level where organizations look at their holistic AI spend, it’s also important to have a well-crafted set of AI value metrics, which can be used to assess the current health and productivity of the portfolio. Borrowing from best practices in innovation management, AI value metrics, such as those that look at input and mix, health and efficiency, and outcomes, help to look across the entire innovation pipeline, from idea to value.

• AI innovation input and mix — What’s going into your pipeline in terms of the types of innovations in the queue.
• AI innovation health and efficiency — The flowrate through your pipeline and the amount of funding being applied.
• AI innovation outcomes — The measure of return on innovation in terms of commercialized innovations that have captured revenue or other objectives.

2. Develop an assessment framework focused on full cost benefit

While many organizations are laser-focused on the cost side of their AI initiatives, your assessment framework needs to incorporate a full cost benefit analysis. “While the current focus for many organizations is squarely on AI tokenomics, it’s important to look at both sides of the coin when it comes to AI value, and look at the business value that’s being delivered by each initiative to give a clear picture of actual return,” says David Evans, AI and growth strategist at thought leader networking platform Thinkers360. 

Ben Schein, VP of AI and analytics at AI infrastructure software company Progress Software, adds that CIOs should stop measuring AI activity and start measuring outcomes where possible. “Usage tells you the meter is spinning, not that value came out,” he says. “Instrument the cost side completely, since every AI action can carry its workload, model, and cost. Then pair costs with benefits where the work allows, so cost per workflow run against value per workflow run, never enterprise-wide spend against anecdotal wins.”

However, Dan Priest, PwC US CAIO, recommends getting back to basics, starting with the investment side but adding a few modern updates. “AI ROI has been illusive for many, in part because organizations are still learning how to achieve it, and because AI sometimes gets a pass on the typical disciplines required to measure it,” he says. “For major AI initiatives, starting with investment might include new infrastructure, labor for the build, models for the intelligence layer, and variable expenses like token costs. All of these should be contemplated in ROI calculation, some of which will require new tracking and controls.”

His benchmarking also points to a threshold effect: ROI stays insignificant until AI investment crosses roughly 1.6% of revenue, and above that line, EBITDA is up 9.5%, revenue is up 3.5%, and total shareholder return is up 20.2%.

3. Include benefits and measure what matters

Another best practice from innovation management is to look at both the quantitative and qualitative benefits of AI initiatives, not solely the direct financials.

“It sounds obvious, but CIOs should measure the business value created like productivity, growth, and other outcomes rather than activity completed, such as building an app, creating a dashboard, or collecting customer feedback,” says Priest. “We recommend looking across five dimensions of value: financial, operating, functional, trust, and workforce. That gives leaders a more consistent way to measure and compare value across an AI portfolio, even when individual investments are designed to produce different outcomes.”

Calculating projected as well as actual ROI can also give CIOs insight into how their AI portfolio is living up to expectations. This is where it’s important to factor in governance costs early in the lifecycle before initiatives get funded, particularly for high-risk applications where downstream governance requirements are high. 

“Ultimately, measure what matters, keep an eye on variable costs, and monitor actuals against expected costs and benefits,” adds Priest. “That gives CIOs the information they need to determine where investments are delivering, where changes are required, and where to lead, lag, or exit.”

Quantifying AI value and ROI doesn’t require a completely new methodology or new approach. It simply takes the same financial rigor applied to many other previous investments. The variable cost dynamics may be more complex, but these are solvable if you align with your AI innovation ambition, apply your assessment frameworks consistently, define your AI value metrics, and measure what matters.

Several months ago, I was invited to an event for CTOs. Just looking around the room, I could see someone had made an assumption about my title. I am a chief transformation officer, not a chief technology officer.

I stayed anyway to see how the other type of CTO thinks about AI. When a CISO got onstage and said, “This is our time,” my immediate reaction was cringe.

I remember thinking, AI is going to change jobs, workflows, skills and how people experience work. Tools and controls alone will not produce transformation. The real challenge is redesigning how work gets done.

I knew from the beginning that AI would require partnership across technology, security, legal, finance and the business. But I saw people and operating-model change as the center of the work, with technical and governance teams enabling it. After working to operationalize AI across a company, I can see what I missed.

Why I started with people and operating models

My original assumption was based on my own experience managing through change. Technology creates possibility; operating models create value. Access is not adoption.

A team can run an impressive pilot that never becomes part of how the function operates. Experimentation means very little if leaders have not defined the business outcome, how the workflow will change or how the team will sustain it once the pilot ends.

People leaders understand job design, learning, manager behavior and the emotional reality of change. People resist initiatives that feel disconnected from the work they are accountable for every day.

Organizations also tend to budget for technology and not for transformation, treating licenses, APIs and model usage as the whole investment. The real cost includes the time people need to learn and build fluency, and the clarity managers need about what good use looks like. 

A technically strong AI program can fail because the organization never changes around it. AI raises the floor, but transformation raises the ceiling. The larger value comes from what happens around the technology, including where human judgment is still required and what the company can now do differently.

Research supports the importance of that organizational layer. McKinsey’s 2025 State of AI report found that redesigning workflows was the factor most associated with reported bottom-line impact of generative AI. 

Operationalizing AI shaped my answer

The more I moved into execution, the more obvious it became that any single function can’t own AI transformation. Technology, data and security could not sit alongside the people transformation as support functions. Leaders across the business have to help design it.

At Branch, I am the executive accountable for AI across the company, including our enterprise strategy and the work of connecting governance, technology, priority use cases and organizational change. Once I started leading that work, I kept running into decisions my team could not make. We needed technology and data leaders to determine whether the architecture was ready and how models would connect to our systems. Security and legal had to establish the boundaries. Finance needed visibility into consumption. The business still had to decide which workflows deserved investment and own the result.

Every practical decision exposed another dependency. We needed an operating model that made routine decisions clear and gave higher-risk work the right review. Good governance should work like a freeway, with lanes, offramps and rules everyone understands, not a roadblock that stops progress. 

Operationalizing AI taught me that no one function can own execution because the work happens across workflows rather than within the boundaries of the org chart.

After eight months of doing this work, I believe someone has to own the transformational work within the organization, but technology, security, legal, finance and people leaders each carry critical parts of the execution. Then, individual functions own their use cases and results.

What a chief AI officer should actually own

Every company needs to know which executive is accountable. Whether that person needs the title of chief AI officer depends on the company.

A dedicated role can be valuable when AI activity is fragmented and the company needs to move from pilots to an enterprise operating model, but it can’t substitute for shared ownership across the leadership team.

That distinction is showing up in the role itself. CIO’s examination of the chief AI officer’s evolution describes a shift away from a central leader owning every AI activity and toward a model where the AI executive establishes strategy, standards and common capabilities while enabling the business to execute. In my experience, that is much closer to what the work requires.

The accountable executive should decide where the company will focus and make sure governance produces decisions quickly enough for teams to act. They need alignment from the leadership team on which risks the company is prepared to accept and how it will know the work is paying off. They also own how the organization changes around the technology. That includes how people learn, what managers expect, how workflows get redesigned and where the company reinvests the time AI creates.

They should not become an AI island. They can’t be the technical concierge for every tool request or the gatekeeper every function waits on. That structure gives the rest of the executive team permission to outsource responsibility for a transformation that affects all of them.

Finding someone who fits that profile is its own challenge. I would look for a transformation leader with real technical fluency. They need to work credibly with architecture, data and security leaders. Their job is to connect those decisions to workflow redesign and bring the organization with them.

In some companies, that person will be the CIO. The 2026 State of the CIO research describes CIOs increasingly acting as AI orchestrators and change management champions. In other companies, the accountable executive may be a chief transformation officer, a chief operating officer or a dedicated CAIO. The title matters less than the mandate, authority and ability to lead across boundaries.

When I think back to that CTO event, I understand why the CISO said, “This is our time.” AI has expanded the mandate of security and made its partnership with the business more important. I also understand why I reacted so strongly. People are the transformation. Ultimate accountability still sits with the CEO. Functional leaders own outcomes in their areas. The board needs visibility into strategy, material risks and oversight. The AI leader keeps those layers connected.

New technology executives often discover the skills that made them successful early in their careers can be the very things that limit their success as a CIO, particularly as the scope, complexity, and expectations of the role expand. Few leaders understand that evolution better than AlTi Global CTO Phil Dundas, my recent guest on the Tech Whisperers podcast.

Leading technology inside some of the world’s most complex financial organizations, Dundas has repeatedly had to rethink what his job requires of him. That has meant learning when to get into the details and when to stay out, replacing control with context, creating genuine accountability and empowerment without leaving people unsupported, and measuring his success less by the problems he solves personally than by the capability of the organization he builds around him.

Those lessons are particularly relevant as CIOs take on broader mandates and lead organizations that operate with increasing speed. Navigating this environment requires a leadership system that enables good decisions, accountability, innovation, and execution to happen at scale. That starts with trust, which Dundas sees as the foundation for client relationships and innovation. Here, Dundas shares some of the hard-earned shifts that helped him make that transition, as well as the leadership practices he believes separate true enterprise leaders from strong technology executives.

Dan Roberts: Trust is a thread through everything you do. How does it shape the way you approach innovation, especially with AI?

Phil Dundas: Wealth management is a trust business. I love the line that trust arrives on a bicycle and leaves in a sports car. It takes years to earn and moments to lose. The relationship between a client and their advisor sits at the center of that trust, and it is underpinned by the data and information the client sees. So client trust depends on data trust, and data trust depends on the people and the discipline behind it.

I’m impatient to innovate, and that’s exactly why I’m so obsessed with foundations. I love to build, to engineer, to develop from the ground up, and to see concepts go from business ideation to business-impacting reality. I want to architect, design, and deliver AI solutions on the most exciting contemporary platforms. But reconciled, clean data and clean identities are what let you ship AI tools that don’t embarrass you a few weeks after the demo. Getting the foundations right isn’t the cautious choice. It’s what enables you to go fast.

The same is true of guardrails. Clear data ownership, sound governance, and clarity on where AI should and shouldn’t be used aren’t there to slow people down. They’re there to speed them up. When people know where the edges are, they can then move faster inside them.

Foundations work is often invisible to the business, though. Nobody sees the data pipelines. So alongside it, you need visible wins, a dashboard or a tool demonstrating forward movement, showing data more timely and accurately than before, so stakeholders can see the progress and keep backing your efforts on the less glamorous work underneath.

As you climb the ladder, some strengths that once made you invaluable can limit your effectiveness as an enterprise leader. How have you had to pivot as your leadership responsibilities became bigger and more complex?

The biggest thing I had to unlearn was the need to be the person with the answer. When you come from a deep, analytical, technical background, your instinct is to step into the “how.” As the role grows, your job shifts to the destination and the outcomes, and to letting your team own more of the route.

That means accepting they may not do it the way you would. Often you’re pleasantly surprised and the result is better than you expected. Sometimes they stumble, and that’s how they learn. Both are hard when you’re up against a deadline with tough stakeholders, and both matter.

The other shift is holding the destination firmly while staying flexible on the route. Conviction holds the destination. Stubbornness refuses to change the route.

I learned that in a previous role on a divestiture, where we were extracting a business from one parent and integrating it into another. I was on the infrastructure and business enablement side, and we came up with some incredibly elegant technical solutions leveraging virtual desktops. We thought, “The business is going to love this.” However, when we sat down to show them, it was technically perfect — and completely unusable. It was cumbersome and hard to navigate for a non-technical end-user. We hadn’t done the design thinking or sat with the business to ask whether it worked for them.

We had to make a tough call and go back to a less sophisticated solution that was what the business needed to get through the migration, as we were up against a transition services agreement deadline and the clock was ticking. It stung, given the time and money we’d invested. But as a leader, you have to acknowledge that, take accountability, and pivot.

You’ve told me about receiving 360 feedback earlier in your leadership career that essentially said you were getting too much into the details. You then discovered you could overcorrect in the other direction. What did those experiences teach you about the difference between empowering people and abandoning them?

That feedback stung, and not just because I’d expected a more flattering read. Earlier in my career I’d worked for leaders who held on too tightly, and I knew how much it drained a team. Hearing I’d started doing the same thing was hard. So I took it to heart, too much so.

At a previous firm, I stepped well back. I wanted people to feel they had real autonomy, so I stopped asking enough questions and trusted that things were in hand. For the most part, this worked well and people felt empowered. On one program, however, my distance became a problem. The project team wasn’t operating at the right level, and the work started veering off course, down a technical route built on solutions that weren’t industry standard. By the time I realized the impact, those choices were hard to correct, and it was a tough price to pay.

What I learned is that accountability doesn’t delegate. You can make someone accountable for an outcome, but you still own it. Your most senior stakeholder isn’t going to say, “I know you empowered that person.” They’re going to say, “You’re the person we’re looking to.”

The fix wasn’t distance; it was a system: regular touchpoints, the right questions, and a sense check with stakeholders so I can stay out of the detail and still know we’re heading in the right direction. From a distance, empowering someone and abdicating responsibility can look the same. The key is whether you’ve built a way to know the difference.

How do you determine what to delegate, what to inspect, and what requires you to get personally involved?

It comes down to the significance of the decision, how reversible it is, and the cost of getting it wrong. Core architecture that will shape how the organization uses technology for years, complex multi-year contracts, and sizable spend are the decisions I stay close to, because ultimately, I’ll be held accountable. Everything else belongs to the team, including many of the strategic calls in their own areas, because they’re closest to the work and best placed to make them. That’s the scale I use to measure my involvement.

I think of it as changing altitude. On day-to-day delivery, I’m often at thirty thousand feet. On architecture, new platform decisions, and any technical designs that are high-stakes or hard to undo, I come right down to three hundred. The skill is knowing which altitude a decision needs, and explaining to the team why you’ve come down so it doesn’t read as a lack of trust.

The same logic applies to buy versus build. Buying a commodity is often a reversible bet, or at least a more modular one — move fast, and if it’s the wrong direction, you can change. Building is where you pour your scarce specialist talent into what differentiates you, and those decisions are typically more costly, warrant more time, and are much harder to undo, so that’s where your conviction needs to be. Ultimately, it’s knowing which decisions you can afford to get wrong and which you must get right.

I won’t pretend I’ve mastered this. Knowing when to come down and when to step back is still a work in progress for me. I notice it sooner now, and I know the best check is to ask my team whether I’ve come down too far or stayed up too long.

What do you do to give people enough context about the business, the customer, the strategy, and the tradeoffs so that they can make good decisions without your involvement?

Instructions tell people what to do in situations I’ve personally anticipated. Context helps them decide well in the ones I haven’t. If people understand the strategy, the customer, and the tradeoffs, they can make good decisions in rooms I’ll never be in.

So every year I reset the team’s strategy against the firm’s and make sure people see it before decisions start landing, not after. People like clarity, and they want to know their work contributes to the broader goals of the company. When someone can say, “What I’m working on today helps the business do this,” they bring more judgment and energy to it. That’s why I see alignment as more of a motivation problem than a governance one.

It has to run in both directions. The business needs a clear line of sight from its goals to the work we’re doing, and the team needs the same line from their daily tasks to those bigger picture goals.

And a lot of transformation isn’t glamorous. Most of it is cornfields, not mountain peaks — day after day of steady progress. Context is what keeps people moving through that stretch, because they know where it leads.

How have you learned to lead successfully by questioning rather than being the one to have all the answers, particularly when you’re surrounded by people who know more about their domains than you do?

It starts with how you ask. Good questions are open, constructive, and get quickly to the decision or information you need. Poor ones leave people feeling judged or undermined.

Many years ago, I was taught to start questions with “how” or “what” rather than “why.” “Why did you do that?” sounds like blame. “What led you there?” or “How are you thinking about the risk?” opens up a coaching conversation. I still catch myself and say, “Hold on, let me ask that a different way.”

Once you accept you’re no longer the smartest person in the room, the questions you ask matter more than the answers you give. But expertise only travels upward if disagreeing with you feels safe. I want my team thinking, “I should make Phil aware of this,” not “I’ve got to tell Phil, and I don’t know how he’s going to react.” If people trust that bad news, or a decision that didn’t work out, will be met with curiosity rather than blame, you hear what you need to know early.

There are still times to make the call yourself — when the stakes are too high, the timeline’s too tight, or the wrong decision would be hard to recover from. Knowing the difference is part of the job.

What have you learned about building a leadership team and operating model that can make great decisions, challenge one another, deliver outcomes, and continue getting better without depending on the CIO?

It starts with who you hire. I’ve long admired Patrick Lencioni’s advice in The Ideal Team Player: Look for people who are humble, hungry, and people-smart. Then invest deliberately in your people’s strengths, even though the instinct is to spend your time on whoever is struggling.

Then it’s trust within the team, enough that people will challenge one another directly. Once, at a leadership offsite, I let my team know I’d noticed decisions coming to me that I’d much rather they took to each other. It’s a very natural and common pattern. It’s easier to rely on the boss to ask the awkward question than to hold a peer accountable, but then the other person wonders why it didn’t come to them directly.

If everyone is all smiles and nodding in team meetings, you probably don’t have the culture for the harder conversations, like “I asked you for this, it didn’t happen, and here’s what that meant.” Those conversations work when everyone understands they’re about behaviors and commitments, not the person. Building that isn’t easy. But once it’s there, leaders ask each other the questions you would have asked, and hold each other to account without you in the room.

Leadership is holding people accountable. It’s also about seeing their potential. A year advisor at my high school identified a capability in me long before I saw it in myself, and it changed my path. That’s what I try to do for my team now — look for the talent someone hasn’t yet recognized in themselves and help shine a light on it. The measure of a leadership team isn’t how it performs when you’re in the room. It’s what happens when you’re not.

For more from Phil Dundas’s leadership playbook, tune in to the Tech Whisperers.

See also:

• The 7 new Cs of IT leadership for the AI era
• The rise of the AI operating executive
• How AI takes flight at GE Aerospace
• What next-generation IT leadership looks like

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

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

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

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

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

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

Compliance and transparency

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

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

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

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

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

Per-workload evaluation

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

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

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

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

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

Shared responsibility model

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

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

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

Total cost analysis

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

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

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

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

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

Where the market is heading

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

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

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

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

A focus on inference

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

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

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

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

From an enterprise perspective, AI sovereignty means complete control over the entire AI stack. For businesses with the human, technical, and monetary resources, this may be possible. For the vast majority, however, external help is required. The danger, as with any vendor relationship, is being locked in to a supplier or technology. With a mature technology that performs discrete tasks, that may not be a problem. But with an emerging and rapidly evolving one like AI and its ability to impact multiple processes across an enterprise, difficulties could arise. Gartner recently predicted that AI platform lock-in will increase from 5% now to 35% next year. So how do you avoid being in that high percentile?

1. Be clear of the trade-offs

As might be expected, there’s an inverse relationship between lock-in risks and operational overheads, including upfront costs, longer-term licensing fees, and internal talent requirements. Relying on open-source models, applications, and self-hosting is the lowest risk in terms of lock-in, but it requires a significant investment in AI engineering skills and infrastructure. In the middle, a multi-cloud or hybrid API approach provides high flexibility to swap underlying models, but relies on managing the abstraction layer. The fastest way to AI deployment is contracting a proprietary all-in-one platform requiring less operational overhead, but risks longer-term vendor dependency.

2. Break down the stack

A key priority to reduce AI lock-in is decoupling that application layer from the model layer. Deploying orchestration frameworks like LangChain or LiteLLM creates a controllable layer between the software applications an enterprise already uses, and the underlying AI models. The backend LLMs can then be swapped around as needed with minimal code rewrites. Model-agnostic architecture at this level ensures new models can be brought in as older ones become obsolete. The one certainty in AI at the moment is rapid change.

3. Keep an open mindset

Frontier models from OpenAI and Anthropic may still lead the pack in terms of performance, but open models (open weight and open source) aren’t far behind. The 2026 Stanford HAI Index shows the performance gap as 3.3%, making open models a serious option for many enterprise deployments. The overhead here is fine-tuning those models, which will usually require third-party help. Preventing this becoming a pathway to lock-in requires ensuring the weights, parameters, and training configurations remain exportable and your intellectual property.

4. Protect your crown jewels

With varying degrees of friction, all technology is replaceable but your data isn’t. Enforcing strict data portability and pipeline autonomy are the core foundations to building a sustainable AI strategy. “The only truly sovereign AI is the one that doesn’t present a new form of lock-in,” says Chris O’Brien, CTO of AI systems integrator, Advania UK. “The assets a CIO can’t substitute are their data and intelligence of how their business actually works. At that level, models are largely interchangeable unless you built your architecture around a single one.”

This requires keeping data preparation, vector databases such as Pinecone, Milvus, and Qdrant, as well as storage layers outside any single vendor’s proprietary AI cloud. Organizational knowledge stores, embeddings, and training data should be kept in open, standardized formats that can be easily re-indexed and, if necessary, migrated to a different platform.

5. Plan your exit

The market for AI products and solutions will look very different in a year’s time. Models are heading to commoditization as performance improvements shrink between generations, open-source alternatives improve, and competition among frontier model providers will likely see falling token costs. Avoiding long-term volume and/or spend commitments will help enterprises more safely navigate this rapidly evolving scene. Negotiating pay-as-you-go or short-term contracts can reduce risk as well as ensure contracts explicitly state your ownership of all prompts, inputs, outputs, and derived contextual metadata.

6. Build your internal skill base

Building core engineering expertise internally around core AI engineering standards such as Python, containerization, and API management will provide a solid foundation for future growth. Knowledge of vendor tools is important, but to build capability for an uncertain future requires foundational and adaptable skills.

Every business is unique

Eventually, AI technologies and platforms will mature into a more stable environment for businesses. Deployment decisions made now need to build in sufficient flexibility to adapt to this uncertain future. For most enterprises, SMBs in particular, there’s a massive imbalance in knowledge, resources, and skills compared to AI vendors and consultants at the leading edge of this transformation. Protecting your unique data assets and knowledge of your workflows, and the sector you operate in to build a replaceable AI layer on top of that, is the way to a more sovereign future.

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

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

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

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

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

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

Establishing data quality

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

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

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

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

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

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

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

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

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

Recognizing the potential, with limitations

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

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

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

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

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

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

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

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

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

Exploring solid use cases

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

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

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

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

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

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

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

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

When I first became a CIO, remarkably few CIOs I knew seemed to have set out to become one.

In fact, the title itself was still relatively unusual at the time. In many organizations, the most senior technology person was the IT Director. The idea of deliberately building a career towards becoming a CIO wasn’t how most of us thought about it.

We arrived there almost accidentally.

People came up through programming, infrastructure, operations, projects or business systems. Careers zigzagged rather than followed carefully designed paths. You took something on because it had broken, or because somebody had been fired, got dragged into an acquisition, found yourself negotiating a major contract, or suddenly found yourself, as I once did, standing in a boardroom trying to explain why something had gone horribly wrong.

Looking back, it was a remarkably unstructured way to develop a senior executive. But I’m beginning to wonder whether that was also its strength. Somewhere in all that career messiness, we acquired breadth.

Today we’re much better at developing technology specialists and creating defined career paths towards senior leadership. Surely that’s progress?

I’m not so sure anymore.

I’ve been guiltier than most. I’ve spent years trying to create career paths for my teams: defining roles, competency frameworks, development plans and logical routes towards leadership. It felt like exactly what a responsible CIO should be doing. Best practice, even. But I’m beginning to wonder whether, in professionalising those career paths, we’ve accidentally engineered out some of the messiness that developed us.

Not certificates. Not CPD credits. Experience.

I see this increasingly when I talk to people who want to become CIOs. An aspiring CIO will sit in front of me with a folder full of certificates, accreditations and courses they’ve completed. They can confidently explain what they’ve studied. But when I put the folder to one side and ask, “Tell me what you’ve achieved,” the conversation can become much harder.

Tell me about the transformation you led. The failing program – yes, we all have one. The acquisition you integrated. The sceptical CFO you persuaded. The commercial decision you got wrong and what you learned from it. The team you built. The board you had to convince.

That’s the experience I want to hear about.

My concern is that we’re becoming very good at helping future CIOs prove what they know, while the modern CIO role increasingly demands evidence of what they have done. And there’s the paradox: Technology careers are becoming more specialized and qualifications more structured at precisely the moment when the CIO role requires greater breadth of experience.

Worse still, much of the formal development I see aspiring CIOs undertaking seems designed to prepare them for the CIO job as it existed five years ago. The job has moved on. Specialization is getting deeper while the CIO role is getting broader

Looking back, some of the experiences that prepared me most for senior leadership weren’t things anybody would sensibly have put into a development plan. They were problems. None came with learning objectives, CPD credits or a certificate at the end. But they taught me. It wasn’t elegant career development. But it produced leaders who had accumulated scars from lots of different battles.

Today, technology careers look very different. We have increasingly sophisticated specialisms in cloud, cybersecurity, data, AI, product, architecture, engineering, digital experience and platform operations. Those disciplines need deep expertise, and specialization has undoubtedly made technology organizations more professional. But there is an unintended consequence. Someone can now spend 10 or 15 years becoming extraordinarily good at one part of technology without ever really needing to understand how the whole organization works.

That’s not necessarily a problem for a specialist. It becomes a problem when we expect them to become an enterprise leader. Because the CIO job is moving in precisely the opposite direction.

CIO’s 2025 State of the CIO research found that 81% of IT leaders described themselves as change makers responsible for championing both business and technology initiatives. Seventy-seven percent said they had developed a strong educational partnership with the CEO and board.

That’s not describing an AI, cloud or cybersecurity specialist. It’s describing an enterprise leader.

Are we still developing CIOs for yesterday’s job?

I think there’s another problem. When organizations deliberately prepare people for technology leadership, much of the curriculum still reflects what we historically believed a CIO needed to know. Technology strategy. Architecture. Cybersecurity. Operating models. Cloud. Governance. Program delivery. Data.

Important? Absolutely. But increasingly they’re the entry ticket, not the differentiator.

Deloitte’s research into contemporary CIOs illustrates the shift. It contrasts the conventional CIO, technical expert and internal technology provider, with a contemporary leader expected to enable transformation, create topline value, take appropriate risks and influence business strategy.

The expectations keep expanding. Deloitte reported in late 2025 that 80% of technology executives surveyed said their roles had significantly expanded to meet business objectives, more than a third were managing a P&L, and 65% of CIOs reported directly to the CEO. That requires a very different development model.

The modern CIO needs to understand technology, certainly. But they also need to understand how their organization makes money. They need to understand a P&L, cash flow, capital allocation and investment cases. What the hell is EBITDA? Well, they should probably know.

I’ve come to realize that being a CIO is as much about everything outside technology as it is about technology itself. I need to understand customers. I need to be able to negotiate. I need to influence people over whom I have absolutely no authority. I need to know when to challenge the CEO,  and when a particular hill simply isn’t worth dying on. I need to be able to walk into a board meeting and explain a complex technology risk without drowning everyone in acronyms, but equally without simplifying it to the point where it becomes meaningless.

Over the years, I’ve also had to understand acquisitions, regulation, geopolitics, organizational design, workforce transformation and commercial strategy. None of those things would once have been considered core technology disciplines. Today, I’d struggle to imagine being an effective CIO without understanding them.

And then, of course, AI arrived and somehow made an already broad job broader again. CIO.com recently reported that in more than 75% of enterprise CIO searches conducted by executive-search firm Caldwell, candidates are now expected to be “board ready”, able to engage directors strategically and speak the language of business leadership.

That phrase interests me. Because I’m not convinced you become “board ready” by completing a module on board communication and receiving a certificate. You become board-ready partly by accumulating enough experience to understand what the other people around that table are worried about.

We need to manufacture the breadth that careers no longer provide. This doesn’t mean recreating the career chaos of the past. I certainly wouldn’t advocate deliberately putting someone onto a failing transformation program for three years because it will be character-building. But we should recognize what those messy careers accidentally provided and deliberately recreate the useful parts.

My concern is that we’re becoming very good at helping future CIOs prove what they know, while the modern CIO role increasingly demands evidence of what they have done. Increasingly, I think the gaps in a future CIO’s experience may tell us more about their readiness than the certificates they’ve collected.

The question I ultimately want answered is simple: Have they experienced enough of the business to understand how the whole organization sees the world,  not just how technology sees it?

If the answer is no, that’s where I’d start their development. Instead of building development primarily around knowledge, we should build much more of it around exposure.

That means deliberately engineering breadth rather than hoping someone picks it up along the way. If I were developing a potential CIO today, I might move them out of technology for a period and give them real responsibility in a business unit with a P&L; put them into a major transformation where success depends as much on people, customers and commercial decisions as it does on technology; and make them part of an acquisition from due diligence through integration. I’d want them negotiating a difficult supplier deal, defending an investment in front of the CFO and presenting to the board when the answer isn’t straightforward. These shouldn’t be observational placements or a week spent shadowing another executive. Give them something to own, decisions to make and consequences to live with. In other words, if modern careers no longer accidentally create breadth, organizations need to manufacture it deliberately.

Some of it can be taught. Much more of it has to be experienced. Technical depth remains enormously important. A CIO without sufficient technology understanding will struggle to challenge their organization intelligently.

Technical credibility and technical specialization aren’t the same thing

The CIO increasingly needs to be able to zoom out. Enough technical understanding to ask the difficult question of an architect. Enough financial understanding to challenge the business case. Enough commercial understanding to see the opportunity. Enough organizational understanding to recognize why the change might fail — and enough influence to bring everyone with them anyway.

Perhaps the accidental CIO wasn’t such an accident after all. We spent decades creating technology leaders through careers that were messy, unpredictable and broad. Now we’re creating clearer pathways, deeper specialisms and more structured professional development. That’s progress. But we should be careful not to optimize away the very experiences that made many of the previous generation effective.

The challenge isn’t to bring back the accidental CIO.

It’s to work out how to deliberately create the breadth that accident used to provide.

AI is moving quickly across organizations. Companies are scaling existing use cases, introducing new tools and giving more employees access to AI as they look for ways to improve efficiency and stay competitive.

That expansion is making AI governance a shared responsibility. CIOs are responsible for helping their organizations adopt the technology effectively and securely. Legal teams are increasingly focused on the litigation, regulatory, privacy and compliance risks associated with its use.

As AI reaches more parts of the business, these teams need to work closely together. Each has visibility and expertise the other needs, and both have an important role in helping the organization scale AI responsibly.

AI has changed the relationship between IT and legal

AI touches nearly every part of a business. It can involve company and customer data, influence decisions, interact directly with employees or customers, and perform work through agents.

Agents, in particular, have changed the governance equation over the past year. When companies were primarily piloting AI, much of that experimentation happened within IT. Those teams were accustomed to working within security, data and compliance requirements. Now organizations are under pressure to scale AI beyond those controlled environments.

That shift is already well underway. McKinsey’s 2025 State of AI survey found that 88% of respondents said their organizations regularly use AI in at least one business function, up from 78% the year before.

I see that pressure from both sides. As a CEO and a member of several boards, I push companies to use AI because I believe failing to adopt it effectively poses a serious competitive risk. But that same push for adoption makes governance more important, not less. CIOs are being asked to expand AI use while simultaneously managing risks that become harder to see as adoption spreads.

The strength of AI agents is that nontechnical employees can use them to build workflows and automate work. People in HR, finance, marketing, communications and other departments no longer need to wait for IT to develop every AI-enabled process. That accessibility creates enormous opportunity, but it also means AI can be deployed by employees who aren’t accustomed to evaluating security, compliance, privacy or legal risk.

Organizations therefore need to know what data an AI system is using, where that data came from, what decisions the system is making, and whether those uses align with company policies and legal requirements.

AI may also be embedded in third-party products an organization already uses. This creates shadow AI, where organizations may have AI operating without a complete understanding of where or how it is being used.

This is one of the biggest areas of risk we see. When we work with organizations that have five or 10 approved AI use cases, those applications usually aren’t where we find the most significant problems. The company already recognized those use cases as potentially risky, so someone evaluated them. The greater risk often comes from the AI the organization doesn’t realize is operating at all.

Understanding how AI is being used across the organization gives CIOs and legal teams a place to start.

AI requires closer collaboration

Legal teams are becoming increasingly aware of the exposure AI can create. There are new AI laws and regulations developing around the world, along with significant litigation happening under laws that already exist.

That concern is showing up among corporate legal leaders. In Norton Rose Fulbright’s 2025 Annual Litigation Trends Survey, 56% of respondents said managing the litigation and legal risks surrounding generative AI had been a challenge for their organization.

Many of those lawsuits involve familiar legal issues, including discrimination, consumer protection, privacy, wiretap laws and consent to use data. AI is simply the context in which those existing issues are now arising. There is no broad exemption from existing law simply because a decision or activity involves AI.

That legal risk isn’t always well understood throughout the rest of the organization. I recently met with a large retailer that had its CIO, COO, technical leaders, business leaders and an attorney in the room to discuss AI governance. When I raised litigation risk, much of the group wasn’t particularly concerned. The attorney was.

She explained that legal was deeply concerned about the company’s exposure and that the company had already faced an AI-related lawsuit. Several other people in the room didn’t know that had happened.

That type of disconnect matters as organizations scale AI. Legal may have information about litigation, regulation, contracts and privacy concerns that hasn’t reached the people making technology decisions. IT has visibility into systems, vendors, data, security and how AI is being deployed across the business.

Regular collaboration gives both groups a more complete understanding of what the organization is doing and where its risks are.

What CIOs and legal teams bring to AI governance

CIOs and technology leaders have an important role in creating visibility around AI. They can help organizations identify the systems and use cases already in place, including internally developed AI, third-party tools, vendor applications and shadow AI.

They also understand the organization’s technology environment. That includes its security requirements, data infrastructure, technical standards and the practical considerations involved in deploying AI at scale.

Legal teams bring a detailed understanding of the legal risks surrounding those same use cases. They can help determine which regulatory requirements apply, identify privacy or intellectual property concerns, review contractual obligations and evaluate whether the organization has the right to use particular data.

In large organizations, the attorney most familiar with AI risk may not be the chief legal officer. It may be a deputy counsel or another member of the department who has been following the issue closely. At smaller companies, it may be one attorney managing AI alongside dozens of other responsibilities. Making AI risk part of the broader conversation gives that legal expertise a way to reach the people responsible for adoption.

Building a partnership between CIOs and legal teams

A strong AI governance program brings these groups together as part of an ongoing process. Many organizations are doing this through an AI governance committee that includes IT, legal, compliance, security and representatives from business units using AI. The committee can review use cases, apply company policies, evaluate risks and determine what safeguards are appropriate.

That work starts with a comprehensive inventory of AI use across the organization. For each use case, the organization should understand what the technology does, what data it uses and what decisions it makes.

The use case itself matters because the same underlying technology can carry dramatically different levels of risk depending on how it is applied. Using generative AI to draft promotional copy about a city, for example, presents a very different risk profile than using it to prepare information that will be submitted to a federal regulator.

From there, the committee can evaluate the use case against company policies and identify areas that need to be addressed. If a resume-screening tool creates a risk of bias or discrimination, for example, the organization may decide to test it regularly or require human review. If an application uses sensitive data, the team needs to understand where that data came from and whether it can legally and securely be used.

The process also needs to be documented. Leaders often believe AI governance means documenting good intentions. Regulators and litigants will care about whether those intentions were operationalized, continuously enforced and supported by evidence.

Company policies are part of that documentation. If a policy requires a human in the loop for certain risk levels, the organization needs to follow that requirement and be able to demonstrate that it did.

Shared visibility makes this process easier. CIOs, legal teams, compliance, security and business leaders should be working from the same understanding of the organization’s AI systems, use cases, policies, risk assessments and approvals. This gives the governance committee the information it needs to make decisions as AI adoption continues to grow.

AI governance requires a shared approach

AI will continue reaching more systems, business functions, vendors and employees. That makes collaboration across the organization an increasingly important part of governing it well.

CIOs understand how the technology is being deployed and what it takes to scale it. Legal teams understand the laws, litigation and other areas of exposure surrounding that use. Bringing that knowledge together gives organizations a clearer view of their AI environment and a stronger process for evaluating new use cases as they emerge.

AI has enormous potential, and companies need to find ways to use it effectively. Scaling it safely requires safeguards and governance to be built into adoption from the beginning and maintained as AI use expands.

For companies expanding their AI usage, such a shared approach provides the structure needed to keep up with the technology and the risks that come with it.