If Your Data Isn't AI-Ready, Neither Is Your Initiative

An e-procurement platform came in with a clear AI idea: build a recommender that matches companies to the most relevant public tenders. The use case made sense. The logic checked out. The CTO said the data was ready.

It wasn't.

Once we looked closer, the issue became obvious. Tender descriptions were inconsistent, incomplete, and often too vague for any meaningful matching. Company profiles were worse - sparse, unstructured, self-reported text that gave an AI system almost nothing to work with.

So we took two steps back.

Before building the recommender, we built what was actually missing:

• A system to help users create clear, structured, high-quality tender descriptions - guided and enriched by LLMs
• A system to help companies generate complete, accurate profiles - pulling data, filling gaps, standardizing structure

Neither was part of the original plan. Both were essential.

The recommender only came after.

This is not an unusual story. The failure mode is consistent: an organization identifies an AI use case, confirms that data exists, and begins the initiative. The mere existence of data doesn't mean data readiness. The gap between those two things is where most AI initiatives stall — in week three of a sprint, when the ML engineer surfaces problems the data team has been working around for years.

The five practices below are not a data quality checklist. They are the sequence that converts an organization's existing data environment into one that AI systems can actually use - and that compounds in value with every AI asset built on top of it.

Before going further: if your organization is in exploration mode - curious about AI but without a specific use case in mind - this is premature. Come back when you have a use case, a target metric, and a team ready to build.

This is for organizations that have an AI initiative in sight and are about to discover that their data is not in the shape they assumed.

1. Audit and Classify Data by AI-Readiness Before You Touch a Model

The most reliable way to lose a sprint is to begin it without knowing what you're working with. The audit comes before the build - not because it is pleasant, but because discovering your data classification in week six of a sprint is the most expensive possible version of finding out.

Most organizations treat data readiness as a binary: we have the data, or we don't. The question that actually matters is which tier the data falls into. Four tiers:

Most organizations, when pressed, will implicitly assume their data sits in tiers three and four. The actual distribution is typically less comfortable. Tier one and two categories tend to be larger than expected - and the problems that put data there are rarely visible from the surface. They live in the column names no one documented, the joins that work technically but mean nothing semantically, and the timestamps from a 2021 migration that were never fully corrected.

Take a customer table, the kind every B2B company has. In its rawest and most common form I've seen: free-text company names entered by sales reps over eight years; three different conventions for company names; industry codes that were optional in 2019 and mandatory in 2022; and a last_active field that silently reset during a 2021 CRM migration. That data is not ready (tier one) for a churn model - the migration artifact alone will teach the model the wrong thing. Deduplicated and standardized company names, with industries backfilled and the migration window flagged, the data becomes tier two: usable, but only after the cleanup is scoped and budgeted. Documented, with a semantic layer explaining what last_active actually means post-migration, it becomes tier three - a RAG pipeline can ground answers on it. Labeled with verified churn outcomes across a balanced distribution of segments, it becomes tier four.

The audit surfaces this before the sprint starts. Done upfront, it costs an afternoon. Done during the sprint, it costs the sprint.

2. Build Comprehensive Metadata - The Most Underrated AI Infrastructure Investment

Most organizations have a reasonable definition of metadata: timestamps, table names, schema documentation, maybe some column descriptions. That is not what AI systems need.

AI systems need to understand what data means in business terms - not just what it contains. The distinction is the difference between a system that works and one that hallucinates plausible-looking results.

Comprehensive metadata means documenting not just the structure of your data, but the business logic behind it - what each data source represents, why it exists, how its components relate to each other, and what implicit rules govern how it should be interpreted. For a relational database, that means table descriptions, valid relationships, column-level definitions, domain groupings, and the custom logic behind derived fields. For a document corpus, it means source classification, recency rules, and the business context that determines when a document is authoritative versus outdated. For an event stream, it means what each event type signals, which combinations are meaningful, and what the absence of an event implies.

