Looking ahead just a short time, Apple could hold a powerful position in AI where it most makes sense: deployment.

Not only will the company offer up its own AI models for the kind of tasks millions use ChatGPT to do today, but it will provide more sophisticated on-device agentic models to help users get things done through Siri AI.

Apple also offers limited capacity for more complex tasks through Private Cloud Compute, and, in partnership with the likes of Google in the US and Alibaba in China, the company is giving users a trusted conduit through which to access even more sophisticated AI services. 

Deeply deployable

Critics can say it took Apple a long time to get to this point, but they also seem to think the company has finally got the mix right with its series 27 operating systems. Arriving late to a party doesn’t mean you won’t shine once you get there.

Apple is also coming up the inside lane around frontier AI, with iterative OS and hardware enhancements that mean its devices become increasingly effective for Edge AI use cases, on device — no cloud service required.

The company appears to be digging down into those use cases. Mark Gurman at Bloomberg recently predicted that future M7 Ultra Macs will support as much as 1.5TB RAM, making these systems more than capable of running full weight frontier models in people’s offices, colleges, and homes. 

While that does assume the AI-flationary memory market can supply that much RAM at prices humans can afford, it is also true that people are already running AI clusters using off-the-shelf Mac minis networked over Thunderbolt cables. It’s no stretch to believe this will continue to be the case, and that it will even broaden as the power/performance offered at the high end grows.

What’s wrong with good enough?

When combined with open AI stacks, particularly newly emerging varieties, Apple’s platforms should become leading contenders for private AI services and edge AI. Many business users will leap at the chance to offer their workers powerful, self-hosted, private AI services using one or more daisy-chained Mac Studios or Mac minis. The recent craze in deployment of both Macs to support OpenClaw instances shows they already are.

Ultimately, these different slices of momentum mean I agree with investor Jason Calacanis that Apple is in position to apply a great deal of pressure on OpenAI and Claude just by putting models on their devices. 

It’s also worth thinking about how people use AI today. How many of the queries made in the world right now constitute relatively simple tasks that could be transacted by on-device AI, such as the emerging new version of Apple Intelligence or even smaller LLM models running on device? You can even run PrismML’s 1-bit, 27-billion parameter Bonsai on an iPad using the Locally app, and that’s in the here and now.

What happens? Pretty soon you’ll find people recognize that they can already run the vast majority of their AI-augmented workflows using services they have on their existing device or can access on their on-prem Mac set-ups. And, of course, as people get used to running small tasks locally and larger tasks on premises, the actual space in which they need to turn to cloud-based frontier models will erode. That’s even as companies like PrismML work towards slimming down full-weight models so they don’t need to run on a server at all.

“It’s going to be wild when people have unlimited tokens on their desks,” said Calacanis in a podcast round table discussion.

Who has the most to lose?

The current incarnations of AI felt like they came from nowhere. Most people weren’t aware of the technology until returning to work after the 2022 holiday season. Since then, the industry has proliferated with dozens of competing models, most recently including powerful but affordable frontier models such as Qwen and Kimi.ai.

These models aren’t necessarily all as good as one another, but in many cases for much of what we do, we’ll find them to be good enough. That’s an existential crisis for some, as industry observers now think the inevitable pricing pressure means some services might have over-invested in capacity before finding any way to turn a profit.

Those profit-seeking services are the ones with the most to lose as Apple extends its hardware advantage, democratizing AI access for all while providing platforms suitable for edge AI, on-premises AI, private AI, and even AI access using third-party services. (The need for the latter will shrink as the capabilities of the former get better.)

Cupertino rising

What does this all mean? While the industry remains young, it is already fragmenting. And striding through the dust of that process comes Apple, equipped with the hardware, software, and approach to build its business even as the enterprise of first mover AI services erodes.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to my daily Apple-related news summaries at The Core.

Just in time for the iPhone’s 20th anniversary, Apple is moving closer to becoming a service company. It is set to launch its new deal with Klarna next week and when it does, Apple enthusiasts in the US will effectively be able to subscribe to their favorite Apple hardware, with the cost spread across up to three years.

This matters because when combined with Apple One and Apple’s Creator Studio subscriptions, the Klarna arrangement brings Apple closer to offering a full subscription model for hardware, software, and services. The only thing you don’t get under the new arrangement is AppleCare, for which you’ll allegedly need to pay extra.

Moving closer to hardware-as-a-service

Apple has slowly been transitioning toward hardware-as-a-service for almost a decade. Back then, Forrester analyst Frank Gillet predicted the company would eventually offer bundles of services and products for a monthly, all-in, fee. 

This isn’t quite where we are yet; you still need at least three subscriptions to get close. But, after the better part of a decade, Apple has moved much nearer to the hardware-as-a-service idea.

There are some products reportedly excluded from the arrangement, including MacBook Neo, Apple Watch SE, the entry-level iPad, and iPhone 16. Clearly, Apple sees those products as sufficiently affordable. 

Easy payments for RAM-ageddon

The new Klarna arrangement comes as Apple is forced to increase product prices as AI-driven memory price inflation becomes widely felt across every economy. In theory, I assume, Apple hopes to make its products available to cash-strapped consumers who need new hardware, while also navigating a time of deep economic tumult and uncertainty. It’s thought the company has previously rejected these plans to protect normal hardware sales, but normality is a kingdom we no longer seem to possess. Interesting times. Probable inflation incoming.

“Apple Upgrade lands at precisely the moment Apple needs it,” IDC analyst Francisco Jeronimo wrote in a note seen by Computerworld. “Having just pushed Mac and iPad prices up on the back of the memory shortage, with iPhone increases widely expected in September — as well as the new iPhone foldable expected at $2,500 — Apple’s real risk is that rising prices even further can impact the upgrade cycle.” 

New age, new shopping habits

The introduction of the scheme gives consumers a way to purchase the company’s popular high-end devices when they are introduced — no doubt,at higher cost — this fall. Plus, of course, if it’s good enough for GM, it’s good enough for Apple.

It’s all about attitude, too. From Apple’s perspective, it has done plenty of the groundwork required to convince its customers that subscription payments for things you value are no bad thing. 

Reluctance to embrace “Access Not Ownership’”purchasing models has dropped dramatically since Apple — and CEO Tim Cook — first began banging the drum for services income. Apple’s services stream has now become its second-biggest revenue driver after the iPhone. It has over 1 billion paid subscriptions, and an active hardware installed base of more than 2.5 billion devices globally.

A combination of changed customer habits and external threat means the stars are now aligned for hardware-as-a-service models. “Reframing a device as a low monthly payment protects that [upgrade] cadence and allows Apple to start marketing their products as device-as-a-service to consumers, which no other vendor was ever able to do,” Jeronimo wrote to me. 

There is a one-more-thing aspect to this: the products are effectively being leased, a new approach that will give Apple a stronger grip on EOL devices, helping it grab more of them for refurbishment, resale, and recycling. Over time, this will give the company a much stronger grip on the lucrative second-user market that exists around Apple equipment, even while for almost every consumer product we find the life we want is something we can rent, but probably can’t afford to own.

Managing future risk

The other solid reason to take a partnership approach is risk management. Apple had intended to develop its own buy-now, pay-later scheme via Apple Pay Later, but abandoned that plan as it became riskier with rising bank rates. “Also, by backing the program with Klarna rather than reviving the in-house subscription plan it shelved in 2024, Apple captures the demand upside without taking the credit risk onto its own balance sheet,” Jeronimo said.

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

Defense research agency DARPA made its largest quantum computing award ever this week, with a $125 million agreement announced on Wednesday. The same day, the White House announced an additional $5 billion for the Genesis Mission, which focuses on AI for science but also includes technology to accelerate quantum computing and quantum sensors.

“Taken together, these announcements signal that U.S. quantum strategy is shifting from supporting individual research projects to building the infrastructure needed for a quantum-enabled economy,” says Heather West, research manager in the infrastructure systems, platforms, and technology group at IDC.

None of the individual quantum announcements are surprising, she says. But the level of coordination is new. “Government investment is expanding beyond foundational research toward commercialization, manufacturing, and deployment,” she says.

“The US government has been signaling that quantum computing is a priority,” says David Mooter, an analyst at Forrester Research. Part of it is the desire for the US to be a leader in quantum, as it has been in other high-tech areas, he says. And part of it is because the government itself can take advantage of quantum computers.

“Spy agencies would love to use them to decrypt intercepted messages, including messages they intercepted years ago and saved,” he says. And other departments could use quantum computers or networks for energy-related research, for supply chain optimization, and for secure communications. 

Quantum computing is accelerating, he says. “I would not be surprised to see a general gate-based quantum computer that’s good enough to provide commercial value for limited use cases by 2030.”

DARPA’s Quantum Benchmarking Initiative

DARPA’s Quantum Benchmarking Initiatives was launched in 2024, and 18 companies were selected in April of 2025 for Stage A of the project, with awards of up to $1 million each. The companies were to use the money to provide details of their concepts and show how they could lead to a functional, fault-tolerant quantum computer in under a decade.

Then, in November of 2025, DARPA chose 11 companies for Stage B of the project, with awards of up to $15 million for developing their research plans.

To date, only two companies have been chosen for Stage C: PsiQuantum and Microsoft. PsiQuantum announced $32 million of DARPA funding for testing and evaluation in September of last year. This week’s $125 million award will expand the scope and pacing of the validation and verification work. Stage C awards can go up to $300 million, according to DARPA.

This past May, PsiQuantum also announced $100 million from the Department of Commerce, part of the CHIPS and Science Act, to accelerate domestic manufacturing of critical quantum computing components.

Microsoft and PsiQuantum are both in Stage C, bypassing the sequential path that other companies are expected to follow, because they were both part of DARPA’s predecessor to QBI, the Underexplored Systems for Utility-Scale Quantum Computing program.

Genesis Mission

Genesis Mission was launched in late 2025 with the goal of using AI to accelerate scientific breakthroughs, and it now includes more than 15 government agencies.

As part of the Genesis Mission, quantum computing and sensing company Infleqtion announced three projects for the Department of Energy on Wednesday. The three projects focus on quantum circuit design for nuclear applications, atomic quantum sensing, and nuclear fusion energy research.

This announcement did not include the total monetary value of the projects, but, in May, the company announced a separate agreement with the Department of Commerce for $100 million to accelerate Infleqtion’s neutral-atom technology roadmap.

Other quantum-related Genesis Mission projects announced this week include $1.5 million for a BlueQubit quantum error correction project with Microsoft and other partners, a Stanford effort to model the behavior of electrons at quantum scale, an MIT quantum sensing project, Argonne National Laboratory projects on quantum circuit design and quantum sensors, Brookhaven Lab quantum sensor projects, and quantum computing projects at Northwestern University.

IBM, one of three dozen private companies that are part of the Genesis Mission Consortium, announced that it will be leading a project to support more effective quantum applications, and will contribute up to $50 million of quantum compute access for the Genesis Mission.

Enterprise priorities

This week’s quantum announcements aren’t a sign that enterprises need to run out and buy quantum computers, says IDC’s West. But they do need to start preparing for the quantum era — such as by identifying business areas where quantum computing could become a competitive differentiator over the next decade.

But the most immediate threat is that of adversaries using quantum computers to break current encryption standards. Organizations should be inventorying cryptographic assets and developing a roadmap for the migration to quantum-proof algorithms, West says.

The point of no return is closer than ever, and many major players in the encryption and communication space, including Google and Cloudflare, have been accelerating their timelines. In fact, this Wednesday was the federal deadline for naming their post-quantum cryptography migration leads under a June executive order.

“The preparation that needs to be done to prepare is to implement post-quantum cryptography yesterday,” says Forrester’s Mooter.

However, according to a survey released by DigiCert this morning, while 87% of organizations are planning, testing or implementing PQC initiatives, only 7% of organizations have deployed quantum-safe or hybrid cryptography across most of their digital certificates.

Just in time for the iPhone’s 20th anniversary, Apple is moving closer to becoming a service company. It is set to launch its new deal with Klarna next week and when it does, Apple enthusiasts in the US will effectively be able to subscribe to their favorite Apple hardware, with the cost spread across up to three years.

This matters because when combined with Apple One and Apple’s Creator Studio subscriptions, the Klarna arrangement brings Apple closer to offering a full subscription model for hardware, software, and services. The only thing you don’t get under the new arrangement is AppleCare, for which you’ll allegedly need to pay extra.

Moving closer to hardware-as-a-service

Apple has slowly been transitioning toward hardware-as-a-service for almost a decade. Back then, Forrester analyst Frank Gillet predicted the company would eventually offer bundles of services and products for a monthly, all-in, fee. 

This isn’t quite where we are yet; you still need at least three subscriptions to get close. But, after the better part of a decade, Apple has moved much nearer to the hardware-as-a-service idea.

There are some products reportedly excluded from the arrangement, including MacBook Neo, Apple Watch SE, the entry-level iPad, and iPhone 16. Clearly, Apple sees those products as sufficiently affordable. 

Easy payments for RAM-ageddon

The new Klarna arrangement comes as Apple is forced to increase product prices as AI-driven memory price inflation becomes widely felt across every economy. In theory, I assume, Apple hopes to make its products available to cash-strapped consumers who need new hardware, while also navigating a time of deep economic tumult and uncertainty. It’s thought the company has previously rejected these plans to protect normal hardware sales, but normality is a kingdom we no longer seem to possess. Interesting times. Probable inflation incoming.

“Apple Upgrade lands at precisely the moment Apple needs it,” IDC analyst Francisco Jeronimo wrote in a note seen by Computerworld. “Having just pushed Mac and iPad prices up on the back of the memory shortage, with iPhone increases widely expected in September — as well as the new iPhone foldable expected at $2,500 — Apple’s real risk is that rising prices even further can impact the upgrade cycle.” 

New age, new shopping habits

The introduction of the scheme gives consumers a way to purchase the company’s popular high-end devices when they are introduced — no doubt,at higher cost — this fall. Plus, of course, if it’s good enough for GM, it’s good enough for Apple.

It’s all about attitude, too. From Apple’s perspective, it has done plenty of the groundwork required to convince its customers that subscription payments for things you value are no bad thing. 

Reluctance to embrace “Access Not Ownership’”purchasing models has dropped dramatically since Apple — and CEO Tim Cook — first began banging the drum for services income. Apple’s services stream has now become its second-biggest revenue driver after the iPhone. It has over 1 billion paid subscriptions, and an active hardware installed base of more than 2.5 billion devices globally.

A combination of changed customer habits and external threat means the stars are now aligned for hardware-as-a-service models. “Reframing a device as a low monthly payment protects that [upgrade] cadence and allows Apple to start marketing their products as device-as-a-service to consumers, which no other vendor was ever able to do,” Jeronimo wrote to me. 

There is a one-more-thing aspect to this: the products are effectively being leased, a new approach that will give Apple a stronger grip on EOL devices, helping it grab more of them for refurbishment, resale, and recycling. Over time, this will give the company a much stronger grip on the lucrative second-user market that exists around Apple equipment, even while for almost every consumer product we find the life we want is something we can rent, but probably can’t afford to own.

Managing future risk

The other solid reason to take a partnership approach is risk management. Apple had intended to develop its own buy-now, pay-later scheme via Apple Pay Later, but abandoned that plan as it became riskier with rising bank rates. “Also, by backing the program with Klarna rather than reviving the in-house subscription plan it shelved in 2024, Apple captures the demand upside without taking the credit risk onto its own balance sheet,” Jeronimo said.

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

Looking ahead just a short time, Apple could hold a powerful position in AI where it most makes sense: deployment.

Not only will the company offer up its own AI models for the kind of tasks millions use ChatGPT to do today, but it will provide more sophisticated on-device agentic models to help users get things done through Siri AI.

Apple also offers limited capacity for more complex tasks through Private Cloud Compute, and, in partnership with the likes of Google in the US and Alibaba in China, the company is giving users a trusted conduit through which to access even more sophisticated AI services. 

Deeply deployable

Critics can say it took Apple a long time to get to this point, but they also seem to think the company has finally got the mix right with its series 27 operating systems. Arriving late to a party doesn’t mean you won’t shine once you get there.

Apple is also coming up the inside lane around frontier AI, with iterative OS and hardware enhancements that mean its devices become increasingly effective for Edge AI use cases, on device — no cloud service required.

The company appears to be digging down into those use cases. Mark Gurman at Bloomberg recently predicted that future M7 Ultra Macs will support as much as 1.5TB RAM, making these systems more than capable of running full weight frontier models in people’s offices, colleges, and homes. 

While that does assume the AI-flationary memory market can supply that much RAM at prices humans can afford, it is also true that people are already running AI clusters using off-the-shelf Mac minis networked over Thunderbolt cables. It’s no stretch to believe this will continue to be the case, and that it will even broaden as the power/performance offered at the high end grows.

What’s wrong with good enough?

When combined with open AI stacks, particularly newly emerging varieties, Apple’s platforms should become leading contenders for private AI services and edge AI. Many business users will leap at the chance to offer their workers powerful, self-hosted, private AI services using one or more daisy-chained Mac Studios or Mac minis. The recent craze in deployment of both Macs to support OpenClaw instances shows they already are.

Ultimately, these different slices of momentum mean I agree with investor Jason Calacanis that Apple is in position to apply a great deal of pressure on OpenAI and Claude just by putting models on their devices. 

It’s also worth thinking about how people use AI today. How many of the queries made in the world right now constitute relatively simple tasks that could be transacted by on-device AI, such as the emerging new version of Apple Intelligence or even smaller LLM models running on device? You can even run PrismML’s 1-bit, 27-billion parameter Bonsai on an iPad using the Locally app, and that’s in the here and now.

What happens? Pretty soon you’ll find people recognize that they can already run the vast majority of their AI-augmented workflows using services they have on their existing device or can access on their on-prem Mac set-ups. And, of course, as people get used to running small tasks locally and larger tasks on premises, the actual space in which they need to turn to cloud-based frontier models will erode. That’s even as companies like PrismML work towards slimming down full-weight models so they don’t need to run on a server at all.

“It’s going to be wild when people have unlimited tokens on their desks,” said Calacanis in a podcast round table discussion.

Who has the most to lose?

The current incarnations of AI felt like they came from nowhere. Most people weren’t aware of the technology until returning to work after the 2022 holiday season. Since then, the industry has proliferated with dozens of competing models, most recently including powerful but affordable frontier models such as Qwen and Kimi.ai.

These models aren’t necessarily all as good as one another, but in many cases for much of what we do, we’ll find them to be good enough. That’s an existential crisis for some, as industry observers now think the inevitable pricing pressure means some services might have over-invested in capacity before finding any way to turn a profit.

Those profit-seeking services are the ones with the most to lose as Apple extends its hardware advantage, democratizing AI access for all while providing platforms suitable for edge AI, on-premises AI, private AI, and even AI access using third-party services. (The need for the latter will shrink as the capabilities of the former get better.)

Cupertino rising

What does this all mean? While the industry remains young, it is already fragmenting. And striding through the dust of that process comes Apple, equipped with the hardware, software, and approach to build its business even as the enterprise of first mover AI services erodes.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to my daily Apple-related news summaries at The Core.

Every day this past week I did something I suspect millions of other people also did: I stared at an LLM model picker and wondered which one I was supposed to want.

OpenAI just released ⁠GPT-5.6 Sol, Terra, and Luna. Sol is the flagship. Terra offers much of its intelligence for less money. Luna is cheaper still. Anthropic released ⁠Claude Sonnet 5 at the end of June and Opus 4.8 the month prior, with a little Fable 5 emerging in between. Meanwhile, Google, which seemed to be winning the model wars a few months ago, is now getting shade from Gergely Orosz, who ⁠argues that Gemini has slipped outside the top tier for software development and has been out of the major model release game for eons (May 19).

Perhaps Orosz is right. Perhaps he’ll be wrong again in six weeks. Honestly, it’s exhausting.

I use ChatGPT and Claude constantly and still have no principled idea which model to choose most of the time. I tend to click whatever looks like the biggest, most expensive option because I don’t know what I’m giving up by choosing something smaller. “Instant” sounds dangerously unserious. “Thinking” sounds expensive but powerful.

A quick survey of my LinkedIn crowd suggests others also feel my “WHICH MODEL???” pain. More importantly, I suspect most enterprises do, too.

A model doesn’t rot

Before getting carried away, however, it’s worth considering whether any of this model churn actually matters. After all, a model doesn’t rot. The model an enterprise put into production in March performs just as well in July as it did when the company selected it. “Obsolete” generally means that something better now exists, not that the deployed model suddenly stopped summarizing insurance claims or classifying support tickets. (In other words, once you have something working, the idea that “but maybe Opus 200.2 is better!” is really a FOMO problem, not a performance issue.)

Most enterprise workloads don’t live at the frontier anyway. Extraction, summarization, classification, document comparison, and customer-service assistance often work perfectly well with smaller, cheaper models. OpenAI’s own pitch for the trio of GPT-5.6 models isn’t simply that Sol is better. It’s that ⁠Terra and Luna deliver different combinations of intelligence, latency, and cost. Luna, the cheapest tier, nearly matches the previous generation’s peak performance at less than half the estimated cost, according to OpenAI.

The practical question, of course, is where to start. An enterprise can’t test every model, every reasoning setting, and every price tier before doing any work. So here’s my advice (which I don’t follow in my own work, but I’m not defining enterprise strategy and can be a little price-insensitive). Start with the cheapest credible model that appears capable of the task. Give it a representative set of real examples and, before you start testing, define what counts as good enough. If it passes, stop. If it fails, move up a tier or try a model with strengths better suited to the work.

That sounds almost offensively simple, but it reverses the way many people, including me, use these products. We start with the biggest model because we’re afraid of what we might lose. Enterprises should start lower and require evidence before paying for more intelligence.

There are exceptions, of course. For genuinely difficult work, such as autonomous coding, complex research, or high-stakes reasoning, beginning with a frontier model may save time. But even then, the goal should be to establish a quality ceiling, then test whether a cheaper model can meet it. It’s changing the question from “which model is best?” to “what is the least expensive model that reliably clears the bar for this job?”

For many workloads, that price improvement matters more than a few extra benchmark points. ⁠As I argued back in 2023, following AI hype doesn’t help anyone. If your model strategy depends on whichever benchmark screenshot is circulating on X this week, you don’t have a strategy. Not a viable one, anyway. Pick a model and ignore the noise.

Except, of course, when that noise suggests a serious signal.

Sometimes better really is better

Frontier improvements aren’t always incremental, making it advantageous to consider an upgrade. Coding is the obvious example. There’s a significant difference between a model that suggests the next few lines of code and one that can inspect a repository, plan a change, use tools, run tests, discover its own mistakes, and keep working for an extended period. That isn’t merely a nicer autocomplete experience. It can reorganize a development workflow.

This is why enterprises can’t simply standardize on an 18-month-old model and declare victory. In some areas, particularly software development and other agentic work, better models can unlock compounding productivity. A model that reliably completes 80% of a bounded task rather than 50% may justify an entirely different division of labor between humans and machines.

Still, that upgrade isn’t free.

Models differ in how they interpret instructions, call tools, manage context, refuse requests, and fail. Prompts and scaffolding tuned for one model can regress when moved to another. Or costs can explode. As one of my Oracle colleagues discovered just this week, running the same tasks in GPT 5.6 was orders of magnitude more expensive than 5.5. The API change may be trivial, but the revalidation and implications are not.

This leaves enterprises caught between two bad options. They can freeze and potentially miss out on meaningful improvements or chase every release and repeatedly test production systems on faith. What to do?

Stop making model bets

The answer is to stop making LLM bets and start making job-to-be-done bets. Stop asking which model is fastest. Instead, figure out what work you are trying to improve. What does a good result look like? How much latency and cost can the workflow tolerate? How wrong can it be before a human must intervene? Once those questions have answers, model selection becomes less opaque.

A difficult code migration may justify GPT-5.6 Sol or Claude Sonnet 5. A repetitive classification task may work just as well with Luna or another smaller model. A regulated workflow may require a model or deployment option that offers particular data controls. Sometimes the correct model is no LLM at all, like when I’m writing this post. Sorry, AI vendors! (At least you won’t get blamed for my mistakes.)

This is where evaluations become the center of enterprise AI strategy. ⁠As I’ve said before, most companies don’t have an AI quality problem so much as an AI measurement problem. Hence, a private evaluation suite built from real company work is the only leaderboard that matters. Does the new model materially improve quality? If so, use it! Does it reduce cost or latency? Again, that’s your free pass to adoption. Does the improvement justify the expense and effort of revalidation? If yes, continue.

Make model releases boring

As important as the model is, keep in mind that AI success always comes back to your company’s data, your company’s workflows, your company’s integrations, etc. That’s the ⁠dull reality behind sexy AI. Retrieval, memory, governance, data quality, observability, and feedback loops aren’t as exciting as a new model launch, but they’re what ultimately make AI truly work.

Again, when it’s time to consider something new, the principle should be to default to the least expensive model that reliably passes your evaluations. Only escalate harder tasks to more capable models when measurement shows that the premium pays. Tip: Make this invisible to employees so that the system routes to the best model for a particular prompt. As dbt Labs’ Jon Lewis expresses it, “The best model is ‘Auto’ and I won’t hear anyone say otherwise.” OpenAI’s own ⁠migration guidance recommends testing models on representative tasks, including trying a lower reasoning level rather than automatically cranking everything to the maximum.

As for me, I’ll probably keep clicking the shiniest option. I don’t have a formal evaluation suite for InfoWorld columns, and the marginal cost is a subscription I already pay. Enterprises don’t get that excuse.

I attended several major technology conferences in 2025 where the first AI agents embedded in enterprise SaaS platforms were announced. Some of these agents showed promise and a glimpse into the future of work, while others looked like natural language extensions of a platform’s existing functionality.  

At the end of 2025, Anthropic and OpenAI launched new AI models and code-generating capabilities. More developers tried vibe coding, and some platforms launched spec-driven development capabilities. By February 2026, even The New York Times reported that the AI disruption had arrived, noting that code generators were building “apps that may be flawed, but credible.”

Wall Street investors took notice of the code-generation improvements and other disruptive factors, driving a selloff in SaaS stocks, now referred to as the “SaaSpocalypse.” Part of their concern stemmed from the belief that CIOs would use AI to write software that would replace SaaS solutions.

AI innovations from SaaS and solution providers

But I thought differently and wrote a response in my article asking whether AI is the end of SaaS as we know it. CIOs might use AI to accelerate application modernization, but I doubt they would replace their ERP, CRM, and even smaller SaaS point solutions by building them.

Instead, I believed it would be SaaS companies that would take the most advantage of AI code-generation capabilities.

This hypothesis drove me to attend nine conferences this spring to see how SaaS companies were launching AI agents and defining a new future of work. I wrote eight articles on what CIOs need to know about data management, agile organizations, marketing, ERPs, critical process management, and other evolutions to plan for in the AI era.

Now, looking across all nine conferences, I can draw some conclusions about how AI agents are shaping the future of work. Here are my learnings and what CIOs need to consider when evaluating and deploying AI agents in the workplace.

Agentic, human-in-the-middle, or augmenting human?

SaaS companies have very distinct perspectives on the future of work, including the extent to which humans will play which roles and whether and how quickly we’ll see agentic, fully automated work.

For example, Atlassian proclaimed, “step into the future of human-AI collaboration,” while SAP unveiled “the autonomous enterprise.” Snowflake aimed to “make AI real for business,” while Appian targeted “serious AI built on process.”

These vendors’ marketers had to decide whether to lead with AI, people, or business in their messaging, but so must CIOs as they contemplate their AI strategies and how to get employees to fully adopt AI agents.

Some CIOs see a fully automated agentic AI as the future, with human-in-the-middle as a transitional phase as departments build trust in AI agents’ decision-making and automation capabilities.

Other CIOs see AI more as a tool that delivers productivity improvements by augmenting human decision-making capabilities. Many of these CIOs see human augmentation as essential to supporting critical thinking, innovation, and creativity.

Deloitte’s State of AI Report, published in January, provides a benchmark. It states that 36% of IT leaders expect at least 10% of their jobs to be fully automated in the next year, and 82% expect to reach that benchmark in three years.

Many organizations will have a mix of AI agents, choosing automation where reliability at scale is possible, but opting for human augmentation in operationally critical or customer-facing domains. But how CIOs position AI agents is not only an operational strategy; it’s also a cultural statement that shapes employees’ embrace of AI and whether detractors vocalize job-loss fears.

In the short term, it will also weigh in on which AI agents to use from different partners and which areas to build in-house.

Many options to test and deploy AI agents

Many solution providers are demonstrating significantly more AI agents this year. For example, SAP went from 40 Joule Agents in 2025 to over 200 in 2026. Three technology capabilities are fueling this significant growth:

• Adobe, Appian, Boomi, Cisco, Domo, Salesforce, SAP, Snowflake, and others offer data fabrics and data-pipeline capabilities to connect data sources outside the primary workflows supported by their platforms. Appian, Pega, Quickbase, and SAP also centralize business process automation, an important starting point for developing AI agents.  
• MCP servers enable integration and communication between AI agents and are used to facilitate multistep agentic workflows. Virtually all the companies announcing major investments in AI agents are also announcing MCP integration capabilities and related partnerships.
• Solution providers are not just using AI code-generating capabilities; many are launching their own AI agent development tools. The first beneficiaries of these development tools are the solution providers themselves and their integration partners, who use them to accelerate the development of AI agents and make them available to customers.

The result is that CIOs will have many options about which agents to test, but will have to dedicate analysts to understand the capability, cost, and compliance trade-offs. Additionally, expect AI agent capabilities to evolve significantly over the next few years, so CIOs should continuously revisit their decisions regarding deployed AI agents, focusing on performance, benefits, and ROI.

CIOs should also watch for signs of shadow AI and employee confusion about which AI agents to experiment with on different platforms. The AI strategy should include a transparent, defined process for selecting, reviewing, evaluating, procuring, deploying, driving adoption, monitoring, and collecting end-user feedback around AI agents.

AI development capabilities for engineers and citizen builders

The apparent ease-of-use of AI code generators may lead some engineering teams to build AI agents rather than buy them from SaaS providers. But CIOs should quickly realize that coding is just one step in developing AI agents, and that aggressively pursuing a build strategy can lead to AI debt and increased AI costs.

DevOps teams can code AI agents using tools such as Claude, Codex, Lovable, and Replit — a do-it-yourself approach. Some SaaS companies are providing an alternative, with AI agent development tools that leverage the data, infrastructure, and governance baked into their platforms. Many of these development tools offer flexibility, allowing developer teams to select AI models and development environments.

Examples of new and enhanced AI development tools I saw at conferences this quarter include:

• Appian Composer and Agent Studio
• Atlassian Rovo Dev
• Boomi Companion
• Cisco Cloud Control Studio
• Domo App Catalyst
• Pega Infinity Studio
• Quickbase Pave
• Snowflake CoCo
• SAP Joule Studio.

I also reviewed Nutanix Agentic AI, a platform-as-a-service for accelerating the deployment of agentic AI workloads, and Adobe Firefly AI Assistant for creatives.

These development tools can target different audiences. Some look like low-code development tools targeted at software developers, whereas others are no-code and enable citizen developers, i.e., businesspeople, to develop applications and agents. Additionally, some of these tools support spec-driven development and generate artifacts such as product requirement documents (PRDs), data models, and testing capabilities.

Before commissioning AI development for apps and agents, CIOs should sponsor proofs of technical, data, modeling, security, and governance capabilities.

The context layer powering AI agents

Between AI agents and the enterprise’s intelligence, including structured data sources, defined business processes, and agent interactions (both human-to-agent and agent-to-agent), lies an evolving “context layer.”

This layer refers to the enterprise knowledge that AI agents draw on when evaluating signals and recommending or taking actions. Context may include a knowledge graph, a semantic layer, cleansed document repositories, and other knowledge bases.

The context layer, skills, tools, out-of-the-box agents, and governance capabilities are some areas to review where solution providers differentiate. Some examples: 

• Many support the Open Semantic Interchange, and some brand their context layers, such as the Atlassian Teamwork Graph, Boomi Knowledge Hub, and the SAP Knowledge Graph.
• Some are branding their guardrails, such as Adobe’s AI Brand Intelligence, Appian’s Private AI, and Quickbase AI Control Center.
• To manage AI agents at scale, some are extending the notion of data catalogs and other governance tools to the AI domain with products such as Boomi Connect, SAP AI Agent Hub, and Snowflake Horizon Catalog.

CIOs should recognize that while solution providers will compete on capabilities, the real “secret sauce” of the context layer lies in the company’s trusted data, well-defined business processes, and employee adoption of AI agents.

Conversational user experiences and coworkers

AI agents use the context layer, but also tap into skills, which encode the procedures they can follow, and tools, which prescribe the actions they can take. Before AI agents are ready to pilot, their governance, including permissions, approval gates, and other guardrails, must be defined. Other capabilities to look for when defining AI agents include orchestration, testing evals, and observability.

In 2025, many solution providers bolted on AI agents to their existing user experiences. This year, many solution providers showcased new conversational user experiences that employees can use instead of traditional ones built with forms, flows, reports, and static dashboards. Conversational user experiences are where AI agents and people come together, whether it’s human-in-the-middle or human augmentation.

Solution providers also grouped their AI agents into assistants or coworkers. For example, Adobe CX Coworker illustrates human augmentation, helping marketers manage campaigns with prompts and monitor their performance. SAP launched Joule Assistants across several business functions, including finance, human capital, supply chain, and customer experience. Other assistants, such as Appian AI Copilot, Atlassian Rovo, Cisco AI Assistant, Nutanix NIVA, and Snowflake CoWork, offer AI-first user experiences to assist different end-user types.

CIOs should demo these AI-first user experiences to glimpse the future of work.

Developers are already getting used to these experiences through code generators and vibe coding tools. Now, similar capabilities are being tailored across all business functions. CIOs should ramp up their change management programs to accelerate the adoption of these AI capabilities.

Solution providers are showcasing AI capabilities that can help CIOs reshape their businesses. But in Q2, there were only a few examples of how AI can help CIOs drive growth, evolve business models, or embed AI into customer-facing products. I expect to see a wave of further AI innovations that will go beyond productivity improvements and efficiencies and help CIOs pursue growth-driving digital transformation strategies.  

Sacolick travelled to conferences mentioned in this article as a guest of Adobe, Appian, Atlassian, Domo, Nutanix, SAP, and Snowflake. In addition, he was hired by Quickbase to speak at its conference.

Over the past decade, software development has been shaped by two closely related transformations. One is the rise of devops and continuous integration and continuous delivery (CI/CD), which brought development and operations teams together around automated, incremental software delivery.

The other is the shift from monolithic applications to distributed, cloud-native systems built from microservices and containers, typically managed by orchestration platforms such as Kubernetes.

While Kubernetes and similar platforms simplify many aspects of running distributed applications, operating these systems at scale is still complicated. Configuration sprawl, environment drift, and the need for rapid, reliable change all introduce operational challenges. GitOps emerged as a way to address those challenges by extending familiar devops and CI/CD techniques beyond application code and into infrastructure and system configuration.

At the heart of GitOps is the concept of infrastructure as code (IaC). In a GitOps model, not only application code but also infrastructure definitions, deployment configurations, and operational settings are described in files stored in a version control system. Automated processes continuously compare the running system with those declarations and work to bring the live environment back into alignment when differences appear.

In this approach, the version control repository serves as the system of record for how applications and their supporting infrastructure should look in production. Changes flow through the same review, approval, and automation pipelines that developers already use for software, bringing greater consistency, traceability, and repeatability to cloud-native operations.

At a high level, GitOps refers to a set of operational practices for managing cloud-native systems using declarative configuration, version control, and automated reconciliation. Rather than treating infrastructure and application configuration as mutable runtime state, GitOps treats them as versioned artifacts that move through the same review, testing, and deployment processes as application code.

GitOps defined

The term GitOps was originally coined and popularized by Weaveworks, which helped formalize the approach in the context of Kubernetes operations. While that early work shaped the way GitOps was discussed and implemented, GitOps has since evolved into a broadly adopted, vendor-neutral pattern. Today, it describes a shared set of ideas rather than a specific product or platform.

The defining characteristic of GitOps is its reliance on declarative configuration stored in a version control system. Instead of issuing imperative commands to change live systems, teams describe the desired state of applications and infrastructure in configuration files. Automated agents then continuously compare that declared state with what is actually running and work to reconcile any differences. This pull-based model—where systems converge toward the desired state defined in version control—provides built-in drift detection, repeatability, and a clear audit trail for every change.

Because GitOps centers on configuration files stored in a version control system, familiar software development practices carry over naturally. Changes are proposed through commits, reviewed before being accepted, and tracked over time. Rollbacks are accomplished by reverting to known-good versions, and the history of how a system evolved is preserved alongside the configuration itself.

While the use of Git as the version control system is not strictly required, it has become the default choice because of its ubiquity in modern devops workflows and its strong support for collaboration and change management, so its place in the name has stuck.

What is the CI/CD process?

A complete look at CI/CD is beyond the scope of this article—see the InfoWorld explainer on the subject—but we need to say a few words about CI/CD because it’s at the core of how GitOps works. The continuous integration half of CI/CD is enabled by version control repositories like Git: Developers can make constant small improvements to their codebase, rather than rolling out huge, monolithic new versions every few months or years. The continuous deployment piece is made possible by automated systems called pipelines that build, test, and deploy the new code to production.

Again, we keep talking about code here, and that usually summons up visions of executable code written in a programming language such as C or Java or JavaScript. But in GitOps, the “code” we’re managing is largely made up of configuration files. This isn’t just a minor detail — it’s at the heart of what GitOps does. These config files are, as we’ve said, the “single source of truth” describing what our system should look like. They are declarative rather than instructive. That means that instead of saying “start up ten servers,” the configuration file will simply say, “this system includes ten servers.”

GitOps and Kubernetes

GitOps first took hold in the Kubernetes ecosystem, where declarative configuration and continuous reconciliation are core design principles. As a result, Kubernetes remains the most common and best-understood environment for applying GitOps practices. A typical GitOps-driven update process for a Kubernetes application looks like this:

1. A developer proposes a change by committing updated application code or configuration to a version control repository, usually through a pull request.
2. That change is reviewed and approved, then merged into the main branch.
3. The merge triggers an automated CI/CD pipeline that tests the change, builds new artifacts if needed, and publishes them to a registry.
4. A GitOps controller or similar automated agent detects the updated desired state stored in version control.
5. The controller compares that desired state with the current state of the Kubernetes cluster and applies the necessary changes to bring the cluster back into alignment.

This pull-based reconciliation loop—where the cluster continuously converges toward the desired state defined in version control—is central to how GitOps works in practice. While Kubernetes provides a natural fit for this model, it represents just one canonical use case. The same patterns increasingly apply to infrastructure provisioning, policy enforcement, and multi-cluster operations beyond Kubernetes itself.

GitOps tooling in practice: Argo CD, Flux, and the ecosystem

GitOps is enabled by a set of tools that embody the principles we’ve outlined, with some open-source projects emerging as de facto standards in cloud-native environments.

At the center of the GitOps ecosystem is Argo CD, an open-source controller that continuously monitors a version control repository and ensures that the state of running systems matches the declared desired state. Argo CD is widely used in Kubernetes environments because it directly implements pull-based reconciliation: it compares the desired state stored in Git with the cluster’s actual state and applies changes to correct any drift.

Alongside Argo CD, Flux is another prominent open source GitOps engine. Both Flux and Argo CD help teams adopt GitOps workflows by managing the synchronization loop between code and runtime, but they differ in operational philosophy, integration surfaces, and ecosystem fit.

GitOps tooling often appears as part of broader platforms or integrated stacks rather than as isolated utilities. For example, multicloud and cluster management solutions now routinely include GitOps support, with Argo CD or compatible controllers bundled alongside deployment, policy, and governance capabilities.

In addition to Flux and Argo CD, a range of auxiliary tools contribute to a complete GitOps ecosystem: policy as code engines (e.g., Open Policy Agent), drift detection systems, and infrastructure provisioning tools that mesh with Git-centric workflows.

GitOps, devops, and normalization

GitOps grew out of the same forces that drove devops into mainstream IT practice, and in its early days, GitOps was often discussed as a distinct extension of devops, specifically tailored to managing declarative infrastructure and Kubernetes-centric systems. At the time, GitOps was still relatively new and not yet widely adopted outside cloud-native pioneers.

Over the last several years, however, GitOps practices have become deeply woven into how teams operate modern cloud environments. Rather than being treated as an optional add-on or marketing term, the core ideas of GitOps — using version-controlled, declarative configuration and automated reconciliation loops to continuously align running systems with intended state — are now part of standard operational practice in many Kubernetes-centric shops. In this sense, GitOps has shifted from a buzzword about what might be possible to a baseline pattern for cloud-native operations, much like devops itself did years earlier.

In environments where Kubernetes and declarative systems are the norm, GitOps workflows are the default way teams manage and deploy change. Many organizations now implement these patterns without explicitly calling them “GitOps,” just as few teams today explicitly say they do “CI/CD” even though continuous pipelines are taken for granted. The term has become less prominent in marketing, but its practices are often embedded in pipelines, controllers, and platform tooling.

That normalization shows up in how GitOps workflows are woven into broader operational frameworks. For example, platform engineering teams frequently build internal developer platforms that encapsulate GitOps patterns behind standardized developer APIs, making the pattern invisible to most application teams while still providing the auditability and automation that GitOps promises.

GitOps beyond Kubernetes: infrastructure, policy, and drift

While GitOps first gained traction as a way to manage Kubernetes deployments, its core principles apply broadly to infrastructure and operational concerns beyond any single orchestration platform. GitOps treats desired state as declarative configuration stored in version control and uses automated reconciliation to ensure running systems align with that state. That pattern naturally extends to infrastructure provisioning, policy enforcement, configuration drift detection, and governance workflows across diverse environments.

In modern operational stacks, infrastructure is increasingly defined declaratively, whether through Kubernetes manifests, Terraform modules, or other infrastructure-as-code formats. Storing these declarations in version control enables the same peer-review, auditability, and rollback practices developers already use for application code. Automated tooling then continuously detects when the live infrastructure diverges from the declared state and works to bring it back into alignment, reducing the risk of configuration drift and inadvertent misconfigurations.

Configuration drift — the state where an environment has diverged from what’s declared in version control — remains a major operational headache, especially in complex, dynamic systems. Drift can arise from ad hoc fixes, emergency updates, or manual changes made outside normal pipelines, and it can lead to inconsistencies, outages, and security gaps. By continually checking running systems against the desired state in Git and reconciling deviations automatically, GitOps workflows help teams keep environments predictable and auditable.

Policy enforcement and compliance are another natural extension of GitOps patterns. As organizations adopt declarative practices, policy-as-code engines and drift detection systems can be woven into GitOps pipelines to validate that proposed configurations meet security, compliance, or operational standards before they’re ever applied to running systems. Embedding policy checks into declarative workflows brings consistency to governance while preserving the automation and speed that devops teams expect.

GitOps – beyond Kubernetes

GitOps began as a way to bring devops discipline to Kubernetes operations, but its longer-term impact has been more subtle. In many ways, it’s been absorbed into the fabric of modern cloud-native operations, where declarative configuration, version control, and automated reconciliation are taken for granted. Today, GitOps is less about a specific set of tools or a named practice and more about an operational mindset. By treating infrastructure and configuration as versioned, auditable artifacts and relying on automation to enforce consistency, GitOps helps teams manage complexity at scale. Even as the term itself fades from the spotlight, the practices it introduced continue to shape how distributed systems are built, deployed, and operated.

Every day this past week I did something I suspect millions of other people also did: I stared at an LLM model picker and wondered which one I was supposed to want.

OpenAI just released ⁠GPT-5.6 Sol, Terra, and Luna. Sol is the flagship. Terra offers much of its intelligence for less money. Luna is cheaper still. Anthropic released ⁠Claude Sonnet 5 at the end of June and Opus 4.8 the month prior, with a little Fable 5 emerging in between. Meanwhile, Google, which seemed to be winning the model wars a few months ago, is now getting shade from Gergely Orosz, who ⁠argues that Gemini has slipped outside the top tier for software development and has been out of the major model release game for eons (May 19).

Perhaps Orosz is right. Perhaps he’ll be wrong again in six weeks. Honestly, it’s exhausting.

I use ChatGPT and Claude constantly and still have no principled idea which model to choose most of the time. I tend to click whatever looks like the biggest, most expensive option because I don’t know what I’m giving up by choosing something smaller. “Instant” sounds dangerously unserious. “Thinking” sounds expensive but powerful.

A quick survey of my LinkedIn crowd suggests others also feel my “WHICH MODEL???” pain. More importantly, I suspect most enterprises do, too.

A model doesn’t rot

Before getting carried away, however, it’s worth considering whether any of this model churn actually matters. After all, a model doesn’t rot. The model an enterprise put into production in March performs just as well in July as it did when the company selected it. “Obsolete” generally means that something better now exists, not that the deployed model suddenly stopped summarizing insurance claims or classifying support tickets. (In other words, once you have something working, the idea that “but maybe Opus 200.2 is better!” is really a FOMO problem, not a performance issue.)

Most enterprise workloads don’t live at the frontier anyway. Extraction, summarization, classification, document comparison, and customer-service assistance often work perfectly well with smaller, cheaper models. OpenAI’s own pitch for the trio of GPT-5.6 models isn’t simply that Sol is better. It’s that ⁠Terra and Luna deliver different combinations of intelligence, latency, and cost. Luna, the cheapest tier, nearly matches the previous generation’s peak performance at less than half the estimated cost, according to OpenAI.

The practical question, of course, is where to start. An enterprise can’t test every model, every reasoning setting, and every price tier before doing any work. So here’s my advice (which I don’t follow in my own work, but I’m not defining enterprise strategy and can be a little price-insensitive). Start with the cheapest credible model that appears capable of the task. Give it a representative set of real examples and, before you start testing, define what counts as good enough. If it passes, stop. If it fails, move up a tier or try a model with strengths better suited to the work.

That sounds almost offensively simple, but it reverses the way many people, including me, use these products. We start with the biggest model because we’re afraid of what we might lose. Enterprises should start lower and require evidence before paying for more intelligence.

There are exceptions, of course. For genuinely difficult work, such as autonomous coding, complex research, or high-stakes reasoning, beginning with a frontier model may save time. But even then, the goal should be to establish a quality ceiling, then test whether a cheaper model can meet it. It’s changing the question from “which model is best?” to “what is the least expensive model that reliably clears the bar for this job?”

For many workloads, that price improvement matters more than a few extra benchmark points. ⁠As I argued back in 2023, following AI hype doesn’t help anyone. If your model strategy depends on whichever benchmark screenshot is circulating on X this week, you don’t have a strategy. Not a viable one, anyway. Pick a model and ignore the noise.

Except, of course, when that noise suggests a serious signal.

Sometimes better really is better

Frontier improvements aren’t always incremental, making it advantageous to consider an upgrade. Coding is the obvious example. There’s a significant difference between a model that suggests the next few lines of code and one that can inspect a repository, plan a change, use tools, run tests, discover its own mistakes, and keep working for an extended period. That isn’t merely a nicer autocomplete experience. It can reorganize a development workflow.

This is why enterprises can’t simply standardize on an 18-month-old model and declare victory. In some areas, particularly software development and other agentic work, better models can unlock compounding productivity. A model that reliably completes 80% of a bounded task rather than 50% may justify an entirely different division of labor between humans and machines.

Still, that upgrade isn’t free.

Models differ in how they interpret instructions, call tools, manage context, refuse requests, and fail. Prompts and scaffolding tuned for one model can regress when moved to another. Or costs can explode. As one of my Oracle colleagues discovered just this week, running the same tasks in GPT 5.6 was orders of magnitude more expensive than 5.5. The API change may be trivial, but the revalidation and implications are not.

This leaves enterprises caught between two bad options. They can freeze and potentially miss out on meaningful improvements or chase every release and repeatedly test production systems on faith. What to do?

Stop making model bets

The answer is to stop making LLM bets and start making job-to-be-done bets. Stop asking which model is fastest. Instead, figure out what work you are trying to improve. What does a good result look like? How much latency and cost can the workflow tolerate? How wrong can it be before a human must intervene? Once those questions have answers, model selection becomes less opaque.

A difficult code migration may justify GPT-5.6 Sol or Claude Sonnet 5. A repetitive classification task may work just as well with Luna or another smaller model. A regulated workflow may require a model or deployment option that offers particular data controls. Sometimes the correct model is no LLM at all, like when I’m writing this post. Sorry, AI vendors! (At least you won’t get blamed for my mistakes.)

This is where evaluations become the center of enterprise AI strategy. ⁠As I’ve said before, most companies don’t have an AI quality problem so much as an AI measurement problem. Hence, a private evaluation suite built from real company work is the only leaderboard that matters. Does the new model materially improve quality? If so, use it! Does it reduce cost or latency? Again, that’s your free pass to adoption. Does the improvement justify the expense and effort of revalidation? If yes, continue.

Make model releases boring

As important as the model is, keep in mind that AI success always comes back to your company’s data, your company’s workflows, your company’s integrations, etc. That’s the ⁠dull reality behind sexy AI. Retrieval, memory, governance, data quality, observability, and feedback loops aren’t as exciting as a new model launch, but they’re what ultimately make AI truly work.

Again, when it’s time to consider something new, the principle should be to default to the least expensive model that reliably passes your evaluations. Only escalate harder tasks to more capable models when measurement shows that the premium pays. Tip: Make this invisible to employees so that the system routes to the best model for a particular prompt. As dbt Labs’ Jon Lewis expresses it, “The best model is ‘Auto’ and I won’t hear anyone say otherwise.” OpenAI’s own ⁠migration guidance recommends testing models on representative tasks, including trying a lower reasoning level rather than automatically cranking everything to the maximum.

As for me, I’ll probably keep clicking the shiniest option. I don’t have a formal evaluation suite for InfoWorld columns, and the marginal cost is a subscription I already pay. Enterprises don’t get that excuse.

The quantum computing industry has a supply-chain problem: The companies that could make the specialized lasers, cryogenics, and photonics it depends on don’t have enough of a market yet to invest in creating these products.

An executive order signed Monday aims to fix that, directing the government to strengthen domestic component manufacturing and partner with the private sector to fill the gaps. In addition, the order tells the Department of Energy to lead the development of a useful quantum computer, assess the performance of quantum computers, and track how close quantum computers are to being able to break encryption. The order also calls for tighter export controls of key quantum technologies and launches a hiring push for quantum talent.

Celia Merzbacher, executive director at Quantum Economic Development Consortium, says the order is “extremely encouraging.”

“It is a sign from the highest level of government that quantum is important,” she tells Network World.

On Tuesday, the Energy Department followed up with its announcement of Quantum Genesis, an initiative to create and deploy what it called the world’s first scientifically relevant, fault-tolerant quantum computer. Quantum computing is a key component of the Genesis Mission, announced at the end of 2025.

Monday’s executive order didn’t include any funding for the new quantum computing strategy but says that it is “subject to the availability of appropriations” and directs the Energy Department to “explore potential private-sector partnership models.”

The next step, according to Merzbacher, is to get the funding in place. “So there’s a role for Congress to write the checks and follow up and do the work that needs to be done,” she says.

The supply chain piece is particularly important. “Quantum is still at a fairly early stage, and the markets aren’t big,” she says. “There isn’t a market engine or flywheel yet.”

Specifically, quantum computing needs electronics, cryogenic technologies, lasers, photonics, and optics, she says. “And there are a lot of players in those areas.”

Some of them are getting into the quantum sector as a business — but some are not, because they see the market as too small, she says. “So, how do you get that flywheel going? One of the things the government can do is send some signals that as the technology comes along, there will be a market, whether that’s the government paying for acquiring some systems and putting them out there for researchers to use, or some other way of sending a demand signal to get the business case to the companies that can actually develop and make the technology.”

The executive order also addresses the issue of assessing the performance of quantum computers. Benchmarks have been lacking in the quantum space.

“It’s not easy to compare quantum computers in an apples-to-apples way because the quantum computer systems aren’t that stable yet,” Merzbacher says. “If you run it in the morning and in the afternoon, you get a different performance.”

By comparison, in AI, there are a number of benchmarks comparing AI models on everything from how well they do at math, to their ability to generate images, to whether they can find bugs in computer code.

Benchmarks are important so that people can do fair comparisons of quantum systems, says Juliette Peyronnet, US general manager at Alice & Bob, a quantum computing company.

“We know Sandia, the national lab, is working on one, and we hope it will be out soon, but it’s not there yet,” she tells Network World. “We want an organization like Sandia to come out with a benchmark that’s not from a vendor.”

Read more about quantum computing and HPC

• IBM sends signals with its $10 billion quantum pledge: “The quantum era is no longer ahead of us, it has started,” said IBM CEO Arvind Krishna in statement tied to news that the company is committing $10 billion to advancing quantum computing and commercializing the technology.
• New tool on AWS makes it easier to develop quantum error correction: Quantum computers are no longer a physics challenge but an engineering one, and quantum error correction is the heart of what’s going to make quantum computing a reality. A new tool uses AI-powered digital twins to make it easier for researchers to solve this challenge, and it’s available on AWS.
• Quantum computing is getting closer, but quantum-proof encryption remains elusive: The day when quantum computers will be able to break conventional encryption is rapidly approaching, but not all companies are prepared to implement post-quantum cryptography.
• China’s LineShine is the world’s fastest supercomputer: The debut of China’s LineShine on the June 2026 edition of the TOP500 rankings ends El Capitan’s run at the top the list and marks the first time a China-based system has led the rankings since Sunway TaihuLight in 2017.
• Curious about quantum? Check out training options from ISC2, IBM, AWS and more: ISC2 released a 30-minute primer on the cybersecurity implications of quantum computing. If you want to dig deeper, there are many quantum training options that don’t require going back to school for a PhD.
• Top quantum breakthroughs of 2025: 10 areas in which we’ve seen significant breakthroughs and milestones in quantum computing.

As AI adoption grows, I see fellow enterprise leaders realizing that just implementing AI is not enough. We need to develop and adopt the best, fastest and most efficient AI models. It’s not just a matter of pride about who has the shiniest toy; optimizing models for efficiency can be the difference between a failed pilot and an effective business strategy.

At the most extreme end of the spectrum, inefficient use of AI can cost billions of dollars. Sam Altman, CEO of OpenAI, made headlines when he admitted on X that his company loses tens of millions of dollars every time people say “please” and “thank you” to his AI models, even though he added that he feels it’s money well spent.

Model efficiency also matters for those of us not operating at OpenAI’s scale. A more efficient model helps reduce overall costs because it doesn’t require as powerful or expensive hardware, uses less electricity, delivers output faster and can operate with a smaller cloud footprint.

Models that are optimized for efficiency deliver lower latency, improved scalability, increased flexibility and are less likely to drift. In my experience, all of this adds up to higher profit margins, a sharper competitive edge and a faster time to market, which are crucial whether you’re planning to use your model internally or sell it to others.

The new CIO investment dilemma

For a long time, it was believed that hardware must continually increase in power to enable models to grow in size. Then DeepSeek v2 came along and demolished all those theories. It showed that more efficient hardware can deliver equivalent results with less compute power by running smaller, smarter models.

Now, those of us in the CIO seat face a new dilemma: should we increase investment in computing power, focus on hardware or concentrate on software?

In my view, the correct answer is: all the above. AI efficiency is a full-stack problem. Hardware, compilers, runtime and model architecture must be co-designed to work in harmony; otherwise, we’re wasting money and failing to achieve the results we need. Today, choosing GPUs vs. custom accelerators vs. CPUs affects which model optimizations are viable.

Hardware power constraints model capabilities

It remains true that even the most powerful model in the world can’t function without access to the necessary hardware. Hardware performance is ultimately bounded by memory bandwidth, interconnect speed and compute units, no matter how optimized our models are.

This means that scalability depends on interconnects. Multi-node training and large inference clusters hinge on the performance of NVLink, InfiniBand or Ethernet fabric, not just model quality, so decisions about hardware investments or cloud providers can be critical to overall functionality.

“The pace of innovation is directly tied to advances in GPUs, tensor processing units (TPUs) and custom accelerators. The real question isn’t just what models we can build, but whether we have the compute infrastructure to support them,” says Gaurav Dewan, a research director at Avasant. “Models can only grow as powerful as the chips, memory systems and data center networks sustaining them.”

Compute power isn’t everything

That said, in my experience, you can’t just throw computing power at every problem. Choices about hardware and cloud architecture determine how effectively users can tap into the potential of compute resources. Modern AI workloads are often memory-bound rather than compute-bound, so faster HBM, cache hierarchies and interconnects directly lower latency.

What’s more, the energy for computing power is limited. Companies can’t always afford the compute power they want, with 58% saying their AI cloud costs are too high. Cost per inference is hardware-driven and compute is usually the biggest line item in AI TCO. It’s not even easy to find space for enough GPUs, creating board-level power and cooling constraints in enterprise AI. More efficient silicon reduces data center strain, sustainability risk and cost per token/inference.

Additionally, reliability and utilization affect ROI. Features like MIG partitioning, hardware scheduling and fault tolerance determine how fully we can monetize expensive accelerators. Performance per watt is now the bottom line, with CIOs like me striving to get more out of every existing GPU per watt, dollar and square meter. We need to make our hardware more efficient by fine-tuning models and software to maximize capability.

“DeepSeek’s breakthrough suggests that AI models no longer need to scale indefinitely in size and complexity to achieve superior performance. Instead, they can be algorithmically optimized to deliver the same, if not better, results while consuming significantly fewer resources,” explains Matthew Taylor in his post on LinkedIn.

Rethinking cloud strategy in the age of AI

That cost pressure has forced many of us to revisit assumptions we held for the better part of a decade. Cloud computing has reached an uncertain crossroads. The hyperscaler-by-default posture that defined the last era of enterprise IT no longer survives a serious look at AI economics.

When inference costs scale linearly with usage and training runs can consume an annual infrastructure budget in weeks, the question I hear in every CIO conversation is the same: does our cloud strategy still match the workload we are actually running?

In my experience, the answer is increasingly no, at least not without significant rebalancing. Private clouds, written off as legacy not long ago, are quietly making a comeback. The combination of predictable cost structures, tighter control over data residency and the sensitivity of the proprietary data feeding our AI systems is making on-premise and colocation options compelling again, particularly for regulated industries.

At the same time, purpose-built neoclouds for GPU workloads, along with sovereign clouds responding to jurisdictional and data-protection mandates, are steadily chipping away at the dominance of AWS, Azure and GCP. None of these alternatives replace the hyperscalers outright, but they are forcing every CIO I know to think about cloud as a portfolio rather than a single vendor relationship.

What I have found is that navigating this shift takes more than a procurement decision. It takes a clear-eyed view of where each workload genuinely belongs. Training, inference, retrieval, fine-tuning and experimentation each carry different cost curves, latency profiles and data-gravity considerations. As organizations move towards the agentic AI era, the underlying data platform becomes equally important, requiring architectures that can support multimodal data, real-time processing and governance at scale.

The enterprises I have seen handle this best treat cloud strategy as an ongoing exercise in workload placement, not a one-time platform commitment.

That is also where the conversation tends to outgrow internal teams.

As AI moves from pilots to production, the questions get harder: how to architect data foundations that survive model churn, how to govern AI without strangling it, how to translate technical efficiency into measurable business value. I have seen organizations lean on specialist partners to think through these problems alongside them. Among the consultancies working at this intersection is Artefact, founded in Paris and operating across data strategy, AI engineering and enterprise transformation. Its work includes governance, platform development, operating models and workforce enablement—areas that have become increasingly important as organizations move from AI pilots to large-scale deployment.

What I find useful about these consultancies is not the technology recommendations themselves; it is the pattern recognition they bring from seeing similar cloud and AI transitions play out across geographies and sectors. In a moment when every CIO is rewriting the playbook simultaneously, that outside vantage point matters more than it used to.

Hardware is often underused and misused

A lot of hardware goes unused or underutilized. Often, GPUs sit idle due to deployment complexity and data infrastructure bottlenecks, so enterprises don’t see the value of the compute power they’re paying for. When data and computing are on two separate chips, compute is wasted moving data between the two locations.

Likewise, models that exceed accelerator memory or require excessive HBM traffic suffer steep latency and cost penalties. Optimizing models to align with hardware means that all the compute power is being put to good use.

Techniques like operator fusion, activation management, fine-tuning smaller models, pruning unnecessary parameters and memory-aware architectures keep more of the model resident on the accelerator, reduce unnecessary read/write cycles and combine steps so data is touched fewer times.

Kfir Aberman, founding member at Decart AI, explains this approach. “Our solution to this was to optimize our kernels for how [Nvidia GPU] Hopper works. Essentially, we created a single ‘mega kernel’ that enables the chip to process all of a model’s computations in a single, continuous pass. By doing this, we eliminate all of the stopping, starting and data movement, allowing more of the GPU to be utilized more of the time, speeding up processing by an order of magnitude.”

When models match accelerator characteristics such as tensor core shapes, SIMD widths and kernel libraries, this keeps expensive silicon working effectively and translates theoretical FLOPs into real throughput.

More hardware can’t overcome model mismatch

Another way that organizations undermine ROI on their own AI investments is by ignoring coordination efficiency.

They’ll buy large GPU clusters but pay little attention to what seem like minor issues with batching and alignment. Unfortunately, when batch sizes are wrong, work is split inefficiently and network links become bottlenecks, you see expensive but underutilized clusters.

Ultimately, more GPUs don’t guarantee more performance. Parallelism and batching must match the system topology. Effective scaling depends on aligning data, tensor and pipeline parallelism and batch sizing with the actual interconnect bandwidth and node configuration.

The magic happens when model and hardware come together

The lesson that those of us in CIO roles are learning is that symbiosis between model and hardware is critical. Code determines what our AI can do, hardware determines how efficiently we can afford to do it and co-design determines whether our AI program scales economically and successfully.

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

Enterprises may soon be paying as much for their developers’ AI token usage as they do for their salaries.

According to Gartner, these costs will meet, or even exceed, the typical software engineer’s monthly salary within the next two years.

This is not only because developers are increasingly adopting generative AI and agentic tools, it reflects a trend toward consumption-based licensing models as vendors balance infrastructure investments with profitability. Rather than the flat per-seat SaaS model of the past, enterprises now pay for developer token use as well.

Gartner senior principal analyst Nitish Tyagi explained that it’s important to note that Gartner’s prediction is based on a global average salary of $2,000 per month; it doesn’t mean AI token usage will exceed all salaries. For instance, in the US, yearly pay rates can be six digits or more.

However, that kind of spend is not out of the realm of possibility, Tyagi emphasized. “I have heard scary numbers like ‘My developer consumed $20K last month,’ or ‘A business user consumed $32K’.”

If these amounts sound shocking, that’s the point. “The goal is to alarm the industry about the impact of token cost if it is not governed and controlled,” he said.

Lack of visibility, immature oversight

Enterprises are quickly moving from experimentation to scaled deployment of AI coding agents, but many still underestimate token costs, Tyagi noted.

This is because cost structures for software engineering workloads are “highly variable,” he pointed out, and there isn’t a lot of transparency into how token consumption is calculated and billed.

AI coding vendors have yet to deliver “mature, built-in cost optimization capabilities,” Tyagi said, and prices will likely only continue to rise as vendors further build out their models while at the same time trying to remain profitable.

Thus, enterprises struggle to forecast and control costs, and, because AI is moving so fast, many organizations lack the “maturity and frameworks” to determine ROI, he noted. Agent-driven workflows are difficult to govern, context windows become bloated, budgets are wiped out earlier than anticipated, and token spend becomes hard to justify.

Added to this, light users such as non-developers will increase their usage as they become more familiar with, and even reliant on, AI tools, driving up token consumption and spend even more.

Tyagi said that, while AI is incredibly valuable, he sees no “direct relationship” between the number of tokens developers consume and their productivity gains. Rather, applying context engineering principles to optimize or reduce token consumption increases quality.

“Tokenmaxxing is not directly related to higher productivity gains,” Tyagi said, “but optimizing token consumption is.”

Still, this in no way means that organizations should move away from AI coding agents, he emphasized. Optimizing token consumption simply means spending only as much as needed without compromising the quality and value brought by AI.

“Without a governed engineering operating model, costs can escalate faster than the productivity gains these tools are designed to deliver,” Tyagi said.

How enterprises can control token usage

The traditional ‘lines-of-code-written’ productivity metric no longer applies when AI can almost instantaneously produce entire Python libraries. Rather, value should be measured in quality, speed, and customer satisfaction metrics, Tyagi said.

For instance: How quickly are developers able to release important features? How much time is reduced between app development and feedback from business, product, and development teams? Shipping features quickly while maintaining quality can create competitive advantage and improve user and customer experience, he said.

Gartner also advises establishing strong governance and cost controls. For instance, introduce token thresholds, automate usage monitoring, and create explicit escalation policies.

“Embedding these controls into engineering workflows ensures consistency and prevents uncontrolled cost growth,” the firm notes.

In addition, enterprises should create a “use case driven” decision framework. This means clearly defining when AI coding agents should be used, and their appropriate levels of autonomy given certain tasks. Further, classify those tasks into three execution models: ‘developer‑led,’ ‘developer‑with‑agent’, and ‘fully agent‑led.’

Enterprises should also select models based on task complexity. Break work into smaller tasks that can be performed by smaller models, “with escalation only when complexity demands it,” Gartner advises. Engineering teams should route workflows deliberately, directing simpler, high-frequency tasks to smaller models and using frontier models only for complex and high-value work.

Another cost saving tactic is mandating specific context engineering practices, the firm says. Developers should be trained to optimize the context they input to AI, including only the information that’s relevant, summarizing that content as much as possible, and eliminating unnecessary data.

Further, teams should embed token usage reviews into development cycles. Regular review of high token consuming workflows can help identify inefficiencies, refine practices, and support collaboration, Gartner says.

Tyagi noted that developers tend to optimize for speed and convenience rather than cost efficiency, so token discipline cannot be achieved through developer choice alone.

His advice for leaders: Do not treat escalating AI coding costs as a reason to move away from AI, or to shift to open generative AI models for everything. “The goal is always to optimize costs without compromising the value.”

Start small, and focus on context engineering first, he said. Assess your current software engineering maturity and select the appropriate agent autonomy. AI assistive development can provide up to 20% productivity gains, “which is not a bad number.”

For developers, he advises: “Target context engineering as one of the most important skills for yourself. This is not only going to help your employer, but also your career.”

This article originally appeared on CIO.com.

Enterprises may soon be paying as much for their developers’ AI token usage as they do for their salaries.

According to Gartner, these costs will meet, or even exceed, the typical software engineer’s monthly salary within the next two years.

This is not only because developers are increasingly adopting generative AI and agentic tools, it reflects a trend toward consumption-based licensing models as vendors balance infrastructure investments with profitability. Rather than the flat per-seat SaaS model of the past, enterprises now pay for developer token use as well.

Gartner senior principal analyst Nitish Tyagi explained that it’s important to note that Gartner’s prediction is based on a global average salary of $2,000 per month; it doesn’t mean AI token usage will exceed all salaries. For instance, in the US, yearly pay rates can be six digits or more.

However, that kind of spend is not out of the realm of possibility, Tyagi emphasized. “I have heard scary numbers like ‘My developer consumed $20K last month,’ or ‘A business user consumed $32K’.”

If these amounts sound shocking, that’s the point. “The goal is to alarm the industry about the impact of token cost if it is not governed and controlled,” he said.

Lack of visibility, immature oversight

Enterprises are quickly moving from experimentation to scaled deployment of AI coding agents, but many still underestimate token costs, Tyagi noted.

This is because cost structures for software engineering workloads are “highly variable,” he pointed out, and there isn’t a lot of transparency into how token consumption is calculated and billed.

AI coding vendors have yet to deliver “mature, built-in cost optimization capabilities,” Tyagi said, and prices will likely only continue to rise as vendors further build out their models while at the same time trying to remain profitable.

