PII Redaction: Reduce Data Leakage in AI Workflows

An AI workflow can classify a customer's billing problem without needing their name or email address. PII redaction removes those personal details before the text reaches a model, a log or another system.

For business leaders, the benefit is straightforward: use the information needed to get work done while sharing less personal data. That can make support automation, document analysis and reporting easier to control.

#What redaction looks like

Personally identifiable information (PII) includes names, contact details and other information that can identify someone. Redaction removes selected details or replaces them with placeholders.

Here is an illustrative example using fictional data:

Before:

I'm Jordan Example. Email me at jordan@example.com. I was charged twice for my subscription.

After:

I'm [PERSON_NAME]. Email me at [EMAIL]. I was charged twice for my subscription.

The billing issue remains available for classification or summarization. The receiving system gets less personal information, while an authorized internal system can keep the connection to the customer.

#How much risk does it remove?

When a personal detail is completely removed from the outgoing text and metadata, that payload no longer exposes the original value directly.

Broader privacy risks remain. A detector can miss an identifier. An attachment or log may still contain the original. Even without a name, a unique combination of job title, location and event details may reveal who someone is. NIST's guidance explains why masking alone may be insufficient for de-identification.

Confidential business information needs its own controls too. Removing names from a contract leaves its pricing and terms intact. Use company policies, additional detection and review to protect trade secrets, credentials and sensitive commercial content.

For leaders, the decision is to define what may be shared, with whom, and for what purpose. Redaction helps enforce that decision alongside access controls and retention limits.

#Why run the model locally?

Sending raw text to an external service for redaction exposes it to that service first. Running the detector locally or on-premises lets you remove personal details within your own infrastructure before sharing the result.

NVIDIA's GLiNER-PII is an open model that detects sensitive information in text. It can run on CPU or NVIDIA GPUs. Your team can bring the model to the data and control the surrounding workflow.

Place redaction before external AI calls, shared logs, search indexes and exports. A final check on an AI reply cannot protect copies made earlier.

Here is a simple workflow:

flowchart LR
  subgraph P[Your infrastructure]
    A[Original text] --> B[Detect and redact PII<br/>GLiNER-PII]
    B --> C{Sharing checks}
  end
  C -- Pass --> D[Redacted text for<br/>approved AI or reports]

Sharing checks hold failures and policy exceptions for internal review. The notebook demonstrates redaction; add these checks to the surrounding workflow.

Local deployment still requires restricted access to the original records and careful logging. The goal is to reduce unnecessary exposure throughout the process.

#Technical example with AIBackends

Our sample notebook demonstrates GLiNER-PII through the AIBackends Python library. Colab runs in Google's hosted environment, so use synthetic data there. Run production data in your approved local or on-premises environment.

Use Python 3.11 or later. This example pins the inspected library version:

python -m pip install "aibackends[pii]==0.8.1"

Redact a synthetic message with an explicit list of labels:

from aibackends.tasks import redact_pii

message = (
    "I'm Jordan Example. Email me at jordan@example.com. "
    "I was charged twice for my subscription."
)

result = redact_pii(
    message,
    backend="gliner",
    labels=["person_name", "email"],
)

# Forward only the redacted text.
print(result.redacted_text)

The GLiNER backend uses NVIDIA's GLiNER-PII model by default. Initial setup needs dependencies and model files; once available, inference runs in the local Python process. For an isolated deployment, provision those files in advance.

Choose labels that match your data and inspect the actual output. The before-and-after example above shows the intended transformation; detection can miss details or remove useful text.

Keep the full result private. The result object also contains the original text, detected values and a redaction map. Logging or forwarding the whole object would expose the information you intended to remove. Send only result.redacted_text to the next step.

#Before putting it into production

Test representative documents for missed identifiers and check that the redacted text remains useful. Validate long documents: the wrapper does not split them into chunks, and the underlying model can truncate long inputs. Hold records for review if extraction or redaction fails.

Check attachments, logs and outgoing requests as well as the main text. No detected matches does not prove that a document contains no sensitive information.

Start with one workflow and a clear rule for what can leave it. To plan a private deployment, bring that workflow to a scoping call.