Check Your Data Before You Build on AI

Is the data good enough for this particular decision?

Data readiness is always relative to a decision. A dataset can be fit for a monthly trend report and unfit for an assistant that recommends whether a payment should be held. The same customer table may be complete enough for one and riddled with stale addresses for the other. So the first question for a data owner is not whether the data is good, but which decision it must support, how often that decision is made, and what a wrong answer costs the person who acts on it. Once those three facts are written down, the rest of the assessment has a fixed target.

This framing also tells you when to stop. If the decision is low consequence and the output is reviewed by a person before anything changes, a modest level of data quality may be acceptable and the work becomes a matter of documenting known gaps. If the decision is high consequence or happens without review, the data has to meet a stricter standard, and that standard usually requires remediation before the AI is connected at all.

Which checks matter most and in what order

Teams that assess data for AI often start with profiling: counts of nulls, duplicate rates and value distributions. Profiling is useful, but it answers the question of whether the data is clean, not whether it is authoritative. A table can be spotless and still be the wrong source because the system of record sits elsewhere. The sequence below puts authority first, then access, then quality, because a quality fix applied to a non-authoritative copy is wasted effort.

The table is a sequence as much as a checklist. If the source is not authoritative, there is little point measuring its completeness. If access is restricted in a way that prevents the workflow from using the field at all, then freshness and structure become academic. Working in this order avoids a common waste of effort, in which the team polishes a dataset that can never be used in production.

Why more data does not make a workflow more ready

A large collection can look like an asset, and it is tempting to feed everything into an AI workflow and let it sort out relevance. In practice a broad feed usually makes results harder to explain. Irrelevant records dilute the signal, conflicting sources produce answers that sound confident and disagree with each other, and access rules that were designed for a narrow report are suddenly applied to a system that reads far more. The better approach is to narrow the input to the fields and records the decision actually needs, then widen only when an evaluation shows a gap.

Where data readiness work usually goes wrong

Three failure patterns recur. The first is treating readiness as a one-off exercise. Data changes as processes change, and a readiness decision made last year may no longer hold once a new intake channel starts sending records in a different format. The second is leaving data ownership vague. When a quality issue is found, the people who discover it often have no authority to fix the source, so the issue is recorded and then forgotten. The third is confusing readiness with permission. A dataset can be ready in quality terms and still be off limits for a given workflow because of privacy obligations, contractual restrictions or internal policy. Those constraints need their own sign-off, not an assumption that technical readiness covers them.

Data-protection obligations deserve particular attention. Personal information that is harmless in a reporting table can become sensitive once an AI workflow is allowed to summarize it, quote it or pass it to another service. The data owner should record which fields may be read, which may be retained, and which must be masked or removed before the workflow sees them.

How do sector and regulation change the readiness standard?

Sector regulation does not create a separate type of data, but it changes the evidence needed to justify using it. A workflow whose outputs may later be examined by an auditor needs a record of which source was used, which version was current and who approved the output. Organizations that already keep such records for reporting have a head start. Those that do not will need to create them before any AI workflow touches a decision that carries regulatory weight.

A readiness decision can be a decision to wait

A readiness assessment that ends in a recommendation to proceed is not automatically a good assessment. Sometimes the right answer is to stop, fix the source or narrow the scope, and come back once a specific test passes. A useful report names the gaps, states whether each one blocks the decision or only limits it, records who owns the fix and describes the test that would change the verdict. Vague conclusions such as the data needs improvement give nobody a task to start on Monday.

Where remediation is needed, the work often sits in the source systems rather than in the AI project, and the people who own those systems may have priorities of their own. Making that dependency explicit in the readiness report is what allows the AI initiative to be scheduled honestly against the remediation work.

Which related services help when data is the constraint?

Readiness work sits inside the wider AI and machine-learning services range, and the adjacent data work depends on which kind of gap is present. When the gaps are about strategy, meaning which data should exist and who should own it, the data strategy consulting service is the more natural starting point. When the gaps are about movement and transformation, the data engineering and pipeline development page is the one to read. On ServiceNow estates, the source authority and quality questions often come down to configuration item records, and the CMDB data quality governance and data governance and source authority guides cover CMDB data quality and governance, and which source is authoritative for a field.

Questions data owners ask before an AI assessment

Do we need to clean everything before any AI work starts?

No. Clean the subset the decision depends on, document the rest as out of scope, and make sure the workflow cannot reach the uncleaned data by accident. Scope restriction is often the fastest route to a usable first release.

Who should sign off a readiness decision?

The data owner should sign off on source authority and quality for the fields in scope. The security or privacy lead should sign off on access and permitted use. The business owner should accept any residual risk. A single signature from one of these roles is not enough.

How often should readiness be reviewed?

Review it when the decision changes, when a source system changes, or when the evaluation shows a pattern of errors that the readiness report did not predict. A calendar date alone is a weak trigger.

Can an AI tool itself help with the assessment?

It can help with profiling and with finding inconsistent values, but it cannot decide authority or permitted use. Those judgements sit with people who understand the business and the obligations attached to the data.

If a dataset is about to become the input to an AI workflow, bring the decision it must support, the source systems involved and the person who owns each one. The conversation can then focus on which checks matter for that decision and whether remediation should come before any build. Discuss your data readiness.