The principle is the same regardless of the data source: an AI system needs to understand what the data means - not just what it contains.

The Text-to-SQL agent we built for a Fortune 500 client operates on one of the most complicated relational database schemas: hundreds of tables, dozens of valid join paths, and business logic accumulated over fifteen years of product evolution. The agent works. Anyone in the organization can ask a question in plain language and receive a correct, structured result.

It works because of one investment that had nothing to do with the model: every table in that schema has a concise explanation of what it contains, why it exists, how it relates to adjacent tables, and what business process generated it. Column names that are not self-explanatory have definitions. Groups of tables that serve a specific business function are documented as a unit. The custom logic behind derived fields is written out.

Without that metadata layer, the agent hallucinated joins, misinterpreted column semantics, and returned results that looked plausible and were factually wrong. We tested this deliberately early in the project. The gap in output quality was the difference between usable and an unacceptable AI agent.

Every additional AI asset built on top of that schema will be more capable, less expensive to build, and faster to ship than it would have been without it. The investment compounds.

Two tracks, depending on where your organization is:

If you are building a digital product from scratch, this is the ideal moment. Use LLMs to generate the initial metadata layer as you build - document what each table contains and why as you add it. The cost at this stage is near-zero. The compounding value across every future AI asset is significant. Organizations that skip this in year one spend significant engineering effort trying to retrofit it.

If you have an established data infrastructure, this is still the right investment - but it is an initiative, not an afternoon's work. It requires engineering time, business input to validate the semantic layer, and probably multiple phases. The correct approach is domain by domain, not organization-wide. Which domain comes first is determined by which data sources your first AI use case depends on - the same logic that governs data quality sprints in Section 4.

3. Calculate Metrics and Build BI Views - Using Your Data to Understand It

One of the most reliable ways to assess data readiness is to build something with the data. Organizations that have built basic BI views on top of their data sources have already resolved a significant fraction of the data quality problems they don't yet know they have - because building a view forced them to confront inconsistencies, null rates, and semantic ambiguities that were invisible in the raw tables.

The value is practical and organizational:

• BI views create a forcing function for data pipeline discipline. If the view breaks, someone notices.
• Building metrics develops organizational understanding of which data sources matter and why: what needs to be kept, how pipelines should be set up, and what the data actually represents.
• The process surfaces the gap between what the data engineering team thinks the data means and what the business team thinks it means. That gap, discovered in a BI session, costs nothing. Discovered in month 3 of a project, it costs multiple sprints.

The most important metrics to build first: understand your customers (who they are, how they behave, and where they stop); understand trends (what is changing and at what rate); understand product usage (which features, which flows, which exit points). These are not sophisticated analytics requirements. They are the baseline that tells your organization what it is working with.

Leverage data engineers and modern LLMs to create the initial views. The goal is not a polished analytics product - it is visibility. Teams that have never built BI views on their data consistently overestimate its quality. The build is diagnostic as much as it is useful.

4. Run Scoped Data Quality Sprints - Not Organization-Wide Cleanup

"Improve data quality across the organization" is a project that does not ship. It has no definition of done, no clear owner, and no connection to a specific business outcome. It sits on the backlog for months - sometimes years - as an initiative everyone agrees is important and nobody prioritizes. The reason it never ships is not organizational failure. It is a scope failure.

The correct frame: a scoped data quality sprint tied to a specific AI use case.

Before the sprint starts, you know your first AI asset - because you have run the prioritization process that identifies it. That asset depends on specific data sources. Three of them, typically, if the scope is right. Those three sources get the sprint. Everything else waits.

The sprint has a definition of done: those three sources move from their current classification tier to AI-ready. That is the exit criterion. The sprint ends when the data is ready - not when the calendar says it should be.

This is not a concession on ambition. It is the only approach that ships. Organizations that attempt organization-wide cleanup first never reach the AI asset. Organizations that tie the data work to the AI asset scope ship both.

