For years, I have been saying that cybersecurity is no longer a technology problem. It has become a business leadership challenge.

Yet, despite record levels of spending, ever-growing security teams, increasingly sophisticated technologies and a constant stream of new regulations, organizations continue to suffer major cyber incidents with alarming regularity. Every week seems to bring news of another ransomware attack, supply chain compromise or data breach affecting organizations that many would have assumed were well protected.

The obvious conclusion is that we are asking the wrong questions.

Too many executive teams remain preoccupied with the latest threat actor, the newest security product the CISO wants to buy or the latest vulnerability making headlines. Those issues matter, but they are not what should be keeping CEOs awake at night.

In my view, there are three far more fundamental issues that deserve the attention of every chief executive.

1. Corporate complexity, and the widening gap between business leadership and cybersecurity reality

Perhaps the biggest cybersecurity risk facing large organizations today is not technical at all.

It is the growing disconnect between executive perception and operational reality.

Many boards genuinely believe their organizations are reasonably well protected. They receive regular dashboards showing improving maturity scores, increasing compliance levels, falling vulnerability counts and reassuring traffic-light reports.

Unfortunately, cyber attackers do not read dashboards.

Behind those executive reports often lies an increasingly complex technology landscape, thousands of unmanaged digital assets, ageing infrastructure, rampant shadow IT, fragmented ownership, inconsistent governance and security teams struggling to keep pace with relentless business change.

The problem is rarely a lack of effort.

It is that corporate complexity has reached a level where traditional governance mechanisms are no longer capable of providing an accurate picture of organizational resilience.

Executives believe they understand the level of cyber risk they face because they receive regular reports. Those reports often measure activity rather than resilience.

Governance committees end up debating around another percentage point of phishing awareness or vulnerability remediation, while fundamental issues remain unaddressed in the background.

2. Organizational inertia, and the need for executive structure to evolve faster

Cyber criminals continue to evolve rapidly. Large organizations generally do not.

This is the second issue that should concern every CEO.

Throughout my career, I have observed organizations repeatedly responding to new cyber threats by adding another technology platform, another monitoring capability, another compliance framework or another governance committee.

Very rarely do they stop to redesign how cybersecurity operates.

The result is what I described several years ago as the “Cybersecurity Spiral of Failure”.

• As complexity and regulation increase, organizations invest in more security products.
• More products create more complexity.
• More products and greater complexity generate more alerts.
• More alerts require more analysts.
• More analysts produce more reports.
• More reports continue to build up executive confidence.
• Meanwhile, the underlying structural weaknesses remain largely unchanged, technical debt piles up and costs escalate.

And when the inevitable breach eventually happens, reality reveals itself, but distrust also sets in between senior executives and security teams.

This is not a funding problem. Nor is it a skills problem. It is fundamentally an operating model problem.

Many organizations continue trying to solve twenty-first century challenges using governance, accountability, organizational and reporting structures designed twenty-five years ago.

The cybersecurity function itself has evolved dramatically. Many executive structures have not.

This organizational inertia extends beyond technology: It affects budgeting cycles, investment priorities, procurement processes, accountability models and decision-making speed.

Cyber attackers innovate every day. Organizational change often takes years.

That imbalance should worry every CEO.

3. Accelerating technological disruption, and how it challenges organizations in areas where they are intrinsically weak

The third issue is potentially the most significant over the coming decade.

• Artificial intelligence, autonomous agents and machine identities
• Software supply chain complexity.
• Quantum computing, and post-quantum cryptography

Each of these developments represents far more than another technical trend.

Together, they fundamentally change the dynamics of cybersecurity.

Artificial intelligence is transforming countless business processes. At the same time, it is also increasing both the speed and sophistication of cyber-attacks while simultaneously transforming defensive capabilities.

Organizations have become increasingly dependent on software ecosystems that extend far beyond their own direct control. Engaging with the supply chain in ways that lead to a genuine appreciation of the risks involved has become a key challenge for most cybersecurity practices.

Quantum computing may eventually invalidate much of today’s cryptographic algorithms, forcing organizations into one of the largest technology efforts since Y2K — but without the benefit of a fixed deadline and faced by a problem that is considerably more complex and hyperconnected IT estates that have little to do with those of the late 90s.

None of these challenges can be solved overnight: They require clear governance, sustained investment over a few years and cross-functional organizational coordination.

Most large organizations are weak on those three fronts: This is precisely why CEOs should be focusing on them now.

Waiting until some of those risks become obvious will almost certainly be too late.

Businesses naturally prioritise immediate commercial pressures. Cybersecurity often involves preparing for risks whose timing remains uncertain.

But one of the greatest leadership failures I keep seeing remains the inability of organizations to act decisively on known unknowns.

That tension explains why many organizations delay action until external events force them to respond. Unfortunately, cybersecurity rarely rewards late action.

Leadership will determine who succeeds

Cybersecurity discussions still frequently focus on technology. I believe they should focus far more on leadership.

Technology will continue evolving. Threat actors will continue adapting. Regulations will continue expanding. Those developments are inevitable.

What remains within the control of every CEO is how their organization responds.

Does cybersecurity remain an IT issue? Or is it recognised as an integral part of business resilience?

How is cybersecurity accountability assigned at executive level? Or does it still rest largely with a CISO hidden in the organization?

Does the board spend sufficient time discussing resilience? Or does cybersecurity appear only when approving budgets or reviewing incidents?

These questions will increasingly determine organizational success.

The companies that navigate the next decade successfully will not necessarily be those spending the most on cybersecurity. Nor will they be those deploying the latest security technologies first.

They will be the organizations whose leadership recognises that cybersecurity has become a permanent business capability — embedded into governance, strategy, operational decision-making and organizational culture.

That transformation cannot be delegated. It begins with the CEO.

And perhaps that is the single biggest issue that should keep every chief executive awake at night: Not when the next cyber-attack will happen, but whether their organization is evolving quickly enough on those matters to meet a threat landscape that is changing much faster than the business itself.

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

ISC2 has begun developing a vendor-neutral AI security certification aimed at cybersecurity professionals working to secure AI systems and manage emerging AI risks.

The nonprofit organization, best known for the CISSP certification, says it is seeking volunteers worldwide to help define the knowledge and skills that will shape the new credential. While ISC2 has not finalized the certification domains, the certification is expected to address both technical AI security and governance topics, with a pilot exam planned before the end of 2026.

According to Casey Marks, ISC2 chief operating officer, feedback from cybersecurity practitioners led ISC2 to conclude that AI security had grown beyond expanding AI content within existing certifications.

“AI has reached a tipping point,” Marks says. “AI no longer is just another tool; instead, it has fundamentally changed the cybersecurity practice itself.”

ISC2 already includes AI-related content in certifications including CISSP and CCSP, but Marks says practitioners have identified new responsibilities and risks that extend beyond those programs. “Enterprise security teams are currently grappling with significant knowledge gaps, particularly around securing model architectures against new vulnerabilities like prompt injection, data poisoning, and model inversion,” Marks adds.

Organizations are working to understand emerging governance frameworks, including the NIST AI Risk Management Framework and ISO/IEC 42001, while adapting traditional application security and security operations workflows to AI systems, he says.

ISC2 has not finalized the certification domains, but Marks says the organization expects the credential to address both technical controls and governance practices for securing AI systems and managing AI risk. The certification will use ISC2’s established certification development process, which relies on cybersecurity practitioners to define job roles, develop exam content, and validate competencies.

Marks says ISC2 will continue to update the certification through ongoing input from cybersecurity professionals, in addition to its regular certification review process.

The organization is also determining which professionals the certification will target. Marks says AI security responsibilities are emerging across security architecture, risk management, security operations, software development security, governance and compliance, communication and network security, and security assessment and testing. ISC2 says the certification will reflect how those roles are evolving.

For organizations that are building AI security programs now, Marks recommends using existing AI training resources, adopting established governance frameworks, creating cross-functional AI security working groups, and participating in the certification development process.

Marks says ISC2 expects AI knowledge to become part of most cybersecurity roles while a more specialized AI security discipline continues to develop. He says organizations will increasingly need professionals with foundational AI security knowledge, as well as specialists in areas such as adversarial machine learning, model architectures, and AI data pipelines.

Looking ahead, Marks says he expects AI security expertise to evolve into both a foundational skill for cybersecurity professionals and a specialized discipline of its own.

“At this time, we are seeing a hybrid evolution occurring in real time: AI security is simultaneously becoming a baseline expectation for all security roles, while also carving out a dedicated, highly specialized discipline,” Marks says.

For years, I have been saying that cybersecurity is no longer a technology problem. It has become a business leadership challenge.

Yet, despite record levels of spending, ever-growing security teams, increasingly sophisticated technologies and a constant stream of new regulations, organizations continue to suffer major cyber incidents with alarming regularity. Every week seems to bring news of another ransomware attack, supply chain compromise or data breach affecting organizations that many would have assumed were well protected.

The obvious conclusion is that we are asking the wrong questions.

Too many executive teams remain preoccupied with the latest threat actor, the newest security product the CISO wants to buy or the latest vulnerability making headlines. Those issues matter, but they are not what should be keeping CEOs awake at night.

In my view, there are three far more fundamental issues that deserve the attention of every chief executive.

1. Corporate complexity, and the widening gap between business leadership and cybersecurity reality

Perhaps the biggest cybersecurity risk facing large organizations today is not technical at all.

It is the growing disconnect between executive perception and operational reality.

Many boards genuinely believe their organizations are reasonably well protected. They receive regular dashboards showing improving maturity scores, increasing compliance levels, falling vulnerability counts and reassuring traffic-light reports.

Unfortunately, cyber attackers do not read dashboards.

Behind those executive reports often lies an increasingly complex technology landscape, thousands of unmanaged digital assets, ageing infrastructure, rampant shadow IT, fragmented ownership, inconsistent governance and security teams struggling to keep pace with relentless business change.

The problem is rarely a lack of effort.

It is that corporate complexity has reached a level where traditional governance mechanisms are no longer capable of providing an accurate picture of organizational resilience.

Executives believe they understand the level of cyber risk they face because they receive regular reports. Those reports often measure activity rather than resilience.

Governance committees end up debating around another percentage point of phishing awareness or vulnerability remediation, while fundamental issues remain unaddressed in the background.

2. Organizational inertia, and the need for executive structure to evolve faster

Cyber criminals continue to evolve rapidly. Large organizations generally do not.

This is the second issue that should concern every CEO.

Throughout my career, I have observed organizations repeatedly responding to new cyber threats by adding another technology platform, another monitoring capability, another compliance framework or another governance committee.

Very rarely do they stop to redesign how cybersecurity operates.

The result is what I described several years ago as the “Cybersecurity Spiral of Failure”.

• As complexity and regulation increase, organizations invest in more security products.
• More products create more complexity.
• More products and greater complexity generate more alerts.
• More alerts require more analysts.
• More analysts produce more reports.
• More reports continue to build up executive confidence.
• Meanwhile, the underlying structural weaknesses remain largely unchanged, technical debt piles up and costs escalate.

And when the inevitable breach eventually happens, reality reveals itself, but distrust also sets in between senior executives and security teams.

This is not a funding problem. Nor is it a skills problem. It is fundamentally an operating model problem.

Many organizations continue trying to solve twenty-first century challenges using governance, accountability, organizational and reporting structures designed twenty-five years ago.

The cybersecurity function itself has evolved dramatically. Many executive structures have not.

This organizational inertia extends beyond technology: It affects budgeting cycles, investment priorities, procurement processes, accountability models and decision-making speed.

Cyber attackers innovate every day. Organizational change often takes years.

That imbalance should worry every CEO.

3. Accelerating technological disruption, and how it challenges organizations in areas where they are intrinsically weak

The third issue is potentially the most significant over the coming decade.

• Artificial intelligence, autonomous agents and machine identities
• Software supply chain complexity.
• Quantum computing, and post-quantum cryptography

Each of these developments represents far more than another technical trend.

Together, they fundamentally change the dynamics of cybersecurity.

Artificial intelligence is transforming countless business processes. At the same time, it is also increasing both the speed and sophistication of cyber-attacks while simultaneously transforming defensive capabilities.

Organizations have become increasingly dependent on software ecosystems that extend far beyond their own direct control. Engaging with the supply chain in ways that lead to a genuine appreciation of the risks involved has become a key challenge for most cybersecurity practices.

Quantum computing may eventually invalidate much of today’s cryptographic algorithms, forcing organizations into one of the largest technology efforts since Y2K — but without the benefit of a fixed deadline and faced by a problem that is considerably more complex and hyperconnected IT estates that have little to do with those of the late 90s.

None of these challenges can be solved overnight: They require clear governance, sustained investment over a few years and cross-functional organizational coordination.

Most large organizations are weak on those three fronts: This is precisely why CEOs should be focusing on them now.

Waiting until some of those risks become obvious will almost certainly be too late.

Businesses naturally prioritise immediate commercial pressures. Cybersecurity often involves preparing for risks whose timing remains uncertain.

But one of the greatest leadership failures I keep seeing remains the inability of organizations to act decisively on known unknowns.

That tension explains why many organizations delay action until external events force them to respond. Unfortunately, cybersecurity rarely rewards late action.

Leadership will determine who succeeds

Cybersecurity discussions still frequently focus on technology. I believe they should focus far more on leadership.

Technology will continue evolving. Threat actors will continue adapting. Regulations will continue expanding. Those developments are inevitable.

What remains within the control of every CEO is how their organization responds.

Does cybersecurity remain an IT issue? Or is it recognised as an integral part of business resilience?

How is cybersecurity accountability assigned at executive level? Or does it still rest largely with a CISO hidden in the organization?

Does the board spend sufficient time discussing resilience? Or does cybersecurity appear only when approving budgets or reviewing incidents?

These questions will increasingly determine organizational success.

The companies that navigate the next decade successfully will not necessarily be those spending the most on cybersecurity. Nor will they be those deploying the latest security technologies first.

They will be the organizations whose leadership recognises that cybersecurity has become a permanent business capability — embedded into governance, strategy, operational decision-making and organizational culture.

That transformation cannot be delegated. It begins with the CEO.

And perhaps that is the single biggest issue that should keep every chief executive awake at night: Not when the next cyber-attack will happen, but whether their organization is evolving quickly enough on those matters to meet a threat landscape that is changing much faster than the business itself.

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

Over the past year, I had the same conversation with almost every team starting an AI initiative. Should we build on Semantic Kernel, AutoGen or Foundry?

