AI readiness is a data-contract question, not a model question

The pilots that impress in a demo and die in production fail for the same reason four times out of five, and it is not the model. It is an upstream system that changed, a definition that moved, or an access rule that the prototype never had to respect.

What the model cannot fix

• A field that means different things in different source systems, so retrieval returns the wrong context confidently.
• A metric that two departments define differently, so the agent answers a question nobody asked.
• A permission model that exists only in the reporting layer, so the AI layer leaks what the dashboard hid.
• A volume drop at the source that turns a good answer into a stale one with no signal.

None of those are model problems. All four are contract problems, and all four are cheaper to find in the second week than in the second quarter.

The two-week readiness sprint, concretely

We scope one process, not a capability. One workflow, one decision owner, and the current cost of doing it the old way written down as a number: hours per week, cost per document, or error rate. That baseline is the only defence against a business case built on enthusiasm.

• Days 1 to 3: the process mapped with the person who does the work, including the exceptions that never appear in the process documentation.
• Days 4 to 7: the data checked at the grain the workflow needs. Not the grain the warehouse happens to hold.
• Days 8 to 10: a thin slice run on your data, with the accuracy measured on items the slice has not seen, plus cost and latency per unit of work.
• Day 10: a written answer. Build, fix the foundation first, or stop.

Why "stop" has to be an allowed outcome

If every sprint ends in a build, the sprint is a sales process wearing a lab coat. Two of the three outcomes in a readiness sprint save the buyer money, which is exactly why they are credible. We have told a manufacturer to stop on a forecasting use case where the promotion history held two observations per year. There is no model that fixes a data-collection habit.

The trust mechanisms that do the selling

European buyers now ask AI Act and data-residency questions in the first security review, not the last. The answers that move deals forward are architectural, and they have to be true before the call:

• Deployment in your tenancy, in an EU region, with model calls that do not leave it where the use case allows.
• Every answer carrying its source and a stored retrieval trail, so an auditor can reconstruct what was asked and what was returned.
• Human approval gates on anything that writes to a system of record.
• An evaluation set that runs on every change, with the accuracy number and the sample size published internally.
• Risk classification and oversight design as deliverables, so the AI Act answer is a document rather than a promise.

The right first question about an AI use case is not "which model", it is "who owns the process today, and what does it cost them".

If the answer to that is unclear, the sprint will produce a technically excellent answer to the wrong question. Fix the ownership first, then spend the money.