AI use and control
Before an RIA approves AI-assisted work
A seven-part control test for deciding whether a proposed use is clear, contained and reviewable enough to enter day-to-day work.

Approval is an operating decision
A product can have strong security features and still be used badly. A modest internal task can expose more client information than its owner realizes. Before AI-assisted work becomes part of the firm's routine, the proposed use needs a written control test.
The test is not a software score. It is a concise record of what the firm is approving, under which conditions, and who has authority to stop it.
The U.S. Securities and Exchange Commission's 2024 enforcement actions concerning misleading statements about AI are a useful reminder that an investment adviser should be able to describe its use accurately. Those actions do not prescribe the framework below. The seven questions are Joans' operating test.
1. Purpose: what work is being approved?
Name the task in terms a principal, adviser, compliance lead, and technology lead would understand in the same way.
"Prepare an internal meeting brief from approved CRM notes and recent correspondence" is specific. "Use AI to improve client service" is not. The description should identify the trigger, the person using the output, the intended recipient, and the decision the output may inform.
If the business purpose, intended users, permitted information and decision authority cannot be stated clearly, the proposed use is not ready for approval.
2. Data: what information enters and leaves?
Record the source systems and information classes involved. Separate public material from firm-confidential information, customer information, credentials, health or family context, and other information the firm treats as especially sensitive.
The review should also cover the output. A summary can disclose information even when the source stays in an approved system. State what may be entered, what is prohibited, where the result is stored, and when temporary material is removed.
3. Provider and contract: does the arrangement cover the intended use?
Identify every provider that receives or can access the information, including services supplied within larger products and relevant subprocessors. Review the applicable service terms and contract for the intended use rather than relying on a product description.
The record should address processing location, reuse or training rights, retention, deletion, incident notice, logging, support access, and the evidence the provider can supply. Legal interpretation stays with qualified counsel; the operating team still needs to know what the approved arrangement permits.
4. Identity and access: who can use it and what can they reach?
Use named identities, appropriate authentication, limited permissions, controlled administration, and a clear offboarding path. Review group membership, shared links, guest access, service accounts, and any connection that can retrieve information on a user's behalf.
Access already granted elsewhere in the environment deserves particular attention. An assistant that can find material quickly can reveal permissions that were technically valid but no longer appropriate.
5. Human authority: which decisions remain with a person?
Identify who checks the source material, who judges the output, who approves any client-facing use, and who is permitted to send or act. The person authorized by the firm remains responsible for professional judgment, recommendations, approvals, and client communication.
Human review is a defined control, not a phrase added to a policy. The reviewer needs enough context, time, and authority to reject the output. Material client communication should not move from generation to delivery without that named review.
6. Retained evidence: what will show how the work was controlled?
Decide what the firm will retain before the first use. Depending on the task, that may include the approved purpose, source rules, configuration, provider review, prompt or template version, material source references, reviewer, final output, exceptions, and date of approval.
The aim is not to preserve every intermediate keystroke. It is to keep enough evidence to reconstruct the material decision and show that the approved process was followed.
7. Failure path: what happens when the service is wrong or unavailable?
Define a manual fallback and the conditions that stop use. The plan should cover an unreliable output, inappropriate disclosure, unexpected system access, provider outage, suspected security event, and a material change to the service.
Staff need a simple escalation route: pause the task, preserve relevant evidence, contain access where necessary, notify the responsible owner, and move to the approved fallback. Incident response and legal obligations remain with the firm's designated specialists.
Record one of three decisions
The test should end with a decision that staff can follow: approved within stated limits, approved for a controlled pilot, or not approved. Record the owner, conditions, open actions, approval date, and next review date.
Staff can then distinguish approved use from improvisation. Reviewers can see the basis of the decision, while product and provider claims remain inputs rather than substitutes for the firm's judgment.