OGuardAI
Use Cases

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 identifiers

Detected Entity Types

Entity TypeExamplesDefault Action
personClient names, counterparty names, attorneysTokenize
emailAttorney and client email addressesTokenize
addressOffice addresses, registered agent addressesTokenize
phoneDirect lines, mobile numbersTokenize
custom*Matter numbers, case IDs, deal codesTokenize (configurable patterns)
companyCompany names, firm namesTokenize
date_of_birthClient DOB in estate/family law mattersTokenize
ssnClient SSN in tax/estate mattersRedact

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 person and company entity types are detected by the NER detector sidecar, which requires detector.mode set to both or advanced. 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: true

The 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

RequirementHow OGuardAI Addresses It
Attorney-client privilegeDetected 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 compatibilitySession blobs can be preserved for litigation hold; token mappings are deterministic and reproducible within the session
Cross-border data restrictionsTokenized text can cross jurisdictional boundaries without triggering data transfer restrictions, since it contains no personal data
Conflicts checkAn 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