Most AI Projects Are Data Projects First

The model gets the attention because it produces the visible behavior. The data decides whether that behavior has anything useful to stand on.

This is why many AI projects turn into data projects immediately after the prototype. The demonstration uses a clean document, a hand-selected export, or context assembled by the person presenting it. Production has to find the right information for every case, respect access, understand what fields mean, notice when the source changed, and preserve enough outcome data to evaluate the result.

That is data-system work.

Access is not availability

An organization may own the information and still be unable to use it.

The source has no supported API. The export omits the field the workflow needs. The document repository exposes broad user access but not the narrower permissions the AI system should inherit. The semantic model contains the trusted calculation, but only the rendered dashboard is easy to reach.

Before selecting a model, map the path:

Where does the authoritative input live?
Who owns it?
How is access granted and revoked?
How quickly does it change?
How is deletion represented?
Which transformations make it usable?
What evidence must travel with the output?

If that path cannot be drawn, the AI architecture is premature.

Meaning is infrastructure

Data quality is often described as missing or invalid values. The harder problem is disagreement.

“Customer” may mean an account in finance, a user in the product, and a household in operations. “Revenue” may be booked, recognized, projected, or adjusted. “Active” may depend on a date, a status, or a sequence of events. The dashboard works because someone encoded one interpretation. An AI system that combines several sources may encounter all of them.

A semantic layer is not glamorous, but it prevents a capable model from fluently comparing incompatible facts.

The minimum useful contract should identify:

| Contract element | What it prevents | | --- | --- | | Definition | Different meanings sharing one label | | Owner | No one responsible for change | | Grain | Mixing rows that represent different things | | Timing | Comparing current and stale state | | Allowed use | Applying data beyond its intended boundary | | Validation | Silent malformed or incomplete input | | Lineage | An output no one can explain |

Retrieval is a data product

Teams often treat retrieval-augmented generation as a model technique. In operation, it is an ingestion and information-retrieval product.

Documents must be collected, parsed, normalized, divided, labeled, indexed, updated, and removed. Permissions must be enforced before context reaches the model. Questions must be tested against expected sources. Retrieval failures must be distinguishable from answer failures.

If the right passage was never retrieved, prompt tuning will not fix the answer. If a document was revoked but remains in the index, a better model makes the exposure more articulate.

The quality loop should ask:

Was the authoritative material present in the corpus?
Was it current?
Was the user allowed to access it?
Did retrieval surface it?
Did the model use it correctly?
Did the interface expose the evidence?

Those are mostly questions about the system around the model.

Feedback has to be designed

AI teams often discover too late that they cannot tell whether the system helped.

A thumbs-up is weak evidence. The user may like the writing while the underlying task remains incomplete. The reviewer may fix the answer outside the application. The final business outcome may occur days later in another system.

Design the feedback path at the same time as the feature:

Record the input and relevant context version.
Preserve the model, prompt, tool, and retrieval versions.
Capture the proposed output and human correction.
Observe the downstream action where possible.
Distinguish quality failure from missing data, tool failure, or policy refusal.
Turn real failures into durable evaluation cases.

Without this record, improvement becomes anecdotal. The team changes prompts based on the most recent complaint and cannot know what regressed.

Do not build the lake before the use

“AI requires better data” can become an excuse for a multi-year platform program. That is the other failure.

Start from a named decision or workflow and work backward. The first useful system may need one governed table, a narrow document collection, and a record of operator correction. Build that path well. Add broader foundations when several working use cases prove they share the same need.

This keeps data work connected to an outcome and creates a real consumer for every contract.

Reporting systems are a useful map

Existing reports often contain more institutional knowledge than an AI discovery workshop.

They reveal which sources are trusted, how entities are grouped, which measures are reviewed together, what timing matters, where manual commentary is added, and who challenges the result. They also reveal duplication and disagreement.

