Walking around Dubai, it’s hard to believe a war is still going on in neighboring countries.

No missiles have struck the city, and it was clear during a recent visit that local residents are keeping to their routines. The biggest public worry, as it has been in many parts of the world, is the extreme heat. (The high today is around 106 degrees.)

Dubai, one of seven emirates in the United Arab Emirates (UAE), continues to emerge as a major global tech hub and is on the verge of becoming a major AI powerhouse. Each of the emirates has their own laws and traditions, with Dubai and Abu Dhabi — the UAE capitol — the most prominent.

Other nations recognize the region’s potential and Dubai’s position. The US, for instance, showed interest in currying favor with the UAE by sending a CIA spy to vet the emirate’s top AI firm, paving the way for future chip and AI deals. That outreach, highlighted in a report in The Wall Street Journal, was a hot topic in the local tech community.

These days, Dubai and Abu Dhabi hope to position themselves as hubs where people and companies go for AI. It’s location makes it an excellent place to do business with connections to Asia, Europe and Africa.

Broadly speaking, the UAE wants to be something of a Switzerland for AI, or “a neutral AI corridor between East and West,” Mahmood Abdulla, a regional technology expert, explained in a 2025 LinkedIn entry.

Data center buildouts

While states like New York are putting a moratorium on the construction of data centers in the US, the UAE is moving in the opposite direction; an aggressive AI data center buildout has government backing.

Stargate UAE, a data center project that involves top tech firms such as OpenAI and Oracle, is being built in Abu Dhabi. The city has essentially planned out a business model designed to turn AI into hard cash with a focus on the energy resources that will play a major role in the effort.

The plan is to redirect Abu Dhabi’s vast energy resources — it has up to 100 billion barrels of known oil reserves — to data centers generating AI tokens. Those tokens can then be sold as compute resources to produce revenue.

With oil markets volatile because of ongoing conflicts and the worldwide rise of renewables, pushing energy use to AI data centers might be a more reliable form of revenue long term.

Will it work? That remains to be seen. But unlike the US backlash against data centers construction in many place, a ban here seems unlikely.

The entrepreneurial spirit

Technological innovations from entrepreneurs have been at the core of Dubai’s rapid growth in recent years as a global business center. Here, AI is already quietly woven into daily life, much as it is in China, where AI is already in factories, homes, and infrastructure.

One founder told me that naming his company to include “AI” is more of a US thing. UAE companies focus less on boasting about AI models and superintelligence; they tend to emphasize user experiences.

On a separate track, Dubai is already targeting the launch later this year of robotic air taxis flying from the airport into the city. (That’s ahead of New York City, where electric air taxis are still being tested.)

Still, Dubai is behind the US when it comes to autonomous ground transport. The first autonomous taxis hit Dubai streets just last year, and there are a limited number operating in tourist areas.

A complicating face tor for the area remains the Iran war. Dubai’s Internet City, a hub with buildings belonging to the likes of Microsoft, Oracle and IBM, largely emptied when the war started in late February. Foreign tech workers left, and property prices declined.

But the real estate market is booming as opportunistic investors buy low. Their bet: the US-Iran war won’t stop the UAE’s growth.

Money is flowing into the area in other ways. Heavy tax burdens in Western countries are pushing wealthy founders to move businesses to Dubai’s tax-free environments. And Dubai is opening the door to those with digital nomad and freelance visas. Although visas can cost thousands of dollars a year, lower rent and healthcare costs compared to the US can offset those costs.

Rivals are emerging, too

UAE’s economic rival, Saudi Arabia is also rising as a tech powerhouse. Riyadh has undertaken reforms at a rapid pace to become an attractive place to do business under its Vision 2030 program.

Saudi Arabia requires corporations to have regional headquarters in the country to win government contracts, a policy that challenges Dubai’s status as a regional business hub.

The UAE also relies heavily on immigrants and human labor, which can be both a plus as well as a challenge. There is no pathway for entrepreneurs or long-time tech workers to retire here, which can undermine worker motivations to stay.

Still, the attractive business environment, combined with local infrastructure and a skilled labor force, make this area appealing. As one founder told me, if the US doesn’t want its most skilled immigrants, the UAE will be happy to welcome them with open arms.

Anthropic CEO Dario Amodei has argued that policymakers should keep lower-risk open-weight AI accessible while placing stricter safeguards around frontier systems, including mandatory testing and limits on China’s access to advanced computing and model capabilities.

In a post outlining Anthropic’s position, Amodei said broad restrictions, including bans on Chinese open-weight models used by US businesses, would not address his main national security concerns. Instead, he pointed to the possibility of authoritarian governments surpassing the US in advanced AI, as well as cyber, biological, and alignment risks posed by increasingly capable systems.

Amodei also called for action against industrial-scale model distillation, which he said allows Chinese developers to improve their models with less computing power than would be needed to train comparable systems from scratch.

The statement followed criticism of Anthropic for not signing an industry letter backed by Nvidia, Microsoft, Meta, IBM, Mistral, Hugging Face and other technology companies urging policymakers to avoid premature restrictions on open-weight models.

The letter said that open weights could broaden access to AI, intensify competition, and enable organizations to adapt and deploy models without relying on a single provider. Amodei agreed with parts of that case but disputed claims that openness inherently improves safety research or gives defenders an advantage over attackers.

He said regulation should be based on a model’s capabilities and risks rather than whether its weights are openly available. Under that approach, sufficiently capable open and closed models would undergo testing before release.

Conditional support

Analysts said Anthropic had moved closer to industry consensus by rejecting blanket bans, but its support remained more limited than the approach backed by many major technology companies.

Deepika Giri, head of research for AI, analytics, and data at IDC, said the Nvidia-backed letter presented open weights as strategic infrastructure that should remain broadly accessible, in contrast with Anthropic’s more restrictive position.

Amodei’s statement clarified that Anthropic supports open-weight models only under certain conditions, a stance that could also help the company preserve its competitive advantages as a proprietary model provider focused on compliance and tighter controls, according to Lian Jye Su, chief analyst at Omdia.

The statement was “a real olive branch” to supporters of open-weight models, according to Pareekh Jain, CEO of Pareekh Consulting. But he said the disagreement had shifted from whether such models should be released to where policymakers should draw the line.

“Anthropic still thinks that once a model gets powerful enough, releasing its weights publicly is riskier than keeping it locked behind an app, because you can never take it back or add safety fixes later,” Jain said.

Will the controls work?

Analysts differed over whether Anthropic’s proposed controls would achieve their aims without creating new barriers for smaller AI developers.

Jain said chip restrictions and measures against illicit model distillation would mainly affect model developers and infrastructure providers, rather than enterprises using models already on the market. Mandatory safety testing, however, could raise development costs and reduce the number of advanced open-weight models available.

“Testing is expensive and time-consuming, and so, giant, well-funded companies like Anthropic, Google and OpenAI can afford it,” Jain said. Smaller developers seeking to release cutting-edge open-weight models could struggle to meet the same requirements, he added.

The additional testing and screening could also restrict the number of open-weight models available to enterprises, according to Su. He said the requirements could weaken some of their principal benefits, including lower costs, reduced vendor dependence and community-led development.

Anand Joshi, managing director of market research firm JP Data, questioned whether limiting China’s access to advanced chips would materially slow its AI development, arguing that Chinese companies had shown they could build highly capable models with less computing power. He supported action against illicit distillation, however, saying safeguards were needed to prevent developers from reproducing the capabilities of other models without authorization.

The impact on most enterprise users could remain limited if less capable models were exempted, Jain said. Businesses deploying models that fall below the proposed testing threshold would probably face little additional cost.

How CIOs should choose

Giri said CIOs should assess models according to their capabilities rather than whether they are open, and should demand independent testing, clear licensing, model documentation and accountability for monitoring and incident response.

“Mandatory safety testing should be triggered by a model’s demonstrated capabilities, not its size or training cost,” Jain said, particularly when a system could significantly assist cyberattacks, biological misuse, or autonomous harmful actions.

Before deployment, CIOs should seek independent evaluations, detailed model documentation, security test results and information about the model’s software supply chain, he added. Charlie Dai, principal analyst at Forrester, said that assessment should include documented red-team results, model provenance, disclosures about training and fine-tuning, and evidence of independent testing against recognized safety benchmarks.

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.

A client called me last week with a problem I have been hearing about more often lately. They had made significant reserved instance commitments with a major cloud provider, overbuying for what they thought would be heavy AI training workloads. Now they were sitting on thousands of dollars in idle capacity every month. Their plan was simple: resell it to someone else. Except they couldn’t.

I have been doing cloud consulting for a long time, and this situation once had a straightforward solution. You went to the marketplace, listed your unused reservations, and found a buyer. The process was a bit clunky, but it worked. These days, the answer is far more complicated, and my client learned this the hard way.

AI has made this problem increasingly common. Companies initially committed to compute capacity based on ambitious training plans. Prototype projects were expected to scale, and inference workloads were projected to grow substantially. Then reality hit. Some projects did not materialize. Some models trained faster than expected. Some inference patterns were lighter than anticipated.

Many organizations now hold reserved capacity they can’t use, discard, or share without a complex, increasingly restricted process. This reality is something every company with significant cloud spend needs to clearly understand.

The history of cloud resale

There was once a functioning resale market for cloud reserved instances. AWS, for example, maintained a Reserved Instances Marketplace where companies that had purchased reserved capacity could sell those reservations to other AWS customers. This was a legitimate, AWS-sanctioned process. Companies would register as sellers, list their unused reservations with pricing and terms, and if a buyer appeared, the marketplace would facilitate the transaction.

The resale market was useful for companies that had overestimated their needs or whose business changes reduced their cloud consumption. Instead of simply absorbing the cost of unused commitments, they could recoup some of that investment by selling to other organizations with unmet demand. It created a secondary market that added liquidity to what was otherwise a rigid financial arrangement.