At first it felt like the most important architectural decision we’d make. Each framework had its own philosophy, each promised to be the foundation for enterprise AI, and picking the wrong one felt like an expensive mistake. I spent a lot of time helping teams weigh the trade-offs.

Looking back, I think we were asking the wrong question. I certainly was.

I watched teams spend months debating SDKs while the decisions that actually decided whether their applications survived production went unexamined. Some built elaborate orchestration layers for workflows that a few deterministic functions would have handled. Others avoided agent frameworks entirely and later found they’d designed themselves into a corner.

Then Microsoft settled it for us. It introduced the unified Agent Framework, quietly moved Semantic Kernel and AutoGen into maintenance mode, and the debate I’d spent months refereeing was suddenly over. Turns out the answer to “which of the three” was “none of the three, here’s a fourth.” The framework hit version 1.0 and general availability in April 2026, stable across .NET and Python.

What surprised me wasn’t the decision. It was how fast a debate that had eaten so much of our attention stopped mattering. Microsoft changed the menu.

It didn’t change the meal.

The framework was never the hard part

Framework selection dominated almost every early conversation I had about enterprise agents. Which SDK do we standardize on? Which orchestration model gives us the most flexibility? Which one is Microsoft actually betting on?

Fair questions. But after a year of watching these projects play out, I’ve slowly come around to a different view. Those weren’t the questions that decided anything.

The first question I ask now is much smaller. Does this thing actually need an agent?

It sounds obvious, and I still get it wrong sometimes. But it’s the mistake I see most. On one project, a team spent weeks designing a multi-agent workflow for a process that ran the same four steps every time: read a document, validate it, call an API, send a notification. The diagrams looked great. The system in production didn’t. A few well-tested functions would have been easier to build, easier to maintain and a lot easier to trust.

Part of this is just that “agent” has become the word everyone reaches for. Sometimes it’s the right call. Sometimes it’s a workflow we already knew how to build, wearing a newer label. An agent earns its complexity when it genuinely has to decide things you can’t predetermine, choosing between tools, adapting to what it finds, working out its own next step. If you already know every step, you have a workflow, and a workflow is usually the better engineering choice. The consolidation didn’t change that. It just made it easier to see.

What building production agents actually taught me

Once I stopped fixating on frameworks, the same three problems kept showing up. None of them had anything to do with the SDK.

Context beats model choice

Early on I spent a lot of time comparing models, the way you’d agonize over a restaurant menu and then order what you always order. Now I spend most of it thinking about context, which is far less fun and far more useful.

I’ve watched good models fail because they were handed too much, not too little. One team I worked with gave the model access to nearly every internal document they had on the theory that more information meant better answers. It went the other way. Responses got slower, less consistent and sometimes skipped right past the thing that actually mattered. When we cut the context down to only what the task needed, the quality jumped almost immediately. I didn’t predict that. It taught me to be suspicious of “just give it everything.”

The best agent systems I’ve worked on weren’t the ones with the biggest context windows. They were the ones careful about what reached the model, and when. That’s not something the framework hands you.

Failure is where the real work is

Most agent demos look great because they’re built around the happy path. Production doesn’t extend that courtesy.

I remember a project where everything held up in testing. Then a downstream API timed out after the agent had already completed several earlier steps. We couldn’t just restart, because part of the business process had already gone through. We ended up spending far more time on recovery logic than we ever spent on prompts. That project changed how I think about this work. The hard part was never getting the model to make a decision. It was making sure the system didn’t fall apart when reality refused to follow the script.

Tool calls fail partway through. APIs return inconsistent data. Models call the same tool over and over because the last answer wasn’t what they wanted. That’s not the exception; that’s a normal Tuesday. Whether you retry, roll back, pause for a human or push on with partial results is a judgment call, and no framework is going to make it for you.

Identity is the real security boundary

This one surprised me most. The moment an agent stops being a chatbot and starts touching real business systems, identity matters more than orchestration.

Every project gets to the same question eventually. Who is this agent actually acting as? The developer’s credentials? A service account? The user who asked? Get it wrong and you’ve built something autonomous running with more access than any single person should have, which is exactly the kind of thing that looks fine until an audit. The Agent Framework, like most modern tooling, makes it easier to wire agents to tools through standards like the Model Context Protocol. That helps. But where human approval belongs, what needs extra authorization, how much rope to give the thing, those are still yours to decide.

The surprises weren’t technical

Here’s what I didn’t see coming. The hardest part of last year wasn’t technical at all. It was organizational. The moment a team heard “agent,” expectations shifted under everyone’s feet. Business stakeholders started expecting full autonomy. Developers assumed the thing could reason its way through anything. People started designing for flexibility before we’d even agreed on what problem we were solving. The word did damage before any code did. I found myself spending as much time resetting expectations as I did discussing architecture.

Build for change, not for today’s winner

I don’t think the teams that struggled last year picked the wrong framework. Semantic Kernel was reasonable. AutoGen was reasonable. Foundry made sense for plenty of cases. I’d have signed off on any of them.

The ones that got hurt put all their eggs in one framework, treating it as the foundation of the whole system instead of as one more dependency. Microsoft provided a migration path. But teams that had tightly coupled their applications to framework-specific abstractions discovered that migrating and rewriting are not the same thing. That wasn’t Microsoft’s doing. It was their own architecture’s. The teams that moved easily had kept their business logic, prompts and orchestration loose enough to evolve independently of any one SDK. For them, the change was a manageable project, not a teardown.

For what it’s worth, nobody I work with is treating this as an emergency. Most are moving the smaller workloads first, watching how they behave and leaving the production-critical systems alone until they actually understand the new abstractions. That’s the right instinct. And I doubt this is the last consolidation we’ll see, the ecosystem is still young, frameworks will keep absorbing each other and over time the differences between them will be operational more than architectural.

I don’t regret the framework debates, honestly. They were reasonable at the time. What changed wasn’t Microsoft’s roadmap.

It was mine. Watching these systems run in production taught me that the framework is the easiest piece to swap out. Recovery logic, context management, security boundaries, the business workflow itself, those stay with you long after today’s SDK gets replaced by tomorrow’s.

So, Microsoft made one decision easier by turning three frameworks into one. Good. Five years from now we’ll be on different tools, and we’ll still be asking the same handful of questions.

Does this actually need an agent? Does it have the right context? Can it recover when something breaks, because something will? Is it acting as the right person?

Those questions outlast every rewrite. That’s where I’ve learned to put my effort.

Frameworks come and go. Good architecture has to survive all of them.

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

Earlier this month, Nokia provided an AI-RAN platform update that brings an AI-native and programmable compute which is projected to double spectral efficiency by 2028. This increases speed, but more importantly, it can allow mobile operators to create some actual monetization beyond connectivity.

With this release, Nokia is introducing what it calls the industry’s first commercial AI-RAN platform, built on its AI‑native anyRAN software and Nvidia’s Aerial AI-RAN stack running on merchant GPU-based accelerated computing. The company is already seeing more than 20% gains in spectral efficiency from AI-driven radio algorithms, with a roadmap to reach 50% by 2027 and more than 100% by 2028, effectively doubling capacity on existing spectrum in dense cells.

Legacy RAN infrastructure enables connectivity but not much beyond that. The AI-RAN makes the network intelligent and extends AI into the physical world, enabling telcos to get more from their infrastructure investments, including providing a path to 6G. The partnership with Nvidia brings CUDA and AI into mobile environments.

For Network World readers, the headline isn’t just that Nokia got to market first with AI‑RAN—it’s that the company is using AI and GPUs to break the historical coupling between radio performance and custom silicon refresh cycles, and to turn the RAN into an application platform.

What AI-RAN actually is

At a technical level, Nokia’s AI‑RAN is a software‑defined baseband architecture that runs Layer 1/Layer 2 RAN functions and AI models on accelerated compute, primarily GPUs, instead of being locked into fixed‑function ASICs. Udayan Mukherjee, Nokia’s CTO for RAN and core, summarized the vision in the analyst briefing: “AI‑RAN is essentially a platform that turns the radio network into a true AI‑native programmable platform… one software detached from the hardware, defining flexible hardware deployment configurations, including part of the AI grid.”

Several pillars stand out:

• AI‑native design: Algorithms move from traditional linear models to increasingly nonlinear techniques (e.g., advanced channel estimation, deep receivers/transmitters, RKHS-based methods), which demand tensor-heavy compute best delivered by GPUs.
• Software-defined RAN: The same anyRAN software stack runs across different hardware configurations—plug‑in cards, standalone AI‑RAN nodes, and COTS/cloud RAN—so innovation comes via software releases rather than baseband card swaps.
• Programmable “D‑apps” layer: Nokia is pushing a new real‑time E3 interface from Layer 1/2 into an application layer for distributed apps (D‑apps) that can tap IQ samples, channel estimation and scheduling data for use cases such as sensing and location services.
• Crucially, this isn’t meant to replace all custom silicon overnight. Mukherjee was explicit: “We are not dropping the purpose‑built product… but we want to also get to merchant silicon, because that’s the future as we want to develop bigger models and AI elements and value‑added services on top of it.” The result is a hybrid era where AI‑accelerated platforms coexist with existing basebands but begin to shoulder the most compute‑intensive workloads.

Why AI-RAN matters for operators

Nokia and its early operator partners are trying to solve three perennial problems: finite spectrum, changing traffic patterns, and the drag of hardware refresh cycles.

First, spectrum constraints. Aji Ed, Nokia’s head of AI‑RAN and cloud RAN, called spectrum “the first constraint everybody has,” noting that operators have paid “huge amount of money” for bands and now need to “get up to the 2x spectrum” in terms of usable capacity. By running more complex AI models for multi‑user MIMO pairing, channel estimation, carrier aggregation and deep receiver/transmitter functions on GPUs, Nokia believes it can unlock those gains where traditional platforms simply run out of compute headroom.

Second, traffic is shifting. Generative AI and distributed inference workloads are driving more uplink-heavy, latency‑sensitive patterns that current RANs weren’t designed for. AI‑RAN’s ability to adapt scheduling, beamforming and resource allocation dynamically via AI models deployed at the baseband is meant to keep up with this shift.

Third, innovation cadence. In Ed’s words, “hardware upgrades can’t keep up with the innovation… we can’t really have a silicon refresh cycle linked with every three‑year cycle.” Nokia’s subscription‑based software model is designed to deliver new AI algorithms, spectral‑efficiency improvements and network optimization features continuously, without requiring “forklift” hardware replacements.

For operators, the message is attractive: comparable TCO and power to existing basebands, “no hardware premium” for GPU adoption, but higher capacity and a path to new services. Nokia told analysts it has reached performance, price and energy efficiency parity between its custom GridShark silicon and GPU-based systems, while moving the baseband roadmap to merchant silicon.

Nokia’s differentiation strategy

Every major RAN vendor is talking about AI‑enhanced radio, but Nokia is drawing a line between incremental gains and what it claims is a platform shift. When asked why its 2x spectral efficiency ambition is so much higher than the ~20% numbers competitors discuss, Ed pointed to the underlying architecture: “We are able to bring much more complex algorithms into this compute infrastructure… all of these require much higher compute, which is exactly what is coming from the accelerated computing.”

Several differentiators emerge:

• Aggressive spectral roadmap: Nokia is targeting 1.5x by 2027 and 2x by 2028, across TDD massive MIMO and FDD scenarios, with a feature roadmap built jointly with Nvidia and other partners.
• Single code base, three deployment paths: The same anyRAN software stack runs on (1) a GPU‑powered AirScale capacity plug‑in card, (2) a high‑capacity standalone AI‑RAN node, and (3) GPU‑based COTS/cloud RAN servers. This lets operators modernize “at their own pace” and mix brownfield evolution with greenfield AI-native deployments.
• Open ecosystem with D‑apps: Nokia is leaning into ORAN compliance (front‑haul, O1/O2) and actively championing the E3 interface and D‑apps concept within ORAN and AI‑RAN alliances, with Bell Labs and at least two external partners already building sensing and location applications on the platform.
• Software subscription tied to value: The commercial model builds on existing software subscriptions but ties pricing more explicitly to delivered value, such as spectral efficiency improvements and new AI services, rather than pure license metrics.

Mukherjee emphasized the openness angle in the briefing: “We see a lot of third‑party applications, whether it’s improving spectral efficiency or location service or sensing, can be developed on this platform… any AI‑powered services from us in Nokia or from ecosystems can be actually developed on top of it.” For operators burned by closed optimization stacks, that’s a notable pivot.

How AI-RAN unlocks new revenue

Most operators will sign off on AI‑RAN if the capacity and TCO story holds, but the more strategic question is monetization beyond connectivity. Nokia’s spokespeople spent considerable time on this in the analyst call, pointing to several classes of services that are difficult or impossible to deliver without AI running in the RAN itself.

Examples include:

• Integrated sensing: Turning the RAN into a distributed sensor grid that can support applications such as 3D mapping, gesture recognition and environmental monitoring, using the same RF infrastructure. Mukherjee noted, “We have at least two to three partners developing sensing applications on top of it… as well as two other companies developing location services.”
• Physical AI and location services: For factories, logistics hubs and smart cities, AI‑RAN can provide high‑precision positioning and real‑time telemetry for robots, drones and autonomous systems by fusing radio data and AI models at the edge.
• Distributed AI infrastructure: Operators exploring “AI‑native cities” can use AI‑RAN nodes and COTS GPU servers as a distributed inference fabric for applications that need tight latency to endpoints—think AR/VR offload, real‑time video analytics or interactive generative AI experiences.
• Premium connectivity tiers: With fine‑grained, AI‑driven control over uplink/downlink scheduling and QoS, operators can create differentiated SLAs for enterprise slices, mission‑critical IoT and AI workloads, charging for guaranteed performance rather than best‑effort connectivity.

Ed framed the opportunity as a continuum: Superior connectivity from 2x spectral efficiency creates “space for new AI workloads and other use cases,” while the D‑apps ecosystem and subscription model provide a mechanism to package and sell those capabilities. In practice, that could look like:

• Industrial sensing-as-a-service, where Nokia and partners supply D‑apps for integrated sensing and positioning, and operators monetize them per site or per device.
• Network‑exposed APIs for inference, location and RF sensing, integrated into operators’ broader network API portfolios as they pursue “network-as-a-platform” strategies.
• Sector‑specific AI‑native services, such as stadium analytics, transportation corridor monitoring, or drone traffic management, built by ISVs on top of Nokia’s exposed E3 data.

