The Register ran a piece this week that a lot of IT leaders will nod along to: digital sovereignty sounds great until you try ditching your suppliers. The gist: everyone in Europe and beyond is suddenly talking about controlling their own data, their own infrastructure, their own destiny. Then they open the hood, see fifteen years of accumulated dependence on two or three hyperscalers, and quietly close it again. Migration is expensive. The skills aren’t there. The integrations run deep. Sovereignty, the article suggests, is a nice speech and a brutal project plan.

The article is right about almost everything, and it still draws the wrong lesson.

The pessimism is earned, but it’s pessimism about retrofitting

Read the piece carefully and notice what every hard case has in common. The organizations struggling aren’t struggling with sovereignty. They’re struggling with reversal. They built for a decade on someone else’s platform, using someone else’s proprietary services, on someone else’s contract terms, and now they want to walk it back. Of course that’s painful. You’re not adopting an architecture at that point. You’re performing surgery on a live patient who’s been fused to the operating table.

Egress fees are the obvious villain, and yes, they’re real money. But egress is the small problem. The big problem is that most cloud-native systems weren’t designed to run anywhere else. When your app logic is welded to a hyperscaler’s managed queue, its identity service, its serverless functions, its specific flavor of managed database, the data can technically leave. The system can’t. You’d be rewriting, not migrating.

So when a CIO says “sovereignty is too hard,” what they usually mean is “unwinding my last ten years of decisions is too hard.” True. Also not an argument against sovereignty. It’s an argument against how they got here.

Lock-in is a design choice you made, whether you noticed or not

Nobody signs a contract titled “Dependence Agreement.” Lock-in accretes. A team picks the managed service because standing up the open equivalent would take three sprints. A vendor discount ties renewal to consumption commitments. A compliance officer signs off on a region, and suddenly the region is load-bearing. Each decision was locally rational. The sum is a company that can’t leave.

The fix isn’t a heroic exit project scheduled for some future fiscal year when things calm down. Things never calm down. The fix is refusing to accumulate the dependence in the first place, and that has to happen at the architecture stage, on day one, when it’s cheap.

What does that actually look like? Concretely:

Own the physical layer or contract it in a way you can walk away from. Know which building your data sits in and under whose legal jurisdiction. If the answer involves a foreign court’s subpoena power, you don’t have sovereignty, you have a hopeful arrangement.

Pick portable primitives. Containers over proprietary serverless. Open protocols over vendor SDKs. Standard databases over managed ones with quirks you’ll only discover during a migration. Boring choices, deliberately.

Stay model-agnostic on the AI side. This is the newest lock-in vector and the fastest-growing one. Teams are currently wiring their workflows to one frontier model’s API the same way teams in 2012 wired everything to one cloud’s services. Same movie, faster projector. If your prompts, your pipelines, and your evaluations only work against one vendor’s endpoint, you’ve rebuilt the exact trap The Register is describing, except this time the vendor can change the model underneath you without asking.

Fix your costs. Variable consumption pricing is itself a control mechanism. When leaving means eating an unpredictable bill, the pricing model is doing the lock-in work the technology doesn’t have to.

None of this is exotic. It’s just unfashionable, because every step trades a little short-term convenience for long-term freedom of movement, and short-term convenience has been winning that trade for fifteen years. The Register piece is the invoice arriving.

We’re biased, and here’s why

Modular builds private AI infrastructure end to end, from the physical facility up through the interface people actually use. From dirt to desktop, on US soil, at fixed pricing, running whatever models fit the client’s needs rather than whichever vendor bought us lunch. So yes, we have a horse in this race.

But the reason we built it that way is precisely the failure mode in this article. We watched organizations try to bolt sovereignty onto architectures that were never meant to grant it, and we watched the retrofit cost kill the initiative every time. The only version of sovereignty that survives contact with a budget meeting is the version that was there from the start, when portability cost nothing extra because it was simply how the system got built.

Your data, your rules. That’s the whole thesis, and it only holds if “your rules” is enforced by the architecture instead of promised by a contract. A sovereignty clause in an MSA is a rule the vendor agreed to follow. A stack you control is a rule nobody has to follow, because there’s no one else in the room.

The honest takeaway

