Ask a room of agency principals whether they have an AI policy and a few hands go up. Ask whether their staff are already using AI and every hand goes up. That gap is the actual risk, and it is not closed by banning anything. It is closed by writing down what is allowed, in enough detail that a busy account manager can follow it on a Tuesday afternoon.
What does an AI governance policy need to cover?
At minimum: which data classifications may and may not go into AI tools, hard stops on sensitive fields, which tools are approved, who reviews output before it reaches a client, what the vendor may do with your data, and how staff report a problem. It should be signed before any AI work begins.
- Data classification. Sort the information your agency handles into tiers and say plainly what may go into an AI tool at each tier. Vague guidance like "use good judgment" produces inconsistent behavior and gives you nothing to point at afterward.
- Hard stops. Name the fields that never go in, in plain language. Social Security numbers and dates of birth are the usual floor. This is the rule staff will actually remember.
- Approved tools. List what is sanctioned. An unnamed tool is an unapproved tool, and this is where most shadow usage lives.
- Human review. State who checks output before it reaches a client, and make it a named role rather than "someone." Every client-facing output gets a person's eyes on it.
- Vendor terms. Record what your provider does with what you send, specifically whether your data trains external or shared models. Get it in the agreement, not from a marketing page.
- Reporting. Say what to do when something goes wrong, and make it safe to report. A policy that punishes disclosure produces silence, not compliance.
- Review date. Put one in. These tools change quarterly.
Why the policy comes before the building
Because governance written after the fact stalls the rollout at the first compliance question, and by then staff have formed habits the policy has to undo. Writing it first is what lets the building continue.
This is not a theoretical sequencing preference. The pattern we see in stalled agency rollouts is consistent: licenses bought, a few enthusiastic people build something useful, then a principal or an E&O carrier asks a reasonable question, nobody has a documented answer, and everything freezes indefinitely. The work was fine. The absence of a policy is what killed it. In our engagements the policy is written and signed before anyone touches a keyboard, which is why it sits second in the sequence described in our practical guide to AI for insurance agencies.
How do you keep it from becoming shelfware?
Build the rules into the tools instead of the binder. A policy staff have to remember is a policy staff will eventually forget on a busy day. The same rules written into each project, so it refuses sensitive fields and prompts for review before send, is what changes behavior.
That is the part most policy templates cannot give you, because it is not a document task. When we build a project for census-to-bill reconciliation, the hard stop on Social Security numbers and dates of birth is enforced on every input, and the QA reminder fires before anything goes out. Nobody has to recall clause four. The tool holds the line. That is the difference between a compliance artifact and a control.
A useful test: hand your policy to your newest account manager and ask them what they may paste into an AI tool when they are behind on a Friday. If they cannot answer in one sentence, the policy is written for a regulator rather than for the person doing the work. Both audiences matter, but only one of them is making the decision at 4pm.
Do we need a HIPAA-aware version?
If your team handles protected health information, which most benefits work does, yes. The HIPAA-aware version adds specific handling rules for PHI, and it is the version we write for benefits engagements.
For LaSalle Benefits, a HIPAA-aware AI Governance Policy was signed as part of the engagement before the ten workflow projects were built. The detail on how client information is handled day to day, including what our own agreements say, is in client data, HIPAA and PII. If you are running benefits work specifically, the segment page on AI training for benefits brokerages covers how governance fits the rest of that engagement.
Does this help with CE or E&O?
It helps with the E&O conversation, because a documented policy and a human-review requirement are what a carrier wants to see. It is also the framing that matters for continuing education, since insurance CE runs through ethics, E&O and compliance rather than software training.
Where that stands today, honestly, is on AI training and insurance CE credit. We would rather you read the current state than assume.
Can we just use a template?
You can start from one, and a generic template is better than nothing. What it will not do is match your data classifications to your actual workflows or enforce anything, which is where the value is.
Every training engagement includes the policy written for your agency and signed before the build, because we are not willing to build projects that handle client data without it. If you would rather write your own and use us only for the training, that is a conversation we are happy to have on a discovery call.