For operators that already use Nokia’s MantaRay and SMO stacks for cross‑network optimization, AI‑RAN essentially becomes the local real‑time execution environment, while R‑apps/X‑apps continue to orchestrate macro-level behaviors. Mukherjee described this layered architecture as “DU and CU on the platform running D‑apps using E3, interfacing to X‑apps and R‑apps through E2SM and connecting to the overall management system/SMO for lifecycle management.”

Adoption path and reality check

Nokia is not promising instant transformation. AI‑RAN pilots are slated for late 2026, with commercial availability on card‑based systems in 2027 and AirScale-based systems around 2028, all driven from a single software stack that supports 4G, 5G and is upgradable to 6G. The company already has trials and collaborations underway with T‑Mobile US, SoftBank, Indosat Ooredoo Hutchison, BT, Elisa, Vodafone, Orange, NTT Docomo, Deutsche Telekom and others.

There are still open questions around 3GPP vs ORAN standardization of E3, the maturity of the D‑apps ecosystem, and how operators will digest yet another subscription layer tied to radio software. But Nokia’s move puts a stake in the ground: in the AI era, the RAN is not just a throughput engine; it’s a programmable AI computer that can be monetized.

For Network World readers evaluating vendor roadmaps, this launch suggests a clear directional change. If Nokia hits its targets, AI‑RAN could mark the point where baseband becomes less about hardware SKUs and more about an AI platform strategy—one where spectral efficiency and new services are rolled out at “software speed,” as Ed described it, rather than at the pace of the next card generation.

Microsoft and Mistral are betting that the future of enterprise AI is in sovereign infrastructure and model choice, rather than with one locked-in system. 

The companies have announced a “significant expansion” of their strategic partnership, which includes a multibillion dollar commitment from Microsoft. Mistral will add to its GPU infrastructure in Europe and extend access to its frontier multilingual models, while Microsoft will expand its sovereign cloud capabilities. The companies will also align on a joint go-to-market plan and will pursue enterprise opportunities together across Europe and globally, as well as funding proofs of concept (PoCs), offering Azure credits, and leading workshops to drive AI innovation with customers.

The partnership between the tech giant and the three-year-old French startup might seem an odd combination at first glance, analysts note, as both develop enterprise AI models and offer access as-a-service. But it reflects changing AI market dynamics.

“It’s possible to be both a competitor and a partner at the same time,” noted technology analyst Carmi Levy. Large cloud providers are becoming AI marketplaces in their own right, he pointed out, and are drifting away from exclusively promoting their own models. Building Mistral support into their infrastructure avoids platform lock-in and removes a “key objection for customers looking for options.”

“As much as Microsoft would want everybody standardizing on Copilot and Phi, it recognizes the simple fact that customers increasingly want to choose their own models,” said Levy.

Expands model access, sovereign cloud capabilities

As part of the agreement, Mistral will expand its Europe-based capacity with thousands of Nvidia Vera Rubin GPUs.

Mistral CEO and co-founder Arthur Mensch described a “slight gap” in compute capacity in Europe, noting that this expansion will provide more compute capability and support Microsoft’s cloud and AI services, providing a “shared platform for training, inference and large-scale deployment.” The companies call it a critical step to allow Microsoft customers to benefit from Mistral’s “scientific and compute innovations.”

In addition, Mistral Medium 3.5 and OCR 4 models are now available in Microsoft Foundry, and Mistral Medium 3.5 can be used in Microsoft Copilot Studio.

The partnership also extends Microsoft’s sovereign cloud infrastructure as well as combining Mistral’s frontier models with Microsoft’s security, compliance, and cloud-to-edge platform. This gives enterprises, particularly those in regulated markets, the ability to deploy AI where they see fit, while maintaining control over their data and workloads, according to the companies.

Further, customers will be able to build AI using the same models, tools, APIs, and workflows they’re used to, across Microsoft Foundry, Foundry Local, and Azure Local, and opt for fully Azure-hosted cloud environments; cloud-connected, controlled Azure Local environments that only use cloud-based Azure when necessary; and fully-disconnected environments that can operate independently for more sensitive scenarios.

“Europe should have access to the world’s most capable AI without compromising control over their data, operations or digital future,” said Brad Smith, vice chair and president, Microsoft, noting that with this partnership, the company is honoring its European digital commitments and giving customers a foundation for AI so they can “operate on their own terms.” Customers with “heightened sovereignty needs” will be able to exercise more control with “resilience and assurance” and continued access to Mistral’s open-weight models.

Enterprise credibility

Gartner distinguished VP analyst Arun Chandrasekaran noted that there’s no doubt that this agreement strengthens Microsoft’s sovereignty messaging and its position in regulated industries, and the tech giant benefits by expanding its AI portfolio with a “credible European frontier model provider”

He pointed to key differences from the initial partnership struck by the two companies in 2024; whereas originally Microsoft was hosting Mistral’s models, it is now consuming capacity built by Mistral in Europe.

Ultimately, the deal emphasizes European data centers, customer-controlled deployments, Azure Local, and fully-disconnected environments, addressing many of the concerns that surrounded the original Azure cloud only relationship, Chandrasekaran explained.

For Mistral, the partnership provides “enterprise credibility, and repeatable infrastructure revenue” that can fund continued AI platform development, he said. The combination of Microsoft’s enterprise AI platform with Mistral’s models and European AI infrastructure will give joint customers more deployment flexibility and expand options around data residency, sovereign AI deployments, and disconnected/on-premises environments.

“It also gives customers more model choice, reducing dependence on a single AI provider,” said Chandrasekaran.

A complementary partnership

Mistral continues to innovate with its frontier AI models and its chat and coding agent, Vibe (formerly Le Chat), yet it doesn’t attract as much attention as Claude or ChatGPT.

One of the company’s key differentiators is its targeted business model. Levy pointed out that not every workload requires “full-flight GPT.” For customers trying to rein in costs and limit exposure with on-premises deployments, Mistral’s “more focused capabilities can represent a cost-effective alternative.”

Chandrasekaran pointed to Mistral’s combination of high-performance open-weight models, strong multilingual capabilities, and a “focus on efficient inference that lowers deployment costs.”

Unlike many frontier AI companies, it offers customers greater flexibility to self-host and customize models; this makes it particularly attractive for enterprises and governments with sovereignty or regulatory requirements, he said. Its European roots also position it as the leading alternative for organizations seeking cutting-edge AI outside the US and Chinese ecosystems.

Bill Wong, research fellow at Info-Tech Research Group, also pointed to Mistral’s high-quality models and “adeptness as a sovereign AI leader.” There is growing demand for AI companies that comply with regional laws and data residency, and Mistral is established as “one of the most prominent European players.”

“Such a strategic position makes it a great partner for Microsoft to further expand its AI offerings beyond just being a single-model provider,” he said. Customers get freedom of choice while complying with data sovereignty and regulatory limitations without having to execute a separate AI deployment, while Mistral, for its part, can go beyond Europe and gain more visibility with international businesses.

Mistral brings both “technological and political advantages,” Levy noted. The startup’s European roots give Microsoft more credibility “at a fraught time for geopolitical relationships.” Customers in Europe and beyond are concerned about US exposure, and Mistral can provide a safer choice.

Meanwhile, Microsoft can deploy European-developed AI models running on European infrastructure, thus maximizing regulatory compliance while offering next-level enterprise marketing scale that Mistral “simply couldn’t achieve on its own,” said Levy. Mistral-based workloads deployed on Azure will also benefit from Microsoft’s “comprehensive security certifications, governance frameworks, and monitoring.”

Bottom line: Both companies can maximize their unique roadmaps through the partnership, he said. “As the rules of the AI economy continue to evolve, expect more eyebrow-raising deals like this to be signed.”

Military strategists know that asymmetric wars are lost not at the point of attack but at the seams between defensive units, where no single commander owns the territory and information moves slower than the threat. In January 2024, a finance employee at Arup’s Hong Kong office learned this lesson for $25 million, joining a video call with what appeared to be the engineering firm’s chief financial officer and several colleagues, receiving instructions to wire funds to a designated account, and complying. Every face on the screen was a deepfake, cloned from publicly available footage of the actual executives. The attackers conducted the entire meeting in real time and vanished before anyone in the organization realized the CFO had never logged on.

The incident would be remarkable enough as a one-off, but it represents a pattern accelerating well beyond isolated cases. Global payment fraud reached $33.4 billion in 2024 according to the Nilson Report, and the US absorbed a disproportionate 42% of those losses despite processing only 25% of global card transactions. The latest FBI Internet Crime report identifies more than one million complaints and nearly $21 billion in cyber-enabled crime losses in 2025 (up from $16 million in 2023), while Deloitte projects AI-enabled fraud in the US will hit $40 billion by 2027. This increasingly includes crypto-related fraud, not just credit card or traditional banking fraud.

For anyone who oversees financial operations, risk or payment technology infrastructure, these numbers are not forecasts of a future “regional conflict.” Instead, they are the current cost of a war most institutions have not yet recognized they are fighting.

Reconnaissance at scale: How AI redraws the attacker’s map

The conventional narrative around AI-powered fraud emphasizes speed: Faster phishing, faster credential stuffing, faster social engineering. Jason Kikta, CTO of Automox, sees the shift differently. “The main threat from AI misuse isn’t faster execution, as automation has been leveraged for years,” Kikta says. “The true dangers are lower barriers to entry and faster adaptation, giving attackers the ability to pivot techniques in near real-time.”

The distinction means that execution is a quantitative improvement, the kind existing defenses can absorb by scaling up. Lower barriers to entry and real-time adaptation are qualitative: A force multiplier that turns every amateur into an equipped operator with a coach that learns from each failed attempt. Deepfake-as-a-service platforms now produce voice clones from three seconds of audio. AI-driven vulnerability scanning maps an institution’s unpatched endpoints while the security team is still scheduling the review meeting. In 2024, 269 million stolen credit card records appeared on dark web platforms, giving AI-equipped attackers what military intelligence analysts would call an order of battle: A detailed map of the defender’s exposed positions, ready to be mined for patterns, tested against live systems and exploited at machine speed.

The result is a combined arms threat, one that operates across domains simultaneously the way a competent military force coordinates air, ground and intelligence rather than running them as independent campaigns. The same AI that crafts a convincing business email compromise can probe unpatched point-of-sale systems to install digital skimmers. The same synthetic identity that opens a fraudulent credit card account can exploit a payment authorization vulnerability discovered through automated scanning. Card-not-present fraud now accounts for 71% of all US card fraud losses, and the attack surface keeps expanding as digital wallets and e-commerce push more transactions into channels where physical card verification is impossible.

Attackers treat endpoint management gaps and transaction monitoring gaps as a single attack surface, while most defenders continue to patrol them as separate territories.

Fragmented command: The structural vulnerability AI exploits

Consider how most financial institutions, crypto platforms and digital asset intermediaries actually organize their defenses: A cybersecurity team focused on identity compromise, endpoint protection and infrastructure threats; a fraud team focused on account takeover, mule networks and scam typologies; an AML or financial crimes team focused on wallet screening, sanctions exposure and suspicious activity reporting; and an AI risk or digital trust team, if one exists at all, focused on synthetic media, model abuse and impersonation. Each function has its own tooling, budget, reporting line and intelligence feeds. In crypto markets, where value can move irreversibly across wallets, chains, mixers, exchanges and OTC brokers in minutes, those silos create exploitable gaps between detection, attribution, interdiction and recovery.

A pig-butchering scam that begins on a dating app, migrates to WhatsApp, directs a victim to a fake crypto investment platform, and then launders proceeds through nested services and cross-chain bridges is not just a fraud event. It is also a cybersecurity event, a financial crimes event, an identity event, a platform abuse event and, increasingly, an AI-enabled social engineering event. Chainalysis reported that high-yield investment scams and pig-butchering schemes were among the most successful crypto scam types in 2024, while also noting growing use of AI in fraud and scams.

Research published by the University of California, Davis found that these schemes follow a staged lifecycle: Trust-building, fabricated investment returns, escalating deposits, withdrawal obstruction and re-targeting of victims after the initial loss. When each part of that lifecycle is monitored by a different team, the institution sees fragments of the attack rather than the economic system of the crime.

“Fraud no longer happens in isolated channels,” observes Jeff Li, Global Product & Designer Lead at Binance. “AI-powered scams move seamlessly across platforms, and payment systems, making fragmented defenses increasingly ineffective.” He believes that the future of security depends on unified intelligence — combining AI, real-time monitoring, secure infrastructure and cross-functional response mechanisms into a single coordinated defense system.

“We’ve invested heavily in AI-driven risk detection, real-time scam warnings and infrastructure to stay ahead of evolving threats, continues Li, claiming that from Q1 2025 to Q1 2026, these efforts helped Binance prevent over $10 billion in potential user losses and protected more than 5 million users globally. As AI continues to reshape both fraud and fraud prevention, the focus remains on building systems that can protect users, not just at scale, but in real time.

Unified command: From org chart to battle plan

Kikta’s assessment contains a contrarian detail worth teasing apart: “The good news is that a strong compliance program prioritizing depth of coverage and speed of enforcement will hold up against AI-enabled fraud,” he says. In a landscape saturated with predictions that existing defenses are obsolete, Kikta argues that the fundamentals of patch management, endpoint hygiene and compliance rigor still hold, provided the clock speed at which those fundamentals execute keeps pace with the adversary.

That clock speed is the operational link between cybersecurity and card fraud prevention. An unpatched point-of-sale terminal or payment gateway exposed for 30 days represents 30 days of reconnaissance opportunity for an AI scanner probing for places to install a digital skimmer or intercept card data in transit. A compliance gap in identity verification is an open invitation for synthetic identities to open accounts and run fraudulent transactions. Endpoint management data and transaction monitoring data describe the same attack surface from different angles, and fusing those streams into a single operational picture, the financial equivalent of a military intelligence fusion center, gives defenders something the current siloed structure cannot: Visibility into an attack developing across domains before it reaches the payment layer.

The value of that convergence extends beyond defense. A unified data layer across cyber, fraud and payments creates consolidated threat intelligence that can inform underwriting decisions, merchant risk scoring and product design. Organizations that treat converged security data as a business intelligence asset (not merely an operational feed) will find they have built something with commercial utility well beyond the security operations center.

Mascaro frames the prescription in terms that belong in a boardroom, not a SOC. “The real competitive advantage in fraud isn’t your AI stack,” he says. “It’s leadership’s clarity to unify risk disciplines that everyone else keeps in separate departments.”

Field manual: What winning institutions do differently

