Skip to main content

How to Build an AI Due Diligence Checklist That Meets Professional Responsibility Standards

This article maps the specific questions and contractual commitments an in-house counsel's AI due diligence checklist must contain to satisfy competence, confidentiality, and supervision duties under ABA Formal Opinion 512 and recent state bar guidance, and uses the sanctions trajectory to establish the verification standard courts now expect.

  • contract review
  • legal research
  • compliance monitoring
  • document drafting
  • e-discovery
  • litigation support
  • law firm
  • in-house legal
  • enterprise
  • small firm
  • free tier
  • cloud
  • on-premise
  • RAG
  • agentic

Profile summary

Primary use cases
legal research, contract review, document summarization
Pricing tier
enterprise/custom
Target audience
in-house legal department
Data & confidentiality notes
Checklist requires zero data retention, no training on customer content, encryption, and subprocessor transparency. (Model Rule 1.6 context →)
Last reviewed
2026-07-04

Full profile

The hard part of approving an AI legal tool is not deciding whether the tool looks useful. It is deciding whether the approval file will still make sense later, when someone asks why the legal department allowed confidential information, legal research, contract analysis, or privileged work product to pass through that system. An AI due diligence checklist for in-house counsel has to answer that later question before the tool is deployed.

That is why a normal enterprise software review is not enough. The security questionnaire may ask about access controls, uptime, subcontractors, and data centers. Those are necessary. They do not, by themselves, show that counsel evaluated the professional responsibility issues courts and bars are now treating as concrete: whether a lawyer understood the tool’s limits, protected confidential information, verified legal output, and supervised the use of the system.

The sanctions record has made the verification issue difficult to treat as theoretical. In Mata v. Avianca, the court imposed a $5,000 sanction after lawyers submitted filings containing six fabricated case citations generated through ChatGPT. In Lacey v. State Farm, sanctions reached $31,000, with the Special Master writing that “no reasonably competent attorney should outsource research and writing to this technology, particularly without any attempt to verify.” In Couvrette v. Wisnovsky, the reported sanction reached $110,000.[1] The point is not that every AI use will end in sanctions. The point is that courts are asking what the lawyer did to verify the output before relying on it.

For the foundational citation-hallucination case, see the Mata v. Avianca incident record. For a broader synthesis of sanctions and professional responsibility risk, see the AI hallucination risk analysis.

Start With Ethics Duties, Not Vendor Features

ABA Formal Opinion 512, issued in July 2024, gives in-house counsel a useful organizing frame even though it is persuasive authority, not a rule that binds every lawyer in every jurisdiction. The opinion states that lawyers using generative AI must have a reasonable understanding of the technology’s capabilities and limitations, must consider confidentiality when client information may be exposed to the provider, and must supervise AI use consistently with duties governing nonlawyer assistance under Rule 5.3.[2]

That “reasonable understanding” standard matters because it rejects two unhelpful extremes. The lawyer does not have to become an AI engineer. But the lawyer also cannot approve a tool based only on a sales demo, a productivity estimate, or a vendor’s general statement that attorneys remain responsible for final work product. Reasonable understanding has to be translated into questions the legal department actually asked, answers the vendor actually gave, and controls the business actually adopted.

Florida Bar Opinion 24-1 adds a more operational confidentiality point. Before sending confidential information through a generative AI tool, lawyers should research the provider’s data retention, data sharing, and self-learning policies. The opinion addresses competence, confidentiality, communication, and supervision; for tool approval, its most practical contribution is that it forces counsel to ask what happens to the data after the prompt is submitted.[1]

State guidance is not uniform. Florida, California, New York, Pennsylvania, and Texas have each approached lawyer AI obligations with different levels of specificity. A national legal department can use ABA Formal Opinion 512 and Florida Opinion 24-1 as a strong baseline, but it still needs a jurisdiction check before treating any checklist as complete.

Infographic showing competence, confidentiality, and supervision as connected pillars of an AI due diligence framework

The Approval Record Should Map Each Question to a Rule

A useful checklist is not a long list of procurement curiosities. It is a map from professional responsibility duty to diligence question to vendor commitment to internal record. That mapping is what lets an in-house lawyer later show that the approval was not a generic technology signoff.

