Lead times of nine to 12 or even 18 months. Costs rising by 35%, 45%, even 50% to 200%. More than halfway through 2026, the market for IT infrastructure that’s crucial for enterprise projects, including those involving artificial intelligence, is strapped.

Memory is at the root of the shortages. Memory prices “have risen by 50% to 200%, resulting in PC prices increasing by 35% to 45% and some server prices rising over 125%,” according to Jon Forest, VP analyst at Gartner. Network switches also need memory, albeit in lesser amounts than servers, so they are not immune, with prices and lead times likewise rising dramatically.

Industry experts agree that most of the issues stem from hyperscalers gobbling up memory capacity, which trickles down to servers, storage systems, and networking devices. But while the source of the problem may be new, supply chain disruptions are far from unprecedented.

As a result, industry insiders are not short on advice on how best to deal with the situation, with tips including making better use of what you have, considering options beyond your usual scope, and lots of planning with your vendors and internal finance teams.

State of the problem

Just how bad is the current supply chain problem? “It’s pretty bad,” says Matt Kimball, vice president and principal analyst with Moor Insights & Strategy. Companies accustomed to 30- to 45-day lead times for various infrastructure are now looking at 6, 12, or even 18 months.

“It’s real, and I’m hearing it from companies of all sizes, from the 1000-server to the 10,000-server shops,” Kimball says.

“Memory costs are expected to rise sharply well into 2027 and will reach up to 25% of network hardware expenses by the end of 2027,” according to an email Gartner’s Forest sent to Network World. The figure below shows the timeline Gartner expects for memory prices, and Forest notes that the same timing applies across networking, storage, and compute infrastructure. 

Gartner

“Enterprise network equipment pricing is projected to increase by over 20% in 2026. This upward trend is anticipated to continue with a further rise of 3% to 5% entering 2027, with no signs of price reduction until the end of 2027.”

But “reduction” will likely look more like “stabilization.”

“That’s something a lot of people don’t like to talk about. But let’s say prices went up 40%, they may come down five,” says Phillip Privett, senior vice president of vendor management with the global distributor and value-added reseller TD SYNNEX. “They’re not going to come down 40%.”

Perhaps worse, compared with past disruptions caused by issues such as fires in chip fabrication factories or the Covid pandemic, Kimball says this one is “durable” because its cause—the AI wave—is more long-lasting and just getting started.

“This AI inference wave we’re hitting is just beginning. It’s going to be longer and bigger than the training wave,” he says. “It’s impacting everything, from AI infrastructure to the traditional stuff that’s standing up your virtualization and cloud infrastructure.”

No vendors seem to be immune, not even the likes of Cisco, which makes its own Cisco Silicon One chips. Or, at least, it designs the chips; they’re actually manufactured by the Taiwan Semiconductor Manufacturing Company (TSMC), the same company that makes many of the other chips that are in such demand. And that’s only one component of many that comprise a switch.

On the other hand, the margins Cisco gets from enterprise sales are far greater than those from hyperscalers because Cisco sells mainly just hardware to hyperscalers, whereas enterprise sales generally include software and services as well. So, Cisco has incentive to keep enterprise customers happy and maintain the 66% margins it reported in Q3, its latest quarter.

Still, Cisco must deal with the same shortages as other vendors.

“I wouldn’t say any company is faring better than others,” says Neil Anderson, vice president and CTO for cloud, infrastructure, and AI solutions at World Wide Technology (WWT). “There may be nuances that some suppliers are employing to balance it to some extent, but I fail to recognize a supplier that’s not having almost the same issue.”

Cloud storage vendor Backblaze is one company that’s facing equipment cost and availability issues. “There are different types of shortages occurring in multiple places, all driven by unusual market demands, really by just a handful of very large buyers,” says James Rowell, senior vice president of operations with Backblaze.

Backblaze is constantly forecasting and monitoring demand triggers, Rowell says. That involves close alignment with the sales team to forecast client needs, as well as paying attention to historical trendlines to predict upcoming demand from new deals and growth with existing clients. But the company also looks for “unnatural market-related triggers” that would cause a spike in utilization.

With hyperscalers buying up vast amounts of capacity, “This is definitely an unnatural phase,” Rowell says. “For about for the last 12 months, I would say there’s been somewhere between a 15% and 30% uptick in costs,” especially in terms of servers and compute disks.

On the positive side, at least for Backblaze, the company is also seeing an uptick in business from an interesting source: AI companies. “We reported in the last earnings period a 70% increase in AI companies using our platform,” says Patrick Thomas, vice president of marketing at Backblaze. “That’s massive.”

On top of that, the company is seeing an uptick in deals from enterprises that can’t get the storage capacity they need or want on-prem. “There’s a general market nervousness where we’ve got potential deals coming our way because those organizations are concerned about being able to do it themselves,” Rowell says.

While some expect new chip fabrication plants currently under construction will ease memory supply constraints, Privett doesn’t buy it. “I don’t see it getting better anytime soon,” he says. “Building a new fab is a two-year process.”

Advice: Start with the basics

Enterprises, then, must play the cards they’re dealt. For Moore Insights’ Kimball, who did stints as an IT exec with the states of Florida and Oregon, that starts with making the most of what you have.

Such a strategy is “shockingly not implemented much” across the companies he sees. “A simple capacity planning exercise can free up a lot of resources.” That includes virtualized servers running at just 20% to 30% utilization as well as extending the life of existing servers. While 15 or 20 years ago it was common to refresh every four years or so, companies can often get six or seven years out of today’s servers.

While such strategies won’t solve your AI compute challenges, they can certainly help support your ongoing operations and free up budget for AI and other modernization projects, he says.

“Sweat your assets,” agrees Privett of TD SYNNEX. “Work them as much as you can, add only what you need, get extensions on your licensing, renewals on your services agreements and things like that. Just sweat it out a little longer.”

If you have budget to spend but can’t get the hardware you’re after, buy something else, says WWT’s Anderson. “Look at things that are not tied to those components, like software projects or SaaS licensing,” he says.

Get friendly with finance teams

Numerous experts recommend regular meetings with your CFO or finance teams to keep them apprised of what you’re up against so the company can plan accordingly.

Gartner’s Forest advises using rolling 12- to 24‑month forecasts and engaging early with suppliers to identify constrained components and SKUs. Committing to quarterly or monthly buys can help you avoid long-term agreements that extend past the rapid increases we’re seeing in 2026, he says.

Also engage with the financing arm of your equipment vendors, some of which are offering financing incentives, Privett says. Compute vendors in particular are offering subsidized financing, deferred payments, and low-cost financing for the first year or so. “Those are huge opportunities to take advantage of,” he says.

By engaging with finance teams, IT groups can conduct budget allocation exercises and try to come up with ways to make the financials work. The last thing you want to do is surprise them with additional budget requests out of the blue.

Kimball recalls his days with the state of Florida, when all budget requests were examined by a technical review working group—which was designed to be hostile.

“I can’t imagine going to them and saying, ‘Oh, did I say that was a million dollars? It’s actually $2 million. I need you to write me a bigger check,’” he says. “I would walk into one of the swamps in Tallahassee and get eaten by the alligators instead of doing that.”

Work with your vendors and VARs

As you put plans together, lean on your vendors for help, including channel partners such as value-added resellers (VAR) and national resellers. “Work with them to map things out and understand what your workloads will look like,” Kimball says.

That’s what Backblaze’s Rowell regularly does with his suppliers. He lays out his forecast for the year, with commitments on what Backblaze will definitely buy, as well as scenarios that account for rapid growth, say, 2x. “And they’ll come back with, ‘Well, okay, no problem,’ or maybe they say we need to put in an allocation right away, or we won’t be able to get what we may need,” he says.

Similarly, he sits down with his CFO regularly to map out predictive models that factor in inflation, price hikes, and the like. The idea is to plan out multiple scenarios, so you don’t get blindsided.

“If you don’t do that, you’ll get caught with your pants down, on the upside-down end of spectrum,” he said – meaning not having the capacity to take advantage of market opportunities.

Acquiring the capacity you need to meet project demand may also mean being flexible in terms of your equipment choices. If you’re a Dell shop but can’t get Dell servers, maybe you go with Lenovo, Kimball says.

“You’ve got to figure out how to use all this silicon and infrastructure in a heterogenous way to serve your needs,” he says. That’s especially true when it comes to AI infrastructure. “If you think you’re going to go with 100% Nvidia for everything from RAG [retrieval augmented generation] to inferencing at the edge, you’re kind of crazy, not because of cost but because of availability.”

Look at alternatives, including AMD and cloud solutions, while staying mindful of how it all plays together. You may not be able to get Nvidia GPUs, but AWS, Azure, and Oracle Cloud have them, Kimball notes.

