AI bias testing tools run unfair discrimination tests on a model: they estimate who belongs to which protected group, measure how outcomes differ, find the inputs that drive the differences and, in the fuller tools, test fairer versions of the model. There are free libraries, in-house notebooks built on them, outside testing services and workflow tools that run the whole cycle. The quickest way to choose is a pilot on a model you filed last year, where your own review already gives the answer. If the tool reproduces your numbers where the methods match, and every difference has a reason you can trace, you have evidence to trust it on the next model. Botminds' AI Bias & Fairness Testing is designed to be tried exactly this way, on one of your own models first.
A demonstration on a vendor's sample data shows that a tool runs. A pilot on your own filed model shows whether it agrees with the work your validators already signed, and that is the comparison an examiner will eventually make.
"SB21-169 requires insurers to demonstrate to the Division of Insurance (Division) how they are testing their data and tools to ensure they do not result in unfair discrimination."
Colorado Division of Insurance, on SB21-169
Which AI bias testing tools are there? Four kinds
Four kinds, and they differ less in metrics than in how much of the test they carry. A library computes; a notebook computes what an analyst codes; a service runs a test and writes it up; a workflow tool runs every step on every model version and leaves the decisions to named people.
Four kinds of AI bias testing tool, by what they carry
| Open-source library | In-house notebook | Outside testing service | Workflow tool | |
|---|---|---|---|---|
| Examples | Aequitas (Python), fairmodels (R), the CFPB’s race-estimate code | Your team’s code, often built on a library | An actuarial or audit firm’s engagement | A tool that runs estimation to report |
| Group estimation | Bring your own | As built | Usually included | Included, kept as probabilities |
| Which input drives a gap | Partly | If coded | Usually, once | Every run |
| Fairer alternatives | Some mitigation methods | Hand-built | Usually, once | Refit and tested every run |
| Documentation | None | What was saved | A report per engagement | A report per model version, signed |
| Repeat after a change | Re-run code | Re-run and re-check | New engagement | Re-run |
Why pilot on last year's filed model?
Because it is the only model where you know the answer, the data is frozen and nothing rides on the result. Your validators signed a test of it; your actuaries decided which inputs were justified; your filing says what was used. A tool that reproduces that work on the same data cut has passed a test with a known answer. A tool demonstrated only on fresh data asks you to trust a number nobody can check.
It also costs no compliance risk. New York already expects insurers with no less discriminatory alternative to repeat the search for alternatives every year (NY DFS, 2024), so re-running last year's model is work you owe anyway. And if the pilot finds something your review missed, it found it on a model you can still act on in the next filing.
Pick the model with care. The best candidate is one with a full write-up of method and results, at least one input that drew scrutiny, and a portfolio large enough to estimate groups with confidence. A model that passed everything tests only half the tool.
What to bring to the pilot
Bring the inputs your own review used, unchanged, plus the review itself. The checklist is also a test of your current process: if any item cannot be found, that is a finding before the pilot starts.
Eight things to bring to a pilot on last year's model
- The model documentation and variable list
As filed, with the change log since the prior version.
- The scored test portfolio and its data cut
The same quotes or claims, scores, tiers and premiums the review used.
- Names and addresses for estimation
Loaded into the test environment only; never into a production system.
- Last year’s results
Every metric by group, the drivers found and the alternatives tried, with the decisions taken.
- The method notes
Estimation method and vintage, labels or probabilities, reference group, significance test.
- Your testing standard
Thresholds, groups, retest triggers and the minimum accuracy an alternative must keep.
- The loss studies behind the inputs
So each input’s explanation can be drafted from your own evidence.
- The filing and the questions it drew
What a regulator actually asked is the best test of the report.
Your prior review against the pilot run: what should match
Compare the two runs layer by layer, from data to decision. Where the methods match, numbers should match closely; where the methods differ, the differences should be explained by the method, in the direction the method predicts.
Prior review against pilot run, layer by layer
Your prior review: Estimated once in a notebook; method and match rates sometimes unrecorded.
The pilot run: Same method stated with its vintage; coverage reported before any result. Counts should match yours if the method does.
Your prior review: The metrics your standard named, for the groups you chose.
The pilot run: The same metrics for every group pair. Where definitions match, the figures should agree to rounding.
Your prior review: Usually one or two inputs examined, one refit at a time.
The pilot run: Every input decomposed and removed in turn. The inputs you flagged should rank near the top.
Your prior review: The alternatives your team had time to try.
The pilot run: A wider set refit on the same data. Any new candidate is a question for the model owner, not an answer.
Your prior review: Written by hand, often after the filing.
The pilot run: Drafted with each number tied to its run; the validator compares it with what was signed.
Your prior review: Weeks to a quarter, by Botminds’ estimate 8–12 weeks of specialist time.
The pilot run: Measured in the pilot; the design target is one day for a complete test.
Alternatives on the same quotes, under the same tests
How to read a disagreement between the tool and your review
Most disagreements come from method choices, and each choice moves the numbers in a predictable direction. Trace each difference to one of the causes below before treating it as an error on either side.
Six common causes of disagreement, and which way they push
| Cause | What differs | Typical effect |
|---|---|---|
| Labels versus probabilities | One run assigned each person a group at a threshold; the other weighted by probability. | Threshold labels can over- or understate gaps; the CFPB found an 80% rule undercounted one group by 25%. |
| Reference group | One run compared with White applicants; the other with the highest-rate group, as the employment four-fifths rule does. | A higher denominator lowers every ratio. |
| Estimation vintage | Different surname lists or block-group years. | Usually small shifts in group counts; check areas that changed fast between the two years. |
| Outcome definition | Preferred-tier rate versus surcharge rate versus average premium. | Different metrics, sometimes different verdicts. |
| Data cut | A different extract date or exclusion rule. | Different counts; check before anything else. |
| Significance method | Unweighted z-test versus a test that allows for the weights. | A test that allows for the weights gives wider intervals; borderline results can flip. |
When a cause cannot be found, run a seeded check: plant an input of known effect in a copy of the portfolio and see which run reports it correctly. Planting a proxy shows the design and what it revealed about labels and probabilities; the adverse impact ratio with probability weights shows how the reference-group choice alone moves a ratio.
How long an AI bias testing pilot takes, week by week
Three weeks is enough for one model if the data is ready. Most of the calendar is access and comparison, not the run itself.
A three-week pilot on one filed model
- Data access and set-up5 d
- Standard entered, test run2 d
- Layer-by-layer comparison5 d
- Validator review and verdict3 d
Agree the verdict criteria before the run. Sensible ones: every metric reproduced where the method matches; every difference traced to a cause; the validator able to reproduce any number in the report from its run; and the elapsed time from portfolio to draft report recorded.
Who should sit in the pilot
The people who signed last year's test, because they are the only ones who can say whether a difference is the tool's error or their own. The validator should chair it; a pilot run by the team that is buying the tool is a demonstration, not a test.
Four seats in a pilot of AI Bias & Fairness Testing on last year's model
Today
Rebuilt last year’s notebook to trust it, then signed a test that arrived after the filing.
With agents
Chairs the pilot: compares each number with last year’s, and decides whether every difference is explained.
Still theirs: The verdict on whether the tool can be trusted
Today
Learned which variable was a problem once the test was done.
With agents
Checks that the drivers and alternatives the tool finds are the ones the review found, and judges any new ones.
Still theirs: Whether any alternative would have been adopted
Today
Owned the notebook and its undocumented choices.
With agents
Supplies the scored portfolio and explains every method choice in last year’s run, so differences can be traced.
Still theirs: The data cut and the method notes
Today
Assembled the filing packet from whatever the review produced.
With agents
Reads the pilot’s report as an examiner would, against last year’s.
Still theirs: Whether the report would answer the regulator
What the validator compares at the end
What a pilot on one model does not prove
A pilot proves agreement on one model, one data cut and one set of method choices. It does not prove the tool will handle a model of a different kind, a group the estimate cannot see well, or an input type your filed model did not have. Plan the second step before the first ends.
The natural second model is a different decision. If the pilot used a rating plan, try an underwriting or claims model next, where the adverse outcome is a decline or a referral rather than a price. New York's letter does not reach claims, but Colorado's statute covers "claims management" among insurance practices, so a tool that only handles prices will leave part of the exposure untested. Then test one model the tool has never seen, with no prior review to lean on, and have the validator challenge it as she would a new test. A tool that passes a known answer and then holds up under challenge on an unknown one has earned a place in the testing cycle.
Third-party AI bias testing: what an outside run can carry, and what it cannot
An outside run can carry the computation and add independence; it cannot carry the insurer's responsibility. New York says insurers "retain responsibility" for third-party tools, and that a vendor's assurance or a proprietary process is not enough on its own to show compliance (NY DFS, 2024). The NAIC bulletin asks insurers to document their due diligence on third parties, so that decisions made with a vendor's AI meet the same legal standards as the insurer's own (NAIC, 2023).
The same logic applies to testing tools: a pilot on your own filed model is the due diligence. It shows how the tool reaches its numbers, on data you understand, before any regulator asks. Independence can come from the validator who chairs the pilot: NIST's framework counts on experts who did not build the system, or outside assessors, taking part in regular assessments (NIST AI RMF, MEASURE 1.3).
Free and GitHub AI bias testing tools in a pilot
Use them as a cross-check. Run the same metric in an open-source library on the pilot data and compare it with the tool's figure; agreement on the arithmetic narrows any disagreement to method choices. The Aequitas authors point out that the field has not agreed on which fairness metric to use (Saleiro et al., 2018), which is why the pilot should fix definitions in your testing standard before either run.
What a free library will not show is the rest of the cycle: drivers on your rating plan, alternatives refit to your data, the written explanation and the sign-off. Those are what the pilot is really testing. Cost per model-year puts a number on that difference; the agents and their limits are on the AI Bias & Fairness Testing page.
Questions people ask
Are there free AI bias testing tools?
Yes. Open-source libraries such as Aequitas and fairmodels compute standard fairness metrics, and the CFPB has published code for its race-estimation method. They are good for cross-checking numbers in a pilot; they do not run the driver analysis, alternatives search or documentation an insurance regulator expects.
Where can I find AI bias testing tools on GitHub?
The open-source toolkits publish their code there, and the CFPB's paper points to its race-estimation code on GitHub. Check what each assumes: most expect each person's group to be known, so you will still need a documented estimation step and probability weighting for insurance data.
What are the main approaches to AI bias testing?
Outcome testing, which compares rates and averages by group; error testing, which compares how often the model is wrong for each group; calibration, which checks that predictions track actual losses for each group; and driver analysis, which finds the inputs behind a gap. Insurance tests usually combine all four, with a search for a less discriminatory alternative.
Should we use a third party for AI bias testing?
For independence, a periodic outside review is valuable. For every test, the cost adds up and the responsibility does not move: New York says insurers "retain responsibility" for third-party tools. A pilot chaired by your own validator gives independence without handing over the judgment.
How long should an AI bias testing pilot take?
About three weeks for one model in our suggested plan, most of it data access and comparison. The run itself should be short; if it is not, that tells you what every later test will cost.
What counts as a successful pilot?
Every metric reproduced where the methods match, every difference traced to a stated cause, any number in the report reproducible from its run, and a validator willing to sign the result. A pilot that finds something your review missed, and explains it, is a success too.