This is the question that keeps principals up, and it deserves a straight answer rather than reassurance. Yes, there is real risk in putting client information into AI tools. No, the safe move is not waiting, because the riskiest version of this is the one already happening in most agencies: capable people using consumer tools on client work with no policy and no record.
Is it safe to put client data into AI tools?
It can be, with rules set first. Four controls do most of the work: a written policy signed before use, data classification with hard stops on sensitive fields built into the tools themselves, human review of every client-facing output, and a vendor agreement confirming your data is not used to train external or shared models.
Notice that none of those controls is "trust the vendor." Vendor terms matter and we will get to them, but a control you cannot verify is not a control. The ones above are things your agency owns and can demonstrate to a carrier, a client, or a regulator without depending on anyone else's roadmap. Where they sit in the wider adoption sequence is covered in our practical guide to AI for insurance agencies.
What is the biggest risk, actually?
Unsanctioned use. Staff pasting client information into consumer AI tools with no policy, no approved tool list, and no record of what went where. That risk exists today at most agencies, and it grows while a decision is postponed.
It is worth being blunt about this, because it inverts how the decision usually gets framed. Principals tend to treat "adopt AI" as the risky choice and "wait" as the safe one. In practice, waiting means your team keeps using these tools without guidance, because the tools are free, the deadline is real, and the work is boring. Adopting deliberately is how you replace invisible usage with usage you can see and control.
What controls actually keep sensitive fields out?
Hard stops built into the tool rather than rules staff have to remember. In the projects we build, fields like Social Security numbers and dates of birth are refused on every input, and QA reminders fire before anything goes out.
Take census-to-bill reconciliation, which is about the most sensitive routine workflow in benefits. The project takes the census and the invoice and returns a categorized discrepancy report, and the hard stop on Social Security numbers and dates of birth is enforced on every input, every time. That rule does not depend on whether the person running it read the policy or is having a bad week. It is built into the thing they are using, which is the whole point. The document version of these rules, and what else the policy has to cover, is in what belongs in an insurance agency's AI governance policy.
What should we check in a vendor agreement?
Four things: whether your inputs train the vendor's models, how long data is retained and whether you can delete it, who at the vendor can access it, and whether the vendor will sign the agreements your compliance position requires.
- Training use. Get it in the agreement that your data does not train external or shared models. A statement on a webpage is not a contractual term and can change.
- Retention and deletion. Know how long inputs persist and what your deletion rights are.
- Access. Understand who can see what, and under what circumstances.
- Paper you can sign. If your work touches protected health information, know what the vendor will and will not commit to in writing before you build workflows on it.
For our own engagements: strict data-handling agreements apply, nothing a client provides is used to train external or shared models, and clients own everything their team builds. If you are evaluating a tool independently, confirm the equivalent in writing with that vendor rather than assuming it carries over.
Does this comply with HIPAA?
HIPAA compliance depends on your agency's controls and agreements, not on the training itself. For benefits work we write and sign a HIPAA-aware AI Governance Policy before anything is built, and we build hard stops on protected fields into every project.
That is what we did at LaSalle Benefits: the HIPAA-aware policy was signed as part of the engagement, ahead of the ten workflow projects. It is also why benefits engagements get their own treatment, described on AI training for benefits brokerages. What we will not tell you is that any tool is "HIPAA compliant" as a property of the software, because that is not how the rule works. Compliance is a property of how your agency handles information, which is why the policy comes first.
Who reviews what goes out?
A person, every time, named in the policy. AI does the assembly. Your team does the judgment. Nothing client-facing ships without human review.
This is a data control as much as a quality one. The review step is where a wrong number, a mismatched client name, or an inappropriate detail gets caught before it reaches somebody's inbox. It is also the answer your E&O carrier is looking for. The workflows where this matters most, and how the review step fits into each, are described in the five use cases every agency builds in week one.
