Feature: Privacy Review Pipeline with PII Detection, Redaction, and Audit Controls

[hoangsonww]

Summary

Add a privacy review pipeline that detects sensitive entities in uploaded documents, lets users generate redacted copies, and records auditable privacy decisions before documents are summarized, indexed, exported, or shared.

Problem / Opportunity

DocuThinker processes PDFs, DOCX files, cloud-imported files, and chat context. Those documents can contain personal data, credentials, health information, legal records, or confidential business terms. The current product emphasizes secure processing, but it does not provide an explicit review workflow for finding and controlling sensitive content before downstream AI workflows use it.

This is a substantial product capability for professional and regulated usage. It also creates a foundation for future enterprise controls without making the core summarization UX harder for personal users.

Proposed Feature

Introduce an opt-in privacy review mode for document ingestion and document detail pages:

• Detect PII and sensitive entities such as names, emails, phone numbers, addresses, account numbers, dates of birth, financial identifiers, API keys, and custom terms.
• Show a review UI with entity type, confidence, source page/section when available, and surrounding snippet.
• Allow users to accept, ignore, or manually add redactions.
• Generate a redacted document text stream for summarization, RAG indexing, chat, export, and sharing.
• Keep original and redacted variants separate with clear metadata.
• Add audit records for scan results, user decisions, redaction generation, and downstream use of redacted versus original text.

Scope

• AI/ML service or backend service for sensitive-entity detection with configurable detectors.
• Backend storage for redaction metadata and audit events.
• Web privacy review UI integrated into upload and document detail workflows.
• API flags that let downstream features request original or redacted text according to permission and policy.
• Tests for detector integration, redaction offsets, and downstream isolation.

Acceptance Criteria

• Users can run privacy review during upload or from an existing document detail page.
• The system detects common PII and sensitive tokens with entity type, confidence, and text location metadata.
• Users can approve detected redactions, dismiss false positives, and add manual redaction spans.
• Redacted output preserves document readability while replacing sensitive spans consistently.
• Summarization, chat, RAG indexing, and exports can be configured to use the redacted text instead of the original.
• Original content remains accessible only to users with explicit permission; redacted variants are clearly labeled.
• Audit events record who scanned, approved, modified, exported, or used redacted content for analysis.
• Tests cover multi-page PDFs, DOCX text extraction, overlapping redaction spans, and downstream redacted-text usage.

Non-Goals

• Full legal compliance certification.
• Automatic deletion of original documents after redaction.
• Building a complete DLP product or endpoint monitoring suite.
• Guaranteeing perfect PII detection accuracy.

Dependencies / Risks

• Text extraction offsets may differ between PDFs, DOCX, and cloud-imported documents; the implementation needs stable span mapping.
• False positives can reduce summary usefulness, so the review UI needs override controls.
• Downstream services must be explicit about which text variant they consume to avoid accidental leakage.

Open Questions

• Should privacy review be enabled per user, per workspace, or per document?
• Which sensitive entity taxonomy should be supported in the first version?
• Should redacted documents be downloadable, or only used internally for AI processing?

[zeweihan]

The PII detection + redaction pipeline is a great feature — document AI without privacy controls is a non-starter for enterprise and legal use cases.

A few architectural suggestions from building similar systems:

1. Layered PII detection: Don't rely on a single detector. Combine:

   • Regex patterns for structured PII (SSN, email, phone, credit card)
   • NER models for unstructured PII (names, addresses, organizations)
   • Contextual heuristics for ambiguous cases ("John" in a contract vs. "John" in a code comment)

2. Confidence-scored redaction: Instead of binary "PII/not PII", assign confidence scores. Let users configure thresholds — legal teams might want 95%+ confidence auto-redaction with manual review for 80-95% range.

3. Audit trail for every redaction: Log {original_hash, pii_type, confidence, redaction_method, timestamp, reviewer}. This is critical for compliance — you need to prove what was redacted and why.

4. Reversible redaction for authorized users: Store redacted content encrypted alongside the document. Authorized reviewers (legal counsel) should be able to reveal specific redactions with an audit log entry.

5. PII type taxonomy: Beyond the basics, legal documents have domain-specific sensitive data:

   • Case numbers and docket IDs
   • Attorney-client privileged markers
   • Settlement amounts
   • Trade secret designations

For the audit controls, consider an append-only log (like a blockchain-lite approach) where each review action is cryptographically chained to the previous one. This gives you tamper-evidence without the overhead of actual blockchain.

Would be interesting to see how this integrates with the RAG pipeline — redacting before embedding, or embedding the full text and redacting at retrieval time, each has different privacy/performance tradeoffs.