Ethics dutyDue diligence questionVendor commitment to requestInternal record to preserve
Competence: Rule 1.1What tasks is the tool designed to perform, what tasks is it not designed to perform, and what failure modes has the vendor identified?Written documentation of intended use, limitations, known failure modes, citation/source functionality, and model or retrieval constraints.Approval memo describing permitted use cases, prohibited use cases, verification steps, and reviewer responsibilities.
Confidentiality: Rule 1.6Will prompts, uploaded documents, outputs, metadata, or user feedback be retained, reviewed, shared, or used for model training?Zero data retention where available, no training on customer content, encryption commitments, access restrictions, and subcontractor disclosures.Security review, privacy review, data-flow notes, consent analysis, and any client or business approval required before use.
Supervision: Rule 5.3Who reviews AI output before reliance, what must they check, and where is that review recorded?Audit logs of prompts and outputs, user-level activity records, administrative controls, and exportable review history.Human review protocol, matter-level verification record, escalation path, and periodic monitoring evidence.

This is also where adoption statistics have limited but real value. Reports cited by Harvey and GC AI state that 87% of GCs reported their teams using generative AI in 2026, up from 44% in 2025, based on the FTI/Relativity General Counsel Report.[1][3] The primary report was not directly reviewed here, so the figure should not carry more weight than it deserves. Still, it reflects the practical reality facing legal operations and in-house counsel: approvals are no longer hypothetical governance exercises.

The ACC AI Toolkit’s second edition, described by ACC in April 2026, also reflects that shift. ACC states that the toolkit includes materials on developing governance for agentic AI and tracking outside counsel’s AI use.[4] That matters because in-house counsel often have to govern two channels at once: tools used internally and AI use by law firms, vendors, or managed service providers working on company matters.

Competence: Ask What the Tool Can Reliably Do and What Must Be Verified

Competence diligence should begin with the actual legal task. “AI research assistant,” “contract review,” “summarization,” and “knowledge management” are not interchangeable risk categories. A tool that summarizes uploaded board materials raises different questions from a tool that generates legal citations, drafts pleadings, or compares contract language against a playbook.

The first checklist question should be blunt: what decisions or work product will users be allowed to rely on? If the answer is “none,” the approval record should say that. If the answer is “users may rely after review,” the record should define the review. “Lawyer oversight” is not a control unless someone can tell who reviews what, when, against which source, and where that review is recorded.

  • Identify approved use cases: research support, first-draft contract language, clause extraction, summarization, privilege review support, policy Q&A, or other defined tasks.
  • Identify prohibited use cases: filing-ready legal research without independent verification, unsupervised legal advice, final privilege calls, or use with restricted data classes.
  • Ask the vendor to describe known limitations and failure modes, including hallucinated citations, incomplete retrieval, outdated source material, unsupported jurisdictional conclusions, or overconfident summaries.
  • Require a source-verification workflow for any tool that produces legal authority, contract references, policy answers, or factual summaries.
  • Document the internal reviewer role responsible for confirming sources before legal advice, filings, board materials, or business approvals rely on the output.

For research and document-analysis tools, citation behavior deserves its own line item. GC AI’s checklist materials identify character-level citation to source documents as a diligence requirement.[1] That is more useful than a generic assurance that the tool “provides citations.” A citation trail should let the reviewer move from the generated answer to the exact source text and determine whether the output fairly represents that source.

The approval memo should capture the legal department’s answer to a practical question: what must be independently checked before anyone relies on the output? For legal research, that may mean confirming that cited cases exist, remain good law, and support the proposition stated. For contract review, it may mean checking extracted clauses against the source agreement and confirming that deviations from the playbook were not missed. For summarization, it may mean reviewing the source documents where the summary identifies commitments, deadlines, admissions, or privileged content.

A hypothetical example shows the difference. If a contract AI tool flags an indemnity clause as “market,” the reviewer should not merely accept the label. The checklist should require the reviewer to open the cited clause, compare it to the company playbook, note any uncited carveouts or caps, and record whether the tool’s conclusion was accepted, corrected, or disregarded. The value is not the ritual of review. The value is a record showing that reliance was conditioned on a defined source check.

Confidentiality: Data Retention and Training Terms Belong in the Ethics File

Confidentiality is where many AI approvals fail quietly. The legal department may know that a vendor has encryption, a security certification, and a privacy policy, but still not know whether prompts, uploaded documents, outputs, or feedback can be retained or used to improve the provider’s systems. Florida Opinion 24-1 makes that gap hard to ignore by calling out the need to research retention, sharing, and self-learning policies before confidential information is sent through the tool.[1]

