The Board Wants AI This Quarter and Your Data Is a Mess. Pick a Different Problem.

There are two honest responses to a board that wants AI this quarter when the data is in poor shape, and the common one is wrong. The common one is to open a data remediation programme, report progress in percentages, and ask for patience. That programme will run past the quarter, past the year, and quite possibly past the sponsor, and at the end of it you will still not have shipped anything.

The other response is to notice that a large share of useful AI work does not touch your historical data at all, and to start there.

Two categories, and only one of them needs your history

The distinction is sharper than most planning conversations make it. Ask whether the answer depends on how your organisation has behaved in the past.

Summarising a contract, extracting fields from a supplier invoice, classifying an inbound email by topic, drafting a first-pass reply, answering a question from a policy document you supply at the time: none of these need your history. The intelligence required is general. Your data is the input to the request, not the material the system learned from. If the document is legible and reachable, the work is feasible today, whatever state your warehouse is in.

Forecasting demand, scoring leads, predicting churn, flagging anomalous payments, recommending a next action: these are entirely dependent on your history, because the pattern being predicted exists only in your own records. For this category, poor data is not an obstacle to be worked around. It is the thing itself.

Most quarterly AI mandates are satisfiable from the first category. The mistake is that the projects people propose come from the second, because prediction sounds more impressive in a board pack than extraction does.

Requested capability	Depends on your history?	Feasible this quarter with messy data
Summarise long documents	No	Yes
Extract fields from forms and invoices	No	Yes, if the format is reasonably consistent
Answer questions from internal documents	No, retrieval rather than training	Yes, if the documents are current and findable
Classify into your own categories	Slightly, a few dozen labelled examples	Usually
Predict churn or demand	Yes	No
Score or rank leads	Yes	No

Our guide on whether your data is actually ready for AI goes further into what makes a dataset unusable, including the leakage problem that makes a broken model look excellent right up until it reaches production.

What "not ready" usually turns out to mean

When people say the data is not ready, they are typically describing one of four things, and only two of them actually block delivery.

The first is that records are inconsistent because three teams entered the same field three ways. This blocks prediction. It rarely blocks a model reading a document, because the document is being read as text rather than joined on a key.

The second is that there is no warehouse and everything lives in operational systems. This blocks nothing in the short term. A pilot can run against an export, a read replica, or an API. Waiting for a platform before proving value is the most expensive delay available in this field, because it spends the budget before anyone knows whether the thing works.

The third is that the outcome you want to predict was never recorded. This is fatal for the prediction project and no amount of volume substitutes. If nobody ever marked an account as churned, there is no churn model, this quarter or any other.

The fourth is that nobody has decided whether the data may leave the network. This one is not a data quality problem at all and it stops more projects than the rest combined, usually late, after the engineering is done. It is worth settling before you scope anything, since the answer determines the architecture. The practical questions to put to your security and legal people are set out in our guide to what happens when company data goes to AI providers.

A sequence that fits a quarter

1. Write down the actual business complaint behind the mandate. "The board wants AI" is not a requirement. "Our people spend two days a week rekeying supplier documents" is, and it points at a category-one project.
2. Test the dependency question on each candidate. If the answer depends on your history, park it and say why in one sentence. This is not obstruction, it is scoping, and it reads much better in writing than in a meeting.
3. Check reachability rather than quality. Can a system get to the documents or records at all, through an API, an export, or a database read. In older estates this is often the real constraint, and the shape of the workaround is covered in our guide on connecting AI to legacy systems.
4. Settle the data-egress approval before design, not after. Get it in writing from whoever can actually give it.
5. Scope to one decision inside one workflow, with a human still holding the steps around it. Partial accuracy is useful in that shape and useless in a full-process replacement.
6. Build the evaluation set and the human review queue before the model is good. Both are what let you ship at imperfect accuracy rather than waiting for a standard nobody defined.

Run the data work in parallel, narrowly

None of this means the data work is unnecessary. It means it should be scoped by a working system rather than by an audit. Once a document-extraction feature is live, you know precisely which fields matter, how often they are missing, and which upstream process produces the inconsistency. That is a remediation backlog with a business case attached to each item.

The alternative, cleaning everything to a general standard before choosing a use case, produces a lot of tidy data that no shipped system depends on. It also produces a quarter with nothing to show, which is what the board was objecting to in the first place.

What to do next

Take the three AI ideas currently in circulation in your organisation and sort them by the dependency question. If all three sit in the prediction category, you do not have a data problem this quarter, you have a scoping problem, and the fix is to find the document-heavy or classification-heavy work that people are doing by hand right now.

Then check the honest timeline before committing to a date in a board paper, because the gap between a working prototype and a system in production is where most of these commitments break. Our note on how long an AI integration takes end to end is a reasonable calibration, and our AI integration services page describes how we sequence the feasibility and permission questions ahead of the build rather than alongside it.