For organizations with mature business intelligence, the right move is often not to bypass reporting. It is to use governed models and review patterns as part of the AI foundation.

An AI-assisted reporting system might combine:

deterministic calculations from the semantic model,
exceptions from explicit thresholds or statistical methods,
model-generated explanation constrained to governed facts,
source-linked narrative context,
and a workflow that captures decisions and follow-up.

The model adds interpretation. The data system preserves meaning.

A readiness checklist

Before building the feature, answer:

Can we identify the authoritative input for each material claim or action?
Are definitions stable enough to encode?
Can access be enforced at the moment data is retrieved?
Will updates and deletions reach the AI system predictably?
Can we construct representative historical cases?
Can we observe human correction or downstream outcome?
Is there an owner for each source and contract?

A “no” does not mean the project should stop. It identifies the work the project actually contains.

The model is still important

None of this minimizes model capability. Better models make more workflows possible and reduce the amount of brittle application logic required. But stronger reasoning does not repair an unknown definition, retrieve a document it cannot access, or observe an outcome no system records.

The organization that treats data work as part of the product can take advantage of each model improvement. The organization that treats data as a prompt attachment rebuilds the same prototype repeatedly.

Most AI projects are data projects first because intelligence needs a reliable relationship to the organization’s reality.

Build that relationship narrowly, explicitly, and in service of a real job.

Permissions are part of the answer

Teams often discuss data access as if it were a connection problem: can the application reach the database, document store, or API? The more important question is whether it can determine what this user, in this workflow, is allowed to see and do.

A knowledge assistant that retrieves a restricted document and hides the citation has already failed. A reporting agent that can read every business unit because the service account has broad access is not permission-aware. A model that receives sensitive columns and promises not to mention them is not enforcing a boundary.

Authorization needs to happen before context reaches the model. The system should carry identity into retrieval, filter at the appropriate row or document level, scope every tool, and preserve an audit record that a responsible operator can understand. Deletion and retention need the same treatment. Removing a source from the visible application is not enough if copies remain in an index, cache, evaluation dataset, or trace.

This is data work because permissions, ownership, lineage, and retention travel with the information. They cannot be repaired by a better prompt.

Build the smallest useful semantic contract

“Clean the data” is too broad to guide a project. A better instruction is to define the contract the intended system needs.

Suppose an operations team wants an AI-assisted weekly review. The system does not need a perfect enterprise ontology. It may need a dependable definition of location, reporting period, revenue, labor cost, exception owner, and prior action. Each field needs a source, timing expectation, validation rule, and owner. The narrative can then be grounded in numbers the review team already recognizes.

That small contract creates leverage beyond the first feature. It gives the application stable inputs, gives evaluations expected values, gives operators a place to challenge meaning, and gives future integrations a clear interface. It is narrow enough to build and important enough to maintain.

A useful contract answers:

What does this field mean in the decision we are supporting?
Which source is authoritative, and at what time?
What values are invalid or suspicious?
Who can see it?
Who resolves disagreements?
How will a correction be recorded?
What outcome tells us the information was useful?

Treat corrections as product data

When a reviewer changes an extracted field, rejects a recommendation, or supplies missing context, the correction is not merely interface state. It is one of the most valuable datasets the system can produce.

Capture the original input, proposed output, evidence shown, correction, reason, reviewer role, and eventual outcome where appropriate. Keep that record within privacy and retention boundaries. It can become an evaluation case, expose a broken definition, reveal a missing source, or show that the workflow itself needs to change.

The feedback interface matters. A generic thumbs-down tells the team that something felt wrong but rarely explains what to fix. A lightweight correction tied to the actual work is far more useful. The goal is not to collect every possible annotation. It is to preserve the decisions people already make while reviewing the system.

This closes the loop between data foundation and product operation. The system begins with imperfect organizational data, helps people do work, records where its understanding failed, and turns those failures into clearer contracts and better tests. That is how an AI project becomes a maintained capability instead of a one-time model integration.