
How InBay Detects Sensitive Information Locally with NVIDIA's GLiNER-PII Model
A behind-the-scenes look at local PII detection, document redaction, and why on-device AI matters for privacy-conscious teams.
Every organisation has documents that contain more personal information than anyone realises.
A contract may include names, addresses, signatures, dates of birth, phone numbers, passport numbers, Medicare details, employee IDs, or health-related information. A PDF may look harmless until you zoom in. A screenshot may contain faces, names, or email addresses hiding in the background. A pasted block of text may have sensitive details buried inside ordinary paragraphs.
It is surprisingly easy to miss all of this before a document leaves your hands.
That is why we built InBay as a local-first sensitive data discovery and redaction tool — designed to scan, highlight, review, and redact sensitive information directly on your computer, before it goes anywhere.
In this post, we go behind the scenes on how that works, and how we use NVIDIA's GLiNER-PII model as part of InBay's on-device detection pipeline.
The privacy problem with "upload first, redact later"
Most AI tools follow the same pattern: upload your document, process it in the cloud, get a result back.
That is convenient. But it creates an uncomfortable question:
What if the document already contains the very information you are trying to protect?
For sensitive workflows, this matters more than people realise. Legal teams handle client information. Healthcare teams handle protected health information. Finance teams handle account numbers and transaction references. Operations teams handle employee records. And many teams paste customer support conversations or internal reports into AI tools without stopping to think about what personal information is sitting inside them.
By the time the tool tells you what it found, your data is already somewhere else.
InBay takes a different approach. The goal is to help teams inspect and clean sensitive documents before they are shared, analysed, uploaded, emailed, or used with other AI systems. The first line of defence happens locally — meaning on your machine, before anything goes anywhere.
What "local" actually means
The word "local" gets used a lot in software. It is worth being specific about what it means here.
Think of it like a smoke detector.
A smoke detector does not send air samples to a laboratory for analysis. It detects smoke right there on your ceiling, in real time, without sending anything anywhere. If you disconnect it from the wall, it still works. Nothing leaves the room.
InBay works the same way.
The NVIDIA GLiNER-PII model is downloaded once and lives on your computer. When you open a document in InBay, the detection happens on your machine — not on our servers, not on NVIDIA's servers, not in any cloud. Your document is never transmitted anywhere just to be scanned.
In practical terms, this means:
- InBay works with your internet connection turned off
- We never see your documents, by design — it is architecturally impossible for us to
- NVIDIA's model has no connection back to NVIDIA once it is installed. It does not send your data to NVIDIA. It does not learn from your files. It simply runs, locally, and does its job
- No third-party AI provider ever touches your content
For businesses in regulated industries, or any team that handles sensitive data with care, this changes the trust model entirely. You are not asking anyone to promise that your data is safe after it has already left your device. It never leaves in the first place.
Why NVIDIA GLiNER-PII?
NVIDIA is best known for the hardware that powers the modern AI industry. But their research teams also build specialised AI models — and GLiNER-PII is one of them.
GLiNER-PII is not a generative model. It does not write, summarise, or guess. It is a detection model, built for one specific job: find spans of text that look like sensitive or personally identifiable information, classify them, and return their exact location with a confidence score.
For example, given the sentence:
Please contact Alex Nguyen at alex@example.com regarding account #4821-X.
GLiNER-PII would return something like:
- "Alex Nguyen" → person name, high confidence, characters 16–26
- "alex@example.com" → email address, high confidence, characters 30–47
- "4821-X" → account identifier, medium confidence, characters 69–74
That precision is exactly what redaction workflows need. It is not enough to know that a document "probably contains PII somewhere." You need to know what was found, where it starts and ends, what type of information it is, and how confident the model is — so you can review it and decide what to do.
How GLiNER differs from older detection tools
Traditional named entity recognition (NER) models were trained on a fixed list of categories. They could find "person", "location", and "organisation" — but adapting them to more specific business labels meant retraining from scratch.
GLiNER is more flexible. At runtime, you can provide the labels you care about, and the model scores possible matches against those labels in context. That matters for privacy work, because sensitive information is not limited to one neat category. Depending on the business, "sensitive" might include names, emails, phone numbers, dates of birth, health references, case numbers, account numbers, customer IDs, addresses, usernames, licence numbers, and more.
GLiNER-PII gives InBay a context-aware detection layer that can be tuned to the kinds of sensitive data your organisation actually handles — without needing to retrain a model.
How InBay's detection pipeline works
Here is a simple walkthrough of what happens when you scan a document in InBay.
Step 1 — Choose what to look for
InBay includes curated lists of PII categories that follow specific government and industry privacy frameworks. You can use one of these out of the box, or customise the list to match what is sensitive for your organisation — whether that is standard contact details, health identifiers, financial references, or something more specific.
Step 2 — Bring in your files
InBay works with PDFs, plain text, images, and scanned documents. You can open a single file, process a whole folder, or use InBay's browser extension to scan text directly on a webpage before you paste or share it. Everything stays on your machine at this stage — no upload required.
Step 3 — InBay extracts the text
Depending on the file type, InBay reads the text content from the document. For PDFs it reads the document layer. For scanned files or images it uses on-device processing to prepare the content for analysis. The result is a text representation ready for the detection model.
Step 4 — The NVIDIA GLiNER-PII model scans the text
The extracted text is passed to the locally installed NVIDIA GLiNER-PII model. This is the step that would normally require a cloud API call in most tools. In InBay, it does not. The model is already on your machine, and the analysis happens there.
The model identifies candidate spans — pieces of text with a start and end position — and compares them against the labels you selected. It returns the detected text, the label, the position, and a confidence score.
Step 5 — InBay surfaces the results for review
Once the model returns detections, InBay highlights them in the document review view. You can see exactly what was found, read the surrounding context, and decide what should be redacted, masked, or left as-is.
This step matters. Automated detection is powerful, but no model — including NVIDIA's — can guarantee 100% accuracy. InBay is designed to keep you in the loop, especially for documents where context changes meaning. A case number in a legal document might need to stay. A name in a medical record might not. That judgement is yours to make.
Step 6 — Export a clean version
After review, InBay exports a redacted or masked version of the document. It also generates a report table of everything that was detected and redacted — so your team has a clear record of what was found and what was cleaned.
Step 7 — InBay wipes the session
Once you are done, InBay clears the session data without a trace. No history is retained. You are ready for the next scan.
Why span-level detection matters
For redaction to be useful, it needs to be precise.
A model that tells you "this document contains personal information" is interesting but not actionable. InBay needs to know:
- What exactly was found?
- Where is it in the document?
- What type of information is it?
- How confident is the model?
- Should a human review it before export?
Because GLiNER-PII returns start and end positions for every detected span, InBay can highlight the exact piece of text rather than flagging an entire page or paragraph as suspicious. This makes review faster and reduces unnecessary over-redaction.
That balance matters. Businesses do not only want to remove risk. They also want to preserve documents that are still readable and useful. Good redaction removes what should not be shared — while keeping everything else intact.
What InBay can help with today
InBay is designed for practical, everyday sensitive document workflows. Current capabilities include:
PDF redaction and masking — review detected PII in PDF files and export a cleaned version with sensitive spans removed or masked.
Text document scanning — work with free-form text where sensitive information may be mixed into normal paragraphs.
Photo and image review — inspect image-based content and use on-device editing tools where needed.
Manual on-device photo editing — blur or mask visual information such as faces or background details directly on your device.
Detection report — review a table of everything detected, what category it belongs to, and what was redacted. Useful for compliance records and team audits.
Document chat — InBay also includes a chat-with-your-document feature, though that uses a separate model pipeline and deserves its own technical post.
The common thread across all of these: give teams more visibility before documents are shared.
Why not just use a large language model?
Large language models are impressive general-purpose tools. But for PII detection and redaction, they are often the wrong tool for the job.
Redaction workflows need consistency, precision, structured outputs, and reviewability. You need a model that can identify the exact piece of text that may be sensitive — not one that interprets, summarises, or occasionally paraphrases. You need confidence scores. You need clear boundaries. You need outputs you can audit.
A specialised span-tagging model is a much better fit for this than a general-purpose chatbot. NVIDIA's GLiNER-PII gives InBay some of the contextual flexibility people like about LLMs — the ability to work with custom labels and understand context — but in a focused architecture built specifically for entity detection.
Local AI is a product decision, not just a technical one
For InBay, running AI locally is not a technical preference. It is a deliberate product choice that changes what customers have to trust — and when.
Instead of asking users to trust that their sensitive documents are safe after they have already been uploaded, InBay helps them inspect and reduce sensitive information earlier in the workflow. Before it goes anywhere.
That is especially important right now. Many teams want to use AI tools more confidently, but they are worried about accidentally exposing customer, employee, patient, student, or client data. Every upload is a decision. InBay helps you make that decision with more information — by showing you what is in the document first.
Scan first. Review locally. Redact what should not be shared. Then decide what is safe to do next.
Where we are going next
NVIDIA GLiNER-PII gives InBay a strong foundation for local sensitive information detection. It powers a practical workflow built around on-device scanning, human review, redaction, and reporting.
But this is only one part of the broader InBay platform.
In future posts we will share more about our Fast Scan mode — instant detection built without AI models, using only programming rules and smart pattern matching — as well as custom privacy frameworks, how InBay handles document chat, how local models are managed and orchestrated on-device, and how businesses can build safer AI workflows without giving up control of their data.
Ready to move your AI workloads on-device safely? If your team is exploring AI but cannot afford accidental data exposure, get in touch with Berrysbay Labs today.