Skip to main content
All resources
AI Governance, Ethics & Compliance
AI-assisted · human reviewed before publication

A Law Firm Control Plane for AI Tools: Identity, Scope, and Review

A practical law-firm control record for AI tools: distinct identity, bounded data access, separated permissions, human review, and revocation evidence.

|7 min read
Legal IntelligenceLaw Firm AIAI GovernanceClient DataHuman Review

As of October 2026, a law firm using an AI tool still owns the professional-judgment, client-information, and supervision decisions that follow from the tool's work. The American Bar Association's Formal Opinion 512 identifies competence, confidentiality, communication, supervision, candor, and reasonable fees as duties lawyers must consider when using generative AI. Florida Bar Ethics Opinion 24-1 and the State Bar of California's practical guidance add jurisdiction-specific considerations for client-facing tools, confidentiality, accuracy, billing, and advertising.

Those authorities do not prescribe one software design, and they do not create a universal rule for every firm. They do support an operating requirement: designated lawyers need evidence of which tool is acting, what information it can reach, what it may change, and who reviews the result. This article translates that requirement into a control record. It is operational guidance, not legal advice; a firm must apply the rules, opinions, client commitments, and court obligations governing its jurisdiction and matters.

Why identity, scope, and review belong in one record

An AI tool that shares a staff login is difficult to distinguish from the person who owns the account. A tool with broad access can expose more client information than its assignment requires. A review step that shows only a finished answer can hide which source the tool used or which system it changed. Treating identity, permissions, and review as separate projects leaves gaps between them.

Identity-management guidance from the OpenID Foundation emphasizes attributability and scoped authorization for software agents. OpenAI's sandbox-security guidance recommends isolated workloads, restricted network access, and keeping long-lived credentials outside environments that execute model-generated code. NVIDIA's OpenShell research shows why policy boundaries need to cover combinations of credentials, tools, files, and network paths rather than one permission in isolation. NIST's AI Risk Management Framework adds governance, documentation, monitoring, and response as continuing functions rather than a one-time setup.

A 6-part control record for every firm AI tool

  1. Name the tool and its human owner. Give each deployed tool a distinct service account or credential where the connected system supports it. Record the lawyer or manager responsible for the workflow. Shared credentials make attribution and selective revocation harder.
  2. State the job in one sentence. Describe the permitted purpose narrowly: draft a follow-up for review, classify an intake message, or summarize a document already approved for processing. A vague purpose such as “help with client work” cannot support a meaningful access decision.
  3. List the data boundary. Record the systems, folders, matter types, and fields the tool may read, plus what is excluded. Before client information is processed, review the provider's retention, training, sharing, security, deletion, and access terms against the firm's duties and client commitments.
  4. Separate read, draft, and act permissions. Reading a permitted record, drafting a proposed change, and sending or writing that change are different permissions. Begin with the narrowest tier that completes the job. An external communication or record mutation needs an explicit authorization and supervision decision.
  5. Define the reviewer and evidence shown. The reviewer should see the proposed action, its target, the source material used, and the before-and-after change when a record will be modified. Review is not meaningful when the basis and consequence are hidden.
  6. Record revocation, monitoring, and retention. Document how to disable the individual tool, who may do so, where action records are stored, and how long inputs and records are retained. The tool should not be able to alter the independent evidence used to investigate its actions.

Apply the record to client intake

Intake is a useful test because it combines prospective-client information, advertising rules, communication, routing, and deadlines. Florida Bar Ethics Opinion 24-1 says a generative AI chatbot should identify itself as a chatbot, avoid a presentation that could create confusion about the relationship, and include clear limitations. It also states that lawyers remain responsible for accuracy and professional judgment.

For an intake workflow, the control record should answer:

  • Which fields may the tool collect before a conflicts or eligibility review?
  • Where is that information stored, and which provider terms govern it?
  • May the tool only acknowledge receipt, or may it classify and route the inquiry?
  • Which messages require lawyer or trained-staff review before delivery?
  • How are urgent dates, ambiguous requests, and possible conflicts escalated?
  • How does the firm correct or delete an intake record when appropriate?

The answers will vary by firm and jurisdiction. The value of the record is that the decision becomes visible and reviewable instead of being inherited from a vendor default.

Test the boundary before expanding it

Use representative, non-client test data to confirm that the tool can complete its assigned job without reaching excluded systems. Exercise denied actions as deliberately as allowed ones: an unapproved recipient, a restricted folder, a request to alter a source record, and an instruction embedded in inbound text. Confirm that the tool stops, records the denial, and routes the exception to the named reviewer.

When the workflow changes, review the control record again. A new integration, model, data source, or outbound action can change the firm's exposure even when the interface looks the same. For a technical view of isolated execution and approval boundaries, see the sandboxed agent-harness playbook.

What a reviewer should be able to verify

  • The tool has a distinct identity and a named human owner.
  • Its purpose and excluded uses are written down.
  • Its data access is limited to the stated job.
  • Read, draft, and act permissions are separately defined.
  • Client-facing or record-changing work has an assigned reviewer.
  • The firm can produce an action record and revoke the tool without disabling unrelated systems.
  • The provider and workflow have been reviewed against the authorities that apply to the firm.

If those answers are scattered across vendor dashboards and individual memory, the missing layer is firm intelligence: the connection between policy, systems, evidence, and ownership. AlphaForge Legal Intelligence addresses the business of the law firm; it does not substitute for the firm's legal or ethics analysis.

To map those connections before changing the firm's stack, request a Firm Intelligence Audit.

AI Governance, Ethics & Compliance

Start with the problem in front of you.

The governance review is a focused entry point into the same Firm Intelligence Audit.