The Question That Actually Signals Maturity
Ask any AI vendor how their infrastructure is provisioned, and the answer tells you more than almost anything else in the sales conversation. "We set it up through the portal" means someone clicked through a console once, got it working, and nobody can fully explain how to reproduce it. "It's provisioned as code" means the entire environment exists as a version-controlled definition that can be rebuilt, audited, and changed deliberately. For AI systems specifically — where the infrastructure often touches sensitive data, model endpoints, and compliance-relevant configuration — this distinction isn't a technical preference. It's a signal of whether what you're being sold is actually production-grade.
What "Ad Hoc Through a Portal" Actually Means
Provisioning infrastructure by hand — clicking through the Azure or AWS console, running one-off CLI commands, patching things during an incident — feels fast in the moment. It also doesn't scale, and the reason isn't really about speed. It's about what happens six months later when nobody remembers exactly which settings were changed, in what order, or why. Manually configured environments accumulate what the industry calls configuration drift: the gap between what the infrastructure is supposed to be and what it actually is. A cloud engineer adjusts a resource directly in the portal during an incident. A temporary fix bypasses the usual process and never gets cleaned up. An automated script updates something outside the approved pipeline. None of these are dramatic events on their own — but they compound, and by the time drift becomes visible, it's often already deep enough that fixing it is genuinely risky.
Why This Matters More for AI Systems Specifically
Every infrastructure team deals with drift. AI systems make the consequences sharper for a few reasons. First, AI infrastructure frequently touches regulated data — model endpoints, vector stores, and document pipelines that process personal or financial information. If you can't reproduce exactly what's deployed and prove it matches what was audited, you don't have a compliance story, you have a hope. Second, AI systems tend to involve more moving pieces than a typical web application — compute, search indexes, key management, container orchestration, monitoring — and each one configured by hand in a console is another undocumented dependency. Third, teams building AI products iterate fast, which means environments get touched constantly. Constant manual changes and infrastructure drift are a bad combination; the more often something changes, the more valuable it is to have that change be a reviewable, versioned diff instead of a console click nobody logged.
The Real Cost of Drift
This isn't a theoretical concern. Research from DORA's State of DevOps analysis found that teams dealing with frequent configuration drift had more than double the change failure rate of teams maintaining consistent infrastructure-as-code hygiene. That's not a minor efficiency tax — it's a direct line from "we configured this by hand" to "our deployments break more often." And the failure mode compounds on itself: drift erodes confidence in the infrastructure definition, which pushes teams toward more manual fixes, which produces more drift. Once a team stops trusting their own infrastructure code, they stop using it properly, and the problem gets worse from there.
What Infrastructure as Code Actually Buys You
The case for IaC isn't about following a trend — by 2026 it's simply the baseline expectation for any team running production infrastructure, AI or otherwise. What it delivers, concretely:
Reproducibility. The entire environment — compute, storage, networking, AI services, access policies — exists as a defined, version-controlled artifact. If a client asks "can you rebuild this exact environment in a new region tomorrow," the answer is yes, because the definition already exists.
Auditability. Every change to the infrastructure is a commit, with a diff, an author, and a timestamp. That's the difference between telling a compliance reviewer "we're confident it's configured correctly" and being able to show them the exact history of every change that's ever touched the environment.
Drift detection. Modern IaC tooling can compare deployed infrastructure against its intended definition and flag anything that's diverged — catching the manual portal change or the incident-time fix before it becomes an invisible liability.
Governance enforcement. Security policies, compliance rules, and access restrictions can be defined once, in code, and applied automatically to every deployment — instead of depending on every engineer remembering to configure them correctly by hand, every time.
Bicep, Terraform, and Choosing the Right Tool
For Azure-centric AI infrastructure, the two dominant real options are Bicep and Terraform, and the right choice depends on the shape of the environment more than personal preference. Bicep is Microsoft's own domain-specific language for Azure, and it integrates tightly with Azure Policy and Azure Resource Manager — there's no separate state file to manage, because Bicep is always evaluating against what's actually deployed in Azure. That's a real operational advantage for teams that are Azure-only. Terraform, by contrast, is cloud-agnostic and backed by a mature state model, which makes it the stronger choice when infrastructure spans multiple providers, or when an organization needs the most rigorous drift detection available — Terraform will actively flag when reality has diverged from its plan. Neither tool is universally correct; the decision should follow whether the environment is single-cloud or multi-cloud, not whichever tool a given engineer already knows.
What Good IaC-Driven AI Infrastructure Looks Like in Practice
Concretely, this means an AI system's entire cloud footprint — compute for inference, vector and document search indexes, secrets and key management, storage, container orchestration, and monitoring — is defined in modular, version-controlled files rather than assembled by hand. Deployment happens through a CI/CD pipeline, so promoting a change from development to staging to production is a controlled, reviewed process rather than someone remembering to repeat manual steps correctly three times. When infrastructure needs to scale, change region, or be reproduced for a new client environment, it's a matter of running the pipeline again — not reconstructing tribal knowledge about what was clicked where, in what order, eighteen months ago.
How We Approach This at Rakri AI
We don't provision AI infrastructure through the console, and we don't consider a deployment production-ready if it can't be rebuilt from its own definition. On projects requiring real infrastructure depth, we've provisioned entire cloud footprints as modular Infrastructure-as-Code — covering container orchestration, search, databases, key management, storage, and monitoring — with zero manual portal configuration, deployed through CI/CD pipelines across development, staging, and production. That's not a technical flourish. It's what makes the resulting system something a client can actually own, audit, and hand off to their own team without us being in the room.
Maturity Is a Choice, Not an Accident
Portal-configured infrastructure isn't a failure of effort — it's usually just the fastest path to something working in a demo. The problem shows up later, when "working" needs to become "auditable, reproducible, and someone else's responsibility." If an AI system is going into production and touching real data, ask how it's provisioned before asking anything else. The answer tells you whether you're looking at a system built to last, or one built to survive the first demo.
