Every CIO I speak with today is wrestling with some version of the same question: How do we move faster with AI and deliver on our commitments?

It’s an understandable concern. Boards and CEOs are asking about AI. Business leaders are experimenting with use cases. Employees are discovering tools daily, while technology vendors promise unprecedented gains in productivity, innovation, and competitive advantage.

After hundreds of conversations with technology executives over the past year, I’ve become convinced that speed isn’t the real issue. The organizations pulling away from the pack aren’t necessarily adopting AI faster than everyone else. They’re executing more effectively — a subtle distinction that represents one of the defining leadership challenges of the AI era.

Technology has never been the hardest part of transformation. People, priorities, culture, and operating models are the biggest challenges. The ability to translate bold boardroom aspirations into thousands of thoughtful decisions made every day by architects, engineers, product managers, analysts, and business leaders is where competitive advantage is created. AI may be accelerating the pace of change, but it hasn’t changed that fundamental truth.

I’ve met plenty of executives who are exceptional in the boardroom. They know how to frame a vision, influence a board, and build confidence among investors and business leaders. I’ve also met remarkable technologists who instinctively understand the architectural decisions, engineering tradeoffs, and implementation details that determine how great ideas become reality. Modern CIOs, however, must move comfortably between both worlds. Afshean Talasaz is one who stands out among this rare breed.

Long before becoming CIO of Colonial Pipeline, Talasaz built his career from the ground up as a business professional, data scientist, and technologist. He has designed enterprise platforms, built AI capabilities, led technology organizations, and partnered closely with executive leadership teams on business transformation. Today, as an executive in residence with our Practitioners for Practitioners (P4P) community, he helps CIOs and business leaders navigate one of the most significant technology shifts of our generation.

While Talasaz brings deep knowledge of data and AI to the table, his greatest strength is his ability to create strategy and connect it with execution. He can spend the morning discussing enterprise reinvention with the board and the afternoon debating architectural principles with the teams responsible for bringing that vision to life.

That versatility gives Talasaz a unique lens on how CIOs can deliver value with AI.

Software companies have a term for engineers who understand every layer of the technology stack: full-stack developers. Listen to Talasaz and it becomes evident that the AI era requires something similar from technology leaders: a full-stack CIO.

The full-stack CIO: Leading with clarity

A full-stack CIO understands how every layer of the enterprise influences the next. They recognize that every strategic priority becomes a portfolio investment, every investment shapes an operating model, every operating model influences architecture, every architecture choice informs product decisions, every product decision shapes engineering priorities.

The best CIOs understand both ends of that journey. The extraordinary ones understand everything in between.

And those who execute best lead with clarity, Talasaz says.

“Everyone, from executives to middle managers to the people writing code, should be able to explain what we’re trying to achieve,” he emphasizes. “Clarity isn’t that we’ve handed out the PowerPoint. It’s that people genuinely understand where we’re going and can articulate it in their own language.”

One of the unintended consequences of the AI boom is that organizations are beginning to confuse activity with alignment. They have AI councils, AI governance committees, AI innovation labs, AI centers of excellence, AI pilots, and AI roadmaps. Yet if you stop ten people in the hallway and ask a deceptively simple question, What business problem are we actually trying to solve? you’ll often hear ten different answers.

As a result, architects optimize for one objective while product teams optimize for another. Business units pursue opportunities that seem perfectly reasonable from their perspective. Engineers make thoughtful technical decisions based on the information available to them. Individually, none of those decisions are necessarily wrong. Collectively, however, they create organizational drift. AI doesn’t create that problem. It simply accelerates the consequences.

And while AI can be a force multiplier for the positive when every decision is guided by a shared understanding of where the organization is headed, it can also be a force multiplier for the negative, resulting in an organization simply moving faster in different directions.

“When we have the fundamentals right, the tech infrastructure, the operating models, the nuances of how our business actually runs, we get the impacts of AI in a positive way,” Talasaz says. “When we don’t have those in place, AI can amplify the gaps or mute the benefits.”

At a time when so much of the conversation surrounding AI is focused on algorithms, agents, and automation, it’s an important reminder that organizations don’t execute strategy; people do.

Reducing organizational friction

Most executives are familiar with the concept of VUCA that characterizes today’s business environment. But Talasaz stresses the importance of turning this concern inward: “If the world outside our organizations is becoming more volatile, uncertain, complex, and ambiguous, what are we, as leaders, doing to the inside of our organizations?”

Leaders spend enormous amounts of time helping their organizations respond to external disruption but comparatively little time asking whether they are inadvertently re-creating those same conditions internally in response to those external needs. Are we reducing uncertainty or introducing more of it? Are we simplifying work or adding unnecessary complexity? Are we helping people focus on what matters most, or asking them to navigate competing priorities and shifting expectations?

Talasaz refers to this phenomenon as double VUCA — something I’ve witnessed repeatedly while working with CIOs over the past decade. Organizations often assume they’re struggling because of technology limitations when the real constraint is organizational friction. Teams wait for decisions. Priorities shift faster than roadmaps. Governance grows heavier. New committees are formed to solve problems created by existing committees. Everyone is working harder, yet the organization somehow feels slower.

AI amplifies both outcomes. Organizations with clarity become dramatically more effective because AI accelerates good decisions. Organizations without clarity simply accelerate confusion.

Operating model as strategy enabler

AI governance is one way to achieve greater clarity, but as Talasaz says, governance shouldn’t primarily exist inside policy manuals that few people read.

Instead, AI governance should be embedded in the daily rhythms of the organization, shaping how teams collaborate, how decisions are made, how products move from ideas into production, and how innovation happens safely without requiring constant escalation. In other words, it’s all about your operating model.

“If you had to pick one thing that isn’t technology, your operating model is the most important element for executing data and AI at scale,” he says.

The best operating models create enough clarity that capable people can make thousands of decisions independently and confidently, without having to wait for permission. By embedding good governance into the way it works, the organization becomes faster.

This advice echoes something I’ve heard repeatedly from some of the world’s most respected CIOs: High-performing organizations aren’t built on tighter control; they’re built on greater trust, supported by clear principles, shared expectations, and operating models that enable responsible decision-making at every level of the enterprise.

Talasaz points out that technology leaders tend to speak in terms of transformation. He suggests CIOs consider a different word: reinvention.

As he explains, transformation implies replacing what exists today with something new. Reinvention starts with a more clear-eyed and practical premise: Some things absolutely must change; others represent years, sometimes decades, of accumulated expertise, customer trust, operational discipline, and competitive advantage.

Reinvention is about building on those strengths while also creating new ways to deliver value. The leaders making the greatest progress in their AI journeys seem to recognize that it’s less about abandoning the past than thoughtfully preparing the organization for the future.

Closing the gap between strategy and execution

Full-stack CIOs must be able to map out the various layers of execution and planning that need to be done at every level of the organization to be successful. To help with this, Talasaz has developed a data and AI framework that draws on his own experiences “from the keyboard to the boardroom.”

As Talasaz sees it, too many organizations have been doing good work in isolation. “They’re doing a lot of the right things,” he says. “They’re just not connected.”

Boards may be discussing growth while business leaders redesign customer experiences. Product teams may be prioritizing new capabilities while architects modernize platforms. Data teams may be improving quality while engineers focus on delivery. Every group makes meaningful progress within its own domain, yet somewhere between strategy and execution, the connective tissue begins to disappear. Talasaz’s framework brings those connecting points to the forefront.

Crucially, the framework doesn’t begin with technology or AI or even with data. It begins with the experiences the organization hopes to create for its customers, employees, or partners. Many AI initiatives start with the question, “What can this technology do?” And indeed, we need to be inspired by the possibilities and challenged to think differently by what the technology can do. But, Talasaz emphasizes, we also need to ask what experiences we need to deliver for our business and how the technology can make that a reality.

The framework challenges CIOs to answer that question first. Only after the experiences are clearly defined does the conversation move to the capabilities required to deliver it, the business activities that support those capabilities, the AI and data products that enable them, and finally the data foundation that makes everything possible.

This shift in perspective ensures that, rather than allowing technology investments to search for business value, the business experience defines the technology required to deliver it. For CIOs, that’s more than a planning exercise. It’s a fundamentally different way of leading.

Over the coming months, the P4P community will be convening a series of small CxO roundtables to explore these issues and work more deeply with Afshean Talasaz’s 6×6 Data and AI Framework. CIOs and other enterprise leaders interested in participating are welcome to reach out to me directly.

When it comes to building an effective AI stack, context is king and power isn’t everything it’s cracked up to be.

“Smaller, smarter, safer — this is a bet our company has taken in how we deploy AI internally,” said Ricky Thakrar, head of sales and account management at Zoho, provider of a suite of popular cloud-based software solutions for sales, marketing, and finance.

“I’m on the business side, and so decisions made by our CIO and IT folks affect me directly, and my teams’ workflows and processes,” he added.

Speaking to a room of tech leaders at the CIO 100 Leadership Live New York event last week, Thakrar explained that every company wants the speed of AI-generated work wedded to the quality of human work, even though these two are diametrically opposed. No amount of model upgrades or spend will close that gap, so the only way forward is to architect your way out. Thakrar encapsulated this idea in a simple formula:

• Smaller: Stop deploying maximum firepower on every task. Many tasks don’t need it.
• Smarter: The system around the model decides more than the model does.
• Safer: Verify at the point a mistake gets locked in, not just downstream of it.

He noted that organizations that win with AI won’t be those deploying the biggest, most powerful models or the most sophisticated architecture, but the ones that figure out that the model is the easy part and the right architecture is harder. That means understanding the hardest element, and the biggest differentiator, is building a human system that learns and compounds alongside agentic systems.

To get it right, organizations need to prioritize the context layer. The size of frontier models like the GPT series, Claude, and Gemini mostly exist to compensate for missing context, Thakrar explained. Without enough context, models need to be able to reason harder and infer more about what a user actually means because it doesn’t know the user’s account, process, or history. A rich context layer makes it possible for enterprises to run workloads on much smaller, lower-power models.

“The intelligence moves from the model into the architecture around it,” he said.

A steep learning curve

One of Zoho’s earliest AI agents was a churn management agent to help the account management team detect churn in customer subscriptions. So when a subscription became inactive, the agent would collect context from notes, meeting recordings, and Zoho’s data enrichment tool, then create a summary of reasons the account might have churned, and schedule a call.

“What happened was I got this churn agent a couple months later, already embedded in our CRM, and within a week my team no longer trusted that agent,” Thakrar said. “The reason is we forgot to collect one very key point.”

In Zoho’s CRM, when a customer buys a bundle of products, that bundle is represented as a single line item. That means the status of any products the customer may have previously purchased individually changes to inactive as they’re moved to the bundle. That’s not churn, but it was interpreted it that way. Zoho fixed it in the second version of the agent.

Then a new problem arose. Many potential customers first purchase Zoho products as pilots or sandboxes. As those customers move from pilot to live instance, they close down the pilot versions. And again, the CRM would record that as subscriptions going inactive.

“The trust deteriorates again because everyone got excited for version 2,” Thakrar said.

Sometimes, a certain product might not be the best fit for a customer and Thakrar’s team will suggest the customer move to another product. That’s deliberate churn, not a churn risk.

“You may have a similar story like this where the agent sounds so good, it’s going to do something quick and add value, but it’s missing context from the account managers, and there are so many more pieces we’re still building out,” Thakrar said. “It’s been almost a year and the problem I have is my team still doesn’t trust it. They’ll see [a message from the agent] and go out and do all the research anyway to make sure it gave the correct answer.”

The team is more on top of potential churn, though, but the promised productivity gains have yet to materialize because the agent has to earn back lost trust due to a lack of context.

“My goal for this year is having an AI-assisted customer journey from sales to account management where the handoff is clean, the context flows, and every piece of information we gather about a customer is weighed, identified, and coached so the sales team can close more deals,” he said.

Zoho’s early experience with agents has led to the idea that constrained, context-rich, deterministic architectures consistently outperform expensive models bolted onto fragmented systems. It all comes down to three pillars: routing, harness, and specialization.

Routing

Routing is about sending workloads to the proper model for the job, which entails providing enough context to a given task that a small, cheap model can handle it without the need for spare reasoning capacity to fill gaps.

Frontier models are expensive and companies can burn through a year’s budget worth of tokens in months. But most tasks can be handled by much smaller, more constrained models at a fraction of the cost.

“You don’t always have to pay the frontier guys for every task,” he said. “We’ve observed with some clients that we could save them 95% with a 3 billion parameter model.”

Harness

An AI agent harness is the software infrastructure scaffolding around an LLM that differentiates an agent from a chatbot. It’s what enables an agent to act on tasks rather than simply respond to prompts. A model reasons through a problem and decides what to do about it. The harness connects the model to the tools, systems, memory, guardrails, and execution environments required to perform the actions determined by the model. The term is frequently used more or less interchangeably with orchestration layer.

“It’s the process around the model, which matters way more than the model itself,” Thakrar said.

In benchmark tests, a superior harness on a less powerful model produces better results than an inferior harness on a much bigger model.

For the best results, Thakrar said, it’s essential to understand the deterministic and non-deterministic elements of a given workload, and build that into the architecture. Machines can read, organize, and validate, and they excel at deterministic tasks. Humans, on the other hand, are exceptional at non-deterministic tasks like judging, synthesizing, and deciding.

Those non-deterministic tasks in a process are the ideal point for AI agents to incorporate a human in the loop, what Thakrar calls human harness. He pointed to a stakeholder mapping agent Zoho built for sales as an example, which takes the context of an initial meeting and third-party enriched data like a LinkedIn profile, weighs probabilities, and makes an educated guess about the stakeholder map.

“The initial goal was just to eliminate that task completely from the human workflow,” he said. “The stakeholder map is done, it’s in the folder, and you can look at it.”

But the agent would struggle to capture nuance. The meanings of titles in organizations always vary, and the politics and dynamics of any given meeting can be difficult for an AI agent to discern. Rather than keep feeding the agent data to try to make it intelligent enough to make those determinations, it was simpler and more efficient for the agent to create a proposed stakeholder map and hand it over to a human who could make changes and explain why those changes were necessary.

Ultimately, Thakrar said the agent still saved human team members time because the stakeholder map was usually pretty close, and the corrections also helped the model grow smarter by adding richer context.

Specialization

Specialization is transitioning a process from testing on a frontier model to production on a much narrower, smaller model. Once you’ve proven that an agent can do a job well, you want to stop paying master-craftsman rates to keep doing that one job well.

Specialization is all about capturing your subject matter experts’ best judgement and pattern recognition to build an open-weight, open source, trained, and fine-tuned model that can be deployed in your own data center.

“The true enterprise bet is to keep that orchestration layer, which is your IP and knowledge, in house,” Thakrar said. “You don’t want to host that on someone else’s model. The goal of everyone in enterprise should be to run, train, and host their own models.”

The evolution of Java is the subject of a just-released documentary about the programming language and development platform. “The Java Story: The Official Documentary” tells the story of Java through interviews with the engineers who created it and shepherded it through three decades.

Produced by CultRepo and sponsored by Oracle, JetBrains, IBM, and Azul, the documentary follows Java from its set-top box and browser-based origins at Sun Microsystems in the 1990s and through its rise to dominate server-side computing in the 2000s, the “dark ages” and resurgence with Java 8 under Oracle in the 2010s, and its continuing modernization and promising role in AI today. “From its humble beginnings as a project code-named ‘Oak’ at Sun Microsystems to becoming a global standard for enterprise software and billions of devices, Java’s journey is one of radical innovation, strategic pivots, and enduring community strength,” said Cult.Repo.

The documentary also delves into Sun’s bitter Java licensing dispute with Microsoft, Oracle’s suit of Google over its use of Java APIs Android (Google won), the creation of the Java Community Process, Sun’s open-sourcing of Java, and Oracle’s switch to the six-month release cycle. Technical enhancements such as lambda expressions in Java 8, virtual threads in Java 21 (Project Loom), and the ongoing refactor to bring value objects to the Java object model (Project Valhalla) also get attention.

Technical experts and other Java figures interviewed in the documentary include James Gosling, creator of Java; Kim Polese, Java’s first product manager; Carla Schroer, director of Java compatibility at Sun Microsystems; James Duncan Davidson, creator of Apache Tomcat; Mark Reinhold, chief architect of the Java Platform Group at Oracle; Brian Goetz, Java language architect in the Java Platform Group at Oracle; Rod Johnson, creator of Spring; and Gavin King, creator of Hibernate.

The cybersecurity landscape has evolved beyond human scale. Today’s adversaries have replaced predictable, manual playbooks with machine-generated attack chains that can breach traditional controls in seconds. To bridge the gap, organizations must move past legacy, reactive controls and embrace a fundamentally different, AI-driven architecture: Agentic Endpoint Security (AES). 

AES represents a paradigm shift, moving security from a passive monitor to an active participant in the defense lifecycle. It provides the visibility and automated guardrails necessary to govern autonomous AI agents and agentic tools, ensuring that as your workforce scales with AI, your security posture remains unbreakable. 

With autonomous AI agents now capable of planning and executing multi-stage attacks at machine speed, the pressure on traditional security operations (SOC) has reached a breaking point. To survive this shift, the strategy is clear: we must fight AI with AI. 

Here is how AI-driven defense, pioneered by Cortex XDR and the era of Agentic Endpoint Security, is fundamentally rewriting the cybersecurity playbook.

1. From reactive patching to proactive prevention 

For decades, the industry lived in a “wait-and-see” mode waiting for a vulnerability to surface, waiting for a signature, and then rushing to patch the hole. But reactive methods just don’t hold up against modern “frontier” AI attacks that are constantly morphing. 

AI-driven defense changes the game by shifting to a prevention-first architecture. Rather than relying on historical signatures, modern platforms deploy localized, ML-driven analysis to evaluate the intent and behavior of an active process, stopping threats pre-execution. Cortex XDR leads with a strict prevention-first approach by using AI-driven local analysis and behavioral threat protection; the XDR agent stops sophisticated threats pre-impact and pre-execution. This proactive stance reduces the overall risk profile by blocking malicious chains of events in real time across network, process, file, and registry activity. 

2. Eliminating the “agentic blind spot” 

As we all rush to adopt generative AI and automated workflows, a new gap has appeared: the “agentic blind spot.” Adversaries are now targeting AI assistants and automated scripts to bypass defenses. Since these digital agents often have deep access to enterprise data, a compromise here lets attackers move completely under the radar. 

The new playbook requires securing this entire ecosystem. By combining the distinct capabilities of Cortex XDR and Koi Security, organizations can effectively close this gap. Koi Agentic Endpoint Security tracks everything from shell commands to prompts in real time, while Cortex XDR adds a layer of defense that identifies and neutralizes behavioral anomalies unique to these automated threats. 

3. Machine-speed detection and “attack storylines” 

When an attacker can move through your network in seconds, human-led teams can’t keep up. To make matters worse, most systems just flood analysts with low-quality, isolated alerts, leading to major burnout. 

AI-driven defense fixes the investigation process by automatically stitching separate data points into a single, high-fidelity “attack storyline.” Cortex XDR uses thousands of machine learning detectors across endpoint, network, and cloud sources to group related signals into one cohesive case. This reveals the full story of an attack, letting your analysts focus on fast remediation instead of digging through piles of data, reducing alert noise by up to 98%. 

4. Surgical and autonomous response 

The final piece of the puzzle is moving from manual remediation to autonomous action. AI-driven response lets your SOC handle threats in minutes, not hours. The platform can automatically revoke compromised tokens or isolate endpoints at machine speed. 

Cortex XDR delivers built-in enterprise-grade automation at no additional cost, providing over 120 out-of-the-box playbooks and 18 quick actions to handle up to 99% of incidents without manual intervention. Crucially, this level of automation requires an unbreakable foundation of agent resilience. To ensure the defense cannot be disabled by an adversary, Cortex XDR is certified in both the AVC EDR Detection and Anti-Tampering tests, successfully blocking all attempts to disable or modify the agent. 

Summary

The threat landscape is changing faster than ever, driven by AI-powered attackers who exploit even the smallest gaps. But you don’t have to stay on the defensive. By shifting to a proactive, AI-driven architecture like the one built into Cortex XDR, you can stop threats before they happen, secure your agentic workflows, and automate away the noise that leads to analyst burnout. 

The journey to a more resilient, AI-powered SOC doesn’t have to be daunting. With the right foundation in place, you’re not just keeping pace with the new threat landscape; you’re staying one step ahead. It’s time to move beyond the old manual playbook and embrace the future of security operations. 

To learn more about Palto Alto Networks, visit https://www.paloaltonetworks.com.

When it comes to building an effective AI stack, context is king and power isn’t everything it’s cracked up to be.

“Smaller, smarter, safer — this is a bet our company has taken in how we deploy AI internally,” said Ricky Thakrar, head of sales and account management at Zoho, provider of a suite of popular cloud-based software solutions for sales, marketing, and finance.

“I’m on the business side, and so decisions made by our CIO and IT folks affect me directly, and my teams’ workflows and processes,” he added.

Speaking to a room of tech leaders at the CIO 100 Leadership Live New York event last week, Thakrar explained that every company wants the speed of AI-generated work wedded to the quality of human work, even though these two are diametrically opposed. No amount of model upgrades or spend will close that gap, so the only way forward is to architect your way out. Thakrar encapsulated this idea in a simple formula:

• Smaller: Stop deploying maximum firepower on every task. Many tasks don’t need it.
• Smarter: The system around the model decides more than the model does.
• Safer: Verify at the point a mistake gets locked in, not just downstream of it.

He noted that organizations that win with AI won’t be those deploying the biggest, most powerful models or the most sophisticated architecture, but the ones that figure out that the model is the easy part and the right architecture is harder. That means understanding the hardest element, and the biggest differentiator, is building a human system that learns and compounds alongside agentic systems.

To get it right, organizations need to prioritize the context layer. The size of frontier models like the GPT series, Claude, and Gemini mostly exist to compensate for missing context, Thakrar explained. Without enough context, models need to be able to reason harder and infer more about what a user actually means because it doesn’t know the user’s account, process, or history. A rich context layer makes it possible for enterprises to run workloads on much smaller, lower-power models.

“The intelligence moves from the model into the architecture around it,” he said.

A steep learning curve

One of Zoho’s earliest AI agents was a churn management agent to help the account management team detect churn in customer subscriptions. So when a subscription became inactive, the agent would collect context from notes, meeting recordings, and Zoho’s data enrichment tool, then create a summary of reasons the account might have churned, and schedule a call.

“What happened was I got this churn agent a couple months later, already embedded in our CRM, and within a week my team no longer trusted that agent,” Thakrar said. “The reason is we forgot to collect one very key point.”

In Zoho’s CRM, when a customer buys a bundle of products, that bundle is represented as a single line item. That means the status of any products the customer may have previously purchased individually changes to inactive as they’re moved to the bundle. That’s not churn, but it was interpreted it that way. Zoho fixed it in the second version of the agent.

Then a new problem arose. Many potential customers first purchase Zoho products as pilots or sandboxes. As those customers move from pilot to live instance, they close down the pilot versions. And again, the CRM would record that as subscriptions going inactive.

“The trust deteriorates again because everyone got excited for version 2,” Thakrar said.

Sometimes, a certain product might not be the best fit for a customer and Thakrar’s team will suggest the customer move to another product. That’s deliberate churn, not a churn risk.

“You may have a similar story like this where the agent sounds so good, it’s going to do something quick and add value, but it’s missing context from the account managers, and there are so many more pieces we’re still building out,” Thakrar said. “It’s been almost a year and the problem I have is my team still doesn’t trust it. They’ll see [a message from the agent] and go out and do all the research anyway to make sure it gave the correct answer.”

The team is more on top of potential churn, though, but the promised productivity gains have yet to materialize because the agent has to earn back lost trust due to a lack of context.

“My goal for this year is having an AI-assisted customer journey from sales to account management where the handoff is clean, the context flows, and every piece of information we gather about a customer is weighed, identified, and coached so the sales team can close more deals,” he said.

Zoho’s early experience with agents has led to the idea that constrained, context-rich, deterministic architectures consistently outperform expensive models bolted onto fragmented systems. It all comes down to three pillars: routing, harness, and specialization.

Routing

Routing is about sending workloads to the proper model for the job, which entails providing enough context to a given task that a small, cheap model can handle it without the need for spare reasoning capacity to fill gaps.

Frontier models are expensive and companies can burn through a year’s budget worth of tokens in months. But most tasks can be handled by much smaller, more constrained models at a fraction of the cost.

“You don’t always have to pay the frontier guys for every task,” he said. “We’ve observed with some clients that we could save them 95% with a 3 billion parameter model.”

Harness

An AI agent harness is the software infrastructure scaffolding around an LLM that differentiates an agent from a chatbot. It’s what enables an agent to act on tasks rather than simply respond to prompts. A model reasons through a problem and decides what to do about it. The harness connects the model to the tools, systems, memory, guardrails, and execution environments required to perform the actions determined by the model. The term is frequently used more or less interchangeably with orchestration layer.

“It’s the process around the model, which matters way more than the model itself,” Thakrar said.

In benchmark tests, a superior harness on a less powerful model produces better results than an inferior harness on a much bigger model.

For the best results, Thakrar said, it’s essential to understand the deterministic and non-deterministic elements of a given workload, and build that into the architecture. Machines can read, organize, and validate, and they excel at deterministic tasks. Humans, on the other hand, are exceptional at non-deterministic tasks like judging, synthesizing, and deciding.

Those non-deterministic tasks in a process are the ideal point for AI agents to incorporate a human in the loop, what Thakrar calls human harness. He pointed to a stakeholder mapping agent Zoho built for sales as an example, which takes the context of an initial meeting and third-party enriched data like a LinkedIn profile, weighs probabilities, and makes an educated guess about the stakeholder map.

“The initial goal was just to eliminate that task completely from the human workflow,” he said. “The stakeholder map is done, it’s in the folder, and you can look at it.”

But the agent would struggle to capture nuance. The meanings of titles in organizations always vary, and the politics and dynamics of any given meeting can be difficult for an AI agent to discern. Rather than keep feeding the agent data to try to make it intelligent enough to make those determinations, it was simpler and more efficient for the agent to create a proposed stakeholder map and hand it over to a human who could make changes and explain why those changes were necessary.

Ultimately, Thakrar said the agent still saved human team members time because the stakeholder map was usually pretty close, and the corrections also helped the model grow smarter by adding richer context.

Specialization

Specialization is transitioning a process from testing on a frontier model to production on a much narrower, smaller model. Once you’ve proven that an agent can do a job well, you want to stop paying master-craftsman rates to keep doing that one job well.

Specialization is all about capturing your subject matter experts’ best judgement and pattern recognition to build an open-weight, open source, trained, and fine-tuned model that can be deployed in your own data center.

“The true enterprise bet is to keep that orchestration layer, which is your IP and knowledge, in house,” Thakrar said. “You don’t want to host that on someone else’s model. The goal of everyone in enterprise should be to run, train, and host their own models.”

Every CIO I speak with today is wrestling with some version of the same question: How do we move faster with AI and deliver on our commitments?

It’s an understandable concern. Boards and CEOs are asking about AI. Business leaders are experimenting with use cases. Employees are discovering tools daily, while technology vendors promise unprecedented gains in productivity, innovation, and competitive advantage.

After hundreds of conversations with technology executives over the past year, I’ve become convinced that speed isn’t the real issue. The organizations pulling away from the pack aren’t necessarily adopting AI faster than everyone else. They’re executing more effectively — a subtle distinction that represents one of the defining leadership challenges of the AI era.

Technology has never been the hardest part of transformation. People, priorities, culture, and operating models are the biggest challenges. The ability to translate bold boardroom aspirations into thousands of thoughtful decisions made every day by architects, engineers, product managers, analysts, and business leaders is where competitive advantage is created. AI may be accelerating the pace of change, but it hasn’t changed that fundamental truth.

I’ve met plenty of executives who are exceptional in the boardroom. They know how to frame a vision, influence a board, and build confidence among investors and business leaders. I’ve also met remarkable technologists who instinctively understand the architectural decisions, engineering tradeoffs, and implementation details that determine how great ideas become reality. Modern CIOs, however, must move comfortably between both worlds. Afshean Talasaz is one who stands out among this rare breed.

Long before becoming CIO of Colonial Pipeline, Talasaz built his career from the ground up as a business professional, data scientist, and technologist. He has designed enterprise platforms, built AI capabilities, led technology organizations, and partnered closely with executive leadership teams on business transformation. Today, as an executive in residence with our Practitioners for Practitioners (P4P) community, he helps CIOs and business leaders navigate one of the most significant technology shifts of our generation.

While Talasaz brings deep knowledge of data and AI to the table, his greatest strength is his ability to create strategy and connect it with execution. He can spend the morning discussing enterprise reinvention with the board and the afternoon debating architectural principles with the teams responsible for bringing that vision to life.

That versatility gives Talasaz a unique lens on how CIOs can deliver value with AI.

Software companies have a term for engineers who understand every layer of the technology stack: full-stack developers. Listen to Talasaz and it becomes evident that the AI era requires something similar from technology leaders: a full-stack CIO.

The full-stack CIO: Leading with clarity

A full-stack CIO understands how every layer of the enterprise influences the next. They recognize that every strategic priority becomes a portfolio investment, every investment shapes an operating model, every operating model influences architecture, every architecture choice informs product decisions, every product decision shapes engineering priorities.

The best CIOs understand both ends of that journey. The extraordinary ones understand everything in between.

And those who execute best lead with clarity, Talasaz says.

“Everyone, from executives to middle managers to the people writing code, should be able to explain what we’re trying to achieve,” he emphasizes. “Clarity isn’t that we’ve handed out the PowerPoint. It’s that people genuinely understand where we’re going and can articulate it in their own language.”

One of the unintended consequences of the AI boom is that organizations are beginning to confuse activity with alignment. They have AI councils, AI governance committees, AI innovation labs, AI centers of excellence, AI pilots, and AI roadmaps. Yet if you stop ten people in the hallway and ask a deceptively simple question, What business problem are we actually trying to solve? you’ll often hear ten different answers.

As a result, architects optimize for one objective while product teams optimize for another. Business units pursue opportunities that seem perfectly reasonable from their perspective. Engineers make thoughtful technical decisions based on the information available to them. Individually, none of those decisions are necessarily wrong. Collectively, however, they create organizational drift. AI doesn’t create that problem. It simply accelerates the consequences.

And while AI can be a force multiplier for the positive when every decision is guided by a shared understanding of where the organization is headed, it can also be a force multiplier for the negative, resulting in an organization simply moving faster in different directions.

“When we have the fundamentals right, the tech infrastructure, the operating models, the nuances of how our business actually runs, we get the impacts of AI in a positive way,” Talasaz says. “When we don’t have those in place, AI can amplify the gaps or mute the benefits.”

At a time when so much of the conversation surrounding AI is focused on algorithms, agents, and automation, it’s an important reminder that organizations don’t execute strategy; people do.

Reducing organizational friction

Most executives are familiar with the concept of VUCA that characterizes today’s business environment. But Talasaz stresses the importance of turning this concern inward: “If the world outside our organizations is becoming more volatile, uncertain, complex, and ambiguous, what are we, as leaders, doing to the inside of our organizations?”

Leaders spend enormous amounts of time helping their organizations respond to external disruption but comparatively little time asking whether they are inadvertently re-creating those same conditions internally in response to those external needs. Are we reducing uncertainty or introducing more of it? Are we simplifying work or adding unnecessary complexity? Are we helping people focus on what matters most, or asking them to navigate competing priorities and shifting expectations?

