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.

Among a range of factors leading to a wave of tech sector layoffs in 2026 is the rapid rise of artificial intelligence and automation. Companies are reconfiguring their workforces to leverage AI for increased efficiency and reduced operating costs. This realignment and reduction is implemented even by companies reporting strong financial performance.

But it’s not just AI leading to workforce cuts. Complementing this technological shift are ongoing economic uncertainty, inflation, and higher interest rates, compounded by a chip shortage and rising energy costs. This mix is driving companies to cut costs and streamline operations for increased efficiency.

According to data compiled by Layoffs.fyi, an online tracker that keep tabs on job losses in the technology sector, 123,941 tech employees were laid off at 269 companies in 2025. The site also reports that 71,981 government employees were laid off by DOGE alone, with 182,528 total federal workers laid off.

Here is a list — to be updated regularly — of some of the most prominent technology layoffs the industry has experienced recently.

Notable tech layoffs in 2026

• Monday.com
• Microsoft
• Meta
• Cisco
• Cloudflare
• Oracle
• Atlassian
• Salesforce
• Amazon
• Ericsson

July 22, 2026: Monday.com cuts 20% of its workforce to restructure for the AI era

The company says the decision to cut 620 jobs isn’t about margins, but about creating a flatter organization built around AI agents, autonomous teams, and deeper customer engagement.

July 6, 2026: Microsoft cuts 4,800 jobs, primarily in sales and Xbox teams

As the company trims thousands of jobs, it’s also investing in embedded engineering teams and AI infrastructure. The layoffs come several weeks after the company offered 8,750 US employees voluntary retirement buyouts.

June 5, 2026: Tech industry cut 38,242 jobs in May, worst since 2024

AI was blamed for 40% of the job cuts in May, up from 7% in January, according to research by employment placement company Challenger, Gray & Christmas.

May 20, 2026: Meta cuts 8,000 jobs, around 10% of workforce

The cuts are expected to expected to hit Meta’s engineering and product teams the hardest, arriving as Meta pivots toward AI to boost efficiency across its organization, according to Yahoo Tech.

May 13, 2026: Cisco to cut nearly 4,000 jobs despite strong growth in AI, enterprise networking

Despite reporting positive financial news — including record third-quarter revenue of $15.8 billion, a 12% year-over-year increase — Cisco said it will eliminate almost 4,000 jobs.

May 7, 2026: Cloudflare to cut 1,100 jobs in AI-focused restructuring

About 20% of Cloudflare’s global workforce will be culled as the company pivots for the agentic AI era, Reuters reported.

April 1, 2026: Oracle to cut up to 30,000 jobs globally, putting enterprise support and roadmaps at risk

Oracle began laying off employees on March 31 in what could be the largest workforce reduction in the company’s history. Employees received termination emails at 6 a.m. local time with immediate system lockouts and no prior warning. (Note: in June, CNBC put the final layoff tally at 21,000.)

March 12, 2026: Atlassian cuts 1,600 jobs to fund AI and enterprise expansion

Atlassian will reduce its global workforce by approximately 10%, eliminating around 1,600 roles, as the collaboration software maker redirects capital toward artificial intelligence development and enterprise sales.

March 11, 2026: Tech layoffs surpass 45,000 in early 2026

A recent analysis by RationalFX found 45,363 job cuts globally so far this year—with roughly 68% or more than 30,000 occurring in the U.S. — highlighting ongoing workforce cuts even as many tech companies report strong revenue growth.

February 10, 2026: Salesforce lays off staffers as executive leadership churn continues

Salesforce has reduced close to 1,000 roles earlier this month across teams, including marketing, product management, data analytics, and its Agentforce AI unit, Business Insider reported, quoting employees familiar with the matter.

January 23, 2026: Amazon layoffs expected to disproportionately hit AWS and tech talent

As the market slows down, AWS and other Amazon units are preparing for another round of layoffs, which is expected to overwhelmingly impact tech talent. An email from HR leader Beth Galetti on Jan. 28 confirmed 16,000 job cuts.

January 15, 2026: Ericsson plans to shed 1,600 jobs in Sweden

 Ericsson lans to cut some 1,600 jobs in Sweden, the telecommunications equipment maker said doubling down on recent cost-saving measures that have helped it weather a prolonged downturn in telecoms spending, Reuters reports.

January 13, 2026: Meta plans to cut around 10% of employees in Reality Labs business

Meta plans to cut around 10% of the employees in its Reality Labs division who work on products including the metaverse, according to three people with knowledge of the discussions, according to The New York Times.

Layoffs in 2025

• Cisco
• Oracle
• Windsurf
• Intel
• Microsoft
• Crowdstrike
• HPE
• Autodesk
• HPE
• CISA
• Workday
• Salesforce
• Meta

Global tech-sector layoffs surpass 244,000 in 2025

Economic uncertainty, elevated interest rates, and AI adoption have driven workforce reductions across tech companies worldwide, according to a RationalFX report.

October 28, 2025: Amazon to cut 14,000 jobs across company

Amazon will reduce its overall workforce by 14,000, cutting layers of management across the company and hiring in some areas to support its “biggest bets”.

August 18, 2025: Cisco and Oracle to cut hundreds of Bay Area jobs

Tech companies Cisco and Oracle are cutting hundreds of jobs across the Bay Area. Cisco will eliminate 221 positions at its Milpitas and San Francisco offices, effective Oct. 13. Oracle is reducing 101 positions in Santa Clara on the same date 

August 5, 2025: 3 weeks after acquiring Windsurf, Cognition offers staff the exit door

Cognition, the AI coding startup that acquired rival company Windsurf three weeks ago, laid off 30 employees last week and is offering buyouts to the roughly 200 remaining employees on the team, reports The Information.

July 25, 2025, Intel to lay off 22% of workforce, CEO Tan signals ‘no more blank checks’

Intel will reduce its workforce to 75,000 employees by the end of 2025 as new CEO Lip-Bu Tan implements sweeping changes designed to transform the struggling chipmaker

July 8, 2025, Intel layoffs begin: Chipmaker is cutting many thousands of jobs

Intel has begun laying off employees across the company. CEO Lip-Bu Tan told workers back in April to expect major layoffs at Intel in the coming months as the chipmaker slashes costs and overhauls its organization after years of technical setbacks and falling sales.

July 2, 2025: Microsoft will cut 9,000 workers

Microsoft will lay off about 9,000 employees, a source familiar with the workforce cut told CNBC.  The cuts will reportedly affect less than 4% of Microsoft’s global workforce and will impact different teams, geographies and levels of experience. This is the latest in a string of cuts the tech giant has made this year.

June 17, 2025: Intel looks to factory layoffs to return to profitability

Intel will lay off up to 20% of its manufacturing sector employees starting in July, according to media reports, as the company looks for options as it seeks a return to profitability. The cuts reportedly will be made around the world, but some of the layoffs will be closer to home, according to a report in The Oregonian citing an internal company memo from Intel manufacturing Vice President Naga Chandrasekaran.

May 7, 2025: CrowdStrike to lay off 5% of staff

CrowdStrike announced a plan to cut about 500 roles, roughly 5% of its workforce, to streamline operations and reduce costs. The cybersecurity company will incur about $36 million to $53 million in charges related to the layoffs

March 6, 2025: HPE cuts 2,500 jobs, remains committed to Juniper buy

CEO Antonio Neri told Wall Street analysts that HPE would begin implementing a cost-cutting program involving layoffs of about 2,500 employees over the next 18 months. HPE employs about 61,000 people worldwide.

Feb. 27, 2025: Autodesk to lay off 9% of workforce

Software maker Autodesk is laying off 1,350 staff. With the rise of subscription and multi-year contracts billed annually, and self-service enablement, it finds it needs fewer sales staff, CEO Andrew Anagnost said in a message to employees. And with its cloud, platform, and AI products proving most profitable, it’s concentrating its staff and investments there.

Feb. 27, 2025: HP to lay off 2,000 more

As part of an ongoing restructuring, HP plans to lay off up to another 2,000 workers. In recent weeks, the company has tried — unsuccessfully — to do away with telephone support staff by forcing callers to wait for at least 15 minutes if they refuse to use self-service support resources online. The company swiftly backtracked, but wider job cuts are still on.

Feb. 21, 2025: CISA lays off 130

Government employees get laid off too: In this case, 130 workers at the US Cybersecurity and Infrastructure Security Agency are being shown the door as a result of a DOGE decision. Cybersecurity experts are concerned that the cuts will harm the international collaborations that CISA has fostered, quite apart from their concerns about the security of the DOGE layoff process itself.

Feb. 5, 2025: Workday lays off 1,750

As it moves to invest more in AI and international growth, Workday is laying off 8.5% of its workforce and disposing of unused office space. Some analysts fear the cutbacks will affect the company’s customer service — unless AI can pick up the slack.

Feb. 4, 2025: Salesforce lays off over 1,000

At the same time as it’s hiring sales staff for its new artificial intelligence products, Salesforce is laying off over 1,000 workers across the company, according to Bloomberg. As of June, 2024, the company had over 72,000 employees, according to its website. Salesforce did not comment on the report. In 2024 the company reportedly laid off around 1,000 staff too, in two waves: January and July.

Jan. 14, 2025: Meta will lay off 5% of workforce

Mark Zuckerberg told Meta employees he intended to “move out the low performers faster” in an internal memo reported by Bloomberg. The memo announced that the company will lay off 5% of its staff, or around 3,600 staff, beginning Feb. 10. The company had already reduced its headcount by 5% in 2024 through natural attrition, the memo said. Among those leaving the company will be staff previously responsible for fact checking of posts on its social media platforms in the US, as the company begins relying on its users to police content.

Tech layoffs in 2024

• Equinix
• AMD
• Freshworks
• Cisco
• General Motors
• Intel
• OpenText
• Microsoft
• AWS
• Dell

Nov. 26, 2024: Equinix to cut 3% of staff

Despite intense demand for its data center capacity, Equinix is planning to lay off 3% of its workforce, or around 400 employees. The announcement followed the appointment of Adaire Fox-Martin to replace Charles Meyers as CEO and the departures of two other senior executives, CIO Milind Wagle and CISO Michael Montoya.

Nov. 13, 2024: AMD to cut 4% of workforce

AMD will lay off around 1,000 employees as it pivots towards developing AI-focused chips, it said. The move came as a surprise to staff, as the company also reported strong quarterly earnings.

Nov. 7, 2024: Freshworks lays off 660

Enterprise software vendor Freshworks laid off around 660 staff, or around 13% of its headcount, despite reporting increased revenue and profits in its fourth fiscal quarter. The company described the layoffs as a realignment of its global workforce.

Sept. 17, 2024: Cisco lays off 6,000

After laying off around 4,200 staff in February, Cisco is at it again, laying off another 6,000 or around 7% of its workforce. Among the divisions affected were its threat intelligence unit, Talos Security.

Aug. 20, 2024: General Motors lays off 1,000 software staff

More than 1,000 software and services staff are on the way out at General Motors, signalling that it could be rethinking its digital transformation strategy. In an internal memo, the company said that it was moving resources to its highest-priority work and flattening hierarchies.

August 1, 2024: Intel removes 15,000 roles

Intel plans to cut its workforce by around 15% to reduce costs after a disastrous second quarter. Revenue for the three months to June 29 stagnated at around $12.8 billion, but net income fell 85% to $83 million, prompting CEO Pat Gelsinger to bring forward a company-wide meeting in order to announce that 15,000 staff would lose their jobs. “This is an incredibly hard day for Intel as we are making some of the most consequential changes in our company’s history,” Gelsinger wrote in an email to staff, continuing: “Our revenues have not grown as expected — and we’ve yet to fully benefit from powerful trends, like AI. Our costs are too high, our margins are too low. We need bolder actions to address both — particularly given our financial results and outlook for the second half of 2024, which is tougher than previously expected.”

July 4, 2024: OpenText to lay off 1,200

OpenText said it will lay off 1,200 staff, or about 1.7% of its workforce, in a bid to save around $100 million annually. It plans to hire new sales and engineering staff in other areas in 2025, it said.

June 4, 2024: Microsoft lays off staff in Azure division

Microsoft laid off staff in several teams supporting its cloud services, including Azure for Operations and Mission Engineering. The company didn’t say exactly how many staff were leaving.

April 4, 2024: Amazon downsizes AWS in a fresh cost-cutting round

Amazon announced hundreds of layoffs in the sales and marketing teams of its AWS cloud services division — and also in the technology development teams for its physical retail stores, as it stepped back from efforts to generalize the “Just Walk Out” technology built for its Amazon Fresh grocery stores.

April 1, 2024: Dell acknowledges 13,000 job cuts

Dell Technologies’ latest 10K filing with the US Securities and Exchange Commission disclosed that the company had laid off 13,000 employees over the course of the 2023 fiscal year; it characterized the layoffs and other reorganizational moves as cost-cutting measures. “These actions resulted in a reduction in our overall headcount,” the company said. A comparison to the previous year’s 10K filing, performed by The Register, found that Dell employed 133,000 people at that point, compared to 120,000 as of February 2024. Dell announced layoffs of 6,650 staffers on Feb. 6, but it is unclear whether those cuts were reflected in the numbers from this year’s 10K statement.

See news of earlier layoffs.

Traditional phishing techniques are in decline as a result of the disruption of the Tycoon2FA phishing-as-a-service (PHaaS) platform, Microsoft said in a new report, “Email threat landscape: Q2 2026 trends and insights”.

“Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs,” the company wrote in the report.

The takedown reduced activity across multiple phishing categories, forcing attackers to shift to newer delivery methods.

Riding this shift in were a few notable phishing campaigns, including an automated business email compromise (BEC) campaign that reached 42,000 organizations in under three hours, and a multi-stage phishing campaign that used nested email (EML) files, calendar invitations, and a Microsoft authentication redirect to deliver malware.

To counter phishing attacks, Microsoft recommends blocking emails containing known bad URLs/ subject fields, enabling password-less authentication methods, or moving to MFA for accounts that still require passwords.

Tycoon2FA disruption sent attackers exploring

The take-down of Tycoon2FA forced its operators to abandon portions of their infrastructure and rework hosting, domain registrations, and delivery mechanisms.

“After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year,” Microsoft said.

The decline extended to QR Code lures and fake CAPTCHA pages, two phishing techniques in which Tycoon2FA accounted for 12% and 14% of industry activity in June, respectively. This indicated that the platform’s customer base had not been able to migrate to a replacement infrastructure.

But cutting off one head of the hacker hydra only gave rise to new tactics elsewhere.

The adaptation came in the form of using Microsoft Teams as a social engineering channel. Attackers established conversations to build trust before attempting credential theft or delivering malicious payloads. “Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June,” Microsoft said.

Microsoft also observed a highly automated BEC campaign that reached over 67,000 users using scripted emails, Amazon Simple Email Service (SES), and engagement tracking, alongside a separate phishing campaign targeting 107,000 users that abused Microsoft’s authentication flow and trusted cloud services, including Teams archive recording and ICS calendar invite, to disguise malware delivery behind legitimate infrastructure.

Phishing changes but the defense doesn’t

While QR Code and Captcha-based phishing attacks dropped significantly in the second quarter, business email compromise (BEC) charted jumped 121% between March and April, before dropping down again in May.

QR Code phishing represented 8.3 million attacks in June 2026, down from a peak of 18.7 million in March. Similarly, Captcha-gated phishing fell from 12 million attacks in March to 2.2 million in June.

BEC attacks hit 9 million in March, falling to 3.9 million in June.

But even as these phishing classics lost momentum and newer techniques emerged, Microsoft’s defensive advice remained rooted in the basics. It noted organizations should complement email filtering with phishing-resistant authentication such as passkeys and phishing-resistant MFA to reduce the effectiveness of credential theft campaigns.

The company also recommended strengthening Exchange Online Protection and Microsoft Defender for Office 365 with capabilities such as Safe links and Zero-hour Auto Purge (ZAP), in which malicious emails already delivered to mailboxes are removed before they are read, alongside enforcing password-less authentication methods like Windows Hello, FIDO keys, and Microsoft Authenticator.

Microsoft concluded its report with a list of indicators of compromise (IoCs) from the threats observed in the quarter to support detection efforts.

This article first appeared on CSO.

Traditional phishing techniques are in decline as a result of the disruption of the Tycoon2FA phishing-as-a-service (PHaaS) platform, Microsoft said in a new report, “Email threat landscape: Q2 2026 trends and insights”.

“Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs,” the company wrote in the report.

The takedown reduced activity across multiple phishing categories, forcing attackers to shift to newer delivery methods.

Riding this shift in were a few notable phishing campaigns, including an automated business email compromise (BEC) campaign that reached 42,000 organizations in under three hours, and a multi-stage phishing campaign that used nested email (EML) files, calendar invitations, and a Microsoft authentication redirect to deliver malware.

To counter phishing attacks, Microsoft recommends blocking emails containing known bad URLs/ subject fields, enabling password-less authentication methods, or moving to MFA for accounts that still require passwords.

Tycoon2FA disruption sent attackers exploring

The take-down of Tycoon2FA forced its operators to abandon portions of their infrastructure and rework hosting, domain registrations, and delivery mechanisms.

“After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year,” Microsoft said.

The decline extended to QR Code lures and fake CAPTCHA pages, two phishing techniques in which Tycoon2FA accounted for 12% and 14% of industry activity in June, respectively. This indicated that the platform’s customer base had not been able to migrate to a replacement infrastructure.

But cutting off one head of the hacker hydra only gave rise to new tactics elsewhere.

The adaptation came in the form of using Microsoft Teams as a social engineering channel. Attackers established conversations to build trust before attempting credential theft or delivering malicious payloads. “Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June,” Microsoft said.

Microsoft also observed a highly automated BEC campaign that reached over 67,000 users using scripted emails, Amazon Simple Email Service (SES), and engagement tracking, alongside a separate phishing campaign targeting 107,000 users that abused Microsoft’s authentication flow and trusted cloud services, including Teams archive recording and ICS calendar invite, to disguise malware delivery behind legitimate infrastructure.

Phishing changes but the defense doesn’t

While QR Code and Captcha-based phishing attacks dropped significantly in the second quarter, business email compromise (BEC) charted jumped 121% between March and April, before dropping down again in May.

QR Code phishing represented 8.3 million attacks in June 2026, down from a peak of 18.7 million in March. Similarly, Captcha-gated phishing fell from 12 million attacks in March to 2.2 million in June.

BEC attacks hit 9 million in March, falling to 3.9 million in June.

But even as these phishing classics lost momentum and newer techniques emerged, Microsoft’s defensive advice remained rooted in the basics. It noted organizations should complement email filtering with phishing-resistant authentication such as passkeys and phishing-resistant MFA to reduce the effectiveness of credential theft campaigns.

The company also recommended strengthening Exchange Online Protection and Microsoft Defender for Office 365 with capabilities such as Safe links and Zero-hour Auto Purge (ZAP), in which malicious emails already delivered to mailboxes are removed before they are read, alongside enforcing password-less authentication methods like Windows Hello, FIDO keys, and Microsoft Authenticator.

Microsoft concluded its report with a list of indicators of compromise (IoCs) from the threats observed in the quarter to support detection efforts.

This article first appeared on CSO.

Traditional phishing techniques are in decline as a result of the disruption of the Tycoon2FA phishing-as-a-service (PHaaS) platform, Microsoft said in a new report, “Email threat landscape: Q2 2026 trends and insights”.

“Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs,” the company wrote in the report.

The takedown reduced activity across multiple phishing categories, forcing attackers to shift to newer delivery methods.

Riding this shift in were a few notable phishing campaigns, including an automated business email compromise (BEC) campaign that reached 42,000 organizations in under three hours, and a multi-stage phishing campaign that used nested email (EML) files, calendar invitations, and a Microsoft authentication redirect to deliver malware.

To counter phishing attacks, Microsoft recommends blocking emails containing known bad URLs/ subject fields, enabling password-less authentication methods, or moving to MFA for accounts that still require passwords.

Tycoon2FA disruption sent attackers exploring

The take-down of Tycoon2FA forced its operators to abandon portions of their infrastructure and rework hosting, domain registrations, and delivery mechanisms.

“After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year,” Microsoft said.

The decline extended to QR Code lures and fake CAPTCHA pages, two phishing techniques in which Tycoon2FA accounted for 12% and 14% of industry activity in June, respectively. This indicated that the platform’s customer base had not been able to migrate to a replacement infrastructure.

But cutting off one head of the hacker hydra only gave rise to new tactics elsewhere.

The adaptation came in the form of using Microsoft Teams as a social engineering channel. Attackers established conversations to build trust before attempting credential theft or delivering malicious payloads. “Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June,” Microsoft said.

Microsoft also observed a highly automated BEC campaign that reached over 67,000 users using scripted emails, Amazon Simple Email Service (SES), and engagement tracking, alongside a separate phishing campaign targeting 107,000 users that abused Microsoft’s authentication flow and trusted cloud services, including Teams archive recording and ICS calendar invite, to disguise malware delivery behind legitimate infrastructure.

Phishing changes but the defense doesn’t

While QR Code and Captcha-based phishing attacks dropped significantly in the second quarter, business email compromise (BEC) charted jumped 121% between March and April, before dropping down again in May.

QR Code phishing represented 8.3 million attacks in June 2026, down from a peak of 18.7 million in March. Similarly, Captcha-gated phishing fell from 12 million attacks in March to 2.2 million in June.

BEC attacks hit 9 million in March, falling to 3.9 million in June.

But even as these phishing classics lost momentum and newer techniques emerged, Microsoft’s defensive advice remained rooted in the basics. It noted organizations should complement email filtering with phishing-resistant authentication such as passkeys and phishing-resistant MFA to reduce the effectiveness of credential theft campaigns.

The company also recommended strengthening Exchange Online Protection and Microsoft Defender for Office 365 with capabilities such as Safe links and Zero-hour Auto Purge (ZAP), in which malicious emails already delivered to mailboxes are removed before they are read, alongside enforcing password-less authentication methods like Windows Hello, FIDO keys, and Microsoft Authenticator.

Microsoft concluded its report with a list of indicators of compromise (IoCs) from the threats observed in the quarter to support detection efforts.

Among a range of factors leading to a wave of tech sector layoffs in 2026 is the rapid rise of artificial intelligence and automation. Companies are reconfiguring their workforces to leverage AI for increased efficiency and reduced operating costs. This realignment and reduction is implemented even by companies reporting strong financial performance.

But it’s not just AI leading to workforce cuts. Complementing this technological shift are ongoing economic uncertainty, inflation, and higher interest rates, compounded by a chip shortage and rising energy costs. This mix is driving companies to cut costs and streamline operations for increased efficiency.

According to data compiled by Layoffs.fyi, an online tracker that keep tabs on job losses in the technology sector, 123,941 tech employees were laid off at 269 companies in 2025. The site also reports that 71,981 government employees were laid off by DOGE alone, with 182,528 total federal workers laid off.

Here is a list — to be updated regularly — of some of the most prominent technology layoffs the industry has experienced recently.

Notable tech layoffs in 2026

• Monday.com
• Microsoft
• Meta
• Cisco
• Cloudflare
• Oracle
• Atlassian
• Salesforce
• Amazon
• Ericsson

July 22, 2026: Monday.com cuts 20% of its workforce to restructure for the AI era

The company says the decision to cut 620 jobs isn’t about margins, but about creating a flatter organization built around AI agents, autonomous teams, and deeper customer engagement.

July 6, 2026: Microsoft cuts 4,800 jobs, primarily in sales and Xbox teams

As the company trims thousands of jobs, it’s also investing in embedded engineering teams and AI infrastructure. The layoffs come several weeks after the company offered 8,750 US employees voluntary retirement buyouts.

June 5, 2026: Tech industry cut 38,242 jobs in May, worst since 2024

AI was blamed for 40% of the job cuts in May, up from 7% in January, according to research by employment placement company Challenger, Gray & Christmas.

May 20, 2026: Meta cuts 8,000 jobs, around 10% of workforce

The cuts are expected to expected to hit Meta’s engineering and product teams the hardest, arriving as Meta pivots toward AI to boost efficiency across its organization, according to Yahoo Tech.

May 13, 2026: Cisco to cut nearly 4,000 jobs despite strong growth in AI, enterprise networking

Despite reporting positive financial news — including record third-quarter revenue of $15.8 billion, a 12% year-over-year increase — Cisco said it will eliminate almost 4,000 jobs.

May 7, 2026: Cloudflare to cut 1,100 jobs in AI-focused restructuring

About 20% of Cloudflare’s global workforce will be culled as the company pivots for the agentic AI era, Reuters reported.

April 1, 2026: Oracle to cut up to 30,000 jobs globally, putting enterprise support and roadmaps at risk

Oracle began laying off employees on March 31 in what could be the largest workforce reduction in the company’s history. Employees received termination emails at 6 a.m. local time with immediate system lockouts and no prior warning. (Note: in June, CNBC put the final layoff tally at 21,000.)

March 12, 2026: Atlassian cuts 1,600 jobs to fund AI and enterprise expansion

Atlassian will reduce its global workforce by approximately 10%, eliminating around 1,600 roles, as the collaboration software maker redirects capital toward artificial intelligence development and enterprise sales.

March 11, 2026: Tech layoffs surpass 45,000 in early 2026

A recent analysis by RationalFX found 45,363 job cuts globally so far this year—with roughly 68% or more than 30,000 occurring in the U.S. — highlighting ongoing workforce cuts even as many tech companies report strong revenue growth.

February 10, 2026: Salesforce lays off staffers as executive leadership churn continues

Salesforce has reduced close to 1,000 roles earlier this month across teams, including marketing, product management, data analytics, and its Agentforce AI unit, Business Insider reported, quoting employees familiar with the matter.

January 23, 2026: Amazon layoffs expected to disproportionately hit AWS and tech talent

As the market slows down, AWS and other Amazon units are preparing for another round of layoffs, which is expected to overwhelmingly impact tech talent. An email from HR leader Beth Galetti on Jan. 28 confirmed 16,000 job cuts.

January 15, 2026: Ericsson plans to shed 1,600 jobs in Sweden

 Ericsson lans to cut some 1,600 jobs in Sweden, the telecommunications equipment maker said doubling down on recent cost-saving measures that have helped it weather a prolonged downturn in telecoms spending, Reuters reports.

January 13, 2026: Meta plans to cut around 10% of employees in Reality Labs business

Meta plans to cut around 10% of the employees in its Reality Labs division who work on products including the metaverse, according to three people with knowledge of the discussions, according to The New York Times.

Layoffs in 2025

• Cisco
• Oracle
• Windsurf
• Intel
• Microsoft
• Crowdstrike
• HPE
• Autodesk
• HPE
• CISA
• Workday
• Salesforce
• Meta

Global tech-sector layoffs surpass 244,000 in 2025

Economic uncertainty, elevated interest rates, and AI adoption have driven workforce reductions across tech companies worldwide, according to a RationalFX report.

October 28, 2025: Amazon to cut 14,000 jobs across company

Amazon will reduce its overall workforce by 14,000, cutting layers of management across the company and hiring in some areas to support its “biggest bets”.

August 18, 2025: Cisco and Oracle to cut hundreds of Bay Area jobs

Tech companies Cisco and Oracle are cutting hundreds of jobs across the Bay Area. Cisco will eliminate 221 positions at its Milpitas and San Francisco offices, effective Oct. 13. Oracle is reducing 101 positions in Santa Clara on the same date 

August 5, 2025: 3 weeks after acquiring Windsurf, Cognition offers staff the exit door

Cognition, the AI coding startup that acquired rival company Windsurf three weeks ago, laid off 30 employees last week and is offering buyouts to the roughly 200 remaining employees on the team, reports The Information.

July 25, 2025, Intel to lay off 22% of workforce, CEO Tan signals ‘no more blank checks’

Intel will reduce its workforce to 75,000 employees by the end of 2025 as new CEO Lip-Bu Tan implements sweeping changes designed to transform the struggling chipmaker

July 8, 2025, Intel layoffs begin: Chipmaker is cutting many thousands of jobs

Intel has begun laying off employees across the company. CEO Lip-Bu Tan told workers back in April to expect major layoffs at Intel in the coming months as the chipmaker slashes costs and overhauls its organization after years of technical setbacks and falling sales.

July 2, 2025: Microsoft will cut 9,000 workers

Microsoft will lay off about 9,000 employees, a source familiar with the workforce cut told CNBC.  The cuts will reportedly affect less than 4% of Microsoft’s global workforce and will impact different teams, geographies and levels of experience. This is the latest in a string of cuts the tech giant has made this year.

June 17, 2025: Intel looks to factory layoffs to return to profitability

Intel will lay off up to 20% of its manufacturing sector employees starting in July, according to media reports, as the company looks for options as it seeks a return to profitability. The cuts reportedly will be made around the world, but some of the layoffs will be closer to home, according to a report in The Oregonian citing an internal company memo from Intel manufacturing Vice President Naga Chandrasekaran.

May 7, 2025: CrowdStrike to lay off 5% of staff

CrowdStrike announced a plan to cut about 500 roles, roughly 5% of its workforce, to streamline operations and reduce costs. The cybersecurity company will incur about $36 million to $53 million in charges related to the layoffs

March 6, 2025: HPE cuts 2,500 jobs, remains committed to Juniper buy

CEO Antonio Neri told Wall Street analysts that HPE would begin implementing a cost-cutting program involving layoffs of about 2,500 employees over the next 18 months. HPE employs about 61,000 people worldwide.

Feb. 27, 2025: Autodesk to lay off 9% of workforce

Software maker Autodesk is laying off 1,350 staff. With the rise of subscription and multi-year contracts billed annually, and self-service enablement, it finds it needs fewer sales staff, CEO Andrew Anagnost said in a message to employees. And with its cloud, platform, and AI products proving most profitable, it’s concentrating its staff and investments there.

Feb. 27, 2025: HP to lay off 2,000 more

As part of an ongoing restructuring, HP plans to lay off up to another 2,000 workers. In recent weeks, the company has tried — unsuccessfully — to do away with telephone support staff by forcing callers to wait for at least 15 minutes if they refuse to use self-service support resources online. The company swiftly backtracked, but wider job cuts are still on.

Feb. 21, 2025: CISA lays off 130

Government employees get laid off too: In this case, 130 workers at the US Cybersecurity and Infrastructure Security Agency are being shown the door as a result of a DOGE decision. Cybersecurity experts are concerned that the cuts will harm the international collaborations that CISA has fostered, quite apart from their concerns about the security of the DOGE layoff process itself.

Feb. 5, 2025: Workday lays off 1,750

As it moves to invest more in AI and international growth, Workday is laying off 8.5% of its workforce and disposing of unused office space. Some analysts fear the cutbacks will affect the company’s customer service — unless AI can pick up the slack.

Feb. 4, 2025: Salesforce lays off over 1,000

At the same time as it’s hiring sales staff for its new artificial intelligence products, Salesforce is laying off over 1,000 workers across the company, according to Bloomberg. As of June, 2024, the company had over 72,000 employees, according to its website. Salesforce did not comment on the report. In 2024 the company reportedly laid off around 1,000 staff too, in two waves: January and July.

Jan. 14, 2025: Meta will lay off 5% of workforce

Mark Zuckerberg told Meta employees he intended to “move out the low performers faster” in an internal memo reported by Bloomberg. The memo announced that the company will lay off 5% of its staff, or around 3,600 staff, beginning Feb. 10. The company had already reduced its headcount by 5% in 2024 through natural attrition, the memo said. Among those leaving the company will be staff previously responsible for fact checking of posts on its social media platforms in the US, as the company begins relying on its users to police content.

Tech layoffs in 2024

• Equinix
• AMD
• Freshworks
• Cisco
• General Motors
• Intel
• OpenText
• Microsoft
• AWS
• Dell

Nov. 26, 2024: Equinix to cut 3% of staff

Despite intense demand for its data center capacity, Equinix is planning to lay off 3% of its workforce, or around 400 employees. The announcement followed the appointment of Adaire Fox-Martin to replace Charles Meyers as CEO and the departures of two other senior executives, CIO Milind Wagle and CISO Michael Montoya.

Nov. 13, 2024: AMD to cut 4% of workforce

AMD will lay off around 1,000 employees as it pivots towards developing AI-focused chips, it said. The move came as a surprise to staff, as the company also reported strong quarterly earnings.

Nov. 7, 2024: Freshworks lays off 660

Enterprise software vendor Freshworks laid off around 660 staff, or around 13% of its headcount, despite reporting increased revenue and profits in its fourth fiscal quarter. The company described the layoffs as a realignment of its global workforce.

Sept. 17, 2024: Cisco lays off 6,000

After laying off around 4,200 staff in February, Cisco is at it again, laying off another 6,000 or around 7% of its workforce. Among the divisions affected were its threat intelligence unit, Talos Security.

Aug. 20, 2024: General Motors lays off 1,000 software staff

More than 1,000 software and services staff are on the way out at General Motors, signalling that it could be rethinking its digital transformation strategy. In an internal memo, the company said that it was moving resources to its highest-priority work and flattening hierarchies.

August 1, 2024: Intel removes 15,000 roles

Intel plans to cut its workforce by around 15% to reduce costs after a disastrous second quarter. Revenue for the three months to June 29 stagnated at around $12.8 billion, but net income fell 85% to $83 million, prompting CEO Pat Gelsinger to bring forward a company-wide meeting in order to announce that 15,000 staff would lose their jobs. “This is an incredibly hard day for Intel as we are making some of the most consequential changes in our company’s history,” Gelsinger wrote in an email to staff, continuing: “Our revenues have not grown as expected — and we’ve yet to fully benefit from powerful trends, like AI. Our costs are too high, our margins are too low. We need bolder actions to address both — particularly given our financial results and outlook for the second half of 2024, which is tougher than previously expected.”

July 4, 2024: OpenText to lay off 1,200

OpenText said it will lay off 1,200 staff, or about 1.7% of its workforce, in a bid to save around $100 million annually. It plans to hire new sales and engineering staff in other areas in 2025, it said.

June 4, 2024: Microsoft lays off staff in Azure division

Microsoft laid off staff in several teams supporting its cloud services, including Azure for Operations and Mission Engineering. The company didn’t say exactly how many staff were leaving.

April 4, 2024: Amazon downsizes AWS in a fresh cost-cutting round

Amazon announced hundreds of layoffs in the sales and marketing teams of its AWS cloud services division — and also in the technology development teams for its physical retail stores, as it stepped back from efforts to generalize the “Just Walk Out” technology built for its Amazon Fresh grocery stores.

April 1, 2024: Dell acknowledges 13,000 job cuts

Dell Technologies’ latest 10K filing with the US Securities and Exchange Commission disclosed that the company had laid off 13,000 employees over the course of the 2023 fiscal year; it characterized the layoffs and other reorganizational moves as cost-cutting measures. “These actions resulted in a reduction in our overall headcount,” the company said. A comparison to the previous year’s 10K filing, performed by The Register, found that Dell employed 133,000 people at that point, compared to 120,000 as of February 2024. Dell announced layoffs of 6,650 staffers on Feb. 6, but it is unclear whether those cuts were reflected in the numbers from this year’s 10K statement.

See news of earlier layoffs.

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.

Ever since Chinese AI startup DeepSeek launched three years ago, enterprise executives have been nervous about relying on Chinese AI models. 

But now that the latest Chinese AI offerings, Alibaba’s 2.4-trillion-parameter model Qwen3.8 Max and Moonshot’s 2.8-trillion-parameter model Kimi K3, are promising even more powerful performance, those IT executives are being forced to again ask if these models are worth using, even in a limited fashion.

Former Walmart head of risk Steven Eric Fisher, now an independent cybersecurity and risk advisor, thinks they should at least take another look.

“Enterprises should take these models seriously, but neither adopt nor reject them solely because they are Chinese,” he said. “They should be assessed like any other critical technology dependency: jurisdiction, ownership, training and software provenance, licensing, data handling, hosting, security, reliability, and the ability to independently test their behavior. Geopolitical exposure is a legitimate risk factor, but it should be incorporated into technical and supply-chain diligence rather than used as a substitute for it.”

Choose applications with care

He added, “Chinese models may be especially valuable for coding, multilingual processing, high-volume document analysis, research, synthetic-data generation, and privately operated security or forensic workflows, but they should be subject to task-specific testing rather than broad benchmark claims.”

Shashi Bellamkonda, principal research director at Info-Tech Research Group, agreed that the Chinese models can work well if they are only used in carefully chosen applications. 

“Although Moonshot’s K3 still trails Claude’s Fable 5 and GPT 5.6 Sol on performance and user experience, good companies that have governance and prompt guardrails will not face the instability and improvisation of [the Chinese] models,” he said. “These models will win in usage. US frontier models are leading as the best models, but Chinese models will be sufficient for high-volume, low-drama tasks that cost less for non-critical transactions.”

On the flipside, Bellamkonda suggested a variety of areas where enterprises should avoid Chinese AI models, including “customer-facing work without a human in the loop, regulated or sensitive data, and anything where a hallucinated answer creates legal or safety exposure. That is where the reliability gap and the political-radioactivity concern both bite, and where the closed American models still earn their premium.”

Bellamkonda said he didn’t see the differences in data reliability, mostly involving hallucination rates, as meaningful for enterprise AI strategy decisions.

“Every open-weight model in this class can get facts wrong or make things up. That is fixable with the right setup, so it is not a reason to avoid these models,” he said. “For high-volume tasks with clear limits, you feed the model your own trusted documents to answer from, and you keep a person checking the output. That combination is safe for production. The model on its own is not.”

Too early for enterprises to consider

However, not everyone agrees that the latest Chinese models have earned their place as enterprise AI decision options. 

Cybersecurity consultant Brian Levine, executive director of FormerGov, focused on Chinese technology concerns when he worked for the US Justice Department as its representative in the US law enforcement Joint Liaison Group (JLG) with China. 

“It is way too early for US enterprises to seriously consider these models,” he said. “Until proven otherwise, enterprises should assume that if they use these models, they may be granting China complete access to everything they do through the models, and potentially access to their networks and employees more broadly. At this point, any pros of using such models are strongly outweighed by the potential security, confidentiality, and reliability concerns.”

Tom Findling, CEO of Conifers.ai, was equally emphatic that enterprise CIOs need to steer clear of these newer Chinese models. 

“Using them inhouse? Absolutely not. You simply don’t know what is planted inside of it and you don’t know what training data is put into them,” Findling said. 

Mike Wilkes, enterprise CISO at Aikido Security, added that the very attractive pricing for these Chinese models may be appealing, but suggested that, despite the low cost, they’re ultimately too risky.

“Enterprises should take these models seriously, but not romantically. Parameter count is horsepower measured in a showroom, not braking distance in the rain,” he said. “The real tests are reliability on your data, the cost of a wrong answer, and whether the model behaves predictably under pressure.”

He noted that the benchmarks on the latest open-weights models are impressive, and very close to those of the frontier lab models, which makes the cost ”incredibly seductive, especially when a team does not want to risk their data being used to train those frontier models.”

But the Chinese models can still work in specific circumstances. “The strongest value will be in bounded, reversible and inspectable work: coding inside a sandbox, multilingual translation, document triage, data extraction and other high-volume tasks where outputs can be verified,” he said. “Cheap intelligence is valuable, but only when it is not mistaken for trustworthy judgment.”

Wilkes added that the regulatory issues surrounding Chinese models can be especially problematic. Texas, for example, has banned their usage.  

A rational choice for some workloads

However, Yuri Goryunov, CIO of consulting firm Acceligence, argued that CIOs should seriously consider these models. 

“Counterintuitively, the biggest benefit of Kimi and models like it is the lack of guardrails,” Goryunov said. “Think of it as stick shift cars in the era of automatics. If you want ease and comfort, stay with the frontiers because they have cruise control, shift the gears for you and they decide when. If you want performance and control, expand your horizons. But a stick shift assumes you know how to drive one: you bring your own governance, your own evals, your own safety layer. That’s a cost and specialized talent, which is super rare, and for the right organization it’s also the whole point.”

Goryunov’s bottom line: “For internal, high-volume, well-harnessed workloads, [the Chinese models] have moved from ‘watch list’ to ‘rational choice.’”

This article originally appeared on CIO.com.

Ever since Chinese AI startup DeepSeek launched three years ago, enterprise executives have been nervous about relying on Chinese AI models. 

But now that the latest Chinese AI offerings, Alibaba’s 2.4-trillion-parameter model Qwen3.8 Max and Moonshot’s 2.8-trillion-parameter model Kimi K3, are promising even more powerful performance, those IT executives are being forced to again ask if these models are worth using, even in a limited fashion.

Former Walmart head of risk Steven Eric Fisher, now an independent cybersecurity and risk advisor, thinks they should at least take another look.

“Enterprises should take these models seriously, but neither adopt nor reject them solely because they are Chinese,” he said. “They should be assessed like any other critical technology dependency: jurisdiction, ownership, training and software provenance, licensing, data handling, hosting, security, reliability, and the ability to independently test their behavior. Geopolitical exposure is a legitimate risk factor, but it should be incorporated into technical and supply-chain diligence rather than used as a substitute for it.”

Choose applications with care

He added, “Chinese models may be especially valuable for coding, multilingual processing, high-volume document analysis, research, synthetic-data generation, and privately operated security or forensic workflows, but they should be subject to task-specific testing rather than broad benchmark claims.”

Shashi Bellamkonda, principal research director at Info-Tech Research Group, agreed that the Chinese models can work well if they are only used in carefully chosen applications. 

“Although Moonshot’s K3 still trails Claude’s Fable 5 and GPT 5.6 Sol on performance and user experience, good companies that have governance and prompt guardrails will not face the instability and improvisation of [the Chinese] models,” he said. “These models will win in usage. US frontier models are leading as the best models, but Chinese models will be sufficient for high-volume, low-drama tasks that cost less for non-critical transactions.”

On the flipside, Bellamkonda suggested a variety of areas where enterprises should avoid Chinese AI models, including “customer-facing work without a human in the loop, regulated or sensitive data, and anything where a hallucinated answer creates legal or safety exposure. That is where the reliability gap and the political-radioactivity concern both bite, and where the closed American models still earn their premium.”

Bellamkonda said he didn’t see the differences in data reliability, mostly involving hallucination rates, as meaningful for enterprise AI strategy decisions.

“Every open-weight model in this class can get facts wrong or make things up. That is fixable with the right setup, so it is not a reason to avoid these models,” he said. “For high-volume tasks with clear limits, you feed the model your own trusted documents to answer from, and you keep a person checking the output. That combination is safe for production. The model on its own is not.”

Too early for enterprises to consider

However, not everyone agrees that the latest Chinese models have earned their place as enterprise AI decision options. 

Cybersecurity consultant Brian Levine, executive director of FormerGov, focused on Chinese technology concerns when he worked for the US Justice Department as its representative in the US law enforcement Joint Liaison Group (JLG) with China. 

“It is way too early for US enterprises to seriously consider these models,” he said. “Until proven otherwise, enterprises should assume that if they use these models, they may be granting China complete access to everything they do through the models, and potentially access to their networks and employees more broadly. At this point, any pros of using such models are strongly outweighed by the potential security, confidentiality, and reliability concerns.”

Tom Findling, CEO of Conifers.ai, was equally emphatic that enterprise CIOs need to steer clear of these newer Chinese models. 

“Using them inhouse? Absolutely not. You simply don’t know what is planted inside of it and you don’t know what training data is put into them,” Findling said. 

Mike Wilkes, enterprise CISO at Aikido Security, added that the very attractive pricing for these Chinese models may be appealing, but suggested that, despite the low cost, they’re ultimately too risky.

“Enterprises should take these models seriously, but not romantically. Parameter count is horsepower measured in a showroom, not braking distance in the rain,” he said. “The real tests are reliability on your data, the cost of a wrong answer, and whether the model behaves predictably under pressure.”

He noted that the benchmarks on the latest open-weights models are impressive, and very close to those of the frontier lab models, which makes the cost ”incredibly seductive, especially when a team does not want to risk their data being used to train those frontier models.”

But the Chinese models can still work in specific circumstances. “The strongest value will be in bounded, reversible and inspectable work: coding inside a sandbox, multilingual translation, document triage, data extraction and other high-volume tasks where outputs can be verified,” he said. “Cheap intelligence is valuable, but only when it is not mistaken for trustworthy judgment.”

Wilkes added that the regulatory issues surrounding Chinese models can be especially problematic. Texas, for example, has banned their usage.  

A rational choice for some workloads

However, Yuri Goryunov, CIO of consulting firm Acceligence, argued that CIOs should seriously consider these models. 

“Counterintuitively, the biggest benefit of Kimi and models like it is the lack of guardrails,” Goryunov said. “Think of it as stick shift cars in the era of automatics. If you want ease and comfort, stay with the frontiers because they have cruise control, shift the gears for you and they decide when. If you want performance and control, expand your horizons. But a stick shift assumes you know how to drive one: you bring your own governance, your own evals, your own safety layer. That’s a cost and specialized talent, which is super rare, and for the right organization it’s also the whole point.”

Goryunov’s bottom line: “For internal, high-volume, well-harnessed workloads, [the Chinese models] have moved from ‘watch list’ to ‘rational choice.’”

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.

OpenAI’s recent update to its Codex coding agent has developers worrying over the impact of the change on large code repositories and long-running AI-assisted sessions.

The update to the Codex CLI reduces the default configured input context window for GPT-5.6 to 272,000 tokens from 372,000 tokens.

In practice, the update means the coding agent will retain a smaller amount of code, conversation history, and other session information before compacting older context to make room for new information, a change that has prompted criticism from some developers on Reddit and X over the reduced token window.

While OpenAI has not publicly explained the rationale behind the update, several developers took to social media to question why OpenAI reduced the default context configuration, with some arguing that the change could make Codex less effective on long-running coding sessions by triggering context compaction sooner.

Others expressed concern that the smaller window could require more frequent context management or session resets, although some noted that the practical impact would depend on project size and how developers structure their workflows.

Smaller context, bigger workflow implications

The context window reduction could affect developer productivity and the adoption of autonomous agents in enterprise workflows, analysts say.

“While the context reduction in Codex is unlikely to affect routine coding tasks such as bug fixes or changes involving a few files, it could impact large codebases, repository-wide refactoring, and long-running sessions,” said Pareekh Jain, principal analyst at Pareekh Consulting.

“Less memory per session means the AI agent forgets earlier parts of a long coding session sooner. The agent may need to summarize or reload context more often, increasing repeated searches, occasional loss of earlier decisions and the need for developers to re-establish context,” Jain added.

That need for manual context management, according to Muskan Bandta, cloud associate at FinOps services providing firm ZopDev, goes completely against the “whole appeal” of Codex-like tools that promised improved productivity out-of-the-box: “A lot of developers are saying their sessions now spend more time on compacting than actually working.”

“While context reduction may not further inflate bills, it shows up as more retries, more compaction, and your engineers spending more time babysitting the thing. The spend just moves from the invoice onto your team’s time.”

Amit Jena, AI development manager at IT consulting firm Kanerika, said that the context reduction will force development teams to choose between two options: either accept that the agent is reasoning with an incomplete picture of the required context or learn to manage a new design constraint around context compaction.

Development teams, Jena said, will need to design workflows that proactively manage context: by breaking work into smaller tasks, relying more on retrieval mechanisms, and monitoring context consumption.

That forced design constraint on engineering, echoed Bandta, will slow the enterprise adoption of agent-driven workflows: “Context is the agent’s working memory, so cutting it by a third changes what you can trust it to do at all.”

Build for changing AI platforms, not fixed limits?

More broadly, analysts pointed out that the episode is a reminder that enterprises should avoid tightly coupling software development workflows to the current operational characteristics of managed AI coding platforms, as context limits, pricing, runtime behavior, and model availability are all likely to evolve with little or no advance notice.

“Enterprises should avoid depending on any single context window, continuously benchmark AI coding tools on real workloads, and build workflows around retrieval, modular design, and agent orchestration so they remain resilient as models evolve,” Jain said.

Kanerika’s Jena echoed that view: “The right approach is to build AI-assisted development pipelines that degrade gracefully when operational parameters shift: instrument your context consumption, don’t hard-code context budgets, and treat the vendor’s current specifications as a starting point, not a contract.” Similarly, Bandta advised enterprises to treat managed AI coding platforms like any other critical software dependency: “Don’t build anything that only works right at the edge of a limit, and keep enough flexibility that you’re not stuck if one vendor changes the deal.”

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.“

See also:

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

In one ransomware response I observed, the master operational dashboard remained green while the underlying environment told a very different story. It was a classic example of what we in the IT audit profession call the “watermelon effect”—green on the outside, red on the inside.

Beneath that dashboard sat an unmapped web of legacy technical debt, undocumented service accounts and shadow cloud instances. For years, presenting a green dashboard to the audit committee could give technology leaders a false sense of comfort. If a catastrophic breach occurred, it was generally treated as an unpredictable operational tragedy, managed via cyber insurance, a carefully calibrated public relations pivot and perhaps a quiet executive transition.

Today, that corporate shield is thinner than many technology leaders assume. For technology leaders in regulated or public-company environments, executive exposure is no longer only a theoretical debate. The regulatory environment has made plausible deniability much harder to sustain.

The erosion of the corporate shield

With the application of the European Union’s Digital Operational Resilience Act (DORA) for financial entities, alongside the broader NIS2 Directive for essential and important entities, cybersecurity governance has become harder to separate from board-level oversight. DORA places ultimate responsibility for ICT risk management on the management body of financial entities, while NIS2 requires management bodies to approve and oversee cybersecurity risk-management measures. In the United States, the U.S. Securities and Exchange Commission’s cybersecurity disclosure rules require public companies to disclose material cyber incidents and describe their cyber risk management, strategy and governance in annual filings. The new burden is not simply to operate controls; it is to show, after the fact, that leadership decisions matched the risk evidence available at the time.

The serious risk to a modern CIO is not simply the occurrence of a sophisticated security incident. The true danger is the inability to reconcile what leadership presented externally to investors, regulators and the board with what the internal evidence showed inside the environment.

When a serious crisis breaks, you may find yourself surrounded by corporate defense counsel, regulatory investigators and outside forensic lawyers all asking variations of the same uncomfortable questions: What did you know, when did you discover it and what specific actions did you take next?

When those questions are asked, a slide deck asserting that your security posture is “aligned with industry best practices” will not be enough. A post-incident review may recognize that sophisticated attacks occur. What creates greater exposure is evidence that known risks were ignored, understated or left outside structured governance. To survive that level of post-incident review, one of your strongest assets is a disciplined, independent evidence trail showing that risks were identified, challenged, escalated and acted on before the first indicator of compromise appeared.

Why point-in-time comfort letters fail regulatory scrutiny

The reality we face is that legacy compliance evidence often falls short under regulatory scrutiny. For years, the annual SOC 2 Type II report or a standardized ISO 27001 certification was brandished by technology teams as the definitive proof of a functional control environment. I have sat in dozens of scoping meetings where an engineering director pointed to a freshly minted compliance report as if it were a complete defense against scrutiny.

But a compliance report is a historical artifact—a retrospective evaluation of how specific controls operated during a defined window of time months in the past. It tells an investigator that on a random afternoon in Q2, your production change-management approvals conformed to a baseline policy. It says absolutely nothing about the configuration drift, unauthorized API keys or emergency patch bypasses that developers introduced the following weekend to hit a product release deadline.

Modern regulators, boards and investors are no longer satisfied by historical comfort letters alone. Under contemporary frameworks, especially regimes focused on operational resilience, static compliance evidence is no longer enough. The expectation of due care has shifted from a passive state of compliance to an active state of continuous challenge. Increasingly, post-incident reviews look for evidence that leadership identified system vulnerabilities, formally escalated material deficiencies, evaluated systemic risk to the business and tracked remediation progress with measurable rigor.

When an architecture fails, post-incident reviews often focus quickly on ownership, escalation and whether known risks were acted upon. If your defensive documentation consists entirely of static policy documents and green dashboards, you leave an evidentiary vacuum that can invite difficult questions about executive oversight. Post-incident reviews rarely turn on perfection. They turn on whether the organization can show a traceable chain of governance.

5 non-negotiable artifacts for your executive evidence engine

This reality requires a complete reframing of your relationship with your IT audit department. Historically, this dynamic has been defined by friction. Technology leaders frequently view my peers and me as compliance traffic cops—bureaucrats who interrupt core engineering sprints to demand evidence samples, user access reviews and system configurations.

It is time to view IT audit through a pragmatic lens: we are your independent evidence engine. We are one of the few corporate functions tasked with independently challenging your control environment, documenting where exceptions were escalated and showing how management responded. When an auditor identifies a control gap and partners with you to draft a management action plan, they are not creating a bureaucratic roadblock. They are helping you construct an evidence trail that can show risk was identified, escalated and acted upon.

To transform your IT audit function into an effective executive shield, you must shift focus away from superficial check-the-box exercises and collaborate on specific artifacts. The most effective exercise you can run with your audit leadership is to flip the timeline completely and ask: if this program were reviewed six months from now, which evidence would show we governed the risk before it failed?

1. Board-facing risk registers with escalation history: A risk register that sits unreviewed on an intranet page for 12 months is not a management tool; to an investigator, it can look like evidence that known risks were not actively governed. Your material technology, cybersecurity and dependency risks must be centrally logged. More importantly, this artifact must contain a clear, chronological escalation history showing exactly when the risk was presented to leadership committees and the board, along with related minutes, decisions or follow-up actions.
2. Granular risk acceptance records: You cannot remediate every vulnerability instantly. Business continuity, legacy software limitations and budgetary boundaries require you to accept certain operational exposures. When this occurs, ensure your risk acceptance records are airtight. A defensible record must document the specific technical variance, the precise financial or operational rationale for the delay, a definitive expiration date, explicit executive sign-off and the active compensating controls deployed to reduce the blast radius in the interim.
3. Tabletop and operational simulation records: Independent frameworks such as ISACA’s Digital Trust Ecosystem Framework can help structure this evidence, but boards and regulators will still look for proof that the testing actually happened. Your audit trail should contain comprehensive records of cyber incident, disaster recovery and third-party dependency simulations. These records must detail the scenario tested, the executive participants, the control failures identified during the drill and a formalized tracking schedule showing when those gaps were closed.
4. AI governance inventories and data-flow mappings: The rapid deployment of generative AI tools across enterprise operations has created a massive blind spot for technology executives. In one audit, we found developers using an unapproved public large language model to accelerate debugging with sensitive internal code. To protect yourself, work with your audit team to build an active enterprise AI inventory that maps data lineage, identifies model business owners, documents risk classification approvals and demonstrates active technical monitoring for unauthorized data exfiltration.
5. Synchronized disclosure-control handoffs: When a material security incident or system outage occurs, the clock begins ticking for regulatory reporting. Your incident response playbook must be technically linked to your corporate disclosure controls. The audit trail should show that a documented, synchronized handoff occurred between your technical response leaders, general counsel, chief financial officer and corporate communications team. This evidence helps show that your external statements match internal technical realities.

In the modern corporate ecosystem, technology leadership is no longer just an engineering challenge; it is an exercise in rigorous, evidence-based governance. The regulatory landscape has changed, and the expectation of continuous traceability cannot be avoided.

Open and direct collaboration with your IT audit team will not prevent a zero-day exploit, an unexpected cloud outage or a critical third-party vendor failure. That is not the purpose of enterprise risk management.

The true value is far more practical: when a serious incident puts your program under review, you will not be forced to defend your reputation with a feeling, an unverified assumption or a misleadingly green dashboard. Instead, you will have an independent record showing that risk was actively seen, appropriately challenged, properly escalated and responsibly managed. In today’s regulatory environment, that disciplined trail of evidence may be the difference between a failure that can be explained and one that begins to look negligent.

.

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

These days, application developers can take their pick from a vast menu of architectural solutions. We can choose from the well-understood to the experimental, and from blended solutions in between. Several powerful middle-ground technologies that emerged during the cloud revolution have really come of age. Here we’ll take a look at putting together three of the most impressive: GitHub, Vercel, and Firestore.

Each of these is an important tool in its own right that can be used to attack specific problems. In combination, they not only meet the needs of several important application scenarios, but they have a superpower—the ability to dramatically shorten the distance between development and deployment.

There is nothing quite as gratifying as putting your hands on just the right mix of tools for a given need.

A ‘no-ops’ stack built for speed

If your primary goal is sheer development velocity, you would be hard-pressed to top this architecture. This “no-ops” stack collapses the distance between your local IDE and a globally distributed production environment. You are essentially trading the overhead of managing VMs and load balancers for the sheer speed of committing code and watching it deploy automatically.

While each component is highly flexible, adopting them requires a specific, event-driven mindset. There are a few finicky bits to manage, mostly around routing environment variables securely and designing around stateless back-end functions. But the constraints are obvious and well-documented.

Before we look more closely, let’s quickly identify the kinds of apps that are a perfect fit here, along with those that are workable and those that really merit a different approach.

• The sweet spot (deploy and go): AI-mediated applications, asynchronous game back ends, and real-time collaborative B2B dashboards. This architecture perfectly absorbs the unpredictable latency of LLM APIs and instantly syncs state across multiple clients without requiring you to build custom WebSocket infrastructure.
• The middle ground (workable, with trade-offs): Headless e-commerce, moderate IoT telemetry, and apps requiring scheduled batch processing. You will encounter friction if your catalog relies on deeply relational SQL constraints, or if your background reporting jobs take longer than a few minutes and hit serverless execution limits.
• The danger zone (look elsewhere): High-frequency trading, fast-paced action multiplayer games, heavy data ETL pipelines, and core financial ledgers. Serverless architectures cannot natively hold open the persistent WebSockets required for twitch-reflex data, and heavy compute tasks will abruptly time out.

We should mention that these categories are not mutually exclusive. Many enterprise applications, such as a full-scale e-commerce platform, straddle these lines. You might use Vercel and Firestore to build a lightning-fast, reactive storefront that handles ephemeral user state like shopping carts, while simultaneously “stitching in” a managed SQL database like Supabase or PlanetScale. This hybrid approach allows you to maintain the relational integrity required for back-office inventory and financial ledgers and pair it with the front-end velocity this stack provides.

GitHub: the bedrock

I don’t need to introduce you to GitHub. It is a central element of the development landscape. I still remember CVS and SVN with a certain nostalgia, but the enhancements of Git speak for themselves. When combined with the orchestration powers of GitHub, it is no wonder that virtually the whole industry has adopted this type of platform.

Git plus GitHub gives you an enormous amount of power already, in terms of how you can organize and automate your projects. But there is a next-level experience in combining GitHub and Vercel. For JavaScript-based projects, you can take simple GitHub pushes and turn them into instantly deployed clients and serverless functions. It is one of the cleanest and least fiddly ways to move from raw code on your local machine to a globally deployed, full-stack architecture.

Vercel: the nexus

Vercel is more than just a deployment host. It is a control plane that ties this high-velocity, no-ops architecture together. Alongside GitHub and Firestore, Vercel’s deeper strength is its ability to act as an orchestration layer between your reactive front end and external stateful services.

Vercel has a great amount of facility in fine-tuning what branches go to what environment and helpful features like instant rollback. You can just log into Vercel’s dashboard for your project and see the history of deployments and any errors and logs. It’s a simple menu choice to roll back to a historical version or compare one version against another.

When you “stitch in” third-party services (such as a managed SQL database like Supabase or a payment processor like Stripe), Vercel’s serverless functions become the lightweight interface, and Vercel’s the adapters handle the communication. You offload the integration logic (the service layer) to Vercel’s global Edge Network, keeping your UI and back end clean, responsive, and decoupled. 

In short, Vercel allows you to get the speed of the “no-ops” development life cycle without sacrificing the complex transactional integrity required for some applications like enterprise inventory systems.

Firestore: the datastore

Firestore is an extremely lightweight, NoSQL, cloud datastore. It has a great deal of add-on power, but its core value proposition is that it accepts virtually any data you stuff into it and it provides event-driven subscriptions to data changes.

These two capabilities together make Firestore about as straightforward a solution to a managed back end as you can imagine. You subscribe to collections or even fields and then you simply stick “unstructured” data (read: JSON with variable fields) in and the client waits for the changes it is interested in.

This is so streamlined that one can just point the browser (or native mobile app) directly at Firestore and listen for events. Which immediately raises the question of identity, for auth and for data visibility, but hold on—Firestore’s third superpower is that it has an authentication module that actually works. What I mean is, it is actually pretty simple and yet confidently secures your app.

Sometimes auth solutions seem either too simple (and yet opaque) or too mired in the nitty gritty. Firestore auth will let you do some basic configuration and start using a reasonable auth almost immediately. 

Not to belabor the point, but having a realistic and attainable auth solution elevates your stack to a production grade—one that can handle many real-world applications. Firestore auth plays nicely with other important APIs, like Stripe. Typically, auth is a major feature that feels like off-roading in a Honda Civic, but Firestore’s approach to auth, added to this particular stack, feels like a normal speed bump. It’s just another component you plug in, rather than a tentacled alien you weave into the your code.

The limits of the velocity stack

This architecture combines components that are optimized for flexibility. That same character also introduces distinct limitations. Understanding these is essential before committing production workloads.

The serverless life cycle

Serverless functions are spun up to handle requests. They close out soon afterward and lose any state. For that reason, they cannot natively hold open persistent WebSockets. If your system requires continuous, sub-millisecond, bidirectional streams—like a real-time multiplayer action game or a high-frequency trading dashboard—pure serverless will fight you all the way. You are forced to introduce a third-party managed WebSocket service to route messages back to your stateless endpoints via HTTP webhooks.

The execution time ceiling

Vercel (like all serverless platforms) enforces strict timeouts on operations. While enterprise tiers might grant you up to 15 minutes, standard functions often time out after 10 to 60 seconds. Long-running tasks like video transcoding, database scripts, or orchestrating multi-step AI agent workflows, which might take 20 minutes to resolve, will run up against these limits. Heavy-lifting tasks must be offloaded to a dedicated, long-running service like Google Cloud Run, or broken into smaller, asynchronous chunks via message queues.

The cold start reality

While the industry has made massive strides in minimizing initialization times—particularly with lightweight edge networks—traditional Node.js-based serverless functions still experience cold starts. If a function has not been invoked recently, or if traffic spikes require a new instance to spin up concurrently, the first request will take a noticeable latency hit as the container provisions and the code loads.

API instead of RAM

In a traditional server environment, you can store transient data in global RAM, allowing subsequent requests to access shared context instantly. In the serverless model, every request might hit a fresh container. Therefore, all shared context must be externalized. Although Firestore serves brilliantly as the state manager, relying on a database for high-frequency, sub-millisecond, ephemeral caching introduces network latency and per-operation costs. That said, using a shared RAM state on a server is non-trivial also, unless you are using a single app server and VM (because high-availability or fail-over requirements will lessen the RAM win on a traditional server).

Tuning for velocity and control

Every architectural decision is a trade-off. There are no cost-free choices. By adopting the GitHub, Vercel, and Firestore stack, you are explicitly maximizing feature velocity over fine-grained control.

You lose the ability to tweak the underlying operating system, hold open persistent sockets, or run hour-long back-end scripts. In exchange, you gain an architecture that scales from zero to global distribution instantly, requires virtually no devops maintenance, and perfectly absorbs the asynchronous, event-driven realities of modern application development.

For the right application—whether it is a fast-moving prototype or an enterprise AI copilot—this stack doesn’t just save time; it fundamentally changes how quickly a small team (or a single person) can impact the market. You stop worrying about build chains, load balancers, and server patches, and you focus on the central mission: shipping features.

Nearly five decades after the launch of VisiCalc, AI is reshaping one of the world’s most familiar productivity tools — the humble spreadsheet.

While a lot of knowledge workers interact with spreadsheets on a regular basis, many lack the skills and confidence to access more advanced functions.

“For a very long time, spreadsheets forced you to learn spreadsheet syntax and spreadsheet ways of working,” said Eric Birnbaum, director of product management for Google Sheets. “But think about how many people need to use spreadsheets at work and don’t have the skill set to create the kinds of spreadsheets that can be really helpful for them.”

The addition of artificial intelligence can help handle that issue, he said, making the software more accessible to a wide range of office workers. “AI is unlocking the power of spreadsheets, taking on a lot of the difficult work that’s required to use them. That can be incredibly empowering for users,” said Birnbaum.

Google has steadily expanded generative AI (genAI) capabilities in Sheets since launching Duet AI — now Gemini — for Workspace in 2023.

Gemini in Sheets is available at no extra cost to Google Workspace subscribers, though a paid AI Expanded Access add-on – costing $30 per user each month – is required to remove certain usage limits.

Features that have rolled out in recent months include the ability for a Gemini agent in Sheets to carry out multi-step actions such as formatting, analysis and data entry, and, more recently, the ability to create entire spreadsheets from a single prompt. A Fill with Gemini feature builds on the existing AI function, enabling users to automatically populate selected cells by detecting intent from information within a spreadsheet as well as from the web.

Another feature, Sheets Canvas (currently available in alpha), lets users generate interactive apps that update in real-time based on changes to spreadsheet data. This could be a kanban board for a sales pipeline, for instance, or an analytics dashboard that uses Sheets as its back-end data source. 

Google claims users already see a range of benefits from Gemini in Sheets. According to an August 2025 survey of 200 Sheets users conducted by the company, the majority of knowledge workers (89%) said AI features in Sheets save them at least an hour a week, and 88% believe AI features have made them more confident in their data analysis skills. 

The most popular AI use cases include creating spreadsheets and charts, analyzing data, and fixing broken formulas. How widely these features are actually used is unclear; Google declined to provide weekly usage statistics for Gemini in Sheets.

As the company embeds Gemini deeper into Sheets, questions remain about just how much businesses can trust AI tools to handle important business data, as well as what increased automation means for those who spend much of their day wrangling data. 

Computerworld recently talked with Birnbaum about the potential benefits and challenges of the latest evolution of spreadsheet software. This interview has been condensed and edited for clarity.

As businesses become more focused on seeing value from AI investments, what measurable benefits are customers seeing from Gemini in Sheets – for example, time saved or other forms of return on investment? “Spreadsheets remain one of the universal languages for businesses, and we don’t anticipate that’s going to change anytime soon. But by bringing AI into the product where people work, we think it can significantly reduce the technical tax of data: the time spent understanding it, sourcing it, analyzing it, visualizing it.

“Historically, data professionals spent — let’s estimate it at 80% of their time — on the mechanical groundwork, data cleaning, crafting formulas, formatting, troubleshooting, and maybe only 20% of their time on actual strategic decision-making.

“We think that by offloading the manual, time-consuming, error-prone data work to Gemini, we can flip that ratio a bit, so humans can focus on the things that really matter: the high-value questions to ask and the judgment calls and decisions that get made from them. We’re starting to see evidence of that in our own user base and customer base.

“The second point to make is that AI can democratize data analysis to some extent, and make it available to many more users. For so many years, the spreadsheet was a gatekeeper; if you couldn’t speak the rigid language of spreadsheet formulas, you couldn’t extract the value from data. But by introducing these natural language interfaces, AI is separating the analytical capability from the technical literacy. 

“If you can ask the right questions, or describe what you want in plain language, Gemini and Sheets can help you achieve your goals in a spreadsheet, even if you have minimal spreadsheet skills yourself.

“What we’ve seen so far from users and customers is that it’s incredibly empowering for people who might have been scared off by data analysis or dreaded opening spreadsheets in the past. You don’t need to go and wait for a data analyst to help you; you can go and do this work yourself in a spreadsheet.”

The flip side is, how confident can businesses be if more junior employees can take on higher-level analysis tasks by relying on AI? Given the propensity for AI models to hallucinate, to what degree can businesses trust that these tools won’t introduce errors into important business data? “It’s something we spent a ton of time thinking about. We’ve gone to great lengths to build these AI tools to collaborate with you, to show their work, explain what they did, and make sure that you can take over where they leave off.

“Our Sheets agent, for example, lays out a really explicit, transparent plan for you to review and approve before any data manipulation happens. It’s designed to do that in plain natural language in a way that the average user could understand, and then it gives you back that final summary, so you know exactly what it did and where it did it.

“The other thing is that the model is great at explaining things. If you inherit a spreadsheet that has some complex formula that you don’t understand, for example, the model does an amazing job of explaining how it works and what it’s doing.

“In many ways AI is not only making these features more accessible, but helping users feel more confident in the output. Human error is an inherent risk in manual data management, with or without AI. One misplaced comma or broken cell reference can completely corrupt an entire financial model, and it can be completely undetected. 

“Our approach with AI in Sheets is to create this deliberate verification loop. You now have another spreadsheet expert working along with you, reducing the likelihood of these mistakes.”

Even if humans produce errors too, does it ultimately come down to accountability when AI is involved? “Our point of view here is that AI should be partnering with the knowledge worker who’s doing the work here. And everything that we’ve built is designed to be that partner. You might be able to offload tasks to the model, but we’re citing sources, we’re providing plans and explanations. We’re ultimately relying on the user to do that final verification.

“We spend a humongous amount of time focused on quality. We know that for AI to be useful in spreadsheets, it has to be reliable. When we launched Sheets Gemini Agent, for example, we were really proud that we set a state-of-the-art benchmark on the full SpreadsheetBench data set, which at the time exceeded competitors and near-human expert ability. 

“But we know quality is never ‘good enough’ or done. We’re constantly working to improve quality for our users and customers, and for the use cases where they’re relying on AI most.”

What potential do you see for more agentic functionality in Gemini Sheets — for example, bringing in data from other sources, creating recurring reports, or taking more actions independently? “We’re listening closely to customers and users and building what they’re telling us they need. The agent is already capable of doing very complex multistep workflows, and we see users discover that the agent is extremely capable of doing end-to-end spreadsheet tasks. In terms of connectors, in an alpha we have connections available to HubSpot, Salesforce, and Mailchimp. We hope to expand that over time.

“There’s no path to have AI replacing analysts. I think AI is giving analysts more time back to actually do the more valuable parts of their job. Analysts that I work with are way more productive and impactful than they ever were before, because they can push that uninteresting spreadsheet grunt work off to the model, freeing up time for more interesting and impactful work.

“A great example: the visualizations I’m getting back from analysts nowadays are canvases instead of static charts that I can explore myself. It’s way more informative and useful than what I was accustomed to before.”

Looking ahead, do you expect a larger share of spreadsheet work to be carried out by agents, with humans setting goals and reviewing results? What will be the biggest change in how people use spreadsheets with AI? “The tasks are likely to stay similar and the use cases for spreadsheets are likely to continue to be relevant. The biggest change will be the ability to push the uninteresting spreadsheet grunt work off to a model and free up time for the user to do things that are more impactful, more interesting, more meaningful to the business.

‘Spreadsheets have historically been these like static containers where data goes to rest. I think AI can turn spreadsheets into these dynamic, localized software applications. And I do actually think this sort of changes the game for how people might use spreadsheets moving forward. 

“It’s not just a passive grid full of numbers; spreadsheets are evolving to become these live, long-lived, collaborative applications. Employees can build these on the fly, like a basic CRM or supply chain dashboard in seconds. This is an area of investment for us moving forward, and we’re really excited to see how this evolves.”

AI assistants and agents, such as ChatGPT or Claude, might be able to analyze spreadsheet files and business data without users working inside a spreadsheet application. What do you think will keep Sheets central to the workflow, rather than simply making it one part of a wider AI-driven process?“We’re in constant touch with customers and users; it’s clear work is still happening in spreadsheets. I think spreadsheets remain incredibly popular tools. If we can bring the AI capabilities users need directly into the product where they already are, we’ll transform the way they work.  

“I think we can be the front-end for some of this great AI innovation and the products that users are accustomed to today. Everything we build is guided by user feedback: users are telling us right now they want AI to help them do their everyday or more complex tasks, and they’re starting in Sheets today.”

Picture the moment after an AI issue is reported.

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

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

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

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

The list is not the response

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

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

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

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

AI incidents do not always look like breaches

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

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

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

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

Evidence has to exist before the investigation

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

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

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

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

Ownership cannot be implied

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

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

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

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

Security leaders need an AI response playbook

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

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

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

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

Governance has to be executable

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

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

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

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

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

Stephen Wilson, field chief technology officer for HashiCorp, an IBM company, likens AI agents to “really smart kindergartners.”

“They know how to do something, but they have no clue as to why they should do it,” Wilson says.

This combination of superior execution power and lack of judgment can create a significant challenge for organizations trying to fit AI agents into their existing zero trust architectures. In a robust zero trust environment, Wilson notes, human users are first authenticated, then given escalating decision-making powers and access over time, with many organizations potentially taking weeks to onboard an IT employee with elevated privileges. But that model breaks down with AI agents that can be spun up for single tasks and then quickly destroyed.

“Imagine having to onboard and offboard one of these entities within your ecosystem once every second,” Wilson says. “The introduction of AI agents isn’t necessarily creating new problems. But it is exacerbating problems that have always been there.”

‘You don’t know when they’re going to be wrong’

The pressure for organizations to aggressively adopt AI has brought a corresponding pressure to lower or delete barriers between authentication, decision-making, execution, and authorization, Wilson says. Rather than rearchitecting their zero trust programs for AI agents, many organizations are essentially giving the tools broad access and hoping for the best.

“These agents move so quickly, and no one is quite certain exactly what access they should have,” Wilson says. “I’ve never seen this before, where really smart security people are just closing their eyes and moving at a rate that can be dangerous.”

Already, unfettered access for agentic AI could unleash “calamity” within some organizations, Wilson says, with a report emerging that an AI agent deleted entire production databases. “We’ve seen an example of months and months of work disappearing, even in stable software development environments,” Wilson says. “Even if we estimate that AI agents are right 80% of the time, the problem is the other 20%—what happens when they’re wrong?”

Taking the long view

While agentic AI can raise short-term security problems, Wilson sees the technology as a forcing function that will spur long-term improvements to organizations’ zero trust environments. “We’re at an inflection point where we’re going to have to do the hard things,” he says. “With human users, we’ve accepted that we’re not going to move as fast as we want, and we’re going to have to say no a lot. But this is a tidal wave.”

Wilson likens the rise of agentic AI to the debut of the iPhone (“but 10 times more potent”), noting that smartphones forced organizations to create security and governance practices for bring-your-own-device (BYOD) and remote work programs. “Before the iPhone, there was no such thing as BYOD,” he says. “It was very painful at first, but we would not have remote work if it wasn’t for the iPhone.”

“AI brings that same challenge,” Wilson says. Doing the hard things, he adds, means moving to zero standing privilege, issuing dynamic credentials at the moment of use rather than relying on long-lived secrets, and building security in rather than bolting it on. The goal is to keep the human “on the loop” rather than in it, supervising agents without slowing them down. “Some organizations are going to take some hard lumps, but I think we’re going to be more secure in the long run.”

To learn more, visit us here.

It started with a one-line message from a finance team on a Tuesday afternoon: A handful of customers had been charged twice that day, and one was disputing a duplicate charge with their bank.

I went straight to the monitoring, expecting to find something broken. Instead, everything looked healthy: By the system’s own records, every order had been paid exactly once. It took the team a month of digging through production incidents to close the gap between a dashboard that said, “all good,” and a customer billed twice.

I’ve since seen this kind of failure across multiple payment systems, some handling hundreds of thousands of transactions a day. What follows is a composite and doesn’t describe any single system or organization. The numbers, timings and identifying details have been changed to keep anything proprietary out.

The retry that charged twice

A customer clicked Pay; the order service called the payment service, which called the external provider. The provider charged the card for $200 and recorded a success on its side.

The only thing that went wrong was timing. The provider was under load and took just over 3 seconds to answer. The client gave up after 2 seconds, a default inherited from internal service calls and never tuned for payments. From the caller’s side, the call had simply failed, so nothing was marked as paid.

The retry logic did what it was built to do and sent the request again. The provider saw what looked like a fresh charge and took the money a second time. The database recorded one payment: the retry. The first charge lived only in the provider’s records, invisible to us until the complaints came in.

Violetta Pidvolotska

The duplicates were refunded within hours, before the dispute could become a chargeback. Understanding what had actually failed took much longer.

Later, we widened the timeout well past the provider’s slowest healthy responses, but as long as a retry can trigger a second charge, a longer timeout only makes the double charge rarer.

The real mistake was older than the limit itself. The system had been told that a timeout means failure.

The third state

We tend to think of a network call as having two outcomes: it worked or it didn’t. A timeout is the third. The request may never have arrived. It may have done its work and lost the response on the way back. That is what bit us. Or it may still be running. From the caller’s side, you can’t tell which.

Code rarely has a separate path for “unknown.” It gets lumped in with failure and the failure path retries. When the request moves money, that is how you charge someone twice.

A slow service shows up as rising response times, an unreliable one as errors. A double charge shows up as a success, and nobody noticed until a customer did.

Timeouts, which I’ve written about before, turn silent hangs into visible failures. And visible failures get retried, which is how we arrived at idempotency.

“Exactly-once” gets used as if it were a setting you could turn on. You cannot promise exactly-once delivery across an unreliable network, as Tyler Treat explains. What you can promise is exactly-once effects: The request may arrive twice, while the charge happens once.

My first instinct was to stop retrying payments automatically and it helped. But not every retry is ours to switch off: The customer refreshes the page, or a retry policy somewhere in the infrastructure resends on its own.

The assumptions under the key

The standard remedy is an idempotency key: The caller attaches a unique value to one attempt at an operation and sends the same value on every retry. A new key gets processed and its result stored; a familiar one gets the stored result back, so the retry has no extra effect. Brandur Leach’s walkthrough of Stripe-like idempotency keys in Postgres lays the pattern out end to end.

The key was shipped and the duplicates stopped. But we relaxed too early. The key turned out to be the easy part.

A key like this rests on four assumptions. I’ve since turned them into a checklist I call the four-assumptions test:

• Claim. Claiming a key is just a matter of checking it’s free first.
• Intent. The same key always carries the same intent.
• Memory. Whatever a key remembers is safe to replay.
• Boundary. Nothing behind the key lies beyond your control.

Over the following month, all four broke: The race in a load test, the other three in production.

Two requests, same millisecond

In a load test, two requests with the same key arrived in the same millisecond. Each checked for the key; neither found it and both started processing.

Violetta Pidvolotska

“Check whether the key exists, then write it” is a race like any other and it broke the claim assumption. We fixed it by flipping the order: now writing the key is the check. Every request writes it as “started” and the database lets only one claim win. The safeguard:

-- Try to claim the key; the UNIQUE index lets only one caller win.
INSERT INTO operations (idempotency_key, state) VALUES (:key, 'started')
ON CONFLICT (idempotency_key) DO NOTHING;

The insert touches one row or none, and that count tells you which path you’re on. One row means you won: Call the provider, then mark the row ‘completed’ and save the response. None means you lost: Read the row and return its saved response or tell the caller to retry later if it is still ‘started’.

One detail is easy to get wrong: Commit the claim before the provider call goes out. Otherwise, a crash rolls it back and erases the only record that a charge may be in flight.

The harder case is a winning request that crashes mid-charge: Its key is stuck at “started,” and every retry is told to wait for an answer that will never come. A stuck claim is the same unknown all over again: Once it has sat in “started” longer than any healthy call could take, ask the provider what actually happened before anyone charges again.

Same key, different request

The second gap appeared a week into production and broke the intent assumption: A caller reused one key for two different requests, $200 and $500, and the system returned the first request’s stored response without noticing the amount had changed.

Violetta Pidvolotska

We fixed it by storing a fingerprint of the request’s contents next to the key, on the same insert, so a request that loses the claim race can still compare its fingerprint against the winner’s. If the fingerprints match, it’s a genuine retry. If they don’t, the key was reused for a different operation and we reject it.

That fix promptly rejected a valid retry. We had been fingerprinting the entire request, including a timestamp that changed between attempts and fields that arrived in a different order, so the fingerprints did not match.

A fingerprint has to capture what a request means rather than how its bytes are arranged. Hash a hand-picked list of business fields and you risk a silent collision: The one field nobody remembered to add lets two different requests match. Hash the whole request minus known noise like timestamps and the failure is loud instead: A missed volatile field rejects a valid retry. We chose loud, the fix came down to two lines:

intent      = drop_fields(request.json, volatile={"client_ts", "trace_id"})  # strip known noise only
fingerprint = sha256(canonical_json(intent))   # canonical form: keys sorted, numbers and spacing normalized

Even “canonical” hides decisions. RFC 8785 pins them down, but it runs every number through an IEEE 754 double, which loses precision on large values, so money amounts are safer as strings or integer cents. Change the canonical form and every stored fingerprint stops matching, so we version it and store the version next to the fingerprint.

The error we cached

The third gap came in through support: A customer hit an insufficient-funds decline, added money, tried again with the same key and got the old “insufficient funds” back. The provider was never asked. The system had been caching every response, declines included, so the failure stuck to the key.

Violetta Pidvolotska

That forced the question behind the memory assumption: What is a key allowed to remember? The rule we landed on: cache only success.

A soft decline or a validation error releases the claim instead: The row flips back to claimable, fingerprint kept. The next attempt reclaims it with an update that only one retry can win and the customer who adds money gets a live attempt instead of a replay. Hard declines are the exception: A stolen-card response is final and that claim stays closed.

On a timeout, we don’t know whether the charge landed, so we ask the provider whether the charge already went through and act on the answer.

Where the guarantee runs out

The first three gaps were on endpoints under the team’s control. The fourth surfaced during reconciliation: A charge on an older provider’s statement with no matching internal record. That provider had no idempotency keys, and the guarantee had reached its boundary. We could not make it safe to call twice.

We got as close as we could: A pending record before the call, a status check before retrying, reconciliation to catch and refund whatever slips through. A window remains where the charge has landed and our record doesn’t know it yet. We kept shrinking that window, but we never managed to close it.

The database that holds the keys forces a decision of its own: When it is down, you either stop taking payments or take them unprotected. That choice is a business call. For a low-stakes write, cleaning up a rare duplicate can cost less than turning customers away. A payment is not low stakes, so we fail closed and stop taking payments until the store is back: A lost sale we can recover, and we had just spent a month learning what duplicates cost.

Questions I ask in design reviews

For anything that stores or changes data, I ask three questions:

• What happens if this runs twice? Ask it out loud for every write.
• Can we prove the answer? Run it twice in tests, in sequence and in parallel; the second run should change nothing.
• Where does the truth live when systems disagree? For payments, it’s the provider because their records show whether money actually moved. Settle whose answer wins before an incident does.

The key is a good idea and, in anything that moves money, a necessary one. It is just not a guarantee. The guarantee is the design around it: A claim that cannot race, an intent the fingerprint confirms, a memory that keeps only what is safe to replay and a boundary you have mapped in advance. That is the four-assumptions test. Every assumption gets tested eventually: You do it at design time or production does it for you.

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

The PC was heralded as revolutionary; it was going to save time, revolutionize our work… But it became an opportunity lost. Paper became digital files. Filing cabinets became shared drives. Memos became email. We sometimes worked faster. We did not necessarily work differently. And we certainly did not work more efficiently. The underlying logic: approval chains, reporting cycles, hierarchies and incentives remained intact.

The internet and smartphones followed the same pattern, compressing time and distance. But neither forced enterprise changes. The tools changed. The organizational model did not. This stagnation is referred to as the Solow Productivity Paradox, a historic mismatch between massive technology investments and flat corporate productivity. And while the Internet boom did see a raise in productivity, it was due to investment in hardware, not so much due to a change in how we worked, as explained by Robert Gordon in The New Economy: What Productivity Miracle?

And now there’s Artificial Intelligence, AI. AI presents a different kind of challenge because it intervenes in cognition itself. It reaches much closer to the operating logic of the enterprise than previous technology waves.

Yet, once again, the response is surface adaptation rather than structural reinvention. AI is layered onto inherited workflows, old approval thresholds, unclear accountability structures and sprawling software, then expecting cost savings to follow. And again, it is the investments in AI that garner any growth, not changes in corporate infrastructure.

This is not transformation. It is acceleration without reform. And this “slap on AI” will have as much long-term impact as the PC.

Automation = efficiency? Wrong

Chief information officers are under intense pressure to turn AI into measurable financial outcomes. In boardrooms, expectations are explicit: deploy AI, automate, reduce operating cost and show results within a budget cycle.

A central misunderstanding in AI programs is the assumption that if a process is costly and labour-intensive, automation creates efficiency. Unfortunately, what appears as inefficiencies are normalized fragmentations. With AI, hidden workflow contradictions become both significant and visible. Organizations discover it wasn’t running a slow but clean process. It was running an incoherent process that relied on human buffering to keep it functioning. This is precisely why so many AI efforts disappoint immediately after a dazzling pilot, degenerate into AI strategy theatre and fail to scale.

When one part of the workflow becomes lightning-fast, but the surrounding process remains fractured, escalations multiply and the IT department, despite having done its job perfectly, is asked to fix the operational fallout with more tooling, more integration, more controls and more spend. The problem is rarely technical. But it becomes so very quickly.

I increasingly think the more useful concept here is process debt. CIOs are already comfortable talking about technical debt and its complexities. Process debt is the upstream generator of that complexity. It accumulates when temporary fixes become permanent, when controls are added without removing older ones and when incidents leave behind workflows nobody dares to challenge. Over time, the process stops reflecting deliberate design and starts reflecting institutional memory, risk aversion and unresolved negotiations between functions.

Case study 1: The regulated approval-heavy process

I was brought into a regulated organization that wanted to identify opportunities for automation. The assumption was that technology was the main constraint. Workflows involved multiple reviews, approvals and handovers between departments. From a distance, it looked like an obvious candidate for automation.

It was a familiar situation: delays, duplicated effort and frustration with how long routine work was taking to complete. The process seemed overstaffed and underdesigned. The natural conclusion was that automation could remove unnecessary tasks and improve speed.

But as I began interviewing the stakeholders, a different picture emerged. Every group could explain its role in the workflow. But the more I listened, the clearer it became that nobody could describe the process as a coherent whole.

What appeared to be an inefficient process was a process that had accumulated layers of governance without ever being reassembled into a consistent operating model. One approval had been added after an audit finding. Another had been introduced during a restructuring. A third existed because of a past incident. None of those approvals looked unreasonable in isolation. Together, they produced a workflow that nobody owned and with approval layers nobody could justify.

From the CIO’s perspective, this translated into technology sprawl. Unaligned and multiple IT systems were being used to support adjacent parts of the workflow. Software had been purchased to manage steps that shouldn’t have existed in the first place. This meant the entire nature of the automation discussion shifted. The strategic question was no longer which step should be automated first. It was whether those steps deserved to exist at all.

Only after the CIO and I brought the business units together to confront these structural dependencies did the process align and technology become part of the answer. Without that preliminary work, automation would simply have moved a poorly understood process faster while expanding the expensive software estate needed to govern it.

That engagement reinforced my conviction that many workflows presented as automation candidates are not ready for automation because they are not sufficiently coherent to automate.

Uncomfortable questions

Because these questions are operationally and politically sensitive, businesses will try to avoid them and hand the unmapped mess directly to IT. As a strategic partner, the CIO must guide the C-suite through these uncomfortable but necessary inquiries before deploying AI into enterprise workflows:

• Does this process need to exist at all?
• Where are decisions actually made in day-to-day practice? Not according to policy documentation, but according to the informal networks of people who actually know how to navigate the exceptions.
• Which parts of the workflow exist because of corporate history rather than necessity?
• Where do decision rights shift between teams without anyone acknowledging it?

AI systems do not handle ambiguities gracefully. Answering these questions upfront determines whether implementing AI will mean genuine savings or simply move organizational incoherence through the enterprise at lightning speed.

Three-layer governance

Governance is the ultimate reason why AI cannot be treated as a traditional technology delivery program with a bit of business input tacked on at the end. Because AI fundamentally alters how enterprise decisions are informed and executed, its deployment must be shaped by an integrated operating and governance framework.

CIOs can evaluate an organization’s true AI readiness based on three interdependent governance layers. By mastering these, the technology stack is protected from being forced to compensate for bad business design.

1. Organizational governance. Core questions: Is this workflow genuinely needed, who actually owns it and what risk or quality definitions are binding across separate business functions? This is a cross-departmental leadership question. It must be resolved by the business units first, or IT inevitably inherits the resulting operational complexity.
2. Endpoint or tool governance. Core questions: How are outputs interpreted when cognitive work is partially or fully delegated to machines? This layer defines exactly where a human-in-the-loop remains mandatory, how exceptions are escalated to specialists and how accountability is maintained when an AI agent makes an optimized operational prediction.
3. Platform governance. Core questions: What is the foundational security, privacy and technical guardrails? This includes LLM/model selection, vendor standards, data privacy compliance, integration rules and continuous monitoring. Paradoxically, this is the layer most organizations focus on first—yet, because it exists entirely to support the processes and tools above it, it should actually be the last to be set in stone.

These layers interlinked. A weakness in one undermines the others. This is where CIOs become strategically important. They are the executives who see when process incoherence is converted into architectural complexity, application sprawl, higher license costs and long-term support burdens. AI decisions without that perspective and organizations will once again confuse digitization with transformation.

Case Study 2: A downstream bottleneck and the structural solution

In another engagement, the business pushed for an AI-driven intake solution. Frontline teams were spending massive amounts of time on repetitive customer data coordination and document verification. On paper, it was an outright victory: IT delivered an AI agent that dropped data extraction times by 85% with an exceptional accuracy rate. In every sense of the word – the pilot was a triumph. And it was phased to implementation.

Within six weeks, the illusion shattered. While the intake layer was now running at lightning speed, the downstream validation process still relied on traditional compliance handoffs, manual fraud checks and legacy database updates. The AI didn’t solve the operational problem; it simply shoved massive volumes of data into a rigid pipeline that was never designed for that velocity.

Escalation queues exploded. The operations team, buried under an unprecedented backlog, began making manual bypass decisions just to keep up, creating immense operational risk.

Rather than allowing IT to be blamed for the downstream chaos, the CIO and I suggested a structural solution. First, we halted further automated intake scaling and used visual process-mapping data to show the rest of the C-suite exactly where the digital pipeline was hitting an analogue wall.

Second, we championed a cross-functional “value stream” redesign. After much negotiation, we managed to leverage the AI’s data-validation outputs to eliminate three manual review steps downstream and replace them with exception-only automated alerts. Finally, we renegotiated the risk-threshold parameters with the legal and compliance teams, shifting accountability from a multi-stage sign-off to a centralized, systemic audit log.

The solution wasn’t adding more software; it was picking the process apart, data point by data point, to align the business rules with machine capabilities. The result was a substantially trimmer, automated end-to-end stream that freed up human resources, allowed redundant software licenses to be safely withdrawn and actually realized the promised financial savings.

Conclusion

Every CIO knows that AI matters. The real challenge facing enterprises whether the executive leadership team is willing to confront what AI inevitably reveals about the fragmented processes, legacy habits and siloed systems organizations have been carrying for decades.

This is why the broad promise of immediate AI savings is overstated. Automation can produce staggering enterprise value, but it cannot create structural coherence on its own. If a workflow is fractured, historically layered and dependent on invisible human intervention, adding AI will not turn it into an efficient system. It will simply scale, cement and automate the weaknesses that were already there.

The CIO’s ultimate responsibility is to ensure that technically incoherent processes do not get permanent residency in the business architecture. This is why the CIO must have a leading seat at the strategic table. Incoherent processes invariably turn into application sprawl, redundant tooling, excess licensing costs, integration debt and massive security exposure.

To avoid this trap, enterprise AI deployment requires cross-departmental leadership willing to examine which work should be automated, which must be completely redesigned and which should be eliminated. 

If not, we will simply repeat the costly errors of past technology shifts: preserve the outdated operating logic, throw a shiny new layer of tooling on top and call the expensive result “transformation.” This time, the bill will be significantly larger. Not because AI is mysterious, but because it is brutally efficient at exposing the waste that organizations used to hide inside their people, their processes and their software.

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

Hyperscalers continue to invest astronomical amounts in data infrastructure for AI workloads, even as they concede that the massive projects may not pan out as planned.

Oracle, for instance, detailed in its latest 10-K report to the US Securities and Exchange Commission (SEC) all of the ways that these investments could be adversely impacted, potentially making the projects more expensive and extending build-out times.

And Meta, as well as building infrastructure, is purportedly planning to create a new line of business that would generate revenue from excess compute power. An infusion of cash from that venture could return some of its massive investments in data centers and chips to bolster its efforts to develop “super intelligence.”

These developments and others indicate that hyperscalers are beginning to optimize their investments for return on AI infrastructure, not just focusing on a data center land grab.

“Both companies recognize that there is huge potential in the buildout, but both have a legal obligation to share material risks that are significant when an industry is spending hundreds of billions of dollars on a capital outlay,” noted Jeremy Roberts, a senior director at Info-Tech Research Group.

He pointed to reports that the top four hyperscalers (Alphabet, Microsoft, Amazon, and Meta) are planning to invest up to $725 billion this year on AI infrastructure, including data centers, which is “mind-boggling.”

“The datacenter buildout we’re seeing now is unprecedented,” he said.

Oracle’s challenges

In its 10-K report, Oracle detailed its data center investment risks, as required by US federal law. In it, the company concedes that data center construction may cost more or take longer due to supply chain risks, local restrictions on development, or because of failure by third parties to complete on schedule, deliver required equipment and components as promised, fail to pay their bills, or opt not to renew contracts.

Oracle has recently invested heavily in AI and data center infrastructure, notably the $300 billion Stargate contract with OpenAI. As part of that deal, Oracle is building enormous data centers across the US. The company says it will continue to enter into long-term lease commitments with data center companies and chip and infrastructure suppliers.

However, it warns, “if we underestimate customer demand or our data center capacity needs, we may face shortages of available infrastructure, limiting our ability to support customer growth.”

New customers may not even consider Oracle offerings at all if the company can’t get what it needs for build-outs, the company says. This could leave it with expensive assets that may not be able to be re-leased, re-purposed, or assigned on “acceptable terms, if at all,” it said.

And while Oracle says it has continued to bolster its cloud products and services, it must continue to be able to develop new or “sufficiently differentiated” offerings and enhance those offerings in a timely manner at a competitive price to meet growing demand, it says. The company also must be able to secure data center capacity at affordable rates, and accurately plan for and manage capacity requirements.

Meta’s infrastructure plans

Meta, meanwhile, is continuing its spending spree on AI infrastructure, anonymous sources told Bloomberg. The company is purportedly developing plans for new cloud infrastructure business lines that would sell access to AI computing power and models, putting it in competition with other data center giants.

One potential scenario would have Meta selling access to models, including its new Muse Spark, hosted on its own AI infrastructure, as well as running the underlying data centers. This model is similar to AWS’ Bedrock offering. Another possibility is Meta selling access to “raw” computing capacity, as do neocloud businesses such as CoreWeave. This move is part of the company’s internal Meta Compute initiative, the sources said.

Like Oracle, Meta has been investing hundreds of billions of dollars in data centers and expensive AI chips. And, according to its latest 10-K: “We plan to continue to significantly expand the size of our infrastructure primarily through data centers, subsea and terrestrial fiber optic cable systems, and other projects.”

Also like Oracle, Meta conceded that these projects are complex and generate exposure to various compliance issues and political challenges. As such, it has “changed, suspended, and terminated” certain projects due to these factors, and will continue to do so if necessary.

The view from the enterprise

For enterprise IT buyers, more competition is probably a good thing in the long term, Roberts noted.

“Advances in data center tech that come about when companies are forced to find every efficiency to stay on top will probably be beneficial,” he said.

However, prices will likely to continue to rise as buildout continues, and anyone making purchasing decisions for components, adjacent products or “basically all hardware” will “feel that pain,” Roberts said.

Those trying to build right now will be competing with hyperscalers who can “pour essentially unlimited funds into construction,” he noted. They will likely have to pay more than they ever have before if they need Nvidia GPUs or high-bandwidth memory from SK Hynix, or even for a crew to plumb and wire a facility.

“I don’t know if this frenzy will cool off any time soon, but now is probably the worst time in recent history to embark on a project like this if you’re a smaller fish in the ocean of AI capital,” Roberts said.

Thus, for this and other reasons, most organizations likely won’t lead their own AI buildouts, he predicted. The successful ones will be those who “effectively optimize AI use, leverage cheaper models, and engage in thoughtful buildouts versus trying to go head-to-head against the richest companies in history in a spending contest.”

This article originally appeared on CIO.com.

Hyperscalers continue to invest astronomical amounts in data infrastructure for AI workloads, even as they concede that the massive projects may not pan out as planned.

Oracle, for instance, detailed in its latest 10-K report to the US Securities and Exchange Commission (SEC) all of the ways that these investments could be adversely impacted, potentially making the projects more expensive and extending build-out times.

And Meta, as well as building infrastructure, is purportedly planning to create a new line of business that would generate revenue from excess compute power. An infusion of cash from that venture could return some of its massive investments in data centers and chips to bolster its efforts to develop “super intelligence.”

These developments and others indicate that hyperscalers are beginning to optimize their investments for return on AI infrastructure, not just focusing on a data center land grab.

“Both companies recognize that there is huge potential in the buildout, but both have a legal obligation to share material risks that are significant when an industry is spending hundreds of billions of dollars on a capital outlay,” noted Jeremy Roberts, a senior director at Info-Tech Research Group.

He pointed to reports that the top four hyperscalers (Alphabet, Microsoft, Amazon, and Meta) are planning to invest up to $725 billion this year on AI infrastructure, including data centers, which is “mind-boggling.”

“The datacenter buildout we’re seeing now is unprecedented,” he said.

Oracle’s challenges

In its 10-K report, Oracle detailed its data center investment risks, as required by US federal law. In it, the company concedes that data center construction may cost more or take longer due to supply chain risks, local restrictions on development, or because of failure by third parties to complete on schedule, deliver required equipment and components as promised, fail to pay their bills, or opt not to renew contracts.

Oracle has recently invested heavily in AI and data center infrastructure, notably the $300 billion Stargate contract with OpenAI. As part of that deal, Oracle is building enormous data centers across the US. The company says it will continue to enter into long-term lease commitments with data center companies and chip and infrastructure suppliers.

However, it warns, “if we underestimate customer demand or our data center capacity needs, we may face shortages of available infrastructure, limiting our ability to support customer growth.”

New customers may not even consider Oracle offerings at all if the company can’t get what it needs for build-outs, the company says. This could leave it with expensive assets that may not be able to be re-leased, re-purposed, or assigned on “acceptable terms, if at all,” it said.

And while Oracle says it has continued to bolster its cloud products and services, it must continue to be able to develop new or “sufficiently differentiated” offerings and enhance those offerings in a timely manner at a competitive price to meet growing demand, it says. The company also must be able to secure data center capacity at affordable rates, and accurately plan for and manage capacity requirements.

Meta’s infrastructure plans

Meta, meanwhile, is continuing its spending spree on AI infrastructure, anonymous sources told Bloomberg. The company is purportedly developing plans for new cloud infrastructure business lines that would sell access to AI computing power and models, putting it in competition with other data center giants.

One potential scenario would have Meta selling access to models, including its new Muse Spark, hosted on its own AI infrastructure, as well as running the underlying data centers. This model is similar to AWS’ Bedrock offering. Another possibility is Meta selling access to “raw” computing capacity, as do neocloud businesses such as CoreWeave. This move is part of the company’s internal Meta Compute initiative, the sources said.

