Preparing company data for AI — four things to fix before you connect a model

The first question you ask an AI agent connected to company data rarely fails outright. It fails in a worse way: the answer sounds right, and it is about a customer who left two years ago.

A model cannot see context that is not in the data. It does not know that "pricing_final_v3" was superseded, that the same company sits in the database three times under three names, or that the column "status2" means something different from "status". It gathers what it finds and returns one smooth answer.

That is what AI actually changes about a data mess: the mess stops being visible. Someone who opens a folder and sees three versions of a price list knows to stop and think. Someone who receives a single sentence from a model has nothing to think about.

Below are four things to fix before you connect a model to anything — and a way to do them without a six-month project.

A single source of truth for every entity#

An entity is simply a thing you will ask about: a customer, a job, an employee, a document, an invoice. One rule applies to all of them: each lives in exactly one place.

That sounds obvious until you check. The customer is in the CRM, in a salesperson's spreadsheet, in an email signature and in the invoicing system. Four addresses, two phone numbers, three spellings of the name.

Someone who asks three colleagues and gets three different answers knows something needs sorting out. A model picks one version, usually the first it found, and attaches no caveat.

In practice: for each entity, name the system of record and write that decision somewhere the whole team can see. The other copies either disappear or become read-only.

Names that need no translator#

Every company older than a few years carries a layer of knowledge that is written down nowhere. That "status 7" means "awaiting collection". That jobs prefixed with "W-" are internal and do not count towards revenue. That the field named "notes2" was created the day "notes" ran out of room.

A new hire absorbs this over their first month by asking the person at the next desk. A model has nobody to ask. It reads the name literally and counts the internal jobs along with the rest.

Three things worth correcting:

Field names say what is in them. "Completion date" rather than "date2". Renaming a column is usually one click, and it removes an entire class of silent errors.

Statuses as words, not numbers. If the system stores numeric codes, keep a human-readable label alongside them. A model reading "awaiting collection" does not have to guess what a seven means.

Abbreviations spelled out at least once. One place recording that "GRN" is a goods received note is enough. The model uses it the way a new colleague would.

This is not about rewriting the database — only the layer the model will be given access to.

Marking what is out of date#

The second thing a model cannot infer: what still applies.

A last-modified date settles nothing. A file edited last week may contain terms from two years ago, and a document untouched for a year may be the only one in force. The model has no basis for telling them apart.

Two things cover most cases:

A status field instead of intuition. Current, archived, draft. Three values, one field, on every document and record that has versions.

A validity date where it makes sense. Price lists, contracts, procedures. Once the data records how long something applies, the model stops answering from expired terms.

Deleting the old material is tempting: the simplest way to stop the model seeing it. It is also irreversible and usually runs into retention obligations. Marking works just as well and can be undone.

Removing duplicates#

Duplicates are the most treacherous of the four, because they do not corrupt the wording of an answer. They corrupt the numbers.

Asked how many open jobs a customer has, a model counts the records it finds under the name you used. If that customer sits in the database as "ABC", "ABC Ltd" and "A.B.C.", the answer comes back too low, with nothing in it hinting that anything is missing.

An order that works:

1. Start with the entity you will ask about most. Usually customers or jobs, not everything at once.
2. Sort alphabetically and read down the list. Duplicates end up next to each other, visible faster than it takes to configure a tool to find them.
3. Set a field that cannot repeat. A company registration number for businesses, an email address for people. This is the step that stops you doing the same work again next quarter.

Without the third step, de-duplication is recurring work. With it, it is a one-off.

How to do this in stages#

Fully organising a company's data is a project that never ends. The goal here is narrower: get the part the model will actually see into order.

Week one: one area. Pick a single entity and work through the four points above for that entity only.

Week two: read-only model. Ask it twenty questions you already know the answers to. It is the cheapest data audit there is — a wrong answer almost always points at a specific record or file.

Week three: fix what surfaced. Not everything, only what was genuinely breaking answers.

Then the next area. A month per entity, and only the areas you will actually ask about — work spread across spare hours, rather than a schedule nobody keeps.

Summary#

Four things: a single source of truth per entity, names that need no translator, expiry marked explicitly, no duplicates. None of them needs a developer or a new tool — they need decisions and a few hours per area.

This work pays for itself before the model is even connected, because the same four problems slow people down too. AI simply makes them invisible. How the connection itself works and what to ask a vendor is covered in the guide on connecting AI to company data.