Be strategic, perhaps by using cloud offerings to handle certain tuning or inference workloads, then bringing them back in-house when appropriate. “Have a better understanding of what absolutely has to be on prem and what can be in the cloud,” he says.

That’s good advice, says Backblaze’s Thomas. When it comes to AI, think about performance tiers and the range of use cases you have. They don’t all need top-tier performance.

“People get wrapped around axle of needing the top end. There’s a lot of flexibility in the edges, innovation in different hardware and software,” Thomas says.

Gartner likewise advises companies to increase configuration flexibility and expand sourcing paths. That may include buying from secondary markets and lease-return programs to preserve continuity with existing infrastructure until the shortages pass, Forest says.

Get started somewhere

Even if you can’t acquire or have to wait for the infrastructure you need, don’t let that keep you from getting started with AI or other modernization projects.

Options include public cloud and neocloud providers, Anderson says. WWT also provides capacity in its own lab so customers can get started with proof-of-concept projects. “Don’t just throw your hands up. We can help you find access to capacity,” Anderson says. “Production-scale AI may be delayed, but don’t let that derail your strategy.”

Colocation providers may likewise be an option, especially if enterprises are struggling to acquire high-end networking equipment. Networking is a key value proposition for colocation providers, in that they have built-in connections to various cloud providers and other ecosystem players.

Equinix, for example, has 280 data centers in 77 metropolitan areas, says Phil Read, senior director, colocation product management for the company. If you have the compute infrastructure, Equinix can help you with the high-end connectivity required both intra- data center and at edge facilities.

It also has partnerships with the likes of Cisco and Nvidia for “ready-to-go AI connectivity,” Read says. That means Equinix offers the right infrastructure to meet the requirements of high-end compute solutions in terms of power density and cooling. Such power densities are significant, requiring 120k VA per rack and up. “There’s plenty of talk about a megawatt rack,” he says.

Power is a significant issue in this entire discussion, Privett says. Older installed computing infrastructure likely consumes far more power than newer systems, which is an argument for upgrading as soon as possible.

“If you modernize today, you could substantially reduce the number of servers needed to support the same applications at a much lower power consumption rate,” Privett says. He advises sitting down with folks from the OT side of the house to make sure power is available for whatever you want to do. In many areas, power is at a premium.

If your plans include installing GPU environments in your own data center, WWT advises you not to delay. “We’re telling customers, you need to talk with us and get that designed, get that ordered, because it will take quite a bit of time until it actually ships and we’re able to install it,” Anderson says.

Moor Insights’ Kimball agrees. “You have to order these parts today if you want to see them hitting your dock, your warehouse, or your office 12 months from now.”

At CIO100 in Frisco, Texas, roughly 100 rising technology leaders sat down for our “Next CIO” session. The group was asked to reflect on a single question: Are you ready to take on the role of CIO? Using the CIO Readiness Framework that we have developed and refined over years of advisory work, we asked each person in the room to score themselves across the five dimensions of the framework. The results point to a gap that should worry any organization building its next generation of technology leaders.

The CIO Readiness Framework

The CIO Readiness Framework organizes the CIO job into five dimensions. We asked each rising leader to score themselves on the same 1-to-5 scale, from “Emerging” to “CIO-Ready.” The five dimensions of the framework are:

• Enterprise leadership: the ability to lead beyond your own function, anticipate where the business is headed and mobilize people through change.
• Business value and financial acumen: understanding how the enterprise makes money well enough to connect technology decisions to growth, margin and risk.
• Influence, narrative and enterprise selling: building belief and support before a decision is ever formally proposed, not just presenting sound logic once it is. 
• Relationships, talent and operating leverage: building trusted executive relationships, developing successors and creating an organization that delivers beyond your own personal reach.
• Technology stewardship and digital judgment: the technical fluency and architectural judgment needed to make durable enterprise technology decisions.

Where the room stands

Across the five dimensions, the average self-assessment landed at 3.4 out of 5, squarely in ‘Proficient’ territory. Consider who was in the room: people already selected by their own organizations as ready to be developed for the next level. Even so, not one of the five dimensions averaged ‘Advanced’ or higher across the entire group. Technology Stewardship and Digital Judgment (the ability to make sound decisions on platforms, architecture and risk) came in as the most mature dimension in the room. At the bottom sat two dimensions in a near tie: Influence, Narrative and Enterprise Selling; and Relationships, Talent and Operating Leverage.

Much more interesting, however, is the spread between the highest- and lowest-rated dimensions. On these bottom two dimensions, ~65% of attendees rated themselves Proficient or below. Compare that to Technology Stewardship, where the number was only 36%. Put plainly, the people in that room are confident in their technical judgment. They are far less confident in the parts of the job that have nothing to do with technology at all.

Why the human dimensions lag, and what to do about it

This tracks with what we hear constantly in our advisory work. Most people who reach the doorstep of the CIO role got there by being excellent at the technical and operational core of IT. Few of them spent their first fifteen years being evaluated on stakeholder mapping, coalition-building, or developing a successor. Those muscles simply were not required until now.

The good news is that these are learnable skills. We recommend a simple approach to close these capability gaps: for the dimensions where you rated yourself lowest, identify a goal that targets your weaknesses, then attach a tactic (a concrete action or behavior) that moves you toward achieving your goal. Lastly, give the whole thing a timeframe. Six months is often a good starting point, as it is long enough to make real progress and short enough that you’ll actually check.

In this activity, the goal represents the destination – for example, to develop a brand of “enterprise leader,” rather than just “strong IT operator.” The tactic is how you get there, something specific enough that you’ll know in six months whether you did it or not. “Get better at influence” is a goal with no tactic attached, which is exactly why it rarely changes anything. “Hold pre-alignment conversations with three sponsors before my next major proposal” is a tactic, and it’s either done or it isn’t.

Here’s what that pairing looks like applied to the two lowest-scoring dimensions from the CIO100 room:

• For Influence, narrative and enterprise selling, a reasonable goal is building support for ideas before they ever reach a formal decision point. Tactics in service of that goal include identifying the informal decision-makers behind a priority and earning their support early, or taking on an external opportunity (e.g., industry panels, published point of views) to build credibility beyond the building.
• For Relationships, talent and operating leverage, a reasonable goal is creating executive capacity instead of personally absorbing more of the work. Tactics in service of that goal may include adding standing one-on-ones with two peers on the executive team, and delegating two recurring items off your own plate with clear decision rights attached.

The takeaway for CIOs building their bench

If you’re a sitting CIO developing your own successors, this data serves as a useful gut check. The people you’re grooming may already operate at an advanced level technically while carrying real gaps in the skills that determine whether they succeed once they have the title. Executive presence, coalition-building and delegation take years to build, so the earlier you start, the better.

The future leaders we worked with at CIO100 had no shortage of ability. What most of them lacked were the specific, practiced habits that turn a strong technology leader into an enterprise one, and the self-assessment data shows they already know it. Acknowledging that gap is the first step toward closing it.

In the summer of 2024, JPMorgan Chase deployed its internal AI platform LLM Suite, launching it very differently than most do: The company didn’t force anyone to use it.

When LLM Suite arrived at its first major division, asset and wealth management, employees were asked to think of it as a research analyst: someone to ask for data, a draft, or an idea. Leadership didn’t set usage objectives or provide a formal mandate.

Access was rolled out in phases and only to those who requested it, and the bank allowed the tool to circulate through word-of-mouth recommendations among colleagues. While half the industry rushed to count users and publish adoption rates, JPMorgan gave up on pursuing that number.

It became flooded with users. In eight months, 200,000 employees had signed up without a single order being issued, out of a workforce of over 300,000. In time, the bank established more than 450 use cases in production.

Two years after that summer launch, JPMorgan had everything to boast about. It had established itself as a global leader in the use of AI: It was the top bank on the Fortune AIQ 50 list, and the third company overall, ahead of all the tech giants except Alphabet.

It was then that the bank’s head of analytics, Derek Waldron, the person best positioned to sell the success, pointed out what still wasn’t working: There was a gap between what the technology was capable of doing and what the bank was actually capturing in its business results.

That gesture is what distinguishes JPMorgan. Although it has much to celebrate, it knows what it lacks, it says so publicly, and it keeps searching for it. Behind that statement lies a way of innovating and measuring that the bank has been developing for years.

Giving up the number everyone was chasing

The first thing JPMorgan did right was not to make adoption the goal. By not forcing anyone, it turned platform usage into a barometer. If a tool worked, it was filled without any campaign; if it didn’t, it was emptied, and that emptiness provided valuable information. If adoption had become a target to be pursued, the organization would have optimized the number instead of understanding what the number represents.

