Back to blog
    How Law Firms Build AI Models Without Sharing Privileged Documents
    legalprivilegeon-premiseenterprise-aicompliancesegment:enterprise

    How Law Firms Build AI Models Without Sharing Privileged Documents

    Legal AI requires training on privileged documents — but attorney-client privilege and work product doctrine prohibit sharing them externally. Here's how law firms are building AI that stays inside the building.

    EErtas Team·

    The best legal AI is trained on real privileged documents. The problem is that training on privileged documents requires those documents to be processed — and processing them through any external system may destroy the very privilege that makes them valuable.

    This is not a theoretical concern. It is the central tension in legal AI, and it explains why law firms have been slower to adopt AI than comparable professional services industries. The documents that would produce the best AI are exactly the documents that cannot leave the building.

    What Attorney-Client Privilege and Work Product Doctrine Require

    Attorney-client privilege protects confidential communications between a lawyer and client made for the purpose of obtaining or providing legal advice. Work product doctrine protects materials prepared by lawyers in anticipation of litigation or trial.

    Both protections can be waived — and this is the critical issue for AI. Privilege is generally waived when protected communications are disclosed to a third party without a common legal interest. The question of whether sending privileged documents to an AI vendor constitutes waiver is not fully settled law, but the risk is real and the consensus among legal ethics scholars is cautious.

    In 2023, ABA Formal Opinion 512 addressed the use of generative AI tools, noting that lawyers must take competent and reasonable measures to safeguard confidential client information, and must understand what AI providers do with the data submitted to them. Several state bar ethics opinions have followed with similar guidance.

    For practical purposes, law firm risk management teams apply a simple rule: if a document is privileged, it does not leave the firm's systems for any purpose, including AI training data preparation, unless the client has explicitly consented. Obtaining that consent for historical document archives — especially on concluded matters — is typically not feasible.

    The consequence: any AI training pipeline for legal documents must run inside the firm's own infrastructure, with no data leaving to external systems.

    What Law Firms Actually Need from AI

    The value proposition of AI for law firms is well understood, but worth being specific about the use cases that require training on internal data.

    Contract review and clause extraction. A model trained on the firm's own negotiated contracts — and the changes that were accepted, rejected, or modified — learns the firm's negotiating posture and risk tolerance for each clause type. This is qualitatively different from a general legal AI trained on public contracts. The firm's clients tend to deal in specific industries, with specific counterparties, under specific governing laws. A model trained on the firm's own work reflects those specifics.

    Matter classification. Classifying incoming documents, emails, and filings by matter type, issue area, and priority — trained on the firm's own matter history. A general-purpose classifier trained on public legal text will perform worse on the firm's specific matter mix than a classifier trained on the firm's own documents.

    Document search across matters. Semantic search over the firm's full document archive — finding precedents, analogous fact patterns, and prior research relevant to a current matter. This requires embedding the firm's own documents, which requires a pipeline that processes those documents without exporting them.

    Due diligence acceleration. Extracting key data points from transaction documents (governing law, defined terms, termination provisions, representations and warranties) to accelerate due diligence review. A model fine-tuned on the firm's own transaction documents with the firm's own extraction schema outperforms a generic extraction model.

    All of these use cases require training or indexing on the firm's own document archive. None of them can be served by a generic legal AI product. And all of them require that the document processing happen inside the firm's systems.

    A legal AI data preparation pipeline must address privilege at every stage.

    Stage 1: Privilege classification. Before any document is processed for AI purposes, it must be classified by privilege status. Most large firms have document management systems (iManage, NetDocuments, Autonomy/OpenText) with access controls that roughly correspond to privilege levels. But access controls are not privilege classifications — a document may be restricted to a matter team without being privileged, and a privileged document may have been shared beyond the matter team.

    For AI training purposes, a conservative approach classifies as privileged any document that is: attorney-client communication, work product, marked as privileged, or in a matter folder with privilege designations. Business records, publicly filed documents, and correspondence with third parties that are not privileged communications are processed separately and may be treated less restrictively.

    Stage 2: Document ingestion. Approved documents are ingested and processed on local infrastructure. PDFs are converted to text with layout preservation; Word documents are processed with metadata extraction; email chains are parsed with thread structure maintained. All processing runs on-premise. No documents are transmitted to external services.

    Stage 3: Clause segmentation. For contract review applications, documents must be segmented into clause-level units. A contract is not a useful unit of training data — a clause is. Segmentation uses a combination of structural cues (heading levels, numbering patterns, section formatting) and semantic cues (clause-type models) to identify boundaries between distinct provisions.

    Good clause segmentation for legal AI is harder than it looks. Contract drafting conventions vary by jurisdiction, transaction type, and drafting tradition. A clause that runs for two pages in a leveraged finance document might be a single sentence in a simple services agreement. The segmentation model must generalize across these formats.

    Stage 4: Clause annotation. Segmented clauses are annotated by lawyers and paralegals with clause type, applicable agreement category, and risk classification. This is the step that requires domain expert involvement — and the interface must be operable without technical knowledge.

    The annotation task for contract review is relatively clear: label each clause segment with its type (limitation of liability, indemnification, change of control, confidentiality, etc.) and optionally with a risk level (standard, negotiate, escalate). A lawyer with contract review experience can do this without guidance beyond the annotation guidelines.

    Stage 5: JSONL export. Annotated clause data is exported in JSONL format for fine-tuning:

    {"text": "Neither party shall be liable for indirect, incidental, consequential, or punitive damages arising from this agreement...", "clause_type": "limitation_of_liability", "risk_level": "standard", "governing_law": "Delaware", "agreement_type": "SaaS"}
    

    This format trains a clause classification model. The same data structure, with a different label field, trains a risk classification model.

    The temptation is to have document review attorneys — the most junior lawyers — do annotation. This is the wrong approach for two reasons.

    First, training data quality depends on annotator consistency, not just accuracy. Junior attorneys are trained to escalate judgment calls, not to apply consistent labels without guidance. They will apply different clause-type labels to similar provisions based on drafting variations that do not affect the clause's legal function.

    Second, the annotation guidelines are a legal product. Writing good annotation guidelines for clause classification requires understanding how the firm's practice groups think about clause types and risk levels — which requires senior input. An annotation project run by document review attorneys without partner-level guidance on the annotation schema will produce training data that does not reflect the firm's actual expertise.

    The right model: senior associates or partners design the annotation schema and guidelines. Paralegals and junior associates apply the labels. Senior review is spot-checked on a 10–15% sample of annotations.

    The Competitive Moat

    Law firms that solve this problem first will have a structural advantage. A contract review model trained on 500 fully annotated matters from the firm's own practice is not a commodity product. It reflects the firm's specific industry focus, its clients' risk tolerance, its negotiating history with frequent counterparties, and its jurisdiction preferences. A competitor using a generic legal AI product does not have that.

    The barrier to replication is not the model — it is the annotated training data. Generating 200–500 annotated contracts from a historical archive, with privilege preserved, is a multi-month project that requires meaningful lawyer time. Once done, it compounds: each new matter adds to the training set, and the model improves continuously.

    The firms that are building this now are doing so quietly. By the time it is obvious that this is important, the early movers will have a two-year head start on their training datasets.


    Your data is the bottleneck — not your models.

    Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading