Getting Your Data Ready for AI: What to Fix Before the First Model

Getting Your Data Ready for AI: What to Fix Before the First Model

Why most AI projects stall on data rather than models, what ready actually means, and the four steps we run before building anything.

Author -

Remzo Hotić

Published -

Every AI project we have seen fail on the data side failed for the same reason: the model was asked to answer from information nobody had checked. Preparing the data is not a preliminary chore. It is most of the work, and it is where the result is decided.

AI does not fix bad data. It scales it.

What ready actually means

A model is only as good as what it can reach. Ready data has four properties. It is reachable: systems are connected, not exported to spreadsheets. It is consistent: one customer is one record. It is current: updated on a schedule you can name. And it is governed: you know who may see what. Most companies have the data. Few have it in this state.

The test is simple. Take a question your team answers every week, such as which open quotes are older than 30 days, and trace where the answer comes from. If it takes three tools and a person who knows the exceptions, the AI will need the same three tools and the same exceptions written down.

Where projects stall

The usual blockers are not exotic.

  • Duplicates. The same customer under three spellings across CRM, invoicing and support, so any answer about them is a third of the truth.
  • Gaps. Fields that were optional and stayed empty, such as industry, deal stage or contract end date, which are exactly the fields the questions depend on.
  • Silos. Knowledge in email threads, PDFs and personal folders that no system indexes.
  • Stale copies. Exports made for one report, never deleted, and later trusted as current.
  • Undefined terms. An active customer meaning one thing in sales and another in finance.

None of these are technical problems, which is why buying a better model does not solve them. Gartner estimated in 2021 that poor data quality costs organisations an average of USD 12.9 million a year, and that figure predates AI reading the data at scale.

The four steps we run first

This is the connect and clean phase of our approach, and it comes before any model is chosen.

Inventory. We list every system that holds data the process touches: CRM, ERP, analytics, documents, email, support. For each one we record who owns it, how it is accessed, how often it changes and whether it contains personal data. The inventory usually surprises people. It is the first time the full picture is on one page.

Connect. We integrate the tools you already use rather than replacing them. Data stays in its system of record and is read through APIs or scheduled syncs, so there is one source of truth and no manual exports.

Clean. Duplicates are merged, key fields are filled or flagged, and terms are defined once and written down. We do this for the fields the pilot needs, not the whole database. A perfect warehouse is not the goal. A reliable answer is.

Govern. Access is set per role before the AI sees anything: what it may read, what it may write, what is pseudonymised on the way in. This is also where retention and deletion rules are decided, which GDPR requires and auditors ask for.

What that looks like in practice

  • A pilot scoped to one process and the five to ten fields it needs.
  • A written definition of each of those fields, agreed by the people who use them.
  • A sync schedule you can state in one sentence: CRM every 15 minutes, invoices nightly.
  • A named owner per source, who signs off when the data is ready.
  • A baseline measured before launch, so the result can be compared against something.

What you can skip

You do not need a data warehouse, a data science team or a year-long migration to start. You need the fields for one process to be reliable, and a way to keep them that way. Everything else can be added once the first result is measured.

The bottom line

The model is rarely the problem. The data it is given is, and that is fixable in weeks rather than years when the work is scoped to a process instead of the whole company. Prepare the data for the first pilot properly and every pilot after it starts from a foundation instead of a cleanup.

If you want to know how far your own data is from ready, the readiness assessment starts with exactly this inventory.

HolyShift

We connect your data. We build AI into your processes. We train your team.

Follow us

Getting Your Data Ready for AI: What to Fix Before the First Model

Getting Your Data Ready for AI: What to Fix Before the First Model

Why most AI projects stall on data rather than models, what ready actually means, and the four steps we run before building anything.

Author -

Remzo Hotić

Published -

Every AI project we have seen fail on the data side failed for the same reason: the model was asked to answer from information nobody had checked. Preparing the data is not a preliminary chore. It is most of the work, and it is where the result is decided.

AI does not fix bad data. It scales it.

What ready actually means

A model is only as good as what it can reach. Ready data has four properties. It is reachable: systems are connected, not exported to spreadsheets. It is consistent: one customer is one record. It is current: updated on a schedule you can name. And it is governed: you know who may see what. Most companies have the data. Few have it in this state.

The test is simple. Take a question your team answers every week, such as which open quotes are older than 30 days, and trace where the answer comes from. If it takes three tools and a person who knows the exceptions, the AI will need the same three tools and the same exceptions written down.

Where projects stall

The usual blockers are not exotic.

  • Duplicates. The same customer under three spellings across CRM, invoicing and support, so any answer about them is a third of the truth.
  • Gaps. Fields that were optional and stayed empty, such as industry, deal stage or contract end date, which are exactly the fields the questions depend on.
  • Silos. Knowledge in email threads, PDFs and personal folders that no system indexes.
  • Stale copies. Exports made for one report, never deleted, and later trusted as current.
  • Undefined terms. An active customer meaning one thing in sales and another in finance.

None of these are technical problems, which is why buying a better model does not solve them. Gartner estimated in 2021 that poor data quality costs organisations an average of USD 12.9 million a year, and that figure predates AI reading the data at scale.

The four steps we run first

