Providers and deployers of AI systems: You only have a couple of weeks left until you must explicitly inform users when they are interacting with AI content.

To assist in the effort, the European Commission (Commission) has published guidelines to help AI deployers get in line with the AI Act’s transparency obligations, which will begin to go into effect on August 2.

After that, companies providing AI systems must alert users when they are interacting with AI. They must also tell users when they have been exposed to deepfakes, “emotion recognition,” or biometric categorization systems, or when they are given AI-manipulated content in matters of “public interests without human review or editorial control.”

Henna Virkkunen, the Commission’s executive VP for tech sovereignty, security and democracy, said in a statement, “with today’s guidelines, the Commission supports the smooth and effective application of the AI Act to make AI systems interacting with people such as chatbots and AI agents and AI content more transparent and trustworthy. These guidelines support providers and deployers in meeting their obligations under the AI Act, while helping citizens know when they are interacting with AI.”

Systems must include machine-readable markers to reveal such content, to reduce “the risk of deception and manipulation” and build public trust in AI.

“Generative systems have collapsed the cost of producing convincing content while the cost of judging it stands where it always stood,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. This requirement is “an attempt to restore friction to that imbalance.”

A company’s non-compliance could result in fines anywhere from €750K (about $856K) to €15M (about $17 million), or even up to 3% of its total worldwide annual revenue.

Transparency requirements

The EU AI Act’s transparency requirements apply to “natural or legal persons,” public authorities, agencies, or other bodies that develop AI systems, or have them developed, and place them on the EU market or into use under their name or trademark. This means all companies, regardless of whether or not they are EU-based.

“Systems placed on the European market, put into service there, or producing outputs used there are inside the field, wherever the developer sits,” Gogia noted.

Applicable systems must be intended to interact directly with “natural persons”; these systems include AI-enabled chatbots or conversational agents, AI companions, or coding agents. However, AI-enabled tools like recommender systems, spam filters, authentication, search and retrieval, transcription, text and code auto-completion, or predictive maintenance do not fall under the rule.

Specific outputs such as AI-generated text, images, video, and audio must contain a machine-readable mark. Deepfakes and public interest-related text created by AI without human review or control must be clearly labeled, however, deepfake content that is “artistic, creative, satirical, or fictional” is largely exempt.

AI content must be marked with one of three labels: “AI,” “Fully AI-generated,” or “Partially AI-modified.” For instance, “Fully AI-generated” applies when news summaries, music, art, or videos have been created without any human oversight (apart from prompting), while “partially AI-modified” could mean a person’s face is swapped into an authentic photograph to create a deepfake.

The three icons are publicly available for free use; enterprises can download zip files in PNG and SVG formats.

Most of the Act’s transparency rules begin to go into effect on August 2. But AI systems placed on the market before then will have some leeway; they must be in compliance by December 2.

However, a four-month allowance “on one obligation, for one population of systems, contingent on one procedural step, is not a strategy,” Gogia emphasized. Enterprises should plan to comply by August 2 and “treat any relief that arrives as margin.”

A consistent code of practice

Along with the transparency guidelines, the Commission has introduced a code of practice that essentially serves as a gesture of good faith. When signed, it can provide “legal certainty” and a “simple and practical” way to demonstrate compliance with the AI Act, according to the Commission. Signatories can also collaborate through the ‘Signatory Taskforce,’ which will share practices and advance technologies around marking and labeling practices.

Providers that choose not to sign must comply through other methods and demonstrate that those methods are “adequate” through assessment by surveillance authorities, according to the Commission.

Non-signatories “keep their flexibility, and will face more case-by-case scrutiny for it,” said Gogia.

Criteria for compliance

Shashi Bellamkonda, principal research director at Info-Tech Research Group, pointed out that the transparency requirements apply to content only when three criteria are met: It has been published, is informative to the public, or is on matters of public interest.

B2B business content or blogs may not need an AI disclosure if they do not meet these criteria, he noted. Also, published text that has undergone human review or is under editorial control does not need to be labeled. Editorial control means that a person must hold the ultimate legal responsibility for the publication of the content.

Many companies like Google, Adobe, and LinkedIn have already established ways to identify images marked as AI-generated. Meta has made it a requirement, but the creator has to add the AI-generated label, Bellamkonda said.

“This is a good move for guardrails around public information, and companies with good compliance and ethical oversight may not have to worry about this,” he noted. But as a general practice, companies should disclose AI-generated content and state whether it has been human reviewed.

Creating a transparency pipeline

Establishing full transparency means identifying who carries the responsibility for the content, whether the marking survives real use, not just testing, and what evidence will defend the decision, Gogia said.

Concerns cluster around responsibility, durability and evidence. Several organizations usually touch one piece of content, and none controls the whole chain, which is why contracts become the “pressure point,” he said. Most current agreements were written to deliver software and say “almost nothing” about provenance persistence, verification access, or evidence retention.

The durability concern is the most difficult, Gogia noted, because marking performs well in controlled settings but “badly in ordinary life.” Meta, for one, said its invisible watermark was designed to survive cropping; a published test, however, found the company’s preview detector missed 55% of cropped images.

“CIOs should ask which platform can actually provide evidence before believing its dashboard,” said Gogia.

Disclosure of AI use must be “clear, distinguishable and accessible,” he emphasized. “A notice buried in lengthy terms, or reachable only through determined clicking, satisfies nobody, least of all a market surveillance authority.”

Sustained compliance is a “living control” requiring a central record of systems, duties and evidence; testing taking place where the user meets the control rather than where the developer built it; and continuous supplier assurance. Enforcement will vary by country, so keep one common baseline with local overlays, Gogia said.

His advice: Inventory every system that talks to people, generates content, or gauges sentiment; classify provider and deployer roles; place disclosures at first interaction; define substantive human review; keep the evidence.

Marks and provenance signals should be tested after content undergoes cropping, compression, translation, transcription, and other editing, Gogia said. A useful audit starts from a real output and follows its “pulse” through generation, editing and publication, identifying at “each beat” the responsible party, the surviving mark, and evidence for exceptions. Missed labels should also be traced for root cause and recurrence.

To ensure compliance, before August 2, enterprises need a prioritized inventory, live disclosures on the highest-risk use cases, and a “named owner for every control,” he noted. In the first 30 days, they should stabilize and test; in the first 90 days, push requirements into procurement processes as a standing discipline. Procurement must secure commitments on marking methods, known failure modes, and evidence access, with explicit notice if/when any of them change.

“The sensible architecture is a common transparency baseline carrying traceability, responsibility, and evidence, with jurisdictional overlays for language, sector rules, and local practice,” Gogia said.

This article originally appeared on CIO.com.

The head of the US government’s AI testing institute, Chris Fall, has resigned about three months after taking charge of the Center for AI Standards and Innovation (CAISI), the federal organization responsible for evaluating advanced artificial intelligence models for safety and security.

Current National Institute of Standards and Technology NIST Director Arvind Raman will serve as acting CAISI Director following Fall’s departure while continuing to oversee the Commerce Department office responsible for the institute, the Daily Signal reported, citing two people familiar with the matter.

A Commerce Department spokesperson who spoke to the publication did not disclose a reason for the resignation.

Fall assumed leadership of CAISI in April after the Trump administration reorganized the former US AI Safety Institute under NIST. The institute develops methodologies for evaluating frontier AI models and works with AI developers on voluntary technical assessments covering areas such as cybersecurity, model misuse, reliability and other risks associated with increasingly capable AI systems.

The leadership change comes as governments and AI companies continue developing technical approaches for evaluating frontier AI models while enterprises expand deployments of generative AI and agentic AI across business operations.

In recent months, the Commerce Department has taken a more active role in AI policy involving advanced models, placing greater attention on how the federal government evaluates technologies with potential national security implications.

Continuity matters more than personalities

CAISI works with AI developers such as Anthropic, Google’s DeepMind and OpenAI on voluntary evaluations of frontier AI models and develops methodologies for testing model capabilities and risks. The institute does not regulate AI developers or certify commercial AI systems.

For enterprises, those evaluations are one source of technical information alongside vendors’ own testing, third-party security assessments and internal AI governance programs.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said enterprises should focus less on the individual leading the institute and more on whether its technical work continues with the same level of consistency and transparency.

“Leadership churn at CAISI weakens the signal long before it weakens the science,” Gogia said. “The testing has not stopped. Its authority simply does not travel as cleanly once the leadership does not.”

According to Gogia, the more important question for enterprises is not whether the institute’s evaluation work will continue but whether the processes supporting those evaluations remain stable.

“The instinct is to ask whether the pipeline is breaking,” he said. “The more useful question is where the pipeline now sits.”

Enterprises still carry the burden of AI governance

Gogia said organizations should continue treating government-led AI evaluations as one input into their governance processes rather than as evidence that a model is inherently safe for enterprise deployment.

“A government evaluation was always a signal, never a certificate,” he said. “A signal loses value the moment its issuer becomes unpredictable.”

He said enterprises should instead monitor whether CAISI maintains consistent evaluation methodologies, continues publishing technical findings and preserves continuity within its research teams under interim leadership.

“The name on the door is not the signal. The behaviour underneath it is,” Gogia said.

Gogia also cautioned against linking Fall’s resignation to recent Commerce Department actions involving AI policy or export controls, noting that there is no public evidence connecting the two.

“CAISI evaluates; it does not enforce export controls, because it holds no such power,” he said. “This is not a testing body reaching for enforcement. It is enforcement reaching past the testing body.”

With Raman assuming the role on an interim basis, the next significant milestone for enterprises will be the appointment of a permanent director, and whether the institute’s evaluation programs continue without disruption, the analyst said.

Gogia said the successor’s mandate may prove more important than the individual selected.

“A CAISI result is not a safe harbour,” he said. “It informs an obligation; it does not discharge one.” NIST did not immediately respond to a request for comment.

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.

AMD executives took to the stage at its Advancing AI 2026 event in San Francisco today to detail the company’s next generation of AI infrastructure solutions, from Instinct MI455X AI accelerator GPUs and 6th Gen EPYC “Venice” CPUs, to Pensando networking, ROCm.AI software and its Helios rack-scale platform that ties it all together.

AMD has been working towards rack-scale AI system solutions for years. Its ZT Systems acquisition last year added valuable engineering talent and intellectual property that is now finally bearing the real fruits. Its Helios AI platform is a major platform evolution for AMD, with shipments scheduled to begin in the second half of this year (which is here and now).

The announcements at Advancing AI show how the company has engineered its AI platform solutions for large reasoning models, sustained inference and agentic workflows. These workloads pressure memory capacity, data movement, networking and CPU orchestration. AMD’s approach is to keep as much data close to the compute engines as possible and move it more efficiently throughout the system, but there’s deeper nuance here that’s obvious versus AMD’s chief rival, NVIDIA.  

AMD’s MI455X targets the AI memory wall

The Instinct MI455X GPU is the compute engine that fuels the Helios rack, and the first GPU based on AMD’s new CDNA 5 architecture. Built with a modular mix of 2nm and 3nm chiplets, it carries 432GB of HBM4 and 23.3TB/s of peak memory bandwidth.

Compared to AMD’s current MI355X, the MI455X offers 1.5 times the memory capacity, up to 2.9 times the peak memory bandwidth and up to four times the peak matrix performance with MXFP4 and MXFP8 data types, which are lower-precision numerical formats designed to accelerate AI processing while reducing memory demands. With MXFP6 (6-bit floating point), performance is rated at up to twice that of MI355X.

AMD also shared some actual, measured internal results using production silicon. The company claims MI455X delivers 3.8 times higher FP8 decode performance, 3.5 times more measured FP4 compute performance and between 2.5 and 3.5 times more networking bandwidth than MI355X, depending on the transfer path tested. Those figures provide more context than just numerical specifications, though they remain AMD-provided comparisons that will need independent validation.

The architectural choices behind the numbers are important. Reasoning models and long context windows require sizeable KV caches for maintaining AI attention states, while mixture-of-experts models frequently move large amounts of data across accelerators. MI455X should let more model data, activation states and cache remain local. New dedicated IP in hardware can transfer data while the GPU continues processing, and expanded cache and multicast capabilities are designed to reduce redundant data movement to further improve efficiency.

The aforementioned lower-precision formats can also raise throughput and reduce memory use, but model developers still have to determine where they can be applied without unacceptable accuracy loss.

AMD’s Helios rack takes aim at Vera Rubin

Helios is AMD’s primary rack-scale competitor to NVIDIA’s Vera Rubin platform. Each liquid-cooled rack combines 72 MI455X GPUs, 18 single-socket Venice host CPUs and Pensando networking technologies.

In its most complete, premium configuration, AMD rates Helios for 2.9 exaflops of low-precision AI compute, with 31TB of aggregate HBM4 capacity, 1.7PB/s of memory bandwidth, 260TB/s of bidirectional scale-up bandwidth and 43TB/s of scale-out bandwidth.

These are formidable figures, but they are technical specifications rather than actual application benchmarks. The more consequential development is AMD’s move from collections of eight-GPU servers to a 72-GPU shared-memory domain. Models too large for one node can operate across the rack without treating every exchange as a scale-out networking transaction, which benefits large-model inference as well as training.

AMD uses UALink over Ethernet, or UALoE, for an open standard scale-up fabric. Each MI455X provides 3.6TB/s of bidirectional scale-up bandwidth, while the complete rack delivers all-to-all connectivity through a single switch layer. AMD also claims six times more scale-out bandwidth per GPU than MI355X when MI455X is configured with three Pensando Vulcano 800 AI NICs.

While open standards give cloud providers more control over suppliers and system design, AMD and its partners now have to prove those components can deliver the predictable performance, reliability and deployment experience customers expect from a tightly controlled, more vertically integrated platform.

Finally, AMD designed Helios with automatic rerouting around failed links, virtual rack partitions, tray-level serviceability and rack-wide power, cooling and health monitoring. Major hyperscalers and potentially large-scale enterprise customers will likely key in on these capabilities, which can affect the availability, total cost and consistency of the AI services they consume.

Kind of like cowbell, AMD Venice gives agentic AI more CPU

AMD’s agentic CPU messaging regarding its upcoming Venice-based EPYC processors is mostly marketing speak, but the underlying requirement is very real. An AI agent can invoke retrieval, databases, security checks, code execution and other tools before a GPU generates a response. Running many agents concurrently increases the amount of conventional compute requirements surrounding the accelerators.

Venice scales to 256 Zen 6 cores with support for 512 threads, 16 memory channels, up to 1GB of L3 cache per socket, along with PCIe 6.0 and CXL 3.1 connectivity. AMD is also offering several Venice configurations for other applications, including general-purpose servers, high-frequency workloads, GPU hosts and high-density CPU sandbox systems used to execute agent tools.

Treating the CPU solely as a GPU host understates its role. Gateways, tokenization, vector search, databases and short-lived code execution stress different mixes of per-core performance, thread count, memory bandwidth and I/O. Specifically, AMD’s internal testing shows Venice significantly outperforming its current EPYC 9965 Turin CPU across five parts of the agentic AI pipeline, including gateway processing, context assembly, vector search, enterprise applications and short-lived tool execution. Individual gains vary by workload, but AMD details the overall generational improvement at up to a 1.7 times lift. As with the MI455X figures though, these comparisons come from AMD and will require independent validation.

Pensando networking and ROCm software advance

Keeping GPUs fed with data and coordinating traffic across racks directly affects utilization and operating costs. In fact, GPU utilization is a pretty sad state of affairs currently for some of the major frontier model providers.

As such, Pensando networking has become central to AMD’s roadmap. Helios can connect each MI455X to as many as three 800Gbps Vulcano AI NICs, while Salina DPUs handle front-end networking and infrastructure services.

On the software side, which is an equally critical component, AMD also introduced ROCm.AI, an AI-assisted development layer due to arrive in August. It includes reusable skills for coding agents, simplified management and Hyperloom, which can profile workloads, tune serving configurations, modify kernels and validate results.

These tools address two persistent AMD challenges: developer efficiency and ease of use, and software tuning. Automated optimization still has to produce repeatable gains without creating hard-to-maintain code, however. And while ROCm has progressed significantly over the last few years, NVIDIA’s CUDA retains an advantage in maturity, tooling and developer familiarity.

Customer commitments underscore rack-scale confidence

AMD now has commitments that give its MI450 generation and Helios considerably more weight. Meta and OpenAI have announced multi-generation agreements composed of up to 6GW of AMD compute capacity, with initial 1GW deployments planned for the second half of 2026.

Oracle plans a 50,000-GPU public cloud cluster beginning in the third quarter, while Microsoft will deploy Helios for Azure AI inference. Finally, just before the AMD event, Anthropic announced a strategic partnership for up to 2 Gigawatts of AMD-fueled AI compute, with its first gigawatt expected online in the first half of 2027.

Commitments of this scale reflect confidence in more than just MI455X performance. These customers are evaluating the complete architecture, including Venice CPUs, Pensando networking, ROCm software, rack integration, serviceability and AMD’s ability to deliver and execute across multiple product generations.

There is some financial alignment behind the agreements as well. AMD issued OpenAI performance-based warrants and committed to investing up to $5 billion in Anthropic. That context matters when evaluating these deals as market validation, but these planned deployments are substantial nonetheless and put Helios on a much stronger foundation as it begins shipping.

AMD expands its robotics and embedded foundation

AMD also expanded its physical AI portfolio, building on credible traction from its Xilinx-derived Kria adaptive system-on-modules and embedded technologies that are already powering robotics, machine vision and industrial automation applications.

The new Ryzen AI Embedded X100 combines up to 16 Zen 5 CPU cores, integrated Radeon graphics, a second-generation NPU and as much as 128GB of unified LPDDR5X memory shared across its compute engines. To me this looks a lot like a repackaging and optimization of the company’s Strix Halo platform, but with specific optimizations for the embedded space. Regardless, AMD is pairing X100 with the Kria AI Robotics Developer Platform, which includes a System Module or SOM, and a new Robotics Partner Network spanning hardware, software and platform providers.

Samples began shipping in June, with full production expected in the fourth quarter. This broader objective is to give developers a path across AMD x86 CPUs, GPUs, NPUs and FPGAs for real-time autonomous systems, rather than requiring them to assemble those hardware engines and software components independently.

Execution for AMD is now the test

AMD has assembled a credible platform for the burgeoning agentic AI market that’s blowing up currently with no signs of stopping. MI455X addresses memory and data movement, Venice handles dense agentic CPU workloads, Pensando networking connects global system resources, and ROCm.AI addresses software complexity. Finally, Helios assembles these components into a true competitive threat for NVIDIA’s latest Vera Rubin platform.

AMD’s open architecture may appeal to customers seeking supplier choice, but openness must also translate into reliable deployments, competitive total cost and software that does not require a significant rip-up. NVIDIA enters this cycle with a stronger ecosystem and far more rack-scale deployment experience. The true test will be how easily and reliably customers can integrate, operate and maintain these AMD solutions at scale.

As it stands, AMD now has major customers and a clearly defined architecture with systems engineering expertise behind it. Delivering Helios on schedule and showing that its performance claims translate into a real production workload throughput advantage and total cost of ownership gains will determine how much the competitive gap narrows. And of course, this is in a market that is clamoring for ever-more compute resources with a seemingly insatiable demand for AI services and capacity. That’s an environment for big iron success. Now AMD just has to deliver optimized, turnkey AI platforms. This is far easier said than done, but time will soon tell as deployments take shape this year.

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

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

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

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

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

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

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

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

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

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

The full-stack CIO: Leading with clarity

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

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

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

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

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

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

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

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

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

Reducing organizational friction

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

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

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

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

Operating model as strategy enabler

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

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

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

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

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

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

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

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

Closing the gap between strategy and execution

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

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

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

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

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

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

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

In public-sector and regulated-cloud work, I learned that sovereignty rarely starts as a national strategy. It starts as an auditor’s question: Who can prove where the data went, which system made the decision and what changes when the vendor or infrastructure does? That question is now moving into AI, and most sovereign-AI debates answer the wrong version of it.

They ask whether a country can build its own model on domestic data and hardware. For the United States and China, which together hold more than 90% of global AI data-center capacity, per a January 2026 Tony Blair Institute analysis, that question is worth asking. However, for almost every other government, it is the wrong place to start. The operative question is narrower: Once AI is embedded in public services, who controls the stack?

The 5 layers of public-sector control

For a CIO, sovereign AI means enforceable control across the AI lifecycle; model ownership is a separate question. Control has five layers:

• Data control: Where sensitive public data sits, and whether it can train a vendor’s model.
• Model control: Which models clear which workloads, and under what validation.
• Infrastructure control: Whether critical workloads run in approved environments.
• Operational control: Whether AI-assisted actions are logged, monitored and reversible.
• Vendor control: Whether the agency keeps portability, audit rights and a real exit.

Those five layers are the control plane for public-service AI. Floyd Dcosta recently made the enterprise case in “AI without sovereignty is just outsourced intelligence”: capability is what a tool can do; authority over how and when it does it is something a buyer can quietly lose. For public services, losing that authority plays out in the public eye.

Public-sector AI risk differs from enterprise risk. A retailer’s bad recommendation costs a sale; a government’s AI touches benefits, tax enforcement, policing and emergency response, raising the bar to due process, records retention and continuity of operations. A government that cannot reconstruct an AI-assisted decision lacks operational sovereignty, even in a domestic data center.

Evaluating risk: Concentration, jurisdiction and shadow AI

Foreign dependency is a real risk, but the exposure that matters is a sudden cutoff: A model you cannot audit, switch or exit, shut off by someone else’s order. A vendor’s nationality is a poor guide to that risk; control is.  Two markers matter. The first is concentration. In July 2024, a single faulty CrowdStrike update crashed about 8.5 million Windows machines, disrupting airlines, hospitals, banks and governments worldwide. No attacker was involved; one homogeneous dependency failed everywhere at once. The lesson points away from vendor nationality and toward uniformity as the fault line, making portability and provider diversity resilience controls.

The second is jurisdiction. In June 2025, Microsoft’s legal director for France told a Senate inquiry, under oath, that it could not guarantee that French public-sector data, even in French data centers, would be protected against US demands under the 2018 CLOUD Act. No such request had been made, and EU data has stayed in the EU since January 2025; senators called the assurance purely declarative. For the most sensitive data, residency does not equal control; the parent’s jurisdiction can matter as much as the server’s. Three US hyperscalers hold about 70% of the European cloud market, while European providers’ share fell from 29% in 2017 to roughly 15%. Concentration plus jurisdiction is the exposure a CIO must price. I have watched teams treat vendor selection as the moment risk was solved; it rarely was.

The wrong response is self-isolation. Most countries will never build frontier models, advanced chips, hyperscale clouds and talent pipelines at once; the Tony Blair Institute calls full self-sufficiency “too expensive, too slow and, for most countries, simply impossible.” The better test is workload sensitivity. Low-risk uses, such as drafting, translation and summarization, can run on commercial platforms with controls; high-risk uses, such as benefits eligibility, fraud investigation and healthcare triage, demand stricter control over data, model behavior and auditability.

Mandating domestic-only provision before a competitive option exists inverts sovereignty. Europe 2031, a five-year scenario from June 2026 by European technologists and policy researchers, illustrates the failure mode: A 2027 “buy European” mandate lands as offensive cyber capability spreads, and agencies that switched to weaker providers are locked out and paying ransoms. The scenario is fiction; the mechanism is not. Leverage comes from being indispensable, not half-hearted self-sufficiency. The closer-to-home effect is shadow AI: Mandate an inferior sanctioned tool and staff bypass it, the way shadow IT grows up around tools people find too slow. A rule that pushes sensitive work into ungoverned shadow AI reduces control instead of adding it.

Regulation and data-residency rules belong in any serious strategy, but carry failure modes. Blanket localization raises hosting costs and slows adoption without guaranteeing control, and a “sovereign cloud” on a foreign parent’s stack can amount to sovereignty theater. The more useful pattern tiers requirements by sensitivity. India’s BHASHINI shows the application layer done well: A public platform serving 100 million-plus inferences a month across 22-plus languages on a vendor- and cloud-agnostic design that keeps data and switching rights public. Sovereignty resides in the portability, not in a national model.

Building an operational sovereignty strategy

Public trust is the constraint sovereignty rhetoric tends to skip. The OECD’s 2025 review of government AI warns that opaque systems make AI-assisted decisions hard to explain and can give public servants false confidence in tools that fail quietly. State-controlled AI is the same problem from the other side: A government that deploys models against its own citizens without audit or record has gained control and lost accountability. An agency that can log, explain and reverse an AI-assisted action can defend it to citizens, courts, auditors and elected officials. If it cannot, it has bought access and called it sovereignty.

None of this is new. AI sovereignty repeats earlier fights over cloud, telecom, semiconductors and cybersecurity. Europe’s flagship cloud project, GAIA-X, became a cautionary tale; the Dutch technologist Bert Hubert called it an “expensive distraction” that produced no European cloud, the familiar result of ambition without absorptive capacity. Cloud taught governments that outsourcing infrastructure does not outsource accountability; telecom, that vendor dependency becomes strategic exposure; chips, that supply chains matter before a crisis; cybersecurity, that trust must be verified continuously. AI inherits all four at once.

Over the next five to ten years, some countries will build national platforms, more will build trusted cloud and trusted model regimes, and most will run hybrids that pair domestic data control with global model access. Trade policy will harden those choices: Export controls on compute and data-localization rules will pull the vendor market into blocs that track alliances more than open markets. For a CIO, that turns a vendor and hosting decision into a five-year bet on whose rules and supply chains will still hold. The ones that succeed will treat sovereignty as an operating requirement, backed by leverage, not a slogan. Start with the control plane before the model: Most agencies will never own the model, and the controls are what decide whether the AI they do run stays accountable. Even when procurement policy is dictated from above, these questions remain within the CIO’s authority:

1. Can we classify AI workloads by public-service risk?
2. Can we prove where sensitive data goes across training, retrieval, inference, logging and retention?
3. Can we restrict which models are approved for which data classes and functions?
4. Can we reconstruct an AI-assisted action in enough detail to explain it?
5. Can we change providers without losing continuity or institutional knowledge?
6. Can we explain the system to citizens, regulators, auditors and elected officials?

A “no” to any of these does not mean the agency lacks AI. It means the agency has access it does not yet control. Public institutions can use global innovation without surrendering public authority, but only once they know what to hold, what to rent and where dependency turns into risk.

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

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

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

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

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

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

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

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

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

A steep learning curve

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

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

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

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

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

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

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

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

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

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

Routing

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

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

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

Harness

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

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

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

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

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

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

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

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

Specialization

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

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

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

Over the past few years, I have learned that basic prompts produce inconsistent, hallucination-prone results that no executive would trust in production. What turned the tide was my move to advanced prompting techniques. These weren’t theoretical experiments; they became a practical foundation for reliable, measurable outcomes. I want to share the techniques that consistently delivered the biggest gains in my projects, complete with real before-and-after examples, copy-paste templates, lessons from failures and guidance on when to evolve beyond prompting to agentic systems.

Why advanced prompting still matters in enterprise settings

Sophisticated prompting remains essential for control, reliability and compliance. If you “ask nicely” and hope for the best, you need deterministic behavior, auditable reasoning and minimal risk of hallucination. Here’s what worked for me.

1. Chain-of-Thought (CoT) and its variants: Unlocking step-by-step reasoning

The problem: Models would jump to conclusions on complex analysis tasks, especially involving data interpretation or multi-step logic.

What I did: I started explicitly instructing the model to “think step by step” and show its reasoning.

Before (basic prompt): “Analyze last quarter’s sales data and recommend three actions.”

After (CoT prompt):

“You’re a senior business analyst. Analyze the following sales data step by step: [data]. First, identify the key trends. Second, calculate the rates and anomalies. Third, link findings to business context. Finally, recommend the three prioritized actions with expected impact. Explain your reasoning at each step.”  

Results: Accuracy and depth improved dramatically.

Variants that worked well: Self-consistency. I ran the same CoT prompt multiple times and took the majority consensus. This reduced variability significantly.

Template you can use:

You are [expert role]. Solve this problem by thinking step by step.

[Task or question]

For each step:

1. State your observation or calculation.

2. Explain the implication.

3. Proceed only when confident.

Final answer in this format: [structured output]

2. Tree-of-Thoughts (ToT): Exploring multiple reasoning paths

For truly complex decisions such as resource allocation or risk assessment, linear CoT isn’t enough. Tree-of-Thoughts lets the model generate and evaluate multiple branches.

Example: I was helping a client evaluate three potential vendor platforms for an AI deployment. A standard prompt gave a superficial comparison. With ToT

Prompt Snippet:

Explore three different reasoning paths for selecting the best vendor platform:

Path 1: Focus on cost and scalability.

Path 2: Focus on security, compliance and integration.

Path 3: Focus on innovation and long-term roadmap.

For each path, evaluate pros/cons against our requirements [list].

Then, compare the paths and recommend the strongest overall option with justification.

Outcome: The model surfaced nuanced trade-offs (e.g., one vendor had superior security, but higher integration cost).

When to use: Strategic planning, troubleshooting or scenarios with high uncertainty and multiple viable approaches.

3. ReAct (Reason+ Act) and prompt chaining: Moving toward agentic behavior

One of the biggest leaps I have noticed comes from combining reasoning with tool use and chaining prompts.

ReAct example: (used in data analytics workflow)

You are an AI analyst with access to tools. For the query below:

1. Reason about what information you need.

2. Choose the appropriate tool or action.

3. Observe the result.

4. Repeat until you can answer confidently.

Query: [user request]

In practice, I chained this with retrieval tools. One automated quarterly compliance reporting; the system reasoned about required data, pulled relevant records, validated them, and generated the reports.

4. Meta-prompting and self-reflection: Letting the model improve itself

Use the model to refine its own prompt. This is a huge time-saver.

You are an expert prompt engineer. Improve the following prompt for clarity, structure and effectiveness with [target model]. Make it more precise while preserving intent.

Original prompt: [paste]

Provide the improved version and explain your changes.

Self-reflection loops (asking the model to critique its own output and revise) are a game-changer for content generation and code-review tasks.

5. Multimodal and structured output techniques

With vision-enabled models, I started combining text with images (e.g., uploading architecture diagrams or dashboards).

Tip from experience: Be extremely specific in describing what the models should focus on.

Best practices I learned the hard way

• Start simple, then layer complexity: Over-engineered prompts from Day One usually backfire.
• Model specific tuning: Some models respond better to XML delimiters; others to explicit reasoning.
• Evaluation and versioning: Treat prompts like code if you track versions and run automated evals.
• Security guardrails: Always include instructions against prompt injections and respect data boundaries.
• When to stop prompting: For repetitive, high-stakes workflows, move to full agents or an orchestration framework.

Final takeaways for technical leaders

Advanced prompt engineering has now become a core competency for anyone responsible for enterprise AI outcomes. Start by picking one technique and apply it rigorously to a real business problem. Document before/ after and you will notice why it’s worth mastering.

The field continues evolving towards more automated and agentic systems, but the ability to precisely direct AI reasoning remains foundational.

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

Late in a large enterprise SAP transformation, the strategic governance conversations began to drift. Instead of executive decisions, we found ourselves debating whether the program needed dedicated testing, whether cutover required a full weekend, whether twenty Agile teams really needed coordination support and whether offshore resources were adding value at all.

The questions were not coming from the delivery teams. They were coming from the executive sponsor.

The sponsor had recently been elevated into a senior leadership role and had never sponsored a technology transformation at this scale. The challenge was not authority. The sponsor had every right to ask any question they wanted. The challenge was that strategic governance had quietly turned into a debate about delivery practices, because the sponsor did not yet have the transformation context to focus the conversation anywhere else.

This is not a story about a bad sponsor. The executive in this case was a capable senior leader with strong judgment and authentic intent. They had been placed into a role they had not yet been prepared for, and the pattern that followed was structural, not personal. It is one of the more common patterns I have observed across enterprise transformation programs, and one of the most consistently misdiagnosed.

Most program failures are not execution failures. They are sponsor mismatches.

When governance becomes a debate about delivery practices

When the sponsor does not understand what an enterprise transformation actually requires, governance forums stop functioning as decision bodies and start functioning as practice debates.

You see it in the questions that get asked. Why do we need a dedicated testing phase? Can the Build timeline be compressed? Why does cutover need a full weekend? Why do we need more Scrum Masters across 20 product teams? Can the US team simply work longer hours instead of using offshore resources? On one program, the sponsor suggested shifting the entire project’s working hours to India time, despite roughly 85 percent of the delivery organization being based in the United States.

None of these questions are unreasonable in isolation. Each one targets a real cost or timeline pressure. The problem is what is missing underneath them: an understanding of the operational risks the original choices were designed to mitigate.

When sponsors ask delivery-practice questions without that context, the program leadership team ends up defending the work instead of advancing it. Decision velocity drops. Trust between the program and its sponsor erodes. Senior delivery talent disengages from governance forums where the conversation never reaches the decisions they need made. What looks from the outside like an active sponsor producing engagement is, from inside the program, an active drain on the cycles needed to deliver.

The compounding cost is not unique to any single program. PMI’s research on executive sponsorship consistently identifies sponsor engagement quality, rather than sponsor presence alone, as one of the strongest predictors of project success. The visible symptom is debate. The actual cost is unmade decisions.

Authority is rarely the issue. Literacy is

When transformations stall under a mismatched sponsor, the diagnostic instinct is to question the sponsor’s authority. Are they senior enough? Do they have the cross-functional reach? Can they unblock?

In most of the programs I have led or advised, authority was not the limiting factor. The sponsor in the SAP program above had ample authority. They could unblock any decision the program needed. What had not been developed was the transformation literacy to know which decisions mattered, which were technical noise and which were execution risks that should not be optimized away.

This is what I have come to think of as the literacy problem. Sponsors elevated into transformation roles often have deep functional expertise (finance, operations, business unit leadership) but limited exposure to the distinct functions of PMO, organizational change management, agile delivery, testing and cutover, and how each one reduces a specific category of implementation risk. They are not expected to be SAP configuration experts. But they need enough transformation literacy to recognize which questions actually belong in a steering committee.

Harvard Business Review’s research on effective executive sponsorship has emphasized that sponsorship effectiveness depends as much on judgment as on authority. Judgment is where literacy becomes operational. A sponsor with authority but limited transformation literacy will optimize for speed and cost in ways that consistently underestimate risk. A sponsor with both will make the tradeoffs the program actually needs.

Prosci’s longstanding benchmark studies on change management have ranked active and visible executive sponsorship as the single greatest contributor to change success for two decades. The word that matters in that finding is active. Active sponsorship without transformation literacy can introduce real cost. Not because the sponsor is acting against the program, but because the optimization choices they make are based on incomplete information about what the program is built to protect against.

Shift the conversation from delivery practices to business risk

When the sponsor relationship is already in place and cannot be changed, the program leadership team has one move that consistently works: shift the conversation.

On the SAP program above, we stopped explaining why the testing phase existed. We started explaining the business risk of reducing it. We stopped debating the number of Scrum Masters. We started connecting delivery capacity to coordination across more than twenty Agile teams and the business cost of losing that coordination. We reframed offshore support as a way to maintain delivery momentum around the clock rather than asking the U.S. team to sustain fifteen-hour days.

The shift is from defending delivery practice to explaining business risk. The sponsor does not need to understand why testing takes the time it does. They need to understand what the program is exposed to if testing is compressed. They do not need to know how many Scrum Masters are statistically optimal for twenty Agile teams. They need to know what coordination breaks when the number is wrong.

This reframing accomplishes two things. First, it brings the conversation back to the level at which sponsors actually make decisions: tradeoffs between business outcomes and business risks. Second, it builds transformation literacy in the sponsor over time, almost as a byproduct. By the third or fourth iteration of business-risk-framed conversations, the sponsor begins to ask the right questions on their own.

In practice, this happens through small but deliberate moves. When the sponsor asks why a phase needs the time it takes, the program lead names two or three things that could go wrong if the time is cut and what each would cost the business. When the sponsor asks why a role is needed, the program lead names the work that would not get done without it. Every delivery-practice question gets converted into a business-risk answer.

The program leadership team’s job is not to make the sponsor an expert in SAP delivery. It is to provide enough transformation context so that executive decisions reflect both business priorities and implementation realities.

There are a few phrases I have used with executive sponsors over the years that capture the underlying issue. The sharpest one:

If the decision has to go above the sponsor, they are not the sponsor.

Sponsorship is defined by what the sponsor can decide without asking someone else. That is the test. Anything else is the appearance of sponsorship, not the substance.

For CIOs supporting enterprise transformation, the implication is direct. Sponsor selection, or sponsor preparation when selection is not an option, is not a hierarchy question. It is a transformation capability question. The same execution discipline that goes into defining decision rights, structuring governance and protecting delivery momentum should apply, with equal rigor, to assessing sponsor fit and building sponsor literacy before the program begins.

A sponsor does not need to be the technical expert. They do need to know when to trust the people who are.

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

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

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

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

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

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

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

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

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

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

Unfortunately, cyber attackers do not read dashboards.

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

The problem is rarely a lack of effort.

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

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

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

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

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

This is the second issue that should concern every CEO.

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

Very rarely do they stop to redesign how cybersecurity operates.

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

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

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

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

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

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

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

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

That imbalance should worry every CEO.

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

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

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

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

Together, they fundamentally change the dynamics of cybersecurity.

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

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

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

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

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

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

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

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

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

Leadership will determine who succeeds

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

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

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

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

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

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

These questions will increasingly determine organizational success.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Unfortunately, cyber attackers do not read dashboards.

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

The problem is rarely a lack of effort.

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

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

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

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

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

This is the second issue that should concern every CEO.

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

Very rarely do they stop to redesign how cybersecurity operates.

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

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

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

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

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

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

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

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

That imbalance should worry every CEO.

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

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

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

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

Together, they fundamentally change the dynamics of cybersecurity.

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

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

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

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

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

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

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

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

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

Leadership will determine who succeeds

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

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

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

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

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

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

These questions will increasingly determine organizational success.

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

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

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

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

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

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

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

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

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

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

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

It didn’t change the meal.

The framework was never the hard part

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

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

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

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

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

What building production agents actually taught me

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

Context beats model choice

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

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

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

Failure is where the real work is

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

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

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

Identity is the real security boundary

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

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

The surprises weren’t technical

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

Build for change, not for today’s winner

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

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

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

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

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

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

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

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

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

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

Late in a large enterprise SAP transformation, the strategic governance conversations began to drift. Instead of executive decisions, we found ourselves debating whether the program needed dedicated testing, whether cutover required a full weekend, whether twenty Agile teams really needed coordination support and whether offshore resources were adding value at all.

The questions were not coming from the delivery teams. They were coming from the executive sponsor.

The sponsor had recently been elevated into a senior leadership role and had never sponsored a technology transformation at this scale. The challenge was not authority. The sponsor had every right to ask any question they wanted. The challenge was that strategic governance had quietly turned into a debate about delivery practices, because the sponsor did not yet have the transformation context to focus the conversation anywhere else.