Like Oracle, Meta has been investing hundreds of billions of dollars in data centers and expensive AI chips. And, according to its latest 10-K: “We plan to continue to significantly expand the size of our infrastructure primarily through data centers, subsea and terrestrial fiber optic cable systems, and other projects.”

Also like Oracle, Meta conceded that these projects are complex and generate exposure to various compliance issues and political challenges. As such, it has “changed, suspended, and terminated” certain projects due to these factors, and will continue to do so if necessary.

The view from the enterprise

For enterprise IT buyers, more competition is probably a good thing in the long term, Roberts noted.

“Advances in data center tech that come about when companies are forced to find every efficiency to stay on top will probably be beneficial,” he said.

However, prices will likely to continue to rise as buildout continues, and anyone making purchasing decisions for components, adjacent products or “basically all hardware” will “feel that pain,” Roberts said.

Those trying to build right now will be competing with hyperscalers who can “pour essentially unlimited funds into construction,” he noted. They will likely have to pay more than they ever have before if they need Nvidia GPUs or high-bandwidth memory from SK Hynix, or even for a crew to plumb and wire a facility.

“I don’t know if this frenzy will cool off any time soon, but now is probably the worst time in recent history to embark on a project like this if you’re a smaller fish in the ocean of AI capital,” Roberts said.

Thus, for this and other reasons, most organizations likely won’t lead their own AI buildouts, he predicted. The successful ones will be those who “effectively optimize AI use, leverage cheaper models, and engage in thoughtful buildouts versus trying to go head-to-head against the richest companies in history in a spending contest.”

It was one of the biggest tech headlines in June: Amid the race leading up to the initial public offerings (IPOs) of artificial intelligence (AI) giants, the United States used its “blocking card” to disable Anthropic’s latest models. Citing national security concerns, the Trump Administration forced the company to prevent non-U.S. citizens (even in the US) from using its most advanced models — the very ones it had just unveiled. Speculation suggests the same thing could happen to OpenAI.

The ban on Anthropic was not lifted until June 30. The US administration said that, in the intervening weeks, it had worked with the company to “review and approve Fable5 to ensure it aligns with the US government and strengthens US leadership in AI.” For its part, OpenAI confirmed that its next major launch would begin with a preview for “trusted partners ”—a list it has shared with the US government.

Are these companies falling victim to their own marketing — having touted that their models are becoming increasingly intelligent and potentially more dangerous? Or are they collateral damage in an uncertain geopolitical world? Whatever the rationale, the recent moves raise questions in Europe, where digital sovereignty movements are on the rise.

The sudden shutdown of Fable 5 and Mythos 5 for European companies had a limited direct impact, because the models were so new. As Fernando Maldonado, senior analyst at Foundry Spain, noted: “Hardly anyone here had even started using them yet.” The indirect impact is more far-reaching, because it shows that a forced technological blackout is possible and that Europe has a limited margin for response.

The doomsday scenarios warn that Europe could be headed for a future tech disaster that will have a domino effect on the economy and society. That’s the conclusion of the “Europe 2031” report, prepared by a group of European AI researchers, analysts, and investors. “The current trajectory of AI calls for the most ambitious political agenda in the history of postwar Europe,” the report concludes. They argue that Europe has failed to grasp the scale of AI ‘s spread and warn that Europe couldl fall into irrelevance. (The group estimates that, in that scenario, the continent would control only 5% of AI computing by 2031, compared to 80% for the US). There is much talk of sovereignty, but little real-world action so far.

That dystopian vision of the future coexists with other, more nuanced perspectives. But analysts and political scientists point out that AI could yet become an economic and political lever that will shape the future balance of power.

The ‘kill switch’ scenario

The total shutdown “kill switch” option, deemed impossible not so long ago, has established itself as one of the real potential fears in geopolitical risk: it was on the agenda at the recent G7 meeting. The Anthropic case was seen as a warning. “Technology is increasingly a strategic asset. Europe must be able to act on its own terms,” European Commission spokesperson Thomas Regnier told Euronews. Speaking to Reuters, he added, “This event is further proof that Europe must strengthen its technological sovereignty.”

The Anthropic outage “has given ammunition to those who have been calling for investment in technological sovereignty and highlights this geopolitical situation,” said Beatriz Arias, director of digital transformation at DigitalES. Arias believes the incident shows that today’s reality requires work in more areas; it is no longer enough to manage telecommunications or standards. Other issues such as interoperability and intellectual property are on the table, as well as “the need to invest more in our own capabilities, without prejudice to our continued commitment to an open model of cooperation and alliances.”

That said, Darío García de Viedma, a researcher in Technology and Digital Policy at the Elcano Royal Institute, does not believe the feared kill switch will be used, “because the US technology export model depends on companies. Companies are the strong arm of US diplomacy in the technological sphere.” For them to play that tole, they need a global presence. But he does agree that what happened with Anthropic helps “explain this risk to the public” — and incidentally showcase what technological sovereignty is.

Even if a catastrophic blackout doesn’t occur, other problems could still hinder access. Political scientist Amélie Férey explained on France Culture how license prices could gradually rise and drive up costs. Or access to certain features could be gradually restricted. As García de Viedma put it, a moratorium on model access would create a “temporal asymmetry.” Disruptions can occur in “the complex supply chain behind all our technology,” through export controls (something now happening in the chip market) or through the degradation of essential services (such as what could happen with Starlink coverage).

In recent years, the European Union has entered a race in that arena, one that involves symbolic measures well as practical legislative moves. The European Parliament has dropped Google as its default search engine and replaced it with the French Qwant. And in early June, the Commission presented its European Technology Sovereignty Package, which addresses, among other issues, AI. They aim to ensure that Europe becomes “a continent of AI, strengthen its digital autonomy, and help build a more sustainable digital future,” while also acknowledging Europe’s technological dependence.

“We cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable, and our services secure,” said Commission President Ursula von der Leyen. Specifically, Europe aims to triple the capacity of its data centers over the next five to seven years, boost the adoption of AI, enhance research and innovation, and work on its own development and deployment efforts. The package will now have to go through an approval process to become law and take effect.

UE

Has Europe done enough?

The big question is whether what Europe has done — and what it plans to do — will be enough. Are the sovereignty packages sufficient, or are they vague and lacking in concrete details? The Europe 2031 group accuses Europe of making empty promises that don’t translate into tangible results.

García de Viedma said the latest package represents “good progress, which is defining technological sovereignty as risk mitigation.” In this case, risk has three aspects: technological dependence could be used as a coercive measure; tech operations could be disrupted “if at any point our alliances deteriorate;” and IT could be used as a tool for surveillance.

“Not to sound like conspiracy theorists, but the fact is that there is a possibility that whoever controls the communication nodes and software has the ability to see, if not everything, then at least some things,” he said. “That gives them an advantage.” Therefore, sovereignty is not so much “that identity-based vision” but rather one of “risk avoidance.” It’s not about using European technology simply because it’s European, but about understanding the risks of not using it.

Viedma believes the Commission has accurately identified today’s problems (such as governance or the digitization of the power grid, “the main bottleneck for AI”) but wonders about the future. Added to this is the issue of money: investment is a key piece in this chess game.

DigitalES views the efforts currently under way — such as those regarding European chips — favorably. “What’s needed is more determination and focus,” said Arias. Incidents like the Anthropic case can “help move in that direction.” While European investment plans in AI may seem less grandiose than those of the sector’s major companies, Arias warned against defeatist rhetoric.

“The EU is doing what it needs to do,” he said, and is creating “a more geopolitically stable environment for investors. Ultimately, this is about the market and who creates the most value.” European regulations can eventually become global standards, with Europe positioning itself “as an attractive partner for investment” — one that is “reliable and more predictable.”

Arias said the key lies not in complete autonomy, but in finding a balance. “We don’t have to produce 100% of what we use, and we shouldn’t depend 100% on a single supplier or jurisdiction.” What’s needed is technological diplomacy, being able to navigate complex waters and safeguard interests.

Playing by different rules in the global AI market is not feasible. “You must be aware of your strengths and weaknesses.” And she insists: “Europe is by no means a long shot — quite the opposite, because it offers certain guarantees.”

The next great revolution

Europe is late to the AI race, but it can still “assume a certain leadership role,” depending on how the sector evolves, as García de Viedma notes. Europe can carve out its own niche and investments are being made and efforts are under way to do so. In AI, this involves identifying areas of European specialization.

There remains a lot of work to be done and, possibly, lessons learned from past experiences to face what lies ahead. AI issues are part of a very complex reality. Arias warned of the need to prepare for “the convergence of artificial intelligence with the computing power that quantum computing will provide” featuring “dual-use technology that will be employed for both military and civilian purposes.” These will be more powerful tools that “require a more solid foundation.

“Such technological diplomacy will be necessary to negotiate global quantum standards, protect intellectual property, and address the potential impact on national security.”

The quantum revolution is imminent, but has yet to unfold, and Europe can capitalize on it. “Europe is jumping on this bandwagon,” argued Arias, highlighting the investments and work on quantum capabilities. “We’re in a very different situation than we were with the cloud and artificial intelligence.” The EU is “acting quickly” and opening the door to “positioning ourselves country by country.”

Every finance transformation conversation we have these days starts with AI. Clients arrive at the table with a list of agentic capabilities they want to deploy and an assumption that technology is the answer.

That assumption is half right. AI is one of the most consequential forces reshaping finance in a generation, and the future-state operating models we are designing today look fundamentally different as a result. But AI alone is not a strategic finance roadmap. The return comes from sequencing AI with the right process redesign, technology architecture and data foundation, with each piece compounding the next.

For decades, CFOs treated transformation like a renovation, managing tasks room by room. They executed separate projects to update the close, replace an ERP and layer better reporting on the same operating model. AI changes that blueprint. For the first time, we can take the house down to the studs and rebuild around capabilities that did not exist three years ago. That is a different kind of project, and it requires a different kind of leader.

AI has done something that previous waves of transformation never managed to do. It has brought the right stakeholders into the conversation and forced finance and IT to address the same problem simultaneously. That side effect alone is reshaping how the next phase of transformation gets built.

This is the part of the conversation IT leaders need to understand.

What the AI conversation has actually done

For most of the last decade, finance transformation was launched in response to a single trigger. A cost-out program. A post-acquisition integration. An ERP that aged out. The CFO owned the initiative, the CIO got pulled in to handle the technology and the rest of the business found out when the new system went live.

The AI moment has changed that pattern and forced a new conversation. When you are taking the house down to the studs rather than swapping out fixtures, the work cannot be done by Finance or IT alone. Stakeholder alignment becomes a precondition for the rebuild, not a nice-to-have. AI is the attraction that pulls everyone into the room.

When a client walks in asking about agentic finance, the CFO, CIO and heads of accounting, FP&A and controllership all show up for the same assessment. Leaders who have historically run parallel agendas now talk about the same problem at the same time. By the time we get to solution design, the cross-functional alignment that used to require months has already happened. Issues get raised early. The transformation moves faster because everyone agreed on the destination before we picked the route.

Maybe we can thank AI for bringing people together who otherwise wouldn’t have been collaborating. That is the reason the next phase of finance transformation looks structurally different from the last.

The roadmap and what’s missing

A strategic finance roadmap is not a project plan. It is more like an architect’s drawings, providing a multi-year design that connects business strategy to a future-state operating model, sequenced so each step compounds rather than starts over.

Every roadmap has a North Star. That future-state vision almost always has an AI component. A multi-agent solution orchestrated on a platform. Continuous close. Predictive FP&A. Real-time controls. Humans in the Loop. A streamlined org chart. That vision, eventually, becomes the destination.

But the destination is not today. What matters today is that the work between the as-is and future-state is cumulative, not throwaway. The data foundation organized for one transformation becomes the foundation for the next. Process improvements made now will accelerate the AI capabilities deployed two years from now.

You do not need an architect for a renovation. You hire a contractor, hand them a task list and inspect the results. You need an architect when you take the house down to the studs. The role most transformation programs are missing right now is not another builder. There are plenty of developers, system implementers and business integrators in any given program. What is missing is the architect.

The architect designs how the parts come together before anyone starts building. That work runs side by side with the client, connecting the dots between the technology, the problems, the data and the functions inside Finance and IT. The architect’s job is to create the vision and the blueprint and to translate between groups that do not naturally speak the same language. Done well, the result is a structure that is fundamentally sound and built to expand as the client’s appetite grows. Done poorly or skipped, the result is a house that cannot accommodate what comes next.

Live on the 1st floor while you build the 2nd… and 3rd

The traditional transformation pitch promises ROI at the end. Wait three years and the numbers will look great. That pitch is structurally fragile, and every CIO who has watched a transformation budget get cut in year two knows why.

Stakeholder fatigue is real. Budget uncertainty is real. In private equity-backed companies, the three-to-five-year hold period is real. Any program that has not produced measurable value in the first phase loses political support before the second phase is built.

The architectural alternative is to design the program so the first floor is occupied while the second and third floors are still being completed. The first process redesign produces value while the next is being scoped. The first technology deployment generates a return while the next is being implemented. The roadmap is not a march toward a distant payoff. It is a sequence of compounding wins.

The materiality of the return matters more than the size. A small process improvement or quick win that delivers a meaningful percentage gain in week ten is worth more than a large transformation that promises a bigger gain in year three. Quick wins prove that the blueprint is working. That proof builds the confidence stakeholders need to fund the next phase and the one after that. Investors want immediate ROI. Boards want immediate ROI. The strategic finance roadmap should be designed to deliver it.

Data in every room

Picture data as the electricity and water in a building: every room needs it, and the pipes and wires that carry it are what make the structure livable. Consolidating, warehousing and improving data quality is how you run those lines. It strengthens every element of the roadmap, not just the AI.

That has implications for how the stack gets selected. Most clients end up with an ecosystem rather than a single platform. ERP, EPM, close management, procurement, reporting and an emerging set of agentic capabilities, all integrated against a shared data foundation. The boundaries between those tools matter less than the data architecture that connects them.

It also has implications for what the CIO needs to be doing right now, even on transformations not yet formally launched. The data work pays dividends regardless of which solutions eventually get built. Cybersecurity, controls and business continuity are not bolted on at the end. They are design constraints embedded in the architecture from day one. SOX compliance is easier to build in than to retrofit, as is every other control discipline that lands on the CIO’s desk.

The roadmap in 5 years

The most concrete way to think about where this is going is to look at the org chart.

The finance org chart five years from now is not going to look like the org chart today. Where there used to be five controllers, there may be one human controller and three E-controllers, with agents sitting alongside them on the chart. The remaining human roles will be split between onshore and offshore in ways that look unfamiliar from where we sit now. The balance and location of every component will shift.

The strategic finance roadmap is the artifact that builds toward that end state, and the roadmap itself will evolve as the work progresses. Not a destination, but a continuous design exercise.

AI is rebuilding finance from the studs up. The strategic finance roadmap is how we make sure the new house is structurally sound, produces returns from the first floor and reflects the vision and the priorities of the people who will live in it. That work belongs to the CFO and the CIO together, or it does not become livable.

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

Microsoft’s controversial claim that its Majorana chip program will make possible a scalable quantum computer by 2029 has been thrown into new doubt by a scientific paper that questions whether the company has correctly interpreted its own experimental evidence.

According to a peer-reviewed paper by Dr. Henry Legg from the University of St Andrews, published this week in Nature, Microsoft’s Topological Gap Protocol (TGP) framework, designed to infer the existence of quantum states in theorized Majorana particles, is flawed.

“Last year Microsoft claimed they had built the equivalent of a precision Swiss watch. However, when I opened the case to examine the mechanism, I found what looked like a chaotic jumble of mismatched parts,” said Legg.

He believed the results gathered from Microsoft’s TGP software data analysis could also be explained by other effects, as well as being skewed by the data chosen for analysis. Because of this, he believed the company’s researchers had jumped to the wrong conclusions.

“Something was making noise, but it didn’t look like the breakthrough Microsoft had claimed. Despite the headlines, the vast majority of scientists in the field were skeptical of Microsoft’s claim from the start; my critique simply backs up that skepticism in the scientific record,” he said.

Topological qubits

The ability to create Majorana ‘zero modes’ that resist the errors suffered by traditional qubit-based designs is fundamental to Microsoft’s entire quantum computing strategy, stretching back two decades. This, of course, assumes the existence of subatomic Majorana fermions, named after the Italian physicist who first proposed them in 1937. To this day, they remain only theoretical.

In 2018, Microsoft said its researchers had detected evidence of their existence, an apparently major breakthrough it was forced to retract when the data was successfully challenged. Nature’s editors subsequently backed this up with the blunt note: “The results in this manuscript do not represent evidence for the presence of Majorana zero modes in the reported devices.”

Despite the setback, Microsoft persisted, in 2025 publishing a new paper in Nature that claimed the company had worked out how to exploit the principle in a new “transistor for the quantum age,” the Majorana 1 chip.

Earlier this month, the company launched its successor, Majorana 2, claiming that AI had helped to achieve a 1,000-fold improvement in reliability compared to the earlier chip. “With this progress, the team now expects to achieve a scalable quantum computer by 2029, cutting its original timeline in half,” the company announced.  

However, Microsoft again finds itself on the defensive after the latest criticism from Legg, who said, “I am simply reflecting what most in the field felt from the initial announcement. I felt that I needed to put these concerns into a formal scientific critique. It is good that it has now been peer-reviewed and published.”

His criticism relates to the transport data system, not the raw experimental data itself, which Microsoft had yet to make fully public in a way that would allow independent analysis.

Microsoft still confident

Microsoft said by email that it remains confident that the Majorana has brought usable quantum computing a step closer, pointing to its collaboration with DARPA as part of the Underexplored Systems for Utility-Scale Quantum Computing (US2QC) program.

“We stand by our results and our roadmap,” said technical fellow and vice president of quantum hardware, Dr. Chetan Nayak. “At the end of the day, success is the delivery of a scalable quantum computer. We are confident in our ability to execute against our roadmap.”

“Skepticism and rigor are hallmarks of the scientific process, which we appreciate and have supported from various academics,” he added. “We have participated in dialogue and our thorough rebuttal was accepted and published by Nature.”

Microsoft is not the only company researching quantum computing hardware, with Google, IBM, and Amazon also working on designs. But even if the hardware matures on the schedule claimed by Microsoft,  many believe the gap between technology and implementation inside enterprises could be more of a slow burn than a sudden jump forward.

Microsoft’s controversial claim that its Majorana chip program will make possible a scalable quantum computer by 2029 has been thrown into new doubt by a scientific paper that questions whether the company has correctly interpreted its own experimental evidence.

According to a peer-reviewed paper by Dr. Henry Legg from the University of St Andrews, published this week in Nature, Microsoft’s Topological Gap Protocol (TGP) framework, designed to infer the existence of quantum states in theorized Majorana particles, is flawed.

“Last year Microsoft claimed they had built the equivalent of a precision Swiss watch. However, when I opened the case to examine the mechanism, I found what looked like a chaotic jumble of mismatched parts,” said Legg.

He believed the results gathered from Microsoft’s TGP software data analysis could also be explained by other effects, as well as being skewed by the data chosen for analysis. Because of this, he believed the company’s researchers had jumped to the wrong conclusions.

“Something was making noise, but it didn’t look like the breakthrough Microsoft had claimed. Despite the headlines, the vast majority of scientists in the field were skeptical of Microsoft’s claim from the start; my critique simply backs up that skepticism in the scientific record,” he said.

Topological qubits

The ability to create Majorana ‘zero modes’ that resist the errors suffered by traditional qubit-based designs is fundamental to Microsoft’s entire quantum computing strategy, stretching back two decades. This, of course, assumes the existence of subatomic Majorana fermions, named after the Italian physicist who first proposed them in 1937. To this day, they remain only theoretical.

In 2018, Microsoft said its researchers had detected evidence of their existence, an apparently major breakthrough it was forced to retract when the data was successfully challenged. Nature’s editors subsequently backed this up with the blunt note: “The results in this manuscript do not represent evidence for the presence of Majorana zero modes in the reported devices.”

Despite the setback, Microsoft persisted, in 2025 publishing a new paper in Nature that claimed the company had worked out how to exploit the principle in a new “transistor for the quantum age,” the Majorana 1 chip.

