In the race to operationalize artificial intelligence at scale, enterprises are discovering that model performance alone is no longer the decisive factor. As organizations commit to multi-year investments in expensive GPU capacity and complex hybrid environments, a quieter but more consequential challenge has emerged: how to govern that infrastructure with the same discipline once reserved for financial systems and production software.

Lior Koriat has spent nearly two decades confronting versions of this problem. As CEO of Quali since 2011, he has guided the company from its early engineering roots into a global provider of Environment as a Service platforms designed to give platform and DevOps teams governed, self-service access to cloud and hybrid infrastructure.

Quali’s Torque platform delivers catalog-based environments with built-in policy enforcement, cost attribution, lifecycle management, and real-time visibility—capabilities that have taken on new urgency as AI workloads introduce autonomous agents, rapidly shifting GPU demand, and environments that too often outlive their purpose.

Before leading Quali, Koriat founded Intellitech Engineering, a systems company serving defense and civilian customers, and later mentored startups through Google Launchpad Accelerator and UC Berkeley’s Sutardja Center for Entrepreneurship & Technology. That background in complex, high-stakes systems informs his view that the next phase of enterprise AI will be defined less by the raw power of models and more by an organization’s ability to treat infrastructure as a governed resource rather than an unlimited pool.

In this interview with Tekedia’s Samuel Nwite, Koriat examines the operational realities of AI infrastructure: the growing risk of poorly allocated capacity, the limits of traditional automation when agents begin provisioning resources, the requirements of true sovereignty, and the practical steps organizations can take to improve utilization without simply buying more hardware.

The discussion offers a clear-eyed assessment of what separates companies that scale AI effectively from those that accumulate cost and complexity in equal measure.

1. You’ve said the next phase of enterprise AI will be defined as much by infrastructure discipline as by model capability. When companies are locking themselves into years of expensive compute capacity, where do you see the biggest blind spots today—organizations that simply don’t have enough infrastructure, or those sitting on large, poorly allocated pools with almost no visibility into who’s actually consuming it?

The bigger problem is increasingly allocation rather than availability. Companies are making significant investments in GPU capacity, but having the hardware does not mean you are using it efficiently. You need visibility into who requested an environment, what workload it supports, how long it is supposed to run, and whether those resources are still being used. Without that context, organizations can continue adding capacity while existing infrastructure sits idle or remains attached to workloads that have already finished. The discipline has to come before the next purchase.

2. Quali has long focused on turning infrastructure into a governed, self-service resource rather than an unlimited pool. Looking at the current AI boom, how much of the waste you’re seeing stems from treating GPU and compute capacity the way companies once treated cloud spend five years ago- easy to provision, hard to track, and even harder to shut down?

There is a strong parallel with the early cloud era. Self-service made infrastructure easier to consume, but organizations learned later that easy provisioning without lifecycle management creates waste very quickly. AI infrastructure raises the stakes because GPU resources are significantly more expensive and the supporting stack is more complex. The goal should still be self-service, but every environment needs an owner, a purpose, a policy, and a defined lifecycle from the moment it is created.

3. You argue that AI infrastructure has to become a governed enterprise resource. In practical terms, what does “governed” look like day-to-day when autonomous agents are the ones requesting environments, spinning up GPUs, and tearing things down? Who ultimately owns the policy, and how do you prevent the control plane from becoming another bottleneck?

Governance has to be embedded in the workflow rather than added as another approval step. An agent can request an environment, but the control plane should understand what it is requesting, what resources it is allowed to consume, which configuration and security policies apply, and when those resources should be retired. The organization defines those policies, and automation enforces them consistently. If every request still requires a person to inspect and approve it manually, we have simply moved the bottleneck rather than solved it.

4. Many organizations are still measuring AI success by how fast they can stand up new environments. You seem to be saying that speed without lifecycle discipline is the real risk. What metrics should boards and CIOs actually be watching right now if they want to know whether their AI infrastructure is under control or quietly bleeding money?

Deployment time matters, but it only measures the beginning of the lifecycle. I would also look at GPU utilization, how long unused environments remain active, how frequently environments drift from their approved configuration, and how much infrastructure exists without a clear owner or workload attached to it. Another useful measure is whether the organization can accurately describe what is running across its environments at any given time. If that requires days of manual investigation, there is an operational visibility problem regardless of how quickly those environments were originally deployed.

5. You’ve described environments that sit idle between training runs or remain attached long after the work is finished. When an organization discovers it has millions of dollars in underutilized GPU capacity, what’s the first operational change that typically delivers the biggest immediate improvement without buying more hardware?

Start by attaching lifecycle information to the infrastructure that already exists, rather than waiting for a broader governance rollout. Once an environment carries an owner and an expected end date, teams can immediately see which capacity is tied to active work and which was provisioned for something that already concluded. That single step tends to surface real savings faster than any new tooling, because it turns a hardware problem into a visibility problem you can actually act on.

