US legal ethics and generative AI — ABA Formal Opinion 512 (29 July 2024) and the Model Rules it applies
This page is generated from the requirement table the AiSSAY engine ships for this framework. When the engine produces an evidence pack, each row below gets a status computed from the operator's own records at that moment. This page shows the table, not anyone's results.
Informational mapping prepared by the operator's own tooling. Not a legal opinion, not a certification, and not a substitute for advice of counsel. It organizes the operator's records against the cited requirements; whether those records satisfy the requirements is a determination for the operator, counsel, and the examiner.
ABA opinions are advisory. They bind a lawyer only as the lawyer's own state adopts the rule or position. Client-file retention periods are set state by state; Model Rule 1.15 brackets five years for trust records as a placeholder. No later ABA formal opinion on AI had issued by September 2026.
The requirement table
10 rows: 5 mechanism, 4 organizational, 1 named gap
| Requirement | Mechanism, duty or gap | Type |
|---|---|---|
| Model Rule 1.1 — competence: understand what the AI tool can and cannot do, and keep that understanding current | organizational: the understanding is the lawyer's. The record's statements of what the agent could not verify, and our measurement of where models miss their own errors, are inputs to it, not a substitute. | organizational |
| Model Rule 1.6 — protect client information used with AI tools | records sealed on the firm's own machines under its key, with no vendor-side copy; every read, export and deletion logged; cryptographic erasure with a tombstone that proves the record existed | mechanism |
| Model Rule 1.6 — informed client consent before confidential information goes into a self-learning tool | organizational: consent is the lawyer's to obtain, and Opinion 512 says boilerplate in an engagement letter is not enough | organizational |
| Model Rules 3.1, 3.3 and 8.4(c) — AI output checked before it reaches a tribunal | figures and citations in each run are reconciled against the sources they claim; findings are raised and runs flagged for review; a named reviewer's countersign is sealed beside the run. The checking itself is the lawyer's. | mechanism |
| Model Rules 5.1 and 5.3 — supervision of lawyers, staff and vendors using AI | who reviewed which run, and when, is in the chain beside the run; holds on irreversible actions show what was stopped for a decision. The supervisory policies are the firm's. | mechanism |
| Model Rules 1.4 and 1.5 — telling clients about AI use, and reasonable fees for AI-assisted work | organizational: disclosure and billing judgment are the lawyer's. The sealed record's timestamps can support a billing question; they do not answer one. | organizational |
| Model Rule 1.16(d) — surrender the papers and property the client is entitled to when the representation ends | full export of every record at any time, with the chain to show the export is complete for its period | mechanism |
| Formal Opinion 520 (January 2026) — respond to information requests from a former client or successor counsel, which can include information that was never written down | organizational: deciding what a former client or successor counsel needs, and conveying what was never recorded, is the lawyer's. The sealed records can supply only what was captured. | organizational |
| Client-file and trust-record retention (state rules) | per-record retain-until dates, set when a record is sealed (default seven years); deletion before that date is refused without a recorded override; legal hold blocks deletion outright | mechanism |
| Reliance on this tool's records as evidence — independent evaluation of its controls | NOT IMPLEMENTED. No penetration test, no third-party review of the cryptography and no independent report on this software's controls exist yet. Anyone relying on these records as evidence must evaluate the tool themselves, and this row says so first. | named gap |
How a status is earned
- Evidenced
- a deterministic check ran against your records and the counts support the row. A store holding no relevant records reads unevidenced — a true statement, not a passing one. Empty never counts as clean.
- Delegated
- the mechanism is enforced by a system you already trust — a store sealed by your own key manager delegates access control to it, and the pack says the enforcing log is your key manager's, not ours. The pack names the endpoint the key manager was reached at. An AWS endpoint other than AWS's own default for the region reads delegated to that endpoint, with a request that you confirm it is your key management service. One backend — AWS KMS — has run against the real AWS KMS service; no other backend has.
- Test seam
- sealed by an in-process test backend — a stub, or a stand-in for the AWS client — and the status names which. No key manager enforces access. The seam is built and tested, and the pack refuses to call that delegation.
- Partially evidenced
- the mechanism is built and some of your runs carry its evidence, but not all — usually because they were sealed before the mechanism existed. The pack says how many runs are in each group, and never counts the missing ones as passing.
- Organizational
- the requirement is a procedure only people can perform. The pack names it as yours instead of dressing a policy up as a mechanism.
- Named gap
- the pack cannot evidence it — either the mechanism is not built, or no software can supply it — and it says which. The gap is printed, because a reviewer should read it here rather than discover it.
No status is typed in by hand: every status is recomputed from the store each time a pack is produced, the requirement and mechanism text is written and reviewed as part of the engine, and the dependency evidence comes from our release scan. A failing mechanism can never be read as evidence that the control works.