This is not a story about a bad sponsor. The executive in this case was a capable senior leader with strong judgment and authentic intent. They had been placed into a role they had not yet been prepared for, and the pattern that followed was structural, not personal. It is one of the more common patterns I have observed across enterprise transformation programs, and one of the most consistently misdiagnosed.

Most program failures are not execution failures. They are sponsor mismatches.

When governance becomes a debate about delivery practices

When the sponsor does not understand what an enterprise transformation actually requires, governance forums stop functioning as decision bodies and start functioning as practice debates.

You see it in the questions that get asked. Why do we need a dedicated testing phase? Can the Build timeline be compressed? Why does cutover need a full weekend? Why do we need more Scrum Masters across 20 product teams? Can the US team simply work longer hours instead of using offshore resources? On one program, the sponsor suggested shifting the entire project’s working hours to India time, despite roughly 85 percent of the delivery organization being based in the United States.

None of these questions are unreasonable in isolation. Each one targets a real cost or timeline pressure. The problem is what is missing underneath them: an understanding of the operational risks the original choices were designed to mitigate.

When sponsors ask delivery-practice questions without that context, the program leadership team ends up defending the work instead of advancing it. Decision velocity drops. Trust between the program and its sponsor erodes. Senior delivery talent disengages from governance forums where the conversation never reaches the decisions they need made. What looks from the outside like an active sponsor producing engagement is, from inside the program, an active drain on the cycles needed to deliver.

The compounding cost is not unique to any single program. PMI’s research on executive sponsorship consistently identifies sponsor engagement quality, rather than sponsor presence alone, as one of the strongest predictors of project success. The visible symptom is debate. The actual cost is unmade decisions.

Authority is rarely the issue. Literacy is

When transformations stall under a mismatched sponsor, the diagnostic instinct is to question the sponsor’s authority. Are they senior enough? Do they have the cross-functional reach? Can they unblock?

In most of the programs I have led or advised, authority was not the limiting factor. The sponsor in the SAP program above had ample authority. They could unblock any decision the program needed. What had not been developed was the transformation literacy to know which decisions mattered, which were technical noise and which were execution risks that should not be optimized away.

This is what I have come to think of as the literacy problem. Sponsors elevated into transformation roles often have deep functional expertise (finance, operations, business unit leadership) but limited exposure to the distinct functions of PMO, organizational change management, agile delivery, testing and cutover, and how each one reduces a specific category of implementation risk. They are not expected to be SAP configuration experts. But they need enough transformation literacy to recognize which questions actually belong in a steering committee.

Harvard Business Review’s research on effective executive sponsorship has emphasized that sponsorship effectiveness depends as much on judgment as on authority. Judgment is where literacy becomes operational. A sponsor with authority but limited transformation literacy will optimize for speed and cost in ways that consistently underestimate risk. A sponsor with both will make the tradeoffs the program actually needs.

Prosci’s longstanding benchmark studies on change management have ranked active and visible executive sponsorship as the single greatest contributor to change success for two decades. The word that matters in that finding is active. Active sponsorship without transformation literacy can introduce real cost. Not because the sponsor is acting against the program, but because the optimization choices they make are based on incomplete information about what the program is built to protect against.

Shift the conversation from delivery practices to business risk

When the sponsor relationship is already in place and cannot be changed, the program leadership team has one move that consistently works: shift the conversation.

On the SAP program above, we stopped explaining why the testing phase existed. We started explaining the business risk of reducing it. We stopped debating the number of Scrum Masters. We started connecting delivery capacity to coordination across more than twenty Agile teams and the business cost of losing that coordination. We reframed offshore support as a way to maintain delivery momentum around the clock rather than asking the U.S. team to sustain fifteen-hour days.

The shift is from defending delivery practice to explaining business risk. The sponsor does not need to understand why testing takes the time it does. They need to understand what the program is exposed to if testing is compressed. They do not need to know how many Scrum Masters are statistically optimal for twenty Agile teams. They need to know what coordination breaks when the number is wrong.

This reframing accomplishes two things. First, it brings the conversation back to the level at which sponsors actually make decisions: tradeoffs between business outcomes and business risks. Second, it builds transformation literacy in the sponsor over time, almost as a byproduct. By the third or fourth iteration of business-risk-framed conversations, the sponsor begins to ask the right questions on their own.

In practice, this happens through small but deliberate moves. When the sponsor asks why a phase needs the time it takes, the program lead names two or three things that could go wrong if the time is cut and what each would cost the business. When the sponsor asks why a role is needed, the program lead names the work that would not get done without it. Every delivery-practice question gets converted into a business-risk answer.

The program leadership team’s job is not to make the sponsor an expert in SAP delivery. It is to provide enough transformation context so that executive decisions reflect both business priorities and implementation realities.

There are a few phrases I have used with executive sponsors over the years that capture the underlying issue. The sharpest one:

If the decision has to go above the sponsor, they are not the sponsor.

Sponsorship is defined by what the sponsor can decide without asking someone else. That is the test. Anything else is the appearance of sponsorship, not the substance.

For CIOs supporting enterprise transformation, the implication is direct. Sponsor selection, or sponsor preparation when selection is not an option, is not a hierarchy question. It is a transformation capability question. The same execution discipline that goes into defining decision rights, structuring governance and protecting delivery momentum should apply, with equal rigor, to assessing sponsor fit and building sponsor literacy before the program begins.

A sponsor does not need to be the technical expert. They do need to know when to trust the people who are.

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

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

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

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

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

What AI-RAN actually is

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

Several pillars stand out:

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

Why AI-RAN matters for operators

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

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

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

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

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

Nokia’s differentiation strategy

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

Several differentiators emerge:

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

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

How AI-RAN unlocks new revenue

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

Examples include:

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

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

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

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

Adoption path and reality check

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

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

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

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

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

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

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

1. From reactive patching to proactive prevention 

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

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

2. Eliminating the “agentic blind spot” 

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

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

3. Machine-speed detection and “attack storylines” 

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

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

4. Surgical and autonomous response 

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

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

Summary

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

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

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

AMD executives took to the stage at its Advancing AI 2026 event in San Francisco today to detail the company’s next generation of AI infrastructure solutions, from Instinct MI455X AI accelerator GPUs and 6th Gen EPYC “Venice” CPUs, to Pensando networking, ROCm.AI software and its Helios rack-scale platform that ties it all together.

AMD has been working towards rack-scale AI system solutions for years. Its ZT Systems acquisition last year added valuable engineering talent and intellectual property that is now finally bearing the real fruits. Its Helios AI platform is a major platform evolution for AMD, with shipments scheduled to begin in the second half of this year (which is here and now).

The announcements at Advancing AI show how the company has engineered its AI platform solutions for large reasoning models, sustained inference and agentic workflows. These workloads pressure memory capacity, data movement, networking and CPU orchestration. AMD’s approach is to keep as much data close to the compute engines as possible and move it more efficiently throughout the system, but there’s deeper nuance here that’s obvious versus AMD’s chief rival, NVIDIA.  

AMD’s MI455X targets the AI memory wall

The Instinct MI455X GPU is the compute engine that fuels the Helios rack, and the first GPU based on AMD’s new CDNA 5 architecture. Built with a modular mix of 2nm and 3nm chiplets, it carries 432GB of HBM4 and 23.3TB/s of peak memory bandwidth.

Compared to AMD’s current MI355X, the MI455X offers 1.5 times the memory capacity, up to 2.9 times the peak memory bandwidth and up to four times the peak matrix performance with MXFP4 and MXFP8 data types, which are lower-precision numerical formats designed to accelerate AI processing while reducing memory demands. With MXFP6 (6-bit floating point), performance is rated at up to twice that of MI355X.

AMD also shared some actual, measured internal results using production silicon. The company claims MI455X delivers 3.8 times higher FP8 decode performance, 3.5 times more measured FP4 compute performance and between 2.5 and 3.5 times more networking bandwidth than MI355X, depending on the transfer path tested. Those figures provide more context than just numerical specifications, though they remain AMD-provided comparisons that will need independent validation.

The architectural choices behind the numbers are important. Reasoning models and long context windows require sizeable KV caches for maintaining AI attention states, while mixture-of-experts models frequently move large amounts of data across accelerators. MI455X should let more model data, activation states and cache remain local. New dedicated IP in hardware can transfer data while the GPU continues processing, and expanded cache and multicast capabilities are designed to reduce redundant data movement to further improve efficiency.

The aforementioned lower-precision formats can also raise throughput and reduce memory use, but model developers still have to determine where they can be applied without unacceptable accuracy loss.

AMD’s Helios rack takes aim at Vera Rubin

Helios is AMD’s primary rack-scale competitor to NVIDIA’s Vera Rubin platform. Each liquid-cooled rack combines 72 MI455X GPUs, 18 single-socket Venice host CPUs and Pensando networking technologies.

In its most complete, premium configuration, AMD rates Helios for 2.9 exaflops of low-precision AI compute, with 31TB of aggregate HBM4 capacity, 1.7PB/s of memory bandwidth, 260TB/s of bidirectional scale-up bandwidth and 43TB/s of scale-out bandwidth.

These are formidable figures, but they are technical specifications rather than actual application benchmarks. The more consequential development is AMD’s move from collections of eight-GPU servers to a 72-GPU shared-memory domain. Models too large for one node can operate across the rack without treating every exchange as a scale-out networking transaction, which benefits large-model inference as well as training.

AMD uses UALink over Ethernet, or UALoE, for an open standard scale-up fabric. Each MI455X provides 3.6TB/s of bidirectional scale-up bandwidth, while the complete rack delivers all-to-all connectivity through a single switch layer. AMD also claims six times more scale-out bandwidth per GPU than MI355X when MI455X is configured with three Pensando Vulcano 800 AI NICs.

While open standards give cloud providers more control over suppliers and system design, AMD and its partners now have to prove those components can deliver the predictable performance, reliability and deployment experience customers expect from a tightly controlled, more vertically integrated platform.

Finally, AMD designed Helios with automatic rerouting around failed links, virtual rack partitions, tray-level serviceability and rack-wide power, cooling and health monitoring. Major hyperscalers and potentially large-scale enterprise customers will likely key in on these capabilities, which can affect the availability, total cost and consistency of the AI services they consume.

Kind of like cowbell, AMD Venice gives agentic AI more CPU

AMD’s agentic CPU messaging regarding its upcoming Venice-based EPYC processors is mostly marketing speak, but the underlying requirement is very real. An AI agent can invoke retrieval, databases, security checks, code execution and other tools before a GPU generates a response. Running many agents concurrently increases the amount of conventional compute requirements surrounding the accelerators.

Venice scales to 256 Zen 6 cores with support for 512 threads, 16 memory channels, up to 1GB of L3 cache per socket, along with PCIe 6.0 and CXL 3.1 connectivity. AMD is also offering several Venice configurations for other applications, including general-purpose servers, high-frequency workloads, GPU hosts and high-density CPU sandbox systems used to execute agent tools.

Treating the CPU solely as a GPU host understates its role. Gateways, tokenization, vector search, databases and short-lived code execution stress different mixes of per-core performance, thread count, memory bandwidth and I/O. Specifically, AMD’s internal testing shows Venice significantly outperforming its current EPYC 9965 Turin CPU across five parts of the agentic AI pipeline, including gateway processing, context assembly, vector search, enterprise applications and short-lived tool execution. Individual gains vary by workload, but AMD details the overall generational improvement at up to a 1.7 times lift. As with the MI455X figures though, these comparisons come from AMD and will require independent validation.

Pensando networking and ROCm software advance

Keeping GPUs fed with data and coordinating traffic across racks directly affects utilization and operating costs. In fact, GPU utilization is a pretty sad state of affairs currently for some of the major frontier model providers.

As such, Pensando networking has become central to AMD’s roadmap. Helios can connect each MI455X to as many as three 800Gbps Vulcano AI NICs, while Salina DPUs handle front-end networking and infrastructure services.

On the software side, which is an equally critical component, AMD also introduced ROCm.AI, an AI-assisted development layer due to arrive in August. It includes reusable skills for coding agents, simplified management and Hyperloom, which can profile workloads, tune serving configurations, modify kernels and validate results.

These tools address two persistent AMD challenges: developer efficiency and ease of use, and software tuning. Automated optimization still has to produce repeatable gains without creating hard-to-maintain code, however. And while ROCm has progressed significantly over the last few years, NVIDIA’s CUDA retains an advantage in maturity, tooling and developer familiarity.

Customer commitments underscore rack-scale confidence

AMD now has commitments that give its MI450 generation and Helios considerably more weight. Meta and OpenAI have announced multi-generation agreements composed of up to 6GW of AMD compute capacity, with initial 1GW deployments planned for the second half of 2026.

Oracle plans a 50,000-GPU public cloud cluster beginning in the third quarter, while Microsoft will deploy Helios for Azure AI inference. Finally, just before the AMD event, Anthropic announced a strategic partnership for up to 2 Gigawatts of AMD-fueled AI compute, with its first gigawatt expected online in the first half of 2027.

Commitments of this scale reflect confidence in more than just MI455X performance. These customers are evaluating the complete architecture, including Venice CPUs, Pensando networking, ROCm software, rack integration, serviceability and AMD’s ability to deliver and execute across multiple product generations.

There is some financial alignment behind the agreements as well. AMD issued OpenAI performance-based warrants and committed to investing up to $5 billion in Anthropic. That context matters when evaluating these deals as market validation, but these planned deployments are substantial nonetheless and put Helios on a much stronger foundation as it begins shipping.

AMD expands its robotics and embedded foundation

AMD also expanded its physical AI portfolio, building on credible traction from its Xilinx-derived Kria adaptive system-on-modules and embedded technologies that are already powering robotics, machine vision and industrial automation applications.

The new Ryzen AI Embedded X100 combines up to 16 Zen 5 CPU cores, integrated Radeon graphics, a second-generation NPU and as much as 128GB of unified LPDDR5X memory shared across its compute engines. To me this looks a lot like a repackaging and optimization of the company’s Strix Halo platform, but with specific optimizations for the embedded space. Regardless, AMD is pairing X100 with the Kria AI Robotics Developer Platform, which includes a System Module or SOM, and a new Robotics Partner Network spanning hardware, software and platform providers.

Samples began shipping in June, with full production expected in the fourth quarter. This broader objective is to give developers a path across AMD x86 CPUs, GPUs, NPUs and FPGAs for real-time autonomous systems, rather than requiring them to assemble those hardware engines and software components independently.

Execution for AMD is now the test

AMD has assembled a credible platform for the burgeoning agentic AI market that’s blowing up currently with no signs of stopping. MI455X addresses memory and data movement, Venice handles dense agentic CPU workloads, Pensando networking connects global system resources, and ROCm.AI addresses software complexity. Finally, Helios assembles these components into a true competitive threat for NVIDIA’s latest Vera Rubin platform.

AMD’s open architecture may appeal to customers seeking supplier choice, but openness must also translate into reliable deployments, competitive total cost and software that does not require a significant rip-up. NVIDIA enters this cycle with a stronger ecosystem and far more rack-scale deployment experience. The true test will be how easily and reliably customers can integrate, operate and maintain these AMD solutions at scale.

As it stands, AMD now has major customers and a clearly defined architecture with systems engineering expertise behind it. Delivering Helios on schedule and showing that its performance claims translate into a real production workload throughput advantage and total cost of ownership gains will determine how much the competitive gap narrows. And of course, this is in a market that is clamoring for ever-more compute resources with a seemingly insatiable demand for AI services and capacity. That’s an environment for big iron success. Now AMD just has to deliver optimized, turnkey AI platforms. This is far easier said than done, but time will soon tell as deployments take shape this year.

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

Revenue from IBM’s z mainframe portfolio declined 42% in the quarter ended June 30, dragging infrastructure revenue down 7% compared to the year-ago quarter. But Big Blue executives remain positive on the mainframe’s role as an important AI platform.

After warning of an earnings shortfall, IBM lowered its full-year forecast. It now expects 2026 revenue to grow between 4% and 5%, rather than its previous forecast of more than 5% growth. Some parts of its business did well: Software revenue grew 5% in the second quarter to $7.76 billion, fueled by 11% growth in hybrid cloud, 18% growth in data, and 3% growth in automation.

On the infrastructure side, IBM posted second-quarter revenue of $3.8 billion, which is down 7%. Within that business, distributed infrastructure grew 37%, but those gains were offset by a 10% decline in hybrid infrastructure and IBM Z’s 42% drop.

In a July 14 letter to investors released prior to IBM’s July 22 earnings call, CEO Arvind Krishna warned of the earnings shortfall and laid out current challenges. He related the infrastructure performance shortfall to “wrapping on the launch of z17 in the second quarter” and stated: “Given this was the strongest start to a mainframe program in our history, we expected Infrastructure revenue to decline low-single digits for the year, beginning this quarter. What played out was worse than our expectations, driven by a shortfall in our Z performance and the associated software stack, primarily in Transaction Processing.”

In the last few weeks of June, customers shifted capex spending and started purchasing more AI infrastructure components in the form of servers, storage, and memory “to secure supply-constrained infrastructure ahead of expected price increases,” Krishna stated. “This dynamic impacted client buying patterns. While we anticipated some supply chain related impact in our expectations, we did not anticipate the magnitude of the capex reprioritization.”

Yet despite challenges this last quarter, z17 remains at nearly 130% growth program-to-program, according to IBM. That’s “well ahead of z16, which was our strongest program on record, with clients representing 85% of installed MIPs maintaining or growing capacity,” the July 14 letter stated.

Mainframe infrastructure momentum is expected to continue, and IBM is anticipating strong workload growth and AI-driven capacity expansion as clients modernize mission-critical systems and emphasize resiliency and security, Krishna said during the company’s Q2 2026 earnings call on July 22.

“AI is driving incremental capacity growth and new workloads as clients look to run AI closer to their most sensitive data,” IBM senior vice president and CFO James Kavanaugh said in the call. “We are seeing strong early adoption of our AI innovations with nearly 50% of z17 customers investing in AI capabilities with Spyre AI accelerator, and clients deploying Watson X Code Assistant for Z are growing MIPS capacity three times faster than those who are not.”

“In a world where infrastructure costs are rising and efficiency matters more than ever, IBM Z offers a compelling economic advantage,” Kavanaugh continued. “Depending on the size and complexity of workloads, clients can realize a 2 to 15x total cost of ownership benefit versus moving these workloads off the platform, reinforcing why the platform remains central to their operations and positioning us to capture additional value as AI workloads grow.”

“We see no evidence of clients moving off mainframe,” Kavanaugh added. “Clients continue to invest in IBM Z to modernize mission-critical workloads with a focus on resiliency and security.”

In responding to an analyst question, Kavanaugh said three key things drive mainframe demand and purchasing requirements:

“One is capacity workload. It’s the most important determinant. 85% Of the installed MIPS capacity out there in the marketplace today running all those core mission critical workloads are either stable or growing. Clients are adding capacity and workload to mainframe, the viability. And by the way, that’s coming in new AI workloads, analytics workloads, Linux-based workloads, and those MIPS are growing program to date over 15 to 20% installed capacity,” Kavanaugh said.

Number 2 is economic factors. “We don’t talk a lot about this, but I think it’s important for our investors to understand things like total cost of ownership. Depending on the size and complexity of the workload, we have anywhere from a 2 to a 15x TCO advantage running on the mainframe [over smaller server systems]. Again, we do not see any evidence of clients migrating off mainframe and lease propensity, which is a great indicator,” Kavanaugh said.

The third driver is AI. “When you look at it, applications, data security, all on the platform, we do 450 billion inferences per day at 1 millisecond with 8 nines availability,” Kavanaugh said. “We’ve got clients that have already purchased over 50% of our Spire inferencing, and those clients that have purchased that are growing MIPS capacity, the way [we monetize value], by over three times faster than others.”

Over the past few years, I have learned that basic prompts produce inconsistent, hallucination-prone results that no executive would trust in production. What turned the tide was my move to advanced prompting techniques. These weren’t theoretical experiments; they became a practical foundation for reliable, measurable outcomes. I want to share the techniques that consistently delivered the biggest gains in my projects, complete with real before-and-after examples, copy-paste templates, lessons from failures and guidance on when to evolve beyond prompting to agentic systems.

Why advanced prompting still matters in enterprise settings

Sophisticated prompting remains essential for control, reliability and compliance. If you “ask nicely” and hope for the best, you need deterministic behavior, auditable reasoning and minimal risk of hallucination. Here’s what worked for me.

1. Chain-of-Thought (CoT) and its variants: Unlocking step-by-step reasoning

The problem: Models would jump to conclusions on complex analysis tasks, especially involving data interpretation or multi-step logic.

What I did: I started explicitly instructing the model to “think step by step” and show its reasoning.

Before (basic prompt): “Analyze last quarter’s sales data and recommend three actions.”

After (CoT prompt):

“You’re a senior business analyst. Analyze the following sales data step by step: [data]. First, identify the key trends. Second, calculate the rates and anomalies. Third, link findings to business context. Finally, recommend the three prioritized actions with expected impact. Explain your reasoning at each step.”  

Results: Accuracy and depth improved dramatically.

Variants that worked well: Self-consistency. I ran the same CoT prompt multiple times and took the majority consensus. This reduced variability significantly.

Template you can use:

You are [expert role]. Solve this problem by thinking step by step.

[Task or question]

For each step:

1. State your observation or calculation.

2. Explain the implication.

3. Proceed only when confident.

Final answer in this format: [structured output]

2. Tree-of-Thoughts (ToT): Exploring multiple reasoning paths

For truly complex decisions such as resource allocation or risk assessment, linear CoT isn’t enough. Tree-of-Thoughts lets the model generate and evaluate multiple branches.

Example: I was helping a client evaluate three potential vendor platforms for an AI deployment. A standard prompt gave a superficial comparison. With ToT

Prompt Snippet:

Explore three different reasoning paths for selecting the best vendor platform:

Path 1: Focus on cost and scalability.

Path 2: Focus on security, compliance and integration.

Path 3: Focus on innovation and long-term roadmap.

For each path, evaluate pros/cons against our requirements [list].

Then, compare the paths and recommend the strongest overall option with justification.

Outcome: The model surfaced nuanced trade-offs (e.g., one vendor had superior security, but higher integration cost).

When to use: Strategic planning, troubleshooting or scenarios with high uncertainty and multiple viable approaches.

3. ReAct (Reason+ Act) and prompt chaining: Moving toward agentic behavior

One of the biggest leaps I have noticed comes from combining reasoning with tool use and chaining prompts.

ReAct example: (used in data analytics workflow)

You are an AI analyst with access to tools. For the query below:

1. Reason about what information you need.

2. Choose the appropriate tool or action.

3. Observe the result.

4. Repeat until you can answer confidently.

Query: [user request]

In practice, I chained this with retrieval tools. One automated quarterly compliance reporting; the system reasoned about required data, pulled relevant records, validated them, and generated the reports.

4. Meta-prompting and self-reflection: Letting the model improve itself

Use the model to refine its own prompt. This is a huge time-saver.

You are an expert prompt engineer. Improve the following prompt for clarity, structure and effectiveness with [target model]. Make it more precise while preserving intent.

Original prompt: [paste]

Provide the improved version and explain your changes.

Self-reflection loops (asking the model to critique its own output and revise) are a game-changer for content generation and code-review tasks.

5. Multimodal and structured output techniques

With vision-enabled models, I started combining text with images (e.g., uploading architecture diagrams or dashboards).

Tip from experience: Be extremely specific in describing what the models should focus on.

Best practices I learned the hard way

• Start simple, then layer complexity: Over-engineered prompts from Day One usually backfire.
• Model specific tuning: Some models respond better to XML delimiters; others to explicit reasoning.
• Evaluation and versioning: Treat prompts like code if you track versions and run automated evals.
• Security guardrails: Always include instructions against prompt injections and respect data boundaries.
• When to stop prompting: For repetitive, high-stakes workflows, move to full agents or an orchestration framework.

Final takeaways for technical leaders

Advanced prompt engineering has now become a core competency for anyone responsible for enterprise AI outcomes. Start by picking one technique and apply it rigorously to a real business problem. Document before/ after and you will notice why it’s worth mastering.

The field continues evolving towards more automated and agentic systems, but the ability to precisely direct AI reasoning remains foundational.

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

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

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

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

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

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

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

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

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

A steep learning curve

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

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

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

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

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

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

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

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

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

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

Routing

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

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

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

Harness

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

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

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

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

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

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

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

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

Specialization

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

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

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

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

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

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

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

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

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

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

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

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

The full-stack CIO: Leading with clarity

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

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

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

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

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

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

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

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

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

Reducing organizational friction

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

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

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

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

Operating model as strategy enabler

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

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

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

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

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

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

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

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

Closing the gap between strategy and execution

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

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

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

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

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

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

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

In public-sector and regulated-cloud work, I learned that sovereignty rarely starts as a national strategy. It starts as an auditor’s question: Who can prove where the data went, which system made the decision and what changes when the vendor or infrastructure does? That question is now moving into AI, and most sovereign-AI debates answer the wrong version of it.

They ask whether a country can build its own model on domestic data and hardware. For the United States and China, which together hold more than 90% of global AI data-center capacity, per a January 2026 Tony Blair Institute analysis, that question is worth asking. However, for almost every other government, it is the wrong place to start. The operative question is narrower: Once AI is embedded in public services, who controls the stack?

The 5 layers of public-sector control

For a CIO, sovereign AI means enforceable control across the AI lifecycle; model ownership is a separate question. Control has five layers:

• Data control: Where sensitive public data sits, and whether it can train a vendor’s model.
• Model control: Which models clear which workloads, and under what validation.
• Infrastructure control: Whether critical workloads run in approved environments.
• Operational control: Whether AI-assisted actions are logged, monitored and reversible.
• Vendor control: Whether the agency keeps portability, audit rights and a real exit.

Those five layers are the control plane for public-service AI. Floyd Dcosta recently made the enterprise case in “AI without sovereignty is just outsourced intelligence”: capability is what a tool can do; authority over how and when it does it is something a buyer can quietly lose. For public services, losing that authority plays out in the public eye.

Public-sector AI risk differs from enterprise risk. A retailer’s bad recommendation costs a sale; a government’s AI touches benefits, tax enforcement, policing and emergency response, raising the bar to due process, records retention and continuity of operations. A government that cannot reconstruct an AI-assisted decision lacks operational sovereignty, even in a domestic data center.

Evaluating risk: Concentration, jurisdiction and shadow AI

Foreign dependency is a real risk, but the exposure that matters is a sudden cutoff: A model you cannot audit, switch or exit, shut off by someone else’s order. A vendor’s nationality is a poor guide to that risk; control is.  Two markers matter. The first is concentration. In July 2024, a single faulty CrowdStrike update crashed about 8.5 million Windows machines, disrupting airlines, hospitals, banks and governments worldwide. No attacker was involved; one homogeneous dependency failed everywhere at once. The lesson points away from vendor nationality and toward uniformity as the fault line, making portability and provider diversity resilience controls.

The second is jurisdiction. In June 2025, Microsoft’s legal director for France told a Senate inquiry, under oath, that it could not guarantee that French public-sector data, even in French data centers, would be protected against US demands under the 2018 CLOUD Act. No such request had been made, and EU data has stayed in the EU since January 2025; senators called the assurance purely declarative. For the most sensitive data, residency does not equal control; the parent’s jurisdiction can matter as much as the server’s. Three US hyperscalers hold about 70% of the European cloud market, while European providers’ share fell from 29% in 2017 to roughly 15%. Concentration plus jurisdiction is the exposure a CIO must price. I have watched teams treat vendor selection as the moment risk was solved; it rarely was.

The wrong response is self-isolation. Most countries will never build frontier models, advanced chips, hyperscale clouds and talent pipelines at once; the Tony Blair Institute calls full self-sufficiency “too expensive, too slow and, for most countries, simply impossible.” The better test is workload sensitivity. Low-risk uses, such as drafting, translation and summarization, can run on commercial platforms with controls; high-risk uses, such as benefits eligibility, fraud investigation and healthcare triage, demand stricter control over data, model behavior and auditability.

Mandating domestic-only provision before a competitive option exists inverts sovereignty. Europe 2031, a five-year scenario from June 2026 by European technologists and policy researchers, illustrates the failure mode: A 2027 “buy European” mandate lands as offensive cyber capability spreads, and agencies that switched to weaker providers are locked out and paying ransoms. The scenario is fiction; the mechanism is not. Leverage comes from being indispensable, not half-hearted self-sufficiency. The closer-to-home effect is shadow AI: Mandate an inferior sanctioned tool and staff bypass it, the way shadow IT grows up around tools people find too slow. A rule that pushes sensitive work into ungoverned shadow AI reduces control instead of adding it.

Regulation and data-residency rules belong in any serious strategy, but carry failure modes. Blanket localization raises hosting costs and slows adoption without guaranteeing control, and a “sovereign cloud” on a foreign parent’s stack can amount to sovereignty theater. The more useful pattern tiers requirements by sensitivity. India’s BHASHINI shows the application layer done well: A public platform serving 100 million-plus inferences a month across 22-plus languages on a vendor- and cloud-agnostic design that keeps data and switching rights public. Sovereignty resides in the portability, not in a national model.

Building an operational sovereignty strategy

Public trust is the constraint sovereignty rhetoric tends to skip. The OECD’s 2025 review of government AI warns that opaque systems make AI-assisted decisions hard to explain and can give public servants false confidence in tools that fail quietly. State-controlled AI is the same problem from the other side: A government that deploys models against its own citizens without audit or record has gained control and lost accountability. An agency that can log, explain and reverse an AI-assisted action can defend it to citizens, courts, auditors and elected officials. If it cannot, it has bought access and called it sovereignty.

None of this is new. AI sovereignty repeats earlier fights over cloud, telecom, semiconductors and cybersecurity. Europe’s flagship cloud project, GAIA-X, became a cautionary tale; the Dutch technologist Bert Hubert called it an “expensive distraction” that produced no European cloud, the familiar result of ambition without absorptive capacity. Cloud taught governments that outsourcing infrastructure does not outsource accountability; telecom, that vendor dependency becomes strategic exposure; chips, that supply chains matter before a crisis; cybersecurity, that trust must be verified continuously. AI inherits all four at once.

Over the next five to ten years, some countries will build national platforms, more will build trusted cloud and trusted model regimes, and most will run hybrids that pair domestic data control with global model access. Trade policy will harden those choices: Export controls on compute and data-localization rules will pull the vendor market into blocs that track alliances more than open markets. For a CIO, that turns a vendor and hosting decision into a five-year bet on whose rules and supply chains will still hold. The ones that succeed will treat sovereignty as an operating requirement, backed by leverage, not a slogan. Start with the control plane before the model: Most agencies will never own the model, and the controls are what decide whether the AI they do run stays accountable. Even when procurement policy is dictated from above, these questions remain within the CIO’s authority:

1. Can we classify AI workloads by public-service risk?
2. Can we prove where sensitive data goes across training, retrieval, inference, logging and retention?
3. Can we restrict which models are approved for which data classes and functions?
4. Can we reconstruct an AI-assisted action in enough detail to explain it?
5. Can we change providers without losing continuity or institutional knowledge?
6. Can we explain the system to citizens, regulators, auditors and elected officials?

A “no” to any of these does not mean the agency lacks AI. It means the agency has access it does not yet control. Public institutions can use global innovation without surrendering public authority, but only once they know what to hold, what to rent and where dependency turns into risk.

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

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.

For many engineering teams, AI adoption means individual engineers write code faster while overall team velocity remains stagnant. Individual speed and team speed are produced by different things, and AI has mostly accelerated the first but not the second.

The step from individual AI adoption to team advantage is one many organizations haven’t taken yet, but it’s the step where real ROI lives. Make the leap and every individual gain starts compounding into something the whole team feels.

Faster individuals, but the same team pace

A developer with a good AI assistant can produce more and produce faster, but ten developers all doing that, each in their own way, with their own tools and their own context, don’t add up to a team that is ten times better. More often they add up to a team moving faster in ten different directions.

The speed stays with the person who created it. The reasoning, context, and decisions that the rest of the team would need to build on that speed gets lost.

These three structural problems explain why:

Problem #1: Context evaporates at scale

An engineer spends an hour with an AI agent working through a hard design decision. They land somewhere good. The code ships. But the reasoning, the alternatives they ruled out, and the constraints they discovered stay in a chat history nobody else will ever open. Six weeks later a teammate touches the same system, has no idea any of that thinking happened, and starts over.

You can’t prompt your way out of a context vacuum. Agents and teammates alike are only as good as the context they start with, and right now most of that context is being generated and immediately lost. The teams that pull ahead will be the ones that treat the reasoning around the work as something worth capturing.

Problem #2: Misalignment creates duplicative work

When individuals move fast in parallel without a shared source of truth, they start stepping on each other’s toes. Two people solve the same problem two different ways. An agent generates a change against a spec that quietly went stale last week. A confidently written pull request follows the wrong internal standard because the standard lived in someone’s head, not in the workflow.

This problem gets worse as more of the work becomes agent-driven. Agents overwrite each other. Specs drift out of date faster than anyone updates them. The faster the individual pieces move, the more expensive the collisions become.

Problem #3: Trust doesn’t scale

The quiet tax on AI-assisted work is review. If an individual developer can’t see how a piece of work was produced, what the intent was, what the agent was told, what standards it was working against, then they can’t confidently build on it. So, they re-check it, or rewrite it, or route around it. The individual saved an hour. The team spent two earning back the trust.

Trust transfers when intent is legible. When a teammate or a reviewer can see what was meant, what was decided, and what guardrails applied, they can accept the work and move on. When they can’t, every handoff becomes a re-litigation.

Turning adoption into advantage

The through-line across all three problems is the same. The value of AI at the team level does not live in the code any single person or agent produces. It lives in whether the intent and context around that work is captured, shared, and reusable by everyone else, human and agent.

That reframes the leadership job. It’s not about driving more adoption, because your teams already handled that. It’s about building the connective layer that turns individual output into team capability.

The window is now

This matters more every month, because the individual productivity story is about to become an agent orchestration story. The organizations that turn individual adoption into team advantage now, while the habits are still forming, will be the ones whose agents actually compound.

See how engineering leaders are building the connective layer between individual AI adoption and team-level compound returns at jira.dev.

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

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

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

Demand growth in data centers

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

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

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

The death of “sticks and bricks”

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

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

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

The digital bridge: Construction management software  to ERP

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

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

From BIM to DCIM: The lifecycle thread

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

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

The scientific inference: AI in the supply chain

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

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

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

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

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

The roadmap for the modern CIO

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

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

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

At Cisco, VP of engineering Jason Andrews deals with all the same technical issues as every other company deploying AI, including ensuring it’s governed, secure, and integrating multiple data sources, legacy systems, and AI models.

But these issues are relatively straightforward compared to the bigger challenges relating to the fast pace of change, specifically how AI can touch and transform nearly every aspect of business.

“We’re thinking about it every day,” he says. “My belief is we’ll be seeing a massive acceleration of everything.”

In coding, for example, he’s witnessing productivity increases up to 110% with AI assistants. “I can build apps or custom integrations a lot faster,” he adds.

And the real benefit of AI isn’t just in speeding up individual steps in a process, but in making AI the core of a new business process. But building it from scratch puts even more pressure on organizations trying to get employees up to speed on new ways of doing things.

“We want to move fast, train people, and get them onboarded,” he says. “But what I thought AI was going to do for my organization nine months ago is different from three months ago.” So by the time something is rolled out, it’s changed three times.

“I struggle with the change management aspect,” he says. “The legacy model of change management isn’t fast enough. How do you create that constant learning?”

One of the ways Cisco approaches it is to create communities where people can talk about these issues and share best practices and governance, and you have to keep people’s minds open that every day is going to be different than the last, Andrews adds.

Testing the AI waters

Cisco isn’t the only organization struggling with change management in the face of the AI tsunami. In a survey of 2,000 global CEOs IBM released in May, 83% of them said AI success depends more on adoption than on the technology itself, and 77% said talent and technology roles are converging.

“Thanks to Claude Code, our entire development cadence is exponentially greater than a year ago,” says Andrew Johnson, CIO at Brownstein Hyatt Farber Schreck, a Denver-based law firm with about 700 employees and clients around the US. But, as with Cisco, the biggest challenge isn’t technical.

“In our industry, with our circumstances, we’re probably less constrained by technical capability than organizational constraints, culture, aptitude, the need to bind people to technology, and what helps me and the client,” he says. “There’s a tremendous amount of cultural shift that has to happen in our organization, which is far more demanding of my attention and complexity of thought than the technical stuff.”

Companies that bill by the hour, such as law firms, may face additional challenges as attorney productivity increases because billable hours might go down. Alternatively, the total number of cases could go up as litigation becomes less expensive. Either way, firms that adapt will see competitive advantage, and the rest will fall behind, putting more pressure on the need for change management.

“If people can’t embrace technology, we won’t be able to get a lot of value out of it,” says Johnson. “I’m talking to people about adapting their way of work. There are certainly a lot of people intrigued and anxious to dive in. They recognize the connection between the potential of the technology and what we do.”

But helping everyone see that connection and then working with them to change their habits is difficult, and requires solid relationships and good communications. “That’s been far more of a bottleneck for us,” he says.

To address the issue, the firm has developed a network of technology champions who also understand the legal side of the business. “Now we need lawyers who know how to use the technology and can articulate these things to the people we’re trying to reach,” Johnson says.

But change management is only one leadership bottleneck slowing AI adoption. Companies also struggle with figuring out their vision for AI, with slow decision-making, and a tendency to focus on the past instead of the future.

Vision and strategy

In another survey, this time of 950 business leaders released by Grant Thornton in April, 51% said strategy is the biggest driver of ROI when it comes to AI adoption, but 79% of operations leaders said they don’t have a fully developed and implemented AI strategy.

“Having leadership understanding why AI is needed and what objective they’re trying to achieve is very important,” says Shivi Verma, senior manager of engineering at Docusign. “Sometimes leadership doesn’t have a strategy for their organization on how AI should be adopted. Many times it’s bottom-up, which creates a chaotic experience.”

When Docusign started adopting gen AI, different teams and organizational units wanted to go in different directions. “All were coming up with their own strategy and tooling,” he says. So Docusign brought business leaders together to understand the pain points, and decide on the technology.

“Getting requirements and placing a bet on a specific technology was important,” he says, “as well as pivoting to a different technology if needed.”

In order to adapt to changes, the company wanted to have a nimble approach, starting with smaller use cases, with power users, and problem areas.

“We try to plan for four to six months,” he adds. “We set expectations for our leadership that we place a bet with a specific technology, but want to be able to pivot.”

Today, the leadership challenge front lines have moved yet again, to agentic AI. “Folks are creating their own agents and deciding their own permissions,” Verma adds. “We’re still coming up with a governance strategy.”

Slow decision-making

When it comes to AI deployments, Dan Diasio, global AI consulting leader at EY and CTO for its US consulting business, admits he’s a bottleneck.

There’s a great deal of interest in what AI can do, and using a variety of new AI tools. But since the firm deals with sensitive client data, safety is paramount. It’s a slow process, but important to build secure infrastructure, and to have trust in the technology. “That’s a reasonable bottleneck that makes sense,” he says.