My client had some experience with this resale market a few years ago and assumed they could use it again. They were unpleasantly surprised to learn that the rules had changed.

AWS changes the rules

In January 2024, AWS implemented a significant policy change that effectively shut down the resale of EC2 Reserved Instances on its platform. AWS stopped allowing companies to resell their unused reserved capacity through the Reserved Instance Marketplace or any other official channel. If you have a reserved instance commitment with AWS, you are essentially stuck with it unless you can use it yourself or modify your reservation.

This change had a real impact on companies that had relied on resale as part of their cloud financial management strategy. It reduced flexibility and increased the risk of long-term reserved commitments. When I explained this AWS policy change to my client’s representatives, I could hear the frustration in their voices. They had made their commitment in good faith, carefully modeled their expected AI workloads, and now faced the reality that there was no easy exit.

The reasoning behind this change is not entirely clear, but AWS likely viewed capacity resales as something that complicated their billing and commitment models without providing enough benefit to the overall ecosystem. Regardless of the company’s reasons, the primary resale path for the largest cloud provider has been effectively closed.

What options still exist?

What can companies do now when they find themselves with reserved capacity they no longer need? The first possibility is to work directly with the cloud provider to modify or exchange the reservation if it is convertible. Some reservation types allow modifications, such as changing the instance type, region, or tenancy. This will not eliminate the commitment, but it may help companies better align their reservations with actual workload needs.

The second option is to use third-party brokers and marketplaces that operate independently of the cloud providers. Although AWS has shut down its official resale channel, brokers and marketplaces still facilitate resale arrangements for other cloud providers and for some AWS scenarios. These arrangements can be more complex and carry more risk, but they remain a possibility for companies determined to move unused capacity.

The third alternative is to optimize usage. Companies can invest in better utilization monitoring, workload placement, and automation to ensure that reserved capacity is used as efficiently as possible. This does not recover the money already spent, but it reduces future waste.

My client explored all three alternatives and found that each had significant limitations. Modifications were possible, but only within a narrow range. Third-party brokers were interested, but the process was opaque and uncertain. Optimization helped, but it could not eliminate the fundamental overcommitment they had already made.

The broader implications

Cloud commitments are more rigid than many enterprises initially realize because they lack a liquid market and because providers control modifications, transfers, or cancellations. Right now, I see this pattern most often in the AI space. Companies commit to massive amounts of compute for training and inference based on projections that rarely reflect the actual workloads. Then they are surprised to find themselves locked into payments. The AI boom has led to significant overcommitment because enterprises remain unaware that the resale mechanisms that once existed have been largely shut down.

This is why cloud financial management has become such an important discipline. Companies need to be far more thoughtful about how they commit to cloud resources, how they model their future consumption, and how they build flexibility into their cloud strategies. The days of assuming you can always resell your way out of an overcommitment are effectively over, at least with AWS.

For Azure and Google Cloud, the resale landscape is slightly different, but the same general principles apply. These providers have their own capacity transfer policies and, like AWS, those policies can change at any time. Companies should understand their options before making large, committed purchases and build contingency plans in case their actual usage diverges from their projections—or if resale policies change.

The bottom line is that reselling unused reserved cloud instances is far more complicated than it sounds. The market is not as open as it once was, the options are limited, and the providers themselves hold most of the cards. My client got burned, and I doubt they will be the only one. Companies that want to optimize their cloud spending should focus on accurate forecasting, thoughtful commitment sizing, and ongoing optimization rather than relying on resale as a safety valve. That approach worked at one point, but those days are largely gone.

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

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

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

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

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

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

Continuity matters more than personalities

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

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

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

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

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

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

Enterprises still carry the burden of AI governance

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

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

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

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

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

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

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

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

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

Jobs involving physical labor are at high risk of disruption from automation, with new technologies such as AI robots becoming more prevalent, according to a recent study by the Organization for Economic Co-operation and Development (OECD). That means workers in construction and extraction, farming, fishing, forestry, production and material transportation could be affected by fast-moving technology changes.

“Routine and low-skilled jobs are at higher risk,” the Paris-based public policy group said, adding that “overall, jobs requiring non-routine cognitive, social and creative skills are less susceptible to automation.”

The kinds of creative and cognitive jobs still thought to be less exposed to automation include social work and community service roles. 

OECD also said management jobs — which often require workers to devise creative answers to solve problems — fall within the creative and cognitive category. “While AI has made some high-skill job requirements more susceptible to automation, many critical skills in these roles remain difficult to automate,” OECD said.

The same still holds true for some physical and manual labor jobs – including cleaners, agricultural workers, food-prep assistants, and laborers — which are less exposed to the affects of AI, OECD said.  

But people who work in programming, translating and interpretation positions could find their work affected by the quick rise of AI tools and services. According to the organization, global AI uptake rose from 7% in 2021 to 20% in 2025.

“In these occupations, GenAI could perform a significant share of tasks at least twice as fast today or in the near future,” OECD said.

The effects of the AI boom are not always uniform across industries or regions. In a separate 2026 Employment Outlook study released by the group, exposure to disruption from generative AI (genAI) ranges from about 16% in some areas to more than 70% elsewhere, depending on industries and occupations. 

Numerous research firms have said in recent years that AI is driving short-term job losses, though tech industry experts and analysts have argued AI will also create new careers and jobs as agentic AI takes over low-skilled work. 

AI technology has become so ubiquitous that it’s been compared to electricity — virtually all companies will need it or at least know how to use it. But it’s adoption has been hindered at times as companies struggle to find ROI from its use, and by regulatory and ethical hurdles.

In the US, AI blamed for June job losses

According to a Challenger, Gray & Christmas study released earlier this month, AI was cited as the top reason for job cuts in June. The outplacement firm said employers cut 45,849 job cuts in June, of which 14,029 were attributed to AI, with the tech industry leading the cuts.

“Tech remains the epicenter of this year’s cuts,” Challenger said. “AI is the dominant force as companies are restructuring around it, automating roles, and reallocating budgets toward new capabilities. The sector is being reshaped in real time.”

Overall, AI has been responsible for 173,568 job cuts since 2021, the company said.

AI is hurting jobs in customer service, internal reporting, telecommunications, and hosting automation, said Victor Janulaitis, a staffing consultant who was formerly CEO at Janco Associates Inc.

“C-level executives continue to be focused on eliminating ‘non-essential’ managers, staff, and services,” he said. “Coders and developers have limited opportunities with legacy applications.”

While jobs in the IT sector overall are declining, current hiring tends to skew in the direction of people with AI skills. A report this month by CompTIA put job listings with AI skills at around 500,000, which is close to double the number in January.

“Employers in other industries are accelerating digital transformation initiatives and moving from AI experimentation to implementation,” said Seth Robinson, CompTIA’s vice president for industry research.

That view dovetails with what ManpowerGroup, the recruitment firm, is seeing; demand for AI-related skills has nearly doubled over the past year, said Ger Doyle, regional president of North America at ManpowerGroup.

That growth extends well beyond traditional technology roles as companies move from experimenting to AI deployments at scale, Doyle said. “We’re seeing it influence hiring across occupations ranging from data science and engineering to project management and operational roles,” he said.

Meta is reportedly planning a cloud business that would sell access to AI computing power and models, extending its internal infrastructure into a commercial service for outside developers and enterprises. Reuters, citing Bloomberg’s reporting, noted that the planned offering would allow customers to access AI models hosted on Meta’s infrastructure and pay based on usage, effectively positioning the company in the infrastructure-as-a-service and AI platform markets. On the surface, this seems like a logical next step. If you are already spending enormous amounts of money to build AI infrastructure, there is a natural temptation to ask whether some of that investment can be monetized beyond your own internal use.

I have seen this pattern before. A company builds sophisticated internal systems, recognizes their value, and then begins to imagine that becoming a cloud provider is simply a matter of exposing those capabilities to external customers. It sounds straightforward, especially given the excitement around AI and the demand for high-performance infrastructure. But cloud computing is not just another distribution model. It is not simply a matter of offering on-demand multitenant services and charging a fee. It is a deeply operational, trust-based business in a market that punishes companies that do not fully understand what enterprise customers require.

A crowded neocloud market

The first problem Meta faces is that this is not an open opportunity. The neocloud space, meaning purpose-built AI infrastructure delivered as a service, is already crowded and increasingly difficult to enter. Amazon, Microsoft, and Google dominate the conversation for obvious reasons. They have years of cloud operating experience, broad service portfolios, global reach, mature ecosystems, and deeply established enterprise relationships. Oracle remains a serious player as well, especially in enterprise applications, data platforms, and performance-sensitive workloads. IBM still matters in hybrid cloud, operations, and industries where governance and regulatory rigor remain central.

That list alone should give Meta pause. These companies are not just infrastructure vendors. They are experienced cloud operators. They have spent years building not only the underlying platforms, but also the native capabilities enterprises now expect by default. Those capabilities include security, governance, identity management, observability, support, compliance, billing controls, resilience planning, and integration with the broader enterprise technology estate. These are not secondary features. They are part of the core value proposition.

This is why late entry into the cloud market is so hard. A new provider is not just competing on price or capacity. It is competing against accumulated trust. Enterprises are not casual buyers. They are selecting long-term operating environments for applications, data, AI models, and business-critical processes. They want confidence that the provider understands how these services will be consumed, governed, and supported over time. Meta is entering a market where the incumbents already have a major head start on all of those fronts.

Harder than it looks

Over the years, I have had many technology companies come to me and say they wanted to reposition their technology in the cloud space, either as software as a service or infrastructure as a service. In the beginning, enthusiasm is always high. The technology is impressive. The market size looks attractive. The revenue models appear compelling. Investors love the story. Then we begin to walk through what it really means to operate as a cloud provider, and the optimism usually fades fast.

The questions become very practical and very uncomfortable. How will tenants be isolated? How will identity and access controls work across different kinds of customers? What governance models will be built in natively? How will workloads be monitored, optimized, and secured? What does support look like 24 hours a day, across regions, across industries, across compliance boundaries? How will outages be handled, communicated, and remediated? How will the platform integrate with existing customer tools for operations, policy management, and security response? How much investment will it take just to become credible before you even begin to differentiate?

Once companies fully understand the complexities, market dynamics, and the capital and execution required to compete even with secondary players, many of them back off. They realize that cloud technology is not a packaging exercise. It is a transformation in how a company designs, operates, supports, sells, and evolves technology. That is why I remain skeptical when any company assumes it can translate internal infrastructure excellence into external cloud success without a very long, disciplined commitment.

Meta’s market readiness

Of course, Meta is not lacking in financial resources. If any company can afford to spend aggressively in this space, it is Meta. The company has the capital to build infrastructure, absorb losses, hire experienced talent, and stay in the market long enough to make a serious attempt. I would never argue that Meta is too small or too poor to try. Quite the opposite. If there is any non-traditional entrant with the financial scale to force itself into the conversation, Meta would be high on the list.

But money does not erase complexity. It only gives you the chance to confront it. The real question is not whether Meta can afford to become a cloud provider. The question is whether Meta has what it takes to become an excellent cloud provider. Those are two very different things. Enterprises are not going to move meaningful workloads to a new platform simply because the company behind it is wealthy or technically famous. They are going to ask whether the provider understands enterprise consumption patterns, enterprise risk, enterprise governance, and enterprise operations.

That is where the challenge becomes much more serious. Meta has extensive experience running infrastructure for itself. That is valuable, but internal operating excellence is not the same thing as external service maturity. Running systems for your own workloads allows a high degree of control over architecture, standards, priorities, and operating assumptions. Running systems for paying customers requires flexibility, consistency, transparency, and support across a wide range of use cases that you do not control. Those are very different disciplines, and companies often underestimate the gap between them.

What exactly is Meta?

Another concern here is strategic clarity. Meta already has a complicated market identity. It is a social media company, an advertising platform company, a hardware company, an AI company, and still, in the minds of many, the company that spent billions pursuing the metaverse. If it now wants to be viewed as a serious cloud infrastructure provider, it will need to explain not only what it is offering, but why customers should believe this is a durable long-term commitment and not just another adjacent experiment.

That uncertainty can be damaging. Customers want stable providers with clear strategic intent. They do not want to architect important systems around a platform if they suspect the provider may lose interest, shift direction, or reframe the business after a few years of uneven results. Cloud computing requires patience, consistency, and deep customer orientation. It is not a market where strategic ambiguity helps.

This could become confusing for Meta internally as well. Building a true cloud business demands focus. It demands years of investment in areas that may not be glamorous but are absolutely necessary, such as governance, operations, controls, support frameworks, partner programs, and enterprise sales alignment. If the company is not willing to make those sacrifices fully and for the long term, the initiative will struggle.

AppleCare+

AppleCare+

The best time for tech workers to unionize was 20 years ago, when they had plenty of leverage. The second-best time is now, when they don’t.

Mass layoffs, AI-driven displacement, corporate surveillance, workplace disillusionment have created conditions that have made organizing compelling for tech professionals. But the federal labor board that has historically protected workers’ right to organize has been weakened, and the companies that once feared it are openly defying it.

Here’s how organizers and labor experts describe the pros and cons to organizing — and how you can get started.

This is Part 2 of a series on tech worker unionization. Also see Part 1: “A brewing battle: More IT workers want unions. The industry doesn’t.”

What unions can — and can’t — do for you

The single biggest benefit of a union contract for most tech workers isn’t pay — it’s protection against arbitrary termination, especially in the wake of recent mass layoffs in tech. In the United States, nonunion “at-will” workers can be fired at any time without a stated reason, while unionized workers negotiate protections written into their contracts.

“That fear of the company letting you go for anything at any time…with a union they just can’t do that,” says Zak Thompson, a senior software engineer at Kickstarter and union steward at Kickstarter United. Now that Kickstarter employees are unionized, people are less worried that saying something negative will result in termination.

“I’ve been shocked at the willingness of my co-workers to speak up against what they see as poor or controversial business decisions,” Thompson says.

Beyond job security, unions can deliver concrete material gains. Kickstarter United was formed in 2020, although getting there wasn’t easy: two employees were fired during the organizing campaign — which itself became a galvanizing event. And while the union hasn’t been able to prevent layoffs, it did negotiate better terms: four months of severance pay and four to six months of continued health insurance, versus the two to three weeks per year of work that management had initially proposed.

Other benefits include a four-day work week; AI protections; a minimum pay floor; and standards for raises, promotions, and time off for the company’s 59 employees.

Unions can give tech workers a voice in decisions that affect their daily work — including how AI tools are deployed. “Nobody I’ve spoken to is against new technology or getting trained in it,” says Max Belasco, a business systems analyst at the University of California Los Angeles School of Law and co-chair of the UCLA chapter of the University Professional and Technical Employees/Communications Workers of America (UPTE-CWA) Local 9119.

“But when new technology is being implemented, we want to know: what’s the five-year vision, the 10-year vision? Are we implementing this in a way that betters staffing, increases efficiency, or eases the lives of people already working? Or are we trying to take away jobs, automate people out of their pension or paycheck?” Belasco says.

The challenges are real. Tech professionals are less inclined to leave their jobs in the current market because wages haven’t been increasing as fast as they once were, and it can take longer to land another job.

“Tech moved from a very tight labor market in 2022 (1.85% unemployment rate) to a noticeably weaker one in 2024–2026 (3.49%),” although that’s still better than the national unemployment rate of 4.36% through May of this year, says Liya Palagashvili, senior research fellow and director of the Labor Policy Project at the Mercatus Center at George Mason University.

Flexibility is a concern. The more substantive challenge, raised by economists including Palagashvili, is that traditional union contracts impose uniform terms across an entire bargaining unit, limiting the flexibility that many tech workers — and their employers —currently enjoy. Tech firms need to move fast, adjusting teams, products, and roles on the fly.

“Collective bargaining agreements can make those adjustments much more difficult, whether by making them slower, costlier, or inconsistent with the contract,” she says.

Workers skeptical of unions in a survey of 1,900 tech professionals conducted by the career site Blind cited specific concerns: that unions are “not meritocratic,” “prevent innovation,” and “hold back earnings of top performers.”

Thompson from Kickstarter United pushes back: “We have nothing in our contract about ‘you can’t bend down and pick up a piece of trash because that’s someone else’s job.’ The company is free to give bonuses and individual raises as much as they like. This is all just up to the people who are bargaining the contract from the union side.”

Organizing carries potentially serious personal risks. During negotiations for a second three-year contract in 2025, Kickstarter United went on strike for 42 days. A few months later, the company announced layoffs.

“They let go strong union leaders, including a person who had bargained our last contract,” Thompson says. The union appealed, and the issue is now going to arbitration.

If you form a union, don’t expect much support from the National Labor Relations Board, the agency that certifies US labor unions and protects workers’ right to organize, in terms of prosecuting complaints of unfair labor practices, Thompson warns. “We’re in a political moment in this country with a pretty weakened NLRB. You have to be ready to organize and withhold worker power without any guarantee of safety.”

Organizers are up against an enormous union avoidance industry. Organizers can expect fierce pushback as soon as the business discovers that organizing is underway.

“There’s a multi-billion-dollar industry in union avoidance,” says Alan McAvinney, a Google software engineer and organizing chair, Alphabet Workers Union-CWA, a 1,400-member minority union of Alphabet employees. (Google is a subsidiary of Alphabet.)

US employers spend roughly $1.7 billion a year on union avoidance consultants and law firms, according to a May 2026 report by the Economic Policy Institute and LaborLab.

Expect hardball tactics. Management may play hardball during the time between when organizers announce their intention to unionize and the actual vote. For example, management can threaten to fire foreign-born workers in the US on H-1B visas if they support the union. Those workers would then have just 60 days to find a new sponsoring employer or lose their H-1B status, according to a recent Tech Workers Coalition blog post.

And at venture capital-backed startups, investment agreements sometimes require management to attest there is no union activity — meaning a public organizing drive can trigger funding withdrawal. Or, if a unionized company is acquired, the new management can dissolve the union overnight by reclassifying unionized workers as new hires.

With these sobering facts in mind, here is how organizers who have done it describe the process of creating a union.

Step 1: Start a conversation with your co-workers

At the University of California, a two-tier system had evolved where some tech workers were unionized and some weren’t, Belasco says. Management created new titles that fell outside the union even though they had similar job descriptions and responsibilities to those in the union. Those nonunion employees received lower pay and benefits than their unionized peers, which created resentment and instability.

Belasco and other organizers wanted to eliminate that division by bringing everyone under the same contract. But when they began their unionization drive, “the biggest barrier we faced wasn’t management opposition — it was that people felt this was just the best-case scenario realistically available: ‘We have this job at the university, we have concerns about automation and layoffs, but what can we really do about it?'” he says.

The antidote to that fatalism, organizers say, is simple: “Just start talking to your immediate co-workers. Are they experiencing the same challenges you are experiencing?” says McAvinney. “There’s no need to start talking about a union at this point.”

Just get a consensus and start building a group of like-minded individuals, Thompson advises. “Always start with one-on-one conversations, and that’s what you should do the whole time. That’s the key to organizing,” he says.

Tech workers often think they’re a special case, says Thompson, and therefore that unionization isn’t a good fit. “You’re not special. You are a company of workers, you are organizing, and there is a playbook for that. Trust the process, because it tends to work pretty well,” he says.

Step 2: Who’s on board, and who’s not? Map your workplace, but keep it quiet

Once there’s a consensus, continue to grow your network. Keep a list of everyone you’ve spoken with and note their disposition: “Is this person union-friendly or anti-union? Would they be a strong organizer?” Thompson says.

Maintaining secrecy early on is essential, because anti-union tactics will start immediately, and that can stop union organizing before it can gain momentum.

“Generally, employers do not want to share power with their workforce,” McAvinney says. Employers will deploy every means at their disposal to stop organizing efforts and peel away potential yes votes.

“If you look at historical examples, having 70% approval before the employer finds out about you results in a high percentage of wins when you actually cast the vote. Historically, that’s an effective buffer,” he says.

There’s a real threat of firing and layoffs. The traditional tech worker belief that job mobility makes collective action unnecessary is now being tested by a tighter job market, McAvinney says, noting that workers who many believe were fired for speaking out back in 2019 were a galvanizing factor in his union’s formation.

“You generally don’t want to be in a situation where the employer feels comfortable firing everyone. Part of that is thinking from a cynical standpoint about what the consequences would be to the employer if they did fire everyone,” he says.

One-on-one conversations that include personally asking co-workers to keep conversations confidential are key to keeping things quiet, Belasco says. When 2,100 UC tech workers voted to unionize in May, 96% voted in favor. To stay out of earshot of managers, avoid employee surveillance tools, and sidestep conference calls that could be recorded, organizers met with workers in their homes.

“That tactic is probably what made the difference between winning the election and getting the majority we got,” he says.

Step 3: Find the right union affiliation or go it alone

“Running a campaign against major employers requires the resources and expertise of the larger labor movement, even if workers publicly present as independent,” says Kate Bronfenbrenner, director of labor education research and senior lecturer emeritus at Cornell University’s School of Industrial and Labor Relations.

Options include the Communications Workers of America (CWA), Service Employees International Union (SEIU), and the Office and Professional Employees International Union (OPEIU), among others. Another resource, the Tech Workers Coalition (TWC), provides training on organizing tactics, AI-in-workplace issues, and contract negotiation, and can match workers to the right unions for their needs.

The Alphabet Workers Union decided early on to affiliate with CWA. “They gave us a bunch of support early on in our campaign with no strings attached,” McAvinney says.

Kickstarter is organized through OPEIU, Thompson says. “They’ll usually have resources and staff that can help you through the next steps: collecting signatures in support of a union, bringing that to management, holding a vote — the more formalized things that interact with US labor law. They’ll also help with organizing along the way,” he says.

For workers at institutions where a union already exists, there may be a faster path. Organizers at UCLA did what’s called a “unit modification,” aligning with UPTE. By organizing under UPTE, the workers didn’t have to negotiate a new contract from scratch — they joined an already-negotiated contract covering existing UPTE tech members, which put them in “a much stronger position” than starting fresh, Belasco says.

Step 4: Choose your union model: majority vs. pre-majority or minority

Assess what’s practical for your organizing effort. In a majority union, more than 50% of all workers in a defined bargaining unit must vote to join the union through an NLRB-supervised election in the private sector, or a Public Employment Relations Board (PERB)-supervised election for public sector workers.

The NLRB must certify the union, which then operates under its legal protections. This means, for example, that the employer must bargain, negotiated contracts are enforceable, violations must go to the NLRB or arbitration, and workers can’t be dismissed without just cause.

A pre-majority or minority union is a minority labor organization operating without NLRB protections or collective bargaining agreements. “Pre-majority means that workers are able to demonstrate majority support — through signed cards, petitions, a walkout, or everyone wearing solidarity T-shirts — without going through a formal election,” Bronfenbrenner says.

The Alphabet Workers Union-CWA (AWU-CWA) formed as a pre-majority union because achieving majority status across a globally distributed workforce of over 100,000 was not a realistic near-term goal. “An underground model where you try to reach 70% support across a workforce of over 100,000 people isn’t realistic,” McAvinney says.

A pre-majority union can still make a difference, he says. For example, the Alphabet Workers Union-CWA convinced management to offer voluntary exit packages — buyouts — prior to announcing layoffs.

For smaller organizations, a majority union may be the more practical option — it’s more attainable, McAvinney says. “I don’t think [the pre-majority union model] is the correct thing to do in all situations. I certainly would not recommend it to a 200-person shop.”

Kickstarter, which had fewer than 100 employees, was able to form a majority union, with 55% voting to organize.

Ultimately, says McAvinney, “there’s no inflection point where you go from being able to win nothing to winning everything, even with a contract and a supermajority. But the more people you have who are willing and able to fight for what they want, the more you’ll be able to get.”

Step 5: Who should — and should not — be in your union?

Belasco’s situation at UCLA illustrates a broader strategic choice that every organizing campaign must make. He had been in a union position in educational technology when he was told his role would be reclassified as a non-union position.

“I was given a choice: apply to the new non-union position to continue doing the work I’d trained for, or stay in my union position doing service desk work I wasn’t used to,” he says. “Essentially, it was a choice between job security and career progression.”

Belasco joined a “wall-to-wall” union, which represents a broad range of university professional and technical employees across the UC system rather than a single job category, such as engineers or tech professionals.

Kickstarter United is another example of a wall-to-wall union. “It’s not just the engineers who are unionized, but also customer support, designers — everyone,” Thompson says.

Wall-to-wall unions are more powerful, but they’re also more difficult to achieve. Under US labor law, “professionals have to vote separately on whether they want to be combined with other workers,” says Bronfenbrenner. “You can never have a wall-to-wall unit without giving professionals the chance to decide whether they want to be separate.”

The law’s “professional employees” category includes roles like software engineers and developers but not necessarily others. For example, customer support specialists and QA analysts would fall into the “non-professional workers” category.

“For decades, the pattern was either to organize everybody except the engineers, or manage to organize the engineers and fail to bring in everybody else — neither of which builds real worker power,” says Simone Robutti, an organizer with Tech Workers Coalition Global, an international branch of TWC based in Berlin.

Step 6: You won the vote. Get ready for what comes next

Winning a union vote means having a seat at the table, says Thompson. “Once the workers have come together and agreed they want that seat, you bring that to management, and they have a chance to voluntarily recognize a union,” he says.

But in most cases employers contest the results, which must be certified by the NLRB or PERB. That process, in which the employer uses various tactics to challenge the legitimacy of the outcome, can take weeks or months.

Unfortunately, the legal framework that is supposed to protect workers during this process has been significantly weakened in the last few years. In a potentially more ominous development, SpaceX, Amazon, Trader Joe’s, Starbucks, and the University of Southern California have in separate legal actions challenged the constitutionality of the NLRB, arguing that the agency’s structure violates the separation of powers. The Fifth Circuit Court of Appeals upheld injunctions against the NLRB in SpaceX’s case in August 2025 — a serious challenge to the agency’s authority.

In the meantime, some companies may disregard negotiated contracts, which can lead to lengthy legal appeals or extended arbitration.

“The NLRB can still force an election, but it can’t force a contract, and companies are saying they simply won’t comply,” Bronfenbrenner says. This is where the expertise and resources of affiliation with a major union can help, she adds.

As a result, contract negotiations can take far longer than workers might expect. At Kickstarter, for example, two years and four months elapsed from the time of the union vote to the first contract, and that was at a 59-person company with a relatively cooperative employer. At larger companies with more aggressive legal teams, the timeline will be longer.

Forming a union is hard work, Robutti says. “It’s not a service you pay for and they protect you. It doesn’t happen spontaneously, and it doesn’t happen magically. It’s the choice to take responsibility for improving your workplace.”

See Part 1: A brewing battle: More IT workers want unions. The industry doesn’t.

The model of the forward deployed engineer is sweeping through enterprise IT like a gold rush, and I’m concerned that many companies don’t understand what they’re signing up for.

Let’s start with the headline numbers. AWS announced a $1 billion investment in a new Forward Deployed Engineering organization. Google Cloud committed $750 million to expand similar programs. Microsoft has been running Azure-focused embedded engineering teams for years, including partnerships with Accenture to scale forward deployed engineering practices. All three are pitching the same story: We’ll send engineers to work directly with your teams, help you deploy AI, and accelerate your digital transformation. You get top-tier technical talent for free, and we get to partner with you on your journey.

It sounds reasonable on the surface. It sounds collaborative, even generous. But I’ve been in this industry long enough to know that when a multi-billion-dollar company offers you something for free, they’re sure to get much more than they give.

What you actually get

The forward deployed engineer model isn’t new. The consulting industry has been doing some version of it for decades. What makes this different is the scale and the direct financial incentive behind it.

These engineers work for the cloud provider. They’re not your employees. They’re not independent consultants. They’re technically excellent professionals who are being paid to solve your immediate problems while simultaneously building relationships and architectures that favor their employer’s ecosystem. Think about it from their perspective. Those forward engineers are evaluated on whether customers succeed with their employer’s platform. They’re rewarded when enterprises adopt more services from that platform. Their career advancement depends on making AWS, Google Cloud, or Microsoft Azure the obvious choice for all of your technical decisions.

This isn’t a criticism of the individual engineers. Many of them are genuinely talented and genuinely want to help. But they’re operating within a system that rewards specific outcomes, and those outcomes align with the vendor’s financial interests, not necessarily yours.

The problem no one talks about

Here’s what I see happening at enterprises right now. A company decides they need help deploying AI. A cloud provider offers to embed engineers at no additional cost. Those engineers work alongside internal teams, make architectural recommendations, and help build out systems. Six months later, the company has a production AI system running on a single cloud platform, built by people with deep expertise in that specific platform.

The problem? Nobody evaluated whether that platform was actually the best choice for the business. Nobody looked at alternatives. Nobody asked whether a multicloud architecture or best-of-breed approach might deliver better results at lower cost.

The engineers embedded in these programs are not going to recommend that you split your workloads across providers. They’re not going to suggest you use open source tools where they make sense. They’re not going to point you toward a competitor when their employer’s solution will work well enough. That’s not how these programs are designed to function. What you’re getting is optimized architecture for a single cloud brand, not optimized architecture for your business.