The bank itself acknowledges that if a tool is broadly used, it means it’s popular, but not necessarily effective. To determine its effectiveness, something more was needed. The answer came from two decisions that only work together: linking each project to a business outcome, and creating the metrics to demonstrate that outcome.

First, to find initiatives that could have a real impact, instead of creating an agenda from the top down, the bank surveyed its business units, asking where there was a problem to solve. Within a few weeks, an internal portal gathered, according to the bank’s figures, nearly a thousand ideas. Of these, only a few hundred moved forward and reached production. An organization doesn’t open a funnel of that size if it expects most ideas to survive; it anticipates that many will be discarded.

The funnel’s filtering method was also different. Before launching each test, the outcome that would ensure the experiment’s survival was defined, along with the steps to be taken the day after the decision. By planning future actions in advance, indecision and the perception of failure were avoided.

A clinical approach to AI experimentation

But setting a threshold for each experiment requires verification, and that’s where the bank encountered an unexpected obstacle. Metrics have their own cycles. Bank customers conduct business on Mondays, not Sundays. They receive their paychecks at the end of the month. In August, they disappear. When an initiative generates a change and a figure rises the following week, there’s no way to know whether it increased due to the change or the calendar.

The solution was borrowed from clinical trials. Instead of rolling out the change to all users, it was rolled out to half, chosen at random. The other half (the control group) operated on the same Monday, the same payroll, and the same August, so that the experimental contribution (the attribution) could be separated.

The next step was to industrialize the experiments. Doing it properly required a specialist sitting alongside each product team, and with that method, they reached eight per year. A self-service platform increased the figure to around 300 tests annually.

The results are concrete. For example, tens of thousands of the bank’s engineers have gained between 10% and 20% efficiency thanks to an internally developed programming assistant.

Finally, the bank discovered that a figure can be accurate and yet mean nothing. Its head of analytics explained this with a simple example. They measure the hour that AI saves one employee, and the three hours it saves another. They add them up, and the result is accurate. But in a process that goes from beginning to end, those saved minutes often don’t appear on the bottom line: They merely shift the bottleneck to the next one.

It’s easy to get stuck on partial metrics because they’re more immediate and produce more impressive numbers. JPMorgan’s discipline consisted of not accepting a metric as valid until verifying its impact on the business at the end of the process.

The question then remains on Monday morning: What can a company that has neither the size nor the budget of a bank take home?

The method is what best exports

What’s most interesting about JPMorgan isn’t what it has done with AI, but how it has done it . Any company can replicate this approach, because it doesn’t depend on proprietary data, scale, or budget.

The following are some best practices that don’t require a €20 billion annual budget. They do require making decisions before starting and are within reach of any company:

Launch far more initiatives than will survive, and announce this clearly. If the organization discovers halfway through that most of its projects will be canceled, it may misinterpret this as a planning failure; if it knows from the outset, it understands it as the natural selection process. This is what makes making mistakes quick and cheap.

Decide in advance the threshold that will shut down a project and plan the next steps. Both aspects are necessary, not just the metric. If a certain figure isn’t reached, the team needs to know what will happen next. Applying a threshold without future planning leaves the team in limbo, and they’ll have to find a reasonable reason to wait another quarter before shutting down.

Work on business outcome metrics from the outset, not just when they’re requested. This tracking not only guides the initiative but also prevents having to reconstruct months of poorly documented decisions. Adoption, by the way, is the number the CFO won’t ask for. It serves as a signal while no one is pursuing it, and it ceases to be useful the day it becomes a target.

How to get it right

Whether metrics mean anything depends on where you focus your attention. It’s best to start with scope, because that’s the most common mistake. Saving three hours in one stage isn’t the same as improving time-to-market: If the entire process isn’t shortened, what you have is freed-up capacity, which is also valuable, but it’s something different, and it’s advisable to make that distinction clear.

Then it’s important to consider that value leakage occurs in two directions. The first is outward: The savings are passed on to the customer in the form of lower prices or better service. The second is inward: The savings in personnel are replaced by spending on computing. If these items fall into different budget categories, it’s easy to overestimate the actual savings.

Finally, there’s an excessive focus on cost savings, at the expense of revenue opportunities. Jamie Dimon, CEO of JPMorgan, put it more bluntly to his analysts than any consulting firm: No one benefits uniquely from AI. In other words, competitors will eventually incorporate those savings. The greatest potential for differentiation lies in revenue: using AI to uncover unmet demand.

The question a CIO will have to answer in a year’s time won’t be how much AI their company uses. It will be which of projects are still alive because they work, and not because no one has bothered to test them.

When Nvidia said Thursday that it plans to pay $13 billion to acquire Hugging Face, the question arose of whether the open AI platform would remain open when it becomes a unit of Nvidia. And the current lack of a single viable open alternative that does everything Hugging Face does for enterprises adds further complications for CIOs.

Rumors of the pending deal have been circulating for at least a week. 

In its announcement, Nvidia said, “Hugging Face will remain an open platform for the entire AI ecosystem. Developers will choose the models they want, the frameworks they want, the clouds and inference service providers they want and the computing platforms they want. Nvidia compute will not be required to build on or deploy through Hugging Face.”

It added that Hugging Face will continue to support open source and open weight models from every model builder, and “continue to support multi-cloud and multi-accelerator development and deployment, so builders can use the hardware and infrastructure that best fit their work.”

Hugging Face CEO Clément Delangue took to his X account to also reassure customers, noting, “open-source AI is at an inflection point” and pointing out that, for the business to scale, it needs “more compute, more support, more collaboration and more visibility. That’s why we went to talk to [Nvidia CEO] Jensen [Huang], who offered to do exactly that with us.”

Preserving the Hugging Face team

Nvidia is also attempting to retain some of the Hugging Face workforce. As part of the deal, according to Nvidia’s 8-K filing, the purchase price is $11.9 billion, with “approximately $1 billion” earmarked for “an equity-based retention program” for Hugging Face employees who agree to join Nvidia. It has yet to be announced how many members of the Hugging Face workforce, estimated to be almost 750, will be offered roles at Nvidia.

But despite the reassurances from Nvidia about maintaining the open nature of Hugging Face, analysts and consultants suggested that the truth may not be known until months, or even a year, after the acquisition finalizes sometime next year; the transaction is expected to close “in the first half of 2027.”

Cause for optimism

Enterprise CIOs can only wait and see what Nvidia will ultimately do. 

But in the meantime, there is cause for optimism, given the history of recent open source acquisitions, said Jason Andersen, principal analyst at Moor Insights & Strategy. 

“There is always a ‘sky is falling’ narrative” with these transactions, Andersen said, but in recent years, open source acquisitions have often turned out quite well.

“What happened to Red Hat after IBM bought it? Things got better,” Andersen said. “The same can be said for GitHub after Microsoft bought it. Or Google’s acquisition of Gemma. There are just too many examples of it going the right way.”

Justin Greis, CEO of consulting firm Acceligence, also sees this acquisition as potentially good news for enterprise CIOs. 

“If Nvidia turned [Hugging Face] into a walled garden or an obvious funnel toward Nvidia hardware, it could undermine the community and network effects it just paid nearly $13 billion to acquire,” he pointed out. “Nvidia is being unusually explicit that Hugging Face will remain model-, framework-, cloud- and accelerator-agnostic, including saying that Nvidia compute will not be required.” 

And, he added, Nvidia could indeed make Hugging Face even more enterprise friendly. 

“Nvidia itself points to the opportunity to improve Hugging Face’s reliability, safety, model evaluation, inference, and deployment capabilities. That is potentially a very big deal,” Greis said, noting that enterprises don’t simply need access to more models, they need confidence that those models can operate within complex environments with governance, security, performance, resilience, and lifecycle management around them.

Those needs make the combination compelling, he said: “Nvidia has the engineering depth, infrastructure expertise and ecosystem reach to significantly raise that bar. Hugging Face has been enormously successful as a developer and open-model platform. Nvidia now has the opportunity to help make it much more enterprise-grade: a place where companies can discover models, datasets, and AI components, but also increasingly evaluate, test, secure, operationalize, and deploy them with the level of confidence and rigor expected inside a large enterprise.”

Avoid a single dependency

Still, said Shashi Bellamkonda, a principal research director at Info-Tech Research Group, there are various practical steps that CIOs can and should soon take to preserve what they have already created within Hugging Face.

“This should be a clarion call for CIOs to treat Hugging Face and open source models as part of their enterprise supply chain, and if a production system depends on an artifact hosted on Hugging Face, keep a verified copy in a second registry, whether that is GitLab, Amazon S3, or an internal artifact store,” he said. “Enterprises should also consider the source for open models and develop a fallback plan such as the model developer’s own repository or another hub, because Hugging Face is the dominant platform today, but no enterprise should depend on one company’s availability, governance, or roadmap.”

