Legal & Compliance

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. 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 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 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 shipped policy lists person and company under detection.required_for, so a request fails closed instead of passing a party name through when the sidecar did not run. A name the sidecar runs on but scores below its confidence threshold is still not returned, so treat name protection as a data-minimization control, not an absolute guarantee.

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

The legal-privilege policy ships in policies/legal-privilege/policy.yaml. This is that file.

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"

# person/company are NER-only types. required_for fails the request closed when the NER sidecar is
# down, so a name/company is never returned raw on the regex-only fallback.
detection:
  required_for:
    - "person"
    - "company"

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 channel the policy names, log_safe, drops person, email, phone, address, and company entirely so an audit or log copy carries no client identities. The runtime clamps log_safe to none regardless, so on that channel every entity resolves to [REDACTED], not only the five listed. 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 the value with a generic, non-identifying label taken from the restore-template floor, not with a description of the party's role: an English person token comes back as (customer) (gendered where the language has a gendered form) and a company token as (company). To read (party A) or (opposing counsel) instead, override the abstract labels deployment-wide under restore_templates in oguardai.yaml. 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 Musterfirma Inc., a Delaware corporation (\"Buyer\"), and Beispielfirma 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 Max Mustermann (max.mustermann@example.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

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