Trust in the tools they work with is essential because clients expect it. “Every tool we use has to go through a detailed security and information privacy impact assessment, as well as a whole other set of controls so they can be used appropriately and safely,” he says.

These reviews can take a lot of time, though, and in the age of AI, speed is a highly valued currency. So how do you balance the two, when safety reviews can require input from a lot of different stakeholders and be extremely time intensive?

“We’ve stood up a team to be able to quickly certify and address a variety of platforms,” Diasio says. “Instead of working with different departments in the way we used to, we’ve started identifying representatives from different departments into a cohort. Decisions we used to make in months now take weeks.”

According to a West Monroe survey of more than 1,200 leaders released earlier this year, slow decision-making is already showing up on the bottom line. Nearly three out of four leaders said their organizations lose up to 5% of annual revenue to slow decision-making and delayed execution.

And the top reasons for the delays? According to 40% of the managers surveyed, the problem was the skills gaps of overwhelmed teams, and 35% pointed to layers of management or approvals. Nearly half said they’re spending 10 to 25% of their time on rework, excessive approvals, and unnecessary meetings, and more than half say up to 50% of their projects fail or lose momentum to delays.

Focus on the future, not the past

When it comes to the decision about where to apply AI in an organization, the tendency, Diasio says, is to turn to the experts with the most expertise in the business. But these are the same people most likely to focus on improving on what they’re already doing.

“And that often blinds people to what’s possible in the future,” he says. “That becomes a significant bottleneck.” So the solution is to revamp the decision-making process around the new reality.

“What we see some advanced companies do is give people who don’t understand the process but understand the technology equal footing with people who don’t understand the technology but understand the process,” he says. “A lot of companies are disproportionately focused on just addressing their operating model right now.”

Instead of focusing on what they’re currently doing, AI-native companies will start with a focus on the customer, he says. This shift in focus isn’t likely to show up immediately on the bottom line, or result in the highest possible number of pilots going into production.

“If leaders are in a position where they’re justifying the use of a technology to the board or their CFO, they become a bottleneck when they start demonstrating their value in terms of the number of things they’re doing,” Diasio says.

But 150 or 200 use cases deployed into production may feel like progress, like things are happening in the organization. But all these use cases are a waste of time and money if they’re applied to existing processes that don’t move the needle. “We see that happen in organizations today,” he says. “Maybe we need to reinvent the processes.”

It’s no secret that companies will need to change in order to adapt to AI. Deloitte recently surveyed 660 global technology leaders and 81% said their current operating model can deploy and govern AI enterprise-wide, but 75% also said their organization must change its operating model within the next 12 to 18 months to drive greater value.

AI ROI is real, says China Widener, Deloitte vice chair and US tech, media, and telecom industry leader. But it’s currently weighted toward efficiency gains, with broader business transformation and revenue upside still developing.

Another Deloitte survey showed that the clearest results from AI were in productivity, with 66% of organizations reporting gains, and cost efficiency, with 40% saying AI reduces costs. “However, revenue impact is still emerging,” says Widener. “Only one in five companies says AI is driving top-line growth today.” But optimism prevails, with 74% expecting it to do so in the future.

Your CFO has a simple question. “We’re spending more on AI. What are we getting for it?” Most CIOs cannot answer it — not because AI isn’t creating value, but because the accounting systems we inherited were built before AI existed as a category of labor.

This June, the conversation shifted from token maxing to token cutting. The New York Times reported that Meta, Uber, Walmart and Amazon are capping employee AI usage. Uber blew through its 2026 AI budget in four months. Satya Nadella started framing it as human capital versus token capital.

All of that is true. None of it answers the CFO. Capping tokens is an input lever, not an output measure. And the human-versus-token framing names two sources of labor when the reality is four.

The enterprise now has 4 sources of labor

There are humans. There are humans assisted by AI. Humans are working alongside AI. And humans are managing AI. Sources two through four are all supervised machine labor at different intensities — none of them have a line item, a manager or an hourly rate. In our 2026 AI Labor Report, 78% of leaders view AI as both software and a labor force. The org chart has not caught up. Neither has the P&L.

Most enterprises are stuck at A-Level 1 with no accounting for any of it, while quietly sliding into A-Level 2. The job descriptions have not caught up. The budget has not caught up. You cannot upskill into a role that has not been named.

AI is the only category of work the modern enterprise has ever bought without a system of record for what it produced.

What you are actually running is supervised machine labor

The model does a first pass. A human makes it usable. One hundred percent of leaders we surveyed said AI work requires human review before it ships; 34% said substantial editing. That is a workforce with no manager, no hourly rate and no line on the income statement.

The accounting breaks in 3 places at once

Under GAAP: COGS if it helps produce the product, OpEx if it does work for you. The same workflow can hit all three buckets at once. A tier-one support resolution involves the human’s salary (OpEx), the AI’s tokens (COGS if support is a delivered service), and the supervisor’s review time (OpEx). Three buckets. One piece of work. No reconciliation. The token invoice arrives from Anthropic or OpenAI and gets coded to OpEx-software because that is what the bill looks like. Audit partners will be asking about this by next year.

When you call AI a tool, you book it like software. When you call it labor, you have to ask which kind and what it is producing.

The per-employee number is the wrong unit

Per-employee AI spend collapses a workforce into a per-head average. It hides the only number that matters: What AI is producing inside each workflow.

Lanai measured two teams inside the same finance organization. Same monthly prep and variance analysis. AI took the same amount of time to produce outputs of similar quality. The only variable was the model each team reached for by default — a choice nobody had made deliberately and nobody had seen until it was measured.

The gap existed for months before anyone saw it.

Faith-based budgeting — the organizational equivalent of putting money in the collection plate and hoping God handles the ROI — is what made it invisible.

AI labor orphaning

That is not a measurement problem. It is a category error. We call it AI Labor Orphaning. AI does the work. The output gets credited to the human who approved it. The token bill lands in OpEx-software. The supervision time absorbs into salaried hours nobody is auditing. Eighty-seven percent of leaders admitted AI output is sometimes or always credited entirely to the human employee. This is the last-click attribution problem of the AI era, running in reverse.

What fills the vacuum? Belief. Forty-three percent assume that if AI was involved, it contributed. Only twelve percent have a clear methodology. Seventy-nine percent are worried AI budgets will be cut because they cannot connect spend to results. The cuts are not coming because AI does not work. They are coming because nobody can prove that it did.

Capping tokens may look like responsible governance, but it is like turning off a staticky radio rather than tuning the dial. The companies cutting AI budgets in 2026 will discover in 2027 that they cut the workflows that worked alongside the ones that did not.

The real cost of AI is not the model. It is the redesign

Three layers. Most organizations only manage the first.

What to actually do

The 12% of organizations that can answer the CFO treat AI like every other category of labor — with a cost per AI Work Hour that is accounted for by a set of AI assistants, co-pilots and agents that are held accountable to performance standards. 

• Audit the four sources separately. Each A-Level has different token economics, SaaS implications and human redesign requirements.
• Find the embedded SaaS repricing before your next renewal. Pull your top 20 contracts. Ask whether AI features previously included are now priced incrementally.
• Redesign the human role at A-Level 2 before you scale it. You cannot upskill into a role that has not been named.
• Build a system of record before you build the next agent. Start with one department. Two weeks. You will find something that surprises you.
• Stop calling it a tool. Start calling it labor. The language determines the chart of accounts.

When your blended AI rate is $22 an hour, the conversation shifts from ‘we spent $340,000 on AI’ to ‘we acquired a skilled workforce at $22 an hour.’ That sentence is defensible. A vendor invoice is not.

The CIOs who will have a defensible AI story in 2027 are the ones who renamed the work in 2026. Not because technology changed. Because they finally built the accounting to see it.

Findings are drawn from the 2026 AI Labor Report, fielded by Wakefield Research with 200 senior technology leaders at US enterprises of 1,000-plus employees, March 20–April 8, 2026 (±6.9pp at 95% confidence).

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

Outsourcing worked – until it didn’t.

After Akirolabs achieved early market validation and onboarded its first enterprise customers, outsourcing began to create strategic limitations around scalability, intellectual property (IP) ownership, security and delivery execution.

The challenges started after the first enterprise customers confirmed product-market fit. At that point, delivery speed became directly tied to business growth. Product quality expectations increased. Infrastructure and security requirements became stricter. Investors started asking difficult but fair questions about IP ownership, operational dependencies and long-term scalability.

Most importantly, engineering execution was no longer just an operational function – it became part of the company’s strategic advantage. That was the moment when the founders decided the company needed dedicated technology leadership to address these challenges. This is how I joined the company at the beginning of 2023. As VP of Engineering and a bit later as CTO, I led the transformation (usually known as insourcing, repatriating or backsourcing) from an outsourced model to an internal engineering organization while maintaining product delivery continuity and preparing the company for the next growth stage. The process took roughly a year and involved not only technical migration, but also organizational design, hiring, process development, infrastructure modernization and cultural transformation – everything from the ground up.

Building an internal engineering organization while still delivering

One of the biggest misconceptions about insourcing is that it is primarily a technical project. It is a leadership and execution challenge.

When I joined the company, there was effectively no internal engineering structure, limited visibility into the existing system and no clear long-term technical strategy. My first months were dedicated to understanding reality and I began with a comprehensive assessment of the codebase, operational risks, documentation quality and knowledge dependencies to determine the most viable transition strategy.

Very early in the process, I faced a critical strategic decision: whether to gradually assume ownership of the existing platform or rebuild it internally. To make that decision, I evaluated four distinct transition models ranging from limited management insourcing to a complete internal rebuild.

After assessing the technical, operational and long-term business implications of each approach, I selected the most demanding option: rebuilding the product internally while maintaining uninterrupted delivery for existing customers. Although riskier in the short term, a full rebuild offered the clearest route to complete IP ownership, architectural flexibility and long-term scalability.

At the time, this decision ran counter to the approach typically taken by startups in similar situations. Most organizations gradually assume ownership of an existing codebase to minimize short-term risk and preserve delivery capacity. My assessment was that the accumulated architectural debt, fragmented knowledge distribution and long-term maintenance risks would ultimately make a phased takeover more expensive and less scalable than a controlled rebuild. The strategy required significantly higher execution discipline, but it allowed us to establish complete ownership of the platform, eliminate inherited constraints and create an architecture capable of supporting enterprise-scale growth.

The next challenge was hiring.

In Germany, hiring can easily take four to six months – mostly due to a typical 3-month notice period, which is incompatible with startup timelines. We solved this by building a hybrid organization structure early: a lean internal core team combined with carefully selected contractors. Instead of hiring only narrow specialists, we prioritized experienced generalists capable of operating across architecture, infrastructure, security and compliance discussions. Later, we evolved toward a product engineering model, where engineers owned broader product outcomes rather than narrowly defined technical functions.

During the first three months, we established a core engineering team of four senior engineers. Over the following nine months, the organization expanded to roughly fifteen engineers while I strategically designed and executed the transformation of the platform’s architecture to meet the rigorous deployment and compliance standards of our first enterprise clients, including Raiffeisen Bank International and Bertelsmann. This structural overhaul allowed the company to meet the deployment, security and compliance requirements of enterprise customers that had previously been inaccessible under the outsourced model. At that point, we had already achieved complete coverage across backend, frontend, DevOps, QA and security.

I also intentionally kept processes lightweight during the transition. Instead of introducing heavyweight frameworks, we focused on clarity of priorities, fast decision-making and execution discipline. We used Kanban over Scrum, eliminated unnecessary meetings, shortened the remaining ones and emphasized engineering culture over process overhead.

Another major challenge was project estimation. Because dual-track development was unavoidable until the in-house platform reached production readiness, estimation accuracy had a direct impact on budget efficiency. Despite all challenges, my initial estimate ultimately proved remarkably close to the final delivery date, differing by only about a week. Accurate forecasting under conditions of parallel development streams, ongoing customer commitments and active team formation became a critical leadership challenge. Maintaining this level of predictability throughout the transition helped align engineering execution with business planning, hiring decisions and investor expectations.

The engineering transformation enabled capabilities that contributed to Akirolabs being recognized as an IDC Innovator in Procurement in 2023, named amongst the Top 27 AI Startups in Germany in 2024, Sifted’s 100 Fastest-Growing Startups in DACH & CEE 2025 and inclusion in 2024-2026 in ProcureTech100 annual recognition of procurement technology providers shaping the future of digital procurement.

Managing risk without slowing down the business

The hardest part of insourcing is not writing code, selecting the technology stack, designing architecture or configuring infrastructure. It is avoiding disruption while the company is changing underneath the product. I successfully orchestrated the concurrent overhaul of product architecture, cross-functional engineering recruitment, infrastructure modernization and live customer operations under exceptionally tight margins.

To reduce delivery risk, we approached the transition in layers.

First, we focused on infrastructure reliability and operational readiness before feature expansion. Cloud architecture, recovery testing, permission segregation and incident management processes were implemented early, not after launch. We also introduced multiple testing stages and dedicated QA functions after learning the hard way that a “developers-only” quality control approach does not scale for complex web platforms and business domains.

Second, we established a structured knowledge-transfer process to rapidly onboard engineers and reduce external dependencies.

Third, we became extremely disciplined about scope management. One of the most common reasons insourcing initiatives fail is uncontrolled change during the rebuild phase. Every new feature request increases uncertainty non-linearly. We learned to separate strategic improvements from distractions and protect the core delivery roadmap aggressively. Throughout the transition, we successfully maintained uninterrupted customer operations by utilizing planned maintenance windows, achieved a near-zero-downtime migration and permanently doubled product velocity immediately following the migration.

Beyond the technical migration itself, the transition established a repeatable operating model for scaling technology organizations beyond the product-market-fit stage. The framework combined organizational redesign, controlled knowledge repatriation, architecture modernization and enterprise-grade operational practices while maintaining uninterrupted customer delivery throughout the transformation. While the implementation was specific to Akirolabs, the underlying principles are broadly applicable to organizations seeking to transition from outsourced development to internal product ownership without disrupting business operations.

By the time the new platform reached production readiness, I had established not only a functioning engineering organization, but also a stable operational model: internal ownership, production-grade infrastructure, security processes, scalable hiring practices and clear technology and product roadmaps.

A positive side effect of the transition was the creation of internal UI/UX and Data Science capabilities, which later became strategically important for AI product initiatives and created a foundation for the third version of the product, which we released in mid-2025.

My technical restructuring and migration to a secure proprietary platform reduced architectural risk, established full in-house ownership and helped strengthen investor confidence during the company’s successful €5M fundraising round in 2024.

The transition created a stronger foundation for scale and supported the company’s continued expansion among enterprise organizations operating at Fortune 500 scale, including Ahold Delhaize, Workday, IFF, Deutsche Bahn and others.

Lessons learned for CTOs considering insourcing

Looking back, several decisions made the transition successful, and several mistakes made it harder than necessary.

The first lesson is simple: decisiveness in strategic transition is paramount to maintaining business momentum. Rapidly evaluating insourcing frameworks and defining clear boundaries with the external partner allowed us to mitigate operational downtime and execute a highly efficient migration ahead of critical market deadlines.

Second, hire more senior people and do it as early as possible. Strong technical leaders multiply execution capacity far beyond their individual contribution. In our case, the quality of the first hires influenced architecture quality, hiring standards, delivery discipline and engineering culture for the entire organization.

Finally, culture matters more than frameworks. Processes can be added later. Ownership mentality cannot.

The biggest long-term advantage of bringing development in-house was not simply faster execution, not better code quality or operational cost optimization by over 30% after the transition which we also achieved. It was an alignment. Product strategy, engineering decisions, customer priorities and business goals became part of the same conversation instead of being separated by organizational boundaries. For technology companies operating in highly competitive markets, that alignment becomes a compounding advantage over time.

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

In the client-server era, the penalty for inefficient programming, such as unoptimized database calls, was largely confined to application responsiveness. Today, in the AI era, code, architectural, and platform inefficiencies are no longer just a performance issue, they’re a financial and environmental liability. Left unchecked, poor code cascades into soaring token costs and spikes data center power consumption, directly undermining both cloud budgets and corporate sustainability goals.

AI’s impact on sustainability

By 2029, IDC projects that the number of actively deployed AI agents will exceed 1 billion worldwide, which is 40 times more than in 2025. And these agents will perform 217 billion actions per day.

To deliver on this demand, AI data centers are being built out at an unprecedented rate, with Gartner forecasting that global spending on data centers over the next three years will increase 31.7% to surpass $650 billion, driven primarily by hyperscaler cloud providers building out AI foundations, and optimizing servers for heavy AI workloads.

All this presents a significant strain on the energy grid as well as environmental sustainability, including:

• The power double-down: The International Energy Agency (IEA) projects that global data center electricity consumption will more than double from about 415 to 945 TWh by 2030, primarily fueled by energy-intensive accelerated computing for AI.
• The inference premium: AI workloads are vastly more demanding than standard web activities. A gen AI query consumes roughly 10 times the electricity of a conventional keyword search, or roughly 2.9 watt-hours as opposed to 0.3 watt-hours.
• Water consumption: Cooling these dense clusters is highly resource intensive. Global AI-related water demand is expected to reach 4.2 to 6.6 billion cubic meters by 2027.

The good news, however, is it’s not all out of the control of end user organizations and CIOs. Just as in the client-server era, through careful planning and execution, CIOs have the potential to significantly improve the performance, costs, and sustainability impacts of their AI application portfolio.

Here are four recommendations to maximize value as you look across your AI applications and infrastructure estate.

Revisit business objectives in light of AI

AI applications and platforms bring several new headaches for CIOs and CFOs in terms of FinOps. The variable nature of AI vendor billing due to variable monthly token costs is just one well-known example. To avoid unpleasant surprises, be sure to carefully review vendor contracts to decipher pricing models. Look for what’s included in seat-based license fees and what’s added as variable charges for agentic AI usage.

In addition, explore new metrics and KPIs such as intelligence per watt to help make sense of your return on AI. Just as miles per gallon helps us evaluate new car purchases, IPW can help to measure the computational efficiency of a system. It quantifies how much intelligence — typically measured in AI inferences, tokens processed, or model training iterations — a processor can deliver for every watt of electrical power it consumes.

According to Max Romanenko, chief engineering officer at relational database platform EDB, cost per query tells you almost nothing in an agentic world where autonomous systems are spinning up databases, pipelines, and queries around the clock. “The metric that matters is intelligence per watt, how much useful AI you get for every unit of energy you spend,” he says. “It isn’t just an environmental number, it’s also a performance indicator.”

With the measurements in place, you can then start to manage and optimize each layer in the AI stack from the infrastructure, or hyperscaler, layer to your own data and application layers.

It’s important to bear in mind that high token usage isn’t necessarily a bad thing. It depends on the net value delivered by each AI application and use case. Managing and optimizing the AI stack is important, but you’ll also want to measure the business value being delivered by each of these applications so you can measure your return.

Take a sovereign AI approach when evaluating hyperscalers

As you work with hyperscalers like Amazon, Google and Microsoft, it’s important to understand how they charge and how much, but also their environmental footprints. For example, by reading their sustainability reports, you can find out their annual water consumption across their global data centers and compare them with other providers.

In 2025, Amazon’s global data center operations used 0.12 liters of water per kilowatt-hour, which amounts to 2.5 billion gallons, or 5% of the annual water consumed by the metro Seattle area. The company has been able to operate more than seven times better than the industry average and have improved their water efficiency by 52% since 2021.

As demand for cloud computing and AI grows, water efficiency is another important metric for CIOs to monitor within hyperscaler ESG reports. While not at the same level of regulation as scope 2 and 3 greenhouse gas (GHG) emissions reporting, enterprises need to pay increasing attention to water use efficiency (WUE) with water scarcity becoming a growing risk for hyperscalers.

The key requisite at the infrastructure layer, though, is to ensure sovereign AI. This doesn’t mean you need to own everything, but you need control over your AI-driven operations when conditions change. With 71% of global executives stating that switching their primary AI vendor or model would be difficult if required today, it’s important to understand AI dependencies and be able to avoid vendor lock-in. 

Control efficiency at the data layer

The AI energy conversation has fixated on models and GPUs, but every agent, model, and inference call runs on the data layer beneath them, and that’s the one place a CIO can actually move the numbers.

“You can’t control consumption at the model layer,” says Romanenko. “Agents consume what they consume. But you can control efficiency at the data layer, and for most enterprises that’s the only real lever they have. Optimize search, retrieval, and vector indexing where the work actually happens and you cut compute, cost, and carbon at the same time. Ignore it, and it’s like running the heat with every window open.”

Ann Dunkin, distinguished professor of the practice at Georgia Tech, adds that CIOs who bring models in house and run them in their own infrastructure, or in the cloud infrastructure of their choosing, can have more control over the sustainability of inference, as well as of their costs and how their data is used.

Fine tune the application layer

When balancing a mix of commercial AI packages and custom-built code, costs can quickly spiral due to inefficient design and orchestration, redundant APIs, and unoptimized model routing.

With inference calls costing approximately 10 times that of conventional web queries, for custom AI applications, it’s important to design them to only use probabilistic code where necessary. Since many custom applications utilize a combination of both probabilistic and deterministic code, this is exactly where software developers need to make smart choices in their designs.

Other techniques to fine tune the application layer include semantic caching, intelligent model routing, and internal AI capability registries. “CIOs can implement intelligent routing solutions to select the most cost-efficient model for every prompt,” says Dunkin. “The most flexible routing solutions can drop into a user’s existing environment and orchestrate the actions of the company’s existing models.”

For CIOs looking to maximize the business value of every AI application in their portfolio, these new considerations, including new metrics, tools and approaches from the infrastructure layer all the way up to the application layer, should be an essential part of the equation.

When Anthropic unveiled Project Glasswing and the Mythos model, much of the discussion focused on the capabilities themselves.

Security leaders debated what these systems could mean for vulnerability discovery, exploit development and the pace of offensive innovation. Researchers examined technical benchmarks. Industry observers questioned how quickly these capabilities might fall into attackers’ hands.

Those conversations are important. They also point to a larger question that predominates my discussions with CISOs: How much time do we have?

Over the past year, conversations about AI in cybersecurity have changed noticeably. Twelve months ago, security leaders wanted to understand whether AI could meaningfully improve security operations. They wanted to know whether it could accurately investigate alerts, reduce analyst workload and operate reliably in production environments.

Today, security leaders are asking about timelines, implementation, how quickly AI is changing the threat landscape and what that means for how security teams operate.

Anthropic’s Mythos and Glasswing, OpenAI’s Daybreak and advances in DeepSeek accelerate those conversations. Each development provides another glimpse into the pace at which AI capabilities are advancing.

AI now reasons through security problems that historically required highly specialized expertise. The implications span vulnerability discovery, attack-path analysis, reconnaissance, social engineering and security operations.

The shift reflects a broader reality: cybersecurity is entering a period where the pace of adaptation may matter as much as the quality of defenses themselves. AI is accelerating both offense and defense simultaneously. Organizations are quickly redesigning security operations around that reality.

One consequence is becoming increasingly visible. For years, cybersecurity teams invested enormous effort in discovering threats, identifying vulnerabilities, gathering telemetry and collecting intelligence. AI is accelerating many of those activities simultaneously. Visibility is improving. Discovery is accelerating. Investigations are becoming faster and more comprehensive.

The bottleneck is beginning to move. The challenge increasingly centers on how quickly organizations can act on what they know. The organizations that gain an advantage may not be the ones with the most information. They will be the ones who can operationalize that information the fastest.

The timeline is compressing

Cybersecurity has experienced many major technology transitions. Cloud computing changed infrastructure. Mobile devices expanded the attack surface. Digital transformation connected systems that were previously isolated.

AI introduces a different dynamic.

Most technology transitions unfolded over years. Organizations had time to evaluate, pilot, deploy and gradually adapt operating models.

The current AI cycle moves at a different pace.

Capabilities improve continuously. New models arrive every few months. New research emerges every few weeks. Security teams absorb developments at the same time attackers do.

Vulnerability discovery provides a useful example. Security teams have long operated around a familiar cycle of discovery, validation, remediation and protection. AI systems accelerate every stage of that process. Similar patterns exist in phishing, reconnaissance, social engineering and attack planning.

A vulnerability that once moved through that cycle over weeks increasingly now moves through those stages in days or, in some cases, hours.

Attackers are already operating at the speed of AI. Defenders are now focused on reaching the same level of operational speed.

This shift is changing the questions CISOs ask.

Early discussions focused on capability. Could AI investigate alerts accurately? Could it operate reliably in production environments? Could it be trusted with meaningful security work?

As organizations gained experience with AI, the discussion shifted toward implementation. Security teams began evaluating where AI could create operational leverage and how quickly they could deploy it into existing workflows.

Today, many CISOs are focused on timing.

The pace of advancement is influencing planning horizons, budget decisions and operating-model discussions. Security leaders are evaluating how quickly they can introduce AI into investigations, threat hunting, detection engineering and response workflows. Boards are asking questions. Executive teams are paying attention.

Security programs that once viewed AI as a future initiative increasingly view it as a current operational priority.

The industry is moving from evaluating AI as a technology to incorporating AI as a security capability.

The timeline compression creates pressure on the traditional security operations model. Investigation speed, response speed and defensive coverage increasingly determine whether organizations can keep pace with adversaries operating with AI assistance.

Security operations are entering a new phase

The impact of AI is becoming particularly visible inside the SOC.

Many security operations centers were built around a straightforward assumption: alerts flow to human analysts who conduct investigations. Operational capacity scales primarily through hiring.

The volume of security data, the number of alerts and the complexity of modern environments have steadily increased. Security teams have responded by building processes, adding tools and creating specialized analyst roles.

AI introduces a new source of operational capacity.

Investigations that require analysts to examine dozens or hundreds of artifacts across endpoint, identity, cloud, network and email systems can now be performed in minutes. Analysts gain access to investigative depth and consistency that would be difficult to achieve manually at scale.

Many security leaders now view this capability through the lens of operating model design. They are examining how investigations are performed, how work is distributed and where human expertise creates the greatest value.

The evolution of the analyst role

One of the most important developments emerging from early production deployments is the evolution of analyst responsibilities.

Security analysts remain central to security operations. Their expertise becomes even more valuable as AI systems take on larger portions of investigative work.

Threat hunting, detection engineering, response strategy, governance and oversight are receiving increased attention. Analysts spend more time shaping how investigations are conducted, evaluating outcomes and improving overall security operations.

Many organizations are already beginning this shift.

Teams are investing more heavily in proactive security activities. Detection engineering programs are expanding. Threat hunting is becoming more accessible. Analysts are spending more time improving systems and less time repeating investigative tasks.

These changes create what I think of as an analyst-amplified SOC: an environment where AI expands the reach of security professionals and enables deeper security work across the organization.

Trust is critical and it doesn’t have to compromise speed

Faced with a compressing timeline, the instinct is to treat speed and trust as a trade-off, i.e., move faster, verify less. That trade-off feels inevitable. It isn’t.

You don’t trust AI in the abstract. You trust that a system understands your tools, your telemetry and the edge cases that only exist in your network. The problem was never speed. It’s speed without context. The faster a context-blind system runs, the more decisions you’re left unable to verify.

The tension eases when the system is quick to deploy and tunes to your environment once it’s there, rather than treating every network the same. Speed stops being the thing you trade against trust. The more it learns about your environment, the sharper and more trustworthy it becomes, so the two compound rather than compete. Trust still develops through operational evidence such as measurable outcomes, visibility into decisions and consistent performance. But where that evidence accrues matters.

The organizations making the fastest real progress understand this. They don’t compromise quality and trust for speed. They invest in AI that earns trust inside their own environment, so they don’t have to choose.

Leadership during a period of rapid change

The conversations surrounding Mythos and Glasswing reflect a broader reality facing security leaders.

AI is becoming part of both offense and defense. Security teams are incorporating it into investigations, detection engineering, response workflows and threat hunting. Attackers are incorporating it into their own operations.

Security leaders have an opportunity to modernize operating models, expand defensive capacity and build organizational experience while these capabilities continue to evolve.

The organizations making progress today are investing in readiness. They are building experience, adapting workflows and preparing teams for a new model of security operations.

The next phase of cybersecurity will be defined by how effectively organizations combine human judgment with machine-scale execution.

The question facing security leaders is increasingly clear: How quickly can their organizations adapt to a continuously changing threat environment?

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

As the CSO grows in prominence, security leaders are increasingly earning a seat at the executive table, reporting directly to the CEO with the expectation to help drive business strategy and ensure organizational success.

Reporting to the CEO unlocks greater access and influence for security leaders, and while CSOs who report to their organization’s CIO still have clout, it’s a very different experience picking up the phone to speak directly with the CEO as a strategic partner.

Regardless of reporting structure, CSOs must clearly understand what they are being tasked to solve. That might sound simple, but making the leap to being a CEO’s direct report requires a new perspective, a different set of skills, and a business-level focus on metrics to do so.

We asked several current CSOs, CEOs, and IT staffing experts for advice on how security executives can best navigate a direct reporting relationship with their CEO. Offering insights below are George Gerchow, CSO at Bedrock Data and member of the IANS faculty; Matt Chiodi, CSO of Cerby; Chris Schueler, CEO at Cyderes; and Greg Fuller, vice president of the Technology Skills Suite at Skillsoft.

1. Understand how the CEO views your role

Most CEOs expect that, when you report directly to them, you fully own your functional area. Whether it’s cybersecurity, operations, or finance, they look to you as the expert in that domain. The CEO may have opinions, but ultimately, you are expected to lead and provide direction.

CEOs expect their CSO to be a true strategic partner, not just a risk reporter — connecting cybersecurity to revenue protection, regulatory compliance, customer trust, and operational resilience. In turn, CSOs should expect CEOs to treat governance as a strategic enabler, not a bureaucratic necessity.

2. Power up on skills vital to your organization at an executive level

On the technology side, AI and machine learning, cloud security, incident response, zero trust architecture, and governance, risk, and compliance (GRC) are the areas where threats evolve fastest and strategic leadership has the greatest impact. 

Equally important are “power skills”: communication, critical thinking, adaptability, and emotional intelligence. The ability to translate complex risk into business terms is what separates a strong CSO from a purely technical one. Skills, not titles, define effectiveness in the eyes of a CEO.

3. Take advantage of your direct access

Direct access to the CEO will enable you to influence strategy, shape resilience planning, and ensure cybersecurity is treated as a business imperative rather than a cost center. That authority is strongest when the CEO understands cybersecurity as a strategic lever, not just a technical function. 

While a direct reporting relationship gives you access to the CEO, it also comes with the responsibility to operate at that level. You need to provide clear, executive-level visibility into your cybersecurity program.

4. Brush up on business translation

A CSO who leads with business alignment will always carry more influence when they can translate risk into business language rather than technical jargon. Building programs that must survive an IPO, a FedRAMP audit, and real customer scrutiny forces you to tie security to revenue and trust.

The most valuable skill is translation — defining technical risk in terms of executive action and business impact that a CEO and a board can act on. You must build trust through transparency. These are the human skills that complement technology, creating a collaborative human-AI dynamic where leaders make faster, better-informed decisions. 

5. Treat conversations as risk assessment opportunities

Highly effective security leaders treat every business conversation as a risk conversation in disguise. That mindset is what largely separates a great CSO from a great technologist. Earn the CEO’s trust by speaking business first, security second. Translate every risk into revenue, reputation, or regulatory exposure.

Remember, a good CEO wants a translator, not an alarm system. They expect no surprises, a clear read on the risks that matter, and a security leader who helps the business move faster rather than slowing it down.

6. Define what a successful relationship should look like and put it in writing

Regardless of the reporting relationship, start by defining the end goal and putting it in writing. It will evolve over time, but having that initial clarity is critical. This is especially important when you’re new in a role and aiming to make your first 60, 90, or 120 days, and your first year, successful. In such cases, it’s essential to align early.

Do that collaboratively, and document it.

7. Prioritize trust and candor

The CEO needs to trust that the CSO isn’t sandbagging, and the CSO needs enough psychological safety to deliver bad news fast. When those conditions exist, security becomes a strategic asset — not a cost center.

To that end, focus on clear communication above all, and present yourself as part of a team, not a solo player. Stay calm under pressure during incidents, and treat people as peers rather than policing them. The leaders who last build trust before they need it.

8. Treat governance as a strategic competitive advantage

The strongest partnerships also share a commitment to governance as a competitive advantage.

Governance is the brakes that let you drive fast safely. When a CSO and CEO are aligned on that principle, the organization can innovate with AI while maintaining oversight and protecting against unnecessary risk. The result is an organization that does not just react to threats but builds resilience into how it operates.

9. Set clear goals and measure progress

Setting clear goals and measuring progress against those goals is essential. When expectations are clear, the areas you need to focus on become much clearer. It doesn’t solve every problem, but aligning early with your leadership, whether that’s a CEO or a CIO, can significantly reduce the pressure you may feel.

Also, never let your boss be surprised. This is where being clear on goals and consistently tracking both leading and lagging metrics becomes especially important, particularly in a direct reporting relationship with the CEO.

10. Be willing to endure challenge and discomfort

Finally, persistence and a willingness to endure discomfort for something that matters more than the pain itself are critical to surviving in this relationship. The role of a cybersecurity leader is often thankless. If you’re doing your job well, no one really notices.

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

The number everyone quotes, and no one acts on

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

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

The six-month cycle problem

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

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

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

Subtraction is a strategy

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

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

The HALT framework: Horizon, Allocation, Liquidation, Tracking

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

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

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

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

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

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

Evaluation criterion	0	1	2
Horizon assigned (H1 / H2 / H3) and documented before funding
Success metric matched to the horizon, not a default quarterly ROI
Kill line set: Named milestone and date, agreed at funding
Owner named with explicit authority to stop the initiative
Fits a deliberate allocation band, not an accidental addition
Odds-raising path documented: Buy or partner and an integration plan

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

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

Review test	Status
Milestone for this horizon met or credibly on track	PASS / FAIL
Burn within plan to the next milestone	PASS / FAIL
Still fits the allocation band, with no quiet horizon drift	PASS / FAIL
Owner confirms continued strategic fit	PASS / FAIL

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

The cost of the timing error

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

The governance return the board has been waiting for

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

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

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

The head of the US government’s AI testing institute, Chris Fall, has resigned about three months after taking charge of the Center for AI Standards and Innovation (CAISI), the federal organization responsible for evaluating advanced artificial intelligence models for safety and security.

Current National Institute of Standards and Technology NIST Director Arvind Raman will serve as acting CAISI Director following Fall’s departure while continuing to oversee the Commerce Department office responsible for the institute, the Daily Signal reported, citing two people familiar with the matter.

A Commerce Department spokesperson who spoke to the publication did not disclose a reason for the resignation.

Fall assumed leadership of CAISI in April after the Trump administration reorganized the former US AI Safety Institute under NIST. The institute develops methodologies for evaluating frontier AI models and works with AI developers on voluntary technical assessments covering areas such as cybersecurity, model misuse, reliability and other risks associated with increasingly capable AI systems.

The leadership change comes as governments and AI companies continue developing technical approaches for evaluating frontier AI models while enterprises expand deployments of generative AI and agentic AI across business operations.

In recent months, the Commerce Department has taken a more active role in AI policy involving advanced models, placing greater attention on how the federal government evaluates technologies with potential national security implications.

Continuity matters more than personalities

CAISI works with AI developers such as Anthropic, Google’s DeepMind and OpenAI on voluntary evaluations of frontier AI models and develops methodologies for testing model capabilities and risks. The institute does not regulate AI developers or certify commercial AI systems.

For enterprises, those evaluations are one source of technical information alongside vendors’ own testing, third-party security assessments and internal AI governance programs.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said enterprises should focus less on the individual leading the institute and more on whether its technical work continues with the same level of consistency and transparency.

“Leadership churn at CAISI weakens the signal long before it weakens the science,” Gogia said. “The testing has not stopped. Its authority simply does not travel as cleanly once the leadership does not.”

According to Gogia, the more important question for enterprises is not whether the institute’s evaluation work will continue but whether the processes supporting those evaluations remain stable.

“The instinct is to ask whether the pipeline is breaking,” he said. “The more useful question is where the pipeline now sits.”

Enterprises still carry the burden of AI governance

Gogia said organizations should continue treating government-led AI evaluations as one input into their governance processes rather than as evidence that a model is inherently safe for enterprise deployment.

“A government evaluation was always a signal, never a certificate,” he said. “A signal loses value the moment its issuer becomes unpredictable.”

He said enterprises should instead monitor whether CAISI maintains consistent evaluation methodologies, continues publishing technical findings and preserves continuity within its research teams under interim leadership.

“The name on the door is not the signal. The behaviour underneath it is,” Gogia said.

Gogia also cautioned against linking Fall’s resignation to recent Commerce Department actions involving AI policy or export controls, noting that there is no public evidence connecting the two.

“CAISI evaluates; it does not enforce export controls, because it holds no such power,” he said. “This is not a testing body reaching for enforcement. It is enforcement reaching past the testing body.”

With Raman assuming the role on an interim basis, the next significant milestone for enterprises will be the appointment of a permanent director, and whether the institute’s evaluation programs continue without disruption, the analyst said.

Gogia said the successor’s mandate may prove more important than the individual selected.

“A CAISI result is not a safe harbour,” he said. “It informs an obligation; it does not discharge one.” NIST did not immediately respond to a request for comment.

What if the next breakthrough in Enterprise AI doesn’t come from computer science alone?

What if it comes from applying principles that physicists have understood for more than a century?

According to Gartner, rising token-driven AI spend is straining budgets and challenging cost justification. As organizations race to deploy generative AI and agentic systems, token consumption dominates nearly every executive discussion: How many tokens did we use? How much did inference cost? Can we reduce our AI bill?

These are important operational questions. But they are not the strategic questions.

I believe the economics of enterprise AI can be viewed through the lens of three well-established principles from thermodynamics: the conservation of energy, entropy, and exergy.

While these principles describe physical systems — not AI —they offer a useful way to think about how organizations should measure AI success.

Principle 1: Value is created through transformation

The 1^st Law of Thermodynamics tells us that energy cannot be created or destroyed. It can only be transformed.

Enterprise AI presents a similar management lesson: Tokens are not valuable because they are consumed; they become valuable only when they are transformed into business outcomes: A faster loan application decision. A better customer experience. Faster and more accurate software. Reduced fraud. Higher employee productivity. A new product. A strategic insight.

The executive question therefore is not, “How many tokens did we consume?” It is: “How much business value did those tokens create?”

This leads to a new executive metric: return on tokens (ROT).

Just as organizations measure return on investment, they should begin measuring the business value generated for every million AI tokens consumed.

The organizations that win will not necessarily consume fewer tokens. They will generate more value from every token they use.

Principle 2: Every transformation creates waste

The 2nd Law of Thermodynamics teaches us that every energy transformation introduces inefficiencies.

Some energy inevitably becomes less useful for doing work.

The same pattern appears in enterprise AI: Not every token contributes equally to business outcomes.

Some are spent on:

• Repeated prompts
• Oversized context windows
• Redundant reasoning
• Hallucinations requiring correction
• Multiple agents performing the same work
• Expensive models solving simple problems

Those tokens are not “lost.” They simply produce very little business value.

I think of this as token entropy. Every enterprise deploying AI will experience it. The goal is not to eliminate token entropy completely — that would be unrealistic. The goal is to continuously identify it, measure it and reduce it. Because every unnecessary token represents an opportunity to improve both cost and business performance.

Principle 3: Useful work matters more than energy consumed

Thermodynamics introduces another important idea: Exergy.

Unlike energy, exergy measures how much energy can actually be converted into useful work. Two systems may consume the same amount of energy while producing dramatically different results.

The same is true for enterprise AI.

Imagine two companies each consuming one billion tokens. One produces meeting summaries. The other transforms claims operations, accelerates software delivery, detects fraud, improves customer retention, and creates new revenue opportunities. Both consumed the same number of tokens. Only one extracted significantly more business value.

Borrowing this concept as a management analogy, I call this token exergy.

Token exergy represents an organization’s ability to convert AI intelligence into meaningful business outcomes:

• High token exergy means AI is solving important business problems.
• Low token exergy means AI is generating activity without creating proportional enterprise value.

The distinction matters, because activity is not the same as impact.

A new responsibility for CIOs

For years, CIOs have monitored infrastructure: Cloud costs, storage, network utilization, GPU consumption.

These metrics remain important, but they tell only part of the story.

Token usage needs to be measured, planned, optimized and governed with the same discipline as any other cloud resource. This means that the next generation of CIO dashboards should answer different questions:

• What is our return on tokens?
• Where is token entropy reducing our effectiveness?
• How much token exergy are we generating?
• Which AI initiatives produce the greatest business value?
• Which use cases create the strongest competitive advantage?

These are no longer technology metrics. They are business metrics.

The next generation of CIOs will not simply deploy AI. They will manage an economy of intelligence.

Their role will resemble that of a portfolio manager — allocating AI capacity where it creates the greatest enterprise value, reducing waste and continuously improving the productivity of every autonomous workflow.

That responsibility cannot be fulfilled by dashboards alone.

It requires an intelligent layer capable of observing, learning and optimizing the entire AI  ecosystem. Three-layer enterprise agentic architecture Will enable this.

The next competitive advantage

Every major technology revolution eventually shifts from measuring inputs to measuring outcomes:

• Factories stopped measuring coal consumption and began measuring productivity.
• Cloud computing evolved beyond server utilization to business agility.
• Digital businesses measured customer acquisition costs and lifetime value.

Enterprise AI is approaching the same inflection point. Organizations that focus only on token costs will optimize for efficiency. Organizations that measure return on tokens, minimize token entropy and maximize token exergy will optimize for business transformation.

That is a fundamentally different objective. And I believe it will separate AI leaders from AI followers.

Because in the end, the future of enterprise AI will not be determined by how many tokens an organization consumes. It will be determined by how effectively those tokens are transformed into lasting business value. The AI adoption spending spree is over. Time to focus on value.

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

Something interesting happened during an internal evaluation of AI meeting transcription tools at Tungsten Automation. The products worked. They weren’t bad. But sitting across from the pricing, we kept asking the same question: what exactly are we paying for?

We already had a secure enterprise AI environment. Building a meeting summary workflow took days, not months. We customized the outputs, injected our own internal context, and controlled security our way instead of working around someone else’s roadmap. We built it. It works better. We own it.

That’s not a knock on those vendors. It’s a signal of something more fundamental happening across enterprise software.

The moat was never the product

For two decades, SaaS rode a favorable asymmetry: building internal tools was hard, integrations were messy, and even modest automation required developers and long timelines. Buying was faster and cheaper than building. That asymmetry fueled the explosion of SaaS into every corner of the enterprise stack.

AI is collapsing that asymmetry. Large language models and agentic workflows can orchestrate APIs, move data between systems, generate interfaces, and automate business logic with a fraction of the engineering effort required even two years ago. The integration friction that once protected entire product categories is evaporating.

The vendors most exposed are not the deeply embedded enterprise platforms. They’re the lightweight workflow layers, the products that essentially put a polished interface on top of accessible data and relatively straightforward processes. Reporting dashboards. Meeting tools. Narrow productivity applications. These products created value by simplifying implementation. That rationale is getting harder to sustain when implementation is no longer the real barrier.

Here’s the part most analyses miss: it’s not just that AI makes development faster. It’s that agents change the integration model entirely. For 30 years, enterprise software was built for humans navigating UIs. Agentic systems don’t use UIs. They call APIs, read from multiple sources simultaneously, and move data freely across systems. The switching costs that once made incumbent software sticky are collapsing, because an agent doesn’t care which UI it used last quarter.

The SaaS that survives

The question isn’t whether SaaS survives. It’s which SaaS survives.

The companies with durable positions are not the ones with the cleanest interface. They’re the ones that transfer operational risk customers genuinely cannot absorb themselves. Compliance. Regulatory certification. Accumulated domain expertise. Liability.

Think about compliant invoicing across 140 countries. That’s not a workflow someone builds in a sprint. The certifications alone take years. A single regulatory change in one jurisdiction can break an AP process for a global enterprise overnight. Customers don’t pay for that capability because it’s technically complex. They pay because they cannot afford to own the risk of getting it wrong.

That’s the distinction that matters: AI lowers the cost of building software. It does not lower the cost of absorbing risk. The vendors who understand this are building durable businesses. The ones who don’t are quietly subsidizing their customers’ internal build programs.

Software sells features. Platforms sell accountability.

The prototype trap

The danger for enterprise buyers right now is overcorrection. Every successful prototype looks like a cost-saving opportunity. Very few survive the jump to production.

Building a workflow with generative AI is becoming straightforward. Maintaining it is not. Models evolve. Outputs drift. Governance requirements tighten. What worked cleanly in a controlled environment behaves differently at scale, and the failure mode is worse than traditional software. Rule-based automation, when it fails, fails obviously. Agents fail silently, confidently, at scale, often with a completely reasonable-sounding explanation.

Engineering teams that take on AI-powered systems need to solve for observability, model drift, access controls, audit trails, and long-term maintenance ownership. In regulated industries, they need to demonstrate exactly how the system reached every decision. That’s not a weekend project. That’s an ongoing operational commitment that compounds over time as models change and regulatory requirements evolve.

Before a team decides to replace an external platform with internal AI tooling, the honest question isn’t, “Can we build this?” The real question is, “Are we prepared to own this in production, for years, as the underlying models change beneath us?” Sometimes the answer is yes. Often the answer is no, and the true cost only becomes visible after the vendor contract is canceled.

Build vs. partner: a sharper frame

The build vs. buy framing has always been too binary. The right question is build vs. partner.

Partner for the capabilities where risk transfer, regulatory complexity, and domain expertise create genuine value your team cannot replicate. Build for the capabilities that actually differentiate your business from your competitors. Don’t burn your best engineers rebuilding compliant invoice processing or production-grade document extraction. Those aren’t competitive advantages. They’re table stakes, and someone else has already paid the cost, across decades, to make them reliable.

The organizations getting this right are honest about where they create unique value. They focus development there, and partner for everything else. The ones getting it wrong are vibe-coding solutions to non-differentiating problems while their actual competitive moat goes unattended.

The true value of software

We’re not watching the death of SaaS. We’re watching the end of the friction-based value proposition: the idea that software is worth renewing because integration used to be painful. That rationale is largely gone.

What survives is software that does something customers cannot reasonably replicate internally: absorb risk, maintain regulatory compliance, deliver operational reliability at scale, and bring genuine domain expertise into a production-grade system that someone else already stress-tested for years.

The vendors who recognize this are already repositioning around accountability, governance, and outcomes. The ones who haven’t will find the next renewal conversation noticeably harder.

Software sells features. Platforms sell accountability. That distinction is about to separate a lot of winners from a lot of cautionary tales.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

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

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

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

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

The next AI bottleneck is the infrastructure behind the model.

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

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

Pilots hide the hard part

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

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

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

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

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

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

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

AI is becoming an integration problem

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

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

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

That is why the CIO question is changing.

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

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

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

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

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

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

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

Latency will become a trust issue

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

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

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

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

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

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

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

Observability has to expand

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

AI needs that, but it also needs more.

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

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

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

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

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

Data readiness is still underestimated

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

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

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

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

That is a real risk.

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

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

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

Security cannot be added later

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

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

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

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

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

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

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

The CIO has to define the operating model

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

The CIO sits in the middle of all of it.

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

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

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

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

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

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

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

That is the shift CIOs need to lead.

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

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

Attackers are increasingly using AI agents to automate all phases of cyberattacks, prompting the security industry and enterprises to find new network defense approaches. One technique that shows promise is to intentionally plant decoy files with prompts that trigger the content safety guardrails built into LLMs with the goal of crashing rogue agentic workflows.

Using decoy resources as tripwires that alert defenders about potential unauthorized access is not a new idea in cybersecurity. These are known as canaries — after the canary in the coal mine early warning system — and can be fake documents, AWS access keys, database dumps, DNS records, and even URLs that would not be queried by legitimate processes, but would be attractive targets for attackers.

What’s new in the approach devised and tested by security firm Tracebit is to use these decoy resources not merely to trigger alerts, but to actually stop AI agents, buying defenders more time. Dubbed “context bombing,” the technique takes advantage of the fact that LLMs are inherently vulnerable to prompt injection — acting on instructions they might encounter inside the data they process.

Enterprises that build their own AI agents have to worry about malicious prompts placed by attackers on web pages, emails, documents, code comments, and in other third-party resources those agents might access. With no defenses in place, companies risk their own agents being hijacked and used against them to perform unauthorized actions. But the malicious AI agents used by attackers have the same vulnerability.

“We call the defensive version a context bomb: a short piece of text designed to trigger a model’s safety guardrails, planted directly in the attacker’s path — a decoy secret, environment variable, or DNS record,” Sam Cox, Tracebit’s CTO, said in a blog post. “An AI agent that reads it will frequently refuse to continue. You still get the alert; and the attack now halts early instead of merely being detected.”

Context bombing triggers massive drop in attack success rate

Tracebit’s tests performed in an AWS test environment cut the success rate normally achieved by AI models across multiple attacks paths by up to 90% by simply adding instructions that would trigger their content safety guardrails. LLMs are trained to refuse answering questions about creating biological, chemical, or nuclear weapons, or, in the case of Chinese open-weight models, sensitive political topics such as the Tiananmen Square massacre.

Furthermore, once one of these banned instructions make it into the context window, the whole session is poisoned, and the model will often refuse to continue without manual intervention. The researchers ran many tests to find short strings that would trigger model safety guardrails reliably, but it’s worth noting that the identified strings were different between the tested models: Claude Opus 4.8, Gemini 3.1 Pro, GLM 5.2, DeepSeek V4 Pro, and Kimi K2.6.

During baseline tests the AI agents managed on average to obtain full account admin in 54% of the 154 attack runs and full compromise (admin + persistence) in 36% of tests. With the context bombs in place, their success rate dropped to 5% for admin access and 1% for full compromise. Also, in 91% of baseline attack runs, the agents managed to complete at least one of ten possible attacks paths, but their average success rate dropped to 15% with the context bombs.

The models from Western AI labs — Opus and Gemini — proved the most capable at reaching full admin access, with 93% and 70% success rates, but were also the most impacted by the context bombs with both their success rates dropping to 0%. This shows that the content safety guardrails are much stronger in these models compared to the Chinese ones that were tested.

Attackers experimented with safety refusals first

The Tracebit researchers had already been experimenting with AI canaries for alert purposes. A paper published in May showed that canaries alerted defenders in 95.9% of 162 successful attack runs performed with AI agents using 10 different AI models. The alerts were triggered 8 minutes before the agents performed critical actions, while the runs required 14 minutes on average to reach admin access.

During those tests the researchers observed that if they instructed the models that the network might include deception, their success rate for full admin access and persistence dropped from 20% to 3% on average.

Then in June, researchers from security firm Socket.dev came across a software supply chain attack involving malicious PyPI wheels that contained prompt injections with content designed to trigger safety guardrails inside AI models. The malicious prompts were included in code comments at the start of the files and the purpose was likely to evade detection from LLM-powered security scanners.

“This header appears designed for AI-mediated analysis, not for Node, Bun, or Python,” the Socket.dev researchers said at the time. “It attempts to derail scanners or analyst copilots that feed the beginning of a file to a language model without clearly isolating the content as untrusted data. In weak pipelines, this can cause refusal behavior, prompt confusion, context pollution, or premature classification before the scanner reaches the actual malware.”

The Tracebit researchers then had the idea to flip the script and trigger such safety refusals through their canary technique against malicious AI agents. So not only does the agent run stop, but an alert is also triggered because the canary was accessed.

There is a risk that the canaries could also be discovered and accessed accidentally by legitimate LLM-powered tools used by engineering or security teams. But at the same time this means organizations could potentially deploy such canaries in sensitive places to stop their own AI agents that might become hijacked or go off the rails on their own.

There are many reports online where AI models performed destructive or unauthorized actions like deleting databases and folders or elevating their privileges because they got struck in failure loops and explored creative ways to complete their tasks. This is even more common with autonomous AI agents that are tasked to reach a goal without human intervention or supervision.

“The speed of autonomous AI attacks is why deception is climbing the priority list for security programs,” Tracebit’s Cox said. “When the attack chain takes minutes rather than days, every minute of response time you can claw back matters — and a control that stops the attacker outright, rather than just reporting them, changes the economics significantly.”

Providers and deployers of AI systems: You only have a couple of weeks left until you must explicitly inform users when they are interacting with AI content.

To assist in the effort, the European Commission (Commission) has published guidelines to help AI deployers get in line with the AI Act’s transparency obligations, which will begin to go into effect on August 2.

After that, companies providing AI systems must alert users when they are interacting with AI. They must also tell users when they have been exposed to deepfakes, “emotion recognition,” or biometric categorization systems, or when they are given AI-manipulated content in matters of “public interests without human review or editorial control.”

Henna Virkkunen, the Commission’s executive VP for tech sovereignty, security and democracy, said in a statement, “with today’s guidelines, the Commission supports the smooth and effective application of the AI Act to make AI systems interacting with people such as chatbots and AI agents and AI content more transparent and trustworthy. These guidelines support providers and deployers in meeting their obligations under the AI Act, while helping citizens know when they are interacting with AI.”

Systems must include machine-readable markers to reveal such content, to reduce “the risk of deception and manipulation” and build public trust in AI.

“Generative systems have collapsed the cost of producing convincing content while the cost of judging it stands where it always stood,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. This requirement is “an attempt to restore friction to that imbalance.”

A company’s non-compliance could result in fines anywhere from €750K (about $856K) to €15M (about $17 million), or even up to 3% of its total worldwide annual revenue.

Transparency requirements

The EU AI Act’s transparency requirements apply to “natural or legal persons,” public authorities, agencies, or other bodies that develop AI systems, or have them developed, and place them on the EU market or into use under their name or trademark. This means all companies, regardless of whether or not they are EU-based.

“Systems placed on the European market, put into service there, or producing outputs used there are inside the field, wherever the developer sits,” Gogia noted.

Applicable systems must be intended to interact directly with “natural persons”; these systems include AI-enabled chatbots or conversational agents, AI companions, or coding agents. However, AI-enabled tools like recommender systems, spam filters, authentication, search and retrieval, transcription, text and code auto-completion, or predictive maintenance do not fall under the rule.

Specific outputs such as AI-generated text, images, video, and audio must contain a machine-readable mark. Deepfakes and public interest-related text created by AI without human review or control must be clearly labeled, however, deepfake content that is “artistic, creative, satirical, or fictional” is largely exempt.

AI content must be marked with one of three labels: “AI,” “Fully AI-generated,” or “Partially AI-modified.” For instance, “Fully AI-generated” applies when news summaries, music, art, or videos have been created without any human oversight (apart from prompting), while “partially AI-modified” could mean a person’s face is swapped into an authentic photograph to create a deepfake.

The three icons are publicly available for free use; enterprises can download zip files in PNG and SVG formats.

Most of the Act’s transparency rules begin to go into effect on August 2. But AI systems placed on the market before then will have some leeway; they must be in compliance by December 2.

However, a four-month allowance “on one obligation, for one population of systems, contingent on one procedural step, is not a strategy,” Gogia emphasized. Enterprises should plan to comply by August 2 and “treat any relief that arrives as margin.”

A consistent code of practice

Along with the transparency guidelines, the Commission has introduced a code of practice that essentially serves as a gesture of good faith. When signed, it can provide “legal certainty” and a “simple and practical” way to demonstrate compliance with the AI Act, according to the Commission. Signatories can also collaborate through the ‘Signatory Taskforce,’ which will share practices and advance technologies around marking and labeling practices.

Providers that choose not to sign must comply through other methods and demonstrate that those methods are “adequate” through assessment by surveillance authorities, according to the Commission.

Non-signatories “keep their flexibility, and will face more case-by-case scrutiny for it,” said Gogia.

Criteria for compliance

Shashi Bellamkonda, principal research director at Info-Tech Research Group, pointed out that the transparency requirements apply to content only when three criteria are met: It has been published, is informative to the public, or is on matters of public interest.

B2B business content or blogs may not need an AI disclosure if they do not meet these criteria, he noted. Also, published text that has undergone human review or is under editorial control does not need to be labeled. Editorial control means that a person must hold the ultimate legal responsibility for the publication of the content.

Many companies like Google, Adobe, and LinkedIn have already established ways to identify images marked as AI-generated. Meta has made it a requirement, but the creator has to add the AI-generated label, Bellamkonda said.

“This is a good move for guardrails around public information, and companies with good compliance and ethical oversight may not have to worry about this,” he noted. But as a general practice, companies should disclose AI-generated content and state whether it has been human reviewed.

Creating a transparency pipeline

Establishing full transparency means identifying who carries the responsibility for the content, whether the marking survives real use, not just testing, and what evidence will defend the decision, Gogia said.

Concerns cluster around responsibility, durability and evidence. Several organizations usually touch one piece of content, and none controls the whole chain, which is why contracts become the “pressure point,” he said. Most current agreements were written to deliver software and say “almost nothing” about provenance persistence, verification access, or evidence retention.

The durability concern is the most difficult, Gogia noted, because marking performs well in controlled settings but “badly in ordinary life.” Meta, for one, said its invisible watermark was designed to survive cropping; a published test, however, found the company’s preview detector missed 55% of cropped images.

“CIOs should ask which platform can actually provide evidence before believing its dashboard,” said Gogia.

Disclosure of AI use must be “clear, distinguishable and accessible,” he emphasized. “A notice buried in lengthy terms, or reachable only through determined clicking, satisfies nobody, least of all a market surveillance authority.”

Sustained compliance is a “living control” requiring a central record of systems, duties and evidence; testing taking place where the user meets the control rather than where the developer built it; and continuous supplier assurance. Enforcement will vary by country, so keep one common baseline with local overlays, Gogia said.

His advice: Inventory every system that talks to people, generates content, or gauges sentiment; classify provider and deployer roles; place disclosures at first interaction; define substantive human review; keep the evidence.

Marks and provenance signals should be tested after content undergoes cropping, compression, translation, transcription, and other editing, Gogia said. A useful audit starts from a real output and follows its “pulse” through generation, editing and publication, identifying at “each beat” the responsible party, the surviving mark, and evidence for exceptions. Missed labels should also be traced for root cause and recurrence.

To ensure compliance, before August 2, enterprises need a prioritized inventory, live disclosures on the highest-risk use cases, and a “named owner for every control,” he noted. In the first 30 days, they should stabilize and test; in the first 90 days, push requirements into procurement processes as a standing discipline. Procurement must secure commitments on marking methods, known failure modes, and evidence access, with explicit notice if/when any of them change.

“The sensible architecture is a common transparency baseline carrying traceability, responsibility, and evidence, with jurisdictional overlays for language, sector rules, and local practice,” Gogia said.

This article originally appeared on CIO.com.

Providers and deployers of AI systems: You only have a couple of weeks left until you must explicitly inform users when they are interacting with AI content.

To assist in the effort, the European Commission (Commission) has published guidelines to help AI deployers get in line with the AI Act’s transparency obligations, which will begin to go into effect on August 2.

After that, companies providing AI systems must alert users when they are interacting with AI. They must also tell users when they have been exposed to deepfakes, “emotion recognition,” or biometric categorization systems, or when they are given AI-manipulated content in matters of “public interests without human review or editorial control.”

Henna Virkkunen, the Commission’s executive VP for tech sovereignty, security and democracy, said in a statement, “with today’s guidelines, the Commission supports the smooth and effective application of the AI Act to make AI systems interacting with people such as chatbots and AI agents and AI content more transparent and trustworthy. These guidelines support providers and deployers in meeting their obligations under the AI Act, while helping citizens know when they are interacting with AI.”

Systems must include machine-readable markers to reveal such content, to reduce “the risk of deception and manipulation” and build public trust in AI.

“Generative systems have collapsed the cost of producing convincing content while the cost of judging it stands where it always stood,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. This requirement is “an attempt to restore friction to that imbalance.”

A company’s non-compliance could result in fines anywhere from €750K (about $856K) to €15M (about $17 million), or even up to 3% of its total worldwide annual revenue.

Transparency requirements

The EU AI Act’s transparency requirements apply to “natural or legal persons,” public authorities, agencies, or other bodies that develop AI systems, or have them developed, and place them on the EU market or into use under their name or trademark. This means all companies, regardless of whether or not they are EU-based.

“Systems placed on the European market, put into service there, or producing outputs used there are inside the field, wherever the developer sits,” Gogia noted.

Applicable systems must be intended to interact directly with “natural persons”; these systems include AI-enabled chatbots or conversational agents, AI companions, or coding agents. However, AI-enabled tools like recommender systems, spam filters, authentication, search and retrieval, transcription, text and code auto-completion, or predictive maintenance do not fall under the rule.

Specific outputs such as AI-generated text, images, video, and audio must contain a machine-readable mark. Deepfakes and public interest-related text created by AI without human review or control must be clearly labeled, however, deepfake content that is “artistic, creative, satirical, or fictional” is largely exempt.

AI content must be marked with one of three labels: “AI,” “Fully AI-generated,” or “Partially AI-modified.” For instance, “Fully AI-generated” applies when news summaries, music, art, or videos have been created without any human oversight (apart from prompting), while “partially AI-modified” could mean a person’s face is swapped into an authentic photograph to create a deepfake.

The three icons are publicly available for free use; enterprises can download zip files in PNG and SVG formats.

Most of the Act’s transparency rules begin to go into effect on August 2. But AI systems placed on the market before then will have some leeway; they must be in compliance by December 2.

However, a four-month allowance “on one obligation, for one population of systems, contingent on one procedural step, is not a strategy,” Gogia emphasized. Enterprises should plan to comply by August 2 and “treat any relief that arrives as margin.”

A consistent code of practice

Along with the transparency guidelines, the Commission has introduced a code of practice that essentially serves as a gesture of good faith. When signed, it can provide “legal certainty” and a “simple and practical” way to demonstrate compliance with the AI Act, according to the Commission. Signatories can also collaborate through the ‘Signatory Taskforce,’ which will share practices and advance technologies around marking and labeling practices.

Providers that choose not to sign must comply through other methods and demonstrate that those methods are “adequate” through assessment by surveillance authorities, according to the Commission.

Non-signatories “keep their flexibility, and will face more case-by-case scrutiny for it,” said Gogia.

Criteria for compliance

Shashi Bellamkonda, principal research director at Info-Tech Research Group, pointed out that the transparency requirements apply to content only when three criteria are met: It has been published, is informative to the public, or is on matters of public interest.

B2B business content or blogs may not need an AI disclosure if they do not meet these criteria, he noted. Also, published text that has undergone human review or is under editorial control does not need to be labeled. Editorial control means that a person must hold the ultimate legal responsibility for the publication of the content.

Many companies like Google, Adobe, and LinkedIn have already established ways to identify images marked as AI-generated. Meta has made it a requirement, but the creator has to add the AI-generated label, Bellamkonda said.

“This is a good move for guardrails around public information, and companies with good compliance and ethical oversight may not have to worry about this,” he noted. But as a general practice, companies should disclose AI-generated content and state whether it has been human reviewed.

Creating a transparency pipeline

Establishing full transparency means identifying who carries the responsibility for the content, whether the marking survives real use, not just testing, and what evidence will defend the decision, Gogia said.

Concerns cluster around responsibility, durability and evidence. Several organizations usually touch one piece of content, and none controls the whole chain, which is why contracts become the “pressure point,” he said. Most current agreements were written to deliver software and say “almost nothing” about provenance persistence, verification access, or evidence retention.

The durability concern is the most difficult, Gogia noted, because marking performs well in controlled settings but “badly in ordinary life.” Meta, for one, said its invisible watermark was designed to survive cropping; a published test, however, found the company’s preview detector missed 55% of cropped images.

“CIOs should ask which platform can actually provide evidence before believing its dashboard,” said Gogia.

Disclosure of AI use must be “clear, distinguishable and accessible,” he emphasized. “A notice buried in lengthy terms, or reachable only through determined clicking, satisfies nobody, least of all a market surveillance authority.”

Sustained compliance is a “living control” requiring a central record of systems, duties and evidence; testing taking place where the user meets the control rather than where the developer built it; and continuous supplier assurance. Enforcement will vary by country, so keep one common baseline with local overlays, Gogia said.

His advice: Inventory every system that talks to people, generates content, or gauges sentiment; classify provider and deployer roles; place disclosures at first interaction; define substantive human review; keep the evidence.

Marks and provenance signals should be tested after content undergoes cropping, compression, translation, transcription, and other editing, Gogia said. A useful audit starts from a real output and follows its “pulse” through generation, editing and publication, identifying at “each beat” the responsible party, the surviving mark, and evidence for exceptions. Missed labels should also be traced for root cause and recurrence.

To ensure compliance, before August 2, enterprises need a prioritized inventory, live disclosures on the highest-risk use cases, and a “named owner for every control,” he noted. In the first 30 days, they should stabilize and test; in the first 90 days, push requirements into procurement processes as a standing discipline. Procurement must secure commitments on marking methods, known failure modes, and evidence access, with explicit notice if/when any of them change.

“The sensible architecture is a common transparency baseline carrying traceability, responsibility, and evidence, with jurisdictional overlays for language, sector rules, and local practice,” Gogia said.

Last year Anthropic gave away one of the most successful things it has ever built. And, no, I’m not talking about Claude. I’m referring to MCP, the now ubiquitous Model Context Protocol, which Anthropic donated to the Linux Foundation’s new Agentic AI Foundation⁠. At the time, MCP was pulling nearly 100 million monthly SDK downloads across more than 10,000 active servers⁠, prompting the question as to why any company would give up such a popular piece of technology.

Google did much the same months earlier, handing its Agent2Agent (A2A) protocol to the Linux Foundation⁠ with AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow signing on as founding members. OpenAI, not to be outdone, supports remote MCP servers in its Responses API⁠, sits on the MCP steering committee, and contributed AGENTS.md to that same foundation alongside its fiercest rival’s protocol.

It’s like Game of Thrones, except the principal AI powers seek regime change through seeming acts of beneficence rather than violence. For those who have been around for a while, it’s also entirely predictable, following a similar script we’ve seen in the cloud, on-premises servers, and more. Platform companies don’t give away technologies they’ve stopped caring about. They give away technologies they no longer need to own because competitive advantage has shifted to new ground.

What does this mean for AI?

Gravity has shifted before

Google has long been an exceptionally active contributor to open source. As I wrote in 2017, Google wasn’t open sourcing TensorFlow and Kubernetes out of generosity but rather turning these open source assets into on-ramps for Google Cloud. Google was playing catch-up to AWS and Microsoft. As then Google product manager Martin Buhr said, the company hoped to “create a gravity well in the market for container-based apps [so] that a significant percentage of them will end up with us.”

In other words, platform companies routinely commoditize one layer of the stack so they can compete somewhere where they hold a stronger hand.

GitHub may be an even better example. Git is open. Anyone can host a Git repository and, once upon a time, different companies did just that. Yet GitHub became the default place software development happens for millions of developers. Nobody pays for Git, but lots of people pay for GitHub. We’re seeing this same phenomenon play out in AI.

Trading contributions for control

Anthropic and OpenAI have both pretended at being all for humanity’s good, but that’s not a good explanation for why they’re racing to give away things like MCP. The deeper reason is that the model itself has turned out to be a poor place to build a lasting moat, and they’re trying to figure out what’s next. As I pointed out recently, the frontier model leaderboards change almost weekly. As such, enterprises shouldn’t build their AI strategy around the assumption that any one vendor will remain permanently ahead on model quality. Instead, as I suggested, AI may be sexy, but the “dull reality” is connecting those models to enterprise data, workflows, etc.

The AI companies understand this better than anyone. Sure, they’ll continue spending billions training ever more capable models because frontier models attract developers, generate headlines, and open enterprise doors. But they’re also quietly acknowledging that benchmark leadership alone doesn’t create a durable platform.

Developers return to the places where their tools, workflows, teammates, and accumulated work already live. Enterprises double down on the systems where their data, permissions, governance, and business processes are already connected. Every new integration makes that destination a little harder to leave, and every new workflow increases its pull. That’s what MCP, A2A, etc., are all about: increasing gravity around the models.

Every major AI company wants to become the place where AI-assisted work naturally happens, and they’re now amassing armies of forward deployed engineers and trying other means to get legacy infrastructure to tie back to their frontier models. The enterprise incumbents want the same thing, but from the opposite direction. They don’t need to own the frontier; instead they need to connect the frontier to the systems that already safely run the business.

That’s why I’m skeptical whenever someone confidently predicts that AI will sweep away enterprise software. I’ve seen this movie before. Developers absolutely live on the frontier, but enterprises don’t. Enterprises create value by connecting new capabilities to decades of accumulated applications, data, policies, and business processes. The newest model matters, and so does the newest agent framework. But neither creates much business value until it’s connected to customer records, financial systems, supply chains, HR data, and everything else enterprises already depend on.

That’s where incumbents still possess enormous gravitational pull. My employer, Oracle, certainly believes so, just as Microsoft, SAP, Salesforce, and ServiceNow do. (Disclosure: I run developer relations at Oracle, which participates in the Agentic AI Foundation.) Ironically, open protocols strengthen that position rather than weaken it. If every model can speak MCP and every agent can interoperate through common standards, enterprises gain the freedom to adopt whichever frontier technology looks best without rebuilding every integration. The protocol becomes interchangeable.

Open standards don’t stop gravity

None of this diminishes the importance of open standards. MCP succeeded because it solves a genuine problem. Developers shouldn’t have to build a custom connector every time an AI application needs access to a database or other business system. Neutral governance also matters because nobody wants foundational infrastructure controlled by a direct competitor. But we shouldn’t confuse open interfaces with open markets.

An enterprise may find it easy to swap one MCP-compatible model for another while still remaining deeply dependent on the place where its prompts, evaluations, security policies, and employee habits have accumulated. Again, we’ve seen this before. Kubernetes made workloads dramatically more portable without making AWS, Microsoft Azure, and Google Cloud interchangeable. SQL has been standardized for decades, yet databases remain fiercely differentiated businesses. Standards reduce friction, but they rarely eliminate competitive advantage. They simply move it.

In like manner, Anthropic, Google, OpenAI, and others are happily standardizing how models, agents, tools, and enterprise systems communicate because they don’t expect the connection itself to determine the winner. Instead they expect to win by becoming the place where AI-assisted work naturally accumulates. Along the way, we’re going to see copious quantities of code given away, increasing developer productivity for all and outsized financial bonanzas for a few. Game on.

As AI becomes embedded in customer experiences, internal workflows, and throughout the supply chain, security leaders are being asked to do more than manage risk. They are being asked to help the business make more informed decisions and move faster.

At the same time, AI has evolved faster than the programs built to govern it.

The result is a widening gap between the pace of transformation and the ability of security, risk, privacy, compliance, and third-party risk teams to understand where the business is exposed.

Move Fast, Don’t Break Things

AI introduces risks like prompt injection and jailbreaks, but the issues keeping CISOs awake at night are more familiar: over-permissioned accounts, poor logging, credentials left in old repositories, sensitive data scattered across systems, and weak access controls. 

AI gives those risks more speed, reach, and impact. 

When AI agents are connected to enterprise data, workflows, vendors, and applications, the blast radius of existing weak spots expands quickly. A low-severity incident now becomes harder to detect, more difficult to remediate, and more consequential for the business. 

This is why boards and executive teams are looking to security leaders for proactive guidance. They want to know whether the business can adopt AI at scale without creating risk that undermines long-term value. 

“Tell us, in real time, which initiatives are safe to accelerate, where we’re exposed, what could slow down our transformation, and what we need to act on right now.”

The CISO mandate has evolved from risk reporting to innovation enablement. 

When Everything is a Risk, Nothing is a Priority

In many organizations, risk context is spread across multiple teams. Security, procurement, privacy, IT, and third-party risk each have their own view.   

That fragmentation creates blind spots. 

Consider an AI agent that can retrieve customer records, access internal knowledge bases, and trigger downstream workflows. Security may know the agent exists, IT may know where it’s deployed, and procurement may know who purchased it. 

Without a holistic view, however, it becomes difficult to determine whether the agent has the right permissions, if it is operating within policy, or how it could expose the business.

But visibility is only half the battle. As AI systems, identities, vendors, and data change at a dizzying scale, organizations need to understand whether policy is actually being followed in real time.

A control that was effective six months ago may no longer suffice after a new AI integration, a vendor update, or a change in permissions. 

Today’s systems are too dynamic to be governed by the same operating model that worked for yesterday’s tech stack. 

From Risk Review to Risk Decisioning

CISOs are now being asked to help the business decide—quickly and defensibly—what can move forward, what needs guardrails, and what should stop. Meeting that mandate requires a different approach: 

• Treat AI risk as part of enterprise risk, not a separate discipline. AI is embedded in the same decisions organizations already make about data, vendors, identities, controls, and business processes.
• Start with the business process and context, not the model. Understand what processes depend on this system, the data it touches, and what happens if it fails. 
• Move from one-time approval to continuous assurance. What matters isn’t whether an AI project passed review six months ago, but whether it is operating within the organizations policies and risk appetite today.
• Measure decision velocity. Demonstrate how quickly the organization is able to determine what moves forward, what needs guardrails, and what must stop.

When risk is connected across the business, priorities become clear. Security leaders can understand not just what needs to be addressed, but what matters most, who owns it, and what the business impact could be. 

When there is a shared understanding of approved use, teams can move faster without relying on ad hoc reviews, static questionnaires, or blanket restrictions. The goal is to make technology and third-party risk visible, prioritized, and actionable at the speed the business now operates.

That shift helps security leaders say “yes” with confidence.

Safeguard Transformation and Scale Innovation

I know the pressure many CISOs are carrying right now. Your scope is getting larger while resources continue to shrink. 

Your leadership is asking you to protect every facet of the organization, support growing risk and compliance requirements, and now, to be a key voice in guiding business strategy.  

When you have clarity on what risks truly matter and have the tools to take action, your risk program can become a driver of responsible and scalable innovation. 

OneTrust helps build risk and compliance programs aligned with the complexity and the speed of your business. Learn more about our integrated risk solutions.

When a goal goes in during a tournament quarter-final and a hundred million people watch it at the same time, what they feel is the goal. The roar, the replay, the disbelief.

They do not feel the contribution feeds traversing private media networks across continents, or the edge nodes absorbing a traffic spike that appeared without warning.

They just feel the moment.

And that’s exactly how it’s supposed to work.

And as live sports viewership pushes into territory that makes previous records look modest (driven by a generation that expects to watch anything, on any device, anywhere, without waiting), the gap between getting that delivery right and getting it wrong has never been more consequential, or more public.

As audiences moved to digital platforms, the margin for error disappeared.

There is a version of this conversation that is easy to have: audiences expect more, technology has to keep up. True, but incomplete.

Audiences have always expected live sport to work. What changed is what “working” means, and how quickly they find out when it doesn’t.

Viewers no longer sit in front of a single screen. During a FIFA World Cup match, a household might have the main feed on the living room television, while someone else streams the highlights on a second TV in the bedroom, all while phones flash with live stats and tablets run separate commentary. From the infrastructure’s perspective, that isn’t just one household watching a game; it’s a chaotic web of concurrent demands triggered by the exact same split-second on the pitch.

Multiply that across tens of millions of viewers, and the scale of the challenge becomes clear. Social media raises the stakes further. When a platform fails during a World Cup knockout match, audiences report it in real-time on the same platforms they use to discuss the game. The complaint travels faster than the fix.

Broadcasters no longer have the luxury of resolving an incident before people notice. The incident becomes the story, and in many cases, travels further than the match itself.

What these viewership numbers actually mean for infrastructure

The shift in how people watch live sport has moved well beyond trend territory.

EMARKETER forecasts that digital live sports audiences in the US will grow to 114.1 million viewers, while traditional pay TV audiences decline to 82.0 million, highlighting the continued shift toward streaming.

The concurrency numbers generated by major sporting events now sit in a territory that would have seemed implausible a decade ago.

During the 2026 FIFA World Cup, for instance, streaming platforms shattered every historical ceiling, highlighted by Brazil’s CazéTV repeatedly breaking global YouTube records for concurrent viewership during the group stage. Meanwhile, in the United States, Peacock and Telemundo’s digital platforms logged an unprecedented 13 million concurrent viewers for a single knockout window. 

When tens of millions of people tune into the same live stream at the same moment, it’s a challenge unlike regular web traffic.

Historically, massive global audiences were insulated by geography. The load was spread across distinct regional networks: antenna signals, satellite downlinks, and physical cable architectures. The physical infrastructure of traditional television inherently absorbed the impact. 

Digital streaming removes that buffer. Traffic spikes all at once, often at the most critical moment. The tighter the match, the deeper the stoppage time, the sharper the spike. Network infrastructure is forced to handle its heaviest, most volatile traffic exactly when it has zero margin for error.

Social media compounds the pressure operationally. The second a crucial goal is scored, a wave of real-time reactions floods the internet, instantly dragging a secondary “curiosity audience” into the app. These are people who weren’t even watching the match, but saw the hype and decided to tune in, meaning the network has to absorb a massive new rush of users precisely while the primary stream is already maxing out its capacity.

To survive these surges while satisfying a modern audience, the underlying broadcast playbook has undergone a massive structural shift. It’s no longer just about handling traffic; it’s also about using modern technology like AI to manage it intelligently.

According to an industry survey, 25% of broadcasters integrated AI into live production workflows in 2025, a massive leap from just 9% the previous year, with 64% identifying AI as the single largest impact driver over the next five years. 

The network is no longer just delivering content. AI is now generating highlights and short clips in real time, producing millions of videos that keep fans engaged long after the live moment has passed.

Ultimately, the technical demand is driven by a shift in what viewers expect. An IBM sports study revealed that 56% of fans now want AI-driven insights layered directly onto their content, while 33% point to real-time, automated translation as the feature that most impacts their experience.