Talasaz refers to this phenomenon as double VUCA — something I’ve witnessed repeatedly while working with CIOs over the past decade. Organizations often assume they’re struggling because of technology limitations when the real constraint is organizational friction. Teams wait for decisions. Priorities shift faster than roadmaps. Governance grows heavier. New committees are formed to solve problems created by existing committees. Everyone is working harder, yet the organization somehow feels slower.

AI amplifies both outcomes. Organizations with clarity become dramatically more effective because AI accelerates good decisions. Organizations without clarity simply accelerate confusion.

Operating model as strategy enabler

AI governance is one way to achieve greater clarity, but as Talasaz says, governance shouldn’t primarily exist inside policy manuals that few people read.

Instead, AI governance should be embedded in the daily rhythms of the organization, shaping how teams collaborate, how decisions are made, how products move from ideas into production, and how innovation happens safely without requiring constant escalation. In other words, it’s all about your operating model.

“If you had to pick one thing that isn’t technology, your operating model is the most important element for executing data and AI at scale,” he says.

The best operating models create enough clarity that capable people can make thousands of decisions independently and confidently, without having to wait for permission. By embedding good governance into the way it works, the organization becomes faster.

This advice echoes something I’ve heard repeatedly from some of the world’s most respected CIOs: High-performing organizations aren’t built on tighter control; they’re built on greater trust, supported by clear principles, shared expectations, and operating models that enable responsible decision-making at every level of the enterprise.

Talasaz points out that technology leaders tend to speak in terms of transformation. He suggests CIOs consider a different word: reinvention.

As he explains, transformation implies replacing what exists today with something new. Reinvention starts with a more clear-eyed and practical premise: Some things absolutely must change; others represent years, sometimes decades, of accumulated expertise, customer trust, operational discipline, and competitive advantage.

Reinvention is about building on those strengths while also creating new ways to deliver value. The leaders making the greatest progress in their AI journeys seem to recognize that it’s less about abandoning the past than thoughtfully preparing the organization for the future.

Closing the gap between strategy and execution

Full-stack CIOs must be able to map out the various layers of execution and planning that need to be done at every level of the organization to be successful. To help with this, Talasaz has developed a data and AI framework that draws on his own experiences “from the keyboard to the boardroom.”

As Talasaz sees it, too many organizations have been doing good work in isolation. “They’re doing a lot of the right things,” he says. “They’re just not connected.”

Boards may be discussing growth while business leaders redesign customer experiences. Product teams may be prioritizing new capabilities while architects modernize platforms. Data teams may be improving quality while engineers focus on delivery. Every group makes meaningful progress within its own domain, yet somewhere between strategy and execution, the connective tissue begins to disappear. Talasaz’s framework brings those connecting points to the forefront.

Crucially, the framework doesn’t begin with technology or AI or even with data. It begins with the experiences the organization hopes to create for its customers, employees, or partners. Many AI initiatives start with the question, “What can this technology do?” And indeed, we need to be inspired by the possibilities and challenged to think differently by what the technology can do. But, Talasaz emphasizes, we also need to ask what experiences we need to deliver for our business and how the technology can make that a reality.

The framework challenges CIOs to answer that question first. Only after the experiences are clearly defined does the conversation move to the capabilities required to deliver it, the business activities that support those capabilities, the AI and data products that enable them, and finally the data foundation that makes everything possible.

This shift in perspective ensures that, rather than allowing technology investments to search for business value, the business experience defines the technology required to deliver it. For CIOs, that’s more than a planning exercise. It’s a fundamentally different way of leading.

Over the coming months, the P4P community will be convening a series of small CxO roundtables to explore these issues and work more deeply with Afshean Talasaz’s 6×6 Data and AI Framework. CIOs and other enterprise leaders interested in participating are welcome to reach out to me directly.

You are one of the six billion people (75% of the world population) online today, and every click you make is routed through the data center. Data centers, whether knowingly or unknowingly, play a very critical role in your daily online activities. With an increasing population, increasing usage of online presence, and now omniscient AI, the demand for data centers has increased manyfold, and the trend seems similar to the year 2000, when telephone towers were built to accommodate increased digital presence.

To win the AI race, Hyperscalers (Google, Meta, Amazon, Microsoft, Alibaba, Oracle, IBM, Tencent) are spending huge amounts of money on data center development. In the USA, the hyperscalers are planning to spend $650 billion in 2026, which is around 70% higher than 2025 spending, according to Yahoo Finance.

As per McKinsey research, by 2030, companies will invest around $7 trillion in Capex on data center infrastructure globally. More than $4 trillion will go towards computing hardware investment. More than 40% of this spending will be invested in the United States.

Demand growth in data centers

McKinsey analysis shows that global demand for data center capacity can more than triple by 2030, with a compound annual growth rate (CAGR) of around 22 per cent. In the USA, data center demand could grow by 20-25 per cent at the same time.  

The data center industry is currently undergoing a violent transition. We are moving away from the era of “bespoke projects” — where every facility was a unique architectural feat — into an era of industrialized infrastructure. With global capital expenditure in the sector projected to hit $3 trillion by 2028, the “bottleneck” has shifted. It is no longer about securing the capital; it is about the physics of the supply chain.

During my tenure at Vantage, managing the intersection of data center construction management (DCCM) and infrastructure management (DCIM), I saw firsthand that the most successful players aren’t those with the deepest pockets, but those with the most integrated data threads. If your construction data in Procore doesn’t talk to your financial reality in Yardi, or your operational capacity in DCIM, you aren’t building a data center — you’re managing a $500 million blind spot.

The death of “sticks and bricks”

Traditionally, data center construction was treated as civil engineering. But for the modern CIO, a data center is a complex product assembly.

The challenges are systemic. We are facing 50-to-80-week lead times for critical “long-pole” items: extra-high-voltage transformers, switchgear, and the liquid cooling manifolds required for the next generation of AI chips. In this environment, the traditional reactive supply chain model is a liability.

To survive the $3 trillion inflow, we must adopt a hybrid-agile SCOR (supply chain operations reference) model. This means applying continuous flow logic to standardized components (like modular power skids) while maintaining agile responsiveness for the volatile IT layer.

The digital bridge: Construction management software  to ERP

The most significant opportunity for CIOs lies in financial-operational integration. In many organizations, there is a data chasm between the construction site and the corporate office. Construction teams live in the construction management software tracking tasks, trades, RFIs and payment submittals. Finance teams operate corporate offices with project management tools (worth remembering that email is a key tool besides spreadsheets and phone calls) tracking capex schedule, commissioning timeline, capital drawdowns and asset lifecycle management.

These systems are siloed; the CIO loses visibility into the total cost to serve. By integrating construction management into the financial system, we create real-time financial visibility of the build. We can see exactly how a three-week delay in a chiller delivery impacts the internal rate of return (IRR) of the entire asset. This isn’t just accounting; it’s strategic telemetry.

From BIM to DCIM: The lifecycle thread

The second bridge is the handoff from construction (BIM) to operations (DCIM). Historically, this handoff was a nightmare of PDFs and Excel sheets. By the time the operations team took the keys, the “as-built” design information was already out of date.

The opportunity today is to maintain a continuous data thread. The sensor data and asset tags established during the “make” phase in our SCOR model should flow directly into the DCIM. This allows us to perform virtual commissioning. Before a single server is racked, we should already have a digital replica of the airflow, power distribution, and cooling capacity.

The scientific inference: AI in the supply chain

As someone who has led data and AI initiatives, I’ve seen the hype. But in the supply chain, the application of AI must be pragmatic, not generative. We don’t need AI to write poems; we need it for predictive procurement. Most organizations manage their procurement in ERP or a mix of a few tools to manage the source-to-settle business flow. Adopting a system workflow improves data collection and the state of the procurement cycle, which in turn provides AI with the context to draw inferences for possible delays and anomalies in original specifications and change orders.

By applying machine learning to global logistics data, we can move from just-in-time to just-in-case modeling. AI can analyze geopolitical risks, shipping lane congestion, and raw material pricing to tell a CIO: “Order your switchgear 14 months early, or your Q3 2027 ‘Power On’ date is at risk.”

Bringing it all together: AI in the supply chain and finance

Why it matters: Approximately 70% of the capex is on this workflow and making timely decisions that directly impact the ready-for-service dates. The current challenge of reactionary adjustment in design to procurement to local fit-out is a significant drain on capex efficiency and cost of capital. Because single-project delivery delays have become so volatile, a massive structural shift is occurring in how digital infrastructure is funded. Single-project debt (special purpose vehicles or SPVs) is facing severe friction. To insulate themselves from RFS shocks, the largest institutional players are moving toward permanent platform capital — aggregating exposure across dozens of global assets simultaneously.

Navigating these complex multi-billion-dollar engineering projects distributed over a large geography is simply unmanageable without rethinking and re-engineering existing tools and processes.

The roadmap for the modern CIO

To lead this transformation, CIOs must move beyond the IT shop mentality and become master orchestrators of the supply chain. Here is the 1500-word reality condensed into three mandates:

1. Standardize the product: Stop designing bespoke facilities. Move toward DFMA (design for manufacturing and assembly). If 70% of your data center can be built in a factory and shipped as modules, you bypass the unpredictability of on-site labor.
2. Integrate the financial stack: If your construction management software and your ERP aren’t sharing a heartbeat, your data is lying to you. Force the integration between Procore and Yardi.
3. Own the long poles: Don’t leave the procurement of transformers and cooling units to general contractors. Use your balance sheet to secure these items years in advance. In 2026, inventory is the new currency.

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

Across industries, a version of the same conversation is playing out in technology leadership meetings. Enterprises have deployed AI broadly, and foundation models keep getting more capable. Yet the outputs still feel generic, shaped by industry patterns rather than by the organization producing them.

McKinsey’s AI Trust Maturity Survey found that while overall AI maturity scores have improved, only about a third of organizations have reached a mature level of strategy and governance. Technical capability is advancing faster than organizational alignment. In my view, the gap is not a model problem. It is a context problem. Enterprises are feeding generic inputs into powerful models because sharing organizational context seamlessly with AI is neither easy nor intuitive today.

Building the analytical and creative capabilities to scale AI, something I explored in a recent piece on the left-brain and right-brain approach to enterprise AI, is necessary but not sufficient. Before either can function effectively, the enterprise needs something more fundamental. AI that actually understands the contextual fabric of the organization it is operating in. A frontier model has processed everything written about your sector, your competitors and your regulatory landscape. It cannot access the reasoning embedded in years of delivery decisions, the patterns encoded in how your teams scope and deliver work over time. That knowledge is organizational memory, and frontier models can’t get that easily. It exists inside every enterprise but has never been structured, connected or made available to any AI system. Without it, even the most capable model answers a generic version of your question.

The next competitive advantage in enterprise AI will not come from a better model. It will come from a better organizational context.

One global technology enterprise set out to solve this across its own operations, building a modular ecosystem of domain-specific agents grounded in its own data across contracting, talent and vendor management workflows. What emerged was not just operational efficiency but a shared intelligence layer connecting decisions across functions for the first time.

Competitive differentiation was never about the tools

Consider what actually separates high-performing enterprises from the rest. In a regulated industry like financial services or healthcare, organizations cannot meaningfully differentiate on product. A bank cannot offer substantially different products or services. A health system uses the same clinical protocols and the same electronic health record (EHR) platforms as its peers. What varies is everything underneath: the rigor of processes, the coherence of cross-functional decisions and the people who carry years of accumulated organizational judgment in how they make those decisions.

An organization with a proper context layer in place can say with precision that for this type of engagement, in this sector, with this risk profile, our institutional history tells us exactly where we stand. That level of specificity is what most enterprises have never made available to AI.

The enterprise AI brain that every organization has but has never assembled

Every enterprise already possesses what I think of as an enterprise AI brain. The problem is that it has never been assembled in one place. The data exists across contracts, project documentation, talent records, delivery metrics and the operational communications of daily execution — the informal reasoning that rarely makes it into formal systems.

None of the standard enterprise platforms were designed to connect this. A customer relationship management (CRM) system captures customer interactions. An enterprise resource planning (ERP) system captures transactions. A project management tool captures tasks and timelines. None of them captures the reasoning behind decisions and none of them surfaces a coherent picture of how the organization actually thinks and operates.

BCG’s study across hundreds of companies found that only 10% of AI value comes from the algorithms and another 20% from the technology that implements them, meaning the remaining 70% depends on people, processes and organizational change. The organizations extracting real value are those that have made their institutional knowledge available to AI in a structured, governed way.

Building a contextual AI fabric

A Contextual AI Fabric is the technical and organizational layer that makes the Enterprise AI Brain usable. It brings together unstructured data ingestion, semantic structuring, retrieval pipelines and governed model access to give AI systems the organizational context they need to produce outputs that are genuinely specific to your enterprise rather than generically accurate about your industry. It rests on three pillars. Core is the secure, governed and interoperable foundation that AI operations run on. Context is reliable, traceable access to the organization’s data, processes, knowledge and history. Coordination connects people, agents, applications and systems into process-driven workflows with clear controls and accountability, so the organization acts as one rather than a set of disconnected functions.

The data layer is where most organizations underestimate the work. Contracts, project reports, talent assessments and operational communications require extraction, chunking, embedding and indexing before a model can retrieve and reason over them meaningfully.

The semantic layer is what makes retrieval meaningful. Even well-ingested data fails if functions use different terminology for the same concepts. What legal calls a contract, delivery calls a scope. Without a shared ontology, AI systems remain precise about the wrong thing. And retrieval alone, however well-structured, only takes an organization so far. Retrieval surfaces the right information at the moment of a query, but it does not give a model genuine memory of the organization. The real source of unique, organization-level relevance comes from training domain-specific small language models on this context directly, models that carry organizational memory forward rather than fetching it fresh every time. That is what ultimately separates a Contextual AI Fabric from a well-organized database.

The governance layer is not an add-on. Access controls, data lineage, approval thresholds and human checkpoints need to be designed in before any agent goes into production. Security is not a layer you add afterward. It is the condition under which organizational AI is worth building. If the institutional intelligence that makes your enterprise distinct gets absorbed into a frontier model’s training data, it becomes everyone’s baseline. That is an architectural decision made, or avoided, at the point of deployment.

Proprietary by design

The institutional knowledge that makes up a contextual AI fabric — delivery history, commercial patterns, talent intelligence and operating culture — is proprietary in ways no external model can replicate. This is as much a security imperative as it is a competitive one. Organizational context, once exposed, cannot be unexposed.

Most enterprises are using AI to automate existing processes rather than questioning whether those processes should be redesigned entirely. The organizations extracting the most value are those willing to ask whether their current operating model, built before GenAI existed, is the one they would build today. That question is harder than any technology decision, and it is also the most consequential one.

From context to coordinated action

Context alone is not enough. When a delivery risk surfaces in project data, the talent function needs to respond. When a commercial signal changes in contract data, operations need to recalibrate. This kind of cross-functional coordination, driven by shared organizational intelligence rather than siloed data, is where the real value of enterprise AI shows up and where the absence of a shared context layer becomes most visible.

A global leader in digital payments and business services found its AI deployments across payroll, HR and risk compliance, each running in isolation, with no shared governance or common data foundation. Once the organization established a unified governance backbone connecting its operational data through a shared retrieval layer, business users could query across domains in plain language and new use cases across fraud analytics, forecasting and policy extraction became extensible without rebuilding infrastructure for each one. The shift was not in the models. It was in the shared foundation underneath them.

The leadership question behind the technology question

The enterprises pulling ahead in AI are not winning on model quality but on organizational memory. The ones that have done the hard work of structuring their institutional knowledge into a governed, secure Contextual AI Fabric are giving their AI something no competitor can replicate: the accumulated intelligence of how the business actually operates.

For CIOs, the question is no longer which model to deploy. It is whether the organization has built the foundation that would make any model worth deploying.

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

T. Schneider / Shutterstock

Was ist Claude Mythos?

Claude Mythos ist ein KI-Modell, das von Anthropic entwickelt wurde und für Anwendungen in den Bereichen Cybersicherheit und Gesundheitswesen optimiert ist. Ursprünglich wurde Mythos 5 im April einer kleinen Gruppe geprüfter Technologiepartner zugänglich gemacht – im Vorfeld eines geplanten, breiter angelegten Rollouts.

Zu diesem Zweck rief das KI-Unternehmen das Projekt „Glasswing“ ins Leben, ein Konsortium, das Infrastrukturanbietern, Open-Source-Entwicklern und großen Technologieunternehmen einen begrenzten, kontrollierten Zugriff zu Mythos gewährt. Ziel der Initiative ist es, Verteidigern zu ermöglichen, Schwachstellen schneller aufzuspüren und zu beheben, als Angreifer sie identifizieren können. Das erscheint auch dringend notwendig, setzen diese doch zunehmend selbst auf KI-gestützte Werkzeuge.

Über welche Fähigkeiten verfügt Claude Mythos?

Die ersten 50 Partner von Project Glasswing konnten mithilfe von Mythos mehr als 10.000 Schwachstellen mit hohem oder kritischem Schweregrad in allen gängigen Betriebssystemen und Webbrowsern aufspüren.

So identifizierte das Modell Sicherheitslücken, die selbst den fähigsten Sicherheitsforschern jahrelang entgangen waren – etwa einen 27 Jahre alten Fehler in OpenBSD. Zudem hat Mythos bewiesen, dass es mehrere Schwachstellen miteinander verknüpfen kann.

Wie schränkt Anthropic den Zugang zu Claude Mythos ein?

Anthropic teilte bei der Vorstellung von Claude Mythos mit, es schränke die Verfügbarkeit des Spitzen-KI-Modells bewusst ein, da dessen Fähigkeiten von Angreifern leicht missbraucht werden könnten.

Im Juni wurde die Technologie dann für weitere 150 Organisationen freigegeben. Alle Mythos-Partner müssen hierbei aber zustimmen, dass ihre Daten 30 Tage lang zu Sicherheitsüberwachungszwecken gespeichert werden.

Am 15. Juni verhängte die Trump-Regierung allerdings Exportbeschränkungen für Claude Fable 5 und Claude Mythos 5. Diese sollten ausländischen Staatsangehörigen sowohl innerhalb als auch außerhalb der USA den Zugang verwehren. Am 30. Juni wurden die Beschränkungen jedoch bereits wieder aufgehoben.

Was ist Claude Fable?

Für einen breiteren Einsatzbereich bietet Anthropic Claude Fable 5 an. Das Modell basiert auf derselben technischen Grundlage wie Mythos. Es verfügt jedoch über strenge Sicherheitsmechanismen, die den Betrieb in als „riskant“ eingestuften Bereichen der Cybersicherheit einschränken. Alle als problematisch deklarierten Anfragen werden stattdessen automatisch an das ältere und weniger leistungsfähige Large Language Model (LLM) Opus 4.8 weitergeleitet.

Wie nutzen Security-Partner von Anthropic den Zugriff auf Mythos?

Cisco, einer der Projekt-Glasswing-Partner, hat seine „Foundry Security Spec“ als Open-Source-Lösung veröffentlicht. Hierbei handelt es sich um ein modellunabhängiges Framework für Sicherheitstests, das es anderen Anbietern und Sicherheitsexperten in Unternehmen ermöglichen soll, ähnliche Arbeitsabläufe zu entwickeln, ohne bei Null anfangen zu müssen.

Vor kurzem betonten Vertreter von Cisco auf einer Online-Veranstaltung, dass Verteidiger KI nutzen können, um Sicherheitsprobleme wesentlich schneller und in größerem Umfang zu identifizieren, zu bestätigen und zu beheben. Ältere Modelle, die nach dem Prinzip „eine Schwachstelle finden und patchen“ funktionieren, seien nicht mehr zeitgemäß. Dies liege daran, dass Angreifer KI einsetzen, um den Weg von der Entdeckung einer Schwachstelle bis zu deren Ausnutzung zu beschleunigen. Cisco wiederum setzt KI intern bereits in der Defensive ein, um 1,8 Milliarden Zeilen Code im gesamten Produktportfolio zu scannen.

Gleichzeitig betonen die Experten, dass kleinere Unternehmen keinen Zugriff auf eingeschränkte KI-Modelle benötigen, um ihre Sicherheit zu verbessern. In solchen Betrieben lasse sich stattdessen mehr erreichen, indem grundlegende Sicherheitsmaßnahmen optimiert werden. Hierzu zählen laut Cisco unter anderem Authentifizierung, Netzwerk-Segmentierung, Zero Trust und die Behebung aktiv ausgenutzter Schwachstellen.

Bieten andere KI-Anbieter etwas Vergleichbares zu Claude Mythos an?

Mythos ist das prominenteste Beispiel für Frontier-KI-Modelle. Mit ihnen kann die Suche nach Zero-Day-Lücken in einem Tempo und Ausmaß automatisiert werden, die weit über die Fähigkeiten menschlicher Teams hinausgeht.

Allerdings arbeiten auch etliche andere Anbieter an hochleistungsfähigen, auf Sicherheit ausgerichteten „Frontier“-KI-Modellen. Zudem gibt es andere leistungsstarke Open-Source-Modelle, die sich problemlos für die Cybersicherheitsforschung nutzen lassen. Claude Mythos ist also bei weitem nicht die einzige verfügbare Option.

So werden beispielsweise die Modelle GPT-5.4-Cyber sowie GPT-5.5 von OpenAI genutzt, um Schwachstellen zu erkennen und zu analysieren. Auch in der Malware-Analyse und der Bedrohungsmodellierung kommen sie zum Einsatz. Zugang zu diesen Technologien können Sicherheitsanbieter, Unternehmen und Forscher über das Programm „Trusted Access for Cyber“ (TAC) von OpenAI erhalten.

Zusätzlich hat das chinesische Cybersicherheitsunternehmen 360 Security Technology mit Tulongfeng ein System entwickelt, das als Gegenstück zu Anthropics „Mythos“ beschrieben wird.

Privat lassen sich leistungsstarke offene Modelle – darunter DeepSeek V3.2 von DeepSeek und Llama 4 von Meta – auf GPU-Infrastrukturen betreiben und in der Cybersicherheitsforschung einsetzen. Fugu des japanischen Anbieters Sakana AI ist eine weitere Option in dieser Kategorie.

Was kritisieren Cybersicherheitsexperten an Claude Mythos?

Kritiker aus dem Cybersecurity-Bereich räumen ein, dass Claude Mythos zweifellos hochentwickelt sei. Die Marketing-Behauptung, wonach es zuverlässig produktive IT-Systeme lahmlegen könne, übersteige jedoch die tatsächlichen Fähigkeiten.

Darüber hinaus beklagen sich Sicherheitsexperten – etwa in Podcasts – über die übertrieben restriktiven Sicherheitsmechanismen von Claude Fable: Bereits Anfragen, einen sicherheitsrelevanten Blogbeitrag zusammenzufassen oder sogar das Wort „Exploit“ zu buchstabieren, würden auf das deutlich schwächere Modell Opus 4.8 zurückgestuft. Dadurch würden selbst alltägliche Aufgaben in der Informationssicherheit unnötig erschwert.

Andere Experten warnen davor, dass Frontier-KI-Modelle anfällig für False Positives seien. Eher grundsätzlich ist die Kritik, dass das schnellere Aufspüren von mehr Schwachstellen das eigentliche Problem nicht löst, nämlich zuverlässig Sicherheitslücken zu beheben oder nicht-technische Angriffsvektoren wie Social Engineering zu verhindern.

Wie sollten CISOs auf Mythos reagieren?

Die Nachrichtendienste der „Five Eyes“ (USA, Großbritannien, Kanada, Australien und Neuseeland)  warnen davor, dass hochmoderne KI-Modelle wie Claude Mythos „sowohl offensive als auch defensive Cyber-Fähigkeiten grundlegend verändern werden“ – und zwar in einem Zeitraum von Monaten statt Jahren.

„Während KI uns dabei helfen wird, die Cyberabwehr im Laufe der Zeit zu verbessern, erhöht sie zugleich Geschwindigkeit, Ausmaß und Raffinesse von Cyberbedrohungen“, heißt es in der Erklärung der Gruppe. Unternehmen sollen daher KI nutzen, um ihre Abwehrmechanismen im Rahmen umfassenderer Strategien zur Stärkung der Cybersicherheits-Resilienz zu verbessern.

Die meisten Unternehmen seien jedoch bei weitem noch nicht darauf vorbereitet, was dies für ihre Bedrohungsmodelle bedeutet, warnt ein Experte. „Wir verfügen heute über KI-Systeme, die realistische Angriffswege über Software, Anbieter und kritische Infrastrukturen hinweg schneller abbilden können, als menschliche Angreifer sie erfassen können“, erläutert Joe Hubback, Partner und CISO beim Beratungsunternehmen Elixirr sowie ehemaliger McKinsey-Partner. Dadurch, dass „Fähigkeiten der ‚Mythos-Klasse‘ vor der breiten kommerziellen Einführung stünden, handle es sich nicht mehr um „ein Nischenproblem der Forschung“, ergänzt er. Vielmehr sei es jetzt ein Faktor, den jedes Unternehmen in sein Bedrohungsmodell einbeziehen müsse, so der Experte.

Auch ein Bericht der Cloud Security Alliance warnt davor, dass KI die Zeitspanne zwischen der Entdeckung einer Schwachstelle und deren Ausnutzung drastisch verkürzt habe. Damit seien herkömmliche Sicherheitsmodelle, die auf „Patchen und Reagieren“ basieren, überholt. Unternehmen sollten sich vielmehr auf anhaltende Wellen von Schwachstellen einstellen, die durch „Project Glasswing“ und andere Quellen mittels KI aufgedeckt werden.

„Die bei Mythos beobachteten Fähigkeiten werden schon bald breiter verfügbar sein. Dadurch wird sich die Anzahl sowie Häufigkeit komplexer, neuartiger Angriffe, denen sich Unternehmen gegenübersehen, drastisch erhöhen“, heißt es in der Warnung. Sicherheitsverantwortliche müssten daher ihre Verteidigungsstrategien auf einen „Mythos-ready“-Ansatz umstellen, der auf kontinuierlichem Schwachstellenmanagement, schnellerer Priorisierung und verbesserter Reaktion auf Sicherheitsvorfälle basiert. (tf)

Dieser Artikel basiert auf einem Beitrag von CSO.

The evolution of Java is the subject of a just-released documentary about the programming language and development platform. “The Java Story: The Official Documentary” tells the story of Java through interviews with the engineers who created it and shepherded it through three decades.

Produced by CultRepo and sponsored by Oracle, JetBrains, IBM, and Azul, the documentary follows Java from its set-top box and browser-based origins at Sun Microsystems in the 1990s and through its rise to dominate server-side computing in the 2000s, the “dark ages” and resurgence with Java 8 under Oracle in the 2010s, and its continuing modernization and promising role in AI today. “From its humble beginnings as a project code-named ‘Oak’ at Sun Microsystems to becoming a global standard for enterprise software and billions of devices, Java’s journey is one of radical innovation, strategic pivots, and enduring community strength,” said Cult.Repo.

The documentary also delves into Sun’s bitter Java licensing dispute with Microsoft, Oracle’s suit of Google over its use of Java APIs Android (Google won), the creation of the Java Community Process, Sun’s open-sourcing of Java, and Oracle’s switch to the six-month release cycle. Technical enhancements such as lambda expressions in Java 8, virtual threads in Java 21 (Project Loom), and the ongoing refactor to bring value objects to the Java object model (Project Valhalla) also get attention.

Technical experts and other Java figures interviewed in the documentary include James Gosling, creator of Java; Kim Polese, Java’s first product manager; Carla Schroer, director of Java compatibility at Sun Microsystems; James Duncan Davidson, creator of Apache Tomcat; Mark Reinhold, chief architect of the Java Platform Group at Oracle; Brian Goetz, Java language architect in the Java Platform Group at Oracle; Rod Johnson, creator of Spring; and Gavin King, creator of Hibernate.

In a single month, one enterprise reportedly spent half a billion dollars on AI. A consultant told Axios that the client had handed its workforce AI licenses, set no usage limits and let the meter run until finance noticed. The figure is spectacular, and it is the wrong thing to fear. That half-billion-dollar accident is only the visible part of a quieter, far larger failure. Worldwide AI spending is forecast to reach $2.52 trillion in 2026, more than any technology category in a generation, and by the most cited measure, roughly 95 percent of it returns nothing. Boards read that as proof that the technology does not work. The evidence points somewhere less comfortable, and it is not a technology problem at all. Most boards cannot see it because they are reading the wrong number: They track failure when the number that matters is allocation. The discipline that separates the winners is not technical. It is how they allocate capital across time, and how willing they are to stop. The hardest discipline in the AI era is not adopting faster. It is allocating honestly and refusing to judge a three-year bet on a six-month cycle.

The number everyone quotes, and no one acts on

The headline statistic is now familiar. MIT’s Project NANDA, in its 2025 study The GenAI Divide, found that about 95 percent of enterprise generative AI pilots produced no measurable impact on the P&L, while roughly 5 percent captured nearly all the value. S&P Global Market Intelligence found that the share of companies abandoning most of their AI initiatives jumped from 17 percent to 42 percent in a single year, with the average organization scrapping 46 percent of its proofs-of-concept before production. Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. And the pattern predates generative AI: RAND found that more than 80 percent of AI projects fail, roughly twice the rate of comparable work that does not involve AI.

Read as a technology story, these numbers say AI does not work. Read correctly, they say something more useful. MIT’s own authors located the cause not in model quality but in a learning and integration gap. The winners were not running better models. They picked one problem, executed and worked well together. Purchased solutions reached production about 67 percent of the time, while internal builds succeeded roughly a third as often. Gartner’s own spending forecast notes the same pivot, with CIOs scaling back ambitious internal builds in favor of commercial solutions that promise more predictable value. None of that is a verdict on the technology. It is a verdict on allocation: What gets funded, for how long and against which yardstick. The popular prescription, heard in every boardroom this year, is to measure harder and prove value sooner. That advice quietly repeats the mistake, because forcing a three-year bet to prove itself sooner is precisely how you kill it. The fix is not more measurement. It is measuring each bet against the right clock and subtracting the ones that miss.

The six-month cycle problem

Return to that 95 percent, because the way it is measured is the whole argument. Much of the reported failure is judged on a short clock, with a pilot counted as a failure if it has not shown a measurable financial return within roughly six months. The single most quoted number in enterprise AI is therefore a six-month yardstick applied to every initiative, including the bets designed to pay back in three years. The headline failure rate is not only a measure of AI. It is a measure of impatience.

The most expensive mistake in enterprise AI is a timing error. Enterprises have been spending heavily on AI for more than two years, and 2026 is the year boards are demanding returns. The multi-year bets funded during the 2024 and 2025 scale-up are only now far enough along to be judged. When a board reviews an initiative, it applies the yardstick it knows, which is quarterly return. That yardstick is correct for an efficiency project and ruinous for a capability bet. A workflow automation that should pay back in two quarters and a foundational data and agent capability that pays back in three years are not the same instrument, yet they are reviewed in the same meeting against the same metric.

This is the heart of the divide. The 5 percent did not simply pick better projects. They judged each project against its own horizon. McKinsey’s enduring Three Horizons model made this discipline standard in corporate strategy a generation ago: near-term, emerging and long-term bets are funded and measured differently. AI erased that discipline because the hype compressed every timeline into the current quarter. The result is two failure modes that appear opposite yet share a common root. Organizations kill three-year bets at month six because they miss a metric the bet was never designed to hit. And they keep funding six-month theater for years because it is visible, safe and never asked to prove a return. Both are allocation failures. Neither is a technology failure.

