The AI-ready data conversation has arrived in asset-intensive industries with all the force, and most of the imprecision, of every previous data-readiness conversation. Boards are asking whether the asset register is AI-ready. CIOs are funding data programmes against the term. Vendor proposals quote it back. And asset management functions, who own the data the question is really about, are being asked to deliver against a target nobody has bothered to define in domain terms.
That is worth pushing back on. AI-ready, as currently used, is the wrong threshold for asset data. It is a category from outside the asset domain, defined by the data needs of generic enterprise models, and it produces unbounded data programmes that never finish. The better threshold, the one that actually disciplines investment, is decision-ready: data sufficient to support the named decisions an asset management function has to make, governed to a level proportionate to the consequence of those decisions.
What “AI-ready” Actually Demands
There is no neutral definition of AI-ready data, and that is the first problem. Gartner’s working definition, the one most often cited, is data aligned to specific use cases, governed at the asset level, supported by automated pipelines, and continuously quality-assured. That is reasonable. It is also a definition that explicitly depends on the use case. AI-ready for a large language model embedded in a knowledge base is not the same as AI-ready for a failure probability model in Maximo Predict, which is in turn not the same as AI-ready for a computer vision model fed by a phone camera in the field.
The asset register that supports all three at the level a regulator would accept is rare in operators of any scale. Each model has different needs around lineage, freshness, label quality, sample balance, bias, and explainability. A data programme scoped to “make our asset data AI-ready” therefore has no defensible boundary. It is a programme to make the data ready for any model, on any timescale, against any future regulatory expectation. That is not a programme. It is a permanent budget line.
Why The Threshold Matters
Thresholds matter because they decide when the data work is finished and the spending stops. A capital sponsor who funds an “AI-ready asset register” cannot be told, two years in, that the work is half done because two more model classes have appeared since the business case was approved. The threshold is the governance object, not the data.
Three things follow from a missing threshold.
The work expands without producing decision value. Organisations end up cleaning fields nobody uses, populating attributes no decision relies on, and reconciling taxonomies whose only consumer is a future model that has not been specified. Months of effort go into data that has no current asset management decision attached to it.
Vendor roadmaps end up setting the scope. Once AI-ready is the target, the practical definition becomes whatever the next AI capability from the platform vendor assumes. The data programme chases the product roadmap. That is a poor place for an asset owner to be, because the roadmap is optimised for the vendor’s portfolio, not the operator’s risk profile.
The asset management function loses control of its data agenda. The decisions that determine the condition and resilience of the estate (what to renew, what to defer, what to retire, where to place reliability investment) require specific evidence. If the data programme is funded against AI readiness rather than against those decisions, the asset management function is taking delivery of someone else’s priorities.
Decision-Ready As The Better Threshold
The alternative is to define the threshold inside the asset domain.
Decision-ready data is data sufficient to support a specific, named asset management decision at the assurance level the organisation has agreed for that decision. The decisions are knowable in advance because they are not a function of the AI roadmap. They are a function of how the asset estate is operated and governed.
In a typical asset-intensive operator, that list is short and stable:
- Which assets are most critical, and what the consequences of failure are
- Which assets need renewal in the next capital cycle, and which can be safely deferred
- Which failure modes justify proactive intervention, and at what frequency
- Which interventions are required for compliance, and which are discretionary
- Where the maintenance backlog exposes the organisation to material risk
For each of those decisions, the data requirement is finite. Asset identification, location, criticality, condition indicators, failure history, intervention cost, and compliance status are not infinite domains. They are scoped, and once scoped they can be governed to a defensible standard. The work has a definition of done.
If, later, an AI model wants to consume that data, it consumes it as one user among many. The data was not built for the model. The model fits the data, or it does not. That is the right power balance for an asset owner.
What This Looks Like In Practice
Moving from AI-ready to decision-ready is not a technical change. It is a small set of operating-model and governance moves that most organisations can make inside an existing programme.
- Name the decisions. Write down the asset management decisions the data is expected to support, with the cycle they sit in (capital, operational, compliance) and the assurance level expected by the audience. Where the decision is not named, no data work should be funded against it.
- Map data requirements to decisions, not to models. For each decision, define the minimum data set, the freshness required, the source of record, and the lineage that has to be defensible. ISO 8000 gives a usable vocabulary for data quality requirements; ISO 55013 gives the asset-management-side framing.
- Govern at the decision level. Assign a data steward to each decision, not to each system. The steward owns the question “is this decision currently supportable from the data we have”, and reports against it on the cycle in which the decision is made.
- Treat AI inference as a downstream consumer. When an AI capability arrives that wants to use the same data, it inherits the existing governance, with the same lineage and the same audit trail. Where the model needs more (more samples, more labelling, more frequent refresh) that is a separate, scoped piece of work, funded against the model’s value case, not against the asset register.
- Retire the unbounded backlog. Any AI-readiness workstream that cannot point to a named asset management decision should be wound down. The work either feeds a decision, in which case it gets scoped properly, or it does not, in which case it is consuming budget that the decision-driven backlog needs.
This is consistent with the discipline set out in asset data governance that actually works, and with the argument about the link between asset evidence and capital governance in asset management’s missing seat at the capital table. The same operating logic, applied to the AI-readiness conversation, produces a defensible scope rather than an open one.
The Position
The honest position for an asset management leader sitting in front of an AI-readiness business case is this. AI-ready is a useful test for whether your data can support a specific model class. It is a poor target for a multi-year asset data programme, because it has no boundary and no domain owner. Anchored to the decisions the asset management function actually makes, the same investment produces evidence that holds up to audit, supports the capital cycle, and can be consumed by an AI model when one arrives. Anchored to AI-readiness alone, it produces a perpetual data project with diminishing political support and no defensible end state.
Where the threshold is set is a leadership choice. It is also one of the few choices in the asset data conversation that does not require a vendor to make it.
For more on how MaxIron approaches asset data and decision support inside MAS programmes, see our services overview.