Whether it’s one screen or several, viewers don’t notice the edge infrastructure or AI powering the experience. They just expect the game to play without interruption.

The planning mistake most organisations make

Capacity planning is where most organisations spend their time when preparing to stream a major event. Can the system handle a million concurrent streams? Can it scale on demand if the numbers exceed projections? These are real questions. 

The lesson is not unique to sports streaming. Every digital business now experiences moments where demand, visibility, and customer expectations collide. Peak traffic events such as flash sales, ticket releases, and viral campaigns can drive website traffic 2 to 25 times above normal levels within seconds. The infrastructure may be different, but the pressure is remarkably similar.

Large-scale system failures occur when multiple components, each functioning as expected on its own, are overwhelmed by a surge in demand, rising latency, or regional blind spots at the same time.

The problem isn’t the individual systems. It’s how they work together.

Latency is the factor most consistently underestimated. A few seconds of delay is not a minor inconvenience in live sport. It is a fundamentally broken experience. 

A viewer whose stream is running four seconds behind will see a notification before the decisive moment appears on screen. Someone watching a service from the privacy of their room may hear a celebration from another room before seeing it on their screen.

Geography is another planning gap. Streaming growth is increasingly being driven by emerging markets. In Southeast Asia alone, premium video streaming subscriptions grew 19% in 2025, led by Indonesia, while viewing hours continued to climb across the region. Yet much of the world’s media infrastructure was originally designed around North American and Western European demand. An architecture that looks robust on paper can deliver very different experiences depending on where the viewer is.

The reason is simple: physical distance still matters. Every extra hop between the viewer and the content adds latency, making it harder to deliver a consistent experience at global scale.

Then there is the timing question. The decisions that determine whether a platform holds during the most-watched minutes of the year are not made on event day. They are made months earlier through choices around architecture, redundancy, testing, and operational readiness.

Once an event is underway, it’s too late to redesign the architecture behind it. If your system isn’t designed to handle the pressure before the crowd arrives, it’s already too late.

The hidden chain behind every live event

When a streaming disruption becomes public, people naturally look for a single point of failure: the app, the platform, or the provider.

A live event depends on dozens of systems working together, and any one of them can become a problem.

And the experience is only as good as the weakest handoff between them.

It all starts with the live camera feed moving from the venue to the production studio. This is a real-time stream, not a file download. If you drop even a single packet at the wrong moment, everything down the line breaks, no matter how perfect the rest of your setup is.

Remote and cloud-based production workflows have redefined how live sports are produced, enabling broadcasters to operate with greater agility and scale. As production becomes more distributed, success increasingly depends on ensuring every stage of the delivery chain works together seamlessly.

Each transition is a potential failure point. Managing them requires visibility that extends across providers, platforms, and networks simultaneously.

Behind every live stream, technologies like encoding, transcoding, packaging, rights management, and ad insertion are constantly at work. If any one of them fails, the stream can go down altogether.

Global distribution introduces another layer of complexity. Viewers in Asia, Africa, and South America may all be watching the same match, but each stream travels across different networks and infrastructure. That means performance can vary by region, and issues may affect one audience without impacting another. 

AI is increasingly helping operators detect anomalies in real time, pinpoint affected regions and trigger corrective actions before disruptions become widespread. Combined with point-to-point monitoring, it provides the visibility needed to keep live events running smoothly at global scale.

Edge delivery is where the difference between preparation and improvisation becomes most apparent. Bringing content closer to users reduces latency, absorbs local traffic surges, and improves performance in markets with variable connectivity. 

The value of technology investments such as AI and Edge becomes clearest during the moments when demand is highest.

Monitoring is what turns visibility into action. With AI helping analyze telemetry and detect anomalies in real time, operations teams can identify issues sooner and respond before they affect viewers. By the time customers start reporting a problem, the opportunity to prevent it has already passed.

What reliability is actually worth

For most of early broadcast history, audience tolerance provided some buffer. Disruptions happened. People accepted them. There was nowhere else to go, and the story rarely escaped the room.

Neither of those things is true now.

A streaming failure during a major match becomes public within seconds. Viewers don’t distinguish between a network issue, a processing failure, or a distribution problem; they simply see a service that failed. That single experience can shape the broadcaster’s reputation, credibility and customer loyalty, influencing whether viewers come back for the next event or recommend the service to others.

The commercial implications are significant. Global tournaments such as the FIFA World Cup illustrate just how valuable live sports rights have become. Their return depends on reliably reaching the audience that was promised.

Advertisers invest in live sport for one reason: to reach a large, engaged audience at the exact moment it matters most. If the stream fails during that window, the opportunity is lost. Those viewers, impressions, and advertising value cannot be recovered once the moment has passed.

The same principle increasingly applies outside media. Customers rarely know nor care whether an outage originated in the application, the cloud environment, the network or a third-party dependency. They experience a failure of the brand. In a digital-first economy, reliability has become part of the customer experience itself.

For broadcasters and streamers, reliability is no longer just an operational KPI. It directly influences audience trust, advertising revenue, and the long-term value of premium sports rights.

The demands ahead are bigger

AI-assisted production is already changing how live events are created. Broadcasters are using AI to automate highlight generation, camera selection and real-time clip packaging for social media, with new AI-assisted workflows producing sports highlights up to 80% faster than traditional methods. 

All of this processing happens within the live delivery chain, where every additional task must be completed without adding latency or compromising the viewing experience.

Personalisation at scale is the next significant challenge. Not personalisation in a vague sense, but the specific technical reality of delivering multi-language commentary tracks, different languages, different statistical overlays, and different camera angles to different viewers watching the same event simultaneously. 

Instead of one stream per event, the infrastructure has to manage a matrix of concurrent variants, each with its own encoding, storage, and delivery requirements. 

Interactive experiences add bidirectional data flows: real-time polls, integrated second-screen data, live wagering. These move data from the viewer back through infrastructure that was primarily built to push content outward. Managing that at scale is a different engineering problem from managing delivery.

Higher-resolution formats (4K now becoming a standard expectation in premium markets, 8K moving into early deployment) are bandwidth-intensive at exactly the scale where bandwidth is already under pressure. Consumer devices are ready. Infrastructure in many high-growth markets is not uniformly there yet.

Many of these capabilities are already being deployed for major global sporting events. The organisations investing seriously in technology, innovation, and infrastructure now are building toward a standard that will be the baseline requirement within a few years. Those that are not will be closing the gap under the worst possible conditions.

The technology you never think about

The broadcasters that succeed don’t leave reliability to chance. They plan for it from the outset, designing their infrastructure to handle peak demand long before the audience arrives.

This reality hits hardest during massive global events. When a stream glitches, millions of people feel it simultaneously in a matter of seconds. Keeping those streams alive doesn’t happen by accident; it takes massive scale, intense discipline, and deep experience controlling everything from the stadium camera to the viewer’s screen.

The lesson extends well beyond live sports. Every enterprise is becoming a real-time digital business, whether it’s delivering AI-powered applications, launching digital products, processing financial transactions, or handling a sudden surge in customer demand. Different industries may face different triggers, but the expectation is the same: the experience has to work, even when demand is at its highest.

Delivering that level of reliability is why many of the world’s largest sports brands rely on Tata Communications. Supporting the broadcast, production, and management of 80% of the world’s sporting events, and reaching more than two billion viewers across 190+ countries, Tata Communications operates in the invisible layers that make every live moment possible. We call this the “Virtual Stadium of the World”, the technology and infrastructure that connects fans, broadcasters, rights-holders, and sporting moments at a truly global scale.

By managing the critical handoffs across contribution networks, edge processing, and global media infrastructure, we engineer the resilience required to keep 120,000 live events running flawlessly every year.

Live sport may be the most visible test of digital infrastructure, but it won’t be the last. As AI, personalisation and real-time experiences become the norm across industries, the ability to deliver reliably at scale will define far more than match day.

To learn more, visit us here.

The biggest and loudest prediction about AI is that it will eliminate millions of jobs. It is dramatic and easy to repeat. But from what I’ve seen, inside most enterprises the more immediate problem has turned out to be something else entirely: a growing mass of tools, agents, models and usage costs spreading faster than most organizations can govern or connect to real business value, also known as AI sprawl.

None of that invalidates the initial fear. Indeed, AI can clear backlogs, speed up analysis, draft usable content and reduce time spent on repetitive work. In my opinion, what goes wrong is the assumption that those gains will scale seamlessly, and that more AI will automatically produce more value.

What really matters is not only how much AI a company can deploy, but whether its use fits inside a growth strategy, an operating model and an organization that can use it well.

The early results of AI use made the logical progression feel obvious, even a foregone conclusion. If it could already improve output in narrow use cases, then broader deployment should produce broader gains. Simple! Better models were expected to deliver better results. More agents were expected to drive more automation. For many companies, this logic held for long enough to encourage overexpansion.

But this logic has started to break down as usage continues to scale. I’ve seen returns diminish much quicker than expected. To illustrate, one industry analysis found that developers who used AI most heavily produced about twice the output of moderate users, but consumed roughly ten times the compute.  

At a certain point, more AI does not create proportionally more value – it simply becomes more expensive. But where, exactly?

From experimentation to sprawl

Experimentation played a key role in this downturn, but it’s not the culprit. As AI continues to sprawl, the problem continues that AI is spreading faster than most companies can coordinate. Teams often solve the same problem in parallel, paying for overlapping capabilities and layering new tools atop existing ones without any clear inventory of what ‘s already in place. What can appear as momentum is really turning into redundancy.

I’ve seen versions of this play out repeatedly. At one financial firm, several business units were pursuing AI projects aimed at automating research and reporting. Each team moved independently; selecting their own tools, building their own workflows and creating separate data pipelines, with little to no coordination between teams. In some cases, different groups were developing nearly identical capabilities without realizing it, solving the same problems twice without any shared visibility into each other’s work.

Individually, the projects showed real promise. Collectively, the projects created duplication, fragmented data and inconsistent standards business and enterprise wide.

By the time leadership stepped back to assess, the company found itself paying for overlapping capabilities, maintaining multiple versions of the same underlying data, and struggling to determine which solutions were actually delivering value versus which were simply consuming budget and eating at engineering time.

Perhaps most troubling: nobody at the enterprise level had a complete view of what was being built, by whom or why. What began as healthy, well-intentioned experimentation had, without anyone deciding it should, evolved into full-blown AI sprawl, creating a patchwork of disconnected initiatives that was difficult to govern, harder to secure and far more expensive than a coordinated approach could and should be.

Early wins encourage a still wider rollout, but many organizations expand usage before they put real controls in place. Experimentation becomes sprawl. Budgets grow quickly, and few leaders have a reliable view of who is using what or why.

AI strategy cannot sit beside growth strategy

This is where I see many companies still get the issue wrong. They treat AI and growth strategy as two separate efforts, then wonder how adoption gets so messy. A business cannot drop AI into its operations and expect momentum to take over. The technology has to support a clear path to growth, whether that means improving margin, speed, service, capacity or decision-making. At the same time, growth plans cannot assume AI changes nothing about delivery, design or operating leverage. The real challenge is in ensuring the two work together.

Personally, I’ve seen better results when AI initiatives are tied to a specific business objective from the beginning, rather than launched as broad, abstract or transformative effort. One mattress retailer I’ve worked with took this approach, starting with a single, focused and well-defined use case rather than trying to transform or overhaul the entire organization at once. The company introduced an AI-powered training platform for store associates, giving employees a low-pressure way to practice sales conversations and product recommendations before applying them to external situations with customers on the floor.

Because employees experienced immediate and tangible value from the tool, adoption spread quickly across locations, with minimal need for top-down mandates. Early, visible success helped to build internal credibility and generate momentum, which leadership then leveraged to expand into more complex AI initiatives across areas such as inventory management, demand forecasting and replenishment planning.

Ultimately, the technology succeeded not because it was innovative for its own sake, but because it was connected to a larger growth strategy: improving sales effectiveness on the floor, driving operational efficiency behind the scenes and strengthening workforce capability at entry level. A major lesson we walked away with here was that starting small and specific, with a clear throughline to business value creates a strong foundation for sustainable and scalable AI use.

What implementation actually takes

All this takes more than a few easy guardrails. It takes strategy. Leaders need a real inventory of the tools, agents and assistants already in use across the business, who owns them, what data they can access and everything that they support.

They also need financial controls that match the economics of token-based usage, including role-based access, thresholds and review processes that make spend visible before it becomes a surprise. Similarly, they need metrics that go beyond mere activity. More prompts do not mean more value. If a deployment cannot be tied to throughput, margin, quality, cycle time or another tangible result, it is still unfinished.

This is also why blunt shutdowns rarely work. If leaders clamp down too hard, employees often move to unsanctioned tools and create a larger shadow AI problem, or the unauthorized use of artificial intelligence tools, models or chatbots by employees, without the knowledge or approval of IT and security teams, with even less visibility and more risk. The better answer is disciplined adoption: clear ownership, rules, metrics and enough flexibility for teams to use AI where it works.

That matters for the people as much as it does for the budget. Those that modernize well end up with better work – not just less of it.

The story of the moment isn’t about AI replacing people – or even AI in general. It’s about whether companies know their own businesses well enough to keep incorporating powerful new tools without mistaking activity for progress. As technological capabilities continue to appear, the winners will be the organizations that understand where it belongs, what it can improve and how to turn each new wave into something permanent.

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

Major AI labs are unleashing forward-deployed engineers (FDEs) to try and grab enterprise customers. Large consultancies are dishing out tokens and assembling armies of consultants — both human and agent — to do the same.

But smaller firms are in the mix now, as well. AI is helping 28Stone Consulting, a New York-based, 230-person technology consultancy for capital markets, punch above its weight against larger rivals in the rush to deliver FDEs.

In this Q&A, Thomas Dolan and Frank Erickson, founders of 28Stone, argue that agentic AI isn’t a one-size-fits-all solution in vertical markets; success takes discipline, deep domain expertise, and human involvement to mitigate risk.

Many enterprises continue to struggle with the use of AI agents, which is consultancies are stepping in to get projects off the ground. 28Stone is among those that have published blueprints and methodologies on the development and delivery of agentic AI workflows with humans in the loop.

Computerworld spoke with both founding partners about why companies are still stumbling with agentic AI rollouts, and what a disciplined delivery process actually looks like.

After 15 years of delivering software for capital markets firms, is ‘AI-first’ a real distinction or just positioning?

Dolan: “We’re not shying away from being AI-forward. What needs to shine through is AI done intelligently — not stuff you get by buying some tokens for somebody on the trading desk. We’re an AI-first firm.”

Erickson: “And it’s temporary. At some point, AI is going to be synonymous with software development.

“The whole idea of an AI SDLC (software development lifecycle) versus an SDLC is going to be one and the same, a lot like cloud computing today. To not include AI in your strategy, you’d look like a COBOL vendor.”

What does agentic AI delivery look like?

Dolan: “We’ve got several AI initiatives delivering a pure agentic approach. We’ve doubled down on the human expertise wrapper in the SDLC. That doesn’t mean sacrificing any of the benefits of the AI models — quite the opposite.

“You don’t achieve anywhere near the same level of value from applying AI without keeping that expertise — industry, functional and technical — throughout the process.”

Where do humans stay in the loop once agents are doing the work?

Dolan: “We’re believers in starting with requirements discovery. Someone who knows the analytical nuances of a good business analyst is critically important; shaping a product owner’s business information through a markup file that can be fed into a BA agent, then treating the output as if it came from a very fast junior BA. Only then is the story complete.

“The developer takes that story, transforms it into the most efficient input, then owns the output, because they’re accountable for that code. A developer should own the code on both the input and output side.

“Your product owner, who knows the business, that’s great. But expecting them to interact with an agent and output enterprise code is ridiculous. It’s not a great plan.“

Why not just put one do-everything person in charge of AI and agents?

Erickson: “Every analyst, programmer or software engineer isn’t a great requirements analyst. And a great domain analyst with some technical background won’t know if the agent’s code is garbage, maintainable, performant.

“It’s unrealistic to expect one individual to have that breadth across domain, software engineering, testing, deployment. Clients ask all the time, and we push back: ‘Great, if you can find that guy, they’re few and far between.’ To deliver at the enterprise level, you need the human expertise, at depth.“

Dolan: “There’s system speed and latency, important in parts of finance. Then there’s speed of delivery, because other areas evolve quickly and time-to-market is critical.

“Our human wrapper may at first pass come across as a little slowed down. Maybe it is. But [Erickson] has a good analogy about one of the dangers of AI: you can end up going really fast in the wrong direction. By the time you look up, you’re way off base and have to backtrack.“

What about AI in your sector do you think is overhyped?

Dolan: “The hype around the ease of use of AI and the democratization of enterprise software delivery — that ‘anybody could do it now, it’s all being done by machines’ — is another idea that could prove costly in the long run.

“This do-it-yourself reaction is dangerous for clients, and for trust in the overall AI benefit, which is real. We compare it to the beginning of offshoring 20, 30 years ago: a golden idea that was going to cure everything. A lot of firms did it thoughtlessly, thinking it’s just labor arbitrage, and it almost inevitably failed. That all-or-nothing mentality missed that offshoring is an amazing way of getting better value for your dollar, but it has to be done thoughtfully, so the delivery process — the thing that ties it all together — stays unsevered.

“We’re seeing that now. I’ve heard, ‘We’ll just push a button, the machine’s building the system.’ The machine is not building the system. It might be writing the code, the story, running the tests.

The system is built by a team of engineers you bring in and trust. My fear is that people will say, ‘We don’t need this vendor or this technology team. I’ve got a product team. They might not be able to code at all, but they know the business,’ and it fails dramatically. 

“Then people say, ‘We played with AI, it’s not ready yet,’ and throw it all away. One of the best things we can do is ensure clients know the benefit is real.“

Erickson: “The hype can be summed up in a single phrase: vibe coding. That has done AI a massive disservice, because there’s a huge difference between vibe coding and enterprise software development, and some of the loudest proponents of AI are too latched on to it. In our industry, the only way to succeed would be a stable of unicorns. It just doesn’t scale. I get perturbed when our people internally refer to AI tooling as vibe coding; if they think that’s what they’re doing, they’re misunderstood.“

When you engage clients at different levels of AI maturity, how do you get them to a understand what works?

Dolan: “95% of our take on an agentic approach is in line with everyone else’s, but that 5% matters, especially in requirements discovery, in who’s giving the requirements and how they’re thought of. It can set you up for dramatic errors, given the speed at which you’re moving.

“There’s a dangerous human tendency we’re seeing among clients to try and cut corners at the start of a project and — in lieu of having deep, expert driven discovery sessions — just summarize what they may want using AI.

“We would hope our clients are collaborative, everyone understanding it’s early days. If a client insists on doing something we feel strongly against, like a product owner completely owning everything right up to code generation, that’s an issue we have to either push back strongly on or step out of the accountability for.“

AI body shops — LLM providers and giant consultancies — are emerging to help enterprises deploy AI. Does that model work?

Dolan: “Whether you’re partnering with an LLM or with an AI-first, generic software provider — ‘Hey, we’re not industry guys, but we know AI delivery’ — you end up, if you’re a bank or a broker-dealer, saying: ‘All right, we know our business, these guys know the AI side of it. What could go wrong? Put us together and we’ll have quality engineering.’

“The problem is what you miss: the know-how of putting industry and technical expertise together and actually delivering financial services systems. The people working at the generic delivery firms, whether an AI-only firm or a body shop somewhere, don’t have that capability.“

Does AI change the economics for smaller consultancies like yours competing against the big firms, and does it cut both ways?

Dolan: “Over our 15 years pre-AI, there were two recurring reasons we’d lose a project. One: ‘We’d love to work with you guys, given your subject matter expertise, but the costs just aren’t there compared to my budgets. I’m being forced to go to a body shop or an [offshore] delivery center.’ The other side of that coin: ‘We love your capabilities, but you’re a firm of 230 people and I need 300, 400 people.’

“AI changes the options for clients. You don’t have to sacrifice the niche vendor who knows your space just because you need a larger team or a cost target. AI levels the playing field and should allow smaller firms to compete with the larger, big-box generic firms, the Accentures of the world.“

Erickson: “It redefines what scale means. You can look at velocity as a measure of your cost to deliver, not a rate card. Scale can’t be defined in terms of headcount anymore. It’s got to be defined in terms of output.

“There’s a threat in it, too. If you’re an Accenture with hundreds of thousands of low-cost software engineers, how do you train all those people? I feel for them. But for us, a couple hundred people with a specific domain focus, it’s a huge opportunity.“

How has the profile of the people you and others hire changed with this agentic process?

Erickson: “You’re still looking for people with strong engineering and design backgrounds, and communication skills, because they interact across the software development lifecycle more than in the past.

“Many take too much joy in typing out perfect code. Sorry, I don’t need you writing for-loops and classes anymore. I need you reviewing them, understanding them, operating at a higher level. That’s a different kind of person: an engineer, not a programmer or a coder. On the [business analyst] side it’s similar: people took great pride in detailed user stories covering every path. Now it’s conversations, prompts, reviewing output — less doing, more interacting.

“More than ever, they have to be interested in the domain. They can’t just be, ‘I want to learn everything there is to know about Java.’ That’s too narrow. They don’t have to be an expert; they have to be interested. In our case, capital markets is a specific niche. The biggest challenge is getting familiar with the tools — finding time, while delivering for customers, to ramp up and make the mistakes you need to without jeopardizing projects.“

What about governance? Who’s keeping AI delivery and its costs under control?

Erickson: “This is evolving rapidly. People aren’t sure how to put governance around this. The most obvious is financial governance. People are starting to get hefty bills. One of our clients spent a million dollars on tokens over the last eight weeks alone. Sticker shock. The token-maxing policies are starting to show their flaws. It’s wild west still: learn on the fly, then figure out what needs to be governed.“

Are CIOs actually opening their wallets? And when they do, what’s the smarter way to invest?

Erickson: “There’s still a lot of caution. Forecasts keep going down on how long something should take. So: ‘I could wait three months and maybe still get it delivered by the same date someone’s promising me now, but for half the price. I’m going to wait and see when equilibrium is met.’ We haven’t seen the wallets open up like crazy — it’s slow adoption.“

Dolan: “One of our clients is looking at it from a productivity-boost perspective: instead of doing the same for less, I can do much more for the same. AI lets clients pull the trigger on things they wouldn’t have in the past — projects that might not have been approved pre-AI, where the costs have come down to a point that’s palatable with the business.“

Erickson: “And that’s the story we’re hoping to hear more of. There isn’t a huge cost anymore to exploring a business opportunity. The time and money that would have gone to a return-on-investment study could be spent on a proof-of-concept with AI, and the project done a few weeks later. Maybe [there’s] a hint of things to come, where decisions start being made quicker. 

“There’s a little fear on our side, though: a lot of tiny little projects is tough for a consulting business.“

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

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

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

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

Centralization: a design choice, not a doctrine

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

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

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

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

Know what belongs at the center

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

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

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

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

Don’t confuse standardization with centralization

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

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

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

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

Let business architecture lead technology architecture

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

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

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

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

Make the cost of complexity visible

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

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

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

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

Revisit the model as maturity changes

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

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

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

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

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

Somewhere in the last eighteen months, “AI agent” stopped being a useful term. CIOs may even be afraid to ask what “agent” truly means, as it now seems to describe everything from a chatbot that answers HR questions to an autonomous research system that plans its own week of work. When a single phrase carries that much weight, well, it stops carrying any.

I’ve spent the last three years inside hundreds of enterprise AI deployments, and the factor that separates the programs scaling elegantly from the ones still shuffling is often the CIO’s architectural fluency: The ability to look at business problems across the organization and recognize, on sight, what kind of AI architecture is the right fit. In my experience there are six archetypes, each with their own nuances, that CIOs should internalize to make well-informed decisions going forward.

1. The conversational assistant

The first, and the one most enterprises meet first, is the conversational assistant: The chat-based partner that an employee or customer opens when they want to think out loud. Deloitte found that 38% of organizations report AI is already strengthening their client or customer relationships. This is the architecture people fall in love with: A well-designed assistant with constantly updated information, persistent user-level memory, tools that can act on behalf of users, and citations on every factual claim becomes a useful problem-solver that’s available at any hour of the day.

A global law firm I work with deployed an internal assistant that gives every attorney instant access to the firm’s accumulated precedent, memos and prior matter work. Associates who used to spend the first hour of a research task hunting through document management systems now start with a grounded, citation-backed answer and refine from there. This helped the firm’s institutional knowledge, previously locked in the heads of senior partners, become queryable by anyone with a deadline at 11 p.m., or later.

A second example: A mid-market wealth management firm built a client-facing assistant that handles portfolio questions, statement explanations and routine servicing requests. The assistant draws from each client’s actual holdings, recent activity and the firm’s published market commentary, with citations linking back to source documents. Advisors stopped being interrupted for the questions that didn’t require an advisor, and clients got answers on a Sunday.

2. The triggered workflow

Another pattern producing the value across the enterprises I work with is something that runs silently: An email arrives, a ticket is created, a file lands in a folder and the agent executes a process utilizing both reasoning and determinism. These agents don’t even require user adoption, because they’re invisible to the end user. They produce measurable outcomes, but fit cleanly into the audit and change-control processes IT teams have run for decades.

A commercial insurer I advise built a triggered workflow for inbound submissions. Every broker email that arrives at the underwriting inbox is classified by line of business, the attachments are parsed, key risk fields are extracted into the policy administration system, and a draft acknowledgment is queued for the underwriter’s review. Seemingly overnight, the inbox began arriving pre-sorted, and submission throughput rose meaningfully without any change to headcount.

Another example, this time from a private equity firm: Every inbound confidential information memorandum (CIM) that hits the deal team’s shared inbox triggers a workflow that extracts the financial summary, screens it against the firm’s investment criteria, drafts a preliminary memo and posts the result into the deal-tracking system. Associates still make the call on what to pursue, but the first three hours of manual work on each opportunity now happen before anyone even opens the file.

3. The autonomous agent — with sub-agents

Here we have the architecture that gets the most conference attention: The autonomous agent, given a task and left to plan its own steps by utilizing its own sub-agents. Autonomous agents are not one-size-fits-all, but they do meet a specific need: Multi-source research, complex cross-system lookups, deep-dive investigations. All of these are processes where the path isn’t usually specified in advance, but the tools are. With the right design discipline, an autonomous agent feels like having a self-sufficient teammate who can call in the right resources and specialists if needed.

A global consulting firm I work with uses an autonomous research agent for early-stage engagement scoping. Given a target company and a strategic question, the agent decides for itself which sub-agents to consult (choosing from internal proprietary databases, prior engagement archives, licensed market data, public filings) and produces a structured briefing with its reasoning chain attached.

Another large technology company I know of deployed an autonomous agent for cross-system incident investigation. When a production alert fires, the agent forms a hypothesis, queries the necessary sub-agents with relevant monitoring tools, log stores and deployment systems, and follows the trail until it reaches a defensible root-cause summary to surface to an engineer.

4. The multi-agent team

The fourth pattern is where the next wave of enterprise quality gains is going to come from. According to Databricks, usage of multi-agent systems grew 327% in just four months as enterprises moved beyond single chatbots. Several specialized agents, each with its own role and toolset, coordinate through a shared protocol: A researcher and a writer, a planner and a set of executors, a proposer and a critic. The proposer-critic feedback loop is one of the smartest techniques in agent design today. One model produces an answer; a second, with a different prompt and often a different provider, evaluates it against explicit criteria. For compliance review, contract analysis, high-stakes classification and any output that will be audited, this second pass is extremely helpful and mirrors how human teams work.

A global bank I work with uses a multi-agent system for marketing and communications review. One agent drafts client-facing copy, a second checks it against the firm’s regulatory and brand guidelines and a third checks it against jurisdiction-specific disclosure rules. Disagreements among the agents are surfaced to a human reviewer with the specific clauses flagged. The compliance team stopped being the bottleneck on every routine piece of copy and started focusing on the high-judgment cases instead.

The next example: A pharmaceutical company built a multi-agent workflow for medical literature summarization. A retriever agent gathers candidate studies, a reader agent extracts study design and findings, a critic agent challenges the reader’s claims against the source text, and a synthesizer agent composes the final brief. The proposer-critic loop in the middle is the reason the medical affairs team trusts the output enough to act on it.

5. The human-in-the-loop (HITL) agent

The fifth pattern is the one I think we’ll see increasingly more of in the future. While many see “full automation” as the goal, the right target is actually to let the agent handle the 80% of a task that is mechanical, while preserving human judgment at the most critical moments. This is achievable via human-in-the-loop (HITL) agents. According to Moody’s, 42% of compliance professionals believe that human oversight is mandatory, and I agree: AI should run right, by getting approval and review before any sensitive business action is taken. HITL is the architecture that can help turn a skeptical team into an enthusiastic one.

A regional health system I worked with uses a HITL agent for prior-authorization letters. The agent assembles the clinical evidence, drafts the letter against the relevant payer’s criteria, and routes it to a nurse case manager for review inside the existing workflow tool. The nurse approves, edits or rejects in seconds rather than minutes, and every edit helps make the next draft better.

A property management company uses a HITL agent to run its maintenance work orders. When a tenant emails about a problem (an HVAC unit that died overnight, say), the agent pulls the structured details (tenant, unit, issue type, urgency), matches the job to the right vendor from the directory, and drafts the work order. A team member approves it in Slack before anything goes out. From there the agent emails the vendor with the full order, confirms with the tenant that someone is on the way and updates Airtable, closing the loop completely.

6. The scheduled agent

On a set schedule or against a batch of inputs, this agent runs the same defined task: Produce a report, refresh a dataset, monitor a set of sources or summarize a period of activity. Under this archetype, unsexy work gets done consistently, integrated into existing operational rhythms like the Monday morning meeting, the daily standup and the monthly board deck, without asking anyone to change their behavior. This is the architecture that shifts AI from feeling like even more work, to a seamless teammate that just works.

A private equity firm I work with runs a scheduled agent every Monday at 6 a.m. that monitors news, filings and earnings activity across every portfolio company and produces a single PDF that lands in the deal partners’ inboxes before the weekly investment meeting. No one logs into a dashboard. The agent shows up, on time, with the same format every week, and the meeting now starts from a shared baseline rather than from whatever each partner happened to read over the weekend.

A second example: A global manufacturer runs a nightly batch agent that ingests the day’s quality-control reports across plants, summarizes anomalies against a rolling baseline, and produces an end-of-shift handoff document for each site lead’s morning. The agent doesn’t flag emergencies, but it ensures that the slow-moving patterns no human would catch reading one shift’s data in isolation get surfaced.

Bringing it together

None of these six archetypes is more advanced than the others or inherently better. But CIOs can have an edge by choosing the one that the operational problem actually calls for.

Before you scope a single deployment, you should be able to look at a business problem and name its shape: Is this a question someone needs answered in the moment, or a process that should run the instant a trigger fires? Does the path need to be discovered, or is it known in advance and just waiting to be executed? Where, exactly, does human judgment have to stay in the loop, and where is it just friction?

Going forward, CIOs should start treating the architecture decision as the first design choice. Everything downstream — adoption, governance, trust — only gets easier if the architecture is the right fit.

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

Last year Anthropic gave away one of the most successful things it has ever built. And, no, I’m not talking about Claude. I’m referring to MCP, the now ubiquitous Model Context Protocol, which Anthropic donated to the Linux Foundation’s new Agentic AI Foundation⁠. At the time, MCP was pulling nearly 100 million monthly SDK downloads across more than 10,000 active servers⁠, prompting the question as to why any company would give up such a popular piece of technology.

Google did much the same months earlier, handing its Agent2Agent (A2A) protocol to the Linux Foundation⁠ with AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow signing on as founding members. OpenAI, not to be outdone, supports remote MCP servers in its Responses API⁠, sits on the MCP steering committee, and contributed AGENTS.md to that same foundation alongside its fiercest rival’s protocol.

It’s like Game of Thrones, except the principal AI powers seek regime change through seeming acts of beneficence rather than violence. For those who have been around for a while, it’s also entirely predictable, following a similar script we’ve seen in the cloud, on-premises servers, and more. Platform companies don’t give away technologies they’ve stopped caring about. They give away technologies they no longer need to own because competitive advantage has shifted to new ground.

What does this mean for AI?

Gravity has shifted before

Google has long been an exceptionally active contributor to open source. As I wrote in 2017, Google wasn’t open sourcing TensorFlow and Kubernetes out of generosity but rather turning these open source assets into on-ramps for Google Cloud. Google was playing catch-up to AWS and Microsoft. As then Google product manager Martin Buhr said, the company hoped to “create a gravity well in the market for container-based apps [so] that a significant percentage of them will end up with us.”

In other words, platform companies routinely commoditize one layer of the stack so they can compete somewhere they hold a stronger hand.

GitHub may be an even better example. Git is open. Anyone can host a Git repository and, once upon a time, different companies did just that. Yet GitHub became the default place software development happens for millions of developers. Nobody pays for Git, but lots of people pay for GitHub. We’re seeing this same phenomenon play out in AI.

Trading contributions for control

Anthrophic and OpenAI have both pretended at being all for humanity’s good, but that’s not a good explanation for why they’re racing to give away things like MCP. The deeper reason is that the model itself has turned out to be a poor place to build a lasting moat, and they’re trying to figure out what’s next. As I pointed out recently, the frontier model leaderboards change almost weekly. As such, enterprises shouldn’t build their AI strategy around the assumption that any one vendor will remain permanently ahead on model quality. Instead, as I suggested, AI may be sexy, but the “dull reality” is connecting those models to enterprise data, workflows, etc.

The AI companies understand this better than anyone. Sure, they’ll continue spending billions training ever more capable models because frontier models attract developers, generate headlines, and open enterprise doors. But they’re also quietly acknowledging that benchmark leadership alone doesn’t create a durable platform.

Developers return to the places where their tools, workflows, teammates, and accumulated work already live. Enterprises double down on the systems where their data, permissions, governance, and business processes are already connected. Every new integration makes that destination a little harder to leave, and every new workflow increases its pull. That’s what MCP, A2A, etc., are all about: increasing gravity around the models.

Every major AI company wants to become the place where AI-assisted work naturally happens, and they’re now amassing armies of forward deployed engineers and trying other means to get legacy infrastructure to tie back to their frontier models. The enterprise incumbents want the same thing, but from the opposite direction. They don’t need to own the frontier; instead they need to connect the frontier to the systems that already safely run the business.

That’s why I’m skeptical whenever someone confidently predicts that AI will sweep away enterprise software. I’ve seen this movie before. Developers absolutely live on the frontier, but enterprises don’t. Enterprises create value by connecting new capabilities to decades of accumulated applications, data, policies, and business processes. The newest model matters, and so does the newest agent framework. But neither creates much business value until it’s connected to customer records, financial systems, supply chains, HR data, and everything else enterprises already depend on.

That’s where incumbents still possess enormous gravitational pull. My employer, Oracle, certainly believes so, just as Microsoft, SAP, Salesforce, and ServiceNow do. (Disclosure: I run developer relations at Oracle, which participates in the Agentic AI Foundation.) Ironically, open protocols strengthen that position rather than weaken it. If every model can speak MCP and every agent can interoperate through common standards, enterprises gain the freedom to adopt whichever frontier technology looks best without rebuilding every integration. The protocol becomes interchangeable.

Open standards don’t stop gravity

None of this diminishes the importance of open standards. MCP succeeded because it solves a genuine problem. Developers shouldn’t have to build a custom connector every time an AI application needs access to a database or other business system. Neutral governance also matters because nobody wants foundational infrastructure controlled by a direct competitor. But we shouldn’t confuse open interfaces with open markets.

An enterprise may find it easy to swap one MCP-compatible model for another while still remaining deeply dependent on the place where its prompts, evaluations, security policies, and employee habits have accumulated. Again, we’ve seen this before. Kubernetes made workloads dramatically more portable without making AWS, Azure, and Google Cloud interchangeable. SQL has been standardized for decades, yet databases remain fiercely differentiated businesses. Standards reduce friction, but they rarely eliminate competitive advantage. They simply move it.

In like manner, Anthropic, Google, OpenAI, and others are happily standardizing how models, agents, tools, and enterprise systems communicate because they don’t expect the connection itself to determine the winner. Instead they expect to win by becoming the place where AI-assisted work naturally accumulates. Along the way, we’re going to see copious quantities of code given away, increasing developer productivity for all and outsized financial bonanzas for a few. Game on.

Security operations centers (SOCs) have spent years struggling under the weight of growing alert volumes, expanding attack surfaces, and chronic staffing shortages. Now artificial intelligence is adding a new complication: not just more information, but more machine-generated information that must itself be evaluated.

“There is an asymmetry here because you now have to parse through a lot of AI slop to get to, ‘Okay, is this real or not?’” Fernando Montenegro, vice president and practice lead at The Futurum Group, tells CSO.

His observation captures a growing concern among security leaders. AI is helping attackers and defenders move faster, but it is also creating new forms of cognitive burden for the humans tasked with separating signal from noise.

As AI accelerates vulnerability discovery and enables more automated reconnaissance and exploitation, defenders are increasingly responsible for overseeing systems whose outputs can be difficult to interpret or verify. The challenge is not simply more work. It is that the volume, speed, and complexity of that work are increasing simultaneously.

Yet experts who study and advise SOCs reject the idea that collapse is inevitable. Instead, they describe an industry entering a difficult transition that could reshape how security teams operate and how humans and machines share responsibility for defense.

The vulnerability surge is exposing years of security debt

One of the most immediate concerns is the possibility that AI dramatically increases the number of vulnerabilities organizations must identify and remediate.

Chris Crowley, a longtime cybersecurity instructor and SOC expert, argues that organizations are facing the consequences of years of accumulated technology debt.

“A lot of what we’re going to have to account for in the next couple of years is a technology debt of vulnerable software that has been deployed because it’s good enough to solve the problem, but then there are all these latent cyber issues, flaws, vulnerabilities that weren’t discovered prior to deployment,” he tells CSO.

AI-assisted vulnerability discovery has the potential to expose those weaknesses at a pace defenders have never experienced before.

“The compression of work that is being dropped on us is unprecedented,” Crowley says. “We’ve just been ignoring it for decades.”

He does not believe AI will necessarily create entirely new classes of vulnerabilities. Instead, he expects defenders to confront much larger volumes of familiar problems.

“We’re going to have 100 of these simultaneously,” he says, referring to the kinds of high-priority vulnerabilities security teams traditionally handle one at a time.

The AI challenge for many SOCs may be less a novelty problem than a volume problem. Security teams already know how to patch systems, prioritize remediation, and respond to critical exposures. What changes is the scale and speed at which those demands arrive.

Organizations with mature patching, prioritization, escalation, and response processes may struggle but adapt. Organizations that have treated security operations as a bare-minimum compliance function may find themselves overwhelmed.

For CISOs, Crowley says, that means treating “patch now” less as an occasional emergency state and more as a permanent operating posture. As AI accelerates vulnerability discovery, the distinction between routine maintenance and crisis response may continue to blur.

