Most customer data platforms are evaluated against the wrong bar. The prevailing definition of “AI data readiness” — completeness, deduplication, documented lineage, governance controls — measures whether data is analyzable. It does not measure whether data is serveable to a model at the moment a decision is made. These are two different bars, and a customer data platform can clear the first while failing the second entirely.

The distinction matters because the marketing use cases now driving AI investment are reactive. An agent deciding a next-best action mid-session, a real-time personalization engine choosing an offer, a conversational assistant answering a customer — each acts on what is true right now, and each needs the customer’s full profile returned programmatically within the window the decision allows. A data platform that produces clean, unified profiles on an overnight batch is ready for reporting and audience building. It is frequently not ready for an agent that has to act in seconds.

Gartner’s Market Guide for Customer Data Platforms has tracked the shift from packaged CDPs toward composable, warehouse-native architectures, and much of that shift is downstream of this exact gap. The purpose of this analysis is to separate the two readiness bars, define AI-readiness precisely enough to test for it, and show which parts of it packaged CDP architecture — Salesforce Data Cloud, Adobe Real-Time CDP, and Twilio Segment among them — structurally cannot deliver. The conclusion is not that packaged platforms have bad data. It is that whether a packaged CDP is “AI-ready” depends entirely on the decision horizon of the use case being tested.

Defining AI-ready customer data

AI-ready customer data is data that can be served to a model at decision time, not merely stored and queried for analysis. That is a serving standard, and it decomposes into four conditions that must hold at the moment of inference.

1. The profile must be unified — one resolved entity, not fragments the model is left to stitch together at request time.
2. It must be fresh — reflecting events from seconds ago, not the state captured by last night’s batch.
3. It must be governed at serve time — consent, purpose limitation, and lineage travelling with the profile so the model uses only what it is permitted to use, evaluated when the profile is served rather than when it was assembled.
4. And it must be programmatically accessible — retrievable for a single entity through an API within the inference window, not exported as an audience or synced to a downstream tool on a schedule.

The contrast is with what can be called analytics-ready data. Analytics-ready data is unified and clean, but it is optimised for humans looking backward: dashboards, segmentation, attribution, model training. It is accessed in bulk, tolerates a batch cadence, and is governed at rest. This is the bar that most “AI data readiness” checklists actually measure, and it is a necessary foundation. The error is treating it as sufficient. Analytics-ready certifies that data is fit to be analysed. AI-ready certifies that data is fit to be served into a live decision. The second is a higher and structurally different bar.

Matching the readiness bar to the decision horizon

Real-time serving is not a virtue in itself, and treating it as one leads to over-engineering. The AI-ready bar is worth paying for only where the decision is reactive to state that has recently changed. The organising principle is to match the readiness bar to the decision horizon of each use case.

Several classes of decision genuinely require it. In-session intent is the clearest: a customer who has just searched for cancellation terms, added a competitor’s product to a comparison, or hit repeated errors is described entirely by events from the current session, and a profile refreshed overnight represents who they were yesterday. Consent and suppression state is the second, and it carries legal weight: when a customer revokes consent, unsubscribes, or is flagged, a platform that propagates that change on a nightly cycle will continue to permit action against them for hours, which is a compliance exposure under regimes such as GDPR and CCPA rather than a relevance miss. Fast-moving operational state — inventory, price, balance, order status, whether another channel has already made contact — is the third, because an agent that confidently asserts something true this morning and false now erodes trust faster than silence would.

Equally, a large set of use cases does not need it, and honest scoping says so. Nightly propensity, churn, and lifetime-value scoring that feeds a campaign; audience construction; attribution and reporting; any decision whose horizon is measured in days — all of these are served perfectly well by analytics-ready data on a batch cadence. Buying real-time serving infrastructure for them adds cost and operational complexity without a corresponding return. The test that follows is therefore applied per use case, against the use cases whose decision horizon is measured in seconds.

A five-criterion test for AI-ready customer data

Readiness can be assessed rather than asserted. Five criteria, each scored as pass, conditional, or fail, determine whether a platform can serve a given real-time use case.

1. The first is freshness and latency: can the platform reflect a new event and serve the updated profile inside the inference window — typically sub-second to a few seconds — rather than on an hourly or nightly cadence.
2. The second is profile completeness at serve time: is the object available in real time the same unified profile used for analysis, or a thin subset held at the edge while the full profile lives in a separate batch store.
3. The third is consent at decision time: is the consent and suppression state current when the model acts, or reconciled on a lag.
4. The fourth is feature and lineage access: can models retrieve governed features with their lineage intact, or only pre-built audiences.
5. The fifth is programmatic access: is there per-entity retrieval through an API or an equivalent interface, or is activation limited to audience export and reverse ETL.