Bellamkonda also pointed out that, by owning Hugging Face, Nvidia would gain valuable visibility into which models are gaining traction, how developers are deploying them, and which hardware ecosystems they run on. It would then “hold a powerful position in the distribution of new open models, so that combination of infrastructure ownership, market intelligence, and hardware influence should factor into CIO planning,” he said.

Mike Wilkes, enterprise CISO at Aikido Security, added that one of the factors that makes a CIO’s 2027 contingency planning in the face of Hugging Face’s new ownership difficult is that there are not that many large open source companies that could directly replace Hugging Face for an enterprise.

“No true replacement exists for Hugging Face at its scale, but there are ways to avoid making it a single point of dependency,” he said. “Azure AI Foundry is probably the closest enterprise alternative regarding model breadth, now advertising more than 11,000 models and supporting models from OpenAI, Anthropic, Meta, Mistral and others. AWS SageMaker JumpStart is another option, as enterprises can create private curated model hubs with their own governance controls. Google’s Model Garden is a third viable choice and supports both managed and self-deployed open models inside the customer’s own cloud environment.”

But adopting any of those alternatives means a move from an independent Hugging Face to Microsoft, Amazon, or Google, “so they change the concentration risk rather than eliminating it,” Wilkes noted. “The best enterprise strategy is not to search for another Hugging Face, but to separate model discovery from model custody. We can continue using Hugging Face to discover and evaluate models while mirroring approved models into an internal repository or registry under our control.”

Risk of increasing AI control by Nvidia

IDC’s Ashish Nadkarni, a group VP, said CIOs must also remember that the Nvidia move could give it various levers to even further tighten its control over global AI developments. 

“Hugging Face is like GitHub for AI. It is the default front door for open AI innovation: it’s where data scientists, machine learning engineers, and developers discover pretrained models, fine-tune them, and push them into production, or find open datasets to train their own models,” he said. “Owning that front door gives Nvidia a major position in the mindshare of today’s AI development personas.”

Consultant Brian Levine, executive director of FormerGov, also advised CIOs to stay alert. He predicted that Nvidia will exert greater control over Hugging Face efforts, but it will happen so gradually that it might not be noticed.

“The risk isn’t a dramatic reverse course. It’s a slow drift, where the Nvidia-optimized path quietly becomes the easy path, and everything else becomes the friction path,” he said. “Stop treating Hugging Face as a vendor-neutral utility and start treating it as a strategically-owned platform. That doesn’t mean leave. It means keep your options real and tested, not theoretical.”

Unanswered questions

And, from an enterprise CIO’s perspective, there’s another worry.

“Nvidia’s openness commitment is precise where it is cheap, and silent where it is expensive,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “The release promises that Nvidia compute will not be required, that multi-cloud and multi-accelerator support continues, and that developers choose their own models, each of which is a commitment about availability rather than about terms. Nothing in it addresses ranking, search placement, or default routing, and those are what decide which models a developer ever sees. Nobody has to be banned for the field to tilt. Gravity is enough and gravity is the part the pledge does not mention.”

This article originally appeared on InfoWorld.

The CIO job description is being rewritten in real time. As AI agents take over the interface layer and connect directly to any data source, the skills that once defined great IT leadership — UX fluency, applications integration, build-versus-buy judgment — are giving way to an entirely different set of questions surrounding not how a process works, but whether it needs to exist at all.

Thimaya Subaiya is living that shift firsthand. At Cisco, he oversees IT and says the ideal CIO candidate today might not have a traditional IT background. Here, he explains why he split the company’s AI leadership out as its own function and why he’ll merge back in, what he’s really looking for in a CIO candidate, and why the Cisco CIO job is such a good one.

How would you describe your role at Cisco?

I lead operations for one of the world’s largest supply chains, as well as security and trust, including product security, internal systems, and data center security. I also lead the CIO organization and have revenue operations, partnership management, and accountability for our AI strategy. Two and a half years ago, I consolidated AI from throughout the company and named a CAIO. I then split out the role to give us a boost in the AI space, but eventually, the CAIO role will merge into IT.

How did you conceptualize the CAIO role?

At first, it was a leader who could pull use cases from all our operations and execute. The role also included the ethical use of AI systems, and prioritized what to guardrail and push out to employees.

But it’s evolved. To take a step back, Cisco pioneered enterprise networking, then built Compute with Cisco, Storage with Cisco, Networking with Cisco, Security with Cisco, and Observability with Cisco. Today, the CAIO is moving up the stack with an AI framework for MCP connectors, which has really moved us forward.

This CAIO group can tell the Cisco-on-Cisco story for AI, because we have a testbed for new ideas. If we continue to rely on multiple vendors, as in the past, we won’t be able to integrate at scale. This is why we isolated the CAIO role, to focus exclusively on AI governance and execution.

You’re in the middle of a CIO search. What are you observing about the CIO talent market?

With AI, the CIO role has completely changed. It’s no longer about UX and applications integration because with MCP, we can connect to any data source at any time, and agents have replaced the interface. The CIO role is now more about rethinking a process and then deploying an agent to execute, rather than reworking a process.

So the ideal CIO is a traditional one who’s learned to think differently, or even someone without a CIO background, but who’s led in product management, innovation, or transformation. The role today requires someone who’s been disruptive, and has had to rethink how a company operates, not just how its applications work.

Our top criteria are strategy, speed of execution, and the ability to scale because we’re not investing in science projects. For example, when the sales team requests a better forecasting tool, a CIO traditionally would make a build or buy decision. But in today’s world, the right question should be if you need a solution to forecast at all, or can an agent do it. Or better yet, do we even need this process?

So what’s the right background for today’s CIO?

Product managers have a relevant background because they manage multiple aspects of how a product comes together: user needs, business outcomes, fit in the market, and getting it built. This understanding of product strategy, marketing, and adoption is extremely important right now because we treat our AI initiatives like products. So a great path for our CIO is data scientist foundations, product management, and transformation.

What about enterprise security?

I treat enterprise security as a separate organization, which every company should do. Testing and evaluating new cyber solutions for frontier models requires a lot of work like scanning everything, taking a neutral view of what’s broken, deciding which tools become standard within development frameworks, which cryptography tools to use, and then maintenance. Abstracting that into its own organization creates focus. It also lets us move at the speed of AI.

When AI attacks, you need AI to defend you, and if security is embedded within the CIO organization, it’s not top of mind for the business. Security has become its own board-level conversation. For today’s CIO, I’d keep AI in but take security out.

A year after the CIO is in place, what will success look like?

Our applications footprint has been reduced, we’ve seen pure productivity gains from accelerating the back, and the speed of new releases is increased. The team is becoming more effective with the same resources, and we can say that our CIO drove us to leverage everything new technologies offer without blowing up on tokens. We’re looking for a new way to operate IT.

Why is the CIO job at Cisco a great opportunity for the CIO you’re describing?

It’s possibly the coolest job out there. We have an entire AI stack end-to-end that nobody else can claim because we bring networking and security together, complemented by observability and collaboration. That combination means we can create net-new solutions that define what technology looks like in the future.

On the security side, we’re one of the very few companies truly integrating AI into defense in a way that can be leveraged across a much broader market. That’s exciting, because it means free access to an entire stack that lets you innovate in ways the industry hasn’t seen before.

I call AI today’s generational technology. Every generation gets a technology that redefines how it operates, including the internet, iPhone, and now AI. Cisco is about to become the first company to launch a personalized AI agent for every employee, reachable through Webex. Think of it this way: the average person has an IQ of around 100. Now every employee is paired with an AI agent that can exponentially increase human capacity, built entirely on the technology available today.

Getting to build things like that, with no proven methodologies or limitations, and nothing but the question of how we get to the future, is the most exciting thing there is if you’re an innovative leader.

Citrix on Tuesday announced that it has completed the acquisition of longtime partner Numecent, producer of technology that containerizes and manages Windows applications.

The acquisition builds on joint efforts to integrate Numecent’s management tool, Cloudpager, with Citrix Desktop-as-a-Service (DaaS) after an integration announced in April let administrators natively publish and manage the application containers through familiar Citrix workflows.

Numecent’s other product, Cloudpaging, packages Windows applications into isolated application containers independent of the underlying operating system, streaming them to Windows endpoints on demand rather than requiring them to be included in a desktop image. 

Citrix plans to further integrate the technology into its platform, while also continuing Cloudpaging and Cloudpager support for physical Windows devices.