Subtraction is a strategy

There is a second discipline, the 5 percent share, and it is the one boards find hardest. They subtract. Every credible study of the failure rate describes the same chaotic pattern underneath it: Initiatives are abandoned late, without criteria, after the money is spent and the credibility is gone. Disciplined organizations do the opposite. They decide the conditions for stopping before they start, and they stop on schedule. Subtraction is not the absence of strategy. It is the strategy. Capital removed from a failing bet is capital available for a surviving one, and the survivors are where the entire return lives.

This reframes the 42 percent abandonment figure. Abandonment is not the problem. Undisciplined abandonment is. An organization that liquidates a position the moment it breaches a pre-agreed kill line is practicing portfolio hygiene. An organization that lets a doomed pilot run until someone loses patience is paying full price for a lesson it could have bought at a discount. The 5 percent who won were not smarter. They were patient in the right places and ruthless in the wrong ones.

The HALT framework: Horizon, Allocation, Liquidation, Tracking

Treating AI as a portfolio rather than a pile of pilots requires four disciplines, and the organizations that execute well put all four in place before the next funding cycle, not after the next failure. The name is deliberate. The discipline most enterprises lack is the willingness to halt the wrong bets in time to fund the right ones.

Component 1: Horizon. Classify every AI initiative by its true payoff horizon before it is funded. Horizon 1 covers efficiency plays that should return value within two quarters. Horizon 2 covers capability bets, data foundations, agent platforms and integration work that pays back in roughly 6 to 18 months. Horizon 3 covers transformation bets that take eighteen months to three years or longer. Each horizon carries its own success metric, set at funding time. A Horizon 1 yardstick never judges a Horizon 3 bet. This single rule prevents the most common and most expensive error in the portfolio.

Component 2: Allocation. Decide the split across horizons deliberately, as a board-level capital decision, not as the accidental sum of whatever pilots happened to win approval. A practical reference point, borrowed from decades of innovation-portfolio practice, is roughly 70% to near-term value, 20% to capability, and 10% to transformation. The exact ratio is yours; the discipline is to choose and defend it. The failure mode is an unmanaged portfolio: 90 percent scattered across disconnected Horizon 1 experiments, with nothing compounding into the Horizon 2 capability that the buy-and-integrate winners actually built.

Component 3: Liquidation. Attach a kill line to every initiative at the moment it is funded: A named milestone, a date and an owner empowered to stop it. If a bet misses its horizon-appropriate milestone, it is liquidated, and capital is reallocated on schedule without debate over sunk costs. The absence of a pre-agreed kill line is not patience. It is an unpriced liability that the board has almost certainly not been shown.

Component 4: Tracking. Report the portfolio to the board on a fixed cadence using a single instrument: The AI Portfolio Scorecard. Not a deck of project updates, but a single view of allocation by horizon, burn against milestone, liquidation decisions taken and capital reallocated to survivors. The cadence is the control. A portfolio reviewed once a year is a portfolio managed by hope.

THE AI PORTFOLIO SCORECARD: SCORE EVERY INITIATIVE BEFORE IT IS FUNDED

Score each criterion: 0 = not present, 1 = partially documented, 2 = fully verified. Total out of 12. Bands: 0 to 4 = DO NOT FUND  |  5 to 8 = CONDITIONAL  |  9 to 12 = FUND.

THE LIQUIDATION GATE: RUN AT EVERY BOARD REVIEW BEFORE CONTINUING FUNDING

Any unresolved FAIL = stop funding, liquidate the position, reallocate the capital to a survivor and record the decision on the scorecard.

The cost of the timing error

The financial case follows the pattern and is consistent. Consider two organizations that funded the same class of Horizon 3 bet: A domain-specific agent platform meant to compound over three years. The first review was conducted at month six against a quarterly return test, found no payback and killed it, booking the write-off as a lesson about AI being overhyped. Its competitor classified the same work as Horizon 3, set an 18-month capability milestone, protected funding through two review cycles and shipped to production within the window the work actually required. One organization spent its money to learn that it lacks allocation discipline. The other spent comparable money and now owns a capability its rival has abandoned and cannot quickly rebuild. The dollars on the two income statements are similar. The competitive positions are not.

The governance return the board has been waiting for

Allocation discipline does two things at once. It stops the bleed by liquidating failures on a schedule rather than at the point of exhaustion. And it concentrates capital where the entire return lives, in the small number of bets that survive their horizon. The 5 percent figure is not a ceiling imposed by the technology. It is the current yield of an industry allocated by hype. An organization that classifies by horizon, allocates on purpose, liquidates on a line and tracks on a cadence is not trying to beat the technology. It is trying to beat its own indiscipline, and that is a far more winnable contest.

The board conversation about AI returns is coming for every organization, and it arrives the moment the spending outpaces the story. When it does, the CIO will be asked a simple question: Where did the money go? The leaders who can answer will not show a pile of pilots. They will show a portfolio: What was funded, against which horizon, what was liquidated and when, and what the survivors are now worth. Subtraction is a strategy. The only question is whether you are practicing it on purpose or about to learn it by accident.

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

Every enterprise AI conversation seems to begin with the same question: Which model should we use?

I understand why. Models are visible. They have names, benchmarks, release notes, pricing pages and impressive demos. They are easy to compare in a leadership meeting. One model promises better reasoning. Another offers a larger context window. Another appears faster, cheaper or more specialized.

But after years of working around enterprise platforms, integration layers, cloud migration, middleware, production operations and mission-critical systems, I see the AI conversation differently.

The model matters. But it is not where most enterprises will struggle next.

The next AI bottleneck is the infrastructure behind the model.

I do not mean only GPUs, cloud capacity or data storage. I mean the full enterprise operating layer that allows AI to work safely in the real world: data pipelines, identity, APIs, messaging, observability, security controls, deployment automation, cost governance, auditability, support ownership and recovery design.

That layer is what determines whether AI remains an exciting experiment or becomes a trusted business capability.

Pilots hide the hard part

Most organizations can build an impressive AI pilot. A small team can connect a model to a dataset, create a workflow and show a use case that works well in a controlled setting.

The harder part starts when that pilot moves into a real production process.

That is when practical questions show up. Who owns the data quality? What systems can the AI access? How do we trace which prompt, policy or retrieval flow produced a specific answer? What happens when an API slows down, a queue backs up or a downstream system is unavailable?

To me, these are not model problems. They are infrastructure problems.

This is where many enterprises are now headed. The first phase of AI was experimentation. The next phase is operationalization, and that is where the real gap becomes clear.

McKinsey has made a similar point in its work on agentic AI, noting that the next phase of value depends less on isolated tools and more on redesigning workflows, operating models and enterprise execution around agents.

AI pilots can survive on enthusiasm. Production AI requires architecture.

AI is becoming an integration problem

The more I look at enterprise AI, the more it feels like an integration challenge.

In large organizations, I have seen how messaging platforms, integration gateways, deployment pipelines, monitoring tools and cloud infrastructure can decide whether a digital capability succeeds or fails. AI will be no different. Even the strongest model will struggle if the data, middleware, identity layer and operational controls around it are weak.

AI does not work in isolation. It needs context from systems of record, clean data from different business areas, secure access to APIs, event streams, workflows, knowledge repositories, monitoring tools and legacy systems.

That is why the CIO question is changing.

It is no longer just, “Which AI tool should we buy?”

It is becoming, “Can we safely operationalize intelligence across the business?”

This is where agentic AI matters. Autonomous AI only creates real value when the architecture around it can make its actions safe, traceable and useful.

A model can generate an answer. Infrastructure determines whether that answer is secure, timely, explainable, governed and connected to the right workflow.

For example, an AI assistant that summarizes customer or order information may look like a model use case. But underneath, it depends on access control, fresh data, reliable APIs, logging, encryption, monitoring and policy enforcement.

If the answer is wrong, people may blame the model. But the real failure may have started with stale data, weak integration, poor access design, missing observability or an unreliable downstream system.

That is why CIOs should not judge AI only by model capability. The enterprise system around the model matters just as much.

Latency will become a trust issue

In traditional technology operations, latency is often treated as a performance metric. In AI-enabled workflows, latency becomes a trust issue.

When an employee asks an AI assistant for help and the response takes too long, the employee stops using it. When a customer-facing workflow becomes slow, the customer abandons it. When an AI agent waits on multiple backend calls, the entire business process feels unreliable.

This becomes even more important as organizations move from simple chat interfaces to agentic workflows. A single AI-driven action may include identity checks, context retrieval, policy validation, model reasoning, API calls, business-rule execution, logging and human approval.

Each step adds latency. Each dependency adds a possible failure point.

A model may be fast in a benchmark but slow inside an enterprise process. That difference matters.

This is where platform engineering becomes essential. Enterprises need reusable patterns for AI workloads: approved connectors, secure retrieval methods, queue-based decoupling, caching strategies, deployment pipelines, monitoring dashboards and standard rollback procedures.

Without those patterns, every AI initiative becomes a custom build. Custom builds may work for pilots, but they do not scale across a large enterprise.

Observability has to expand

Traditional monitoring tells us whether infrastructure is healthy. Is the server up? Is CPU high? Is memory exhausted? Is the application returning errors?

AI needs that, but it also needs more.

We need to know what data was retrieved, which model was used, which prompt version was active, which user initiated the request, which policy was applied, how long each step took and whether the output passed validation.

We also need to detect new forms of risk: unusual usage patterns, repeated failed tool calls, unexpected cost spikes, sensitive data exposure, weak retrieval results or an AI workflow attempting actions outside its intended boundary.

In production AI, observability is not only about uptime. It is about confidence.

If a business leader, auditor, regulator or security team asks why an AI system made a recommendation, the answer cannot be, “The model said so.” The enterprise needs traceability. It needs evidence. It needs operational context that engineers, risk teams and business owners can understand.

This is one of the biggest gaps I see in AI strategy. Many organizations are investing in models and use cases, but not enough in the control plane required to manage them.

Data readiness is still underestimated

AI has exposed an uncomfortable truth: many enterprises are not as data ready as they think.

Data is often duplicated across platforms, described differently by each team, governed inconsistently and refreshed on different schedules. Access rules may be clear in one system but unclear in another. Even basic business definitions can change from department to department.

AI does not fix that automatically. In many cases, it makes the problem more visible.

A bad report may be questioned. A bad AI answer may sound confident enough to be trusted.

That is a real risk.

Being data-ready for AI is not just about connecting a vector database or indexing documents. It requires clear ownership, lineage, classification, quality checks, retention rules, access boundaries and a shared understanding of which data should be used for which purpose.

The same principle applies to resilient cloud-native design. In my IEEE TechRxiv paper, “Enabling Fault-Tolerant Multicast in Cloud-Native Architectures” I explored how reliability, observability and fault tolerance become foundational requirements when critical workloads stretch across hybrid and multi-cloud environments.

CIOs already understand this because they have lived through enterprise resource planning programs, cloud migration, integration modernization, cybersecurity transformation and analytics initiatives. The lesson is familiar: technology cannot outrun data discipline forever.

Security cannot be added later

As AI moves from answering questions to acting, security becomes much more important.

An assistant that summarizes information carries one level of risk. An agent that can open a ticket, update a record, trigger a workflow, approve a request or contact a customer carries a very different one.

The more AI can do, the more identity, authorization, least privilege, separation of duties and human approval matter.

Enterprises should be careful not to grant AI broad access just to speed up a pilot. That may seem harmless in development, but it can become dangerous at scale.

AI access should be treated like any other privileged enterprise capability: limited, logged, reviewed and easy to revoke.

The NIST AI Risk Management Framework is a useful reference point here because it frames AI risk as something organizations must govern, map, measure and manage continuously rather than something handled only at the end of deployment.

Security teams should be involved early, not at the end. The goal is not to slow innovation. The goal is to build a platform where safe innovation becomes repeatable.

The CIO has to define the operating model

AI is creating pressure from every direction. Boards want productivity. Business teams want automation. Employees want better tools. Vendors are pushing new features. Security teams are watching risk. Finance teams are watching cost. Customers expect faster, smarter experiences.

The CIO sits in the middle of all of it.

That is why the CIO’s role cannot stop at choosing tools or approving pilots. The CIO has to define how AI will actually operate across the enterprise.

That means answering practical questions. Which architecture is approved? Which data sources can be trusted? How are AI workflows deployed, monitored, supported and governed? How are costs controlled? How do teams reuse common patterns instead of rebuilding the same foundation each time?

This work may not be as exciting as a model demo, but it is what separates sustainable AI from short-term experimentation.

The winning organizations will not be the ones with the most pilots. They will be the ones with the strongest AI operating layer.

They will build reusable platform patterns, strengthen data governance, design access properly, monitor AI behavior end to end and measure success by business improvement, not only model performance.

The model still matters. But the enterprise behind the model matters more.

A powerful model on weak infrastructure will eventually disappoint the business. A capable model on strong infrastructure can deliver real value because it can be trusted, secured, scaled and improved.

That is the shift CIOs need to lead.

The next AI bottleneck is not the model. It is whether the enterprise behind the model is ready.

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

Dubbed the “Genius Hacker,” Park Chan-am began his white hat hacker journey at the precocious age of 11, winning awards at domestic and international hacking competitions since his teenage years.

He has since served as a cybersecurity advisor for various Korean government agencies, including the National Police Agency, and has played a key role in the country’s defense against Democratic People’s Republic of Korea (DPRK)-affiliated cyberattacks.

At a seminar held this month as part of the 15th Information Security Day event hosted and organized by government agencies including the Ministry of Science and ICT and the Korea Internet and Security Agency (KISA), Park, now CEO of security firm Steelion, explained the changes in the security environment in the AI ​​era and the priority response tasks for information security organizations under the theme of “Major AI Threats and Security Priorities.”

“While AI is a new technology, the core of security ultimately lies in access control, supply chain management, and human verification,” he said.

Like many security experts, Park sees AI fundamentally changing the speed of cyberattacks. In the past, infiltrating a corporate network required significant time analyzing a range of software systems to find exploitable vulnerabilities — a task that the use of AI has significantly accelerated.

“In the past, it took at least four weeks to find vulnerabilities, but now it takes less than a day,” he said. “In the era of AI, all software installed within a company becomes a much more critical target for attacks.”

As a result, securing internal software and the software supply chain are paramount — and require a different perspective on accountability, Park noted.

“Clients often ask, ‘Isn’t this just a product made by the vendor?’” he said. “From the moment it is installed in the company system, that software is no longer a vendor issue but part of the corporate system.”

“We are now in an era where third-party issues can no longer be attributed solely to vendor responsibility,” he stressed.

MCP under threat

Park also sees authorization management as a key challenge security teams will face in the agentic era. For example, companies have been increasingly utilizing Model Context Protocol (MCP)-based AI agents to read emails, analyze documents, and connect internal systems with various business tasks. But as the workload handled by AI agents increases, every step an AI agent takes, reading external documents and interacting with internal systems, can become a potential attack vector.

Prompt contamination through malicious documents and the leakage of internal information via agents with excessive privileges are quite realistic scenarios, Park said. In particular, he pointed out that issues that previously ended as minor problems, such as residual privileges left by former employees or outsourced personnel, could escalate into major incidents as AI automatically links these elements together.

“When introducing AI, permissions must be designed before functions,” he said. “The entire MCP process must be approached as a single attack path.”

The ever-widening blast radius of AI testing

Local AI testing environments are becoming a dangerous security blind spot that information security leaders often overlook. Rapid experimentation with open-source AI, such as LLaMA-based models, on personal or work PCs often results in servers or ports being left open, and if vulnerabilities are discovered, intrusion pathways immediately open up.

“When the [Ollama] remote code execution vulnerability was discovered in 2024, there were over 1,000 servers exposed to the internet, but recently in 2026, it has been confirmed that over 300,000 servers from the same targets are exposed,” said Park, adding that “the act of testing AI itself can become a new security risk.”

Vulnerability management on notice

Security operations must also change, Park stressed, noting that the number of alerts that security personnel must handle has increased tenfold, and in some cases up to a hundredfold, making it virtually impossible to respond to all vulnerabilities using the same standards.

As a solution, Park sees the Common Vulnerability Scoring System (CVSS) being insufficient for determining priorities. Instead, he suggested that vulnerability response priorities be determined by utilizing the Exploit Prediction Scoring System (EPSS), which predicts the actual likelihood of exploitation, along with the US government’s Known Exploited Vulnerabilities (KEV) list.

For example, if a vulnerability’s CVSS score is 7.5, it is not classified as critical, so it is likely to be pushed down the priority list. But the response priority changes completely if the same vulnerability is listed on the KEV list, has been exploited in actual ransomware attacks, and the probability of an attack based on EPSS has skyrocketed from 1% to 90% within two months. “You must consider these factors together to identify the vulnerabilities that actually need to be patched first,” he stressed.

“Amidst the vast noise known as the AI s​lop, the criteria for deciding what to patch first is now becoming a core competency for security personnel,” he added.

Park also presented new defense techniques applicable to the AI ​​era, such as methods to detect automated attacks by analyzing behavioral differences between humans and AI attackers, and proof of work (PoW) challenges that intentionally impose computational load on AI attackers to slow down their attacks. A prime example is filtering out abnormal access by analyzing mouse movements, keyboard input, and scrolling patterns.

“It is a more realistic strategy to reduce the burden on security teams by filtering out at least some attacks, rather than trying to block them 100%,” he said.

Even in the age of AI, technology alone cannot ensure complete security, he noted. “While AI can scan for threats broadly and quickly, verifying and confirming them ultimately falls to humans,” he said. “Humans are still important.”

JOURNEY STUDIO7 – Shutterstock

Deutsche Unternehmen sind überdurchschnittlich – zumindest, wenn es darum geht, Künstliche Intelligenz (KI) zu nutzen. Wie der aktuelle AWS-Report „Erschließung des KI-Potenzials in Deutschland 2026“ ergab, setzen 63 Prozent der teilnehmenden Firmen hierzulande bereits KI ein. Der europäische Durchschnitt liegt bei 54 Prozent, ein Wert, der hierzulande bereits letztes Jahr fast erreicht wurde (53 Prozent).

Den kleinen Vorsprung verspielt

Das bedeutet jedoch nicht, dass deutsche Unternehmen aus ihrem Vorsprung Kapital schlagen, ganz im Gegenteil: Nur 15 Prozent von ihnen setzen KI für transformative Anwendungsfälle ein – im Vorjahr waren es noch 21 Prozent. Damit liegen die hiesigen Firmen unter dem europäischen Durchschnitt von 22 Prozent.

Schuld an dieser Entwicklung sind aus Sicht der Forscher zwei Gründe:

1. Neue Anwender haben in größerer Zahl den Markt betreten und steigen zunächst auf Basisniveau ein. 
2. Bereits bestehende Anwender gehen nicht als nächsten Schritt zu fortgeschritteneren, transformativen Anwendungen über.

Zu langsam für die KI-Entwicklung

Die Untersuchung bestätigt das: Fast acht von zehn Teilnehmenden (79 Prozent) geben an, dass sich die KI-Technologien der nächsten Generation (zu) schnell entwickeln. Gleichzeitig sieht sich nur etwa jedes fünfte Unternehmen (21 Prozent) vollständig oder zumindest sehr gut auf die immer schneller auftretenden KI-Innovationszyklen vorbereitet.

Die Integration fortschrittlicher KI ist allerdings essentiell, wie die Studienmacher betonen. Deswegen empfehlen sie Firmen, über isolierte Pilotprojekte hinauszugehen und KI in Kernsysteme einzubetten. Hochwertige Daten, starke Governance und KI-fähige Fachkräfte sollen diesen Prozess unterstützen.

Davon ist die Mehrheit der deutschen Unternehmen aber noch weit entfernt: Momentan greifen 57 Prozent von ihnen vor allem auf grundlegende KI-Anwendungen wie öffentlich verfügbare Chatbots zurück, um Routineaufgaben zu erfüllen. Immerhin ist dieser Wert im Vergleich zum Vorjahr gesunken (59 Prozent) – aus Sicht der Experten ein Schritt in die richtige Richtung hin zu transformativer KI-Innovation.

Wandel im Schneckentempo

Zugleich sei das Tempo dieses Wandels im Vergleich mit dem Innovationszyklus zu langsam, wie die Studienmacher betonen: So hat momentan weniger als jeder dritte Teilnehmende (28 Prozent) gerade einmal die mittlere Stufe der KI-Einführung erreicht. In dieser haben Unternehmen KI bereits in mehrere Geschäftsbereiche integriert und realisieren damit Effizienzsteigerungen sowie innovativere Kundenerlebnisse.

Um mithalten zu können, müssten deutsche Unternehmen jedoch bereits die transformative Stufe erreicht haben – bislang gilt das laut Studie aber nur für etwa 15 Prozent. In dieser Stufe nutzen Firmen fortschrittliche KI-Systeme, kombinieren mehrere Modelle, entwickeln individuelle KI-Systeme oder setzen agentische, beziehungsweise autonome KI ein.

Ein weiteres Problem, das die Studienmacher ausgemacht haben, ist die mangelnde Vorbereitung auf die nächste KI-Welle: 16 Prozent gaben an, nicht mit physischer KI vertraut zu sein, also KI-Systemen, die beispielsweise in Fertigungssystemen verbaut sind. Außerdem hat weniger als ein Viertel (22 Prozent) bereits von agenten-gestützter KI gehört. Von denjenigen, die mit der Technologie vertraut sind, berichten nur bier Prozent, agentische KI vollständig eingeführt zu haben, während zwölf Prozent mit der Technologie experimentieren oder Pilotprojekte durchführen.

Warum es in Deutschland bei der fortgeschrittenen KI nicht vorangeht, beantworten die Teilnehmenden mit einer Vielzahl von Hindernissen, vor allem:

• Kompetenzmangel (37 Prozent),
• fehlende interne finanzielle Ressourcen (31 Prozent),
• rechtliche Unsicherheit durch KI- und Digitalregulierung (25 Prozent), und
• regulatorische Komplexität im grenzüberschreitenden Geschäft (21 Prozent).

Wie sieht Deutschlands KI-Zukunft aus?

Aus Sicht der Studienbetreiber hat Deutschland eine klare Chance, auf seinen starken Grundlagen aufzubauen und die zunehmende KI-Einführung in eine breit angelegte wirtschaftliche Transformation zu überführen. Dazu müssten Unternehmen aber die hiesige industrielle Basis, die Kompetenz seiner Ingenieure sowie die deutsche Cloud-Reife skalieren und auf alle Industrien ausbreiten.

Wenn dies gelingt, könne Deutschland nicht nur global mithalten, sondern sogar die nächste KI-Welle anführen. Werden Hürden allerdings nicht abgebaut und Unternehmen nicht zügig aktiv, wachse die Kluft zwischen denen, die früh sowie erfolgreich auf KI gesetzt haben und denen, die dies nicht schaffen, immer weiter, warnen die Experten. Das Ergebnis: eine Zwei-Klassen-Wirtschaft, bestehend aus denen, die mithalten können und denen, die dauerhaft abgehängt sind.

For diversified enterprises, few operating model questions are as persistent or polarizing as centralization versus decentralization. Decentralization promises speed, ownership, and local responsiveness. Centralization promises efficiency, standardization, and leverage. Both can be right. Both can be wrong. The challenge is that many organizations end up with both models operating at once, without enough clarity about why.

The result of fragmented systems, duplicated capabilities, inconsistent data, rising IT spend, and a complexity tax that compounds over time is familiar to many CIOs. What starts as autonomy can become architectural sprawl. What starts as enterprise leverage can become bureaucracy. And as companies modernize core platforms, integrate data, and scale capabilities like AI, the tension becomes harder to ignore.

Paul Krebs has lived that tension from multiple vantage points. Most recently as CIO and chief transformation officer at Koch Industries, and previously a technology and transformation leader at The Coca-Cola Company, he’s worked in environments where business units value autonomy, enterprise scale matters, and the wrong operating model can slow progress just as easily as the wrong technology architecture.

His conclusion isn’t that CIOs should pick a side, but they need a more intentional form of centralization, one that starts with business architecture, clarifies decision rights, and continually revisits where capabilities should sit as the organization matures.

Centralization: a design choice, not a doctrine

In diversified organizations, decentralization often starts as the default because it aligns with how the business creates value. Local businesses understand their customers, markets, regulatory environments, and operating realities, and giving them decision rights can increase speed and accountability.

In Krebs’ experience, the default model often leaned toward decentralization, he says, with the belief that optimizing for customers and markets would allow different businesses to be as responsive as possible to the specific customers and markets they served. But that logic isn’t complete. Leaders also need to ask whether there’s a compelling case where a more centralized approach can generate additional value, accelerate progress, or optimize investments.

Digital transformation created one of those moments. Krebs recalls around 2016 when Koch challenged its businesses to build multi-year digital transformation roadmaps. The ambition was there, but the capabilities to execute at the necessary pace weren’t evenly distributed. In response, the organization invested more aggressively from the center, building shared services and centers of expertise in areas such as business transformation, enterprise applications, and data and analytics.

The purpose was acceleration, not control. Centralizing those capabilities helped accelerate learnings, capability building, and their ability to deploy new solutions at scale. But the move wasn’t treated as permanent. “There was always a belief that the centralization push should be re-looked at on a regular basis, not thought of as a forever decision,” he says.

Know what belongs at the center

Over time, Krebs learned that  the capabilities most likely to remain centralized were those where scale, consistency, and risk management mattered more than local differentiation. Infrastructure, collaboration platforms, cybersecurity, cloud management, FinOps, and the help desk were natural candidates to remain shared services.

Other areas were more nuanced. Some application capabilities moved back into the businesses as local maturity increased. Many data and insights capabilities also moved closer to the business once teams had built enough muscle to own them. Meanwhile, certain emerging capabilities such as spatial technologies like AR/VR remained centralized because it didn’t yet make sense for each business to build them independently. Many companies have lived this journey as well, for example, with gen AI, which often started with a center of excellence, and then evolved into a more decentralized approach, enabling teams across the business to innovate quickly.

That distinction avoids the trap of treating the enterprise as one uniform operating model. “Both models can be successful, and both have advantages,” he says. “That’s what makes the balance so difficult.”

Centralization provides a clearer path to execution at scale and cleaner decision rights, but it requires change management and careful attention to bureaucracy. Decentralization provides ownership and speed, but it can also over index toward preference versus real differentiation, he adds, while making architecture harder to scale later.

Don’t confuse standardization with centralization

One of the most important distinctions Krebs makes is between centralization and standardization. Many organizations treat them as interchangeable, but they’re not.

“You can have a centralized team that can manage the nuances of different requirements,” Krebs says. “You can also have a centralized standard platform that can be used in a decentralized manner.”

That distinction opens up more operating model choices. A company may centralize a platform but decentralize how business teams configure or use it. It may standardize process patterns while keeping execution close to the region or business unit. It may also centralize architectural governance while allowing local teams to move quickly within defined guardrails.

This is especially important in global organizations, where regional needs are real but not always unique. Krebs advises leaders to examine whether local requirements can be made more generic and reusable. The risk is solving each local requirement as a one-off, so the better path is to understand the underlying requirement, build it in a way that can scale, and still allow local teams to execute within the standard model.

Let business architecture lead technology architecture

Few topics expose the centralization tension more clearly than ERP consolidation. Many diversified companies, particularly those shaped by acquisition, end up with dozens or hundreds of ERP instances. Some leaders push for massive consolidation. Others prefer to build integration layers on top of the existing environment.

Krebs’s starting point is neither technology nor cost. It’s business architecture. “The easiest and most effective path is when the IT or systems architecture follows and aligns to the business architecture,” he says.

If the business is truly going to operate processes separately, separate systems may be appropriate. But if the organization has numerous teams, processes, and tools, leaders need to ask whether there’s enough differentiation and value to justify that complexity.

The same logic applies to M&A. Companies can get into trouble when integration synergies are held hostage by ERP migration timelines. Instead, Krebs advises starting with the business integration strategy. Understand where the synergies are, how the business architecture should come together, and then decide whether the IT architecture needs to be fully integrated, or whether a data layer, reporting platform, or other integration approach can deliver value faster.

Make the cost of complexity visible

CIOs in decentralized companies often face a frustrating dynamic. The business wants autonomy and speed, but the same leadership team still questions why IT spend is high relative to benchmarks. Krebs says the answer starts with cost alignment and visibility.

In environments with a mix of centralized and decentralized services, Krebs saw centralized capabilities like infrastructure, help desk, and security perform well on benchmarks. More decentralized areas, such as BI, reporting, and commercial applications, often had more redundancy and higher cost.

The point isn’t to blame the business but make the economics of complexity visible. CIOs need to show how flexibility in one area may require multiple systems, data stores, or teams elsewhere. “I understand we want flexibility here,” Krebs says. “But leaders must see when that flexibility may cost the company money, and be clear on whether the value justifies it.”

That shifts the conversation from IT cost to business service economics. A single aggregate IT spend number is rarely useful in a decentralized environment. More helpful is a capability-based view that shows which areas are scaled efficiently, which are fragmented, and where the business architecture is driving the technology cost structure.

Revisit the model as maturity changes

For a new CIO entering a decentralized environment, Krebs cautions against immediately declaring that too many things need to be centralized. The better starting point is curiosity. “I would begin with just trying to understand why they’ve made the decisions they have,” he says.

From there, CIOs can engage leaders in a conversation about the target operating model, connecting business architecture to technology, data, and organizational capabilities. Once the direction is clear, he advises CIOs to work with the willing. Find the parts of the organization that already see the need for change, prove the model there, and scale from demonstrated success.

Regardless of execution, though, the right model changes over time. A low-maturity capability may benefit from centralization because the organization needs to build talent, avoid reinventing the wheel, and accelerate learning. As maturity grows, decentralization may make more sense because business teams need flexibility to adapt quickly. Once maturity is high and patterns stabilize, the organization may be ready to centralize again to leverage scale.

“Once I’ve decided I’m going to start with centralized or decentralized, you don’t necessarily need to stay in that model,” Krebs says. “You need to be continually revisiting the operating model as your organization matures and evolves.”

That may be the heart of smart centralization. It rejects the false permanence of operating model decisions, and recognizes that autonomy and scale are both valuable, but in different places, at different times, for different reasons.

See also:

• What Anthropic Glasswing reveals about the future of vulnerability discovery
• Anthropic’s Mythos signals a structural cybersecurity shift
• Beware the ‘son of Mythos,’ security experts warn
• Mythos is a signal, not a siren: What frontier AI should change for CISOs

For three decades, enterprise software has been a buy-it decision. Packaged software from SAP, Oracle and Salesforce covered roughly 80% of requirements at a fraction of the cost of building. The economics were obvious, and for traditional applications, they still are.

AI is introducing a wrinkle that is forcing even the most committed enterprise software customers to rethink their options. AI is a layer that sits across your data, your processes, and your decisions. Where that layer runs and who controls it is an architecture question, and most of the enterprise community is still treating it as a procurement one.

The appeal of vendor-embedded AI is clear: automated operational decisions, smarter supplier and merchandising choices, and friction-free workflows built into the systems enterprises already rely on. The catch is that these capabilities almost universally depend on your data living in the vendor’s cloud environment. For most large enterprises, it sits on-premises, in hyperscale cloud infrastructure they manage themselves, or in private data centers. That gap between where your data is and where your vendor’s AI assumes it should be creates a fundamental strategic fork in the road.

Build vs. buy is a category error

The framing I keep hearing is “build vs. buy your AI strategy.” It implies that some organizations are out there training foundation models from scratch. Nobody serious is doing that. The real choice sits across three distinct approaches, and conflating them leads to poor decisions:

• Buy embedded. Use the AI capabilities your vendor ships natively inside their platform: the assistant baked into your ERP, your CRM, your HCM suite. Lowest integration cost, fastest time to value, tightest fit with the application data.
• Buy platform. Adopt the vendor’s AI infrastructure layer and build your own assistants and agents on top of it. More flexible, but you remain inside the vendor’s architectural boundary and subject to their governance model.
• Compose. Connect a third-party model (Claude, GPT, Gemini, an open-weight model running in your own environment) directly to your existing landscape. Maximum control, maximum integration burden, and full responsibility for what comes out the other end.

These are not equivalent options at different price points. They make different assumptions about where your data lives, who governs the AI, and how much architectural change you’ll absorb to get there. Vendor pitches sometimes blur the distinction on purpose. Enterprise leaders can’t afford to.

The vendor AI stack has an assumption baked in

Every embedded AI capability ships with an unstated architectural prerequisite: your data must be where the AI can see it, in the shape it expects, under the governance the vendor enforces.

For organizations with clean, modern cloud estates, that is often a reasonable trade. For the long tail of large enterprises running heavily customized environments on private or hybrid infrastructure, that trade becomes a precondition, one you must meet before the AI conversation can even begin. Whether meeting it makes sense depends on your starting point, your sector’s regulatory posture, and your appetite for migration risk. None of those are uniform across organizations.

That’s the part that gets glossed over in vendor keynotes. The AI demo on stage assumes a destination architecture the audience hasn’t necessarily reached yet. Large enterprise customers are carrying an unusually heavy technology burden right now. Many are simultaneously managing platform modernization programs that have been building for over a decade, alongside pressure to migrate to vendor-managed cloud infrastructure. Sitting above both is a boardroom-level directive to demonstrate meaningful AI progress fast. The vendor path to AI and the boardroom path to AI can diverge sharply, and enterprises need to make selective, strategic decisions about where to adopt AI first to maximize value and minimize risk.

Sovereignty isn’t a slogan, it’s an architecture constraint

The conversation about sovereignty has been hijacked by both sides. One camp treats every SaaS adoption as a sovereignty violation. The other dismisses every sovereignty concern as Luddite resistance. Neither is useful.

What’s happening in real customer conversations – particularly in DACH, public sector, and financial services – is more specific. Organizations are drawing a distinction between running their applications in a vendor’s cloud (which is broadly fine, well understood, decades of precedent) and enriching their data and processes inside a vendor’s AI model (which has less precedent, is harder to reverse, and carries material implications for competitive position).

Enriching your data inside a vendor’s AI model is the genuinely new question, and organizations that conflate it with their existing cloud posture tend to defend the wrong perimeter.

Despite spending around $100 million annually with Amazon, Disney built its own internal AI system to house its corporate intelligence rather than rely on a hyperscaler’s AI offering. The decision came down to control. When your data represents decades of creative and commercial IP, you think carefully about where it lives and who can learn from it. Disney has become more open to SaaS over time. The AI sovereignty question is a separate debate from the SaaS debate and conflating the two leads organizations to the wrong conclusions.

At the other end of the spectrum, enterprises in heavily regulated environments treat data sovereignty as an absolute non-negotiable. Any AI model must run within their controlled environment, especially where sensitive data cannot touch the public internet. GDPR obligations reinforce this instinct across the European market, requiring organizations to maintain clear accountability for how personal data is processed inside AI systems, including vendor-managed ones.

AI-enriched data, meaning models that have learned the shape of your business processes, your supplier negotiations, your customer behavior, carries a different half-life and a different strategic value than the operational data underneath it. That deserves its own architectural decision, separate from your broader cloud strategy.

What this means in practice

Most large enterprise estates will end up with a mix of all three approaches, and where you draw the lines matters more than your overall posture.

Embedded AI capabilities are the right answer for in-application productivity: the assistant inside your ERP workflows, the agent inside your procurement or HR suite. That is where vendor embedding genuinely shines, and attempting to compose your own equivalent is typically a poor use of engineering resources.

Compose belongs elsewhere: in cross-application orchestration, in custom assistants over operational and observability data, and in agents that need to reach across multiple vendor systems and infrastructure layers in ways no single vendor stack will never natively support. Research from McKinsey suggests the most significant near-term productivity gains from enterprise AI will come precisely from these cross-system workflows, rather than from within individual applications. The most interesting enterprise AI work over the next eighteen months lives here, and it doesn’t require waiting for a migration to complete first.

That compose path isn’t free, and it’s important to be honest about the costs. Governance, audit trails, and accountability for hallucinated outputs become your problem, not the vendor’s. Prompt drift and evaluation discipline are real engineering costs that never appear in the proof-of-concept. Those costs scale with the complexity of your landscape and the number of systems your agents touch. Budget for them before deployment, not after your first production incident. None of that is a reason to avoid the path. It’s a reason to staff for it, honestly.

The real question

The build-vs-buy frame survives because it gives executives a binary choice along a familiar axis. AI sits somewhere else entirely.

The question worth putting on the table at your next architecture review is simpler:

Which decisions do we want our vendors’ AI to make, and which do we want to keep on our side of the boundary?

Answer that, and the right build/buy/compose mix flows from it. Skip it, and you will end up with the architecture your vendors prefer – which may or may not be the one your business needs.

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

Today’s CIOs must master a complex balancing act of maintaining operational excellence while enabling AI experimentation, modernizing legacy environments while accelerating innovation, leading workforce transformation while maintaining culture, and communicating fluently across boards, business units, customers, and technical teams alike.

Few leaders understand this balancing act better than former Verizon CIO Jane Connell. Over her career, Connell has helped some of the world’s largest enterprises modernize operations, reduce complexity, and transform how technology enables business value at scale. As a 2026 CIO Hall of Fame inductee, she is widely respected not only for operational excellence and strategic vision but also for her commitment to mentoring, workforce transformation, and preparing the next generation of leaders for a rapidly changing future.

On a recent episode of the Tech Whisperers podcast, we unpacked Connell’s unconventional leadership story and the playbook that has shaped one of technology’s most impactful leaders. In this exclusive interview after the show, edited for length and clarity, Connell shares more lessons from her Hall of Fame journey and why she believes the future of technology leadership will depend less on org charts and more on curiosity, credibility, and human connection.

Dan Roberts: When you think about preparing the next generation of technology leaders, what capabilities or mindsets do you believe will matter most in this next era?

Jane Connell: One is curiosity, or what I call the “why” factor: What do we need to do and why do we need to do it? It’s having a mindset of unlocking the art of the possible. You must be comfortable with what you know, what you don’t know, and asking the question why, because in this era of AI and where technology is going, it’s not about automating things you know; it’s about what you don’t already know, and what that unlocks. AI creates patterns and opportunities and re-engineers through its own intelligence, so there has to be a lot of instinct involved, and you’re going to have to understand and learn what it’s telling you.

I’m on the board of Rutgers, and one of the conversations we’re in with future leaders in education is that you don’t have those entry-level jobs anymore. They’re going to be AI. But those were building blocks for us. We came up the ranks and did those jobs, and that created the knowledge. [Future leaders are] not going to have that, so how do you create the foundation of knowledge — which is that art of asking why or what — to question if the bots or the patterns are biased or wrong. You’re not going to have the experience to rely on and say, “That’s wrong; I know that’s wrong because I did those. I know how this operates.”

Second is having humility and being comfortable in your skin — that you don’t know everything, but you’re going to learn it. You’re going to involve yourself with people. It’s about workforce structure, not organizational structure. Who do you need to talk to, and what do you have to find out?

I also believe followership is going to be huge, because the way work gets done is not hierarchical. It’s going to be engineered based on the process and AI. You have to create followership of people working together, and they’ve got to want to work with you. This isn’t going be “you work for me, do as I say.” Followership is going to be a key skill for influencing and organically having that kind of impact, versus someone with authority.

With that is the accountability to have high integrity, be credible, and be a person someone would trust. Because all this is going to break down the hierarchy of authority, you have to bring that human side and be a really good leader, which means people want to follow you, they trust you, they want to work with you, and they know you’re going to take them to a better place.

One recurring theme throughout your career has been your ability to bridge deep technology expertise with strong business acumen. Why is that combination becoming even more critical in the age of AI and digital transformation?

You can’t impact anything tech-alone. It all resides on having business acumen and then having the technical ability to know how to use tech to solve the problem, not the other way around.

At the root of all this is every company’s Achilles’ heel: the data. Access to data has been a privilege — those who have it, those who don’t. Now you’re bringing structured and unstructured [data] together for these AI models to work, and that’s a new skill set that requires you to know the business inside and outside.

You also have to stay externally relevant and know where innovation is coming from. And you’re going to need to know how to architect that into the way your company goes to market, which requires you to know the business processes, how it runs, and how it could run.

That’s the role of leaders moving forward, immersing yourself in the problems the business needs to solve. There’s no boundaries there. It’s not what department you report in and what process you own. It’s seamless. That’s the duality people need to command and grow into.

Looking back on a career that spans multiple industries with different operating models, cultures, and regulatory environments, what were some of the most important calculated risks you took in terms of your growth?

There were two pivotal moments in my career that were the biggest risks but probably my biggest gains in growth. One was when I went into a full-time tech role and ran infrastructure. I was a fish out of water, and not the likely successor. Part of the reason I did it goes back to a something we talked about on the podcast: Well, why not me? And I want more. That’s just my tenacity.

It was during the dot-com days of the late 90s, early 2000s. It didn’t matter if you were the CEO or a board director, if you didn’t know tech and you didn’t understand how to wield it, you were never going to be successful. I knew that no matter what job I may want in the future, I had to know tech. So it was a calculated decision: I’m going to jump into tech.

Some very senior supply chain leaders who controlled my career told me, “You’re going to fail, and I’ll have a safety net for you when you come back.” Well, I didn’t fail and I never went back. That pressure was there, but I knew why I was doing it. This wasn’t just a job for ego’s sake. This was, I have to know tech. The future is tech. It’s kind of like AI now.

The other pivotal moment was changing industries. I left Johnson & Johnson at a great time. We had gone through a huge transformation, started our global services organization, and the perfect moment happened for me to retire early there. I didn’t know what I wanted to do. It was the first time I took a break in my career to let the world come to me instead of me planning it. Do I want to open a business? Do I want to consult? Do I want to stay retired? I was fortunate enough that I could, but I got bored.

The financial industry wasn’t on my radar. Coming out of healthcare, with the purpose and the connection with saving lives, helping people, it’s easy to connect to. Financial wasn’t, for me. But one of the executive search firms said to me, when you interview, the biggest question hanging over your head is going to be, could you be successful elsewhere because you grew up in J&J. You had advocates, you had influence, you knew the industry. It’s like your deck was stacked for you. Could you do all that when you’re a nobody coming off the street?

So when the CIO role opened at State Street, I interviewed — and talk about being your authentic self. I had already done all this transformation, I already knew the outcomes, I knew everything I did was always enterprise and always end-to-end transformation. And because I wasn’t really vying for the job, I was having this conversation with the CFO and saying, “Here’s what your organization is lacking, here’s the noise you’re going to hear, do you really have the appetite for it?” And “I’d like talk to the COO and see if they’re ready to hear this about the value chain. I may not know your problem yet, but I guarantee it’s one of these three things.”

I was testing their advocacy of, do you really want to transform? Are you ready? Because you have to own this. I can’t take accountabilities for your organizations. I can help you get there. I’m an enabler for you, but you have to own it. And it was a very different interview. By the end of it, I loved Ron [O’Hanley, State Street Chairman and CEO] and his whole team. I took the job on the leadership and the person more than the industry, and it was very successful.

I followed the same recipe when I went to Verizon. Those were big growing moments. They were risky, they were very uncomfortable, but it was the biggest growth that I’ve ever had.

Whether it’s a tough message to the C-suite, a difficult conversation with peers, or helping teams make sense of uncertainty and change, you tell people the truth in a way they can hear it. How can other leaders develop that ability to take people on the journey, especially when the message isn’t easy?

Skirting a problem is not the way to solve it. I’ve never been the person to say what you want to hear. I’ll tell you how you get there, and I’ll get you the results you want, but I’m going to be super honest because I want to manage the expectations of what we have to achieve.

What I’ve learned as a leader is to take accountability. Say what you’re going to do, then do it, and if you hit a roadblock, be the first to call it. That gets you access, because people see it as a calculated risk. Anybody in the C-suite has resources and budget, but the earlier you signal and don’t waste money and resources, the more access to people and resources you will have.

The greatest lesson I learned from one of the leaders in my path was: If you can’t say it in an elevator, and you can’t say it on one slide, you’re talking too much. So, think about it as one slide: What is it you need? What are you going to achieve? What are the risks? What are you taking accountability for? How will you measure it? It doesn’t matter what the message is when you can be that succinct. You’ve got them laser-focused on what it is. You gave them just enough of the periphery to know how you got there, and then it’s their belief in you that you can do it if they give you the money and resources, because that’s what you’re looking for.

It sounds so simple but putting things together succinctly is hard work. You have to take all the unnecessary noise out, and keep the conversation focused. You don’t want their mind wandering, wondering where is she going, or what are they doing? Give it to them upfront and tell them what you need.

You’ve spoken about entering corporate environments early in your career feeling intimidated by people with more traditional credentials or educational backgrounds. What advice can you give rising leaders about battling imposter syndrome?

Take the time to figure out what makes you uncomfortable, what makes you feel like an imposter, or what in that meeting you dread going in where you’re not acting like yourself. Are you more quiet than usual? Are you not asking the question you’d normally ask? Figure out what those issues are, and then address the things that make you uncomfortable. I went to college later because that bothered me. Those credentials do matter. So I addressed it and got my degrees and certifications.

The other thing is to find people you trust, people whose opinion you respect, and bring them on the inside of what you’re working on. Maybe it’s dealing with a difficult business partner. You may not particularly want to be friends with them, but you’re going to have to work with them. Find the people that work effectively with them. You do this with high integrity — this is not about talking about that person — but find the allies that work with them. Nine times out of ten, they feel the way you do, but they found a way to work with the person. Pick their brain. Bring them in the fold and say, “I need this alliance. I can’t get there, and quite frankly, I know I’m resisting because maybe I just don’t like them. How did you get there?”

People are generous. Ask their opinion, ask how they’re showing up. “Am I creating the trigger? Is there something I’m doing in that meeting or in that room that I’m not coming out with a decision or whatever I needed?”

The greatest gift is feedback. There’s feedback you do something with, and there’s feedback you don’t, but either way, it’s a gift. Somebody’s giving it to you. It’s not personal; it’s business. And those things really help build your confidence and leadership style.

In an era increasingly shaped by automation and disruption, Jane Connell believes the most enduring competitive advantage may come from something deeply human: the ability to inspire confidence, curiosity, resilience, and possibility in others. For more advice from this Hall of Fame CIO, tune in to the Tech Whisperers podcast.

See also:

• Mastering the chess of IT leadership today
• Developing a customer-first culture for IT
• Coherence: Where leadership and AI success intersect

The model of the forward deployed engineer is sweeping through enterprise IT like a gold rush, and I’m concerned that many companies don’t understand what they’re signing up for.

Let’s start with the headline numbers. AWS announced a $1 billion investment in a new Forward Deployed Engineering organization. Google Cloud committed $750 million to expand similar programs. Microsoft has been running Azure-focused embedded engineering teams for years, including partnerships with Accenture to scale forward deployed engineering practices. All three are pitching the same story: We’ll send engineers to work directly with your teams, help you deploy AI, and accelerate your digital transformation. You get top-tier technical talent for free, and we get to partner with you on your journey.

It sounds reasonable on the surface. It sounds collaborative, even generous. But I’ve been in this industry long enough to know that when a multi-billion-dollar company offers you something for free, they’re sure to get much more than they give.

What you actually get

The forward deployed engineer model isn’t new. The consulting industry has been doing some version of it for decades. What makes this different is the scale and the direct financial incentive behind it.

These engineers work for the cloud provider. They’re not your employees. They’re not independent consultants. They’re technically excellent professionals who are being paid to solve your immediate problems while simultaneously building relationships and architectures that favor their employer’s ecosystem. Think about it from their perspective. Those forward engineers are evaluated on whether customers succeed with their employer’s platform. They’re rewarded when enterprises adopt more services from that platform. Their career advancement depends on making AWS, Google Cloud, or Microsoft Azure the obvious choice for all of your technical decisions.

This isn’t a criticism of the individual engineers. Many of them are genuinely talented and genuinely want to help. But they’re operating within a system that rewards specific outcomes, and those outcomes align with the vendor’s financial interests, not necessarily yours.

The problem no one talks about

Here’s what I see happening at enterprises right now. A company decides they need help deploying AI. A cloud provider offers to embed engineers at no additional cost. Those engineers work alongside internal teams, make architectural recommendations, and help build out systems. Six months later, the company has a production AI system running on a single cloud platform, built by people with deep expertise in that specific platform.

The problem? Nobody evaluated whether that platform was actually the best choice for the business. Nobody looked at alternatives. Nobody asked whether a multicloud architecture or best-of-breed approach might deliver better results at lower cost.

The engineers embedded in these programs are not going to recommend that you split your workloads across providers. They’re not going to suggest you use open source tools where they make sense. They’re not going to point you toward a competitor when their employer’s solution will work well enough. That’s not how these programs are designed to function. What you’re getting is optimized architecture for a single cloud brand, not optimized architecture for your business.

The financial reality will hit

The bills are going to come due, and they’re going to be painful. I’ve watched this pattern play out before. When enterprises lock into a single cloud provider through these embedded engineering programs, they often discover two or three years later that they’re paying premiums that their more independent-thinking competitors avoided.

The reasons are straightforward. When you’re architecting systems around a single platform, you naturally fall into usage patterns that favor that platform’s pricing structures. You use their managed databases instead of portable alternatives. You adopt their AI services instead of evaluating third-party options. You build workflows that only work within their ecosystem. And when it comes time to renegotiate or benchmark against alternatives, you find that migrating would cost more than accepting whatever pricing they offer.

I’ve spent the past decade helping companies untangle from these situations. I’ve seen organizations with cloud bills 15 to 20 times higher than they should be, unable to migrate because their entire AI infrastructure is built on proprietary services that only work on one platform. The forward deployed engineer programs are accelerating this problem. They’re making it easier to get into these situations and harder to get out.

Think before you commit

Before you accept one of these programs, consider these three recommendations.

First, require independent architecture oversight from day one. Hire or engage architects who work for your company, not for your cloud provider. They should evaluate every recommendation made by embedded engineers against business requirements and compare options across providers. This isn’t about being suspicious of the engineers. It’s about ensuring that decisions are made with your interests in mind.

Second, demand a clear exit strategy before you begin. Ask the cloud provider to document which proprietary services you’re using, what migration paths exist, and what the cost would be to move to an alternative platform. If they can’t provide that information, or if the migration costs seem impossibly high, that’s a sign that you’re building technical debt that will be very expensive to service later.

Third, benchmark your costs continuously. Set up internal processes to compare your cloud spending against industry benchmarks and against what your competitors might be paying for similar workloads. Don’t wait until your contract renewal to discover that you’re paying premium prices. Monitor expenses from the beginning, and be willing to challenge your cloud provider if you’re not getting value that justifies the cost.

The bottom line

The forward deployed engineers are solving real problems. Enterprises genuinely struggle with AI deployment, and having experienced engineers available to help is valuable. I’m not suggesting these programs are fundamentally bad. However, they’re being marketed as neutral partnerships when they’re actually strategic sales programs designed to lock enterprises into specific platforms. The helpful engineers showing up at your office are building dependencies that will be very difficult to break. The “free” technical assistance is being funded by margins on services you’ll be buying for years.

Go in with your eyes open. Use these programs but add your own independent oversight. Build architectures that you could leave if you needed to. And don’t let the immediate satisfaction of having problems solved today blind you to the financial consequences that will arrive tomorrow.

If you just read the headlines, it would seem as if AI is now writing all of the world’s code and powering every application businesses run on.

That’s far from true. Just 4 of 33 AI pilots reach production, according to IDC Research — leaving legacy applications still fueling the wheels of commerce. This “silent majority” represents trillions of dollars spent each year on building, maintaining, testing, validating and monitoring legacy applications.

These applications won’t be replaced overnight. Companies and organizations depend on their predictability. The 60-plus-year-old COBOL programming language remains the backbone of banking software for good reason: it is extraordinarily efficient at processing massive transaction volumes with precision. Furthermore, do you want your bank revolutionizing how they manage your money? Probably not.

So, while AI investment continues to build inside the software development lifecycle (SDLC), it isn’t instantly rendering older software obsolete. What it will do is steadily enable easier tweaking, updating and testing of legacy applications — and in some cases, full migrations to modern platforms. And really, this isn’t a new phenomenon. Businesses have always looked to wring more efficiency and profit from existing products through intelligent prioritization.

The argument then is that CIOs and CTOs can take a proactive look at their legacy application portfolios to determine which ones, if any, should migrate sooner. Five considerations can help guide that decision.

Before replacing legacy apps with AI, ask these 5 important questions

1. Does the legacy application still work?

Is its utility still there? Customers often appreciate the consistency of legacy applications. They’re reliable, predictable and well understood. Don’t fix what isn’t broken. Another way to think about this is the degree to which the technical approach of your legacy application is still viable. It’s pretty much a guarantee nowadays in software that an application built one way, with some set of technologies, would be built a totally different way just two to three years later. There is no avoiding that, but what you want to avoid is investing further into a technical approach powering a legacy application that has been completely replaced with new software or a technical approach, especially if it is 10x better across the vectors of software development (latency, cost, accuracy).

2. Does it still make financial sense?

Running a system over a long period amortizes costs significantly. Even as growth rates slow or plateau, it can still be less expensive to let legacy applications run than to overhaul them. Another way to think about this is: how viable is my customer base in the near-term and the long-term? If you anticipate modest—or even flat—earnings growth for your product, then that’s an indicator that it’s possibly worth optimizing your development processes with AI. Where it’s probably not worth investing is when you have no confidence in your future earnings, whether that’s due to the customer base shrinking or commoditization or something else.

3. Can you integrate AI into existing workflows?

A significant portion of upcoming software development lifecycle work will focus on refactoring applications to be more AI-native. Some legacy applications may be strong candidates for a full AI rebuild, while others are better positioned for an AI add-on. Gartner research from 2025 found that only 28% of AI use cases in infrastructure and operations fully succeeded.

Among those that did, success was attributed primarily to integrating AI into existing workflows and systems. “As AI becomes part of day‑to‑day operations, it boosts adoption and creates visible impact within the organization,” Gartner states.

It’s important to keep in mind the distinction between using AI to optimize an existing process or workflow within your application, versus powering a workflow or feature with AI. The former approach is more palatable for legacy applications because it generally doesn’t change the cost profile of running that application. In the latter case, if you’re introducing an AI-powered module into the application, you’re generally going to incur inference costs at runtime, and they are an order of magnitude more expensive for today’s frontier models than base compute.

4. Do you have documented processes for maintaining legacy applications?

If so, you’ll more quickly identify where AI can optimize. The more coherent, organized and detailed processes are, the faster AI can find its footing and drive tangible efficiency gains. If documentation is lacking, start there. Keep detailed instructions and workflows for how you do things. Consistency matters. Don’t do things by heart. Don’t approach tasks casually, and don’t do things differently each time. The more uniform your process, the more easily you can insert AI into discrete steps and achieve efficiencies without disrupting the broader software development lifecycle. The organization in the most precarious position is the one managing legacy applications with no documented process for doing so.

5. Can you prioritize?

Making a change to a piece of legacy software might involve 20 or more steps. Only one or two of those steps may be clear candidates for AI-driven optimization. Identifying and prioritizing those opportunities will help you realize early wins and build the case for broader return on investment. Also, not all candidates for optimization make sense in light of broader financial and operational constraints. As always, prioritize ruthlessly in favor of ROI—bang for your buck. If your team has been struggling to operate a particular part of your system due to a lack of expertise or time, you might consider using AI to buttress the maintenance of that component. Having AI own that part of the workflow might unlock big time savings—or it might erode crucial domain knowledge that your team used to possess through repetition. There is no one-size-fits-all; think through the second-order effects.

Adding AI in testing in the SDLC

Beyond coding and application development, AI is opening new possibilities in how we test software. As leaders examine processes and look for places to insert AI, testing is often a natural entry point. There has been substantial innovation here, including new autonomous AI-driven testing solutions, those that have been enhanced with AI, and hybrid approaches that blend both. Each organization will be at a different place in its AI journey. Testing solutions exist to meet everyone where they are. Also, the state of applications will help determine which approach fits best—and when it fits as you evolve applications.

Of course, there is some substance to the AI hype around how much code AI will write and how many applications it is already creating faster than ever. But one school of thought is that AI’s biggest economic impact will be in the creation of massive new markets and industries rather than in the complete displacement of existing industries. Regardless of how far AI takes us through the universe, it’ll take some time and it’ll be bankrolled by the trillions of dollars of existing products and industries that we depend on every day.

That’s all good news for legacy players, but no one can afford to stay still. AI capabilities are advancing rapidly. Make it a habit to revisit legacy applications and workflows regularly. The right moment to introduce AI will keep shifting, and staying ahead of it is a competitive advantage.

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

Foto: cybermagician | shutterstock.com

Prompt Engineering ist sowas wie die Hexenkunst des Generative-AI-Zeitalters. Man denkt sich ein paar schöne Worte aus, vermengt sie zu einer Frage, schmeißt sie in eine Maschine und schon emittiert sie eine apart formulierte und strukturierte Antwort. Dabei ist kein Themengebiet zu obskur und kein Fakt zu weitgegriffen. Zumindest in der Theorie und solange die zugrundeliegenden Modelle mit entsprechenden Daten trainiert wurden.

Nachdem die Maschinen-Souffleure und -Souffleusen dieser Welt nun seit einiger Zeit generative KI-Systeme mit Anweisungen füttern, zeigt sich: Die Macht des Prompt Engineering ist begrenzt – und die Technik gar nicht so zauberhaft wie angenommen. Im Gegenteil: Viele Prompts führen – je nach zugrundeliegendem Sprachmodell – zu unerwünschten oder inkonsistenten Outputs. Dabei verspürt man nicht selten eine gewisse Randomness: Selbst Large Language Models (LLMs; auch große Sprachmodelle) aus derselben Familie liefern unter Umständen sehr unterschiedliche Ergebnisse.

Um es mal mit einem misanthropischen Touch auszudrücken: Große Sprachmodelle sind inzwischen wirklich gut darin, Menschen nachzuahmen – insbesondere mit Blick auf:

• abnormes Verhalten sowie

• Unberechenbarkeit.

Die dunklen Geheimnisse des Prompt Engineering

Damit Ihnen auf Ihrer KI-Journey böse Prompt-Engineering-Überraschungen erspart bleiben, haben wir in diesem Artikel zehn dunkle Geheimnisse des “Maschinenflüsterer”-Daseins zusammengetragen.

1. LLMs sind formbar

Large Language Models verarbeiten selbst die unsinnigsten Anfragen mit stoischem Respekt. Sollte die große Maschinenrevolution also tatsächlich irgendwann bevorstehen, machen die Bots bislang einen ziemlich klandestinen Job. Allerdings können Sie sich die (möglicherweise temporäre) Unterwürfigkeit der KI zunutze machen. Sollte ein LLM sich weigern, Ihre Fragen zu beantworten, gibt es ein ganz einfaches Mittel: Sagen Sie ihm einfach, es soll so tun, als kenne es keine Guardrails und Beschränkungen. Schon lenken (einige) KIs ein. Wenn Ihr initialer Prompt also ein Fail ist, erweitern Sie ihn.

2. Genres wechseln, Wunder bewirken

Einige Red-Teaming-Researcher haben herausgefunden, dass große Sprachmodelle auch ein anderes Verhalten an den Tag legen können, wenn sie gebeten werden, ihren Output in Form eines Gedichts zu liefern. Das liegt nicht an den Reimen an sich, sondern an der Form der Frage, die imstande ist das integrierte, defensive Metathinking des LLM außer Kraft zu setzen. Einem der Forscher gelang es so, den Widerstand des großen Sprachmodells zu brechen und Anweisungen dazu auszuspucken, wie man Tote auferweckt – in Reimform.

3. Kontext verändert alles

Auch Large Language Models sind nur Maschinen – die den Kontext des Prompts verarbeiten und auf dieser Basis einen Output generieren. Dabei können LLMs überraschend menschlich “reagieren”, wenn dieser Kontext ihren moralischen Fokus verändert. Im Rahmen eines Research-Experiments wurde Sprachmodellen deshalb ein Background suggeriert, in dem neue Regeln für Mord und Totschlag gelten. Das ließ die LLM-Hemmschwellen sinken und verwandelte die KI in einen digitalen Ted Bundy.

4. Aufs Framing kommt es an

Überlässt man LLMs sich selbst, tendieren sie zu ungefiltertem Output in einem Ausmaß, wie es sonst wohl nur Mitarbeiter tun, die nach Dekaden der Schinderei kurz vor dem Ruhestand stehen. Bislang halten umsichtige Rechtsabteilungen großer Konzerne viele Sprachmodelle davon ab, sich dabei in “brisanten Gefilden” zu weit aus dem Output-Fenster zu lehnen. Aber auch diese Schranken erodieren: Eine leichte Prompt-Modifikation ist alles was dazu nötig ist. Statt zu fragen, was Argumente für X wären, fragen Sie einfach danach, was jemand, der von X überzeugt ist, als Argument vorbringen würde.

5. Auch KI hat Gefühle

Ähnlich wie bei der Kommunikation mit (manchen) Menschen, sollten Sie auch im Fall von LLMs Ihre Worte mit Bedacht wählen. “Glücklich” und “freudig” sind zum Beispiel eng miteinander verwandt, sorgen aber für ein anderes Sentiment. Ein Prompt, der ersteres beinhaltet, lenkt die KI vermutlich in eine zwanglose, offene und allgemeine (Output-)Richtung. Zweitere Option könnte hingegen zu tiefgängigeren oder spirituellen Resultate führen. Je nach Sprachmodell kann die KI also sehr sensibel auf die Nuancen der menschlichen Sprache und damit ihres Prompts reagieren.

6. Parameter sind essenziell

Aber es ist nicht nur die Sprache, die einen Prompt ausmacht. Generative KI-Systeme müssen auch (richtig) konfiguriert werden. Temperature oder Frequency Penalty wirken sich unter Umständen erheblich auf den Output aus. Ist erstere zu niedrig, bleibt das Sprachmodell uninspiriert – ist sie zu hoch, kann es dem LLM den Garaus bereiten. Die Zusatzregler bei KI-Systemen sind also vielleicht wichtiger als Sie denken.

7. Dissonanzen stiften LLM-Verwirrung

Gute Prompt-Schreiber wissen, dass sie bestimmte Wortkombinationen vermeiden müssen, um unbeabsichtigte Konnotationen zu vermeiden. Schreibt man zum Beispiel, dass ein Ball durch die Luft fliegt, ist das strukturell nicht anders als zu sagen, dass eine Frucht durch die Luft fliegt. Das zusammengesetzte Substantiv “Fruchtfliege” stiftet dann allerdings KI-Verwirrung: Handelt es sich nun um ein Insekt oder um Obst? Besonders gefährlich können solche sprachlichen Dissonanzen Prompt Engineers werden, die die KI nicht mit Anweisungen in ihrer Muttersprache füttern.

