Data work gets funded for answers, not for platforms

A request for data engineering budget usually reaches the board in the worst possible form: as a platform. A new storage layer, a catalogue, quality tooling, an eighteen-month schedule and a promise that everything will be easier afterwards. The board rightly asks what will change and when, and does not get an answer it could check.

The same spend described differently gets approved far more easily. Not “we need proper data”, but “this system answers wrongly in these cases, for this reason, and this is what it costs us today”.

Why the platform request loses

It has no recipient. A platform serves everybody, so nobody in particular is accountable for whether it paid off. A line without an owner of the outcome is the first to go when the budget tightens.

It has no point of proof. The benefit is promised for after completion, and completion is a long way off. A board that has funded one of these before usually remembers how it ended.

It competes with spend that has a number. Next to it sits a request for a salesperson with a revenue forecast and a machine with a costed payback. A request for “foundations” loses to anybody who can say what the business gets and when.

Where to start instead

With one AI system that is already live or about to be funded, and with the question of what it costs that its answers cannot be trusted. That cost rarely sits in a single ledger line, but it can be assembled from several.

Manual checking. If experts verify every answer because they do not know how fresh the data behind it was, the system is not saving their time, only moving it. Those hours can be counted.

A pilot that never reaches production. The demonstration worked on a chosen set, and real data stopped it. Every month in that state is a team’s cost with no return.

Disputes without an answer. A customer or an auditor asks where an answer came from. Without lineage, the reply is several days of somebody’s work and an uncertain result.

Regulatory requirements. If the system falls into the high-risk category under the EU AI Act, data governance and record-keeping are legal obligations rather than good practice.

Infographic

What an AI system's value rests on

1. 01DecisionWhat somebody does differently because of the system's answer.
2. 02AnswerWhat the system returns and the user sees.
3. 03Data under the answerFresh, complete and traceable to a source, or not.
4. 04Sources and ownersSystems, inboxes and drives, each with somebody accountable.

What the request should contain

One system and one path. Not five sources at once, but one significant source done properly: ingestion, checks and lineage. The pattern then repeats more cheaply, and the request is small enough to stop if it is not working.

Questions you will be able to answer afterwards. How fresh is the data under this answer? Where did it come from? What is missing from it? Who finds out first when a load fails? Today the answer to each is usually “we do not know”. That is a definition of success a board understands without a glossary.

A date that can be checked. Quality checks on an existing pipeline can be in place within days and usually expose a real problem straight away. A properly built path for one significant source is typically a matter of weeks. That first step is the cheapest evidence in the whole request.

The cost of running it. Pipelines do not end at acceptance. Somebody has to run them, and storage and embeddings cost money every month. A request that leaves this out comes back a year later as a surprise.

The trap after the first success

Once the first path works, there will be a temptation to extend it to the whole company straight away. That is the moment the request for an answer quietly turns back into a request for a platform, only with a better justification.

It is better to add a second source for a second system, with the same arithmetic, than to announce a programme. A shared layer will emerge from the repetition if it is genuinely needed. A warehouse is worth building when several consumers need consistent history, not as a prerequisite for the first AI system.

The best argument

The strongest argument for data work is the first published number: a source’s freshness, its completeness, the share of documents that cannot be read reliably. It is usually worse than anybody assumed, and from that moment the budget conversation looks different.

That is how we shape an AI data engineering engagement: one system that has to be trusted, one path taken all the way through, and quality numbers published before anybody asks for the next budget.