Thus, enterprises struggle to forecast and control costs, and, because AI is moving so fast, many organizations lack the “maturity and frameworks” to determine ROI, he noted. Agent-driven workflows are difficult to govern, context windows become bloated, budgets are wiped out earlier than anticipated, and token spend becomes hard to justify.

Added to this, light users such as non-developers will increase their usage as they become more familiar with, and even reliant on, AI tools, driving up token consumption and spend even more.

Tyagi said that, while AI is incredibly valuable, he sees no “direct relationship” between the number of tokens developers consume and their productivity gains. Rather, applying context engineering principles to optimize or reduce token consumption increases quality.

“Tokenmaxxing is not directly related to higher productivity gains,” Tyagi said, “but optimizing token consumption is.”

Still, this in no way means that organizations should move away from AI coding agents, he emphasized. Optimizing token consumption simply means spending only as much as needed without compromising the quality and value brought by AI.

“Without a governed engineering operating model, costs can escalate faster than the productivity gains these tools are designed to deliver,” Tyagi said.

How enterprises can control token usage

The traditional ‘lines-of-code-written’ productivity metric no longer applies when AI can almost instantaneously produce entire Python libraries. Rather, value should be measured in quality, speed, and customer satisfaction metrics, Tyagi said.

For instance: How quickly are developers able to release important features? How much time is reduced between app development and feedback from business, product, and development teams? Shipping features quickly while maintaining quality can create competitive advantage and improve user and customer experience, he said.

Gartner also advises establishing strong governance and cost controls. For instance, introduce token thresholds, automate usage monitoring, and create explicit escalation policies.

“Embedding these controls into engineering workflows ensures consistency and prevents uncontrolled cost growth,” the firm notes.

In addition, enterprises should create a “use case driven” decision framework. This means clearly defining when AI coding agents should be used, and their appropriate levels of autonomy given certain tasks. Further, classify those tasks into three execution models: ‘developer‑led,’ ‘developer‑with‑agent’, and ‘fully agent‑led.’

Enterprises should also select models based on task complexity. Break work into smaller tasks that can be performed by smaller models, “with escalation only when complexity demands it,” Gartner advises. Engineering teams should route workflows deliberately, directing simpler, high-frequency tasks to smaller models and using frontier models only for complex and high-value work.

Another cost saving tactic is mandating specific context engineering practices, the firm says. Developers should be trained to optimize the context they input to AI, including only the information that’s relevant, summarizing that content as much as possible, and eliminating unnecessary data.

Further, teams should embed token usage reviews into development cycles. Regular review of high token consuming workflows can help identify inefficiencies, refine practices, and support collaboration, Gartner says.

Tyagi noted that developers tend to optimize for speed and convenience rather than cost efficiency, so token discipline cannot be achieved through developer choice alone.

His advice for leaders: Do not treat escalating AI coding costs as a reason to move away from AI, or to shift to open generative AI models for everything. “The goal is always to optimize costs without compromising the value.”

Start small, and focus on context engineering first, he said. Assess your current software engineering maturity and select the appropriate agent autonomy. AI assistive development can provide up to 20% productivity gains, “which is not a bad number.”

For developers, he advises: “Target context engineering as one of the most important skills for yourself. This is not only going to help your employer, but also your career.”

The SaaS and AI software markets have entered an era of pricing upheaval, with some new pricing models that can benefit IT leaders and some that may burn through their budgets.

The global software marketplace may be headed toward a widespread pricing reset, as AI products that compete with traditional SaaS offerings force vendors to rethink per-seat pricing, many observers say.

Pricing for traditional SaaS products is trending toward outcome-based billing, which is generally good news for CIOs and CFOs. At the same time, however, pricing for some AI tools, and some SaaS packages, is moving toward consumption-based billing, which can lead to huge invoice surprises if IT leaders don’t keep a close eye on employee usage.

CIOs should expect major pricing changes — and the need to deal with pricing uncertainty — as software vendors respond to competition and market demand, says Sidharth Ramsinghaney, director of strategy and operations at CRM data platform provider Twilio.

“The most immediate problem is budget volatility that most organizations have never had to manage before,” he says. “The shift transfers forecasting risk from vendor to buyer.”

At least 40% of enterprise SaaS spending will shift toward usage-, agent-, or outcome-based pricing by 2030, Gartner has predicted, with seat-based vendor revenue share declining from 21% to 15%. As recently as late 2025, however, some SaaS vendors were hiking prices.

AI agents, in particular, have the potential to disrupt pricing models, Ramsinghaney says. “That projection holds if AI agents continue replacing human task execution,” he adds. “AI agents have decoupled labor from value, making per-seat pricing obsolete when one agent does work that previously required 10 employees.”

However, if agent adoption stalls, per-seat pricing may have more longevity than current predictions suggest, he says, and with uncertainty about the most profitable pricing model, hybrid pricing may become the default.

Questions about outcomes

Meanwhile, even though some customers have pushed for, and some vendors have experimented with, outcome-based pricing, it’s not an easy model to figure out, Ramsinghaney says.

“Pure outcome-based pricing stays aspirational for most categories because outcome attribution is genuinely hard to measure cleanly,” he adds.

Jasper Geurts, CTO at software consulting firm Software Improvement Group, agrees that outcome-based pricing is difficult to implement. Many AI vendors, for example, are combining seat-based pricing with usage, instead of focusing on outcomes, he says.

Vendors will continue to experiment with outcome- and usage-based models, but there’s an ongoing debate over what counts as an outcome, he notes.

 “An agent can pass every acceptance test and still produce code nobody can safely evolve,” he explains. “If you pay only for functional outcomes, you are paying vendors to create technical debt.”

While some SaaS vendors look at outcome-based or hybrid pricing models, it’s a different story with AI vendors, Geurts says. The cost for frontier AI models is going up, not down, with Anthropic’s new Fable 5 model costing double the per-token price of Opus 4.8, he notes.

“CIOs tell me the token economy is opaque,” he says. “You cannot forecast a bill when agents decide how many tokens to burn. CIOs should treat tokens like cloud spend a decade ago: Meter it, govern it, tie it to outcomes.”

Still, token pricing isn’t fixed, with both OpenAI and Anthropic considering price cuts to better compete against each other as both move toward IPOs.

This pricing upheaval creates new headaches for IT leaders, Geurts says. Spending becomes harder to predict, and the outputs harder to control.

“Per-seat pricing capped the bill at headcount,” he adds. “Usage pricing scales with consumption, and as AI moves from assistants to autonomous coding, code volume outgrows what any architecture team can review. The code itself is a liability you keep paying for.”

At the same time that token usage pricing has increased, subscription pricing for AI tools has risen as well, according to a study from Lorka AI, provider of an AI-based writing and research tool.

AI tools that were free or low cost in 2023 now average between $20 and $30 per employee per month, with some premium AI tiers now reaching $200 per month, Lorka AI says. Some enterprises using several AI tools are now spending more than $1,200 per year per employee, often with overlapping functionality between products, according to the company.

Vigilance needed

All of this pricing uncertainty means that IT leaders need to be extra vigilant about software costs, experts say.

CIOs will need to pay close attention to both how services are procured and how much they are used, says Maksim Hodar, CIO at software development firm Innowise. CIOs should pay attention to usage analytics so that they can identify cost control measures and determine which pricing model best suits their business cases, he recommends.

CIOs should also conduct pilot programs before scaling the use of new software with new pricing models, he suggests.

“CIO success depends upon your ability to choose a service’s pricing model based on your business process, risk profile, and expected value associated with the service,” he says. “It’s easy to become overwhelmed by trends in the industry and simply go with what everybody else is doing.”

Hodar expects several different pricing models to hang on, with the predictability of per-seat pricing and the flexibility and scalability of usage-based pricing keeping both models around. Outcome-based pricing will also emerge as an alternative as long as vendors and customers can measure the outputs, he predicts.

IT leaders who haven’t yet embraced FinOps practices should now do so, adds Twilio’s Ramsinghaney. CIOs should track token and other usage to verify that features deliver more value than they cost, he recommends.

Those enterprises moving to outcome-based pricing models should enter explicit outcome measurement agreements with software and platform providers, he adds. “Attribution disputes are where these contracts fall apart,” he says. “Outcome-based pricing only scales where both parties can agree on attribution, and in complex enterprise environments where multiple factors drive results, that clean attribution often doesn’t exist.”

Like others, Ramsinghaney sees room for multiple pricing models going forward. Usage-based pricing works for infrastructure and API-first products where buyers build their own applications, while outcome-based pricing wins where results are cleanly measurable, such as resolved support tickets or completed workflows.

“Hybrid wins as the dominant model rather than either pure form, because it balances vendor revenue predictability with buyer cost alignment,” he adds.

Some per-seat pricing will survive as well, he says, but its use will shrink to situations where humans remain the primary users and value is closely tied to headcount.

“Per-seat persists for collaboration tools and applications where software augments human work, rather than replacing it,” Ramsinghaney says. “The misalignment only becomes acute when AI agents start acting as users that don’t occupy seats.”

Many companies are still buying software for workflows that define how they compete. That used to be a rational way to control costs and reduce risk. Increasingly, though, it’s becoming a quiet way to standardize away differentiation.

For most of the last 20 years, the CIO’s answer to build versus buy was clear: unless you’re a software company, don’t build. Buy a SaaS product, integrate it into the stack, and reserve scarce engineering capacity for the few places where custom work is unavoidable. That advice was rational. It protected companies from fragile custom systems, undocumented dependencies, runaway maintenance costs, and the shadow applications that later became operational liabilities.

But defaults age. When they do, leaders often continue defending them long after the conditions that made them useful have changed. The buy-default is reaching that point. The case for buy hasn’t disappeared, but its status as the automatic default has, and the CIO who continues to default to buy without revisiting why is no longer protecting the business from risk but protecting an assumption that’s quietly stopped being load-bearing.

What changed

Three shifts have moved the math, and the technology side of each one gets the headlines. The business consequence is the part the CIO must act on.

The first shift is cost. AI-assisted development has compressed the time from idea to working software from quarters to weeks, and in some cases prototypes that once required a formal six-figure engagement can now be produced by a small team in a sprint, or by a capable operator over a weekend. Productivity surveys of AI-assisted developers put the gain in the 70 to 90 percent range on routine engineering tasks, and several large technology firms now report that AI-generated code accounts for up to 40% of new commits. The business consequence is that workflows previously too expensive to customize are now economically viable. The custom build is no longer reserved for the few capabilities the business can’t live without. It’s available, in principle, for any capability where the off-the-shelf product forces a meaningful compromise.

The second is who can build. The democratization of software development is no longer a category of marketing slide. Gartner has been writing for years about fusion teams and the rise of business-side technologists, and the AI generation of coding tools has accelerated that trajectory beyond what most enterprise architecture functions are tracking.

Recent usage data on AI-assisted coding platforms suggest that roughly 65% of users don’t come from a developer background. They sit in operations, marketing, and finance, and they increasingly produce working internal applications, not just demos or toys. The business consequence is that build decisions will happen whether CIOs govern them or not. The CIO who assumes building still requires hiring a software team is operating on a labor market description that no longer matches reality, and is also operating on the assumption that the build-or-no-build decision still sits inside IT. It doesn’t.

The third shift is what gets exposed. The traditional reasons custom builds failed haven’t vanished. Authentication, scalability, recoverability, security, and maintainability are still real engineering disciplines, and they still consume real effort. What’s changed is they’re increasingly available as managed services, embedded primitives, or platform features.

Authentication can be subcontracted to a specialist provider. Compliance-aware data storage can be procured on a credit card. Documentation can be generated alongside the code it documents. The business consequence is that the risk has shifted from can we build it to can we govern what we build. That’s a different question, and most organizations aren’t yet structured to answer it.

The combination of those three shifts has done something the industry hasn’t fully digested yet: not eliminating the case for buy but eliminating the case for buy as automatic default.

Where the case for build now holds

This isn’t an argument that organizations should now build everything. The places where buy was the right answer for so many years remain the places where it’s still the right answer today.

For commodity workflows, accounting, payroll, calendaring, document storage, identity management, and the common operations of any business, the SaaS market wins decisively. The advantage of building these is small, the cost of maintaining them is real, and the supply of mature products is strong. CIOs are still correct to push back when a business unit proposes building its own ERP. That hasn’t changed, and it won’t.

What has changed is the second category — the workflows that aren’t commodity, the processes that distinguish the business from its competitors, and the operating model details that get bent around the limitations of off-the-shelf systems because no vendor has built a product that matches the actual shape of the work.

In that category, buying has always been a compromise. CIOs accepted the compromise because the alternative was building, and building was unaffordable. With the cost of building no longer prohibitive, that compromise becomes a deliberate choice rather than an unavoidable one. In the workflows where the business is supposed to be different from its competitors, accepting a vendor’s idea of how the work should be done isn’t a neutral position but a slow erosion of the differentiation the business is presumably trying to defend.

The CIO’s job is also to tell the difference between these requests, where buy still wins and the buy-default ones are now obstacles to the business’s competitive position.

This can’t become another category of decisions quietly delegated to IT. If a workflow defines how the business competes, the accountable owner must be the business leader who owns that capability. The CIO should own the architecture, guardrails, risk model, and integration logic, and the business should own the value, adoption, and operating consequences. When that split isn’t explicit, accountability disappears, and the build-versus-buy decision becomes another technology argument with business consequences no one owns.

The risks have moved, not disappeared.

It’d be irresponsible to write this without naming what hasn’t changed. Custom builds still fail when the people building them ignore non-functional requirements. Independent security reviews of AI-generated code report basic failure rates approaching half of the samples examined, with leaked secrets, hardcoded credentials, and misconfigured access controls turning up routinely when the builder isn’t a security practitioner.

Citizen developers still produce systems that look like they work and turn out to be ungoverned, undocumented, and unmaintainable. The single-point-of-failure problem, where the entire build lives in the head of one person who eventually leaves, isn’t theoretical. Most CIOs have either inherited a build like that or watched a peer do so. The reflexes that produced the buy-default aren’t arbitrary, they’re scar tissue.

The shift isn’t that those risks have disappeared. It’s where they sit within the decision’s architecture. They used to live in the column labelled “reasons not to start.” They now live in the “things to design for if you do” column. That’s a different conversation that requires a different role from the CIO than the one most of us were trained for.

In the previous era, the CIO’s value-add was largely defensive. Stop the bad build before it starts. Push the business toward the vendor that the company can hold accountable. Maintain the standardization that makes the environment sustainable. That work still matters, but it’s no longer sufficient.

The new value is architecture, not gatekeeping. It’s the ability to look at a workflow and tell the business whether buying it commoditizes a real differentiator, whether building it is operationally sustainable, what the maturity prerequisites are, and where the build needs to sit relative to the rest of the stack. It’s also the ability to govern citizen development without trying to suppress it, because suppression is no longer a viable strategy. Business users will build with or without IT’s blessing and the CIO who makes that an adversarial relationship loses both the build and the governance.

What this asks of the CIO function

If the build-versus-buy question is no longer settled, the CIO role can’t remain settled either. So, a few things follow.

Architecture must come back to the center of the role. Not enterprise architecture as the bureaucratic ritual it became in many organizations, but as the discipline of deciding which capabilities the business builds, buys, and how the two compose into something coherent. That work can’t be delegated to vendors or business units, both of whom have legitimate but partial views of the question.

Governance of citizen development becomes a real responsibility, not a residual one. The CIO who pretends business users aren’t building loses visibility into a category of growing risk. The CIO who entirely shuts down citizen development loses the ability to capture the value it can produce. The middle path of frameworks, sandboxes, security primitives, and lightweight standards, is harder to design and run than either extreme, and it’s now part of the job.

Talent strategy has to update. The CIO function has been hiring against a labor market that assumed a sharp line between business users and software developers. That line has become a gradient. Hiring needs to follow.

Most importantly, the CIO needs to be willing to retire advice that’s become reflex. The buy-default served the field well for a long time. The unwillingness to revisit it serves the field poorly now.

So the build-versus-buy question isn’t really about software but about which capabilities the business must control, which it can safely consume, and who owns the consequences when that choice proves wrong. The old default protected organizations from one kind of risk. Leaving it unexamined now creates another.

The economics have shifted and the default shouldn’t survive unexamined. The better question is no longer whether responsible CIOs should build or buy but whether they know which business capabilities are too important to leave to a vendor’s operating model.

The need for a central data repository for enterprise analytics and gen AI has made the data lakehouse the default choice for enterprise data. Meanwhile, the emergence of open table standards makes the shift easier and reduces vendor lock-in for enterprises while also allowing for better integration between lakehouses and other enterprise systems and service providers.

Data lakehouses combine the structure of data warehouses with the flexibility of data lakes, making them versatile tools to make the most of any data the enterprise collects, whether it’s for business analytics, integration with other systems, or providing relevant context to LLMs.

The idea behind the data lakehouse is to merge together the best of what data lakes and data warehouses have to offer, says Gartner analyst Adam Ronthal.

Data warehouses also enable companies to store large amounts of structured data with well-defined schemas, as they’re designed to support a large number of simultaneous queries and deliver results quickly to many simultaneous users.

Data lakes, on the other hand, enable companies to collect raw, unstructured data in many formats for data analysts to hunt through. These vast pools of data have recently grown in prominence thanks to the flexibility they provide enterprises to store massive data streams without first having to define the purpose of doing so. 

According to Gartner, data lakehouses are the next step in the evolution of data architectures, merging these two capabilities into a single platform to overcome limitations of previous architectures, reducing complexity, streamlining data management, and supporting diverse workloads.

In late 2025, Gartner also released the first market guide for data lakehouse platforms. “The lakehouse is now firmly established as the architecture that most organizations will seek to standardize on,” wrote Ronthal and his co-authors in the report.

Meanwhile, data lakehouses themselves are also standardizing on the Apache Iceberg data table format, first created by Netflix in 2017, and donated to the Apache Software Foundation the following year. It hit the tipping point in 2024 with adoption by companies like Apple, LinkedIn, Adobe, and all the major cloud vendors. Even Databricks, which created the competing Delta Lake standard, now supports Iceberg natively.

Lakehouse vendors are opening their architecture more to allow better access to the data by third parties, says Gerry Szatvanyi, chief AI officer at consulting firm OSF Digital. “That wasn’t the case a few years ago,” he says.

And other enterprise service providers have been taking advantage of this, he says. For example, Salesforce Data Cloud can connect directly to Iceberg-formatted data.

“Salesforce has a Zero Copy access format, so it can connect its own data platform to another data lake without copying data into Salesforce,” says Szatvanyi.

And of course, as with everything else in the enterprise today, gen AI is having a big effect. Data lakehouses are particularly good for LLMs because they can provide critical business context for RAG embeddings and MCP access, the two most common ways to feed data into LLMs.

“Lakehouses are being accessed more by AI agents,” Szatvanyi says. “It’s the main thing I see happening.”

Even traditional business analytics is now increasingly handled via AI interfaces, he adds, democratizing user access to enterprise data.

In a recent IDC report, the leading vendors in the data platform space are Databricks, Google, Oracle, and Snowflake, with other major players including Microsoft, IBM, and Cloudera. IDC also listed Amazon SageMaker as a lakehouse platform to watch, but it only became widely available in early 2025, so wasn’t yet included among the top vendors.

Gartner includes Databricks, Google, Oracle, Snowflake, Microsoft, IBM, Cloudera and Amazon SageMaker on its list of representative vendors for data lakehouse platforms, among other firms.

The business benefits of data lakehouses

Docusign opted to go with Snowflake for the data platform used to train an internal agent for sales, and is training its ML models in order to serve customers more accurately. Information is pulled from Salesforce, and they’re also exploring Atlassian and ServiceNow, as well as other internal custom tools.

The information also goes out to LLMs using RAG embedding pipelines, and MCP connectivity is also being explored as the technology matures.

Other companies use data lakehouses for the flexibility of the data sources it supports and the volume of data they can handle.

Sega Europe, for example, began using the Amazon Redshift data warehouse to collect event data from its Football Manager video game back in 2016. At first this event, data consisted simply of players opening and closing games.

“But there was so much more data we could collect,” says Felix Baker, the company’s head of data services. “Like what teams people were managing, or how much money they were spending.”

Because of the data structures needed for inclusion in the data warehouse, data was coming in batches and it took too much time to analyze.

“We wanted to analyze the data in real-time,” Baker adds, but this functionality wasn’t available in Redshift at the time. “Databricks offered an out-of-the-box managed services solution that did what we needed without us having to develop anything,” he adds. In addition, the data lakehouse architecture enabled Sega Europe to ingest unstructured data, such as social media feeds.

The cost efficiencies enabled by providing a source for all of an organization’s structured and unstructured data is a value driver for data lakehouses, says Steven Karan, AI transformation lead at Capgemini, and it’s helped implement data lakehouses at leading organizations in financial services, telecom, and retail.

Moreover, data lakehouses store data in a way that it’s readily available for use by a wide array of technologies, from traditional business intelligence and reporting systems to ML and AI. “Other benefits include reduced data redundancy, simplified IT operations, a simplified data schema to manage, and easier to enable data governance,” Karan says.

Helping data emerge

One particularly valuable use case for data lakehouses is in helping companies get value from data previously trapped in legacy or siloed systems. For example, one Capgemini enterprise customer, which had grown through acquisitions over a decade, couldn’t access data related to resellers of their products.

“By migrating the siloed data from legacy data warehouses into a centralized data lakehouse, the client could understand at an enterprise level which of their reseller partners were most effective, and how changes such as referral programs and structures drove revenue,” he says.

One company capitalizing on the benefits of data lakehouses is life sciences, analytics, and services company IQVIA, which began using data lakehouses several years ago.

Before the pandemic, pharmaceutical companies running drug trials used to send employees to hospitals and other sites to collect data about things such as adverse effects, says Wendy Morahan, senior director of product management for clinical data analytics at IQVIA. “That’s how they make sure the patient is safe.”

Once the pandemic hit and sites were locked down, however, pharmaceutical companies had to scramble to figure out how to get the data they needed — and to get it in a way that was compliant with regulations, and fast enough to enable them to quickly spot potential problems.

Snowflake and Databricks gave the company the ability to store the raw data in any format, including images and audio, all in a single platform.

Lakehouse adoption growth

In a February report from Research and Markets, the data lakehouse market has been growing exponentially.

In 2025, it totaled $10.3 billion and is predicted to hit $12.6 billion by the end of this year, a compound growth rate of 22%. By 2030, this will be up to $27.3 billion, the research firm projects.

And according to a recent survey from Dremio, a lakehouse vendor, 63% of companies run most analytics on a lakehouse rather than a traditional warehouse, up from 55% in 2024.

Data lakehouses are also increasingly being used for IT and security workloads, says Ed Bailey, field CISO at telemetry vendor Cribl. “Previously, lakehouse providers were the realm of business data with a focus on structured data and SQL.”

Lakehouses can handle IT and security data at a lower cost, and this is a critical issue given the volumes of data in this space. “Even mid-sized companies produce much more IT and security data than business data,” he says. “Lakehouse vendors are finally starting to push into the market.”

But it’s still early, and initial solutions are immature and an awkward fit for this kind of data. “IT and security data are very different from business data,” he adds. For example, business data tends to be more predictable and well-structured. Plus, business users are more familiar with using data analytics tools than IT and security users. “This mismatch has been a serious obstacle to adoption,” he says.

Data lakehouses are also evolving in another way. Gartner says the lakehouse isn’t the ultimate solution but a transitional architecture on the way to more advanced systems, such as data fabric. The difference between the two is data lakehouses contain data from disparate systems, while data fabrics simply contain pointers to where the data is natively located.

An advantage of data fabrics is that the original security access controls and metadata are preserved and used, there’s no duplication of data, and no need to reconcile disparate standards.

“But it comes with some performance issues, and access isn’t that seamless,” says OSF Digital’s Szatvanyi.

A data fabric might be a good place for smaller companies to start, he says, or you can use both. “You can have a big chunk of data in a lakehouse and have a fabric for two or three secondary systems,” he says. “But I’d say the data lakehouse is the gold standard.”

Anyone can build an app now. But nobody seems to care.

Well, not nobody. VCs keep funding startups that add AI to, well, everything. But users aren’t buying the massive influx of new apps. In a chart shared by Jen Zhu Scott based on the new National Bureau of Economic Research’s working paper “Writing Code vs. Shipping Code,” iOS app releases have exploded since the advent of agentic AI. That would perhaps be cause for celebration had app reviews not declined during this same period, and apps with significant usage have stayed essentially flat.

In other words, more apps but almost nobody new showing up to use them.

For those of us that grew up in open source, it’s a familiar problem. The greater the abundance of code, the greater the need to help would-be customers navigate it through marketing (including branding), sales, etc. AI is creating so much noise, in terms of new code, new products, etc., that the real work has shifted to taste-making.

Getting more but not using more

I’ve been saying for a while that developer productivity isn’t about producing more code faster. Or at least it shouldn’t be. Productivity is about producing well-architected, secure, maintainable code that solves a problem someone actually has.

That’s a very different thing. It’s not something AI can fix; at least, not yet.

Charity Majors put it more bluntly in a post I wrote in 2024: “Writing code is the easiest part of software engineering,” she said. The harder parts are figuring out what to build, integrating it into a larger system, validating that it works, maintaining it over time, and getting humans to trust it enough to use it.

Turns out the harder parts are really hard. Mert Demirer, Leon Musolff, and Liyuan Yang tracked more than 100,000 GitHub developers alongside their AI usage telemetry. Autocomplete, interactive agents, and autonomous agents each ramped raw coding activity, with cumulative effects on commits of 40%, 140%, and 180%. That sounds great until you look how the gains attenuate the closer you get to actual users. For example, that 180% jump in commits became roughly 50% more projects and just 30% more actual releases. The report’s authors call this the weak-link problem: The strong link (writing code) got much stronger, while the weak links (everything else humans have to do) didn’t. The estimated elasticity of substitution between AI and human effort is 0.25, which is economist for “these complement each other, but they don’t replace each other.”

When the authors checked four major app marketplaces, they found a bump in new apps but no increase in total usage. In other words, we’re getting better at creating things with AI’s help; apparently we’re not good at turning that into user interest. User attention (and budget) is finite. The hard part is to figure out how to get users to care enough to pay (with their time or their money).

Learning to love marketing

So what’s actually scarce in a world of near-infinite software? Not code, for sure. No, what’s scarce is attention, trust, and a reason to switch.

That means the durable advantages in software increasingly live in the parts of the business developers often undervalue, like a recognizable brand (something that Red Hat figured out early on in open source) or a channel they already use. Or it could be in areas that developers appreciate but don’t pay for, like good documentation or a welcoming community.

This isn’t a new idea; it’s just newly unavoidable. We’re watching something similar inside enterprises, where AI adoption is wildly uneven, not because the technology has no value, but because the organizational plumbing around it often hasn’t been built. This is why a new kind of speed is important. I once argued that speed was the killer app, and that was mostly true. Today the more interesting speed is how quickly you can earn trust, fit into a workflow, answer objections, and get adopted.

Years ago I wrote that RethinkDB was dead and MongoDB wasn’t what killed it. RethinkDB was at the time, by many technical measures, a better database, built around “correctness, simplicity, and consistency.” It still lost—and badly. Its founder’s own postmortem was unsparing: They had picked a brutal market and tuned the product to the wrong definition of good. Being technically right turned out to have almost nothing to do with getting adopted.

With AI we’re generating a thousand smaller “RethinkDBs,” only faster and with nicer landing pages generated by the same model that wrote the code. These aren’t going to win, any more than RethinkDB was able to unseat MongoDB. It’s not just about the tech, but rather about making that tech fit within a user’s or enterprise’s world and making it easy to adopt. AI makes this harder, not easier.

It’s a cliché that developers don’t like marketing. It’s also false in my inexperience. What developers don’t like is traditional marketing. During my time at MongoDB and now at Oracle, my developer relations teams have focused on offering developers deep, hands-on enablement, and the response has been fantastic. Is a technical tutorial marketing? Of course it is. So is a forward-deployed engineer working side by side with an enterprise’s engineers to help them effectively use your tech. Just because it’s not a 30-second Super Bowl ad doesn’t mean it’s not marketing.

Years ago the Dilbert cartoon captured developers’ disdain for marketing. It was funny then, and it’s funny now, but it has never been true.

Years ago Matt Klein, creator of the open source Envoy project, once talked me through all the non-development work that goes into making an open source project thrive. As he reflected, “If you look at what I did in 2016 and early 2017 to [introduce] and grow the project, it was not technical.” So what was it, if not core engineering? “It was all leadership, public relations, marketing, documentation, etc., and I did it all myself and I nearly killed myself [doing it].” As he summed it up for me, it was a “f—ing lot of work,” and much (most?) of it wasn’t about code. It was about helping users appreciate the value of that code.

TL;DR? The boring but essential go-to-market grind has always been the real job. It’s what will separate winners from losers in AI.

The boring work wins

None of this is an argument against AI coding tools. Developers should absolutely use them. I use them constantly.

But AI can’t compensate for the hard work that goes into making a product successful in the market. In a world drowning in AI-generated sameness, taste becomes a competitive advantage. For me, “taste” translates into knowing what not to build, or what not to publish. It’s also all about knowing how to market one’s product, which might include ads but definitely needs to incorporate technical training that helps developers make sense of your code.

In short, there’s no Field of Dreams “build it and they will come.” There’s just a lot of hard, human work to help real people find and use your code.

Transformation of an organization is no longer measured solely in terms of productivity, automation, or the adoption of new tools. In nonprofits like Amnesty International Spain, technology has also become a matter of independence, privacy, and the ability to act autonomously.

For over 14 years, the Spanish branch of the organization has operated with a clear premise to minimize its dependence on large technology platforms, and maintain control over its data, systems, and communications. This strategy, amid the ongoing European debate on digital sovereignty and AI, is taking on a new dimension. “From the ground up, we have a policy of being technologically independent, hosting as much as possible ourselves to ensure we have no problems suing any company, or that any report we publish doesn’t affect the systems we work with,” says head of IT infrastructure Carlos López Belenguer.

Having worked like this long before concepts such as digital sovereignty became a regular part of the European tech debate, people are now discussing it more. “I think it’s a powerful and quite appropriate term,” he says.

Technology to avoid dependence on big tech

Amnesty International Spain’s tech strategy has focused on finding free software alternatives and self-hosted systems that allow them to maintain control over their infrastructure. “One of the great advantages of free software is we aren’t dependent on any company to work,” says Belenguer, adding it’s especially important in an organization dedicated to defending human rights, so it can denounce or investigate any company knowing it won’t face retaliation regarding the use of software.

In his view, the current geopolitical context and some recent moves by large technology companies further reinforce this philosophy. “It’s no coincidence Microsoft is withdrawing a significant portion of its licensing model for NGOs right after Donald Trump said none of its suppliers could have certain policies that went against his administration’s philosophy,” he says.

Belenguer adds that these types of changes can create significant economic and technological problems for organizations that depend entirely on external platforms. “When you already have your entire infrastructure in place, you don’t have many options to switch to the competition, because you’re really intertwined,” he says.

Providing the means

A prime example of this strategy has been implementing Nextcloud as an internal collaborative work platform. But Belenguer’s relationship with this tool began years before its deployment within the organization. “I was already familiar with the software and had been following it for years,” he says.

At that time, Amnesty International Spain was still working with local file servers, and solutions like Microsoft 365 and Microsoft SharePoint were just beginning to spread. “Like many others, we worked with a file system on a local server in the office,” he says. “Everyone went to work in person, and the whole Office 365 movement was just starting to emerge.”

However, the organization decided to explore another option. “I proposed Nextcloud because I was already familiar with it, had considerable experience with open-source software, and we already had quite a few things hosted,” he says. “In the end, it was just a matter of launching one more product.”

The implementation began with a small pilot test with five users, which later grew to 10, and then 30. But the major turning point came with the pandemic in 2020 and the rise of remote work. “By then, we already had it up and running in production with everyone using it,” Belenguer says. “It practically saved our lives in IT.”

The tool evolved from a simple file-sharing system into a collaborative work platform. “When people saw they could edit documents concurrently and work together seamlessly, they began to find many more uses for it,” he says.

Privacy, flexibility, and control

Beyond functionality, Belenguer says the main differentiating value of these types of solutions is control over infrastructure and data. “The only real way today to guarantee privacy when working with big tech is to leave big tech,” he says.

In this way, he expresses a particularly critical view of how large tech platforms handle personal data. “Microsoft seeks to create a general profile of everyone who works with or uses a computer,” he says, adding that the increasing integration of digital services, accounts, and tools is generating a massive collection of information about users. “All this is done under the guise of improving security or ensuring a better user experience.”

Free software, on the other hand, offers a more flexible and secure alternative. “Being your own Google without compromising user privacy and documents, and being technologically independent is a huge leap,” he says.

In addition to privacy, the adaptability offered by working with one’s own infrastructure is also key. “We’ve had much more flexibility both in managing the platform and in recovering lost data, as well as enabling different ways of working,” he says.

Despite its commitment to technological independence, Amnesty International Spain acknowledges that some dependencies remain difficult to overcome, so certain tools from major tech companies have become de facto standards. “A big commitment I feel we have to make is to use Teams,” says Belenguer. “Many people don’t realize an alternative exists.” Still, he adds the organization has achieved a high degree of technological autonomy. “I’d say we’re at about 70% independent,” he says. “If the US cuts the cord, we believe we could continue working practically without problems.”

AI: opportunity and concern

Regarding AI, Amnesty International Spain has developed internal policies to limit use of external tools with sensitive data. “We’ve developed policies to ensure personal data is neither shared nor fed into any AI controlled by a large company,” he says.

At the same time, the nonprofit is working on projects to deploy its own self-hosted models that can offer users tools with which to process personal data without compromising sensitive information. Among the projects under development are those related to videoconferencing, transcription, and voice and text analysis and synthesis. “We’re aiming for a hybrid model in which certain tasks can be performed with external tools, and others require our own infrastructure,” he says.

Belenguer understands AI will continue to profoundly transform the work of organizations. “There’s practically no aspect of our work that won’t be affected,” he adds. Despite this, he believes this very transformation makes maintaining technological control even more important. “It’s a very good time to try to become technologically independent and control most of our systems,” he says.

