How to Supervise AI-Generated Communications: A Compliance Officer's Guide

Your supervision framework was designed for a different problem

The supervisory infrastructure most broker-dealers have built over the past decade works reasonably well for what it was designed to do: catch the registered rep who says something they shouldn't in an email to a client. eCommunications surveillance platforms, sampling review processes, principal sign-off workflows — these are all calibrated to the volume and behavior of human communicators.

AI agents are not human communicators. An agent handling client inquiries can generate 10,000 responses before your compliance team has reviewed one. An agent assisting with marketing content can produce materials in minutes that would take a human writer hours. The supervision model you have right now — archive, scan, sample, review, escalate — was not designed for that volume. More importantly, it was designed for detection, not prevention. By the time an AI-generated communication surfaces in a review queue, it has already reached the client.

This is the core problem with supervising AI-generated communications: the standard model is structurally mismatched. AI agents change the scale of communications risk in ways that require a different supervision architecture, not just a louder alarm bell on the existing one.

What FINRA Rule 3110 actually requires — and where the gap is

Rule 3110 requires broker-dealers to establish and maintain a supervisory system reasonably designed to achieve compliance with applicable FINRA rules and federal securities laws. For communications, that means the firm must have procedures to review and supervise outbound communications with the public.

The "reasonably designed" standard is doing real work in that sentence. FINRA doesn't specify the exact mechanics. It requires that your system be thoughtfully constructed for the actual risk environment you're operating in. What was reasonably designed for a team of registered reps sending email is not necessarily reasonably designed for an AI agent generating thousands of client-facing outputs per day. The standard is context-dependent.

As of now, FINRA has not issued AI-specific guidance on Rule 3110 compliance. That doesn't mean the obligation is relaxed — it means firms are making judgment calls about adequacy without a bright-line rule to follow. In 2025, FINRA brought 12 enforcement actions for misleading communications, generating $6.5 million in fines — and communications violations appeared in the agency's top five enforcement categories for the first time in five years. That enforcement posture will reach AI-generated communications. The question is whether your supervisory framework is already built for it when it does.

"When using Gen AI technology to create or otherwise assist in creating chatbot communications that are used with investors, ensuring the appropriate supervision of those communications, and retention of those chat sessions, in accordance with SEC and FINRA rules."

— FINRA · 2025 Annual Regulatory Oversight Report

For a detailed treatment of FINRA Rule 2210, Rule 3110, and how they apply to AI agents, that article covers the full regulatory landscape. Here, the focus is operational: what does a functioning supervision framework for AI-generated communications actually look like?

eCommunications surveillance: what it covers and what it doesn't

Before building a framework, it's worth being precise about what existing tools do and don't address. Most compliance teams already have one of the major eCommunications surveillance platforms deployed. These tools are good at what they were designed for. They are not a substitute for AI-specific governance.

The critical column is timing. Post-send detection and pre-send prevention are not equivalent compliance strategies. Post-send tells you a violation happened. Pre-generation governance prevents the violation from being created. For AI agents operating at scale, only the second model is viable.

A six-component supervision framework for AI agents

Building a supervision framework for AI-generated communications that can survive a Rule 3110 examination requires six components working together. No single component is sufficient on its own.

1. Pre-generation policy context injection. Relevant policy constraints — approved claims, prohibited language categories, applicable regulatory rules, firm-specific restrictions — are delivered into the agent's context window before it generates any client-facing output. This is the enforcement layer. The agent produces compliant output by construction because it has been given the rules that apply to this specific communication in this specific context. Without this, everything else in the framework is reactive.
2. Approved claims and prohibited language registry. Pre-generation injection requires something concrete to inject. That means maintaining a structured, current registry of what your agents can say and cannot say: approved product claims, required disclosures, prohibited language categories, competitor-reference restrictions, and regulatory constraints specific to each communication type. This registry is not a PDF handbook. It needs to be machine-readable and regularly updated as products, regulatory guidance, and firm risk tolerance evolve.
3. Escalation protocol for edge cases. Not every situation falls cleanly within or outside your approved framework. Agents will encounter requests that require judgment a policy registry can't fully supply: unusual client scenarios, nuanced investment questions, communications where suitability is ambiguous. Your escalation protocol defines what those edge cases look like, routes them to a registered principal before any response goes out, and documents the routing decision. Critically, this protocol must be wired into the agent's workflow — not a separate process the agent can bypass.
4. Near-miss audit trail. Every time the supervision framework prevents a policy-violating output — or flags content near a constraint boundary — that event should be logged. The near-miss audit trail serves multiple purposes: it demonstrates the framework is functioning, it surfaces patterns worth addressing in training or policy updates, and it provides the documentation a FINRA examination will ask for. Compliance programs that prevent violations are hard to defend without evidence that the prevention happened. This is that evidence.
5. Principal review for high-risk output categories. Certain communication types require a registered principal review regardless of whether the pre-generation governance layer cleared them. Identify which output categories those are for your firm — investment recommendations, performance representations, new client onboarding communications, anything touching suitability — and establish a principal review workflow for them. This is the AI-agent equivalent of the pre-use principal review required under Rule 2210 for retail communications. It's not a blanket requirement for every agent output; it's a targeted one for the categories where the regulatory stakes are highest.
6. Written Supervisory Procedures update covering AI. Your existing WSP was written before AI agents existed. Add a specific section covering AI-generated communications: the agents in scope, the governance controls in place, the escalation protocol, the principal review requirements, the audit trail structure, and the procedures for updating the approved claims registry. If a FINRA examiner asks how you supervise AI-generated communications, your WSP should answer that question precisely. If it doesn't mention AI at all, you have a documentation problem regardless of how well the underlying controls work.

