Legal AI Prompt and Output Audit Logs

Definitions

Field definitions

Controlled vocabulary guidance

Event type

Examples: SESSION-START; PROMPT-RECEIVED; MODEL-CALL; RETRIEVAL; TOOL-CALL; POLICY-CHECK; OUTPUT-CREATED; EDIT; APPROVAL; ACCESS; EXPORT; RETENTION; HOLD; INCIDENT; CORRECTION

Governance: Version the event taxonomy and require a documented unknown or other value when instrumentation encounters an event outside the approved vocabulary.

Actor type

Examples: HUMAN-USER; REVIEWER; APPROVER; SERVICE; PROVIDER; ADMINISTRATOR; INCIDENT-RESPONDER; UNKNOWN

Governance: Keep the initiating actor, executing service, provider, reviewer, and administrator distinct and link delegation or impersonation.

Output state

Examples: GENERATED; PARTIAL; REFUSED; QUARANTINED; EDITED; REVIEWED; APPROVED-FOR-SCOPE; PUBLISHED; REJECTED; SUPERSEDED; UNAVAILABLE

Governance: Define each state and transition locally. Approved-for-scope is a workflow disposition and never means universally correct or legally sufficient.

Policy decision

Examples: ALLOW; DENY; REDACT; REQUIRE-HUMAN-REVIEW; LIMIT-SCOPE; ROUTE; HOLD; EXCEPTION; NOT-EVALUATED

Governance: Record the policy version, rule or reason, evaluator, affected scope, override authority, and effective time for every decision.

Data handling class

Examples: PUBLIC; INTERNAL; CONFIDENTIAL; CLIENT-RESTRICTED; PRIVILEGED; PERSONAL; REGULATED; SECURITY-SENSITIVE; PROVIDER-RESTRICTED

Governance: Permit multiple classifications where required, define precedence, and connect each class to access, redaction, provider, retention, and disclosure controls.

Redaction status

Examples: NOT-REQUIRED; PENDING; APPLIED; REVIEWED; REJECTED; REVERSED-BY-AUTHORITY; ORIGINAL-SEGREGATED; UNAVAILABLE

Governance: Record the rule, version, affected fields, reviewer, reason, and original-content boundary. Do not treat a masked display as deletion of the source.

Retention and hold state

Examples: ACTIVE-RETENTION; DISPOSITION-ELIGIBLE; HOLD-PENDING; HOLD-ACTIVE; HOLD-RELEASED; DISPOSITION-APPROVED; DISPOSED; EXCEPTION

Governance: Use the schedule, purpose, trigger, authority, scope, release evidence, and conflict review. Legal holds and privacy restrictions require matter-specific assessment.

Integrity and completeness state

Examples: VERIFIED-CHAIN; SIGNED; HASHED; RECONCILED; GAP-DETECTED; DUPLICATE; OUT-OF-ORDER; CORRECTED; UNAVAILABLE

Governance: Describe what the control can detect and its blind spots. Never label a record truthful or legally proven solely because an integrity check passed.

Practical workflow

1. Declare the audit boundary and purpose

   Identify the AI feature, workflow, legal use case, tenant or organization, matter or contract scope, systems, providers, users, tools, environments, jurisdictions, and period covered. State whether the log supports operational review, security investigation, quality evaluation, records management, incident response, client reporting, or another purpose. A log design is not a universal legal or evidentiary standard.

2. Assign stable event and interaction identifiers

   Create a non-reused audit event ID and link it to an interaction ID, session ID, workflow or matter ID, parent event, retry or correction event, and source system. Preserve correlation IDs across gateways, model calls, retrieval services, tools, approval steps, exports, and incidents so a reviewer can reconstruct the sequence without copying every payload into every record.

3. Record actor and authorization context

   Capture the human or service actor, actor type, tenant or firm, role, delegated authority where applicable, client or matter scope, authentication assurance, service account, impersonation or delegation marker, and authorization decision. Keep identity data proportional to the purpose and distinguish the person who initiated an action from the service that executed it.