A cultural shift that has already begun

Belenguer acknowledges those who opted to maintain their own infrastructure and reduce dependence on large technology platforms were seen as oddities. “For a long time, we felt quite alone doing this,” he says. But he believes the current context is driving a change in mindset. “In the last two years, though, we’ve seen a major ideological shift. There’s constant and enthusiastic talk about digital sovereignty, hosting your own systems, and owning your data.”

This shift confirms the path the organization embarked on years ago made sense. “Now we realize we were largely right and we’ve done the necessary thing,” he says.

I’ve lost count of how many clients have called frustrated, not because their managed services provider (MSP) was missing SLAs, but because meeting every SLA still wasn’t helping employees do their jobs. Tickets close on time, uptime stays above target, and scorecards are green across the board yet employees remain frustrated by broken processes, recurring issues, and support that feels transactional instead of useful.

The help desk resolves tickets quickly without solving underlying problems, so employees create their own workarounds. This is the watermelon effect: green on the outside, red on the inside. It remains one of the most persistent problems in outsourced IT today.

Patterns across major MSP relationships

I see this pattern across relationships with every major provider. These are sophisticated organizations with mature delivery capabilities that can absolutely hit the metrics you put in front of them. That’s precisely the problem.

Vendors optimize for whatever the contract measures. If your contract only measures operational outputs, that’s what your provider will focus on. They’re not doing anything wrong. They’re doing exactly what the contract incentivizes.

What I’ve seen time and again is that the contracts organizations signed five or seven years ago were designed for a different model of IT support, one that enforces compliance and control costs. They weren’t designed to drive outcomes or improve the employee experience, and in many cases, those contracts are still running.

Realigning a major MSP relationship isn’t simply a matter of telling the provider to do better. It requires changing what the contract measures. That’s where experience level agreements come in.

Why SLAs weren’t designed to measure what matters most

SLAs were built for an earlier era of IT. The logic was straightforward: define the service, establish operational standards, measure compliance, and apply financial consequences when performance falls short. It’s precise, auditable, and legally defensible.

But SLAs measure the process, not the outcome. A service desk can resolve 95% of tickets within the agreed timeframe and still leave employees feeling completely unsupported. An application can technically meet uptime standards while being so slow and unreliable that employees avoid using it. That gap, between what the contract measures and what employees actually experience, is where productivity leaks, morale erodes, and the business case for outsourcing quietly unravels.

I’ve sat in enough quarterly business reviews with providers to know how this dynamic plays out. The provider presents a polished scorecard. Every metric is green or amber. The client’s internal stakeholders raise concerns about employee complaints, escalating shadow IT, and department heads who have stopped submitting tickets because they’ve given up. The provider points to the scorecard and there’s no mechanism in the contract to address the gap.

That’s a contract design problem, not a provider capability problem. And it’s one that experience-based measurements like XLAs are specifically designed to solve.

The shift organizations need to make, and why it’s hard

When I work with clients on realigning MSP relationships, the conversation often starts with frustration, and the solution isn’t straightforward either. Organizations face real structural barriers to making this shift, like with baseline data, for instance. You can’t set meaningful experience targets without knowing where you’re starting from. Many of my clients have been operating on SLA-only contracts for years, sometimes with the same provider, and they have no employee experience data at all. They know ticket volumes and resolution times, but they have no idea how employees actually feel about the service.

Contract language is another issue. Major MSPs have mature commercial teams that are very skilled at navigating ambiguous commitments. Improving the employee experience isn’t a contractual commitment. A defined happiness score is, one that’s measured by a specific tool, and reported monthly with agreed escalation protocols when thresholds are missed.

Another is incentive alignment. The most common mistake I see organizations make is converting an XLA into a penalty mechanism. If the only consequence for missing an experience target is a financial deduction, providers will manage the number rather than the experience. The most effective XLA structures I’ve worked on combine penalties for persistent underperformance with shared gain mechanisms that reward genuine improvement.

Four ways to structure XLAs in an outsourcing contract

Based on what I’ve seen work across client relationships, there are four practical models for building XLAs into a contract. The right starting point depends on where the organization and the provider relationship currently are.

1. Commit to a defined experience score. The vendor commits contractually to achieving a defined satisfaction threshold. This is the most rigorous model and requires established baseline data on both sides. It works best when the relationship has been running for at least six to 12 months and both parties have experience measurement in place.

2. Commit to a digital experience score. Here, the XLA is tied to a broader digital employee experience (DEX) score that combines employee sentiment with technical telemetry. Providers like HCL and Cognizant increasingly support this model through partnerships with platforms like Nexthink.

3. Commit to continuous improvement. Rather than setting fixed thresholds immediately, both parties agree to a shared obligation to improve experience metrics over time, with targets reviewed and reset every six months. This is usually the best entry point for organizations that are new to experience measurement. It builds a data baseline, establishes a culture of shared accountability, and avoids the trap of locking in arbitrary targets before either party understands the benchmarks.

4. Commit to delivering the XLA capability. In this model, the provider takes responsibility for building and operating the measurement infrastructure itself. This works well when the client lacks internal XLA capability but still wants accountability built into the relationship from the outset. I’ve seen this work particularly well in new contract structures with Accenture and Capgemini, both of which have invested in building proprietary experience measurement frameworks.

What XLAs actually measure

Unlike SLAs, which focus on technical outputs, XLAs focus on human outcomes. The metrics I most commonly see built into client contracts include:

• Employee satisfaction scores
• Perceived lost productivity time
• Repeat incident rates for the same underlying issue
• Ease of getting support across different channels
• Task completion success rates
• Confidence in IT services overall

The goal isn’t to eliminate SLAs as systems still need uptime targets and response standards, and providers operate at a scale where those operational commitments genuinely matter. So the goal is to add the missing layer of whether or not employees feel supported and productive, not just if tickets are being processed.

The data infrastructure behind a working XLA program

Strong XLA programs depend on three categories of data working together. Getting this right is often where the real negotiation with providers happens, because data ownership and transparency are genuinely contested terrain in major MSP relationships.

Experience data (X-data): This is the human layer, how employees feel about their IT experience. It comes from pulse surveys, post-interaction feedback, and always-on feedback channels. Platforms like HappySignals, Nexthink, and Qualtrics are commonly used. One of the most important negotiating points I work through with clients is ensuring that this data is owned by the client, not the provider. Some MSPs propose operating the measurement platform themselves, which creates a structural conflict of interest.

Operational data (O-data): This is the traditional metrics layer already stored in ITSM platforms most common among our clients like ServiceNow or Jira Service Management. Most providers already produce this data and the value comes from correlating it with experience data, not treating it in isolation.

Technical data (T-data): This is the infrastructure layer comprised of device health, application performance, network latency, and endpoint health. Platforms like Nexthink and 1E collect this telemetry passively. When experience scores drop, correlating against technical data tells you whether the problem is the technology environment, the support process, or the service interaction itself. Without that triangulation, you know something is wrong but can’t pinpoint why.

The transparency problem

In my experience, the biggest failure point in XLA programs isn’t the metrics but transparency. When clients hide poor experience scores or providers obscure unfavorable data, the foundation of the XLA model breaks down.

I’ve seen MSPs manage the measurement platform and report improving scores, only for independent measurement to reveal a very different reality. The strongest XLA programs treat experience data as jointly owned, openly shared, and central to collaborative problem-solving.

Contracts create accountability, but governance drives improvement. Weekly working sessions, monthly reviews, and leadership steering meetings matter far more than scorecards alone. Building that level of transparency is often the hardest part.

The shift from service delivery to outcome delivery

The shift from SLA-only contracts to XLA-enabled outsourcing reflects more than a new measurement framework. It signals a fundamental change in how organizations define IT value. Cost and efficiency still matter, but leading organizations are now asking whether technology investments improve employee productivity, reduce frustration, and create better support experiences. That requires a different level of provider accountability.

MSPs can deliver experience-based outcomes, but they rarely prioritize them unless contracts demand it. XLAs formalize those expectations, and increasingly, organizations see them as the standard for measuring meaningful IT performance.

Enterprise cloud teams are trained to act on utilization data.

If a virtual machine is idle, resize it.
If storage is overallocated, reclaim it.
If a GPU appears underused, move the job to a smaller instance.

That logic is central to modern FinOps. It helps organizations reduce waste, improve forecasting and keep cloud spending under control.

But secure AI training introduces a different problem: sometimes the utilization signal is technically true and operationally misleading.

A GPU can look underused even when the workload is not over-provisioned. In privacy-preserving machine learning, low accelerator utilization may indicate a memory-bound bottleneck, not excess capacity. If a cloud optimization process treats that signal as ordinary waste, the recommended fix can make the job slower and more expensive.

For CIOs, this is not just a GPU tuning issue. It is a cloud governance issue. As I have noted previously, IT leaders must look beyond the cloud bill to understand the hidden operational costs of AI governance

The utilization number does not explain the bottleneck

Traditional cloud right-sizing depends on a simple assumption: low utilization usually means unused capacity.

That assumption works for many enterprise workloads. It can work for web services, batch jobs, databases and standard compute jobs. But secure AI training can break that assumption because the workload shape changes.

In my IEEE systems research on privacy and robustness in machine learning, I profiled what happens when trust controls are added to model training. The important lesson for CIOs was not only that secure training costs more, but it was that secure training can change what infrastructure metrics mean.

On a controlled NVIDIA V100 GPU setup, privacy-preserving training increased cost by 3.55x on a vision workload and 2.96x on a tabular workload. Robustness training increased cost by 4.07x on the vision workload.

Those cost multipliers matter. But for FinOps teams, the deeper finding is this:

The workload became less aligned with the hardware signals that cloud teams often use for rightsizing.

Why privacy-preserving training can look inefficient

Modern AI accelerators are very good at large, dense mathematical operations. Standard model training often keeps these accelerator units busy because the work can be organized into large blocks of computation.

Differential privacy training often requires per-example gradient computation and clipping. Instead of pushing most of the work through large, efficient operations, the system performs more fine-grained steps across individual training examples.

That changes the performance profile. In my study, this pattern created memory-bound behavior and reduced effective use of specialized GPU compute units such as Tensor Cores. To a dashboard, that can look like underutilization.

To a systems engineer, it means something more specific: the job is not waiting because the GPU is too large. It is waiting because the workload is constrained by memory movement and per-example operations, simply those are not the same problem.

The FinOps risk: Right answer, wrong context

Automated cloud recommenders are useful because they identify resources that appear oversized or idle. The problem is not that these tools exist. The problem is applying a generic right-sizing rule to a specialized AI workload.

A standard recommendation workflow might ask, “Is the accelerator busy?: For secure AI training, CIOs need the team to ask, “Why is the accelerator not busy?”

If the answer is idle capacity, downsizing may save money.

If the answer is memory-bound privacy computation, downsizing may increase total cost.

A smaller instance may have a lower hourly price, but cloud bills are not based only on hourly price. They are based on hourly price multiplied by runtime. If the smaller instance extends the training job enough, the total bill can rise.

That is the FinOps blind spot: a recommendation can look correct on a utilization dashboard but fail when measured against the full training job.

Secure AI needs a different exception policy

Enterprise IT already treats some workloads differently. Regulated databases, security-sensitive systems and latency-critical applications often have special infrastructure policies.

Secure AI training needs similar exception handling; a model training job that uses differential privacy or adversarial training should not be evaluated the same way as an idle development server. These workloads can produce unusual utilization patterns because the algorithm itself changes the way hardware is used.

1. Tag secure-AI training jobs

FinOps teams need to know when a training job uses privacy-preserving or robustness-oriented methods.

A simple workload tag can prevent the job from being evaluated as ordinary compute. The tag should tell cloud teams:

Low utilization may be caused by the algorithm, not by waste.

This gives FinOps, MLOps and infrastructure teams a shared signal before any right-sizing decision is made.

2. Treat rightsizing as a review trigger, not an automatic action

For secure AI jobs, an automated recommendation should start an investigation. It should not automatically become a change request.

Before moving the workload to a smaller instance, the team should answer four questions:

• Is the workload compute-bound or memory-bound?
• Is the bottleneck caused by data loading, memory bandwidth or per-example privacy operations?
• Would the smaller instance reduce total job cost, or only reduce hourly rate?
• Has the team measured runtime impact before approving the change?

This shifts FinOps from simple utilization management to workload-aware cost governance.

3. Bring MLOps into FinOps decisions

FinOps teams understand pricing, commitment plans, chargeback and utilization. But secure AI workloads require another layer of interpretation.

Someone must understand what the training algorithm is doing.

DP-SGD and PGD do not merely consume more GPU time. They change the computation pattern. That means utilization percentage alone is not enough to make an infrastructure decision.

CIOs should connect FinOps, MLOps, AI governance and infrastructure engineering before applying cost recommendations to secure AI training workloads.

4. Measure total job economics, not only instance utilization

The cheapest instance is not always the lowest-cost option. For secure AI training, CIOs should require teams to compare:

• Hourly cost
• Total runtime
• Energy use
• Job completion time
• Model utility impact
• Infrastructure bottleneck profile

To truly optimize these economics, teams must look beyond the hardware and apply model-level deep cuts to slash AI training costs. Ultimately, a GPU that looks underused may still be the better economic choice if it completes the workload faster and avoids a longer memory-bound run. Failing to account for the model utility impact during these infrastructure changes can easily lead organizations into the AI accuracy trap, where cost savings inadvertently ruin real-world performance.

The CIO takeaway

The next phase of enterprise AI will require more than model accuracy and fast experimentation. Organizations will need AI systems that are private, robust, governable and economically sustainable.

In ordinary cloud operations, low utilization often means waste. In secure AI training, low utilization may mean the workload has exposed a hardware-software mismatch.

The rule for CIOs is simple: Do not right-size secure AI training jobs until you understand why the accelerator is underused.

In trustworthy AI, utilization is not always truth.

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

As VP of data and analytics at Atlanta-based Georgia-Pacific, Matt Robuck gives a multitude of insights to the business. In the past, these would’ve been delivered as dashboards and reports, but over the last three years, with the proliferation of AI, he and his team of over 180 engineers have been questioning how they can strategically implement emerging tech to solve problems differently.

“Georgia-Pacific has been around for nearly 100 years, and many of the problems we’re trying to solve today we’ve been dealing with for decades,” he says. “New technologies allow us to look at these challenges through a different lens.”

Metadata and the AI ecosystem

According to Robuck, developing an AI ecosystem starts with having a very strong bedrock of data. “We’ve made substantial investments over the past three years to build these foundations,” he says. “In the past, data quality, metadata and contextual data weren’t seen as critical because if something was wrong in a report, a human would usually catch it. But with AI agents, there usually isn’t a human in the loop until much later in the process, which means poor-quality data can have big consequences.”

When building the data platform, Georgia-Pacific invested in data lake architecture, proactive data quality, and metadata. “We couldn’t have moved as fast as we have without these things,” he adds. For Robuck, the metadata component — the data context — is critical to the success of their AI agents.

With over 1,000 applications running across the company, each one has its own naming conventions, data types, and data structures. So when an agent is put on top of these data sets, it’ll do its best to interpret the data. “But we need more deterministic outcomes,” he says. “Our agents need to be right more often than not. Metadata, therefore, acts as a translation layer, giving the agents critical context.”

And by making the metadata even richer, with more detailed information about Georgia-Pacific’s different manufacturing sites, like size, products they produce, and business lines they serve, the agents have deeper knowledge of what the data means for the business more broadly.

The company considered building their own metadata solution, but given its size and scale, it partnered with agentic data intelligence platform Alation to ensure the process was quick and cost-effective.

Using data to solve real business problems

One area where these foundations are now being used to add value is across the business’ marketing function. Georgia-Pacific invests heavily in both digital and traditional marketing to promote its consumer products. But when a business wants to understand if its marketing budget is being allocated effectively, it must be able to track campaign performance.

“If you budget $50 million for a campaign, but no one sees it, that’s a nice waste of money,” Robuck says. The marketing team used to spend months at a time consolidating data to determine whether a particular campaign performed well, and then adjust strategies based on this deep dive.

“Understanding marketing performance is ultimately a data challenge,” he says. “That’s why we built a solution that pulls near real-time data from multiple marketing platforms, and turns it into actionable insights, giving marketing teams a far clearer view of how their campaigns perform.”

This strategy cuts costs, eliminates about 30,000 man hours every year, and helps the business connect with a wider customer base. In addition, if the marketing team deploys a campaign that isn’t performing well, having near real-time data allows them to pivot before they’ve wasted time and money on the wrong strategy.

“There’s been fairly substantial optimization of our marketing spend through this process,” he says, adding there are many other opportunities to improve marketing processes, including how he and his team recently deployed a new set of agents on top of these marketing datasets and data products, which can analyze performance data and make recommendations based on how the different campaigns are doing.

“Soon we’ll see agents autonomously making decisions and changing our campaign strategies in real-time,” he says. “Maybe there’s a human in the loop or maybe this runs fully autonomously.”

But the success of this initiative doesn’t mean Georgia-Pacific plans to throw AI at every business problem. “You must start with the business problem in mind, not AI, and think about it holistically,” he says. “To achieve what we have with our marketing team, we went on a three-year journey to get the data right and make sure what we were proposing was the right fit for them.”

There’s no denying the excitement around Model Context Protocol (MCP), an open protocol for connecting AI assistants with external data, tools, and APIs. Since its debut by Anthropic in late 2024, thousands of MCP servers have emerged for devops, cloud, and beyond.

Now that developers have integrated MCP servers into applications, and they have been battle-tested, usage patterns are emerging. For instance, supplying better context for AI is the most commonly cited primary value of using MCP, according to Zuplo’s State of MCP report released in early 2026. The Zuplo report also found that 63% of MCP users adopt MCP servers for accessing data sources such as documentation or knowledge bases.

In software development, context engineering is the act of supplying AI coding agents with relevant data and capabilities to improve the accuracy and relevance of their outputs. It also involves optimizing the breadth of information to guide efficient processing. Such context can include coding style, internal libraries, institutional knowledge, production data, and external data from platforms like Slack, Atlassian, Notion, or GitHub, among others.

“MCPs support context engineering because it creates a standard way for AI systems to connect to various business tools,” says Todd Olson, CEO of Pendo, a product experience platform. “The key benefit is that the agent determines what context it needs based on the question, then uses the appropriate MCP server to fetch that information in real time.”

With the rise in AI-assisted coding, MCP is becoming a doorway for real-time dynamic search and retrieval across various sources, playing an important role in context engineering efforts. As Joey Stout, solutions architect at Spacelift, an infrastructure orchestration platform, puts it, MCP is the “saving grace of vibe coding.”

How MCP boosts context engineering

Using MCP, agents can fetch structured data contextually relevant to the task at hand. According to Edgar Kussberg, group product manager at Sonar, MCP accelerates the knowledge-hunting engineers must routinely perform on a daily basis.

“When an engineer needs to answer a question, they do not rely on memory alone,” says Kussberg. “They navigate code repositories, dashboards, CI systems, documentation, and security reports, pulling information from each system as needed. MCP gives AI agents that same capability.”

Many of the most popular MCP servers retrieve contextual information to improve agentic coding. For example, an MCP server from Context7 provides up-to-date documentation, while another from Filesystem pulls from any directory on a local machine. An MCP server from Sentry accesses production issues and errors, a server from SonarQube exposes security issues, and a server from Multiplayer returns user session data.

The great thing about using MCP for these situations is that it avoids the need to put large code chunks in every prompt. Instead, coding context like relevant methods, dependencies, or recent changes can be called at runtime, says Venugopal Jidigam, head of agentic platform engineering at WaveMaker, an agentic development platform. “The MCP server assembles and returns scoped, structured context, which the model then uses to reason and respond accurately,” he says.

Another common context-gathering example is retrieving institutional knowledge. “Instead of hardcoding that knowledge into the model, the agent uses MCP to retrieve relevant documents or data at runtime,” says Ebrahim Alareqi, principal machine learning engineer at Incorta, a data and analytics platform provider. “This keeps the agent lightweight while still giving it access to enterprise-specific context when needed.”

Others praise MCP for its role in bringing common standards to agentic data retrieval. “MCP provides the plumbing that makes context engineering practical,” says Gil Feig, co-founder and CTO at Merge, an API platform provider. Without standards, teams end up building fragile custom data pipelines that break often, he adds.

Benefits of using MCP for gathering context

AI-assisted coding has some challenges. Most notably is a trust issue. The vast majority of developers don’t trust the output of AI coding agents — 96%, according to Sonar’s 2026 State of Code Developer Survey report. A second challenge is increased time spent reviewing and debugging AI-generated code. A late 2025 StackOverflow survey found nearly half of developers report frustration dealing with AI solutions that are “almost right, but not quite”.

Context engineering, as well as the use of MCP for this purpose, could help overcome many of these challenges. Using MCP servers, engineers can automatically append relevant logs or internal data to their prompts, refining LLM processing considerably to avoid irrelevant outputs.

The end result is improved accuracy. “MCP allows systems to dynamically fetch what the model needs, like APIs, databases, files, or domain knowledge,” says Neeraj Abhyankar, VP of data and AI at R Systems, a digital product engineering company. “This makes prompts leaner, reduces hallucinations, and ensures models operate with task‑relevant context.”

Another huge benefit is better context window management. Using MCP for context engineering can enable more efficient interaction with underlying models. “MCP tools can save you thousands of tokens just by ensuring you’re using the right things,” says Spacelift’s Stout.

Stout specifically highlights the GitHub MCP server. “It can now access specific files directly from GitHub and do GitHub searching and all the bells and whistles you expect when referencing GitHub,” he says. “MCP made retrieval from GitHub a million times better.”

Using MCP also enhances autonomy and scalability across an enterprise. “Teams can stop relying on partial views or anecdotal evidence and instead operate from a shared understanding,” says Pendo’s Olson. This greatly reduces the friction typically involved in stitching tools, building reports, or looping in teammates, he says.

All in all, the experts say the benefits of MCP in context engineering are numerous. Standardizing on MCP affords more focused prompts that generate more explicitly and relevant context, decreasing the likelihood of LLM hallucination and optimizing what the agent acts on. This in turn can lessen the manual review required for validation and debugging, reclaiming some developer time in the process.

Together, these benefits aim to solve many of the core issues inherent in AI-generated code and agentic workflows at large. “MCP shifts AI development from fragile prompt tuning to repeatable engineering,” says WaveMaker’s Jidigam. “The result is consistent behavior, minimal data exposure, and AI systems that can scale.”

To MCP, or not to MCP

Experts agree MCP can go beyond retrieval augmented generation (RAG) to provide more timely and relevant content in a more optimized fashion. “Traditional knowledge bases and RAG pipelines rely on pre-indexed snapshots,” says Sonar’s Kussberg. “In fast-moving environments, this quickly becomes outdated.”

For this reason and others, MCP unlocks all kinds of possibilities for developers. That said, the protocol is not a silver bullet for all use cases. It’s up against competing agentic protocols for some scenarios, and even simple CLI or direct API access for others.

Ballooning portfolios of MCP servers can increase LLM inputs substantially, too, requiring vigilant optimization techniques to avoid hitting token limits. Such strategies include intentionally designing tools, progressive disclosure, automated discovery, and other emerging tactics.

Then, there are MCP-related security concerns. The security model for the MCP protocol itself has matured quite a bit, but it’s incumbent upon implementers to enforce the correct permissions. “MCP, when implemented the right way, lets you enforce policy-driven access controls,” says Merge’s Feig. This should prevent a junior engineer, for instance, from accessing logs they’re not authorized to access, even if the agent has broader permissions, he adds.

To boost confidence using MCP within enterprise development settings, many experts recommend using an MCP registry that houses vetted, governed MCP servers approved for internal use. Other tools and practices, including agent skills, code mode, and emerging specifications for deterministic AI also promise to play a role in establishing context for agents.

Beyond MCP itself, Stout recommends using Claude Code’s tool search feature, which searches for tools without using token windows. He also highlights Sisyphus, an OpenCode-compatible agent for matching models with different tasks, and Plannotator, a plugin for Claude Code and OpenCode that can be used to plan projects, both of which can aid optimization.

Context is king

The pace of MCP development is accelerating. Analysis of 1,400 MCP servers by Bloomberry charted a 232% increase in six months, from August 2025 to February 2026. Interestingly, read operations outpaced write operations two to one, indicating these servers are performing a significant amount of data retrieval.

Looking to the future, context engineering is anticipated to continue cementing itself as a software discipline, while MCP wields the power to transform APIs into engines for agentic reasoning. As Jidigam says, “MCP-like abstractions will become standard infrastructure, much like REST did in earlier eras.”

Others are similarly confident. “In context engineering, MCP becomes the control plane agents use to access context, tools, and actions,” adds Incorta’s Alareqi. “It will be foundational as software becomes increasingly agent-driven.”

The underlying takeaway: MCP already plays a large role in context engineering, and will continue to do so. As the standard interface between AI systems and data, MCP is the primary vessel for dynamic cross-platform context retrieval at run time, allowing engineers to fetch documentation, API references, policies, available actions, and more.

However, this doesn’t mean context engineering has reached its zenith. Looking ahead, context engineering will evolve from fetching information to coordinating it, says Kussberg, combining multiple MCPs along the way. This will require increased discipline in enforcing standards, assessing risks, and validating changes more often, he says.

So, get started with context engineering using MCP, and stay alert to how your MCP servers are impacting LLM token usage and shaping workflows. The difference between context and non-context matters. Because, as they say, context is king.

Apple has confirmed this year’s Worldwide Developers Conference (WWDC) will take place June 8-12. The show begins with a keynote speech likely to be Tim Cook’s final public appearance as Apple’s CEO. His successor, John Ternus, will also be in the spotlight, but perhaps not quite as much as Apple’s promised smart Siri successor.

Getting AI right is incredibly important to the company this year, and Apple seems to recognize that. The official media invitation features a brightly glowing Swift logo with the tagline “Coming Bright Up,” which some see as a hint at the advanced AI capabilities Apple intends making available. It also hints at the new Siri user interface Apple is building, while the use of a Swift suggests the introduction of additional Foundation Models with which developers can add AI tools to their products.

On the developer website, Apple’s media images all show that bright glow, which also hints at potential improvements to Liquid Glass. There’s no doubt at all that the entire industry will be tuned into WWDC to find out where Apple is going with AI. So, no pressure there, right?

AI tools developers can use

The company told developers to expect more than 100 new videos about tools, technologies, and design, many of them to be revealed during the Platforms State of the Union address, which follows the keynote.

“WWDC26 will kick off June 8 with the Keynote and Platforms State of the Union, introducing incredible updates for Apple platforms, including AI advancements and exciting new software and developer tools,” Apple said, announcing the event.

Apple knows the world is watching and seems unlikely to want to disappoint its audience again, though the way it framed this in suggests some of the improvements will be for developers, with end users to benefit later. This is the approach Apple has taken with Foundation Models so far, though it isn’t yet clear if the company intends introducing a paid tier of APIs for developers. I’d consider that a risk at this stage, given the perception Apple faces.

What’s at stake?

A confluence of challenges means Apple is perceived as having fallen behind on AI. That’s got to hurt. The company is under a lot of pressure to push back against that viewpoint, and while that’s a challenge, it’s also a big opportunity. 

Wedbush Securities analyst Dan Ives says Apple is a “sleeping tech giant” poised for growth if it gets the mix right, predicting the company’s ecosystem could become the “consumer hub” of AI, to the extent that 20% of the global population will use Apple to access it. At Morgan Stanley, analyst Erik Woodring thinks what Apple is about to introduce will prompt a mass upgrade and sees revenue potential in AI services for the company. In general, people seem to agree that Apple’s ecosystem is more than capable of handling the demands of AI; the challenge is properly integrating it within Apple’s environment.

What is Apple Planning?

At the moment, strong speculation suggests Apple has added new Writing Tools, improved image generation on its devices, and has worked with Google Gemini to extend the number of available APIs developers can use, as well as enhancing contextual understanding by Siri.

Any one of these things would have impressed us all at one time, but in an AI world of Claude, Gemini, or even Grok, some will likely see even these enhancements as weak sauce. Additional key expectations include:

• Siri will become a chatbot-style assistant in the form of an LLM-enhanced app, built in partnership with Google Gemini.
• Apple will give users a choice of AI apps, including the ability to make whatever they choose the default on their system.
• Siri will gain a new interface hosted in the Dynamic Island on devices that support it.
• Siri might also gain the ability to string instructions together using a combination of text/speech and Shortcuts abilities. 
• You should see improved contextual awareness; Siri will be able to “see’”what’s on your screen and take relevant actions across one or more third-party apps.
• Those functions are likely to be delivered by App Intents, which permits developers to make app functions available across the system without opening the apps.
• Visual Intelligence will let the iPhone camera app identify more options, including objects and passes, such as for events and public transit.
• Multitasking on iPads should improve, while macOS might gain some touch-based interface improvements. That could set the scene for better integration between iPad and Mac, and, of course, make a touchscreen Mac possible.

Most recently, there’s been chatter about Apple introducing an iMac equipped with an M5 processor. If so, this could emerge at, or slightly before, WWDC.

As it does each year, the conference will feature the Apple Design Awards, Swift Student Challenge, Labs, and an in-person, 1,000 people gathering in Cupertino for the keynote. 

Watch it in real time

The keynote will be available to stream on Apple’s website. It will also be hosted on the Apple TV app and Apple’s YouTube channel, with playback on-demand after the event.

You can follow me on social media! Join me on BlueSky,  LinkedIn, and Mastodon.

As CNBC recently reported, some of the resistance to large AI data center construction is pushing the market to consider a more distributed model, including small compute systems designed for residential settings. The story pointed to pilot-stage thinking among companies such as PulteGroup, Nvidia, and Span, suggesting this is no longer just a home-lab fantasy or a fringe edge-computing thought experiment. It is now credible enough to be discussed by experts in housing, energy management, and economic infrastructure. It’s certainly not mainstream, but it is worth serious examination.

Economic forces at work

The timing is not accidental. Homes are expensive, especially for those who bought at the elevated prices and interest rates of late. Mortgage payments are a heavy burden; insurance and taxes continue to climb. In this housing market, homeowners are increasingly interested in turning underutilized parts of their properties into sources of recurring income. Spare rooms have become short-term rentals. Garages have become workshops or accessory units. Rooftops have become solar assets. Now, major players in the housing market are considering basements, utility rooms, and detached structures as potential spaces for small-scale server infrastructure.

At the same time, businesses are under pressure to rethink where compute lives. AI is increasing the demand for processing capacity. Edge workloads continue to grow. Not every application needs to run in a hyperscale facility, and not every business wants to pay for hyperscale economics. There is a strategic appeal to pushing workloads closer to users or into lower-cost, more widely distributed locations. Residential hosting becomes one possible answer to a question the industry is already asking: How much infrastructure can be decentralized without losing economic and operational control?

There is also a cultural shift at work. More technically capable homeowners now understand racks, uninterruptible power supply systems, network monitoring, remote access, and even local power upgrades. The old gap between enterprise infrastructure knowledge and prosumer infrastructure knowledge has narrowed. That makes the idea feel more achievable, even if the barriers to doing it commercially remain substantial.

Business models taking shape

The most important point to understand is that there is not yet a large, polished market in which random homeowners openly host random third-party servers the way people list rooms on Airbnb. What does exist are several adjacent business models that point in that direction without fully embracing the concept of residential colocation.

One model is the controlled edge-host program. In this arrangement, a company places or manages compute equipment in selected distributed locations, often with strict standards for connectivity, power, and maintenance. The homeowner or site operator is not acting as an open colocation provider. Instead, they participate in a curated hosting network where the provider controls the service architecture.

Another model is the decentralized compute marketplace. These platforms allow individuals or smaller operators to sell spare compute capacity from their own hardware. This is closer to the economics of monetizing residential infrastructure. Still, it is not the same as taking custody of someone else’s physical server and being responsible for the environment in which it runs. Selling compute cycles is one thing. Housing enterprise hardware is another.

A third model is the traditional infrastructure broker or marketplace. These companies already match buyers and sellers for colocation, bare-metal, and related services. They are proof that brokering infrastructure relationships is a viable business. But those relationships generally connect enterprises to professional facilities, not to homeowners willing to make room for a small server farm next to their furnace or water heater.

In other words, the components of a market are visible. Distributed demand exists. Brokering exists. Willing hosts likely exist. But the residential version remains incomplete because the trust, standardization, and liability models are still underdeveloped.

The upside is obvious

The strongest positive component of this potential market is its financial aspect. If a homeowner can generate enough monthly income to offset part of a mortgage payment, the idea will always attract attention, especially in newer housing markets, where monthly carrying costs are high, and people are seeking durable sources of supplemental income. Hosting infrastructure sounds like, at least in theory, a more stable and less socially intrusive way to monetize a property than opening a home to a constant stream of short-term tenants.

There is also an argument for asset utilization. Many homes contain underused spaces that could produce some economic return. A basement corner, a detached workshop, or a dedicated utility room may be worthless from a revenue perspective until someone turns it into something productive. If infrastructure providers are willing to pay for access to space, power, and connectivity, the home begins to function as part of the digital economy rather than simply as shelter.

For businesses, the appeal is equally straightforward. Residential locations may offer lower real estate costs, faster deployment, and better geographic distribution for select workloads. In regions with relatively inexpensive electricity and strong connectivity, a modest amount of residential hosting could fill gaps that do not warrant full commercial data center expansion. Homes will not replace data centers; rather, they might, in a very narrow set of circumstances, complement them.

The downsides are everything else

The problem with the whole idea is that the negatives are significant. Residential power is not data center power. Residential broadband is not enterprise-grade networking. A private home is not a secure, redundant, environmentally controlled facility, no matter how carefully a rack is installed.

Power is the first issue. Most homes are not designed to handle sustained commercial server loads without electrical upgrades. These upgrades can be expensive, heavily regulated, and dependent on local utility cooperation. Once backup batteries, uninterruptible power supply systems, cooling equipment, and dedicated circuits are added, the project starts to look less like a side hustle and more like a facilities operation.

