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
The supervisory evidence is blunt. In workshops the European Central Bank ran with 13 supervised banks across nine countries in 2025, it found that only a few were effectively applying data management standards in practice or adapting them to what AI models need, and noted that poor inputs will inevitably produce unreliable results. The ECB's supervisory priorities for 2026 to 2028 describe persistent deficiencies in risk data aggregation frameworks with no improvement on the year before. That is the sector with the most money and the most scrutiny.
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 rather than at the model.
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. 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.
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.
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. Under DORA, an exit plan for a critical ICT service must be comprehensive, documented and sufficiently tested. An untested rollback is not a rollback. 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.