“Enterprise customers have told us for years that application management is one of the most painful parts of running a Windows environment,” said Shawn Bass, SVP and GM of Citrix DaaS, in the announcement of the acquisition. “Numecent has solved this in a genuinely elegant way. By bringing Cloudpaging and Cloudpager into Citrix, we can make this capability native to every DaaS and physical desktop deployment so IT teams get back the time they spend wrestling with images and app conflicts.”

Analysts and consultants said the move will help enterprise IT to some extent, but will also increase vendor lock-in with Citrix while potentially exposing enterprises to data security risks.

Good for Citrix customers

Gartner VP Analyst Stuart Downes said, “overall, this is a positive for Citrix customers,” but he stressed that the promised conversions “are not 100% compatible.” 

He said, “low-level integrations into the kernel are generally not successful” because code that needs the lowest level of OS integration usually needs direct links to the hardware. Still, he estimated that applications at the low level probably account for only 2% of enterprise applications. 

For the more typical apps, Downes said that there will likely be “north of 90% compatibility. It varies. There are quite a lot of complex factors in app virtualization.” But he emphasized that Numecent offers two components: Cloudpager and Cloudpaging, and “we have yet to see how Citrix will integrate both.”

Justin Greis, CEO of consulting firm Acceligence, also sees a lot of potential savings for the enterprise.

“Large companies can have thousands of Windows applications, including legacy, custom, industry-specific, and highly specialized applications,” he said. “Many have dependencies on particular versions of Windows, libraries, configurations, or desktop images. Every major desktop refresh, Windows migration, VDI program, cloud move, acquisition, or infrastructure modernization effort can therefore create another application testing and repackaging cycle. The ability to abstract more of the application layer from the environment underneath it can remove a meaningful amount of that friction.”

Noah Kenney, principal consultant at Digital 520, added that the theoretical advantage that Citrix can now offer has great enterprise potential.

But, he argued, this likely amounts to an enterprise IT pay less now, pay more later situation.

“There are operational savings here, which is why customers will adopt it, but the bill comes due when they try to leave,” Kenney said. “This is a good acquisition for Citrix and probably bad for enterprise leverage over time. Citrix can now lose the desktop and still keep the customer. Every application moved into Cloudpager raises the cost of the next migration. Customers get the simplification now and Citrix gets the switching cost later.”

Half right

Sanchit Vir Gogia, chief analyst at Greyhound Research, said that he reads the containerization pitch as half right. “The packaging premise is valid. The cross-operating-system execution premise is not,” he said.

Gogia pointed out that Numecent Cloudpaging packages a Windows application with its dependencies and streams it to a Cloudpaging Player on a physical or virtual Windows endpoint, where it executes locally. “A Mac or Linux user reaches that application through Citrix’s remote delivery, where it still executes on Windows. That is cross-platform access, not cross-platform execution,” he said. “A Windows application does not become a Mac application merely because its pixels arrive on a Mac. The container is a packaging promise and the boundary of that promise is Windows.”

That said, he noted that there is still a lot of value in the Citrix arrangement, because Cloudpaging separates an application from a particular Windows image and carries that package across physical and virtual Windows environments, including Arm-based devices. 

“The real advance is not escaping Windows,” Gogia explained. “It is making application change less dependent on desktop change. Microsoft’s own App Assure data puts enterprise application compatibility above 99.7%, and Cloudpaging’s commercial logic lives almost entirely inside the fraction that remains. At enterprise scale, the final 1% of applications can carry far more than 1% of the business risk.”

But, he added, “Existing Numecent customers need binding answers on entitlements, migration and exit. Citrix has bought control of a useful Windows application lifecycle. Control now has to prove itself, and the proof it owes customers is less complexity, not merely more control for Citrix.”

Possible risk

However, consultant Brian Levine, executive director of FormerGov, pointed out that the nature of these new Citrix capabilities could expose users to serious security issues, including the risk of data exfiltration. 

He sees Cloudpager as “essentially a privileged switch that can push software to every Windows endpoint at once, which is precisely the kind of mass-distribution channel that produced SolarWinds and Kaseya. Bolting it onto Citrix, whose NetScaler gear has been a favorite ransomware target through repeated ‘CitrixBleed’ flaws, may leave CIOs and organizations wondering who will focus on security for the combined entity, and how will it prevent the type of attacks we’ve seen against Citrix.”

Citrix was asked to comment on these security questions, but did not do so by publication time. 

This article originally appeared on Computerworld.

The Trump Administration’s decision to punish Anthropic for its stance forbidding Claude’s use in domestic surveillance and autonomous weapons by identifying it as a supply chain risk to national security was “arbitrary and capricious,” a federal judge ruled on Thursday.

US District Court Judge Rita Lin said federal authorities had no legitimate reason to tell companies with government contracts that they couldn’t work with Anthropic.

“The undisputed record shows that the challenged actions constituted unlawful retaliation in violation of the First Amendment and that Anthropic was denied the pre-deprivation process required under the Fifth Amendment,” Lin said in her ruling, calling the designation “arbitrary and capricious.”

She stressed that the government action seemed punitive, and was not based on legal and national security risks.

The government’s words and deeds “confirm that the challenged actions were based on a desire to make a public example out of Anthropic for its ‘arrogance’ in criticizing the government, not based on any articulable basis to believe that Anthropic would actually sabotage its model,” Lin wrote.

She pointed out, “a few days before the challenged actions began, Secretary Hegseth proposed applying the Defense Production Act to Anthropic, which would mean the company was essential to national security rather than a threat to it. Even now, the government is discussing collaboration with Anthropic on its new model, Mythos, in an array of sensitive contexts. None of that is consistent with a genuine fear that Anthropic is a saboteur [that] would poison its software to harm national security.”

The judge added that the stated government fears made no sense, noting that the usage policy applicable to Pentagon work is a purely contractual limit. “Anthropic is incapable of enforcing it technologically, and does not have direct visibility into how DoW [Department of War] uses its model,” she pointed out.

“Nothing in the Administrative Record describes, even at a high level, what technological means would give rise to the so-called ‘backdoors’ or could otherwise allow Anthropic to ‘disable’ or affect Claude during a DoW operation,” the judge wrote. “Anthropic has submitted unrebutted evidence that it lacks any technological means to access or control deployed models.”

Lawyers, consultants, and analysts who looked at the decision were confident that the case would be appealed, and that it will end up in the US Supreme Court. 

Alan Webber, program VP for national security, defense, and intelligence at IDC, said that Lin’s ruling “was that the label [supply chain risk] was retaliation for Anthropic refusing to loosen safety guardrails DoD [Department of Defense, aka the Department of War] wanted lifted, dressed up in national security language. Put another way, a government customer tried to use a supply chain risk designation as leverage in a contract dispute over model behavior and application, and not because of an actual vulnerability.”

Implications for CIOs

Webber said the implications for CIO strategy are concerning.

“If a government CIO is relying on a vendor’s contractual guardrails, this case says those commitments can potentially become the trigger for exactly the kind of blacklisting that risk registers are supposed to protect against,” Webber said, noting that anyone who paused Claude usage or froze a subcontract because of the DoD mandate has a legal basis to resume the initiatives. “But obviously that doesn’t mean they will, or even should, as this will be appealed.”

He added that competing AI vendors have been using the government action as a sales tool, and with this ruling, the argument that Anthropic is a designated supply chain risk ”just got weaker, which could lead to contract award disputes.”

Consultant Brian Levine, executive director of FormerGov, recommended that CIOs do what they should have always done: Evaluate all products based solely on their merits. 

“CIOs should focus on using the frontier models that they believe make the most sense for their business, considering factors such as effectiveness, cost, security, safety, and confidentiality,” he said. “Anthropic and the other large frontier models each have too much market share to make retaliation for their use realistic, and the administration seems to have already moved on from this particular battle.”

Justin Greis, CEO of consulting firm Acceligence, agreed that this case has profound implications for CIOs and their AI decisions. 

What the federal judge did was reject the leap from a commercial and policy disagreement to an expansive supply chain risk designation without a sufficiently grounded technical rationale or process, Greis pointed out.

“The court found that Anthropic did not have the ability to access, alter, or shut down models once deployed in the government environment, and that the government ultimately conceded Anthropic’s technology was not inherently riskier than other comparable black box AI models,” he said.

“I think that distinction matters enormously for CIOs and CISOs,” he stressed. “As AI becomes part of the operating fabric of an enterprise, ‘We don’t trust the vendor’ cannot become a substitute for a defined risk model. Organizations need to be able to articulate what the actual technical risk is, how it manifests, what controls exist, and whether the response is proportional to that risk.”

“That becomes particularly important with AI,” he added, “because people can easily conflate disagreements over model behavior, usage policies, ethics, contractual restrictions, and cybersecurity into one amorphous category called ‘AI risk.’”