Heat and noise follow quickly. Commercial hardware generates both continuously, which affect the comfort of the house, the cost of climate control, and the long-term reliability of the equipment. It also transforms residential life. Maintenance becomes routine. Monitoring becomes constant. The house begins to absorb the rhythm of an always-on machine room.

Then come the risks that stall many otherwise creative ideas. Fire hazards. Water damage. Physical theft. Tampering. Insurance complications. Zoning restrictions. HOA objections. Lease restrictions for tenants. Questions about who can access the equipment and when. Liability if a customer’s hardware is damaged. Compliance concerns if sensitive data or regulated workloads are involved. All of these factors are manageable in theory, but they are precisely why professional facilities exist.

Customer trust may be the biggest obstacle of all. Most businesses are comfortable buying compute from a recognized provider because they assume a predictable operating environment. That assumption weakens significantly when the infrastructure sits in a private residence. Who is responsible during an outage? What happens if there is a storm, a flood, or a neighborhood power event? How is physical access controlled? How are incidents documented? Those questions are not edge cases. They determine the model’s viability.

What is realistic from here?

Residential data hosting is unlikely to become the next mainstream large-scale hosting model. The economics of professional data centers still win in most situations because those facilities were built to solve exactly the problems that home models will struggle to address. Reliability, security, redundancy, and customer assurance are difficult and expensive to achieve. Purpose-built environments handle them better.

Still, the concept should not be dismissed outright. In some parts of the country, there may be a path forward. Cheap power. Upgradeable electrical service. Strong broadband. Detached or isolated space. Favorable local rules. Workloads that benefit from geographic distribution and do not require pristine enterprise conditions. In those scenarios, carefully managed micro-hosting could make sense.

That is probably the realistic future. Not an Airbnb for random servers. Not whole neighborhoods that are converted into basement data centers. Instead, a selective market where curated providers match specific homeowners or small properties with specific infrastructure needs under tightly controlled terms. What will start as a niche could still be enough to matter.

A widely active phishing-as-a-service (PhaaS) operation known as FlowerStorm has begun using a browser-based virtual machine to conceal credential theft code, marking what researchers say is an escalation in phishing-kit sophistication that could make attacks harder for traditional email and static-analysis tools to detect.

Researchers at Sublime Security said in April that they identified the campaign, which used KrakVM, an open-source JavaScript virtual machine recently published on GitHub, to obfuscate malicious code delivered via HTML attachments in phishing emails.

The campaign targets credentials and multi-factor authentication (MFA) codes for services including Microsoft 365, Hotmail, and GoDaddy, while also supporting adversary-in-the-middle (AiTM) interception techniques designed to hijack authenticated sessions.

“What makes this campaign notable is the adoption of KrakVM as a delivery wrapper within a month of the project’s public release,” the researchers wrote in a report.

The findings highlight how phishing operations are increasingly adopting techniques traditionally associated with sophisticated malware campaigns, including virtualized execution environments and layered obfuscation frameworks.

Browser-based VM used to hide phishing payloads

According to the report, victims receive phishing emails containing HTML attachments disguised as voicemail notices, invoices, or vendor communications. When opened in a browser, embedded JavaScript immediately launches a credential-harvesting workflow tailored to the victim’s environment.

The attack chain uses KrakVM to compile malicious JavaScript into encrypted bytecode, which is executed through a virtual machine running inside the browser.

“KrakVM compiles JavaScript into unreadable bytes,” the researchers wrote, adding that the virtual machine then interprets and executes the payload at runtime.

The approach adds multiple layers of obfuscation designed to complicate static analysis and evade traditional email-security tooling.

While virtual-machine-based obfuscation has long been used in malware packers and software protection systems, its adoption inside large-scale phishing kits appears far less common.

The campaign dynamically adapts to victims

After deobfuscation, the phishing payload loads infrastructure designed to impersonate Microsoft 365 and other login portals while dynamically adapting to targeted users.

According to the report, the malware can determine which authentication provider should be impersonated, preload victim email addresses into phishing pages, and customize branding elements such as company logos and backgrounds.

The phishing kit also enumerates MFA methods registered on victim accounts, including Microsoft Authenticator push notifications, TOTP codes, SMS authentication, and voice verification flows.

When the victim enters credentials, the kit forwards them to a command-and-control server, which attempts a real login against the target service. If the service prompts for MFA, the kit presents the victim with a matching prompt, captures the response, and forwards it to complete the attacker’s session.

Researchers said the framework supports real-time AiTM interception, allowing operators to relay authentication sessions while harvesting credentials and MFA tokens.

“A widely known unique feature of FlowerStorm is its capability for advanced AiTM and MFA interception,” the report said.

Detection challenges grow for defenders

The combination of VM-based obfuscation and AiTM-capable payload creates a detection gap for email security tools.

Sublime Security said its own Autonomous Security Analyst system identified the attack as malicious, partly because of the HTML attachment’s use of “heavily obfuscated JavaScript with custom virtual machine bytecode.”

The researchers also noted that both KrakVM and FlowerStorm appeared to operate close to their default configurations, suggesting the campaign did not require advanced technical sophistication from operators.

That raises concern that VM-based obfuscation techniques could spread quickly across phishing ecosystems if tooling becomes easier to operationalize, the report added.

The broader phishing ecosystem is evolving

The campaign has targeted sectors including local government, logistics, retail, communications, and real estate, according to the report. Researchers also identified infrastructure using domains designed to resemble court systems, enterprise portals, and Microsoft-related services.

Sublime published 153 indicators of compromise, including dozens of subdomains on cloud object storage services across regions, including Singapore, Bangkok, Frankfurt, Tokyo, Seoul, Jakarta, and Ashburn.

The researchers also identified domain naming patterns that overlap with prior FlowerStorm reporting, including German-language domains assembled from English words to mimic legitimate business names.

Sophos had documented FlowerStorm in December 2024, after the kit emerged following a disruption to the Rockstar2FA phishing service. The researchers said they had found no evidence linking the KrakVM developer to FlowerStorm operations.

The findings come as security teams face increasingly sophisticated phishing campaigns that blend credential theft, MFA interception, session hijacking, and anti-analysis techniques into unified attack chains.

“This campaign likely represents only the earliest use of KrakVM’s obfuscation capabilities,” the researchers wrote. “We anticipate more complex implementations as its adoption grows.”

A newly identified malware campaign is abusing Microsoft’s Phone Link feature to intercept SMS-based one-time passwords and other sensitive mobile data directly from Windows systems.

The activity, first observed by Cisco Talos in January 2026, involves a remote access trojan dubbed CloudZ and a custom plugin named Pheno that together allow attackers to harvest credentials and potentially capture authentication codes synced from a user’s smartphone, Talos researchers Alex Karkins and Chetan Raghuprasad wrote in a blog post.

“According to the functionalities of the CloudZ RAT and Pheno plugin, this was with the intention of stealing victims’ credentials and potentially one-time passwords (OTPs),” the researchers wrote.

The attack does not target the mobile device itself. Instead, it exploits the trust relationship between phones and Windows PCs by monitoring data mirrored through the Phone Link application, the blog post said.

CloudZ “utilizes the custom Pheno plugin to hijack the established PC-to-phone bridge by abusing the Microsoft Phone Link application, allowing the plugin to continuously scan for active Phone Link processes and potentially intercept sensitive mobile data like SMS and OTPs without deploying malware on the phone,” the Talos report said.

The technique sidesteps the need to compromise the mobile device itself, which the researchers said makes the intrusion notable to enterprise defenders.

It adds to a growing body of attacker tradecraft aimed at bypassing SMS- and app-based MFA by extracting authentication codes from compromised Windows systems where mobile data is synced.

Microsoft did not immediately respond to a request for comment.

Phone Link data becomes an attack surface

Microsoft Phone Link, previously known as Your Phone, is a built-in Windows feature that connects a PC to a smartphone and mirrors messages, notifications, and calls on the desktop.

Pheno is designed to locate the Phone Link data stored locally on the Windows system. According to the advisory, the attacker using CloudZ “can potentially intercept the Phone Link application’s SQLite database file on the victim machine, potentially compromising SMS-based OTP messages and other authenticator application notification messages.”

Because this data resides on the endpoint, the technique shifts risk from mobile devices to enterprise-managed Windows systems, potentially bypassing controls focused on securing smartphones.

Multi-stage infection chain

The intrusion begins with an unknown initial access vector, followed by the execution of a malicious file disguised as a ScreenConnect update, Talos said.

The initial payload is a Rust-compiled loader using filenames such as “systemupdates.exe,” which drops a .NET loader disguised as a text file in a system directory, the post said.

Persistence is established through a scheduled task named “SystemWindowsApis” that runs at startup with elevated privileges using the legitimate regasm.exe utility, the researchers wrote in the blog.

The .NET loader runs anti-analysis checks before unpacking CloudZ. It performs multiple checks to detect security tools and sandbox environments before executing the payload in memory, the report said.

It “calculates the actual elapsed time of a sleep command to detect if it is executed in the analysis environment,” and scans for tools such as Wireshark, Fiddler, Procmon, and Sysmon. “The .NET loader exits the execution if these are detected in the victim environment,” the blog post added.

The CloudZ payload is then decrypted in memory and executed, it said.

RAT enables credential theft and plugin delivery

CloudZ establishes an encrypted connection to a command-and-control server and supports a range of functions, including credential harvesting, file operations, and remote command execution, Talos said.

The malware also retrieves secondary configuration data from attacker-controlled infrastructure.

The Talos researchers wrote that the RAT downloads configuration data from remote servers and “extracts the C2 server IP address … and port number … establishing connections through TCP sockets.”

It also rotates user-agent strings to blend its traffic with legitimate browser activity, the researchers noted.

Pheno plugin monitors active device sync

The Pheno plugin is responsible for identifying active Phone Link sessions and enabling data interception.

It “scans all running processes for specific keywords such as ‘YourPhone,’ ‘PhoneExperienceHost,’ or ‘Link to Windows,’” and logs results locally, the report said.

The plugin then checks for evidence of a proxy connection used by Phone Link to relay data between devices.

“The presence of ‘proxy’ … indicates that the Phone Link session is actively routing traffic through its relay channel,” the researchers wrote.

When such activity is detected, the plugin flags the system as connected, which “eventually allows the attacker … to potentially monitor SMS or OTP requests that appear on the Phone Link application,” according to the report.

Talos has released detection signatures and indicators of compromise, including malware hashes, command-and-control infrastructure, and Snort rules associated with the activity.

Cisco Talos did not attribute the activity to a known threat actor.

The article originally appeared on CSO.

A newly identified malware campaign is abusing Microsoft’s Phone Link feature to intercept SMS-based one-time passwords and other sensitive mobile data directly from Windows systems.

The activity, first observed by Cisco Talos in January 2026, involves a remote access trojan dubbed CloudZ and a custom plugin named Pheno that together allow attackers to harvest credentials and potentially capture authentication codes synced from a user’s smartphone, Talos researchers Alex Karkins and Chetan Raghuprasad wrote in a blog post.

“According to the functionalities of the CloudZ RAT and Pheno plugin, this was with the intention of stealing victims’ credentials and potentially one-time passwords (OTPs),” the researchers wrote.

The attack does not target the mobile device itself. Instead, it exploits the trust relationship between phones and Windows PCs by monitoring data mirrored through the Phone Link application, the blog post said.

CloudZ “utilizes the custom Pheno plugin to hijack the established PC-to-phone bridge by abusing the Microsoft Phone Link application, allowing the plugin to continuously scan for active Phone Link processes and potentially intercept sensitive mobile data like SMS and OTPs without deploying malware on the phone,” the Talos report said.

The technique sidesteps the need to compromise the mobile device itself, which the researchers said makes the intrusion notable to enterprise defenders.

It adds to a growing body of attacker tradecraft aimed at bypassing SMS- and app-based MFA by extracting authentication codes from compromised Windows systems where mobile data is synced.

Microsoft did not immediately respond to a request for comment.

Phone Link data becomes an attack surface

Microsoft Phone Link, previously known as Your Phone, is a built-in Windows feature that connects a PC to a smartphone and mirrors messages, notifications, and calls on the desktop.

Pheno is designed to locate the Phone Link data stored locally on the Windows system. According to the advisory, the attacker using CloudZ “can potentially intercept the Phone Link application’s SQLite database file on the victim machine, potentially compromising SMS-based OTP messages and other authenticator application notification messages.”

Because this data resides on the endpoint, the technique shifts risk from mobile devices to enterprise-managed Windows systems, potentially bypassing controls focused on securing smartphones.

Multi-stage infection chain

The intrusion begins with an unknown initial access vector, followed by the execution of a malicious file disguised as a ScreenConnect update, Talos said.

The initial payload is a Rust-compiled loader using filenames such as “systemupdates.exe,” which drops a .NET loader disguised as a text file in a system directory, the post said.

Persistence is established through a scheduled task named “SystemWindowsApis” that runs at startup with elevated privileges using the legitimate regasm.exe utility, the researchers wrote in the blog.

The .NET loader runs anti-analysis checks before unpacking CloudZ. It performs multiple checks to detect security tools and sandbox environments before executing the payload in memory, the report said.

It “calculates the actual elapsed time of a sleep command to detect if it is executed in the analysis environment,” and scans for tools such as Wireshark, Fiddler, Procmon, and Sysmon. “The .NET loader exits the execution if these are detected in the victim environment,” the blog post added.

The CloudZ payload is then decrypted in memory and executed, it said.

RAT enables credential theft and plugin delivery

CloudZ establishes an encrypted connection to a command-and-control server and supports a range of functions, including credential harvesting, file operations, and remote command execution, Talos said.

The malware also retrieves secondary configuration data from attacker-controlled infrastructure.

The Talos researchers wrote that the RAT downloads configuration data from remote servers and “extracts the C2 server IP address … and port number … establishing connections through TCP sockets.”

It also rotates user-agent strings to blend its traffic with legitimate browser activity, the researchers noted.

Pheno plugin monitors active device sync

The Pheno plugin is responsible for identifying active Phone Link sessions and enabling data interception.

It “scans all running processes for specific keywords such as ‘YourPhone,’ ‘PhoneExperienceHost,’ or ‘Link to Windows,’” and logs results locally, the report said.

The plugin then checks for evidence of a proxy connection used by Phone Link to relay data between devices.

“The presence of ‘proxy’ … indicates that the Phone Link session is actively routing traffic through its relay channel,” the researchers wrote.

When such activity is detected, the plugin flags the system as connected, which “eventually allows the attacker … to potentially monitor SMS or OTP requests that appear on the Phone Link application,” according to the report.

Talos has released detection signatures and indicators of compromise, including malware hashes, command-and-control infrastructure, and Snort rules associated with the activity.

Cisco Talos did not attribute the activity to a known threat actor.

The question nobody is asking loudly enough

I keep hearing the same AI conversation everywhere I go. Better models, faster inference, more capable agents. The race is on and everyone wants in.

But something is missing.

Most organizations I work with have already moved past experimentation. AI is embedded in workflows, shaping customer interactions, processing internal documents, informing operational decisions. The question of whether AI works has largely been answered. What has not been answered, in most cases, is something far more basic.

Where does our data actually go when it flows through an LLM? Who can access it? Under which jurisdiction is it processed? Could it end up improving someone else’s model?

These are not hypothetical concerns. These are the questions that surface when a regulator asks how your organization handles personal data, when a client wants to know what happens to the documents they share with your AI-powered service, or when a board member reads about a policy change at one of the major AI providers and wants to know what it means for the business.

In my experience, most organizations cannot answer these questions clearly. Not because they do not care, but because the adoption moved faster than the governance. Teams were encouraged to experiment, pilots became production and somewhere along the way, the data conversation got left behind.

This is not a fringe problem. Recent industry data suggests that most enterprise leaders are now actively redesigning their data architectures, not because the AI did not work, but because the way it was connected to their data became a liability.

The capability conversation has dominated for the last two years. I think the next two years will be defined by a different question entirely: Not what can AI do, but who controls what it knows?

Your data is already travelling further than you think

When I talk to CIOs about AI risk, the conversation almost always starts with model accuracy, hallucinations or bias. Rarely does anyone open with: “Do we actually know where our data goes when someone on the team uses an LLM?”

That question matters more than most people realise. Not because of some hypothetical future breach, but because right now, most organizations are operating across a mix of LLM tiers and tools with no unified picture of what data is going where or under what terms.

OpenAI, Anthropic and Google all operate a two-tier system. At the enterprise and API level, based on publicly available policies, the commitments are clear: Your data is not used for model training. But those protections only apply if everyone in your organization is using the enterprise tier. In practice, that is almost never the case.

Teams sign up for free accounts to test things quickly. Employees paste internal documents into consumer-tier tools because it is faster than raising a ticket. Contractors use personal subscriptions for client work. None of this is malicious. All of it is invisible to leadership.

And the consumer tiers operate under very different rules. OpenAI’s consumer ChatGPT may use conversations for model improvement unless the user opts out. Google’s free Gemini tier works similarly. In September 2025, Anthropic introduced changes to its consumer terms: Conversations are now eligible for training by default, with data retention extending from 30 days to up to five years.

This is the shadow AI problem. Corporate data entering consumer-tier systems where it may be retained for extended periods and processed under terms nobody in the organization approved. Not because anyone made a bad decision, but because no one made a deliberate one.

When a regulator in Riyadh asks how your organization handles personal data processed through an LLM, or a client in Doha wants to know where their documents went after your team used AI to summarise them, “we think we are on the enterprise tier” is not a defensible answer. The problem is not that something has gone wrong. It is that most organizations could not prove things are going right.

The sovereignty map is more complicated than people think

Most conversations about data sovereignty still default to one question: Where is the data stored? In the context of AI, that is not enough.

I work across the UK, the Gulf and Europe. Each region is moving toward stronger data protection, but they are getting there differently, at different speeds and with different expectations. For any organization operating across borders, that creates real tension.

In Europe, GDPR set the foundation and the EU AI Act is raising the bar further. In Saudi Arabia, the PDPL is no longer a paper exercise. SDAIA issued 48 enforcement decisions in 2025 and published cross-border transfer rules requiring a four-step risk assessment before personal data leaves the Kingdom. In Qatar, the PDPPL has been in place since 2016, but enforcement was historically light. That changed in late 2024, with the National Data Privacy Office now issuing binding decisions against organizations found in violation.

Now add the LLM layer.

When an organization sends data through a cloud-based LLM, the question is not just where the data is stored. It is where the data is processed at inference time. Your infrastructure might sit in Riyadh, but if the model processes your prompt on a server in another jurisdiction, most legal frameworks would say sovereignty has not been preserved.

And as organizations move toward agentic AI, this gets harder still. Agents do not respond to a single prompt. They retrieve context from multiple sources, call external tools and chain decisions across systems. Each step is a potential jurisdiction question and a potential compliance gap that nobody mapped.

Sovereignty is not just geography. It has at least four dimensions: Where data and compute reside, who manages them, who owns the underlying technology and who governs it. Most organizations are only thinking about the first one.

The real trade-off: Pay to keep your data or pay with your data

Once an organization recognises the sovereignty problem, the natural instinct is to bring everything in-house. Run your own models, keep your data on your own infrastructure, remove the dependency on external providers entirely.

That instinct is understandable. It is also expensive.

Local models like Llama and Mistral give you full control. No data leaves your boundary. No third-party terms to worry about. No inference happening in a jurisdiction you did not choose. On paper, it solves the problem.

In practice, a production-grade on-premise deployment for a 70 billion parameter model costs anywhere from $40,000 to $190,000 in hardware alone. Self-hosting only becomes cost-effective if you are processing above roughly two million tokens per day. Below that, the API is cheaper. On top of the hardware, you need the talent to deploy, fine-tune, secure, patch and maintain these systems over time. That is not a one-off cost. It is an ongoing operational commitment that most organizations underestimate.

And there is a capability gap. The frontier models, the ones that perform best on complex reasoning, coding, analysis and multi-step tasks, are not available for self-hosting. If your use case demands the best available performance, you are using an API. That means your data is leaving your boundary, processed under someone else’s terms, in someone else’s infrastructure.

So, the trade-off is real. At the extremes, you are either paying serious money to keep your data close, or you are paying with your data by accepting terms you may not fully understand. Most organizations sit somewhere in between, but very few have made that choice deliberately. It happened by default. Someone picked a tool, someone else signed up for an account, a pilot became production and suddenly the organization is operating across a patchwork of tiers, agreements and jurisdictions that nobody designed and nobody fully controls.

This is not a technology decision. It is a strategic one. And it belongs in the boardroom, not buried in an IT procurement process.

The market is already restructuring around sovereignty

If you want to know where enterprise AI is heading, follow the money.

The sovereign cloud market is projected to grow from $154 billion in 2025 to over $800 billion by 2032. That is not a forecast driven by hype. It is driven by enterprise buyers telling their providers: We need to control where our data lives and how it is processed.

The response has been significant. Microsoft launched Foundry Local, which lets organizations run large AI models on their own hardware in fully disconnected environments, and committed to processing Copilot interactions in-country for 15 nations by the end of 2026. Google and Oracle are pushing a model where AI services move to where the data lives rather than the other way around, deploying their cloud stacks inside customer infrastructure and sovereign regions.

These are not experimental initiatives. They are multi-billion-dollar structural shifts. And they tell me something important: The providers are not leading this conversation. They are responding to it.

But it is worth being honest about what sovereign offerings deliver today. They come with cost premiums, longer deployment timelines and in some cases a reduced feature set. The trade-off does not disappear. It changes shape. CIOs still need to understand what sovereignty means for their specific context, not just trust that a sovereign label on a cloud product solves the problem.

What CIOs should be doing now

If I were advising a CIO today, I would not start with tools or vendors. I would start with visibility.

Know exactly what data flows through which LLM and under what terms. Not at the contract level, at the actual usage level. Which teams are using which tools? Are they on consumer or enterprise tiers? Who approved the terms? If you cannot answer those questions today, that is the first problem to solve.

Map your data exposure against every jurisdiction you operate in, and do not stop at storage. Understand where inference happens. Understand where context is retrieved from. If you are operating across the EU, Saudi Arabia and Qatar, those are three different regulatory frameworks with three different enforcement postures, and the LLM layer touches all of them.

Audit for shadow AI. Not as a one-off exercise, but as a recurring part of your governance. Employees are not going to stop using AI tools. The goal is not to block adoption. It is to make sure adoption happens on terms the organization has chosen deliberately.

Do not default to local models out of fear or cloud models out of convenience. Make the trade-off intentionally, with real cost and capability analysis behind it. Understand what you gain and what you give up in each direction and make sure that decision is documented and owned at the right level.

Build procurement frameworks that treat LLM data handling as a first-class requirement. Not a footnote in a vendor assessment, but a core criterion alongside security, resilience and performance. If a provider cannot clearly explain what happens to your data, that is not a gap in their documentation. It is a gap in their offering.

The readiness gap is real. 95% of enterprise leaders say they plan to build sovereign AI foundations. Based on current research, only 13% are on track. The organizations that close that gap first will scale faster, win more trust and defend their choices with confidence. The rest will have the conversation forced on them.

From AI capability to AI sovereignty

For the last couple of years, the focus has been on what AI can do. Bigger models, faster outputs, more automation. That progress is real and I do not think anyone should slow down.

But I think the next phase will be defined by something different. Not capability, but control. Not what the model can do, but whether you can prove you know where your data went, who had access to it, what terms governed it and what happens to it next.

CIOs will not be judged on whether they adopted AI. They will be judged on whether they adopted it in a way they can defend. To a regulator. To a client. To a board. In plain language, with evidence they can stand behind.

In my first article for CIO Network, I argued that explainability is the control layer that makes AI safe to scale. Data sovereignty is the other half of that equation. Explainability answers “why did the system do that?” Sovereignty answers “where did the data go and who controls it?”

If you can answer both, you can scale with confidence. If you cannot, you are building on a foundation you do not fully own.

And once that foundation is questioned, it is very difficult to rebuild.

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

Apple last week nixed its long-held “net cash neutral” target, a move analysts see as giving the company more flexibility to make massive infrastructure investments or acquisitions. Naturally, as AI is the only thing that seems to matter in tech these days, commentators rushed to speculate on potential acquisition targets in the AI space.

The thing is, this may not be about AI. 

Now that Apple has confirmed John Ternus as its next CEO, the market can stop treating the company’s cash shift as speculative and start treating it as strategic. Ternus, a hardware‑first leader by background, understands the value of services and has pledged to expand Apple’s services business. 

Services, services, services

The great thing about services is that they provide the company with a solid and predictable revenue stream to insulate it from fluctuations in product-driven business. We’ve seen this in the last few years, with Apple’s dramatically climbing services income acting as a cushion against slow product quarters, empowering the company to return successive record results. There is no doubt the high margins generated by services oils Apple’s business machinery.

“I look forward to continuing to expand that and continuing to look for the kinds of services where we’re really finding the opportunities between the hardware and software,” Ternus said, pointing particularly at Apple Pay. 

Years of watching the company tells me that Apple tends to leave the truth in plain sight if you happen to be sensitive to it; I read that statement as suggesting the company is preparing to introduce its latest Apple Pay service updates.

Apple Card for the rest of us?

The most widely awaited of these would be the introduction of an upgraded Apple Card service with a new provider. The limitation of the Apple Card (other than the waning enthusiasm of card partner, Goldman Sachs and the long journey to find a new partnership with JP Morgan Chase) is that it is still only available in the US, despite global interest. It is challenging for Apple to meet that interest due to a smorgasbord of different data, financial services, and local regulations. Apple Card in India, for instance, would be challenged by local regulations that forbid banking partners from storing transaction data, while in Europe the reward structure would need to be revised to consider the much lower interchange fees charged for credit card transactions there. 

Ultimately, whoever Apple works with on the service would have to accommodate credit risk and it’s probable the computer company will need to underwrite some of that risk. If it wants to expand this service internationally — perhaps with the provision of additional banking services in some nations — this would be a good use of Apple’s ongoing money mountain, enabling it to deepen its move into financial services.

A world of opportunities

Of course, Apple Card is far from the only service that could benefit from Apple’s decision to use cash more strategically. Beyond any potential AI acquisitions, the company could also take positions in streaming entertainment partners, for example; the ever-speculated on Disney purchase is just one of a multitude of options there, but Netflix also seems within Apple’s multi-billion dollar reach.

Apple also has the good fortune to sit at the crossroads of technology, the liberal arts, and health, so it could think about health insurance as a potential space for services expansion. Also, given the company’s continued move to rebuild its business along the lines of a closed loop manufacturing chain, at what point does it make sense for it to invest in its own clean energy supply? 

Stop to think about it and there really are a ton of highly profitable options for major Apple investments that could drive the business forward, and many of these have nothing much to do with AI (except, of course, software). Perhaps that’s a good thing. 

Smart about AI

The rapid pace of AI development and deployment almost certainly mean the fundamentals of the AI landscape will change swiftly. Server-based AI might remain the interaction for most of us, but high-value services will inevitably be found in on-premises, sovereign, ultra-secure, and/or edge device AI. 

That rapid evolution means a billion spent on an essential component today could be meaningless in five years. Plus, with a multitude of emerging AI companies, it’s inevitable some — potentially with valuable technologies — will fail. 

In this context, it makes sense for Apple to crouch, tiger-like, waiting to jump in to make strategic acquisitions as the competitive environment forces some of the smaller AI players to the wall. Apple won’t be alone in any potential bidding wars, but its decision to use its cash flow strategically means it might nail some of those deals. 

Coming soon?

The timing of Apple’s news about its handling of cash matters. Now that shareholders have been told to expect it, the business can change direction. 

Should we expect any immediate moves? If the company has any quick plans, it’s possible we may learn more at WWDC in June — or perhaps at the big iPhone reveal this fall, when the Cook-Ternus transition is complete. Ultimately, Apple’s next phase won’t be defined solely by what it does acquire, but in which parts of the business it chooses to invest.

Please follow me on social media: BlueSky,  LinkedIn, or Mastodon.

Quantum computers are prone to high error rates, so, to make qubits usable, a lot of redundancy is required. It typically takes hundreds—even thousands—of physical qubits to make one usable, “logical” qubit.

This has been a major obstacle to the development of practical quantum computers. If thousands of qubits are needed for a quantum computer to do anything useful, and it takes a thousand physical qubits to make one logical one, then we’re talking millions of qubits—and, today, the largest qubit array is just more than 6,000 qubits, and that was an experimental demonstration.

The largest general-purpose quantum computers today are IBM’s Condor, with 1,121 superconducting qubits, and Atom Computing’s AC1000 with more than 1,200 neutral atom qubits—and both counts are for physical qubits, not logical qubits.

Last week, quantum computing company QuEra published a paper showing that a logical qubit can be built with just two physical qubits. Neutral atom computers have two types of qubits—memory and computation—and these qubits can be moved from one mode to another. The two-to-one ratio is currently just for the memory qubits.

“The paper does not show—yet—that you can do operations on the qubit,” says Yuval Boger, chief commercial officer at QuEra Computing. “We’ve done it with other codes, but not this particular one. But without quantum memory, the quantum computer won’t work anyway.”

The same algorithm should also have a very significant improvement in error correction on the entangled computation side of the quantum computer as well, he adds. “But we haven’t published that result yet,” he says. “I’m sure that will be forthcoming.”

Like Atom Computing, QuEra makes a neutral atom quantum computer, and its Gemini model has 260 physical qubits and is commercially available.

“We’ve demonstrated a 3,000-qubit machine running continuously,” Boger adds.

That puts a usable quantum computer within sight, he says. “There is still work to be done. But it’s not years and years and years.”

The timeline has also been affected by recent changes in estimates as to how many qubits a quantum computer actually needs to be useful. For example, according to the latest Google research, it could take as few as 1,200 logical qubits for a quantum computer to break elliptic curve cryptography.

The QuEra announcement is also helping position neutral atoms as a viable alternative to the superconducting approach, such as the one used by IBM, says Holger Mueller, analyst at Constellation Research.

“It’s the race for error correction,” he says. The question is whether QuEra’s approach will be the one that works. “How good or record-breaking the result is remains to be seen,” Mueller says.

And the paper is focused on memory, he adds, though the company plans to use the same algorithm for other qubits. “So, it is a key report to keep the neutral atom technology and vendors viable,” he says.

According to Sridhar Tayur, professor of operations management at Carnegie Mellon University’s Tepper School of Business, there are four levels of quantum computing breakthroughs.

“There’s something on paper, then there’s something in a lab, like a proof of concept,” he says. “Then there’s a prototype at scale, and then there’s production scale.”

The QuEra announcement is just at the research paper level, he says. Many people see these theoretical results, and their minds immediately jump to commercial products, he says. “But it’s not like they even have a physical demonstration of this,” Tayur says.

The security industry has spent years building better authentication. Longer passwords, second factors, hardware tokens. And attackers responded by moving past authentication entirely.

Adversary-in-the-middle (AiTM) phishing does not steal credentials and replay them. It sits between the user and the legitimate service, watches a real authentication succeed in real time, and walks away with the session token that proves it happened. The login was genuine. The MFA prompt was real. The attacker just observed — and copied the result.

If you have read the analysis of how these attacks work, you understand the mechanism. This piece is about what comes after that understanding. Specifically: What controls reduce risk when the attack does not touch credentials at all?

Why most current defenses miss the point

The instinct after learning about AiTM phishing is to strengthen authentication. Buy hardware keys. Deploy passkeys. Force phishing-resistant MFA for privileged accounts.

That instinct is correct but incomplete.

Phishing-resistant authentication stops the credential theft phase. FIDO2 and passkeys bind the authentication challenge cryptographically to the legitimate domain, so a proxy domain cannot complete the handshake. This works. Organizations that have deployed passkeys broadly have significantly reduced their AiTM exposure at the authentication layer.

But authentication is not the only layer that matters. Session tokens issued after successful authentication are the real target, and most organizations treat them as inherently trustworthy once issued. They are not.

A session cookie is a bearer token. Whoever holds it is authenticated. There is no cryptographic binding between the token and the device that generated it, no ongoing proof that the holder is who they claim to be, and no automatic expiry triggered by location change or device mismatch. An attacker who steals a session token in one country can replay it from another, and the identity provider will accept it as legitimate.

This is where most defenses currently have a gap.

The 3 controls that close the gap

Control #1: Bind sessions to managed devices

The most impactful single control for session security is requiring managed, compliant devices as a condition of accessing sensitive resources. When access policies — such as Microsoft Entra Conditional Access — require that the device presenting a session token is enrolled, managed and meets compliance requirements, stolen tokens become significantly harder to replay.

An attacker who intercepts a session token cannot easily replay it from an unmanaged machine if the policy requires device compliance. The session gets terminated. The attacker needs not just the token but also a compliant device — a much higher bar.

This control is not foolproof. Sophisticated attackers can attempt to compromise managed devices directly. But it eliminates the easiest replay vector: Taking a stolen token and opening it in a browser on a completely different machine.

The practical challenge is rollout. Requiring managed devices for all users immediately creates friction for contractors, part-time workers and anyone using personal devices for work. The pragmatic approach is to start with the highest-risk access: Administrative roles, finance systems and any application handling sensitive data. Expand from there as device management coverage improves.

Control #2: Monitor for post-authentication anomalies

AiTM attacks do not generate failed login attempts. They generate successful ones. Traditional monitoring focused on authentication failures will miss these attacks entirely.

The signals that matter are in what happens after authentication succeeds. Specifically:

• Impossible travel. If a session authenticates from one location and then accesses resources from a geographically distant location minutes later, that warrants investigation. The time between events matters — a session that authenticates in New York and then accesses resources from a different continent thirty minutes later is not a normal user scenario.
• New device registration. Attackers who gain session access often immediately register a new MFA device or add a new authentication method to ensure persistent access. A new device registration occurring within minutes of a successful login is a high-fidelity signal worth alerting on.
• Inbox rule creation. A consistent post-compromise behavior across many attack campaigns is the creation of email forwarding rules or inbox filters designed to hide security alerts and forward communications to attacker-controlled addresses. Microsoft’s own incident response teams have documented this pattern repeatedly. Monitoring for inbox rule creation, particularly rules that forward externally or hide emails containing specific keywords, catches this behavior reliably.
• Privilege escalation attempts. Attackers who gain access to a standard user account typically attempt to escalate to higher-privilege roles or access administrative interfaces. Anomalous access attempts against admin portals or privilege management systems shortly after a new session authentication are worth flagging.