A use case passes only where all five hold. The value of scoring them separately is that failure is rarely total — a platform typically passes some and fails others, and the specific failures point directly at the architectural cause rather than a general verdict. This scorecard is the artefact a data team can apply to its own platform, and it is rendered as the test matrix in this analysis.

Where packaged CDP architecture falls short

Consider a single use case throughout: an AI agent selecting a next-best action during a live customer session, which requires the complete, consent-aware profile returned in roughly a few hundred milliseconds. Scored against the five criteria, the leading packaged platforms tend to fail on different criteria, and the reasons are architectural rather than matters of data quality. The latency figures below are illustrative, used to indicate order of magnitude rather than measured benchmarks.

Salesforce Data Cloud is built on a data-lake foundation, with segments and calculated insights computed on a batch or scheduled cadence. Streaming ingestion exists, but the derived attributes an agent would rely on — computed traits, calculated insights — are materialised on a schedule rather than at request time. The typical failure is freshness and latency: the raw event may arrive quickly, but the computed profile the agent needs lags behind it. Its analytics-ready credentials are strong; the serving path for a seconds-horizon decision is the weak point.

Adobe Real-Time CDP distinguishes an edge profile, held for low-latency activation, from the full profile in the hub. The edge profile is deliberately a subset — a bounded set of attributes and audiences replicated for speed — while the complete unified profile remains in the central store. For an agent needing the whole profile, this fails profile completeness at serve time: what is fast is partial, and what is complete is not fast. The naming implies real-time completeness that the architecture scopes down for good latency reasons.

Twilio Segment exposes a Profile API and computed traits, but trait computation and audience synchronisation introduce latency between an event and its reflection in the served profile, and much activation runs through downstream syncs on a schedule. The common failures are freshness and, for richer needs, feature and lineage access, since what is exposed is computed traits and audiences rather than governed features with lineage. It is strong for identity stitching and activation; less suited to serving governed features into live inference.

Each platform genuinely passes the criteria that matter for batch and analytical work, and for many organisations that is the whole requirement. The point is narrower and structural: the same architectures that make these platforms excellent analytics-ready systems — precomputation, edge subsetting, scheduled synchronisation — are the reason they miss specific AI-ready criteria for the seconds-horizon case.

What clears the AI-ready bar

The pattern that passes the test serves the profile from where the complete data already lives rather than copying a subset elsewhere for speed. In a warehouse-native or composable arrangement, the unified profile is maintained in the data platform — a warehouse or lakehouse such as Snowflake, BigQuery, or Databricks — and served through a low-latency layer that reads the current profile, evaluates consent and lineage at the point of serving, and returns the full entity through an API in the inference window. Because there is no separate edge copy to reconcile and no scheduled trait job standing between the event and the served profile, the same object is both complete and current, and governance is applied when the profile is served rather than when it was assembled.

This is not free, and it is not always the right call. It requires engineering ownership of the serving layer, a warehouse capable of the required read latency, and a team comfortable operating that infrastructure. For an organisation whose AI use cases are batch-horizon, or one without the engineering capacity to run a serving layer, a packaged CDP remains the pragmatic choice — it clears the bar those use cases actually set, and imposing a composable architecture on a batch requirement is a net loss. The verdict is architecture-driven and use-case-driven, not a matter of vendor preference: match the serving pattern to the decision horizon, and adopt the warehouse-native path only where the seconds-horizon use cases justify it.

Conclusion

AI data readiness is not a single checklist score. It is two bars — analytics-ready and AI-ready — where most platforms clear the first and the second is defined by the ability to serve a complete, current, governed profile into a live decision. Whether a packaged CDP is “AI-ready” is therefore not answerable in the abstract; it depends on which use case is being tested and how fast its decision horizon is.

The practical step is to inventory AI use cases by decision horizon, separate the batch-horizon ones from the seconds-horizon ones, and run the five-criterion test — freshness and latency, profile completeness at serve time, consent at decision time, feature and lineage access, and programmatic access — against the current platform for the seconds-horizon cases only. Where the platform passes, no change is warranted. Where it fails, the failure will name its own architectural cause, and that is the point at which a warehouse-native serving path earns its cost.

For teams working through this systematically, the customer data infrastructure pillar sets out the underlying capabilities a data layer needs to serve AI use cases, and how packaged and warehouse-native approaches differ across them. It is the place to start before scoring a specific platform against the readiness test above.