The financial reality will hit

The bills are going to come due, and they’re going to be painful. I’ve watched this pattern play out before. When enterprises lock into a single cloud provider through these embedded engineering programs, they often discover two or three years later that they’re paying premiums that their more independent-thinking competitors avoided.

The reasons are straightforward. When you’re architecting systems around a single platform, you naturally fall into usage patterns that favor that platform’s pricing structures. You use their managed databases instead of portable alternatives. You adopt their AI services instead of evaluating third-party options. You build workflows that only work within their ecosystem. And when it comes time to renegotiate or benchmark against alternatives, you find that migrating would cost more than accepting whatever pricing they offer.

I’ve spent the past decade helping companies untangle from these situations. I’ve seen organizations with cloud bills 15 to 20 times higher than they should be, unable to migrate because their entire AI infrastructure is built on proprietary services that only work on one platform. The forward deployed engineer programs are accelerating this problem. They’re making it easier to get into these situations and harder to get out.

Think before you commit

Before you accept one of these programs, consider these three recommendations.

First, require independent architecture oversight from day one. Hire or engage architects who work for your company, not for your cloud provider. They should evaluate every recommendation made by embedded engineers against business requirements and compare options across providers. This isn’t about being suspicious of the engineers. It’s about ensuring that decisions are made with your interests in mind.

Second, demand a clear exit strategy before you begin. Ask the cloud provider to document which proprietary services you’re using, what migration paths exist, and what the cost would be to move to an alternative platform. If they can’t provide that information, or if the migration costs seem impossibly high, that’s a sign that you’re building technical debt that will be very expensive to service later.

Third, benchmark your costs continuously. Set up internal processes to compare your cloud spending against industry benchmarks and against what your competitors might be paying for similar workloads. Don’t wait until your contract renewal to discover that you’re paying premium prices. Monitor expenses from the beginning, and be willing to challenge your cloud provider if you’re not getting value that justifies the cost.

The bottom line

The forward deployed engineers are solving real problems. Enterprises genuinely struggle with AI deployment, and having experienced engineers available to help is valuable. I’m not suggesting these programs are fundamentally bad. However, they’re being marketed as neutral partnerships when they’re actually strategic sales programs designed to lock enterprises into specific platforms. The helpful engineers showing up at your office are building dependencies that will be very difficult to break. The “free” technical assistance is being funded by margins on services you’ll be buying for years.

Go in with your eyes open. Use these programs but add your own independent oversight. Build architectures that you could leave if you needed to. And don’t let the immediate satisfaction of having problems solved today blind you to the financial consequences that will arrive tomorrow.

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.

It is tempting to date cloud computing from the launch of Amazon S3 in 2006 and the rise of infrastructure as a service (IaaS) that followed. That was certainly the moment the market changed in a visible, irreversible way. But the truth is that cloud began earlier, in the 1990s, when software as a service (SaaS), application hosting, managed services providers, and various forms of remote subscription computing started to reshape how enterprises thought about owning and operating technology. Even then, the core value proposition was familiar: Let someone else run the infrastructure, abstract the complexity, deliver capability as a service, and allow the business to consume only what it needs.

What AWS changed was the scale, accessibility, and precision of the execution. Amazon turned infrastructure into a programmable utility. It made compute and storage available in ways that were elastic, self-service, API-driven, and globally reachable. That was the breakthrough. Enterprises had outsourced pieces of technology before, but now they could rent raw infrastructure with unprecedented speed and flexibility. The launch of Amazon S3 was especially important because it provided a durable, scalable storage foundation that became one of the building blocks for modern digital business.

AWS changed everything

Technology markets are rarely transformed by the first company to think of an idea. They are transformed by the first company to make that idea operationally real, economically viable, and broadly consumable. AWS did exactly that. It built a model for infrastructure as a service that allowed enterprises, startups, and eventually governments to rethink the entire life cycle of IT delivery.

Looking back from 2026, it is difficult to remember how radical this concept once seemed. At the time, many enterprise leaders considered public cloud too risky, too immature, too uncontrolled, or simply too foreign for conventional IT governance. There were concerns about security, compliance, vendor dependency, performance, data residency, and reliability. Many of those concerns were valid. Early cloud adoption often ran ahead of cloud maturity, and many organizations discovered that moving quickly did not always mean moving wisely.

Still, the economics of agility overwhelmed the inertia of the old model. Provisioning that once took months could be done in minutes. Capital expenditure gave way, at least in part, to operating expenditure. Experimental workloads became easier to justify. Digital businesses could scale without building data centers first. AWS led that transition, and the rest of the industry followed, including competitors that helped mature the market.

Cloud’s strengths and liabilities

If the first decade of cloud was about acceleration, the second decade was about correction. Enterprises learned that cloud was not automatically cheaper, not automatically simpler, and not automatically better. It was better when used with discipline. It was more cost-effective when architected intelligently. It was more resilient when governance, operations, and security were designed into the system rather than added later.

This is when the industry grew up. We learned about cloud financial management because too many organizations assumed elasticity would control cost, only to discover that unused resources, poor workload placement, and fragmented accountability could drive spending far beyond expectations. We learned that public cloud could provide extraordinary innovation and reach, but also that not every workload belongs there. Latency, sovereignty, compliance constraints, legacy integration challenges, and predictable high-volume workloads all forced a more nuanced view.

We also learned about concentration risk. As enterprises standardized on a small number of hyperscalers, questions emerged around resilience, lock-in, and strategic dependency. The answer was never simplistic multicloud posturing for its own sake. It was architectural realism. Use the public cloud where it creates a clear advantage. Keep options open where business risk requires it. Understand portability, but do not romanticize it. In other words, cloud became less ideological and more practical.

Cloud is now an assumption

Perhaps the most important shift of all is that we no longer debate whether cloud is real or whether enterprises should use it. That argument is over. Cloud is baked into the cake. It is part of enterprise operating reality. The modern enterprise assumes on-demand infrastructure, platform services, automation pipelines, managed databases, identity fabrics, observability stacks, and globally distributed application delivery. Even when workloads remain on-premises or at the edge, they are often built, governed, or operated with cloud-native thinking.

This is maturity. Cloud is not a project or a trend. It is not even a strategy by itself. It is an enabling model that now underpins enterprise strategy. Businesses no longer ask whether to adopt cloud in the abstract. They ask how much cloud, which cloud services, under what governance model, at what cost profile, and in support of which business outcomes.

That may sound less exciting than the early days of disruption, but it is actually the mark of success. The most powerful technologies eventually disappear into standard practice. Electricity, networking, virtualization, and mobile platforms all went through this process. Cloud has done the same.

How cloud supports the AI race

As enterprises move aggressively into AI, cloud has entered another pivotal phase. AI is not replacing cloud. It is intensifying the importance of cloud while also changing how value is measured. Training, tuning, deploying, and governing AI systems require immense computational scale, specialized infrastructure, distributed data access, and operational consistency. Public cloud providers are well positioned to offer those capabilities, particularly with GPUs, AI platforms, managed model services, and data integration tools.

But this is not a repeat of the early cloud era. Enterprises are more sober now. They know the importance of cost, latency, and data gravity. They know that governance and accountability matter more in AI than perhaps anywhere else in modern IT. The role of cloud in the AI race is therefore foundational, but not absolute. Some AI workloads will run in public cloud. Some will be distributed across edge computing environments. Some will remain in private environments for reasons of sovereignty, economics, or control. The key is not to force a universal answer. The key is to create an architecture that aligns AI ambitions with operational reality.

Cloud should play the role it has gradually earned: not as a religion, but as a strategic utility. For AI, the cloud is where many enterprises will source scale, experimentation speed, global reach, and managed innovation. The winning organizations understand where cloud creates leverage and where other operating models make more sense.

Changing how enterprises think

The real story of the past 20 years is not just that AWS launched S3 and helped popularize infrastructure as a service. It is that cloud changed enterprise behavior. It normalized service consumption over asset ownership. It moved architecture toward abstraction, automation, and modularity. It forced IT organizations to broker capability rather than build everything from scratch. It redefined speed as a core competitive requirement.

And now, as AI becomes the next forcing function, cloud stands less as a novelty and more as the platform on which the next era will be built. That is a remarkable outcome for something that, in many ways, started with the old idea that computing could be delivered remotely on a subscription basis. We have been heading here for longer than many people realize. In the past two decades, led in large measure by AWS and the broader hyperscale movement it accelerated, cloud has evolved from a gamble to an indispensable foundation.

Hard to believe? Yes. But also inevitable in retrospect.

France’s OVHcloud is moving beyond cloud infrastructure into frontier AI model development, a shift that could test whether Europe can produce another serious alternative to US and Chinese AI systems.

The company, one of Europe’s leading homegrown cloud providers, plans to train a family of models from scratch and aims to open-source them once they meet its performance targets, CEO Octave Klaba told Reuters.

The move would put OVHcloud in closer comparison with Mistral AI, the Paris-based model developer that has become Europe’s most visible challenger to US AI labs.

Klaba said the economics of building advanced AI models have changed, with improvements in chips, training methods, and synthetic data reducing the cost of a project that may once have required about $1.15 billion (€1 billion) to now cost less than $230 million (€200 million).

Reuters reported that OVHcloud said one of its models has completed pre-training on Jupiter, the Germany-based EuroHPC supercomputer described as Europe’s fastest and its first exascale system, though the company has not yet disclosed detailed performance benchmarks.

This comes as European governments and enterprises are increasingly having to assess AI infrastructure through the lens of data governance and continuity of access, rather than performance alone.

Those concerns were sharpened this month after Anthropic said a US government export-control directive required it to suspend access to its Fable 5 and Mythos 5 models by foreign nationals inside and outside the US.

Training is only the opening cost

OVHcloud’s lower cost estimate does not capture the full cost of becoming a frontier AI model provider, said Neil Shah, vice president for research and partner at Counterpoint Research.

