Sensitive information redaction workbench

The problem you will solve

A fictional support team wants to share example tickets without exposing email addresses or phone numbers. Build a redaction workbench that shows what was detected and what remains uncertain. Masking selected identifiers does not establish anonymity: contextual clues and unsupported identifier types can still reveal information.

Before you start

Text spans, Unicode handling, pattern matching and precision/recall metrics.

Suggested tech stack

• Python
• Regex
• JSON Schema
• FastAPI
• pytest

Data plan

Author 40 fictional tickets with invented contact details and manually annotate sensitive character spans. Include tricky punctuation, international formats, harmless number strings and overlapping detections. Never use real customer tickets to develop this public demo.

Hardware and cost

A deterministic email/phone baseline runs on CPU. An optional Google Sensitive Data Protection comparison is a hosted service with usage costs; use synthetic text and review data-handling settings. Do not upload sensitive data merely to test the system.

Define the input and output

Use this illustrative contract as a starting point, then specify required fields, validation and error responses in your own implementation. It is not a complete API schema.

Input: {"text":"Email demo@example.com about order 123."}
Output: {"text":"Email [EMAIL_ADDRESS] about order 123.","detections":[{"start":6,"end":22,"type":"EMAIL_ADDRESS"}],"requires_review":true}

Your five build milestones

Finish and test one milestone before extending the system. Keep an experiment log with the decision, the alternative you rejected and the evidence behind the choice.

1. Declare the supported scope

   List which identifier types the demo detects and which it does not. Define span offsets and replacement rules, then label a held-out fixture before tuning any patterns.

2. Build transparent detection

   Implement simple pattern detectors and return typed spans with a reason. Keep the original text in memory for the review session rather than logging it by default.

3. Handle span boundaries

   Resolve overlapping detections and apply replacements without corrupting later offsets. Test Unicode and repeated identifiers, with consistent placeholder types and deterministic output.

4. Compare and review

   Optionally compare a hosted detector on the same synthetic cases. Show missed detections and false positives beside the original text, and require human review before exporting shared examples.

5. Test the export boundary

   Inspect browser downloads, API responses and application logs for original identifiers. Publish known gaps and explain that a clean automated result is not a privacy or compliance certification.

How to evaluate your project

Set your acceptance criteria before looking at the final test results. The checks below are proposed experiments, not measured outcomes or a guarantee that a particular model will pass.

• Measure span-level precision and recall by identifier type, stating how partial overlaps are scored.
• Count sensitive test values remaining in exported text and false redactions of harmless order identifiers separately.
• Test replacements, logging and export paths, not just detection accuracy; report all known unsupported formats.

Save your test cases, run command, dependency versions and results together. Compare on identical inputs, retain failures in the denominator and report sample sizes. If a change improves one metric but harms another, explain which trade-off fits your use case.

Failure modes worth demonstrating

• Calling partially redacted text anonymous or promising every identifier has been removed.
• Leaking original values in debug logs, screenshots or downloaded review metadata.

Optional extension

Add a redaction-policy version and re-run older synthetic fixtures whenever a detector or export format changes.

Turn the build into portfolio evidence

Your repository should let another person understand the problem and reproduce the core evaluation without needing your private credentials.

• A README with problem, intended user, architecture, setup commands and a small input/output example.
• A permitted sample dataset, its origin or generator, a frozen test split and a single evaluation command.
• A results table comparing your baseline with your final approach, including failures and sample counts.
• A short demo or screenshots, a limitations section and one decision you would change with more time.
• Environment-variable names without secret values, a dependency list and attribution/license notices for any reused code or datasets.

Resume framing

Describe this as a personal or educational project. State what you implemented, how you tested it and what your measured results were. Replace placeholders with your own evidence; do not claim employer impact, production traffic or accuracy you did not measure.

Built sensitive information redaction workbench using Python, Regex, JSON Schema; evaluated against [baseline] on [N held-out cases], documented [measured result] and [important limitation].

Be ready to explain your decisions

• Why is high redaction precision not enough to prevent data leakage?
• How do you replace overlapping spans without shifting the wrong characters?

Answer with a concrete failure from your implementation, the options you considered, your measured evidence and the limitation that remains.

Google documentation and GitHub references

The project scope, milestones and evaluation plans above are original AIJobFever educational material. These official Google resources offer background or implementation examples; they are not finished implementations of this blueprint. No Google endorsement is implied. Review repository licenses, supported platforms and current costs before reusing code or provisioning services.

• Google Cloud: redacting sensitive information ↗