Why AI projects stall at the data layer, not the model

The demo goes well. A manager asks for active customers by region, the assistant produces a table, and everyone sees the potential. Then finance says an active customer is one with a posted invoice in the last 90 days. Sales includes any customer with an open opportunity. Service counts customers with an active support agreement. The model did not fail. It answered a question the company had never defined.

This is where many AI projects slow down. The team keeps changing prompts or testing another model, but the disagreement sits underneath both. Production AI needs a stable account of the business. Without it, a more fluent model produces a more convincing version of the same uncertainty.

A convincing demo can hide unresolved work

A proof of concept usually has a narrow dataset, a helpful project team and a handful of rehearsed questions. Production has missing records, late updates, duplicate customers, cancelled documents and users who ask the same question in different ways. It also has consequences. A wrong answer may change a stock order, a collection call or a board report.

The move to production changes the standard. It is no longer enough for an answer to sound reasonable. The team must know which records were used, which business rule shaped the result, how current the source was and whether the user was allowed to see it.

That standard is achievable. It starts by treating data readiness as a product decision, not a cleanup exercise pushed to the end.

Create a definition register people will actually use

A definition register is a short record of the measures and business terms the application may use. It does not need to become a hundred-page governance manual. For each important term, capture the plain-language meaning, source, calculation, exclusions, owner and reconciliation report.

Consider net sales. The name alone does not tell you whether to include tax, unposted documents, cancelled invoices, returns or credit notes. It also does not say which date controls the reporting period. Those choices must match the reports managers already trust.

The owner matters. A technical team can show why two calculations differ, but it should not invent the commercial definition. The responsible business leader decides, and the application records that decision.

Four tests that expose the real gap

The semantic layer turns records into business language

Operational databases describe how software stores data. Managers ask about customers, margin, overdue balances and delivery performance. A semantic layer connects those two worlds through tested views and calculations.

This is where NexLink defines approved measures once, then lets dashboards and AI questions use the same definition. If the sales dashboard and the assistant calculate revenue separately, they will eventually disagree. Shared views prevent that drift and make testing practical.

The layer should stay small at first. Build the views required for the first decisions, reconcile them, and expand only when a real use case needs more. Copying every available field creates a larger security and quality problem without creating more value.

Use a release gate, not a feeling

A production decision needs explicit pass conditions. Start with a set of questions collected from the people who will use the system. For each question, record the expected source, required filters, acceptable answer and evidence that should accompany it.

Run those questions whenever a data view, prompt, model or application rule changes. Some tests can compare exact numbers. Others need a reviewer to judge whether the explanation matches the evidence and avoids unsupported claims.

A useful release gate also covers failure. The application should say when the latest synchronisation failed, when a requested measure is unavailable and when the user's permissions block part of the answer. A clear refusal is safer than a polished answer built from incomplete data.

A practical data-readiness assessment

The first assessment can be completed around one high-value decision. There is no need to catalogue the entire company before proving the method.

1. Choose one decision that currently takes too long or depends on manual spreadsheet work.
2. Collect the reports, exports and source screens people use today.
3. Write the key definitions and record any disagreement.
4. Confirm the authorised data route and the smallest dataset required.
5. Reconcile a first business view against the trusted report.
6. Test real questions against that view and record the evidence behind each answer.
7. Decide whether the result is ready, limited to a pilot, or blocked by a named data issue.

This produces a useful outcome even when the answer is "not yet". The company leaves with a named gap and an owner, rather than another open-ended AI experiment.

Questions to ask before choosing another model

• Which business decision will this application improve?
• Who owns each important definition?
• Which existing report will prove the new calculation?
• How current must the data be?
• Can users inspect the source, filter and timestamp behind an answer?
• What will the application do when a measure is disputed or unavailable?
• Which known questions must pass before a release reaches users?

This draft uses generic examples and synthetic scenarios. It does not contain client data or describe a client's internal systems.