Building a generative AI use case inventory that stands up to a FINRA examination

What an examiner is looking for

FINRA states that its rules are technology neutral and continue to apply when firms use generative AI, whether the firm builds a tool for proprietary use or relies on a third party, including embedded features in existing third-party products. FINRA also says the rules that apply depend on how the firm deploys the technology, and that a firm should evaluate tools before deploying them. Rule 3110 requires a supervisory system reasonably designed and tailored to the firm's business. Among the considerations FINRA lists for AI adoption is maintaining a detailed inventory of AI models with assigned risk ratings, so that they can be monitored according to risk level.

These statements shape the inventory in three ways. Scope must reach vendor products with generative AI features, not only tools the firm sanctioned. Each entry must record how the technology is deployed, because that determines which obligations apply. And each entry must connect to supervision and to the pre-deployment evaluation. A list of tool names does none of this.

The practical distinction is between a declared inventory and a verified one. A declared inventory records what teams say they use. A verified inventory also shows what policy permitted and what actually happened. Examiners can ask about either, and a firm that can only answer the first has an inventory that goes stale the day after the last survey.

Step 1: Define scope and the fields each entry must hold

Start by defining a use case. A workable definition is a specific scenario in which generative AI is used to advance a business purpose, such as summarizing client documents or drafting code. Federal agency AI inventories use comparable definitions. Keep a separate consolidated record of products with generative AI features, since one product may support many use cases, and each use case needs its own risk view.

FINRA does not prescribe a field list. The fields below are a practical design drawing on federal agency inventory structures, which separate identifiers, purpose, data, lifecycle and risk, and on FINRA's inventory and risk-rating consideration. Adapt them to your business.

• Identity and ownership: Unique ID, name, accountable business owner, compliance contact, and the business function served.
• Purpose and deployment context: Intended purpose, who uses it, whether output reaches customers or the public, and whether it is built in-house, procured, or an embedded vendor feature.
• Technology: Vendor, product and model or models used, and any coding assistant or agent involved.
• Data handled: Data types in prompts and outputs, including customer personal information and confidential firm data.
• Risk and supervision: Risk tier, human review requirement, and the supervisory procedure the entry maps to.
• Lifecycle and evidence: Stage, approval and retirement dates, pre-deployment evaluation record, and a pointer to runtime evidence.

Classifying by risk and supervisory relevance

FINRA names model risk management, data governance, customer privacy and supervisory control systems as dimensions to consider when adopting AI. These work well as classification criteria. A simple tiering scheme scores each entry on whether output reaches customers or the public, whether sensitive or customer data is handled, whether the output informs a regulated activity, how much human review sits between output and effect, and whether the tool can take actions rather than only generate text.

FINRA reports that the most common generative AI use among member firms is summarization and information extraction, meaning condensing large volumes of text and extracting key information from unstructured documents. Even an internal use like this can carry risk when the source documents hold client data, so tiering should look at data and downstream reliance, not only at whether the use is customer-facing.

Write the criteria down and apply them the same way to every entry. Examiners are more likely to accept a defensible, consistently applied scheme than a sophisticated one applied unevenly. Each tier should drive something concrete: review frequency, required human approval, and the depth of evidence retained.

Step 3: Keep the inventory current and tied to policy

A point-in-time spreadsheet fails because change is continuous. New vendor features appear in products already approved, teams switch models, and coding assistants are installed without a ticket. Build maintenance into existing control points: procurement and vendor review, change management, access provisioning, and periodic attestation by owners. Add a recurring reconciliation of declared entries against technical discovery, and record the date and outcome of each cycle so the firm can show the inventory is maintained, not just created.

Link every entry to the policy that governs it. The entry should name the supervisory procedure it falls under and state what the use case is permitted to do: which data classes may enter prompts, which actions a tool or agent may take, and what requires human approval. Without this, the inventory says what exists but not what was allowed, and that is the question examiners press on supervision and control.

Also record the pre-deployment evaluation for each entry, since FINRA expects firms to evaluate tools before deploying them and to be able to continue complying with applicable rules. Retain the evaluation, the approver and any conditions with the entry itself. Watch for further FINRA guidance as well. FINRA has said it will consider additional guidance on how particular rules apply to specific use cases, and entries may need to be reclassified when it arrives.

Step 4: Link evidence, and where runtime enforcement fits

Evidence for an entry falls into three groups: what was approved (evaluation, risk tier, owner sign-off), what was permitted (the policy in force), and what happened (records of actual use). The first two are documents the firm already produces. The third is usually weakest, because it is reconstructed from interviews or scattered application records after a request arrives.

Enforcing policy at runtime closes part of that gap. When policy is enforced in the execution path, each interaction or tool call is evaluated and results in an outcome such as allow, redact, block, rate limit or escalate for human approval. That outcome is a record of what the policy permitted and what occurred, created at the time of the event and enforced at runtime, not reviewed after the fact. Attached to an inventory entry, it turns a declared claim into a verifiable one, and use that was never declared still produces evidence that can feed discovery.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, and generates continuous audit-ready evidence from that enforcement. Its scope is individual interactions and tool calls. Ownership, risk tiering, pre-deployment evaluation and supervisory mapping remain records the firm maintains in its inventory. Trussed runs in production for regulated enterprises in insurance, pharma, healthcare and education, supports self-managed deployment in the customer cloud, and offers configurable retention and data residency, which matter when evidence must be retained and produced on request.