Preparing business data for AI agents is the work that decides whether the deployment holds. It means auditing what you actually hold, resolving the quality problems, restructuring information into something an agent can retrieve, and setting the governance rules that keep the outputs defensible a year later. This article is for the teams past the question of whether to use AI and on to the harder one: is our data ready? Europe's banking supervisor has published an answer for its own sector, and it is not flattering.
Why business data is rarely ready out of the box
Most organisations meet the same problem once the project starts. The data exists. It was built for people, for quarterly reports, and for systems bought in 2011. None of that is the same as being built for machine consumption, and closing the gap is deliberate work rather than a parallel workstream.
Three failure modes account for most of it:
- duplicates, where the same customer appears three times and the agent double-counts or contradicts itself
- inconsistent categorical labels, where “UK”, “United Kingdom” and “GB” are three separate entities to a machine and one country to a human
- stale records, where a price that changed six months ago is quoted back with complete confidence
We found stale records and duplicates in the data behind the chat assistant on this site. In September 2026 a review of our Help Center page turned up a client figure we had dropped in July. The same figure sat in the assistant's knowledge base. With the fix came a written rule: a claim stays in the knowledge base only while a page a visitor can open still carries it. A crawl of the live site is the check. Later that month we found two client reviews twice in its corpus, once as the review and once as an old page left over from our WordPress migration.
In 2025 the European Central Bank found that only a few of the banks it examined applied data management standards in practice; our piece on why most AI projects fail sets out what else it found.
Skipping the phase does not save time. It moves the cost into production, where it is far more expensive to find. Most of our data and analytics work starts here.
The four layers of data preparation
Preparation runs in sequence, and each layer has an exit criterion. You do not start the next one until the previous is finished, which is what stops teams cleaning data that should never have been in scope.
- Inventory and audit. Map every source the agent will touch, with an owner, an update frequency and a format for each.
- Cleaning and deduplication. Apply deterministic matching rules before any model sees the data.
- Structuring and enrichment. Convert documents and email into retrievable passages, each tagged with source, date and document type.
- Access and governance. Decide what the agent may read, what it may write, and what it may not touch at all.
What agent-ready data actually looks like
Cleaned data is necessary and not sufficient. An agent needs data that is retrievable, contextualised and bounded, which is roughly the difference between a room full of books and a library with a catalogue and a borrowing policy.
Most enterprise deployments choose retrieval over fine-tuning, because retrieval keeps the data external and updatable without retraining. The on-premise assistant we deployed for a logistics operator has both. It runs keyword and vector search over a Qdrant index of the operator's documents, and its model was fine-tuned with LoRA to the client's domain language. Passage size is empirical rather than a rule: small enough to answer one question, large enough to carry its own context, tuned against your own corpus. A legal team's contracts prepared properly have each clause extracted separately and tagged by contract type and jurisdiction. Prepared badly, an eighty-page agreement goes in as one document and the agent misses the clause that mattered.
Our site assistant made the same mistake with questions on the evening it went live. It matched full-sentence questions whole against short page titles, found nothing and answered without sources. The fix that night split each question into its key words and ranked pages by how many of them matched.
Poorly prepared | Agent-ready | |
|---|---|---|
Format | Whole documents | Passages that answer one question |
Metadata | Filename only | Source, date, document type, owner |
Access control | Whatever the service account can reach | Explicit read, write or neither, per source |
Version control | None | Changelog, so behaviour changes are traceable |
Update mechanism | Manual re-upload | Scheduled, with a record of what changed |
Version control is the part teams skip and then need most. If the underlying data changes, the agent's behaviour changes with it, and without a changelog every debugging session starts from guesswork. Each changelog entry also needs a saved evaluation run. In September 2026 our site assistant's knowledge base changed twice and its retrieval once. Each change was logged and dated, and no saved run came between them. The next run, on 29 September, had one more answer over the length limit than the August run. We could not tell which change, if any, caused it.
When we moved the assistant to a newer model in October, we ran the suite four times on the setting we shipped. It scored 33, 34, 33 and 34 of 35.
Not sure whether the team you are about to hire has done this before?
Our free checklist covers what to ask in an RFP, three warning signs that a vendor may not deliver, and a scoring matrix for comparing proposals on something other than price.
Setting governance rules before go-live
Three rules belong in place before an agent reaches live data.
- Read and write boundaries, documented explicitly rather than inherited from a service account.
- Audit logging of every query and every output, with timestamps.
- A rollback procedure that has been rehearsed, not drafted.
In a regulated firm these are not good practice, they are obligations with article numbers. Article 10 of the EU AI Act requires training, validation and testing data to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete, with governance covering data origin and examination for bias. Article 12 requires automatic event logging across the system's lifetime. Where the agent runs on a third-party ICT service that supports a critical or important function, Article 28(8) of DORA requires an exit plan that is comprehensive, documented and sufficiently tested. The same discipline shows up wherever agents touch regulated banking systems.
A readiness checklist before deployment
Sign this off jointly before the agent touches production data, with a named owner against each line.
- sources inventoried, with owner and update frequency [data engineer]
- duplicates resolved and labels normalised [data engineer]
- documents chunked and tagged [data engineer]
- access permissions defined and tested [platform owner]
- version control and changelog in place [data engineer]
- rollback procedure documented and rehearsed [platform owner]
- audit logging active and readable [compliance]
Data work behind agents we have shipped
Working out whether your data is ready?
WislaCode prepares business data for AI systems inside regulated environments, where the audit trail and the access model matter as much as the retrieval quality.
What types of business data can AI agents work with?
Structured data such as databases and CRM records, semi-structured data such as JSON and logs, and unstructured data such as email, contracts and call transcripts. The unstructured half has to be pre-processed into retrievable passages first. Without that step the agent either misses the relevant passage or produces something that reads well and is wrong.
How long does it take to prepare business data for an AI agent?
There is no universal figure, and any vendor quoting one is guessing. What is consistent is the direction of the error: teams underestimate this phase, and the cost lands in production rather than in the plan. Scope it against your own systems and their owners.
Do I need to clean all my data before deploying an AI agent?
No, and trying to is how projects stall indefinitely. Scope the data the agent will actually use, prepare that subset properly, and expand once it works. Cleaning an entire data estate before deployment is renovating a building to move into one room.
What is the difference between fine-tuning and retrieval for business data?
Fine-tuning puts knowledge into the model's weights, so updating it means retraining. Retrieval keeps the data external and fetches it when the question is asked, so a correction to a source document takes effect immediately. For business data that changes weekly, retrieval is usually the more maintainable choice.
How do I know if my business data is ready for an AI agent?
A useful test: could a competent new analyst, given only the sources the agent will have, answer the questions you expect the agent to handle? If not, because the data is incomplete, inconsistent or unreachable, the agent will hit the same wall. Readiness is a practical threshold, not a technical one.