The $230 million (€200 million) figure likely refers mainly to the initial training run, Shah said. Once trained, however, models require continued investment because they can become depreciating assets if they are not improved with fresh data.

OVHcloud would also need to spend on fine-tuning, post-training, sovereign infrastructure, storage, security, distribution, and enterprise support. It would also need enough scale to make model serving economically viable against established AI providers such as Google and Anthropic.

“Model is seen as a depreciating asset if it is not consistently trained and kept fresh with the data,” Shah said.

That makes OVHcloud’s plan a test not only of technical capability, but also of policy support and economic viability. If the company falls short, enterprises may be reluctant to shift workloads away from more established models.

The lower training cost could still give OVHcloud a credible starting point, said Charlie Dai, principal analyst at Forrester.

The budget range can be enough to produce a credible frontier model as efficiency gains reduce the cost of entry, Dai said. But enterprise competitiveness will depend on sustained capabilities beyond training, including inference efficiency, data pipelines, evaluation frameworks, and ecosystem reach.

Buyers need proof

OVHcloud’s plan remains an expression of intent rather than demonstrated capability, said Sanchit Vir Gogia, chief analyst at Greyhound Research, pointing to the absence of published benchmarks and other details.

“$200 million now buys a serious training run,” Gogia said. “It does not buy a serious enterprise AI franchise.”

Gogia said questions around sovereignty also extend to the infrastructure used to train the model, noting that pre-training was run on Jupiter rather than on infrastructure owned or controlled by OVHcloud.

The system is a publicly owned European supercomputer in Germany that runs on American silicon, Gogia said, adding that this shows how partial European AI sovereignty remains.

CIOs will need evidence that the models can be supported in production, governed effectively, audited when needed, and exited without major disruption.

Gogia said a European-owned model could reduce some dependence on US and Chinese providers, but would not remove jurisdictional risk. “Sovereignty does not abolish the off switch,” he said. “It changes whose hand rests upon it.”

OVHcloud’s move into model development could also alter the lock-in risks enterprises need to assess, Gogia said. Customers may be able to move cloud infrastructure later, but find it harder to shift AI workloads once applications and processes are built around a provider’s models and governance tools.

Z.ai has released GLM-5.2, an MIT-licensed open-source AI model designed for long-running software engineering tasks, as the Chinese company seeks to challenge proprietary coding models on cost and performance.

The company said GLM-5.2 ranked just behind Anthropic’s Claude Opus 4.8 on FrontierSWE, a long-horizon coding benchmark, trailing it by 1%. Z.ai said the model also edged out OpenAI’s GPT-5.5 by 1%.

Z.ai said GLM-5.2 supports a one-million-token context window with up to 131,072 output tokens, positioning it for agentic coding workflows that require reasoning across large codebases.

The company is also making an efficiency argument. It said GLM-5.2 uses a technique called IndexShare, which reduces per-token compute by 2.9 times at a one-million-token context length. It also said changes to the model’s multi-token prediction layer increased the acceptance length for speculative decoding by up to 20%.

The changes are aimed at a practical problem for developers: long-context coding agents can be expensive to run when they are asked to work across large repositories.

Enterprise appeal

GLM-5.2’s clearest appeal is that it pairs stronger coding capabilities with the cost advantages of an open-source model. But capability alone will not be enough to make it a credible alternative.

“Western enterprises will want independent benchmark validation, successful deployments at global enterprises, strong security and governance controls, and long-term support commitments,” said Pareekh Jain, CEO of Pareekh Consulting.

Jain said the fastest route to enterprise credibility would be hosting by a major cloud provider like AWS. That would allow customers to use the model under standard enterprise terms, with service-level commitments and compliance certifications.

Tulika Sheel, senior VP at Kadence International, said GLM-5.2 would also need to prove it can operate as a stable enterprise product.

“Demonstrated success in real-world deployments and transparent governance will be just as important as benchmark scores,” Sheel said.

The performance and cost claims will also need to hold up against established models.

“Enterprise leaders generally consider two major factors when evaluating new models,” said Lian Jye Su, chief analyst at Omdia. “First, they look at overall performance against competitors, where GLM-5.2 performs well in long-horizon agentic coding and software engineering. Second, they look at the cost of adoption. As an open-source model, GLM-5.2 has clear cost advantages.”

Su said the model could appeal to engineering teams under pressure to control AI costs. It may also attract open-source advocates and companies with significant operations in the Asia-Pacific.

But the claims still need wider validation, particularly around hallucination control and coherence during extended tasks. These are critical issues for enterprises considering AI coding agents, which may need to work across large codebases and multi-step software engineering workflows.

Jain said the one-million-token context window could be useful for large codebase analysis. It could also help with legacy modernization projects and complex engineering documentation.

He said long-context capability may also help with audit logs or legal contracts, where splitting material into smaller chunks can create errors across document boundaries. But for everyday coding tasks, effective retrieval systems may matter more than very large context windows, making some of the benefits more limited in practice.

Governance risks

The governance question depends largely on where the model runs.

Sheel said enterprises should evaluate GLM-5.2 as they would any strategic technology partner, rather than as a standalone model. That means looking at where data is stored and whether the model can be used in environments that customers control.

That deployment choice is central to the risk calculation, according to Jain. Because GLM-5.2 is available under an MIT license, companies can download the weights and run them on their own infrastructure, reducing the need to send sensitive data to Z.ai.

“The risk flips completely if you use Z.ai’s hosted API instead,” Jain said.

He said Chinese national security rules could require domestic companies to cooperate with government requests, making hosted use difficult for regulated industries or workloads involving sensitive data.

Su said the issue is not limited to Chinese vendors. Recent restrictions affecting access to some Anthropic models have also highlighted the risk that enterprises may have limited control over the availability of AI services from foreign providers.

“Selecting solutions from American and Chinese AI vendors does expose non-US Western enterprises to additional risk of having zero control over the availability and uptime of these models,” Su said.

The article originally appeared on InfoWorld.

Anthropic’s apparent inability to identify which of its users are foreign nationals has led to some collateral damage from a US export ban on its most powerful AI models — but there is a way around it, at least for some.

On Friday, the US government ordered Anthropic to suspend access to Fable and Mythos, the new AI models it had introduced just a few days earlier, to all foreign nationals, citing national security reasons.

[ See also: Anthropic Fable dispute suggests ‘export’ no longer means what it used to ]

While the drafters of the US order may have had sovereignty in mind, they ended up making it an identity management problem.

“The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance,” Anthropic said in a blog post commenting on the order, implying that it was unable to distinguish between foreign nationals and US citizens in its user base.

That’s likely the case today, but for its consumer customers, an update to its privacy policy, introduced last week and taking effect on July 8, gives it a new option: asking them for government ID.

The section of the policy on collection of personal data contains a new provision under the heading “Personal data you provide to us directly,” saying:

• Verification Data: In certain circumstances, we may ask you to verify your age or identity. If you choose to do so, data we will collect includes, depending on the method: an image of your government-issued identity document and the information appearing on it (such as your ID number and date of birth); your image in photo or video form, facial geometry templates (which may be considered ‘biometric data’ in some jurisdictions); and the result of the verification (for example, whether your age meets the applicable threshold).

If the government ban on foreign access to Fable and Mythos continues, that would give Anthropic the option of opening access to users willing to submit a scan of their identity document, provided that it contained proof of their US citizenship. That would be the case for US passports — and also for citizens’ driving licenses issued by some US states along the country’s Northern border, which issue so-called enhanced driving licenses indicating the holders’ nationality.

Enterprise users most likely to benefit from the power of the new AI models, though, will have to hope Anthropic finds some other way out of the current impasse.

The article originally appeared on CIO.

Nvidia’s new RTX Spark is one of the most interesting personal computing announcements in years. That’s because it’s not just another PC platform, but tries to redefine the role of the personal computer in the age of AI. Announced at Computex 2026, RTX Spark is Nvidia’s new platform for slim Windows laptops and compact desktops, designed to combine an Arm-based CPU, Blackwell-based RTX graphics, and a large, unified memory architecture into a single AI-first computing system.

We have all grown accustomed to a cloud-centric AI model over the past few years. We open an application, send a request over the network, and a hosted service in a distant data center provides the intelligence. ChatGPT, Grok, Gemini, and similar systems have trained the market to think of AI as something that lives elsewhere. RTX Spark proposes a different model. It asks a simple yet disruptive question: What if the model, the agent, the data, and the application could all live on your own machine? Nvidia is not just selling a faster PC. It is selling a new architectural premise.

Features, functions, and prices

On paper, RTX Spark is designed to be a highly capable local AI system. Nvidia has described the platform as combining AI acceleration and RTX graphics on a single chip for thin laptops and small desktops. Public specifications for the platform indicate configurations with up to 6,144 Blackwell GPU cores, up to a 20-core CPU, up to 1 petaflop of FP4 AI performance, and up to 128GB of unified memory. These are not ordinary PC numbers. They are clearly intended to support serious local AI workloads.

The unified memory approach is especially important. In traditional PC architecture, the CPU and GPU often use separate memory pools, which can become a bottleneck when running large models. By contrast, RTX Spark’s design is intended to make it easier for the system to host and run AI models locally. This enables Nvidia to position the machine as capable of hosting persistent AI agents, supporting local inference, and even allowing users to customize or fine-tune certain classes of language models.

Nvidia is also careful not to frame the system as only an AI box. In a smart move, the company is marketing RTX Spark for gaming, creative applications, AI development, and agentic workflows. This has been designed not as a one-trick pony, but as a capable computer first and an AI workstation second. Otherwise, it remains a niche developer experiment.

Pricing remains uncertain because Nvidia hasn’t published a universal price for every RTX Spark laptop or desktop. The platform will appear in products from different manufacturers, which means prices will vary. The best indicator comes from the related DGX Spark desktop, listed at about $4,699, though early estimates placed it between $2,999 and $3,999.

