AI will not fix data you do not trust

An assistant answers from the documents your retrieval step hands it, so the answer is only as good as that set. If two systems hold different versions of the same customer, product or price, the assistant picks one, blends both, or quotes them with equal confidence — and the failure arrives as a fluent paragraph rather than an error. The answer flips in one case only: when a question needs judgement over records that are clean and have a single owner, an assistant earns its place. When the record itself is in dispute, no model settles it.

What does the assistant actually read?

The model does not know your business. It receives a set of rows, passages or documents that a search step selected because they matched the question, and it writes an answer out of that set. Everything the answer can be right or wrong about is inside it.

That moves the work upstream. Which sources are indexed, how each record is identified, how duplicates are merged and who may retrieve what are decided before the model is called. A better model does not repair a wrong selection; it makes one read better.

Why does one record per thing come first?

A customer with two identifiers is two customers to a retriever. One row says SARL Benali, another says Benali SARL, a third carries only a phone number, and a fourth is the same shop under the name it traded under two years ago. Ask for the total owed and you get one of them, or a sum of three.

The fix is organisational before it is technical: one system owns the customer record, every other system points at it by a stable key, and merging duplicates is a routine with a named owner. Naming an authoritative source is worth nothing while both sources still accept edits.

What do names and units have to do with it?

Column names are the model's only guide to meaning: qty, Quantite, الكمية, qty_pcs and units_sold are five unrelated fields to a search step, whatever they mean to the person who built the spreadsheet. A model reads labels; it does not audit intent.

Units cause the same error with more damage: stock in kilograms here and tonnes there, prices in dinars in the sales system and in thousands of dinars in the owner's summary. Nothing throws an error; each produces a number that looks reasonable and is wrong by a factor.

Two artefacts prevent most of it: one name and one unit per concept, written down, and a one-line description beside each table. The W3C's data on the web guidance treats such metadata as part of publishing data, not an extra.

What do duplicates do to a count?

They double it. Asked how many active customers you have, an assistant counts rows, not people: the same pharmacy entered by two sales representatives, the same supplier under a legal and a trade name, the same product with and without its size.

De-duplication belongs in the index, not the prompt. Merge on a business key — a phone number, a registration number, an internal code — and keep the merge reversible.

Who is allowed to see what the assistant retrieves?

Permissions belong to the retrieval layer. If the index covers every document and the only safeguard is a sentence asking the model to hide salaries, that sentence is a request, not a control: a prompt instructs a text generator; it does not grant access.

The workable shape is the one your source systems already use. Identify the person asking, decide what that identity may open, and filter the search before it runs. A warehouse manager asking about stock should not retrieve a supplier contract that the same search would legitimately surface for the finance director. The NIST AI Risk Management Framework treats defined roles and continuous monitoring as part of governing a system, which is where a permission rule belongs. In practice the check sits inside the query, and the answer is built from what came back.

How do you test it before you deploy it?

Write the questions down, with answers, before the assistant exists: thirty to fifty that staff actually ask, with the answer recorded by whoever knows it. Include questions the corpus cannot answer, because a correct "I do not have that" is a result and an invented figure is a failure.

Then a human marks every answer:

Problem	What the answer looks like	What has to change
Two systems, one entity	Confident, split totals	One owner, one key
Opaque column names	Plausible wrong figure	Name and unit dictionary
Permissions left open	Right answer, wrong reader	Filter at retrieval

Re-run it after any change to a source system, and put the next run in a calendar: a test set run once measures a demonstration.

What is the order of work?

1. List the questions the assistant will answer, and who asks each one.
2. Name the system that owns each answer.
3. Fix the conflicts those questions expose: duplicates, names, units, empty required fields.
4. Write the permission rules per role and enforce them in the query.
5. Build the question set with the people who use the data, not only its pipeline's builder.
6. Mark the answers by hand and count how many are wrong, refused or unsafe.
7. Set the scope from that count, and the date of the next run.

Steps one to four take longer than connecting a model, and decide whether the assistant is worth having.

Where this goes wrong

The clean demonstration. A pilot over the three best-maintained tables shows that the model can work. It says nothing about the tables that hold the disputes.

The answer that looks successful. Ask for last month's revenue and receive the accounting export plus a sales tracker that already includes it. The paragraph is well written, the figure is roughly double, and nobody questions it until it reaches a report to the bank.

Permissions handled in the prompt. Someone writes a careful instruction about confidentiality; the first employee who phrases a question differently receives a salary table, and the incident surfaces months later.

The cleaning project with no end. "We will fix the data first" is how these stall: with no definition of fixed, the assistant is never deployed and the data is never finished.

Silent change. A column is renamed, a unit changes in an export, an upstream system sends an empty field. Nothing fails loudly; the answers drift.

What this does not cover

Nothing here concerns choosing a model, writing prompts or estimating cost per query; those matter, and they come second. It does not cover the legal basis for processing personal data, retention periods or sector rules, which are questions for a lawyer in your jurisdiction. Nor does it cover two branches that genuinely keep separate records: merging them is a business decision, and it comes before the assistant does.

We build the record, the naming and the permission layer first, then put the assistant on data whose answers can be checked.