Consulting · AI governance
In a regulated industry, an AI hallucination isn't a quality bug — it's a violation with a docket number, and a second reader shows up: not just the attacker, but the examiner. We translate the reg stack into engineering requirements, assess your AI against it, and wire the controls so the evidence an examiner accepts is a byproduct — not a binder written by hand.
Two audiences, one system
We've translated the consumer-finance stack — UDAAP, ECOA, TILA, FCRA, GLBA, and the fifty-state map — out of legal citation and into engineering: blocking evals, enforcement rules, and data controls.
The good news is that the attacker and the examiner want the same thing. The architecture that stops the one is the evidence that satisfies the other — if you build it to emit that evidence as exhaust. Few teams combine the AI-engineering depth and the reg-stack fluency to do both; that's the work.
Which statutes bind which features, translated out of legal citation into the blocking evals, enforcement-layer rules, and data controls each one demands. UDAAP, ECOA, TILA, FCRA, GLBA, and the fifty-state map, as a requirements table your engineers can build against.
Including the two that rule out whole designs: the adverse-action review (may a generative model decide or explain a credit outcome?) and the eval-data review (are your golden sets and traces regulated assets you're mishandling under the Safeguards Rule?).
Evidence as exhaust: the logs, eval results, versioned rule tables, and audit trail that answer an examiner with a query instead of a scramble — produced by the controls, not written by hand after the fact.
Which regulations touch which AI features, and what each demands in engineering terms. Jurisdiction included — because the same answer can be compliant in one state and a violation in the next.
Where the model sits in each consequential path. Adverse-action reasons, disclosure math, fail posture, and eval-data handling each rule certain designs in or out.
The gaps ranked by exposure, plus the blocking eval scenarios — term accuracy, covered-borrower, bias, per-state rules — that turn compliance into a test that fails the build, not a promise.
Wire the controls so the compliance evidence is a byproduct: an examiner's request becomes a query filtered by jurisdiction, not a binder assembled under deadline.
The whole argument, article by article, is theGovernance in Regulated Rooms series — the model we assess against.
Nonbank lenders, fintechs, insurers, and other regulated operators deploying AI in consequential paths — where a wrong sentence is a compliance event, not a support ticket.
The rare pairing this needs: production AI-engineering depth and genuine reg-stack fluency, both published in the open. Not a law firm that can't build, and not engineers who've never read the statute.
Start with an assessment scoped to your regulators and your architecture.