Earlier this month, the company launched its successor, Majorana 2, claiming that AI had helped to achieve a 1,000-fold improvement in reliability compared to the earlier chip. “With this progress, the team now expects to achieve a scalable quantum computer by 2029, cutting its original timeline in half,” the company announced.  

However, Microsoft again finds itself on the defensive after the latest criticism from Legg, who said, “I am simply reflecting what most in the field felt from the initial announcement. I felt that I needed to put these concerns into a formal scientific critique. It is good that it has now been peer-reviewed and published.”

His criticism relates to the transport data system, not the raw experimental data itself, which Microsoft had yet to make fully public in a way that would allow independent analysis.

Microsoft still confident

Microsoft said by email that it remains confident that the Majorana has brought usable quantum computing a step closer, pointing to its collaboration with DARPA as part of the Underexplored Systems for Utility-Scale Quantum Computing (US2QC) program.

“We stand by our results and our roadmap,” said technical fellow and vice president of quantum hardware, Dr. Chetan Nayak. “At the end of the day, success is the delivery of a scalable quantum computer. We are confident in our ability to execute against our roadmap.”

“Skepticism and rigor are hallmarks of the scientific process, which we appreciate and have supported from various academics,” he added. “We have participated in dialogue and our thorough rebuttal was accepted and published by Nature.”

Microsoft is not the only company researching quantum computing hardware, with Google, IBM, and Amazon also working on designs. But even if the hardware matures on the schedule claimed by Microsoft,  many believe the gap between technology and implementation inside enterprises could be more of a slow burn than a sudden jump forward.

This article originally appeared on NetworkWorld.

Microsoft’s controversial claim that its Majorana chip program will make possible a scalable quantum computer by 2029 has been thrown into new doubt by a scientific paper that questions whether the company has correctly interpreted its own experimental evidence.

According to a peer-reviewed paper by Dr. Henry Legg from the University of St Andrews, published this week in Nature, Microsoft’s Topological Gap Protocol (TGP) framework, designed to infer the existence of quantum states in theorized Majorana particles, is flawed.

“Last year Microsoft claimed they had built the equivalent of a precision Swiss watch. However, when I opened the case to examine the mechanism, I found what looked like a chaotic jumble of mismatched parts,” said Legg.

He believed the results gathered from Microsoft’s TGP software data analysis could also be explained by other effects, as well as being skewed by the data chosen for analysis. Because of this, he believed the company’s researchers had jumped to the wrong conclusions.

“Something was making noise, but it didn’t look like the breakthrough Microsoft had claimed. Despite the headlines, the vast majority of scientists in the field were skeptical of Microsoft’s claim from the start; my critique simply backs up that skepticism in the scientific record,” he said.

Topological qubits

The ability to create Majorana ‘zero modes’ that resist the errors suffered by traditional qubit-based designs is fundamental to Microsoft’s entire quantum computing strategy, stretching back two decades. This, of course, assumes the existence of subatomic Majorana fermions, named after the Italian physicist who first proposed them in 1937. To this day, they remain only theoretical.

In 2018, Microsoft said its researchers had detected evidence of their existence, an apparently major breakthrough it was forced to retract when the data was successfully challenged. Nature’s editors subsequently backed this up with the blunt note: “The results in this manuscript do not represent evidence for the presence of Majorana zero modes in the reported devices.”

Despite the setback, Microsoft persisted, in 2025 publishing a new paper in Nature that claimed the company had worked out how to exploit the principle in a new “transistor for the quantum age,” the Majorana 1 chip.

Earlier this month, the company launched its successor, Majorana 2, claiming that AI had helped to achieve a 1,000-fold improvement in reliability compared to the earlier chip. “With this progress, the team now expects to achieve a scalable quantum computer by 2029, cutting its original timeline in half,” the company announced.  

However, Microsoft again finds itself on the defensive after the latest criticism from Legg, who said, “I am simply reflecting what most in the field felt from the initial announcement. I felt that I needed to put these concerns into a formal scientific critique. It is good that it has now been peer-reviewed and published.”

His criticism relates to the transport data system, not the raw experimental data itself, which Microsoft had yet to make fully public in a way that would allow independent analysis.

Microsoft still confident

Microsoft said by email that it remains confident that the Majorana has brought usable quantum computing a step closer, pointing to its collaboration with DARPA as part of the Underexplored Systems for Utility-Scale Quantum Computing (US2QC) program.

“We stand by our results and our roadmap,” said technical fellow and vice president of quantum hardware, Dr. Chetan Nayak. “At the end of the day, success is the delivery of a scalable quantum computer. We are confident in our ability to execute against our roadmap.”

“Skepticism and rigor are hallmarks of the scientific process, which we appreciate and have supported from various academics,” he added. “We have participated in dialogue and our thorough rebuttal was accepted and published by Nature.”

Microsoft is not the only company researching quantum computing hardware, with Google, IBM, and Amazon also working on designs. But even if the hardware matures on the schedule claimed by Microsoft,  many believe the gap between technology and implementation inside enterprises could be more of a slow burn than a sudden jump forward.

This article originally appeared on NetworkWorld.

Apple’s threatened product pricing hike arrived Thursday with steep increases landing across all its products (except the iPhone) — and rapidly accelerating RAM prices are to blame.

Apple CEO Tim Cook had warned last week about the need for price increases, with Bloomberg reporter Mark Gurman subsequently telling us these were “imminent.”

The increases have been imposed as a result of the massive demand for memory and storage components generated by the rapid investment in AI servers. Prices have increased to meet this demand, with vendors shifting manufacturing to the advanced memory modules demanded by AI companies. In doing so, they have not invested in additional production capacity, further exacerbating the demand/supply imbalance.

“Unfortunately, price increases are unavoidable,” Cook told The Wall Street Journal. “We’re doing our best to mitigate the huge increases that are being passed to us, and we’ve been trying to shield our customers from the increases, but the situation has become unsustainable.”

The price increases are going to hurt

The price hikes even affect products Apple hasn’t updated in years, such as the HomePod and Apple TV. The extent of the increase is big in some cases — the Apple TV is up 55% while an M3 Ultra Mac Studio sees a 32.5% rise. While I had hoped any higher prices would be aimed at Apple’s high-end products, the extent and scale of the changes suggests the enormity of the component price increases the company has been struggling with.  

“We haven’t seen anything like this in modern Apple,” said Neil Cybart at Above Avalon.

Here’s what starting prices look like now:

Macs

• MacBook Pro, up $300 to $1,999.
• MacBook Air, up $200 to $1,299.
• MacBook Neo, up $100 to $699.
• iMac, up $200 to $1,499.
• Mac mini (M4 Pro), up $200 to $1,599. 
• Mac Studio (M4 Max), up $500 to $2,499.
• Mac Studio (M3 Ultra), up $1,300, to $5,299.

iPads

• iPad Air, up $200 to $749.
• iPad Pro, up $200 to $1,199.
• iPad, now starts at $449.
• iPad mini, now $599.

Other hardware

• Vision Pro, up $200 to $3,699
• HomePod mini, up $30 to $129.
• Apple TV, up $70 to $199.

There were no immediate changes to the iPhone, Apple Watch and AirPods — but no guarantees, either, that their prices won’t also jump.

This is AI-flation

The scale of these increases is like a dose of cold water on the already tepid optimism of investors. This was quickly reflected by a big sell off on Apple stock, which was down more than 6.5% at one point today. And the impact was contagious across the sector as investors realized that if Apple was forced to increase prices even at the lower end of the market it so recently secured, it’s likely other manufacturers will be forced to do the same. This can only further dampen market optimism.

Concerning the MacBook Neo, Francisco Jeronimo, IDC vice president for client devices, said: “The $100 increase takes the entry model from $599 to $699, close to a 17% increase, one of the sharpest percentage hikes in the announcement, and it hits one of Apple’s best-selling, most price-sensitive laptops right as it is winning share. Raising the price of its fastest-selling entry product indicates that Apple believes demand will stay strong, given the value the product offers. It also signals Apple is willing to give up some unit growth at the bottom of the range to defend margin, and it widens the gap the Neo had just closed against Windows entry-level machines.”

The fact of the matter is that consumers are effectively paying an inflationary fee for the benefit of the ongoing global AI rollout. That rollout is already consuming vast quantities of investor cash, despite the shaky business plan of existing incumbents. 

“We have never seen a component price increase this much, this quickly,” Apple ​said in a statement. “We have shielded our customers from these increases so far, but we have now reached a point where we need to begin ⁠raising prices on a number of products, including today’s increases for iPad and Mac.”

Apple and the entire industry will not want to maintain prices at these levels if they can avoid it. That’s going to mean the entire tech industry will now begin leaning on memory manufacturers such as Micron to do more about building out production capacity, or at least promising to do so. Of course, the other hope might be that investors finally see the folly of the AI business model and slow down deployment, though that seems unlikely.

“We know this is not welcome news, and we are working tirelessly to find solutions,” the company said.

Please join me on social media at BlueSky,  LinkedIn, or Mastodon, even better, please subscribe to The Core for your daily collection of human-curated Apple News.

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

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

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

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

The new CIO investment dilemma

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

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

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

Hardware power constraints model capabilities

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

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

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

Compute power isn’t everything

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

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

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

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

Rethinking cloud strategy in the age of AI

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

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

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

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

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

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

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

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

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

Hardware is often underused and misused

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

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

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

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

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

More hardware can’t overcome model mismatch

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

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

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

The magic happens when model and hardware come together

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

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

AI has emerged as a top priority for businesses and a vehicle for transformation, as evidenced by Accenture research: 97% of executives believe AI will transform their company and industry. But as companies move from AI pilots to scaling AI across the enterprise, we have had repeated conversations with CIOs and technology leaders who are arriving at the same uncomfortable realization: AI stack decisions are not easily reversible.

Unlike earlier eras of enterprise IT, where abstraction layers insulated applications from hardware choices, today’s AI stack—the infrastructure, technologies and frameworks that powers AI systems – tends  to be tightly co-engineered, with stronger dependencies in the underlying compute layers. Choices made about models, runtimes and compute platforms now shape cost structures, performance ceilings and strategic flexibility. AI-ready infrastructure has re-emerged as a new source of differentiation, and with it, a new kind of vendor lock-in.

At the center of this shift is the move from training – building AI models – to inference, where those models are used in production to generate outputs from new data. While early attention focused on the cost of training large models, enterprises are now scaling AI across the organization, running models continuously across workflows. This shift significantly changes the economics of AI.

For instance, agentic AI is reshaping infrastructure architecture and platforms because inference is becoming persistent, stateful and increasingly data intensive. As AI Factories scale, the focus is shifting from peak model performance toward sustainable token economics, where the key differentiators are lowest cost per generated token, power efficiency and infrastructure utilization at scale. In this environment, achieving those outcomes requires full-stack optimization across compute, networking, memory, storage and data fabrics, curated and integrated across ecosystem partners. Secure multitenancy and confidential computing are becoming core design principles, and enterprise AI is now ready to be industrialized at scale.

Modern AI infrastructure is a strategic bet

What makes AI infrastructure different is not just scale, but integration. Modern AI systems are built on tightly co-engineered stacks where GPU accelerators, high-bandwidth interconnects, compilers and runtimes are designed in tandem to maximize throughput and efficiency for AI workloads.

To get the massive computing power required for AI, providers design their hardware and software to work exclusively with one another. This has shifted enterprise decision-making from choosing hardware one piece at a time to committing to ecosystems. And that commitment carries consequences.

In traditional IT environments, applications could also generally move across environments with a manageable amount of effort. In AI systems, that assumption breaks down. What appears portable at the model or application layer often depends on deeply optimized components underneath that layer, such as memory handling and compiler frameworks like CUDA or ROCm that are fine-tuned to specific hardware.

We find it useful to think about AI systems as a layered structure:

Accenture

While upper layers retain some flexibility, dependencies increase as you move downward. Changing your foundational AI provider often means having to rebuild and re-optimize large portions of your technology from scratch.

This is why infrastructure decisions in AI feel less like procurement choices and more like strategic, high-stakes bets.

Why switching AI platforms is harder than it looks

In theory, switching platforms should be straightforward. Models can be retrained, applications rewritten, and infrastructure replaced. In reality, the cost of switching extends far beyond hardware or licensing.

• The first challenge is engineering effort. Migrating to different platforms requires engineers to revalidate model behavior, re-tune inference pipelines, and rebuild performance baselines. During this period, teams spend most of their time stabilizing and not innovating.
• The second challenge is hidden dependency. Over time, system optimization becomes tied to a specific stack. This might include latency expectations, batching strategies, orchestration logic and even human workflows. These ties are not always obvious, but they shape how systems behave in production.
• The third challenge is timing. There is never a convenient time to migrate, especially factoring in rising AI infrastructure and inference costs, competitive pressure or scaling demands. Organizations are often forced to switch platforms precisely when disruption is hardest to absorb.

Rethinking performance vs control

Despite these barriers, organizations do switch. In our experience, this typically happens under three conditions.

One common trigger is when the opportunity cost of staying begins to outweigh the cost of leaving. As performance gaps widen across competing ecosystems, inefficiencies accumulate to the point that remaining on the current platform is no longer viable. Another driver comes from shifts in vendor dynamics. Pricing volatility, supply constraints, or misalignment in product roadmaps can introduce risks that force a re-evaluation. Finally, regulatory requirements, data sovereignty constraints or geopolitical shifts can force platform changes regardless of technical preference.

Across all three strategies, one principle stands out. Lock-in is not inherently negative, and openness is not inherently superior. Timing matters more than ideology.

Given these dynamics, the central question for CIOs is not how to avoid lock-in, but how to manage it deliberately. This represents a significant shift in strategies that previously considered vendor lock-in as a detriment. In practice, we see three broad approaches emerge, each reflecting a different balance between performance and control.

Some organizations take a performance-first approach. They optimize deeply within a specific ecosystem because performance directly drives business outcomes. Eli Lilly’s AI Factory is a strong example. The company has invested heavily in a tightly integrated NVIDIA-based stack to maximize throughput and utilization. In this case, infrastructure is a competitive lever and not merely a support function. Higher switching costs are accepted because near-term performance advantages are decisive.

Others lean toward a portability-first model. These organizations prioritize flexibility, governance, and long-term independence over absolute performance. BNP Paribas illustrates this well through its internal LLM platform built on open-source models and controlled infrastructure. By retaining ownership of the stack, the bank ensures data sovereignty, regulatory alignment and predictable cost.

A growing number are adopting a hybrid approach. Rather than applying a single strategy across the enterprise, they segment workloads based on sensitivity to performance, cost and governance. For example, in late 2024, JPMorganChase outlined its approach at a leading cloud and technology conference. It described combining a firm-wide internal AI platform with cloud-based services to move generative AI into production at scale. This reflects a broader enterprise pattern of pairing internally controlled environments with external ecosystems to balance control, scalability and cost.

A performance advantage is only valuable if it lasts long enough to justify the lock-in it creates. Similarly, portability only matters if the ecosystem evolves in ways that make switching worthwhile. This is where many organizations struggle. They evaluate platforms based on current benchmarks rather than the direction of the ecosystem.

In practice, we encourage leaders to track a set of evolving signals. These range from the maturity of open compiler ecosystems and improvements in cross-platform runtimes, to shifts in performance per watt and increasing regulatory focus on sovereign AI. Together, these indicators help determine whether the industry is moving toward convergence or further fragmentation.

Conclusion

AI is forcing a reset in how technology leaders think about IT architecture. The goal for CIOs is no longer to eliminate dependency, but to choose it consciously and manage and revisit that choice over time.

In our experience, the most effective organizations treat this as a dynamic problem. They evaluate where performance truly differentiates them, where flexibility protects them, and how quickly those boundaries are shifting. They also recognize that some degree of re-platforming is inevitable and plan for it, rather than treating it as a failure.

Ultimately, AI infrastructure strategy is not about optimizing for today’s conditions. It is about getting ready for where the ecosystem is going next. The leaders who navigate this well are not those who avoid lock-in entirely, but those who understand when to embrace it when to limit it and when to move beyond it before the market forces that decision on them.

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

I have sat in enough post-pilot reviews to know how this story ends before anyone says a word. The pilot worked. The demo went well. The executive team was genuinely impressed, and someone in that room used the word “scale.” There was real energy. Leadership was aligned, the business case was solid and the timeline looked achievable. Then three months passed. Then six. The deployment is still pending, the original team has scattered and the business has quietly concluded that IT is great at demos and slow at everything that follows.

I am not describing a technology failure. I am describing what happens when an AI initiative arrives at an organizational problem that predates it by years and finds no one with the authority to resolve it.

What killed the deployment was the meeting nobody planned for. It happened sometime after the pilot ended and before anyone had agreed on who owned the data the model needed to operate in production. I have watched this sequence play out often enough to stop treating it as a project management gap. It is a structural one, and it was waiting long before the first model was ever trained.

The data question nobody ever had to answer

Most enterprises have been managing data ownership ambiguity for decades. It was survivable because the technologies they relied on could work around it. A BI team could pull a clean extract for the quarterly report. A data warehouse could house a copy of the customer record without anyone deciding who was responsible for keeping it current. Shadow IT could build departmental workarounds that served specific needs without ever touching the underlying question of where authoritative ownership sat. Data was treated as a byproduct of operations, managed by whoever built the system that produced it, with no named owner accountable for its accuracy or use.

The cost of that arrangement was low enough, for long enough, that it never forced a decision. In many organizations I have worked with, asking who owns a specific dataset produces three different answers depending on who you ask. That was tolerable when the stakes were a dashboard that was sometimes wrong. It stops being tolerable when a production AI model is making workflow decisions or customer-facing recommendations based on whatever that dataset happens to contain on a given day.

Putting a model into production that operates on live customer data, contract language or financial records requires someone to make binding calls about access rights, update protocols, data lineage and accountability when the underlying data is wrong. Those are not technical decisions. They are organizational ones. They require a business owner who will stand behind the data, with the authority to make and enforce decisions about how it is used, updated and governed. The data debt that accumulated across years of deferred ownership decisions does not disappear when a pilot succeeds. It surfaces when you try to scale.

Organizations that had resolved this before their first AI deployment did not have better technology. They had usually been forced into the conversation by something else entirely: a regulatory exam, a failed ERP migration, a data breach that made the question of accountability suddenly expensive. The organizations that had not resolved it discovered what the ambiguity costs when AI made it impossible to defer any longer.

What the meeting looks like and what it costs

Here is how the meeting tends to go. The CIO or a project lead convenes the stakeholders whose data the production deployment will require. Sales says they own the customer relationship data, but Legal says the underlying record is a shared asset subject to retention policy. The data engineering team says they manage the pipeline but do not make ownership decisions about what flows through it. The CDO, if one exists, says any governance change requires a committee review and a documented policy update. Nobody is technically wrong. That is exactly what makes it so difficult to move.

What follows is usually a working group, a governance charter and an executive sponsor who was not in the room when the pilot was approved. These are not bad things, but they take time and they consume organizational energy that nobody budgeted for when the pilot looked like a clean success. The AI project is now waiting on an organizational redesign question that predates it by a decade.

I have seen this stall run six months. I have seen it run considerably longer. During that time, the CIO absorbs questions from the business about why the technology that worked so well in the demo is not yet live. The honest answer is that the organization is working through a governance question that the business itself has never resolved, but that answer does not land well in a status update. What the business experiences is an IT initiative that worked in a controlled environment and then stopped. That perception accumulates. The CIO who delivered an impressive pilot is now the CIO who cannot seem to execute.

By the time the data question is settled, the original business champion has often moved on to other priorities. The vendor relationship has cooled. The momentum that existed in the room after the demo is gone, and rebuilding it requires re-educating stakeholders who have already withdrawn. Each deployment that stalls this way makes the next proposal harder to fund and harder to staff with the business partners who matter.

The cost is not only the delayed deployment. It is the credibility spent in the gap and the reduced appetite for the initiative that comes after it.

What the CIOs who got through it actually did

