Data foundations first
What AI can do for a process is capped by the records that process already keeps, and the cap is set before the project starts. The work is unglamorous: deciding how finely data is broken down, putting a name against each source, dating what has been checked. It cannot run alongside the AI build, because the AI build will absorb the blame for the data work's timeline.
"Garbage in, garbage out" is true and useless. The sharper version: you can predict which AI use cases will fail from the state of three or four tables, before anyone writes code. And the failure is rarely that the output is obviously wrong. It is that the output is plausible and nobody can check it.
Decision rights
Somebody says "the data is good enough to start", and that call belongs to the process owner, not to whoever is building the AI. The owner knows which numbers get argued about at month-end. The builder does not, and finds out in week six.
Make it a go/no-go before the AI work is scoped, not a condition. "Build it while we sort the data out" turns a data problem into a delivery problem with a deadline, and the deadline always wins. When the honest answer is that the data will not carry the use case, the output is a different use case, not a longer plan. That reframing is the most valuable thing this layer produces and the thing most often skipped.
Memory and context
Three properties decide whether a record set can carry AI work.
Grain: how finely the data is broken down, and whether two sources break it down the same way. Actuals by cost centre and plan by department cannot be compared by any model, because the comparison does not exist in the data. AI cannot join what the organisation never joined.
Ownership: a name against each source. Without one, a question about a number becomes a project, and questions about numbers are most of what AI output generates in its first months.
Freshness: when this was last true. A table with no last-updated field is a table you cannot reason about, and a surprising number of them run companies.
Execution
Do not start a data programme. Take one use case, walk backwards to the three or four records it actually reads, and fix those. A slice ships. Master data management is how this gets deferred for two years and then cancelled.
The shape differs by size. For an established company it is a quarter of unglamorous work on a handful of sources, usually including the one system nobody wants to touch. For something being built from scratch it is a naming convention and one spreadsheet, done in a week, and doing it then is the cheapest it will ever be.
Governance
Before AI touches a source, three things are true of it: a named owner, a definition that owner will defend in a meeting, and a stated refresh cadence. Those are checkable. A source failing any of them is not ready, however clean the values look.
One rule above the rest: the AI does not get to fix the data it reads. A system that cleans its own inputs has no independent check left. Its errors stop looking like errors, become self-consistent, propagate into whatever reads them next, and are very hard to find afterwards. Cleaning is a separate job with separate review.
Observability
The measure is how much AI output the process owner can trace back to a source record without asking anyone. High: review is fast and objections are specific. Low: review turns into archaeology and people quietly stop doing it.
The first failure you see is not an error. It is a disagreement about a number that turns out to be two definitions, not one mistake. That is a grain problem announcing itself and it is the cheapest signal you will get. Measure the data work separately from the AI work, or the AI project reports the data project's timeline and the next proposal starts from a false number.