The scoped sprint is not a standalone decision - it is a direct output of the AI strategy process described in The Hidden ROI Killer in AI Projects. The prioritization framework in that post produces a first AI use case: high expected gain, understood complexity, agreed definition of success. The data sources that asset requires are exactly the ones that get the first sprint. And the scoring dimension that typically generates the largest gap between business and technical teams is data availability - not "do we have data," but "is our data structured, accessible, and in a shape an AI system can use?" Clickstream data and labeled training examples are not the same thing. When a CPO scores data availability at 4 and an ML engineer scores it at 2, that gap is exactly what the sprint is designed to close - and the sprint starts with the sources the first AI use case actually depends on.

One note for larger organizations: retrospective metadata creation - the work described in Section 2 - will itself require multiple data quality sprints at scale. The same logic applies: one domain at a time, sequenced by the AI asset roadmap, not as a standalone cleanup initiative.

5. Standardize Ingestion, Data Format, and ETL Pipelines Before You Scale

The first four sections are about understanding, documenting, and fixing your data. This section is about building the infrastructure that makes every subsequent AI asset cheaper, faster, and more capable than the one before it.

Standardization is the scaling layer. It is most valuable once you know which data you need to standardize - which is exactly the knowledge the audit, the metadata work, the BI build, and the scoped sprints produce. The sequence is intentional.

What standardization enables:

• Preprocessing costs that do not grow linearly with data volume
• ETL pipelines that remain manageable as the number of AI use cases grows
• A shared data layer that allows AI assets to compound - where the output of one asset becomes the input of another, without bespoke integration work for each connection

The most important consequence of non-standardized data is architectural: a central AI intelligence that transforms isolated AI use cases into a compounding ROI system becomes functionally impossible. You cannot build a network on incompatible data formats. The cost of connecting assets grows with each addition rather than decreasing. The system becomes brittle before it becomes powerful.

An organization that has completed all five steps has something that most AI-invested organizations do not: a production-ready data foundation and a BI system, and an infrastructure that makes every AI asset built on top of it faster and cheaper to build than the one before.

And it all brings us down to the often underrated question:

Are you building a shared intelligence layer - or just isolated AI wins?

The clients who move fastest on AI are not the ones with the most data. They are the ones who built the data foundation before they needed it - or who, when they found they hadn't, were willing to take two steps back before moving forward.

The most powerful version of this is not one AI asset built on clean data. It is three to five assets that share the same foundation and compound each other's outputs.

For a Fortune 500 client with over 100,000 employees, the Text-to-SQL agent we built does not just answer questions from human users. It is architected to be callable by other agents across the organization - any agent in any department can query the core data layer without bespoke integration, without a data analyst in the loop, without a dedicated pipeline built for that use case. The Text-to-PPTX agent calls it to populate presentation slides with live data. The data visualization agent calls it to generate charts on demand. A reporting agent in a different business unit calls it to pull the specific metrics its weekly summary requires.

The result is a shared intelligence layer that democratizes access to the organization's most valuable data source across 100,000 employees and an unlimited number of future agents, without the infrastructure cost growing proportionally with each new connection.

That is only possible because the metadata layer exists. Because the data format is standardized. Because the ETL pipelines were built to a consistent specification. Remove any one of those elements, and the agent is a silo. With them, it is a platform.

Before you close this post, ask yourself three things. Can you describe the data your first AI use case requires in terms of what it means - not just which tables and columns it touches? Do you have a defined scope for what data readiness means for that use case, or is it a general aspiration? And have you mapped how the second and third AI assets you build will share the infrastructure of the first - or is each one starting from scratch?

If you cannot answer those three questions, the data readiness work has not started yet.

Dušan Stamenković is the founder of Prosperaize, an AI Asset Development & Management Consultancy. He advises organizations on whether, where, and how to invest in AI - reducing risk and maximizing return across the AI investment lifecycle.