Govern what the AI does.

On September 22, I joined the panel Governing Generative Artificial Intelligence: Building Comprehensive Frameworks at FINRA’s Midwest Region Member Firm Forum in St. Louis. My perspective was that of a practitioner building AI governance inside a small financial firm: how do you make the controls meaningful without creating a program the team cannot operate?

The organizing idea I brought to the discussion was simple: governance should scale with what the AI does. A drafting assistant, a surveillance workflow, and a customer-facing chatbot need different controls. Putting them all in one bucket makes it harder to see where the consequential decisions happen.

FINRA’s Regulatory Notice 24-09 supplies the starting point: existing obligations continue to apply when a firm uses GenAI. The work begins by identifying the activity, the data, and the responsibility involved.

Three tiers. Different responsibilities.

I use three categories to make the first governance decision. These are my working categories, not a FINRA classification or a substitute for analyzing a particular use case.

Classify the workflow, not just the vendor. The same tool can sit in more than one tier. A person drafting an internal memo is one use; a system using that tool to perform a supervisory review is another. Sensitive data can require stronger controls in any tier.

Classify data before you connect anything.

The model is only part of the risk. A connector determines what the model can reach, and how quickly it can retrieve it. A permission that seems modest when a person opens one record can become consequential when an agent can query thousands.

I start with four data categories and make the permitted access explicit:

• Aggregate: appropriately de-identified information available for approved analysis.
• Operational: business information available through controlled, role-based access.
• Personal information: access scoped to the individual case and the task, with bulk retrieval restricted.
• Highly sensitive regulated data: items such as Social Security numbers and identity documents kept outside general-purpose AI connectors and handled through controlled systems.

These are access-design categories; they do not replace the firm’s legal data classifications. The principle is that AI access inherits the user’s authorization, with additional limits where the workflow needs them. Speed and aggregation deserve their own risk assessment.

Build a program the team can actually run.

A useful inventory records each tool and connector, its owner, its use tier, the data it can reach, the approval decision, and the controls attached to that decision. It is the population you test against, rather than a list you assemble when someone asks.

My default is that an unlisted tool is not approved. At the same time, a clearly bounded assistive use should have a straightforward approval path. Higher-risk uses bring compliance and technology into the review before deployment.

A recurring inventory and access review gives a small team a practical starting point: reconcile what is approved with what is connected, inspect permissions, sample actual use, and follow up on exceptions. Quarterly review can provide a cadence, but new integrations, material changes, and incidents should trigger review sooner. One periodic test does not replace ongoing supervision.

The 2026 FINRA Annual Regulatory Oversight Report discusses governance, testing, monitoring, and risks specific to agents. I translate those considerations into named owners, documented methods, and evidence someone can review.

Put compliance in the loop.

Human oversight becomes useful when you can point to where it happens. For a compliance agent, I start with a written workpaper: objective, regulatory basis, population, sample, tolerance, methodology, evidence, and sign-off.

The agent’s job is bounded: retrieve the permitted data, run the specified comparison, prepare an exception list and supporting evidence, then stop for review. Compliance owns the method and a person owns the conclusion.

The AI flags. The principal decides.

The boundary between reading and doing should be enforced in the tooling. Read, compare, draft, and flag can be permitted within scope. Changing a record, sending a communication, or affecting a customer account requires an explicit authorization step. Read-only access still needs data protections; it does not eliminate disclosure or misuse risk.

Write down the books-and-records boundary.

“Is a prompt a business record?” is too broad a starting question. I ask what role the prompt and output play: working material for a person, evidence for a supervisory conclusion, or part of a customer interaction.

My approach distinguishes transient assistive working material from final work product and from the evidence underlying a regulated activity. That distinction needs to be documented against the applicable recordkeeping requirements. Calling something a draft or placing it in the assistive tier does not itself exempt it from retention.

For supervisory workflows, the design should preserve enough context to reconstruct the work: relevant inputs and outputs, methodology and model versions, execution details, evidence, and reviewer sign-off. Customer-facing workflows also need records of the content actually delivered and the review appropriate to that communication.

The aim is a deliberate retention policy tied to the activity. Required records and legal holds take priority over ordinary deletion schedules. This is a framework for asking the right questions, not a blanket rule that every prompt must be retained or that assistive prompts can always be discarded.

Make the contract match the control.

A vendor’s product description, settings, and contract can say different things. A default training opt-out is useful, but it does not answer what the signed agreement permits or what happens when the underlying model provider changes.

I use an AI addendum checklist to turn those questions into a repeatable review:

• Identify AI features, model providers, and subprocessors.
• Address training on firm data, including prompts, outputs, and embeddings.
• Specify retention, deletion, and permitted processing at each layer.
• Carry relevant obligations through to downstream providers.
• Require notice of material model, feature, or contractual changes.
• Address output ownership, incident notification, and access to evidence.
• For connected agents, ask how the vendor tests prompt injection and limits tool access.

The foundation-model provider is part of the dependency chain. The firm needs to understand who processes its data and which controls survive a change in that chain.

A small firm can begin with an inventory, a data-access table, a vendor checklist, and one carefully specified workpaper. The quality of the program depends on whether those decisions are clear enough to operate and test.

Govern what the AI does, not the fact that it is AI.