Data strategy for AI: what to fix before you build

A data strategy for AI does not need to be a two-year data programme. It needs to answer one question well: can this data support this use case, safely? Answer it for the first use case, fix what that turns up, and the second use case inherits most of the work. Trying to make the whole estate AI-ready before anything is built is, in my view, how data programmes stall with nothing in production to show for them.

The UK government's AI Playbook puts the dependency plainly. AI systems rely heavily on the quality and quantity of their data, and poor quality, biased or noisy data can lead to inaccurate outcomes if it is not managed. The Playbook also warns that AI can make existing risks worse, and names poor data management and insufficient security classification among them.

One of our published engagements shows where the time really goes. Connecting a client's AI workspace to its finance data took a single afternoon. Agreeing the definitions that make an answer correct took a week with the finance director, and that week was the real work. Had we stopped after the afternoon, the client would have had a tool that looked finished and quietly disagreed with finance.

The six areas below are what to check, and the checklist at the end puts them on one page you can take into a meeting.

Access comes first because it is the check that turns into an incident when it fails. The AI Playbook states the rule in one line: make sure your AI model only has access to the data the user of the model should be able to access.

The usual way to break it is a single service account that can read everything, with the AI trusted to work out what each person should see. A model is not an access control. The safer pattern carries each person's own permissions through to the data, so the AI cannot return anything the person could not have opened themselves. In the finance engagement, the connector carried each person's existing Looker entitlements, and nobody gained access they did not already have.

Respecting permissions exposes a second problem, which is oversharing. A file shared with the whole company years ago was hard to find by browsing. An assistant that searches everything a person can open will find it on the first day. Review sharing on the document stores in scope before you connect anything, rather than after the first surprised email.

Access also has to change when people do. Our engagement file on identity provisioning for more than 1,000 users shows the pattern: access follows the HR record, so a leaver loses it because a record changed rather than because somebody noticed. Test it with two people who have different access asking the same question. Each should get an answer built only from what they are allowed to see.

The UK government's Data Quality Framework treats data quality as fitness for purpose: is this data set good enough for what I want to use it for? It is the right question for AI, because the bar moves with the job: a drafting assistant can live with gaps that would be unacceptable in a system that approves payments. The framework's six dimensions make a practical review when you take them one use case at a time.

Fix problems at source where you can. The framework asks organisations to solve data quality issues at source rather than apply temporary fixes. A clean-up script placed in front of the AI is exactly that kind of temporary fix, and the next use case will have to write its own.

Every source the AI reads needs an owner who can say who may see it, what it means and when it is wrong. Without one, nobody can sign off the access rules above, and nobody can settle an argument about whether an AI answer is right.

Definitions are where ownership earns its keep. A business with three working definitions of revenue will get three kinds of answer from an AI, depending on which table it happened to read. Agree each definition once, write it down where the AI can use it, and name the person who is allowed to change it. In the finance engagement that person was the finance director, and the AI's answers were checked against his until the two agreed.

The same goes for documents. A policy with no owner and no review date is a policy nobody will notice is out of date until the AI quotes it to a customer.

AI use cases usually read one of two kinds of data, and the preparation differs. Documents, such as policies, contracts, case notes and wiki pages, are usually read through retrieval: the system searches for the passages that match a question and passes them to the model with it. The AI Playbook calls this retrieval augmented generation (RAG), and notes that it preserves access controls when the search covers only data the user is permitted to see. Databases, such as a warehouse, a finance system or a CRM, are usually read by the AI running a query, so the risk moves from finding the right passage to computing the right number.

GOV.UK Chat, described in the AI Playbook, is a useful public example on the documents side. The team chose retrieval over fine-tuning because GOV.UK content changes regularly. Returning whole pages sometimes exceeded the model's token limit, so they worked on chunking, embedding models and re-ranking, and at an answer accuracy of 80% they concluded that accuracy had to improve before the product went to users. Most of the fixes they list are about how the content was split, indexed and ranked, which is where I would expect most of the effort on a document project to go.

On the database side, reconciliation is the same idea as our pattern for checking an AI system's output before it acts: the model proposes a figure or an action, and a deterministic check against the system of record decides whether it stands.

If the use case reads documents, run these checks on the collection before it is indexed. They are cheaper before indexing than after, because every fix afterwards means indexing again.

If the data identifies people, data protection law applies to the AI system as it does to any other processing. The ICO's guidance on AI and data protection is the place to start, and the ICO says that guidance is under review because of changes made by the Data (Use and Access) Act. This section describes the guidance as published on 29 September 2026. It is not legal advice.

Fill this in for one use case with the business owner and the data owners in the room. Every line you cannot complete is either a fix to make before the build or a reason to pick a different first use case.

The last line is the point of the exercise. A written fix-first list with names and dates beats a build that starts on data nobody has checked. For a broader read that also covers ownership, value and controls, the AI readiness assessment linked below takes a few minutes.

When the checklist shows the gaps are in the data layer, that is what our Data platform & AI enablement work covers: connecting AI to the warehouse under the permissions people already have, agreeing definitions once in a semantic layer, and adding data contracts and reconciliation so an AI answer lands on the same figures as the board pack. The finance engagement above is one example of it.

Where the use case is still open, a fixed-scope AI strategy sprint with a data and systems feasibility check ranks the candidates against your real data, usually over two to four weeks. Either can run as a statement of work, small or large, and start within a day of the scope being signed. A data job you have already scoped can be resourced on contract from the collective of associates who work with 1AYM, held to the same standard. Book a call below or email tayyeb@1aym.com.