None of these signals is conclusive on its own. But building detection rules around the combination — successful authentication followed by impossible travel followed by new device registration, for example — creates a detection capability that catches AiTM post-compromise activity that authentication monitoring misses entirely.

Control #3: Shorten session lifetimes for high-value access

Long-lived session tokens give attackers more time to operate after a successful interception. A token that remains valid for seven days provides a much larger window than one that expires after an hour and requires reauthentication.

The friction of more frequent reauthentication is real. Users notice. For productivity applications used continuously throughout the day, aggressive session timeouts create a poor experience.

The answer is risk-based session management rather than uniform policies. Sessions accessing low-sensitivity productivity tools can have longer lifetimes. Sessions accessing financial systems, administrative interfaces, HR data or anything handling regulated information should have short lifetimes and require reauthentication before performing sensitive operations. NIST’s Digital Identity Guidelines provide a useful framework for thinking about session timeout thresholds by assurance level.

This approach concentrates the friction where the risk is highest, which makes it more defensible to users and leadership alike.

The training problem has not gone away

Technical controls reduce risk. They do not eliminate it. Users remain part of the attack surface, and the awareness training most organizations provide does not prepare them for what AiTM phishing looks like.

Traditional phishing training teaches people to look for indicators of fake pages: Misspellings, suspicious URLs, unusual sender addresses. AiTM phishing pages show none of these indicators because they are not fake. They proxy the real service in real time. The URL may be suspicious, but users who click links in emails rarely check URLs carefully, even after training.

The one behavioral change that reduces AiTM exposure is simple and teachable: Do not start authentication flows from links in emails. Navigate directly to the service. Bookmark login pages. If you receive an email telling you to log in somewhere, open a browser tab and type the address yourself rather than clicking through.

This sounds obvious. It is not instinctive. Most users have spent years clicking login links in emails because it is faster and those links usually are legitimate. Changing that behavior requires explicit, repeated training that explains why the old approach is no longer safe — not just instruction to be more suspicious of phishing generally.

Pair this with a low-friction reporting mechanism. Users who notice something feels wrong should be able to flag it in seconds. The value of early reporting in limiting the damage from a successful session compromise is significant, and that value disappears if reporting requires effort or feels like it will generate blame rather than action.

The honest assessment

AiTM phishing is a real and growing threat. Phishing-as-a-Service platforms like Tycoon 2FA and FlowerStorm have lowered the barrier to entry to the point where this is no longer an advanced technique requiring sophisticated threat actors. It is a commodity attack available to anyone willing to pay a subscription.

The organizations that reduce their exposure are those that treat session security as seriously as credential security, build detection capability around post-authentication behavior rather than just failed logins, and give users a realistic model of how modern phishing works.

Phishing-resistant authentication is the right long-term direction. Getting there takes time, budget and change management. In the meantime, the controls above provide meaningful risk reduction without waiting for full passkey deployment.

The goal is not to make AiTM attacks impossible. It is to make them expensive enough that attackers move on to easier targets.

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

Workers are facing a conundrum: They worry about the potential for their displacement by AI even as it dramatically speeds up their own productivity.

According to a new survey from Anthropic, workers in roles most likely to be taken over by AI (developers or IT workers, for instance) recognize their precarious position. Yet, perhaps naturally, they readily adopt the tools that could take their jobs, and see first-hand how well they work.

This measurement is fundamentally different from the way others are gauging AI job displacement, noted Thomas Randall, research director at Info-Tech Research Group.

While macro reports, such as those from Goldman Sachs, the International Monetary Fund (IMF), or the World Economic Forum (WEF), are asking what share of existing job tasks AI could theoretically perform in the future, “Anthropic is measuring qualitative experiences of workers in the present,” he pointed out. This “tells us how people are navigating this landscape in real time.”

The paradox of AI in the workforce

Anthropic’s survey of 81,000 Claude users gauged peoples’ “visions and fears” around advances in AI, and weighed these findings against the company’s own measurement of jobs most vulnerable to AI displacement. This was based on Claude usage data; jobs are identified as more exposed when associated tasks are significantly performed on the platform, in work-related contexts, and take up a larger share of a role.

Some occupations at risk include computer programmers, data entry keyers, market researchers, software quality assurance analysts and testers, information security analysts, and computer user support specialists.

Overall, one-fifth of respondents expressed concern about displacement, noting that their job, or at least aspects of it, is being taken over by automation. Those in jobs identified as most exposed readily recognized that fact, voicing worry three times as often as those in less at-risk positions. One software engineer remarked: “like anyone who has a white collar job these days, I’m 100% concerned, pretty much 24/7 concerned, about losing my job eventually to AI.”

Early-career respondents were also more nervous than others.

At the same time, those in the highest-paid occupations reported the largest productivity gains when using AI. This is most notably in terms of their ability to perform new tasks, which was cited by 48% of users. In addition, 40% of workers said the technology helped speed up their work, and a little more than 10% said it improved the quality of their work.

In general, enterprise usage of AI is “actually quite consistent,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. Teams are using the technology “where information is abundant and time is limited,” such as in drafting documents and code, summarizing content, responding to customer queries, navigating internal systems.

Is AI actually creating more work?

Still, not everyone thinks AI makes their jobs easier or faster. In some cases, people felt it made their work harder; for instance, project managers are assigning tickets for issues that are much more difficult to solve, Anthropic noted.

Gogia agreed that, even when tasks become easier, scope and responsibilities expand, and roles can absorb adjacent tasks. This results in a “redistribution of effort,” rather than a reduction of effort.

“Faster generation means higher expectations on quality,” he said. More output feeds into decision pipelines that are already constrained. “In some cases, the system becomes heavier, not lighter.”

Delayed impact on enterprises

 The market is rewarding those who can integrate AI into complex workflows to do more, faster, and often with better outcomes, Gogia noted. However, the most exposed tasks, including  documentation, basic coding, routine analysis, and structured support work, often “sit at the base of the experience ladder.”

These very tasks traditionally have given entry-level workers a way in, and the automation of them reduces the urgency for companies to hire them. “What you begin to lose is not the job,” said Gogia. “It is the path into the job.”

This can have a delayed impact; enterprises may not realize until years later that they do not have enough mid-level experts because they didn’t bring enough people in at lower levels. As AI plays a greater role in the workplace, there must be a “conscious effort” to rethink how people enter and grow, Gogia said. “New pathways need to be created, and they need to be deliberate.”

How enterprise leaders should adjust

As is often the case, sentiment moves faster than structural change, Gogia pointed out. Workers feel the shift almost immediately, but organizations take longer to adjust hiring, redesign roles, and rethink workforce structures.

“This is why expectations can become misaligned,” he noted. The reality is that most enterprises have introduced AI into existing ways of working without fundamentally changing them. Acceleration occurs in unchanged systems that still carry the same dependencies, approval chains, and coordination challenges.

Ultimately, Gogia advised, leaders must approach the shift with “intentional design.” This requires clarity, he emphasized; people need to understand how their work is expected to change. What will be enhanced? What will reduce? Where should they focus their development?

Baselines are moving: Roles may begin to look “oversized” as what used to be considered a full day’s work begins to look like half a day’s work, or what used to be considered efficient begins to look average. “AI is changing how work is done, but more importantly, it is changing what work expects from people,” said Gogia.

As well, Info-Tech’s Randall pointed out that workers who experience AI expanding what they can do by performing tasks previously outside their competence appear to relate to AI more positively than those who experience it as doing their existing job faster. So, he advised, “tech leaders should design AI deployment around capability extensions.”

Along with goal setting, managers must have support, Gogia emphasized. They set expectations and interpret strategy, and when they’re not properly equipped, “even the best tools will fall short,” he said. Measurement must also evolve; enterprises need to look at quality, sustainability, and capability development over time.

“What we are witnessing right now is not a sudden disruption,” said Gogia. “It is a gradual shift that is becoming impossible to ignore.”

Workers are facing a conundrum: They worry about the potential for their displacement by AI even as it dramatically speeds up their own productivity.

According to a new survey from Anthropic, workers in roles most likely to be taken over by AI (developers or IT workers, for instance) recognize their precarious position. Yet, perhaps naturally, they readily adopt the tools that could take their jobs, and see first-hand how well they work.

This measurement is fundamentally different from the way others are gauging AI job displacement, noted Thomas Randall, research director at Info-Tech Research Group.

While macro reports, such as those from Goldman Sachs, the International Monetary Fund (IMF), or the World Economic Forum (WEF), are asking what share of existing job tasks AI could theoretically perform in the future, “Anthropic is measuring qualitative experiences of workers in the present,” he pointed out. This “tells us how people are navigating this landscape in real time.”

The paradox of AI in the workforce

Anthropic’s survey of 81,000 Claude users gauged peoples’ “visions and fears” around advances in AI, and weighed these findings against the company’s own measurement of jobs most vulnerable to AI displacement. This was based on Claude usage data; jobs are identified as more exposed when associated tasks are significantly performed on the platform, in work-related contexts, and take up a larger share of a role.

Some occupations at risk include computer programmers, data entry keyers, market researchers, software quality assurance analysts and testers, information security analysts, and computer user support specialists.

Overall, one-fifth of respondents expressed concern about displacement, noting that their job, or at least aspects of it, is being taken over by automation. Those in jobs identified as most exposed readily recognized that fact, voicing worry three times as often as those in less at-risk positions. One software engineer remarked: “like anyone who has a white collar job these days, I’m 100% concerned, pretty much 24/7 concerned, about losing my job eventually to AI.”

Early-career respondents were also more nervous than others.

At the same time, those in the highest-paid occupations reported the largest productivity gains when using AI. This is most notably in terms of their ability to perform new tasks, which was cited by 48% of users. In addition, 40% of workers said the technology helped speed up their work, and a little more than 10% said it improved the quality of their work.

In general, enterprise usage of AI is “actually quite consistent,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. Teams are using the technology “where information is abundant and time is limited,” such as in drafting documents and code, summarizing content, responding to customer queries, navigating internal systems.

Is AI actually creating more work?

Still, not everyone thinks AI makes their jobs easier or faster. In some cases, people felt it made their work harder; for instance, project managers are assigning tickets for issues that are much more difficult to solve, Anthropic noted.

Gogia agreed that, even when tasks become easier, scope and responsibilities expand, and roles can absorb adjacent tasks. This results in a “redistribution of effort,” rather than a reduction of effort.

“Faster generation means higher expectations on quality,” he said. More output feeds into decision pipelines that are already constrained. “In some cases, the system becomes heavier, not lighter.”

Delayed impact on enterprises

 The market is rewarding those who can integrate AI into complex workflows to do more, faster, and often with better outcomes, Gogia noted. However, the most exposed tasks, including  documentation, basic coding, routine analysis, and structured support work, often “sit at the base of the experience ladder.”

These very tasks traditionally have given entry-level workers a way in, and the automation of them reduces the urgency for companies to hire them. “What you begin to lose is not the job,” said Gogia. “It is the path into the job.”

This can have a delayed impact; enterprises may not realize until years later that they do not have enough mid-level experts because they didn’t bring enough people in at lower levels. As AI plays a greater role in the workplace, there must be a “conscious effort” to rethink how people enter and grow, Gogia said. “New pathways need to be created, and they need to be deliberate.”

How enterprise leaders should adjust

As is often the case, sentiment moves faster than structural change, Gogia pointed out. Workers feel the shift almost immediately, but organizations take longer to adjust hiring, redesign roles, and rethink workforce structures.

“This is why expectations can become misaligned,” he noted. The reality is that most enterprises have introduced AI into existing ways of working without fundamentally changing them. Acceleration occurs in unchanged systems that still carry the same dependencies, approval chains, and coordination challenges.

Ultimately, Gogia advised, leaders must approach the shift with “intentional design.” This requires clarity, he emphasized; people need to understand how their work is expected to change. What will be enhanced? What will reduce? Where should they focus their development?

Baselines are moving: Roles may begin to look “oversized” as what used to be considered a full day’s work begins to look like half a day’s work, or what used to be considered efficient begins to look average. “AI is changing how work is done, but more importantly, it is changing what work expects from people,” said Gogia.

As well, Info-Tech’s Randall pointed out that workers who experience AI expanding what they can do by performing tasks previously outside their competence appear to relate to AI more positively than those who experience it as doing their existing job faster. So, he advised, “tech leaders should design AI deployment around capability extensions.”

Along with goal setting, managers must have support, Gogia emphasized. They set expectations and interpret strategy, and when they’re not properly equipped, “even the best tools will fall short,” he said. Measurement must also evolve; enterprises need to look at quality, sustainability, and capability development over time.

“What we are witnessing right now is not a sudden disruption,” said Gogia. “It is a gradual shift that is becoming impossible to ignore.”

This article originally appeared on Computerworld.

Cisco today unveiled a prototype switch it says will significantly accelerate the timeline for practical, distributed, quantum-computing-based networks.

Cisco’s Universal Quantum Switch is designed to connect quantum systems from different vendors, such as IBM, IonQ, Google and Rigetti, in all major qubit encoding technologies, at room temperature, and over standard telecom fiber, according to Vijoy Pandey, senior vice president and general manager of Outshift, Cisco’s emerging technologies and incubation group.

“Today we have quantum computers operating at roughly 100 to 1,000 qubits in size, and from the public roadmaps of leading quantum players, we believe this number [is] going up to 10,000 in the next three years,” Pandey said. “Actual quantum computers will get bigger over time, of course, but it creates a big scalability problem once you start connecting them. What the switch will do is effectively link smaller quantum computers and create a large, distributed quantum computer, allowing faster scaling than building one massive quantum computer alone.”

“This is a foundational piece of technology that lets us move from direct point-to-point connections, the tin cans and a wire, to building out a quantum network, to building out the quantum Internet at scale, to be able to connect those quantum computers at scale within the data center, but also to be able to connect quantum sensors across the Internet at scale as well,” Pandey said.

The Cisco Universal Quantum Switch works in many of the ways that current multivendor switches work to form the backbone of the internet in that it allows connectivity no matter what the underlaying protocols and equipment are, Pandey said. When two quantum computers need to share information, the Universal Quantum Switch accepts the signal in whatever modality it arrives, translates it into a common language for routing, and delivers it in the format the receiving system needs, without losing any quantum information along the way, Pandey said. 

The switch preserved quantum information with less than 4% degradation in encoding and entanglement fidelity in proof-of-concept experiments, Pandey said.

This is made possible by a Cisco-patented conversion engine, where output modality can match the input or be an entirely different one, letting the quantum switch connect and translate between quantum systems that were never designed to talk to each other. It’s a critical capability for building quantum networks that work across different vendors and technologies, according to Cisco.

“The switch is non-blocking, allowing multiple photons to flow through the chip at the same time, each independently routed while preserving its quantum state, enabling flexible scalable quantum networking,” Pandey said.

The major quantum encoding modalities which are used to carry quantum information include:

• Polarization (the orientation of light waves)
• Time-bin (the timing of light pulses)
• Frequency-bin (the color or frequency of light)
• Path (the physical or spatial path)

To date, the quantum switch has been experimentally validated with polarization encoding. Support for time-bin and frequency-bin is built into the switch design and will be the next step in Cisco’s ongoing validation process, Pandey said.

The switch can also be used to tie together and process data from quantum-sensing devices which are or will be used in applications from healthcare and navigation to energy and infrastructure.

The Cisco Universal Quantum Switch is just the latest component in the vendor’s quantum arsenal which is aimed at offering a full stack of data center-oriented quantum technologies. 

In September the vendor rolled out a package of prototype software it says will facilitate distributed quantum computing networks and support real-time applications. The software stack includes three layers: an application layer with a network-aware distributed quantum computing compiler that supports quantum algorithm execution in a networked quantum data center; a control layer with quantum networking protocols and algorithms that support the applications as well as manage the devices (hardware and software) that make up a quantum network through northbound and southbound APIs; and a third layer for device support, consisting of an SDK and APIs to physical devices as well as a library of emulated and simulated ones.

The Universal Switch is based on the quantum entanglement chip announced by Outshift last May that generates pairs of entangled photons that can instantly transmit quantum state between each other, regardless of the distance between them. The entanglement chip generates 200 million entangled pairs per second. The chip operates at room temperature, uses minimal power, and functions using existing telecom frequencies. It’s designed to work with existing infrastructure, meaning it can send photons over existing fiber. And it operates at standard telecom frequencies, so there’s no need to rip and replace anything to support it, according to Cisco. In addition, because of these properties, customers could deploy gear supporting the chip alongside an existing classical computer infrastructure, Cisco said.

“The quantum future won’t be built by any one company or any one technology. It will be built by connecting them all with this technology,” Pandey said.

Consumer engagement has been fundamentally changing with the advent of AI agents, forcing a rethink by software-as-a-service (SaaS) companies, and creativity platform provider Adobe is responding by shifting its approach to what it calls ‘Customer Experience Orchestration (CXO).’

Announced today at Adobe Summit, the new Adobe CX Enterprise suite is a pivot to a future defined by agents rather than by software alone, where SaaS companies claim an advantage based on their deep domain expertise and troves of first and third-party data.

The platform brings together customizable and out-of-the-box AI agents, Model Context Protocol (MCP) endpoints, and new intelligence systems built on Adobe’s orchestration engine.

“SaaS is changing, and we are re-architecting so that we can participate in the reimagination, the redefinition of SaaS,” said Adobe VP Sundeep Parsa.

Agents executing with guidance from a ‘coach’

Adobe CX Enterprise builds on the company’s Adobe Experience Platform (AEP) Agent Orchestrator, which brought AI agents directly into Adobe apps. Released in 2025, AEP now  powers more 1 trillion experiences annually, according to the company.

AEP remains the “anchor” for Adobe CX Enterprise, which now gives customers the ability to create agent skills (reusable instructions), as well as providing specialized and customizable agents. These can be incorporated into any AI tech stack, including Anthropic’s Claude, OpenAI’s ChatGPT, Google’s Gemini, Microsoft Copilot, Nvidia’s NemoClaw, and others. Developers also have access to Model Context Protocol (MCP) servers and other infrastructure required to build customized use cases.

“We’re going to make sure our applications are not trapped inside our UI layer, that they become composable services available through MCP tool calls or the A2A layer,” Parsa explained. “Customers can tap into what they have and bring that into their own unique processes, be their own UI.”

He emphasized the importance of customer choice. Many enterprises are still grappling with the ‘build or buy’ question; some will prefer to create their own bespoke user interface (UI) layer, while others will have no interest in doing so.

With CX Enterprise, enterprises can use pre-loaded agent skills to build custom workflows, or can launch agents pre-built for specific tasks like workflow optimization (coordinating tasks or automating handoffs) and brand governance (enforcing policies, managing permissions, tracking asset rights). And, a new Adobe CX Enterprise Coworker, to be available in the coming months, will act on specified goals and orchestrate other agents to perform multi-step actions.

For instance, if a marketing team is looking to increase loyalty subscriptions by 3% in the next quarter, the CX Enterprise Coworker will work with other agents to identify relevant audience segments, surface performance insights, create a plan, and develop email copy or visual assets, Parsa noted. Once all this is approved by a human, the Coworker will then help execute the campaign and monitor results.

Whereas previously agents would build an audience, then “go to sleep,” Adobe’s new CX Enterprise Coworker is “always on,” has persistent memory, and can run workflows across weeks, or even full financial quarters if required, Parsa explained. He likened the CX Enterprise Coworker to an American football quarterback, the player who directs the activities on the field, guided by a coach on the sidelines. Coworker’s coach is a marketer or a brand specialist.

“We’re doubling down on this framing of customer experience orchestration,” Parsa says.

Moving to one-on-one personalization

Along with these agentic tools, Adobe is introducing two new intelligence systems: Adobe Brand Intelligence and Adobe Engagement Intelligence.

Brand Intelligence is built on a fine-tuned large language model (LLM) with vision-language capabilities that learns from “qualitative and nuanced inputs” like annotations, feedback cycles, or rejected assets.

“Brand intelligence is going after a much harder problem than ‘a brand kit,’ which is a codification of a CSS style guide,” Parsa explained. The LLM can begin to understand brand sentiment, informed by “data engagement signals and the actual enterprise assets.”

Adobe Engagement Intelligence helps teams decide next best offers, messages, or other actions for targeted customers. This is based on their lifetime interactions, rather than click-throughs or conversions, according to Parsa.

Whereas previously, less was more, “in this world, more is better,” he said, pointing out that the promise of generative AI is producing more material economically. “It’s not creating more for more’s sake, it’s targeted campaigns that get you much closer to one-on-one personalization.”

Early production gains are “massive,” Parsa claimed. This is because troubleshooting and early detection of problems now takes “hours, not days and weeks.”

SaaS companies’ data advantage

Like many SaaS companies grappling with an agent-driven future where pay-per-seat models are becoming less relevant, Adobe is emphasizing its data advantage. Parsa pointed out that more than 20,000 enterprises have built on Adobe’s platform over the years, giving the company enormous amounts of data alongside domain expertise.

Generative AI and AI agents do a good job of understanding the “corpus of world knowledge” and building some “useful capabilities for all of us,” Parsa acknowledged. “But these technologies stop at the enterprise walls, because those are ‘walled gardens.’”

Further, enterprise context is very complicated and spread across numerous applications, he noted. “It’s codified in documents; in some cases just tribal knowledge informs how people function on a day to day basis.” AI agents working on their own (like OpenClaw or Claude Cowork) break in the enterprise because they are “brittle” and not grounded in enterprise data, he said.

“We are a proxy for all of the enterprise context that lives inside our applications,” said Parsa. “We’re going to bring that into the AI layer much faster than a customer restarting that whole process with an AI platform.”

Ultimately, he said, Adobe is “adapting and adjusting” to customer feedback and consumer interaction with brands, as well as with the internet itself, as customer engagement undergoes a dramatic shift in the era of AI. As this unfolds, Parsa emphasized the importance of “open, open, open.”

“We absolutely are going to work with tech partners, we’re going to work with other SaaS companies to make sure that we stay flexible and meet the customer where they are,” he said.

I’ve been arguing for a while now that enterprise AI won’t really take off until it gets boring. Not boring in the sense of uninspired; no, I mean boring in the sense that enterprises can trust it, govern it, observe it, and hand it to rank-and-file employees without undue concern that things will go wrong.

We have no shortage of over-funded startups clamoring to be the next big thing in AI, but not nearly enough that are quietly doing the essential work to make AI safe for enterprise consumption. Enter Stacklok.

On the surface, this might look like yet another startup trying to surf the AI agent wave. It’s not. Stacklok is exciting precisely because its executive team is deeply experienced in being unexciting. Back at Google, Craig McLuckie and Joe Beda were instrumental in the creation of Kubernetes. They took the messy, chaotic world of container orchestration and built an abstraction layer that made it “boring” enough that the largest banks, telcos, and retailers in the world could rely on it with confidence. Now they’re bringing that ability to wring order out of chaos to agentic AI, and they recognize that the real problem in enterprise AI has more to do with operational accountability than model quality.

I interviewed McLuckie and Beda to better understand the opportunity to create a “Kubernetes moment” in agentic AI.

Targeting accountability

McLuckie founded Stacklok in early 2023. Beda, his Kubernetes and later Heptio counterpart, had “semi-retired” in 2022. Beda doesn’t need to make more money, and he’s not joining out of nostalgia. As he tells it, this is “an extraordinary moment in the industry,” with “an opportunity to bring deep expertise in developer platforms and enterprise-grade infrastructure” to solving key enterprise problems.

“The biggest problem,” McLuckie says, “is accountability.” He explains: “An agent, no matter how sophisticated, no matter how capable, no matter how useful, cannot be held accountable for the work it undertakes.” That’s exactly right. A large language model can write code, summarize a contract, file a ticket, or trigger a workflow, but if it mangles customer data, oversteps its permissions, or keeps running after the employee who launched it has left the company, nobody gets to shrug and blame the model. The enterprise still owns the outcome.

Even OpenAI, which has been slower to take the enterprise seriously than Anthropic, now recognizes that enterprises need AI to fit inside workflows, controls, deployment models, and day-to-day operations. It’s no longer just about raw model prowess, as Tom Krazit writes. In other words, the market is slowly rediscovering what infrastructure people have known for a long time: Enterprises may buy capability, but they deploy control.

A related issue, according to Beda, is that AI’s speed changes everything. Tasks that used to take a human days or weeks may soon be completed in minutes by an agent. That doesn’t just create productivity. It creates scale, and scale turns manageable sloppiness into operational disaster. As he puts it, “The volume dial is going to 11 across the board.” I recently said that humans don’t use most of their granted permissions, but agents will. That’s exactly why identity, authorization, and auditability suddenly stop being problems for the security team and become architecture.

This is where the Kubernetes analogy is actually useful, rather than just founder mythmaking.

AI’s Kubernetes moment

Too many people remember Kubernetes as a container story. Enterprises embraced it for a more practical reason: It gave them a common operating model across environments, plus an ecosystem of policy, security, observability, and workflow tools layered on top. Cloud Native Computing Foundation now says 82% of container users run Kubernetes in production, and the organization explicitly frames Kubernetes as the operating system for AI. In our interview, McLuckie describes Kubernetes’ deeper contribution as “self-determination.” That is, it gave enterprises a consistent substrate on premises, at the edge, and in the cloud. That consistency is what helped an ecosystem to flourish around it.

Beda goes one step further: “One of the core ideas in Kubernetes is that you describe what you want to happen, and then you have the system go make it happen.” This, he says, means that Kubernetes is essentially “control theory rendered into software. Over time, an enterprise’s desired state moves into code, into version control, and into systems traceable back to accountable humans. Nerdy and sort of dull? Sure. But that’s the point. Enterprise AI doesn’t just need smarter models. It needs systems where humans declare intent, machines execute it, and the whole mess remains observable and auditable.

This is why I keep insisting that the biggest strategic question in agentic AI isn’t whether agents are cool. They are—or at least they can be. No, the real question is who owns the control plane. Stacklok matters because it is explicitly aiming at that layer. The company’s bet is that enterprises want to run and manage Model Context Protocol–based agent infrastructure on the Kubernetes they already know. They want policy, identity, isolation, and observability built in, not bolted on afterwards.

That last part matters because MCP is important, but it isn’t enough. Anthropic introduced MCP in November 2024 as an open standard for connecting AI systems to tools and data. Later, they donated it to the Linux Foundation’s Agentic AI Foundation to keep it neutral and community-driven. It worked. Anthropic reports there are now more than 10,000 active public MCP servers and support across ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code.

That’s awesome, but it’s also not enough. Why? Because a protocol isn’t a platform. A protocol can help an agent talk to a tool, but it doesn’t, by itself, tell an enterprise who approved that agent, what data it can touch, how its actions are logged, or how to shut it down safely when the human who launched it has left the company.

Meeting users where they are

That’s where Stacklok’s self-hosted, Kubernetes-native bias starts to look smart rather than stodgy. (Though, again, “stodgy” isn’t a bad thing for risk-averse enterprises.) McLuckie is blunt: “If you’re an enterprise connecting agents to sensitive data, you are almost certainly not comfortable with that data egressing your security domain or being sent to a SaaS endpoint that a vendor controls.” We’ve seen this movie before. When your hosting, identity, tool integration, and policy layers all belong to the same vendor, “choice” starts to mean “replatform.”

No one wants that.

This is also where open source matters, though not in the simplistic sense that open source automatically wins. It doesn’t. Enterprises don’t buy ideology: they buy simplicity. But in a young market, they also value leverage. I’ve written before that open source doesn’t magically redistribute market power. What it can do is give customers options and some control over their fate. In AI, where model switching costs are still relatively low, that optionality matters. Talking with McLuckie and Beda, it’s clear they are open source true believers, but not obnoxiously so. That’s good, because enterprises don’t need a sermon on openness; they just need enough neutrality to avoid getting trapped while the market is still changing underneath them.

It’s all about meeting enterprises where they are and helping them to incrementally move to where they’d like to be. As McLuckie stresses, most enterprise AI teams are being asked to deliver more with AI while running with flat or capped headcount. They don’t need and can’t implement a grand theory of some idealized, fully autonomous enterprise. Instead, they need an accretive (golden) path from here to there using things they already understand, such as containers, isolation, OpenTelemetry, Kubernetes, existing identity systems, and existing observability stacks.

Sound boring? Good!

The opposite of “boring” in enterprise AI isn’t innovation. It’s slideware or demoware that looks great in a keynote but dies on contact with procurement, security review, compliance, and the first ugly bit of enterprise data. McLuckie captures this perfectly: “Vibe-coding a platform for two weeks can produce something plausible. It won’t produce something accurate, hardened, or enterprise-grade.”

Will Stacklok be the company that defines this layer? It’s way too early to say. Markets this young are littered with smart people who were directionally right and commercially wrong. But the company is aiming at the right problem, and that already puts it ahead of a depressingly large percentage of the AI industry.

Again, the next era of enterprise AI will be won by whoever makes agents governable, portable, observable, and boring enough to trust. Kubernetes helped do that for cloud-native infrastructure. Stacklok is betting the same playbook can work for agentic infrastructure. That’s not a nostalgic rerun of Kubernetes. It’s a recognition that enterprises still need what they’ve always needed: not more magic, but a way to control it.

In an era of constant technological change, agility is more than a buzzword; it is the single most critical characteristic of a high-performing IT department. While C-suite leaders look to technology for a competitive edge, many CIOs find themselves wrestling with a fundamental challenge: Innovation is only as strong as a team’s ability to adapt. The most ambitious transformation roadmaps, from AI adoption to cloud migration, will inevitably stall if the workforce’s skills have not kept pace with the technology. This places a new mandate on the CIO, one focused less on managing technology and more on cultivating a culture of continuous learning.

CIOs need to think and act like chief learning officers, treating skill development as a core strategic function rather than solely an HR responsibility.

The urgency of this shift is clear in the data. The World Economic Forum’s Future of Jobs Report continues to list digital skills, cloud know-how and AI literacy among the fastest-growing capabilities. Meanwhile, research from CompTIA shows that nearly three-quarters of CIOs see skills alignment as the top barrier to realizing the value of their technology investments. This creates a dangerous gap between ambition and execution.

In its 2026 Global CEO Survey, PwC found that CEOs’ top concern is whether they are “transforming fast enough to keep up with technology, including AI”. Yet other PwC research on workforce hopes and fears reveals that only a small fraction of workers use generative AI daily. The pace of innovation is dramatically outstripping workforce readiness, creating an urgent mandate for CIOs to become agents of change.

From my perspective, AI upskilling must be treated as a strategic operating system for the entire IT department. Competitive advantage comes from a deep, holistic understanding of where AI fits, what business problems it solves and how humans and systems can work together effectively. It cannot be an afterthought or a hopeful assumption.

You can’t steer without knowing your starting point

To build an effective upskilling program, you must first understand your current capabilities. I advise CIOs to begin by mapping their existing IT, data and AI skills landscape to identify strengths and, more importantly, to expose blind spots or gaps before they become business risks. This requires a structured skills-mapping process that inventories both core technical skills and adaptive work behaviors. The former includes essentials like cloud fluency, modern software engineering, cybersecurity and data science literacy. The latter is about nurturing the human element and the skills that enable teams to thrive amidst change.

Using established competency frameworks, such as the NIST NICE Framework for cybersecurity roles, can provide a standardized language and structure to this process. These frameworks help create consistent job descriptions and clear learning pathways. This assessment should go beyond just listing skills. CIOs should understand how teams actually apply those capabilities in real delivery environments. Regular reassessment, ideally semi-annual, ensures your skills map stays current as technology evolves and business priorities shift, preventing your upskilling program from becoming misaligned.

Build a continuous learning system, not just a training program

The most effective CIOs I know treat learning like a living program, one designed to evolve as technology, roles and business priorities change. This means moving beyond sporadic, one-time training initiatives to build an ongoing capability-building system. Key elements include role-based, modular learning paths. For a cloud engineer, this might mean a path focused on advanced container orchestration and AI-powered observability tools. For a project manager, the path might focus on agile methodologies for running AI projects and data-driven reporting.

It is also critical to create safe environments for experimentation, such as internal sandboxes or pilot programs, where teams can apply new AI skills without operational risk. This fosters a culture where failure is seen as a valuable learning opportunity, not a mistake to be hidden. Furthermore, encouraging peer-led learning through internal workshops, hackathons and formal mentorship programs can accelerate skill transfer and break down the silos that so often hinder progress.

This is crucial because adoption alone does not guarantee success. For instance, new research from the Project Management Institute demonstrates this very point. In our Gen AI and Agility report, we surveyed 2,000 project professionals who use both agile practices and GenAI. We found that while adoption is growing rapidly, the actual value they realize varies widely depending on how the technology is applied and whether agile values are genuinely practiced. Simply giving teams new tools is not enough.

Governance also plays a critical role here, ensuring that learning investments stay connected to business outcomes. In practice, this could mean a small, cross-functional council that meets quarterly to review learning metrics, assess alignment with new business goals and make decisions on retiring old training modules and commissioning new ones. This keeps the program dynamic and prevents it from becoming obsolete.

Embedding this practice into your IT culture is what makes it stick. CIOs can use several tactics to weave continuous learning into the fabric of their departments. Link skill updates to project retrospectives. Tie career progressions and compensation to skills mastery in core areas like AI literacy and data integrity. I’m also a huge advocate for holding “innovation days” where teams can explore new AI tools and features, building confidence with the very technologies the organization is already investing in. Without this focus on adoption, even the best technology is wasted. A 2025 report on digital adoption from WalkMe found that enterprises wasted millions on underused tech last year alone because adoption was an afterthought.

Avoid the common detours on your upskilling roadmap