Original government edict still problematic

Mark Rasch, a former federal prosecutor who is now general counsel at Unit221B, a threat intel and security consulting company, said he was surprised by how quickly government attorneys surrendered on this case. 

“One of the things that struck me is that the government appears to have abandoned any rationale it might have had for its decision about Anthropic,” he said. The government “came back with all these reasons, but then they abandoned them all when they had to prove them.”

But, he said, the government instruction to all government contractors to also shun Anthropic was problematic. 

“It’s one thing for the government to say ‘We’re not going to do business with you.’ It’s quite another thing to say ‘Nobody we do business with can do business with you either,’” Rasch said. “This says that if you are disfavored by the administration, they’re not just going to blacklist you and say they won’t do business with you. They’re going to say that nobody can do business with you.”

Supreme Court arguments will likely be very different

Rasch predicted that the legal arguments in the Supreme Court will be quite different, and will potentially sidestep the lack of evidence.

“In the Supreme Court, [the government’s] biggest argument will not be that ‘We are right that it is a supply chain risk,’ but that, ‘Whether we’re right or wrong is irrelevant. We get to make that [supply chain risk designation] decision, not the court.’”

That would mean that the Supreme Court Justices could avoid exploring whether the government made the right decision, and instead focus on whether the government has the unlimited right to decide who is a national security risk.

This article originally appeared on Computerworld.

Companies grow in many ways, and physical security must keep pace. Sometimes growth occurs naturally through the evolution of internal business programs, but other times one company grows by acquiring another one, and it’s often a company that’s very different from the one that’s doing the acquiring. Growth is exciting, but with growth through acquisition, security teams face challenges around integrating two sets of dissimilar systems, processes, org charts and security cultures. These planning tips should help keep you agile and prepared when your security team encounters acquisitional growth.

Converging to an integrated roadmap

When one company acquires another, there’s an inevitable mismatch between security programs and plans. Company A might have mature processes but outdated systems; Company B might have recent tech but few processes for integrating its use. Or the companies might have different deployment and application philosophies. Sometimes the company being acquired has no formal physical security program at all.

The security culture at each company can also clash: one uses phone-based mobile credentials, while the other uses proximity access cards; one is rigorous about securing its IP due to strict regulations, while the other can historically afford to be more casual. These disconnects intensify when the acquired company’s people aren’t motivated to adopt the policies and practices of their acquirer.

Guess what? Very soon, they’ll all need to play together as one organization. And if one or both of the companies has an existing security technology roadmap, they each face inheriting various aspects of the other’s strategy. For all plans to work together and operational continuity to be preserved throughout the change, security leaders must find some way to blend the two companies’ strategies and cultures to yield an integrated plan for common platforms, activities and standards across the newly unified team.

Elevating security visibility

For most of us, corporate mergers and acquisitions (M&A) seem to happen fast — sometimes without warning. The decision to merge with or acquire another company is typically made in corporate boardrooms, beyond the consideration or awareness of individual departments. As senior executives meet to discuss fine print and calculate bottom lines, they don’t always account for the true costs of merging teams, resources and processes at the operations level, including IT, facilities management and security.

During acquisitions, then, security needs to play a role in shaping change, not just executing it. The number one way to accomplish this is to identify the committee in your company that manages M&A-related changes and do what you can to make sure security is on it. With security leaders adding their voice, you’ll face fewer roadblocks and misfires as acquisitions proceed.

As due diligence proceeds in the wake of an acquisition announcement, it’s up to the security team to provide its own accounting and plans, so that budget and support are hopefully available to accommodate the transition. This means jockeying for visibility as decisions get made that impact the efficacy of security operations and the protection of the newly merged physical environments.

Four areas to focus on

Why does visibility matter so much for security during acquisitional due diligence?

First of all, this work matters because cost and scope assumptions regarding security systems and personnel that are made without security leadership present are doomed to be woefully inaccurate. But also, merging security programs often incurs expenses that go way beyond traditional personnel and technology costs: SME travel during due diligence and integration, retraining of personnel, support for new users and so on. The transition team might be aware of some of these costs, but security can be there early on to make a holistic case by showing cost models, gap analyses and other key roadmap elements.

Planning and positioning your new security journey along this blended route is a matter of examining each company’s current security program and finding effective ways to integrate each one with the other — including potentially sunsetting certain program elements by evaluating and selecting the ones that work best in the new organization.

Correlation must happen across four main areas — budget, technology, people and culture. Let’s take a look at some high-level guidance in each area to help you get started. Then, we’ll jump into three key scenarios to see the areas where emphasis is especially needed to achieve smooth results.

Correlation area #1: Budget and business integration

In many ways, roadmapping starts and ends with a budget. If you don’t have funding, you can’t provide security on the level you plan for. If you don’t work with your M&A committee to identify and amplify security considerations in your blended roadmap, you’ll miss the chance to get your share of budget up front. Be prepared with security budget items and ready to defend them. Need to consolidate and integrate massive security solutions at both companies? Find out now, not later, and obtain the funding you need to get it done.

At the same time, educate yourself on the relative security postures of the two companies, and seek to strengthen your overall posture where needed. Incoming business units often push back on requests for funding, and the security team at the acquiring company must be prepared. The best way is to be backed up by the right corporate policies and directives that reinforce security standards and put the burden on the acquiring company to ensure compliance. Lacking this leverage, the security team has very little leverage to get the business units to spend money.

Wielding emotional intelligence to keep productivity on track

Acquisitions are a time of heightened emotions, and morale can be sharply affected, particularly at the company being acquired. Simultaneously, the security program integrations that acquisitions entail often expose new, temporary security vulnerabilities.

The most success with positive morale and productivity occurs when both companies are intentional about understanding each other’s position. The acquiring company succeeds with diplomacy, helping the new teammates understand the WHY of certain changes rather than just steamrolling in to implement them. Including this “why” perspective will help prioritize integration activities with minimal disruption in a sometimes-fragile transition.

Meanwhile, the acquired company succeeds by finding power in its more modest position, showing up in good faith, knowing its questions will be heard and answered.

Correlation area #2: Technology and infrastructure

The nuts and bolts of merging security at two companies often come down to how you’ll overlay the tech components — primarily your access control and video surveillance platforms, but also the other systems, platforms, applications, network appliances and other technologies that support security at your sites. It also helps to have the annual costs of operating your security program ready to share, as you might discover opportunities for savings as you go along, such as lowering operating costs by eliminating redundant server resources and application licenses.

Ultimately, your goal is to retrofit and standardize systems across two — or sometimes more — environments. In the course of doing this, you’re likely to uncover gaps and mismatched elements that will take time and money to fix. In some cases, the whole platform at your company or the one you’re acquiring might be so close to end-of-life that the acquisition is actually a chance to wipe the slate clean and start over. Make sure your M&A committee understands the importance and nuances of your concerns and has visibility and clarity on your proposed approach.

Correlation area #3: People and roles

Role redundancy is usually what people fear most when they hear their company is undergoing M&A. The axe can fall pretty hard in some acquisitions, depending on how similar the roles and procedures are in each environment. Security is no exception. As soon as you can, you’ll want to carefully document teams, roles, duties and job descriptions at both companies to check for overlaps and gaps.

But don’t make assumptions too fast. You won’t know exactly how many people are needed until you’re crystal clear on the direction your new roadmap is taking. In some cases, so-called redundant personnel can be retrained, reassigned or even promoted based on revisions you make to integrate operations.

Use your voice on the M&A committee to make your personnel expectations clear. No matter the outcome, you’ll benefit from having a clear sense of each company’s security team and how their methods of providing security services compare.

Correlation area #4: Culture

Security culture is a vital consideration for acclimating newly merged companies to one another. The characteristics of a company’s culture drive the way it does business, and when one company acquires another, those cultures have the potential to clash.

Some large companies have been so stung by this reality they’ve made cultural association a deciding factor over others in whether to acquire a company or to alternatively continue growing some other way.

At companies that acquire or are acquired, these culture clashes can impact a physical security program in various ways. Users at smaller companies acquired by larger ones sometimes feel like “Big Brother” is watching them, whereas they formerly operated with less electronic oversight. If the security team at an acquired company has less sophisticated platforms and processes, they can feel overwhelmed by the need to upgrade both and adjust their approach. Change management is essential for addressing these issues and providing a unified security culture at the resulting merged company that everyone feels a part of.

Navigating security culture differences

Acquired companies often feel bombarded with integration requirements, including many that don’t match up with the security culture they’re accustomed to.

