Gives AI somewhere to run.
Provides the capacity required for training, inference, and AI applications.
Most AI readiness work addresses whether you can run models — compute, data pipelines, governance of training sets. It does not address the harder question: whether an AI system can safely understand and change the environment it is running on.
Provides the capacity required for training, inference, and AI applications.
Connects technical state to the institutional context AI needs to reason safely.
Infrastructure becomes sufficiently modeled, governed, observable, and executable.
AI-ready infrastructure is infrastructure that is sufficiently modeled, governed, observable, and executable for AI to safely understand and act upon it.
Four criteria — and they are not independent. Remove any one and the rest stop working:
Together they describe one condition: AI operating on truth it did not author, inside rules it cannot bypass, with results verified back to the model.
Assets, configuration, state, relationships, and ownership exist in one synchronized model rather than being distributed across monitoring, ITSM, IaC, and a CMDB that each describe a different version. Without this, an agent reasons from inference — and inference is indistinguishable from confidence in its output. The model itself is constructed by deterministic parsing and machine learning — never by generative AI — so an agent is reasoning against truth it did not author.
Test: Can you produce, right now, an accurate list of what you run and what depends on what?
Intent, policy, constraints, exceptions, and permitted states are expressed where they can be consulted rather than remembered. Connected change is validated before it reaches infrastructure. This is the criterion most organizations are missing, and the one credentials cannot substitute for: access defines what an agent can reach, not what it is allowed to do.
Test: Is there anything that would stop a well-formed but impermissible change before it runs?
Most enterprises have observability. What is usually missing is context attached to the signal — who owns the resource, what depends on it, what it was intended to be. Telemetry without that context tells an agent what happened but not what it means, or whether it matters. Run-state observation completes the picture: the model compares what each device runs against what is intended, so drift is observed at the source, not only in emitted telemetry.
Test: Does an alert tell you ownership and downstream impact, or only that something changed?
A decision that cannot be carried out deterministically leaves a human to translate intent into action, which is where the speed advantage disappears. Approved change executes against the model and the result is verified back into it, closing the loop rather than ending at a recommendation.
Test: When something is approved, does it execute and verify — or does it become a ticket?
How the model behind criteria one and three is built and proven — generated-not-stored, the round-trip test, and the five questions to ask of any AI-maintained model — is covered on the Authoritative Model page.
GPU capacity and a mature data platform determine whether you can train and serve models. They say nothing about whether an agent can safely change a firewall rule. These are different readiness questions and they are routinely conflated.
A more accurate record of what exists is still a record of what exists. It does not state what is allowed, and no amount of additional discovery turns a description into an authority.
Seeing the environment in detail is necessary and insufficient. It is the ceiling of the Observe ladder — full visibility, no authority — and governing change begins as a separate climb from there.
It covered data quality, model governance, GPU capacity, and skills. All of it necessary — and all of it about whether you can build and run AI. None of it asked whether AI can safely touch the systems the business runs on.
Can we train, buy, and deploy models? Data pipelines, platform capacity, model risk, talent. This work is underway in most enterprises and it is the version of “AI ready” the industry talks about.
Can an AI system safely understand and change our infrastructure? This is a different question with a different owner — and it is the one that determines whether agents ever move past supervised pilots.
The second question is cheaper to answer than the first and is usually not being asked at all. It is also the one that gates the return on the first: models you can run but cannot let act are a cost centre with a demo.
Gartner predicts that by 2028, misconfigured AI in cyber-physical systems will shut down national critical infrastructure in a G20 country — and frames the cause as internal rather than adversarial: a flawed update, a misplaced decimal.
An agent acting on an incorrect understanding of the environment does not resemble an intrusion, and no perimeter control will stop it. What stops it is infrastructure that can state what is permitted and evaluate a proposed change against it before execution — which is what the four criteria describe.
A food producer with more than 24,000 employees across 98 physical locations had bought millions of dollars of network hardware — and could not deploy it.
Their monitoring tool produced alert storms that took too long to trace and could not capture full device configuration. After a year it had not assembled an accurate CMDB or standardized naming. Signals without a model — criterion three without criterion one.
An internal infrastructure-as-code effort was not delivering what it promised. Execution capability existed; nothing defined what correct looked like for each site, so nothing could be trusted to run unattended.
This is what not-AI-ready looks like in practice — not an absence of tools, but tools without a model that holds authority. No agent could have operated safely in that environment, for exactly the reason the technicians could not: nobody could say with confidence what anything was supposed to be.
Customer under NDA; described at the customer’s level of disclosure. Read the full customer story →
Readiness is not a programme completed before any AI work begins. It is established for one scoped environment in a fixed order — because each criterion depends on the one before it.
Systems connect read-only and the model reconciles what the cloud APIs report, what IaC declares, what the CMDB records, and what monitoring observes. Where they disagree, the disagreement is the first finding.
Intent, policy, constraints, and permitted states are captured against the model and validated against your historical change decisions — so you see how it would have behaved before it governs anything.
Once signals attach to a model that knows ownership, dependencies, and intent, observability gains context without new tooling. It becomes an effect of the model rather than a separate investment.
Governance turns on as a decision, starting with the change types where a mistake costs most. Only then do people, automation, and AI clear the same gate — and an agent becomes structurally unable to act outside authorized state.
What changes when agents propose and act, not just answer.
Two terms that sound alike and answer different questions.
The buyer path for the leader accountable for agents.
AI infrastructure gives AI somewhere to run. An Infrastructure Operating Model gives AI an environment it can safely understand and act upon.
Readiness has an architecture, a security posture, and a test. These pages take each one further.
The structural requirements an environment has to meet before an agent can reason about it.
Hardware for training models and an environment an agent can safely operate are different problems.
What changes when the actor proposing change is autonomous rather than supervised.
Where the controls sit when an agent can act, and what has to hold before it does.
AI-ready infrastructure starts with the model.
Start with the six-question self-assessment. Then use a 60-minute working session to test the result against your environment and choose the right first scope.
The self-assessment returns an AI-Ready Infrastructure Score from 0 to 100. The working session tests the main gaps against real evidence. No infrastructure connects during the session.