This is the connect and clean phase of our approach, and it comes before any model is chosen.

Inventory. We list every system that holds data the process touches: CRM, ERP, analytics, documents, email, support. For each one we record who owns it, how it is accessed, how often it changes and whether it contains personal data. The inventory usually surprises people. It is the first time the full picture is on one page.

Connect. We integrate the tools you already use rather than replacing them. Data stays in its system of record and is read through APIs or scheduled syncs, so there is one source of truth and no manual exports.

Clean. Duplicates are merged, key fields are filled or flagged, and terms are defined once and written down. We do this for the fields the pilot needs, not the whole database. A perfect warehouse is not the goal. A reliable answer is.

Govern. Access is set per role before the AI sees anything: what it may read, what it may write, what is pseudonymised on the way in. This is also where retention and deletion rules are decided, which GDPR requires and auditors ask for.

What that looks like in practice

  • A pilot scoped to one process and the five to ten fields it needs.
  • A written definition of each of those fields, agreed by the people who use them.
  • A sync schedule you can state in one sentence: CRM every 15 minutes, invoices nightly.
  • A named owner per source, who signs off when the data is ready.
  • A baseline measured before launch, so the result can be compared against something.

What you can skip

You do not need a data warehouse, a data science team or a year-long migration to start. You need the fields for one process to be reliable, and a way to keep them that way. Everything else can be added once the first result is measured.

The bottom line

The model is rarely the problem. The data it is given is, and that is fixable in weeks rather than years when the work is scoped to a process instead of the whole company. Prepare the data for the first pilot properly and every pilot after it starts from a foundation instead of a cleanup.

If you want to know how far your own data is from ready, the readiness assessment starts with exactly this inventory.

HolyShift

We connect your data. We build AI into your processes. We train your team.

Follow us

Getting Your Data Ready for AI: What to Fix Before the First Model

Getting Your Data Ready for AI: What to Fix Before the First Model

Why most AI projects stall on data rather than models, what ready actually means, and the four steps we run before building anything.

Author -

Remzo Hotić

Published -

Every AI project we have seen fail on the data side failed for the same reason: the model was asked to answer from information nobody had checked. Preparing the data is not a preliminary chore. It is most of the work, and it is where the result is decided.

AI does not fix bad data. It scales it.

What ready actually means

A model is only as good as what it can reach. Ready data has four properties. It is reachable: systems are connected, not exported to spreadsheets. It is consistent: one customer is one record. It is current: updated on a schedule you can name. And it is governed: you know who may see what. Most companies have the data. Few have it in this state.

The test is simple. Take a question your team answers every week, such as which open quotes are older than 30 days, and trace where the answer comes from. If it takes three tools and a person who knows the exceptions, the AI will need the same three tools and the same exceptions written down.

Where projects stall

The usual blockers are not exotic.

  • Duplicates. The same customer under three spellings across CRM, invoicing and support, so any answer about them is a third of the truth.
  • Gaps. Fields that were optional and stayed empty, such as industry, deal stage or contract end date, which are exactly the fields the questions depend on.
  • Silos. Knowledge in email threads, PDFs and personal folders that no system indexes.
  • Stale copies. Exports made for one report, never deleted, and later trusted as current.
  • Undefined terms. An active customer meaning one thing in sales and another in finance.

None of these are technical problems, which is why buying a better model does not solve them. Gartner estimated in 2021 that poor data quality costs organisations an average of USD 12.9 million a year, and that figure predates AI reading the data at scale.

The four steps we run first

This is the connect and clean phase of our approach, and it comes before any model is chosen.

Inventory. We list every system that holds data the process touches: CRM, ERP, analytics, documents, email, support. For each one we record who owns it, how it is accessed, how often it changes and whether it contains personal data. The inventory usually surprises people. It is the first time the full picture is on one page.

Connect. We integrate the tools you already use rather than replacing them. Data stays in its system of record and is read through APIs or scheduled syncs, so there is one source of truth and no manual exports.

Clean. Duplicates are merged, key fields are filled or flagged, and terms are defined once and written down. We do this for the fields the pilot needs, not the whole database. A perfect warehouse is not the goal. A reliable answer is.

Govern. Access is set per role before the AI sees anything: what it may read, what it may write, what is pseudonymised on the way in. This is also where retention and deletion rules are decided, which GDPR requires and auditors ask for.

What that looks like in practice

  • A pilot scoped to one process and the five to ten fields it needs.
  • A written definition of each of those fields, agreed by the people who use them.
  • A sync schedule you can state in one sentence: CRM every 15 minutes, invoices nightly.
  • A named owner per source, who signs off when the data is ready.
  • A baseline measured before launch, so the result can be compared against something.

What you can skip

You do not need a data warehouse, a data science team or a year-long migration to start. You need the fields for one process to be reliable, and a way to keep them that way. Everything else can be added once the first result is measured.

The bottom line

The model is rarely the problem. The data it is given is, and that is fixable in weeks rather than years when the work is scoped to a process instead of the whole company. Prepare the data for the first pilot properly and every pilot after it starts from a foundation instead of a cleanup.

If you want to know how far your own data is from ready, the readiness assessment starts with exactly this inventory.

HolyShift

We connect your data. We build AI into your processes. We train your team.

Follow us