Before any AI tool goes near client records, your compliance team will ask one question: what exactly are we sending to the AI?
With many AI tools, the answer is: your records. To answer a question, they pass the relevant files to the AI company to be read. Each question becomes a transfer of client information to a third party.
Provider protections help, but they start after the data is sent
OpenAI and Anthropic have made real progress. Used directly under their business terms, they don't train on what you send by default, and eligible customers can arrange “zero data retention” controls, with some exceptions. These are worth having. But they govern how your data is handled once it has arrived. They don't stop it being sent. “They agreed to look after it” is not the same as “they never had it”.
There is another way to build it
Picture the AI as a skilled researcher who is never allowed into your filing room. It's given a map instead: what the drawers are called, what each holds, and your firm's own notes. From that, it writes precise instructions for finding the answer. Those are carried out by software that only looks, and the answer is assembled for you from records the AI never saw.
It works. On BIRD, the research benchmark for turning plain English into database queries, this approach reached 72%, well above the published GPT-4 result. The trade-off is that the AI can't read through records itself, so it suits questions about your figures (how many, how much, what's overdue) rather than summarising documents.
How we do it. This is the design behind AI LLModelQuery. SLAQuery, for contracts and service agreements, follows the same principle a different way: it answers by quoting your approved documents and can work with no AI at all; with AI switched on, the AI is given only the few passages needed for one question. In AI LLModelQuery, for everyday questions the AI never receives the records that come back, columns you mark as sensitive are taken off its map and blocked from queries, and an administrator can switch on a request trace that records what was sent, for your compliance team to review.
In the cloud, ask who holds the keys
If a cloud service is broken into, or a staff member's password is stolen, what protects your data? In some designs the vendor holds everything needed to reach it. A safer design keeps control at your end.
How we do it. When our connecting software runs on your network, your database login stays there; the cloud never holds it. We can also require every request to read your data to carry a one-minute, single-use ticket that can only be issued from inside your office network or VPN. A stolen password used from elsewhere doesn't get it.
Ten questions to ask any AI vendor
- Are our records sent to the AI, or only a description of the database? Any exceptions? Can you show us, in the running product?
- Which AI company and platform is used, and what training and retention terms apply?
- Can we mark information as sensitive so the AI is never given it?
- Can we see a record of what was sent?
- Can it ever change our data, or only read it?
- In the cloud, where is the login to our database kept, and what does the vendor see or keep?
- If a staff member's password is stolen, what stops someone reading our data from elsewhere?
- How was the accuracy figure measured, on what kind of data, and can we test it on ours?
- What does it do when it isn't sure: guess, or tell us?
- Who owns what it learns about how our business works, and can we read, change and remove it?
The bottom line
Provider protections are a sensible starting point. Not sending client records to the AI at all is stronger. And being able to check what was sent beats taking anyone's word for it.
Alchemy Loop builds AI tools for firms that handle sensitive information. Learn more at llmodelquery.com.