The checklist should separate ordinary security from AI-specific confidentiality. SOC 2 Type II certification and AES-256 encryption are useful controls identified in GC AI’s vendor diligence materials.[1] They do not answer every AI ethics question. A system can be encrypted and still retain prompts. A vendor can have strong enterprise security and still reserve broad rights to analyze customer inputs. The approval record needs both the security answer and the AI data-use answer.

Confidentiality issueQuestion to askApproval evidence
Prompt and document retentionDoes the provider retain prompts, uploaded documents, outputs, embeddings, feedback, logs, or metadata, and for how long?Contract term, product setting screenshot, data processing addendum, or vendor security response.
Training and self-learningCan customer content be used to train, fine-tune, evaluate, or improve models or related systems?No-training commitment, zero data retention term where available, or documented restriction on use of customer content.
Human review by providerCan provider personnel review prompts, documents, outputs, flagged content, or support tickets containing legal material?Access-control terms, support protocol, confidentiality obligations, and customer approval requirement for support access.
Subprocessors and sharingWhich affiliates, infrastructure providers, model providers, or subprocessors receive customer data?Subprocessor list, notice rights, flow-down confidentiality terms, and data-location information.
Client or business consentDoes the proposed use involve information that requires client consent, business-unit approval, or matter-specific restriction?Consent analysis, matter restriction note, or documented decision not to use the tool for that data class.

Zero data retention should be requested where the use case involves sensitive legal material and the vendor can support it. The phrase should not be left undefined. The checklist should ask whether zero retention covers prompts, uploads, generated outputs, embeddings, logs, telemetry, abuse-monitoring records, and backup systems. If the vendor carves out operational logs or support records, the approval memo should say what remains stored, for how long, and why that residual retention is acceptable.

For free or consumer AI tools, the confidentiality analysis usually becomes harder because the legal department may not have negotiated retention, training, audit, or support-access terms. For more on that boundary, see the companion discussion of the ethics of free AI tools for lawyers.

Supervision: Make Review Duties Visible

Rule 5.3 supervision becomes operational only when the legal department assigns responsibility. If a vendor says the lawyer remains responsible for reviewing output, that is not yet a supervision system. It is a disclaimer. The approval record should identify which users may use the tool, which outputs require review, who may approve reliance, and what evidence of review is retained.

ABA Formal Opinion 512 treats AI supervision through the same basic lens as nonlawyer assistance: lawyers must make reasonable efforts to ensure that the conduct is compatible with professional obligations.[2] In practice, that requires technical and procedural records. Without logs, there may be no way to reconstruct what prompt was submitted, what source material was uploaded, what answer the system returned, or whether a human reviewer changed it before use.

  • Require audit logs showing user activity, prompts, uploaded files, generated outputs, timestamps, and administrative changes, subject to privilege and confidentiality controls.
  • Define which outputs must be preserved with the matter file, contract record, research memo, investigation file, or approval packet.
  • Assign review responsibility by role, not aspiration: requesting lawyer, supervising lawyer, practice lead, legal operations reviewer, privacy counsel, or information security owner.
  • Create escalation triggers for hallucinated citations, unsupported factual assertions, confidential-data exposure, privilege concerns, or output that conflicts with known law or company policy.
  • Schedule periodic review of usage logs, exception reports, and incident records after deployment.

The audit-log requirement is not just an information security preference. It is what makes supervision provable. GC AI’s diligence materials identify audit logs of prompts and outputs as a vendor requirement.[1] If the tool cannot provide usable logs, the legal department should decide whether the use case is low enough risk to proceed anyway, whether a separate internal record can substitute, or whether the tool should be limited to nonconfidential, nonreliance use.

Standard RFPs Need an AI Addendum

A standard IT RFP can still do important work. It should cover security certifications, incident response, business continuity, access controls, subprocessors, data location, and privacy terms. The problem is that it often stops before the AI-specific questions begin. Worqlo states that standard IT RFPs miss up to 60% of AI-specific risk questions.[5] Treat that figure as a vendor-published warning, not an independent legal standard, but the underlying point matches what shows up in approval meetings: traditional questionnaires rarely ask enough about model behavior, training use, retrieval limits, prompt retention, or output verification.

