Legal & Compliance
Protect attorney-client privilege and confidential case data when using AI for contract review, legal research, and document summarization
Protect attorney-client privilege, client identities, and confidential case data when using AI for contract review, legal research, and document summarization.
The Problem
Law firms and corporate legal departments are under pressure to adopt AI for contract review, due diligence, legal research, and document summarization. The productivity gains are substantial: AI can reduce first-pass contract review time by 60-80%. But legal data carries unique sensitivity requirements that go beyond standard PII protection.
Attorney-client privilege demands that client identities, case details, and legal strategy remain confidential. Sending a contract containing party names, case references, and deal terms to a third-party LLM creates a privilege waiver risk. Even if the LLM provider's terms of service disclaim data use for training, the act of transmitting privileged information to a third party may be sufficient to challenge privilege in litigation.
Beyond privilege, legal documents contain a dense concentration of sensitive data: party names, counterparty identifiers, contract values, governing law clauses, and custom identifiers like matter numbers and court case IDs. Generic PII detection misses domain-specific patterns (matter numbers, case citations, deal codes), and naive redaction destroys the relational structure that makes legal analysis possible.
How OGuardAI Solves It
OGuardAI sits between your legal application and the AI model. Client-identifying information is tokenized with semantic metadata, preserving the document's logical structure while removing real identifiers. The AI model can analyze contract clauses, compare terms, and summarize obligations without knowing who the parties are.
Legal Application (DMS, CLM, eDiscovery)
|
v
OGuardAI Runtime (privileged data exists only here, transiently)
|
+---> Tokenized text (no client data) ---> LLM Provider
+---> Encrypted session blob ------------> Your Application
|
v
Restored output (channel-specific)
+---> Attorney review: full restore
+---> Client report: formatted names
+---> Court filing: redacted
+---> Knowledge base: abstract identifiersDetected Entity Types
| Entity Type | Examples | Default Action |
|---|---|---|
person | Client names, counterparty names, attorneys | Tokenize |
email | Attorney and client email addresses | Tokenize |
address | Office addresses, registered agent addresses | Tokenize |
phone | Direct lines, mobile numbers | Tokenize |
custom* | Matter numbers, case IDs, deal codes | Tokenize (configurable patterns) |
company | Company names, firm names | Tokenize |
date_of_birth | Client DOB in estate/family law matters | Tokenize |
ssn | Client SSN in tax/estate matters | Redact |
Entity types marked with * are custom types defined via policy rules, not built-in. See the Extending Entities guide for how to add custom types.
The
personandcompanyentity types are detected by the NER detector sidecar, which requiresdetector.modeset tobothoradvanced. The built-in detector alone covers structured PII (email, phone, IBAN, card, identifiers, address, date of birth) but does not detect person, company, or location names.
The custom entity type supports configurable regex patterns for domain-specific identifiers. Legal teams can define patterns for their matter numbering scheme (e.g., MTR-\d{4}-\d{6}), court case numbers (e.g., \d{2}-cv-\d{5}), or internal deal codes.
Example Policy
name: "legal-privilege"
version: "1.0.0"
description: "Attorney-client privilege protection for legal AI workflows"
rules:
- entity_type: "person"
protection_level: 2
action: "tokenize"
conditions: []
- entity_type: "company"
protection_level: 2
action: "tokenize"
conditions: []
- entity_type: "email"
protection_level: 2
action: "tokenize"
conditions: []
- entity_type: "address"
protection_level: 2
action: "tokenize"
conditions: []
- entity_type: "phone"
protection_level: 2
action: "tokenize"
conditions: []
- entity_type: "iban"
protection_level: 1
action: "tokenize"
restore_mode: "masked"
conditions: []
- entity_type: "ssn"
protection_level: 1
action: "redact"
conditions: []
- entity_type: "passport"
protection_level: 1
action: "redact"
conditions: []
- entity_type: "credit_card"
protection_level: 1
action: "tokenize"
restore_mode: "masked"
conditions: []
# Firm-defined entity (detected by custom_patterns below).
- entity_type: "matter_id"
protection_level: 2
action: "tokenize"
conditions: []
custom_patterns:
- entity_type: "matter_id"
pattern: '\bMAT[-:\s]?\d{4,8}\b'
confidence: 0.9
context_words: ["matter", "case", "docket", "file"]
defaults:
protection_level: 2
action: "tokenize"
restore_mode: "full"
on_redact: "continue"
channel_rules:
log_safe:
person: "none"
email: "none"
phone: "none"
address: "none"
company: "none"
metadata_policy:
expose_gender: true
expose_formality: true
expose_language: true
expose_role: trueThe default restore_mode: full means that unless an output channel overrides it, all non-redacted entities are restored to their original values, so an attorney gets the full analysis back. iban and credit_card are tokenized rather than redacted, but their per-rule restore_mode: masked means they come back masked even on a full-restore channel. The one shipped channel, log_safe, drops person, email, phone, address, and company entirely so an audit or log copy carries no client identities. The firm's matter_id custom pattern (MAT-####) is detected and tokenized without any code change.
To reuse an analysis across matters, add an export channel with restore_mode: abstract for person and company; abstract restore replaces names with semantic descriptions like (party A) or (opposing counsel). See the policy authoring guide for the abstract restore mode.
Example API Call
Transform a contract clause
curl -X POST http://localhost:3000/v1/transform \
-H "Content-Type: application/json" \
-H "X-API-Key: your-key-here" \
-d '{
"input": "ASSET PURCHASE AGREEMENT\n\nThis Agreement is entered into as of January 15, 2026, by and between Meridian Technologies Inc., a Delaware corporation (\"Buyer\"), and Apex Digital Solutions LLC, an Oregon limited liability company (\"Seller\").\n\nMatter: MAT-2026048\n\nSection 4.2 Indemnification. Seller shall indemnify Buyer against all losses arising from breaches of representations in Section 3. The indemnification cap is USD 5,000,000. Claims must be submitted to Robert Langford (robert.langford@meridiantech.com) within 18 months of closing.\n\nGoverning Law: State of Delaware.",
"policy": "legal-privilege"
}'Response (tokenized)
{
"safe_text": "ASSET PURCHASE AGREEMENT\n\nThis Agreement is entered into as of January 15, 2026, by and between {{company:c_001:dfe4fe5cf129}}, a Delaware corporation (\"Buyer\"), and {{company:c_002:2037a484a291}}, an Oregon limited liability company (\"Seller\").\n\nMatter: {{custom:matter_id:x_001:420611569902}}\n\nSection 4.2 Indemnification. Seller shall indemnify Buyer against all losses arising from breaches of representations in Section 3. The indemnification cap is USD 5,000,000. Claims must be submitted to {{person:p_001:ad4f97591c16}} ({{email:e_001:1bcaef1a4aff}}) within 18 months of closing.\n\nGoverning Law: State of Delaware.",
"session_id": "01916c2a-5d3e-7000-8000-000000000003",
"session_state": "eyJ2IjoxLCJzaWQiOi...",
"entity_context": [
{ "token": "{{company:c_001:dfe4fe5cf129}}", "type": "company" },
{ "token": "{{company:c_002:2037a484a291}}", "type": "company" },
{ "token": "{{person:p_001:ad4f97591c16}}", "type": "person", "formality": "formal", "language": "en" }
],
"stats": { "entities_detected": 5, "entities_transformed": 5, "entities_blocked": 0 }
}The contract structure, legal terms, indemnification cap, governing law, and temporal clauses pass through unchanged. The AI model can analyze the indemnification clause, compare it against market terms, and flag unusual provisions, all without knowing who the parties are.
Rehydrate for the attorney
curl -X POST http://localhost:3000/v1/rehydrate \
-H "Content-Type: application/json" \
-H "X-API-Key: your-key-here" \
-d '{
"output": "<LLM-generated contract analysis with tokens>",
"session_state": "eyJ2IjoxLCJzaWQiOi...",
"output_channel": "internal_summary"
}'The attorney sees the full analysis with all party names, matter numbers, and contact details restored (with iban and credit_card masked per their rules). Send the same session state to the log_safe channel and the log copy carries no client identities. Add an abstract-restore export channel, as described above, when you want the analysis reused across matters without exposing who the parties are.
Compliance and Privilege Notes
| Requirement | How OGuardAI Addresses It |
|---|---|
| Attorney-client privilege | Detected client identities and matter details are tokenized before they reach the LLM provider. Person and company names rely on the NER sidecar (best-effort): a name the model misses can pass through, so treat this as a data-minimization control, not an absolute guarantee. |
| ABA Model Rule 1.6 (Confidentiality) | Reasonable measures to prevent disclosure: tokenization, AES-256-GCM encryption, session expiry, trust boundary enforcement |
| GDPR (client PII in EU matters) | PHI/PII tokenization satisfies data minimization (Art. 5(1)(c)); no persistent storage of personal data |
| Litigation hold compatibility | Session blobs can be preserved for litigation hold; token mappings are deterministic and reproducible within the session |
| Cross-border data restrictions | Tokenized text can cross jurisdictional boundaries without triggering data transfer restrictions, since it contains no personal data |
| Conflicts check | An abstract-restore export channel (added to the policy) lets attorneys reuse anonymized precedent analyses without identifying the parties |
Ethical Considerations
Legal AI introduces specific ethical obligations. OGuardAI addresses the data protection dimension, but attorneys retain responsibility for:
- Reviewing and verifying all AI-generated legal analysis before relying on it
- Ensuring that AI use complies with applicable bar rules and court orders
- Maintaining competence in understanding the technology's capabilities and limitations (ABA Model Rule 1.1, Comment 8)
- Disclosing AI use to clients where required by jurisdiction or engagement terms
Related Resources
- Customer Support Case Study: Walkthrough of a support workflow with formal language handling
- GDPR Compliance: GDPR-specific documentation for legal teams handling EU client data
- Compliance Controls Mapping: HIPAA, GDPR, SOC 2, PCI DSS control mapping
- Extending Entity Types: How to add custom entity patterns for matter numbers and case IDs
Finance & PCI-DSS
Protect financial PII when using AI for fraud detection, customer support, and financial reporting with PCI-DSS-aligned controls without limiting AI capabilities
HR & Employee Data
Protect employee PII when using AI for HR workflows, recruiting, and internal documentation while respecting works-council and GDPR obligations