What "reasonably designed" looks like in practice

Examinations are documentation exercises as much as they are substantive ones. A supervision framework that works but isn't documented is indistinguishable, from an examiner's perspective, from a framework that doesn't exist. "Reasonably designed" means you can show your work.

Practically, that means three things beyond implementing the six components above.

First, your WSP needs to describe the AI supervision framework at a level of specificity that makes it auditable. Which agents are in scope. What controls govern each agent's client-facing outputs. Who owns the approved claims registry and on what schedule it's reviewed. What constitutes an edge case requiring escalation and who receives the escalation. These aren't abstract policy statements — they're operational procedures that tell an examiner exactly what should happen and who is responsible.

Second, your near-miss audit trail needs to be complete and retrievable. If an examiner asks for evidence that your pre-generation governance layer was active and functioning during a specific date range, you need to be able to produce it. Audit logs that exist but aren't organized for retrieval create the same problem as audit logs that don't exist. Build the retrieval workflow into your compliance operations from the start.

Third, the WSP update is not a one-time exercise. As your AI agent deployments change — new agents, new communication channels, new use cases — the documentation needs to keep pace. A supervision framework that was reasonably designed six months ago but hasn't been updated to reflect three new agent deployments is not currently reasonably designed. Treat WSP updates for AI as a compliance event, not an annual housekeeping task.

For the legal buyer perspective on what a complete AI governance framework requires across the enterprise, the GC-focused guide covers the broader organizational context this supervision framework sits within.

A practical implementation checklist

1. Inventory every AI agent currently operating in client-facing communications workflows. Include agents that generate content a human then sends — those are in scope too.
2. Map each agent to the applicable regulatory framework. Client-facing communications from a broker-dealer trigger Rule 2210 and Rule 3110. Anything that could be a recommendation triggers Reg BI. Any channel with potential MNPI access triggers Reg FD analysis.
3. Build or procure the approved claims and prohibited language registry. If it doesn't exist in a machine-readable format that can be injected at inference time, the pre-generation governance layer has nothing to work with.
4. Implement pre-generation policy context injection for every in-scope agent. This is not optional — it is the primary control.
5. Define your edge case escalation criteria and wire the escalation protocol into the agent workflow. Test it.
6. Identify the output categories requiring principal review and establish the review workflow.
7. Confirm your audit logging captures near-misses and governance decisions, not just final outputs sent.
8. Update your Written Supervisory Procedures to document the complete AI supervision framework.
9. Set a recurring review cadence — quarterly at minimum — to update the registry and the WSP as deployments change.

Frequently Asked Questions

Does FINRA Rule 3110 apply to AI-generated communications?

Yes. The obligation to maintain a supervisory system reasonably designed to achieve compliance applies to the firm's communications, regardless of whether a human or AI agent produced them. FINRA has not issued AI-specific guidance yet, but the "reasonably designed" standard still requires that your supervision framework be adequate for the actual volume and nature of your AI agent communications.

Is sampling 5% of AI agent outputs sufficient for Rule 3110 purposes?

Almost certainly not on its own, at AI agent communication volumes. A 5% sample that was reasonable for a team of registered reps represents a qualitatively different level of oversight when the underlying population is 10,000 daily outputs. Pre-generation governance controls — not sampling — are the appropriate primary control for AI-generated communications at scale. Sampling can supplement a pre-generation framework; it cannot substitute for one.

What is the difference between a pre-generation governance layer and a standard AI content filter?

A content filter evaluates output after it is generated, often after it has been sent. A pre-generation governance layer delivers relevant policy context — firm-specific approved claims, regulatory constraints, current organizational context — into the agent's context window before it generates anything. The agent operates with those constraints active at inference time, producing compliant output from the start rather than having non-compliant output caught downstream.

What should our Written Supervisory Procedures say about AI agents?

At minimum: which agents are in scope, what pre-generation governance controls apply to each, how the approved claims registry is maintained and updated, what escalation triggers exist and who receives escalations, which output categories require principal review, how the near-miss audit trail is maintained, and who owns each element of the framework. If your WSP currently has no section addressing AI-generated communications, add one before the next examination cycle.