4. Capture time and execution context

   Record event time, received time, start and end times when available, time zone or UTC convention, environment, region, network or request context where justified, client or application version, and execution status. Preserve clock or timestamp limitations and do not present a system timestamp as a legal deadline, filing date, or proof of when a human knew a fact.

5. Identify model, provider, and version

   Record provider, model family, model identifier, deployment or endpoint, release or version, routing decision, system instruction reference, safety configuration, embedding or reranking model when used, and relevant service terms or data-use setting. Preserve the configuration snapshot or immutable reference needed to explain later changes, including fallback and retry behavior.

6. Define prompt and input handling

   Record the prompt template or version, user request, system and developer instructions, variables, attachments, conversation context, language, input classification, and transformation steps. Store verbatim content only when authorized and necessary; otherwise use a controlled reference, tokenized copy, field-level redaction, or cryptographic digest with a clear statement of what cannot be reconstructed.

7. Trace retrieval and source context

   For retrieval-augmented or search-assisted work, record the source systems, index or knowledge-base version, query, filters, access scope, chunk or record identifiers, ranking or selection details, retrieval timestamp, source version, and context supplied to the model. Preserve source links and permissions without assuming that retrieval proves source authority, completeness, currency, or the truth of the generated answer.

8. Record parameters and generation controls

   Capture generation and retrieval parameters that can affect behavior, such as temperature where exposed, token or length limits, top-k or threshold values, seed where supported, stop conditions, tool mode, response format, timeout, retry count, and fallback path. Name unavailable parameters rather than inventing them and separate provider defaults from organization-selected settings.

9. Log tools and external actions

   Create child events for each tool or external service call. Record tool name and version, authorization, input reference, sanitized arguments, output reference, side effects, result code, latency, retry, failure, human confirmation, and rollback or compensating action. Treat a tool result as an input or system observation, not automatically as a verified fact or approved legal conclusion.

10. Apply and preserve policy decisions

    Record content, privacy, security, privilege, matter-scope, data-residency, human-review, and use restrictions applied before, during, or after generation. Include policy or rule version, evaluator, decision, reason, confidence or exception state, action taken, override authority, and effective time. Keep an organization-designed policy label separate from a legal determination made by qualified reviewers.

11. Store output and provenance references

    Record the output version, response content or protected reference, finish state, citations or source links, refusal or warning, safety or policy result, response format, and relationship to the prompt and tools. Link the output to the exact context used where available. If output is truncated, filtered, streamed, unavailable, or changed by a provider, preserve that limitation and the observable evidence.

12. Track edits, review, and approval

    Preserve generated, edited, annotated, rejected, approved, published, and superseded versions as attributable states. Capture editor, reviewer, approver, role and authority, comments, changes or diff reference, decision, conditions, dissent, approval purpose, effective time, and expiry or re-review trigger. Approval means approval for the declared use and scope; it does not convert an AI output into a guaranteed correct legal answer.

13. Control access and disclosure

    Apply matter, client, ethical-wall, privilege, confidentiality, role, tenant, region, and purpose-based access rules to logs and linked payloads. Record views, searches, exports, shares, administrative actions, failed attempts, recipient scope, and revocation. Prevent broad dashboards, support access, training exports, analytics, or provider access from exposing prompts, personal data, privileged material, or restricted source content.

14. Set retention, deletion, and hold behavior

    Map each log class and linked artifact to a records schedule, business purpose, privacy limitation, contract or client instruction, disposition trigger, and approved retention owner. Record legal-hold or investigation status, hold scope, notice, preservation action, release authority, conflicts with routine deletion, and disposition evidence. Do not assume that a longer retention period is always safer or legally required.

15. Redact and minimize protected content

    Classify personal, privileged, work-product, confidential, regulated, security-sensitive, client-restricted, and provider-restricted content. Define collection minimization, field-level masking, viewer-specific redaction, reversible tokenization, key custody, re-identification controls, and original-content segregation. Record redaction rule, version, actor or service, reason, timestamp, affected fields, reviewer, and whether the protected original remains available under an approved boundary.