To help ease these differences, enable the business, and reduce the stress of change, both companies’ integration teams should ensure security leadership from both sides is engaged, not just the acquiring company, while helping the security team itself adjust to the increased risks it often faces as part of becoming a larger brand or differently focused operation.

Preparing for the scenarios ahead

Budget, technology, people and culture provide the foundation for aligning security programs during acquisitional growth. However, the way these areas are addressed will depend on where the organization is in the acquisition process. A company preparing for possible growth will face different priorities than one responding to an acquisition already underway or managing acquisitions as an ongoing part of its business.

Every IT leader knows the pattern. One team builds a report in a spreadsheet. Another spins up a workflow with slightly different logic to answer the same question. A dashboard is shared across three departments, and within a week, nobody can say for certain where the underlying numbers came from. 

Instead of freeing up capacity, self-service has quietly become another form of manual work: chasing down mystery logic, reconciling duplicated effort, and answering questions nobody wants to own. 

Self-service was never the risk 

It is tempting to read that scenario as an argument for tighter control — fewer people building, more requests routed through a central team, more approvals before anything ships. That reaction is understandable, but it solves the wrong problem. 

Self-service fails when there are no shared rules for access, quality, documentation, and ownership. Without those guardrails, speed doesn’t produce faster decisions, just more confusion distributed across spreadsheets and more shared drives. 

The real tension is that most organizations have been offered only two options. Either lock everything down, or let everyone build whatever they want and hope it holds together. Neither one scales. 

IT as the paved road, not the checkpoint 

Centralizing data was never the hard part. The real challenge is the last mile: turning that data into decisions and actions the business can actually trust. Closing that gap does not mean IT owns every rule, calculation, and exception that determines how work gets done. 

It means IT builds the paved road — trusted access, approved workflows, reusable templates, and visibility into what is being built — while the people closest to the work own and adapt the business logic that runs through it. 

That division of labor changes what “governance” means in practice. Instead of a gate every request has to pass through one at a time, governance becomes the infrastructure that keeps logic visible, understandable, repeatable, and auditable by design. When the fastest way to answer a question is also the most trusted way, analysts do not need to be talked into compliance, and IT does not need to inspect every workflow to know it will hold up. It is simply how the work gets done. 

Freedom and guardrails, together 

Governed self-service isn’t about choosing between speed and control, it’s about giving each side of the equation what it actually needs to trust the other. 

Governed self-service gives analysts: 

• Access to trusted data 

• Reusable templates and workflow patterns 

• Clear rules for sharing and automation 

• A way to document logic 

• Support when a workflow needs to scale 

And it gives IT: 

• Visibility into who is building what 

• Better governance over access and data use 

• Fewer one-off requests 

• Less mystery logic floating around the business 

• A cleaner path from individual workflow to team-wide process 

What this looks like in practice 

Papa Johns’ finance team offers a useful example of governed self-service in action. The team handles risk-sensitive, high-volume work — franchise billing, royalty calculations, aggregator commissions, and SOX-compliant period close — across a global, multi-currency franchise business. 

Historically, much of that logic lived in spreadsheets and disconnected tools, separate from the systems of record and hard to audit when workflows changed. 

Using Alteryx, Papa Johns rebuilt franchise billing and reconciliation as a governed workflow that runs directly against its Google BigQuery environment, so calculations execute where the data already lives rather than being copied out to another location. 

With Alteryx, complex calculations are visible, repeatable, and auditable. Finance users can ask natural language questions, such as comparing month-over-month figures, and receive immediate answers while also seeing how logic is applied. IT can support governance without becoming a bottleneck. 

The partnership between the business and IT was key to scaling success. Michael Wyant, VP of Enterprise Data and Corporate Solutions, and his team are responsible for governance and data pipelines. The finance team owns the business logic and can adapt it as requirements change. 

Each side owns the part of the problem it understands best. 

The result is a workflow that finance trusts, that IT can stand behind, and that scales as a template for other high-stakes processes across the business. That’s the kind of outcome that governed self-service is meant to produce. 

Fewer surprises, more trust 

None of this requires IT to slow analysts down or analysts to work around IT. When self-service is built on shared standards, analysts stop waiting on tickets, IT stops chasing down mystery logic, and the business gets answers that hold up the moment someone asks, “Where did this number come from?” 

Alteryx supports that model by giving business teams a governed way to build and adapt workflows themselves, while giving IT the visibility, controls, and security required to support it all at enterprise scale. 

The goal was never more control for control’s sake. It is fewer surprises, less rework, and more answers the business can actually trust. 

Ready to see what governed self-service could look like for your team? Explore the AI-Ready Starter Kits to get started. 

 To learn more, visit us here. 

There’s a scenario that plays out every day across the enterprise. A salesperson is about to close a major deal. They want to know what their commission will be. They type the question into ChatGPT or their favorite AI assistant. What comes back is a thoughtful, well-written explanation of how software companies typically structure sales compensation. 

The one thing it won’t tell them is what their commission will actually be if they close this specific deal. That gap between what AI can reason over and what it knows about your business is the defining challenge of enterprise AI adoption right now. 

I call it the logic layer. And without it, AI gives you impressive sounding outputs that are often disconnected from how your business runs. 

Why business logic lives with the analyst 

One of the more persistent myths in AI is that analysts are on the verge of becoming unnecessary. 

The reality is the opposite, and the logic layer is exactly why. 

In an AI-enabled enterprise, analysts become more essential because they are closest to the logic and context that governs the business. They know which definition of pipeline matters and which edge cases matter in audit, merchandising, finance, or marketing. 

I believe enterprises that succeed in the AI era will not be defined by how much AI they deploy but whether the people who understand the business own and control the intelligence that runs it. 

If that ownership defaults entirely to IT or to a vendor’s black box, companies risk scaling systems they cannot fully adapt or audit. Giving business teams the tools and mandate to own their logic is what makes the AI system trustworthy and responsive to how your business runs. 

That is why I see analysts as the architects of this next phase. 

What the logic layer looks like in practice 

Let me return to the commissions example, because it illustrates the concept precisely. Right now, when a salesperson needs to know their commission on a deal, they send a message to the commissions analyst. That analyst has their own spreadsheet — because comp plans change every quarter, with spiffs and special programs layered on top. They run the math manually and send back an answer. 

What if that same analyst built a simple, well-defined calculator that encoded their commission logic — the actual rules for your company, your plans, your programs — and connected it to the AI systems your salespeople are already using? Now when a rep asks what their commission will be on a specific deal, they get the right answer. Not a generic explanation of how commissions work. 

And here’s the compounding value: that same logic can then be used by the annual planning agent to model the operational cost implications of different comp plans. It can feed the scenario planning model that runs hundreds of simulations for financial planning. The analyst who built it enables an entire network of AI systems to act on accurate, business-specific logic. 

That’s the logic layer in practice: curated, purpose-built data assets and calculators that encapsulate how your business works, maintained by the people who understand it, deployable to every AI system that needs it. 

What the logic layer requires 

This is where I think most companies are still stuck. They’ve made the infrastructure investments. They have cloud data platforms and approved LLMs. But they’re asking those systems to do things they were never designed to do on their own. 

The logic layer requires three things: 

• Purpose-built data assets. A narrow, clean, well-defined data set that reflects how you actually measure a specific business process. 

• Encoded business logic. This is the part that lives in people’s heads right now — the policies, the edge cases, the context that makes data mean something. 

• The ability to update it. Nobody runs a business to keep it the same. The logic layer has to be something that domain experts can update when the business changes. 

A pragmatic path forward 

The good news is that you don’t have to wait for a perfect architecture before you start building a logic layer. 

Start with your highest-value, most-repeated business processes — the ones where an analyst is currently fielding the same questions week after week. These are the processes where encoding logic into a curated, AI-ready data asset delivers immediate, measurable value. 

Then, empower your analysts to own that encoding — not IT. Give them low-code tools to do the work, and the mandate to treat that encoded logic as a strategic asset they own and evolve as the business changes. 

This is also where leadership posture matters. 

I have said for a while that this should not be framed as a choice between business and IT. It is both. IT should set standards, manage infrastructure, establish security boundaries, and make approved AI capabilities available across the organization. But IT should not become the bottleneck for every piece of business logic the company needs to operationalize. 

If this feels familiar, it should. We have seen this pattern before in enterprise technology. Infrastructure and platforms matter. But the last mile, the part that turns capability into business value, always depends on the people closest to the work. 

AI is no different. 

The companies that get the most from AI will be the ones that treat it like an operating model. They will automate core workflows, curate the right data, and empower analysts and domain experts to define the logic that makes AI useful and generate answers the business can use. 