If you’re deep in a hyperscaler today, the article’s pessimism is fair warning: don’t announce a grand exodus you can’t fund. Rank your workloads by how trapped they are. Move the portable ones. Stop the bleeding on new builds by making them portable by default. Sovereignty regained incrementally beats sovereignty announced and abandoned.

And if you’re starting something new right now, an AI initiative, a new product line, a greenfield system, you have a choice the retrofitters would kill for. You can build on ground you own. The cost of doing it from day one is small. The cost of doing it in year ten is the entire subject of that Register article.

So here’s what I’d genuinely like to know from people running infrastructure right now: if you had to move your most important workload off its current platform in twelve months, what’s the first thing that would break? Not hypothetically. Name it. That answer tells you more about your sovereignty posture than any strategy deck, and I’d like to hear it.

The post Sovereignty isn’t an exit plan. It’s a floor plan. appeared first on Modular Technology Group.

Spirit Airlines needed money. Google, according to the flight attendants’ union, wanted something more interesting than interest payments.

Fortune reported last week that the Association of Flight Attendants is accusing Google of structuring a deal around Spirit’s restructuring that would hand the tech giant access to confidential airline data for AI purposes. The union’s language was blunt. “Adding insult to injury” is how they framed it: their employer is in financial distress, their jobs are uncertain, and now the data generated by their work might get folded into someone else’s model training as a side effect of a transaction they had no seat at.

Set aside for a moment whether the union’s characterization holds up in every detail. The shape of the deal is the story. And the shape is one we’re going to see again and again.

Data as the sweetener

When a company is healthy, its data sits behind contracts, policies, and a general reluctance to give anything away. When a company is desperate, all of that becomes negotiable. Data turns into an asset on the table, right next to the gates and the aircraft leases. A lender or strategic partner who wants training data doesn’t have to buy it on the open market. They can attach it to financing that the company can’t afford to refuse.

Notice who’s missing from that negotiation. The flight attendants whose schedules, communications, performance records, and operational patterns make up a real chunk of that “confidential data” were not in the room. They didn’t sign up for it when they took the job. There was no consent moment. Their information became a bargaining chip because it happened to be sitting in systems their employer controlled and their employer needed cash.

That’s the part that should make every executive uncomfortable, and not only on behalf of the workers. Flip the seats. Your company’s data is sitting in a vendor’s cloud right now. That vendor has its own investors, its own pressures, its own potential acquirers. If your vendor hits a rough patch, or gets bought, or signs a strategic partnership with an AI lab, what stops your data from becoming their sweetener?

Read your agreements. In most cases the honest answer is: less than you think. Terms of service change. “Improving our services” clauses stretch. Acquisitions transfer data along with everything else, and the successor company’s appetite may not match the original vendor’s promises.

Consent doesn’t survive the deal

Here’s the mechanism worth naming plainly. Consent, in most data arrangements, is a snapshot. An employee consents to an HR system. A company consents to a cloud provider’s terms. Then the world moves. The provider changes hands, the terms get amended, a financing deal introduces a new party with new incentives. The original consent never contemplated any of it, but the data doesn’t get re-asked. It just flows to wherever the paperwork now permits.

The Spirit situation makes this vivid because a bankruptcy court and a union give it visibility. Most versions of this story never get a headline. The data quietly gains a new downstream use, a new processor, a new training pipeline, and nobody with standing to object ever finds out.

For firms handling client files, patient records, case materials, or workforce data, this should reframe the vendor question entirely. The question is not “do I trust this vendor today.” It’s “do I trust every future owner, creditor, and strategic partner of this vendor, under financial conditions I can’t predict.” Nobody can answer yes to that honestly.

The only clean answer is architectural

You can’t contract your way out of this. You can architect your way out of it.

If the AI workload runs inside infrastructure you control, on hardware in a known jurisdiction, with models you selected and can swap, there’s nothing for a third party to acquire access to. There’s no pool of your data sitting in someone else’s cloud waiting to become deal collateral. A vendor’s bankruptcy, acquisition, or creative new financing arrangement can’t repurpose data it never touched.

That’s the entire premise behind private AI workspaces as we build them at Modular. Client data and workforce data stay inside the client’s environment. Models run locally. Nothing feeds a third-party training pipeline, not because a policy says so, but because there’s no pipe. We own the stack from the physical facility to the interface the user touches, which means there’s no intermediate layer where someone else’s business model can intervene. Your data, your rules, from dirt to desktop.

