Your data is the hard part, not the model

Ask a team why their AI programme is behind schedule and you will rarely hear an answer about models. You will hear about a field that means three different things in three systems, a warehouse nobody has owned since a reorganisation two years ago, and a permissions model that cannot say who is allowed to see what.

That is the actual work. Roughly seventy percent of the effort behind a programme that reaches production goes into the data rather than the model, and the split is not a sign that something has gone wrong. It is the shape of the job.

Readiness is specific, not general

"Is our data ready?" is not a question that can be answered. Ready for what? A forecasting model needs history, consistency, and a clean definition of the thing being forecast. A support assistant needs current documents, a reliable notion of which version is authoritative, and a way to keep answers inside what the company actually says.

Teams that make progress stop auditing the estate in the abstract and start working backwards from one decision they want to change. The scope collapses immediately. Instead of a two-year cleanup you get a list of six tables, two owners, and a definition that has to be settled.

Ownership beats architecture

The most common failure is not technical. It is that no one is accountable for a dataset once the project that created it ends. Pipelines quietly rot, a source system changes a field, and the model that depended on it degrades without anyone noticing until a business user complains.

Naming an owner for each dataset that feeds a production model sounds bureaucratic and is the single highest-return thing most organisations can do. It converts data quality from an occasional project into somebody's standing job.

Build the boring layer first

Lineage, access control, evaluation sets, and a place to log what the model actually did in production are not glamorous, and they are what separates a programme that can add its second use case cheaply from one that pays full price every time.

The first use case is always expensive. The question worth asking during it is how much of what you are building will still be useful for the fifth.