This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.
What I Built
What if the document you shared contained information you thought was already gone?
A document can look perfectly clean on the surface while still carrying sensitive information, forgotten comments, author metadata, tracked changes, or hidden text. We often assume that once something is deleted or edited, it disappears completely. Digital documents can tell a different story.
That is the idea behind Ghost in the Document, a local-first document privacy tool designed to uncover these hidden traces before a file is shared.
The application scans supported PDF, DOCX, and TXT files for potentially sensitive information, examines supported document structures for selected hidden content, and lets users review the findings before choosing what to redact. It then creates a redacted copy and performs post-save checks to help verify the result.
For this challenge, I interpreted Ghost in the Machine as the remnants of information that remain inside our digital files long after we stop thinking about them.
The goal was to turn that idea into something practical: a tool that helps people look beyond what is immediately visible and take greater control over the information they share, without needing to upload their documents to an online AI service.
Demo
See Ghost in the Document in action, from scanning a document to reviewing findings and creating a redacted copy.
Code
GitHub Repository: Ghost in the Document
The project is built with Python and brings together document processing, a Gradio interface, rule-based detection, open-source AI, and locally running language models.
The code is available on GitHub for anyone interested in exploring the implementation or running the project locally.
How I Built It
I did not want to rely on a single model to identify every possible privacy risk. Different kinds of information require different detection techniques, so I built the application around several complementary layers.
1. Rule-Based Detection
The first layer uses regular expressions and predefined rules to identify recognizable patterns, such as email addresses and phone numbers.
These checks are fast and predictable for information that follows known formats. They provide a useful first line of detection before more context-dependent analysis takes place.
2. GLiNER for Named Entity Recognition
Not every sensitive detail follows a predictable pattern. Names, organizations, and locations can appear in many different forms.
I integrated GLiNER to help identify these entities in document text, extending detection beyond what regular expressions alone can reasonably capture.
3. Ollama for Local Language Model Analysis
Some information becomes sensitive because of its context rather than its format. A locally running language model through Ollama adds another layer of analysis to help identify contextual details that simpler methods might miss.
I also included a safeguard that checks whether proposed findings appear verbatim in the source text. This helps reject invented text spans, although it does not eliminate every possible model error or guarantee complete detection.
4. Looking Beyond Visible Text
The contents displayed when opening a document are only part of the picture.
The application also examines supported document structures for selected hidden content, including metadata, comments, tracked changes, and hidden text. These checks help identify traces that may not be obvious to someone simply reading the document.
5. Review, Redaction, and Verification
Finding a potential privacy issue is only the beginning. Users need control over what gets removed, and the application needs to check what happens afterward.
Ghost in the Document lets users review findings and select the information they want to redact. It then creates a separate redacted copy and performs post-save checks on the output.
I wanted this to be a review-driven workflow rather than a process that blindly removes everything a model flags. A successful scan or verification check should not be treated as proof that a document is completely free of sensitive information.
The current version supports text-based PDFs, DOCX, and TXT files. Scanned PDFs and image-based documents requiring OCR are outside the current scope.
One of the main challenges was bringing these different components together into a single, usable workflow. Detection, document processing, redaction, and verification each have their own limitations, and making them work together required treating them as separate but connected stages.
Why Does Open Innovation Matter?
There is an obvious contradiction in uploading a private document to an external service just to check whether it contains private information.
That is one of the main reasons I wanted to explore local AI.
Open-source tools and locally runnable models make it possible to build a workflow where documents can be processed on the user's own machine, without depending on a paid, hosted AI API for the core local workflow.
They also offer flexibility. Rule-based detection, named entity recognition, and language model analysis can be combined, tested, and improved independently. Developers can experiment with different models and approaches rather than being tied to a single closed service.
For a privacy-focused application, that flexibility matters. It makes local processing more accessible and gives users greater control over how their information is handled.
Of course, open-source AI and local execution do not automatically guarantee perfect privacy or accuracy. Models can miss sensitive information, produce false positives, and struggle with unusual document structures. Redaction and verification can also have limitations.
That is why this project combines multiple detection methods with human review and post-save checks instead of treating any single model as the final authority.
The Spirit of It
The unsettling thing about a ghost is not always that it exists. Sometimes, it is the fact that nobody knows it is there.
Documents have a similar problem.
A comment can survive long after a discussion has ended. A personal detail can remain buried in a paragraph. Information that seems to have disappeared can leave traces behind. We edit, save, and share files assuming their history has been left behind, but sometimes it travels with them.
That became the central idea behind Ghost in the Document.
I wanted to interpret the challenge theme in a way that was both creative and useful. Instead of building something spooky just for appearances, I treated the ghosts as the forgotten remnants of information that can follow our digital work.
Building this project also reinforced an important lesson: privacy is not just about detecting sensitive information. It is about helping people understand what has been found, decide what should be removed, and check the result before sharing it.
There is still room to improve detection coverage and strengthen verification, but the purpose remains simple.
Before a document leaves your machine, give it one last chance to reveal what it is carrying.
Team
Built by me, with my teammate @rishi_rajgoel_c5e99c8b81
Top comments (0)