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.

The European Union has now published a set of measures aimed at boosting Europe’s tech industry to help reduce reliance on US and Chinese suppliers for AI, cloud, and semiconductors. The proposals include rules to restrict the use of US hyperscalers for certain public sector procurement purposes, but stop short of banning them outright.

“Technological sovereignty does not mean protectionism. Europe remains grounded in openness, partnership, and fair competition,” Henna Virkkunen, executive vice president for Tech Sovereignty, Security and Democracy, said in a statement Wednesday. “At the same time, Europe wants to be in the position to make its own choices, avoiding dependence on single dominant suppliers, especially from non-like-minded countries.”

The European Technological Sovereignty Package — released after several delays — includes two legislative proposals: the Cloud and AI Development Act and Chips Act (CAIDA) 2.0 and the Open Source Strategy and Strategic Roadmap for Digitalization and AI in Energy.

CAIDA aims to triple data center capacity in the next five to seven years by easing restrictions for deployments across the EU. It also includes rules that, if enacted, would require EU public bodies to meet certain sovereignty criteria for cloud service procurement related to certain sensitive workloads.

Amid ongoing trans-Atlantic tensions and a long-time deep reliance on US tech providers, European organizations have become increasingly wary of a “kill switch” that would cut off access to digital services. There are also concerns that US hyperscalers could be compelled to share data with US government under the CLOUD Act and Foreign Intelligence Services Act (FISA), even when data centers are located in Europe.

The CAIDA proposals include four levels of criteria for suppliers; the most basic includes data center infrastructure located and operated in the region – something  many US cloud suppliers already provide – with stricter rules around supplier ownership, full control over the software stack, and more stringent cybersecurity certification.

The majority of existing EU public sector workloads (70%) fall under the first level, with 20% at level 2, and 9% at level 3. Only a small proportion (1%) of the most sensitive workloads would require level 4.

Other proposals include the Chips Act 2.0, a follow-up to the 2023 legislation that sought to improve semiconductor production capabilities; the updated version now aims to boost research and spur demand for domestically produced processors. 

The legislative proposals must be negotiated by the European Parliament and Council of the European Union before adoption.

Tech companies seem to be falling over each other these days in firing people to either replace them with AI or to pay to build AI infrastructure. Wouldn’t it be nice if they at least waited until AI actually worked for business?

On the one hand, top tech businesses such as Amazon, Block, Cisco, Cloudflare, and Meta have all announced that they’re slashing payrolls — either because AI can do the same work as people or they need the cash to build out their AI infrastructure. Isn’t that great? All together, of the 37,638 tech job cuts so far this year, 47.9% — almost half —  can be tracked back to AI. 

On the other hand, despite all the AI hype and hysteria, no one has yet proven that AI is, generally speaking, really all that helpful for businesses. Oh, I know, I know. You did great things with OpenClaw vibe programming. Microsoft’s CEO, Satya Nadella, claims 20% to 30% of the company’s code was written by AI. And Nvidia assures us that 88% of its surveyed customers report AI has increased their revenues. 

But really, what else would they say? “Dear Board, we just blew half a billion bucks on Nvidia GPUs, and we’re losing money hand over fist?” I don’t think so.

The truth is, as an IDC study reports, a mind-boggling 88% of proof-of-concept AI projects never reach production. Lest we forget, MIT’s The GenAI Divide: State of AI in Business 2025 study found that 95% of AI projects fail to deliver measurable P&L impact. 

Now, I have to acknowledge that AI is finally becoming truly helpful in business. As a guy who knows a thing or two about programming, Linus Torvalds, creator of Linux and Git, said at Open Source Summit North America, “I’m personally 100% convinced that AI is changing programming.” He estimates that “AI will increase your productivity by a factor of 10.” 

But is that reason enough to slash make workforce cuts of between 10% to 40%? (Short answer: No. Longer answer: Noooo!)

It’s not just the mass firings. Workers who are either awaiting the axe, or have escaped it for the moment, are miserable. As one Meta employee told The San Francisco Standard, “I tend to cry in the shower,” and, “A lot of my feelings about my job are about the general chaos and not just the layoffs. ” 

So, explain this to me: When everyone knows AI-driven layoffs are coming, exactly how well do you expect them to work? You really think they can give their best? 

Making matters worse, it’s an open secret that IBM, Google, and Meta are having their employees train their AI replacements. As a popular meme puts it, workers are now “building your own coffin.” Is it any wonder that a lot of people — 29% of all employees and 44% among Gen Z workers —  are deliberately sabotaging work when the boss insists they train their AI replacements?

It also sure doesn’t help office morale when the CEO keeps saying AI will replace half of all employees. A particularly egregious example of this was when Standard Chartered CEO Bill Winters proclaimed his bank would slash thousands of jobs and replace “lower-value human capital” with AI.  

He’s since backed off the claim, but come on — we all know he meant it. Just like all the other CEOs who’ve said similar things, between FOMO and the knowledge that AI job news is sure to make the stock price jump, they’re eager to cut headcounts and boast about how successful AI will make them. 

What happens a few quarters down the road? Their attitude today seems to be let  tomorrow take care of tomorrow. I hate to tell them, but that really doesn’t work in the long run. (Not, mind you, that a future much farther ahead than the next quarter seems to matter much anymore to business executives.)

It should. As a recent Deloitte study stated: “Most respondents reported achieving satisfactory ROI on a typical AI use case within two to four years. This is significantly longer than the typical payback period of 7seven to 12 months expected for technology investments. Only 6% reported payback in under a year, and even among the most successful projects, just 13% saw returns within 12 months.” 

AI, in short, is not the miracle cure for what ails businesses that its fans claim. 