That probably gives us the right way to think about pricing for this broader category. These are unlikely to be inexpensive mainstream PCs, at least not at launch. They are more likely to arrive as premium systems aimed at developers, technical professionals, creators, and early adopters willing to pay for high-end AI capabilities on the device. Over time, that may broaden. For now, however, this looks like a new high-value, high-cost category rather than a commodity PC refresh.

What is its real purpose?

The most important thing about RTX Spark is not the chip. It is the purpose behind the chip. This machine is ultimately built to run AI agents locally, and that is a bigger deal than it may seem at first glance. An AI agent is more than a chatbot. It persists state, accesses tools, works across applications, remembers context, automates tasks, and increasingly acts as a software-based worker. Nvidia is explicitly positioning Spark systems to run personal AI agents directly on the local machine, potentially around the clock. That creates a very different computing model from what most of us use today.

There is another important layer to this story. These systems are also being positioned as platforms on which users can build and run smaller, more limited, locally tuned versions of large language model systems. Put plainly, you may be able to create your own model-based assistant that runs directly on the RTX Spark. It will not be as broadly capable as a frontier model operated by OpenAI or another hyperscaler. It is likely to be less generally capable, narrower in its expertise, and more constrained by local hardware limits. But it will be yours, it will be local, and it will respond without relying on a remote API call to a hosted AI service hundreds or thousands of miles away.

Such a shift is conceptually significant. For years, the AI industry has conditioned us to believe that serious intelligence must be centralized. RTX Spark suggests a future in which at least some intelligence becomes personal, portable, and self-contained.

Welcome to the revolution

The breakthrough here is not that local models will instantly outperform remote models. They will not. But the architecture of AI use may begin to diversify. Today, the default assumption is centralization. We assume the model, the knowledge base, and the application stack will all live in the cloud, and the user is simply a client. With systems like RTX Spark, that assumption starts to weaken. The model can run on the local machine. The agent can run on the local machine. Sensitive data can remain on the local machine. The application logic can be executed on the local machine. This changes latency, privacy, resiliency, and cost models. It also changes who controls the AI.

That does not mean the cloud goes away. Far from it. Enterprise use cases that benefit from centralized models and data will continue to exist. Businesses want the same knowledge base, business rules, database consistency, and governance model available to everyone. Centralization remains powerful because it reduces fragmentation and keeps systems aligned. Yes, a single-tenant, RTX Spark-based AI environment can be useful for certain projects, but it can also create islands of intelligence that do not easily share knowledge across teams and systems.

Possible use cases

I see the strongest potential use cases in disconnected or semi-disconnected environments. Think about physicians doing diagnostics support in privacy-sensitive contexts, field engineers collecting and interpreting data in remote areas, military and public sector users operating at the edge, or professionals who need highly private, self-contained AI assistance without relying on constant connectivity. In those scenarios, the value proposition is very strong. Having the model, data, application, and agent all on one portable system is not a limitation. It is the point.

The bigger question is whether mainstream enterprise AI will migrate in that direction. I remain skeptical that most organizations want hundreds or thousands of individually tuned, locally hosted models to replace centralized AI services. I predict that this category will complement the cloud rather than displace it. The more likely future is hybrid: centralized AI where shared knowledge and governance matter, and local AI where privacy, portability, latency, or disconnected operations matter more.

Enterprises are increasingly investing copious amounts of cash in AI without a lot to show for it. This could be, in part, because the wrong people are leading the change.

As I’ve argued before⁠, AI isn’t likely to eliminate developers so much as change what we need from them. For example, we keep asking whether junior developers are needed in a world where large language models can write code faster and cheaper. What this overlooks is the reality that these younger developers and their relative inexperience may be exactly what we need to rewrite the rules of software development.

This thought hit me while reading James Governor’s riff on something Ben Griffiths⁠ wrote about our industry’s habit of confusing age with authority. Griffiths remembered sitting through a conference talk in which a speaker tried to shame a young audience for not recognizing some of the older men who had shaped computing. The irony, Ben noted, was that many of those “old men” had done their world-changing work when they were younger than the people being lectured. Bill Joy wrote vi when he was 22, John Carmack created Doom at 23, Linus Torvalds launched Linux at 22, etc. Many of our industry’s titans made their biggest contributions before they had decades of experience.

The point isn’t that young people are smarter. They’re not. The point isn’t that the key to AI success is to ignore more experienced developers. That’s dumb. Rather, it’s a suggestion that Griffiths’ larger point is right: At the beginning of big shifts, experience can be a mixed blessing. It can help you see risk, but it can also make you overconfident in old ways. The most successful enterprises will find ways to balance youthful innovation with experienced guardrails.

The factory doesn’t redesign itself

Zara Zhang recently pointed to Paul David’s classic 1990 paper, “The Dynamo and the Computer,”⁠ as a way to understand why so many companies have “adopted” AI without much to show for it. David’s argument, simplified, is that electricity didn’t immediately transform factories. For a long time, factories simply swapped out the central steam engine for an electric motor while keeping the same layout, the same workflows, and the same assumptions.

Electricity was new, but we largely stifled its potential by force-fitting it into old factory systems.

The big productivity gains came later, when factories stopped treating electricity as a cleaner steam engine and started redesigning work around smaller motors distributed throughout the factory. Once each machine could have its own motor, the factory no longer had to organize itself around a single driveshaft. Work could instead be reorganized around the flow of production.

That’s a decent description of where many enterprises are with AI. Enterprises today are buying copilot licenses by the thousands, wiring agents into existing applications, etc., and then wondering why the results are so uneven, as I’ve written⁠. This is the equivalent of swapping the steam engine for an electric one and declaring that the AI modernization work is done. It’s not. Not even close.

The real payoff won’t come from asking AI to write the same tickets a bit faster. It will instead come from changing how teams define work and how (and what) developers build. The “factory” has to change.

So here’s the uncomfortable question: Who is most likely to build the new factory?

Experience cuts both ways

There’s an obvious danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence and limited context. Enterprises need software that works, yes, but “works” also means it complies, scales, respects security boundaries, and more.

This is where experienced developers matter. A lot.

As I pointed out recently, the agent era makes engineering judgment more important than ever. After all, AI makes it easier to generate code, but easier code generation can become easier technical debt generation. Hence, the limiting factor becomes less of “Can we create something?” and more of “Can we create the right thing, in the right place, with the right constraints?” Taste is required, in other words.

Senior engineers are often better at seeing those constraints because their experience gives them “taste.” They know why the weird validation rule exists, and they remember the customer who depended on the undocumented behavior. They understand why a simple schema change can turn into a multi-week migration.

But experience also has a shadow side, because it can make the current process feel inevitable. A senior engineer may see an AI assistant as a faster autocomplete because that’s the easiest way to fit AI into their existing mental model. A junior developer, less invested in the old workflow, may ask the more interesting questions: Why are we doing this ticket at all? Why isn’t the spec executable? Why can’t the agent generate the test harness first?

It’s not that the more experienced developers don’t know these questions. Rather, they may simply not have the energy to rage against the machine, as it were.

The value of inexperience

The worst way to use junior developers in the AI era is to treat them as cheaper versions of senior developers. That was always a bad idea, but AI makes it worse. If the job is “take this ticket, generate some code, and send it to a senior person for review,” the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior doesn’t learn much, the senior gets buried in review, and the enterprise ends up with more code, which, as I’ve said, is hardly a good thing.

Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues. That might mean giving these newer developers interesting questions to answer, such as:

• How would we redesign onboarding if every internal API had an AI-readable contract and examples that actually worked?
• How would we change code review if the agent produced a change summary, test evidence, dependency risk, and rollback plan with every pull request?
• How would we build features if product requirements were written as executable acceptance tests rather than vague prose?
• How would we reduce toil if agents could safely perform routine migrations, dependency updates, or incident triage within clearly defined boundaries?

These are not toy problems. They’re not “junior work.” They’re exactly the sort of process redesign that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

So what should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. We seem to be moving quickly away from the idea that “lots of tokens” equals “great engineer,” but the fact that we even flirted with it is damning. I love how Santiago Valdarrama eviscerates this vanity metric: “Measuring AI productivity in number of lines written is a stupid mistake. One day, everyone will have always been against this.” Instead we should be asking questions like, “What part of our software delivery process no longer makes sense?” AI’s biggest gains will come when we change how we specify, test, review, and ship software.

Second, mix up your AI workflow teams. No, not committees or PowerPoint-producing centers of excellence. I’m talking about combining two or three newer developers who are already fluent in AI-native tools with two or three senior engineers who understand production, security, architecture, and organizational constraints. Then give them a real workflow to redesign, such as dependency upgrades or test creation.

Third, make the senior engineer’s job less about saying no and more about defining the guardrails within which others can say yes. I’ve argued that golden paths are key to using AI effectively. Good senior engineers should define the paved roads: approved patterns, test requirements, observability standards, etc. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Going back to the factory electricity metaphor, we’ll fail with AI modernization if we simply add AI without removing outdated processes.

Bring everyone to the table

The future of software development won’t belong to the young. It won’t belong to the old, either. It will belong to teams that combine the talents of both.

Newer developers often bring impatience. They’re less likely to accept the existing workflow as sacred. They’re more likely to try weird tools, compose them in unexpected ways, and wonder why enterprise software development feels like a ritualized exercise in waiting for permission.

Experienced developers bring judgment. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is often boring, and boring is good.

Enterprises need both. They need the developer who asks why the factory is still organized around the old drive shaft, and they need the developer who knows which machines will kill someone if moved casually. In sum, every development team needs people who know why the old system exists… as well as those who don’t.

A US federal judge has ruled that the Trump administration’s $100,000 fee on new H-1B visa petitions was unlawful, giving technology companies temporary relief from a policy that threatened to raise the cost of hiring foreign skilled workers.

