How Do Financial Firms Govern Internal AI Under FINRA, SEC, and the EU AI Act?
A financial institution deploying internal AI takes on two obligations simultaneously: demonstrating why an automated system reached a decision, and demonstrating that regulated data never crossed a boundary it should not have. Most AI deployments satisfy neither, because they were architected for capability and governed afterward. The alternative is governed autonomy — agents execute under per-agent least-privilege identity, a human approves anything consequential, and every action writes to an immutable audit ledger inside your own cloud tenant.
What actually creates the regulatory exposure?
Not the model. The dispatch path.
An AI system that summarizes an internal document creates almost no exposure. An AI system that acts — flags a transaction, adjusts a risk score, contacts a customer, writes to a system of record — creates exposure at the moment of action, and the exposure has three separable components:
- Attribution. Who or what took the action, under which identity, on whose authority.
- Explanation. What inputs and rules produced it, and can that be reconstructed later.
- Boundary. Where the data was processed, and whether that constitutes a transfer or a third-party disclosure.
Every framework currently in play — FINRA supervisory obligations, SEC recordkeeping expectations, the EU AI Act's requirements for high-risk systems, the NIST AI Risk Management Framework, and emerging state statutes — is asking some version of those three questions [Inherited — framework requirements as published; jurisdiction-specific applicability requires counsel review].
This is the sector-specific case of the general problem covered in the evidence production gap: the control may be operating correctly and still be undemonstrable.
Why do KYC and AML alert queues fail?
Because they are tuned for recall and staffed for precision, and those two facts are incompatible.
Detection thresholds are set conservatively — correctly so, since a missed suspicious activity report is a materially worse outcome than an extra review. The consequence is an alert population far larger than the analyst hours available to work it. What follows is predictable:
Triage becomes the bottleneck, not detection. The system finds more than the team can dispose of. Backlog grows during exactly the periods when transaction volume spikes, which are the periods when genuine anomalies are most likely.
Disposition quality degrades under queue pressure. An analyst working a 400-item queue spends less time per item than one working 90. The cheapest thing to cut is the cross-reference — checking behavioral history against transactional pattern against relationship context — which is the step that separates a real anomaly from a customer who bought a car.
The evidentiary record thins out at the same rate. Rushed disposition produces rushed rationale, and the rationale is what an examiner reads two years later.
None of this is a detection-tuning problem, and tightening thresholds to reduce volume trades a workload problem for a regulatory one. It is a capacity problem, and capacity problems respond to capacity.
What can agents take over, and what stays human?
The split is not arbitrary. It follows the same line as everywhere else: work bounded by hours becomes agent work; work bounded by judgment stays with a person.
| Workflow | What the work actually is | Agent or human |
|---|---|---|
| Alert enrichment — pulling relationship, behavioral, and transactional context onto an alert | Retrieval at volume | Agent |
| Cross-referencing an alert against prior dispositions and known patterns | Pattern matching | Agent |
| Drafting the disposition rationale with sources attached | Structured composition | Agent, under approval |
| Deciding whether conduct is suspicious | Judgment, materiality, institutional knowledge | Human — always |
| Filing a regulatory report | Legal act with personal accountability | Human — always |
| Evidence harvesting for an examination request | Retrieval and mapping | Agent |
| Screening a proposed automated action against policy before dispatch | Rule evaluation | Agent |
| Accepting residual risk on an exception | Executive judgment with a named owner | Human — always |
The rows in bold are not a limitation of the technology. They are the rows where a regulator expects a person's name, and a system that removes the name from them has made the institution's position worse rather than better.
What does the control path look like end to end?
Five stages, in order, for any action that touches regulated data or a customer:
- Policy compilation.Your own obligations — supervisory procedures, recordkeeping rules, jurisdictional constraints, contractual commitments — are compiled into a versioned rule set where every rule traces back to its source clause. Not a vendor's generic template.
- Pre-dispatch screening. The proposed action is evaluated against that rule set before it executes. A blocked action returns the specific governing rule, so a reviewer resolves a question rather than opening a ticket.
- Human approval. Anything consequential passes a person. This is structural — it sits in the dispatch path, not in a configuration menu.
- Immutable ledger write. Actor, identity, rationale, sources consulted, confidence, and before/after state, appended to a record inside your own Google Cloud tenant under VPC Service Controls [Inherited — Google Cloud platform capability].
- Standing-record re-testing. When a rule changes, previously approved records are re-evaluated against the new rule set and exposure that accumulated without anyone touching anything is surfaced.
Two architectural properties make this defensible rather than decorative. Agents hold per-agent least-privilege identity, so no agent can widen its own access to a restricted repository. And a gateway validates every tool call against policy before an external action runs — including sanitization of inputs and outputs, which is the control that addresses prompt injection against systems ingesting unstructured customer text.
Decision tree: which governance obligation binds you first?
| Your path | First control to stand up | Why first |
|---|---|---|
| System advises only, no action | Supervisory logging of outputs and use | Cheapest control that closes the recordkeeping question |
| System acts on customer or transaction records | Pre-dispatch screening + human approval gate | Exposure is created at the action, so the control belongs before it |
| System informs credit, pricing, or eligibility | Full attribution and explanation record | Highest-risk classification under most AI frameworks |
| Data would be processed outside your tenant | Perimeter isolation, before anything else | A transfer question cannot be logged away after the fact |
How does this reach the P&L?
Honestly: through examination readiness and analyst capacity, not through a headline efficiency number.
We do not publish a cost-per-alert or an analyst-multiple figure, and you should be skeptical of vendors who do — the number depends entirely on your alert volume, threshold configuration, and disposition standards, none of which a vendor knows before looking at your data. What we do instead is model it on your numbers first, then let you decide whether the delta justifies anything.
The ladder
1 — Autonomous Audit Report (free). Modeled on your own data: alert population and disposition latency, which automated actions currently execute without a pre-dispatch check, where your examination evidence is reconstructed rather than contemporaneous. [Assessment scope — modeled on client data]
2 — Control Mapping Sprint. Your supervisory procedures and recordkeeping obligations compiled into a versioned, clause-traceable rule set. Yours to keep regardless of what follows.
3 — Governed pilot — one workflow. Typically alert enrichment and disposition drafting, inside your tenant, with the approval gate and ledger live, so you can inspect the artifact an examiner would see.
4 — Compliance Shield in production. The full control path across your framework set, with standing-record re-testing.
Step 1 commits you to nothing.
Frequently asked questions
Can AI agents make KYC or AML decisions?
They should not, and under a governed model they do not. Agents enrich alerts, cross-reference history, and draft disposition rationale. Whether conduct is suspicious, and whether a regulatory report is filed, remain human decisions with a named accountable person.
What does algorithmic accountability require in practice?
A reconstructable record of what an automated system did and why: the inputs consulted, the rule set applied, the identity that executed it, and the human who approved it, all dated and unalterable after the fact.
Does using AI in compliance workflows create new regulatory exposure?
It can, in two ways: by processing regulated data outside your perimeter, and by taking consequential actions without an attributable approval. Both are architectural choices rather than inherent properties of AI, which is why the perimeter and the approval gate are the first two controls.
Where is transaction data processed?
Inside your own Google Cloud tenant under VPC Service Controls, with per-agent least-privilege identity and a gateway that validates tool calls against your policy before any external action runs.
How long does examination evidence take to assemble under this model?
The evidence is collected continuously rather than assembled on request, so the work shifts from gathering to reviewing. How much time that saves depends on your current collection method, which is what the AAR models against your own numbers [Target — modeled, validated per client via the AAR].