What happens when you need to share a contract, a screenshot, or a support log without exposing personal data? Until now, many solutions required combining OCR, detection models, storage, and a custom interface. OpenAI Privacy Filter offers a more direct foundation, while gradio.Server helps turn it into scalable web applications.
A model for detecting personal data
Privacy Filter is a 1.5-billion-parameter model, with 50 million active parameters, released under the Apache 2.0 license. It detects categories such as names, addresses, email addresses, phone numbers, private URLs, dates, account numbers, and secrets.
The model works with a context of up to 128,000 tokens and achieves state-of-the-art results on the PII-Masking-300k benchmark, according to its launch information. In practice, this makes it possible to analyze lengthy documents in a single pass, without splitting them into fragments and then trying to reconstruct the original positions.
The advantage is not only detecting sensitive information. It is also preserving exactly where each fragment appears so it can be highlighted, hidden, or replaced.
BIOES decoding helps maintain consistent boundaries in long or ambiguous entities. This matters in documents where a name, an address, and an account number may appear together, such as contracts, résumés, or conversation exports.
Three applications for real-world use cases
The Hugging Face article presents three applications built with the same architecture. Each one has a different interface, but they share a simple rule: everything that needs to run the model goes through an endpoint managed by Gradio.
1. Document Privacy Explorer
You can upload a PDF or DOCX file and read it like a normal document, with each piece of personal information highlighted according to its category. The interface includes sidebar filters and a summary panel with statistics.
The application extracts text with tools such as PyMuPDF and python-docx. Privacy Filter then analyzes the entire content and returns a structure containing the original text, the start and end positions of each entity, the detected category, and statistical data.
The interface is served as a custom HTML page. This makes it possible to use a serif typeface, change filters through CSS classes in the browser, and update the summary without running the model again. Why does that matter? Because reading a sensitive document should feel like reading a document, not filling out a technical form.
The main endpoint is defined with @server.api(name="analyze_document"). This annotation connects the function to Gradio's queue and allows the same service to be consumed from the browser through @gradio/client or from Python with gradio_client.
2. Image Anonymizer
The second use case is designed for Slack screenshots, receipts, Stripe dashboards, or any image containing personal data. The application identifies names, email addresses, and account numbers, then places black bars over them.
The workflow combines OCR with Privacy Filter. First, Tesseract obtains the text and the coordinates of each word. Then, the backend reconstructs the full content and preserves a map between each character and its position in the image.
When the model returns a sensitive fragment, the application checks that map and turns it into pixel rectangles. The frontend receives the image and the coordinates, but everything else happens in the browser:
- Turn all bars in a category on or off.
- Move a bar to correct its position.
- Draw a new bar manually.
- Export a PNG at its natural resolution.
This design avoids sending every adjustment back to the server. The model detects, and the browser handles the editing. It is a very useful separation when you want a fast experience and precise visual controls.
3. SmartRedact Paste
The third example works like a privacy-focused pastebin. You paste an email, a system log, or a support ticket and receive two links.
The public link shows the redacted version with markers such as <PRIVATE_PERSON>, <PRIVATE_EMAIL>, or <ACCOUNT_NUMBER>. The private link requires a token kept only by the person who created the post and allows them to view the original text with the entities highlighted.
Detection also works with multilingual text. The model's examples include Spanish, French, Chinese, Hindi, and other languages, without the application needing to change its main workflow.
Here, redaction is simple: each detected entity is replaced with a category marker before the text is stored. The system can also assign a lifespan to each post and periodically delete expired items.
What gradio.Server adds
You could build these interfaces with gr.Blocks, gr.HighlightedText, or gr.ImageEditor. However, the authors needed more customized experiences: a document reader, a canvas with its own controls, and public and private routes with specific formats.
gradio.Server works as a FastAPI application that also integrates Gradio's capabilities. This makes it possible to mix two types of routes in the same process:
@server.apifor functions that run the model and need a queue.@server.getor@server.postfor HTML pages, quick queries, and files.
The difference is more important than it may seem. An endpoint defined with @server.api can use Gradio's queue, process concurrent requests in a controlled way, work with @spaces.GPU on ZeroGPU, and expose the same method to JavaScript and Python clients.
Regular FastAPI routes are reserved for surfaces that do not require inference. For example, serving the home page, displaying a saved post, or returning a file. There is no point in sending those operations through a model queue.
The architecture in a table
| Application | Queued computation with @server.api | Regular FastAPI routes |
|---|---|---|
| Document Privacy Explorer | Extract text, detect entities, and calculate statistics | Reader page |
| Image Anonymizer | Run OCR, detect entities, and convert spans into rectangles | Canvas interface and examples |
| SmartRedact Paste | Detect entities, redact text, and generate identifiers | Creation page, public and private views |
The browser can connect to the endpoint with Client.connect and send files using handle_file. The result comes back as structured data, for example {text, spans, stats} in the document explorer or {image_data_url, width, height, boxes} in the image anonymizer.
This way, the backend does not need to know every detail of the interface. It only delivers clear data. The frontend decides how to highlight, filter, move, or export it.
Why this pattern scales
The word scalable often sounds like it belongs to massive infrastructures, but here it starts with a design decision: separate inference from presentation.
The model runs on a common, controlled endpoint. Interfaces can change without duplicating the detection logic. In addition, the same endpoint serves both a web application and Python clients, making it easier to create internal scripts, automated tests, or integrations with other services.
In SmartRedact Paste, for example, the complete application code is around 200 lines because storage, routes, and the model all live in the same process. That is enough for a functional prototype or an internal tool, although a public service would need to add persistent storage, robust authentication, usage limits, and clear retention policies.
There is also a practical lesson: automating detection does not eliminate the need for human review. A filter can miss a piece of data or flag text that should not be hidden. That is why the manual controls in the image anonymizer and the ability to review spans in documents are not decorative extras. They are part of a responsible tool.
Applied privacy in AI does not have to start with a gigantic platform. It can begin with a well-defined endpoint, an interface that respects the user's work, and a clear separation between detecting, displaying, and editing. That combination turns a specialized model into tools that solve everyday problems.