Clean Data First: Five Unglamorous Tasks That Decide Whether Your AI Pilot Works

The demonstration is not the problem

Every AI pilot that disappoints a UK SME tends to disappoint for the same reason, and it is rarely the model. The assistant was fluent. The summaries were tidy. Then somebody asked it a question about a customer and received three different answers, because the CRM holds three versions of that customer under slightly different names. Or it surfaced a contract summary to a member of staff who should never have had sight of the folder the contract lived in.

The conclusion drawn in the post-mortem is usually that the technology is not ready. The more uncomfortable conclusion is that the business was not ready, and that the pilot exposed something that had been quietly wrong for years. That is an opportunity, provided it is treated as a data governance problem rather than a procurement failure.

The five tasks below are dull. None of them will impress anyone in a board pack photograph. All of them determine whether an AI pilot produces a result or produces a cautionary tale.

Task one: one customer, one record

Duplicate records are the most common reason an AI assistant contradicts itself. If the same client appears four times across the CRM, the accounts system and a spreadsheet maintained by the sales team, no amount of prompt engineering will produce a reliable answer.

Owner: operations director, working with the CRM administrator. Success measure: a defined matching rule (company number, postcode and registered name, for example), a merged set of active accounts, and a monthly exception report showing new duplicates as they arise. A reasonable target before go-live is above 95 per cent of active customers resolved to a single record.

Task two: name an owner for every dataset

Data without an owner has no quality standard, no retention rule and nobody to answer when the AI produces something strange. Ownership is a human appointment, not a technical setting. Customers belong to sales or operations, suppliers to procurement, financial records to finance, employee data to HR.

Owner: each member of the leadership team, for their own domain. Success measure: a single-page data register listing each dataset, its system of record, its business owner, its classification and its permitted uses — reviewed and signed off annually. Where two systems both claim to be the source of truth, the register must say which one wins.

Task three: tighten permissions before you widen them

AI tools amplify whatever access already exists. If a shared drive has been left open to all staff because nobody wanted to have an awkward conversation, connecting an assistant to that drive turns an administrative untidiness into a data protection incident. The instinct at pilot stage is to grant broad access so the tool works; the correct move is the opposite.

Owner: IT lead, with each line manager confirming who on their team needs what. Success measure: every file share and Microsoft 365 group has a named business owner, the number of broad grants such as everyone or all staff is counted and reduced to a documented minimum, and a quarterly access review is completed with evidence retained.

Task four: fix retention with dates rather than intentions

Storage limitation is a legal obligation, not a preference, and an AI assistant trained or grounded on a decade of accumulated documents will reproduce whatever is in them — including records that should long since have gone. UK GDPR requires personal data to be kept no longer than necessary, the Companies Act 2006 requires accounting records for six years from the end of the relevant financial year, and HMRC expects supporting records for a similar period.

Owner: finance director or company secretary. Success measure: a retention schedule with a defined period and disposition action for each dataset, automated deletion or review where the platform allows it, and a disposal log that can be produced on request.

Task five: bring shadow AI into the light

Staff are already pasting documents into public chatbots, and no policy announced quietly in a newsletter will stop it if the official tools are slower and worse. The practical approach is to establish an approved list, a short acceptable use statement, and a route to request something new that gets answered within a fortnight.

Owner: chief operating officer, supported by whoever holds the information security brief. Success measure: a register of AI tools in use and who uses them, an approved-tools list published internally, and evidence that at least one request has been through the approval route. A policy nobody can act on is not a control.

Sequencing the ninety days

These tasks do not need a programme office. A sensible shape is three parallel workstreams over a quarter: duplicate resolution in the first month, so the pilot has something clean to reason over; ownership and retention in the second; permissions and shadow AI running throughout, because neither is a one-off exercise.

The pilot itself should be deliberately narrow — one process, one team, one measurable outcome — and should not begin until tasks one and three are at least substantially complete. Starting with a clean record set and a defended permission model is the difference between a demonstration and a deployment.

How you will know it worked

Judge the groundwork by leading indicators rather than by the pilot's demo. Duplicate rates falling. Named owners appearing against every dataset. Broad-access grants reducing quarter on quarter. A retention schedule with dates in it. A register of AI tools that a director can actually read.

Those are the assets that outlast whichever assistant was fashionable in the autumn. The pilot will be judged on its results, but the results are downstream of the plumbing — and the plumbing is a governance job, not a technology purchase.