Is our data safe with AI in the loop?
By Aaron Melton,
It can be, if data protection is treated as a design constraint rather than a setting to check later. The practical pattern is to anonymize personal information before any model sees it, keep the model grounded in your own records, decide in writing what data can and cannot touch a model, and run on infrastructure you control when the data warrants it.
The question behind the question
When a business owner asks whether AI is safe, they usually mean one of three things: will my customers' information end up somewhere it should not, will the model make things up, and will I be able to explain what happened if something goes wrong. Those are three different risks, and each has a different control.
Risk one: data leaving the building
A language model hosted by a vendor is, from a data-protection standpoint, a third party. Whatever you send it, you have shared. The control is not to avoid AI; it is to control what gets sent.
The strongest version of that control is anonymization in front of the model. Names, addresses, account numbers, and anything else that identifies a person are replaced with placeholders before the text reaches the model. The model classifies, routes, or drafts against the placeholders, and the real values are restored afterwards, inside your own systems. The model never sees a resident's name, and the result is just as useful.
Where even that is not enough, the model itself can run on infrastructure you control. Open models are good enough for many workflow tasks, and they can run on a server the vendor never touches.
Risk two: the model making things up
A model answering from general knowledge will sometimes produce a confident wrong answer. The control is grounding: the model is given the specific documents it may answer from, and its answer cites where it found the information. If the answer is not in the documents, the correct behavior is to say so, not to guess. This is the same pattern whether the documents are county records or a supplier's price lists.
Risk three: explaining what happened
Every automated step should be logged: what came in, what the model saw, what it produced, and who approved it. When a question comes up later, the answer is in the log. For processes with legal weight, the log is the product. We built document redaction tooling for a county where the applicable legislation requires a stated legal basis for every redaction; the system records that basis alongside each one, and a staff member accepts or overrides it before publication.
What we write down before anything goes live
For every AI step we build, we document which data it can see, which model it uses and where that model runs, what it is allowed to do without review, and where the log lives. That document is part of the deliverable. If you cannot get a clear answer to those four questions from whoever is building your automation, that is the problem to fix first.
What this looked like for one client
A county government wanted AI-assisted email triage but could not let resident data reach an external model. We built a triage pipeline that anonymizes personal information before any model sees the message, classifies and routes it, and supports retrieval over county records, all on the county's own infrastructure. It is the clearest proof we have that AI automation and strict data protection are compatible.