The institutions gaining ground in this new form of asymmetric conflict share a common operational posture: They treat endpoint management as card fraud prevention rather than IT maintenance, and they feed cyber, fraud and payments intelligence into a single picture rather than three separate briefings. The defensive AI advantage, such as it is, comes from that integration, not from any single model’s sophistication.

Adversaries have already unified their operations. Yet, payment processors and financial institutions that keep running separate campaigns on separate fronts, with separate intelligence, will keep conducting after-action reviews of battles they have already lost.

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

For the past three years, the AI conversation has been dominated by scale. Bigger models, bigger compute clusters, bigger headlines. But the next wave of competitive advantage won’t come from who can rent the biggest model; it will come from who can build the smallest one that knows their business.

That model is the small language model (SLM): Compact, purpose-built, trained on an organization’s own data and run under that organization’s own governance. And it is about to become one of the most consequential strategic assets available to both the private and public sector.

The problem with renting intelligence

Right now, most organizations consume AI the way they once consumed electricity from a single utility by plugging into a handful of frontier models built by a small number of global vendors. These models are extraordinary generalists. They are also, by design, generic. They are tuned to be safe, broad and useful to everyone, which means they are optimised for no one in particular.

That’s a problem for any organization trying to build genuine differentiation. If every competitor in your sector is calling the same foundation model with the same prompts, the model itself is not your edge. Your edge is what only you know, your proprietary data, your institutional judgement, your operating history. A generic model can’t see any of that unless you keep feeding it to them, turn after turn, at cost, with no lasting memory and no guarantee of where that data ends up.

An SLM flips that equation. Trained on an organization’s own document libraries, case histories, policy archives, transaction data and operational know-how, it becomes a model that thinks the way your organization thinks, because it was built from your organization’s accumulated judgement. It doesn’t need to be the smartest model in the world. It needs to be the most useful one for you.

I’ve seen this play out directly. At one of Australia’s largest integrated tourism and cruise businesses, simultaneously a B2C retailer, a B2B distributor to thousands of agency and wholesale clients globally, an aggregator marketplace for more than 1,800 independent tourism operators, and a cruise operator with offshore shared services spanning finance, customer contact and content management. The constraint wasn’t a lack of access to large general-purpose models. It was that none of them understood the business: 1,800 different operator catalogues, each with its own pricing logic, inventory quirks and content conventions; years of customer contact history with its own vocabulary and escalation patterns; a marketplace search experience that needed to reason over the business’s own product taxonomy, not the open web’s.

Models trained and tuned on that proprietary data, operator listings, historical tickets, booking and pricing data delivered results a generic model never could. Domain-tuned content drafting cut operator listing time by 70% and eliminated a 23-day onboarding backlog outright, taking new-operator time-to-live from 23 days to three. A semantic search model trained on the marketplace’s own product catalogue lifted booking conversion by 24%. AI-driven triage trained on the business’s own contact history cut Tier 1 escalations by 34%. None of this came from a smarter foundation model. It came from a smaller, more specific one that knew the business.

Why “small” is the strategic choice, not the compromise

There’s a temptation to treat SLMs as the budget option, what you build when you can’t afford a frontier model. That’s the wrong frame. The evidence is already compelling: Microsoft’s Phi-4 family of small models, released in early 2025, demonstrated that a 14-billion-parameter model can match or exceed the performance of models many times its size on complex reasoning and domain-specific tasks while running at a fraction of the compute cost and on-premise, entirely within an organization’s own infrastructure. Smaller, domain-trained models are increasingly outperforming general-purpose giants on narrow, high-value tasks, with far tighter control over data residency, security and explainability.

For a CIO or CTO, that combination of lower cost, tighter governance, higher task-specific accuracy is rare enough to demand attention on its own. But the deeper value sits one layer up, at the operating model. An SLM trained on your service history can sit inside claims processing, citizen services, clinical triage, asset maintenance scheduling or M&A due diligence quietly compounding institutional knowledge into a reusable asset rather than letting it walk out the door every time someone retires or resigns.

That is the real shift: AI capability stops being a subscription and starts being a balance-sheet asset. It can be valued, protected, audited and improved because it belongs to you.

The public sector’s hidden advantage

Nowhere is this more obvious than in government. The public sector sits on some of the richest, least-exploited data and institutional knowledge in the country: Decades of policy outcomes, service delivery history, regulatory precedent, infrastructure records and frontline expertise. Most of it has never been put to systematic use because no commercially available model was ever trusted to touch it, and rightly so.

A small, sovereign, purpose-built model changes that calculus. Trained, hosted and governed entirely within government infrastructure, an SLM doesn’t require sensitive citizen or policy data to leave a secure perimeter. The Australian Government has already recognised this direction: The APS AI Plan, released in November 2025, commits to expanding the GovAI platform to provide all public servants with secure, sovereign AI tools operating entirely within Australian Government infrastructure. SLMs tuned to individual agency mandates are the logical next step and a more powerful one than any generic government-wide tool can deliver.

Rather than each agency independently negotiating with the same handful of overseas vendors, a coordinated approach of common standards for model governance, shared security architecture, common evaluation frameworks and pooled infrastructure investment would let agencies build and reuse SLM capability horizontally, the way shared services and common ICT platforms have been built before. Each agency gets a model genuinely tuned to its mandate, but the security model, audit trail and assurance framework are consistent, government-backed and independently verifiable.

Done well, this isn’t just an efficiency play. It’s a sovereignty play. As GovTech Review has noted, large language models hosted offshore create data flows that extend beyond Australia’s borders in ways that are rarely transparent, a risk that is simply untenable for government. Sovereign, purpose-built models keep Australian public data, public knowledge and the resulting capability uplift inside Australian hands, rather than exporting both the data and the long-term value to offshore platforms.

Why this belongs in the innovation budget, not the IT budget

The instinct in many organizations is to treat AI spend as an IT line item, something to be minimised, benchmarked and squeezed for cost efficiency. SLMs deserve a different treatment. They are closer to R&D than infrastructure: An investment in converting accumulated institutional knowledge into a durable, defensible capability.

That argument holds in the private sector too. A PE-backed portfolio company, a regulated financial services firm, a healthcare provider — each has years of proprietary operating data sitting idle in case files, transaction logs and service records. An SLM built on that data is a way of turning a sunk cost, decades of operational history, into a forward-looking asset that compounds with every additional case it processes.

Boards and executive committees that are still asking “what is our AI strategy?” as a single, undifferentiated question are asking the wrong thing. The better question is: Which parts of our operation are rich enough in proprietary data and judgement to justify owning the model outright, rather than renting someone else’s?

The opportunity in front of us

The first wave of enterprise AI adoption was about access: Getting a capable model into people’s hands quickly. The next wave will be about ownership: Who controls the model, who controls the data it was built on, and who captures the long-term value of the institutional knowledge it encodes.

Australia, with a public sector rich in data and a private sector with deep vertical expertise in financial services, resources, healthcare and logistics, is well placed to lead on this if it treats small, sovereign models as a genuine national capability question, not a procurement footnote. The organizations, and the country, that move early will not just save money. They will own something their competitors can’t easily replicate: An AI that knows them.

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

Technology executives from across the New York metropolitan area gathered July 16 at Convene, One Liberty Plaza, for CIO 100 Leadership Live New York, a full day of roundtables and panel discussions on enterprise AI investment, governance, and organizational change.

Several key areas of consensus emerged throughout this highly interactive event. Infrastructure fragmentation continues to block the path to securing returns on AI investments prompting leaders to understand rising cloud spend attributed to large language model utilization. This has caused a growing number of organizations to refocus on on-premises and hybrid options in C-suite and board-level capital planning conversations. Speakers, along with comments from the audience, described a shift from project thinking to product thinking, with smaller multidisciplinary teams moving faster than legacy structures.

Several participants repeatedly warned that automating broken processes just amplifies dysfunction. Governance and measurement remain unresolved, with usage metrics still getting mistaken for business value. One of the panels explored how CIOs may benefit from applying venture capital-style scrutiny to enterprise bets, weighing team execution as heavily as the technology itself. The throughline was a redefinition of the CIO role, from technology executor to business strategist fluent in revenue, board engagement, and transformation ownership.

Morning roundtable tackles AI infrastructure

The day opened with an invitation-only executive breakfast roundtable, “Beyond the Pilot, Building the Infrastructure for Real AI Returns,” co-hosted by Unisys and Dell Technologies. Over a dozen executives representing major public and private sector organizations across the New York metropolitan area joined Steve Hollander, senior director of Americas global alliances at Dell Technologies, and Matt Marshall, CIO at Unisys for a workshop-style discussion.

The session explored the strategic, operational, financial, and technological issues that must be mastered to optimize infrastructure decisions and separate organizations that are experimenting with AI from those competing on it. Discussion questions probed how CIOs measure whether AI investment is translating into business results, how they can break the cycle of fragmented and siloed AI deployments, how boards are beginning to scrutinize seven-figure token spend and whether on-premises or hybrid infrastructure can rein in costs.

The take-home point: the organizations pulling ahead are the ones that stopped treating AI as four separate problems, strategic, operational, financial, technological, owned by four separate functions, and started running it as one coordinated decision. Fragmentation is the actual cost center here, not the token spend itself. A CIO who solves the infrastructure question in isolation from the governance question, or the cost question in isolation from the talent question, ends up optimizing one silo while the other three keep bleeding value. Competing on AI, instead of just experimenting with it, means the finance, operations, technology and business sides are reasoning from the same picture of what’s being built and why, so the tradeoffs get made once, together, instead of getting re-litigated at every handoff.

Forum sessions open with a mandate for growth

Following breakfast, the main forum program began with “The New CIO Mandate, Delivering Growth, Not Just Technology.” In a moderated conversation, Laksh Nathan, chief information officer at Paramount Skydance, drew on his experience with mergers, enterprise transformation and AI-enabled development to describe a shift from project and application management toward a product-centric operating model. Nathan addressed how smaller, multidisciplinary teams are changing expectations on both the business and technology sides of the enterprise, and what mindset changes CIOs must lead to turn AI into an engine of growth rather than a cost center.

PwC followed with a session on “Designing the Intelligent Enterprise, From AI Investment to Evolving Operations.” Darren O’Meara, principal and chief technology officer for managed services, and Meghna Shah, principal for engineering and AI, examined why fragmented outcomes persist even after heavy investment in technology and transformation.

The intelligent enterprise, they posited, is less about working toward achieving specific technology outcomes and more about creating operating models that integrate strategy, technology, operations, and governance into one system. This, they explained, requires linking AI, data, and decisions across the business and will leave an indelible mark on how decision rights are redesigned, funding models are developed, and accountability is enforced to accommodate the speed of the agentic economy.

Talent, tradeoffs, and the cost of getting it wrong

The session “Return on Transformation: Time, Talent, and Tradeoffs” — with Prashant Hinge, chief information and transformation officer at MSIG USA; Joseph Gimigliano, chief technology officer at Northwell Health; and Eduard de Vries Sands, AI executive advisor at PatientPoint — examined why transformation initiatives so often lose their way.

The main culprit, even today in 2026, continues to revolve around a persistent instinct for technology implementations to become the objective rather than the means to a measurable business outcome. The panelists made the case for doing the incredibly difficult work of re-engineering (if not entirely re-imagining) existing processes before automating them and then placing smaller bets inside that bigger vision.

Ricky Thakrar, head of sales and account management at Zoho, took the stage to present “Smaller, Smarter, Safer, The Enterprise AI Architecture Most Leaders Get Backwards,” arguing that constrained, context-rich architectures consistently outperform expensive models bolted onto fragmented systems.

A round of Hot Topic Discussion Groups and a networking lunch followed, including the Next CIO Luncheon featuring Robert Half Regional Director Jason Deneu.

Afternoon sessions turn to security, scale, and investment signals

CSO and CIO Contributor Joan Goodchild moderated “Securing Trust in the Agentic Economy,” a discussion with Marlowe Cochran, CISO at the New York State Education Department, and Gee Rittenhouse, vice president of security services at AWS, on how organizations are balancing speed, innovation and security as AI agents move from experimentation into productization at scale.

Rittenhouse framed agentic risk as closer to human risk than traditional software risk, describing how an independent agent acting in a non-deterministic way really does look like a potential insider threat, pushing CISOs toward behavioral monitoring over static workload protection. He tied this to a structural shift in defense, noting it’s hard to do agentic security if you’re not observing it, putting observability at the center of agentic risk management.

Cochran concurred, adding that many of the key tools that are needed to move into the agentic economy already exist, but must be implemented more aggressively, comprehensively and even more creatively. CISOs don’t need to invent an entirely new security discipline for the agentic era so much as extend identity management, access control and monitoring frameworks they already run to cover a new class of non-human actor — agents.

A session on “AI, From Experimentation to Enterprise Impact” brought together Meagan Gentry, national AI practice manager and distinguished technologist at Insight and Yuri Gubin, chief technology officer at DataArt, for a candid look at why pilots stall before reaching scaled production and what operating capabilities, governance, cost visibility, continuous education, must be in place to sustain AI once a proof of concept works.

During the session’s Q&A segment, a discussion emerged around how proof-of-concept success can result in a false signal, raising questions about whether pilots should be considered successful before the intended outcomes have had time to materialize, and drawing a distinction between measuring usage and adoption versus measuring business value.

The panelists explored how CIOs can identify the small number of transformational AI opportunities worth pursuing rather than managing hundreds of incremental use cases, and even challenged whether prioritization is the CIO’s job at all. The discussion closed on a sequencing question with real strategic weight, whether AI-first strategies are putting the technology ahead of the business problem CIOs are trying to solve, and what role CIOs should play with boards in defining the outcomes AI is expected to support.

A shift in perspectives

The “Think Like a VC, Investment Shifts Towards Focused AI Applications” session featured three venture investors, Aaron Darr, partner at Lead Edge; Isabelle Phelps, partner at Lerer Hippeau; and Marshall Porter, general partner at AlleyCorp. The panel explored how investors evaluate risk and talent in a market where products and competitive positions can shift within months, and what separates a focused AI application with durable enterprise value from an AI wrapper built to chase a trend.

The panel challenged the enterprise instinct to seek certainty in a market moving this fast, questioning whether CIOs should stop looking for technologies that will future-proof the enterprise and instead grow more comfortable continuously reassessing their bets. Investors framed this as a deliberate departure from the traditional low-tolerance-for-failure posture that has long governed enterprise technology purchasing, arguing that the search for certainty has itself become a risk in a market where products and business models can shift within months. The discussion pressed CIOs to weigh how they can adopt a more dynamic investment mindset without compromising the enterprise security, governance and accountability their organizations still depend on.

