This is what happens when you don't control your infrastructure

This is what happens when you don't control your infrastructure

Contributors

Gregory Kurtzer, CEO of CIQ and Founder of Rocky Linux

Watch what happens when you build on infrastructure you do not control. Last week, the argument made itself.

At 5:21 PM on Friday, June 12, the US Department of Commerce issued an export control directive to Anthropic. The order required the company to immediately suspend all access to its two most capable AI models, Fable 5 and Mythos 5, for any foreign national, whether inside or outside the United States. Foreign nationals on Anthropic's own team were included. There was no advance notice. To comply, Anthropic disabled the models for every customer.

That is how fast it happened: no deprecation timeline, no transition period, no warning of any kind before organizations running production AI workloads on those models were looking at a blank response.

I have seen this before.

When Red Hat announced the end of CentOS Linux in December 2020, they gave the community a sunset date and called it a transition. It was a policy decision made by a single vendor that severed thousands of organizations from infrastructure they had built their operations on and trusted. The engineers, contributors, and organizations who came together to build Rocky Linux understood one thing clearly: you cannot build critical infrastructure based on someone else's permission. December 2020 proved it.

Last Friday proved it again, with higher stakes.

The difference matters, and it matters specifically. In 2020, the actor was a corporation making a business decision. There were lawyers, notice periods, and at least the posture of a transition plan. Last Friday, the actor was the federal government exercising export control authority, with no advance notice, no negotiation, and no appeals window before the lights went out.

The directive was tied to perceived risks associated with higher end models. Mythos 5 is Anthropic's most capable model, restricted from public release because of its ability to identify and exploit software vulnerabilities at a level that surpasses human cybersecurity experts. Fable 5 is Mythos with safety guardrails layered on top, designed specifically to prevent that capability from being misused, and the version Anthropic released publicly. The government's concern was not a flaw in the models themselves. A third party found a method to bypass Fable 5's guardrails, effectively unlocking Mythos-level capability from a publicly available model and using it to find vulnerabilities in code and infrastructure. Anthropic disputed the scope: the technique amounts to asking the model to read a codebase and identify flaws, the finding was narrow and non-universal, and comparable capabilities already exist in other publicly available models, including OpenAI's GPT-5.5. Whether the government's response was proportionate is a debate that will continue. What it revealed is more important: when your AI runs on someone else's infrastructure, the threshold that satisfies a regulator becomes the threshold that ends your access. The specific trigger is almost beside the point.

Anthropic complied and publicly disagreed with the directive. They stated that the standard applied here, if applied consistently across the industry, would essentially halt all new model deployments from every frontier provider. They may be right about that. As of today, the models are still off, and organizations that had built workflows on them have no alternative.

Canadian Prime Minister Mark Carney described this plainly as the danger of over-reliance on a limited number of providers. Speaking at the G7 on Sunday, he compared the systemic risk to conditions that preceded the 2008 financial crisis. He said: "It is never a good idea to have one option." Less than 48 hours had passed since the directive landed.

He is not wrong.

The organizations most exposed by Friday's directive did not make careless infrastructure decisions. Many made what looked like reasonable choices: a major commercial provider, enterprise terms, strong uptime history. What no reasonable risk model could have anticipated before last Friday was an export control directive that cut off access for an entire user class with no prior notice, a failure mode that does not appear in business continuity frameworks, was not in any vendor risk assessment template before this week, and is now a documented, real-world event that every infrastructure team needs to account for.

Research computing is built on guaranteed availability. Compute allocations are planned quarters in advance, scientific workflows run against grant deadlines and publication windows, and AI tooling is now embedded in the critical path at institutions worldwide. Cloud AI access is structurally incompatible with that requirement. Last Friday's directive made it plain, and it affected the global research community regardless of where institutions are located: a US government action against a US company removed access for research organizations in Europe, Asia, and Australia that have no relationship with US export control law and no recourse when it changes. If your AI inference depends on an external provider, that access can be revoked overnight by a decision you are not part of. On Friday it was a government. Next it could be a price change, a deprecation, or a shift in terms you didn't agree to.

Own your inference stack

The infrastructure answer has several layers, and each one matters.

Start with the model itself. Open-weight models like Llama, Mistral, Qwen, and DeepSeek, along with the expanding field of domain-specific variants, can be downloaded, deployed, and run on infrastructure you control. No export control directive can reach model weights that live on your hardware. That is the foundational point. But ownership of the model does not stop at inference.

Organizations running Fuzzball can orchestrate AI workloads across heterogeneous environments: bare-metal HPC clusters, on-premises GPU nodes, and hybrid cloud infrastructure, all under unified orchestration. Inference runs where you need it, workloads scale across your infrastructure, and sensitive data never routes through a third-party API. When access controls change upstream, your infrastructure does not notice.

The deeper layer is what you do with the model once you have it. Fine-tuning, post-training, and reinforcement learning on domain-specific data produce models that reflect your organization's knowledge, security requirements, and operational constraints. You are not just running someone else's model locally. You are building and owning the model itself. That work requires a hardened, stable foundation: an Enterprise Linux operating system with GPU-accelerated workload support, certified AI framework compatibility, and the enterprise support that production AI infrastructure demands. RLC Pro AI and RLC Pro AI Hardened are built for exactly this. The Hardened variant addresses the security posture required by regulated industries, defense environments, and government organizations, where the risk calculus after last Friday is even sharper.

Together this is what a sovereign AI infrastructure stack looks like in practice: open-weight models you own, fine-tuning and post-training capabilities on your own compute, inference orchestration across your environment, and a hardened Enterprise Linux foundation built for the workload. The model-provider chokepoint is gone. No upstream access decision can disable weights that run on your own hardware.

This is what derisking looks like in practice. When the next directive lands, organizations running inference on infrastructure they own do not have an incident. They have a normal workday. Getting there does not have to be complicated. CIQ makes this stack simple to deploy, built to scale across your environment, secure at the foundation, and fast enough that your AI development does not slow down to get there.

Own your infrastructure. That is what this comes down to, and it is what CIQ was built to help you do.

The pattern holds

The Rocky Linux community built something specifically because of the lesson from December 2020, not as a reaction to Red Hat, but as the affirmative answer to a structural problem: critical infrastructure cannot depend on a single point of external control. That principle does not stop at the operating system. It runs straight through to where your AI models are trained, fine-tuned, and served.

The lesson from December 2020 is the same lesson from last Friday. It is harder to dismiss now.


Gregory Kurtzer is the founder of Rocky Linux and CEO of CIQ.

Ready to learn more about what CIQ can do for you?

Get in touch

Related posts

AI workflow orchestration: why separate platforms fail

AI workflow orchestration: why separate platforms fail

CIQ Fuzzball and Nvidia NIM for Voice-to-Text Processing

CIQ Fuzzball and Nvidia NIM for Voice-to-Text Processing

CIQ's Partnership with NVIDIA: Transforming Enterprise GPU Infrastructure

CIQ's Partnership with NVIDIA: Transforming Enterprise GPU Infrastructure

What to know about community support versus vendor support

What to know about community support versus vendor support

Built for scale. Chosen by the world’s best.

2.75M+

Rocky Linux instances

Being used world wide

90%

Of fortune 100 companies

Use CIQ supported technologies

250k

Avg. monthly downloads

Rocky Linux