Short answer
Model selection is close to a solved problem. Data condition is not. In most projects the majority of effort goes into making records consistent, complete and connected, and a project that skips this produces a tool that is confidently wrong.
The pattern we see most
A business has years of useful information. It is in a spreadsheet, an accounting package, a folder of scanned PDFs, and a WhatsApp history. Individually each source is fine. Together they disagree.
The same customer appears as SARL Belkaid, Belkaid & Associés and belkaid sarl. Dates are written three ways. Prices sometimes include tax and sometimes do not, with nothing recording which. A person navigates this without noticing, because a person carries the missing context in their head. A model does not.
What we check before quoting
| Check | Why it matters |
|---|---|
| Is there a stable identifier? | Without one, records cannot be joined across systems. |
| Are the same things written the same way? | Variants become separate entities and split your history. |
| Are units and currencies explicit? | Implicit conventions produce plausible, wrong arithmetic. |
| How complete are the required fields? | Gaps get filled by guesswork unless the system is built to refuse. |
| Is there a record of change? | Without history you cannot audit what the system did or why. |
Why this is worse with documents
Text carries structure that is obvious to a reader and invisible to software. A scanned act has headings, parties, clauses and amounts, but the file is a picture. Getting from that to something queryable means recognition, layout parsing, and a schema decision about what you are extracting.
Bilingual documents multiply the problem, one act may run in Arabic with French names and Latin-script numerals in the same paragraph. We cover the specifics in French, Arabic and one document.
What to do before you hire anyone
- Pick one source of truth per fact. Decide where a price lives. Everything else copies from it.
- Give every entity a stable ID. Even a sequential number is enough. Never reuse one.
- Write units and currencies down. Explicit beats conventional, always.
- Export a real sample. Two hundred genuine records tell more than any description of the system.
Doing these four things costs you nothing and reduces the price of any AI project you commission afterwards, from us or anyone else.
The uncomfortable part
Sometimes the honest recommendation after looking at the data is not an AI project at all. It is fixing how records are captured, so that in six months there is something worth building on. That is a less exciting proposal, and it is frequently the right one.
Frequently asked questions
Why do AI projects fail on data rather than models?
Modern models are broadly capable out of the box, so model choice rarely decides the outcome. Inconsistent identifiers, implicit units, and records spread across disconnected systems are what stop a tool from producing reliable answers.
How much data do we need for an AI project?
Less than people expect, if it is consistent. A few hundred well-structured records often beat tens of thousands of inconsistent ones. Quality and consistency matter more than volume.
What can we do to prepare our data?
Pick one source of truth per fact, give every entity a stable identifier, record units and currencies explicitly, and export a genuine sample of a couple of hundred records. These four steps lower the cost of any AI build.