As of October 2026, a chat transcript is not a complete record of what an AI tool did. A transcript may show a prompt and a response. It may not show which credential was used, which record was retrieved, whether a tool call changed data, which policy version applied, or who approved an outbound action.
That gap matters in a law firm. The American Bar Association's Formal Opinion 512 places competence, confidentiality, communication, supervision, candor, and reasonable-fee questions around lawyers' use of generative AI. Florida Bar Ethics Opinion 24-1 emphasizes confidentiality, accuracy, supervision, and responsibility for client-facing uses. Neither opinion says that one log format satisfies every duty. They do make reconstruction and supervision practical concerns that a firm should address under its governing rules.
Start with the incident question
An action record should help a designated reviewer answer: what happened, under whose authority, to which system or person, using what information, with which approval, and with what result? NIST's AI Risk Management Framework treats documentation, monitoring, incident response, and recovery as connected governance functions. OpenAI's tracing documentation likewise describes end-to-end records that can include model responses, tool calls, inputs and outputs, duration, and status.
The goal is not to retain everything forever. Excessive logging can create its own confidentiality, security, discovery, and retention concerns. The firm needs a defined record that is useful enough to investigate and protected enough not to become a second uncontrolled client-data repository.
Record 10 fields for consequential actions
- Tool identity. Record the distinct service identity, workflow name, and deployed version.
- Human owner. Name the lawyer, manager, or team accountable for the workflow.
- Time and request identifier. Use a consistent timestamp and a unique identifier that connects related steps without relying on memory.
- Trigger and purpose. Record whether the run came from a user request, a schedule, an inbound message, or another system, plus the permitted job it was trying to perform.
- Data classes and sources. Identify the systems or records consulted. Prefer references, classifications, and hashes where they can support reconstruction without duplicating sensitive content.
- Tools and permissions used. Record the function called, the credential or role class, and whether the action was read, draft, write, send, publish, delete, or spend.
- Target and proposed change. Capture the recipient, record, file, account, or external system affected and a before-and-after representation where appropriate.
- Policy result. Record which rule set and version allowed, denied, or escalated the action.
- Approval evidence. For gated actions, record the approver's authenticated identity, time, decision, and the exact action shown for review. Do not manufacture a reviewer identity for automated events.
- Outcome and error state. Record whether execution succeeded, failed, timed out, was rolled back, or required follow-up.
Separate conversation history from execution evidence
A model conversation can be relevant context, but it should not be treated as the authoritative execution record. The execution layer should produce its own event when a tool reads a matter record, drafts a message, sends a communication, or alters data. That record should exist even if the conversational interface is unavailable.
For a complementary explanation of durable change history, see why agent actions need versioned evidence. This draft remains distinct from general control-plane architecture because its primary purpose is incident reconstruction.
Protect the log itself
- Limit access. Reviewers should see only the matters and systems necessary for their role.
- Reduce unnecessary content. Do not copy full documents, prompts, or client messages when a reference, classification, or digest can support the review.
- Make alteration visible. Keep the operational tool from silently rewriting or deleting its own action record. Use append-oriented storage or equivalent controls appropriate to the system.
- Define retention. Set retention with the firm's governing duties, client commitments, litigation-hold process, cyber program, and actual investigative need in view. There is no universal retention period for every firm and workflow.
- Test retrieval. Run a tabletop exercise: select one historical action and ask a reviewer to reconstruct identity, authority, data source, approval, and outcome from the stored evidence.
Use the record for review, not surveillance theater
A log that nobody owns or can query is not an effective control. Assign review triggers: denied access, unusual outbound volume, a new data source, repeated tool errors, approval bypass attempts, or a complaint tied to a communication. Define who investigates and how the tool is paused while facts are gathered.
AlphaForge Legal Intelligence connects those operational records to the business of the law firm: ownership, intake, client communication, systems, and evidence. The design must still be reviewed under the firm's jurisdiction-specific obligations and security program.
To map where evidence is missing before adding another integration, request a Firm Intelligence Audit.