The decision removes, at least for now, a major cost burden for employers that use the H-1B program to fill roles in domains including software development, cloud computing, data science, and AI.

US District Judge Leo Sorokin in Boston found that the fee functioned as a tax that the administration did not have authority to impose without congressional approval. The ruling came in a lawsuit brought by 20 Democratic state attorneys general challenging the fee.

Standard employer costs for H-1B petitions typically range from about $2,000 to $5,000, making the proposed $100,000 payment a sharp increase for companies seeking foreign talent.

The ruling is unlikely to end uncertainty for employers, with the Trump administration expected to appeal. But it could allow companies that had paused international hiring plans to resume normal recruitment for the upcoming H-1B cycle, said Pareekh Jain, CEO of Pareekh Consulting. Still, he said, employers should remain cautious because the legal and policy concerns are likely to continue.

“This provides breathing room for CIOs, even though it’s temporary,” said Neil Shah, vice president for research and partner at Counterpoint Research. “They should make the necessary contingency plans, whether that means doing more with less by leveraging AI or relying more on local talent.”

How companies may rethink hiring

If higher H-1B costs return in another form, CIOs will have to be more selective about sponsorship, weighing the added cost against the strategic value of the role and the long-term potential of the employee, Shah said.

“Ultimately, the decision comes down to business unit P&L: whether the unit can absorb the cost of acquiring the talent for that role,” Shah added.

That uncertainty could also lead CIOs to compete for talent from other companies, potentially driving up salaries for skilled workers. Some CIOs may conclude that paying a one-time $100,000 fee, amortized over the employee’s tenure, is still more cost-effective than engaging in a bidding war for scarce local talent.

Danish Faruqui, CEO of Fab Economics, said that CIOs may reserve H-1B sponsorship for a narrower set of mission-critical roles if costs increase.

“If there is such a financial burden, CIOs will justify sponsoring very specific roles,” Faruqui said. “These would be principal enterprise architects, AI, ML, and deep-tech researchers, senior product managers, and regulatory and compliance experts.”

More routine or project-based roles are likely to be treated differently, Faruqui said.

“Junior to mid-level software engineers, entry-level business analysts, and entry-level data scientists would shift from H-1B to domestic hiring,” Faruqui said. “Cloud migration, DevOps, ERP, and CRM implementation could be done through contractors or consulting firms, while QA, product testing, tier-one help desk support, and legacy maintenance are roles that CIOs could prioritize for automation.”

Who would be most affected?

Startups, smaller companies, and enterprise IT departments would have faced the greatest pressure from the fee and stand to benefit most from the ruling, Jain said.

Large technology companies would have been better placed to absorb the $100,000 cost, he said. Meanwhile, companies with mature offshore delivery models may be less likely to increase their reliance on H-1B hiring.

The article originally appeared on CIO.

Enterprises are moving aggressively into generative AI. On the surface, that seems like the right call. The technology is powerful, accessible, and increasingly embedded in how businesses build applications, automate processes, and support decision-making. A development team can connect an application to a large language model in days. A product team can add AI features in weeks. Business leaders see quick wins, faster innovation, and a path to modernizing nearly every part of the company.

These are the upsides everyone is talking about. The part we don’t discuss enough is the economic trap forming underneath all this convenience.

Most enterprises think of tokens as a technical billing detail. They are not. Tokens are the unit of economic dependency in generative AI. Every prompt, response, summarization, retrieval step, workflow action, and agent decision is measured and monetized through tokens. Tokens are not just part of the plumbing. They are the tollbooth between your enterprise and a provider’s intelligence platform. The more AI becomes central to your operations, the more power that tollbooth holds over your future costs.

Tokens are not just a pricing unit

A token is usually described as a chunk of text processed by a model. That is accurate enough for developers, but it misses the bigger issue for CIOs, architects, and corporate boards. In the enterprise, tokens are the mechanism by which AI capabilities are rented. They are the meter attached to the intelligence itself.

That distinction matters because token usage grows faster than most companies anticipate. A simple user prompt rarely remains simple in production systems. It can trigger retrieval from internal knowledge stores, multiple model calls, tool use, post-processing, policy checks, and agent loops. What appears to be a single transaction to the user may involve several layers of token consumption behind the scenes. As a result, enterprises often underestimate the true operating cost of AI-enabled systems, especially as those systems mature and spread across departments.

Today, those costs still feel manageable. In many cases, they feel surprisingly low. That is exactly why the trap is so dangerous.

The market is in a subsidy phase

Current token pricing is giving enterprises a false sense of comfort. Many remote LLM providers are aggressively competing for market share. They want developers building on their APIs. They want enterprise applications tightly coupled to their platforms. They want AI agents, copilots, workflows, and customer experiences to depend on their models. To make that happen, pricing remains highly attractive relative to the value delivered.

That does not mean the economics of generative AI are stable. It means the market is still being shaped by investor capital, strategic pricing, and growth expectations. Providers are racing to establish position, and enterprises are benefiting from that race. But no market stays in that phase forever. At some point, investors will expect durable profitability. At some point, weaker providers will disappear, consolidate, or retreat. At some point, the survivors will have more leverage and much less reason to price primarily for adoption.

That’s when the token trap closes.

Enterprises that build deep dependence on remote models during the subsidy phase may find that what seemed inexpensive at pilot scale becomes punishing at enterprise scale. The application that costs $1,000 per month today may cost 10 or 20 times that amount a few years from now, not only because usage has increased, but also because the market has repriced the dependency.

Easy to adopt, expensive to exit

Cloud computing followed a similar path, with many enterprises mistaking short-term convenience for long-term economics. In the early years, the case was compelling and largely accurate. Move faster, reduce friction, avoid capital spending, and scale with ease. Those benefits were real. Many organizations made architectural decisions that prioritized speed over leverage. They became dependent on managed services, provider-specific tools, and operating models that were easy to adopt but expensive to unwind.

Years later, many enterprises discovered that their cloud bills were much higher than expected and their exit options much narrower than advertised. That was not because the cloud failed. Architectural dependency eventually became financial dependency.

Generative AI is repeating that pattern, only faster. The integration barrier is lower, the pressure to adopt is higher, and the pace of enterprise experimentation is far greater. As a result, companies are wiring remote LLMs into applications, workflows, and agentic systems with very little thought about how these costs will behave in the next five to 10 years.

Agentic AI makes things worse

The more enterprises move from simple prompt-response systems to agentic architectures, the more dangerous the token trap becomes. Agents are not single-call systems. They plan, deliberate, retrieve information, invoke tools, evaluate results, retry steps, and often coordinate with other agents. Each of those actions consumes tokens. Costs no longer rise in a neat linear fashion. They compound.

This matters because agentic AI is increasingly being presented as the future of enterprise automation. It’s true in many cases. But if an enterprise builds agentic systems primarily on remotely hosted intelligence, it is also building future business processes on top of someone else’s pricing model. That is a major strategic risk. The more successful those systems become, the harder they are to replace. The harder they are to replace, the more pricing power shifts to the provider.

This is how businesses end up operationally dependent on a cost structure they do not control.

The appeal of AI sovereignty

The answer is not to reject public models or pretend that external providers play no role. They clearly do. There will always be cases where renting frontier AI capabilities makes sense. But enterprises need to stop assuming that renting is the default for every workload.

AI sovereignty is the alternative that deserves much more attention. That means building, tuning, deploying, and governing models inside the enterprise for use cases where long-term control matters more than access to the absolute frontier. Enterprises need to recognize that most business applications do not need a world-class general-purpose model. They need a model that is good enough for a specific purpose, aligned to the enterprise’s data, governed by the enterprise’s rules, and operated at a predictable cost.

It’s a very different way of thinking.

A self-hosted or enterprise-controlled model may not match the rich feature set of the largest public offerings. It may lack the same breadth, polish, or marketing appeal. But for many internal business tasks, those factors do not matter.

Here’s the most critical question to guide your architectural direction: Can a sovereign AI model solve the problem reliably, securely, and economically over time? If the answer is yes, owning that capability may be far more strategic than forever renting something with more power than you need. In effect, the enterprise becomes its own provider for the workloads that matter most.

Prepare for changing markets

Too many companies still treat generative AI architecture as a tactical IT issue. It is not. These decisions directly affect cost structure, operating flexibility, data control, and long-term competitiveness. If AI becomes a force multiplier across the business, the economics of AI become strategic to the business itself.

The companies that get this right will not necessarily be the fastest adopters. They will understand the difference between experimentation and dependency. They will use external models when it makes sense, but they will also invest in sovereign capabilities where ownership matters. They will think like architects, not consumers.

Here’s the takeaway: Cheap tokens come with strings. They are a gateway to a dependency model that will typically look very different once providers stop pricing for growth and start pricing for leverage. Enterprises cannot keep mistaking today’s bargain for tomorrow’s reality. Boards and executive teams need to act now to get ahead of this issue. The key question is not whether generative AI creates value. It clearly does. The real question is whether the enterprise can still afford and control the value it creates once the market matures.

Technology companies announced 38,242 job cuts in the US in May 2026, the highest monthly total for the sector since August 2024, according to research by employment placement company Challenger, Gray & Christmas. So far this year the company has observed 123,653 US technology job cuts, a rise of 66 percent from the same period in 2025.

These figures represent the third successive month that there has been an increase in job layoffs across all sectors, the company said.

“The labor market is being reshaped by technology in real time. AI is now the leading reason companies give for cutting jobs and the primary industry citing it is technology,” said Andy Challenger, chief revenue office at Challenger, Gray and Christmas.”

AI was blamed for 38,579 of the 97,006 job cuts announced across all industries tracked by the company. It accounted for 40% of the cuts observed in May, up from 7% in January.

This year has already seen some major layoffs in technology. In March, HPE slashed 2,500 jobs from its wage bill, while Oracle announced plans to shed an unspecified number of developers. And the cuts keep on coming, just last month, Meta shed 8,000 employees.