A Lightning Insights followed, featuring five-minute briefings from Insight, Platform9 and Console, followed by Keystone Senior Principal Ellora Sarkar’s talk on why most enterprise AI investment fails to produce measurable value and what separates the small share of firms capturing real return on investment from the majority still stuck in pilots.

Closing the day

The forum closed with “What’s Next for the CIO, Preparing for the Next 12 to 24 Months,” a fireside conversation with Leif Maiorini, CIO for corporate services at Omnicom. Maiorini discussed why business processes need to be redesigned for agentic speed rather than automated around existing human workflows, how organizational structures may shift as autonomous agents reshape visibility and decision support, and where sustainable differentiation will come from once AI capability itself becomes widely accessible.

Maiorini encouraged the industry to clearly distinguish between nondifferentiated services that should be made as efficient as possible and the differentiated capabilities that actually influence why customers choose to do business with an organization, once the major efficiency gains from optimization and AI have been captured.

He was candid about the governance gap agentic systems open up, noting that agents lack the professional reputation, personal accountability and inherent constraints that shape human behavior, which creates new risk when autonomous decisions occur at machine speed. That combination, reinvesting efficiency gains into genuine differentiation while building governance models suited to non-human decision-makers, framed his closing case for why human creativity and judgment remain the enterprise’s most durable asset even as the underlying technology becomes commoditized.

Join the CIO 100 Awards & Conference Aug 17–19, 2026 at Omni PGA Frisco Resort & Spa, Frisco, TX — where top IT leaders celebrate innovation and connect.  Learn more to attend or partner.

Apple’s recently announced $30 billion multi-year agreement with Broadcom is significant because it means billions of chips for Apple devices will be made in the US, supporting hundreds of jobs. 

This is Apple’s biggest US procurement deal so far, but it won’t be the last; when it announced the arrangement, Apple confirmed it is, “working with the administration and businesses across the US to help create an end-to-end silicon supply chain in America.”

That statement implies that the 15 billion chips Broadcom will produce won’t be the only processors in Apple devices to carry tiny little “Made in the USA” slogans. Broadcom is making custom silicon components and wireless connectivity technologies such as RF/wireless chips (Wi-Fi, Bluetooth, cellular, FBAR filters) and ASIC work, rather than application processors. But they are still chips for Apple devices.

TSMC doubles down

That’s why it is significant that TSMC confirmed plans to extend its own manufacturing in America. It already has a $165 billion US commitment; now, it is investing an additional $100 billion in four more chip plants — including one dedicated to churning out the company’s most advanced 2nm (and smaller) processors. 

“We believe this investment will help to further foster the development of the US semiconductor ecosystem, strengthen the supply chain, and support an increasing number of high-tech, high-paying jobs in the United States,”  CEO C.C. Wei told analysts.

TSMC has also confirmed plans to invest in packaging facilities for processors, which is basically the process where memory, processor, and networking nodes can all be combined and packaged on the chip. That sort of packaging is needed to make the final SoC chip. That means TSMC factories in the US will be able to churn out the advanced processors used in Apple’s current and, presumably, future devices.

The bill so far

That’s three investments — in processor manufacturing, packaging, and Broadcom radios and chips — all of which are strategically important to Apple devices. TSMC makes the brains, Broadcom brings the connectivity. Total value so far: $295 billion, around 1.5 times Apple’s annual revenue in the Americas.

It isn’t all about Apple. TSMC has other clients, and Apple is no longer the company’s biggest customer thanks to the drive to AI. But it is still an important one. That means at least some of TSMC’s newly invested US manufacturing capacity will be dedicated to making chips for Apple. The open question is how much US-manufactured chips will cost in contrast to those made elsewhere.

It’s bigger than two deals

These aren’t the only chip-focused partnerships Apple has made domestically. Apple’s American Manufacturing Program (AMP) launched in August 2025 as part of a $600 billion four-year US investment commitment. TSMC and Broadcom were both named AMP partners, but they weren’t alone, and some arrangements have already been announced:

• GlobalFoundries is bringing mixed-signal chip manufacturing to make advanced ICs for Face ID.
• Texas Instruments expanded production for analog/power chips.
• Samsung is making a new chip-making process at its Austin, TX fab, described by Apple as having “never been used before anywhere in the world.”
• Apple became the “first and largest customer” of Amkor’s new advanced packaging/test facility in Arizona.
• Corning is expanding glass production.
• Applied Materials is making chip manufacturing equipment under AMP.

Bundle all these deals together and it’s crystal clear that Apple’s $600 billion investment is at least in part focused on the technologically advanced components on which its devices are built. These components also have the advantage in being incredibly small, which means they are easy and cheap to ship for final assembly at increasingly automated final production locations worldwide. 

So, is it coming home?

That’s the strategy: keep the high-value, hard-to-automate work — and the jobs it requires — in America, while leaving final assembly flexible enough to go wherever that makes sense now or in the future. Is Apple bringing manufacturing home? Partially, in that the bits that matter the most — brains and networking— are coming back, even if assembly is not.

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.

It’s not so much generosity that’s behind Anthropic’s decision to extend free access to its most advanced model, Fable, for paid subscribers until July 19, analysts say. Its a last-minute move to grab users, data and model evaluation results.

After the free-access period, Anthropic plans to convert Fable to a pay-per-use model, at $10 per million input tokens and a whopping $50 for 1 million output tokens.

That is double the price of its next most advanced model, Opus 4.8, for input and output tokens. “We’re extending Claude Fable 5 access on all paid plans, as well as keeping Claude Code’s weekly rate limits 50% higher, through July 19,” Anthropic’s team said in a July 12 tweet.

Anthropic keeps extending Fable because it does not yet know what its flagship is worth, said Sanchit Vir Gogia, principal analyst at Greyhound Research. “A vendor confident in its price does not move the same cutoff twice in six days, both times at the wire,” Gogia said.

Anthropic is essentially pushing deadlines to test its products, while users gain by being able to put their toughest tasks to Fable, Gogia said.

Anthropic, which did not immediately reply to a request for comment about the situation, has already seen plenty of action with Fable and its sister model Mythos. Both have been touted as the company’s most advanced models yet.

Fable stumbles, then reappears

Fable was officially launched June 9. Just three days later, on June 12, the US government put export controls on it after Amazon researchers bypassed Fable’s safeguards, prompting the model to identify software vulnerabilities and demonstrate an exploit. 

After Anthropic scrambled to address the issues — and after the export controls were lifted — Fable was relaunched July 1.

Fable’s freebie extension comes after OpenAI’s latest model, ChatGPT 5.6 Sol, became generally available July 9. Sol is cheaper at $5 per one million tokens input, and $30 for 1 million output tokens.

Anthropic and OpenAI are competing aggressively to build market share, said Jack Gold, principal analyst at J. Gold Associates. “Anthropic and OpenAI are looking to go public and the more users they have, the more attractive it is — even if they are not yet producing income,” he said.

In some ways, the two companies are following a well-trodden path to get customers hooked on their products and turned into paying customers. That’s what Meta, Google and Microsoft, for instance, have done over the years with various “free” offers that later morphed into paid products. 

Plus, said Gold, ”The more users you have, the better you can train your models across multiple data sets.”

That’s a potential boon for proprietary large language model (LLM) vendors offering free tokens in a bid to lock enterprises and vendors into their AI environments. But numerous experts have warned enterprises not to fall for that tactic. Instead, they argue enterprises should diversify AI development across multiple AI and cloud vendors, and adopt open-source models.

An LLM space race?

According to LLM benchmarks maintained by Artificial Analysis, Fable is the most intelligent model currently available, with Sol just behind it in second place. One benchmark by LiveBench places Sol as being better in reasoning, with Fable better at math, data analysis, instruction following and language. Both models have advantages in coding.

Meanwhile, Cursor and SpaceXAI on July 8 unveiled Grok 4.5, which the companies said can “handle difficult, long-running tasks that require creatively using tools to solve problems, whether in software engineering, data science, finance, legal work, or anything else you do on a computer,” the company said in a blog entry.

Its pricing is even more aggressive than Fable and ChatGPT 5.6 Sol. Grok 4.5 charges $2 for 1 million input tokens and $6 for 1 million output tokens.

There are growing concerns about tokenmaxxing, where enterprises rack up billions of dollars in token spending, blowing past usage limits before finance controls are implemented.

Enterprises might decide to spend more on models such as Mythos and Fable — if the benefits are tangible, said Max Leaming, head of data science and AI solutions at ManpowerGroup. Fable and Mythos may “actually be less expensive to use in spite of the spiked token cost because it’s far more efficient,” he said.

A company might find that the models use fewer tokens, are faster, and can reduce compute time, he said. “Even though the per-token costs may go up, we may see overall costs go down,” Leaming said.

Every major sporting and pop culture event creates a familiar conversation among employers: How much productivity will be lost?

This year’s FIFA World Cup was no exception. Before the tournament began, UKG research found that 37% of employees globally planned to adjust their work schedules during the tournament. Some intended to take time off. Others expected to arrive late, leave early, or otherwise alter their work patterns. The estimated global productivity loss from presentism and absenteeism ranged from $17 billion (UKG) to an astonishing $30.2B (Challenger, Gray & Christmas).

As tournament play began, viewership surged across broadcast and streaming platforms: FOX Sports reported record audiences, while Peacock and Telemundo viewership increased more than 230% compared to the 2022 tournament through the first 12 matches.

Those numbers are interesting, but, as a CIO, I think they point to a more important question: Why do events like this still disrupt organizations in the first place?

The World Cup is unique because it is one of the few workforce disruptions we can see coming years in advance, and the tournament game schedule is a blend of predictable (pool play) and unpredictable (knockout stage). We know employees will modify schedules. We know customer-demand patterns will shift. We know some industries will experience staffing challenges while others see increased activity.

None of this is a surprise.

That is what makes the UKG survey results so interesting. They reveal a broader truth: Even when change is predictable, many organizations still struggle to prepare for it effectively.

The issue is rarely a lack of data. Most organizations have access to workforce, operational, financial and customer information. The challenge is that those signals often live in disconnected systems, making it difficult to translate information into action before problems emerge.

In my experience, this is where many operating models begin to break down.

Organizations need to optimize operations for adaptability

For years, organizations optimized for efficiency, standardization and predictability. Those priorities helped businesses scale, but they also created processes that can struggle when conditions change. Increasingly, the ability to adapt is becoming just as important as the ability to execute efficiently.

Adaptability is often discussed in the context of unexpected events, but many operational challenges are highly predictable. Major sporting events, seasonal demand fluctuations, weather patterns, holiday periods and workforce trends all generate signals organizations can anticipate.

The question is not whether the information exists. The question is whether organizations can connect workforce, operational, financial and customer data in a way that allows leaders to act on those signals before they become problems.

This is where technology leaders have an important role to play.

Access to real-time insights leads to agile decision making

As CIOs, we are increasingly responsible for creating the conditions that allow organizations to sense changes, make decisions and respond quickly. That requires more than modern technology. It requires connected data, simplified processes and operating models designed to support faster decision making across the business.

When workforce planning, scheduling, labor costs, customer demand and operational performance exist in separate systems, organizations spend their time reconciling information. When those signals are connected, they can spend their time making decisions.

This is also where AI has the potential to create significant value. Much of today’s conversation focuses on productivity gains, but I believe the larger opportunity is responsiveness.

Organizations generate millions of operational signals every day. AI can help process those signals, identify patterns, surface risks and recommend actions faster than traditional approaches. The value is not simply producing more insights. The value is helping organizations shorten the distance between awareness and action.

When AI is combined with connected data and embedded into operational workflows, it can help leaders respond to changing conditions with greater speed and confidence. That is ultimately what organizations need: not perfect predictions, but the ability to make better decisions faster.

Three questions to ask right now to test operational effectiveness

For CIOs, the World Cup offers an interesting stress test. It creates a visible, measurable change in workforce behavior, but the lessons extend far beyond a sporting event. I think there are three questions every technology leader should consider:

1. Can we identify operational changes as they happen, or only after they appear in reports?
2. Can our teams make decisions quickly when conditions change?
3. Are our systems helping employees adapt, or creating additional complexity when flexibility is required?

The answers often reveal more about organizational readiness than any technology roadmap.

Operational excellence means moving from information to action

Eventually, the tournament will end. The broader challenge it exposes will remain. Workforce expectations will continue to evolve. Economic conditions will continue to change. New technologies will continue to reshape how organizations operate.

Organizations cannot predict every disruption. But they should be able to prepare for the ones they can see coming.

The World Cup is a reminder that operational excellence is not just about responding to change. It is about recognizing signals early, connecting information across the business, and acting before predictable challenges become operational problems.

In my experience, the companies that do this well are not necessarily the ones with the most detailed plans. They are the ones with the clearest visibility, the simplest operating models and the ability to turn information into action quickly. Increasingly, that is what modern operational excellence looks like.

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

IBM has bolstered its Power server portfolio with a new edge S1112 server and announced IBM Power Autonomous Operations, an AI agent that helps customers monitor Power systems and autonomously resolve issues to keep operations running smoothly. Additional software upgrades are aimed at helping customers deploy and manage AI infrastructure components. 

“Each announcement addresses a different layer of the enterprise technology stack, from how infrastructure is deployed and managed to how applications are developed, modernized, and optimized,” wrote Brandon Pederson, senior IBM i product manager, in a blog post about the new products. “Together, they reinforce a broader direction for IBM Power of helping clients move from manually operated infrastructure toward intelligent, resilient, and AI-assisted systems that are easier to manage, easier to modernize, and ready for new workloads.” 

The new IBM Power S1112 is a one‑socket Power11 server engineered for IBM i, AIX, and Linux. Aimed at distributed and edge locations, it is Big Blue’s new entry-level i server and is AI‑ready by design, integrating on‑chip Matrix Math Acceleration (MMA) for fast inferencing and other AI‑driven use cases, such as support for AI-assisted decisions, automation, and analytics close to where data is generated and consumed, Pederson stated.

The server supports two configurations: a 10-core 3.05 to 4.0 Ghz Power11 Processor in a rack version only, and a 4-core 3.60 to 4.0 Ghz Power11 in rack and tower form factors, IBM stated.