6. Sovereign AI conversations often focus on where the model and data live. You suggest infrastructure governance is becoming equally important. How do you respond to a government or regulated enterprise that believes owning the hardware and keeping data on-prem is enough to claim sovereignty when agents can still act across systems without deterministic policy enforcement?

Physical control is only one part of sovereignty. An organization can own the servers and keep the data inside its own facilities, but it still needs control over how infrastructure is provisioned, configured, changed, and accessed. That becomes more important as agents begin taking operational actions because the agent itself is not deterministic. The policies around what it can provision and the boundaries within which it can operate therefore need to be deterministic and consistently enforced.

7. Traditional automation executes static scripts. An intelligent control plane, as you describe it, understands intent, ownership, cost, and policy. Walk me through a concrete example of how that shift changes the outcome when an AI agent requests a large GPU cluster for a short-lived experiment versus a long-running production workload.

The infrastructure may look identical at the provisioning stage, which is exactly the risk. Picture two requests for the same eight GPUs. One is a short experiment that needs that capacity for six hours and should expire automatically once the job finishes. The other is a production workload that needs those same eight GPUs indefinitely, along with dedicated networking and storage, security controls, monitoring, and a change policy that follows enterprise standards rather than a timer. A traditional script would provision both requests the same way because they look the same on paper. An intelligent control plane reads the intent behind the request and provisions each one differently from the start. The objective is to automate the right environment for the workload, not simply automate whatever infrastructure was requested.

8. Platform engineering teams spent the last decade removing friction for developers. Now they’re being asked to enforce cost controls, policy, and auditability across far more expensive and dynamic infrastructure. Are we asking these teams to do two jobs that are fundamentally in tension, or is there a way to design the control plane so speed and governance reinforce each other?

They only become competing objectives when governance depends on manual intervention. If approved architectures, security requirements, cost controls, and lifecycle policies are built into reusable workflows, developers can get infrastructure faster because they are no longer waiting for multiple teams to configure each component separately. The platform team defines the operating boundaries once and makes them repeatable. That is how governance becomes an enabler of self-service rather than an approval layer sitting in front of it.

9. Zero-touch operations have been a long-standing goal. You say we’re closer than most people realize, but governance—not automation—is the limiting factor. What specific capabilities still need to mature before a large enterprise can safely allow agents to provision, optimize, and retire AI environments with minimal human intervention?

We already know how to automate many of the individual actions. The harder problem is giving automation enough context to know whether an action should happen. That requires visibility into ownership, dependencies, policy, cost, current state, and the lifecycle of the environment. It also requires continuous validation because an environment that was compliant when it was deployed can drift over time. Zero-touch operations become practical when those controls are part of the operating model rather than dependent on someone reviewing the environment afterward.

10. Looking five years ahead, hybrid AI environments—public cloud, private cloud, on-prem, and edge—will almost certainly be the default. What’s the single hardest unsolved problem in creating one consistent operational standard across those environments, and how close is the industry to solving it?

The hardest problem is consistency. Every environment has different APIs, provisioning models, security controls, and operational tooling, while the enterprise still needs one way to define what an approved workload looks like. Replacing all of those tools with one technology is neither realistic nor necessary. The industry needs a control layer that can use the tools organizations already have while applying consistent policy and lifecycle management across them. We are making meaningful progress there, but most enterprises still operate these environments as separate domains today.

11. You’ve watched companies generate Infrastructure-as-Code and environments at a pace that was unthinkable a few years ago, only to lose track of what they created. If you could redesign one common enterprise practice around AI infrastructure provisioning from scratch, what would you change first, and why?

I would stop treating provisioning as the end of the automation process. Infrastructure as Code is very good at describing what an environment should look like when it is created, but the environment continues changing after deployment. Ownership changes, dependencies evolve, configurations drift, and workloads eventually end. I would design the process around the full lifecycle from the beginning, including deployment, continuous validation, modification, utilization, and retirement.

12. Ultimately, you believe the organizations that succeed will treat AI infrastructure as an operational capability rather than a collection of technologies. What early signals tell you that a company is on that path—and what red flags tell you it’s still treating infrastructure as an unlimited pool that expands every time a new workload appears?

A stronger signal than deployment speed is whether teams default to reusing validated infrastructure patterns instead of rebuilding the same stack for every new project, because that habit only forms once governance is built into the workflow rather than treated as a separate control. The clearer warning sign is the opposite: several teams independently solving the same provisioning problem, each with its own approach to ownership and cleanup. That kind of duplication is usually the first evidence that infrastructure is accumulating rather than being managed, long before it shows up as a cost problem.