It’s rarely a compute or budget problem. It’s that none of them was built to govern the thing AI teams actually request: a complete, accountable environment.
For years, most infrastructure teams ran on a governance system nobody designed and almost nobody named out loud: the approval workflow.
A pull request, a change ticket, a cloud access request: each required a person to review it before it took effect. That review step functioned as governance, whether or not anyone called it that. It was where ownership got checked and intent got questioned, using judgment that had never been written into a policy engine because a person supplied it instead.
Automation has spent the last decade removing that person. Infrastructure-as-code replaced tickets. GitOps replaced manual deploys. Self-service catalogs replaced request forms. Each change was a genuine improvement: provisioning got faster and more consistent. But the review step was not replaced with anything else. It was simply removed, along with the friction it created. That was tolerable as long as infrastructure stayed cheap and slow-moving enough for the resulting gaps to go unnoticed.
AI infrastructure is where that assumption stops holding.
Every layer solved a real problem. None of them solved this one.
The current infrastructure stack does an enormous amount, and does it well. Kubernetes schedules, heals, and scales containers better than anything that came before it. Terraform’s own documentation describes its job as letting teams “build, change, and version cloud and on-prem resources safely and efficiently,” and it does exactly that. Crossplane describes itself as “a control plane framework for platform engineering,” reconciling the resources it is told to manage. GitOps engines such as Argo CD continuously compare a live system against a Git-declared desired state and correct the drift. Azure Arc extends “a single control plane” across clusters running anywhere, for inventory, policy sync, and access control. Developer portals such as Backstage unify visibility into services and infrastructure tooling through a catalog.
Each tool delivers what it says and that is the point. Each one manages a specific, well-defined technical object: a cluster, a resource, a Git repository’s desired state, a catalog entry, a Terraform plan. None of them, by their own documentation, manages the thing a person or an AI agent actually asks for, a training environment, a production environment, a testing environment. That request is not for a cluster or a resource. It is for a complete, governed thing with an owner, a reason for existing, a budget, a policy set, and eventually an expiration date. No system in the stack above treats that request as a single governed object. Each one owns a slice of it.
Provisioning, orchestration, security, FinOps, and observability each govern their own layer well. None of them is accountable for the environment as a whole.
This pattern is not new. It is the same one that has repeated at every infrastructure transition: each abstraction shifted where complexity lived rather than eliminating it, and each shift
exposed the next problem nobody had built for yet.
| Era | Primary Abstraction | What It Actually Governs |
| Physical infrastructure | The server | Whether a machine exists and is reachable |
| Virtualization | The virtual machine | Whether a resource pool is allocated efficiently |
| Public cloud | The service | Whether capacity can be consumed on demand |
| Kubernetes | The workload | Whether a container is scheduled, healthy, and scaled |
| AI infrastructure | The environment | Whether infrastructure still serves the purpose it was created for |
What each infrastructure era actually governs, not the technology that defined it, but the operational question it answered.
AI removed the cushion
For most of the last decade, an ungoverned resource was a manageable problem. A forgotten virtual machine sat quietly costing a few hundred dollars until someone eventually noticed. That is no longer the shape of the risk.
A forgotten GPU training job does not idle quietly. It can burn thousands of dollars in GPU-hours within days, often with no ticket, no approver, and no one left who remembers requesting it. Flexera’s 2026 State of the Cloud Report found that wasted IaaS/PaaS cloud spend rose to 29% in 2026, reversing five straight years of decline, an increase the report attributes in part to the cost unpredictability of AI workloads. Gartner projects that the average Fortune 500 enterprise will run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025, and found that only 13% of organizations believe they have adequate governance for those agents. No human approval workflow was built to review that volume of infrastructure-touching decisions. A governance model that depends on a person in the loop stops working at the exact point it is needed most.
How long legacy platforms have left
There is no single date every organization shares, because the deadline is set by how fast AI workloads are scaling inside a given environment, not by a calendar. But the growth curves behind that scaling are public, and they are not gradual. Gartner projects the average Fortune 500 enterprise moves from fewer than 15 AI agents in 2025 to more than 150,000 by 2028, roughly a 10,000-fold increase in three years. Gartner’s separate figures on worldwide IT spending put AI’s share at about 32% in 2025, rising to 40.6% in 2026. IDC puts AI infrastructure spending at $318 billion in 2025, forecast to reach $497 billion in 2026, a 56% single-year increase.
Extrapolating from that curve, rather than reading a specific date off it: organizations already running AI at meaningful production scale, hundreds of agents, or a GPU footprint that is a material share of infrastructure spend, are likely already past the point where approval-workflow-era governance holds up. The 13%-adequate-governance figure and the 80%-already-experienced-risky-behavior figure cited earlier suggest that is already true for most of them. For organizations earlier in adoption, a reasonable estimate is 12 to 24 months before the same gap becomes unavoidable, tracking the window in which Gartner and IDC expect agent volume and AI infrastructure spend to cross those thresholds. That is an estimate, not a measured fact, but it is the same kind of extrapolation any capacity-planning exercise already relies on, and waiting for certainty before acting on it is itself the higher-risk choice.
The more useful signal for any specific organization isn’t the calendar anyway. It’s which of the following stages a platform is already in.
| Stage | Warning Sign | What’s Actually Happening |
| 1. Early friction | Tagging and cost attribution start drifting | Manual metadata falls behind as environment count grows. Finance and platform teams reconcile spreadsheets to answer basic ownership questions. |
| 2. Recurring workarounds | Self-service requests need manual exceptions | The policy engine can’t express AI-specific constraints, GPU quotas, model versioning, data residency, so teams route around it with one-off tickets. |
| 3. Visible waste | Idle environments pile up faster than they’re reclaimed | GPU and cloud spend rises without a matching rise in delivered value. No one can produce a current, trusted inventory of what’s running and why. |
| 4. Governance bypass | Approvals get rubber-stamped or skipped for agent-initiated changes | Request volume exceeds review capacity. Teams grant broad standing access just to keep pace, widening the blast radius of any single mistake. |
| 5. Total failure | The platform can’t answer what exists, who owns it, or what it costs | A cost overrun, compliance failure, or security incident forces an emergency manual audit. Trust in the platform’s data collapses organization-wide. |
A platform rarely fails all at once. It moves through stages, and each one is a warning sign the next is closer than it looks.
What changes when the environment becomes the governed object
The practical shift is narrower than it sounds. It shows up in specific mechanics, not a new layer of dashboards.
| Workload / Resource Governance | Environment Governance |
| Applies to a cluster, VM, or resource | Applies to the complete environment those resources belong to |
| Policy checked at request time (who can click submit) | Policy evaluated against the actual deployment plan, before it runs |
| Cost reconciled from a bill, after the fact | Cost attributed to owner, project, and purpose at creation |
| Idle resources persist until someone notices | Idle environments expire on a defined lifecycle policy |
| Governance = a human checkpoint in the process | Governance = a property enforced by the infrastructure itself |
| Answers: “Is it running?” | Answers: “Is it still justified?” |
The distinction is operational, not technical. Workload governance asks whether something is running. Environment governance asks whether it should still be.
At Quali, this is the model Torque is built around. Curate discovers every piece of infrastructure-as-code an organization already has, Terraform, OpenTofu, Helm, Ansible, Kubernetes manifests, CloudFormation, and classifies each resource as Codified, Managed, or Unmanaged, so nothing governed is invisible and nothing invisible is assumed governed. Policy is evaluated against the actual Terraform plan output before anything deploys, not against who was allowed to submit the request, and returns approved, denied, or requiring manual review with a stated reason. Governance constraints, cost ceilings, maximum duration, allowed regions, required tags, are embedded directly in the blueprint an environment is created from, so they travel with the environment instead of living in a separate policy document nobody checks after launch.
The same model extends to AI agents that touch infrastructure directly. An agent scoped to cost analysis can read spend data and recommend changes; it cannot provision or destroy anything. A deployment agent can provision within its quota; it cannot modify the cost policy that bounds it. Plain API or MCP connectivity solves how an agent reaches infrastructure, not what it is allowed to do once it is there. That gap is already visible in production: 80% of organizations report having encountered risky agent behavior, including unauthorized changes and unrecoverable workflows.
This isn’t only a cloud problem
The environment-governance gap is not confined to public cloud accounts. Stack Automation, co-developed by Quali and Cisco, applies the same model to physical infrastructure, provisioning compute, networking, and storage from bare metal through to a running application. Cisco’s own published FAQ for the product, independent of anything Quali says about itself, lists the specific systems it operates across: APIC, Catalyst Center, Nexus Dashboard, Cisco Intersight, Identity Services Engine, ThousandEyes, Splunk, and Cisco Secure Firewall, alongside third-party software including VMware, Red Hat OpenShift, NVIDIA NIMs, NetBox, and Veeam. That list matters less as a product feature than as evidence for the underlying claim: an environment worth governing spans far more than a set of cloud VMs, and a governance model that only reaches as far as the public cloud console is already too narrow for what organizations are building.
Six questions worth asking any infrastructure platform
None of this requires replacing Kubernetes, Terraform, or whatever GitOps pipeline already works. It requires being precise about what a platform is actually governing, and what it only appears to govern.
A short, practical way to test that:
- Does policy evaluate the actual deployment plan, or only who was allowed to submit the request?
- Is cost attributed to an owner and a purpose at the moment of creation, or reconciled from a bill afterward?
- Does an idle environment expire on a defined policy, or wait for someone to notice and act?
- When an AI agent touches this system, does it operate under the same constraints a person would, or under the broader permissions of a service account?
- Is “environment” a single object with one owner and one lifecycle, or an assembly of separate tickets across five different systems?
- If every human approver were removed tomorrow, would governance keep functioning, or would it quietly stop?
That last question matters most. For most infrastructure stacks today, the honest answer is that governance would stop. Nothing would break. The thing that had been doing the governing was a person, and the person would be gone.
The point was never that automation is dangerous
Automation without an owner is invisible until it becomes expensive. The industry spent the last decade making infrastructure fast: provisioning in minutes instead of months, deployment in seconds instead of days. AI infrastructure does not need a faster version of that. It is exposing, at a cost and a speed that is hard to ignore, that speed was never the missing part. Ownership was. The environment is what people, and increasingly AI agents, actually request. Not the cluster. Not the resource. Not the pipeline. Infrastructure platforms should start treating it that way.
Start with the six questions above, applied to whatever actually runs your AI environments today. Pick one: a training pipeline, an inference service, an agent sandbox. Trace who owns it, what it costs, and what happens if no one touches it for thirty days. If any of those answers is unclear, that is the gap this piece describes, not a hypothetical one, and it is worth fixing before the next environment gets created rather than after. Quali built Torque around closing exactly that gap, for teams who want to see the model working rather than just read about it.
See the next generation of Torque in action
Torque is evolving fast, with new AI-powered capabilities for infrastructure discovery, environment design, governed self-service, lifecycle management, and agentic operations. Get a first look at the new Torque experience, watch the latest product videos, and see how we’re making even the most complex enterprise and AI infrastructure easier to design, deploy, govern, and operate. [Explore the new Torque experience]
