Introduction
You can pass a model validation review and still fail a market conduct exam. That surprises a lot of teams. The validation asks whether your model performs well. The exam asks whether a real customer got treated fairly, and whether you can prove it. Those are two very different questions, and the gap between them is where most AI compliance issues in insurance actually live.
Here’s the part worth sitting with. Almost none of these problems come from exotic technology. They come from four ordinary places. Data nobody checked. A model nobody can explain. A vendor nobody audited. A decision nobody wrote down.
So this piece skips the hand-wringing about AI risk in general. You get 10 specific failure points that regulators are already asking about across underwriting, pricing, claims, fraud, marketing, and service, and the controls that fix each one. If you’re already running AI in production, treat this as a checklist you can hold your current setup against.
What the AI Regulations for Insurers Look Like Right Now?
You don’t need to memorize every rule. You just need to know which four layers apply to you.
The NAIC Model Bulletin
Shapes most exam questions in the US. It asks for a written AI program, senior management and board ownership, real internal controls, oversight of the vendors you buy from, and documentation whenever a regulator asks. It’s guidance rather than law, but it’s the frame regulators use when they write their data calls.
State Rules That Go Further
Colorado asks life insurers using external consumer data to test for unfair discrimination and report the results, which flips the burden onto you to prove a fair outcome. New York holds you accountable for models and data you licensed from someone else. California keeps AI out of medical necessity decisions without a licensed clinician in the loop.
The EU AI Act
Write life or health risk for people in the EU and your pricing and risk assessment systems count as high risk. That brings human oversight, logging, data governance, and technical documentation duties. It follows the customer, not your head office.
The Old Laws Are Still Doing the Heavy Lifting
Most enforcement won’t arrive under an AI statute at all. Unfair trade practice acts, state discrimination laws, FCRA, HIPAA, and GLBA already cover this ground. Your model is just a new way to break a rule that existed long before it.
Top 10 AI Compliance Issues in Insurance and How to Fix Each One
Here are the AI compliance issues insurance carriers run into most often, along with why regulators care and what you can do about each one.
1. Proxy Discrimination Hiding Inside Your Underwriting Model
Your model never sees race. It sees ZIP code, occupation code, education level, credit-based attributes, and shopping history. A gradient boosting model will find the correlation whether anyone wanted it to or not, and the output starts sorting people the same way a banned variable would.
Regulators call this unfair discrimination, and Colorado and New York both expect you to go looking for it rather than wait for a complaint.
Test outcomes, not inputs. Run disparate impact analysis on approval rates, rating tiers, and pricing across inferred protected classes, using a method like Bayesian Improved Surname Geocoding where you don’t collect the attribute. Set your adverse impact ratio threshold before you build, not after you see the results. And keep a log of the variables you rejected, because examiners ask what you chose not to use just as often as they ask what you used.
2. Adverse Decisions Your Team Cannot Explain
An applicant gets declined or rated up. They call their agent. The agent opens the file and finds a score, a flag, and nothing else. Nobody in the building can say why in plain English.
That’s an adverse action notice problem under FCRA when consumer data drove the decision, and a right-to-explanation problem under the EU AI Act for high-risk systems.
Generate reason codes at the moment of the decision and store them with it. Don’t reconstruct them later from a saved model, because model versions change and your reconstruction won’t match what the customer actually got. Map SHAP values or similar attribution to reasons a person can read out loud. A good internal test: could a licensed producer explain this decision on a phone call without reading a technical term? If not, you’re not done.
3. Third-Party AI Vendors You Cannot Audit
You license a scoring model. The vendor treats its training data and methodology as a trade secret. Then a regulator asks you how the score works, and “our vendor won’t tell us” is not an answer anyone accepts.
Both the NAIC bulletin and New York’s guidance put the responsibility on the carrier, no matter who built the thing.
Move the fight into procurement, where you still have leverage. Ask for audit rights, bias testing results, and cooperation with regulatory data calls in the contract itself. Keep a vendor AI inventory with a risk tier per tool. Then run your own outcome testing on your own book, because the fairness metrics your vendor showed you were calculated on someone else’s population, not on your policyholders.
4. Alternative Data With No Consent Trail
Somebody added a data source two years ago. Nobody wrote down where it came from, what the customer agreed to, or which use cases it was cleared for. Now marketing data is quietly feeding an underwriting model.
That’s GLBA, state privacy law, and FCRA territory if the source counts as a consumer reporting agency, plus the data governance section of the NAIC bulletin.
Keep a lineage record per feature, not per system. You want to point at any single variable and say where it came from, what the legal basis is, and which models are allowed to use it. Purpose limitation controls do the rest of the work by stopping data from drifting from the use it was collected for into a use it was never cleared for.
5. Claims Automation That Goes Further Than the Rules Allow
Automating a straightforward approval is fine. Automating a denial is where carriers get into trouble, especially in health lines where California requires licensed clinician review for medical necessity. The subtler version: you have human review on paper, but your adjusters approve whatever the model outputs because they’re measured on throughput.
Unfair claims settlement practice acts and prompt payment rules apply here, and the EU AI Act’s human oversight requirement adds another layer.
Decide clearly which decisions a model can close on its own and which always need a person. Then track your override rate. If reviewers almost never overrule the model, your human oversight isn’t real and an examiner will read it that way. The same logic applies to fraud scoring. If you’re running AI-powered fraud detection in insurance claims, a high-risk flag should route a claim to an investigator, never deny it outright.
6. Generative AI That Invents Coverage
Your chatbot tells a customer their policy covers water damage. It doesn’t. Or your agent assist tool summarizes a claim file and gets a date wrong, and that summary drives the decision.
A wrong coverage statement is a misrepresentation under unfair trade practice acts. It doesn’t matter that a model said it instead of a person.
Ground every answer in the actual policy documents through retrieval, and make the system cite the clause it pulled from. Set confidence thresholds that hand off to a human. Then build refusal behavior on purpose: coverage questions, eligibility questions, and claim outcome questions should go to a person by default, not get answered by a model doing its best. Log every prompt and output, and match the retention period to your existing record retention schedule.
7. PHI and Customer Data Leaking Into Prompts and Training Sets
An AI developer pastes claim notes into a public model to test something. A retrieval index includes documents the person asking has no right to see. Training data keeps identifiers that were never needed in the first place.
HIPAA applies in health lines, GLBA across the board, and the NAIC Insurance Data Security Model Law starts an incident reporting clock you don’t want to discover late.
De-identify before training. Carry your access controls into the retrieval layer rather than applying them only at the app layer, because that’s where the quiet leaks happen. Get a BAA in place with any model provider touching PHI. And give people an approved internal tool, since shadow AI usually shows up when the sanctioned option is too slow to use.
8. Model Drift Nobody Is Watching
You validated the model at launch. It looked good. Eighteen months later your book has shifted, your mix has changed, and the model is producing outcomes that would have failed the original review. Nobody noticed because nobody was looking.
The NAIC bulletin expects ongoing monitoring, not a one-time sign-off. The EU AI Act requires post-market monitoring for high-risk systems.
Here’s the part teams miss: a model can hold its accuracy while its fairness metrics quietly degrade. So monitor disparate impact continuously, right alongside performance. Tie revalidation to how much the model matters, not just to a date on the calendar. And write down, in advance, what triggers a retrain and what triggers pulling the model out of service.
9. Rating Models That Never Made It Into a Rate Filing
Your data science team improves the model. The new version goes live. Nobody tells the actuarial team, and nobody checks whether the change moved outside what your state filing described.
That’s a filing violation, and it’s one of the easiest AI compliance issues in insurance for a regulator to spot, because they can compare what you filed against what you’re actually charging.
Put a gate in your deployment pipeline for anything touching rating. Actuarial sign-off before release, with a written check on whether the change is material to the filing. Version your models like you version code, keep the approval attached to the version, and treat a model update in rating with the same seriousness you’d treat a rate change.
10. Missing Documentation When the Examiner Asks
This one stings, because you might be doing everything above correctly. The problem is that the evidence lives in Slack threads, notebooks, and one data scientist’s memory. When the data call arrives, you can’t produce it.
Read the NAIC bulletin closely, and it’s really a documentation standard. If you can’t show it, you didn’t do it.
Keep a model inventory as your system of record, with an owner, a purpose, a risk tier, a validation date, and an approval chain for every model. Store immutable decision logs holding the model version, the inputs, the output, and any human override with the reason attached. Then maintain an exam readiness pack all year instead of building one in a panic over three weeks.
How Bacancy Technology Builds AI Governance That Survives an Exam
Most carriers we work with don’t need a new AI strategy. Nearly all of the AI compliance issues in insurance we get called about trace back to missing controls around AI that’s already running, and they need it fixed without freezing the roadmap for six months. Here’s how we handle it:
- We start with an honest AI inventory: Teams almost always undercount their own footprint, because nobody logged the vendor features switched on inside the policy admin system or the tools individual producers picked up on their own.
- We tier every model by consequence, not sophistication: A plain logistic regression that declines applicants carries more risk than a large model sorting inbound email, so your controls follow customer impact instead of technical complexity.
- We build decision logging into the application layer: Every output stores its model version, inputs, reason codes, and any human override, so you can pull up a single decision from eight months ago without rebuilding it.
- We wire bias testing into the deployment pipeline: A model can’t reach production until it clears the fairness thresholds you set, which stops testing from turning into the task everyone skips when a release date gets tight.
- We keep the model inventory as your single system of record: Every model carries an owner, a purpose, a risk tier, a validation date, and an approval chain, so nothing sits in production that nobody has signed off on.
- We work around the legacy core instead of waiting on it: Older platforms often can’t log at the granularity an audit trail needs, so we build the capture layer around them and let the modernization conversation run on its own timeline.
All of it feeds into insurance compliance management software, so your controls, validation dates, approvals, and test results sit in one place you can walk a regulator through. No pulling evidence out of five systems and a spreadsheet three weeks before an exam.
Fix AI Compliance Issues in Insurance Before a Regulator Finds Them
None of this requires you to slow down your AI program. It requires you to write things down while you build, because documentation created during development reads as credible and documentation created after a data call reads as exactly what it is.
If you want a place to start this week, pick one model that touches a customer decision and ask three questions about it. Can we explain a single decision it made last month? Can we show who approved it and when? Have we tested its outcomes for disparate impact since launch? Whatever you can’t answer is your first project, and it’s usually the paper trail rather than the math.
The teams handling this well aren’t the ones with the biggest AI budgets. They’re the ones who treated governance as part of the build instead of a review at the end. If your internal team is stretched thin, this is a reasonable thing to hand to an insurance IT services partner who has done it before, and it’s a lot cheaper than remediating under an exam deadline.