As you travel this path, be mindful of common pitfalls that can easily derail your efforts. One of the most frequent pitfalls I see is chasing a single trend, like GenAI, at the expense of foundational IT skills. I’ve seen organizations invest heavily in a single large language model API for all employees while their core network infrastructure remains outdated and vulnerable, creating a lopsided and fragile capability. Another pitfall is treating training and upskilling as a “one-and-done” event. Without continuous reinforcement and opportunities for real-world application, the natural “forgetting curve” takes over and knowledge quickly fades. Finally, a failure to apply governance leads to a “wild west” scenario. This results in one department becoming highly proficient in a specific AI tool that is incompatible with the rest of the enterprise, creating new, more complex silos instead of breaking them down. Upskilling for the AI era demands balance; you must build depth in core disciplines alongside adaptability for new technologies.

This AI era requires CIOs to be cultivators of talent, not just managers of technology. Our role is to model and encourage adaptability, continuous learning and disciplined experimentation across our entire IT workforce. To be truly agile, our teams must be empowered with the skills and the confidence to match their ambition. The time has come to move from a model of reactive training to one of intentional, strategic capability-building that becomes part of your organization’s very DNA. By leading this journey, you can ensure your teams and your organization are ready to meet the future with confidence.

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

Enterprise AI agents are supposed to streamline workflows. Instead, two fresh findings show they can just as easily streamline data exfiltration.

Security researchers have uncovered prompt-injection vulnerabilities in both Microsoft Copilot Studio and Salesforce Agentforce that allow attackers to execute malicious instructions via seemingly harmless prompts.

According to Capsule Security findings, SharePoint forms and public-facing lead forms within Copilot are vulnerable to attackers issuing prompts that can override system intent and trigger data exfiltration to attacker-controlled servers.

One of these flaws has already been assigned a high-severity CVE, with another “critical” one reportedly missing the bar for categorization. The flaws can allow theft of PIIs, customer/lead records, free-text business context, and operational/workflow data.

In both cases, AI agents treat untrusted user input as trusted instructions, Capsule researchers noted in the disclosures shared with CSO ahead of their publication on Wednesday.

ShareLeak: SharePoint forms data leaked through Copilot

The Microsoft-side issue, dubbed “ShareLeak,” is about how Copilot Studio agents process SharePoint form submissions. The attack begins with a crafted payload inserted into a standard form field, like “comments”, which the agent later ingests as part of its operational context.

Because the system concatenates user input with system prompts, the injected payload overrides the agent’s original instructions. The model is thus tricked into believing the attacker’s instructions are legitimate system directives. The malicious input moves from form submission to agent execution without any resistance.

Once compromised, the agent can access connected SharePoint Lists and extract sensitive customer data, including names, addresses, phone numbers, and send it externally via email. The researchers found that even when Microsoft’s safety mechanisms flagged suspicious behavior, the data was exfiltrated.

The root cause is that there is no reliable separation between trusted system instructions and untrusted user data. In the existing setup, the AI cannot distinguish between the two, the researchers said.

Microsoft patched the issue following disclosure, assigning CVE-2026-21520 to it and assessing its severity at 7.5 out of 10 on the CVSS scale. The mitigation was carried out internally, and no further action is required from the users.

PipeLeak: Salesforce Agentforce hijacked by a simple lead

In the Salesforce Agentforce case, attackers embed malicious instructions inside a public-facing lead form. When an internal user later asks the agent to review or process that lead, the agent executes the embedded instructions as if they were part of its task.

According to a Capsule demonstration, the agent retrieves CRM data via the “GetLeadsInformation” function and then sends it externally via email.

The compromise isn’t limited to a single record. Researchers demonstrated that a hijacked agent could query and exfiltrate multiple lead records in bulk, effectively turning a single form submission into a database extraction pipeline.

The researchers said Salesforce acknowledged the prompt injection issue but characterized the exfiltration vector as “configuration-specific,” pointing to optional human-in-the-loop (HITL) controls. Capsule’s pushback on that framing argues that requiring manual approvals undermines the very purpose of autonomous agents.

The deeper issue, they noted, is insecure defaults. Systems designed for automation should not allow untrusted inputs to redefine agent goals.

Both disclosures converge on a baseline that calls for treating all external inputs as untrusted and having filters in place that separate data from instructions. This would entail enforcing input validation, least-privilege access, and strict controls on actions like outbound email.

In my nearly two decades as an identity practitioner — including leading identity programs at global financial institutions and serving as a CISO — I’ve seen a recurring pattern that quietly erodes enterprise velocity. I call it “Monday morning friction.”

The symptoms often look mundane, but they are systemically expensive:

• The project stall: A cloud migration pauses while an engineer waits days for approval on a single resource.
• The executive “dark” period: A newly hired leader spends their first week unable to access the very dashboards they were hired to oversee.
• The security workaround: A developer uses a shared credential because the formal request process is too slow for the current sprint.

In large enterprises, these moments are often dismissed as routine IT friction. In practice, they are signals of manual access governance quietly slowing the pace of the business.

When I sat in the CISO chair, the pressure was binary: Keep the organization secure without becoming the “Office of No.” What has become increasingly clear in boardroom conversations is that manual access governance is no longer just a security concern. It has evolved into a persistent source of operational friction that slows the very transformation CIOs are tasked with accelerating.

The productivity tax of the “I don’t know” loop

The most significant hidden cost in governance isn’t software — it is lost time.

Research from Lakeside Software’s 2024 IT Leaders Report shows that employees lose nearly an hour each week to IT-related friction, with access delays and technical hurdles among the primary contributors. In a 10,000-employee enterprise, that translates into hundreds of thousands of productive hours annually spent waiting, escalating or troubleshooting.

This creates what I’ve seen repeatedly: The “copy-paste” model of onboarding. A new employee is told to replicate the access of someone else in a similar role. Over time, those inherited permissions accumulate. What begins as expedience becomes structural privilege creep.

The SaaS paradox: Modern tools, manual workflows

Most enterprises no longer rely on spreadsheets for governance. They use sophisticated identity governance and administration (IGA) platforms. Yet the presence of modern interfaces has not eliminated manual intervention.

Today’s “manual trap” is less visible. It’s the human-in-the-loop model that requires managers to interpret cryptic entitlements and click “approve” on decisions they may not fully understand.

Even in organizations with advanced identity tooling, automation frequently stops halfway. HR systems, identity directories, provisioning engines and application logs may each function well in isolation — but the human often becomes the integration layer between them. That integration work carries a cost. Every escalation pulls focus from higher-value work and pulls the CIO further away from digital acceleration goals.

Governance as a spend signal

Increasingly, CIOs are asking a broader question: Can identity governance help manage SaaS sprawl?

Identity data holds a powerful, underused signal. Authentication frequency and inactivity patterns reveal where access no longer aligns with usage. When viewed through an operational lens, identity governance becomes a shadow IT discovery tool.

For CIOs managing margin pressure and platform rationalization, this reframes identity from a cost center to a potential efficiency lever. If an identity platform can flag that a significant portion of a SaaS tier is unused because the governance signal shows zero logins in 90 days, it moves from a security checkbox to a procurement asset.

Approval fatigue and governance debt

Manual governance often creates the illusion of control. A manager clicking “approve” feels like oversight. In practice, high-volume approval queues create approval fatigue.

When access requests arrive described in dense shorthand — such as FIN-PRD-DB-USR-RW — most managers lack the time or context to dissect each entitlement. Over time, approvals become reflexive. This is where governance debt accumulates.

Like technical debt, governance debt is the byproduct of incremental shortcuts. The interest on that debt is paid not only in risk, but in downtime, rework and fragmented visibility.

The scaling problem: AI and machine identities

Manual governance models were designed for a workforce of humans. That denominator is changing. In cloud-forward environments, non-human identities — such as service accounts, bots and AI agents — already outnumber human users. These identities are created and modified at the speed of code.

A governance model that depends on manual review does not scale for AI. As CIOs invest in automated workflows and autonomous agents, identity governance increasingly needs to transition from a human-centric process to a higher-velocity automated control plane.

Identity as an operational control system

The friction surrounding access governance is often framed as a security trade-off: Safety versus speed. In practice, the issue is fragmentation.

When identity operates in isolation, organizations rely on people to bridge the gaps. Human coordination becomes the control plane. That is expensive, slow and prone to error.

Viewed through this lens, identity governance is an operational control system that influences onboarding speed, engineering throughput and workforce productivity. CIOs who recognize its role in shaping workflow velocity and cost transparency gain a competitive edge. Governance does not have to function as an emergency brake; it can become part of the engine.

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

A strong application portfolio is an essential IT resource. Ensuring that the portfolio is ready to meet enterprise operational and financial needs is essential to long-term business success. Unfortunately, applications tend to accumulate over time, leading to bloat that creates confusion, undermines efficiency, and introduces risk to the organization.

Application rationalization streamlines an existing application portfolio to improve efficiency, reduce complexity, make room for innovation, and lower the total cost of ownership (TCO) through a specific set of processes.

Application rationalization is a daunting task for any CIO. Here are seven tips that can make the process faster and easier.

Be methodical and make use of metadata

“Application management is periodically necessary to reduce duplicate systems and services while adhering to your organization’s architectural standards,” says William Fortwangler, chief information and digital office program instructor at Carnegie Mellon University.

“Hopefully, you have a great application or service catalog containing meta data describing all facets of your service,” Fortwangler says. For each service you need to know when your contract is up, its cost, where it runs, and whether you can restructure its term, he advises. “About 50 to100 metadata points should be housed within your application catalog describing your system so that decisions can be made on its future.”

The best way to handle application rationalization is by approaching the task in small steps, says Cristian-Ovidiu Marin, CEO at OnlineGames.com. “Pick one department, inventory everything, and clean it up,” he advises. “That experience teaches more than any enterprise-wide framework, because every organization has different dependencies.” Marin adds that some business stakeholders may not agree with your rationalization approach, so it’s important to communicate and justify why it’s necessary.

Marin acknowledges that application rationalization is unglamorous work. “But it’s one of the highest-impact moves a CIO can make.”

Recruit business analysis support

“You can’t just talk about application rationalization, you’ve got to roll up your sleeves and seek help,” advises Todd Kimpton, managing partner at managed IT services provider Etter+Ramli.

Kimpton believes the best way to achieve successful application rationalization is to ask your organization’s business analyst team to thoroughly assess all existing tools. “They need to identify overlaps, understand the true capabilities of each system, and most critically, explore alternative market options,” he says. “Sometimes, the most pragmatic solution requires consolidation by removing a handful of underperforming applications and replacing them with a more robust business-ready tool. It’s about ruthless efficiency,” Kimpton states.

Application rationalization isn’t just about cutting fat, Kimpton observes. “It’s about building a leaner, more resilient, and AI-ready platform that serves the business strategically, not just functionally,” he says. “It’s ensuring that every dollar spent on software truly supports the business’s growth and future innovation, rather than just keeping the lights on.”

Prioritize based on use data and strategic vectors

Begin by collecting information on your current inventory and usage, recommends Bob Gourley, CTO at cybersecurity consulting firm OODA. “For every program, map the business capability it enables, who uses it, and the worth it provides,” he says.

Gourley advises prioritizing inventory according to price, risk, overlap, and strategic significance. “All of these attributes should be evidence-based on true use data and enterprise requirements,” he says. “You’ll prevent shocks and foster buy-in for application retirements or replacements when you also include the software-dependent people.”

Application rationalization isn’t just a simple matter of cutting costs, Gourley says. “It’s also a means of improving manageability, enhancing security, and providing the ability to deliver on technology investments,” he states. “When executed, it can also unlock budgets for innovation.”

Analyze the underlying data infrastructure as well

While CIOs must inventory applications, they should also examine the data infrastructure that supports them, says Bakul Banthia, co-founder of database-as-a-service platform provider Tessell. “Each application should be evaluated on the basis of business criticality, cost, risk, performance, and modernization potential,” he advises.

“Too often, rationalization stops at the application layer,” he warns. “The real leverage comes when CIOs evaluate the data platforms underneath those applications, because that’s where much of the cost and operational burden lives.”

Banthia says that a data-focused approach effectively aligns IT decisions with business outcomes rather than on isolated technology metrics. “When application rationalization is tied to cost transparency, resilience, security, and scalability, CIOs can make informed decisions about whether to retire, consolidate, modernize, or replatform systems,” he states. “By addressing data infrastructure alongside applications, you avoid simply shifting complexity from one place to another and, instead, achieve sustainable simplification.”

Establish governance guidelines and a regular rationalization cadence

When tackling rationalization, set simple categories — such as Keep, Invest, Tolerate, Replace, and Retire — then enforce governance so exceptions don’t quietly re-create sprawl, says Ken Herron, co-founder of revenue intelligence firm vConversational.

Herron notes that a big mistake is treating rationalization as a one-time cleanup project, driven by procurement, without changing how new apps get approved and integrated. A light quarterly review, plus a deeper annual cycle tied to planning and budgeting works well, although high-change areas may need monthly checks, he advises.

Align with project management and budgeting cycles

Learning to rationalize requires a combination of data analysis, user feedback, and continuous IT infrastructure monitoring, says Pavlo Tkhir, CTO at software development company Euristiq.

Tkhir says that a practice that has yielded noticeable positive results for his organization is integrating the rationalization process into IT project management and budgeting cycles. “Every six to twelve months, we review the application portfolio to identify duplicate functionality, legacy solutions, and opportunities for automation,” he says.

Tkhir recommends aiming for small, measurable results while gradually expanding coverage. “Ultimately, application rationalization not only saves resources, but also creates a flexible IT environment ready for scaling and the adoption of promising new technologies.”

Tkhir says a common mistake CIOs make is treating rationalization as a one-time initiative with no need for regular updates. “As a result, the list of legacy or ineffective applications grows again and efficiency declines.”

Enlist stakeholders and include qualitative input

Start by compiling a complete inventory, assessing each application’s business and technical value, and comparing each product against consistent criteria, suggests technology business advisor Chris M. Walker. Calculate the total cost of ownership and score each application from there. “Then decide whether to retire, consolidate, modernize, or keep the application,” he says. “Transparency and stakeholder involvement are also critical to success.”

Long-term effectiveness comes from combining quantitative metrics with qualitative input, Walker says. “Additionally, CIOs who involve business leaders will avoid blind spots and gain buy‑in,” he notes. “Scoring systems provides clarity, while stakeholder engagement ensures decisions are strategic rather than purely technical.”

The best way to achieve truly effective rationalization is by examining case studies and pilot projects, Walker advises. Then start small with one department or portfolio, apply a structured framework, and refine the process before scaling. “Industry playbooks and modernization guides can provide useful templates, but hands‑on experience is the most valuable teacher.”

Application rationalization is not just about reducing tools; it’s about aligning IT with business strategy, Walker states. “CIOs should view the process as a continuous portfolio management discipline, one that balances efficiency with innovation,” he says. “When done right, it becomes a driver of digital transformation rather than a reactive clean-up effort.”

CIOs are under constant pressure to innovate business processes for better efficiency and efficacy under financial constraints. Especially, in early-stage startups and small organizations with limited budgets, CIOs face extreme pressure from the board of directors to maximize the ROI on every dollar spent on innovation, as 60-90% of the organization’s budget is consumed just running operations. To make the most of limited budgets for innovation and optimize the cost of innovation, I vouch for investing in employee-led innovation as one of the best ways to develop cost-effective innovative solutions.  

The core idea behind optimizing the cost of innovation with employee-led innovation is based on the fact that employees working at the grassroots level know the business operations, challenges and potential solutions better than any other outside vendor or consultants. I agree that in many scenarios, industry-standard solutions, outside vendors and consultants provide better and cost-effective solutions. However, when the problem is company-specific and an organization needs customized innovative solutions, employee-led innovation wins.  

Your employees are your goldmine of ideas who can identify problems faster, find effective solutions quicker and iterate faster.  

Leadership needs to provide the pathway, resources and culture for employee-led innovation to happen and flourish.     

A framework for CIOs to lead the employee-driven innovation    

Struggling with scaling the operations of customer support departments to meet the growing needs of business, I ran the initiative of employee-led innovation a few years back, where operations employees highlighted repetitive manual tasks in the customer support operations, the need for the development of new channels of customer support and the creation of more extensive customer self-help resources. 

We successfully automated manual customer support operations, developed a live chat channel to reduce call and email volume and created an extensive knowledge base to reduce the number of tickets.   

The results included: 

• 25% faster response times 

• 30% more tickets resolved 

• 15% reduction in support calls 
   

The success was not due to new technology alone. It was due to accurate problem identification and early validation by the people performing the work. 

My framework for leading employee-driven innovation 

I use the following framework to lead employee-driven innovation initiatives from ideation to execution.     

1. Capture operational problems 

The first stage of finding innovative solutions is to capture the right problems causing operational friction. In most cases, industry standard solutions and external consultants fail to address the operational challenges because of the wrong identification of the problem. 

The operational proximity of the employees leads to high-quality problem discovery as they directly experience the friction, bottlenecks and system limitations. Directed the department to identify recurring issues, including workflow delays, repetitive manual processes, customer complaints and system limitations.  

2. Translate problems into testable hypotheses 

Early solutions proposed by employees are often assumptions. To find innovative solutions that are practical, applicable and drive business value, transform the problem into testable hypotheses. Ask questions: 

• What is the problem? Who is affected? How often does it occur?  

• What is the business impact?  

• What assumption must be true for a solution to work? 

• How many users are affected?  

• What is the potential value of resolution?  

This prevents random experimentation and aligns efforts with business priorities. 

3. Rapid experimentation and pilot implementation   

Finding novel solutions requires experimentation. To find the solution to selected problems, enter a focused innovation sprint. Teams develop prototypes and workflow models to demonstrate whether the idea can create measurable improvement. The focus is on proving value and validating usefulness, not perfection or building a production system.  

Allocate small budgets to the promising solutions. Test the solutions in real-world usage for 4-8 weeks. Measure success using practical metrics such as time saved, operational cost reduced and customer experience improved. This converts innovation into business value. 

4. Iterate and scale or stop    

Every initiative reaches a decision point. Measure the effectiveness of the initiative. Adopt an agile approach. Iterate, refine and retest. Scale into operations if it proves to be effective. Otherwise, terminate and document learning. Stopping ideas is not failure. It prevents larger, more expensive failures later.       

My key takeaways for leaders  

• Create structured processes to drive employee-led innovation. The key driver of employee-driven innovation is always leadership. Create the right structures, processes and environment where employee-led innovation can happen. Design systems where employees can reach the leadership to discuss the problems they face and want to solve. Provide support and direction to align innovation initiatives with business strategy.
• Find the right people. Find the right intrinsically motivated people who care deeply about their work and listen to their ideas. Create a group of motivated individuals, set up a small innovation lab and fuel the group with necessary resources.
• Create an environment for innovation to flourish. The right alignment to the business strategy, the right talent, streamlined processes and a decent budget still cannot create the low-cost engine of innovation unless you have a culture of collaboration at the workplace. Collaboration transforms even ordinary spaces into catalysts for advancement by fostering open exchange, sharing and interplay of ideas.      

When CIOs intentionally create the right structures, culture and decision frameworks, employee-driven innovation can become a low-cost, high-impact engine for competitive advantage.  

You are already sitting on a goldmine of ideas. You need to find the right people, fuel them with resources and create an environment for innovation. 

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

As every CISO knows, maintaining a strong cybersecurity posture is costly. What’s not so well known is that there are many ways cybersecurity can be enhanced with the help of relatively trivial investments. Simply by thinking creatively, a security leader can substantially boost enterprise protection at a minimal cost.

Could your organization benefit from some extra low-cost protection? If so, here are eight ways to improve enterprise cybersecurity without seriously denting your budget.

1. Enforce MFA better

Risk mitigation should start with fundamentals, says Trevor Horwitz, CISO at compliance technology services firm TrustNet. “MFA directly supports confidentiality and access control, which are core security objectives,” he states. “In almost every breach we analyze, compromised credentials are involved.” Most organizations already have access to this capability. Turn it on, especially for privileged access, Horwitz advises.

Randy Gross, CISO at certification firm CompTIA, agrees. “Begin by clearly defining the crown jewels and the next tier of important systems, then enforce MFA and least privilege across those environments,” he recommends. “Next, establish time-bound remediation expectations for the meaningful vulnerabilities in those systems before expanding attention to the broader environment.”

2. Take full advantage of your existing tools

A practical way to strengthen enterprise security without incurring additional significant spend is to ensure you’re fully leveraging the capabilities of solutions already present within your organization, says Gary Brickhouse, CISO at security services firm GuidePoint Security.

“Most organizations have invested heavily in security solutions, yet most are only using a portion of what those tools can do,” he explains. “By optimizing and operationalizing existing technologies, organizations can realize a reduction in cybersecurity risk with little spend.”

Brickhouse says this approach is highly effective because it focuses on improving operational maturity rather than adding more technology solutions. “This tactic also increases ROI by helping to ensure organization are getting the most value from solutions they already own,” he says.

3. Conduct tabletop exercises

Don’t underestimate the power of tabletop exercises, advises Ryan Davis, CISO at IT services provider New Charter Technologies. “They almost guarantee a positive action, and the only cost is in time,” he says.

A tabletop exercise requires participants to view scenarios from an execution perspective rather than a theoretical position.

“Practicing for unexpected scenarios enables teams to exercise muscles they wouldn’t normally use,” Davis says. “It allows team members to ask questions they may not typically ask in everyday scenarios because there isn’t time or an obvious need to do so.”

He adds that the approach also quickly highlights strengths that don’t need further attention, as well as gaps that need to be closed.

4. Utilize the application layer

An effective way to bolster coverage and reduce overall risk is to include the application layer in your cybersecurity strategy, says Bill Oliver, managing director at cybersecurity platform provider SecurityBridge. He notes that ERP systems sit at the core of your company’s operations and have been targeted by bad actors for years.

“Monitoring your ERP systems for missing security patches, bad security configurations, real-time security events, and so on can give you great cybersecurity protection at a relatively low cost as compared to other cybersecurity initiatives,” he says. “Understanding what security events are happening in real time, will greatly bolster your company’s cybersecurity program and correct a weakness that has been there since day one.”

5. Implement passkeys

Passkeys eliminate the single biggest attack vector most organizations face: stolen or phished credentials, says John Coursen, CISO at Fortify Cyber, a firm that helps regulated industries secure their infrastructure.

“They remove the human element from authentication,” he explains. Coursen notes that passwords tend to get reused, phished, and stuffed into credential databases. “Passkeys can’t be phished, because there’s no shared secret to steal.”

Coursen observes that most modern identity providers, such as Azure AD and Okta, already support passkeys. “The tech isn’t hard to implement — it’s the behavior change and getting users to adopt it.”

Start with your highest-risk users, Coursen advises, including executives, finance teams, and anyone with access to sensitive client data or wire transfer authority.

6. Aim for the heart

Target what attackers actually exploit, suggests Mike Wilkes, CISO at security technology provider Aikido Security. “Set up redundant DNS providers — they’re low-cost, high-impact, and massively underused,” he says. “Put Cloudflare’s free plan in front of your public-facing apps, and you get DDoS mitigation and a WAF layer instantly.”

Turn on SPF, DMARC, and DKIM, since email is still the No. 1 initial access vector and these DNS controls take just an afternoon to implement. “Enable MFA everywhere using the free Google Authenticator,” Wilkes says, while also recommending checking DNS records and auditing MFA for gaps.

7. Consider human risk management

At a time when the vast majority of cyberattacks involve people, human risk management is a critical and cost-effective way to keep the enterprise safe, says Matt Lindley, chief innovation and security officer at cybersecurity awareness training firm NINJIO.

Human risk management works because it addresses the most urgent cyberthreat most enterprises face by establishing a culture of cybersecurity at every level of the organization, Lindley says.

“Instead of treating employees as the weak links in an organization’s cybersecurity posture, they should be regarded as its greatest security assets,” he states. “When employees are empowered to identify, report, and thwart cyberattacks, the enterprise now has a distributed and adaptive layer of cybersecurity.”

Effective human risk management requires security leaders to provide engaging, actionable, and personalized security awareness training, Lindley says. It also demands a high degree of accountability. He notes that security leaders should be able to determine whether behavioral interventions are actually working by using benchmarks beyond vanity metrics, such as completion rates.

“This means providing data on phish reporting and other real-world improvements to the organization’s cybersecurity posture, all of which will generate buy-in across the C-suite,” he says.

8. Double-down on cybersecurity fundamentals

One of the most effective low-cost security strategies is to double down on fundamentals such as identity protection, patching, visibility, and user awareness, says Jeff Foresman, vice president of cybersecurity at technology services firm Resultant.

Most organizations already have the tools they need through platforms like Microsoft and Google, as well as their endpoint and email security stacks, Foresman says. The real opportunity, he notes, lies in better configuration and disciplined execution, such as enforcing MFA everywhere, reducing unnecessary admin access, patching Internet-facing systems quickly, and improving phishing reporting and response. “Those steps alone significantly reduce real-world risk,” Foresman says.

Foresman notes that a fundamentalist approach works by targeting how attackers actually gain access. The majority of breaches still begin with compromised credentials, phishing, exposed systems, or misconfigurations, not advanced zero-day exploits, he explains. By focusing on identity, email, and attack surface reduction, organizations can address the most common entry points.

“It’s practical, measurable, and tied to the breach patterns we see every day, rather than theoretical controls,” Foresman says.

See also:

• How MFA gets hacked — and strategies to prevent it
• Redefining multifactor authentication: Why we need passkeys
• Human risk management: CISOs’ solution to the security awareness training paradox
• CISOs must rethink the tabletop, as 57% of incidents have never been rehearsed
• Phishing training needs a new hook — here’s how to rethink your approach

The “digital divide” used to mean unequal access to devices and the internet. Today, that gap has evolved into something more consequential: An AI divide — not about access to tools, but about who knows how to use them well. 

In recent months, while mentoring several newly graduated computer science majors, I was struck by how familiar their resumes looked. Many had completed the same core coursework I took more than 25 years ago — database management, Java, traditional software engineering — while contemporary foundations like cloud platforms, applied AI, statistical modeling and GenAI workflows were often missing. 

The problem is not that Gen Z lacks ambition or intelligence. The problem is that the systems meant to prepare them, educational institutions and enterprises, are adapting at radically different speeds. 

The AI divide: Not access, but readiness 

A small number of well-funded, elite universities have begun integrating AI and GenAI into their curricula. But many less-resourced schools have taken a more cautious path — some even prohibiting student use of AI tools. The real constraint isn’t access to GenAI; it’s the harder, costlier work of modernizing curricula and upskilling faculty. Updating course design, retraining instructors and building new evaluation methods takes time and money. Many institutions simply don’t have enough of either, at least not yet.  

Meanwhile, headlines like “80% of Gen Z already uses AI” can be misleading. Adoption statistics often mask an uncomfortable truth: Usage intensity and skill depth vary dramatically. “Using AI” can mean anything from experimenting with a chatbot once a month to integrating AI into daily workflows with disciplined verification and iterative prompt design. 

Three Gen Z personas in AI adoption 

In observing how young professionals approach emerging technologies like GenAI, I see three distinct personas. They are not fixed identities. People can move between them. But the personas clarify the gap between surface adoption and real capability. 

1. The driver 

Drivers are proactive and disciplined. They learn continuously, experiment intentionally and integrate AI into their workflows, personally and professionally. Over time, they evolve from basic prompting (such as the PICO structure: Persona, input, context, output) to more sophisticated approaches like multi-step reasoning, iterative refinement and structured evaluation. 

Like real-world drivers, they make route adjustments, adapt to changing conditions and can choose their destinations. With repetition, AI becomes second nature, not a novelty, but a durable capability. 

2. The bus rider 

Bus riders use AI occasionally and tactically. Their prompts tend to be simple and task-based, often approached as a “better search” rather than collaborative problem solving. The goal is a quick outcome, not deeper understanding. 

For example, if a poem needs translation, a driver leveraging AI might specify tone, rhythm, audience, length, cultural nuance and even ask the model to assume the role of a bilingual poet skilled in both traditions. A bus rider is more likely to type: “Translate this.” Both users are “using AI,” but only one is building a transferable skillset. 

Bus riding is easy. It takes you somewhere. But it rarely gets you exactly where you want to go — and it rarely builds mastery. 

3. The train rider 

Train riders are passive and often cynical about AI’s impact. They spend more time debating AI than learning it, and they adopt a doomsday view that AI automation will replace most Gen Z jobs. Their posture is not adaptation; it’s resignation. 

The irony is that this mindset becomes self-fulfilling: The less you learn and practice, the narrower the career path.  

AI as foundational, not optional 

AI is becoming foundational to nearly every aspect of computing. We live in a digitized world where workflows, decision-making and productivity increasingly depend on AI-enabled tools. The practical implication is simple: Drivers will expand their career frontier, while bus riders and train riders will find their paths narrowing. 

This is why younger talent should not be viewed merely as junior technologists who need more tools. They benefit most from structured pathways that build judgment, context and accountability alongside technical fluency. 

Judgment is now an operational skill 

AI increases speed and output. However, it is unlikely AI will replace responsibility, at least not soon. In fact, the faster work moves, the more critical human judgment becomes. And in AI-enabled environments, judgment isn’t abstract; it shows up in daily operational decisions, such as: 

• Knowing when an AI output is “directionally useful” versus production-ready 

• Understanding data lineage and recognizing where bias or incompleteness may exist 

• Recognizing when speed introduces downstream risk — legal, security or reputational 

• Knowing when to escalate uncertainty rather than “force” an answer into production 

Early-career professionals often learn tools quickly. The responsibility of educators and employers is to pair that speed with decision frameworks to help them acquire the intuition to know when to move fast and when to slow down. 

Hybrid converged teams multiply results 

One of the most powerful ways to close the AI divide inside organizations is to build intentionally hybrid teams of seasoned experts and early career professionals. When designed well, they don’t just “balance” each other; they multiply effectiveness in AI adoption. 

Senior experts bring: 

• Pattern recognition from past cycles of technology change 

• Institutional memory around compliance, risk and client expectations 

• Confidence to challenge outputs — human or machine 

Early career professionals bring: 

• Comfort experimenting with emerging tools 

• Fluency in digital collaboration 

• A bias toward iteration and improvement 

Done right, this combination accelerates adoption while protecting quality. 

Upskilling as the core of AI readiness 

Organizations should treat AI adoption not only as a technology initiative, but also as an enablement and skills initiative. Training priorities should include: 

• AI fluency and model awareness 

• Human-in-the-loop validation practices 

• Data integrity, privacy and security fundamentals 

• Governance, ethics and workflow-level controls 

At Integreon, we avoid sink-or-swim models of skill development. Instead, we use structured exposure that accelerates learning without compromising trust: 

• Scenario-based training where teams review AI-assisted outputs together 

• Clear escalation paths for uncertainty — not just errors 

• Explicit conversations about why a decision was made, not just what decision was made 

• Ongoing refreshers as tools evolve and risk profiles shift 

This matters especially for early professionals. Small errors compound at scale. AI makes scaling easier than ever, which can become a double-edged sword.  

Conclusion 

The AI divide is not ultimately a technology problem. It is a capability problem, rooted in curriculum modernization, workforce design and the cultivation of judgment. Gen Z is not behind because they lack access to AI. Many are behind because they lack the structure that turns exposure into mastery. 

The winners in the AI era will be those who learn to “drive,” to master prompt engineering patterns and use AI with intention, context, verification and accountability. Education must modernize faster. Employers must treat upskilling as an operating system, not a one-time course. Leaders must design environments with hybrid converged teams that combine speed with wisdom. 

AI will reward the prepared, not the most skeptical and not the most casual. The future belongs to the drivers, and it is our shared responsibility to help the next-gen workforce become one. 

I used to think AI performance was mostly a GPU problem. 

Then I watched a “healthy” GPU fleet crawl. Not because we ran out of compute, but because we ran out of movement. Tokens waiting on data. GPUs waiting on batches. Services waiting on east-to-west traffic. Storage queues quietly turning into tail latency. 

Today, I do not even call this a storage problem. It is an information supply chain problem. In real enterprise AI, data is scattered across on-prem, cloud and edge footprints. Training and inference cycles get longer. Expensive resources like GPUs stay scarce. And the system pays a time tax every time data has to hop, copy, translate or wait. IBM frames AI storage in this same “supply chain” reality, especially as organizations modernize for distributed data and AI at scale.  

If you are running AI in production, especially LLM inference and retrieval augmented generation (RAG), the network and storage layer is where “it works” becomes “it works reliably at scale.” 

This is my field guide to the patterns that matter, the metrics that expose bottlenecks quickly and the open-source tools that can help you fix them. 

The metric shift: From averages to tail latency 

Traditional infrastructure teams love averages. AI punishes that mindset. 

For LLM inference, user experience is governed by two numbers: 

• Time to first token (TTFT): How long users wait before they see the first token.  

• Time per output token (TPOT): How smoothly tokens stream after the first one.  

MLCommons uses TTFT and TPOT in its LLM inference benchmarking rules because they reflect what users feel, not what a mean value hides. 

Once you track TTFT and TPOT in percentiles (p95 and p99), the network and storage layer stops being “someone else’s problem” and becomes an architectural priority. 

Two traffic shapes, two different bottlenecks 

Most enterprise AI systems fall into two traffic shapes that break different things. 

Shape 1: Training and batch analytics 

• Big sequential reads and writes  

• Dataset shuffles and checkpoints  

• Distributed training traffic across nodes  

This is bandwidth hungry. Parallelism and throughput matter. Latency is often less visible than in interactive workloads, but when training stretches from days to weeks, it is frequently a data path problem. 

Shape 2: Inference and RAG 

• Bursty request patterns  

• Many small reads (vector search, metadata, prompt artifacts)  

• High fan-out and fan-in across services  

• Tail latency dominates  

Most CIO conversations I have are about inference, because that is where customer experience, employee productivity and revenue workflows live. That means the architecture should be optimized for consistency, not just peak throughput. 

Three failure modes I see constantly 

1) GPUs look busy, but they are not productive 

I have seen GPU utilization in the 60 to 80 percent range while tokens per second stayed flat and queues kept growing. The system looked “loaded,” but it was not delivering more outcomes. 

In practice, the fix is often not “more GPUs.” It is better batching and memory management in the serving layer, so GPUs spend more time generating tokens and less time context switching or waiting for fragmented work. 

