A governance playbook for AI agents in financial-services compliance
By Krish Subramanian, Chief AI Officer, KOI AI · Published · 4 min read
Compliance is where governed AI agents earn their keep and where ungoverned ones get a lender in trouble. This playbook sets out what a mid-size bank or lender needs before an agent drafts a filing or assembles audit evidence: a classification of what the agent may do, a maker-checker approval map, documentation for the model inventory, a record every action lands on, and the monitoring that keeps it that way.
Compliance teams at mid-size lenders spend a large share of their week on work that is repetitive, documented, and reviewed anyway: drafting recurring documentation, assembling audit evidence, triaging exception reports. That is the profile of work an agent does well, and it is also the work where an unexplained action is a finding. The playbook below is how KOI approaches it, and it applies whoever builds the agent.
1. Start with work that is already reviewed
The safest first agents sit in workflows where a person already reviews the output before it goes anywhere. The agent changes who prepares, not who decides.
- ◆Compliance documentation drafted from the source systems, for the compliance officer to approve.
- ◆Audit-evidence packages assembled with provenance for each item.
- ◆Exception reports read, classified, and routed with a drafted resolution.
- ◆Regulatory changes summarized and mapped to the policies and controls they touch.
- ◆Third-party due-diligence files assembled for a reviewer.
- ◆Reconciliation breaks investigated and drafted for approval.
2. Classify what the agent may do
| Class | In compliance work | Rule |
|---|---|---|
| Read | Retrieve records, summarize policies, answer questions from the system of record | Within the entitlements you grant |
| Prepare | Draft documentation, assemble evidence, classify exceptions, draft resolutions | Always allowed; always reviewed before use |
| Act internally | Open a case, update a status, attach a package to a request | Policy check; approval by record type |
| Act externally | File with a regulator, send to an auditor or counterparty, change a customer or loan record | A named person's sign-off, every time. Credit, pricing, and adverse-action decisions are never the agent's |
The four action classes applied to compliance work.
3. Build the approval map
Maker and checker, applied to the agent: it prepares, a named person approves. The map lists each consequential action, the approver by role and name, the threshold that escalates it, and the segregation rule that keeps the person who configured the agent from approving its output. Approval happens in the tools the team already uses, with the draft, its sources, and the agent's reasoning in view. Approval latency is measured from the first week, because a slow gate is a gate people route around.
4. Document for the model inventory
An agent that drafts filings belongs in your model inventory, and the documentation your model-risk function expects under SR 11-7 maps cleanly onto it:
- ◆Purpose and scope: the workflows the agent runs, and the ones it does not.
- ◆Inputs: the systems and records it reads, and under what entitlements.
- ◆Limitations: what it cannot do, the exceptions it hands to a person, the conditions under which it stops.
- ◆Validation: the real-run testing before launch, with the approvers' corrections on record.
- ◆Monitoring: the exception rate, the approval latency, the share of drafts changed on review, and the periodic re-validation schedule.
- ◆Change control: who may change the agent's policy or scope, and how that change is recorded.
KOI delivers this documentation with every compliance deployment, written for the model-risk and internal-audit functions rather than for engineers.
5. Make the record the audit trail
Every agent action, the policy check it passed, the person who approved it, and the time, in one place. When an examiner asks how a filing was prepared, the answer is the record, not a reconstruction from inboxes and shared drives. At a mid-size commercial lender, KOI's accountability ledger served as the audit trail: audit preparation went from weeks to days, every action on the workflows in scope carried a recorded approver, and no material exception was missed over the measurement period.
6. Monitor and re-validate
- ◆Exception rate: the share of items the agent routes to a person. A sudden change means the inputs changed.
- ◆Review changes: the share of drafts an approver edits. Falling is good; zero means nobody is reading.
- ◆Approval latency: hours from draft to decision. Rising means the approver is overloaded.
- ◆Periodic re-validation: a sample of the agent's work reviewed against the source, on a schedule your internal audit sets.
- ◆Third-party risk: KOI as a vendor sits under your third-party risk-management program, with the documentation the interagency guidance expects.
7. What examiners ask, and what answers it
| The question | The artifact |
|---|---|
| Who approved this filing? | The record: approver, time, the draft they saw |
| What can the agent do on its own? | The action classification and the approval map |
| How do you know it works? | The validation record and the monitoring metrics |
| What happens when it is wrong? | The policy check that stops it, the fallback, and the correction on record |
| Is it in your model inventory? | The SR 11-7 documentation set |
| How is the vendor managed? | The third-party risk file |
Six questions from an examination, and the artifact that answers each.