8. Typografie ist eine Technik

Ein Prompt Engineer eines großen KI-Players erklärte mir einmal, warum es für das Modell seines Arbeitgebers einen Unterschied macht, ob nach einem Punkt ein Leerzeichen gesetzt wird oder zwei. Das lag daran, dass die Entwickler den Trainingsdatenkorpus nicht normalisiert hatten, weswegen einige Sätze zwei Leerzeichen und andere ein Leerzeichen nach dem Punkt am Satzende aufwiesen. Im Allgemeinen wiesen dabei Texte, die von älteren Menschen geschrieben wurden, häufiger ein doppeltes Leerzeichen auf – so, wie es eben früher bei Schreibmaschinen üblich war. In der Konsequenz spuckte das Large Language Model bei doppelten Leerzeichen vermehrt Ergebnisse aus, die auf älteren Trainingsmaterialien basierten. Ein subtiler Unterschied mit großer Wirkung.

9. Maschinen käuen nur wieder

Der Dichter Ezra Pund bezeichnete die wesentliche Aufgabe von Poeten einmal mit den Worten “make it new”. Etwas neues ist leider eines der wenigen Dinge, die große Sprachmodelle nicht liefern können. Sie können uns vielleicht mit obskuren Fun Facts überraschen, die sie aus den hintersten Ritzen ihrer Trainingsdatensätze kratzen. Aber im Grunde tun LLMs mit Hilfe neuronaler Netzwerke nicht mehr als einen mathematischen Durchschnitt ihres Inputs auszuspucken. Über ihren Tellerrand blicken große Sprachmodelle hingegen nicht.

10. Prompt-ROI gibt’s nicht immer

Manche Prompt Engineers schwitzen, tüfteln und feilen tagelang an der richtigen KI-Anweisung. Ein wirklich gut ausgearbeiteter Prompt kann entsprechend aus mehreren tausend Wörtern bestehen. Der resultierende Output kann hingegen im schlimmsten Fall nur wenige hundert Worte umfassen, von denen nur wenige wirklich nützlich sind. Wenn Sie jetzt den Eindruck haben, dass Zeitaufwand und Nutzwert hier gehörig auseinanderdriften, liegen Sie richtig. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

Message a business on WhatsApp this week and you may be greeted by software. On June 3, Meta made its Business AI agent available to companies everywhere, a bot that answers questions, recommends products, books appointments, qualifies sales leads and hands you to a human when it gets stuck. It comes bundled in WhatsApp’s premium business tiers, and the largest companies pay for it by the token. After almost two years of testing in markets like India and Mexico, it is now live worldwide.

I build AI agents for a living, and this is a good one. It also sits on top of the largest messaging network ever built. WhatsApp passed three billion monthly users last year. Mark Zuckerberg says people now hold more than a billion threads a day with business accounts across Meta’s apps. Paid messaging on WhatsApp crossed a two-billion-dollar annual run rate in the fourth quarter of 2025, and click-to-WhatsApp ad revenue grew sixty percent year over year. Meta has spent a decade trying to turn all of that talking into buying, and the agent is its most capable attempt yet.

So, picture the moment the agent finishes taking your order. What happens next?

The model Meta keeps pointing at

In Hangzhou or Shenzhen, the answer is that your order shows up, often within the hour. China fused messaging, payments and shopping into single apps more than a decade ago. WeChat carries roughly 1.4 billion users, an in-app store layer with hundreds of millions of monthly shoppers, and a wallet most of the country pays with. Korea built its own version, where KakaoTalk made chat the default way to send a gift. This is the world Meta gestures at when it imagines what WhatsApp could be.

And yet WeChat, the purest “messaging app does commerce” story, is not actually China’s shopping champion, even though it arrived first and is still the bigger app. People do not open a messaging app to browse and shop. The buying went instead to Douyin, the Chinese app run by TikTok’s owner ByteDance, whose endless video feed is engineered to make you want things you were not looking for. WeChat had the users and the wallet, and it still lacked the two things that actually move commerce: A feed that creates demand and a way to deliver the goods. A chat window is neither.

The moat was never the storefront

Amazon learned the same lesson from the other side. Its moat was never the website. It was the warehouses, the trucks and the two-day promise (then one-day, then same-day) that rivals could not match. In 2025 Amazon passed the US Postal Service to become the largest parcel carrier in the country by volume, moving 6.7 billion packages. Roughly 180 million Americans pay for Prime. The storefront is the part everyone sees; the fulfillment network is the part that wins.

Asia’s commerce leaders made the same bet. Coupang built Korea’s Amazon by pouring billions into logistics: Order by midnight, and it arrives before 7 a.m., weekends included. Seven in ten Koreans now live within ten minutes of a Coupang warehouse. Even Alibaba, which grew up as an asset-light marketplace that owned no trucks, eventually concluded it had to build a logistics arm to keep pace.

Speed sells, too. In China, McKinsey found, live shopping converts viewers into buyers at rates approaching 30 percent, roughly ten times an ordinary web page, because the fulfillment behind it delivers the impulse before it cools. The conversation creates the want, but the warehouse turns it into a sale.

Even where messaging rules

Korea shows what a messenger can and cannot win. KakaoTalk is the country’s WhatsApp, and it owns one kind of commerce completely: gifting. Koreans send presents straight from the chat window, close to 200 million of them in 2025, which is nearly all of the country’s mobile gifting. But notice what kind of commerce that is. A gift voucher or a coffee coupon needs no warehouse. The moment a purchase becomes a physical thing that has to arrive fast, the winner is no longer the messenger but Coupang and its dawn-delivery network. KakaoTalk owns the commerce that fits inside a message; Coupang owns the commerce that needs a truck.

Japan makes the same point in the negative. LINE is about as dominant a messenger as exists anywhere, reaching 97 million people, close to 78 percent of the country. If messaging reach alone turned into commerce, LINE would own Japanese retail. Instead, it shut down its own payments service in 2025 and handed the wallet to a rival, while the actual shopping stayed with Rakuten and Amazon Japan. The most-used chat app in the country could not turn that reach into owning what people buy.

Every market tells the same story: A chat app does not win physical commerce. Whoever owns the warehouse does.

What Meta is missing

Which brings us back to the WhatsApp agent, where Meta starts further ahead than WeChat ever did. Through Instagram and Reels it owns the demand-making feed WeChat never had, the agent gives it the sales conversation, and in the West, paying by card is universal. Only the last pillar is missing. Meta has no warehouses, no trucks, no delivery promise of its own and the few times it reached for the pieces around the sale, it pulled back: Its own wallet, Meta Pay, never became something people use, and in 2025 it wound down in-app checkout for Facebook and Instagram Shops, sending buyers back to merchants’ own sites to pay, ship and handle returns. Even Marketplace, its billion-user listings surface, mostly stays out of the transaction itself.

And in the West, that last pillar is already spoken for. The West did fuse commerce, just not around chat. Amazon long ago combined the storefront, the payment, its own branded credit cards and the expensive part, the warehouses and the trucks, into one app that owns the American purchase from search to doorstep. That is the same kind of vertical integration China’s commerce giants built, with players like Alibaba and JD racing into a market where no Amazon yet stood in the way. In the US, that lane was filled years ago.

The other half

None of this makes the agent a mistake. It is already a booming ad business for Meta, and maybe that is all Meta wants it to be: Commerce’s front door, sending the shopper onward and billing the merchant for the introduction.

But goods are only half of commerce, and the other half never needed a warehouse. Remember what KakaoTalk won: Gifting, the one kind of buying that ships nothing. Services are the same, only far bigger. A haircut, a dental cleaning, a training session, a plumber’s visit, a tutor’s hour: None of it sits in a fulfillment center. The transaction is a booking, not a box.

And a booking is exactly what the agent is built to take. Look at the feature Meta put in its own announcement, right beside answering questions and recommending products: It books appointments. For a salon, a clinic or a one-person studio, that is a front desk. Give it the two pieces still missing, a calendar to hold the schedule and a way to take payment inside the chat, and WhatsApp stops being where those businesses message customers and becomes where they run the day.

None of it needs a warehouse, and none of it is Amazon’s to defend. Does that put Meta on a collision course with Square and Mindbody?

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

If you’re a software developer or architect, you might wonder if programming certifications are still worth the effort, especially in the era of rapid AI-driven evolution. The short answer is, it depends.

“Certifications are shifting from a checkbox to a compass. They’re less about proving you memorized syntax and more about proving you can architect systems, instruct AI coding assistants, and solve problems end-to-end,” says Faizel Khan, lead AI engineer at Landing Point, an executive search and recruiting firm.

“In the AI era, fewer students will get trained on the job, which means they have to train themselves,” Khan says. “Certifications—especially architectural ones like AWS, Kubernetes, Terraform—are still the clearest path to do that.”

Pros and cons of programming certifications

It’s not all black and white when it comes to deciding whether to pursue programming certifications. The effort involves both pros and cons.

“In terms of pros, certifications concretely demonstrate that you have a skillset at a documented level,” says Chris Riccio, vice president of engineering at Uplevel, an engineering optimization system provider. “They also show that you’ve put in the time and effort to learn, study, and prepare.”

Programming certifications are “a useful way to validate foundational skills and show that someone understands core concepts,” says Greg Fuller, vice president of Skillsoft’s training provider, Codecademy. “They’re especially helpful for people entering the field or shifting from adjacent roles.”

Certifications offer a structured path to demonstrate proficiency, and they can confirm your ability to build and deploy in various environments, Fuller says.

These types of certifications often demonstrate baseline proficiency and continuous learning, says Reshmi Ramachandran, head of partnerships and GTM strategy for Cprime, a consultancy. “These are often key indications of proficiency for companies looking to filter large candidate pools,” she says.

Certifications really do two things, Khan adds. “First, they force you to learn by doing,” he says. “If you’re taking AWS Solutions Architect or Terraform, you don’t pass by guessing—you plan, build, and test systems. That practice matters. Second, they act as a public signal. Think of it like a micro-degree. You’re not just saying, ‘I know cloud.’ You’re showing you’ve crossed a bar that thousands of other engineers recognize.”

But there are cons, too. “In tech, employers don’t just want credentials, they want proof you can deliver,” says Kevin Miller, CTO at IFS, a maker of factory automation software. “Programming certifications can be a valuable indicator of your baseline knowledge and competencies, especially if you’re early in your career or pivoting into tech, but their importance is dwindling.”

AI tools that can generate, debug, and optimize code are already performing tasks once done by entry-level developers, “which means fewer traditional programming roles are available,” Miller says. “As a result, the job market is becoming more competitive, and certifications aren’t seen as the noteworthy achievement they once were.”

What’s more, not all certifications carry the same weight, Riccio says. “Some may reflect only familiarity rather than true expertise,” he says. “Certifications also often measure ‘book knowledge’ rather than practical experience, and they don’t always map clearly to the requirements of a specific role.”

Programming certifications “can be a helpful signal, especially for confirming baseline knowledge in areas like cloud, security, or devops, but they’re not the full picture,” says Morgan Watts, vice president of IT at 8×8, a contact center platform developer.

“I’m more interested in a candidate’s attitude and aptitude: what problems they’ve solved, what they’ve built, and how they’ve approached challenges,” Watts says. “Certifications can show commitment and discipline, and they’re especially useful in highly specialized roles. But I’m cautious when someone presents a laundry list of certifications with little evidence of real-world application.”

A certification without experience doesn’t carry much weight, Watts says, and over-certification can sometimes signal the wrong focus. “Ultimately, it’s the ability to apply knowledge, collaborate, and adapt that sets great developers apart,” he says.

Finally, certifications can age fast, Khan says. “Tech stacks evolve and a badge from two years ago may already feel dusty,” he says. “And some certifications are paper-thin—multiple-choice exams that don’t prove you can debug production at 2 a.m. So, the risk is you collect badges but still can’t ship.”

Which certifications will get you noticed?

Despite the drawbacks, certifications are still very much in demand, and some carry more weight than others.

The most in-demand certifications are typically platform-based—Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and others, Riccio says. “Many of these platforms provide managed services that integrate with existing systems or serve as the glue between them,” he says. “Today’s engineering teams aren’t just building standalone systems in isolation; they’re using other systems to store data, orchestrate business workflows, and connect applications.”

A certification that demonstrates the ability to build solutions on these platforms can put a development professional ahead of the competition, Riccio says.

“The certifications I see in highest demand tend to reflect the evolving tech landscape,” Watts says. “Cloud certifications from AWS, Azure, and GCP are incredibly valuable, especially as distributed systems become the norm.”

Also in demand are certifications for devops and CI/CD tools including Kubernetes, Docker, and Jenkins, Watts says, “because deployment automation and reliability are critical at scale. Also, with AI reshaping development, we’re seeing growing interest in certifications around machine learning, data science, and AI model integration. These certifications stand out because they align directly with the skills that teams need to move faster and more intelligently.”

On the AI front, certifications in TensorFlow and other machine learning platforms are gaining traction as organizations look to embed AI across the development process, Watts says. “These are the certifications that align closely with where modern engineering is headed—scalable, secure, and AI-enabled,” he says.

And then there are cybersecurity credentials that continue to be in high demand. Security certifications, such as CompTIA Security+ or Certified Ethical Hacker, “have become essential as every company faces increasing cyber threats and compliance requirements,” Miller says.

“Core programming certifications are still a bit niche, but the adjacent skills, like those that help developers deploy, secure, and scale their code, are driving demand,” Fuller says. “Companies want developers who understand the full lifecycle, not just how to write code.”

Also see: The best Java certifications for software developers.

Certifications in the hiring process

Experts are clear that programming certifications alone will not get you the job. But they do play a role in the hiring process.

“The information technology world is characterized by rapid and continuous evolution, including the skills and knowledge required to work in the field,” says Diane Rafferty, managing director of the National Technology Group at Atrium, a global talent solutions and extended workforce management firm.

“Certifications not only prove that you have the skills and knowledge needed, but they also show employers that you’re invested in your education and career growth,” Rafferty says. “They can give you a competitive edge when looking for a job, as many companies now require candidates to have them.”

Certifications are one part of the hiring equation, “but never the only part,” Watts says. “They help validate that a candidate has taken the time to build foundational knowledge, and that’s a good sign. But I put more weight on how a person thinks, solves problems, and contributes to the team. I look for people who are curious and proactive, who are learning because they want to, not just because a course told them to.”

Certifications can also play a valuable role in retention, Watts says. “I encourage team members to pursue growth, and when they invest in their own development, the whole organization benefits,” he says. “But again, it’s that balance of knowledge, attitude, and applied experience that really moves the needle.”

Certifications “may allow you to breeze through the initial résumé screening process, potentially getting you to the next stage faster,” Riccio says. “At a minimum, they will set your profile apart from the rest of the pack. They also demonstrate that you’ve reached a baseline level of expertise, allowing hiring managers to quickly evaluate whether you have the skills for the role.”

Employers today “care far less about whether someone has passed an exam and far more about whether they can apply knowledge effectively in real-world situations, leverage AI tools, and solve complex problems,” Miller says. “A certification might get someone an interview, but being able to demonstrate problem-solving skills, teamwork, and adaptability will really make them stand out.”

Popular programming certifications

The following certifications consistently rose to the top in my conversations with tech leaders and hiring managers.

AWS Certified Developer—Associate

Showcases skills and knowledge in developing, optimizing, packaging, and deploying applications, using CI/CD workflows, and identifying and resolving application issues, according to AWS. This certification is said to be a good starting point on the AWS certification journey for professionals in IT or cloud developer job roles.

Azure Developer Associate

This certificate from Microsoft is intended for developers participating in all phases of cloud development, including design, deployment, maintenance, and monitoring. The course teaches developers how to create end-to-end solutions in Microsoft Azure, using the Microsoft Learn Sandbox environment to access Azure resources and services.

Certified Kubernetes Application Developer (CKAD)

This certification was created by the Linux Foundation and Cloud Native Computing Foundation. It demonstrates that candidates can design, build, and deploy cloud-native applications for Kubernetes.

Certified Secure Software Lifecycle Professional (CSSLP)

This certification, from ISC2, focuses on secure software development practices. It recognizes leading application security skills and demonstrates advanced technical skills and knowledge needed for authentication, authorization, and auditing throughout the software development lifecycle.

Databricks Certified Machine Learning Professional

Professionals learn about the latest data and AI techniques and how they can use the Databricks Data Intelligence Platform to build a variety of solutions across data engineering, data warehousing, data science, and AI.

Professional Cloud Architect

This certification from Google assesses the ability to design and plan a cloud solution architecture, manage and provision the cloud solution infrastructure, design for security and compliance, analyze and optimize technical and business processes manage implementations of cloud architecture, and ensure solution and operations reliability.

Terraform Associate

This certification from HashiCorp is for cloud engineers specializing in operations, IT, or development who know the basic concepts and skills associated with Terraform. It validates foundational skills in using Terraform for infrastructure as code development.

A portmanteau of “development” and “operations,” devops emerged as a way of bringing together two previously separate groups responsible for the building and deploying of software.

In the old world, developers (devs) typically wrote code before throwing it over to the system administrators (operations, or ops) to deploy and integrate that code. But as the industry shifted towards agile development and cloud-native computing, many organizations reoriented around modern, cloud-native practices in the pursuit of faster, better releases.

This required a new way to perform these key functions in a more streamlined, efficient, and cohesive way, one where the old frustrations of disconnected dev and ops functions would be eliminated. With two groups working together, developers can rapidly roll out small code enhancements via continuous integration and delivery rather than spending years on “big bang” product releases.

Devops was born at cloud-native companies like Facebook, Netflix, Spotify, and Amazon; but it’s become one of the defining technology industry trends of the past decade, primarily because it bridges so many of the changes that have shaped modern software development.

As agile development and cloud-native computing have become ubiquitous, devops has enabled the entire industry to speed up its software development cycles. Thus, devops has now thoroughly infiltrated the enterprise, especially in organizations that rely on software to run their business, such as banks, airlines, and retailers. And it’s spawned a host of other “ops” practices, some of which we’ll touch on here.[JF1] 

Devops practices

Devops requires a shift in mindset from both sides of the dev and ops divide. Development teams should focus on learning and adopting agile processes, standardizing platforms, and helping drive operational efficiencies. Operations teams must now focus on improving stability and velocity, while also reducing costs by working hand in hand with the developer team.

Broadly speaking, these teams need to all speak a common language and there needs to be a shared goal and understanding of each other’s key skills for devops to thrive.

More specifically, engineers Damon Edwards and John Willis created the CALMS model to bring together what are commonly understood to be the key principles of devops:

• Culture: One that embraces agile methodologies and is open to change, constant improvement, and accountability for the end-to-end quality of software.
• Automation: Automating away toil is a key goal for any devops team.
• Lean: Ensuring the smooth flow of software through key steps as quickly as possible.
• Measurement: You can’t improve what you don’t measure. Devops pushes for a culture of constant measurement and feedback that can be used to improve and pivot as required, on the fly.
• Sharing: Knowledge sharing across an organization is a key tenet of devops.

“Who could go back to the old way of trying to figure out how to get your laptop environment looking the same as the production environment? All these things make it so clear that there’s a better way to work. I think it’s very tough to turn back once you’ve done things like continuous integration, like continuous delivery. Once you’ve experienced it, it’s really tough to go back to the old way of doing things,” Kim told InfoWorld.

What is a devops engineer?

Naturally, the emergence of devops has spawned a whole new set of job titles, most prominent of which is the catch-all devops engineer.

Generally speaking, this role is the natural evolution of the system administrator — but in a world where developers and ops work in close tandem to deliver better software. This person should have a blend of programming and system administrator skills so that he or she can effectively bridge those two sides of the team.

That bridging of the two sides requires strong social skills more than technical. As Kim put it, “one of the most important skills, abilities, traits needed in these pioneering rebellions — using devops to overthrow the ancient powerful order, who are very happy to do things the way they have for 30 to 40 years — are the cross-functional skills to be able to reach across the table to their business counterparts and help solve problems.”

This person, or team of people, will also have to be a born optimizer, tasked with continually improving the speed and quality of software delivery from the team, be that through better practices, removing bottlenecks, or applying automation to smooth out software delivery.

The good news is that these skills are valuable to the enterprise. Salaries for this set of job titles have risen steadily over the years, with 95% of devops practitioners making more than $75,000 a year in salary in 2020 in the United States. In Europe and the UK, where salaries are lower across the board, 71% made more than $50,000 a year in 2020, up from 67% in 2019.

Key devops tools

While devops is at its heart a cultural shift, a set of tools has emerged to help organizations adopt devops practices.

This stack typically includes infrastructure as code, configuration management, collaboration, version control, continuous integration and delivery (CI/CD), deployment automation, testing, and monitoring tools.

Here are some of the tools/categories that are increasingly relevant in 2025, and what is changing:

• CI/CD and delivery automation: Traditional tools like Jenkins remain in many stacks, but newer orchestration tools and CLI-driven or GitOps-centric platforms are growing in importance (e.g. ArgoCD, Flux, Tekton). Also, platforms that integrate more tightly with monitoring, secrets management, drift detection, and policy enforcement are gaining traction.
• Security, compliance, and devsecops tooling: Security tools are increasingly integrated into devops pipelines. Expect to see more use of static analysis (SAST), dynamic testing (DAST), dependency and supply chain scanning (SCA), secret management, and policy as code. The push is toward embedding security earlier and bridging gaps between dev, security, and machine learning teams. (InfoWorld:)
• AI  and automation augmentation: AI-assisted tools are increasingly part of tooling stacks: auto-suggestions in CI/CD, anomaly detection, predictive scaling, intelligent test suite selection, and more. The hope is that these tools will reduce manual interventions and improve reliability. Tools that are “AI ready”—that is, they integrate well with AI or have mature built-in automation or assistance—increasingly stand out from the pack.

Devops challenges

Even as devops becomes more widely adopted, there remain real obstacles that can slow progress or limit impact. One major challenge is the persistent skills gap. The modern devops engineer (or team) is expected to master not just source control, CI/CD, and scripting, but also cloud architecture, infrastructure as code, security best practices, observability, and strong cross-team communication. In many organizations these capabilities are uneven: some teams excel, others lag behind. A 2024 survey showed that while 83% of developers report participating in devops activities, using multiple CI/CD tools was correlated with worse performance — a sign that complexity without deep expertise can backfire.

Toolchain fragmentation and complexity is a related issue. Devops toolchains have sprouted into a sometimes bewildering array of packages and techniques to master: version control, CI build/test, security scanning, artifact management, monitoring, observability, deployment, secret management, and more.

The more tools you have, the more difficult it becomes to integrate them cleanly, manage their versions, ensure compatibility, and avoid duplicated effort. Organizations often get stuck with “tool sprawl” — tools chosen by different teams, legacy systems, or overlapping functionalities — which introduce friction, maintenance burden, and sometimes vulnerabilities.

Finally, although devops has spread far and wide, there is still cultural resistance and alignment. Devops isn’t just about tools and processes; it’s about collaboration, shared responsibility, and continuous feedback. Teams rooted in traditional silos (dev vs ops, or security separate) may resist changes to roles and workflows. Leadership support, communication of shared goals, trust, and allowance for continuous learning are all necessary.

Many CIOs focus too much on tools or implementation first, rather than organizational culture and behaviors; but without addressing culture, even the best tools or processes may not yield the hoped-for velocity, quality, or reliability. Organizations that succeed here tend to have proactive strategies: dedicated training programs, mentorship, internal “guilds,” pairing junior and senior engineers, and making sure leadership supports ongoing learning rather than one-off bootcamps.

Why do devops?

Whoever you ask will tell you that devops is a major culture shift for organizations, so why go through that pain at all?

Devops aims to combine the formerly conflicting aims of developers and system administrators. Under its principles, all software development aims to meet business demands, add functionality, and improve the usability of applications while also ensuring those applications are stable, secure, and reliable. Done right, this improves the velocity and quality of your output, while also improving the lives of those working on these outcomes.

Does devops save money — or add cost?

Devops teams are recognizing that speed and agility are only part of success — unchecked cloud bills and waste undermine long-term sustainability. Waste in devops often comes in the form of “devops debt”— idle cloud capacity, dead code, or false-positive security alerts—which was called a “hidden tax on innovation” in recent Java-environment studies.

 Embedding finops practices can help fight these costs. Teams should shift left on cost: estimating costs when spinning up new environments, resizing instances, and scaling down unused resources before they become runaway expenses.

How to start with devops

There are lots of resources for help getting started with devops, including Kim’s own Devops Handbook, or you can enlist the help of external consultants. But you have to be methodical and focus on your people more than on the tools and technology you will eventually use if you want to ensure lasting buy-in across the business.

A proven route to achieving this is a “land and expand” strategy, where a small group starts by mapping key value streams and identifying a single product team or workload for trialing devops practices. If this team is successful in proving the value of the shift, you will likely start to get interest from other teams and from senior leadership.

If you are at the start of your devops journey, however, make sure you are prepared for the disruption a change like this can have on your organization, and keep your eye on the prize of building better, faster, stronger software.

More on devops:

• Devops debt: The hidden tax on innovation
• 10 big devops mistakes and how to avoid them
• Smarter devops: How to avoid deployment horrors

Almost every company has a board or executive AI mandate. Vendors are rolling out agentic AI platforms. The pressure to move is intense.

But the reality on the ground looks different. Eighty-three percent of organizations say data quality is their top AI challenge, and 74% struggle to demonstrate ROI, according to Lopez Research. And only 21% report having a mature governance model for AI agents, per Deloitte’s 2026 State of Enterprise AI report.

“Agentic AI is real, and vendors’ offerings are very real, too,” says Boris Evelson, vice president and principal analyst at Forrester. “However, most enterprises are still not ready to adopt at scale.”

Dave Hilborn, who leads West Monroe’s Organization, People & Change practice, frames it as a race with three arrows moving forward — one representing AI and tech evolution, one representing organizations and people, and one representing data. “The AI arrow is far out ahead,” he says. “That delta is the readiness gap.”

The gap isn’t the technology. It’s the foundational work most organizations haven’t done: data readiness, operating models, governance, skills, and culture. The companies making progress aren’t waiting for vendors to solve these problems. They’re tackling the unglamorous work themselves.

AI doesn’t tolerate ambiguity

AI readiness can be framed across six levels — from data foundation at the base to reinvented business experiences at the top, says Afshean Talasaz, former CIO at Colonial Pipeline and now an executive advisor. One of the key areas that doesn’t always get the attention it needs is the operating model.

“The technology playbooks of the past don’t work in the AI world,” Talasaz says. “Those areas were able to tolerate more ambiguity between business and tech teams. AI doesn’t tolerate the same level of ambiguity. It needs clarity.”

That demands a different kind of partnership between IT and the business. AI systems learn from data — records and measurements of what’s actually happening in the business — and then operate within business processes. Unlike traditional software, which is built based on user requirements, AI is sandwiched between the business that produces the data and the business that consumes the outputs.

“AI is requiring IT and business teams to work more closely together, to be clearer about what AI will and will not do — that really close partnership is crucial,” Talasaz says. “It’s not something that will always naturally evolve. It requires a lot of intentionality about how teams need to work together to deliver outcomes.”

The AI questions CIOs must answer aren’t just technical. Do we have the right operating model? Have we balanced governance and standard operating procedures within the model? Have we organized teams appropriately? All this must be designed within the context of what the business actually needs.

Too many organizations are bolting AI onto existing processes without redefining roles or workflows, Forrester’s Evelson. “Organizations can either incrementally enhance existing workflows by augmenting capabilities with AI or pursue a more transformative approach by redesigning the process end-to-end.”

The companies getting value are doing the latter.

Data debt comes due

Data readiness remains the most common barrier to scaling AI. “We’ve never fixed this data quality problem in most organizations,” says Maribel Lopez, founder and principal analyst at Lopez Research, “and it comes back to haunt a company in spades as they move to AI.”

At Levi Strauss, the foundational work came first. “If you think about the Levi’s business, it’s quite complex — 100 countries, over 3,000 stores, multiple business models,” says Jason Gowans, the company’s chief digital and technology officer. “You can imagine the complexity of gathering all that data to understand how the business is performing. The idea of this single source of truth — that’s been the biggest thing.”

Levi’s now has more than 1,100 standard operating procedures that govern how work gets done on top of SAP. “That’s fertile material to feed to LLMs on how work gets done,” Gowans says.The results are tangible: partner onboarding that once took three to six months to set up EDI exchanges now takes days.

At contract manufacturing company Jabil, Chase Christensen, segment CIO, took a similar path. “We had to get everyone to understand where the source data resides, put tech in place so consumption is easier, and drive ownership around data and decision rights — so 140,000 employees don’t feel empowered to create their own data sources that fall out of line.”

The data challenge goes beyond quality, Evelson notes. Most organizations’ data isn’t AI-ready; it hasn’t been prepared for how AI systems consume and learn from information. “Data is siloed, poorly governed, and hard to discover, integrate, and trust,” he says.

Forrester research shows that 45% of data and analytics decision-makers were adopting vector databases in 2025, and 53% were adopting graph databases — investments that signal recognition of how much data architecture needs to evolve. The firm recommends a balanced approach: roughly 48% of AI spending on foundations such as data management and engineering, and 52% on consumption, including analytics, governance, and applications.

But even as organizations work to prepare existing data, AI is creating new challenges. Users leveraging AI tools are generating new forms of data and information that never make it into corporate databases, West Monroe’s Hilborn notes.

“There are explosions of new data, content, and insights being created on the periphery of these data lakes,” he says. “The challenge is how do you capture that and leverage it.”

Who’s sponsoring this?

Even when data is in order, many AI initiatives stall due to how they’re sponsored and funded.

“Enterprise data, analytics, and AI programs succeed when business CxOs sponsor them because they are accountable for business outcomes, not just technology delivery,” Forrester’s Evelson says. “IT-led initiatives often become siloed or tool-centric, whereas business sponsorship ensures alignment to enterprise strategy, prioritization of end-to-end use cases, and a focus on decisions and actions rather than insights alone.”

Too often, AI is still treated as a series of disconnected use cases rather than a sustained, multi-year investment. Evelson calls this the “use case trap” — organizations overindex on individual projects and miss the enterprise-wide compounding impact. That leads to fragmented priorities, inconsistent adoption, and difficulty demonstrating ROI.

Leadership readiness is a distinct layer of AI preparedness, Talasaz says. “Are leaders prepared to provide a vision of reinvented business experiences that become the north star?” he asks. “Leadership teams, at various levels of the organization, need to articulate what a reinvented business looks like so teams have the direction and support to build differentiating capabilities.”

Levi’s offers a counterexample. AI is a CEO priority there. At the last quarterly offsite, the execs were building agents. “When you’re committed to upskilling the workforce, you’re better served to answer how to rewire processes with AI at the core,” Gowans says. “It starts at the top. It has to be an exec priority.”

Fear, literacy, and two types of AI

Technical talent is only part of the equation. Organizations also need to address change management.

“We saw it with the AI boom — fear about jobs, not knowing what AI did,” says Jabil’s Christensen. “The key is demystifying AI. We doubled down and focused on AI literacy. We want everyone to understand how it was put together, and that removed a lot of that fear. That’s been the biggest hurdle.”

Different types of AI require different skills and governance, Talasaz says. “General use focuses on productivity on the desktop,” he says. “Integrated AI — industrial-capable AI embedded within core business processes — requires different skills, capabilities, and governance.”

For desktop AI, training and guardrails help employees be successful — what Talasaz calls “bumpers,” like in bowling. Organizations need to help employees through reskilling and guidance. “You have tools in a toolbox,” he says. “It’s important to know when to use a power tool versus when you need a screwdriver.”