I recently had a chance to go deeper on these ideas on the Talking AI podcast. If you want to hear more of my thinking on the analyst’s evolving role, how the logic layer connects to agentic workflows, and why I think the next 18 months will be pivotal for getting this right, it’s worth a listen. 

 To learn more, visit us here. 

Every new frontier model release seems to spur a fresh round of doomsday articles. Just Google “the end of white-collar jobs,” and you’ll be bombarded with discourse on the end of modern work, the unraveling of the social contract between employees and organizations. 

What I don’t see anyone talking about, however, and what I believe is a far more productive conversation, is the opportunity for knowledge workers. 

Nobody understands critical business processes better than your line-of-business (LOB) employees. Not executives. Not IT. Not even the most advanced LLMs. These are your business analysts and RevOps professionals, your supply chain managers and finance leaders, and the employees whose expertise has been forged over decades. 

For an enterprise to become truly intelligent, these workers must be involved in how AI workflows are built and deployed. Their guiding hand is the only way AI can learn and truly understand your business. 

But what does this transition look like, and how can organizations start operationalizing AI in a meaningful way alongside knowledge workers? Let’s take a look. 

What enterprise intelligence requires 

Imagine walking your board through a set of financials and recommending specific actions. Then, in your next meeting, you walk everything back because your AI layer got the numbers wrong. 

There is no faster way to kill an AI initiative than by delivering wrong outputs. Without trust, the whole system falls apart. 

In our recent survey of 1,400 business and IT leaders, we found that while over 90% of organizations are using AI, only 28% trust it to support decision-making. As for how many organizations scaled their AI pilots into production, the number was just under 25%, suggesting a very strong correlation between trust and operationalization. 

An intelligent enterprise, then, is an organization that has trustworthy AI embedded across the business. 

At Alteryx, we say the results of any AI system must follow our VURA framework: an AI system and its outputs must be visible, understandable, repeatable, and auditable. In other words, two people need to be able to go to AI with a question and arrive at the same answer; anyone who uses AI in their workflows must be able to explain how their AI system arrived at that answer. 

Who’s responsible for operationalizing AI? 

Enterprise intelligence is about trustworthy AI deployed throughout key business processes, but who’s ultimately responsible for these AI systems and processes: IT teams or knowledge workers? 

Let’s say you want to use AI in your Sarbanes-Oxley process, e.g., your journal entries, revenue recognition, access controls, etc. Before IT can help you build a new AI workflow, IT must first understand your Sarbanes-Oxley process in great detail. Then, they have to code a tool your finance team can trust. 

It’s possible, sure. But creating this solution would take an inordinate amount of time. Then, when a new regulation comes along or you have an acquisition, the whole thing falls apart. You have to get back in line with IT to retune everything. 

Moreover, if your books don’t balance out or if you fall out of compliance, IT does not want to have that responsibility fall on them. You can see why ownership of AI systems and workflows must sit with LOB workers. They are the only ones with the expertise to ensure the veracity of AI’s outputs. They are the only ones who can successfully shape and define its logic and oversee its ongoing execution. 

Data is the fuel. Business logic is what keeps AI on course. 

Finally, there’s the question of data. We’ve all heard “bad inputs, bad outputs.” Seeing as I’m the CEO of a data analytics company, you might expect me to say that reliable data is the end-all, be-all when it comes to trustworthy AI outputs. 

And while it’s absolutely essential, it’s only the first step. 

Aggregating your enterprise data into a cloud data platform is immensely useful. All of that data becomes readily accessible. You gain a single source of truth across teams and workflows. But you can’t point your LLM at a cloud data platform and ask it to make sense of your data for a complex business process. 

Again, you need the people who understand these critical processes to guide your LLMs to interpret the right data in the right way. This is what will make your AI systems visible, understandable, repeatable, and auditable. Yes, you need clean, reliable data. But more than that, you need business logic around that data, and that can only come from your knowledge workers. 

The five pillars of enterprise intelligence 

At the highest level, enterprise intelligence rests on five core pillars: 

1. Trustworthy, transparent data 

2. Empowered business analysts 

3. Shared responsibility across the C-suite 

4. Cross-functional collaboration 

5. Leadership that evolves alongside AI 
    

Each pillar reinforces the same core idea: AI only becomes valuable when it’s grounded in reliable data, shaped by real business expertise, supported by executive ownership, and scaled across teams that can put it to work to improve their daily processes. 

Tap into the intelligence all around you 

As a business leader looking to build an intelligent enterprise, the most important questions you can ask are the ones around operationalizing AI in key business processes. What would it take for you to trust AI’s outputs? What would make AI-powered processes superior to your current ones? 

Once you have those answers, engage your LOB workers immediately. Give them ownership and autonomy. Rather than asking AI to replace them, lean into their intelligence. Let your knowledge workers use their expertise to amplify, shape, and govern AI. Their business mastery is what makes enterprise intelligence possible. 

 To learn more, visit us here. 

“You’re right,” the LLM says. “I was mistaken.” 

Have you ever read these words during an AI workflow? Nothing kills trust faster than incorrect outputs. It’s no wonder, then, that only a quarter of businesses today fully trust AI to support decision-making and forecasting. 

And yet, we know AI is business critical. Nine out of 10 businesses are using it; 64% say it’s powering innovation. 

So, how do you bridge the gap from experimentation to trustworthy deployment? How do you get verifiable, reproducible results from AI at scale? In this article, I’ll show you the framework that’s powering AI success for leading organizations. 

Why organizations still don’t trust AI 

We asked 1,400 IT and business leaders what their biggest barriers to success with AI workflows were. One in two (49%) said inaccurate or biased outputs; 38% said it was a reluctance to allow AI to make decisions without human oversight. 

Then, there was the data issue. Data readiness is an integral part of successful AI workflows. However, half of all organizations said they still faced poor quality or fragmented data. While you don’t need perfect data to start using LLMs, you absolutely need trustworthy data. 

VURA: The framework for trustworthy AI 

Closing this trust gap requires two things. First, organizations need a logic layer that connects AI systems to the people who understand the data and business best. Line-of-business teams and analysts cannot sit on the sidelines. They need to help build and validate AI workflows so the logic behind AI’s outputs reflects how the business actually operates. 

Second, AI workflows and processes should be visible, understandable, repeatable, and auditable. Together, these principles form VURA, a framework we developed to help organizations build and scale trustworthy AI systems. These guidelines will help build trust in your data and your AI’s outputs. You’ll need both if you want your business to build enterprise intelligence. What follows are the four pillars of VURA.  

• Visible 

Visibility is transparency. Your AI workflows shouldn’t be a black box regarding the data used and the logic applied. Every employee using AI tools should be able to answer two questions: “Where did this answer come from?” and “How did we draw that conclusion?” Otherwise, employees may be working from incorrect information. They could give your customers faulty intel or make important decisions with serious downstream effects. 

If those answers are still unclear, you may need to tighten your governance or reconsider whether your current AI and data solutions are working. Visibility becomes especially important when AI is used across teams. 

• Understandable 

It can almost feel like science fiction when tools like ChatGPT or Gemini take the most complicated or vague of prompts, parse through them, and give you an intelligent, thoughtful answer. 

However, this low threshold for asking and answering virtually any question in natural language isn’t an excuse for glossing over business fundamentals. Your AI systems must be able to explain the logic behind their outputs to even non-technical business users, and your business experts must be able to validate those outputs. 

• Repeatable 

Repeatable means that with the same AI tools, data, prompts, and business logic, AI will give you the same answer every time. Two people should be able to go to AI with the same question and arrive at the same answer. If an AI system or workflow gives you an excellent answer followed by one that’s clearly wrong, it’s not ready for operationalization. You can’t trust it. 

Repeatability also requires documentation. When teams identify prompts or processes that help produce reliable outcomes, those should be recorded and shared. 

• Auditable 

An auditable AI process means you can see what happened. There’s a trail. If there’s an answer or report that seems off, you should be able to identify who owns the workflow, what data and prompts were used, what logic the system followed, and where human judgment and oversight were involved. Auditability is a check and balance for both your AI systems and the human engineers working behind the scenes. 

Start building trustworthy AI systems today 

AI can only deliver scalable business value when it’s grounded in trustworthy data and business logic. To operationalize these systems, you’ll have to ensure your AI workflows are visible, understandable, repeatable, and auditable. 

Alteryx is the transformation and business logic layer that helps you move AI from experimental pilots to trustworthy production. It connects to data wherever it lives, helps business users apply their expertise to AI-powered workflows, and instills the guardrails needed for both your data and your AI systems. 

With Alteryx, the people closest to the business can shape how data is prepared and applied, while IT gains the governance and auditability required for enterprise use. That’s how AI outcomes become trustworthy. That’s how enterprise intelligence is built. 

 To learn more, visit us here.