And because the pricing is fixed, there’s no meter running that tempts anyone, us included, to find secondary value in what flows through the system. The economics are aligned with the architecture. You pay for capability, not for the privilege of becoming training data.

The flight attendants understood something instinctively that a lot of boardrooms still haven’t internalized: once your data is in someone else’s hands, your interests and theirs will eventually diverge, and when they do, the paperwork will favor whoever holds the servers.

The closing thought

I keep coming back to the phrase “adding insult to injury.” The injury was the financial distress. The insult was discovering that your working life had a resale value you never agreed to. Spirit’s flight attendants at least have a union loud enough to get this into Fortune. Most employees, and most companies whose data is riding in third-party clouds, will never get the courtesy of a headline.

The uncomfortable exercise for this week: pull up your top three data-holding vendors and try to answer, from the actual contract language, what happens to your data if they’re acquired or restructured. If you’ve done that exercise, or if you think I’m overreading the Spirit deal, tell me what you found. I’d genuinely like to compare notes.

The post When the financing comes with a data clause appeared first on Modular Technology Group.

What Happened

Three separate incidents. Three different organizations. One common thread: loss of control over data sent to cloud AI platforms.

The Pentagon vs. Anthropic. The Department of Defense designated Anthropic — maker of Claude, one of the most capable AI models on the market — as a national security risk after a dispute over who ultimately controls the model and the data flowing through it. When a defense agency can’t get comfortable with the control dynamics, that’s a signal worth paying attention to.

OpenAI’s vendor breach. A third-party analytics provider working with OpenAI exposed business customer data. Not through a sophisticated attack — through the kind of supply-chain vulnerability that’s inevitable when your data passes through multiple hands you’ve never met.

CISA’s ChatGPT incident. The acting director of CISA — the federal agency literally responsible for cybersecurity — accidentally uploaded sensitive government documents to ChatGPT’s public platform. If the people whose job is protecting data can make this mistake, what about the rest of us?

The Real Problem Isn’t the Headlines

These aren’t edge cases. They’re the natural, predictable result of centralizing sensitive work inside infrastructure you don’t control.

Every time you send a prompt to a cloud AI service, you’re trusting:

• That vendor’s security posture
• Their subcontractors’ security posture
• Their data retention policies (and whether those policies change tomorrow)
• Whatever a court might compel them to preserve or disclose
• Whatever a future acquirer might decide to do with the data

That’s a long chain of trust for organizations handling privileged, regulated, or confidential information. And every link in that chain is a potential point of failure.

There’s a Better Way

At Modular, we built Private AI Workspaces specifically to eliminate this chain of dependency.

Your prompts, embeddings, documents, and outputs never leave your environment. There’s no third-party analytics layer siphoning data to vendors you’ve never vetted. No silent retention policy buried in terms of service. No competing obligations between your privacy and a government subpoena aimed at your AI provider.

The infrastructure is yours — hosted on your own hardware, or in our FedRAMP-certified data center with full tenant isolation. Either way, the data stays exactly where you put it.

What That Looks Like in Practice

• Wildcat — Entry-level private AI workspace. Shared infrastructure, isolated data. Perfect for firms getting started with AI who want privacy from day one.
• Panther — Dedicated LLM server, isolated frontend, private document storage. For teams with real data to protect.
• Grizzly — Fully dedicated hardware with air-gapped options. On-premise if you need it. For organizations where “good enough” security isn’t.

All tiers run on model-agnostic infrastructure. You’re not locked into one AI vendor — you choose the models that work best for your use case, and you can switch whenever you want. Fixed monthly pricing means no surprise bills when your team actually starts using AI the way they should be.

The Bottom Line

Private AI isn’t a luxury tier. It’s becoming the baseline for anyone who takes their data seriously.

The organizations that will thrive aren’t the ones with the flashiest AI tools — they’re the ones who maintain control over where their data lives, who can access it, and what happens to it tomorrow.

If your organization is rethinking where its AI workloads live, we’re happy to compare notes.

Modular Technology Group builds, hosts, and maintains private AI workspaces for organizations that need enterprise-grade capability without sacrificing data sovereignty. Get in touch or schedule a consultation.

The post Three Security Incidents in Three Weeks: Why Private AI Is No Longer Optional appeared first on Modular Technology Group.

The post BREAKING: Your AI now remembers everything you say. appeared first on Modular Technology Group.