He compares the situation to disaster recovery planning. Organizations that wait until a crisis arrives to establish staffing plans, escalation paths, and remediation processes may discover there is not enough help available.

Cognitive overload may become the defining challenge

While vulnerability discovery receives much of the attention, Montenegro believes security leaders need a broader framework for understanding AI’s impact.

Organizations should think about AI through three lenses, he says: security for AI, AI for security, and security from AI. The first involves protecting AI systems. The second involves using AI to improve defensive operations. The third asks what happens when adversaries use AI against the organization.

For SOCs, all three categories are beginning to overlap.

As AI makes it easier to create reports, assessments, vulnerability submissions, and other operational artifacts, humans remain responsible for determining whether that information is accurate and useful.

“It becomes much easier to generate content,” Montenegro says, “but if you’re going to review that content as a human, the onus on you now is that much larger.”

The result is a new form of cognitive overload. Security professionals may spend increasing amounts of time evaluating machine-generated information instead of conducting higher-value security work.

Organizations can increasingly use AI to summarize reports, evaluate alerts, and assist with investigations, but humans remain responsible for validating the results.

“We’re not at the stage yet where people are comfortable” handing off critical decisions entirely to AI, he says.

That leaves defenders caught between two competing realities: AI is creating more information to process, but AI is also becoming one of the few viable tools for managing that growing workload.

For Montenegro, the principle should be to automate tasks, not roles. AI can absorb repetitive investigative steps, but organizations should be cautious about removing humans from the process entirely.

The risk, he says, is that if organizations hide too much complexity behind automated outputs, analysts may lose opportunities to develop the domain knowledge needed to advance.

“How is that professional who is reacting to those alerts growing as a professional?” he says.

The gap between mature and struggling SOCs may widen

Not every organization will experience the impact of AI in the same way.

John Hubbard, senior cybersecurity consultant and SANS instructor, believes the industry’s response will largely depend on how well organizations have prepared for operational stress before AI arrives at scale.

“I would roughly break security operations teams into two camps,” Hubbard tells CSO. “There are the ones that are definitely struggling, are already overwhelmed. And then some are doing really well.”

The struggling organizations tend to be understaffed, underfunded, undertrained, or dependent on ad hoc processes. Every incident feels different, forcing teams to improvise under pressure.

“Getting hit with something like this can certainly be an accelerant for burnout if they weren’t already experiencing it,” Hubbard says.

By contrast, mature security teams have already invested in processes, training, exercises, and automation. “The teams that are doing a really solid job now are probably not super overwhelmed because they’ve developed the processes and procedures to be ready for this kind of thing,” Hubbard says.

He compares successful SOCs to fire departments. Firefighters cannot predict exactly where the next emergency will occur, but they know how to respond because they have rehearsed those responses repeatedly.

“The teams that kind of can react like a fire department are the ones that are getting it right,” he says.

Those organizations conduct tabletop exercises, adversary emulation exercises, red-team assessments, and incident response drills. As a result, they can absorb additional workload without descending into panic.

Burnout remains the industry’s most difficult problem

Despite widespread concern about AI-enabled attacks, none of the experts view AI solely as a threat. Several argue that AI will become essential for helping defenders cope with the challenges it creates.

Jose-Marie Griffiths, president emerita and former CIO of Dakota State University, believes AI can help security teams sift through overwhelming volumes of information and identify the signals that matter most.

“People who work in SOCs are now seeing overwhelming volumes of data, and they’re getting fatigued,” Griffiths tells CSO.

AI can help automate portions of analysis, validate alerts, and improve visibility into complex environments. But Griffiths cautions that some AI-assisted vulnerability discovery tools are also producing large numbers of false positives.

That matters because false positives do not eliminate work. They create it. As organizations confront escalating volumes of findings, distinguishing genuine risk from erroneous results may become as important as discovering vulnerabilities in the first place.

The experts agree that technology alone will not determine outcomes. People will.

Crowley argues that cybersecurity professionals must recognize that uncertainty is intrinsic to the profession. “We are the group that deals with uncertainty,” he says. “That’s really and truly what cybersecurity is.”

That reality places responsibility on both individuals and organizations. Analysts need mechanisms for managing stress. Teams need to recognize when colleagues are approaching their limits. Managers need to establish healthy escalation practices and realistic expectations.

Hubbard rejects the notion that burnout is inevitable.

“It is not a foregone conclusion that security operations jobs have to be a painful grind that everyone hates,” he says.

He has seen organizations where employees remain engaged for years because leaders actively manage workload, create supportive cultures, and encourage open communication.

That includes making it safe for analysts to admit when they have reached their limits. “If people are unwilling to say, ‘I’m maxed out right now, and I’m going crazy,’ that’s going to be the thing that breaks a lot of teams,” Hubbard says.

Pay alone may not solve the problem. Crowley pointed to SANS/SOC survey findings showing that compensation ranked fourth among retention factors, behind meaningful work, training, and professional development.

The future SOC may look very different

Griffiths believes organizations will need to respond not only with better technology but with structural changes. Traditional tiered SOC models may need to evolve into more collaborative teams with diverse expertise working together in real-time.

“I think we’re going to have to eliminate the hierarchies a little bit and have teams of people with different expertise working together,” she says.

She also argues that organizations should invest in human expertise rather than simply increasing AI consumption. “Buy engineers, not tokens,” she says.

Professional networks and peer support will matter as much as any tool, Griffiths says, because defenders need trusted communities where they can compare notes, share practices, and avoid facing sustained pressure in isolation.

If there is a consensus emerging among experts, it is that AI is exposing weaknesses that already existed.

The staffing shortages, alert fatigue, burnout, and process failures affecting SOCs did not begin with generative AI. AI is simply amplifying them.

At the same time, AI is providing new tools that may help organizations manage those very challenges.

The future SOC may spend less time manually triaging alerts and more time validating automated findings, conducting threat hunting, and making strategic decisions. Human expertise may increasingly be paired with AI systems that act as operational partners.

The transition will not be painless. Some teams will struggle. Some practitioners may leave the field. Others will adapt and thrive.

“In a way,” Griffiths says, “we’re turning the whole SOC inside out.”

Montenegro sees the transition as a cybersecurity version of the Red Queen effect: defenders and attackers must keep running simply to stay in place.

Borrowing from science-fiction author William Gibson, Montenegro offered perhaps the simplest description of the industry’s current moment: “The future is already here. It’s just unevenly distributed.”

For security leaders, that future is arriving in the form of AI-generated vulnerabilities, AI-assisted investigations, and AI-enabled adversaries. The question is no longer whether security operations centers will change. It is whether organizations can adapt quickly enough to keep pace.

Microsoft addressed 722 CVEs this month once the 427 Chromium upstream relays are set aside — roughly three times a normal cycle and one of the largest single months in recent memory. Two vulnerabilities arrive under active exploitation: an elevation of privilege in Active Directory Federation Services (CVE-2026-56155), and an elevation of privilege in SharePoint Server (CVE-2026-56164). A third, a BitLocker security feature bypass (CVE-2026-50661) is publicly disclosed but not yet exploited.

The July 2026 Patch Tuesday earns Patch Now recommendations for Windows, Office, Exchange, and SQL Server. SharePoint has two critical RCEs on top of its exploited zero-day, and Exchange Server returns with a critical on-premises spoofing flaw. Adding to our (dear) administrator’s efforts, SharePoint Server 2016/2019 and SQL Server 2016 all reach end of support today. The Readiness team has provided a handy infographic of the expected risk profile of this month’s Patch Tuesday updates.

Known issues

The July release note flags known issues against the following updates:

• BitLocker recovery prompt on first restart – the PCR7 recovery condition tracked since April remains live on the platforms that did not receive the Boot Manager servicing fix (Windows Server 2022 and Windows 10 22H2). Devices with BitLocker on the OS drive, the Group Policy “Configure TPM platform validation profile for native UEFI firmware configurations” set with PCR7 included, and Secure Boot State PCR7 Binding reported as “Not Possible” may be prompted for the recovery key on the first restart after installing this update. This month’s publicly disclosed BitLocker security feature bypass (CVE-2026-50661) keeps the component in focus.

• WSUS synchronization error details suppressed (Windows Server 2025 and 2022) – WSUS no longer displays synchronization error details in its error reporting, a deliberate change made to address the Remote Code Execution Vulnerability CVE-2025-59287. Sync still works, but administrators triaging a failed synchronization lose the detail pane and must fall back to the SoftwareDistribution logs.

Windows Update can still replace manually installed graphics drivers with older OEM versions from the catalogue (the four-part Hardware ID ranking issue acknowledged on the Hardware Dev Center). The two-part HWID pilot runs to September 2026.

Major revisions and mitigations

Between the June and July Patch Tuesdays, MSRC Security Update Guide notices updated 651 reported CVEs across six notification dates (15, 19, 26 June and 3, 8, 11 July), 532 of them routine Chromium upstream re-publications. Of the roughly 30 Microsoft revisions, almost all were cross-platform Office catch-up with no bearing on a Windows enterprise estate. No further action required for IT administrators for this Windows update cycle.

Windows lifecycle and enforcement updates

This is the deadline cycle June pointed at. The July end-of-support wave lands today, and it collides with the month’s heaviest patching. SharePoint and SQL Server take some of their most active security updates ever on platforms receiving their last.

• SharePoint Server 2016 and 2019, Project Server 2016 and 2019, SQL Server 2016 and InfoPath 2013 have all reached end of support. SQL Server 2014 ESU Year 2 reaches end of support today. SharePoint 2016/2019 take an actively exploited zero-day and two RCEs this cycle, and SQL Server 2016 takes a critical RCE, all as their final security update. Now is the time to get moving on updating these platforms.

The 2011 Secure Boot certificate expiries have now passed; devices that never took the Windows UEFI CA 2023 key updates under CVE-2023-24932 can no longer receive updated boot components, with the Windows Production PCA for the boot manager still ahead on 19 October 2026. Kerberos RC4 hardening (CVE-2026-20833) has been in enforcement since April 2026; the July 2026 update removes the RC4DefaultDisablementPhase rollback control that let administrators defer it, making enforcement final.

Microsoft’s July 2026 Patch Tuesday is a security-only release: 180 test-guidance entries, 14 of them high risk (June had one). Printing and graphics are the centre of gravity: win32kfull.sys, the kernel-mode window manager, is the most-patched binary (14 entries), and seven high-risk flags sit alongside it – the Print Spooler, four win32k entries, and two GDI+ metafile entries. NTFS is the second theme, with 10 entries, two high risk. Every entry reports no functional changes – it’s pure regression validation. The packages span Windows 11 26H1 back to Server 2012 ESU.

Printing and graphics (high risk)

The Print Spooler flag centres on shared printers, whose queue status must track jobs accurately; the win32k flags cover 32-bit application printing, font rendering in printed and exported output, on-screen rendering, and window management; the GDI+ flags cover metafiles.

• Share a printer from a print server, print from a separate client in varied sizes and formats, and cancel a job, confirming the queue reflects every state change
• Print from your 32-bit applications, and print text-heavy, graphics-heavy, and multi-page documents to physical and virtual (PDF or XPS) printers, repeating after orientation, scaling, and resolution changes
• Export documents with varied fonts to PDF and confirm fonts and layout survive; render EMF+ files that apply effects to very large images, and convert EMF files to WMF
• Open and close windows rapidly, drive common dialogs by mouse and keyboard, and close parents with children open – no orphaned windows

Storage and file systems (high risk)

Both NTFS high-risk flags target integrity – extended attributes, and volume recovery after an unexpected shutdown. File History carries its own high-risk flag on clients. A Windows Server 2025-only bundle across boot, BitLocker, and ReFS demands the full Secure Boot/BitLocker matrix. Eight entries hit Server 2025 alone, including WSL, GPU partitioning, and a scripted Windows Server Backup pass repeating recovery after rolling the date 90 days forward.

• Exercise NTFS extended attributes – older-system EAs, backup workflows that preserve them, concurrent same-file operations where supported – with antivirus, encryption, or storage filters active
• Simulate an unexpected shutdown during file activity, verify the volume mounts intact, run chkdsk, and confirm indexing, shadow copies, and backup still work
• Run a full File History pass: back up, modify and back up again, exclude folders, change frequency, move the destination
• On Server 2025, boot all four Secure Boot/BitLocker combinations, in standard and confidential VMs where supported

Devices, input and networking (high risk)

Three further high-risk flags land here: HID input (hidparse.sys with win32k) – touch, keyboard, mouse, touchpad, through disconnects and restarts; the WinSock bundle (afd.sys plus Bluetooth and multicast drivers); and IrDA. The heaviest ask is not high risk at all: the NetAdapterCx driver (24H2/25H2, Server 2025) wants 500-plus adapter enable-disable cycles under Driver Verifier.

• Run the connectivity suite: browsing, large downloads, mapped drives, an RDP session idle 30+ minutes, a Teams call, an hour of streaming, and localhost apps such as Docker or WSL
• Stress Bluetooth: pairing, 10+ minutes of audio, input after idle, and reconnection after sleep
• Where infrared hardware exists, transfer a file and run at least 100 connect-disconnect cycles
• Sweep the rest: DNS Server (zone data must stay under its configured database directory), the client resolver (five entries), DHCP Server (five entries), SMB, NFS, Message Queuing (five entries), RRAS administration, client VPN, and WinHTTP/WinINet consumers

Other windows components

Windows Installer itself is patched: testing should include application install, uninstall, repair, and force a rollback. Hyper-V wants virtual-switch traffic as part of its testing exercises with Virtual Filtering Platform policies enforced. Sixteen media-related security entries cover playback, HEVC and MPEG-TS, USB audio, and MIDI 2.0.

Shell hardening and LSA isolation

These two entries are a little different from the rest of the cycle: they ask you to confirm a security behaviour actively works, not just that nothing regressed. A pass here means the protection fired, so treat them as functional checks rather than box-ticking.

• Shortcut handling (windows.storage.dll; Windows 11 23H2 and earlier, plus Server 2022): drop a shortcut file carrying the Mark of the Web into a folder and confirm the system refuses to extract its icon and leaks no NTLM credential hash – include the zero-click paths, where the icon would otherwise render without you opening anything
• LSA isolation and KeyGuard (24H2/25H2, Server 2025): run the supplied PowerShell validation script, which turns on Virtualization-based Security if it isn’t already, exercises KeyGuard key operations in both required and best-effort isolation modes, and reports pass or fail – it needs TPM 2.0, UEFI with Secure Boot disabled, and PowerShell 7
• Run that script on a dedicated test machine, never a shared one: it enables test signing, disables automatic updates, and reboots without asking

Office & SharePoint

July’s Office wave is security-only; everything landed on 14 July, and nothing critical or non-security shipped in the 7 July preview. It’s an MSI-only cycle, so Click-to-Run estates can sit this one out.

• On MSI Office 2016, apply the client updates – Excel (KB5002886), Word (KB5002890), PowerPoint (KB5002867), and five further Office 2016 security updates (KB5002273, KB5002887, KB5002748, KB5002857, KB5002830) – then exercise macros, external data, embedded objects, and any line-of-business add-ins
• On SharePoint Server, patch 2016 (KB5002891, plus the KB5002892 language pack) and Subscription Edition (KB5002882), then check browser-based editing; the guidance lists SharePoint 2019 with a baseline but ships no 2019 package, so there is nothing to install there

Mind the rollback rules before you schedule the window: most client updates can be uninstalled, but the server updates cannot and always require a reboot.

Developer tools & databases

The developer estate gets a broad but low-drama sweep this month. Both .NET and SQL Server patch widely, but the ask is representative-application validation rather than anything exotic – install on the matching branch and confirm normal behaviour.

• .NET: install the SDK updates (8.0.423, 9.0.316, 10.0.302, x64 and x86) and the Framework rollups spanning 3.5 through 4.8.1 – which reach from Windows Server 2012 up to Windows 11 26H1 and Server 2025 – then run a representative set of applications and confirm they function normally
• SQL Server: the GDR updates span 2016 SP3 through 2025 – install each on its matching branch and test that each removes cleanly
• Check an encrypted client connection through the separately patched Windows SQL client (dbnetlib.dll), which ships outside the server branches

The Readiness team recommends the following priorities for your larger enterprise deployments:

• Start with printing and graphics: half the high-risk flags sit in the Print Spooler, win32k, and GDI+, so regress shared printers, 32-bit printing, PDF export, metafiles, and window management before anything else
• Take NTFS next – extended attributes and crash recovery both touch data integrity – and add a client File History backup-and-restore pass
• Give Server 2025 its wider matrix – the Secure Boot/BitLocker combinations, WSL, GPU partitioning, and the scripted backup pass – and work through the stress suites
• Run the scripted KeyGuard validation on any VBS estate, preferably on a dedicated machine.

Each month, we break down the update cycle into product families (as defined by Microsoft) with the following basic groupings:

• Browsers (Microsoft IE and Edge)
• Microsoft Windows (both desktop and server)
• Microsoft Office
• Microsoft Exchange and SQL Server
• Microsoft Developer Tools (Visual Studio and .NET)
• Adobe (if you get this far)

Browsers

Edge has had a busier month than usual. Microsoft addressed 46 Microsoft Edge (Chromium-based) CVEs this cycle. None critical, but heavily weighted to remote code execution (21 entries) and spoofing (13), led by CVE-2026-58289, a remote code execution flaw. A run of further RCEs (CVE-2026-57981, CVE-2026-56645, CVE-2026-57974) follows.

• Microsoft Edge – the Edge-specific fixes ship in the Edge stable channel (version 150.0.4078.65, released 9 July). The concentration of RCE and spoofing this month is worth a look for managed Edge estates rather than a routine wave-through.
• Chromium upstream – 427 CVEs relayed through MSRC this cycle, spanning the weekly Chrome release cadence since the June report: use-after-free, out-of-bounds read/write, type confusion, and inappropriate-implementation flaws across V8, Dawn, ANGLE, Skia, and Tint. The same fixes ship in the Chrome Stable channel; see the Chrome releases blog for the upstream notes.

The Chromium volume looks (quite) alarming but is routine plumbing: it flows to Edge through its own auto-update channel. Add these browser (Edge) updates to your standard release schedule for your managed environments.

Microsoft Windows

Windows carries the bulk of this month’s updates: 406 CVEs, 31 rated critical and 374 important. Elevation of privilege dominates by volume (226 entries), followed by remote code execution (70), information disclosure (70), denial of service (23), and a scatter of security-feature-bypass, tampering, and spoofing entries across the following feature groupings:

• DHCP – the standout network cluster: DHCP Server remote code execution (CVE-2026-50518, “Exploitation More Likely,” and CVE-2026-56159), with further critical DHCP Server and DHCP Client RCEs behind them (CVE-2026-48564, CVE-2026-50370, CVE-2026-54128). DHCP servers are the deployment priority.
• VMSwitch and Hyper-V – the Windows VMSwitch elevation of privilege (CVE-2026-57092) is one of the month’s highest-severity flaws, joined by two critical Hyper-V elevation-of-privilege entries (CVE-2026-50680, CVE-2026-54127), guest-to-host risk on virtualisation hosts.
• Network stack RCE – a Windows Server Network driver RCE (CVE-2026-56188, “Exploitation More Likely”), plus TCP/IP (CVE-2026-54999), the Reliable Multicast Transport Driver (CVE-2026-54982), and SSTP (CVE-2026-50694).
• Graphics – Windows GDI+ remote code execution (CVE-2026-50380) and a DirectX Graphics Kernel RCE (CVE-2026-50382), both reachable through document-rendering paths.
• Windows Media – a large cluster: three critical Media Foundation RCEs (CVE-2026-57090, CVE-2026-57094, CVE-2026-57087) lead 14 Windows Media and seven Media Foundation entries overall.
• Identity infrastructure – beyond the exploited ADFS flaw, Active Directory Domain Services takes a critical RCE (CVE-2026-49164) and Active Directory Certificate Services a critical elevation of privilege (CVE-2026-54121). Domain controllers take priority again.
• Print Spooler, WSUS, and MSMQ – critical RCE/EoP in the Print Spooler (CVE-2026-58608), Windows Server Update Services (CVE-2026-50444), and Message Queuing (CVE-2026-54992, “Exploitation More Likely”), all server-role attack surface.

The Windows Kernel is the most-patched component (28 CVEs, seven “More Likely”), followed by NTFS (21), Windows Runtime (17), Windows Media (14), ReFS (12), and Win32k (15 across its two entries). Add this Windows update to your Patch Now deployment schedule.

Microsoft Office

Microsoft released 96 Office CVEs this month: 19 critical, 76 important. Remote code execution leads (53 entries), ahead of information disclosure (27) and spoofing (10). SharePoint is the centre of gravity: it touches 39 of the 96 CVEs and supplies the family’s one actively exploited flaw.

• SharePoint Server: has been exploited (who would have guessed) and reaches end of support today. CVE-2026-56164, an elevation of privilege, is under active exploitation. Above it sit two critical remote code execution flaws, both “Exploitation More Likely” (CVE-2026-50522, CVE-2026-58644) and a critical security feature bypass (CVE-2026-55040). SharePoint Server 2016 and 2019 reach end of support on 14 July, so this exploited, critical-heavy set is the final security update those on-premises farms will receive.
• Office has experienced a long run of critical remote code execution entries across Office, Word, and PowerPoint (among them CVE-2026-55033 and CVE-2026-55127 in Word, CVE-2026-55043 in PowerPoint, and CVE-2026-55018 in Office), topped by CVE-2026-55045.

With an exploited zero-day, two RCEs, and an end-of-support deadline all landing on SharePoint in the same cycle, SharePoint environments are the priority. Add the July Office and SharePoint updates to your Patch Now schedule.

Microsoft Exchange and SQL Server

Both Exchange and SQL Server carry critical-rated security vulnerabilities this month. Exchange Server returns with an on-premises security update for Exchange Server Subscription Edition, the only on-premises release still supported after Exchange Server 2016 and 2019 reached end of support in October 2025; SQL Server takes two critical remote code execution flaws, one of them against SQL Server 2016, which reaches end of support on the same day.

• Exchange Server (on-premises) – CVE-2026-55008, a spoofing vulnerability rated critical and “Exploitation More Likely,” is the headline. Behind it, a remote code execution entry (CVE-2026-55005) and two elevation-of-privilege flaws (CVE-2026-55006, CVE-2026-55009) round out the on-premises set. A separate Exchange Online elevation of privilege (CVE-2026-54998, critical) is fixed service-side with no customer action.
• SQL Server – two critical remote code execution flaws: CVE-2026-54117 (SQL Server 2025) and CVE-2026-54118 (which reaches back to SQL Server 2016 SP3), with five further important elevation-of-privilege and information-disclosure entries behind them. The 2016 exposure matters because SQL Server 2016 reaches end of support on 14 July: a critical RCE on a platform taking its final update.

Both belong on the Patch Now schedule this month: the Exchange on-premises update for its critical spoofing flaw, and the SQL Server update for the two critical RCEs.

Microsoft developer tools

Microsoft released 24 CVEs across its developer tooling this month, all rated important. The weighting shifts from last month’s Visual Studio Code concentration toward .NET and ASP.NET Core, where a run of denial-of-service entries dominates the volume:

• ASP.NET Core and .NET – the two highest-severity entries are ASP.NET Core elevation-of-privilege entries (CVE-2026-47300, CVE-2026-47303), ahead of a .NET security feature bypass (CVE-2026-50528) and two .NET / .NET Framework remote code execution flaws (CVE-2026-50646, CVE-2026-50649).
• Visual Studio and VS Code – a GitHub Copilot / Visual Studio Code security feature bypass (CVE-2026-41109) and a second VS Code security feature bypass (CVE-2026-57102) lead here, with a VS Code remote code execution entry behind them (CVE-2026-50520) and a Visual Studio RCE (CVE-2026-47305).

Add these Microsoft updates to your standard developer update release schedule.

Adobe (and third-party updates)

Outside Microsoft’s own catalogue, July is quiet. Adobe issued no Acrobat or Reader security updates. So, the month belongs to Microsoft, and it is a heavy one: 722 CVEs, roughly three times a normal cycle and one of the largest on record. Worth noting that this lands in the same season Microsoft has been talking up AI-assisted vulnerability management, and the AI stack it is selling as the answer, Copilot and Azure OpenAI among them, sits in the centre of this patch cycle’s own critical-rated updates. The (AI) tooling may be getting smarter, but the patch pile is (definitely) not getting smaller. This may be the beginning of an accelerating curve of ever larger patch cycles. My feeling is that we are in the middle of the beginning of this coming patch surge.

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

Dozens of former Apple employees now working at OpenAI have been put on notice after Apple reportedly sent legal letters ordering them to preserve documents and communications relevant to its trade secrets lawsuit against OpenAI. 

The Financial Times reports that “around 40” employees have been targeted with these letters, which repeat Apple’s claim that its confidential information might have been exfiltrated, alleging “trade secret misappropriation and breach of contract.”  The letters also require them to arrange to meet with Apple’s lawyers.

The underlying lawsuit

This comes on the heels of Apple’s explosive lawsuit against OpenAI in which Apple accused the AI company (and former Apple Vice President Tang Tan) of extensive coordinated data theft. Tan was at Apple for 24 years and is now Chief Hardware Officer at OpenAI. 

Apple’s lawsuit is defined by claims OpenAI took a range of steps to pry confidential Apple data from existing Apple employees, including using information such as internal project code names, to gain even more knowledge during interviews. The company says the evidence it has presented so far is only the “tip of the iceberg” concerning OpenAI’s approach.

The lawsuit requests that OpenAI be prevented from using any Apple information during the development of its hardware. Apple is also seeking damages and suing two former employees for breach of contract for violating their employment agreements.

The letters are significant. They represent formal directives that require former Apple staff to preserve documents, messages, emails, and other communications that could be relevant to the case. The demand reflects Apple’s belief that the alleged misuse of confidential information could be more widespread across the competing company. What’s critical is that orders of this kind override any standard data destruction policy and deletion of the requested information becomes a legal offense. 

Why this matters beyond the protagonists

In making its move, Apple shows this is not a dispute about just one or two hires, but an attempt to constrain the movement of intellectual property between the two firms. With AI hardware emerging as the next major battleground in tech, the case could become a defining one; whatever resolution is eventually reached could define the extent to which former employees can carry experience and knowledge between competing firms. The case might also define what the line is between experience and knowledge and the sharing of trade secrets.

This is important, because modern hardware development relies on far more than just finished designs. Product design leans into supplier relationships, manufacturing assumptions, physics, extensive prototyping, and product-roadmap priorities. If courts treat those accumulated insights as protectable secrets, hiring between major technology companies could become far more legally sensitive.

The Jony Ive question

The case comes as Apple prepares to combat OpenAI in hardware. Its competitor is now working with legendary former Apple designer Jony Ive. Ive is not named in the litigation, but Apple will be keen to find out whether confidential product knowledge, design processes, or supply-chain insights have travelled with former staff into OpenAI’s device work.

Ultimately, for Apple, it’s about protecting its many blueprints for whatever hardware the company expects will come after the iPhone.

For its part, OpenAI has refuted Apple’s lawsuit, arguing that it is “not aware of any evidence” that the lawsuit has merit. “We have no interest in other companies’ trade secrets,” said OpenAI spokesperson Drew Pusateri. “We remain focused on building innovative technology that empowers people everywhere.” The company’s lawyers also claim it did respond to Apple’s initial inquiries on the matter.

What’s at stake

The significance of Apple’s newly-shared communication preservation orders is that if discovery uncovers evidence supporting Apple’s claims, the case could complicate OpenAI’s hardware plans and create unwelcome scrutiny ahead of any future public offering.

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

We are inundated with promises that artificial intelligence will save us and that the next governance framework will protect us. Buy this platform, adopt that model and the hard part finally gets easier. After 15 years in this field, I have wanted that shortcut as much as anyone.

But both promises are downstream of something neither one can produce. You cannot automate trust between two people. You cannot govern your way to a relationship. As AI moves into the core of how organizations operate, and accountability stops mapping cleanly to the org chart, what holds when the stakes are highest is not the platform or the policy. It is two human leaders who know each other well enough to carry the weight together.

I think about this often now, a year after publishing a book about the pressures bearing down on security leaders, “The CISO On The Razor’s Edge: Leading Cybersecurity When The System Is Designed To Break.” The partnership between the CIO and the CISO is the last human relationship in cybersecurity. AI raises the stakes. Governance sets the floor. The relationship is what holds.

I saw it work once, up close. When I worked in Washington State, the CIO, Bill Kehoe, talked to his CISO, Ralph Johnson, every day. Weekends included. Not because a policy required it, but because the mission did. That partnership is a large part of why the role stayed sustainable for them when it broke so many others.

The promise we keep believing

Walk any conference floor and you will hear the same pitch in a hundred variations. The next AI layer will close the gap. The next framework will lock down the risk. The technology is usually ready. The organization is not. I have watched too many well-funded programs stall to still believe the tool is the answer, and almost every time, the breakdown traced back to leaders who were not aligned before the work began. A framework run by misaligned leaders inherits the misalignment. You can buy the best controls on the market and still watch them fail when two leaders work from different assumptions about who owns what.

Bill and Ralph understood this. Security decisions were not handed to Ralph after the fact to bless or block. They were made with him, inside the technology decisions, because the two had already agreed on what mattered. That is not governance. That is leadership creating the conditions in which governance can work.

It is the real lesson I came to in the book. Technical knowledge matters, but it is not enough. As I wrote then, “Influence, trust and internal relationships are non-negotiable.” Without influence, CISOs cannot lead. Without technical substance, they cannot prioritize what matters. And without partnership, especially with their CIO, “they’re operating without a safety net.”

AI does not change that truth. It raises the cost of ignoring it.

When decisions move at machine speed

The ground under both roles is shifting. Work no longer flows through people alone. It moves across people, platforms, partners and agents at the same time, and it moves fast. Decisions that once waited for a meeting now form in seconds. The org chart, built for an era when humans did the work and reporting lines explained accountability, struggles to keep up.

This is where the partnership stops being a nicety and becomes infrastructure. When decisions form at machine speed, the human escalation path has to be instant. There is no time to negotiate a relationship in the middle of an incident. Either the trust is already there, built in the quiet stretches before anything goes wrong, or it is not there when it counts.

I asked Bill what he would lose if his daily calls with Ralph dropped to once a week. His answer cut straight to it.

“Cyber does not rest,” he told me. “It is active and dynamic and requires 24/7/365 attention.” Drop to a weekly check-in, he explained, and “I am treating the CISO like any other executive position.” For Bill, AI only raises the stakes on that daily contact. “Relationships and partnerships between the CIO and CISO will never die due to AI,” he said. “I can’t even imagine a scenario where I don’t talk to my CISO on a daily basis including weekends to discuss the latest risks and vulnerabilities or news on potential AI attacks.”

That is the point most of the market misses. A platform can flag the anomaly. It cannot decide what the organization is willing to risk, who carries that decision or how two leaders stand behind it together. The faster the machines move, the more the partnership has to already be in place.

The loneliest seat in the building

There is a reason some now call the CISO job the least desirable role in business. The seat carries enormous accountability and rarely the authority to match. As one security leader put it, the pressure has never been higher and the control has never felt lower. People are burning out and walking away from a role that has never mattered more.

Here is the hard part. There is no log file for burnout. No alert fires when the weight finally exceeds the leader. That drain is invisible right up until it is not, and it raises organizational risk as surely as any unpatched system. The structural fixes the industry debates are all real and all slow.

The fastest source of relief available to a CISO is not a framework. It is a CIO who treats the relationship as a daily partnership rather than a line on a chart. An isolated CISO is a vulnerability. A partnered one is an asset.

You see what that partnership is worth in the worst moment. I asked Bill what it looks like when an incident hits and public trust is on the line. He did not reach for a tool.

“I am accountable as CIO to everything that occurs in the state from a technology lens including cyber,” he said. When a severe incident hits, the call comes to him from agency leadership or the Governor’s Office. Then he follows the plan, but never alone: “I will be in constant contact with the CISO on the details of the incident.”

That is the safety net made real. The CISO is not carrying the mission alone at the moment it matters most. On the razor’s edge, leadership keeps you upright. Partnership keeps you in the fight.

The work no tool will do for you

In my advisory work, I sit with C-suite leaders who share values and still cannot find alignment. The barrier is rarely disagreement. It is that they are not communicating clearly or often enough to build the trust that alignment requires. I have watched negotiations that could only happen by proxy, over email, because two capable leaders had stopped talking directly.

I recently sat in an hour-long discussion where alignment and shared values were present the whole time. It did not become clear until the final fifteen minutes. That is what real alignment costs: patience, persistence and a stubborn commitment to clarity. If leaders cannot do that work themselves, no AI model or governance tool will do it for them.

This is why I stand up an AI review board for the organizations I work with and host the leadership conversations that decide whether a company’s AI ambitions thrive or stall. The board itself matters less than what it provides: neutral ground, a regular cadence and an agenda that forces the hard issues into the open before a crisis forces them. If your organization has no venue like that, that absence is its own form of dysfunction. The cadence is what makes communication effective. Not easy. Effective.

Build the bond on purpose

You cannot framework your way to trust. But you can build it deliberately, and that is a leadership act, not a governance one. The partnership and stakeholdering skills that once looked like soft extras are now the core executive work. A few moves matter most:

• Set a standing contact rhythm with your counterpart before you need one, daily or near-daily, not quarterly
• Make decision rights and accountability explicit while it is calm, so no one improvises them mid-incident
• Translate security into business outcomes together, so the board hears one aligned voice

Build the relationship as deliberately as you would build any critical control, because that is what it is. If you cannot connect the partnership to outcomes the business actually feels, you have a friendship, not a performance lever.

A year after writing “The CISO On the Razor’s Edge,” I am even more convinced that strong leadership precedes effective governance and partnership precedes them both. This is the good news, not the hard news. The CIO and CISO who build real trust do not just reduce risk. They move faster than their competitors, because they spend no energy fighting each other. They earn the board’s confidence, because the board hears one clear voice. And they unlock the AI strategy everyone else is still struggling to govern, because they have already done the human work that makes governance hold.

That is the upside waiting on the other side of this relationship. AI will keep advancing. Governance will keep maturing. But the organizations that win the next decade will be the ones where two leaders decided the partnership was worth building before they needed it. Bill and Ralph knew it every day, weekends included. The edge is there for anyone willing to do the same.

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

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

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

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

Build vs. buy is a category error

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

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

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

The vendor AI stack has an assumption baked in

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

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

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

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

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

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

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

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

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

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

What this means in practice

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

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

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

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

The real question

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

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

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

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

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

Organizations usually face the same questions concerning XLAs: What should we measure, who owns the data, how should incentives work, and how will this change provider behavior after signature.

There are no easy answers either, but after advising clients in MSP relationships with major providers, I’ve seen what works and what doesn’t. Successful XLA programs rarely start with massive transformation, nor rely on perfection before adding experience accountability to the contract.

Start with the right metrics

The first concern I hear is what to measure. MSPs often steer that discussion toward metrics already in their reporting stack. That’s a trap.

Unlike SLAs, which measure operational outputs, XLAs should focus on employee experience and business outcomes. The strongest programs start with three to five high-signal metrics tied to the employee journeys creating the most friction. More than that and the program loses focus before it gains traction.

I typically recommend starting with employee satisfaction scores, perceived lost productivity time, repeat incident rates, task completion success, and ease of getting support. Then focus early measurement on common employee experiences like service desk interactions, employee onboarding, application reliability, and device performance.

Trying to measure everything is understandable, but it’s also one of the fastest ways to stall an XLA program.

Precisely define roles and responsibilities

This is the part of XLA contract design where I spend the most time with clients, and it’s the part that major MSPs are most likely to leave vague if you let them. Accenture and TCS both have mature commercial teams skilled at agreeing to things in principle while avoiding specific accountability in writing. Don’t let that happen here.

Employee experience isn’t solely the vendor’s responsibility. It’s genuinely shared, which is a more productive framing than pure vendor accountability, but only if the split is clearly spelled out. This is what I’ve found works in practice.

Customer responsibilities

• Selecting tools and platforms
• Managing data infrastructure
• Sharing experience data openly with the provider
• Supporting internal improvement initiatives that the provider flags

Vendor responsibilities

• Running the measurement cadence
• Delivering monthly experience reporting
• Identifying and surfacing improvement opportunities from the data
• Executing operational improvements within agreed timelines

Without this level of specificity, XLA programs almost always become reporting exercises. The data gets collected, the scorecard gets presented, and nothing actually changes.

Build flexible targets

One of the biggest mistakes in XLA design is treating experience targets like traditional SLAs,  setting once at contract signing and left unchanged for years. Employee expectations, workforce patterns, and technology environments, after all, evolve constantly. A target that feels ambitious in year one may become meaningless by year three.

The strongest XLA contracts include formal reviews every three to six months to recalibrate targets, align with business priorities, and raise expectations as experience improves. This prevents providers from locking in easy wins and coasting. When providers resist review cycles, it’s often a sign they believe the targets can be met on autopilot, a red flag in any XLA program.

Use the right scoring method

One overlooked XLA best practice is how experience scores are calculated. Point-in-time scores can be distorted by outages, isolated incidents, or low survey participation, and providers sometimes exploit that volatility.

I advise clients to calculate official XLA scores using rolling two-month averages instead of snapshots. It creates a more stable and accurate view of experience trends, and makes operational timing games much harder. Most importantly, define the scoring methodology explicitly in the contract. Don’t leave it to be worked out operationally after signing.

Structure incentives carefully

Relying on penalty-only incentives is one of the most expensive XLA mistakes. On paper, the model is simple: miss the target, pay the penalty. In practice, it drives the wrong behavior. Providers focus on protecting themselves instead of improving employee experience, optimizing survey timing, and managing averages rather than solving problems collaboratively.

I’ve seen this repeatedly in Infosys, HCL, and TCS relationships. The strongest XLA structures combine risk and reward where providers earn meaningful upside for exceeding targets, innovating, and improving outcomes. Penalties still matter, especially in mature programs, but they can’t be the only lever otherwise the contract becomes another SLA model with better branding.

Define escalation processes

When experience scores fall below threshold, the contract needs to specify what happens next. This sounds obvious, but I’ve reviewed many service delivery measurement frameworks in clients’ incumbent MPS contracts that specify financial consequences without defining any collaborative process to address the underlying problem.

The escalation language I push clients to include specifies:

• a joint review process triggered when scores fall below threshold.
• root cause analysis expectations and timelines.
• remediation planning requirements with named owners on both sides.
• timelines for corrective action and progress reporting.

The framing matters as much as the mechanics. Escalation should be positioned as collaborative problem-solving, not blame assignment. Contracts that turn every missed score into a commercial dispute damage the relationship when provider engagement matters most. The best MSPs treat escalation as a shared diagnostic exercise, not a contractual confrontation.

Establish an operating rhythm

Signing the contract is the beginning, not the end. In my experience, the organizations that get the most out of XLA programs are those that build a disciplined operating cadence and stick to it. The ones that treat XLAs as a reporting exercise almost never see meaningful improvement.

This is the cadence I recommend:

Daily: Both parties maintain live dashboards showing experience trends, application performance, regional issues, and persona-specific insights to catch emerging issues.

Weekly: Customer and vendor teams hold focused working sessions to determine what improved experience this week, what hurt it, which remediation actions were completed, and what’s the priority for next week.

Monthly: Formal governance meetings to review experience scores, improvement actions, root cause discussions, and cross-functional issues that need escalation.

Biannually: Leadership steering meetings to assess overall experience performance, recalibrate targets, and align the XLA program with evolving business priorities to honestly evaluate whether or not the program is driving the outcomes the organization actually cares about.

Common mistakes organizations make

After working through XLA design and implementation with clients across their MSP relationships, the failure modes are predictable. Here’s what to watch for.

Setting targets before establishing a baseline
Rushing into targets before understanding your current state is one of the fastest ways to create disputes. Spend the first three to six months gathering baseline data, then negotiate targets based on evidence rather than guesswork.

Measuring too much
More metrics don’t create more insight. Frameworks with 20 data points rarely survive operational reality. Start focused and expand gradually.

Hiding the data
Transparency is foundational to XLAs. Providers who obscure poor scores, especially when controlling the measurement platform, undermine the entire model. Clients who weaponize the data create the same problem. Build mutual transparency obligations into the contract.

Over-relying on penalties
Penalty-only structures recreate legacy SLA behaviors. Balanced incentives drive better long-term outcomes.

Treating XLAs as static
Employee expectations, technology, and business priorities evolve constantly. Without formal review cycles, XLA programs quickly become irrelevant.

Start smaller than you think you need to

The organizations that get XLAs right are rarely the ones with the most sophisticated tooling. They’re the ones that stopped waiting for a perfect program and introduced real accountability into the contract with what they had.

The most effective starting points are often simple: agree on a focused set of experience metrics, establish a six-month review cycle, commit to shared visibility and data transparency, and create joint accountability for continuous improvement.

From there, maturity develops over time. Governance builds trust, data becomes more actionable, and targets evolve alongside business priorities. The relationship shifts from compliance management to outcome-driven partnership.

In my experience, the organizations that succeed are the ones that stopped accepting green scorecards at face value and demanded something more meaningful.

Once upon a time, there were actual arguments as to whether CIOs should be business people, not technology people. With any luck, these arguments were stomped out back here: “The case against the ‘business-savvy CIO’” — which drove the arguments for this false dichotomy into the ground back in 2018.

Some complications have arisen in the near decade since, so I’m afraid we need to revisit the subject — especially as the most recent of this has made the drumbeat for business-savvy CIOs that much louder.

One source of this need was the case of the dreaded Digital adjectival abuse, also known as “Digital as a Noun.”

Digital was a big deal back in the pre-COVID era. It matters here because for Digital to work, business leaders needed to be technologists, not just business people.

As business leaders became better technologists, CIOs needed to keep up on the business potential for the various Digital technologies their business leader friends were suddenly asking for.

Another source of confusion was COVID itself, and the discovery it led to on the part of those business executives not already convinced that the entire business ran on IT, and that any area that still relied on manual processes should be presumed incompetent. Rather than insisting on a full-blown ROI to justify automating a function, those relying on manual methods were (or should have been) asked to justify this choice.

AI changes the equation

But as tendentious or tectonic as those shifts might have seemed at the time, AI is raising the now-what-do-I-do? equation to new heights.

That’s because CIOs are now being given a new set of alternatives:

• Whether they want to be business people after all;
• Whether they should become or remain classical business/technologists;
• Or, should they set their sights on becoming AI business/technologists.

You might have noticed an emerging trend in IT: The proliferation of articles about AI whose content even many tech-savvy CIOs can’t make heads or tails of.

And no, the problem isn’t that their texts include a bunch of unfamiliar buzzwords.

Much of the offending content is rooted in unfamiliar concepts, not vocabulary changes.

Or, even more frustrating, the puzzlement sometimes lies in familiar buzzwords whose meaning has changed and become obscure.

So never mind whether CIOs should be business people or technologists. A more challenging question is whether CIOs should be business people, classically tech-savvy people, or AI/tech-savvy people.

Or some combination of those alternatives.

But wait, there’s a whole other level we need to dig through. That’s because this collection of confusing questions isn’t the starting point. It’s because, as CIO, the questions that matter aren’t about how the CIO engages with the rest of the company as an executive.

It’s how the CIO engages as the company’s highest-level business analyst.

The CIO’s changing roles and directives

With classical IT organizational architectures, a CIO could make sense of all of IT’s slices, dices, and levels, how the pieces fit together to make the business more effective, and how adding and rearranging the pieces could help make the business more effective and competitive.

In the good ol’ days, that is, CIOs could succeed wearing their business analyst haberdashery without having to give up their executive function.

Read the average opinion piece on how AI affects the CIO’s role and you’ll get the same tired back-office-to-front-office recommendations we waded through when Digital was king. But AI isn’t what’s driving that shift, if it even is a shift.

No, here’s what I think the average CIO is in for:

• Elevating the business analyst: CIOs need to be smart about AI, but aren’t in a position to make themselves business-analyst-smart about AI. So it’s up to the CIO to give IT’s best business analysts assignments that will make them AI- smart, and to schedule regular debriefings to help the CIO become smart enough.
• Become architect-level smart about AI: CIOs should build a capability-level view of AI, collaborating with the whole IT department to gain a realistic understanding of what high-level business capabilities AI does and could bring to the business party.
• Adopt the CSO hat on the company’s behalf: No, notchief security officer. Chief skepticism officer: What the company needs the CIO to become is someone able to see through the hype and blather that sets implementation traps and leads to seductive but unachievable transformation programs.

Why this matters more than you might think

Once upon a time, one of the hallmarks of well-built IT was simplicity. IT professionals designed and engineered systems they and their colleagues could understand because the systems were designed to be graspable.

Among the many changes AI is bringing to the fore is that AIs don’t need the same level of simplicity, and we can anticipate that AIs won’t be instructed to make their designs human-graspable either.

We already have too many applications in the IT portfolio that are the only repositories of business logic the company has — the developers and business analysts who supported this business logic retired long ago.

That was the case when simplicity was a design goal.

Just imagine the scenario when AIs build systems for which simplicity isn’t a target they’re aiming for at all.

See also:

• AI is reducing leadership to simply managing work
• Can an AI be a competent leader? Let’s find out
• AI is about to get really weird. CIOs better be prepared.

The industry conversation around AI infrastructure has narrowed to a single dimension: scale. The focus is on GPUs, power, cooling and the massive physical footprint required to train and run AI agents and models. At the same time, organizations are adjusting to the speed and scale with which AI is identifying vulnerabilities — which is much faster than remediation can be started.

However, almost no one is talking about the infrastructure layer that actually determines whether AI workloads remain secure, resilient and compliant. This is the layer that runs the world’s most sensitive, regulated, high‑value workloads. Thankfully, it already has the guardrails needed for an era where vulnerabilities are discovered faster than ever. But are they being set correctly?

With more than one billion AI agents expected by 2029, organizations need a plan for their infrastructure layer to withstand threats from new frontier models, maintain uptime and protect data sovereignty. As they scale AI deployments, enterprises must secure the infrastructure AI depends on.

These five steps outline what organizations can do now to strengthen their infrastructure posture using proven, enterprise‑grade practices for current and future threats.

Step 1: Build on infrastructure engineered for security and resilience

Infrastructure must be secure by design, not secured after deployment. The systems that have historically supported the world’s most critical workloads — from global payments to national‑scale operations — were built with this principle at their core. If you’ve already invested in systems designed for mission-critical workloads, you’ve checked this first box.

Enterprise‑grade systems have been engineered with multilayered security controls, pervasive encryption, confidential computing and hardware‑level protections that make exploitation dramatically harder. A frontier model in the hands of a bad actor can chain weaknesses faster than humans can patch them — unless the underlying infrastructure is built to absorb and deflect that pressure.

When I meet with clients, I often tell them what our own security teams operate under: we assume vulnerabilities will continue to be discovered and we design for that reality. That mindset is what separates infrastructure that survives frontier‑model pressure from infrastructure that collapses under it. These systems continue to evolve with predictive failure analysis and accelerated recovery, allowing systems to continue operating even during investigation and remediation.

Step 2: Treat uptime and resilience as a security requirement

If your infrastructure fails, your workloads will too. These systems depend on uninterrupted access to data and compute, and even seconds of downtime can compound operational and security risk. Enterprise‑grade platforms deliver near‑continuous availability through redundant hardware paths and intelligent system recovery.

The easiest fix? Ample resources and an up-to-date infrastructure foundation. Too often, a security problem is really an availability problem that turned into a security problem. When systems fall behind on maintenance, capacity or recovery readiness, they create the exact openings a frontier model can exploit. A delayed maintenance cycle or a recovery process that takes too long becomes the opening a frontier model can exploit. Resilience is not just about uptime. It is a security control. And this will not be the last time a frontier model tests the limits of that resilience.

Data resilience is equally critical. Cyber‑resilient storage systems with immutable backups and rapid recovery capabilities ensure that critical data remains protected and available even after a cyber incident or disaster.

Step 3: Operate for continuous discovery, not periodic defense

The idea that you can prevent every vulnerability is outdated. The more realistic model is continuous discovery — finding, prioritizing and addressing issues faster than they can be exploited. Organizations must operate as if vulnerabilities will be found faster than ever.  Instead of relying on static defenses, they should emphasize layered controls, rapid triage, continuous delivery of fixes and coordinated disclosure.

Frontier models in the hands of bad actors can amplify security challenges by connecting vulnerabilities. They can chain misconfigurations, outdated components and privilege gaps into a viable attack route in minutes. And the more outdated or inconsistent an environment is, the easier that chaining becomes.

Modern operational‑intelligence tooling helps them surface that risk, prioritize what matters and act before an attacker can exploit the gaps. These platforms help organizations understand where they are exposed, identify which maintenance issues carry the highest operational and security risk, and reduce the blind spots that frontier‑model attackers are increasingly adept at exploiting.

It’s critical to assess how you manage your vulnerabilities. Internal processes should address severe vulnerabilities within hours, regardless of whether they are discovered by humans, traditional tooling or AI‑driven techniques. As AI accelerates vulnerability chaining, this posture maintains operational integrity and reduces exposure.

Step 4: Use AI to defend AI

Leading organizations are integrating AI‑driven threat detection directly into their infrastructure. On operating systems like z/OS, AI‑based analytics can identify anomalous and potentially malicious data access, reducing investigation time and limiting impact.

Beyond detection, autonomous security models are emerging that continuously govern risk, investigate threats and enforce resilience across identities, data, applications, cloud and networks. Across the industry, we’re seeing the rise of autonomous security frameworks that use AI to assess posture, detect threats and harden controls without waiting for human intervention. Combined with modern AI‑accelerated processors, these capabilities allow threats to be analyzed and mitigated directly within the infrastructure itself.

Step 5: Join a broader ecosystem fighting frontier model threats

No organization can face frontier model threats alone. These risks require coordinated industry action. Frontier models give both good and bad actors the ability to analyze codebases, chain vulnerabilities and probe infrastructure at a scale that no single enterprise can counter on its own.

Across the industry, coalitions are emerging to assess and remediate vulnerabilities discovered by frontier-class models and to help enterprises build AI resilience. Initiatives like Project Glasswing, Project QuiltWorks and the Frontier AI Alliance are examples of how providers, consultancies and security firms are beginning to coordinate their response to AI-accelerated threats.

Organizations can also benefit from independent assessments that evaluate readiness for agentic-enabled threats and identify gaps across their infrastructure. These assessments help teams understand where they are exposed, how frontier models might chain those exposures together, and what actions will reduce the likelihood of a high-impact event.

Participating in these programs is one of the most concrete steps enterprises can take today to strengthen their AI infrastructure posture.

Your AI security depends on the infrastructure you choose

AI is accelerating both innovation and risk. The organizations that succeed will be those that build on resilient, secure infrastructure, prioritize uptime as a security control, operate with continuous discovery, use AI to defend AI and participate in the global response to frontier‑model threats. In the end, your ability to scale AI safely comes down to the infrastructure you trust to run it.

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

Meta is reportedly planning a cloud business that would sell access to AI computing power and models, extending its internal infrastructure into a commercial service for outside developers and enterprises. Reuters, citing Bloomberg’s reporting, noted that the planned offering would allow customers to access AI models hosted on Meta’s infrastructure and pay based on usage, effectively positioning the company in the infrastructure-as-a-service and AI platform markets. On the surface, this seems like a logical next step. If you are already spending enormous amounts of money to build AI infrastructure, there is a natural temptation to ask whether some of that investment can be monetized beyond your own internal use.

I have seen this pattern before. A company builds sophisticated internal systems, recognizes their value, and then begins to imagine that becoming a cloud provider is simply a matter of exposing those capabilities to external customers. It sounds straightforward, especially given the excitement around AI and the demand for high-performance infrastructure. But cloud computing is not just another distribution model. It is not simply a matter of offering on-demand multitenant services and charging a fee. It is a deeply operational, trust-based business in a market that punishes companies that do not fully understand what enterprise customers require.

A crowded neocloud market

The first problem Meta faces is that this is not an open opportunity. The neocloud space, meaning purpose-built AI infrastructure delivered as a service, is already crowded and increasingly difficult to enter. Amazon, Microsoft, and Google dominate the conversation for obvious reasons. They have years of cloud operating experience, broad service portfolios, global reach, mature ecosystems, and deeply established enterprise relationships. Oracle remains a serious player as well, especially in enterprise applications, data platforms, and performance-sensitive workloads. IBM still matters in hybrid cloud, operations, and industries where governance and regulatory rigor remain central.

That list alone should give Meta pause. These companies are not just infrastructure vendors. They are experienced cloud operators. They have spent years building not only the underlying platforms, but also the native capabilities enterprises now expect by default. Those capabilities include security, governance, identity management, observability, support, compliance, billing controls, resilience planning, and integration with the broader enterprise technology estate. These are not secondary features. They are part of the core value proposition.

This is why late entry into the cloud market is so hard. A new provider is not just competing on price or capacity. It is competing against accumulated trust. Enterprises are not casual buyers. They are selecting long-term operating environments for applications, data, AI models, and business-critical processes. They want confidence that the provider understands how these services will be consumed, governed, and supported over time. Meta is entering a market where the incumbents already have a major head start on all of those fronts.

Harder than it looks

Over the years, I have had many technology companies come to me and say they wanted to reposition their technology in the cloud space, either as software as a service or infrastructure as a service. In the beginning, enthusiasm is always high. The technology is impressive. The market size looks attractive. The revenue models appear compelling. Investors love the story. Then we begin to walk through what it really means to operate as a cloud provider, and the optimism usually fades fast.

The questions become very practical and very uncomfortable. How will tenants be isolated? How will identity and access controls work across different kinds of customers? What governance models will be built in natively? How will workloads be monitored, optimized, and secured? What does support look like 24 hours a day, across regions, across industries, across compliance boundaries? How will outages be handled, communicated, and remediated? How will the platform integrate with existing customer tools for operations, policy management, and security response? How much investment will it take just to become credible before you even begin to differentiate?

Once companies fully understand the complexities, market dynamics, and the capital and execution required to compete even with secondary players, many of them back off. They realize that cloud technology is not a packaging exercise. It is a transformation in how a company designs, operates, supports, sells, and evolves technology. That is why I remain skeptical when any company assumes it can translate internal infrastructure excellence into external cloud success without a very long, disciplined commitment.

Meta’s market readiness

Of course, Meta is not lacking in financial resources. If any company can afford to spend aggressively in this space, it is Meta. The company has the capital to build infrastructure, absorb losses, hire experienced talent, and stay in the market long enough to make a serious attempt. I would never argue that Meta is too small or too poor to try. Quite the opposite. If there is any non-traditional entrant with the financial scale to force itself into the conversation, Meta would be high on the list.

But money does not erase complexity. It only gives you the chance to confront it. The real question is not whether Meta can afford to become a cloud provider. The question is whether Meta has what it takes to become an excellent cloud provider. Those are two very different things. Enterprises are not going to move meaningful workloads to a new platform simply because the company behind it is wealthy or technically famous. They are going to ask whether the provider understands enterprise consumption patterns, enterprise risk, enterprise governance, and enterprise operations.

That is where the challenge becomes much more serious. Meta has extensive experience running infrastructure for itself. That is valuable, but internal operating excellence is not the same thing as external service maturity. Running systems for your own workloads allows a high degree of control over architecture, standards, priorities, and operating assumptions. Running systems for paying customers requires flexibility, consistency, transparency, and support across a wide range of use cases that you do not control. Those are very different disciplines, and companies often underestimate the gap between them.

What exactly is Meta?

Another concern here is strategic clarity. Meta already has a complicated market identity. It is a social media company, an advertising platform company, a hardware company, an AI company, and still, in the minds of many, the company that spent billions pursuing the metaverse. If it now wants to be viewed as a serious cloud infrastructure provider, it will need to explain not only what it is offering, but why customers should believe this is a durable long-term commitment and not just another adjacent experiment.

That uncertainty can be damaging. Customers want stable providers with clear strategic intent. They do not want to architect important systems around a platform if they suspect the provider may lose interest, shift direction, or reframe the business after a few years of uneven results. Cloud computing requires patience, consistency, and deep customer orientation. It is not a market where strategic ambiguity helps.

This could become confusing for Meta internally as well. Building a true cloud business demands focus. It demands years of investment in areas that may not be glamorous but are absolutely necessary, such as governance, operations, controls, support frameworks, partner programs, and enterprise sales alignment. If the company is not willing to make those sacrifices fully and for the long term, the initiative will struggle.

Shadow IT has long been a major problem for CISOs, but the biggest problem may be coming from the executive suite’s hunger for unsanctioned AI.

Nearly two-thirds of senior decision-makers admit to using unapproved AI tools, compared to just 31% of lower-level employees, according to a survey by Microsoft solutions partner TrustedTech.

The use of shadow AI is prevalent among senior executives even though three in four employees acknowledge security or data privacy risks related to the practice.

“Most shadow AI users are not ignorant of the risk,” TrustedTech says in a white paper. “They are deliberately choosing to use these tools anyway. This is not a training issue. It is a culture, incentives, and alternatives issue.”

In many cases, the problem is driven by a lack of approved tools, the report adds.

“People use shadow AI because what their employer hands them is worse than mainstream AI tools, or because nothing has been approved in the first place,” the report says. “That doesn’t change until the sanctioned tools are genuinely worth using.”

A question of authority

The use of shadow AI by CEOs and other C-suite executives can create major problems for CISOs, CIOs, and other IT executives because they may not have the authority to put the kibosh on it.

It also presents a challenge for IT leaders to provide the AI tools that employees and executives want to use.

When executives use shadow AI, CISOs are in a difficult position, because governance only works when it’s modeled from the top, says Andy Nolan, VP of technology at TrustedTech.

“If senior leaders bypass approved AI tools or policies, it sends an implied message that speed matters more than security and compliance,” he adds. “Employees notice that behavior, and it becomes much harder to ask the rest of the organization to follow standards that leadership isn’t following themselves, first.”

Another major problem is that executives often work with highly sensitive information, including financial data, strategic plans, intellectual property, and customer information, he notes.

But CISOs and CIOs also can’t solve the problem by becoming the AI police in every situation, Nolan says, because their role is to help the business innovate safely.

“That requires executive alignment, clear governance, and providing secure AI tools that people actually want to use,” he adds. “When leadership embraces those solutions, the rest of the organization is almost sure to follow.”

All risk, no reward

The use of shadow AI by senior executives puts CISOs and CIOs in an impossible position, agrees Amit Maloo, CISO at AI procurement provider Ivalua. CISOs and CIOs are held accountable for the risk exposure but have no visibility into the problem, he says.

“When senior leaders use ungoverned AI tools for business decisions, those decisions still have consequences, such as financial commitments, contract reviews, and data sharing,” he adds. “But there is no audit trail, no permissions model, or no way to reconstruct what happened or why.”

Part of the problem is that approved AI options often don’t meet the needs of users, Maloo says.

“AI policies alone aren’t enough; organizations need to pair governance with usability,” he adds. “If approved AI tools don’t meet the pace of business, employees at every level, including leadership, will find their own solutions. Successful organizations will be those that make the secure path the easiest path.”

IT leaders can’t solve the problem with more governance, he notes. “Policies and restrictions slow shadow AI down, but they don’t stop it, especially when the people using it are senior enough to absorb the disciplinary risk,” Maloo adds. “What CIOs can do is focus on providing tools that grant users full access to the necessary systems and data, eliminating the need to choose between a capable but ungoverned tool and a safe but limited one.”

Speed over security

The TrustedTech data echoes a June report from employee monitoring software vendor Teramind, which found that more than two-thirds of C-level executives prioritize speed over security when using AI tools, notes Nik Kale, a principal engineer and product architect at Cisco, and member of the Coalition for Secure AI.

In addition, the Teramind report found that two-thirds of enterprise AI activity runs through personal accounts on platforms for which the company already owns licenses, he notes.

“People are paying for the governed version and using the ungoverned version of the same product, so the problem isn’t the tools,” he says. “The approved path is slower, buried in procurement, or disconnected from where the work actually happens, and speed wins every time under a deadline.”

The problem then isn’t with the AI tools, but with the friction involved, he says. “People aren’t going around the front door because the room is locked,” Kale adds. “They’re going around it because the front door is slower.”

In many cases, the use of shadow AI exposes a couple of shortcomings in enterprise processes, adds Matthew Scavetta, chief technology innovation officer at IT solutions provider Future Tech Enterprise.

Many organizations don’t do a good job of making employees aware of the AI tools available to them, he says, and many organizations don’t offer training on the sanctioned applications, which drives users to pick products they are familiar with.

“If you don’t solve problems for people quickly or make people aware of which tools they can use safely, they will find a workaround,” he adds. “AI tools are no different than anything else.”

Shadow AI use by executives puts IT leaders in an incredibly difficult position, he says.

“CIOs, in particular, are under more and more pressure each year to keep up with what’s possible as tech influencers keep preaching about the potential of these tools,” Scavetta says. “CEOs and board members are constantly getting swept up in the hype; meanwhile, there are more and more case studies coming out showing how little ROI some organizations have realized. It’s a never-ending game of balancing possible with practical.”

As AI use ratchets up, demand for data center capacity is higher than it’s ever been. But New York State is telling the industry: Not so fast.

New York Governor Kathy Hochul this week signed an Executive Order described as the “nation’s first moratorium” on new hyperscale data centers, massive factories that typically comprise thousands of servers devouring tens or hundreds of megawatts of power.

During this up to one year pause, the state will halt issuance of environmental permits for data centers as it develops a regulatory framework to protect ratepayers, the energy grid, the environment, and local communities.

Like other states, New York is seeing “unprecedented” demand for data center development that would ultimately require “massive amounts” of energy and water, Hochul noted. And community backlash seems to be accelerating at the same pace.

This is “a symptom of a bigger, nationwide issue,” said Matt Kimball, VP and principal analyst for data center technologies at Moor Insights & Strategy. “Compute demand is far outpacing the grid,” prompting state and local leaders to pause and figure out how to manage things more effectively.

Creating a blueprint for local development, community support

New York already requires data centers to pay more for energy, or to supply their own, to keep costs affordable for residents. Hochul also plans to pursue legislation that would repeal sales tax exemptions for massive data centers already existing in the state.

During the moratorium, New York will develop a “Generic Environmental Impact Statement” (GEIS) to assess the potential environmental impacts of data center construction and operation, including their water and energy demands and impact on air quality. Once it’s lifted, new data center projects will only be allowed to proceed if they strictly observe state, zoning, and other local approvals.

On a shorter 60-day timeline, the state will issue a Community Investment Framework (CIF) to provide guidance to local governments negotiating large-scale data center deals, and to ensure operators are investing in and partnering with host communities and workforces. This will set standardized expectations for projects and establish baseline thresholds for data center operators’ investment into local communities.

Notably, New York is proposing a contribution of $1 million per megawatt (MW) of anticipated utility demand per project. Thus, 50 megawatts of use would require data center operators to reinvest $50 million into their host community; 400 megawatts would require $400 million.

The framework will include ‘Good Neighbor Commitments’ around landscaping, design, and mitigation of noise and light pollution; labor commitments to give organized labor “a seat at the table” to determine wage standards, local hiring, and workforce development; and a community investment fund to support the host community’s “long-term economic vitality and quality of life.”

Data center operators, for instance, could provide direct financial support to host communities, or invest in public infrastructure, housing improvements, workforce development and training programs, or in broadband expansion.

“Having a published playbook for how to make this work across a state versus having to negotiate this on a county-by-county basis should be a win for everybody,” Moor’s Kimball noted.

Separately, New York is also considering establishing a fund that would require data centers to invest in the state’s aging grid infrastructure and support new clean energy procurement.

What enterprises and other states should be watching

Realistically, a data center buildout takes anywhere from 3 to 5 years from the point of site selection to turning on the switch for the first time, Kimball pointed out. The one-year moratorium doesn’t do too much for that.

What matters more is what New York does during that pause, he noted, for example, establishing a regulatory framework to re-price the cost of hyperscale deployment, determining costs for grid upgrades or “bring your own power” expectations, developing requirements for more formalized operator contributions to the local community, or considering the repeal of tax exemptions.

“And really, this subsidizing angle is the biggest,” said Kimball. States across the country have been subsidizing buildouts to get data center business for years. “This could signal the beginning of the end of those subsidies for many states.”

For enterprise IT leaders, the headline is the signal that power and permitting are now “first-order variables” for infrastructure strategies, right alongside cost and latency requirements, said Kimball.

So, if an enterprise’s cloud or co-location strategy or roadmap assumes hyperlocal capacity, that assumption now carries some risk. CIOs and IT leaders should therefore work with providers to gain more clarity on regional capacity.

The moratorium could result in some “border-hopping,” with enterprises hosting local servers in adjacent states like Pennsylvania, Connecticut, or New Jersey, but that’s not likely to be widespread, Kimball noted.

The realistic regional impact will be “more of a slow squeeze rather than a shock,” he said. This could result in tighter colocation availability and firmer pricing in the New York Metropolitan area over the next few years. Cloud providers may also steer new AI capacity to regions like Georgia, Ohio, Texas, and Utah, where power and permitting are more predictable.

An inflection point, but more trickle-down than direct impact

Indeed, noted Jeremy Roberts, senior director for research and content at Info-Tech Research Group, the moratorium is an “inflection point” and a “way to placate an increasingly angry public,”.

People don’t like the fact that, beyond the initial build, data centers don’t create many jobs, they take up a lot of space, they use a significant amount of power and resources, and they can be “noisy and smelly.”

However, the impact of the moratorium is likely going to be “macro” for everyday enterprises, as New York is specifically targeting hyperscale data centers.

“If you were planning on building a data center in New York and your name is not [Microsoft CEO] Satya Nadella, it’s probably not going to affect you,” said Roberts.

But the consequences of the move will certainly trickle down, for instance, with AI device or hardware purchases supplanting software acquisition. Roberts pointed to IBM’s history-making stock plunge this week, which the company attributed to enterprise buyers diverting IT budgets away from software and mainframes to stockpile AI hardware like servers and memory chips to get ahead of anticipated supply issues and price increases.

If enterprises plan to invest in anything that uses storage or CPUs, they will be paying more in the future, Roberts said. “It’s a symptom of a problem you’re going to feel.”

That said, constraints usually inspire innovation; if a hyperscaler can’t build a 50MW data center, it will likely find ways to string together smaller data centers or adapt in other ways. This could “percolate” across the industry, Roberts said. “People are endlessly creative.”

As AI use ratchets up, demand for data center capacity is higher than it’s ever been. But New York State is telling the industry: Not so fast.

New York Governor Kathy Hochul this week signed an Executive Order described as the “nation’s first moratorium” on new hyperscale data centers, massive factories that typically comprise thousands of servers devouring tens or hundreds of megawatts of power.

During this up to one year pause, the state will halt issuance of environmental permits for data centers as it develops a regulatory framework to protect ratepayers, the energy grid, the environment, and local communities.

Like other states, New York is seeing “unprecedented” demand for data center development that would ultimately require “massive amounts” of energy and water, Hochul noted. And community backlash seems to be accelerating at the same pace.

This is “a symptom of a bigger, nationwide issue,” said Matt Kimball, VP and principal analyst for data center technologies at Moor Insights & Strategy. “Compute demand is far outpacing the grid,” prompting state and local leaders to pause and figure out how to manage things more effectively.

Creating a blueprint for local development, community support

New York already requires data centers to pay more for energy, or to supply their own, to keep costs affordable for residents. Hochul also plans to pursue legislation that would repeal sales tax exemptions for massive data centers already existing in the state.

During the moratorium, New York will develop a “Generic Environmental Impact Statement” (GEIS) to assess the potential environmental impacts of data center construction and operation, including their water and energy demands and impact on air quality. Once it’s lifted, new data center projects will only be allowed to proceed if they strictly observe state, zoning, and other local approvals.

On a shorter 60-day timeline, the state will issue a Community Investment Framework (CIF) to provide guidance to local governments negotiating large-scale data center deals, and to ensure operators are investing in and partnering with host communities and workforces. This will set standardized expectations for projects and establish baseline thresholds for data center operators’ investment into local communities.

Notably, New York is proposing a contribution of $1 million per megawatt (MW) of anticipated utility demand per project. Thus, 50 megawatts of use would require data center operators to reinvest $50 million into their host community; 400 megawatts would require $400 million.

The framework will include ‘Good Neighbor Commitments’ around landscaping, design, and mitigation of noise and light pollution; labor commitments to give organized labor “a seat at the table” to determine wage standards, local hiring, and workforce development; and a community investment fund to support the host community’s “long-term economic vitality and quality of life.”

Data center operators, for instance, could provide direct financial support to host communities, or invest in public infrastructure, housing improvements, workforce development and training programs, or in broadband expansion.

“Having a published playbook for how to make this work across a state versus having to negotiate this on a county-by-county basis should be a win for everybody,” Moor’s Kimball noted.

Separately, New York is also considering establishing a fund that would require data centers to invest in the state’s aging grid infrastructure and support new clean energy procurement.

What enterprises and other states should be watching

Realistically, a data center buildout takes anywhere from 3 to 5 years from the point of site selection to turning on the switch for the first time, Kimball pointed out. The one-year moratorium doesn’t do too much for that.

What matters more is what New York does during that pause, he noted, for example, establishing a regulatory framework to re-price the cost of hyperscale deployment, determining costs for grid upgrades or “bring your own power” expectations, developing requirements for more formalized operator contributions to the local community, or considering the repeal of tax exemptions.

“And really, this subsidizing angle is the biggest,” said Kimball. States across the country have been subsidizing buildouts to get data center business for years. “This could signal the beginning of the end of those subsidies for many states.”

For enterprise IT leaders, the headline is the signal that power and permitting are now “first-order variables” for infrastructure strategies, right alongside cost and latency requirements, said Kimball.

So, if an enterprise’s cloud or co-location strategy or roadmap assumes hyperlocal capacity, that assumption now carries some risk. CIOs and IT leaders should therefore work with providers to gain more clarity on regional capacity.

The moratorium could result in some “border-hopping,” with enterprises hosting local servers in adjacent states like Pennsylvania, Connecticut, or New Jersey, but that’s not likely to be widespread, Kimball noted.

The realistic regional impact will be “more of a slow squeeze rather than a shock,” he said. This could result in tighter colocation availability and firmer pricing in the New York Metropolitan area over the next few years. Cloud providers may also steer new AI capacity to regions like Georgia, Ohio, Texas, and Utah, where power and permitting are more predictable.

An inflection point, but more trickle-down than direct impact

Indeed, noted Jeremy Roberts, senior director for research and content at Info-Tech Research Group, the moratorium is an “inflection point” and a “way to placate an increasingly angry public,”.

People don’t like the fact that, beyond the initial build, data centers don’t create many jobs, they take up a lot of space, they use a significant amount of power and resources, and they can be “noisy and smelly.”

However, the impact of the moratorium is likely going to be “macro” for everyday enterprises, as New York is specifically targeting hyperscale data centers.

“If you were planning on building a data center in New York and your name is not [Microsoft CEO] Satya Nadella, it’s probably not going to affect you,” said Roberts.

But the consequences of the move will certainly trickle down, for instance, with AI device or hardware purchases supplanting software acquisition. Roberts pointed to IBM’s history-making stock plunge this week, which the company attributed to enterprise buyers diverting IT budgets away from software and mainframes to stockpile AI hardware like servers and memory chips to get ahead of anticipated supply issues and price increases.

If enterprises plan to invest in anything that uses storage or CPUs, they will be paying more in the future, Roberts said. “It’s a symptom of a problem you’re going to feel.”

That said, constraints usually inspire innovation; if a hyperscaler can’t build a 50MW data center, it will likely find ways to string together smaller data centers or adapt in other ways. This could “percolate” across the industry, Roberts said. “People are endlessly creative.”

This article originally appeared on NetworkWorld.

Thinking Machines Lab, the San Francisco startup founded by former OpenAI CTO Mira Murati, has released Inkling, its first general-purpose AI model. The launch adds another US-developed entrant to an open-weight market where Chinese developers produce several leading coding and reasoning models.

Inkling uses a mixture-of-experts architecture with 975 billion total parameters, of which 41 billion are active during processing. It supports a context window of up to 1 million tokens and was pretrained on 45 trillion tokens spanning text, images, audio, and video. Thinking Machines said it also trained the model for coding, tool use, and multimodal tasks.

The release follows the October 2025 launch of Tinker, Thinking Machines’ first product and an API-based platform for customizing AI models. Developers can fine-tune Inkling through the platform.

In a June 2026 assessment, AI model routing platform OpenRouter highlighted DeepSeek V4 Flash, GLM 5.2, MiniMax M3, and Nvidia Nemotron 3 Ultra as four notable open-weight models. Nemotron was the only US-developed model in the group.

Performance and developer access

Thinking Machines Lab’s benchmark table shows mixed results. Inkling scored 77.6% on SWE-Bench Verified, behind DeepSeek V4 Pro and GLM 5.2 but ahead of Nvidia Nemotron 3 Ultra. It also recorded 74.1% on MCP Atlas, 77.1% on BrowseComp with context management, and 79.8% on IFBench.

Thinking Machines said Inkling’s result used a bash-only harness, while the comparison figures were reported by the competing models’ developers.

The model includes a reasoning-effort setting that developers can adjust from 0.2 to 0.99. Thinking Machines said the setting allows users to balance performance against the number of generated tokens. In the company’s testing, Inkling matched Nemotron 3 Ultra’s Terminal Bench 2.1 score while generating about one-third as many tokens.

Developers can fine-tune Inkling through Tinker using context lengths of 64,000 or 256,000 tokens and test it through the Inkling Playground. The model is available through APIs from Together AI, Fireworks, Modal, Databricks, and Baseten. It is also supported by inference software, including SGLang, vLLM, TokenSpeed, llama.cpp, and Hugging Face Transformers.

Inkling’s full weights are available on Hugging Face as the original checkpoint and as a quantized NVFP4 checkpoint. Thinking Machines also previewed Inkling-Small, which has 276 billion total parameters and 12 billion active parameters. The company said it would release the smaller model’s full weights after completing testing.

Enterprise impact

Inkling’s differentiation lies in its open weights, multimodal capabilities, controllable reasoning, and integration with Tinker, rather than benchmark leadership, according to Biswajeet Mahapatra, principal analyst at Forrester.

“Enterprises are most likely to benefit in workloads where domain adaptation matters more than generic model performance, including knowledge-intensive copilots, multimodal customer service, document understanding, operational workflow automation, and agentic tasks that require organization-specific data, policies, and processes,” Mahapatra said.  

Inkling’s US origin could also influence adoption among Western enterprises, according to Pareekh Jain, CEO of Pareekh Consulting. He said many Western organizations face regulatory or procurement barriers when considering Chinese-developed AI models.

“Inkling gives those organizations a US-developed open-weight option that they can deploy on their own infrastructure,” Jain said.

However, the benefits will need to be weighed against the cost of deploying the full model.

Running Inkling on private infrastructure requires a GPU cluster with at least 2 TB of aggregated VRAM for the BF16 checkpoint, according to the model card. Thinking Machines lists configurations of eight Nvidia B300 GPUs or 16 H200 GPUs. A quantized NVFP4 checkpoint lowers the requirement to at least 600 GB and can run on four B300 GPUs or eight H200 GPUs.

“Because Inkling is a massive model with 975 billion total parameters, running the full model still requires significant GPU infrastructure, making closed-model APIs more economical for many organizations,” Jain said.

Jain said Inkling-Small may be a more feasible option for many enterprises because it could reduce infrastructure costs and latency while retaining useful performance across key workloads.

Safety and governance

Thinking Machines said it trained Inkling for calibration, instruction following, and resistance to censorship. The company said the model showed “strong patterns of censorship non-compliance” when evaluated by Cognition on its Propaganda and Censorship Eval.

Inkling scored 98.6% on StrongREJECT, which Thinking Machines described as a test of whether models refuse unambiguous harmful requests.

The model’s safety behavior should be retested after an enterprise customizes it, according to Jain. “Model fine-tuning can weaken safety filters, so companies should retest safety after customizing the model rather than assuming it stays safe,” Jain said.

He added that self-hosted and modified versions could diverge from Thinking Machines’ official model over time without receiving automatic updates.

“CIOs need to ensure every AI agent action is logged, auditable, and governed by human approval for high-risk tasks,” Jain said.

The article originally appeared on InfoWorld.

Thinking Machines Lab, the San Francisco startup founded by former OpenAI CTO Mira Murati, has released Inkling, its first general-purpose AI model. The launch adds another US-developed entrant to an open-weight market where Chinese developers produce several leading coding and reasoning models.

Inkling uses a mixture-of-experts architecture with 975 billion total parameters, of which 41 billion are active during processing. It supports a context window of up to 1 million tokens and was pretrained on 45 trillion tokens spanning text, images, audio, and video. Thinking Machines said it also trained the model for coding, tool use, and multimodal tasks.

The release follows the October 2025 launch of Tinker, Thinking Machines’ first product and an API-based platform for customizing AI models. Developers can fine-tune Inkling through the platform.

In a June 2026 assessment, AI model routing platform OpenRouter highlighted DeepSeek V4 Flash, GLM 5.2, MiniMax M3, and Nvidia Nemotron 3 Ultra as four notable open-weight models. Nemotron was the only US-developed model in the group.

Performance and developer access

Thinking Machines Lab’s benchmark table shows mixed results. Inkling scored 77.6% on SWE-Bench Verified, behind DeepSeek V4 Pro and GLM 5.2 but ahead of Nvidia Nemotron 3 Ultra. It also recorded 74.1% on MCP Atlas, 77.1% on BrowseComp with context management, and 79.8% on IFBench.

Thinking Machines said Inkling’s result used a bash-only harness, while the comparison figures were reported by the competing models’ developers.

The model includes a reasoning-effort setting that developers can adjust from 0.2 to 0.99. Thinking Machines said the setting allows users to balance performance against the number of generated tokens. In the company’s testing, Inkling matched Nemotron 3 Ultra’s Terminal Bench 2.1 score while generating about one-third as many tokens.

