My Honest Checklist for CIOs on AI-Ready IT: What I Look for Before Saying Yes to Any AI Initiative
An AI-ready IT infrastructure checklist for CIOs covers seven data foundation requirements: discovery completeness above 90%, CI data freshness within 30 days, current blast radius mapping, validated CI ownership, explainable automated actions, AI model reconciliation against live discovery data, and a 90-day queryable audit trail. Without these, AI systems act with confidence on incomplete or stale information — a greater operational risk than not deploying AI at all.
Every quarter I get proposals for AI initiatives in IT: automated remediation, AI-assisted change advisory, intelligent alerting, agentic ticketing. Some are genuinely promising. Some are solutions looking for a problem. For a CIO, the harder question is never whether an AI initiative has theoretical merit — most do. It is whether the IT organization’s data foundation can support it. This is my AI-ready IT infrastructure checklist for deciding just that.
Industry analysis consistently identifies data quality failures — not model limitations — as the primary reason enterprise AI deployments produce wrong outcomes at scale. An AI system acting on incorrect or stale infrastructure data does not fail gracefully. It acts with confidence on wrong information, and in IT operations, that is more dangerous than not having the AI at all.
Salil Kulkarni has served as CIO in enterprise IT environments and advises organizations on AI governance and infrastructure readiness.
Why I developed this checklist
This is not a framework from a consulting engagement or a vendor evaluation guide. It is a set of questions I ask because I have seen AI initiatives fail in specific, avoidable ways, and in each case the failure traced back to one of these seven items being absent.
I am also not suggesting that an AI initiative is safe once all seven items are checked. I am suggesting that without them, the initiative is demonstrably not safe, and no amount of model sophistication compensates for infrastructure data that cannot be trusted.
Item 1: Can you show me where every asset is and what it is doing right now?
Not what it was doing last quarter. Not what the documentation says it should be doing. What the infrastructure is actually producing, discovered from the network, right now.
I ask this question by requesting a discovery scan comparison against the CMDB for the segment the AI initiative will operate on. If the delta between what discovery finds and what the CMDB records is more than 15%, the AI is operating on a data set with meaningful blind spots. Automated remediation on a 15%-incomplete infrastructure map will take corrective actions against the 85% it can see and leave the 15% — potentially including the actual source of the problem — untouched.
Discovery completeness is the foundation. Everything else in this checklist sits on top of it. That comparison should be available on demand — not tied to a separate scan project every time an initiative comes up for approval. Virima IT discovery
| What discovery completeness threshold does an IT environment need for AI initiatives? |
|---|
| For AI systems making automated remediation or change decisions, I use 90% as the minimum, meaning less than 10% of the infrastructure the AI will operate on should be undiscovered or unrepresented in the CMDB. Below that threshold, the AI’s decision surface has blind spots large enough to produce confident wrong actions. For read-only AI recommendations (no automated execution), 80% coverage is an acceptable starting point. |
Item 2: When was this data last updated, and from what source?
The source matters as much as the date. CMDB data updated by manual entry six months ago is different from data updated by a discovery scan. The manual entry reflects what someone believed was true; the discovery scan reflects what the infrastructure confirmed was true.
I ask for explicit source attribution on any CI record the AI will act on: what generated this record, when, and from which discovery method. CMDB accuracy is the precondition every AI initiative depends on, not a future state. To achieve Trusted Runtime Truth, the data must be explainable all the way back to its origin — not just current, but traceable.
For AI initiatives in active operational environments, I set a maximum data age of 30 days for the CI segments the AI will operate on. For change automation specifically, I require a fresh scan within 7 days of any change window.
Item 3: If this service fails, what else fails with it?
In IT, blast radius refers to the scope of services and infrastructure components that fail or degrade when a single service goes down. An AI system without that understanding is operating without consequence modeling. It can identify that Service A is degrading. It cannot determine whether restarting Service A will cascade into Services B, C, and D unless the dependency map is complete and current.
I ask to see the ViVID™ service map for the tier-1 services the AI will interact with. If the map was built from documentation rather than discovery, I ask for a discovery validation before proceeding. Blast radius maps built from architecture documents reflect the intended design. AI initiatives need maps built from what is actually connected, which only discovery can confirm.
Item 4: Who owns each production service, and how do I reach them at 2 AM?
This item sounds like an organizational hygiene question. It is also an AI readiness question. When an automated system takes an action that produces an unexpected result — and it will — the escalation path to a human decision-maker must be immediate and accurate. If CI ownership records are stale, the automated system’s escalation goes to the wrong person.
I check a sample of 20–30 CI ownership records before approving any AI initiative: call the listed owner, verify they are still responsible for that service, and confirm the on-call contact is current. A rate above 20% means the ownership data is not ready. At 20%, one in five automated escalations routes to the wrong person — too high a failure rate when response time for an AI-triggered incident is measured in minutes, not hours. So I treat that threshold as a hard stop, not a yellow flag.
Item 5: Can you explain why the AI took a specific action?
This item is about explainability, and it is non-negotiable for me. If the AI system cannot produce a plain-language explanation of each action it took — “I restarted Service A because CI record X showed configuration drift from the baseline established on date Y, and the dependency map indicated no downstream services would be affected” — then the system is operating as a black box.
The NIST AI Risk Management Framework treats explainability as a core governance requirement, not an enhancement. Black box automation in IT infrastructure is not acceptable at a board level. When an incident review asks “why did the automated system do that?”, the answer must be traceable through the data the system used, not through a statistical model that cannot be audited.
| Why does CIO-level approval of AI initiatives require explainability in data-driven actions? |
|---|
| When an AI-driven remediation produces an unexpected outcome — a cascade failure, a wrong rollback, a service disruption — the post-incident review will ask what data the system used and why it acted as it did. A system that cannot answer that question cannot be safely approved by a CIO, because the accountability gap falls on the CIO regardless of what the AI model concluded. |
Item 6: Has the team reconciled AI-asserted facts against discovery data in the last 30 days?
This item is the one most organizations skip. AI systems that consume CI data to make recommendations will, over time, build internal representations of the infrastructure that diverge from what discovery finds. Those internal representations are updated by the model, not by the infrastructure. This means the longer an AI system runs without a reconciliation against fresh discovery data, the more its internal model drifts from the infrastructure it believes it knows.
I ask for a reconciliation log: a comparison, run within the past 30 days, of the AI system’s internal infrastructure model against a fresh discovery scan of the same segments. Any delta — CIs the AI believes exist but discovery cannot confirm, dependencies the AI is routing around that no longer exist — must be resolved before the AI system’s next decision cycle.
Item 7: Can you audit every automated action taken in the last 90 days?
The final item is audit completeness. Every automated action the AI system takes must be logged with: the action taken, the CI records it acted on, the data state of those CIs at the time of action, the rule or threshold that triggered the action, and the timestamp.
This log must be queryable for at least 90 days. For regulated industries, I extend this to 12 months. When a compliance audit or a board inquiry asks about automated IT actions, the answer must come from a log, not from reconstructed memory.
For more on how IT risk registers intersect with automated action governance, that specific governance layer deserves its own examination. The conversation about what AI-ready IT infrastructure requires is one I am having with more CIO peers every quarter.
| What must an AI system audit log contain for board-level scrutiny? |
|---|
| Every automated action must be logged with: the action taken, the CI records acted on, the data state of those CIs at the time of action, the rule or threshold that triggered the action, and a timestamp. That log must remain queryable for a minimum of 90 days — 12 months for regulated industries. When a compliance audit or board inquiry asks why the system acted as it did, the answer must come from a log, not reconstructed memory. |
What I hear from my peers
When other CIOs ask me about AI readiness, the same questions come up repeatedly. Here are the answers I give.
