← The reading table Keeping business data safe with AI tools
The data problems we get called about start at setup: a permission nobody reviewed, a vendor policy nobody read, an integration nobody switched off. Here is what to establish before a tool touches a customer record.
Keep the data safe by deciding what the tool can reach before you connect it, not after. Three things settle most of it: grant the minimum access the tool needs to work, get the vendor's training and retention terms in writing, and know how to get the data back or deleted when you stop paying. Everything else is detail.
The WhatsApp ordering agent we built for a D2C lighting brand in India confirms orders and chases cash-on-delivery confirmations. It reaches real customer records to do that.
What an agent like that is allowed to see is a separate decision from what it is allowed to say, and it is the one that gets made in a hurry. The tool is the easy part to connect. Working out what it may reach is the part that takes an afternoon and saves a year.
Where does your data go when you use an AI tool?
To the vendor's infrastructure, and usually further than the setup screen implies. The path runs from your system to their API, through whatever model they have contracted, into logs held for some period you have not been told, and sometimes into a training set.
OWASP lists this second in its 2025 Top 10 for LLM Applications, as Sensitive Information Disclosure: the model surfacing data it was never meant to expose, to someone who was never meant to see it. Third on the same list is Supply Chain, which is the version of this problem you inherit from a vendor's own dependencies rather than cause yourself.
The practical consequence is that "where does our data go" has two answers, and the second one is about a company you have never heard of.
What is a data map, and why does it matter more than the tool choice?
A data map is a working document that records, for one workflow, what data enters it, every system that data passes through, how long each system keeps it, and who owns it at each step. It is not a compliance artefact and it does not need a template. A page is usually enough.
It matters because a workflow that crosses four tools creates four retention policies, four access lists and four offboarding problems, and nobody holds all of that in their head. The UK's Information Commissioner's Office publishes an AI and data protection risk toolkit that walks the same ground in more formal language, and it is the reference worth reaching for when the workflow touches personal data.
Write the map while you build. Writing it afterwards turns into an archaeology project.
Which permissions should an AI tool actually get?
The minimum set that lets it do the one job you bought it for, and nothing granted "for later". Access requested during setup is access held forever, because nobody schedules a review of a permission screen they clicked through in March.
The test is concrete. A tool that drafts sales emails does not need to read billing records. A chatbot handling lead enquiries does not need the HR folder. An agent that confirms orders does not need write access to the product catalogue. When the tool asks for more than the job requires, the question to put to the vendor is which feature depends on it, and the answer is occasionally that none does.
Role-based access does the same work on the human side. The marketing team does not need the supplier contracts, and the earliest version of any system is the one where everyone can see everything because that was the fastest way to get it running.
What should you ask a vendor before signing?
Four questions, and the answers belong in writing rather than in a sales call.
Are our inputs used to train your models, and can we opt out? How long is our data retained after we delete it from the interface? Which jurisdiction is it stored in? Who inside your company can read it, and under what process?
Some vendors publish all four plainly. Others make them genuinely hard to find, and the time it takes to locate them is information in itself. If the system in question makes decisions about people rather than about orders, the wider question of whether it is safe to adopt at all comes before the procurement question.
What happens to your data when you stop using a tool?
Usually nothing, which is the problem. Cancelling a subscription ends the billing relationship and leaves the data where it is, under a retention policy you agreed to and have not read since.
Offboarding belongs in the same document as onboarding: what gets exported, what gets deleted, who confirms the deletion, and by when. Agree it while the vendor still wants your business. Ask for it after you have cancelled and you are a former customer raising a support ticket.
The same applies to the integrations around the tool. An API key issued to a system nobody uses any more is still a valid API key. Reviewing them quarterly takes an hour and is the least interesting hour in the calendar.
When a system already handles customer data in production, the review stops being a checklist and becomes an audit of what it actually does, including what it discloses when someone asks it the wrong question on purpose. That is a different exercise, and the way we run it is deliberately bounded.
Pick one tool your team connected this year and try to answer the four vendor questions from memory. Whichever one you cannot answer is the one to start with.
MorningLabs AI builds the agents, automations and internal systems a business runs on, and audits AI systems that are already live.