“For IBM i clients, Power S1112 is especially important because it expands what entry IBM i environments can do. IBM i P05 clients can run IBM i partitions within the P05 software tier while also using additional system resources for AIX, Linux, VIOS, AI, or open-source workloads on the same server,” Pederson wrote. “This creates a flexible path to consolidate workloads, improve utilization, and support modernization without forcing clients into a larger platform than they need.”

Announced: IBM Power Autonomous Operations

On the software side, IBM Power Autonomous Operations offers automation capabilities via an embedded AI agent that offers natural language interactions designed to help customers manage, tune, and streamline their environments without relying on deep domain expertise for every task, Pederson stated.

“IBM Power Autonomous Operations is designed to continuously monitor, optimize, protect, and manage Power environments. It combines Power telemetry, AI-powered analytics, automation, and operational workflows into a unified experience that helps IT teams reduce complexity, improve resiliency, and increase productivity,” Pederson wrote. 

“Rather than simply showing operators what is happening, Power Autonomous Operations is designed to help teams decide what to do next. The platform analyzes system telemetry, identifies risks and optimization opportunities, and provides intelligent recommendations or automated actions to improve performance, resiliency, and operational efficiency,” Pederson wrote.

Agentic Engine for IBM i

IBM also issued a preview of the Agentic Engine for IBM i, which is aimed at providing greater AI support for Power systems. 

IBM described the Agentic Engine as a new enablement layer designed to make it easier to adopt native and integrated AI agents into IBM i workloads and business processes. The engine provides the runtime, IBM i Knowledge Pack, observability, extensibility, MCP server, and foundational agents that help teams build trusted agents for IBM i without starting from scratch. Developers can build agents using their preferred coding tools, run them close to Db2 for i data under native IBM i object-level authority, and extend them into broader enterprise workflows through APIs and agent-to-agent integration.

With security, governance, and instrumentation built in, the Agentic Engine for IBM i helps organizations manage agent behavior, monitor activity, and support responsible adoption across mission-critical environments, Pederson stated.

IBM Bob Premium Package for i

Also in the AI agent vein, IBM announced support for its Bob AI application development environment for the i system. The idea here is to help customers quickly modernize applications built on RPG and COBOL.

“These capabilities help developers explain complex RPG and COBOL programs, convert Fixed-Format RPG to modern Free-Format RPG, refactor monolithic applications into modular structures, generate RPG, CL, COBOL and DDS code, create technical documentation, and produce unit tests to support validation,” Pederson wrote. “Rather than relying on generic prompts and inconsistent results, IBM i teams can use expert-built skills that deliver more predictable, repeatable and higher-quality outcomes. Agentic workflows help guide multi-step development tasks from understanding and planning through implementation and validation, allowing developers to modernize incrementally without losing control.”

IBM also added new development features to the core operating system for i with IBM i 7.6 Technology Refresh 2 and i 7.5 Technology Refresh 8 that include a variety of features designed to enhance RPG and COBOL development, security, and hybrid cloud integration.

IBM Power S1112 is expected to be generally available on July 24, IBM Power Autonomous Operations is expected to be generally available on September 23, 2026, and IBM Bob Premium Package for i was made generally available on June 24, 2026.

Oracle on Tuesday expanded its AI Agent Studio for Fusion Applications with new pro-code development tools, including a CLI-based capability called AI Studio Skill, allowing developers to build agentic applications using familiar environments such as VS Code, Codex, and Claude Code.

The AI Studio Skill is the CLI that provides the Fusion-specific context and tooling that AI coding assistants need to build Fusion-native applications. It provides access to the project structure, APIs, templates, validation, packaging, and deployment workflows required for Fusion Agentic Applications, Natalia Rachelson, SVP of product for Fusion Applications at Oracle, told InfoWorld.

“Think of it as Oracle’s development harness for popular AI coding assistants. Developers can use models like Codex or Claude Code to generate code, while the AI Studio Skill connects those models to Oracle AI Agent Studio and the Fusion runtime,” Rachelson said.

Familiar tools and workflows to simplify development

The access to familiar IDEs and harnesses, according to analysts, will make it easier for developers to build and maintain agentic applications for business workflows.

“The AI Studio Skill provides developers a way to build Fusion agents like a new software function versus configuring them like application extensions,” said Scott Bickley, advisory fellow at Info-Tech Research Group.

“Enterprise developers expect source control, code review, repeatable deployments, testing or debugging, and integration into their existing toolchains. Connecting the various IDEs and code assist products will make it easier to build, validate, and maintain agentic applications using already familiar tools and processes. This ostensibly will result in agents that are easier to maintain, govern, and align with enterprise development practices,” Bickley added.

For Robert Kramer, managing partner at KramerERP, the move is likely to drive more adoption of the Studio itself: “Oracle is meeting developers where they already work and making Fusion a more attractive place to build agentic applications.”

Native runtime could aid governance in production deployments

However, the CLI and IDE integrations, for Bickley, extend beyond developer productivity into tackling the governance and execution challenges that often prevent AI prototypes from reaching production.

“One of the most painful barriers to production AI is that many prototypes are built outside the enterprise systems where identity, permissions, workflow approvals, and overall system governance are already built in,” Bickley said.

In contrast, the integrations will allow enterprises to run agentic applications from inside Oracle’s platform, leveraging existing business context, identity, approvals, and governance rather than recreating those capabilities through external orchestration layers when moving them into production, Bickley added.

That shift, the analyst further added, will prove beneficial for CIOs because it will accelerate business outcomes while operating within a trusted environment.

Governance, observability, and lifecycle management matter more to CIOs after agentic applications move into production, Kramer echoed.

Governance gains come with strategic trade-offs

The approach of building and running agentic applications natively inside Oracle Fusion, though, is not without trade-offs, analysts cautioned.

CIOs should pay close attention to vendor lock-in as more business processes become agentic, Bickley pointed out.

“In the case of Oracle Fusion, ensure the ATLAS framework provides an accurate validation layer at a low cost of overhead. Consider the levers that Oracle may avail itself of contractually or commercially in the future,” Bickley said.

“ROI should be modeled against a progressive monetization schema as AI agents operate upon a consumption-based infrastructure.  As such, ensure provisions limiting cost overlays and uplifts are agreed upon prior to locking in,” Bickley added.

These considerations, the analyst further added, are becoming increasingly relevant because most enterprise software vendors, including the likes of SAP and ServiceNow, are introducing offerings and features to become the runtime and orchestration layer for enterprise AI.

Earlier in May, SAP expanded its AI strategy with the Autonomous Enterprise vision, introducing a unified Business AI Platform, Joule Studio 2.0, and AI Agent Hub to let enterprises build, govern, and run AI agents within a managed runtime.

In June, ServiceNow expanded its AI transformation by adding new features to its Context Engine and AI Control Tower, in order to better embed governance, enterprise context, and observability into AI workflows across enterprise systems.

During the same month, Salesforce, via its Informatica acquisition, added features to tie AI agents more closely to trusted enterprise data and operational workflows.

For developers and enterprises willing to try out the new CLI-based experience, it can be accessed from within the Studio without any additional cost, Oracle said.

The company is also adding a public GitHub repository that it said will provide templates, starter projects, sample applications, reusable assets, and reference architectures to help developers build and validate agentic applications faster.

Gen AI spending is moving beyond the familiar software model of seats, licenses, and pilots. As AI shifts from copilots to embedded workflows and autonomous agents, one user request can trigger multiple model calls, retrieval steps, retries, orchestration layers, and infrastructure events. A tool that looks affordable in pilot may behave very differently once connected to production systems or allowed to act with less human supervision.

According to Michael Corrigan, CIO of World Insurance Associates, AI introduces a fundamentally different cost model — one that’s usage driven, non-linear, and tightly coupled to business activity. “Success requires shifting from traditional IT budgeting to FinOps-style discipline where consumption, value, and governance are actively managed in real time,” he says.

Here are five ways CIOs can build that discipline before AI costs spiral.

Forecast AI by workflow, not by user

At World, a top 25 insurance broker with about 3,000 employees across roughly 300 locations, AI use falls into three broad categories, Corrigan says. One is broad tools, such as copilots. Another is embedded AI inside SaaS platforms. And the third is bespoke AI built around specific workflows and manual processes.

“The bespoke is the area that’s growing the most right now,” he says. “And that’s where the model, from a cost perspective, has really been shifting from a license seat cost to a token consumption or token burn cost, or even a hybrid.”

Seat-based pricing is relatively easy to forecast whereas consumption-based AI isn’t. Costs may depend on prompt complexity, output length, model choice, workflow design, and whether the system calls a model once or many times in the background.

World tries to manage that uncertainty by defining the business problem, success criteria, and expected operational improvement upfront. Pilots help estimate consumption before scaling, but Corrigan says they don’t remove the ambiguity.

“We’ll try our best in the pilot to understand what the consumption rate is, what the token burn rate is,” he says. But once a consumption-based workflow goes into production, he adds, an estimate is put into place. That estimate is informed, but still rough.

Elmer Morales, founder and CEO of koder.com, an agentic AI coding startup, says CIOs should think less about headcount and more about workflow mechanics. Agentic AI costs are driven by the number of decisions an agent makes, how often it retrieves external data, how much context it carries, and how many systems it touches.

“CIOs should start by mapping workflows, not necessarily users,” he says. “The relevant variable isn’t going to be the headcount but how many decisions an agent makes per task.”

Model the failure path, not just the happy path

Pilots can mislead because they often test the cleanest version of an AI workflow. Morales says many enterprises model agentic AI costs around the happy path: the user gives a clear prompt, the system understands the request, the agent completes the task, and the process ends. Production is messier.

“They generally don’t model for situations where the agent is going to need to go back and check its work and redo things,” Morales says. “A lot of times, agents are wrong, either because they hallucinate or they understood the problem incorrectly.”

In an agentic workflow, the system may check its work, call another tool, retrieve more data, or redo a step. While that may improve quality, it also adds cost.

The difference between copilots and agents is central. A copilot interaction is often one prompt and one response. An agentic workflow may involve agents moving through a decision tree, executing tasks in sequence or in parallel, and calling sub-agents or external systems along the way. “By the time it’s achieved the original goal, the agent might have made 50 or 100 model calls, compared with a single call for a traditional copilot prompt,” Morales says.

That’s why CIOs should require teams to model the failure path before production, like how many retries are allowed, how much context is resent, which tools can be called, when a human should intervene, and what happens when the agent can’t complete the task.

Build cost controls into the architecture

Traditional FinOps practices still matter, but AI requires more than retrospective dashboards and chargebacks.

According to Pavan Madduri, senior cloud platform engineer at industrial supply company Graigner, looking backward at usage data, as traditional FinOps often does, can be too late. Costs are shaped by prompt design, model selection, agent behavior, orchestration choices, and runtime loops.

“Dashboards or chargebacks, those are historical accounting,” he says. “The money’s already gone.” For AI, he argues, cost controls need to be embedded into the architecture. That includes hard token caps, retry-depth limits, maximum runtime limits, workload prioritization, background-job throttling, and cluster-level controls that prevent runaway consumption.

“The real FinOps means you need to have the cost constraints embedded into your architecture framework,” Madduri says.

Those controls also extend to infrastructure. Expensive GPUs may sit warm between jobs because systems need capacity available when inference demand arrives. Teams may pass huge schemas, databases, or thousands of lines of code into frontier models when a smaller or more focused prompt would do.

Enterprises should also adopt event-driven autoscaling, Madduri says. “Use tools like KEDA to scale GPU nodes down to zero the moment inference demand drops, so teams only pay for the windows when the silicon is actively crunching tokens.”

Corrigan says World uses rate limits, spend limits, alerts, and approval gateways for consumption-based tools. When users approach token consumption limits, automated alerts allow IT and the business to review whether the continued spend is justified.

“If it’s not meeting the success criteria we expected, you have to have the control in place to say we’re going to move on or kill that process,” Corrigan says.

Route work to the right model

CIOs can also reduce AI bill shock by avoiding a default assumption that every task requires the most powerful model available. While some tasks need advanced reasoning, many others don’t. A simple support ticket, log-parsing task, or structured database transaction may be handled by a smaller or cheaper model. A complex architecture decision, legal analysis, or multi-step reasoning task may justify a more powerful one.

“Choosing the right model for the right prompt and right question — that’s where you leverage the maximum from that model, and you can decrease the costing,” Madduri says. “If you default every single call to a frontier model, that’s architectural laziness.”

Morales makes a similar point. Not every step in an agentic workflow requires a top-of-the-line model. Model routing, he says, is the discipline of determining the best model for the task, and providing the relevant context when the model needs it.

According to Jim Olsen, CTO of enterprise software company ModelOp, CIOs should use the least expensive model that can accomplish the business goal. Using the biggest model for everything is easier, but expensive. “It’s like hiring the most expensive engineer to change a few colors in a website’s CSS, or visual styling,” he says. “You wouldn’t do that. You use the appropriate tools for the task.”

Tie consumption to business value

For Olsen, the deeper enterprise problem is AI value shock, not just bill shock. Spending $200,000 in a quarter on AI is justified if it produces $2 million in business value. The problem is spending heavily on use cases that don’t generate a meaningful return.

“Are you actually getting that return on investment, or are you just blowing tokens for something that’s not delivering the value to your business?” Olsen asks. Tracking token usage by user or department may show who consumed AI, but not whether the consumption mattered.

For most enterprise AI systems, Olsen says costs should be tied back to business use cases. A model may be used for HR document search, customer support, code review, problem resolution, or other functions. Each use case may draw on the same underlying models or agents, but the business value can be very different.

That’s why he argues that companies need an AI inventory, a record of which business workflows use which models, agents, providers, workflows, and systems. Without that inventory, enterprises can’t connect consumption to value.

Corrigan takes a similar approach from a governance perspective. At World, new AI ideas go through an intake process. Business users propose improvements, and IT, finance, operations, sales, and business stakeholders evaluate, prioritize, and monitor them from pilot through production.

That may be where the next stage of AI FinOps is heading, toward a clearer understanding of which AI consumption deserves to scale, not just to lower bills. So the question, as Olsen puts it, isn’t whether someone used a million tokens. It’s what are they using them for.

Apple has released the first public betas of its “27” series of operating systems, and feedback so far suggests they’re already very stable builds, even at this early end of the release cycle. 

For most intrepid public beta testers, the big attractions here are Siri AI and the heavily improved Apple Intelligence tools – though Siri AI is not yet available in Europe due to regulatory problems there. Overnight social media commentary has been highly positive, with Siri widely seen as delivering on what we always thought it should be rather than the limited product it became.