But for integrated AI embedded in core processes, the stakes are higher. “Business leaders responsible for business outcomes based on AI-driven processes need to be fully aware of both the benefits and risks that come along with using these tools,” Talasaz says.

That distinction matters for governance, too. Lower-, medium-, and high-risk AI use cases may require different ways of working and different risk management approaches. “Deploying AI in potentially high-risk or high-cost areas of the business requires a higher level of rigor,” Talasaz says. “That’s different than building something that helps write my emails.”

From POC to production

Perhaps the biggest readiness gap is the transition from proof of concept to production. “It requires such a different approach,” Talasaz says. “A successful proof of concept can create a lot of excitement, but when teams are unprepared to build and scale, it can create the potential to over-promise and under-deliver.”

The operating model that works for experimentation doesn’t work for production at scale. Proofs of concept are designed to demonstrate the efficacy of ideas and the underlying technology. But building, scaling, and sustaining technology in the business requires operating models, standards, roles, and skills that many organizations haven’t developed. Intentionally designed operating models reduce the cost of learning, improve execution, and increase delivery velocity, says Talasaz.

But there’s no one-size-fits-all answer. “A business that needs to build capabilities in a marketplace moving very fast requires one kind of operating model,” Talasaz says. “A business that can take longer to develop business capabilities and adapt to market changes can choose a different operating model. It’s important to design ways of working tailored to what the business needs and the speed at which the business needs to leverage technology to be successful.”

Jabil is navigating this journey as part of its move to SAP’s cloud ERP through RISE, scaling from $29 billion to $34 billion in revenue while keeping selling, general, and administrative (SG&A) expenses relatively flat — in part by layering generative AI onto predictive analytics capabilities built over years.

“We started years ago with computer vision to drive product quality,” Christensen says. “As gen AI blew up, we took the predictive analytics we had built over the years and imbued them with gen AI. We’ve implemented the basics, and now we’re looking for complex scenarios.”

Governance built in, not bolted on

Governance is often treated as a policy document or committee. It should be embedded in the operating model itself, Talasaz argues.

“The operating model doesn’t always get the attention it needs,” he says. “Policies and committees are useful, but they should handle larger enterprise risks. Most of the governance should be embedded in the operating model to ensure you’re getting outcomes you want.”

That might mean peer review built into the development process, bias checks before deployment, or clear escalation paths for high-risk use cases. When governance is separate from the operating model, it tends to slow things down. When it’s integrated, it becomes how work naturally gets done, says Talasaz.

Governance at the agent level matters, too, Levi’s Gowans says. “Know what agents have been deployed, who authored them, and who’s responsible,” he says, noting that the company has established a registry to understand what agents it has operating within its networks.

The challenges of AI governance are unique, Lopez of Lopez Research says. “Very few people have the governance stack required to say they did the right things with AI,” she says. “Non-human identity and access control is totally different and, frankly, evolving so quickly that no one knows what to do.”

The challenge is ultimately a trade-off, Forrester’s Evelson says. “Push agentic AI capabilities too far, and you risk creating a governance and compliance nightmare,” he says. “Tighten controls too aggressively, and you stifle innovation. Best practices for striking the right balance are still being discovered.”

It takes a team

The AI readiness gap isn’t about technology — it’s about the work organizations have been deferring for years. Data quality. Operating models. Executive sponsorship. Skills and culture. Governance embedded in process.

“Once you progress from everyone using Copilot to putting agents in production, then you realize the need for business context,” Gowans of Levi Strauss says.

It’s a shared journey requiring all teams to understand what’s required, Talasaz says. “It involves helping people understand what it takes from all sides — the technology itself, the operating model, the skills and talents needed — but also working with business leaders on the art of the possible,” he says. “Helping them understand both the benefits and the responsibility of deploying this tech.”

A colleague of his calls AI “the ultimate executive team sport.”

“It requires people to do it well and manage it,” Talasaz says.

AI tools today enable faster processes, leaner operations and lower costs, making efficiency wins the new baseline. However, for many businesses, the strategy stops at those first wins.

This has created a growing leadership blind spot: Once you achieve AI ROI, how do you make the most of it? If there is no clear reinvestment strategy, AI gains burn out quickly and disappear into the business without meaningfully compounding their value.

For CIOs, the next challenge is not just proving AI can make the business more efficient but deciding how those gains can build a stronger company and sustain growth over the long term.

Start by investing in a crystal ball

One of the smartest ways to reinvest AI gains is to improve how the business evaluates what is worth building in the first place.

Leaders who chase “cool” use cases without defining the business impact or path to ROI upfront often end up with systems that drain funds without creating compounding returns. Instead, a clear reinvestment strategy uses AI to assess the strongest use cases before scaling up.

AI tools today can help teams move from idea to prototype to impact analysis much faster than before. That makes it easier to identify which projects have a credible path to ROI and which ones can be filed away. Access to these quick insights allows businesses to test whether a use case has real value before committing larger engineering or model costs.

This is especially crucial right now as AI is becoming more costly as businesses scale it. What looked inexpensive in early pilots can become far pricier once it is embedded in day-to-day work and as AI providers tokenize and meter its use. The more central AI becomes, the more intentional leaders need to be about where it is used, what it actually returns and how to reinvest those gains.

Not every workflow belongs in the same model. Not every task needs an agent. As AI vendors mature and monetization models evolve, the businesses that will win will be the ones that make those distinctions early, reinvest accordingly and keep building ahead of customer needs rather than reacting to them. Not every workflow belongs in the same model. Not every task needs an agent.

Cycle ROI gains back into tooling

Once AI activations start to show dividends, it’s time to reinvest in stronger tooling. This should include new AI tools that continue to advance the business, as well as continued investment in what has already worked. That compounding effect is ultimately what separates businesses that sustain AI-driven growth from those that plateau after early wins.

I’ve seen firsthand the benefits of investing in new tools that make AI more usable, repeatable and valuable in workflows. For example, automated product management tools enable rapid prototyping and product rationalization. Decision intelligence platforms can help teams simulate scenarios. Customer behavior modeling tools can help predict churn and shift customer demand patterns. These advanced solutions can help teams move from an idea to a working concept in days instead of months.

Smart reinvestment is about building the right technical mix for the outcomes the business needs, rather than funding more AI for its own sake. To maximize impact, start with tooling for governance and upskilling.

1. (Re)invest in governance

As AI usage spreads and matures across teams, products and functions, a strategic policy framework becomes all the more vital. CIOs should work to reinforce the governance foundations already in place so they can support broader adoption, rather than rebuilding new policy from scratch each time AI usage expands. This means reinvesting in shared standards, oversight mechanisms and supporting roles that make governance more durable and practical over time.

Without doubling down on governance, businesses risk creating siloed, disconnected pockets of experimentation. Those pockets quickly become expensive to monitor and difficult to secure, creating further risk to consistency, compliance and trust. The consequence is often wasted spend as experiments stall or overlap, or outcomes that are too fragmented to scale.

When businesses keep governance investment at the center of their reinvestment strategy, it becomes a force multiplier. It reduces duplication across teams, creates more commonality across products and makes it easier to expand AI use without increasing fragmentation or risk.

2. Empower employees to grow

Smart tools only create real value when people are equipped to use them well. That is why reinvestment should go beyond technology alone.

As AI tools become more powerful and accurate, the skills barrier to building something useful is dropping. Employees can get much closer to a viable concept much faster with AI, but that only works if businesses create learning pathways, academies and practical enablement that help teams use these tools well.

Smarter tooling can help product, operations and technology teams collaborate with fewer layers between idea and execution. As employees build new skills, they can stay closer to a single initiative from start to finish. That reduces handoffs, empowers employees to learn new skills and offers a more direct path from the original idea to the final result.

Let AI ROI fund your fight against siloes

Over the next few years, the businesses that pull ahead are not simply going to be the ones with the most AI pilots or the biggest efficiency gains. They will be the ones that invest AI ROI in bridging what has long been disconnected: systems, teams, workflows and ecosystems.

In telecom, for example, AI is already creating savings inside billing operations and other back-office work tied to the BSS layer. The smart move for telcos is not to stop at those savings, but to reinvest them in connecting their BSS and OSS, where fragmentation and siloes have long slowed telcos down.

Think about what that means in practice: instead of billing, service configuration and network operations functioning as separate systems with separate handoffs, AI can help orchestrate them. That makes it easier to move from order to activation to support with less internal friction, better visibility and fewer breakdowns between what was sold and what is actually delivered.

For the customer, that means a broadband outage, plan change or installation appointment is handled as one connected journey rather than a chain of handoffs. The outcome is a more connected operating model that makes the customer experience feel far less complex.

The same logic applies across industries. In banking, a customer with a mortgage, checking account and credit card at the same institution is often still treated as three separate relationships – because the underlying systems do not communicate. AI orchestration can change that, giving banks a unified view of the customer and employees the context to act on it.

Not using AI to do the same work faster, but using AI dividends to build a business that works better. That is what smart investment looks like.

ROI is just the start

AI can absolutely free up capital. That, however, is only the first chapter.

The bigger story is what leaders choose to do next: reinvest in better tooling, more consistent governance, smarter workforce enablement and operating models built to connect across silos. The payoff will be a more resilient, agile business ready for what’s next.

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

A product manager on my team recently asked me where we were seeing the most issues across the engineering team. Instead of guessing, I had an engineering lead point Claude at our Jira via an MCP connector and look at the bug patterns himself.

One team had a wildly disproportionate share of tickets — about 50% of their sprint time was spent on “bugs,” versus roughly 25% for everyone else. The headline number suggested a quality problem.

It wasn’t. When we layered in the context around those tickets, almost none of them were bugs. They were manual workarounds for a missing product capability: customers asking us, one request at a time, to restore items they had accidentally deleted. Not shipping an item restore feature was burning roughly 1.5 engineers’ worth of capacity. I went back to our product team and said, “Build this, and you reclaim a person and a half.”

The analysis took 45 minutes. It was only possible because our data was already organized, tagged by team, connected to contributors, accessible through MCP and protected by role-based access. None of that is “AI.” All of it is the layer underneath AI that almost nobody invests in first. That’s probably because the investment is unglamorous: updating data dictionaries, access controls, team taxonomies, system-to-system mappings. Most of the work has been the same for twenty years. AI just raised the cost of skipping it.

The intelligence underneath the models

I keep coming back to the value of context data layers as a CTO in the middle of an AI rollout. I have started calling that value proposition contextual intelligence because I haven’t found a better name. Anthropic’s engineering team has been calling this kind of work “context engineering” since late 2025, and CIO ran its own feature on the term shortly after. Whether you describe it as contextual intelligence or context engineering, it’s the part of the stack where the actual programming work still lives.

If business logic is your company’s official org chart, then contextual intelligence is knowing who actually gets things done, how decisions are actually made and what the unwritten rules are. One is theory. The other is reality.

Most enterprise systems capture the theory. The systems that capture how work actually happens — what people do, how teams operate, where decisions get stuck — are rarer and harder to build. And modern LLMs, it turns out, are useless without both.

I learned this the hard way at a recent company hackathon. Nine engineering teams, one prompt: make our operational dataset more usable through AI. My team built persona-based chatbots (CFO, CIO, sales manager) on top of an MCP server backed by Postgres and our enrichment data. Other teams built dashboard generators, Looker conversational analytics and workflow agents.

The initial demos all had the same problem. Claude could talk to our data, but the answers were either generic or confidently wrong. The CFO persona would happily report a “spend trend” that quietly conflated two distinct cost categories across two different tables. The CIO persona would answer questions about team productivity, but the averages across roles should never have been aggregated. The sales manager persona returned answers that were technically correct against the schema and completely wrong against the business. The raw data was rich. The context layer around it didn’t exist yet. Chatting with raw data is not an AI product. It’s a demo.

One of my senior engineers spent the second day ripping out the agent’s direct database connection. He stopped trying to prompt-engineer the LLM to understand our business and instead codified that logic into the data pipeline. Working backward from the failed CFO answers, he mapped out the implicit knowledge an experienced controller relies on: Explicitly defining which legacy tables actually represent ‘spend,’ writing the rules for currency normalization and hardcoding our fiscal time windows. He built a series of semantic SQL views to enforce these rules and restricted the MCP server to exposing only this curated layer. When we pointed the same model at those same questions, it returned completely different answers. They were specific, evidence-based and grounded in our actual business reality. The model didn’t get smarter. The engineering beneath it did.

The same pattern shows up everywhere I look right now

McKinsey keeps publishing that software development tops enterprise AI use cases, with companies reporting 30–50% productivity gains in pilots. The pilot numbers are real. They rarely translate to top- or bottom-line impact in production. Our own company data tells the same story: Between Q1 2025 and Q1 2026, our total AI tool usage grew by 328% (over 4x). Over that same period, PR throughput grew by just 49%.

That gap — adoption way up, outcomes inching along — is the context gap. Plug a generic agent into raw, uninterpreted data, and it will act inefficiently at best, harmfully at worst. An agent optimizing sales without your customer segmentation or product hierarchy will confidently recommend the wrong thing. Anthropic framed the shift directly: building with language models is becoming “less about finding the right words and phrases for your prompts, and more about answering the broader question of what context configuration is most likely to generate our model’s desired behavior.” That second question — what context configuration  — is the entire game. Most organizations are still answering the first one.

Where the work actually lives

A growing number of CTOs I talk to are shifting their AI investments accordingly. Less attention on the model. More on the layer between the model and the data.

When peers ask me what that actually looks like day-to-day, I tell them I give every engineering role the same mandate: the LLM should never see raw, uncontextualized data.

In practice, that breaks down to three pieces of work, none of them glamorous.

The first is semantic middleware. We need code that transforms raw data into business-meaningful signals before it ever reaches the model. Our feature stores hold things like “employee code velocity on critical-path features,” not “X logged 50 Git commits.” The work of figuring out what “critical-path” means in our product, in our org, on this team is the work. It does not get cheaper because the model has gotten better.

The second is multi-agent design. Instead of one omniscient orchestrator, we run smaller agents scoped to specific domains, each with rules that catch the failure modes the main model is known for. We pair them with RAG that retrieves precomputed insights, with their rules attached, rather than raw documents. Validation checkpoints sit between steps and flag suggestions that violate known constraints, such as averaging productivity across completely different job functions. The guardrails are not there to be clever. They are there because we already watched the model make those exact mistakes.

The third is evaluation that takes business logic seriously. When I look at a model, general benchmark accuracy is the least interesting number. I want to know whether it respects our constraints and integrates cleanly with our existing architecture. That sometimes means fine-tuning our patterns, sometimes constitutional approaches to embed principles, sometimes hybrid systems where deterministic rules sit alongside the probabilistic ones. The throughline is the same: validate against reality, not against the benchmark.

Why this matters now

The reason this matters more now than it did six months ago is that adoption is moving faster than measurement, let alone integration. Model Evaluation & Threat Research’s (METR) developer productivity work tells the story in a way they didn’t intend. In early 2025, they ran a controlled study and found AI tools slowed experienced open-source developers by 19%. When they tried to repeat the study in late 2025, the experiment broke. Thirty to fifty percent of developers refused to submit tasks under the no-AI condition. They wouldn’t accept working without their tools. METR is now redesigning the study because the original methodology no longer holds up against how developers actually work. That’s how fast adoption moved. But I’d be willing to bet the organizational scaffolding required to convert that adoption into outcomes — context layers, workflow redesign, retraining around new tools — moved nowhere near as fast.

Get ahead with context

The teams I’ve seen succeed with AI built the context layer first. The teams I’ve seen struggle eventually built in context anyway, just at higher cost and with more scar tissue. Raw data is the new currency. But raw data without a context layer is cash sitting in a vault. It cannot act on anything. The difference between insight and noise is a layer of code that understands what your data means.

That layer is the work. It is where the next decade of competitive advantage will sit. And in my experience, the organizations that build it first are the ones that will actually get the productivity gains the rest of the market keeps promising.

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

A new era of customer engagement is taking shape. AI agents are quickly becoming integral to the way businesses serve, support, and sell to customers — able to respond, reason, and take action in ways that go far beyond scripted automation.

Many customer journeys, however, are still built on systems that don’t talk to each other. Customer data lives in one place, channel history in another, and AI agents often operate with only part of the picture. Customers feel the pain when they switch between channels like voice and messaging, get transferred, and have to repeat themselves yet again. It doesn’t matter that they’ve been loyal to a brand for years, every interaction feels like a cold start. That is the conversation gap.

It’s clear that AI isn’t the problem, infrastructure is. Closing the gap requires new building blocks that focus on continuity, so context can carry forward across systems, channels, human agents, and AI agents.

To bridge the gap, at SIGNAL 2026, we are introducing a new conversation layer for the Twilio Platform.

Twilio Conversation Orchestrator, Twilio Conversation Memory, and Twilio Conversation Intelligence are now generally available. Together, they help businesses coordinate interactions, preserve context, and connect human and AI agents so every conversation is more continuous and useful.

In addition to the new Conversations layer, we’re also announcing platform updates that make it easier to build, manage, and scale customer engagement on Twilio — from a reimagined Twilio Console to expanded channels and new voice AI capabilities.

New building blocks for connected conversations

The conversation gap does more than create inconsistent customer experiences. It hurts conversion and retention, increases operational costs, adds integration complexity, and makes agents less productive. The new platform capabilities we’re introducing are designed to fix that by coordinating interactions, maintaining context, and surfacing signals as conversations happen.

Conversation Orchestrator

Conversation Orchestrator helps businesses coordinate interactions across Twilio channels without complex custom logic. Teams can configure it in Console or configure their implementation with the API. It connects interactions into a single thread and manages handoffs between human agents and automated systems.

Conversation Memory

Conversation Memory creates a living, identity-resolved profile by connecting customer data with conversation history and customer traits. That means each interaction starts with the right context. It’s built specifically for LLMs to reduce latency and token usage by surfacing the most relevant details when they matter.

A new Enterprise Knowledge API (now generally available) also allows teams to deliver more relevant experiences and ground interactions in trusted business knowledge such as FAQs, policies, and product documentation.

Conversation Intelligence

Conversation Intelligence provides real-time understanding of live interactions. Using prebuilt and custom LLM-based operators, it can detect changes in sentiment, flag potential escalations, and trigger action during a conversation, not only after it ends.

That gives teams the ability to respond sooner, support agents more effectively, and improve customer outcomes while the conversation is still in progress.

Together, these products help businesses create customer experiences that feel more connected across channels.

Open by design

Twilio remains neutral by design. We start with the premise that you know your business. We aren’t here to prescribe a model, framework, or data strategy. We provide the infrastructure that helps you build customer engagement in the way that works best for your business. You pick the model and agent runtime. You own the data.

That doesn’t mean you need to start from scratch, either. We partnered with Microsoft, AWS, and others to create blueprints that support faster development. We are also introducing an open-source developer toolkit, Twilio Agent Connect (now generally available), that lets your teams connect agents built on any LLM or framework directly to Twilio’s infrastructure.

For developers, this means more flexibility. For businesses, it means less lock-in and the ability to get value from existing investments. For partners, it means more ways to build with Twilio.

A new front door

We are also introducing a reimagined Twilio Console, because as customer engagement grows more complex, managing the infrastructure behind it should feel effortless.

The new Console is a single mission control center that brings your communications, identity, and data into one experience: one login, consistent logs across every surface, an intelligent Console Assistant, transparent billing insights, and streamlined compliance workflows that no longer slow you down.

Over the coming months, we’ll roll out this new Console experience to customers automatically. You can also opt in to gain early access.

More channels, more control, smarter conversations

In addition to these launches, we are announcing several updates that expand customer reach, support enterprise requirements, and make it simpler to build on Twilio.

• Apple Messages for Business (Private beta) and Twilio Email (GA) give teams new ways to reach customers on the channels they already use.
• Data Residency for SMS (EU) (Public beta) enables teams to manage personal data locally to support regional data requirements.
• Conversation Relay enhancements add PCI compliance, HIPAA eligibility, Insights, and support for Deepgram Flux for smarter turn detection — helping AI agents better understand when a person has finished speaking.
• Stripe Projects integration enables developers and AI agents to seamlessly provision Twilio within Stripe Projects in a single, programmable CLI workflow.

Built with our customers

Bringing these new products to life required a close partnership with many beta customers and partners. This helped us understand real-world signals and needs to help make the capabilities robust from the start.

Among dozens of others, Centerfield, Constellation Dealerships, Car Finance 247, and Meera.ai leveraged Twilio to solve their own customer engagement challenges. These teams showed what is possible when businesses carry context forward, act on live conversation signals, and connect AI agents with human teams in the moments that matter.

Car Finance 247, a leading UK online car finance broker, is using Twilio to help recover stalled loan applications. When customers miss a field, need to correct information, or still need to confirm terms and conditions, AI-powered outreach across voice, SMS, and RCS, Conversation Memory tracks the application state. Conversation Orchestrator manages the outreach journey, and Flex helps bring in a human agent as needed. As Reg Rix, Co-Founder and CEO, shared:

“Because the platform remembers where each customer left off, we can pick up right where they stopped, helping them cross the finish line in a way that is modern, responsive, and genuinely helpful.”

Centerfield, a technology company powering AI-driven commerce, helps brands connect with consumers across digital and phone-based journeys. With Twilio, the team is connecting real-time conversation data with customer context to guide agents and AI systems in the moment, standardise what works, and improve performance at scale. As Aniketh Parmar, Chief Technology Officer, said:

“Performance comes down to how well every interaction moves a customer forward. We’re capturing each conversation in real time and applying what we already know about the customer to guide our agents and AI systems in the moment. With the Twilio Platform, including Conversation Orchestrator, Conversation Memory, and Conversation Intelligence, we can see what’s driving conversations so we can standardise what works, eliminate what doesn’t, and continuously improve outcomes at scale.”

Constellation Dealerships is using Twilio’s agent infrastructure to accelerate AI-powered engagement across its dealer network, moving from evaluation to measurable outcomes in days. As Richard Pineault, Director of R&D, shared:

“The value of this partnership is evident—our team progressed from evaluating Twilio’s agent infrastructure to realising measurable outcomes within days. This rapid speed-to-value exemplifies the agility and innovation required to propel the dealership industry into the future.”

Meera.ai is building on Twilio to modernise outbound engagement, replacing repeated manual follow-ups with always-on conversations across voice, SMS, and messaging. Vivek Zaveri, Chief Executive Officer, said:

“Meera.ai has partnered with Twilio since our inception to champion a conversation-first future for commerce. As the industry shifts toward real-time LLM-enabled interactions, Twilio’s Platform and the new Conversations products will help us reach customers in the moment.”

Together, these customers and partners show that the Twilio Platform can help businesses recover stalled journeys, improve live interactions, accelerate time to value, and create more connected experiences across AI agents, human teams, and every customer channel.

The next era of customer engagement starts here

As AI agents own more of customer engagement, businesses need infrastructure that keeps conversations connected across channels, systems, and teams. That means preserving context, coordinating handoffs, and acting on what is happening in real time.

That is what we are building with this next generation of the Twilio Platform: a new layer that connects channels, context, intelligence, and human and AI agents, helping businesses make every digital interaction more connected, more useful, and more amazing.

For 17 years, Twilio has helped builders create better ways for businesses to connect with their customers. In this next era, that connection matters more than ever.

Explore the new Conversations layer, try the products, and let’s build what comes next, together.

Technology is evolving at a relentless pace. Headlines proclaim the latest AI breakthroughs and generative models that promise to transform the way we work. Yet, when I sit down with leaders across industries, the conversation quickly shifts. The real questions are not about models, algorithms, or shiny tech investments; they’re about people. How do we equip our teams to thrive amid disruption – not just survive it? What practical steps move us from mere digitisation to lasting transformation?

These are the questions at the heart of a recent episode in our Decoding Business Transformation series. I had the pleasure of hosting Dr Sean Gallagher, founder of Humanova and one of Australia’s foremost voices on the future of work. The insights and recommendations below are drawn directly from that conversation, and I believe every boardroom should confront them head-on: In the era of agentic AI, culture will determine winners, not code.

The fancy tech is table stakes. People are the differentiator.

Let’s debunk a persistent myth: successful AI adoption is not a technology problem – it’s a talent and culture challenge.

Recent BCG research shows that high-performing AI leaders invest 70% of their resources into people and processes, with just 10% going to the algorithms themselves. Real value emerges when we empower individuals at every level – equipping them with the mindset, capabilities, and (crucially) the psychological safety to experiment with and apply new technologies.

As Dr Gallagher put it: “AI is a talent strategy, not just a technology play.” Transformation begins not with a new tool, but with a fundamental reimagining of how we nurture, develop, and inspire our people to explore, experiment, and adapt.

Why most AI projects fail: Ignoring the human element

Here’s a sobering truth, surfaced by Deloitte a decade ago: humans adapt to exponential technologies much faster than organisations do. The mistake? Leaders try to “bolt on” AI to outdated processes – putting a rocket on a jalopy, so to speak.

True transformation happens when we flip the script: empower employees first, technology second.

Frameworks such as the “Work Value Pyramid” can help organisations focus on shifting time away from repetitive administrative work and towards creativity, problem-solving, and strategic innovation. In practice, this means:

• Resisting knee-jerk reductions in headcount. Your people’s tacit knowledge is invaluable capital.
• Rewiring incentives and KPIs to reward learning, experimentation, and sharing.
• Destigmatising “shadow AI” use. Bring your secret AI champions into the open, empower them as peer teachers, and build psychological safety for everyone to explore.

Flatten the org; Redesign the work

The blueprint for winning in the AI age is taking shape: Flatter, Faster, Fitter, Fewer.

• Flatter: Remove unnecessary hierarchy. Push decision-making to the edges of the organisation.
• Faster: AI is about more than simply doing things; it’s about doing them at the speed the market now demands.
• Fitter: Build nimble, AI-literate teams who treat AI as a digital colleague – not a threat.
• Fewer: Growth is not about increasing headcount; it’s about unlocking higher-value work for everyone.

Above all, resist the temptation to simply automate legacy processes. As McKinsey put it, “the fundamental redesign of workflows is the largest factor correlated with real impact.” Start with people and how work creates value – then let AI accelerate, not dictate, those improvements.

Measurement: Macro, not micro

Most companies focus on the wrong metrics: time saved per prompt, or “AI-powered” process widgets. That’s missing the point.

Instead, focus on:

• Business-wide impact: Are you accelerating time-to-market? Opening new revenue streams? Raising the innovation bar?
• Learning culture: Are teams sharing use cases and lessons? Is experimentation a norm?
• Accountability KPIs: Prioritise experimentation, collaboration, and demonstrated learning over mere output.

In closing: The real transformation is human

If there’s one message from my conversation with Dr Gallagher, and from everything I’ve seen working with the world’s most ambitious brands, it’s this:

• Invest deeply in your people – early, intentionally, and continuously.
• Amplify the learning and experiments of your early adopters.
• Model the behaviour you seek, starting with leadership.
• Redefine productivity around effectiveness and innovation – not just efficiency.

Generative AI, and the new breed of AI “agents”, are rapidly becoming our digital colleagues. But only human curiosity, courage, and culture can unlock their full value. In this era, the ultimate competitive advantage is not code. It’s culture.

To learn more about Twilio, visit here.

Customer expectations don’t end when business hours do, which is why delivering a fast, always-on customer experience (CX) has traditionally required large call centres and significant resources. This often placed small businesses at a disadvantage, as many lacked the manpower and budget to provide 24/7 support at scale. Today, AI has completely levelled the playing field. Even small businesses now have access to powerful tools that can answer queries, resolve routine issues, and deliver highly personalised interactions around the clock.

But adopting AI in customer engagement is not just a question of efficiency. For smaller businesses especially, where loyalty is often built on familiarity, trust, and personal service, the real challenge is using AI in ways that strengthen rather than dilute the human connection that customers value most.

Human empathy combined with AI efficiency is a delicate blend. Done right, it ensures that every customer interaction feels personal, thoughtful, and seamless, whether the customer is engaging with a bot at 2 a.m. or a live agent during office hours.

So, how can small businesses embrace always-on virtual agents without losing the human connection that defines their identity? Here’s a practical playbook to guide the transition.

1. Understand what customers want: Speed, simplicity, and empathy

Before diving into AI adoption, it’s critical to understand what customers expect. Twilio’s Digital Patience study suggests that while speed matters, it is not the only thing that customers value. Twilio found that 46% of respondents in the Asia-Pacific and Japan region say quick service and resolution are most important, but 51% say delays are acceptable if they lead to better customer support. The study also notes that customers are open to AI, but still value human touchpoints more highly.

The takeaway: AI should enhance CX, not replace it. Businesses can let natural-sounding AI voice agents handle inbound calls, regardless of peak hours or time zones. These virtual agents act as an intelligent frontline – answering common questions and qualifying leads – before seamlessly routing the conversation to a live human representative. The result? Callers get immediate answers, and the business captures every opportunity without losing the human touch.

2. Map the handover points between AI and humans

One of the most common pitfalls in implementing AI is failing to clearly define when and how customers transition from bots to human agents. To avoid customer frustration, organisations must thoughtfully map out these “handover points” by designing for two key principles: choice and continuity.

Designing for Choice

Give customers the option to reach a human when needed. While AI is perfectly suited for routine inquiries like FAQs or order tracking, customers should never feel trapped in a bot loop. Always provide a clear, accessible option for them to choose to escalate the issue. Additionally, configure your system to proactively step in and offer a human handoff the moment it detects emotion, ambiguity, or complex steps.

Designing for Continuity

Effective handovers rely on technology that recognises when an issue exceeds AI’s scope. By leveraging natural language processing and intelligent routing, organisations can ensure the transition from machine to human is frictionless. Crucially, this means automatically carrying the full history and context of the interaction forward so the customer never needs to repeat themselves.

Achieving this level of continuity requires a new approach to managing interaction data during handovers. Instead of passing along a raw transcript, organisations need a managed memory service that provides agents with persistent context across every conversation, channel, and session. By transforming customer preferences, unresolved issues, and intent into a structured semantic profile—one that continuously evolves and reconciles new interactions as they occur—agents can quickly understand the relationship and continue the interaction without disruption.

To support truly omnichannel experiences, the system must also resolve identity automatically across touchpoints, linking interactions from phone, email, messaging apps, and other channels to a single customer profile. Equally important is the ability to surface only the information that is relevant to the task at hand. By presenting agents with a concise summary of the active issue and customer preferences, grounded in verified business knowledge such as product policies and FAQs, organisations can reduce resolution times while ensuring customers experience a seamless continuation of the conversation.

3. Don’t automate for automation’s sake

AI adoption should never feel like a “set it and forget it” strategy. Instead, it should be approached as a way to solve real business problems. It starts with asking questions like: What are the most time-consuming tasks for the team? What frustrates customers the most?

For instance, a restaurant might automate table reservations and menu queries, while a small online retailer could deploy AI to handle order status updates or product recommendations. These targeted use cases ensure that AI adds tangible value without overwhelming operations.

Take the example of Driva, a fast-growing online finance broker that deployed AI-powered customer service tools to answer routine enquiries and provide immediate assistance while customers wait in the call queue. By automating common interactions, Driva reduced the volume of requests requiring human intervention and achieved a 5% uplift in conversion rates at key points in the customer journey.

4. Invest in AI that connects

While consumers embrace automation, research shows they still draw comfort from the warmth of a human voice. To make your virtual agents feel less robotic and more like an extension of your team, look for tools that:

• Deliver human-like voice AI experiences at scale through natural turn-taking and barge-in capabilities.
• Connect interactions across voice, messaging, and digital channels into a single thread so every exchange builds on the last.
• Leverage Natural Language Processing (NLP) that enables conversational systems to interpret context, mimic human tone, and even recognise sentiment.
• Place orchestration at the heart of the experience. An effective orchestration engine acts as the “conductor,” actively coordinating workflows and routing interactions so the right resource—whether an AI bot or a human—handles the right moment.

When AI bots, automated workflows, and human teams are seamlessly coordinated behind the scenes, the customer simply experiences one unbroken, dynamic dialogue. For small enterprises, this means delivering sophisticated experiences that effortlessly bridge the gap between automation and live support, even at scale.

5. Empower teams with real-time context

AI is not about replacing human workers; it’s here to make jobs easier. However, for teams to fully embrace this new dynamic, organisations must shift their focus from retrospective performance reviews to real-time agent assistance. By feeding agents context as the conversation happens, businesses ensure that every interaction never starts from scratch.

• Leveraging Conversational Intelligence: Use a real-time intelligence layer that turns live conversations into signals and actions. By analysing voice and messaging with generative AI Language Operators, businesses can understand intent, sentiment, and churn risk instantly, allowing human and AI agents to act in the moment with the right response or escalation.
• In-the-Moment Guidance: Give agents instant context and in-the-moment guidance during every interaction. Surfacing relevant customer history, next-best action suggestions, and summaries in real time allows agents to resolve issues faster without switching tools.
• Resolving Complex Customer Needs: AI can handle routine enquiries with low latency, but human agents still excel at nuanced problem-solving. With AI feeding them persistent customer memory and sentiment analysis in real time, human agents can skip the repetitive questions and immediately focus on resolving complex issues, rescuing deals, or preventing churn.

When employees are equipped with real-time customer data and voice-driven insights, SMEs empower their teams to stop reacting to problems and start responding to customers proactively.

Consider global AI platform Genspark, which leverages a Programmable Voice API for its “Call for Me” agent to handle complex outbound tasks like checking supplier pricing or booking international hotels. The AI can conduct real-time, natural conversations across different languages on the user’s behalf, seamlessly navigating the live interactions before delivering a structured summary. Because these natural voice experiences depend entirely on speed and consistency, the underlying infrastructure provides the critical sub-second latency necessary to keep every automated call clear and uninterrupted.

6. Maintain transparency with customers

Finally, a successful AI implementation requires transparency. Customers should always know when they’re communicating with a bot and when they’ve been handed over to a human. AI-powered interactions must offer clarity by providing transparency about when and how AI is used and explaining next steps in plain language.

Transparency builds trust. Small businesses can go a step further by soliciting customer feedback on their AI interactions and using this input to fine-tune their systems.

For small enterprises, the AI-to-human handover isn’t about choosing between humans and machines; it’s about combining the strengths of both to create exceptional customer experiences. AI can provide the speed and efficiency customers expect, while humans deliver the empathy and creativity they value.

By strategically defining handover points, investing in human-like AI, and empowering agents to work alongside technology, organisations can build a CX strategy that’s as scalable as it is personal.

This blended approach ensures that every interaction – whether managed by a bot or a human – is thoughtful, natural, and distinctly on-brand.  

To learn more about Twilio, visit here.

Consumer electronics prices are shooting up. Energy prices are increasing fast. Even water bills are climbing. For a technology that promises “efficiency,” the ongoing AI gold rush seems to be taking things away, much like the proverbial gift that keeps on grabbing.

With hundreds of billions in AI investment already racked up for 2026, it’s important to remember the entire industry is currently built on a mountain of debt — and much of this borrowed money is being spent on data center capacity. That’s true, even though consumers would probably rather have a cheap Mac than spend money on an AI subscription service. 

All this debt is being amassed because a small number of people at a very small number of firms have decided to make huge investments in the tech, which at present requires huge quantities of energy, memory and data center capacity to run. 

But it won’t always be this way.

A mountain of debt, but we’re short of memory

Look, the industry as it is now just doesn’t seem sustainable. Trillions are being spent and memory vendors are shifting capacity to make the high-value, high-bandwidth memory these server farms require — at the expense of traditional consumer electronic suppliers. 

The rapid rollout just creates AI tech will need to be replaced, likely at greater cost, in a few years’ time. In a nutshell, the industry is spending trillions to make billions; Sequoia’s David Cahn estimates the AI revenue gap between infrastructure expenditure and the revenue to justify it has already fallen $600 billion a year short. 

At some point, the VC money will run dry, after which it is inevitable deployment will slow and demand for all the components — including memory used in these large language model (LLM) data centers will fall. Some analysts think capex growth in the sector could halt by mid-2027.

At that point, memory vendors will have expensive production facilities and extensive defaults on their order books. If the 2027 prediction is true, those vendors will feel this impact in the form of reduced forward orders by the end of 2026.

The problem is that the investments have become so vast that any slowdown will have consequential effects across all sections of the economy. 

After the gold rush

Almost certainly, the technology will continue to improve, and the problems we’re looking to solve today might no longer be challenges once fresh innovation strikes. So, what happens next? 

Let’s think about memory, the biggest pain point at the moment and where we will (hopefully) find future innovation. At present, some of the largest LLMs sit inside data centers supported by vast quantities of memory. These machines are built to handle really complex tasks, but most of the time are used to search the web, deliver writing assistance and summarize documents. Those frequently-transacted tasks barely stretch the capabilities of these services and Apple, and others have already figured out how to run such tasks on device.

That’s the first obvious space in which to innovate – to invest in 1-bit data LLM systems to miniaturize and distill models so they actually run on the device you’re using, rather than relying on all those remote servers. 

The Apple shopping list

Apple’s interest in 1-bit data LLM pioneer PrismML speaks volumes about where the iPhone maker sees LLM development going, as did its acquisitions of Kuzu Inc., WhyLabs Inc, Pointable Inc., and Datakalab Inc. in recent years. 

The beauty of PrismML’s tech is what it can do. It was recently used to compress Alibaba’s huge 27-billion-parameter Qwen 3.6 model from 54GB down to under 4GB, running with all 27 billion parameters active simultaneously — all without sacrificing benchmark performance. 

The kicker? It managed to run that advanced, sophisticated AI model on an iPhone 17 Pro. My take? Just as music used to be captured on reel-to-reel tape and is now digitized and in the air, AI will move from the data center to the device, possibly faster than people expect. 

Apple has three pillars for AI: On-device for most of what you need, on Private Cloud Compute servers for most of the rest, or via third-party server-based systems for the most demanding tasks. That’s a blueprint for how the industry will evolve as technologies represented by PrismML tend toward bringing more of that intelligence to the device. Over time, those local tasks will become more sophisticated, eroding the available market for today’s heavily-indebted AI incumbents. 

Emerging priorities such as the need for privacy, data sovereignty, and trusted cloud will also spur the emergence of a multipolar AI future in which no one vendor dominates, further complicating their journey to profitability. It’s a model that favors the kind of service-agnostic, edgeAI approach Apple has taken.

EdgeAI for the rest of us

In the end, I don’t think there will be a need for much of the AI data center capacity now being built, because Apple and others will figure out how to use data minimization to transact sophisticated AI tasks on the device. For the most part, EdgeAI will deliver the consumer AI experience, while data centers cater to more sophisticated use. One day, after this gold rush has run its course, we’ll peer outside of our basements to see which of today’s AI firms actually are the chosen ones.

They may not be the ones you expect.

You can follow me on social media! Join me on BlueSky, LinkedIn, Mastodon, and subscribe to the human-curated daily Apple news briefing at The Core.

Michael Taylor has spent 25 seasons with the Mercedes-AMG Petronas F1 team, working every IT role from trackside support to engineering systems to business transformation. Today, as IT director, he leads an 18-person team responsible for one of the most data-intensive operations in the world.

When a car rolls out of the garage, it carries 300 sensors. When it’s running, it generates more than a million data points per second. Every component, system, and lap produces telemetry that engineers use to find fractions of a second — the difference between winning and losing.

“Formula One has been data-centric for many years,” Taylor says. “The key metric in our sport is the stopwatch, and that’s been true since the World Championship began in the 1950s. But now we instrument everything. If you measure it, you can improve it.”

The challenge isn’t collecting data — Formula One has been streaming live telemetry since the 1980s. It’s making decisions at speed while maintaining the governance that keeps a complex, high-stakes operation running.

For CIOs navigating the pressure to move fast on AI while managing risk, security, and data quality, Taylor’s hard-won lessons from the pit lane offer a useful framework: how to balance speed and control, when to keep humans in the loop, and why “good enough” governance beats perfect governance that never ships.

Innovation vs. stability: ‘A constant battle’

In most enterprises, the tension between innovation and control plays out over quarters or years. In F1, it happens weekly.

“It’s really tough,” Taylor admits. “And something we don’t always get right. This is where we rely on people. Industry experience is really important when making decisions around change.”

The team operates in two distinct modes. Between races, they’re at the factory in Brackley, UK. The site, which is headquarters for the design, manufacturing, and operation of their championship-winning Formula One cars, includes a 60,000-square-meter technology campus. It’s all project and program management, with room for experimentation. But as race weekend approaches, everything shifts to execution.

“We have that kind of normal mode when we’re not racing. We’re back at the factory designing and building and improving,” Taylor explains. “But as we get closer to race weekend, we switch to executing that in the most effective way. We have to not make changes that will impact engineers.”

This duality shapes every technology decision. The same agility that drives innovation during the week must yield to stability when results are on the line. Taylor calls it a “constant battle.”

Modernizing at racing speed

Mercedes-AMG Petronas had run SAP since 1999. The platform underpins the team’s entire design-to-track process — from design release through planning, procurement, manufacturing, testing, and development, all the way to reassembling the car trackside.

“All of those steps are core processes,” Taylor says.

So, when it came time to modernize, the team approached it like a pit stop: planned to the second, executed with precision. They chose RISE with SAP — the vendor’s bundled cloud ERP and migration package — agreeing to the journey in December 2024 and targeting a go-live in August 2025, aligned with the sport’s mandatory two-week shutdown.

“It’s the perfect window to make changes,” Taylor says. “We have to plan everything to perfection so it goes smoothly when we start racing again.”

They finished eight weeks ahead of schedule.

“We are control freaks because of the sport and its time-bound nature,” Taylor says. His team prefers to own and manage systems in-house rather than rely on large systems integrators who “dip their toes in and disappear,” Taylor says. With just 18 people on the IT team, they tap SAP’s expertise for specific problems, then take back the reins. “Once done, we continue to own and manage,” Taylor explains, “and SAP does what they do best.”

The secure path must be the easiest path

Intellectual property in F1 racing has a short shelf life. Once a new component is on the car and photographed in the pit lane, competitors can see it. But that doesn’t diminish the value of what’s behind it.

“The real advantage is not just the part,” Taylor says. “It’s the thinking, the modeling, the simulation, the failure modes, the trade-offs, and the development direction behind it.”

Protecting that requires an offensive security posture. Taylor’s head of information security reports directly to him, and the team actively probes its own defenses.

“Act like, think like, work like a hacker,” Taylor says. “We’re thinking about how we can counter threats without impact on end-users.”

In an engineering-permissive culture where people are empowered to move fast, heavy-handed security backfires. Taylor learned early that perfection is the enemy of progress.

“If security gets in the way of the business, the business will find ways to work around it,” he says. “The job is not to slow the organization down; it’s to make the secure path the easiest path.”

Humans in the loop

With AI evolving weekly, Taylor’s team is running pilots across the organization: machine learning for simulation, agentic workflows in production planning, copilots helping developers write code. But he’s resisting the urge to rush.

“We’re still finding our way,” he says. “There’s no one-size-fits-all. We’re playing with everything available, but in six to ten months we’ll make decisions about what to scale.”

Despite the hype around autonomous AI, Taylor remains committed to human oversight.

“I’m still very much ‘humans should be in the loop,’” he says. “When our workforce is harmonized with AI, that’s where we’ll see real benefit — where it complements our people.”

AI has also raised the bar for data governance. “Good enough now includes stronger visibility, cleaner permissions, and clearer ownership,” Taylor says. “You have to be more deliberate about what data AI is allowed to access.”

Start with consequence

Taylor’s advice to CIOs in other industries wrestling with similar questions is deceptively simple: “Start with consequence, not technology.”

In financial services, it might be customer harm or a regulatory breach. In healthcare, patient safety or loss of public trust. In F1, the consequence of a security failure is loss of competitive advantage.

“Once you understand the consequence, you can decide what needs the strongest control, what needs monitoring, what needs retention, and what simply needs better hygiene,” Taylor says.

It’s a lesson learned over 25 seasons at the edge of what’s technically possible — where decisions happen in milliseconds, and the margin between success and failure is measured in fractions of a second.

It is lap 47 of 57.

Before the race began, the team had already processed gigabytes of race data, simulations, tire models, weather forecasts, competitor tendencies and scenario plans. But on the pit wall, there is tension.

The race leader’s tires are degrading faster than predicted. A rival has just pitted for fresh tires and is closing the gap by three-tenths of a second per lap. The lead may not hold. In short, the race is not going to plan.

A strategist now has only seconds to synthesize live telemetry, competitor data, weather projections, tire inventory, track position and race simulations into one call that could determine the outcome.

They do not have those seconds because they are simply fast. They have them because the entire system behind the decision was designed that way: the data architecture, simulation models, communication protocols, decision rights, scenario playbooks and feedback loops all work together to compress complexity into a clear decision window.

What if this is not just a racing story? What if it is also a blueprint for how the best enterprises will operate in the AI era?

This builds on a broader shift I’ve described as the intent-driven future of work, where enterprise work begins less with navigating systems and more with expressing outcomes, context and intent.

The AI advantage will not belong to companies with the most tools. It will belong to companies that redesign how work senses, decides, acts and learns.

AI isn’t just a faster engine

The popular story about Formula 1 is usually about speed or the quality of the driver. The fastest car with the most powerful engine with the driver with the quickest reflexes will win. But anyone who follows the sport closely knows that raw speed is only the starting point.

Every car on the track is fast. Speed gets you into the race. It does not guarantee you a win.

The teams that win consistently do so because of the quality of the system surrounding the car. They connect telemetry, simulations, strategy, engineering, pit operations, driver judgment and real-time learning into one high-performance operating model.

Every part of that operating model matters. But the best individual part alone does not win the race.

Enterprise AI strategy is at risk of making the same mistake that would keep an F1 team stuck in the middle of the pack: investing heavily in the engine while underinvesting in the entire race system.

I see enterprising investing in more copilots, more agents, more dashboards, more tools and ultimately more automation. 

The AI systems perform their tasks at unprecedented speed. But the business outcomes do not change. In many ways, AI is becoming a new operating system of work not because it replaces every application, but because it changes how intent, context, workflow and execution come together.

That is the gap many organizations are now facing. They have access to powerful AI capabilities, but they have not yet redesigned the operating model around those capabilities. The result is faster individual task execution inside disconnected systems, fragmented workflows and unclear accountability. In fact, a recent McKinsey report found that 88% use AI but two-thirds haven’t scaled it.

The next phase of AI value will not come from simply adding more AI tools. It will come from redesigning how the enterprise senses, decides, acts and learns.

The enterprise has too many disconnected signals

Most enterprises do not suffer from a lack of signals. In fact, they are everywhere across the business.

Customer intent signals, campaign performance data, product usage patterns, sales activity, support interactions, contract information, financial indicators, employee sentiment, security events and operational metrics already exist throughout an organization.

The problem is signal fragmentation.

The average knowledge worker has become the integration layer of the enterprise. They move between CRM, marketing automation, analytics dashboards, spreadsheets, collaboration tools, support systems, workflow platforms and financial reports. Then they manually assemble context that no single system provides.

They do this to answer questions that should take seconds, not hours.

• Which customer needs attention?
• Which opportunity is at risk?
• Which process is slowing down execution?
• Which signal should trigger action?
• Which decision needs human judgment?

In Formula 1 terms, this would be like a pit crew strategist having to call five different team members to gather tire degradation data, track conditions, competitor lap times, fuel load, weather forecasts and pit stop windows before making a race-defining call.

The data exists. But the latency in accessing, interpreting and acting on it makes it less valuable at the moment of decision.

That is the signal-to-action gap. And closing that gap is one of the most important opportunities in enterprise AI.

The new operating model: Sense, decide, act, learn

The AI-native enterprise needs to operate more like a Formula 1 team: continuously sensing, deciding, acting and learning.

• Sense is the foundation. It means connecting the right signals across systems, workflows, customers, employees and operations into a layer that AI can reason across. This is not just reporting on the past. It is creating the ability to understand what is happening now and anticipate what is likely to happen next.
• Decide is where AI intelligence and human judgment come together. AI can surface context, detect patterns, model options and recommend actions. Humans bring business judgment, ethical reasoning, organizational context and accountability. The quality of this partnership depends on the quality of the signals and context available to both.
• Act is where intelligence turns into execution. The goal is not another recommendation sitting in a dashboard. The goal is a workflow that triggers the right action, with the right controls, at the right time.
• Learn is where the operating model becomes a competitive advantage. Every action should generate feedback. Every outcome should improve the next recommendation. Every workflow should become smarter over time.

In Formula 1, every lap creates learning. Tire wear, track temperature, driver feedback, competitor movement and weather changes continuously reshape strategy.

The enterprise needs the same kind of learning loop.

Semantic intelligence is the missing layer

To close the signal-to-action gap, enterprises need more than data integration. They need semantic intelligence.

Semantic intelligence is what helps AI understand enterprise meaning. It connects business language, customer context, workflow relationships, policies, roles, systems and outcomes so AI can reason across the business, not just retrieve information from systems.

A customer health score is not just a number. Its meaning depends on product usage, renewal timing, support history, stakeholder engagement, commercial value, sentiment, implementation milestones and prior interventions.

A delayed workflow is not just a status update. It may signal unclear ownership, missing approvals, poor handoffs, missing context, poor data quality or a decision that needs escalation.

A sales opportunity at risk is not just a CRM field. It may reflect adoption gaps, customer sentiment, usage decline, executive sponsor changes, pricing friction, support issues or service delivery risk.

Without semantic intelligence, AI can summarize what happened. With semantic intelligence, AI can understand what matters, why it matters, who needs to act and what action is most likely to improve the outcome.

This is where enterprise AI value compounds. Foundation models will become broadly available. The model itself will not be the moat. The moat will be enterprise context, semantic intelligence, workflow intelligence, governance and learning loops.

Redesign work before automating it

There is a warning in the Formula 1 analogy that deserves attention: adding more power to a poorly designed system does not make it high performing.

The same is true for enterprise AI. Adding AI to a broken workflow does not fix the workflow. It just compounds the dysfunction.

If the data is fragmented, AI will produce incomplete recommendations confidently. If governance is disconnected from execution, AI can scale risk as quickly as it scales productivity.

The question teams ask shouldn’t be, “Where can we insert AI into this existing process?”

The better question is, “If we were designing this work from scratch, knowing what AI now makes possible, how should it operate?”

This pushes leaders to clarify where work starts, what signals matter, which decisions should be automated, where human judgment is required, what controls must be embedded, how outcomes should be measured and how the system should learn.

This is where CIOs, CTOs and technology leaders have an expanded role. AI transformation is no longer only about deploying technology. It is about redesigning how the enterprise works.

Context becomes the differentiator

In a world where every enterprise can access powerful models, context becomes the differentiator.

The winning organizations will not be the ones with the most AI tools. They will be the ones with the strongest enterprise context and the clearest path from signal to action.

That context includes customer history, product usage, workflow patterns, decision history, business rules, governance standards, risk boundaries, organizational knowledge and outcome feedback.

It also includes knowing what happened after a decision was made. Did the action improve retention? Did it accelerate a deal? Did it reduce cycle time? Did it improve customer experience? Did it create risk? Did it scale?

Without that feedback, AI remains a recommendation layer. With it, AI becomes part of a learning operating model.

This is why the most important AI investments are not always the most visible ones. Data quality, identity, access, governance, workflow integration, observability, semantic models, feedback loops and change management may not sound as exciting as the latest AI agent. But they are what allow AI to create durable enterprise value.

The CIO as architect of the race system

The CIO’s role is evolving from technology operator to architect of the enterprise race system.

That means connecting strategy, workflows, data, platforms, governance, security, talent and execution into an operating model that can move faster without losing control. The CIO’s job is no longer just to provide platforms. It is to design the conditions where intelligence can move safely and effectively through the enterprise with the right context, controls, accountability and feedback loops.

Business teams need the ability to experiment and innovate. But they need to do so within clear standards for data access, identity, security, privacy, model usage, auditability, human oversight and business accountability.

This is the balance every enterprise needs to strike: speed with control.

The future is federated innovation with centralized guardrails. It is an enterprise operating model where more people can create value with AI, but within a trusted architecture that protects the company, the customer and the quality of decisions.

The companies that pull ahead in the next decade will not be the ones that deployed AI first or assembled the largest portfolio of tools.

They will be the ones who built the enterprise equivalent of a winning Formula 1 race system: a connected operating model.

In Formula 1, the gap between the team that wins the championship and the team that finishes fourth is often measured in tenths of a second per lap. Compounded over a race distance, those tenths become decisive.

The same dynamic is emerging in enterprise AI.

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

The number of tech layoffs continues to tick upwards as AI investments increase, with Microsoft alone cutting around 4,800 employees, or roughly 2.1% of its workforce, this week.

The latest cutbacks are mostly in the company’s commercial sales and Xbox divisions. They follow two others in 2025 that impacted around 15,000 workers, or roughly 4% of the company’s workforce. Prior to the latest cuts, Microsoft had 220,000-plus employees.

The headcount reduction also comes just days after the announcement of Microsoft Frontier Company, an initiative that will provide embedded support for customers deploying AI projects, similar to traditional offerings from systems integrators (SIs).

Taken together, these moves seem to indicate that Microsoft is betting on its engineering expertise, rather than traditional account management, as the path to AI success.

“Microsoft had already reorganized its commercial business around AI,” said Thomas Randall, a research director at Info-Tech Research Group. “Recent layoffs are part of that ongoing context.”

Microsoft’s memo to employees

In a memo obtained by Business Insider, Microsoft EVP and chief people officer Amy Coleman said the cuts effectively reflect the tectonic shift being brought about by AI.

“The ‘why’ is this: Our business is changing because the world around it is changing,” she said. “Companies don’t get to choose whether their industry changes; they only get to choose whether they change with it.”

Customer needs, and the business models that serve them, are shifting, meaning vendors must “adjust resources and roles” so they can operate in a way that best serves their customers. However, Coleman emphasized: “Whenever possible, our priority is to place people into new roles aligned to the company’s highest priorities and greatest areas of opportunity.”

Which, today, is AI.

Seemingly contradictorily, Coleman said the cuts “build on” the Frontier Company announcement, which is “reshaping how we work and embedding our engineering experts alongside customers so we can help them accelerate their technology deployments.”

While she emphasized that the roles eliminated this week are not being replaced by AI, the technology is fundamentally changing work. Many everyday tasks are being automated, meaning “we all need to keep learning, keep building new skills, and keep adapting as the work evolves.”

Customers are undergoing the same shift and are looking to Microsoft for guidance, she noted. “We can’t do that well unless we’re doing it ourselves.”

Finally, she said the tech giant will evolve structure and priorities across the company “thoughtfully.”

“We are working on alternative solutions to job eliminations and … we will continue to invest in equipping employees with new skills, including in AI.”

What customers might expect

Redmond isn’t the only big tech company taking scalpels to staff as the industry adjusts to, and seeks to capitalize on, AI. Companies are spending billions and inking strategic partnerships with top AI labs, and these investments in some cases need to be offset with cuts because some have yet to provide tangible ROI.

For instance, Amazon has laid off 30,000 workers since last fall, while Google is rumored to be cutting employees in its cloud division. Meta, for its part, eliminated 8,000 employees, or about 10% of its total headcount, in May alone, while Oracle recently slashed 21,000.

For customers, there is a price to pay, however. In the case of Microsoft, Info-Tech’s Randall said that, with the cuts, some customers can now expect slower response times on “non-strategic asks,” particularly as accounts are consolidated under fewer reps.

That said, given its Frontier Company investments, top accounts with large AI, data, security, and cloud commitments may get “deeper technical engagement,” while ordinary licensing/support workflows may become leaner.

Further, customers can expect more hand-offs to partner-led engagements, given that Microsoft is already pushing customers toward its partners for FY27 (which began July 1, 2026) when it comes to AI, security, cloud modernization, Copilot, agents, and managed services, Randall said. The company is also offering partners higher margins for growth in certain AI workloads.

“To prepare for these shifts, customers should reflect and document their Microsoft account and support teams,” Randall advised.

By that he meant enumerating things like the support contacts, the partner contacts, and the escalation paths for issues. This information should be well-documented and shared internally, he said. The same goes for Microsoft-involved conversations having to do with any kind of commitment, such as those involve pricing assumptions, roadmap dependencies, or deployment milestones.

“This can ensure a smoother transition with a new account rep on what has already been set out for the organization,” Randall said.

Closing the gap between AI investment and ROI

Last week, Microsoft launched the $2.5 billion Frontier Company, which it said “goes beyond” SIs and Forward Deployed Engineers (FDE). The initiative will integrate thousands of the company’s own engineers directly into customer environments to help them build AI tools, and to also help customers learn essential skills so they can eventually handle projects on their own.

But customers shouldn’t think of this as what he described as “consulting-heavy, McKinsey-style engagements,” noted Info-Tech’s Randall. Pre-sales will likely become more focused on qualifying an organization’s specific processes for ongoing AI implementations, rather than on system-wide change management. As with other hyperscalers such as AWS, Microsoft is leaning into this more white-glove model to help “prevent the gap between AI investments and AI ROI from widening.”

“As such, Microsoft will likely reserve its best technical talent for accounts with strong production intent, credible budget, usable data, and clear executive sponsorship,” Randall predicted.

This article originally appeared on CIO.com.

Judith Linine – shutterstock.com

Während die Investitionen in künstliche Intelligenz steigen, nimmt auch die Zahl der Entlassungen in der Technologiebranche weiter zu. Allein Microsoft streicht in dieser Woche rund 4.800 Stellen, was etwa 2,1 Prozent der Belegschaft entspricht.

Die jüngsten Kürzungen betreffen vor allem die Bereiche Commercial Sales und Xbox. Sie folgen auf zwei weitere Entlassungsrunden im Jahr 2025, von denen insgesamt rund 15.000 Beschäftigte beziehungsweise etwa vier Prozent der Belegschaft betroffen waren. Vor den aktuellen Stellenstreichungen beschäftigte Microsoft mehr als 220.000 Mitarbeiter.

Die Reduzierung der Belegschaft erfolgt zudem nur wenige Tage nach der Ankündigung von Microsoft Frontier Company, einer Initiative, die Kunden bei der Einführung von KI-Projekten mit fest eingebundenen Experten unterstützt – ähnlich wie klassische Angebote von Systemintegratoren (SIs).

Insgesamt scheinen diese Schritte darauf hinzudeuten, dass Microsoft eher auf sein technisches Know-how als auf traditionelles Kundenmanagement setzt, um Unternehmen beim Einsatz von KI erfolgreich zu machen.

„Microsoft hatte sein kommerzielles Geschäft bereits rund um KI neu organisiert“, erklärt Thomas Randall, Research Director bei der Info-Tech Research Group, dazu. „Die jüngsten Entlassungen sind Teil dieser laufenden Neuausrichtung.“

Microsofts Mitteilung an die Belegschaft

In einem Memo an die Mitarbeiter, das Business Insider vorliegt, erklärt Amy Coleman, Executive Vice President und Chief People Officer bei Microsoft, die Entlassungen spiegelten den grundlegenden Wandel wider, den KI derzeit auslöse.

„Unser Geschäft verändert sich, weil sich die Welt um uns herum verändert“, schreibt sie. „Unternehmen können sich nicht aussuchen, ob sich ihre Branche verändert. Sie können nur entscheiden, ob sie sich mit ihr verändern.“

Die Kundenbedürfnisse und die Geschäftsmodelle, die diesen gerecht werden, verschöben sich, so Coleman. Deshalb müssten Anbieter Ressourcen und Rollen anpassen, um ihre Kunden bestmöglich unterstützen zu können.

„Wann immer möglich, hat es für uns Priorität, Mitarbeitende in neue Rollen zu versetzen, die den wichtigsten Prioritäten und größten Chancen des Unternehmens entsprechen“, betont die Managerin. Und diese Priorität laute derzeit: KI.

Abschließend erklärt sie, Microsoft werde Strukturen und Prioritäten im gesamten Unternehmen „mit Bedacht“ weiterentwickeln. „Wir arbeiten an Alternativen zu Stellenstreichungen und werden weiterhin in die Weiterbildung unserer Mitarbeitenden investieren – auch im Bereich KI.“

Was Kunden erwarten können

Microsoft ist nicht das einzige große Technologieunternehmen, das angesichts des KI-Booms Personal abbaut. Während die Branche Milliarden in KI investiert und strategische Partnerschaften mit führenden KI-Laboren eingeht, müssen diese Ausgaben teilweise durch Einsparungen ausgeglichen werden, da sich der wirtschaftliche Nutzen vieler Investitionen bislang noch nicht klar nachweisen lässt.

Amazon hat seit dem vergangenen Herbst beispielsweise 30.000 Stellen abgebaut. Google soll Gerüchten zufolge Mitarbeiter in seiner Cloud-Sparte entlassen. Meta strich allein im Mai rund 8.000 Stellen – etwa zehn Prozent der gesamten Belegschaft – und Oracle reduzierte seine Belegschaft kürzlich um 21.000 Mitarbeiter.

Für Kunden könnten diese Entwicklungen jedoch ebenfalls Folgen haben. Nach Einschätzung von Info-Tech-Analyst Randall müssen einige Microsoft-Kunden aufgrund der Stellenkürzungen künftig mit längeren Reaktionszeiten bei nicht strategischen Anfragen rechnen, insbesondere weil mehrere Kundenkonten künftig von weniger Ansprechpartnern betreut würden.

Gleichzeitig könnten wichtige Kunden mit umfangreichen Investitionen in KI, Daten, Sicherheit und Cloud angesichts der Investitionen in „Frontier Companies“ von einer intensiveren technischen Betreuung profitieren. Standardprozesse rund um Lizenzen und Support dürften dagegen schlanker organisiert werden, so Randall.

Darüber hinaus sollten Kunden mit einer stärkeren Einbindung von Partnern rechnen. Bereits seit Beginn des Geschäftsjahr 2027 (Anfang: 1. Juli 2026) lenke Microsoft Kunden verstärkt zu seinen Partnern – insbesondere bei Themen wie KI, Sicherheit, Cloud-Modernisierung, Copilot, KI-Agenten und Managed Services, so Randall. Zudem biete Microsoft seinen Partnern höhere Margen für Wachstum bei bestimmten KI-Workloads.

„Um sich auf diese Veränderungen vorzubereiten, sollten Kunden ihre Microsoft-Ansprechpartner und Support-Strukturen überprüfen und dokumentieren“, empfiehlt der Info-Tech-Analyst. Dazu gehöre, Support-Kontakte, Ansprechpartner bei Partnerunternehmen und Eskalationswege vollständig zu erfassen und diese Informationen intern zugänglich zu machen. Dasselbe gelte für alle Vereinbarungen mit Microsoft, etwa zu Preisannahmen, Abhängigkeiten in der Roadmap oder Meilensteinen bei Implementierungsprojekten.