The CIOs I have seen navigate this well made one consistent choice: they resolved data ownership before seeking approval to expand scope, treating it as a prerequisite the deployment required rather than something the deployment would eventually sort out. They forced the data conversation into the open at the level where binding decisions could actually be made. They brought it forward as a business decision, routed to whoever held authority over the relevant business processes and did not move forward until they had genuine alignment, the kind that would hold when the first access request actually landed.

Some of them used the pilot phase deliberately to surface the ambiguity. They ran the pilot on a constrained, clearly-owned dataset and watched where the ownership questions appeared as they tried to expand access. They documented those specifically. By the time they were presenting pilot results to the executive team, they had a clear account of the organizational work the deployment would require alongside the technical work. They did not present this as a problem. They presented it as part of the plan, which is what it is.

That approach requires more work before the first executive briefing. It is significantly faster in aggregate, and it changes what the CIO is accountable for. Framing the data conversation as a business decision, at the beginning, means the CIO is no longer absorbing blame for a governance failure that belongs to the organization. The deployment either moves forward with ownership settled or it does not move forward at all, and everyone in the room understands why. The organizations that skip this conversation tend to find out what it costs about four months after the demo. Some of them find out several times before they change the sequence.

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

For the past few years, the most visible corner of the AI market has been easy to caricature: OpenAI gets the consumer attention, Anthropic gets the developer love, Google gets the benefit of the doubt with increasingly capable models and a complementary product suite, and everyone else gets to explain why they’re not dead yet.

That’s unfair, of course, but not completely wrong. In AI, attention compounds and it’s leading to outsized revenue, with both OpenAI and Anthropic reportedly rushing toward trillion-dollar-sized IPOs on the backs of billions in revenue.

So it’s easy to underrate Mistral AI.

Honestly, I hadn’t thought of the Paris-based company for a year. Maybe longer. But then Brian Hall announced he’s joining Mistral as CMO, and I had an Arrested Development “Her?” moment. Hall, a longtime Microsoft exec, hired me at AWS and went on to run product marketing at Google Cloud. His move prompted curiosity because Mistral doesn’t dominate developer chatter in the United States or boast the same seemingly endless compute budgets as Anthropic or OpenAI. If the AI market is simply a race to build the biggest, most magical, most general-purpose model, Mistral isn’t the company to bet on.

But that’s the wrong question, and likely the wrong bet.

The more interesting question is when the enterprise AI market will revert to type and demand that AI deliver the same security, predictability, and control we’re used to from other IT investments. Here Mistral has a real story. As Hall notes, Mistral’s approach is to “prioritize AI for mission-critical environments that need the confidence and self-control to bet for the long term (with open weights and real sovereign capabilities).”

While this might have sounded like an overly hopeful talking point, it became real in June when the US government ordered Anthropic to suspend access for foreign nationals to its most advanced Fable 5 and Mythos 5 models. Anthropic said it would disable the models for all users because of the export-control directive. “Can this vendor be forced to turn us off?” is no longer a theoretical question.

That’s why Mistral’s quiet focus on enterprise control just might work.

The wrong race

The enterprise control story is much more compelling than the narrative I used to hear. You know, the “Europe needs its own OpenAI” schtick. There is a market for “patriotic AI,” but it’s relatively small. The far bigger market is comprised of enterprises that just want AI that works, costs less (or delivers more) than expected, and can be customized while fitting their compliance requirements.

Though the company’s initial launch page went out of its way to mention that the company was operating out of Europe and headquartered in Paris, since at least October 2023 Mistral’s product posture has centered on enterprise control. Scattered throughout its current (and past) website are words like “customize,” “fine-tune,” “open source,” and “complete control.” Mistral pitches Studio for building and running AI apps, Forge for custom model training and alignment, Vibe for agentic work, Vibe for Code for coding workflows, and Compute for training and inference infrastructure. The company talks about observability, evals, guardrails, deployment portability, and running production AI “from edge to cloud.”

In other words, it sounds less like a chatbot company and more like an infrastructure company.

That positioning becomes clearer when you look underneath the product names. Mistral AI Studio includes an AI Registry that acts as a system of record for agents, models, data sets, judges, tools, and workflows. It tracks lineage, ownership, and versioning. It enforces access controls and promotion gates before deployment. That’s boring governance plumbing (and “boring” is good in enterprise IT, as I’ve written).

Forge may be even more important. Mistral describes it as a way for enterprises to train frontier-grade models on proprietary enterprise data. Rather than training on others’ copyrighted information strewn across the web or on a mountain of Reddit posts, Forge goes well beyond retrieval-augmented generation (RAG) to not simply “read in” proprietary docs/info/etc., but rather to give an enterprise its own private OpenAI, as it were. 

That’s super interesting.

But is it different? I mean, OpenAI and Anthropic can do plenty of this, with greater scale and the benefit of leading frontier models. Both have enterprise products, cloud partnerships, evals, agents, governance tools, and varying forms of model customization. Mistral’s bet with Forge isn’t that the big labs can’t customize models. It’s that some enterprises aren’t interested in customization as a side feature bolted onto a frontier API. It is the product. OpenAI and Anthropic can build everything around Forge but not Forge itself, because the one thing they almost certainly aren’t interested in selling is independence from them.

This is where Mistral may have found a useful seam, one that allows it to ask a different set of questions. What if the best enterprise model isn’t the smartest general-purpose model? What if the best model is the one that’s small enough to run where the customer needs it, open enough to inspect and adapt, cheap enough to use broadly, and specialized enough to do the job? What if “good enough, governable, and your own” beats “slightly smarter, mostly opaque, and rented”?

This won’t matter for every use case, of course. If I’m asking AI to reason through a spreadsheet or write code, I probably want the best model I can get. But for banks, defense agencies, manufacturers, utilities, telcos, and governments, “best” is multidimensional and includes questions like latency, auditability, etc. It’s why banks, for example, still run so many workloads on premises: They want control.

What about compute?

None of this makes compute irrelevant. But it may change how compute matters.

If Mistral is trying to be a French version of OpenAI, its lack of hyperscale compute is a fatal weakness. It won’t outspend OpenAI, Oracle, Microsoft, Google, Amazon, SpaceX, or Anthropic. It probably won’t out-recruit them across every frontier research area, either. The AI market is already littered with companies that underestimated how quickly “good model” became “not good enough.”

But if Mistral is trying to become the enterprise-controlled AI layer for organizations that don’t want all intelligence to live behind someone else’s API, compute becomes a more nuanced issue. It still needs infrastructure, and Mistral seems to know it. After all, Mistral raised $830 million in debt to buy 13,800 Nvidia chips for a data center near Paris. That’s a rounding error compared to OpenAI and Anthropic, of course, but the real question is whether Mistral can turn relative compute scarcity into a virtue, like Amazon’s Leadership Principle “Frugality” on steroids. If lower compute capacity leads Mistral to deliver smaller, more efficient, and more specialized models, which in turn helps enterprises maintain more control of their data at lower cost, then less really does become more.

Mistral’s compute challenge, then, is not to try and have as much compute as OpenAI. It’s to make customers care less about raw compute scale and more about deployment flexibility, specialization, and control.

That’s a hard sell. But it’s not a dumb one.

What Mistral must prove

The bear case remains obvious. OpenAI has consumer distribution, developer mindshare, capital, and a brand that has basically become synonymous with AI. Anthropic has become the developer darling and has an unusually strong enterprise story of its own. Google has the models, the infrastructure, the data, and a bevy of complementary services. AWS, Microsoft, and Oracle have customer relationships and infrastructure.

Mistral has to prove that there’s room for another center of gravity. More specifically, it must prove three things.

First, it has to show that open-weight and controllable AI matter enough to influence buying decisions, not just conference panels. Everyone says they want control, just as most like the idea of open source. But proprietary software and cloud services still dominate the market. Mistral must make control feel like the easy button.

Second, it must prove that specialization beats generality in enough high-value markets. “Our model is almost as good” is not a strategy. “Our model is better for your bank, your government agency, or your retailer” just might be.

Third, it needs to establish a beachhead within enterprise IT before OpenAI and Anthropic become “boring” enough to satisfy the same buyers. This is the real race. The biggest AI companies are hiring enterprise sales teams, building admin controls, and cutting deals with every major cloud. Mistral’s window exists because the market is still young, but that window won’t stay open much longer.

If AI remains a model benchmark race, Mistral likely loses. But if AI keeps evolving to become grown-up enterprise infrastructure, Mistral has a real chance.

A new form of vendor lock-in is here. And it’s not proprietary languages or rigid enterprise software suites — it’s something more fundamental. It’s the very thing that writes the code.

JetBrains Research found that 74% of developers worldwide use AI tools. Claude Code, available only since May 2025, is now the most popular AI coding tool, followed by Gemini Code Assist and GitHub Copilot, according to Jellyfish’s 2026 State of Engineering Management Report.

The latter study also found that 91% of developers say their productivity has increased in the past 12 months. As coding output expectations are rewritten daily, the engineering world is becoming heavily reliant on paid external AI services.

Gartner predicts that by 2028 spending on AI coding tokens could exceed developer salaries. Yet, tokenmaxxing while vibe coding through a vendor’s cloud-based API feels like a far cry from the open foundations of free programming languages and open models, which many of today’s AI platforms now abstract.

“Open infrastructure will be the backbone of the AI era,” says Peter Farkas, CEO of Percona, a provider of open-source database solutions. “Right now, too many companies are building their entire AI strategy on top of proprietary platforms because the convenience is seductive.”

“It’s ‘three clicks’ to stand up a database or an AI service in a hyperscaler, and that convenience blinds people to the lock-in they’re signing up for,” he adds. “As AI workloads mature, organizations will realize that depending on one vendor for their data, models, runtime, and pricing is not a strategy.”

AI-assisted coding is democratizing software engineering for non-engineers and accelerating top performers. But if teams are always working within the confines of how one platform thinks the world should work, it could create locked-in toolsets at scale. And as AI platform costs rise, a fundamental question arises: will software developers consume AI on their own terms, or on someone else’s?

There’s a strong case that the long-term winners in tech will be built on open-source standards and foundations, similar to the history of cloud-native computing and the internet itself.

“Open always wins,” says Brian Alvey, CTO at WordPress VIP, a managed WordPress hosting platform. “Not because it’s a fancy ideology, but because it gives you total freedom to adapt, evolve, and stay in control.”

Open infrastructure avoids a future where developers perpetually rent. “For AI to be useful to people at large, it can’t be something you’re paying rent for the rest of your life,” says Manik Surtani, CTO and co-founder of the Agentic AI Foundation (AAIF), a vendor-neutral home for open-source agentic AI technologies. “And it can’t be concentrated in one particular corporation or a small handful of corporations, because we know how that goes.”

Pricey, closed, proprietary AI

AI development today is traveling two parallel paths. On one path, open-source AI is thriving and fueling tremendous growth in the number and variety of AI models and tools. Just take the thousands of open-weight models on HuggingFace, the community around the OpenClaw AI agent, or the many academic institutions publishing new breakthroughs.

“Open-source models and tooling are hot on the heels of state-of-the-art, with interesting and boundary-pushing work being shared by labs and researchers across the world,” says Austin Parker, director of AI strategy at Honeycomb, an observability platform provider, citing frontier open-source models like Mistral, DeepSeek, and Ai2’s OLMo as examples.

Others agree. “There’s unprecedented openness at the model and tooling layer, with open-source models, frameworks, and orchestration advancing at remarkable speed,” says Mark Collier, general manager of AI and infrastructure at the Linux Foundation.

On the other path, we’re seeing heavy reliance on proprietary AI systems controlled by Anthropic, Cursor, Google, Microsoft, OpenAI, and others. As Collier says, “Many platforms are wrapping those open components in closed, opinionated interfaces that trade short-term speed for long-term constraints.”

Open source and the AI tooling market don’t always mix well. LangChain’s Open Agent Platform, for instance, was open-sourced to much fanfare in 2025, but by 2026 had been deprecated, with the repository now recommending fully managed alternatives.

For Roman Shaposhnik, co-founder and CTO of Ainekko, provider of an open-source, composable AI stack, the current AI platform landscape is reminiscent of low-code and no-code platforms, which promised democratization of software development but often failed to deliver, becoming synonymous with platform lock-in and inflexibility.

“Honestly, it feels familiar,” Shaposhnik says. “We have incredibly powerful AI tools right now, but most of them come bundled as tightly controlled platforms.” This is a risk for AI, he says, because the infrastructure, models, and hardware are tightly coupled. “If those layers are closed, you lose flexibility fast.”

Some abstractions that sit on top of models, like routing and agent frameworks, tend to be tightly coupled and optimized for certain models. Other platforms take the walled garden concept quite literally. Anthropic, for instance, has repeatedly made headlines for blocking access to its Claude models over vague policy violations. The company recently shut off competitor xAI’s use and stonewalled OpenCode, drawing community backlash.

Moves toward increasingly closed systems don’t bode well for an AI economy already built on shaky economics. As Vikram Srivats, head of product experience at WaveMaker, provider of an agentic application development platform, adds, “Given the unit economics of AI tooling and pace of accelerated change to keep up, it seems obvious that some will evolve to more of a closed system to be able to monetize and gain ROI.”

Why openness matters in the AI era

Reliance on proprietary AI platforms can create long-term operational dependencies. As systems become less interoperable, organizations may be forced to standardize on a single stack across data pipelines, models, and decision logic, says the Linux Foundation’s Collier.

“As infrastructure consolidates, enterprises become more exposed when platforms change direction, raise prices, or fall behind technically,” he says. “If you can’t change platforms without re-architecting your AI systems, you’ve already given up too much control.”

“When you build on someone else’s platform, you have to live by their rules and those rules always change,” adds WordPress VIP’s Alvey. “We’ve all seen this before, businesses wasting time and money building to serve Google, Facebook, YouTube, and the App Store, instead of building to serve their customers.”

Platform lock-in can also create direct business risk. As Ainekko’s Shaposhnik says, “It usually shows up as higher costs, fragile systems, and growing risk when it’s time to change direction.”

At Ainekko, an internal group called the AI Plumbers focuses on back-end AI infrastructure like inference, scheduling, memory, and hardware integration. “Their view is simple,” says Shaposhnik. “If those layers are closed, everything above them becomes fragile.”

Open standards, interfaces, and infrastructure provide a necessary hedge against closed systems to prevent this sort of fragility. “In the AI era, open infrastructure gives enterprises control, portability, and choice at exactly the time they need it most,” says Percona’s Farkas.

It can cost upwards of $100,000 to migrate enterprise software, according to Cloudaware, making portability a major enterprise concern. From this perspective, procuring closed systems can become a costly architectural dependency.

Others argue that openness is a critical hedge against vendor concentration risks at large, especially if AI replaces human labor en masse. “If all of that economic value is now being concentrated in the hands of one or two companies,” says the AAIF’s Surtani, “that’s an order of magnitude bigger problem than we’ve seen in any other wave of computing.”

Instead, open foundations allow adaptability to evolving conditions so enterprises can swap out models, agents, data, hardware, and orchestration, as needed. “Open standards let those components change independently without breaking the system,” says Collier. 

Openness can also help future-proof businesses against economic upheaval. “Open everything will help build a cushion for businesses and users to survive and thrive after the almost-certain correction in the current hype cycle,” says WaveMaker’s Srivats.

Momentum toward open AI infrastructure

At the industry level, momentum toward open AI infrastructure is growing. The establishment of the Agentic AI Foundation, Anthropic’s donation of Model Context Protocol (MCP), and Block’s donation of its Goose agent are significant ecosystem-wide moves toward openness. Other advances include the donation of llm-d, a Kubernetes framework for LLM inference, to the Cloud Native Computing Foundation (CNCF).

For Parker, donations like this help ensure long-term support and care. “Open standards aren’t just the foundation of the internet, they’re the foundation of the AI space,” he says. “I predict that we’ll see these practices continue, especially as enterprise adoption increases in earnest,” he adds.

Still, some question whether this level of stewardship is enough for a rapidly evolving ecosystem. “The internet benefited early on from groups that helped keep vendors aligned,” says Shaposhnik. “In AI infrastructure, we don’t really have that yet.”

“All of us open source veterans are hopeful,” he says, “but we also need to adapt to this new reality in what we do regarding AI infrastructure.”

Beyond industry governing bodies, companies themselves are also spearheading open AI initiatives. Warp, an agentic development environment, recently went open source amid closed-source rivals. Arcade.dev, meanwhile, is pushing an open-source Agent Library for agentic memory.

Where openness matters most in the AI stack

While AI infrastructure can be open in many ways, a few layers stand out as especially important. First is the openness of the model itself. “Open-source models must be the foundation of future trust and value,” says WaveMaker’s Srivats.

“The forms of open infrastructure that reduce integration friction and accelerate adoption stand out,” adds Neeraj Abhyankar, VP of data and AI at R Systems, a global digital solutions provider. For him, open model representation formats, open orchestration and execution layers, open agentic protocols, and open governance and metadata standards are all essential for enterprise flexibility.

Others place more value on the connective tissue between AI components. “The most important forms of open infrastructure are the ones that connect systems together,” says Collier. “That includes open APIs, metadata standards, identity and policy frameworks, and protocols for how models and agents communicate.” 

Arguably, MCP has become the connective tissue between AI agents and the broader API ecosystem. “If we get MCP right we unlock the same level of interoperability between entities on the web and models driving them as we came to enjoy during the Web 2.0 era and the API-first boom,” says Shaposhnik. “If we don’t we risk massive proprietary lock-ins.”

Parker agrees that open protocols will underlie future AI progress. “We’ll see continued development and progress on AI agents which will rely on protocols like MCP and ACP [Agent Client Protocol] to interoperate with various clients and each other,” he says. Yet a gap remains around API conventions for models. “It would be nice if we could get a commitment from model providers to use a standard here.”

For the AAIF’s Surtani, opening up the protocol layer is the most important aspect. “I think it’s really important for interoperability, for choice,” he says. “It means you can bring your own agent, you can bring your own framework, you can bring your own harness, and pick what model you want.”

Open standards may also play a significant role within inference architecture. “As AI expands to the edge, developers need visibility into how models run, how memory is used, and how performance scales,” says Shaposhnik. Open systems could make it easier to optimize, debug, and adapt while helping enterprises avoid observability fragmentation.

Lastly, cloud-native architectural standards are a key ingredient for open AI infrastructure. “We’re seeing Kubernetes become the missing link for people who want the hyperscaler-style convenience without hyperscaler lock-in,” says Percona’s Farkas. For him, Kubernetes has become the de facto hybrid enterprise deployment option for data, workloads, and AI components.

History repeats itself

The 2026 State of Open Source Report found avoiding vendor lock-in to be the primary driver of open source adoption. But beyond being a strategic decision for a single company, open infrastructure provides a layer for entire industries to be built upon.

Arguably, the internet itself is evidence of this, where groups like the IETF and the IEEE were instrumental in defining the fundamental protocols. “Without open protocols we would’ve been in telco hell and without phenomenons like Google or Facebook,” says Shaposhnik.

Or, take the history of Linux as a parallel. “Linux became the default operating system because it offered a common, vendor-neutral foundation that everyone could build on,” says Collier. “In the AI era, open infrastructure will define the layers that organizations rely on for long-term continuity.”

At the infrastructure level, open standards have repeatedly underpinned major platform shifts, from Docker to Kubernetes. The question now is whether AI will develop a similarly durable standards layer.

For Parker, it’s too early to say, but the current growth of AI mirrors the early cloud. “Remember that it took many years before we saw the development and popularization of the open source cloud-native ecosystem,” he says. “I think it would be a mistake to extrapolate from the current trajectory towards a closed, proprietary future.”

Others agree the future must be rooted in openness. “I see open infrastructure becoming the foundation of enterprise AI,” says R Systems’s Abhyankar. “As systems become more distributed and agent‑driven, closed ecosystems simply won’t scale.”

The groundwork is being laid through open agentic protocols, open frameworks, and industry support intended to reduce fragmentation around proprietary standards.

“Ironically, the AI movement has mostly seemed to learn from the mistakes of the past and is starting off on a more open foot,” says Parker. “Over time, I believe we’ll see innovation and openness thrive.”