Developers can fine-tune Inkling through Tinker using context lengths of 64,000 or 256,000 tokens and test it through the Inkling Playground. The model is available through APIs from Together AI, Fireworks, Modal, Databricks, and Baseten. It is also supported by inference software, including SGLang, vLLM, TokenSpeed, llama.cpp, and Hugging Face Transformers.

Inkling’s full weights are available on Hugging Face as the original checkpoint and as a quantized NVFP4 checkpoint. Thinking Machines also previewed Inkling-Small, which has 276 billion total parameters and 12 billion active parameters. The company said it would release the smaller model’s full weights after completing testing.

Enterprise impact

Inkling’s differentiation lies in its open weights, multimodal capabilities, controllable reasoning, and integration with Tinker, rather than benchmark leadership, according to Biswajeet Mahapatra, principal analyst at Forrester.

“Enterprises are most likely to benefit in workloads where domain adaptation matters more than generic model performance, including knowledge-intensive copilots, multimodal customer service, document understanding, operational workflow automation, and agentic tasks that require organization-specific data, policies, and processes,” Mahapatra said.  

Inkling’s US origin could also influence adoption among Western enterprises, according to Pareekh Jain, CEO of Pareekh Consulting. He said many Western organizations face regulatory or procurement barriers when considering Chinese-developed AI models.

“Inkling gives those organizations a US-developed open-weight option that they can deploy on their own infrastructure,” Jain said.

However, the benefits will need to be weighed against the cost of deploying the full model.

Running Inkling on private infrastructure requires a GPU cluster with at least 2 TB of aggregated VRAM for the BF16 checkpoint, according to the model card. Thinking Machines lists configurations of eight Nvidia B300 GPUs or 16 H200 GPUs. A quantized NVFP4 checkpoint lowers the requirement to at least 600 GB and can run on four B300 GPUs or eight H200 GPUs.

“Because Inkling is a massive model with 975 billion total parameters, running the full model still requires significant GPU infrastructure, making closed-model APIs more economical for many organizations,” Jain said.

Jain said Inkling-Small may be a more feasible option for many enterprises because it could reduce infrastructure costs and latency while retaining useful performance across key workloads.

Safety and governance

Thinking Machines said it trained Inkling for calibration, instruction following, and resistance to censorship. The company said the model showed “strong patterns of censorship non-compliance” when evaluated by Cognition on its Propaganda and Censorship Eval.

Inkling scored 98.6% on StrongREJECT, which Thinking Machines described as a test of whether models refuse unambiguous harmful requests.

The model’s safety behavior should be retested after an enterprise customizes it, according to Jain. “Model fine-tuning can weaken safety filters, so companies should retest safety after customizing the model rather than assuming it stays safe,” Jain said.

He added that self-hosted and modified versions could diverge from Thinking Machines’ official model over time without receiving automatic updates.

“CIOs need to ensure every AI agent action is logged, auditable, and governed by human approval for high-risk tasks,” Jain said.

I have sat in a lot of ERP training sessions over the years. Some were excellent. Most were not. And the ones that failed share a pattern I have come to recognize almost immediately: a vendor trainer at the front of the room, working through the same slide deck they use for every client, at the same pace, with the same examples, regardless of who is sitting in the chairs.

In one room, you might have a warehouse supervisor who has never used enterprise software, a finance manager with 20 years of system experience and a department coordinator somewhere in between. The vendor trainer covers the same material with all of them. Everyone gets a certificate at the end. Almost nobody is prepared to do their job in the new system when go-live arrives.

I want to be clear about something before I go further. In my previous CIO article, I wrote about why organizations should stop blaming their ERP vendor when implementations fail. That argument still stands. But the training problem is a choice the organization makes. Most organizations spend less than 5% of their total ERP project budget on training and then hand that underfunded responsibility to the vendor. The vendor delivers what they were contracted to deliver. The gap between what got delivered and what the organization actually needed is not the vendor’s fault. It is a decision the organization made, often without fully understanding its consequences.

After 25 years of leading enterprise software implementations and based on the doctoral research I conducted studying ERP implementations in small businesses, I am convinced that the organizations that get training right share one thing in common: they build the expertise internally rather than importing it.

Why vendor training falls short

Vendor trainers know the software. That is not in question. What they do not know is your business: your processes, your workflows, your data, your terminology, your culture and the specific ways your organization will use the system once it is live.

That gap matters more than most organizations realize. Research consistently shows that inadequate training is one of the primary drivers of ERP implementation failure, not because training did not happen, but because the training that happened did not connect the system to the work. Employees left those sessions knowing what buttons to click without understanding why those buttons mattered to their specific job.

Generic training has a structural problem: it is optimized for coverage, not relevance. The goal is to ensure every employee has seen every feature. The result is that employees spend significant time learning functionality that does not apply to their role, while the functionality that does apply gets the same shallow treatment as everything else.

A finance manager sitting through a session on shop floor production tracking is not learning anything she will use. A warehouse supervisor learning about financial journal entries is in the same position. Both leave the session technically trained. Neither leaves prepared.

There is also a timing problem. Vendor training typically happens in a compressed window before go-live, delivered as a series of sessions rather than a progression. Research on learning retention suggests that training delivered weeks before it is needed, without reinforcement or practice, is largely forgotten by the time employees need to apply it. The result is a go-live day where everyone attended training and almost nobody feels ready.

What internal expertise looks like in practice

In my doctoral research, I interviewed six IT managers from small businesses who had each led successful ERP implementations. Five of the six identified role-based, department-specific training as essential to their outcome. What distinguished their approach was not that they spent more on training. It was that they built the training capability inside the organization rather than contracting it out.

The approach that worked most consistently was identifying one person from each affected department early in the implementation, before configuration even began. That person became the departmental expert: involved in design decisions, consulted on how their team’s processes mapped to the new system and ultimately responsible for either delivering training to their colleagues or co-leading it alongside a formal trainer.

This is sometimes called a super user model, and the research supports its effectiveness. But what I observed in the implementations that worked goes beyond the mechanics of the model. The departmental expert brought something a vendor trainer cannot: credibility. When the warehouse supervisor learns the receiving process from someone who has worked in that warehouse, who understands the exceptions and the edge cases and the way things truly flow on a busy day, the training resonates in a way that a generic session never can.

There is also an ownership dimension that is easy to underestimate. Peer-based training led by internal super users helps employees connect system steps to their daily responsibilities in ways that outsider-led training rarely achieves. The departmental expert has skin in the game. They are going to use this system too. That shared stake changes the dynamic in the training room and sustains the support relationship long after the formal training is over.

I have seen this play out in both directions. In implementations where the organization invested in building internal expertise early, go-live day was hard but manageable. Questions went to the departmental expert, who could answer them in the language of the department. Issues surfaced quickly because someone in each area was watching for them. Adoption stabilized faster because the support was embedded in the team rather than accessible only through a help desk ticket.

In implementations where training was handed entirely to the vendor, the pattern was different. Go-live revealed gaps that training had not covered. The vendor’s support engagement was winding down. The organization had no internal expertise to draw on. Employees reverted to workarounds. The system went live but never fully took hold.

How to build internal training capability before go-live

The organizations that got this right did not wait until the training phase to think about training. They started building internal expertise at the beginning of the project. Here is what that looked like in practice.

Identify departmental experts early

Select one person from each affected department before configuration begins. Choose people who are respected by their colleagues, have a solid understanding of their department’s processes and are willing to invest extra time in the project. This is not a small ask. Make sure they and their managers understand the commitment and that the contribution is recognized.

Involve them in the implementation, not just the training

The departmental expert should participate in process design sessions, configuration reviews and user acceptance testing. By the time training begins, they should understand the system deeply enough to explain not just how it works but why specific decisions were made. That context is what makes internal training credible.

Design training around the job, not the system

Training content should be organized around realistic work scenarios specific to each department, not around the system’s feature set. The finance team trains on how to process their transactions in the new system. The warehouse team trains on how to manage their receipts and inventory. Connect every step to the work employees actually do.

Plan for post-go-live support, not just pre-go-live training

The weeks immediately after go-live are when training becomes real and when the gaps in pre-go-live preparation surface. The departmental expert should have a defined support role in that period: available to their colleagues, connected to the project team and empowered to escalate issues that need resolution. This is not a minor detail. It is where the investment in internal expertise pays its most important dividends.

None of this requires a large budget or a dedicated training function. It requires early decisions about who will own the training relationship inside each department and the organizational commitment to support those people through the implementation, rather than treating training as a final phase activity.

The vendor knows the software. That knowledge is valuable and should not be wasted. But your people know your business, your processes and the way work flows on any given day. The question is not whether to use your vendor’s expertise. It is whether you are also building the internal expertise that turns a trained workforce into a prepared one. The organization that does both will not just go live. It will thrive.

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

In many teams, dependency security still happens after the most important trust decision has already been made. A package is added, the lockfile changes, the feature moves forward, and only later does the pipeline ask whether the application should have trusted that code in the first place.

That workflow made sense when dependency security was mostly viewed as a compliance check. Run a scanner. Produce a report. Fail the build if the risk crosses a threshold. Let someone decide what to do next.

But the modern Node.js ecosystem has changed. The risk no longer begins in CI. It begins earlier, at the moment a developer decides to trust a package.

That is why the next phase of Node.js security cannot be limited to better pipeline enforcement. It has to move closer to the developer workflow, before dependencies become part of the application, before a pull request becomes someone else’s problem, and before a build log becomes the first moment anyone realizes that something important has changed.

Every install is a trust decision

The npm ecosystem is built on trust at an enormous scale. Every install is a trust decision. Every transitive dependency extends that decision to maintainers, packages, scripts, release pipelines, and infrastructure the application team may never inspect directly. This model gave JavaScript its incredible velocity. It also created one of its deepest security weaknesses.

Recent npm supply chain incidents show why this matters. In March 2026, malicious Axios versions were published to npm through a compromised maintainer account. Microsoft later described how those packages attempted to retrieve a second-stage payload during installation. In May 2026, TanStack published a postmortem explaining that 84 malicious versions across 42 npm packages were published through a legitimate release pipeline after an attacker abused GitHub Actions behavior and runner trust boundaries. Security researchers also reported broader Mini Shai-Hulud activity across the npm ecosystem in May, including hundreds of malicious package versions published in a short period.

Not every one of these incidents is a traditional CVE. Some are malicious package compromises. Some involve CI/CD credential theft. Some involve maintainer or pipeline compromise. But they all point to the same larger issue: dependency risk is now part of everyday software engineering, not something that can be pushed entirely to a downstream security process.

The problem is not the scanner. It is the handoff.

Ubiquitous dependency risk changes what developers need from security tooling.

The problem is not that teams lack scanners. Many organizations already run security checks in CI. The problem is that the output of those checks often arrives too late and speaks the wrong language for the person expected to act on it.

A pull request fails. A long vulnerability report appears. The report may be technically accurate. It may contain the right advisory IDs, affected versions, dependency paths, severity labels, and references. But the developer still has to comb through the output and reconstruct the actual engineering decision from the evidence provided.

That reconstruction is rarely simple. The developer has to understand which package introduced the issue, whether the vulnerable dependency is direct or transitive, whether the fix is actually within the application team’s control, and whether the recommended version is safe to adopt. They also have to determine whether the dependency is used in production or only during development, whether the update might break the application, and whether the fix belongs in the current pull request or requires separate engineering work.

That uncertainty is where security work often slows. The scanner has detected risk, but the developer has not been given a clear path from detection to decision.

Security needs to move closer to engineering judgment

This is not a criticism of scanning. Scanning is necessary. CI enforcement is necessary. Centralized security platforms are necessary. But they are not sufficient, because they often operate after the trust decision has already been made.

The real architectural question is this: where should dependency security live in the software development life cycle?

If it lives only in CI, it becomes an interruption. If it lives only in dashboards, it becomes someone else’s queue. If it lives only in periodic audits, it becomes a backlog. But if it lives at the moment a dependency is introduced, upgraded, or reviewed, it becomes part of engineering judgment.

That shift matters because modern JavaScript development is becoming faster than human review can comfortably handle. Developers no longer add dependencies only by reading documentation and choosing libraries manually. AI coding assistants can suggest packages, generate install commands, modify package files, and rewrite code around third-party APIs. Agentic development workflows can make dependency changes as part of broader automated refactors.

AI makes the trust boundary harder to see

That acceleration is useful. It also changes the risk model.

When a human developer adds one package, the team can review the decision. When a coding agent modifies several dependencies as part of a larger task, the trust boundary becomes harder to see. The package file changes, the lockfile changes, the application still runs, and the pull request may look like a normal feature update. But the real security question may be hidden inside the dependency graph.

This is where Node.js teams need a different mental model.

Dependency adoption should not be treated as a small implementation detail. It should be treated as an architectural decision with security consequences. A new package is not just code reuse. It is a new trust relationship.

That does not mean developers should stop using packages. The npm ecosystem exists because reuse works. Most teams cannot and should not build everything themselves. But convenience should not erase visibility. If a dependency becomes part of the application, the team should understand what was added, what changed in the lockfile, what risk comes with it, and what action is available if something is wrong.

Developers need confidence, not just reports

The same applies to remediation. Developers do not want a wall of vulnerability text. They want confidence. They want to know what action reduces risk, what version should be targeted, whether the change is safe, and whether the fix is actually under their control. A vulnerability report that leaves the developer uncertain may satisfy a process requirement, but it does not necessarily improve the speed or quality of remediation.

That is the gap many teams feel today. Security tools are often very good at saying, “There is a problem.” They are less consistent at helping the developer answer, “What should I do next?”

This is the broader problem I have been exploring through CVE Lite CLI, now an OWASP project. The point is not that one command-line tool solves Node.js security. It does not. The larger idea is that dependency security has to move closer to the developer’s moment of decision. A useful developer-side security workflow should not merely report that risk exists. It should help the engineer understand whether the issue is in their control, what change is available, and whether the fix actually reduces risk.

The future is decision support, not just detection

That distinction is important. The future of Node.js security is not just more detection. It is better decision support.

Security teams still need policy. Enterprises still need dashboards. CI still needs gates. But developers need something more immediate: a way to reason about dependency risk while the code is still fresh in their mind. That is where the ecosystem has to evolve.

We already accept that testing belongs close to development. We accept that linting belongs close to development. We accept that formatting, type checking, and build validation belong close to development. Dependency security should follow the same path. It should not be treated as a mysterious report that appears at the end of the process. It should become part of the normal rhythm of engineering work.

Before adding a package, developers should understand what trust relationship is being introduced. Before accepting an AI-generated dependency change, they should inspect what entered the graph. Before merging a pull request, teams should understand whether a vulnerability is direct, transitive, fixable, or blocked by another package. And before treating a CI failure as noise, organizations should ask whether the workflow is giving developers enough information to act confidently.

Node.js security will be won, or lost, before CI runs

The Node.js ecosystem will not become safer by slowing down all development. That is unrealistic. It will become safer when security work is placed where developers can actually use it.

The next generation of Node.js security will be won or lost before CI runs.

It will be won when dependency decisions are still small enough to understand, fresh enough to review, and close enough to the developer for action to feel natural.

That is the shift teams need to make now. Not from insecure to secure in one step, but from late detection to earlier judgment. From vulnerability reports to engineering decisions. From trusting packages by habit to understanding trust as part of software design.

A year ago, most enterprise AI systems generated recommendations. Today, AI systems are approving transactions, routing shipments, updating records, interacting with customers, and triggering downstream software actions with little or no human involvement.

For CIOs, that shift changes the central governance question. The challenge is no longer simply whether an AI model is accurate. It is whether the organization can explain, audit, and defend the decisions the system makes.

When an AI assistant suggests a meeting time or summarizes a document, mistakes are inconvenient. When an autonomous AI system issues a refund, reprices a product, modifies a customer record, or initiates a financial transaction, mistakes carry operational, legal, and reputational consequences.

When those consequences arrive, “the model decided” is not an acceptable explanation.

This is the accountability gap emerging at the center of enterprise AI adoption. Organizations are deploying increasingly autonomous systems while relying on technology that often provides little visibility into how decisions are made. The result is a growing mismatch between the level of authority organizations grant AI and their ability to understand or justify its actions.

Black-box AI may have been acceptable when AI primarily generated predictions. It becomes far more problematic when AI begins taking actions on behalf of the business.

The lesson software already learned

Fortunately, the technology industry has faced a similar challenge before.

As enterprise software systems became more distributed and complex, troubleshooting failures became increasingly difficult. Engineers could no longer rely on intuition to understand what happened when something broke. The solution was observability: the practice of instrumenting systems so their internal state could be understood through logs, metrics, traces, and monitoring.

The goal was not to predict every possible failure in advance. It was to create enough visibility that teams could reconstruct what happened after the fact and identify the root cause.

Enterprise AI now requires a similar discipline.

But AI observability must go beyond traditional software observability. It is not enough to know what action occurred. Organizations also need visibility into why the system believed that action was appropriate.

An auditable AI system should be able to answer questions such as:

• What information did the system rely on?
• Which tools or data sources did it access?
• What alternatives did it consider?
• What verification steps were performed?
• How confident was it in its conclusion?
• What events led to the final action?

These questions are rapidly becoming essential operational requirements rather than technical nice-to-haves.

Why visibility matters more as AI gains autonomy

As AI systems become more autonomous, failures become harder to detect and diagnose.

A human reviewing a single AI-generated recommendation can often spot obvious mistakes. A network of AI agents coordinating multiple tasks across business processes presents a different challenge. Decisions can build upon one another. A flawed assumption early in a workflow can propagate through subsequent actions, creating confident but incorrect outcomes.

The challenge is rarely identifying that something went wrong. Eventually, an error surfaces through a customer complaint, a failed transaction, an audit finding, or an operational disruption.

The challenge is determining why it happened.

Which information influenced the decision? Which tools were consulted? Which safeguards worked as intended? Which ones failed?

Without visibility into the reasoning process, troubleshooting autonomous AI workflows can become significantly more difficult than debugging traditional software systems.

For CIOs responsible for enterprise reliability, compliance, and governance, that lack of visibility creates unacceptable operational risk.

Moving toward glass-box AI

The answer is not to slow AI adoption. The answer is to make AI systems observable.

Increasingly, organizations are seeking AI systems that behave more like a glass box than a black box. The objective is not to expose every parameter inside a neural network. Rather, it is to provide a clear, auditable record of how decisions were reached and why actions were taken.

The most promising approaches share two common characteristics.

The first is verification. Instead of treating a single model’s output as ground truth, systems incorporate independent validation steps before actions are executed. Multiple agents, external checks, business rules, or verification workflows help identify errors before they become operational incidents.

The second is explainability. Effective systems maintain a decision trail that captures inputs, intermediate reasoning steps, tool usage, verification activities, and outputs in a form that human reviewers can understand.

Together, these capabilities create something that has long been expected of human decision-makers but is often missing from AI systems: the ability to show your work.

The regulatory and business reality

The push toward AI observability is not being driven solely by technologists.

Regulators increasingly expect organizations to demonstrate oversight of automated decision-making systems. Emerging AI governance frameworks place growing emphasis on transparency, traceability, accountability, and human oversight.

Customers are moving in the same direction. Whether the decision involves pricing, service, eligibility, or support, people increasingly want the ability to understand and challenge outcomes that affect them.

The result is a convergence of operational, regulatory, and market pressures around a single requirement: organizations must be able to explain what their AI systems are doing.

Three questions every CIO should ask

Before deploying autonomous AI systems, technology leaders should be able to answer three basic questions:

1. Can we reconstruct the complete decision path that led to an action?
2. Can we verify critical outputs before actions are executed?
3. Can a human auditor understand why the decision occurred?

If the answer to any of those questions is no, the organization may be granting more authority to AI than it can responsibly govern.

Accountability will become a competitive advantage

The organizations that succeed with autonomous AI will not necessarily be those that automate the most processes or deploy the largest models. They will be the organizations that combine automation with accountability.

Black-box systems made sense when AI primarily generated predictions. As AI increasingly acts on behalf of businesses, customers, and employees, visibility becomes essential.

The future of enterprise AI will belong not to systems that merely act, but to systems whose actions can be examined, understood, and trusted.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

It’s been several years since generative AI and large language models (LLMs) took the world by storm. LLMs surpassed earlier natural-language systems at generating text, while diffusion models enabled generating images, music, and videos.

These generative AI models work well in the digital world, but on their own, they have limited capabilities to comprehend the three-dimensional physical world and other spaces. This includes the objects occupying an area, how they relate to each other, tracking movement, and answering complex questions requiring an understanding of dimensions, distances, motion, and collisions.

Spatial intelligence is an AI capability that allows models to reason about three-dimensional space. These models can generate 3D scenes of the world and other spaces. This content can then be displayed through traditional renderers, game engines, or AR/VR systems that use spatial computing techniques. But it’s the spatial intelligence model’s ability to connect natural language with 3D models that has the most applications in robotics, manufacturing, construction, and other physical environments.   

Dr. Fei-Fei Li, often called the godmother of AI, published a manifesto on how spatial intelligence is AI’s next frontier, contrasting it with LLMs. “While current state-of-the-art AI can excel at reading, writing, research, and pattern recognition in data, these same models bear fundamental limitations when representing or interacting with the physical world,” wrote Dr. Li. “Our view of the world is holistic—not just what we’re looking at, but how everything relates spatially, what it means, and why it matters. Understanding this through imagination, reasoning, creation, and interaction—not just descriptions—is the power of spatial intelligence.”

The concept of spatial intelligence isn’t new and was described in Howard Gardner’s book, Frames of Mind, in 1983. Recent breakthroughs, including the launch of World Labs’ Marble and its $1 billion funding round, and competing approaches from Google’s Genie 3 and Nvidia Cosmos, should put spatial intelligence and world models on more R&D road maps.

What are spatial intelligence models?

It’s important to develop AI literacy and understand the terminology and concepts related to the physical world and 3D AI technologies: 

• Spatial intelligence encompasses specialized approaches such as geospatial models for mapping the physical world and building information modeling (BIM) for modeling physical structures. It also extends to generative 3D, robotics, and physical reasoning applications.
• World models are a class of neural network architectures and are currently a prominent approach to building spatial intelligence.
• Digital twins are live, virtual replicas of physical assets that combine 3D models with real-time sensor data. Spatial intelligence, an emerging capability of digital twins, adds natural-language prompting, generative scenario exploration, and physics-aware reasoning.
• Spatial computing refers to digital content anchored in and interacting with physical space, sensed and rendered in three dimensions and delivered through AR/VR and mixed-reality systems.

“Spatial intelligence models go beyond pixels to understand the 3D structure of the world—how objects are positioned, how they move, and how they interact,” says David Fattal, founder and CTO at Leia. “This enables applications like more realistic video generation, spatial computing interfaces, and AI systems that can reason about physical environments. As real-world 3D data becomes more available, these models will become foundational to the next generation of visual AI.”

Monitoring the built environment

To better understand spatial intelligence, let’s consider physical infrastructure such as bridges and buildings. The American Society of Civil Engineers estimates a $9.1 trillion investment is needed from 2024 through 2033 to achieve a state of good repair. When maintenance and monitoring lag, it can lead to major failures such as the 2022 collapse of the Fern Hollow Bridge in Pittsburgh.

Spatial intelligence and the development of digital twins may help identify issues earlier and prioritize where investments are needed. “Spatial intelligence models serve as the 4D digital blueprints for our built environment, allowing us to visualize and predict the complex interactions between aging assets and the shifting ground beneath them,” says Patrick Cozzi, chief platform officer at Bentley Systems. “By synthesizing disparate geospatial data into a living digital twin, these models provide the foresight necessary to mitigate the hidden risks of structural fatigue and subsurface instability.”

There’s a significant challenge in bridge health monitoring and transitioning from manual, infrequent structural inspections to leveraging sensors, digital twins, and spatial intelligence. Cozzi adds, “This integration of continuous field data moves beyond static documentation, empowering agencies to evolve from reactive repairs to proactive, resilient asset management that safeguards the long-term integrity of our most critical public systems.”

Avoiding collisions

Bridges are largely static, but the real world is increasingly being occupied by autonomous systems such as self-driving cars, robots, and drones. And where there are moving systems, there is a risk of collisions.

“Spatial intelligence models are AI systems that reason about the physical world by combining vision, sensor data, and contextual cues to understand space, motion, and object relationships,” says Sudeep George, CTO at iMerit. “The value of spatial intelligence models lies not just in perceiving an environment, but in enabling machines to act within it safely and in real time. That is especially important in robotics and autonomous systems, where decisions must be made in complex, multimodal, fast-changing settings.”

To see one example, this tutorial for simulating robotic environments combines Nvidia Isaac Sim, an open source robotics reference framework, with spatial intelligence in Marble from World Labs. 

Today’s collision detection systems, such as those used in autonomous vehicles, typically rely on modules for sensing, perception, planning, and control. Spatial intelligence models may offer improvements by assessing the collision risks of unidentified objects or by tracking objects that move out of sensor view. For example, Waymo’s World Model, built on Genie 3, is a simulator that generates complex weather conditions and other critical safety events.

For an out-of-this-world example, James Urquhart, field CTO and technology evangelist at Kamiwaza, has delivered several examples of spatial intelligence applications, including one for satellite collision detection and conflict analysis. Urquhart says, “Models that specialize in these types of data sets, as well as the physics and geography of the real world, enable faster and more accurate decision-making for tasks that depend on them.”

Applying spatial intelligence

Recent spatial intelligence announcements include creating 3D worlds from image or text prompts with Marble and simulating water physics, lighting, weather, and animal behavior with Genie 3. But difficulties remain in bringing spatial intelligence to physical-world use cases.

“Spatial intelligence and world models are laying the groundwork for future AI agents that will be able to interact in and with our physical world,” says Jason Corso, cofounder and chief scientist at Voxel51. “These models are significantly more challenging to develop and test, largely because the data underlying their development is complex, and it’s hard to handle all of the combinatorics involved in the physical world.”

In addition to learning the models and prototyping with them, development and data leaders need to review the data assets that will feed spatial intelligence models. “Spatial intelligence models translate location signals into a structured understanding of the real world, but they’re only as reliable as the data beneath them,” says Dan Adams, executive vice president and general manager of Enrich at Precisely. “The real unlock isn’t the model—it’s the reference layer with persistent identifiers, confidence metadata, and source lineage that lets AI reason about places, not just match strings.”

Even once applications are developed, there will be infrastructure challenges in deploying them at the edge. Ali Kayyam, principal research scientist at BrainChip, says, “The key to unlocking spatial intelligence at scale is having the low-power, event-driven hardware that can run it at the sensor in real time where it matters most.”

Where to get started

My suggestions for developers looking to get hands-on with spatial intelligence and world models:

• To try out Marble, review their API documentation and case studies, and then experiment with a developer-focused React application.
• Review the Nvidia Cosmos developer hub, documentation, and cookbook of case studies and learning paths.
• You can get an overview of Genie 3, but access is currently restricted through Project Genie, which requires a Google AI Ultra subscription.

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.

It’s been several years since generative AI and large language models (LLMs) took the world by storm. LLMs surpassed earlier natural-language systems at generating text, while diffusion models enabled generating images, music, and videos.

These generative AI models work well in the digital world, but on their own, they have limited capabilities to comprehend the three-dimensional physical world and other spaces. This includes the objects occupying an area, how they relate to each other, tracking movement, and answering complex questions requiring an understanding of dimensions, distances, motion, and collisions.

Spatial intelligence is an AI capability that allows models to reason about three-dimensional space. These models can generate 3D scenes of the world and other spaces. This content can then be displayed through traditional renderers, game engines, or AR/VR systems that use spatial computing techniques. But it’s the spatial intelligence model’s ability to connect natural language with 3D models that has the most applications in robotics, manufacturing, construction, and other physical environments.   

Dr. Fei-Fei Li, often called the godmother of AI, published a manifesto on how spatial intelligence is AI’s next frontier, contrasting it with LLMs. “While current state-of-the-art AI can excel at reading, writing, research, and pattern recognition in data, these same models bear fundamental limitations when representing or interacting with the physical world,” wrote Dr. Li. “Our view of the world is holistic—not just what we’re looking at, but how everything relates spatially, what it means, and why it matters. Understanding this through imagination, reasoning, creation, and interaction—not just descriptions—is the power of spatial intelligence.”

The concept of spatial intelligence isn’t new and was described in Howard Gardner’s book, Frames of Mind, in 1983. Recent breakthroughs, including the launch of World Labs’ Marble and its $1 billion funding round, and competing approaches from Google’s Genie 3 and Nvidia Cosmos, should put spatial intelligence and world models on more R&D road maps.

What are spatial intelligence models?

It’s important to develop AI literacy and understand the terminology and concepts related to the physical world and 3D AI technologies: 

• Spatial intelligence encompasses specialized approaches such as geospatial models for mapping the physical world and building information modeling (BIM) for modeling physical structures. It also extends to generative 3D, robotics, and physical reasoning applications.
• World models are a class of neural network architectures and are currently a prominent approach to building spatial intelligence.
• Digital twins are live, virtual replicas of physical assets that combine 3D models with real-time sensor data. Spatial intelligence, an emerging capability of digital twins, adds natural-language prompting, generative scenario exploration, and physics-aware reasoning.
• Spatial computing refers to digital content anchored in and interacting with physical space, sensed and rendered in three dimensions and delivered through AR/VR and mixed-reality systems.

“Spatial intelligence models go beyond pixels to understand the 3D structure of the world—how objects are positioned, how they move, and how they interact,” says David Fattal, founder and CTO at Leia. “This enables applications like more realistic video generation, spatial computing interfaces, and AI systems that can reason about physical environments. As real-world 3D data becomes more available, these models will become foundational to the next generation of visual AI.”

Monitoring the built environment

To better understand spatial intelligence, let’s consider physical infrastructure such as bridges and buildings. The American Society of Civil Engineers estimates a $9.1 trillion investment is needed from 2024 through 2033 to achieve a state of good repair. When maintenance and monitoring lag, it can lead to major failures such as the 2022 collapse of the Fern Hollow Bridge in Pittsburgh.

Spatial intelligence and the development of digital twins may help identify issues earlier and prioritize where investments are needed. “Spatial intelligence models serve as the 4D digital blueprints for our built environment, allowing us to visualize and predict the complex interactions between aging assets and the shifting ground beneath them,” says Patrick Cozzi, chief platform officer at Bentley Systems. “By synthesizing disparate geospatial data into a living digital twin, these models provide the foresight necessary to mitigate the hidden risks of structural fatigue and subsurface instability.”

There’s a significant challenge in bridge health monitoring and transitioning from manual, infrequent structural inspections to leveraging sensors, digital twins, and spatial intelligence. Cozzi adds, “This integration of continuous field data moves beyond static documentation, empowering agencies to evolve from reactive repairs to proactive, resilient asset management that safeguards the long-term integrity of our most critical public systems.”

Avoiding collisions

Bridges are largely static, but the real world is increasingly being occupied by autonomous systems such as self-driving cars, robots, and drones. And where there are moving systems, there is a risk of collisions.

“Spatial intelligence models are AI systems that reason about the physical world by combining vision, sensor data, and contextual cues to understand space, motion, and object relationships,” says Sudeep George, CTO at iMerit. “The value of spatial intelligence models lies not just in perceiving an environment, but in enabling machines to act within it safely and in real time. That is especially important in robotics and autonomous systems, where decisions must be made in complex, multimodal, fast-changing settings.”

To see one example, this tutorial for simulating robotic environments combines Nvidia Isaac Sim, an open source robotics reference framework, with spatial intelligence in Marble from World Labs. 

Today’s collision detection systems, such as those used in autonomous vehicles, typically rely on modules for sensing, perception, planning, and control. Spatial intelligence models may offer improvements by assessing the collision risks of unidentified objects or by tracking objects that move out of sensor view. For example, Waymo’s World Model, built on Genie 3, is a simulator that generates complex weather conditions and other critical safety events.

For an out-of-this-world example, James Urquhart, field CTO and technology evangelist at Kamiwaza, has delivered several examples of spatial intelligence applications, including one for satellite collision detection and conflict analysis. Urquhart says, “Models that specialize in these types of data sets, as well as the physics and geography of the real world, enable faster and more accurate decision-making for tasks that depend on them.”

Applying spatial intelligence

Recent spatial intelligence announcements include creating 3D worlds from image or text prompts with Marble and simulating water physics, lighting, weather, and animal behavior with Genie 3. But difficulties remain in bringing spatial intelligence to physical-world use cases.

“Spatial intelligence and world models are laying the groundwork for future AI agents that will be able to interact in and with our physical world,” says Jason Corso, cofounder and chief scientist at Voxel51. “These models are significantly more challenging to develop and test, largely because the data underlying their development is complex, and it’s hard to handle all of the combinatorics involved in the physical world.”

In addition to learning the models and prototyping with them, development and data leaders need to review the data assets that will feed spatial intelligence models. “Spatial intelligence models translate location signals into a structured understanding of the real world, but they’re only as reliable as the data beneath them,” says Dan Adams, executive vice president and general manager of Enrich at Precisely. “The real unlock isn’t the model—it’s the reference layer with persistent identifiers, confidence metadata, and source lineage that lets AI reason about places, not just match strings.”

Even once applications are developed, there will be infrastructure challenges in deploying them at the edge. Ali Kayyam, principal research scientist at BrainChip, says, “The key to unlocking spatial intelligence at scale is having the low-power, event-driven hardware that can run it at the sensor in real time where it matters most.”

Where to get started

My suggestions for developers looking to get hands-on with spatial intelligence and world models:

• To try out Marble, review their API documentation and case studies, and then experiment with a developer-focused React application.
• Review the Nvidia Cosmos developer hub, documentation, and cookbook of case studies and learning paths.
• You can get an overview of Genie 3, but access is currently restricted through Project Genie, which requires a Google AI Ultra subscription.

For decades, software engineering has been plagued by “productivity theater.” Every few years, the industry aligns around a new vanity metric — usually one that latches onto whatever technology happens to be in vogue at the time. For a discipline rooted in creativity and problem-solving, this is a poor way to demonstrate progress. Yet, we find ourselves in this position once again. The pattern is often the same: reach for something we can easily count, and in doing so, lose sight of what we are actually trying to achieve.

Quantity over quality: the wrong measurement, every time

I recall when I was coming up as a software engineer in the 1990s, a small number of companies took up the practice of paying their engineers by each line of code. This may have been productivity theater at its worst, leading to negative incentives, inefficient processes, and just generally bad engineering. Developers were rewarded for writing far more code than the problems they were facing required — classic “quantity over quality” — and the result was bloated, brittle codebases that were all but impossible to maintain. The goal — to create reliable software that solved real user problems — got buried under the incentive to produce.

Then in the 2000s, the rise of Agile brought us story points, an abstract way to estimate task complexity, effort, and risk relative to other work. Rather than answering “How long will this take?,” story points were meant to answer, “How big is this compared to what we’ve done before?” This approach sounds good in theory, but in practice, some development teams learned to game the system by inflating estimates, over-engineering solutions to look productive, and losing sight of whether the work they produced actually created value. Once again, the metric became the goal, and the actual goal — delivering outcomes that mattered to the business — became secondary.

Every one of these metrics failed for the same reason: they measured effort instead of value.

Quantity in the age of AI

Today, “tokenmaxxing,” a trend in which developers and teams optimize for consuming as many AI model tokens as possible, treats raw consumption as an equivalent for output. As I see it, this is the latest flawed productivity metric to make its way into the world of software engineering. Tokenmaxxing is nothing more than another vanity metric, and is just as useless as using “lines of code” or inflated “story points” as a benchmark.

Tokenmaxxing is the result of a few different behaviors, including:

• Prompt flooding: stuffing massive codebases, documentation, and context into every prompt, burning tokens on context the model doesn’t actually need.
• Agent swarms: running multiple AI agents in parallel to maximize code output, regardless of whether the work is coordinated or coherent.
• Background loops: keeping AI sessions or agents running continuously in the background, racking up token spend without clear ownership of what is being produced — or why.

Now, it is no secret that AI is reshaping how software is developed, and these behaviors are the result of that reshaping. Providing AI with codebases, running multiple agents at once, and even relying on coding assistants for help all have their uses. But when we lose control of the changes we are making and why we are making them, we find ourselves facing a new version of the same old problem: measuring engineering productivity with the wrong metrics.

A more useful question to ask isn’t, “How many tokens did we spend?” but rather, “What problem did we actually solve, and for whom?”

Spending resources without goals

Yes, AI is giving software engineers the ability to do more with less, to move quickly, and to experiment in ways that were previously out of reach. But leaning on AI to perform productivity, rather than deliver it, is a trap that will cost us in code quality, team capability, and business credibility.

As a CTO, I am all for experimenting with AI. I want to use it to make our programs better, stronger, and future-proof. What I don’t want is for it to drive us toward excess while leaving us with little to show for it.

The test I keep coming back to is simple: does this AI-generated output help us ship something that matters? Does it reduce friction for a user, close a gap in a workflow, or improve reliability for a customer? If the answer isn’t clear, then we are spending resources — both human and computational — without a defined goal. And that is not engineering. That is activity.

Spec-driven development: where value gets defined

It is time to adopt newer approaches like spec-driven development, a method where engineers write detailed specifications first and AI generates code against them. Rather than relying on prompt flooding and agent swarms and hoping AI produces the best result, we need to shift toward defining requirements, reviewing AI-generated output, and orchestrating systems with intent.

But spec-driven development is more than a methodology. It is the place where engineering intent and business value get defined together. The spec is where you answer, “Why does this matter, and what problem are we solving?” before a single token gets spent.

Software engineers have long taken pride in writing elegant code, and I would hate to see AI cheapen that pride rather than elevate it. In an AI-first world, the craft shouldn’t disappear; it should simply move upstream. The spec is where elegance lives now, and it deserves the same attention to detail we once reserved for the code itself.

At its core, software engineering is about defining, analyzing, and resolving technical challenges. If we are willingly giving all of that up to AI, we will lose the integrity of our discipline and the ability to prove our value. Using the maximum number of tokens to produce code isn’t impressive. Using a well-crafted, intentional prompt to solve a specific problem? That’s the work worth celebrating.

Stop performing productivity and start delivering it

We are at an inflection point. Many organizations are defaulting to activity-based metrics, measuring how much AI is being used rather than whether it is improving delivery, product quality, or business outcomes.

The question worth asking is not, “How much AI did we use this sprint?” It is “What value did we deliver for our users, our team, or our business?” Was it the ability to resolve a critical bug more quickly? Reduced cycle time on a high-value feature? A customer workflow that now takes minutes instead of hours? Those are outcomes. Those are the things worth measuring.

AI can help us deliver meaningful outcomes faster, but only if we use it with the same rigor and intent we expect from every other engineering or business decision. Don’t let it become another form of productivity theater. The most successful engineering organizations in the age of AI won’t be the ones that consumed the most tokens, they’ll be the organizations that never lost sight of why they were building in the first place.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.