It Is Time for IT Departments to Run Models
Frontier AI access is becoming a regulated supply chain. Enterprises need an internal model layer before model dependency becomes an operational risk.
The Anthropic Fable/Mythos incident looked, at first, like a vendor-specific crisis. A frontier model provider received a government directive, access rules changed, and customers lost access to models they expected to use. That alone was enough to make enterprise buyers uncomfortable.
But the larger signal came when similar access-control logic began appearing around OpenAI’s GPT-5.6 rollout. OpenAI’s own release language described a limited preview for trusted partners, shaped by government engagement, before broader availability. That does not mean ChatGPT is being “shut off.” It means frontier AI access is moving into the same category as chips, cloud regions, cybersecurity tooling, encryption, and other strategic technologies.
For operators, the conclusion is straightforward: AI can no longer live only inside business-unit experimentation budgets. IT departments need to step in and run models.
Macro Context: AI Is Leaving the SaaS Comfort Zone
The first phase of enterprise AI adoption looked like SaaS procurement. Buy seats. Approve a few tools. Let developers, analysts, support teams, and executives experiment. Watch usage grow and assume the platform layer will remain available.
That phase is ending. AI is not just another collaboration tool when it starts touching code review, incident response, document processing, security analysis, customer workflows, internal knowledge systems, and operational decision support. Once those workflows depend on model access, the model becomes infrastructure.
Infrastructure has different rules than software. It needs redundancy, observability, governance, security boundaries, cost controls, and disaster recovery. Most companies would never let one external SaaS vendor become the only path to identity, payments, networking, or production data access. Yet many are drifting toward exactly that posture with AI.
The deeper issue may be that AI adoption moved faster than AI operations. Teams adopted model access before they built model governance. Now the market is showing why that sequencing matters.
Deep Dive: The Risk Is Not One Vendor
The wrong lesson from the Anthropic incident is “do not use Anthropic.” The wrong lesson from OpenAI’s limited rollout is “do not use OpenAI.” Both are too narrow.
The better lesson is that frontier AI is becoming a regulated, politicized, capacity-constrained, safety-reviewed supply chain. Vendors may still be excellent. Models may still improve rapidly. Customer value may still be real. None of that removes the enterprise dependency problem.
A model can be technically superior and still be operationally fragile. A vendor can be competent and still face government directives, export-control constraints, compliance obligations, safety gating, capacity limits, pricing changes, or geopolitical pressure. A workflow can deliver productivity gains and still require an exit plan.
This is familiar territory for IT departments. Cloud teams already design around region failure. Security teams already plan for vendor compromise. Data teams already think about portability, backups, schemas, and retention. Infrastructure teams already understand that the best component is not always the safest dependency.
AI now needs the same operating discipline.
The Case for Internal FOSS and Open-Weight Models
Internal FOSS and open-weight models are not a moral position. They are a control layer.
The enterprise does not need every internal model to beat the best frontier model on every benchmark. That is the wrong comparison. A smaller internal model only needs to be good enough for the workflow, cheap enough to run repeatedly, private enough for the data boundary, and available enough to survive external disruption.
Most enterprise AI work is not frontier reasoning. It is classification, extraction, summarization, ticket enrichment, routing, document comparison, code explanation, log interpretation, policy Q&A, and first-pass analysis. These workloads are repetitive, measurable, and often sensitive. They are exactly where internal models can become economically and operationally rational.
The phrase “internal model” should not mean random GPU experiments scattered across engineering teams. It should mean a governed enterprise capability: approved models, private inference endpoints, workload routing, evaluation datasets, prompt logging, access controls, cost dashboards, and fallback paths.
That is where IT belongs.
What IT Should Own
IT departments should now own the enterprise AI control plane.
That control plane starts with a model registry. The company should know which models are approved, where they run, what license terms apply, which data classes they can touch, which teams use them, and what risks each model introduces. This is not bureaucracy for its own sake. It is the minimum inventory required to run AI as infrastructure.
The second layer is private inference. Some workloads should run inside the enterprise boundary, either on-premises, in a private cloud environment, or in a controlled virtual private deployment. Sensitive customer data, proprietary code, internal documents, regulated workflows, and security logs should not automatically flow to hosted frontier APIs by default.
The third layer is routing. Routine workloads can go to smaller internal models. Sensitive workloads can go to private inference. Hard reasoning or specialized work can go to frontier APIs. The point is not to ban external models. The point is to stop treating them as the only path.
The fourth layer is evaluation. Enterprises need internal benchmarks based on real workflows, not only public leaderboards. A model that looks weaker on a general benchmark may perform well on a company’s tickets, contracts, runbooks, pull requests, or customer-support transcripts. Internal evals convert AI procurement from taste into operations.
The Cost Layer Is Becoming Harder to Ignore
The infrastructure layer is also becoming a cost issue. Usage-based AI does not behave like ordinary seat-based SaaS. Agents call models repeatedly. Coding tools expand context. Automated workflows generate hidden token demand. A successful rollout can create a larger bill, not a smaller one.
This matters for IT because cost control is architecture. If every workflow defaults to a premium frontier API, the company has little control over unit economics. Once IT runs internal models for repeatable workloads, frontier spend becomes a deliberate allocation instead of an uncontrolled default.
This is where open models change the bargaining position. Enterprises with internal capacity can negotiate better, route more intelligently, and reserve premium inference for work that actually needs it. Enterprises without that capacity are price takers.
The same logic applies to availability. A company with internal inference can absorb vendor disruption. A company without it has to wait.
Open Models Are Not Risk-Free
The open-model argument should not become naive optimism. Internal models shift responsibility back onto the enterprise. They require security review, patching, monitoring, access control, licensing review, red-team testing, model evaluation, and operational support.
Open-weight does not always mean truly open source. Some models have usage restrictions. Some licenses are more permissive than others. Some models are easier to deploy than govern. Some may underperform on specialized tasks without tuning or retrieval.
That is why this belongs with IT, security, legal, data governance, and platform engineering. Internal AI should not be a side project. It should be a managed capability with explicit standards.
The practical position is hybrid: use frontier models where they are worth it, use internal models where control matters, and build routing between the two.
Implications for Enterprise Behavior
One emerging pattern is that enterprise AI strategy is splitting into two layers. The first layer is capability access: which frontier models can the company use today? The second layer is sovereignty: which workflows can the company continue running if access changes tomorrow?
The second layer will matter more over time. As models become more capable, governments will pay closer attention. As AI spend grows, CFOs will demand predictability. As workflows become embedded, CIOs will demand continuity. As data exposure increases, CISOs will demand boundaries.
This increasingly looks like the moment when AI leaves innovation theater and enters enterprise architecture. The teams that merely distribute AI tools will have adoption. The teams that build model operations will have resilience.
For labor, this also changes the skill map. Companies will need platform engineers who understand inference. Security teams that understand model behavior. Data teams that can build evaluation sets. Procurement teams that understand token economics and license terms. IT leaders who can talk about models the way they already talk about cloud, identity, and endpoint control.
That is not a small shift. It is the operationalization of AI.
Conclusion
The lesson from recent frontier-model access events is not that enterprises should abandon OpenAI, Anthropic, Google, Microsoft, or any other major provider. That would be an overcorrection.
The lesson is that critical AI workflows need an internal model layer.
Enterprises should keep using frontier APIs where they create clear value. But they should stop assuming external access will always be broad, stable, cheap, politically uncomplicated, and operationally available. That assumption no longer fits the evidence.
IT departments should now build model registries, private inference paths, approved open-weight deployments, internal evaluations, routing rules, cost dashboards, and fallback plans. The companies that do this will not be anti-frontier. They will be better frontier customers because they will know when premium models are worth paying for.
AI started as a productivity tool.
It is becoming infrastructure.
Infrastructure needs control, redundancy, and an exit plan.
That is why it is time for IT departments to run models.