Caveat emptor

Once installed, the new operating system is fast and better performing on the iPhone, though there are some limitations anyone considering the beta should consider first:

• This is beta software; things can and sometimes do go wrong. So don’t install it on your primary device unless you know how to restore your device and its data.
• Some critical apps such as banking tools, VPNs and some smart home management software are reported to be unstable at times.
• Once the public beta is first installed, there’s a lengthy period during which your device will rebuild its database; this can take many hours and performance will be affected.
• As the OS beds in, users might experience sudden battery drain or the device might seem warmer than usual.
• You’ll need to join a lengthy Siri waitlist before you can install the updated Siri AI.
• Siri AI requires significant hardware capabilities and only runs on iPhone 15 Pro, iPhone 16 and iPhone 17 models. Alternatively, you must have an M1 or later Mac or an iPad running an M1 chip or later, or A17 Pro (iPad mini).

Siri AI is a big improvement

Siri AI is the big reward here. Joanna Stern called it “significantly better.” It will provide you with much better responses than its predecessor, and its contextual understanding is sophisticated and advanced. 

That’s because Siri can search across your messages, emails, photos and more to help you find what you’re looking for and has some understanding of where you are and what you are doing to help it make even more accurate decisions. It is faster than it’s ever been with a dedicated app (which includes logs of your interactions) and a new glowing design when activated. 

The assistant can now hold an ongoing conversation with you, understands what’s on screen, and take some actions in apps. One way that might be useful is if you are looking at a recipe online, you can ask Siri to write up a shopping list for the recipe ingredients and paste it in a Note. Siri has become much more knowledgeable than in the past thanks to its expanded and updated world knowledge database.

Apple Intelligence has been beefed up, too, with keyboard tools much improved on the last version. Siri can even reflect your personal tone and style based on the person you’re communicating with when sending a Mail or Messages post. 

Apple and the image

The Camera app now has a new Siri mode; it can do things like identify objects and people, or import event details from a leaflet. You can easily search or ask questions about what’s around you, and there are useful new actions you can take, such as getting nutritional insights about a plate of food.

Image Playground wasn’t terribly impressive when it first appeared, and a lot of people did little with it. It seems much better now, capable of generating photo-realistic images in virtually any style from natural language prompts or editing existing images. It’s a useful step up.

Another impressive feature is Spatial Reframing. This lets you shift the composition of a photo after you’ve taken it, using AI to create accurate renditions of what is outside the frame. A new Extend tool lets you expand images, which is useful for adjusting aspect ratios or creating Lock Screen wallpapers.

The future on your wrist

If you use an Apple Watch, you’ll be impressed, as the contextual AI extends to that device. So, you can have context-savvy conversations with your watch and ask it to do tasks on your behalf. It makes it feel like a bona fide computer on your wrist and bodes well for other future wearable products from the company. 

There are lots of other interesting features in the beta. Call Context can automatically surface the information you need, like a confirmation code or reservation number, when calling up a business. And a new Notify Me feature in Safari lets you know when a web page changes, so you can watch for stock availability or ticket sales.

How to install the beta

If you’re interested in installing the new OSes, Apple’s Beta Software Program website should be your first port of call. You’ll need to sign in to access the betas using your Apple Account. Once you’ve done that, open Settings and go to Software Update; there you can select Beta Updates and choose the 27 series Public beta. Tap Update Now and the installation will begin.

You can follow me on social media! Join me on BlueSky, LinkedIn, Mastodon, and subscribe to The Core.

AI-driven hyperscale data centers are creating a new generation of risks and challenges that extend well beyond power shortages and chip supply, according to a new report from Zurich North America.

The unprecedented scale, speed and complexity of AI data center construction are exposing the industry to new threats previously unknown to the older generation of data centers, ranging from severe weather and energy constraints to insurance capacity, labor shortages and geopolitical disruptions, in its report, “Data Center Risks Right Now: Six Critical Questions to Enable a Resilient Buildout.”

The report states that hyperscalers are prepared to spend an estimated $710 billion in capital expenditures during 2026, and global investment in data centers is projected to top $7 trillion by 2030. New capacity added between 2026 and 2030 is expected to total roughly 100 gigawatts, equivalent to the peak electricity demand of about nine New York Cities.

Much of that is because these new data centers are not like any previous generations of  data center development in that modern AI campuses can span up to 20 buildings, consume as much as 2,000 megawatts of electricity and house billions of dollars’ worth of servers and cooling equipment.

In addition, insurance providers are struggling to keep pace with the massive growth in projected value of these data centers.  Zurich says the average value of the data centers it insured has jumped from roughly $150 million five years ago to about $3 billion today, while the largest campuses can be measured in the tens of billions of dollars.

The report cited six areas of concern, the primary of which is growing: severe weather.   Severe weather has surpassed fire as leading construction threat due to changing geography. Zurich states that 64% of U.S. data center capacity currently under construction is located outside traditional markets such as Northern Virginia, in areas are known for bad weather.

They include West Texas, Tennessee, Wisconsin and Ohio, where tornadoes, hailstorms and high winds present new hazards. Zurich says severe weather has become the largest source of losses in its U.S. builders-risk portfolio over the past three years, surpassing fire as the industry’s dominant construction threat. Weather accounts for 32% of losses in Zurich’s data center portfolio, followed by fire and equipment damage.

The second issue is compressed construction schedules. Operators are increasingly beginning operating portions of a campus where construction is complete and while construction continues elsewhere. That means welding and other, heavy equipment plus incomplete fire protection coexist with active server halls containing sensitive computing equipment.

Beyond construction and to absolutely no surprise, Zurich identifies energy infrastructure as one of the defining challenges facing AI expansion. The report notes that U.S. data center electricity demand increased roughly 22% in a single year and is expected to nearly triple to approximately 134 gigawatts by 2030.

Likewise, water availability is becoming equally important as power as AI workloads generate more heat and require increasingly sophisticated cooling systems. The report notes that many operators are deploying closed-loop water recycling systems or shifting toward air cooling where possible in a bid to reduce water consumption.

Downtime has become more expensive because so much expensive equipment is involved, even minor operational failures can become multimillion-dollar events.

The report also warns that replacement equipment often requires months to arrive, citing industry estimates that switchgear may take up to 85 weeks to replace and generators as long as 100 weeks.

Workforce shortages have raised operational concerns as the AI construction boom is straining the labor market, and they don’t mean The IT staff to run the place, they need people to build it. Zurich cited a report from Associated General Contractors of America that 92% of U.S. construction firms are having difficulty finding qualified workers.

The report concludes that geopolitical tensions, regulatory scrutiny and emerging technologies will increasingly influence where and how data centers are built. Among the trends Zurich identifies are growing political concern over electricity prices and water consumption, increased reliance on nuclear energy, interest in integrating future quantum computing systems and even early proposals for orbital data centers supported by solar power.

What is cloud native? Cloud native defined

The term “cloud-native computing” encompasses the modern approach to building and running software applications that exploit the flexibility, scalability, and resilience of cloud computing. The phrase is a catch-all that encompasses not just the specific architecture choices and environments used to build applications for the public cloud, but also the software engineering techniques and philosophies used by cloud developers.

The Cloud Native Computing Foundation (CNCF) is an open source organization that hosts many important cloud-related projects and helps set the tone for the world of cloud development. The CNCF offers its own definition of cloud native:

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is not exhaustive.

This definition is a good start, but as cloud infrastructure becomes ubiquitous, the cloud native world is beginning to spread behind the core of this definition. We’ll explore that evolution as well, and look into the near future of cloud-native computing.

Cloud native architectural principles

Let’s start by exploring the pillars of cloud-native architecture. Many of these technologies and techniques were considered innovative and even revolutionary when they hit the market over the past few decades, but now have become widely accepted across the software development landscape.

Microservices. One of the huge cultural shifts that made cloud-native computing possible was the move from huge, monolithic applications to microservices: small, loosely coupled, and independently deployable components that work together to form a cloud-native application. These microservices can be scaled across cloud environments, though (as we’ll see in a moment) this makes systems more complex.

Containers and orchestration. In could-native architectures, individual microservices are executed inside containers — lightweight, portable virtual execution environments that can run on a variety of servers and cloud platforms. Containers insulate the developers from having to worry about the underlying machines on which their code will execute. That is, all they have to do is write to the container environment. 

Getting the containers to run properly and communicate with one another is where the complexity of cloud native computing starts to emerge. Initially, containers were created and managed by relatively simple platforms, the most common of which was Docker. But as cloud-native applications got more complex, container orchestration platforms that augmented Docker’s functionality emerged, such as Kubernetes, which allows you to deploy and manage multi-container applications at scale. Kubernetes is critical to cloud native computing as we know it — it’s worth noting that the CNCF was set up as a spinoff of the Linux Foundation on the same day that Kubernetes 1.0 was announced — and adhering to Kubernetes best practices is an important key to cloud native success. 

Open standards and APIs. The fact that containers and cloud platforms are largely defined by open standards and open source technologies is the secret sauce that makes all this modularity and orchestration possible, and standardized and documented APIs offer the means of communication between distributed components of a larger application. In theory, anyway, this standardization means that every component should be able to communicate with other components of an application without knowing about their inner workings, or about the inner workings of the various platform layers on which everything operates.

DevOps, agile methodologies, and infrastructure as code. Because cloud-native applications exist as a series of small, discrete units of functionality, cloud-native teams can build and update them using agile philosophies like DevOps, which promotes rapid, iterative CI/CD development. This enables teams to deliver business value more quickly and more reliably.

The virtualized nature of cloud environments also make them great candidates for infrastructure as code (IaC), a practice in which teams use tools like Terraform, Pulumi, and AWS CloudFormation, to manage infrastructure declaratively and version those declarations just like application code. IaC boosts automation, repeatability, and resilience across environments—all big advantages in the cloud world. IaC also goes hand-in-hand with the concept of immutable infrastructure—the idea that, once deployed, infastructure-level entities like virtual machines, containers, or network appliances don’t change, which makes them easier to manage and secure. IaC stores declarative configuration code in version control, which creates an audit log of any changes.

Foundry

How the cloud-native stack is expanding

As cloud-native development becomes the norm, the cloud-native ecosystem is expanding; the CNCF maintains a graphical representation of what it calls the  cloud native landscape that hammers home to expansive and bewildering variety of products, services, and open source projects that contribute to (and seek to profit from) to cloud-native computing. And there are a number of areas where new and developing tools are complicating the picture sketched out by the pillars we discussed above.   

An expanding Kubernetes ecosystem. Kubernetes is complex, and teams now rely on an entire ecosystem of projects to get the most out of it: Helm for packaging, ArgoCD for GitOps-style deployments, and Kustomize for configuration management. And just as Kubernetes augmented Docker for enterprise-scale deployments. Kubernetes itself has been augmented and expanded by service mesh offerings like Istio and Linkerd, which offer fine-grained traffic control and improved security

Observability needs. The complex and distributed world of cloud-native computing requires in-depth observability to ensure that developers and admins have a handle on what’s happening with their applications. Cloud-native observability uses distributed tracing and aggregated logs to provide deep insight into performance and reliability. Tools like Prometheus, Grafana, Jaeger, and OpenTelemetry support comprehensive, real-time observability across the stack.

Serverless computing.  Serverless computing, particularly in its function-as-a-service guise, offers to strip needed compute resources down to their bare minimum, with functions running on service provider clouds using exactly as much as they need and no more. Because these services can be exposed as endpoints via APIs, they are increasingly integrated into distributed applications, operating side-by-side with functionality provided by containerized microservices. Watch out, though: the big FaaS providers (Amazon, Microsoft, and Google) would love to lock you in to their ecosystems.  

FinOps. Cloud computing was initially billed as a way to cut costs — no need to pay for an in-house data center that you barely use — but in practice it replaces capex with opex, and sometimes you can run up truly shocking cloud service bills if you aren’t careful. Serverless computing is one way to cut down on those costs, but financial operations, or FinOps, is a more systematic discipline that aims to aligns engineering, finance, and product to optimize cloud spending. FinOps best practices make use of those observability tools to best determine what departments and applications are eating up resources.

How cloud-native architecture is adapting to AI workloads

Enterprises deploy larger AI models and make use of more and more real-time inference services. That’s putting demands on cloud-native systems and forcing them to adapt to remain scalable and reliable.

For instance, organizations are re-engineering cloud environments around GPU-accelerated clusters, low-latency networking, and predictable orchestration. These needs align with established cloud-native patterns: containers package AI services consistently, while Kubernetes provides resilient scheduling and horizontal scale for inference workloads that can spike without warning.

Kubernetes itself is changing to better support AI inference, adding hardware-aware scheduling for GPUs, model-specific autoscaling behavior, and deeper observability into inference pipelines. These enhancements make Kubernetes a more natural platform for serving generative AI workloads.

AI’s resource demands are amplifying traditional cloud-native challenges. Observability becomes more complex as inference paths span GPUs, CPUs, vector databases, and distributed storage. FinOps teams contend with cost volatility from training and inference bursts. And security teams must track new risks around model provenance, data access, and supply-chain integrity.

Application frameworks for building distributed cloud-native apps

Microsoft’s Aspire is one of the most visible examples of a shift towards application frameworks to simplify how teams build distributed systems. Opinionated frameworks like Aspire provide structure, observability, and integration out of the box so developer don’t need to stitch together containers, microservices, and orchestration tooling by hand.

Aspire in particular is a prescriptive framework for cloud-native applications, bundling containerized services, environment configuration, health checks, and observability into a unified development model. Aspire provides defaults for service-to-service communication, configuration, and deployment, along with a built-in dashboard for visibility across distributed components.

While Aspire was originally aligned with Microsoft’s .NET platform,Redmond now sees it as having a  polyglot future. This positions Aspire as part of a broader trend: frameworks that help teams build cloud-native, service-oriented systems without being locked into a single language ecosystem. Several other frameworks are gaining traction: Dapr provides a portable runtime that abstracts many of the plumbing tasks in cloud-native distributed applications, and Orleans offers an actor-model-based framework for large-scale systems in the .NET world, and Akka gives JVM teams a mature, reactive toolkit for elastic, resilient services.

Frameworks and tools in the expanding cloud-native ecosystem

While frameworks like Aspire simplify how developers compose and structure distributed applications, most cloud-native systems still depend on a broader ecosystem of platforms and operational tooling. This deeper layer is where much of the complexity—and innovation—of cloud-native computing lives, particularly as Kubernetes continues to serve as the industry’s control plane for modern infrastructure.