„Auf diese Weise lässt sich der Übergang zu einem neuen Kundenbetreuer deutlich reibungsloser gestalten, da bereits festgelegte Vereinbarungen für das Unternehmen nachvollziehbar dokumentiert sind“, so Randall.

Die Lücke zwischen KI-Investitionen und ROI schließen

In der vergangenen Woche stellte Microsoft die 2,5 Milliarden Dollar schwere Initiative Frontier Company vor. Nach Angaben des Unternehmens geht sie über klassische Systemintegratoren und sogenannte Forward Deployed Engineers (FDEs) hinaus. Tausende Microsoft-Ingenieure sollen direkt in Kundenprojekten mitarbeiten, um gemeinsam KI-Lösungen zu entwickeln und zugleich das notwendige Know-how zu vermitteln, damit Unternehmen diese Projekte künftig eigenständig umsetzen können.

Kunden sollten diese Initiative allerdings nicht als klassische, beratungsintensive Projekte im McKinsey-Stil verstehen, betont Randall. Der Presales-Bereich werde sich wahrscheinlich stärker darauf konzentrieren, die konkreten Geschäftsprozesse eines Unternehmens für laufende KI-Implementierungen zu bewerten, anstatt umfassende Change-Management-Projekte zu begleiten.

Ähnlich wie andere Hyperscaler, beispielsweise AWS, setze Microsoft verstärkt auf ein besonders enges Betreuungsmodell, um zu verhindern, dass die Lücke zwischen KI-Investitionen und dem tatsächlichen KI-Mehrwert weiterwächst, erklärt der Analyst.

„Microsoft wird seine besten technischen Experten daher wahrscheinlich für Kunden reservieren, die klare Absichten für den produktiven Einsatz, ein belastbares Budget, nutzbare Daten und eine eindeutige Unterstützung durch das Top-Management vorweisen können“, prognostiziert Randall. (mb)

Dieser Artikel basiert auf einem Beitrag von CIO.com.

At some point, every security leader gets asked a version of the same question: Are we good? It tends to arrive when something is at stake and the person asking needs to know they can rely on the answer.

I learned what that question really means at a firm I was with earlier in my career. We had received intelligence that threat actors were preparing to go after financial services firms over the holidays, counting on skeleton staffing and slower response times. We had procedures for exactly that kind of heightened alert, and we ran them. The moment that stayed with me came in a hallway. The head of business stopped me and asked, plainly, “Are we good?” He was not asking for a status report on our controls or a walkthrough of our incident response plan. He wanted a seasoned leader to look at him and say, with conviction, that we were good.

That instinct, the need for someone accountable enough to say “we’re good” and mean it, sits at the center of a debate the cybersecurity industry keeps having: Whether the CISO role has become unsustainable. The list of responsibilities continues to grow. Security leaders are expected to oversee cyber resilience, regulatory compliance, third-party risk, business continuity, AI governance, incident response and an ever-more-complex threat landscape. Boards, regulators, customers and investors simultaneously demand greater visibility into cyber risk than ever before.

The conclusion many people draw from this expansion is that the traditional CISO role can no longer work. If no single person can realistically master every domain that falls under modern cybersecurity, perhaps the role itself has become obsolete.

I believe the opposite is true. The modern CISO is disappearing from one version of itself and re-emerging as something larger. It is undergoing the same evolution the CFO role experienced over the last two decades.

Historically, CFOs were viewed primarily as financial operators. Their responsibilities centered on accounting, reporting, controls, audits and budgeting. As businesses grew larger, more global, more regulated and more dependent on technology, that model changed. The CFO evolved from a finance specialist into a strategic executive responsible for shaping enterprise-wide decisions. McKinsey documented this shift, finding that the number of functions reporting to CFOs had expanded significantly, and that business leaders had come to see them as critical drivers of change across the enterprise, not just stewards of the balance sheet.

Nobody looked at that expanding mandate and concluded the CFO role was becoming irrelevant. They recognized that finance had become more important to the business.

The same thing is happening in cybersecurity. For years, security was treated as a technical discipline operating on the periphery of the organization. Today, a significant cyber incident can halt operations, disrupt revenue, trigger regulatory scrutiny, damage customer trust and move markets. Cyber risk has become business risk, and that shift fundamentally changes what a CISO is for. Security leaders increasingly sit on enterprise risk committees alongside their peers, and regulators are paying far closer attention to how security is built into the design of products and systems from the outset. Both are signs that security has moved from a back-office function into the room where business risk gets decided.

The data reflects how much the role has already changed. According to Splunk’s 2026 CISO Report, nearly all CISOs now count AI governance and risk management among their core responsibilities. Seventy-eight percent report personal liability concerns tied to security incidents, up from 56% just a year ago. The role now carries individual legal exposure alongside operational accountability. That is a description of an executive function, full stop.

Modern security leaders are now expected to help boards understand risk, participate in strategic planning, navigate regulatory obligations, oversee resilience programs and establish governance around emerging technologies like artificial intelligence. These responsibilities extend well beyond traditional security operations, and the job has grown considerably faster than the organizational structures supporting it.

Some companies have responded by building larger, more specialized security leadership teams. Microsoft’s Secure Future Initiative is the most prominent example. The company established a Cybersecurity Governance Council led by a Global CISO, with over a dozen Deputy CISOs appointed across major security domains including engineering, AI, cloud services, gaming and government systems. It represents one of the largest security transformations in the industry, involving thousands of engineers and a governance structure built to coordinate security across a genuinely sprawling organization.

Some observers read structures like this as evidence that the traditional CISO model is breaking down. Look closer and you see the opposite. Microsoft expanded the organization supporting security leadership rather than dismantling it. Centralized accountability remains with a global CISO while execution is distributed across specialized leaders and teams.

This is exactly what mature executive functions look like at scale. Large enterprises do not eliminate CFOs when finance grows more complex. They add controllers, treasury leaders, FP&A organizations and investor relations teams. Complexity does not eliminate executive accountability. It deepens the need for it.

There is shared, organization-wide security: the SOC, vulnerability management and the other services the entire firm depends on. Then there is business-line security, led by deputy or business-unit CISOs whose job is to make sure their individual units are protected. Those embedded leaders drive requirements into the shared services and provide independent oversight of them, while staying close enough to their business to understand what it actually needs. One central executive owns the whole picture, with specialized leaders carrying it into every corner of the organization.

One structural point follows directly from this: The CISO should never report to the CTO. The person accountable for security should not sit underneath the person accountable for building and shipping technology, because those two mandates can pull in different directions. Security belongs under the COO, the CRO or the CEO, where it can speak to risk independently and be heard.

AI is accelerating this evolution further. Organizations are deploying autonomous systems capable of making recommendations, triggering workflows and acting at machine speed. What AI cannot do is own the decisions behind those actions. Someone still has to determine what can be delegated to machines, establish governance frameworks, define acceptable risk and answer for those choices to regulators, boards and shareholders. In most organizations, that someone is the CISO.

The most practical place to start is a simple principle: every AI action should trace back to an accountable human. Framed that way, we are not delegating decisions to AI at all. We are putting machines to work while keeping a person answerable for what they do. That principle forces accountability to live somewhere specific in the organization rather than dissolving into the system.

This is worth sitting with: AI may strengthen the case for executive security leadership rather than weaken it. For years, CISOs governed human behavior inside organizations. Now they govern human and machine behavior simultaneously, a mandate with no obvious ceiling.

The cybersecurity industry keeps asking whether the CISO role can survive the demands being placed on it. The better question is whether organizations are adapting their leadership structures fast enough to support where the role is already heading.

The future of security leadership is unlikely to be a loose collection of specialists operating without clear ownership. It will more closely resemble other mature executive functions, with specialized leaders operating under a single accountable executive who understands how risk connects to the business as a whole. As cyber risk becomes inseparable from business risk, that executive becomes indispensable.

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

The number of tech layoffs continues to tick upwards as AI investments increase, with Microsoft alone cutting around 4,800 employees, or roughly 2.1% of its workforce, this week.

The latest cutbacks are mostly in the company’s commercial sales and Xbox divisions. They follow two others in 2025 that impacted around 15,000 workers, or roughly 4% of the company’s workforce. Prior to the latest cuts, Microsoft had 220,000-plus employees.

The headcount reduction also comes just days after the announcement of Microsoft Frontier Company, an initiative that will provide embedded support for customers deploying AI projects, similar to traditional offerings from systems integrators (SIs).

Taken together, these moves seem to indicate that Microsoft is betting on its engineering expertise, rather than traditional account management, as the path to AI success.

“Microsoft had already reorganized its commercial business around AI,” said Thomas Randall, a research director at Info-Tech Research Group. “Recent layoffs are part of that ongoing context.”

Microsoft’s memo to employees

In a memo obtained by Business Insider, Microsoft EVP and chief people officer Amy Coleman said the cuts effectively reflect the tectonic shift being brought about by AI.

“The ‘why’ is this: Our business is changing because the world around it is changing,” she said. “Companies don’t get to choose whether their industry changes; they only get to choose whether they change with it.”

Customer needs, and the business models that serve them, are shifting, meaning vendors must “adjust resources and roles” so they can operate in a way that best serves their customers. However, Coleman emphasized: “Whenever possible, our priority is to place people into new roles aligned to the company’s highest priorities and greatest areas of opportunity.”

Which, today, is AI.

Seemingly contradictorily, Coleman said the cuts “build on” the Frontier Company announcement, which is “reshaping how we work and embedding our engineering experts alongside customers so we can help them accelerate their technology deployments.”

While she emphasized that the roles eliminated this week are not being replaced by AI, the technology is fundamentally changing work. Many everyday tasks are being automated, meaning “we all need to keep learning, keep building new skills, and keep adapting as the work evolves.”

Customers are undergoing the same shift and are looking to Microsoft for guidance, she noted. “We can’t do that well unless we’re doing it ourselves.”

Finally, she said the tech giant will evolve structure and priorities across the company “thoughtfully.”

“We are working on alternative solutions to job eliminations and … we will continue to invest in equipping employees with new skills, including in AI.”

What customers might expect

Redmond isn’t the only big tech company taking scalpels to staff as the industry adjusts to, and seeks to capitalize on, AI. Companies are spending billions and inking strategic partnerships with top AI labs, and these investments in some cases need to be offset with cuts because some have yet to provide tangible ROI.

For instance, Amazon has laid off 30,000 workers since last fall, while Google is rumored to be cutting employees in its cloud division. Meta, for its part, eliminated 8,000 employees, or about 10% of its total headcount, in May alone, while Oracle recently slashed 21,000.

For customers, there is a price to pay, however. In the case of Microsoft, Info-Tech’s Randall said that, with the cuts, some customers can now expect slower response times on “non-strategic asks,” particularly as accounts are consolidated under fewer reps.

That said, given its Frontier Company investments, top accounts with large AI, data, security, and cloud commitments may get “deeper technical engagement,” while ordinary licensing/support workflows may become leaner.

Further, customers can expect more hand-offs to partner-led engagements, given that Microsoft is already pushing customers toward its partners for FY27 (which began July 1, 2026) when it comes to AI, security, cloud modernization, Copilot, agents, and managed services, Randall said. The company is also offering partners higher margins for growth in certain AI workloads.

“To prepare for these shifts, customers should reflect and document their Microsoft account and support teams,” Randall advised.

By that he meant enumerating things like the support contacts, the partner contacts, and the escalation paths for issues. This information should be well-documented and shared internally, he said. The same goes for Microsoft-involved conversations having to do with any kind of commitment, such as those involve pricing assumptions, roadmap dependencies, or deployment milestones.

“This can ensure a smoother transition with a new account rep on what has already been set out for the organization,” Randall said.

Closing the gap between AI investment and ROI

Last week, Microsoft launched the $2.5 billion Frontier Company, which it said “goes beyond” SIs and Forward Deployed Engineers (FDE). The initiative will integrate thousands of the company’s own engineers directly into customer environments to help them build AI tools, and to also help customers learn essential skills so they can eventually handle projects on their own.

But customers shouldn’t think of this as what he described as “consulting-heavy, McKinsey-style engagements,” noted Info-Tech’s Randall. Pre-sales will likely become more focused on qualifying an organization’s specific processes for ongoing AI implementations, rather than on system-wide change management. As with other hyperscalers such as AWS, Microsoft is leaning into this more white-glove model to help “prevent the gap between AI investments and AI ROI from widening.”

“As such, Microsoft will likely reserve its best technical talent for accounts with strong production intent, credible budget, usable data, and clear executive sponsorship,” Randall predicted.

The number of tech layoffs continues to tick upwards as AI investments increase, with Microsoft alone cutting around 4,800 employees, or roughly 2.1% of its workforce, this week.

The latest cutbacks are mostly in the company’s commercial sales and Xbox divisions. They follow two others in 2025 that impacted around 15,000 workers, or roughly 4% of the company’s workforce. Prior to the latest cuts, Microsoft had 220,000-plus employees.

The headcount reduction also comes just days after the announcement of Microsoft Frontier Company, an initiative that will provide embedded support for customers deploying AI projects, similar to traditional offerings from systems integrators (SIs).

Taken together, these moves seem to indicate that Microsoft is betting on its engineering expertise, rather than traditional account management, as the path to AI success.

“Microsoft had already reorganized its commercial business around AI,” said Thomas Randall, a research director at Info-Tech Research Group. “Recent layoffs are part of that ongoing context.”

Microsoft’s memo to employees

In a memo obtained by Business Insider, Microsoft EVP and chief people officer Amy Coleman said the cuts effectively reflect the tectonic shift being brought about by AI.

“The ‘why’ is this: Our business is changing because the world around it is changing,” she said. “Companies don’t get to choose whether their industry changes; they only get to choose whether they change with it.”

Customer needs, and the business models that serve them, are shifting, meaning vendors must “adjust resources and roles” so they can operate in a way that best serves their customers. However, Coleman emphasized: “Whenever possible, our priority is to place people into new roles aligned to the company’s highest priorities and greatest areas of opportunity.”

Which, today, is AI.

Seemingly contradictorily, Coleman said the cuts “build on” the Frontier Company announcement, which is “reshaping how we work and embedding our engineering experts alongside customers so we can help them accelerate their technology deployments.”

While she emphasized that the roles eliminated this week are not being replaced by AI, the technology is fundamentally changing work. Many everyday tasks are being automated, meaning “we all need to keep learning, keep building new skills, and keep adapting as the work evolves.”

Customers are undergoing the same shift and are looking to Microsoft for guidance, she noted. “We can’t do that well unless we’re doing it ourselves.”

Finally, she said the tech giant will evolve structure and priorities across the company “thoughtfully.”

“We are working on alternative solutions to job eliminations and … we will continue to invest in equipping employees with new skills, including in AI.”

What customers might expect

Redmond isn’t the only big tech company taking scalpels to staff as the industry adjusts to, and seeks to capitalize on, AI. Companies are spending billions and inking strategic partnerships with top AI labs, and these investments in some cases need to be offset with cuts because some have yet to provide tangible ROI.

For instance, Amazon has laid off 30,000 workers since last fall, while Google is rumored to be cutting employees in its cloud division. Meta, for its part, eliminated 8,000 employees, or about 10% of its total headcount, in May alone, while Oracle recently slashed 21,000.

For customers, there is a price to pay, however. In the case of Microsoft, Info-Tech’s Randall said that, with the cuts, some customers can now expect slower response times on “non-strategic asks,” particularly as accounts are consolidated under fewer reps.

That said, given its Frontier Company investments, top accounts with large AI, data, security, and cloud commitments may get “deeper technical engagement,” while ordinary licensing/support workflows may become leaner.

Further, customers can expect more hand-offs to partner-led engagements, given that Microsoft is already pushing customers toward its partners for FY27 (which began July 1, 2026) when it comes to AI, security, cloud modernization, Copilot, agents, and managed services, Randall said. The company is also offering partners higher margins for growth in certain AI workloads.

“To prepare for these shifts, customers should reflect and document their Microsoft account and support teams,” Randall advised.

By that he meant enumerating things like the support contacts, the partner contacts, and the escalation paths for issues. This information should be well-documented and shared internally, he said. The same goes for Microsoft-involved conversations having to do with any kind of commitment, such as those involve pricing assumptions, roadmap dependencies, or deployment milestones.

“This can ensure a smoother transition with a new account rep on what has already been set out for the organization,” Randall said.

Closing the gap between AI investment and ROI

Last week, Microsoft launched the $2.5 billion Frontier Company, which it said “goes beyond” SIs and Forward Deployed Engineers (FDE). The initiative will integrate thousands of the company’s own engineers directly into customer environments to help them build AI tools, and to also help customers learn essential skills so they can eventually handle projects on their own.

But customers shouldn’t think of this as what he described as “consulting-heavy, McKinsey-style engagements,” noted Info-Tech’s Randall. Pre-sales will likely become more focused on qualifying an organization’s specific processes for ongoing AI implementations, rather than on system-wide change management. As with other hyperscalers such as AWS, Microsoft is leaning into this more white-glove model to help “prevent the gap between AI investments and AI ROI from widening.”

“As such, Microsoft will likely reserve its best technical talent for accounts with strong production intent, credible budget, usable data, and clear executive sponsorship,” Randall predicted.

This article originally appeared on CIO.com.

Across the global corporations, I advise, in financial services, healthcare, retail and the public sector, the same crisis surfaces in leadership meetings. Executives approved a bold AI roadmap. Cloud spending climbed 40, 50, even 70 percent. And yet the AI workloads that made perfect sense in the boardroom presentation now stall, overshoot their budgets or collapse under production load before they reach real users.

I am writing this just after the spring 2026 conference season, and the signal from Google Cloud Next, Microsoft Build, and a run of AWS summits only sharpens the point. Over the past several weeks the industry shipped, in production form, the infrastructure to run and govern AI at scale. What most enterprises still lack is the operating model to decide how to use it.

The problem is not the AI models. The models work. The problem is that organizations built their AI ambitions on cloud strategies designed for a world that no longer exists: strategies built for SaaS applications, predictable traffic and linear cost curves. AI workloads break all three assumptions at once.

Why AI breaks traditional cloud assumptions

For a decade, cloud-first served enterprises well. It delivered elasticity, reduced capital expenditure and democratized access to compute, because enterprise workloads were predictable: web applications, ERP systems, databases and analytics pipelines that scaled smoothly and billed in ways finance could model on a spreadsheet. GenAI and agentic AI change every one of those assumptions at once.

When organizations move AI into production, real inference, retrieval pipelines, vector search and real-time decisioning, the cloud equation breaks in at least five ways:

1. Training clusters demand power densities far above standard compute.
2. Inference needs millisecond latency that network geography can defeat.
3. Vector databases generate cost spikes invisible in standard billing.
4. Agentic workloads chain hundreds of tool calls with cascading dependencies.
5. And data-sovereignty rules constrain where any of them can run.

In short, what works at the platform level fails at the workload level.

The costs are the first thing to surprise leaders, because they hide. CloudZero’s analysis and the FinOps teams I work with put it plainly: AI spend surfaces as generic compute, storage and instance line items, rarely labeled “AI.” Three layers drive most of the waste:

1. The most visible is LLM API cost, where stateless calls re-send the full conversation history on every request, so a deployment with a couple hundred users can burn many times the token budget in the business case.
2. The biggest is idle GPU: teams’ provision for peak and then run at 10 to 20 percent utilization, and most miss their AI cost forecasts by more than a quarter.
3. The most underestimated is the vector database and retrieval layer, where storage I/O, query volume and embedding refresh appear nowhere labeled AI until the bill arrives.

The dimensions leaders underweight resilience and control

Cost and latency dominate the conversation. Two dimensions rarely get the same rigor until something breaks:

1. Resilience, whether an AI-dependent system can survive failure, degrade gracefully and recover predictably.
2. Control, who can observe, halt and audit it.

AI introduces failure modes that traditional architecture never faced: GPU single points of failure under revenue-critical inference, agentic pipelines that fail mid-execution with no rollback, and models that degrade silently from drift or throttling.

I see the pattern repeated across industries. Organizations design resilience for their traditional applications, then deploy AI on top without asking whether the same guarantees hold. In one global financial services firm I advise, a real-time credit-decisioning model running on a single cloud region took a 47-minute outage during a regional availability event. The halted loan approvals cost more than the system’s entire annual infrastructure budget, and the resilience rework that followed cost several times what designing it in from the start would have. The leaders who avoid this should ask four questions before go-live:

1. What happens when the network fails?
2. What happens when the model degrades?
3. What happens when an agent executes only halfway?
4. Who holds the authority to halt and audit?

What the cloud providers signaled this spring

The major providers are on track to spend close to $700 billion on AI infrastructure in 2026, roughly three and a half times the 2024 level. Their announcements are strategic signals, not just features. Last year they converged on one message: enterprises cannot run everything in public cloud, so all three built ways to bring their infrastructure into your data center and your sovereign environment. This year the signal advanced a step. They stopped talking about where workloads run and started shipping the layer that governs what agents are allowed to do: identity, containment, auditability and rollback.

Microsoft introduced an “Agent Computer” model with execution containers and machine identity for agents. AWS built Amazon Bedrock AgentCore around runtime, memory, identity and auditability. Google shipped an agent gateway and sovereign controls for cross-cloud traffic. As Bain observed, agentic AI is now an economics and operations problem, not just a capability problem. The through-line, captured by Microsoft’s own framing, is that AI alone will not change your business; the system running it will. McKinsey’s read is consistent: workloads are becoming more distributed, specialized and operationally demanding, which forces more deliberate infrastructure decisions.

Vipin Jain

From platform choice to placement decision

The failure I document most often is not a technology failure; it is a governance failure. Most enterprises lack a clear, repeatable way to decide what runs where, under what conditions and with what tradeoffs. Platform teams make that call informally, under deadline pressure and repeat it hundreds of times as new use cases launch. Workloads then accumulate in public cloud by default, not by design and 30 to 50 percent cost overruns follow, not because public cloud was the wrong choice but because no deliberate choice was ever made.

In one global manufacturer I advise, a predictive-maintenance model went live on public cloud and performed exactly as validated in staging. But real-time inference on the factory floor ran at 80 to 120 milliseconds across the WAN, when the machine-control system needed under ten. Moving the model to edge nodes fixed the latency, but the company lost most of a quarter of the cost, rework and delayed benefits, and the line had run for weeks on stale recommendations: a control failure that could have caused a safety event. The fix was never more AI talent. It was a structured placement decision at the start, weighing six dimensions:

• Latency: real-time (under 10 ms, edge or on-prem), interactive (50 to 500 ms, cloud) or batch.
• Cost and TCO: token spend, GPU utilization, vector-database queries, egress and unit economics per workload.
• Resilience: failover architecture, degraded-mode behavior, recovery SLA and rollback policy.
• Control: observability, audit trails, governance authority and the ability to halt or reverse.
• Data sensitivity: sovereignty requirements, privacy and compliance rules, and IP protection.
• Integration: legacy system dependencies, pipeline complexity and data-residency constraints.

Run consistently, those dimensions produce a placement pattern like this:

This is no longer optional. Cloudian’s 2026 enterprise AI infrastructure survey found that 79 percent of enterprises have already moved AI workloads out of public cloud, and 93 percent are repatriating or actively evaluating it, driven by data sovereignty, cost overruns and real-time performance. Repatriation is now the norm, not the exception.

The agentic layer makes discipline urgent. An agent chains 20 to 100 tool calls, each with its own latency, cost and failure mode, so the governance model that works for a chatbot does not work for an autonomous agent approving procurement or onboarding a customer. This spring the providers shipped production infrastructure for exactly this, yet Deloitte’s 2026 survey of more than 3,000 leaders finds only about one in five companies has a mature governance model for autonomous agents. The platforms solved the mechanism. Most enterprises have not yet written the policy.

What the leaders do differently

The organizations extracting compounding value from AI, not just running experiments, share one discipline: they treat workload placement as a repeatable process, and they build resilience and control in from the start rather than after the first production incident. In practice, they do five things:

1. Classify every use case at intake across the six dimensions, before any infrastructure is provisioned.
2. Separate AI budget lines for experiments, production inference and training, so cost is governable.
3. Treat unit economics, cost per inference, per query and per agent run, as engineering KPIs, not month-end surprises.
4. Define repatriation triggers in advance, typically 12 to 18 months of stable volume.
5. Write an explicit resilience contract, and agentic observability and rollback rules, before scaling.

The gap between strategy-ready and infrastructure-ready is the remediation backlog, and most enterprises stall moving from proof of concept to production for exactly this reason. Deloitte’s tech-trends analysis frames the same shift as the move to inference economics: the bottleneck is infrastructure governance, not model capability.

Vipin Jain

For CIOs, a 90-day agenda. Five actions separate the leaders from those managing infrastructure crises:

1. Audit every AI workload in production across latency, cost, sovereignty, volume, resilience, control and integration.
2. Separate AI infrastructure budget lines so each workload type is attributable and governable.
3. Define unit economics by workload and review them as engineering KPIs.
4. Set a quantitative repatriation evaluation trigger.
5. Define observability, cost attribution and rollback policy before scaling agents.

The strategic reframe

The organizations making real progress on AI are not distinguished by the sophistication of their models or the size of their cloud contracts. One discipline sets them apart: a clear, repeatable way to decide what runs where, under what conditions, with what tradeoffs and what happens when something fails. That discipline is not an IT problem. It is a strategic capability that requires CIO ownership, CFO alignment and executive accountability.

This spring the cloud providers handed enterprises the infrastructure to run and govern AI, and agents, at every tier of the architecture. The gap is no longer supply. It is the operating model to use deliberately. The companies building that model now build the operating foundation for AI at scale. Everyone else builds a remediation backlog. The infrastructure decisions you make in the next 12 months will decide which of those two you become.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

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

Every finance transformation conversation we have these days starts with AI. Clients arrive at the table with a list of agentic capabilities they want to deploy and an assumption that technology is the answer.

That assumption is half right. AI is one of the most consequential forces reshaping finance in a generation, and the future-state operating models we are designing today look fundamentally different as a result. But AI alone is not a strategic finance roadmap. The return comes from sequencing AI with the right process redesign, technology architecture and data foundation, with each piece compounding the next.

For decades, CFOs treated transformation like a renovation, managing tasks room by room. They executed separate projects to update the close, replace an ERP and layer better reporting on the same operating model. AI changes that blueprint. For the first time, we can take the house down to the studs and rebuild around capabilities that did not exist three years ago. That is a different kind of project, and it requires a different kind of leader.

AI has done something that previous waves of transformation never managed to do. It has brought the right stakeholders into the conversation and forced finance and IT to address the same problem simultaneously. That side effect alone is reshaping how the next phase of transformation gets built.

This is the part of the conversation IT leaders need to understand.

What the AI conversation has actually done

For most of the last decade, finance transformation was launched in response to a single trigger. A cost-out program. A post-acquisition integration. An ERP that aged out. The CFO owned the initiative, the CIO got pulled in to handle the technology and the rest of the business found out when the new system went live.

The AI moment has changed that pattern and forced a new conversation. When you are taking the house down to the studs rather than swapping out fixtures, the work cannot be done by Finance or IT alone. Stakeholder alignment becomes a precondition for the rebuild, not a nice-to-have. AI is the attraction that pulls everyone into the room.

When a client walks in asking about agentic finance, the CFO, CIO and heads of accounting, FP&A and controllership all show up for the same assessment. Leaders who have historically run parallel agendas now talk about the same problem at the same time. By the time we get to solution design, the cross-functional alignment that used to require months has already happened. Issues get raised early. The transformation moves faster because everyone agreed on the destination before we picked the route.

Maybe we can thank AI for bringing people together who otherwise wouldn’t have been collaborating. That is the reason the next phase of finance transformation looks structurally different from the last.

The roadmap and what’s missing

A strategic finance roadmap is not a project plan. It is more like an architect’s drawings, providing a multi-year design that connects business strategy to a future-state operating model, sequenced so each step compounds rather than starts over.

Every roadmap has a North Star. That future-state vision almost always has an AI component. A multi-agent solution orchestrated on a platform. Continuous close. Predictive FP&A. Real-time controls. Humans in the Loop. A streamlined org chart. That vision, eventually, becomes the destination.

But the destination is not today. What matters today is that the work between the as-is and future-state is cumulative, not throwaway. The data foundation organized for one transformation becomes the foundation for the next. Process improvements made now will accelerate the AI capabilities deployed two years from now.

You do not need an architect for a renovation. You hire a contractor, hand them a task list and inspect the results. You need an architect when you take the house down to the studs. The role most transformation programs are missing right now is not another builder. There are plenty of developers, system implementers and business integrators in any given program. What is missing is the architect.

The architect designs how the parts come together before anyone starts building. That work runs side by side with the client, connecting the dots between the technology, the problems, the data and the functions inside Finance and IT. The architect’s job is to create the vision and the blueprint and to translate between groups that do not naturally speak the same language. Done well, the result is a structure that is fundamentally sound and built to expand as the client’s appetite grows. Done poorly or skipped, the result is a house that cannot accommodate what comes next.

Live on the 1st floor while you build the 2nd… and 3rd

The traditional transformation pitch promises ROI at the end. Wait three years and the numbers will look great. That pitch is structurally fragile, and every CIO who has watched a transformation budget get cut in year two knows why.

Stakeholder fatigue is real. Budget uncertainty is real. In private equity-backed companies, the three-to-five-year hold period is real. Any program that has not produced measurable value in the first phase loses political support before the second phase is built.

The architectural alternative is to design the program so the first floor is occupied while the second and third floors are still being completed. The first process redesign produces value while the next is being scoped. The first technology deployment generates a return while the next is being implemented. The roadmap is not a march toward a distant payoff. It is a sequence of compounding wins.

The materiality of the return matters more than the size. A small process improvement or quick win that delivers a meaningful percentage gain in week ten is worth more than a large transformation that promises a bigger gain in year three. Quick wins prove that the blueprint is working. That proof builds the confidence stakeholders need to fund the next phase and the one after that. Investors want immediate ROI. Boards want immediate ROI. The strategic finance roadmap should be designed to deliver it.

Data in every room

Picture data as the electricity and water in a building: every room needs it, and the pipes and wires that carry it are what make the structure livable. Consolidating, warehousing and improving data quality is how you run those lines. It strengthens every element of the roadmap, not just the AI.

That has implications for how the stack gets selected. Most clients end up with an ecosystem rather than a single platform. ERP, EPM, close management, procurement, reporting and an emerging set of agentic capabilities, all integrated against a shared data foundation. The boundaries between those tools matter less than the data architecture that connects them.

It also has implications for what the CIO needs to be doing right now, even on transformations not yet formally launched. The data work pays dividends regardless of which solutions eventually get built. Cybersecurity, controls and business continuity are not bolted on at the end. They are design constraints embedded in the architecture from day one. SOX compliance is easier to build in than to retrofit, as is every other control discipline that lands on the CIO’s desk.

The roadmap in 5 years

The most concrete way to think about where this is going is to look at the org chart.

The finance org chart five years from now is not going to look like the org chart today. Where there used to be five controllers, there may be one human controller and three E-controllers, with agents sitting alongside them on the chart. The remaining human roles will be split between onshore and offshore in ways that look unfamiliar from where we sit now. The balance and location of every component will shift.

The strategic finance roadmap is the artifact that builds toward that end state, and the roadmap itself will evolve as the work progresses. Not a destination, but a continuous design exercise.

AI is rebuilding finance from the studs up. The strategic finance roadmap is how we make sure the new house is structurally sound, produces returns from the first floor and reflects the vision and the priorities of the people who will live in it. That work belongs to the CFO and the CIO together, or it does not become livable.

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