Will that stop businesses? I doubt it. While I appreciate that California Gov., Gavin Newsom is trying to bandage the AI job bleedout by mandating studies on subsidizing companies to keep employees rather than replace them with AI, I doubt that will do much to staunch the wound. 

At the Open Source Summit North America, Linux Foundation CEO Jim Zemlin was optimistic about AI and jobs. He pointed out that, thanks to AI becoming  “pretty damn good coders,” the number of open-source projects on GitHub has led to a “surge of new code and projects.” 

Zemlin also believes that while few developers will write code, “engineers will still design, review, secure, and integrate that code.” (He’s referring to what’s becoming  known as forward-deployed engineers.) This, in turn, will supposedly lead to tech job growth. 

I’d feel a lot better about that prediction if I believed the C-suite suits at most companies were capable of truly forward-looking thinking rather than focusing entirely on hiking the stock price by making the next quarter look good through staffing cuts. 

In the long run, sure, AI will make us more productive. But, we’re not there yet. For now, companies need to keep employees happy, not shove AI down their throats — and work out carefully and thoughtfully how AI will really work for business. 

If ever there were a lawsuit in which a jury and judge should have ruled against both the accuser and the defendants, Elon Musk’s suit against OpenAI and Microsoft was it. 

The high-profile legal battle pitted the world’s richest man against a company worth more than $3 trillion, another that might soon launch a $1 trillion IPO, and tech execs claiming to have only the good of the world in mind, not mere filthy lucre, while they develop a technology some fear could eventually destroy humankind.

The lawsuit was eventually thrown out, but only on technical grounds. Meanwhile, unregulated AI marches on, with Musk, OpenAI and Microsoft all getting richer.

The only winner in this suit was hypocrisy. Here’s why.

Back to the beginning

To understand how this unfolded, we need to go back to OpenAI’s beginnings. The company was founded by current CEO Sam Altman, Musk and others in 2015 — back when AI was a niche technology, used primarily for image and speech recognition, robotics, and experiments in self-driving cars.

The founders funded OpenAI out of their own pockets as a nonprofit company aimed at developing AI for the good of the world. Then, as the technology evolved, Altman, Musk and others grew worried it might become so powerful that, without serious guardrails, it could pose a danger to humans. They feared what might happen if AI reached the level of a super-powerful artificial general intelligence (AGI) system, superior to humans on a variety of tasks, with general problem-solving skills rather than narrowly targeted ones – and the ability to think for itself rather than heeding humans. 

In an earlier version of Musk’s suit against OpenAI and Microsoft, Musk put their fears this way: “A.G.I. poses a grave threat to humanity — perhaps the greatest existential threat we have today.”

Early on, OpenAI wasn’t on many people’s radar. When Microsoft invested $1 billion in the company in 2019, few outside the tech industry took notice. Between 2021 and 2023 Microsoft invested $2 billion more, still without drawing a lot of attention.

Then in November 2022, OpenAI released ChatGPT, launching the generative AI (genAI) revolution — and all the disruption that has followed since. Eventually, as it became clear how important and valuable genAI technology would become, Microsoft’s investment ballooned to $13 billion.

Nonprofit no more

OpenAI insiders were convinced several years before ChatGPT’s release that the company could become tremendously profitable. With potentially trillions of dollars at stake, in 2017 they started looking for a way to turn the nonprofit operation into a for-profit company.

It was at that point, OpenAI says, that Musk pushed to gain majority equity in the company if it went public, take control of the board, and become CEO. When the other founders balked, Musk withheld funding.

Last year, OpenAI released copies of emails he sent to it during the height of their in-fighting. In one, in February 2018, he lobbied for the creation of a for-profit arm, pointing out that, “a for-profit pivot might create a more sustainable revenue stream over time and would, with the current team, likely bring in a lot of investment.” 

Musk then suggested that OpenAI “attach to Tesla as its cash cow.” When the other founders dismissed the idea, Musk threw a fit and quit the company. OpenAI went ahead and launched a for-profit arm, becoming a hybrid of a for-profit and nonprofit company in 2019.

Years later, in 2024, Musk filed suit, targeting OpenAI, Altman, OpenAI co-founder and president Greg Brockman, and Microsoft — accusing them of “stealing a charity” by creating the for-profit arm of OpenAI, and taking the $13 billion Microsoft investment. He claimed they had all illegally enriched themselves through the profit/nonprofit setup and sought $150 billion in damages. (OpenAI fired back last year with a counter suit.)

It took only two hours for the jury to rule against Musk, though the ruling didn’t address his actual claims. Rather, the suit was thrown out because it had been filed after the statute of limitations had run out.

Cynicism and hypocrisy win out

Everyone in this case was driven by venality. Altman portrayed himself as only wanting to develop AI to help humanity — and as evidence, pointed out he has no equity in OpenAI. What he neglected to add, though, is that he has more than a $2 billion stake in companies that have deals with OpenAI, and stands to gain billions more if those deals grow after any IPO.

Microsoft, meanwhile, has used its investments in OpenAI to become a multi-trillion-dollar company. And if, as expected, OpenAI becomes a trillion-dollar company when it files its IPO later this year, Microsoft’s 27% ownership stake in the company would make it $270 million richer. That’s not a bad payoff for turning a blind eye to the way in which OpenAI performed a bait-and-switch from nonprofit to for-profit company. 

As for Musk…, well, what can you say about someone who claims he wants to save humankind from the evils of AI, while at the same time lobbying for OpenAI to become a for-profit company and milking it like a cash cow? 

He’s shown he’s not only the world’s wealthiest man. He’s also the world’s most hypocritical.