First in a series on running AI agents in production inside a financial institution. The prologue argued that production is a system built around the model, and that the real test is whether you can prove the agent still works. This piece is that proof in practice: one full validation cycle, with the methodology, the real numbers, the disparities we found, and what we are doing about them.
What production-grade AI validation is actually like in practice
This post showcases how Bretton AI validates AI agents before and after they go into production. It covers our model risk framework, the scenario testing protocol we ran against a synthetic dataset akin to what we see in production, the fairness analysis we conducted across 129 countries and multiple identity field types, and, most importantly, the gaps we found and what we are doing about them.
We operate in the banking industry, where regulators, customers, and their legal and risk teams ask hard questions about how our models behave. The right response to those questions is a complete, honest answer. AI companies have a habit of publishing only the results it is proud of. That approach makes everyone less safe, and it makes impressive results less credible when they do show up. Our Applied AI team runs validation continuously. What follows is a detailed account of one cycle: the methodology, the results, the disparities we identified, and the mitigations we have put in place or are actively building.
The task: entity research and screening at scale
The agent in this post, which we refer to internally as the Research Agent, investigates and verifies identity and geographic attributes for individuals and companies inside financial compliance workflows. Given a person or company record, it is expected to find and confirm key fields: country, city, region, and date of birth for persons; country, city, and region for companies. It does this by synthesizing customer-provided records, official government and registry data, open web sources, and reference databases.
This sounds tractable until you work with it at scale. The model processes entities from dozens of countries in a single batch. Name spellings vary. Transliterations from non-Latin scripts introduce ambiguity. Administrative regions do not map cleanly across geocoding APIs. Some sources are authoritative and others are simply wrong. The model has to make judgment calls across all of it, cite its reasoning, and stay consistent enough that a compliance analyst can rely on the output.
The stakes are asymmetric and unforgiving. A false negative in a screening context means missed information. A false positive means analyst time spent chasing data that was never there. At the volume and speed financial institutions operate, neither is tolerable at a high rate.
The validation framework
A single accuracy number is not a validation program. We need to know whether the agent handles known edge cases, performs on real work, stays reliable after deployment, and does not regress when the system changes. Our framework has four layers.
Scenario and regression testing. Before material changes ship, we test against synthetic and adversarial cases built around known failure modes: fuzzy names, transliteration, diacritic removal, name transpositions, multilingual inputs, and conflicting identity fields. The library is not static. When we find a meaningful failure in production, it becomes a permanent regression test.
Ground-truth benchmarking. We compare outputs against human-validated production cases and measure precision, recall, F1, and accuracy. We track unsupported outputs separately from ordinary incorrect answers, because a hallucinated value is a different failure from choosing the wrong value out of real evidence, and the two call for different fixes.
Production monitoring. After deployment, the Bretton Evaluator reviews sampled production traces against a defined rubric, giving us an ongoing signal as models, prompts, tools, data providers, and customer configurations change. The Bretton Evaluator gets a full treatment later in this series; here it is one layer of the framework rather than the subject.
Revalidation and escalation. Material changes to the system, meaningful performance degradation, or customer-reported failures can trigger revalidation outside the regular cadence. A benchmark only describes the version of the system that produced it. When the system changes materially, the evidence behind it has to be refreshed.
Together these layers form a continuous loop: test known failure modes, measure real outcomes, monitor production, and turn new failures into permanent tests. For the analysis below, each testable field was compared against human-reviewed ground truth and classified as a true positive, false positive, or false negative.
The dataset
The dataset for this cycle was ~1,000 entities, ~940 persons and ~100 companies, drawn from four sequential synthetic batches.
For each entity, we tested:
- Persons: country, city, region, date of birth (4 fields each)
- Companies: country, city, region (3 fields each)
After excluding cases where both model output and ground truth were empty (no test possible), the dataset produced 3,062 testable (entity, field) measurements.
The geographic spread reflects the underlying portfolio: 129 countries are represented in the person dataset.
Our review team generated human-validated verdict labels, marking each output as correct, incorrect, or sourced from a low-quality reference, for three of the four batches. For the earliest batch, which predates the addition of verdict labels to our review workflow, we applied a conservative rule-based fallback: any case where the model returned a value with no ground-truth counterpart was counted as a false positive rather than a true positive. This is the more prudent assumption, and it is disclosed in our model risk policy under Known Limitations.
Results: person entities
Across all 941 person entities and 2,803 testable rows, the combined results were:
The model correctly identified 2,665 of 2,803 testable field values, with 94 false positives and 44 false negatives.
Performance by field type. The model performs differently across field types, and the reasons matter for how we think about production risk. Country and date of birth have the highest precision. Country is highly canonicalized with a well-defined answer space and strong signal from multiple source types, so errors are rare. Date of birth behaves similarly: when the value exists, it is usually unambiguous and well-corroborated. City and region are harder. Region in particular spans ambiguous mappings, state versus province versus metropolitan area, differing international conventions for administrative subdivisions, and geocoding APIs with uneven global coverage. The precision gap between country (98.6%) and region (94.2%) reflects that directly.
This field-level breakdown is one of the most actionable outputs of the cycle. The model's risks are not spread evenly. They concentrate in region and city, which is exactly where we invest most in source quality and threshold tuning.
Non-Latin script coverage
Transliteration variance is a scenario our model risk policy specifically flags as high-risk: names originally written in Cyrillic, Arabic, Chinese characters, Vietnamese diacritics, and other non-Latin scripts, where the same entity can appear under several transliterated spellings across sources. We identified 44 unique entities in the dataset with non-Latin script names, cutting across Cyrillic, Arabic, CJK, and Vietnamese diacritic representations, and analyzed that cohort on its own.
Recall on this cohort is 100.0% across every batch. The model did not miss a single entity with a non-Latin name. Three false positives appeared in Batch C, all on the region field, where a low-confidence Wikipedia source contributed an incorrect regional designation. These were caught during verdict labeling, and the source was flagged in our QA backlog.
This is one of the results we are most confident in, and it took the most deliberate engineering to reach. Early versions of the model had structural gaps on Arabic and Cyrillic transliterations. Closing them required a scenario library of common transliteration variants, fuzzy matching tuned specifically for recall on transliterated names, and extensive multilingual testing before each release.
Results: company entities
Company entities performed better than persons across every metric, which is structurally expected. Company data tends to be more canonicalized, more widely corroborated across sources, and less exposed to transliteration variance. The dataset covered 95 companies across 21 countries.
Across 259 testable rows there was a single false positive in the entire company dataset. That is 100.0% recall, no missed company-level field value across 21 countries, at 99.6% precision.
Where the model needs work
The region precision gap. Across all geographies, region precision trails the other fields: 94.2% against 98.6% for country. This is structural, not random. Administrative regions vary widely in how they are named, defined, and mapped across jurisdictions and geocoding APIs, and the gap is largest where sub-national boundaries are complex or where several administrative levels coexist (state, province, metropolitan area, municipality). We are reviewing confidence-band thresholds for region predictions specifically. Our policy defaults to recall (we would rather retrieve a region value and have a human verify it than miss it), but this finding suggests we can tighten region precision without meaningfully hurting recall. That trade-off analysis is in progress.
Non-Latin region false positives (Batch C). The three false positives in the non-Latin cohort all fell on the region field, all from less reputable sources. They are now named regression cases in the scenario library. The 100.0% recall on the cohort holds regardless: these were cases where the model returned a wrong value, not cases where it missed an entity.
What the mitigations actually look like
Writing "we have mitigations" is easy. What they look like in practice is worth being specific about.
The scenario library. A growing set of regression cases built from known failure modes and production learnings, spanning fuzzy names, diacritics, transpositions, multilingual inputs, transliteration, and conflicting identity fields. As new issues surface, representative cases are added so future changes get tested against them.
Evaluator-based quality review. We use the Evaluator to review completed runs against a defined rubric and flag material failures in correctness, grounding, workflow execution, and deliverable quality. We are extending this into batch-scale monitoring so the same framework can support ongoing quality reporting across production.
Human adjudication. Automated evaluation is not treated as ground truth by default. The Applied AI team reviews and adjudicates the Bretton Evaluator's outputs against human judgment, so we can measure where the judge is too permissive, too strict, or inconsistent. That calibration is a prerequisite for relying on it at a larger scale.
Production feedback loop. Issues from internal QA, customer feedback, or evaluation runs feed back into the improvement process. When a failure is a repeatable pattern, it becomes a new regression case or drives changes to instructions, tooling, confidence handling, or system constraints.
Recurring validation and reporting. We run formal validation on material changes and are building toward recurring customer-facing performance reporting on the same framework. The goal is to make quality measurement a standing part of operating the system, not a one-time launch exercise.
What's next
The work coming directly out of this cycle is straightforward: expand regression coverage for the failure modes we found, improve confidence handling on ambiguous fields, and keep calibrating the Bretton Evaluator against human review.
We are also building toward a public benchmark for entity research and screening that will let outside teams compare models and configurations on this class of task. The compliance AI space needs more public evaluations of this kind, and we intend to contribute to that infrastructure rather than only run internal tests.
If you work on model risk, AI validation, or compliance engineering and want to compare notes, we would like to hear from you. This is hard enough that the field is better off thinking about it together.
