LLM Meeting Notes as Reg BI Documentation: Controls and Evidence Examiners Are Likely to Expect

What Reg BI requires, and what it does not

Reg BI is satisfied by complying with four component obligations: Disclosure, Care, Conflict of Interest and Compliance. The adopting release frames the test as an objective assessment of the facts and circumstances at the time the recommendation is made, not in hindsight. That timing matters for AI notes. A summary produced and fixed close to the meeting carries more evidentiary weight than one generated or rewritten later.

The documentation duties are narrower than many teams assume. Broker-dealers and associated persons are not required to prepare and maintain documentation of the basis for each specific recommendation, including an evaluation against similar available alternatives. The adopting release encourages a risk-based approach to deciding which recommendations to document. Where oral disclosure is made, however, firms must maintain a record of the fact that it was made. The release gives recordings of telephone conversations and contemporaneous written notations as examples of sufficient documentation.

This shapes the framing. An AI meeting note is usually a voluntary or risk-based record, not a mandated one. That does not make it low risk. When a firm points to a note as evidence of its Care Obligation process or of a disclosure, the note's accuracy and completeness are what an examiner will test. An AI note also cannot demonstrate Care, Conflict of Interest or Compliance Obligation compliance by itself, because those depend on how the firm satisfies each component, not on note-taking alone.

Which is the record of authority: the note or the recording?

The regulatory text offers examples of acceptable documentation, such as recordings and contemporaneous notations, but it does not say whether an AI summary or the underlying recording governs when the two differ. The firm has to decide and write that decision down.

Three positions are defensible. The AI note can be the record, which places the full burden on review and accuracy testing. It can be a supporting aid, with the recording or transcript as the record of authority. Or it can be non-record working material that a human then converts into an approved note. The second and third positions are easier to defend, because a discrepancy can be resolved against what was actually said.

Whichever position the firm takes, three design rules follow. Retain the source recording or transcript with the AI output so the firm can show what was said and what the model produced. Keep the AI-generated note distinguishable from any human-edited or approved version. And confirm retention treatment under Exchange Act Rules 17a-3 and 17a-4 with counsel before designating any AI output as a record, since that designation drives how long it is kept and how it is produced.

Failure modes that create examination risk

FINRA acknowledges that GenAI tools can summarize large and complex documents and points to attendant risks that members must weigh against their regulatory obligations. The following failure modes are the ones most relevant to Reg BI documentation. Treat each as a hypothesis to test against your own recordings, not as an assumed rate.

The common thread is that an error in a note is not a harmless typo. If the note states a risk tolerance or objective the client never gave, it can undermine the firm's account of the facts at the time of the recommendation.

• Omission: The summary drops a stated constraint, liquidity need, or a disclosure the advisor made orally.
• Hallucination: The note adds a client-profile detail, product feature or statement that was never said.
• Misattribution: Risk tolerance or investment objectives are assigned to the wrong person, account or meeting.
• Run-to-run inconsistency: The same recording produces materially different notes on different runs, weakening reliance on any one output.
• Unfixed timing: Notes regenerated or edited after the fact blur what was documented at the time of the recommendation.
• Sensitive data exposure: Client identifiers and account details reach a model without any control over what leaves the firm.

Where runtime policy enforcement fits, and where it stops

Runtime enforcement addresses a specific gap: a written AI policy does not show what the tool was permitted to do in a given meeting. Trussed enforces policy in the execution path of AI interactions, so decisions to allow, redact, block or escalate for human approval are enforced at runtime, not reviewed after the fact. The enforcement itself generates audit-ready evidence for each interaction, mapped to frameworks including NIST. For a note-taking workflow, that means client data can be redacted before a model call, and a note can be routed to a human reviewer before it is relied on. Trussed can be self-managed in the customer's cloud, with configurable retention and data residency.

The limits matter as much as the capabilities. Enforcement applies to individual interactions and tool calls. It does not tell a firm whether a summary is accurate, whether a recommendation met the Care Obligation, or whether a note qualifies as a record under Rules 17a-3 and 17a-4. Those remain decisions for the firm's compliance, supervisory and legal functions. A runtime layer produces evidence of what the AI was allowed to do and what it produced; it does not replace review, accuracy testing or the firm's determination of record status.