The AI addendum should be short enough that people actually use it and specific enough that it creates an approval record. It should not ask the vendor to explain artificial intelligence generally. It should ask the vendor to commit to how this system handles legal department data and how users can verify legally significant output.

RFP addendum areaMinimum questionWhy it matters
Model and retrieval designDoes the tool generate answers from a general model, retrieve from customer-approved sources, or combine both?The reviewer needs to know whether an answer is grounded in identified source material or generated without a verifiable source trail.
Source citationCan the tool cite the exact source text supporting each answer, and can the reviewer inspect that source?Competence review depends on checking whether the output accurately represents the source.
Customer-data useWill customer prompts, documents, outputs, or feedback be used for training, evaluation, product improvement, or other provider purposes?Confidentiality analysis turns on what happens to the information after submission.
Logging and exportCan the customer export or preserve prompt, output, review, and user-activity records?Supervision and later incident review require reconstructing what happened.
Administrative controlsCan the legal department restrict users, use cases, data types, integrations, and external sharing?Approval may depend on limiting the tool to lower-risk workflows.
Incident and error handlingHow does the vendor notify customers of data exposure, model errors, source failures, or system changes affecting legal output?The legal department needs a path to suspend use, investigate, and correct reliance.

Paywalled vendor checklists from legal research and procurement providers may add useful detail, but they are not necessary to understand the core structure. The evaluation should be built from the duties counsel must satisfy: competence, confidentiality, and supervision.

What the Final Approval File Should Contain

The approval file should be boring in the best possible way. Six months later, a reviewer should be able to see the proposed use case, the data involved, the vendor commitments, the known limitations, the verification protocol, and the person responsible for supervision. If the legal department cannot reconstruct those items, the checklist was not finished.

  • Use-case description: what the tool is approved to do, what it is not approved to do, and which legal teams or business users may use it.
  • Ethics mapping: the Rule 1.1 competence analysis, Rule 1.6 confidentiality analysis, and Rule 5.3 supervision analysis, with jurisdiction-specific notes where needed.
  • Vendor commitments: retention, training, encryption, access, logging, source citation, subprocessors, support access, and incident notification.
  • Verification protocol: what outputs require checking, which sources must be checked, who performs review, and where the review is recorded.
  • Residual-risk decision: what risk remains after controls, who accepted it, and whether any client consent, business approval, or use restriction applies.
  • Monitoring plan: audit-log review, incident tracking, model or product-change review, and periodic recertification.

Contract terms such as indemnity, liability caps, suspension rights, termination assistance, and audit rights still matter. They are downstream of the evaluation, not substitutes for it. A favorable indemnity clause does not show that the legal department understood the tool’s limitations. A termination right does not show that confidential information was protected before use. Those provisions should follow the diligence record, not replace it.

For an example of a procurement-grade platform evaluation applying this kind of lens, see the Harvey AI enterprise legal platform evaluation.

The Narrow Answer In-House Counsel Need

In-house counsel do not need to certify that an AI tool is risk-free. They do need to be able to show that competence, confidentiality, and supervision were considered before deployment, using questions and records tied to the rules that govern the lawyers approving the tool.

That means the checklist should not end with “approved by legal.” It should end with a record: the tool’s approved use, the limits counsel understood, the confidential-data terms counsel reviewed, the verification steps users must follow, and the logs or review notes that will exist if something later has to be reconstructed.

ABA Formal Opinion 512 is a strong starting point, and the ABA Formal Opinion 512 tracker entry can help readers locate the opinion context. But state variation remains. Before approving a tool for real legal work, counsel should check the applicable jurisdiction-specific guidance and preserve incident records, exception decisions, and review evidence alongside the vendor diligence file.

References

  1. AI Legal Ethics, GC AI, May 2026.
  2. ABA Issues First Ethics Guidance on AI Tools, ABA News, July 2024.
  3. AI for General Counsel, Harvey.
  4. Artificial Intelligence Toolkit for In-house Lawyers, ACC, April 2026.
  5. Enterprise AI Vendor RFP Questions, Worqlo, 2026.

Corrections & feedback

Submit corrections to factual information, flag stale data, or share deployment experience. Comments are moderated. Nothing in comments constitutes legal advice.

Comments

Join the discussion with an anonymous comment.

Loading comments...
Blogarama - Blog Directory