16. Protect integrity and handle failures

    Use an appropriate integrity design such as append-only storage, sequence checks, signed manifests, hash or chain references, immutable receipts, reconciliation, monitored clock behavior, and controlled correction events. Log missing, duplicated, delayed, malformed, unauthorized, provider-unavailable, or out-of-order events and the recovery action. Integrity controls can show whether a record changed; they do not prove that its content was correct when created.

17. Link incidents and improve the control

    Link privacy, security, model, retrieval, prompt-injection, unauthorized-access, policy-bypass, harmful-output, data-loss, hold, and retention incidents to affected events, users, systems, providers, matter or client scope, containment, notification assessment, evidence, owner, status, and corrective action. Review completeness, access, latency, redaction, retention, and approval findings by declared population and improve the design without turning a control metric into a correctness claim.

Comparison

Limitations and exceptions

• An audit log records selected events and states; it does not prove that an AI output is correct, complete, current, unbiased, authoritative, privileged, or legally sufficient.
• A log can be incomplete because of provider limits, disabled instrumentation, dropped events, streaming behavior, retries, clock differences, failed exports, unavailable payloads, or an unrecorded human action.
• A retrieval trace can show what was selected or supplied, but it does not prove that the source was authoritative, current, complete, correctly interpreted, or applicable to the matter.
• A model identifier and parameter record may not reproduce a response when provider weights, hidden prompts, tools, safety layers, routing, indexes, or external data have changed.
• A hash, signature, sequence number, or append-only store can support change detection and provenance review, but it does not validate the meaning or truth of the logged content.
• Verbatim prompts and outputs may contain personal, privileged, confidential, regulated, or security-sensitive information and may create additional access, minimization, retention, and disclosure obligations.
• An approval, edit, or workflow completion shows a recorded human decision for a declared purpose; it does not establish that the reviewer checked every proposition or that the output is fit for another use.
• Retention, redaction, incident, and legal-hold treatment depends on the organization, jurisdiction, client instructions, contracts, records policy, and matter facts and requires qualified advice where legally significant.

Primary sources

Methodology

This guide uses an organization-designed audit-log framework rather than claiming that any cited authority prescribes a complete legal-AI log. Start with a system and workflow inventory covering user interfaces, model gateways, providers, prompts, attachments, retrieval indexes, source repositories, tools, policy evaluators, approval steps, exports, analytics, support access, and incident systems. Define the declared population and minimum event set before selecting storage technology. Use stable IDs and correlation links across every material transition, record timestamps with an explicit time convention, and preserve provider, deployment, model, release, prompt-template, retrieval-index, tool, policy, and application versions. Separate the original input, derived context, tool result, model output, human edit, approval, and published artifact so later reviewers can tell what the system generated from what a person changed. Capture sources and retrieval decisions with permission context and source version, but do not imply that a citation or retrieved chunk proves truth. Capture the parameters and failure paths that materially affect behavior, including retries, fallbacks, streaming truncation, unavailable values, and provider-side changes. Treat policy decisions as governed organization labels with a rule version, reason, scope, and override authority; qualified legal, privacy, security, records, and matter reviewers decide legal effect. Minimize prompt and output content by purpose, classify sensitive material, segregate privileged or restricted originals, apply viewer-specific redaction, and record the decision without leaking the protected value into broad logs. Connect retention and disposition to a schedule, purpose, client or contract requirement, privacy limit, and hold state. Use append-only or otherwise controlled integrity evidence, sequence and completeness checks, reconciliation, and explicit correction events. Test ordinary, denied, edited, approved, retried, failed, offline, tool-using, retrieval-changing, provider-changing, incident, and hold scenarios. Measure capture coverage, field completeness, timestamp quality, source and version linkage, policy-decision coverage, approval lineage, access-review coverage, redaction accuracy, hold preservation, incident linkage, and recovery time by declared populations and periods. These metrics show control operation; they are not measurements of AI correctness.

FAQs

Related CaseDocker capabilities

Related guides and resources

• Legal AI citation verification workflow
• Legal AI vendor security checklist
• Legal AI data residency and privacy requirements
• Legal RAG knowledge-base governance
• Legal AI pilot success metrics