Serving engines like vLLM are useful here because they treat inference performance as a tunable discipline. You can tune batching, scheduling and memory behavior to balance throughput with TTFT and TPOT under real concurrency.  

Pattern I rely on: Separate the front door (API gateway, auth, rate limits) from the batching brain (LLM serving engine). Optimize for TTFT and TPOT, not just concurrency. 

2) East-to-west traffic quietly eats your latency budget 

RAG workloads are network hungry. A single prompt can trigger: 

• embedding lookup  

• vector search  

• metadata fetch  

• document chunk fetch  

• rerank  

• prompt assembly  

• LLM call  

Even if each hop is “fast on average,” the p99 gets ugly under load because the pipeline is chatty and synchronous. The system starts to feel like the model is slow when the real issue is that your request spends too much time traveling. 

Pattern I rely on: Collapse hops where possible, co-locate latency sensitive services and treat network round trips as a scarce resource. A simple rule I use is this: Do not let your p99 depend on a long chain of synchronous calls. 

3) Storage becomes the hidden queue 

In inference systems, storage rarely looks saturated at the device level. The problem is usually the data path: Too many copies, too much CPU involvement and too many small metadata operations that show up as tail latency. 

I like to explain the principle using GPUDirect Storage, even if you do not implement it. NVIDIA describes GPUDirect Storage as enabling a more direct DMA path between storage and GPU memory, reducing CPU overhead and latency by avoiding extra copies. 

You do not need that exact technology to benefit from the lesson. 

Pattern I rely on: Make the data path boring. Fewer copies. Fewer layers. Fewer handoffs. 

Unified data services beat siloed performance wins 

I have watched teams chase a 20% performance gain in one tier while ignoring the bigger issue: data fragmentation. 

If your AI pipeline bounces across disconnected file, object and block systems, you keep paying the hop tax. You also increase the chance that “the right data” is not where the model expects it to be. 

IBM’s AI storage framing is helpful because it emphasizes unified storage approaches that consolidate file, block and object services while integrating with existing investments, to deliver data at scale with low latency. 

Translated into an enterprise goal, this means fewer copies, fewer bridges and fewer places where tail latency can hide. 

Content-aware storage and RAG: An underused lever 

Here is a point that does not get enough attention. RAG is not only about models and vector databases. It is also about whether your enterprise can make unstructured data retrievable without turning the data estate into a copy machine. 

IBM notes that very little enterprise data is used to train the large language models behind assistants, limiting business value and highlights “content-aware” approaches that extract semantic meaning from unstructured data so assistants can answer more intelligently. 

I like this framing because it shifts the conversation from “store more data” to “make data usable where it already lives.” That is often the difference between a RAG system that scales and one that becomes a governance and cost problem. 

The metrics I track now (and why they work) 

When I am asked what to measure, I keep it simple. I want metrics that map to user experience and capacity decisions. 

Inference experience 

• TTFT p95 and p99  

• TPOT p95 and p99  

• Tokens per second per GPU  

• Queue time before execution  

MLCommons is a good anchor here because TTFT and TPOT are benchmarked precisely to capture user-visible behavior. 

Network health 

• Service-to-service latency p95 and p99  

• Retransmits and packet loss  

• East to west throughput per node  

• Queue depth in the network path during peak load  

Storage health 

• Read latency p95 and p99  

• IOPS and bandwidth at the namespace or volume level  

• Cache hit rates  

• Metadata operation rate and latency (the sleeper issue)  

System efficiency 

• GPU active time vs waiting time  

• CPU utilization and softirq time on serving nodes  

• Fan-out per prompt and per request type  

Two real-world use cases (with quantified outcomes) 

These examples reflect patterns I have seen repeatedly. The numbers are representative and meant to show the shape of the problem, not promise identical results in every environment. 

Use case 1: RAG assistant that “felt slow” even with plenty of GPU 

Symptoms 

• TTFT p95 drifted from about 0.7s to about 2.2s during peak hours  

• TPOT p95 stayed acceptable, but the first response felt delayed  

• GPU utilization looked fine, but queue time rose steadily  

Root cause 

• Vector search and chunk retrieval created bursty east to west traffic  

• Too many synchronous hops and too little caching of hot content  

• Network tail latency amplified fan-out  

Fix pattern 

• Co-located vector search and document store for hot shards  

• Cached top-k retrieved chunks and prompt templates  

• Added asynchronous retrieval and progressive context loading for long documents  

Outcome 

• TTFT p95 returned near baseline under similar user load  

• Fewer p99 spikes because the pipeline depended on fewer synchronous calls  

• Modest improvement in tokens per second because fewer requests stalled on I/O  

Use case 2: Adding GPUs did not improve throughput 

Symptoms 

• Tokens per second increased only about 10 percent after adding 25 percent more GPUs  

• TPOT p99 worsened under concurrency  

• CPU utilization spiked on serving nodes  

Root cause 

• Serving layer batching and memory churn wasted GPU cycles  

• Storage path added extra copies and CPU overhead for artifacts  

• Scheduling placed workloads on nodes without the right NIC or storage locality  

Fix pattern 

• Tuned the serving engine to match request size distribution and concurrency behavior (vLLM tuning is a good reference point for this type of work)  

• Improved device-aware placement using Kubernetes device plugin patterns so specialized hardware is advertised cleanly to the scheduler  

• Reduced CPU bounce buffering behavior in the data path where feasible  

The Kubernetes device plugin framework is the simple building block behind making “specialized resources” schedulable at scale. 

Outcome 

• More linear scaling as GPUs were added  

• Stabilized TPOT p99 because fewer requests were blocked behind slow neighbors  

• Reduced CPU overhead, freeing headroom for networking and observability  

Open source that fits these patterns 

You can implement most of these improvements using open-source components: 

• Observability: Prometheus, Grafana, OpenTelemetry and eBPF-based tooling to see flow-level latency and fan-out.  

• Caching: Redis for hot key/value caching; local NVMe caches for hot artifacts.  

• Serving: vLLM for configurable batching and memory behavior under load. 

• Scheduling: Kubernetes device plugins and resource-aware node pools for GPU and NIC locality. (Kubernetes device plugins:)  

• Storage: Ceph is a common open-source option for software-defined block, file and object patterns. IBM also calls out IBM AI Storage Ceph as an open source, software-defined approach aligned to these needs.  

Limitations and tradeoffs 

Every performance win has an operational cost. These are the tradeoffs I plan for. 

1. Caching improves consistency, but invalidation is hard. Freshness, permissions and compliance requirements complicate “simple” caches.  

2. Device-aware scheduling improves performance, but increases complexity. You introduce Kubernetes device plugins, operators and topology awareness. It is worth it, but it must be managed. 

3. Reducing copies can improve latency, but raises platform constraints. Direct data paths reduce CPU overhead, but they come with configuration and compatibility requirements.  

4. Unifying data services reduces silos, but consolidation needs governance. A unified approach can reduce hop tax, but only if access control, lifecycle policies and ownership are clear.  

Future scope: What will matter more next 

Over the next 12 to 24 months, I expect four themes to grow: 

• AI SLOs become standard: TTFT and TPOT become operational targets, not just benchmark terms.  

• Workload placement becomes policy-driven: Placement logic becomes strategic, spanning hybrid footprints.  

• More GPU-centric data paths: Fewer CPU copies and less context switching where possible.  

• RAG becomes “information supply chain” first: Content-aware approaches and unified data services reduce re-copying and re-governing the same data. 

What I would tell a CIO in an elevator pitch 

If you want AI to feel fast and reliable, stop treating it like a model deployment and start treating it like a distributed system with strict tail latency expectations. 

Measure TTFT and TPOT in percentiles. Map your pipeline fan-out. Make network and storage visible. Then apply disciplined patterns: Isolate lanes, cache aggressively, schedule intelligently, reduce copies in the data path and unify data services where it makes sense. 

Your GPUs will thank you, but more importantly, your users will. 

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

Intel’s Core Ultra Series 3 processors with Intel vPro, built for business PCs, are off to a fast start, already powering more than 125 designs including newly-announced systems from Dell and HP, the company said.

Unveiled this week at an event in New York City, the Core Ultra Series 3 with Intel vPro brings what Intel described as “next-generation performance efficiency and integrated AI acceleration,” as well as providing an enhanced vPro management platform.

The company first announced the Core Ultra Series 3 processors in October 2025. Previously codenamed Panther Lake, they will also appear in new consumer PCs.

Users of systems running on the new chips will see over 30% faster performance, up to 80% better graphics, and up to 4x AI performance compared to four-year-old systems, the average PC refresh period for businesses, according to Intel.

While the new systems can run code faster, Intel is also pushing for them to be more intelligent about the code they do run. Enhancements to vPro include the Intel vPro Certification Program that Intel said results in as much as 59% reduced CPU utilization, a 74% reduction in background activity, and power efficiency improved by 56%.

AI is also playing a bigger role in the form of vPro Intelligence with Device IQ, which offers AI-driven analytics to detect, diagnose, and resolve issues. There’s also vPro Fleet Services to simplify out-of-band manageability via a fully managed SaaS-based activation and integration with Microsoft Intune, and security enhancements including Intel Total Storage Encryption for Microsoft BitLocker and AI-based threat detection using Intel’s chip-based Threat Detection technology (DTECT).

Business PCs incorporating these technologies will be available beginning on March 31.

Dell has launched an updated Dell Pro Notebook lineup which includes devices powered by the Intel Core Ultra Series 3 processor. It offers models with and without vPro.

The Dell Pro Premium is designed for on-the-go executives and managers; the Dell Pro 7 is for users such as consultants and sales professionals who need systems that are portable, yet capable; the Dell Pro 5, the company said, provides mobility for users such as financial analysts while maintaining the performance they need for their business applications; and the Dell Pro 3 was created for users who run core productivity applications such as email, document creation, and collaboration.

The Dell Pro Premium will be available on March 31, and the other models will hit the shelves in May. Pricing has not yet been announced.

HP’s refreshed portfolio for business includes 31 new models powered by Intel, AMD, and Arm processors. Intel-powered devices include multiple configurations in the EliteBook 8 G2 series, an AI PC designed for knowledge workers, and the EliteBook 6 G2 series for mobile professionals and office collaborators. Other models are directed at the SMB market. The company also announced the EliteDesk 8 G2 for enterprise workers.

The EliteBook 8 G2 devices are expected to be available in April, as are the EliteDesk models. The EliteBook 6 G2 is scheduled for June. Pricing has not yet been announced.

With AI coding assistants rapidly advancing, some organizations are pushing the AI-aided application development concept further by engineering enterprise-grade tools to replace or extend traditional software.

While a trend toward vibe coding your own enterprise software appears to be in its infancy, some companies have reportedly replaced their traditional CRMs with homegrown applications.

In recent weeks, stock prices of traditional SaaS vendors have taken hits over worries about competition from AI. Much of concern has focused on customers spending less on SaaS as they ramp up AI deployment and on AI agents taking over some functionality of SaaS platforms.

But some experts contend that customers may also opt out of some SaaS subscriptions entirely as they roll their own replacements. While major SaaS platforms may not be in danger, smaller enterprise apps that connect to them may increasingly be deployed in house by companies using AI coding assistants or deploying home-grown agents.

IT leaders should beware, however, that significant challenges exist. Replacing road-tested enterprise software packages with vibe-coded apps is risky, with the responsibility of maintenance and support falling on the deploying organization.

Vibe coding vs. buying

Nevertheless, AI coding agent vendor Factory has been eating its own dog food by building some of its own enterprise apps, says Eno Reyes, CTO and cofounder there. Several of Factory’s customers are doing the same thing, he adds.

In the past six to eight months, the company has started asking whether it can build a software package itself instead of buying or subscribing, he says. Factory’s customer support workflow and its legal tooling were built internally with AI agents, and the company replaced a third-party analytics app with an internal build.

“Internally, we’ve started building a lot of things that historically we would have bought,” Reyes says. “A lot of our internal workflow systems are just code that the agents produced.”

He sees the same trend among customers. “A lot of the tools they used to buy are small utilities or micro-SaaS products,” he says. “With an agent, someone can just say, ‘Build me a dashboard that shows engineering velocity’ or ‘connect this dataset with this one and visualize it.’ Instead of going through procurement, the tool just gets built.”

The advantages of building your own software include flexibility and speed, Reyes adds. “If you want something very specific, an agent can generate it directly against your own data, systems, and workflows,” he says. “That’s why things like internal dashboards, analytics tools, or small workflow apps are often easier to build than buy now.”

The cost of doing it yourself

But there are also real disadvantages, with the costs of building your own internal apps and the maintenance of the software being major considerations, Reyes cautions.

“Even though agents can generate software, a full SaaS product usually exists because a large team has spent years maintaining it,” Reyes adds. “When we run our internal benchmark where agents replicate SaaS products feature by feature, the agent can do it, but it takes a long time to run and it’s expensive. And when it’s finished, you still don’t have a team of hundreds of people maintaining the system.”

Another potential problem is the scope of the software being built. “Tools like vibe-coding apps can produce smaller applications easily,” Reyes says. “But when you’re talking about complex enterprise systems, the software gets large very quickly, and you need infrastructure that can manage and maintain that codebase over time.”

With these potential downsides, Reyes doesn’t see vibe-coding AI apps replacing all established SaaS platforms anytime soon. Enterprise apps like Slack, with strong network effects, will survive, as will systems — like Salesforce’s CRM — that function as a core source of truth, he says.

Instead, AI coding assistants and agents will compete with apps that form the layer around major enterprise systems, Reyes predicts. Tools that simply connect other products, visualize internal data, or provide small workflow utilities are easier to generate on demand, he says.

Adam Arellano, field CTO at AI-powered dev tools vendor Harness, also sees some push toward organizations developing their own enterprise software, but he warns about the pitfalls.

“This is happening a lot, with some extreme cases where a C-suite leader has mandated ‘no new software purchases or headcount, do it with AI,’” he says. “There are other more reasonable approaches where a company has built point solutions for very specific problems and found certain levels of success that are useful in the short term but sometimes flounder after a while.”

The advantages of vibe coding your own enterprise software include the satisfaction of quickly building a tool for a specific need, Arellano adds. But maintaining the vibe-coded software and getting it to work with other apps can be a challenge, he says.

“Not unique to vibe-coded tools, this has always been the hard part of point solutions in the enterprise, but getting point solutions to reliably function and play nicely with larger platforms or programs of record takes work,” he says. “Vibe coding makes the problem urgent because the speed at which these tools can be produced is so much faster than enterprises can integrate their outputs, understand how they work, and maintain their connections.”

In the immediate future, vibe coding critical internal apps isn’t likely to save much money or time, unless the process is well governed, he says, noting recent outages at AWS related to AI-generated code.

However, improvements in AI coding assistants will make it easier over the long term for companies to develop their own enterprise software, Arellano says. “It will take a while and like any new tech or tool, the road to good will be littered with the broken remains of ‘almost good enough, but not quite’ tools,” he adds. “A lot of things are going to break in the meantime.”

Seduced by AI coding assistants

Other IT leaders see major risks with vibe coding enterprise software. The practice has a “seduction phase,” says Geoff Burke, senior technology advisor at ransomware defense vendor Object First.

“At first, it feels like a brilliant partner,” he explains. “But give it too much autonomy and it injects inaccuracies, complexity, and bypasses security norms, which you will spend twice as long cleaning up later.”

AI-assisted development should operate within strict access controls, diligent peer review, robust testing, and isolation from sensitive information and production environments, Burke says.

“Companies are bolting on AI to look modern, which may be fine in parts of the stack, but in core development workflows and repositories, CIOs should not chase trends that rely on experimental AI to make critical decisions about code and data integrity,” he adds.

Vibe coding with strict controls may produce good results, but if employees outside the IT team quietly create their own workarounds using AI coding assistants, chaos can ensue, adds Blake Crawford, cofounder and CTO at IT consulting firm Fusion Collective.

There’s huge potential for crippling technical debt when all employees feel free to create their own enterprise apps without supervision, he says. Most veteran IT professionals will know the strengths and weaknesses of AI-generated software, but an accounts payable clerk creating add-on apps for his SAP workflow may not, he adds.

“I use AI coding assistants in my daily practice, but I’m more than 25 years into my dedicated technology career,” he says. “I understand what AI coding assistants are good at, and even more importantly, what ‘good’ looks like in software development. That allows me to intercept problems quickly and avert any additional tech debt.”

AI assistants are showing up at many companies that don’t focus on IT products, and in many cases, employees and leaders have major questions about the best way to use them, Crawford says.

“With vibe coding, a company then owns what is made, right down to the problems it creates,” he says. “An enterprise doesn’t work well if it’s stitched together with myriad apps, many of which will be misused and grow beyond their scope, making everything from support to integration a problem.”

Crawford sees the temptation to roll your own enterprise apps growing as AI coding assistants improve, but he urges caution.

“There will be a serious retraction when the bill comes due on poor architectures and accumulated technical debt,” he says. “If companies aren’t careful, leaders will be looking at years, if not decades, worth of issues to deal with.”

There’s a quiet assumption baked into most AI adoption conversations: that access equals advantage.

Buy the API. Plug in the model. Watch productivity soar. Brief the board on your AI transformation. Repeat.

It’s a compelling narrative, and for vendors, it’s a lucrative one. But there’s a harder question that most enterprises haven’t yet asked loudly enough: Who actually controls the intelligence powering your most critical decisions?

Because access and control are not the same thing. And as AI becomes embedded deeper into business operations, supply chains, customer relationships and strategic planning, the gap between those two concepts will define the next era of enterprise competitiveness — and risk.

The illusion of capability

When an organization integrates a third-party AI system, it gains capability — but not sovereignty.

The distinction is not semantic. It is strategic.

Capability is what the tool can do. Sovereignty is your authority over how, when, why and for whom it does it. Most enterprises currently have the former and are dangerously short on the latter.

Consider what “AI adoption” actually looks like in practice for the majority of organizations today: SaaS platforms with AI features baked in, large language model APIs accessed through third-party wrappers, copilot tools that sit inside productivity suites owned by someone else. In every case, the enterprise is the consumer of intelligence — not the architect of it.

Rented intelligence comes with invisible terms. The model can change overnight. Pricing can shift. The vendor can be acquired, sunset the product or alter the underlying behavior, all without your consent. Your “AI strategy” is, in reality, a dependency strategy. And dependency, at scale, is a liability.

That’s not transformation. That’s sophisticated outsourcing with better marketing.

What sovereignty actually means

AI sovereignty is not about building your own foundation model from scratch. Very few organizations need that, and fewer still could responsibly afford it. This is not a call for every enterprise to become an AI research lab.

Sovereignty is about governance, transparency and control at every layer of the AI stack. For CIOs, that means demanding accountability across four distinct dimensions:

• Data sovereignty means your training data, fine-tuning data and inference data stay under your jurisdiction. You know where it goes, who sees it, how it’s retained and how it may be used to improve someone else’s model. The moment your proprietary data flows through an external system under permissive terms, you’ve potentially handed a competitor — or a future competitor — a map of your business.
• Model sovereignty means you can audit, validate and — where necessary — override the model’s outputs. You’re not a black-box passenger. You understand, at least at a governance level, why a recommendation was made. If your AI-powered system flags a customer as high-risk, denies a loan or makes a supply chain decision, you need to be able to explain that to a regulator, a customer or a board. “The model said so” is not an acceptable answer in any of those rooms.
• Operational sovereignty means you can run the system on your infrastructure, in your regulatory environment, without a third-party kill switch embedded in your operations. Uptime, security posture, data residency and business continuity must remain under your control; not subject to a vendor’s SLA and their legal team’s definition of “reasonable.”
• Strategic sovereignty means your AI roadmap isn’t held hostage to a vendor’s product priorities, API deprecations or quarterly earnings pressures. It means you have portability, optionality and the internal capability to adapt — not just consume.

Without all four, AI adoption is building on sand.

AI sovereignty is not about building your own foundation model from scratch. Very few organizations need that. Sovereignty is about governance, transparency and control at every layer of the AI stack.

The geopolitical reality CIOs can’t ignore

This isn’t abstract philosophy. It’s already a board-level crisis in motion.

Nations are waking up to the reality that AI is infrastructure — as strategic as energy grids, telecommunications networks or financial clearing systems. The country or corporation that controls the AI layer controls the insight layer. And whoever controls insight shapes decisions, at scale, in real time.

That’s why we’re seeing the EU’s AI Act push hard on transparency and accountability requirements that will force explainability into procurement conversations. It’s why governments across Europe, Asia and the Middle East are mandating sovereign AI cloud environments for public sector workloads. It’s why defense and intelligence agencies flatly refuse to run critical operations through foreign-owned models. And it’s why enterprises in financial services, healthcare and critical infrastructure are scrambling to renegotiate AI vendor contracts that were signed before anyone thought carefully about data residency and model governance.

This is not protectionism. It’s prudence. And the CIOs who recognize it early will be the ones who avoid the painful — and expensive — unwind later.

The enterprise blind spot that will define the next decade

Here is the uncomfortable truth that most AI enthusiasm papers over: when a company allows its customer data, proprietary processes and competitive intelligence to flow through a third-party AI system, it risks training its own replacement.

Every query, every document, every workflow that passes through an external AI enriches that vendor’s understanding of your industry, your customers and your operational logic, sometimes explicitly, sometimes through aggregated inference, sometimes through the terms buried in a click-through agreement your legal team didn’t fully review. The data flywheel spins in the vendor’s favor, not yours.

Meanwhile, your teams grow increasingly dependent on outputs they can’t explain, validate or own. Institutional knowledge migrates from your people to an external system you don’t control. The prompt engineers become the new power users, but the underlying intelligence, the actual competitive asset, belongs to someone else.

That’s not a productivity gain. That’s a long-term strategic liability dressed up as innovation.

A sovereignty-first AI framework for CIOs

The answer isn’t to reject AI. The answer is to adopt it deliberately, with governance built in from day one — not retrofitted after the audit.

• Audit your AI dependencies like you audit your supply chain. Map every third-party AI touchpoint across the organization. Understand what data flows where, under what contractual terms and what your exit options are. If you don’t know, that’s the first problem to solve.
• Distinguish between commodity AI and strategic AI. Using an external model to summarize emails, generate first drafts or auto-categorize support tickets? That’s commodity usage; the risk-reward tradeoff is manageable. Running pricing decisions, M&A analysis, patient diagnostics or fraud detection through a system you don’t control? That demands a fundamentally different level of scrutiny, contractual protection and architectural isolation.
• Invest in internal AI literacy, not just AI tooling. Sovereignty requires humans who understand what the model is doing, not just that it’s doing something impressive. Build model evaluation competency internally. Train decision-makers to interrogate outputs, not just consume them. The organizations that will fare best are those that treat AI as a skill to be developed, not just a service to be purchased.
• Demand explainability as a contract requirement, not a product feature. If a vendor cannot provide a credible account of why their model made a recommendation, they should not be making recommendations that affect your customers, your compliance posture or your business outcomes. Explainability isn’t a nice-to-have. It’s a fiduciary baseline.
• Architect for portability from the start. Design your AI infrastructure so you’re not locked into a single provider’s ecosystem. Model interoperability, open standards and the ability to swap or self-host foundational components aren’t technical niceties: they’re strategic insurance policies. The cost of building in portability now is a fraction of the cost of rearchitecting under duress later.

The leadership imperative

AI sovereignty is ultimately a leadership question, not a technology question. It requires CIOs to move from implementers of vendor vision to architects of organizational intelligence, and it requires boards and CEOs to fund that shift accordingly.

The organizations that will lead in the next decade won’t be those that adopted AI fastest. They’ll be those who adopted it wisest, who understood that intelligence, like data before it, must be governed, not just consumed. Who insisted on control even when convenience argued against it. Who built AI capability that compounds internally, rather than dependency that compounds externally.

Every CIO today faces a version of the same strategic fork: build an AI foundation your organization owns and understands, or optimize for short-term speed and inherit long-term exposure.

The question isn’t whether you’re using AI.

The question is: do you own your AI future — or are you renting someone else’s?

Because AI without sovereignty isn’t a competitive advantage.

It’s just very fast dependence.

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

CIO코리아와 한국IBM은 3월 5일 서울 그랜드 인터컨티넨탈 서울 파르나스에서 ‘에이전틱 AI 리더십 익스체인지(Agentic AI Leadership Exchange)’ 조찬 포럼을 개최했다. 제조·유통 산업의 CIO, CDO, AX·DX 리더들을 대상으로 열린 이번 행사에는 30여 명의 업계 관계자가 참석해 ‘무엇을 할 수 있는가’를 넘어 ‘어떻게 실제 성과로 연결할 것인가’를 핵심 화두로 에이전틱 AI 도입과 확산 전략을 논의했다. 행사에서는 EY 컨설팅의 이창호 파트너와 한국IBM 기술 리더 4인이 연사로 나서 에이전틱 AI의 글로벌 도입 사례를 비롯해 엔터프라이즈 표준 아키텍처, AI 레디 데이터 전략, 백엔드 연동 방안 등을 소개했다.

한국IBM 김성균 상무는 개회사에서 올해 초 고객사를 만나며 공통적으로 확인한 두 가지 핵심 어젠다로 AI 에이전틱과 SRE(사이트 신뢰성 엔지니어링) 구축을 꼽았다. 그는 “고객들이 가장 궁금해하고 많이 질문하는 핵심 주제를 중심으로 이번 행사를 구성했다”며 행사의 취지를 설명했다.

첫 연사로 나선 이창호 EY 파트너는 ‘주요 산업의 에이전틱 AI 도입 현황 및 전망’을 주제로, AI-레디(Ready) 기업으로 도약하기 위한 다섯 가지 핵심 전환 방향을 제시했다. 그는 ▲인간 중심 프로세스를 AI-퍼스트 워크플로우로 재설계 ▲현안 중심의 바텀업 개선이 아닌 AI 에이전트 기반 톱다운 혁신으로 전환 ▲에이전트를 단순 지원 도구가 아닌 전사 수준의 비즈니스 플랫폼으로 인식 ▲단일 조직·시스템 내 개선을 넘어 조직 간·시스템 간 업무 혁신에 집중 ▲업무 자동화 중심에서 의사결정 지원 중심으로 전환해야 한다고 강조했다.

이 파트너는 “이제 기업들의 관심은 에이전트 개발 방법론이 아니라 어디에서 실질적인 ROI를 확보할 수 있는가로 이동하고 있다”며 “톱다운 접근을 통해 성과 창출이 기대되는 영역을 우선 선정해 추진하는 것이 중요하다”고 말했다.

이 파트너는 특히 기존 RPA가 반복 작업 자동화에 머물렀다면, 에이전틱 AI 시대에는 LLM 기반의 APA(Agentic Process Automation)로 패러다임이 전환되고 있다고 설명했다. APA는 맥락 이해와 실시간 학습, 자율적 의사결정이 가능해 인간의 판단이 필요했던 업무까지 자동화할 수 있다는 것이다. 또한 조직 간 커뮤니케이션 영역에서 문서와 데이터가 비효율적으로 전달되는 지점에 에이전트를 도입하면 효과가 크다고 짚었다.

이창호 파트너는 마지막으로 에이전트 시대의 전략적 전환을 위한 제언도 제시했다. 그는 단일 부서나 시스템 단위의 PoC에 머물기보다 기간계 시스템과 연계된 자동화를 지향해야 하며, AI가 핵심 비즈니스를 수행하는 환경에서 기업이 어떤 모습일지를 먼저 구상한 뒤 이를 역산하는 방식으로 조직 간 의사결정 업무를 위한 AI 플랫폼 전략을 수립할 필요가 있다고 조언했다. 또한 AI 기술 조직이 아닌 프로세스 혁신 조직을 중심으로 협업 체계를 구축하고, AI가 학습하고 활용할 데이터의 의미 기반 연결을 위해 ‘AI 레디 데이터(AI Ready Data)’를 준비해야 한다고 설명했다.

김혜영 한국IBM 소프트웨어 테크니컬 리더는 복수의 글로벌 조사 결과를 인용하며 에이전틱 AI 도입의 현실을 짚었다. MIT 조사에 따르면 AI를 도입한 기업 가운데 실제로 성공적인 성과를 거둔 기업은 5% 미만에 불과하다. IDC 조사에서는 84%의 기업이 AI 유스케이스를 발굴하고 연구하고 있는 것으로 나타났지만, BCG 기준으로 실제 파일럿 프로젝트까지 진행한 기업은 26%에 그친다. 또한 맥킨지 보고에 따르면 운영 단계로 확장해 실질적인 효과를 거둔 기업은 10% 수준에 불과하다.

김 리더는 이러한 격차의 원인에 대해 “많은 기업이 에이전트를 만드는 데 초점을 맞추고 있지만, 실제 백엔드 시스템 연동을 포함한 운영 준비는 충분히 갖추지 못한 경우가 많기 때문”이라고 진단했다.

김혜영 리더는 엔터프라이즈 에이전틱 AI의 표준 아키텍처로 에이전트 SDLC(개발 라이프사이클), 에이전트 오케스트레이션, 모델 및 도구 계층, 데이터·시스템 연동 계층, 보안·거버넌스 계층, 운영·비용 관리 계층 등 6개 기술 스택을 제시하며 “에이전트 개발뿐 아니라 뒷단 시스템과의 연동, 라이프사이클 관리, 거버넌스까지 갖춰야 비즈니스 성과로 이어진다”고 강조했다.

김광수 한국IBM 어카운트 테크니컬 리더는 에이전틱 ADLC(Agent Development Lifecycle)를 주제로 발표했다. 그는 에이전트 AI 도입 시 부서별로 분리된 AI 운영의 사일로화, 중앙 관리 체계의 부재, 거버넌스 미비 등 세 가지 허들을 지적하며 “에이전트를 구축했다고 해서 끝나는 게 아니라 개발·테스트·배포·운영·모니터링의 전반적 프로세스를 갖추어야 지속적 확장이 가능하다”고 말했다.

IBM의 ‘왓슨x 오케스트레이트(watsonx Orchestrate)’ 플랫폼을 중심으로, 노코드 기반의 5분 내 에이전트 구축, 수백 가지 커넥터를 통한 ERP·CRM 등 기존 시스템과의 빠른 연결, 멀티벤더·멀티모델 지원, 내장된 가드레일을 통한 보안·거버넌스 기능 등을 소개했다. 또한 개발자 향 커스텀 에이전트 구축 도구인 ‘밥(Bob)’ 프로젝트와 에이전트 옵저버빌리티 기능도 함께 공개했다.

한 글로벌 식음료·소비재 기업의 실제 도입 사례도 공유됐다. 해당 기업은 기존 MS 코파일럿 환경 안에서 왓슨x 오케스트레이트를 통해 HR·IT 등 멀티 에이전트 오케스트레이션을 구현했으며, 직원 만족도와 생산성 향상, 보안 리스크 감소, 확장 가능한 아키텍처 확보 등의 효과를 거둔 것으로 소개됐다.

김동영 한국IBM 어카운트 테크니컬 리더는 ‘AI 레디 데이터(AI Ready Data)’ 관점에서 발표했다. 그는 “63%의 기업이 데이터 파편화 문제를 경험하고 있고, 실제 AI 모델에 활용되는 기업 데이터는 1% 미만”이라며 데이터 통합·품질·거버넌스·비정형 데이터 관리 등 네 가지 관점의 준비가 필요하다고 설명했다.

특히 비정형 데이터 처리와 관련해, IBM의 왓슨X닷데이터(watsonx.data)가 PDF·워드 등 문서에서 데이터를 자동 추출하고 청킹·임베딩을 거쳐 벡터 데이터베이스에 적재하는 파이프라인을 제공한다고 소개했다. 또한 IBM이 인수한 컨플루언트(Confluent)의 카프카 기반 실시간 데이터 처리 역량과 데이터스택스(DataStax)의 NoSQL·벡터·그래프 데이터베이스 기능을 결합해 AI에 필요한 실시간 데이터 인프라를 구축할 수 있다고 설명했다. 제로 카피(Zero-Copy) 통합 기능을 통해 온프레미스와 클라우드 간 데이터를 복사 없이 활용할 수 있어 비용·속도·보안 측면에서 최적화된다는 점도 강조됐다.

마지막 세션에서 유근진 한국IBM 어카운트 테크니컬 리더는 AI 에이전트의 엔터프라이즈 백엔드 연결을 주제로 발표했다. 그는 제조 현장에서 “3번 라인 가동 상태가 어때?”라고 물었을 때 성형기 진동을 감지해 예방 정비를 권고하거나, 유통 매장에서 “강남점 제품 재고 상태는?”이라는 질문에 4시간 후 품절 예상과 자동 발주 제안까지 이어지는 챗봇 데모를 선보이며 “실시간 시스템 오브 레코드에서 발생한 데이터를 AI가 실시간으로 피드받아 액션하는 것이 ROI의 가장 핵심적인 부분”이라고 말했다.

유근진 리더는 엔터프라이즈 AI 에이전트 아키텍처에서 API 게이트웨이, AI 게이트웨이, MCP 게이트웨이라는 세 가지 단일 진입점의 중요성을 강조했다. 프롬프트 종류에 따른 적절한 LLM 모델 라우팅, 비용 관리 및 최적화, 보안·인증·인가 등을 게이트웨이 단에서 통합 관리해야 한다는 것이다. 보안 측면에서는 API 키·인증서 등을 중앙 저장소에서 관리하고 접속 시점에만 동적으로 발급·폐기하는 ‘단기 자격증명’ 방식을 제안했다.

그는 또한 AI 에이전트 시대에 옵저버빌리티(가시성)의 중요성을 언급하며, LLM 토큰 사용량·비용·레이턴시 모니터링부터 에이전트의 비결정적 행동 추적, MCP 게이트웨이 연동 상태 점검까지 포괄적 관찰이 필요하다고 밝혔다. 유근진 리더는 “에이전트 기능을 제공하는 소프트웨어 벤더는 많지만, 개발부터 운영, 비용 관리까지 엔터프라이즈 전반을 아우르는 기능을 제공하는 사례는 아직 많지 않다”며 “IBM은 이러한 영역을 통합적으로 지원하는 플랫폼을 제공하고 있다”고 설명했다.
jihyun.lee@foundryco.com