Kubernetes provides the core abstractions for deploying and orchestrating containerized workloads at scale. Managed distributions such as Google Kubernetes Engine (GKE), Amazon EKS, Azure AKS, and Red Hat OpenShift build on these primitives with security, lifecycle automation, and enterprise support. Platform vendors are increasingly automating cluster operations—upgrades, scaling, remediation—to reduce the operational burden on engineering teams.

Surrounding Kubernetes is a rapidly expanding ecosystem of complementary frameworks and tools. Service meshes like Istio and Linkerd provide fine-grained traffic management, policy enforcement, and mTLS-based security across microservices. GitOps platforms such as Argo CD and Flux bring declarative, version-controlled deployments to cloud-native environments. Meanwhile, projects like Crossplane turn Kubernetes into a universal control plane for cloud infrastructure, letting teams provision databases, queues, and storage through familiar Kubernetes APIs. These tools illustrate how cloud-native development now spans multiple layers: developer-focused application frameworks like Aspire at the top, and a powerful, evolving Kubernetes ecosystem underneath that keeps modern distributed applications running.

Advantages and challenges for cloud-native development

Cloud native has become so ubiquitous that its advantages are almost taken for granted at this point, but it’s worth reflecting on the beneficial shift the cloud native paradigm represents. Huge, monolithic codebases that saw updates rolled out once every couple of years have been replaced by microservice-based applications that can be improved continuously. Cloud-based deployments, when managed correctly, make better use of compute resources and allow companies to offer their products as SaaS or PaaS services. 

But cloud-native deployments come with a number of challenges, too:

• Complexity and operational overhead: You’ll have noticed by now that many of the cloud-native tools we’ve discussed, like service meshes and observability tools, are needed to deal with the complexity of cloud-native applications and environments. Individual microservices are deceptively simple, but coordinating them all in a distributed environment is a big lift.
• Security: More services executing on more machines, communicating by open APIs, all adds up to a bigger attack surface for hackers. Containers and APIs each have their own special security needs, and a policy engine can be an important tool for imposing a security baseline on a sprawling cloud-native app. DevSecOps, which adds security to DevOps, has become an important cloud-native development practice to try to close these gaps.
• Vendor lock-in: This may come as a surprise, since cloud-native is based on open standards and open source. But there are differences in how the big cloud and serverless providers works, and once you’ve written code with one provider in mind, it can be hard to migrate elsewhere.
• A persistent skills gap: Cloud-native computing and development may have years under its belt at this point, but the number of developers who are truly skilled in this arena is a smaller portion of the workforce than you’d think. Companies face difficult choices in bridging this skills gap, whether that’s bidding up salaries, working to upskill current workers, or allowing remote work so they can cast a wide net. 

Cloud native in the real world

Cloud native computing is often associated with giants like Netflix, Spotify, Uber, and AirBNB, where many of its technologies were pioneered in the early ’10s. But the CNCF’s Case Studies page provides an in-depth look at how cloud native technologies are helping companies. Examples include the following:

• A UK-based payment technology company that can switch between data centers and clouds with zero downtime
• A software company whose product collects and analyzes data from IoT devices — and can scale up as the number of gadgets grows
• A Czech web service company that managed to improve performance while reducing costs by migrating to the cloud

Cloud-native infrastructure’s capability to quickly scale up to large workloads also make it an attractive platform for developing AI/ML applications: another one of those CNCF case studies looks at how IBM uses Kubernetes to train its Watsonx assistant. The big three providers are putting a lot of effort into pitching their platforms as the place for you to develop your own generative AI tools, with offerings like Azure AI Foundry,Google Firebase Studio, and Amazon Bedrock. It seems clear that cloud native technology is ready for what comes next.

Learn more about related cloud-native technologies:

• Platform-as-a-service (PaaS) explained
• What is cloud computing
• Multicloud explained
• Agile methodology explained
• Agile development best practices
• Devops explained
• Devops best practices
• Microservices explained
• Microservices tutorial
• Docker and Linux containers explained
• Kubernetes tutorial
• CI/CD (continuous integration and continuous delivery) explained
• CI/CD best practices

Picture the moment after an AI issue is reported.

A security analyst is reviewing a ticket reporting that an internal AI tool produced the wrong recommendation in a live business workflow. The risk is not theoretical anymore. Someone wants to know whether this is a security incident, a model issue, a privacy issue, a vendor issue or just “something the AI did.” The risk register has a line item for inaccurate output, and it may even have a severity rating.

What it does not have is an answer to the question everyone is now asking: who has the authority to stop this thing?

That is the gap many AI governance programs still need to close. Organizations are getting better at identifying AI risks, documenting them and assigning them to governance categories. What they are often less prepared for is the operational moment when an AI risk becomes a real event that has to be investigated, contained and explained.

In security programs, that distinction matters. A risk register can document concerns, but it cannot preserve evidence, notify leadership, assess impact or decide whether an AI system should keep running. Security leaders do not need another spreadsheet that says AI can fail; they need an executable response model for what happens when it does.

The list is not the response

Risk registers are useful because they create visibility. They help organizations name risks, compare severity, assign ownership and communicate concerns to leadership. In early AI adoption, visibility matters because many organizations are still discovering where AI is being used, what data is involved and which business processes may be affected.

But a risk register is not a control. Security teams already understand this in other domains. A list of vulnerabilities is not a vulnerability management program, and a list of third-party risks is not a vendor risk management function. The list is only the beginning of the work.

AI risk creates the same problem. A risk entry that says “model output may be inaccurate” does not define who monitors output quality, what level of error is acceptable, what evidence should be preserved or who can pause the system. A risk entry that says “sensitive data may be exposed” does not explain whether prompts are logged, whether outputs are reviewed, whether the vendor can use submitted data or whether the event should trigger privacy, legal or security escalation.

This is where AI governance can look stronger than it actually is. The organization may have a policy, a committee, an intake form and a risk register, but those artifacts do not automatically create operational readiness. When something happens, the real test is whether the organization knows what to do next.

AI incidents do not always look like breaches

Part of the challenge is that AI incidents do not always look like traditional cybersecurity incidents. A breach has familiar patterns: unauthorized access, data exfiltration, malware, credential compromise or suspicious activity in a system. AI failures can be messier because they may appear first as a bad recommendation, a misleading summary, an unsafe automation, a flawed classification or an output that quietly changes a decision.

That does not make them less important. An AI tool used in a security workflow could misclassify an alert. A generative AI assistant could expose sensitive information in a response. A model embedded in a business process could drift over time and produce unreliable recommendations. A vendor-managed AI feature could change behavior after an update that the organization did not fully review.

Security teams need a practical way to sort these events. Not every AI error should be treated as a full security incident. Still, every organization using AI in meaningful workflows should know how AI-related events are reported, triaged and escalated. Without that structure, teams may lose time debating ownership while the impact continues.

The first step is defining what counts as an AI incident. That definition should be broad enough to capture security, privacy, safety, operational and compliance concerns, but specific enough that employees know when to report something. A confusing chatbot answer may not require the same response as a data exposure event, but both should have a path for review.

Evidence has to exist before the investigation

Incident response depends on evidence. That is obvious in cybersecurity, but it is often overlooked in AI governance conversations. If an organization cannot reconstruct what happened, who used the system, what data was involved and what output was produced, it will struggle to investigate the event or defend its response.

AI systems can complicate that evidence trail. Prompts may not be logged. Outputs may not be retained. Vendor tools may provide limited visibility. Model versions may change. Users may copy AI-generated content into other systems without preserving its source. Business teams may treat AI output as a recommendation rather than a system event.

Security leaders should push for evidence requirements before AI systems move into production. At a minimum, organizations should know what logs are available, how long they are retained, who can access them and whether they are sufficient for investigation. For higher-risk use cases, teams may also need records of model version, prompt history, output history, user actions, data sources and downstream decisions.

This does not mean every AI interaction needs heavy surveillance. Monitoring should be proportional to risk, and organizations still need to respect privacy, legal and workforce considerations. The point is simpler: if the AI system matters enough to influence real work, it matters enough to leave an evidence trail when something goes wrong.

Ownership cannot be implied

AI ownership is often fragmented. A business unit may sponsor the use case, a data science team may configure the model, IT may manage the platform, security may assess risk, and a vendor may provide the underlying capability. Everyone is involved, but no one may be fully accountable after deployment.

That ambiguity becomes dangerous during an incident. If an AI tool begins producing unreliable output, the organization needs to know who owns the system, who owns the business process and who owns the decision to continue or stop use. A governance committee can provide oversight, but it usually cannot serve as the operational owner of every deployed AI capability.

Security programs should insist on named ownership for AI systems, especially those used in sensitive or high-impact workflows. Ownership should include responsibility for monitoring, exceptions, user guidance, vendor coordination and incident escalation. It should also include decision rights, because accountability without authority is just a name in a spreadsheet.

The hardest question is often pause authority. Who can suspend, restrict, roll back or retire an AI system when risk exceeds tolerance? If that question is not answered before deployment, the organization may be forced to answer it under pressure.

Security leaders need an AI response playbook

An AI response playbook does not need to be complicated, but it does need to be real. It should explain how employees report AI concerns, how the event is triaged, what evidence is preserved, who investigates, when legal or privacy teams are involved, and who can make operational decisions. It should also define when executive leadership needs to be notified.

The playbook should reflect the type of AI system involved. A low-risk internal productivity tool may require a lightweight review path. An AI system supporting security operations, regulated decisions, customer communication, healthcare workflows or financial processes needs stronger monitoring and escalation. The response model should fit the risk of the use case.

This is where security can add discipline without turning AI governance into bureaucracy. Security teams already know how to build escalation paths, preserve evidence, run incident reviews and improve controls after failures. The opportunity is to extend that operating muscle into AI governance before incidents force the issue.

Organizations should also conduct post-incident reviews for meaningful AI events. The goal should not be blame; it should be learning. Did the monitoring work? Was the owner clear? Was the evidence sufficient? Did the vendor respond? Were users confused about acceptable use? Did the organization know who could make the decision?

Governance has to be executable

AI governance is often discussed as a policy, ethics or compliance challenge. It is all of those things, but once AI systems enter production, it also becomes a security execution challenge. Risk has to be monitored, events have to be investigated and someone has to be able to act.

That is why the next maturity step is not simply better documentation. Organizations need governance that works when a system is live, a decision is time-sensitive and the facts are incomplete. In that moment, the risk register may help explain what the organization expected, but it will not run the response.

Security leaders should not wait for AI governance to arrive fully formed from somewhere else in the enterprise. They should help shape the operating model now, while many organizations are still early enough to correct course. The goal is not to own every AI risk; it is to ensure AI risk can be managed once AI becomes operational.

A risk register can tell leaders what might go wrong. An incident response plan tells people what to do when it does. For AI governance to matter in security programs, organizations need both.

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

Most AI agents today are optimised for responsiveness—faster first responses, shorter wait times, higher service rates. And on those metrics, they’re delivering.

It’s no surprise then that 90% of business leaders believe their customers are satisfied with conversational AI experiences. Yet only 59% of consumers agree, according to Twilio’s latest report on conversational AI.

What could explain this 31-point gap? The data is unambiguous. 54% of consumers say AI agents rarely have context about them as a customer. 78% say the ability to escalate to a human is important, yet few get the chance to do so. And only 15% report experiencing a seamless handoff from an AI agent to a human one.

All this to say that the real measure of an AI agent isn’t how fast it answers, but whether it solves the problem. In fact, 72% of consumers would choose an AI over a human if it could resolve their issue more quickly.

Speed without resolution will only result in frustration.

Why most AI agents aren’t great at resolution

It’s not hard to see why most AI agents fail to resolve customer issues: they can’t take action on behalf of the customer, they can’t escalate conversations when they reach their limits, and they lack the real-time context needed to personalise the interaction.

Think about what a typical AI service interaction looks like. A customer calls with a billing question. The AI agent reads their intent accurately enough. But it can’t pull up the customer’s account in real time, process a credit, or route to a human specialist who knows the context of the conversation. So the customer repeats themselves. Or simply gives up.

The root cause is structural. In most stacks, the channel is the system of record, not the conversation. Voice, SMS, chat, and WhatsApp each run as separate sessions, so the moment a customer switches channels or escalates to a human, the interaction resets. Engineering teams paper over this by stuffing full transcripts into AI prompts to fake continuity. This inflates token costs, slows responses, and still truncates older context once the window fills up.

This is the gap between a chatbot and an agent. A chatbot responds. An agent resolves. It’s no wonder that the 59% of organisations planning to fully replace their current conversational AI solution within the year understand this distinction. Their early investments were simply optimised for the wrong outcome.

What resolution actually requires

A smarter agent only gets you so far. Businesses need four capabilities to close the resolution gap:

1. Agency: Agents must be able to take real action, such as scheduling, processing, and updating records, within the conversation itself.
2. Always-on monitoring: Agents should continuously evaluate the quality of interactions and catch failures before they become customer complaints
3. Intelligent routing: Agents should escalate issues with full context so that humans can pick up where they left off.
4. Real-time contextual data: Agents should have the same customer context as a well-prepared human agent. This includes purchase history, past interactions, account status, and preferences.

None of these are speculative. They’re available today, and the companies deploying them are already seeing the difference.

Case in point: OhMD, a healthcare communications platform for physician practices and medical groups. The company built Nia, an AI-powered voice assistant that uses Twilio’s Conversation Relay to handle routine patient calls (scheduling, prescription refills, FAQs). Complex calls are routed to staff with full context, which saves patients from repeating themselves.

The results were immediate. OhMD saw a 60% improvement in self-service first-call resolution, with appointment scheduling flows completing in as little as one minute. By 2026, Nia is projected to handle more than 55 million patient interactions annually.

As Twilio CEO Khozema Shipchandler noted, “What we’re starting to see with OhMD is that they’ve got a 60% lift in self-serve capability to actually resolve calls. They’re able to drive the conclusion of these calls in less than a minute in many instances.”

Patients aren’t impressed because the phone rang once. They’re impressed because the call ended with their problem solved.

Think resolution, not speed

For every customer service leader evaluating their AI agent roadmap, the implication is straightforward. Stop measuring success by response time alone. Start measuring it by resolution rate—specifically, self-service resolution rate.

That means investing not in faster replies, but in smarter infrastructure: agents that act, routing that adapts, data that flows in real time, and monitoring that holds the system accountable.

The future of customer service isn’t about answering faster. It’s about answering fully.         

To learn more about Twilio, visit here.